Cryptography and NetworkSecurity

IPSEC

Security architecture andprotocol stack

IP

TCP

SSL/TLS

Applicaz. (SHTTP)

IPSEC

Secure applications:PGP, SHTTP, SFTP,…

or

Security down in theprotocol stack

-SSL between TCPand applic. layer

- IPSEC between TCPand IP

Why not security at link layer?

• Security at link layer: protect IP packet at each hop(there is a shared key among two router that areconnected by a link)

• Good: all traffic is encrypted (including IP header)• Bad: Svantaggi:

– Cooperation among router is required– Significant computatonal effort (when a router receives a

packet it decodes it, then it encode for the next hop)

IP Security

• have considered some application specificsecurity mechanisms– eg. S/MIME, PGP, Kerberos, SSL/HTTPS

• however there are security concerns that cutacross protocol layers

• It is important to have a security protocolthat can be used by all applications

• IP security: security between IP and TCP

IPSec

• IP Security mechanism provides– authentication– confidentiality– key management

• applicable to use over LANs, across public &private WANs, & for the Internet

• Very very complicate specification (RFC2401/2402/2406/2408...)

• mandatory in IPv6, optional in IPv4

IPSec

firewall

Benefits of IPSec

• a firewall/router provides strong security toall traffic crossing the perimeter

• is resistant to bypass• is below transport layer, hence transparent

to applications• can be transparent to end users (allow to

realize Virtual Private Networks)• can provide security for individual users if

desired

IPSec Services

• Access control• Connectionless integrity• Data origin authentication• Rejection of replayed packets

– a form of partial sequence integrity• Confidentiality (encryption)• Limited traffic flow confidentiality

IPSecArchitecture

Security Associations

• A one-way relationship between sender &receiver that affords security for trafficflow

• Defined by 3 main parameters:– Security Parameters Index (SPI)– IP Destination Address– Security Protocol Identifier– Other: sequence number, anti replay window, info.

On used algorithms, lifetime etc.• There is a database of Security Associations

Authentication Header (AH)

• provides support for data integrity &authentication of IP packets– end system/router can authenticate user/app– prevents address spoofing attacks by tracking

sequence numbers

• based on use of a MAC– HMAC-MD5-96 or HMAC-SHA-1-96

• users must share a secret key

Authentication Header

Transport & Tunnel Modes

Authentication Header (AH):transport mode

Note that only part of the header is authenticated

Authentication Header (AH):tunnel mode

Encapsulating Security Payload (ESP)

• provides message content confidentiality &limited traffic flow confidentiality

• can optionally provide the sameauthentication services as AH

• supports range of ciphers, modes, padding– DES, Triple-DES, RC5, IDEA, CAST etc– CBC most common– padding to meet blocksize of the packet

Encapsulating Security Payload

Transport vs Tunnel Mode ESP

• transport mode is used to encrypt &optionally authenticate IP data– data protected but header left in clear– Adversary can do traffic analysis but is efficient– good for ESP host to host traffic

• tunnel mode encrypts entire IP packet– add new header for next hop– slow– good for VPNs (Virtual Private Networks, gateway

to gateway security)

ESP - encoding and authentication:Transport mode

ESP - encoding and authentication:Tunnel mode

Combining Security Associations

• SA’s can implement either AH or ESP• to implement both need to combine SA’s

– form a security bundle

• have 4 cases (see next)

Combining Security Associations

Key Management

• IPSEC handles key generation & distribution• typically need 2 pairs of keys

– 2 per direction for AH & ESP• manual key management

– System administrator manually configures everysystem

• automated key management– automated system for on demand creation of keys

for SA’s in large systems– has Oakley & ISAKMP elements

Oakley

• a key exchange protocol• based on Diffie-Hellman key exchange• adds features to address weaknesses

– cookies, groups (global params), nonces, DHkey exchange with authentication

• can use arithmetic in prime fields orelliptic curve fields

ISAKMP

• Internet Security Association and KeyManagement Protocol

• provides framework for key management• defines procedures and packet formats to

establish, negotiate, modify, & delete SAs• independent of key exchange protocol,

encryption alg, & authentication method

ISAKMP

SSL (Secure Socket Layer)

• transport layer security service• uses TCP to provide a reliable end-to-end

service– originally developed by Netscape– version 3 designed with public input– subsequently became Internet standard known as

TLS (Transport Layer Security)

• SSL has two layers of protocols

SSL Architecture

SSL Architecture

• SSL session– an association between client & server– created by the Handshake Protocol– define a set of cryptographic parameters– may be shared by multiple SSL connections

• SSL connection– a transient, peer-to-peer, communications link– associated with 1 SSL session

SSL Record Protocol

• confidentiality– using symmetric encryption with a shared secret

key defined by Handshake Protocol– IDEA, RC2-40, DES-40, DES, 3DES, Fortezza,

RC4-40, RC4-128– message is compressed before encryption

• message integrity– using a MAC with shared secret key– similar to HMAC but with different padding

SSL - Record Protocol

Authentication: MACSimila to HAMC (uses concatenation instead of EXOR)

Hash(MAC_secret_key || pad2 ||hash(MAC_secret_key || pad1 || seqNum ||SSLcompressed.type ||SSLcompressed.length ||SSLcompressed.fragment))

– pad1=0x36 repeated 48 times (MD5); 40 times(SHA-1)

– pad2=0x5C repeated …– SSLcompressed.type = high level protocol used to

process segment

Metodi di codifica

• Segment 214 = 16384 bytes• compression in SSLv3:

– Compression must be no loss and must guaranteeto reduce pack size

– default: no compressione• Several encryption methods:

– block ciphers: IDEA (128) RC2-40, DES-40, DES(56), 3DES (168),

– Stream Cipher: RC4-40, RC4-128– Smart card: Fortezza

SSL - record

SSL - Payload

SSL Change Cipher Spec Protocol

• one of 3 SSL specific protocols whichuse the SSL Record protocol

• a single message• causes pending state to become current• hence updating the cipher suite in use

SSL Alert Protocol

• conveys SSL-related alerts to peer entity• severity

• Two possibilities: warning or fatal (close connection)

• specific alert• unexpected message, bad record mac, decompression failure,

handshake failure, illegal parameter• close notify, no certificate, bad certificate, unsupported

certificate, certificate revoked, certificate expired,certificate unknown

• compressed & encrypted like all SSL data

SSL Handshake Protocol

Most complex part of SSL• allows server & client to:

– authenticate each other– to negotiate encryption & MAC algorithms– to negotiate cryptographic keys to be used

• comprises a series of messages in phases– Establish Security Capabilities– Server Authentication and Key Exchange– Client Authentication and Key Exchange– Finish

SSL Handshake Protocol

Protocollo di Handshake

4 steps1. Hello: determina funzionalità sicurezza2. Server sends certificate, asks for

certificate and starts excahnge session keys3. Client sends certificate and continues

exchages of keys4. End of handshalke protocol: encoded

methods changesNote: some requests are optional

clear separation between handshake and therest (to avoid attacks)

Handshake : paramatersMessage type parametersHello-request nullClient-hello version,nonce(32B),sessionID,

propos. cipher and compress. methodServer_hello <as before>Certificate X.509v3 chain of certificatesServer_key_exchange info, signature of mess.Certificate_request typ of cert., authorityServer_done nullCertificate_verify signature of certificateClient_key_exchange info, signature of mess.

Finished hash of all exchanged messag.(integrity of handshake prot.)

Handshake Protocol - step 1Initialization : Client_hello: client to Server

– Version = + highest SSL version used by client– 32 bit time stamp + 28 bytes random (a pseudo number

generator is required)– sessionID: 0 0: nex connection; ≠0 update previous

connection– Proposed crypto methods: ordered sequence of acceptable

alg. (first prefered method)– Compression algorithms: ordered sequence of acceptable alg.

: Server_hello: server to client– ack all above

Handshake Protocol - Fase 1Algorithms for key exchange

RSA : session key is encoded with server public keyDiffie-Hellman (several versions)

FissoEffimero Ephemeral Diffie HellmanAnonimo

FortezzaOther decisions:

Crypto algorithm and (either a stream algo or a block algo)MAC algorithmHash (in byte): 0, 16 - MD5, 20 - SHA-1Key material – info used to generate session keysInfo for initializing CBC (initial vector)

Handshake Protocol - step 2

Server authentication and key exchangeServer to client

Certificato: X.509 certificate chain (optional)Server_key_exchange (optional)

Hash(Client_hello.random||ServerHello.random||ServerParms)

Certificate_request: (optional)Server_hello_done: I am done and I wait for

answers

Handshake Protocol - Fase 3

Client authentication• Client verifies server certificates and

parametrs• Client to server

Client Certificate and info to verify it: (if asked)Message for key exchange (Client_key_exchange)

Handshake Protocol Phase 4

Fine: si passa alla fase successi cipher_specClient to server

Messagge: Change_cipher_specFinished message under new algorithms, keys (new cipher_spec)

Server sends backMessage: Change_cipher_specFinished message under new algorithms, keys (new cipher_spec)

TLS (Transport Layer Security)

• IETF standard RFC 2246 similar to SSLv3• with minor differences

– in record format version number– uses HMAC for MAC– a pseudo-random function expands secrets– has additional alert codes– some changes in supported ciphers– changes in certificate negotiations– changes in use of padding

Paying in the Web: SSLSSL and credti card are sued for paying• simple• No need of specilaised software• Compliant with credit card mechanisms• Most used method for paying in the webProblems• Malicious sellers have info on clients• Clients can in princile refuse t o pay (there is no signature)• Many disputes (20%- 60%!)• Expensive method for the shop

Pagamenti con SSL - 3

Esperienza mostra che la gran parte dellecontestazioni è dovuta a pochi cattivicommercianti

Quindi si fa pagare caro le dispute (perespellere i cattivi commercianti)

Però• Si penalizzano i commercianti onesti• I commercianti possono scomparire• non si elimina il problema delle frodi dei clienti

Secure Electronic Transactions(SET)

• open encryption & security specification• to protect Internet credit card transactions• developed in 1996 by Mastercard, Visa etc• not a payment system• rather a set of security protocols & formats

– secure communications amongst parties– trust from use of X.509v3 certificates– privacy by restricted info to those who need it

SET Components

SET Transaction1. customer opens account2. customer receives a certificate3. merchants have their own certificates4. customer places an order5. merchant is verified6. order and payment are sent7. merchant requests payment authorization8. merchant confirms order9. merchant provides goods or service10. merchant requests payment

Dual Signature

• customer creates dual messages– order information (OI) for merchant– payment information (PI) for bank

• neither party needs details of other• but must know they are linked• use a dual signature for this

– signed concatenated hashes of OI & PI

Purchase Request – Customer

Purchase Request – Merchant

Purchase Request – Merchant

1. verifies cardholder certificates using CA sigs2. verifies dual signature using customer's public

signature key to ensure order has not beentampered with in transit & that it was signed usingcardholder's private signature key

3. processes order and forwards the paymentinformation to the payment gateway forauthorization (described later)

4. sends a purchase response to cardholder

Payment Gateway Authorization1. verifies all certificates2. decrypts digital envelope of authorization block to obtain

symmetric key & then decrypts authorization block3. verifies merchant's signature on authorization block4. decrypts digital envelope of payment block to obtain

symmetric key & then decrypts payment block5. verifies dual signature on payment block6. verifies that transaction ID received from merchant matches

that in PI received (indirectly) from customer7. requests & receives an authorization from issuer8. sends authorization response back to merchant

Payment Capture

• merchant sends payment gateway apayment capture request

• gateway checks request• then causes funds to be transferred to

merchants account• notifies merchant using capture

response

Summary

• have considered:– IPSec security framework– AH– ESP– key management & Oakley/ISAKMP