{"id":7693,"date":"2026-10-17T05:58:27","date_gmt":"2026-10-17T05:58:27","guid":{"rendered":"https:\/\/technodidact.de\/?p=7693"},"modified":"2026-10-17T05:58:28","modified_gmt":"2026-10-17T05:58:28","slug":"nepomuk-als-loeschsystem-ein-konzeptioneller-entwurf-zu-architektur-triggern-und-der-entscheidung-vor-der-krise","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/nepomuk-als-loeschsystem-ein-konzeptioneller-entwurf-zu-architektur-triggern-und-der-entscheidung-vor-der-krise\/","title":{"rendered":"Nepomuk als L\u00f6schsystem: Ein konzeptioneller Entwurf zu Architektur, Triggern und der Entscheidung vor der Krise"},"content":{"rendered":"\n

Von DerSchneider<\/strong><\/p>\n\n\n\n

\n

Hinweis:<\/strong> 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 \u201eNepomuk-System“ in der beschriebenen Form ist bislang nicht implementiert. Wo im Folgenden von \u201eeinem Nepomuk-System“ die Rede ist, ist stets ein hypothetisches System gemeint, nicht ein real verf\u00fcgbares.<\/p>\n<\/blockquote>\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Es gibt Momente, in denen ein Geheimnis gef\u00e4hrlicher 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 \u00dcbertragung des Nepomuk-Prinzips \u2013 \u201elieber sterben als preisgeben“ \u2013 auf ein technisches L\u00f6schsystem f\u00fcr verschl\u00fcsselte Dateien.<\/p>\n\n\n\n

Dieser Artikel beschreibt, wie ein solches System funktionieren w\u00fcrde<\/em>, wann sein Einsatz rational w\u00e4re<\/em> und welche Architektur n\u00f6tig w\u00e4re<\/em>, 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\u00e4gung zusammensetzt. \u201eLieber sterben als preisgeben“ ist dabei keine ethische Empfehlung, sondern die Beschreibung eines Prinzips, dessen technische Umsetzung hier durchdacht wird.<\/p>\n\n\n\n

Das Prinzip: Entscheidung vor der Krise<\/h2>\n\n\n\n

Die Nepomuk-Legende handelt von einem Mann, der unter Folter schwieg. Der historische Johannes von Pomuk starb 1393 im Machtkampf zwischen K\u00f6nig Wenzel IV. und der Kirche, doch die Legende machte ihn zum M\u00e4rtyrer des Beichtgeheimnisses. Das entscheidende Moment: Er traf seine Entscheidung nicht in der Folterkammer. Er hatte sie vorher getroffen.<\/p>\n\n\n\n

Genau das w\u00e4re der Kern eines technischen Nepomuk-Systems. Der Nutzer w\u00fcrde in Sicherheit definieren, unter welchen Bedingungen gel\u00f6scht wird. Das System w\u00fcrde diese Regel unter Druck vollstrecken. Es g\u00e4be keine Hintert\u00fcr, keinen Admin-Override, keine letzte Instanz, die doch noch entscheidet, die Daten herauszugeben. Die Entscheidung w\u00e4re gefallen, bevor die Krise beginnt.<\/p>\n\n\n\n

Das ist der Unterschied zwischen einem Passwort, das man unter Folter doch nennt, und einem Schl\u00fcssel, der physisch nicht mehr existiert. Der Mensch kann brechen. Ein \u00fcberschriebener Schl\u00fcssel nicht.<\/p>\n\n\n\n

Das Angreifermodell: Wogegen das System sch\u00fctzt<\/h2>\n\n\n\n

Bevor die Architektur Sinn ergibt, muss klar sein, gegen wen sie sch\u00fctzt. Das Angreifermodell ist im Entwurf implizit<\/strong>: ein physischer Angreifer mit Zugriff auf das Ger\u00e4t, aber ohne Kenntnis des Duress-PINs. Gegen diesen Angreifer hilft die Kombination aus HSM, Quorum und Grace Period.<\/p>\n\n\n\n

Gegen einen Angreifer, der das Ger\u00e4t zerst\u00f6rt oder den Nutzer vor der Trigger-Bet\u00e4tigung \u00fcberw\u00e4ltigt, hilft das System nicht. Ebenso wenig gegen einen staatlichen Angreifer mit forensischen Ressourcen, der das Ger\u00e4t vor der L\u00f6schung analysiert, oder gegen einen Insider, der die Trigger-Konfiguration kennt. Das Angreifermodell bestimmt, welche Trigger sinnvoll sind \u2013 und welche Illusion bleiben. Ein System, das gegen alles sch\u00fctzen soll, sch\u00fctzt gegen nichts.<\/p>\n\n\n\n

Die technische Grundlage: Crypto-Shredding<\/h2>\n\n\n\n

Ein Nepomuk-L\u00f6scher w\u00fcrde keine Dateien l\u00f6schen. Er w\u00fcrde den Schl\u00fcssel l\u00f6schen, mit dem die Dateien entschl\u00fcsselt werden. Dieses Verfahren hei\u00dft Crypto-Shredding und w\u00e4re der eigentliche Mechanismus, der das Prinzip technisch umsetzbar macht.<\/p>\n\n\n\n

Die Logik ist einfach: Daten werden mit einem Data Encryption Key (DEK) verschl\u00fcsselt. Der DEK wird wiederum mit einem Key Encryption Key (KEK) verschl\u00fcsselt, der in einem Hardware-Sicherheitsmodul (HSM) oder einer Secure Enclave liegt. Wird der KEK \u00fcberschrieben, ist der DEK unentschl\u00fcsselbar. Die Daten blieben physisch auf dem Datentr\u00e4ger vorhanden \u2013 als Kryptotext, der ohne Schl\u00fcssel keinen Informationswert mehr hat.<\/p>\n\n\n\n

Dieses Verfahren ist in der Sicherheitsforschung etabliert. Apple nutzt ein verwandtes Verfahren<\/strong> \u2013 das Verwerfen der Schl\u00fcssel im sogenannten effaceable storage<\/em> bei \u201eAlle Inhalte und Einstellungen l\u00f6schen“ \u2013, doch die Gleichsetzung mit dem hier beschriebenen Crypto-Shredding ist eine Analogie, keine technische Identit\u00e4t<\/strong> . Der Vorteil gegen\u00fcber physischem \u00dcberschreiben w\u00e4re: Die L\u00f6schung dauerte Millisekunden, unabh\u00e4ngig von der Datenmenge, und hinterlie\u00dfe keine lesbaren Reste des Klartexts.<\/a><\/a><\/p>\n\n\n\n

F\u00fcr ein Nepomuk-System w\u00fcrde das bedeuten: Die L\u00f6schung w\u00e4re schnell, leise und forensisch wirksam \u2013 wenn die Integration gelingt. Ein Angreifer, der das Ger\u00e4t beschlagnahmt, f\u00e4nde einen Datentr\u00e4ger voller Zufallsdaten. Er k\u00f6nnte sie nicht entschl\u00fcsseln, weil der Schl\u00fcssel nicht mehr existiert.<\/p>\n\n\n\n

Ein minimales Code-Beispiel<\/h3>\n\n\n\n

Das folgende Python-Beispiel zeigt den Kernmechanismus in seiner einfachsten Form. Es ist bewusst kein vollst\u00e4ndiges Nepomuk-System \u2013 es zeigt nur: DEK verschl\u00fcsselt Daten, KEK verschl\u00fcsselt DEK, KEK \u00fcberschreiben = Daten tot.<\/p>\n\n\n\n

python<\/p>\n\n\n\n

from cryptography.hazmat.primitives.ciphers.aead import AESGCM\nimport os\n\nclass CryptoShredDemo:\n    def __init__(self):\n        # KEK: Key Encryption Key (in der Realit\u00e4t: HSM)<\/em>\n        self.kek = AESGCM.generate_key(bit_length=256)\n        # DEK: Data Encryption Key (verschl\u00fcsselt die Daten)<\/em>\n        self.dek = AESGCM.generate_key(bit_length=256)\n        # DEK unter KEK \"verpackt\" (Envelope Encryption)<\/em>\n        self.encrypted_dek = self._wrap_dek()\n\n    def _wrap_dek(self):\n        kek_cipher = AESGCM(self.kek)\n        nonce = os.urandom(12)\n        return nonce + kek_cipher.encrypt(nonce, self.dek, None)\n\n    def _unwrap_dek(self):\n        kek_cipher = AESGCM(self.kek)\n        nonce = self.encrypted_dek[:12]\n        return kek_cipher.decrypt(nonce, self.encrypted_dek[12:], None)\n\n    def encrypt_secret(self, plaintext: bytes) -> bytes:\n        dek = self._unwrap_dek()\n        nonce = os.urandom(12)\n        return nonce + AESGCM(dek).encrypt(nonce, plaintext, None)\n\n    def decrypt_secret(self, ciphertext: bytes) -> bytes:\n        dek = self._unwrap_dek()\n        nonce = ciphertext[:12]\n        return AESGCM(dek).decrypt(nonce, ciphertext[12:], None)\n\n    def shred(self):\n        \"\"\"Crypto-Shredding: KEK \u00fcberschreiben \u2192 DEK unentschl\u00fcsselbar.\"\"\"\n        self.kek = b'\\x00' * 32\n        self.encrypted_dek = None<\/pre>\n\n\n\n
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\u00fcr Kafka eingesetzt . shred()<\/code> ist der entscheidende Punkt: Es wird nicht der Chiffretext gel\u00f6scht, sondern der Schl\u00fcssel, der ihn lesbar macht. Ohne KEK ist der DEK unentschl\u00fcsselbar, ohne DEK sind die Daten Zufallsbytes.<\/a><\/p>\n\n\n\n
Wichtiger Hinweis:<\/strong> Das Python-Beispiel ist nicht forensisch sicher. Python-Objekte k\u00f6nnen im Speicher verbleiben. Ein reales System br\u00e4uchte ein HSM, das den KEK tats\u00e4chlich \u00fcberschreibt.<\/p>\n\n\n\n
Die Trigger: Wann gel\u00f6scht w\u00fcrde<\/h2>\n\n\n\n
Ein System, das l\u00f6scht, braucht Regeln, wann es l\u00f6scht. Diese Trigger m\u00fcssten vor der Krise definiert werden und d\u00fcrften nicht vom Nutzer im Ernstfall abh\u00e4ngig sein. Vier Typen sind denkbar:<\/p>\n\n\n\n
Trigger<\/th>Wer l\u00f6st aus?<\/th>St\u00e4rke<\/th>Schw\u00e4che<\/th>Reales Beispiel<\/th><\/tr><\/thead>
Manuell (Duress)<\/strong><\/td>Nutzer<\/td>Direkt, kontrolliert<\/td>Nutzer muss handlungsf\u00e4hig sein<\/td>GrapheneOS Duress-PIN <\/a><\/a><\/td><\/tr>
Automatisch (Manipulation)<\/strong><\/td>HSM\/Hardware<\/td>Umgeht den Menschen<\/td>Setzt HSM-Erkennung voraus<\/td>(konzeptionell)<\/td><\/tr>
Extern (Dead-Man’s-Switch)<\/strong><\/td>Server\/Vertrauensperson<\/td>Schutz bei Verhaftung\/Ohnmacht<\/td>Fehlalarme (Reise, Netzausfall)<\/td>gokill (Open Source)<\/td><\/tr>
Policy-basiert (Kontext)<\/strong><\/td>System<\/td>Erkennt ungew\u00f6hnliche Umgebung<\/td>Fehleranf\u00e4llig, nur mit Quorum<\/td>(konzeptionell)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
GrapheneOS bietet seit 2024 einen Duress-PIN als real existierendes Feature.<\/strong> Wird er eingegeben, werden die Verschl\u00fcsselungsschl\u00fcssel zerst\u00f6rt, das Ger\u00e4t wird unbrauchbar, und die eSIM-Partition wird gel\u00f6scht . Dieser PIN deckt allerdings nur einen der vier Trigger-Typen<\/strong> 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\u00f6rung von Eigentum zur Vereitelung einer rechtm\u00e4\u00dfigen Beschlagnahme .<\/a><\/a><\/a><\/p>\n\n\n\n
Ein Architekturvorschlag: F\u00fcnf Schichten<\/h2>\n\n\n\n
Ein Nepomuk-System, das diesen Namen verdienen w\u00fcrde, br\u00e4uchte mehr als einen Trigger. Die folgende Schichtung ist ein Designvorschlag, keine Beschreibung bestehender Systeme<\/strong>.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Schicht 1: Das Geheimnis isolieren.<\/strong> Der KEK l\u00e4ge im HSM. Er verlie\u00dfe den Chip nie. Gel\u00f6scht w\u00fcrde nur der KEK. Diese Isolation w\u00e4re die Grundlage daf\u00fcr, dass L\u00f6schung \u00fcberhaupt schnell und sicher m\u00f6glich ist.<\/p>\n\n\n\n
Schicht 2: Trigger definieren.<\/strong> Die vier oben genannten Typen w\u00fcrden kombiniert. Ein einzelner Trigger reichte nicht. Die Kombination \u2013 etwa ein Heartbeat plus ein zweites unabh\u00e4ngiges Signal \u2013 w\u00e4re das Minimum f\u00fcr ein System, das nicht st\u00e4ndig Daten vernichtet.<\/p>\n\n\n\n
Schicht 3: L\u00f6schtiefe staffeln.<\/strong> Stufe 1 l\u00f6schte den KEK aus dem RAM (kalt), Stufe 2 \u00fcberschriebe ihn im HSM (warm), Stufe 3 machte den DEK unentschl\u00fcsselbar (Crypto-Shred), Stufe 4 \u00fcberschriebe physisch (nur bei h\u00f6chstem Schutzbedarf). Die Regel lautete: immer die niedrigste ausreichende Stufe.<\/p>\n\n\n\n
Schicht 4: Fehlausl\u00f6sung minimieren.<\/strong> Drei Ma\u00dfnahmen w\u00e4ren unverzichtbar: ein Quorum (mindestens zwei unabh\u00e4ngige Signale), eine Grace Period (L\u00f6schung in 60 Sekunden, abbrechbar) und ein Trockenlauf (das System protokollierte \u201ew\u00fcrde l\u00f6schen“, ohne zu l\u00f6schen).<\/p>\n\n\n\n
Schicht 5: Nachweisbarkeit.<\/strong> Vor der L\u00f6schung w\u00fcrde ein Audit-Log extern gesichert: dass gel\u00f6scht wurde, wann, durch welchen Trigger \u2013 aber nicht, was gel\u00f6scht wurde. Das Log w\u00e4re signiert und append-only.<\/p>\n\n\n\n
Wann ein Nepomuk-System sinnvoll w\u00e4re<\/h2>\n\n\n\n
Nicht jede Situation rechtfertigte ein System, das Daten unwiderruflich vernichtet. Die Entscheidung folgte einer Risikogleichung:<\/p>\n\n\n\n
Schaden(Preisgabe) > Schaden(L\u00f6schung) + [Wahrscheinlichkeit(Fehlausl\u00f6sung) \u00d7 Schaden(Fehlausl\u00f6sung)]<\/strong><\/p>\n\n\n\n
Diese Ungleichung ist ein heuristisches Werkzeug, keine quantitative Kalkulation<\/strong>. Der \u201eSchaden 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\u00e4gung nehmen muss.<\/strong><\/p>\n\n\n\n
Die Gleichung ginge in f\u00fcnf F\u00e4llen auf. Diese f\u00fcnf F\u00e4lle sind Plausibilit\u00e4tsargumente, keine empirisch belegten Szenarien.<\/strong><\/p>\n\n\n\n
Der Schl\u00fcssel \u00f6ffnet mehr als die Datei.<\/strong> Wenn ein einzelner Entschl\u00fcsselungsschl\u00fcssel ein ganzes Netzwerk sch\u00fctzte, w\u00e4re die Preisgabe eine Kaskade.<\/p>\n\n\n\n
Die Daten sind zeitkritisch.<\/strong> Whistleblower-Material, das in 48 Stunden ver\u00f6ffentlicht wird: Nach der Publikation ist Geheimhaltung irrelevant.<\/p>\n\n\n\n
Menschenleben h\u00e4ngen an Anonymit\u00e4t.<\/strong> Wenn die Preisgabe zur Identifikation und Verfolgung von Menschen f\u00fchrte, w\u00e4re die L\u00f6schung der humanere Schaden.<\/p>\n\n\n\n
Die Daten sind giftig.<\/strong> Gestohlene Exploits, Malware, kompromittierende Daten, deren Besitz selbst das Risiko darstellt.<\/p>\n\n\n\n
Die Daten sind unersetzlich, aber die Person ist es auch.<\/strong> Wenn der Schaden der Preisgabe existenziell ist und der Schaden der L\u00f6schung \u201enur“ Datenverlust bedeutet.<\/p>\n\n\n\n
In f\u00fcnf anderen F\u00e4llen w\u00e4re ein Nepomuk-System nicht<\/strong> sinnvoll: wenn Fehlausl\u00f6sungen wahrscheinlich sind, wenn die Daten reproduzierbar sind, wenn die Preisgabe ohnehin unvermeidlich ist, wenn die L\u00f6schung rechtlich Beweisvernichtung darstellt, und wenn es um Alltagssicherheit von Normalnutzern geht.<\/p>\n\n\n\n
Lessons Learned aus realen Systemen<\/h2>\n\n\n\n
Der Entwurf steht nicht im luftleeren Raum. Drei reale Systeme zeigen, welche Bausteine bereits existieren \u2013 und was fehlt.<\/p>\n\n\n\n
a) Conduktor Gateway (Kafka + Crypto-Shredding).<\/strong> In Kafka ist physische L\u00f6schung wegen der append-only-Architektur praktisch unm\u00f6glich. Conduktor l\u00f6st das mit per-User-DEKs, die unter einem KEK im KMS verpackt sind. L\u00f6schung = Tombstone des EDEK im Key-Store . Das ist genau das Muster, das der Artikel beschreibt \u2013 nur ohne die Trigger-Schicht. Der Unterschied: Conduktor l\u00f6st ein GDPR-Problem, kein Duress-Problem.<\/a><\/p>\n\n\n\n
b) pg_hardstorage (PostgreSQL-Backups).<\/strong> Dieses System nutzt per-Tenant-KEKs, um Backups kryptographisch zu vernichten. Der Befehl kms shred<\/code> hat drei Sicherheitsgates: --require-approval<\/code> (n-of-m), --confirm-keyring<\/code> (Tippen des Pfads), --yes<\/code> (Irreversibilit\u00e4t best\u00e4tigen) . Das ist genau die Grace-Period-Logik, die der Artikel fordert \u2013 nur ohne die Duress-Komponente.<\/a><\/a><\/p>\n\n\n\n
c) GrapheneOS Duress-PIN.<\/strong> Das einzige reale System mit einem manuellen Duress-Trigger. Es zerst\u00f6rt die Schl\u00fcsselableitungssecrets 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 \u2013 genau das, was der Artikel als unzureichend kritisiert.<\/a><\/a><\/a><\/p>\n\n\n\n
Was der Entwurf daraus lernt:<\/strong> Die Technik (Crypto-Shredding, DEK\/KEK) ist in Produktion erprobt. Die Trigger-Kombination (Quorum + Grace Period + Trockenlauf) ist in keinem bekannten System vollst\u00e4ndig implementiert. Die rechtliche Frage (Ist Duress-PIN Beweisvernichtung?) ist ungekl\u00e4rt und h\u00e4ngt vom Fall Tunick ab.<\/p>\n\n\n\n
Die Grenzen: Was ein Nepomuk-System nicht k\u00f6nnte<\/h2>\n\n\n\n
Der Mensch bleibt der Schwachpunkt.<\/strong> Ein System k\u00f6nnte den Schl\u00fcssel l\u00f6schen. Es k\u00f6nnte nicht verhindern, dass der Nutzer unter Druck das Duress-Passwort nennt, bevor er es nutzt.<\/p>\n\n\n\n
Fehlausl\u00f6sung ist der gr\u00f6\u00dfte Feind.<\/strong> Jede L\u00f6schung, die nicht h\u00e4tte sein m\u00fcssen, untergr\u00fcbe das Vertrauen in das System.<\/p>\n\n\n\n
Der Angreifer kann das gesamte Ger\u00e4t zerst\u00f6ren.<\/strong> Crypto-Shredding sch\u00fctzte den Schl\u00fcssel, nicht die Hardware. Ein Angreifer, der das Ger\u00e4t physisch vernichtet, erreichte dasselbe Ergebnis \u2013 nur ohne dass der Nutzer die Kontrolle hatte. Die Bedrohung \u201ePreisgabe“ w\u00fcrde durch Zerst\u00f6rung nicht immer abgewendet, sondern manchmal nur verschoben.<\/p>\n\n\n\n
Rechtliche Grauzone.<\/strong> In vielen Rechtsordnungen ist Beweisvernichtung strafbar \u2013 aber die Rechtslage ist jurisdiktionsabh\u00e4ngig und keineswegs klar<\/strong>. Der Fall des GrapheneOS-Nutzers, der 2025 bei einer Grenzkontrolle seinen Duress-PIN eingab, zeigt die Konsequenzen: Anklage nach 18 U.S.C. \u00a7 2232 . Ob \u00a7 2232 auf das Eingeben eines PINs \u00fcberhaupt anwendbar ist, ist rechtlich umstritten<\/strong> \u2013 das Gesetz setzt traditionell eine physische Zerst\u00f6rungshandlung voraus . Der Fall ist ein laufendes Verfahren, kein Pr\u00e4zedenzfall. In Deutschland etwa ist Beweisvernichtung nicht per se strafbar, sondern nur in bestimmten Konstellationen (\u00a7 274 StGB Urkundenunterdr\u00fcckung greift bei digitalen Daten selten).<\/a><\/a><\/p>\n\n\n\n
Kein Recovery bedeutet, dass kein Fehler erlaubt ist.<\/strong> Ein Bug im Trigger, ein Stromausfall zur falschen Zeit \u2013 und die Daten w\u00e4ren weg. Die einzige Absicherung w\u00e4re Redundanz au\u00dferhalb des Nepomuk-Systems.<\/p>\n\n\n\n
Symbolik versus Substanz.<\/strong> L\u00f6schung w\u00e4re nur dann echt, wenn der Schl\u00fcssel wirklich weg ist. Ohne HSM oder Secure Enclave w\u00e4re ein Nepomuk-System eine Behauptung, keine Garantie.<\/p>\n\n\n\n
Was hier fehlt<\/h2>\n\n\n\n
Ein ehrlicher Entwurf benennt seine offenen Fragen. F\u00fcnf sind zentral:<\/p>\n\n\n\n
    \n
  1. Wie wird ein Quorum technisch umgesetzt, ohne dass ein einzelner Fehler es aushebelt?<\/strong><\/li>\n\n\n\n
  2. Wie verhindert man, dass die Grace Period selbst zum Angriffsziel wird?<\/strong><\/li>\n\n\n\n
  3. Wie auditierbar ist ein System, das per Definition keine Hintert\u00fcr hat?<\/strong><\/li>\n\n\n\n
  4. Wer haftet, wenn ein Fehlalarm Daten vernichtet?<\/strong><\/li>\n\n\n\n
  5. Gegen welches Angreifermodell wird \u00fcberhaupt entworfen?<\/strong> Ein System, das gegen alles sch\u00fctzen soll, sch\u00fctzt gegen nichts.<\/li>\n<\/ol>\n\n\n\n
    Fazit und Ausblick<\/h2>\n\n\n\n
    Das Nepomuk-Prinzip als L\u00f6schsystem ist kein Allheilmittel. Es w\u00e4re eine letzte Verteidigungslinie f\u00fcr Situationen, in denen die Preisgabe gef\u00e4hrlicher ist als der Verlust. Seine St\u00e4rke l\u00e4ge in der Entscheidung vor der Krise: Der Nutzer legte die Regel fest, das System vollstreckte sie, es g\u00e4be keine Hintert\u00fcr. Seine Schw\u00e4che l\u00e4ge in derselben Unwiderruflichkeit: Ein Fehler, und die Daten w\u00e4ren f\u00fcr immer weg.<\/p>\n\n\n\n
    Die Bausteine daf\u00fcr existieren. Crypto-Shredding ist etabliert. HSMs k\u00f6nnen Schl\u00fcssel sicher \u00fcberschreiben. 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\u00f6schung, Trockenlauf statt blinder Aktivierung.<\/strong> Dieser Artikel schl\u00e4gt die Integration vor; er behauptet nicht, dass sie existiert. Ein solches System existiert bislang nicht \u2013 weder kommerziell noch als Open-Source-Projekt.<\/strong><\/p>\n\n\n\n
    Die historische Figur Johannes Nepomuk schwieg unter Folter. Die Legende machte ihn zum Schutzpatron des Beichtgeheimnisses. Ein technisches System kann nicht schweigen \u2013 aber es k\u00f6nnte den Schl\u00fcssel so verwahren, dass Schweigen die einzige Option w\u00e4re.<\/p>\n\n\n\n
    \n\n\n\n
    Quellen:<\/strong><\/p>\n\n\n\n
    Prim\u00e4rquellen und offizielle Dokumentation:<\/strong><\/p>\n\n\n\n