Ci mancava anche questa. Come se la firma digitale, qui da noi, avesse bisogno di altri ostacoli ed inciampi sul suo già accidentato cammino. Eppure si è montato il "caso": la notizia ha rimbalzato rapidamente fuori e dentro la Rete e, come nel gioco del "telefono senza fili" che facevamo da bambini, ad ogni rimbalzo si è colorita di nuovi ed inediti risvolti, giungendo alla fine ad essere totalmente stravolta.
Tutto è iniziato qualche giorno fa quando ci si è accorti di uno strano comportamento di DiKe, il software di firma digitale di InfoCamere. Firmando con esso un file Word comprendente macro o campi variabili, è possibile in seguito ottenere dal programma la verifica della firma stessa (e dunque la certezza dell'integrità del documento Word) anche se il documento appare chiaramente modificato, appunto nei campi variabili, rispetto a com'era al momento in cui è stato firmato (vedi Tra i "bachi" delle norme e quelli dei programmi di Manlio Cammarata e La firma è sicura, il documento no di Andrea Gelpi).

All'inizio sembrava trattarsi di un semplice bug del prodotto di InfoCamere. Con più calma (ma non ci voleva molto a capirlo) ci si è accorti che il problema era ovviamente generalizzabile a tutti i software di firma digitale, ed è scoppiato il pandemonio. Attorno al caso si sono allora formati due partiti: i "catastrofisti" che si sono sentiti legittimati ad affermare che la firma digitale è inutilizzabile tout court, e gli "inquisitori" che se la sono presa con l'inaffidabilità dei certificatori e dei software da essi prodotti. In parte questi due atteggiamenti riflettono le posizioni contrapposte dei giuristi e dei tecnici: i primi sostengono in buona sostanza che dal momento che la firma digitale sbaglia non possiamo più usarla né darle valore legale, i secondi ribattono che "a firma digitale non sbaglia, occorre solo usarla nel modo giusto. Il bello è che tali posizioni pregiudizialmente conflittuali sono, in certa misura, entrambe giuste!

Vale forse la pena, a questo punto, di tentare di fare un po' di chiarezza sulla situazione, cercando di capire non solo qual è esattamente il problema, ma soprattutto se e come si può cercare di risolverlo. Prima però vorrei notare che ad oggi l'unico effetto di questa bagarre, la quale a volte è sembrata più un dialogo tra sordi che un dibattito costruttivo, è che il proverbiale uomo della strada (o, peggio, qualche parlamentare poco informato.) ascoltandola si è vieppiù convinto che della firma digitale non ci si può fidare, e quindi "meno male che non la stiamo usando". Peggio di così non poteva andare.

Tuttavia non si può evitare di affrontare la questione, liquidandola, come molti hanno fatto, con un'alzata di spalle: il problema c'è davvero ed è anche dannatamente serio, come vedremo. Ed è anche, purtroppo, di difficilissima soluzione, perché non è un problema (solo) tecnico. Siamo nella classica situazione in cui bisogna cercare di salvare capra e cavoli; questa volta però non è detto che ci si riesca, forse occorrerà sacrificare qualche cavolo.

Per capire dov'è il problema cerchiamo innanzitutto di andare a vedere cosa succede esattamente nel caso incriminato. Facciamo dunque un passo indietro.
Quando firmiamo digitalmente un file, non facciamo altro che leggere uno alla volta i bit di quel file, effettuare su di essi un determinato calcolo standard, detto hash, ed infine cifrare il risultato di questo calcolo con la nostra chiave crittografica segreta per "sigillarlo" in un involucro impenetrabile che lo protegge e lo autentica. Il risultato di quest'ultima operazione è la famigerata "firma digitale" da noi generata ed associata a quel documento.

Qualcuno che in seguito volesse verificare l'autenticità di questa firma digitale, dovrebbe innanzitutto ripercorrere il medesimo processo: ossia prendere il file in questione, leggerlo un bit alla volta e calcolare l'hash secondo il metodo standard; poi dovrà prendere l'hash che abbiamo precedentemente cifrato e vedere se è uguale a quello che lui ha appena calcolato. Per fare ciò dovrà procurarsi la nostra chiave crittografica pubblica e decifrare con essa il valore da noi in precedenza fornito per l'hash cifrato. Se il risultato di questa decifrazione corrisponde al calcolo dell'hash del documento da lui appena fatto, egli non può che avere la certezza che il documento è rimasto integro ed immutato da quando è stato firmato, in quanto l'hash che avevamo in precedenza calcolato e "sigillato" coincide con l'hash attuale del file da lui appena ricalcolato; ma siccome nessuno può avere modificato il risultato del nostro calcolo precedente, in quanto impenetrabilmente cifrato con quella particolare chiave crittografica che solo noi al mondo possediamo, ne consegue che l'autore della "firma" originaria siamo necessariamente noi ed essa si riferisce certamente al file in questione.

In pratica tutte queste operazioni vengono svolte automaticamente dal software. Nel caso particolare della firma digitale "qualificata" secondo la normativa italiana, la chiave pubblica viene prelevata direttamente dal certificato inserito nella "busta" insieme al documento, secondo lo standard PKCS#7. La sostanza non cambia.
Non ci sono modi per scappare a questo ferreo processo. La fase di verifica è oggettiva e ripetibile in quanto legata ad un preciso calcolo: se il risultato collima col previsto la firma è autentica, altrimenti no. Fortunatamente la matematica non è una questione di opinioni.

La firma digitale, dunque, stabilisce in modo matematicamente certo. che cosa? Che un certo file è rimasto identico, bit per bit, rispetto a com'era nel momento in cui qualcuno l'ha "fotografato", sigillando poi questa "foto" con una speciale ceralacca digitale. Tutto qui. Il processo di firma digitale non può e non deve entrare nel merito di cosa sia il file in questione, di cosa rappresenti, di cosa significhi. Un file è una determinata sequenza di bit, punto e basta. L'interpretazione del suo significato dovrebbe essere lasciata ai programmi applicativi che dovranno gestirlo, non dovrebbe riguardare il software che genera o verifica la firma digitale.

Veniamo così al punto dolente. La firma digitale funziona benissimo. Il problema è a monte ed è più sottile, direi quasi filosofico. Il problema vero è: che cos'è un "documento"? O, per essere più precisi, dato il contesto: cos'è un "documento informatico"? Bene, se siamo giuristi possiamo dire che un documento informatico è "una rappresentazione informatica di atti, dati o fatti giuridicamente rilevanti"; se siamo tecnici possiamo dire che un documento informatico è un file, una sequenza di bit che rappresentano qualcosa sotto forma digitale (un testo, un'immagine, un suono, .). In entrambi i casi ciò che viene sottinteso è che un "documento" è qualcosa di statico, ossia di intrinsecamente immutabile; o meglio ancora, che rappresenta un contenuto immutabile (su questo punto vedi Funziona o non funziona? L'aspetto legale di Manlio Cammarata).

Non sto facendo il sofista: nel nostro caso la distinzione tra rappresentazione immutabile e contenuto immutabile non è un bizantinismo, ma è proprio la chiave del problema. Il quale, come dicevo prima, non è strettamente tecnico e soprattutto non è legato alle procedure ed agli algoritmi della firma digitale, né tantomeno alla loro specifica implementazione in questo o quel prodotto di mercato: ma proprio al concetto di "documento" come oggetto "firmabile". La domanda che dobbiamo farci è dunque: l'oggetto di firma è il contenitore o il contenuto?

Mi spiego con un esempio. Supponete di avere un programmino a linea di comando (come quelli che usavano ai tempi del DOS) che si chiama OGGI.EXE e che, quando viene eseguito, scrive su una riga dello schermo la data del giorno corrente. Un vostro amico esperto di diritto, ma assolutamente digiuno di computer, vede il programma, lo "apre" varie volte e si accorge che scrive sempre "25/09/2002"; egli pensa dunque che il file OGGI.EXE altro non sia che una qualche forma di documento il quale contiene al suo interno la stringa fissa "25/09/2002". Decide quindi di firmarlo digitalmente, ed usa a tale scopo un qualsiasi prodotto di firma digitale a norma di legge. Qualche giorno dopo il vostro amico "apre" di nuovo quel "documento" e si accorge che il suo contenuto è stato modificato: esso infatti adesso "contiene" la stringa "30/09/2002". Ne verifica dunque la firma digitale ma scopre con sgomento che essa non rileva anomalie di sorta: secondo il programma di verifica, infatti, il "documento" OGGI.EXE è rimasto assolutamente immutato rispetto a ieri. La conclusione che il vostro amico trae, perfettamente logica dal suo punto di vista, è che il programma di firma digitale non funziona perché non si è accorto che il "documento" OGGI.EXE è stato modificato!

Ecco quindi il vero busillis. Il vostro amico ha ragione ma ha contemporaneamente torto. Il programma di verifica della firma digitale non ha sbagliato: il file OGGI.EXE ovviamente non è stato modificato. Il fatto è che esso è un programma, non un documento nel senso comune che diamo a questo termine. È una sequenza di istruzioni, le quali pur rimanendo certamente sempre uguali a sé stesse (e ci mancherebbe anzi che cambiassero!) producono risultati diversi a seconda della situazione. E' dunque un contenitore statico ed immutabile, mentre il contenuto che rappresenta, che è poi il vero "documento" nel senso stretto di contenuto informativo, non è evidentemente né statico né immutabile.

L'errore dunque non è né nel programma in sé, né nelle procedure di firma digitale: l'errore è semantico, e consiste nell'aver scambiato il contenitore per il contenuto. Parafrasando in altri termini, è come se un notaio vi autenticasse con il suo sigillo tondo non il documento che gli portate ma la cartellina, aperta, nella quale glielo consegnate: ovviamente l'autentica sulla cartellina non garantirebbe in alcun modo l'integrità del suo contenuto, il quale può essere variato senza alterare minimamente l'integrità della cartellina stessa.

Nel caso particolare del file di Word le cose stanno esattamente allo stesso modo. Purtroppo Word non è solo un elaboratore di testi: esso è un programma a sua volta programmabile, ossia può eseguire particolari meta-istruzioni che servono ad automatizzare determinati compiti ripetitivi i quali altrimenti andrebbero svolti manualmente dall'utente. Uno di questi compiti è, ad esempio, l'inserimento all'interno di un documento della data e dell'ora correnti. Per fare dunque in modo che un documento utilizzato di frequente mostri sempre la data aggiornata, senza doverla correggere ogni volta a mano, basta indicare a Word di inserire lui, automaticamente, la data corrente nella posizione indicata. Ciò si fa inserendo nel documento un apposito comando sotto forma di campo variabile. Questi altro non è che una meta-istruzione che Word, a tempo debito, eseguirà per ottenere un risultato, il cui valore verrà inserito nel documento al posto giusto. Un po' come il nostro programma OGGI.EXE visto poco fa.

Se adesso firmate digitalmente questo documento Word, vi mettete nella stessa situazione in cui si è messo il vostro ipotetico amico di prima quando ha firmato il programma. Domani il vostro documento Word mostrerà una data differente: tuttavia la verifica della sua firma digitale non segnalerà nessuna variazione all'interno del file. Ciò è perfettamente corretto: il file in effetti non è cambiato, dato che la sequenza di istruzioni che inserisce la data nel documento è rimasta sempre uguale; è solo il risultato di questa sequenza di istruzioni ad essere diverso, e certamente il software di firma digitale non può saperlo!

Questo della data è solo il caso più eclatante. Sfruttando l'estrema programmabilità dei documenti Word si possono congegnare situazioni molto più perverse: ad esempio creare documenti che appaiono a video in un modo e in stampa in un altro, oppure documenti che prima di una certa data appaiono in un modo e dopo quella data in un altro. Pensate ad esempio ad un contratto in cui la cifra dell'importo da pagare si dimezza (o cambia segno!) qualche giorno dopo la stipula.

Il problema così com'è stato esposto non riguarda, com'è chiaro, nessun software specifico di firma digitale. Anche l'onesto PGP non può che verificare, in perfetta buona fede, che il file Word (ma non ciò che rappresenta!) non è stato modificato. Tuttavia nel caso specifico di DiKe c'è in effetti un'aggravante: questo software infatti si fa vanto di riconoscere il tipo di file, per poterlo aprire ed interpretare al suo interno. Per DiKe dunque il file Word non è un'anonima sequenza di bit ma è un oggetto con nome e cognome, dalla struttura nota. Tant'è che il suo contenuto viene visualizzato all'interno del browser di cui il programma è dotato. Ciò avviene probabilmente invocando il motore stesso di Word tramite l'apposita interfaccia di programmazione, ma questo non cambia nulla: il fatto è che DiKe stesso si fa carico di aggiornare i campi variabili del documento quando lo mostra, anche se questo è in palese contrasto con la logica della firma digitale.

Tale comportamento è senz'altro fuorviante, e contribuisce ad aggravare un problema che già di per sé risulta piuttosto scabroso. In teoria un software di firma digitale non dovrebbe occuparsi di comprendere cosa sta firmando o verificando: se lo vuole fare ben venga, ma almeno che lo faccia bene!

Quale può essere infine la conclusione di questa vicenda?
La risposta non è facile. Il buon senso suggerirebbe di risolvere il problema limitando il novero dei documenti firmabili digitalmente ai soli formati "puri", non programmabili, immutabili ed assoluti. Ossia ai veri documenti, e non ai meta-documenti come sono quelli di Word o di Excel. Tuttavia questi ultimi formati sono proprio quelli di utilizzo e scambio più comuni sia fra privati che fra aziende, quindi metterli "fuori legge" per quanto riguarda la firma digitale significherebbe limitare automaticamente portata ed utilità della norma sulla firma digitale stessa.

L'alternativa tuttavia è altrettanto insoddisfacente: essa consisterebbe nell'inserire nei prodotti di firma digitale della "intelligenza", sotto forma di conoscenza dei formati nativi e proprietari dei vari word processor o spreadsheet programmabili, per fare in modo che all'atto della firma i software possano accorgersi della presenza di campi variabili e prendere così gli opportuni provvedimenti. Il che però significa che il produttore del software in questione avrebbe l'obbligo di supportare tutti gli standard di mercato, non solo per quanto riguarda i word-processor ma anche per altre categorie di documenti (ad esempio i formati AutoCAD per schemi meccanici), con la necessità di apportare aggiornamenti al prodotto ogni volta che un formato di mercato cambia, e così via.

Come se non bastasse, questo approccio presenta anche nuovi problemi metodologici: ad esempio, cosa dovrebbe fare un programma di firma qualora si accorgesse che il documento che sta firmando contiene campi variabili? Fermarsi e rifiutare di andare avanti? Modificare il documento, sostituendo tutti i campi variabili con i valori da essi rappresentati in questo preciso momento? In linea di principio entrambi questi comportamenti sembrano ugualmente complessi da ottenere, ma a ben pensarci non ci sono molte altre alternative.

Insomma, in un modo o nell'altro, dal punto di vista tecnico, ci andiamo a cacciare in un ginepraio dal quale è difficile uscire senza graffi.