I saggi su SecLab

Firma digitale: ma siamo sicuri?

SecLab n° 3, marzo 2003

Recentemente due brutti colpi si sono abbattuti sulla già emaciata istituzione della firma digitale che, come tutti sanno, qui da noi per un motivo o per l'altro non è mai riuscita a decollare realmente. Fatto sta che nell'arco di pochi mesi sono emersi, ed hanno provocato non poco clamore sia fra gli addetti ai lavori sia presso il pubblico generale, due problemi che, per quanto di natura e portata ben differenti, tuttavia hanno contribuito a minare la fiducia dell'opinione pubblica (ed anche di non pochi giuristi) verso la reale affidabilità dei sistemi di firma digitale. Tutto ciò, assommato alle stranezze dei recenti regolamenti di riordino della materia, ha portato più di un operatore del diritto a porre in dubbio la validità in toto della firma digitale, aumentando così la già elevata confusione sulla materia. Ma come stanno realmente le cose?

Tutto è cominciato nello scorso autunno, quando una segnalazione sulla mailing list di sikurezza.org, subito ripresa dalla rivista giuridica on-line InterLex, fece emergere in tutta la sua rilevanza un problema in verità noto ai tecnici da tempo ma sino ad allora, chissà perché, ignorato dai più. Così quello che in un primo momento sembrava un semplice bug di DiKE, che è il software di firma digitale prodotto da Infocamere, si rivelò, ad una successiva e più meditata analisi, come un problema generalizzato ed inevitabile di cui soffrono tutti i sistemi di firma digitale, nessuno escluso ed eccettuato, quando sono chiamati a firmare documenti che… tali non sono! Il problema riguarda infatti più propriamente i documenti, non i software di firma, e si può riassumere in una sola domanda: cos'è un "documento firmabile digitalmente"?

Tutti noi abbiamo istintivamente presente il concetto di "documento", anche se probabilmente non ne conosciamo l'esatta definizione giuridica; e a quasi tutti noi sembra ovvio che un file di Word costituisca un ragionevole esempio di "documento", ancorché informatico. Eppure questa convinzione è falsa, ed è alla base del colossale qui-pro-quo che ha rischiato di far collassare l'istituto della firma digitale prima ancora che si affermasse realmente. Il problema sta nei campi variabili di Word e nelle sue macro, che consentono ad un documento di modificarsi automaticamente nella sua apparenza pur senza comportare una reale modifica a livello dei bit di cui è formato il suo file. Ad esempio un campo "data corrente" fa sì che il documento, ogni volta che viene aperto, mostri nell'intestazione la data del giorno attuale: da un certo punto di vista dunque il documento è stato modificato, nel senso che aprendolo evidentemente non appare più uguale a com'era ad esempio ieri; ma dall'altro non è stato modificato, in quanto ovviamente i bit del file sono uguali a com'erano ieri! Questo apparente paradosso scombussola i principi del diritto su cui si poggia l'istituto della firma digitale, i quali prevedono che il documento sia rappresentazione immutabile di atti, dati o fatti giuridicamente rilevanti; laddove l'immutabilità si riferisce ovviamente al contenuto informativo del documento ("quello che vedo sullo schermo") e non alla sua struttura fisica ("i bit registrati sul disco"). L'equivoco semantico, tranquillamente ignorato da tecnici e giuristi sino a che non è scoppiato il "caso DiKE", porta ad un dilemma assai spinoso: firmare digitalmente un documento contenente campi variabili, come lo sono i file di Word, è come chiedere al notaio di autenticare un documento scritto a matita, ossia assurdo. Eppure i documenti Word sono gli unici che in qualche modo vale la pena di firmare, perché costituiscono ormai lo standard di codifica documentale elettronica utilizzato in tutte le nazioni del mondo. La soluzione a questo dilemma non è stata ancora trovata…

E mentre i giuristi ed i tecnici ancora si accapigliavano sulla definizione di "documento" ecco arrivare, proprio pochi giorni fa, la seconda mazzata. Anche in questo caso sikurezza.org ed InterLex si aggiudicano il merito di aver portato alla ribalta il caso, che per fortuna riguarda questa volta un semplice (anche se dirompente) bug di un prodotto specifico. Nella fattispecie si tratta del programma "Firma&Cifra" di Postecom, un'applicazione di firma digitale piuttosto ben quotata in quanto prodotta da un ente sicuramente preparato ed affidabile. Ma i bug non risparmiano nessuno, come ben sa chiunque abbia provato a sviluppare software seriamente; e questa volta le spese le ha fatte Postecom, la cui immagine non ha certamente guadagnato dalla campagna che il bug ha suscitato. In poche parole è stato dimostrato che il software di verifica del prodotto "Firma&Cifra" è facilmente ingannabile: esso infatti può essere portato, con semplici artifici tecnici, a certificare la validità della firma digitale di un documento, e dunque in sostanza l'autenticità del documento stesso, anche quando il documento è assolutamente fasullo, con buona pace della sicurezza e della inviolabilità della firma digitale.

Questa volta il problema non è filosofico ma pratico: in sintesi ciò ce accade è che, se nella "busta" PKCS#7 che contiene il documento digitale firmato, la relativa firma digitale ed il certificato del firmatario, si inserisce anche il certificato "root" della Certification Authority con il quale è stato firmato il certificato del firmatario, il software di Postecom prende quest'ultimo certificato per buono, senza verificare se invece esso appartenga ad una Certification Authority reale ed autentica, e lo usa per autenticare il certificato del firmatario. Così per ingannare il software "Firma&Cifra" basta costruirsi in casa una CA, farle emettere un certificato "root" intestato a Postecom ed usare quest'ultimo per certificare un altrettanto fasullo certificato emesso a nome di un firmatario che desideriamo. Firmando un documento con quest'ultimo certificato, ed avendo cura di inserire nel PKCS#7 anche il certificato della nostra falsa CA, otterremo un documento falso che tuttavia "Firma&Cifra", nella sua ingenua fiducia, scambierà per buono. Una mancanza imperdonabile ed ingiustificabile, anche a valle delle "motivazioni" tecniche ufficialmente rilasciate da Postecom che purtroppo sembrano troppo simili ad un esercizio di libera arrampicata sugli specchi.

Cosa possiamo imparare da questi due episodi tanto diversi ma egualmente micidiali? innanzitutto che, come d'altronde avviene sempre in qualunque branca della tecnica, la teoria è un conto e la pratica è un altro. La sicurezza di un sistema non è quella del suo modello teorico ma quella effettivamente risultante da una sua implementazione reale, la quale può essere viziata da errori concettuali, di progetto, di sviluppo, di programmazione, di integrazione; tutti problemi che il modello teorico non presenta. Ciò potrebbe portare a biasimare il modello di sviluppo proprietario, nel quale è difficile accorgersi per tempo di tutti gli errori del software, ed a preferire invece quello di tipo open nel quale una parte fondamentale dello sviluppo è costituito dalla cosiddetta "peer review", ossia la revisione continua effettuata da un gran numero di utenti indipendenti. Tuttavia è utopistico credere che si possa realmente applicare il modello open nello sviluppo di software commerciale destinato ad ambienti ad alta competitività.

L'insegnamento vero dunque è un altro: quando si parla di tecnologie estremamente nuove, con forte impatto sociale e bassa penetrazione culturale, si deve istintivamente adottare un modello mentale basato sulla prudenza: solo dopo parecchio tempo di "rodaggio" dell'intera macchina, sia sul piano tecnologico che su quello giuridico-legislativo, si potranno abbassare gli schermi e procedere a tutta velocità. Ma sino a che l'uso della firma digitale non sarà diffuso come quello dei Bancomat, un po' di sana paranoia da parte di tutti gli attori in campo non guasterà, e probabilmente eviterà all'intero sistema ulteriori bruti scossoni che potrebbero anche metterlo KO.

Ultima modifica: 4 settembre 2006
Visitatori dal 6 maggio 2003: 29,466

Torna alla Pagina dei saggi sulla newsletter SecLab
Vai alla Pagina dei Commenti