Ändpunktskryptering kräver inte att en meddelandetjänst undviker central lagring. En server kan lagra krypterade meddelanden för synkronisering utan att ha de hemligheter som behövs för att läsa innehållet.
Det svåra med meddelanden på flera enheter är att avgöra vilka enheter som är behöriga, vilka nycklar de får och om de kan få tillgång till äldre historik. Dessa beslut är viktigare än om systemet använder en databas.
Fyra skilda åtgärder som ofta kallas ”synkronisering”
| Åtgärd | Vad den behöver åstadkomma |
|---|---|
| Leverera nya meddelanden | Föra skyddat innehåll till enheter som för närvarande är behöriga |
| Länka en ny enhet | Fastställa att kontoägaren godkänner den nya ändpunkten |
| Överföra historik | Ge den nya enheten tillgång till utvalt tidigare innehåll och materialet för att dekryptera det |
| Återställa identitet | Återställa eller ersätta identitetsnycklar utan att nödvändigtvis återställa meddelandehistoriken |
En produkt kan stödja en åtgärd utan att stödja alla fyra. En lyckad inloggning bevisar inte att gammal chatthistorik går att återställa.
Hur krypterad leverans kan stödja flera enheter
En metod upprätthåller separata sessioner för varje enhet. Signals Sesame-specifikation beskriver sessionshantering i en asynkron miljö med flera enheter, inklusive enheter som läggs till eller tas bort och meddelanden som anländer i fel ordning.
Det är ett dokumenterat konstruktionsexempel, inte ett universellt krav. Andra system kan kryptera innehållet en gång och distribuera skyddade innehållsnycklar, använda gruppmekanismer eller kombinera olika metoder. ”E2EE kräver en fullständig kopia av nyttolasten per enhet” är ett alltför brett påstående.
Oavsett vilken konstruktion som väljs innebär en ny enhet med dekrypteringsförmåga ytterligare en ändpunkt som behöver skyddas. En försummad bärbar dator kan exponera klartext som den tar emot även om servern aldrig ser den klartexten.
Lagrad chiffertext har fortfarande konsekvenser för integritet och lagringstider
Krypterad lagring är inte detsamma som ingen lagring. Leverantörer kan behålla leveransinformation, enhetsregister, tidsstämplar, medlemskap eller krypterad meddelandehistorik. Detaljerna varierar och bör anges uttryckligen.
Livaras säkerhetsdokumentation säger att dess relä lagrar chiffertext och driftdata för synkronisering och återhämtning vid återanslutning. Den beskriver routning, medlemskap, tidsstämplar, leveransstatus och andra uppgifter. Detta bör inte beskrivas som en odokumenterad tillfällig kö som nödvändigtvis försvinner så snart alla enheter har fått ett meddelande.
Innehållets konfidentialitet och lagringen av metadata kräver därför separata frågor. Fråga vad som sparas, hur länge och vad radering eller borttagning av kontot förändrar; hitta inte på en lagringstid när ingen har verifierats.
Vad Livaras v7-återställning faktiskt återställer
Livara beskriver v7 som en krypterad identitetssäkerhetskopia, förseglad före uppladdning med en slumpmässig 256-bitars återställningsnyckel. Den dokumenterade nyttolasten innehåller identitetsnyckelmaterial, och formatet autentiserar sin kryptografiska svit, identitetsepok och generation.
Samma sida anger att den återställer identitet, inte chatthistorik. En återställningsfras bör därför inte framställas som en garanti för att en ny enhet kan visa varje gammal konversation.
Kontrollera vilka aktuella alternativ för historiköverföring och säkerhetskopiering som faktiskt finns tillgängliga för dig innan du ersätter eller raderar en enhet. Håll allt återställningsmaterial privat. Skicka inte en återställningsfras till ett supportkonto och klistra inte in den på en overifierad webbplats.
Framåtsekretess raderar inte en behörig enhets inkorg
En ratchet-mekanism kan begränsa vad ett senare nyckelintrång avslöjar om tidigare krypterad trafik när dess antaganden gäller och föråldrade hemligheter raderas. Den kan inte dölja klartext som en ändpunkt redan har lagrat eller hindra skadlig kod som förblir aktiv från att läsa nya meddelanden.
På samma sätt kräver säkerhet efter intrång en lämplig färsk uppdatering efter att angriparen har förlorat åtkomsten. Det är inget löfte om att vilken gammal surfplatta som helst blir ofarlig varje gång en meddelanderäknare ökar.
En checklista för säkrare enhetsbyte
- Inventera dina länkade enheter innan du lägger till ytterligare en.
- Använd appens dokumenterade flöde för länkning och verifiering, inte en QR-kod som en främling har skickat.
- Kontrollera vilken historik den nya enheten får med en ofarlig testkonversation.
- Bekräfta återställningsmaterialet och eventuell separat historiksäkerhetskopia innan du raderar den gamla enheten.
- Återkalla behörigheten för enheter du inte längre kontrollerar och kontrollera om samtalspartner får en avisering om identitetsändring.
- Granska lokala nedladdningar, aviseringar och operativsystemets säkerhetskopior på varje ändpunkt.
Livaras hotmodell omfattar uttryckligen ändpunkternas och mottagarnas begränsningar. De begränsningarna är relevanta på varje skärm. Ett användbart löfte om flera enheter förklarar enhetsbehörighet, lagrade data och återställningens omfattning var för sig.
