Capitolo 3. La sicurezza La fiducia. Capitolo 3 - Sicurezza: la fiducia

Transcript

1 Capitolo 3 - Sicurezza: la fiducia Capitolo 3 La sicurezza 3.1. La fiducia Ci sono tanti e diversi modi di descrivere la fiducia: nel contesto dell e-commerce e della sicurezza dei sistemi informatici, si potrebbe definire la fiducia principalmente come l aspettativa o la convinzione che la controparte di una transazione si comporterà in accordo ad una data politica e senza intenti criminali; la fiducia nei sistemi, invece, si potrebbe definire come l aspettativa o la convinzione che essi siano robusti, affidabili e resistenti di fronte agli attacchi. La fiducia è quindi essenzialmente una convinzione e si assume che sia basata sull evidenza, sull esperienza e sulla percezione. Nel mondo fisico la fiducia nelle cose e in altre persone è basata sull esperienza, sull apparenza e sulle informazioni raccolte: tutti questi aspetti evidenziano il fatto che la fiducia è un fenomeno molto soggettivo. Un altra caratteristica del mondo fisico è che il numero di persone con cui si può entrare potenzialmente in relazione è limitato dalla distanza e da altri limiti fisici, mentre su Internet il limite è rappresentato solo dal numero di persone on-line in quel momento: la sfida è quella di riuscire a stabilire la fiducia in ambito informatico. Il partner di una transazione può essere qualcuno che si è già conosciuto, ma nella maggior parte dei casi sarà qualcuno totalmente sconosciuto e con il quale non si è mai interagito prima: le decisioni sulla fiducia devono essere basate su tutte le evidenze e le informazioni che possono essere raccolte, perciò l atto di decidere se fidarsi o no può essere definito come l attività di collezionare, codificare, analizzare e presentare evidenze rilevanti con l obiettivo di prendere decisioni. La chiave della sicurezza è la fiducia. Sia per uno sviluppatore sia per un fornitore di servizio, l obiettivo è quello di garantire il più alto grado di sicurezza possibile, in modo tale che l utente possa essere sicuro del fatto che le informazioni inviate e ricevute siano e si mantengano private e veritiere; in una forma o nell altra, comunque, ogni sistema di sicurezza si basa sulla fiducia tra gli utenti di quello stesso sistema. Esistono differenti forme di fiducia, a seconda dei problemi da affrontare e dei rischi da limitare, perciò la scelta su quale forma di fiducia applicare viene determinata da scelte politiche. In particolare esistono due importanti forme di fiducia che gli utenti di un sistema che implementa la sicurezza devono essere in grado di capire: fiducia-nella-terza-parte (third-party trust) o indiretta e fiducia personale o diretta. Cerchiamo di capire questi concetti e fornire alcune informazioni addizionali. 1

2 Fiducia indiretta Capitolo 3 - Sicurezza: la fiducia Chris Figura 3.1: fiducia-nella -terza-parte. Il concetto di fiducia indiretta (third-party trust) si riferisce ad una situazione nella quale due individui (Alice e Bob in Figura 3.1) si fidano implicitamente l uno dell altro, anche senza aver precedentemente stabilito una relazione personale: in questa situazione la reciproca fiducia può sussistere, perché entrambi conoscono direttamente il medesimo terzo individuo (Chris in Figura 3.1) e quel terzo individuo garantisce ognuno dei due sulla affidabilità dell altro. La fiducia-nella-terza-parte è un requisito fondamentale per qualsiasi implementazione su larga scala di un sistema di sicurezza basato sulla crittografia a chiave pubblica, che prevede, cioè, l accesso alle chiavi pubbliche degli utenti (nel paragrafo 3.2 si spiegherà in modo approfondito il concetto di chiavi e crittografia). Infatti, in una rete su larga scala, è impraticabile e irrealistico aspettarsi che ogni individuo abbia preventivamente stabilito relazioni con tutti gli altri; inoltre, per il fatto che le chiavi pubbliche devono essere disponibili per tutti, l associazione tra una chiave pubblica e una persona deve essere garantita da una terza parte assolutamente affidabile e irreprensibile, per prevenire travestimenti. In effetti, gli utenti si fidano implicitamente di una qualsiasi chiave pubblica certificata dalla terza parte, perché l organizzazione di quest ultima è proprietaria e mantiene in modo sicuro l associazione tra la certificazione e l oggetto della fiducia. In generale, l agente di certificazione viene chiamato Certification Authority (CA): si tratta di un entità la cui principale responsabilità è quella di certificare l autenticità degli utenti e può essere vista come analoga allo Stato che emette passaporti e carte di identità (identità cartacee). Ogni altro Stato che si fidi dell autorità del primo si fiderà anche del passaporto dell utente: questo è un buon esempio di fiducia-nella-terza-parte. Similmente ad un passaporto, l identità elettronica di un utente, emessa per lui da una CA, è la prova che l utente ha del fatto che una CA si fida di lui; per questo, attraverso la fiducia-nella-terzaparte, chiunque ritenga la CA affidabile dovrebbe anche fidarsi dell utente, per una sorta di proprietà transitiva. Sia l ufficio di emissione passaporti sia la CA sono una combinazione di strutture fisiche di controllo: nel caso dell ufficio passaporti ci sono una serie di controlli fissati dall ordinamento giudiziario, che stabiliscono quali persone sono cittadini rispettabili e le modalità per ottenere un passaporto; similmente, una CA può essere pensata come un gruppo di persone facenti parte di una organizzazione, le quali determinano le politiche di sicurezza sulla rete e decidono quali individui possono ricevere identità elettroniche, cioè certificati. 2

3 Fiducia diretta Capitolo 3 - Sicurezza: la fiducia Il concetto di fiducia diretta si riferisce ad una situazione nella quale due individui hanno stabilito una relazione di fiducia direttamente tra loro, senza intermediazioni (Bob e Bill in Figura 3.2). Mentre la fiducia-nella-terza-parte permette agli individui di fidarsi implicitamente l uno dell altro senza prima aver stabilito alcuna relazione personale, la fiducia diretta si basa sulla conoscenza reciproca, prima dello scambio di informazioni delicate. Per la sicurezza sulla rete è richiesta la fiducia diretta quando individui provenienti da domini separati (dominio P e dominio Q in Figura 3.2) si scambiano informazioni sulle chiavi per rendere sicure le comunicazioni, poiché le rispettive CA non hanno stabilito una relazione di fiducia attraverso una certificazione incrociata. Senza una fiducia diretta, in questo scenario lo scambio di chiavi non avrebbe alcun valore, perché l informazione sulla chiave stessa potrebbe essere non affidabile (non la chiave in sé, ma i dati del proprietario). Figura 3.2: fiducia diretta tra individui. Quando si applica la fiducia diretta per rendere sicure le comunicazioni, solamente la responsabilità di ognuna delle parti può dare una qualche garanzia: se si sceglie questa strada significa, probabilmente, che ognuna delle parti ritiene che la fiducia personale sia sufficiente per il tipo di operazioni che si stanno portando avanti. Comunque, quando è presente la fiducia diretta, lo scambio di chiavi tra individui con un rapporto personale fornisce un potente meccanismo per assicurare comunicazioni sicure. Vedremo di seguito, però, che servono ben altre tecniche, tanto nel mondo del wired Internet quanto in quello del wireless Internet Fondamento della validità dei certificati Il certificato di un utente della rete è l equivalente elettronico del suo passaporto e, in quanto tale, un certificato contiene informazioni sicure che possono essere usate per verificare l identità del proprietario: per esempio il certificato ne contiene il nome, ma soprattutto la chiave pubblica, che rappresenta la parte critica di informazione per quanto riguarda la sicurezza. Volendo affrontare il problema in termini di fiducia, ci sono due aspetti centrali in relazione ai certificati. Il primo riguarda la credibilità dell informazione contenuta nel certificato. Come si può pretendere che una persona si fidi del fatto che il nome e la chiave pubblica contenuti in un certificato appartengano veramente a chi dichiara di esserne il proprietario? Come si può essere sicuri che il certificato non sia stato falsificato? Senza questo tipo di credibilità, la crittografia a chiave pubblica crollerebbe come un castello di carte, perché nessuno sarebbe sicuro di crittografare dati per la persona giusta, mentre un certificato sarebbe 3

4 Capitolo 3 Sicurezza: fondamento della validità dei certificati completamente inutile se non si potesse associarlo ad un preciso individuo. Allora, per stabilire un rapporto di fiducia, deve esserci un intermediario, la CA, che appone la propria firma digitale al certificato, garantendo così l integrità, l autenticazione e il non ripudio dello stesso (questi concetti saranno approfonditi tra breve, nel paragrafo 3.2 dedicato alla sicurezza). Dopo aver appurato che un certificato è reso credibile dalla firma digitale della CA, il secondo aspetto che porta a fidarsi di un certificato riguarda il lecito dubbio sulla credibilità della CA in sé stessa. Se, come prima, si mette in relazione di analogia questo scenario con quello del mondo burocratico e giuridico, il corretto parallelo si potrebbe fare su fino a che punto ci si può fidare dell ufficio che ha emesso il passaporto. Si prenda l esempio di un cittadino che entra nello Stato A presentando un passaporto apparentemente valido emesso da un ufficio dello Stato B: gli ufficiali dello Stato A ospite dovranno valutare la credibilità dell ufficio passaporti dello Stato B, facendo riferimento ad una lista correntemente valida di Stati affidabili, redatta da un gruppo di sorveglianza a livello superiore, che rientri, comunque, nei limiti di controllo dell agenzia. Figura 3.3: fiducia-nella -terza-parte estesa attraverso la certificazione incrociata. L analogia con la lista di Stati affidabili, nel contesto della sicurezza delle reti, è riferita come dominio di certificazione incrociata tra CA. La certificazione incrociata è un processo grazie al quale due CA si scambiano, in modalità sicura, informazioni sulle reciproche chiavi, in modo tale che ognuna delle due possa effettivamente certificare la credibilità della chiave dell altra. Essenzialmente, la certificazione incrociata è una forma estesa di fiducia-nella-terza-parte, nella quale gli utenti appartenenti ad una rete nel dominio di una CA si fidano implicitamente di tutti gli utenti appartenenti ai domini di altre CA certificate in modo incrociato con la propria CA. Da una prospettiva tecnica, la certificazione incrociata coinvolge la creazione di certificati incrociati tra due CA: quando la CA X e la CA Y (in Figura 3.3) si certificano l un l altra, in modo incrociato, la CA X crea e firma un certificato contenente la chiave pubblica della CA Y, e viceversa. Di conseguenza, gli utenti appartenenti ad entrambi i domini sono garantiti sul fatto che le relative CA si fidano l una dell altra; per questo gli utenti di un dominio si possono fidare di quelli dell altro attraverso una fiducia-nella-terza-parte estesa. Ci sono, naturalmente, molti più accordi da prendere nella certificazione incrociata tra CA, piuttosto che nei dettagli tecnici che hanno a che fare con lo scambio sicuro di chiavi ed informazioni analoghe tra utente e CA (cosa, in sé, abbastanza facile da realizzare). In quanto la certificazione incrociata estende la fiducia-nella-terza-parte, è importante, per ogni dominio CA, essere completamente sicuro delle strutture di sicurezza degli altri partner. Riprendendo un ennesima volta il parallelo del passaporto, sarebbe inverosimile che uno Stato dichiarasse di avere fiducia nel passaporto emesso da un altro Stato senza prima esaminarne a fondo la politica adottata per creare e distribuire passaporti ai cittadini. Per esempio, prima di stabilire un rapporto di 4

5 Capitolo 3 Sicurezza: fondamento della validità dei certificati fiducia, ogni Stato vorrà sicuramente capire in modo dettagliato il processo con il quale la controparte verifica l identità di un cittadino prima di conferirgli un passaporto. Analogamente si presentano le cose quando si creano certificazioni incrociate tra diversi domini CA: per esempio, prima di procedere, entrambi i domini CA vorranno conoscere le altrui politiche di sicurezza, specialmente le modalità di accesso alle funzioni di manipolazione della sicurezza all interno del dominio. È anche verosimile che gli accordi legali vengano firmati dai rappresentanti di entrambi i domini: questi accordi dovrebbero precisare le politiche di sicurezza richieste in entrambi i domini e fornire una garanzia controfirmata che le direttive saranno messe in pratica Responsabilità di una CA Una CA può anche emettere un certificato per un altra CA. Nell analisi di un particolare certificato, può sorgere il bisogno di esaminare anche il certificato dell emissario, eventualmente in modo ricorsivo per ogni CA madre, fino a raggiungere quella in cui riporre completa fiducia: si può anche scegliere di fidarsi solamente di certificati con una catena limitata di emissari, per ridurre il rischio di incontrare un anello debole (tutto ciò è generalmente trasparente all utente finale che, nella maggioranza dei casi, non avrebbe la preparazione per comprendere ciò che avviene). Ogni certificato richiede un emissario che asserisca la validità dell identità del possessore del certificato stesso e ogni emissario richiede un altro emissario che asserisca l affidabilità del primo, fino ad arrivare al livello di CA che ispiri fiducia, oppure al livello root, cioè alla radice dell albero delle CA (possono esistere diverse root per diverse strutture ramificate di certificati). Qui sorge un problema: chi garantisce la validità del certificato della CA al livello root, che per definizione non ha emissari? In questo caso particolare il certificato è auto-assegnato, in modo tale che l emissario del certificato ne sia anche il soggetto. Come risultato vediamo che l utente finale deve porre una grande attenzione nello scegliere un certificato auto-assegnato, ma comunque la pubblicazione in grande stile e con molta pubblicità della chiave pubblica della CA di livello root dovrebbe ridurre il rischio: sarebbe facilissimo individuare un impostore che pubblicizzasse la propria chiave proclamando di essere una CA a livello root. Fondare una CA, anche non a livello di root, rappresenta comunque una grossa responsabilità, che richiede una struttura interna estremamente solida dal punto di vista amministrativo, tecnico e gestionale; le CA non hanno solamente il compito di emettere certificati, ma anche quello di gestirli: questo significa anche decidere per quanto tempo i certificati saranno validi, significa doverli rinnovare e mantenere delle liste di certificati già emessi, ma non più validi (Certificate Revocation List, o CRL). Per capire la funzione delle CRL, si provi ad immaginare un generico client, titolare di un certificato in quanto impiegato di un azienda; si immagini anche che questo stesso certificato debba essere revocato quando l impiegato lascia la compagnia: poiché i certificati sono documenti che vengono distribuiti pubblicamente, non è possibile stabilire, a partire dal certificato in sé, se questo sia stato revocato oppure no. Per essere sicuri della validità del certificato, quindi, è necessario contattare la CA che lo ha emesso, per procedere con il controllo delle CRL. Si è parlato tanto e tanto si parlerà di certificati: a titolo di esempio si presenta qui un esempio di certificato crittografato, per avere almeno un idea del suo aspetto: -----BEGIN CERTIFICATE----- MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUGA 1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTE VMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBzbmFrZW9pb C5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzELMAkGA1UEB hmcwfkxftatbgnvbagtdfnuywtlierlc2vyddetmbega1uebxmku25ha2ugvg93bje XMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNlcnZlciBUZWFtMR 5

6 Capitolo 3 Sicurezza: responsabilità di una CA kwfwydvqqdexb3d3cuc25ha2vvawwuzg9tmr8whqyjkozihvcnaqkbfhb3d3dac25ha2 VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDH9Ge/s2zcH+da+rPTx /DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8bvKR+yy5DGQiijsH1D/j8HlGE+q4TZ 8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaalWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2D LbCTzLZyPwIDAQABoyYwJDAPBgNVHRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQ QEAwIAQDANBgkqhkiG9w0BAQQFAAOBgQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1 v1kl8mqr+kfjghcrtpqaztzqcdt2q2qoyulcgszhbegmi0esdkpfg6mp0penssifepyni+/8u9ht4 LuKMJX15hxBam7dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== -----END CERTIFICATE La sicurezza Poniamo il caso di un consumatore che desideri comprare qualcosa su Internet, oppure quello di un uomo d affari che cerca di vendere qualcosa su Internet (queste transazioni, come già specificato nel capitolo introduttivo, sono comunemente chiamate e-commerce): questi due casi estremi enfatizzano la necessità di utilizzare comunicazioni sicure. A questo scopo viene usata, ormai da qualche anno, la tecnologia Secure Sockets Layer (SSL) per garantire una via sicura tramite la quale trasmettere informazioni delicate, come quelle riguardanti acquisti con carta di credito, operazioni di borsa, invio e ricezione di , trasmissione dei risultati di esami medici ed altre informazioni strettamente personali. In poche parole, SSL è una tecnologia che permette il trasferimento sicuro di informazioni su Internet: consiste in un software installato su browser e server, che si può facilmente ottenere sottoscrivendosi ad un Secured Service Provider (SSP) come SSL.com, VeriSign, Entrust, Infinite Technologies, oppure ottenendo da esso un Seller s Certificate ed installandolo su un server sicuro preesistente; probabilmente, comunque, una parte di esso è già contenuta sia nel Web browser sia nel Web server, a priori: infatti, tutti i maggiori browser e server sono abilitati alla gestione di SSL. La tecnologia SSL è stata sviluppata dalla Netscape Communications Corporation ed è diventata presto la modalità industriale standard per proteggere le comunicazioni sul Web: si tratta di un livello di protocollo che può essere posizionato tra un protocollo di rete affidabile e connection oriented (ad esempio TCP/IP) ed un protocollo a livello di applicazione (ad esempio HTTP): SSL garantisce una comunicazione sicura tra client e server, tramite una mutua autenticazione, con l uso delle firme digitali per l integrità e della crittografia per la privacy; è progettato per supportare una rosa di specifici algoritmi crittografici, sia per il sunto matematico (digest) sia per le firme digitali, permettendo di sceglierne di particolari per server specifici, ma anche di supportare eventuali nuovi algoritmi: le varie decisioni su quali algoritmi utilizzare sono prese durante la negoziazione tra il client e il server all inizio della sessione sicura. Un protocollo è, essenzialmente, un insieme di regole e procedure ed, in quanto tale, SSL applica ad un messaggio una serie di operazioni che lo manipolano facendogli apparentemente perdere significato: queste operazioni sono portate avanti in modo che il messaggio non possa essere letto mentre viene trasferito, o meglio: se anche fosse intercettato durante la trasmissione, risulterebbe completamente incomprensibile per chiunque, escluso il reale destinatario. Quando il messaggio raggiunge il ricevente giusto, SSL si incarica di riportarlo al suo aspetto originale, controllando che provenga dal mittente corretto (autenticazione) e che non sia stato modificato nel frattempo (integrità) I quattro concetti base Il primo passo da compiere per capire la modalità di funzionamento del modello di sicurezza WAP (WTLS) è indagare come SSL renda l e-commerce sicuro su Internet. Le soluzioni per la garanzia della sicurezza oggi disponibili mantengono l informazione inaccessibile ad individui che non devono conoscere determinati dati confidenziali o finanziari, 6

7 Capitolo 3- Sicurezza: i quattro concetti base proteggono informazioni critiche che potrebbero essere usate contro una corporazione o per generare delle transazioni fraudolente, ma soprattutto portano serenità, in quanto permettono a singoli individui ed intere istituzioni di condurre i propri affari e di scambiarsi informazioni on line senza alcuna preoccupazione. Sono quattro i concetti base che un servizio di sicurezza deve rispettare: Privacy: la privacy assicura che solamente il mittente ed il ricevente di un messaggio crittografato possano leggerne i contenuti; per garantire la privacy, una soluzione sicura deve, quindi, fare in modo che nessun altro possa vedere, accedere o altrimenti usare le informazioni private trasmesse tramite Internet, che potrebbero essere indirizzi, numeri di carte di credito, numeri di telefono, ecc. Integrità: l integrità assicura la rilevazione di qualsiasi cambiamento nel contenuto di un messaggio, tra l istante in cui viene inviato e l istante in cui viene ricevuto: per esempio, quando un utente ordina alla propria banca di trasferire $ 1000 da un conto ad un altro, l integrità garantisce che i numeri di conto e l ammontare della somma non possano essere alterati senza che la banca o l utente se ne accorgano; se il messaggio dovesse essere alterato in un qualsiasi modo durante la trasmissione, il sistema di sicurezza deve assolutamente avere un modo per scoprire e notificare l alterazione: in molti sistemi, quando viene riscontrata una alterazione, il sistema di ricezione impone la ritrasmissione del messaggio. Autenticazione : l autenticazione assicura che tutte le entità coinvolte in una comunicazione siano in effetti chi dichiarano di essere: l autenticazione del server dà modo agli utenti di verificare di essere effettivamente in comunicazione con il sito Web con cui sono convinti di essere connessi, mentre l autenticazione del client assicura che quest ultimo sia proprio chi dichiara di essere. Anche nel mondo reale esistono esempi di autenticazione: la presentazione di una patente di guida o di una carta di identità garantisce che l acquirente che firma un assegno è proprio la persona nominata su quell assegno, mentre la presentazione di un distintivo o di una tessera di riconoscimento dell azienda dei telefoni, con annessa foto identificativa, garantisce che la persona che si presenta alla porta è veramente l addetto del telefono e questi sono solo alcuni dei tanti possibili esempi. Non ripudio (o non disconoscimento): il non ripudio fornisce un modo per garantire che una parte coinvolta in una transazione non possa poi in seguito falsamente dichiarare di non aver mai partecipato alla transazione stessa; nel mondo reale questa funzione è svolta dalle firme apposte a mano in calce ai documenti: quando un acquirente stacca un assegno, presentando la patente di guida o la carta di identità assicura la controparte sulla propria identità (autenticazione), mentre la firma sull assegno assicura per il futuro che il firmatario fosse di fatto presente e acconsentisse sull importo e sul destinatario dell assegno stesso (non ripudio). Nel mondo Internet, il protocollo SSL, i certificati digitali e la coppia username/password sono usati in concomitanza per fornire tutti e quattro i livelli di garanzia sopra citati Tecniche crittografiche SSL comprende diverse tecniche crittografiche, qui elencate per sommi capi e poi spiegate in modo approfondito. Crittografia con coppia di chiavi: la crittografia con coppia di chiavi (pubblica e privata) è il metodo crittografico cruciale di SSL: utilizza due chiavi e sofisticati algoritmi matematici per convertire un testo in chiaro in una serie di dati crittografati e viceversa. La coppia di chiavi consiste in una chiave pubblica e registrata, disponibile per chiunque, e in una chiave privata tenuta rigorosamente segreta dal suo proprietario: un messaggio crittografato con la chiave pubblica può essere decrittografato solamente da qualcuno in possesso della corrispondente chiave privata (questo è fondamentale per la privacy); analogamente, un messaggio crittografato con la chiave privata può essere decrittografato solamente da 7

8 Capitolo 3 - Sicurezza: tecniche crittografiche qualcuno in possesso della corrispondente chiave pubblica (questo è fondamentale per l autenticazione con firma digitale). La crittografia con chiave pubblica usa algoritmi molto avanzati per crittografare una piccola quantità di informazioni, mentre non è applicabile per quantità di dati più rilevanti. Algoritmi di bulk encryption: esistono, per contro, algoritmi di bulk encryption (bulk = massa, grande quantità) che usano solamente una chiave segreta e condivisa (bulk key) tra i due comunicanti per crittografare i messaggi: questi algoritmi sono estremamente difficili da decodificare quando la bulk key contiene un elevato numero di bit. Combinazione delle due tecniche: SSL utilizza, allora, la crittografia con coppia di chiavi per scambiare tra il client e il server la bulk key, nelle primissime fasi di una conversazione sicura in Internet, assicurando così che suddetta chiave rimanga segreta per tutta la durata della conversazione; poi si serve di questa chiave per crittografare la parte veramente sostanziale dei dati, cioè le informazioni che rivestono importanza per i due comunicanti e che devono essere scambiate. SSL utilizza la crittografia con coppia di chiavi e gli algoritmi di bulk encryption per garantire la privacy in Internet. Algoritmi di hashing: SSL usa algoritmi di hashing per creare una piccola impronta digitale, matematicamente generata, di un messaggio: se una qualsiasi parte del messaggio viene alterata, la sua impronta nuovamente generata a partire dal messaggio ricevuto non coinciderà più con la prima, quando il messaggio verrà controllato dal ricevitore: in questo caso viene richiesto al mittente la ritrasmissione. Questo è il modo con cui SSL garantisce l integrità La crittografia simmetrica La crittografia è la scienza di occultare le informazioni. Per gran parte della storia dell uomo è esistita solo una forma molto pratica e semplice di crittografia: la crittografia simmetrica. Un esempio di crittografia simmetrica è quella usata da Giulio Cesare, che spostava semplicemente in avanti ogni lettera di un messaggio di un certo numero di lettere, secondo l alfabeto. Per esempio, spostando ogni lettera di tre posti in avanti, potremmo cifrare un messaggio in questo modo: Questo è il messaggio, ottenendo: Tahvzr h no phvvdllnr. In questo caso, il testo Tahvzr h no phvvdllnr viene chiamato testo cifrato e il numero 3 (il numero di posti di cui ogni lettera è stata spostata) è la chiave: chi riceve il testo cifrato deve conoscere la chiave, cioè il numero 3 (per sapere di dover spostare di 3 posti indietro le lettere). Questo tipo di cifratura è ovviamente molto debole (ci sono solo 26 possibili chiavi), ma è molto utile per spiegare a cosa assomiglia una cifratura simmetrica: è simmetrica perché chiunque conosca la chiave per crittografare (muovere avanti le lettere di tre posti) conosce anche la chiave per decrittografare (spostare indietro le lettere di tre posti) e viceversa; tutte le cifrature simmetriche hanno questa proprietà, anche se con quelle attuali si ha la possibilità di scegliere tra molte più chiavi di quante ne avesse a disposizione Giulio Cesare La crittografia asimmetrica Fino a poco tempo fa, si era soliti usare questa tecnica di crittografia simmetrica per rendere sicura la trasmissione delle informazioni attraverso la rete pubblica, ma il problema consisteva nel fatto che la chiave, per essere nota ad entrambi, doveva essere trasmessa dall uno all altro in una trasmissione separata, rendendola vulnerabile al furto durante il passaggio. Durante la seconda guerra mondiale, le spie e le loro basi dovevano condividere un libro di codici; più tardi gli scienziati svilupparono hardware specializzato che poteva operare all interno di scatole a prova di intromissione, spostato da luogo a luogo da corrieri fidati. Una volta che entrambe le parti conoscevano la chiave, potevano comunicare in modo sicuro ogniqualvolta lo desiderassero, ma stabilire la chiave all inizio era dispendioso e rischioso. La crittografia simmetrica rendeva possibile una comunicazione sicura tra persone che veramente ne avessero le possibilità economiche e i 8

9 Capitolo 3 - Sicurezza: tecniche crittografiche mezzi (i governi, i militari, grosse istituzioni finanziarie), ma non sarebbe mai diventata abbastanza semplice da utilizzare per le persone comuni. Più in particolare, supponendo di avere solo questo metodo di crittografia simmetrica, in cui il client e il server conoscono entrambi la chiave A, sorgono numerosi altri problemi: oltre al fatto che il client deve trovare un modo sicuro di trasmettere la sua chiave segreta al server (se la chiave segreta venisse intercettata, tutte le trasmissioni del client sarebbero compromesse), il client deve a maggior ragione potersi fidare del server, per il fatto di usare sempre la medesima chiave: se il server fa il doppio gioco, potrebbe dare la chiave segreta a qualcun altro, leggere altri messaggi privati del client non indirizzati a lui dopo averli intercettati e addirittura spacciarsi per il client! Inoltre, nel caso di un organizzazione con persone che hanno bisogno di scambiarsi messaggi segreti, ci sarebbe bisogno di tenere memorizzate migliaia (per non dire milioni) di chiavi segrete, oppure utilizzarne meno (tipo passpartout), compromettendo la sicurezza. Negli ultimi anni 70, tre accademici di Stanford ebbero una brillante idea: Whitfield Diffie, Martin Hellman e Ralph Merkle si chiesero cosa sarebbe successo se il fatto di conoscere la chiave per crittografare non significasse conoscere automaticamente la chiave per decrittografare. Cosa succederebbe se fosse così difficile trovare la chiave per decrittografare a partire da quella per crittografare da poter tranquillamente pubblicare quest ultima di fronte al mondo intero? In questo modo chiunque voglia comunicare con una persona in particolare potrebbe cercare la sua chiave pubblica, con essa crittografare il messaggio e quindi inviarlo: solamente quella persona conoscerebbe la corrispondente chiave per decrittografare e nessun altro potrebbe leggere il messaggio, anche conoscendo la chiave pubblica. Questa fu la geniale idea della crittografia a chiave pubblica, basata essenzialmente su una crittografia ASIMMETRICA. Certo che avere l idea è una cosa, realizzarla nella pratica è un altra: Diffie, Hellman e Merkle cercarono di realizzare questo sogno con un metodo, chiamato Diffie-Hellman key agreement, attraverso il quale due persone potevano mettersi d accordo su una chiave simmetrica condivisa e segreta usando solo messaggi pubblici, ma non si trattava della crittografia a chiave pubblica, che è tipicamente asimmetrica. L invenzione di un vero e proprio sistema di crittografia asimmetrica a chiave pubblica si deve a Ron Rivest, Leonard Adelman e Adi Shamir, che lavoravano al MIT (Massachussets Institute of Technology): il loro sistema, chiamato criptosistema RSA (prima fu messo il nome di Rivest, perché fu lui a colpire nel segno), era basato sulla difficoltà nel trovare i divisori, cioè i due fattori primi, di numeri molto grandi (il processo è noto come fattorizzazione ). Questo metodo non solo permette di inviare messaggi crittografati, ma possiede anche un altra importante proprietà: una persona, crittografando un messaggio con la propria chiave privata, può provare che un dato messaggio proviene proprio da lui: questo è il concetto che sta alla base della firma digitale, che garantisce un modo per stabilire l integrità di quanto inviato in un mondo dove vengono scambiati solo bit e byte L utilizzo pratico della crittografia Con la crittografia a chiave pubblica vengono usate due chiavi separate per crittografare e decrittografare un messaggio, in modo tale che nient altro che messaggi crittografati debbano attraversare la rete: la crittografia asimmetrica è utilizzata, appunto, per risolvere il problema di consegnare la bulk key (usata nella crittografia simmetrica) in modalità sicura. Per fare questo si cripta la bulk key con la chiave pubblica del server al quale si vuole inviare il messaggio; dal momento che solo lui conosce la corrispondente chiave privata e che solamente con la chiave privata si può decriptare il messaggio, solamente quel server potrà ricavare la bulk key ed utilizzarla per decriptare le successive trasmissioni. Perché bisogna usare questa combinazione di crittografia asimmetrica e simmetrica? La ragione è semplice: la crittografia a chiave pubblica è lenta ed è applicabile solamente per crittografare piccole quantità di informazioni (la chiave simmetrica o bulk key, per l appunto), 9

10 Capitolo 3 - Sicurezza: tecniche crittografiche mentre la crittografia simmetrica è molto più veloce ed è adatta per crittografare grandi quantità di dati. Volendo dare una forma schematica all intero processo, così come avviene nella realtà: crittografia e invio del messaggio da parte del client: generazione della chiave simmetrica A; cifratura del messaggio M con la chiave A per ottenere M*; ottenimento della chiave pubblica del destinatario; cifratura della chiave simmetrica A con la chiave pubblica del destinatario per ottenere A*; invio di {A*, M*}; Ricezione del messaggio e decrittografia da parte del server: ricezione di {A*, M*} e separazione dei due campi; decrittografia di A* con la propria chiave privata per ottenere A; decrittografia di M* con la chiave A per ottenere il messaggio originale M. Dal momento che questi concetti non sono del tutto intuitivi né immediati, vengono qui di seguito spiegati anche con l aiuto di due immagini, separando, per semplicità, l invio della bulk key da quello del messaggio (anche se in realtà avviene tutto insieme). All inizio della comunicazione, SSL usa la crittografia asimmetrica (vedi Figura 3.4) per trasferire verso il server la bulk encryption key unica (A), generata dal browser sul momento: si ha la garanzia della sua unicità grazie ad algoritmi che coinvolgono l ora, la data ecc. Figura 3.4: trasmissione della bulk key, crittografata con la chiave pubblica: crittografia asimmetrica. Gli algoritmi di crittografia asimmetrica più conosciuti sono: RSA, Diffie-Hellman, DSA e Figura 3.5: trasmissione del messaggio crittografato con la bulk key: crittografia simmetrica. Elliptic Curve Cryptography (ECC). A questo punto, per velocizzare il trasferimento (la crittografia asimmetrica è adatta per crittografare piccole quantità di dati) SSL usa la crittografia simmetrica, attraverso la bulk key unica, per crittografare e decriptare i messaggi. (si veda la Figura 3.5). 10

11 Capitolo 3 - Sicurezza: tecniche crittografiche Si noti che in questo esempio solamente il server è stato autenticato: i certificati client possono essere usati per autenticare un utente nei confronti del Web server, ma a tutt oggi la maggior parte delle applicazioni Web si accontentano della semplice coppia username e password. Gli algoritmi di cifratura simmetrica hanno il vantaggio della velocità: generalmente sono dalle 100 alle 1000 volte più veloci degli algoritmi asimmetrici tipicamente usati (questa caratteristica li rende di gran lunga preferibili per cifrare file da memorizzare localmente): la cifratura asimmetrica è così tanto più lenta di quella simmetrica che spesso, per molti messaggi, ci vuole più tempo per decriptare la chiave che per decriptare il messaggio in sé. Algoritmi ben noti per la crittografia simmetrica sono: DES, Triple DES, RC2 e RC4 e la loro robustezza dipende, naturalmente, dalla lunghezza della chiave di sessione (la bulk key), generata in ogni sessione sicura: più è lunga la chiave e più è difficile violare il codice crittografico (se è 40 bit, la cifratura è considerata debole; dai 128 in su è considerata forte). La maggior parte dei browser supporta sessioni SSL a 40 bit, mentre già con Netscape Communicator 4.0 si ha la possibilità di crittografare con chiavi a 128 bit (questo significa avere una sicurezza superiore di volte rispetto a quella a 40 bit) La firma digitale Una volta che si sia stabilita una connessione sicura tra due parti, qualsiasi messaggio ricevuto da un entità esterna alla connessione sicura viene rigettato, oppure l utente viene avvertito. SSL realizza ciò creando una specie di impronta digitale univoca del messaggio (chiamata anche riassunto o digest) per entrambe le parti, attaccandola in allegato ad ogni messaggio. Figura 3.6: trasmissione del messaggio firmato. Vediamo meglio questo processo di firma digitale con l aiuto, anche qui di alcune immagini. Prima di tutto, attraverso una one-way function, si realizza un riassunto matematico del messaggio (chiamato anche hash code o message digest : si tratta dell impronta digitale del messaggio univocamente determinata di cui si parlava prima ed è indicato come hash code creates a unique digital fingerprint of original check in Figura 3.6): se anche un solo bit del messaggio dovesse variare, l hash code cambierebbe in modo drammatico. Più in particolare, l hash code è la rappresentazione di messaggi lunghi e di dimensione variabile attraverso loro riassunti più corti e con lunghezza fissa: gli algoritmi di digest sono stati progettati per produrre riassunti univoci per ogni messaggio, ognuno dei quali è strutturato in modo da rendere estremamente difficile risalire al messaggio originale. È anche pressoché impossibile trovare due messaggi differenti che generino lo stesso digest: questo fatto elimina la possibilità di sostituire un messaggio con un altro mantenendo lo stesso digest. 11

12 Capitolo 3 Sicurezza: la firma digitale Il secondo passo nel creare una firma digitale consiste nel crittografare l hash code insieme ad altre informazioni (come ad esempio un numero di sequenza), con la chiave privata del mittente (vedi in Figura 3.6 la dicitura Sign hash code using sender s PRIVATE key ). Anche se chiunque può decrittografare la firma usando la corrispondente chiave pubblica, solamente il firmatario conosce la chiave privata: questo significa che solamente lui può aver firmato il digest. Inoltre, includendo il digest nella firma, quest ultima risulterà valida solamente per quel messaggio: in questo modo si assicura anche l integrità del messaggio, in quanto nessun altro può cambiare il messaggio e firmarlo nuovamente (con una chiave privata a lui ignota); inoltre, per essere tutelati contro l intercettazione e il riuso della firma da parte di un intruso in un istante successivo, la firma contiene un numero di sequenza unico. Tutto questo meccanismo protegge il server da un eventuale falsa dichiarazione del client, che potrebbe dire di non aver mai mandato il messaggio (non ripudio). Il terzo passo consiste nell appendere la firma digitale al messaggio (vedi la dicitura Append the signed hash code to check in Figura 3.6), che si comporta così alla stregua di una firma manuale in calce ad un assegno. Infine il messaggio con apposta la firma digitale viene crittografato con la bulk key ( Encrypt check using one-time symmetric key ), si unisce la bulk key crittografata con la chiave pubblica del server ( Encrypt one-time symmetric key using recipient s PUBLIC key ) e si spedisce il tutto. Figura 3.7: ricezione del messaggio firmato. Il ricevente del messaggio segue questi diversi passi a ritroso, per leggere il messaggio: nella fase di apertura ricava, utilizzando la propria chiave privata, la bulk key (vedi in Figura 3.7 la dicitura Decrypt one-time symmetric key using recipient s PRIVATE key ); poi usa la bulk key per decriptare il resto del messaggio, che contiene anche la firma digitale ( Decrypt check using one-time symmetric key ). A questo punto, SSL verifica l integrità del messaggio procedendo con un ulteriore passo di autenticazione: verifica la firma digitale decrittografandola con la chiave pubblica del mittente (è evidente che il mittente deve essere certificato, per possedere una chiave pubblica), mettendo così in chiaro il digest ( Verify digital fingerprint using sender s PUBLIC key ); allo stesso tempo viene creato un nuovo hash code a partire dal messaggio ricevuto, posto poi a confronto con l originale decrittografato ( Rehash creates a new digital fingerprint from decrypted check for comparison with the original ). Se tra i due c è un match, cioè se coincidono perfettamente, allora il ricevente ha la conferma che il messaggio non è stato alterato, ma sa anche qualcosa in più: solamente il mittente certificato con cui è convinto di parlare può aver inviato il messaggio, perché solamente lui possiede la chiave privata che ha firmato l hash code originale, perciò la firma digitale garantisce sia l integrità del 12

13 Capitolo 3 Sicurezza: la firma digitale messaggio, sia l identità del mittente, quindi l autenticazione e il non ripudio. Se tra i due digest, invece, non si verifica un match, SSL comprende che il messaggio è stato alterato e ne richiede la ritrasmissione. Una delle applicazioni più utili della firma digitale, a parte l autenticazione dei messaggi veri e propri, riguarda la conferma delle chiavi pubbliche di terze persone: la crittografia a chiave pubblica, infatti, lascia scoperto un possibile punto debole. Nel momento in cui si vuole comunicare con un particolare Web server, bisogna determinarne la chiave pubblica e il modo migliore per ottenerla sarebbe quella di ottenerla direttamente da lui: la maggioranza delle volte, però, questo non è possibile e si è costretti ad ottenerla attraverso la rete. Come abbiamo visto il sistema a doppia chiave risolve ogni problema rispetto ad un eventuale intercettazione della chiave lungo il tragitto, ma presta il fianco alla possibilità che un terzo individuo malizioso, conoscendo la volontà di comunicare con quel particolare Web server, si spacci per lui e spedisca una chiave pubblica contraffatta. Se si cade nel tranello e si utilizza quella chiave, i successivi messaggi saranno leggibili non dal Web server con cui si è convinti di comunicare, bensì dal terzo individuo, titolare della vera corrispondente chiave segreta: quest ultimo potrà poi perfezionare il suo inganno rispedendo a sua volta tutti i messaggi al Web server, che in questo modo non si accorgerà nemmeno dell esistenza di una tappa in più lungo la strada. Questo problema (chiamato problema dell uomo nel mezzo ) è assolutamente concreto e reale e la soluzione sta nel chiedere e ottenere che ogni nuova chiave pubblica sia firmata da qualcuno che si conosce e di cui si dispone già con certezza della rispettiva chiave pubblica. Se si è costretti a ottenere la chiave del Web server via rete, si avrà cura di verificare che essa sia firmata da una CA che abbia magari contatti quotidiani con il Web server stesso. Siccome si hanno tutte le ragioni per potersi fidare di tale CA, si può dire di possederne con certezza la vera chiave pubblica. Con questa chiave si può verificare la firma che la CA ha apposto sulla chiave pubblica del Web server, potendo quindi verificare che la CA, considerata affidabile, garantisca che la chiave pubblica appena arrivata sia effettivamente quella del Web server. A questo punto è evidente che la certificazione delle chiavi può diventare rapidamente molto complessa, consentendo, da un unico punto di partenza sicuro, di estendere la rete di contatti a dismisura, comprendendo anche entità che non si incontreranno mai direttamente. Con questa caratteristica il cerchio viene chiuso e diventa veramente possibile stabilire un infrastruttura comunicativa priva di contatti fisici che sia doppiamente sicura, sia dal punto di vista della possibilità di leggere il contenuto della comunicazione, sia da quello di poterne garantire la provenienza Distribuzione sicura di certificati digitali Dal momento che chiunque può generare coppie di chiavi (tutto sommato si tratta di calcolare il prodotto di due numeri primi estremamente elevati: la sicurezza deriva dal fatto che è estremamente difficile riuscire a ottenere i due fattori partendo dal loro prodotto) sarebbe, in linea teorica, possibile per un individuo malizioso costruire un sito Web, spacciarlo per quello, ad esempio, di una banca e quindi falsificare le informazioni contenute in una transazione, fornendo una chiave pubblica agli utenti, i quali sarebbero convinti di dialogare in modalità sicura con una banca, mentre in realtà stanno sì comunicando in modo sicuro, ma con un individuo pericoloso: certamente nessuno potrebbe intercettare le conversazioni che intercorrono tra loro, ma i clienti si troverebbero nelle grinfie di una persona disonesta, alla quale, in buona fede, comunicherebbero informazioni private e preziose. Per prevenire questo tipo di frodi vengono utilizzati i certificati digitali, che rappresentano un modo autenticato di distribuire le chiavi pubbliche (non quelle private!): i certificati digitali sono usati per autenticare le parti di una conversazione in Internet, in modo tale che entrambi (l utente e il fornitore di contenuto) sappiano per certo con chi ognuno di loro sta dialogando in quel momento. In particolare, SSL usa i certificati digitali per collegare insieme importanti informazioni che servono per identificare un client o un server (il nome dell organizzazione, il suo indirizzo di e- 13

14 Capitolo 3 Sicurezza: distribuzione sicura di certificati digitali mail, il paese di appartenenza, l organizzazione che ha emesso il certificato, ecc.). Esistono due tipi differenti di certificati digitali, presentati qui di seguito. I certificati root: le CA sono entità rispettabili, fidate e indipendenti che emettono chiavi e certificati in favore di individui e società; esse utilizzano metodi molto seri e rigorosi, per sondare in profondità le realtà che si trovano di fronte: avendo la responsabilità di garantire la veridicità di quanto dichiarano i richiedenti il certificato, è loro preciso dovere capire se i richiedenti sono veramente chi dichiarano di essere e sono, perciò, degni di fiducia. Le CA rendono disponibili i propri certificati root per il download da parte di chiunque (alcuni gratuiti di tipo trial, cioè di prova, altri a pagamento), in modo che chiunque voglia comunicare con loro in modo sicuro possa farlo; un certo numero di compagnie, come VeriSign, Thawte, SSL.com o RSA Security, si sono pubblicamente proposte in qualità di CA, fornendo servizi come la verifica e il trattamento delle richieste, e l emissione e la buona gestione dei certificati. È possibile per chiunque creare una propria CA personale: anche se questo può risultare estremamente rischioso e oneroso in Internet, nell ambito di una rete Intranet potrebbe risultare utile, perché, in questo ambiente ristretto, sarebbe più facile per l organizzazione verificare l identità degli individui e dei server. I certificati server e client: i certificati server sono usati per autenticare un Web server (è facile trovare queste realtà, in Internet), mentre i certificati client o personali sono usati per autenticare l identità di un singolo utente (per loro natura sono molto rari); entrambi i certificati includono quattro componenti base: la chiave pubblica; informazioni che legano la chiave pubblica al suo possessore; informazioni su chi ha emesso il certificato; la firma digitale di chi ha emesso il certificato. Più in particolare i campi di informazione tipici includono: il nome del possessore del certificato; l indirizzo del possessore del certificato; il numero di telefono del possessore del certificato; il nome della compagnia per cui il possessore del certificato lavora; le medesime informazioni per chi ha emesso il certificato; un identificatore univoco per il certificato (serial number); un indicatore del livello di fiducia che può essere posto nel certificato; la data di emissione del certificato la data di scadenza del certificato. Ci si riferisce alle informazioni raccolte su un qualsiasi individuo come al suo Distinguished Name, o DN, perciò un certificato contiene due DN: quello del possessore e quello dell emissario del certificato. La cosa più importante, però, è che i certificati server e client sono essi stessi crittografati con la CHIAVE PRIVATA della CA e in questo modo si ha la sicurezza che sia veramente stata la CA ad emettere quel certificato: quando un Web browser richiede di avere una conversazione sicura con un Web server, il server spedisce al browser il proprio certificato (che contiene la propria chiave pubblica) crittografato con la chiave privata di una determinata CA (è praticamente lo stesso certificato che la CA ha inviato al Web server al momento della certificazione); allora il browser autentica il Web server confermando che una CA fidata ha crittografato il certificato CON LA PROPRIA CHIAVE PRIVATA E SEGRETA, decrittografandolo con la chiave pubblica della CA stessa, pubblicamente disponibile e da esso generalmente già conosciuta. A questo punto il browser usa la chiave pubblica del Web server riposta nel certificato inviato per crittografare la bulk key (generata ex novo tutte le volte che si stabilisce una nuova sessione sicura) da mandare e condividere con il Web server: questa nuova chiave è ora usata per crittografare il resto della conversazione. Usando il certificato server, il Web server e il browser possono intrattenere una conversazione sicura privata e autenticata, con integrità garantita: se ogni parte possiede un certificato che valida l identità dell altro, conferma la sua 14

15 Capitolo 3 Sicurezza: distribuzione sicura di certificati digitali chiave pubblica ed è firmato (= crittografato con la chiave privata di ) da un agenzia fidata, allora entrambi saranno sicuri di comunicare con chi sono convinti di star comunicando Richiesta di un certificato digitale Per ottenere un certificato si deve costruirne una richiesta, che contenga tutte le informazioni personali che appariranno nel certificato stesso: esistono due tipi di richieste di certificato largamente usate, note come PKCS#10 e RFC Una richiesta di certificato PKCS#10 (di gran lunga la più semplice) consiste internamente di quattro campi: un numero di versione (1-3); il nome dell utente finale (DN o Distinguished Name); la sua chiave pubblica; gli attributi. Il campo degli attributi contiene qualsiasi altra cosa si desideri codificare nel certificato, come il numero di telefono, il numero di fax, l indirizzo , lo scopo per cui si intende usare la chiave e una moltitudine di altre proprietà. Può essere difficile capire quali informazioni possano essere incluse nel DN, che, teoricamente, è una stringa univoca che identifica il possessore del certificato, e quali, invece, debbano far parte degli attributi: la distinzione consiste nel fatto che un DN dovrebbe possedere soltanto i seguenti campi: il codice del paese (due lettere), tipo IT, UK, ecc.; lo stato o la provincia; la località; l organizzazione o la compagnia; la propria unità organizzativa; il proprio nome, tipo Morena Bonezzi. La richiesta di certificati RFC 2511, invece, permette di includere altre informazioni attraverso l uso delle estensioni, che possono essere attributi addizionali, come il numero di telefono, oppure istruzioni per l uso del certificato. Per esempio, un certificato auto-assegnato richiede un estensione Key Usage per assicurare che possa, tale chiave, firmare altri certificati; si può anche voler aggiungere qualche estensione sulla politica del certificato. Per quanto riguarda le chiavi, ci sono due differenti approcci per generarne una coppia e creare un certificato a partire dalla chiave pubblica, come si è già avuto modo di dire: delegare alla CA il compito di generare la coppia di chiavi e il certificato; generare la coppia di chiavi localmente, usando mezzi hardware o software, creare la richiesta di certificato contenente la propria chiave pubblica e inviare tutto alla CA. Nel caso si stia mantenendo una rete con molti server, è meglio generare centralmente tutte le coppie di chiavi, certificarle tutte e distribuire tutti i certificati simultaneamente. Quando il certificato raggiunge la data di scadenza, si può generare una nuova coppia di chiavi ed inviare la nuova chiave pubblica alla CA perché venga certificata, oppure ricertificare la vecchia chiave inviandola alla CA: in generale, è meglio generare una nuova coppia di chiavi. Sarebbe quello anche il momento giusto per cambiare la frase che protegge (passphrase) la chiave privata. Se altre persone hanno usato il vecchio certificato per inviare messaggi crittografati e il ricevente li ha memorizzati in questa forma, allora quest ultimo deve mantenere una copia della vecchia chiave privata per poter poi leggere i vecchi messaggi, ma se questo dovesse causare problemi, si può anche decrittografare i messaggi e ricrittografarli con la nuova chiave pubblica. 15

16 Capitolo 3 Sicurezza: difficoltà dell utente di fronte alla certificazione Difficoltà dell utente di fronte alla certificazione Piuttosto che sull autenticazione dell utente, la maggior parte delle applicazioni Web attuali si basano semplicemente sull immissione di uno username e di una password da parte dell utente, per cercare di garantire il non ripudio. Le applicazioni, però, possono richiedere una firma digitale da parte del client, che implica che l utente autorizzi specificatamente una transazione e, in particolare, che possieda un certificato client. L autorizzazione è quindi crittografata con la chiave privata del client, che quest ultimo mantiene rigorosamente segreta. In ogni caso, però, l adozione dei certificati client per uso individuale su Internet ha avuto uno sviluppo molto scarso, anche perché gli utenti non hanno né tempo né voglia di seguire il noioso iter burocratico necessario per l ottenimento di un certificato client. Differenti combinazioni di tutte le tecniche di sicurezza sopra esposte sono usate per diverse applicazioni, a seconda della tipologia di sicurezza necessaria e della misura in cui la soluzione ha necessità di essere bilanciata con la convenienza per l utente finale. Proprio per questo i certificati client per la garanzia di autenticazione e non ripudio non sono utilizzati in modo diffuso sul Web, attualmente, perché la maggioranza degli utenti non vuole essere annoiata con pratiche amministrative e burocratiche per ottenere e mantenere in modo sicuro un certificato client SSL 3.0 Esiste una serie di versioni del protocollo SSL: in particolare, uno dei maggiori benefici di SSL 3.0 risiede nel fatto che questa versione aggiunge il supporto per il caricamento automatico delle catene dei certificati, permettendo così ad un server di inviare al browser un proprio certificato insieme ai certificati degli emissari. Il browser che si utilizza per navigare su Internet supporta tipicamente un certo numero di CA ben note, perciò, richiedendo una comunicazione sicura con un Web server, se questo risultasse certificato da una di esse, si è automaticamente garantiti sulla tutela delle trasmissioni. Se, invece, ci si trova a comunicare con un Web server certificato da una CA non compresa nella lista contenuta nel browser, sarà necessario caricare il certificato della CA in questione nel browser stesso, abilitando perciò quest ultimo a validare anche tutti i certificati server firmati da quella CA.; questo comportamento potrebbe risultare alla lunga pericoloso, perché, una volta caricato il certificato, il browser accetterà tutti i certificati firmati da quella particolare CA. Invece il caricamento automatico delle catene di certificati che si ha con la versione 3.0 del protocollo SSL permette al browser di validare il certificato del server anche se i certificati di alcune CA intermedie non sono stati installati, in quanto essi fanno comunque parte della catena di certificati (si vedrà, però, nel Capitolo 3 che la costruzione delle catene di certificati non è poi così immediata come si potrebbe pensare). SSL 3.0 è la base del protocollo standard Transport Layer Security (TLS), sviluppato ad opera della Internet Engineering Task Force (IETF) Sequenza di handshake La sessione SSL viene stabilita seguendo una sequenza di handshake tra il client e il server, che può variare, a seconda che il server sia stato configurato per fornire un certificato server, oppure per richiedere un certificato client. Anche se possono esistere casi particolari in cui vengono richiesti passi addizionali di handshake, ad esempio per la gestione delle informazioni sulla Cipher Suite, cioè il set riguardante gli algoritmi da usare per la crittografia, qui di seguito si tratterà lo scenario più comune, rimandando, per ulteriori dettagli, alle specifiche di SSL. 16

17 Capitolo 3 Sicurezza: SSL 3.0 e sequenza di handshake Figura 3.8: sequenza di handshake. Una volta che una sessione SSL è stata stabilita (durante l handshake sono stati fissati il numero di versione del protocollo, l identificatore di sessione, il set di algoritmi crittografici e le tecniche di compressione, vedi Figura 3.8), può essere utilizzata per più comunicazioni richiesta/risposta consecutive, evitando così le penalizzazioni di performance legate alla necessità di ripetere i numerosi passi necessari per iniziare una sessione ex novo: per questo, il server assegna ad ogni sessione SSL un unico identificatore di sessione (memorizzandolo in cache) che può essere usato dal client nelle successive comunicazioni, per ridurre il tempo necessario per l handshake (perlomeno finché l identificativo di sessione rimane memorizzato nella cache del server e naturalmente finché il client non chiude il browser). I passi della sequenza di handshake, così come vengono presentati in Figura 3.8, sono: negoziazione della Cipher Suite da usare durante il trasferimento dati; costituzione e distribuzione della chiave di sessione o bulk key tra client e server ( exchange random values ); autenticazione del server nei confronti del client (opzionale); autenticazione del client nei confronti del server (opzionale). Il primo passo permette al client e al server di negoziare una Cipher Suite supportata da entrambi (le specifiche del protocollo SSL 3.0 ne definiscono 31), definita dalle componenti presentate qui di seguito. Metodo per lo scambio delle chiavi (key exchange): il metodo di key exchange stabilisce un accordo tra il client e il server sul metodo di condivisione della chiave crittografica segreta simmetrica (bulk key) usata per la crittografia dei dati: SSL 2.0 utilizzava solamente lo scambio di tipo RSA, mentre SSL 3.0 supporta la possibilità di scegliere tra diversi algoritmi di scambio di chiavi, inclusi RSA quando sono usati i certificati, oppure Diffie- Hellman per lo scambio di chiavi senza certificati e senza una precedente comunicazione tra client e server. Una variabile determinante nella scelta del metodo di scambio delle chiavi è la firma digitale: bisogna decidere insieme se usarla oppure no; in caso affermativo bisogna concordare su quale tipo di firma utilizzare. Firmare con una chiave privata fornisce una garanzia contro l eventuale cosiddetto attacco dell uomo-nel-mezzo, durante lo scambio di informazioni usato nella generazione della chiave condivisa. Cipher per il trasferimento dati: SSL usa algoritmi convenzionali per la crittografia simmetrica di un messaggio in una sessione sicura. Si può scegliere tra ben nove possibilità, includendo anche quella di non utilizzare la crittografia: Nessuna tecnica crittografica; Stream di cifre; RC4 con chiave a 40 bit; RC4 con chiave a 128 bit; 17

18 Capitolo 3 Sicurezza: SSL 3.0 e sequenza di handshake CBC (Cipher Block Chaining: una porzione del testo precedentemente cifrato è usata per crittografare il blocco corrente); RC2 con chiave a 40 bit (algoritmo proprietario di RSA DSI); DES con chiave a 40 bit (Data Encryption Standard: comprende varianti, includendo DES40 e 3DES_EDE); DES con chiave a 54 bit; Triple DES con chiave a 168 bit; Idea (chiave a 128 bit: uno dei migliori e crittograficamente più forti algoritmi disponibili); Fortezza (chiave a 96 bit); Funzione di digest: la scelta della funzione di digest determina la modalità di creazione di un riassunto a partire da un unità di record. Il messaggio di digest è usato per creare il Message Authentication Code (MAC) che è crittografato insieme al messaggio per fornire integrità e per premunirsi contro attacchi ripetuti. SSL supporta le seguenti possibilità: Nessun digest (Scelta nulla); MD5, algoritmo di hash a 128 bit; Secure Hash Algorithm (SHA-1), algoritmo di hash a 160 bit. Figura 3.9: la struttura dello stack SSL I tre protocolli della sequenza di handshake La sequenza di handshake usa tre protocolli: SSL Handshake Protocol, per stabilire la sessione SSL tra client e server; SSL Change Cipher Spec Protocol, per stabilire effettivamente un accordo sulla Cipher Suite da adottare durante la sessione; SSL Alert Protocol per lo scambio di messaggi di errore tra il client e il server. Questi protocolli, così come l Application Protocol Data, si innestano nell SSL Record Protocol, come si può vedere nella Figura 3.9: questo innestamento di protocolli è trasferito come se fosse un dato unico al protocollo di livello inferiore, che non esamina il contenuto di ciò che gli viene inviato, così come il protocollo incapsulato non si rende conto della presenza degli strati inferiori. L innestamento dei protocolli di controllo SSL da parte del Record Protocol significa che, se venisse rinegoziata una sessione attiva, il protocollo di controllo verrebbe ritrasmesso sicuramente, mentre se non fosse esistita prima una sessione, allora verrebbe usata la Null Cipher Suite, il che significa che non esisterebbe crittografia e che i messaggi sarebbero privi di verifiche di integrità tramite digest sin da quando la sessione viene stabilita. L SSL Record Protocol è usato per trasferire applicazioni e dati di controllo SSL tra il client e il server, possibilmente frammentando questi dati in unità più piccole o combinando messaggi multipli, contenenti dati e provenienti da protocolli di più alto livello, in singole unità (si veda a 18

19 Capitolo 3 Sicurezza: SSL 3.0 e sequenza di handshake questo proposito la Figura 3.10). Può comprimere, appendere firme digitali e crittografare queste unità, prima di trasmetterle utilizzando il protocollo di trasporto sottostante disponibile. Un modo comune di usare SSL è proprio quello di rendere sicure le comunicazioni HTTP sul Web, tra un browser e un Web server. Questa possibilità non preclude l uso di comunicazioni HTTP non sicure. La versione sicura viene realizzata sovrapponendo HTTP su SSL (protocollo HTTPS), ma con un rilevante differenza: usa lo schema URL https piuttosto che http e una differente porta del server (per default la 443). Figura 3.10: frammentazione dei dati Crittanalisi e attacchi alla sicurezza Prima di concludere questa discussione generale, è necessario un commento critico sul grado di sicurezza effettivamente raggiungibile con strumenti di questo tipo. Finora non si è detto che la sicurezza dell algoritmo RSA non è affatto assoluta, ma al contrario, lo sforzo necessario per rompere con la sola forza bruta una tipica chiave RSA (questo è il nome dello specifico algoritmo di crittografia a chiave pubblica utilizzato dal più generale algoritmo PGP, Pretty Good Privacy, nelle sue versioni più diffuse) è quantificabile, con le attuali conoscenze matematiche, in modo abbastanza preciso. A seconda dei mezzi a disposizione, questo sforzo è misurato in migliaia o milioni di anni di calcolo, ipotizzando anche l impiego di computer molto più potenti di quelli pubblicamente conosciuti in questo momento. La sicurezza, da questo punto di vista, è quindi relativamente assoluta, sempre che non subentrino altri anelli, più deboli, nella catena del sistema. Infatti, l informazione più delicata con cui si ha a che fare è la chiave privata che, data la sua lunghezza, non potrebbe certo essere ricordata a memoria da una persona normale; per questo viene normalmente memorizzata su un dispositivo di memorizzazione secondaria, come un dischetto o un file sul proprio hard disk. In quest ultimo caso, è necessario proteggerla in un qualche modo, con una password o una passphrase (concettualmente simile ad una password, ma potenzialmente costituita da più parole o addirittura da una frase, invece di una parola sola). Ebbene: il fatto di scrivere la propria passphrase su un foglietto post-it appiccicato al monitor può ridurre i famosi milioni di anni di calcolo a pochi secondi. A parte questo esempio banale, i potenziali anelli deboli sono sfortunatamente molti. Tuttavia si tratta sempre di debolezze esterne all algoritmo di crittografia vero e proprio: è inutile chiedersi se i milioni di anni potranno presto ridursi a centinaia con l aiuto di computer più potenti: è molto più utile, invece, chiedersi ad esempio in base a quali criteri è stata scelta la propria passphrase. La metodologia di attacco più efficiente conosciuta fino a questo momento, infatti, piuttosto che tentare tutte le combinazioni possibili della chiave (brute force attack) si affida a dizionari, che limitano i 19

20 Capitolo 3 Sicurezza: crittanalisi e attacchi pratici tentativi per trovare la passphrase alle sole combinazioni più plausibili in base a fattori tipicamente umani. Prima di commentare i possibili attacchi condotti tramite dizionario, però, è opportuno soffermarsi ancora un momento sugli attacchi brute force. Nel caso del PGP o dell RSA, questi consistono nel tentativo di ottenere i codici di accesso avendo a disposizione la sola chiave pubblica. In termini matematici si tratta di fattorizzare un numero estremamente alto; lo sforzo necessario per compiere questa operazione dipende direttamente e in primo luogo dalla lunghezza della chiave pubblica prescelta. Le tipiche chiavi pubbliche create con l RSA sono costituite, in genere, da un numero ben preciso di bit: 384, 512, 768, 1024, All aumentare della lunghezza della chiave pubblica aumenta anche lo sforzo necessario per fattorizzarla; questo aumento avviene però in forma esponenziale e quindi una chiave da 1024 bit è incomparabilmente più sicura, da questo punto di vista, di una da 512. Per rendere più evidenti queste differenze, la Tabella 3.1 qui riportata indica un tentativo di stima dello sforzo richiesto, con gli algoritmi attualmente più evoluti, per fattorizzare alcune tipiche chiavi pubbliche generate dall RSA: Dimensioni della chiave in Anni - MIPS necessari per la bit fattorizzazione Tabella 3.1 L intensità dello sforzo è espressa in anni-mips, una misura comunemente usata per indicare la potenza di calcolo: un anno-mips corrisponde a un anno di calcolo ininterrotto effettuato da una macchina della potenza di 1 MIPS (cioè in grado di eseguire un milione di istruzioni al secondo; è da tenere presente che i comuni personal computer esprimono in genere una potenza di calcolo superiore a 200 MIPS). Per dare un idea concreta di quale sia la capacità di calcolo raggiungibile attualmente, ricordiamo i due più importanti eventi che hanno sottoposto a prove pratiche la resistenza dell RSA agli attacchi brute force. Nel primo caso si trattava di raccogliere la sfida lanciata da Ron Rivest nel 1977: a chi fosse riuscito a fattorizzare un numero di 129 cifre (approssimativamente corrispondente a una chiave RSA da 425 bit), Rivest prometteva un premio simbolico di 100 dollari. La sfida era nota con il nome RSA-129 : lo stesso Rivest aveva stimato che fossero necessari almeno 150 anni per realizzare una simile impresa. Nel 1994, dopo soli 17 anni, questo obiettivo è stato raggiunto seguendo una metodologia assai interessante: i calcoli sono stati eseguiti su una gigantesca macchina virtuale, composta da migliaia di computer sparsi in tutto il mondo: infatti, anziché concentrare lo sforzo su una sola macchina, che avrebbe portato a tempi di calcolo assolutamente improponibili, la sfida è stata ampiamente pubblicizzata in rete e, attraverso alcuni coordinatori, distribuita a migliaia di volontari, ognuno dei quali metteva a disposizione le proprie risorse di calcolo nei momenti in cui queste non venivano utilizzate per le normali attività lavorative. Attraverso questa enorme iniziativa pubblica e collettiva si è riusciti, in soli otto mesi di lavoro effettivo ed esprimendo uno sforzo complessivo pari a anni-mips a superare la sfida, fattorizzando il numero di 129 cifre e decrittografando il messaggio di sfida scritto nel 1977 da Rivest. Questo evento rese evidenti a tutti le incredibili possibilità offerte dalla cooperazione in rete su vasta scala. Il secondo evento degno di nota è avvenuto nel 1995 e ha rappresentato il primo attacco brute force riuscito direttamente contro una vera e propria chiave RSA: si trattava della chiave da 384 bit (116 cifre) di Blacknet, un esperimento dimostrativo di come avrebbe potuto funzionare un ipotetico mercato nero di informazioni segrete, basato su crittografia e firme digitali. La chiave è 20