Ett intrång i en meddelandeserver innebär inte nödvändigtvis att alla meddelanden blir lästa. Resultatet beror på lagrade data, var nycklarna finns och angriparens åtkomstnivå. Även när chatttexten är korrekt totalsträckskrypterad kan kontouppgifter, tidpunkter, gruppmedlemskap och leveransvägar vara känsliga.
För att bedöma en incident bör man först fråga vad angriparen fått tillgång till: en databaskopia, infrastrukturnycklar, en aktiv server eller systemet för programvarupublicering? Dessa scenarier har inte samma konsekvenser.
En stulen databas är inte samma sak som en kontrollerad server
En angripare som bara har en gammal databaskopia är begränsad till de uppgifter som registrerats där. Kontroll över den aktiva tjänsten kan göra det möjligt att registrera nya data, stjäla sessioner, ändra svar eller försöka byta ut en kontakts nyckel. Åtkomst till kedjan för programvarupublicering är en annan risk: skadlig kod på en ändpunkt kan se texten före kryptering eller efter dekryptering.
Påståendet «databasen saknar nyckeln till meddelandetexten» är därför viktigt, men inget fullständigt svar på alla typer av intrång.
Jämförelse av fem arkitekturmönster
Detta är pedagogiska mönster, inte en rangordning av fem produkter. En tjänst kan ha flera mönster för olika funktioner.
| Mönster | Data som är tillgängliga från databasen | Viktig gräns |
|---|---|---|
| Meddelanden och lösenord i klartext | Innehåll och inloggningsuppgifter är direkt läsbara | Lämpligt skydd saknas för båda datatyperna |
| Hashade lösenord, meddelanden i klartext | Innehållet är läsbart; lösenordsgissningar kan eventuellt testas | Kvaliteten på lösenordslagringen skyddar inte chatttexten |
| Innehåll krypterat med serverns nyckel | Chiffertext; läsning beror på åtkomst till nyckeln | Verklig separation mellan nyckel och data är viktig |
| E2EE-chatt med en säkerhetskopia som leverantören kan komma åt | Den pågående chatten kan vara skyddad, men historikkopian har en separat exponeringsväg | Säkerhetskopians policy och nyckel måste granskas |
| E2EE-chatt med krypterad återställning och oberoende nyckel | Chiffertext och driftdata; innehållsskyddet beror på konstruktion och nyckelskydd | Enheten, återställningsfrasen och autentisering av kontakter är fortfarande viktiga |
Kryptering av serverdisken hjälper mot stöld av en rå disk. När angriparen även har den aktiva tjänsten eller dekrypteringsnyckeln bör man inte förutsätta samma skydd. Målet med E2EE är att den förmedlande tjänsten inte ska ha den nyckel som krävs för att läsa skyddat innehåll.
Vad avslöjar metadata?
Metadata kan visa vilka konton som har kommunicerat, när de varit aktiva, vilka grupper de tillhör och hur mycket data som överförts. Det är inte meddelandetexten, men uppgifterna är värdefulla för att förstå kontaktnätverk eller aktivitetsmönster.
Livaras säkerhetssida beskriver uttryckligen lagring och behandling av driftdata, bland annat routning, medlemskap, tidpunkter, chiffertextens storlek och leveransstatus. Sekretess för privat innehåll får inte tolkas som fullständig anonymitet eller avsaknad av alla data på servern.
SRP tar inte bort risken för lösenordsgissning från kontodata
SRP är en metod för att bevisa kännedom om ett lösenord utan att skicka själva lösenordet direkt. Servern lagrar fortfarande verifieringsdata, en så kallad verifier. Säkerhetsavsnittet i RFC 5054 förklarar att stöld av en verifier kan möjliggöra en ordboksattack för att gissa lösenordet.
«Lösenordet skickas inte över nätverket» skiljer sig alltså från «det finns inga lösenordsrelaterade data att stjäla». Ett unikt och starkt lösenord, skydd av enheten och lämplig incidenthantering behövs fortfarande. SRP ersätter inte heller innehållskryptering eller skydd av inloggningssessioner.
Vilka gränser anger Livara?
Livaras säkerhetsdokumentation beskriver LVR1 för direktmeddelanden och LGS1 för skyddade grupper. Gruppskyddet beror på gruppens faktiska status; en äldre inkompatibel grupp ska inte märkas som E2EE. Offentliga kanaler ligger utanför denna sekretessgräns.
Samma dokument beskriver v7-återställning som ett krypterat identitetspaket som skyddas före uppladdning. Processen återställer den kryptografiska identiteten, inte chatthistoriken. Att återställningsfrasen eller enheten med nycklarna exponeras är ett annat scenario än enbart databasstöld.
Detta är publicerade produktbeskrivningar, inte resultat från en oberoende revision i denna artikel. Att nämna AES eller ML-KEM bevisar inte heller i sig att nyckelhanteringen och appens implementation är korrekta.
Vilka frågor bör man ställa när en incident meddelas?
- Vilken tidsperiod och vilka system berördes? Den vaga formuleringen «användaruppgifter» räcker inte.
- Var klartext, filer, nycklar, verifier, inloggningssessioner eller bara chiffertext tillgängliga?
- Kunde angriparen ändra tjänsten eller den programvara som levererades till användarna?
- Vilka åtgärder behövs via officiella kanaler: avsluta sessioner, byta lösenord, uppdatera eller kontrollera en kontakts identitet?
- Kan återställningsrådet radera lokal historik? Läs begränsningarna innan du tar bort appen.
Använd inte en länk från ett anonymt meddelande för att «omedelbart verifiera kontot». Öppna meddelandet själv via den officiella adressen. Livaras hotmodell hjälper till att förstå allmänna gränser; omfattningen av en verklig incident måste fastställas med bevis från just den incidenten.
