Source: http://docplayer.it/1839057-Progetto-e-sviluppo-di-una-pki.html
Timestamp: 2016-10-21 13:42:41+00:00
Document Index: 166118410

Matched Legal Cases: ['art 1', 'art 2', 'art 3', 'arte 3', 'arte 2', 'art 4', 'arte 3', 'art 5', 'art 6', 'art 7', 'art 8']

⭐PROGETTO E SVILUPPO DI UNA PKI
Download "PROGETTO E SVILUPPO DI UNA PKI"
1 UNIVERSITA POLITECNICA DELLE MARCHE Facoltà di INGEGNERIA Corso di Laurea in Ingegneria Elettronica Dipartimento di Elettronica, Intelligenza Artificiale e Telecomunicazioni PROGETTO E SVILUPPO DI UNA PKI PER LA FIRMA DIGITALE BASATA SU SMART CARD IN AMBITO SANITARIO Relatore Chiar.mo Prof. Aldo Franco Dragoni Tesi di laurea di Matteo Liuti Correlatore Chiar.mo Prof. Paolo Puliti Anno Accademico 2004/20052 3 Indice Indice Struttura della tesi... 1 Capitolo 1. INTRODUZIONE Lo sviluppo dei sistemi informatici Il problema della sicurezza La sicurezza nella Pubblica Amministrazione... 6 Capitolo 2. CRITTOGRAFIA Concetti base di crittografia Crittografia Simmetrica Cifratura a blocchi e a flusso Algoritmi a blocchi Algoritmi a flusso I principali algoritmi di cifratura simmetrica Data Encryption Standard (DES) Triple DES (TDES) Advanced Encryption Standard (AES) International Data Encryption Algorithm (IDEA) RC2 e RC Crittografia asimmetrica Algoritmi a chiave di cifratura pubblica Algoritmi a chiave di decifratura pubblica Uso combinato delle due tecniche I principali algoritmi di cifratura asimmetrica Rivest Shamir Adelman (RSA) Digital Signature Algorithm (DSA) Considerazioni generali sulla sicurezza degli algoritmi crittografici Funzione di Hash Firma Digitale Aspetti legali della firma digitale I4 Indice Capitolo 3. PUBLIC KEY INFRASTRUCTURE Introduzione Il certificato a chiave pubblica Ciclo di vita di un certificato Revoca di un certificato Certification Authority e Registration Authority Modello di fiducia Tipologie di collegamenti fra Autorità di Certificazione...49 Modello reticolare...50 Modello ad albero...52 Modelli a struttura ibrida Catene di certificazione Standard Standard X.509 per i certificati a chiave pubblica Standard PKCS...60 Capitolo 4. SMART CARD Aspetto di una Smart Card Architettura interna Tipi di Smart Card Standard Standard ISO/IEC ISO/IEC : Caratteristiche fisiche...69 ISO/IEC : Dimensione e locazione dei contatti...70 ISO/IEC : Segnali elettrici e protocolli di trasmissione Altri standard Abstract Syntax Notation Funzionamento di una Smart Card Sequenze di attivazione e disattivazione Sistema operativo File system Protocolli di trasmissione...82 Protocollo T= Protocollo T= Application Protocol Data Unit...86 II5 Indice 4.6 Interfaccia con le applicazioni PC/SC Open Card Framework Confronto tra OCF e PC/SC Java Card PKCS# Caratteristiche tecnologiche Sessioni Sessioni R/O Sessioni R/W Eventi di sessione Oggetti Oggetti Data Oggetti Key Oggetti Certificate Considerazioni sulla sicurezza Provider di sicurezza IAIK Capitolo 5. REALIZZAZIONE DEL PROGETTO Descrizione generale del progetto Applicazione all ambito sanitario Implementazione Strumenti utilizzati Installazione del Provider IAIK Software prodotto Software di inizializzazione Software di firma Tool di gestione della smart card Capitolo 6. CONCLUSIONI E SVILUPPI FUTURI Appendice. CODICE JAVA Bibliografia Ringraziamenti III6 7 Struttura della tesi Struttura della tesi Ogni capitolo della tesi riguarda un argomento chiave del progetto sviluppato. In questo lavoro hanno particolare importanza i concetti di crittografia, infrastrutture a chiave pubblica e smart card. Per ognuno di essi viene fornita prima una descrizione generale delle nozioni di base, andando poi ad approfondire i concetti più importanti e inerenti al progetto. Il primo capitolo fornisce una visione breve e introduttiva dell evoluzione dei sistemi informatici e dei problemi di sicurezza ad essa legati, con uno sguardo al settore della Pubblica Amministrazione. Il secondo capitolo descrive le tecniche crittografiche simmetriche ed asimmetriche, necessarie per comprendere l argomento più importante di questo lavoro che è la firma digitale. Di essa si spiegherà il funzionamento ed il suo valore legale. Il terzo capitolo si occupa dell infrastruttura a chiave pubblica (Public Key Infrastructure) fornendone una descrizione strutturale e funzionale e introducendo gli standard di base. Il quarto capitolo è dedicato interamente alle Smart Card, alla loro architettura, al loro funzionamento ed ai loro requisiti in termini di normative e standard. Presenta anche una sezione che descrive il modo con cui un applicazione può interagire con la smart card servendosi di un apposito provider di sicurezza. Il quinto capitolo descrive il lavoro che ho realizzato in collaborazione con la ASUR zona 7 della regione Marche. Verrà fornita prima una presentazione generale per poi andare in dettaglio sui vari aspetti del progetto e sulle scelte fatte. Nel capitolo sesto sono espresse alcune considerazioni personali sul lavoro svolto e vengono proposti dei possibili punti di sviluppo. Infine l appendice contiene il listato del software prodotto. 18 Struttura della tesi 29 Introduzione Capitolo 1. INTRODUZIONE 310 Capitolo Lo sviluppo dei sistemi informatici Lo sviluppo dei sistemi informatici negli ultimi anni ha compiuto passi da gigante, sia per quanto riguarda la continua nascita di nuove tecnologie, sia per la sempre più ampia possibilità di accesso a queste nuove conoscenze. Indubbiamente un notevole contributo a questa diffusione deriva dall enorme successo di Internet. Dal suo predecessore ARPANET (nato nel 1969 dalla collaborazione tra alcune università degli Stati Uniti 1 ) e soprattutto dall introduzione del World Wide Web (nel 1992 da parte del CERN) e del protocollo HTTP con il quale i server Web comunicano tra loro, si è verificata una vera e propria rivoluzione che ha reso alla portata di tutti risorse che prima erano inaccessibili. La facilità di acceso e di uso del Web, unita alla possibilità di offrire contenuti in modo immediato, consente ai singoli e alle aziende di rendere massima l efficienza e la chiarezza delle comunicazioni. Con gli anni questa sempre maggiore diffusione ha reso internet una necessità, portando enormi vantaggi ma anche una notevole quantità di rischi. 1.2 Il problema della sicurezza E perfettamente intuibile come la facilità di accesso ad un qualunque sistema favorisca l accesso anche da parte di persone che non hanno intenzioni del tutto benevole. Sono sempre più frequenti infatti i cosiddetti crimini informatici ad opera di soggetti che penetrano nei sistemi per visualizzare, modificare o addirittura cancellare informazioni sensibili, o con il semplice intento di recare danno al sistema. Le tecniche di accesso sono diverse e vanno dal social engineering, allo sniffing, allo scan e così via. Le conseguenze di questi crimini possono essere disastrose, specialmente se il sistema in questione è quello di una grande azienda. 1 Per la nascita di ARPANET hanno collaborato l Università dello Utah, l Università di California e lo Stanford Research Institute, finanziati dal progetto Advanced Research Projects Agency del governo degli Stati Uniti. 411 Introduzione Il problema della sicurezza dei sistemi informatici è quindi un argomento molto importante che deve essere sempre considerato (nelle giuste misure 2 ) qualunque sia il sistema di cui si disponga. In questo scenario ci vengono in aiuto diversi strumenti come la crittografia, la firma digitale, le PKI e le Smart Card che impareremo a conoscere nel corso di questa trattazione. Da quanto detto si delineano due aspetti su cui è opportuno intervenire: controllo degli accessi al sistema; protezione dei dati sensibili. Il primo punto coinvolge il problema dell autenticazione, cioè del riconoscimento di chi accede al sistema. Si possono individuare, a tal proposito, tre livelli di sicurezza: Autenticazione ad un fattore: basata su qualcosa che l utente sa. E il caso di una coppia di login costituita da nome utente e password. Autenticazione a due fattori: basata su qualcosa che l utente sa e qualcosa che l utente ha. E il caso che esamineremo di una smart card con PIN di autenticazione. Autenticazione a tre fattori: basata su qualcosa che l utente sa, qualcosa che l utente ha ed una caratteristica unica dell utente. E il caso di sistemi che integrano funzionalità di controllo biometriche come impronte digitali, cornea o altro. Per quanto riguarda la protezione dei dati sensibili, questa avviene mediante l impiego di particolari funzioni crittografiche. La crittografia è una tecnica che ci consente di proteggere i nostri dati rendendoli incomprensibili a chiunque, a meno che non abbia la chiave giusta per decifrarli. In questo modo anche se un messaggio che viaggia in rete venisse intercettato da un soggetto male intenzionato, egli non potrebbe mai sapere che cosa tale messaggio in realtà contiene. Questo permette di garantire la segretezza di una comunicazione, in quanto solo chi è in possesso della chiave di decifratura può interpretare correttamente il messaggio. 2 Si tenga sempre presente che il livello di sicurezza di un sistema deve essere proporzionale all importanza delle informazioni che si intende proteggere. 512 Capitolo 1 Livelli di sicurezza ancora più elevati si raggiungono con la crittografia asimmetrica che impiega due chiavi (una pubblica e una privata) per effettuare le operazioni di cifratura e decifratura. La crittografia (nello specifico la quella asimmetrica) trova impiego (ed anzi è alla base) del processo di firma digitale. Questa ha lo stesso ruolo della firma autografa su documento cartaceo 3, cioè serve a garantire l autenticità del documento, ossia la corretta identità del mittente. In generale, quando si allega la firma digitale ad un documento informatico si garantisce l autenticità dell autore e l integrità della trasmissione, cioè il fatto che nessuno abbia modificato il documento dopo l invio. L impiego di queste tecniche richiede una struttura capace di gestire correttamente l uso delle chiavi pubbliche di crittografia (tramite l utilizzo di appositi certificati 4 ) e in grado di fornire i protocolli di comunicazione e le regole base per offrire i servizi crittografici. La struttura in questione prende il nome di Public Key Infrastructure (PKI). Una PKI offre un elevato livello di sicurezza finché le chiavi pubbliche e private vengono gestite correttamente, da qui l esigenza di trovare un mezzo che ci consenta di custodire la nostra chiave privata in estrema sicurezza, ma anche di poterla portare sempre con noi. Il problema trova soluzione con l impiego delle Smart Card, cioè schede capaci non solo di contenere dati al loro interno, ma anche di elaborarli La sicurezza nella Pubblica Amministrazione Da qualche anno a questa parte il settore della Pubblica Amministrazione sta attraversando una crescente informatizzazione dei servizi. L obiettivo principale è quello di creare servizi on-line, orientati alle necessità dei cittadini e delle imprese e capaci di rendere più semplice e rapida ogni interazione con le Pubbliche Amministrazioni. Inoltre si intende eliminare gradualmente la documentazione cartacea sostituendola con documenti 3 Per una descrizione più dettagliata sugli aspetti legali della firma digitale si rimanda al paragrafo I certificati a chiave pubblica, appunto. 5 Da cui appunto il nome di scheda intelligente. 613 Introduzione informatici usufruendo delle citate tecniche di crittografia e firma digitale. I vantaggi che ne scaturiscono sono molto rilevanti: si va da una maggiore efficienza e velocità dei servizi, ad un più facile accesso ai servizi stessi, ad una migliore archiviazione delle informazioni, alla possibilità di effettuare ricerche più veloci e più mirate, alla possibilità di consultare sedi diverse indipendentemente dalla loro posizione geografica. Un progetto sicuramente ambizioso ma necessario per stare al passo con il continuo sviluppo tecnologico. Abbiamo già parlato dei rischi che comporta l apertura di un qualsiasi sistema informatico alla rete telematica, e nel caso delle Pubbliche Amministrazioni è di particolare importanza il problema della non divulgazione dei dati sensibili degli utenti. Questo si traduce nella necessità di realizzare un sistema di comunicazione in grado di garantire la riservatezza e la segretezza dei dati scambiati. Un apposito ente governativo, il CNIPA (Centro Nazionale per l Informatica nella Pubblica Amministrazione 6 ), ha il preciso obiettivo di dare supporto alla Pubblica Amministrazione nell utilizzo efficace dell informatica per migliorare la qualità dei servizi e contenere i costi dell azione amministrativa. Diversi progetti sono stati sviluppati ed alcuni sono già operativi a livello regionale, come ad esempio il progetto ESCAPE 7 (Electronic Signature in Care Activities for Paper Elimination) della regione Veneto, CRS-SISS 8 (Carta Regionale dei Servizi Sistema Informativo Socio-Sanitario) della regione Lombardia, SUT 9 (Sportello Unico del Territorio) e Progetto People 10 della regione Marche. A livello nazionale invece esistono due progetti che riguardano la Carta di Identità Elettronica (CIE) e la Carta Nazionale dei Servizi (CNS) per l autenticazione dell individuo e l accesso ai servizi delle pubbliche amministrazioni. La CIE è stata emessa dai comuni in sostituzione della carta d identità tradizionale. Essa adotta una smart card ibrida (cioè che presenta, oltre al14 Capitolo 1 microchip, anche una banda ottica) e i dati del titolare (compresa la foto) sono impressi in modo visibile sul supporto fisico della scheda e memorizzati sia all interno del chip che della banda ottica. Questa doppia tecnologia da garanzie sulla sicurezza dei dati e consente il riconoscimento in rete del titolare. La carta d identità elettronica è stata individuata come strumento di semplificazione del rapporto tra Pubblica Amministrazione e cittadini, cercando di salvaguardare diversi obiettivi, tra i quali: maggiore sicurezza nel processo di identificazione ai fini di polizia; utilizzo quale strumento di identificazione in rete per l accesso ai servizi telematici; completa interoperabilità su tutto il territorio nazionale. Per quanto riguarda la Carta Nazionale dei Servizi, invece, questa definisce uno standard per favorire la convergenza degli strumenti di identificazione digitale. La CNS, progettata parallelamente alla CIE, ha il fine di anticipare le funzioni di accesso ai servizi in rete e rappresenta il punto di riferimento per l emissione di carte multiservizi. Mediante questa carta, infatti, è possibile ottenere servizi sanitari, fiscali, usufruire di sistemi di pagamento bancari e postali e utilizzare la firma digitale. 815 Crittografia Capitolo 2. CRITTOGRAFIA 916 Capitolo Concetti base di crittografia La crittografia è la disciplina che studia la trasformazione di dati allo scopo di nascondere il loro contenuto semantico, impedire il loro utilizzo non autorizzato, o impedire qualsiasi loro modifica non rilevabile 11. Il termine deriva dal greco crypto che significa nascondere e graphein che significa scrivere, infatti la crittografia è stata definita anche come la scienza della scrittura segreta 12. Parallelamente alla crittografia si sviluppa un altra disciplina che prende il nome di crittoanalisi e si occupa di recuperare il contenuto di un messaggio cifrato senza disporre delle informazioni necessarie alla decifratura. Ambedue le discipline sono governate da una branca della matematica che va sotto il nome di crittologia. La crittografia è stata sempre presente nella storia dell uomo, anche se in forme diverse. Il più semplice esempio risale ai tempi di Giulio Cesare che nella sua corrispondenza scambiava l ordine delle lettere spostandole di quattro verso destra in modo che la A risultasse la D e così via. Figura 1. Esempio di cifrario di sostituzione monoalfabetica impiegato da Giulio Cesare. E una tecnica molto semplice di cifrario di sostituzione monoalfabetica che risulta completamente inefficace una volta noto l algoritmo utilizzato. L evoluzione delle tecniche crittografiche ha avuto una svolta proprio quando si è deciso di rendere pubblici gli algoritmi di cifratura e decifratura dei messaggi, legando la capacità di leggerne correttamente il contenuto ad una ulteriore informazione che è appunto la chiave di decifratura. Da qui nascono le moderne tecniche di crittografia come la crittografia simmetrica e quella 11 Bruce Schneider: Applied Cryptography Second Edition: protocols, algorithms and source code in C 12 Jonathan Knudsen: Java Cryptography. 1017 Crittografia asimmetrica che vedremo approfonditamente nei prossimi paragrafi. I vantaggi che questo nuovo modo di pensare ha portato sono molti: la pubblicazione degli algoritmi rende possibile il loro studio da parte dei crittoanalisti di tutto il mondo consentendo di scoprirne eventuali debolezze; come conseguenza del punto precedente si hanno nuovi algoritmi sempre più sicuri; si rendono molto più accessibili le tecniche di protezione dati anche ad aziende che non dispongono di personale specializzato. Grazie a queste nuove tecniche un sistema crittografico è in grado di garantire i seguenti requisiti: Autenticazione d identità: verifica dell identità di una o entrambe le parti coinvolte in una comunicazione; Integrità dei dati: il documento trasmesso deve contenere tutte le informazioni in esso presenti sin dalla redazione, con la possibilità di verificare le eventuali alterazioni, intenzionali o meno, che i dati possono aver subito attraversando un canale insicuro; Autenticità dei dati: verifica dell effettiva identità del mittente; Non ripudio: impossibilità, da parte sia del mittente che del destinatario, di negare l avvenuto scambio di dati. Nel seguito del capitolo andremo a studiare le principali tecniche di crittografia simmetrica e asimmetrica, analizzandone il principio di funzionamento, i pregi e i difetti. Verranno inoltre fornite delle brevi indicazioni sugli algoritmi che queste tecniche adottano, focalizzando maggiormente l attenzione sull algoritmo RSA, in quanto è forse il più conosciuto ed è quello impiegato nello sviluppo di questo progetto. Negli esempi e negli schemi che verranno riportati si farà spesso riferimento ad un ipotetico scambio di dati tra un Mittente e un Destinatario. La situazione si presenta in questo modo: 1118 Capitolo 2 Mittente Messaggio in chiaro Cifratura Messaggio cifrato Destinatario Chiave Chiave Canale di trasmissione Messaggio in chiaro Decifratura Messaggio cifrato Figura 2. Schema di principio di una comunicazione cifrata tra due entità Il messaggio originale (messaggio in chiaro) viene opportunamente cifrato con una apposita chiave. Il risultante messaggio cifrato sarà spedito sul canale di trasmissione e giungerà al destinatario che effettuerà le operazioni di decifratura per recuperare il contenuto originale del messaggio. Lungo il canale il messaggio è visibile a tutti, ma questo non compromette la sicurezza della comunicazione in quanto, essendo cifrato, solo chi è in possesso dell apposita chiave è in grado di comprenderne il contenuto. 2.2 Crittografia Simmetrica La crittografia simmetrica, detta anche a chiave segreta, utilizza algoritmi che impiegano un unica chiave sia per le operazioni di cifratura sia per quelle di decifratura 13. Il mittente e il destinatario devono essere in possesso della stesa chiave per fare in modo che l intera operazione abbia successo. L uso di una chiave diversa comporterebbe l impossibilità di recuperare le informazioni dal messaggio cifrato e, di conseguenza, la necessità di ripetere la trasmissione. La sicurezza è garantita fintantoché la chiave rimane a conoscenza solo dei due interlocutori e segreta ad ogni altro Da qui il nome di crittografia simmetrica. 14 Da qui il nome di crittografia a chiave segreta. 1219 Crittografia Lo schema di funzionamento è il seguente: Mittente Messaggio in chiaro Cifratura Messaggio cifrato Chiave Canale sicuro Canale insicuro Destinatario Messaggio in chiaro Decifratura Messaggio cifrato Figura 3. Schema di funzionamento di una comunicazione cifrata con tecnica simmetrica. Come si può vedere il funzionamento è molto simile allo schema di crittografia di base introdotto precedentemente. Si può notare però l impiego di due canali di trasmissione: un canale sicuro 15 riservato alla chiave segreta ed un canale insicuro in cui viene spedito il messaggio cifrato. Il mittente e il destinatario devono innanzitutto concordare in segreto la chiave da utilizzare per la cifratura e decifratura, il mittente quindi, prima dell invio del messaggio, genera la chiave segreta e la spedisce al destinatario attraverso un canale sicuro. Il difetto principale di questa tecnica sta proprio in questo scambio, in quanto, anche se si adotta un canale sicuro, c è sempre il rischio che le informazioni vengano intercettate e, poiché l informazione che sta viaggiando in rete è proprio la chiave segreta, la sua intercettazione comprometterebbe la sicurezza di tutta la comunicazione. In questo caso infatti verrebbe meno non solo il requisito di segretezza, ma anche quelli di integrità del messaggio ed autenticazione del mittente. Se una terza parte infatti riuscisse ad entrare in possesso della chiave segreta, potrebbe intercettare il messaggio cifrato, modificarlo e cifrarlo di nuovo, senza che il destinatario si accorga di nulla. Un altro svantaggio della crittografia simmetrica riguarda il fatto che ogni utente deve disporre di una chiave diversa per ogni altro utente con cui intenda 15 Ad esempio un canale SSL. 1320 Capitolo 2 comunicare. Questo rappresenta un problema tanto più serio quanto più il numero di utenti è elevato. Per avere un riscontro pratico si pensi che in un generico sistema di n utenti ci si troverebbe a dover gestire un numero di chiavi segrete pari a: n ( n 1) Cifratura a blocchi e a flusso. Gli algoritmi impiegati nella crittografia simmetrica si possono distinguere in due categorie: algoritmi a blocchi: l operazione di cifratura o decifratura viene effettuata su gruppi di bit (o byte, o parole) detti appunto blocchi; algoritmi a flusso: l operazione di cifratura o decifratura viene effettuata sui singoli bit (o byte, o parole). Algoritmi a blocchi Il messaggio da cifrare (o decifrare) viene suddiviso in blocchi di lunghezza prefissata (solitamente 64 bit) e l algoritmo viene applicato ad ognuno di questo blocchi singolarmente. E necessario che il messaggio abbia lunghezza esattamente multipla della dimensione del blocco altrimenti si verifica un errore nell applicazione dell algoritmo. Per evitare questo problema si prevede il riempimento dell ultimo blocco con opportuni caratteri di allineamento. Questo procedimento è noto come pad ed in figura è riportato l esempio di un messaggio suddiviso in n blocchi in cui al blocco n-esimo sono stati aggiunti i caratteri di riempimento (parte tratteggiata). 1421 Crittografia Blocco 1 Blocco 2 Blocco 3.. Blocco n-1 Blocco n Figura 4. Esempio di suddivisione in blocchi di un messaggio e applicazione dei caratteri di riempimento (tratteggio). Esistono diversi modi per eseguire l operazione di pad a seconda dei diversi tipi di dato. Di seguito vengono brevemente descritti quelli più comuni: il più semplice di tutti non fa altro che aggiungere zeri fino al raggiungimento della lunghezza stabilita per il blocco; se i dati sono binari si integra il blocco con bit che sono l opposto degli ultimi bit costituenti il messaggio; nel caso di caratteri ASCII si usano byte di riempimento casuali specificando nell ultimo byte il carattere ASCII corrispondente al numero di byte aggiunti; un ultima tecnica impiega anch essa bit di riempimento casuali, ma negli ultimi tre bit vengono indicati il numero di bit originali (quindi non aggiunti) che costituiscono l ultimo blocco. Un difetto di questa tecnica si incontra quando il messaggio è esattamente multiplo della dimensione del blocco (ad esempio 64 bit) e quindi non si necessiterebbe di alcun tipo di padding. In questo caso si dovrà aggiungere un ulteriore blocco con 61 bit random e gli ultimi tre nulli. Citiamo ora i più comuni algoritmi a blocchi: Electronic Codebook (ECB): è il metodo più semplice in cui il risultato dell operazione dipende solo dal valore della chiave. In questo modo, fissata una chiave K, un certo blocco B al quale viene applicato l algoritmo darà come risultato sempre lo stesso blocco B. Questa caratteristica di univocità del risultato apre la strada all elaborazione parallela, in cui diversi blocchi del messaggio possono essere trasformati in modo indipendente (anche da più calcolatori) ottenendo lo stesso risultato di una elaborazione singola ma a tutto vantaggio della velocità di esecuzione. L altra faccia della medaglia riguarda il fatto che un crittoanalista (o peggio un hacker che sia entrato in possesso della 1522 Capitolo 2 chiave segreta) può risalire dal messaggio cifrato a quello originale tramite un attacco a forza bruta, ovvero cifrando diversi messaggi fino a che non ottiene la stessa sequenza cifrata 16. Cipher Block Chaining (CBC): questa tecnica prevede che ciascun blocco in chiaro venga messo in XOR con in blocco cifrato precedente e poi ulteriormente cifrato con la chiave segreta. Questo modo di procedere fa si che il risultato dell operazione ad ogni blocco dipenda non solo dalla chiave utilizzata, ma anche dalla cifratura di tutti i blocchi precedenti. Diventa così impossibile effettuare un attacco a forza bruta su un blocco n-esimo del messaggio senza conoscere anche i precedenti, in quanto non è più detto che due blocchi uguali, cifrati con la stessa chiave, diano lo stesso risultato. Rimane il fatto però che due messaggi identici saranno cifrati in modo identico. Per evitare ciò viene allora inserito in testa ad ogni blocco da cifrare un vettore di inizializzazione, che non è altro che un blocco casuale di dati. Cipher Feedback (CFB): i blocchi vengono incatenati in modo molto simile a quello della tecnica precedente. In questo caso però ogni blocco cifrato viene messo in XOR con il corrente blocco in chiaro spezzettato in segmenti più piccoli. La cifratura elementare di un blocco viene quindi effettuata su gruppi di 4 o 8 bit alla volta man mano che questi giungono al cifratore. L idea è quella di elaborare i dati non appena divengono disponibili invece di aspettare che un blocco sia del tutto completato. Algoritmi a flusso Negli algoritmi simmetrici a flusso il messaggio in chiaro si presenta in ingresso come un stream (un flusso, appunto) di dati e l operazione di cifratura (o decifratura) viene effettuata su ogni singolo bit (o byte) di ingresso. Più in dettaglio questi algoritmi fanno uso di un generatore di bit che, a seconda della chiave fornita, è in grado di produrre una sequenza di bit 16 Si intende in questo tipo di attacco che la terza persona (crittoanalista o hacker che sia) sia a conoscenza della chiave segreta e comunque la buona riuscita dell attacco richiede tempi lunghissimi (tanto più lunghi quanto più è grande il blocco). 1623 Crittografia apparentemente casuale 17. Nell effettiva operazione di cifratura i dati in ingresso vengono messi in XOR con i dati provenienti dal generatore. In questo modo non si verifica mai che due messaggi identici, cifrati con la stessa chiave, diano origine a due messaggi cifrati uguali. Gli algoritmi a flusso a loro volta si possono dividere in due categorie: Algoritmi autosincronizzanti: in questo tipo di algoritmi il generatore di numeri casuali prende in ingresso, ad ogni passo, anche un certo numero di bit cifrati precedentemente. Quindi, comunque sia fissata una chiave, uno stesso bit (o byte) potrà essere cifrato ogni volta in modo diverso a seconda delle precedenti informazioni elaborate dal flusso in ingresso. Algoritmi sincroni: in questi algoritmi il flusso di bit generati è completamente indipendente dal flusso di dati in ingresso. Questo comporta il vantaggio di ridurre la propagazione degli errori: si pensi ad esempio ad un canale di trasmissione rumoroso in cui si verifica un errore su un bit durante l invio del messaggio cifrato. In ricezione il decifratore sbaglierà, ovviamente, il bit incriminato, ma questo errore non si ripercuoterà su altri bit, in quanto non c è la dipendenza dagli stati precedenti (come invece avviene nel caso degli algoritmi autosincronizzanti) I principali algoritmi di cifratura simmetrica Verranno ora presentati alcuni tra i più noti algoritmi impiegati nella crittografia simmetrica. Per ognuno di essi si illustreranno i concetti base riguardanti il loro funzionamento e si effettueranno delle brevi considerazioni sulla loro sicurezza. 17 Tale sequenza di bit pseudocasuali è il risultato di complesse operazioni aritmetiche che si basano sui parametri costituenti la chiave. Di fatto risulta (quasi) impossibile prevedere la sequenza generata senza conoscere la chiave. 1724 Capitolo 2 Data Encryption Standard (DES) Il Data Encryption Standard (DES) venne adottato dal governo degli Stati Uniti nel 1977 come standard per la crittografia simmetrica. E stato sviluppato dalla IBM come evoluzione di un altro algoritmo, Lucifer, risalente ai primi anni 70. Sebbene la sua validità dovesse essere programmata di 5 o 10 anni, il DES è rimasto un riferimento per molti anni a seguire 18. L algoritmo che utilizza, il DEA (Data Encryption Algorithm), rientra nella classe dei codici a blocchi ed è utilizzabile con tutti i modelli visti precedentemente. Ogni blocco ha la dimensione di 64 bit. Più in dettaglio il DES impiega blocchi di 64 bit ed utilizza chiavi di cifratura di 64 bit suddivise in 8 sottoblocchi di 8 bit ciascuno. L ultimo bit di ogni sottoblocco è di controllo, di conseguenza è come se avessimo a che fare con una chiave a 56 bit. Durante la cifratura il blocco di testo in chiaro viene innanzitutto trasposto e poi diviso in una metà destra e una metà sinistra di 32 bit ciascuna. In seguito, ad ognuna di queste metà, vengono applicate 16 passate (dette round) tramite una funzione che opera trasposizioni e sostituzioni mediante apposite sottochiavi 19. Durante ogni round l output della metà sinistra diventa l input della destra e viceversa. Dopo il completamento di tutti i round i due sottoblocchi vengono riuniti e il risultato permutato per invertire la trasposizione iniziale. L operazione di decifratura avviene in modo del tutto analogo, con la sola accortezza di assegnare le sottochiavi in ordine inverso a quello utilizzato durante la cifratura. Questo algoritmo, che potrebbe a prima vista sembrare molto cavilloso, in realtà sfrutta operazioni molto semplici come trasposizione, sostituzione e XOR di bit. Nonostante abbia resistito anche più del dovuto come standard, il DES non è considerato un algoritmo molto sicuro ed è utilizzato per la cifratura di dati relativamente importanti. Il difetto maggiore è il limitato spazio delle chiavi (keyspace 20 ) di cui dispone che è pari a Esistono inoltre delle 18 Già nei primi anni 90 non era più considerato abbastanza sicuro e nel 1998 è stato violato per la prima volta. 19 Le sottochiavi vengono ricavate dividendo i bit effettivi che costituiscono la chiave in due sottoblocchi di 28 bit ciascuno. Ad ogni round questi semiblocchi vengono sciatati verso sinistra dando origine alle sottochiavi. 20 Per keyspace si intende l insieme di tutte le chiavi, diverse l una dall altra, ricavabili come combinazione di n bit (dove n rappresenta la dimensione della chiave). 1825 Crittografia perplessità riguardanti la sua sicurezza derivanti dal ruolo che ha avuto l NSA 21 nel validare l algoritmo. In particolare si contesta la scelta di ridurre la dimensione delle chiavi da 128 bit a 64 bit, dando adito a congetture sulla robustezza di DES. Triple DES (TDES) Una evoluzione del DES può essere considerata il triplo-des (noto anche come DESede), così denominato in quanto utilizza tre chiavi indipendenti in tre diversi passaggi. Ci sono molte varianti del TDES, di seguito ne illustreremo due tra le più comuni. La prima impiega sue chiavi K 1 e K 2 di 56 bit ciascuna raddoppiando così l effettiva lunghezza della chiave (che ora è di 112 bit) ed incrementando il keypsace di un fattore Ogni blocco di 64 bit viene prima cifrato con la prima chiave (K 1 ), poi decifrato con la seconda (K 2 ), poi di nuovo cifrato ancora con la prima chiave (K 1 ). Questo modo di procedere rende TDES un algoritmo molto più sicuro del precedente. Una particolarità riguarda il fatto che se le due chiavi K 1 e K 2 risultassero uguali, allora l applicazione di questo algoritmo porterebbe un risultato identico all applicazione dell algoritmo DES. Un altra versione di TDES sfrutta tre chiavi diverse e indipendenti da 56 bit ciascuna, con un effettivo keyspace di 168 bit. Ogni blocco viene cifrato per tre volte, ogni volta con una chiave diversa. E sicuramente un algoritmo più complesso e più costoso (soprattutto in termini di tempo) dei precedenti, ma è anche il più sicuro. Advanced Encryption Standard (AES) E un algoritmo di cifratura a blocchi, noto anche come algoritmo di Rijndael 22, sviluppato dai crittografi belgi Joan Daemen e Vincent Rijmen. E stato adottato dalla National Institute of Standards and Technology (NIST) e dalla US Federal Information Processing Standard (FIPS) nel novembre National Security Agency 22 Più propriamente AES è una particolare implementazione dell algoritmo Rijndael. 1926 Capitolo 2 Ogni blocco ha dimensione fissa di 128 bit e possono essere impiegate chiavi di 128, 192 o anche 256 bit. AES opera su delle matrici chiamate stati. Con 128 bit in input (ovvero le dimensioni di un blocco) ogni stato è composto da 4 righe e 4 colonne di 32 bit ciascuna, cioè matrici di 4x4 byte. Durante la cifratura, ad ogni fase (round), vengono eseguite le operazioni sostituzione, spostamento, combinazione lineare dei byte ed inoltre ogni byte viene combinato in XOR con una chiave di sessione calcolata dal gestore delle chiavi. Questo algoritmo presenta molti vantaggi, primo fra tutti la possibilità di impiego di chiavi di lunghezza diversa e comunque tale da garantire un ottimo livello di sicurezza. Si pensi che, secondo l NSA, la dimensione di una chiave impiegata per cifrare dati Top Secret deve essere di 192 o 256 bit. Inoltre AES è di facile implementazione sia hardware che software e le sue richieste di risorse sono limitate. Questo lo rende applicabile a qualsiasi tipo di strumento capace di eseguire operazioni crittografiche ed è un grosso incentivo per la sua diffusione. International Data Encryption Algorithm (IDEA) IDEA è nato nel 1991 sotto il nome di IPES (Improved Proposed Encryption Standard) ideato dai crittologi Xuejja Lai e James L. Massey. E anch esso un algoritmo a blocchi di 64 bit ed è applicabile a tutti i modelli di cifratura a blocchi. Utilizza chiavi a 128 bit e l operazione di cifratura comporta una divisione del blocco in chiaro in quattro sottoblocchi di 16 bit. Ognuno subisce otto round di trasformazioni durante le quali vengono eseguite le operazioni di XOR dei bit, addizione e moltiplicazione modulare. Nell ultimo round i quattro sottoblocchi vengono concatenati per produrre il blocco cifrato. Durante gli otto round sono coinvolte nelle operazioni 52 chiavi diverse (sei per ogni round) che vengono ricavate dividendo la chiave iniziale in otto stringhe di 16 bit che costituiscono le prime otto chiavi. In seguito i 128 bit della chiave originale vengono shiftati di 25 bit a sinistra ottenendo una nuova sequenza che verrà ancora divisa in otto stringhe a 16 bit per ricavare altre otto sottochiavi. Iterando il procedimento si ricavano tutte le 52 sottochiavi. 2027 Crittografia L operazione di decifratura è identica eccezion fatta per il modo con cui vengono ricavate le sottochiavi. Offre un buon grado di sicurezza, al livello del TDES 23 ed il suo utilizzo per scopi non commerciali è libero. RC2 e RC4 Questi algoritmi sono stati sviluppati dalla RSA Data Security Inc. e l ideatore è Ron Rivest 24. Sono algoritmi applicabili sia nella cifratura a blocchi che in quella a flusso. In particolare RC2 opera una tripla cifratura, come nel caso TDES, ma risulta molto più veloce. La caratteristica dei due algoritmi è che utilizzano chiavi di lunghezza arbitraria come seme per un generatore di numeri pseudo-casuali che vengono messi in XOR con i dati da cifrare. Sono giudicati algoritmi sicuri, ma il loro libero utilizzo è limitato a sole chiavi di lunghezza non superiore di 40 bit. 2.3 Crittografia asimmetrica Nel 1976 Whitfield Diffie e Martin Hellmann, due crittologi americani, pubblicarono uno scritto in cui, ipotizzando di poter disporre di un cifrario asimmetrico, dimostravano la fattibilità di sistemi crittografici di nuovo tipo mediante il concetto di chiavi pubbliche. Un sistema di questo tipo si sarebbe servito di due chiavi distinte, l una l inverso dell altra, con le seguenti caratteristiche: complementari: se una chiave è usata per cifrare l altra deve essere usata per decifrare e viceversa; indipendenti: la conoscenza di una chiave non deve consentire di risalire all altra chiave. Di fatto è stato il punto di inizio dal quale si sono poi sviluppate tutte le tecniche che vedremo nel corso della trattazione. 23 Alcuni crittologi sostengono sia migliore IDEA, altri invece sostengono il contrario. 24 Da cui il nome RC: Ron s Code (o Rivest s Code). 2128 Capitolo 2 La crittografia asimmetrica, detta anche crittografia a chiave pubblica, prevede l utilizzo di due chiavi diverse per le operazioni di cifratura e decifratura. Una di queste chiavi deve rimanere nota al solo possessore, che quindi è l unica persona in grado di utilizzarla. Tale chiave è detta chiave privata. L altra chiave invece può essere resa liberamente nota ed è utilizzabile da qualsiasi utente necessiti il suo impiego in una comunicazione. Tale chiave è detta chiave pubblica. Le due chiavi sono legate matematicamente tra loro, ma costruite in modo che sia impossibile risalire alla chiave privata partendo da quella pubblica. La distribuzione delle chiavi pubbliche avviene tramite l utilizzo di appositi certificati, detti certificati a chiave pubblica, ed è affidata ad una entità detta Autorità di Certificazione. Questi concetti verranno ripresi ed approfonditi nel capitolo successivo riguardante l infrastruttura a chiave pubblica, per ora ci basta sapere che un certificato è un mezzo tramite il quale vengono rese note le chiavi pubbliche di un particolare utente, e l Autorità di Certificazione ci garantisce che quella chiave appartiene effettivamente all utente in questione. Nella crittografia asimmetrica un messaggio cifrato con una delle due chiavi della coppia può essere decifrato solo con la chiave ad essa associata. L ordine di utilizzo delle chiavi è arbitrario ai fini della corretta decifratura, quindi è possibile cifrare un messaggio con la propria chiave privata e decifrarlo con quella pubblica, oppure cifrare con la chiave pubblica e decifrare con quella privata. In ambedue i casi si è capaci di risalire correttamente al messaggio originale, ciò che cambia riguarda alcuni requisiti di sicurezza che vedremo tra poco. Proprio sulla base dell arbitrarietà di utilizzo delle chiavi è possibile dividere gli algoritmi asimmetrici in due categorie: algoritmi a chiave di cifratura pubblica: impiegano la chiave pubblica in cifratura e quella privata in decifratura; algoritmi a chiave di decifratura pubblica: impiegano la chiave privata in cifratura e quella pubblica in decifratura. 2229 Crittografia Algoritmi a chiave di cifratura pubblica Il funzionamento di questo tipo di algoritmi asimmetrici è illustrato nello schema seguente in cui si considera l esempio di una comunicazione tra un generico Mittente ed un altrettanto generico Destinatario. Si indicano con K privd e K pubd rispettivamente le chiavi privata e pubblica del destinatario. Mittente Messaggio in chiaro Cifratura Messaggio cifrato KpubD Canale insicuro KpubD Destinatario KprivD Messaggio in chiaro Decifratura Messaggio cifrato Figura 5. Schema di funzionamento di un algoritmo a chiave di cifratura pubblica. E opportuno fare una considerazione prima di proseguire. Nello schema viene raffigurato l invio della chiave pubblica dal destinatario al mittente (la freccia tratteggiata). Questa rappresentazione vuole solo indicare che la chiave pubblica che si utilizza appartiene effettivamente al destinatario, e che il mittente, in qualche modo, ne viene in possesso. Il modo in cui questo avviene è stato citato ad inizio capitolo e verrà approfondito nella prossima sezione. Il funzionamento dei questo schema è molto semplice e ricorda quello a cifratura simmetrica, eccezion fatta per la distinzione tra chiave pubblica e privata. Il Mittente cifra il messaggio in chiaro con la chiave pubblica del Destinatario, quest ultimo riceve il messaggio cifrato e, tramite l utilizzo della propria chiave privata, riesce a risalire al messaggio originale. Ricordiamo che l impiego di una qualsiasi altra chiave nella decifratura darebbe un risultato del tutto senza senso e, di conseguenza, l impossibilità da parte del destinatario di conoscere il messaggio originale. Questa caratteristica dell algoritmo, unita alla fondamentale proprietà di uso esclusivo delle chiavi 2330 Capitolo 2 private da parte dei soli possessori, garantisce un importante requisito di sicurezza: la segretezza della comunicazione. Infatti il Mittente, utilizzando la chiave pubblica del Destinatario, sa che quel messaggio potrà essere decifrato solo dall effettivo possessore della chiave associata. Anche se il cifrato venisse intercettato da una terza entità (ricordiamo che si fa uso di un canale insicuro) questa non sarà capace di comprenderne il significato. Il difetto di questo schema sta nel fatto che il Destinatario non può essere sicuro dell effettiva identità del mittente, in quanto chiunque può procurarsi la sua chiave pubblica e spedirgli dei messaggi cifrati. Algoritmi a chiave di decifratura pubblica Lo schema di funzionamento è illustrato nella figura seguente in cui con K privm e K pubm si intendono rispettivamente le chiavi privata e pubblica del mittente. Anche in questo caso valgono le considerazioni dell esempio precedente riguardanti lo scambio della chiave pubblica tra i due interlocutori. 2431 Crittografia Mittente Messaggio in chiaro Cifratura Messaggio cifrato KprivM KpubM Canale insicuro Destinatario KpubM Messaggio in chiaro Decifratura Messaggio cifrato Figura 6. Schema di funzionamento di un algoritmo a chiave di decifratura pubblica. Il Mittente cifra il messaggio in chiaro con la propria chiave privata ed il Destinatario utilizza la chiave pubblica del Mittente per decifrare il messaggio. In questo modo, se il destinatario riesce a recuperare correttamente il messaggio originale, vuol dire che questo è stato cifrato con la chiave privata associata a quella pubblica che ha utilizzato nella decifratura, e solo una persona ha la facoltà di usufruire di detta chiave privata: il Mittente. In altre parole il destinatario è sicuro dell effettiva identità del mittente, viene cioè garantito con questo schema un altro requisito di sicurezza fondamentale: l autenticazione d identità. Dall altra parte però viene meno la caratteristica di segretezza (tipica del caso precedente) in quanto chiunque può venire a conoscenza della chiave pubblica del mittente e quindi chiunque è in grado di decifrare il messaggio. Questo tipo di cifratura trova largo impiego nei sistemi che fanno uso della firma digitale, come vedremo più avanti nel corso del capitolo. Uso combinato delle due tecniche Abbiamo visto come i due schemi di cifratura asimmetrica riescano a garantire alternativamente la segretezza della comunicazione e l autenticazione del mittente. Sono però queste due caratteristiche troppo importanti che devono 2532 Capitolo 2 essere presenti contemporaneamente in una comunicazione crittografata. Si può allora pensare di adottare contemporaneamente i due schemi in modo combinato così da poter raggiungere un livello di sicurezza ancora maggiore. Il risultato dell impiego delle due tecniche è riportato nel seguente schema: Mittente Text Cifratura T Cifratura Cipher KprivM KpubD Canale insicuro Destinatario Text Decifratura T Decifratura Cipher KpubM KprivD Figura 7. Schema di utilizzo della cifratura asimmetrica per l invio di un messaggio autenticato e segreto. Con Text si vuole indicare il messaggio in chiaro, T rappresenta un messaggio cifrato intermedio diverso da quello finale che viene spedito al mittente e che è invece indicato con Cipher. Per quanto riguarda le chiavi si ha la stessa nomenclatura dei casi precedenti. Avvengono due successive operazioni di cifratura: prima il Mittente cifra il messaggio in chiaro con la propria chiave privata ottenendo un messaggio intermedio T ; poi T viene ancora cifrato con la chiave pubblica del Destinatario ottenendo il messaggio cifrato finale (Cipher). In ricezione il Destinatario andrà a decifrare il messaggio prima impiegando la sua chiave privata e poi quella pubblica del Mittente. 2633 Crittografia In realtà, in cifratura, l ordine di utilizzo delle due chiavi è arbitrario, ma deve essere noto, in quanto chi riceve il messaggio dovrà eseguire la decifratura impiegando le chiavi in ordine inverso. In termini di sicurezza l utilizzo della chiave privata del mittente garantisce la proprietà di autenticazione del messaggio, mentre l impiego della chiave privata del destinatario garantisce la segretezza della trasmissione. Un ultima considerazione riguarda l incremento del numero delle chiavi all aumentare del numero di utenti che vogliono comunicare tra loro. Questo problema era particolarmente sentito nella crittografia simmetrica in cui si aveva un incremento quadratico delle chiavi. Nella crittografia asimmetrica non è invece necessario che un utente crei una chiave diversa per ogni comunicazione con un altro utente. Ognuno infatti dispone di una propria coppia di chiavi ed utilizza sempre questa coppia per comunicare con qualsiasi altro utente. In questo modo si ha un incremento lineare del numero di chiavi in funzione del numero di utenti. Nella realtà lo schema appena descritto non è molto utilizzato perché piuttosto complesso. Non è raro invece l utilizzo di tecniche miste che uniscono la semplicità della crittografia simmetrica con la sicurezza di quella asimmetrica. L esempio più immediato riguarda la tecnica impiegata nel protocollo SSL 25 in cui, nella comunicazione tra due entità, viene creata al volo una chiave segreta, detta chiave di sessione, per cifrare il messaggio. La chiave a sua volta viene cifrata con la chiave pubblica del destinatario ed allegata al messaggio stesso I principali algoritmi di cifratura asimmetrica La crittografia asimmetrica consente di cifrare solo blocchi di dati di dimensione fissa. E infatti impossibile cifrare i dati in ingresso bit a bit come avveniva negli algoritmi simmetrici a flusso. Possiamo quindi dire che la crittografia asimmetrica lavora solo su blocchi di bit. 25 Secure Socket Layer, chiamato nelle sue ultime versioni con il nome di Transport Layer Security (TLS). 2734 Capitolo 2 In questo paragrafo verranno introdotti alcuni tra i più noti algoritmi di crittografia asimmetrica, andando ad esaminare più in dettaglio solo uno tra questi, l algoritmo RSA, che, oltre ad essere forse il più famoso, è quello impiegato in questo progetto di firma digitale. Rivest Shamir Adelman (RSA) L algoritmo RSA è stato sviluppato da Ron Rivest, Adi Shamir e Len Adelman 26. Descritto per la prima volta nel 1977 è stato poi brevettato nel 1983 negli Stati Uniti dal MIT 27. Si basa sul problema matematico della fattorizzazione di un numero, che consiste nel trovare quei numeri primi che, moltiplicati tra loro, forniscono il numero dato. E questo un problema tanto più complesso quanto più è grande il numero iniziale. Forniamo ora una breve descrizione dell algoritmo. Per generare la coppia di chiavi si eseguono queste operazioni: 1. si scelgono due numeri primi p e q abbastanza grandi da garantire un adeguato livello di sicurezza; 2. si calcola il prodotto n = p q (detto modulo); 3. si sceglie un numero e (detto esponente pubblico) che sia più piccolo e primo rispetto a ( p 1) ( q 1) ; 4. si calcola un numero d (detto esponente privato) tale che: ( d ) mod [( p 1) ( q 1) ] = 1 e ; 5. la coppia ( n, e) costituisce la chiave pubblica, mentre la coppia ( n, d ) costituisce la chiave privata. A questo punto le chiavi sono state create ed i fattori p e q possono essere distrutti (anche se in realtà vengono mantenuti all interno della chiave privata). Due chiavi create in questo modo sono chiaramente legate tra loro (dal fattore n) e inoltre per calcolare d da e (e quindi la chiave privata a partire da quella pubblica) non basta conoscere n, ma serve anche il prodotto ( p 1) ( q 1) soprattutto se n è grande.. In ogni caso è un operazione molto costosa in termini di tempo, 26 Il nome RSA è infatti acronimo dei loro cognomi. 27 Massachusetts Institute of Technology. 2835 Crittografia privata L operazione di cifratura avviene nel seguente modo: 1. l utente si procura la chiave pubblica del destinatario ( n, e) ; 2. il messaggio in chiaro m viene cifrato attraverso l operazione c = m e mod( n), in cui c indica il messaggio cifrato. L operazione di decifratura prevede che l utente, con la propria chiave ( n, d ), compia la seguente operazione: m = c d mod( n). L algoritmo permette anche di invertire l ordine di utilizzo delle chiavi, cioè è possibile cifrare con la chiave privata e decifrare con quella pubblica. In ogni caso il procedimento restituisce il messaggio originale solo se le chiavi utilizzate nella cifratura e nella decifratura appartengono alla stessa coppia, e sono quindi legate dal fattore n secondo la relazione descritta nel punto 4. Da questa breve presentazione nasce però un dubbio sulla sicurezza e dell algoritmo, in quanto si basa sull assunzione che il calcolo di c ( n) mod (con n numero composto di cui non si conoscono i fattori) sia computazionalmente intrattabile 28. Il dubbio nasce dal fatto che questa assunzione non è mai stata dimostrata! Digital Signature Algorithm (DSA) L algoritmo DSA, proposto nel 1991 dal NIST per l utilizzo nell ambito dello standard DSS (Digital Signature Standard), è stato progettato appositamente per la realizzazione di firme digitali. Il procedimento di cifratura infatti prevede anche l utilizzo di una funzione di Hash 29 (nello specifico la funzione SHA) ed apposite operazioni di verifica della firma. Esso si basa sulla difficoltà di risoluzione del problema del logaritmo discreto. In linea teorica sarebbe possibile ricavare la chiave privata calcolando il logaritmo discreto di quella pubblica. Nella realtà però questa operazione è impraticabile a causa della grandezza dei numeri in gioco. Tale algoritmo però non viene molto utilizzato in quanto esistono algoritmi ritenuti molto più sicuri. 28 Nota come assunzione RSA. 29 La funzione di Hash sarà illustrata tra poco in questo stesso capitolo. 2936 Capitolo Considerazioni generali sulla sicurezza degli algoritmi crittografici Ogni algoritmo crittografico viene studiato dai crittoanalisti per valutarne l effettiva robustezza a vari tipi di attacchi e quindi misurarne la sicurezza. Nel corso di tutto il capitolo sono stati presentati molti algoritmi diversi tra loro, ognuno con determinate caratteristiche che lo rendevano più o meno sicuro di un altro. Come detto ad inizio capitolo, però, l evoluzione crittografica più importante si è verificata quando è stato abbandonato il principio di security by obscurity secondo il quale un sistema (in questo caso un particolare algoritmo crittografico) risulta sicuro fintantoché rimane segreto alle persone non autorizzate ad accedervi, in quanto, non conoscendolo, non sono in grado di violarlo. Ad esso si è sostituito il concetto, che è diventato un fondamento della crittografia moderna, secondo il quale la sicurezza di un sistema crittografico dipende esclusivamente dalla conoscenza della chiave. Tutti gli algoritmi introdotti nei paragrafi dedicati alla crittografia simmetrica e asimmetrica sono infatti di dominio pubblico ed il loro funzionamento è noto a chiunque, eppure questo non costituisce una minaccia alla loro sicurezza, anzi, al contrario, è un incentivo al loro sviluppo, in quanto è più facile scoprirne difetti e debolezze e quindi porvi rimedio. Ciononostante la chiave non è altro che una sequenza di bit generata in modo più o meno casuale che, in linea teorica, può sempre essere ricavata. Esistono infatti dei metodi di ricerca esaustiva che consentono di risalire alla chiave utilizzata nella cifratura provando ad applicare l algoritmo ad un testo cifrato, impiegando chiavi sempre diverse, fino a che non si ottiene un risultato sensato. Questo modo di procedere è noto come attacco a forza bruta (brute force attack). Il successo di questo tipo di attacchi dipende dal numero massimo di tentativi che possono essere fatti, ovvero dal numero massimo di chiavi che quel particolare algoritmo può accettare, cioè dal keyspace. Per darci un idea di quanto influisca la lunghezza della chiave in un attacco a forza bruta si può considerare l esempio riportato in tabella che indica 3037 Crittografia i tempi necessari al completamento dell attacco variando le dimensioni della chiave, sotto l ipotesi di poter effettuare un milione di tentativi al secondo. Lunghezza della chiave Dimensioni del keyspace Tempo di ricerca 32 bit 4,29*10 9 1,2 ore 40 bit 1,1* giorni 48 bit 2,81* ,9 anni 56 bit 7,21* anni 64 bit 1,84* anni Tabella 1. Tempo di ricerca necessario per un attacco a forza bruta nell ipotesi che si possano effettuare un milione di tentativi al secondo. Ancora una volta la sicurezza del sistema è legata solo alla chiave ed in particolare ad una sua caratteristica che è la lunghezza. Si può decidere di scegliere una chiave talmente lunga da rendere materialmente impossibile un attacco a forza bruta 30, questo però comporterebbe anche una notevole riduzione delle prestazioni del nostro sistema, in quanto una chiave più lunga richiederebbe calcoli più complessi e quindi un rallentamento delle operazioni di cifratura e decifratura. Occorre quindi trovare un giusto compromesso tra il grado di sicurezza che si vuole raggiungere e la velocità di esecuzione richiesta 31. In generale, quando si vuole realizzare un sistema di sicurezza, bisogna sempre tenere presente che tipo di dati si stanno proteggendo. Il livello di sicurezza del sistema deve essere tanto più alto quanto più sono sensibili le informazioni in gioco. In quest ottica è opportuno seguire due linee guida: il costo 32 richiesto per violare l algoritmo deve essere superiore al valore dei dati protetti; il tempo richiesto per violare l algoritmo deve risultare superiore al tempo per cui i dati cifrati devono rimanere segreti. 30 Si intende con le tecnologie attualmente disponibili. In futuro un aumento delle capacità di calcolo o una nuova tecnica di crittoanalisi potrebbe ridurre drasticamente i tempi necessari al recupero della chiave. 31 Si pensi in particolare al caso della Smart Card che sono dispositivi estremamente sicuri, ma con limitatissime risorse di calcolo. 32 Si intende costo non solo in senso monetario, ma anche in termini di risorse e tempo impiegati. 3138 Capitolo 2 Sotto queste ipotesi, qualsiasi tentativo di attacco, anche se andasse a buon fine, non comporterebbe alcun vantaggio al soggetto attaccante. 2.5 Funzione di Hash La funzione di Hash è un processo di trasformazione dei bit, che si differenzia dagli algoritmi crittografici finora trattati. Un qualsiasi messaggio elaborato tramite funzione di Hash restituisce una stringa di bit di lunghezza fissa (solitamente 128 o 160 bit), detta message digest (impronta digitale). Tale impronta rappresenta una sorta di riassunto, o sintesi matematica, del messaggio. Andiamo ora ad enunciare le proprietà che caratterizzano la funzione di Hash e che la rendono crittograficamente sicura : è applicabile a qualsiasi sequenza di dati di qualsiasi tipo e dimensione; il risultato della sua applicazione è una stringa di bit di dimensione fissa (128 o 160bit) indipendente dalla dimensione del messaggio originale; la variazione di un solo bit del messaggio originale comporta la variazione dell intero digest; è una funzione a senso unico (one way), cioè risulta impossibile risalire al messaggio originale partendo dal digest; è una funzione senza collisioni (collision free), nel senso che è impossibile trovare due messaggi diversi tra loro che restituiscano lo stesso digest. E necessario a questo punto fare una precisazione. Negli ultimi due punti si è utilizzato il termine impossibile. Questo in realtà non è del tutto corretto, sarebbe più opportuno parlare di bassa probabilità piuttosto che di impossibilità. Come abbiamo detto, la funzione di Hash restituisce sempre una sequenza di lunghezza fissa indipendentemente dal tipo e dalla dimensione del messaggio originale. In termini più precisi si può dire che la funzione di Hash realizza una applicazione non iniettiva che ha come dominio uno spazio a dimensione infinita (che rappresenta l insieme di tutti i messaggi in chiaro di 3239 Crittografia qualsiasi lunghezza) e come codominio uno spazio a dimensione finita (che rappresenta l insieme di tutti i possibili digest di lunghezza prefissata). Figura 8. Rappresentazione della funzione di Hash come applicazione dall insieme infinito V dei messaggi in chiaro all insieme finito W di tutti i possibili digest di lunghezza prefissata. Di fatto effettua una compressione dello spazio, per questo motivo prima è stata utilizzata l espressione di riassunto matematico per definire l impronta di un messaggio. Risulta però matematicamente impossibile (e questa volta il termine è impiegato correttamente) che ad ogni elemento del dominio corrisponda un unico elemento del codominio! La matematica comunque ci assicura anche che la probabilità che a due elementi distinti del dominio corrisponda uno stesso elemento del condominio è, se pur diversa da zero, estremamente bassa. In senso pratico non si sono ancora trovati due messaggi diversi che abbiano lo stesso digest. Da questa considerazione si può ritenere ragionevole l assunto che la funzione di Hash risulti crittograficamente sicura, cioè a senso unico e priva di collisioni. Una conseguenza immediata di quest ultima proprietà è che può risultare altrettanto ragionevole dire che due messaggi che presentato lo stesso digest sono uguali tra loro. Questa è una definizione particolarmente interessante in quanto ci permette di utilizzare la funzione di Hash ogniqualvolta ci interessi confrontare due messaggi tra loro per verificarne l uguaglianza. Essendo i 3340 Capitolo 2 messaggi di dimensioni arbitrarie, infatti, risulta sicuramente più comodo eseguire il confronto direttamente sui digest che sono a lunghezza fissa. Questa tecnica apre la strada ad una delle più importanti applicazioni della funzione di Hash: la firma digitale. Prima di concludere il paragrafo facciamo una veloce panoramica sugli algoritmi che la funzione di Hash utilizza: MD5 (Message Digest 5): è un algoritmo sviluppato dai laboratori RSA che fornisce digest di 128 bit; SHA (Secure Hash Algorithm): chiamato anche Secure Hash Standard (SHS) è un algoritmo pubblicato dal Governo degli Stati Uniti che produce digest di 160 bit; SHA-1: è la versione migliorata del precedente algoritmo. Produce anch esso digest di 160 bit, ma, a differenza del suo predecessore, l SHA-1 non è stato ancora violato. 2.6 Firma Digitale Si è già discusso sulla tendenza, da parte di enti pubblici e privati, ad eliminare (o quantomeno ridurre) la documentazione cartacea e favorire quella digitale, evidenziando i vantaggi che questo comporterebbe in termini di: migliore gestione degli archivi; più efficienza nei servizi; minor costo; realizzazione di sistemi sicuri che garantiscano: autenticazione d identità, integrità dei dati, autenticità dei dati, non ripudio. La firma digitale rende possibile tutto questo in quanto, lo dice la parola stessa, consente la firma di documenti direttamente in formato digitale. Questo processo deve essere ovviamente regolamentato da opportune normative giuridiche che garantiscano adeguati livelli di sicurezza, ma di queste ci occuperemo nel prossimo paragrafo. La firma digitale è una tecnologia matematico-informatica che consente la creazione e la gestione di documenti informatici sicuri, ovvero documenti dei 3441 Crittografia quali sia possibile attribuirne la provenienza soggettiva e verificarne l integrità del contenuto dal momento della loro formazione. Alla base del processo di firma digitale troviamo due concetti già noti, che sono la crittografia asimmetrica e la funzione di Hash. In particolare, della crittografia asimmetrica, si sfrutta l algoritmo a chiave di decifratura pubblica secondo il quale un documento viene cifrato con la chiave privata del mittente consentendo sempre la sua piena identificazione. La funzione di Hash invece ci consente di rendere la cifratura più semplice e veloce, in quanto non viene cifrato il documento originale, ma bensì la sua impronta (digest) che sappiamo essere di lunghezza fissa. Vediamo ora come si realizza la firma digitale di un qualsiasi documento informatico: Mittente Text Hash Digest Cifratura Firma KprivM Text + Firma Figura 9. Processo di firma digitale di un documento informatico. Il processo prevede tre stadi principali: generazione del digest: il messaggio originale (Text) viene elaborato mediante la funzione di Hash ottendo così la sua impronta (Digest); generazione della firma: il digest viene cifrato con la chiave privata del mittente (K prim ); apposizione della firma: al messaggio in chiaro si allega la firma precedentemente ottenuta (ed eventualmente il certificato contenente la chiave pubblica di decifratura). 3542 Capitolo 2 Il documento firmato così ottenuto viene inviato al destinatario che, a sua volta, dovrà eseguire dei controlli per assicurarsi della validità della firma. Le operazioni che compie sono riportate nel seguente schema: Destinatario Text Hash Digest Text + Firma Confronto Firma Decifratura Digest presunto KpubM Figura 10. Processo di verifica della firma digitale. Il processo di verifica della firma digitale prevede i seguenti stadi: il documento firmato viene diviso nella parte di documento in chiaro ed in quella relativa alla firma e le due parti vengono elaborate separatamente; il documento in chiaro viene sottoposto alla funzione di Hash e se ne calcola il digest; la firma viene decifrata con la chiave pubblica del mittente (recuperata dal certificato relativo al mittente stesso) ottenendo così il digest presunto, ovvero l impronta del documento originale al momento della firma; i due digest vengono tra loro confrontati e a questo punto ci sono due possiblità: o i digest risultano uguali: allora la firma è valida ed il documento è integro; o i digest sono diversi: significa che il documento ha subito delle modifiche (dolose o accidentali) dal momento in cui è stato firmato dal mittente a quello in cui è stato ricevuto dal destinatario. La firma digitale così ottenuta lega l entità, che detiene l uso esclusivo della chiave privata, ai dati, tramite l impiego del digest. Infatti ogni firma, anche se apposta con la stesa chiave privata, è unica e diversa in relazione ad un diverso documento. 3643 Crittografia Questo tipo di firma offre tutte le garanzie di sicurezza di una normale firma autografa, portando in più due vantaggi fondamentali: è più difficile da falsificare: in quanto si dovrebbe entrare in possesso della chiave privata del mittente; garantisce l integrità del documento: la modifica anche di un solo bit del documento comporta la variazione dell intero digest. Prima di discutere gli aspetti legali vorrei puntualizzare un aspetto che è passato un po in secondo piano per dare maggiore risalto ai processi di firma e verifica. Da quanto detto il documento firmato, costituito dal testo in chiaro con allegata la firma, viene spedito al destinatario su un canale telematico. E opportuno precisare che in questa operazione vengono utilizzati canali di comunicazione sicuri (come ad esempio SSL) e quindi in rete viaggiano sempre messaggi cifrati. In questo modo rimane garantita la segretezza della trasmissione. Inoltre non è necessario che il documento e la sua firma si trovino sullo stesso supporto digitale, le due parti possono anche essere separate e spedite su canali diversi senza che per questo venga meno il legame esistente fra di esse Aspetti legali della firma digitale La sicurezza di una operazione giuridica, cioè la possibilità di dimostrarne efficacemente l esistenza e il contenuto, deriva dal poter disporre di una documentazione sicura, ossia non alterabile o che mantenga traccia delle eventuali alterazioni. Oggi la funzione di mezzo probatorio è assolta fondamentalmente dai documenti cartacei, tuttavia l impiego sempre più frequente delle nuove tecnologie ha fatto sorgere l esigenza di riconoscere uno status giuridico ai documenti su supporto informatico e la loro validità ai fini probatori. A questo 33 Con l accortezza che il destinatario disponga di un sistema in grado di riconoscere e recuperare le due parti. 3744 Capitolo 2 scopo devono essere garantiti i requisiti fondamentali di integrità, non modificabilità e autenticazione. Nel caso del tradizionale supporto cartaceo questo è possibile grazie all inscindibilità fisica tra contenuto (il testo del documento) e contenitore (il foglio di carta) e all apposizione della sottoscrizione autografa. Diversamente, nel caso dei documenti informatici, il medesimo contenuto è facilmente riproducibile su diversi contenitori, ed ogni copia risulta esattamente identica all originale. Grazie alle elaborazioni previste nel processo di firma digitale è possibile rendere il documento informatico altrettanto sicuro garantendo tutti i requisiti necessari. La legislazione italiana è stata tra le prime a livello mondiale a dettare una disciplina organica in materia di firma digitale e documento informatico. L introduzione nel nostro ordinamento dell istituto della firma digitale è avvenuto in modo progressivo. Il primo passo risale alle normativa del 15 marzo 1997 noto come Legge Bassanini in materia di riforma della Pubblica Amministrazione e di semplificazione amministrativa. Esso testualmente disponeva che gli atti, dati e documenti formati dalla pubblica amministrazione e dai privati con strumenti informatici o telematici, i contratti stipulati nelle medesime forme, nonché la loro archiviazione e trasmissione con strumenti informatici, sono validi e rilevanti a tutti gli effetti di legge. In attuazione da quanto previsto da tale norma il 10 novembre 1997 è stato emesso il decreto legge n.513 contenente i criteri e le modalità per la formazione, l archiviazione e la trasmissione di documenti con strumenti informatici e telematici. In seguito, l 8 febbraio 1999, fu emanato un successivo decreto recante le regole tecniche per la formazione, la trasmissione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici. Successivamente l Autorità per l Informatica nella Pubblica Amministrazione 34 ha elaborato uno schema di Testo Unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa, applicabile per la parte relativa ai documenti informatici e alla firma digitale 34 Oggi CNIPA: Centro Nazionale per l Informatica nella Pubblica Amministrazione. 3845 Crittografia anche nei rapporti tra privati. Tale testo è stato approvato definitivamente il 6 ottobre 200 ed è entrato in vigore il 28 dicembre dello stesso anno. Questa serie di normative ha sancito la totale equiparazione della firma digitale alla sottoscrizione autografa e del documento informatico firmato digitalmente alla scrittura privata, purché conforme alle disposizioni del Testo Unico. 3946 Capitolo 2 4047 Public Key Infrastructure Capitolo 3. PUBLIC KEY INFRASTRUCTURE 4148 Capitolo Introduzione Nel capitolo precedente si è discusso il funzionamento di alcune tecniche crittografiche e si sono fatte delle considerazioni sulla loro sicurezza. In particolare abbiamo visto che le applicazioni di firma digitale utilizzano algoritmi crittografici asimmetrici e che la sicurezza di questi algoritmi è legata esclusivamente alla segretezza della chiave privata. Di questo ovviamente si deve occupare l utente stesso cercando di divulgare il meno possibile le informazioni riguardanti la sua chiave privata e soprattutto evitando di delegarne l uso a terzi. Si consiglia l utente di dotarsi di apposite Smart Card che rendono il compito più semplice. Questo però non basta per garantire del tutto la sicurezza del sistema. La firma digitale lega infatti un documento non al suo autore, ma alla chiave privata impiegata nell operazione di cifratura. Si ha quindi bisogno di una entità che ci assicuri che quella chiave appartiene ad una certa persona. Inoltre un sistema informatico che faccia uso della firma digitale, per essere completamente funzionante, deve poter gestire in modo corretto lo scambio e la divulgazione delle chiavi pubbliche. Si introduce così il concetto di infrastruttura a chiave pubblica 35, in cui un autorità fidata si preoccupa di identificare e autenticare tutti gli utenti che vogliano usufruire dei suoi servizi e garantisce inoltre l appartenenza di una chiave pubblica ad uno specifico utente mediante l emanazione di un certificato. Si può definire una PKI come un insieme di hardware, software, risorse umane, protocolli, regole e procedure necessarie per fornire supporto all utilizzo su larga scala dei sistemi di crittografia asimmetrici. Prima di procedere alla descrizione di una PKI ritengo opportuno spiegare il meccanismo di gestione delle chiavi pubbliche. Il prossimo paragrafo, infatti, introdurrà il concetto di certificato a chiave pubblica, che verrà poi ripreso nella parte dedicata agli standard. 35 PKI: Public Key Infrastructure 4249 Public Key Infrastructure 3.2 Il certificato a chiave pubblica Un certificato a chiave pubblica è un documento informatico che associa una chiave pubblica ad un soggetto. In esso dovranno quindi essere scritti alcuni dati necessari all identificazione del soggetto stesso. Per risultare valido, un certificato deve essere firmato da una apposita entità (l Autorità di Certificazione) che garantisca l effettiva appartenenza della chiave pubblica al soggetto in questione. Un certificato a chiave pubblica deve quindi contenere: Informazioni varie sul formato del certificato; Subject: dati identificativi del soggetto; Chiave pubblica del soggetto e informazioni relative (algoritmo di cifratura utilizzato, impieghi previsti e altro); Periodo di validità del certificato; Issuer: dati identificativi dell emettitore del certificato; Signature: un digest delle informazioni precedenti cifrato con la chiave privata dell emettitore. In pratica un utente (soggetto) si rivolge ad una Autorità di Certificazione per farsi rilasciare il certificato a chiave pubblica. In una comunicazione tra due entità il mittente appone la firma sul documento originale ed invia il documento firmato ed il certificato. Il destinatario deve verificare l attendibilità del certificato prima ancora di verificare la firma. Deve quindi decifrare la signature con la chiave pubblica dell issuer ottenendo un digest presunto da confrontare con il digest ricavato da tutti gli altri campi del certificato elaborati con la funzione di Hash. Se il confronto ha esito positivo allora il certificato è valido e si procede alla verifica della firma. Le figure sottostanti mostrano i processi di firma e verifica di un certificato: 4350 Capitolo 3 Root certificate Data Root CA public key Signature Root CA private key hash digest enc Subject certificate enc Data Subject public key hash digest Signature Figura 11. Firma del certificato da parte di un soggetto e di una Autorità di Certificazione. Root CA certificate Data Root CA public key Signature Subject certificate dec Presumed digest Data Subject public key hash digest =? Ok Signature Figura 12. Verifica di un certificato a chiave pubblica. L impiego dei certificati a chiave pubblica non è comunque obbligatorio. Nel Testo Unico 36 si afferma che l attività di certificazione è necessaria solo ove si vogliano conseguire gli effetti di validità e rilevanza a tutti gli effetti di legge. E del tutto lecito infatti scambiarsi documenti con la tecnica delle chiavi asimmetriche senza ricorrere all uso dei certificati, ad esempio nel caso in cui si dispone di una rete di piccole dimensioni in cui ci si scambiano dati non troppo riservati e quindi si può tollerare un livello di sicurezza meno restrittivo. 36 Vedi paragrafo Aspetti legali della firma digitale. 4451 Public Key Infrastructure La certificazione diventa necessaria quando si desidera che il documento acquisti pieno valore probatorio. In ultimo si può fare un osservazione sul fatto che un certificato a chiave pubblica lega una chiave pubblica ad una certa persona (che abbiamo chiamato soggetto). In realtà eravamo partiti dall esigenza di legare la chiave privata al soggetto in questione. Una PKI in realtà non può gestire le chiavi private (per evidenti motivi di sicurezza), ma abbiamo visto il legame matematico forte che associa indissolubilmente le chiavi pubblica e privata. Un certificato quindi lega un soggetto ad una coppia di chiavi, fornendosi della sola informazione di cui può disporre, che è la chiave pubblica Ciclo di vita di un certificato L emissione effettiva di un certificato elettronico da parte di una Autorità di Certificazione a favore di un utente finale deve essere preceduta da una fase di registrazione dell utente stesso. Attraverso il processo di registrazione l utente richiedente il servizio di certificazione si identifica presso l autorità preposta al servizio di registrazione. Le credenziali che in questa fase l utente deve sottoporre all Autorità di Registrazione dipendono fortemente dalle modalità e procedure di registrazione definita nell ambito di una politica di sicurezza. Il processo di registrazione stabilisce una relazione iniziale tra utente finale e Autorità di Certificazione. L utente finale, una volta attestata l autenticità della sua identità, viene registrato nel dominio di fiducia gestito dalla CA. L obiettivo di primaria importanza del processo di registrazione è quindi quello di garantire che la chiave pubblica, di cui un certo utente finale richiede la certificazione, appartenga effettivamente al nome del richiedente. Terminata la fase di registrazione, l utente può richiedere l emissione di un certificato elettronico. La procedura di generazione di un certificato elettronico consiste dei seguenti passaggi: L utente finale sottopone all Autorità di Certificazione le informazioni da certificare. 4552 Capitolo 3 L Autorità di Certificazione può verificare l accuratezza delle informazioni presentate in accordo a politiche e standard applicabili. L Autorità di Certificazione firma le informazioni generando il certificato a chiave pubblica e lo inserisce in un database pubblico. Solitamente la CA archivia una copia del certificato anche sul suo database privato. Ogni operazione di generazione dei certificati elettronici viene registrata su un archivio di registrazione dati. Ogni certificato elettronico generato ha una validità temporale limitata, al termine della quale va sostituito. Il periodo di validità di un certificato, in assenza di compromissioni o di usi illeciti, garantisce l utente che deve utilizzare tale certificato che la chiave pubblica possa essere utilizzata per lo scopo per cui è stata generata e che l associazione tra la chiave pubblica e le altre informazioni contenute nel certificato sia ancora valida Revoca di un certificato L operazione di revoca di un certificato costituisce una fase molto critica della gestione del ciclo di vita dei certificati. Un certificato elettronico deve essere revocato in presenza di almeno una delle seguenti condizioni: Compromissione rilevata, o semplicemente sospettata, della chiave privata corrispondente alla chiave pubblica contenuta nel certificato. Cambiamento di una qualsiasi delle informazioni contenute nel certificato elettronico o delle condizioni iniziali di registrazione. La revoca del certificato elettronico è effettuata dalla Autorità di Certificazione e generalmente viene avviata su richiesta dello stesso utente finale. In questo caso, data la criticità e le implicazioni dell operazione di revoca, è indispensabile predisporre un sistema di autenticazione della richiesta di revoca. Ogniqualvolta un certificato viene revocato, tutti gli utenti appartenenti alla stessa infrastruttura devono essere informati dell avvenuta revoca. Il meccanismo più comunemente utilizzato per la notifica su larga scala di avvenute revoche fa uso della cosiddetta lista di revoca dei certificati (CRL: 4653 Public Key Infrastructure Certificate Revocation List). La gestione di tali liste è delegata alla Certification Authority. Nell ambito del dominio amministrato ogni CA pubblica periodicamente una struttura dati contenente l elenco dei certificati revocati, ossia una lista firmata digitalmente dalla CA che riporta i certificati revocati, la data temporale in cui è avvenuta la revoca ed eventualmente il motivo della revoca. Di seguito è schematizzato il formato di una lista di revoca dei certificato conforme allo standard X509. Figura 13. Formato di una CRL secondo lo standard X509. Le liste di revoca giocano un ruolo di fondamentale importanza in tutti i processi crittografici, in quanto devono essere consultate sia in fase di cifratura, sia in fase di verifica della firma. Infatti, prima di cifrare un messaggio, va verificato che la chiave pubblica che si deve usare per la cifratura appartenga ad un certificato valido. Analogo discorso vale per la verifica della firma, poiché una firma può essere ritenuta valida solo se il certificato del firmatario, oltre ad essere autentico ed integro, non è stato revocato. 4754 Capitolo Certification Authority e Registration Authority Le principali entità che costituiscono una PKI sono: Certification Authority (CA): o Autorità di Certificazione (già menzionata in precedenza) è l entità che rilascia i certificati. Una CA garantisce per un certo numero di utenti o per altre Autorità di Certificazione. E un punto molto critico della struttura in quanto la compromissione di una CA (ad esempio la venuta a conoscenza della sua chiave privata da parte di terzi) potrebbe compromettere la sicurezza dell intera PKI. E quindi opportuno che sia l hardware che il software che hanno accesso diretto alla chiave privata della CA si trovino su una macchina off-line. Registration Authority (RA): o Autorità di Registrazione, è l entità che si occupa della creazione delle chiavi, della distribuzione dei certificati, di assegnare gli identificativi (alias) ai client, di archiviare chiavi e certificati, di generare e gestire le richieste di certificato e altro ancora. In pratica svolge tutte quelle funzioni che servono per interfacciare l utente con l Autorità di Certificazione Modello di fiducia Abbiamo appena detto che una Autorità di Certificazione garantisce per un certo numero di utenti o, eventualmente, per altre Autorità di Certificazione. Questo significa che ogni utente che appartiene ad una certa AC è a conoscenza delle chiavi pubbliche di tutti gli utenti appartenenti alla stessa AC e può quindi verificare la firma di ognuno di essi. Nel caso fossero coinvolti gli utenti di diverse AC, è necessario che le AC in questione emettano degli appositi certificati (detti cross certificate) che consentano ad ogni utente di fidarsi della AC esterna. La modalità con cui l utente arriva a fidarsi di un certificato emesso da una AC a lui sconosciuta, partendo dalla fiducia che egli ripone in una singola 4855 Public Key Infrastructure AC a lui nota, viene indicata come modello di fiducia (Trust Model) dell infrastruttura. Più precisamente un modello di fiducia specifica in che modo si può porre fiducia nell asserzione che un utente remoto sia effettivamente chi dice di essere (autenticazione) e che abbia effettivamente i diritti di accesso al servizio o informazione che sta richiedendo (autorizzazione). Quindi il modello di fiducia si pone alla base dell infrastruttura a chiave pubblica, specificando quali procedure riescono a garantire il corretto funzionamento dei servizi di sicurezza offerti dall infrastruttura stessa. Un esempio di modello di fiducia è il cosiddetto web of trust (rete di fiducia) utilizzato dal programma di cifratura PGP. In questo particolare modello non si fa ricorso ad Autorità di Certificazione centralizzate, ma sono gli utenti stessi a certificarsi reciprocamente le chiavi di cui possono garantire la provenienza, firmandole. Tale meccanismo si basa sul presupposto che un utente firmi la chiave pubblica altrui solo quando ha la certezza sull identità del suo titolare. Nessuno però può assicurare che venga firmata una chiave pubblica sulla quale non sono stati esercitati accurati controlli. Questo modello, anche se del tutto funzionale, non ha validità giuridica in quanto ritenuto poco sicuro. Esistono comunque altri modelli, e li vedremo nel prossimo paragrafo, che prevedono strutture reticolari o strutture gerarchiche ad albero, e che hanno maggiore valenza legale Tipologie di collegamenti fra Autorità di Certificazione In genere una PKI è composta da diversi Certificatori 37 ognuno dei quali garantisce per un certo numero di utenti. Nasce però un problema quando un utente che si riferisce ad una CA riceve un messaggio da un altro utente che fa riferimento ad un altra CA. Non conoscendo quest ultima l utente non è in grado di identificare il mittente, quindi cade un fondamentale requisito di sicurezza. Da qui la necessità di far interagire tra loro le varie CA. 37 Nel Testo Unico dell AIPA il nome di Certification Authority è stato tradotto in Certificatore, anche se risulta di uso più comune la traduzione letterale Autorità di Certificazione. I due termini indicano comunque la stessa entità ed in questo testo sono utilizzati in modo del tutto equivalente. 4956 Capitolo 3 Esistono due modelli principali di collegamento fra Autorità di Certificazione: Modello reticolare: ogni CA nasce come autorità locale di cui si fidano tutti e solo gli utenti appartenenti ad essa. Modello ad albero: prevede una CA globale di cui tutti si fidano, che distribuisce opportunamente le sue mansioni ad altre CA locali, ognuna facente capo ad una comunità ristretta di utenti o ad altre CA ancora più localizzate. Modello reticolare La figura sottostante indica un esempio di PKI composta da quattro Autorità di Certificazione ognuna facente capo a tre utenti. Figura 14. PKI strutturata secondo il modello reticolare. L interoperabilità tra Autorità di Certificazione diverse è ottenuta mediante accordi fra le AC stesse. Si supponga che l utente U11 riceva un messaggio firmato dall utente U32 e ne voglia quindi verificare la firma. L Autorità cui U11 fa riferimento (AC1) non possiede la chiave di U32, quindi non è in grado di fornirla direttamente. E allora necessario che AC1 si metta in contatto con AC2 chiedendogli la chiave di U32. 5057 Public Key Infrastructure In particolare, nella comunicazione tra le due Autorità di Certificazione, AC1 verifica in primo luogo che AC2 adotti politiche di sicurezza uguali, o comunque che garantiscano un livello di sicurezza almeno pari a quello garantito dalle proprie politiche, in seguito AC1 rilascia un certificato, detto cross certificate, che: garantisce che una chiave certificata da AC2 è valida; contiene la chiave di verifica dei certificati di AC2. Tale certificato, una volta reso noto a tutti gli utenti appartenenti ad AC1, permette loro di fidarsi di una chiave certificata da AC2. E proprio grazie a questi cross certificate che un Autorità di Certificazione ripone la sua fiducia su un altra AC. Di fatto un utente può verificare la firma di un qualsiasi altro utente la cui AC abbia instaurato un cross certificate con la propria. Bisogna notare che questo modello prevede che, agli occhi di un utente, sia sempre la propria Autorità di Certificazione a garantire l autenticità delle firma delle altre AC, in linea con un modello di distribuzione della fiducia che prevede che ogni entità si fidi soltanto della AC di appartenenza. Il rilascio dei cross certificate però presenta aspetti problematici. Prima di rilasciare un cross certificate una Autorità di Certificazione deve assicurarsi che l altra AC garantisca un livello di sicurezza almeno pari a quello da lei offerto. Questo in realtà non capita mai, perché le AC fanno riferimento a realtà ambientali diverse fra loro e probabilmente anche di diversi paesi, quindi soggette a specifiche politiche di sicurezza. Quello che in effetti è il vantaggio di una struttura reticolare, cioè collegare diverse AC indipendenti fra loro, senza creare un sistema centralizzato, si rivela un arma a doppio taglio, in quanto proprio questa indipendenza può manifestarsi come un limite alle possibilità di comunicazione tra gli utenti. In generale il livello di sicurezza di una Autorità di Certificazione, di conseguenza l affidabilità dei certificati da essa rilasciati, risulta determinato dai seguenti fattori: gli algoritmi crittografici impiegati nei processi di firma digitale; le politiche di accesso agli elaboratori adottate; il software utilizzato; 5158 Capitolo 3 le procedure per l identificazione e l autenticazione preliminare degli utenti. Modello ad albero Facendo uso delle stesse convenzioni del caso precedente, riportiamo l esempio di una PKI composta da quattro Autorità di Certificazione strutturata secondo il modello ad albero. Figura 15. PKI strutturata secondo il modello ad albero. Nel modello ad albero esiste un unica Autorità di Certificazione globale della quale tutti gli utenti dell infrastruttura di fidano. Ogni utente però non interagisce direttamente con essa, ma con altre AC, ciascuna locale ad una comunità ristretta di utenti. Questo modello prevede che le AC siano distribuite gerarchicamente, secondo una struttura ad albero, in cui ogni livello corrisponde ad una Autorità di Certificazione con un ruolo diverso all interno dell infrastruttura. Ogni AC garantisce per tutti i livelli ad essa sottostanti firmando i certificati a chiave pubblica con la propria chiave privata. La AC globale, che è all apice della gerarchia, garantisce per se stessa con un certificato autofirmato. 5259 Public Key Infrastructure Si può definire il modello ad albero come un caso particolare del modello reticolare, considerando i certificati che legano le AC padre con le AC figlie dei veri e propri cross certificate. Ciò che distingue i due modelli è il fatto che normalmente una AC padre rilascia un cross certificate per ogni AC figlia, mentre non è necessario il procedimento inverso, cioè che le AC figlie rilascino un cross certificate per la AC padre. Questo perché la struttura ad albero è accentrata ed il possesso della chiave pubblica della AC radice permette la verifica di qualsiasi certificato rilasciato da qualsiasi altra AC dell albero. Un utente infatti, per verificare il certificato emesso da un altra AC, deve risalire la gerarchia dell albero verificando tutti i cross certificate che portano alla radice. Questo tipo di collegamento tende a minimizzare il problema delle diverse politiche di sicurezza adottate da ogni AC. La AC globale infatti ha anche il compito di dettare delle linee di sicurezza alle quali tutte le AC facenti parte dell albero devono attenersi. Nelle applicazioni pratiche, le PKI con effetti legali impiegano un modello ad albero che si sviluppa su due livelli, con il livello superiore di emanazione Statale o pubblica che certifica le autorità inferiori, normalmente private. Modelli a struttura ibrida In questo caso si hanno più infrastrutture ad albero che, per necessità di cooperazione, si riuniscono in un unica rete di AC secondo le modalità del modello infrastrutturale a rete. Soltanto le AC radice devono rilasciarsi mutuamente dei cross certificate, e questo garantisce l interoperabilità fra tutte le AC appartenenti agli alberi le cui radici si sono mutuamente certificate. La situazione finale è simile a quella di una rete di AC, ma con una differenza sostanziale: ogni utente continua a fidarsi soltanto della AC radice dell albero contenente la sua AC locale di appartenenza. Una struttura ibrida di questo tipo è quella destinata a formarsi in una realtà di ampiezza continentale o mondiale, in cui ogni stato sviluppa una infrastruttura nazionale gerarchica indipendentemente dagli altri, poi, se le varie infrastrutture sono compatibili tra loro, una serie di certificazioni mutue riesce a garantire l interoperabilità fra di esse. 5360 Capitolo Catene di certificazione In uno scenario costituito da una molteplicità di Autorità di Certificazione su larga scala, strutturate secondo un certo modello organizzativo, non è pensabile che ogni utente abbia diretta conoscenza della chiavi pubbliche di ogni potenziale interlocutore, sottoforma di certificato elettronico, o delle chiavi pubbliche delle corrispondenti Autorità di Certificazione competenti. Occorre quindi disporre di un meccanismo corretto di ritrovamento dei certificati elettronici degli interlocutori appartenenti a domini di sicurezza esterni. Il modello generale su cui si basano tutti i sistemi di distribuzione su larga scala della chiavi pubbliche sottoforma di certificati elettronici, utilizza le cosiddette catene di certificazione, anche note come cammini di certificazione. Il problema del ritrovamento di un cammino di certificazione consiste sostanzialmente nel trovare, se esiste, un cammino di certificazione che permetta di verificare l autenticità di un certificato elettronico di uno specifico utente remoto, a partire da un insieme di chiavi pubbliche, assunte come radici del cammino, delle quali si ha la diretta e sicura conoscenza. La risoluzione del problema quindi assume per date certe condizioni iniziali: tali condizioni iniziali si identificano nella conoscenza di chiavi di specifiche autorità di certificazione già note, e che quindi già dispongono della nostra fiducia. La figura sottostante mostra un esempio di catena di certificazione, costituita da tre certificati, in una ipotetica comunicazione tra Alice e Bob appartenenti a due CA diverse. 5461 Public Key Infrastructure Figura 16. Esempio di catena di certificazione. La presenza del certificato 1 garantisce Alice sull autenticità della chiave pubblica dell autorità di certificazione B; Alice può quindi utilizzare la chiave pubblica di B per verificare l autenticità del certificato 2. La presenza del certificato 2 garantisce ora Alice sull autenticità della chiave pubblica dell autorità di certificazione C; ora Alice può utilizzare la chiave pubblica dell autorità di certificazione C per verificare l autenticità del certificato 3 e quindi della chiave pubblica di Bob. Se fosse venuto a mancare il certificato 2 Alice non avrebbe potuto verificare l autenticità del certificato elettronico di Bob e conseguentemente avviare con Bob una comunicazione sicura. Il cammino che si percorre all interno di una catena di certificazione riflette il modello strutturale che costituisce la PKI. L esempio precedente è riconducibile ad un modello reticolare in cui il certificato 1 ed il certificato 2 costituiscono due cross certificate che legano rispettivamente l autorità di certificazione A con B, e l autorità di certificazione B con C. In un modello ad albero si avrebbe uno schema molto simile, nel quale i cross certificate legano le autorità di certificazione padre con le figlie. La differenza risiede nel certificato all apice della catena, che rappresenta l autorità di certificazione radice. Tale certificato infatti è autofirmato, in quanto la CA 5562 Capitolo 3 radice garantisce per se stessa, quindi i campi subject e issuer del certificato rappresentano la stessa entità. Riportiamo di seguito l esempio di un cammino di certificazione che si potrebbe trovare in una infrastruttura che utilizza un modello ad albero. L autorità di certificazione A è la CA radice. Figura 17. Esempio di catena di certificazione in una struttura ad albero. 5663 Public Key Infrastructure 3.4 Standard Questo paragrafo descrive brevemente gli standard in vigore che disciplinano i certificati a chiave pubblica e le PKI. Questi standard riguardano molti campi tra cui il formato con cui i dati devono essere contenuti in un certificato, le regole di implementazione degli algoritmi crittografici, le regole di utilizzo di hardware crittografici e altro ancora Standard X.509 per i certificati a chiave pubblica Lo standard ormai diffusamente riconosciuto di definizione del formato dei certificati è quello descritto nelle specifiche ITU X , corrispondenti alle specifiche ISO/IEC Tale standard è giunto alla terza versione (X.509v3), dopo che le due precedenti versioni si erano dimostrate insufficienti a risolvere certe problematiche. Vediamo da quali campi è composto un certificato: Version: indica la versione del formato del certificato. Serial Number: è un codice numerico che identifica univocamente il certificato. Signature Algorithm: specifica l algoritmo utilizzato dalla CA per firmare il certificato. Issuer X.500 Name: indica il nome della CA (secondo lo standard di naming X.500). Validity Period: specifica la data e l ora di inizio validità e fine validità del certificato. Subject X.500 Name: nome del possessore del certificato. Subject Public Key Information: contiene il valore della chiave pubblica del possessore del certificato e l algoritmo con cui tale chiave viene usata. 38 International Telecommunication Unit. 39 International Standard Organization / International Electrotechnical Commission. 5764 Capitolo 3 Issuer Unique Identifier: è una stringa di bit aggiuntivi, opzionale, usata nel caso in cui nella struttura ad albero ci siano due CA. Subject Unique Identifier: stringa opzionale di bit usata nel caso di omonimia tra due membri di una stessa CA. CA Signature: è la firma digitale della CA sul certificato. Nella terza versione dello standard è stato aggiunto un ulteriore campo: Standard Extention. Questo campo è suddiviso in tre sottoinsiemi: l identificatore del tipo di estensione, un indicatore di criticità e il valore effettivo dell estensione. L indicatore di criticità facilita l interoperabilità tra sistemi che non utilizzano certificati con determinate estensioni e sistemi che, invece, interpretano tutte le estensioni definite a livello di standard. Tale indicatore è semplicemente un flag che indica se l estensione è critica o non critica; nell ultimo caso il sistema che deve elaborare il certificato può eventualmente ignorare l estensione in questione se non è in grado di interpretarla. Le estensioni standard definite nei certificati X.509v3 si dividono in quattro gruppi: Estensioni contenenti informazioni sulla chiave pubblica che specificano il tipo di utilizzo per cui è stata emessa una certa chiave. Estensioni contenenti informazioni aggiuntive relative alla CA e all utente possessore del certificato. Estensioni contenenti informazioni sulle politiche di emissione e sulle finalità di utilizzo dei certificati. Estensioni contenenti informazioni sui vincoli di spazio di nomi o di politica da imporre durante il ritrovamento o la verifica di un certificato appartenente ad un dominio di fiducia esterno. Vediamo di seguito un esempio di certificato X.509 v3. 5865 Public Key Infrastructure Figura 18. Esempio di certificato X.509v3. Per avere un idea di come si presenta nella pratica un certificato a chiave pubblica conforme allo standard X.509 riportiamo di seguito l esempio di un certificato (autofirmato) rilasciato dall Autorità di Certificazione della BNL (BNL Multiservizi) 40. Version: V3 Subject: CN=Proxy Locale Multiservizi, OU=Certification Service Provider, O=Multiservizi S.p.A., L=Roma, ST=rm, C=IT Signature Algorithm: SHA1withRSA, OID = Key: SunJSSE RSA public key: public exponent: modulus: d5d b80aca4 1fb8228b cc319e8f 4dd956f3 a010e5f2 d42bbe13 2ad8ce46 a53c044c eb8e4073 ebe42ff dde 44ade1c9 5a4d19ac 31da9390 c2f50ccd Validity: [From: Fri Feb 18 11:46:14 CET 2000, To: Mon Feb 15 11:46:14 CET 2010] Issuer: CN=Proxy Locale Multiservizi, OU=Certification Service Provider, O=Multiservizi S.p.A., L=Roma, ST=rm, C=IT SerialNumber: [ 01] Certificate Extensions: 1 [1]: ObjectId: Criticality=false Extension unknown: DER encoded OCTET string = 0000: D F 6E %.#Emissione ce 0010: D 4C rtificati per ML 40 Questo certificato è in dotazione con il software di installazione del lettore di Smart Card GemPC410 della Gemplus utilizzato nello sviluppo di questo lavoro. 5966 Capitolo : F S Proxy Algorithm: [SHA1withRSA] Signature: 0000: DE 7D 2B 55 5B C E C4 95 D5 c...+u[.wb : 2C CB 29 0F 71 EE C A0 10 7A E7 4A,.4.).q...z.J 0020: 28 0A C3 97 AB BF DC B3 1E 12 1B 47 (.(q...2g...g 0030: B3 F C5 06 E7 03 DB 7F 25 4E 0C B2 16 E9..fB...%N Standard PKCS PKCS è l acronimo di Public Key Cryptography Standard e rappresenta una famiglia di standard rilasciati dalla RSA Laboratories 41, con lo scopo di accelerare lo sviluppo e l impiego delle tecniche di crittografia asimmetrica. Pubblicati per la prima volta nel 1991, queste specifiche sono presto diventate un punto di riferimento per il settore. Ogni specifica riguarda uno o più aspetti legati al mondo della crittografia e della sicurezza. Questo standard si articola in quindici normative che definiscono gli algoritmi di crittografia, la sintassi e le interfacce per l utilizzo di vari strumenti crittografici. Di seguito ne riportiamo una breve descrizione 42 : PKCS#1: RSA Cryptography Standard. Definisce le linee guida per l implementazione dell algoritmo RSA sui calcolatori digitali. PKCS#3: Diffie-Hellman Key Agreement Standard. Standard per l implementazione dell algoritmo di key agreement Diffie-Hellman. PKCS#5: Password-Based Criptography Standard. Raccomandazioni per l implementazione della cifratura basata su password. PKCS#6: Extended-Certificate Sysntax Standard. Propone una sintassi ASN.1 che estende quella dei certificati X.509. PKCS#7: Cryptographic Message Syntax Standard. Sintassi generale per i dati crittografati. Su questo formato si basa ad esempio il protocollo di posta elettronica S/MIME e molti altri formati di interscambio per le informazioni di identificazione personale Le specifiche PKCS#2 e PKCS#4 sono state incorporate nel PKCS#1. 6067 Public Key Infrastructure PKCS#8: Private-Key Information Syntax Standard. Sintassi ASN.1 per le informazioni relative ad una chiave privata, e descrizione della sintassi per la chiavi private cifrate. PKCS#9: Selected Attribute Types. Definisce i tipi ASN.1 degli attributi usati in PKCS#6, PKCS#7, PKCS#8 e PKCS#10. PKCS#10: Certification Request Syntax Standard. Descrive una sintassi per la richiesta di firma di un certificato. PKCS#11: Cryptographic Token Interface Standard. Specifica una API (Cryptoki) per i dispositivi in grado di eseguire operazioni crittografiche e trattare le informazioni relative (chiavi e certificati). È lo standard de facto per l interoperabilità tra i diversi modelli e tipi di HSM (Hardware Security Module). Definisce un modello ad oggetti del token indipendente dall hardware sottostante e dalla piattaforma operativa. PKCS#12: Personal Information Excange Syntax Standard. Specifica un formato portabile per la memorizzazione o il trasporto di informazioni personali, come chiavi private, certificati e altro. È il formato utilizzato nei browser più comuni per l importazione e l esportazione di chiavi e certificati (Netscape/Mozilla, Internet Explorer, Opera, Konqueror). PKCS#13: Elliptic Curve Cryptografy Standard. Standard ancora in fase di sviluppo, che specifica molti aspetti della crittografia basata sulla teoria delle curve ellittiche. PKCS#15: Cryptographic Token Information Format Standard. Propone un modello generalizzato per l accesso alle smart card e ai token crittografici, al fine di favorire maggiormente l interoperabilità tra l hardware dei diversi vendor. 6168 Capitolo 3 6269 Smart Card Capitolo 4. SMART CARD 6370 Capitolo Aspetto di una Smart Card Le Smart Card sono schede del tutto simili, nella forma, a quelle che si utilizzano per telefonare o per le operazioni bancarie (carte di credito). Sono infatti delle tessere di plastica capaci di contenere dati al loro interno. La caratteristica che distingue le Smart Card dalle altre schede però, sta nel fatto che esse contengono un processore in grado di dotarle di una certa intelligenza (da cui appunto il nome di scheda intelligente ), che consente non solo la semplice memorizzazione dei dati, ma anche la loro elaborazione. Secondo lo standard ISO vengono definite Integrated Circuit Card (ICC, ovvero schede a circuito integrato ). La figura sottostante da un idea di come viene inserito il microchip all interno della tessera. Figura 19. Applicazione del chip sulla scheda. In pratica questo processore consente di eseguire operazioni sui dati direttamente all interno della card. E questa una proprietà da non sottovalutare in quanto fornisce un enorme contributo alla sicurezza. Infatti le operazioni che si svolgono sulla scheda riguardano soprattutto dati sensibili (dati personali del possessore della carta, certificati a chiave pubblica, chiavi private ) e più questi rimangono legati alla scheda, maggiore è il livello di sicurezza. Ma vediamo ora più in dettaglio come è fatta una Smart Card. 6471 Smart Card 4.2 Architettura interna Abbiamo già detto che una Smart Card possiede al suo interno un processore, ma questo da solo non basta per eseguire le operazioni menzionate. Ecco come è composta schematicamente una Smart Card: Figura 20. Architettura interna di una Smart Card. CPU: è il processore centrale, di tipo CISC a 8, 16 o 32 bit e con un clock di 3,5 o 5 MHz; ROM: è una memoria di sola lettura le cui dimensioni variano da 2 a 64 KByte e contiene il sistema operativo della scheda; PROM: è una memoria molto piccola (32 o 64 Byte) che contiene il numero seriale della scheda; EEPROM: ha una capacità di circa 128 KByte e contiene informazioni relative a dati e applicazioni (è la memoria di massa); RAM: memoria di lavoro volatile, varia tra 128 e 1024 Byte; Sottosistema I/O: è l interfaccia per lo scambio dati con l esterno. 6572 Capitolo 4 Come si può vedere la struttura di una Smart Card è molto simile a quella di un normale computer. Alcune schede possono presentare delle variazioni allo schema descritto (che è da ritenersi una struttura base di riferimento) a seconda delle funzioni cui sono destinate. Un esempio che ci riguarda molto da vicino è dato proprio dalle schede crittografiche. Gli algoritmi che queste devono eseguire sono molto complessi quindi necessitano di un ulteriore processore chiamato appunto coprocessore crittografico. Altri esempi si possono avere nel campo della biometria in cui i dati relativi al riconoscimento dell impronta digitale, o della retina, o di qualunque altra caratteristica biometrica, sono molto ingombranti quindi necessitano di una espansione di memoria realizzata ad esempio con una banda ottica (che può arrivare a contenere diversi MByte). 4.3 Tipi di Smart Card E opportuno a questo punto spendere qualche parola in più sui diversi tipi di Smart Card. La prima distinzione che si può fare riguarda la presenza o meno del microchip, abbiamo allora: Schede di memorizzazione (memory card): non hanno al loro interno un processore, ma solo un dispositivo di memorizzazione (ad es. banda magnetica). Consentono la memorizzazione e il recupero dati. Potrebbero contenere anche una logica di sicurezza per l accesso ai dati (autenticazione); Schede con processore (ICC): contengono un microchip che consente di memorizzare, recuperare e manipolare i dati. Alcune di esse presentano anche un coprocessore di supporto per le operazioni più complesse (schede crittografiche). Un altra classificazione delle Smart Card può essere fatta in base al loro modo di comunicare con il mondo esterno, si hanno quindi: Smart Card con contatti: si accede alla scheda per mezzo di contatti posti sulla superficie della tessera; 6673 Smart Card Smart Card senza contatti: presentano un dispositivo capace di trasmettere e ricevere onde elettromagnetiche utilizzate per scambiare i dati. 4.4 Standard Le Smart Card, anche se diverse nell architettura, devono rispettare alcuni standard riguardanti le loro caratteristiche fisiche, i protocolli di comunicazione, i comandi etc. Due enti in particolare (International Standard Organization 43 e International Electrotechnical Commission 44 ) si sono proposti di sviluppare una serie di requisiti di riferimento per i produttori di Smart Card. I produttori, dal lato loro, hanno tutto l interesse a rispettare tali requisiti, in quanto questo garantisce l interoperabilità, cioè la possibilità di utilizzare schede diverse su di uno stesso hardware (o software), e quindi facilita la diffusione delle schede. In questo paragrafo verranno illustrati alcuni standard, con particolare attenzione allo standard ISO/IEC Standard ISO/IEC 7816 Tutte le caratteristiche fondamentali di una Smart Card sono esposte nella normativa ISO/IEC 7816 che comprende le seguenti sezioni: ISO/IEC : Physical characteristics; ISO/IEC : Dimensions and location of the contacts; ISO/IEC : Electronic signals and transmission protocols; ISO/IEC : Inter-industry commands for interchange; ISO/IEC : Numbering system and registration procedure for application identifiers; ISO/IEC : Inter-industry data elements;74 Capitolo 4 ISO/IEC : ISO/IEC : ISO/IEC : ISO/IEC : ISO/IEC : ISO/IEC : Inter-industry commands for Structured Card Query Language; Security related inter-industry commands; Enhanced inter-industry commands; Electronic signals answer to reset for synchronous card; Card structure and enhanced functions for multi-application use; Cryptographic information application. Questi standard sono in continua evoluzione a seguito dell uscita di nuove tecnologie o dell impiego di particolari soluzioni nate come proprietarie (dall iniziativa di un produttore) e poi sviluppatesi fino a diventare di uso comune. Gli standard forniscono delle linee guida da seguire quando si ha a che fare con le Smart Card. Tuttavia ogni produttore è consigliato a seguire tali requisiti, ma non obbligato, per questo non è raro imbattersi in particolari schede che implementano funzioni non inerenti agli standard descritti (soprattutto nel campo della crittografia), ma che un produttore ha ritenuto opportuno implementare come migliore soluzione per un determinato impiego. E comunque il buon senso a suggerirci di trovare un compromesso tra rispetto degli standard e libera iniziativa a soluzioni proprietarie. Si pensi a cosa succederebbe se, ad esempio, ognuno producesse schede di differente forma e con diversi protocolli di comunicazione! Si verrebbe a creare il caos più assoluto! Senza dimenticarci di una proprietà fondamentale come l interoperabilità che sarebbe completamente persa. Per questo è necessario attenersi ad alcuni riferimenti comuni a tutti, e sono proprio quelli che troviamo nelle prime tre sezioni dello standard ISO/IEC Di fatto, una scheda dichiarata conforme al suddetto standard risulta conforme almeno alle prime tre sezioni. 6875 Smart Card ISO/IEC : Caratteristiche fisiche Questo standard definisce le caratteristiche fisiche di una Smart Card, in particolare: le sue dimensioni: Figura 21. Dimensioni di una Smart Card secondo lo standard ISO/IEC il valore minimo di radiazione ultravioletta che la scheda deve sopportare, stimato al livello medio di radiazione ambientale; il valore minimo di esposizione ai raggi X che non provochi danni alla scheda, stimato ad una energia media corrispondente alla quantità cumulativa annuale; il profilo della superficie dei contatti: la differenza tra il livello dei contatti e quello della superficie della scheda deve essere minore di 0,1 mm; la resistenza alle sollecitazioni meccaniche sia della scheda che dei contatti: questi non devono essere danneggiati dalla pressione provocata da una sfera di acciaio del diametro di 1,5 mm alla quale è applicata una forza di 1,5 N; la resistenza elettrica tra i contatti: non deve essere superiore a 0,5 Ω per valori di corrente compresi tra 50 µa e 300 ma; il valore minimo di campo magnetico statico che la scheda deve sopportare; 6976 Capitolo 4 la resistenza a scariche elettrostatiche: il chip non deve subire danni se sottoposto ad una scarica elettrica di 1500 V provenienti da una capacità di 100 pf attraverso una resistenza di 1500 Ω; i limiti massimi di flessione della scheda: deve resistere ad una deformazione di 2 cm dal lato lungo, o di 1 cm dal lato corto, con una periodicità di 30 flessioni al minuto. ISO/IEC : Dimensione e locazione dei contatti Questa sezione si occupa di definire le dimensioni fisiche, la locazione e l assegnamento dei contatti del chip sulla carta. In figura è riportato lo schema dei contatti esterni del microcontroller previsti dallo standard, la loro disposizione sulla tessera plastificata e la dimensione dei contatti stessi. Figura 22. Posizione e dimensione dei contatti sulla Smart Card. 7077 Smart Card Figura 23. Assegnazione dei contatti. V CC. Tensione continua di alimentazione, 3 o 5V; RST. Linea di reset; CLK. Segnale di clock del microcontroller. Lo spazio esiguo non permette alle smart card di disporre di un alimentazione interna, e il segnale di clock deve essere fornito dall interfaccia esterna (IFD: Interface Device o CAD: Card Acceptance Device); GND. Riferimento di massa per le tensioni applicate; V PP. Alcune smart card hanno bisogno, in fase di programmazione, di una tensione continua supplementare, fornita su questa linea. I/O. Linea per l input/output seriale. I contatti C4 e C8 non sono collegati, e sono riservati ad usi futuri (Reserved for Future Use). ISO/IEC : Segnali elettrici e protocolli di trasmissione Questo standard descrive i segnali elettrici e i protocolli di trasmissione utilizzati nelle Smart Card. In particolare vengono date indicazioni sui livelli delle tensioni e correnti riguardanti tutti i segnali introdotti precedentemente, nonché sui tempi di salita e discesa e sulle capacità parassite. Di seguito sono riportate solo le specifiche su alcuni segnali, tra i quali quelli fondamentali di alimentazione e clock, il reset che verrà discusso ulteriormente 7178 Capitolo 4 più avanti, e l'i/o. Viene tralasciato Vpp il cui utilizzo è opzionale e interessa più il programmatore della scheda che non l'utente finale. Symbol Conditions Minimum Maximum Unit Vih Either (1) Iih max = +/- 500uA 2 VCC V Iih max = +/- 50uA 0.7 VCC VCC (3) V Vil Iil max = 1mA V Voh Either (2) Iol max = +/- 100uA 2.4 VCC V Iol max = +/- 20uA 3.8 VCC V Vol Iol max = 1mA V tr, tf Cin = 30pF; Cout = 30pF 1 us (1) For the interface device, take into account both conditions. (2) It is assumed that a pull up resistor is used in the interface device (recommended value 20k Ohm. (3) The voltage on I/O shall remain between 0.3V and VCC+0.3V. Figura 24. Caratteristiche elettriche di I/O sotto normali condizioni operative. Symbol Conditions Minimum Maximum Unit Vih Either (1) IIih max = +/- 200uA 2.4 VCC (2) V Iih max = +/- 20uA 0.7*VCC VCC (2) V Iih max = +/- 10uA VCC-0.7 VCC (2) V Vil Iil max = +/-200 ua 0 (2) 0.5 V Voh Either (2) tr, tf Cin = 30pF Iol max = +/- 100uA 2.4 VCC V Iol max = +/- 20uA 3.8 VCC V 9% of the period with a max:0.5us (1) For the interface device, take into account three conditions. (2) The voltage on CLK shall remain between 0.3V and Vcc+0.3V. Figura 25. Caratteristiche elettriche di CLK sotto normali condizioni operative. Symbol Conditions Minimum Maximum Unit Vih Either (1) IIih max = +/- 200uA 4 VCC (2) V Iih max = +/- 20uA VCC-0.7 VCC (2) V Vil Iil max = +/-200 ua 0 (2) 0.6 V (1) For the interface device, take into account both conditions. (2) The voltage on RST shall remain between 0.3V and VCC+0.3V. Figura 26. Caratteristiche elettriche di RST sotto normali condizioni operative. 7279 Smart Card Symbol Minimum Maximum Unit Vcc V Icc 200 ma Figura 27. Caratteristiche elettriche di V cc sotto normali condizioni operative. Inoltre in questo standard sono definite anche le sequenze di attivazione e il comportamento del microcontroller al segnale di reset. Sono infine definiti due protocolli half-dupex asincroni di trasferimento dei dati chiamati T=0 e T=1. Questi ultimi concetti saranno ripresi ed analizzati più in dettaglio nel paragrafo riguardante il funzionamento di una Smart Card Altri standard Abbiamo visto come le prime tre sezioni dello standard ISO/IEC 7816 definiscano i requisiti che regolamentano le caratteristiche fisiche, i protocolli di comunicazione e il funzionamento di basso livello della Smart Card. Salendo di un livello troviamo il set di comandi di cui dispone la scheda. Una sua definizione viene data nella parte quarta dello standard precedente, tuttavia i comandi disponibili sono legati alle operazioni che la scheda è destinata a compiere, quindi è possibile trovare diversi set di comandi per diversi campi applicativi, ognuno comunque regolato da un opportuno standard. Di seguito sono riportati gli standard principali relativi ai set di comandi: ISO/IEC Fornisce indicazioni riguardanti: o il contenuto dei messaggi (sia di comando che di risposta) inviati dal lettore alla scheda e viceversa; o la struttura dei file e dei dati interni alla scheda; o i metodi di accesso a file e dati nella scheda; o i metodi di secure messaging; o i metodi di accesso agli algoritmi presenti nella scheda (senza occuparsi di descrivere tali algoritmi). 7380 Capitolo 4 EMV (Europay, Mastercard, Visa). È uno standard industriale che definisce comandi specifici per le transazioni finanziarie. Non è uno standard internazionale, ma costituisce comunque un riferimento per il settore. GSM Costituisce lo standard per le applicazioni legate alla telefonia mobile. CEN EN Standard che definisce comandi specifici per applicazioni di moneta elettronica (electronic purse) Abstract Syntax Notation L Abstract Syntax Notation (ASN) è il metodo più usato per strutturare i dati nelle smart card e trova particolare applicazione nelle schede crittografiche. Rispetta gli standard internazionali ISO/IEC 8824 relativi alla sintassi e ISO/IEC 8825 per quanto riguarda le regole di codifica. Ambedue sono inerenti alle raccomandazioni X.409 del CCITT. La struttura dati ASN.1 è una struttura flessibile, cioè vengono specificati di volta in volta il tipo di dato che si sta trasmettendo e la sua lunghezza. Gli sviluppatori di questo standard hanno preferito evitare strutture fisse in quanto potrebbero risultare incompatibili con eventuali sviluppi futuri comportando così costi aggiuntivi di adattamento. Di seguito è riportato un esempio di struttura dati che rispetta le Basic Encoding Rules (BER) dello standard ASN.1 e nota con il nome di struttura TLV. TAG 1 o 2 byte LENGTH da 1 a 3 byte VALUE n byte Figura 28. Struttura dati TLV dello standard ASN.1. 7481 Smart Card E composta da tre campi: Tag: è un etichetta che identifica il dato e ne specifica il tipo; Length: specifica la lunghezza del dato. La codifica di questo campo è definita nelle Distinguished Encoding Rules (DER) che sono un sottoinsieme delle BER. Value: rappresenta il dato vero e proprio. Vediamo ora più in dettaglio il campo Tag. I due bit più significativi selezionano un tipo (o classe) di dato presente nel campo Value tra i quattro disponibili: universal (00): rappresenta un dato generico; application (01): specifica un dato che appartiene ad una applicazione o ad uno standard; context-specific (10); private (11). Le ultime due classi si riferiscono a dati di applicazioni non standardizzate. Il bit successivo specifica se l oggetto in questione è una primitiva o un constructed (se è stato creato da altri oggetti). I rimanenti bit (cinque se il campo tag fosse di un solo byte, più altri otto se il campo fosse lungo due byte) codificano l effettiva etichetta scelta dall utente per identificare il dato. MSB LSB classe constr. etichetta Figura 29. Significato dei bit costituenti il campo TAG. Questo tipo di struttura ha il vantaggio di essere semplice, flessibile e permette di scambiare qualsiasi tipo di dato. Per contro potrebbe comportare un elevato costo di gestione nel caso in cui il campo Value fosse di pochi byte, in quanto si avrebbero più byte impiegati per descrivere il dato (nei campi T e L) rispetto a quelli costituenti il dato vero e proprio (campo V). 7582 Capitolo Funzionamento di una Smart Card In questo paragrafo verranno ripresi i concetti, già citati nella descrizione dello standard ISO/IEC , relativi alle sequenze di attivazione e disattivazione della scheda e ai protocolli di trasmissione che essa utilizza. Inoltre verranno brevemente descritti anche il sistema operativo impiegato dalla scheda e la struttura del file system per la gestione dei dati. Infine si illustreranno anche i concetti base del protocollo APDU Sequenze di attivazione e disattivazione Lo scambio dei dati tra smart card e interfacce esterne è regolato da una procedura descritta dettagliatamente nella terza sezione della normativa ISO/IEC 7816, nella quale il segnale applicato alla linea di reset (RST) gioca un ruolo fondamentale. La sequenza di attivazione è la seguente: mantenere RST basso; applicare V cc ; mettere il contatto I/O in modalità ricezione; applicare, se previsto, la tensione V pp ; applicare un segnale di clock stabile (CLK). descritti. La figura seguente mostra l andamento temporale dei segnali appena 7683 Smart Card GND VCC CLK RST I/O Inserimento smart card Stabilizzazione contatti ATR t Figura 30. Sequenza di attivazione. Con RST a livello basso, il microcontroller è nello stato di reset. Dopo un certo numero di cicli di clock, RST viene portato a livello alto. La smart card inizia la comunicazione in un intervallo di tempo compreso tra 400 e cicli di clock, inviando sulla linea seriale una trama chiamata ATR (Answer To Reset), che include informazioni relative ai protocolli di trasmissione supportatati, all identificazione del tipo di smart card, dell hardware on-board e del sistema operativo, varie informazioni aggiuntive (historical characters) che possono anche essere inserite dal produttore della carta e infine da un checksum di controllo. Con l ATR è possibile identificare univocamente il modello di smart card con il quale l IFD sta comunicando. Se nell ATR la card dichiara di supportare più di un protocollo di comunicazione (ad esempio sia T=0 che T=1), l IFD invia una trama detta PTS request (Protocol Type Selection). Dopo la risposta della card (PTS response) sarà selezionato uno tra i protocolli negoziabili, e inizierà la comunicazione vera e propria. 7784 Capitolo 4 La sequenza di disattivazione è la seguente: abbassare il livello di RST; abbassare CLK; scollegare V pp ; abbassare I/O; disattivare l alimentazione V cc Sistema operativo L elaborazione dei comandi, la gestione del file system e molte altre caratteristiche delle smart card dipendono dal particolare sistema operativo cablato in ROM, che pilota le operazioni del microcontroller. In un certo senso possiamo pensare ad una smart card come ad una scatola nera alla quale inviamo dei comandi e dalla quale riceviamo delle risposte. Sebbene chiamare Sistema Operativo i pochi Kbyte cablati nelle ROM delle smart card potrebbe sembrare fuorviante, per rendersi conto dell alto grado di sviluppo al quale si è arrivati è sufficiente pensare al fatto che molti tra i sistemi operativi per smart card permettono di incorporare interpreti per linguaggi di alto livello come Basic o Java. Lo sviluppo di un Sistema Operativo per una Smart Card è diverso da quello che si avrebbe in un computer tradizionale, in quanto sono diverse le condizioni ambientali (in cui il SO è inserito) e le condizioni di utilizzo. In una smart card si ha a disposizione pochissima memoria (nell ordine dei Kbyte), non è presente alcuna interfaccia utente ed infine sono ottimizzate per garantire la massima sicurezza dei programmi, durante la loro esecuzione, e dei dati, durante il loro accesso o elaborazione. Queste condizioni sono molto restrittive e rendono necessario lo sviluppo di un sistema specifico che, pur avendo affinità di base con i normali sistemi operativi, deve per forza differenziarsi da essi. 7885 Smart Card Le dimensioni di un sistema operativo per smart card dipendono dalle caratteristiche e dalle funzioni della scheda. In generale si va dai 3 KB di sistemi per singole applicazioni, ai 30 KB per smart card multiapplicazione. I compiti principali che un sistema operativo per smart card deve assolvere sono: trasferimento dei dati dalla smart card verso l esterno e dall esterno verso la smart card; controllo dell esecuzione dei comandi; gestione dei file; gestione ed esecuzione di algoritmi crittografici (per smart card crittografiche) File system Molti dei comandi dello standard ISO/IEC sono rivolti alla gestione del file system. Una smart card consente solo l utilizzo di strutture standardizzate di file. I dati sono organizzati secondo la gerarchia ad albero illustrata nella figura seguente. MF DF EF Figura 31. Struttura gerarchica del file system di una smart card. 7986 Capitolo 4 I file si dividono principalmente in due categorie: Dedicated File (DF): è un contenitore di file (directory) che può avere al suo interno degli EF o anche altri DF di livello inferiore. Il DF radice è chiamato Master File (MF) e rappresenta la directory root del file system. Non esistono limitazioni al livello di profondità dei DF (eccetto la limitazione di spazio). Nelle schede multiapplicazione si tende a creare una directory (e quindi un DF) per ogni applicazione. Elementary File (EF): contengono i dati utili per le applicazioni. Si dividono a loro volta in: o Internal EF: contengono dati che utilizza il sistema operativo (ad esempio dati del SO stesso, di una applicazione, chiavi segrete o codice programma). L accesso a questi file è protetto. o Working EF: contengono dati utili per le applicazioni esterne, cioè dati che sono destinati ad un utilizzo al di fuori della scheda. La figura sottostante mostra una schematizzazione dei vari tipi di file. File Directory Data MF EF DF Internal EF Working EF Figura 32. Tipi di file presenti in una smart card. I dati all interno degli EF possono essere organizzati secondo una di queste quattro strutture predefinite: 8087 Smart Card Transparent. Ci si riferisce con questo termine ad una sequenza binaria non strutturata, alla quale si può accedere in lettura o scrittura per singoli byte o per blocchi; Linear Fixed. I dati sono organizzati in record di lunghezza fissa: ogni file può contenerne al massimo 254. Questa struttura permette operazioni di lettura/scrittura di un numero intero di record. La lunghezza di ogni record può essere al massimo di 254 byte; Linear Variable. Come per la struttura linear fixed, l unità minima di lettura/scrittura è il record, fino ad un massimo di 254 per ogni file. La dimensione dei record è variabile (da un minimo di un byte fino ad un massimo di 254 byte), e ogni record ha un campo supplementare che ne indica la lunghezza. La tipica applicazione di una struttura simile è una rubrica telefonica, nella quale i nomi e i numeri di telefono non hanno lunghezza fissa: usare allo stesso scopo una struttura linear fixed è possibile, ma non efficiente in termini di gestione dello spazio in memoria; Cyclic. È basata sulla struttura linear fixed (dimensione massima di un record 254 byte), ma ha in più un puntatore che indica l ultimo record che è stato scritto. Raggiunto l ultimo record, il puntatore indirizzerà i successivi accessi al primo record della struttura (lista ciclica). Anche in questa struttura il massimo numero di record memorizzabile è 254. Ognuno dei file appena introdotti, oltre a contenere i dati, deve anche fornire alcune informazioni sul suo formato. Tutte le informazioni riguardanti il file sono contenute sul file stesso attraverso una struttura di questo tipo: Header Body File Figura 33. Struttura interna di un file. 8188 Capitolo 4 Un file è costituito da una intestazione (header) che contiene informazioni sulla struttura del file e sulle condizioni di accesso. Questa punta al corpo del file (body) che contiene i dati veri e propri. Per motivi di sicurezza solo il sistema operativo può accedere all intestazione del file, mentre all utente (o a qualsiasi applicazione esterna) sarà proposto solo il corpo del file. Per questo l header e il body sono contenuti in due pagine diverse della memoria, in quanto, in caso contrario, si potrebbero sfruttare dei trucchi per accedere all header e cambiare le condizioni di accesso al file. Ogni file, infine, può essere selezionato usando un opportuno identificatore (FID: File Identifier), cioè un campo di due byte che contiene il nome del file (in esadecimale 45 ). L utilizzo di alcuni di questi identificatori è riservato, come ad esempio FID 3F00 che è associato al master file, oppure FID FFFF riservato ad applicazioni future. Analogamente esiste anche un identificatore per le applicazioni chiamato Application Identifier (AID) Protocolli di trasmissione Attualmente le smart card utilizzano due protocolli di trasmissione denominati T=0 e T=1. Sono due protocolli per comunicazioni seriali asincrone di tipo half duplex. Per il futuro sono previsti anche altri tipi di protocolli, come ad esempio il T=2 che sarà in grado di gestire comunicazioni full duplex, ma sono ancora in fase di sviluppo. Protocollo T=0 Il protocollo T=0 è forse il più comune, anche perché largamente impiegato nello standard GSM. Si tratta di un protocollo di comunicazione byteoriented, nel quale ogni unità di trasmissione è preceduta da un bit di start a 45 La smart card impiega un modo di indirizzamento codificato in esadecimale in quanto, non esistendo alcuna interfaccia utente, tali indirizzi devono essere compresi solo dai programmi. 8289 Smart Card livello basso e seguito da un bit di parità e da un livello alto della durata di due bit (guard time) che segnala la fine della trasmissione. start bit n data byte n parity bit n start bit n+1 guard time Figura 34. Esempio di un byte dati e bit di controllo del protocollo T=0. T=0 adotta un modello di comunicazione master-slave, nel quale il segnale di comando è sempre generato dall IFD (master) e il segnale di risposta dalla smart card (slave). I dati scambiati tra IFD e smart card sono organizzati in trame chiamate TPDU (Transmission Protocol Data Unit). La trama di comando inviata dall IFD alla smart card ha sempre la seguente struttura. CLA INS P1 P2 P3 Figura 35. Trama di comando T=0. Nella trama di comando distinguiamo i seguenti campi: CLA. Classe dell istruzione. INS. Codice dell istruzione. P1, P2. Parametri dell istruzione. P3. Lunghezza dell eventuale blocco di dati seguente. Dopo ogni comando il protocollo prevede l invio da parte della smart card, di un codice di risposta (ACK). A seconda del tipo di istruzione selezionata dalla trama di comando, ad ACK segue la trasmissione dei dati da o 8390 Capitolo 4 per la smart card. Se viene rilevato un errore di parità su un byte del blocco trasmesso, il ricevente (IFD o smart card) abbassa il livello della linea I/O prima che termini il guard time, forzando la ripetizione della trasmissione dell intera trama. La comunicazione termina con due byte di stato inviati dalla smart card all IFD (SW1 e SW2), che contengono gli eventuali codici di errore. Il valore 0x9000 segnala il successo dell operazione. Il controllo di parità può rilevare solo errori sul singolo bit; inoltre, se durante il trasferimento dall IFD alla card di una sequenza di lunghezza P3, viene perso un byte, si incorre nello stallo (deadlock) della card, che si può sbloccare solo riattivando la linea RST. La probabilità che si verifichino errori di questo tipo è comunque molto bassa. T=0 si colloca tra il primo (livello fisico) e il secondo (data link) livello dello stack ISO/OSI, poiché interviene sia sull elaborazione del singolo byte (introducendo i bit di parità), che nella definizione dell intera trama. La mancata separazione dei layer rende T=0 poco adatto al trattamento di dati cifrati, per i quali è preferibile che i blocchi trasmessi siano trattati direttamente dai livelli sorgente e destinazione, lasciando ai layer intermedi il solo compito di inserire le intestazioni che gli competono. T=0 garantisce un buon transfer rate medio 46, e la larga diffusione sul mercato, unita alla semplicità della realizzazione, lo rendono una soluzione ancora molto praticata, sebbene in rapida obsolescenza. Protocollo T=1 T=1 è un protocollo block-oriented più complesso e articolato di T=0, classificabile al livello data-link dello stack ISO/OSI. La differenza fondamentale con T=0 è che l unità minima di trasmissione è una sequenza di byte di lunghezza variabile (block o frame). T=1 si appoggia su un protocollo del livello fisico simile a T=0, ma senza controllo di parità. Il controllo degli errori viene effettuato sull intero blocco dei dati scambiati tra smart card e IFD, realizzando in questo modo la separazione dei layer e rendendo T=1 più adatto per il trasporto di dati cifrati. 46 Il valore del transfer rate dipende dalla frequenza di clock del microcontroller e da altri parametri in gioco. 8491 Smart Card La comunicazione inizia dopo la ricezione dell ATR da parte dell IFD, oppure dopo un eventuale PTS andato a buon fine. La struttura di un blocco è illustrata qui sotto. Prologue field Information field Epilogue field node address protocol control byte length APDU EDC NAD PCB LEN 1 byte 1 byte 1 byte byte byte Figura 36. Struttura di un blocco T=1. Il campo NAD permette di controllare la tensione V pp (2 bit) e di codificare indirizzi logici di sorgente e destinazione dei dati (ognuno su 3 bit). PCB codifica varie informazioni sulla gestione del protocollo. LEN codifica la lunghezza in byte del campo successivo. Il valore 0xFF per questo campo è riservato per future estensioni. Il campo APDU (Application Protocol Data Unit) contiene i dati da o per il livello applicativo. EDC (Error Detection Code) contiene un codice di correzione degli errori calcolato sui campi precedenti, selezionabile via ATR tra un codice di ridondanza ciclica (CRC) o longitudinale (LRC). A parità di condizioni generali (frequenza di clock e altri parametri) l analisi delle prestazioni indica che i transfer rate ottenibili con T=0 e con T=1 sono molto simili. T=1 dispone di un meccanismo di rilevazione e correzione degli errori più affidabile e, come abbiamo visto, realizza una separazione tra i livelli preferibile in determinate circostanze (secure messaging). Dall altro lato, T=1 richiede una programmazione più complessa e un buffer sulla scheda di dimensioni in media quattro volte maggiori rispetto al buffer sufficiente per T=0 (300 byte contro 1100). 8592 Capitolo Application Protocol Data Unit Le strutture dati APDU (Application Protocol Data Unit) definite nello standard ISO/IEC contengono sia i comandi provenienti dal livello applicativo e destinati alla smart card, sia le risposte che quest ultima restituisce ai livelli superiori dopo aver elaborato i dati in ingresso. Le APDU sono quindi distinte in due classi: command APDU e response APDU. La struttura più generale di un APDU di comando è la seguente. CLA INS P1 P2 Lc Data Le header body Figura 37. APDU di comando. I primi quattro campi sono lunghi ciascuno un byte e costituiscono l intestazione (header); i restanti tre (body) sono opzionali e di lunghezza variabile. CLA identifica lo specifico set di comandi che si sta usando: ad esempio un valore 0xA0 per CLA identifica il set di comandi dello standard GSM Ai comandi ISO è assegnato il range 0x0X (dove X è una qualsiasi cifra esadecimale), mentre i valori di CLA appartenenti al range 0x8X e 0x9X sono riservati per i comandi proprietari definiti dal costruttore della card. INS contiene la codifica dell istruzione. Per motivi di compatibilità con i protocolli di trasferimento dati sottostanti (T=0 e T=1) sono vietate le configurazioni con INS pari, e i range 0x6X e 0x9X. I byte seguenti dell intestazione (P1 e P2) possono assumere qualsiasi valore, e vengono usati per fornire maggiori informazioni sull istruzione codificata in INS (sono i parametri del comando). Il corpo dell istruzione può mancare del tutto o essere presente solo parzialmente, dando luogo a quattro possibili configurazioni significative per un APDU di comando. 8693 Smart Card a) header b) header Le c) header Lc data d) header Lc data Le Figura 38. Possibili configurazioni di una APDU di comando. I campi Lc e Le hanno lunghezza variabile da uno a tre byte, e codificano rispettivamente la lunghezza in byte del successivo campo dati, e il numero di byte che ci si aspetta in risposta dalla smart card. Il campo data contiene gli eventuali dati che la card dovrà processare. La struttura dell APDU di risposta è la seguente. Data SW1 SW2 Figura 39. APDU di risposta. Il campo Data è opzionale, con lunghezza pari al valore del campo Le del comando che ha richiesto la risposta, e naturalmente contiene il risultato dell elaborazione della smart card. I due campi SW1 e SW2 sono obbligatori e contengono i codici di stato (Status Word) della smart card. Valori pari a 0x61XX o 0x9000 identificano l assenza di errori o di condizioni anomale, mentre altri valori, così come specificato nello standard, si riferiscono ad errori o situazioni eccezionali. Come si può notare, la struttura descritta è molto simile a quella definita nel protocollo di trasferimento T=0: la corrispondenza con i TPDU è definita caso per caso nella normativa. Ad esempio, per una command APDU con il solo header il campo P3 del TPDU è impostato a 0x00. Nel caso del protocollo T=1, le APDU vengono mappate nel campo information senza alcun cambiamento. 8794 Capitolo 4 La figura seguente mostra l integrazione tra i protocolli di trasmissione descritti nel paragrafo precedente e i comandi del livello applicativo: nel blocco Card si può identificare il sottosistema di I/O, e in APDU Processor il sistema operativo/cpu. Application Command Response Funzioni specifiche della card Reader Command (T=0 / T=1) Response Card Command Response APDU Processor Figura 40. Schema di una comunicazione tra una applicazione e la smart card. 4.6 Interfaccia con le applicazioni Abbiamo visto in che modo una smart card comunica con il proprio lettore, attraverso i protocolli T=0 o T=1, e con le applicazioni, attraverso le APDU di comando e di risposta. In questo paragrafo andremo a descrivere più in dettaglio la struttura dell interfaccia tra la smart card e le applicazioni che richiedono i suoi servizi. Verranno illustrate e discusse tre principali architetture: PC/SC, Open Card Framework e Java Card. 8895 Smart Card PC/SC Il progetto PC/SC è centralizzato sull interoperabilità tra smart card e card terminal e la cooperazione tra card terminal e personal computer. Si struttura in otto parti che ricoprono tutte le specifiche: dalle caratteristiche fisiche della smart card e del suo lettore fino al livello applicazione. Figura 41. Architettura PC/SC. 8996 Capitolo 4 Part 1. Fornisce una descrizione introduttiva dell architettura PC/SC. Part 2. Specifica le caratteristiche fisiche della scheda (ICC) e del lettore (IFD) e da indicazioni sulle regole di gestione degli errori. Part 3. Specifica le caratteristiche dell interfaccia tra lettore e PC in modo da rendere il sistema indipendente dal dispositivo fisico. La parte 3 e la parte 2 (quindi l IFD e l IFD Handler) costituiscono quello che viene chiamato Interface Device Subsystem. Part 4. Descrive le linee guida per lo sviluppo di protocolli interni relativi all interfaccia descritta nella parte 3. Part 5. Definisce il componente base dell architettura PC/SC: l ICC Resource Manager. Esso si occupa di gestire le richieste provenienti dalle applicazioni e smistarle ai diversi lettori di schede, nonché regolare gli accessi multipli ad una stessa risorsa. Part 6. Specifica le due interfacce primarie usate dall applicazione: ICC Service Provider: contiene una classe che mantiene il contesto della comunicazione con la smart card (necessaria nel caso di accessi multipli). In più può anche fornire primitive per l accesso ai file della scheda o per le operazioni di autenticazione. Crypto Service Provider: specifica le primitive per le operazioni crittografiche quali generazione e gestione delle chiavi, firma digitale, funzioni di hash e altre ancora. Part 7. Contiene consigli per il programmatore sull utilizzo di questa interfaccia. Part 8. Contiene consigli su come gestire l identificazione, l autenticazione e la memorizzazione sicura dei dati Open Card Framework Lo scopo che gli sviluppatori di OCF hanno voluto raggiungere è quello di realizzare un interfaccia di alto livello tra la smart card e le applicazioni il più possibile universale in termini sia di tipologie di schede adottabili, sia di diversi tipi di computer o sistemi operativi. Tale progetto è stato sviluppato con tecnologia Java sfruttando i vantaggi di una struttura orientata agli oggetti. 9097 Smart Card L Open Card Framework è strutturato in questo modo: Figura 42. Architettura OCF. Nel livello più alto c è l applicazione (application developer) che vuole comunicare con la smart card. Il Card Issuer è responsabile dell application management layer che si occupa di eseguire e far coesistere più applicazioni in una stessa card. Può accadere che un applicazione richieda una funzione specifica di una determinata smart card (ad esempio una funzione crittografica), in questo caso, se si dispone di una JavaCard la funzione viene eseguita come applet all interno della card stessa, altrimenti la funzione deve essere fornita dall interfaccia OCF tramite il Card Service. Esso contiene tutte le informazioni riguardanti il sistema operativo e le funzioni supportate dalla scheda. Nel livello più basso troviamo il Card Terminal che interfaccia direttamente con l hardware (è una classe che astrae il lettore della scheda). L Open Card Framework Core contiene cinque oggetti: CardServiceScheduler, SmartCard (che non è il dispositivo fisico ma una sua 9198 Capitolo 4 astrazione), CardID e i due registri: CardServiceRegistry e CardTerminalRegistry. Quando viene inserita una smart card nel lettore per prima cosa vengono creati gli oggetti SmartCard e CardID che identificano il tipo di scheda. Il CardServiceFactory contiene le informazioni riguardanti i servizi offerti da una smart card. Quando un applicazione richiede un certo servizio ad una determinata scheda il CardServiceRegistry chiama tutti i CardServiceFactory relativi al CardID dell oggetto SmartCard finché non viene creato un appropriato oggetto CardService. In modo analogo, quando si inserisce la smart card (e dopo l avvenuta identificazione), il CardTerminalRegistry chiama tutti i CardTerminalFactory relativi al CardID dell oggetto SmartCard finché non viene creato l oggetto CardTerminal opportuno. Per fare in modo che OCF funzioni con diverse smart card, ognuna di esse deve disporre del relativo CardTerminal Confronto tra OCF e PC/SC La prima differenza sta nella struttura architetturale delle due soluzioni. OCF segue maggiormente una filosofia ad oggetti accentrata principalmente sui servizi offerti dalla smart card, PC/SC invece è meno orientato agli oggetti e tiene più in considerazione i dispositivi fisici che sono appunto personal computer e smart card. Un immediato riscontro di questo diverso approccio lo si può trovare analizzando il CardTerminal di OCF che non fornisce specifiche sul suo funzionamento di basso livello, cosa che invece avviene (e in modo molto dettagliato) sia nell IFD che nell IFD Handler di PC/SC. Una differenza più forte si evidenzia nell ambito delle applicazioni crittografiche. PC/SC presenta un componente dedicato a questo tipo di funzioni: il Crypto Service Provider, cosa che invece viene a mancare nell altra struttura. Per questo si può dire che PC/SC è più orientato verso la crittografia rispetto ad OCF. Le due soluzioni comunque hanno anche molte cose in comune, come è facile aspettarsi da due progetti che, nonostante seguano strade diverse, si 9299 Smart Card pongono lo stesso obiettivo. Ci sono infatti alcuni componenti che offrono funzionalità simili (e a volte equivalenti). E il caso dell ICC Service Provider di PC/SC e del CardService di OCF; oppure l Interface Device Subsystem di PC/SC e il CardTerminal di OCF. In definitiva, sia OCF che PC/SC offrono, in un modo o nell altro, una valida interfaccia che garantisce tutti i servizi offerti dalla scheda e richiesti dalle applicazioni. Forse la differenza più importante riguarda il loro campo di utilizzo. OCF infatti, essendo strutturato ad oggetti e sviluppato in Java, può essere utilizzato in modo indipendente dal sistema operativo che il personal computer supporta, mentre PC/SC è strettamente legato a Microsoft Windows. Dall altra parte PC/SC è in grado di interfacciarsi con qualsiasi linguaggio di programmazione, mentre OCF è ristretto al campo delle applicazioni Java Java Card Una Java Card è un particolare tipo si smart card che consente l utilizzo, all interno della scheda stessa, del linguaggio di programmazione Java, così da poterne sfruttare le caratteristiche di sicurezza, robustezza e compatibilità con vari sistemi operativi. La Java Card contiene una versione rivista della Java Virtual Machine chiamata Java Card Virtual Machine (JCVM) che interagisce col sistema operativo della smart card. Questa, in pratica, implementa tutte le funzioni che la smart card deve offrire e le rende disponibili sottoforma di applet. La JCVM in realtà contiene un sottoinsieme di tutte le classi costituenti il linguaggio Java a causa delle forti limitazioni di spazio e potenza di calcolo presenti in una smart card. L insieme delle classi caricate nella Java Card costituisce l interfaccia (API) con le funzioni della scheda ed è chiamata Java Card Framework. Questa è composta da quattro package: javacard.framework: è il package più importante e fornisce la struttura base del linguaggio Java. Deve essere in ogni Java Card; javacardx.framework: contiene le classi per la gestione dei file; 93100 Capitolo 4 javacardx.crypto: implementa le funzioni crittografiche; javacardx.cryptoenc: fornisce i metodi di cifratura. Il primo è essenziale ed è installato su tutte le Java Card, mentre gli altri tre sono delle estensioni (opzionali) che vengono installate appositamente dal costruttore. Sul secondo package è bene fare una precisazione: in effetti una Java Card non include un file system vero e proprio, ma la gestione dei file è affidata ad apposite applet (contenute appunto in questo pacchetto). Queste applet ovviamente rispettano lo standard ISO/IEC riguardante la sintassi e la struttura dei file. Meritano una nota particolare i due ultimi pacchetti. La poca memoria disponibile in una smart card rende impossibile (o comunque molto lenta) l esecuzione di algoritmi crittografici complessi programmati in Java, per questo nei due package sono contenute classi che riportano gli algoritmi in codice macchina nativo in modo da velocizzarne l esecuzione. Non è stato possibile unificare tutte le funzioni crittografiche in un solo pacchetto a causa di alcune restrizioni legislative. Queste riguardano l esportazione e l utilizzo di funzioni crittografiche. L uso della crittografia infatti non è consentito liberamente, ma è soggetto a leggi locali diverse da paese a paese. In particolare se si intende usare algoritmi crittografici per le sole operazioni di decifratura è sufficiente servirsi del pacchetto javacardx.crypto, mentre se si hanno anche esigenze di cifratura allora occorre implementare il pacchetto javacardx.cryptoenc. In definitiva tutte le funzioni della Java Card vengono eseguite come applet all interno della JCVM. Vediamo ora più in dettaglio l iter da seguire per lo sviluppo e l esecuzione di una applicazione destinata ad una Java Card. 94101 Smart Card Figura 43. Processo di sviluppo di una applicazione per Java Card. Il procedimento è del tutto simile a quello impiegato per realizzare un qualsiasi software Java per computer: si parte dal codice sorgente e si compila per ottenere il bytecode. La differenza sta proprio nella Virtual Machine. La JCVM infatti è composta di due parti: una Off-card VM che riceve il bytecode e vi esegue le varie operazioni di verifica (riguardanti il formato, la sintassi e, se presente, la firma). Questa inoltre crea un file CAP (Card Application File) da inviare all altra parte della VM; una On-card VM che riceve il file CAP e ne testa e interpreta il bytecode generando le istruzioni macchina per il processore della smart card. Una soluzione di questo tipo porta tutti i vantaggi che sono caratteristici del linguaggio Java, in particolare la robustezza, la sicurezza e l indipendenza dall hardware in uso. Con questa struttura è inoltre possibile eseguire più applet su una stessa Java Card garantendo comunque la loro indipendenza (attraverso un controller di accesso) e la sicurezza dei dati. Il problema più grande invece riguarda l impiego di risorse. Nelle smart card la memoria disponibile è poca e va preziosamente custodita. Per una 95102 Capitolo 4 stessa funzione l impiego di una Java Card richiede maggiori risorse rispetto ad una smart card tradizionale. Questo si fa sentire maggiormente in applicazioni crittografiche, dove le esigenze di calcolo sono più elevate. Da quanto detto si può concludere che l utilizzo di una Java Card può risultare vantaggioso fin quando si eseguono applicazioni semplici come ad esempio la gestione dei file (in pratica quando si utilizzano smart card per fini che esulano dalla crittografia, come ad esempio operazioni bancarie o telefoniche). Quando invece si entra nell ambito crittografico si deve raggiungere un compromesso tra una maggiore sicurezza e indipendenza dall hardware ed una minore capacità prestazionale dovuta appunto ad un impiego più massiccio di risorse. 4.7 PKCS#11 Abbiamo già introdotto (nel capitolo relativo alle infrastrutture a chiave pubblica) la famiglia di standard PKCS 47 che regolamentano le condizioni di impiego di algoritmi crittografici asimmetrici. Analizzeremo ora in dettaglio una particolare sezione dello standard, denominata PKCS#11: Cryptographic Token Interface Standard. Questo standard specifica un interfaccia per la programmazione di applicazioni (API), detta Cryptoki (Cryptographic Token Interface), per tutti quegli strumenti che contengono informazioni, o sono in grado di implementare funzioni, di tipo crittografico. Cryptoki segue un approccio basato sulla programmazione ad oggetti cercando di raggiungere l obiettivo dell indipendenza tecnologica e della condivisione di risorse presentando alle applicazioni una visione comune e di tipo logico del dispositivo crittografico che viene denominato cryptographic token. Lo standard specifica i tipi di dato e le funzioni disponibili per un applicazione che richiede servizi crittografici. Cryptoki isola un applicazione dai dettagli del dispositivo crittografico. L applicazione non deve cambiare se vuole interfacciarsi con un nuovo tipo di periferica o se vuole girare sotto un 47 Vedi paragrafo Standard PKCS. 96103 Smart Card altro ambiente, in altre parole l applicazione diventa portabile e si garantisce la proprietà di interoperabilità. E importante precisare che non è necessario che tutti i dispositivi crittografici siano in grado di eseguire la totalità delle funzioni offerte dall interfaccia. Il compito di cryptoki è quello di rendere disponibile un modo logico di programmare i dispositivi, di qualunque tipo essi siano. Per cui ognuno di essi, nella realtà, implementerà un sottoinsieme delle funzioni offerte da cryptoki. PKCS#11 non specifica i dettagli di programmazione, ma si limita a fornire una descrizione precisa dei tipi di dato e delle funzioni che possono essere utilizzati da uno sviluppatore di software per scrivere la propria applicazione Caratteristiche tecnologiche Il modello generale di cryptoki è illustrato nella seguente figura. Figura 44. Modello generale Cryptoki. 97104 Capitolo 4 Il modello illustra i vari stadi di una comunicazione tra una o più applicazioni che richiedono operazioni crittografiche e uno o più dispositivi in grado di eseguire tali operazioni. L applicazione non comunica direttamente con il dispositivo fisico, ma, tramite l interfaccia cryptoki, accede ad un oggetto che rappresenta la sua astrazione logica: il Token. In particolare si possono evidenziare due oggetti: il Token, che astrae il dispositivo fisico in grado di svolgere operazioni crittografiche (ad esempio la smart card); e lo Slot, che astrae il dispositivo fisico di lettura. Questo modello rende tutti i dispositivi crittografici logicamente uguali, in modo che l applicazione non debba interfacciarsi direttamente ai driver della periferica e ciò rende possibile l interoperabilità. Cryptoki permette inoltre ad una o più applicazioni di accedere ad uno o più token. E capace infatti di gestire il funzionamento multisessione attraverso il blocco Device Contention/Synchronization che smista le richieste delle applicazioni ai rispettivi token. Cryptoki viene implementato tramite una libreria scritta in ANSI 48 C alla quale l applicazione si può collegare in modo diretto o dinamico Sessioni Cryptoki richiede che un applicazione apra una o più sessioni con un token per guadagnare l accesso agli oggetti ed alle funzioni del token stesso. Una sessione fornisce una connessione logica tra l applicazione e il token, e può essere di due tipi: R/W (Read/Write) oppure R/O (Read/Only). Le denominazioni R/W e R/O si riferiscono agli oggetti del token, non a quelli della sessione. In entrambi i tipi di sessione, infatti, un applicazione può creare, leggere, scrivere e distruggere oggetti sessione e leggere oggetti token. Solo in una sessione R/W è però consentito creare, modificare o distruggere oggetti token. 48 American National Standard for Programming Language. 98105 Smart Card Una volta aperta la sessione l applicazione ha accesso a tutti gli oggetti pubblici del token, per accedere a quelli privati è necessario autenticarsi tramite una procedura di login (nella quale bisogna fornire il PIN del token). Quando una sessione viene chiusa tutti gli oggetti creati al suo interno vengono distrutti, questo vale anche per oggetti che sono in uso da parte di altre sessioni. Cryptoki infatti supporta le operazioni multissessione, ma un particolare token permette solo un certo numero di sessioni aperte per ogni applicazione. Sessioni R/O Una sessione di sola lettura è costituita da due diversi stati. Figura 45. Stati di una sessione R/O. Quando la sessione viene aperta può trovarsi nello stato R/O Public Session se non è stata eseguita alcuna autenticazione, o nello stato R/O User Functions se l utente è stato autenticato. Nel primo caso l applicazione ha accesso in sola lettura agli oggetti token pubblici e in lettura e scrittura agli oggetti sessione pubblici. Nel secondo caso l applicazione ha accesso in sola lettura a tutti gli oggetti del token (pubblici e privati) e in lettura e scrittura a tutti gli oggetti sessione (pubblici e privati). 99106 Capitolo 4 Sessioni R/W Una sessione di lettura e scrittura è costituita da tre stati. Figura 46. Stati di una sessione R/W. Quando la sessione è aperta si può trovare nello stato R/W Public Session se non sono state eseguite autenticazioni, nello stato R/W User Functions se è stata eseguita una autenticazione, nello stato R/W SO Functions se è stato autenticato un utente di tipo SO (Security Officer: ha il compito di inizializzare il token impostando il PIN o manipolando alcuni oggetti pubblici). Nel primo caso l applicazione ha accesso in lettura e scrittura a tutti gli oggetti pubblici. Nel secondo caso l applicazione ha accesso in lettura e scrittura a tutti gli oggetti. Nell ultimo caso l applicazione ha accesso in lettura e scrittura ai soli oggetti pubblici del token. Eventi di sessione A seguito di particolari operazioni una sessione può cambiare il suo attuale stato. Gli eventi responsabili del cambiamento di stato di una sessione sono: 100107 Smart Card Log In SO: il Security Officer è stato autenticato dal token. Log In User: il normal user è stato autenticato dal token. Log Out: l applicazione disconnette l utente corrente (che sia SO o normal user). Colse Session: l applicazione chiude la sessione corrente o tutte le sessioni da lei aperte. Device Removed: il token viene rimosso dal dispositivo di lettura. In Cryptoki tutte le sessioni che un applicazione ha con un token devono avere lo stesso stato di autenticazione. Quando un applicazione si autentica all interno di un token tutte le sessioni di quell applicazione diventano autenticate dal token stesso e se un applicazione si disconnette da un token tutte le sessioni dell applicazione vengono automaticamente chiuse. Le sessioni vengono gestite da un handle di sessione, che è un valore che identifica univocamente una sessione. Tale valore viene specificato alle funzioni per indicare loro su quale sessione devono agire Oggetti Un token è un dispositivo che contiene oggetti e può operare funzioni di tipo crittografico. Cryptoki definisce tre classi di oggetti: dati, certificati e chiavi. Un oggetto dato è specificato dall applicazione, un oggetto certificato contiene un certificato digitale, un oggetto chiave contiene una chiave crittografica che può essere pubblica, privata o segreta. Ogni oggetto chiave possiede dei sottotipi che ne specificano l utilizzo nei meccanismi 49. La gerarchia degli oggetti è la seguente. 49 Nel testo tecnico PKCS#11: Cryptographic Token Interface Standard della RSA Laboratories, gli algoritmi crittografici vengono indicati con il nome di mechanism e di conseguenza tradotti in meccanismi. 101108 Capitolo 4 Figura 47. Gerarchia degli oggetti definiti in cryptoki. Gli oggetti possono anche essere classificati in base al loro tempo di vita e alla loro visibilità, si possono quindi distinguere: Oggetti token: sono visibili a tutte le applicazioni connesse al token che hanno un permesso sufficiente e permangono all interno del token anche quando la sessione viene chiusa ed il token rimosso dallo slot. Oggetti sessione: ogni volta che una sessione viene chiusa tutti gli oggetti creati dalla sessione vengono distrutti. In aggiunta tali oggetti sono visibili solo all applicazione che li ha creati. Un ulteriore classificazione può essere fatta in base ai requisiti di accesso, quindi troviamo: Oggetti pubblici: un applicazione non ha necessità di eseguire un login al token per vederli. Oggetti privati: sono visibili solo a seguito di una avvenuto login. In generale un oggetto consiste in una serie di attributi, ognuno dei quali è caratterizzato da un determinato valore. Andiamo ora a vedere più da vicino le tre principali classi di oggetti definite da cryptoki. 102109 Smart Card Oggetti Data Un oggetto Data contiene informazioni relative alle applicazioni ed è definito da cryptoki con i seguenti attributi: Data object Application Object ID Value Figura 48. Attributi di un oggetto Data. Oggetti Key Gli oggetti Key contengono chiavi di crittografia e autenticazione, che possono essere private, pubbliche o segrete. Key Key type Key ID Start Date End Date Derive Local Key Gen Mechanism Public Key Subject Trusted Encrypt Verify Verify Recover Wrap Private Key Subject Sensitive Decrypt Sign Sign Recover Unwrap Extractable Always Sensitive Never Extractable Secret Key Sensitive Encrypt Decrypt Sign Verify Wrap Unwrap Extractable Always Sensitive Never Extractable Figura 49. Gerarchia e attributi di un oggetto Key. 103110 Capitolo 4 Oggetti Certificate Gli oggetti Certificate possono memorizzare certificati a chiave pubblica. Cryptoki specifica la modalità di accesso a questo tipo di oggetti, ma non attribuisce significati ed usi ai certificati. Certificate Certificate Type Trusted X.509 Public Key Certificate Subject Certificate ID Issuer Serial Number Value X.509 Attribute Certificate Owner Issuer Serial Number Attribute Types Value Figura 50. Gerarchia e attributi di un oggetto Certificate. In realtà cryptoki prevede anche altri tipi di oggetti, che forniscono informazioni aggiuntive riguardanti, ad esempio, le caratteristiche hardware del dispositivo e gli algoritmi crittografici supportati. La visione generale della gerarchia di alto livello degli oggetti definiti dallo standard cryptoki e di alcuni attributi ad essi associati è illustrata nella seguente figura. 104111 Smart Card Figura 51. Gerarchia completa degli oggetti definiti nello standard cryptoki Considerazioni sulla sicurezza Come interfaccia ai dispositivi crittografici Cryptoki fornisce le basi per la sicurezza all interno di un computer o di un sistema di comunicazione. Le due principali caratteristiche dell interfaccia che facilitano tale compito sono: L accesso agli oggetti privati, le funzioni crittografiche e i certificati di un token richiede un PIN. Quindi il semplice possesso del dispositivo crittografico non è sufficiente per usarlo, è necessario anche conoscere il PIN di autenticazione. Una protezione aggiuntiva per le chiavi private o segrete può essere garantita designandole come sensitive, cioè che non possono mai essere rivelate in chiaro al di fuori del token, oppure unextractable, ovvero non possono mai essere rivelate al di fuori del token neanche in forma criptata (anche se rimangono comunque utilizzabili). Ci si aspetta che l accesso ad oggetti privati di tipo sensitive o unextractable risulti difficile all infuori dell interfaccia Cryptoki. Un dispositivo è solitamente dotato di un ambiente protetto (ad esempio una memoria protetta) 105112 Capitolo 4 in cui memorizzare dati di questo tipo, alcuni dispositivi però non hanno questa possibilità, quindi devono proteggere i loro oggetti in altro modo. Una soluzione è quella di cifrare tali oggetti con una chiave speciale, detta master key, che viene ricavata dal PIN dell utente. Sicuramente la crittografia è solo un elemento di sicurezza, e il token rappresenta solo un componente di un sistema, per cui la sicurezza deve essere intesa a livello globale. Mentre un token può essere considerato sicuro, bisogna allargare il campo di vista anche al sistema operativo che ospita l applicazione che fa uso del token. E infatti possibile che altre applicazioni ostili intercettino informazioni riservate (come ad esempio il PIN del dispositivo) mentre queste sono gestite dal sistema operativo oppure attraversano un canale di comunicazione, con la conseguenza che l applicazione pirata potrebbe far eseguire qualsiasi tipo di operazione al token. Da notare comunque che, in ognuno di questi spiacevoli casi, le chiavi marcate sensitive o unextractable non possono in alcun modo essere rilevate o modificate. Si può quindi concludere che Cryptoki non garantisce la sicurezza dell intero sistema, ma fornisce una buona e solida base per lo sviluppo di applicazioni che fanno uso di dispositivi crittografici Provider di sicurezza IAIK Un provider di sicurezza è un software in grado di fornire la più ampia varietà di funzioni crittografiche e realizzare un interfaccia per l accesso al dispositivo crittografico. In questo lavoro è stata utilizzata un implementazione dello standard PKCS#11 sviluppata dall Institute for Applied Information Processing and Communications (IAIK) presso l università austriaca University of Technology di Graz 50. Il Provider IAIK fornisce un insieme di funzioni crittografiche accessibili mediante le API standard Java JCA (Java Cryptography Architecture) e JCE113 Smart Card (Java Cryptography Extention) e permette l accesso al dispositivo fisico tramite una libreria conforme al descritto standard PKCS#11. La parte che si occupa di comunicare direttamente col il token prende il nome di Wrapper. La libreria fornita dal wrapper fa uso dei metodi nativi di Java JNI (Java Native Interface) che permettono alle applicazioni scritte in Java di usare le API Cryptoki (che, ricordiamo, sono scritte in C). Nella figura seguente è illustrata l organizzazione dei livelli software coperti dal wrapper IAIK. Figura 52. Struttura dei livelli software del wrapper IAIK. Lo strato più basso è occupato dalla libreria dinamica di sistema fornita dal produttore del token, compilata per la piattaforma di destinazione, seguendo le direttive della specifica PKCS#11. Lo strato immediatamente superiore del wrapper è necessario per realizzare lo strato JNI che permette al codice Java di utilizzare funzioni C. Questo strato e quello ancora superiore devono quindi rispettare la convenzione dei nomi (name mangling) delle funzioni e dei metodi nativi prevista da JNI. Alla cima dello stack c è il livello API, che è una struttura Object-Oriented con la quale si interfacciano le applicazioni. Il provider IAIK è dedicato all uso di particolari dispositivi crittografici, come le smart card, e gli oggetti utilizzati durante l esecuzione delle funzioni crittografiche vengono gestiti in modo specifico. Ad esempio gli oggetti chiave del provider PKCS#11 rappresentano chiavi contenute all interno di un token e quindi non possono essere gestite come normali chiavi software. Infatti se un applicazione richiede l utilizzo di una chiave per un operazione crittografica, il provider non trasferisce la chiave alla JVM, bensì invia il dato da elaborare 107114 Capitolo 4 all interno del token e chiede al token stesso di eseguire l operazione prevista con la specifica chiave. In questo modo la chiave non esce mai al di fuori del token che contiene, oltre alla chiave stessa, anche l implementazione dell algoritmo necessario ad eseguire l operazione direttamente dentro il token. Possiamo immaginare il token come una scatola nera all esterno della quale vediamo entrare ed uscire dati in chiaro e dati cifrati, ma non possiamo in alcun modo vedere cosa avviene all interno della scatola. 108115 Realizzazione del progetto Capitolo 5. REALIZZAZIONE DEL PROGETTO 109116 Capitolo Descrizione generale del progetto Il lavoro che andrò ora a presentare è stato sviluppato in collaborazione con la ASUR zona 7 della regione Marche. Nel corso di questa tesi si è fatto spesso riferimento al settore della Pubblica Amministrazione e alla sua progressiva migrazione verso le tecnologie informatiche, allo scopo di trarre vantaggi sia per chi lavora (in termini di migliore gestione degli archivi e procedure più veloci), sia per l utenza pubblica (garantendo più efficienza nei servizi e minori tempi di attesa). Proprio in quest ottica va ad inserirsi questo progetto, del quale ora illustreremo le linee guida. L obiettivo è quello di progettare un software che utilizzi le smart card per realizzare la firma digitale di documenti elettronici. Il campo di applicazione è appunto l ambito sanitario, in cui un medico può inviare o richiedere dei referti ad un database (chiamato repository) per eventuali operazioni di teleconsulto o di second opinion. Il referto in questione, prima di essere spedito, dovrà essere firmato digitalmente, in modo da garantire i requisiti base di un sistema di sicurezza (autenticazione, integrità e riservatezza). Per il momento l attenzione è rivolta ad un utenza di soli medici, si prevede comunque che, una volta avviato il servizio, anche i pazienti possano disporre di una propria smart card. La prima decisione che si deve prendere riguarda il tipo di smart card da adottare. La scelta ricade su due possibili alternative: adottare una carta di impiego nazionale (come la CIE 51 ); oppure adottare una soluzione propria. La prima scelta sembrerebbe più vantaggiosa, considerando che, in breve tempo, tutti saranno in possesso della carta di identità elettronica; inoltre c è anche il vantaggio, non da poco, di poter usare una sola carta per più servizi. Seguire questa strada, però, si è rivelato presto difficoltoso a causa del fatto che la CIE non è ancora disponibile in tutti i comuni, inoltre c è una mancanza di divulgazione di materiale, sia tecnico che pratico, relativo al suo funzionamento. Non rimane quindi che adottare una soluzione propria che preveda l impiego di una smart card specifica per il servizio offerto. 51 Carta di Identità Elettronica. 110117 Realizzazione del progetto Come si è detto, l utenza prevista, sia attuale che futura, per questo progetto coinvolge sia i medici che i pazienti. Un campo di impiego così vasto richiede una particolare attenzione alla possibilità di utilizzo delle tecnologie informatiche proposte da parte di personale non specializzato. Si è cercato quindi di improntare il progetto verso la semplicità d uso, continuando comunque a garantire tutti i servizi e i requisiti di sicurezza previsti. Si è scelto allora di partire da zero e seguire tutti i passi necessari alla realizzazione dell infrastruttura per la firma digitale. Si prevede quindi che un utente (che si tratti, indifferentemente, di un medico o di un paziente) si procuri una smart card vuota, che dovrà essere inizializzata e resa utilizzabile per le operazioni di firma digitale. Il progetto, quindi, si compone di due parti principali: Inizializzazione: è la fase in cui la smart card è resa operabile. Si deve dotare la scheda di una coppia di chiavi e di un certificato a chiave pubblica (nel formato X.509). Più precisamente vengono create, al suo interno, la coppia di chiavi asimmetriche e la richiesta di certificato da inviare alla Certification Authority. Quest ultima firmerà un certificato X.509 che poi sarà memorizzato all interno della smart card. Firma: è la fase in cui si realizzano le operazioni legate alla firma digitale del documento elettronico. In particolare sarà possibile: cifrare il documento originale per ottenere la firma; decifrare un documento firmato; verificare la firma per testare l integrità del documento. Il software di firma riceverà in ingresso direttamente il digest del documento originale, si dovrà quindi occupare di cifrarlo con la chiave privata presente nella smart card e restituire un oggetto che contenga il documento cifrato ed il certificato a chiave pubblica (che contiene la chiave di decifratura). Il fatto di avere come input un digest rende il software di firma utilizzabile con qualunque tipo di documento e, di conseguenza, in qualsiasi contesto. 111118 Capitolo Applicazione all ambito sanitario Questo lavoro trova applicazione ad un altro progetto nato anch esso dalla collaborazione tra l Università Politecnica delle Marche e la ASUR Marche zona 7 di Ancona riguardante la delocalizzazione della refertazione diagnostica. Tale progetto, denominato MirO, si pone l obiettivo di fornire un prodotto flessibile in grado di implementare un servizio di refertazione asincrono: cioè capace di separare, sia da un punto di vista temporale che spaziale, l esecuzione di un esame dalla refertazione dello stesso. Lo scopo è quello di creare un applicazione software completa in grado di gestire l intero processo di telerefertazione e di teleconsulto. Figura 53. Posizione del progetto MiRo nel processo di telerefertazione e teleconsulto. Tale progetto intende realizzare una piattaforma orientata ai servizi che abbia le caratteristiche di flessibilità e semplicità. La sua architettura infatti è basata su standard diffusi e riconosciuti, come Internet, in modo da creare le basi per facilitare le applicazioni sia in ambito sanitario a livello di personale medico, che, in un prossimo futuro, direttamente ai cittadini. MiRo si basa sul concetto di evento. L effettuazione di un esame presso un laboratorio (qualsiasi, di una qualunque struttura ospedaliera) e la 112 Vedere altro
LA FIRMA ELETTRONICA: STRUMENTO PER LA SICUREZZA DELLE INFORMAZIONI di Marco Pironti Ricercatore di Economia e Gestione delle Imprese presso il Dipartimento di Informatica della Facoltà di Scienze MM.FF.NN. Dettagli UNIVERSITÀ DEGLI STUDI DI PARMA
UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA Tesi di laurea in RETI DI CALCOLATORI Autenticazione Centralizzata con il sistema CAS, integrando Dettagli Appunti di Sicurezza. Orgest Shehaj Appunti di Sicurezza Orgest Shehaj 26 dicembre 2012 1 Indice 1. Crittografia 2. Cifrari storici 3. Des e Rsa 4. Identificazione, Autenticazione e Firma Digitale 5. Key Management Dettagli Università degli studi di Roma Tre Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica. Protocollo SSH
UNIVERSITÀ DEGLI STUDI DI TRENTO DOCUMENTO ELETTRONICO, FIRMA DIGITALE E SICUREZZA IN RETE. INTRODUZIONE ALL ARGOMENTO. A cura di: Eleonora Brioni, Direzione Informatica e Telecomunicazioni ATI NETWORK. Dettagli REALIZZAZIONE DI UN COMPONENTE PER UN SISTEMA DEDICATO: CODIFICA AES A 512 BIT
POLITECNICO DI MILANO FACOLTÀ DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA REALIZZAZIONE DI UN COMPONENTE PER UN SISTEMA DEDICATO: CODIFICA AES A 512 BIT Relatore: Correlatore: Prof. Fabrizio Dettagli UNIVERSITÀ DEGLI STUDI DELLA CALABRIA. Realizzazione di Web services per l autenticazione "Single Sign On" su infrastruttura PKI/LDAP
UNIVERSITÀ DEGLI STUDI DELLA CALABRIA Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Orientamento Elettronica e Telecomunicazioni Realizzazione di Web services per l autenticazione "Single Dettagli IL PROCESSO TELEMATICO:
UNIVERSITA DEGLI STUDI DI MESSINA FACOLTA DI SCIENZE MM.FF.NN. CORSO DI LAUREA IN INFORMATICA IL PROCESSO TELEMATICO: REALIZZAZIONE CON J2EE Tesi di Laurea Universitaria di: Alessandro Grosso Relatore: Dettagli Introduzione alla crittografia
Capitolo 2 Introduzione alla crittografia In questo capitolo sono introdotti i concetti di base della crittografia e presentate informazioni preliminari necessarie per proseguire nella lettura del libro. Dettagli Creazione ed implementazione di una Certifcation Authority open-source. Crescenzio Gallo e Michelangelo De Bonis
Dipartimento di Scienze Economiche, Matematiche e Statistiche Università degli Studi di Foggia Creazione ed implementazione di una Certifcation Authority open-source Crescenzio Gallo e Michelangelo De Dettagli Analisi e sperimentazione di tecnologie per la mutua autenticazione e trasferimento di credenziali tra siti federati
UNIVERSITÀ DEGLI STUDI DI SIENA FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Analisi e sperimentazione di tecnologie per la mutua autenticazione e trasferimento di credenziali Dettagli Andrea Pasquinucci. Aspetti di Crittografia Moderna. Da DES alla Crittografia Quantistica
Andrea Pasquinucci Aspetti di Crittografia Moderna Da DES alla Crittografia Quantistica 001 Aspetti di Crittografia Moderna Da DES alla Crittografia Quantistica Andrea Pasquinucci Comitato Tecnico Scientifico Dettagli IPsec e TLS a confronto: funzioni, prestazioni ed estensioni
IPsec e TLS a confronto: funzioni, prestazioni ed estensioni di Davide Cerri Ottobre 2001 Il materiale contenuto in questo documento è interamente tratto dalla tesi dal titolo I protocolli IPsec e TLS Dettagli Appunti di Sicurezza by Bergami Giacomo is licensed under a Creative Commons Attribution- NonCommercial-NoDerivs 3.0 Italy License.
Appunti di Sicurezza by Bergami Giacomo is licensed under a Creative Commons Attribution- NonCommercial-NoDerivs 3.0 Italy License. 1 2 Indice 1 Introduzione 5 1.1 Tipologie di attacchi.................................. Dettagli Francesco Groccia. Informatica contraria
Francesco Groccia Informatica contraria Informatica contraria Francesco Groccia No-Copyright. Tutti i diritti rovesciati! Chiunque è invitato a usare questo documento per qualsiasi Dettagli Politecnico di Milano - Facoltà di ingegneria di Como Corso di Laurea in Ingegneria dell Ambiente e del territorio. cerri@cefriel.
Politecnico di Milano - Facoltà di ingegneria di Como Corso di Laurea in Ingegneria dell Ambiente e del territorio Sicurezza dell informazione Davide Cerri cerri@cefriel.it Sommario Introduzione Crittografia Dettagli Architetture per la protezione dell informazione nei sistemi embedded
POLITECNICO DI TORINO III Facoltà di Ingegneria dell Informazione Corso di Laurea in Ingegneria delle Telecomunicazioni Tesi di Laurea Magistrale Architetture per la protezione dell informazione nei sistemi Dettagli PtBox. Progetto di Sicurezza Informatica. CDL in Ingegneria Informatica Magistrale. Politecnico di Bari. Studenti:
PtBox Progetto di Sicurezza Informatica CDL in Ingegneria Informatica Magistrale Politecnico di Bari Studenti: Patruno Donato @email: patrunodonato@virgilio.it Trotta Gianpaolo Francesco @email: gianpaolo.trotta@gmail.com Dettagli I.T.I.S. E. MAJORANA MARTINA FRANCA(TA)
I.T.I.S. E. MAJORANA MARTINA FRANCA(TA) ----------------------------------------------------------------- TESINA: SICUREZZA RETI MATERIA: SISTEMI DATA EMISSIONE: 20-06-2005 AUTORI: ANGELO SPALLUTO INDICE: Dettagli Tecnologie e standard di trust management e trust negotiation
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per reti mobili Tecnologie e standard di trust management e trust negotiation Anno Accademico Dettagli Progettazione e realizzazione di un middleware client-server per servizi di telerefertazione online
UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Elettronica Dipartimento di Elettronica, Intelligenza Artificiale e Telecomunicazioni Progettazione e realizzazione Dettagli Capitolo 1 - Numerazione binaria
Appunti di Elettronica Digitale Capitolo - Numerazione binaria Numerazione binaria... Addizione binaria... Sottrazione binaria... Moltiplicazione binaria... Divisione binaria... Complementazione... Numeri Dettagli La gestione della sicurezza con GNU/Linux
La gestione della sicurezza con GNU/Linux Simone Piccardi piccardi@truelite.it Revisione: 1368 Truelite Srl http://www.truelite.it info@truelite.it ii iii Sicurezza con GNU/Linux Prima edizione Copyright Dettagli Capitolo 5 - I processi, la sicurezza e i pagamenti CAPITOLO 5. Il processo di acquisto, la sicurezza e i sistemi di pagamenti
CAPITOLO 5 Il processo di acquisto, la sicurezza e i sistemi di pagamenti 5.1 Il processo di vendita on line Bisogna con realismo e convinzione riconoscere che nessun processo di vendita on line potrà Dettagli Integration of Quantum Key Distribution in the SSL/TLS handshake protocol
Università degli studi di Padova Anno accademico 2012-2013 Dipartimento di Ingegneria dell Informazione Tesi di laurea triennale in Ingegneria dell Informazione Integration of Quantum Key Distribution Dettagli Problematiche di Sicurezza di Sistemi Cloud
Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea triennale Anno Accademico 2011-2012 Relatore Ch.mo Prof. Antonio Pescapè Candidato Marco Rosario Palmieri matr. N46000128 Dedica. Dettagli Sicurezza in rete SSL
Elementi di crittografia AA. 2004/2005 Sicurezza in rete SSL Patrizio ANGELINI Alessio BROZZI Giulia MASSIMI Roberto TURCHETTI Introduzione Con il crescente sviluppo di Internet e dei servizi ad esso collegati Dettagli Progetto di gestione dell Accesso in un sistema di Identity and Access Management di Ateneo
Università degli studi di Parma Facoltà di Scienze Matematiche Fisiche Naturali Corso di Laurea in Informatica Tesi di Laurea in Reti di Calcolatori Progetto di gestione dell Accesso in un sistema di Identity Dettagli Dispositivo di firma Insieme di dispositivi hardware e software che consentono di sottoscrivere con firma digitale documenti informatici.