En diskkopia, direkt kontroll över servern och åtkomst till telefonen är tre olika scenarier; en allmän garanti räcker inte för alla tre.
Om en meddelandeserver tas över beror det exakta svaret på ”vad avslöjas?” på lagrade data, var nycklarna finns och vilken åtkomst angriparen har. Att få en kopia av disken är inte samma sak som att ha direkt kontroll över tjänsten och appens distributionsväg.
Artikeln undersöker ett hypotetiskt scenario med stöd i Livaras offentliga dokumentation. Den gör inga påståenden om var Livaras datacenter ligger, att ett beslag har skett eller att tjänsten garanterat fungerar under ett internetavbrott. Innehållskryptering, nätverkstillgänglighet och infrastruktursäkerhet är skilda frågor.
Fastställ först typen av åtkomst
Lagrad serverkopia: angriparen får tillgång till de filer, databaser eller säkerhetskopior som finns i kopian. Om privat innehåll har krypterats korrekt på enheten och servern inte har dekrypteringsnyckeln avslöjar innehavet av kopian i sig inte samtalstexten.
Aktiv kontroll över tjänsten: utöver att läsa befintliga data kan angriparen blockera vissa förfrågningar, returnera gamla data eller ändra beteendet hos kontrollerade delar. Kontroll av kontaktens identitet, versionskontroll och klientens integritet blir viktigare i detta scenario.
Samtidig åtkomst till enheten: en upplåst telefon, skadlig kod eller en läsbar kopia hos en samtalsdeltagare kan avslöja innehållet på en helt annan väg. Inte heller Livaras hotmodell garanterar skydd för en upplåst eller infekterad enhet.
Vilka data syns på servern enligt Livaras dokumentation?
Livaras säkerhetssida, märkt med version 0.1.68, skiljer innehållet i direkta chattar under LVR1 och kompatibla privata grupper under LGS1 från driftinformation. Samma sida säger uttryckligen att äldre inkompatibla grupper förblir utanför E2EE; därför måste statusen för det aktuella samtalet kontrolleras.
| Datakategori | Dokumenterad gräns och möjlig följd |
|---|---|
| Text och bilagor i ett skyddat samtal | Servern lagrar den krypterade kopian; läsning kräver rätt nyckel |
| Kommunikationsmetadata | Uppgifter som parter, tid, storlek och leveransstatus är tillgängliga för tjänsten |
| Gruppmedlemskap | Ingår i serverns driftinformation och operativa befogenheter |
| Offentlig kanal | Innehållet är offentligt och läsbart för servern |
| Paket för identitetsåterställning v7 | Krypteras före uppladdning och kräver en separat återställningshemlighet |
| Valfritt inspelningsläge på servern | Märkningen REC skiljer det från E2EE; integritet från ände till ände ska inte förutsättas |
Dokumentationen nämner LSS1-kod för metadataskydd, men den är inte kopplad till vanlig meddelandesändning. Att ett protokollnamn finns i projektet bevisar inte att protokollet används i all kommunikation.
Tabellen beskriver produktpåståenden, inte resultatet av ett verkligt beslagstest eller en oberoende granskning av alla databaskopior.
Hur viktiga kan metadata vara?
Information om kontakter mellan personer, tidpunkter och gruppmedlemskap kan vara känslig även utan meddelandetext. Men påståendet ”hela kommunikationsgrafen avslöjas för alltid” är inte precist utan kännedom om lagringstider, loggarnas täckning och vilken datakopia som har erhållits.
En verklig bedömning måste fråga vilka fält som samlats in, hur länge de sparats och vilka säkerhetskopior som är åtkomliga. Innehållskryptering bestämmer inte ensam policyn för datalagring. Man kan inte heller utifrån en meddelandetjänsts arkitektur dra slutsatsen att alla tjänster nödvändigtvis sparar samma metadata.
Vilken risk innebär serverkontroll för framtida meddelanden?
I en säkerhetsgranskning bör manipulation av medlemslistan, tillhandahållande av en annan identitetsnyckel, blockering av uppdateringar och leverans av en skadlig klient testas var för sig. Effekten beror på validering på klientsidan, hur förändringar visas och identitetsverifiering.
Utan implementationstester går det inte att säga att varje övertagen server säkert kan lägga till en dold medlem; lika lite går det att säga att aktiv serverkontroll inte har någon effekt. I känsliga samtal bör oväntade förändringar av identitet eller medlemmar undersökas. Att jämföra nyckelns fingeravtryck med kontakten via en oberoende, betrodd väg ger mer information än att enbart lita på visningsnamnet.
Om angriparen ändrar koden som körs på enheten kan texten bli synlig före kryptering. Därför ingår säker appdistribution och säkra uppdateringar i scenariot och är inte frågor utanför kryptografin.
Vad tillför postkvantskydd?
Standarden NIST FIPS 203 för ML-KEM hjälper till att etablera en delad hemlighet. Korrekt användning i en hybridkombination kan minska risken för vissa framtida angrepp mot nyckelutbytet. Detta ersätter inte enhetssäkerhet, begränsad metadatalagring eller serverns åtkomstkontroll.
Även Proof Lab visar endast vissa lokala P-256-, HKDF- och AES-GCM-operationer och undantar den fullständiga LVR1/LGS1-kombinationen från testet. Ett lyckat resultat garanterar inte att hela produkten står emot ett övertagande av infrastrukturen.
Vad ska vi göra vid en bedömning eller verklig incident?
- Dokumentera typen av åtkomst och bekräftade uppgifter; likställ inte ett rykte om driftstörningar med en fastställd säkerhetsincident.
- Kontrollera appversionen och krypteringsstatusen för det aktuella samtalet.
- Undersök identitetsförändringar, gruppmedlemmar och okända sessioner via officiella vägar.
- Lämna inte ut återställningshemligheten, lösenordet eller privat innehåll till okända för en ”säkerhetskontroll”.
- Vid allvarlig risk eller juridiska frågor, sök hjälp av en lämplig expert och vidta inte oåterkalleliga åtgärder utifrån en enda artikel.
En tillförlitlig slutsats måste ange vilka data som skyddas, i vilken version och mot vilken åtkomst. ”Ingenting händer ens om servern beslagtas” ersätter inte det svaret.
