Vad är nollkunskapskryptering? En enkel guide
Nollkunskapskryptering innebär att leverantören inte kan komma åt din data.
Nollkunskapskryptering är en leverantörsbunden arkitektur där tjänsten inte innehåller den nyckel som behövs för att dekryptera lagrat användarinnehåll. Till skillnad från vanlig molnkryptering där leverantören kontrollerar innehållsnyckeln, kan kryptering på klientsidan behålla den förmågan på användarenheter. En juridisk begäran, intrång eller insider kan fortfarande avslöja chiffertext, kontouppgifter, trafikdata eller annan metadata som leverantören behåller. NIST:s vägledning för nyckelhantering gör nyckelförvaring central för åtkomst, men klientappen, operativsystemet och den olåsta enheten förblir en del av förtroendegränsen.
Hur nollkunskapskryptering fungerar
Den enklaste analogin: ett hotellsafe där bara du anger kombinationen, och hotellet aldrig lär sig den. Om du glömmer kombinationen kan hotellet inte öppna safet åt dig. Det är inte ett fel i designen. Det är designen.
I tekniska termer fungerar nollkunskapskryptering genom tre steg:
Nyckelhärledning på enheten. Användaren tillhandahåller en autentiseringsinformation som lösenord, lösenordsfras eller mönster. En lösenordsbaserad nyckelhärledningsfunktion kombinerar den med ett salt för att skapa en nyckel på användarens enhet. En väl separerad design kan använda den nyckeln för att låsa upp en slumpmässig innehållskrypteringsnyckel istället för att kryptera varje fil direkt med den mänskliga referensen.
Kryptering före överföring. All data krypteras på enheten med den härledda nyckeln innan den lämnar enheten för molnlagring eller säkerhetskopiering. Den krypterade utdatan (chiffertext) är det som laddas upp.
Leverantören får ingen klartextinnehållsnyckel. Innehållsnycklar finns nödvändigtvis i klientminnet under användning och kan också lagras lokalt eller på distans i autentiserade krypterade kuvert. Leverantören kan lagra chiffertext och inslagna nycklar utan att hålla den användarhemlighet som behövs för att öppna dem. Metadata för konto, trafik, poststorlek och timing kan fortfarande vara synliga.
Den kritiska begränsningen: om användaren förlorar alla giltiga referenser och återställningsvägar, blir det krypterade innehållet otillgängligt. Återhämtning kan fortfarande existera, men dess nyckelförvar måste förklaras. Om en e-poståterställning ensam återställer läsbart innehåll utan ett gammalt enhetsgodkännande, återställningsfras, återställningsnyckel eller motsvarande användarhållen hemlighet, har leverantören behållit en effektiv väg tillbaka till klartexten.
Nollkunskapskryptering vs. andra typer av kryptering
Termen "kryptering" förekommer i marknadsföringsmaterial för nästan varje molntjänst. Skillnaderna mellan typerna är betydande.
| Typ | Vem håller nyckeln | Leverantören kan läsa data | Överlever leverantörsintrång | Exempel |
|---|---|---|---|---|
| Ingen kryptering | Ej tillämpligt | Ja | Nej | Dropbox (standardnivå) |
| Kryptering under transport (TLS) | Leverantören | Ja (i vila på deras servrar) | Nej | Google Foton |
| Serversideskryptering i vila | Leverantören | Ja (de håller dekrypteringsnyckeln) | Delvis (beror på intrångets omfång) | iCloud (standard) |
| Plattform end-to-end-kryptering | Klientenheter och kontoåterställningssystem | Inte via den normala servicevägen | Beror på klient, återställning och metadataexponering | iCloud med avancerat dataskydd |
| Leverantörsblind kryptering på klientsidan | Klient- och användarkontrollerad återställningsväg | Ingen leverantörsinnehållsnyckel för klartextinnehåll | Innehåll kan förbli krypterat; metadata och chiffertext kan fortfarande läcka | Krypterade valv och säkerhetskopieringssystem |
Distinktionen mellan "kryptering i vila" och "nollkunskapskryptering" är den mest förväxlade. Med kryptering i vila krypterar leverantören din data på sina servrar med nycklar de kontrollerar. Detta skyddar mot fysisk stöld av serverhårdvara. Det skyddar inte mot leverantören som läser din data, en statlig stämningsansökan för data och nycklar, eller ett insiderhot. Leverantören har dekrypteringsförmågan.
Med leverantörsblind kryptering på klientsidan får tjänsten inte klartextinnehållsnyckeln genom det dokumenterade protokollet. Lagrad chiffertext kan förbli ogenomskinlig för den leverantören, medan klientprogramvaran, återställningsvägen, kontometadata och mjukvaruleveranskanalen fortfarande kräver förtroende och granskning.
Varför nollkunskapskryptering spelar roll
Dataintrång exponerar miljarder poster årligen
Identity Theft Resource Center rapporterade 3 205 datakomprometteringar i USA 2023, vilket påverkade cirka 353 miljoner individer. När en leverantör innehar innehållsnycklar kan ett intrång avslöja både lagrad data och en sökväg för att dekryptera den. Leverantörsblind kryptering separerar dessa tillgångar: ett serverintrång kan fortfarande exponera chiffertext och metadata, men inte en leverantörsinnehållen rentextinnehållsnyckel. Autentiseringsgissning och klientkompromisser förblir separata risker.
Juridisk tvång är ett verkligt hot
Leverantörer kan åläggas att avslöja data de behåller. En leverantörsblind design kan begränsa svaret till chiffertext och tillgänglig konto-, trafik-, fakturerings- eller tjänstemetadata eftersom leverantören inte innehar klartextinnehållsnyckeln. Huruvida en annan part kan erhålla användaruppgifter, utnyttja en klient eller tvinga fram avslöjande är en separat fråga. Apple introducerade Advanced Data Protection i iOS 16.2 som en valfri expansion av end-to-end-kryptering för iCloud data.
"Lita på oss" är inte en säkerhetsarkitektur
Kryptering på serversidan bygger på leverantörskontrollerade nycklar och policy. Leverantörsblind kryptering ändrar nyckelförvaringen så att den dokumenterade tjänstevägen saknar en klartextinnehållsnyckel. Det är en starkare arkitektonisk gräns, men dess kraft beror fortfarande på korrekt klientkod, autentiserad mjukvaruleverans, ljudåterställning, säkra enheter och en implementering som matchar specifikationen.
NIST-standarden bakom kryptografin
AES-GCM standardiserades av National Institute of Standards and Technology i SP 800-38D (2007). AES själv valdes ut av NIST genom en offentlig tävling 2001. "256" in AES-256 hänvisar till en 256-bitars nyckel. En uttömmande sökning över en enhetligt slumpmässig nyckel är beräkningsmässigt omöjlig, men ett mänskligt lösenord eller mönster kan ge mycket mindre entropi även när en nyckelhärledningsfunktion matar ut 256 bitar.
GCM (Galois/Counter Mode) lägger till autentiserad kryptering, vilket innebär att dekrypteringsprocessen detekterar eventuell manipulering av chiffertexten. Om en enda bit av krypterad data ändras misslyckas dekrypteringen snarare än att producera korrupt utdata. Detta förhindrar angripare från att manipulera krypterad data utan att det upptäcks.
PBKDF2 (Lösenordsbaserad nyckelhärledningsfunktion 2), specificerad i RFC 8018, konverterar en av människan tillhandahållen autentiseringsuppgifter till nyckelmaterial med fast längd genom upprepade pseudoslumpmässiga funktionsanrop. Fler iterationer ökar kostnaden för varje gissning. De lägger inte till entropi till ett förutsägbart mönster eller lösenord, så val av autentiseringsuppgifter och offlineverifiering spelar fortfarande roll.
Hur Vaultaire implementerar leverantör-nyckelseparation
Vaultaire är ett krypterat valv på klientsidan för iPhone. I den bemärkelse som produkten ofta marknadsförs som "noll kunskap", är dess snävare dokumenterade påstående att Wraxle inte tar emot valvinnehåll i klartext eller de nycklar som behövs för att dekryptera det. Så här fungerar implementeringen och de återstående förtroendegränserna i varje lager.
Nyckelhärledning. Användaren ritar ett mönster på ett 5x5 rutnät med 25 punkter. PBKDF2-HMAC-SHA512 kombinerar den sekvensen med en enhetsövergripande Keychain salt för 600 000 iterationer för att härleda en 256-bitars valvnyckel. Valvnyckeln autentiserar det krypterade indexet och lindar en separat slumpmässig 256-bitars huvudnyckel. Återställningsinformation, inklusive mönstret, lagras i en AES-GCM krypterad Keychain databas istället för klartextfiler eller ett Vaultaire-konto.
Filkryptering. Varje importerad fil krypteras med AES-256-GCM under den slumpmässiga huvudnyckeln. CryptoKit skapar autentiserade förseglade lådor med färska nonces, och streamingformatet härleder en distinkt nonce för varje beställd bit.
Metadatakryptering. Filnamn, MIME typer, datum, indexposter och miniatyrbildsdata skyddas också med AES-256-GCM. Vaultaire använder inte ChaCha20 för valvmetadata.
Nyckelhantering. Vaultaire lagrar sin enhetssalt och krypterade återställningsdatabas som vanligt iOS Keychain objekt med generiska lösenord skyddade med WhenUnlockedThisDeviceOnly tillgänglighetsklass. Mönsterhärledda valvnycklar och slumpmässiga huvudnycklar bearbetas i appminnet genom CryptoKit. Låsning sänker aktiv nyckelstatus, men Swift och iOS stöder inte en garanti för att varje tillfällig kopia skrivs över.
Upptäckt av valv. Det normala gränssnittet visar ingen valvlista. Det lokala formatet lagrar exakt 1 krypterad indexfil för varje valv, och underhållskoden kan räkna upp dessa filer. Någon med app-container-åtkomst kan därför räkna krypterade index, även om filnamnen inte avslöjar mönster, namn eller klartextinnehåll. Se hela säkerhetsarkitektur och mönsterkryptering förklaring.
Hur man avgör om en app använder äkta nollkunskapskryptering
Börja med tre snabba tester och verifiera sedan den publicerade arkitekturen:
Glömt lösenordstestet. Om enbart e-poståterställning återställer läsbar data, fråga vilken leverantörshållen mekanism som återställde den effektiva innehållsnyckeln. Användarhållna återställningsfraser, godkännande av gamla enheter och leverantörskontrollerade återställningar är olika utformningar.
Testet av den nya enheten. Om en ny enhet återställer läsbart innehåll, identifiera den hemliga eller betrodda enheten som auktoriserade den. Enbart kontoinloggning föreslår en leverantörskontrollerad återställningsväg; en återställningsfras plus krypterade backupposter kan bevara leverantör-nyckelseparation.
Kontotestet. En e-postadress eller ett telefonnummer länkar identitet till tjänstens metadata, men det bevisar inte i sig att leverantören kan dekryptera innehåll. Inspektera nyckelhierarkin, återställningsdesign, klientkod eller revision, metadatapolicy och om autentiserad chiffertext tillåter kontroller av autentiseringsuppgifter offline.
Dessa tester är filter, inte ett säkerhetsbevis. En sammanhängande specifikation bör namnge innehållsnyckeln, upplåsningsnyckeln, salter, härledningsparametrar, autentiserat krypteringsformat, nonce-regler, återställningskuvert, lokal hemlig lagring, molnmetadata och den punkt där klartextnycklar finns. Oberoende granskning är starkare bevis än en produktmärkning.
Vanliga frågor
Är nollkunskapskryptering detsamma som end-to-end-kryptering?
De överlappar men är inte identiska. End-to-end-kryptering (E2EE) innebär att data krypteras på avsändarens enhet och dekrypteras bara på mottagarens enhet. Nollkunskapskryptering innebär att leverantören inte kan komma åt datan. En tjänst kan vara end-to-end-krypterad utan att vara nollkunskap om leverantören genererade eller har tillgång till nycklarna vid något tillfälle. Nollkunskapskryptering är den strängare standarden.
Vad händer om jag tappar bort mitt lösenord med nollkunskapskryptering?
Dina data blir permanent otillgängliga om alla giltiga autentiseringsuppgifter och återställningskuvert försvinner. En leverantörskontrollerad återställning eller huvudnyckel skulle försvaga leverantörsgränsen, så återställning måste utformas separat. Vaultaire genererar en anpassad fras med 9 separata ord vars härledda återställningsnyckel öppnar ett krypterat valvnyckelkuvert. Frasen regenererar eller kodar inte nyckeln, och återställning av ny enhet kräver också den matchande krypterade CloudKit rekord.
Kan brottsbekämpning komma åt nollkunskapskrypterad data?
En leverantör kan behöva avslöja lagrad chiffertext och de konto-, trafik-, fakturerings- eller tjänstmetadata som den behåller. Utan en leverantörsinnehållen innehållsnyckel i klartext kan den leverantören inte använda sin normala tjänstsökväg för att dekryptera innehållet. Enhetsexploatering, upptäckt av autentiseringsuppgifter, återställningskopior och påtvingat avslöjande är separata vägar vars laglighet och effektivitet varierar beroende på jurisdiktion och fakta.
Är nollkunskapskryptering långsammare än vanlig kryptering?
AES-256-GCM prestandan beror inte på vem som har nyckeln. Lösenordsbaserad härledning lägger till arbete under upplåsning, och dess varaktighet beror på algoritm, iterationsantal, enhet och implementering. Applikationer bör mäta den kostnaden för hårdvara som stöds och balansera lyhördhet mot kostnaden för varje offline-gissning.
Betyder nollkunskap att appen inte samlar in någon data alls?
Inte nödvändigtvis. Termen adresserar leverantörens innehåll-nyckelgräns, inte alla dataflöden. En app kan fortfarande bearbeta kontodata, analyser, kraschrapporter, IP-adresser, poststorlekar, timing eller annan tjänstemetadata. Vaultaire kräver inget identitetskonto och säger att dess samtyckesbaserade analyser utesluter valvinnehåll, mönster, fraser och dekrypteringsnycklar; dess sekretesspolicy beskriver gällande insamlings- och förvaringsregler.
Hur jämförs nollkunskapskryptering med Apples Advanced Data Protection?
Apples Advanced Data Protection (ADP), introducerad i iOS 16.2, utökar end-to-end-kryptering till ytterligare iCloud kategorier och använder återställningsmodellen för Apple-konton. Vaultaire håller valvsinnehåll lokalt som standard och kräver inget Vaultaire-identitetskonto; valfri säkerhetskopiering, synkronisering och delning använder krypterad klientsida CloudKit poster i användarens Apple-konto. Vaultaire erbjuder också mönsterseparerad valvåtkomst och tvångsläge, med lagrings- och återställningsgränserna som beskrivs i dess trovärdig förnekelse dokumentation.
Sammanfattning
Noll-kunskapskryptering behandlas bäst som ett påstående om leverantör-nyckel-separation: tjänsten innehåller inte den klartextnyckel som behövs för att dekryptera lagrat innehåll. Det är starkare än kryptering på serversidan under leverantörskontrollerade nycklar, men det är inte ett påstående att nycklar bara finns i minnet, att metadata försvinner eller att varje kompromiss med klient och enhet besegras. Bedöm produkten efter dess nyckelhierarki, återställningsdesign, implementering och oberoende granskning.