At-Rest-Encryption¶
ℹ️ Hinweis (Diátaxis): Sektion in drei Teile gesplittet — 31-A How-to (aktivieren / migrieren), 31-B Reference (Format, Coverage), 31-C Explanation (Krypto-Architektur).
31-A How-to: Encryption aktivieren und Bestand migrieren [How-to]¶
So aktivieren Sie die At-Rest-Verschlüsselung manuell und migrieren existierende Klartext-Dateien.
31-A.1 Encryption aktivieren¶
- Klicken Sie in der Topbar auf den 🔒 DSGVO-Button.
- Im DSGVO-Settings-Dialog scrollen Sie zur Sektion At-Rest-Encryption.
- Aktivieren Sie den Toggle Vereins-Daten verschlüsseln.
- Falls noch Klartext-Dateien existieren, klicken Sie auf 🔄 Bestehende Klartext-Dateien jetzt verschlüsseln.
- Die Migration läuft idempotent durch alle Daten-Dateien (State, Stammdaten, Snapshots) — schon verschlüsselte Dateien werden übersprungen.
💡 Tipp: Bei Neuinstallationen ab v3.6.0 ist Encryption bereits standardmäßig aktiv, sobald der OS-Keychain verfügbar ist. Sie müssen nichts manuell aktivieren.
31-A.2 Encryption-Status prüfen¶
Im DSGVO-Dialog zeigt die At-Rest-Encryption-Sektion an:
- Aktivierungs-Status (an / aus)
- Modus (Keychain / Passphrase)
- OS-Keychain-Verfügbarkeit (macOS Keychain Services / Windows DPAPI / Linux kwallet/gnome-keyring)
- Anzahl Klartext-Dateien (sollte 0 sein nach Migration)
31-A.3 Master-Passphrase einrichten (Modus B)¶
Wenn Sie zusätzlich Schutz im laufenden User-Account wünschen (z. B. Familien-Mac mit gemeinsamem Login):
- DSGVO-Dialog → Sektion 🔑 Master-Passphrase
- Klicken Sie auf Master-Passphrase einrichten
- Folgen Sie § 32 für die weiteren Schritte
🚨 Warnung: Bei Verlust der Master-Passphrase sind alle verschlüsselten Daten unwiederbringlich. Es gibt keinen Recovery-Mechanismus — eine Hintertür wäre ein Sicherheits-Bruch.
31-A.4 Backup-Strategie¶
- Wenn der Auto-Backup-Ordner mit aktiver Encryption auf eine Cloud synchronisiert wird (iCloud, Dropbox, Google Drive), bekommt der Cloud-Anbieter nur Geheimtext.
- Der Master-Key ist NICHT im Backup. Geht er verloren (Festplatten- Ausfall ohne Backup, Keychain-Reset), sind die Daten unwiederbringlich.
- Empfehlung: Zusätzlich gelegentlich einen Klartext-Export über Tab IO → JSON-Export auf ein getrenntes, sicheres Medium.
31-B Reference: Coverage, Container-Format, Performance [Reference]¶
31-B.1 Verschlüsselungs-Coverage¶
| Datei | Verschlüsselt seit |
|---|---|
einsatz_state.json (aktiver Einsatz) |
v3.6.0 |
personen.json, hunde.json, pruefungen.json |
v3.6.0 |
alarmgruppen.json, adressbuch.json |
v3.6.0 |
snapshots/*.json (rotierende Backups) |
v3.5.2 |
tile-cache/ (Karten-Kacheln) |
nicht verschlüsselt — keine PII |
print_settings.json, dsgvo_settings.json |
nicht verschlüsselt — keine PII |
31-B.2 Container-Format¶
Jedes verschlüsselte File beginnt mit dem 4-Byte-Magic SAR1 und folgt
dem AES-256-GCM-Schema:
┌──────────┬─────────────┬─────────────┬──────────────────────┐
│ "SAR1" │ 16-Byte IV │ 16-Byte Tag │ Ciphertext (variabel)│
│ (4 Byte) │ (CSPRNG) │ (Auth-Tag) │ │
└──────────┴─────────────┴─────────────┴──────────────────────┘
31-B.3 Master-Key-Modi¶
| Modus | Datei | Schutz greift |
|---|---|---|
| A — Keychain (Default) | sar-master-key.bin (per OS-Keychain gewrappt) |
Gerät ausgeschaltet oder kein User-Login |
| B — Passphrase (opt-in) | sar-passphrase-key.bin (per User-Passphrase gewrappt) |
Auch im laufenden User-Account |
Die beiden Modi schließen sich aus — Modus B löscht beim Aktivieren die Modus-A-Datei.
31-B.4 Performance-Kennzahlen¶
| Metrik | Wert |
|---|---|
| Verschlüsselungs-Overhead pro Datei | < 1 ms (AES-256-GCM ist hardware-beschleunigt auf modernen CPUs mit AES-NI) |
| Datei-Wachstum | +36 Bytes pro Datei (Magic + IV + Tag) |
Sichtbarkeit in cat / hexdump |
unleserliches Geheimtext-Binary — ein versehentlich kopiertes Backup bleibt geschützt |
| Backward-Compat | Klartext-Files (ohne SAR1-Magic) bleiben lesbar; idempotente Migration |
31-B.5 OS-Keychain-Mapping¶
| OS | Keychain-Backend |
|---|---|
| macOS | Keychain Services (System-Keychain) |
| Windows | DPAPI (Data Protection API, User-Scope) |
| Linux | kwallet (KDE) ODER gnome-keyring (GNOME) |
| Linux ohne Keyring | UI zeigt Hinweis, Encryption-Toggle ist disabled — Workaround: Passphrase-Modus B |
31-C Explanation: Krypto-Architektur und Bedrohungs-Modell [Explanation]¶
🔧 Fortgeschritten: Diese Sektion erklärt das Krypto-Design. Für die Bedienung ist sie nicht erforderlich, aber für Pen-Tester und Datenschutzbeauftragte wertvoll.
31-C.1 Algorithmus-Wahl: AES-256-GCM¶
Authenticated Encryption with Associated Data (AEAD) ist das moderne Idiom für File-Encryption. AES-256-GCM:
- AES-256: Symmetrische Verschlüsselung mit 256-Bit-Schlüssel (post-quantum-tauglich gegen Grover's Algorithm bis ~2050)
- GCM (Galois/Counter Mode): integrierter MAC (Auth-Tag) → garantiert Integrität + Vertraulichkeit in einem Schritt
- Hardware-beschleunigt auf allen modernen CPUs (Intel AES-NI, ARM Crypto-Extension, Apple Silicon)
Warum nicht ChaCha20-Poly1305? AES-NI ist auf den Ziel-Plattformen (macOS-Intel, macOS-arm64, Windows-x64, Linux-x64) bereits hardware- beschleunigt. ChaCha20 wäre für CPUs ohne AES-NI besser, aber auf Mobile-iOS / Android implementiert es Apple/Google ohnehin als Hardware- Pfad.
31-C.2 Initialisierungs-Vektor (IV)¶
Pro Datei wird ein frischer 16-Byte-IV via CSPRNG
(crypto.randomBytes(16)) generiert. Niemals wird derselbe IV mit
demselben Schlüssel zweimal verwendet — das wäre der häufigste
GCM-Implementierungs-Fehler.
31-C.3 Master-Key-Lebenszyklus¶
- Erst-Erzeugung: 32 Byte CSPRNG-Output
(
crypto.randomBytes(32)) — entweder beim ersten App-Start (Modus A) oder bei der Passphrase-Einrichtung (Modus B). - Speicherung Modus A: Per
safeStorage.encrypt()durch Electron insar-master-key.bingeschrieben — der OS-Keychain ent-/verschlüsselt automatisch beim Datei-Lesen. - Speicherung Modus B: Per AES-256-GCM mit Wrap-Key (von
PBKDF2 oder scrypt aus User-Passphrase abgeleitet, siehe
§ 32) gewrappt in
sar-passphrase-key.bin. - Verwendung: Beim App-Start in einer geschützten Buffer-Region
(libsodium-
sodium_mlock) gehalten — Speicher-Dump-Schutz.
31-C.4 Bedrohungs-Modell und Schutz-Profil¶
| Bedrohung | Modus A (Keychain) | Modus B (Passphrase) |
|---|---|---|
| Festplatte gestohlen, Gerät aus | ✅ geschützt | ✅ geschützt |
| Mitnutzer am gleichen User-Account (laufende Session) | ❌ Master-Key ist im RAM zugreifbar | ✅ geschützt (Sperre möglich) |
| GPU-Brute-Force gegen Passphrase | n/a | siehe § 32.5 (scrypt-resistent) |
| Speicher-Dump während Laufzeit | ❌ Master-Key im RAM | ❌ Master-Key im RAM |
| Hardware-Token-Bypass | n/a | n/a |
| Cloud-Backup-Datenleck | ✅ Backup ist Geheimtext | ✅ Backup ist Geheimtext + Passphrase nicht im Backup |
| Forensik auf Filesystem-Image | ✅ alle Daten geschützt | ✅ alle Daten geschützt |
31-C.5 Was Encryption nicht abdeckt¶
- Daten in Transit: Live-Sync-Daten zwischen Peers werden via WebRTC-DTLS bzw. TLS verschlüsselt, aber nicht mit dem At-Rest-Master-Key. Das ist ein anderes Krypto-System.
- Daten in Use: Während die App läuft und der Master-Key im RAM liegt, kann ein Angreifer mit Root-Zugriff theoretisch den Master-Key aus dem RAM extrahieren.
- Side-Channel-Attacken: Timing-Attacken auf AES-NI sind bekannt (Cache-Bleichenbacher) — die Praxis-Auswirkungen für einzelne Vereinsstaffeln sind aber vernachlässigbar.
🌐 BOS-Übergreifend: Das hier dokumentierte Krypto-Modell ist dem von BSI-empfohlenen Standard (TR-02102) konform. Vor externer Pen-Test-Vergabe ist die Doku in
docs/pen-test-preparation.mdzu lesen.
31-C.6 Quellen¶
- AES-Standard: NIST FIPS 197
- GCM-Modus: NIST SP 800-38D
- Electron
safeStorage: https://www.electronjs.org/docs/latest/api/safe-storage - BSI TR-02102: Technische Richtlinie „Kryptographische Verfahren: Empfehlungen und Schlüssellängen"