Sicurezza reale e sicurezza di carta
di Andrea Monti - 25.02.03
Due vulnerabilità in qualche mese: quella relativa alla sottoscrizione di
file contenenti campi dinamici (come quelli di Microsoft Word) e quella sulla
verifica dei certificati di cui si parla in questo numero. Questo è il poco
invidiabile primato raggiunto dal "sistema firma digitale" italiano
che rischia di mettere in discussione certezze giuridiche, investimenti
miliardari e soprattutto il processo di innovazione della PA.
E' infatti appena il caso di evidenziare che, dimostrata per tabulas
la presenza dei difetti in questione, le presunzioni normative sulla provenienza
e sull'integrità del documento firmato digitalmente cominciano a vacillare.
Dipendenti come sono dalla garanzia offerta dai noti modelli matematici che
descrivono la crittografia a chiave pubblica e la funzione di hash. Queste
caratteristiche teoriche sembravano garantire la "tenuta stagna" del
transatlantico "firma digitale" che, appena uscito dal porto, ha
invece cominciato a imbarcare acqua da più parti.
E allora le considerazioni più immediate di fronte al naufragio che si
profila sono essenzialmente due. La prima riguarda le decisioni tecniche operate
dai certificatori e in particolare su quelle che hanno privilegiato modelli di licensing
proprietari. E' inutile ripetere tesi ampiamente dibattute, e per le quali
basta rinviare a scritti già pubblicati (vedi Utilizzare la firma digitale. Le applicazioni pratiche
evidenziano nuovi problemi). E' opportuno invece domandarsi - e veniamo
alla seconda considerazione - come sia stato possibile "aggirare" una
normativa che dicono essere rigorosa e inespugnabile proprio sul versante
tecnico. Facendo si che si potessero realizzare software "a norma" che
invece rivelano dei difetti di progettazione e non solo di implementazione.
Attenzione: la questione non è banale. I difetti che affliggono un sistema
di firma (almeno quelli noti ad oggi) non dipendono da vulnerabilità del
software (come nel caso del recente worm che ha infettato i server Microsoft SQL)
ma appunto da evidenti carenze di progettazione. In altri termini: se il
software di verifica della firma non è in grado di accorgersi della
"genuinità" di un certificato, vuol dire che le relative istruzioni
non sono state proprio scritte. Così come la mancata rilevazione della presenza
di dati variabili all'interno di un file evidenzia, semplicemente, che
scrivendo l'applicazione non ci si è posti il problema.
E allora - per spiegare ciò che è accaduto - i casi sono due: o la
normativa non è sufficientemente rigorosa (lasciando mano troppo libera a chi
ha sviluppato i software) o non è stata prestata adeguata attenzione alla sua
"traduzione" in linee di codice. Non si capisce però, a questo punto,
che senso abbia sbandierare l'approvazione AIPA del manuale operativo, quando
il software cui ci si riferisce è tutt'altro che "a norma". Quindi
non resta che lamentare l'ennesimo bug normativo, che non ha attribuito all'AIPA
il potere di entrare nel merito delle funzionalità dei prodotti. Come dire,
l'importante è che ci sia una sicurezza di carta. |