Recuperare un account, un’identità e una cronologia delle conversazioni sono operazioni diverse; verifica quale sia effettivamente supportata dal prodotto.
Il recupero dell’identità crittografica ripristina il materiale delle chiavi associato alla tua identità di messaggistica. Non equivale automaticamente ad accedere di nuovo a un account, ripristinare tutte le conversazioni o dimostrare che un dispositivo sostitutivo sia sicuro.
Un backup cifrato delle chiavi può consentire a un server di conservare un pacchetto recuperabile senza possedere il segreto necessario per aprirlo. Che questo progetto protegga l’utente dipende dalla generazione delle chiavi, dall’autenticazione, dalla custodia del segreto di recupero e dal modo in cui il client gestisce l’identità recuperata.
Tre cose che vengono chiamate «recupero»
| Obiettivo del recupero | Cosa deve essere ripristinato o autorizzato |
|---|---|
| Accesso all’account | Autorizzazione ad accedere e utilizzare il servizio |
| Identità crittografica | Le chiavi private appropriate o una nuova identità autenticata |
| Cronologia delle chat | I dati dei messaggi e tutte le chiavi o lo stato necessari per leggerli |
Un accesso riuscito non dimostra nessuno degli altri due risultati. Analogamente, una chiave d’identità non ricrea necessariamente vecchie chiavi dei messaggi eliminate intenzionalmente o un file di cronologia che non esiste più.
Annota quale obiettivo promette realmente la funzione di recupero di un prodotto prima di farvi affidamento.
Come può funzionare un backup cifrato dell’identità
Un progetto tipico genera il materiale d’identità su un dispositivo fidato, cifra un backup con un segreto di recupero separato e conserva presso il servizio soltanto il pacchetto protetto. Un dispositivo sostitutivo recupera il pacchetto e usa localmente il segreto di recupero.
Il server può comunque controllare l’accesso al pacchetto, osservare le richieste, trattenere i dati o restituire una versione precedente. La cifratura autenticata e il legame con versione e identità aiutano ad affrontare specifici rischi di manomissione; disponibilità e gestione dei ripristini a versioni precedenti richiedono una progettazione propria. «Cifrato sul server» non è una risposta completa a ogni scenario di compromissione del server.
Anche una chiave di recupero casuale ad alta entropia e una password scelta da una persona sono input diversi. Non descrivere HKDF come un metodo che trasforma qualsiasi passphrase debole in un segreto robusto. RFC 5869 illustra il ruolo di HKDF e lo distingue dal password stretching.
Cosa dice la documentazione v7 di Livara
La pagina sulla sicurezza di Livara afferma che le sue chiavi P-256 per accordo di chiavi e firma e il seed ML-KEM vengono cifrati sul dispositivo con una chiave di recupero casuale a 256 bit prima del caricamento. Il formato v7 autentica informazioni tra cui la suite, l’epoca dell’identità e la generazione.
La stessa pagina è esplicita: ripristina l’identità, non la cronologia delle chat. Afferma inoltre che una password di accesso corretta, da sola, non basta per aprire il backup cifrato delle chiavi; serve la chiave di recupero rappresentata dalla frase di recupero.
Queste sono dichiarazioni pubblicate sul prodotto, non una nuova verifica del formato di backup o di ogni percorso di recupero. Il modello di minaccia, più generale, va letto insieme a questa descrizione più circoscritta del recupero.
Dove si inserisce SRP
Il modello di autenticazione SRP riguarda l’accesso basato su password. Può evitare la trasmissione della password stessa nello scambio previsto dal protocollo, ma non definisce il contenuto di un backup delle chiavi né deriva automaticamente ogni chiave di recupero.
Il suo verificatore lato server deve comunque essere protetto. RFC 5054, sezione 3.3 descrive il rischio di indovinare le password dopo il furto di un verificatore. Non trasformare «il server non riceve la password in questo scambio» in «una violazione del server non può esporre nulla di utile».
Sessioni dell’account, pacchetti di recupero, metadati operativi e software client sono risorse distinte con modalità di guasto distinte.
Lista di preparazione per un recupero sicuro
- Conferma esattamente quali dati vengono ripristinati dalla funzione e quali no.
- Conserva il segreto di recupero dove perdere il telefono non significhi perdere anche l’unica copia.
- Evita di inserire il segreto in un messaggio, una richiesta di assistenza o uno screenshot pubblico.
- Proteggi il luogo in cui è conservato il segreto; chiunque lo ottenga può acquisire capacità importanti se ottiene anche il backup pertinente e l’accesso necessario.
- Consulta le istruzioni ufficiali di recupero prima di cancellare o sostituire l’unico dispositivo funzionante.
- Esegui prove soltanto mediante procedure supportate, senza distruggere l’unica copia di dati importanti.
Dopo il recupero, controlla separatamente i dispositivi collegati e le sessioni. Il materiale d’identità recuperato non revoca automaticamente un vecchio dispositivo. Se l’identità crittografica cambia, i contatti con cui scambi informazioni sensibili dovrebbero verificare la nuova chiave attraverso un percorso fidato indipendente.
Se si perde la frase di recupero
Non presumere che l’assistenza possa ricreare un segreto che il sistema è stato progettato per non conservare. Allo stesso modo, non presumere che ogni password di account dimenticata significhi che tutti i messaggi locali siano già scomparsi. Gli esiti dipendono dai dispositivi rimasti, dai backup disponibili e dalle regole documentate del prodotto.
La domanda utile è specifica: «Quale segreto o copia manca, e quale obiettivo di recupero resta possibile?». Produce una risposta più sicura rispetto alla promessa generica che il recupero sia semplice oppure impossibile.
