La firma digitale è un meccanismo ampiamente riconosciuto, anche sul piano giuridico, pur rimanendo un istituto in continua evoluzione, come lo sono in generale le nuove tecnologie e, nel campo giuridico, la disciplina del diritto connesso all’uso di esse. In particolare il legislatore italiano ha fatto notevoli sforzi per definire un sistema di norme il più possibile solido, avviando fin dal 1997 (D.P.R 513/97) un percorso legislativo fatto di numerosi passaggi, tra i quali i più importanti sono quelli di coordinamento con la normativa comunitaria (Direttiva Europea 1999/93), che hanno portato dapprima alla revisione del D.P.R. 445/2000, e poi alla definizione di un “testo unico” che oltre alla materia della firma digitale e del documento informatico, ricomprende molte norme che regolano l’uso dell’informatica e delle nuove tecnologie nell’ambito della pubblica amministrazione (D.lgs n. 82 del 7 marzo 2005, detto Codice dell’Amministrazione Digitale) e per i contratti elettronici. Accanto al testo di legge principale, la firma digitale trova dettagliata regolazione nelle norme tecniche (quelle attualmente in vigore sono pubblicate con DPCM 13 gennaio 2004), soggette a periodica revisione, delle quali si attende nuova pubblicazione nel corso del 2008. Nella definizione e revisione delle regole tecniche, così come nella sorveglianza sull’attività dei Certificatori Accreditati, che costituiscono elemento essenziale ad assicurare alla firma digitale il valore di identificazione del firmatario, il CNIPA (Centro Nazionale per l’Informatica della Pubblica Amministrazione), organo operante presso la Presidenza del Consiglio dei Ministri, riveste un ruolo fondamentale rappresentando la massima autorità in materia.
Attraverso la firma digitale in Italia e in gran parte dei paesi esteri, è possibile attribuire al documento elettronico pieno valore probatorio, almeno uguale a quello tradizionalmente attribuito alla scrittura privata, quindi alla firma autografa. Tale dato giuridico è l’immediata conseguenza di scientifiche considerazioni, che si basano sulla tipologia di tecniche crittografiche che stanno alla base della firma digitale. In particolare la concreta impossibilità di produrre la firma di un documento informatico senza il possesso di una chiave segreta (opportuna sequenza di bit) con la quale il sottoscrittore, unico ed esclusivo possessore, esegue un noto algoritmo di crittografia (RSA) considerato di assoluta robustezza al fine di generare la firma stessa, offre la garanzia che la firma digitale possa assolvere a pieno alle sue funzioni di identificazione e di “approvazione” di ciò che il documento include, se si considera che la firma stessa è in grado di rilevare ogni minima modifica del contenuto del documento, e cioè ogni minima modifica dei bit di cui il documento è composto, che venisse apportata al documento dopo essere stato firmato. D’altra parte il meccanismo della certificazione offre elevate garanzie sull’identità del sottoscrittore, soprattutto quando il certificatore utilizzato è accreditato presso il CNIPA, come previsto ad esempio nel caso della Pubblica Amministrazione.
Non vi sono al momento debolezze del protocollo di firma digitale che possano consentire anomali comportamenti del documento informatico firmato, tali da consentire alterazioni e contraffazioni di documenti informatici firmati, che non siano contemplati dalla normativa tecnica vigente, e dalle raccomandazioni tecniche e pragmatiche che in ambito nazionale ed internazionale gli organi competenti (in Italia il CNIPA) impartiscono, e che, sulla base di tali prescrizioni, risultano realisticamente di difficilissima attuazione. Così dovrebbe rientrare nell’esperienza comune (almeno degli addetti ai lavori) l’evitare di firmare documenti su un computer “affetto” da virus, trojan horse, o altro software malicious, per il rischio che si possa firmare un documento diverso da quello voluto senza farlo apparire al sottoscrittore (ma il buon senso comune imporrebbe di evitare di usare un computer infetto anche per molte altre delicate attività, come l’home banking per esempio).
Dovrebbe ancora rientrare nella comune conoscenza il dover evitare di firmare un documento Word contenente macro istruzioni tali da modificarne il contenuto anche dopo la firma, semplicemente perché non sono i bit del documento a modificarsi (cosa che verrebbe rilevata dalla firma), ma solo il risultato dell’esecuzione di tali istruzioni, che potrebbero infatti dipendere da variabili esterne al documento e per questo mutare con il tempo. Per quest’ultimo punto le norme prevedono l’annullarsi dell’efficacia probatoria del documento, in modo da tutelare in giudizio, il sottoscrittore che avesse firmato un documento con tali caratteristiche, senza adottare le comuni tecniche che consentono di disattivare le macro-istruzioni prima della sottoscrizione. Per tale motivo alcuni formati vengono considerati più pericolosi di altri, e il CNIPA e altri organismi internazionali, hanno indirizzato gli utenti verso formati ritenuti più sicuri, perché consentono comportamenti “dinamici” del contenuto in misura minore. Tra i formati, quelli che escludono totalmente la possibilità di includere istruzioni, sono i formati immagine (bitmap, jpeg, tiff, etc), o il formato testo (txt).
L’attacco messo a punto da Buccafurri, Lax e Caminiti si basa sulla attuale assenza, tra gli elementi del file sottoposti a trasformazione crittografica nel processo di firma, dei meta-dati connessi alla tipologia di file, primo fra tutti il nome e l’estensione del file. Attraverso questo attacco, è possibile che Tizio firmi un contratto elettronico in formato ritenuto assolutamente sicuro (ad esempio un’immagine bitmap) di valore pari a 1.000 Euro, e che poi il documento firmato appaia al destinatario come un contratto di valore pari a 100.000 Euro, così come la stampa che del documento si potrà fare, semplicemente perché il nome del file firmato (di quello che tecnicamente prende il nome della busta crittografica) viene a posteriori modificato.

E' possibile scaricare qui un file di esempio dell'attacco, chiamato "contratto.bmp", il cui contenuto cambia in funzione dell'estensione (provare salvando il file in locale e rinominandolo in "contratto.htm").

Torna indietro