Roberto A. Foglietta en Knowledge Lovers (Every Bee's Hive), Communications and journalism, IT - Information Technology ◽Freelance Consultant • ◾www.roberto.foglietta.name 19/4/2018 · 5 min de lectura · +600

Scrivere una PEC con un PDF allegato

Scrivere una PEC con un PDF allegato

6th Draft – Published on April 18, 2018 on Linkedin

Introduzione

La sezione Fisco de Il Sole 24 Ore ci informa con un articolo del 10 aprile 2018 che l'allegato PDF in una PEC non ha automaticamente valore legale, cosa per altro nota almeno dal 7 gennaio 2015 e comunque desumibile dallo standard PEC:

Sono sempre più numerose le pronunce di merito che censurano le modalità digitali utilizzate dal Fisco per la formazione e la notificazione degli atti impositivi. Così, la CTR Liguria (sentenza 1745/3/2017, presidente Canepa e relatore D’Avanzo) e la CTP Treviso (sentenza 93/1/2018, presidente Chiarelli e relatore Fadel) ribadiscono ancora una volta che è inesistente la notifica di un atto impositivo se avviene tramite messaggio PEC contenente in allegato il file dell’atto non firmato digitalmente.

Il PDF allegato a una PEC

Qualora però il messaggio contenesse il testo (non formattato) e/o codici hash del PDF allegato allora il messaggio deve essere considerato nella sua interezza ovvero allegato incluso.

La ragione risiede nel come viene a formarsi la "busta" PEC che contiene messaggio ed allegato. 

Sebbene dopo l'apertura della PEC, il messaggio e l'allegato sono separabili, i codici hash nel messaggio lo mettono in univoca relazione con l'allegato formando un catena di fiducia/sicurezza dalla busta al messaggio e dal messaggio all'allegato.

Già nel maggio del 2015 era stato chiarito il punto dai vari siti che si occupano di legge, ad esempio:

Per esempio, non avrebbe alcuna valida prova scritta in mano chi invii, alla propria controparte, una PEC che riporti il seguente messaggio: “Si invia comunicazione come da allegato” e poi il testo vero e proprio è contenuto in un pdf. Meglio sarebbe fare un “copia e incolla” del contenuto dell’allegato al corpo dell’email.

Anche per la Raccomandata A/R non esiste la certezza che la comunicazione sia aperta e letta da parte della persona interessata.

D'altronde anche per la PEC non potrebbe essere diverso in quanto anche qualora il gestore di comunicazione certificasse legalmente all'interno della sua piattaforma l'apertura, non potrebbe garantire che effettivamente sia stata letta dalla persona interessata.

Ciò non può valere per un'azienda, dotata di organizzazione propria, per la quale è ragionevole supporre che l'organizzazione stessa provveda alla gestione della casella PEC e delle relative comunicazioni.

La ricevuta di consegna

Su Wikipedia Italia si può trovare qualche altra informazione riguardo alla PEC e il servizio di ricevuta di consegna completa che, invece, certifica anche il contenuto:

Esiste una funzionalità che permette, a chi invia, di chiedere una ricevuta di consegna "completa" (cioè che contiene anche una copia esatta, firmata digitalmente dal proprio gestore di posta, del messaggio spedito): tale ricevuta "completa" fa piena prova del contenuto inviato (al contrario di quanto avviene con la tradizionale posta raccomandata cartacea, con la quale il mittente non dispone di una prova sull'effettivo contenuto del plico imbustato: per ovviare a questo limite della tradizionale raccomandata, si può ricorrere all'espediente di non utilizzare la busta per spedizioni ma di confezionare il plico con lo stesso contenuto, opportunamente ripiegato e sigillato).

È perciò un limite di chi utilizza lo strumento della PEC piuttosto che dello strumento stesso, anche se a parte Italia, Svizzera e Hong Kong, il resto del mondo fa affidamento sullo standard descritto dalla RFC 3798 e non riconosce la PEC.

Caratteristiche della comunicazione

Nella misura in cui il testo della comunicazione è firmato digitalmente oppure l'indentità del mittente legalmente accettabile nell'ambito della comunicazione e il testo della PEC riporta un riferimento al l'allegato e il relativo codice hash l'intera comunicazione nel suo complesso {mittente, testo, allegato, destinatario, data, ora} ha validità legale.

Potrebbe non rispettare altri requisiti aggiuntivi relativi a delle norme specifiche alla comunicazione o allo scopo della comunicazione ma nel suo complesso vale quanto sopra scritto.

Ad esempio nella comunicazione fra due parti private fra le quali si è già instaurato un rapporto di natura giuridica che le identifica univocamente la necessità della firma digitale non può essere considerato un requisito indispensabile stante il fatto che non può esserci dubbi sulla reciproca identità delle parti e la PEC garantisce gli altri requisiti relativi alla comunicazione.

Anche su questo punto però occorre fare un distinguo che implica la rappresentanza legale ovvero la firma digitale garantisce che, all'interno dell'organizzazione comparente come mittente della comunicazione, il legale rappresentante abbia sottoscritto la comunicazione, salvo non provi che le credenziali gli siano state sottratte in modo fraudolento e utilizzate a sua insaputa.

Perciò in caso di contestazione l'originalità, l'integrità e la volontà inerenti alla comunicazione si accettano in sede di giudizio, mediazione o arbitrato.

Utilizzo degli hash code

A questo punto vale la pena spendere alcune parole sulla scelta e l'utilizzo del codice hash.

Il codice hash è una stringa alfanumerica con caratteristiche peculiari fra le quali la capacità di relazionare l'input ad uno specifico output in modo univoco ma non il viceversa in quanto, generalmente, la sequenza di bit di output è più corta di quella in input.

Collisioni degli hash code

Ne consegue che tutti gli hash possono avere collisioni ma quelli definiti criptograficamente forti garantiscono che:

  • 1. alla minima variazione della stringa di bit in ingresso corrisponda una macroscopica variazione del codice hash in uscita;

  • 2. due sequenze di bit che in ingresso alla funzione di hash fornirebbero lo stesso codice hash sono così diverse fra loro da non essere confondibili.

Vediamo nella pratica cosa significa. Si consideri la funzione hash(...) così sotto descritta:

  • hash( fileA ) = 8b3c6fe9
  • hash( fileB ) = b57f733d
  • hash( fileC ) = 8b3c6fe9

Il fileC è una collisione del fileA. 

Ad esempio abbiamo una piantina catastale A che è differente dalla stessa per le modifiche in B, gli hash delle due sono molto diversi. Ma il fileC che é il testo ASCII della Divina Commedia ha lo stesso codice hash del fileA. 

Questo non è un problema perché il nostro disquisire riguarda se la piantina catastale allegata in PDF abbia le modifiche A oppure quelle B non che sia un file ASCII contenente il testo di un'opera.

La validità degli hash code

La bontà di una funzione di hashing è nel suo algoritmo a parità di lunghezza del codice hash prodotto. 

A parità di algoritmo usato, la forza del codice hash ovvero la sua resistenza a essere violato dipende dalla sua lunghezza.

Per violare un codice hash potremmo immaginare di utilizzare i campi non visibili dello standard PDF allora abbiamo il fileA a cui applichiamo le modifiche affinchè diventi il fileB e quindi alteriamo i campi non visibili alla ricerca di un hash code che collida con quello prodotto dal file A

  • hash( fileA, modifiche B, {N alterazioni invisibili} ) = {hash-1, ..., hash-N}

Al tentativo N-esimo potremmo trovare che hash( fileB* ) = hash( fileA ). 

  • Più è grande il numero medio <N> dei tentativi che occorre fare per trovare una collisione più è sicura la funzione di hash;

  • Il numero di tentativi medio per attaccare la funzione md5sum(...) è di circa due centinaia di trilioni di trilioni di trilioni.

Prendiamo alcune funzioni per esempio: CRC32, md5sum, sha1sum, sha256sum, sha512sum. 

Il CRC non è una funzione hash ma una funzione di controllo errore (circular redundancy code, 32 bit) perciò nonè utile al nostro scopo.

La funzione md5sum è genera un hash MD5 che al momento è considerato debole ovvero il numero di tentativi per trovare una collisione è relativamente basso che si può affrontare con attacchi di tipo brute-force. 

Questo non significa che chiunque possa farlo ma che è possibile che la controparte obbietti sulla debolezza dello md5sum come funzione di hash come diversivo.

Le funzioni sha*sum sono l'implementazione del medesimo algoritmo SHA-1 con finestre di elaborazione e stringhe di uscita di lunghezza differente. Quindi a parità di algoritmo SHA, la sua forza cresce esponenzialmente come 2^(4n) dove n è la differenza di lunghezza del codice in uscita. 

La lunghezza dei codici hash definisce l'ampiezza degli spazi in cui possono diversificarsi i relativi codici hash:

  • md5: 2^(4 * 32) = 3.4 * 10^38

  • sha1: 2^(4 * 40) = 1.5 * 10^48

  • sha512: 2^(4 * 128) = 1.3 * 10^154

Perciò potremmo pensare che la soluzione migliore sia quello di scegliere la sha512sum perchè l'algoritmo SHA è migliore di quello MD5 e la lunghezza del codice hash è più lunga.

Intanto abbiamo capito che non basta allegare il codice hash ma occorre anche specificare quale algoritmo e anche quale specifica funzione che utilizza quell'algoritmo. 

Inoltre due hash corti potrebbero essere meglio di uno solo lungo perché in questo modo l'attaccante dovrebbe trovare una doppia collisione ovvero una collisione all'interno di uno spazio di possibilità che è il prodotto dello spazio del primo hash moltiplicato quello del secondo hash.

Aspetti dibattimentali

In questo senso una coppia di hash {md5sum, sha1} generano uno spazio di hashing di 72 caratteri esadecimali ovvero uno spazio di 2^(4 * 72) combinazioni che è più piccolo di quello fornito dalla funzione sha512sum però ha una peculiarità: deve essere attaccato contemporaneamente su due funzioni diverse. 

Da un punto di vista puramente teorico non cambia molto ma da un punto di vista argomentativo: se trovare una collisione è equivalente a comprare un biglietto della lotteria e vincere il primo premio allora trovarne due significa comprare due biglietti e vincere sia il primo che il secondo premio. 

E' palese che l'uso di due hash ha una forza argomentativa incredibilmente superiore perché che qualcuno possa vincere alla lotteria è vagamente plausibile ma che possa vincere due volte insieme non è credibile.

Infine non guasta dare una descrizione dell'allegato sia in termini di formato, impaginazione e descrizione del contenuto: 

Si allega file PDF contenente la scansione in bianco e nero della relazione del geometra Tizio redatta in data X su tre pagine A4 inclusa la piantina in ultima pagina. Tale documento allegato è univocamente indetificato dai seguenti codici hash md5sum: 8B3C...6FE9; sha1sum: B57F...733D.

Così si è creata una copia digitale fedele e legalmente valida del documento originale in cartaceo. 

A questo punto l'invio di una PEC il cui contenuto soddisfi i requisiti richiesti e abbia in allegato il PDF a cui corrispondano i codici hash riportati nel testo della PEC costituisce nel suo complesso una comunicazione legalmente tanto valida quanto il testo della PEC stesso. 

Infatti, se il testo è una comunicazione valida allora sono stati comunicati i codici hash e poiché questi identificano univocamente l'allegato in PDF ne consegue che spetterà all'altra parte dimostrare di aver ricevuto qualcos'altro in allegato.

Gli hash code sono presentati in caratteri esadecimali {0, ..., 9, A, B, C, D, E, F} perciò le lettere possono essere rappresentate in minuscolo oppure in maiuscolo. Scegliere quest'ultimo aiuta a leggerli qualora si stampino su carta.

Approccio BlockChain alla comunicazione

Inoltre se la comunicazione non è a se stante ma a sua volta riporta esplicitamente, contestualmente, coerentemente e mediante identificativi univoci altre comunicazioni precedenti allora si forma una catena. Se la comunicazione viene replicata verso diversi destinatari essa ha anche un backup. 

Perciò nel suo insieme, una tale comunicazione, può costituire una catena, che potrebbe essere spezzata in un anello, ma potrebbe anche costituire una rete in cui ogni singola parte della comunicazione è validamente legata alle altre anche da più di una connessione. 

Questo significa che anche se un collegamento o una parte dovesse essere messa in dubbio nel suo complesso il quadro di riferimento rimarrebbe valido.

Uno sguardo al futuro

Per quanto riguarda la resistenza dei codici hash, può darsi che quando in futuro la disponibilità di computer quantistici sarà alla portata di chiunque, la validità dei codici hash potrebbe essere messa in discussione ma si tenga presente che l'algoritmo SHA-1 è utilizzato per le comunicazioni sicure TLS, SSL e SSH quindi anche PEC perciò, nell'evenienza, la vastità del problema sarà di portata epocale.

Conclusione

Gli strumenti tecnologici se conosciuti e utilizzati correttamente offrono opportunità anche maggiori degli strumenti convenzionali. 

D'altra parte ogni nuova opportunità sottende anche a dei rischi nuovi e in particolare se utilizzata in modo scorretto la tecnologia può creare più  problemi di quanto ne avrebbe potuto risolvere.

Non è solo un problema di utilizzo perché quanto poco ci sarebbe voluto a coloro che hanno sviluppato e gestiscono le piattaforme PEC inserire in automatico un fondo al messaggio che riportasse i dati identificativi degli allegati incluso una coppia di codici hash? 

Molto poco e avrebbero evitato un errore abbastanza prevedibile da parte degli utilizzatori. Piuttosto vale la pena chiedersi perché non sia stato fatto.

Anche questo caso ci fa riflettere sulla necessità di affrontare la digitalizzazione in un'ottica più olistica e secondo i paradigmi dell'innovazione.

Humor da nerd

L'inossidabile fierezza dei primitivi digitali...

Indice di tutti gli articoli pubblicati

Condividi

(C) 2018, Roberto A. Foglietta, testo licenziato con Creative Common Attribuzione, Non commerciale, Condividi allo stesso modo, versione 3.0, Italia (CC BY-NC-SA 3.0 IT).