Interlex n.ro 245
di Andrea Monti
Due vulnerabilità in qualche mese: quella relativa alla sottoscrizione di file Microsoft Word contenenti campi dinamici e quella sulla “certificazione 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 variabli 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”. Ma soprattutto c’è da domandarsi che cosa sia oggetto di controllo da parte delle autorità competenti, se le funzionalità del software o invece (come pare sia) la sola correttezza formale delle procedure descritte nei voluminosi manuali redatti dai certificatori. Come dire, l’importante è che ci sia una sicurezza di carta.
Possibly Related Posts:
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?
- Le accuse mosse a Pavel Durov mettono in discussione la permanenza in Europa di Big Tech
- Cosa significa l’arresto di Pavel Durov per social media e produttori di smart device
- Il nodo della crittografia è arrivato al pettine della UE
- Dopo SPID è ora di cancellare anche la firma digitale