Krypterad lagring skiljer filens byte från rätten att dekryptera, men mottagare, metadata och lokala kopior ingår fortfarande i hotmodellen.
En totalsträckskrypterad bilaga kan lagras på en server utan att servern får filen i klartext. En vanlig konstruktion krypterar filen på avsändarens enhet med en ny innehållsnyckel, laddar upp kryptotexten och skickar nyckeln till de avsedda mottagarna inuti ett autentiserat krypterat meddelande.
Separationen är användbar, men ”zero-knowledge-lagring” är ingen fullständig specifikation. Du behöver fortfarande fråga hur nycklar, filreferenser, filnamn, åtkomstkontroller och nedladdade kopior hanteras.
Bilagans livscykel
- Förbered filen. Avsändaren väljer ett foto, en video eller ett dokument. Borttagning av metadata eller omkodning är ett separat steg; kryptering i sig tar inte bort EXIF eller dokumentegenskaper.
- Skapa krypteringsmaterial. En säker implementation genererar nödvändigt nyckel- och nonce-material enligt det valda schemat.
- Kryptera före uppladdning. Lagringstjänsten får krypterade byte i stället för originalinnehållet.
- Leverera en autentiserad referens. Det krypterade chattmeddelandet innehåller det mottagarna behöver, till exempel en filadress, dekrypteringsnyckel och relevanta integritetsmetadata.
- Hämta och verifiera. Mottagarens klient hämtar dataobjektet och verifierar autentiseringen innan resultatet betraktas som giltigt innehåll.
- Hantera lokala kopior. Visning, export, redigering eller sparande i ett galleri kan skapa kopior utanför den ursprungliga krypterade lagringens gräns.
Nyckeln kan färdas genom samma leverantörs infrastruktur i ett krypterat hölje. Att kalla det ”out of band” kan vilseleda: det är logiskt åtskilt från objektlagringen, men levereras inte nödvändigtvis via en oberoende kommunikationskanal.
Vad autentiserad kryptering tillför
Ett autentiserat krypteringsschema skyddar konfidentialitet och upptäcker obehöriga ändringar inom sitt autentiserade område. NIST:s GCM-specifikation definierar en sådan konstruktion och dess krav. Korrekt hantering av nycklar och nonce samt kontroll av autentiseringsresultatet är nödvändiga; ett erkänt algoritmnamn gör inte varje implementation säker.
Appen måste också knyta filen till rätt meddelande och samtal. Ett giltigt krypterat dataobjekt bevisar inte i sig att det hör hemma i just den här chatten. Filidentifierare, förväntad storlek, delarnas ordning och bilagemetadata behöver en lämplig autentiserad konstruktion.
Vad lagringstjänsten fortfarande kan få veta
| Information | Döljs den av enbart innehållskryptering? |
|---|---|
| Filens ursprungliga byte | Det är avsikten gentemot parter utan nyckeln |
| Ungefärlig krypterad storlek | Vanligen inte |
| Tidpunkter för upp- och nedladdning | Vanligen inte |
| Vilket konto som begär en fil | Beror på routning och åtkomstkontroll |
| Filnamn och bildtext | Bara om protokollet skyddar dem också |
| En kopia sparad av mottagaren | Nej; mottagaren har redan klartextåtkomst |
Åtkomstkontroller spelar roll även när dataobjekten är krypterade. De kan begränsa oönskad nedladdning, missbruk och exponering av identifierare. Kryptering ersätter inte behörighetskontroll, lagringspolicyer eller tillgänglighet.
Stora filer kräver mer än en slogan
En konstruktion för stora filer kan strömma data eller dela upp dem i autentiserade delar. Det kan minska minnesanvändningen, men delarnas numrering, slutlig längd, omförsök och hantering av avklippta data måste definieras. Hitta inte på prestandasiffror och hävda inte att en fil i ett meddelande nödvändigtvis orsakar ”uppsvällt ratchet-tillstånd”; sådana resultat beror på implementationen.
Ett användbart test omfattar en giltig fil, en ändrad byte, en avklippt nedladdning, en omordnad del och ett obehörigt hämtningsförsök. Kör sådana tester endast i en auktoriserad testmiljö med icke-känsliga filer. Anteckna om klienten avvisar ogiltiga data innan de öppnas.
Vad Livara dokumenterar
Livara beskriver på sin säkerhetssida kryptering före uppladdning, en slumpmässig nyckel per fil som överförs inom den skyddade sessionen samt skydd för filnamn och bildtexter i samtal med aktiv E2EE, inklusive kompatibla privata grupper. Äldre inkompatibla grupper ligger uttryckligen utanför skyddet. Sidan skiljer skyddade samtal från offentliga sändningskanaler. Detta är dokumenterade produktpåståenden, inte en ny implementationsgranskning i denna artikel.
Hotmodellen erkänner också att en mottagare eller komprometterad enhet kan exponera läsbart innehåll. Krypterad lagring kan därför inte lova att en bild försvinner från varje enhet när dess chattmeddelande raderas.
Frågor innan du delar känsliga filer
Kontrollera om samtalstypen stöder E2EE, om alla avsedda mottagare är betrodda och om själva filen innehåller identifierande metadata. Granska automatiskt sparande i galleriet och säkerhetskopiering av foton till molnet separat. För ett dokument bör du överväga om kommentarer, revisionshistorik eller inbäddade egenskaper ska tas bort före sändning.
Förstå slutligen radering och återställning. Att ta bort ett dataobjekt från servern kan stoppa framtida hämtning, men återkallar inte mottagarens befintliga kopia. Att förlora den nödvändiga nyckeln kan göra en kvarvarande krypterad fil oläsbar. En bra bilagekonstruktion förklarar båda följderna tydligt.
