Mini lezione di reti

Per capire dove ci stiamo muovendo, è fondamentale spiegare seppur brevemente e in maniera semplicistica, come il protocollo TCP/IP funziona.
Per ridurre la complessità di progettazione, la maggior parte delle reti sono organizzate come una serie di strati o livelli, ognuno costruito su quello inferiore: il livello inferiore fornisce dei servizi a quello superiore.(fig. 1)

TCP/IP indica quindi il tipo di protocollo utilizzato, ed in particolare IP si riferisce al livello di rete ( Internet Protocol ), mentre il TCP ( Trasmission Control Protocol) è il protocollo di livello di trasporto impiegato.
Queste possono apparire solo come delle sigle ma dietro ad esse, esiste tutto il progetto di Internet.
Il compito dell'IP è quello di permettere ad un host, di inserire pacchetti in una qualsiasi rete, in modo tale che questi viaggino indipendentemente verso la destinazione. L'importante è notare che questi pacchetti così instradati possono arrivare in un ordine diverso da quello con cui erano stati spediti, sarà poi compito del livello superiore (TCP) ordinarli per fornirli a sua volta all'applicazione ( WEB, FTP, E-mail, ecc. ).  Si capisce quindi che il protocollo di livello di trasporto TCP, fornisce un ordinamento dei pachetti ed eventualmente richede quei pacchetti andati persi nel routing tra reti. A livello trasporto esiste anche il protocollo UDP (User Data Protocol ) che è un protocollo non confermato, e viene utilizzato per lo più per applicazioni non affidabili, o che comunque non rientrano nell'utilizzo del TCP (quest'ultimo è un protocollo pesante e quindi per applicazioni real-time, quali voice su IP e videoconferenze viene utilizzato l'UDP dato che dalla richiesta di un pacchetto andato perso a quando arriva effettivamente, la deadline scadrebbe ) fig.2.

Nei primi numeri di questa rivista, si è spiegato come in Java sia possibile tramite la classe Socket effettuare delle comunicazioni tra host. Quello era un esempio di connessione affidabile e quindi basata su TCP. Mentre la classe DatagramSocket costituisce il punto di accesso all'UDP.
 

La sicurezza in ambiente TCP/IP

Sono possibili diversi di approcci per ottenere una sicurezza in ambiente TCP/IP. Questi sono simili nel servizio che forniscono e nei meccanismi che usano, ma differiscono rispetto al loro ambiente di applicabilità e nella loro relativa localizzazione all’interno dello stack TCP/IP.

Secure Socket Layer (SSL)

L’SSL Record Protocol fornisce i servizi basilari di sicurezza ai vari protocolli di livello più alto. Ad esempio, l’HTTP, che fornisce i servizi di trasferimento per le interazioni WEB client-server, può operare alla cima del SSL. I tre più alti livelli del protocollo sono definiti come parte del SSL: l’Handshake protocol, il Change Cipher Spec Protocol e l’ Alert Protocol. Questi specifici protocolli dell’SSL sono usati nel management degli scambi SSL e saranno analizzati più avanti.
Due importanti concetti dell’SSL sono l’SSL session e la SSL connection, che sono definiti nello specifico come segue:

Connection: una connessione è un trasporto ( nella definizione del modello di layering OSI) che fornisce un adatto tipo di servizio.Per SSL, questa connessione è una peer-to-peer relationships. Le connessioni sono transitorie e ogni connessione è associata con una sessione.

Session: una  sessione SSL è un’associazione tra un client e un server. Sessioni sono create dal Handshake Protocol. Sessioni definiscono un set di parametri di sicurezza crittografica che possono essere condivisi su multiple connessioni. Sessioni sono usate per permettere la negoziazione di nuovi parametri per ogni connessione.

• Session identifier: una sequenza di byte arbitrari scelta dal server per identificare uno stato di sessione, attivo o recuperabile
• Peer certificate: Un certificato X509.v3 del peer, elemento che potrebbe anche essere nullo.
• Compression method: l’algoritmo usato per comprimere i dati prima della criptazione.
• Cipher spec: specifica l’algoritmo di data encryption e l’hash algorithm usato per il calcolo del MAC. Esso definisce anche attributi crittografici quali l’hash_size.
• Master secret:48 byte segreti condivisi tra client e server.
• Is resumable: un flag che indica se la sessione può essere usata per iniziare una nuova connessione.

• Server e client random: una sequenza di byte random che sono scelti dal server e dal client per ogni connessione.
• Server write MAC secret: la chiave segreta usata nelle MAC operation sull’invio di dati dal server.
• Client write MAC secret: la chiave segreta usata nelle MAC operation sull’invio di dati dal client.
• Server write key: la chiave di encryption convenzionale per i dati criptati dal server e decriptati dal client.
• Client write key: la chiave di encryption convenzionale per i dati criptati dal client e decriptati dal server.
• Initialization vectors: quando viene usato un block cipher nel CBC mode, un vettore di inizializzazione è mantenuto per ogni key. Questo campo è prima inizializzato dal SSL Handshake Protocol. Dopo di ciò, il blocco di testo cifrato finale di ogni record è conservato per essere usato come vettore di inizializzazione nel seguente record.
• Sequence numbers: ogni parte mantiene numeri di sequenza separate per trasmettere e ricevere messaggi per ogni connessione. Quando una parte manda o riceve un change cipher spec message, l’appropriato numero di sequenza è settato a zero. Il numero non può eccedere 2^64-1

SSL Record Protocol

• Il SSL Recor Protocol fornisce due servizi per la connessione SSL:
• Confidenzialità: definisce una chiave segreta comune che è usata per il criptaggio convenzionale del payload SSL.
• Integrità dei messaggi: l’Handshake Protocol definisce anche una chiave segreta comune, che è usata per formare un message authentication code (MAC).

• Il primo passo, è dunque la frammentazione. Ogni messaggio di livello più alto è frammentato in blocchi di massimo 2^14 byte .
• Successivamente è applicata la compressione, operazione comunque opzionale. Essa deve essere lossless, cioè priva di errori e non deve incrementare la lunghezza del contenuto di più di 1024 byte. Nella versione 3 dell’SSL non è specificato nessun algoritmo di compressione, e quindi quello di default è il null.
• Lo step successivo consiste nel calcolare un Message Autentication Code (MAC) sui dati compressi. A tale scopo viene usata una chiave segreta.
• Il passo ancora successivo prevede che il messaggio compresso più il MAC, vengano criptati, usando una criptazione simmetrica. La criptazione non può aumentare la lunghezza del contenuto più di 1024 byte, così che la lunghezza totale non ecceda 2^14+2048. Sono permessi i seguenti algoritmi:

Una fondamentale assunzione nella crittanalisi, enunciata per prima da Dutchman A. Kerckhoffs nello scorso secolo, è che la sicurezza di un algoritmo di crittografia deve risiedere interamente nella chiave. Kerckhoffs, assume quindi che il crittanalista, abbia una completa conoscenza dei dettagli dell'algoritmo e quindi una sua implementazione. In generale rompere un algoritmo di criptaggio, non necessariamente significa trovare un modo per permettere ad un intruso, di risalire al plaintext, dal ciphertext. Rompere un algoritmo di criptaggio semplicemente significa trovare delle debolezze, che possono essere espresse con una complessità minore del brute force attack (ricerca esaustiva delle chiavi).
Quest'inciso permette di capire che in genere nella crittografia più lunga è una chiave e più sicure sono le informazioni ( anche quì comunque esistono le eccezioni vedi il Two DES). A causa delle leggi statunitensi sull'esportazione della crittografia, solo alcuni degli algoritmi di fig.6 sono esportabili (utilizzabili tra USA e resto del mondo), ed in particolare l'RC4, l'RC2 e il DES nella versione a 40 bit.
Per gli stream encryption, il messaggio compresso più il MAC vengono criptati, da notare che il MAC è calcolato prima del criptaggio e inoltre il MAC è poi criptato con il plaintext o il plaintext compresso.Per i block encryption, il padding può essere aggiunto dopo il MAC prima del criptaggio. Il padding è nella forma di un numero di padding byte seguiti da un byte che indica la lunghezza del padding. La quantità totale di padding è la più piccola quantità tale che la grandezza totale del dato da criptare (plaintext più MAC più padding) è un multiplo della lunghezza del blocco dell’algoritmo di criptaggio. Ad esempio se il plaintext è di 58 byte, con un MAC di 20,usando un block cipher quale il DES con 8 byte di blocco, allora il campo padding.length sarà 78 byte, e per rendere la lunghezza totale un intero multiplo di 8, saranno aggiunti due byte come padding.

 

• Lo step finale dell’SSL Record Protocol, è di preparare un header, consistente dei seguenti campi:
• Content Type (8 bits): il protocollo di più alto livello usato per processare il frammento.
• Major Version (8 bits): indica la maggiore versione dell’SSL in uso. Per l’SSL v3 questo valore è tre.
• Minor version (8 bits): indica la minore verisone in uso. Per l’SSL v3 questo valore è zero.
• Compressed length (16 bits): la lunghezza in byte del frammento di plaintext ( anche compresso nel caso in cui si usi una compressione). Il massimo valore è 2^14+2048.


I Content Type che sono stati definiti, sono change_cipher_spec, alert,handshake, and application_data, dove i primi tre sono specifici protocolli dell’SSL. Si noti inoltre che non viene fatta nessuna distinzione tra le varie applicazioni (HTTP, SMTP ecc.) che possono usare l’SSL, rendendolo del tutto generale.

Change Cipher Spec Protocol

Alert Protocol

Handshake Protocol

• Fase 1 Stabilire le capacità di sicurezza


Questa fase è usata per iniziare una connessione logica e per stabilire le capacità di sicurezza che saranno associate ad essa. Lo scambio è iniziato dal client che manda un client_hello message fig7a con i seguenti parametri:

Versione: La più alta versione SSL capita dal client. 
Random: Una struttura random generata dal client, consistente di un 32 bit timestamp e di 28 byte generati da un sicuro generatore di numeri casuale. Questi valori servono per prevenire replay attacks e sono usati durante il key exchange.
SessionID: un identificatore di sessione a lunghezza variabile. Un valore non zero indica che il client vorrebbe aggiornare i parametri di una esistente connessione o creare una nuova connessione su questa sessione. Un valore zero invece significa, che il client vorrebbe stabilire una nuova connessione su una nuova sessione.
CipherSuite: questa è una lista che contiene la combinazione di algoritmi supportati dal client, in ordine decrescente di preferenza. Ogni elemento della lista ( ogni cipher suite) definisce sia un algoritmo di scambio chiave sia un CipherSpec.
Metodo di compressione: questa è una lista di metodi di compressione supportati dal client.

Dopo l’invio del messaggio client_hello, il client aspetta un server_hello message fig7b, che contiene gli stessi parametri del client_hello message. Per il server_hello message è applicata la seguente convenzione: Version field contiene la più bassa delle versioni suggerite dal client e la più alta supportata dal server. Il Random field è generato dal server ed è indipendente da quello del client. Se il campo SessionID  era non zero, gli stessi valori sono usati dal server, viceversa il campo del server SessionID conterrà il valore della nuova sessione. Il campo CipherSuite contiene la singola cipher suite selezionata dal server tra quelle proposte dal client. Il campo di compressione contiene il metodo di compressione selezionato dal server tra quelli supportati dal client. 
Il primo elemento dei parametri del Cipher Suite è il metodo di scambio chiave ( poi conventional encryption e MAC). Sono supportati i seguenti metodi di scambio chiave:

RSA 
Fixed Diffie-Hellman
Ephemeral Diffie-Hellman
Anonymous Diffie-Hellman
Fortezza

Dopo la definizione di un metodo di scambio chiave abbiamo il CipherSpec che include i seguenti campi:

Cipher Algorithm 
MAC Algorithm
CipheType: cioè a blocchi o a stream
IsExpotable
HashSize
Key Material
IV Size

A questo punto per far capire meglio cosa avviene, facciamo un esempio di questa fase dell'Handshake protocol: in fig 7c si evidenzia un possibile messaggio del client verso il server che quindi viene svegliato ( corrisponde alla fig. 7a ) 

Una possibile risposta del server, può essere allora quella di figura 7d:

Come si vede dall’esempio sarà il client a dare la preferenza, ma la scelta finale spetta al server fornitore del servizio, che però deve rispettare la priorità. Si noti inoltre che il numero random del server è diverso da quello del client.

Fase 2. Autenticazione del server e scambio chiave
Il server inizia questa fase mandando il suo certificato, se esso è necessario, per essere autenticato.
Il certificate message  è richiesto per ogni metodo di scambio chiave su cui si è d’accordo eccetto per anonymous Diffie-Hellman.
Dopo, un server_key_exchange message potrebbe essere mandato, se richiesto. Esso non è richiesto in due casi: se certificati con il fixed Diffie-Hellman oppure se si usa un algoritmo RSA per lo scambio chiave. Questo messaggio è necessario quindi solo in alcuni casi. 
Il certificate_request message include due parametri: tipo certificato( indica l’algoritmo a chiave pubblica) e l’autorità del certificato ( cioè una lista dei nomi distinti di varie autorità). Il messaggio finale della fase 2 è sempre richiesto: server_done message, che è mandato dal server per indicare la fine del server hello e associati messaggi. Dopo aver mandato questi messaggi il server aspetterà per una client response. Questo messaggio non ha parametri. In figura 8 vengono specificati questi messaggi dove quelli evidenziati sono opzionali e quindi dipendenti dalle particolari situazioni.

 

Fase 3. Autenticazione del Client e scambio chiave
Dopo la ricezione del server_done message, il client dovrebbe verificare che il server ha fornito un valido certificato, se richiesto e controlla che i parametri del server_hello sono accettabili. Se tutto è soddisfatto, il client manda uno o più messaggi indietro al server.
Se il server ha richiesto un certificato, il client inizia questa fase mandando un certificate message. Se nessuna certificazione adatta è disponibile, il client manda un no_certificate alert.
Successivamente il client_key_exchange message, che deve essere mandato in questa fase. Il contenuto di questo messaggio dipende dal tipo di key exchange.
Infine, in questa fase il client potrebbe mandare un certificate_verify message che provvede ad una esplicita verifica del certificato del client (fig.9).

Fase 4. Terminazione
Questa fase completa il settaggio della connessione sicura. Il client manda un change_cipher_spec message e copia il CipherSpec pendente nel corrente CipherSpec. Si può notare che questo messaggio non è considerato parte del HandShake Protocol ma è mandato usando il Change Cipher Spec Protocol. Il client allora immediatamente manderà il finished message con il nuovo algoritmo. Il finished message verifica che lo scambio di chiave e il processo di autenticazione sono stati fatti con successo. In risposta a questi due messaggi il server manda un proprio change_chiper_spec message, trasferendo il pendente al corrente CipherSuite, e mandando il suo messaggio finale. A questo punto l’handshake è completato ( finalmente...) e il client e il server possono iniziare lo scambio di dati dell’application layer.

Questo è quindi il Secure Socket Layer ( per ulteriori approfondimenti si veda lo standard direttamente ); il Transport Layer Security è grosso modo il SSL, ma con delle piccole eccezioni che riguardano per lo più la tipologia di algoritmi supportati: ad esempio il TLS non supporta il Fortezza come scambio chiave, e il calcolo degli schemi di MAC. 
Un'analisi del SSL è stata fatta da Bruce Schneier, uno dei maggiori esperti di crittografia, evidenziando come il Record Protocol sia estremamente sicuro, e l'Handshake Protocol potrebbe esserlo in dipendenza dall'implementazione utilizzata. 
La prossima volta, si affronterà quest'argomento dal punto di vista Java. Si commenterà una possibile implementazione della classe SSLSocket, quella che potrebbe fornire la sicurezza alle applicazioni, e inoltre si spiegherà come ottenerla nel protocollo HTTP col Java Plug-in. 

 
 

Bibliografia

• William Stalling “Cryptography and Network Security” Prentice Hall ed.
• Richard E. Smith “Internet Cryptography” Addison Wesley ed.
• Andrew S. Tanenbaum “Reti di Computer” Prentice Hall ed.

• Bruce Schneier “Applied Cryptography”second edition J.Wiley &Sons ed., un ottimo libro
• www.counterpane.com  il sito di B. Schneier dove si trova di tutto per la crittografia.

 

 

http://home.netscape.com/eng/ssl3/   SSL3 specification

http://www.ietf.org/html.charters/tls-charter.html

http://www.counterpane.com/hotlist.html
ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/     SSLeay un'implementazione in C del protocollo 
http://directory.netscape.com/Computers/Security/Internet/SSL-TLS dove trovare oltre agli standard anche numerose implementazioni in Java