Kløften mellem påstanden og arkitekturen
Hver cloud-leverandør, der håndterer følsomme data, fremsætter en eller anden version af den samme påstand: "Vi krypterer dine data." Påstanden er næsten altid sand — og næsten altid utilstrækkelig.
LastPass-bruddet i 2022 er den definitive case study. LastPass krypterede deres brugeres adgangskode-skabe. De brugte kryptering. Påstanden var nøjagtig. Og alligevel 25 millioner brugere fik deres krypterede skabe eksfiltreret, og $438 millioner blev efterfølgende stjålet fra LastPass-brugere i efterfølgende kryptovaluta-heists frem til 2025, ifølge forskning fra Coinbase Institutional.
Det britiske Informationskommissærkontor idømte LastPass's britiske enhed en bøde på £1,2 millioner i december 2025 for "manglende implementering af passende tekniske og organisatoriske sikkerhedsforanstaltninger." Krypteringen eksisterede. Sikkerhedsforanstaltningerne levede ikke op til de krævede standarder.
For virksomheder, der evaluerer cloud-privatlivsværktøjer — herunder PII anonymisering platforme — ændrer LastPass-præcedens spørgsmålet om indkøb. Spørgsmålet er ikke "krypterer de vores data?" Det er "kan de dekryptere vores data?"
De fire zero-knowledge spørgsmål, der faktisk betyder noget
Når man evaluerer en leverandørs zero-knowledge påstand, bestemmer fire spørgsmål, om arkitekturen er ægte:
1. Hvor sker nøgleafledning?
I ægte zero-knowledge arkitektur sker afledningen af krypteringsnøgler på klientsiden — i browseren eller desktop-applikationen — før nogen data overføres. Den afledte nøgle bruges til at kryptere data lokalt. Kun krypteret ciphertext rejser til leverandørens servere.
Hvis leverandøren afleder krypteringsnøgler på deres servere, har de nøglerne. Hvis de har nøglerne, kan de dekryptere. Påstanden er teknisk korrekt ("vi krypterer") men vildledende i sin implikation.
2. Har leverandøren nogensinde adgang til plaintext?
Nogle værktøjer krypterer data i hvile, men dekrypterer dem til behandling — kører AI-modeller, analyser, søgeindeksering eller generering af revisionslog. I løbet af behandlingsvinduet er plaintext tilgængelig på leverandørens infrastruktur. Et brud i dette vindue eksponerer dataene i ukrypteret form.
3. Hvad sker der under juridisk proces?
Hvis en regeringsmyndighed sender en stævning til leverandøren, hvilke data kan de producere? En leverandør med server-side nøgler kan blive tvunget til at producere dekrypteret indhold. En leverandør med zero-knowledge arkitektur kan kun producere krypteret ciphertext — selv under juridisk tvang har de intet nyttigt at overlevere.
4. Hvad eksponerer et fuldt serverkompromis?
I en ægte zero-knowledge implementering giver et fuldstændigt brud på leverandørens infrastruktur kun krypterede blobs. Angriberen modtager ciphertext uden nøglerne til at dekryptere det. I en leverandør-kontrolleret nøgleimplementering eksponerer et serverbrud nøglerne sammen med dataene.
LastPass implementeringsfejl
LastPass-bruddet afslørede en specifik implementeringskløft: ældre konti brugte PBKDF2 med så få som 1 iteration til nøgleafledning, i stedet for de anbefalede 600.000 iterationer. Den svagere nøgleafledning gjorde brute-force angreb på de eksfiltrerede skabe beregningsmæssigt mulige.
Dette illustrerer, hvorfor evaluering af zero-knowledge påstande kræver undersøgelse af implementeringsdetaljer, ikke kun arkitektoniske beskrivelser. En leverandør kan bruge et zero-knowledge design, mens de implementerer det svagt. De rigtige spørgsmål at stille dækker både arkitekturen (nøgleafledningssted) og implementeringsstyrken (algoritme og iterationsantal).
Okta-bruddet: En anden fejltilstand
I oktober 2023 afslørede Okta, at 600.000+ kundesupportoptegnelser blev lækket i et brud. Okta er en identitetsplatform — det firma, som mange virksomheder bruger til at sikre adgang til deres andre cloud-værktøjer. Okta-bruddet var en anden fejltilstand end LastPass: ikke en svaghed i zero-knowledge implementeringen, men et kompromis af supportinfrastrukturen, der tilfældigvis indeholdt kundedata.
Den SaaS-brudstigning på 300% i 2024 (AppOmni/CSA) afspejler begge fejltilstande: arkitektoniske svagheder som LastPass og infrastrukturkompromiser som Okta. Zero-knowledge arkitektur adresserer den arkitektoniske fejltilstand. Det eliminerer ikke al brudrisiko, men det sikrer, at selv et fuldstændigt infrastrukturkompromis ikke eksponerer dekrypterbare kundedata.
Hvordan en ægte evaluering ser ud
For indkøbsteams, der vurderer zero-knowledge påstande, er evaluerings-tjeklisten:
Arkitekturanalyse:
- Anmod om dokumentation, der viser, hvor nøgleafledning finder sted (klientside vs. serverside)
- Spørg om krypteringsalgoritmen, nøglelængden og iterationsantallet
- Anmod om bekræftelse af, at plaintext aldrig overføres til leverandørens servere
Brudscenariotest:
- Bed leverandøren beskrive, hvad et fuldt serverkompromis ville eksponere
- Hvis svaret inkluderer noget andet end "krypteret ciphertext, vi ikke kan dekryptere," er påstanden ikke ægte zero-knowledge
Juridisk procesgennemgang:
- Spørg, om leverandøren kan overholde en stævning, der kræver produktion af kundens plaintext
- Ægte zero-knowledge leverandører kan ikke producere, hvad de ikke har
Overholdelsesdokumentation:
- Anmod om leverandørens GDPR Artikel 32 overholdelsesdokumentation
- ISO 27001 certificering (især bilag A kryptografiske kontroller) giver ekstern verifikation af nøglehåndteringspraksis
Den £1,2 millioner LastPass ICO bøde fastslår, at leverandører, der fremsætter krypteringspåstande, er underlagt reguleringsvurdering af, om disse påstande lever op til de krævede standarder. Den samme evalueringsramme, som regulatorer anvender, er tilgængelig for indkøbsteams, før et brud opstår.
Kilder: