Che cosa può vedere e che cosa no il relay di SSP

SSP è un portafoglio a due dispositivi. L’estensione del browser custodisce una chiave, il telefono l’altra, e nessuno dei due può muovere fondi da solo. Ma quei due dispositivi devono parlarsi, e lo fanno attraverso un server che gestiamo noi e che chiamiamo relay.

Quel server è il posto ovvio in cui porre una domanda scomoda: se tutto passa per un’infrastruttura gestita dall’azienda del portafoglio, che cosa vede esattamente quell’azienda?

È una domanda legittima e merita una risposta precisa anziché rassicurante. Ecco dunque che cosa c’è davvero nel codice.

Il relay non può firmare nulla

Partiamo dalla parte che conta di più.

Il relay non riceve mai una chiave privata. Né cifrata, né divisa, in nessuna forma. La chiave del portafoglio resta nell’estensione del browser e quella dell’app resta sul telefono; le uniche cose che attraversano la rete sono chiavi pubbliche, dati non firmati e firme già prodotte sui tuoi dispositivi.

Non è un impegno di policy, è un impegno strutturale. Il multifirma due-di-due richiede entrambe le firme per muovere fondi, e il relay non possiede nessuna delle due chiavi. Un relay del tutto malevolo — il nostro, compromesso, o sostituito da un attaccante — resta incapace di produrre una transazione valida, perché produrne una richiede segreti che non gli sono mai stati inviati.

Questa è la garanzia. Tutto ciò che segue riguarda ciò che il relay maneggia davvero: un insieme più ristretto ma realmente non vuoto.

Che cosa transita, e per quanto

Il relay conserva quattro tipi di record. Due si cancellano da soli.

Dati di sincronizzazione, quando accoppi i due dispositivi. Portano la catena, la tua identità di portafoglio, la chiave pubblica estesa dell’app, l’identità WK risultante, i nonce pubblici, l’indirizzo generato e lo xpub di recupero con la sua firma.

Dati di azione, quando stai firmando qualcosa. Portano la catena, il percorso di derivazione, la tua identità WK, il tipo di azione, il carico utile stesso e gli UTXO pertinenti.

Entrambe le raccolte hanno in MongoDB un indice TTL impostato a expireAfterSeconds: 900. Quindici minuti. Il database cancella il record comunque vadano le cose: non è un lavoro di pulizia che qualcuno deve ricordarsi di lanciare, né una promessa in un’informativa sulla riservatezza. È un indice, imposto dal database stesso.

Token di notifica push, perché il telefono possa essere svegliato quando c’è qualcosa da approvare. Questi restano, perché un token che scadesse ogni quindici minuti sarebbe inutile.

Lo xpub di recupero, uno per identità, senza alcuna scadenza. È voluto e il codice lo dice: esiste perché il portafoglio possa recuperarlo quando gli serve, e non soltanto nei brevi momenti in cui entrambe le app sono sveglie.

La parte su cui dovremmo essere schietti

Guarda di nuovo quel carico di sincronizzazione. Contiene una chiave pubblica estesa.

Uno xpub non è una chiave di spesa e non può autorizzare una transazione. Ma non è nulla di trascurabile. Da uno xpub di conto si può derivare ogni indirizzo che quel conto userà mai, il che significa che chi lo possiede può osservare l’intero saldo e la cronologia delle transazioni su quella catena. È accesso in lettura alla tua vita finanziaria su quel conto — proprio il collegamento che la riservatezza on-chain consiste nell’evitare.

Il carico di azione è altrettanto concreto. Mentre firmi, il relay maneggia la transazione non firmata: dove vanno i soldi, quanti, e da quali uscite.

Dunque il riassunto onesto non è «il relay non vede nulla». È:

Il relay non può spendere il tuo denaro, e per quindici minuti alla volta può vedere che cosa ne stai facendo.

La finestra di quindici minuti è la mitigazione, ed è significativa: limita quanta cronologia possa accumularsi in un solo posto. Ma dentro quella finestra i dati ci sono, e preferiamo dirlo chiaramente piuttosto che lasciare che «non custodiale» svolga un lavoro retorico che non si è guadagnato.

Il principio di progetto che vale la pena prendere in prestito

C’è un commento nel servizio di recupero che cattura l’architettura meglio di qualsiasi diagramma:

il portafoglio verifica quella firma contro la chiave pubblica di identità che deriva da sé, quindi questo archivio non è considerato affidabile.

Lo xpub di recupero è conservato insieme a una firma staccata che SSP Key ha prodotto su di esso. Quando il portafoglio lo recupera, deriva in modo indipendente la chiave pubblica di identità e controlla la firma da sé. Se il relay restituisse uno xpub diverso — per compromissione, per un difetto o per sostituzione deliberata — la firma non verificherebbe e il portafoglio lo rifiuterebbe.

Il relay è trattato come un tubo non affidabile dal software che vi si appoggia. È il modo giusto di costruire su un’infrastruttura che gestisci tu, perché significa che un errore del tuo server non diventa un problema dei tuoi utenti. È anche lo schema da cercare nel valutare qualunque portafoglio: non «promettono di comportarsi bene?», ma «che succede se il loro server si comporta male?».

Che cosa potrebbe davvero fare un relay ostile

Conviene essere concreti sul modello di minaccia reale.

Potrebbe osservare. Entro la finestra TTL, il tuo xpub e la tua transazione in sospeso. È un’esposizione di riservatezza, non un rischio di furto.

Potrebbe censurare. Rifiutarsi di passare messaggi tra i tuoi dispositivi, il che ti impedirebbe di firmare nuove transazioni per la via consueta. Fastidioso e disturbante — e non è lo stesso che perdere qualcosa. Le tue chiavi restano tue, i tuoi fondi restano sulla catena, e i percorsi di recupero esistono proprio perché il relay potrebbe non esserci.

Potrebbe mentire, e per lo più fallire. Sostituire uno xpub di recupero viene sventato dal controllo di firma descritto sopra. Ecco perché quella verifica conta.

Non può firmare. Nessuna chiave, nessuna firma, nessuna transazione.

Il peggiore caso realistico è sorveglianza e disservizio, non perdita. È una posizione sensibilmente migliore di quella di un servizio custodiale, dove il peggiore caso equivalente è che i soldi non ci sono più. Non equivale a «nessuno può vedere nulla», e confondere le due cose è il modo in cui ci si ritrova con un quadro falso della propria riservatezza.

Che cosa puoi fare sulle parti visibili

Capisci che cosa espone l’accoppiamento. Sincronizzare una catena significa che uno xpub di quella catena transita per il relay. È il costo perché il progetto a due dispositivi funzioni.

Ricorda che la finestra è breve, non nulla. Quindici minuti per azione sono un limite, non un’assenza.

Tratta lo xpub di recupero come permanente. È conservato senza scadenza per scelta, ed è materiale di chiave pubblica con una firma verificabile allegata — ma è durevole, e conviene saperlo anziché scoprirlo.

Giudica l’architettura, non la rassicurazione. La domanda utile sul server di un portafoglio non è se l’azienda prometta discrezione. È se il software si accorgerebbe che il server ha mentito. Il nostro controlla firme invece di fidarsi delle risposte, e puoi leggerlo nel codice invece di credere a noi.

La cosa che più vorremmo fosse compresa è la forma dello scambio. Un portafoglio a due dispositivi ha bisogno di un canale di coordinamento, e un canale di coordinamento è un luogo dove si accumulano metadati. L’abbiamo limitato con una scadenza imposta dal database e abbiamo progettato i client perché diffidino del server — ma la versione onesta è che il relay vede cose reali, per poco, e nessuna architettura accurata porta quel numero a zero.