Krypteringsillusion
I december 2022 meddelte LastPass et brud. Den officielle udtalelse indeholdt beroligende formuleringer: brugeradgangskoder var "krypterede". Boksdata var "sikret".
I 2025 var der stjålet over $438 millioner fra LastPass-brugere – direkte fra deres angiveligt krypterede bokse.
Hvordan? LastPass sad med nøglerne.
Dette er den afgørende skelnen, som ethvert enterprise-sikkerhedsteam skal forstå, inden de vælger et cloudbaseret værktøj, der håndterer følsomme data – herunder PII-anonymiseringsplatforme.
Serversidekryptering vs. zero-knowledge-arkitektur
De fleste cloudværktøjer, der påstår at "kryptere dine data", bruger serversidekryptering (SSE). Her er hvad det faktisk betyder:
| Egenskab | Serversidekryptering | Zero-knowledge-arkitektur |
|---|---|---|
| Hvor kryptering sker | På leverandørens server | På din enhed (browser/desktop) |
| Hvem besidder nøglerne | Leverandøren | Kun dig |
| Leverandøren kan læse dine data | Ja | Nej |
| Serverbrud eksponerer data | Ja | Nej (kun chiffertekst) |
| Leverandøren kan tvinges til at udlevere data | Ja | Nej (de har dem ikke) |
| Myndigheder/politi kan tilgå | Via leverandøren | Ikke muligt uden din nøgle |
LastPass brugte serversidekryptering med nøgler, de selv kontrollerede. Da angriberne brød ind i deres infrastruktur, fik de adgang til både chifferteksten og midlerne til at dekryptere den – via social manipulation af medarbejdere, brute-force-angreb på svage hovednøgler og udnyttelse af metadata om ældre konti.
Hvorfor dette er relevant for GDPR artikel 25
GDPR artikel 25 (Privacy by Design) kræver, at dataansvarlige implementerer "passende tekniske og organisatoriske foranstaltninger", der integrerer databeskyttelse i behandlingen "som udgangspunkt og som standard".
Europæisk Databeskyttelsesråd (EDPB) har præciseret, at dette inkluderer kryptografisk dataminimering – dvs. at arkitekturen i sig selv bør gøre data utilgængelige for uautoriserede parter, ikke blot beskytte dem via adgangskontroller.
En leverandør, der besidder dine krypteringsnøgler, kan ikke opfylde artikel 25 i den strengeste fortolkning, fordi:
- Et vellykket angreb på deres infrastruktur kunne eksponere dine data
- En juridisk stævning rettet mod leverandøren kunne producere dine data
- En illoyal medarbejder hos leverandøren kunne tilgå dine data
- Et forsyningskædeangreb på leverandørens nøglehåndteringstjeneste kunne eksponere dine data
Både den tyske Bundesbeauftragte für den Datenschutz (BfDI) og det østrigske Datenschutzbehörde har udstedt vejledning om, at zero-knowledge-arkitektur er den foretrukne tekniske implementering til højrisikobehandling.
Virkelighed om SaaS-brud
AppOmni / Cloud Security Alliance 2024-rapporten dokumenterede en 300% stigning i SaaS-brud fra 2022 til 2024. Angrebenes sofistikationsgrad er steget markant:
- Gennemsnitlig tid til brud: 9 minutter (ned fra timer)
- Tredjeparts involvering i brud: fordoblet år over år (Verizon DBIR 2025)
- Conduent-brud: 25,9 millioner poster eksponeret (CPR-numre, sygesikringsdata)
- NHS-leverandørbrud: 9 millioner patienter eksponeret
I dette trusselbillede har arkitektoniske garantier erstattet politikløfter som den minimumssstandard, der er acceptabel for højrisikobehandling.
Hvad ægte zero-knowledge-arkitektur ser ud
En ægte zero-knowledge-arkitektur har disse verificerbare egenskaber:
1. Klientsideafledning af nøgler Krypteringsnøglen afledes fra din adgangskode ved hjælp af en memory-hard KDF (Argon2id, bcrypt eller scrypt) på din enhed. Den afledte nøgle forlader aldrig din enhed.
2. Kryptering på klientsiden Data krypteres, før det forlader din browser eller desktop-applikation. Serveren modtager kun chiffertekst – meningsløs uden nøglen.
3. Ingen serversidelagring af nøgler Leverandøren gemmer ingen nøgler, nøglefragmenter eller nøglesikkerhedskopier. Gendannelse sker via en bruger-kontrolleret gendannelsesfrase.
4. Kryptografisk verificerbarhed Arkitekturen bør kunne dokumenteres og auditeres – ideelt set åben for ekstern gennemgang. Vage påstande om "end-to-end-kryptering" uden tekniske detaljer bør behandles med skepsis.
Sådan implementerer anonym.legal zero-knowledge
anonym.legals zero-knowledge-autentificering bruger:
- Argon2id-nøgleafledning: 64 MB hukommelse, 3 iterationer – de OWASP-anbefalede parametre til sikkerhedsapplikationer med højt sikkerhedsniveau
- AES-256-GCM-kryptering: Anvendes fuldt ud i browseren/desktoppen, inden data transmitteres
- 24-ords BIP39-gendannelsesfrase: Den eneste måde at gendanne adgang på – opbevares ikke af anonym.legal
- Ingen serversideadgang til nøgler: anonym.legal-servere modtager kun AES-256-GCM-chiffertekst uden nøglerne til at dekryptere den
Et komplet anonym.legal-serverbrud ville give angriberne krypterede blobs, der ikke kan dekrypteres uden hver brugers afledte nøgle – som kun eksisterer på deres enhed.
Tjekliste til leverandørevaluering
Når du evaluerer et cloudværktøj, der håndterer følsomme data, bør du stille disse spørgsmål:
Arkitekturspørgsmål:
- Hvor sker kryptering/dekryptering – på din enhed eller på leverandørens server?
- Hvem genererer krypteringsnøglerne?
- Hvor opbevares krypteringsnøglerne?
- Kan leverandøren producere klartekstkopier af dine data som svar på en stævning?
- Hvad sker der med dine data, hvis leverandøren overtages?
Spørgsmål om brudsmodstandsdygtighed:
- Hvis leverandørens komplette infrastruktur kompromitteres, hvilke data er eksponeret?
- Hvis en medarbejder hos leverandøren svigter, hvilke data kan vedkommende tilgå?
- Hvis et forsyningskædeangreb kompromitterer leverandørens infrastruktur, hvad er eksponeret?
Regulatoriske spørgsmål:
- Kan leverandøren levere dokumentation, der opfylder GDPR artikel 25?
- Er arkitekturen gennemgået af en uafhængig sikkerhedsauditor?
- Er der ISO 27001- eller SOC 2-certificering, der dækker krypteringsimplementeringen?
Enhver leverandør, der ikke klart kan svare "nul – dine data er krypteret, inden de forlader din enhed" på spørgsmålene om brudsmodstandsdygtighed, er afhængig af serversidekryptering.
Brugsscenario: Tysk sygeforsikrings due diligence
En complianceansvarlig hos et stort tysk sygeforsikringsselskab (Krankenkasse) havde brug for et cloudbaseret anonymiseringsværktøj til behandling af forsikringstagernes klagelogfiler. DPO'ens tjekliste indeholdt:
- Leverandøren kan ikke tilgå forsikringstagerdata
- Ingen databehandling på infrastruktur uden for Tyskland
- GDPR artikel 32-tekniske foranstaltninger dokumenteret
- DPA-rapporterbar brudrisiko er minimeret
Et fremtrædende USA-baseret anonymiserings-SaaS-produkt fejlede ved det første kriterium: supportteamet kunne nulstille brugerbokse, hvilket antydede serversideadgang til nøgler. Et andet værktøj gemte behandlet tekst i 30 dage til "revisionsspor"-formål – igen serversideadgang.
anonym.legals zero-knowledge-arkitektur opfyldte alle fire kriterier. DPO'en kunne dokumentere: "Selv et komplet leverandørinfrastrukturkompromis giver ingen brugbare forsikringstagerdata – krypteringsnøgler eksisterer kun på vores arbejdsstationer." GDPR artikel 32-dokumentation var færdig på fire timer.
ICO's håndhævelsespræcedens
I december 2025 bødlagde UK's Information Commissioner's Office den britiske LastPass-enhed med £1,2 millioner for "manglende implementering af passende tekniske og organisatoriske sikkerhedsforanstaltninger".
Bøden var ikke for selve bruddet – den var for de arkitektoniske beslutninger, der gjorde bruddet katastrofalt: utilstrækkelige KDF-iterationer for ældre konti, metadataeksponering og det grundlæggende valg om at holde nøgler på serversiden.
Myndigheder evaluerer nu ikke blot, om et brud fandt sted, men om arkitekturen minimerede bruddets konsekvenser. Zero-knowledge-arkitektur er den klareste tekniske demonstration af denne hensigt.
Hvornår zero-knowledge-arkitektur ikke er den rette løsning
Zero-knowledge-kryptering introducerer afvejninger, der har betydning for visse brugsscenarier:
Kompleks gendannelse: Hvis brugere mister deres krypteringsnøgler, er data permanent utilgængeligt. I modsætning til traditionel cloud-lagring, hvor administratorer kan nulstille adgang, er der ingen bagdørsgendannelsesmulighed. Organisationer med høj personaleudskiftning eller dårlig nøglehåndteringspraksis kan finde dette problematisk.
Samarbejdsulemper: Krypterede data kan kun deles, når modtageren har den tilsvarende dekrypteringskapacitet. Dette tilføjer trin sammenlignet med simpel linkdeling i standard cloudtjenester.
Regulatoriske grænsetilfælde: Visse jurisdiktioner kræver retshåndhævelsesadgang til data ved retskendelse. Zero-knowledge-arkitekturer forhindrer dette by design – hvilket kan skabe juridisk eksponering i visse brancher (finansielle tjenester, telekommunikation) med forpligtelser til lovlig aflytning.
Beregningsomkostninger: Klientsideafledning med Argon2id og AES-256-GCM-kryptering tilføjer ventetid, der har betydning for realtidsbehandlingsscenarier i stor skala.
For organisationer, der behandler meget store mængder tekst (millioner af dokumenter om dagen) eller dem med strenge forpligtelser til lovlig aflytning, kan en hybridarkitektur – der kun krypterer de mest følsomme felter og lader metadata være tilgængeligt – være mere praktisk end end-to-end zero-knowledge.
Konklusion
"Vi krypterer dine data" er ikke en sikkerhedsgaranti – det er en markedsføringspåstand, der kræver undersøgelse.
De spørgsmål, der er vigtige: hvem besidder nøglerne, hvor sker krypteringen, og hvad eksponeres, hvis leverandørens infrastruktur kompromitteres?
For organisationer, der behandler følsomme data i henhold til GDPR, HIPAA eller tilsvarende rammer, afgør de arkitektoniske svar på disse spørgsmål både din regulatoriske eksponering og din faktiske brudrisiko.
LastPass krypterede deres brugeres data. Zero-knowledge-arkitektur ville have gjort 2022-bruddet til en ikke-hændelse. De $438 millioner, der blev stjålet fra brugerne, var prisen for den arkitektoniske genvej.
anonym.legal implementerer zero-knowledge-arkitektur til PII-anonymisering: Argon2id-nøgleafledning kører i din browser eller desktop-applikation, AES-256-GCM-kryptering sker, inden data forlader din enhed, og anonym.legal-servere gemmer kun chiffertekst, som de ikke kan dekryptere.
Kilder: