Prove per whistleblower: marca temporalmente senza pubblicare

Una Proof of Existence sigillata può preservare le prove di un whistleblower senza pubblicare mai i file. Il mittente calcola l'hash delle prove, le cifra per un solo destinatario scelto e pubblica un record Label 309 su Cardano. Il record on-chain contiene solo l'hash e le chiavi incapsulate — mai il testo in chiaro, e mai l'identità del destinatario. In seguito il destinatario decifra il file e conferma che corrisponde all'impegno con timestamp.

Questo dimostra che le prove esistevano entro un momento pubblico e che hanno raggiunto chi detiene una chiave specifica. Non rende anonimo il mittente, non lo mette al sicuro, non garantisce alcuna protezione legale né assicura che qualcosa venga ammesso in tribunale. Considera un record sigillato come uno strato di prova e cifratura, non come una strategia di disclosure a sé stante.

Quale problema risolve davvero?

Le prove sono fragili. Un file si può cancellare. Un documento si può modificare. Uno screenshot si può contestare. Un export di un database si può rigenerare e retrodatare. Un whistleblower ha spesso bisogno di dimostrare che un file specifico esisteva prima di una disclosure, di una denuncia per ritorsione, di un audit o di una causa — e di dimostrarlo senza affidarsi alla buona volontà dell'organizzazione oggetto delle prove.

Allo stesso tempo, pubblicare il file in chiaro può essere pericoloso, illegale o semplicemente sbagliato. Può esporre persone terze, segreti commerciali o cartelle cliniche.

Un record Label 309 sigillato separa la prova dal testo in chiaro. La linea temporale può essere pubblica e permanente. Il contenuto resta cifrato per un solo destinatario. Ottieni il timestamp senza pagare il prezzo della disclosure.

Come funziona la prova sigillata, passo dopo passo?

Il flusso è lo stesso descritto in hash, firma, sigilla, condividi, applicato a materiale sensibile:

1. Il mittente prepara il file con le prove, o un manifest che descrive molti file.
2. Il software calcola l'hash del testo in chiaro.
3. Il contenuto viene cifrato per l'indirizzo di ricezione del destinatario — la chiave di contenuto viene incapsulata nella chiave pubblica del destinatario in una busta sigillata in stile age.
4. Il testo cifrato viene conservato in una posizione indirizzata per contenuto (ar:// o ipfs://). Lì viene conservato solo il testo cifrato; il testo in chiaro mai.
5. Un record Label 309 viene pubblicato su Cardano e porta con sé l'hash e la chiave incapsulata — non il testo in chiaro, non la chiave pubblica del destinatario.
6. In seguito il destinatario recupera il testo cifrato e lo decifra in locale.
7. Il destinatario ricalcola l'hash del testo in chiaro e lo confronta con il record.

Il record dimostra quando l'impegno esisteva. Il file decifrato dimostra su cosa verteva l'impegno. Servono entrambe le metà, e la seconda resta privata a chi detiene la chiave.

Perché non mettere le prove direttamente sulla blockchain?

Perché una catena pubblica è permanente, e alcune prove non si possono mai rendere pubbliche in sicurezza. Il materiale sensibile può contenere dati personali, informazioni aziendali riservate, dettagli clinici, segreti commerciali, credenziali, vulnerabilità di sicurezza, i nomi di persone estranee ai fatti o contenuti soggetti a vincoli di legge. Una volta finito su un registro pubblico, non si può più tornare indietro.

Una prova sigillata permette al mittente di impegnarsi sui byte esatti senza esporli. Il destinatario riceve e verifica il contenuto in privato, mentre il resto del mondo vede solo che un qualche record sigillato è stato pubblicato a un certo block time. È lo stesso schema trattato in disclosure riservata senza file pubblici.

Chi dovrebbe essere il destinatario — e come raggiungere quello giusto?

Scegli il destinatario con cura. Può essere un giornalista, un avvocato, un'autorità di vigilanza, un ufficio etico interno, un revisore, un'organizzazione della società civile o un investigatore di fiducia. Il requisito imprescindibile è che il mittente disponga di un indirizzo di ricezione che appartenga davvero al destinatario previsto.

Un indirizzo di ricezione è solo una stringa di chiave pubblica (ha l'aspetto di age1…). Di per sé non dimostra nulla su chi lo controlla — Label 309 non specifica deliberatamente alcuna directory né alcun registro fidato di chiavi. Quindi, per prove sensibili, il mittente dovrebbe confermare l'indirizzo tramite un canale già fidato da entrambe le parti, esattamente come descrive verificare un destinatario prima di sigillare un file.

Sbagliare qui ha un costo reale: invia alla chiave sbagliata e le prove diventano illeggibili per la persona che intendevi — o leggibili da qualcuno che non intendevi.

Il mittente dovrebbe firmare il record?

Di solito no, se l'obiettivo è evitare l'attribuzione.

Una firma a livello di record vincola il record a una chiave pubblica. È utile quando un'azienda o una persona nominata vuole assumersi la responsabilità. È rischiosa quando il mittente deve evitare di collegare la disclosure a un'identità.

Le firme di paternità in Label 309 sono sempre facoltative. Un record sigillato non firmato dimostra comunque che l'impegno sulle prove esisteva entro un momento pubblico — semplicemente non rivendica alcuna paternità pubblica e, on-chain, non vincola alcuna identità del mittente. Il compromesso è semplice:

• i record firmati aggiungono responsabilità;
• i record non firmati evitano un'attribuzione pubblica garantita da una chiave.

Quale sia quello giusto dipende interamente dal contesto legale e di sicurezza, ed è una decisione da prendere con un legale, non da un articolo di blog.

Un record sigillato rende anonimo il mittente?

No. È il limite più importante in assoluto, quindi vale la pena essere netti.

Un record Label 309 sigillato e non firmato tiene fuori dalla catena il testo in chiaro, l'identità del destinatario e qualsiasi firma del mittente, e il feed globale dei record è cieco rispetto al destinatario — nulla al suo interno rimanda a chi può decifrare. Ma l'anonimato dipende da molto più dei byte di un singolo record. Tutto ciò che sta fuori dal record può comunque esporre il mittente:

• metadati di rete e indirizzi IP;
• fingerprint del browser o del dispositivo;
• un dispositivo compromesso;
• tracce di pagamento;
• attività dell'account sul gateway;
• correlazioni temporali tra le pubblicazioni;
• metadati di file, documenti e fotocamera;
• lo stile di scrittura;
• errori operativi;
• il canale usato per parlare con il destinatario.

La crittografia non può risolvere questi aspetti. Sono il terreno di strumenti dedicati alla protezione delle fonti, della sicurezza operativa e della consulenza legale. Non considerare una Proof of Existence sigillata come un sistema di anonimato — consideralo un modo per marcare temporalmente e cifrare, e abbinalo agli strumenti giusti per tutto il resto.

Cosa può verificare il destinatario una volta che ha il file?

Un destinatario con la chiave privata corrispondente può controllare l'intera catena di affermazioni:

• che il record Label 309 esiste su Cardano;
• il block time e il contesto di conferma di quel record;
• che la sua chiave apre uno degli slot della busta, recuperando la chiave di contenuto;
• che l'hash del testo in chiaro ricalcolato corrisponde all'hash impegnato sulla catena;
• una inclusion proof Merkle, se le prove erano una foglia di un bundle più ampio;
• una firma del record, se il mittente ha scelto di firmare.

Chiunque non disponga di una chiave corrispondente — un verificatore pubblico incluso — può comunque confermare che il record esiste, che la sua busta è ben formata e che l'URI del testo cifrato è raggiungibile. Ciò che non può fare è decifrarlo o scoprire su cosa verte l'impegno. Questa separazione è il punto: la catena fa da testimone a un impegno, e solo chi detiene la chiave conferma su cosa verte.

Cosa non dimostra una prova sigillata?

Un timestamp è ristretto di proposito. Un record sigillato non dimostra:

• che le prove siano veritiere;
• che il mittente sia tutelato dalla normativa sul whistleblowing;
• che la disclosure sia legale;
• che il destinatario sia affidabile o che manterrà riservato il testo in chiaro;
• che il file sia stato ottenuto lecitamente;
• che il mittente sia anonimo.

E una volta che un destinatario decifra il contenuto, nulla gli impedisce di condividerlo — la cifratura protegge il file in transito e a riposo, non la discrezione del destinatario dopo.

Ciò che un record sigillato dimostra è preciso e utile: un impegno con timestamp su byte specifici, recapitato a chi detiene una chiave specifica. Non sostituisce una consulenza legale, la prassi giornalistica di protezione delle fonti, gli strumenti di comunicazione sicura o un piano di sicurezza. Per approfondire questo confine, vedi cosa una prova non dimostra.

Perché sigillare un manifest invece di un singolo archivio?

Le prove arrivano di solito come un insieme, non come un unico file ordinato. Invece di sigillare un singolo archivio opaco, il mittente può costruire un manifest delle prove che registra:

• i nomi dei file o identificatori neutri;
• gli hash per ciascun file;
• il momento della raccolta;
• note su fonte e catena di custodia;
• lo stato delle redazioni;
• le informazioni sul destinatario;
• le foglie Merkle e le inclusion proof.

Le voci sensibili possono a loro volta essere cifrate. Il manifest aiuta il destinatario a capire cosa è stato divulgato e a verificare i singoli file in seguito. Per insiemi di grandi dimensioni, una singola Merkle root impegna l'intero bundle pur permettendo di controllare ogni file per conto proprio — l'approccio di un record per migliaia di file.

Come dovrebbe prepararsi un'organizzazione a ricevere disclosure sigillate?

Le organizzazioni dovrebbero fare il lavoro di base prima di invitare le persone a inviare prove sensibili. Significa pubblicare gli indirizzi di ricezione con cura, ruotarli o ritirarli quando serve, verificare la titolarità dell'indirizzo da un capo all'altro, proteggere i seed dei destinatari che possono decifrare, definire con chiarezza chi è autorizzato a decifrare e documentare come vengono gestite le prove sigillate.

Dovrebbero anche essere oneste con le fonti riguardo ai limiti. Un indirizzo di ricezione non è un sistema completo di secure-drop; è una componente di un processo di intake. Un'organizzazione che vuole sostenere disclosure realmente ad alto rischio ha bisogno di procedure legali, di sicurezza e operative costruite attorno alla crittografia — non della sola crittografia.

In che modo questo aiuta in seguito, in una controversia?

Stabilisce la linea temporale delle prove. Se più avanti sorge una questione, il destinatario potrebbe essere in grado di mostrare:

• il riferimento della transazione Cardano;
• il record Label 309 e il suo block time;
• il payload cifrato;
• le prove decifrate;
• l'hash del testo in chiaro corrispondente;
• la inclusion proof Merkle, per un file in bundle;
• il fatto che l'impegno esisteva prima di una certa data.

Questo può sostenere un'indagine, una segnalazione, una revisione legale o un processo di accountability interno — e, poiché la verifica richiede solo i metadati della transazione, i byte e un explorer pubblico di Cardano, non dipende dal fatto che CardanoWall esista ancora. Sono prove sull'esistenza e sull'integrità, non su chi abbia ragione. Lo schema correlato per le disclosure aziendali sensibili al tempo è trattato in cronologie degli incidenti di sicurezza, e il contesto più ampio del tribunale in prove legali ed e-discovery.

In breve

Un record Label 309 sigillato permette a un whistleblower e a un destinatario scelto di preservare le prove in privato. Marca temporalmente un impegno, cifra i file per un solo destinatario e consente a quel destinatario di dimostrare in seguito che i byte decifrati corrispondono al record pubblico.

Non garantisce anonimato, legalità, sicurezza o veridicità, e un destinatario può divulgare ciò che decifra. Usalo come uno strato attento all'interno di un processo di disclosure più ampio e ben consigliato — mai come l'intero piano.

Approfondimenti

• Disclosure riservata senza file pubblici
• Verifica un destinatario prima di sigillare un file
• Cosa una prova non dimostra
• Lo standard Label 309: label309.org
• Il codice open-source, la CLI e gli SDK: github.com/cardanowall