Cryptography and Network Security IPSEC Security architecture and - - PowerPoint PPT Presentation

Cryptography and Network Security

IPSEC

Security architecture and protocol stack

IP TCP

SSL/TLS

• Applicaz. (SHTTP)

IPSEC

Secure applications: PGP, SHTTP, SFTP,…

• r

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

IPSec

firewall

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 &
• ptionally 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 214 = 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)

Handshake : paramaters

Message type parameters

Hello-request null Client-hello version,nonce(32B),sessionID,

• propos. cipher and compress. method

Server_hello <as before> Certificate X.509v3 chain of certificates Server_key_exchange info, signature of mess. Certificate_request typ of cert., authority Server_done null Certificate_verify 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.

• rder 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