KI-Shield Security Architecture

Datenschutzkonforme Nutzung generativer KI mit Zero-Knowledge-Pseudonymisierung, Post-Quantum-signierter Audit-Kette und Blockchain-verankerter Beweisführung.

Executive Summary

KI-Shield ist eine kryptografische Sicherheitsarchitektur, die Unternehmen die datenschutzkonforme Nutzung generativer KI-Sprachmodelle (ChatGPT, Claude, Gemini, Mistral AI, Llama und weitere) ermöglicht. Kern des Systems ist ein mehrschichtiges Pseudonymisierungsverfahren, das personenbezogene Daten bereits auf dem Endgerät des Nutzers im Webbrowser erkennt und durch typerhaltende Stellvertreterzeichenketten ersetzt, bevor sie an einen externen Sprachverarbeitungsdienst übertragen werden.

Ergänzend implementiert KI-Shield eine manipulationssichere Audit-Kette mit hybrider Signatur-Architektur: jeder Audit-Eintrag wird gleichzeitig mit einem klassischen Ed25519-Schlüssel und mit dem NIST-standardisierten Post-Quantum-Verfahren ML-DSA-65 (FIPS 204) signiert und vor dem Speichern unmittelbar gegen-verifiziert (Write-Time-Verifikation). Eine tägliche Verankerung in der Polygon-Blockchain sichert die Beweiskraft öffentlich ab.

1. Regulatorischer Kontext

KI-Shield adressiert die folgenden Rahmenwerke durch seine Architektur — nicht durch vertragliche Zusagen:

2. Architektur-Übersicht

KI-Shield besteht aus zwei strikt getrennten Domänen: einer Nutzer-Domäne (Webbrowser auf dem Endgerät) und einer Betreiber-Domäne (Server-Infrastruktur). Zwischen beiden Domänen wird zu keinem Zeitpunkt unverschlüsselter personenbezogener Inhalt übertragen.

2.1 Module in der Nutzer-Domäne (Webbrowser, lokal)

• Dokumentenextraktionsmodul (10): PDF, DOCX, OCR (WebAssembly). Dokumente verlassen das Endgerät nicht.
• Mustererkennungsmodul (20): vier parallele Erkennungsschichten (siehe §3).
• Substitutionsmodul (30): Ersetzt Tokens durch typerhaltende Stellvertreter; verwaltet die bidirektionale Zuordnungstabelle ausschließlich im flüchtigen RAM.
• Kryptografisches Sicherungsmodul (40): Web-Crypto-API. Argon2id ≥ 600.000 Iterationen, AES-256-GCM.
• Re-Substitutionsmodul (70): Ersetzt Stellvertreter in der KI-Antwort zurück durch die Originaltokens.
• Orchestrierungsmodul (80): Wählt zwischen Nur-RAM und verschlüsseltem Chiffretext-Storage.

2.2 Module in der Betreiber-Domäne

• Empfangsschnittstelle (51): Nimmt ausschließlich den substituierten Anfragetext und Metadaten entgegen.
• Weiterleitung an externen Sprachverarbeitungsdienst (60): HTTPS-Routing (BYOK: ChatGPT, Claude, Gemini, Mistral, Llama).
• Speichereinheit (53): Speichert nur Chiffretextblöcke — ohne Entschlüsselungsmittel.
• Audit-Kette: Ed25519 + ML-DSA-65 dual-signiert, Write-Time-verifiziert.
• Tägliche Blockchain-Verankerung: Merkle-Root in der Polygon-Blockchain.

3. Vier-Schichten-PII-Erkennung

Das Mustererkennungsmodul kombiniert vier parallele Erkennungsschichten. Konfliktauflösung nach dem Prinzip der längsten Übereinstimmung sowie kontextbasierter Unterscheidung.

3.1 Namensbasierte Erkennungsschicht

Prüfung gegen Eigennamen-Sammlung mittels Set-basierter Hash-Suche in konstanter Zeit. Kontextuelle Hinweise (Anreden, akademische Titel) erhöhen die Präzision bei Mehrdeutigkeiten.

3.2 Musterbasierte Erkennungsschicht mit Prüfziffer-Validierung

• MOD-97 für IBAN (ISO 13616)
• Luhn für Kreditkartennummern (ISO/IEC 7812)
• ISO/IEC 7064 Mod-11,10 für Krankenversicherungsnummern
• ICAO 9303 für maschinenlesbare Identitätsdokumente

Die Prüfziffer-Validierung reduziert Fehlalarme gegen Null: nur Tokens mit mathematisch korrekter Prüfziffer werden als PII-Kandidaten markiert.

3.3 Schlüsselwortbasierte Erkennungsschicht

Kuratierte Schlüsselwortlisten für 42 PII-Kategorien (Gesundheitsdaten, Religion, politische Meinung, biometrische Daten etc.). Kontextuelle Auswertung zur Vermeidung von Fehltreffern in unbeteiligten Nennungen.

3.4 Kontextbasierte Konfliktauflösung

Bei mehrdeutigen Erkennungen (Geräteseriennummer vs. Telefonnummer, Kreditkartennummer vs. anderer Identifikator) entscheidet eine kontextbasierte Analyse des umgebenden Textes.

3.5 Neuronale Erkennungsschicht (Server-Variante)

Die Server-Variante (KI-Shield Proxy) ergänzt die drei Browser-Schichten durch eine neuronale NER mit spaCy. Die reine Browser-Variante arbeitet ohne ML-Inferenz — komplett deterministisch.

4. Substitution und Zuordnungstabelle

4.1 Typerhaltende Pseudonyme

Erkannte Tokens werden nicht durch einen generischen Platzhalter ersetzt, sondern durch typspezifische Stellvertreterketten:

Müller          → [PERSON_001]
15.03.1978      → [DOB_001]
DE89 3704...    → [IBAN_001]
Diabetes Typ 2  → [MEDICAL_001]

Der Typerhalt sichert die semantische Kohärenz: die KI behandelt [IBAN_001] weiterhin als Bankkontonummer.

4.2 Initialisierungsoffset gegen Informationslecks

Zu Beginn jeder Sitzung wählt das Substitutionsmodul einen pseudozufälligen Initialisierungsoffset. Die Nummerierung der Pseudonyme startet nicht bei 001, sondern bei einer zufälligen Zahl — aus dem numerischen Anteil einer Stellvertreterkette kann nicht auf die Token-Anzahl der Sitzung geschlossen werden.

4.3 Bidirektionale Zuordnungstabelle — flüchtig im RAM

Die Zuordnungstabelle wird ausschließlich im flüchtigen Arbeitsspeicher des Webbrowsers gehalten. Sie wird zu keinem Zeitpunkt an den Server übermittelt.

5. Web-Crypto-Flow und Betriebsmodi

5.1 Modus A — Nur-RAM (maximaler Zero-Knowledge-Schutz)

Die Zuordnungstabelle existiert ausschließlich im flüchtigen Arbeitsspeicher und wird mit dem Tab-Schließen vernichtet. Keine Persistenz.

5.2 Modus B — Verschlüsselter Chiffretext-Storage

1. Schlüsselableitung aus dem Nutzerpasswort mittels Argon2id mit mindestens 600.000 Iterationen und kryptografisch zufälligem Salt (Web Crypto API).
2. Verschlüsselung der Zuordnungstabelle mit AES-256-GCM (Authenticated Encryption, zufälliger IV, Authentifizierungsanhang).
3. Übermittlung des Chiffretextblocks an die Speichereinheit des Servers.
4. In späterer Sitzung: Abruf, Entschlüsselung im Browser mit dem erneut aus dem Passwort abgeleiteten Schlüssel.

Der Server sieht ausschließlich den verschlüsselten Block. Der Entschlüsselungsschlüssel verlässt zu keinem Zeitpunkt den Browser.

5.3 Browser-Standards, kein Plugin

Das System verwendet ausschließlich standardisierte Browser-Schnittstellen — Web Crypto API, File API, Canvas API. Kein Browser-Plugin, keine Zusatzsoftware.

6. Hybride Post-Quantum-Audit-Kette

6.1 Warum hybrid?

Klassische Signaturverfahren (ECDSA, RSA, Ed25519) sind gegen Quantencomputer verwundbar. Post-Quantum-Verfahren (ML-DSA-65) sind quantensicher, haben aber weniger langjährige Analyseerfahrung. KI-Shield signiert daher jeden Audit-Eintrag gleichzeitig mit beiden Verfahren. Ein Angreifer müsste beide gleichzeitig brechen.

6.2 Write-Time-Verifikation

Nach Erzeugung der beiden Signaturen und vor dem Schreiben in die Audit-Kette werden beide gegen den gerade signierten Payload und die Public Keys verifiziert. Schlägt die Verifikation fehl, wird der Eintrag nicht geschrieben.

6.3 Hash-Chain mit öffentlich prüfbarer Integrität

Jeder Eintrag enthält den Hash des vorherigen Eintrags sowie seinen Chain-Index. Die kryptografische Integritätskette bleibt im Klartext, während die Nutzlasten verschlüsselt sind. Ein Auditor kann die Integrität der Kette verifizieren, ohne die Inhalte zu sehen.

6.4 RFC-3161-Zeitstempel

Der Hash jedes Audit-Eintrags wird zusätzlich durch einen qualifizierten Zeitstempel nach RFC 3161 versiegelt. Der Existenzzeitpunkt ist damit unabhängig vom KI-Shield-System beweisbar.

6.5 Tägliche Polygon-Verankerung

Einmal täglich wird der Merkle-Root aller Audit-Einträge in einer Transaktion der Polygon-Proof-of-Stake-Blockchain festgeschrieben — dritte, unabhängige Beweisebene.

7. Compliance-Mapping

8. Sicherheitsbetrachtungen

Angriffsfläche des Betreibers: Selbst bei vollständiger Kompromittierung des KI-Shield-Servers besitzt der Angreifer ausschließlich verschlüsselte Chiffretextblöcke und Hashes. Ohne das Nutzerpasswort sind diese Daten kryptografisch unbrauchbar. Ein erfolgreicher Angriff auf den Server leckt keine personenbezogenen Daten.

Angriffsfläche des LLM-Anbieters: Der externe Sprachverarbeitungsdienst erhält ausschließlich den substituierten Anfragetext mit Pseudonymen. Auch ein US-Cloud-Act-Zugriff auf OpenAI, Anthropic oder Google liefert keine identifizierenden Nutzerdaten.

Post-Quantum-Widerstandsfähigkeit: Die gleichzeitige Signatur mit Ed25519 und ML-DSA-65 gewährleistet, dass beim Auftreten kryptografisch relevanter Quantencomputer die ML-DSA-65-Signatur die Beweiskraft der Audit-Kette fortführt.

Restrisiko Nutzer-Endgerät: Die Zero-Knowledge-Architektur verlagert einen Teil des Vertrauens auf die Integrität des Nutzer-Endgeräts. Ein kompromittiertes Endgerät kann den Schutz unterlaufen.

9. Bewusste Grenzen

• AVV bleibt erforderlich. Die Zero-Knowledge-Architektur reduziert die Eingriffsintensität, hebt aber nicht die AVV-Pflicht nach Art. 28 DSGVO auf.
• Erkennungsrate ist nicht 100%. Kein PII-Erkennungssystem ist perfekt. Bei hochsensiblen Inhalten zusätzlich manuell prüfen.
• Sprachabhängigkeit. Primär auf deutsche und englische Texte kalibriert.
• Externe LLM-Qualität. Wir haben keinen Einfluss darauf, ob ChatGPT zufällig personenbezogene Phantasie-Antworten generiert. Unser Re-PII-Check der Antwort filtert erkennbare Fälle.

10. Referenzen

NIST FIPS 204 ML-DSA (2024) · FIPS 180-4 SHA-256 · NIST SP 800-38D AES-GCM · RFC 3161 Time-Stamp Protocol · RFC 8032 Ed25519 · RFC 9106 Argon2 · ISO 13616 IBAN · ISO/IEC 7812 Luhn · ISO/IEC 7064 Mod-11,10 · ICAO 9303 MRTD · DSGVO EU 2016/679 · EU AI Act EU 2024/1689 · eIDAS 2.0 EU 2024/1183 · § 203 StGB · BSI IT-Grundschutz

Anhang: Prior-Art-Statement und Lizenzierung

Die in diesem Dokument beschriebene Kernarchitektur ist in den folgenden eingetragenen deutschen Gebrauchsmustern geschützt:

Lizenzierung: Die zusätzlich in diesem Dokument beschriebenen Architektur-Elemente, die nicht Gegenstand der oben genannten Gebrauchsmuster sind (insb. regulatorische Interpretationen, Compliance-Mappings, ergänzende Erkennungsalgorithmen), werden unter der Creative Commons Attribution 4.0 International (CC BY 4.0) veröffentlicht.

Nachbauhinweis: Die Implementierung der durch die oben genannten Gebrauchsmuster geschützten Verfahren erfordert eine Lizenz der Schutzrechtsinhaberin KI-Shield UG. Die Beschreibung in diesem Whitepaper dient der Transparenz gegenüber Kunden, Auditoren und der wissenschaftlichen Öffentlichkeit und stellt keine Lizenzgewährung dar.

Zweck der Veröffentlichung: Technische Dokumentation gegenüber Geschäftskunden, Datenschutzbeauftragten und Auditoren. Ergänzt — nicht ersetzt — die amtliche Gebrauchsmuster-Beschreibung.

Ende des Whitepapers Version 1.0

KI-Shield UG (haftungsbeschränkt) · HRB 524511 Amtsgericht Jena · Greußen, Thüringen
info@ki-shield.de · ki-shield.de · ki-shield.eu
Veröffentlicht am 17. April 2026