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