1. 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

2. Indice
1 Introduzione..............................................................................................1
1.1 Progetto Carta Regionale dei Servizi (Friuli Venezia Giulia).............1
1.1.1 Cos'è la CRS...................................................................................1
1.1.2 Come nasce la CRS.......................................................................1
1.2 Obiettivo ...............................................................................................2
2 LDAP – Active Directory (Microsoft)...................................................3
2.1 Active Directory....................................................................................3
2.1.1 LDAP.............................................................................................3
2.1.2 Perché usare Active Directory......................................................4
2.1.3 Single­Sign On..............................................................................4
2.1.4 Riassumendo: concetti chiave di Active Directory.......................5
2.2 Autenticazione......................................................................................5
2.2.1 Complessità, non ripudiabilità, identificazione e autorizzazione
................................................................................................................ 6
2.2.2 Fattori di autenticazione..............................................................6
2.2.3 Metodi di autenticazione..............................................................7
2.2.4 Fattori di scelta.............................................................................8
2.2.5 Vulnerabilità.................................................................................9
2.3 Utenti di Active Directory..................................................................10
2.3.1 Primary Domain Controller........................................................10
3 Autenticazione con Smart Card su dominio Active Directory.....11
3.1 Smart Card.........................................................................................11
3.1.1 Utilizzi.........................................................................................12
3.1.2 Struttura e caratteristiche .........................................................12
3.1.3 Classificazione.............................................................................13
3.1.4 Memory Card...............................................................................14
3.1.5 Microprocessor Smart Card........................................................15
3.1.6 Modalità di lettura......................................................................15
3.2 Integrazione client­server attraverso la Smart Card.......................16
i

3. 3.2.1 Smart Card Subsystem...............................................................16
3.2.2 Smart Card Setup Tool...............................................................17
3.2.3 Metodologie di connessione.........................................................17
3.2.4 Interfaccia Smart Card...............................................................18
3.2.5 Resource Manager.......................................................................18
3.3 Identificare l'utente............................................................................19
3.3.1 Tipi di autenticazione.................................................................20
3.3.2 Autenticazione ad un dominio Windows....................................20
4 La Carta Regionale dei Servizi...........................................................22
4.1 La Carta Nazionale dei Servizi..........................................................22
4.1.1 Gli standard CNS........................................................................22
4.2 La Carta Regionale dei Servizi .........................................................26
4.2.1 Finalità........................................................................................26
4.2.2 Struttura e caratteristiche.........................................................27
4.3 I certificati digitali.............................................................................28
4.3.1 I certificati nella CRS.................................................................28
4.4 Autenticazione sul Web......................................................................30
5 Autenticazione con CRS su Active Directory...................................31
5.1 Specificità dei certificati CRS............................................................31
5.1.1 L'estensione Extensions..............................................................34
5.2 I problemi............................................................................................34
5.3 La soluzione .......................................................................................35
5.4 Casi d'uso............................................................................................36
6 Transitività dell'autenticazione: da dominio a Web.......................38
6.1 Avvicinandosi al problema.................................................................38
6.1.1 Strumenti....................................................................................39
6.1.2 Prerequisiti..................................................................................39
6.1.3 Passaggi concettuali....................................................................40
6.2 Funzionamento dell'applicazione.......................................................40
6.3 Sviluppo dell'applicazione..................................................................41
6.3.1 web.config....................................................................................41
6.3.2 Default.aspx.cs............................................................................42
6.3.3 Possibili comportamenti.............................................................45
7 Conclusioni..............................................................................................47
8 Ringraziamenti.......................................................................................50
Bibliografia.................................................................................................51
ii

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. (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

20. 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

21. • 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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 PREDISPOSTO SCRITTO DA DESCRIZIONE
DA DA
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/ - Dedicated File (directory) dove
Ente Emettitore vengono installati i servizi che
necessitano, per il loro
funzionamento, di una struttura dati
riservata nella memoria riscrivibile
(EEPROM) del microcircuito
PIN Ente Ente Emettitore Ente Emettitore È il PIN utente richiesto per usare la
Emettitore 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 Ente Emettitore Ente Emettitore È il PUK utente richiesto per
Emettitore 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

28. ELEMENTO FORNITO PREDISPOSTO SCRITTO DA DESCRIZIONE
DA DA
Id_Carta - Ente Emettitore/ Ente Emettitore/ È il numero identificativo della carta
Certification Certification che contiene informazioni sull'Ente
Authority Authority Emettitore e il numero progressivo
dell'emissione presso tale Ente
Cda Certification Ente Emettitore Ente Emettitore È il certificato, rilasciato da una
Authority 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 Certification È il Dedicated file destinato ad
Authority Authority ospitare le informazioni per la firma
digitale
Carta sanitaria Produttore Regione/ Regione/ È lo spazio dedicato ad ospitare la
Ministero Salute Ministero Salute carta sanitaria. Fornito dal produttore,
viene predisposto e scritto dalle
regioni o dal Ministero della Salute
PIN_SO Ente Ente Emettitore Ente Emettitore È il PIN di Security Officer che può
Emettitore essere utilizzato per l'installazione
della firma digitale eventualmente
rilasciato dall'Ente Emettitore
all'utente per poter installare tale
servizio
Dati_personali Ente Ente Emettitore Ente Emettitore È un file elementare che contiene i
Emettitore dati personali dell'individuo
Memoria_residua Ente Ente Emettitore Ente Emettitore È l'ammontare dello spazio totale
Emettitore 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 Obbligatorio 8 Formato GGMMAAAA
documento
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

29. 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 Obbligatorio 4
momento dell'emissione
Indirizzo di residenza Opzionale 80
Eventuale annotazione in caso Vuoto 0 Presente per compatibilità
di non validità del documento CIE
per l'espatrio
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

30. 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

31. ◦ 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

32. 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

33. 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

34. 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

35. ◦ 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.hRfo7thkjYF45tF40
v0t8DkgiIG=)
◦ 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

36. ▪ 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. Figura 6.6: Pagina Web, DominioNomeutente
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

49. di tipo CRS.
c) L'utente non ha un certificato di tipo CRS
L'utente non è associato ad alcun certificato.
46