Servizi Sicuri

per le comunicazioni in rete

Secure socket layer (SSL)

Transport layer security (TLS)

HTTP

TCP

SSL/TLS

TCP

HTTP

Handshake Change cipherspec Alert

Record

HTTP

TCP

SSL: Netscape

TLS:RFC 2246

Applicaz.

Applicaz.

TCP

HTTPS

Applicaz.

Sessione e Connessione

• La sessione è un'associazione logica tra Cliente e Server.

• Una sessione viene creata dal protocollo di Handshake e definisce un insieme di parametri crittografici che possono essere condivisi fra molteplici connessioni.

• La sessione evita la costosa rinegoziazione dei parametri di sicurezza per ciascuna connessione

client server

Sessione e Connessione

Sessione e Connessione

Protocollo di Handshake

Ogni messaggio ha tre campi: tipo, lungh., content (parametri associati al tipo)

I protocolli Handshake, Change e

Record client_hello

server_hello

certificate

server_key_exchange

certificate_request

server_hello_done

finished

change_cipher_spec

certificate

client_key_exchange

certificate_verify

change_cipher_spec

finished

server client Protocollo Handshake, Fase 1: selezione

dei meccanismi per la riservatezza, per la

autenticazione e per l’accordo sul segreto Protocollo Handshake, Fase 2 : autentica-

zione del server e invio di chiavi.

Messaggio certificate obbligatorio tranne

per scambio anonymous. Messaggio

server_key_exchange obblig. per DH

anon., ephemeral, RSA se server solo

chiavi di firma RSA

Protocollo Handshake, Fase 3 : autentica-

zione del client e accordo sul segreto

Protocollo Hanshake, Fase 4 (Change)

controllo di tutti i dati scambiati

dati

dati Protocollo Record: scambio sicuro dei

dati

Segreto condiviso

Chiavi installate

I Messaggi Hello

In questa fase il client ed il server si dicono cosa sanno fare ed il client autentica il server

• Messaggio client_hello e server_hello

– Versione di SSL

– Random: timestamp (32 bit) + random byte[28]; client e server generano quantità random diverse

– ID di sessione: in base al valore (1) viene creata una nuova sessione, (2) viene creata una connessione in una sessione esistente (3) vengono rinegoziati i parametri di una sessione esistente

– Suite di cifratura (Cipher suite) specifica la lista degli algoritmi di cifratura supportati dal cliente in ordine di gradimento; ciascun elemento della lista definisce sia il metodo per lo scambio delle chiavi sia una suite di cifratura (algoritmi, hash, vettori di inizial.); il server sceglie

– Metodo di compressione: lista dei metodi di compressione supportati dal client; il server sceglie

9

Hello messages

• client_hello

– client_version

• the highest version supported by the client

– client_random

• current time (4 bytes) + pseudo random bytes (28 bytes)

– session_id

• empty if the client wants to create a new session, or

• the session ID of an old session within which the client wants to create the new connection

– cipher_suites

• list of cryptographic options supported by the client ordered by preference

• a cipher suite contains the specification of the

– key exchange method, the encryption and the MAC algorithm

– the algorithms implicitly specify the hash_size, IV_size, and key_material parameters (part of the Cipher Spec of the session state)

• exmaple: SSL_RSA_with_3DES_EDE_CBC_SHA

– compression_methods

• list of compression methods supported by the client

SS

L H

andshake P

roto

col / P

hase 1

10

Hello messages cont’d

• server_hello

– server_version

• min( highest version supported by client, highest version supported by

server )

– server_random

• current time + random bytes

• random bytes must be independent of the client random

– session_id

• session ID chosen by the server

• if the client wanted to resume an old session:

– server checks if the session is resumable

– if so, it responds with the session ID and the parties proceed to the finished

messages

• if the client wanted a new session

– server generates a new session ID

– cipher_suite

• single cipher suite selected by the server from the list given by the client

– compression_method

• single compression method selected by the server SS

L H

andshake P

roto

col / P

hase 1

11

Supported key exchange methods • RSA based (SSL_RSA_with...)

– the secret key (pre-master secret) is encrypted with the server’s public RSA key

– the server’s public key is made available to the client during the exchange

• fixed Diffie-Hellman (SSL_DH_RSA_with… or SSL_DH_DSS_with…)

– the server has fix DH parameters contained in a certificate signed by a CA

– the client may have fix DH parameters certified by a CA or it may send an unauthenticated one-time DH public value in the client_key_exchange message

• ephemeral Diffie-Hellman (SSL_DHE_RSA_with… or SSL_DHE_DSS_with…)

– both the server and the client generate one-time DH parameters

– the server signs its DH parameters with its private RSA or DSS key

– the client may authenticate itself (if requested by the server) by signing the hash of the handshake messages with its private RSA or DSS key

• anonymous Diffie-Hellman

– both the server and the client generate one-time DH parameters

– they send their parameters to the peer without authentication

• Fortezza - Fortezza proprietary key exchange scheme SS

L H

andshake P

roto

col / P

hase 1

12

Server certificate and key exchange

messages • certificate

– required for every key exchange method except for anonymous DH

– contains one or a chain of X.509 certificates (up to a known root CA)

– may contain

• public RSA key suitable for encryption, or

• public RSA or DSS key suitable for signing only, or

• fix DH parameters

• server_key_exchange

– sent only if the certificate does not contain enough information to complete the key exchange (e.g., the certificate contains an RSA signing key only)

– may contain

• public RSA key (exponent and modulus), or

• DH parameters (p, g, public DH value), or

• Fortezza parameters

– digitally signed

• if DSS: SHA-1 hash of (client_random | server_random | server_params) is signed

• if RSA: MD5 hash and SHA-1 hash of (client_random | server_random | server_params) are concatenated and encrypted with the private RSA key

SS

L H

andshake P

roto

col / P

hase 2

13

Certificate request and server

hello done msgs • certificate_request

– sent if the client needs to authenticate itself

– specifies which type of certificate is requested

(rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, …)

• server_hello_done

– sent to indicate that the server is finished its part of

the key exchange

– after sending this message the server waits for client

response

– the client should verify that the server provided a valid

certificate and the server parameters are acceptable

SS

L H

andshake P

roto

col / P

hase 2

14

Client authentication and key

exchange • certificate

– sent only if requested by the server

– may contain • public RSA or DSS key suitable for signing only, or

• fix DH parameters

• client_key_exchange – always sent (but it is empty if the key exchange method is fix DH)

– may contain • RSA encrypted pre-master secret, or

• client one-time public DH value, or

• Fortezza key exchange parameters

• certificate_verify – sent only if the client sent a certificate

– provides client authentication

– contains signed hash of all the previous handshake messages • if DSS: SHA-1 hash is signed

• if RSA: MD5 and SHA-1 hash is concatenated and encrypted with the private key

MD5( master_secret | pad_2 | MD5( handshake_messages | master_secret | pad_1 ) )

SHA( master_secret | pad_2 | SHA( handshake_messages | master_secret | pad_1 ) )

SS

L H

andshake P

roto

col / P

hase 3

15

Finished messages • finished

– sent immediately after the

change_cipher_spec message

– first message that uses the newly negotiated

algorithms, keys, IVs, etc.

– used to verify that the key exchange and

authentication was successful

– contains the MD5 and SHA-1 hash of all the

previous handshake messages: MD5( master_secret | pad_2 | MD5( handshake_messages | sender | master_secret | pad_1

) ) |

SHA( master_secret | pad_2 | SHA( handshake_messages | sender | master_secret | pad_1

) )

where “sender” is a code that identifies that the sender is the client or

the server (client: 0x434C4E54; server: 0x53525652) S

SL H

andshake P

roto

col / P

hase 4

L’accordo sul segreto (Handshake

2&3):

anonymous Diffie-Hellman

pre_master_secret

|| ||

H H

RC, RS RC, RS

master_secret (48 byte)

RNG esp

n,g

RNG esp

n,g

esp esp n n server_key_exchange client_key_exchange

Prevenzione di attacchi di replay

client_hello: RC

server_hello: RS

L’accordo sul segreto (Handshake

2&3):

fixed Diffie-Hellman

|| ||

H H

RC, RS RC, RS

master_secret

p,g,YS

firma CA

esp esp p,XS

pre_master_secret

p,XC

p,g,YC

firma CA

certificate certificate

L’accordo sul segreto (Handshake

2&3):

ephemeral Diffie-Hellman

RNG esp

n,g

RNG esp

n,g

esp esp n n

pre_master_secret

|| ||

H H

RC, RS RC, RS

master_secret

S

k[privC]

S

k[privS]

k[pubS]

firma CA

k[pubC]

firma CA

V

k[pubS]

V

k[pubC]

certificate

server/client_key_exchange

L’accordo sul segreto (Handshake

2&3):

cifratura asimmetrica

|| ||

H H

RC, RS RC, RS

master_secret

k[pubS]

k[pubS]

firma CA

RNG RSA

RSA

k[privS]

pre_master_secret

client_key_exchange

RX TX RX TX

La verifica del segreto e

la generazione delle chiavi

|| H

Tutti

i dati

scambiati

nei messaggi di handshake precedenti master_secret (48 B)

change_cipher_spec

finished

change_cipher_spec

|| H

Tutti

i dati

scambiati

master_secret

finished

funzione

pseudo-

casuale

funzione

pseudo-

casuale

Record:

riservatezza

Record:

autenticazione

Handshake

H

|| tipo

lung. Z

n° seq.

||

|| int (tipo, vers, lungh frag.)

TCP

= intestazione

TCP

CFR

SI/NO

Alert

MAC segretoT

=

||

H

MAC

tipo

lung.

n° seq.

segretoR

Ek ksT IVT Dk

ksR

IVR

Il flusso “sicuro” dei dati

Z

frag.

Dati HTTP

defrag.

Z-1

Dati HTTP

HMAC

hash(MAC_wr_secret||pad2||hash(MAC_wr_secret||pad1||seq_num||tipo||lungh||frammcompresso))

Il certificato è quello giusto?

Servizi di sicurezza

a livello di rete

IPv4

A B

Rete

Packet sniffing: lettura dei pacchetti in transito

IP spoofing: falsificazione dell'indirizzo del mittente

Connection hijacking: inserimento di dati nei pacchetti in transito

Clogging: generazione di un carico di lavoro inutile ed oneroso

IPSec

A B

Rete

RFC 1636 (1994), RFC 2401, 2402,2406, 2408 (1998)

IPSEC estende sia IPv4 sia IPv6 con funzioni di sicurezza

Autenticazione

Riservatezza

Key Agreement

Indirizzi IP:

4 → 16 ottetti

Riferimento anche per LAN e WAN

Servizi di Sicurezza Offerti •Integrità dei datagrammi

•Autenticazione dell’origine dei dati

•Rifiuto dei pacchetti di ‘replica’

•Confidenzialità

•Confidenzialità parziale del flusso di traffico

IPsec è costituito da tre protocolli:

•Authentication Header (AH) per autenticazione dei pacchetti

•Encapsulating Security Payload (ESP) per confidenzialità ed

autenticazione dei pacchetti

•Internet Key Exchange (IKE) per negoziazione dei parametri di sicurezza,

autenticazione e distribuzione delle chiavi

Applicazioni IPSEC:

Connettività sicure delle sedi locali via Internet

Accesso remoto sicuro via Internet

Routing sicuro

Servizi e Protocolli

SA SA

Componenti di IPSec

IPSec è un’architettura per dare sicurezza al livello IP.

IPSec prevede:

• una suite di protocolli per svolgere servizi: IKE, AH, ESP

• un insieme di entità per istanziare i servizi: SA, SAD, SPD

Host

o

gateway

Host

o

gateway

1a- IKE: Negoziazione

1b- Accordo sulla SA

SA SA

2 - AH: Autenticazione

3 - ESP: Riservatezza

Tipo di protezione

SAD SAD Tipo di traffico

SPD SPD Tipo di politiche

stato! stato!

• SA(Security Association): struttura che identifica in maniera

univoca una connessione unidirezionale tra due interlocutori,

specificando il servizio di sicurezza offerto con i relativi

parametri(chiavi, algoritmi..)

• SPD(Security Policy Database): entità che esamina tutto il traffico

IP, sia in ingresso che in uscita, per decidere quali pacchetti debbano

usufruire dei servizi IPSec e per approntare di caso in caso il tipo di

servizio più adatto

• SAD(Security Association Database): entità che tiene traccia di

quale tipo di servizio per una SA sia stato espletato e in quale modo

Gli elementi di IPSec

Security Association

Valore di SPI nelle

intest. di AH, ESP

per poter selezionare

la SA con cui

elaborare il

pacchetto ricevuto

Parametri di una SA

per gestire l’anti replay

Database di Sicurezza

La funzionalità di SAD deve essere disponibile

pero’ il modo in cui viene fornita è lasciata

all’implementazione

Esempi di Politiche

SPD

Singolo indirizzo, elenco o

intervalli di indirizzi ident. utente

ottenuto dal S.O

I selettori consentono di filtrare il traffico in uscita

per associarlo ad un’opportuna SA

usato per sistemi che

gestiscono la sicurezza del

flusso di informazioni

Invio di un messaggio

Pacchetto IP Quale security policy?

Security rules

SPD

Crea nuova SA

oppure

legge SA esistente

Applica algoritmi

SAD

Pacchetto IPSec

Ricezione di un messaggio

Pacchetto IPSec Trova SA

Applica algoritmi

SAD

Quale security

policy?

Verifica security

policy

SPD

Pacchetto IP

Modalità di incapsulamento

Protezione payload

pacchetto IP

Protezione intero

pacchetto IP

IPSEC Trasporto

IPSEC Tunnel 1.

IPSEC Tunnel 2.

Il servizio per l’autenticazione (AH)

pacchetto

pacchetto

segreto origine

hash integrità

HMAC - MD5 96 bit

HMAC - SHA-1 96 bit

……….

HMAC

segreto condiviso

pacchetto

AH

S/N CFR

HMAC

Il servizio per la riservatezza (ESP)

pacchetto D

chiave origine

cifrario segretezza

chiave segreta condivisa

pacchetto pacchetto E

DES, TDES, IDEA,

RC5, CAST, Blowfish

……….

ESP

Intestazioni

AH (Authentication Header)

ESP (Encapsulating Security Payload)

Campi comuni

- Security Parameter Index (SPI): questo campo di 32 bit, insieme

all’indirizzo IP di destinazione ed all’identificatore di protocollo,

identifica in maniera univoca la SA relativa al datagramma.

- Sequence number field: espleta il servizio di anti-replay tramite la

numerazione progressiva dei datagrammi

- Autentication Data: contiene l’ICV (Integrity Check Value), che

consente di verificare l’integrità del pacchetto in fase di ricezione.

Servizio anti-replay

All’arrivo di ogni nuovo

pacchetto valido, la

destinazione lo marca e

sposta la finestra in modo da

disporlo all’estremità destra

Finestra scorrevole

Lunghezza di default della finestra: 64 pacchetti

Costruzione di AH

Costruzione di ESP

Funzionalità

Trasporto e Tunnel

Pacchetti IP

originali IP header TCP/UDP header||data

IPSec header

Pacchetti IPSec con SA in modalità trasporto

IP header IPSec header

Pacchetti IPSec con SA in modalità tunnel

TCP/UDP header + data

ESP e/o AH

IP header

AH

TCP/UDP header||data IP header

ESP e/o AH

Protocollo IKE

IKE (Internet Key Exchange): meccanismo con cui due interlocutori

possono accordarsi sui parametri relativi ad una SA

(creazione, cancellazione, AH o ESP, ecc.).

• framework ISAKMP (gestione chiavi)

• protocollo Oakley (distribuzione chiavi basato su DH)

• protocollo Skeme (autenticazione)

Identificazione

Scambio D-H

Negoziazione

IKE fase 1: ISAKMP SA

Iniziatore (Ix) Ricevente (Rx)

ID Ix|| ||Sign. Ix HDR|| [CERT]

cifrato

5

ID Rx|| ||Sign. Rx HDR|| [CERT]

cifrato

6

KE|| N Rx HDR|| 4

KE|| N Ix HDR|| 3

HDR|| SA 2

HDR|| SA 1

chiave anonima e nonce chiave anonima e nonce

nome, cert, e firma

nome, cert, e firma

HDR SA 1 HASH N Ix

cifrato HDR SA 2 HASH N Rx

cifrato

Iniziatore (Ix) Ricevente (Rx)

HDR HASH 3

cifrato

IKE fase 2: creazione di una SA

auten., proposta e random nuova chiave

auten., proposta e random nuova chiave