Nepomuk als Löschsystem: Ein konzeptioneller Entwurf zu Architektur, Triggern und der Entscheidung vor der Krise
Von DerSchneider
Hinweis: Dieser Text ist ein konzeptioneller Entwurf. Er beschreibt eine Architekturidee, kein existierendes Produkt. Die genannten Bausteine (Crypto-Shredding, Duress-PIN, Dead-Man’s-Switch) existieren einzeln, aber ihre Integration zu einem „Nepomuk-System“ in der beschriebenen Form ist bislang nicht implementiert. Wo im Folgenden von „einem Nepomuk-System“ die Rede ist, ist stets ein hypothetisches System gemeint, nicht ein real verfügbares.
Einleitung
Es gibt Momente, in denen ein Geheimnis gefährlicher wird, sobald es preisgegeben wird. Nicht der Besitz der Daten ist dann das Risiko, sondern ihre Offenlegung. Genau hier setzt der Gedanke an, der in diesem Entwurf durchdacht wird: die Übertragung des Nepomuk-Prinzips – „lieber sterben als preisgeben“ – auf ein technisches Löschsystem für verschlüsselte Dateien.
Dieser Artikel beschreibt, wie ein solches System funktionieren würde, wann sein Einsatz rational wäre und welche Architektur nötig wäre, damit es nicht zur Datenkatastrophe wird. Es geht nicht um ein Produkt, das man kaufen kann. Es geht um ein Designprinzip, das sich aus einer historischen Legende, kryptographischen Verfahren und einer klaren Risikoabwägung zusammensetzt. „Lieber sterben als preisgeben“ ist dabei keine ethische Empfehlung, sondern die Beschreibung eines Prinzips, dessen technische Umsetzung hier durchdacht wird.
Das Prinzip: Entscheidung vor der Krise
Die Nepomuk-Legende handelt von einem Mann, der unter Folter schwieg. Der historische Johannes von Pomuk starb 1393 im Machtkampf zwischen König Wenzel IV. und der Kirche, doch die Legende machte ihn zum Märtyrer des Beichtgeheimnisses. Das entscheidende Moment: Er traf seine Entscheidung nicht in der Folterkammer. Er hatte sie vorher getroffen.
Genau das wäre der Kern eines technischen Nepomuk-Systems. Der Nutzer würde in Sicherheit definieren, unter welchen Bedingungen gelöscht wird. Das System würde diese Regel unter Druck vollstrecken. Es gäbe keine Hintertür, keinen Admin-Override, keine letzte Instanz, die doch noch entscheidet, die Daten herauszugeben. Die Entscheidung wäre gefallen, bevor die Krise beginnt.
Das ist der Unterschied zwischen einem Passwort, das man unter Folter doch nennt, und einem Schlüssel, der physisch nicht mehr existiert. Der Mensch kann brechen. Ein überschriebener Schlüssel nicht.
Das Angreifermodell: Wogegen das System schützt
Bevor die Architektur Sinn ergibt, muss klar sein, gegen wen sie schützt. Das Angreifermodell ist im Entwurf implizit: ein physischer Angreifer mit Zugriff auf das Gerät, aber ohne Kenntnis des Duress-PINs. Gegen diesen Angreifer hilft die Kombination aus HSM, Quorum und Grace Period.
Gegen einen Angreifer, der das Gerät zerstört oder den Nutzer vor der Trigger-Betätigung überwältigt, hilft das System nicht. Ebenso wenig gegen einen staatlichen Angreifer mit forensischen Ressourcen, der das Gerät vor der Löschung analysiert, oder gegen einen Insider, der die Trigger-Konfiguration kennt. Das Angreifermodell bestimmt, welche Trigger sinnvoll sind – und welche Illusion bleiben. Ein System, das gegen alles schützen soll, schützt gegen nichts.
Die technische Grundlage: Crypto-Shredding
Ein Nepomuk-Löscher würde keine Dateien löschen. Er würde den Schlüssel löschen, mit dem die Dateien entschlüsselt werden. Dieses Verfahren heißt Crypto-Shredding und wäre der eigentliche Mechanismus, der das Prinzip technisch umsetzbar macht.
Die Logik ist einfach: Daten werden mit einem Data Encryption Key (DEK) verschlüsselt. Der DEK wird wiederum mit einem Key Encryption Key (KEK) verschlüsselt, der in einem Hardware-Sicherheitsmodul (HSM) oder einer Secure Enclave liegt. Wird der KEK überschrieben, ist der DEK unentschlüsselbar. Die Daten blieben physisch auf dem Datenträger vorhanden – als Kryptotext, der ohne Schlüssel keinen Informationswert mehr hat.
Dieses Verfahren ist in der Sicherheitsforschung etabliert. Apple nutzt ein verwandtes Verfahren – das Verwerfen der Schlüssel im sogenannten effaceable storage bei „Alle Inhalte und Einstellungen löschen“ –, doch die Gleichsetzung mit dem hier beschriebenen Crypto-Shredding ist eine Analogie, keine technische Identität . Der Vorteil gegenüber physischem Überschreiben wäre: Die Löschung dauerte Millisekunden, unabhängig von der Datenmenge, und hinterließe keine lesbaren Reste des Klartexts.
Für ein Nepomuk-System würde das bedeuten: Die Löschung wäre schnell, leise und forensisch wirksam – wenn die Integration gelingt. Ein Angreifer, der das Gerät beschlagnahmt, fände einen Datenträger voller Zufallsdaten. Er könnte sie nicht entschlüsseln, weil der Schlüssel nicht mehr existiert.
Ein minimales Code-Beispiel
Das folgende Python-Beispiel zeigt den Kernmechanismus in seiner einfachsten Form. Es ist bewusst kein vollständiges Nepomuk-System – es zeigt nur: DEK verschlüsselt Daten, KEK verschlüsselt DEK, KEK überschreiben = Daten tot.
python
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
class CryptoShredDemo:
def __init__(self):
# KEK: Key Encryption Key (in der Realität: HSM)
self.kek = AESGCM.generate_key(bit_length=256)
# DEK: Data Encryption Key (verschlüsselt die Daten)
self.dek = AESGCM.generate_key(bit_length=256)
# DEK unter KEK "verpackt" (Envelope Encryption)
self.encrypted_dek = self._wrap_dek()
def _wrap_dek(self):
kek_cipher = AESGCM(self.kek)
nonce = os.urandom(12)
return nonce + kek_cipher.encrypt(nonce, self.dek, None)
def _unwrap_dek(self):
kek_cipher = AESGCM(self.kek)
nonce = self.encrypted_dek[:12]
return kek_cipher.decrypt(nonce, self.encrypted_dek[12:], None)
def encrypt_secret(self, plaintext: bytes) -> bytes:
dek = self._unwrap_dek()
nonce = os.urandom(12)
return nonce + AESGCM(dek).encrypt(nonce, plaintext, None)
def decrypt_secret(self, ciphertext: bytes) -> bytes:
dek = self._unwrap_dek()
nonce = ciphertext[:12]
return AESGCM(dek).decrypt(nonce, ciphertext[12:], None)
def shred(self):
"""Crypto-Shredding: KEK überschreiben → DEK unentschlüsselbar."""
self.kek = b'\x00' * 32
self.encrypted_dek = None
Was das Beispiel zeigt: Die Envelope-Encryption-Struktur (DEK/KEK) ist der Kern des Crypto-Shreddings. Dieses Muster ist real und wird unter anderem von Conduktor Gateway für Kafka eingesetzt . shred() ist der entscheidende Punkt: Es wird nicht der Chiffretext gelöscht, sondern der Schlüssel, der ihn lesbar macht. Ohne KEK ist der DEK unentschlüsselbar, ohne DEK sind die Daten Zufallsbytes.
Wichtiger Hinweis: Das Python-Beispiel ist nicht forensisch sicher. Python-Objekte können im Speicher verbleiben. Ein reales System bräuchte ein HSM, das den KEK tatsächlich überschreibt.
Die Trigger: Wann gelöscht würde
Ein System, das löscht, braucht Regeln, wann es löscht. Diese Trigger müssten vor der Krise definiert werden und dürften nicht vom Nutzer im Ernstfall abhängig sein. Vier Typen sind denkbar:
GrapheneOS bietet seit 2024 einen Duress-PIN als real existierendes Feature. Wird er eingegeben, werden die Verschlüsselungsschlüssel zerstört, das Gerät wird unbrauchbar, und die eSIM-Partition wird gelöscht . Dieser PIN deckt allerdings nur einen der vier Trigger-Typen ab und ist kein Gesamtsystem. Ein Fall aus dem Jahr 2025 zeigt die rechtliche Dimension: Ein Reisender am Flughafen Atlanta gab bei einer Grenzkontrolle seinen Duress-PIN ein; die Staatsanwaltschaft erhob Anklage wegen Zerstörung von Eigentum zur Vereitelung einer rechtmäßigen Beschlagnahme .
Ein Architekturvorschlag: Fünf Schichten
Ein Nepomuk-System, das diesen Namen verdienen würde, bräuchte mehr als einen Trigger. Die folgende Schichtung ist ein Designvorschlag, keine Beschreibung bestehender Systeme.
Schicht 1: Das Geheimnis isolieren. Der KEK läge im HSM. Er verließe den Chip nie. Gelöscht würde nur der KEK. Diese Isolation wäre die Grundlage dafür, dass Löschung überhaupt schnell und sicher möglich ist.
Schicht 2: Trigger definieren. Die vier oben genannten Typen würden kombiniert. Ein einzelner Trigger reichte nicht. Die Kombination – etwa ein Heartbeat plus ein zweites unabhängiges Signal – wäre das Minimum für ein System, das nicht ständig Daten vernichtet.
Schicht 3: Löschtiefe staffeln. Stufe 1 löschte den KEK aus dem RAM (kalt), Stufe 2 überschriebe ihn im HSM (warm), Stufe 3 machte den DEK unentschlüsselbar (Crypto-Shred), Stufe 4 überschriebe physisch (nur bei höchstem Schutzbedarf). Die Regel lautete: immer die niedrigste ausreichende Stufe.
Schicht 4: Fehlauslösung minimieren. Drei Maßnahmen wären unverzichtbar: ein Quorum (mindestens zwei unabhängige Signale), eine Grace Period (Löschung in 60 Sekunden, abbrechbar) und ein Trockenlauf (das System protokollierte „würde löschen“, ohne zu löschen).
Schicht 5: Nachweisbarkeit. Vor der Löschung würde ein Audit-Log extern gesichert: dass gelöscht wurde, wann, durch welchen Trigger – aber nicht, was gelöscht wurde. Das Log wäre signiert und append-only.
Wann ein Nepomuk-System sinnvoll wäre
Nicht jede Situation rechtfertigte ein System, das Daten unwiderruflich vernichtet. Die Entscheidung folgte einer Risikogleichung:
Schaden(Preisgabe) > Schaden(Löschung) + [Wahrscheinlichkeit(Fehlauslösung) × Schaden(Fehlauslösung)]
Diese Ungleichung ist ein heuristisches Werkzeug, keine quantitative Kalkulation. Der „Schaden der Preisgabe“ ist oft existenziell und nicht in derselben Einheit messbar wie Datenverlust. Die Gleichung sagt nicht, wie viel Schaden akzeptabel ist. Sie sagt nur, welche Richtung die Abwägung nehmen muss.
Die Gleichung ginge in fünf Fällen auf. Diese fünf Fälle sind Plausibilitätsargumente, keine empirisch belegten Szenarien.
Der Schlüssel öffnet mehr als die Datei. Wenn ein einzelner Entschlüsselungsschlüssel ein ganzes Netzwerk schützte, wäre die Preisgabe eine Kaskade.
Die Daten sind zeitkritisch. Whistleblower-Material, das in 48 Stunden veröffentlicht wird: Nach der Publikation ist Geheimhaltung irrelevant.
Menschenleben hängen an Anonymität. Wenn die Preisgabe zur Identifikation und Verfolgung von Menschen führte, wäre die Löschung der humanere Schaden.
Die Daten sind giftig. Gestohlene Exploits, Malware, kompromittierende Daten, deren Besitz selbst das Risiko darstellt.
Die Daten sind unersetzlich, aber die Person ist es auch. Wenn der Schaden der Preisgabe existenziell ist und der Schaden der Löschung „nur“ Datenverlust bedeutet.
In fünf anderen Fällen wäre ein Nepomuk-System nicht sinnvoll: wenn Fehlauslösungen wahrscheinlich sind, wenn die Daten reproduzierbar sind, wenn die Preisgabe ohnehin unvermeidlich ist, wenn die Löschung rechtlich Beweisvernichtung darstellt, und wenn es um Alltagssicherheit von Normalnutzern geht.
Lessons Learned aus realen Systemen
Der Entwurf steht nicht im luftleeren Raum. Drei reale Systeme zeigen, welche Bausteine bereits existieren – und was fehlt.
a) Conduktor Gateway (Kafka + Crypto-Shredding). In Kafka ist physische Löschung wegen der append-only-Architektur praktisch unmöglich. Conduktor löst das mit per-User-DEKs, die unter einem KEK im KMS verpackt sind. Löschung = Tombstone des EDEK im Key-Store . Das ist genau das Muster, das der Artikel beschreibt – nur ohne die Trigger-Schicht. Der Unterschied: Conduktor löst ein GDPR-Problem, kein Duress-Problem.
b) pg_hardstorage (PostgreSQL-Backups). Dieses System nutzt per-Tenant-KEKs, um Backups kryptographisch zu vernichten. Der Befehl kms shred hat drei Sicherheitsgates: --require-approval (n-of-m), --confirm-keyring (Tippen des Pfads), --yes (Irreversibilität bestätigen) . Das ist genau die Grace-Period-Logik, die der Artikel fordert – nur ohne die Duress-Komponente.
c) GrapheneOS Duress-PIN. Das einzige reale System mit einem manuellen Duress-Trigger. Es zerstört die Schlüsselableitungssecrets und die eSIM . Der Fall Tunick zeigt die rechtliche Dimension . Der Unterschied zum Nepomuk-Entwurf: GrapheneOS hat kein Quorum, keine Grace Period, keinen Trockenlauf. Es ist ein Einzeltrigger-System – genau das, was der Artikel als unzureichend kritisiert.
Was der Entwurf daraus lernt: Die Technik (Crypto-Shredding, DEK/KEK) ist in Produktion erprobt. Die Trigger-Kombination (Quorum + Grace Period + Trockenlauf) ist in keinem bekannten System vollständig implementiert. Die rechtliche Frage (Ist Duress-PIN Beweisvernichtung?) ist ungeklärt und hängt vom Fall Tunick ab.
Die Grenzen: Was ein Nepomuk-System nicht könnte
Der Mensch bleibt der Schwachpunkt. Ein System könnte den Schlüssel löschen. Es könnte nicht verhindern, dass der Nutzer unter Druck das Duress-Passwort nennt, bevor er es nutzt.
Fehlauslösung ist der größte Feind. Jede Löschung, die nicht hätte sein müssen, untergrübe das Vertrauen in das System.
Der Angreifer kann das gesamte Gerät zerstören. Crypto-Shredding schützte den Schlüssel, nicht die Hardware. Ein Angreifer, der das Gerät physisch vernichtet, erreichte dasselbe Ergebnis – nur ohne dass der Nutzer die Kontrolle hatte. Die Bedrohung „Preisgabe“ würde durch Zerstörung nicht immer abgewendet, sondern manchmal nur verschoben.
Rechtliche Grauzone. In vielen Rechtsordnungen ist Beweisvernichtung strafbar – aber die Rechtslage ist jurisdiktionsabhängig und keineswegs klar. Der Fall des GrapheneOS-Nutzers, der 2025 bei einer Grenzkontrolle seinen Duress-PIN eingab, zeigt die Konsequenzen: Anklage nach 18 U.S.C. § 2232 . Ob § 2232 auf das Eingeben eines PINs überhaupt anwendbar ist, ist rechtlich umstritten – das Gesetz setzt traditionell eine physische Zerstörungshandlung voraus . Der Fall ist ein laufendes Verfahren, kein Präzedenzfall. In Deutschland etwa ist Beweisvernichtung nicht per se strafbar, sondern nur in bestimmten Konstellationen (§ 274 StGB Urkundenunterdrückung greift bei digitalen Daten selten).
Kein Recovery bedeutet, dass kein Fehler erlaubt ist. Ein Bug im Trigger, ein Stromausfall zur falschen Zeit – und die Daten wären weg. Die einzige Absicherung wäre Redundanz außerhalb des Nepomuk-Systems.
Symbolik versus Substanz. Löschung wäre nur dann echt, wenn der Schlüssel wirklich weg ist. Ohne HSM oder Secure Enclave wäre ein Nepomuk-System eine Behauptung, keine Garantie.
Was hier fehlt
Ein ehrlicher Entwurf benennt seine offenen Fragen. Fünf sind zentral:
- Wie wird ein Quorum technisch umgesetzt, ohne dass ein einzelner Fehler es aushebelt?
- Wie verhindert man, dass die Grace Period selbst zum Angriffsziel wird?
- Wie auditierbar ist ein System, das per Definition keine Hintertür hat?
- Wer haftet, wenn ein Fehlalarm Daten vernichtet?
- Gegen welches Angreifermodell wird überhaupt entworfen? Ein System, das gegen alles schützen soll, schützt gegen nichts.
Fazit und Ausblick
Das Nepomuk-Prinzip als Löschsystem ist kein Allheilmittel. Es wäre eine letzte Verteidigungslinie für Situationen, in denen die Preisgabe gefährlicher ist als der Verlust. Seine Stärke läge in der Entscheidung vor der Krise: Der Nutzer legte die Regel fest, das System vollstreckte sie, es gäbe keine Hintertür. Seine Schwäche läge in derselben Unwiderruflichkeit: Ein Fehler, und die Daten wären für immer weg.
Die Bausteine dafür existieren. Crypto-Shredding ist etabliert. HSMs können Schlüssel sicher überschreiben. Dead-Man’s-Switches sind implementiert. Duress-PINs gibt es in GrapheneOS. Was fehlt, ist die Integration zu einem System, das die Risikogleichung ernst nimmt: Quorum statt Einzeltrigger, Grace Period statt sofortiger Löschung, Trockenlauf statt blinder Aktivierung. Dieser Artikel schlägt die Integration vor; er behauptet nicht, dass sie existiert. Ein solches System existiert bislang nicht – weder kommerziell noch als Open-Source-Projekt.
Die historische Figur Johannes Nepomuk schwieg unter Folter. Die Legende machte ihn zum Schutzpatron des Beichtgeheimnisses. Ein technisches System kann nicht schweigen – aber es könnte den Schlüssel so verwahren, dass Schweigen die einzige Option wäre.
Quellen:
Primärquellen und offizielle Dokumentation:
- GrapheneOS: Offizielle Dokumentation zu Duress-PIN (grapheneos.org/features)
- GitHub: k4lipso/gokill – Software Dead-Man’s-Switch (github.com/k4lipso/gokill)
- Conduktor Docs: Crypto Shredding for Kafka (docs.conduktor.io)
- pg_hardstorage: Crypto-shred und n-of-m Approvals (github.com/cybertec-postgresql/pg_hardstorage)
Sekundärquellen (Fachpresse und Berichterstattung):
- ZDNET/Yahoo Tech: „Duress passcodes explained“ – Funktionsweise, rechtliche Risiken, Fall Samuel Tunick
- ABA Journal: „Wiped Clean: Is resetting your phone after being stopped by Border Patrol agents a federal offense?“ – Fall Tunick, rechtliche Analyse
- Android Authority: „I use a duress PIN to protect my data“ – Praxisbericht
- TechJuice: „GrapheneOS Duress PIN“ – Funktionsbeschreibung
- Apple iOS Security Guide: Effaceable Storage und Schlüsselverwaltung
Rechtliche Einordnung:
Post Comment