Un nuovo attacco alla firma digitale

English version

 

Questo sito documenta un recente risultato scientifico relativo ad un nuovo attacco alla firma digitale. Allo scopo di evitare cattive interpretazioni chiarisco da subito che l'attacco non riguarda la robustezza degli algoritmi e hash crittografici usati per la generazione e la verifica della firma. Riguarda invece sia le procedure attualmente utilizzate per "confezionare" la busta crittografica e verificare la validità della firma, che le informazioni incluse nella stessa busta crittografica.

 

A causa di recenti articoli apparsi sul Web, redatti sulla base di una cattiva interpretazione dei nostri risultati scientifici è opportuno, prima di presentare l'attacco, offrire alcuni chiarimenti in forma di risposta alle obiezioni mosse nei riguardi dell'attacco:

 

1. Obiezione: "Il bug non è della firma ma è di Windows" 

Innanzi tutto l'attacco ha successo non solo su Windows (che è il più diffuso SO per PC al mondo), ma anche con altri SO come Linux/KDE, free BSD/KDE e MacOSX. In secondo luogo l'attacco infatti "sfrutta" una caratteristica comune a molti SO (in quelli Unix-like la cosa dipende dal window manager) per la quale il tipo di file viene riconosciuto attraverso l'estensione. Di per sé essa non è ritenuta una vulnerabilità né in contesto scientifico né in contesto commerciale.

Non si può quindi affermare che ciò che documentiamo nel lavoro sia una vulnerabilità dei SO (men che meno solo di Windows). 

Infatti un sistema software è sicuro se non è possibile sfruttare sue debolezze intrinseche o sfruttare caratteristiche dell'ambiente in cui è eseguito per determinarne un comportamento malicious. 

La vulnerabilità che abbiamo rilevato riguarda il sistema di firma, in quanto sfruttando le (lecite) caratteristiche dei Sistemi Operativi (l'ambiente in cui è eseguito) è possibile determinare un comportamento malicious.

 

E’ interessante considerare la seguente metafora: 

Se il 99.99% delle strade del mondo presenta dossi (o buche), e viene progettata un'autovettura che appena incontra un dosso esplode, e per evitare questo sarebbe sufficiente una minima modifica nel progetto dell'autovettura, il problema riguarda la strada o l'autovettura?

La risposta è immediata.

Le strade, nella metafora, sono i SO su cui sono elaborati i documenti. Quelli che ho elencato sopra coprono forse più del 90% dei PC in uso. L'autovettura è il sistema di firma. Che si intende non soltanto gli algoritmi, ma il modo con cui li usiamo. Perciò busta, sw di generazione e verifica, etc.

Cioè ciò che rende diversa la teoria dalla pratica, che alla fine è quella che riguarda tutti.

2. Obiezione: "La firma digitale non è stata falsificata" 

In senso tecnico la firma non viene falsificata con questo attacco. Possono però essere realizzati dei documenti informatici “falsi”, cioè alterati. Non abbiamo mai affermato nella nostra ricerca che abbiamo falsificato la firma digitale, cioè che la debolezza individuata riguardi gli algoritmi di firma (hash inclusi) .
Tuttavia essa è una debolezza degli strumenti di firma compliant alla normativa europea (nella quasi totalità). E' un problema di rilevanza pratica perché l'attacco riesce, e questo è indiscutibile.

3. Obiezione: "Questo attacco è noto da tempo" 

Fino ad Aprile 2008, e cioè fino al momento in cui il lavoro è stato messo a disposizione del CNIPA e inviato a conferenza, non risulta alcuna documentazione che dimostri tale affermazione.

4. Obiezione: "Questo attacco è identico a quello basato su istruzioni incluse nei documenti (detti non–statici) già noto dal 1999" 

Certamente no. Quel tipo di attacco, che opera per esempio sui file di Word attraverso le macro-istruzioni, comporta la modifica di ciò che viene presentato all’utente, in funzione della modifica di variabili esterne (per es., la data del sistema). Quell’attacco è ben noto e ampiamente documentato, vi è anche letteratura scientifica circa le strategie di contrasto. Tuttavia, sebbene gli effetti di questo attacco siano simili a quelli del nostro, quest’ultimo agisce attraverso una tecnica profondamente diversa, in quanto nel documento compromesso è presente solo html con comportamento totalmente statico, compliant anche con la normativa europea più stringente (che è quella Slovena).

Infatti, nel documento sloveno "Specifying the content and formal specifications of  document formats for QES" è richiesto per l’HTML:
"A document in HTML and XHTML shall contain only static objects and all necessary document components shall be directly in HTML and XHTML document, i.e. it shall not contain references on external resources that might change visualization. HTML and XHTML shall not contain other document types than defined in [19] and pictures which visualization is not unambiguous, i.e. animations and pictures with used lossy (irreversible) compression.".
Inoltre la normative tecnica Europea più stringente rispetto alle minacce basate sulla presenza di codice nei documenti è il documento CWA 14170:2004, che, prevede come “Security Requirement” "An SDP capable to make the signer sign only a static document format”.
Il nostro attacco agisce anche su formati totalmente statici. Quindi anche se formalmente l’HTML incluso nel BMP del nostro attacco può essere denotato come “codice” presente nel documento, essendo esso STATICO, non riguarda le minacce fino ad oggi note.
Che i due attacchi siano profondamente differenti dal punto di vista della modalità di funzionamento lo si comprende anche dal fatto che la nostra soluzione (inclusione di nome + estensione) negli “authenticated attributes” della busta PKCS#7, che è risolutiva nel nostro caso, non è efficace per gli attacchi basati sulla presenza di codice. Viceversa, la disattivazione dai formati che lo consentono dei meccanismi che prevedono l'inclusione di istruzioni al fine di dare al documento un comportamento dinamico (es. disattivazione delle macro di Word, javascript in pdf o html, etc.), lascerebbe inalterata la possibilità di condurre a termine con successo il nostro attacco.
Una implicazione pratica di quanto detto prima è che, rispetto al rischio derivante dalla presenza di codice nei documenti, fino ad oggi nessuno avrebbe reputato pericoloso un documento sottoposto a firma di tipo bitmap (che, di fatto, non può avere contenuti dinamici, non ha riferimenti a risorse esterne, animazioni e immagini con compressione lossy), visualizzabile correttamente con un viewer di immagini. D'altra parte i formati immagine e i formati txt sono stati considerati gli unici totalmente esenti dal rischio di comportamento dinamico fino ad oggi.

5. Obiezione: "Il livello di pericolosità è trascurabile" 

Non direi trascurabile, anche se sicuramente non è alto. Tutto dipende dall’uso della firma, dalla quantità di documenti firmati gestiti dal singolo utente, dal fatto che la firma venga usata nel contesto del commercio elettronico o meno, dal livello di alfabetizzazione delle vittime, da tanti fattori. Se firmo un form Web, e magari non visualizzo neppure le estensioni, e poi “uploado” il form (html) firmato, se la parte con cui opero è l’attaccante, può successivamente modificare l’estensione e poi contestarmi un pagamento con un contratto BMP… Magari dopo molti mesi. Conoscere l’attacco può aiutare a contrastare le minacce.

6. Obiezione: "La truffa verrebbe subito smascherata" 

Ciò è tipico delle alterazioni di documenti (sia cartacei che informatici). Non per questo non dobbiamo preoccuparci di contrastare il rischio.

 

 

Inoltre presentiamo alcune risposte ad articoli apparsi sul Web

 

 

Risposta all'articolo apparso su interlex , N. 376, del 26 giugno 2008, dal titolo "Un 'baco' che non c'è e una scorciatoia per i disonesti" di Manlio Cammarata

 

Risposta all'articolo apparso su interlex , N. 376, del 26 giugno 2008, dal titolo "La luna, il pozzo, la bufala" di Corrado Giustozzi

 

Risposta alla lettera CNIPA 25 giugno 2008 relativa all'articolo "come ti falsifico la firma digitale".

 

Buona navigazione                                             

Francesco Buccafurri                                           

 

Descrizione dell'attacco

 

Articoli scientifici:

·         Rapporto tecnico

·         Buccafurri, F., Caminiti, G., Lax. G., Signing the Document Content is notEnough: A new Attack to Digital Signature, IEEE International Conference on theApplications of Digital Information and Web Technologies (ICADIWT), Ostrava, Czech Republic, 2008, pp.520--525, IEEE press.

·         Buccafurri, F., Caminiti, G., Lax, G., The Dalì Attack on Digital Signature, Journal of Information Assurance and Security, Vol. 3, pp.185--194, Dynamic Publishers, Inc., 2008.

·         Francesco Buccafurri, "Digital Signature Trust Vulnerability: A new attack on digital signatures" Information Systems Security Association Journal, October 2008

·         Buccafurri, F., I formati adatti alla dematerializzazione: un punto a favore di PDF/A, Unificazione & Certificazione (organo ufficiale dei due enti normatori UNI e CEI), n.6/2009.

·         Buccafurri, F., Caminiti, G., Lax. G., Fortifying the Dalì Attack on Digital Signature, International Conference on Security of Information and Networks (SIN 2009), Famagusta, North Cyprus, 2009,pp.278--287, ACM Press.

·         Buccafurri, F., Caminiti, G., Lax, G., Digital Document Signing:Drawbacks and Solutions, submitted as a chapter of the book Security in Computing and Networking Systems: The State-of-the-Art.

Rassegna stampa

      Panorama

      Calabria Ora

 

 

Contatti:

Prof. Francesco Buccafurri

Dipartimento DIMET, Facoltà di Ingegneria

Università Mediterranea di Reggio Calabria

Tel: 0965 875302

E-mail: bucca@unirc.it