Emanate le norme tecniche per la firma digitale… e adesso?

Computer Programming n.ro 81 del 21-09-02

Prima di analizzare dettagliatamente il testo del DPCM (che non è uno standard per la compressione audio ma significa “Decreto Presidente Consiglio Ministri” ) di cui sopra è bene chiarire da subito qualche equivoco suscitato, più o meno in buona fede, da “disinteressati” operatori del settore dicendo cosa non è e cosa non fa la firma digitale.

Do per scontato che possediate un minimo di fondamenti di crittografia a chiave pubblica e che sappiate dell’esistenza del DPR 513/97 (il provvedimento che attribuisce pieno valore legale ai file firmati digitalmente) di cui ho parlato spesso in precedenti articoli di Computer Programming (molti dei quali disponibili in rete su http://www.spaghettihacker.it).

La cosa fondamentale da tenere presente è che pur essendo tecnicamente possibile usare svariati algoritmi per “firmare”, solo l’impiego di quelli indicati nel DPCM secondo le modalità ivi stabilite consente di attribuire ai file un valore giuridico assolutamente equivalente ai documenti cartacei.

Ciò implica che:

a – PGP e tutti gli altri programmi di crittografia a chiave pubblica, anche se in grado di “firmare” un file non rientrano nell’applicazione di questa legge, quindi non possono essere utilizzati per produrre certificazioni valide e rilevanti ad ogni effetto di legge.

b – la firma digitale legalizzata (FDL uso questa dicitura per distinguerla da quella comune) troverà applicazione essenzialmente nell’ambito della Pubblica Amministrazione e del settore business to business.

c – per quanto riguarda il commercio elettronico (dato e non concesso che i numeri sull’utenza sbandierati di recente siano attendibili) continueranno ad applicarsi gli attuali sistemi che garantiscono la sicurezza del canale di trasmissione (SSL) con autenticazione dell’utente tramite attribuzione di userid e password. Da un punto di vista giuridico (praticamente: davanti al giudice) queste transazioni hanno comunque un valore legale anche se meno “forte” di quelle certificate con la FDL. I sistemi diversi da quelli che usano la FDL possono essere impiegati per tutti quegli acquisti (e sono la stragrande maggioranza) che non richiedono necessariamente la forma scritta.

d – le varie Certification Authority attualmente presenti non sono quelle di cui al DPCM ma soltanto degli operatori che si offrono come garanti dell’identità di terze parti. Questa certificazione ha una rilevanza giuridica indiretta.

Quale ruolo per gli sviluppatori?

Fatte queste doverose premesse e sfruttando il fatto che siete ancora sicuramente “freschi” anticipo quello di cui avrei voluto scrivere alla fine dell’articolo, vale a dire degli spazi che si aprono per chi sviluppa software.

Come vederemo meglio in seguito, la normativa non specifica nè piattaforme nè programmi ma solo algoritmi e standard tecnici, ne consegue che chiunque potrà realizzare delle applicazioni per la gestione della firma digitale, ed in effetti sul mercato già cominciano a spuntare – manco a dirlo con l’etichetta dei “soliti noti” – i primi esempi di software crittografici targati “Italia”.

Manco a dirlo – pure se la legge non lo specifica – si tratta di applicazioni proprietarie che girano su piattaforme proprietarie. In altri termini: scatole nere delle quali si ignora il funzionamento e la struttura. Se questo può andare bene per videogiochi, browser e wordprocessor che se funzionano male poco importa, sono meno tranquillo quando il “metodo” si applica ad un settore così delicato come quello della identità elettronica (di fatto, la firma digitale null’altro è se non questo). Si, avete capito bene, intendo parlare ancora una volta di Opensource, una filosofia che – anche in questo caso – dimostra di essere strumento di analisi estremamente potente.

Interludio 1 – libertà di codice

I termini della questione sono chiari, ma li riassumo brevemente per chiarezza di esposizione. Da qualche tempo si è diffuso un approccio allo sviluppo di software che – contrariamente al modello attualemente dominante – obbliga la completa accessibilità ai sorgenti e la loro libera modificabilità. Da un punto di vista tecnico questo si traduce in una maggiore efficenza e stabilità delle applicazioni oltre che in una loro più rapida evoluzione. Il risvolto politico/giuridico dell’Opensource è che consente di liberare le Istituzioni da una vera e propria “schiavitù elettronica” fornendo loro i mezzi per emanciparsi dall’uso di tecnologie proprietarie che le asserviscono ad interessi privati (e spesso stranieri). Altri Paesi hanno già cominciato sperimentazioni in tal senso, come la Francia, che dall’ottobre dello scorso anno ha installato in strutture pubbliche 100 stazioni che fanno girare Linux, con lo scopo dichiarato di liberarsi di sistemi proprietari. Ciò significa dunque – avendo a disposizione i sorgenti – poter esercitare un controllo pieno ed assoluto sullo sviluppo di software.

Torniamo a noi

Ma cosa c’entra tutto questo con la crittografia?

Presto detto.

Tutto il meccanismo di certezza giuridica atribuito alla firma digitale, ancora prima che sulla complessa infrastruttura di certificazione, deve necessariamente basarsi su algoritmi di cifratura estremamente robusti e su programmi che li implementano in modo efficiente e senza bug.

Il migliore degli algoritmi applicato in un software che funziona male fa crollare l’intero castello. L’esempio più evidente, concreto e attuale di quello che sto dicendo è PGP. Notoriamente PGP è considerato dalla “comunità” il non plus ultra della crittografia, e ciò non ostante il fatto che la stessa guida del programma metta in guardia gli utenti da un’eccessiva “fiducia” nello strumento. Forse non molti sanno che la versione 6.01 per Windows98 di questo software contiene un’utility – PGPDisk – che consente di creare dei dischi virtuali da montare e smontare con una passphrase al cui interno sono cifrati i file. Peccato che questa utility sia buggata (tant’è che è stata rilasciata immediatamente la release 6.02 in grado di importare i file creati con la precedente) vanificando quindi in concreto la protezione che in teoria sarebbe offerta da sistemi “a prova di bomba”.

Ora provate ad immaginare cosa potrebbe succedere nel campo della firma digitale se più o meno casualmente il meccanismo di generazione e custodia delle chiavi dovesse rivelarsi malcostruito o mal progettato… se del software in questione non fossero noti i sorgenti sarebbe praticamente impossibile – per chiunque tranne che per i malintenzionati – individuare e segnalare il difetto, con il risultato che un numero enorme di persone potrebbe trovarsi nella condizione di chi guida un’automobile convinto di avere i freni, che però funzionano a “corrente alternata”. Non è difficile immaginare cosa potrebbe accadere affrontando qualche curva, magari un po’ imprudentemente.

Avendo accesso ai sorgenti, viceversa, chiunque potrebbe analizzare l’applicazione, individuare eventuali problemi e segnalarli a chi di dovere.

L’obiezione più immediata a questo ragionamento è che rendendo publiche le specifiche si favorsice il “lavoro” dei criminali ma se ci pensate su un attimo scoprirete che non è così.

In primo luogo perchè il “principio di Kerchoffs” – il pilastro della crittografia – stabilisce che la sicurezza di un sistema deve dipendere dalla segretezza della chiave e non da quella dell’algoritmo (e quindi il fatto che le soluzioni tecniche adottate siano conosciute non è un ostacolo alla loro divulgazione). In secondo luogo perchè l’approccio “security through obscurity” (italicamente traducibile con un non rigorosissimo “occhio non vede, cuore non duole”) è paragonabile ad una noce di cocco… dura da rompere, ma una volta spaccata non c’è più difesa per il contenuto.

Ciò premesso, rispondo alla domanda contenuta nel titoletto… un software standard per l’applicazione della firma digitale non esiste. I problemi tecnici dell’impiego di queste tecnologie nell’ambito di reti estese e multi piattaforma sono ancora tutti da esplorare, così come assai oscuri sono al momento i programmi per la gestione delle certificazioni delle chiavi. Insomma… un vero e proprio universo digitale si offre a chi avesse la voglia e il coraggio di “spingersi la’ dove nessun uomo è mai arrivato prima” (con mille scuse ai fan di Star Trek!).

Qualche curiosità…curiosa

Concludendo questa introduzione alle norme tecniche (oggetto della seconda parte che comparirà sul prossimo numero) vorrei fare cenno ad alcune perplessità che mi danno da pensare.

Come è noto, “la legge non ammette ignoranza”. In altri termini non si può andare davanti ad un giudice e giustificarsi dicendo “non lo sapevo!”. Dal che consegue che il cittadino dovrebbe essere messo in condizioni di conoscere le leggi in modo da evitare il problema di cui sopra, ed in effetti a questo serve la Gazzetta Ufficiale. Pecato che nel caso di queste norme tecniche si faccia amplissimo riferimento a standard, protocolli e quant’altro che sono coperti da copyright, con la conseguenza che se qualcuno volesse conoscere il testo integrale delle norme in questione non si potrebbe limitare alla tradizionale Gazzetta ma, mettendo mano al portafogli, dovrebbe procurarsi altrove queste informazioni.

Si potrebbe rispondere che al cittadino medio non interessano queste sottigliezze tecniche, importanti invece per aziende che quindi hanno la capacità economica per acquistare ciò che occorre.

Questa non è una risposta.

Il diritto di accesso alle leggi non può essere subordinata all’uso che di queste deve essere fatto, specie, lo ripeto, in un settore come quello dell’identità elettronica, dove solo il controllo diffuso della collettività può costituire la forma più efficiente di “immunizzazione” da errori più o meno in buona fede.

Il resto, alla prossima puntata.

Possibly Related Posts: