Verifica il destinatario prima di sigillare un file

Prima di sigillare un file sensibile, verifica l'indirizzo di ricezione del destinatario tramite un canale che difficilmente un attaccante può controllare. Un indirizzo di ricezione è una chiave pubblica, non un nome. Se cifri verso la chiave sbagliata, ad aprire il file potrebbe essere chi possiede quella chiave — e non chi volevi davvero raggiungere.

È il fallimento umano più comune nei flussi di lavoro cifrati. La crittografia può essere impeccabile e l'invio risultare comunque errato, perché nulla, in una stringa di caratteri, dimostra di chi sia la chiave. La cifratura risponde alla domanda «chi può aprire questi byte?». Non risponde a «ho scelto la persona giusta?».

Cos'è un indirizzo di ricezione?

Un indirizzo di ricezione è una chiave pubblica di cifratura che il mittente usa per sigillare un record. Con CardanoWall esiste in due forme:

age1... — un indirizzo di ricezione classico X25519;
age1pqc... — un indirizzo di ricezione ibrido post-quantum.

Il mittente sigilla verso l'indirizzo pubblicato del destinatario. Il destinatario apre il record con la chiave privata corrispondente, derivata dal suo Identity Seed. L'indirizzo è fatto per essere condiviso; la chiave privata e il seed devono restare segreti. (Per saperne di più su cos'è un indirizzo e su come i destinatari lo distribuiscono, vedi cos'è un indirizzo di ricezione.)

Perché verificare la chiave è così importante?

Perché le chiavi pubbliche non sono identità.

Chiunque può inviarti una stringa che assomiglia a un indirizzo di ricezione. Chiunque può incollare una chiave accanto a un nome familiare. La stringa di per sé non dimostra nulla su chi controlla la chiave privata corrispondente — solo che qualcuno la possiede. Un attaccante che ti fa avere il proprio indirizzo riesce a leggere tutto ciò che sigilli «verso» il tuo contatto, mentre il tuo contatto non riceve niente.

Per un file di prova usa e getta può non avere importanza. Per prove legali, dati di un incidente, informazioni personali, lavori inediti o materiale di whistleblower, verifica la chiave prima di sigillare. La rubrica serve proprio a rendere stabile questa verifica: controlli la chiave una volta, la salvi e riutilizzi la voce salvata invece di reincollare ogni volta una stringa di cui doverti fidare di nuovo.

Cosa rende buono un canale di verifica?

Usa un percorso che difficilmente l'attaccante può controllare e conferma la chiave tramite un canale diverso da quello che l'ha consegnata. Opzioni ragionevoli, all'incirca in ordine di robustezza:

una consegna di persona (per esempio, scansionando insieme un codice QR);
una telefonata a un numero che già conosci, leggendo ad alta voce il fingerprint della chiave;
una pagina di chiavi .well-known sul dominio ufficiale del destinatario;
un record DNS TXT su quel dominio;
un profilo firmato, collegato dal sito ufficiale del destinatario;
una conversazione cifrata end-to-end già esistente di cui ti fidi;
una directory di chiavi approvata dall'organizzazione;
un fingerprint della chiave stampato e consegnato tramite un processo di cui ti fidi.

Il metodo giusto dipende da cosa stai inviando. Per file di alto valore, conferma su due canali indipendenti: una chiave che ti arriva via email e viene riletta in una telefonata è molto più difficile da falsificare di ciascuno dei due da solo.

Cosa non basta da solo?

Un nome familiare non basta. Considera questi casi come non verificati finché un secondo canale non li conferma:

una chiave che arriva in un thread di email nuovo di zecca;
un messaggio diretto da un account che non hai verificato;
uno screenshot di una chiave;
un profilo pubblico senza alcun collegamento fidato alla persona;
un indirizzo che ti viene inoltrato da terzi;
un messaggio del tipo «ecco la mia nuova chiave» senza alcun controllo su un secondo canale.

Gli attaccanti si concentrano sul momento dello scambio di chiavi, perché è l'unico passaggio in cui una chiave sostituita appare del tutto normale. Una volta salvata una chiave sbagliata, ogni invio futuro può continuare in silenzio a finire nel posto sbagliato.

Come dovresti usare la rubrica?

Salva la chiave dopo averla verificata, mai prima. Per ogni contatto fidato, la rubrica registra:

un nome visualizzato;
la chiave pubblica di firma Ed25519 del contatto (l'identificatore che lega i suoi record a lui);
un indirizzo di ricezione age1..., se ne ha uno;
un indirizzo di ricezione post-quantum age1pqc..., se ne ha uno;
come hai verificato la chiave, e quando;
note in formato libero — annota esattamente come l'hai controllata.

In seguito, quando componi un record sigillato, scegli il contatto dalla rubrica invece di incollare di nuovo un indirizzo. Così una sola verifica accurata si trasforma in molti invii più sicuri. Per una guida pratica su come crearne una, vedi crea la tua rubrica e come funziona la rubrica.

Conviene preferire l'indirizzo post-quantum?

Per i file che potrebbero restare sensibili per molti anni, sì: usa l'indirizzo post-quantum quando il destinatario ne offre uno.

Un indirizzo ibrido age1pqc... è molto più lungo di uno classico, ma protegge da un attaccante che oggi registra il testo cifrato sigillato e lo decifra più avanti con un futuro computer quantistico («harvest now, decrypt later»). Se un record deve restare riservato solo nel breve termine, di solito basta un indirizzo classico age1....

Qualunque sia la tua scelta, la regola non cambia: verifica prima l'indirizzo. Una chiave post-quantum che non hai verificato non è più sicura di una classica che non hai verificato.

E se il destinatario cambia le chiavi?

Verifica la nuova chiave come se fosse un nuovo contatto. Non sovrascrivere un indirizzo di ricezione salvato solo perché un messaggio sostiene che è cambiato — è esattamente la forma che assume un attacco di sostituzione di chiave. Conferma la nuova chiave tramite un canale fidato, aggiorna la voce e annota il motivo del cambiamento.

Per team e organizzazioni, la rotazione delle chiavi dovrebbe essere annunciata in posti prevedibili: un dominio ufficiale, un profilo firmato o un processo interno documentato. Se sospetti che una chiave sia stata compromessa, smetti subito di sigillare verso il vecchio indirizzo e aspetta che il nuovo venga confermato.

Cosa rivela on-chain un record sigillato?

Non una lista leggibile di destinatari. Un record sigillato Label 309 racchiude la chiave del contenuto in uno slot cifrato per ciascun destinatario, poi li mescola, così il record pubblico non porta alcun campo «destinatario» in chiaro. La Inbox trova i record destinati a te decifrando a tentativi ogni slot in locale con le tue chiavi. Ciò che un osservatore può vedere è che esiste un record sigillato, quando è stato pubblicato e quanti slot ha — mai chi sono i destinatari.

Questa cecità rispetto al destinatario protegge la privacy on-chain, ma non fa nulla per la verifica della chiave. La catena nasconde verso chi hai sigillato; non può controllare che tu abbia sigillato verso la chiave giusta. Scegliere l'indirizzo corretto resta interamente compito del mittente. E nota il limite sull'altro versante: sigillare mantiene il testo in chiaro cifrato per chi possiede le chiavi, ma non garantisce l'anonimato, e qualunque destinatario può divulgare il testo in chiaro una volta che l'ha decifrato. (Per cosa una prova può e non può stabilire, vedi cosa una prova non dimostra.)

In breve

Una buona cifratura più un cattivo controllo della chiave è comunque un cattivo invio. Quindi:

verifica un indirizzo di ricezione prima di sigillare qualcosa di sensibile, idealmente su due canali;
salva le chiavi verificate nella rubrica; annota come ciascuna è stata controllata;
riverifica quando una chiave cambia — tratta la nuova chiave come un contatto del tutto nuovo.

La crittografia è la parte facile. La verifica è la parte che spetta a te.

Per approfondire

Cos'è un indirizzo di ricezione e profili pubblici e indirizzi di ricezione.
Come ricevere record sigillati e divulgazione riservata senza file pubblici.
Modalità whitelist per i record in arrivo — un filtro complementare della Inbox per ciò che ricevi.
Lo standard aperto Label 309 su label309.org; il codice open-source, gli SDK e la CLI su github.com/cardanowall.