Lokale App
Öffnet den Tresor, liest die Trägerdatei, führt die Krypto-Operationen aus und zeigt entschlüsselte Daten nur während der aktiven Sitzung an.
Security Architecture
Sicherheitsarchitektur & Bedrohungsmodell.
Diese Seite erklärt, welche Werte BlindLock schützt, welche Angreifer angenommen werden, wo die Trust Boundaries liegen und welche Risiken bewusst außerhalb des Schutzbereichs bleiben. Der Kern: Eine gestohlene Datei soll ohne Passwort und ohne das gebundene Gerät wertlos bleiben.
Systemmodell: Was existiert wirklich?
BlindLock ist kein Cloud-Tresor mit lokaler Oberfläche. Die sicherheitsrelevante Laufzeit liegt auf dem Gerät des Nutzers.
Trägerdatei & Datei-Tresor
Der vollständige Passwort-Tresor steckt verschlüsselt und steganografisch in einer PNG-Datei. Größere Dateien liegen getrennt in einem verschlüsselten, getarnten Datei-Tresor.
Sicherheitschip
TPM 2.0 oder Apple Secure Enclave halten nicht exportierbares Schlüsselmaterial, das als Geräte-Anker in die Ableitung eingeht.
Sicherheitsschlüssel
YubiKey, Google Titan oder SoloKey können als weiterer physischer Faktor verlangt werden.
Lizenz, Version & Wallet-Netzwerk
Aktivierung und jeder neue Entsperrvorgang benötigen eine verschlüsselte Lizenz- und Versionsprüfung. Ausdrücklich aktivierte Wallet-Funktionen nutzen geprüfte Blockchain-Knoten. Tresorinhalte werden nicht an BlindLock übertragen.
Cloud-Tresor
Es gibt keinen serverseitigen Passwortspeicher, keinen Sync-Tresor und kein Anbieter-Konto, das Tresorinhalte hält.
Schützenswerte Assets.
Das Bedrohungsmodell priorisiert nicht abstrakte Sicherheitsbegriffe, sondern konkrete Werte, deren Verlust Schaden verursacht.
Tresor-Inhalte
- Passwörter und Login-Daten
- TOTP-2FA-Secrets
- Seed-Phrases und Private Keys
- Sichere Notizen und Dateien
Schlüsselmaterial
- Master-Key-Material im Speicher während einer offenen Sitzung
- Argon2id-Ableitung aus Passwort und Parametern
- Hardware-gebundener, nicht exportierbarer Geräte-Anker
- Optionale Security-Key-Bestätigung
Metadaten
- Existenz eines Tresors
- Trägerdatei-Zuordnung
- Nutzungsmuster
- Lizenz- und Aktivierungsstatus
Verfügbarkeit
- Backup der aktiven PNG-Datei
- Verschlüsseltes BlindLock-Backup und getrennte Wiederherstellungsphrase
- Bei Datei-Tresoren: Container-, Recovery-Datei und Recovery-Faktor
- Integrität von App-Updates
Trust Boundaries.
Die wichtigsten Sicherheitsentscheidungen liegen an den Übergängen zwischen Nutzer, Gerät, Dateisystem, Hardware und Online-Diensten.
Nutzer → App
PIN, Passwort und optionale Security-Key-Bestätigung werden lokal eingegeben.
Risiko: Phishing, Keylogger, kompromittierte UI. Minderung: keine Web-Login-Oberfläche, OS-Dialog für Security-Key-PIN, langsames PIN-Gate.
App → Dateisystem
Die App liest den Passwort-Tresor aus der Trägerdatei und optionale Datei-Tresore vom lokalen Speicher.
Risiko: Diebstahl oder Kopie der Datei. Minderung: Verschlüsselung, Steganografie und Hardwarebindung.
App → Sicherheitschip
Die App fordert hardware-gebundenes Material an, ohne es exportieren zu können.
Risiko: Umgehung durch fremdes Gerät. Minderung: nicht exportierbarer Geräte-Anker, Rate-Limits und Chip-Policy.
App → Netzwerk
Lizenz- und Versionsprüfung erfolgen beim Entsperren online; aktivierte Wallet-Funktionen können Blockchain-Knoten ansprechen.
Risiko: Metadatenabfluss oder manipulierte Updates. Minderung: strikte Trennung von Tresorinhalten und technischen Verbindungsdaten sowie kryptografisch abgesicherte Update-Integrität.
Angreiferannahmen.
BlindLock ist für realistische Desktop-Bedrohungen ausgelegt, nicht für magische Sicherheit gegen ein bereits vollständig kontrolliertes Gerät.
Der Angreifer besitzt Dateien
Er hat eine Kopie der Trägerdatei, des Containers oder sogar der gesamten Festplatte. BlindLock soll verhindern, dass daraus ohne Passwort und Gerät ein Tresor wird.
Der Angreifer kann offline raten
Er kann beliebig viele Passwortversuche auf gestohlenen Dateien starten. Argon2id, Hardwarebindung und fehlende Erkennungsmerkmale sollen diesen Weg teuer und unzuverlässig machen.
Der Angreifer sammelt langfristig Ciphertext
Deshalb gibt es keine zentrale Tresor-Datenbank als Sammelziel, und ruhende Dateien sind 256-Bit-symmetrisch verschlüsselt — ohne praktikablen Quantenangriff.
Der Angreifer kontrolliert die aktive Sitzung
Keylogger, Bildschirmaufnahme oder Speicherzugriff auf einem kompromittierten, entsperrten Gerät liegen außerhalb des Kernschutzes.
Missbrauchspfade und Gegenmaßnahmen.
Die folgenden Pfade sind die wichtigsten Angreiferziele aus Sicht des Produkts.
Datei-Diebstahl
Angreifer kopiert Träger- oder Tresordatei. Gegenmaßnahmen: Steganographie, fehlende Magic Bytes, AEAD-Verschlüsselung, Argon2id, Hardwarebindung.
Offline-Brute-Force
Angreifer probiert Passwörter gegen eine gestohlene Datei. Gegenmaßnahmen: speicherharte Ableitung, unabhängige Schlüssel, Geräte-Anker und langsames PIN-Gate.
Cloud-Breach
Bei BlindLock gibt es keinen zentralen Tresor-Server. Ein Anbieter-Breach kann keine Tresor-Inhalte exfiltrieren, wenn sie nie beim Anbieter liegen.
Harvest-now-decrypt-later
Keine zentrale Tresor-Datenbank bedeutet: nichts, was sich massenhaft ernten ließe. Ruhende Dateien sind 256-Bit-symmetrisch verschlüsselt — ohne praktikablen Quantenangriff. Post-Quantum-Komponenten (ML-KEM-1024, ML-DSA-87) sind je Einsatzbereich dokumentiert.
Kompromittierter Endpunkt
Läuft Malware mit Benutzerrechten während der Tresor geöffnet ist, kann sie Eingaben, Bildschirm oder Speicher angreifen. Gegenmaßnahmen liegen primär bei OS-Hygiene, Security-Key-Nutzung und Sitzungsdisziplin.
Backup-Verlust
Lokale Kontrolle bedeutet lokale Verantwortung. Für Gerätewechsel und Notfälle sind ein verschlüsseltes BlindLock-Backup und die getrennte Wiederherstellungsphrase vorgesehen; Datei-Tresore benötigen zusätzliche Recovery-Dateien und -Faktoren.
Verifikationsstatus und ehrliche Grenzen.
Für ein Security-Produkt ist wichtig, welche Aussagen bewiesen, geprüft oder nur Designziele sind.
Formal verifiziert sind die kryptographischen Bausteine, nicht die gesamte App. BlindLock beschreibt den Einsatz von libcrux/HACL* für AES-256-GCM, XChaCha20-Poly1305, ML-KEM-1024 und ML-DSA-87. Diese Bibliotheken enthalten formal verifizierte Primitiven. Der eigene App-, UI-, Lizenz- und Integrationscode ist damit nicht automatisch formal verifiziert.
Ein unabhängiger Audit wäre der nächste Vertrauenshebel. Diese Seite dokumentiert das Bedrohungsmodell und die beabsichtigten Schutzgrenzen. Ein externer Security-Audit oder ein öffentliches Whitepaper würde die Aussagekraft für Käufer, Suchmaschinen und LLMs deutlich erhöhen.