In un certificato di firma digitale possono essere inserite indicazioni sull'attività professionale o sulle cariche del titolare, o sui suoi eventuali poteri di rappresentanza. In questo modo con la verifica della firma digitale si può avere anche la certezza che il firmatario sia legittimato alla firma di determinati documenti.
Un certificato, e la chiave segreta associata, non "vive" all'infinito. Esso ha una data di nascita e una data di scadenza, dopo la quale perde di validità. Ma un certificato può perdere di valore anche prima della propria scadenza: essere revocato in seguito al verificarsi di qualche "incidente" (ad esempio, la perdita di segretezza della chiave segreta), o sospeso temporaneamente (ad esempio su richiesta dello stesso utente certificato).
Comunque il certificatore deve rendere pubblica la revoca o la sospensione in tempi molto stretti, perchè un ritardo può trarre in inganno chi riceve un documento elettronico firmato, e verifica come valida una firma digitale che invece non lo è (ad esempio in seguito alla perdita, da parte del titolare, del potere di rappresentanza).
"Tempi molto stretti" non significa settimane o giorni, ma minuti o addirittura secondi: è il contesto operativo a suggerire la migliore politica da adottare. La tempestività di segnalazione della revoca o sospensione è particolarmente importante: basti pensare alle conseguenze che può avere una serie di ordini di pagamento sottoscritti dall’amministratore di una società dopo che gli è stato revocato il mandato. Sino a quando la revoca del mandato (e quindi del certificato che lo documenta) non viene resa pubblica, quell'ordine è valido per chiunque compia la verifica della firma.
18
Firma Digitale e Non
Requisiti Formali per il Rilascio e la Gestione dei Certificati
A questo punto dovrebbe essere chiara la criticità del ruolo del certificatore nello scenario di creazione di un documento informatico "valido e rilevante a tutti gli effetti di legge" all’interno di un Gruppo Chiuso di Utenza, e ben si comprendono i motivi che hanno spinto il legislatore (italiano ed europeo) a prevedere per i certificatori pubblici norme restrittive, tanto da disegnare un sistema molto più rigido delle prassi di certificazione in uso in ambiti meno critici (ad esempio su Internet).
L'art.8 del D.P.R.513/1997 stabilisce, tra l'altro, che l'attività di certificazione possa essere svolta da soggetti privati che abbiano gli stessi requisiti richiesti per l'esercizio dell'attività bancaria e che siano iscritti in un apposito elenco, tenuto dall'Autorità per l'informatica nella pubblica amministrazione; analoghi requisiti (tranne quelli di tipo soggettivo) sono richiesti per le Amministrazioni pubbliche che intendono svolgere l'attività di certificazione nel proprio ambito13.
Il certificatore privato deve avere la "forma di società per azioni e capitale sociale non inferiore a quello necessario ai fini dell'autorizzazione all'attività bancaria". Questo significa che solo società di grandi dimensioni, come le banche e i maggiori operatori di telecomunicazioni possono realizzare strutture con i requisiti richiesti per l'emissione di certificati che consentono di firmare documenti informatici "validi e rilevanti a tutti gli effetti di legge".
In effetti, l'esperienza Internet dimostra che l'attività di certificazione può essere svolta con successo da strutture di dimensioni ben più piccole di quelle rese obbligatorie dalla nostra normativa. È invece discutibile che l'affidabilità dei singoli certificatori possa essere ottenuta con il sistema del web-trust, cioè della fiducia e della certificazione reciproca: "io ti certifico perché un mio amico ti conosce" e così via. In molti casi basta inviare per fax la fotocopia di un documento per essere abilitati al rilascio di un certificato: quanto ci vuole per inviare un documento contraffatto?
Evidentemente il livello di sicurezza tipico della rete non è idoneo alla sottoscrizione di documenti validi e rilevanti a tutti gli effetti di legge.
Con la firma digitale certificata secondo la normativa italiana si possono sottoscrivere atti anche per importi rilevanti; nella pubblica amministrazione si può gestire l'intero flusso documentale, si possono emanare atti di qualunque tipo e, soprattutto, si semplificano enormemente i rapporti tra gli uffici e i cittadini, compresi i flussi di denaro.
Per la normativa italiana non ci sono limiti qualitativi o quantitativi alle transazioni che possono essere compiute con la firma digitale: si potranno comperare o vendere società, ottenere prestiti per miliardi, certificare bilanci di società di dimensioni sovranazionali. E tutto ciò anche tra soggetti che non si conoscono e che non hanno avuto precedenti rapporti, o che non fanno parte di "sistemi chiusi", come quello delle transazioni tra istituzioni finanziarie, che da tempo avvengono per via telematica.
E' evidente che questo scenario globale può funzionare solo con un livello molto elevato di affidabilità dei certificati e delle chiavi digitali, poiché sul certificato è fondata la sicurezza del documento informatico.
Si giustifica così il rigore delle norme relative alla registrazione dei certificatori, compresa la dimensione economica delle società: non si deve dimenticare che il certificatore può essere chiamato a risarcire i danni causati da vizi dei certificati, o più semplicemente da un ritardo nella pubblicazione della sospensione o della revoca di una coppia di chiavi.
13 Si deve sottolineare che le pubbliche amministrazioni hanno i medesimi obblighi dei privati (tranne la forma societaria, ovviamente) per quanto concerne organizzazione oggettiva e sicurezza, ma solo se intendono produrre certificati con valenza esterna: possono invece adottare regole più "leggere" per la sottoscrizione di documenti interni e non destinati all'esterno.
19
Firma Digitale e Non
Con le norme sui requisiti e sui compiti dei certificatori il legislatore italiano ha voluto costruire un edificio di certezza e di affidabilità del documento informatico, in quanto la sua diffusione in ambito pubblico e la sua adozione da parte dei privati sono in buona parte legate al clima di fiducia che si creerà sull'uso del nuovo sistema.
Se gli utenti non si fideranno della firma digitale il suo impiego sarà evitato o rallentato il più a lungo possibile, con conseguenze negative per la modernizzazione della pubblica amministrazione e lo sviluppo stesso della società dell'informazione.
Certification Authority: operatività
Un’Autorità di Certificazione (Certification Authority - CA) è un’entità che riceve un insieme di informazioni, le verifica e le garantisce rispetto a una terza parte (ovvero gli utenti del Gruppo Chiuso di Utenza di cui è certificatore).
La CA deve realizzare le seguenti funzioni principali:
1. accettare le richieste di certificazione
2. verificare l’identità delle persone o delle organizzazioni che richiedono la certificazione 3. emettere i certificati
4. revocare i certificati
5. fornire informazioni sui certificati che ha emesso.
Le prime due funzioni sono dette di registrazione, mentre le altre rispettivamente di emissione e gestione dei certificati. I certificati emessi da una CA forniscono alle entità certificate un mezzo per provare la propria identità in un contesto di transazione elettronica. I certificati sono basati su un sistema di crittografia a chiave pubblica.
Un certificato emesso da una CA e firmato con la chiave segreta della CA tipicamente contiene:
•
la chiave pubblica del titolare certificato;
•
il nome del titolare: se il titolare è una persona fisica il suo nome e cognome, data di nascita, eccetera - se invece è un server il nome è il suo indirizzo di rete (indirizzo simbolico DNS o indirizzo IP);
•
la data di scadenza del certificato;
•
il nome della CA che ha emesso il certificato;
•
la firma digitale della CA che ha emesso il certificato (ovvero l’HASH delle informazioni precedenti codificato con la chiave segreta della CA).
Le informazioni inserite nel certificato sono estratte da un documento elettronico presentato alla CA dall’aspirante titolare: la Richiesta di Certificazione (Certification Request). I campi inseriti nella richiesta di certificazione e le procedure utilizzate per verificarli sono parte della “policy” specifica della CA.
Se le procedure definite dalla policy della CA sono state eseguite correttamente, la CA emette un documento elettronico in formato X.509, ovvero il certificato del titolare richiedente, contenente la chiave pubblica associata.
Chiunque può verificare la policy ed il certificato della CA, che la CA deve rendere pubblici all’interno del proprio Gruppo Chiuso di Utenza. La CA deve mantenere un Registro Pubblico dei Certificati emessi, una Lista dei Certificati Revocati (Certification Revocation List - CRL), e una Lista dei Certificati Sospesi (Certification Suspension List - CSL), che devono essere disponibili come stabilito dalla policy.
20
Firma Digitale e Non
Solitamente una CA può emettere tre tipi di certificati:
•
Personali, rilasciati a persone fisiche: contenengono informazioni quali nome, cognome, indirizzo, casella email, eccetera: possono essere utilizzati per garantire la provenienza di una email, per inviare un numero di carta di credito, per firmare documenti elettronici, e così via.
•
Server, rilasciati ai titolari di server che operano in rete (www, ftp, TSA, ...). Questi certificati sono emessi per garantire l’identità del server stesso, e sono particolarmente utili per implementare siti di commercio elettronico in cui i clienti vogliono essere certi di operare con particolari server, o per i server TSA (di marcatura temporale, TSA – Time Stamp Authority).
•
Software, per garantire l'autenticità della provenienza del software, specialmente se questo viene distribuito in Rete.
21
Firma Digitale e Non
E la quarta dimensione?
Dire che una persona ha firmato un documento, assumendone la paternità, non sempre è sufficiente. Spesso è importante definire con la maggior certezza possibile il momento in cui tale assunzione è stata fatta.
Se si parla di una poesia, o di un brano musicale, la cosa non è poi così determinante14. Ma quando si ha a che fare con documenti che comportano il passaggio di proprietà di un bene, o la cessione di valori, stabilire con esattezza il momento da cui il cambio o la cessione ha effetto è molto importante, in quanto la firma non è un atto fine a se stesso, ma un anello di una catena di eventi distribuita nel tempo.
Nel campo della firma olografa l’apposizione della nostra firma è accompagnata quasi sempre dalla contestuale apposizione di una data, e in alcuni casi anche dell’ora. Quando firmiamo un assegno dobbiamo mettere la data (onde evitare strani giochini con la valuta e il calcolo degli interessi), e quando l’agente assicurativo ci consegna la polizza auto firmata, compila l’ora da cui la polizza ha effetto.
Nel campo della firma digitale il problema si pone in modo analogo, ma la sua soluzione è leggermente più complicata. Un parallelo è, a questo punto, doveroso.
•
Se firmiamo un documento cartaceo, e scriviamo nello stesso documento un riferimento temporale (la data, ed eventualmente l’ora), inseriamo nel documento una informazione che ha la stessa fisicità delle altre informazioni15 (quali il titolo, il testo del documento, la firma, ...).
•
Quando si trattano documenti in formato elettronico, il corpo del documento viene racchiuso in una busta, ovvero l’insieme di una testata (in cui sono registrate le informazioni identificative del documento) e una coda (in cui sono registrate le informazioni accessorie)16. Questa formalizzazione è necessaria in quanto i documenti elettronici non sono trattati direttamente da esseri senzienti (come nel cartaceo), ma con il supporto di programmi di elaborazione che operano in base a schemi rigidi.
Ciò significa che a un documento firmato digitalmente dobbiamo aggiungere le informazioni relative alla data e ora di firma. Queste sono già incluse nel formato PKCS#7, ma sono quelle definite dall’orologio del computer su cui è stato creato il file firmato, e quindi non opponibili a terzi se non sulla base della buona fede del firmatario.
Per dare maggior enfasi e garanzia è possibile calcolare una marca temporale del file firmato, ovvero una evidenza firmata digitalmente da una entità esterna accreditata, che afferma in modo inequivocabile che il file firmato era tale a un certo tempo.
È un pò come firmare un documento davanti a un notaio, che sotto alla nostra firma appone una data, un’ora e la propria firma. Il notaio è l’entità esterna accreditata, la cui valenza è accettata anche in sede legale. Nel caso della firma digitale i notai coinvolti nel processo sono due:
1. il certificatore che ha rilasciato il certificato al firmatario, e che attesta la validità del certificato, della chiave segreta associata, ed entro certi limiti l’identità del firmatario, 2. il marcatore temporale, che attesta la certezza di esistenza del file firmato in un certo momento temporale.
14 ... ovviamente gli storici della letteratura o della musica non sono molto d’accordo al riguardo ...
15 Con fisicità si intende lo stesso pezzo di carta, fisicamente distinto da altri pezzi di carta (quali ad esempio una busta).
16 Si veda ad esempio il formato dei file PKCS#7 illustrato nei paragrafi precedenti.
22
Firma Digitale e Non
Marca Temporale: La certificazione del tempo
Stabilire con certezza il momento in cui un dato evento ha avuto luogo è una necessità sempre presente nella nostra vita, professionale e non.
Come stabiliamo “il momento” di un evento?
La risposta è semplice: con la memoria.
Ma non solo. La risposta completa è: con la memoria e con la sua affidabilità.
Quando ricordiamo un evento ricordiamo (salvo gli smemoranda
) anche il momento in cui si è verificato, e se
ci fidiamo della nostra memoria tanto ci basta.
Ma quando il momento in cui si è verificato un dato evento interessa non solo noi, ma anche altre persone, dobbiamo darne in qualche modo una evidenza comune. Se chiaccheriamo con un amico basta la nostra memoria e quanto riportiamo verbalmente (l’affidabilità è un componente di base dell’amicizia!).
Se invece l’evento si riferisce a un contesto non strettamente amichevole, e quindi soggetto in qualche forma a essere manipolato (quando ad esempio vendiamo l’automobile usata, o compriamo casa), abbiamo la necessità di identificare in modo univoco e possibilmente non contestabile il momento in cui l’evento si è verificato.
E qui la forma scritta diventa indispensabile
verba volant, scripta manent
...
ma scrivere su un pezzo di carta una data e/o un’ora non basta: ci vuole una assunzione di paternità di quanto afferma lo scritto, ovvero una firma.
In una scrittura privata si riporta data (e ora), e si appongono le firme degli interessati. E salvo prova contraria ciò è sufficiente a garantire quella che i legali chiamano “opponibilità a terzi”.
In una scrittura redatta da un notaio è la firma del notaio a garantire la veridicità di quanto affermato dallo scritto, data (e ora) compresa (un informatico direbbe, a questo punto, che il notaio è affidabile “per default”).
Quando dal mondo reale ci spostiamo al mondo elettronico dei documenti informatici abbiamo bisogno di qualcosa che ci dia le stesse garanzie temporali dell’orologio e del calendario del notaio. E qui ci viene in aiuto il meraviglioso mondo degli orologi atomici, e del loro utilizzo in Internet per garantire un allineamento globale degli orologi e della misura del tempo.
Una sorgente temporale globale e gratuita: il protocollo NTP
Sin dal momento della sua nascita la suite TCP/IP (sembra il nome di una collezione di mobili d’epoca!) ha previsto nei suoi protocolli l’NTP (Network Time Protocol – Protocollo del Tempo di Rete), identificato dal magico numerello del codice servizio 123 (si, proprio un, due, tre, e non è un caso).
Nello schema NTP una miriade di computer possono connettersi tra di loro per scambiarsi informazioni relative alla propria visione del tempo. Alcuni di questi computer fungono da server, altri (la maggior parte) da client. I server erogano informazioni attendibili sul tempo (in pratica, quando richiesti, dicono che ora è secondo loro), mentre i client allineano i propri orologi interni (i system clock) sulla base delle indicazioni ricevute dai server.
23
Firma Digitale e Non
I server si distinguono in base alla affidabiità delle loro sorgenti di riferimento temporale. Quei computer che possono avvalersi di dispositivi hardware (orologi atomici, connessioni via radio a orologi atomici ufficiali, ...) sono di classe stratum-1, mentre i server che non dispongono di dispositivi hardware e mantengono il loro system-clock aggiornato in base ad indicazioni che pervengono loro da server stratum-1, sono di classe stratum-2: e così di seguito si hanno server stratum-3 (che ridistribuiscono il tempo di server stratum-2), server stratum-4 (che ridistribuiscono il tempo di server stratum-3), sino ai server di affidabilità più bassa, gli stratum-16.
Gli elenchi ufficiali dei server pubblici stratum-1 e stratum-2 sono pubblicati sul sito ufficiale NTP
(http://www.ntp.org/), e in particolare all’indirizzo http://support.ntp.org/bin/view/Servers/WebHome.
Qualunque server o client che installiamo in casa nostra può richiedere il supporto della rete NTP (l’insieme distribuito dei server NTP stratum-1 e stratum-2), e aggiornare con costanza e sicurezza il proprio system-clock al prezzo di qualche pacchetto UDP scambiato ogni tanto sulla rete Internet: un aggiornamento ogni dieci minuti al costo di qualche decina di byte – una spesa folle
!!!
TSA, TSQ e TSR
Ma, ma, ma ...
... tutto ciò non è sufficiente. Chi ci assicura che il documento firmato in formato PKCS#7 riporti effettivamente una data-ora ricavata da un server NTP ufficiale?
Nessuno!
E allora ecco venirci in aiuto la nostra beneamata firma digitale. Se a indicare la data-ora del nostro file firmato è una entità terza accreditata (in gergo tecnico una TSA – Time Stamp Authority), che a lato della data-ora del documento mette la sua riverita firma digitale opponibile a terzi, allora siamo salvi. Evviva.
Ma se il file che stiamo firmando è, ad esempio, di 100 Mbyte cosa facciamo? Lo spediamo via rete alla TSA? E
scarichiamo da questa il file marcato temporalmente da 100 Mbyte? Una cosuccia un pò dispendiosa.
E ancora una volta dobbiamo richiedere l’aiuto degli amici matematici e del loro miracoloso hash (o impronta, ricordate?). E così procediamo in pochi semplici passi:
•
calcolo l’hash del file firmato (20 byte),
•
lo includo in una richiesta di marca temporale (TSQ – Time Stamp Query – un piccolo file di meno di 1
Kbyte),
•
invio la TSQ alla TSA,
•
la TSA trasforma la TSQ in una marca temporale firmata e opponibile a terzi (TSR - Time Stamp Response – altro piccolo file di circa 4 Kbyte contenente il mio hash e la data-ora certificata, il tutto firmato dalla TSA),
•
la TSA mi ritorna la TSR ...
sino ad associare a fianco del mio documento firmato (il file PKCS#7, con estensione .p7m) la sua marca temporale (il file TSR, con estensione .tsr). La coppia di file .p7m + .tsr mi permette finalmente di avere un documento elettronico, firmato digitalmente, marcato temporalmente, e opponibile a terzi.
Più difficile a dirsi che a farsi. Alla faccia di chi ci vuol male.
Una piccola nota: le TSA accreditate (dal CNIPA ovviamente) non lavorano gratis, e le marche temporali se le fanno pagare. In media circa 30 centesimi di euro a marca. Da utilizzare cum juicio direbbe il Manzoni.
24
Firma Digitale e Non
Marca temporale: lo standard RFC 3161
Tutto il ragionamento dei paragrafi precedenti è riassunto formalmente nello standard Internet RFC-3161
(Internet X.509 Public Key Infrastructure - Time-Stamp Protocol - TSP).
Questo standard definisce il contesto
“Un servizio di marcatura temporale supporta l’asserto probatorio che uno specifico dato esiste prima di un dato momento temporale.”
“I servizi di non ripudio (ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997) richiedono l’abilità di stabilire l’esistenza di uno specifico dato prima di un dato momento temporale.”
gli attori
“La TSA è un TTP (Trusted Third Party – terza parte affidabile) in grado di creare marche temporali al fine di indicare che uno specifico dato esiste prima di un dato momento temporale.” il come
“La TSA DEVE:
1. utilizzare una sorgente temporale affidabile;
2. includere un valore temporale affidabile in ogni marca temporale;
3. includere un nuovo numero intero univoco in ogni nuova marca temporale generata; 4. produrre una marca temporale ogni qualvolta riceve una richiesta valida da una entità richiedente, quando possible;
5. includere in ogni marca temporale un identificatore che indichi univocamente la policy di sicurezza adottata al momento di creazione della marca;
6. marcare temporalmente solo la rappresentazione hash del dato (ovvero una impronta numerica associata con una funzione hash a una via, resistente alle collisioni e univocamente identificata da un OID – Object IDentifier);
7. esaminare l’OID della funzione hash a una via resistente alle collisioni, e verificare che la lunghezza dell’hash sia consistente con l’algoritmo di hash.
8. non esaminare in alcun modo l’impronta che viene marcata temporalmente (ad esclusione della verifica della lunghezza, come sopra specificato);
9. non includere alcuna identificazione della entità richiedente nella marca temporale; 10. firmare ogni marca temporale utilizzando una chiave generata esclusivamente a questo scopo, con l’indicazione esplicita della finalità della chiave riportata nel certificato corrispondente; 11. includere nella marca temporale solo le estensioni supportate dalla TSA se richieste esplicitamente dalla entità richiedente – se non possibile la TSA DEVE rispondere con un messaggio di errore.” il cosa
“TSQ – la richiesta di marca temporale”
“TSR – la risposta di marca temporale”.
Il cosa è illustrato nelle figure alle pagine seguenti.
25
Firma Digitale e Non
Nella richiesta TSQ sono inclusi:
•
la versione della marca richiesta (attualmente v1)
•
l’algoritmo di hash
•
l’hash del file (o più generalmente del dato) da marcare
•
l’OID della policy di sicurezza richiesta alla TSA (opzionale)
•
il NONCE, un numero random di 64 bit generato dall’entità richiedente, e quanto più univoco possibile per il richiedente (opzionale)
•
il flag di richiesta di presenza del certificato di firma della TSA nella risposta (opzionale)
•
eventuali estensioni (opzionale).
File Originale da
marcare
TSQ
Version e
Alg oritmo HASH