Cryptography and Network Security IPSEC

Cryptography and Network Security IPSEC

Security architecture and protocol stack Applicaz. (SHTTP) SSL/TLS TCP IPSEC IP Secure applications: PGP, SHTTP, SFTP, or Security down in the protocol stack -SSL between TCP and applic. layer - IPSEC between TCP and 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 are connected 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 specific security mechanisms eg. S/MIME, PGP, Kerberos, SSL/HTTPS however there are security concerns that cut across protocol layers It is important to have a security protocol that 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 (RFC 2401/2402/2406/2408...) mandatory in IPv6, optional in IPv4

firewall IPSec

Benefits of IPSec a firewall/router provides strong security to all 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

IPSec Architecture

Security Associations A one-way relationship between sender & receiver that affords security for traffic flow 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 same authentication 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 every system 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, DH key exchange with authentication can use arithmetic in prime fields or elliptic curve fields

ISAKMP Internet Security Association and Key Management 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: MAC Simila 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 2 14 = 16384 bytes compression in SSLv3: Compression must be no loss and must guarantee to 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 which use 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 steps 1. Hello: determina funzionalità sicurezza 2. Server sends certificate, asks for certificate and starts excahnge session keys 3. Client sends certificate and continues exchages of keys 4. End of handshalke protocol: encoded methods changes Note: some requests are optional clear separation between handshake and the rest (to avoid attacks)

Message type Hello-request Client-hello Server_hello Certificate Server_key_exchange Certificate_request Server_done Certificate_verify Handshake : paramaters parameters null version,nonce(32b),sessionid, propos. cipher and compress. method <as before> X.509v3 chain of certificates info, signature of mess. typ of cert., authority null signature of certificate Client_key_exchange info, signature of mess. Finished hash of all exchanged messag. (integrity of handshake prot.)

Handshake Protocol - step 1 Initialization : 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 1 Algorithms for key exchange RSA : session key is encoded with server public key Diffie-Hellman (several versions) Fisso Effimero Ephemeral Diffie Hellman Anonimo Fortezza Other decisions: Crypto algorithm and (either a stream algo or a block algo) MAC algorithm Hash (in byte): 0, 16 - MD5, 20 - SHA-1 Key material info used to generate session keys Info for initializing CBC (initial vector)

Handshake Protocol - step 2 Server authentication and key exchange Server to client Certificato: X.509 certificate chain (optional) Server_key_exchange (optional) Hash(Client_hello.random ServerHello.random ServerPar ms) 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_spec Client to server Messagge: Change_cipher_spec Finished message under new algorithms, keys (new cipher_spec) Server sends back Message: Change_cipher_spec Finished 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: SSL SSL 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 web Problems 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 delle contestazioni è dovuta a pochi cattivi commercianti Quindi si fa pagare caro le dispute (per espellere 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 Transaction 1. customer opens account 2. customer receives a certificate 3. merchants have their own certificates 4. customer places an order 5. merchant is verified 6. order and payment are sent 7. merchant requests payment authorization 8. merchant confirms order 9. merchant provides goods or service 10. 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 sigs 2. verifies dual signature using customer's public signature key to ensure order has not been tampered with in transit & that it was signed using cardholder's private signature key 3. processes order and forwards the payment information to the payment gateway for authorization (described later) 4. sends a purchase response to cardholder

Payment Gateway Authorization 1. verifies all certificates 2. decrypts digital envelope of authorization block to obtain symmetric key & then decrypts authorization block 3. verifies merchant's signature on authorization block 4. decrypts digital envelope of payment block to obtain symmetric key & then decrypts payment block 5. verifies dual signature on payment block 6. verifies that transaction ID received from merchant matches that in PI received (indirectly) from customer 7. requests & receives an authorization from issuer 8. sends authorization response back to merchant

Payment Capture merchant sends payment gateway a payment 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