Att återställa ett konto, en identitet och en konversationshistorik är olika åtgärder; kontrollera vilken av dem produkten faktiskt stöder.
Återställning av kryptografisk identitet återställer nyckelmaterial som hör till din identitet i meddelandetjänsten. Det är inte automatiskt samma sak som att logga in på ett konto igen, återställa alla konversationer eller bevisa att en ersättningsenhet är säker.
En krypterad säkerhetskopia av nycklar kan låta en server lagra ett återställningsbart paket utan att ha hemligheten som behövs för att öppna det. Om den konstruktionen skyddar användaren beror på nyckelgenerering, autentisering, förvaring av återställningshemligheten och hur klienten hanterar den återställda identiteten.
Tre saker som kallas ”återställning”
| Återställningsmål | Vad som måste återställas eller godkännas |
|---|---|
| Kontoåtkomst | Behörighet att logga in och använda tjänsten |
| Kryptografisk identitet | Lämpliga privata nycklar eller en ny autentiserad identitet |
| Chatthistorik | Meddelandedata och de nycklar eller tillstånd som krävs för att läsa dem |
En lyckad inloggning bevisar inget av de andra två. På samma sätt återskapar en identitetsnyckel inte nödvändigtvis gamla meddelandenycklar som avsiktligt raderats, eller en historikfil som inte längre finns.
Skriv ned vilket mål produktens återställningsfunktion faktiskt utlovar innan du förlitar dig på den.
Så kan en krypterad identitetskopia fungera
En typisk konstruktion skapar identitetsmaterial på en betrodd enhet, krypterar en säkerhetskopia med en separat återställningshemlighet och lagrar endast det skyddade paketet hos tjänsten. En ersättningsenhet hämtar paketet och använder återställningshemligheten lokalt.
Servern kan fortfarande styra åtkomsten till paketet, observera förfrågningar, hålla inne data eller lämna tillbaka en äldre version. Autentiserad kryptering och bindning till version och identitet hjälper mot vissa manipuleringsrisker; tillgänglighet och hantering av återställning till äldre versioner kräver egna lösningar. ”Krypterat på servern” är inte ett fullständigt svar på alla scenarier där servern komprometteras.
En slumpmässig återställningsnyckel med hög entropi och ett lösenord valt av en människa är också olika indata. Beskriv inte HKDF som en metod som gör vilken svag lösenfras som helst till en stark hemlighet. RFC 5869 beskriver HKDF:s roll och skiljer den från lösenordsförstärkning genom ökad beräkningskostnad.
Vad Livaras v7-dokumentation säger
Livaras säkerhetssida säger att dess P-256-nycklar för nyckelöverenskommelse och signering samt ML-KEM-frö krypteras på enheten med en slumpmässig 256-bitars återställningsnyckel före uppladdning. v7-formatet autentiserar bland annat algoritmsviten, identitetsepoken och generationen.
Samma sida är tydlig: det återställer identiteten, inte chatthistoriken. Den säger också att ett korrekt inloggningslösenord ensamt inte räcker för att öppna den krypterade nyckelkopian; återställningsnyckeln som representeras av återställningsfrasen krävs.
Detta är publicerade produktpåståenden, inte en ny granskning av säkerhetskopians format eller alla återställningsvägar. Den mer allmänna hotmodellen bör läsas tillsammans med denna snävare beskrivning av återställning.
Var SRP passar in
SRP:s autentiseringsmodell gäller lösenordsbaserad inloggning. Den kan undvika att överföra själva lösenordet i det avsedda protokollutbytet, men definierar inte innehållet i en nyckelkopia och härleder inte automatiskt varje återställningsnyckel.
Dess verifierare på serversidan behöver fortfarande skyddas. RFC 5054, avsnitt 3.3 beskriver risken för lösenordsgissning efter att en verifierare har stulits. Gör inte om ”servern får inte lösenordet i detta utbyte” till ”ett serverintrång kan inte exponera något användbart”.
Kontosessioner, återställningspaket, operativa metadata och klientprogramvara är separata tillgångar med separata felmoder.
Checklista för säkra förberedelser inför återställning
- Bekräfta exakt vilka data funktionen återställer och vilka den inte återställer.
- Förvara återställningshemligheten så att en förlorad telefon inte också innebär att den enda kopian går förlorad.
- Undvik att lägga hemligheten i ett meddelande, ett supportärende eller en offentlig skärmbild.
- Skydda platsen där hemligheten lagras; den som får tag på den kan få viktiga möjligheter om personen också får den relevanta säkerhetskopian och åtkomsten.
- Läs de officiella återställningsanvisningarna innan du raderar eller ersätter den enda fungerande enheten.
- Testa bara med stödda förfaranden, utan att förstöra den enda kopian av viktiga data.
Efter återställningen ska länkade enheter och sessioner granskas separat. Återställt identitetsmaterial återkallar inte automatiskt en gammal enhet. Om den kryptografiska identiteten ändras bör kontakter som du utbyter känsliga uppgifter med verifiera den nya nyckeln via en oberoende betrodd väg.
Om återställningsfrasen går förlorad
Anta inte att supporten kan återskapa en hemlighet som systemet är konstruerat för att inte behålla. Anta inte heller att varje glömt kontolösenord betyder att alla lokala meddelanden redan är borta. Utfallet beror på kvarvarande enheter, tillgängliga säkerhetskopior och produktens dokumenterade regler.
Den användbara frågan är konkret: ”Vilken hemlighet eller kopia saknas, och vilket återställningsmål är fortfarande möjligt?”. Det ger ett säkrare svar än ett generellt löfte om att återställning antingen är enkel eller omöjlig.
