Perché le tue chiavi non lasciano mai il dispositivo

In CardanoWall, le tue chiavi private restano sul tuo dispositivo. Il software che firma, sigilla, decifra a tentativi e verifica gira in locale; il gateway ospitato è progettato per non ricevere mai il tuo Identity Seed, la tua chiave di firma, le tue chiavi di destinatario né il materiale che decifra un file sigillato.

Il gateway ha parecchio da fare anche senza quei segreti. Può calcolare un preventivo, accettare testo cifrato già pronto per lo storage, inviare una transazione Cardano, indicizzare i record e tenere traccia del tuo saldo. Niente di tutto questo richiede le chiavi che dimostrano la paternità o aprono un payload sigillato. La separazione è voluta: il servizio aiuta a far viaggiare la prova, e tu conservi i segreti.

Di quali chiavi stiamo parlando?

Un'identità Label 309 parte da un singolo valore: un Identity Seed da 32 byte. Da quel seed, qualsiasi software conforme deriva le chiavi che un'identità usa davvero, in tre ruoli:

• una chiave Ed25519 che firma i record;
• una chiave X25519 che riceve i record sigillati in modo classico;
• una chiave ibrida post-quantum che riceve i record sigillati in modo post-quantum.

La derivazione è deterministica. Gli stessi 32 byte producono sempre le stesse tre coppie di chiavi, in qualunque client conforme. È questo che rende il seed portabile — ed è questo che lo rende l'unica cosa che valga la pena custodire. Chiunque possieda il seed può ripristinare l'identità, firmare al suo posto e decifrare i record sigillati indirizzati a essa. Per questo il seed resta privato, e tutto ciò che segue discende da qui.

Cosa fa il client in locale?

Il client gestisce ogni operazione che tocca una chiave privata:

• generare o importare un Identity Seed;
• derivare da esso le chiavi di firma e di ricezione;
• firmare i record;
• cifrare i file prima del caricamento;
• costruire gli slot sigillati del destinatario che avvolgono una chiave di contenuto;
• decifrare a tentativi i record in arrivo per individuare quelli indirizzati a te;
• decifrare il testo cifrato e ricalcolare l'hash del testo in chiaro;
• verificare le firme e la struttura dei record.

L'app web, l'app desktop, lo strumento da riga di comando e qualsiasi software costruito sugli SDK differiscono per il modo in cui conservano le chiavi e per come le sbloccano. Il principio non cambia tra l'uno e l'altro: il materiale delle chiavi private non viene inviato al gateway.

E allora cosa fa il gateway?

Il gateway esegue il flusso di pubblicazione. Può:

• calcolare un preventivo;
• ricevere testo cifrato già pronto e restituire un URI indirizzato per contenuto;
• accettare un record di prova predisposto;
• inviare una transazione Cardano e attendere la conferma;
• gestire le riorganizzazioni della catena e rimborsare automaticamente se una pubblicazione fallisce in modo permanente;
• indicizzare i record in un feed condiviso;
• tenere traccia del saldo del tuo account;
• esporre la propria API ed emettere eventi del ciclo di vita.

Sono compiti reali, e costituiscono gran parte del lavoro operativo. Ma nessuno di essi ha bisogno di una chiave che decifri il tuo contenuto sigillato. Il gateway è uno strato di trasporto e di operazioni. Non è il vault della tua identità, e non è progettato per comportarsi come tale.

Perché questa separazione conta?

Perché una prova dovrebbe restare verificabile senza fidarsi del servizio che ha contribuito a crearla.

Se un servizio ospitato detenesse l'unica copia delle tue chiavi, quel servizio diventerebbe la tua radice di fiducia. Se chiudesse, cambiasse i termini, subisse una violazione o bloccasse il tuo account, la tua capacità di firmare, decifrare o persino verificare potrebbe dipendere da esso. È proprio la situazione che Label 309 è costruito per evitare.

Un record Label 309 è verificabile a partire da dati pubblici. A un verificatore servono soltanto i metadati della transazione, facoltativamente i byte del contenuto e un explorer Cardano pubblico — nessun server dell'emittente, in nessun passaggio. Un record sigillato può essere aperto da chi possiede la chiave. Un record firmato può essere controllato rispetto alla sua chiave di firma. Il gateway può rendere la pubblicazione molto più semplice, ma per progetto non può leggere un payload sigillato correttamente solo perché ha contribuito a metterlo on-chain.

È questa la differenza tra un servizio che ti dice di avere una prova e una prova che si regge da sola.

Il gateway può leggere i miei file sigillati?

Se il client ha sigillato il contenuto correttamente, no — il gateway vede sempre e solo testo cifrato.

Ecco com'è strutturato un record sigillato. Il record pubblico on-chain si impegna sull'hash del testo in chiaro — quell'hash, insieme al block time, è la prova del timing. Il payload cifrato in sé non finisce mai on-chain; risiede a un URI indirizzato per contenuto (come ar://). La chiave di contenuto è avvolta verso una o più chiavi pubbliche di destinatario, uno slot per ciascun destinatario. Il destinatario (o il mittente) recupera il testo cifrato, lo decifra in locale e ricalcola l'hash del testo in chiaro per confermare che coincida con l'impegno on-chain.

Il gateway può vedere che esiste un record sigillato, e può osservare la dimensione del testo cifrato, i tempi di caricamento, l'attività dell'account, lo stato della transazione e i metadati pubblici. Non è progettato per vedere il testo in chiaro, e senza la giusta chiave privata il testo cifrato resta illeggibile. Due avvertenze oneste accompagnano tutto questo: la sigillatura protegge la riservatezza, non l'anonimato — i metadati osservabili restano comunque metadati — e un destinatario che decifra un file può sempre scegliere di divulgare il testo in chiaro in un secondo momento. La cifratura protegge i byte in transito e a riposo, non ciò che fa poi un lettore autorizzato.

Il gateway può falsificare una prova valida?

È progettato in modo che non possa far superare una verifica indipendente a una prova non valida.

Un verificatore controlla il record on-chain, la struttura del record, gli hash, le firme e — per un record sigillato che riesce ad aprire — l'hash del testo in chiaro ricalcolato. Se un gateway mentisse su una transazione, alterasse i byte del record, eliminasse una firma o puntasse a byte che non corrispondono all'hash su cui ci si è impegnati, un verificatore indipendente dovrebbe accorgersene.

È una promessa precisa, e vale la pena non esagerarla. Un gateway può comunque comportarsi male nei modi operativi ordinari: può non riuscire a pubblicare, ritardare una transazione, restituire un errore, riportare in modo scorretto il proprio stato, avere un'interruzione di servizio o offrirti un'esperienza scadente. Ciò che non dovrebbe essere in grado di fare è trasformare una prova non valida in una che si verifica senza problemi rispetto ai dati pubblici. La comodità può venire meno; l'affermazione crittografica non dipende dall'onestà del gateway.

E nello specifico per l'app web?

L'app web è software che gira in un browser, e questo ne plasma il modello di fiducia.

Il confine rilevante comprende il browser, il codice dell'applicazione che viene caricato, qualsiasi estensione installata, il dispositivo stesso e il flusso di sblocco. Un browser è comodo, ma non è lo stesso ambiente di un vault desktop o di uno strumento da riga di comando eseguito da una build che controlli tu. Uno script malevolo in una sessione sbloccata può leggere i segreti in memoria; una content-security policy rigorosa, script ridotti al minimo e un passaggio di sblocco esplicito riducono questa esposizione, ma nessuna app web può sostenere di eliminarla.

È uno dei motivi per cui esiste un client desktop dedicato, per chi vuole storage locale e un controllo più stretto su come vengono custodite le chiavi. L'invariante vale per ogni client — il gateway non ha bisogno delle tue chiavi private — anche se ciascun client protegge quelle chiavi in modo diverso. Per un resoconto più completo di dove passa la linea, vedi cosa CardanoWall può e non può vedere.

E per l'app desktop?

CardanoWall Desktop è un'applicazione open source e multipiattaforma, costruita fin dall'inizio attorno a un vault cifrato locale.

Un core in Rust possiede il vault dell'identità, la crittografia, il motore di sincronizzazione, la decifratura a tentativi e la verifica, con una webview che si limita a renderizzare l'interfaccia. I seed e le chiavi private derivate non vengono passati alla webview come normali stringhe JavaScript; quando un contenuto deve essere mostrato in anteprima, i byte decifrati vengono trasmessi alla view attraverso un canale dedicato, anziché transitare per la pagina come stringa. I segreti non vengono inviati al gateway, e non passano nel renderer.

Quell'architettura restringe la superficie di attacco; non la cancella. Un sistema operativo compromesso, una dipendenza malevola, un keylogger o un malware approvato dall'utente possono comunque vanificare la sicurezza locale — lo stesso limite onesto che porta con sé qualsiasi wallet desktop. Tenere le chiavi fuori dal gateway e fuori dal renderer è un miglioramento concreto, non una garanzia contro un host completamente compromesso. Per come funziona nel dettaglio, vedi la panoramica di CardanoWall Desktop e delle prove offline.

E per lo strumento da riga di comando e gli SDK?

Contano perché rendono lo stesso modello disponibile senza il sito web.

Uno sviluppatore può tenere un seed in locale, firmare i record in locale, sigillare i file in locale e inviare attraverso qualsiasi gateway. Un sistema di integrazione continua può pubblicare con credenziali API a permessi limitati, mantenendo il materiale dell'identità sotto i controlli del team. Un'azienda può costruire il proprio client o integrare Label 309 nel software esistente. La divisione resta la stessa a prescindere dall'interfaccia che scegli: il gateway pubblica, il client conserva i segreti.

Lo strumento da riga di comando e gli SDK sono open source e indipendenti dal gateway, così il confine è qualcosa che puoi ispezionare anziché qualcosa che devi dare per buono sulla fiducia.

Cosa non andrebbe mai inviato a un gateway?

Non inviare mai questi elementi a un gateway — né ad alcun sito web:

• il tuo Identity Seed L309-SEED-1…;
• il seed grezzo in esadecimale;
• una chiave privata di firma;
• una chiave privata di ricezione X25519;
• un segreto di ricezione ibrido post-quantum;
• una passphrase che decifra contenuto sigillato;
• testo in chiaro che intendevi tenere privato.

Il gateway può legittimamente aver bisogno di chiavi pubbliche, firme pubbliche, byte pubblici del record, testo cifrato, identificatori di preventivo, token API e identificatori di account. Quelli non sono materiale d'identità privato. La regola è semplice: se un flusso di lavoro ti chiede di incollare un segreto da qualche parte, fermati e domandati perché.

Cosa richiede comunque la tua attenzione?

Le chiavi locali sono sicure solo quanto l'ambiente che le circonda. La crittografia tiene un gateway lontano dai tuoi segreti; non può proteggere un seed che un utente copia in un form controllato da un attaccante. Quindi devi comunque:

• proteggere il tuo Identity Seed e tenerne un vero backup;
• verificare l'indirizzo di ricezione di un destinatario prima di sigillare qualcosa di sensibile;
• evitare i siti di phishing;
• essere accorto con le estensioni del browser;
• mantenere aggiornati i tuoi dispositivi;
• usare la cifratura del disco dove ha senso;
• capire come vengono messi in cache i file decifrati;
• eseguire build fidate degli strumenti desktop e da riga di comando;
• definire politiche di gestione delle chiavi per i flussi di lavoro condivisi o di team.

Vale la pena essere schietti sui modi in cui le cose possono andare storte, perché non sono simmetrici. Se perdi il seed e i tuoi fattori di sblocco, l'uso futuro di quell'identità è perduto — anche se qualsiasi prova già pubblicata continua a verificarsi, per sempre, a partire dai dati pubblici. Un seed rubato è una compromissione totale dell'identità: la risposta è creare una nuova identità e disattivare la vecchia, non reimpostare una password. Non c'è alcun reset; è il prezzo del fatto che non esiste un custode.

Perché questo conta per uno standard aperto

Uno standard di prova aperto non dovrebbe dipendere da un unico operatore fidato.

Se CardanoWall sparisse domani, un record Label 309 dovrebbe restare significativo. Se un'azienda gestisce il proprio gateway, i suoi record dovrebbero restare standard. Se esporti il tuo seed verso un altro client conforme, dovrebbe derivare esattamente le stesse chiavi. Tutto questo funziona solo se il confine resta pulito: i record sono standard, la verifica è indipendente, i gateway sono sostituibili, i client conservano i segreti, e puoi sempre fare tu stesso il backup della radice dell'identità.

Quindi «le chiavi non lasciano mai il dispositivo» non è uno slogan. È parte di ciò che rende portabile una Proof of Existence — una prova che puoi portare con te oltre qualsiasi singolo servizio, questo incluso.

La versione breve

Il gateway aiuta a pubblicare la prova. Il client conserva i segreti.

Le chiavi private non vengono inviate al gateway. Il contenuto è cifrato prima del caricamento. La decifratura avviene in locale. La verifica non dipende dal fidarsi della parola di un servizio. È questa la forma di sicurezza su cui CardanoWall è costruito — e la forma che Label 309 è progettato per mantenere aperta.

Approfondimenti

• La tua identità è un seed — cos'è l'Identity Seed e perché è il vero backup.
• Come CardanoWall conserva la tua identità — il vault cifrato e cosa il server può e non può decifrare.
• Cosa una prova non dimostra — i limiti onesti delle prove di timing e integrità.
• Lo standard Label 309 su label309.org, proposto al processo CIP di Cardano e in revisione presso gli editori CIP.
• I client open source, gli SDK e il gateway su github.com/cardanowall.