WIRELESS TRANSPORT LAYER SECURITY (WTLS) A cura di: Pettisani Diego e Ullo Antonio Il livello di protocollo che si occupa della sicurezza nell’architettura WAP è chiamato Wireless Transport Layer Security (WTLS). Questo protocollo deriva dal TLS (che si basa sulle specifiche del SSL 3.0) incorporando però alcune nuove caratteristiche (quali ad esempio il supporto dei datagram, un handshake ottimizzato, il refreshing dinamico delle chiavi) ed è inoltre implementato per funzionare su reti di bearer a banda ristretta e relativa alta latenza. Il WTLS è un livello del protocollo opzionale ed è progettato per funzionare sia su connessioni orientate che su protocolli di trasporto datagram (si assume inoltre che le entità di gestione delle applicazioni abbiano i supporti necessari per gestire una connessione sicura). L'obbiettivo principale del WTLS è quello di fornire a due applicazione le seguenti proprietà:
Il WTLS garantisce queste proprietà utilizzando gli stessi schemi di crittografia del SSL. Differenza tra WTLS ed SSL Il WTLS, come detto in precedenza, si basa sulle specifiche dell’SSL ma a differenza di quest’ultimo funziona anche con protocolli di trasporto datagram (come UDP). Tali protocolli sono caratterizzati dal fatto che i dati viaggiano in maniera completamente indipendente tra di loro e inoltre possono essere persi, arrivare non in ordine o addirittura essere duplicati. Queste caratteristiche rendono non utilizzabile il protocollo SSL, così come è stato progettato, su un protocollo di trasporto datagram. Si pensi infatti alla fase di handshake tra un client ed un server: non è pensabile che possa avere un buon esito se, ad esempio, la richiesta di connessione sicura iniziale del client non giunge mai al server o se l’accettazione di un certificato da parte di una delle due entità non arrivi mai all’altra. Per poter supportare i datagram sono stati allora introdotti nel WTLS una serie di meccanismi che fronteggiano l’eventualità che i dati non arrivino mai o arrivino in disordine o siano duplicati. In particolare per superare i problemi sopra citati il WTLS si basa su una macchina a stati asimmetrica (cioè una per il client ed una diversa per il server, l'interazione delle due macchine permette di sincronizzare i dati che le due entità si scambiano in una connessione sicura), sull’uso dei time out per non bloccare una delle due entità nell’attesa infinita della risposta dell’altra, sul controllo della validità del numero di sequenza dei pacchetti in arrivo e sulla concatenazione di più messaggi di handshake che viaggiano nella stessa direzione in un unico pacchetto da spedire. Inoltre WTLS definisce un nuovo tipo di certificato chiamato certificato WTLS. Sebbene i certificati standard X.509 (usati in SSL) sono supportati, essi sono opzionali in WTLS anche perché i cellulari improbabilmente supportano lo standard X.509 per la loro dimensione. Un certificato WTLS fornisce le stesse funzioni di un certificato X.509, di cui è una versione semplificata non contenendo tutti gli stessi campi (come per esempio il nome alternativo), rendendolo più piccolo e quindi più economico da trasmettere. Sottolivelli del WTLS Il livello WTLS al suo interno è logicamente composto da due sottolivelli: un livello inferiore detto Record protocol che "poggia" sul livello di trasporto datagram (WDP) ed uno superiore sul quale si trovano affiancati l’un l’altro tre protocolli: Alert protocol, Change Cipher protocol, Handshake protocol al fine di gestire separatamente e nel contempo, sinergicamente le fasi relative ad una completa realizzazione di sessione in sicurezza.  I sottolivelli del WTLS WTLS Record Protocol E’ il protocollo che gestisce la frammentazione dei messaggi provenienti dai livelli superiori resasi necessaria per la cifratura degli stessi utilizzando algoritmi di cifratura a blocchi. Inoltre, è in questo livello che si fa uso del MAC (Message Authentication Code); sono previsti i digest (l'impronta digitale ottenuta applicando una funzione hash) al fine di conferire l’auspicata integrità al messaggio inviato. WTLS Change Cipher Protocol E’ il protocollo che segnala la transizione dalla fase di handshake-certificazione a fase trasmissione vera e propria utilizzando i metodi di cifratura concordati. Esso consta di un singolo messaggio che viene trasmesso dal client o dal server per segnalare alla parte ricevente che il record che seguirà sarà protetto secondo quanto concordato in fase di negoziazione. WTLS Alert Protocol E’ il protocollo che supporta gli avvisi relativi all’occorrenza di eventuali problemi avuti in fase di gestione di una sessione di sicurezza stabilendo a seconda della tipologia di evento occorso tre livelli di avviso:
WTLS Handshake Protocol I parametri crittografici di una sessione sicura sono prodotti dal protocollo WTLS Handshake che opera sopra il WTLS Record. Quando un client ed un server avviano una comunicazione essi si accordano sulla versione del protocollo, selezionano gli algoritmi di crittografia, si autenticano vicendevolmente e usano tecniche di crittografia a chiave pubblica per generare un segreto da condividere. Il protocollo WTLS Handshake è equivalente a quello dell'SSL e comprende i seguenti passi:
Questi obiettivi sono conseguiti attraverso il protocollo handshake che può essere riassunto nel modo
seguente. In aggiunta il server può inviare un messaggio ServerKeyExchange di scambio chiavi. Una volta che il server ha inviato il suo hello si mette in attesa di una risposta da parte del client. Quest’ultimo deve inviare il proprio certificato (se è stato richiesto) sempre con un messaggio Certificate. Il client invia poi un messaggio ClientKeyExchange di scambio di chiavi (se il suo certificato non contiene abbastanza dati per lo scambio di chiavi), seguito dal messaggio CertificateVerify (utilizzato per fornire una esplicita verifica da parte del server del certificato del client), quindi manda al server un ChangeCipherSpecMessage (che cambia le impostazioni dello stato della connessione) cui fa seguire immediatamente un messaggio Finished (che soddisfa i nuovi parametri di sicurezza stabiliti). Quando il server riceve il ChangeCipherSpecMessage cambia le impostazioni dello stato della connessione e invia a sua volta il proprio ChangeCipherSpecMessage e un messaggio Finished. A questo punto l’handshake è completato ed il client e il server possono scambiarsi i dati in modo sicuro.  Flusso di messaggi per un full handshake Se invece il client ed il server decidono di ripristinare una precedente
sessione sicura invece di negoziare i parametri di sicurezza il flusso dei messaggi è il seguente. Una volta che la connessione è stata ristabilita il client ed il server possono cominciare a scambiarsi dati. Inoltre durate l’handshake abbreviato può essere rinegoziato un nuovo key refresh. E' importante notare che è possibile stabilire molte connessioni sicure su un unica sessione sicura. Ogni connessione sicura stabilita su una stessa sessione sicura condivide con le altre diversi parametri (quali ad esempio la chiave segreta).  Flusso di messaggi in un handshake abbreviato Una variante agli handshake visti in precedenza la si ottiene se il server in seguito ad un ClientHelloMessage può recuperare il certificato del client da un servizio di distribuzione o da una propria sorgente. Se lo scambio di chiavi prevede l’impiego della tecnica Diffie-Hellman, assumendo che i parametri siano forniti dal certificato, il server è in grado già a questo punto di calcolare i segreti pre-master e master. In questo caso allora il server invia il suo certificato, un ChangeCipherSpecMessage ed un messaggio Finished. Il client risponde con un ChangeCipherSpecMessage e i dati possono così essere scambiati.  Flusso di messaggi in un handshake ottimizzato Utilizzando uno pseudo linguaggio di tipo C riportiamo di seguito, a titolo d'esempi, le strutture dei messaggi di hello sopra citati. Client Hello message: struct {
Client_version;
Random;
SessionID;
Client_key_ids;
Trusted_key_ids;
CipherSuites;
CompressionMethod;
SequenceNumberMode;
Key_refresh;
} ClientHello;
Il campo Client_version precisa la versione di protocollo WTLS utilizzata. Random è l’attributo che conterrà un valore casuale calcolato dal client e da inviare al server ad esempio per realizzare schemi di identificazione o di accordo scambio chiavi. Session ID precisa l’identificativo di sessione utile a distinguere più sessioni esistenti nell’unità di tempo. Client_key_ids contiene la lista di identità e chiavi crittografiche che il client supporta. s contiene una lista di tipologie di certificati supportati dal client. CipherSuites contiene la lista degli schemi di crittografia supportati dal client. CompressionMethod contiene la lista dei metodi di compressione dell’informazione supportati. Le liste inviate al server sono ordinate in base alla preferenza di scelta del client. SequenceNumberMode contiene informazioni su come sarà gestita la numerazione della sequenza dei blocchi cifrati. Key_refresh definisce quanto spesso bisogna rinegoziare i parametri di sicurezza. Server Hello message: struct {
Server_version;
Random;
SessionID;
Client_key_id;
CipherSuite;
CompressionMethod;
SequenceNumberMode;
Key_refresh;
} ServerHello;
La struttura del ServerHelloMessage è simile a quella del ClientHelloMessage. Il campo Server_version specifica la versione del WTLS che si sta utilizzando. Il campo Random ha le stesse funzionalità di quello presente nel messaggio di hello del client (i loro valori sono comunque differenti), come il campo SessionID. Il server tra le varie liste che gli ha proposto il client memorizzerà le sue scelte nei campi Client_key_id (l'identità e la chiave crittografica che ha scelto), CipherSuite (lo schema di crittografia che ha scelto) e CompressionMethod (l'eventuale algoritmo di compressione dei dati che ha scelto). Nel campo SequenceNumberMode deve confermare la scelta effettuata circa il modo di numerare i messaggi. Ed infine nel campo Key_refresh il server indica gli intervalli di tempo in cui si effettuerà una rinegoziazione dei parametri di sicurezza. Qualora in fase di scambio messaggi esistesse qualche disaccordo sui parametri proposti dal client, il server attiva i messaggi di errore previsti dal protocollo Alert. Gli algoritmi utilizzati dal WTLS Concludiamo il nostro discorso sul WTLS riportando gli algoritmi di crittografia che supporta. Le informazioni sono state prese dalla più recente documentazione fornita dal WAP Forum sul WTLS datata 18 Febbraio 2000 riguardante la versione WAP 1.2. Algoritmi per lo scambio della chiave di sessione: Algoritmi di cifratura a blocchi, tutti funzionanti in modalità CBC (Cipher Block Chaining):
Funzioni Hash:
Il WTLS non supporta (ancora) nessun algoritmo di compressione dati, ma
comunque è stato progettato per un eventuale futuro supporto.
|
 |
||
 |
Copyright © Marcello Scatà 1997-2002 - Ultima modifica domenica 7 novembre 2004 Execution time 16 ms | ||
| |||
