INFRASTRUTTURA SICURA

Transcript

1 UNIVERSITÀ DI PADOVA FACOLTÀ DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESI DI LAUREA INFRASTRUTTURA SICURA PER LO SCAMBIO DI DATI SENSIBILI SU RETI WIRELESS Relatore: Chiar.mo Prof. Michele Moro Correlatore: Chiar.mo Prof. Carlo Ferrari Laureando: Rudi Verago Anno Accademico

2

3 a mamma e papà, per il passato, il presente e il futuro, grazie per sempre

4

5 La sicurezza è un processo, non un prodotto, e come tale ha molti componenti, che devono essere affidabili e ben studiati e, soprattutto, collaborare fra loro. Infatti, l efficacia del sistema di sicurezza dipende in modo essenziale da come i vari componenti collaborano fra di loro. A volte i punti deboli sono costituiti proprio dalle interfacce fra i componenti. Un sistema di sicurezza può essere paragonato a una catena, composta da vari anelli, ciascuno dei quali influisce in modo determinante sulla sua resistenza. Come in qualsiasi catena, la forza del sistema di sicurezza corrisponde a quella del suo componente più debole Sicurezza digitale BRUCE SCHNEIER

6

7 Sommario In questa tesi di laurea è stata sviluppata una infrastruttura completa e sicura per lo scambio di dati sensibili, in particolar modo biometrici, su reti wireless di nuova generazione. Abbiamo introdotto il concetto di avere e essere realizzando un modello a doppia autenticazione: autenticazione del dispositivo: infrastruttura a chiave pubblica e instaurazione di un tunnel cifrato autenticazione dell utente: login e password Il primo livello è stato implementato con la modalità a rete privata virtuale (VPN), usando il protocollo IPsec; mentre il secondo mediante la tecnologia dei web service (SOAP). Sono stati realizzati dei servizi web per l utente (invio e ricezione dei file), un interfaccia in Java per l autenticazione e una directory LDAP per la memorizzazione sicura dei dati. Infine sono state analizzate varianti all infrastruttura in particolar modo riguardanti la sicurezza applicata ai messaggi XML (XML-Security). E stata quindi prodotta e definita un infrastruttura interoperabile con differenti piattaforme hardware-software, dotata di un doppio livello di sicurezza in ogni sotto sezione (client, server, autenticazione, rete) ed applicabile sia a reti wireless (WLAN) che a reti cablate. E stato introdotto e implementato il concetto di separazione dei segreti ed infine proposto un utilizzo innovativo del protocollo SOAP. Le applicazioni tipiche rigurdano ambienti dove la sicurezza è l aspetto più importante, ossia applicazioni critiche come ad esempio stazioni di acquisizione di impronte biometriche e reti governative. 1

8

9 Indice 1 Introduzione 7 2 Reti wireless Utilizzo Dispositivi e topologia Livello fisico Wireless e wired Carrier Sense Multiple Access Modulazione x Wireless Security Cenni sulla sicurezza Cifratura Autenticazione Vulnerabilità Parking lot attack e Warchalking EAP e 802.1x AAA: RADIUS Extensible Authentication Protocol Pregi e difetti 802.1x Virtual LAN Attacco: metodologie Difesa: metodologie Il futuro: i

10 INDICE 4 Virtual Private Network Descrizione Modalità Protocolli IPSec AH ESP IKE Traffico IPv IPSec e le reti wireless Vantaggi e svantaggi Infrastruttura: autenticazione del dispositivo Modello VPN Linux FreeS/WAN RoadWarrior Implementazione VPN Certificato server Certificati client Configurazione server Configurazione Client Verifica Sniffer Opportunistic Encryption Prestazioni Considerazioni funzionali Difesa IPsec Web Service e LDAP EXtensible Markup Language Definizione, strumenti e semantica Vantaggi e raccomandazioni Web Service Simple Object Access Protocol

11 INDICE Document-driven SOAP-RPC Web Services Description Language Universal Discovery, Description ed Integration Metodologie Lightweight Directory Access Protocol Biometria Infrastruttura: autenticazione utente e servizi disponibili Directory LDAP Autenticazione utente Upload file Server Client Download File Lista file Ricezione Modifiche Cifratura dati biometrici Doppio Tunnel Altri servizi Controllo connessione Serivizi di amministrazione Considerazioni Funzionali Performace Sicurezza SOAP XML Security XML Digital Signature XML Encryption WS Security e XML firewall SAML e Single Sign-On XKMS e XACML La sicurezza oggi: web service

12 INDICE 8.7 Studio della fattibilità Implementazione XML Security Conclusioni 147 A Sicurezza Informatica 149 A.1 Data Encryption Standard A.2 Advanced Encryption Standard A.3 TwoFish e altri A.4 Crittografia Asimmetrica A.5 SHA e MD A.6 Certificato Digitale A.7 Importazione certificati Windows XP/ A.8 Firme del nuovo millennio A.9 Modelli ISO/OSI e TCP/IP: sicurezza B Software 163 B.1 Java: XML, WS, JNDI B.2 Apache Axis B.3 Jakarta Tomcat B.4 Linux FreeS/Wan B.5 OpenLDAP B.6 Strumenti di rete B.6.1 Ethereal B.6.2 Netperf Elenco degli acronimi 179 Elenco delle figure 185 Elenco dei listati 189 Bibliografia 191 Indice analitico 201 6

13 It is insufficient to protect ourselves with laws; we need to protect ourselves with mathematics Capitolo 1 Applied Cryptography BRUCE SCHNEIER Introduzione Secondo uno studio Gartner il numero di hotspot (punti di accesso) per le reti wireless è aumentato e destinato a crescere ulteriormente: da appena nel 2001 si è passati a circa previsti per il 2004 (circa 1000 in Italia). Il numero di utenti WLAN (Wireless Local Area Network) dovrebbe raggiungere i 15,3 milioni di utenti nel mondo entro la fine del Queste cifre sono piuttosto eloquenti: la tecnologia wireless sta entrando nella vita di tutti i giorni migliorandone la qualità. Attorno alla tecnologia wireless si è creato un luogo comune piuttosto fondato: le WLAN sono insicure. Le cause sono molteplici, se ne possono però individuare due: la cattiva progettazione del protocollo e il fatto che l aria è intrisicamente un mezzo insicuro. Uno degli scopi della tesi è lo studio della sicurezza su reti wireless di nuova generazione per un integrazione nel progetto coordinato dal professore Michele Moro: Infrastrutture innovative per l autenticazione tramite parametri biometrici. Il progetto all inizio prevedeva uno studio principalmente orientato alla integrità e alla cifratura dei dati in modo tale da assicurare la confidenzialità delle informazioni scambiate. Analisi preliminari hanno evidenziato l impossibilità di limitarci a tale aspetto: perciò si è deciso di introdurre il problema dell autenticazione e della memorizzazione sicura introducendo la definizione di un infrastruttura completa. Nella prima parte sono state analizzate le tecnologie e le metodologie adot- 7

14 Introduzione tate, quindi i meccanismi di protezione del protocollo b e g, e ciò che è ancora in fase di definizione: il WPA (wireless protected access). Nella seconda parte ci siamo dedicati alla realizzazione di una infrastruttura sicura per l autenticazione, la trasmissione e la memorizzazione. La nostra infrastruttura prevede un autenticazione a doppio livello: autenticazione della macchina tramite certificati digitali mediante l impiego del protocollo IPsec operante a livello trasporto nella pila ISO/OSI autenticazione dell utente tramite la coppia login-password a livello applicazione mediante l uso dei web service; la memorizzazione dei dati viene fatta su una directory LDAP. Sono quindi ben evidenti due fasi: l autenticazione della macchina può avvenire in maniera trasparente all utente finale mentre l autenticazione a livello applicazione richiede l intervento diretto dell utente. La struttura a doppia autenticazione assicura, virtualmente, una maggiore sicurezza poiché un malintenzionato dovrebbe essere in possesso di entrambi i segreti, quindi fisicamente in possesso di una stazione autorizzata e di un account valido. L amministrazione nel caso di infrastrutture per applicazioni critiche ha un costo elevato, ma siamo riusciti a provvedere un interfaccia semplice da usare. L uso di tecnologie ampiamente sperimentate quali il protocollo IPsec e PKI permettono una certa affidabilità; si farà riferimento ad esse con il nome di tappeto sicuro (secure carpet). L uso sperimentale dei Web Service (WS) assicura invece un ottima portabilità permettendo a sistemi diversi di interagire senza problemi. Sistemi Linux, Sun, della famiglia Microsoft Windows e della famiglia BSD, possono dialogare senza problemi grazie al metalinguaggio XML universalmente adottato. La sperimentazione è stata svolta utilizzando un server Linux ad-hoc e client sia Linux che Windows. Tutti i software usati sono opensource quindi l unico costo da mettere in preventivo è quello che riguarda l amministrazione. 8

15 Introduzione La sezione wireless è stata resa sicura utilizzando probabilmente la migliore tecnologia oggi disponibile, un modello innovativo di comunicazione sicura nato per reti cablate non private: il tunnelling (anche nella sua implementazione sperimentale chiamata Opportunistic Encryption). La definizione di un autenticazione a doppio livello assicura un ottima protezione sul lato client: in tutte le applicazioni oggi esistenti si autentica o il dispositivo o l utente ma mai entrambi, in un contesto critico ciò non è sufficiente. E necessario suddividere le due entità che rappresentano il client (persona e macchina), e autenticarle in maniera distinta. Abbiamo introdotto e proposto una soluzione al concetto dell avere e essere : dobbiamo avere una macchina autorizzata e essere (mediante un account valido) conosciuti dal server. L architettura è stata studiata per offrire due strati di sicurezza in ogni entità: un hacker avrebbe bisogno di due segreti per sferrare un attacco. Un altro particolare concetto introdotto è la separazione dei segreti: un hacker non potrebbe concentrare l attacco su un singolo soggetto, poiché per accedere a parti di esso avrebbe bisogno di informazioni che risiedono in altri luogi. Ad esempio per accedere alle informazioni memorizzate nella directory LDAP avrebbe bisogno di un account valido, ma le credenziali di questo account risiedono nell application server. L applicazione del SOAP (per i web service) è sicuramente inedita in questo contesto: il protocollo viene usato per scambiare file biometrici e per autenticare l utente; inoltre l architettura sviluppata permette di renderlo sicuro; infine permette l uso, come dimostreremo, delle tecnologie attualmente in fase di standardizzazione sulla XML-Security. Un ultimo aspetto da rilevare è l uso del protocollo LDAP: in genere esso viene usato come semplice servizio di directory per informazioni tipicamente testuali come nomi, indirizzi, password... nella nostra infrastruttura invece la directory è usata come repository di file anche binari. Come precedentemente detto i dati sensibili su cui abbiamo centrato il nostro interesse sono dati biometrici ma a costo zero lo studio può essere applicato a qualsiasi tipo di dati delicati. Verranno illustrati i possibili attacchi all infrastruttura sviluppata e i metodi di difesa. Ampio spazio verrà dato anche a possibili modifiche. 9

16 Introduzione Nel secondo capitolo vengono presentate dal punto di vista fisico le reti wireless descrivendone i dispositivi, le topologie e i protocolli del livello 1 e 2 del modello ISO/OSI. Nel terzo capitolo vengono presentate le problematiche di sicurezza inerenti alle WLAN, illustrate le metodologie di difesa disponibili e quelle in fase di sviluppo, infine i metodi di attacco. Nel quarto capitolo viene introdotto il modello IPsec (Internet Protocol Security) su cui sono basate le VPN (Virtual Private Network), vengono descritti i protocolli da cui è composto e le applicazioni possibili. Nel quinto capitolo si descrive l implementazione del primo livello di autenticazione, ossia quello riservato al dispositivo, sia nel caso di reti wireless che nel caso di rete cablate LAN. Vengono illustrate le configurazioni del server e del client, dimostrata la funzionalità e analizzate le prestazioni. Nel sesto capitolo vengono illustrate le tecnologie usate a livello applicazione: XML, Web Service, LDAP. Nel settimo capitolo viene sviluppato l applicativo che esegue l autenticazione e implementa i servizi web disponibili; viene inoltre formalizzata l infrastruttura implementando una directory sicura per la memorizzazione dei dati e un handler ad-hoc per gli account degli utenti. Al termine del capitolo verrà analizzata la struttura nella sua interezza. Nell ottavo capitolo viene presentata una possibile modifica all infrastruttura utilizzando tecnologie attualmente in fase di definizione come XML- Encryption e XML-Signature. Infine nelle appendici sono riportate informazioni storiche, implementative dei software utilizzati e degli algoritmi crittografici. 10

17 Capitolo 2 Reti wireless You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat! ALBERT EINSTEIN Le reti locali (LAN) hanno avuto una larghissima diffusione negli ultimi anni grazie alla loro facilità di installazione, di utilizzo e ad un costo relativamente basso. Lo standard più diffuso è Ethernet con il protocollo specificato dall Institute of Electrical and Electronics Engineers (IEEE), il mezzo trasmissivo impiegato è il cavo coassiale o il doppino. L accesso alle Ethernet è tuttavia limitato a postazioni fisse: per questo (ma non solo) l IEEE ha fondato il working group che ha come scopo la standardizzazione delle reti wireless (WLAN). 2.1 Utilizzo L si propone di ridefinire il livello fisico e il sottolivello MAC (Medium Access Control) del livello datalink del modello ISO/OSI. Le comunicazioni avvengono su radiofrequenze attorno ai 2.45 GHz. L uso di connessioni senza fili assicura alcuni vantaggi rispetto alle connessioni via cavo: mobilità dei terminali minori costi di installazione uso all interno di edifici storici quando è impossibile effettuare un cablaggio oppure effettuarlo comporta costi elevati comodità degli utenti, con conseguente aumento della produttività; uno 11

18 Reti wireless studio di NOP World ha mostrato come le WLAN accelerino la produttività in media del 22% roaming inteso come continuità di comunicazione anche spostandosi da una località ad un altra Le statistiche riguardo all impiego di questa tecnologia sono piuttosto eloquenti: il giro di affari nel 1998 era di 300 milioni di dollari mentre la previsione per il 2005 è di circa 10 miliardi di dollari (fonte Gartner Dataquest). Tutti i più grandi nomi nel campo del networking hanno una loro linea di prodotti wireless: 3COM, IBM, Cisco, Apple, Compaq, Nokia, Lucent, D- Link, Fujitsu e Intersil. Il campo di utenza è altresì molto esteso. Infatti sono molti i professionisti che possono trarne immediati vantaggi: i medici possono avere immediato accesso al database dalla camera dei pazienti, i consulenti accesso alla rete aziendale, i gestori di magazzino per consultazioni on-site e così via. 2.2 Dispositivi e topologia Di norma i dispositivi sono di due tipi: Access Point (AP) e Wireless Terminal (WT). I WT sono schede di rete dotate di antenne, collegate su porte USB, PCMCIA o integrate come nella tecnologia Intel Centrino, mentre gli AP sono bridge di rete. Un insieme di almeno due WT in grado di interagire si chiama BSS (Basic Service Set). In un BSS può essere presente un AP che coordina i WT e fornisce l accesso alle reti; se viene introdotto un Distribution System (DS) che connette gli AP, allora l intera struttura viene chiamata ESS (Extended Service Set). Le configurazioni possibili sono due: Ad-Hoc Network: è la configurazione più semplice, non ci sono ponti verso altre reti e tutti i nodi sono paritari (peer to peer); la trasmissione è presieduta da un master che ha funzioni particolari; è la configurazione che ha maggiori problemi di sicurezza 12

19 2.2 Dispositivi e topologia Figura 2.1: Esempio di ad-hoc network Infrastructure Network: l AP svolge funzioni di bridge tra la sottorete wireless e la rete cablata; esso non è mobile ma è collegato fisicamente alla LAN; ogni AP gestisce un certo numero di WT (al massimo 20); nel caso di comunicazioni tra i dispositivi wireless, l AP funge da ripetitore mentre durante le altre comunicazioni inoltra il traffico nella backbone LAN. Figura 2.2: Esempio di Infrastructure network 13

20 Reti wireless Uno dei più stimolanti utilizzi delle reti wireless è la possibilità di accesso a Internet nei più disparati ambienti; in questa struttura ogni AP è un hotspot che fornisce proprio un punto d ingresso alla rete globale. Secondo uno studio di Analysys Research entro il 2006 vi saranno oltre hotspot locations nell Europa Occidentale suddivisi tra aeroporti, alberghi e bar, dove le persone abilitate godranno del privilegio di essere sempre collegati, a banda larga, alla Rete. 2.3 Livello fisico La diffusione delle WLAN è stata, almeno all inizio, maggiore negli USA rispetto all Europa. Il vecchio continente ha sempre avuto una specie di timore verso questa tecnologia: a causa dell Universal Mobile Telecommunications System (UMTS), le WLAN erano viste come un concorrente e quindi come ostacolo alla diffusione del nuovo protocollo europeo; perciò i vari governi hanno adottato una politica limitante creando un evidente divario di sviluppo; quello che non è stato capito è che i due protocolli sono complementari Wireless e wired Le reti wireless sono contraddistinte da una serie di problematiche non presenti nelle reti cablate: scelta di una banda radio non utilizzata da altre applicazioni potenza del segnale deve essere limitata hidden node: una stazione rivela che il canale è libero ma in realtà un altra sta trasmettendo e il suo segnale non viene ricevuto riflessione dei segnali radio, provoca sfasamenti temporali (multipath finding) rumorosità del canale vulnerabilità poiché i dati sono facilmente intercettabili (ne parleremo ampiamente nel prossimo capitolo) 14

21 2.3 Livello fisico Carrier Sense Multiple Access Sia le reti wireless che quelle cablate si basano sul CSMA (Carrier Sense Multiple Access) in cui l idea di base è che il mezzo trasmissivo sia condiviso, lo scopo principale è la gestione delle collisioni ossia l interferenza causata da sovrapposizioni di segnali distinti. Il meccanismo di base implica che una stazione prima di trasmettere debba ascoltare il mezzo (cavo o etere) per sentire se è già impegnato da qualcun altro, se è libero si inizia la trasmissione. Le WLAN e le Ethernet differiscono a questo livello per la gestione delle collisioni. Nelle reti Ethernet può succedere che due stazioni nello stesso momento percepiscano libero il mezzo e quindi inizino a trasmettere: si genera una collisione che viene, con piccolo ritardo, percepita da entrambe; attendono allora un tempo casuale e riprovano la trasmissione. Questo sistema prende il nome di CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Nell etere è molto difficile sentire le collisioni, quindi è necessario introdurre una variazione al modello chiamata CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Per evitare la sovrapposizione e le interferenze del segnale un client, prima di iniziare la comunicazione, invia un pacchetto di richiesta RTS (Request To Send) all AP che in caso di via libera risponde con un CTS (Clear To Send). Nel caso in cui due client inviino un RTS nello stesso istante, avviene lo stesso una collisione: in questo caso entrambi i WT aspettano un tempo T (calcolato attraverso un algoritmo esponenziale detto di back-off ) prima di ritrasmettere. Tutte le stazioni della rete che riescono a ricevere almeno uno dei pacchetti (CTS o RTS) entrano in uno stato che impedisce loro di accedere al mezzo: ponendo un flag Virtual Carrier Sense Indicator (VCSI) ad ON per tutta la durata della connessione. E richiesto quindi un dispositivo di controllo, appunto l AP; con questo modello si risolve anche il problema del nodo nascosto ma si introduce un maggiore traffico di controllo sulla rete quindi si riducono le performance. Il problema del nodo nascosto riguarda la situazione in cui due WT siano talmente distanti, oppure in mezzo ci sia un ostacolo tale da non permettere 15

22 Reti wireless di sentirsi. Figura 2.3: Problema del nodo nascosto Supponiamo che A e B (figura 2.3) vogliano comunicare con C: A trasmette ma B non riceve il segnale di A, quindi pensa che il canale sia libero. Grazie al meccanismo precedentemente illustrato però B riceve il segnale CTS dell AP, quindi riesce correttamente a gestire il suo accesso al mezzo. Nel caso di Ad-Hoc Network uno dei client (di solito il primo che entra in rete) agisce da arbitro del mezzo Modulazione Sono possibili quattro tipi diversi di livello fisico: infrarossi: non analizzato in questa sede Frequecy Hopping Spread Spectrum Direct Sequence Spread Spectrum Ortogonal Frequency Division Multiplexig Frequency Hopping Spread Spectrum Nelle tecniche SS (Spread Spectrum) viene estesa la banda in modo da produrre un segnale più robusto e facile da rilevare, in modo tale da ottenere un rapporto segnale/rumore favorevole. 16

23 x FHSS (Frequency Hopping Spread Spectrum) usa una portante stretta che cambia frequenza in base ad una sequenza conosciuta dal trasmettitore e dal ricevitore. I salti avvengono su differenze di frequenze tali da evitare interferenze; in altri termini si può dire che il segnale modula, nel corso del tempo di salto, una portante sempre diversa. Il tempo di uso di una portante è di circa 0.4 secondi. FHSS ha un alta potenza trasmessa e un ottima resistenza alle interferenze, di costosa realizzazione sono i modulatori ad alta velocità. Direct Sequence Spread Spectrum Vengono generati dei flussi di bit casuali (chip): per trasmettere un 1 si invia la sequenza di chipping positiva, per trasmettere uno 0 la sequenza negativa; più lunga è la sequenza (di solito bit) di chip, più probabile è che il trasmettitore riesca a ricostruire il messaggio originale. La portante viene modulata quindi da un codice digitale dove il bit-rate del codice è superiore al bit-rate delle informazioni: tutto ciò si concretizza in una maggiore ampiezza di banda. DSSS introduce una bassa potenza di emissione poiché il segnale è espanso in una banda molto ampia, ha una minore resistenza alle interferenze rispetto alla FHSS ma la realizzazione è più economica e quindi permette di raggiungere velocità maggiori a parità di costo. Orthogonal Frequency-Division Multiplexing OFDM consiste nello scomporre il flusso dei dati da trasmettere in N flussi da inviare in parallelo; i flussi sono modulati con portanti ortogonali tra loro, ossia con distanza in frequenza tale da non avere interferenza mutua. L algoritmo OFDM implementa una soluzione efficace per l effetto multipath (riflessione segnali che provoca sfasamenti temporali), assicurando una velocità teorica molto maggiore rispetto sia al DSSS che al FSSS x I principali protocolli utilizzati sono illustrati in tabella. 17

24 Reti wireless Frequenza Banda Velocità a 5 GHz 300 MHz 1-54 Mbps b 2.4 GHz 83.5 MHz 1-11 Mbps g 2.4 GHz 83.5 MHz 1-54 Mbps Tabella 2.1: Protocolli Wireless Qualsiasi protocollo della serie x introduce nella banda di trasmissione il meccanismo dei canali. Si pensi al caso in cui l area di funzionamento di due AP si sovrapponga: si avrebbe distorsione del segnale; grazie ai canali è possibile associare ad ogni AP una banda ben distinta. La convenzione è associare al primo AP il canale 1, al secondo il 6 e così via con distanza 5 canali per ogni AP. Il numero dei canali disponibili dipende dallo standard. In figura 2.4 sono illustrati i canali dei protocolli b/g: si può notare come 4 AP relativamente vicini non creino interferenza uno con l altro poiché operano su bande differenti. Un regola pratica consiglia di usare al massimo tre canali diversi all interno della stessa rete (nel nostro caso ) E nato nel 1997 ed è il capostipite di tutti i protocolli wireless. Aveva specifiche a 1 e 2 Mbit/s, modulazione di tipo DHSS e FHSS: le prestazioni a detta di molti esperti erano insufficienti; soffriva soprattutto di problemi di interoperabilità. Nel 1999 è stato sostituito dal a e dal b a L a utilizza la codifica OFDM e usa otto canali di trasmissione (4 non sovrapposti). Esistono specifiche per data rate di 6, 9, 12, 18, 24, 36, 48, e 54 Mbps. Ha una copertura di circa 20 metri a ha avuto diffusione quasi esclusivamente in Canada e America poiché la banda utilizzata (5 GHz) non era disponibile (libera) in altri stati. 18

25 x Figura 2.4: Canali nel protocollo b e g 19

26 Reti wireless b Usa la modulazione di tipo DSSS, ha 13 canali in tutto ma 3 non sovrapposti. Permette una copertura massima (alla massima velocità) di circa 30 metri all interno e di circa 100 metri all esterno, la potenza dei sistemi wireless tipicamente varia tra i 30 e i 100 mw. I prodotti che implementano l b e rispettano le direttive WECA (Wireless Ethernet Compatibility Alliance) in merito sono dotati del marchio Wi-Fi g L g usa tecnologie molto simili a quelle dell a permettendo data rate di 54 Mbit/s ed è completamente compatibile con l b. Usa OFDM e ha 3 canali non sovrapposti. Assicura la copertura dell b g è stato rilasciato nel giugno In tutti i protocolli illustrati la velocità delle trasmissioni viene variata dinamicamente in base al rapporto segnale/disturbo. 20

27 Wireless security is like safe skydiving - if you want the safety and security, just don t do it Capitolo 3 KENNETH NEWMAN Wireless Security Le varie tipologie di reti cablate (Ethernet, Token Ring... ) non prevedono meccanismi di sicurezza mentre nella definizione delle reti wireless si sono date delle specifiche di cifratura, autenticazione e integrità che sono risultate però, alla prova dei fatti, insufficienti. Non è stata posta particolare attenzione al fatto che l aria è un mezzo intrinsecamente insicuro. Per attaccare una rete cablata si deve avere un punto di accesso fisico e quindi una postazione collegata alla rete, mentre nelle WLAN tutto ciò non è necessario; un aggressore potrebbe effettuare tranquillamente il suo attacco all esterno dell edificio dove è installata la WLAN, ad esempio lungo il perimetro esterno avendo infatti tutti accesso all etere! 3.1 Cenni sulla sicurezza Per rendere sicuro il traffico delle informazioni si devono cifrare i dati, garantire che non vengano modificati e autenticare gli attori della comunicazione. Queste pretese non sono eccessive, basti pensare alla normale comunicazione cartacea; parasafrando Zimmerman possiamo dire si inviano cartoline per i saluti ma si usano buste chiuse per le lettere d amore. Cenni di crittografia Esistono due fondamentali tecniche crittografiche: a chiave simmetrica (chiave segreta) e a chiave asimmetrica (chiave pubblica). 21

28 Wireless Security Consideriamo il caso in cui due persone A e B vogliano scambiarsi un file. Nella metodologia a chiave simmetrica entrambi gli attori conoscono un segreto, rappresentato tipicamente da una sequenza di bit relativamente lunga (qualche decina o centinaia di bit); la persona A elabora il file con la chiave e lo trasmette, l utente B con la stessa chiave esegue l operazione inversa e ricostituisce il file nella forma originaria. Gli attori si devono accordare sul sistema di cifratura (algoritmo) e sulla chiave. La debolezza di questo sistema si basa sulla difficoltà maggiore o minore, da parte dell hacker, di indovinare la chiave, mentre il pregio è la semplicità. Gli algoritmi più diffusi sono il DES (Data Encryption System), l AES (Advanced Encryption System), l IDEA (International Data Encryption Algotithm), il BlowFish e il TwoFish. Il limite fondamentale è dato dalla necessità tra coppie di attori di scambiarsi chiavi attraverso canali sicuri e la congiunta proliferazione della chiavi. Figura 3.1: Crittografia a chiave simmetrica La crittografia a chiave pubblica (PKI, Public Key Infrastructure) prevede che ogni utente abbia una coppia di chiavi, una privata e una pubblica, e che esista un algoritmo in grado di cifrare con una chiave e decifrare con l altra. L utente B diffonde il più possibile la sua chiave pubblica, l utente A acquisisce questa chiave, utilizzandola cifra il file e lo trasmette; l utente B decifra il file usando la propria chiave privata. L assunto fondamentale è che la chiave privata non sia facilmente ricavabile da quella pubblica e dai messaggi cifrati, essendo questi scambiati attraverso canali insicuri. Per un utilizzo corretto si deve inoltre assicurare l autenticità della chiave pubblica attraverso la sua certificazione che garantisce che quella chiave pubblica sia stata generata dall attore che legittimamente possiede la relativa chiave privata. Questo meccanismo di certificazione av- 22

29 3.1 Cenni sulla sicurezza Figura 3.2: Crittografia a chiave asimmetrica viene tramite un organo chiamato certification authority CA (per maggiori informazioni si rinvia all Appendice A.6). L algoritmo più utilizzato è il RSA (dal nome dei loro inventori Rivest Shamir Adleman). La sicurezza degli algoritmi, sia a chiave simmetrica che asimmetrica, dipende dalla loro robustezza (cioè dall invulnerabilià a possibili attacchi) e dalla lunghezza della chiave: più è lunga più sicura è la comunicazione. Gli algoritmi PKI (Public Key Infrastructure), cioè quelli a chiave asimmetrica, sono di solito dalle 100 alle 1000 volte più lenti di quelli a chiave simmetrica, quindi frequentemente si ricorre a tecniche ibride: la PKI viene usata all inizio della connessione per scambiarsi la chiave segreta, ed in seguito la comunicazione avviene con algoritmi a chiave simmetrica. Firma elettronica e digitale L utente che invia il file deve anche avere la certezza che il destinatario riceva esattamente quello che ha inviato: a tale scopo si usano meccanismi di verifica dell integrità basati su un riassunto matematico del file (firma elettronica). Si deve garantire che due file diversi non abbiano la stessa firma. Dalla firma elettronica deve essere impossibile risalire al messaggio originale. Esistono vari tipi di firme digitali, per maggiori informazioni si rimanda all Appendice A.8. La firma digitale invece corrisponde alla firma elettronica avanzata, ed è la sola che conferisce al documento informatico il pieno valore legale. E un particolare tipo di firma elettronica qualificata basata sul sistema di chiavi asimmetriche. 23

30 Wireless Security 3.2 Cifratura Il protocollo di cifratura definito negli standard a/b/g è il WEP (Wired Equivalent Privacy): in esso le chiavi sono statiche (fisse, non variano nel tempo), impostate manualmente e devono essere scambiate tra tutti gli utenti della rete. Si basa sull algoritmo simmetrico RC4 e lavora a livello datalink (livello 2) nella pila ISO/OSI. La lunghezza delle chiavi WEP varia da 40 a 128 bit (256 e 512 sono di solito soluzioni proprietarie). 3.3 Autenticazione Abbiamo detto che ogni AP gestisce una sottorete cioè regola il traffico dei WT di cui percepisce il segnale. A ciascuna di queste sottereti è associato un nome SSID (Service Set IDentifier) univoco. Lo SSID è un identificatore di 32 caratteri che viene inserito in tutti i pacchetti trasmessi. Per connettersi ad una WLAN quindi il WT deve preventivamente conoscere almeno un SSID. L autenticazione di base nelle WLAN può riferirsi sia all utente che alla scheda di rete WT. L autenticazione della scheda di rete, nelle specifiche del protocollo , avviene solamente sull AP. L autenticazione dell utente invece richiede l utilizzo di un server esterno alla WLAN, verrà descritta nella sezione 3.6. Nell sono previsti due metodi di autenticazione di base: open key: il caso più semplice, qualunque client può autenticarsi con l AP conoscendo solo il suo SSID; nel caso in cui il WEP sia attivo viene abilitato solo il traffico di rete cifrato con la chiave dell AP e con il SSID corretto shared key: utilizzato solo con WEP attivo, si articola in più fasi: 1. il client invia la sua identità in chiaro all AP, quindi invia il suo MAC, le impostazioni sulla velocità di connessione e l SSID 2. l AP risponde con un challenge in chiaro ossia un breve pacchetto che deve essere elaborato dal WT e ritrasmesso 3. il client cifra il challenge con la chiave WEP e lo restituisce all AP 24

31 3.4 Vulnerabilità 4. l AP controlla che il challenge sia cifrato correttamente (quindi con la chiave WEP esatta) e invia uno status code al client Uno dei metodi di autenticazione più sicuri ma allo stesso tempo più semplici è quello che si basa sul MAC (Media Access Control) address filtering. L access point ha una lista di MAC e permette l autenticazione solo a WT che hanno il MAC address (univoco per ogni device) all interno di questa lista. Il MAC filtering però introduce seri problemi di amministrazione, è necessario infatti tenere aggiornate tutte le tabelle degli AP; inoltre nel caso in cui un visitatore voglia avere accesso temporaneo, è essenziale aggiornare temporaneamente le tabelle. Tale incubo potrebbe essere accettato se il sistema fosse invulnerabile ma con tool liberamente disponibili non è difficile catturare MAC autorizzati e mascherare il proprio. 3.4 Vulnerabilità Il SSID dovrebbe essere considerato il primo livello di sicurezza: è infatti la prima (e troppe volte unica) informazione che un WT deve conoscere per poter accedere alla rete. Proprio per questo dovrebbero essere adottati tutti gli accorgimenti che si usano nel caso di una normale password: dovrebbe essere ad esempio relativamente lunga, composta da lettere, numeri, simboli e non facilmente deducibile. Quando esce dalla fabbrica ogni AP ha associato un SSID di default, di solito è uguale alla parola default, al nome dell azienda oppure a stringhe banali come abc, La prima regola fondamentale è pertanto cambiarlo appena si installa l AP. In molte reti l SSID è inviato in broadcast a tutti i client per facilitare le operazioni di ingresso nella WLAN: è pertanto indispensabile a tutti i livelli disabilitare questa opzione. Un secondo livello di sicurezza, valido anche per le reti wired, è quello di disabilitare il Dynamic Host Configuration Protocol (DHCP). DHCP è un protocollo dell IETF che associa in maniera dinamica ad ogni nuovo client della rete un indirizzo IP e che invia il gateway e la netmask. Disabilitare il DHCP significa che l utente, prima di instaurare la connessione, deve specificare il suo IP e le altre informazioni di rete. Per un hacker tutto ciò rappresenta 25

32 Wireless Security un ulteriore ostacolo in quanto dovrebbe conoscere anche il range di indirizzi della rete che vuole attaccare. Il WEP ha lacune piuttosto gravi. Innazitutto è un protocollo a chiave condivisa, il che non è un inconveniente in una azienda piccola, ma in una grossa rete (centinaia di terminali) lo scambio della chiave tra tutti gli utenti la rende piuttosto vulnerabile; oltretutto molte volte la chiave WEP è uguale all SSID. Altro inconveniente è la staticità: chiavi così corte, non dinamiche, facilitano gli attacchi basati sulla forza bruta ossia gli attacchi basati sulla generazione sequenziale delle chiavi. Consideriamo il caso in cui venga usata una chiave da 64 bit: 40 bit sono riservati alla chiave WEP e gli altri 24 sono associati ad un numero casuale chiamato Initialization Vector (IV). Il pacchetto inviato contiene i dati cifrati con i bit ma è preceduto dallo IV in chiaro riducendo pertanto la chiave ai rimanenti 40 bit. Figura 3.3: Schema a blocchi dell algoritmo RC4 La maggior vulnerabilità dipende partanto dal datato algoritmo RC4. Il riuso di identici IV produce identiche chiavi e ciò avviene spesso a causa del piccolo numero di bit usati; inoltre molti dispositivi usano sempre le stesse 26

33 3.5 Parking lot attack e Warchalking sequenze di IV. I ricercatori Stubblefield, Ioannidis e Rubin hanno dimostrato, nello studio intitolato Using Fluhrer, Mantin and Shamir attack to break WEP [28], che l uso di uno stesso IV consente ad un hacker di risalire alla chiave WEP usata analizzando il traffico cifrato (si rimanda alla bibliografia per maggiori informazioni). Essi hanno sperimentato inoltre che sono sufficienti da a di pacchetti per risalire alle chiavi, tali pacchetti rappresentando il traffico di circa un ora di comunicazioni. Un ulteriore debolezza è l uso del semplice Cyclic Redudancy Check (CRC) per l integrità dei dati: infatti è noto che si può calcolare la differenza di CRC di due messaggi che differiscono di un solo bit. Iterando la tecnica è possibile modificare arbitrariamente n bit di un messaggio e aggiustare correttamente il CRC. Palesi debolezze si notano nel processo di autenticazione. Il modello open key non offre nessun tipo di sicurezza e il modello shared key non assicura il principio base dell autenticazione, quindi non c è nessun meccanismo che identifichi in maniera precisa il client. Un esempio significativo viene dato da Kenneth Newman in una sua famosa presentazione:... dalla finestra del mio appartamento riesco a captare il segnale di 12 AP in 5 minuti: 6 default (nessuna protezione, come sono usciti dalla fabbrica) e 3 WEP... camminando in Wall/Water/Broad Streets 150 AP in 20 minuti... in macchina 448 in 90 minuti: 75 defaults, 26% WEP Parking lot attack e Warchalking Gli hacker hanno trovato nuovi espedienti e nuove soluzioni per attaccare con successo le reti wireless. Le risorse tipiche di un attacker di WLAN sono notebook (o portatile), una scheda wireless, uno sniffer come AirSnort, AiroPeek ed eventualmente una 27

34 Wireless Security Figura 3.4: Un hacker italiano di WLAN antenna omnidirezionale o direzionale (per poter ricevere segnali distanti). Sono sufficienti queste risorse per effettuare un parking lot attack cioè un attacco dal parcheggio. Possiamo pensare ad un hacker in giro in bicicletta o seduto comodamente in macchina che prova ad annusare l aria in cerca di una WLAN da attaccare. Per quanto pittoresca possa sembrare, questa è la realtà attuale; nell ambiente underground l antenna fatta con i tubi delle patatine Pringles è uno strumento indispensabile! Figura 3.5: L antenna fai-da-te 28

35 3.6 EAP e 802.1x Gli hacker hanno sviluppato anche un codice: il warchalking (guerra dei gessetti), composto da una serie di simboli che vengono lasciati sui muri o per terra davanti ad uffici ed aziende. Grazie a questi simboli il lavoro di attacco è notevolmente semplificato, vengono in questo modo comunicate le esperienze già effettuate su quella particolare rete. Una ricerca ha evidenziato questo fenomeno: dei giornalisti del settore sono andati in giro per i centri commerciali di Londra, New York e Sidney e hanno verificato che in media dal 60-70% delle reti erano facilmente bucabili, quindi la protezione massima che potevano avere era la cifratura WEP attivata e la autenticazione shared key. La ricerca, commissionata dalla RSA Security, ha mostrato anche che alla fine del 2001 c erano 48 reti wireless attive e vulnerabili mentre un anno dopo (dicembre 2002) ve ne erano 148: molte di esse erano segnate con i simboli del warchalking. Figura 3.6: Simbologie del warchalking 3.6 EAP e 802.1x Come risolvere le debolezze del WEP? 29

36 Wireless Security Nell Aprile del 2002 l IEEE ha ratificato lo standard 802.1x, nato inizialmente per reti cablate ma facilmente applicabile nel caso delle WLAN, che agisce a livello datalink (sottostrato MAC) della pila ISO/OSI. Quando una richiesta di accesso è inviata all AP, quest ultimo la inoltra ad un server (nella rete cablata) tipicamente RADIUS (Remote Access Dial-In User Service) o Kerberos. Il WT comunica solo con l access point e quest ultimo, in modo wired, con il server. Lo standard 802.1x non definisce un metodo preciso ma un architectural framework nel quale possono essere usate varie metodologie, per questo una delle sue caratteristiche fondamentali è la versatilità. Le tre entità in gioco sono il supplicant, l authenticator e il server. Figura 3.7: Le entità nel protocollo 802.1x AAA: RADIUS La grande maggioranza delle implementazioni del 802.1x si appoggiano per l autenticazione ad un server AAA (Authentication Authoritation Accounting). Le funzioni offerte dall AAA devono permettere di rispondere alle seguenti domande nel dialogo tra server e client: chi sei? quali servizi sono autorizzato a fornirti? 30

37 3.6 EAP e 802.1x quali risorse puoi usare e per quanto tempo? Il RADIUS è stato definito dalla Merit Network e dalla Livingston ed è stato standardizzato dall IETF (Internet Engineering Task Force) in numerosi RFC (Request for Comments). Il suo scopo principale è l autenticazione in remoto; storicamente è stato usato nei provider per fornire l accesso alla rete Internet. Non implementa in sè particolari meccanismi di sicurezza. L evoluzione del RADIUS, attualmente in fase di standardizzazione sempre presso l IETF, si chiama Diameter Extensible Authentication Protocol L EAP è un insieme di direttive che permette agli sviluppatori di creare il proprio metodo per trasferire le credenziali di autenticazione, ossia un insieme di specifiche d implementazione dello standard 802.1x. Provvede solo all autenticazione degli utenti e non definisce ad esempio la cifratura dei dati. Ci sono 5 metodi principalmente usati: EAP-MD5, EAP-Cisco (conosciuto come LEAP, Lighweigth EAP), PEAP (Protected EAP), EAP-TLS e EAP-TTLS. Lo standard è nato originariamente per le reti cablate e la definizione riguardava esclusivamente connessioni di tipo PPP. Successive modifiche da parte dell IEEE hanno definito le specifiche EAPOL (EAP over LAN), ossia metodi che permettono di incapsulare i messaggi EAP e di inviarli su reti Ethernet o segmenti di reti LAN wireless. L EAP è sviluppato attraverso un paradigma di comunicazione challengeresponse, quindi un modello sincrono in cui sono definiti quattro tipi di messaggi: EAP Request per le richieste di autenticazione o di credenziali, EAP Response come risposta alle request, EAP Success per comunicare il successo dell operazione e EAP Failure per la notifica di un errore. Un tipico esempio di connessione è il seguente: 1. il supplicant richiede la connessione all AP (authenticator) inviando un pacchetto di challenge 2. l AP richiede l identità dell utente e la inoltra al server 3. ll server richiede al client la dimostrazione dell identità 31

38 Wireless Security 4. ll client risponde inviando le credenziali al server tramire l AP 5. in caso di correttezza delle credenziali fornite, il client ha accesso alla WLAN In questo processo l AP diventa parte integrante dell infrastruttura, cioè vengono impostate in esso le policy necessarie all attuazione dell 802.1x: l AP rappresenta in qualche modo l entità più debole, più facilmente attaccabile. Ogni AP ha un software di impostazione tipicamente accessibile tramite browser: l unico livello di sicurezza è dato dalla password di accesso. Attacchi all AP sono quindi relativamente semplici ma altrettanto pericolosi poichè permettono di causare interruzioni di funzionamento oppure intrusioni (anche nelle rete cablata) da parte di malintenzionati. EAP-MD5 E il primo modello della serie EAP. Supporta esclusivamente l autenticazione one-way (solo del client) tramite login-password, non supporta il key management ossia la distribuzione delle chiavi WEP. Il nome deriva dal fatto che viene effettuato l hashing della password con il protocollo MD5 prima dell invio sulla rete; non è consigliato l uso sulle WLAN ma solo sulle reti cablate. LEAP E un protocollo proprietario della Cisco ed è usato prevalentemente nel loro hardware; cifra i dati usando chiavi WEP generate dinamicamente e supporta la mutua autenticazione. La maggior parte delle implementazioni LEAP compatibili usa però un autenticazione a livello di login-password. Recenti studi hanno evidenziato un estrema vulnerabilità proprio nel caso di preshared password. Sono noti evidenti problemi di interoperabilità con hardware e software non targato Cisco. EAP-TLS (Transport Layer Security) Essenzialmente è lo standard-de-facto in sistemi Microsoft Windows XP e Linux; è basato sui certificati e provvede alla mutua autenticazione. L au- 32

39 3.6 EAP e 802.1x tenticazione EAP-TLS avviene automaticamente, senza alcun intervento da parte dell utente, usa concetti di PKI: il client e il server devono preventivamente avere un certificato valido e vi deve essere un certificate-authorityserver; al termine della fase di riconoscimento avviene la creazione di un tunnel TLS. Il server provvede alla generazione delle chiavi per la sessione wireless in modo dinamico. Ha il pregio di permettere una veloce riconnessione (via rigenerazione della sessione del tunnel SSL/TLS). Figura 3.8: EAP-TLS secondo Cisco EAP-TTLS (Tunnelled Transport Layer Security) E stato sviluppato dalla Funk Software e dalla Certicom Corp. E un estensione dell EAP-TLS e non necessita della configurazione del certificato dal lato client; si può appoggiare ad un infrastruttura esistente (ad es. su Active Directory) e per questo sta riscuotendo notevole successo. Per- 33

40 Wireless Security mette di eliminare l unico punto critico nella struttura dell EAP-TLS ovvero la distribuzione dei certificati del client. PEAP E anch esso un evoluzione dell EAP-TLS ed è stato sviluppato da Cisco, Microsoft e RSA Security Group. E molto simile all EAP-TTLS e per questo è in diretta competizione. Anche il PEAP usa solo il certificato digitale del server per creare un tunnell SSL/TLS cifrato su cui scambiare successivamente le credenziali di autorizzazione del client Pregi e difetti 802.1x L EAP provvede a tre significativi benefici oltre alla versatilità: gli schemi con la mutua autenticazione eliminano l attacco Man in the Middle; cioè l AP deve autenticare lo user e lo user deve autenticare l AP implementa un sistema di amministrazione e distribuzione di chiavi centralizzato permette di definire in modo semplice policy centralizzate per la classificazione degli utenti wireless L EAP-MD5 non assicura protezione adatta alle rete wireless, è invece più indicato per le reti wired; il LEAP ha come vantaggio la semplicità, ma recenti studi hanno dimostrato la sua vulnerabilità. L EAP-TLS introduce elevati costi di amministrazione a causa della costituzione della Certification Authority (CA) e della Certificate Revocation List (CRL) e introduce una certa complessità nei protocolli di comunicazione poiché l autenticazione avviene a più stadi. Se i certificati vengono memorizzati su qualche supporto (hard disk, smart card) e quindi ciò che si autentica non è l utente ma piuttosto il device. I problemi dell 802.1x sono prevalentemente due: interoperabilità (in quanto molte volte hardware differenti non riescono a comunicare) e sicurezza in alcune implementazioni. 34

41 3.7 Virtual LAN 3.7 Virtual LAN Il concetto di VLAN (Virtual Local Area Network) è stato introdotto per porre rimedio agli svantaggi delle reti di grosse dimensioni: elevato traffico multicast (invio ad un gruppo particolare di utenti) e broadcast (invio a tutta la rete) routing (instradamento) tra differenti sottoreti sicurezza diverse competenze all interno di grandi organizzazioni Una VLAN risolve queste problematiche permettendo la definizione di più sottoreti logiche separate all interno di un unica infrastruttura fisica, si vanno così a creare differenti LAN virtuali in cui ogni client può parlare con un altro client all interno della sottorete; un client può appartenere a più sottoreti. L uso delle VLAN produce dei vantaggi anche nelle reti medio/piccole: prestazioni: traffico di tipo broadcast viene notevolmente ridotto in quanto non è più esteso a tutta la rete ma solo agli stessi utenti di un VLAN sicurezza: confinano il traffico interno di ogni VLAN alle sole stazioni appartenenti ad essa; è possibile inoltre creare diverse policy, diversi servizi e privilegi per ciascuna sottorete fornendo quindi vari tipi di sicurezza Lo standard delle VLAN è 802.1q: gli switch a livello 2 (datalink) definiscono differenti domini di broadcast mentre la connessione tra diverse VLAN avviene usando dei router (livello 3). Questo protocollo è purtroppo arrivato in ritardo rispetto alle soluzioni dei costruttori, quindi molte volte per sfruttare appieno le potenzialità di questa tecnologia è nessario ricorrere a soluzioni proprietarie. Si può pensare a delle applicazioni anche nel caso delle reti wireless, ad esempio differenti scenari di autenticazione: in un ambiente universitario i docenti potrebbero sftruttare il protocollo EAP-TTLS mentre gli studenti il MAC address filtering. Fondamentale è l uso differenziato delle risorse: ai 35

42 Wireless Security docenti sarebbe possibile accedere in modo esclusivo ad alcune di esse (all interno della stessa VLAN) mentre agli utenti ne sarebbero riservate altre. Le VLAN possono essere usate anche per fornire accesso wireless in area pubbliche senza compromettere la sicurezza totale della rete: negli Internet hotspot infatti il sistema deve essere necessariamente open in modo tale da assicurare libero (o facile) accesso; sarebbe impensabile usare ad esempio un autenticazione di tipo EAP-TLS e quindi fornire ad ogni client un certificato valido. Il concetto di VLAN è molto simile al concetto di sottorete di un AP quindi di sottorete con un determinato SSID, è questa infatti una delle applicazioni più immediate: associare ad ogni AP una rete virtuale, gestendo ad un primo livello diverse policy di sicurezza direttamente sull access point. Il problema più grande è che 802.1q non è supportato universalmente e non è implementato direttamente sugli AP, quindi tutta la gestione deve essere fatta all interno della rete cablata; esistono alcune valide soluzioni proprietarie come quelle offerte dalla Cisco e dalla Compex. 3.8 Attacco: metodologie I motivi principali di attacco a reti WLAN sono essenzialmente due: uso risorse, furto informazioni. La prima motivazione consiste nell usufruire della connessione alla rete: questo accadeva soprattutto all inizio quando Internet non era così alla portata di tutti (non serve ritornare indietro di molti anni). La seconda invece è un argomento molto più delicato ed è il motivo principale per cui c è ancora parecchia diffidenza nei confronti delle reti wireless. Le metodologie di attacco principali sono: Sniffer: software che monitora il traffico di rete; lo scopo dell attacker è catturare informazioni che transitano nella rete per rubarle ed eventualmente autenticarsi in modo illegittimo; gli sniffer agiscono a livello fisico permettendo alle schede di rete di lavorare in maniera promiscua. I più diffusi sono NetStrumbler, AirPort, AiroPeek: permettono tra l altro di crackare le chiavi WEP in automatico. Spoofing: un intrusore impersona un dispositivo legittimo rubandone 36

43 3.9 Difesa: metodologie le credenziali. Ad esempio può sniffare il traffico e catturare un MAC valido che poi userà con l AP per autenticarsi. Può riguardare la falsificazione di un IP permettendo all attacker di reindirizzare il traffico verso di lui (i nodi di rete non notano irregolarità), oppure la falsificazione dei dati. Denial of Service (DoS): attacco a risorse di rete in modo da limitarne o bloccarne il funzionamento. L attacco, di questo tipo, più diffuso è a scapito dell AP ad esempio interferendone il segnale radio. Session Hijacking: viene usata una sessione già attiva di un altro client autorizzato, è una tecnica molto raffinata e difficile da attuare Jamming: viene introdotto un segnale radio che produce interferenza, ad esempio AP non autorizzati che permettono l ingresso a client esterni e AP clone con segnali molto forti (Evil Twin). Man in the Middle (MITM): probabilmente l attacco più pericoloso e più usato, consiste nel dirottare il traffico tra due client verso un terzo host. L attacker impersona uno dei due interlocutori o meglio si presenta a ciascuno di loro come fosse l altro. La classificazione introdotta non è così rigida come sembra, molte volte gli attacchi elencati avvengono assieme o addirittura uno è una semplice conseguenza dell altro. 3.9 Difesa: metodologie Alla luce di quanto visto nei paragrafi precedenti possiamo definire dieci regole fondamentali per difendere le reti WLAN. Le prime cinque regole dovrebbero necessariamente essere applicate in tutti i contesti, la 6 e la 7 assieme forniscono un livello di sicurezza medio-basso quindi adatto ad un uso ad esempio domestico; la 8 e la 9 garantiscono flessibilità e possibilità di varie configurazioni. La regola numero 10 sarà illustrata nel prossimo capitolo. 37

44 Wireless Security 1. Disabilitare il broadcast (invio automatico da parte dell AP) dell SSID e scegliere SSID non banali 2. Disabilitare DHCP provvedendo alla distribuzione manuale degli IP e delle informazioni di rete 3. Analizzare periodicamente la rete tramite strumenti di auditing in modo tale da rilevare traffico indesiderato 4. Curare la disposizione degli AP in modo che il segnale radio non si propaghi all esterno dell area d interesse ma soprattuto non si propaghi all esterno dell edificio dove è installata la WLAN 5. Cambiare la password dell utente amministratore dell AP 6. Abilitare la crittografia WEP a 128 bit. Non utilizzare chiavi banali, introdurre la rotazione automatica delle chiavi (se permesso dall hardware) e cambiarle frequentemente 7. Usare il MAC address filtering 8. Usare l 802.1x nelle implementazioni a chiave pubblica (TLS, PEAP o TTLS) e un architettura centralizzata con un server AAA come Radius o Kerberos 9. Cambiare il range degli indirizzi della WLAN ed eventualmente introdurre le VLAN 10. Usare una Virtual Private Network con il protocollo IPsec Tutte le tecniche analizzate (anche quelle dell i esposto nella sezione 3.10) agiscono anche a livello dell AP, che quindi non è un semplice repeater ma è parte integrante dei modelli di autenticazione. Una regola fondamentale dice che la sicurezza di un infrastruttura è uguale alla sicurezza del suo anello debole, che in questo caso è proprio l AP. E importante renderlo difficilmente raggiungibile curandone la posizione fisica. Paradossalmente può 38

45 3.10 Il futuro: i essere meglio non prevedere alcun tipo di meccanismo sull AP impostandolo come se fosse un dispositivo non intelligente e gestendo tutta la sicurezza su un server esterno, ma ciò non è possibile ricorrendo all 802.1x. L EAP-MD5 è vulnerabile all offline attack dictionary, in quanto usa la coppia login-password, e inoltre suscettibile ad attacchi MITM, session hijacking perché autentica solo il client e non il server. L EAP-LEAP è vulnerabile solo all attacco del dizionario. Le tecniche che introducono un tunnel SSL/TLS consentono di contrastare ad attacchi MITM, Session Hijacking e nella maggior parte dei casi a sniffing dello username e della password; l EAP-TTLS però recentemente è stato dimostrato essere anch esso suscettibile ad attacchi di tipo MITM. Nella tabella 3.1 sono riassunte le caratteristiche dei vari metodi EAP. Ovviamente se si vuole un buon sistema di protezione è importante delineare esattamente l infrastruttura a disposizione: evidenziare quello che si vuole proteggere e quindi quello su cui si vuole porre maggiore attenzione. Lo scenario all interno di un centro finanziario è sicuramente diverso rispetto ad un ambiente ospedaliero Il futuro: i Il nuovo standard sulla sicurezza per le reti wireless si chiama i. La correzione degli errori e l introduzione di nuove tecnologie ha richiesto enormi tempi di sviluppo: doveva uscire nel terzo trimestre del 2003 ma attualmente è ancora marcato come bozza e voci di corridoio dicono che non sarà pronto prima della fine del terzo trimestre del In attesa del i la Wireless Fidelity Alliance (Wi-Fi Alliance) ha introdotto un sottoinsieme di specifiche che dovrà essere integrato in tutti i prodotti certificati Wi-Fi; l aggiornamento è solo software e quindi è disponibile anche come download di pacchetti. L i è l integrazione del WPA con AES e dell EAP. Il salto di qualità è dato dall introduzione del Temporal Key Integrity Protocol (TKIP) e dell EAP. Il TKIP provvede alla crittografia dei dati generando in maniera dinamica le chiavi; ad esempio se si imposta un lifetime 39

46 Wireless Security EAP- LEAP EAP- EAP- PEAP MD5 TLS TTLS Mutua No Si Si Si Si autenticazione RADIUS si Si Si Si Si Autentica Si Si No Si Si utenti Certificato No No Si Si Si server Certificato No No Si No No client Tunnelling No No Si Si Si Distruzioni No Si Si Si Si chiavi Riconnessione No No No Si Si veloce Efficente Si Si No No No Costi Bassi Medi Alti Alti Alti manutenzione Attacco NI NI I I I dizionario MITM NI NI I I I Session NI I I I I Hijacking Sniffer NI I I I I Tabella 3.1: Metodi EAP; I=Immune, NI=Non Immune 40

47 3.10 Il futuro: i della chiave di un minuto, alla fine di questo minuto verrà scambiata tra il client e l AP una nuova chiave di cifratura in modo naturalmente criptato con la chiave precedente. Nel TKIP è integrato un nuovo algoritmo di integrità chiamato Micheal (MIC) che permette di risolvere i difetti del CRC a 32 bit. Il WPA è quindi sicuro? La risposta, almeno per ora, è no. Dallo standard 802.1i si può leggere: A passphrase typically has about 2.5 bits of security per character, so the passphrase of n bytes equates to a key with about 2.5n + 12 bits of security. Hence, it provides a relatively low level of security, with keys generated from short passwords subject to dictionary attack. Use of the key hash is recommended only where it is impractical to make use of a stronger form of user authentication. A key generated from a passphrase of less than about 20 characters is unlikely to deter attacks. La sicurezza è assicurata solo se si usa una passphrase di 20 caratteri, ma quale utente è disposto a farlo? Considerazioni più semplici si possono fare riferendosi per esempio al dinamismo delle chiavi nel TKIP: tale tecnica non è sufficiente se si continua ad usare un algoritmo modesto come il WEP, infatti anche l intercettamento di pochi pacchetti potrebbe permettere di perforare l intero sistema. Il WPA è infine suscettibile da attacchi Denial of Service: infatti, se l AP riceve due pacchetti che falliscono la verifica del MIC entro 60 secondi, allora il sistema pensa di essere sotto attacco e disconnette tutti i client per altri 60 secondi. Come detto se aggiungiamo al WPA l EAP e usiamo come algoritmo di cifratura l AES otteniamo l i. 41

48

49 Capitolo 4 Secondo noi il protocollo IPSec è troppo complesso per essere sicuro ma è migliore di qualsiasi altro protocollo oggi esistente FERGUSON E SCHNEIDER Virtual Private Network Alla luce di quanto visto nei capitoli precedenti ci si accorge di come sia difficile rendere veramente sicura una rete wireless. WEP è assolutamente inadeguato, bisogna quindi rivolgere l attenzione verso altri algoritmi di cifratura ma soprattutto verso modelli di sicurezza più robusti. L autenticazione con l 802.1x non è ancora allo stato ottimale, quindi: come comportarsi in attesa del ritardatario i? Esiste una soluzione diventata lo standard nella comunicazione commerciale sulle reti wired: la Virtual Private Network. Un idea innovativa, introdotta in primis dalle aziende e non da università o organismi di standardizzazione, potrebbe essere quella di applicarla alle WLAN. 4.1 Descrizione Rendere sicura la connessione tra client all interno di una LAN è un compito relativamente semplice ed economico; se i due terminali sono vicini e appartengono alla stessa rete è possibile ricorrere a proxy (per esaminare il traffico in uscita), a firewall (per limitare il traffico in ingresso), a VLAN (Virtual LAN, per formare sottoreti) e così via. Ma se i due interlocutori sono fisicamente molto distanti come rendere sicura la connessione? Come far in modo che l utente seduto nello studio a casa sua possa usare le risorse, in maniera trasparente e sicura, della LAN in ufficio? Installare una linea dedicata sarebbe nella maggior parte delle situazioni 43

50 Virtual Private Network impossibile sia per motivi tecnici che per motivi economici. Servirebbe una rete sempre accessibile da ogni parte del mondo, in ogni circostanza, in ogni momento. La soluzione naturalmente è la rete globale Internet. Il costo di cablaggio diventerebbe nullo ma purtroppo anche la sicurezza. Le comunicazioni sicure sulla rete Internet permettono una rapido incremento del teleworking e dell e-learning, con tutti i loro aspetti positivi. Un recente studio dell Osservatorio ANEE 2003 ha mostrato che circa il 72% degli atenei italiani è impegnato in iniziative di formazione online mentre negli USA (fonte MATE) le previsioni parlano di un investimento nell e-learning di 8 miliardi di dollari e di 14 entro il Oltre 48 milioni di persone lavorano lontano dall ufficio, secondo la ITAC: 24.1% lavorano per la strada, 21.7% a casa, 7.5% sui centri di telelavoro, 4.2% su uffici distaccati. Come assicurare allora la riservatezza dei dati che transitano su Internet? Ricorrendo ad una Virtual Private Network (VPN). La VPN permette alle organizzazioni di estendere le proprie reti attraverso Internet assicurando: autenticazione: identità dell utente remoto confidenzialità: trasmissione privata e sicura integrità: controllo che i dati trasmessi siano inalterati Per il Virtual Private Netwrok Consortium (VPNC) la definizione esatta è: A virtual private network (VPN) is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures La VPN è un infrastruttura end-to-end che garantisce cioè la sicurezza solo tra le due entità ai capi della connessione. Ci sono vari tipi di connessioni possibili: Client to LAN: usato ad esempio dai lavoratori dinamici o dai telelavoratori, viene creato un tunnel diverso per ogni utente 44

51 4.2 Modalità Figura 4.1: Un esempio di VPN LAN to LAN: il tunnel è creato tra i due gateway delle LAN: è assicurato il traffico sicuro su Internet ma non all interno delle LAN perché rimane scoperta la tratta gateway-client Intranet: abilita gli uffici remoti e gli utenti l accesso sicuro alle applicazioni TCP/IP che girano sulla Intranet della propria azienda o organizzazione Extranet: garantiscono accesso sicuro alla Extranet per fornitori, rivenditori, partner ecc. 4.2 Modalità Esistono due diverse tecnologie implementative: Modalità Tunnel: viene codificato tutto il traffico tra gli end-point; l utente finale non ha percezione della crittografia applicata. I pacchetti scambiati vengono incapsulati in altri pacchetti. E il modello più usato e più sicuro, però introduce una maggiore lentezza nella rete. Questa 45

52 Virtual Private Network modalità è realizzata a livello hardware tipicamente dai router o dai firewall. Modalità Trasport: avviene a livello software. Internet lascia in chiaro solo le informazioni di instradamento IP (headers e trailes dei pacchetti). 4.3 Protocolli Vi sono varie tipologie di tunnelling, le tre più usate sono: IPsec (Internet Protocol Security): è nato nel 1999 ma è in continua evoluzione, lavora a livello 3 del modello ISO/OSI Pptp (Point-to-point tunneling Protocol): essendo il più vecchio è quello più supportato da molti tipi di rete; non usa PKI per l autenticazione ma la coppia login-password. E in grado di assegnare anche gli indirizzi IP. L installazione e la gestione sono piuttosto semplici. L2tp (Layer 2 Tunneling Protocol): è stato per molto tempo il più diffuso; effettua l incapsulamento dei frame PPP (Point-to-Point Protocol) cifrati in frame IP. Usa la porta UDP 1701 ed è usato di solito come connessione client-gateway o gateway-gateway; è posto a livello 2 (datalink) nel modello ISO/OSI Esistono anche versioni miste come L2TP/IPSEC. 4.4 IPSec La tecnologia Internet Protocol Security (IPSec) è stata sviluppata dalla Internet Engineering Task Force (IETF). Non è un semplice protocollo ma un insieme di protocolli: Encapsulating Security Payload (ESP, garantisce riservatezza, autenticità e integrità), Authentication Header (AH, garantisce integrità e autenticità), Internet Key Exchange (IKE, gestisce le chiavi di connessione). IPsec è specificato nel RFC Può operare sia in modalità trasporto che tunnel. Nella modalità trasporto non viene modificato l header IP originale ma viene aggiunto un header 46

53 4.4 IPSec IPsec (figura 4.2); l impostazione tunnel è più complessa dal punto di vista computazionale poiché cifra tutto il pacchetto (header compreso), aggiunge lo stesso header IPsec usato nella modalità trasporto e infine crea un nuovo header IP per l instradamento. Figura 4.2: Modalità trasporto Figura 4.3: Modalità tunnel La creazione della VPN si divide in due fasi: prima avviene la creazione del tunnel con l IKE e poi la comunicazione vera e propria. L AH e l ESP quindi non si occupano dello scambio delle chiavi e presumono che i due interlocutori si siano già accordati sul modello da usare e che abbiano già formato una Security Association (SA). IPSec può usare, a seconda dell implementazione, gli algoritmi di cifratura DES, 3DES (triplo DES), AES, BlowFish, 47

54 Virtual Private Network TwoFish, gli algoritmi di hashing MD5 (Message Digest 5), SHA (Secure Hashing) e HMAC (Hashing for Message Authentication) e l autenticazione mediante RADIUS, SecureID e certificati digitali. Lavora a livello 3 del modello ISO/OSI: Figura 4.4: Posizionamento protocolli nel modello ISO/OSI AH E stato definito nella RFC Sia l AH che l ESP possono operare in modalità tunnel e trasporto. L AH protegge il contenuto mediante hash del payload IP cioè dell header dei protocolli superiori, dell exeternal header e dei dati. Figura 4.5: Authentication Header 48

55 4.4 IPSec L algoritmo AH è più semplice dell ESP e quindi garantisce meno sicurezza ma introduce un minore overhead permettendo maggiore performance ESP In principio prevedeva solo la confidenzialità ma successivamente ha integrato meccanismi di autenticità e integrità. Svolge quindi tutte le funzioni praticate dall AH: generalmente non si usano mai assieme; vi sono proposte che prevedono di togliere AH dallo standard in quanto ovviamente superfluo. E stato definito nella RFC L ESP opera aggiungendo un header e un trailer al datagram, cifra tutto il datagram e parte del suo trailer mentre autentica anche il suo header. Questo significa che un algoritmo di hash è usato per produrre una rappresentazione a lunghezza fissa dei dati autenticati alla fine del pacchetto Figura 4.6: Encapsulating Security Payload IKE E usato per l instaurazione automatica della SA. L algoritmo è molto complesso e scalabile. Alcuni detrattori insistono sul fatto che sia appunto troppo complesso e contorto. Il protocollo IKE si articola in due fasi. Nella prima si instaura Internet Security Association Key Management Security Association (ISAKMP SA), vale a dire una connessione sicura per lo scambio dei messaggi IKE, mentre nella seconda l ISAKMP SA viene utilizzata per la negoziazione e l instaurazione delle IPsec SA. La prima fase può essere realizzata in due modi: main 49

56 Virtual Private Network mode e aggressive mode, mentre nella seconda fase si usa il quick mode. Il metodo aggressive è molto più veloce ma è suscettibile ad attachi MITM. Il lavoro principale è svolto dall algoritmo Diffie-Hellman (DH) che permette agli endpoint di stabilire un segreto comune, però non provvede all autenticazione che invece viene svolta usando uno di questi metodi: Pre-Shared keys (PSK): gli utenti si scambiano una chiave in maniera non automatica (via telefono, fax, mail ecc.) e poi la inseriscono nel client durante la configurazione della VPN PKI: viene usato il Digital Signature Standard (DSS) o il Rivest-Shamir- Adleman (RSA) Nelle SA si specificano informazioni quali: la tipologia dell autenticazione, gli algoritmi crittografici usati, le chiavi di sessione condivise, la lifetime delle chiavi e della SA stessa. La IPsec SA è unidirezionale quindi ne devono essere create due distinte, una per ogni direzione. Ogni SA è identificata da tre parametri: tipo di protocollo (AH o ESP), indirizzo di destinazione e il Security Parameter Index (SPI) che è un numero a 32 bit Traffico Quando viene instaurata una connessione IPsec tutto il traffico viene prima processato dal protocollo. Ogni nodo IPSec gestisce due registri per ogni interfaccia di rete: SAD (Security Association Database) e SPD (Security Policy Database). Il SAD contiene l elenco di tutte le SA attive mentre il SPD contiene le regole (policy) per l elaborazione dei pacchetti. In caso di traffico in uscita il pacchetto sarà associato ad una SA esistente oppure verrà richiesta l instaurazione di una nuova; qualora il traffico fosse in ingresso verrà controllato l header IP per verificare la presenza di valori ESP o AH. Ciascun client può sostenere più SA, quindi più tunnel IPsec, con macchine differenti; l unico limite è dato dalla potenza di calcolo del processore. Il protocollo IPsec può implementare vari tipi di VPN: i due casi più interessanti sono il collegamento di più sottoreti tramite il tunnel tra i gateway delle stesse e la modalità roadwarrior. Quest ultimo schema prevede che 50

57 4.5 IPv6 uno dei due interlocutori sia un semplice host con indirizzo IP, eventualmente dinamico; come infrastruttura si avvicina al modello client-server. 4.5 IPv6 La versione 4 del protocollo IP (IPv4) è inadeguata agli usi odierni in quanto soffre di alcuni problemi: primo tra tutti usa uno spazio di indirizzamento a soli 32 bit cioè consente combinazioni. Agli attuali tassi di crescita di Internet è calcolato che tali combinazioni verranno esaurite entro il Inoltre la nascita di nuove applicazioni (ad esempio real time) richiede un nuovo protocollo ed altre applicazioni maggiore sicurezza. L IETF ha deciso di assegnare alla nuova versione di IP il numero 6, il numero 5 è saltato a causa di una serie di errori e malintesi. L IPv6 (Internet Protocol version 6) usa uno spazio di indirizzamento di 128; mentre gli indirizzi dell IPv4 sono scritti normalmente come quattro numeri decimali separati da punti, gli indirizzi IPv6 sono costituiti da otto numeri esadecimali a quattro cifre, separati da due punti (gli zeri iniziali possono essere omessi). IPv4 IPv fe80:0000:0000:0000:02a0:24ff:fe77:4997 Tabella 4.1: Protocolli IP IPv6 supporta più livelli gerarchici di indirizzamento ed usa un header semplificato rimuovendo o rendendo opzionali alcuni campi dell IPv4 in modo tale da permettere maggiori prestazioni e assicurando un maggiore flessibilità grazie all introduzione di nuove estensioni. IPv6 introduce dei meccanismi di individuazione di particolari flussi dati per i quali è previsto un trattamento speciale e dei meccanismi di ottimizzazione di controllo del flusso. La novità maggiore è la capacità di autenticazione e privacy tramite il supporto nativo per la suite di protocolli IPsec. Tale caratteristica è ancora in fase di definizione. 51

58 Virtual Private Network 4.6 IPSec e le reti wireless La VPN è applicabile abbastanza semplicemente alle reti wireless. Paradossalmente non viene impostata alcuna policy di sicurezza sull AP (accesso open e WEP disabilitato) e il tutto viene gestito dai due end-point. Proprio per questo l AP è non intelligente ; in questo modo si elimina già a priori la maggior parte degli attacchi hacker fatti sull AP. La soluzione VPN offre una scalabilità simile alla soluzione 802.1x e certamente maggiore della coppia WEP e MAC filtering; inoltre è gestita via software e quindi utilizzabile con tutte le schede di rete a differenza dell 802.1x che ha bisogno di hardware apposito e certificato. Un curioso paragone fornito dalla Intermec Technologies Corp mette in corrispondenza le reti wireless con le comuni abitazioni dove viviamo; la sicurezza delle reti wireless può essere suddivisa in 3 categorie: Basic, Active e Hardened. Figura 4.7: Il punto di vista della Internec Technologies Corp Basic security significa rete open oppure protetta dal WEP, quindi è come se la nostra casa avesse la porta aperta o al massimo chiusa solo a chiave: 52

59 4.7 Vantaggi e svantaggi i ladri possono entrare tranquillamente. Active security è l uso dell 802.1x e del WPA (in futuro del i), questa volta a protezione della nostra casa troviamo un Doberman o un Rottweiler che ci avverte se qualcuno sta entrando. Hardened invece significa VPN (FIPS 140 è la loro particolare soluzione), quindi IPsec, ed è come se avessimo il filo spinato attorno e un sistema satellitare. 4.7 Vantaggi e svantaggi Ecco un riassunto di tutti i vantaggi dell uso delle tecnologie VPN: costi ridotti rispetto all uso di linee dedicate a lunga distanza, telefonate su lunga distanza; l unica spesa da prevedere riguarda il software a corredo basso overhead per l amministrazione grazie alla centralizzazione la protezione dal livello network dà la possibilità di fornire un servizio indipendente dal protocollo di livello superiore (IPX, TCP, UDP ecc.) evitando così lo sviluppo di applicazioni ad-hoc è scalabile ad un grande numero di utenti è flessibile perché si può applicare a vari scenari wireless tra cui ad esempio semplici connessioni (dial-up, modem, Digital Subscriber Line) e aree pubbliche di accesso negli aeroporti, alberghi (hotspots) completa trasparenza per l utente è un open stardard molte aziende adottano già le VPN su reti wired: l estensione su rete wireless è piuttosto semplice abilita la centralizzazione delle informazioni critiche ed importanti permette una certa flessibilità nel lavoro in risposta ad una crescita di team o ai bisogni famigliari o semplicemente a condizioni atmosferiche che limitano gli spostamenti 53

60 Virtual Private Network permette agli utenti di essere sempre aggiornati vantaggio dell azienda sui concorrenti creando rapporti vicini tra rivenditori, fornitori e impiegati Gli svantaggi più significativi sono: tutti gli utenti devono usare un software per la creazione della connessione con conseguente aumento dei costi di gestione prestazioni meno elevate nella comunicazione a causa della complessità degli algoritmi usati si devono configurare firewall e proxy per permette di accettare il traffico IPsec, in particolar modo accettare il traffico proveniente dalle porte UDP (per il protocollo IKE) e quello della porta 51 (ESP) L amministrazione di una VPN è stata definita da qualche utente scontento un administrative nightmare, ma più che altro si tratta di un luogo comune indotto dal fatto che la VPN usa una PKI. Tale soluzione è però indispensabile per difendersi dall attacco Man in The Middle. L amministrazione poteva definirsi un incubo per quanto riguarda ad esempio l importazione di certificati in ambienti differenti ma oggi la situazione è sicuramente più agevole infatti l infrastruttura a chiave pubblica è ben integrata in tutti i moderni sistemi operativi. I due attacchi più famosi a discapito di un infrastruttura IPsec sono stati considerati da Vesselin Tzvetkov della Bochum University e rigurdano implementazioni tra gateway; come vedremo tali considerazioni non interessano la nostra infrastruttura. 54

61 E fondamentale autenticare sia il dispositivo che l utente. E indispensabile avere e essere. Capitolo 5 R. V. Infrastruttura: autenticazione del dispositivo La VPN non provvede, se usata da sola, a meccanismi di AAA: per questo abbiamo introdotto un infrastruttura a doppia autenticazione. 5.1 Modello VPN Nel nostro progetto abbiamo sviluppato un infrastruttura a due livelli. Lo scopo rimane quello di permettere lo scambio sicuro di informazioni sensibili su reti wireless, ma per fare questo dobbiamo assicurare che il traffico destinato al server provenga solo da macchine e utenti abilitati. Provvederemo inoltre ad una memorizzazione sicura delle informazioni. Si è scelto di autenticare il dispositivo, quindi l elaboratore connesso, tramite la VPN preferendola ai protocolli della serie 802; nel corso del capitolo motiveremo tale scelta. L autenticazione dell utente avverrà ad un secondo livello e sarà gestita assieme ai servizi tramite i web services. Lo scenario comprende un utente collegato ad un server, il collegamento è diviso in due sezioni: la prima tratta è wireless quindi il client è connesso ad un access point, la seconda wired dove l AP è connesso tipicamente ad un hub di rete. Il percorso AP-server può comprendere sia un collegamento diretto che una connessione a Internet. Il server si appoggerà ad una directory server per l autenticazione. 55

62 Infrastruttura: autenticazione del dispositivo Figura 5.1: Primo livello di autenticazione 5.2 Linux FreeS/WAN FreeS/WAN (S/WAN: Secure Wide Area Network) è un implementazione open source del protocollo IPsec per Linux nata nell Aprile 1999 (vedi appendice B.4). La versione inizialmente utilizzata, nella nostra struttura, è la 2.00 (uscita il 28/04/2003), successivamente abbiamo provveduto all aggiornamento alla versione più stabile 2.04 (uscita il 13/11/2003). FreeS/WAN si compone di due parti: KLIPS (kernel IPsec): modulo del kernel realizza AH e ESP ed è implementato come Pluto: realizza IKE ed è implementato come demone Vi sono inoltre varie patch esterne e script che forniscono interfacce e moduli aggiuntivi. Nella versione base usa come algoritmo di cifratura il 3DES (implementa anche il DES per necessità, ma non è fornito all utente finale) e come algoritmi di hashing l MD5 e il SHA. IKE non supporta l aggressive mode e permette l autenticazione tramite segreto condiviso o mediante chiavi RSA. 56

63 5.3 Implementazione VPN Le due applicazioni supportate sono la VPN classica, che permette a siti diversi di comunicare in maniera sicura usando Internet, e la roadwarrior. Introduce anche il concetto di Opportunistic Encryption (OE) (vedi sezione 5.3.6) ora al vaglio dell IETF per una possibile standardizzazione all interno dell IPsec. FreeS/WAN si compone di un unico pacchetto in formato tar.gz o rpm. L installazione prevede la ricompilazione del kernel per l inserimento del modulo KLIPS, mentre la configurazione si basa su file di testo. Per maggiori informazioni si rimanda all appendice RoadWarrior Tale modalità è uno dei tanti prototipi introdotti dal team di FreeS/WAN e consiste nella connessione IPsec tra un gateway (in seguito con questo termine indicheremo uno dei due endpoint), tipicamente un server, e un client con indirizzo IP dinamico. I problemi da risolvere sono fondamentalmente due: gestire il dinamismo dell IP e la presenza del Network Address Translation (NAT). L implementazione di FreeS/WAN fornisce un ottima soluzione a tali questioni. 5.3 Implementazione VPN FreeS/WAN è nato e sviluppato su reti wired mentre noi lo applicheremo a reti wireless. Nella nostra infrastruttura useremo come algoritmi di cifratura il 3DES, l AES, il BlowFish, il TwoFish e come algoritmi di hashing l MD5, il SHA1, il SHA2 tramite la configurazione della patch di JuanJo Ciarlante. L autenticazione non sarà basata su chiavi RSA, ma su certificati digitali X.509 per garantire l interoperabilità con altri sistemi. Tutte le prove sono state effettuate con un portatile dotato di scheda wireless connesso ad un Access Point collegato ad un server Linux. FreeS/WAN realizza un IPsec di tipo bump in the stack poiché vengono aggiunte delle interfacce di rete virtuali oltre a quelle fisiche. Se ad esempio la scheda di rete è rappresentata con eth0, sarà creata un interfaccia ipsec0 57

64 Infrastruttura: autenticazione del dispositivo e tutte le comunicazioni avverranno usando questo dispositivo. Eventuali tabelle di routing dovranno essere modificate reindirizzando il traffico. La prima cosa da fare per creare la connessione IPsec è la gestione dei certificati. Abbiamo realizzato una Certification Authority (CA) del Laboratorio di Sistemi in Tempo Reale del Department of Information Engineering e una Certification Revocation List (CRL). E stata creata un interfaccia in PHP per la CA dal collega Marco Rizzetto tramite la quale è possibile generare certificati, revocarli e convertirli in vari formati (la homepage della CA è mostrata in figura 5.2) Figura 5.2: Interfaccia CA realizzata dal collega M. Rizzetto Certificato server Il formato del certificato deve essere X.509: esso andrà copiato nella directory di configurazione di FreeS/WAN (tipicamente in /etc/ipsec.d). Verrà inoltre inserito nel file /etc/ipsec.secrets il percorso della chiave privata e la passphrase associata. Sarà importante proteggere adeguatamente le chiavi private che si trovano in /etc/ipsec.d/private assegnando a ciascuna di esse permessi adeguati. 58

65 5.3 Implementazione VPN Una delle caratteristiche sorprendenti dell IPsec (e anche dell implementazione FreeS/WAN) è l interoperabilità: i client quindi possono essere sia Linux, che Microsoft Windows 2000/XP, sistemi della famiglia BSD e sistemi UNIX come AIX dell IBM Certificati client La certificazione per un client Linux è alquanto semplice poiché si ripeterà esattamente la stessa procedura per la creazione del certificato del server. Figura 5.3: Inserimento credenziali di certificazione Si deve porre molta attenzione allo scambio dei certificati, quindi al passaggio dal server al client. Questo dovrà essere preferibilmente effettuato su rete sicura (sopra un tunnel SSL/TLS) o in modo manuale (ad esempio con il floppy). Per l esportazione su client Microsoft si deve usare un formato differente: il PKCS12; l operazione è comodamente disponibile via interfaccia web. Il 59

66 Infrastruttura: autenticazione del dispositivo formato PKCS12 è uno standard binario per la memorizzazione della chiave pubblica e privata usato ad esempio come default per l importazione e l esportazione nei browser Microsoft Explorer e Mozilla. Oltre alla passphrase (necessaria per leggere la chiave privata) introduce una password di esportazione. L importazione del certificato in sistemi Microsoft è leggermente più complessa che nel caso di client Linux (si rimanda alla Appendice A.7). Microsoft Windows XP richiede per l instaurazione di una connessione IPsec i Support Tools e il Service Pack 1 mentre Windows 2000 il Resource Kit e almeno il Service Pack 2. Listato 5.1: Certificato del client 1 Certificate: 2 Data: 3 Version: 3 (0x2) 4 Serial Number: 2 (0x2) 5 Signature Algorithm: md5withrsaencryption 6 Issuer: C=it, ST=pd, L=pd, O=unipd, CN=wirmo 7 Validity 8 Not Before: Oct 10 13:44: GMT 9 Not After : Oct 7 13:44: GMT 10 Subject: C=it, ST=pd, L=pd, O=unipd, CN=nadia 11 Subject Public Key Info: 12 Public Key Algorithm: rsaencryption 13 RSA Public Key: (2048 bit) 14 Modulus (2048 bit): 15 00:b0:80:1e:c1:21:c3:60:45:54:a6:42:0c:5d:86: 16 87:87:52:47:20:e8:39:ff:13:18:c4:cc:a5:5a:cf: 17 60:67:2a:a6:e6:06:a8:7b:09:f5:9b:41:88:93:80: 18 9a:e3:93:a0:32:a7:a1:9e:df:69:98:c7:f8:86:ad: 19 2b:74:cd:ba:b7:5b:e3:61:5a:d9:da:67:ae:6b:16: 20 55:46:df:40:f5:b8:54:46:9f:a6:40:3f:8a:29:0b: 21 0c:14:a1:e0:0d:a5:f4:80:f4:22:fd:63:f0:31:b7: 22 5b:fc:fc:84:5e:93:29:8b:a0:7d:03:49:c2:4d:f2: 23 50:94:18:4a:fb:54:a6:ff:cc:a7:19:f8:14:f9:3b: 24 48:45:2c:53:e8:65:b2:87:be:c8:93:24:5c:af:cc: 25 c6:88:b8:eb:df:a0:ac:d2:78:6e:86:04:75:05:1d: 26 bf:52:ef:97:ad:f1:8c:49:30:5f:6e:69:f8:38:58: 27 fc:30:5a:00:19:75:d5:60:b2:1c:fb:85:2b:25:4d: 28 7a:11:fe:84:2a:1c:c5:bc:a9:5f:cf:ed:b7:3c:7d: 29 7c:65:32:ab:f8:df:a5:3e:47:56:54:15:36:55:e0: 30 e0:f7:6d:28:a2:88:68:42:fc:97:1b:74:b2:cc:1e: 31 4a:f9:a6:d0:41:ba:c8:76:ab:39:5a:4c:a1:79:b4: 32 74:c7 33 Exponent: (0x10001) 34 X509v3 extensions: 35 X509v3 Basic Constraints: 36 CA:FALSE 37 Netscape Comment: 38 OpenSSL Generated Certificate 60

67 5.3 Implementazione VPN 39 X509v3 Subject Key Identifier: 40 F8:C6:60:62:4B:FB:23:86:4A:ED:C5:6A:AF:01:27:28:FF :01:12:AD 41 X509v3 Authority Key Identifier: 42 keyid:28:3f:a5:2d:8f:75:b4:e1:be:71:07:c5:24:8d:88:cb: F8:6E:F6:01 43 DirName:/C=it/ST=pd/L=pd/O=unipd/CN=wirmo 44 serial: Signature Algorithm: md5withrsaencryption 47 32:bd:86:f4:ad:be:d3:81:41:98:3b:d4:ba:f8:bf:2c:fc:d0: 48 60:3b:68:5f:9a:e9:26:ba:f1:b8:71:ee:2d:35:8a:78:9d:44: 49 b3:61:82:88:b7:50:96:0f:ae:19:c7:e5:39:35:33:68:81:54: 50 d9:ef:f5:66:02:66:23:34:00:2b:e7:6c:75:f3:d7:de:7e:7e: 51 3b:5e:7d:5e:88:76:01:9d:a9:ca:40:85:2e:7e:7b:d8:0d:f9: 52 a0:c5:81:e9:24:be:47:c4:9e:c6:61:c2:19:3c:61:d8:97:bb: 53 23:15:30:61:0a:7f:fd:fa:c4:b4:1e:8f:c7:d9:56:75:5c:45: 54 19:bb:d6:89:10:09:7d:e1:8c:9b:ad:7f:c5:93:0f:5d:44:80: 55 dd:be:93:3c:c4:f6:72:43:a9:93:27:1e:3f:23:73:6b:67:ea: 56 0d:54:8e:a7:68:66:83:5f:36:d0:24:d3:21:90:52:64:e4:1a: 57 95:46:5c:d6:9a:3a:54:f9:c5:b7:49:ae:aa:89:3c:72:1c:0d: 58 e8:e0:f6:4b:0d:c5:68:3a:55:eb:9f:5f:25:91:0a:52:1d:49: 59 cf:9c:e4:71:ba:12:0f:c1:d8:ac:a7:cf:6e:f7:b1:33:08:a6: 60 fd:9a:bb:a8:db:e5:19:78:36:bd:fe:81:4d:10:7c:3f:42:1e: 61 83:ad:7c: BEGIN CERTIFICATE MIID1jCCAr6gAwIBAgIBAjANBgkqhkiG9w0BAQQFADBHMQswCQYDVQQGEwJpdDEL 64 MAkGA1UECBMCcGQxCzAJBgNVBAcTAnBkMQ4wDAYDVQQKEwV1bmlwZDEOMAwGA1UE 65 AxMFd2lybW8wHhcNMDMxMDEwMTM0NDQ3WhcNMTMxMDA3MTM0NDQ3WjBHMQswCQYD 66 VQQGEwJpdDELMAkGA1UECBMCcGQxCzAJBgNVBAcTAnBkMQ4wDAYDVQQKEwV1bmlw 67 ZDEOMAwGA1UEAxMFbmFkaWEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB 68 AQCwgB7BIcNgRVSmQgxdhoeHUkcg6Dn/ExjEzKVaz2BnKqbmBqh7CfWbQYiTgJrj 69 k6ayp6ge32myx/igrst0zbq3w+nhwtnaz65rflvg30d1ufrgn6zap4opcwwuoean 70 pfsa9cl9y/axt1v8/irekymloh0dscjn8lcuger7vkb/zkcz+bt5o0hflfpozbkh 71 vsitjfyvzmaiuovfokzseg6gbhufhb9s75et8yxjmf9uafg4wpwwwgazddvgshz7 72 hssltxor/oqqhmw8qv/p7bc8fxxlmqv436u+r1zuftzv4od3bsiiighc/jcbdllm 73 Hkr5ptBBush2qzlaTKF5tHTHAgMBAAGjgcwwgckwCQYDVR0TBAIwADAsBglghkgB 74 hvhcaq0ehxydt3blblnttcbhzw5lcmf0zwqgq2vydglmawnhdguwhqydvr0obbye 75 FPjGYGJL+yOGSu3Faq8BJyj/ARKtMG8GA1UdIwRoMGaAFCg/pS2PdbThvnEHxSSN 76 imv4bvybouukstbhmqswcqydvqqgewjpddelmakga1uecbmccgqxczajbgnvbact 77 AnBkMQ4wDAYDVQQKEwV1bmlwZDEOMAwGA1UEAxMFd2lybW+CAQAwDQYJKoZIhvcN 78 AQEEBQADggEBADK9hvStvtOBQZg71Lr4vyz80GA7aF+a6Sa68bhx7i01inidRLNh 79 goi3ujyprhnh5tk1m2ibvnnv9wyczim0acvnbhxz195+fjtefv6idggdqcpahs5+ 80 e9gn+adfgekkvkfenszhwhk8ydixuymvmgekf/36xlqej8fzvnvcrrm71okqcx3h 81 jjutf8wtd11egn2+kzze9njdqzmnhj8jc2tn6g1ujqdozonfntak0ygqumtkgpvg 82 XNaaOlT5xbdJrqqJPHIcDejg9ksNxWg6VeufXyWRClIdSc+c5HG6Eg/B2Kynz stmipv2au6jb5rl4nr3+gu0qfd9chootfii= END CERTIFICATE----- Nel listato 5.1 è riportato il certificato del client generato con OpenSSL; per maggiori informazioni e per una descrizione dettagliata dei campi si rimanda all Appendice A.6. 61

68 Infrastruttura: autenticazione del dispositivo Configurazione server Nelle nostre prove è stato assegnato al server l IP e al client l IP nella sottorete ; nella connessione roadwarrior si è soliti chiamare i due interlocutori right e left. Dopo aver creato ed esportato i certificati di devono configurare le due postazioni; il software FreeS/WAN si appoggia principalmente su un file di testo: ipsec.conf. Il file ipsec.conf del server è riportato nel listato 5.2. Le righe 4-8 servono alla definizione dell interfaccia di comunicazione e al debug. Successivamente ogni sezione si occupa di gestire una particolare connessione. Nella sottosezione %default si impostano i parametri comuni a tutte le connessioni definendo gli algoritmi usati (aes128 bit con sha oppure con md5) e l autenticazione via certificati digitali. Fondamentale è la riga 13 che indica il lifetime di una chiave: al termine di questo periodo (un minuto) viene generata dal server un altra chiave simmetrica e spedita al client. Abbiamo realizzato due tipi di connessioni ipsec: una wired di prova e una wireless sperimentale. La sezione roadwarrior è comune ad entrambi: specifica che in linea di massima è accettata ogni connessione da parte di un qualsiasi client dotato di certificato valido (right=%any) e precisa il certificato del server wirmo.pem (gateway left). Le parte dedicata alla connessione wired specifica solo il range di indirizzi dei client abilitati, in questo caso solo la sottorete x. La connessione wireless è invece realizzata in maniera leggermente diversa. Il contrasto più evidente è il fatto che vengano accettate connessioni da qualsiasi IP; infatti abbiamo impostato leftsubnet= /0. Tale espediente è necessario per bypassare l Access Point. Essendo l AP un gateway (non nel senso di FreeS/WAN ma nel senso classico) si sarebbe dovuto creare il tunnel tra il server e l AP, lasciando così scoperta la parte wireless. Con una leftsubnet così vasta, /0 infatti corrisponde a qualsiasi IP, riusciamo a rendere sicura sia la tratta wireless che quella wired. L unico svantaggio è la necessità di elencare, direttamente nel file di configurazione, tutti i certificati dei client (nel nostro caso nadia.pem). 62

69 5.3 Implementazione VPN 1 version Listato 5.2: File ipsec.conf server WIRMO 3 # configurazione di base 4 config setup 5 interfaces=%defaultroute 6 klipsdebug=none 7 plutodebug=all 8 uniqueids=yes 9 10 # parametri di connessioni 11 conn %default 12 keyingtries=1 13 keylife=1m 14 compress=yes 15 disablearrivalcheck=no 16 authby=rsasig 17 leftrsasigkey=%cert 18 rightrsasigkey=%cert 19 ike=aes128-sha,aes128-md5 20 esp=aes128-sha1,aes128-md # generale roadwarrior 23 conn roadwarrior 24 right=%any 25 left=%defaultroute 26 leftcert=wirmo.pem 27 auto=add 28 pfs=yes # rete wired (cablata) 31 conn roadwarrior-net 32 leftsubnet= /24 33 ike=aes128-sha,aes128-md5 34 esp=aes128-sha1,aes128-md5 35 also=roadwarrior # rete wireless 39 conn roadwarrior-wireless 40 leftsubnet= /0 41 rightcert=nadia.pem 42 ike=aes128-sha,aes128-md5 43 esp=aes128-sha1,aes128-md5 44 also=roadwarrior 63

70 Infrastruttura: autenticazione del dispositivo Configurazione Client La configurazione dei client è la stessa, sia che si tratti di sistemi Microsoft che Linux. Listato 5.3: Configurazione wired client NADIA 1 conn roadwarrior 2 left=%any 3 right= rightca="c=it,s=pd,l=pd,o=unipd,cn=wirmo" 5 network=auto 6 auto=start 7 pfs=yes 8 9 conn roadwarrior-net 10 left=%any 11 right= rightsubnet= /24 13 rightca="c=it,s=pd,l=pd,o=unipd,cn=wirmo" 14 network=auto 15 auto=start 16 pfs=yes Tralasciamo la descrizione della parte wired analizzando solo la parte wireless esposta nel listato 5.4 (le due sono molto simili). Abbiamo indicato nella riga 3 l indirizzo esatto del server, nella riga 5 la CA che ha generato i certificati sia per il client che per il server, nella 6-7 gli algoritmi di cifratura e di hashing. Per usare altri algoritmi come ad esempio il Blow- Fish e il SHA seconda versione basta semplicemente sostituire le righe con esp=blowfish128-sha2,blowfish-md5. Listato 5.4: Configurazione wireless client NADIA 1 conn roadwarrior-wireless 2 left=%any 3 right= rightsubnet= /24 5 rightca="c=it,s=pd,l=pd,o=unipd,cn=wirmo" 6 ike=aes128-sha,aes128-md5 7 esp=aes128-sha1,aes-md5 8 network=auto 9 auto=start 10 pfs=yes 64

71 5.3 Implementazione VPN L avvio del tunnel IPsec su Linux è attuabile con il semplice comando ipsec start, che provvede come detto precedentemente ad attivare il demone PLUTO ed a caricare l interfaccia virtuale ipsec0. In sistemi Microsoft invece si deve avviare il comando ipsec.exe. Figura 5.4: Avvio IPsec Microsoft Windows XP La rete rimane inutilizzabile per circa dieci secondi, tempo nel quale i due gateway instaurano una Security Association. Tale ritardo è stato notevolmente ridotto nell ultima versione del tool Ipsec ma non è stato possibile sperimentarla. Va considerato che il tunnel può essere avviato al bootstrap della macchina in maniera trasparente all utente. Una volta installato IPsec esso viene visto come servizio di Windows e può essere amministrato come tale, quindi avviato/sospeso/arrestato/ripreso quando si desidera; anche le operazioni di debug risultano facilitate Verifica Sniffer Vi sono vari metodi per verificare la creazione del tunnel. Ad esempio è possibile sferrare un qualsiasi attacco a cui pone rimedio la VPN e controllarne l effettibilità. Un altro esempio, decisamente più semplice ma eclatante, è provare ad avviare una sessione FTP (File Transfer Protocol) o TELNET. In questi protocolli l autenticazione tramite login avviene inviando la password 65

72 Infrastruttura: autenticazione del dispositivo Figura 5.5: Ping Figura 5.6: Servizio IPsec 66

73 5.3 Implementazione VPN in chiaro. E possibile catturare queste informazioni ricorrendo a qualsiasi sniffer, come ad esempio Ethereal o Ettercap. Se invece è presente un tunnel IPsec i dati saranno illeggibili in quanto codificati con gli algoritmi scelti. Come è detto l implementazione FreeS/WAN è bump-in-the-stack cioè vi è un interfaccia fisica eth0 e un interfaccia virtuale ipsec0. Figura 5.7: I dati catturati sull interfaccia eth0 Se si catturano i dati su eth0 si vedranno i pacchetti ESP (dopo la sessione IKE), mentre nell interfaccia ipsec0 i dati saranno in chiaro. Nella figura 5.7 e 5.8 sono illustrati due screenshot dello sniffer Ethereal che mostrano tale circostanza Opportunistic Encryption Può capitare che da una macchina non dotata di certificato sia necessario effettuare una connessione sicura al server, pensiamo ad esempio al caso in cui un amministratore di rete debba interrompere momentaneamente o spegnere urgentemente il server ma non voglia correre il rischio che gli vengano rubate le credenziali di autenticazione. Ci viene incontro la Opportunistic Encryp- 67

74 Infrastruttura: autenticazione del dispositivo Figura 5.8: I dati catturati sull interfaccia ipse0 tion (OE) di FreeS/WAN accennata precedentemente. Essa ci permette di instaurare una connessione IPsec, nel caso in cui uno dei due gateway non abbia un certificato usando un server DNS (Domain Name Server). Un server DNS contiene le informazioni sui nodi della rete: tipicamente in esso sono memorizzati record dalla forma (nomeclient,ip). DNS prevede la possibilità di aggiungere a tale record campi di tipo TXT (testo, come ad esempio una descrizione) o KEY (dove memorizzare una chiave). Se noi aggiungiamo il campo KEY, e in esso inseriamo la chiave pubblica del server,possiamo immaginare che il client possa andare a prendersi proprio lì le informazioni per l instaurazione della connessione. Questo tipo di connessione è simile a quella che avviene nei browser quando si usa il protocollo SSL/TLS. Tale modello ricorda inoltre quello usato dal protocollo EAP-TTLS e dal PEAP, l applicazione dell OE IPsec in un contesto wireless potrebbe essere un ottima risposta a tale tecniche, poiché come esse assicura una semplice amministrazione. Un problema fondamentale di tale modello è l autenticità della chiave pub- 68

75 5.4 Prestazioni blica del server: nessuno può assicurarla. Allo stato attuale non esiste soluzione. Il successore del DNS, il DNSSEC (DNS Security), ovvia a questo inconveniente ma è attualmente in fase di definizione. L OE è stata introdotta nella nostra infrastruttura per permettere comunicazioni urgenti o particolari e non come funzionamento normale. 5.4 Prestazioni La creazione del tunnel, come detto precedentemente, introduce un ritardo del tutto trascurabile, soprattutto alla luce del fatto che deve essere eseguita una sola volta. Le differenze principali riguardano invece l overhead introdotto dalla codifica e decodifica dei dati nel protocollo ESP (nelle nostre prove non abbiamo usato l AH). Sono state adottate due tecniche di indagine. La prima introdotta dall ingegnere Davide Cerri nella sua tesi IPsec e TLS a confronto: funzioni, prestazioni ed estensioni prevede il collegamento diretto tra le due postazioni e misura le prestazioni con il software Netperf. Nel nostro caso la tratta può essere divisa in due: la parte wireless comunica a 11 Mbps (802.11b) mentre la parte wired a 100 Mbps; ovviamente viene considerata come velocità massima teorica quella della linea più lenta (quindi 11 Mbps). Sono state effettuate dieci misurazioni con il software Netperf, sia con il protocollo TCP che con il protocollo UDP (per simulare la sessione IKE), usando come algoritmo di cifratura il 3DES (per la compatibilità con i sistemi Microsoft) e il SHA a 256, bit saturando la linea per 100 secondi a misurazione. I risultati sono esposti nella tabella 5.1 mentre nella figura 5.9 sono confrontate le medie. Possiamo vedere come le prestazioni sul protocollo TCP diminuiscano di circa 12% mentre per il protocollo UDP del 3%. L overhead introdotto dall E- SP va quindi ad influire sulla velocità della rete in maniera molto leggera. L unico svantaggio che abbiamo notato è un occupazione del processore a livelli attorno al 15% e tutto ciò potrebbe essere un problema nel caso il server dovesse servire molti client e quindi creare molti tunnel. La differenza di 69

76 Infrastruttura: autenticazione del dispositivo TCP TCP su IPsec UDP UDP su IPsec Tabella 5.1: Prestazione collegamento diretto, i dati vanno intesi come Mbit/s prestazioni tra UDP e TCP è imputabile al fatto che nell UDP non entrano in gioco meccanismi di controllo del flusso. La seconda tecnica consiste nell inviare un file tramite protocollo FTP e misurare il tempo di download. E stato scelto un file di dimensione notevole (100 Mbyte) in modo da ottenere una media attendibile. Durante il traffico normale FTP si è ottenuta una velocità media di 4,1 Mbit/s (con un picco di 4,4 Mbit/s) mentre con il tunnel IPsec 3,6 Mbit/s (con picco di 4 Mbit/s). Tali rallentamenti confermano i risultati precedenti; il leggero calo di prestazioni è dovuto al fatto che non si ha la certezza di intasare la connessione come invece assicura l uso del software Netperf. La connessione wired e la connessione wireless presentano fattori di rallentamento (a causa del tunnel IPsec) simili nel caso di connessione diretta tra due host (senza collisioni). L unica differenza si riscontra in generale nella velocità massima: nelle reti LAN ci si avvicina molto ai 10 o ai 100 Mbit/s (circa 9 o 90 MBit/s) mentre nelle WLAN si ottengono dei picchi attorno al 50% quindi circa 5.5 Mbit/s al posto degli 11 nominali. Ciò potrebbe sembrare strano visto che il CSMA/CA (WLAN) è un evoluzione del CSMA/CD (LAN) ma il rallentamento è dovuto al fenomeno della riflessione dei segnali radio, alla rumorosità del canale e all overhead introdotto dal meccanismo di RTS/CTS 70

77 5.4 Prestazioni Figura 5.9: Media dei risultati 1 # IKE Listato 5.5: Un piccolo firewall per IPsec 2 iptables -I INPUT -p udp --sport dport 500 -j ACCEPT 3 iptables -I OUTPUT -p udp --sport dport 500 -j ACCEPT 4 5 # ESP e AH 6 iptables -I INPUT -p 50 -j ACCEPT 7 iptables -I OUTPUT -p 50 -j ACCEPT 8 iptables -I INPUT -p 51 -j ACCEPT 9 iptables -I OUTPUT -p 51 -j ACCEPT (vedi 2.3.2) Considerazioni funzionali La configurazione del server e della connessione introduce alcune problematiche. L uso dell interfaccia virtuale causa la variazione delle NAT. Inoltre i protocolli IPsec inseriscono delle difficoltà nell interazione con i firewall. ESP e AH operano rispettivamente sulla porta 50 e 51 mentre IKE usa il protocollo UDP sulla porta 500. Bisogna quindi ridefinire alcune regole nel firewall (quelle usate da noi sono riportate nel listato 5.5). 71

78 Infrastruttura: autenticazione del dispositivo E importatante però notare che l uso della VPN nella configurazione roadwarrior assicura il roaming grazie alla possibilità di dinamismo dell IP. Tale funzionalità è di ostacolo nell 802.1x (alcune implementazioni dell EAP non prevedono addirittura l uso del DHCP) poiché l AP entra nelle policy di sicurezza, quindi dovrebbe essere configurato in modo tale da implementare l EAP. 5.5 Difesa IPsec E stato possibile usare il protocollo AES, BlowFish, TwoFish solo con il tunnel tra due macchine Linux; se il client invece è Windows ci si deve accontentare del 3DES, mentre entrambe le configurazioni operano correntemente con il SHA. Le limitazioni sono dovute all impossibilità di reperire patch di sicurezza per il sistema operativo di casa Microsoft. I metodi di packet sniffing vengono efficacemente contrastati come visto nella sezione La modularità di IPsec permette di utilizzare nuovi protocolli e permette di scegliere policy diverse in base ad ogni situazione implementativa. Se si desidera un basso livello di sicurezza, ad esempio in ambito domestico, sarà sufficiente usare l OE con un il 3DES e l MD5, mentre se, come nel nostro caso, si devono scambiare dati sensibili allora si introdurranno certificati a 2048 bit, si userà l AES come cifratura e il SHA come hashing. La gestione delle policy con FreeS/WAN è semplice e immediata. Le tecniche di spoofing in cui l attacker impersona un utente legittimo trovano naturale contrasto nell IPsec, mentre si deve prestare attenzione alle tecniche di attacco DNS spoofing efficaci invece quando si usa l OE. L introduzione della PKI permette di rendere immune l infrastruttura agli attacchi MITM e Session Hajcking. Gli attacchi DoS sono invece possibili in corcondanza con attacchi di tipo Jamming (interferenze sul segnale radio dell AP) permettendo di interrompere la connessione per un breve periodo come nel caso dell EAP. A livello software è impossibile risolvere questo inconveniente: sarebbe necessario intervenire nel livello fisico del modello ISO/OSI ad esempio introducendo delle tecniche di modulazioni particolari; ciò esula però dallo scopo della tesi. La VPN garantisce una sicurezza più estesa rispetto all EAP: infatti copre 72

79 5.5 Difesa IPsec non solo la tratta wireless ma anche quella wired. I detrattori dell IPsec però si lamentano del fatto che il protocollo operi a livello 3 (network) mentre il protocollo 802.1x a livello 2 (datalink), quindi assicurando un altro strato di sicurezza. Nella nostra infrastruttura ciò è irrilevante essendo infatti tutto il traffico TCP/IP. Si ricorda che nè la VPN, nè l i proteggono i client da attacchi di tipo peer-to-peer come ad esempio i virus: quindi rimane fondamentale adottare meccanismi di protezione locali come software antivirus e firewall. Con la VPN quindi i tentativi di furto delle credenziali e dei dati trasmessi trovano un ottima soluzione soprattutto alla luce del fatto che con l IPv6 l IPsec diventerà uno standard universalmente adottato. L unica attenzione da porre, come illustrato precedentemente, riguarda lo scambio dei certificati del client che deve avvenire in modo affidabile. Nei prossimi capitoli introdurremo il concetto di autenticazione dell utente e implementeremo i servizi ad esso disponibili. 73

80

81 Capitolo 6 The XMLbased protocol is language and platform neutral, means that information sharing relationships can be initiated among disparate parties, across different platforms, languages and programming environments Web Service e LDAP ROBERT A. VAN ENGELEN Finora abbiamo provveduto ad una struttura che autentica la macchina, il dispositivo e che quindi fornisce un tappeto sicuro (carpet) per effettuare altre operazioni. Per assicurare quei meccanismi di AAA che la VPN non fornisce introduciamo l autenticazione dell utente e i servizi che vengono forniti all utente. L IPsec si posiziona a livello network: per non interferire con esso dobbiamo effettuare tutte le altre operazioni ad un livello superiore, cioè applicazione. L infrastruttura con l ingresso dell autenticazione utente diventa quella illustrata in figura 6.1. L utente userà una postazione autorizzata, quindi in rete ed autenticata tramite PKI con il server, introducendo login e password e di seguito avrà a disposizione le operazioni a cui è abilitato. In questo capitolo introdurremo le tecnologie usate per autenticare l utente (Web Service e SSL/TLS), memorizzare le informazioni (LDAP), gestire gli account (XML), rappresentare le informazioni biometriche (XCBF). 6.1 EXtensible Markup Language L extensible Markup Language (XML) è nato nel febbraio del 1998 come raccomandazione del W3C (World Wide Web Consortium) come rivisitazione del complesso SGML (Standard Generalized Markup Language). E una tecnologia che permette di rappresentare informazioni in formato testuale definendo un metalinguaggio ossia un insieme di regole per creare altri linguaggi. Un 75

82 Web Service e LDAP Figura 6.1: Infrastruttura 76

83 6.1 EXtensible Markup Language errore comune è quello di vedere XML come puro linguaggio orientato al web; in realtà è molto di più poiché è riferibile a qualsiasi campo di applicazioni Definizione, strumenti e semantica Uno dei punti di forza dell XML è la portabilità: infatti rappresenta i dati in maniera testuale e quindi compatibili con qualsiasi piattaforma. XML sostanzialmente è un linguaggio di marcatura, un documento XML è un file di testo che contiene un elemento (root) che può contenere altri elementi. Le regole di contenimento sono specificate da una grammatica formale basata su espressioni regolari. Gli elementi sono delimitati da tag e possono avere degli attributi, ogni tag una volta aperto va sempre chiuso, non può quindi succedere come nell HTML con il tag <BR>: in XML dovremmo necessariamente scrivere <BR/>. All inizio di un documento XML è presente la dichiarazione dei namespace, essi servono essenzialmente a dichiarare l appartenenza degli elementi a particolari linguaggi XML, sono utili per evitare la possibilità di collisione tra nomi: è possibile paragonarli ai namespace in C/C++. Semantica La definizione della sintassi e della semantica di un documento XML può avvenire con due strumenti e alla struttura di un file: DTD (Document Type Definition) e XSD (XML Schema Definition). Essi provvedono alla definizione dei nuovi tag e di nuove strutture introdotti nel documento XML. Il loro uso non è obbligatorio ma è fortemente consigliato in tutti i casi. Il DTD è uno standard nato precedentemente all XML e scritto in SGML, le specificazioni DTD di un documento XML possono risiedere sia all esterno che all interno del documento stesso. Nel listato 6.1 mostriamo un semplice esempio di documento XML-DTD che riprenderemo successivamente, in cui è illustrato un possibile database degli utenti. La prima parte riguarda le definizioni DTD e indicano i tag permessi e il tipo di valori contenuti. XSD è definito usando lo stesso XML, è più complesso rispetto al DTD e non sta tutt oggi riscontrando un grande successo; il W3C però raccomanda 77

84 Web Service e LDAP Listato 6.1: Esempio XML-DTD 1 <?xml version="1.0"?> 2 <!DOCTYPE carpet-users [ 3 <!ELEMENT carpet-users (username,name, )> 4 <!ELEMENT username (#PCDATA) > 5 <!ELEMENT name (#PCDATA) > 6 <!ELEMENT (#PCDATA) > 7 ]> 8 9 <carpet-users> 10 <user> 11 <username>rudi</username> 12 <name>rudi Verago</name> 13 < >vlain@unipd.it</ > 14 </user> 15 </carpet-users> l uso dell XSD perché il DTD usa una sintassi propria richiedendo editor ed elaboratori ad-hoc. Se gli elementi di un documento sono annidati correttamente e rispettano le regole precedentemente illustrate allora il documento è detto well-formed. Se inoltre rispetta le regole semantiche specificate dal DTD o XSD associato allora il documento è detto valido. Parser Per elaborare i file XML si usano strumenti software chiamati parser. Esistono principalmente due tipi di parser: quelli compatibili con il DOM (Document Object Model) e quelli invece con il SAX (Simple API for XML). Il DOM si interfaccia direttamente con la rappresentazione gerarchica (come albero di nodi) dei dati in memoria, quindi è adatto a file di dimensioni medio/piccole. La navigazione all interno del file XML corrisponde alla navigazione all interno dell albero. Il SAX invece è adatto a documenti di dimensioni notevoli poiché non carica tutto il file durante l elaborazione. Usa il concetto event-driven (ad esempio usato nella programmazione di interfacce grafiche), ossia provvede a definire quale azioni compiere quando nella navigazione si incontrano taluni elemen- 78

85 6.1 EXtensible Markup Language ti. La navigazione avviene solo in avanti, è come se si avesse un indice in grado solo di avanzare e permette solo la lettura. Il SAX, proprio per questa caratteristica è più efficiente ma anche maggiormente oneroso dal punto di vista implementativo. Solo DOM è una raccomandazione del W3C. Il parser più diffuso è il Xerces sviluppato dal consorzio Apache: esistono implementazioni sia in Java che in C/C++; il parser di default in Java è il Crimson Vantaggi e raccomandazioni I vantaggi dell XML sono molteplici: permette di definire nuovi linguaggi permette agli sviluppatori di creare facilmente strutture ad-hoc per contenere informazione strutturata è semplice è facilmente elaborabile è comprensibile dagli esseri umani è facilmente editabile Mentre gli svantaggi sono: i documenti tendono ad essere molto più ingombranti dei dati binari velocità dell elaborazione dei parser Nel capitolo 8 faremo riferimento anche all XSLT (Extensible Stylesheet Language Transformation): esso è uno strumento per descrivere come trasformare documenti XML, fornisce cioè delle regole (templates) per trasformare alberi (documenti XML) in altri alberi. Le tecnologie che fanno da cornice al metalinguaggio XML sono molteplici e i linguaggi ottenuti dall XML tutt oggi sono moltissimi; in questa sede abbiamo introdotto brevemente solo gli strumenti che useremo nella nostra infrastruttura. 79

86 Web Service e LDAP Per concludere citiamo le raccomandazioni fornite dal W3C riguardo all XML: 1. XML dovrà essere direttamente usabile su internet. 2. XML dovrà supportare un largo campo di applicazioni. 3. XML dovrà essere compatibile con SGML. 4. XML dovrà essere facilmente interpretabile. 5. XML non dovrà avere opzioni. 6. XML dovrà essere leggibile dall uomo. 7. XML dovrà essere definito velocemente. 8. XML dovrà avere una progettazione formale e concisa. 9. I documenti XML dovranno essere facili da creare. 10. L economicità nel markup non dovrà avere alcuna importanza. 6.2 Web Service Il miglior modo per introdurre i web service (WS) è darne la definizione ufficiale, ovvero quella fornita dal W3C: Un web service è un interfaccia che descrive una collezione di operazioni, accessibili attraverso una rete mediante messaggistica XML La vera rivoluzione dei web service sta nella parola XML che rende questa tecnologia universale. Un primo paragone può essere fatto con i componenti dinamici tradizionali quali CGI e servlet: i web service estendono questi componenti assicurando l indipendenza dalla piattaforma e dal protocollo di trasporto. La comunicazione tra WS può essere anche automatica tra pacchetti software grazie alla loro descrizione ed indicizzazione standardizzata. Un esempio può chiarire molte cose. Supponiamo di aver creato un editor in Java e voler implementare un correttore automatico dinamico ossia un 80

87 6.2 Web Service correttore costantemente aggiornato con nuovi neologismi. L approccio tradizionale prevede che l utente debba installare patch di aggiornamento oppure interroghi un sito che offra questo servizio tramite CGI. In questo secondo caso l utente dovrebbe avviare la connessione ad Internet, digitare l indirizzo ed interrogare il motore di ricerca: i WS rivoluzionano questo aspetto. Potremmo immaginare che il sito offra un WS che svolge la funzione di ricerca dei neologismi, dal lato client implementeremo una richiesta in XML che si integra con l applicazione: in questo modo tutto sarà trasparente all utente. Possiamo pensare ad una situazione leggermente più complessa in cui l applicativo (in automatico) interroghi un motore di ricerca di WS, scelga uno dei risultati e compili la richiesta XML runtime. Tutto ciò è reso possibile dalla potenza espressiva dell XML. I WS permettono alle aziende di eliminare le difficoltà di comunicazione tra software scritti in diversi linguaggi di programmazione, sviluppati da altrettanti vendor o eseguibili su vari sistemi operativi. I protocolli che compongono l infrastruttura dei WS sono: SOAP WSDL UDDI Simple Object Access Protocol Simple Object Access Protocol (SOAP) è un protocollo leggero per lo scambio di informazioni in ambienti distribuiti; è interamente basato sull XML. SOAP non dipende dal protocollo di comunicazione dei messaggi ma tipicamente viene associato con l HTTP. Allo stato pratico non è necessario ridefinire ogni volta il formato e la struttura dei documenti XML da trasmettere per invocare un servizio remoto; diversi servizi sono perciò interrogabili e usufrubili con un linguaggio comune e universalmente riconosciuto. Un documento SOAP è innanzittutto un file XML well-formed composto da tre sezioni principali: 81

88 Web Service e LDAP envelope: la busta che contiene il messaggio SOAP, è sempre presente ed è il nodo root header: è opzionale, contiene informazioni che estendono il messaggio, relative ad esempio a gestione delle transazioni e autenticazione body: il corpo del messaggio, contiene le informazioni vere e proprie che si devono scambiare gli interlocutori Vi possono essere anche degli attachment di tipo binario; attualmente questa modalità è in fase di standardizzazione (SOAP with Attachment) anche se esistono già delle implementazioni (ad esempio SAAJ di Sun). Figura 6.2: Componenti messaggio SOAP SOAP è semplice e flessibile, può essere usato nei più differenti scenari. L integrazione di SOAP ed HTTP è alquanto semplice in quanto si fa uso 82

89 6.2 Web Service principalmente dei comandi di POST. La versione attuale dello standard SOAP è la 1.2 (raccomandazione W3C del giugno 2003). Ci sono principalmente due filosofie di sviluppo per i WS: document-driven e RPC Document-driven E un modello basato sull entità messaggio SOAP, consente di manipolare ciascun elemento della richiesta ed accedere a qualsiasi elemento della risposta SOAP. E di tipo fire&forget ovvero semplice invio da un punto ad un altro senza che ci sia controllo del traffico. Viene utilizzato in soluzioni di messaggistica, come ad esempio: l invio asincrono di informazioni real-time, l interfacciamento con servizi strutturati in modo particolare (non standard), collegamento a servizi che hanno una risposta dinamica SOAP-RPC L altro modello invece gestisce richieste e risposte di Remote Procedure Call (RPC), può essere sia asincrono che di tipo request/response (simile al RPC classico). Non è un modello vincolato a SOAP ma è aperto ad eventuali evoluzioni future. E fortemente basato sul WSDL (vedi 6.2.4). Con RPC non è necessario occuparsi di come vengono formati i messaggi SOAP: la programmazione avviene ad un livello più alto. Questa metodologia è indicata per lo sviluppo di applicazioni ad esempio complesse (con molti servizi) oppure per integrare WS esistenti Web Services Description Language Web Services Description Language (WSDL) è il dialetto XML usato per descrivere i web service: permette di indicare il formato dei messaggi da inviare, i metodi esposti dal web service, i parametri e i valori di ritorno. Nasce da un consorzio formato da IBM, Microsoft e Ariba con lo scopo di trovare delle modalità per standardizzare i web service. Lo scopo dei WSDL è permettere alle applicazioni l interfacciamento automatico, cioè permettere ai software di comunicare senza l intervento dell utente in modo tale da rendere il processo trasparente. 83

90 Web Service e LDAP WSDL descrive prima gli elementi astratti e poi le loro implementazioni pratiche. Gli elementi di un documento WSDL sono: Type: definizione dei tipi dei dati scambiati, sono creati con XSD Message: è un messaggio identificato da un nome composto da più part; gli elementi del message definiscono in modo astratto i tipi dei dati scambiati Operation: indica il tipo dell operazione descritta dal WS, può essere di tipo input, output e fault (errore) Port Type: un insieme di operazioni astratte e di messaggi Binding: dettagli per l implementazione delle port type come ad esempio il tipo di protocollo (HTTP, FTP... ) Port: indica l indirizzo IP con cui effettuare la connessione, provvede quindi alla specificazione dell endpoint che fornisce il servizio Service: insieme di port type Universal Discovery, Description ed Integration Universal Discovery, Description ed Integration (UDDI) è una specifica per la realizzazione di registri distribuiti, basati sul web, di web service; i registri UDDI vengono usati per la ricerca e la promozione di servizi web. E sostanzialmente un servizio di naming come il DNS (che però opera a livello più basso) e LDAP (vedi 6.3). L interrogazione dei registri può essere effettuata da browser o con il SOAP. Le informazioni gestite da UDDI sono di tre tipi: pagine bianche: contengono informazioni anagrafiche delle aziende pagine gialle: contengono le liste dei WS divisi per categoria pagine verdi: contengono informazioni tecniche sui WS come l URL dove risiedono e gli eventuali file WSDL 84

91 6.2 Web Service Esempio WS L esempio precedente può essere specificato quindi nel seguente modo: l applicativo interroga l UDDI per cercare il WS che gli interessa e consulta il WS tramite il WSDL per informarsi sui metodi e sui parametri di comunicazione. Tutte le comunicazioni usano come protocollo di alto livello il SOAP Metodologie Nella metodologia più semplice i web service possono essere visti come un estensione del modello RPC (Remote Procedure Call): la comunicazione può essere sincrona, il protocollo che effettua la chiamata remota (request) si blocca finché non riceve la risposta (response). E compito del client informarsi sui metodi offerti dal server e sui parametri richiesti. Le librerie in Java che implementano tale paradigma sono le JAX-RPC (Java API for XML-based RPC). Il JAX-RPC descrive un WS come una collezione di interfacce remote e metodi provvedendo alla conversione dei documenti WSDL. I WSDL invece vedono i WS come una collezione di ports e operation. Le corrispondenze sono le seguenti: wsdl:porttype interfacce wsdl:operation metodi wsdl:message parametri wsdl:type tipi La seconda tipologia di implementazione invece è orientata ai messaggi SOAP (document-driven). Java la implementa nel pacchetto JAXM (Java API for XML-Based Messaging) in due modalità: una sincrona e una asincrona. La JAXM è preferibile quando si ha una grande quantità di dati da scambiare o quando si ha bisogno di una maggiore fluidità (il client non viene bloccato). Il codice RPC in genere è più semplice in quanto si occupa la JVM dell interfacciamento con il SOAP mentre nel modello document-driven è compito del programmatore creare i messaggi XML. 85

92 Web Service e LDAP 6.3 Lightweight Directory Access Protocol LDAP è uno standard aperto per l erogazione di servizi di directory tramite una rete Intranet o Internet proposto nel 1993 dalla IETF nel RFC All inizio non ha avuto una grossa diffusione ma negli ultimi anni è stato riscoperto grazie alla sua versatilità che gli permette di memorizzare ogni tipo di informazione. LDAP è la versione leggera dello standard X.500. Le directory possono essere paragonate ad un elenco del telefono; alcune sono locali (forniscono servizio ad un ristretto contesto) mentre altre sono globali (forniscono servizio ad esempio su Internet). L implementazione più conosciuta per questo tipo di servizi è il DNS. Le possibili applicazioni dell LDAP sono: white pages, autenticazione utente, autorizzazione utente, routing posta elettronica, distribuzione certificati digitali, memorizzazione profili utenti ecc. Ogni directory viene intesa come un albero i cui nodi sono oggetti dotati di una struttura predefinita. Ogni oggetto è un istanza di uno o più classi, ha un nome univoco RDN (Relative Distinguished Name) e un DN (Distinguished Name) che è la sequenza degli RDN letti dalla foglia alla radice. Un directory schema descrive i tipi di objectclass che possono essere presenti in un certo albero. Lo entry è la struttura primaria del LDAP, contiene informazioni su un oggetto (persona, computer... ), ogni entry può avere uno o più attributi anche multipli; ogni attributo è una coppia (tipo, valore) identificato da un OID (Object IDentifier). Un objectclass quindi specifica il tipo di oggetto rappresentato da un entry, una classe A può essere una sottoclasse di un altra classe B (A eredita tutti gli attributi di B). Viene usata la semantica X.500 per le classi di oggetti: OID descrizione categoria (astratta, strutturale, ausiliaria) attributi obbligatori attributi opzionali 86

93 6.3 Lightweight Directory Access Protocol Nella figura 6.3 è mostrato un esempio di directory. E indicato il sottoalbero il cui nodo radice è dn=zeus, dn=edu (dn = domain name) che fa parte dell objectclass Organization. La radice ha due figli ou=docenti ou=studenti (ou=organization unit), le foglie appartengono alla objectclass Person. Ogni nodo può avere degli attributi, ad esempio gli attributi obbligatori in Person sono uid (RDN), sn (surname) e cn (common name) mentre quelli opzionali mail e givenname. Il DN della foglia con RDN uguale a vervla si può ricostruire percorrendo l albero dalla radice (seguendo il percorso evidenziato): uid=vervla, ou=studenti, dn=zeus, dn=edu. Lo schema di questo albero è rappresentato dagli objectclass organization, organizational unit e person e dai loro attributi. Figura 6.3: Esempio di directory LDAP La directory di figura 6.3 potrebbe rappresentare gli account di un laboratorio all interno di una rete universitaria, in cui vi sono due unità (studenti e docenti) che hanno privilegi differenti. Le operazioni sulle directory LDAP possono avvenire principalmente in 87

94 Web Service e LDAP due modi: tramite file di testo in formato LDIF (LDAP Data Interchange Format, specificato nel RFC 2849); di solito tale modalità è usata per l esportazione e l importazione di entry. tramite le API di naming dei linguaggi di programmazione come ad esempio le JNDI (Java Naming and Directory Interface) di JAVA. L uso dei linguaggi di alto livello fornisce una semplice interfaccia per le operazioni di scrittura, lettura, cancellazione e modifica. Sebbene non esista un linguaggio comune di interrogazione delle directory LDAP, come invece avviene con SQL nei database, vi sono delle convenzioni universalmente adottate: ad esempio nella ricerca si deve specificare da dove iniziare (base), l ambito della ricerca (scope), il filtro di ricerca e gli attributi da restituire. Il servizio di directory è basato sul modello client-server; sono date le specifiche anche di distribuzione dei dati tra vari server e di ridondanza (uno o più mirror anche inconsistenti tra loro). Vi è una certa similitudine tra database ed elenco LDAP: entrambi contengono informazioni in relazione tra loro ed indicizzate tramite una o più chiavi. In una directory LDAP i dati però sono memorizzati in forma descrittiva, organizzati gerarchicamente per fornire risposte rapide soprattutto in lettura. L implementazione open source più usata è OpenLDAP che realizza la versione 3 del protocollo (RFC 2251). 6.4 Biometria La recente necessità di una sempre più spinta sicurezza hanno dato impulso ad una crescente diffusione delle tecnologie biometriche in molteplici settori applicativi: logon di rete (o locale), scambio sicuro di documenti, firma digitale, controllo accessi... Molti governi promuovono la sperimentazione per l introduzione della biometria per il riconoscimento individuale. Il governo inglese all inizio di di- 88

95 6.4 Biometria cembre 2003 ha dato il via alla sperimentazione su volontari (per un periodo di 6 mesi) per l introduzione nel passaporto di mappa iridiologica e impronte digitali. Il governo olandese sperimenta da più di un anno l introduzione di tecniche biometriche per combattere il fenomeno dell immigrazione clandestina, mentre il governo americano per combattere il terrorismo; una scuola prestigiosa di Phoenix negli USA testa la scansione facciale per l individuazione dei criminali. Si potrebbero fare centinaia di esempi simili che mostrano appunto come la biometria sicuramente entrerà a far parte, in un futuro non molto remoto, della vita comune di tutte le persone. La nostra infrastruttura è nata per scambiare in particolare dati biometrici (in generale dati sensibili ossia preziosi ). Il primo problema che abbiamo dovuto affrontare è stato: come rappresentarli? Non esiste attualmente uno standard adottato universalmente tale da permettere un assoluta interoperabilità. L organizzazione per il progresso degli standard informativi strutturati (OASIS), un consorzio no profit costituito dalle maggiori aziende hardware e software a livello mondiale, ha presentato la sua soluzione basata sul linguaggio standard XML che permette ai vari sistemi di scambiarsi le informazioni biometriche. Tutti i vantaggi dell XML possono quindi essere estesi a questo linguaggio, assicurando inoltre una maggiore facilità di visualizzazione, di registrazione e di interrogazione dei dati biometrici. Il nuovo standard si chiama XML Common Biometric Format (XCBF), esso definisce un insieme di codifiche XML per il formato CBEFF (Common Biometric Exchange File Format) sviluppato dal NIST; tali codifiche sono basate sullo schema ANSI X9.84. Lo scopo principale dello standard non è quindi quello di ridefinire il formato con cui sono rappresentati i dati biometrici ma fornire loro un contenitore comune sicuro. Nel listato 6.2 è mostrato un semplice esempio. Nel semplice file XCBF mostrato (listato 6.2) si possono individuare due sezioni principali il biometricheader e il biometricdata. Nel biometricheader vengono illustrati dei valori che descrivono il dato biometrico e che sono indipendenti dalla piattaforma hardware e software; tale dato può essere poi rappresentato come biometricdata (nel nostro caso) 89

96 Web Service e LDAP Listato 6.2: Esempio XCBF 1 <BiometricSyntaxSets> 2 <biometricobjects> 3 <BiometricObject> 4 <biometricheader> 5 <version> 0 </version> 6 <recordtype> <id> 6 </id> </recordtype> 7 <datatype> <processed/> </datatype> 8 <purpose> <audit/> </purpose> 9 <quality> 100 </quality> 10 <validityperiod> 11 <notbefore> </notbefore> 12 <notafter> </notafter> 13 </validityperiod> 14 <format> 15 <formatowner> 16 <oid> </oid> 17 </formatowner> 18 <formattype> 19 <BlindedPrimaryAccountNumber> 20 A23D552FB C1F D9CCB2 21 </BlindedPrimaryAccountNumber> 22 </formattype> 23 </format> 24 </biometricheader> 25 <biometricdata> 26 0A0B0C0D 27 </biometricdata> 28 </BiometricObject> 29 </biometricobjects> 30 </BiometricSyntaxSets> 90

97 6.4 Biometria e quindi come XML markup oppure come dato binario (ad esempio in attachment). Tale metodologia assicura, come ricordato più volte, la massima flessibilità. Sono visibili la versione del biometricheader (version), un intero (recordtype) che identifica il tipo di dato (impronta digitale, mappa retinica... ), un intero per la qualità del dato (quality), il periodo di validità e così via. La potenza espressiva dell XCBF non si limita a questi pochi campi, permette infatti di rappresentare informazioni quali il dato cifrato, la firma digitale o meglio tutte le informazioni inerenti alla sfera della sicurezza. Per maggiori dettagli si rimanda alle specifiche dell OASIS. La versione 1.1 è stata rilasciata nell Agosto del Le critiche a tale standard però non mancano: infatti la Epic, un organismo per la tutela dei diritti civili, si lamenta per la scarsa attenzione alle problematiche sulla privacy; il direttore Marc Rotenberg dichiara che il protocollo garantisce gli aspetti di sicurezza ma a causa dell uso dell XML (e quindi a causa della maggiore semplicità di interazione tra differenti realtà) facilita l accumulo e l aggregazione di dati provenienti da diverse banche dati. 91

98

99 Capitolo 7 Web services also depend on the ability of enterprises using different computing platforms to communicate with each other. This requirement makes the Java platform, which makes code portable, the natural choice for developing WS. Infrastruttura: autenticazione utente e servizi disponibili Nel capitolo precedente sono stati introdotti i protocolli che abbiamo usato per completare la nostra infrastruttura. Ci siamo occupati di LDAP per fornire una directory centralizzata dove i nostri dati vengano memorizzati preferibilmente in formato XCBF, abbiamo parlato di XML perché abbiamo realizzato un sistema di autenticazione basato su questo metalinguaggio e mostreremo cosa possono offrire i web services sviluppando i servizi disponibili agli utenti. La seconda parte dell infrastruttura avrà come filo conduttore il linguaggio Java. Questo secondo livello deve essere posto al di sopra del tunnel IPsec (carpet) illustrato nei capitoli precedenti e ricordandoci che con la VPN si autentica il dispositivo, mentre in questa parte ci occuperemo principalmente dell interazione con l utente previa autenticazione tramite la coppia loginpassword. In figura 7.1 è mostrata la sezione dell infrastruttura da sviluppare. All inizio avremo un amministratore che ha accesso alla CA del laboratorio e che creerà un certificato digitale per una macchina; una persona autorizzata provvederà ad importare correttamente il certificato nel client e da quel momento in poi potrà venir creato un tunnel sicuro tra quest ultima ed 93

100 Infrastruttura: autenticazione utente e servizi disponibili Figura 7.1: Infrastruttura a livello applicazione il server. L instaurazione della VPN potrà avvenire al boot della macchina; a questo punto la stazione è autorizzata allo scambio dei dati biometrici. Un utente che voglia interagire dovrà dotarsi di login e password dall amministratore del laboratorio; fatto questo potrà effettuare il logon (operazione 1) dalla macchina abilitata (quindi dotata di certificato). In una prima fase all utente saranno rese disponibili le operazioni di invio e di download (operazioni 2 e 3) di dati biometrici mediante interfaccia stand-alone realizzata in Java. I servizi saranno realizzati appoggiandosi al protocollo SOAP sopra un ulteriore tunnel SSL/TLS; i dati saranno centralizzati in una directory LDAP non direttamente in rete (tale aspetto sarà chiarito più avanti) e verranno cifrati con la password dell utente. La gestione dell autenticazione dell utente non si appoggia ad un servizio LDAP ma bensì ad un handler realizzato ad-hoc in XML. In figura 7.2 è mostrata l interfaccia utente da cui sono possibili le operazioni descritte. 94

101 7.1 Directory LDAP Figura 7.2: Interfaccia utente Vista la complessità, l infrastruttura sarà illustrata utilizzando il paradigma inside-out, ossia descrivendo ad un primo livello ogni aspetto (implementazione di un protocollo) in generale e poi ad un secondo livello integrando i vari elementi. 7.1 Directory LDAP I dati biometrici saranno contenuti in un server LDAP che può comunicare solo con il server del laboratorio. Per l implementazione abbiamo usato il pacchetto open source OpenLDAP nella versione 2.1. Abbiamo definito quindi uno schema ad-hoc chiamato Carpet, vale a dire una struttura particolare per gli entry del database. Pacchetti come OpenL- DAP forniscono una vasta possibilità di scelta per quanto riguarda gli schemi e le tipologie degli attributi, soprattutto se la directory viene usata come server di autenticazione; schemi come organizationalperson, inetorgperson sicuramente garantiscono completezza ma non offrono flessibilità: gli attributi 95

102 Infrastruttura: autenticazione utente e servizi disponibili obbligatori sono sempre gli stessi e molte volte superflui; infine la gestione dei file binari è quasi completamente assente. Per questo abbiamo realizzato il nostro semplice schema, mostrato nel listato 7.1. Lo schema ha al suo interno 4 attributi usernamecarpet, datecarpet, desccarpet, biocarpet e 2 objectclass usercarpet e classcarpet. La nostra directory ha un primo livello di nodi formato da tutti gli utenti (username- Carpet) che hanno almeno un dato biometrico nel database e ad un secondo livello tutti i dati biometrici (biocarpet) identificati da una chiave che è la data (datecarpet) in cui sono stati immessi nella directory; infine una descrizione opzionale. La classe usercarpet specifica il primo livello mentre classcarpet il secondo. Il tipo degli attributi viene specificato dalla clausola SYNTAX: tutti sono stringhe tranne il dato biometrico che è dichiarato binario; tuttavia si ricorda che generalmente memorizzeremo dati in formato XCBF (XML). Sia la tipologia dei dati che le sequenze di numeri che compaiono all inizio di ogni dichiarazione sono OID e servono per identificare a livello globale (in tutta Internet) gli oggetti di uno schema; sono organizzati gerarchicamente (si possono trovare anche nel protocollo SNMP). Gli OID vengono assegnati da apposite autorità presenti su Internet come ad esempio IANA (Internet Assigned Numbers Authority). Nel caso del usernamecarpet abbiamo usato un OID pari a : la prima parte dovrebbe essere quella assegnata dal IANA mentre la seconda indica che si tratta di un attributo LDAP (1.1.2) e il numero dell attributo nello schema (in questo caso 1). Attualmente (13 gennaio 2004) la distribuzione degli OID è arrivata a , ma per ora ne abbiamo scelto uno fittizio ( ); quando l infrastruttura sarà formalizzata nella sua interezza provvederemo alla registrazione dello schema. Nella figura 7.3 è mostrato un esempio della nostra directory. 96

103 7.1 Directory LDAP 1 attributetype Listato 7.1: Schema Carpet 2 ( NAME usernamecarpet 3 DESC Username 4 EQUALITY caseignorematch 5 SUBSTR caseignoresubstringsmatch 6 SYNTAX {32768} ) 7 8 attributetype 9 ( NAME datecarpet 10 DESC date insertion bio data 11 EQUALITY caseignorematch 12 SUBSTR caseignoresubstringsmatch 13 SYNTAX {32768} ) attributetype 16 ( NAME desccarpet 17 DESC description bio data 18 EQUALITY caseignorematch 19 SUBSTR caseignoresubstringsmatch 20 SYNTAX {32768} ) attributetype 23 ( NAME biocarpet 24 DESC biometric data 25 SYNTAX ) # # objectclass 30 ( NAME usercarpet 31 SUP top STRUCTURAL 32 MUST (usernamecarpet) ) objectclass 35 ( NAME classcarpet 36 SUP top AUXILIARY 37 MUST (datecarpet $ biocarpet) 38 MAY ( desccarpet) ) 97

104 Infrastruttura: autenticazione utente e servizi disponibili Figura 7.3: Browsing della directory 7.2 Autenticazione utente L autenticazione dell utente è il secondo livello dell infrastruttura, come detto avverrà tramite login e password. Dal lato server non si useranno infrastrutture esistenti ma ci si appoggierà ad un handler creato ad-hoc. Tale scelta può apparire può apparire strana ma più avanti daremo un significato ben chiaro a tale scelta. Tutto ruota attorno ad un file XML gestito con le API di parsing di Java. Un esempio del file è nel listato 7.2. La gestione del file è molto simile a quella che effettua Tomcat nel suo MemoryRealm (vedi Appendice B.3). Gli attributi di ogni utente sono piuttosto standard: della password viene effettuato un hashing con l algoritmo SHA a 256 bit. E stata introdotta una minima suddivisione dell utenza in 3 gruppi con privilegi distinti. L utente getfile può solo prelevare file dalla directory, l utente sendfile solo spedirli mentre l utente administrator ha compiti particolari di amministrazione sulla directory. Naturalmente ogni eventuale combinazione è accettata. Nella nostra infrastruttura non è stato definito il concetto di sessione ossia non è prevista la sessione unica: logon-servizi-logout. Questo perchè possiamo 98

105 7.2 Autenticazione utente 1 <?xml version="1.0"?> 2 <!DOCTYPE carpet-users [ Listato 7.2: File utenti 3 <!ELEMENT carpet-users (username,password,name, , roles)> 4 <!ELEMENT username (#PCDATA)> 5 <!ELEMENT password (#PCDATA)> 6 <!ELEMENT name (#PCDATA)> 7 <!ELEMENT (#PCDATA)> 8 <!ELEMENT roles (#PCDATA)> 9 ]> <carpet-users> 12 <role rolename="sendfile"/> 13 <role rolename="getfile"/> 14 <role rolename="administrator"/> 15 <user> 16 <username>rudi</username> 17 <password>780d06d3a2af1b22aa2f657aa1385e3813a 18 9d2ecc16edffb23f6e30b05dc4b45</password> 19 <name>rudi Verago</name> 20 < >vlain@unipd.it</ > 21 <roles>sendfile,getfile,administrator</roles> 22 </user> 23 <user> 24 <username>nadia</username> 25 <password>780d06d3a2af1b22aa2f657aa1385e3813a 26 9d2ecc16edffb23f6e30b05dc4b45</password> 27 <name>nadia Bellossi</name> 28 < >nadia.beox@libero.it</ > 29 <roles>sendfile,getfile</roles> 30 </user> 31 <user> 32 <username>jaja</username> 33 <password>230f1b22aad06d3a2a2f657f6e30b05dc4b 34 aa1385e39d2ecc16edffb a</password> 35 <name>james Janton</name> 36 < >janton@nowhere.it</ > 37 <roles>sendfile</roles> 38 </user> 39 </carpet-users> 99

106 Infrastruttura: autenticazione utente e servizi disponibili immaginare che i client siano delle stazioni non intelligenti in cui un utente prepara l operazione che deve eseguire e all atto della comunicazione invia le credenziali di autenticazione dell utente. Al termine dell operazione l utente non si dovrà preoccupare di fare il logout; se invece deve eseguire subito dopo una nuova operazione dovrà rieffettuare il logon: tale modello introduce un minimo overhead per l utenza ma assicura maggiore sicurezza. Illustriamo brevemente come viene effettuato il parsing del file di amministrazione dell utente. Immaginiamo che l utente debba scaricare un file dalla directory: la prima cosa che farà sarà quella di inviare le sue credenziali, vale a dire login-password (nelle sezioni descriveremo la comunicazione) e il server dovrà controllare prima se l utente esiste e in seguito se appartiene al gruppo getfile. Il parsing del documento XML avviene con le API DOM di Java. Il pattern Factory (listato 7.3) viene implementato per ottenere un istanza valida indipendente dalla piattaforma prima creando l oggetto DocumentBuilderFactory, poi una sua istanza DocumentBuilder; se quest ultima è valida viene caricato interamante in memoria un oggetto di classe Document (ossia il file XML). L uso del DOM è la soluzione più adeguata per il nostro modello poiché il file XML tipicamente sarà di dimensione medio-piccola. Nelle righe avviene l hashing della password inviata dall utente. Infine si realizza la vera e propria navigazione all interno del file ossia all interno dell oggetto Document (foresta) rappresentato nella struttura di figura 7.4. La listuser rappresenta la lista dei nodi che hanno come tag <username>, a questo livello viene fatto il confronto con lo username inviato dall utente ed individuato il blocco <user> ossia nella figura 7.4 la colonna verticale. Infine si esegue il match per la <password> e per il <role>. Il modello è del tutto equivalente per quanto riguarda negli altri casi ossia per la classe degli administrator e dei sendfile. A questo livello è stato definito il database dove vengono memorizzati i file, l autenticazione dell utente e le classi di utenza; nei prossimi capitoli descriveremo come sono stati implementati i due servizi dal lato client-server 100

107 7.2 Autenticazione utente Listato 7.3: Autenticazione utente XML 1 DocumentBuilderFactory factory; 2 DocumentBuilder builder; 3 Document document=null; 4 try{ 5 factory = DocumentBuilderFactory.newInstance(); 6 builder = factory.newdocumentbuilder(); 7 document = builder.parse("/opt/bio/carpet-users.xml"); 8 } 9 catch (SAXException e) { 10 e.printstacktrace(); 11 } 12 catch (ParserConfigurationException e) { 13 e.printstacktrace(); 14 } 15 catch (IOException e) { 16 e.printstacktrace(); 17 } 18 //----- digest e conversione byte[] a String byte[] passwordbyte = password.getbytes(); 20 MessageDigest md = MessageDigest.getInstance("SHA-256"); 21 md.update(passwordbyte); 22 byte[] digest = md.digest(); StringBuffer sb = new StringBuffer(); 25 for (int i = 0; i < digest.length; i++) { 26 int tmp = (int)digest[i]; 27 if (tmp < 0) 28 tmp = tmp; 29 String tmpstr = Integer.toHexString(tmp); 30 if (tmpstr.length() == 1) 31 sb.append("0"); 32 sb.append(tmpstr); 33 } 34 passworddigest=sb.tostring(); 35 // NodeList listuser = document.getelementsbytagname("username"); for (int i=0; i < listuser.getlength(); i++){ 39 if (username.compareto(listuser.item(i).getfirstchild(). getnodevalue())==0){ 40 NodeList listpassword = document.getelementsbytagname("password" ); 41 if (passworddigest.compareto(listpassword.item(i).getfirstchild ().getnodevalue())==0){ 42 NodeList listroles=document.getelementsbytagname("roles"); 43 String rolesusertemp = listroles.item(i).getfirstchild(). getnodevalue()); 44 if (rolesusertemp.regionmatches(0,rolesusertemp,0,"getfile". lenght){ 45 return true; 46 } 47 } 48 } 49 } 50 return false; 101

108 Infrastruttura: autenticazione utente e servizi disponibili Figura 7.4: Vista DOM logica del file XML 102

109 7.3 Upload file e i processi SOAP di comunicazione. 7.3 Upload file Nella figura 7.5 è mostrata l interfaccia realizzata con le Swing di Java; è stata suddivisa in tre sezioni. Nella prima in alto ci sono i menù a tendina e i bottoni di avvio veloce dei servizi, nella seconda a destra c è l area di lavoro vera e propria, vale a dire dove avviene l interazione con l utente; infine a sinistra c è un frame di log che tiene traccia di tutte le operazioni eseguite. Figura 7.5: Presentazione interfaccia Server Usando il modello RPC per i web services il server espone dei metodi che possono venire chiamati dal client. Per l upload il server implementa il metodo capturedata che richiede come parametri in ingresso il nome del file, la sua descrizione, il suo datahandler, il nome dell utente e la sua password mentre fornisce in uscita una stringa che descrive il risultato dell operazione. Se si fossero scambiati dati solo in formato XCBF si sarebbe potuto inglobare il file all interno del messaggio SOAP, ad esempio rappresentandolo come una stringa; si è preferito invece usare un datahandler per assicurare il corretto funzionamento anche in caso di dati binari. La prima operazione che si esegue è il controllo delle credenziali illustrate 103

110 Infrastruttura: autenticazione utente e servizi disponibili Listato 7.4: Connessione alla directory 1 DirContext ctx=null; 2 Properties env = new Properties(); 3 env.put(javax.naming.context.initial_context_factory,"com.sun.jndi.ldap.ldapctxfactory"); 4 env.put(javax.naming.context.provider_url,"ldap://localhost:389"); 5 env.put(javax.naming.context.security_principal,"cn=admin,dc=conmo, dc=com"); 6 env.put(javax.naming.context.security_credentials,passwordroot); 7 try{ 8 ctx = new InitialDirContext(env); 9 } 10 catch(namingexception e){ 11 e.printstacktrace(); 12 } in 7.2, quindi la correttezza della login-password e l appartenenza alla classe sendfile. Successivamente si effettua la connessione al server LDAP (listato 7.4) usando le API di Java JNDI. Il server LDAP in questo caso viene indicato come localhost e ciò può sembrare una contraddizione con quello affermato precedentemente. In realtà a livello applicazione i due server sono distinti. Il web service offre un metodo per l elaborazione della directory ma non offre una visibilità diretta del database, quindi in realtà l utente comunica con il WS e solo il WS può comunicare con la directory. Gli attacchi esterni vengono annullati prevedendo un bind sul server LDAP, ossia esso è accessibile solo da localhost (e quindi dai WS implemetati localmente). JNDI opera sulle directory LDAP in maniera simile a come JDBC (Java Database Connectivity) opera sui database, implementando l interfaccia Context o più spesso la DirContext che la estende direttamente per accedere ai sistemi di directory. Non esiste però in JNDI un linguaggio di interrogazione universale come ad esempio SQL (Standard Query Language) per i database. Nelle righe 5 e 6 vengono specificate le credenziali di accesso al database; può sembrare strano che venga usato l utente amministratore ma questo assicura ancora una maggiore distinzione logica tra i due server (vedi 7.7). Si procede successivamente alla creazione degli attributi per l inserimento nella directory: viene acquisita la data corrente e convertito il datahandler in 104

111 7.3 Upload file Listato 7.5: Creazione attributi e objectclass 1 // ---- attributo utente 2 Attribute usernamecarpet = new BasicAttribute("usernameCarpet", username); 3 // ---- descrizione 4 Attribute desccarpet = new BasicAttribute("descCarpet", desc); 5 // ---- data corrente 6 Date d = Calendar.getInstance().getTime(); 7 String currentdate = String.valueOf(d.toString()) ; 8 Attribute datecarpet = new BasicAttribute("dateCarpet", currentdate) ; 9 // ---- conversione da datahandler a byte[] - bio data 10 ByteArrayOutputStream buffos= new ByteArrayOutputStream(); 11 try{ 12 dh.writeto(buffos); 13 } 14 catch(exception ioe){ 15 ioe.printstacktrace(); 16 } 17 byte[] buff = buffos.tobytearray(); 18 Attribute biocarpet = new BasicAttribute("bioCarpet", buff); 19 // ---- unione attributi 20 String RDN="usernameCarpet="+username+","+domainName; 21 Attributes attributetop = new BasicAttributes(); 22 Attributes attribute = new BasicAttributes(); 23 Attributes researchuser= new BasicAttributes(); 24 researchuser.put(usernamecarpet); 25 String complrnd="datecarpet="+currentdate+","; 26 Attribute objclasses = new BasicAttribute("objectclass"); 27 objclasses.add("top"); 28 objclasses.add("classcarpet"); 29 attribute.put(objclasses); 30 attribute.put(datecarpet); 31 attribute.put(biocarpet); 32 attribute.put(desccarpet); array di byte poiché LDAP gestisce gli attributi binari in tale forma. Vengono inoltre formati gli RDN (vedi sezione 6.3) dell utente e del file (si ricorda che come chiave viene usata la coppia utente-date). L utente può essere presente oppure no nella directory; se ricade nel primo caso significa che ha già inviato almeno un file. Si effettua una ricerca e si controlla se il risultato contiene almeno un elemento. Nella configurazione del server abbiamo indicato quali indici usare al demone per effettuare la ricerca veloce (vedi Appendice B.5) Se l utente non compare deve essere creato il nodo a lui associato inserendo il suo usernamecarpet e la objectclass usercarpet associata; in 105

112 Infrastruttura: autenticazione utente e servizi disponibili Listato 7.6: Ricerca utente 1 NamingEnumeration answer=null; 2 boolean ISuserLDAP=false; 3 try{ 4 answer = ctx.search(domainname,researchuser); 5 ISuserLDAP = answer.hasmore(); 6 } 7 catch(namingexception e){ 8 e.printstacktrace(); 9 } Listato 7.7: Inserimento dati 1 if (!(ISuserLDAP)){ // se l utente NON esiste 2 Attribute topclasses = new BasicAttribute("objectclass"); 3 topclasses.add("top"); topclasses.add("usercarpet"); 4 attributetop.put(topclasses); attributetop.put(usernamecarpet); 5 try{ 6 ctx.createsubcontext(rdn, attributetop); 7 } 8 catch(exception nabe){ 9 nabe.printstacktrace(); 10 } 11 } 12 try{ // --- operazioni comuni 13 ctx.createsubcontext(complrdn+rdn, attribute); 14 } 15 catch(exception nabe){ 16 nabe.printstacktrace(); 17 } seguito viene aggiunto la foglia corrispondente al dato biometrico inviato. Al termine di ogni operazione si chiude la connessione con la direcory invocando la direttiva ctx.close(). Nell analisi non abbiamo mai parlato di web services: è stato sviluppato un normale metodo capturedata di una classe Java capturefile. Per la creazione del WS useremo due software open source: Apache Axis (appendice B.2) e Jakarta Tomcat (appendice B.3). Axis sarà usato come framework di sviluppo delle applicazioni SOAP mentre Tomcat come application server per esporre i WS. Per maggiori dettagli sull integrazione si rimanda all Appendice. Prendiamo ora il nostro file.java, lo rinominiamo.jws, lo copiamo in Tom- 106

113 7.3 Upload file cat e eseguiamo il deploy, finalmente ottenendo il file WSDL riportato sotto. Listato 7.8: WSDL capturefile 1 <?xml version="1.0" encoding="utf-8"?> 2 <wsdl:definitions 3 targetnamespace = " 4 xmlns=" 5 xmlns:apachesoap=" 6 xmlns:impl=" 7 xmlns:intf=" 8 xmlns:soapenc=" 9 xmlns:wsdl=" 10 xmlns:wsdlsoap=" 11 xmlns:xsd=" 12 <wsdl:types> 13 <schema targetnamespace=" 14 xmlns=" 15 <import namespace=" 16 <complextype name="arrayof_xsd_string"> 17 <complexcontent> 18 <restriction base="soapenc:array"> 19 <attribute ref="soapenc:arraytype" wsdl:arraytype="xsd:string[]"/> 20 </restriction> </complexcontent> </complextype> </schema> 21 </wsdl:types> 22 <wsdl:message name="mainresponse"> 23 </wsdl:message> 24 <wsdl:message name="capturedataresponse"> 25 <wsdl:part name="capturedatareturn" type="xsd:string"/> 26 </wsdl:message> 27 <wsdl:message name="mainrequest"> 28 <wsdl:part name="args" type="impl:arrayof_xsd_string"/> 29 </wsdl:message> 30 <wsdl:message name="capturedatarequest"> 31 <wsdl:part name="filename" type="xsd:string"/> 32 <wsdl:part name="desc" type="xsd:string"/> 33 <wsdl:part name="dh" type="apachesoap:datahandler"/> 34 <wsdl:part name="username" type="xsd:string"/> 35 <wsdl:part name="password" type="xsd:string"/> 36 </wsdl:message> 37 <wsdl:porttype name="capturefile"> 38 <wsdl:operation name="main" parameterorder="args"> 39 <wsdl:input message="impl:mainrequest" name="mainrequest"/> 40 <wsdl:output message="impl:mainresponse" name="mainresponse"/> 41 </wsdl:operation> 42 <wsdl:operation name="capturedata" parameterorder="filename desc dh username password"> 43 <wsdl:input message="impl:capturedatarequest" name="capturedatarequest" /> 44 <wsdl:output message="impl:capturedataresponse" name=" capturedataresponse"/> 45 </wsdl:operation> 46 </wsdl:porttype> 47 <wsdl:binding name="capturefilesoapbinding" type="impl:capturefile"> 48 <wsdlsoap:binding style="rpc" transport=" http"/> 49 <wsdl:operation name="main"> 50 <wsdlsoap:operation soapaction=""/> 51 <wsdl:input name="mainrequest"> 52 <wsdlsoap:body encodingstyle=" encoding/" namespace=" use="encoded"/> 53 </wsdl:input> 54 <wsdl:output name="mainresponse"> 55 <wsdlsoap:body encodingstyle=" encoding/" namespace=" jws" use="encoded"/> 56 </wsdl:output> 107

114 Infrastruttura: autenticazione utente e servizi disponibili 57 </wsdl:operation> 58 <wsdl:operation name="capturedata"> 59 <wsdlsoap:operation soapaction=""/> 60 <wsdl:input name="capturedatarequest"> 61 <wsdlsoap:body encodingstyle=" encoding/" namespace=" use="encoded"/> 62 </wsdl:input> 63 <wsdl:output name="capturedataresponse"> 64 <wsdlsoap:body encodingstyle=" encoding/" namespace=" jws" use="encoded"/> 65 </wsdl:output> 66 </wsdl:operation> 67 </wsdl:binding> 68 <wsdl:service name="capturefileservice"> 69 <wsdl:port binding="impl:capturefilesoapbinding" name="capturefile"> 70 <wsdlsoap:address location=" jws"/> 71 </wsdl:port> 72 </wsdl:service> 73 </wsdl:definitions> Nelle prime righe sono indicati i namespace a cui si riferisce il file WSDL (wsdl:definitions), ossia le specifiche dei dialetti XML usati, utili inoltre per non avere interferenza tra tag di applicazioni differenti. In wsdl:types vengono specificati i tipi dei dati scambiati secondo lo standard SOAP-RPC: le stringhe sono state raggruppate in un array; nell elemento wsdl:message c è la definizione astratta dei tipi dei parametri in ingresso al web service, o meglio in ingresso al metodo invocato. Nel wsdl:porttype sono presentati i metodi esposti con l ordine dei parametri, nel binding invece il tipo di protocollo (RPC), quindi le specifiche su come comporre i messaggi SOAP. L ultimo elemento wsdl:service indica il nome del web service e l indirizzo http dove risiede. Il file come detto più volte è di facile lettura sia per un calcolatore che per una persona, quindi potremmo immaginare un programma runtime che interroghi questo file WSDL e crei la richiesta di connessione e di servizio in modo automatico, l unico compito dell utente sarebbe quello di fornire i parametri d ingresso corretti e fornire un interpretazione del risultato Client Nello sviluppo del metodo dal lato server non abbiamo tenuto minimamente conto del fatto che tale metodo venisse poi reso disponibile via web service. Dal lato client invece dobbiamo interfacciarci direttamente al file WSDL del WS e inizializzare una conversazione RPC. 108

115 7.3 Upload file Nella figura 7.6 è presentata l interfaccia realizzata per l upload; si compone sostanzialmente di due passi. Nel primo l utente seleziona il file da spedire e fornisce una breve descrizione del dato, se pensiamo al client come una stazione dove venga effettuata solo questa operazione potremmo prevedere un dispositivo di acquisizione biometrica. Nella seconda fase l utente inserisce le credenziali, quindi login-password. Figura 7.6: Interfaccia Upload File Nel listato 7.9 effettuiamo un invocazione dinamica (Dynaminc Invocation Interface, DII) del WS indicando il suo indirizzo esatto e il nome del metodo; Call Axis implementa javax.xml.rpc.call mentre Service Axis javax.xml.rpc.service. I passaggi da eseguire sono: 1. ottenere un JAX-RPC Service (listato 7.9) 2. istanziare una JAX-RPC Call usando il metodo createcall() del JAX- RPC Service (rimuovendo eventuali parametri della connessione precedente) (listato 7.9) 3. configurare l istanza della Call con il nome del metodo, i parametri di 109

116 Infrastruttura: autenticazione utente e servizi disponibili Listato 7.9: Istanze 1 String namews="capturefile.jws"; 2 private Service service = new Service(); 3 private Call call; 4 call = (Call) service.createcall(); 5 call.removeallparameters(); 6 String dirws = " 7 // String dirws = " ; 8 URL endpointws=new URL(dirWS); 9 call.settargetendpointaddress(endpointws); 10 call.setoperationname(new QName(nameWS, "capturedata")); ingresso e uscita (listato 7.10 e 7.11); nel listato 7.10 è indicato l elaborazione dell oggetto datahandler 4. invocare il WS con il metodo invoke() (listato 7.11) La porta di comunicazione (rappresentata con la variabile portserver) tipicamente è 8080, successivamente useremo la porta 8443 quando parleremo di sessione SSL/TLS. Il modello JAX-RPC (quello implementato da Axis) supporta boolean, byte, double, float, int, long, short come tipi primitivi e loro combinazioni o unioni (come ad esempio gli array). Come trasferire allora dati binari in una infrastruttura SOAP, vale a dire in un sistema dove gli interlocutori si scambiano messaggi di testo? Possiamo adottare due tecniche differenti: cambiare modello di comunicazione implementando il document-driven con il SAAJ oppure usare la classe javax.activaton.datahandler. I dati vengono memorizzati in un oggetto di tipo datahandler e l architettura Java si occupa di inglobarli come SOAP attachment, senza esplicita richiesta dell utente, provvedendo alla serializzazione e deserializzazione mediante il metodo registertypemapping. Il dato non è passato direttamente nell envelope del messaggio SOAP ma piuttosto come puntatore ad un attachment: la gestione dal lato server diventa allora banale. Tale operazione viene effettuata di default anche per le immagini (java.awt.image) e le stringhe (java.lang.string). 110

117 7.4 Download File Listato 7.10: DataHandler sul client 1 DataHandler dh = new DataHandler(new FileDataSource(fileName)); 2 QName qnameattachment = new QName(nameWS, "DataHandler"); 3 call.registertypemapping( 4 DataHandler.class, qnameattachment, 5 new org.apache.axis.encoding.ser.jafdatahandlerserializerfactory( DataHandler.class, qnameattachment), 6 new org.apache.axis.encoding.ser. JAFDataHandlerDeserializerFactory(DataHandler.class, qnameattachment) 7 ); Listato 7.11: Parametri e Invoke 1 call.addparameter("filename", org.apache.axis.constants.xsd_string, ParameterMode.IN); 2 call.addparameter("desc", org.apache.axis.constants.xsd_string, ParameterMode.IN); 3 call.addparameter("datahandler", qnameattachment, ParameterMode.IN); 4 call.addparameter("username", org.apache.axis.constants.xsd_string, ParameterMode.IN); 5 call.addparameter("password", org.apache.axis.constants.xsd_string, ParameterMode.IN); 6 7 call.setreturntype(org.apache.axis.constants.xsd_string); 8 9 String result = (String) call.invoke(new Object[] { filename,desc, dh, username, password }); Successivamente vengono passati tutti i parametri d ingresso con il loro nome e il tipo; alla fine si effettua invoke(). 7.4 Download File L operazione di download dei file è piuttosto simile nell implementazione all operazione dell upload: vengono però scambiati i ruoli degli interlocutori e la comunicazione avviene in due istanti differenti e ben distinguibili, quindi implementeremo due servizi distinti Lista file Nel primo servizio l utente invia login-password e come risposta ottiene le descrizioni e le date di tutti i file che ha memorizzato nella directory. L invocazione del servizio è nel listato L uscita, ossia il risultato del web 111

118 Infrastruttura: autenticazione utente e servizi disponibili Listato 7.12: Lista File: client 1 String dirws = " 2 URL endpointws=new URL(dirWS); 3 call.settargetendpointaddress(endpointws); 4 call.setoperationname(new QName(nameWS, "putlist")); 5 call.addparameter("username", org.apache.axis.constants.xsd_string, ParameterMode.IN); 6 call.addparameter("password", org.apache.axis.constants.xsd_string, ParameterMode.IN); 7 call.setreturntype(org.apache.axis.constants.soap_array); 8 String[] result = (String[]) call.invoke(new Object[] { username, password}); service, è un array di stringhe che rappresentano le varie descrizioni/date di ogni file. Come prima cosa, dal lato server, viene controllata la login-password (il procedimento è lo stesso che nel caso precedente solo che ora viene invece controllato se l utente appartiene al gruppo getfile) e successivamente ricercato nella directory il sottoalbero associato all utente. Se l utente esiste (listato 7.13) vengono cercate (riga 8) tutte le sotto entry rappresentanti i file inviati, viene creata poi una struttura di appoggio temporanea: un Vector temp di stringhe. Mediante un doppio ciclo annidato vengono memorizzate sia le date che le descrizioni in una stringa unica (per ogni file) divisa da un carattere /. L ultima operazione è la conversione in un array di stringhe che verrà elaborato dal client per la visualizzazione Ricezione Dopo l inserimento di una login e password corretta, all utente viene mostrata la lista dei suoi file biometrici, gli viene chiesto quale vuole scaricare e dove scaricarlo (rispettivamente 1 e 2 nella figura 7.7). Il client, nella seconda fase, passa come parametri lo username dell utente (già autenticato) e la data del file biometrico scelto. Un datahandler è il valore di ritorno. Il RDN del file scelto è dato dalla data, dallo username e dal nome del dominio ossia, a questo livello, tutti dati noti: non è necessario effettuare una 112

119 7.4 Download File Listato 7.13: Lista File: server 1 if ((ISuserLDAP)){ // se l utente esiste 2 try{ 3 SearchControls constraints = new SearchControls(); 4 constraints.setsearchscope(searchcontrols.subtree_scope); 5 // --- estrae solo gli attributi data e descrizione 6 String attrlist[] = {"datecarpet","desccarpet"}; 7 constraints.setreturningattributes(attrlist); 8 NamingEnumeration results = 9 ctx.search("usernamecarpet="+username+","+domainname,"( datecarpet=*)", constraints); 10 Vector temp = new Vector(); 11 while (results.hasmore()) { 12 SearchResult si =(SearchResult)results.next(); 13 Attributes attrs = si.getattributes(); 14 NamingEnumeration ae = attrs.getall(); 15 // --- mette il risultato in vector 16 while (ae.hasmoreelements()) { 17 Attribute attrisdate =(Attribute)ae.next(); // Data 18 String id1 = attrisdate.getid(); 19 Enumeration vals1 = attrisdate.getall(); 20 Attribute attrisdesc =(Attribute)ae.next(); // Descrizione 21 String id2 = attrisdesc.getid(); 22 Enumeration vals2 = attrisdesc.getall(); 23 // --- data e descrizione divisi dal carattere "/" 24 String onedata=vals1.nextelement()+"/"+vals2.nextelement (); 25 temp.add(onedata); 26 } 27 } 28 // ---- trasformo il vector nell array di stringhe 29 int numdata=temp.size(); 30 result = new String[numData]; 31 for (int i = 0; i < numdata; i++) { 32 result[i]=(string)temp.get(i); 33 System.out.println(result[i]); 34 } 35 } 36 catch(namingexception e){ 37 e.printstacktrace(); 38 } 39 } 113

120 Infrastruttura: autenticazione utente e servizi disponibili Figura 7.7: Interfaccia Download File Listato 7.14: Download: client 1 String dirws = " 2 URL endpointws=new URL(dirWS); 3 call.settargetendpointaddress(endpointws); 4 call.setoperationname(new QName(nameWS, "putdata")); 5 QName qnameattachment = new QName(nameWS, "DataHandler"); 6 call.registertypemapping(dh.getclass(), qnameattachment, 7 JAFDataHandlerSerializerFactory.class, 8 JAFDataHandlerDeserializerFactory.class); 9 10 call.addparameter("username", org.apache.axis.constants.xsd_string, ParameterMode.IN); 11 call.addparameter("datecarpet", org.apache.axis.constants.xsd_string, ParameterMode.IN); 12 call.setreturntype(qnameattachment); dh = (DataHandler) call.invoke(new Object[] { username, dateselect }); 114

121 7.5 Modifiche Listato 7.15: Download: server 1 // --- crea RND file scelto 2 String RND ="datecarpet="+datedownload+","+"usernamecarpet="+ username+","+domainname; 3 Attribute datecarpet = new BasicAttribute("dateCarpet", datedownload ); 4 Attributes researchuser= new BasicAttributes(); 5 // --- la data è la chiave 6 researchuser.put(datecarpet); 7 String[] attr = {"biocarpet"}; 8 Attribute answer=null; 9 try{ 10 answer = ctx.getattributes(rnd,attr).get("biocarpet") ; 11 byte[] resultbyte = (byte [])(answer.get()); 12 // --- conversione byte[] -> datahandler 13 dh=new DataHandler(new String(resultByte),"text/plain"); 14 } 15 catch(namingexception e){ 16 e.printstacktrace(); 17 } ricerca all interno della directory ma è sufficiente estrarre direttamente il valore dell attributo biocarpert mediate il metodo getattributes(rnd,attr).get( biocarpet). Ricordiamo che i database LDAP conservano i dati binari come array di byte quindi alla fine dovrà esserci la conversione in datahandler. Non vengono riportati i WSDL di questi WS poiché non mostrano nessuna altra informazione rispetto a quello presentato nel listato Modifiche Attualmente l infrastruttura assicura un ottimo grado di protezione da attacchi di qualsiasi tipo; con le modifiche che andremo a descrivere in questa sezione aggiugeremo un doppio livello di protezione a tutti gli attori della nostra struttura: ad un attacker non basterà conoscere un solo segreto ma ne avrà bisogno sempre di due. Immaginiamo che un hacker voglia rubare delle informazione biometriche quindi dei file memorizzati nel server LDAP: non potrebbe attaccare direttamente il server dalla rete poiché la directory non è direttamente disponibile dall esterno, dovrebbe prendere possesso del server del laboratorio in remoto conoscendo sia la password di root della macchina sia le credenziali di ac- 115

122 Infrastruttura: autenticazione utente e servizi disponibili cesso all LDAP. Oppure dovrebbe prendere possesso fisicamente di un client autorizzato ma necessiterebbe ugualmente delle credenziali dell utente Cifratura dati biometrici L accesso alla directory può avvenire solo da un host particolare (server del laboratorio) ma se l hacker si imposessasse fisicamente del server LDAP? Avrebbe sempre bisogno di due livelli di autorizzazione, se conoscesse le credenziali dell amministratore dovrebbe conoscere le credenziali dell utente admin della directory (entità distinta dalla precedente). Potrebbe però modificare le impostazioni del demone LDAP e ottenere accesso al database solo con l utente root del server: per questo motivo introduciamo la cifratura dei dati biometrici, vale a dire dell attributo binario della directory. Tale cifratura viene eseguita con l algoritmo AES e con la password dell utente che, ricordiamo, non risiede in questo server ma bensì nel server di autenticazione del dispositivo e dell utente. Questa modifica prevede che nella fase di registrazione di un file biometrico il dato venga cifrato dal web service di upload file e decifrato dal WS di download file. Nel capitolo vedremo una variante di questo procedimento. Illustriamo nel listato 7.16 il codice che va inserito nel codice 7.7. Sono state usate le JCE (Java Cryptography Extension) per cifrare il dato biometrico con il protocollo AES e con MD5. La password dell utente, memorizzata nella variabile di tipo String password, deve essere convertita in un array di caratteri (righe 13-16), poichè secondo la politica della SUN le stringhe sono ritenute poco sicure. Per le operazioni esposte ci si deve riferire ad un provider ossia ad un package che implementa un certo numero di funzionalità crittografiche: molte volte si ricorrono a librerie esterne, come ad esempio BouncyCastle, per ovviare a problemi di esportazione di dati cifrati al di fuori degli Stati Uniti. Nel nostro però abbiamo usato il provider implementato dalla SUN e in particolar modo nella modalità PBE (Password-Based Encryption), usiamo cioè una chiave derivata dalla password dell utente aggiungendo dei numeri 116

123 7.5 Modifiche Listato 7.16: Cifratura AES con MD5 del dato biometrico 1 PBEKeySpec pbekeyspec; 2 PBEParameterSpec pbeparamspec; 3 SecretKeyFactory keyfac; 4 byte[] salt = { 5 (byte)0xc7, (byte)0x73, (byte)0x21, (byte)0x8c, 6 (byte)0x7e, (byte)0xc8, (byte)0xee, (byte)0x99 7 }; 8 9 // --- inizializza parametri chiper 10 pbeparamspec = new PBEParameterSpec(salt, 20); // --- conversione String -> char[] 13 char[] charpassword = new char[password.length()] ; 14 for (int i=0;i<password.length();i++){ 15 charpassword[i] = password.charat(i); 16 } // --- crea PBE Cipher con la chiave e i parametri di cifratura 19 pbekeyspec = new PBEKeySpec(charPassword); 20 keyfac = SecretKeyFactory.getInstance("PBEWithMD5AndDES"); 21 SecretKey pbekey = keyfac.generatesecret(pbekeyspec); 22 Cipher pbecipher = Cipher.getInstance("PBEWithMD5AndDES"); 23 pbecipher.init(cipher.encrypt_mode, pbekey, pbeparamspec); // --- cifra il file biometrico biodata 26 byte[] chipertext = pbecipher.dofinal(biodata); 117

124 Infrastruttura: autenticazione utente e servizi disponibili casuali specificati nell array di byte salt. La codifica vera e propria avviene nella riga 26 con il metoro dofinal. La procedura di decifratura è del tutto simile tranne per il fatto che nel chiper pbecipher va specificata la direttiva DECRYPT_MODE al posto di ENCRYPT_MODE; è fondamentale implementare lo stesso tipo di PBE, vale a dire usare lo stesso salt Doppio Tunnel Un hacker che volesse sferrare l attacco analizzando il traffico di rete, e non il client o il server, dovrebbe innanzittutto bucare il tunnel IPsec: come dimostrato ampiamente nella sezione 5.5 ciò risulta alquanto complicato. Se però ci riuscisse potrebbe rubare le credenziali a qualche utente, oppure riuscire a catturare dati biometrici. Per questo introduciamo un secondo tunnel: una sessione SSL/TLS. Tale soluzione è un modo elegante per contrastare l unico punto debole dell architettura VPN ossia lo scambio del security bag (chiave privata con il certificato nel formato PKCS-12): un hacker in possesso di tale informazione avrebbe tutte le informazioni per decifrare il tunnel IPsec creato tra il client ed il server. TLS (Transport Layer Security) è uno standard IETF specificato nel RFC 2246, deriva dal protocollo SSL (Secure Socket Layer); TLS è un protocollo che lavora tra il livello 4 (trasporto) e il livello 5 (sessione), quindi giace al di sopra nel modello ISO/OSI del protocollo IPsec (livello 3). Le caratteristiche fornite sono: riservatezza, integrità dei dati e autenticazione. L applicazione più diffusa è quella legata ai browser nella trasmissione sicura di pagine web o di dati provenienti da form HTML: si pensi ad esempio quando si controlla la mail con yahoo.it o si inviano login e password oppure quando si inserisce il numero di carta di credito per un acquisto su amazon. com. I WS sono una tecnologia recente e quindi sotto il punto di vista della sicurezza piuttosto immatura. Per la prima generazione di WS molti sviluppatori non usano modelli ad-hoc (come quelli descritti nel capitolo 8) ma usano sessioni SSL/TLS per fornire confidenzialità e autenticazione one-way come nel caso dei browser. 118

125 7.5 Modifiche Listato 7.17: Configurazione Tomcat SSL/TLS 1 <!-- Define a SSL Coyote HTTP/1.1 Connector on port > 2 3 <Connector port="8443" 4 maxthreads="150" minsparethreads="25" maxsparethreads="75" 5 enablelookups="false" disableuploadtimeout="true" 6 acceptcount="100" debug="0" scheme="https" secure="true" 7 clientauth="false" sslprotocol="tls" /> Ipotizziamo di connetterci al sito mail.yahoo.it per controllare la mail, e di scegliere la modalità di connessione sicura, verremo reindirizzati ad un indirizzo ossia verrà creato un tunnel SSL/TLS tra il nostro pc e un server di Yahoo.it effettuando un autenticazione one-way poiché noi (il client) non abbiamo un certificato valido; in questa accezione useremo SSL/TLS nella nostra infrastruttura. Anche se non assicura una sicurezza paragonabile alla autenticazione two-way il tunnel SSL/TLS stile-browser permette di aggiungere un ulteriore livello di sicurezza con un costo amministrativo quasi nullo poichè i protocolli sono integrati perfettamente all interno di qualsiasi web/application server. Poiché i WS risiedono su un application server si è dovuto configurare Tomcat (vedi B.3) per accettare connessioni SSL/TLS. Come prima cosa deve essere creato un certificato per il server tramite l utility di Java: keytool; successivamente si deve configurare il web server in modo tale che accetti connessioni https sulla porta 8443 modificando il file di impostazioni server.xml (listato 7.17). Dal lato client si deve innanzitutto implementare l interfaccia di Java X509TrustManager per accettare certificati self-signed poiché il server usa un certificato firmato da se stesso e non viene usata la mutua autenticazione (non generiamo quindi il certificato del client). E sufficiente riscrivere i metodi della classe checkclienttrusted e checkservertrusted lasciandoli vuoti in modo tale da accettare le connesioni non trusted e quindi non causare eccezioni di tipo CertificateException. Infine è necessario modificare l url del web services modificando la porta di connessione e il protocollo (https): 119

126 Infrastruttura: autenticazione utente e servizi disponibili E importante notare che una soluzione che comprenda esclusivamente SSL/TLS e WS non è ottimale, può essere adeguata in contesti dove la sicurezza non sia fondamentale ma sicuramente non lo è nelle transazioni B2B (Business to Business) o in applicazioni critiche come la nostra. Si ricorda però che la nostra infrastruttura prevede un tunnel IPsec a livello più basso rispetto al tunnel SSL/TLS. Un diagramma riassuntivo dei livelli di sicurezza dell infrastruttura è illustrato nella figura 7.8; si può vedere come ogni entità prevede due livelli. 7.6 Altri servizi Oltre ai metodi principali di upload/download file, autenticazione utete, codifica/decodifica dei dati, interfacciamento con dati XML e directory LDAP sono stati implementati altri servizi: logger delle operazioni: permette di salvare il log su un file controllo connessione con l application server servizi di amministrazione del database degli utenti Controllo connessione E stato implementato come un web service, con un metodo solo, che non fa nulla se non restuire una stringa. Dal lato client l utente si interfaccia con la finestra di dialogo della figura 7.9: inserisce l indirizzo IP e la porta del server e procede all interrogazione. Dal lato del client c è un metodo dinamico che invoca il web service del server: se il WS viene raggiunto allora restituisce la stringa ok altrimenti viene generata un eccezione di tipo ConnectException, ServiceException, RemoteException, MalformedURLException... L eccezione viene catturata dal client e viene segnalato l errore all utente. Questo servizio viene usato anche per indicare l indirizzo IP e la porta del server Tomcat: ad esempio se per alcune connessioni non si vuole il tunnel SSL/TLS sarà sufficiente impostare la porta al valore

127 7.6 Altri servizi Figura 7.8: Livelli di sicurezza dell infrastruttura 121

128 Infrastruttura: autenticazione utente e servizi disponibili Figura 7.9: Finestra di controllo della connessione Serivizi di amministrazione I servizi di amministrazione non rigurdano la directory LDAP ma esclusivamente il database XML degli utenti, le operazioni classiche che si possono eseguire sono: creazione utente, cancellazione utente, modifica attributi utente; gli utenti che possono eseguire tali operazioni sono quelli che nel campo roles hanno come valore administrator. Per la creazione di un nuovo utente è stata creata l interfaccia di figura Nella prima parte del form vanno inserite le credenziali di un utente amministratore mentre nella seconda parte gli attributi dell utente da creare: l invocazione del WS consiste nel passaggio di tutti questi parametri al server. Dal lato del server invece i passi da seguire sono: 1. controllo credenziali dell amministratore nel file utenti XML 2. controllo dell esistenza dell utente sempre nel file XML, se lo username è già usato viene comunicato al client l errore: l amministratore deve quindi fornire uno nuovo 3. composizione degli elementi XML 4. salvataggio del file L interfacciamento con il database/file XML avviene con le DOM ed in particolar modo usando il parser Xerces, parte del codice è illustrato nel listato 7.18: vengono creati gli elementi, ossia i tag, degli attributi (name, password, 122

129 7.6 Altri servizi Figura 7.10: Frame creazione utente 123

130 Infrastruttura: autenticazione utente e servizi disponibili , name, roles), assegnati a loro i valori inviati dal client formando quindi le coppie tag/valore ed infine inseriti in coda al file. 7.7 Considerazioni Funzionali L uso dei WS assicura una buona interoperabilità, virtualmente sarebbe possibile scrivere il proprio codice ad esempio in Microsoft.NET ed interrogare il nostro application server Tomcat/Axis; in realtà la situazione non è così rosea come potrebbe sembrare. Lo sviluppo dei WS è ancora all inizio e non sono così rari problemi di interoperabilità tra client che usano piattaforme software/hardware differenti. Nel nostro caso inoltre utilizziamo una classe molto particolare per la manipolazione dei file (datahandler) che potrebbe creare altri problemi di compatibilità: l uso però di Java assicura la portabilità in tutti i sistemi per cui è disponibile una virtual machine. Possibili modifiche a questa tipologia di sviluppo sono sostanzialmente di due tipi: uso esclusivo file di testo: il file sarebbe rappresentato mediante un oggetto di tipo String; gli svantaggi rigurdano la non versabilità (non si possono più scambiare dati binari come ad esempio immagini) e le dimensioni: diventerbbe problematico scambiare stringhe lunghe qualche megabyte. Alcune sperimentazioni del consorzio Apache fissano il limite a 5-10 MByte. uso SOAP con attachment: vorrebbe dire cambiare modello implementativo usando al posto dell RPC il document-driven; anche questo approccio attualmente è sconsigliato poichè il protocollo è ancora in fase di definizione Performace Abbiamo mostrato nella sezione 5.4 come l introduzione del tunnel IPsec produca rallentamenti accettabili (nell ordine del 10%). 124

131 7.7 Considerazioni Funzionali Listato 7.18: Inserimento utente file XML 1 // --- seleziono il nodo radice 2 Node root=document.getfirstchild(); 3 4 // --- creo l elemento contenitore dell utente 5 Node userele=document.createelement("user"); 6 7 // --- creo i singoli elementi/attributi dell utente 8 Element usernameele = document.createelement("username"); 9 Text usernametxt = document.createtextnode(username); 10 usernameele.appendchild(usernametxt); 11 Element passwordele = document.createelement("password"); 12 Text passwordtxt = document.createtextnode(passworddigest); 13 passwordele.appendchild(passwordtxt); 14 Element nameele = document.createelement("name"); 15 Text nametxt = document.createtextnode(name); 16 nameele.appendchild(nametxt); 17 Element ele = document.createelement(" "); 18 Text txt = document.createtextnode( ); 19 ele.appendchild( txt); 20 Element rolessele = document.createelement("roles"); 21 Text rolesstxt = document.createtextnode(roless); 22 rolessele.appendchild(rolesstxt); // --- inserisco gli attributi in coda 25 userele.appendchild(usernameele); 26 userele.appendchild(passwordele); 27 userele.appendchild(nameele); 28 userele.appendchild( ele); 29 userele.appendchild(rolessele); 30 root.appendchild(userele); // --- salvataggio sul disco usando lo Xerces 33 FileOutputStream fos = new FileOutputStream("carpet-users.xml"); 34 OutputFormat of = new OutputFormat("XML","ISO ",true); 35 of.setindent(1); 36 of.setindenting(true); 37 XMLSerializer serializer = new XMLSerializer(fos,of); 38 serializer.asdomserializer(); 39 serializer.serialize( document.getdocumentelement() ); 40 fos.close(); 125

132 Infrastruttura: autenticazione utente e servizi disponibili A livello applicazione abbiamo introdotto un server LDAP e una messaggistica SOAP per i web services. LDAP non è avido di risorse: si ricorda infatti che è nato come protocollo di ricerca veloce. Non sono stati riscontrati particolari rallentamenti nemmeno in fase di scrittura. La nostra non è una applicazione real-time quindi non ha bisogno di prestazioni spinte, l uso dei WS assicura delle performance più che soddisfacenti anche alla luce del fatto che abbiamo: usato parser veloce: Xerces, probabilmente il miglior parser oggi disponibile; esistono implementazioni sia in C++ che in Java usato l ultima versione di Apache: ci siamo affidati alla nuova famiglia 2.x usato messaggi SOAP brevi: durante l autenticazione dell utente i messaggi sono dell ordine di un 1 Kbyte usato un engine SOAP efficente: Axis ha performance molto buone usato attachment piuttosto che lunghe stringhe all interno del messaggio SOAP implementando un datahandler Sicurezza SOAP SOAP fondamentalmente è un protocollo insicuro se usato da solo: i messaggi, in quanto testo HTTP, passano tranquillamente qualsiasi tipo di firewall. Comuni attacchi ai web services sono: 1. DoS (Denial of Service) sul server interropendo la disponibilità dei servizi 2. cattura e manipolazione messaggi SOAP: inserimento riferimenti a entità sul filesystem DoS aggiungendo al file XML molti tag vuoti in modo tale da rendere il compito dei parser dal lato server oneroso in termini di tempo 126

133 7.7 Considerazioni Funzionali Entity Expansion Attacks: dichiarazioni ricorsive all interno di file XML Entrambi gli attacchi vengono eliminati nella nostra infrastruttura: il primo grazie all introduzione dell aunteticazione del dispositivo e del client, il secondo grazie all instaurazione del tunnel IPsec ed eventualmente SSL/TLS. 127

134

135 Capitolo 8 Although WS-Security is the security cornerstone, it is only the beginning and must be extended with additional specifications that deal with policy, trust and privacy issues XML Security JESS THOMPSON Come accennato nella sezione i protocolli basati su XML sono intrinsecamente insicuri poiché sono basati su file di testo che possono invocare metodi, interagire con le applicazioni e bypassare i firewall. In questo capitolo introdurremo le tecnologie che vanno sotto il nome XML- Security e WS-Security, e che stabiliscono delle metodologie di cifratura, autenticazione e integrità dei documenti XML. Sono modelli attualmente in fase di definizione e di standardizzazione, quindi aperti a modifiche piuttosto radicali. Molte aziende internazionali stanno puntando molto su queste tecnologie perché i WS rappresentano veramente un enorme rivoluzione e XML può sicuramente diventare l ascii del futuro, l esperanto dell informatica. Spiegheremo infine come è possibile implementare queste tecnologie in modo tale da ridefinire parte della nostra infrastruttura eseguendo uno studio di fattibilità. Il consorzio W3C specifica che un architettura sicura per i web service deve garantire: autenticazione: il WS sia accessibile da utenti con identità verificata autorizzazione: l utente autenticato abbia i permessi per accedere ai servizi o ai dati confidenzialità: i dati scambiati siano protetti (cifrati) integrità: i messaggi non possano essere modificati 129

136 XML Security non ripudiabilità: impossibilità di negare, successivamente, ciò che si è inviato accessibilità: il WS deve essere sempre accessibile e quindi non deve essere soggetto ad attacchi di tipo DoS (Denial of Service) 8.1 XML Digital Signature XML Digital Signature (XMLDS) è stata sviluppata dal W3C e dall IETF. XMLDS fornisce servizi di integrità, autenticazione di messaggi e autenticazione del firmatario per qualunque tipo di dati. Il compito fondamentale è quello di associare una chiave a dei dati, non specifica però le chiavi associate a persone o istituzioni e nemmeno il significato dei dati firmati. Ci si deve riferire, quindi, ad altri protocolli per la definizione delle chiavi dell algoritmo. XMLDS può essere usato per firmare ed effettuare il digest di qualsiasi file XML, naturalmente nel nostro caso sarà applicato a file SOAP. La flessibilità dell XML è un vantaggio importante però introduce alcune problematiche: due documenti possono contenere le stesse informazioni ma avere differenti strutture; la differenza non riguarda la logica, ossia la struttura dei tag, ma ad esempio gli spazi all interno dei tag, i delimitatori di riga, i commenti... Per un parser che deve interpretare un documento XML ciò non è rilevante ma per uno strumento di signature è fondamentale firmare esattamente e solamente i dati. Per ovviare a tale inconveniente viene introdotto il concetto di canonizzazione; la canonizzazione è un processo che consiste nell applicare al documento XML un insieme di trasformazioni in modo da rappresentare le informazioni variabili in maniera standard. Due documenti logicamente equivalenti devono quindi avere la stessa forma canonica. Ci sono tre tipi di XML signature: enveloping,enveloped e detached. Quando la firma raccoglie tutti i dati si dice enveloping, quando fa parte del documento (diventandone un elemento) si dice enveloped, infine quando la firma è tenuta separata dai dati è detta detached. Il processo di signature si compone di cinque fasi: 130

137 8.2 XML Encryption 1. identificare il documento da firmare 2. trasformarlo in forma canonica 3. applicare le eventauli trasformazioni (ad esempio con il linguaggio XSLT) 4. creare un sommario (digest) dei risultati della trasformazione 5. cifrare per produrre la firma del digest Si deve quindi, in fase di firma, provvedere alla creazione dell elemento Signature che contiene tre elementi: SignedInfo, SignatureValue, e KeyInfo. Signedinfo è una struttura che contiene i vari algoritmi usati e il digest del messaggio, SignatureValue il valore vero e proprio della firma e KeyInfo un identificatore dell algoritmo usato per la verifica della firma; quest ultimo elemento è l unico opzionale. La procedura di validazione del messaggio è semplice ed è composta tipicamente da tre passi: 1. trasformazione in forma canonica dell elemento SignedInfo 2. controllo dell integrità del messaggio verificandone il valore di digest: questa operazione può avvenire in quanto il ricevente conosce i dati (il messaggio è in chiaro), le eventuali trasformazioni applicate (sono contenute in SignedInfo nel campo Transforms) e l algoritmo di digest (contenuto nell attributo Algorithm dell elemento DigestMethod ) 3. in caso di correttezza del digest si esegue la verifica della firma, anche qui tutte le informazioni da conoscere sono contenute nell elemento SignedInfo 8.2 XML Encryption XML Encryption soddisfa la raccomandazione del W3C sulla condifenzialità. La cifratura può riguardare il documento nella sua interezza, un elemento del documento, il contenuto di un elemento, gli attachment. 131

138 XML Security Listato 8.1: Esempio XML Digital Signature 1 <?xml version="1.0"?> 2 <SOAP-ENV:Envelope 3 xmlns:soap-env=" 4 xmlns:ds=" 5 <SOAP-ENV:Header> 6 <ds:signature> 7 <ds:signedinfo> 8 <ds:canonicalizationmethod 9 Algorithm=" 10 <ds:signaturemethod 11 Algorithm=" 12 <ds:reference URI="#infrastrutturaSicuraDownloadFile"> 13 <ds:transforms> 14 <ds:transform 15 Algorithm=" 16 </ds:transforms> 17 <ds:digestmethod 18 Algorithm=" 19 <ds:digestvalue> 20 i.valore.digest </ds:digestvalue> 22 </ds:reference> 23 </ds:signedinfo> 24 <ds:signaturevalue> 25 M.u.l.t.i.v.a.c.firma </ds:signaturevalue> 27 <ds:keyinfo> 28 <ds:keyname>identificatorechiaveopzionale</ds:keyname> 29 </ds:keyinfo> 30 </ds:signature> 31 </SOAP-ENV:Header> <SOAP-ENV:Body> 34 <!-- messaggio SOAP contenenente... --> 35 <!--... il metodo da invocare e i parametri --> 36 </SOAP-ENV:Body> 37 </SOAP-ENV:Envelope> 132

139 8.3 WS Security e XML firewall Listato 8.2: Esempio XML Encryption 1 <?xml version= 1.0?> 2 <EncryptedData 3 xmlns=" 4 MimeType="text/xml"> 5 <EncryptionMethod 6 Algorithm=" 7 <ds:keyinfo xmlns:ds=" 8 <ds:keyname>identificatore</ds:keyname> 9 </ds:keyinfo> 10 <CipherData> 11 <CipherValue>M.U.L.T.I.V.A.C.c13ra...</CipherValue> 12 </CipherData> 13 </EncryptedData> La cifratura dell intero documento (in ogni caso) produce un file piuttosto semplice e dalla struttura sempre uguale, un esempio è indicato nel listato seguente. Viene indicato il tipo di algoritmo usato, l identificatore della chiave (opzionale) ed infine il risultato dell operazione di cifratura. La cifratura di un elemento invece va a riscrivere solo la parte che rigurda quell elemento inserendo tutti i campi del caso precedente; il resto del documento XML rimane intatto. Naturalmente verranno aggiunte le informazioni di cifratura nell envelope del messaggio SOAP. Le estensioni negli altri casi sono banali: nella cifratura del valore dell elemento rimarrà invariato il tag, verrà modificato esclusivamente il valore (aggiungendo le stesse informazioni del caso precedente); la cifratura dell attachment produrrà un allegato cifrato mentre le informazioni sull algoritmo saranno contenute nel messaggio SOAP. 8.3 WS Security e XML firewall I concetti visti permettono di introdurre una nuova entità nell universo della sicurezza detta XML firewall: esso è un firewall che si occupa del controllo dei file XML, quando riceve ad esempio un documento SOAP provvede a 133

140 XML Security verificare che sia firmato e cifrato correttamente e che le informazioni all interno sia coerenti. Agisce nei livelli più alti del modello ISO/OSI o meglio del modello TCP/IP (figura 8.1), e può essere sia di tipo hardware che software. Figura 8.1: La pila della sicurezza: firewall Come detto in altre occasioni uno dei motivi dell insicurezza dei WS è il fatto che siano trasparenti ai firewall; con il concetto di XML Firewall eviteremo tale inconveniente: è necessario però che a tutti i documenti sia applicato XML Digital Signature e XML Encryption. Le specifiche WS-Security (WSS) indicano uno standard per l uso delle tecnologie XML-Encryption e XML Digital Signature nei messaggi SOAP. WS-Security precisa che l header SOAP contenga i dati relativi alla protezione; non specifica il formato della firma o della crittografia, ma come incorporare le informazioni sulla protezione definite in base ad altre specifiche. Uno degli aspetti fondamentali di WSS è l uso del concetto di Security Token. Un SecurityToken è simile ad una carta d identità o meglio ad un pass che deve essere mostrato per usufruire di un determinato WS. I token possono essere sia in formato testo che binario, vengono suddivisi in 6 tipi: UsernameToken: coppia login e digest della passoword certificato X.509: è il più usato tra quelli binari, viene definito come BinarySecurityToken 134

141 8.3 WS Security e XML firewall Listato 8.3: UsernameToken e BinarySecurityToken 1 <! > 2 <wsse:usernametoken> 3 <wsse:username>rudi</wsse:username> 4 <wsse:password Type="wsse:PasswordDigest"> 5 780d06d3a2af1b22aa2f657aa1385e3813a9d2ecc16edffb23f6e30b05dc4b45 6 </wsse:password> 7 <wsse:nonce>5uw4abku/m6/s5rne+l7vg==</wsse:nonce> 8 <wsu:created 9 xmlns:wsu=" T15:44:02Z 11 </wsu:created> 12 </wsse:usernametoken> <! > 15 <wsse:binarysecuritytoken 16 ValueType="wsse:X509v3" 17 EncodingType="wsse:Base64Binary" 18 Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa f"> 19 UUBni3ImMULTIVAC </wsse:binarysecuritytoken> ticket Kerberos: il Kerberos è un sistema di autenticazione nato nel 1993 ad opera del MIT, un ticket in questo contesto è un insieme di dati che permette ad un servizio di identificare un client. Nonostante Kerberos non sia un server di AAA (assicura solo l autenticazione) è usato in varie implementazioni di UNIX e come default in Windows 2000/2003 SAML assertion: vedi sezione 8.4 documento XCBF: nel caso di dati biometrici documenti XrML (extensible rights Markup Language): gestione diritti digitali Se il client usa lo UsernameToken deve inviare, nella richiesta di esecuzione del web service, la sua password sottoposta ad hash e firmare il messaggio usando tale password; in caso di X.509 (PKI) il messaggio può essere firmato con la chiave privata. Nel listato 8.4 viene mostrato un esempio di applicazione della XML Encryption all interno del WSS. Il body del messaggio SOAP è esattamente identico a quello del listato 8.2 mentre, come detto, nell header vengono aggiunte altre informazioni. 135

142 XML Security Listato 8.4: UsernameToken e BinarySecurityToken 1 <soap:envelope 2 xmlns:soap=" 3 xmlns:xenc=" 4 <soap:header 5 xmlns:wsse=" 6 xmlns:wsu=" 7 <wsu:timestamp> 8 <wsu:created 9 wsu:id="id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"> T14:26:15Z 11 </wsu:created> 12 <wsu:expires 13 wsu:id="id-10c46143-cb53-4a8e-9e83-ef374e40aa54"> T14:31:15Z 15 </wsu:expires> 16 </wsu:timestamp> 17 <wsse:security soap:mustunderstand="1" > 18 <xenc:referencelist> 19 <xenc:datareference 20 URI="#EncryptedContent-f6f50b d3-aac4-390 f476f2e51" /> 21 </xenc:referencelist> 22 <xenc:referencelist> 23 <xenc:datareference 24 URI="#EncryptedContent-666b184a-a388-46cc-a9e b9d43b6" /> 25 </xenc:referencelist> 26 </wsse:security> 27 </soap:header> 28 <soap:body> </soap:body> 31 </soap:envelope> 136

143 8.4 SAML e Single Sign-On 8.4 SAML e Single Sign-On Il Single Sign-On (SSO) consente ad un utente di autenticarsi una sola volta per accedere a differenti risorse. Nelle sua implementazione di base permette di scambiare il securitytoken in maniera sicura tra diverse entità. Security Assertions Markup Language (SAML) è un linguaggio XML che definisce appunto le regole (la sintassi) per lo scambio delle informazioni di autenticazione tra applicazioni; deriva dalla fusione di due standard concorrenti S2ML (Security Services Markup Language) e AuthML (Authentication XML). Questo modello introduce un entità chiamata SAML Authority, che svolge mansioni paragonabili a quelle della CA; un ruolo simile è svolto da Microsoft nell infrastruttura chiamata Passport. Immaginiamo che un utente A voglia invocare due WS di due differenti server che indichiamo con X e Y, ipotizziamo inoltre che l uso dei WS necessiti di autenticazione. A invia a X le proprie credenziali, X controlla la validità ed in caso di veridicità permette l uso del WS: l utente A invoca il WS. Ora A deve usufruire del service del server Y: nella metodologia comune dovrebbe inviare una seconda volta le credenziali. Con il SSO, e con SAML, il server Y quando riceve la richiesta di esecuzione del WS chiede alla SAML Authority, cioè al server X oppure ad una terza entità, l assertion dell utente, ossia l informazione che l utente A è autenticato. L assertion è in generale una dichiarazione di un fatto che riguarda un determinato soggetto in un determinato istante; può essere di tre tipi: di un attributo, di autenticazione e di autorizzazione. Gli elementi di un assertion sono: issuer: SAML authority assertion ID: codice identificativo subject: entità di cui si richiede l autenticazione advice: informazioni addizionali fornite dalla SAML Authority conditions: condizioni sulla validità dell assertion; è espressa nella forma NotBefore e NotOnOrAfter 137

144 XML Security Listato 8.5: Esempio SAML assertion di autenticazione 1 <samlp:response 2 MajorVersion="1" MinorVersion="0" 3 RequestID=" " 4 InResponseTo=" " 5 StatusCode="Success"> 6 <saml:assertion 7 MajorVersion="1" MinorVersion="0" 8 AssertionID=" " 9 Issuer="Lab. Sistemi Tempo Reale, UNIPD" 10 IssueInstant=" T10:00:23Z"> 11 <saml:conditions 12 NotBefore=" T10:00:30Z" 13 NotAfter=" T10:15:00Z" /> 14 <saml:authenticationstatement 15 AuthenticationMethod="Password" 16 AuthenticationInstant=" T10:00:20Z"> 17 <saml:subject> 18 <saml:nameidentifier 19 SecurityDomain="linda.dei.unipd.it" Name="rudi" /> 20 </saml:subject> 21 </saml:authenticationstatement> 22 </saml:assertion> 23 </samlp:response> Un esempio di assertion fornita da una authority è la seguente: Le richieste, le risposte e le assertion SAML vengono trasportati in un messaggio SOAP; generalmente risiedono nel body del messaggio. L estrazione degli elementi SAML può avvenire tramite browser oppure all interno di XML Firewall, nell ultimo caso il messaggio deve necessariamente essere elaborato con le specifiche XMLDS. E importante rilevare che SAML non specifica né nuovi meccanismi né impone limiti all autenticazione, può essere quindi utilizzato negli scenari più differenti. Un esempio di applicazione del linguaggio SAML è illustrata in figura 8.2. Supponiamo che al DEI (Dipartimento di Ingegneria dell Informazione, Università di Padova) ci siano vari laboratori che offrono web service: uno studente comodamente da casa potrebbe usufruire di questi servizi. Ipotizziamo inoltre che l utente abbia un account valido impostato precedentemente e si sia preventivamente autenticato su un qualche server; non è importante dove avvenga questa operazione ma è fondamentale che la SAML Authority del 138

145 8.4 SAML e Single Sign-On dominio dei.unipd.it contenga l assertion che A è autenticato. Supponiamo ora che A voglia utilizzare un servizio del Laboratorio 2 (lab2), A invia una richiesta di accesso, lab2 inoltra all authority dei.unipd.it una request per authentication assertion ossia richiesta del tipo A può usufrire del servizio richiesto in questo particolare momento?. L authority restituisce un authentication assertion reference al lab2. In caso di successo della procedura di autenticazione l utente usa il servizio del lab2. Figura 8.2: Esempio applicazione SAML L esempio sopra proposto è molto semplice e riguarda esclusivamente un aspetto del SAML, in ogni caso fa capire come tale procedura possa essere ripetuta per tutti gli altri server a cui l utente A richiede l esecuzione di un WS. Nel settembre del 2001 è nata la Liverty Alliace, un consorzio di aziende (vendor e software house) formato con lo scopo di definire standard per la gestione delle identità e in particolare per proporre un framework SSO. At- 139

146 XML Security tualmente comprede più di 160 membri: Sony, Nokia, Novell, Vodafone, HP, Bank of America, Sun, RSA... Lo scopo, come detto, è quello di integrare le varie tecnologie XML in una infrastruttura che permetta la gestione: dell identità (network e federal), del SSO e del singolo logout, del cosidetto circolo di fiducia (idendity provider, service provider ecc.) e SAML. Tutto questo dovrebbe avvenire nella piena osservanza delle regole di privacy. 8.5 XKMS e XACML XML Key Management Specification (XMKS) provvede ad un interfaccia XML per i servizi di PKI, specifica quindi la distribuzione, la validazione e la revoca delle chiavi. Un servizio XKMS è in tutto e per tutto un web service che permette agli utenti di registrare e revocare le loro chiavi usando un dialetto XML. E formato da due protocolli: XML Key Information Service Specification (XKISS): servizio per validare le chiavi pubbliche usate nella XMLDS e XML Encryption XML Key Registration Service Specification (XKRSS): web service che accetta la registrazione e la revoca delle chiavi pubbliche XML Access Control Markup Language (XACML) è sviluppato dall OASIS e fornisce una sintassi per la gestione delle informazioni di autorizzazione; descrive inoltre un linguaggio di policy. La tipica applicazione riguarda il caso in cui un utente A voglia eseguire un operazione su una risorsa, A dovrà richiedere l autorizzazione (il permesso) a chi controlla questa risorsa; l organo controllore è detto Policy Enforcement Point (PEP). Il PEP forma una richiesta (request) composta: dagli attributi dell utente A, dalla risorsa in questione, dal tipo di azione e provvede ad inviarla ad un altra entità chimata Policy Decision Point (PDP); il compito di PDP è quello di controllare le policy e inviare a PEP il risultato (response). PEP comunicherà ad A il permesso (in caso positivo) di uso della risorsa. 140

147 8.6 La sicurezza oggi: web service Le entità PEP e PDP devono essere tenute concettualmente separate ma nessuno vieta di implementarle nella stessa applicazione. Nonostante XACML sia poco più che un draft ha la caratteristica di poter integrarsi perfettamante con SAML e LDAP. 8.6 La sicurezza oggi: web service Come detto più volte le tecniche illustrate in questo capitolo non vengono ampiamente usate. Al giorno d oggi la sicurezza dei WS non viene intesa a livello dei documenti XML: applicandone quindi la cifratura, firmandoli o provvedendone all autenticazione, ma piuttosto utilizzando le tecnologie che comunemente sono da supporto all HTTP. Queste tecniche sono principalmente: HTTP basic authorization, SSL over HTTP (HTTPS, HTTP Secure) e combinazione delle due. La miglior configurazione possibile è quella data dall unione delle due tecniche: in questo modo si assicurano tutte le raccomandazioni del W3C tranne la non ripudiabilità e l accessibilità. HTTP basic authorization HTTP basic authorization (BASIC-AUTH) è un meccanismo molto semplice usato per proteggere l accesso ad un WS: l utente deve possedere username e password. Il web server ha una lista di account validi e le corrispettive risorse a cui possono accedere, il client all atto dell invocazione del WS deve fornire la coppia username-password. Apache Axis realizza tale caratteristica in maniera immediata, nel listato 8.6 è mostrata l invocazione del WS dal lato client. Listato 8.6: Invocazione WS con BASIC-AUTH 1 call.settargetendpointaddress(endpointws); 2 call.setoperationname(new QName(nameWS, namemethod)); 3 call.setusername("rudi"); 4 call.setpassword("pa33w0rd"); 5 6 String ret = (String) call.invoke( new Object[] { dati } ); 141

148 XML Security Il server cattura username e password con i metodi sotto indicati; l handler, ossia la gestione e il controllo delle informazioni, deve essere realizzato ad-hoc oppure ci si deve appoggiare ad altri server come ad esempio Tomcat. Listato 8.7: BASIC-AUTH: lato server 1 String username = msgcontext.getusername(); 2 String password = msgcontext.getpassword(); Nel documento SOAP le informazioni dell utente vengono codificate ma il resto del messaggio rimane in chiaro quindi un hacker potrebbe benissimo catturarlo, modificarne il contenuto e rispedirlo: si capisce quindi come questo meccanismo, se usato da solo, non offra alcun livello di sicurezza. Nella nostra infrastruttra si sarebbe potuto usare BASIC-AUTH ma si è preferito ricorrere a un handler scritto ad-hoc poiché dovevamo contenere altre informazioni oltre a quelle di autenticazione e successivamente prevedere un facile interfacciamento con LDAP (vedi Capitolo 7). HTTPS HTTP Secure è stato usato nella nostra infrastruttura (7.5.2) nella modalità con autenticazione one-way (solo del server) poiché il client non aveva un certificato. E possibile però effettuare una mutua autenticazione usando il tool di Java keytool per generare i certificati per la sessione SSL/TLS. L installazione e l uso del certificato sul lato client è molto semplice: è sufficiente copiare il file.keystore in una directory a piacere (ad esempio nel profilo) e specifare nell invocazione del WS: Listato 8.8: WS con HTTPS 1 String dirws = " axis/"+namews; 2 System.setProperty("javax.net.ssl.trustStore", "C:\\ Documents and Settings\\rudi\\.keystore"); Si ricorda però che il livello di sicurezza introdotto dal tunnel TLS è molto inferiore a quello del tunnel IPsec poiché TLS lavora a livello trasporto mentre IPsec a livello rete nel modello ISO/OSI. 142

149 8.7 Studio della fattibilità 8.7 Studio della fattibilità In figura 8.3 sono mostrati i vari protocolli sull XML e WS-Security e il loro stato di definizione (per gentile concessione della SUN Microsystems): il linguaggio C14N riguarda la forma canonica di un documento XML, WS-Policy è usato per la descrizione delle policy dei WS, WSPL è simile a WS-Policy ma è parte integrante di XACML. Quelli indicati con il riquadro rosso sono standard della Liberty Alliance: ID-FF (Federation Framework) per la gestione dell identità network e federale [105] e ID-WSF (Web Services Framework) per l identità applicata al contesto dei WS [117]. Vi è un errore: essendo l immagine datata agosto 2003 non indica il fatto che XCBF è diventato un standard OASIS. Figura 8.3: Protocolli XML-Security. Sun Microsystems Implementazione XML Security Nel capitolo 7 abbiamo integrato meccanismi di autorizzazione e autenticazione creati ad hoc su un doppio tunnel IPsec/TLS con i web services. Si può pensare di modificare l infrastruttura a livello applicazione inserendo i concetti della XML-Security. 143

150 XML Security La nostra infrastruttura sarebbe quindi interamente basata sui web service, quindi intenderemo per cifratura e firma metodologie da applicare a messaggi SOAP (ed eventualmente ad attachment). L integrazione dei vari protocolli è piuttosto immediata: possiamo usare XML Digital Signature e XML Encryption per firmare e cifrare i messaggi SOAP, XACML per definire le autorizzazioni mentre SAML interagisce con tutti gli altri protocolli: SAML e XMLDS: per firmare le assertion garantendo autenticazione, integrità e non ripudiabilità SAML e XML Encryption: cifrare le assertion per assicurarne la confidenzialità SAML e XKMS: l infrastruttura PKI si appoggia a XKMS permettendo di rendere sicuro il traffico SAML SAML e XACML: per definire policy di accesso e controllo alle assertion SAML SAML e WS-Security: le assertion possono essere viste come il security- Token della WSS Se vogliamo un infrastruttura a chiave pubblica/privata implementeremo XKMS per la gestione delle chiavi pubbliche oppure potremmo appoggiarci ad un server LDAP per la gestione degli account utente (login e password). Nella figura 8.4 ipotizziamo uno scenario in cui l authority sia anche il server che si occupi dell autenticazione. Alcune operazioni sono bidirezionali, ossia prevedono al meccanismo di request/response: sono indicate con le freccie su entrambi i lati; l ordine temporale degli scambi è: 1. client richiede il WS, il serverws dirige questa richiesta alla SAML Authority 2. client si autentica e riceva dall authority un assertion che indica tale fatto 144

151 8.7 Studio della fattibilità Figura 8.4: Richiesta di servizio 145

152 XML Security 3. client rispedisce la richiesta al serverws con l assertion appena ottenuta 4. il serverws verifica (controlla l autenticità) l assertion con l authority 5. il serverws comunica al client che può eseguire il WS oppure nega l autorizzazione Una volta ottenuta l autorizzazione il client A e il serverws spediscono messaggi SOAP cifrati con XML Encryption e firmati con XMLDS. 146

153 Conclusioni Lo sviluppo di un infrastruttura sicura per reti wireless deve tenere conto di alcuni aspetti del tutto irrilevanti nel caso di reti cablate, si pensi ad esempio alla facilità di cattura dei dati nelle WLAN. Nonostante ciò il nostro modello di infrastruttura usa tecnologie nate su reti cablate, non sviluppate ad-hoc per le reti wireless e che quindi possono essere applicate in entrambi i casi. IPsec è uno standard ampiamente affermato nella sfera B2B (Business 2 Business), sta riscontrando un notevole successo anche in ambienti domestici, negli uffici e nelle aziende. Ha il vantaggio di essere estremamente versatile infatti può proteggere qualsiasi tipo di traffico e può essere integrato in qualsiasi struttura esistente; è un investimento sicuramente ragionato poiché è integrato nel protocollo IPv6 e quindi sarà implementato in tutti i sistemi operativi. I Web Service sono una tecnologia piuttosto recente su cui i grandi nomi dell informatica internazionale (tra cui IBM, Sun, Microsoft e Novell) stanno investendo sempre più fondi per la ricerca e per la definizione/standardizzazione dei protocolli. La nostra infrastruttura trae vantaggi dall integrazione di queste tecnologie riuscendo a fornire un doppio livello di sicurezza ad ogni livello e ad ogni componente. La progettazione ha infatti tenuto conto dei punti deboli dei protocolli usati aggiungendo uno strato ulteriore di sicurezza dove fosse necessario. Un hacker intenzionato a sferrare un attacco alla nostra infrastruttura potrebbe colpire : un client, uno dei due server (web server o LDAP) oppure agire analizzando il traffico di rete. 147

154 Conclusioni Dal punto di vista del client dovrebbe non solo impossessarsi di una stazione autorizzata ma anche detenere le credienziali di qualche utente (doppia autenticazione); al server LDAP non potrebbe accedere direttamente ma dovrebbe farlo attraverso il web server: ma anche qui sarebbero necessari due segreti. Nella remota possibilità che riuscisse ad impadronirsi della directory LDAP dovrebbe conoscere le credenziali dell amministratore e la password dell utente a cui vuole rubare i dati biometrici, quest ultima informazione risiede però in un altro server. Infine l analisi del traffico di rete, grazie a doppio tunnel IPsec-TLS, non porterebbe a nessun risultato utile. Le applicazioni tipiche rigurdano contesti in cui i dati scambiati siano sensibili, quindi contesti in cui riservatezza, integrità ed autenticazione siano i principali aspetti da tenere in considerazione. La costruzione dell infrastruttura è avvenuta a blocchi, ossia sono state prese diverse tecnologie, sono state sviluppate singolarmente ed infine integrate. E qundi possibile adattare il modello a vari contesti: ad esempio in un laboratorio di ricerca potrebbe essere sufficiente avere solamente un tunnel IPsec tra i vari client della rete, mentre in una connessione HTTP tra client su Internet utilizzare solo l applicazione con i WS. Questa scalabilità è importante anche dal punto di vista amministrativo, infatti applicazioni critiche potrebbero richiedere l uso dei certificati, delle password e delle directory mentre piccole aziende potrebbero ritenere più che sufficiente un autenticazione login-password a livello applicazione. L aspetto della modularità dell infrastruttura rende inoltre più agevoli grandi e piccole modifiche: potremmo ad esempio pensare di sostituire l autenticazione del dispositivo e l instaurazione del tunnel IPsec con le nuove specifiche i oppure usare il RADIUS come server di AAA. Entrambi questi cambiamenti sarebbero attuabili semplicemente sostituendo le parti dell infrastruttura interessate come abbiamo fatto vedere nell uso delle tecnologie XML-security 148

155 Appendice A Sicurezza Informatica A.1 Data Encryption Standard Il DES è un cifrario sviluppato dalla IBM e modificato dalla National Security Agency (NSA); è stato adottato come standard dal governo degli Stati Uniti dal 1977, dismesso nel 1998 quando la Electronic Frondier Fondation realizza la DES Cracker Machine e documenta i risultati della sue sperimentazioni in un libro dal titolo Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design. Il DES usa una chiave a 56 bit per cifrare i dati in blocchi da 64 bit ed è stato pensato per essere efficiente dal punto di vista hardware. Al giorno d oggi un hacker fornito di un supercalcolatore può, usando la forza bruta, crackare la chiave nell ordine di qualche secondo. Per fronteggiare l evoluzione hardware è stata standardizzata un variazione del DES: il 3DES che provvede a ripetere l operazione tre volte. La dimensione della chiave è quindi di 168 bit. L applicazione doppia di algoritmi di cifratura è suscettibile ad attacchi di tipo meet-in-the-middle, che permette di decifrare i dati con al più 2 N+1 (con N uguale alla dimensione di una chiave) tentativi; quindi non si ricorre mai a soluzioni che usano un numero pari di chiper. Lo svantaggio più evidente del 3DES è la lentezza se paragonato ad altri algoritmi simili. IPsec usa la versione del 3DES specificata nel RFC 2451, in particolare la 149

156 Sicurezza Informatica Figura A.1: Blocchi 3DES variante in cui la prima e la terza chiave sono identiche. Citiamo infine l algoritmo IDEA anch esso nato come evoluzione del DES nel 1991 da due progettisti svizzeri: Xuejja Lai e James L. Massey; l IDEA usa blocchi da 64 bit ma chiavi da 128. E uno degli algoritmi più usati nei software commerciali, ma non ha mai avuto diffusione nel mondo open source poiché è protetto da brevetto. A.2 Advanced Encryption Standard L AES è vincitore di un concorso indetto dal National Institute of Standards and Technology (NIST). E stato sviluppato da due ricercatori belgi Rijmen and Daemen da cui ha preso anche il nome Rijndael, ed è stato dichiarato Federal Information Processing Standard (FIPS) il 6 Dicembre Usa tre differenti lunghezze di chiave: 128, 192 e 256 bit. Interessante è un famoso confronto con l antenato DES: In the late 1990s, specialized DES Cracker machines were built that could recover a DES key after a few hours... by trying possible key values... assuming that one could build a machine that could recover a DES key in a second (i.e., try 255 keys per second), then it would take that machine approximately

157 A.2 Advanced Encryption Standard thousand-billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old. E appunto questa la potenza dell AES: permette di usare chiavi relativamente brevi (128 bit) avendo un affidabilità molto maggiore di qualsiasi altro algoritmo di cifratura, ed proprio questo lo rende uno dei capi saldi del nuovo standard i. La sua schedulazione della chiave è veloce, e le sue richieste di memoria sono basse, quindi è efficiente in hardware e in ambienti con poca memoria. Il Rijndael inoltre è ottimizzato per architetture parallele. L algoritmo AES è piuttosto semplice: prima il messaggio viene sottoposto ad un XOR con la chiave K 0, successivamente viene ripetuta 10 volte la funzione di cifratura F con chiavi generate da un processo di espansione attivato dalla chiave master. Figura A.2: Iterazioni dell algoritmo AES In ingresso ad ogni blocco si hanno messaggi da 16 byte, si effettua una prima permutazione S ad ogni byte e successivamente una seconda permutazione P a tutto il blocco. L espansione delle chiavi si basa anch essa su delle permutazioni delle chiavi precedenti. Poiché sono presenti solo semplici operazioni a livello logico permette di ottenere ottimi risultati in termini di velocità (vedi [35]): un implementazione scritta in C++ su un Pentium 200 permette un efficienza di crittografia di 70 Mbit al secondo. 151

158 Sicurezza Informatica A.3 TwoFish e altri Finalista del concorso vinto dal Rijndael è anche un altro algoritmo usato spesso con l IPsec: il TwoFish; realizzato dal team di Bruce Schneier (John Kelsey, Doug Whiting, David Wagner, Chris Hall, e Niels Ferguson), probabilmente il più grande esperto di sicurezza mondiale e autore delle bibbie della crittografia Applied Cryptography e Secrets and Lies. il TwoFish è veloce e versatile poiché usa tavole di sostituzione variabili che dipendono dalla chiave segreta. Il TwoFish è una variante del BlowFish (1993) anch esso sviluppato da Bruce Schneier. Per completezza riportiamo le caratteristiche anche dell ultimo finalista del concorso del NIST: il Serpent. E stato sviluppato da Ross Anderson, Eli Biham e Lars Knudsen; ha performance piuttosto scadenti (se confrontati con TwoFish e Rijndael) poiché i progettisti hanno scelto di utilizzare il doppio delle iterazioni che ritenevano sicure contro gli attacchi attualmente conosciuti. A.4 Crittografia Asimmetrica Introdotta nel 1976 da Whitfield Diffie e Martin Hellman si basa su di una coppia di chiavi: una pubblica e una privata non ricavabili una dall altra (per chiavi maggiori di 512 bit) allo stato attuale dei processori. Il primo algoritmo in assoluto è il Diffie-Hellman, si basa sulla difficoltà dei problemi logaritmici; è solitamente usato per concordare una chiave segreta simmetrica. L algoritmo più usato in assoluto è il RSA (dalle iniziali degli sviluppatori: Ron Rivest, Adi Shamir e Leonard Adelman), si basa sul concetto che è facile calcolare il prodotto di 2 numeri primi molto grandi ma, dato il loro prodotto, è particolarmente difficile risalire ai fattori primi che lo compongono (il problema è NP). Più lunga è la chiave più sicura è la comunicazione, ma più onerosa la cifratura dal punto di vista computazionale; chavi lunghe 256 bit sono attac- 152

159 A.5 SHA e MD5 cabili in alcune settimane, 512 in alcuni mesi e 1024 bit in alcuni secoli (o meglio anni). Tipicamente vengono usate chiavi da 1024 o 2048 bit. Il procedimento di creazione delle chiavi sfrutta alcune proprietà dei numeri primi. Innanzittutto si sceglie una chiave N tale che B = P Q, con P e Q due numeri primi molto grandi, poiché N viene resa pubblica deve essere scelta in modo da essere difficilmente fattorizzabile o meglio non fattorizzabile in un tempo relativamente breve. Viene successivamente calcolaato il valore Z della funzione di Eulero di N, ossia il prodotto di P 1 e Q 1; scelto poi un valore D tale che D e Z siano primi tra loro. A questo punto si deve ricercare un numero E tale che E D mod Z = 1. Il testo in chiaro M viene visto come una sequenza di bit e diviso in blocchi M 1, M 2, M 3... lunghi K bit, dove K è il più grande intero che soddisfa l equazione: 2 K < N. La chiave privata è la coppia (N, D), la chiave pubblica invece è data dalla coppia (N, E). La cifratura in fase di trasmissione avviene nel seguente modo: C i = M i H mod N (A.1) C rappresenta il messaggio cifrato, in fase di ricezione si esegue la decodifica con la chiave privata: M i = C i D mod N (A.2) La sicurezza nel codice RSA risiede nel fatto che non è stato ancora trovato il modo rapido di fattorizzare due numeri primi, ossia trovare P e Q conoscendo N. A.5 SHA e MD5 Tali algoritmi sono detti one-way-hash. Hash perché trasformano un testo in una stringa a lunghezza fissa e one-way perché è facile calcolare tale stringa ma difficile effettuare l operazione inversa. MD5 è sviluppato dalla RSA Data Security inc. e definito nel RFC 1321, è il successore di MD2 e MD4, algoritmi ormai in disuso. Produce hash di 128 bit elaborando blocchi di 512 bit alla volta, per questo usa il padding: 153

160 Sicurezza Informatica si aggiungono un uno seguito da tanti zeri alla fine in modo da ottenere un messaggio lungo un multiplo di bit, infine si aggiungono 64 bit contenenti la lunghezza originale del messaggio (modulo 2 64 ). E probabilmente l algoritmo di hashing più usato. Il SHA è simile all MD4, è stato prodotto dal NIST e della National Security Agency (NSA) del governo degli Stati Uniti. Il messaggio deve essere di lunghezza inferiore a 2 64 bit e viene elaborato a blocchi di 512 bit producendo tipicamente (dipende dalle versioni) un hash di 160 bit. Anch esso uso la tecnica del padding. La versione generalmente usata non è quella originale ma una sua variante, chiamata SHA-1, introdotta per porre rimedio ad alcune vulnerabilità. Altre varianti sono state introdotte per corrispondere alle chiavi da 128, 192 e 256 bit dell AES. Lo sforzo per rompere un algortimo di crittazione con attacco di tipo brute force è 2 lungh.chiave operazioni, ma con un attacco di tipo birthday sono necessari soltanto 2 lungh.hash/2 tentativi, dunque come regola generale si può pensare di assumere che la lunghezza di un hash debba essere il doppio della chiave per avere la stessa resistenza a questo tipo di attacco. SHA-256, SHA-384 and SHA-512 sono progettati per corrispondere dunque all AES rispettivamente di 128, 192 e 256-bit. A.6 Certificato Digitale Un certicato digitale è un statement formato digitalmente da un entità, che assicura l autenticità della chiave pubblica (o di qualche altra informazione) in un altra entità. L entità può essere una persona, un organizzazione, un programma, un computer ecc. I certificati digitali sono stati introdotti soprattutto per la diffusione sicura delle chiavi pubbliche, ricordiamo infatti che molti attacchi alla PKI avvengono modificando la chiave pubblica. L organo che produce i certificati è la Certification Authority, che agisce quindi come terza parte fidata. Lo standard X.509 definisce quali informazioni devono risiedere all interno dei certificati: 154

161 A.6 Certificato Digitale Version: vi sono quattro versioni dello standard; la 1 è nata nel 1988 (è ancora oggi molto diffusa), la 2 nel 1993 (non ha mai avuto una grossa espansione), la 3 nel 1996 e la 4 nel 2001 Serial Number: numero identificativo del certificato Signature Algorithm Identifier: l algoritmo usato per firmare il certificato: può essere RSA o DSA Issuer Name: l entità che ha prodotto il certificato, tipicamente una CA Valid Period: periodo di validità del certificato, espresso come data d inizio e termine, tale valore dipende da molti fattori come ad esempio dal periodo di validità della chiave privata usata per la firma Subject Name: il nome dell entità certificata, si esprime nello standard X.500 (lo stesso quindi di LDAP); un esempio è C=it, ST=pd, L=pd, O=unipd, CN=wirmo dove C indica Country, O Organization, CN Common Name, L per Locality, ST State/Provincia. Subject Public Key Information: la chiave pubblica Issuer Unique Identifier: id univoco per la CA Subject Unique Identifier: id univoco dell ente che deve essere certificato CA Signature: la firma della CA estensioni: campi aggiuntivi della versione 3 usati soprattutto per permettere ad ogni entità di avere più certificati e per avere certificati per finalità differenti I dati nel certificato sono codificati prevalentemente usando lo standard ASN.1/DER (Abstract Syntax Notation 1 / Definite Encoding Rules): l ANS.1 descrive i dati mentre il DER descrive come memorizzare e trasferire le informazioni. Tale combinazione è apprezzata ed odiata allo stesso tempo infatti viene definita powerful and flexible e cryptic and awkward. 155

162 Sicurezza Informatica Per le trasmissioni che non possono gestire dati binari è disponibile lo standard testuale Privacy Enhanced Mail (PEM). Il formato usato nell implentazione del tunnel IPsec è PKCS-12 (chiamato security bag), come detto precedentemente contiene sia la chiave privati che uno o più certificati a chiave pubblica; è usato per il trasporto dell identità digitale di un utente tra applicazione differenti. E molto usato ad esempio nei prodotti Microsoft, Netscape e Lotus ma altrettanto criticato dal punto di vista tecnico per l implementazione. Un ulteriore struttura nella gestione dei certificati è la CRL (Certificate Revocation List) : una lista firmata digitalmente di certificati che sono stati revocati oppure scaduti e che quindi non possono più essere utilizzati. A.7 Importazione certificati Windows XP/2000 Come detto nella sezione l importazione dei certificati nei sistemi operativi Microsoft non è così semplice come in ambiente Linux, dove è sufficiente copiare il certificato nella directory di configurazione di FreeS/WAN. Non basta un semplice doppio click sul file p12 (PKCS12) ma invece si deve usare il tool Microsoft Managment Console (MMC, figura A.3). Le operazioni da eseguire sono le seguenti (sono le stesse sia per Windows XP che per Windows 2000): 1. START Esegui mmc 2. File Aggiungi/Rimuovi Snap-in Aggiungi 3. Certificati Aggiungi Account del Computer Computer Locale Fine 4. Gestione Criteri di Protezione IP Aggiungi Computer Locale Fine 5. Chiudi OK 156

163 A.8 Firme del nuovo millennio Figura A.3: Microsoft Managment Console 6. Certificati (computer locali) Personale Tasto destro mouse Tutte le Attività Importa 7. Avanti Seleziona File Avanti Inserisci Passphrase Avanti Attivare Selezionare automaticamente... Avanti Fine Ora alla macchina è associato il certificato importato, tale certificato può essere gestito tramite gli strumenti di amministrazione di Windows. Si ricorda infine per l installazione del tunnel IPsec è necessario installare almeno il Service Pack 2.0 e i Resource Kit Tool mentre per Windows XP almeno il Service Pack 1.0 e i Support tools. A.8 Firme del nuovo millennio La firma autografata che si fa quando si sottoscrive un contratto non assicura un livello di sicurezza adeguato. Inoltre in ambito digitale è molto difficile il suo utilizzo. 157

164 Sicurezza Informatica Per ovviare a questi e ad altri problemi sono stati introdotte le firme elettroniche. Il decreto della repubblica numero 445 del 28 dicembre 2000 definisce quattro livelli di firma: Art. 1 com.1 let. cc: si intende per firma elettronica ai sensi dell articolo 2, comma 1, lettera a), del decreto legislativo 23 gennaio 2002, n. 10, l insieme dei dati in forma elettronica, allegati oppure connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di autentificazione informatica Art. 1 com.1 let. dd: si intende per firma elettronica avanzata ai sensi dell articolo 2, comma 1, lettera g), del decreto legislativo 23 gennaio 2002, n. 10, la firma elettronica ottenuta attraverso una procedura informatica che garantisce la connessione univoca al firmatario e la sua univoca identificazione, creata con mezzi sui quali il firmatario può conservare un controllo esclusivo e collegata ai dati ai quali si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati Art. 1 com.1 let. ee: si intende per firma elettronica qualificata la firma elettronica avanzata che sia basata su un certificato qualificato e creata mediante un dispositivo sicuro per la creazione della firma Art. 1 com.1 let. n: La firma digitale è un particolare tipo di firma elettronica qualificata basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l integrità di un documento informatico o di un insieme di documenti informatici Possiamo ad esempio pensare ad un paragone con un database (vedi [38]). La firma elettrica corrisponde alle informazioni associate ai dati registrati mediante le associazioni logiche, l utente A abita in via M. Polo, l informazione della via è associata, nel senso della firma elettronica, all utente A. Se introduciamo un chiave di accesso al record [A, via M. Polo] e l unico che conosce la chiave è l utente A allora otteniamo un firma elettronica avanzata. 158

165 A.9 Modelli ISO/OSI e TCP/IP: sicurezza Quando la chiave è generata e garantita da un certificato stabilito nella Comunità europea allora si parla di chiave elettronica qualificata: possiamo immaginare in questo caso che l utente A debba prima recarsi dal certificatore, richiedere ed ottenere una smart card e solo con quella porre le modifiche ai suoi dati nel database. Il paragone con il database termina quando si parla di firma digitale, in questo caso dobbiamo riferirci ad un documento elettronico, tipicamente un file. La differenza sostanziale tra firma digitale e firma elettronica non va vista quindi in funzione della forza della firma ma in base al campo di applicazioni cui ci si riferisce. Si ricorda infine che la firma digitale e la firma elettronica qualificata sone le uniche che hanno validità legale, in realtà regna la più totale confusione anche tra gli organi competenti. Le direttive europere indicano che : il documento informatico, quando è sottoscritto con firma digitale o con firma basata su di un certificato qualificato ed è generata mediante un dispositivo per la creazione di una firma sicura, fa inoltre piena prova, fino a querela di falso, della provenienza delle dichiarazioni da chi l ha sottoscritto A.9 Modelli ISO/OSI e TCP/IP: sicurezza L OSI è organizzato in sette livelli mentre il TCP/IP in quattro. Il TCP/IP è molto più semplice dell OSI ed è organizzato in protocolli, poiché ogni livello indica un protocollo ben definito, mentre l OSI si occupa di definire l architettura e la suddivisione delle entità non specificando nessuna implementazione. Nei capitoli precedenti abbiamo sempre parlato del modello OSI come modello generale di riferimento, in realtà tutte le applicazioni considerate lavorano effettivamente sullo stack TCP/IP. Nel TCP/IP i livelli/protocolli sono: Applicazione: contiene i protocolli di alto livello, come ad esempio HTTP su cui avvengono le comunicazioni dei documenti SOAP Trasporto: flusso di byte bidirezionale tramite un canale virtuale, i dati non sono duplicati e il canale è reso affidabile mediante il controllo 159

166 Sicurezza Informatica Figura A.4: ISO/OSI vs TCP/IP del flusso; ad esempio il protocollo IKE agisce a questo livello mediante l UDP Internet: agisce l IP, scambio di datagrammi senza garanzia di consegna; gestisce i problemi di instradamento e congestione della connessione Host-to-Network: non è specificato nel modello La nostra infrastruttura copre totalmente il modello TCP/IP fornendo un meccanismo di sicurezza per ogni livello: per il livello IP usiamo l IPsec, per il livello trasporto il protocollo TLS e per il livello applicazione usiamo la cifratura dei dati biometrici. L unico livello scoperto rimane quello host-to-network, di cui non ci occupiamo poiché è strettamente legato all hardware. Nella sezione 5.5 abbiamo detto che l IPsec offre la migliore sicurezza disponibile anche se confrontato con i procolli della serie 802.1x, ora abbiamo tutti gli elementi per dimostrare tale affermazione: permette la cifratura con gli algoritmi di nuova generazione: AES e TwoFish 160

167 A.9 Modelli ISO/OSI e TCP/IP: sicurezza usa chiavi dinamiche usa concetti di PKI interoperabilità, permette inoltre una facile estensione ad infrastrutture già esistenti è integrato nell IPv6 tutto il traffico è TCP/IP (o meglio SOAP grazie a web service) e quindi una protezione a livello datalink sarebbe stata superflua 161

168

169 Appendice B Software In questa appendice verranno presentati i software utilizzati per lo sviluppo della tesi. Verranno illustrati inoltre i metodi di installazione e di configurazione. B.1 Java: XML, WS, JNDI Tutti conoscono Java e tutti ammirano le sue caratteristiche: indipendente dalle piattaforme, orientato agli oggetti, garbage collector, sintassi semplice ed elegante, applet. Ma la caratteristica che forse più di tutte ha saputo donare a Java una diffusione capillare è la presenza di librerie sempre complete, ottimamente documentate e sempre al passo con i tempi che implementano cioè in maniera puntuale le nuove tecnologie. In particolar modo ci siamo rivolti alle tecnologie XML e WS, alle JNDI e alle SWING per l interfaccia grafica. Sun ha riunito le proprie tecnologie a supporto dei web service e dell XML all interno del JWSDP (Java Web Services Developer Pack) : Java API for XML Messaging (JAXM): fornisce un modello ad oggetti per la definizione dei messaggi in formato SOAP; permette la realizzazione dei WS nella modalità document-driven Soap with Attachments API for Java (SAAJ): consentono una completa modellazione di un messaggio SOAP complesso 163

170 Software Figura B.1: Java API for XML Processing (JAXP): API per il parsing dei file XML, permette anche di interfacciarsi con un parser esterno come ad esempio Xerces; realizza sia il DOM che il SAX. Java API for XML Registries (JAXR): permettono l interfacciamento con i registri UDDI e ad altre tipologie di servizi, come ad esempio ebxml (Electronic business and XML) Java API for XML-based RPC (JAX-RPC): per costruire web service implementando il modello SOAP-RPC (vedi 6.2.6) Java Architecture for XML Binding (JAXB): permette di effettuare il binding di XML schema ad una rappresentazione di codice Java JavaServer Faces (JSF): permette di realizzare interfacce Web-based dotate di componenti, gestibili con gli eventi JavaServer Pages (JSP): permette di creare pagine HTML dinamiche lato server XML and Web Service Security: vedi Capitolo 8 164

171 B.1 Java: XML, WS, JNDI Tomcat: vedi Appendice B.3 Ant : è un tool di build, è simile al make del C/C++ Non si è usato direttamente questo pacchetto poiché allo stato attuale e con l hardware a disposizione tale scelta sarebbe risultata troppo onerosa dal punto di vista computazionale, si è preferito invece riferirsi ad altre implementazioni (più leggere) degli stessi standard. Si è però fatto riferimento alle guide e alle specifiche del JWSDP. Oltre alle API XML si sono utilizzate le JNDI per l interfacciamento con la directory LDAP, le SWING per la creazione dell interfaccia utente e le JCE (Java Cryptography Extension) per la codifica/decodifica sicura dei dati biometrici. 165

172 Software B.2 Apache Axis Apache Axis (Apache extensible Interaction System) è un prodotto open source nato dalle ceneri di SOAP4J (SOAP for Java) di IBM, implementazione donata al consorzio Apache. Axis non è un semplice SOAP engine ma un framework per realizzare sistemi di integrazione, implementa JAX-RPC, SAAJ e JAXM (in realtà è la prima parziale realizzazione di tale standard). Figura B.2: Axis permette di sviluppare i WS in due modi differenti: tramite lo standard JWS (Java Web Services): che consente di creare WS senza codifica ma inserendo alcuni metatag all interno del codice; nella forma più semplice, è possibile creare una semplice classe Java, rinominarla con l estensione jws, copiarla sotto Tomcat per fare in modo che il runtime di Axis la riconosca e gli crei intorno un infrastruttura dinamica che consente di esporre la classe come servizio tramite i file WSDD (Web Service Deployment Descriptor): sono complementari ai file WSDL e contengono la descrizione dei servizi di cui si 166

173 B.2 Apache Axis vuole effettuare il deploy ; non necessita del codice sorgente ma solo dei file con estensione class. Listato B.1: Semplice esempio WSDD: deploy.wsdd 1 <deployment 2 xmlns=" 3 xmlns:java=" 4 <service name="mioservizio" provider="java:rpc"> 5 <parameter name="classname" value="mioservizio"/> 6 <parameter name="allowedmethods" value="*"/> 7 </service> 8 </deployment> Nel listato B.1 è mostrato un semplice esempio che permette di effettuare il deploy della classe mioservizio e di tutti i metodi in essa realizzati. La procedura d installazione è immediata, è sufficiente disporre del file deploy.wsdd e del file mioservizio.class, posizionarsi nella directory dove è presente quest ultimo ed eseguire java org.apache.axis.client.adminclient deploy.wsdd Axis fornisce molti tool di controllo, management e codifica. Molto utili risultano il TCP monitor e il SOAP monitor che permettono di controllare i messaggi SOAP scambiati tra i due interlocutori durante l esecuzione dei Web Service. Per la codifica invece si può usare WSDL2Java per generare lo scheletro delle classi Java a partire dal file WSDL, oppure Java2WSDL che a partire da un package JAVA genera in automatico il file WSDL. L installazione in se è molto semplice: basta scompattare il file d installazione (contenente le librerie, la documentazione e gli esempi), copiare la directory webapps/axis nella sottodirectory webapps di Tomcat e impostare il CLASSPATH. Digitando sul browser comparirà l homepage di Axis (vedi figura B.3) da cui è possibile ad esempio: validare (controllare) la presenza di tutte le librerie, vedere i servizi disponibili (deployed), usare il SOAP monitor o gli strumenti di amministrazione. Ci sono quattro stili principali di sviluppo dei web service in Axis: RPC, document, wrapped, message. La modalità RPC usa le convenzioni SOAP- 167

174 Software Figura B.3: Amministrazione locale RPC ed è di default in Axis. Document, wrapped e message si rifescono all architettura document-driven introdotta nella sezione Document e wrapped sono simili in quanto non si rifescono al coding SOAP dei dati trasmessi mentre differescono solo per il modo in cui interpretano i messaggi XML. Message permette di ricevere e trasmettere messaggi XML arbitrari nell envelope SOAP. Una funzionalità molto utile di Axis è la possibilità di analizzare il traffico di rete mediante dei tool: TCP monitor e SOAP monitor (figura B.4). Il primo è uno sniffer che cattura tutti i pacchetti TCP con in più la funzionalità di poter raggruppare le coppie di pacchetti request/response ; il SOAP Monitor inoltre aggiunge una comoda interfaccia per la visualizzazione dei messaggi SOAP. Nell engine Axis sono previsti meccanismi basilari di autenticazione tramite l implementazione di un semplice handler. Il consorzio Apache sta sviluppando in parallelo un insieme di librerie per l implementazione degli standard sulla WS-Security introdotti nel capitolo 8 chiamato XML-Security. 168

175 B.2 Apache Axis Figura B.4: SOAP monitor di Axis La maggior parte delle volte il non funzionamento del framework Axis non dipende dalle librerie in sè ma dalla configurazione degli altri pacchetti da cui dipende: Tomcat ed Apache Web Server quindi vanno settati correttamente. Opinione del sottoscritto è che debba essere migliorata la gestione delle librerie ad esempio prevedendo un tool per il caricamento, infatti nelle normali applicazioni la variabile globale CLASSPATH contiene decine di riferimenti. 169

176 Software B.3 Jakarta Tomcat L inventore di Tomcat (e anche di Ant) è James Duncan Davidson: un vero e proprio visionario dell informatica. Tomcat fa parte del progetto della Apache Software Fondation chiamato Jakarta; è un application server e in particolare l implementazione di riferimento per le specifiche delle servlet Java e delle JSP. Può essere usato da solo o assieme ad un web server; nella nostra infrastruttura si è impiegato in coppia con Apache HTTP Server versione Figura B.5: L installazione è molto semplice anche per Tomcat: bisogna porre solo attenzione al setup corretto della variabile CLASSPATH; esistono poi comodi script di avvio e chiusura del server sia per ambienti Microsoft che Linux. Ad installazione terminata digitando compare la home page di amministrazione di Tomcat (figura B.6). Particolarmente importante è la struttura delle directory, in quanto si deve permettere la corretta interazione con Axis: nella directory conf andranno settati i file di configurazione (ad esempio della sessione SSL/TLS ), nella directory lib andranno poste le librerie Java e all interno della directory 170

177 B.3 Jakarta Tomcat Figura B.6: Amministrazion Tomcat webapps saranno posti i WS e file WSDL. E richiesto per l uso dei WS l installazione di un parser XML: la nostra scelta è caduta su Xerces, anch esso sviluppato dal consorzio Apache. Il successo di Tomcat è imputabile a vari fattori, sicuramente uno dei più importanti è l attenzione riguardo alle problematiche sulla sicurezza. Assicura in modo semplice il supporto SSL/TLS e l uso dei Realm AAA vale a dire permette di connettersi a database di utenti (username+password) per autorizzare o meno l uso di una particolare applicazione web. Si può appoggiare a database relazionali, a JDBC (Java Database Connectivity), a directory LDAP, a MemoryRealm (file XML) ed a infrastrutture JAAS (Java Authentication and Authorization Service). 171

178 Software B.4 Linux FreeS/Wan FreeS/WAN è nato da un idea di John Gilmore: Given the current rampage of Federal cops, it is even more important that honest citizens and businesses protect themselves from wiretapping, by deploying good encryption both in your own systems, and for communication with anyone else. If we can secure 5% of the traffic this year, we can secure 20% next year; and 80% two years out. The whole Internet will have been secured. Per le caratteristiche implementative di FreeS/WAN rifersi alla sezione 5.2. Figura B.7: La difficoltà dell installazione di FreeS/WAN dipende dalla distribuzione di Linux a causa della necessità di ricompilare e patchare il kernel più volte anche per piccole modifiche. Leggermente ostica (per un neofita) risulta l installazione per Debian, Gentoo, Slackware, agevole per RedHat grazie al supporto nativo per gli RPM (Red Hat Package Manager). Una prima ricompilazione del kernel riguarda l inserimento del modulo KLIPS, da notare come negli ultimi kernel non sia ancora implementato il 172

179 B.4 Linux FreeS/Wan supporto per le estensioni di sicurezza del protocollo IPv6: questa situazione appare piuttosto paradossale poiché alcune applicazioni usano già IPv6 ma sono impossibilitate nell usare IPsec. Una seconda ricompilazione rigurada invece il supporto per i protocolli di cifratura AES e della famiglia Fish. Anche questa situazione appare piuttosto surreale poiché AES è uno standard affermato dal 2001, ciò conferma come in sistemi Linux e Windows la sicurezza non rappresenti un aspetto fondamentale in fase di progettazione. Oltre al file ipsec.conf, di cui si è parlato ampiamente nel capitolo 5, fondamentale è il file ipsec.secrets che contiene le chiavi RSA o elementi per l autenticazione fra host; altri file come certificati e revocation list devono stare nella directory /etc/ipsec.d/. La correttezza dell installazione e della configurazione può essere accertata con l utility ipsec (figura B.8). Figura B.8: Ipsec verify 173

180 Software B.5 OpenLDAP OpenLDAP è l implementazione open source di LDAP più diffusa per server UNIX-like. OpenLDAP implementa la versione 2 e 3 dello standard (RFC e ), SSL/TLS (RFC 2829, per l accesso sicuro), DNSbased service location (RFC 2247), LDIF (RFC 2849). Supporta inoltre la distruzione dei carichi di lavoro, la replica delle informazioni ed assicura brevi tempi di risposta alle richieste di interrogazione. Figura B.9: Il server LDAP è gestito da due demoni: slapd e slurpd. Lo slapd è il server che gestisce le richieste dei client (può essere in esecuzione su più macchine), mentre lo slurpd garantisce la consistenza delle informazioni tra le istanze di slapd. La gestione del demone slapd avviene tramite il file slapd.conf, tale file è diviso in tre sezioni: global: include gli schemi, definisce le ACL (Access Control List), direttive di debugging e di amministrazione backend: contiene direttive per i pacchetti a supporto di openldap (come SQL, Perl, BerkleyDB ecc.) 174

181 B.5 OpenLDAP database: specifica dove sono memorizzate le directory, l utente amministratore di ogni directory, l eventuale mirroring (replica) e le ACL locali Nel listato B.2 sono mostrate le poche aggiunte al file di configurazione slapd.conf nel nostro server; si nota il nodo radice (dc=conmo, dc=com), l amministratore root anch esso inserito come una entry della directory, lo schema usato, il tipo di database, la directory fisica (nel senso classico) dove è memorizzato e gli indici di ricerca veloce. Listato B.2: Slapd.conf 1 include /etc/openldap/schema/carpet.schema 2 3 database ldbm 4 suffix "dc=conmo,dc=com" 5 rootdn "cn=root,dc=conmo,dc=com" 6 rootpw {SSHA}gsRP0R82oy2N82DjCiGj5uWztnRubfbP 7 directory /var/lib/ldap 8 9 index usernamecarpet eq La gestione delle directory può avvenire tramite i file LDIF e i tool offerti da OpenLDAP (ldapadd, ldapsearch, ldapdelete, ldapmodify... ) oppure tramite le API di Java. E molto utilizzato il modulo PAM per l autenticazione, in questo caso la directory viene usata per la gestione delle login al posto del datato NIS. Ottima inoltre è l interoperabilità con le Active Directory di Microsoft. 175

182 Software B.6 Strumenti di rete B.6.1 Ethereal Ethereal è un analizzatore di rete sotto licenza GPL che si appoggia principalmente sulle librerie libpcap (tcpdump) creato da Gerald Combs. Permette l analisi catturando (sniffando) i dati dalla rete, rappresenta uno strumento essenziale per ogni amministratore. Figura B.10: Supporta numerosi protocolli tra cui: , AH, ASN.1, DHCP, DNS, ESP, GPRS, GSM, HTTP, ICMP, IPv6, ISAKMP, Kerberos, LDAP, NFS, PPP, RADIUS, SSL, UDP, TCP, TELNET. Nella lista completa della versione (rilasciata il 13 dicembre 2003) il supporto è di 442 protolli. Ethereal consente due livelli di filtri: in fase di cattura e in fase di visualizzazione; supporta tale caratteristica anche con un linguaggio di scripting derivato dalla sintassi dello storico Berkeley packet filter. 176