Vault-Core, Schlüsselpfade, Steganographie
Dieses Whitepaper beschreibt die sicherheitsrelevanten Datenflüsse und Kontrollpunkte.
Technical Spec · Stand 5. Juli 2026
Security Whitepaper.
Dieses Whitepaper beschreibt den technischen Aufbau von BlindLock: Schlüsselhierarchie, Tresor-Lifecycle, Steganographie, Hardwarebindung, Post-Quantum-Komponenten, Netzwerkgrenzen, Recovery-Modell und bekannte Grenzen.
1. Scope und Verifikationsstatus.
Dieses Dokument ist eine produktnahe technische Spezifikation, kein unabhängiger Auditbericht. Es beschreibt, wie BlindLock konzeptionell aufgebaut ist und welche Schutzgrenzen öffentlich kommuniziert werden. Es ersetzt kein Penetration Testing, keine formale Prüfung der gesamten Anwendung und keine externe Code-Review.
Kein vollständiger App-Beweis
Formal verifiziert sind genutzte kryptographische Primitiven, nicht automatisch die ganze App.
Nächster Vertrauenshebel: Ein unabhängiger Security-Audit und ein öffentliches Implementierungs-Review würden diese Spezifikation stark aufwerten.
2. Designziele und Nicht-Ziele.
Kein Cloud-Tresor
Tresor-Inhalte sollen nicht auf BlindLock-Servern liegen. Ein Anbieter-Breach soll keine Tresordaten offenlegen können.
Datei allein reicht nicht
Eine kopierte Träger- oder Tresordatei soll ohne Passwort und gebundenes Gerät wertlos bleiben.
Keine offensichtliche Zielscheibe
Der vollständige Passwort-Tresor liegt steganografisch verborgen im PNG; Datei-Tresore tragen keine offensichtliche Tresor-Signatur.
Langfristige Krypto-Resilienz
Keine zentrale Tresor-Datenbank, die man ernten könnte; ruhende Dateien sind 256-Bit-symmetrisch verschlüsselt. Post-Quantum-Komponenten (ML-KEM-1024, ML-DSA-87) sind je Einsatzbereich dokumentiert.
Team- oder Enterprise-Sync
BlindLock priorisiert lokale Kontrolle vor zentraler Teamverwaltung oder nahtlosem Cloud-Sync.
Schutz gegen kompromittierte Hosts
Ein vollständig kompromittiertes Betriebssystem während einer offenen Sitzung kann Eingaben, Speicher oder Bildschirm angreifen.
3. Tresor-Lifecycle.
BlindLock trennt Einrichtung, Entriegelung, aktive Sitzung und Sperrung. Jede Phase hat andere Assets und andere Risiken.
Einrichtung:
1. Nutzer wählt PNG-Trägerdatei.
2. Nutzer wählt Passwort.
3. App versiegelt Geräte-Anker im TPM 2.0 oder in der Apple Secure Enclave.
4. Optionaler Sicherheitsschlüssel wird registriert.
5. Passwort-, Notiz-, 2FA- und Wallet-Einträge werden verschlüsselt im Träger verborgen.
6. Größere Dateien werden optional in einem separaten Datei-Tresor gespeichert.
Öffnen:
1. PIN passiert das langsame Argon2id-Eingangstor.
2. App liest den verschlüsselten Passwort-Tresor aus der Trägerdatei.
3. Passwort, passende Trägerdatei und Geräte-Anker werden in der Ableitung kombiniert.
4. Optionaler Security-Key bestätigt den Zugriff.
5. Tresor entschlüsselt nur im Arbeitsspeicher.
Sperren:
1. Sitzung wird beendet.
2. Entschlüsselte Inhalte werden aus dem Arbeitsspeicher entfernt.
3. Auf der Festplatte bleibt nur verschlüsselter Inhalt.
Wichtig: Die PIN ist ein Eingangstor zum hardware-versiegelten App-Anker. Die Tresor-Faktoren sind Datei, Passwort und Gerät; optional kommt ein Sicherheitsschlüssel hinzu.
4. Schlüsselhierarchie.
Die öffentliche Produktbeschreibung nennt drei Voraussetzungen für den Tresorzugriff: die passende Trägerdatei, das Nutzerpasswort und einen hardware-gebundenen Geräte-Anker. Aus ihnen wird Schlüsselmaterial für die Verschlüsselung abgeleitet.
Trägerdatei
Sie enthält den vollständigen verschlüsselten Passwort-Tresor und liefert zugleich den Dateifaktor. Ohne die passende Datei fehlt ein Faktor.
Passwort
Das Nutzerpasswort wird mit Argon2id speicherhart abgeleitet. Die Produktbeschreibung nennt je nach Gerät 512 MiB bis 4 GB für die Passwort-Härtung.
Geräte-Anker
Ein nicht exportierbarer Anker aus TPM 2.0 oder Apple Secure Enclave geht in die Ableitung ein. Dadurch ergibt dieselbe Datei mit demselben Passwort auf fremder Hardware einen falschen Schlüssel.
Optionaler Security-Key
Ein FIDO2-Sicherheitsschlüssel kann als weiterer physischer Faktor verlangt werden. Eine eventuelle PIN dieses Schlüssels bleibt im Betriebssystemdialog.
Verschlüsselungsschichten
- AES-256-GCM und XChaCha20-Poly1305 dienen als AEAD-Schichten für Vertraulichkeit und Integrität.
- ML-KEM-1024 und ML-DSA-87 sind die Post-Quantum-Komponenten des Stacks (Einsatzbereiche siehe unten).
- HKDF wird in den Produktseiten als Kombinationspfad für Faktoren beschrieben.
Einsatzbereiche der Post-Quantum-Komponenten (Stand heute): Die ruhende Tresor-Datei ist ausschließlich symmetrisch, authentifiziert verschlüsselt (256 Bit). Gegen 256-Bit-symmetrische Verfahren ist kein praktikabler Quantenangriff bekannt; ein durch Quantencomputer brechbares Public-Key-Glied kommt in der ruhenden Datei nicht vor — sie benötigt deshalb keine Post-Quantum-Hülle. ML-KEM-1024 und ML-DSA-87 liegen als geprüfte Komponenten im Stack; ihre produktiven Einsatzpfade (Signaturen für Software-Updates und Lizenzen, Schlüsselaustausch auf den Netzkanälen) sind auf der Sicherheitsseite und in diesem Whitepaper dokumentiert — und werden erst behauptet, wenn sie ausgeliefert sind.
Keine erfundene Garantie: Die genaue interne Key-Schedule sollte in einem späteren Audit-Dokument mit Code-Referenzen, Testvektoren und Versionsnummern veröffentlicht werden.
5. Steganographie und Container-Design.
BlindLock nutzt Steganographie nicht als Ersatz für Kryptographie, sondern als Tarnschicht. Selbst wenn ein Angreifer die Trägerdatei findet, soll er nur verschlüsselten Inhalt vorfinden.
F5-Matrix-Encoding
F5-Matrix-Encoding bettet den bereits verschlüsselten Passwort-Tresor unauffällig in PNG-Träger ein.
Vollständig im Träger
Passwörter, Notizen, 2FA-Secrets und als Tresoreinträge gespeicherte Wallet-Daten liegen vollständig verschlüsselt im PNG.
Separater Container
Größere Dateien liegen in einer eigenen verschlüsselten und getarnten Containerdatei ohne offensichtliche Tresor-Signatur.
6. Hardwarebindung.
Hardwarebindung ist der Unterschied zwischen „Datei plus Passwort“ und „Datei plus Passwort plus dieses Gerät“. Es reduziert den Wert einer kopierten Tresordatei.
TPM 2.0
Der Geräte-Anker wird an TPM 2.0 gebunden. Die App soll den Anker nutzen können, ohne ihn als exportierbaren Klartextschlüssel zu speichern.
Secure Enclave / T2
Auf Apple-Systemen stützt sich das Modell auf Secure Enclave beziehungsweise T2-gebundene Credentials und deren Zugriffspolitik.
StrongBox
Auf unterstützten Android-Geräten bindet StrongBox den Sicherheitsanker an geschützte Hardware.
Wichtig für Recovery: Hardwarebindung erhöht Sicherheit, macht Backups aber anspruchsvoller. Deshalb braucht der Nutzer eine getrennte Recovery-Strategie.
7. Netzwerkgrenzen.
BlindLock verarbeitet Tresorinhalte lokal, benötigt aber für Aktivierung und jeden neuen Entsperrvorgang eine kurze verschlüsselte Verbindung zur Lizenz- und Versionsprüfung. Ausdrücklich aktivierte Wallet-Netzwerkfunktionen kommunizieren zusätzlich mit geprüften Blockchain-Knoten.
Lizenz & Version
Technische Lizenz-, Geräte-, Plattform- und Versionsinformationen werden verarbeitet; sicherheitskritische Releases können eine Mindestversion voraussetzen.
Wallet-Netzwerk
Nur nach ausdrücklicher Aktivierung: öffentliche Adressen, Saldenabfragen, signierte Transaktionen und Transaktionsstatus.
Nicht übertragen
Passwörter, Notizen, TOTP-Secrets, private Schlüssel, Seed-Phrases und Dateien aus dem Tresor.
Risiko
Update-Manipulation oder Metadatenabfluss. Die Gegenmaßnahme ist strikte Datentrennung und kryptographisch abgesicherte Update-Integrität.
8. Recovery und Backups.
BlindLock betreibt keinen zentralen Tresor-Backupdienst. Du bestimmst selbst, wo deine verschlüsselten Sicherungen liegen.
- Die aktive PNG-Datei ist die laufende Datendatei des Passwort-Tresors und sollte regelmäßig gesichert werden.
- Für Gerätewechsel und Notfälle empfiehlt sich ein verschlüsseltes BlindLock-Backup mit getrennt aufbewahrter Wiederherstellungsphrase.
- Jeder Datei-Tresor benötigt zusätzlich seine Containerdatei, Recovery-Datei und den Recovery-Faktor.
- Backups können lokal, extern oder durch deine bewusste Entscheidung in einem synchronisierten Cloud-Ordner liegen.
- BlindLock kann ein verlorenes Passwort nicht zentral zurücksetzen, ohne das Sicherheitsmodell zu brechen.
Höchstes Verfügbarkeitsrisiko: Wer Datei, Passwort, Wiederherstellungsphrase und gebundenes Gerät gleichzeitig verliert, hat keine sinnvolle Wiederherstellungsbasis mehr.
9. Verifikation, Audits und offene Arbeit.
Dieses Whitepaper verbessert Transparenz, ersetzt aber keine unabhängige Prüfung. Für maximale Glaubwürdigkeit sollten die folgenden Artefakte folgen:
Öffentliche Testvektoren
Beispieldaten für Ableitung, Container-Erkennung, Entschlüsselungsfehler und Signaturprüfung.
Externer Audit
Unabhängige Prüfung von App-Code, Krypto-Integration, Update-Pfad und Lizenzgrenze.
Build-/Release-Sicherheit
Signierte Releases, reproduzierbare Build-Dokumentation und klare Update-Integritätsprüfung.
OSS-Grenze dokumentieren
Exakt benennen, welche Bibliotheken offen und formal verifiziert sind und welcher BlindLock-Code proprietär bleibt.