Hvad er nul-kendskab-kryptering? En enkel guide

Hvad er nul-kendskab-kryptering? En enkel guide

Nul-kendskab-kryptering betyder at udbyderen ikke kan tilgå dine data.

Nul-viden-kryptering er en udbyder-bundet arkitektur, hvor tjenesten ikke har den nødvendige nøgle til at dekryptere lagret brugerindhold. I modsætning til standard skykryptering, hvor udbyderen kontrollerer indholdsnøglen, kan kryptering på klientsiden bevare denne funktion på brugerens enheder. En juridisk anmodning, brud eller insider kan stadig afsløre chiffertekst, kontoregistreringer, trafikdata eller andre metadata, som udbyderen beholder. NISTs nøglehåndteringsvejledning gør nøgledepot centralt at få adgang til, men klientappen, operativsystemet 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:

  1. Nøgleafledning på enheden. Brugeren angiver legitimationsoplysninger såsom 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 den menneskelige legitimation.

  2. 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.

  3. 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 for konto, trafik, registreringsstørrelse og timing kan stadig være synlige.

Den kritiske begrænsning: Hvis brugeren mister alle gyldige legitimationsoplysninger og gendannelsesstier, bliver det krypterede indhold utilgængeligt. Genopretning kan stadig eksistere, men dets nøgleforvaring skal forklares. Hvis en e-mail-nulstilling alene gendanner læsbart indhold uden en gammel enhedsgodkendelse, gendannelsessætning, gendannelsesnøgle eller tilsvarende brugerbevart 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)
Platform end-to-end kryptering Klientenheder og kontogendannelsessystem Ikke gennem den normale servicevej Afhænger af klient, gendannelse og metadataeksponering iCloud med avanceret databeskyttelse
Udbyderblind kryptering på klientsiden Klient- og brugerstyret gendannelsessti Ingen nøgle til indhold i almindelig tekst fra udbyderen 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 udbyderblind klientsidekryptering får tjenesten ikke klartekstindholdsnøglen gennem den dokumenterede protokol. Lagret chiffertekst kan forblive uigennemsigtig for den pågældende udbyder, mens klientsoftwaren, gendannelsesstien, 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, hvilket berørte cirka 353 millioner individer. Når en udbyder har indholdsnøgler, kan et brud afsløre både lagrede data og en sti til at dekryptere dem. Udbyder-blind kryptering adskiller disse aktiver: et serverbrud kan stadig afsløre chiffertekst og metadata, men ikke en udbyder-holdt klartekstindholdsnøgle. Credential-gætning og klientkompromis forbliver separate risici.

Juridisk tvang er en reel trussel

Udbydere kan blive pålagt at videregive data, de opbevarer. Et udbyderblindt design kan begrænse dette svar til chiffertekst og tilgængelige konto-, trafik-, fakturerings- eller tjenestemetadata, fordi udbyderen ikke har klartekstindholdsnøglen. Hvorvidt en anden part kan få en brugerlegitimation, udnytte en klient eller tvinge videregivelse 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

Server-side kryptering er afhængig af udbyder-kontrollerede nøgler og politik. Udbyderblind kryptering ændrer nøgleopbevaringen, så den dokumenterede tjenestesti mangler en klartekstindholdsnøgle. Det er en stærkere arkitektonisk grænse, men dens kraft afhænger stadig af korrekt klientkode, autentificeret softwarelevering, lydgendannelse, 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, konverterer en menneske-leveret legitimation 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 adgangskode, så valg af legitimationsoplysninger og offlinebekræftelse har stadig betydning.

Hvordan Vaultaire implementerer udbyder-nøgleadskillelse

Vaultaire er en krypteret boks på klientsiden til iPhone. I produktforstand, der ofte markedsføres som "nulviden", er dens snævrere dokumenterede påstand, at Wraxle ikke modtager almindeligt tekstboksindhold 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 én enhed i hele Keychain salt til 600.000 iterationer for at udlede en 256-bit vault-nøgle. Vault-nøglen autentificerer det krypterede indeks og ombryder en separat tilfældig 256-bit hovednøgle. Gendannelsesoplysninger, herunder mønsteret, gemmes i en AES-GCM krypteret Keychain database i stedet for almindelige tekstfiler eller en Vaultaire-konto.

Filkryptering. Hver importeret fil er krypteret med AES-256-GCM under den tilfældige hovednøgle. CryptoKit opretter autentificerede forseglede kasser med friske nonces, og streamingformatet udleder en særskilt nonce for hver bestilte del.

Metadata kryptering. Filnavne, MIME typer, datoer, indeksposter og thumbnail-data er også beskyttet med AES-256-GCM. Vaultaire bruger ikke ChaCha20 til vault-metadata.

Nøglestyring. Vaultaire gemmer sin enheds salt og krypterede gendannelsesdatabase som almindelig iOS Keychain generiske adgangskoder beskyttet med WhenUnlockedThisDeviceOnly tilgængelighedsklasse. Mønsterafledte vault-nøgler og tilfældige hovednøgler behandles i apphukommelsen igennem CryptoKit. Låsning falder aktiv nøgletilstand, men Swift og iOS understøtter ikke en garanti for, at enhver forbigående kopi overskrives.

Hvælving opdagelse. Den normale grænseflade viser ikke en vault-liste. Det lokale format gemmer nøjagtigt 1 krypteret indeksfil for hver boks, og vedligeholdelseskode kan opregne disse filer. En person med app-container-adgang kan derfor tælle krypterede indekser, selvom filnavnene ikke afslører mønstre, navne eller almindeligt tekstindhold. 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:

  1. Glemt adgangskode testen. Hvis e-mail-nulstilling alene gendanner læsbare data, så spørg hvilken udbyder-holdt mekanisme, der genskabte den effektive indholdsnøgle. Brugerholdte gendannelsessætninger, godkendelse af gammel enhed og udbyderkontrollerede nulstillinger er forskellige designs.

  2. Testen af den nye enhed. Hvis en ny enhed gendanner læsbart indhold, skal du identificere den hemmelige eller betroede enhed, der har godkendt den. Alene kontologin foreslår en udbyderkontrolleret gendannelsessti; en gendannelsessætning plus krypterede backup-registreringer kan bevare udbyder-nøgleadskillelse.

  3. 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 offline-legitimationskontrol.

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 anmeldelse er stærkere bevis end et produktmærke.

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 legitimationsoplysninger og gendannelseskonvolutter går tabt. En udbyderstyret nulstilling eller hovednøgle ville svække udbydergrænsen, så gendannelse skal designes separat. Vaultaire genererer en brugerdefineret sætning med 9 separate ord, hvis afledte gendannelsesnøgle åbner en krypteret vault-key-konvolut. Sætningen regenererer eller koder ikke nøglen, og gendannelse af ny enhed kræver også den matchende krypterede CloudKit optegnelser.

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 udbyder-holdt klartekstindholdsnøgle kan denne udbyder ikke bruge sin normale tjenestesti til at dekryptere indholdet. Udnyttelse af enheden, registrering af legitimationsoplysninger, gendannelseskopier og tvungen offentliggørelse er separate ruter, hvis lovlighed og effektivitet varierer afhængigt af jurisdiktion og fakta.

Er nul-kendskab-kryptering langsommere end almindelig kryptering?

AES-256-GCM præstation afhænger ikke af, hvem der har nøglen. Adgangskodebaseret udledning 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 adresserer udbyderens indhold-nøgle-grænse, ikke alle datastrømme. En app kan stadig behandle kontodata, analyser, nedbrudsrapporter, IP-adresser, registreringsstørrelser, timing eller andre servicemetadata. Vaultaire kræver ingen identitetskonto og siger, at dens samtykkebaserede analyser udelukker vault-indhold, mønstre, sætninger og dekrypteringsnøgler; dens privatlivspolitik beskriver de gældende indsamlings- og opbevaringsregler.

Hvordan adskiller nul-kendskab-kryptering sig fra Apples avancerede databeskyttelse?

Apples Advanced Data Protection (ADP), introduceret i iOS 16.2, udvider ende-til-ende-kryptering til yderligere iCloud kategorier og bruger Apple-kontogendannelsesmodellen. Vaultaire holder hvælvingsindhold lokalt som standard og kræver ingen Vaultaire-identitetskonto; valgfri backup, synkronisering og deling bruger krypteret klientside CloudKit poster på brugerens Apple-konto. Vaultaire tilbyder også mønstersepareret vault-adgang og tvangstilstand, med opbevarings- og gendannelsesgrænserne beskrevet i dens plausibel benægtelsesdokumentation.

Sammenfatning

Nul-viden-kryptering behandles bedst som et krav om udbyder-nøgle-separation: Tjenesten har ikke den klartekstnøgle, der er nødvendig for at dekryptere lagret indhold. Det er stærkere end server-side kryptering under udbyder-kontrollerede nøgler, men det er ikke en påstand om, at nøgler kun findes i hukommelsen, at metadata forsvinder, eller at enhver klient og enhed kompromitteres er besejret. Bedøm produktet ud fra dets nøglehierarki, gendannelsesdesign, implementering og uafhængig gennemgang.

Læs sikkerhedsarkitekturen