Secondo un certo DPCM 13/11/2014, dall’11 febbraio scorso nelle copie autenticate in proprio dagli avvocati di atti e provvedimenti presenti nel fascicolo informatico sarebbe necessario indicare (anche) l’impronta di hash e l’UTC: il primo equivale al codice fiscale del file, ossia ad un riferimento univoco capace di stabilire che un certo file è identico ad un altro bit-per-bit; l’UTC è invece il riferimento temporale, ossia la data e l’ora in cui l’autentica stessa è stata effettuata.
Sull’applicabilità o meno di tale dpcm al pct (e alle notifiche pec) la migliore dottrina si è divisa, mentre la giurisprudenza non si è ancora pronunciata: peraltro, se e quando quest’ultima lo farà, ove ritenesse applicabile il citato dpcm, non potrebbe comunque che dichiarare l’irrilevanza giuridica dell’eventuale mancanza dell’impronta di hash e/o dell’UTC, per ragioni che vi risparmio perché esulano dal tema specifico del presente articolo, che riguarda infatti altro e precisamente quanto segue.
Come detto, l’impronta di hash nella dichiarazione di autentica dovrebbe servire ad indicare che il file autenticato corrisponde bit-per-bit al file che si trova nel fascicolo informatico; una corrispondenza quindi non solo formale o apparente ma sostanziale, ontologica. Bit-per-bit, appunto. E ciò dovrebbe appunto consentire di verificare che il file autenticato è proprio uguale, in tutto e per tutto, a quello che si trova nel fascicolo informatico.
Le intenzioni del dpcm sono, tutto sommato, buone.
Senonché -e vengo al punto- di buone intenzioni sono lastricate le vie dell’inferno.
Infatti:
1) i file firmati digitalmente che si trovano nel fascicolo sono in formato p7m, mentre quegli stessi file che l’utente scarica dal fascicolo stesso sono in formato pdf: questi ultimi, cioè i file pdf autenticati in proprio dall’avvocato, sono diversi bit-per-bit dai corrispondenti file p7m che si trovano nel fascicolo: in altri termini, l’impronta di hash del file pdf autenticato, che dovrebbe servire a dire che il file autenticato stesso è uguale bit-per-bit al file p7m del fascicolo informatico non corrisponde all’impronta di hash del file p7m stesso (d’altra parte, se vi corrispondesse, non si tratterebbe di copia ma di duplicato, per il quale non sarebbe necessaria l’autentica con l’hash). Poco male, direte voi: se tutti i file pdf estratti da un medesimo file p7m che si trova nel fascicolo informatico hanno la stessa impronta di hash, la verifica dell’autentica è comunque possibile: basta effettuare un nuovo download in pdf dello stesso file p7m dal fascicolo e verificare così che il file (nuovamente) scaricato abbia la stessa impronta di hash indicata dall’avvocato nel file autenticato. Giusto, ma aspettate di leggere il punto 2.
2) Ogni volta che si fa il download di un file firmato digitalmente (p7m) che si trova nel fascicolo telematico, il sistema genera una nuova copia del file stesso che rende disponibile all’utente in formato pdf, il quale è ogni volta diverso bit-per-bit dal precedente. In altri termini, 5 download di uno stesso file p7m generano 5 pdf con 5 impronte di hash diverse. Ciò significa che l’impronta di hash indicata dall’avvocato nella dichiarazione di autentica non corrisponde né all’impronta di hash del file p7m che si trova nel fascicolo né all’impronta di hash di tutti gli altri file pdf che si scaricassero dal fascicolo al fine di verificare la corrispondenza del file autenticato dall’avvocato con quello presente nel fascicolo (giacché a questo -e non ad altro- serve l’impronta di hash).
In pratica, l’autentica del file si basa su un criterio di corrispondenza (l’impronta di hash) che… non corrisponde.
Difatti, se ad esempio l’avvocato autenticasse il file allegato alla comunicazione pec della cancelleria indicando la relativa impronta di hash, siccome quest’ultima non corrisponde mai a quella del file p7m presente nel fascicolo informatico né a quella dei file pdf da lì scaricati, la verifica di conformità del predetto file autenticato si ridurrebbe ad accertare che esso abbia lo stesso contenuto formale cioè il medesimo testo del corrispondente file presente nel fascicolo informatico da cui si sarebbe dovuto estrarre. Cioè, esattamente quello che si farebbe se non ci fosse l’impronta di hash, che è appunto del tutto inutile secondo le stesse intenzioni per cui è stata introdotta, oltre che -in ogni caso- sproporzionata allo scopo, giacché impone formalismi eccessivi (sarebbe come pretendere che il notaio autenticasse un rogito dichiarando che la copia ha non solo il contenuto ma anche il tipo di carta e addirittura l’inchiostro uguale a quelli dell’originale), senza peraltro riuscire a garantire alcunché mancando appunto una corrispondenza tra hash indicato nella copia ed hash dell’originale o di sue ulteriori copie.
Adde:
Non essendoci alcun collegamento tra l’impronta di hash e il file presente nel fascicolo informatico né soprattutto con i successivi download dello stesso file, ne consegue che l’avvocato autenticante dovrà conservare, sine die, con estrema cura il file originario da cui ha estratto l’impronta, non potendo fare affidamento sul file presente nel fascicolo informatico. Ciò non sarebbe ovviamente necessario se ogni download del medesimo file presente nel fascicolo informatico avesse la stessa impronta.