UNIVERSITÀ DEGLI STUDI DI TRIESTE____________________

FACOLTÀ DI INGEGNERIA

Laurea in Ingegneria Informatica

SPERIMENTAZIONE DELLA CARTA REGIONALE DEI SERVIZI PER 

L'AUTENTICAZIONE SU UN DOMINIO ACTIVE DIRECTORY

Relatore: Laureando:Prof. Fulvio Sbroiavacca Andrea Ramani

____________________

Anno Accademico 2009-2010

Indice

1 Introduzione..............................................................................................11.1 Progetto Carta Regionale dei Servizi (Friuli Venezia Giulia).............1

1.1.1 Cos'è la CRS...................................................................................11.1.2 Come nasce la CRS.......................................................................1

1.2 Obiettivo ...............................................................................................22 LDAP – Active Directory (Microsoft)...................................................3

2.1 Active Directory....................................................................................32.1.1 LDAP.............................................................................................32.1.2 Perché usare Active Directory......................................................42.1.3 Single­Sign On..............................................................................42.1.4 Riassumendo: concetti chiave di Active Directory.......................5

2.2 Autenticazione......................................................................................52.2.1 Complessità, non ripudiabilità, identificazione e autorizzazione................................................................................................................62.2.2 Fattori di autenticazione..............................................................62.2.3 Metodi di autenticazione..............................................................72.2.4 Fattori di scelta.............................................................................82.2.5 Vulnerabilità.................................................................................9

2.3 Utenti di Active Directory..................................................................102.3.1 Primary Domain Controller........................................................10

3 Autenticazione con Smart Card su dominio Active Directory.....113.1 Smart Card.........................................................................................11

3.1.1 Utilizzi.........................................................................................123.1.2 Struttura e caratteristiche .........................................................123.1.3 Classificazione.............................................................................133.1.4 Memory Card...............................................................................143.1.5 Microprocessor Smart Card........................................................153.1.6 Modalità di lettura......................................................................15

3.2 Integrazione client­server attraverso la Smart  Card.......................16

i

3.2.1 Smart Card Subsystem...............................................................163.2.2 Smart Card Setup Tool...............................................................173.2.3 Metodologie di connessione.........................................................173.2.4 Interfaccia Smart Card...............................................................183.2.5 Resource Manager.......................................................................18

3.3 Identificare l'utente............................................................................193.3.1 Tipi di autenticazione.................................................................203.3.2 Autenticazione ad un dominio Windows....................................20

4 La Carta Regionale dei Servizi...........................................................224.1 La Carta Nazionale dei Servizi..........................................................22

4.1.1 Gli standard CNS........................................................................224.2 La Carta Regionale dei Servizi .........................................................26

4.2.1 Finalità........................................................................................264.2.2 Struttura e caratteristiche.........................................................27

4.3 I certificati digitali.............................................................................284.3.1 I certificati nella CRS.................................................................28

4.4 Autenticazione sul Web......................................................................305 Autenticazione con CRS su Active Directory...................................31

5.1 Specificità dei certificati CRS............................................................315.1.1 L'estensione Extensions..............................................................34

5.2 I problemi............................................................................................345.3 La soluzione .......................................................................................355.4 Casi d'uso............................................................................................36

6 Transitività dell'autenticazione: da dominio a Web.......................386.1 Avvicinandosi al problema.................................................................38

6.1.1 Strumenti....................................................................................396.1.2 Prerequisiti..................................................................................396.1.3 Passaggi concettuali....................................................................40

6.2 Funzionamento dell'applicazione.......................................................406.3 Sviluppo dell'applicazione..................................................................41

6.3.1 web.config....................................................................................416.3.2 Default.aspx.cs............................................................................426.3.3 Possibili comportamenti.............................................................45

7 Conclusioni..............................................................................................478 Ringraziamenti.......................................................................................50Bibliografia.................................................................................................51

ii

1 Introduzione

1.1 Progetto   Carta   Regionale   dei   Servizi  (Friuli Venezia Giulia)

La Carta Regionale dei Servizi (CRS) è un progetto la cui finalità è quella di realizzare e distribuire ai cittadini un unico strumento per l'accesso ai pubblici servizi sia regionali che nazionali.

1.1.1 Cos'è la CRS

La Carta Regionale dei Servizi è una carta strettamente personale, valida come tessera sanitaria, tessera Europea di Assicurazione malattia e Codice Fiscale.

Con essa è, inoltre, possibile usufruire di alcuni servizi digitali offerti dalla pubblica amministrazione regionale attraverso Internet. Questi servizi riguardano principalmente la Sanità, gli Enti Locali, la scuola, la fiscalità locale e la mobilità.

1.1.2 Come nasce la CRS

Nel 2004 la Regione Friuli Venezia Giulia firmava con il ministero dell'Economia e Finanze l'Accordo di Programma Quadro. In tale accordo figurava anche il progetto SMART, intervento che prevedeva l'avvio sperimentale della nuova Carta Regionale dei Servizi.

Agganciandosi a tale progetto, per evitare duplicazioni di strumenti con le medesime potenziali finalità, il Presidente della Regione, d'intesa con l'Agenzia delle Entrate del Friuli Venezia Giulia, propose un adeguamento agli standard CNS della tessera sanitaria. In questo modo, invece di avere

1

due tessere indipendenti, la CRS e la tessera sanitaria, era possibile mettere a disposizione del cittadino un'unica soluzione che svolgesse entrambi i ruoli.

In seguito a tale proposta, e con l'accordo di Regione, ministero dell'Economia e Finanze, Istituto Poligrafico e Zecca dello Stato, si riuscì ad ideare un unico strumento per l'accesso a pubblici servizi sia regionali che nazionali: la Carta Regionale dei Servizi.

La realizzazione del progetto è stata possibile grazie alla cooperazione congiunta del servizio per l'E-government della Regione, l'Agenzia regionale della Sanità e Insiel.

1.2 Obiettivo

L'obiettivo del mio progetto, svolto presso l'Insiel, è quello di studiare l'autenticazione tramite la CRS su di un dominio Active Directory e di trasporla anche nell'ambito del Web. L'intento finale è quello di creare un'applicazione Web che permetta di autenticarsi su un server, sfruttando il meccanismo di Single-Sign On, tramite il certificato digitale presente nella Carta Regionale dei Servizi.

2

2 LDAP – Active Directory (Microsoft)

2.1 Active Directory

Active Directory, nome utilizzato da Microsoft per riferirsi all'implementazione della sicurezza in una rete distribuita di computer, è un insieme di servizi di rete, meglio noto come directory service, che si basa sui concetti di dominio e di directory. Il directory service di Active Directory fornisce uno strato di astrazione fra le risorse e gli utenti: organizza e memorizza informazioni su reti di computer e su risorse condivise, disponibili tramite la rete, facilitando così, notevolmente, il lavoro di monitoraggio dell'amministratore del sistema. Tale organizzazione avviene grazie ad uno dei protocolli utilizzati da Active Directory: il LDAP.

2.1.1 LDAP

LDAP (Lightweight Directory Access Protocol) è un protocollo applicativo standard per l'interrogazione e la modifica dei servizi di directory che agisce nello strato appena superiore ai protocolli TCP ed IP; viene implementato in network di tipo IP (Internet Protocol) e si basa sul modello client-server: la sua funzione principale è quella di abilitare l'accesso ad una directory pre-esistente.

Nello specifico, in Active Directory, LDAP viene usato come una base di dati che memorizza in forma centralizzata tutte le informazioni di un dominio di rete, relativamente ad autenticazioni ed accesso ai servizi. Il vantaggio più evidente del suo utilizzo è quello di riuscire a mantenere tali informazioni sincronizzate tra i vari server di autenticazione di accesso alla rete.

3

2.1.2 Perché usare Active Directory

Le reti, cui Active Directory ha accesso, possono variare da una singola installazione, con poche centinaia di oggetti, a grandi installazioni, con milioni di oggetti. Una struttura Active Directory si può definire, dunque, come un framework gerarchico di oggetti: include, infatti, in un unico sistema di monitoraggio, tutte le risorse (stampanti, etc...), tutti i servizi (e-mail, etc...) e tutti gli utenti (account utenti e gruppi). In una rete, quindi, Active Directory fornisce informazioni sugli oggetti, li organizza, controlla gli accessi e ne imposta le security, garantendo così che l'accesso ad ogni risorsa possa venire effettuato solo dagli utenti che ne hanno effettivamente il diritto.

Inoltre, una delle peculiarità più evidenti ed importanti che rende l'utilizzo dei servizi di rete di Active Directory particolarmente vantaggioso, è il meccanismo di Single-Sign On.

2.1.3 Single­Sign On

Tramite il Single-Sign On un utente, una volta entrato nel dominio ed effettuato il logon ad esso da una qualsiasi delle macchine di dominio, può accedere alle risorse disponibili in rete (condivisioni, mailbox, intranet, etc...) senza dover rieffettuare, fino alla fine della sessione, una nuova autenticazione. Questa politica facilita di molto la gestione degli utenti. Gli obiettivi sono multipli:

• Semplificare la gestione delle password (più grande è il numero delle password che un utente deve gestire, maggiore è la possibilità che, per facilitarne la memorizzazione, utilizzi delle password simili le une alle altre; il livello di sicurezza, in questo modo, si abbassa notevolmente)

• Semplificare la gestione degli accessi ai vari servizi

• Semplificare la definizione e la gestione delle politiche di sicurezza

Quando si parla di Single-Sign On, esistono tre diversi approcci possibili attraverso i quali è possibile creare un sistema che si basa sul meccanismo di autenticazione appena descritto: l'approccio centralizzato, l'approccio federativo e l'approccio cooperativo.

1. Approccio centralizzato

Il principio è di disporre di un database globale e centralizzato di tutti gli utenti e di centralizzare allo stesso modo la politica di sicurezza. Questo approccio è destinato principalmente ai servizi

4

che dipendono tutti dalla stessa entità (per esempio all'interno di un'azienda).

2. Approccio federativo

Con questo approccio, differenti gestori ("federati" tra loro) gestiscono dati di uno stesso utente. L'accesso ad uno dei sistemi federati permette automaticamente l'accesso a tutti gli altri sistemi. Questo approccio è stato sviluppato per rispondere ad un bisogno di gestione decentralizzata degli utenti: ogni gestore federato mantiene il controllo della propria politica di sicurezza.

3. Approccio cooperativo

L'approccio cooperativo parte dal principio che ciascun utente dipenda, per ciascun servizio, da uno solo dei gestori cooperanti. In questa maniera ciascun gestore gestisce in modo indipendente la propria politica di sicurezza. L'approccio cooperativo risponde ai bisogni di strutture istituzionali nelle quali gli utenti sono dipendenti da un'entità (università, laboratori di ricerca, amministrazioni, etc...).

2.1.4 Riassumendo: concetti chiave di Active Directory

In conclusione, si può dire che Active Directory si basa su tre concetti chiave: LDAP (gestione), le reti (condivisibilità) e Single-Sign On (sicurezza). Inoltre, fra le altre caratteristiche vi è piena integrazione fra Active Directory e DNS in quanto, entrambi, condividono la stessa struttura gerarchica e, quindi, gli stessi nomi.

2.2 Autenticazione

Col termine autenticazione si indica, nel caso più frequente, un metodo attraverso il quale si prova l'identità di qualcuno, allo scopo di consentirne l'accesso a risorse di qualsiasi genere. Le tecniche di autenticazione sono estremamente differenziate, sia come metodo che come efficacia, in funzione di diversi fattori. In termini semplici, si può dire che una tecnica di autenticazione è efficace quando garantisce, con ottima probabilità, che il richiedente l'accesso sia effettivamente il titolare del diritto. Uno dei concetti fondamentali che si fanno strada quando si parla di autenticazione è la complessità della tecnica di autenticazione.

5

2.2.1 Complessità,   non   ripudiabilità,  identificazione   e  autorizzazione

La complessità dipende, essenzialmente, dalla criticità dell'identificazione, dai fattori che la possono limitare, e dal valore delle informazioni cui si garantisce l'accesso dopo l'operazione di autenticazione: maggiore è il valore delle informazioni, o delle risorse in generale, più complessa sarà la tecnica di autenticazione.

Con l'aumentare della complessità della tecnica di autenticazione si fa strada un altro concetto fondamentale, oltre a quello dell'identità: la non ripudiabilità. In altri termini, se la tecnica di autenticazione è sufficientemente sicura, allora, oltre a garantire l'identità di colui che accede, impedisce a chi ha effettuato l'autenticazione di poter negare di aver avuto accesso alle risorse che l'autenticazione gli garantiva. Per quanto la tecnica di autenticazione possa essere complessa, nessun sistema di autenticazione può dirsi realmente efficace se non con la stretta collaborazione dell'utente: è a cura dell'utente stesso ricordarsi l'eventuale password, conservare la Smart Card o i dispositivi di memorizzazione e non comunicare ad altri gli estremi del proprio sistema di autenticazione, etc...

L'autenticazione non va confusa con l'identificazione che determina se un utente è conosciuto o meno dal sistema, o con l'autorizzazione con cui si conferisce all'utente il diritto di accedere a specifiche risorse o a servizi.

2.2.2 Fattori di autenticazione

Un buon processo di autenticazione ricorre, normalmente, ai seguenti tre fattori chiave:

1. Qualcosa che solo l'utente conosce

Ad esempio, il cognome della nonna da nubile o una parola chiave.

2. Qualcosa che solo l'utente possiede

Ad esempio, una tessera di riconoscimento o una scheda magnetica o una chiave hardware.

3. Qualcosa che solo l'utente è

Ad esempio, un aspetto fisiologico o comportamentale; si parla, in questo caso, di biometria.

6

2.2.3 Metodi di autenticazione

Da un punto di vista squisitamente pratico, i metodi maggiormente utilizzati per l'autenticazione in ambito informatico si possono sintetizzare nei tre seguenti:

1. Username e password statiche o dinamiche

L'utilizzo di username e password statiche, ossia che non vengono modificate in tempo reale durante il processo di autenticazione, è quello più diffuso ed è sostanzialmente il più semplice da implementare. In questo caso, l'utente deve ricordare il proprio username e la password ad esso associato (che, ovviamente, sono anche memorizzate sul sistema di accesso). Tale metodo, se non è associato ad altri meccanismi, può risultare piuttosto debole in quanto si presta a diversi tipi di attacchi. Attacchi che però possono essere ridotti in misura considerevole utilizzando una password sicura (lunghezza estesa ed utilizzo di caratteri speciali oltre a quelli alfanumerici) e modificandola periodicamente. C'è anche da sottolineare che, con le opportune precauzioni e unitamente al tracciamento del computer dal quale ci si autentica, il metodo basato su password statiche è sufficiente per un gran numero di casi pratici, a meno di non pretendere la validità legale inoppugnabile per l'intero processo di autenticazione. In questo caso può essere necessario ricorrere a sistemi che, pur basandosi su metodi statici, coinvolgano un certificato digitale conforme all'attuale normativa (documento elettronico che attesta, con una firma digitale, l'associazione tra una chiave pubblica e l'identità di un soggetto).

2. Dispositivi di memorizzazione di chiavi o certificati

Le password dinamiche, invece, sono generate automaticamente mediante sistemi automatici: la generazione avviene soltanto all'occorrenza. Inoltre, la validità di tali “password” è estremamente limitata nel tempo. Non è, in senso stretto, un sistema di autenticazione rivolto all'individuo, ma può essere utilizzato congiuntamente al sistema delle password statiche per realizzare sistemi estremamente robusti di autenticazione e di trasmissione.

3. Dispositivi biometrici

In questa categoria rientrano i meccanismi di autenticazione basati su sistemi fisici, come le Smart Card, le carte magnetiche, le chiavi di memoria, etc... Su tali dispositivi è memorizzato un certificato digitale che garantisce, unitamente a una password statica, l'identificazione del possessore (il meccanismo, se si vuole, è analogo a quello del bancomat ma molto più robusto in quanto il PIN, ossia

7

la password statica, può essere modificato dal possessore e, inoltre, può essere associato ad un certificato per altri scopi, tra cui la crittografica del canale di comunicazione). Si tratta, però, di un sistema più costoso e che richiede il possesso costante di un dispositivo fisico che, in caso di smarrimento, deve essere rigenerato provocando l'interruzione del servizio per un periodo di tempo non sempre accettabile.

In questa categoria rientrano i dispositivi di riconoscimento automatico della persona sulla base di alcune caratteristiche fisiche, come le impronte digitali, l'impronta retinica o quella vocale, etc... Sono nati per garantire il massimo livello di sicurezza nell'autenticazione individuale, a partire da caratteristiche singolari della persona fisica. Purtroppo, i sistemi di riconoscimento sono soggetti ad errori statistici che non possono essere eliminati. Inoltre, le caratteristiche fisiche possono essere imitate in qualche modo. Ad ogni modo, allo stato attuale, tali sistemi hanno senso solo in situazioni di alta richiesta di sicurezza nell'identificazione della persona fisica “a vista” e sono sempre associati a sistemi ulteriori di controllo e di emergenza. Sono assolutamente da scartare in caso di autenticazione remota, non assistita, e implicano un costo notevole per la loro implementazione.

2.2.4 Fattori di scelta

Per poter scegliere quale tipologia di dispositivo di autenticazione utilizzare bisogna tener conto, fondamentalmente, di alcuni aspetti: accuratezza, costi, invasività, identificazione o verifica.

1. Accuratezza

Un sistema viene ritenuto tanto più accurato quanto maggiormente garantisce l'efficienza nell'autenticazione. Ad esempio, mentre un sistema basato su password testuali fornisce il massimo di accuratezza nell'autenticazione (se si fornisce la password esatta) un sistema biometrico può essere, a causa di problemi del sensore o di uno stato di “alterazione” biometrica dell'utente, meno accurato.

2. Costi

Maggiore è l'affidabilità e la precisione del sistema, maggiori sono i costi necessari per l'acquisto dei dispositivi di autenticazione. Inoltre, per quelle specifiche applicazioni nelle quali non è possibile far ricorso a dispositivi di grandi dimensioni, tanto maggiore è la miniaturizzazione del dispositivo, tanto più onerosi saranno i costi per l'acquisto del dispositivo stesso. Quindi, è importante valutare

8

un buon compromesso tra affidabilità e prestazioni del sistema, alla luce dei costi delle diverse soluzioni.

3. Invasività

Si parla di invasività solo ed esclusivamente nell'ambito dell'autenticazione mediante parametri biometrici. Infatti, la lettura di parametri biometrici da parte di una macchina richiede all'utente che si vuole autenticare comportamenti che possono essere considerati invasivi. La scansione oculare o il riconoscimento mediante impronta digitale implicano il trattamento di dati che possono essere considerati sensibili: in questo caso, si rischia, addirittura, di andare a violare la Privacy dell'individuo (ad esempio, difficilmente i clienti di una banca accetterebbero un sistema di bancomat che richieda loro di avvicinare un occhio ad uno scanner di retina o di iride. Un bancomat di questo tipo difficilmente potrebbe avere successo).

4. Identificazione o verifica

Sono due meccanismi di controllo che vengono usati durante il processo di autenticazione.

• L'identificazione è un processo di tipo “uno-a-molti”: confronta i dati dell'autenticazione (siano essi una password o un'impronta biometrica) con moltissimi altri presenti in un database, al fine di stabilire un'identità

• La verifica è un processo di tipo “uno-a-uno”: confronta i dati di autenticazione con i dati che sono memorizzati, per esempio, su una Smart Card. Questo processo è molto più veloce, dato che non serve fare ricerche complesse su una base di dati

2.2.5 Vulnerabilità

Tutti i sistemi hanno un certo livello di vulnerabilità: le password, le immagini delle impronte digitali e tutti gli altri dati che viaggiano su una rete possono essere intercettati e, come tali, copiati, alterati e, in una parola, violati. Inoltre è possibile “attaccare” un sistema con vari metodi, al fine di scoprire le password in esso memorizzate. C'è, poi, il rischio dell'accesso fisico alle macchine: occorre sempre considerare il caso che l'accesso fisico da parte di terzi alla propria macchina o, peggio, al server di autenticazione, possa inficiare l'intera infrastruttura.

9

2.3 Utenti di Active Directory

In una rete di computer si hanno due fondamentali possibilità di operare:

1. In gruppo di lavoro

Ogni computer ha la stessa importanza e gli utenti eseguono un logon locale potendo, così, condividere risorse e cartelle.

2. In dominio di rete

In questa configurazione c'è almeno un computer, denominato server, che svolge attività speciali.

Mentre in un gruppo di lavoro non esistono vere e proprie distinzioni fra le varie persone che utilizzano i PC della rete e si possono considerare, quindi, tutti degli utenti di pari livello, in un dominio di rete, un suo utente è solo chi è abilitato ad accedere ai servizi del dominio stesso. Il compito di gestire gli utenti di un dominio è del PDC.

2.3.1 Primary Domain Controller

Il PDC (Primary Domain Controller) è un server che ha il particolare onere di attribuire gli accessi al dominio. Ogni utente appartenente ad un certo dominio, può accedere ad un qualunque PC della rete (nella propria azienda), svolgere il proprio lavoro e salvarlo in locale sulla macchina su cui sta lavorando. Ora l'utente, sia che il PC a cui si collegherà la prossima volta sia sempre lo stesso, sia che ne usi uno diverso (appartenente sempre alla medesima rete aziendale) avrà la possibilità, attraverso l'autenticazione al suo dominio, di poter accedere ai propri dati salvati e riuscire, così, a continuare l'attività iniziata nella sessione precedente. L'idea, quindi, è quella di poter usufruire di un dominio di rete per avere accesso univoco e protetto verso le risorse. In questa situazione il PDC gestisce gli accessi determinando le autorizzazioni per operare in rete.

Nello specifico, in una rete aziendale, Active Directory si pone l'obiettivo di memorizzare le informazioni di autorizzazione e autenticazione richieste per assicurare che solo gli utenti appropriati accedano alle risorse di rete.

10

3 Autenticazione  con Smart Card su  dominio Active Directory

3.1 Smart Card

La Smart Card è un dispositivo hardware delle dimensioni di una carta di credito, che possiede potenzialità di elaborazione e memorizzazione dati ad alta sicurezza. É un'evoluzione della tradizionale carta magnetica ed è costituita da un supporto di plastica nel quale è incastonato un microchip, o Circuito Integrato (IC). Quest'ultimo fornisce funzionalità di calcolo e memorizzazione dati maggiori rispetto a quelli permessi dalla tecnologia magnetica e può essere sia una semplice memoria sia un microprocessore.

Figura 3.1: Struttura fisica di una Smart Card

11

3.1.1 Utilizzi

Le Smart Card rendono più convenienti e sicure moltissime operazioni: offrono sicurezza nei sistemi a scambio virtuale di dati, sia da una parte che dall’altra della rete; proteggono da una serie di minacce per la sicurezza (dall’incauta memorizzazione di password utenti all'uso di sistemi sofisticati di attacco); possono servire come accesso al sistema di rete, a depositi bancari o ad altri tipi di dati. Generalmente, quindi, gli standard di sicurezza ed affidabilità dei microchip offrono la possibilità di utilizzare le Smart Card in una grande varietà di campi, quali ad esempio:

• Affidabilità e salvataggio valori

• Informazioni di sicurezza

• Commercio elettronico

• Economia personale

• Assistenza sanitaria

• Telecomunicazione e sicurezza sociale su rete

• Identificativi e accesso all’Università

3.1.2 Struttura e caratteristiche 

I microchip che si trovano sulle Smart Card possono essere molto diversi fra loro e, sebbene la struttura sia solitamente la stessa, le loro prestazioni possono variare considerevolmente; tutto dipende dall'utilizzo della Smart Card e dal lavoro che essa è chiamata ad adempiere (ad esempio, è inutile che si usino Smart Card con una memoria RAM capiente o con una CPU se il loro utilizzo resta, poi, limitato a quello di schede telefoniche). Normalmente, la struttura e la composizione di una Smart Card è di questo tipo:

1. Parte plastica

Tipicamente resistente, elastica ed economica; fatta di PVC, ABS, Melinex.

2. CPU

A 8, 16 o 32 bit; con clock a 5Mhz.

3. ROM (Read Only Memory)

Da 2k a 64k; contiene il sistema operativo e programmi fissi. Dopo la scrittura non è modificabile.

12

4. PROM (Programmable Read Only Memory)

A 32 o 64 byte; contiene il numero seriale della Smart Card.

5. EEPROM (Electrically Erasable Read Only Memory)

Circa 128k; memorizza informazioni variabili; tipicamente contiene le applicazioni e i dati.

6. RAM (Read Only Memory)

Da 128 a 1024 byte utilizzata per memorizzazioni temporanee; si cancella quando si sfila la Smart Card (power off).

7. Porta di I/O

Utilizzata per l'interscambio fisico delle informazioni.

3.1.3 Classificazione

Le Smart Card possono essere classificate in base a diversi criteri. Sulla base delle potenzialità e delle caratteristiche del microchip, si distinguono Smart Card a sola memoria (Memory Card) e Smart Card a microprocessore (Microprocessor Card). Invece, in base al tipo di interfaccia di collegamento, si distinguono Smart Card con Contattiera (Contact), Smart Card con antenna (Contactless Smart Card) e Smart Card con antenna e contattiera (Dual Interface Card). Le caratteristiche del microchip determinano sia il costo della Smart Card, sia l'ambito di applicazione. Le caratteristiche del supporto di plastica e dell'interfaccia di comunicazione determinano invece il ciclo di vita della Smart Card.

Figura 3.2: Struttura gerarchica, diversificazione delle Smart Card

13

3.1.4 Memory Card

Le Smart Card a sola memoria (o Memory Card) tecnologicamente più semplici, sono più economiche ma offrono un livello di sicurezza più basso rispetto alle Smart Card a microprocessore. Infatti, la Memory Card ha unicamente funzionalità di memorizzazione sicura dei dati, non ha potere di elaborazione e non può modificare dinamicamente i file. Essa comunica con i lettori attraverso protocolli sincroni. Il microchip contiene una componente di memoria permanente, nella quale si può leggere e scrivere attraverso un insieme di funzioni cablate in un circuito logico pre-programmato, stampato nel microchip durante la fase di produzione. Il circuito logico, a sua volta, comprende un meccanismo di protezione che salvaguarda l'accesso ai dati memorizzati, basandosi tipicamente su un insieme di permessi di accesso. Di solito, le Memory Card offrono da 1 a 4 Kbyte di memoria e sono usate principalmente per applicazioni semplici (carte prepagate, carte per la raccolta punti, etc... in questi casi il meccanismo di protezione consente di evitare l'incremento fraudolento del credito). I comandi per la lettura e scrittura in memoria sono tipicamente sequenze di byte incapsulate in un protocollo seriale. Il vantaggio delle Memory Card sta nel loro basso costo dovuto alla semplicità della tecnologia adottata. Tuttavia, per applicazioni più complesse, che richiedono un livello di sicurezza maggiore, si preferisce usare Smart Card a microprocessore.

Ci sono principalmente tre tipi di Memory Card:

1. Straight Memory Card

Schede che immagazzinano solo dati e non hanno capacità di elaborazione. Non possono identificarsi, per cui il nostro PC deve sapere che tipo di scheda è stata inserita nel lettore.

2. Protected / Segmented Memory Card

Hanno incorporata la logica per controllare l'accesso alla memoria della scheda stessa. Alcune di queste schede possono essere configurate per restringere l’accesso sia in lettura che in scrittura. Questo, di solito, è fatto attraverso una password o chiave di sistema.

3. Stored Value Memory Card

Queste schede sono progettate per lo specifico scopo di immagazzinare valori o scatti (telefonici). Le schede sono usa e getta o ricaricabili. La maggior parte di queste schede incorpora misure di sicurezza permanenti già al momento della loro produzione (ad esempio, una password inserita direttamente nel chip dal fabbricante).

14

3.1.5 Microprocessor Smart Card

Per quanto riguarda la Smart Card a microprocessore, grazie alla potenza di calcolo fornita dal microprocessore incluso nel microchip, essa può essere paragonata ad un piccolo computer portatile, altamente affidabile ed inattaccabile, in grado di elaborare e memorizzare informazioni, salvaguardandone la riservatezza. Questo tipo di Smart Card possiede un vero e proprio sistema operativo di scheda (COS), che la rende idonea ad elaborare informazioni in maniera indipendente. In particolare, il sistema operativo si occupa della gestione interna della memoria e fornisce varie funzioni, tra le quali: lettura e scrittura in memoria, funzioni di programmazione dei permessi di accesso, funzioni crittografiche, etc... La programmabilità del microchip, conseguente alla presenza di un sistema operativo, consente di ottimizzare e personalizzare la Smart Card per una particolare applicazione, o di integrare sullo stesso dispositivo più applicazioni (eventualmente interagenti tra loro). L'unico limite a tale flessibilità è rappresentato dalla disponibilità di risorse di memoria. Il set di comandi di una Smart Card a microprocessore è molto più vasto di quello di una Smart Card a sola memoria. Logicamente, aumentando la potenza di calcolo, lievitano anche i costi. Oltre ai comandi di lettura e scrittura, le Smart Card a microprocessore forniscono comandi di gestione dell'accesso alla memoria (ad esempio, comandi di verifica del PIN) e comandi di gestione del file system interno; tali comandi vengono chiamati APDU (Application Protocol Data Unit). Grazie alla capacità di memorizzare informazioni in maniera estremamente sicura ed inviolabile e alla possibilità di elaborare dati al suo interno, la Smart Card a microprocessore si propone, in primo luogo, come strumento informatico di identificazione sicura e certificata degli individui e, in secondo luogo, come dispositivo di elaborazione a supporto della crittografia, in grado di memorizzare e proteggere le chiavi crittografiche private e di eseguire i principali algoritmi crittografici.

3.1.6 Modalità di lettura

Possiamo distinguere due diverse modalità di lettura delle Smart Card: Contact e Contactless. La differenza sta nel tipo di interfaccia di collegamento esistente tra il microchip e il mondo esterno: le prime hanno una contattiera mediante la quale ricevono l'alimentazione e, una volta inserite in un apposito dispositivo terminale, detto lettore di Smart Card, dialogano con l'esterno; le seconde hanno un'antenna che reagisce alla presenza di un campo elettromagnetico emesso da uno speciale dispositivo di lettura/scrittura nella banda delle radio-frequenze (con tecnologia RFID), consentendo così al microchip di scambiare dati con l'esterno

15

(purché l'antenna si trovi entro una distanza minima dal dispositivo di lettura/scrittura). Le Smart Card Dual Interface, invece, offrono entrambe le interfacce (Contact e Contacless) e pertanto la comunicazione con il microchip può avvenire indifferentemente attraverso uno o l'altro metodo. Tale caratteristica consente di integrare sulla stessa Smart Card sia applicazioni complesse, come quelle di firma digitale tipiche delle Smart Card contact, sia applicazioni più semplici e veloci, come quelle di controllo dell'accesso ad aree riservate, che richiedono esclusivamente accessi alla memoria wireless.

3.2 Integrazione   client­server  attraverso  la  Smart  Card

Per poter utilizzare una Smart Card, e, quindi, rendere attiva l'integrazione client-server tramite Smart Card, è necessario possedere un lettore: un'unità hardware che, per funzionare, deve essere collegata e configurata direttamente con un PC. I lettori di Smart Card vengono controllati mediante i driver e sono inseriti e rimossi dal sistema attraverso il meccanismo di “Plug and Play”, o tramite l'utilizzo del Pannello di Controllo. Una volta collegato il lettore al PC, un driver di periferica specifico associa le funzionalità del lettore ai servizi da esso offerti. Così, essi diventano fruibili all'utente, grazie all'integrazione che si crea fra il sistema operativo Windows e l'infrastruttura della Smart Card: il driver del lettore comunica l'inserimento e la rimozione della Smart Card al gestore di risorse e, quindi, rende disponibili le funzioni di comunicazione delle informazioni da e verso la Smart Card stessa.

3.2.1 Smart Card Subsystem

Una volta che il lettore di Smart Card è stato collegato al PC e riconosciuto dal sistema operativo, entra in gioco lo Smart Card Subsystem: il suo compito è quello di provvedere alla creazione di un collegamento tra il lettore e le applicazioni che lo utilizzano (lo Smart Card Subsystem può funzionare solamente se il lettore è già stato preventivamente riconosciuto). A seconda della tipologia del dispositivo e del tipo di servizi offerti, i lettori di Smart Card possono essere suddivisi in categorie, o gruppi logici, chiamati Reader Groups. Questi gruppi possono essere definiti di default dal Smart Card Subsystem, oppure, allo stesso modo, venire scelti sia dagli amministratori che dagli utenti del sistema. A questo punto il sistema operativo è pronto e resta in attesa dell'inserimento della Smart Card nel lettore. Avvenuto ciò, la procedura di

16

riconoscimento fra la card ed il sistema avviene, di solito, attraverso uno Smart Card Setup Tool, fornito dal produttore del lettore.

3.2.2 Smart Card Setup Tool

Il Setup Tool deve fornire le seguenti informazioni sulla card:

• La sua ATR String (una sequenza di byte ritornata dalla Smart Card quando viene accesa. Questi byte vengono usati per far identificare la card nel sistema)

• Una lista di Smart Card interface supportate dalla card (COM, etc...)

• Un nome per la card, utile per far identificare la card all'utente (altresì, l'utente può utilizzare per il riconoscimento direttamente il Setup Tool)

• Il primary service provider associato alla card (opzionale), usato per poter accedere alla card direttamente attraverso l'interfaccia (COM, etc...)

3.2.3 Metodologie di connessione

Una volta identificata la card, lo Smart Card Subsystem utilizza diversi metodi per connettersi ad essa. Principalmente, ciò avviene attraverso l'uso di un'applicazione o di un service provider:

• Un'applicazione può usare SCardConnect per connettersi ad una card presente in un lettore specificato (la funzione SCardConnect stabilisce una connessione, usando uno specifico Resource Manager Context, fra l'applicazione chiamante e una Smart Card contenuta in uno specifico lettore. Se non trova nessuna card viene restituito un errore). Questo è il metodo più semplice per stabilire una comunicazione con una Smart Card

• Un'applicazione può ricercare una specifica Smart Card dentro ad un determinato insieme di lettori. L'applicazione identifica la card dal suo nome, e specifica una lista di lettori nei quali si potrebbe trovare. Il Resource Manager ricerca la lista di lettori per ciascuna card attraverso una ATR String che corrisponda al suo nome, e trasferisce l'informazione all'applicazione. Lo Smart Card Subsystem non visualizza mai un'interfaccia nè interagisce con la card prima di aver ottenuto la ATR string

17

• Un'applicazione può richiedere una lista di card che abbiano le specifiche tecniche adatte a supportare un determinato insieme di interfacce. Successivamente, l'applicazione può usare la lista di lettori del caso precedente. Questo permette all'applicazione di connettersi alle card in base alle loro capacità, senza considerare i loro nomi

3.2.4 Interfaccia Smart Card

Una volta che la Smart Card è connessa e viene riconosciuta dal sistema, si presenta all'utente un'apposita interfaccia; l'interfaccia Smart Card è composta da un predefinito insieme di servizi fruibili direttamente dall'utente (prestabiliti a priori dall'azienda emettitrice e già disponibili dentro la Smart Card stessa), dai protocolli necessari per invocare i servizi e da qualunque oggetto riguardante il contesto e il funzionamento dei servizi stessi. Ciascuna interfaccia di Smart Card è identificata da un GUID (Globally Unique Identifier, identificatore unico globale), un numero pseudo-casuale usato per poter distinguere i vari oggetti che la compongono. Utilizzando un determinato identificatore GUID un'applicazione può ricercare, quindi, una particolare interfaccia (combinazione interfaccia grafica, protocolli, servizi - sempre se compatibile con la Smart Card in questione). La sua implementazione, però, potrebbe variare a seconda della Smart Card utilizzata: ogni GUID, in base alla card che si sta utilizzando, può avere diversi tipi di implementazione; essi, però, non influiscono in alcun modo sull'interazione fra l'applicazone e la Smart Card. L'insieme di interfacce supportate da una certa Smart Card viene definito dal sistema dopo aver inserito la stessa nell'apposito lettore (ad esempio, se una Smart Card ha come primary service provider un'interfaccia di tipo COM, i servizi della carta stessa diventano fruibili in una grande varietà di ambienti di programmazione, inclusi Java e l'ambiente di sviluppo Microsoft Visual Basic).

3.2.5 Resource Manager

Dopo che è stata scelta l'interfaccia, i servizi offerti dalla Smart Card vengono resi disponibili al sistema tramite il gestore di risorse, o Resource Manager, della Smart Card; il gestore viene riconosciuto dal sistema operativo e, poi, viene eseguito come servizio attendibile (trusted). Tutte le richieste di accesso con Smart Card vengono indirizzate, mediante il gestore di risorse, al lettore che contiene la card. Pertanto, il gestore di

18

risorse è responsabile della gestione e del controllo dell'accesso di tutte le applicazioni a qualsiasi Smart Card, indipendentemente dal lettore in cui venga inserita. In pratica, il Resource Manager rende disponibile, ad una determinata applicazione, una connessione virtuale diretta alla Smart Card richiesta. Si può dire, dunque, che lo Smart Card Resource Manager gestisce l'accesso ai lettori e alle Smart Card. Per poterlo fare, esso utilizza le seguenti funzioni:

• Identifica e tiene traccia delle risorse

• Alloca i lettori e le risorse attraverso l'uso di più applicazioni

• Supporta lo spostamento delle risorse basilari (primitives) per accedere ai servizi disponibili su una determinata card

Nota: questo è un punto importante perché le card correnti sono dispositivi single-threaded (un processo alla volta) che spesso richiedono l'esecuzione di più comandi per completare una singola operazione. La transazione permette che comandi multipli possano venire eseguiti senza interruzione, assicurando che l'informazione di stato intermedia non sia corrotta

Nel caso siano presenti più lettori contemporaneamente ed un'applicazione cerchi una card, lo Smart Card Subsystem fornisce una lista di nomi di lettori, conosciuti dal sistema, in cui guardare. Per ciascun lettore nella lista, il Resource Manager dà le seguenti informazioni:

• Se il lettore è disponibile per essere usato da questa applicazione

• Se c'è una card inserita in questo lettore, e, se è così, qual è la sua ATR string

• Se la ATR string della card corrisponde ad una qualunque delle ATR string delle card richieste

L'applicazione, quindi, usa le informazioni che vengono restituite per poter applicare ulteriori filtri alle card, oppure per suggerire all'utente di scegliere la card desiderata.

3.3 Identificare l'utente

Nel momento in cui la Smart Card viene inserita nel lettore ed è riconosciuta dal sistema, si pone il problema dell'autenticazione. L'autenticazione tramite Smart Card rientra nel fattore “qualcosa che solo l'utente possiede”; principalmente la card opera il riconoscimento tra Smart Card e mondo esterno.

19

3.3.1 Tipi di autenticazione

Lo standard ISO definisce tre tipi di autenticazione, in base a chi effettivamente effettua la verifica dell’identità (la card, il mondo esterno o entrambi):

1. Interna

Verifica dell'identità della card da parte del terminale.

2. Esterna

Verifica dell'identità del terminale da parte del mondo esterno.

3. Reciproca

Sia interna che esterna; verifica dell'identità della card da parte del terminale e verifica dell'identità del terminale da parte del mondo esterno.

Il principio generale su cui si basa l'autenticazione è il seguente: i due soggetti o subjects si scambiano le proprie chiavi pubbliche e delle semi-chiavi casuali, crittografate tramite la propria chiave privata e valide solo nell'ambito di quella determinata sessione (autenticazione dinamica); ognuno dei due subject, dopo aver verificato l'identità dell'altro, unisce le due semi-chiavi formando, così, un'unica chiave (conosciuta solo dai due soggetti); la chiave viene, poi, utilizzata per crittografare il traffico scambiato dai due soggetti.

3.3.2 Autenticazione ad un dominio Windows

Parlando di autenticazione su un sistema operativo Microsoft, una Smart Card può autenticarsi ad un dominio Windows (da Windows 2000 in poi) in tre modi:

1. Logon interattivo

L’utente, inserendo il PIN, si autentica alla macchina utilizzando la Smart Card.

Dopo che l’utente inserisce il PIN nella finestra di logon, il sistema operativo inizia una sequenza di azioni per determinare se l’utente può essere identificato e autenticato.

2. Autenticazione client

In generale, l'autenticazione client implica l'identificazione e la convalida di un client ad un server per stabilire un canale di comunicazione protetto. In genere, vengono utilizzati protocolli

20

protetti quali SSL (Secure Sockets Layer) o TLS (Transport Layer Security), di solito insieme ad un certificato con chiave pubblica attendibile, che viene fornito dal client. TLS e SSL sono protocolli crittografici, adottati per garantire la sicurezza delle transazioni on-line, che permettono una comunicazione sicura su reti TCP/IP attraverso un processo di cifratura a livello di trasporto TCP/UDP; impediscono la manomissione, la falsificazione e l'intercettazione dei dati e ne garantiscono l'integrità. Grazie all'impiego del SSL, infatti, si abilitano due fondamentali servizi di sicurezza:

a) Secure channel

Tutti i dati trasferiti tra il sito Web e l'utente finale sono cifrati.

b) Server authentication

L'utente può verificare l'identità ed autenticità del sito Web al quale si è collegato.

La sessione protetta viene stabilita utilizzando l'autenticazione con chiave pubblica con scambio di chiavi, per ricavare una chiave di sessione univoca che può essere, quindi, adoperata per garantire l'integrità e la riservatezza dei dati durante la sessione.

La Smart Card è utilizzata durante la generazione di una sessione sicura con SSL o TLS: il ruolo della Smart Card nell’autenticazione client è quello di firmare una parte del protocollo durante la sessione iniziale di negoziazione SSL; la chiave privata, corrispondente al certificato a chiave pubblica, è memorizzata sulla Smart Card e quindi il metodo di autenticazione è “forte”. L’operazione che coinvolge la chiave privata è fatta sulla card: in tal modo la chiave privata non è mai esposta al computer host o alla rete.

Quindi nell'autenticazione tramite Smart Card si migliora il processo di autenticazione con chiave pubblica e ciò avviene poiché la card stessa viene utilizzata come archivio protetto della chiave privata e, allo stesso tempo, anche come motore crittografico per l'esecuzione di una firma digitale o di uno scambio di chiavi.

3. Logon remoto

Utilizza certificati a chiave pubblica tramite TLS per autenticare uno user remoto ad un account memorizzato in Active Directory. Windows 2000 include un modulo incorporato per Smart Card che serve ad abilitare l'autenticazione forte per utenti remoti; ciò avviene tramite l'uso di protocolli ad autenticazione reciproca: il client ed il server devono entrambi dimostrare le proprie identità. Se il server a cui si è connessi non fornisce alcuna prova della propria identità, la connessione verrà terminata.

21

4 La Carta Regionale dei Servizi

4.1 La Carta Nazionale dei Servizi

La Carta Nazionale dei Servizi (CNS) è un documento informatico, rilasciato da una Pubblica Amministrazione, con la finalità di identificare in rete il titolare della carta. Utilizza una Smart Card a microprocessore in grado di registrare in modo protetto le informazioni necessarie per l’autenticazione in rete. La CNS può venire emessa da tutte le amministrazioni purché si attengano alle restrizioni indicate dal decreto interministeriale siglato (fra il Ministero dell'Interno, il Ministero per l'Innovazione e le Tecnologie e il Ministero dell'Economia e delle Finanze) il 9 dicembre 2004 sulle regole tecniche e di sicurezza per la diffusione e l'utilizzo della CNS.

4.1.1 Gli standard CNS

Per quanto riguarda la struttura del supporto fisico, la CNS non presenta particolari restrizioni. Va comunque rilevato che devono essere fatti salvi i vincoli imposti dagli standard internazionali sulle Smart Card (dimensione, posizionamento chip e banda magnetica, struttura antenna, etc...). A proposito del layout, sulla carta devono essere presenti la scritta “Carta Nazionale dei Servizi” ed il nome della Pubblica Amministrazione che l’ha emessa. Inoltre i dati da stampare sulla CNS e l’eventuale loro memorizzazione sul microchip sono decisi e disposti dall’Ente emettitore che la rilascia: l'Ente emettitore è, in generale, la Pubblica Amministrazione che rilascia la CNS e ne garantisce la corretta gestione del ciclo di vita. Sulla CNS non devono essere presenti dei dati utilizzabili in alcun modo per il riconoscimento a vista del titolare, come ad esempio la fotografia.

A livello strutturale il microprocessore deve rispettare le specifiche

22

pubblicate sul sito del Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA) e sul sito della Carta d’Identità Elettronica (CIE), in conformità agli standard ISO 7816 e 14443: viene utilizzata la tecnologia CMOS 0,18μ, una CPU da 24 bit, una frequenza di clock esterna da 1 a 10 Mhz, 500000 cicli di lettura/scrittura (minimo), 160KB di ROM e 72 KB di EEPROM.

Figura 4.1: Organizzazione del File System della carta CNS, in base alle direttive del CNIPA

La struttura dei dati registrati nella memoria riscrivibile (EEPROM) del

23

microcircuito può essere descritta dalla tabella 4.1:

Legenda

• Fornito da: indica il soggetto che fornisce l’informazione (proprietario del dato)

• Predisposto da: indica il soggetto responsabile della predisposizione della struttura nel File System della carta destinata a contenere il dato

• Scritto da: indica il soggetto responsabile dell’inserimento del dato nella CNS.

ELEMENTO FORNITO DA

PREDISPOSTO DA

SCRITTO DA DESCRIZIONE

MF - Produttore - È il Master File della struttura di memorizzazione. Corrisponde alla directory radice di un ordinario sistema operativo

DF0 - Produttore - Dedicated File (directory) dove vengono memorizzate le informazioni prodotte durante la fase di inizializzazione della carta

DF1 - Produttore - Dedicated File (directory) dove vengono memorizzate le informazioni raccolte durante la fase di personalizzazione della carta

DF2 - Produttore/Ente Emettitore

- Dedicated File (directory) dove vengono installati i servizi che necessitano, per il loro funzionamento, di una struttura dati riservata nella memoria riscrivibile (EEPROM) del microcircuito

PIN Ente Emettitore

Ente Emettitore Ente Emettitore È il PIN utente richiesto per usare la chiave privata Kpri per le operazioni di autenticazione in rete. Questo codice deve essere consegnato dall'Ente Emettitore o centro servizi di rilascio, con garanzia di segretezza, al titolare della CNS

PUK Ente Emettitore

Ente Emettitore Ente Emettitore È il PUK utente richiesto per sbloccare la carta nel caso non si disponga del PIN. Questo codice deve essere consegnato dall'Ente Emettitore, con garanzia di segretezza, al titolare della CNS

Kpri - Ente Emettitore - Chiave presente internamente alla carta, congiuntamente al Kpub. Essa è invisibile all'esterno, ma utilizzabile per le operazioni di cifra richieste durante l'operazione di strong authentication (autenticazione forte). Il microcircuito deve essere provvisto di un motore crittografico interno (crypto-engine), al fine di rendere più rapide tali operazioni

24

ELEMENTO FORNITO DA

PREDISPOSTO DA

SCRITTO DA DESCRIZIONE

Id_Carta - Ente Emettitore/Certification

Authority

Ente Emettitore/Certification

Authority

È il numero identificativo della carta che contiene informazioni sull'Ente Emettitore e il numero progressivo dell'emissione presso tale Ente

Cda CertificationAuthority

Ente Emettitore Ente Emettitore È il certificato, rilasciato da una Certification Authority iscritta all'albo, che garantisce la validità del legame tra la componente pubblica Kpub ed il titolare della CNS

Firma digitale Produttore Certification Authority

Certification Authority

È il Dedicated file destinato ad ospitare le informazioni per la firma digitale

Carta sanitaria Produttore Regione/Ministero Salute

Regione/Ministero Salute

È lo spazio dedicato ad ospitare la carta sanitaria. Fornito dal produttore, viene predisposto e scritto dalle regioni o dal Ministero della Salute

PIN_SO Ente Emettitore

Ente Emettitore Ente Emettitore È il PIN di Security Officer che può essere utilizzato per l'installazione della firma digitale eventualmente rilasciato dall'Ente Emettitore all'utente per poter installare tale servizio

Dati_personali Ente Emettitore

Ente Emettitore Ente Emettitore È un file elementare che contiene i dati personali dell'individuo

Memoria_residua Ente Emettitore

Ente Emettitore Ente Emettitore È l'ammontare dello spazio totale previsto per i servizi decurtato dello spazio utilizzato da quelli già installati

Tabella 4.1: Struttura dati e matrice delle responsabilità

Il file elementare dei dati personali è codificato con le definizioni specifiche descritte nella tabella 4.2:

DATO TIPO DI DATO DIMENSIONE MAX DESCRIZIONE

Emettitore Obbligatorio 4 Indicazione dell'emittente

Data di emissione del documento

Obbligatorio 8 Formato GGMMAAAA

Data di scadenza del documento Obbligatorio 8 Formato GGMMAAAA

Cognome Obbligatorio 26

Nome Obbligatorio 26

Data di nascita Obbligatorio 8 FORMATO GGMMAAAA

Sesso Obbligatorio 1 'M' maschile, 'F' femminile

Statura (cm) Opzionale 0 Presente per compatibilità CIE

Codice fiscale Obbligatorio 16

25

DATO TIPO DI DATO DIMENSIONE MAX DESCRIZIONE

Cittadinanza (codice) Opzionale 0 Presente per compatibilità CIE

Comune di Nascita Obbligatorio 4

Stato estero di Nascita Opzionale 0 Presente per compatibilità CIE

Estremi atto di Nascita Opzionale 0 Presente per compatibilità CIE

Comune di residenza al momento dell'emissione

Obbligatorio 4

Indirizzo di residenza Opzionale 80

Eventuale annotazione in caso di non validità del documento per l'espatrio

Vuoto 0 Presente per compatibilità CIE

Tabella 4.2: Definizione dati personali

4.2 La Carta Regionale dei Servizi 

La Carta Nazionale dei Servizi della Regione Friuli Venezia Giulia (o Carta Regionale dei Servizi - CRS) rappresenta il nuovo libretto sanitario del cittadino. La nuova tessera sanitaria (TS) è utilizzabile come mezzo:

• Di riconoscimento e di utilizzo di servizi socio-sanitari in rete (servizi di e-government fruibili via Internet)

• Di memorizzazione di dati sanitari aggiuntivi (ASS, medico, esenzioni, etc...) in luogo di adesivi nello “spazio a disposizione dei dati sanitari regionali” per consentire l'abolizione del cosiddetto “libretto sanitario”

La CRS diventa, così, lo strumento tecnico utilizzato dal cittadino per godere di vari servizi, sanitari e non solo, presenti su un portale dedicato.

4.2.1 Finalità

La nuova tessera sanitaria del Friuli Venezia Giulia consente alla Regione di mantenere integre le finalità e gli obiettivi previsti per una tessera sanitaria elettronica (prevista dall'articolo 50 del decreto legge 30 settembre 2003, n° 269), di avviare ulteriori servizi basati sull'utilizzo di una carta a microprocessore con possibilità di accesso in rete e di ottimizzare i costi per i cittadini evitando l'emissione a breve distanza di

26

più carte con finalità analoghe.

La definizione della soluzione individuata è suffragata dai seguenti elementi:

• La carta prodotta è la TS prevista dall'art, 50, ma integrata dalla componente CNS

• Le carte sono prodotte a partire dai dati dell'anagrafe dell'Agenzia delle Entrate/Sogei validate, nella fase di produzione massiva, dalla Regione Friuli Venezia Giulia

• Il layout dei dati visibili sulla carta è uguale a quello della tessera sanitaria, ed il verso è quello definito dalla normativa europea della TEAM

• La struttura ed i contenuti del microprocessore sono quelli definiti dalle specifiche CNIPA per le Carte Nazionali dei Servizi

4.2.2 Struttura e caratteristiche

Tutte le CNS sono personalizzate con i caratteri braille (combinazione di 3 lettere del codice fiscale: le prime due che identificano il nome e il sedicesimo carattere del codice fiscale), per agevolare i cittadini non vedenti nel riconoscimento tra più tessere in possesso della stessa persona, nonché la direzione di utilizzo della stessa; nello specifico è stato inserito il microchip in posizione tale da non inficiare i dati presenti sul fronte della TS ed è stato utilizzato, per il simbolo della Regione, lo spazio a disposizione delle Regioni per i dati sanitari. Tale scelta è coerente con l'impostazione della TS in quanto i dati sanitari verranno poi registrati dalla Regione direttamente sul microprocessore, all'atto dell'attivazione della CNS.

Le caratteristiche fisiche delle TS, il tipo di microchip, la crittografia usata per la Firma Digitale e la banda magnetica (solo la terza traccia è riservata ad uso futuro per fini regionali) rispettano gli standard previsti per le CNS. Anche l'organizzazione del File System, come definita dalle specifiche CNIPA, è la stessa delle CNS. Le informazioni da inserire nel File System della CNS Regione Friuli Venezia Giulia, invece, sono:

• Anagrafica come da specifiche CNS

• Certificato carta

• Predisposizione firma digitale

• Struttura NetLink completa in cui saranno creati vuoti i file relativi a:

27

◦ Dati amministrativi protetti

◦ Dati di emergenza a lettura libera

◦ Dati di emergenza protetti

◦ Puntatori a eventi sanitari

Figura 4.2: Esempio di Carta Regionale dei Servizi

4.3 I certificati digitali

Un certificato digitale è un documento elettronico che attesta, attraverso una firma digitale, l'associazione tra una chiave pubblica e un determinato soggetto (una persona, una società, un computer, etc...). Ogni messaggio crittografato con una data chiave pubblica può essere decrittato solo da chi possiede la relativa chiave privata. Vale anche viceversa: se possiamo decrittare un messaggio con una determinata chiave pubblica allora siamo sicuri che quel messaggio è stato crittato da una precisa chiave privata. L'utilizzo del certificato digitale non garantisce, però, che chi si autentica sia effettivamente chi viene descritto dal certificato: il suo scopo è, infatti, garantire che l'autenticante sia il proprietario del certificato ma nulla si può dire sulla sua reale identità; ci si può solo fidare della veridicità del certificato in base alla “fama” e all'affidabilità della Certification Authority che lo ha emesso. Inoltre, nel certificato digitale sono presenti dei campi attributo, ovvero dettagli identificativi e descrittivi, che specificano informazioni riguardo il documento stesso, chi lo ha emesso (Certification Authority) e il proprietario.

4.3.1 I certificati nella CRS

La CRS contiene un Certificato di Autenticazione della carta, emesso dalla Certification Authority, che viene utilizzato per tutte le funzioni di

28

riconoscimento in rete e che, in combinazione con il PIN utente, permette l’utilizzo dei servizi in rete da parte del titolare. Fattore molto importante è il formato: conditio sine qua non, nell'ambito della CNS e della CRS, è che i certificati debbano essere nel formato Codificato Base64 X.509. Tra le informazioni, il certificato contiene anche il codice fiscale del titolare stesso.

A tale proposito i Certificati di Autenticazione CRS emessi dalla Certification Authority sono rilasciati su dispositivo sicuro di firma (Smart Card) ed attivati su richiesta diretta del titolare, successivamente all’identificazione fisica dello stesso da parte dell'Ente Emettitore (nel caso specifico la Regione Autonoma Friuli Venezia Giulia) o di altro soggetto da questi delegato.

Per procedere all’emissione del Certificato di Autenticazione per la CRS è necessario eseguire una procedura di registrazione, durante la quale i dati dei titolari vengono memorizzati negli archivi del Certificatore; alla fase iniziale di registrazione, quindi, segue quella della personalizzazione della carta, sempre ad opera dell'Ente Certificatore: le informazioni anagrafiche ottenute in fase di registrazione, congiuntamente alle informazioni generate in fase di personalizzazione, vengono utilizzate per generare il Certificato di Autenticazione per la CRS. Nel corso della fase di personalizzazione, vengono inserite nella CRS le informazioni necessarie per l’identificazione in rete del titolare della carta; in particolare, viene generato il codice PIN, da inserire al momento dell’autenticazione in rete, ed il codice PUK, da utilizzare per lo sblocco della carta a seguito di iterata digitazione errata del codice PIN. I codici PIN e PUK vengono inviati in busta chiusa internografata ad opera della Regione Autonoma Friuli Venezia Giulia, a seguito della richiesta di attivazione della CRS da parte del titolare.

Il certificato ha una validità di cinque anni a partire dalla data di emissione, ovvero fino alla data di pubblicazione della sua revoca o sospensione, se precedentemente effettuate. In prossimità di scadenza, può venire rinnovato con l’emissione di un nuovo certificato; la richiesta di un nuovo certificato, però, deve essere avviata prima della scadenza dello stesso. La procedura di rinnovo richiede la generazione di una nuova coppia di chiavi e nella conseguente certificazione della nuova chiave pubblica.

Il profilo minimo (caratteristiche, campi e dettagli) del certificato della Carta Regionale dei Servizi è quello stabilito dal CNIPA.

29

4.4 Autenticazione sul Web

La CNS dispone di certificati che permettono l’autenticazione Web. Normalmente, i dati scambiati via internet sono “in chiaro” e un intruso potrebbe indebitamente accedere a informazioni confidenziali. È possibile, tramite il protocollo SSL, stabilire un canale di comunicazione criptato e sicuro. [VEDI Capitolo 3, Paragrafo: ”3.3 Identificare l'utente”]

Oltre a questo primo livello di sicurezza, l’autenticazione Web è un meccanismo che, grazie alla Smart Card CNS, permette al server Web di assicurarsi dell’identità dell’utente che cerca di connettersi. Le informazioni riservate comunicate dal server Web saranno protette per due ragioni:

• Sono criptate e firmate, quindi nessuno può né leggerle né modificarle

• Sono trasmesse solo se l’utente è stato validamente identificato

Di fondamentale importanza, nell'utilizzo del protocollo SSL a livello di browser Web, è la presenza dei certificati digitali delle Certification Authority, che hanno emesso il proprio certificato CNS, fra quelli ROOT del sistema operativo: infatti, senza di essi, il browser impedirebbe l'uso dei certificati di tipo SSL client.

Invece, a livello di server, il gestore del server Web deve necessariamente installare su quest'ultimo un idoneo certificato SSL server, rilasciato da una terza parte fidata (Certification Authority).

30

5 Autenticazione   con  CRS su  Active  Directory

5.1 Specificità dei certificati CRS

Come visto nel capitolo precedente, i certificati digitali contengono dei campi compilati con i relativi dettagli [VEDI Capitolo 4, Paragrafo “4.3.1 I certificati nella CRS”]. Un tipico certificato associato ad una Smart Card CRS contiene i seguenti attributi:

• VERSION: indica versione dello standard X.509 utilizzato; può essere 1, 2 o 3

• SERIAL: indica il numero seriale univoco del certificato; impostato dalla CA

• INNER SIGNATURE:

◦ ALG. ID: (Esempio: id-sha1-with-rsa-encryption)

◦ PARAMETER: (Esempio: 0)

• ISSUER: indica la Certification Authority; contiene informazioni relative alla CA

◦ Common Name: nome identificativo (Esempio: Certification Authority Cittadini)

◦ Organizational Unit Name: tipo di servizio erogato (Esempio: Servizi di certificazione)

◦ Organization Name: nome del Certificatore accreditato (Esempio: Actalis S.p.A.)

◦ Country Name: nome della nazione della Certification Authority (Esempio: IT)

• VALIDITY: indica il periodo di validità del certificato

31

◦ Not Before: Oct 28, 03 09:59:55 GMT

◦ Not After: Oct 27, 09 09:58:42 GMT

• SUBJECT: indica chi ha commissionato il certificato digitale

◦ Common Name: nome identificativo. Deve contenere il codice fiscale del titolare, l’identificativo univoco del dispositivo e il valore dell’hash calcolato sul file elementare contenente i dati personali del titolare (Esempio:

LGRDNT63H14H501T/1234567890123456.hRfo7thkjYF45tF40v0t8DkgiIG=)

◦ Organizational Unit Name: nome dell’amministrazione (Esempio: Ministero della Salute)

◦ Organization Name: nome convenzionale di progetto (Esempio: CNS)

◦ Country Name: nome della nazione del Subject (Esempio: IT)

• PUBLIC KEY: informazioni sulla chiave pubblica utilizzata (Esempio: 1024 bit)

• ALGORITHM: tipo di algoritmo di crittografia usato

◦ ALG. ID: identificativo dell'algoritmo (Esempio: id-rsa-encryption)

◦ PARAMETER: parametro dell'algoritmo (Esempio: 0)

• MODULUS: chiave pubblica (Esempio: 0x00a209b4 65f57559 1f699938 e29a27b3 13a30893 7379cb22 37a6380e 9dd48c4d c9057d01 1039dd56 a55e9940 76c68c50 069a25b5 d777ffc4 d8c56ca2 fc3163e0 279d919f 0bb1d22d bb07d923 9e972ff3 252ed27a 4781bccd 99d7b76d 149d08cd 057f4b9d 9b04ddcb 76e1029e 16e0067f f7407553 01aa513e 126ae6b1 2977ea16 b3)

• EXPONENT: (Esempio: 0x010001)

• EXTENSIONS: informazioni e politiche proprie del certificato digitale (verranno trattate in maniera più approfondita al termine del certificato di esempio)

◦ Authority Information Access:

▪ Method: (Esempio: id-ad-ocsp)

▪ Location:

• Uniform Resource ID: (Esempio:

http://www.capki.it/OCSP/ResponderOne)

◦ Certificate Policies:

32

▪ Policy 1:

▪ ID: (Esempio: 1.3.76.16.2.1)

▪ Qualifier 1: (Esempio: unotice (id-qt-unotice))

▪ userNotice:

• explicitText: (Esempio: Identifies X.509 authentication certificates issued for the italian National Service Card (CNS) project in according to the italian regulation)

▪ Policy 2:

▪ ID: (Esempio: OID del Certificatore)

▪ Qualifier 1: cps (id-qt-cps)

▪ CPS uri: (Esempio:

https://www.capki.it/PrivateCA/CNSCPS)

◦ Key Usage:

◦ Extended Key Usage:

◦ Authority Key Identifier: (Esempio: 0xea3e2ce0 c724083f 97563685 e8b85cbd 4bba9e30)

◦ CRL Distribution Points: indirizzi dei Certificate Revocation List

◦ Distribution Point 1: indirizzi Internet che contengono la lista dei certificati digitali che sono stati revocati prima della data di fine validità

▪ Uniform Resource ID: (Esempio:

https://www.capki.it/Certificatore/CRL3)

◦ Subject Key Identifier: (Esempio: 0x44a0ff7c f5592ca6 63da6059 490ac1ce 337ecc2a)

• SIGNATURE: firma digitale

◦ ALG. ID: identificativo algoritmo di crittografia (Esempio: id-sha1-with-rsa-encryption)

◦ PARAMETER: (Esempio: 0)

◦ VALUE: firma digitale (Esempio: 0x6c3e208d 1d9bea97 31757b54 b752678f 1002426b a5e403d5 f5368d51 fce72a97 4040731e e0601ead e1e34a46 a7d0c305)

Alcuni campi devono essere presenti obbligatoriamente, mentre altri sono

33

facoltativi. L'estensione che risulta essere fondamentale, in quanto contiene dati addizionali che un emittente può voler aggiungere al certificato, si chiama “Extensions” (se presente, secondo lo standard X.509 la versione del certificato è la terza).

5.1.1 L'estensione Extensions

I campi che devono essere presenti all'interno di questa estensione sono Key Usage, Extended Key Usage, Certificate Policies, CRL (Certificate Revocation List – liste presenti in rete che contengono l'elenco dei certificati digitali revocati prima della loro naturale data di scadenza) Distribuition Points, Authority Key Identifier e Subject Key Identifier.

• Key Usage e Extended Key Usage

Indicano delle informazioni riguardo l'utilizzo della chiave privata; nello specifico, il primo campo indica l’utilizzo principale previsto della chiave del Titolare (Digital Signature, etc...), mentre il secondo ne indica ulteriori utilizzi di tipo secondario (Client Authorization, Smart Card Logon, etc...).

• Certificate Policies

Indica informazioni relative alla Policy usata nel certificato; è presente un identificatore.

• CRL Distribuition Points

Indicano gli indirizzi internet delle CRL.

• Authority Key Identifier e Subject Key Identifier

Indicano gli identificatori della chiave privata, rispettivamente della Certification Authority e dell'utente.

Invece, l'eventuale aggiunta di altre estensioni, anche private, è opzionale.

5.2 I problemi

Nell'ambito dei sistemi Windows, i certificati che vengono utilizzati, affinché possano essere considerati validi, devono contenere determinate chiavi attributo. Il problema che si è riscontrato nell'utilizzo della CNS sui sistemi Windows è dovuto, appunto, alla mancanza di alcuni attributi nel certificato. La problematica nasce dal fatto che le CNS non sono native per tali sistemi e, quindi, i relativi certificati non sottostanno ai requisiti imposti dalle normative Microsoft: i campi e gli attributi che devono essere

34

presenti nel certificato associato alla CNS non sono gli stessi che, invece, debbono essere presenti nei certificati utilizzati sotto Windows. In pratica, i certificati digitali associati alle CNS non vengono riconosciuti dal sistema operativo come validi. Nello specifico, mancano:

• Un attributo associato al campo di tipo EKU (Extended Key Usage), lo “Smart Card Logon”, ovvero una possibile modalità di autenticazione tramite Smart Card

• Il campo UPN (User Principal Name), cioè il nome utente associato al certificato

Mentre il campo EKU è previsto dal certificato associato alla CNS ma è sprovvisto del giusto attributo, il campo UPN non esiste.

5.3 La soluzione 

Ipoteticamente esisterebbero due condizioni particolari in cui l'autenticazione tramite Smart Card, su domini Active Directory, sarebbe comunque garantita, a prescindere dal sistema operativo usato; l'idea sarebbe quella di andare ad agire direttamente sui certificati digitali associati alla card stessa:

• Il certificato della Smart Card utilizzata contiene tra le varie EKU quella nota come “Smart Card Logon”

• Il certificato non contiene alcuna EKU

In ogni caso, queste non sono scelte accettabili, in quanto tutti i certificati digitali associati alle Smart Card già emesse non si possono più modificare. Un’alternativa, a livello client, sarebbe quella di aggiungere nella Smart Card un nuovo certificato digitale contenente le specifiche corrette. In realtà ciò non è possibile: oltre al fatto che non verrebbe riconosciuto in rete nei processi di autenticazione, il certificato non avrebbe neanche alcuna validità legale, in quanto non emesso dalla Certification Authority che gestisce la CRS.

Per quanto riguarda il problema dell'assenza dell'EKU “Smart Card Logon”, è stato risolto andando ad agire direttamente a livello software, sul sistema operativo: si è fatta una scelta di mercato, preferendo studiare la risoluzione della problematica solamente sui sistemi più recenti, quali Windows Vista, Windows Server 2008 e Windows 7. Infatti, non esiste ancora alcuna risoluzione dell’inconveniente sui sistemi Windows precedenti (come ad esempio Windows XP e Windows Server 2003). Tale operazione è stata effettuata in due modi diversi a seconda della versione del sistema operativo.

35

Per Windows Vista Service Pack 1 e Windows Server 2008 (senza Service Pack) è possibile eliminare il bug mediante l'applicazione di due hotfix direttamente sul sistema operativo: una patch, installata a livello client, si occupa di risolvere la mancanza dell’EKU nel certificato della Smart Card, aggiungendone uno fittizio; l'altra patch, invece, viene installata a livello server ed ha il compito di forzare la validazione del certificato sprovvisto dell'EKU.

Per le versioni più aggiornate di Windows Vista (successive a Service Pack 1) e per Windows 7 la risoluzione del bug avviene in maniera nativa.

Per superare, invece, il problema dell'assenza del campo di tipo UPN è necessario aggiungere nel profilo utente (in Active Directory) la parte pubblica del certificato permettendo, così, di bypassare la sua assenza nel certificato stesso; in questo caso sarebbe necessaria, però, un'operazione amministrativa preliminare che associ utente e certificato direttamente in Active Directory. Sarà poi cura di Windows Server trovare il certificato in AD e, quindi, l’UPN dell’utente cui è associato questo certificato.

5.4 Casi d'uso

Sintetizzando, quindi, si può dire che l'autenticazione, tramite l'utilizzo della CRS, su un dominio Active Directory può avvenire in tre modi differenti:

1. Autenticazione forte tramite certificato su Smart Card

Nei domini di rete Microsoft è possibile utilizzare funzioni di autenticazione forte basate su Smart Card. L'autenticazione univoca dell'utente avviene grazie alla combinazione dell'inserimento delle credenziali di accesso e del certificato associato alla CRS utilizzata. Per tale utilizzo, oltre alle informazioni base identificative del Titolare, nel certificato possono essere inserite informazioni di controllo tipiche dell’ambiente Microsoft necessarie ad abilitare certi servizi.

2. Autenticazione forte tramite certificato privo delle estensioni Microsoft

Procedimento del tutto identico a quello precedente; l'unica differenza sta nella mancanza di alcuni attributi (EKU di tipo “Smart Card Logon” e campo UPN) nel certificato associato alla Smart Card utilizzata. Per sopperire a ciò, permettendo quindi la piena funzionalità del procedimento di autenticazione, entrano in gioco le due patch descritte nel paragrafo precedente.

36

3. Riconoscimento dell'identità di un cittadino tramite CRS

Lo strumento necessario per poter effettuare le principali attività legate alla Carta Regionale dei Servizi si chiama Card Management System (CMS). Il sistema viene utilizzato per seguire l'intero ciclo di vita delle carte dall'emissione, passando per la gestione dell'anagrafica e l'abilitazione di servizi on-line, fino alla scadenza o alla revoca del certificato ad esse associato. Grazie alla combinazione dell'anagrafica del CMS regionale e della CRS è, dunque, possibile identificare univocamente l'utente: basta associare un account di Active Directory ai dati anagrafici del possessore della Carta Regionale dei Servizi.

Affinchè i metodi di autenticazione descritti nei punti 2 e 3 possano funzionare è inoltre necessario, come già descritto nel paragrafo precedente [VEDI Capitolo 5, Paragrafo “5.3 La soluzione”], che avvenga un'operazione amministrativa preliminare il cui compito è quello di associare utente e certificato direttamente in Active Directory.

37

6 Transitività  dell'autenticazione:  da  dominio a Web

6.1 Avvicinandosi al problema

L'idea che sta alla base di questo progetto è quella di poter sperimentare uno dei possibili utilizzi della CRS: oltre ai servizi offerti sul portale della Regione Friuli Venezia Giulia, la Carta Regionale dei Servizi può essere adoperata anche per autenticarsi su di un dominio [VEDI Capitolo 5, Paragrafo “5.4 Casi d'uso”]. È possibile effettuare il login ad un sito Web, con la CRS, accedendo a delle risorse protette tramite il meccanismo di Single-Sign On? Il problema è capire come ciò possa essere realizzato.

Una valida ipotesi di risoluzione si basa sulla possibilità di provare a "trasportare" il sistema di autenticazione locale direttamente in rete: si cerca, infatti, di sfruttare l'autenticazione su di un dominio tramite Active Directory. A questo sistema di autenticazione si vorrebbe però aggiungere la possibilità di utilizzare il meccanismo di Single-Sign On, in modo tale da permettere all'utente di autenticarsi sul Web senza inserire nuovamente le credenziali: si sfruttano, cioè, i dati precedentemente inseriti per poter accedere al sistema operativo del proprio computer. Inoltre, invece di utilizzare il binomio username e password, si vorrebbe poter usufruire della possibilità di potersi autenticare su Active Directory tramite l'uso di una Smart Card con il relativo PIN [Logon interattivo, VEDI Capitolo 3, Paragrafo “3.3.2 Autenticazione ad un dominio Windows”]. Ecco che, quindi, sfruttando il certificato digitale presente nella Carta Regionale dei Servizi sarebbe teoricamente possibile autenticarsi sul Web, con Single-Sign On, tramite la CRS.

L'obiettivo di questo capitolo, dunque, è quello di spiegare minuziosamente il modo in cui si è arrivati alla realizzazione di un'applicazione Web che verifichi tali ipotesi.

38

6.1.1 Strumenti

Per i motivi descritti precedentemente [VEDI Capitolo 5, Paragrafo “5.2 I problemi”], legati all'incompatibilità (nativa) dei certificati digitali Windows con quelli CRS, si è scelto di utilizzare, come sistema operativo, Windows 7. Siccome il linguaggio di programmazione più appropriato per poter gestire la CRS è C#, l'ambiente di sviluppo su cui è stata sviluppata l'applicazione è Visual Web Developer 2008 Express Edition. Riassumendo, quindi, si è utilizzato:

• Visual Web developer 2008 Express Edition

◦ Progetto ASP.NET Web Site

▪ Linguaggio Visual C#

Lato client

• Sistema operativo: Microsoft Windows 7

• Browser Web: Internet Explorer 8

Lato server

• Applicazioni e servizi Internet: IIS (Internet Information Service)

• ADSI (Active Directory Server Interfaces)

• .NET Framework 2.0

6.1.2 Prerequisiti

Affinché ci si possa autenticare tramite CRS sul Web è necessario si verifichino una serie di situazioni particolari studiate ed impostate "ad hoc".

1. Lato client

• Deve essere possibile autenticarsi tramite Smart Card sul proprio sistema operativo

• Per accedere al proprio sistema operativo deve essere necessario inserire le credenziali: non deve essere possibile l'autenticazione di tipo anonima

• Su Internet Explorer si deve impostare, come tipo di autenticazione, "windows authentication"

2. Lato server

• Nel server non deve essere possibile autenticarsi in maniera

39

anonima; si deve, invece, poter usare la “windows authentication” (tali impostazioni vanno modificate nel IIS del server)

• Bisogna impostare l'attributo dell'utente SMARTCARD_REQUIRED, obbligando, così, l'utente ad autenticarsi tramite Smart Card

6.1.3 Passaggi concettuali

Riassumendo, i passaggi concettuali principali si possono suddividere in 3 fasi distinte:

1. Introduzione

Dopo aver studiato in che modo avviene l'autenticazione su un dominio Active Directory tramite la CRS, si vuole tentare di espandere questo concetto anche all'autenticazione sul Web. Si cerca, quindi, di verificare se è possibile autenticarsi attraverso l'uso della Smart Card CRS e Single-Sign On in rete: per fare ciò, si è deciso, quindi, di sviluppare un'applicazione lato server.

2. Scenario

Il client vuole accedere ad una specifica pagina Internet. Le risorse presenti nella pagina sono protette: affinché la pagina richiesta possa essere visualizzata è necessario vengano passate le credenziali di accesso del client. Solamente se esse risultano corrette, il client può avere accesso alla pagina richiesta.

3. Nello specifico

La Carta Regionale dei Servizi contiene un certificato digitale che certifica l'identità del possessore della stessa. Di conseguenza, quando la pagina Web richiesta dall'utente necessita di credenziali, viene passato, oltre allo username e alla password di dominio del server, anche il certificato digitale presente nella CRS.

6.2 Funzionamento dell'applicazione

Quando l'utente tenta di accedere alla pagina Web, cioè dopo averne digitato nella barra degli indirizzi il relativo URL, entra in esecuzione sul server l'applicazione scritta in C# associata alla pagina richiesta. Lo scopo dell'applicazione è:

40

1. Verificare il tipo di autenticazione dell'utente (deve essere di tipo "windows authentication")

2. Controllare che l'utente sia autenticato (non deve esserci autenticazione anonima nel sistema operativo del pc in uso)

3. Assicurarsi che l'utente abbia le credenziali di accesso ad un dominio sul server (quello in cui “si trova” la pagina Web richiesta)

4. Se l'utente ha accesso ad un dominio sul server verificare se possiede un certificato digitale per autenticarsi

5. Nel caso in cui il certificato sia presente testare se è un certificato standard CRS X.509

Se questi passaggi hanno dato tutti esito positivo l'utente può visualizzare la pagina Web richiesta. Altrimenti viene visualizzato a schermo un errore del server in quanto l'utente non ha “i diritti” necessari per effettuare l'azione desiderata.

6.3 Sviluppo dell'applicazione

L'applicazione sviluppata comprende una pagina Web molto semplice ed il codice necessario per testare se l'utente ha “il diritto” di poterla visualizzare. In realtà, il server che è stato utilizzato ha un indirizzo IP privato di tipo statico e si trova in una Intranet Locale e non in rete ( la sostanza e la funzionalità del progetto resta comunque la stessa di un vero e proprio server Web).

Il codice si snoda in tre parti distinte:

1. La parte scritta in XML (file web.config), che contiene le impostazioni che controllano la modalità di utilizzo del sito Web

2. La parte scritta in C# (file Default.aspx.cs), che contiene l'algoritmo necessario per poter verificare se l'utente si sta autenticando con una CRS

3. La pagina Web (file Default.aspx), composta da una TextBox ed un pulsante

6.3.1 web.config

Il file web.config è quello di default proposto da Visual Web Developer 2008, tranne per l'aggiunta della modalità di autenticazione di tipo Windows e l'impedimento, da parte dell'utente, di effettuare il logon di tipo

41

anonimo (Figura 6.1).

Figura 6.1: Particolare file web.config

6.3.2 Default.aspx.cs

Il file Default.aspx.cs si divide in due parti distinte:

1. La procedura Page_Load, che va in esecuzione appena viene richiesta la pagina Web

2. La procedura Button1_Click, che va in esecuzione se si clicca sul pulsante della pagina Web

La prima azione che si effettua nella procedura Page_Load è quella di ricavare il nome dell’utente che ha effettuato il logon (Figura 6.2); dopo di che, viene effettuata in Active Directory una ricerca per poter ricavare gli attributi legati ad esso (Figura 6.3).

Figura 6.2: Procedura Page_Load (parte 1)

Figura 6.3: Procedura Page_Load (parte 2)

42

Fra questi attributi, sono di particolare interesse “altSecurityIdentities” e “userAccountControl”: con il primo si può verificare se all’utente è associato un certificato digitale e se esso è di tipo CRS; con il secondo si può accertare se l’utente sia effettivamente obbligato ad autenticarsi attraverso l’uso di una Smart Card.

Procedendo con l’analisi del codice, viene verificato se all’utente è associato almeno un certificato digitale. Come detto precedentemente, ciò accade grazie all’attributo “altSecurityIdentities”, la cui funzione è quella di fornire un array di stringhe, dove ogni stringa contiene la descrizione di uno dei certificati associati all’utente. Per ogni certificato digitale trovato, si verifica se la sua descrizione corrisponde a quella presente sul certificato della Carta Regionale dei Servizi: ciò avviene confrontando la stringa restituita dall’attributo “altSecurityIdentities,” compresa fra <I> (il subject del certificato dell’issuer) e <S> (il subject del certificato dell’utente), con la stringa identificativa di una CRS (<I> C=IT,O=Actalis S.p.A.,OU=Servizi di certificazione,CN=Regione Autonoma Friuli Venezia Giulia - CA Cittadini) (Figura 6.4).

Figura 6.4: Procedura Page_Load (parte 3)

Nel caso in cui si trovi almeno un certificato di tipo CRS entra in gioco l’attributo “userAccountControl”: tale attributo altro non è che una bitmask. Per sapere se l’utente è costretto ad autenticarsi con la CRS bisogna verificare che fra le opzioni della bitmask sia attiva SMARTCARD_REQUIRED (associata al numero 262144) (Figura 6.5).

43

Figura 6.5: Page_Load (parte 4)

In caso positivo si può, quasi certamente, concludere che l’utente si stia autenticando tramite l’utilizzo di una CRS.

La procedura Button1_Click, invece, una volta caricata la pagina Web, si occupa solo ed esclusivamente di stampare nell'apposita TextBox, dopo aver cliccato sul pulsante, il dominio in cui è avvenuto il logon e l'utente che lo ha effettuato (Figura 6.6).

44

Figura 6.6: Pagina Web, Dominio\Nomeutente

6.3.3 Possibili comportamenti

I possibili comportamenti del programma variano a seconda delle condizioni che si vengono a verificare: esse possono essere verificate mediante il messaggio stampato a schermo, nella TextBox, al caricamento della pagina Web. Come si evince dalla Figura 6.5, i casi possibili che si possono avere sono quattro, raggruppabili in due categorie:

1. Successo

L'utente si è autenticato con la CRS, in quanto ha un certificato digitale di tipo CRS ed è abilitato l'attributo SMARTCARD_REQUIRED.

2. Insuccesso (3 possibilità)

a) L'utente non è tenuto ad autenticarsi con CRS

Anche se l'utente è associato ad un certificato digitale di tipo CRS l'attributo SMARTCARD_REQUIRED è disabilitato: ciò vuol dire che potrebbe capitare che l'utente, nonostante abbia un certificato di una Carta Regionale dei Servizi, non stia usando la CRS per autenticarsi.

b) L'utente non si autentica con CRS

Anche se l'utente è associato ad un certificato digitale esso non è

45

di tipo CRS.

c) L'utente non ha un certificato di tipo CRS

L'utente non è associato ad alcun certificato.

46

7 Conclusioni

Il presente progetto aveva come obiettivo quello di verificare la possibilità di poter trasportare il concetto di autenticazione da un dominio Active Directory direttamente sul Web, sfruttando il meccanismo di Single-Sign On. Per poter vedere se ciò fosse stato possibile, è stata sviluppata un'applicazione Web che, attraverso l'autenticazione dell'utente sul proprio computer tramite la CRS, permettesse all'utente stesso di poter accedere direttamente ad un dominio senza inserire ulteriori credenziali.

Purtroppo, però, mancando documentazione Microsoft a riguardo, non si è riusciti fino in fondo nella verifica della transitività da locale a Web. Il problema che non rende possibile la finalizzazione degli intenti, sta nell'impossibilità di potersi autenticare sul dominio del server senza inserire ulteriormente le credenziali; nello specifico, dunque, viene a cadere l'utilità del Single-Sign On. Infatti, impostando sul server l'obbligatorietà da parte dell'utente di effettuare il logon tramite l'uso di una Smart Card (quindi di fatto attivando l'attributo SMARTCARD_REQUIRED) accade che ADSI non riesca a prelevare in automatico le credenziali di accesso al dominio sul server.

Quindi, le situazioni che si possono presentare sono due:

1. Attributo SMARTCARD_REQUIRED settato

Per visualizzare la pagina Web è necessario reinserire le credenziali di accesso al proprio pc (Figura 7.1).

2. Attributo SMARTCARD_REQUIRED non settato

Anche se all'utente è associato almeno un certificato di tipo CRS, potrebbe non aver utilizzato la Carta dei Servizi per autenticarsi, in quanto, non essendo obbligato ad usare una Smart Card, il logon potrebbe essere avvenuto anche tramite l'inserimento di username e password (Figura 7.2).

47

Figura 7.1: Richiesta Credenziali

Figura 7.2: Utente non necessariamente autenticatosi con la CRS

Ciò non toglie che utilizzando altri tipi di tecnologie (come ad esempio provando ad integrare Web Server Apache, Tomcat e LDAP su Linux)

48

questo tipo di transizione sia, invece, possibile.

Resta da dire che, in ogni caso, l'ampliamento delle funzioni e delle funzionalità della Carta Regionale dei Servizi porterebbe ad un enorme risparmio in termini di denaro e di praticità. Magari, si potrebbe sfruttare meglio la tecnologia offerta dalle Smart Card e usare la CRS anche come tessera della benzina, bancomat, carta di credito e abbonamento per i trasporti pubblici; o ancora come mezzo per iniziare sessioni crittografate SSL e strumento per firmare documenti digitali.

49

8 Ringraziamenti

Probabilmente, queste righe saranno le più noiose di tutto questo lungo lavoro, ma vanno fatte: non solo perché “si deve” ma perché “lo devo”.

Prima di tutto ringrazio la mia famiglia: “tutta” la famiglia sia chiaro. Questo è un ringraziamento veramente sentito, in quanto ogni giorno della mia vita lo devo ad ognuno di loro. Il sostegno morale e l'amore non sono mai mancati, come non sono mai mancati consigli e supporto. Università e non, loro ci sono, qualsiasi siano le mie scelte: ecco perché li ringrazio.

Un enorme grazie, quasi quasi direi “grazissimo”, va anche ai miei amici: quelli che non mancano mai, quelli che se gli scrivi ti rispondono sempre, quelli che appena possono ti rincuorano, che ti fanno divertire, ridere e sorridere, quelli che anche se non ci si vede spessissimo si sa hanno sempre un posto riservato nel proprio cuore. Da loro ho imparato che il tempo non conta: quando si è amici lo si è per sempre.

Arrivo, dunque, ai ringraziamenti di tipo “universitario”: ringrazio tutti i compagni di corso, colleghi di avventure e di sventure che hanno condiviso con me questo interminabile triennio. Ringrazio anche i professori, che grazie a questi benedetti (o maledetti, dipende) 30 esami mi hanno fatto maturare ed imparare molto. Un sentitissimo ringraziamento va anche ai miei “prof” delle superiori del Liceo Scientifico Galileo Galilei per il bagaglio personale, culturale, umano e scientifico che mi hanno lasciato.

“Dulcis in fundo” un grazie all'Insiel che mi ha ospitato per questo tirocinio. Un ringraziamento in particolare va: al Prof. Fulvio Sbroiavacca, che ha reso possibile questa esperienza, al Dott. Paolo Piscardi, che mi ha seguito in tutto “l'iter” progettuale, a Patrizio Bruno, che mi ha aiutato nella parte relativa alla programmazione, a Michele Leonori, ottimo compagno di mensa e non solo, e ai colleghi tutti che ho incontrato in questi mesi.

Sinceramente, non credevo di poter arrivare a questo punto e solo ora mi rendo conto, guardando il mio sudatissimo libretto, di tutto ciò che è stato questo lunghissimo percorso: posso finalmente dire “gatto”.

E per concludere con onore, ed in bellezza, non può mancare la citazione da triestino DOC che, ahimè, da anni mi contraddistingue: Fata la xè!!!

50

Bibliografia

Libri

• “Case for strong User Authentication”, Mark Lobel, PricewaterhouseCoopers, 2000

• DPCM 9 dicembre 2004, sulle regole di diffusione e utilizzo CNS

• Manuale Operativo FVG (Versione 1.1 del 31/08/2007)

• "Programmazione delle Smart Card", Ugo Chirico, Gruppo Editoriale Infomedia, 2003

Siti Internet

• Aspitalia.com, Enumerare utenti Active Directory

[http://www.a spitalia.com/script/705/Enumerare-Utenti-Active- Directory.aspx]

• Carta Regionale dei Servizi del FVG

[www.cartaservizi.regione.fvg.it]

• Enciclopedia libera Wikipedia

[www.wikipedia.it]

• Information Technology Support Center. University of Mariland. Best Practices: User Authentication Mechanisms

[http://www.itsc.state.md.us/oldsite/info/InternetSecurity/BestPractices/Authentic.htm]

• Security Focus OnLine Library on Authentication

[http://www.securityfocus.com/library/category/32]

• Supporto Microsoft

◦ Accesso proprietà ADSI non Managed

[http://msdn.microsoft.com/en-us/library/ms180896(v=vs.80).aspx]

◦ Assenza EKU certificato CNS, Patch 1

51

[http://support.microsoft.com/kb/955558]

◦ Assenza EKU certificato CNS, Patch 2

[http://support.microsoft.com/kb/959887]

◦ Autenticazione IIS

[http://msdn.microsoft.com/it-it/library/aa292114%28v=vs.71%29.aspx]

◦ Proprietà utenti Active Directory

[http://msdn.microsoft.com/en-us/magazine/cc163295.aspx]

◦ Provider autenticazione Windows

[http://msdn.microsoft.com/it-it/library/907hb5w9(v=vs.80).aspx]

◦ Superlayer .NET per ADSI

[http://msdn.microsoft.com/en-us/library/9t2667d1.aspx]

• Dia

◦ Capitolo 1, Smart Card

[http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/autentic_windows/pagineWebProgetto/capitolo1.htm]

◦ Capitolo 2, Autenticazione Smart Card

[http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/autentic_windows/pagineWebProgetto/capitolo2.htm]

◦ Capitolo 3, Autenticazione Smart Card sotto Windows

[http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/autentic_windows/pagineWebProgetto/capitolo3.htm]

Forum

• Ilient.com, "windows authentication" Windows 7 - Internet Explorer 8

[http://www.ilient.com/Sysforums/posts/list/2159.page]

• Supporto Microsoft, problema certificato CNS VS certificato Microsoft

[http://blogs.msdn.com/b/spatdsg/archive/2008/04/17/smartcard-in-2008-and-vista.aspx]

52