Cosa può vedere CardanoWall (e cosa non può)

CardanoWall vede i normali dati di servizio e i record di prova pubblici che pubblichi. Per progettazione non vede in chiaro il tuo Identity Seed, le tue chiavi private o il contenuto in chiaro di un file che sigilli. Il materiale più sensibile è custodito e usato sul tuo dispositivo, non sui nostri server.

Questa è la versione onesta del modello di privacy. CardanoWall è un prodotto hosted costruito su un gateway, quindi ha realmente bisogno di dati di account, fatturazione, pubblicazione e indicizzazione per funzionare. La domanda interessante non è «CardanoWall vede qualcosa?» — la risposta è sì. La domanda interessante è che tipo di dati vede e cosa resta cifrato per noi.

Questo articolo percorre quella linea di confine, categoria per categoria.

Quali dati di account conserva CardanoWall?

Normali dati di un servizio hosted. A seconda di come usi il prodotto, possono includere:

l'identificativo del tuo account;
gli identificativi di accesso, come un indirizzo email o il riferimento a un account OAuth collegato;
i record di fatturazione e il tuo saldo prepagato;
i metadati delle API key e la forma sottoposta ad hash delle API key (mai la chiave in chiaro);
i riferimenti del payment processor per le ricariche;
le impostazioni a livello di account;
i timestamp delle azioni sull'account;
i metadati di supporto e operativi;
i log di rate limit e di sicurezza.

Sono gli stessi dati che conserva qualunque servizio basato su account. Nessuno di essi è il tuo Identity Seed.

Quali dati di identità può vedere?

Le chiavi pubbliche dell'identità — e niente di privato.

In CardanoWall, un'identità deriva in modo deterministico da un singolo Identity Seed da 32 byte, e le chiavi pubbliche di quell'identità sono ciò di cui il servizio ha bisogno per fare il suo lavoro: elencare la tua identità, contare le sue prove firmate, collegare un'identità al tuo account dopo una verifica di possesso e mostrare un profilo pubblico quando scegli di pubblicarne uno.

Il servizio può quindi vedere dati pubblici dell'identità, come:

la chiave pubblica di firma Ed25519;
la chiave pubblica di ricezione X25519;
l'eventuale chiave pubblica di ricezione ibrida post-quantum;
l'ora di creazione dell'identità nel database del servizio;
lo stato del collegamento tra un account e un'identità;
gli eventuali campi del profilo pubblico che attivi.

Sono fatti pubblici o di livello di servizio. Non sono la chiave privata di firma né la chiave privata di ricezione, e non possono essere riconvertiti nel tuo seed.

Cosa non ha mai bisogno di vedere il server?

Tutto ciò che gli permetterebbe di agire al posto tuo. Il server non ha bisogno, ed è progettato per non conservare in forma utilizzabile:

gli Identity Seed in chiaro;
le chiavi private di firma Ed25519;
le chiavi private di ricezione X25519;
i segreti di ricezione ibridi (post-quantum);
il materiale di sblocco prodotto dalla tua passkey;
il contenuto decifrato del tuo vault dell'identità;
il contenuto in chiaro decifrato di un file sigillato.

Tutto questo risiede sul tuo dispositivo dopo che hai effettuato lo sblocco, oppure nei backup che controlli tu. La copia portabile e canonica di un'identità è il suo seed: quell'unico artefatto, non il comodo livello hosted, è il vero backup.

Cosa rivela al server il vault cifrato?

Che esiste — e poco altro.

Per permetterti di sbloccare su un nuovo dispositivo con una passkey, CardanoWall conserva una sola riga di vault cifrato corrente per ciascun account. Il server può leggere i metadati di quella riga — quando è stata aggiornata l'ultima volta, il suo numero di versione e quali credenziali passkey registrate vi sono associate — perché gli servono per l'esperienza di sblocco e per la gestione del ciclo di vita.

Ciò che il server non può fare è decifrare il vault. Il vault è un singolo testo cifrato in stile age, indirizzato esclusivamente ai tuoi fattori di sblocco passkey WebAuthn (le stanze PRF). Di proposito non esiste un percorso di sblocco derivato da password né un destinatario a chiave pubblica aggiunto al vault, così il testo cifrato conservato non espone nulla che il server possa attaccare offline a forza bruta. È una comodità a livello di servizio, non una custodia: noi teniamo la scatola chiusa, le tue passkey tengono le uniche chiavi.

Il testo in chiaro del vault contiene i tuoi Identity Seed e le tue etichette private di visualizzazione — esattamente il materiale che non deve mai essere leggibile dal server. Lo stesso schema regola anche la revoca: rimuovere una passkey ri-cifra il vault verso i fattori che ti restano e cancella in modo definitivo il testo cifrato precedente, così l'autenticatore rimosso non può più aprire il vault corrente. Questa è una revoca reale per lo stato attuale, anche se non è retroattiva: una copia che un attaccante ha già esfiltrato e potrebbe ancora aprire è un problema a parte. Come le passkey proteggono il tuo vault dell'identità approfondisce questo punto.

Quali dati di prova sono pubblici?

La prova stessa. I record Label 309 vengono pubblicati su Cardano proprio perché chiunque disponga del riferimento della transazione possa verificarli. A seconda del record, i dati pubblici possono includere:

gli hash del contenuto;
il riferimento della transazione;
il block time assegnato dalla catena;
la struttura del record;
le firme e le chiavi pubbliche del firmatario, quando l'autore ha scelto di firmare;
le Merkle root, per i record raggruppati;
i metadati della busta cifrata;
gli URI di storage indirizzato per contenuto (ar://, ipfs://);
il numero di slot cifrati per i destinatari;
la famiglia di key-exchange usata per un record sigillato.

Quei dati sono pubblici di proposito: sono ciò che rende verificabile una prova senza dover fidarsi di CardanoWall. Per un record sigillato, nota cosa non c'è: il contenuto in chiaro del file non finisce mai sulla catena. Un osservatore può vedere che un record è sigillato, quanti slot per destinatari ha e quale famiglia di key-exchange usa, ma non chi sono i destinatari e non i contenuti.

Cosa possono vedere i gateway di storage?

I byte conservati e i metadati delle richieste.

Se un record punta a un contenuto su Arweave o IPFS, i gateway pubblici che servono quei byte possono vedere le richieste che li riguardano. Per un file pubblico, quei byte sono in chiaro. Per un file sigillato, quei byte sono testo cifrato e dovrebbero restare illeggibili senza la chiave privata del destinatario.

I gateway possono anche osservare i tempi, la dimensione dell'oggetto e gli schemi delle richieste. Non sono il posto in cui riporre la fiducia per la riservatezza. È proprio questo il motivo per cui conviene sigillare un file sensibile prima che vada allo storage, anziché affidarsi al livello di storage per tenerlo riservato.

Cosa può vedere il browser mentre sei sbloccato?

Tutto ciò che gli serve per agire come la tua identità — finché la sessione resta sbloccata.

Dopo lo sblocco, i tuoi Identity Seed e le chiavi private da essi derivate risiedono nella memoria di sessione del browser, così l'app può firmare e decifrare. Quando decifri un file sigillato, anche il contenuto in chiaro è nel browser. Al blocco o al logout, quel materiale in memoria viene azzerato con la massima diligenza possibile.

Questa è privacy lato client, ed è onesta riguardo ai suoi limiti. Tenere i segreti sul tuo dispositivo ti protegge dalla custodia da parte del server, ma significa che il tuo dispositivo e l'ambiente del browser contano. Un'estensione del browser malevola, un software locale ostile o una falla di cross-site scripting attiva durante una sessione sbloccata possono leggere ciò che è in memoria. Header content-security rigorosi, un flusso di sblocco con script minimi e lo sblocco solo su azione esplicita riducono tutti quell'esposizione, ma non possono eliminarla. Per le identità sensibili, usa un dispositivo di cui ti fidi; storage del browser e chiavi di sessione spiega esattamente cosa viene messo in cache e cosa no.

Cosa può rivelare la rubrica?

La tua lista di contatti è un dato di servizio, e può essere sensibile a suo modo.

I contatti fidati sono voci locali all'account che ti risparmiano di incollare lunghe chiavi pubbliche ogni volta che sigilli un file per qualcuno. Una voce può contenere un nome visualizzato, una chiave pubblica di firma, eventuali indirizzi di ricezione (classici e post-quantum), come e quando hai verificato il contatto, e note in formato libero.

Non sono Identity Seed, ma l'elenco di chi sono i tuoi corrispondenti può rivelare relazioni e flussi di lavoro. Il logging di CardanoWall è scritto in modo da tenere tutto questo riservato: le azioni lato server che creano e modificano i contatti registrano solo un identificativo di richiesta e l'identificativo del tuo account — mai il nome del contatto, le chiavi, le note o il metodo di verifica.

Cosa CardanoWall non promette?

Non promette l'invisibilità.

CardanoWall non è una rete di anonimato. La blockchain, i gateway di storage, il sistema di pagamento, il login del tuo account, il tuo browser e il tuo percorso di rete possono tutti esporre metadati. Pubblicare un record sigillato non firmato tiene fuori dal record Label 309 stesso il mittente, i destinatari e il contenuto in chiaro — ma questa è privacy a livello di record, non anonimato completo. L'indirizzo Cardano che paga la fee, il tuo IP così come lo vedono i gateway e segnali simili vivono fuori dal record e fuori da questa garanzia.

Non rende nemmeno sicuro un dispositivo compromesso. Se la tua sessione sbloccata sta eseguendo codice malevolo, quel codice può vedere ciò che vedi tu.

E una prova pubblicata è pubblica per progettazione. Dimostra che byte specifici esistevano entro un momento pubblico specifico. Non dimostra, da sola, chi li ha scritti, chi li possiede o che il loro contenuto sia vero — vedi cosa una prova non dimostra per questo confine.

La versione breve

CardanoWall può vedere i dati di servizio e i dati di prova pubblici. Per progettazione non vede in chiaro il tuo Identity Seed, le tue chiavi private, il testo in chiaro del tuo vault o il contenuto in chiaro di un file sigillato.

Quindi, in pratica: sigilla i file sensibili prima che lascino il tuo dispositivo, conserva una copia sicura del tuo seed, sblocca su dispositivi di cui ti fidi e tratta come permanentemente pubblico tutto ciò che pubblichi sulla catena.

Una buona privacy parte dal sapere esattamente dove risiede ogni tipo di dato — e CardanoWall è costruito in modo che i dati che contano di più risiedano con te.

Per approfondire

CardanoWall è l'implementazione di riferimento di Label 309, uno standard di Proof-of-Existence aperto e neutrale rispetto al fornitore. Lo standard è stato sottoposto al processo CIP di Cardano ed è in fase di revisione da parte degli editor CIP come proposta di categoria Metadata (PR aperta). Il core crittografico, gli SDK e gli strumenti da riga di comando sono open source su github.com/cardanowall, così puoi verificare con un audit esattamente cosa viene calcolato sul tuo dispositivo, invece di crederci sulla parola.