Crittografia end-to-end, con le chiavi sui tuoi dispositivi

C’è un solo segreto alla radice del tuo account, e viene creato su un dispositivo — non emesso da un server. Tutto il resto ne deriva tramite un albero di chiavi: una radice HMAC-SHA-512, poi un passo HMAC per ogni elemento di percorso etichettato. La coppia di chiavi che apre le chiavi di sessione sigillate esce da quell’albero sotto l’etichetta "content", e così pure una chiave separata per ogni altro tipo di blob memorizzato, così nessuna chiave fa due lavori.

È per questo che un browser nuovo di zecca può accedere al tuo account e non mostrarti comunque nulla della settimana scorsa. Accedere dimostra al relay chi sei. Leggere una vecchia sessione richiede la chiave, e la chiave non è sul relay da inviare. Ripristinare il dispositivo è il passo che la sposta — da un dispositivo che la ha già, o dalla chiave segreta che hai conservato.

Significa anche che il caso di perdita è reale e vale la pena dirlo una volta: se tutti i dispositivi connessi sono spariti e con essi la chiave segreta, le sessioni crittografate non possono essere recuperate né da noi né da nessun altro. Un relay che potesse restituirle sarebbe un relay che potrebbe leggerle.

Aggiungere un dispositivo è il momento in cui si sposta il materiale delle chiavi, quindi è il momento che vale la pena capire. Scansionare il codice QR solleva una richiesta, e non fa altro: l’approvazione avviene su un dispositivo già connesso, e quando entrambi gli schermi mostrano un breve codice di conferma sei tenuto a confrontarli prima di approvare.

Quello che l’approvazione fa davvero è sigillare la chiave dei contenuti con la chiave pubblica del dispositivo che l’ha chiesta, in una busta che porta una chiave mittente effimera e un nonce nuovo. Quella busta attraversa il relay come tutto il resto. Collegare un terminale aggiunge un ulteriore vincolo: il payload è autenticato rispetto a un segreto di abbinamento che ha viaggiato nel codice QR, non attraverso il server, così un relay che sostituisse il payload non riuscirebbe a produrre un tag corrispondente.

Tutto quanto sopra descrive l’impostazione predefinita, e l’impostazione predefinita non è un suggerimento che il client possa far cambiare al server. Un relay appena installato è impostato per richiedere archiviazione crittografata end-to-end: una scrittura in chiaro viene rifiutata con un errore di policy anziché essere accettata in silenzio. I client leggono la policy dall’endpoint features del server prima di creare una sessione, quindi la modalità in cui si trova una sessione è stata concordata prima del suo primo messaggio.

Un operatore del server ha altre due impostazioni disponibili. Una può permettere a un account di scegliere, così sessioni crittografate e in chiaro coesistono sullo stesso relay — richiede sia la policy opzionale sia il permesso di opt-out, e quel permesso è disattivato a meno che l’operatore non lo attivi. L’altra richiede il testo in chiaro, per le organizzazioni che gestiscono la crittografia a livello di infrastruttura e hanno bisogno che il server possa leggere ed elaborare il contenuto delle sessioni. Quest’ultima è un compromesso reale e vale la pena dirlo senza addolcirlo: in una sessione in chiaro il server può leggere la trascrizione. È questo il senso dell’impostazione.

La modalità è fissata per sessione al momento della creazione, così una sessione non è mai metà dell’una e metà dell’altra, e cambiare la modalità di un account cambia cosa succede alle nuove sessioni anziché tornare indietro su quelle vecchie. Nulla viene decrittato retroattivamente, e nulla viene crittografato retroattivamente.

Le variabili che impostano tutti e tre, le opzioni a riposo che stanno sotto e i controlli di identità che le circondano sono la metà che riguarda l’operatore, e vivono su la pagina sul self-hosting per i team.

Una notifica push è l’unica cosa che esce dal modello, perché deve arrivare a un telefono che non ha nulla di aperto. La risposta di Happier è che a inviarle è il tuo stesso computer. Il server memorizza i tuoi token push; la CLI sul tuo computer li rilegge e invia la notifica da sé, il che tiene il relay fuori da un percorso in cui altrimenti dovrebbe conoscere i contenuti.

Quello che il payload trasporta è deliberatamente scarno: il tipo di strumento o di richiesta, e un breve indizio dove serve — un file come src/file.ts, il nome di un comando, un conteggio come “3 domande”. L’input grezzo degli strumenti non ci viene messo. Abbastanza per decidere se prendere in mano il telefono, su uno schermo che chiunque sia dietro di te può leggere.

Tutto questo vale anche su un relay che non gestisci tu. Il motivo per gestirne uno tuo è la riga qui sopra su identificatori e forma: la crittografia non nasconde chi parla con chi, né quanto spesso, e sul tuo relay anche quel registro è tuo. Un comando mette il relay su hardware che possiedi, e il percorso diventa il tuo dispositivo, il tuo relay, il tuo computer, senza nulla dentro che non abbia deployato tu.

Su questa pagina non c’è nessuna certificazione perché non ce n’è una da riportare, e una pagina sulla sicurezza che allude a una conformità che non ha è peggio di una che non la nomina affatto. Quello che c’è invece è il codice da cui è stata scritta ogni frase qui sopra, con licenza MIT e leggibile prima di eseguirlo: le primitive in packages/protocol/src/crypto, la crittografia di sessione in apps/cli/src/api/encryption.ts, la policy di archiviazione che il server applica nel suo endpoint features, e lo schema che mostra esattamente quali colonne sono in chiaro.

Questa è anche la risposta onesta a come dovresti trattare questa pagina: come una mappa di dove guardare, non come una promessa da prendere sulla fiducia. Leggi i quattro file, oppure esegui il relay tu stesso e leggi cosa dichiara ai suoi client.

Il riferimento sul modello di crittografia copre lo stesso terreno come procedura — cosa ti chiede il ripristino, cosa significa ogni modalità di archiviazione per un account, quale flusso usare quando un dispositivo non riesce ancora a leggere una sessione.