En nyckel för en viss fil innebär inte engångsvisning eller att mottagarens kopia kan återkallas.
För att skydda en bilaga kan en meddelandeapp kryptera filen på avsändarens enhet med en slumpmässig nyckel, ladda upp den krypterade versionen och skicka filnyckeln till mottagaren i ett totalsträckskrypterat meddelande. Detta mönster kallas ibland kuvertkryptering: den stora filen och den lilla mängd information som behövs för att öppna den följer olika men sammanhängande vägar.
Förklaringen gäller bilagor i samtal med E2EE; att skicka filer i vilken app eller kanaltyp som helst ger inte nödvändigtvis samma skydd.
En privat bilds väg från enheten till mottagaren
- Avsändarens enhet genererar en innehållsnyckel för filen.
- Filen krypteras med autentiserad kryptering; mottagaren måste kunna upptäcka obehöriga ändringar av data.
- Den krypterade versionen placeras på en fillagringstjänst.
- Filens adress eller identifierare och den nödvändiga nyckeln skickas till mottagaren i ett skyddat meddelande.
- Mottagarens enhet hämtar filen, validerar den och öppnar den sedan.
Livaras säkerhetsdokumentation beskriver en slumpmässig, filspecifik nyckel för bilagor och hur den överförs inom meddelandesessionen. Artikeln förklarar denna beskrivna arkitektur, inte resultatet av en granskning av implementationen.
En ”filspecifik nyckel” är inte samma sak som att ”filen bara kan öppnas en gång”
En nyckel som genereras för en fil kan behövas för att läsa samma fil flera gånger. Att nyckeln är filspecifik innebär inte att den kastas bort direkt efter första visningen, att filen raderas automatiskt eller att mottagaren hindras från att spara den.
En meddelandenyckel för engångsbruk och användning av en innehållsnyckel för en bilaga är också två skilda begrepp. Funktioner som Visa en gång eller försvinnande meddelanden kan inte härledas enbart ur algoritmens namn.
Varför är både nyckeln och nonce viktiga?
AES-GCM ger, utöver konfidentialitet, kontroll av datas autenticitet, men korrekt användning är avgörande. Standarden NIST SP 800-38D beskriver reglerna för GCM. Att återanvända samma kombination av nyckel och nonce för olika data kan äventyra säkerheten.
För användaren är den praktiska slutsatsen att beteckningen ”AES-256” inte räcker. Även specifikationerna för nyckelhantering, slumpgenerering, filvalidering och felhantering måste granskas. En ändrad byte ska leda till att en ogiltig fil avvisas, inte att manipulerat innehåll visas som en intakt fil.
Vad ser mottagaren, servern och galleriappen?
| Plats | Säkerhetsfråga |
|---|---|
| Fillagringstjänst | Har tjänsten bara krypterade byte, eller har den även tillgång till nyckeln? |
| Meddelandet med nyckeln | Skyddas nyckeln, filnamnet och beskrivningen i E2EE-samtalet? |
| Mottagarens enhet | Var finns filen efter att den öppnats: i minnet, cachen eller galleriet? |
| Molnsäkerhetskopia | Ingår den sparade kopian i bildernas säkerhetskopia, och vilket skydd har den säkerhetskopian? |
Kryptering under överföring styr inte den kopia som mottagaren sparar i galleriet. Innan du skickar en känslig handling bör du även granska onödiga delar av bilden, text i bakgrunden och filens platsinformation.
Vad är annorlunda för en fil i en privat grupp?
Antalet behöriga nyckelinnehavare ökar. Livara beskriver stöd för bilagor i kompatibla privata grupper i E2EE-läge i LGS1; det påståendet ska inte utsträckas till offentliga kanaler. Varje medlem som har fått filen kan behålla en kopia. Att ta bort en medlem eller rotera framtida nycklar återkallar inte den tidigare kopian.
Checklista för att skicka känsliga filer
- Kontrollera samtalets miljö och deltagare igen.
- Om kontaktens identitet är viktig, verifiera nyckelns fingeravtryck via en betrodd väg.
- Skicka bara nödvändig information; en bild av hela dokumentet behövs inte alltid.
- Kom överens med mottagaren om sparande i galleriet, automatisk nedladdning och molnsäkerhetskopiering.
- Lämna inte den dekrypterade filen på en delad eller olåst enhet.
Vanliga frågor
Garanterar en filspecifik nyckel säker överföring?
Nej. Säkra enheter, autentisering av mottagaren och korrekt implementation behövs också. Läs Livaras hotmodell tillsammans med krypteringsspecifikationerna.
Har en bild i en offentlig kanal samma skydd?
Enligt Livaras angivna gräns är kanaler offentliga och läsbara; inget löfte om privata bilagors konfidentialitet ges för dem.
Räcker enbart fillänken?
Det beror på tjänstens utformning. Bedöm länken, nyckeln och åtkomstbehörigheten separat; att en URL är lång eller slumpmässig bevisar inte E2EE.
