Cryptography and Network Security IPSEC

Cryptography and Network

Security

Security architecture and

protocol stack

IP

TCP

SSL/TLS

Applicaz. (SHTTP)

IPSEC

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

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...)

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)

IPSec

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.

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

Authentication Header (AH):

transport mode

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

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

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

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,

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

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

= 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 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

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

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.

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

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

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%!)

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

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

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

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)

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