Vad är nollkunskapskryptering? En enkel guide
Nollkunskapskryptering innebär att leverantören inte kan komma åt din data.
Nollkunskapskryptering är en arkitektur avgränsad till leverantören där tjänsten inte har 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 upplå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 anger en inloggningsuppgift som ett lösenord, en lösenfras eller ett 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 inloggningsuppgiften.
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 innehållsnyckel i klartext. 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 omslutna 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 inloggningsuppgifter och återställningsvägar blir det krypterade innehållet otillgängligt. Återställning kan fortfarande finnas, men dess nyckelförvaring 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) |
| End-to-end-kryptering i plattformen | Klientenheter och kontoåterställningssystem | Inte via den normala tjänstevägen | Beror på klient, återställning och metadataexponering | iCloud med avancerat dataskydd |
| Leverantörsblind kryptering på klientsidan | Klienten och en användarkontrollerad återställningsväg | Ingen innehållsnyckel i klartext hos leverantören | 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 kryptering på klientsidan som leverantören inte kan se in i får tjänsten inte innehållsnyckeln i klartext 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 dataintrång i USA 2023, som berörde cirka 353 miljoner personer. När en leverantör har innehållsnycklarna kan ett intrång avslöja både lagrade data och en väg att dekryptera dem. Kryptering som leverantören inte kan se in i skiljer dessa tillgångar åt: ett serverintrång kan fortfarande exponera chiffertext och metadata, men inte en innehållsnyckel i klartext hos leverantören. Gissning av inloggningsuppgifter och intrång i klienten förblir separata risker.
Juridisk tvång är ett verkligt hot
Leverantörer kan åläggas att avslöja data de behåller. En design som leverantören inte kan se in i kan begränsa svaret till chiffertext och tillgänglig konto-, trafik-, fakturerings- eller tjänstemetadata, eftersom leverantören inte har innehållsnyckeln i klartext. Om en annan part kan få tag på en användares inloggningsuppgift, utnyttja en klient eller tvinga fram ett avslöjande är en separat fråga. Apple introducerade Avancerat dataskydd 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. Kryptering som leverantören inte kan se in i ändrar nyckelförvaringen så att den dokumenterade tjänstevägen saknar en innehållsnyckel i klartext. Det är en starkare arkitektonisk gräns, men dess styrka beror fortfarande på korrekt klientkod, autentiserad mjukvaruleverans, sund å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 valdes själv ut av NIST genom en offentlig tävling 2001. "256" i AES-256 syftar på 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 (Password-Based Key Derivation Function 2), specificerad i RFC 8018, omvandlar en inloggningsuppgift som en människa anger 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å valet av inloggningsuppgift och offlineverifiering spelar fortfarande roll.
Hur Vaultaire håller nycklarna borta från leverantören
Vaultaire är ett krypterat valv på klientsidan för iPhone. I den produktbemärkelse som 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 ett enhetsomfattande Keychain-salt för 600 000 iterationer för att härleda en 256-bitars valvnyckel. Valvnyckeln autentiserar det krypterade indexet och omsluter en separat slumpmässig 256-bitars huvudnyckel. Återställningsinformation, inklusive mönstret, lagras i en AES-GCM-krypterad Keychain-databas, vars nyckel också finns på samma enhet, i stället för i 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 nya nonces, och streamingformatet härleder en egen nonce för varje segment i ordningsföljd.
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 sitt enhetssalt och sin krypterade återställningsdatabas som vanliga generiska lösenordsobjekt i iOS Keychain, skyddade med tillgänglighetsklassen WhenUnlockedThisDeviceOnly. Mönsterhärledda valvnycklar och slumpmässiga huvudnycklar bearbetas i appens minne genom CryptoKit. Låsning släpper det aktiva nyckeltillståndet, men Swift och iOS kan inte garantera att varje tillfällig kopia skrivs över.
Upptäckt av valv. Det normala gränssnittet visar ingen valvlista. Lagringsformatet har en lagringskatalog per valv. Någon med åtkomst till appcontainern kan därför räkna valven, även om katalognamnen inte avslöjar mönster, namn eller klartextinnehåll. Se hela säkerhetsarkitekturen och förklaringen av mönsterkryptering.
Hur man avgör om en app använder äkta nollkunskapskryptering
Börja med tre snabba tester och verifiera sedan den publicerade arkitekturen:
Testet med glömt lösenord. Om enbart en e-poståterställning återställer läsbara data, fråga vilken mekanism hos leverantören 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 med ny enhet. Om en ny enhet återställer läsbart innehåll, ta reda på vilken hemlighet eller betrodd enhet som godkände det. Enbart kontoinloggning tyder på en leverantörskontrollerad återställningsväg; en återställningsfras plus krypterade säkerhetskopieposter kan hålla nycklarna borta från leverantören.
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. Granska nyckelhierarkin, återställningsdesignen, klientkoden eller en granskningsrapport, metadatapolicyn och om autentiserad chiffertext tillåter kontroll av inloggningsuppgifter 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 inloggningsuppgifter och återställningskuvert går förlorade. En leverantörskontrollerad återställning eller huvudnyckel skulle försvaga leverantörsgränsen, så återställning måste utformas separat. Vaultaire genererar en återställningsfras med nio ord, eller använder en egen fras på minst sex ord, vars härledda återställningsnyckel öppnar ett krypterat valvnyckelkuvert. Frasen återskapar eller kodar inte nyckeln, och återställning till en ny enhet kräver också de matchande krypterade CloudKit-posterna.
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 innehållsnyckel i klartext hos leverantören kan den leverantören inte använda sin normala tjänsteväg för att dekryptera innehållet. Utnyttjande av enheten, upptäckt av inloggningsuppgifter, å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?
Prestandan för AES-256-GCM 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. Appar bör mäta den kostnaden på hårdvara som stöds och väga svarstid mot kostnaden för varje offlinegissning.
Betyder nollkunskap att appen inte samlar in någon data alls?
Inte nödvändigtvis. Termen gäller leverantörens gräns för innehållsnycklar, 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. Dess appanalys och kraschdiagnostik är aktiverade som standard och kan stängas av med "Dela fel anonymt" i Inställningar. Den dokumenterade händelsepolicyn utesluter valvinnehåll, mönster, fraser och dekrypteringsnycklar; sekretesspolicyn beskriver de nuvarande reglerna för insamling och lagring.
Hur jämförs nollkunskapskryptering med Apples Avancerat dataskydd?
Apples Avancerat dataskydd (ADP), introducerad i iOS 16.2, utökar end-to-end-kryptering till fler iCloud-kategorier och använder återställningsmodellen för Apple-konton. Vaultaire krypterar valvinnehållet på enheten och kräver inget Vaultaire-identitetskonto; dess iCloud-säkerhetskopiering (på som standard, kan stängas av), synkronisering och delning använder CloudKit-poster som krypterats på klientsidan 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 dokumentation om trovärdig förnekelse.
Sammanfattning
Nollkunskapskryptering behandlas bäst som ett påstående om att nycklarna hålls borta från leverantören: tjänsten har inte den nyckel i klartext 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 intrång i klient och enhet avvärjs. Bedöm produkten efter dess nyckelhierarki, återställningsdesign, implementering och oberoende granskning.