By · Last updated 2026-03-03

Zurück zum BlogDSGVO & Compliance

Zero-Knowledge vs. Zero-Trust: Warum Ihr...

LastPass hat die Daten seiner Benutzer ebenfalls verschlüsselt – und trotzdem wurden 438 Millionen Dollar gestohlen.

March 3, 20269 min Lesezeit
zero-knowledgeencryptionGDPRdata protectionSaaS securityLastPass

Die Verschlüsselungs-Illusion

Aktualisiert für 2026

Im Dezember 2022 informierte LastPass seine Nutzer über einen Datenverlust. Die Botschaft klang beruhigend: Passwörter seien „verschlüsselt." Tresorinhalte seien „gesichert."

Bis 2025 wurden über 438 Millionen Dollar von LastPass-Nutzern gestohlen. Der Diebstahl kam direkt aus den angeblich sicheren Tresoren.

Wie? LastPass hielt die Schlüssel.

Ihr Sicherheitsteam muss das wissen, bevor es ein Cloud-Tool wählt. Das gilt für jedes Tool, das sensible Dateien verarbeitet — einschließlich PII-Anonymisierungsplattformen.

Server-seitige vs. Zero-Knowledge-Verschlüsselung

Die meisten Cloud-Tools behaupten, „Ihre Dateien zu verschlüsseln." Sie verwenden jedoch server-seitige Verschlüsselung (SSE). Das bedeutet konkret:

EigenschaftServer-seitige VerschlüsselungZero-Knowledge-Architektur
Wo Verschlüsselung stattfindetAuf dem Server des AnbietersAuf Ihrem Gerät (Browser/Desktop)
Wer die Schlüssel hältDer AnbieterNur Sie
Anbieter kann Inhalt lesenJaNein
Server-Einbruch legt Dateien offenJaNein (nur Chiffriertext)
Anbieter kann zur Herausgabe gezwungen werdenJaNein (sie haben es nicht)
Zugang für BehördenÜber den AnbieterOhne Ihren Schlüssel nicht möglich

LastPass hielt die Schlüssel. Das war der entscheidende Fehler. Angreifer drangen ein und erhielten sowohl den Chiffriertext als auch die Werkzeuge, ihn zu knacken. Sie nutzten Social Engineering, schwache Passwörter und Metadaten alter Konten.

Warum das für DSGVO Artikel 25 wichtig ist

DSGVO Artikel 25 (Datenschutz durch Technikgestaltung) ist klar. Verantwortliche müssen „geeignete technische und organisatorische Maßnahmen" umsetzen. Diese müssen von Anfang an eingebaut sein.

Das Europäische Datenschutzausschuss (EDPB) hat ergänzt, dass dies kryptografische Datenminimerung umfasst. Das System selbst muss den Zugang zu Datensätzen sperren. Zugriffskontrollen allein reichen nicht aus.

Ein Anbieter, der Ihre Schlüssel hält, kann Artikel 25 in seiner strengen Form nicht erfüllen. Hier ist der Grund:

  1. Ein System-Einbruch könnte Ihre Datensätze offenlegen.
  2. Eine Vorladung an den Anbieter könnte Ihre Inhalte herausgeben.
  3. Ein böswilliger Mitarbeiter könnte Ihre Dateien einsehen.
  4. Ein Supply-Chain-Angriff könnte alles offenlegen.

Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) hat dazu Leitlinien veröffentlicht. Ebenso die österreichische Datenschutzbehörde. Beide empfehlen Zero-Knowledge als beste technische Wahl für risikoreiche Verarbeitung.

Der SaaS-Sicherheitscheck

Der AppOmni / Cloud Security Alliance 2024-Bericht stellte einen 300-prozentigen Anstieg von SaaS-Sicherheitsverletzungen von 2022 bis 2024 fest. Die wichtigsten Fakten:

  • Zeit bis zum Einbruch: 9 Minuten (früher gemessen in Stunden)
  • Drittpartei-Beteiligung an Sicherheitsverletzungen: verdoppelt im Jahresvergleich (Verizon DBIR 2025)
  • Conduent-Einbruch: 25,9 Millionen Datensätze offen gelegt (Sozialversicherungsnummern, Krankenakten)
  • NHS-Anbieter-Einbruch: 9 Millionen Patienten betroffen

Politische Versprechen reichen nicht mehr aus. Starke Architektur ist jetzt der Mindeststandard für risikoreiche Verarbeitung. Das gilt ohne Ausnahme.

Wie echte Zero-Knowledge-Architektur aussieht

Ein echtes Zero-Knowledge-System hat diese klaren Merkmale:

1. Clientseitige Schlüsselableitung Ihr Schlüssel kommt aus Ihrem Passwort. Ein speicherintensiver KDF (Argon2id, bcrypt oder scrypt) läuft auf Ihrem Gerät. Der Schlüssel verlässt es nie.

2. Clientseitige Verschlüsselung Ihr Inhalt wird verschlüsselt, bevor er Ihren Browser oder Ihre App verlässt. Der Server erhält nur Chiffriertext. Ohne den Schlüssel ist dieser nutzlos.

3. Keine server-seitige Schlüsselspeicherung Der Anbieter speichert keine Schlüssel, keine Schlüsselteile und keine Schlüssel-Backups. Sie nutzen Ihre eigene Wiederherstellungsphrase, um wieder Zugang zu erhalten.

4. Kryptografische Überprüfbarkeit Das System muss gut dokumentiert sein. Es muss für Audits offen sein. Vage „Ende-zu-Ende-Verschlüsselung"-Behauptungen ohne technische Details sind ein Warnsignal.

Wie anonym.legal Zero-Knowledge umsetzt

anonym.legal's Zero-Knowledge-Login verwendet:

  • Argon2id Schlüsselableitung: 64 MB Speicher, 3 Iterationen — die OWASP-Empfehlung für hochsichere Apps
  • AES-256-GCM-Verschlüsselung: Läuft vollständig in Ihrem Browser oder Desktop-App, bevor Inhalte übertragen werden
  • 24-Wort-BIP39-Wiederherstellungsphrase: Der einzige Weg zur Wiederherstellung des Zugangs — nicht von anonym.legal gespeichert
  • Kein server-seitiger Schlüsselzugang: anonym.legal-Server erhalten nur AES-256-GCM-Chiffriertext, den sie nicht entschlüsseln können

Ein vollständiger anonym.legal-Server-Einbruch würde nur verschlüsselte Blobs liefern. Ohne den Schlüssel jedes Nutzers — der nur auf dessen Gerät existiert — sind diese Blobs nutzlos.

Sehen Sie unsere Sicherheits- und Compliance-Übersicht und Compliance-Dokumentation für vollständige Details.

Die Anbieter-Checkliste

Wenn Sie ein Cloud-Tool für sensible Datensätze wählen, stellen Sie diese Fragen:

Architekturfragen:

  • Wo findet Verschlüsselung statt — auf Ihrem Gerät oder auf dem Server des Anbieters?
  • Wer erstellt die Schlüssel?
  • Wo werden Schlüssel gespeichert?
  • Kann der Anbieter Klartext-Kopien Ihrer Inhalte bei einer Vorladung herausgeben?
  • Was passiert mit Ihren Dateien, wenn der Anbieter aufgekauft wird?

Einbruch-Resilienz-Fragen:

  • Wenn das System des Anbieters vollständig eingebrochen ist, welche Datensätze sind offen gelegt?
  • Wenn ein Mitarbeiter des Anbieters böswillig handelt, welche Inhalte kann er einsehen?
  • Wenn ein Supply-Chain-Angriff den Anbieter trifft, was wird offen gelegt?

Regulatorische Fragen:

  • Kann der Anbieter Dokumentation für DSGVO Artikel 25 vorlegen?
  • Hat ein externer Prüfer das System bewertet?
  • Gibt es ein ISO 27001- oder SOC 2-Zertifikat, das Verschlüsselung abdeckt?

Jeder Anbieter, der die Einbruch-Fragen nicht mit „null — Inhalte sind verschlüsselt, bevor sie Ihr Gerät verlassen" beantworten kann, nutzt server-seitige Verschlüsselung. Sehen Sie unsere FAQ und das Glossar für weitere Definitionen.

Der Anwendungsfall: Deutsche Krankenkasse

Ein Compliance-Beauftragter einer großen deutschen Krankenkasse benötigte ein Cloud-Anonymisierungs-Tool. Die Aufgabe: Versicherungsnehmerbeschwerden verarbeiten. Die Anforderungen des Datenschutzbeauftragten umfassten:

  • Anbieter kann nicht auf Versicherungsnehmerdatensätze zugreifen
  • Keine Verarbeitung außerhalb Deutschlands
  • DSGVO Artikel 32 technische Maßnahmen dokumentiert
  • DPA-meldepflichtiges Einbruchsrisiko ist minimiert

Ein großer US-amerikanischer Anonymisierungs-SaaS scheiterte am ersten Punkt. Ihr Support-Team konnte Benutzer-Tresore zurücksetzen — Beweis für server-seitigen Schlüsselzugang. Ein zweites Tool speicherte verarbeitete Texte 30 Tage für „Prüfpfad"-Zwecke — erneut server-seitiger Zugang.

anonym.legal erfüllte alle vier Kriterien. Der Datenschutzbeauftragte konnte schreiben: „Selbst ein vollständiger Anbieter-Einbruch liefert keine nutzbaren Versicherungsnehmerdatensätze — Schlüssel existieren nur auf unseren Workstations." DSGVO Artikel 32-Dokumentation wurde in vier Stunden abgeschlossen.

Sehen Sie unsere Fallstudien für weitere Beispiele.

Das ICO-Durchsetzungs-Präzedenzfall

Im Dezember 2025 verhängte das britische Information Commissioner's Office eine Geldstrafe gegen die LastPass UK-Einheit in Höhe von £1,2 Millionen. Der Grund: „Versäumnis, geeignete technische und organisatorische Sicherheitsmaßnahmen umzusetzen."

Die Strafe galt nicht für den Einbruch selbst. Sie galt für die Architekturentscheidungen, die den Einbruch so schädlich machten. Schlechte KDF-Einstellungen, offen gelegte Metadaten und server-seitige Schlüsselspeicherung spielten alle eine Rolle.

Regulatoren fragen jetzt: Hat das System den Einbruch-Schaden begrenzt? Zero-Knowledge-Architektur beantwortet das klar. Es ist der beste Beweis für diese Absicht.

Wann Zero-Knowledge-Architektur nicht passt

Zero-Knowledge-Verschlüsselung hat Kompromisse. Diese sind für manche Anwendungsfälle wichtig:

Wiederherstellungskomplexität: Wenn Nutzer ihre Schlüssel verlieren, sind ihre Dateien für immer weg. Es gibt keine Hintertür. Hohe Mitarbeiterfluktuation oder schlechte Schlüsselverwaltung machen das zum echten Risiko.

Kollaborationsreibung: Verschlüsselte Inhalte können nur geteilt werden, wenn die andere Partei die richtigen Entschlüsselungstools hat. Das ist langsamer als ein einfacher Link-Share in Standard-Cloud-Apps.

Regulatorische Grenzfälle: Einige Regionen verlangen Strafverfolgungszugang zu Datensätzen per Gerichtsbeschluss. Zero-Knowledge-Systeme verhindern das durch Design. Das kann rechtliche Probleme in Finanzdienstleistungen oder Telekommunikation verursachen, wo gesetzliche Abfangpflichten gelten.

Rechenaufwand: Argon2id-Schlüsselableitung und AES-256-GCM-Verschlüsselung fügen beide Latenz hinzu. Das ist vor allem bei Echtzeit-Hochvolumen-Verarbeitung relevant.

Für Teams, die täglich Millionen von Dokumenten verarbeiten, kann ein hybrider Ansatz besser geeignet sein. Verschlüsseln Sie nur die sensibelsten Felder. Halten Sie Metadaten zugänglich. Sehen Sie Preispläne für Volumentarife.

Fazit

„Wir verschlüsseln Ihre Dateien" ist kein Sicherheitsversprechen. Es ist ein Marketingausdruck, der geprüft werden muss.

Die echten Fragen sind einfach. Wer hält die Schlüssel? Wo findet Verschlüsselung statt? Was wird offen gelegt, wenn die Systeme des Anbieters eingebrochen werden?

Für Teams, die sensible Datensätze unter DSGVO, HIPAA oder ähnlichen Regeln verarbeiten, formen diese Architekturentscheidungen sowohl Ihr rechtliches Risiko als auch Ihre tatsächliche Einbruchsexposition.

LastPass hat die Inhalte seiner Nutzer verschlüsselt. Zero-Knowledge-Architektur hätte den Einbruch 2022 zu einem Nichtereignis gemacht. Die 438 Millionen Dollar, die von Nutzern gestohlen wurden, waren der Preis einer architektonischen Abkürzung.


anonym.legal nutzt Zero-Knowledge-Architektur für PII-Anonymisierung. Argon2id-Schlüsselableitung läuft in Ihrem Browser oder Desktop-App. AES-256-GCM-Verschlüsselung findet statt, bevor Inhalte Ihr Gerät verlassen. anonym.legal-Server speichern nur Chiffriertext, den sie nicht entschlüsseln können. Erfahren Sie mehr auf unserer Über uns-Seite oder erkunden Sie das Token-System.

Quellen

Bereit, Ihre Daten zu schützen?

Beginnen Sie mit der Anonymisierung von PII mit über 285 Entitätstypen in 48 Sprachen.

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.