Un Nuovo Attacco alla Firma Digitale

 

Sommario

Questo lavoro presenta un nuovo attacco alla firma digitale. I risultati qui solo accennati, saranno presentati alla "IEEE International Conference on the Applications of Digital Information and Web Technologies" (http://www.dirf.org/diwt2008/) nell'agosto 2008 e inclusi negli Atti della stessa conferenza.

 

Introduzione

La firma digitale è un elemento chiave nell'ambito di molti processi innovativi, con effetti negli ambiti del privato, della pubblica amministrazioni, ma più in generale del sistema economico-sociale. In particolare, le attività di e-government dovrebbero ricevere dalla firma digitale un forte impulso ad ampliare significativamente la loro azione e la loro efficacia. In ogni caso, la proprietà principale che la firma digitale deve soddisfare è quella di costituire, almeno tanto quanto la firma autografa, una prova non ripudiabile sia dell'identità del sottoscrittore del documento elettronico che dell'attestazione di ciò che il documento rappresenta. Quindi, ogni forma di vulnerabilità dovrebbe essere attentamente considerata allo scopo di comprendere se la firma digitale possa rappresentare per i documenti elettronici ciò che la firma autografa rappresenta per quelli tradizionali.

Il punto più critico del protocollo di firma è la segretezza della chiave privata. Essa dovrebbe essere garantita anche in caso di attacchi sofisticati, in quanto la sua compromissione potrebbe determinare conseguenze disastrose. L'uso di smart card sufficientemente sicure (le leggi della Comunità Europea impongono come livello minino l'ITSEC E3-high [16]) è una misura ragionevole per risolvere tale problema. Certamente, una smart card può essere considerata una piattaforma sicura anche perchè non è realistico immaginare che attacchi esterni possano avere successo. Sfortunatamente, la firma digitale non è esente da serie debolezze.

La vulnerabilità più nota è strettamente correlata al fatto che una smart card è un computer limitato [22], poiché manca dei dispositivi di I/O. Pertanto, in generale il processo globale di generazione della firma digitale non può essere considerato sicuro, poiché il PC utilizzato per generare l'impronta del documento da firmare (cui la smart card è necessariamente interfacciata) è potenzialmente insicuro. Il rischio concreto è che alla fine il PC possa ottenere dalla smart card una firma su un documento arbitrariamente scelto, diverso da quello visualizzato sullo schermo ed effettivamente scelto dall'utente. Chiaramente l'utente potrebbe non essere consapevole dell'esistenza di un siffatto documento, per cui tale problema può essere considerato molto grave. Secondo il parere di Rivest [21] esiste una contraddizione intrinseca tra possedere un dispositivo sicuro ed usare una “interfaccia utente ragionevolmente personalizzabile” che supporti il download delle applicazioni. In altri termini, si potrebbe pensare ad un’applicazione molto sicura per la firma digitale che sia eseguibile su computer stand-alone (portatili), tali da non permettere l'esecuzione di altri programmi. In caso contrario, il processo di firma digitale rimane inerentemente insicuro, poiché i PC non possono rappresentare piattaforme sicure. Rivest [21] suggerisce che la firma digitale non dovrebbe essere considerata come una prova non ripudiabile, ma semplicemente come un'evidenza plausibile. Così per gli utenti dovrebbero esistere casi ben definiti in cui poter ripudiare la firma. Il problema, ben noto in letteratura [14, 24, 3], è complesso e non ammette una soluzione completa fintanto che il PC è parte del processo di generazione della firma.

Recentemente sono state proposte soluzioni euristiche [8, 23, 18, 4, 17, 6, 7] che permettono di mitigarne le conseguenze.

Un'altra ben nota vulnerabilità è derivante dalla possibilità per i documenti di incorporare macro-istruzioni o codice eseguibile (si pensi ad esempio alle macro dei documenti Word, oppure al codice Javascript dei documenti PDF). Il problema è che un documento contenente istruzioni non è statico, nel senso che la visualizzazione (la presentazione) del suo contenuto potrebbe dipendere da tali istruzioni. Per esempio, si consideri il caso di un contratto che include un valore che dipende dalla data di sistema, in modo tale che, dopo una certa data, il valore visualizzato sia modificato. La firma digitale dovrebbe essere in grado di evitare la modifica di ciò che un documento mostra all'utente, allo scopo di garantire l'integrità dell'informazione, non solo in termini tecnici, ma anche dal punto di vista degli effetti (legali) prodotti dai bit che compongono i documenti digitali. Nell’esempio precedente, chiaramente i bit del contratto digitale non variano, ma il loro effetto, in termini di contenuto rappresentato, sì. Sfortunatamente, la firma digitale non è in grado di rilevare il comportamento dinamico del documento, tantomeno i suoi (pericolosamente dinamici) effetti legali, in quanto è ottenuta a partire dai bit che compongono il documento mediante l'applicazione di una funzione di hash crittografico prima, e l'esecuzione di un algoritmo di crittografia asimmetrica (tipicamente RSA [20]) poi. Questa vulnerabilità è ben nota ed il modo per contrastarla è banalmente quello di forzare l'utente a verificare la presenza di macro nel documento prima della firma, quindi assumendo che egli sia in grado di svolgere tale compito.

Un'ulteriore metodo suggerito è quello di restringere i formati permessi per i documenti a quelli che non supportano l'inclusione di istruzioni, come il testo (es. ASCII), PDF/A [19], ecc. Le regole tecniche tipicamente prendono in considerazione tale problema, concludendo che la firma non ha valore probatorio quando è applicata a documenti che incorporano istruzioni in grado di modificare ciò che tali documenti rappresentano (si veda per esempio la legislazione italiana a tal proposito [1]).

Questo articolo discute un attacco molto insidioso, mai documentato prima nella letteratura scientifica, né in ambito tecnico, legale o professionale, i cui effetti sono pari all'inclusione di istruzioni nei documenti digitali. Tuttavia, tali effetti sono ottenuti mediante manipolazione dei documenti, ma senza l'inserimento di alcuna istruzione, e pertanto essi non fanno parte dei casi considerati dalla legge. Inoltre, è possibile utilizzare l'attacco anche con quei formati (come quelli di tipo immagine) che sono considerati estremamente sicuri.

Il contributo dell'articolo è semplice, ma allo stesso tempo indiscutibilmente rilevante da un punto di vista pratico, poiché (1) l'attacco proposto ha successo nei confronti delle infrastrutture tecnologiche attualmente utilizzate ed approvate sia dalla legge che dagli standard industriali, e (2) la diffusione delle firme digitali è in rapida crescita. A sostegno di questa affermazione, giova ricordare che il Centro Nazionale per l'Informatica nella Pubblica Amministrazione (CNIPA) [9] ha considerato molto significativi [10] i risultati presentati in questo articolo, affermando l'intenzione di considerare il problema qui esposto sia nella prossima stesura delle regole tecniche che nella sede del Forum of European Supervisory Authorities for Electronic Signatures [13], di cui il CNIPA è membro.

 

L’attacco

L'attacco si basa sulla considerazione che l'utente che firma un documento ne conosce il contenuto sulla base di ciò che è visualizzato sullo schermo del PC. Ovviamente, il documento (cioè il file) sottoposto a firma consiste dei bit di cui è composto, ma il significato del documento -- che dipende dal modo con cui il documento è mostrato al sottoscrittore -- dipende dal software usato per la sua decodifica. Quindi le informazioni che riguardano il tipo del documento (che dipende direttamente dal modo con cui le informazioni incluse nel documento sono codificate e, conseguentemente, dal formato del file e dal software capace di gestirlo) non sono prese in considerazione durante il processo di firma, e quindi non sono in nessun modo incluse nella busta crittografica.

Ad esempio consideriamo un utente che firma un file picture.bmp. Dopo l'applicazione della firma digitale a questo file verrà generata la busta crittografica in formato PKCS\#7 che sarà salvata con nome picture.bmp.p7m, perchè il software di firma aggiunge l'ulteriore estensione .p7m al nome iniziale del file. Se l'utente estrae il documento dalla busta crittografica, il nome del file firmato è ottenuto da quello della busta dopo la rimozione della seconda estensione ( .p7m), visto che l'informazione relativa al nome del file non è memorizzata nella busta. Di conseguenza il software di verifica non può rilevare una eventuale modifica fatta al nome del file. Nel caso in cui il file picture.bmp.p7m sia (per errore o volontariamente) rinominato, ad esempio in picture.htm.p7m, la procedura di verifica della firma ha ancora successo, ed il file è estratto e rinominato in picture.htm.

L'indipendenza della firma dal nome del file non è stata ritenuta una debolezza, in quanto relativamente al legame tra documento e firma, quest'ultima deve essere connessa solo ai bit contenuti nel documento. Ciò potrebbe non sembrare un rischio per la robustezza della firma digitale in quanto è prevedibile che una sequenza di bit significativa in un certo formato non lo è in un altro. Ad esempio, nel caso precedente, i bit del file picture.bmp interpretati in formato HTML non producono alcun significativo risultato.

Il fondamento del nostro attacco risiede nella falsità di questa assunzione. Infatti, una prefissata sequenza di bit potrebbe essere interpretabile in formati differenti producendo contenuti molto differenti. Questa affermazione verrà provata attraverso esempi, per mezzo dei quali descriveremo il nostro attacco alla firma digitale.

 

Iniziamo considerando un file bitmap con estensione .bmp che rappresenta un'immagine I. Con un editor esadecimale, conoscendo il formato bitmap [5], modifichiamo alcuni bytes inserendo il tag HTML per l'apertura di commento (<!--) (un commento è ignorato dall'interprete HTML). Quindi creiamo un opportuno file HTML che include un testo T. Inseriamo all'inizio del file HTML il tag HTML di chiusura di commento ( -->). Infine accodiamo il file HTML al file modificato dell'immagine. Il file risultante è visualizzato correttamente da un visualizzatore bitmap che mostra l'immagine I. Cambiando l'estensione da .bmp a .htm, il file verrà aperto dal browser che mostrerà il testo T anzicchè l'immagine I. Questa procedura di attacco può essere applicata anche ad altri formati quali .pdf, .tif, .ps, .rtf, .doc, ....

Un esempio concreto di attacco è il seguente.

Tizio vuole delegare Caio a firmare al suo posto contratti di valore inferiore a 1.000 euro. Tizio chiede a Caio di preparare la delega in formato elettronico, e per evitare la possibile inclusione di macro codice chiede che il documento sia ottenuto come scansione del documento stampato (un'immagine non può avere una visualizzazione non statica). Caio modifica opportunamente (come sopra descritto) i bit del file ottenuto dalla scansione.

In dettaglio, dopo i primi due byte del file immagine inserisce la sequenza <!--, come mostrato in Figura 1.

 

Figura 1: Modifiche alla bitmap

 

Inoltre accoda al file il tag HTML di chiusura del commento ( -->) seguito dal codice HTML che permette la visualizzazione del contenuto desiderato

Caio salva quindi l'immagine come delegation.bmp e la invia a Tizio per essere firmata. Il contenuto del file delegation.bmp è visualizzato in Figura 2.

 

Il sottoscritto Tizio, delega Caio a sottoscrivere contratti di acquisto in sua vece per un valore non superiore a 1.000 Euro
 

In Fede    
Tizio      

Figura 2: Il File delega.bmp

 

Tizio firma il documento e produce la busta crittografica con nome delega.bmp.p7m. Poichè la firma è stata correttamente generata ed il documento non è stato alterato, il processo di verifica della firma ha successo.

A questo punto Caio completa l'attacco semplicemente modificando il nome della busta crittografica da delega.bmp.p7m a delega.htm.p7m. Poiché la verifica della firma è fatta sulla base dei bit contenuti nella busta crittografica, che non contiene il nome del file, il cambio del nome del file non modifica l'esito della verifica. Infatti, la verifica effettuata sulla busta rinominata ha successo. In Figura 3 è mostrato il documento che risulta firmato.

 

Il sottoscritto Tizio, delega Caio a sottoscrivere contratti di acquisto in sua vece per un valore non superiore a 100.000 Euro

In Fede    
Tizio      

Figura 3: Il risultato dell'attacco

 

Il documento appare differente da quello firmato. Infatti ora la delega consente a Caio di firmare per conto di Tizio contratti di valore inferiore a 100.000 euro invece di 1.000 euro come richiesto da Tizio. Si osservi che l'attacco ha successo su qualsiasi Sistema Operativo che riconosce il tipo di file attraverso l'estensione (come Microsoft Windows, Linux/KDE, MacOsX, etc.)..

 

Una possibile soluzione allo schema d'attacco descritto in precedenza consiste semplicemente nell'includere il nome del file e la sua estensione nella busta crittografica in modo tale che sia garantita l'integrità non solo del contenuto del documento ma anche del suo nome. A tale scopo possono essere utilizzati gli "authenticated attributes" del formato PKCS#7. La soluzione da noi proposta è simile a quella suggerita in [2], in cui il formato del documento è incluso come tipo MIME nell'attributo content-hints del Cryptographic Message Syntax (CMS) [15]. Ciò è stato fatto in base alle specifiche tecniche e alle raccomandazioni fornite in [2, 11, 12], in cui sono discussi, ma in modo soltanto teorico, i problemi derivanti dalla scorretta determinazione del formato del file (senza alcun specifico riferimento ad un attacco concreto).

References
[1] Italian technical rules (DPCM 13 gennaio 2004). http://www.cnipa.gov.it/site/_files/DPCM 040113_v2.pdf.
[2] ETSI Technical Specification TS 101 733 V1.7.3., 2007.
[3] M. Abadi, M. Burrows, C. Kaufman, and B. Lampson. Authentication and delegation with smartcards. In TACS’91: Selected papers of the conference on Theoretical aspects of computer software, pages 93–113, Amsterdam, The Netherlands, The Netherlands, 1993. Elsevier Science Publishers.
[4] Istvan Zsolt Berta, Levente Butty, and Istvan Vajda. Mitigating the untrusted terminal problem using conditional signatures. In ITCC ’04: Proceedings of the International Conference on Information Technology: Coding and Computing, Vol. 2, page 12. IEEE Computer Society, 2004.
[5] BMP file format fromWikipedia. http://en.wikipedia.org/wiki/BMP_file_format.
[6] Francesco Buccafurri and Gianluca Lax. Hardening digital signatures against untrusted signature software. In Proceedings of the 2nd IEEE International Conference on Digital Information Management (ICDIM’07), pages 159–164, 2007.
[7] Francesco Buccafurri and Gianluca Lax. Signing digital documents in hostile environments. International  Journal of Internet Technology and Secured Transactions, 2008. ISSN: 1748-5703.
[8] Dwaine Clarke, Blaise Gassend, Thomas Kotwal, Matt Burnside, Marten van Dijk, Srinivas Devadas, and Ronald Rivest. The untrusted computer problem and camera-based authentication. In Proc. of the 1st Int. Conf. on Pervasive Computing, volume 2414 of LNCS, pages 114–124. Springer-Verlag, 2002.
[9] CNIPA. http://www.cnipa.gov.it.
[10] CNIPA. Personal communication, 2008.
[11] European Committee for Standardization. CWA14170 - Security requirements for signature creation applications, 2004.
[12] European Committee for Standardization. CWA14171 - General guidelines for electronic signature verification, 2004.
[13] FESA. http://www.fesa.eu.
[14] H. Gobioff, S. Smith, D. Tygar, and B. Yee. Smart cards in hostile environments. In Proceedings of the 2nd USENIX Workshop on Electronic Commerce, pages 23–28, 1996.
[15] R. Housley. Cryptographic Message Syntax (IETF RFC 3852), Vigil Security, 2004.
[16] ITSEC. Information technology security evaluation criteria: Preliminary harmonised criteria. June 1991. Document COM(90) 314, Version 1.2. EU Commission.
[17] B. Lee and K. Kim. Fair exchange of digital signatures using conditional signature. In Symposium on Cryptography and Information Security, 2002.
[18] T. Matsumoto. Human-computer cryptography: An attempt. In ACM Conference on Computer and Communications Security, pages 68–75, 1996.
[19] PDF/A Competence Center. http://www.pdfa.org.
[20] R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM, 21(2):120–126, 1978.
[21] Ronald L. Rivest. Issues in cryptography. In Computers, Freedom, and Privacy Conference, 2001.
[22] B. Schneier and A. Shostack. Breaking up is hard to do: Modelling security threats for smartcards. In Proc. USENIX Workshop Smart Card Technology, 1999.
[23] Tage Stabell-Kulo, Ronny Arild, and Per HaraldMyrvang. Providing authentication to messages signed with a smart card in hostile environments. In Proceedings of the USENIX Workshop on Smartcard Technology, 1999.
[24] Bennett Yee and J. D. Tygar. Secure coprocessors in electronic commerce applications. In Proc. of the first USENIX Workshop on Electronic Commerce, pages 155–170, 1995.

 

Home Page