GSMWORLD.it: Stack WAP: WTLS

WIRELESS TRANSPORT LAYER SECURITY (WTLS)

A cura di: Pettisani Diego e Ullo Antonio
Coordinamento: Prof. Alfredo De Santis
Sistemi di elaborazione dell'informazione (Sicurezza su Reti)
Università di Salerno - Anno Acc.1999-2000

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

Privacy
Integrità delle informazioni
Autenticazione

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:

fatal - la sessione viene immediatamente chiusa e viene invalidato anche il relativo Session ID;
critical - la sessione viene chiusa ma può essere usato il relativo Session ID per un’altra transazione in sicurezza;
warning - la sessione viene mantenuta aperta e si segnala uno specifico errore riscontrato durante il ciclo di vita della stessa.

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:

Scambio di hello message per accordarsi sugli algoritmi e per lo scambio di valori random.
Scambio dei parametri crittografici necessari per permettere al client e al server di accordarsi su un pre-master secret (per generare in seguito una chiave di sessione segreta condivisa).
Scambio di certificati e informazioni crittografiche per permettere al client ed al server di autenticarsi.
Generare un master secret (chiave di sessione segreta condivisa) a partire dai segreti pre-master e dallo scambio di valori random.
Fornire i parametri di sicurezza per il livello record.
Permettere al client ed al server di verificare che l'handshake sia terminato con successo senza che vi sia stata una interferenza da parte di qualche attaccante.

Questi obiettivi sono conseguiti attraverso il protocollo handshake che può essere riassunto nel modo seguente.
Il client invia un ClientHelloMessage al quale il server deve rispondere con un ServerHelloMessage (o un eventuale errore fatale se non può essere istanziata una connessione sicura). Il client hello ed il server hello sono usati per stabilire la versione del protocollo, lo scambio delle chiavi, l’algoritmo di crittografia, il metodo di compressione (opzionale), il key refresh (e cioè quanto spesso i parametri della connessione, come chiavi e MAC, devono essere aggiornati) ed il sequence number mode. Inoltre due valori random sono generati e scambiati: il ClientHello.random e il ServerHello.random (utilizzati per schemi di identificazione o scambio chiavi). In seguito ai messaggi hello, il server invia il suo certificato con il messaggio Certificate (se deve autenticarsi) ed eventualmente può richiedere quello del client con il messaggio CertificateRequest (o prelevarlo da un servizio di distribuzione dei certificati).

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.
Il client invia un ClientHelloMessage usando l’ID della sessione sicura da ripristinare. Se il server trova l’ID ed ha la volontà di ripristinare questa sessione sotto questi parametri invia al client un ServerHelloMessage con lo stesso ID. A questo punto il server deve inviare un ChangeCipherSpecMessage seguito immediatamente da un messaggio Finished. Il client non appena riceve questi messaggi risponde con il proprio ChangeCipherSpecMessage seguito da un messaggio Finished.

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

DES
Triplo DES
RC5
IDEA

Funzioni Hash:

MD5
SHA-1

Il WTLS non supporta (ancora) nessun algoritmo di compressione dati, ma comunque è stato progettato per un eventuale futuro supporto.

DISCLAIMER GSMWORLD.it consente all'utente di utilizzare il contenuto della presente pagina a condizione che: a) il documento serva solo a scopi informativi; b) il documento sia usato solo per scopi personali e comunque non commerciali; c) si faccia riferimento all'autore, quando il documento viene usato. GSMWORLD.it non si assume alcuna responsabilità per qualsiasi materiale realizzato o pubblicato da Terzi che sono linkati direttamente da questa pagina. Tutti i marchi, i nomi dei prodotti e dei servizi citati sono registrati dai rispettivi proprietari.