DSGVO-konforme Blockchains: Lösungen | IT-Medienrecht

DSGVO und Blockchain: Praxistaugliche Kompatibilität durch Architektur und Governance

Die DSGVO fordert Datenminimierung, Zweckbindung, Transparenz und die Beachtung von Betroffenenrechten. Blockchains hingegen basieren auf Unveränderlichkeit, Replikation und Offenheit. Dieser scheinbare Widerspruch ist jedoch nicht zwingend unüberbrückbar.

Mit einer durchdachten Architektur, einer präzisen Rollenverteilung, eIDAS-gestützten Nachweisen und klaren Vertrags- und Governance-Regeln lassen sich die Kernpflichten der DSGVO auch in Blockchain-Projekten erfüllen. Dieser Beitrag skizziert praxistaugliche Muster, beleuchtet typische Irrtümer und bietet eine Checkliste für Projekte, die bis 2025 belastbar sein müssen.

Ausgangslage: DSGVO-Pflichten und technische Eigenschaften der Blockchain in Einklang bringen

• Grundprinzipien (Art. 5)
• Rechtsgrundlagen (Art. 6, Art. 9)
• Transparenz- und Informationspflichten (Art. 13/14)
• Technische und organisatorische Maßnahmen (Art. 25, 32)
• Umfassende Betroffenenrechte (Auskunft, Berichtigung, Löschung, Einschränkung, Widerspruch)

• Unveränderlichkeit
• Dezentrale Speicherung
• Verifikation per Konsens
• Globale Replikation

• Datenminimierung versus vollständige, dauerhafte Speicherung.
• Löschung und Berichtigung versus Unveränderlichkeit.
• Eindeutige Verantwortlichkeit versus verteilte Governance und das Problem, dass sich „Niemand ist verantwortlich“ fühlt.
• Internationale Datenflüsse (weltweite Nodes) versus Transferregime.

Die Lösung dieser Konflikte liegt selten in der Entscheidung "Blockchain oder DSGVO", sondern vielmehr in der Gestaltung der Architektur. Persönliche Daten sollten grundsätzlich nicht als Klartext on-chain gespeichert werden. Stattdessen gehören sie in kontrollierte Off-Chain-Speicher. On-chain verbleiben dann nur minimal notwendige Anker wie Hashes, Commitments, Referenzen oder Zustandsmarker. Ein Beispiel für die Bedeutung einer sorgfältigen Datenverarbeitung und -minimierung finden Sie in unserem Beitrag zum Thema Achtung vor Analytics ohne Anonymisierung.

Diese Sichtweise wird seit Jahren von europäischen Fachstellen gestützt und konkretisiert. Dazu zählen unter anderem die CNIL mit Richtlinien und Praxisempfehlungen zum datenschutzkonformen Blockchain-Einsatz sowie Studien des Europäischen Parlaments und des EU Blockchain Observatory.

Diese Institutionen betonen, dass Permissioned-Architekturen die Kontrolle über Rollen und Datentransfers erleichtern. In Permissionless-Netzen ist die Compliance anspruchsvoller, aber nicht ausgeschlossen. Hierbei müssen personenbezogene Inhalte durch geeignete Konstrukte wie Commitments, selektive Offenlegung und Kryptografie ersetzt werden (cnil.fr, Europäisches Parlament, EU Blockchain Observatory and Forum).

Ein weiterer Baustein für die rechtliche Anschlussfähigkeit ist die eIDAS-Verordnung 2. Elektronische Ledger sind darin als Beweis-Infrastruktur rechtlich verortet. Qualifizierte elektronische Ledger genießen eine Vermutung für die Integrität und die korrekte zeitliche Reihenfolge ihrer Einträge. Dies erhöht die Beweiskraft gut gestalteter Ketten, ersetzt jedoch nicht die DSGVO-Pflichten (EUR-Lex, european-digital-identity-regulation.com, EY).

Architektur- und Technikmuster: Off-Chain-First, Commitments und selektive Offenlegung

Off-Chain-First und On-Chain-Minimum

Personenbezogene Daten werden primär außerhalb der Blockchain verarbeitet. Hierfür kommen Systeme wie Datenbanken, Objektspeicher oder WORM-Repositories zum Einsatz, deren Zugriffe, Speicherfristen und Löschungen steuerbar sind. On-chain werden ausschließlich verifizierende Marker gehalten, wie kryptografische Hashes, Merkle-Root-Commitments, Zustands-IDs oder Token-Identifier ohne direkten Personenbezug.

Der Hash dient als Unveränderlichkeitsnachweis, während der Personenbezug off-chain verbleibt. Die CNIL empfiehlt diese Trennung ausdrücklich und merkt an, dass Permissioned-Netzwerke die Governance erleichtern (cnil.fr).

Pseudonymisierung statt Anonymisierung

Öffentliche Schlüssel, Adressen oder Transaktions-IDs sind in vielen Konstellationen personenbezogene Daten, da sie mittelbar einer natürlichen Person zugeordnet werden können. Dies bedeutet, dass echte Anonymisierung selten, Pseudonymisierung hingegen häufiger erreicht wird.

Architekturen reagieren darauf mit wechselnden Schlüsseln, Privacy-Enhancements (z. B. Adress-Rotation, Payment-Codes) und vor allem mit der Verlagerung sensibler Inhalte off-chain. Studien und Workshops warnen vor einer falschen Sicherheit: Oft genügen bereits Metadaten zur Re-Identifizierung (Europäisches Parlament, ResearchGate).

Commitments und Nachweise

Anstatt Daten direkt zu veröffentlichen, werden Commitments geschrieben. Dabei handelt es sich um Hashes auf strukturierte Datensätze, Merkle-Bäume oder akkumulierte Zustände. Eine spätere Offenlegung ist selektiv möglich, beispielsweise durch Proof-of-Inclusion oder Zero-Knowledge-Nachweise.

Die Kette belegt Integrität und Zeitpunkt. Off-chain werden die Daten gezielt gelöscht, berichtigt oder gesperrt. Auf diese Weise lassen sich Datensparsamkeit und Nachweisinteressen effektiv miteinander verbinden.

Selektive Offenlegung und Zero-Knowledge

Zero-Knowledge-Nachweise (z. B. zk-SNARKs) ermöglichen es, Eigenschaften eines Datums zu beweisen, ohne das Datum selbst offenzulegen. Beispiele hierfür sind der Nachweis, dass eine Person über 18 Jahre alt ist, eine Adresse in Land X besitzt oder eine Berechtigung Y hat.

In der Praxis wird dies häufig mit verifizierbaren Berechtigungsnachweisen (verifiable credentials) kombiniert. Ein Aussteller signiert Attribute, der Inhaber legt gegenüber einem Prüfer nur die relevanten Attribute offen, idealerweise mit ZK-Stichproben (Range-Proofs, Membership-Proofs). Dies erlaubt Identitäts- und Berechtigungsprüfungen ohne zentrale Datenhaltung.

Redaktion statt „Löschen auf Kette“

Unterstützen Ketten redaktionsfähige Strukturen (z. B. per Governance-Beschluss, redactable ledgers / Chameleon-Hashes), sind Korrekturen möglich. Rechtlich ist zu beachten, dass ein technisches Überschreiben nicht zwingend erforderlich ist. Oft genügt es, wenn personenbezogene Inhalte nie on-chain standen oder durch kryptografische Entkopplung und Löschung der Off-Chain-Daten faktisch unerreichbar werden.

Die DSGVO fordert Wirksamkeit, nicht zwingend eine Bit-Löschung an jedem Speicherort.

Datenbank- und Urheberrechte mitdenken

Viele blockchain-gestützte Register enthalten schutzfähige Datenbanken. Extraktionen, Spiegelungen und Kopien durch Miner oder Validatoren können hierbei bestehende Rechte berühren. Gleichzeitig entstehen an Smart-Contract-Code urheberrechtliche Positionen. Die Zweckübertragung (z. B. für Audit, Fork, Re-Use) muss vertraglich geregelt werden. Diese Fragen sind parallel zu den DSGVO-Anforderungen zu adressieren.

eIDAS-gestützte Nachweise

Qualifizierte Zeitstempel und Siegel lassen sich vor die on-chain-Schicht ziehen. Off-chain-Dokumente, Logs und Zustandsnachweise werden qualifiziert signiert oder gestempelt. Die Hashes werden zusätzlich in ein Ledger geschrieben. So entsteht eine doppelte Beweiskaskade, die einen Trust-Service und das Ledger kombiniert.

eIDAS 2 verleiht qualifizierten elektronischen Ledgers eine gesetzliche Vermutung für deren Integrität und Chronologie (EUR-Lex, european-digital-identity-regulation.com).

Betroffenenrechte und „Unveränderlichkeit“: Praktische Lösungen für Auskunft, Berichtigung, Löschung

Auskunft (Art. 15)

Auskunftspflichten betreffen vor allem Off-Chain-Bestände und Protokolle. Empfehlenswert sind Datenkataloge, die für jede on-chain-Referenz den zugehörigen Off-Chain-Speicher verweisen (Data Lineage). On-chain-Hashes werden in der Antwort erklärt, ohne sensible Inhalte offenzulegen.

Für verteilte Netze ist zu definieren, welche Stelle Auskunft erteilt. Dies kann ein Lead-Controller oder eine Koordinationsstelle sein, die vertraglich festgelegt wird.

Berichtigung (Art. 16)

Ist ein off-chain gespeicherter Datensatz fehlerhaft, wird er dort berichtigt. Die neue Version erhält einen neuen Hash. On-chain kann ein Korrektur-Marker eingetragen werden (z. B. „superseded by state X“).

Ein tatsächlich auf der Kette gespeicherter Klartext sollte vermieden werden. Andernfalls bleibt nur eine Korrekturanmerkung plus die Unterbindung der weiteren Nutzung durch Governance-Regeln.

Löschung (Art. 17)

Löschen bedeutet, Daten wirksam zu entfernen oder unbrauchbar zu machen. In Blockchain-Architekturen werden personenbezogene Inhalte daher idealerweise gar nicht erst auf die Kette geschrieben. Für Off-Chain-Bestände sind Löschroutinen verbindlich zu definieren.

On-chain wird eine Referenz unbrauchbar, wenn der Off-Chain-Datensatz nicht mehr existiert oder der Entschlüsselungsschlüssel vernichtet wurde (Krypto-Shred). CNIL und weitere Stellen betonen, dass Permissioned-Umgebungen mit klaren Lösch- und Zugriffspflichten die praktische Umsetzung erleichtern (cnil.fr).

Einschränkung/Widerspruch (Art. 18/21)

Eine Einschränkung der Verarbeitung lässt sich als „Freeze“ im Off-Chain-System abbilden. On-chain kann ein Flag oder ein Zustandswechsel gesetzt werden, der weitere Verarbeitung verhindert. Beim Widerspruch ist zu prüfen, ob die Rechtsgrundlage berechtigte Interessen oder eine Einwilligung war. Bei berechtigten Interessen ist die Abwägung zu aktualisieren und gegebenenfalls zugunsten des Betroffenen anzupassen.

Datenübertragbarkeit (Art. 20)

Die Portabilität bezieht sich auf die vom Betroffenen bereitgestellten Daten. Technisch lassen sich exportfähige Off-Chain-Profile (maschinenlesbare Formate, APIs) bereitstellen. On-chain-Marker spielen hierfür regelmäßig keine Rolle. Wichtig ist, dass die Portabilität nicht mit einer Pflicht zur Offenlegung von Geschäftsgeheimnissen oder Rechten Dritter verwechselt wird.

Besondere Kategorien (Art. 9)

Gesundheitsdaten, politische Meinungen sowie biometrische oder genetische Daten unterliegen strengsten Anforderungen. Solche Inhalte gehören nicht in öffentlich einsehbare Register. Wo eine Verarbeitung nötig ist, beispielsweise für Berechtigungsnachweise in Gesundheits-Szenarien, sind Zero-Knowledge / selektive Offenlegung und starke Off-Chain-Kontrollen Pflicht.

Governance, Rollen, Transfers: Verantwortlichkeit definieren, internationale Risiken beherrschen

Rollenmodell

In Permissioned-Netzen ist regelmäßig ein oder sind mehrere Verantwortliche identifizierbar (Konsortium, Betreiber, Use-Case-Owner). Je nach Konstellation liegt eine gemeinsame Verantwortlichkeit nahe (Art. 26), da über Zwecke und Mittel gemeinsam entschieden wird. Validatoren und Mitglieder können als Auftragsverarbeiter eingebunden werden, sofern sie weisungsgebunden handeln.

In Permissionless-Netzen ist die Rollenzuordnung schwieriger. Praktikabel sind Konstruktionen, die den konkret angebotenen Dienst (z. B. eine Wallet- oder Registry-Anwendung) als eigenständige Verantwortlichkeit konzipieren, während das zugrundeliegende Protokoll als „Infrastruktur“ behandelt wird. CNIL weist darauf hin, dass eine klare Verantwortlichenbestimmung unverzichtbar ist – „niemand ist verantwortlich“ ist kein DSGVO-Modell (cnil.fr).

Rechtsgrundlagen und DPIA

Für viele Register-Anwendungen kommen berechtigte Interessen in Betracht (Art. 6 Abs. 1 lit. f). Bei Identitäts- oder Zertifikatsprozessen können gegebenenfalls rechtliche Pflichten oder Verträge als Grundlage dienen. In risikoreichen Szenarien ist eine Datenschutz-Folgenabschätzung (DPIA) angezeigt. Diese bewertet systematisch die Risiken (Re-Identifizierbarkeit, Krypto-Schlüsselverlust, Chain-Forks, internationale Replikation) und die vorgesehenen Abhilfen (Off-Chain-Kontrollen, ZK-Nachweise, Zugriffskontrollen, Audit).

Internationale Datentransfers

Öffentliche Ketten replizieren Daten global, was die Regeln für Drittlandstransfers auslöst. CNIL empfiehlt deshalb Permissioned-Netze, in denen der Node-Standort kontrolliert und vertraglich über Standardvertragsklauseln oder BCR abgesichert werden kann.

In öffentlichen Netzen ist dies kaum umfassend sicherzustellen. Daher gilt umso mehr: Keine personenbezogenen Inhalte on-chain, sondern ausschließlich nicht-personenbeziehbare Commitments (cnil.fr).

eIDAS-Brücke und Beweisführung

eIDAS 2 stärkt die rechtliche Wirkung elektronischer Ledger. Ein elektronisches Ledger darf als Beweis nicht allein wegen seiner Form zurückgewiesen werden. Bei qualifizierten Ledgers bestehen Vermutungen für Integrität und korrekte zeitliche Reihenfolge.

Für forensische Nachweise oder Compliance ist es sinnvoll, Trust-Services (qualifizierter Zeitstempel/Siegel) mit dem Ledger zu kombinieren. So werden Doppel-Anker (Trust-Service + Chain) geschaffen (EUR-Lex, european-digital-identity-regulation.com).

Typische Vertragsbausteine

Bei der Vertragsgestaltung sind folgende Punkte essenziell:

• Rollen und Verantwortlichkeit (Art. 26-Abkommen / joint controllership; AVV nach Art. 28).
• Datenkategorien, die Abgrenzung zwischen On-Chain und Off-Chain, Retention, Löschung, sowie der Schlüssellebenszyklus (Erzeugung, Rotation, Vernichtung).
• Sicherheits- und Auditklauseln, eIDAS-Trust-Services, Beweisführung (Zeitstempel/Siegel, Hash-Register), und Regeln für Fork- oder Incident-Management.
• Regelungen zu Drittlandtransfers und Node-Standorten (nur in Permissioned-Netzen), Standardvertragsklauseln/BCR und Subverarbeiterketten.
• Rechte an Smart-Contract-Code und Datenbanken, Zweckübertragung sowie Regeln für Fork-Reuse.

Prüfpunkte/Checkliste (kompakt)

Für eine DSGVO-konforme Blockchain-Implementierung sollten folgende Punkte beachtet werden:

1. On-chain nur Commitments oder Zustände speichern – keine Klardaten, keine „besonderen Kategorien“.
2. Off-Chain-Speicher mit klaren Lösch- und Berichtigungsroutinen, Zugriffskontrollen, Logging und Retention managen.
3. ZK / Verifiable Credentials für selektive Offenlegung nutzen; Adress-Rotation und Key-Hygiene implementieren.
4. Vereinbarungen für Verantwortliche, Auftragsverarbeiter oder joint controllership treffen; eine Datenschutz-Folgenabschätzung mit Risikominderung durchführen.
5. Internationale Aspekte: Nodes und Transfers steuern oder personenbezogene Daten vollständig off-chain halten.
6. eIDAS-Trust-Services und Ledger als Nachweiskaskade kombinieren.
7. Umfassende Dokumentation: Datenkatalog, Policy-Stack, Incident- und Key-Management.

Fazit

DSGVO-konforme Blockchains sind kein Widerspruch, sondern das Ergebnis eines durchdachten Designs, einer klaren Governance und einer präzisen Beweisdisziplin. Wer personenbezogene Inhalte strikt off-chain hält, on-chain nur verifizierende Marker nutzt, selektive Offenlegung ermöglicht und Verantwortlichkeiten klar regelt, kann die klassischen Konflikte aus Datenminimierung, Löschung und Internationalität auflösen.

eIDAS 2 schlägt dabei die Brücke zur gerichtsfesten Beweisführung. Ein sauberer Mix aus qualifizierten Zeitstempeln, Siegeln und elektronischen Ledgers schafft Nachweise, die fachlich tragfähig und rechtlich anschlussfähig sind. Entscheidend bleibt der Nachweis im Detail – Korpus, Schlüssel, Protokolle, Policies und Verträge – nicht die bloße Schlagwort-Kompatibilität.