L’Italia è il luogo dove le migliori intenzioni tecnologiche vanno a morire nel labirinto delle procedure amministrative. L’ultimo, eclatante esempio di questo corto circuito tra innovazione e realtà è la gestione della Firma Elettronica Qualificata (FEQ), comunemente chiamata Firma Digitale.

Siamo di fronte a un paradosso kafkiano: un sistema nato per garantire la massima sicurezza giuridica e l’integrità dei documenti digitali sta, di fatto, costringendo migliaia di cittadini e professionisti a compiere l’atto legalmente più sconsiderato possibile: firmare un contratto senza averlo letto.

Non è un’esagerazione iperbolica, è la quotidiana realtà segnalata da chiunque si trovi a interagire con piattaforme della Pubblica Amministrazione, come i portali delle Camere di Commercio.

La Trappola del Checksum e il Mito dell’Integrità

Per capire come siamo finiti in questo vicolo cieco, dobbiamo scendere per un attimo nel tecnico, ma non troppo. La firma digitale si basa su un concetto matematico solido: l’hashing. Quando firmi un file, il software calcola una “impronta digitale” unica (il checksum) di quel file e la sigilla crittograficamente con la tua chiave privata. Se anche un solo bit del documento cambia, l’impronta non corrisponde più e la firma decade. È una garanzia assoluta di integrità.

Il problema non è la matematica, è come l’Amministrazione Italiana ha deciso di implementarla.

I sistemi della PA spesso pretendono che il cittadino scarichi un modulo PDF precompilato, lo firmi digitalmente e lo ricarichi. È qui che scatta la trappola. Un PDF moderno non è un pezzo di carta inerte; è un contenitore dinamico.

Se un utente, spinto dal più elementare buon senso, decide di aprire quel PDF appena scaricato per rileggerlo e verificare che i dati siano corretti prima di apporvi la sua firma, commette un “errore” fatale. Software comuni come Adobe Acrobat o Anteprima su Mac spesso modificano invisibilmente i metadati del file all’apertura. Aggiungono la data dell’ultima visualizzazione, ottimizzano la struttura delle pagine, inseriscono tag proprietari.

Per l’occhio umano il testo è identico. Per il computer, il file è cambiato. Il checksum è alterato.

Quando il cittadino, ignaro, firma quel file e prova a caricarlo sul portale della PA, il sistema lo rigetta con un errore crittografico. Il risultato? Ore perse, costi inutili, frustrazione e la necessità di ricominciare la procedura.

L’Incubo del file .p7m e l’Istruzione dell’Assurdo

A complicare le cose c’è l’amore italico per il formato CAdES, che trasforma i documenti nei famigerati file con estensione .p7m. Questo formato avvolge il documento originale in una “busta crittografica” che lo rende illeggibile a un normale doppio clic. Per visualizzarlo, l’utente deve possedere software specifici (come Dike o ArubaSign), che non sempre sono a portata di mano o facili da usare per tutti.

Si è arrivati così all’istruzione dell’assurdo, diffusa ufficiosamente da molti sportelli PA e consulenti: “Una volta scaricato il modulo, non apritelo assolamente. Firmate il file p7m ‘al buio’ e ricaricatelo subito, altrimenti il portale non lo accetta.”

Siamo al collasso del senso logico e giuridico. La firma è l’atto con cui un soggetto si assume la paternità e la responsabilità del contenuto di un documento. Come può la legge pretendere che questo atto avvenga impedendo, di fatto, la verifica del contenuto stesso un istante prima della sottoscrizione? È un sistema che premia l’obbedienza cieca alla procedura tecnica a discapito della consapevolezza dell’atto legale.

Verso eIDAS 2.0: Uscire dalla Preistoria dei File p7m

Tutto questo ci insegna che non basta digitalizzare; bisogna farlo mettendo l’essere umano al centro del processo (User Experience, o UX). Il modello attuale, basato su client desktop e manipolazione fisica di file, è preistorico.

In teoria la soluzione è in arrivo ed è già tracciata dal nuovo regolamento europeo eIDAS 2.0, che si materializza in Italia con l’EUDI Wallet (il famigerato IT Wallet). Con esso si passerà dal concetto di “firma sul file” alla “firma sul dato” via API/Cloud.

Ma viste le premesse vogliamo scommettere che la soluzione, anche in questo caso, non rispetterà le aspettative ?