Firma digitale: trovato sistema di falsificazione
di Roberta D'Onofrio

Firma digitale: trovato sistema di falsificazione

martedì 24 giugno 2008
Un ricercatore reggino dell'Università Mediterranea di Reggio Calabria ha trovato una falla nel sistema di firma digitale. Il caso è finito nelle mani del CNIPA

Scoperto un sistema di falsificazione della firma digitale, la procedura utilizzata da aziende e amministrazioni pubbliche per siglare documenti inviati via internet.

A smentire l'immodificabilità dei documenti informatici è stato il gruppo di studio del professor Francesco Buccafurri, docente di sistemi di elaborazione dell'informazione all'Università Mediterranea di Reggio Calabria che ha messo a punto un nuovo attacco alla firma digitale.

Il docente ha ipotizzato il caso in cui un documento dopo essere stato firmato digitalmente da un funzionario può poi apparire con un contenuto modificato senza che la procedura di verifica della firma rilevi la modifica.

E se prima si pensava che la contraffazione fosse possibile solo nei formati (es. Word) che permettono l'inclusione di istruzioni nascoste all'interno del documento, il caso rilevato dal docente reggino dimostra che anche altri formati considerati sicuri, come quelli per l'immagine bitmap, possano essere soggetti a modifiche.

«Basterebbe che la firma digitale agisse anche sul nome del file» sostiene Buccafurri. Nel frattempo il Cnipa sta valutando i provvedimenti da adottare e la possibilità di suggerire al FESA (Forum of European Supervisory Authorities for Electronic Signatures) una revisione normativa e tecnica della firma elettronica.

Se vuoi aggiornamenti su Firma digitale: trovato sistema di falsificazione inserisci la tua e-mail nel box qui sotto:


Il caso è ben noto da alcuni anni. Nel gruppo di standardizzazione sulla firma elettronica (ESI) dello European Telecommunications Standards Institute - ETSI, ai cui lavori partecipo dal 2001, la cosa fu segnalata anni fa da Peter Rybar (che è, ovviamente, solo omonimo del celebre pianista morto il 4 Ottobre 2002) dell'apposito organo governativo Slovacco. L'attacco ha esito positivo solo se si opera in violazione dell'art. 3, comma 3, del DPCM 13/1/2004 ("Il documento informatico, sottoscritto con firma digitale o altro tipo di firma elettronica avanzata basata su un certificato qualificato e generata mediante un dispositivo sicuro per la creazione di una firma, non produce gli effetti di cui all’articolo 10, comma 3, del testo unico, se contiene macroistruzioni o codici eseguibili, tali da attivare funzionalità che possano modificare gli atti, i fatti o i dati nello stesso rappresentati.") Infatti tale attacco è attuato mediante l'inserimento nel file da firmare di codice eseguibile che, qualora, come riportato nell'articolo, il tipo di file sia cambiato (per esempio in "htm"), fa apparire, al posto del testo visualizzato dal firmatario, un testo previsto da chi ha inserito tali istruzioni "malevoli". Pertanto allo stato attuale in Italia una firma qualificata apposta a un tale file non ha il valore legale di "firma digitale" nel senso previsto dal Dgls 82/2005 all'art. 1, comma 1, lettera s. Non è, infatti, a caso che il citato DPCM 13/1/2004 dispone all'art. 42: "Il certificatore deve indicare nel manuale operativo i formati del documento informatico e le modalità operative a cui il titolare deve attenersi per ottemperare a quanto prescritto dall’articolo 3, comma 3." Tale disposto deriva precisamente dalla necessità di agevolare i titolari dei certificati nell'evitare i formati "pericolosi"; quali appunto i formati oggetto dell'attacco. Infine: nel CEN Worskhop Agreement 14170 del maggio 2004 il capitolo 8.6 "Hidden Text and Active Code Requirements" fa riferimento proprio a casi di questo tipo.
scritto da Franco Ruggieri - giovedì 26 giugno 2008 alle ore 8.55
sono false le affermazioni "falsificata la firma" e "smentita l'immodificabilità dei documenti firmati" perchè nel caso citato la firma non viene toccata modificata o falsificata e nemmeno il file che contiene già le due diverse informazioni. Si tratta solo di un giochetto che permette di visualizzare un contenuto piuttosto che un altro, il precedente commento ci spiega anche perchè si tratta di un giochetto non troppo pericoloso, quindi niente falsi allarmismi
scritto da alelavarra - giovedì 26 giugno 2008 alle ore 11.32
Evidentemente Franco Ruggieri si riferisce ad un altro tipo di attacco, non quello che abbiamo mostrato nel nostro lavoro.

Infatti, diversamente da quanto affermato da Ruggieri:

>Infatti tale attacco è attuato mediante >l'inserimento nel file da firmare di codice >eseguibile che, qualora, come riportato >nell'articolo, il tipo di file sia cambiato (per >esempio in "htm"), fa apparire, al posto del >testo visualizzato dal firmatario, un testo >previsto da chi ha inserito tali >istruzioni "malevoli".

il nostro attacco NON PREVEDE L'INCLUSIONE DI CODICE ESEGUIBILE. Come puo' essere facilmente verificato scaricando il file-esempio sulle nostre pagine dedicate all'attacco
www.unirc.it/firma
il documento non ha nè macro codice, nè codice eseguibile al suo interno, quindi non ricade sotto l'applicazione dell'art. 3 comma 3 del DPCM 13 gennaio del 2004.
Questa è la novità fondamentale dell'attacco che, viceversa, dal punto di vista degli effetti, è simile a quello basato su macro-codice o codice eseguibile (cioè il file firmato ha una "presentazione" variabile, pur non modificando i suoi bit).

I formati considerati "pericolosi", già previsti dalla deliberazione AIPA 51/2000, non includono certamente i formati immagine, dove invece il nostro attacco SI APPLICA.

Non risulta alcun lavoro scientifico precedente al nostro che documenta tale attacco. Se qualcuno è in grado di inviarmelo, sarà allora capace di smentirmi.

Cio' non significa assolutamente che vadano alimentati allarmismi, perchè in ogni caso
il nostro attacco si aggiunge agli altri possibili
(trojan horse, macro-codice, principalmente), con un livello di pericolosità che, provandolo a stimare, non è maggiore dei precedenti.

Pero' affermare che la novità non esista, è affermare una cosa palesemente falsa e tecnicamente scorretta.
A ulteriore riprova di cio', vi è il fatto che la nostra normativa non prevede contromisure per questo attacco, che potrebbero essere l'inclusione del nome del file (inclusa l'estensione) nei campi soggetti a firma della busta.
Inoltre ho avuto dal CNIPA chiare e documentabili attestazioni di interesse verso l'attacco, che è stato reputato degno di analisi "estremamente seria" e di sottoposizione al FESA (Forum of European Supervisory Authorities for Electronic Signatures) al fine di "evidenziare il problema".

E' sufficientemente evidente che se fosse vero quello che dice Ruggieri, il
CNIPA non avrebbe certo dato questo tipo di
valutazioni, impegnandosi addirittura ad EVIDENZIARE il problema in sede EUROPEA.


Vorrei dire infine ad "alevarra" che anche l'attacco basato su macro-codice è un "giochetto", di uguale pericolosità,
che pero' ha preoccupato e preoccupa gli addetti ai lavori (vi sono anche alcuni recenti lavori scientifici che mirano a contrastarlo).
Molti attacchi informatici sono "giochetti".
Bisogna vedere l'effetto che possono avere questi giochetti.
Da un certo punto di vista il nostro "giochetto" potrebbe anche risultare piu' pericoloso, perche' agisce su fomrati considerati ampiamente "SICURI".



scritto da Francesco Buccafurri - lunedì 30 giugno 2008 alle ore 8.54
Per maggiore completezza, sempre rispetto
al commento del Dott. Ruggieri,

riporto cio' che è incluso nel
documento (già a noi noto) a cui si riferisce,
e cioè: CWA 14170:2004




8.6 Hidden Text and Active Code Requirements

Threat:
The SD may hold hidden CODE capable of modifying the signed document presentation without affecting its cryptographic validity, thus deceiving the verifier and/or the signer.

Security Requirement:
1. An SDP capable to make the
signer sign only a static
document format should be
available. If it is not available:
a. The SDP shall warn the
signer of the presence of
hidden CODE.
b. A SD viewer must be
available without
discrimination from a
trusted source, capable
to warn of modifications
occurred after the SD
was signed.


Come si puo' facilmente verificare, la minaccia RIGUARDA LA PRESENZA DI CODICE (MACRO o CODICE ESEGUIBILE). Del resto, il requisito di sicurezza considerato sufficiente è "to sign only a static
document" - cioè firmare solo documenti STATICI,
cioè che non contengono macro-istruzioni o codice eseguibile.

Il formato immagine (per es. BMP) su cui abbiamo costruito l'attacco è un formato SATICO. Questa è conoscenza comune.
IL NOSTRO ATTACCO INFATTI NON SI BASA SULLA PRESENZA DI MACROCODICE O CODICE ESEGUIBILE NEL DOCUMENTO, NE' SULLE VARIE TECNICHE CHE PRODUCONO AMBIGUITA' DI PRESENTAZIONE (Font, hidden text -- caratteri uguali allo sfondo, etc.).

scritto da Francesco Buccafurri - lunedì 30 giugno 2008 alle ore 8.54
Già in aprile 2007 era stata pubblicata sul sito della Národný Bezpecnostný Úrad – National Security Authority Slovacca – il documento in slovacco corrispondente a quello in inglese: “Specifying the content and formal specifications of document formats for QES” in cui si davano le indicazioni su come gestire i formati dei documenti. A seguito di insistenze e richieste di chiarimenti (purtroppo in slovacco) Peter Rybar pubblicò nel mese di maggio sul sito http://elpi2.szm.com/priklad.htm un esempio dell’attacco in questione. Convengo che non si tratta di una pubblicazione accademica, ma, senza nulla togliere alla ricerca, resta il fatto che la notizia era già disponibile da tempo, anche se in un sito che poteva sfuggire. Qualcosa sul tipo di quello che accadde per le curve ellittiche a Victor Miller e Neal Koblitz. Peter Rybar rappresenta la Národný Bezpecnostný Úrad - National Security Authority Slovacca in seno allo ESI dello ETSI. Venendo al nocciolo della questione, purtroppo devo dire che non sono d’accordo con l'affermazione che l’attacco “NON SI BASA SULL'INCLUSIONE DI MACRO-CODICE O CODICE ESEGUIBILE NEL DOCUMENTO”. Esso si basa, infatti, sull’inserimento in un file *.bmp di istruzioni eseguibili con lo HTML. La distinzione tra “eseguibile” e “interpretabile” è un bizantinismo che può essere di interesse per alcuni tecnici, ma che è intrinsecamente irrilevante. Tutto ciò che gira su un computer è interpretato o eseguito da un qualche programma, altrimenti saremmo costretti a leggere e interpretare da soli le sequenze di “1” e di “0”, cosa che nemmeno Pico della Mirandola potrebbe fare. In questo caso, insomma, i due termini hanno lo stesso significato. Nel caso in questione, in particolare, si tratta di “istruzioni” (ovverosia “codice”) che un interprete HTML è in grado di visualizzare e un altro visualizzatore non è in grado di trattare. Infatti, mentre il visualizzatore di Windows per i formati *.bmp ignora, a torto o a ragione, questi “codici”, il suo equivalente su Unix protesta vivacemente. In conclusione: l’art. 3, comma 3, del DPCM 13/1/2004 si applica appieno.
scritto da Franco Ruggieri - lunedì 30 giugno 2008 alle ore 15.09
Egregio Dott. Ruggieri

non metto in dubbio la sua buona fede ma
dall'URL che mi invia non si evince alcuna
data e, inoltre, stranamente, non viene indicizzato neanche
da google.

In relazione alla questione che riguarda Peter Rybar,
la invito a consultare il sito polacco:

http://ipsec.pl/podpis-elektroniczny/2008/atak-na-podpis-elektroniczny-przez-zmiane-rozszerzenia.html

I commenti in inglese
inseriti dall'autore dell'articolo Pawel Krawczyk sono alquanto
significativi:
"Our article actually mentioned Italian team as primary source from the very beginning. In rough translation the first paragraph goes as follows:
"...this is the lesson coming from new attack published by scientists from Italina university Reggio Calabria. This information is circulating among interested parties for a few weeks now, but it was first mentioned in public by Czech magazine Cryptoworld"
The problem is that the original paper itself is not public, and we had to make some reference. The only public information so far was the one from CryptoWorld. That's why we have mentioned it, but at the same time we gave reference to the original article, noting that it's not yet public."

Di che maggio parla relativamente al documento
di cui mi fornisce URL? 2007?
Se fosse cosi' come mai Rybar ha aspettato un anno per
farne una pubblicazione in cecoslovacco su una rivista on-line
(Cripto-World)?


Relativamente all'applicazione dell'art. 3, mi permetta di dissentire.
Il legilatore non ha genericamente incluso il termine "istruzione":
ha specificato con accuratezza due tipi di codice,
macro-istruzioni o codici eseguibili, escludendo quindi
i linguaggi di mark-up.
Si tratta di norme tecniche, dove le parole hanno un significato
ben preciso.
Nella disciplina informatica sia il termine macro-istruzioni
che istruzioni eseguibili hanno infatti un significato ben preciso,
che non include certamente le istruzioni di un
linguaggio di mark-up.


In ogni caso credo sia di scarso rilievo se l'art. 3 sia
direttamente applicabile o se
invece sia necessaria (come credo) una "applicazione
estensiva" da parte del Giudice.
L'aspetto rilevante è quello tecnico,
considerato che fino ad oggi i formati immagine
sono stati universalmente considerati sicuri
(proprio coerentemente alle intenzioni del
legislatori che sottendono
l'art. 3, comma 3 del DPCM 13 gennaio 2004).

Ho modo di ritenere, per le dichiarazioni rilasciate dal CNIPA, che nelle nuove regole tecniche
si farà chiarezza su questo aspetto, proprio
tenendo conto delle nuove conoscenze.

scritto da Francesco Buccafurri - lunedì 30 giugno 2008 alle ore 16.12
Il sito di Peter Rybar è stato fatto a maggio 2008, ma in ETSI la cosa si sapeva da alcuni mesi. Purtroppo non ricordo quanto tempo fa se ne parlò la prima volta. In ogni modo, ripeto, non c'è una questione di paternità: lasciamola a Esaù e a Giacobbe. Replico per l'ultima volta a due asserzioni: >"Nella disciplina informatica sia il termine macro-istruzioni che istruzioni eseguibili hanno infatti un significato ben preciso, che non include certamente le istruzioni di un linguaggio di mark-up."< E infatti il DPCM non parla di "istruzioni", bensì di "codici eseguibili" il che è volutamente ben più ampio di "istruzioni". >"considerato che fino ad oggi i formati immagine sono stati universalmente considerati sicuri (proprio coerentemente alle intenzioni del legislatori che sottendono l'art. 3, comma 3 del DPCM 13 gennaio 2004)"< Purtroppo anche su questo devo dissentire. Non è vero, almeno dal punto di vista giuridico, che "fino ad oggi i formati immagine sono stati universalmente considerati sicuri", tanto è vero che la Deliberazione dell'allora AIPA N. 24 del 30/7/1998 per l'antesignano della attuale conservazione sostitutiva prevedeva solo CGM e TIFF. Insomma: circa l'interpretazione della norma ognuno resta della sua idea, vedo, anche se il legislatore ha usato un termine adeguatamente generale da comprendere tutto. Concludo questa, ormai noiosa e inconcludente, diatriba bizantina dicendomi d'accordo sulla necessità, già da me sollevata in altre sedi, che il CNIPA o chi per lui indichi quali sono i formati utilizzabili e come si devono utilizzare: non si possono lasciare i singoli certificatori a decidere ciascuno per conto proprio, visto che ci sono opinioni particolari su che cosa significhi "codice eseguibile". La Slovacchia, tanto per restare in tema, lo ha fatto un anno fa.
scritto da Franco Ruggieri - lunedì 30 giugno 2008 alle ore 17.22
Non so se Peter Rybar tenga molto al piatto di lenticchie in cambio della primogenitura: può sempre chiederglielo, non mi riguarda. Per quanto riguarda la 24/98, faccio ammenda: mi sono basato sulla memoria e mi ricordavo male. Ho sbagliato a non andare a verificare. Ribadisco invece, e con questo chiudo questa ormai inutile discussione, che i comandi HTML, bizantinismi a parte, costituiscono vero e proprio "codice eseguibile". Rispiegarlo un'altra volta mi sembrerebbe un'offesa all'intelligenza di chiunque: quanto ho detto in precedenza è chiaro per tutti e, principalmente, l'evidenza dei fatti lo dimostra da sola. In ogni modo le riconosco il merito di avere fornito (prima o dopo Peter Rybar non mi interessa) un chiaro esempio di come alcuni formati di immagini e lo HTML possano dare adito di per sé a truffe, indipendentemente dalla firma elettronica, e che pertanto debbano essere assolutamente evitati dall'utente non tecnicamente esperto qualora intenda apporre o verificare una QES. Mi auguro che, una volta superato l'attrito di primo distacco, il nuovo governo vari le nuove regole tecniche sulla firma digitale a cui dovranno far seguito quelle tecnologiche, ivi compreso, ormai è inevitabile, l'elenco dei formati di documento da utilizzare, escludendo categoricamente *.bmp, *.jpg, *gif, *.htm, e simili.
scritto da Franco Ruggieri - martedì 1 luglio 2008 alle ore 8.46
Gent.mo Dott. Ruggeri,

la ringrazio per le informazioni,
per me la discussione non è stata noiosa e inconcludente
in quanto è stato molto utile confrontarmi
con lei, che lavora sul campo in ambito ETSI.

Il fatto che Rybar abbia pubblicato questo sito
nel maggio 2008 (cioe'
solo dopo l'invio da parte
nostra del lavoro scientifico
alla conferenza IEEE
che si svolge in Rep. Ceca)
è esattamente quello che mi aspettavo.

Sulla Deliberazione AIPA N. 24 del 30/7/1998,
devo farle notare che la deliberazione
non restringe ai formati in questione,
ma richiede che "almeno i formati CGM o TIFF"
siano supportati. Il che è chiaramente diverso.

Ritornando a Rybar e alla Slovenia,
le vorrei fare notare che nel documento
"Specifying the content and formal specifications of
document formats for QES" Rybar, nel luglio 2007,
"richiedeva" per gli HTML (affinchè fossero sicuri):

"A.4 HTML and XHTML document

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


Un HTML come quello del nostro attacco è perfettamente compliant
con queste specifiche.
Ciò dimostrerebbe che almeno fino a quella data
Rybar non aveva concepito l'attacco concretamente.


Mi fa piacere che concorda sulla necessità di una revisione normativa
anche se temo che una restrizione sui formati possa essere
facilmente realizzabile.
scritto da Francesco Buccafurri - martedì 1 luglio 2008 alle ore 8.00
NOTA PER IL LETTORE: COME RISULTA DALL'ORARIO IL COMMENTO A MIA FIRMA (FRANCESCO BUCCAFURRI) DELL'1 LUGLIO 2008 E'PRECEDENTE AL COMMENTO DI FRANCO RUGGIERI DELLO STESSO GIORNO. QUINDI I DUE PRECEDENTI COMMENTI VANNO LETTI IN ORDINE INVERSO A QUELLO CON CUI APPAIONO.
scritto da Francesco Buccafurri - martedì 1 luglio 2008 alle ore 11.07
In relazione al discorso dei formati e alla presunta "sicurezza" del formato TIFF, desideravo comunicare che abbiamo realizzato l'attacco anche sul formato TIFF, largamente utilizzato nei documenti acquisiti per scansione (come nel caso della conservazione sostitutiva).

scritto da Francesco Buccafurri - martedì 15 luglio 2008 alle ore 21.58
Il sito di Rybar e' del 2008... PECCATO, che la documentazione del sito ISTITUZIONALE Slovacco sia del 2007: che sia una cospirazione? (mi sembra un po eccessivo... ma certo non e' che manchi la documentazione, solo che non e' in italiano...) http://elpi2.szm.com/priklad.htm http://www.nbusr.sk/ipublisher/files/nbusr.sk/elektronicky-podpis/legislativa/9/specifyingcontentformalspecofdocqes_en_071.pdf Vabbeh, partiamo con la colletta e chiediamo a Rybar se viene a spiegarcelo di persona...
scritto da Diego Zanga - venerdì 12 settembre 2008 alle ore 9.01
Il documento a cui si riferisce l'ormai noto Diego Zanga è già riferito nei commenti precedenti (se avesse letto se ne sarebbe accorto), proprio come prova del fatto che il nostro attacco NON era noto (commento 1 luglio 2008, ore 8.00).
scritto da Francesco Buccafurri - venerdì 12 settembre 2008 alle ore 19.21
Aggiungo che Diego Zanga, il 28 giusgno 2008, mi scriveva per e-mail cio' che segue:

"Le segnalo anche che non ho sotto mano una dichiarazione ufficiale di
Peter Rybar, che per quanto ho avuto modo di verificare ha
"IPOTIZZATO" il problema da voi DIMOSTRATO (in Slovacchia e di li in
ambito ETSI(?) e FESA), ma le posso assicurare che tra l'altro Rybar
non ha messo in discussione il fatto che il lavoro da voi svolto sia
appunto VOSTRO e frutto del VOSTRO ingegno."

Sia ben chiaro, non è certo sulle affermazioni di Diego Zanga che si basa la certezza di originalità del nostro lavoro e di primogenitura del risultato. Ho riportato questa frase giusto per fornire qualche elemento circa l'affidabilità delle affermazioni di Zanga.
scritto da Francesco Buccafurri - venerdì 12 settembre 2008 alle ore 21.33

Inserisci il tuo commento

Nome (obbligatorio):
Email (obbligatorio):
Sito:
 
Vuoi salvare questi dati?
Commento:
Codice di controllo: