End-to-endversleuteling vereist niet dat een berichtenapp centrale opslag vermijdt. Een server kan versleutelde berichten voor synchronisatie opslaan zonder te beschikken over de geheimen die nodig zijn om de inhoud te lezen.
Het lastige aan berichtenverkeer op meerdere apparaten is bepalen welke apparaten bevoegd zijn, welke sleutels ze krijgen en of ze toegang hebben tot oudere geschiedenis. Die beslissingen zijn belangrijker dan de vraag of het systeem een database gebruikt.
Vier afzonderlijke handelingen die vaak ‘synchronisatie’ worden genoemd
| Handeling | Wat deze moet bereiken |
|---|---|
| Nieuwe berichten afleveren | Beschermde inhoud bezorgen op apparaten die momenteel bevoegd zijn |
| Een nieuw apparaat koppelen | Vaststellen dat de accounteigenaar het nieuwe eindpunt goedkeurt |
| Geschiedenis overdragen | Het nieuwe apparaat toegang geven tot geselecteerde eerdere inhoud en het bijbehorende ontsleutelmateriaal |
| Identiteit herstellen | Identiteitssleutels herstellen of vervangen zonder noodzakelijk ook de berichtgeschiedenis te herstellen |
Een product kan één handeling ondersteunen zonder ze alle vier te ondersteunen. Succesvol aanmelden bewijst niet dat oude chatgeschiedenis kan worden hersteld.
Hoe versleutelde aflevering meerdere apparaten kan ondersteunen
Eén aanpak onderhoudt afzonderlijke sessies voor elk apparaat. De Sesame-specificatie van Signal beschrijft sessiebeheer in een asynchrone omgeving met meerdere apparaten, waaronder het toevoegen of verwijderen van apparaten en berichten die in de verkeerde volgorde aankomen.
Dat is een gedocumenteerd ontwerpvoorbeeld, geen universele eis. Andere systemen kunnen inhoud eenmaal versleutelen en beschermde inhoudssleutels verspreiden, groepsmechanismen gebruiken of benaderingen combineren. ‘E2EE vereist een volledige dubbele payload per apparaat’ is te algemeen.
Welk ontwerp ook wordt gekozen, een apparaat toevoegen dat kan ontsleutelen betekent een eindpunt toevoegen dat bescherming nodig heeft. Een verwaarloosde laptop kan de leesbare tekst die hij ontvangt blootstellen, ook als de server die tekst nooit ziet.
Opgeslagen cijfertekst heeft nog steeds gevolgen voor privacy en bewaring
Versleutelde opslag is niet hetzelfde als geen opslag. Aanbieders kunnen afleverinformatie, apparaatrecords, tijdstempels, lidmaatschappen of versleutelde berichtgeschiedenis bewaren. De details verschillen en moeten expliciet worden vermeld.
Volgens de beveiligingsdocumentatie van Livara slaat de relay cijfertekst en operationele gegevens op voor synchronisatie en herstel na opnieuw verbinden. De documentatie beschrijft routering, lidmaatschappen, tijdstempels, afleverstatus en andere records. Dit mag niet worden omschreven als een ongedocumenteerde tijdelijke wachtrij die noodzakelijk verdwijnt zodra elk apparaat een bericht ontvangt.
Vertrouwelijkheid van inhoud en bewaring van metadata vragen daarom om afzonderlijke vragen. Vraag wat wordt bewaard, hoelang en wat wissen of het verwijderen van een account verandert; verzin geen bewaartermijn als er geen is geverifieerd.
Wat Livara’s v7-herstel daadwerkelijk herstelt
Livara beschrijft v7 als een versleutelde identiteitsback-up, die vóór het uploaden wordt verzegeld met een willekeurige herstelsleutel van 256 bits. De gedocumenteerde payload bevat identiteitssleutelmateriaal, en het formaat authenticeert zijn suite, identiteitsepoch en generatie.
Dezelfde pagina vermeldt dat het de identiteit herstelt, niet de chatgeschiedenis. Een herstelzin mag daarom niet worden voorgesteld als garantie dat een nieuw apparaat elk oud gesprek kan weergeven.
Controleer voordat u een apparaat vervangt of wist welke huidige opties voor geschiedenisoverdracht en back-ups daadwerkelijk voor u beschikbaar zijn. Houd al het herstelmateriaal privé. Stuur geen herstelzin naar een supportaccount en plak deze niet op een niet-geverifieerde website.
Forward secrecy wist de inbox van een bevoegd apparaat niet
Een ratchet kan beperken wat een latere compromittering van sleutels onthult over eerder versleuteld verkeer, wanneer de aannames gelden en verouderde geheimen zijn verwijderd. Het kan geen leesbare tekst verbergen die een eindpunt al heeft opgeslagen, en evenmin voorkomen dat nog actieve malware nieuwe berichten leest.
Ook beveiliging na compromittering vereist een geschikte verse update nadat de aanvaller de toegang heeft verloren. Het is geen belofte dat elke oude tablet onschadelijk wordt telkens wanneer een berichtenteller verdergaat.
Een veiligere checklist voor het wisselen van apparaat
- Inventariseer uw gekoppelde apparaten voordat u er nog een toevoegt.
- Gebruik het gedocumenteerde koppelings- en verificatieproces van de applicatie, niet een QR-code van een onbekende.
- Controleer met een onschuldig testgesprek welke geschiedenis het nieuwe apparaat ontvangt.
- Bevestig het herstelmateriaal en eventuele afzonderlijke back-ups van de geschiedenis voordat u het oude apparaat wist.
- Trek de toegang in van apparaten die u niet meer beheert en controleer of gesprekspartners een melding van de identiteitswijziging krijgen.
- Bekijk lokale downloads, meldingen en back-ups van het besturingssysteem op elk eindpunt.
Het dreigingsmodel van Livara omvat expliciet de beperkingen van eindpunten en ontvangers. Die beperkingen blijven op elk scherm relevant. Een nuttige belofte voor meerdere apparaten legt apparaatautorisatie, opgeslagen gegevens en de reikwijdte van herstel afzonderlijk uit.
