Vertrauen ist gut, Mathematik ist besser: Warum Keycave der sicherste Ort für Ihre Geheimnisse ist

In der digitalen Sicherheit gibt es zwei Arten von Anbietern: Diejenigen, die versprechen, gut auf Ihre Daten aufzupassen (und dabei den Schlüssel besitzen), und diejenigen, die den Schlüssel technisch gar nicht besitzen können. Keycave gehört zur zweiten Kategorie.

Wir haben uns nicht nur gefragt: "Wie sichern wir unsere Server?", sondern: "Wie bauen wir ein System, bei dem selbst ein kompromittierter Server keine Gefahr darstellt?"

Die Antwort liegt in einer Architektur, die als Zero-Knowledge (Null-Wissen) bekannt ist.

Das "Blinder-Server"-Prinzip

Klassische Cloud-Speicher funktionieren wie ein Bankschließfach, zu dem auch der Bankdirektor einen Ersatzschlüssel hat. Keycave funktioniert anders:

1. Verschlüsselung beim Absender: Bevor eine Datei, ein Tresorcode oder eine Notiz Ihren Computer oder Ihr Smartphone verlässt, wird sie lokal verschlüsselt.
2. Der Tunnel: Die Daten reisen durch das Internet. Selbst wenn jemand diese Leitung anzapft (z.B. über den US Cloud Act bei Cloudflare), sieht er nur digitales Rauschen.
3. Die Lagerung: Unser Server (das Backend) empfängt dieses Rauschen und speichert es. Der Server weiß dass Sie etwas gespeichert haben, aber mathematisch gesehen kann er nicht wissen was es ist.

Szenario: Der Ernstfall

Lassen Sie uns den schlimmsten Fall annehmen ("Worst Case Scenario"):

• Szenario: Ein staatlicher Akteur beschlagnahmt die Server oder ein Administrator wird erpresst.
• Das Ergebnis: Die Angreifer finden in der Datenbank nur Spalten wie ciphertext und iv (Initialisierungsvektoren). Ohne Ihr Master-Passwort, das niemals übertragen wird, sind diese Daten wertlos. Es gibt keinen "Generalschlüssel" für uns als Anbieter.

Warum Georgien + Client-Side-Encryption?

Unser rechtlicher Sitz in Georgien schützt vor automatischen Durchgriffen europäischer oder amerikanischer Behörden. Doch Gesetze können sich ändern – Mathematik nicht. Selbst wenn wir gesetzlich zur Herausgabe gezwungen würden: Wir können nur verschlüsselte Datenblöcke herausgeben. Wir können nicht entschlüsseln, was wir nicht lesen können.

Wir sind jederzeit reaktionsfähig, sollte sich die Rechtslage ändern. Die Daten werden innerhalb des Bereichs der Datenschutz-Grundverordnung (DSGVO) bzw. der General Data Protection Regulation (GDPR) gehalten und unterliegen also dem strengen europäischen Datenschutz.

Architecture Review: Die Kryptografie hinter Keycave

Dieser Artikel beleuchtet die technische Implementierung der Keycave-Sicherheit basierend auf dem Frontend-Core und dem Backend-Handler. Das System setzt auf Client-Side Encryption unter Verwendung der nativen Web Crypto API (SubtleCrypto). Dies garantiert Performance und verhindert Angriffe auf veraltete JavaScript-Bibliotheken.

1. Der Krypto-Stack

Wir verwenden ausschließlich industrieerprobte Standards ohne "Home-Brewed Crypto":

• Algorithmus: AES-GCM (Galois/Counter Mode) mit 256-Bit Schlüssellänge.
• Integrität: GCM bietet authentifizierte Verschlüsselung (AEAD). Manipulationen am Ciphertext werden beim Entschlüsseln sofort erkannt (Tag mismatch), bevor Daten verarbeitet werden.
• Schlüsselableitung: PBKDF2 mit SHA-256.

2. Die Schlüssel-Hierarchie (Key Wrapping)

Keycave nutzt ein mehrstufiges Key-Wrapping-System, um Flexibilität (z.B. Passwortänderung ohne Neuverschlüsselung aller Daten) mit Sicherheit zu verbinden.

A. KEK (Key Encryption Key)
Der KEK wird nur im RAM des Clients erzeugt und nie gespeichert.

• Input: User Master-PIN + Salt (vom Server, cmk_wrap_salt_b64).
• Methode: PBKDF2, 200.000 Iterationen.
• Zweck: Dient nur dazu, den CMK zu entschlüsseln.

B. CMK (Customer Master Key)
Dies ist der Identitätsschlüssel des Nutzers (AES-256).

• Der CMK liegt verschlüsselt (gewrappt mit dem KEK) auf dem Server (cmk_wrapped_key_b64).
• Beim Login lädt der Client den Blob, nutzt den KEK zum Entpacken (unwrapKey) und hält den CMK im Session-Memory (KeyCaveSession).

C. DEK (Data Encryption Key)
Jeder Tresor (Vault) hat einen eigenen zufälligen AES-256 Schlüssel.

• Dieser DEK wird mit dem CMK des Nutzers verschlüsselt und als wrapped_dek_b64 in der Tabelle gespeichert.
• Vorteil: Wenn Sie einen Tresor teilen, verschlüsseln wir den DEK zusätzlich mit dem KEK des Empfängers (oder einem temporären Share-Key). Die eigentlichen Daten müssen nicht umgeschlüsselt werden.

3. Datenfluss & Zero-Knowledge Beweis

Ein Blick in den Code beweist die "Blindheit" des Servers:

1. Frontend: Das Skript generiert einen randomisierten IV (12 Bytes) und verschlüsselt die Datei via AES-GCM.
2. Transport: Der Browser sendet nur den encryptedBlob und die crypto_meta_json (enthält den IV) an den Server.
3. Backend: Der PHP-Code empfängt den Stream und speichert ihn direkt. Es findet keine serverseitige Krypto-Operation statt, da dem Server der DEK fehlt.
4. Datenbank: In der DB stehen lediglich Blobs. Selbst Dateinamen können (je nach Konfiguration im Frontend) verschleiert werden.

4. Schutz gegen Replay- & Man-in-the-Middle (Cloud Act)

Da wir Cloudflare als CDN nutzen, terminiert SSL theoretisch dort.

• Gefahr: Cloudflare könnte theoretisch den Traffic mitlesen (US Cloud Act).
• Mitigation: Da die Payload (POST Body) bereits im Browser AES-256 verschlüsselt wurde, sieht Cloudflare (und jede andere Instanz dazwischen) nur binären Müll. Die SSL-Verschlüsselung ist lediglich ein zusätzlicher Tunnel um den bereits verschlüsselten Datentransfer.

5. Sharing via OTP (One-Time-Pad Logik)

Beim Teilen (shareVaultWithOTP) passiert Folgendes im Client:

1. Ein zufälliges Passwort wird generiert (Client-Side).
2. Ein neuer KEK wird daraus abgeleitet.
3. Der Tresor-DEK wird mit diesem neuen KEK verschlüsselt (wrapped_dek_b64).
4. Der Server speichert diesen Wrap.
5. Der Clou: Das Passwort ist Teil des Links (Anchor/Hash) oder wird dem Nutzer angezeigt. Es wird nicht im Klartext an den Server gesendet (der Payload enthält nur wrapped_dek_b64, nicht das Passwort).

6. Post-Quanten-Kryptografie (PQC)

Fazit: Keycave verlässt sich nicht auf Server-Sicherheit, sondern auf Mathematik. Solange AES-256 als sicher gilt, sind Ihre Daten sicher – unabhängig davon, wer physischen Zugriff auf die Server hat.