[Linuxtrent] Re: attacco alla firma digitale
- From: "Roberto Resoli" <roberto.resoli@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 10 Jul 2008 21:48:44 +0200
Il 10 luglio 2008 15.56, Francesco Buccafurri <bucca@xxxxxxxx> ha scritto:
> 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.
Mi pare di capire, nonostante le doppie negazioni :-), che sia un complimento,
grazie.
In effetti, mi è semplicemente capitato di avere a che fare con la
firma digitale per qualche anno, per una serie di circostanze
particolari.
> 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.
Non credo sia molto interessante capire "di chi è la colpa",
quanto rendersi conto che per garantire la sicurezza di un processo
non ci si può limitare a considerare solo alcuni aspetti, ma bisogna esaminare
tutta la catena.
Questa cosa mi ricorda un po' la vicenda della linea Maginot; negli
anni precedenti la I guerra mondiale,
i francesi costruirono una poderosa linea di difesa lungo il confine,
pensando così di aver eretto un baluardo inespugnabile.
Le truppe tedesche semplicemente aggirarono la linea e attaccarono da
un'altra parte.
L'attuale normativa sulla firma mi sembra un po' come la linea
Maginot: ci si concentra solo sul dispositivo di firma, e sulla
crittografia.
Nessuno attaccherà mai li, lo farà su altri fronti, come dimostra
efficacemente la vicenda del documento bifronte.
E bisogna dire che la rozzezza dell'associazione tabellare di un
estensione ad un mime-type
fatta da windows sembra fatta apposta per questo attacco.
Indubbio che ce ne possano essere altri parimenti efficaci su altre piattaforme.
> 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.
non so. A me pare che un documento che cambia visualizzazione
dall'oggi al domani non sia degno di tal nome.
> 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à.
Sicuramente; non esiste documento sicuro, perchè avrò sempre
bisogno di un interprete per visualizzarlo.
Che poi il codice stia nel documento o nell'interprete...
sono le due cose insieme che concorrono alla mia percezione.
> 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.
Sicuramente riduce l'applicabilità pratica della firma in moltissimi campi.
> 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.
Sono d'accordissimo. Questi problemi sono segnalati da anni.
Non so se si possano risolverle, ma prenderne coscienza serenamente mi
pare saggio,
> 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.
Parole sante.
> 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.
Vedremo, forse qualcosa si muoverà ...
....
> 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.
Purtroppo sono documenti assai poco noti, e men che meno applicati
in pratica (almeno qui da noi)
> 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.
andrò a leggere;
Saluti,
Roberto Resoli
> 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
>
>
>
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: