MODELLI DI SICUREZZA

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

Un primo passo per capire come funziona il modello di sicurezza in WAP è quello di capire il modello di sicurezza applicato al World Wide Web.

SICUREZZA IN WWW

Un buon sistema deve cercare di garantire quattro differenti concetti di sicurezza:

• Privacy: garantisce che solo il mittente ed il destinatario possano leggere il contenuto del messaggio cifrato. Per garantire la privacy una soluzione sicura deve assicurare che nessun altro possa vedere, accedere o usare informazioni private (quali ad esempio numero di carte di credito, numeri di telefono,...).
• Integrità: assicura il rilevamento da parte del destinatario di qualsiasi manomissione (anche solo parziale) effettuata sul messaggio originale generato dal mittente. Normalmente se si rileva una manomissione su un messaggio originale il sistema richiede al mittente di reinviarlo.
• Autenticazione: assicura che tutte le parti coinvolte in una comunicazione sono chi dicono di essere. L’autenticazione del server fornisce un mezzo attraverso il quale il client verifica di comunicare proprio con chi desiderava farlo e non con un "shadow-server". Similmente l’autenticazione del client permette di dimostrare al server che il client è proprio chi dice di essere.
• Non-Repudio: è un mezzo per garantire che effettuata una transazione una delle due parti non possa negare di aver preso parte a quella transazione.

Il protocollo SSL (Secure Socket Layer) è ampiamente utilizzato nel mondo WWW di Internet, insieme a meccanismi di firma digitale, per fornire tutti i concetti di sicurezza sopra esposti.

La crittografia a chiave pubblica è un metodo di crittografia utilizzato dal protocollo SSL e consiste nell’utilizzo di coppie di chiavi e algoritmi matematici per convertire testi in chiaro in dati cifrati e viceversa. La coppia di chiavi consiste in una chiave pubblica registrata e una chiave privata che è tenuta segreta dal possessore della chiave stessa. Un messaggio cifrato con la chiave pubblica può essere decifrato solo da chi possiede la chiave privata e analogamente un messaggio cifrato con la chiave privata può essere decifrato solo da chi possiede la chiave pubblica.

Normalmente però questo metodo richiede un elevato livello computazionale ed è utilizzato solo per per scambiarsi piccole quantità di informazioni quali ad esempio una chiave da condividere. Una volta che le due parti hanno una chiave condivisa (e ovviamente non conosciuta da terzi) possono comunicare attraverso algoritmi di crittografia più veloci (in termini computazionali) che si basano appunto su una chiave condivisa tra le due parti. Con questi metodi il protocollo SSL permette di garantire la privacy in una comunicazione Internet.

Invece per garantire l’integrità sono utilizzati degli algoritmi hashing che creano una sorta di impronta digitale su un messaggio. Se anche una piccola parte del messaggio viene alterata durante il suo percorso nella rete automaticamente salta la corrispondenza messaggio-impronta digitale e il destinatario richiede al mittente di spedire il messaggio originale.

I certificati digitali sono invece utilizzati per garantire l'autenticazione e cioè creare una corrispondenza sicura tra il possessore di una chiave pubblica/privata e la sua vera identità. Il certificato stesso è firmato con la chiave privata di una Autorità di Certificazione che crea una dipendenza tra la chiave pubblica e il possessore del certificato (occorre comunque che la Autorità di Certificazione sia una compagnia sicura e fidata). Quando un web browser richiede una conversazione sicura con un web server, il server fornisce al browser le sue credenziali attraverso il server certificate.

Il browser autentica il web server confermando che una Autorità di Certificazione valida ha emanato quel certificato, quindi cifra una chiave da condividere con la chiave pubblica presente nel certificato del Web Server (la chiave da condividere sarà così conosciuta solo dal web server poiché è l’unico in grado di decifrarla attraverso la propria chiave privata). La chiave segreta condivisa è utilizzata per cifrare il resto della comunicazione che a questo punto diviene sicura: in particolare sono rispettate la privacy, l’autenticazione e l’integrità.

Per garantire il non-ripudio, invece, è necessario che una applicazione richieda la firma digitale dell'utente in modo che sia lui ad autorizzare una particolare transazione. L’autorizzazione è cifrata con la chiave privata dell'utente e l’applicazione la decifra con la chiave pubblica prelevata dal certificato dell’utente stesso. Si ha così la garanzia che la transazione sia stata realmente richiesta da quell’utente e inoltre l’utente non può negare di averla fatta in quanto l’autorizzazione a procedere è cifrata con la sua chiave privata (che in linea teorica dovrebbe essere solo di sua conoscenza).

SICUREZZA IN WAP

L’architettura WAP purtroppo non è completamene adattabile al modello di sicurezza sopra esposto per i seguenti due motivi:

• Il protocollo SSL è stato progettato per comunicazioni di tipo wired (ampia banda a disposizione e basse latenze) che vedono coinvolti PC con elevate capacità di calcolo e memorizzazione: una transazione SSL con un terminale WAP comporterebbe notevoli ritardi nella comunicazione andando a incidere enormemente sulle prestazioni e sui costi della comunicazione.
• Il mondo WAP non prevede una comunicazione diretta tra il client ed il web server: tra loro vi è sempre il WAP Gateway che fa da tramite tra il terminale mobile ed il web server.

Per risolvere il problema delle prestazioni è stato progettato un nuovo protocollo (il WTLS) appositamente per i terminali mobili tenendo in considerazione i loro limiti fisici: tale protocollo garantisce comunque un buon livello di sicurezza riducendo enormemente gli overhead del protocollo SSL.

Il problema legato alla presenza del WAP Gateway è stato invece risolto facendo utilizzare a quest’ultimo il protocollo SSL per comunicare in modo sicuro con il web server, mentre per comunicare con il WAP browser utilizza il protocollo WTLS. La necessità di passare da WTLS a SSL (e vice-versa) è resa obbligatoria dalla natura delle comunicazioni wireless che sono caratterizzate da una banda di trasmissione ristretta ed una elevata latenza. Il modello di sicurezza WAP attuale è mostrato nella figura seguente.

Il modello di sicurezza WAP

Si noti che tale soluzione non porta alla realizzazione di un unico canale sicuro tra il client ed il web server (come avviene nel mondo WWW quando si utilizza il protocollo SSL) ma si creano due canali sicuri separati: il primo, tramite il protocollo WTLS, collega il WAP Browser al WAP Gateway mentre il secondo, tramite il protocollo SSL, collega il WAP Gateway al web server. Il punto critico di tale modello è proprio il WAP Gateway.

Il WAP Gateway infatti è il punto di collegamento tra i due canali ed è il responsabile delle traduzioni WTLS - SSL (e viceversa): qui i dati, seppur per brevi istanti, passano in chiaro perchè per tradurre, ad esempio, il WTLS in SSL occorre prima decifrare i dati in WTLS portandoli in chiaro e poi cifrarli in SSL. Tali traduzioni, necessarie al fine di permettere una connessione sicura e virtuale tra i due protocolli, richiedono inoltre del tempo e necessitano di una memorizzazione (seppur temporanea) in una memoria del WAP Gateway.

Affinchè un certo livello di sicurezza sia garantito diventa allora assolutamente indispensabile che:

1. I WAP Gateway non memorizzino mai informazioni decifrate su mezzi di memorizzazione secondari.
2. Il processo di traduzione (cioè decifra WTLS e cifra in SSL, e viceversa) sia il più veloce possibile in modo da eliminare i dati residenti nella memoria volatile interna del WAP Gateway nel più breve tempo possibile).
3. Si garantisca una sicurezza fisica del WAP Gateway, in modo che vi possano accedere solo amministratori autorizzati.
4. Siano limitati gli accessi remoti al WAP Gateway per effettuare operazioni di manutenzione affinchè esso non sia disponibile a nessun altro sito remoto al di fuori del suo firewall.

Per evitare i problemi legati alle traduzioni WTLS - SSL la tendenza attuale da parte dei fornitori di servizi è quella di inglobare il WAP Gateway all’interno del proprio web server: tale soluzione se da una parte aumenta il livello di sicurezza, dall’altra limita le prestazioni della navigazione Internet.

Prendiamo infatti in considerazione il Nokia 7110 (il primo cellulare entrato in commercio con supporto WAP): per effettuare la navigazione Internet occorre settare, prima di cominciare il collegamento, l’indirizzo IP del WAP Gateway attraverso il quale le nostre richieste saranno trasferite in HTTP al web server specificato. Una volta settato l’indirizzo IP del WAP Gateway si può effettuare il classico collegamento Internet specificando il numero del service provider, con il quale abbiamo l’accesso alla rete, e la classica coppia username e password, attraverso le quali ci autentichiamo con il provider stesso. A questo punto se non si è interessati ad una comunicazione sicura ed il WAP Gateway specificato prima del collegamento ha una visione globale della rete, la navigazione Internet avviene in modo del tutto analogo a come la conosciamo.

Supponiamo invece di voler comprare un libro ed effettuare una operazione di trading on-line: non possiamo fare le due operazioni in un unico collegamento se si desidera che queste siano realizzate in modo sicuro e i due web server interessati incorporino anche due diversi WAP Gateway. Infatti prima settiamo il 7110 con l’indirizzo IP del Gateway gestito dal server che vende i libri, ci colleghiamo ed acquistiamo il libro. Dopodichè siamo costretti a disconnetterci, cambiare l’indirizzo IP del WAP Gateway inserendo quello gestito dalla banca con cui fare l’operazione di trading on-line, e infine ci colleghiamo ed eseguiamo l’operazione.

Oltre al discorso della sicurezza va notato che un particolare ISP (Internet Service Provider) che gestisce un Gateway ne può anche limitare la visibiltà nei confronti della rete. Un portale, ad esempio, che gestisce anche un WAP Gateway può avere particolari interessi economici a limitare la visibilità della rete solo nei confronti di alcuni siti/servizi con i quali ha stipulato particolari contratti di sponsorizzazione.
L’alternativa rimane quella della gestione completa e accurata del WAP Gateway e delle traduzioni che esso deve effettuare rispettando i vincoli sopra descritti. Tale soluzione ha sicuramente il grande vantaggio di disaccoppiare il Gateway da un particolare fornitore di servizi (evitando i problemi di prestazioni esistenti per la soluzione che prevede l’accoppiamento Gateway-Web Server) ma richiede una amministrazione più difficoltosa.

A prescindere comunque dalla gestione dei WAP Gateway rimane immutata la fiducia che il client deve avere nei loro confronti. Ovviamente il client prima di riporre la propria fiducia (e magari il proprio denaro) verso un particolare WAP Gateway deve accertarsi della sua identità analizzandone accuratamente il certificato. E' bene chiarire inoltre che l’unico certificato che il client riceve è proprio quello del WAP Gateway con cui comunica e non quello del web server che restituisce i servizi richiesti. Anche l’autenticazione infatti è "spezzata" dalla presenza del WAP Gateway: il client sceglie il WAP Gateway e ne verifica l’attendibilità, il quale a sua volta verificherà l’attendibilità dei siti con cui il client vorrà comunicare. Supponiamo, per chiarire la situazione, che un client debba acquistare online un libro su "Amazon" appoggiandosi al WAP Gateway della "Nokia": il client non può verificare direttamente che il sito cui destina il proprio denaro sia proprio "Amazon" e non uno "shadow server", tale verifica infatti la può svolgere solo il WAP Gateway. E' proprio ora che entra in gioco il rapporto di fiducia client-WAP Gateway: il client verificato che il WAP Gateway con cui comunica è proprio quello della Nokia non si pone il problema della veridicità dei dati che questi gli fornisce.

Il WTLS fornisce tutta una serie di meccanismi che permettono la mutua autenticazione tra il client ed il WAP Gateway (anche quest’ultimo infatti può richiedere il certificato del client per controllarne l’identità). L’autenticazione del client da parte del WAP Gateway è però ancora poco utilizzata per via dell’impossibilità da parte dei dispositivi wireless attualmente in commercio di memorizzare certificati. In futuro tale problema sarà superato integrando dispositivi di memorizzazione simili alle smart card con i terminali mobili.
Inoltre i fornitori di WAP Gateway possono implementare dei meccanismi di uso della firma digitale per garantire anche il concetto di non-ripudio. Sicurezza end-to-end

Le problematiche relative al modello di sicurezza WAP attuale sono allo studio del WAP Forum e l’obiettivo prefissato è quello di realizzare un meccanismo di sicurezza end-to-end tra WAP browser e web server. Fino a che non verrà raggiunto tale obiettivo il WTLS fornirà una connessione sicura solo tra il WAP Gateway ed il client garantendo privacy, integrità e autenticazione tra di loro.

La Phone.com recentemente (settembre 2000) ha iniziato a pubblicizzare uno speciale WAP Proxy, chiamato Secure Enterprise Proxy, che sarebbe in grado di creare un unico canale sicuro tra client e web server. Lo schema della Phone.com è il seguente:

Sicurezza end-to-end con Secure Enterprise Proxy

Purtroppo dalla documentazione disponibile non vengono descritte le specifiche del Secure Enterprise Proxy in maniera approfondita. Comunque d'interessante si può rilevare che il Secure Enterprise Proxy è stato progettato per una futura versione (non ancora pubblicizzata nemmeno dal WAP Forum) di WAP, la versione WAP 1.3. Ricordiamoci che la Phone.com è uno dei membri fondatori del WAP Forum e che quindi è una società più attive riguardo lo sviluppo delle specifiche del WAP.

Di seguito riportiamo un articolo sul Secure Enterprise Proxy datato 26 settembre 2000 apparso su Portel.it: Phone.Com: da oggi transazioni WAP più sicure. "Phone.com ha annunciato di aver rimediato ad un bug che rendeva attaccabile qualsiasi transazione su WAP. Fino a ieri i dati venivano criptati tramite due differenti protocolli: il WTLS - Wireless Transport Layer Security nel percorso telefonino/cella, e il noto SSL nel restante tragitto. Il rapido processo di criptazione/decriptazione che avveniva a metà tragitto rendeva quindi la transazione vulnerabile. Da oggi, grazie all'Enterprise Proxy Server di Phone.com sarà possibile gestire completamente i dati tramite il WTLS, con buona pace di aziende e consumatori." (26/9/2000)

La creazione di questo canale sicuro risolverà quindi il problema del WAP Gateway di tradurre e tenere in memoria per brevissimi istanti di tempo i dati cifrati dal WTLS (e quindi garantirà la privacy che prima veniva a mancare). Resterà da vedere se la presenza del WAP Gateway impossibiliterà lo stesso l'autenticazione 'diretta' tra client e web server, oppure se questo WAP Proxy della Phone.com porterà una soluzione anche a questo problema.