Citadel

Post-Quanten-Hybrid-Verschlüsselungs- und Schlüsselverwaltungsserver.

Citadel kombiniert X25519 + ML-KEM-768 zur Schlüsselkapselung und AES-256-GCM zur Datenverschlüsselung, gemäß dem Hybridansatz von NIST für den Post-Quanten-Übergang. Anwendungen verschlüsseln und entschlüsseln Daten über eine REST-API. Citadel verwaltet die Schlüssel – Generierung, Rotation, Widerruf, Zugriffskontrolle und Prüfprotokollierung.

Status: Funktionierende Implementierung. Nicht auditiert. Keine Produktionsbereitstellungen. Siehe Sicherheit unten.

---

Was es tut

Your Application              Citadel                         Database
       |                         |                               |
       |-- POST /encrypt ------->|                               |
       |                         |-- hybrid KEM (X25519+ML-KEM)  |
       |                         |-- derive AES-256 key (HKDF)   |
       |                         |-- encrypt with AES-256-GCM    |
       |<-- encrypted blob ------|                               |
       |                                                         |
       |-- store blob ------------------------------------------>|

Ihre Anwendung berührt niemals das rohe Schlüsselmaterial. Der verschlüsselte Blob ist in sich geschlossen – er enthält den verpackten Schlüssel, Algorithmuskennungen und den Chiffrattext. Speichern Sie ihn in jeder Datenbank. Entschlüsseln Sie ihn, indem Sie ihn mit derselben AAD und demselben Kontext an Citadel zurücksenden.

Architektur

citadel-envelope    Hybridverschlüsselungskern (X25519 + ML-KEM-768 + AES-256-GCM)
citadel-keystore    Schlüssel-Lebenszyklusverwaltung, 4-stufige Hierarchie, bedrohungsadaptive Richtlinien
citadel-api         HTTP-Server, bereichsspezifische API-Schlüssel-Authentifizierung, Ratenbegrenzung, Echtzeit-Dashboard

Schnellstart

Docker (empfohlen)

# Klonen
git clone https://github.com/mrcord77/rust_citadel.git
cd rust_citadel

# Ihren Admin-API-Schlüssel festlegen
echo -n "your-secret-key" | sha256sum | cut -d' ' -f1
# Kopieren Sie den Hash

# Starten
CITADEL_API_KEY_HASH=<eingefügter-hash> docker compose up -d

# Prüfen
curl http://localhost:3000/health
# {"status":"ok","version":"0.2.0"}

Dashboard: http://localhost:3000

Aus dem Quellcode

Erfordert Rust 1.75+.

cargo build --release -p citadel-api
CITADEL_API_KEY="your-secret-key" CITADEL_SEED_DEMO=true ./target/release/citadel-api

Verwendung

Python

import requests

api = "http://localhost:3000"
headers = {"Authorization": "Bearer your-secret-key"}

# Verschlüsseln
r = requests.post(f"{api}/api/keys/{dek_id}/encrypt", headers=headers, json={
    "plaintext": "sensitive data",
    "aad": "record-001",        # bindet Chiffrattext an diesen Datensatz
    "context": "patient-records" # Bereichstrennung
})
blob = r.json()

# Entschlüsseln
r = requests.post(f"{api}/api/decrypt", headers=headers, json={
    "blob": blob,
    "aad": "record-001",
    "context": "patient-records"
})
plaintext = r.json()["plaintext"]

Siehe citadel_example.py für ein vollständiges Arbeitsbeispiel mit AAD-Bindung, Schlüsselrotation und bedrohungsbewusstem Anwendungsverhalten.

curl

# Status
curl http://localhost:3000/api/status -H "Authorization: Bearer $KEY"

# Schlüssel auflisten
curl http://localhost:3000/api/keys -H "Authorization: Bearer $KEY"

# Verschlüsseln
curl -X POST http://localhost:3000/api/keys/$DEK_ID/encrypt \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"plaintext":"hello","aad":"test","context":"demo"}'

API-Endpunkte

Endpunkt	Methode	Bereich	Beschreibung
/health	GET	—	Health-Check
/api/status	GET	read	Bedrohungsstufe, Schlüsselanzahl
/api/metrics	GET	read	Sicherheitsmetriken
/api/keys	GET	read	Alle Schlüssel auflisten
/api/keys	POST	manage	Neuen Schlüssel generieren
/api/keys/:id	GET	read	Schlüsseldetails abrufen
/api/keys/:id/activate	POST	manage	Einen ausstehenden Schlüssel aktivieren
/api/keys/:id/rotate	POST	manage	Schlüssel rotieren (neue Version)
/api/keys/:id/revoke	POST	manage	Schlüssel dauerhaft widerrufen
/api/keys/:id/destroy	POST	manage	Schlüsselmaterial vernichten
/api/keys/:id/encrypt	POST	encrypt	Daten verschlüsseln
/api/decrypt	POST	encrypt	Daten entschlüsseln
/api/threat	GET	read	Bedrohungsinformationen im Detail
/api/policies	GET	read	Aktive Schlüsselrichtlinien
/api/auth/whoami	GET	read	Aktuelle API-Schlüssel-Informationen
/api/auth/keys	GET	admin	API-Schlüssel auflisten
/api/auth/keys	POST	admin	API-Schlüssel erstellen
/api/auth/keys/:id	DELETE	admin	API-Schlüssel widerrufen

Schlüsselhierarchie

Root Key
  └── Domain Key (pro Umgebung / Geschäftseinheit)
        └── KEK — Key Encrypting Key (umhüllt DEKs)
              └── DEK — Data Encrypting Key (verschlüsselt Anwendungsdaten)

Folgt NIST SP 800-57. Jede Ebene begrenzt den Schadensradius einer Kompromittierung – ein durchgesickerter DEK legt keine anderen DEKs offen, da der KEK separat ist.

API-Schlüssel-Bereiche

Bereich	Berechtigungen
read	Schlüssel, Status, Metriken, Bedrohungsstufe anzeigen
encrypt	Daten verschlüsseln und entschlüsseln
manage	Schlüssel erstellen, rotieren, widerrufen, vernichten
admin	Alles oben Genanntes + API-Schlüssel verwalten

admin impliziert alle anderen Bereiche. Prinzip der geringsten Privilegien: Geben Sie Überwachungs-Dashboards read, Anwendungsdiensten read + encrypt, Verwaltungswerkzeugen admin.

Adaptives Bedrohungssystem

Citadel überwacht Sicherheitsereignisse und passt die Schlüsselrichtlinien automatisch an:

Stufe	Auslöser	Reaktion
LOW	Normalbetrieb	Standard-Kryptoperioden
GUARDED	Geringfügige Anomalien	Etwas engere Rotation
ELEVATED	Verdächtige Muster	Verkürzte Rotationspläne
HIGH	Aktive Bedrohungsindikatoren	Erzwungene Rotation, reduzierte Nutzungsbeschränkungen
CRITICAL	Unter Angriff	Maximale Einschränkungen

Ereignisse, die die Bedrohungsstufe erhöhen: fehlgeschlagene Authentifizierung, Entschlüsselungsfehler, schnelle Zugriffsmuster, manuelle Eskalation. Der Wert nimmt mit der Zeit ab.

Kryptographie

Komponente	Algorithmus	Standard
Schlüsselkapselung (klassisch)	X25519 ECDH	RFC 7748
Schlüsselkapselung (post-quanten)	ML-KEM-768	FIPS 203
Datenverschlüsselung	AES-256-GCM	NIST SP 800-38D
Schlüsselableitung	HKDF-SHA256	NIST SP 800-56C

Hybride Konstruktion: Beide gemeinsamen Geheimnisse werden konkateniert und durch HKDF geführt. Die Sicherheit bleibt erhalten, wenn entweder X25519 oder ML-KEM-768 sicher bleibt.

Drahtformat

version[1] || suite_kem[1] || suite_aead[1] || flags[1] || kem_ct_len[2] ||
x25519_ephemeral_pk[32] || mlkem768_ct[1088] || nonce[12] || aead_ct[variable]

Selbstbeschreibend, versioniert, keine Aushandlung (verhindert Downgrade-Angriffe). Siehe SPEC.md für die vollständige Spezifikation.

Sicherheitseigenschaften