Verschlüsselung: das Schutzmodell im Klartext
Was mit einem hochgeladenen Bundle passiert, sollte kein Rätsel sein. Diese Seite beschreibt die reale Verschlüsselung des OKF Knowledge Hub – was geschützt ist, wie, und ausdrücklich auch, was nicht geschützt ist. Ehrlichkeit an dieser Stelle ist wichtiger als ein starkes Wort auf dem Marketing-Blatt.
Ein Hinweis zum Namen. Diese Seite hieß im Entwurf „Client-Side AES-GCM". Das war falsch. Die Verschlüsselung läuft serverseitig, pro Nutzer. Der Text unten beschreibt, was der Code tatsächlich tut.
Das Modell in einem Absatz
Jeder Nutzer bekommt einen eigenen Schlüssel, abgeleitet aus einem geheimen Master-Key und der stabilen Google-Konto-ID. Damit werden seine Bundles mit AES-256-GCM verschlüsselt, bevor sie den Speicher erreichen. Der Objektspeicher (S3) hält ausschließlich Chiffretext. Klartext existiert nur flüchtig, innerhalb einer authentifizierten Anfrage des Eigentümers – genau dann, wenn der Hub für ihn die Bibliothek rendert, den Graphen baut oder eine RAG-Antwort erzeugt. Einen Admin-Weg, der fremden Klartext liest, gibt es nicht.
Die Schlüsselableitung
Es gibt keinen einzelnen Schlüssel für alle. Aus dem serverseitigen OKF_MASTER_KEY und der stabilen Google-sub des Eigentümers leitet der Hub per HKDF-SHA256 einen 256-Bit-Schlüssel je Nutzer ab (Key-Encryption-Key). Zwei Nutzer haben damit verschiedene Schlüssel, auch wenn derselbe Master zugrunde liegt. Die API prüft bei jedem Zugriff zusätzlich, ob die angemeldete Person Eigentümerin des angeforderten Bundles ist.
Die Verschlüsselung selbst
Verschlüsselt wird mit AES-256-GCM, einem authentifizierten Verfahren: Es schützt zugleich die Vertraulichkeit und die Integrität der Daten. Jeder Vorgang zieht einen frischen 12-Byte-Initialisierungsvektor. Das gespeicherte Objekt ist ein einzelner Puffer in fester Reihenfolge:
[ 12-Byte IV ][ 16-Byte GCM-Auth-Tag ][ Chiffretext / ciphertext ]Der Auth-Tag lässt beim Entschlüsseln erkennen, ob am Chiffretext manipuliert wurde – eine veränderte Datei entschlüsselt nicht, sie schlägt fehl. Nicht nur die Bundles selbst werden so geschützt, sondern auch der semantische Vektorindex jedes Bundles, der verschlüsselt neben dem Bundle liegt.
Was das schützt
Diese Architektur schützt gespeicherte Dateien vor einfachem Klartextzugriff im Speicher-Backend: Wer nur den S3-Bucket sieht, sieht Chiffretext. Und sie trennt die Bundles sauber nach Konto – der Schlüssel des einen Nutzers entschlüsselt die Daten des anderen nicht. Zusammen mit der Eigentümerprüfung an den Endpunkten ergibt das eine klare Grenze zwischen den Wissensbasen verschiedener Nutzer.
Was es nicht ist
Das Wichtigste zuerst: Dies ist keine Zero-Knowledge- und keine Ende-zu-Ende-Verschlüsselung. Die Serveranwendung verfügt über das nötige Schlüsselmaterial und entschlüsselt Inhalte für autorisierte Funktionen – anders könnte sie weder die Bibliothek rendern noch RAG rechnen. Wer ein Vertrauensmodell braucht, in dem der Betreiber die Inhalte technisch nicht lesen kann, findet es hier nicht. Für ein solches Modell müsste der Schlüssel beim Nutzer bleiben und der Server nur Chiffretext sehen.
Daraus folgt die praktische Regel, die auch in der Anleitung steht: Laden Sie keine Passwörter, privaten Schlüssel, Zugangstokens oder Daten hoch, deren Speicherung auf einem fremden Server nicht zulässig ist. Und nutzen Sie den KI-Assistenten nicht mit Inhalten, die nicht an OpenRouter und den gewählten Modellanbieter übermittelt werden dürfen – denn eine Chat-Anfrage verlässt die serverseitige Grenze bewusst.
Die semantische Suche bleibt lokal
Ein Punkt, der oft übersehen wird: Die Embeddings für die semantische Suche rechnet ein lokales Modell auf dem Server. Für den Aufbau des Vektorindex verlässt kein Inhalt die Maschine. Der Index wird verschlüsselt gespeichert. Erst der KI-Chat überträgt Frage und ausgewählte Auszüge nach außen – alles davor bleibt innerhalb der serverseitigen Grenze.
Auf der Roadmap
Zwei Dinge sind bewusst noch offen und stehen im Changelog. Erstens die Schlüsselrotation: Aktuell verschlüsselt der Per-User-Schlüssel die Bundles direkt, ohne eine zwischengeschaltete Datenschlüssel-Hülle (Envelope). Eine solche Hülle wäre nötig, wenn Schlüssel regelmäßig rotiert werden sollen – sie kommt, wenn Rotation wirklich gebraucht wird. Zweitens ein optionales clientseitiges Verschlüsselungsmodell für Nutzer, die dem Server nicht vertrauen wollen; das wäre ein anderes Produkt und ist heute nicht implementiert.
Weiter im Thema
Wie Anmeldung, Speicherung und AI-Verarbeitung im Alltag zusammenspielen, steht im Abschnitt Datenschutz und Sicherheit der Anleitung. Bekannte Grenzen und Fehlerfälle behandelt die Fehlerbehebung.
Beschreibung nach der realen lib/crypto.js und server.js dieses Projekts: HKDF-SHA256-Per-User-KEK, AES-256-GCM, Layout [IV][Tag][Chiffretext], Chiffretext-only auf S3. Stand 2. August 2026. / Description per this project's real lib/crypto.js and server.js.