Riceviamo e pubblichiamo una nota del prof. Francesco Buccafurri, nella quale
replica alle osservazioni formulate negli articoli Un "baco" che non c'è e una scorciatoia per i
disonesti di Manlio Cammarata e La luna, il pozzo, la
bufala di Corrado Giustozzi.
Per concludere il discorso si veda La vera
"bufala" è la notizia e Meno male che non mi ha sfidato a duello!
Spett.le Redazione di Interlex,
Egregio Dott. Cammarata,
e p.c. Egr. Sig. Giustozzi
Consiglio Nazionale dell'Ordine dei Giornalisti
Consiglio dell'Ordine dei Giornalisti del Lazio
con la presente chiedo formalmente la pubblicazione sul giornale Interlex (www.interlex.it)
delle seguenti mie risposte agli articoli citati in oggetto (incluse in calce alla presente mail).
Tale richiesta sostituisce la precedente richiesta di pubblicazione del 27 giugno, sulla quale, essendo essa
redatta della forma della risposta personale ai rispettivi autori, rimuovo l'autorizzazione alla pubblicazione
(per altro non avvenuta).
Ribadisco invece la richiesta di pubblicare quanto segue tempestivamente, in quanto ritengo
doveroso da parte Vostra, consentirmi di esprimere le mie argomentazioni di difesa,
rispetto ad attacchi a volte lesivi della mia immagine ed immotivatamente sbeffeggianti
(mi riferisco all'articolo del Sig. Giustozzi).
Fatto salvo ogni diritto di azione legale in merito a quanto già pubblicato, diffido Interlex dalla pubblicazione
di ulteriori articoli che possano risultare lesivi della mia immagine, e chiedo l'immediata
pubblicazione delle scuse dell'autore e della redazione.
Cordiali Saluti
Prof. Francesco Buccafurri
Professore Ordinario di
Sistemi di Elaborazione delle Informazioni,
Dip. DIMET, Facolta' di Ingegneria,
Direttore CESIAT
(Centro Servizi Informatici d'Ateneo)
Universita' "Mediterranea" di Reggio Calabria,
Feo di Vito
89122 Reggio Calabria
In riferimento 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.
Cammarata scrive: "Il problema del documento che cambia contenuto non è
nuovo. E' stato sollevato nel lontano 2002, oggetto di approfondite discussioni
su queste pagine"
E' falso. Il problema era noto ben prima. Già la deliberazione AIPA 51/2000
introduce una serie di prescrizioni destinate alle PA sui formati da utilizzare,
in riferimento alla non staticità dei documenti. Tuttavia, come osservato piu'
avanti, tale fattispecie è diversa da quella individuata nel nostro studio.
Cammarata scrive: "Il legislatore ha risolto da tempo il problema: per
essere "valido e rilevante a tutti gli effetti di legge" e quindi
equivalente al documento cartaceo con firma autografa, il documento informatico
deve presentare una serie di requisiti. Prima di tutto "I documenti
informatici devono essere presentati al titolare, prima dell'apposizione della
firma, chiaramente e senza ambiguità" (CAD, art. 35, c. 2). Poi "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" (art. 3, comma 3 delle regole
tecniche attualmente in vigore - DPCM 13 gennaio 2004).
I documenti utilizzati dai ricercatori calabresi non presentano questi
requisiti. Quindi non possono essere validi ai sensi della normativa sulla firma
digitale. Se qualcuno pensasse di servirsene per trarre qualcuno in inganno,
potrebbe incorrere in uno dei reati di falso previsti e puniti dagli articoli
476 e seguenti del codice penale. Fine della questione."
Anche questo è falso. Relativamente a quanto prescritto dal CAD, art 35, comma
2, è sufficientemente evidente che un documento precostituito per l'attacco da
noi documentato "si presentata al titolare, prima dell'apposizione della
firma, chiaramente e senza ambiguità". Ma d'altra parte il comma 2 del
suddetto art. 35 NON RIGUARDA IL FORMATO O LE PROPRIETA' DEL DOCUMENTO, ma solo
LE CARATTERISTICHE DEL DISPOSITIVO DI FIRMA E DEL SOFTWARE DI FIRMA. (Tra
l'altro il comma 3 esclude da questa prescrizione le firme applicate mediante
procedura automatica-- ma questo non è di rilievo). Quindi nulla ha a che
vedere con la materia oggetto di discussione.
Relativamente all'art. 3, comma 3 delle regole tecniche attualmente in vigore -
DPCM 13 gennaio 2004, è anche qui facile rendersi conto che tale prescrizione,
cosi' come quella della (implicitamente abrogata?) deliberazione AIPA 51/2000,
si riferisce alla possibile presenza di macro-codice o codice eseguibile nei
documenti.
Il nostro attacco NON SI BASA SULL'INCLUSIONE DI MACRO-CODICE O CODICE
ESEGUIBILE NEL DOCUMENTO, operando, per esempio, su un formato (come quello
immagine - BMP) che non puo' contenere tali istruzioni. Del resto il CNIPA, mi
ha confermato senza ambiguità la non diretta applicazione del sopra citato art.
3, e la necessità di adeguare le norme tecniche.
Detto questo non è da escludere che in giudizio potrebbe anche essere adottata
un'applicazione estensiva di tale prescrizione, "assimilando" il
nostro attacco a quello basato su documenti contenenti macro- istruzioni, ma
questa è un'altra faccenda.
Attiene alla giusta facoltà del Giudice di compensare, secondo il suo prudente
apprezzamento e l'applicazione della giurisprudenza, eventuali vacanze, aporie
logiche, contraddizioni, che possono esistere (come in questo caso) nella
normativa vigente. Ciò tuttavia non solleva il legislatore dall'obbligo di
ridurre più possibile tali incongruenze normative. Infine, che sulla base
dell'attacco possono essere realizzati reati (frode informatica, falso in
scrittura privata, falso ideologico, etc.) è più che lapalissiano.
E' il motivo per il quale ho ritenuto di dover divulgare più in fretta
possibile questo studio, e di informare preventivamente (PRIMA DELLA
PUBBLICAZIONE SCIENTIFICA) il CNIPA, quale organo di riferimento in questa
materia.
In riferimento all'articolo apparso su interlex , N. 376, del 26 giugno 2008,
dal titolo "La luna, il pozzo, la bufala" di Corrado Giustozzi
Giustozzi scrive: "Sembrava impossibile, eppure al giorno d’oggi c’è
ancora qualcuno che ha il coraggio di sostenere di aver trovato il punto debole
della firma digitale e di essere in grado di falsificarla. Ora, si trattasse di
qualcuno che ha trovato un algoritmo efficiente di fattorizzazione, gli daremmo
il premio Nobel (stiamo cercando tale algoritmo “solo” da duemilacinquecento
anni, e la firma digitale si basa proprio sulla speranza che non esista…); si
trattasse di qualcuno che ha trovato un modo di generare facilmente collisioni
di tipo second preimage nelle funzioni hash tipo SHA-2 gli faremmo tanto di
cappello; ma i trucchi da imbonitore, per carità, evitateceli. E soprattutto
non spacciateli per “debolezze intrinseche” della firma digitale: sarebbe
come dire che i tostapane non funzionano perché se ci metto dentro una trota
non esce una fetta di pane tostato!"
Non abbiamo mai affermato nella nostra ricerca che il nostro attacco si basi
sulla "rottura" dell'algoritmo RSA o degli hash crittografici usati
nella firma. Il riferimento di Giustozzi a questa fattispecie è del tutto fuori
luogo. Per informazione, il premio Nobel non potrà mai essere preso da nessuno
in questo campo, perchè il premio Nobel non è stato istituito nè per la
matematica, nè per l'informatica, che è disciplina troppo giovane. Poteva fare
riferimento invece al premio Turing, scienziato che Giustozzi dall'alto della
sua esperienza sicuramente conoscerà, come conoscerà la sua teoria.
Giustozzi scrive: "Già. In realtà ciò che il pluringegneristico team di
ricerca dell’Università Mediterranea ha scoperto, e persino documentato in un
dottissimo paper disponibile in sola lingua inglese, non è ahimè una
vulnerabilità “della firma digitale” tout court ma, banalmente, una nota ed
annosa limitazione (pardon, “caratteristica”) di Windows. Tant’è che la
proof of concept da essi illustrata a sostegno della propria tesi non funziona
su nessun altro sistema operativo degno di questo nome. Ma di ciò i ricercatori
calabresi si sono “dimenticati” di far menzione…
Vediamo dunque come stanno le cose. Dice il calabro ricercatore: “se prendo
una immagine in formato BMP che dice una cosa, la violento trasformandola
surrettiziamente in un documento HTML che ne dice un’altra, firmo il tutto,
cambio nome al file da BMP in HTML, lo apro, allora perbacco! vedo il file HTML
e non l’immagine BMP”.
Grande scoperta: lo sanno tutti che Windows decide cos’è un file non
andandolo a guardare ma fidandosi di quello che dice il suo nome, o meglio l’estensione
di tre lettere che segue il punto. Così se prendo un file DOC e gli cambio
estensione in BMP, e poi ci clicco sopra due volte, non partirà Word per
aprirlo ma Paint, o il programma di grafica attivo per default; il quale
oltretutto si arrabbierà moltissimo per non essere in grado di aprire il file,
dato che il suo contenuto non corrisponde a quello previsto per un file BMP, e
non saprà cosa fare per visualizzarlo. Naturalmente ciò vale anche per il
viceversa, e per qualsiasi altra trasformazione da un’estensione ad un’altra.
(Notiamo per inciso che tutti i sistemi operativi più seri quali Unix o Mac-OS
non basano la loro decisione su una mera convenzione associata al nome del file,
ma vanno a guardare cosa c’è effettivamente nel file stesso e lo riconoscono
per quello che è il suo reale formato. Windows no, bontà sua).
Ora, è perfettamente possibile pensare di riuscire a costruire un file che
risponda contemporaneamente alle specifiche tecniche di due formati differenti.
Si tratta di una situazione patologica ma sicuramente realizzabile, magari
sfruttando ad arte qualche bug di qualche diffuso programma di interpretazione
di specifici formati (quello che si chiama genericamente parser). Ad esempio,
come hanno fatto i ricercatori calabresi, si può accodare ad una immagine BMP
un pezzo di testo HTML (confidando che il parser delle immagini non protesti per
questi dati extra!) e quindi modificare i primi byte dell’immagine BMP (sempre
confidando che il medesimo parser sia di bocca buona…) per far sì che l’immagine
stessa appaia ad un interprete di codice HTML come un “commento” da
ignorare. Ora, questo abominio digitale è l’equivalente di quelle immagini
ambivalenti di cui vanno tanto fieri gli psicologi cognitivi: ad esempio i due
famosi profili affacciati che visti in altro modo diventano una coppa, o la
vecchia signora che vista in altro modo diventa una giovane ragazza. Un bieco
trucco, insomma, nel quale il file “taroccato” può essere aperto sia da un
parser per immagini (che “vede” la sola parte BMP ed ignora quella HTML) che
da un parser per HTML (che viceversa “vede” la sola parte HTML ed ignora
quella BMP), con contenuti ovviamente assai diversi tra l’uno e l’altro
caso.
La miopia di Windows fa sì che questa insana ambivalenza interpretativa possa
essere “pilotata” a piacere semplicemente modificando l’estensione del
file: se questa è BMP allora il doppio clic lo farà automaticamente aprire da
un visualizzatore di immagini, mentre se è HTML da un browser. I risultati
saranno ovviamente diversi, perché ciascun programma “vedrà” solo la parte
di file che è in grado di interpretare e, se non è troppo schizzinoso, non si
lamenterà per non riuscire ad interpretare l’altra parte. Ciò però vuol
dire che il file è cambiato da una visualizzazione all’altra? Ovviamente no:
semplicemente, l’automatismo fa sì che se ne veda una parte oppure un’altra,
a scelta. Ma il file è sempre quello, nella sua immutabile interezza, a
prescindere da quale parte si decida di vederne."
Il fatto che i file prodotti secondo la tecnica da noi mostrata siano
"polimorfi" è un fatto intrinseco. Non dipende dal Sistema Operativo
usato. La cosa attiene ad un principio basilare, noto a chiunque sia competente
in informatica, circa il fatto che il significato di una sequenza di bit puo'
essere definito quando è definita la codifica che essi rappresentano, e quindi
il modo con cui questi bit devono essere intepretati.
L'aggravante dei sistemi operativi che, come Windows, effettuano associazioni
automatiche tra file ed applicazioni in base all'estensione, rende il problema
significativo dal punto di vista pratico, circa il modo con cui la firma è
utilizzata, considerato che la stragrande maggioranza dei documenti (ivi
compresi quelli firmati) sono elaborati e mantenuti su piattaforma Microsoft
(piaccia o non piaccia).
Giustozzi scrive: "E allora dov’è il tanto sbandierato bug della firma
digitale? Ci dice ancora il professore: “se io firmo il file, e poi cambio
estensione al file firmato, visualizzo di fatto un documento non conforme a
quello che mi aspettavo, eppure la firma digitale risulta sempre verificata.”.
Ma che grande scoperta! Il file non è stato modificato, e dunque è ovvio che
la firma digitale risulti verificata. Il fatto che il trucco dell’estensione
continui a funzionare sul file firmato è un problema che riguarda la miopia di
Windows, non la firma digitale in sé: la quale, come noto, riguarda solo ed
esclusivamente il contenuto di un file e non, per amor di Dio, i suoi metadati."
Il motivo che la firma non rilevi il problema, è certamente evidente, per come
funziona la firma e per come è usata la busta crittografica. Il problema sta
proprio nel fatto che i metadati non vengono firmati. Questo è proprio la
debolezza su cui si basa l'attacco. Come il CNIPA mi ha confermato, circa
l'ipotesi di soluzione da noi ipotizzata (inclusione del nome -- in particolare
l'estensione -- del file in un campo della busta sottoposto a firma), sarebbe
una soluzione da "consigliare ai certificatori" (anche se,
probabilmente, di difficile attuazione -- aggiungo io).
Giustozzi scrive:
"In altre parole: nella formazione della firma digitale non concorrono cose
quali il nome del file, la sua data di creazione, la lunghezza, l’attributo di
sola lettura e via dicendo, com’è giusto che sia. Perché infatti il nome di
un documento dovrebbe essere significativo rispetto al suo contenuto? Sarebbe
come se il nome attribuito ad un faldone nel quale sono riposti degli atti fosse
importante ai fini del contenuto degli atti ivi riposti, col risultato che l’eventuale
modifica del nome del faldone dovrebbe inficiare la validità (e la firma) degli
atti stessi!"
La metafora del faldone non regge. Il fatto che il nome diventi significativo
nel nostro caso dipende da un fatto tecnico.
Di fatti si parla dell'estensione e non del nome, in quanto essa (per la quasi
totalità dei casi reali -- windows è il piu' diffuso SO al mondo), è un
metadato che DESCRIVE IL FORMATO DEL DOCUMENTO.
Allora la metafora giusta dovrebbe essere legata ad una domanda del tipo:
Avrebbe efficacia probatoria, in merito alla funzione dichiarativa, una firma
autografa apposta su un documento codificato in un linguaggio coniato ad hoc,
dal sottoscrittore, non noto a nessuno, senza che il documento stesso abbia al
suo interno "i metadati" necessari a poter intepretare il contenuto?
Il valore probatorio sarebbe nullo.
Semplicemente perchè quel pezzo di carta non sarebbe un documento secondo
l'accezione giuridica del termine (in quanto non è la rappresentazione di atti
e fatti giuridicamente rilevanti, ma soltanto una sequenza inintellegibile di
caratteri).
Giustozzi scrive: "Con l’occasione notiamo che i nostri prodi
ricercatori, senza dover necessariamente stuprare un’immagine BMP, potevano
produrre un effetto similare in vari modi alternativi. Prendiamo ad esempio il
formato ZIP, comunemente usato per archiviare tanti file comprimendoli in uno
solo: oramai molte applicazioni di uso comune producono i loro file in questo
formato standard, ma hanno cura di dotarli di estensioni differenti per fare in
modo che non vengano aperti per errore da altre applicazioni. Il formato ODT per
i documenti OpenOffice ed il formato JAR usato per distribuire classi Java e
metadati associati sono due esempi comuni di tale diffusa pratica. Se dunque
fate doppio clic su un file ODT esso verrà aperto da OpenOffice come se fosse
un documento (ed in effetti lo è), mentre se gli cambiate nome in ZIP e poi gli
fate doppio clic verrà aperto da WinZip come se fosse un archivio (ed in
effetti è anche questo!). Anche in questo caso la semantica dell’azione
innescata dal doppio clic viene decisa dall’estensione associata al nome del
file, e ciascuna applicazione lanciata lo vedrà in modo diverso: ma la sostanza
del file rimane sempre la medesima, ossia quella di un insieme di byte unico ed
immutabile.
Anche in questo caso, dunque, funzionerebbe il trucco del professore calabrese:
ma cosa c’entra la firma digitale?"
Ciò che dice Giustozzi su Zip e ODT è privo di significato. Il nostro attacco
è basato sulla capacità di un documento di presentarsi in modo diverso con
diversi contenuti informativi entrambi intellegibili. Per questo ha
significatività pratica. Non è il caso a cui Giustozzi si riferisce.
Giustozzi scrive: "Per concludere: non scherziamo con la firma digitale e
soprattutto non scomodiamola invano. Già ha avuto tanti problemi nel corso
degli anni, ed ha dovuto subire denigrazioni e sconfessioni da parte di
personaggi ed istituzioni a dir poco insospettabili. Se c’è tuttavia una cosa
che funziona bene sono i suoi meccanismi tecnici, e quelli non è possibile
metterli in discussione con trucchi da prestigiatore. Una cosa di cui
assolutamente non abbiamo bisogno è quella di ingenerare nella gente comune
ulteriore confusione e sospetto nei riguardi delle tecnologie digitali.
Se vogliamo alzare il livello di alfabetizzazione e pretendere che tutti inizino
a partecipare alla vita della Società digitale non possiamo continuare
impunemente a fare disinformazione terroristica sulla valenza delle tecnologie
abilitanti su cui essa si fonda. Quando si scoprirà l’algoritmo di
fattorizzazione veloce o quello di collisione degli hash ci preoccuperemo, ma
sino ad allora, per carità, non alimentiamo falsi spettri con minacce
inesistenti."
Mi fa piacere che Giustozzi sia così tranquillo e scettico rispetto alla
necessità di adottare strategie per evitare l'uso fraudolento della debolezza
da noi individuata. Si sa che l'ansia non fa bene alla salute.
Vedo infatti che ha perso l'atteggiamento ansioso che invece aveva nel settembre
del 2002, quando (con almeno 2 anni di ritardo -- in quanto la cosa era
ampiamente regolata dalla normativa vigente in forza della deliberazione AIPA
51/2000), nell'articolo "Funziona o non funziona? L'aspetto tecnico"
(http://www.interlex.it/docdigit/corrado8.htm) propagandava come scoop il fatto
che alcuni formati comunemente usati (es. Word, ed Excel) potessero includere
macro-istruzioni, e i relativi rischi di falsi informatici, senza neppure citare
che l'organo competente (AIPA) aveva già considerato approfonditamente il
problema e introdotto restrizioni nell'ambito della PA relative ai formati
utilizzabili (sopra citata deliberazione AIPA 51/2000).
In quell'articolo Giustozzi era particolarmente preoccupato per l'attacco basato
sulle macro-istruzioni, che, si noti bene, ha GLI STESSI POTENZIALI EFFETTI
DELL'ATTACCO PRESENTATO NEL NOSTRO STUDIO. Infatti, nella sezione introduttiva
dell'articolo scriveva: "Tuttavia non si può evitare di affrontare la
questione, liquidandola, come molti hanno fatto, con un'alzata di spalle: il
problema c'è davvero ed è anche dannatamente serio, come vedremo. Ed è anche,
purtroppo, di difficilissima soluzione, perché non è un problema (solo)
tecnico. Siamo nella classica situazione in cui bisogna cercare di salvare capra
e cavoli; questa volta però non è detto che ci si riesca, forse occorrerà
sacrificare qualche cavolo."
Ma, in relazione alla mutevolezza delle dotte valutazioni di Giustozzi, è
davvero singolare la parte finale di quell'articolo che recita:
"Quale può essere infine la conclusione di questa vicenda? La risposta non
è facile. Il buon senso suggerirebbe di risolvere il problema limitando il
novero dei documenti firmabili digitalmente ai soli formati "puri",
non programmabili, immutabili ed assoluti. Ossia ai veri documenti, e non ai
meta-documenti come sono quelli di Word o di Excel [...]".
Ciò dimostra che un mondo ideale in cui sono ammessi formati che non
includono macro-istruzioni o codice eseguibile l'avrebbe tranquillizzato
Oggi Giustozzi scopre che anche in questo mondo ideale (il nostro attacco agisce
infatti su un formato - quello immagine - che assolutamente non può includere
macro-istruzioni), i pericoli a cui fa riferimento in quell'articolo
esisterebbero comunque, ma non si preoccupa per nulla.
Le mie congratulazioni, significa che ha migliorato di molto il suo
self-control.
|