|
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
|
