Un servizio che firma prove sui tuoi dati ha una tentazione evidente: mettere i dati nella prova. Renderebbe più facili la ricerca e il supporto e permetterebbe una dashboard più ricca. Abbiamo deciso presto che le ricevute Trustvice non lo avrebbero fatto: una ricevuta porta l’hash di ciò che descrive, non il contenuto.
Questo post spiega perché, e dove il design smette di proteggerti senza il tuo aiuto.
Prove che devono viaggiare#
Una ricevuta è utile solo se puoi darla a qualcuno: un auditor, una controparte, un mediatore. Tutto ciò che contiene è leggibile da chi la riceve. Se le ricevute portassero contenuti, ogni ricevuta condivisa lascerebbe trapelare qualcosa, e dovresti pensare ogni volta a cosa oscurare.
Un hash SHA-256 lo evita. Sono 64 caratteri esadecimali che identificano i byte esatti del tuo contenuto senza rivelarli. La ricevuta dice in sostanza: a quest’ora, questi byte sono stati presentati con questa etichetta. I byte li tieni tu. Quando serve, li produci, chiunque ne calcola l’hash, e l’hash corrisponde alla ricevuta oppure no.
Dove l’hash non basta#
Ti trarremmo in inganno se ci fermassimo qui. Gli hash proteggono bene i contenuti a una condizione, e alcuni campi di una ricevuta non sono affatto hash.
Un hash nasconde il contenuto solo quanto il contenuto è imprevedibile#
SHA-256 non si inverte, ma si può indovinare. Se l’input ha poche possibilità, come una risposta sì o no, un indirizzo email, un codice breve o un modello noto, chi ha la ricevuta può calcolare l’hash dei candidati e confrontarli. Per contenuti così, includi un valore casuale, un nonce, in ciò di cui calcoli l’hash, e conserva il nonce con l’originale. La ricevuta prova allora l’esistenza senza permettere a chi legge di indovinare.
Alcuni campi sono scritti in chiaro#
Le etichette e gli altri campi di testo libero che scegli sono scritti in chiaro e, una volta firmati in una ricevuta, ci restano. Usa identificativi opachi, come un numero d’ordine o un id interno, e tieni la tabella di corrispondenza dalla tua parte.
Calcola l’hash dei byte esatti#
Un hash identifica byte, non significato. Un a capo finale, \r\n invece di \n o una diversa normalizzazione Unicode danno un hash diverso. Per il testo, decidi una volta codifica e fine riga e rispettali. Per i record strutturati, salva i byte esatti di cui hai calcolato l’hash, non una nuova serializzazione: un JSON.stringify successivo con un altro ordine delle chiavi ha un hash diverso. Per più file, calcola l’hash di un manifest che elenca l’hash di ogni file, e attesta il manifest.
Conserva i tuoi originali#
Pianifica una conseguenza: una ricevuta non può riprodurre il contenuto. Se perdi l’originale, la ricevuta continua a verificarsi, ma non prova più nulla di utile su un documento che puoi mostrare. Conserva gli originali in modalità write-once, accanto alle loro ricevute.
Cancellazione e natura della prova#
C’è un limite che nessun design può eliminare. Una ricevuta già consegnata a qualcun altro resta verificabile da lui qualunque cosa facciamo, perché la verifica richiede solo la ricevuta e una chiave pubblica. È la proprietà che la rende una prova. Ed è anche il motivo per cui i consigli sopra contano: tieni i dati personali fuori dai campi in chiaro, e la questione di cancellare una ricevuta diventa raramente difficile. Di solito basta cancellare l’originale nel tuo archivio, perché la ricevuta ne tiene solo l’hash.
In breve#
Firmiamo fatti sui tuoi dati, non i dati. Partire dall’hash permette alle ricevute di circolare e fa sì che la verifica non richieda mai di fidarsi del nostro storage. Non rende privato un valore indovinabile e non protegge ciò che scrivi nei campi in chiaro. Usa nonce per input piccoli, id opachi per le etichette e conserva i tuoi originali.
Approfondisci in Cosa prova una ricevuta e cosa no e nella nostra pagina sulla sicurezza.
Demo live