Hvad er nul-kendskab-kryptering? En enkel guide
Nul-kendskab-kryptering betyder at udbyderen ikke kan tilgå dine data.
Nul-viden-kryptering er en arkitektur, hvor udbyderen er udelukket, og tjenesten ikke har den nødvendige nøgle til at dekryptere lagret brugerindhold. I modsætning til almindelig skykryptering, hvor udbyderen kontrollerer indholdsnøglen, kan kryptering på klientsiden holde den rolle på brugerens enheder. En juridisk anmodning, brud eller insider kan stadig afsløre chiffertekst, kontoposter, trafikdata eller andre metadata, som udbyderen beholder. NISTs vejledning om nøglehåndtering gør nøgleopbevaring central for adgang, men klientappen, styresystemet og den ulåste enhed forbliver en del af tillidsgrænsen.
Sådan fungerer nul-kendskab-kryptering
Den enkleste analogi: en hotelpengeskab hvor du selv sætter kombinationen og hotellet aldrig får den at vide. Glemmer du kombinationen, åbner hotellet ikke pengeskabet for dig. Det er ikke en designfejl. Det er designhensigten.
I tekniske termer fungerer nul-kendskab-kryptering i tre trin:
Nøgleafledning på enheden. Brugeren angiver en hemmelighed, f.eks. en adgangskode, en adgangssætning eller et mønster. En adgangskodebaseret nøgleafledningsfunktion kombinerer den med et salt for at producere en nøgle på brugerens enhed. Et godt adskilt design kan bruge denne nøgle til at låse op for en tilfældig indholdskrypteringsnøgle i stedet for at kryptere hver fil direkte med brugerens hemmelighed.
Kryptering inden overførsel. Alle data krypteres på enheden med den afledte nøgle inden de forlader enheden til cloud-opbevaring eller backup. Det krypterede output (chiffertekst) er det der uploades.
Udbyderen modtager ingen indholdsnøgle i klartekst. Indholdsnøgler eksisterer nødvendigvis i klienthukommelsen under brug og kan også gemmes lokalt eller eksternt inde i autentificerede krypterede konvolutter. Udbyderen kan gemme chiffertekst og indpakkede nøgler uden at holde på den brugerhemmelighed, der er nødvendig for at åbne dem. Metadata om konto, trafik, poststørrelse og timing kan stadig være synlige.
Den kritiske begrænsning: Hvis brugeren mister alle gyldige hemmeligheder og gendannelsesveje, bliver det krypterede indhold utilgængeligt. Gendannelse kan stadig findes, men det skal forklares, hvem der opbevarer dens nøgler. Hvis en e-mail-nulstilling alene gendanner læsbart indhold uden en gammel enhedsgodkendelse, gendannelsessætning, gendannelsesnøgle eller tilsvarende brugerbevaret hemmelighed, har udbyderen bevaret en effektiv rute tilbage til klarteksten.
Nul-kendskab-kryptering vs. andre typer kryptering
Begrebet "kryptering" optræder i markedsføringsmateriale fra næsten enhver cloud-tjeneste. Forskellene mellem typerne er væsentlige.
| Type | Hvem holder nøglen | Udbyderen kan læse data | Overlever udbyderbrud | Eksempel |
|---|---|---|---|---|
| Ingen kryptering | Ingen | Ja | Nej | Dropbox (standardniveau) |
| Kryptering under overførsel (TLS) | Udbyder | Ja (i hvile på deres servere) | Nej | Google Fotos |
| Serversidekryptering i hvile | Udbyder | Ja (holder dekrypteringsnøglen) | Delvist (afhænger af bruddets omfang) | iCloud (standard) |
| End-to-end-kryptering på platformen | Klientenheder og kontogendannelsessystem | Ikke gennem den normale servicevej | Afhænger af klient, gendannelse og metadataeksponering | iCloud med Avanceret databeskyttelse |
| Kryptering på klientsiden, som udbyderen ikke kan læse | Gendannelsesvej styret af klienten og brugeren | Udbyderen har ingen indholdsnøgle i klartekst | Indhold kan forblive krypteret; metadata og chiffertekst kan stadig lække | Krypterede boks- og backupsystemer |
Forskellen mellem "kryptering i hvile" og "nul-kendskab-kryptering" er den hyppigst forvekslede. Ved kryptering i hvile krypterer udbyderen dine data på sine servere med nøgler han kontrollerer. Det beskytter mod fysisk tyveri af serverhardware. Det beskytter ikke mod udbyderens læsning af dine data, en statslig stævning for data og nøgler, eller en intern trussel. Udbyderen har dekrypteringsevnen.
Med klientsidekryptering, som udbyderen ikke kan læse, får tjenesten ikke indholdsnøglen i klartekst gennem den dokumenterede protokol. Lagret chiffertekst kan forblive uigennemsigtig for den pågældende udbyder, mens klientsoftwaren, gendannelsesvejen, kontometadata og softwareleveringskanalen stadig kræver tillid og gennemgang.
Hvorfor nul-kendskab-kryptering er vigtigt
Databrud rammer milliarder af poster hvert år
Identity Theft Resource Center rapporterede 3.205 datakompromitteringer i USA i 2023, som ramte cirka 353 millioner personer. Når en udbyder har indholdsnøgler, kan et brud afsløre både lagrede data og en måde at dekryptere dem på. Kryptering, som udbyderen ikke kan læse, adskiller disse aktiver: et serverbrud kan stadig afsløre chiffertekst og metadata, men ikke en indholdsnøgle i klartekst hos udbyderen. Gæt på adgangskoder og kompromittering af klienten forbliver separate risici.
Juridisk tvang er en reel trussel
Udbydere kan blive pålagt at videregive data, de opbevarer. Et design, hvor udbyderen ikke kan læse indholdet, kan begrænse dette svar til chiffertekst og tilgængelige konto-, trafik-, fakturerings- eller tjenestemetadata, fordi udbyderen ikke har indholdsnøglen i klartekst. Om en anden part kan få fat i brugerens hemmelighed, udnytte en klient eller tvinge udlevering igennem, er et separat spørgsmål. Apple introducerede Avanceret databeskyttelse i iOS 16.2 som en valgfri udvidelse af end-to-end-kryptering til iCloud-data.
"Stol på os" er ikke en sikkerhedsarkitektur
Kryptering på serversiden afhænger af nøgler og politikker, som udbyderen styrer. Kryptering, som udbyderen ikke kan læse, ændrer nøgleopbevaringen, så den dokumenterede tjenestevej mangler en indholdsnøgle i klartekst. Det er en stærkere arkitektonisk grænse, men dens kraft afhænger stadig af korrekt klientkode, autentificeret softwarelevering, sund gendannelse, sikre enheder og en implementering, der matcher specifikationen.
NIST-standarden bag kryptografien
AES-GCM blev standardiseret af National Institute of Standards and Technology i SP 800-38D (2007). AES selv blev udvalgt af NIST gennem en offentlig konkurrence i 2001. "256" i AES-256 refererer til en 256-bit nøgle. Udtømmende søgning over en ensartet tilfældig nøgle er beregningsmæssigt umulig, men et menneskeligt kodeord eller et menneskeligt mønster kan give langt mindre entropi, selv når en nøgleafledningsfunktion udsender 256 bit.
GCM (Galois/Counter Mode) tilføjer autentificeret kryptering, hvilket betyder at dekrypteringsprocessen vil afsløre enhver manipulation af chifferteksten. Hvis én bit af krypterede data ændres, slår dekryptering fejl i stedet for at producere korrupt output. Det forhindrer angribere i at manipulere med krypterede data uden at blive afsløret.
PBKDF2 (Adgangskodebaseret nøgleafledningsfunktion 2), specificeret i RFC 8018, omdanner en hemmelighed, som et menneske har valgt, til nøglemateriale med fast længde gennem gentagne pseudorandom-funktionskald. Flere iterationer øger prisen på hvert gæt. De tilføjer ikke entropi til et forudsigeligt mønster eller en forudsigelig adgangskode, så valget af hemmelighed og muligheden for offlinekontrol har stadig betydning.
Sådan holder Vaultaire nøglerne væk fra udbyderen
Vaultaire er en krypteret boks på klientsiden til iPhone. Selvom den slags produkt ofte markedsføres som "nul-viden", er dens snævrere dokumenterede påstand, at Wraxle ikke modtager boksindhold i klartekst eller de nødvendige nøgler til at dekryptere det. Her er, hvordan implementeringen og de resterende tillidsgrænser fungerer på hvert lag.
Nøgleafledning. Brugeren tegner et mønster på et 5x5-gitter med 25 prikker. PBKDF2-HMAC-SHA512 kombinerer denne sekvens med et enhedsdækkende Keychain-salt i 600.000 iterationer for at udlede en 256-bit boksnøgle. Boksnøglen autentificerer det krypterede indeks og indpakker en separat tilfældig 256-bit hovednøgle. Gendannelsesoplysninger, herunder mønsteret, gemmes i en AES-GCM-krypteret Keychain-database i stedet for klartekstfiler eller en Vaultaire-konto.
Filkryptering. Hver importeret fil er krypteret med AES-256-GCM under den tilfældige hovednøgle. CryptoKit opretter autentificerede sealed boxes med friske nonces, og streamingformatet udleder en særskilt nonce for hver del i rækkefølgen.
Metadatakryptering. Filnavne, MIME-typer, datoer, indeksposter og thumbnail-data er også beskyttet med AES-256-GCM. Vaultaire bruger ikke ChaCha20 til boksmetadata.
Nøglestyring. Vaultaire gemmer sit enhedssalt og sin krypterede gendannelsesdatabase som almindelige generiske adgangskoder i iOS Keychain, beskyttet med tilgængelighedsklassen WhenUnlockedThisDeviceOnly. Mønsterafledte boksnøgler og tilfældige hovednøgler behandles i apphukommelsen via CryptoKit. Låsning kasserer aktiv nøgletilstand, men Swift og iOS garanterer ikke, at enhver forbigående kopi overskrives.
Opdagelse af bokse. Den normale grænseflade viser ikke en boksliste. Sider fra alle bokse deler én mappe med tilfældige navne, så filnavnene viser ikke, hvilken boks en fil hører til, og de afslører ikke mønstre, navne eller indhold i klartekst. En person med adgang til app-containeren kan stadig anslå, hvor mange bokse du har, fordi antallet af lagerarenaer sætter en grænse for det. Se hele sikkerhedsarkitektur og mønsterkrypteringsforklaring.
Sådan afgør du om en app faktisk bruger nul-kendskab-kryptering
Start med tre hurtige test, og bekræft derefter den offentliggjorte arkitektur:
Testen med glemt adgangskode. Hvis en nulstilling via e-mail alene gendanner læsbare data, så spørg, hvilken mekanisme hos udbyderen der genskabte den reelle indholdsnøgle. Gendannelsessætninger, som brugeren har, godkendelse fra en gammel enhed og nulstillinger styret af udbyderen er forskellige designs.
Testen af den nye enhed. Hvis en ny enhed gendanner læsbart indhold, skal du finde den hemmelighed eller betroede enhed, der godkendte den. Et kontologin alene tyder på en gendannelsesvej styret af udbyderen; en gendannelsessætning plus krypterede backupposter kan holde nøglerne væk fra udbyderen.
Kontotesten. En e-mailadresse eller et telefonnummer knytter identitet til tjenestens metadata, men det beviser ikke i sig selv, at udbyderen kan dekryptere indhold. Undersøg nøglehierarkiet, gendannelsesdesignet, klientkoden eller revisionen, metadatapolitikken, og om autentificeret chiffertekst tillader offlinekontrol af adgangskoder.
Disse tests er filtre, ikke et sikkerhedsbevis. En sammenhængende specifikation bør navngive indholdsnøglen, oplåsningsnøglen, salte, afledningsparametre, autentificeret krypteringsformat, nonce-regler, gendannelseskonvolutter, lokal hemmelig lagring, cloud-metadata og det punkt, hvor der findes klartekstnøgler. Uafhængig gennemgang er stærkere bevis end en produktetiket.
Ofte stillede spørgsmål
Er nul-kendskab-kryptering det samme som end-to-end-kryptering?
De overlapper, men er ikke identiske. End-to-end-kryptering (E2EE) betyder at data krypteres på afsenderens enhed og kun dekrypteres på modtagerens enhed. Nul-kendskab-kryptering betyder at udbyderen ikke kan tilgå dataene. En tjeneste kan være end-to-end-krypteret uden at være nul-kendskab, hvis udbyderen genererede nøglerne eller havde adgang til dem på et tidspunkt. Nul-kendskab-kryptering er en strengere standard.
Hvad sker der hvis jeg mister min adgangskode med nul-kendskab-kryptering?
Dine data bliver permanent utilgængelige, hvis alle gyldige hemmeligheder og gendannelseskonvolutter går tabt. En udbyderstyret nulstilling eller hovednøgle ville svække udbydergrænsen, så gendannelse skal designes separat. Vaultaire bruger en gendannelsessætning, enten en genereret sætning på ni ord eller en selvvalgt på mindst seks ord, hvis afledte gendannelsesnøgle åbner en krypteret boksnøglekonvolut. Sætningen regenererer eller koder ikke nøglen, og gendannelse på en ny enhed kræver også de matchende krypterede CloudKit-poster.
Kan politiet tilgå data krypteret med nul-kendskab-kryptering?
En udbyder skal muligvis afsløre gemt chiffertekst og de konto-, trafik-, fakturerings- eller tjenestemetadata, den beholder. Uden en indholdsnøgle i klartekst hos udbyderen kan denne udbyder ikke bruge sin normale tjenestevej til at dekryptere indholdet. Udnyttelse af enheden, opsnapning af adgangskoder, gendannelseskopier og tvungen udlevering er separate veje, hvis lovlighed og effektivitet varierer afhængigt af jurisdiktion og fakta.
Er nul-kendskab-kryptering langsommere end almindelig kryptering?
AES-256-GCM-ydeevnen afhænger ikke af, hvem der har nøglen. Adgangskodebaseret afledning tilføjer arbejde under oplåsning, og dets varighed afhænger af algoritmen, iterationsantal, enhed og implementering. Applikationer bør måle denne pris på understøttet hardware og afbalancere reaktionsevnen mod de omkostninger, der pålægges hvert offline-gæt.
Betyder nul-kendskab at appen slet ikke indsamler data?
Ikke nødvendigvis. Udtrykket handler om, at udbyderen ikke har indholdsnøglen, ikke om alle datastrømme. En app kan stadig behandle kontodata, analyser, nedbrudsrapporter, IP-adresser, poststørrelser, timing eller andre tjenestemetadata. Vaultaire kræver ingen identitetskonto. Dens appanalyse og nedbrudsdiagnostik er aktiveret som standard og kan slås fra med "Del fejl anonymt" i Indstillinger. Den dokumenterede hændelsespolitik udelukker boksindhold, mønstre, sætninger og dekrypteringsnøgler; privatlivspolitikken beskriver de nuværende regler for indsamling og opbevaring.
Hvordan adskiller nul-kendskab-kryptering sig fra Apples Avanceret databeskyttelse?
Apples Avanceret databeskyttelse (ADP), introduceret i iOS 16.2, udvider ende-til-ende-kryptering til flere iCloud-kategorier og bruger Apple-kontogendannelsesmodellen. Vaultaire krypterer boksindhold på enheden og kræver ingen Vaultaire-identitetskonto; dens iCloud-sikkerhedskopi, der er slået til som standard, samt synkronisering og deling bruger klientsidekrypterede CloudKit-poster på brugerens Apple-konto. Vaultaire tilbyder også mønsteradskilt adgang til boksene og tvangstilstand, med opbevarings- og gendannelsesgrænserne beskrevet i dokumentationen om troværdig benægtelse.
Sammenfatning
Nul-viden-kryptering forstås bedst som et krav om, at udbyderen ikke har nøglerne: Tjenesten har ikke den klartekstnøgle, der er nødvendig for at dekryptere lagret indhold. Det er stærkere end kryptering på serversiden under nøgler, som udbyderen styrer, men det er ikke en påstand om, at nøgler kun findes i hukommelsen, at metadata forsvinder, eller at enhver kompromittering af klient og enhed er afværget. Bedøm produktet ud fra dets nøglehierarki, gendannelsesdesign, implementering og uafhængig gennemgang.