[Linuxtrent] attacco alla firma digitale

  • From: "Francesco Buccafurri" <bucca@xxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Thu, 10 Jul 2008 15:56:34 +0200

Mi riferisco al commento di Roberto Resoli riportato
in basso.
Vorrei aggiungere qualche elemento
alla discussione che spero possa essere utile.

1. mi pare che i commenti di Resoli siano piu' o meno
quello che uno si aspetta da una persona competente
che non abbia retro-motivi che non lo portino ad assumere
un atteggiamento basato sull'onestà intellettuale.
Per questo lo ringrazio, perchè pare che questa sia
una dote rara.
Negare l'esistenza di questo attacco alla firma
mi sembra intellettualmente poco onesto.
Parlare di vulnerabilità di Windows
(e l'attacco ha successo anche su altre piattaforme...)
è chiaramente tecnicamente scorretto.
Eppure il Web, da punto informatico (e tutti i siti
che lo riprendono), Interlex, etc., è pieno
di questa incredibile affermazione.
Sarebbe come dire che l'attacco alla firma
digitale basato sui contenuti dinamici
di Word, per esempio, corrisponda ad una vulnerabilità
di Word e non del sistema di firma.
Il problema da noi segnalato sta alla firma
esattamente come l'ambiguità dei
documenti causata da macro o da Java script
sta a lla firma.
Quest'ultima è stata ritenuta universalmente
una debolezza del sistema di firma e non dei
documenti.
Lo stesso vale quindi per il nostro attacco.


2. Che si tenti di confondere il nostro attacco
con quello basato su contenuti dinamici (istruzioni
che fanno cambiare il contenuto)
mi sembra un'operazione scorretta
e priva di chance di riuscita.
Sul sito www.unirc.it/firma
si possono trovare numerose argomentazioni
a supporto di quanto sto dicendo.

In aggiunta, si pensi che
Jøsang et. al, nel lavoro:
What You See is Not AlwaysWhat You Sign,
scriveva:
"ambiguity can be avoided by signing the bitmap 
that constitutes the analogue graphical representation
of a digital document" 

riferendosi ai formati immagine quindi come formati "sicuri",
cioè statici, privi di rischi di ambiguità.
Il nostro attacco dimostra che, con una via diversa,
anche i formati immagine possono essere
"pericolosi".
D'altra parte ritengo che la restrizione sui formati
ipotizzata da FRanco Ruggieri sia inapplicabile.


3. che il documento tampered con il nostro attacco non abbia
le caratteristiche richieste dalla legge per avere validità
legale, sia o no applicabile la normativa tecnica vigente,
deriva dall'ambiguità del documento, e quindi dalla
impossibilità di attribuire un funzione dichiarativa alla firma.
Giustamente come osserva Resoli non si puo' stabilire
cosa il firmatario ha "approvato" con la firma.
Ma il problema non è giuridico
(anche se sono sicuro che piu' di un giurista
sarebbe capace di scrivere 10 pagine
di commenti su questo tema se volesse...magari per non concludere 
nulla -- con tutto il rispetto per i giuristi).
Il problema è conoscere le minacce ed eventualmente
attrezzarsi per contrastarle.
In Italia si pensa troppo spesso che i problemi
si risolvono "per decreto". Basta fare una norma e abbiamo la coscienza 
a posto.
Cosi' siamo il paese con il piu' alto numero di norme
al mondo ma spesso serenamente violate o disattese.

Nel caso in questione, piu' che dire (come fa l'illustre
giurista di Interlex) che i documenti contraffatti non sono
validi e con questa affermazione negare
la significatività del problema segnalato,
bisognerebbe semmai affrontare la questione dell'adeguamento
delle norme tecniche e, di conseguenza, dei sw di firma
e verifica.

Poi davvero non capisco come mai Interlex si sia cosi'
seriamente preoccupato degli attacchi basati sulle macro di word
(articolo di giustozzi del 2002 - 
http://www.interlex.it/docdigit/corrado8.htm)
Anche quelli non sono documenti con le carte in regola....
addirittura in questo caso c'e' una precisa norma
che lo esclude (art. 3 comma 3 del DPCM 13 gennaio del 2004).
E ai tempi dell'articolo di Giustozzi c'era
la deliberazione AIPA 51/2000, che escludeva addirittura
il formato word!

4. Resoli cita correttamente il documento
CWA 14170. Viene citato anche nel nostro articolo
scientifico (per cui ci è assolutamente noto).
Le prescrizioni di quel documento derivano dalla consapevolezza
che non è facile prevedere le fonti di ambiguità.
Il nostro lavoro, che individua una nuova
fonte di ambiguità dei doc informatici,
è una ulteriore prova di questo.

5. sulle nostre pagine www.unirc.it/firma
si possono trovare ulteriori commenti
a supporto delle posizioni che ho sostenuto
in questi giorni, nelle (talora assurde)
discussioni avvenute sul Web.



Ringrazio per l'interesse
Saluti
Francesco Buccafurri




> Mah, mio parere spassionato: il problema c'è; anche se il
> documento bifronte non ha validità legale, sostanzialmente perchè
> non è un Documento Informatico, anche se la firma è valida
> tecnicamente.
>
> Il problema è che non è possibile capire quale fosse la reale
> intenzione del firmatario, perchè non si sa cosa abbia visto al
> momento della firma, poichè non ha dato alcuna consenso su quale
> sia il Content-Type legittimo.
>
> Su questa cosa anche le raccomandazioni del CEN sono molto chiare:
> da CWA 14170, capitolo 7.6, Tabella 6 (Acronimi: SD -> Signer's
> Document DTBS -> Data To Be Signed )
>
> "3. Inappropriate presentation of the SD.
>
> === Title of Threat ===
> That a verifier perceives a SSD (nota di roberto: è un typo,
> secondo me intendevano SD) in a different form to that perceived
> by the signer because the verifier interprets the SD using a
> different Data Content Type to that used by the signer.
>
> === Threat ===
> This can happen in the context of any application or security
> policy that allows more than one SD Data Content Type.
>
> === Security Requirement ===
> The DTBS shall contain the Data Content Type of the SD if this is
> not indicated by other means. "
>
>
> Credo che un'aggiornamento della normativa, sulla scorta di quanto
> fatto in altri paesi, sia opportuna.
>
> ciao, rob
>


--
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts: