Sicherheitsarchitektur — Arc OS

"Wir können deine Daten nicht lesen, selbst wenn wir es wollten"
Zero-Knowledge-Architektur mit Ende-zu-Ende-Verschlüsselung für Benutzerprivatsphäre.

Zuletzt aktualisiert: 2026-04-28 (Phase 45 — E2EE-Architektur FERTIG ✅)
Aktuelle Phase: 48 (Architektur-Dekomposition abgeschlossen)
Sicherheitsstatus: 🟢 GREEN (Phase 42 Multi-Tenancy + Phase 45 E2EE abgeschlossen)

Inhaltsverzeichnis

1. Sicherheitsmodell
2. Zero-Knowledge-Architektur ⭐ NEU (Phase 45)
3. Multi-Tenancy-Sicherheit (Phase 42)
4. Verschlüsselungsdetails
5. Schlüsselverwaltung
6. Angriffsfläche
7. Compliance
8. Audit-Historie

Sicherheitsmodell

Aktueller Zustand (Phase 48)

Authentifizierung & Autorisierung:

• ✅ JWT (HMAC-SHA256, 24h TTL)
• ✅ OAuth (Google, GitHub)
• ✅ Multi-Tenancy-Isolation (owner_id-Gates)
• ✅ Path-Traversal-Schutz
• ✅ SSRF-Allowlists
• ✅ CSP-Header (default-src 'self', X-Frame-Options: DENY)
• ✅ Sicherheits-Header (X-Content-Type-Options: nosniff, Referrer-Policy)

Daten im Ruhezustand (Phase 45 — FERTIG ✅):

• ✅ API-Keys verschlüsselt via Vault AES-256-GCM (encryptField/decryptField)
• ✅ Chat-Nachrichten im Ruhezustand in SQLite verschlüsselt (Migration 015, Auto-Encrypt/Decrypt)
• ✅ PII-Bereinigung in JSONL-Logs (E-Mails, API-Keys, JWTs, Kartennummern)
• ✅ Recovery-Key-Verwaltung (1Password-Stil XXXX-XXXX-XXXX-XXXX-XXXX)

Urteil: Sicher für Multi-Tenancy UND Benutzerprivatsphäre im Ruhezustand.

Implementierung (Phase 45 — Hybride Architektur)

Designentscheidung: Echtes Zero-Knowledge E2EE ist unmöglich, wenn der Server Daten verarbeiten muss (Claude CLI benötigt Klartext-API-Keys, Child Bot benötigt Klartext-Nachrichten für KI-Verarbeitung). Lösung: Hybrid-Ansatz — clientseitige Krypto-Grundlage + serverseitige At-Rest-Verschlüsselung.

Client (Browser):
  WebCrypto PBKDF2 (100k iter) → AES-256-GCM Master-Key
  Master-Key-Lebenszyklus: Login → sessionStorage → Logout/401 → löschen
  Recovery-Key: Master-Key verschlüsseln → auf Server speichern

Server (Bun + SQLite):
  vault.ts encryptField() → AES-256-GCM im Ruhezustand für API-Keys
  db.ts Auto-Encrypt/Decrypt → transparente Chat-Nachrichten-Verschlüsselung
  pii-sanitizer.ts → PII aus JSONL-Logs entfernen

Zero-Knowledge-Architektur

Phase 45 (FERTIG ✅ 2026-04-28) — Issues #16–#20

Designprinzip

Server ist nicht vertrauenswürdig. Selbst mit Root-SSH-Zugang zur Datenbank können Administratoren Benutzerdaten ohne das Passwort des Benutzers nicht entschlüsseln.

Vorbild: Signal-artiges E2EE, angepasst für KI-Workspace-Zusammenarbeit.

1. Master-Key-Ableitung

Das Benutzerpasswort leitet ZWEI unabhängige Schlüssel ab:

Benutzerpasswort
    │
    ├─ PBKDF2(password, "auth-salt", 100k Iterationen) 
    │     ↓
    │  authHash (nochmals mit bcrypt gehasht, Kosten 12)
    │     ↓
    │  An Server gesendet zur Authentifizierung (Login)
    │
    └─ PBKDF2(password, "master-salt", 100k Iterationen)
          ↓
       masterKey (AES-256-GCM Verschlüsselungsschlüssel)
          ↓
       NIEMALS an Server gesendet (bleibt im Browser-sessionStorage)

Sicherheitseigenschaft: Server kompromittiert → Angreifer erhält authHash → kann masterKey nicht ableiten (verschiedenes Salt).

2. Clientseitiger Verschlüsselungsfluss

Senden einer Chat-Nachricht:

// 1. Benutzer tippt im Browser
const plaintext = "sk-ant-abc123xyz (mein API-Key)";

// 2. Browser verschlüsselt mit Master-Key
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  masterKey,
  new TextEncoder().encode(plaintext)
);

// 3. Verschlüsselten Blob an Server senden (KEIN Klartext)
POST /api/crm/projects/arc-v2/chat {
  content_encrypted: base64(ciphertext),  // Server kann das nicht lesen
  content_iv: base64(iv)
}

Server-Speicherung (SQLite):

INSERT INTO chat_messages (content_encrypted, content_iv, timestamp)
VALUES (
  X'8a9f3c...blob...',  -- verschlüsselt, für Server undurchsichtig
  X'7b2e1a...iv...',
  '2026-04-24T10:30:00Z'
);

Admin fragt Datenbank ab:

SELECT content_encrypted FROM chat_messages WHERE id = 1;
-- Gibt zurück: Blob (ohne Master-Key bedeutungslos)

Nachricht empfangen:

// 1. Verschlüsselten Blob vom Server abrufen
const response = await fetch('/api/crm/projects/arc-v2/chat/history');
const messages = await response.json();

// 2. Browser entschlüsselt mit Master-Key
for (const msg of messages) {
  const plaintext = await crypto.subtle.decrypt(
    { name: "AES-GCM", iv: base64Decode(msg.content_iv) },
    masterKey,
    base64Decode(msg.content_encrypted)
  );
  console.log(new TextDecoder().decode(plaintext));
}

3. Was verschlüsselt wird

4. Server-Schema-Änderungen

Vorher (Phase 43):

CREATE TABLE chat_messages (
  id INTEGER PRIMARY KEY,
  content TEXT NOT NULL,  -- ❌ Klartext
  timestamp TEXT
);

Nachher (Phase 45):

CREATE TABLE chat_messages (
  id INTEGER PRIMARY KEY,
  content_encrypted BLOB NOT NULL,  -- ✅ AES-GCM Ciphertext
  content_iv BLOB NOT NULL,          -- ✅ Initialisierungsvektor
  timestamp TEXT,
  key_version INTEGER DEFAULT 1      -- für Schlüsselrotation
);

Multi-Tenancy-Sicherheit

Phase 42 (ABGESCHLOSSEN) — Vollständiger Audit-Bericht: docs/security/audit-2026-04-23.md

Isolationsmodell

Jeder Benutzer besitzt Projekte. Kein Benutzer kann auf Projektdaten eines anderen Benutzers zugreifen (außer Admin/CEO).

Gate-Funktion (canAccessProject):

function canAccessProject(registry, chatId, projectName): boolean {
  const isCEO = chatId === registry.ceo_chat_id;
  const user = userQueries.findById(chatId);
  const isAdmin = user?.role === 'admin';
  
  if (isCEO || isAdmin) return true;  // Superuser-Bypass
  
  // DB SSOT: owner_id-Prüfung
  const project = projectQueries.findByName(projectName);
  return project?.owner_id === chatId;
}

Angewendet auf:

• /api/crm/projects/:name/* (62+ Endpunkte)
• /api/sse/logs/:name, /api/sse/consultant/:name
• /ws/terminal/:name
• /api/cli/*, /api/mcp/* (Knowledge API)

Verteidigungsebenen (Netzwerk → Anwendung)

┌─────────────────────────────────────────────────────────────┐
│ Ebene 1: Infrastruktur                                      │
│   - Nur SSH-Key-Auth (kein Passwort)                       │
│   - Fail2ban (5 fehlgeschlagene Versuche → 10 min Sperre)  │
│   - UFW-Firewall (22, 80, 443 nur)                         │
├─────────────────────────────────────────────────────────────┤
│ Ebene 2: Netzwerk                                           │
│   - Bun bindet nur 127.0.0.1 (kein externer Zugang)        │
│   - Nginx Reverse Proxy (Pfadblockierungen: /.*, /config/, ...) │
│   - HTTPS (TLS 1.3) + HSTS                                 │
├─────────────────────────────────────────────────────────────┤
│ Ebene 3: Authentifizierung                                  │
│   - JWT (HMAC-SHA256, 24h TTL, vault-gespeichertes Secret)  │
│   - OAuth (Google, GitHub) mit CSRF-Token                  │
│   - E-Mail-Verifizierung (24h TTL)                         │
│   - Rate-Limiting (Login: 5/min)                           │
├─────────────────────────────────────────────────────────────┤
│ Ebene 4: Autorisierung                                      │
│   - Multi-Tenancy-Gates (owner_id-Prüfungen)               │
│   - Nur Admin: interaktives Terminal                        │
│   - Projekt-gebundene JWT-Token                            │
├─────────────────────────────────────────────────────────────┤
│ Ebene 5: Eingabe-Validierung                                │
│   - isValidProjectName-Regex                               │
│   - safePath (Path-Traversal-Verhinderung)                 │
│   - SSRF-Allowlist (HTTPS + Domain-Whitelist)              │
├─────────────────────────────────────────────────────────────┤
│ Ebene 6: Datenschutz (Phase 45)                             │
│   - E2EE (clientseitige Verschlüsselung)                   │
│   - Zero-Knowledge-Architektur                             │
│   - CSP-Header (XSS-Verhinderung)                          │
└─────────────────────────────────────────────────────────────┘

Phase-42-Patches (16 Fixes, alle abgeschlossen)

Urteil: 🟢 GREEN — Multi-User bereit (keine bekannten Privilege-Escalation-Vektoren)

Verschlüsselungsdetails

Algorithmen (Phase 45)

PBKDF2-Implementierung

// Auth-Hash (an Server gesendet)
const authKeyMaterial = await crypto.subtle.importKey(
  "raw",
  new TextEncoder().encode(password),
  "PBKDF2",
  false,
  ["deriveBits"]
);
const authBits = await crypto.subtle.deriveBits(
  {
    name: "PBKDF2",
    salt: new TextEncoder().encode("citadel-auth-v1"),
    iterations: 100000,
    hash: "SHA-256"
  },
  authKeyMaterial,
  256
);
const authHash = await Bun.password.hash(
  Buffer.from(authBits).toString("hex"),
  { algorithm: "bcrypt", cost: 12 }
);

// Master-Key (im Browser behalten)
const masterKeyMaterial = await crypto.subtle.importKey(
  "raw",
  new TextEncoder().encode(password),
  "PBKDF2",
  false,
  ["deriveKey"]
);
const masterKey = await crypto.subtle.deriveKey(
  {
    name: "PBKDF2",
    salt: new TextEncoder().encode("citadel-master-v1"),
    iterations: 100000,
    hash: "SHA-256"
  },
  masterKeyMaterial,
  { name: "AES-GCM", length: 256 },
  false,  // NICHT extrahierbar
  ["encrypt", "decrypt"]
);

AES-GCM-Verschlüsselung

// Verschlüsseln
const iv = crypto.getRandomValues(new Uint8Array(12));  // 96-Bit-Nonce
const ciphertext = await crypto.subtle.encrypt(
  {
    name: "AES-GCM",
    iv,
    tagLength: 128  // 128-Bit-Auth-Tag
  },
  masterKey,
  plaintext
);

// Entschlüsseln
const plaintext = await crypto.subtle.decrypt(
  { name: "AES-GCM", iv },
  masterKey,
  ciphertext
);

Warum AES-GCM?

• ✅ Authentifizierte Verschlüsselung (manipulationssicher)
• ✅ Hardware-beschleunigt (AES-NI auf x86)
• ✅ NIST-genehmigt, verwendet von Signal/WhatsApp/TLS 1.3

Schlüsselverwaltung

Lebenszyklus

┌──────────────────────────────────────────────────────────────┐
│ Registrierung / Erster Login                                 │
├──────────────────────────────────────────────────────────────┤
│  1. Benutzer gibt Passwort ein                               │
│  2. Browser leitet authHash + masterKey ab (PBKDF2)         │
│  3. authHash an Server senden (bcrypt → speichern)          │
│  4. masterKey in sessionStorage speichern (ephemer)         │
│  5. Recovery-Key generieren (masterKey verschlüsseln → Server speichern) │
│  6. Benutzer lädt Recovery-PDF herunter (MUSS GESPEICHERT WERDEN!) │
└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐
│ Nachfolgende Logins                                          │
├──────────────────────────────────────────────────────────────┤
│  1. Benutzer gibt Passwort ein                               │
│  2. authHash ableiten → an Server senden → verifizieren     │
│  3. masterKey ableiten → in sessionStorage speichern        │
│  4. Bereit zum Verschlüsseln/Entschlüsseln                  │
└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐
│ Logout / Tab schließen                                       │
├──────────────────────────────────────────────────────────────┤
│  sessionStorage.clear() → masterKey gelöscht                │
│  Kein Schlüssel = keine Datenentschlüsselung möglich        │
└──────────────────────────────────────────────────────────────┘

Recovery-Mechanismus

Problem: Passwort vergessen → masterKey verloren → Daten nicht wiederherstellbar.

Lösung: Recovery-Key (einmalig generiert, offline vom Benutzer gespeichert).

┌──────────────────────────────────────────────────────────────┐
│ Recovery-Key-Generierung                                     │
├──────────────────────────────────────────────────────────────┤
│  1. Zufälligen 128-Bit-Schlüssel generieren                  │
│     recoveryKey = crypto.getRandomValues(16 bytes)          │
│  2. Kodieren: "A83Z-KL9P-MM4X-VN2Q-8JC7" (20 Zeichen)       │
│  3. Master-Key verschlüsseln: AES-GCM(masterKey, recoveryKey) │
│  4. Verschlüsselten Master-Key auf Server speichern          │
│  5. Benutzer anzeigen: ⚠️ SPEICHERN ODER DATEN FÜR IMMER VERLIEREN │
│     [PDF herunterladen] [Drucken] [Gespeichert]             │
└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐
│ Recovery-Fluss                                               │
├──────────────────────────────────────────────────────────────┤
│  1. Passwort vergessen? → Recovery-Key eingeben             │
│  2. Verschlüsselten Master-Key vom Server abrufen           │
│  3. Master-Key mit Recovery-Key entschlüsseln               │
│  4. NEUES Passwort festlegen                                 │
│  5. authHash + masterKey aus neuem Passwort neu ableiten    │
│  6. Erfolg → Zugriff wiederhergestellt                      │
└──────────────────────────────────────────────────────────────┘

Rate-Limit: Max. 5 Recovery-Versuche pro Stunde (Brute-Force-Schutz).

Angriffsfläche

Geminderte Bedrohungen

Außerhalb des Umfangs (Benutzerverantwortung)

Compliance

DSGVO (EU-Verordnung 2016/679)

SOC 2 Typ II (Zukünftig)

Geplant für Enterprise:

• Zugriffsaudit-Trail
• Schlüsselrotations-Richtlinie (jährlich)
• Penetrationstests (vierteljährlich)
• Lieferantenrisikobewertung

Audit-Historie

INC-2026-06-11: Cryptominer auf Contabo-VPS (2026-06-11) — ⚠️ EINGEDÄMMT

Typ: Sicherheitsvorfall (kein Audit) Schweregrad: P0 — aktive Kompromittierung eines produktiv mitgenutzten Hosts Root Cause: Ein autonomer Dritt-Agent-Stack (OpenClaw), der die Arc-OS-Maschine mitnutzte, legte ein sudo-fähiges Konto (aiuser) an, in dem bereits ein Angreifer-SSH-Key hinterlegt war; unter diesem Konto lief ~76 Tage ein Monero-Miner mit 294 % CPU. Auswirkung auf Arc OS: nichts kompromittiert — Root sauber, Vault für aiuser nicht lesbar, kein laterales Pivoting. Nur gestohlene CPU. Status: eingedämmt (Bedrohung neutralisiert); vollständige Remediation (Contabo-Rebuild, OpenClaw-Entscheidung, Credential-Rotation) offen. Vollständiger Bericht: docs/security/incident-2026-06-11-contabo-miner.md · Issue #474

Phase 42: Multi-Tenancy-Sicherheit (2026-04-23)

Auditor: Sentinel (interner Security-Agent)
Umfang: Multi-Tenant-Isolation, SSRF, Path-Traversal, Eingabe-Validierung
Befunde: 16 Issues (alle behoben)
Urteil: 🟢 GREEN
Vollständiger Bericht: docs/security/audit-2026-04-23.md

Phase 43: UI/UX-Sicherheit (2026-04-24)

Auditor: Vanguard (Design + Accessibility)
Umfang: XSS-Vektoren, CSP-Lücken, Inline-Skripte
Befunde: 21 Issues (alle behoben)
Urteil: A- (95/100)
Vollständiger Bericht: docs/design/ui-ux-audit-2026-04-23.md

Phase 45: E2EE-Implementierung (2026-04-28)

Implementiert von: Product Owner + Claude
Umfang: At-Rest-Verschlüsselung, Recovery-Keys, CSP-Header, PII-Bereinigung
Unterphasen:

• 45.1 — WebCrypto-Fundament (frontend/src/crm/crypto/e2ee.ts, 214 Zeilen) ✅
• 45.2 — API-Key Vault-Verschlüsselung (shared/vault.ts encryptField/decryptField) ✅
• 45.3 — Chat-Nachrichten At-Rest-Verschlüsselung (Migration 015, db.ts Auto-Encrypt) ✅
• 45.4 — Recovery-Keys (Migration 016, 4 API-Endpunkte, RecoveryKeySection-UI) ✅
• 45.5 — CSP-Header + PII-Bereiniger (shared/pii-sanitizer.ts) ✅ Urteil: 🟢 Alle P0+P1-Punkte abgeschlossen. P2-Erweiterte-Features (Forward Secrecy, Multi-Device-Sync) verschoben.

Phase 45: E2EE-Penetrationstest (GEPLANT)

Auditor: Externer Pen-Tester (TBD)
Umfang: WebCrypto, Schlüsselverwaltung, Side-Channel-Lecks
Budget: 5.000 $
Zeitplan: Nach Abschluss von Phase 45

Kontakt

Sicherheitsprobleme: GitHub Security Advisory (private Meldung)
Allgemein: [email protected]
Bug-Bounty: 100 $–5.000 $ (Phase 46+)

Letzter Audit: Phase 45 E2EE (2026-04-28). Nächster: Externer Pen-Test.