01 · Schutzpfade
„Der Tresor“ umfasst
unterschiedliche Mechanismen.
Im geprüften FlameP-Code stehen drei unterschiedliche technische Pfade: ein lokal verschlüsselter Vault, eine im Browser geschützte Kommunikationsschlüssel-Hierarchie und der serverseitige persönliche Cloud-Tresor. Ihre Eigenschaften sind nicht austauschbar.
Was welcher Mechanismus schützt| Pfad | Gefundener Mechanismus | Geltungsbereich |
|---|
| Lokaler Vault | Zufälliger 256-Bit-Tresorschlüssel; passphrasengeschützte Schlüsselhülle mit Argon2id und AES-256-GCM. | Die Aufrufer dieses lokalen Vault-Moduls. Der Modulname beweist noch nicht seinen Ausführungsort. |
| Kommunikationsschlüssel | 32-Byte-Geheimnis, im Browser über PBKDF2 und AES-GCM verpackt; HKDF für zweckgebundene Kommunikationsschlüssel. | Kommunikationszustand mit dem Zweck DIRECT_MESSAGES_STATE_V1. Keine pauschale Verschlüsselung sämtlicher Cloud-Dateien. |
| Persönlicher Cloud-Tresor | Serverseitige Passwort- und Faktorprüfung, zeitlich gebundene Zugriffe, Owner-Zuordnung und persönliche Datenbankumgebung. | Zugriff auf Dateien und persönliche Verarbeitung. Der untersuchte Dokumentpfad verarbeitet lesbare Inhalte auf dem Server. |
Der lokale Vault hat eine konkrete Verschlüsselungsimplementierung. Die Cloud-Zugriffsprüfung ist eine andere Schutzschicht. Wer beide gleichsetzt, beschreibt die Sicherheit falsch.
02 · Die entscheidende Frage
Was bedeutet
vollständige Serverkontrolle?
Ein Nutzerkonto, ein Anwendungsdienst und der Administrator des Betriebssystems haben unterschiedliche Macht. Eine Berechtigungsprüfung schützt vor Aufrufen ohne gültige Freigabe. Ein Angreifer mit vollständiger Kontrolle über den ausführenden Host kann zusätzlich Programme verändern und laufende Verarbeitung beobachten.
Die Zugriffsebenen im Vergleich| Zugriffsebene | Was sie ermöglicht | Was daraus folgt |
|---|
| Normales FlameP-Konto | Aufrufe innerhalb der geprüften Konto-, Tresor- und Sitzungsrechte. | Ein angemeldetes Konto erhält dadurch keine fremden Tresorrechte. |
| Kopie verschlüsselter Daten | Auswertung des Ciphertexts und der mitkopierten Metadaten. | Ohne passenden Schlüssel oder erfolgreich erratenes Entsperrgeheimnis bleibt korrekt verschlüsselter Inhalt unlesbar. |
| Anwendungsprozess | Zugriff auf seine Eingaben, Ausgaben und im Prozess erreichbare Schlüssel. | Was dieser Prozess im Klartext verarbeitet, liegt innerhalb seiner Vertrauensgrenze. |
| Vollständige Host-Administration | Kontrolle über gewöhnliche Prozesse, Konfiguration und ausgelieferte Software. | Vom selben Host durchgesetzte Softwareprüfungen allein schließen diesen Administrator nicht kryptografisch aus. |
Was der geprüfte Cloud-Pfad tatsächlich macht
- Das Entsperrpasswort erreicht den Server.
handleUnlock() liest den Request-Body und übergibt body.password an verifyVaultSecurity(). Der Server erhält für diesen Vorgang das Passwort als verarbeitbaren Wert. Ein Passwort-Hash schützt die gespeicherte Prüfkopie; er entfernt das Passwort nicht aus diesem Vorgang.
- Der Server prüft Passwort und zweiten Faktor.
Die Prüfung verwendet den gespeicherten Passwort-Hash sowie einen optional eingerichteten TOTP-Faktor. Bei Erfolg erzeugt sie eine Zugriffsfreigabe für die Sitzung.
- Der Dokumentpfad verarbeitet Originaldateien.
Der serverseitige Intake dekodiert die übergebenen Dateibytes und ruft die Inhaltsextraktion auf. Damit stehen die zu extrahierenden Inhalte dem ausführenden Serverprozess zur Verfügung. Base64 ist eine Kodierung, keine Verschlüsselung.
Für diesen geprüften Cloud-Pfad ist die Aussage „FlameP kann selbst mit vollständiger Serverkontrolle nicht zugreifen“ falsch.
Das ist eine Folgerung aus dem Datenfluss: Wer den verarbeitenden Prozess kontrolliert, kann dessen lesbare Eingaben erreichen. Daraus folgt keine Aussage, dass Mitarbeiter tatsächlich Inhalte gelesen haben. Es beschreibt die technische Möglichkeit.
Warum helfen hier weder HTTPS noch ein Container allein?
HTTPS schützt die Übertragung bis zu ihrem Endpunkt. Der empfangende Server verarbeitet danach die entschlüsselten Anwendungsdaten. Container und getrennte Prozesse begrenzen gewöhnliche Dienstzugriffe. Der Administrator des gemeinsamen Hosts liegt außerhalb dieser gewöhnlichen Dienstgrenze.
Auch „keine dauerhafte Speicherung“ und „kein zentraler Masterkey“ schließen das Abfangen während einer laufenden Verarbeitung nicht aus.
Was ist mit einem gestohlenen verschlüsselten Backup?
Das ist eine andere Angriffssituation. Ein Angreifer mit einer verschlüsselten Datenkopie und ohne nutzbaren Schlüssel besitzt keinen laufenden Entsperrprozess. Verschlüsselung mit ausreichend starken Schlüsseln schützt genau gegen solche Datenkopien. Ob ein konkretes Backup diese Voraussetzungen erfüllt, bestimmt dessen tatsächliches Daten- und Schlüsselmaterial.
03 · Kryptografie
Die Schlüsselmechanik.
Mit konkreten Parametern.
Lokaler Vault: zufälliger Schlüssel, geschützte Hülle
Beim Anlegen erzeugt das lokale Modul einen zufälligen Schlüssel mit 32 Byte. Dieser Schlüssel verschlüsselt Inhalte. Aus der Passphrase wird mit Argon2id ein separater Verpackungsschlüssel abgeleitet. Dieser schützt den Tresorschlüssel mit AES-256-GCM. Der gespeicherte Deskriptor enthält die verschlüsselte Schlüsselhülle, Salt, Parameter und eine verschlüsselte Prüfkonstante.
Lokaler Vault · Deskriptor V2| Baustein | Wert im Code | Bedeutung |
|---|
| Tresorschlüssel | 32 zufällige Byte / 256 Bit | Der Inhaltschlüssel wird unabhängig von der Passphrase erzeugt. |
| Passwortableitung | Argon2id | Erzeugt den Verpackungsschlüssel. |
| KDF-Parameter | 65.536 KiB Speicher, 3 Durchläufe, Parallelität 1 | Erschweren massenhaftes Passwort-Raten; garantieren kein starkes Nutzerpasswort. |
| Salt | 16 zufällige Byte | Getrennte Ableitung auch bei gleichen Passphrasen. |
| Verschlüsselung | AES-256-GCM | Vertraulichkeit und Authentizitätsprüfung der geschützten Daten. |
| Kontextbindung | AAD mit getrennten Kennungen für Schlüsselhülle und Prüfwert, jeweils inklusive Vault-Pfad | Die Entschlüsselung prüft den gebundenen Kontext. |
| Schlüsselzustand nach Öffnen | Prozessinterne Map unlockedKeys | Der ausführende Prozess hält eine verwendbare Schlüsselkopie. |
| Sperren | Puffer überschreiben und Map-Eintrag löschen | Entfernt die vom Modul gehaltene Schlüsselkopie. Weitere Kopien außerhalb dieses Puffers werden damit nicht automatisch erfasst. |
Was beim Passwortwechsel passiert
Das Modul öffnet den vorhandenen Tresorschlüssel mit der bisherigen Passphrase und verpackt ihn unter der neuen Passphrase neu. Die Inhalte werden dabei nicht neu verschlüsselt; der Code meldet ausdrücklich vault_content_reencrypted: false.
Das ist effizient, weil der Inhaltschlüssel erhalten bleibt. War dieser Inhaltschlüssel bereits kopiert, macht der reine Passwortwechsel die gestohlene Kopie nicht unbrauchbar.
Kommunikationsschlüssel: Browser und zweckgebundene Ableitung
Der Browser erzeugt ein 32-Byte-Geheimnis. Ein aus dem Passwort abgeleiteter AES-Schlüssel verpackt dieses Geheimnis. Die Hülle ist zusätzlich an Tresor-ID, Owner-ID, Schlüssel-ID und Format gebunden. Aus dem geöffneten Geheimnis leitet HKDF Schlüssel für den Kommunikationszustand einer Welt und eines Geräts ab.
Browser-Kommunikationsschlüssel · V1| Baustein | Wert im Code | Geltungsbereich |
|---|
| Passwort-KDF | PBKDF2-SHA-256, 310.000 Iterationen | Verpackung des Kommunikationsgeheimnisses. |
| Salt | 32 zufällige Byte | Passwortgebundene Hülle. |
| Hülle | AES-GCM, 256-Bit-Schlüssel, 12-Byte-IV, 128-Bit-Tag | Kommunikationsgeheimnis und gebundener Kontext. |
| Ableitung | HKDF-SHA-256; Zweck DIRECT_MESSAGES_STATE_V1 | Welt- und gerätespezifischer Kommunikationszustand. |
| Geöffneter Schlüssel | Nicht exportierbarer WebCrypto-HKDF-Schlüssel in IndexedDB | An Owner, Tresor, Lease, Schlüssel-ID und Ablauf gebunden. |
| Sperrung | Cache entfernen, Generation erhöhen, andere Tabs benachrichtigen | Verhindert die reguläre weitere Verwendung über diesen Clientpfad. |
„Nicht exportierbar“ beschränkt den Schlüssel-Export über WebCrypto. Es verhindert nicht automatisch, dass bösartiger Code im berechtigten Browserkontext den Schlüssel für erlaubte Operationen benutzt.
Diese Kommunikationsverschlüsselung ist kein Nachweis für Ende-zu-Ende-Verschlüsselung aller Cloud-Dokumente.
04 · Zugriffsschutz
Berechtigungen begrenzen
die regulären Zugriffe.
Die Cloud-Tresor-Route prüft Sitzung und Tresorzuordnung. Der Dateipfad weist widersprechende Nutzer-, Owner-, Konto- oder Tresor-IDs zurück und prüft die Zielidentität anhand des Datenbankmanifests. Dateioperationen laufen über die persönliche Verarbeitung und deren Autorisierung.
Passwortprüfung und Faktor
Der serverseitige Passwort-Hash verwendet scrypt mit N=32768, r=8, p=1, 64 Byte Ausgabe und einem zufälligen 16-Byte-Salt. Das ist ein Passwortprüfverfahren. Es verschlüsselt keine Dokumentinhalte.
Bei eingerichtetem TOTP verlangt die Entsperrprüfung zusätzlich einen sechsstelligen Code. Die Implementierung verwendet 30-Sekunden-Schritte, prüft das aktuelle und die beiden benachbarten Zeitfenster und weist bereits verbrauchte Zähler zurück. Nach fünf Fehlversuchen setzt sie eine fünfminütige Sperre.
Sitzungen und Inaktivität
Die Route definiert eine Zugriffs-TTL von einer Stunde. Für die Inaktivität akzeptiert die Einstellungsfunktion 60, 300, 900, 1.800 oder 3.600 Sekunden. Welche Auswahl ein konkreter Nutzer gesetzt hat, ist davon getrennt. Sperren und Sitzungswiderruf entziehen Anwendungsberechtigungen.
Eigene Runtime
Der Cloud-Runtime-Code definiert eine eigene Runtime-ID, ein eigenes Datenverzeichnis und einen internen Unix-Socket. Öffentliche PostgreSQL-Listener sind in dieser Konfiguration ausgeschaltet. Die Datenbankauthentifizierung verwendet SCRAM-SHA-256; SQL- und Parameterlogging sind eingeschränkt.
Diese Maßnahmen schützen Dienst- und Nutzergrenzen. Sie machen einen vom Host kontrollierten Prozess nicht unabhängig vom Host-Administrator.
05 · Wiederherstellung
Recovery verändert Zugang.
Es braucht eigene Grenzen.
Die geprüfte Sicherheitsimplementierung verwaltet acht Recovery-Code-Einträge. Sie speichert Code-Hashes sowie gegebenenfalls eine geschützte Hülle des Kommunikationsschlüssels. Die Einträge sind an dessen Schlüssel-ID gebunden.
Bei erfolgreicher Verwendung aktualisiert der Server Passwort-Hash und Kommunikationsschlüssel-Deskriptor, markiert den Code als benutzt und erhöht die Zugriffsgeneration. Der Vorgang entfernt außerdem den vorhandenen TOTP-Zustand. Ein wiederholter Aufruf wird nur als bestätigte Wiederholung anerkannt, wenn Vorgangs-ID, neuer Passwortnachweis und Deskriptorbindung zusammenpassen.
Ein Recovery-Vorgang ist eine Änderung an der Sicherheitsgrenze – nicht nur eine E-Mail.
Die ältere Recovery-WO verlangt ausdrücklich eine Wiederherstellung ohne Betreiber-Entschlüsselungszugriff. Die serverseitige Verwaltung der Wiederherstellung ist dafür allein kein Beweis. Entscheidend bleibt, ob ein Administrator die Prüfung verändern oder das neue Entsperrgeheimnis beim nächsten Vorgang erfassen kann.
Wo liegt das Geheimnis des zweiten Faktors?
Die TOTP-Geheimnisse werden im geprüften Servermodul mit AES-256-GCM verschlüsselt. Den dafür verwendeten 32-Byte-Speicherschlüssel liest der Server aus einer betrieblichen Schlüsseldatei. Das schützt die Datenbankkopie allein vor unmittelbar lesbaren TOTP-Geheimnissen.
Ein Administrator mit Zugriff auf diesen Schlüssel und die verschlüsselten TOTP-Daten kann sie entschlüsseln. Dieser Speicherschlüssel ist kein nachgewiesener Masterkey für sämtliche Tresorinhalte; er hat den konkreten Zweck, TOTP-Geheimnisse zu schützen.
Auch hier gilt: Ein Backup stellt Daten wieder her. Ein Recovery-Verfahren stellt einen Zugang wieder her. Beide Vorgänge sind nur dann erfolgreich, wenn ihre jeweils benötigten Daten und Schlüssel verfügbar sind.
06 · Dokumente & KI
Wo Inhalte verarbeitet werden,
werden Inhalte verständlich.
Der untersuchte persönliche Dokument-Intake läuft auf dem Server. Er übernimmt Dateibytes, lässt sie prüfen und extrahiert Textabschnitte. Die Dateileseroute liefert Originalinhalt als Base64 sowie Vorschautext zurück. Dafür greifen Owner-, Sitzungs- und Scope-Prüfungen.
Eine solche Autorisierung sagt, wer einen regulären Abruf ausführen darf. Sie verändert nicht die Tatsache, dass der ausführende Prozess Inhalte lesen kann. Eine zusätzliche Festplattenverschlüsselung beseitigt diese Klartextgrenze während des Betriebs ebenfalls nicht.
Die Freigabe an eine KI ist ein weiterer Übergang
Ein externer Anbieter erhält den für die Aufgabe übermittelten Inhalt. Die Tresorsperre holt diese Kopie nicht zurück. Speicherfristen, Weiterverwendung und Löschung bei diesem Empfänger richten sich nach der tatsächlich gewählten Verarbeitung.
Das vorhandene Produktkonzept verlangt den kleinsten nützlichen freigegebenen Kontext, eine sichtbare Entscheidung bei Erweiterungen und keinen stillen Wechsel zu einem weniger privaten Anbieter. Diese Anforderungen sind eigenständig zu prüfen; die vorliegende Quellcode-Lektüre ist kein vollständiger KI-Datenfluss-Test.
Zusammenfassungen, Suchindizes und Metadaten
Eine Zusammenfassung kann vertrauliche Information enthalten. Dasselbe gilt für Suchindizes und Embeddings. Der bestehende Derived-Data-Vertrag verlangt Schutzvererbung aus den Quellen. Konto-, Laufzeit- und Abrechnungsmetadaten bleiben ein eigener Datenbereich mit eigenen Zugriffs- und Aufbewahrungsregeln.
07 · Offenes Wissen, geheime Schlüssel
Bekannter Code
ist noch kein Schlüssel.
Ein Angreifer darf das Verfahren und seinen Quellcode kennen. Sichere Kryptografie hängt von geschützten Schlüsseln und korrekter Implementierung ab. Das öffentliche Wissen über AES-GCM oder Argon2id liefert den passenden geheimen Schlüssel nicht mit.
Quellcodekenntnis ermöglicht jedoch, Fehler, ungeschützte Übergänge und falsche Annahmen zu suchen. Deshalb muss das vollständige System betrachtet werden – einschließlich Entsperrung, Browser, Recovery und Softwareauslieferung.
Angriff und tatsächliche Grenze| Angriff | Was schützt | Was dadurch nicht verschwindet |
|---|
| Code vollständig bekannt | Geheime Schlüssel; etablierte, korrekt eingesetzte Verfahren. | Implementierungsfehler und schwache Passwörter. |
| Verschlüsselte Schlüsselhülle gestohlen | Passphrase und KDF verteuern das Raten. | Offline-Raten wird nicht durch die Sperre einer Web-Anmeldung begrenzt. |
| Konto übernommen | Zusätzliche Tresorprüfung und gegebenenfalls TOTP. | Mitgestohlene Faktoren oder bereits offene Sitzungen. |
| Vollständige Serverübernahme | Nur eine außerhalb dieser Kontrolle liegende Schlüssel- und Verarbeitungsgrenze kann Klartext zuverlässig entziehen. | Der geprüfte Cloud-Dokumentpfad verarbeitet Klartext innerhalb der Servergrenze. |
| Manipulierter Webcode | Eine unabhängig abgesicherte Software-Vertrauenskette ist erforderlich. | Vom selben Betreiber veränderbarer Code kann die nächste Entsperrung oder erlaubte Schlüsselverwendung angreifen. |
| Schadsoftware auf dem Nutzergerät | Geräteschutz und begrenzte offene Sitzungen reduzieren das Risiko. | Bereits angezeigter oder im berechtigten Prozess lesbarer Inhalt. |
| Schlüsselverlust | Ein eingerichteter, gültiger kryptografischer Wiederherstellungsweg. | Ohne nutzbaren Schlüsselweg entschlüsselt eine Datensicherung sich nicht selbst. |
| Ausfall oder Datenzerstörung | Getrennte Sicherungen und ein funktionierender Restore. | Verschlüsselung allein garantiert keine Verfügbarkeit. |
08 · Die technische Betreibergrenze
Wann Serverkontrolle
den Inhalt nicht erreichbar macht.
Für ruhende verschlüsselte Daten ist die Bedingung klar: Dem kontrollierten Server fehlt jeder nutzbare Entschlüsselungsweg. Für das gesamte Produkt muss diese Trennung auch beim Öffnen, Verarbeiten, Wiederherstellen und Aktualisieren der Software bestehen.
- Schlüsselkontrolle liegt außerhalb der Betreiberrechte.
Der Betreiber kann weder den Schlüssel lesen noch eine Schlüsselhülle selbst öffnen. Ein ausschließlich nutzerseitiges Entschlüsselungsgeheimnis wird nicht gleichzeitig als Klartextpasswort an den kontrollierten Server gesendet.
- Klartext entsteht außerhalb der gewöhnlichen Serverkontrolle.
Eine Verarbeitung auf dem vertrauenswürdigen Nutzergerät hält ihren Klartext außerhalb des Servers. Eine hardwaregeschützte Serververarbeitung braucht zusätzlich einen überprüfbaren Mechanismus, der Schlüssel nur an die zugelassene Ausführung freigibt. Ein gewöhnlicher Container stellt diese Grenze nicht her.
- Die Softwareauslieferung darf diese Trennung nicht heimlich aufheben.
Ein Server, der beliebig neue Entsperrsoftware liefern kann, kann den nächsten Zugriff angreifen. Code-Integrität, Aktualisierung und Vertrauen in den ausgeführten Client gehören deshalb zur kryptografischen Betreibergrenze.
- Recovery, Backups und abgeleitete Daten behalten dieselbe Grenze.
Eine Supportfunktion, ungeschützte Sicherung oder lesbarer Suchindex darf keinen Ersatzweg zum Inhalt schaffen.
- Ausdrücklich freigegebene Empfänger bleiben sichtbar.
Wer Inhalte für eine externe Verarbeitung freigibt, verschiebt für diese Kopie die Vertrauensgrenze. Die Aussage über den verschlossenen Tresor darf diese Entscheidung nicht verdecken.
Diese Bedingungen erklären, wodurch ein technischer Ausschluss des Betreibers entsteht. Der oben beschriebene Cloud-Pfad erfüllt die vollständige Trennung nicht: Sein Server empfängt das Entsperrpasswort und verarbeitet Dokumentinhalte.
„Kein Zugriff erlaubt“ ist eine Berechtigungsregel.
„Kein Zugriff möglich“ verlangt eine Grenze außerhalb der Kontrolle des Angreifers.
09 · Nachvollziehbarkeit
Die Aussagen folgen
dem gelesenen Code.
Gelesen wurde der DEV-Stand 1066e884c106a51d210873044157d7cb66c81e7d, aufgelöst aus /srv/flamep/current. Die nachfolgenden Befunde beziehen sich auf diesen Stand. Die Produktionsumgebung und tatsächliche Nutzerinhalte wurden nicht untersucht.
Es wurden ausschließlich Softwaredateien gelesen. Keine Schlüsseldateien, Passwörter, Datenbankinhalte oder privaten Dokumente wurden geöffnet. Es fand kein Entschlüsselungsversuch und kein Angriffstest statt.
S1 · Cloud-Entsperrungapps/api/routes/personal-vault.route.mjshandleUnlock(): Request-Passwort an verifyVaultSecurity(); anschließend createAccessLease(). hashVaultPassword(): scrypt-Parameter. Der statische Routenvertrag nennt außerdem cryptographic_closed: false; die Bewertung beruht auf dem tatsächlichen Datenfluss, nicht allein auf diesem Flag.
S2 · Faktoren und Recoveryapps/api/routes/personal-vault-security-v11.mjsTOTP-Prüfung, Fehlversuchssperre, serverseitige Verschlüsselung der Faktor-Geheimnisse, Recovery-Code-Verbrauch und Erneuerung der Zugangsdaten.
S3 · Serververarbeitung persönlicher Dateienapps/api/routes/my-brain-personal-intake.route.mjsapps/api/routes/personal-vault-files-v1.mjsServerseitige Dekodierung und Extraktion von Dateiinhalten; Original- und Vorschautext-Lesepfad. Der Befund betrifft diese untersuchten Verarbeitungspfade.
S4 · Lokale Schlüsselhüllesrc/foundry/vault/vaultPassphraseKeyProvider.mjssrc/foundry/vault/vaultEnvelopeEncryption.mjsArgon2id, zufälliger Inhaltschlüssel, AES-256-GCM, Passphrasenwechsel, prozessinterne Schlüssel-Map und Sperren. Dies ist eine Modulanalyse, keine Übertragung seiner Eigenschaften auf den Cloud-Tresor.
S5 · Kommunikationsschlüssel im Browserapps/web/public/assets/personal-vault-communication-key.mjssrc/foundry/vault/vaultCommunicationKeyContract.mjsPBKDF2/AES-GCM-Hülle, HKDF-Zweckbindung, IndexedDB-Cache und Lease-Abgleich. Der Serververtrag verwaltet den geschützten Deskriptor.
S6 · Runtime-Trennungsrc/foundry/vault/cloudTresorRuntimeContract.mjsOpaque Kennung, persönliche Pfade, Unix-Socket und PostgreSQL-Konfigurationswerte.
Vorhandene ProduktvorgabenTresor-Recovery-WO V1.1 · 23.09.2026; First User Journey SOLL V1.1 · 18.09.2026; Technical Architecture Masterdeck V1 · 15.09.2026; Derived Data Security Design · 12.09.2026. Sie definieren insbesondere den angestrebten Ausschluss von Betreiber- und Admin-Entschlüsselungszugriff.
Allgemeine kryptografische GrundlagenOWASP · Cryptographic Storage ↗OWASP · Key Management ↗Fachliche Grundlagen für Verschlüsselungsgrenzen und Schlüssellebenszyklus; keine FlameP-Abnahme.
