Das Modell in einem Satz
Jeder Chip speichert einen 32-Byte-Vault-Wrap-Schlüssel in einer authentifizierten verschlüsselten Datei. Jeder Zugangsdatensatz, den wir für Sie aufbewahren, ist unter diesem Schlüssel verschlüsselt. Um irgendetwas zu entschlüsseln, muss sich der Chip physisch im Feld des Lesegeräts befinden, eine gegenseitige AES-128-Authentifizierung abschliessen, und der Server muss den Wrap-Schlüssel auslesen. Kein Chip im Feld, kein Klartext.
Mehrschichtige Verteidigung
Der Chip selbst (NXP MIFARE DESFire EV3)
Manipulationssicheres Secure Element von NXP, einem der weltweit führenden Hersteller von NFC- und Kontaktlos-Bezahlchips. AES-128 gegenseitige Authentifizierung mit dem Server im DESFire-EV2-Modus. Von NXP signiertes Originalitätszertifikat, sodass wir die Echtheit des Siliziums verifizieren können. Ohne erfolgreiche Authentifizierung verweigert der Chip jede Operation.
Chip-gebundene Verschlüsselung (Zero-Knowledge)
Schlüssel pro Zugangsdatensatz, abgeleitet via HKDF-SHA256 aus dem Vault-Wrap-Schlüssel des Chips. ChaCha20-Poly1305 AEAD, ein moderner Verschlüsselungsstandard, der von Cloudflare, Google-Diensten und dem Signal-Protokoll verwendet wird. Die Bindung der zugehörigen Daten (Benutzer, Site, Credential-ID) verhindert Ciphertext-Swap-Angriffe. Der Server speichert nur Chiffretext.
Transport- und Sitzungssicherheit
TLS 1.3, der aktülle Internet-Sicherheitsstandard, mit HSTS-Preload. Strikte Content Security Policy, Cross-Origin Opener Policy und Cross-Origin Resource Policy Header. SameSite=Strict-Cookies für Operator-Sessions. Pro-IP-Ratenbegrenzungen bei der Authentifizierung, Sperre nach mehreren fehlgeschlagenen Anmeldeversuchen. Alle Session-Tokens sind im Ruhezustand SHA-256-gehashed.
Betrieb und Wiederherstellung
Drei unabhängige Wiederherstellungspfade, damit Sie niemals daürhaft ausgesperrt sind: ein Backup-Chip, ein druckbarer Shamir-aufgeteilter Schlüssel und ein mehrstufiger Identitätsverifizierungsprozess. Jede destruktive Aktion erfordert die Zustimmung mehrerer Operatoren. Verschlüsselte Backups, geschützt mit einem age-Privatschlüssel, der auf einem separaten isolierten System gespeichert ist.
Bedrohungsmodell
Wir sind ehrlich darüber, wogegen diese Technologie schützen kann und wogegen nicht.
Wogegen wir schützen
- Phishing. Passkeys sind herkunftsgebunden; Phishing scheitert konstruktionsbedingt.
- Gestohlene Zugangsdaten. Jede Site hat eine eindeutige, vom Server generierte Zugangsdate. Es gibt kein Master-Passwort zu knacken.
- Server-Kompromittierung. Der Server hält Chiffretext. Ohne den Chip liest ein Angreifer Müll.
- Netzwerk-Abhören. TLS 1.3 und HSTS-Preload an allen Endpunkten.
- Gestohlenes Gerät. Jede neü Anmeldung erfordert einen Chip-Tap.
- Backup-Leck. Backups sind im Ruhezustand mit einem öffentlichen age-Schlüssel verschlüsselt, dessen private Hälfte auf einem separaten isolierten System lebt.
- Insider-Angriff. Unsere Operatoren können keine Vaults entschlüsseln. Wiederherstellungsaktionen erfordern die Zustimmung mehrerer Operatoren und ein vollständiges Audit-Log.
Wogegen wir nicht schützen
- Physische Entfernung des Chips. Ihr Körper, Ihre Entscheidung.
- Zwang. Wenn jemand Sie zum Scannen zwingt, kann das System es nicht erkennen.
- Kompromittierung Ihres Geräts während der Chip getappt wird. Das Zeitfenster ist auf den Moment des Taps begrenzt.
- Gezielte staatliche Angreifer mit beliebiger Codeausführung auf Ihrem entsperrten Gerät. Kein Verbraucher-Authentifikator schützt davor.
Kryptografische Primitive
Wir sind transparent über jeden Algorithmus, den wir verwenden. Jeder verschlüsselte Blob trägt eine Ein-Byte-Versionsnummer, damit wir Algorithmen ohne Unterbrechung rotieren können.
| Verwendung | Algorithmus |
|---|---|
| Gegenseitige Chip-Authentifizierung | AES-128 (NXP DESFire EV3, EV2 mode) |
| Vault-Schlüssel auf dem Chip | 32 Byte zufällig, gespeichert in einer authentifizierten Datei |
| Verschlüsselung pro Zugangsdatensatz | ChaCha20-Poly1305 AEAD with HKDF-SHA256 |
| FIDO-Assertion-Signatur | ECDSA P-256 with SHA-256 (FIDO2 and WebAuthn, COSE ES256) |
| Chip-Originalitätsverifizierung | ECDSA secp224r1, von NXP bei der Herstellung signiert |
| Wiederherstellungsschlüssel-Aufteilung | Shamir Secret Sharing |
| Operator-Passwörter | PBKDF2-HMAC-SHA256, OWASP-empfohlene Iterationszahl |
| Backup im Ruhezustand | age (X25519 key exchange, ChaCha20-Poly1305 symmetric) |
| Konstantzeit-Vergleich | Konstantzeit-Vergleich aus der Standardbibliothek |
| Generierung von Zufallszahlen | Vom Betriebssystem bereitgestellter CSPRNG |
| TLS | TLS 1.3 mit HSTS-Preload |
Härtung des Operator-Panels
Unsere Kundendienstmitarbeitenden melden sich an einem separaten Panel mit eigenem Authentifizierungsmodell an. Sie können Kunden-Vaults nicht entschlüsseln. Sie können den Status einsehen, Wiederherstellungsanfragen genehmigen und destruktive Aktionen nur mit Peer-Zustimmung auslösen.
- Unsere Mitarbeitenden können Ihre Daten nicht lesen, Punkt.
- Jede sensible Aktion erfordert die Zustimmung mehrerer Mitarbeitender.
- Jede Aktion wird mit vollständigem Audit-Trail protokolliert.
- Mitarbeiter-Sessions laufen automatisch ab und werden nach fehlgeschlagenen Versuchen gesperrt.
Das vollständige Sicherheitsmodell für Operatoren finden Sie auf der Seite technische Architektur.