By · Last updated 2026-03-03

Tillbaka till BloggenGDPR & Efterlevnad

Zero-Knowledge mot Zero-Trust-kryptering

LastPass krypterade sina användares data — och ändå stals 438 miljoner dollar. Här är skillnaden mellan serversideskryptering och sann zero-knowledge-arkitektur.

March 3, 20269 min läsning
zero-knowledgeencryptionGDPRdata protectionSaaS securityLastPass

Krypteringsillusion

Uppdaterad för 2026

I december 2022 berättade LastPass om ett intrång. Deras budskap var lugnt: lösenord var "krypterade." Valvinnehåll var "säkrat."

Fram till 2025 hade över 438 miljoner dollar stulits från LastPass-användare. Stölden kom direkt från deras "säkra" valv.

Hur? LastPass hade nycklarna.

Ditt säkerhetsteam måste känna till detta innan de väljer ett molnverktyg. Det gäller alla verktyg som hanterar känsliga filer — inklusive plattformar för PII-anonymisering.

Serversideskryptering mot Zero-Knowledge-kryptering

De flesta molnverktyg säger att de "krypterar dina filer." Men de använder serversideskryptering (SSE). Så här fungerar det:

EgenskapServersideskrypteringZero-Knowledge-arkitektur
Var kryptering skerPå leverantörens serverPå din enhet (webbläsare/skrivbord)
Vem har nycklarnaLeverantörenBara du
Leverantören kan läsa ditt innehållJaNej
Serverintrång exponerar filerJaNej (bara kryptotext)
Leverantören kan tvingas dela innehållJaNej (de har det inte)
Rättsvårdens åtkomstVia leverantörenInte möjlig utan din nyckel

LastPass hade nycklarna. Det var det ödesdigra felet. Angripare bröt sig in och fick både kryptotexten och verktygen för att knäcka den. De använde sociala knep, svag lösenordsbruteforce och gammal kontometadata.

Varför detta spelar roll för GDPR Artikel 25

GDPR Artikel 25 (Privacy by Design) är tydlig. Personuppgiftsansvariga måste använda "lämpliga tekniska och organisatoriska åtgärder." Dessa måste byggas in från början.

Den europeiska dataskyddsstyrelsen (EDPB) har tillagt att detta inkluderar kryptografisk dataminimering. Systemet i sig måste blockera åtkomst till uppgifter. Åtkomstkontroller räcker inte ensamma.

En leverantör som har dina nycklar kan inte uppfylla Artikel 25 i dess striktaste form. Här är varför:

  1. Ett intrång i deras system kan exponera dina uppgifter.
  2. En stämning mot leverantören kan lämna ut ditt innehåll.
  3. En illojal anställd kan läsa dina filer.
  4. En leveranskedjeattack kan exponera allt.

Tysklands federala dataskyddskommissionär (BfDI) har utfärdat vägledning om detta. Det har även den österrikiska Datenschutzbehörde. Båda anser att zero-knowledge är det bästa tekniska valet för högriskbearbetning.

Verklighetscheck för SaaS-intrång

AppOmni/Cloud Security Alliance 2024-rapporten visade en 300% ökning av SaaS-intrång från 2022 till 2024. Nycklelfakta:

  • Tid till intrång: 9 minuter (mättes tidigare i timmar)
  • Tredjeparters roll i intrång: fördubblades år för år (Verizon DBIR 2025)
  • Conduent-intrång: 25,9 miljoner poster exponerade (personnummer, hälsofiler)
  • NHS-leverantörsintrång: 9 miljoner patienter exponerade

Policydokument räcker inte längre. Stark arkitektur är minimikravet. Detta gäller all högriskbearbetning.

Hur sann Zero-Knowledge-arkitektur ser ut

Ett riktigt zero-knowledge-system har dessa tydliga egenskaper:

1. Klientsidesnyckelhärledning Din nyckel kommer från ditt lösenord. En minnesintensiv KDF (Argon2id, bcrypt eller scrypt) körs på din enhet. Nyckeln lämnar den aldrig.

2. Klientssideskryptering Ditt innehåll krypteras innan det lämnar din webbläsare eller app. Servern får bara kryptotext. Utan nyckeln är den kryptotexten värdelös.

3. Ingen serversideslagring av nycklar Leverantören har inga nycklar, inga nyckeldelar och inga nyckelbackuper. Du använder din egen återställningsfras för att återfå åtkomst.

4. Kryptografisk verifierbarhet Systemet måste vara väldokumenterat. Det måste vara öppet för revision. Vaga påståenden om "end-to-end-kryptering" utan tekniska detaljer är en varningssignal.

Hur anonym.legal implementerar Zero-Knowledge

anonym.legal:s zero-knowledge-inloggning använder:

  • Argon2id-nyckelhärledning: 64 MB minne, 3 iterationer — OWASP:s val för högsäkerhetsappar
  • AES-256-GCM-kryptering: Körs helt i din webbläsare eller skrivbordsapp innan något innehåll skickas
  • 24-ords BIP39-återställningsfras: Det enda sättet att återfå åtkomst — lagras inte av anonym.legal
  • Ingen serversidesnyckeltillgång: anonym.legal:s servrar får bara AES-256-GCM-kryptotext de inte kan dekryptera

Ett fullständigt anonym.legal-serverintrång skulle bara ge krypterade blobbar. Utan varje användares nyckel — som bara finns på deras enhet — är dessa blobbar värdelösa.

Se vår säkerhets- och efterlevnadsöversikt och efterlevnadsdokumentation för fullständiga detaljer.

Checklista för leverantörsutvärdering

När du väljer ett molnverktyg för känsliga uppgifter, ställ dessa frågor:

Arkitekturfrågor:

  • Var sker kryptering — på din enhet eller på leverantörens server?
  • Vem skapar nycklarna?
  • Var lagras nycklar?
  • Kan leverantören lämna ut klartext av ditt innehåll om de får en stämning?
  • Vad händer med dina filer om leverantören köps upp?

Frågor om intrångsmotståndskraft:

  • Om leverantörens system är helt komprometterat, vilka uppgifter exponeras?
  • Om en anställd hos leverantören agerar illojalt, vilket innehåll kan de se?
  • Om en leveranskedjeattack drabbar leverantören, vad exponeras?

Regulatoriska frågor:

  • Kan leverantören visa dokumentation för GDPR Artikel 25?
  • Har en extern revisor granskat systemet?
  • Finns det en ISO 27001- eller SOC 2-certifiering som täcker kryptering?

Vilken leverantör som helst som inte kan svara "noll — innehåll är krypterat innan det lämnar din enhet" på intrångsfrågorna använder serversideskryptering. Se vår FAQ och ordlista för fler termer.

Användningsfallet: Due diligence hos ett tyskt sjukförsäkringsbolag

En efterlevnadsansvarig på ett stort tyskt sjukförsäkringsbolag (Krankenkasse) behövde ett molnanonymiseringsverktyg. Uppdraget: behandla försäkringstagares klagomålsloggar. DPO:n hade fyra krav:

  • Leverantören får inte komma åt försäkringstagaruppgifter
  • Ingen bearbetning utanför Tyskland
  • GDPR Artikel 32 tekniska åtgärder dokumenterade
  • DPA-rapporterbar intrångsrisk minimerad

Ett stort amerikanskt anonymiserings-SaaS misslyckades med den första punkten. Deras supportteam kunde återställa användarvalv — bevis på serversidesnyckeltillgång. Ett andra verktyg behöll bearbetad text i 30 dagar för "revisionsspår" — återigen serversidesåtkomst.

anonym.legal uppfyllde alla fyra krav. DPO:n kunde skriva: "Även ett fullständigt leverantörsintrång ger inga användbara försäkringstagaruppgifter — nycklar finns bara på våra arbetsstationer." GDPR Artikel 32-dokumentation var klar på fyra timmar.

Se våra fallstudier för fler verkliga exempel.

ICO:s verkställighetspraxis

I december 2025 bötfällde UK Information Commissioner's Office den brittiska LastPass-enheten med £1,2 miljoner. Anledning: "underlåtenhet att implementera lämpliga tekniska och organisatoriska säkerhetsåtgärder."

Böterna gällde inte intrånget i sig. De gällde arkitekturvalen som gjorde intrånget så skadligt. Dåliga KDF-inställningar, exponerade metadata och serversidesnyckeltillgång spelade alla en roll.

Tillsynsmyndigheter frågar nu: begränsade systemet intrångsskadan? Zero-knowledge-arkitektur svarar på det tydligt. Det är det bästa beviset på den avsikten.

När Zero-Knowledge-arkitektur inte är rätt lösning

Zero-knowledge-kryptering har avvägningar. Dessa spelar roll för vissa användningsfall:

Återställningskomplexitet: Om användare förlorar sina nycklar är deras filer borta för gott. Det finns ingen bakdörr. Hög personalomsättning eller svaga nyckelhanteringsvanor gör detta till en verklig risk.

Samarbetsfriktioner: Krypterat innehåll kan bara delas om den andra parten har rätt dekrypteringsverktyg. Det är långsammare än en enkel länkdelning i vanliga molnappar.

Regulatoriska kantfall: Vissa regioner kräver att brottsbekämpning kan komma åt uppgifter via domstolsbeslut. Zero-knowledge-system blockerar detta av design. Det kan orsaka juridiska problem inom finansiella tjänster eller telekommunikation, där regler om laglig avlyssning gäller.

Beräkningsoverhead: Argon2id-nyckelhärledning och AES-256-GCM-kryptering lägger båda till fördröjning. Det spelar störst roll för realtids- och högskalerad bearbetning.

För team som bearbetar miljontals dokument per dag kan ett hybridupplägg fungera bättre. Kryptera bara de känsligaste fälten. Håll metadata öppen. Se prissättningsplaner för volymtier.

Slutsats

"Vi krypterar dina filer" är inte ett säkerhetslöfte. Det är en marknadsföringsfras som kräver granskning.

De verkliga frågorna är enkla. Vem har nycklarna? Var sker kryptering? Vad exponeras om leverantörens system drabbas av intrång?

För team som bearbetar känsliga uppgifter under GDPR, HIPAA eller liknande regler formar dessa arkitekturval både din juridiska risk och din faktiska intrångsexponering.

LastPass krypterade sina användares innehåll. Zero-knowledge-arkitektur skulle ha gjort 2022 års intrång till en icke-händelse. De 438 miljoner dollar som stals från användare var priset för ett arkitekturalt genvägsval.


anonym.legal använder zero-knowledge-arkitektur för PII-anonymisering. Argon2id-nyckelhärledning körs i din webbläsare eller skrivbordsapp. AES-256-GCM-kryptering sker innan något innehåll lämnar din enhet. anonym.legal:s servrar lagrar bara kryptotext de inte kan dekryptera. Läs mer på vår om-sida eller utforska tokensystemet.

Källor

Redo att skydda din data?

Börja anonymisera PII med 285+ entitetstyper på 48 språk.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.