UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA Tesi di laurea in RETI DI CALCOLATORI Autenticazione Centralizzata con il sistema CAS, integrando un’infrastruttura a chiave pubblica in Ambito Universitario Candidato: Relatore: Matteo Sironi Chiar.mo Prof Roberto Alfieri Correlatore: Dott.Ing Marco Panella Anno Accademico 2008/2009
123
Embed
Facoltà di scienze Matematiche Fisiche e Naturali I R C · 2017-01-05 · UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSITÀ DEGLI STUDI DI PARMA
Facoltà di scienze Matematiche Fisiche e Naturali
Corso di Laurea in INFORMATICA
Tesi di laurea in RETI DI CALCOLATORI
Autenticazione Centralizzata con il
sistema CAS, integrando un’infrastruttura
a chiave pubblica in Ambito Universitario
Candidato: Relatore:
Matteo Sironi Chiar.mo Prof Roberto Alfieri
Correlatore:
Dott.Ing Marco Panella
Anno Accademico 2008/2009
Ai miei genitori
Ai miei nonni
Alla mia Maider
Indice
1 Introduzione 9 1.1 Contributo della tesi ..............................................................................................11
2.1 Modello generale di comunicazione cifrata tra A e B , con possibilità di intrusione...15
2.2 Modello di crittografia simmetrica ............................................................................17
2.3 Modello di crittografia asimmetrica ..........................................................................19
2.4 Autenticazione a due vie con protocollo challenge-response .....................................22
2.5 Autenticazione con centro di distribuzione chiavi KDC ............................................23
2.6 Protocollo di autenticazione Kerberos.......................................................................25
2.7 Mutua autenticazione con crittografia a chiave pubblica ...........................................27
2.8 Differenze tra autenticazione normale e centralizzata................................................33
3.1 Creazione di un documento firmato e cifrato.............................................................41
3.2 Principali differenza tra firma autografa e firma digitale ...........................................45
3.3 Struttura dello standard X509 per i certificati digitali ................................................50
3.4 Esempi di Smart Card, lettori e token USB ...............................................................53
3.5 Esempio di Carta Nazionale dei Servizi fornita dalla Cnipa ......................................54
4.1 Esempio di autenticazione distribuita prima e dopo l’introduzione di CAS ...............62
4.2 Esempi di plug-in di autenticazione per CAS ............................................................65
4.3 Schema di autenticazione CAS in modalità diretta ....................................................69
4.4 Schema di autenticazione CAS in modalità proxy.....................................................72
4.5 Catena di autenticazione tramite proxy .....................................................................72
5.1 Finestra di autenticazione CAS dell’Università di Parma ..........................................78
6.1 Pagina di conferma di avvenuta autenticazione riportante l’avviso di scadenza password ............................................................... 100
6.2 Certificato Digitale dell’Università di Parma in formato PEM ............................... 103
6.3 Esempio di autenticazione CAS tramite invio di un certificato digitale .................. 112
Capitolo 1
Introduzione
L’obbiettivo di questa tesi è quello di approfondire le problematiche relative
all’autenticazione in rete di un utente, in un ambito universitario.
L’autenticazione è un processo necessario quando due entità coinvolte in uno
scambio di messaggi o informazioni sulla rete, vogliono essere sicuri dell’identità
della controparte.
Infatti sempre più persone utilizzano la rete di Internet, ed è sempre più
numerosa la quantità di enti e soggetti che utilizzano Internet oltre che per
scambiare importanti informazioni, anche per effettuare dei pagamenti o
transazioni bancarie.
Per questi motivi le varie entità in gioco devono poter essere sicure delle
reciproche identità, e diventa quindi necessario introdurre il concetto di Identità
Digitale: l’Identità Digitale di un soggetto è quell’insieme di informazioni che
identificano univocamente un soggetto in rete, nello stesso modo in cui le
caratteristiche somatiche di un individuo lo identificano nella vita reale.
1 Introduzione 10
Al momento sono sempre più frequenti le frodi sulla rete di Internet, nelle quali
soggetti malintenzionati cercano di rubare le credenziali di un utente, il che rende il
problema della sicurezza in fase di autenticazione un argomento da non
sottovalutare.
Il problema della sicurezza comunque non si ferma alla sola fase di
autenticazione. Altri problemi sono la segretezza, il principio del non ripudio e
l’integrità dei dati.
La segretezza riguarda la necessità che due soggetti possano scambiarsi messaggi
o informazioni riservati, senza che nessuno possa intercettarli, leggerli o
modificarli. È quindi sempre più comune nascondere il contenuto originale dei
documenti in transito sulla rete, cifrandoli con tecnologie crittografiche sempre più
avanzate, che permettono uno scambio di messaggi sempre più sicuro.
Il principio del non ripudio è fortemente legato al concetto di firma. Infatti si
vuole che un documento in formato elettronico possa non essere ripudiato come
avviene per un documento cartaceo, ovvero con l’apposizione di una firma che
garantisce la validità del documento. Inoltre sempre per quanto riguarda i
documenti elettronici scambiati, disporre di una metodologia che permetta il
riconoscimento immediato del proprietario, è fondamentale.
Il problema dell’integrità dei dati è concettualmente collegato alla problematica
precedente, infatti si cerca di avere uno strumento che permetta di verificare in
maniera definitiva, se un documento elettronico è originale oppure ha subito
modifiche.
Per queste motivazioni nasce quindi l’idea di introdurre nei documenti elettronici
una Firma Digitale, che permetta una sicura e veloce identificazione del firmatario
e garantisca l’integrità dell’intero documento.
Anche la sicurezza in fase di autenticazione può trarre un sostanziale beneficio
dall’introduzione del concetto di Firma Digitale: avere uno speciale documento
elettronico debitamente firmato che attesti l’identità di un soggetto, non può che
migliorare e garantire un alto grado di sicurezza del sistema.
Questo è il concetto che sta alla base dei Certificati Digitali e di tutta
l’infrastruttura necessaria per un loro utilizzo sicuro e garantito. Contengono
informazioni personali sul proprietario, e gli consentono un’autenticazione più
1.1 Contributo della tesi 11
Sicura. I certificati digitali vengono rilasciati da una specifica Autorità che li firma e
ne certifica dunque la validità.
Disporre di un sistema che offra un servizio sicuro e qualificato, che certifichi
l’Identità Digitale di un utente sulla rete, aumenta notevolmente la sicurezza sia del
sistema stesso, sia di tutta la rete di Internet.
Con l’introduzione di una tecnologia del genere tuttavia si è introdotto un nuovo
problema, ovvero quale deve essere l’Autorità che garantisca il rilascio dei
certificati digitali validi con relativa firma.
A questa problematica purtroppo non esiste una soluzione globale per tutta la
rete internet. La soluzione sta nell’avere svariate Autorità di certificazione
considerate fidate, a cui le varie organizzazioni si appoggiano.
1.1 Contributo della tesi
Questo progetto di tesi si è concentrato sullo studio dei vari protocolli di
autenticazione, valutandone i principali vantaggi e svantaggi, cercando di applicare
gli aspetti studiati per migliorare il servizio di autenticazione web tramite il sistema
CAS dell’Ateneo di Parma.
Le motivazioni più importanti che hanno spinto questo lavoro sono state:
Studiare approfonditamente le diverse metodologie di autenticazione, con
particolare attenzione ai vantaggi in termini di sicurezza che si possono
ottenere introducendo le nuove tecnologie disponibili.
Migliorare la qualità e la sicurezza del sistema di autenticazione
dell’Università di Parma.
Offrire nuove funzionalità ai propri utenti, permettendo nuove modalità di
accesso ai servizi web offerti, garantendo sicurezza, efficienza, comodità e
trasparenza.
1.2 Aspetti sviluppati 12
1.2 Aspetti sviluppati
Per sviluppare gli obbiettivi preposti è stato eseguito uno studio approfondito
delle varie tematiche annesse al progetto, per poter affrontare in maniera più
consapevole l’integrazione di queste in un contesto concreto, in questo caso una
struttura universitaria.
Nel secondo capitolo verranno discusse approfonditamente le varie tecniche di
autenticazione disponibili e i diversi protocolli, con particolare attenzione per
quanto riguarda il tema della sicurezza, offrendo anche una panoramica della
crittografa ad essi associata. Verranno introdotte le nuove tecnologie di
autenticazione, con una precisa valutazione dei benefici che possono portare.
Successivamente verrà spiegato dettagliatamente cosa significa autenticazione
centralizzata Single Sign On, ovvero un servizio che permetta di centralizzare in un
unico punto tutte le autenticazioni.
Il terzo capitolo darà ampio spazio all’argomento dell’Identità digitale e delle
relative implementazioni. Verrà largamente trattato il tema della Firma Digitale,
cosa è e quali tecniche sono utilizzate, specificando inoltre il contesto legale che
essa rappresenta. Grazie all’introduzione della Firma Digitale si dirà come è
possibile legare l’identità digitale di un soggetto ad un certificato in formato
elettronico, ed introdurre un’infrastruttura che gestisca questo concetto.
Il quarto capitolo studierà approfonditamente il protocollo CAS in tutte le sue
modalità, riportando i miglioramenti che si possono ottenere con la sua
introduzione in un servizio di autenticazione.
Il quinto capitolo mostrerà come il sistema CAS è attualmente integrato
nell’Università di Parma, mentre il sesto capitolo discuterà il progetto affrontato
per migliorare il servizio corrente In particolare verrà specificato come e perché
introdurre nel protocollo CAS un sistema per la gestione della scadenza password
degli utenti locali di Ateneo. In secondo luogo verranno chiarite le modalità per
l’introduzione di un’infrastruttura a chiave pubblica per la gestione dei certificati
digitali, motivando in maniera precisa le scelte effettuate, ed illustrando l’utilità di
un servizio di questo tipo e anche gli svantaggi ad esso associati.
Capitolo 2
Autenticazione distribuita
L’autenticazione nell’ambito della sicurezza informatica è uno dei concetti
principali per la gestione dell’identità, durante una comunicazione tra due processi
remoti: si vuole essere sicuri che l’interlocutore col quale stiamo dialogando, sia
veramente chi dice di essere, e viceversa.
Talvolta si confonde il termine autenticazione con il termine autorizzazione.
Sebbene questi concetti siano legati tra loro ed entrambi importanti per la
sicurezza, il loro significato è profondamente differente. Infatti come già detto
l’autenticazione si preoccupa del problema di assicurare l’identità del processo col
quale stiamo dialogando, invece l’autorizzazione si occupa di gestire che cosa ad un
processo è permesso di fare. Il problema dell’autenticazione è più complicato di
quanto si possa pensare, e talvolta richiede l’ausilio di protocolli crittografici
complessi. Invece l’autorizzazione, che di norma viene eseguita dopo
l’autenticazione, normalmente consiste nella ricerca in tabelle o database o servizi
di directory dei vari permessi concessi all’utente. Per questo motivo l’interesse di
questa tesi si sviluppa principalmente sul problema dell’autenticazione.
L’autenticazione può avvenire attraverso varie tecniche, come la digitazione di
una password segreta, l’invio di informazioni personali garantite come certificati
2.1 Introduzione alla crittografia 14
digitali o smart card, token USB o altri metodi. Dato che l’invio di dati personali
sulla rete può essere un processo pericoloso in quanto intercettabile, sulla rete
l'autenticazione deve essere effettuata solamente utilizzando scambi di messaggi e
dati, che fanno parte di un protocollo di autenticazione. Di questi ne esistono
diversi, ognuno con le proprie caratteristiche, vantaggi e svantaggi.
L'autenticazione deve avvenire on-line, cioè istantaneamente e deve essere
distinta dall'autenticazione di colloqui passati.
Il prossimo paragrafo da un’introduzione alla crittografia, che è essenziale per
ogni protocollo di autenticazione e capire al meglio i vari argomenti trattati.
2.1 Introduzione alla crittografia
Questo paragrafo ha lo scopo di accennare alcuni elementi di crittografia senza
entrare nel dettaglio, data l’enorme vastità degli argomenti. Tuttavia alcuni aspetti
sono fondamentali per capire meglio alcune delle tecniche utilizzate, come il
concetto di chiave e di algoritmo simmetrico o a chiave pubblica.
Il termine crittografia deriva dal greco antico, da due parole che possiamo
tradurre come “scrittura segreta”. Ha radici storiche molto antiche, in quanto già
in passato era necessario comunicare segretamente senza che altri intercettassero il
contenuto della comunicazione.
Le varie tecniche che consentono di mantenere segreto il contenuto di un
messaggio, vengono chiamate tecniche di cifratura e decifratura.
I messaggi da cifrare, detti testi in chiaro, vengono trasformati da una funzione
parametrizzata da una chiave. L’output di questo processo di cifratura viene
chiamato testo cifrato.
Decifrare è l’operazione legittima di lettura del messaggio cifrato, mentre
decriptare è l’ attività di decifrazione da parte di un intruso malintenzionato. Un
possibile intruso che cerca di scoprire il contenuto del messaggio durante la sua
spedizione, non può fare altro che essere a conoscenza della chiave di cifratura per
poterlo leggere, altrimenti vedrà solo lettere o simboli incomprensibili.
2.1.1 Chiavi e algoritmi 15
Gli intrusi appartengono principalmente a due categorie:
Intrusi passivi : cercano solo di capire il contenuto del messaggio
Intrusi attivi : cercano di modificare il contenuto del messaggio
Figura 2.1 Modello generale di comunicazione cifrata tra A e B , con possibilità di intrusione
2.1.1 Chiavi e Algoritmi
La segretezza della chiave è quindi un elemento fondamentale affinché la
comunicazione resti sicura. La funzione o l’algoritmo di cifratura invece non deve
essere segreto. Questo può sembrare un controsenso, ma dopo anni di esperienza si
è concluso che, credere di avere un algoritmo segreto, quando in realtà l’intruso
detto anche criptoanalista lo ha scoperto, produce più danno che guadagno.
In più rendendo pubblico un algoritmo di crittografia, si ottiene gratuitamente il
test di numerose menti brillanti, che desiderano forzare il sistema per mostrare la
propria intelligenza, avendo conferma o meno della sua robustezza.
Il principio è quindi di avere un algoritmo di cifratura pubblico ma complesso,
per impedire all’ intruso di capire quale sia la chiave crittografica, pur avendo a
disposizione una grande quantità di testo cifrato.
2.1.2 Due principi fondamentali della crittografia 16
Esistono vari metodi per un criptoanalista per cercare di decriptare un
messaggio, innanzitutto deve capire quale algoritmo è stato usato per la cifratura,
poi deve scoprire la chiave. Per farlo può iniziare ragionare su di essa, oppure
tentare un cosiddetto attacco a forza bruta, che significa provare tutte le possibili
chiavi e combinazioni.
Qui entrano quindi in gioco le diverse tipologie di chiave. Dato che la vera
segretezza sta in essa, la sua lunghezza è alla base della progettazione del sistema
crittografico. Al giorno d’oggi gli algoritmi utilizzano come chiave una stringa che
può variare dai 128 bit, ai 1024 bit, dipendendo anche dalla tecnica utilizzata. Una
chiave da 128 bit, genera un possibile spazio di chiavi di 2128 ≈ 3 x 10 38 chiavi.
2.1.2 Due Principi fondamentali della crittografia
Sono due i principi della crittografia alla base dello studio dei diversi sistemi
crittografici:
Ridondanza
Il primo principio dice che tutti i messaggi cifrati devono al loro interno
contenere una parte ridondante, cioè una parte d’informazione non
necessaria alla comprensione del messaggio stesso.
Il destinatario deve quindi essere in grado di stabilirne la validità, con un
semplice esame del contenuto o con un breve calcolo.
Questo tecnica è necessaria per prevenire attacchi da parte di intrusi attivi,
al contrario facilita la decrittazione degli intrusi passivi. Questo è però il
concetto che sta alla base dell’idea della firma digitale, che verrà spiegata
dettagliatamente nei prossimi capitoli.
Attualità
Il secondo principio afferma che è necessario avere la possibilità di
controllare che ogni messaggio sia stato trasmesso di recente. Questo per
evitare che intrusi attivi inviino messaggi vecchi, proponendoli per nuovi, e
per evitare attacchi a ripetizione di forzatura del codice.
2.1.3 Algoritmi a chiave simmetrica 17
2.1.3 Algoritmi a chiave simmetrica
Il principio alla base di questo tipo di algoritmi, sta nel fatto che viene usata la
stessa chiave sia per cifrare che per decifrare il messaggio.
La maggior parte di questi utilizzano la tecnica della cifratura a blocco. Si
prendono in input n bit alla volta dal testo in chiaro, e producono n bit di testo
cifrato utilizzando la chiave. Tipicamente i blocchi vanno da un minimo di 64 bit ad
un massimo di 256 bit. La trasformazione in testo cifrato avviene tramite varie
iterazioni di trasposizione e sostituzione dei bit.
Tra i più famosi, possiamo citare DES1 (in disuso), triple DES (obsoleto, ma
ancora in uso), AES2, IDEA3.
Uno dei vantaggi nella scelta di usare un algoritmo di tipo simmetrico è per la sua
velocità. Infatti sia la cifratura che la decifratura risultano molto efficienti e rapidi.
Lo svantaggio maggiore però, è che la chiave da utilizzare deve essere stata stabilita
prima dell’inizio della comunicazione, e questo può pregiudicare fortemente la
Gli algoritmi a chiave pubblica o asimmetrica si distinguono rispetto ai
precedenti, per il fatto che la chiave con la quale si cifra un messaggio è diversa
dalla chiave con cui viene decifrato il messaggio. Inoltre la chiave di cifratura non è
in alcun modo derivabile da quella di decifratura.
Ad ogni soggetto coinvolto che intenda comunicare, è quindi associata una coppia
di chiavi:
Una chiave privata, tenuta segreta ed utilizzata per decifrare i messaggi in
arrivo dalla rete.
Una chiave pubblica, resa disponibile a tutti, usata da qualsiasi soggetto del
mondo esterno per cifrare un messaggio diretto al proprietario della relativa
chiave privata.
Lo scenario di comunicazione opera in questo modo4:
1. Bob intende comunicare con Alice. Si procura quindi la sua chiave pubblica,
che è disponibile a tutti.
2. Cifra il messaggio con la chiave appena ottenuta, e lo invia ad Alice.
3. Alice riceve il messaggio, ed è l’unica che lo può decifrare, perché è la sola in
possesso della chiave segreta relativa alla sua chiave pubblica.
Se ora Alice volesse rispondere a Bob in maniera sicura, dovrebbe quindi
procurarsi la chiave pubblica di Bob, cifrare con questa il messaggio ed inviarlo.
Bob dal canto suo sarebbe l’unico in grado di decifrarlo.
Il concetto generale alla base della crittografia asimmetrica, si fonda su principi
matematici solidi. Precisamente sull’uso di un problema complesso, ovvero un
operazione matematica facile da eseguire, ma difficile poter risalire agli elementi di
partenza solo attraverso il risultato. Uno dei metodi più utilizzati è la
scomposizione in fattori primi di numeri molto grandi, dalle trecento cifre in su. E’
molto facile e veloce moltiplicare due numeri primi, ben più difficile, laborioso e
soprattutto lungo riottenere quei numeri dal risultato della loro moltiplicazione.
4 Vengono Mantenuti i nomi storici Alice e Bob per indicare i soggetti coinvolti nella comunicazione segreta come nella maggior parte dei libri di crittografia.
2.1.4 Algoritmi a chiave pubblica
19
Tra gli algoritmi più famosi possono citare RSA5, DSS6 e lo scambio di chiavi
Diffie-Hellman7.
Uno dei vantaggi più interessanti della tecnica degli algoritmi a chiave pubblica è
la sicurezza. Infatti i soggetti coinvolti possono comunicare in tutta riservatezza,
senza problema di essere intercettati.
Tuttavia un lato molto negativo può subentrare quando uno dei soggetti dichiara
di essere chi in realtà non è. Questo è un problema molto grave e sono state
inventate svariate soluzioni per risolvere ciò, come la firma e i certificati digitali e le
PKI. Questi sfruttano un ulteriore proprietà degli algoritmi asimmetrici, ovvero
che l’ordine in cui vengono usate le due chiavi può essere scambiato: si può cifrare
un messaggio con la chiave privata e decifrarlo con la chiave pubblica.
Un altro dei principali svantaggi nell’uso di crittografia a chiave pubblica è la sua
lentezza. Infatti per avere una buona sicurezza, è necessario utilizzare chiavi molto
grandi. Per esempio l’algoritmo RSA che utilizza il metodo dei fattori primi, per
essere considerato sicuro deve utilizzare chiavi da almeno 1024 bit, il che lo rende
abbastanza lento.
Figura 2.3 Modello di crittografia asimmetrica
5 Nome dovuto alle iniziali dei nomi dei suoi tre creatori Rivest, Shamir e Adleman. http://it.wikipedia.org/wiki/RSA 6 http://it.wikipedia.org/wiki/Digital_Signature_Standard 7 http://it.wikipedia.org/wiki/Scambio_di_chiavi_Diffie-Hellman
2.2 Protocolli di autenticazione 20
2.2 Protocolli di autenticazione
Il problema di stabilire le identità di due processi remoti durante una
comunicazione è non banale. Perciò esistono vari protocolli di autenticazione, per
garantire ad entrambi gli attori coinvolti che, quando il protocollo è stato
completato, l’identità delle due parti è considerata sicura.
Il modello generale utilizzato in tutti i protocolli è il seguente:
Alice inizia la comunicazione inviando un messaggio a Bob, o ad una terza
persona fidata, chiamata KDC8.
Si susseguono vari scambi di messaggi nelle due direzioni, i quali possono
anche essere intercettati o modificati dall’intruso Trudy9.
Al termine del protocollo, Alice è sicura di dialogare con Bob e viceversa.
Un buon metodo molto utilizzato per avere una comunicazione veloce e sicura,
consiste nell’uso combinato delle due tecniche di crittografia simmetrica e
asimmetrica.
Inizialmente i due soggetti coinvolti si scambiano messaggi tramite crittografia a
chiave pubblica. All’interno di questi messaggi sicuri, viene stabilita una nuova
chiave di sessione segreta, da utilizzare successivamente per tutto il resto della
comunicazione, tramite crittografia simmetrica.
Sono molteplici le ragioni per cui si utilizza una nuova chiave casuale diversa per
ogni connessione: minimizzare la quantità di traffico inviato usando le chiavi
permanenti degli utenti, riducendo quindi la quantità di testo cifrato simile che può
essere intercettato da un intruso, e rendere minimi i rischi in una sfortunata
situazione dove un processo va in crash, e il relativo core dump entra in possesso
di malintenzionati.
Sono quattro le regole generali da seguire per la progettazione di un protocollo
corretto:
Chi inizia l’autenticazione deve provare la sua identità, prima che lo faccia
chi risponde.
8 Key Distribution Center, centro di distribuzione delle chiavi 9 Nome storico per i crittografi per indicare l’intruso.
2.2.1 Autenticazione basata su segreto condiviso 21
Per provare la mutua identità, inizialmente devono essere usate chiavi
differenti.
Per le richieste di entrambi, devono essere utilizzati insiemi differenti.
Rendere il protocollo resistente ad attacchi, nel caso in cui vi sia una
sessione parallela, e le informazioni ottenute da una sessione possano essere
utilizzate per forzare l’altra.
Se anche solo una di queste regole viene meno, è più probabile che il protocollo
subisca una forzatura indesiderata.
2.2.1 Autenticazione basata su segreto condiviso
Questi protocolli presuppongono che tra Alice e Bob vi sia già una chiave di
sessione segreta nota ad entrambi, KAB, scambiata anche tramite metodi fisici
(telefono o di persona), ma mai in viaggio sulla rete.
Si utilizza un principio base comune a molti protocolli di autenticazione:
Il soggetto A invia un numero casuale al soggetto B, che trasforma il numero
arrivatogli con un particolare algoritmo e ritrasmette il risultato.
I numeri casuali utilizzati ad ogni nuova connessione sono detti nonce10 e una
tecnica di questo tipo è chiamata challenge-response:
Nel messaggio 1 iniziale , Alice invia la propria identità A in chiaro a Bob. Bob dal
canto suo non può sapere se si tratta di Alice o Trudy, quindi crea una richiesta per
Alice contenente un numero casuale molto grande, RB, e lo invia in chiaro nel
messaggio 2. Alice riceve il numero, lo cifra con la chiave condivisa KAB, e reinvia a
Bob il numero cifrato, nel messaggio 3. Bob a questo punto è sicuro che sta
comunicando con Alice, perché è improbabile che Trudy abbia scoperto KAB, e
quindi generato il messaggio 3.
Alice però non è ancora sicura di interagire con Bob, quindi invia nel messaggio 4
un altro numero casuale RA. Bob risponde con il messaggio 5, contenente il numero
casuale arrivatogli da Alice RA, cifrandolo di nuovo con la chiave condivisa KAB.
10 Contrazione del’inglese ‘number used once’, Numeri usati una sola volta. http://it.wikipedia.org/wiki/Nonce
2.2.2 Autenticazione con KDC 22
A questo punto entrambi i soggetti sono sicuri della rispettiva identità, e possono
eventualmente scambiarsi una nuova chiave di sessione, cifrata con la chiave KAB.
Figura 2.4 Autenticazione a due vie con protocollo challenge-response
Questo protocollo è abbastanza sicuro, tuttavia non è esente da possibili attacchi.
L’unica violabilità si ha quando Alice è un server in grado di accettare più sessioni
alla volta e non ben configurato. L’attacco viene chiamato per riflessione, perché
aprendo una seconda sessione, è possibile ingannare il server e facendolo
rispondere alla sua stessa domanda, senza conoscere la chiave.
2.2.2 Autenticazione con KDC
La tecnica basata su segreto condiviso impone che ad ogni coppia di soggetti che
intendano comunicare, sia corrisposta una relativa chiave condivisa.
Questa tecnica può essere buona se le persone coinvolte sono relativamente poche,
però con l’aumentare di soggetti, aumenta notevolmente il numero delle chiavi.
Questo può portare a notevoli rischi, oltre ad una elevata scomodità.
Un metodo per risolvere questo problema, può essere usando di un centro di
distribuzione chiavi (KDC). In questo modello ogni utente possiede una singola
chiave condivisa con il KDC, e la coordinazione dell’autenticazione e
dell’instaurazione della chiave di sessione sono gestite dal KDC.
2.2.2 Autenticazione con KDC
23
Il protocollo opera in questo modo:
Alice sceglie una chiave di sessione KS, ed invia un messaggio al KDC, cifrato
con la chiave che condivide con esso, contenente la chiave di sessione scelta
ed il soggetto con cui vuole dialogare, cioè Bob.
Il KDC vede questa richiesta, decifra il messaggio proveniente da Alice ed
estrae l’identità del destinatario, e la chiave di sessione scelta. Invia quindi
un messaggio a Bob cifrato con la sua chiave condivisa col KDC, contenente
l’identità di Alice e la chiave di sessione da utilizzare.
Bob si vede recapitare il messaggio, lo decifra, e subito sa che Alice intende
dialogare con lui usando la chiave di sessione KS.
La fiducia nel KDC garantisce che l’identità dei soggetti sia quella dichiarata.
Tuttavia questo protocollo è soggetto ad attacchi del tipo a ripetizione. L’intruso
potrebbe intercettare il messaggio 2, ed inviarlo ripetutamente a Bob. Bob che si
fida del KDC, vede i continui tentativi di connessione di Alice, li accetta, e continua
ad eseguire quello che gli viene richiesto.
Esistono molte soluzioni per evitare attacchi a ripetizione, come per esempio
inserire in ciascun messaggio un contrassegno temporale chiamato timestamp, così
da scartare subito i messaggi scaduti. Il problema è che su di una rete distribuita gli
orologi non sono mai perfettamente sincronizzati, e anche permettendo un
intervallo temporale maggiore, l’intruso avrebbe difficoltà ma ancora campo libero.
Oppure come in precedenza si potrebbe inserire in ciascun messaggio un numero
casuale, un nonce. In questa seconda soluzione però, il soggetto dovrebbe
memorizzare tutti i nonce in arrivo, e scartare i messaggi con quelli già usati.
Combinazioni di queste due tecniche, come il protocollo di Needham-Schroeder11
su cui si basa l’autenticazione con Kerberos, possono portare ad una soluzione.
Figura 2.5 Autenticazione con centro di distribuzione chiavi KDC
Il protocollo Kerberos è pensato per fornire sicurezza di autenticazione su reti
aperte e insicure, dove la comunicazione tra gli attori che ne fanno parte può essere
intercettata o soggetta ad attacchi a ripetizione. Il suo nome deriva dal famoso
personaggio mitologico Cerbero. Questi era un cane a tre teste posto a guardia
dell’inferno, per evitare l’ingresso a persone non desiderate.
Fu progettato dal MIT12, per fornire un accesso sicuro alle risorse di rete agli
utenti, che si potevano connettere da differenti workstation, ed assume che queste
siano sicure al loro interno. Si basa sul protocollo di Needham-Schroeder,
supponendo che gli orologi dei vari componenti siano sincronizzati.
Gli obiettivi che originariamente si intendevano raggiungere con il sistema
Kerberos erano autenticazione, autorizzazione e accounting13, fornendo all’utente
trasparenza, fiducia, sicurezza e scalabilità. Alla fine però solo il primo obiettivo,
ovvero l’autenticazione è stato portato a termine.
Precedentemente gli utenti, per connettersi scambiavano un informazione
segreta col server, generalmente una password. Il problema era che questa
informazione veniva trasmessa in rete, quindi poteva essere intercettata.
Il protocollo permette uno scambio di messaggi cifrati tra le workstation e i
server, senza che circolino informazioni segrete sulla rete.
Kerberos utilizza tre differenti server, dove i primi due integrano un KDC:
Authentication Server (AS): verifica gli utenti durante il login.
Ticket Granting Server (TGS): emette un ticket14 utilizzato per provare
l’identità di chi lo possiede.
Service server (SS): compie il lavoro richiesto dall’utente.
Per permettere lo scambio di messaggi cifrati, ogni utente ed ogni servizio
dovranno avere una chiave condivisa ed utilizzare un algoritmo di crittografia forte.
Il server AS conserva al suo interno un database con le chiavi degli utenti e le
chiavi dei servizi, quindi è in grado di scambiare con essi messaggi cifrati senza che
12 http://it.wikipedia.org/wiki/Massachusetts_Institute_of_Technology 13 Verifica della quantità di risorse utilizzate da un particolare utente connesso 14 Letteralmente un "biglietto", che un client presenta ad un server di servizio applicativo, per dimostrargli l'autenticità della sua identità.
2.2.3 Autenticazione con Kerberos
25
venga scambiata la chiave. La tecnica adottata per utilizzare la password dell’utente
nelle operazioni di cifratura, si basa su di una conversione che trasforma la
password, in una chiave di cifratura simmetrica condivisa tra utente e server AS.
Quindi nemmeno il server conosce la reale password, ma solo una sua cifratura.
Il funzionamento del protocollo si distingue in tre diverse fasi:
La prima fase, l'Authentication Service Exchange, avviene all'atto del login
dell'utente, dove vi è uno scambio di messaggi con il server AS, cifrati con la loro
chiave condivisa. In questa fase, la workstation controlla in locale la validità della
password. Se la password è errata, l’utente non può decifrare il messaggio in arrivo
dal server AS. Dunque la password non è entrata in rete ed è rimasta sulla
workstation solo per pochi millisecondi.
Nella seconda fase, il Ticket Granting Service Exchange, viene concesso il ticket
di servizio dal server TGS all’ utente che lo richiede, dopo aver presentato
opportune credenziali valide passate nella fase uno dal server AS. Il ticket ha una
validità temporale, così da evitare che intrusi usino ticket scaduti.
Ed infine la terza fase, il Client/server Authentication Exchange, dove l’utente si
presenta al servizio applicativo forte del ticket appena ricevuto.
Figura 2.6 Protocollo di autenticazione Kerberos.
2.2.3 Autenticazione con Kerberos
26
Lo scopo di tutta questa infrastruttura è di permettere al client di accedere ai
server su tutta la rete in modo sicuro, senza che le sue informazioni segrete
viaggino in rete. Infatti la password è rimasta sulla workstation e solo per pochi
istanti.
Successivamente se l’utente vuole accedere ad un servizio di un altro server
applicativo, deve semplicemente richiedere un altro ticket al server TGS, senza
autenticarsi nuovamente ad AS. Questa tecnica è il preludio al concetto di
autenticazione centralizzata con CAS, che verrà trattata esaustivamente.
Si può però notare che il lavoro di autorizzazione è lasciato completamente ai
singoli server applicativi. Infatti i ticket che gli utenti presentano, servono solo a
dimostrare la loro identità, ma non a concedere permessi privilegiati.
Kerberos è utilizzato in molti sistemi reali, ed è una buona soluzione, tuttavia non
da nessuna garanzia se l’infrastruttura è vulnerabile: i server di autenticazione AS e
TGS, i server applicativi (imap, pop, smtp, telnet, ftp, ssh , AFS, lpr, ...) ed i client
devono essere mantenuti costantemente aggiornati perché si posso garantire la
sicurezza.
2.2.4 Autenticazione con crittografia a chiave pubblica 27
2.2.4 Autenticazione con crittografia a chiave
pubblica
La mutua autenticazione può essere eseguita anche con la crittografia a chiave
pubblica. Se Alice vuole comunicare con Bob, ha bisogno della sua chiave pubblica.
Se esiste una terza parte fidata che gestisce le chiavi pubbliche, solitamente una
Public Key Infranstructure (PKI), Alice può richiedergli la chiave pubblica di Bob
ed iniziare la comunicazione. Solitamente la chiave pubblica è contenuta all’interno
di un certificato digitale, argomento prevalente dei prossimi capitoli.
Ottenuta la chiave, Alice invia un messaggio a Bob comprendente la sua identità
ed un numero casuale, cifrato con la sua chiave pubblica.
Quando Bob riceve il messaggio, lo decifra con la sua chiave privata, e vede
l’identità di Alice. Però è ancora ignaro sulla sua vera identità, chiede quindi alla
PKI di fornirgli la chiave pubblica di Alice.
Ricevuta la risposta, crea un pacchetto cifrato con la chiave pubblica di Alice, e
glielo invia. Il pacchetto contiene il numero casuale generato da Alice, un altro
numero casuale generato sul momento da Bob, ed una chiave di sessione da
utilizzare.
Alice riceve il pacchetto da Bob e lo decifra con la sua chiave privata. Vedendo che
Bob le ha reinviato il suo numero casuale, il messaggio non è una ripetizione,
quindi è sicura di parlare con lui.
Come ultimo passo, Alice reinvia il numero casuale generato da Bob, cifrandolo
con la chiave di sessione da lui scelta, così da confermare la mutua autenticazione.
Figura 2.7 Mutua autenticazione con crittografia a chiave pubblica
2.3 Metodi di autenticazione
28
2.3 Metodi di autenticazione
L’identità di un soggetto durante un tentativo di autenticazione può essere
controllata principalmente in tre diversi modi:
Quello che si sa: All’utente è associato un username ed una password.
Solitamente l’username è una stringa contenente un nome, un indirizzo e-
mail, oppure un nickname. La password invece è una stringa, che
generalmente non ha un particolare significato. E’come una chiave da
inserire, per dimostrare di conoscerla, ed essere veramente chi si dichiara.
La password dovrebbe essere sufficientemente complessa per non essere
indovinata, e non troppo difficile da non ricordare.
Quello che si ha: un certificato digitale o una smart card. Un certificato
digitale è un documento ‘elettronico’, che stabilisce le proprie credenziali sul
web. Una smart card invece è una carta di plastica, come una vera e propria
carta di credito, e necessita di un architettura hardware esterna per poter
essere letta. Contiene un micro-chip dove sono salvate varie informazioni
sul possessore, e talvolta queste informazioni sono proprio sotto forma di
certificato digitale.
Quello che si è: si utilizzano dati biometrici personali per identificare
l’utente. Questi possono essere riconoscimento della voce, impronte digitali,
dimensioni delle dita e della mano, scansione della retina ecc. In ogni caso
sono necessari complessi dispositivi fisici per effettuare i riconoscimenti, il
che porta quest’ultimo tipo ad essere ancora poco in uso.
2.3.1 Vantaggi e svantaggi dei metodi di
autenticazione
Nelle tre metodologie viste sopra, ognuna ha dei particolari vantaggi e svantaggi,
in termini di efficienza, sicurezza, garanzia, e costi di realizzazione.
2.3.1 Vantaggi e svantaggi dei metodi di autenticazione
29
La più semplice delle tre è l’autenticazione tramite password. La sicurezza di
questo metodo dipende molto anche dalla realtà in cui si deve operare.
Se un username ed una password di un contatto in una chat vengono intercettati,
il problema pur non essendo banale, non è relativamente grave. L’intruso può
impersonificare l’utente mandando qualche messaggio o qualche mail, o scorrere la
lista di contatti. Ben più grave situazione invece, se le credenziali di un conto
bancario di un utente cadono in mani sbagliate. Questo metodo ha però anche altre
problematiche sia per gli utenti, sia per i fornitori dei servizi richiesti.
I servizi disponibili e richiesti dalla stragrande maggioranza degli utenti sono
molteplici, è quindi necessario ricordarsi molte differenti password. Questo può
portare ad avere sempre la medesima password per più servizi, o sceglierne di
troppo semplici, il che facilità l’intercettazione. Per alcuni, le continua richieste di
autenticazione sono considerate scomode, ed un ostacolo alla navigazione. Gli
utenti tendono anche a dimenticare le password, contattando l’assistenza o se
possibile procedendo direttamente alla creazione di un nuova identità. Questo
comporta notevoli costi per gli i gestori degli applicativi.
Inoltre vari servizi richiedono che la password venga cambiata dopo un
determinato periodo, oltre il quale viene considerata scaduta. Questo per
aumentare ulteriormente la sicurezza.
Per questi motivi, talvolta l’utente incarica terze parti per aiutarlo nel processo di
autenticazione. Questi possono essere software locali o remoti.
Localmente, la gestione delle password può essere demandata al browser web
dell’utente. Questi può ricordare tutte le varie password dei vari siti visitati,
semplificando la vita all’utente. Tuttavia non viene risolto il problema se l’utente si
collega ad internet da postazioni diverse, come una biblioteca o un internet café.
In remoto, la gestione delle password può essere assegnata ad un proxy server su
internet, eventualmente gestito dallo stesso internet provider o da un servizio di
rete specifico. Il meccanismo è simile al precedente, solo che in questo caso l’utente
si autentica una sola volta al proxy, il quale dopo l’autenticazione utente, si
preoccupa di inserire automaticamente le password quando richieste. Questa
tecnica è possibile, tuttavia di non semplice implementazione e uso su scala
mondiale.
2.3.1 Vantaggi e svantaggi dei metodi di autenticazione
30
Un ulteriore soluzione consiste nell’avere un unico servizio di autenticazione
fidato per più applicazioni, che utilizza un particolare protocollo sicuro da lui
scelto. Si crea quindi una sottorete di fiducia, dove i servizi sono direttamente
collegati all’unico dispositivo di autenticazione. Una volta che l’utente si è
autenticato, può accedere alle applicazioni di quella sottorete. Questa è l’idea che
sta alla base dell’autenticazione centralizzata, e del server CAS. Ovviamente il
dispositivo di autenticazione può anche essere configurato per autorizzare o meno
un utente ad accedere ad un servizio, ma come già detto questo è un altro
problema. Questa tecnica è una delle più adottate, nelle aziende ma soprattutto
dalle Università, in quanto si vuole dare ai propri studenti la possibilità di un'unica
autenticazione centrale, per poi poter eseguire varie operazioni, come l’iscrizione
agli esami, iscrizioni ai corsi, servizio mail ecc.
Al crescere dell’importanza di verificare con certezza l’identità di un utente,
username e password non offrono più un metodo sicuro. Un altro aspetto, per certi
versi ancora più importante della sicurezza dell’identità, è la sicurezza
dell’autenticità di un messaggio inviato. Quando si ha a che fare con documenti
legali, ordini e transazioni aziendali e bancarie, si deve trovare un modo per poter
verificare che il documento elettronico sia autentico, oltre che assicurarsi che sia
stato spedito veramente dal mittente dichiarato. E’ ovvio che un autenticazione con
semplice username e password e successivo invio del documento, non offre
abbastanza sicurezza e autenticità richiesti per questo ambiente.
Con la nascita dei certificati digitali, delle smart card, dei token USB, e dell’idea di
introdurre la firma digitale, entrambi i problemi possono essere risolti. Tuttavia la
sicurezza e l’autenticità non possono essere garantiti con assoluta certezza, perché
se un utente smarrisce la propria smart card, e magari ha all’interno il codice PIN 15
per utilizzarla, si è di nuovo al punto di partenza. Questa vulnerabilità però non è
collegata ad una falla nella struttura informatica portante, ma solo ad un errore
umano. L’uso di certificati digitali e di smart card è in continua espansione, e
probabilmente saranno il metodo di autenticazione predominante nei prossimi
anni.
15 Codice numerico di quattro cifre. http://it.wikipedia.org/wiki/Codice_PIN
2.3.1 Vantaggi e svantaggi dei metodi di autenticazione
31
Il terzo modo di autenticazione, ovvero quello per biometria, offre al giorno
d’oggi la maggior sicurezza possibile. I lettori di impronte digitali stanno uscendo
di serie su molti modelli di computer portatili, e si può immaginare che in futuro
non serviranno solo per il login locale del computer, ma anche per un
autenticazione biometrica in rete. Tuttavia dato il costo ancora molto elevato di
alcuni strumenti necessari al riconoscimento personale, basti pensare ad un
apparecchio di scansione della retina, questa metodologia non è ancora del tutto
diffusa, e riservata a pochi utenti.
Le ultime due tecniche viste vengono chiamate tecniche di autenticazione forte.
L’autenticazione forte è divenuta fondamentale con la comparsa di attacchi alla
rete e furti di dati sempre più sofisticati, la necessità di aprire le reti aziendali per
includere fornitori, clienti e partner commerciali e l’inasprimento e la capillarità
delle normative. Nonostante ciò, le spese e la complessità delle soluzioni di
autenticazione forte spesso ne scoraggiano l’adozione.
I problemi di sicurezza continuano a minare la fiducia nelle attività online. Uno
dei più gravi e sentiti è il controllo dell’identità. Se gli utenti e i dispositivi che
accedono alla rete non vengono identificati adeguatamente, le imprese sono
esposte al rischio di frodi, phishing, furto di identità, spoofing di IP.
Il phishing è una nuova subdola forma di social engineering, nella quale i
criminali si presentano come entità legittime per ottenere da ignari consumatori
informazioni personali come numeri di carta di credito, password e numeri di
previdenza sociale. Di norma, questi soggetti utilizzano siti Web fraudolenti o
indirizzi e-mail di aziende ben note per inviare messaggi di spam che ingannano il
destinatario e lo inducono a fornire dati confidenziali. Le informazioni personali
così acquisite vengono poi usate per frodi con carte di credito, furti di identità e
altri reati.
La sicurezza dei metodi di autenticazione, si può quindi riassumere:
Debolissima: Username/password trasferite in chiaro (da vietare)
Debole: Username/password su canale criptato
Media: Protocollo Challenge/response con Secure ID
Apposizione Sul documento La firma è una sua parte integrante
e legata al supporto.
Allegata al documento La coppia (documento-firma) costituisce il documento.
Paternità Riconducibile al soggetto direttamente.
Riconducibile al soggetto tramite l’uso del suo PIN
privato e segreto.
Verifica Paternità Diretta e soggettiva,
attraverso il confronto con una firma autentica.
Indiretta e oggettiva attraverso un algoritmo di
verifica pubblico.
Contraffabilità documento copia
Agevolmente contraffabile, ma
facilmente riconoscibile.
Non contraffabile senza il PIN segreto, ma eventuale
falso non riconoscibile.
Validità temporale Illimitata Limitata
Ripudiabilità Autentica per impedire il ripudio.
Ripudio impossibile senza provare il contrario.
Figura 3.2 Principali differenza tra firma autografa e firma digitale.
3.3 Gestione delle chiavi pubbliche 46
3.3 Gestione delle chiavi pubbliche
La crittografia a chiave pubblica consente la comunicazione sicura tra soggetti
che non condividono una chiave comune, e permette la firma dei documenti senza
la presenza costante di una terza parte fidata sempre on-line.
Il problema sul quale sì è prestata poca attenzione è: come fanno due soggetti che
non si conoscono, a procurarsi le rispettive chiavi pubbliche ed essere
completamente sicuri che appartengano veramente a loro?
Una possibile soluzione sarebbe quella di istituire un sito web per ogni soggetto,
ed inserire all’interno di esso la propria chiave pubblica. Ovviamente questa non
può risultare una soluzione accettabile. Sarebbe molto semplice per un possibile
intruso, intercettare la richiesta della home page da parte da parte del richiedente
la chiave, e sostituirne una contraffatta. L’ignaro utente credendo di dialogare con
il soggetto richiesto, potrebbe passare informazioni preziose all’intruso, il quale
potrebbe anche facilmente modificare questi messaggi e ridirigerli al vero utente
richiesto, con conseguenze disastrose.
È quindi necessario avere un sistema sicuro per poter scambiare le chiavi
pubbliche ed essere sicuri della loro provenienza.
Un primo tentativo per distribuire le chiavi sarebbe quello di avere un centro di
distribuzione chiavi aperto 24 ore su 24 che fornisca le chiavi pubbliche su
richiesta. Questa idea non sarebbe del tutto errata, però l’intero sistema
diventerebbe presto un collo di bottiglia, pregiudicando la scalabilità. Inoltre se il
centro fosse fuori uso per un guasto, la sicurezza di tutta la rete diventerebbe
instabile e subirebbe un improvvisa battuta d’arresto.
Per questo motivo è stata sviluppata una soluzione differente: non è più
necessaria la creazione di un centro sempre on-line, ma un centro che certifichi che
le chiavi pubbliche siano associate alle persone o gli enti che le esibiscono.
Un organizzazione che certifica l’appartenenza delle chiavi pubbliche si chiama
Certificate Autority, abbreviato CA, ovvero un autorità di certificazione.
Il modo in cui la CA garantisce la veridicità dei soggetti associati, è attraverso il
rilascio ad essi di un certificato digitale da lei debitamente firmato. Ovviamente
prima di rilasciarlo, la CA deve essere sicura dell’identità del soggetto richiedente.
3.3.1 Certificati digitali 47
3.3.1 Certificati digitali
Un Certificato digitale identifica univocamente un identità digitale. Il suo scopo
principale solitamente è quello di legare una chiave pubblica ad uno specifico
soggetto, che può essere un singolo utente, ma anche un intera organizzazione o
un’azienda. L’utente potrà accedere ad ogni risorsa senza inserire nessuna
password, e la sua identità sarà garantita dal certificato, così come l’integrità dei
dati dalla sua firma digitale. Un autenticazione con certificati è di tipo forte.
I certificati non sono ne segreti ne protetti. Questo perché la loro costruzione
garantisce che nessuno li possa modificare senza essere scoperti.
L’idea è la stessa che sta alla base della firma digitale, ovvero la crittografia a
chiave pubblica. Per ottenere un certificato, un soggetto deve recarsi da una CA con
la chiave pubblica da lui scelto, e un documento che garantisce la sua identità.
La CA dopo opportune ricerche, può decidere o meno di rilasciare il certificato; in
caso positivo emette il certificato, ne calcola l’impronta e lo firma con la sua chiave
privata. Dopodiché consegna al richiedente il certificato debitamente firmato.
Il certificato al contrario di una normale chiave pubblica, può essere
tranquillamente messo nella propria home page. Chiunque voglia dialogare con lui,
può scaricare il certificato dal sito ed ottenere la relativa chiave pubblica. Come
conferma, calcola l’impronta digitale del certificato, e decifra la firma del certificato
con la chiave pubblica della CA. Se le due impronte ottenute sono uguali, il
certificato è autentico, altrimenti è stato modificato.
Come per la firma digitale, anche i certificati hanno un periodo di validità
temporale, e possono essere revocati. Quindi oltre al controllo precedente, si deve
controllare anche che non sia scaduto o revocato. Questo può essere fatto
controllando una particolare lista pubblica aggiornata costantemente, contenente i
certificati revocati.
Questo protocollo non è attaccabile da parte di un intruso, perciò non è
necessario che i certificati siano segreti o crittografati.
Un certificato può essere anche usato per associare una chiave pubblica ad un
particolare attributo, per esempio la raggiunta maggiore età da parte del soggetto,
così da consentirgli accesso a servizi specifici per maggiorenni.
3.3.1 Certificati digitali
48
Si distinguono differenti tipi di certificati secondo il livello di firma :
I certificati auto-firmati sono dei certificati ad uso interno, firmati da un
server locale. Questo tipo di certificati permettono di garantire la
confidenzialità degli scambi all'interno di un'organizzazione, ad esempio per
i bisogni di un'intranet, come una rete interna di una università. E' quindi
possibile effettuare l’autentificazione degli utenti, grazie ai certificati auto-
firmati, rimanendo all’interno della intranet.
I certificati firmati da un organismo di certificazione sono necessari quando
si tratta di assicurare la sicurezza degli scambi con degli utenti anonimi, ad
esempio nel caso di un sito web accessibile al pubblico. Il certificatore terzo
permette di assicurare all'utente che il certificato appartiene effettivamente
all'organizzazione alla quale dichiara di appartenere.
I certificati servono principalmente in tre tipi di contesti :
Il certificato cliente, immagazzinato nelle risorse del computer dell'utente
oppure contenuto in un contenitore come una smartcard, che permette di
identificare un utente e di associargli dei diritti. Nella maggioranza delle
situazioni, esso è trasmesso ai server al momento di una connessione, che
attribuisce dei diritti, in funzione dell'accreditamento dell'utente. Si tratta di
una vera carta d'identità digitale che utilizza un paio di chiavi asimmetriche
di una lunghezza che va da 512 a 1024 bit.
Il certificato server installato su un server web permette di assicurare il
collegamento tra il server e il proprietario del servizio. Nel caso di un sito
web, permette di garantire che l'URL e in particolare il dominio della pagina
web appartengano effettivamente a questa o quell'azienda. Inoltre permette
di mettere in sicurezza le transazioni con gli utenti grazie al protocollo
SSL25.
Il certificato VPN26 è un tipo di certificato installato nelle apparecchiature di
rete che permette di codificare i flussi di comunicazione pezzo per pezzo fra
25 Secure Sockets Layer. Protocollo comunemente utilizzato per la gestione della sicurezza di una trasmissione dei messaggi su Internet 26 Virtual Private Network. Rete che utilizza una infrastruttura pubblica di telecomunicazioni, per fornire gli uffici remoti o singoli utenti un accesso sicuro alla rete della propria organizzazione.
3.3.2 Certificati X.509 49
due punti (ad esempio due siti di un'azienda). In questo tipo di situazione gli
utenti possiedono un certificato client, i server usano un certificato server e
le apparecchiature di comunicazione uno privato.
3.3.2 Certificati X.509
Se tutti i soggetti interessati ad aver un certificato si presentassero alla CA di
competenza, con una differente richiesta di struttura interna, sarebbe impossibile
arrivare ad una corretta gestione di essi. Per questo sono stati sviluppati vari
standard. Lo standard approvato e più in uso attualmente su internet è X.509, di
cui ne sono state sviluppate varie versioni, ma in questo momento è in uso la terza
versione.
X.509è stato influenzato pesantemente dal mondo OSI27, portandosi dietro però
anche qualcuna delle sue caratteristiche non migliori, come la nomenclatura e la
codifica. Però la IETF28, una comunità aperta di tecnici, ricercatori e sviluppatori
che ha l’intento di standardizzare le tecnologie di internet, ha approvato X.509
ignorando qualche volta il protocollo OSI, come i nomi delle macchine dei
protocolli di trasporto o gli indirizzi e-mail. Questa versione approvata da IETF è
descritta in RCF328029.
Lo standard X509, creato dalla ITU30, fece il suo debutto nella sua prima versione
nel 1988, parallelamente allo standard X500 utilizzato per i servizi di directory31.
Assunse fin dal principio un sistema gerarchico di autorità di certificazione per il
rilascio dei certificati, totalmente in contrasto con il modello della rete di fiducia,
web of trust, utilizzato da PGP32, dove chiunque poteva firmare e quindi certificare
la validità delle chiavi altrui.
27 http://it.wikipedia.org/wiki/Open_Systems_Interconnection 28 http://en.wikipedia.org/wiki/IETF 29 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, IETF, April 2002 30 International Telecommunication Union. http://www.itu.int 31 Un servizio di directory consente di dare dei nomi a degli oggetti e di associare a tali oggetti degli attributi 32 http://it.wikipedia.org/wiki/Pretty_Good_Privacy
3.3.2 Certificati X509
50
Nel 1993 uscì una seconda versione di X509. Fu migliorata la versione precedente
con l'aggiunta di altri due campi, il sostegno e la directory di controllo di accesso.
La terza versione, quella utilizzata tuttora, ha aggiunto una certa compatibilità
con altre topologie di reti e filtri, come maglie e ponti, la possibilità di essere
utilizzato in peer-to-peer33, compatibilità con PGP in una rete di fiducia, e altro
ancora. È stato introdotto anche un ulteriore campo opzionale: l’estensione del file
contenente il certificato. Le estensioni comuni più utilizzate sono “.CER”, “.PEM”, e
“.DER”.
La funzione principale dello standard X.509 quindi è quella di descrivere i
certificati, e questo include una definizione del certificato ed i suoi relativi campi.
Ogni certificato segue questa definizione, e in pratica è l’unica tipologia di
certificato usata e garantita nell’ ambito del commercio elettronico on-line.
X.509 include anche gli standard per le implementazioni delle liste di revoca dei
certificati (certificate revocation list ,CRL).
L’immagine mostra la struttura dello standard X509:
Figura 3.3 Struttura dello standard X509 per i certificati digitali
33 Rete di computer dove non esiste l’architettura client-server, ma molteplici nodi equivalenti che fungono sia da client che da server. http://it.wikipedia.org/wiki/Peer-to-peer
3.3.2 Certificati X.509
51
I campi di ogni singolo certificato, permettono di rilevare le informazioni in esso
contenute e di distinguerlo univocamente:
Version (Versione): identifica la versione di quale standard X509 alla quale
il certificato corrisponde.
Certificate Serial Number (Numero Seriale): è un identificatore unico
diverso per ogni certificato.
Certificate Algorithm Identifier: L’identificatore dell’algoritmo utilizzato per
firmare il certificato.
Issuer (Ente emettitore): il nome (DN, per Distinguished Name)
dell'autorità di certificazione emettente il certificato. Questo campo
identifica anche chi è responsabile della verifica dell’identità del soggetto.
Validity Period: il periodo di validità del certificato, contenente la data di
rilascio e quella di scadenza.
Subject (Soggetto): il nome del computer, utente, dispositivo di rete o
servizio al quale viene rilasciato il certificato.
Subject public key information: informazioni sulla chiave pubblica del
soggetto, precisamente.
Algorithm Identifier: algoritmo per l’utilizzo della chiave pubblica.
Public key value: chiave pubblica del soggetto.
Issuer Unique Identifier : codice identificativo univoco dell'emittente, usato
per identificare l’autorità che ha rilascio del certificato (opzionale).
Subject Unique Identifier: codice identificativo univoco del soggetto, usato
per identificare l’utente del certificato (opzionale).
Extension (Estensione): utilizzata per fornire ulteriori funzionalità e
caratteristiche al certificato(opzionale).
Certification Autority’s Digital Signature: firma digitale del certificato posta
dalla Certification Autority.
I campi Issuer e Subject, rispettivamente ente emittente e soggetto, talvolta non
contengono un solo attributo specificante il relativo nome ma una struttura tipo
X500.
3.3.2 Certificati X509
52
I campi di un nome X500 maggiormente utilizzati nei certificati digitali sono:
CN : Nome comune, o Common name
O : Organizzazione
OU : Dipartimento all'interno dell’organizzazione
C : Sigla del paese (nazione)
ST : Regione o provincia
L : Località
E : e-mail ufficiale
Con l'uso dei certificati X509 v3 e del protocollo SSL (Secure Socket Layer),
sviluppato inizialmente da Netscape ma che nella versione 3.0 è stato
standardizzato dalla IETF e ha preso il nome di TLS 1.0 (Transport Layer Security),
è possibile creare dei tunnel di connessione sicuro.
SSL é un protocollo al livello applicazione che fornisce un canale sicuro di
comunicazione tra parti, ed é basato su meccanismi crittografici a chiave pubblica e
su certificati X.509.
Esempi di protocolli di sessione incapsulati in tunnel SSL sono: https (secure
(secure LDAP), pop3s (secure pop3) e nntps (secure USENET transport protocol).
Il protocollo TLS/SSL non si limita a criptare i dati che passano nel tunnel, ma,
quando richiesto, garantisce anche l'autenticità del client e del server (mutua
autenticazione). Notare che gli algoritmi asimmetrici hanno una complessità
computazionale molto maggiore di quelli simmetrici, e per questo motivo nel
protocollo SSL, grazie a un primo scambio di dati crittografati asimmetricamente,
client e server si accordano su un algoritmo simmetrico e sulla relativa chiave di
sessione con cui criptare simmetricamente il resto della conversazione.
3.3.3 Smart card e Token USB 53
3.3.3 Smart card e Token USB
La smart card è un dispositivo hardware, evoluzione della normale tessera
magnetica. Contiene un microchip, nel quale sono integrati vari componenti, come
un microprocessore a 8 bit, un coprocessore crittografico, e varie memorie per
l’archiviazione dei dati. La costruzione del microchip porta all’inattaccabilità
esterna delle memorie e dei dai al loro interno, a meno di una riprogrammazione
completa della stessa. Grazie alle caratteristiche di protezione dei dati del
microchip e alla presenza del coprocessore crittografico, sulle smart card è quindi
possibile inserire in tutta sicurezza un certificato digitale X509. Di norma le smart
card sono protette da un codice per poter essere attivate. Questo è il codice PIN,
solitamente una stringa di quattro cifre.
Per poter essere lette, le smart card necessitano di un apposito lettore hardware
esterno, il che alle volte non è sempre presente in un normale personal computer.
Per questo motivo, i dispositivi token USB si stanno espandendo sempre più
frequentemente. Un token USB svolge le stesse funzioni di una smart card, il tutto
integrato in una semplice chiavetta collegabile al computer tramite la porta USB,
presente oramai dovunque.
L’autenticazione con smart card o token USB garantisce molta più sicurezza
rispetto ai metodi tradizionali, in quanto oltre a possedere il dispositivo stesso,
l’utente deve anche conoscere la password o il codice di attivazione.
La possibilità di avere una smart card o un token USB per l’autenticazione inoltre
fornisce anche molta flessibilità e portabilità, in quanto può essere usata dovunque
vi sia il dispositivo di lettura o la porta USB, non rilegando quindi l’utente ad
utilizzare il proprio certificato X509 solo sul proprio PC locale.
Figura 3.4 Esempi di Smart Card, lettori e token USB
3.3.4 Carta nazionale dei servizi 54
3.3.4 Carta nazionale dei servizi
Lo sviluppo del piano di e-government prevede la disponibilità estesa di uno
strumento nazionale di autenticazione in rete. Per tale motivo il processo di
diffusione di tale strumento viene accelerato affiancando al progetto della Carta di
Identità Elettronica (CIE) quello della Carta Nazionale dei Servizi (CNS). La carta
CNS, si configura come l’infrastruttura per l’accesso ai servizi in Rete (sanità,
trasporti, biglietti) e la gestione personalizzata delle informazioni, semplificando i
processi di identificazione e autenticazione certa, a costi contenuti e riducendo gli
iter burocratici. Le caratteristiche tecniche ed organizzative della CNS sono definite
dallo stesso gruppo di lavoro interministeriale, istituito dal Ministero dell’interno,
che cura gli aspetti tecnico-organizzativi. La carta può contenere eventuali
informazioni di carattere individuale generale, ha validità determinata
dall'amministrazione emittente, comunque non superiore a sei anni. Al Cnipa34 è
attribuito il compito di definire le iniziative atte a migliorare il sistema dei servizi,
accessibile in rete delle pubbliche amministrazioni, ed effettuare controlli di qualità
sulle procedure e sui dati utilizzati per l'emissione delle CNS.
Il quadro normativo vigente ora in Italia, pone regole abbastanza rigide sull’uso
della carta nazionale dei servizi nelle pubbliche amministrazioni. Precisamente
l’articolo 66 comma 3, del D.Lgs. 82/2005 recita:
“…è fissata la data, comunque non successiva al 31 dicembre 2007, a
decorrere dalla quale non è più consentito l’accesso ai servizi erogati
in rete dalle pubbliche amministrazioni, con strumenti diversi dalla
carta d’identità elettronica e dalla carta nazionale dei servizi.” Parte dell’articolo 66 comma 3 del D.Lgs 82/2005
Figura 3.5 Esempio di Carta Nazionale dei Servizi fornita dalla Cnipa.
34 Centro Nazionale per l’informatica nella pubblica amministrazione
3.4 Infrastruttura a chiave pubblica 55
3.4 Infrastruttura a chiave pubblica
Il problema della gestione delle chiavi pubbliche non è stato risolto
completamente, è solo stato rimandato ad un livello più alto, ovvero la CA.
Affidarsi ad una sola CA in tutto il mondo, o una specifica per ogni stato o
nazione non è un idea funzionante. Lì collasserebbe tutto il carico di lavoro, e
potrebbe essere un dannoso punto di rottura del sistema.
Una soluzione possibile sarebbe quella di avere varie CA, tutte gestite dalla
medesima organizzazione, tutte aventi la stessa chiave privata di firma usata per
firmare i certificati. Qui verrebbero risolti i due problemi sovrascritti, ma se ne
introdurrebbe un’ulteriore, ovvero l’importanza della segretezza dell’unica chiave
privata. Se venisse scoperta, l’intera struttura crollerebbe in poco tempo.
Un ulteriore problematica sarebbe la scelta su chi affidare la CA. I candidati più
logici sarebbero il governo, le banche, i contabili o gli avvocati. Sfortunatamente
nessuno di essi suscita un senso di sicurezza totale per tutti i cittadini, quindi è
necessario non avere una singola autorità fidata.
Per questi motivi è stato trovato un metodo differente per certificare le chiavi
pubbliche le firme digitali, e viene comunemente chiamato PKI (public key
infrastructure), infrastruttura a chiave pubblica.
Una infrastruttura a chiave pubblica PKI è una installazione informatica
costituita da applicazioni che utilizzano tecniche crittografiche con chiavi
asimmetriche. Una PKI ha diversi componenti, quali gli utenti, le diverse CA, i
certificati e le directory. La funzione della PKI è quella di fornire la struttura
necessaria ad inserire ed integrare tutte queste componenti, e definire gli standard
da utilizzare per i diversi tipi di documenti e di protocolli.
Una PKI è composta di regola da entità distinte:
Una Registration Authority, RA, incaricata delle formalità amministrative.
Qui è dove formalmente gli utenti si rivolgono per le loro richieste. La RA è
anche incaricata di verificare le credenziali del richiedente, prima di
rilasciare il certificato.
3.4 Infrastruttura a chiave pubblica
56
Una Certificate Authority, CA, incaricata dei compiti tecnici di creazione,
validazione e verifica dei certificati digitali. L'autorità di certificazione è
anche incaricata della firma delle richieste di certificato da parte di utenti
che hanno già la propria chiave pubblica (sigla CSR per Certificate Signing
Request35). Ha inoltre per missione la firma delle liste di revoca (CRL per
Certificate Revocation List).
Un Repository Autority, ovvero l’autorità di stoccaggio, la cui missione è
quella di conservare in sicurezza i certificati.
Una Certificate Management System, il cui compito è quello di garantire
l’intera struttura e il sistema di gestione dei certificati.
Il ruolo dell'infrastruttura di chiavi pubbliche è multiplo e copre soprattutto i
seguenti campi :
Registrare le richieste di chiavi verificando l'identità dei richiedenti.
Generare le coppie di chiavi (chiave privata / chiave pubblica) da utilizzare
per una nuova identità digitale richiesta.
Garantire la confidenzialità delle chiavi private corrispondenti alle chiavi
pubbliche.
Certificare l'associazione tra ogni utente e la sua chiave pubblica.
Generazione di transazioni informatiche riservate.
Emissione e pubblicazione di certificati.
Gestione dei registri dei certificati emessi, e delle liste di sospensione e
revoca.
Revocare le chiavi pubbliche, in caso di perdita da parte del proprietario, di
scadenza della data di validità o di compromissione.
Gestione di sistemi di autorizzazione, autenticazione e identificazione
Altri servizi, come la marcatura temporale dei certificati.
35 Un CSR è fondamentalmente una chiave pubblica che viene generata dall’utente sul proprio server, che contiene le informazioni specifiche del proprio sito e della propria organizzazione, ed inviata alla CA.per la registrazione e certificazione
3.4.1 Strutturazione delle PKI 57
3.4.1 Strutturazione delle PKI
Le diverse PKI esistenti non sono organizzate tutte allo stesso modo al loro
interno. Per quanto riguarda le PKI a livello di impresa, la maggior parte di esse
sono organizzate in maniera gerarchica, creando una catena di certificati che
stabiliscono l’identità delle parti coinvolte. La CA di livello più elevato, denominata
CA root o radice, certifica le CA di secondo livello, denominate anche Regional
Autority, che possano coprire certe determinate regioni geografiche come uno
stato o una regione. Queste a loro volta certificano le vere e proprie CA che
emettono i certificati X509 alle organizzazioni o ai privati. Si crea quindi una
struttura piramidale o ad albero, alla quale tutte le CA coinvolte devono rispettare
il proprio livello assegnato. I livelli dell’albero non sono per forza tre come in
questo caso, ma possono averne anche di più o di meno, in quanto non è stato
stabilito uno standard che stabilisce i vari livelli dell’albero.
Quando la CA radice autorizza una nuova CA regionale, genera un certificato
X509 che ne sancisce l’avvenuta approvazione. Questo include la sua nuova chiave
pubblica da utilizzare, e la firma ufficiale della CA radice. Analogamente quando
un’autorità regionale approva una nuova CA, produce e firma un certificato che
riporta l’avvenuta approvazione, contenente la nuova chiave pubblica per essa.
Grazie a questa gerarchia di certificazione, si può alleggerire il lavoro delle CA
radice che si suppongono fidate, demandando il lavoro ai livelli più bassi
dell’albero. Un utente o un organizzazione che non fosse pienamente sicuro della
veridicità della CA locale, potrebbe risalire la catena di certificati firmati, fino ad
arrivare alla CA root, la quale garantirebbe per tutta la struttura, creando una
catena di fiducia o percorso di certificazione.
I browser moderni contengono al loro interno le chiavi pubbliche di oltre un
centinaio di CA radice, le quali vengono chiamate ancore fiduciarie (trust anchors).
In questo modo si evita di avere una singola autorità radice unica per tutto il
mondo. La scelta su quali ancore affidarsi è quindi lasciata al produttore del
browser, però agli utenti è ovviamente concesso di cancellare dalla lista le CA che
crede siano sospette.
3.4.2 Servizi di directory 58
La struttura gerarchica delle CA non è la sola con la quale vengono organizzate le
PKI. Una struttura alternativa è quella della creazione della già citata rete di
fiducia, utilizzata dove non è necessaria una garanzia estrema come la struttura
gerarchica. Questa organizzazione è basata sull’uso di certificati emessi dalle parti
stesse e garantiti da terze parti. Questi schemi sono conosciuti come GPG (GNU
Privacy Guard) e PGP (Pretty Good Privacy).
Una nuova tipologia di PKI che si sta velocemente sviluppando è la Simple Public
Key Infrastructure (SPKI), nata per passare la rigidità dello standard X509 e la
non perfetta organizzazione della rete di fiducia PGP. La SPKI viene utilizzata per
collegare soggetti direttamente alle chiavi, utilizzando un modello locale di fiducia,
integrando però anche un sistema di autorizzazione ai servizi.
3.4.2 Servizi di directory
Un’altra decisione riguardanti le varie PKI è dove memorizzare i certificati
rilasciati, e delle loro catene di fiducia fino ad un’ancora fiduciaria. Una possibilità
è quella di far memorizzare ad ogni singolo utente il proprio certificato. Questo
metodo è sicuro, in quanto gli utenti non possono modificare il certificato data la
presenza della firma della CA, però in certe situazioni può non essere il massimo
della comodità ed efficienza di prestazioni.
Una proposta alternativa sarebbe quella di usare un server DNS36, cioè il server
preposto ad organizzare i computer in domini ed abbinare i nomi degli utenti o
host in indirizzi IP, utilizzandolo anche come directory dei certificati. Questa
proposta nacque dal fatto che quando un host deve contattarne un altro, deve
cercare il suo indirizzo IP usando un DNS; quindi il DNS potrebbe comunicare al
richiedente, sia l’indirizzo IP del destinatario sia il suo eventuale certificato. Questa
idea in teoria sarebbe molto giusta, ma in pratica non del tutto attuabile, perché in
questo modo si appesantirebbe non poco il lavoro dei DNS.
Alcune PKI quindi sono strutturate con uno specifico directory server dedicato
alla gestione dei certificati X509. Soprattutto le PKI a livello di impresa sono 36 Domain Name Server
3.4.3 Liste dei certificati revocati 59
spesso strettamente legate ai servizi di directory dell'azienda che offrono servizi di
ricerca, in cui la chiave pubblica incorporata in un certificato di ogni dipendente,
può essere memorizzata assieme ad altri dettagli personali, come numero di
telefono, indirizzo e-mail, dipartimento. Oggi la principale tecnologia per i sistemi
di directory è un server LDAP, e infatti lo standard X.509 nasce con il predecessore
di LDAP, ovvero lo standard X.500.
3.4.3 Liste dei certificati revocati
Il problema della revoca dei documenti personali di identità esiste come nel
mondo reale anche in quello digitale. L’autorità che ha emesso un certificato
digitale può decidere di revocarlo, se il proprietario ne ha abusato in qualche modo,
se è stata persa o intercettata la chiave privata associata, o per altri motivi di
primaria importanza. Per fare ciò, ogni CA emette periodicamente una lista
contenente i numeri seriali dei certificati revocati, la CRL (Certificate Revocation
List). Il metodo più comune utilizzato dalle varie CA per operare con le CRL,
consiste nel pubblicare occasionalmente una lista principale dei certificati revocati,
ed aggiornare questa molto frequentemente. Questa tecnica permette di ridurre il
carico di banda necessario a distribuire le CRL.
Le applicazioni invece non possono adottare la stessa tecnica , ovvero scaricare
periodicamente la lista di tutti i certificati revocati, perché il traffico sulla rete
diventerebbe presto insostenibile. Per questo viene introdotto lo specifico
protocollo OCSP (Online Certificate Status Protocol), secondo il quale in tempo
reale, un applicazione al momento della verifica del certificato emesso da una CA
nota, chiede alla stessa se il numero seriale di quel certificato è stato revocato o no.
L’introduzione delle CRL porta vantaggi riscontrabili in termini di sicurezza, ma
causa quindi anche una serie di svantaggi in termine di comodità. Un’altra
complicazione deriva dal fatto che un certificato potrebbe anche essere reintegrato
nella rete. La gestione della revoca con le CRL toglie in parte una delle migliori
proprietà dei certificati, ovvero la possibilità di essere utilizzati senza contattare le
CA, però la loro introduzione è indispensabile per un buon livello di sicurezza.
Capitolo 4
Il servizio di autenticazione
centralizzata : CAS
Il servizio di autenticazione centralizzata, Central Authentication Service CAS,
permette di realizzare un sistema di autenticazione unica, Single Sign On (SSO), tra
applicazioni basate su interfaccia web o mail server, per mezzo di ticket di
autenticazione. Le applicazioni demandano il problema dell’autenticazione al
server centrale CAS, senza più preoccuparsi dei vari problemi di identificazione
dell’utente.
L'utente dovrà autenticarsi una sola volta, ad esempio con username e password,
o con l’invio di un certificato digitale, e da quel momento in poi potrà utilizzare
tutte le applicazioni fornite del sistema, senza doversi autenticare nuovamente,
finché la sessione è valida. I motivi che portano alla scelta di un’architettura di
questo tipo sono la sicurezza e la convenienza, in quanto gli utenti devono fare
4 Il servizio di autenticazione centralizzata: CAS
62
molto meno perdendo anche meno tempo, e le applicazioni sono protette dal server
centrale fidato.
CAS fu creato inizialmente come progetto open source dal gruppo Information
Tecnology Services (ITS) della Yale Universities 37, e successivamente nel
dicembre 2004 divenne un progetto JA-SIG, sempre in cooperazione con Yale e
con la Reutgers Universities. È utilizzato da molte università americane ed europee
integrando i sistemi di autenticazione preesistenti basati su LDAP o Kerberos.
Il sistema CAS è multipiattaforma, dato che il server è implementato su servlet
java38, e può essere eseguito su di un servlet engine, seguendo le specifiche JSP39
versione 1.2. Le librerie per il server applicativo sono inoltre disponibili per vari
linguaggi di sviluppo o anche di scripting, come JAVA, JSP, Perl, PHP, ASP,
PL/SQL, Python.
Figura 4.1 Esempio di autenticazione distribuita prima e dopo l’introduzione di CAS
37 http://www.yale.edu/ 38 Una servlet è un piccolo programma scritto in linguaggio Java, eseguito in un server web. Operano all'interno di un applicazione server e potenziano le sue funzionalità. http://java.sun.com/products/servlet/ 39 JavaServer Pages, è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o XML.
4.1 Strutturazione del sistema CAS
63
4.1 Strutturazione del sistema CAS
Il sistema CAS nella sua forma più generale è composto principalmente da tre
diverse componenti:
Il server CAS centrale
Un server applicativo che fornisce un servizio
Un cliente utente, che intende accedere al servizio applicativo, solitamente
tramite un browser web.
Alle volte a queste tre componenti se ne può aggiungere una quarta, negli
specifici casi in cui un ulteriore applicazione deve autenticarsi impersonificando
l’utente vero e proprio. Questa modalità di funzionamento è detta modalità proxy.
Il server CAS centrale è il componente preposto all’identificazione dell’utente,
nonché il software che deve gestire una corretta e soprattutto sicura autenticazione.
Il software e tutte le sue librerie server vengono installate e configurate su di un
web server come Apache Tomcat40, che utilizzi il protocollo HTTP41 e HTTPS42.
Il server applicativo invece è una qualsiasi risorsa o servizio web-based, o una
qualsiasi interfaccia web, che utilizzi anch’essa i protocolli HTTP o HTTPS, sul
quale devono essere installate specifiche librerie CAS, apposite per le applicazioni.
Queste applicazioni che utilizzano il meccanismo di autenticazione proprio del
CAS, vengono chiamate “CAS-ifyed”.
Il client utente o semplicemente l’utente, è il soggetto che intende accedere ai
servizi del server applicativo, solitamente tramite un browser web. Per una
configurazione ottimale, il browser dell’utente dovrebbe aver abilitato i cookie43 e i
redirect Javascript44, anche se questa configurazione non è strettamente
necessaria per un corretto funzionamento del sistema CAS.
40 http://tomcat.apache.org/ 41 L'Hypertext Transfer Protocol (HTTP) è il protocollo di trasferimento per un ipertesto usato come principale sistema per la trasmissione di informazioni sul web. http://it.wikipedia.org/wiki/Hypertext_Transfer_Protocol 42 L'Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) è il risultato dell'applicazione di un protocollo di crittografia asimmetrica al protocollo di trasferimento di ipertesti HTTP. 43 Un cookie HTTP è un piccolo file creato da un server web visitato, e viene utilizzato per memorizzare informazioni all'interno del proprio computer. http://support.mozilla.com/it/kb/Gestione dei cookie 44 Attraverso il redirect è possibile inoltrare le visite di un sito web verso un altro sito web senza che l'utente se ne accorga. Questi vengono scritti in Javascript ed eseguiti automaticamente nei browser web.
4.2 Caratteristiche di CAS
64
4.2 Caratteristiche di CAS
Il CAS fornisce un sistema in SSO basato su di un protocollo aperto e ben
documentato. È dotato di un componente server Java open source e dispone di una
buona documentazione e soprattutto di una vasta comunità di sviluppatori.
Gli scopi principali del server CAS sono:
Facilitare l’autenticazione centralizzata SSO per più applicazioni comuni.
Semplificare la procedura stessa di autenticazione
Consentire un autenticazione sicura agli utenti, senza che questi debbano
rivelare le proprie credenziali ai servizi e agli applicativi ogni volta.
Le caratteristiche migliori del sistema CAS sono sicurezza, affidabilità, flessibilità.
La sicurezza dell’intero sistema risulta notevolmente rafforzata, utilizzando i
meccanismi di CAS. Infatti per l’intero ciclo di autenticazione, le credenziali
dell’utente viaggiano solo una volta tra il browser dell’utente ed il server, e su di un
canale protetto e crittografato SSL. Durante l’autenticazione, il server CAS cerca di
salvare nel browser dell’utente uno speciale cookie privato: il Ticket Granting
Cookie, TGS. Questo non contiene nessun tipo di dato confidenziale, per questo
viene denominato opaco, ma contiene solamente un identificativo di sessione noto
al CAS. Transita sulla rete in chiaro senza protezione, ma solo il CAS può leggerlo o
scriverlo. Il ticket ha comunque un tempo di vita relativamente breve, e viene
cancellato definitivamente alla chiusura del browser da parte dell’ utente.
Questo speciale ticket, serve come garanzia di già avvenuta autenticazione,
qualora l’utente intenda accedere ad un'altra applicazione del sistema. In questo
modo l’utente in tutta trasparenza non deve re autenticarsi ogni volta che cambia il
servizio applicativo richiesto.
Le applicazioni invece non comunicano attraverso il ticket TGT, ma attraverso
altri ticket appositi, detti Service Ticket, ST. Anch’essi sono opachi, non
contenendo informazioni personali, e possono essere utilizzati solo una volta (one
time ticket). Il ST viene emesso dal server CAS verso l’utente, il quale in modo
automatico lo passa al servizio applicativo. Questi lo ridirige di nuovo verso il CAS
per confermare l’identità dell’utente, chiudendo il ciclo di autenticazione.
4.2 Caratteristiche di CAS
65
Per quanto riguarda la flessibilità, nel pacchetto software che costituisce il server
CAS sono comprese tutte le funzionalità per la una corretta gestione del suo
protocollo. Invece la procedura che verifica l’identità dell’utente è lasciata
completamente allo sviluppatore, garantendogli una notevole libertà di scelta su
come adattare il server ai propri meccanismi di autenticazione locale, tramite
plugin45 per un Database relazionale, un server LDAP, certificati X509, semplici
file di testo protetti da password, o anche una combinazione di questi impostando
una scala di priorità da seguire. Inoltre i plugin possono essere estesi per gestire
meccanismi già esistenti come Kerberos o Active Directory46 (AD). Per questo sono
disponibili varie librerie di sistema, con le quali lo sviluppatore può interfacciare il
server CAS con il metodo di autenticazione da lui preferito.
Figura 4.2 Esempi di plugin di autenticazione per CAS
45 Software che interagisce con un altro software per ampliarne le funzioni. http://it.wikipedia.org/wiki/Plugin_(informatica) 46 Active Directory è un insieme di servizi di rete che implementano un servizio di directory. http://it.wikipedia.org/wiki/Directory_service
4.2 Caratteristiche di CAS
66
Anche l’affidabilità del servizio offerto dal CAS è molto alta. È possibile
configurare anche il server applicativo sul quale è installato CAS, per garantire un
affidabilità ancora più elevata. Per questo le librerie client e server sono in continua
crescita, per ridurre i difetti ed ottimizzare il codice su ogni piattaforma.
Un'altra peculiarità del CAS è il suo possibile uso in modalità Proxy. Un proxy è
un servizio, che a sua volta deve impersonare un utente autenticandosi su altri
Servizi. Questa modalità è stata introdotta con la seconda versione di CAS, perché
in generale in un sistema SSO non si dovrebbe limitare solamente ad
un’autenticazione diretta tra un client ed un server, ma a volte coinvolgendo una
terza parte. Per esempio un servizio interpellato da un utente potrebbe dover
contattare un altro servizio back-end47, o utilizzando un portale48, l’utente
autenticato avrebbe la necessità di interrogare un applicazione esterna.
Questi sistemi terzi quindi devono a loro volta poter identificare l’utente, e non
sarebbe ovviamente ne saggio ne comodo reinviare a questi le credenziali personali
dell’utente per identificarlo. Per questo il server CAS permette l’utilizzo di speciali
ticket per questa modalità, chiamati Proxy Garantig Ticket, PGT. Questi
permettono un autenticazione sicura su applicazioni terze, garantendo a queste
l’identità dell’utente.
Rispetto ad un normale sistema SSO, il CAS ha inoltre delle caratteristiche
specifiche. Le comunicazioni tra client e server, e tra server centrale e applicativo,
viaggiano tutte sul protocollo protetto HTTPS, e vengono utilizzati solamente i
certificati digitali generati e gestiti dalla CA specificata all’interno della
configurazione del server CAS centrale. Questi due aspetti contribuiscono a una
doppia sicurezza: le comunicazioni sono crittografate e riservate, e l’identità dei
soggetti è garantita. Gestendo i certificati digitali in modo centralizzato, è quindi
possibile creare un’infrastruttura a chiave pubblica interna e locale.
47 Service che accetta credenziali proxied ossia autenticazione da un proxy. 48 Un portale è un sito web che costituisce il punto di ingresso a un insieme di risorse o servizi. È una porta privilegiata che un utente attraversa per entrare in una comunità: un’azienda, un'Università, una rete sociale.
4.3 Schemi di funzionamento di CAS
67
4.3 Schemi di funzionamento di CAS
Il server CAS può essere utilizzato in due modalità:
Modalità diretta
Modalità Proxy
La modalità diretta è quella nata e pensata fin dalla prima versione del CAS, dove
vi è un tentativo di autenticazione diretta da parte dell’utente verso il CAS.
La modalità proxy fu introdotta nella seconda versione del sistema CAS, e
permette l’autenticazione su più livelli, ovvero tramite proxy. Questa funzionalità
permette di accedere ad una applicazione remota utilizzando le stesse credenziali
presentate dall’utente al sistema di autenticazione, agendo come client per conto
dello stesso.
4.3.1 Funzionamento di CAS in modalità diretta
Questo schema di funzionamento non prevede terze parti nel sistema, e viene
attivata nel momento in cui un utente tramite browser, cerca di accedere ad un
servizio applicativo la cui autenticazione è gestita dal CAS. Questa è la richiesta
iniziale [1a]. Il server applicativo rimanda l’utente alla pagina di login del server
CAS, [1b], tramite connessione sicura HTTPS, passando come parametro
aggiuntivo l’URL dell’applicazione richiesta.
Il CAS chiede all’ utente che gli vengano fornite le sue credenziali, tramite la
relativa form di autenticazione o tramite l’invio automatico del certificato digitale
utente, se disponibile. Queste vengono controllate e verificate nel passo [2], con il
servizio di autenticazione scelto, LDAP in questo caso. Tutte le comunicazioni tra
utente e server CAS passano attraverso un canale SSL sicuro e crittografato. Se
l’autenticazione non ha avuto successo verrà visualizzato un opportuno messaggio
contenente l’errore ottenuto, come nome utente o password incorretti, e l’utente
non avrà accesso al servizio. In caso invece di autenticazione avvenuta, l’utente
viene ridiretto automaticamente all’applicazione richiesta [3], appendendo però
4.3.1 Funzionamento di CAS in modalità diretta
68
all'URL di redirezione un ticket, chiamato service ticket (ST), sotto forma di una
lunga stringa alfanumerica. Questo ticket serve per indicare che l’utente ha
eseguito correttamente l’autenticazione, e richiesto quella specifica applicazione.
Infatti il server CAS nel momento in cui verifica le credenziali dell’utente, prende
anche nota del servizio da lui richiesto, così da associare al ticket stesso, il nome
dell’utente e il servizio richiesto. Il service ticket è utilizzabile una sola volta, ed
invalidato non appena utilizzato.
Inoltre il CAS cerca di salvare nel browser dell’utente un cookie, il Ticket
Granting Cookie (TGC) valido per la sessione globale, ed eliminato
automaticamente dopo un intervallo di tempo o dopo la chiusura del browser
stesso. Questo meccanismo permette di identificare l’utente senza doversi
riautenticare, nel caso in cui questi richiedesse di accedere ad un'altra applicazione
del sistema, implementando quindi la tecnica del SSO.
A questo punto l'applicazione richiamata dall'utente, verifica se il service ticket
passatogli dal browser utente sia corretto, tramite una comunicazione protetta
HTTPS con il server CAS (passo [4]). Il server CAS controlla che il ticket inviatogli
dall’applicazione sia valido e associato allo stesso servizio richiesto, dopodiché se la
validazione ha successo, viene restituito al chiamante il nome utente. A questo
punto l’applicazione è sicura dell’identità dichiarata dell’utente, e può procedere
nella propria comunicazione con esso, chiudendo di fatto il ciclo di autenticazione.
L’annullamento della sessione globale può essere eseguita semplicemente
accedendo alla pagina di logout del server CAS. Questa non farà altro che eliminare
il cookie TGC. Altrimenti questo viene annullato automaticamente alla chiusura del
briose da parte dell’utente, oppure dopo un intervallo temporale di circa un’ora.
Utilizzando una metodologia di autenticazione come questa, l’utente ha un grado
di sicurezza molto elevato, infatti le proprie credenziali hanno viaggiato sulla rete
solo una volta in tutto il ciclo di autenticazione, peraltro su un canale sicuro.
Inoltre le applicazioni sono completamente trasparenti, infatti l’identificazione ad
esse è basata su ticket opachi non contenenti ne le credenziali utente ne
informazioni riservate.
Oltre a ciò anche le reautenticazioni seguenti vengono affrontate in maniera
efficace, se l’utente aveva precedentemente accettato il cookie TGC: al momento di
4.3.1 Funzionamento di CAS in modalità diretta
69
una richiesta di un nuovo servizio applicativo, non vedendo un ticket ST valido,
rimanderà l’utente al server CAS. Questi leggendo il cookie TGC riconoscerà
automaticamente l’utente e la sua sessione attiva, quindi creerà per esso un nuovo
ticket ST specifico per il nuovo servizio, il tutto in modo completamente
trasparente all’utente.
La figura 4.3 mostra uno schema di autenticazione per questa modalità.
Figura 4.3 Schema di autenticazione CAS in modalità diretta.
4.3.2 Funzionamento di CAS in modalità proxy
70
4.3.2 Funzionamento di CAS in modalità proxy
Gli sviluppatori di CAS a Yale hanno pensato di introdurre nella versione 2.0
alcune nuove caratteristiche tra le quali la possibilità di sviluppare una applicativo
proxy e su più livelli detta anche multitier49, restando però compatibile con la
versione precedente. Questa modalità, detta anche di tipo CAS-proxy, è necessaria
quando un'applicazione deve fare le veci di qualcun'altro (un utente o un'altra
applicazione) nell'autenticazione, cioè essa stessa deve autenticarsi su di un'altra
applicazione impersonificando un utente. Un tipico esempio nel quale è necessario
un meccanismo di questo tipo è un applicazione webmail in un sistema in SSO.
L'utente si autenticherà tramite CAS, e accederà poi a webmail essendosi già
autenticato. Questa applicazione però dovrà collegarsi al server IMAP50 della posta
per poterla leggere, facendo quindi le veci dell'utente.
Per un corretto funzionamenti di questa modalità è necessario introdurre tre
ulteriori tipologie di ticket, oltre ai già noti ticket TGC e ST:
Proxy-granting ticket (PGT): è un ticket mandato dal Server CAS ad una
applicazione in possesso di un ticket ST valido, associato al singolo utente e
a quella determinata applicazione. Conferisce a questa il permesso di
richiedere dei proxy-ticket (PT), diventando di fatto un Proxy.
Proxy-granting ticket IOU (PGTIOU): è un ticket mandato dal Server CAS
durante il processo di validazione tra CAS e Proxy, insieme a un PGT. Il
proxy ha il compito di gestire una tabella che correli i ticket PGTIOU e PGT.
Proxy ticket (PT): è un ticket utilizzabile da un proxy per accedere ad una
applicazione esterna impersonando l’utente. Un ticket PT identifica il proxy
o la catena di Proxy che hanno richiesto l'autenticazione al servizio esterno,
infatti, dato che questo è un meccanismo riproducibile a catena, un PT può
essere utilizzato da altri proxy per ottenere a sua volta un PGT. Viene inoltre
conservata una traccia della catena di proxy, cioè del percorso di
autenticazione, tra l'utente e applicazione esterna finale.
49 http://en.wikipedia.org/wiki/Multitier_architecture 50 Un server IMAP e il server a cui un client di posta elettronica si collega per scaricare la posta.
4.3.2 Funzionamento di CAS in modalità proxy
71
Il funzionamento di CAS in versione proxy, è analogo alla modalità diretto fino al
passo [4]. Su richiesta dell’applicazione, il server CAS fornisce un elemento
aggiuntivo nella comunicazione in formato XML [5], un ticket PGTIOU.
Questo è un valore identificativo con cui è indicizzato il corrispondente PGT, il
Proxy Granting Ticket, che viene creato dal server CAS. Il PGT viene quindi
trasmesso [5] al server proxy, insieme al corrispondente PGTIOU. Questa
comunicazione è protetta tramite un canale SSL, utilizzando i certificati digitali dei
due server, che devono essere opportunamente installati, per garantire la
segretezza del PGT. Questo tipo di comunicazione è necessaria anche per garantire
a ciascuna delle due controparti, CAS server e proxy server, l'identità dell'altra,
realizzando una mutua autenticazione, in un modo semplice e funzionale. Il PGT
viene memorizzato autonomamente, e mappato al PGTIOU dal servizio proxy per
usarlo successivamente. Il PGT permette infatti al proxy di richiedere, anche più
volte, dei Proxy Ticket PT, tramite i quali può impersonificare l’utente alla specifica
applicazione web richiesta. Infatti un ticket PGT è legato ad un utente, ad un proxy
e a più servizi applicativi, mentre un ticket PT è legato ad un utente, ad un proxy e
ad un servizio applicativo specifico, e può essere utilizzato una sola volta.
A questo punto quindi il proxy ha bisogno del ticket PT associato all’applicazione
web nella quale deve impersonificare l’utente: questo viene richiesto al server CAS
nel passo [6a] attraverso una comunicazione HTTPS, passando come parametro il
ticket PGT ed il servizio di destinazione. Il server CAS vede questa richiesta,
verifica la validità del PGT, genera il PT richiesto, e lo spedisce al proxy ([6b]).
Il server proxy può ora quindi comunicare questo PT all’applicazione che intende
utilizzare [7], nelle stesse modalità in cui il browser dell'utente si collega con un
servizio applicativo nel funzionamento diretto.
A sua volta il servizio verifica il PT comunicando in HTTPS con il server CAS [8a],
mandando come argomenti il suo ID di servizio e il PT, ottenendo come risposta
[8b] l'Username dell'utente autenticato e la traccia della catena dei proxy coinvolti,
se ovviamente il PT è valido. Il Target può inoltre decidere, alla luce di questi dati,
come e se dare accesso al Proxy, e procedere come più opportuno.
4.3.2 Funzionamento di CAS in modalità proxy
72
Figura 4.4 Schema di autenticazione CAS in modalità proxy
Questo meccanismo di autenticazione può ripetere il ciclo più volte secondo le
necessità, concedendo alle stesse applicazioni web il potere di autenticarsi come
l'utente comunicando con altre applicazioni, in una catena di proxy.
Figura 4.5 Catena di autenticazione tramite proxy
4.4.1 Limitazioni di CAS nelle versioni 1 e 2 73
4.4 La versione 3 del server CAS
La terza versione del server CAS non introduce una nuova metodologia di
autenticazione o una nuova modalità di funzionamento, bensì è stata sviluppata
per superare alcune limitazioni delle precedenti versioni risolvendo anche alcuni
dei loro bug, integrare nuove specifiche funzionalità per rimanere al passo coi
tempi, cercando quindi di restare un sistema di autenticazione centralizzata
all’avanguardia, ed ovviamente rimanere comunque compatibile all’indietro con le
due precedenti versioni.
4.4.1 Limitazioni di CAS nelle versioni 1 e 2
La più grande limitazione del sistema CAS fino all’introduzione della terza
versione è quella di non fornire alle applicazioni informazioni sull'utente
riguardanti l'autorizzazione. Infatti fu progettato per realizzare solo un sistema di
autenticazione e l'unico dato disponibile è il nome univoco dell’utente. Per alcune
applicazioni è indispensabile avere a disposizione i dati degli utenti, ad esempio
nome, cognome, numero di matricola per gli studenti o codice identificativo per i
dipendenti, facoltà, o altri dati anagrafici, quindi in questi casi né la versione 1 né la
2 di CAS sembrano la scelta più appropriata.
Un altro limite nella seconda versione del server CAS sta nella gestione dei server
che si autenticano in modalità proxy. La configurazione avviene a livello di rete
(firewall) e a livello di Certification Authority, ma una volta generati e configurati i
certificati per i server coinvolti, il sistema CAS non ha un controllo diretto su quali
server possono accedere alla catena di autenticazione, in che modalità, o revocare
l'autorizzazione a operare.
Un ulteriore difficoltà nello sviluppo del server CAS 2, sta nell’organizzazione e
strutturazione del codice sorgente: questo è intessuto dentro le servlet, e non è
perfettamente organizzato secondo un modello di dominio chiaro e ben strutturato.
Tutto questo porta ad avere difficoltà tra i vari sviluppatori al momento di
4.4.2 CAS 3 74
apportare modifiche al codice, problema non da poco quando si parla dello
sviluppo di un software per la sicurezza come questo. Inoltre l'interfaccia del server
CAS nelle versioni 1 e 2 non sono multilingua, e per personalizzarle è necessario
intervenire direttamente sul codice JSP.
Infine il server CAS non è predisposto per il controllo della scadenza della
password. Non viene né mostrato alcun avvertimento in tal senso, né bloccato
l'ingresso all'utente. Purtroppo questa funzionalità non è ancora stata introdotta
nella terza versione del CAS, e sarà uno degli argomenti principali nella descrizione
delle attività svolte in questo progetto di tesi.
4.4.2 CAS 3
Gli obbiettivi del CAS 3 furono quindi superare i limiti intrinsechi dei precedenti
sistemi, definire un ben preciso modello di dominio sfruttando le tecniche
dell’ingegneria del software, implementare un architettura software moderna, di
facile modifica e sviluppo, personalizzabile dall’utente senza stravolgere l’intero
sistema, ed ovviamente compatibile con i suoi due predecessori.
Con l’introduzione della nuova terza versione di CAS, alcuni limiti delle
precedenti versioni sono stati superati. Innanzitutto il sistema può ora fornire alle
applicazioni informazioni sull'utente, permettendo a queste di poter gestire
direttamente e autonomamente i vari permessi utente di autorizzazione.
È migliorato quindi il controllo sull'autorizzazione delle applicazioni e reso più
granulare, ad esempio quali servizi possono contattare CAS, quali funzionalità
possono sfruttare, e quali attributi dell'utente possono essere visti.
Vengono supportate inoltre nuove metodologie di autenticazione, come SAML51 2.0
per l'integrazione con Google Accounts52, e per Shibboleth. Quest’ultimo è un
progetto inter-universitario volto a sviluppare una soluzione open source che
51 Security Assertion Markup Language (SAML) è uno standard informatico per lo scambio di dati di autenticazione e autorizzazione tra domini di sicurezza distinti. 52 http://www.ja-sig.org/wiki/display/CASUM/SAML+2.0+(Google+Accounts+Integration)
4.5 Valutazioni sull’uso di CAS 75
consenta alle organizzazioni lo scambio di informazioni sui propri utenti, in modo
sicuro e rispettoso della privacy, basandosi sul protocollo SAML.
L’interfaccia web è stata notevolmente migliorata soprattutto graficamente e
nella gestione degli eventuali errori, rendendola inoltre multilingua.
Infine il codice dell'applicazione CAS è stato riscritto basandosi sull'architettura
Spring53, un framework opensource per lo sviluppo di applicazioni su piattaforma
Java che è stato largamente riconosciuto all'interno della comunità Java quale
valida alternativa al modello basato su Enterprise JavaBeans54 (EJB). Rispetto a
quest'ultimo, il framework Spring lascia una maggiore libertà al programmatore
fornendo allo stesso tempo un'ampia e ben documentata gamma di soluzioni
semplici adatte alle problematiche più comuni.
4.5 Valutazioni sull’uso di CAS
Il sistema CAS è un buon sistema di autenticazione, mentre per quanto riguarda
le politiche di autorizzazione ancora non si è raggiunto un livello di qualità
eccezionale. In effetti, è prassi utilizzare CAS in combinazione con un directory
server in cui sono censite sia le identità degli utenti che i ruoli assegnati, tuttavia è
responsabilità di ogni singola applicazione connettersi alla directory per accedere
al profilo dell’utente e quindi applicare le dovute policy.
Per quanto riguarda l’autenticazione invece il sistema affronta il problema con
standard di qualità molto elevati. Infatti Le password passano solo attraverso il
browser e il server CAS attraverso un canale dati sicuro e cifrato, e le identificazioni
successive avvengono per mezzo di ticket opachi inviati in chiaro. L’applicazione
non entra mai in contatto con la password in transito sulla rete, e questo è
probabilmente il più grande vantaggio usando il sistema CAS.
Notare inoltre che non è strettamente necessario implementare meccanismi di
crittografia sul transito in rete dei ticket, in quanto questi ultimi hanno validità per
Sono stati inseriti con successo nella cartella: /cas-server-core/src/main/java/org/jasig/cas
Il file :
login-webflow.xml
È stato inserito con successo nella cartella: /cas-server-webapp/src/main/webapp/WEB-INF
L’installazione procede con varie modifiche a questi file e ai file di configurazione
del server CAS. 57 Tutti i file relativi a questa configurazione specifica di CAS sono disponibili all’indirizzo: http://www.ja-sig.org/wiki/spaces/listattachmentsforspace.action?key=CAS&fileExtension=&sortBy=date
6.3.3 Modifiche ai file sorgenti Java di CAS 92
6.3.3 Modifiche ai file sorgenti Java di CAS
Tutte le modifiche effettuate sono necessarie per poter integrare le nuove
funzionalità nel sistema CAS dell’Università. Il file Java più soggetto a modifiche è
stato il “ExtendedLdapAccountStatusGetter.java”.
La configurazione originale, prevedeva solamente la ricerca di un solo attributo
dal server LDAP: ‘statusAttributeName’. Questo attributo serve a specificare il
giorno di scadenza dell’account utente, e sul server LDAP è l’equivalente
dell’attributo ‘ShadowExpire’. Questo però non è sufficiente agli scopi desiderati,
in quanto su LDAP è necessario ricercare anche l’attributo ‘ShadowLastChange’.
Si è quindi dichiarato un nuovo attributo ‘lastchangeAttributeName’, e
modificato internamente alcune funzioni della classe.
Una di queste è la funzione pubblica:
public []String resolveFromLDAP(String lookupAttributeValue)
Questa funzione prende come parametro di ingresso una stringa contenente il
nome dell’utente, ed è stata modificata internamente per avere come valore di
ritorno un array di stringhe contenente gli attributi speciali ricercati sul server
LDAP. Inizialmente dagli sviluppatori questa funzione era stata pensata per aver
come valore di ritorno un solo parametro stringa, ma questo non era sufficiente in
quanto i parametri da ricercare sul server LPAD sono più di uno.
Questa la definizione completa della funzione suddetta:
private String[] resolveFromLDAP(final String lookupAttributeValue) { // Modifiche effettuate: Valore di ritorno da String a String[] final String searchFilter = LdapUtils.getFilterWithValues(this.filter,lookupAttributeValue); if (this.logger.isDebugEnabled()) { this.logger.info("LDAP: starting search for value='" + lookupAttributeValue + "'" + "with searchFilter '" + searchFilter + "'"); } try { // searching the directory AttributesMapper mapper = new AttributesMapper(){ public Object mapFromAttributes(final Attributes attrs) throws NamingException { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: trying to map attribute '" + ExtendedLdapAccountStatusGetter.this.statusAttributeName+
6.3.3 Modifiche ai file sorgenti Java di CAS
93
"' and '" + ExtendedLdapAccountStatusGetter.this.lastchangeAttributeName+ "' from result."); int attributessize = attrs.size(); ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found "+ attributessize +" attributes as result, starting to resolve..."); final Attribute attribute = attrs.get(ExtendedLdapAccountStatusGetter.this.statusAttributeN ame); // Modifiche effettuate : Aggiunta parametro attribute1 final Attribute attribute1 = attrs.get(ExtendedLdapAccountStatusGetter.this.lastchangeAttributeN ame); if (attribute == null) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: attribute was null in result."); return null; } // Modifiche effettuate : Aggiunto eventuale debug per il parametro // attribute1 if (attribute1 == null) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: attribute1 was null in result."); return null; } if (ExtendedLdapAccountStatusGetter.this.logger.isDebugEnabled()) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found attribute in result, value='" + attribute.get() + "'"); // Modifiche effettuate : Aggiunto debug per il parametro attribute1 ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found attribute1 in result, value='" + attribute1.get() + "'"); } // Modifiche effettuate : Modificato Il valore di ritorno del nuovo // oggetto mapper: Da stringa ad array di due stringhe String[] attributi = {(String) attribute.get(), (String) attribute1.get()}; return attributi; } // Fine if }; // Fine definizione oggetto mapper // Chiamata effettiva della search() al server Ldap final List resultList = this.ldapTemplate.search( this.searchBase, searchFilter, getSearchControls(), mapper); if (resultList.isEmpty()) { this.logger.warn("No result was found for: " + lookupAttributeValue); return null; } if (resultList.size() > 1) { this.logger.error("LDAP: search returned multiple results" + " for value='" + lookupAttributeValue + "'" + " which is not allowed."); return null; } // Modificato il valore di ritorno per la funzione resolveFromLDAP() : // Array di stringhe contenente i due parametri ritornati da Ldap al // posto di un unica stringa return (String[]) resultList.get(0);
Un'altra funzione pubblica sempre della medesima classe, modificata molto
ingentemente è la funzione:
‘public int getStatus(String userID)’.
Questa funzione prende come parametro di ingresso la stringa contenente il nome
utente in fase di autenticazione, e ritorna un numero intero codificante lo stato
attuale dell’account utente. Può quindi essere considerata una delle funzioni di
maggior rilevanza di tutto il pacchetto software integrato, perché appunto in essa
avvengono la maggior parte dei controlli relativi alle decisioni da prendere.
Dopo aver risolto la ricerca su LDAP avvalendosi della funzione descritta
precedentemente, utilizza i due58 attributi speciali ritornatigli, in modo da gestire
correttamente tutti i casi che si possono presentare.
Questa è la parte di codice sorgente Java relativa a questa funzione:
public int getStatus(String userID) { this.logger.debug("lookup for userID='" + userID + "'"); // Modifica effettaute: ldapResult da String a String[] String[] ldapResult=resolveFromLDAP(userID); this.logger.debug("LdapResult='" + ldapResult[0] + "' and '" + ldapResult[1] + "'"); // Modifiche effettaute: inizializzazione delle variabili shadowexpire e // shadowlastchange necessarie per i calcoli int shadowexpire = Integer.parseInt (ldapResult[0]); int shadowlastchange = Integer.parseInt (ldapResult[1]); // Modifiche effettuate: Calcolo del currentday int currentday = (int)Math.round(System.currentTimeMillis()/86400000); // Stampa delle info dei risultati ottenuti this.logger.info("Currentday -> "+ currentday ); this.logger.info("Shadowexpire -> "+ ldapResult[0] );
58 In realtà gli attributi da ricercare sarebbero cinque; però, per gli attributi ‘ShadowWarning’, ‘Shadow-Inactive’ e ‘ShadowMax’ del server Ldap, essendo gli stessi per ogni account, rispettivamente 20, 20 e 180, si è optato per il settaggio diretto all’interno del file “deployerConfigContext.xml”, invece di ricercarli ogni volta sul server Ldap
6.3.3 Modifiche ai file sorgenti Java di CAS
95
this.logger.info("Shadowlastchange -> "+ ldapResult[1] ); this.logger.info("Shadowlastchange + DaysTillLocked -> "+ (shadowlastchange + daysTillLocked) ); this.logger.info("Shadowlastchange + DaysTillLocked + WarningDays-> "+ (shadowlastchange + daysTillLocked + warningDays) ); // Switch della variabile shadowexpire per il calcolo dello stato account // dell'utente switch (shadowexpire) { case -2: return STATUS_BLOCKED; case -1: return STATUS_ACTIVATE; case 65536: return STATUS_ACTIVE; default: if (shadowexpire < currentday) { return STATUS_LOCKED; // L'account è scaduto } else { if (shadowlastchange + daysTillLocked + warningDays < currentday) { return STATUS_LOCKED; // L'account è scaduto Non è stata cambiata la password da troppo tempo } else if (shadowlastchange + daysTillLocked - warningDays < currentday) { return STATUS_CHANGEPWD; // L'account è nel periodo di 40 gg nel quale è possibile cambiare la // password } else { return STATUS_ACTIVE; // L'account è attivo } } // Fine Switch }
Le modifiche apportate a questa funzione sono state necessarie per gestire
correttamente le varie situazioni che potevano presentarsi.
Dopo aver risolto la ricerca sul server LDAP grazie alla chiamata alla funzione
‘resolveFromLdap(…)’ dei due attributi citati, viene calcolato il giorno corrente,
ed effettuato uno ‘switch’ della variabile ‘shadowexpire’ corrispondente alla
variabile ‘statusAttributeName’ della classe stessa, settata direttamente
dall’amministratore del sistema.
Questo ‘switch’ controlla inizialmente che l’amministratore non abbia deciso di
bloccare l’account utente o che vi sia stata data validità illimitata. Questo viene
fatto direttamente sul server LDAP settando opportunamente i parametri relativi
all’attributo ShadowExpire.
6.3.4 Modifiche ai file di configurazione di CAS 96
Altrimenti se questo parametro non trova la giusta corrispondenza nello ‘switch’,
si entra nel caso di default, dove viene effettuata una serie di ‘if-else’ per il controllo
del secondo parametro ‘shadowlastchange’ corrispondente alla variabile della
classe ‘lastchangeAttributeName’.
Questo viene opportunamente combinato con gli altri due parametri
‘daysTillLocked’ e ‘warningDays’ settati da file, e confrontato con il giorno
corrente.
In ogni caso si avrà come valore di ritorno di questa funzione un numero intero
specificante l’attuale stato dell’account utente. Ne risulta che questo potrà essere
scaduto, oppure che sia nel periodo di 40 giorni nel quale viene ricordato di
cambiare la password, oppure semplicemente che sia attivo.
Vale la pena notare che le variazioni qui introdotte nei file sorgenti Java, non
intaccano assolutamente il protocollo di autenticazione CAS e le specifiche di
connessione sicura con l’utente, ma solamente lo step di autenticazione locale
interna tra CAS ed il server LDAP di ateneo.
Infatti il protocollo CAS generale proseguirà solamente a fronte di:
Credenziali utente valide
Validità dello stesso account e della relativa password
6.3.4 Modifiche ai file di configurazione di CAS
Per una corretta configurazione del server CAS è necessario configurare il file
“deployerConfigContext.xml” situato nella cartella
“/cas-server-webapp/src/main/webapp/WEB-INF/”.
È un file di configurazione molto importante, in quanto contiene le specifiche
interne di connessione al server LDAP59, e setta il valore di alcune variabili interne,
necessarie in fase di compilazione ed esecuzione del programma.
59 I campi relativi alla connessione al server LDAP di ateneo e relativa password sono contrassegnati da asterischi, per ovvi motivi di sicurezza.
6.3.4 Modifiche ai file di configurazione di CAS
97
Inoltre questo è il file da modificare per poter introdurre le nuove funzionalità di
gestione della scadenza password, in quanto è da questo punto in poi che il nuovo
progetto debitamente compilato, vedrà i nuovi file e le nuove opzioni introdotte.
Questa la parte di codice XML relativa alle specifiche di configurazione:
6.3.5 Compilazione e installazione pacchetto CAS 100
6.3.5 Compilazione e installazione pacchetto CAS
Operate tutte le modifiche ai file sorgenti Java di installazione ed ai vari file di
configurazione, è possibile ricompilare l’intero pacchetto CAS grazie a Maven2.
Dalla shell ci si sposta nella directory principale del CAS e si esegue il comando:
mvn -Dmaven.test.skip=true package install
Il precedente comando ricompila l’intero pacchetto CAS con le relative modifiche
e crea uno speciale file con estensione .war60, pronto per essere copiato nella
cartella principale di Apache Tomcat.
Infatti procedendo alla copia di questo file nella cartella ‘webapp’ del server
Tomcat e all’avvio del server stesso, questi procederà automaticamente alla
creazione della directory contenente l’intera applicazione web funzionante. Questo
processo viene chiamato comunemente deploy.
Questo un esempio di autenticazione al server CAS con un account nel quale la
password è in fase di scadenza. Verrà consentito l’accesso al servizio richiesto, non
prima però di avere avvertito l’utente della scadenza della propria password.
Figura 6.1 Pagina di conferma di avvenuta autenticazione riportante l’avviso di scadenza password
60 I file con estensione .war sono denominati Web Archives e rappresentano dei componenti utilizzati in fase di messa in opera di un'applicazione(deployment). Un file .war, al suo interno, contiene i componenti Web che fanno parte di una applicazione J2EE (come, ad esempio pagine JSP, file HTML, file .class e file XML).
6.4 Secondo problema affrontato: Gestione dei Certificati X509 101
6.4 Secondo problema affrontato:
Gestione dei certificati X509
La crescita, lo sviluppo e la sicurezza dei certificati digitali come metodo di
autenticazione, ha fatto crescere la necessità di fornire anche l’Università di Parma
di una metodologia di autenticazione tramite l’uso di certificati X509 per i propri
studenti, docenti, tecnici, e tutto il personale annesso.
Per questo il secondo problema affrontato durante il periodo di tirocinio è stato
quello di configurare il server CAS di Ateneo, permettendo l’accettazione di
certificati digitali tipo X509 in fase di autenticazione utente.
Come già specificato, il server CAS è già predisposto per un uso di questo tipo.
Quindi rispetto al problema precedente di gestione delle password dove sono state
necessarie pesanti modifiche al codice sorgente java, per risolvere questa
problematica è stata necessaria un’attenta configurazione delle varie entità
coinvolte.
Infatti in primo luogo si è configurato il server Apache Tomcat sul quale è
installato il sistema CAS, per identificare se stesso agli utenti esterni, ed accettare
certificati digitali in fase di autenticazione.
Successivamente è stato scelto il modo in cui il CAS identifica il possessore del
certificato, e configurata la relativa metodologia di autenticazione. Infatti CAS
lascia libera scelta allo sviluppatore del modo in cui le credenziali fornite nel
certificato e l’autorità che le ha rilasciate verranno gestite.
Quindi la possibilità di accettare certificati rilasciati direttamente dall’Università,
porterà alla creazione di un’infrastruttura a chiave pubblica locale per l’Ateneo di
Parma. Inoltre nel caso in cui un utente abbia già un suo personale certificato non
rilasciato per forza dalla CA dell’Università, potrà richiedere attraverso un apposito
servizio, che questo venga registrato all’interno del sistema, ed utilizzato per le
future autenticazioni.
6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X509 102
6.4.1 Configurazione di Apache Tomcat per il
supporto dei certificati X509
Il sistema CAS opera in modo sicuro solamente quando il client si connette
attraverso una connessione TLS/SSL. È quindi necessario configurare Tomcat
consentendo una connessione HTTPS, definendo una specifica porta di ascolto
sicura per queste richieste. Inoltre le connessioni che supportano SSL vengono
configurate con due file che rappresentano una collezione di certificati X509,
chiamati keystoreFile e truststoreFile.
Il keystoreFile è un certificato X509 che il server Tomcat userà per identificare se
stesso al browser utente. Questo certificato contiene inoltre il nome del DNS sul
quale Tomcat è in esecuzione.
Il truststoreFile invece è una collezione di certificati X509 che rappresenta le
Certificate Authority dalle quali Tomcat è disposto ad accettare i certificati utente.
Quando un browser utente si connette al server Tomcat sul quale è installato il
sistema CAS tramite canale HTTPS, questi deve identificare se stesso inviando il
proprio certificato. È stato quindi necessario generare il certificato che Tomcat
presenterà alla richiesta di identificazione, e questo può essere fatto tramite l’utility
Java keytool, presente nella versione Java 6 installata. Infatti con questo tool è
possibile creare dei certificati dalla shell di Unix, eseguendo il comando:
6.4.2 Configurazione di CAS per il supporto dei certificati X509
107
<action-state id="sendTicketGrantingTicket"> <action bean="sendTicketGrantingTicketAction" /> <transition on="success" to="serviceCheck" /> </action-state> <decision-state id="serviceCheck"> <if test="${flowScope.service != null}" then="generateServiceTicket" else="viewGenericLoginSuccess" /> </decision-state> <action-state id="generateServiceTicket"> <action bean="generateServiceTicketAction" /> <transition on="success" to ="warn" /> <transition on="error" to="viewLoginForm" /> <transition on="gateway" to="redirect" /> </action-state> <end-state id="viewGenericLoginSuccess" view="casLoginGenericSuccessView" /> <end-state id="showWarningView" view="casLoginConfirmView" /> <end-state id="redirect" view="bean:dynamicRedirectViewSelector" /> <end-state id="viewServiceErrorView" view="viewServiceErrorView" /> <end-state id="viewServiceSsoErrorView" view="viewServiceSsoErrorView" /> </flow> A questo punto è necessario configurare come il server CAS esamini il certificato
X509 presentatogli dal browser utente verificando che sia stato rilasciato da una
CA fidata, e che estrapoli nei campi del certificato l’identificatore da ricercare sul
server LDAP per proseguire nell’identificazione dell’utente.
Da qui sono entrate in gioco le scelte effettuate in base agli obbiettivi prefissati,
ovvero concentrarsi sulla sicurezza degli utenti locali dell’Università. Possedere
quindi un account sul server LDAP di Ateneo è un requisito fondamentale per
proseguire nell’autenticazione e identificazione utente.
Due sono state le strategie adottate: la prima consiste nell’identificare l’utente
tramite il campo CN del certificato, contenente l’indirizzo e-mail dell’Università
che funge da identificatore unico sul server LDAP.
La relativa configurazione del file “deployerConfigContext.xml” avviene
fatta aggiungendo uno speciale bean nella lista delle proprietà
‘credentialsToPrincipalResolvers’, specificando quale campo ricercare nel
certificato e come ricercarlo sul server LDAP attraverso la configurazione della
proprietà ‘authenticationHandlers’.
6.4.2 Configurazione di CAS per il supporto dei certificati X509
108
Questa la sezione di codice XML relativa a tale parte: ... <bean id="authenticationManager" ... <property name="credentialsToPrincipalResolvers"> <list> <bean class="org.jasig.cas.adaptors.x509.authentication.principal.X509- CertificateCredentialsToIdentifierPrincipalResolver"> <property name="identifier" value="$CN" /> </bean> </list> </property> ... <property name="authenticationHandlers"> <list> <bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler"> <property name="filter" value="mail=%u"/> <property name="searchBase" value="dc=unipr,dc=it"/> <property name="contextSource" ref="contextSource"/> </bean> ... Tuttavia questa scelta non è del tutto efficiente, in quanto obbliga l’utente a
possedere un certificato digitale contenente obbligatoriamente il campo CN
correttamente settato al relativo valore della sua e-mail. Una restrizione di questo
tipo non può essere considerata una buona metodologia nell’uso dei certificati
digitali, perché imporrebbe a questi di rispettare una specifica struttura. Questo
ovviamente non è quello che si vuole dal momento che si desidera introdurre un
sistema di autenticazione attraverso certificati digitale che possono essere rilasciati
da CA differenti e aventi differenti strutture interne.
La seconda strategia invece è più elegante e consiste nella ulteriore ricerca di uno
speciale attributo inserito opportunamente sul server LDAP di Ateneo, composto
da una stringa alfanumerica contenente:
Il numero seriale del certificato.
L’autorità certificante (Issuer DN) che lo ha rilasciato
In questo modo quando l’utente presenta il proprio certificato, e il server CAS
opportunamente configurato estrapola automaticamente i due precedenti campi
creando una stringa comprendente l’unione dei due. Si connette quindi al server
LDAP ricercando su di esso la stringa appena creata. Nel caso in cui questa
6.4.2 Configurazione di CAS per il supporto dei certificati X509
109
corrisponda ad una delle sue entry, l’utente sarà univocamente identificato e verrà
ritornato come parametro il relativo attributo contenente il valore della e-mail, così
successivamente l'utente verrà riconosciuto come tale dall’intero sistema.
In caso contrario verrà riproposta all’utente la normale form di login tramite
username e password.
Questa modalità viene fatta attraverso una precisa configurazione del file
“deployerConfigContext.xml”, specificando alcuni bean di connessione al
server LDAP ed introducendone altri, precisando al sistema CAS quale metodologia
di identificazione utente affrontare. Questo codice XML relativo a tale file:
<?xml version="1.0" encoding="UTF-8"?> ... <bean id="authenticationManager" class="org.jasig.cas.authentication.AuthenticationManagerImpl"> ... <property name="credentialsToPrincipalResolvers"> <list> ... <bean class="org.jasig.cas.authentication.principal. CredentialsToLDAPAttributePrincipalResolver" > <property name="credentialsToPrincipalResolver"> <!-- This resolver this will create a unique ID of form: SERIALNUMBER=<certificate_serial_number>, <certificate_issuerDN> eg: SERIALNUMBER=25263647932548882251489395556682941778 SERIALNUMBER=200301, CN=Citizen CA, C=BE --> <bean class="org.jasig.cas.adaptors.x509.authentication. principal.X509CertificateCredentialsToSerialNumberAnd IssuerDNPrincipalResolver" /> </property> <!-- attribute that needs to be matched to in LDAP: --> <property name="filter" value="storicoserver=%u" /> <!-- to be retrieved from LDAP as the new principal for CAS: --> <property name="principalAttributeName" value="mail" /> <property name="searchBase" value="ou=people,dc=unipr,dc=it" /> <!-- reference to LDAP server configuration: --> <property name="contextSource" ref="contextSource" /> </bean> </list> </property> ... <property name="authenticationHandlers"> <list> ... <bean class="org.jasig.cas.adaptors.x509.authentication.handler. support.X509CredentialsAuthenticationHandler"> <property name="trustedIssuerDnPattern" value="[email protected], CN=www.cce.unipr.it/CA, OU=Centro di Calcolo Elettronico, O=Universita degli Studi di Parma, L=Parma, ST=Parma, C=IT" /> </bean>
6.4.2 Configurazione di CAS per il supporto dei certificati X509
110
<bean class="org.jasig.cas.adaptors.ldap. BindLdapAuthenticationHandler"> <property name="filter" value="mail=%u"/> <property name="searchBase" value="dc=unipr,dc=it"/> <property name="contextSource" ref="contextSource"/> </bean> </list> </property> </bean> ... <bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource"> <property name="userDn"value="cn=***,dc=LDAP,ou=CCE, ou=Strutture,dc=unipr,dc=it"/> <property name="password" value="***"/> <property name="urls"> <list> <value>***</value> </list> </property> <property name="baseEnvironmentProperties"> <map> <entry> <key> <value>java.naming.security.authentication</value> </key> <value>simple</value> </entry> </map> </property> </bean> Adottando questa strategia è possibile quindi accettare qualsiasi tipo di certificato
digitale che sia stato rilasciato da una delle CA ritenute fidate. L’unico contro è che
l’utente deve aver registrato correttamente il proprio certificato sul server LDAP di
Ateneo.
Questo passo può essere effettuato attraverso un apposito servizio web
dell’Università, al quale verrà richiesto di controllare il certificato presentatogli e
sottoporre a giudizio la sua effettiva registrazione, dove verrà mappata
opportunamente la stringa contenente il numero seriale e l’autorità certificante sul
server LDAP, legando quindi il certificato stesso all’identità digitale del soggetto
relativa a questa infrastruttura.
In questo modo avrà anche un maggiore controllo iniziale sull’identità dell’utente
che richiederà di utilizzare il proprio certificato digitale per le autenticazioni future.
Questa specifica configurazione, che impone come requisito di autenticazione
quello di avere un account utente locale, può essere modificata proprio in questo
6.4.3 Compilazione e installazione del pacchetto CAS con certificati X509 111
punto. Infatti inserendo un differente bean nella lista relativa alla proprietà
‘credentialsToPrincipalResolver’, è possibile configurare il CAS per
accettare certificati digitali di utenti che non abbiano obbligatoriamente un account
locale, identificandoli semplicemente con il relativo campo Distinguished Name
DN comune a tutti i certificati digitali. In questo modo sarebbe possibile
autenticare soggetti esterni all’Ateneo, ad esempio docenti o personale di altre
Università, che presentino un certificato digitale valido rilasciato da una delle CA
considerate fidate impostate nel truststoreFile del server Tomcat.
Una di queste potrebbe essere la comunità GARR62: il consorzio ideatore e
gestore della rete telematica nazionale dell'Università e della ricerca. La sua
missione consiste nell'implementazione, gestione ed ampliamento della rete
telematica nazionale ad altissima velocità, interconnessa con tutte le reti della
ricerca europee e mondiali. Il lavoro del GARR rappresenta un contributo
significativo per l'attività della comunità scientifica ed accademica italiana e per il
progresso tecnologico ed industriale del nostro Paese. Infatti uno dei suoi servizi è
proprio quello di rilasciare certificati digitali X509 ai membri della propria
comunità.
Configurare il server Tomcat per accettare i certificati emessi dalla GARR
Certification Authority sarebbe un ottima scelta, e permetterebbe un miglior
scambio di informazioni con docenti e ricercatori esterni all’Ateneo.
Così facendo gli utenti aderenti a questa comunità sarebbero effettivamente
autenticati ed identificati, lasciando poi ad un altro servizio come Shibboleth la
facoltà di decidere le relative politiche di autorizzazione.
6.4.3 Compilazione e installazione pacchetto CAS
con certificati X509
La configurazione del server CAS è ora conclusa. Si può procedere alla sua
completa installazione come già specificato nel paragrafo 6.3.5, compilando l’intero
pacchetto software CAS e procedendo al successivo deploy sul server Tomcat.
62 http://www.garr.it/
6.4.3 Compilazione e installazione del pacchetto CAS con certificati X509
112
Richiedendo ora un servizio web dell’Università per il quale è necessaria
l’autenticazione, questi rimanderà l’utente alla pagina web del CAS, che si
presenterà inviando il proprio certificato.
Se l’utente avrà installato sul proprio browser uno o più certificati digitali, verrà
richiesto in automatico di inviarne uno tra quelli disponibili, altrimenti verrà
presentata la form di login attraverso username e password.
In caso l’autenticazione abbia successo, l’utente verrà riconosciuto dall’intera
infrastruttura tramite il valore della sua e-mail dell’Università.
Figura 6.3 Esempio di autenticazione CAS tramite invio di un certificato digitale.
Vale la pena notare che nel caso in cui l’utente abbia un solo certificato digitale
installato sul proprio browser, o che lo abbia settato per fare in modo di inviarne
uno automaticamente, l’utente sarà totalmente trasparente alla fase di
autenticazione.
Infatti se questa avrà successo, non verrà nemmeno mostrata la pagina di
conferma, ma l’utente verrà direttamente reinviato al servizio richiesto.
6.4.4 Problemi con le Certification Revocation List 113
6.4.4 Problemi con le Certification Revocation List Purtroppo il sistema qui presentato non ha ancora implementato un servizio per
la gestione delle liste di revoca dei certificati, quindi come controllare che un
certificato al momento della sua presentazione, non sia stato revocato. Questo
deriva dal fatto che attualmente non sono state fatte scelte relative a quale strategia
utilizzare: la strategia sincrona o quella asincrona.
Nella prima strategia si può pensare di configurare l’intero sistema affinché
questi controlli nello stesso istante dell’autenticazione, che il certificato
presentatogli dall’utente non sia nelle liste di revoca della CA associata,
connettendosi ad essa attraverso lo specifico protocollo OCSP, quindi in modo
sincrono rispetto all’autenticazione.
Utilizzando invece la seconda strategia, ovvero quella asincrona, si può pensare di
programmare il sistema affinché scarichi quotidianamente le liste di revoche dalla
CA e le memorizzi ad esempio su LDAP. Durante l’autenticazione utente il server
LDAP dovrebbe solamente effettuare una veloce ricerca, ricercando nella propria
lista se il certificato presentato dall’utente sia stato revocato.
Queste due strategie hanno entrambe vantaggi e svantaggi. La prima ha come
grande vantaggio una migliore sicurezza, infatti il sistema riconosce
immediatamente se il certificato è stato revocato o sospeso. Per contro si ha che
l’intero protocollo di autenticazione risulta notevolmente appesantito, tanto è vero
che si deve attendere la risposta della CA prima di proseguire, ed inoltre il traffico
in rete aumenta considerevolmente.
La seconda strategia invece ha come maggior pregio la leggerezza del protocollo
ed il minor traffico in rete. Difatti il sistema si connette alla CA solo in momenti
prefissati per aggiornare i dati sulle liste di revoca, e la successiva ricerca locale sul
server LDAP è molto snella e veloce. A sfavore invece si può notare un rilevante
calo della sicurezza del sistema. Precisamente il possibile intruso potrebbe
attaccare nel periodo di tempo che intercorre l’aggiornamento della lista locale.
Riducendo questo lasso di tempo, i rischi di un possibile attacco diminuirebbero,
però si appesantirebbe nuovamente il traffico in viaggio sulla rete. È quindi
necessaria un attenta riflessione e decidere quale di queste due strategie utilizzare.
Capitolo 7
Conclusioni
7.1 Risultati ottenuti
Al termine dello studio degli argomenti trattati e della loro possibile applicazione
in uno scenario concreto come quello di una struttura universitaria si può
affermare che gli obbiettivi preposti all’inizio sono stati raggiunti.
I miglioramenti proposti infatti affrontano il problema della sicurezza in maniera
ottimale, sia per quanto riguarda la modalità di autenticazione tramite username e
password, che per quella più innovativa ovvero tramite i certificati digitali.
Tanto è vero che l’integrazione del sistema attuale col servizio di gestione per la
scadenza della password porta notevoli vantaggi in termini di affidabilità e
protezione degli account dell’Ateneo, a scapito di una perdita di tempo non
superiore ai tre minuti da parte degli utenti per cambiarsi la password in media
ogni 180 giorni.
Anche l’introduzione della nuova modalità di autenticazione tramite certificati
digitali porterà grandi benefici in merito a comodità e soprattutto efficienza del
sistema. Per quanto riguarda la sicurezza, la strutturazione del servizio qui
7.2 Utilizzo dei nuovi servizi
116
proposta non potrebbe essere migliore, anche se come già riportato solo i soggetti
aderenti a questa Università possono servirsene.
Inoltre un aspetto da non sottovalutare, è la possibilità per l’utente che intenda
usufruire delle applicazioni offerte, di avere una totale trasparenza durante il
protocollo di autenticazione, se questi avrà semplicemente settato il browser per
inviare automaticamente il proprio certificato digitale.
7.2 Utilizzo dei nuovi servizi
Il sistema qui presentato è stato testato all’Interno del S.I.T.I con buoni risultati
per quanto riguarda entrambi i miglioramenti proposti. In particolare il servizio di
gestione della scadenza password potrebbe essere inserito nell’attuale modalità di
autenticazione già da quest’anno, portando i benefici già trattati.
Anche il secondo miglioramento presentato potrebbe essere attivato a breve,
anche perché l’Università già dispone di una CA per la richiesta ed il rilascio dei
certificati digitali.
Un possibile scenario d’uso di quest’ultima modalità, sarebbe quella di fornire
agli utenti che lo richiedessero, una smart card o un token USB contenente il
proprio certificato digitale. Lo studente, il docente, o qualsiasi persona del
personale strutturato, potrebbero accedere a qualsiasi computer sparso tra i vari
dipartimenti in maniera veloce, comoda e soprattutto affidabile, e allo stesso modo
potrebbero anche autenticarsi dal PC di casa o quello di un internet café, sempre in
totale sicurezza e garanzia di protezione dei propri dati e informazioni personali.
Inoltre i cambiamenti da effettuare alle varie configurazioni per supportare
anche utenti estranei all’Ateneo per esempio appartenenti alla comunità GARR,
sarebbero minimi, anche se si dovrebbe però integrare il servizio CAS con il
sistema Shibboleth, progetto per il quale l’Università si sta peraltro attrezzando.
7.3 Sviluppi futuri
117
7.3 Sviluppi futuri
Gli scenari riguardanti le possibili evoluzioni di questo progetto riguardano senza
ombra di dubbio la modalità di autenticazione tramite certificati digitali.
Difatti l’ormai collaudata metodologia di accesso tramite username e password
integrata al servizio della relativa scadenza qui proposto, difficilmente potrà essere
nuovamente migliorata, a meno di un cambio generale del protocollo e dell’intero
sistema di autenticazione stesso.
Invece la continua espansione dei certificati X509 renderà questa tipologia di
accesso ai servizi dell’Università sempre più importante, sia per la sicurezza locale
qui ampiamente affrontata, ma anche per la possibilità di interagire con soggetti ed
enti esterni all’Ateneo. Ma come quasi sempre accade, l’ampliamento di un servizio
porta all’introduzione di ulteriori problematiche annesse. Si dovrà quindi
pianificare accuratamente lo scenario al quale si vorrà arrivare, tenendo anche
conto dei costi e soprattutto dei rischi che questi miglioramenti porteranno.
Una ulteriore tematica che potrebbe essere analizzata sarebbe quella relativa alle
già citate liste di revoca dei certificati. Ma per quello appena detto, varrebbe la
pena di affrontare questo problema nello stesso momento in cui si deciderà di
“aprire le porte” al mondo esterno.
Bibliografia [1] Reti di Calcolatori, A Tanenbaum.
[2] Internet e reti di calcolatori, J Kurose W Ross.