Sistemi per la sicurezza nella gestione di documenti informatici: un'applicazione in ambito universitario

L'Autorità di Registrazione è l'entità che deve inizialmente 
accertare l'identità dell'utente che richiede un certificato elettronico 
in base a una certa politica di sicurezza che verrà in seguito 
descritta. Pertanto nel nostro sistema la RA avrà il compito di 
registrare i vari docenti e fornire loro l'autorizzazione iniziale e le 
relative carte d'accesso. 
L'Autorità di Certificazione gestisce l'intero ciclo di vita dei 
certificati elettronici assegnati ai vari utenti che precedentemente si 
erano registrati presso l'Autorità di Registrazione, dalla creazione 
alla revoca, passando attraverso fasi di aggiornamento e 
sostituzione. Sarà sempre la CA che avrà l'onere di stabilire 
relazioni di fiducia con altre CA, qualora diventi necessario per la 
nostra applicazione un’interazione col "mondo esterno". 
A queste tre entità se ne affianca una quarta: il timestamp 
server, ossia un sistema di validazione temporale che è in grado di 
fornire ai documenti una data e un ora autenticata. Vedremo in 
dettaglio il suo funzionamento nel successivo capitolo quando ci 
occuperemo dell’implementazione del sistema, 
A queste tre entità si affiancheranno due sistemi di 
immagazzinamento dei dati: il sistema di Directory, che avrà il 
compito di memorizzare e rendere pubblici i vari certificati 
elettronici e di gestire la Certificate Revocation List (CRL) e il 
database che conterrà i vari verbali d'esame firmati dai docenti e 
sarà gestito dal server. 
2 
ClientCA
RA
Rete di
Director
Interconnessione
dei verbali
Database
 Figura 5.1: Schema dell’organizzazione del sistema complessivo 
5.2 Inizializzazione dei docenti 
La fase di inizializzazione dei docenti è quella fase iniziale 
tramite la quale i vari docenti, accedendo a una postazione client, si 
identificano per la prima volta alla PKI e grazie alla quale, in caso 
di esito favorevole, potranno successivamente essere abilitati a 
svolgere le varie operazioni di firma e cifratura all’interno 
dell’organizzazione universitaria. Questa fase è così articolata: 
3
y
verbali
Server
Server
Timestamp
1. Registrazione iniziale: i docenti, come qualsiasi end entity, 
devono presentarsi all'Autorità di Registrazione e, una volta 
identificati, vengono registrati dalla RA come professori 
universitari. Al docente viene dato, in supporto cartaceo, un 
valore segreto iniziale (Initial Athentication Key) relativo ad un 
certo valore di riferimento (Reference Value), in maniera 
analoga a quanto fa una banca con i suoi clienti quando fornisce 
il PIN (Personal Identification Number) per l’utilizzo di una 
carta bancomat. Questa coppia di valori serve all'utente per 
disporre dell’autorizzazione necessaria nella successiva fase di 
certificazione con la CA. Inoltre la RA fornisce a ciascun 
docente un dispositivo di memorizzazione per la coppia di 
chiavi (per esempio, una smart card) e un floppy disk, il cui 
utilizzo sarà spiegato in seguito. Va osservato che questa fase 
viene svolta completamente in modalità "out-of-band", ossia 
senza ricorrere ad alcun tipo di comunicazione che utilizzi una 
struttura di reti di calcolatori. La RA potrebbe coincidere con 
l’ufficio personale dell’Ateneo: alla presa di servizio di un 
nuovo docente si provvede anche alla sua registrazione iniziale. 
2. Key Generation: l'utente, inserita la smart card nell'apposito 
dispositivo di lettura, tramite l'interfaccia grafica 
dell'applicazione client può generare la sua coppia di chiavi. La 
generazione avviene completamente all'interno della smart card, 
grazie al chip che ivi è incorporato, in modo che la chiave 
privata non esca mai dalla carta. Si noti che il nostro sistema 
prevede la possibilità che l'utente possa svolgere operazioni sia 
di firma sia di cifratura; pertanto verranno generate due coppie 
1
di chiavi, a cui corrisponderanno due certificati elettronici. 
1
 In realtà, in conformità con le diverse necessità di gestione delle chiavi solo la coppia di 
chiavi di firma viene generata all'interno della smart card, mentre la coppia di chiavi di 
cifratura viene generata dalla PKI e successivamente trasferita nella carta. 
4 
3. Richiesta di certificazione: a questo punto l'applicazione 
genera un messaggio di richiesta di certificazione per la CA. 
Tale richiesta può essere autenticata grazie all'utilizzo 
dell'associazione Reference Value-Initial Athentication Key 
(RV-IAK), che garantisce che l’utente era stato registrato 
precedentemente dalla RA. Il messaggio con la chiave pubblica 
dell'utente è, quindi, spedito alla CA in modalità “on-line” in 
virtù del fatto la coppia numerica (RV-IAK) ha creato un canale 
di comunicazione autenticato tra end-entity e la CA. Va 
osservato che tale canale, finita la fase di inizializzazione, non 
2
potrà più essere utilizzato. 
4. Verifica della richiesta di certificazione: la CA alla ricezione 
del messaggio ne verifica l'autenticità tramite la coppia RV-IAK 
e in caso di successo provvede a generare un profilo per l'utente 
e la creazione di due certificati elettronici, uno per la chiave 
pubblica di firma, l’altro per la chiave pubblica di cifratura. 
Questi certificati, oltre alla rispettiva chiave pubblica, 
contengono il nome e il cognome del docente, il nome della CA 
di appartenenza, la validità temporale delle chiavi e altre 
informazioni in conformità con lo standard X.509v3 
3
[RFC2459]; sono memorizzati nel relativo sistema di directory, 
e firmati con la chiave privata della CA, sono spediti insieme al 
certificato della stessa CA alla postazione client che ha richiesto 
la certificazione. 
5. Conferma della certificazione: il docente riceve dalla CA il 
messaggio di risposta alla richiesta di certificazione; 
l’applicazione client verifica i certificati tramite la chiave 
pubblica della CA e in caso di successo memorizza i certificati 
elettronici ricevuti nella smart card. Ovviamente il docente deve 
2
 Per creare questo canale autenticato, Entrust utilizza un suo protocollo SEP (Secure 
Exchange Protocol) che utilizza la crittografia a chiave simmetrica. 
3
 Come vedremo in seguito, Entrust memorizza nella directory solo i certificati di cifratura e 
non anche quelli di verifica. 
5
già possedere in maniera fidata la chiave pubblica della CA; per 
far questo la CA nella fase di registrazione iniziale deve fornire 
in modalità “out-of-band” l’impronta digitale () della 
4
sua chiave pubblica. 
Riportiamo di seguito il diagramma di flusso dei dati 
dell’inizializzazione del docente corredato dal relativo dizionario 
dei dati. 
Notazione Descrizione 
RV Reference Value: è un valore di riferimento generato 
dalla RA per la prima identificazione dell’utente. 
IAK Initial Athentication Key: è il codice segreto relativo 
al RV che consente a una end-entity di autenticarsi 
quando accede per la prima volta alla CA. 
Kpub Sono le due chiavi pubbliche: una di firma, l’altra di 
cifratura. 
Kpriv Sono le due chiavi private: una di firma, l’altra di 
cifratura. 
Certificato CA E’ il certificato elettronico X.509v3 dell’Autorità di 
certificazione 
Certificato docente Sono i due certificati elettronici X.509v3 
corrispondenti alle due chiavi pubbliche. 
Tabella 5.1: Dizionario di Dati per l’inizializzazione del docente 
4
 Entrust non richiede la verifica della chiave pubblica della CA in quanto la sua validità è già 
garantita dall’utilizzo del protocollo SEP. 
6 
fingerprint
Figura 5.2: Data Flow Diagram per l’inizializzazione del docente 
5.3 Inizializzazione dell’applicazione server 
Anche l’applicazione server, residente in un dedicato 
elaboratore, da noi inseguito denominato server, essendo anch’essa 
un end-entity, avrà una fase di inizializzazione simile a quella dei 
docenti. La principale differenza deriva dal fatto che l'applicazione, 
una volta inizializzata, non richiederà più l’intervento umano, se 
non per motivi di manutenzione. Pertanto la fase di inizializzazione 
7
si tradurrà semplicemente nel generare un profilo per tale 
applicazione, che sarà anch'essa registrata dalla CA. Ovviamente a 
differenza dei client utilizzati dai docenti, l’applicazione server non 
disporrà di una smart card per la memorizzazione delle due coppie 
di chiavi, le quali saranno semplicemente memorizzate localmente 
nella postazione server. Va da sé che l’elaboratore server dovrà 
essere custodito in un ambiente intrinsecamente sicuro in modo da 
evitare un’eventuale manomissione o copia di tali chiavi. Un 
analogo discorso andrà fatto per il sistema che ospita l’intera 
struttura PKI (RA, CA e directory.) 
Nella postazione server sono anche presenti le cosiddette 
capability dei docenti, ossia è definita una matrice degli accessi in 
virtù della quale si stabilisce per ogni corso d'esame quale docente 
risulti titolare (e quindi, se abbia potere di firma dei verbali.) 
Queste capability sono fornite dalle Segreterie di Facoltà in base ai 
carichi didattici stabiliti per ogni anno accademico dai diversi 
Consigli dei Corsi di laurea. 
5.4 Verbalizzazione degli esami 
Una volta terminata la fase di inizializzazione 
dell’applicazione server, ogni docente, dopo avere eseguito la 
propria fase di inizializzazione, è in grado, mediante l’interfaccia 
grafica del client, di poter compiere tutte quelle operazioni 
necessarie per la verbalizzazione digitale di un esame. Si suppone 
che ogni verbale sia relativo ad un unico studente esaminato. 
L’intera operazione attraversa le seguenti fasi: 
1. Il docente accede attraverso una qualsiasi postazione client, 
carica l’applicazione "client" che consente la verbalizzazione 
dell’esame. Per utilizzare tale applicazione, il docente deve 
8 
inserire la propria smart card e il floppy disk nei rispettivi 
lettori. L'applicazione chiede il codice di protezione della carta 
(PIN), che garantisce l'autenticazione del possesso della smart 
card da parte del docente. Se il PIN è corretto, allora, tramite le 
informazioni contenute nel certificato elettronico del docente 
(memorizzato nella carta), viene verificato che il possessore 
della carta sia effettivamente un docente; per far ciò si 
utilizzano le estensioni del certificato secondo lo standard 
X.509v3. 
2. Se l'accesso viene autenticato, l'applicazione, mediante 
l’interfaccia grafica, consente al docente la compilazione del 
verbale per gli esami di cui ha diritto: il docente inserisce i vari 
dati richiesti dalla schermata (anagrafica dello studente, voto, 
quesiti, ecc.). In tale fase di compilazione, l'applicazione può 
prelevare dal floppy disk tutte quelle informazioni che 
alleggeriscono il docente dall'onere della digitazione (es: 
numero del verbale, codice esame, codice docente, ecc.) Al 
termine della compilazione il docente avvia la procedura di 
firma del verbale: l’applicazione calcola mediante un'opportuna 
funzione hash il digest message del documento contente i dati 
del verbale appena compilato e passa tale digest message alla 
smart card, la quale, pilotata dall’applicazione, effettua 
l’operazione di firma del digest tramite la chiave privata di 
firma del docente contenuta nella carta. Il digest message 
firmato, che rappresenta la firma del verbale, viene restituito 
all’applicazione. Poiché un verbale deve essere firmato da due 
docenti, l’applicazione provvede a ripetere la prima fase di 
autenticazione per il secondo docente, il quale, una volta 
autenticato, firma il verbale, anche lui utilizzando la sua smart 
card. A questo punto il messaggio è costituito dal verbale in 
chiaro (in quanto il verbale, essendo un documento pubblico, 
9
non ha bisogno di essere crittografato) e dalle firme elettroniche 
dei due docenti. 
3. Il messaggio, prima di essere inoltrato al server, viene spedito a 
un gestore di servizi di marcatura temporale (timestamp server) 
che marca con la data e l’ora di trasmissione il verbale: al 
documento viene apposta una terza firma, quella del timestamp 
server, che consente al verbale di avere una riferimento 
temporale autenticato. 
4. Finito il processo di validazione temporale, il timestamp server 
restituisce il messaggio al client la quale provvede a spedirlo al 
server tramite un appropriato protocollo di trasporto. 
5. Il server, a meno di problemi occorsi in fase di trasmissione 
sulla rete, riceve il verbale firmato e passa a verificarne la firma. 
Per fare ciò, utilizza la chiave pubblica di verifica del docente 
contenuta nel relativo certificato (facente parte anch'esso del 
5
messaggio inviato dalla postazione client); tale chiave pubblica 
deve essere verificata in quanto potrebbe non essere più valida 
(es: un docente ha smarrito la smart card oppure è stato 
trasferito; in entrambi i casi il suo certificato elettronico è stato, 
pertanto, revocato); per far questo, l’applicazione dove 
connettersi con la Directory, nel quale sono contenuti tutti i 
certificati validi e quelli invece revocati (CRL). Oltre alla 
verifica della firma, bisogna verificare le capability di colui che 
ha firmato il documento, ossia bisogna verificare che il mittente, 
oltre ad avere la qualifica di docente, stia firmando un verbale 
per un esame per il quale ha effettivamente il diritto di docenza. 
A questo scopo l'applicazione server consulta il database locale 
contente le capability dei docenti e ne verifica la legittimità di 
tale firma. Se la verifica del documento va a buon fine e quindi 
il verbale non è stato alterato, l’applicazione server comunica 
5
 Il regolamento dell’AIPA richiede espressamente che il certificato di verifica della firma sia 
incluso nel messaggio firmato, nonostante il server avrebbe la possibilità di disporre già di una 
copia di tutti i certificati dei docenti. 
10 
all’applicazione client il buon esito della verbalizzazione, 
mandando un messaggio d'acknowledge firmato con la propria 
chiave privata di firma. Il verbale firmato è infine memorizzato 
in un apposito database. 
6. L’applicazione cliente riceve il messaggio d'acknowledge 
firmato dal server, ne verifica la firma e, in caso di successo, ne 
deduce la buona riuscita dell’intera operazione. 
7. Se invece l’applicazione server constata un errore nel processo 
di verifica del verbale firmato, non ritiene valido tale 
documento; pertanto non effettua nessuna sua archiviazione, ma 
manda un messaggio di notifica di errore al client (anch’esso 
firmato). Il client, ricevendo tale notifica di errore, ha l’onere di 
rispedire nuovamente il verbale firmato. Quando descriveremo 
nel dettaglio il protocollo di comunicazione vedremo come 
gestire tali situazioni. 
2. Timestam
dei verbali
Client
3. Invio verbale firmato
4. Invio risposta firmata
1. Compilazione e firma del
5. Verifica del verbale ed
6. Controllo risposta server
Database
Director
 Figura 5.3: Verbalizzazione di un esame 
11
ypg
verbali
eventuale memorizzazione
verbale
Server
in
Server
Timestamp
Il protocollo di comunicazione tra client e server deve 
ovviamente tenere in conto la possibilità di eventuali 
malfunzionamenti nella comunicazione tra i due nodi remoti, che 
possono comportare la perdita di messaggi. Inoltre ci dovrà essere 
un appropriato grado di replicazione dei verbali sia dal lato client 
sia dal lato server affinché l'intero sistema presenti un certo livello 
di fault tolerance, che lo renda robusto nei confronti di guasti dei 
dispositivi fisici di memorizzazione. Perciò, nella fase di 
realizzazione, dovremmo tener conto di queste due esigenze: 
garanzia di una comunicazione affidabile e robustezza a fronte di 
guasti. 
Riassumendo i vari componenti software del sistema abbiamo: 
• Applicazione client: consente, attraverso un’interfaccia grafica 
user-friendly, un veloce e intuitivo utilizzo da parte dei docenti, 
che tramite quest’applicazione possono inizializzarsi e 
successivamente compilare, firmare e poi spedire al server i vari 
verbali. 
• Applicazione server: riceve i verbali firmati dai docenti, verifica 
la loro validità e provvede alla loro archiviazione. 
• Sistema PKI: costituito dall’Autorità di registrazione, da quella 
di certificazione e dal sistema di directory, consente 
l’inizializzazione dei docenti e dell’applicazione server e 
gestisce tutti i compiti tipici di un’infrastruttura a chiave 
pubblica, quali la gestione delle chiavi e dei certificati 
elettronici. 
5.5 Il protocollo di comunicazione 
Come è stato descritto precedentemente, la comunicazione tra 
le due end-entity avviene secondo un semplice protocollo tipico dei 
modelli cliente - servitore, ove il cliente manda un messaggio di 
12 
"richiesta" (che consiste nel verbale di un esame) e il servitore 
manda una risposta () che rappresenta la ricevuta della 
richiesta del cliente. I messaggi possono viaggiare in una qualsiasi 
rete di interconnessione (ad esempio Internet) senza aver problemi 
di sicurezza, poiché la sicurezza non è demandata al mezzo 
trasmissivo ma è già insita negli stessi messaggi in virtù 
dell'utilizzo della tecnologia a chiave asimmetrica. 
Ciò che ancora non abbiamo considerato è innanzitutto come 
gestire il fatto che la risposta del server possa non essere positiva, 
in quanto la procedura di verifica della firma del docente può 
fallire. Inoltre bisogna tener conto del fatto che stiamo utilizzando 
un sistema di reti di calcolatori, in cui i messaggi posso essere persi 
o corrotti, in cui gli elaboratori possono essere temporaneamente 
non disponibili o irraggiungibili; pertanto nella progettazione del 
protocollo dovremo considerare i possibili malfunzionamenti 
dovuti alla rete di interconnessione. 
A questi problemi tipici nelle comunicazioni di rete, si 
aggiunge un altro problema di natura locale che riguarda il fatto 
che sia da parte del client, sia da parte del server, i verbali devono 
essere memorizzati in formato elettronico (file ) su un supporto di 
memorizzazione fisico (memoria secondaria) che, come tutti i 
dispositivi fisici, è soggetta a possibili guasti che possono 
compromettere la reperibilità delle informazioni ivi memorizzate. 
Pertanto nella progettazione dovremo tenere conto anche di questo 
aspetto. 
5.5.1 Fallimento della verifica della firma del docente 
In base a quanto detto precedentemente, il primo caso da 
gestire è quando l'applicazione server non riconosce la firma del 
13
acknowledge
docente nella fase di verifica. Questo può succedere 
sostanzialmente per due motivi: 
1. Il pacchetto (o i pacchetti) su cui viaggia il messaggio 
spedito dal cliente viene alterato o a causa di un qualche 
malfunzionamento verificatosi durante la trasmissione 
oppure a causa di un attacco attivo da parte di un intrusore 
che volontariamente tenta di cambiare il contenuto del 
verbale, violando l'integrità del messaggio. 
2. La firma del docente non è più valida in quanto il certificato 
elettronico contenente la corrispondente chiave pubblica di 
firma è stato revocato e l'applicazione server se n'è accorta 
accedendo alla Certificate Revocation List (CRL). 
Poiché nel nostro sistema il caso più frequente sarà il primo 
(molto più rare saranno firme con certificati revocati), si è scelto 
che l'applicazione server mandi al client un messaggio di notifica di 
tale insuccesso (messaggio firmato con la sua chiave privata) e che 
l'applicazione client, a seguito di tale notifica, effettuerà una 
ritrasmissione del verbale. A questo scopo il verbale firmato, prima 
di essere spedito, viene memorizzato temporaneamente nella 
memoria di massa del client (il suo hard disk) e successivamente 
cancellato quando il server dà la conferma di memorizzazione del 
verbale nell'apposito database. In questo modo l'applicazione può 
ritrasmettere il verbale in modo completamente trasparente 
all'utente, ossia senza che il docente se ne accorga. 
Se la verifica di firma questa volta ha successo, 
l'applicazione server manderà l'acknowledge previsto e il docente 
riceverà tale notifica senza accorgersi dell'avvenuta ritrasmissione. 
Nel caso in cui la verifica di firma fallisca ancora, dopo un 
adeguato numero di ritrasmissioni, l'applicazione client segnalerà al 
docente la mancata verifica della sua firma. A questo punto il 
verbale non sarà cancellato dall’hard disk del client: il docente sarà 
14 
obbligato dall'applicazione a memorizzare sul suo floppy il verbale 
non trasmesso (successivamente vedremo come gestire questi 
verbali non trasmessi.) 
Va osservato che l'applicazione client è strutturata in modo 
da sospendere il docente dalla compilazione di un altro verbale fin 
quando non riceva una risposta, positiva o negativa, da parte del 
server. Inoltre il server farà un'attività di auditing, ossia 
memorizzerà in un file tutti i tentativi di fallimento di verifica della 
firma. 
5.5.2 Fallimento delle verifica delle capability del 
docente 
Un altro motivo per cui il server non può dare una risposta 
positiva al client è dovuta al mancato riscontro delle capability del 
docente. Il server, se constata che il verbale è relativo ad un esame 
di cui il docente non ha diritto di firma, notifica tale fatto 
all'applicazione client: a questo punto sarà premura del docente 
verificare la correttezza del file contenuto nel suo floppy disk che 
fornisce all'applicazione le informazioni con cui è possibile 
inizializzare i verbali (corsi, codice docente, ecc.) 
5.5.3 Fallimento della verifica della firma del server 
Nella comunicazione tra cliente e servitore, non solo il verbale è 
f i r m a t o , m a l o è a n c h e i l m e s s a g g i o d i r i s p o s t a d a p a r t e 
dell'applicazione server, cosicché il client possa verificare 
l'autenticità della risposta. Pertanto, si potrà verificare un 
fallimento anche nella procedura di verifica della firma del server. 
In tal caso, il client, non essendo notificato dell'avvenuta ricezione 
15