Meddelandeintegritet: kan servern ändra en krypterad chatt?

En meddelandeapp kan ha funktioner för redigering och radering, men i ett system med autentiserad kryptering ska servern inte kunna ändra chiffertexten i smyg och ändå leverera ett giltigt meddelande. Meddelandeintegritet i en meddelandeapp innebär att mottagaren kan upptäcka att data har ändrats efter krypteringen; det är inte samma sak som att bevara fullständig historik eller juridiskt bevisa en konversation.

Viktiga punkter

• Autentiserad kryptering avslöjar manipulation av chiffertext, men bevarar inte nödvändigtvis historiken över redigeringar och raderingar.
• Enligt Livaras tekniska dokumentation skyddar AES-256-GCM privata meddelanden med en autentiseringstagg; ett manipulerat paket ska inte dekrypteras som giltigt.
• En tillåten redigering ska vara en ny ändpunktskrypterad händelse, inte serverns hemliga överskrivning av det gamla paketet.
• Säkerhetsnummer hjälper till att kontrollera motpartens nyckel, inte personens ärlighet eller en skärmbilds juridiska giltighet.
• Vid känsliga tvister bör du även utanför samtalstråden bevara originalfilen, tider, redigeringsstatus och oberoende bevis.

Vad är meddelandeintegritet egentligen?

Meddelandeintegritet innebär att mottagaren kan upptäcka otillåtna ändringar i krypterade data. Konfidentialitet frågar ”Vem kan läsa texten?”; integritet frågar ”Kom samma data fram som avsändaren krypterade?”. Förklaringen av ändpunktskryptering och dess gränser beskriver skillnaden närmare.

Detta är en konceptbild med illustrativa etiketter, inte Livaras faktiska gränssnitt eller resultatet av ett test där ett manipulerat meddelande avvisats.

Enligt Livaras tekniska dokumentation ändpunktskrypteras direktmeddelanden med LVR1 och kompatibla privata grupper med LGS1. Enligt Livaras säkerhetssida förblir äldre inkompatibla grupper tydligt utanför E2EE, och en ny grupp skapas inte med krypteringsetiketten förrän alla medlemmar är redo. Kontrollera statusen för just den konversationen. Dokumenten anger att LVR1 använder ECDH P-256 och ML-KEM-768 för att härleda meddelandenycklar. Att en komponent är standardiserad innebär inte ett oberoende godkännande av hela kombinationen eller produkten. Livara använder sedan AES-256-GCM för att skydda innehållet.

Enligt produktdokumentationen omfattar skyddet text, redigeringar och bilagor i privata samtal. Livaras kanaler är däremot inte ändpunktskrypterade: servern kan avsiktligt läsa deras innehåll, bland annat för att ta bort missbruksmaterial. Även gruppmedlemskap styrs av servern. Säkerheten för samtal och inspelningsläge måste bedömas separat från textmeddelanden.

Upptäcka manipulation och AES-256-GCM-kryptering i meddelandeappar

Utöver att kryptera innehållet skapar AES-GCM en autentiseringstagg. Om chiffertexten eller autentiserade data ändras ska taggkontrollen misslyckas. NIST SP 800-38D definierar GCM-läget och varnar för att återanvändning av en nonce med samma nyckel kan försvaga säkerheten kraftigt.

Enligt Livaras tekniska specifikationer använder privata meddelanden AES-256-GCM. Om servern ändrar en del av det skyddade paketet kan den inte skapa en ny autentiseringstagg utan meddelandenyckeln; mottagaren ska därför inte acceptera paketet som intakt. Det korta svaret på ”Kan servern ändra ett meddelande?” är att servern kan radera, hålla inne, blockera eller fördröja data, men inte ska kunna få manipulerat innehåll att framstå som giltigt.

Garantin är inte obegränsad. Kryptografi kan inte neutralisera skadlig kod på enheten, en angripares tillgång till en upplåst skärm eller en tillåten användarredigering. Innehållsintegritet döljer inte heller nödvändigtvis metadata. Guiden om meddelandemetadata och vad de avslöjar beskriver denna gräns.

Kan servern ändra ett meddelande, eller är redigering något annat?

Servern ska inte kunna skriva över det tidigare krypterade paketet i hemlighet, men den kan leverera en redigeringshändelse som avsändaren har skapat. Säker meddelanderedigering beror på att redigeringen autentiseras och ändpunktskrypteras precis som originalmeddelandet, i stället för att servern direkt ändrar den lagrade texten.

Enligt Livaras dokumentation skyddas redigering i direktchattar av LVR1 och i kompatibla privata grupper av LGS1. När du bedömer gränssnittet bör du kontrollera om appen visar ”redigerat”; kryptografi ensam bevarar dock inte den tidigare versionen för alltid på alla enheter.

”Radera för alla” är också en begäran om att kasta innehåll, inte ett bevis på att alla kopior förstörts. Mottagaren kan ha sett meddelandet, läst aviseringen, sparat filen eller tagit en skärmbild. Försvinnande meddelanden minskar varaktigheten men garanterar inte att alla kopior raderas.

Vad bevisar autentisering av chattmeddelanden?

Autentisering av chattmeddelanden visar att meddelandet skapades med sessionsnycklarna och inte manipulerades på vägen. Det bevisar inte att kontoinnehavaren personligen höll i enheten, att texten är sann eller att mottagaren senare kan bevisa den entydigt för en tredje part.

Livara beskriver säkerhetsnummer i sin tekniska dokumentation som ett sätt att upptäcka nyckeländringar. Två personer kan jämföra nyckelfingeravtryck via en oberoende kanal; guiden för chattkontroll med säkerhetsnummer beskriver de praktiska stegen. Kontrollens syfte är att minska risken för att kontaktens nyckel ersätts med en angripares, men den gör inte en infekterad enhet säker.

Kontoautentisering är också en separat fråga. Ingen inloggningsmekanism, hur stark den än är, ersätter meddelandeintegritet, kontroll av kontaktens nyckel eller enhetssäkerhet.

Innehållsintegritet är inte meddelandeordning eller färskhet

Ett gammalt paket kan ha en giltig autentiseringstagg. Att förhindra att det accepteras igen kräver protokolldesign, räknare, sessionsidentifierare och att mottagaren bevarar tillstånd; AES-GCM är inte ensamt en ordningslogg för hela konversationen. Skillnaden är viktig när återuppspelning, sena meddelanden och synkronisering mellan flera enheter bedöms.

Det måste också framgå vilka data som faktiskt omfattas av autentiseringstaggen. Om konversations-ID eller händelsetyp ligger utanför den autentiserade kontexten löser skydd av meddelandekroppen ensamt inte hela problemet. Kodgranskning och tester av just den versionen ska klargöra sambandet.

Om meddelandets text eller status är oväntad

Dokumentera appversion, observationstid, berörda enheter och om en redigeringsetikett finns. Kontrollera med kontakten via en oberoende kanal om en tillåten redigering gjordes. Tillskriv inte en synkroniseringsskillnad servermanipulation utan bevis; ignorera inte heller ett autentiseringsfel eller en nyckeländring utan skäl.

Använd ett okänsligt testmeddelande i en teknisk rapport och publicera inte kontaktens privata data i en offentlig rapport. Om konversationen ska användas i ett juridiskt ärende avgör inte kryptografi eller en skärmbild ensam dess juridiska giltighet; anlita en kvalificerad expert innan du ändrar bevismaterial.

Hur bedömer vi en meddelandeapps integritetsanspråk?

Nöj dig inte med ordet ”krypterat”. Fråga:

• Vilka samtal och filer ändpunktskrypteras?
• Vilken AEAD-algoritm använder tjänsten?
• Hur registreras och visas redigeringar och raderingar?
• Hur upptäcker användaren ändringar i kontaktens nyckel?
• Vilka metadata, vilket innehåll eller vilka medlemskap styr servern?
• Har samtal samma garantier som meddelanden?
• Har protokollet granskats oberoende?

Livara publicerar specifikationer och verktyg för att undersöka vissa av sina anspråk. Android-användare kan jämföra APK-filens kontrollsumma med SHA-256 i Proof Lab för offlinekontroll av appen. Den här artikeln lägger dock inte fram bevis för en oberoende granskning av den aktuella versionen. Publicerade specifikationer och testvektorer underlättar kontroll, men ersätter inte oberoende granskning.

För privata samtal är Livaras huvudanspråk begränsat och tydligt: AES-256-GCM ska avslöja paketmanipulation och redigeringar ska också krypteras. Det innebär inte en oföränderlig logg, garanterad radering av alla kopior eller automatiskt juridiskt bevis.

Vanliga frågor

Kan serveradministratören ändra texten i ett krypterat meddelande?

I en korrekt AES-256-GCM-design kan serveradministratören inte ändra chiffertexten och skapa en giltig autentiseringstagg utan meddelandenyckeln. Administratören kan fortfarande radera, blockera eller fördröja paketet. Garantin omfattar inte en infekterad enhet eller avsändarens tillåtna redigering.

Bevisar etiketten ”redigerat” vad den tidigare versionen var?

Nej. Etiketten säger bara att det visade innehållet ändrades efter sändningen, om inte appen också sparar versionshistorik. Kryptering kan kontrollera redigeringshändelsens autenticitet men bevarar inte den tidigare texten automatiskt.

Garanterar ett säkerhetsnummer alla meddelandens autenticitet?

Nej. Ett säkerhetsnummer hjälper till att kontrollera att krypteringsnyckeln hör till kontakten och att upptäcka ändringar. Det säger inte vem som höll enheten vid sändningen, om meddelandet är sant eller om enheten saknar skadlig kod.

Raderar ”radera för alla” meddelandet överallt?

Nej. Funktionen kan ta bort kopian i appen men återkallar inte en sparad fil, avisering, skärmbild eller tidigare registrering. Radera för alla minskar varaktigheten; det garanterar inte radering från mottagarens enhet eller andra system.