Het herstellen van een account, een identiteit en een gespreksgeschiedenis zijn verschillende handelingen; controleer welke het product daadwerkelijk ondersteunt.
Cryptografisch identiteitsherstel herstelt sleutelmateriaal dat bij je berichtenidentiteit hoort. Dat is niet automatisch hetzelfde als opnieuw inloggen op een account, alle gesprekken herstellen of bewijzen dat een vervangend apparaat veilig is.
Met een versleutelde sleutelback-up kan een server een herstelbaar pakket opslaan zonder het geheim te bezitten dat nodig is om het te openen. Of dat ontwerp de gebruiker beschermt, hangt af van sleutelgeneratie, authenticatie, de bewaring van het herstelgeheim en de manier waarop de client met de herstelde identiteit omgaat.
Drie dingen die mensen ‘herstel’ noemen
| Hersteldoel | Wat moet worden hersteld of toegestaan |
|---|---|
| Accounttoegang | Toestemming om in te loggen en de dienst te gebruiken |
| Cryptografische identiteit | De juiste privésleutels of een nieuwe geauthenticeerde identiteit |
| Chatgeschiedenis | Berichtgegevens en alle sleutels of toestand die nodig zijn om ze te lezen |
Een geslaagde aanmelding bewijst geen van de andere twee resultaten. Evenmin maakt een identiteitssleutel noodzakelijkerwijs oude, bewust gewiste berichtsleutels opnieuw aan of een geschiedenisbestand dat niet meer bestaat.
Schrijf op welk doel de herstelfunctie van een product daadwerkelijk belooft voordat je erop vertrouwt.
Hoe een versleutelde identiteitsback-up kan werken
Een gebruikelijk ontwerp genereert identiteitsmateriaal op een vertrouwd apparaat, versleutelt een back-up met een afzonderlijk herstelgeheim en slaat alleen het beschermde pakket bij de dienst op. Een vervangend apparaat haalt het pakket op en gebruikt het herstelgeheim lokaal.
De server kan nog steeds de toegang tot het pakket regelen, verzoeken observeren, gegevens achterhouden of een oudere versie teruggeven. Geauthenticeerde versleuteling en binding aan versie en identiteit helpen tegen specifieke manipulatierisico’s; beschikbaarheid en het omgaan met terugzetten naar oudere versies vereisen een eigen ontwerp. ‘Versleuteld op de server’ is geen volledig antwoord op elk scenario waarin een server wordt gecompromitteerd.
Een willekeurige herstelsleutel met hoge entropie en een door een mens gekozen wachtwoord zijn ook verschillende invoerwaarden. Beschrijf HKDF niet als een methode die iedere zwakke wachtwoordzin in een sterk geheim verandert. RFC 5869 bespreekt de rol van HKDF en onderscheidt die van wachtwoord-stretching.
Wat de v7-documentatie van Livara zegt
Volgens de beveiligingspagina van Livara worden de P-256-sleutels voor sleutelovereenkomst en ondertekening en de ML-KEM-seed vóór het uploaden op het apparaat versleuteld met een willekeurige herstelsleutel van 256 bits. Het v7-formaat authenticeert informatie waaronder de suite, de identiteitsepoch en de generatie.
Dezelfde pagina is expliciet: het herstelt de identiteit, niet de chatgeschiedenis. Er staat ook dat een correct inlogwachtwoord alleen onvoldoende is om de versleutelde sleutelback-up te openen; de herstelsleutel die door de herstelzin wordt weergegeven, is vereist.
Dit zijn gepubliceerde productclaims, geen nieuwe audit van het back-upformaat of iedere herstelroute. Het algemenere dreigingsmodel moet samen met deze specifiekere beschrijving van herstel worden gelezen.
Waar SRP past
Het SRP-authenticatiemodel gaat over inloggen met een wachtwoord. Het kan voorkomen dat het wachtwoord zelf wordt verstuurd in de bedoelde protocoluitwisseling, maar definieert niet de inhoud van een sleutelback-up en leidt niet automatisch iedere herstelsleutel af.
De verifier aan de serverzijde moet nog steeds worden beschermd. RFC 5054, paragraaf 3.3 beschrijft het risico van wachtwoordraden nadat een verifier is gestolen. Maak van ‘de server ontvangt het wachtwoord niet in deze uitwisseling’ niet ‘een serverinbraak kan niets bruikbaars blootleggen’.
Accountsessies, herstelpakketten, operationele metadata en clientsoftware zijn afzonderlijke te beschermen onderdelen met afzonderlijke faalwijzen.
Een checklist voor veilige herstelvoorbereiding
- Controleer precies welke gegevens de functie herstelt en welke niet.
- Bewaar het herstelgeheim waar verlies van de telefoon niet ook verlies van de enige kopie betekent.
- Zet het geheim niet in een bericht, supportticket of openbare schermafbeelding.
- Bescherm de plaats waar het geheim wordt bewaard; wie het bemachtigt, kan belangrijke mogelijkheden krijgen als diegene ook de relevante back-up en toegang verkrijgt.
- Lees de officiële herstelinstructies voordat je het enige werkende apparaat wist of vervangt.
- Test uitsluitend via ondersteunde procedures, zonder de enige kopie van belangrijke gegevens te vernietigen.
Controleer na herstel gekoppelde apparaten en sessies afzonderlijk. Hersteld identiteitsmateriaal trekt een oud apparaat niet automatisch in. Als de cryptografische identiteit verandert, moeten contacten met wie je gevoelige informatie uitwisselt de nieuwe sleutel verifiëren via een onafhankelijk vertrouwde route.
Als de herstelzin verloren is
Ga er niet van uit dat support een geheim kan reconstrueren dat het systeem bewust niet bewaart. Ga er evenmin van uit dat ieder vergeten accountwachtwoord betekent dat alle lokale berichten al verdwenen zijn. De uitkomst hangt af van overgebleven apparaten, beschikbare back-ups en de gedocumenteerde regels van het product.
De nuttige vraag is specifiek: ‘Welk geheim of welke kopie ontbreekt, en welk hersteldoel blijft mogelijk?’ Dat geeft een veiliger antwoord dan een algemene belofte dat herstel moeiteloos of onmogelijk is.
