Fråga inte bara ”är samtalet krypterat?”; fråga var krypteringen upphör och vad inspelning förändrar.
Att chatten är krypterad bevisar inte i sig att ljud, video, skärmdelning eller samtalsinspelningar har samma skydd. För att bedöma ett samtal behöver du fråga hur långt medieinnehållet förblir krypterat, vem som har nyckeln och vad som förändras när funktioner som inspelning aktiveras.
Den här guiden delar upp säkerhetspåståenden i lager som går att granska; namnet på ett protokoll eller en hänglåsikon ersätter inte svaren på dessa frågor.
Tre olika vägar i en och samma app
| Väg | Exempel på data | Säkerhetsfråga |
|---|---|---|
| Lagrade meddelanden | Text, bilder, filer och röstmeddelanden | Vem kan läsa kopiorna på enheten, på servern och i säkerhetskopian? |
| Direktsänt medieinnehåll | Mikrofonljud, video och skärmdelning | Upphör krypteringen på motpartens enhet eller på en mellanliggande server? |
| Signalering | Samtalsinbjudan, svar och information för att samordna anslutningen | Vem kan ändra kontrollmeddelanden eller mottagarens identitet? |
Ett röstmeddelande som skickas i chatten är en fil; ett röstsamtal är en direktsänd ström. En produkt kan använda olika nycklar och mekanismer för dessa två. Bra ljudkvalitet eller ett textmeddelande som inte kommer fram säger inte heller i sig något om säkerheten för den andra vägen.
Vad visar DTLS-SRTP?
I WebRTC skyddar SRTP medieströmmen, och DTLS-SRTP är ett sätt att upprätta det nyckelmaterial som behövs. RFC 5764 förklarar DTLS-SRTP-mekanismen, och RFC 3711 förklarar skyddet av mediepaket.
Men påståendet ”vi använder WebRTC” svarar inte i sig på om konferensservern dekrypterar medieinnehållet. Krypteringens ändpunkter och hur de autentiseras måste vara tydligt angivna. Förbindelsen mellan användaren och servern kan vara krypterad, samtidigt som servern har tillgång till dekrypterat innehåll för bearbetning eller inspelning. Det är inte samma sak som E2EE mellan deltagarna.
WebRTC:s säkerhetsarkitektur i RFC 8827 visar också att tilliten till webbappen, signaleringsvägen och motpartens identitet är viktiga vid sidan av skyddet för medieinnehållet. Krypterade paket innebär inte att alla delar av produkten är tillförlitliga.
Varför måste signalering bedömas separat?
Signaleringen samordnar vem som ringer vem och hur anslutningen upprättas. Om en app skyddar kontrollmeddelanden behöver man fortfarande granska hur skyddet kopplas till deltagarnas verkliga identiteter och till medienycklarna.
Tre frågor räcker som vägledning när du läser dokumentationen:
- Är inbjudan, svaret och nyckelinformationen skyddade mot ändringar?
- Hur vet användaren att nyckeln tillhör den avsedda motparten?
- Vilken varning visas när nyckeln eller enheten ändras?
Information om routning, tidpunkter och samtalsdeltagare kan vara känd för tjänsten även vid ett E2EE-samtal. Förklaringen av metadata i meddelandetjänster tar upp den skillnaden.
Samtalsinspelning skapar en ny säkerhetsgräns
”Krypterat samtal” ger inget fullständigt svar om den inspelade versionen. En deltagare kan spela in ljud eller video med sin egen enhet. Inspelning på serversidan måste också dokumenteras separat: får servern tillgång till medieinnehåll i klartext för att spela in? Vem lagrar filen? När raderas den?
Om aktivering av inspelning ändrar säkerhetsläget måste förändringen vara tydlig för deltagarna. Kontrollera inspelningsstatus och deltagarnas samtycke före ett känsligt samtal; att den inbyggda inspelningsindikatorn är avstängd garanterar inte att ingen spelar in med annan utrustning.
Hur ska man läsa Livaras aktuella dokumentation?
Livaras säkerhetssida beskriver direkta samtal och gruppsamtal som E2EE, men anger valfri inspelning på serversidan som ett undantag: i det synliga REC-läget ändras samtalsskyddet till transportkryptering. Det här är ett påstående i produktdokumentationen, inte ett resultat från ett oberoende test eller en oberoende säkerhetsgranskning i den här artikeln.
Begränsningen av alla gruppsamtal till ”2–6 personer på Android” i den gamla texten stämmer inte med den aktuella dokumentationen och ligger inte till grund för den här guiden. För den kapacitet, plattform och version som är aktuell behöver man granska den senaste vägledningen och appens faktiska beteende; den här artikeln innehåller inget kapacitetstest.
Namnet på chattalgoritmer som ML-KEM bevisar inte heller i sig att samma algoritm används för samtalets medieinnehåll. Ett påstående om postkvantskydd för samtal kräver specifika belägg för medievägen och autentiseringen. Läs Livaras hotmodell tillsammans med funktionssidan, inte som ersättning för ett oberoende test.
Kort checklista innan du jämför två tjänster
Anteckna även version och källa för varje ”ja”:
- Beskrivs samtal mellan två personer, gruppsamtal och skärmdelning separat?
- Framgår det om servern bara vidarebefordrar paket eller också kan dekryptera medieinnehållet?
- Går det att kontrollera deltagarens identitet och nyckel?
- Syns det när någon byter enhet, en deltagare läggs till eller inspelning aktiveras?
- Är samtalsvägen densamma på webben och i appen, eller finns det skillnader?
- Förklaras hur inspelade filer och metadata lagras?
- Gäller beläggen från tester eller säkerhetsgranskningar samma version och funktion?
Om svaret saknas i dokumentationen, skriv ”okänt”; ett uteblivet svar bevisar varken säkerhet eller avlyssning.
Vanliga frågor
Hindrar ett E2EE-samtal motparten från att spela in?
Nej. Den behöriga mottagaren har tillgång till innehållet i klartext och kan spela in det med programvara eller en annan enhet.
Är transportkryptering dåligt?
Transportkryptering ger ett viktigt skydd mot avlyssning längs överföringsvägen. Skillnaden är att tjänsten som utgör ändpunkten kan ha tillgång till det dekrypterade innehållet; det ska inte kallas E2EE mellan användare.
Gör postkvantkryptering i chatten även samtalen postkvantsäkra?
Nej. Påståendet måste gälla samma lager, algoritmer och implementationsversion. Bedöm chatt och samtal separat.
