Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Transcript

1 Roma, 30 gennaio 2003

2 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in rete e la definizione di architetture di riferimento che le pubbliche amministrazioni potranno adottare per fornire servizi al cittadino in un processo in sintonia con il piano di e-government del governo. In uno scenario quindi di erogazione di servizi on-line paragonabile per certi aspetti agli schemi forniti dall ecommerce e alle transazioni on-line del trading bancario, l architettura dei servizi in rete deve garantire la sicurezza nella sua accezione più ampia, con particolare riguardo alla: privacy del cittadino, e quindi agli aspetti di crittografia e di integrità delle informazioni, autenticità del mittente, e quindi agli aspetti necessari a garantire che chi richiede un servizio è proprio la persona che ci si aspetta stia attivando il servizio e che questa non possa negare quanto attivato non ripudio-, autenticità dell erogatore del servizio, e quindi agli aspetti di certificazione e di autorizzazione ad erogare del server erogatore del servizio richiesto dal cittadino. Quanto di seguito esposto è uno dei possibili schemi che si possono prendere e riferimento per poter iniziare ad erogare dei servizi in rete. L architettura descritta è specifica di servizi erogati in modalità web che, al momento, è la realtà più diffusa e sicuramente la modalità più semplice da implementare. Va infine rilevato che quanto detto, in questa breve descrizione, per la CNS è valido anche per la CIE e viceversa. La CNS è una carta a microprocessore (il cui file system ha la completa compatibilità con quello del microchip della CIE) in grado di ospitare applicazioni che possono essere sviluppate anche da da terze parti 1. L architettura di riferimento della CNS è stata progettata per garantire l indipendenza delle applicazioni dai sistemi operativi delle carte e permettere la realizzazione di servizi qualificati che sfruttino al meglio le caratteristiche di versatilità e sicurezza delle carte a microprocessore. La figura seguente illustra l architettura del sistema. Le aree colorate evidenziano le funzioni software che sono fornite dal Ministero dell Interno (per la documentazione di dettaglio si veda il sito 1 Tra le applicazioni che possono essere ospitate è compresa anche la firma digitale con valore legale (ossia equivalente sotto l aspetto giuridico alla sottoscrizione autografa tradizionale). Per gli aspetti relativi a tale applicazione si rimanda ad altro documento.

3 Servizi standard Applicazioni per i servizi qualificati Appl. di emissione PKCS#11 Protezione SSL CSP API (Metacomandi) APDU specificate univocamente Resource Manager Windows Drivers PC/SC dei lettori S.O. carta #1 S.O. carta #2 S.O. carta #N La compatibilità tra i sistemi operativi è realizzata a livello di APDU (Application Protocol Data Unit). Questo significa che il produttore di ciascuna carta/sistema operativo, deve verificare il set di comandi definito appositamente per la CNS e la CIE dal Ministero dell Interno, eventualmente apportando al sistema operativo tutte le modifiche necessarie ai fini dell interoperabilità delle carte. Facendo sempre riferimento allo schema precedente, il Resource Manager di Windows viene utilizzato per consentire di prescindere rispetto alle specificità dei lettori di chip, che devono essere però equipaggiati di driver PC/SC. Da quanto sopra esposto si evince che, almeno al momento della scrittura del presente documento, non si prendono in considerazione realtà diverse da quelle Microsoft (come per esempio MAC o UNIX). Ovviamente la portabilità di questa architettura verso altri ambienti è possibile, in quanto non esistono limitazioni tecnologiche. Le API (cioè i metacomandi) rappresentano l interfaccia tra le applicazioni e la carta a microprocessore. Esse sono standard, sono pubblicate dal Ministero dell Interno e possono essere utilizzate per realizzare applicazioni che sfruttano le risorse delle carte a microprocessore, prescindendo dal tipo di carta (purché aderente alle specifiche pubblicate). Lo strato intermedio PKCS#11 (o in ambiente Microsoft il CSP) può essere utilizzato dagli attuali browser per funzioni native di sicurezza che sfruttano il protocollo SSL V3, supportato in modo nativo dai più diffusi prodotti commerciali. Nei paragrafi che seguono saranno illustrate le modalità con cui è possibile realizzare funzioni di sicurezza con tale architettura. Uno dei modi più semplice per utilizzare la CNS la CIE in condizioni di sicurezza è quella di sviluppare applicazioni in architettura web e quindi sfruttare le funzioni che browser di larga diffusione (Internet Explorer, Netscape, Mozilla, ecc.) rendono disponibili. In particolare è possibile utilizzare in modo semplice, senza la necessità di sviluppare software aggiuntivo ma limitandosi ad operazioni di configurazione, le funzionalità del protocollo SSL.

4 SSL è sostanzialmente una libreria di programmi che consentono di realizzare un canale di comunicazione che gode delle seguenti caratteristiche: riservatezza del contenuto dei messaggi, integrità dei messaggi, mutua autenticazione delle parti coinvolte. Tali caratteristiche, valide qualunque sia la rete di comunicazione utilizzata, vengono ottenute con i seguenti procedimenti: la mutua autenticazione tra server e client, basata sull utilizzo di una coppia di chiavi asimmetriche; la crittografia dei dati trasmessi (che è di tipo simmetrico); l'integrità dei messaggi utilizzando funzioni di hash con chiave. Per l autenticazione delle parti, SSL prevede l uso di certificati digitali del tipo X509v3 (come quello presente all interno della CNS o CIE). Il grosso vantaggio offerto da SSL risiede nel fatto che web browser e web server sono già predisposti, se opportunamente configurati, per garantire i livelli di sicurezza sopra descritti. L utilizzo del protocollo SSL considerando la sua implementazione sui maggiori server commerciali, richiede che, sia sul server che sul client, siano presenti una coppia di chiavi asimmetriche e che su entrambi in fase di apertura di sessione sia possibile ottenere il certificato della controparte. Ovviamente, nel caso specifico le informazioni relative al client sono contenute nella smart card della CIE/CNS. Nello scenario dell erogazione dei servizi in rete al cittadino deve essere assicurato che chi sta erogando il servizio richiesto sia proprio la pubblica amministrazione competente e responsabile del servizio da erogare. Ciò significa che ogni server della pubblica amministrazione abilitato ad erogare un servizio deve essere certificato. Esistono tre possibilità: i siti vengono autenticati da una struttura governativa (Es. SSCE); i siti vengono autenticati dai certificatori accreditati per la firma digitale; i siti vengono autenticati da soggetti autorizzati generici. Nel primo caso va definita e costruita una struttura ad hoc presso un qualche settore governativo; inoltre c è il rischio che la centralità di questo servizio non sia gradita agli enti locali. Nel secondo caso bisogna garantire un livello di fiducia adeguato ai certificati che queste strutture utilizzano per la loro attività. Il modello che appare adeguato, perché poco invasivo e già sperimentato per la firma digitale è quello dell elenco pubblico dei certificatori di autenticazione. La catena di fiducia rimane sotto il controllo centrale (è indispensabile) mediante la firma digitale di tale elenco che può essere effettuata dal Ministero dell Interno.

5 Lo stesso discorso appena fatto vale per l ipotesi tre, anche se in questo caso bisognerebbe discriminare sui servizi offerti. Non dovrebbe certificare un soggetto generico se sono offerti servizi di pagamento o comunque servizi ad elevato rischio informatico dal punto di vista dell analisi del rischio effettuata. Esistono soluzioni alternative ma come variazione di dettaglio di quelle presentate. Deve essere risolto il problema delle liste di revoca. Se operano i certificatori, non è efficiente far gestire ai web server le oltre dieci CRL/CSL. E invece sicuramente possibile utilizzare un server, ad esempio di tipo OCSP, che garantisce informazioni applicative sullo stato della revoca e si alimenta per proprio conto con i dati dei certificatori. Anche in questo esistono soluzioni analoghe ma comunque basate su un server (logicamente) centrale. Se si dispone della CNS (o della CIE), il client potrà utilizzare la coppia di chiavi contenute nella carta a microprocessore con le modalità che saranno illustrate di seguito 2. Nel sistema operativo Windows, le funzioni di crittografia sono gestite dal modulo CSP (Cryptographic Service Provider). Quando le chiavi di cifratura sono memorizzate su smart card, il CSP deve essere in grado di interagire con quest ultima. Il Ministero dell Interno rende disponibile il modulo CSP (CIE_CSP) che può essere installato in sostituzione del modulo di default di Windows, garantendo così l interazione con qualunque carta a microprocessore aderente alle specifiche della CNS. Con questa soluzione il browser Explorer può utilizzare le funzioni di sicurezza della CNS in modalità nativa. Naturalmente il modulo CIE_CSP deve essere opportunamente installato sul sistema client. Per queste operazioni è possibile fare riferimento alla manualistica presente sul sito Sullo stesso sito è anche riportato il manuale utente per l attivazione della protezione SSL (CIE_CSP Guida Utente) 3. Il browser Netscape non utilizza le funzioni del CSP ma interagisce con le librerie della smart card con modalità PKCS #11. In questo caso occorre installare sul client il modulo fornito CIE_PKCS11 fornito dal Ministero dell interno. Si tratta di un implementazione dello standard PKCS #11, versione 2.01 (detto anche «Cryptoki»). 2 3 Per queste funzioni viene utilizzata la coppia di chiavi, presente sulla smart card, che identifica univocamente la CNS o CIE. Le operazioni crittografiche avvengono all interno della smart card, in modo che la chiave segreta non possa essere in alcun modo estratta. Questa coppia di chiavi non può essere utilizzata per operazioni di firma digitale in quanto NON aderenti alla normativa vigente (per la firma digitale si veda la documentazione specifica). Le modalità operative per l installazione e l utilizzo delle funzioni SSL dipendono anche dalle caratteristiche del browser e quindi possono variare in funzione della versione utilizzata. Sulla documentazione pubblicata nel sito è riportata la modalità operativa relativa alla versione più recente.

6 Anche in questo caso il modulo CIE_PKCS11 deve essere installato sul sistema client. Per questa operazione e per le modalità d uso è possibile fare riferimento alla manualistica presente sul sito Il responsabile dell erogazione del servizio dovrà invece provvedere alla generazione di una coppia di chiavi sul web server, nonchè alla pubblicazione della chiave pubblica utilizzando un certificato formato X.509 v.3 4. Dovrà inoltre provvedere ad inserire il certificato utente, reperibile dalla CNS, nell elenco dei certificati abilitati ad usufruire del servizio. Il web server dovrà inoltre essere configurato in modo da gestire la lista dei certificati revocati (CRL) 5. Sia che si utilizzi Explorer, che Netscape, è necessario che sul browser sia presente il certificato che contiene la chiave pubblica del server. Ciò può ottenersi nei seguenti modi: il certificato viene preinstallato sul browser (ad esempio con un opportuno kit di installazione); il certificato viene scaricato ed installato sul browser al momento del primo utilizzo della funzione protetta (in tal caso uno specifico messaggio chiederà all utente se intende utilizzare ed installare il certificato); il certificato del server è firmato da una certification authority il cui certificato è presente per default sul browser, in tal caso non è necessaria alcuna installazione. Ovviamente l ultima soluzione è quella più semplice sotto l aspetto operativo, ma richiede che si utilizzino i servizi di una certification authority appartenente ad una ristretta rosa di società i cui certificati sono inseriti «all origine» nei browser. La soluzione esposta ha il vantaggio di non richiedere la scrittura di software aggiuntivo, ma presenta le seguenti limitazioni: è adatta solo ad applicazioni di tipo web (ad esempio non è utilizzabile per applicazioni client server tradizionali); non permette di realizzare funzioni di sicurezza diverse da quelle standard SSL; le modalità operative sono rigidamente condizionate dai prodotti browser e web server utilizzati. In tutti quei casi in cui tali limitazioni non sono accettabili, è possibile utilizzare funzioni di sicurezza «ad hoc». In generale sono possibili due strade: 4 5 Ciò può essere fatto sfruttando le caratteristiche del web server oppure ricorrendo ai servizi di un certificatore. Nel caso di ricorso a certificati acquisiti da terzi, occorre fare ricorso a certificati che abilitino la crittografia simmetrica con chiavi lunghe 128 bit. La verifica della validità del certificato mediante accesso alla CRL è gestita in modo differente dai web server. Ad esempio Apache verifica automaticamente l assenza del certificato dalla lista nera (CRL) mentre in altri web server tale funzione deve essere attivata dal programma.

7 l impiego di funzioni di sicurezza proprie dell ambiente client Windows (ad esempio le funzioni del CIE_CSP utilizzabili con le CryptoApi o l interfaccia standard PKCS11), l interazione con il middleware che gestisce la smart card attraverso i Metacomandi. Tra le due possibilità deve essere preferita la seconda, in quanto consente l interazione con l ambiente di sicurezza attraverso una modalità standard indipendente dallo specifico ambiente software. Utilizzando i Metacomandi è infatti possibile combinare le funzioni di sicurezza in modo semplice ed integrato con le altre funzioni applicative.