SimpleumSafe 3 Sicherheit – Technisches Whitepaper
SimpleumSafe trennt verschlüsselte Dateiinhalte, verschlüsselte Metadaten und die zum Öffnen benötigten Schlüssel. Das Safe-Passwort schützt die Schlüsseldatei; es wird nicht selbst als Dateiverschlüsselungsschlüssel verwendet.
Dieses Whitepaper beschreibt die aktuelle Architektur von SimpleumSafe 3 für technische Prüfer und interessierte Anwender. Im Mittelpunkt stehen ruhende Daten, Schlüsselverwaltung, die Schutzgrenze von Arbeitskopien unter macOS, Backups und Synchronisation.
Auf einen Blick
- Dateiinhalte werden als einzeln verschlüsselte Dateien unter nicht aussagekräftigen UUID-basierten Namen gespeichert.
- Dateinamen, Ordnerbeziehungen, Datumsangaben, Tags, Kommentare und weitere Metadaten liegen in verschlüsselten SQLCipher-Datenbanken.
- SimpleumSafe erzeugt zufällige Verschlüsselungsschlüssel. Das Safe-Passwort schützt die Schlüsseldatei, die diese Schlüssel enthält.
- Das normale Synchronisationsziel enthält verschlüsselte Safe-Daten, aber nicht die separate Safe-Schlüsseldatei.
- Vorschau, Bearbeitung, Teilen und Export benötigen eine nutzbare Kopie. Für diese autorisierte Kopie verändert sich die Schutzgrenze.
- Simpleum Media kann ein vergessenes Safe-Passwort nicht wiederherstellen und fehlendes Schlüsselmaterial nicht neu erzeugen.
Umfang und Sicherheitsgrenzen
SimpleumSafe ergänzt die bereits von macOS, iOS und iPadOS bereitgestellten Schutzmaßnahmen um eine Verschlüsselungsschicht auf Anwendungsebene. Sie soll die Daten in einem geschlossenen oder gesperrten Safe sowie die durch die SimpleumSafe-Synchronisation übertragenen verschlüsselten Daten schützen.
Eine breitere Erklärung dieser Schutzebenen bietet die Seite Sicherheit von SimpleumSafe.
Verschlüsselung beseitigt nicht jedes Risiko. Der Schutz hängt außerdem davon ab,
- ein starkes und nur für diesen Zweck verwendetes Safe-Passwort zu wählen,
- das Gerät sicher und aktuell zu halten,
- Schlüssel- und Wiederherstellungsmaterial getrennt von nicht vertrauenswürdigen Safe-Kopien aufzubewahren,
- den Safe zu sperren, wenn er nicht verwendet wird,
- unabhängige Backups anzulegen und ihre Wiederherstellung zu testen sowie
- exportierte, geteilte oder extern bearbeitete Kopien angemessen zu behandeln.
Gestaltungsprinzipien
Nutzbare Sicherheit
SimpleumSafe soll verschlüsselte Dateispeicherung praktisch nutzbar machen, ohne dass Anwender kryptografische Algorithmen konfigurieren müssen. Die Oberfläche verbindet Verschlüsselung mit alltäglichen Archivfunktionen wie Ordnern, Tags, Favoriten, Kommentaren, Import, Export, Vorschau und Bearbeitung.
Etablierte kryptografische Komponenten
Die Architektur verwendet etablierte Formate und Bibliotheken anstelle proprietärer Verschlüsselungsalgorithmen:
- AES-256 für die Verschlüsselung von Dateien und Datenbanken,
- das Datenformat RNCryptor Version 3 für verschlüsselte Schlüsseldateien und Dateinutzdaten sowie
- SQLCipher für verschlüsselte SQLite-Datenbanken.
Eine kürzere Erklärung der Algorithmen und ihrer Aufgaben finden Sie unter Welche Verschlüsselungsmethode verwendet SimpleumSafe?.
Datenminimierung zwischen Softwareebenen
Verschlüsselung und Schlüsselverwaltung sind in der Komponente Simpleum®Cryptor gebündelt. Andere Anwendungsteile fordern Operationen von dieser Komponente an, anstatt Verschlüsselungsschlüssel direkt auszulesen. Das reduziert die Menge des Codes, der Schlüsselmaterial verarbeitet, ersetzt aber keine sicheren Entwicklungspraktiken, Tests oder Plattformschutzmaßnahmen.
Standardmäßig verschlüsselt im Safe
SimpleumSafe hält gespeicherte Dateiinhalte und Metadaten verschlüsselt. Eine Entschlüsselung erfolgt erst, wenn eine autorisierte Operation die Informationen benötigt, etwa um einen Dateinamen anzuzeigen, eine Vorschau zu erzeugen, eine Datei zu bearbeiten, zu teilen oder zu exportieren.
Speichermodell
Jede importierte Datei wird durch zwei geschützte Bestandteile repräsentiert:
- Verschlüsselte Dateidaten: der binäre Inhalt der Datei.
- Verschlüsselte Attribute: ursprünglicher Dateiname, Ordnerbeziehung, Datumsangaben, Tags, Kommentare und weitere Verwaltungsdaten.
Durch diese Trennung muss eine große verschlüsselte Datei nicht neu geschrieben werden, wenn sich nur ein kleines Attribut ändert. Sie unterstützt außerdem transaktionale Aktualisierungen, Backups und Synchronisation.
Import
Ein Import wird transaktional verarbeitet. SimpleumSafe schreibt die Dateiattribute in die verschlüsselte Datenbank und den Dateiinhalt in eine verschlüsselte Binärdatei. Länger dauernde Importe können pausiert und fortgesetzt werden.
Der Name der verschlüsselten Datendatei basiert auf einer UUID und enthält weder den ursprünglichen Dateinamen noch andere importierte Attribute.
Export, Teilen, Vorschau und Bearbeitung
Bei einem Export werden Dateiname, Ordnerhierarchie, Datumsangaben und Dateiinhalte am gewählten Ziel rekonstruiert. Diese exportierte Kopie wird nicht mehr durch den Safe geschützt.
Auch Vorschau und Bearbeitung benötigen eine nutzbare Kopie. Unter macOS legt SimpleumSafe diese Kopie wie unten beschrieben in einem verschlüsselten temporären Speicher ab. Eine externe Bearbeitungsanwendung kann die Arbeitskopie lesen, solange sie geöffnet ist.
Backup
Das Safe-Backup von SimpleumSafe kopiert verschlüsselte Dateidaten und speichert die zum Wiederaufbau des Archivs benötigten Informationen in einem verschlüsselten, für die Wiederherstellung vorgesehenen Format. Ein Backup unterscheidet sich von der Synchronisation: Synchronisation überträgt Änderungen und Löschungen, während ein Backup einen wiederherstellbaren Zustand bewahren soll.
Backups bleiben von ihrem zugehörigen Schlüsselmaterial abhängig. Ein Backup-Konzept sollte deshalb sowohl das Safe-Backup als auch einen getesteten Wiederherstellungsplan umfassen, wobei Wiederherstellungsdaten getrennt aufbewahrt werden.
Die praktische Backup-Strategie erklärt der Beitrag Warum Backups zur digitalen Sicherheit gehören.
Schlüsselhierarchie und Öffnen eines Safes
Erstellen eines Safes
Beim Erstellen eines Safes erzeugt SimpleumSafe zufällige Schlüssel für Dateidaten und verschlüsselte Datenbanken. Diese Schlüssel werden in die Safe-Schlüsseldatei (k.crypt) geschrieben.
Der Anwender wählt ein Safe-Passwort. RNCryptor leitet aus diesem Passwort und zufälligen Salts getrennte Verschlüsselungs- und Authentifizierungsschlüssel ab. Diese abgeleiteten Schlüssel schützen die Safe-Schlüsseldatei. Weder das Safe-Passwort noch die abgeleiteten Schlüssel werden gespeichert.
Diese Unterscheidung ist wichtig:
- Das Safe-Passwort entsperrt die Safe-Schlüsseldatei.
- Die Safe-Schlüsseldatei enthält zufällig erzeugte Verschlüsselungsschlüssel.
- Diese zufälligen Schlüssel schützen Dateidaten und Datenbanken.
Eine Änderung des Safe-Passworts schützt daher die Schlüsseldatei neu; nicht jede gespeicherte Datei muss erneut verschlüsselt werden.
Öffnen eines Safes
Wenn ein Anwender das Safe-Passwort eingibt, versucht SimpleumSafe, die Safe-Schlüsseldatei zu authentifizieren und zu entschlüsseln. Im Format RNCryptor Version 3 lässt ein Authentifizierungsfehler nicht erkennen, ob das Passwort falsch oder die verschlüsselten Daten beschädigt sind. SimpleumSafe behandelt deshalb beide Fälle als fehlgeschlagenen Öffnungsvorgang.
Wird die Schlüsseldatei erfolgreich geöffnet, hält der Simpleum®Cryptor das benötigte Schlüsselmaterial für die autorisierte Safe-Sitzung vor. Simpleum Media erhält weder das Safe-Passwort noch eine serverseitige Kopie der Schlüsseldatei und kann den Zugriff nicht rekonstruieren, wenn sowohl Passwort als auch Wiederherstellungsmaterial fehlen.
Paketstruktur eines Safes
Ein Safe verwendet eine Paketstruktur mit Schlüsselmaterial, verschlüsselten Datenbanken und verschlüsselten Dateinutzdaten. Abbildung 2 zeigt die grundlegende Speicherbeziehung. Sie ist bewusst vereinfacht: Zusätzlich können funktionsspezifische Schlüsseldateien, Konfigurationen, Einstellungen, Transaktionen, Synchronisationsbuchhaltung und Hilfsdateien des Betriebssystems vorhanden sein.
k.crypt
Safe-SchlüsseldateiZum Öffnen des Safes erforderlich
r.crypt
WiederherstellungsschlüsseldateiOptional; getrennt aufbewahren
*.crypt
Verschlüsselte DatenbankenAttribute, Einstellungen und Transaktionen
files/
Verschlüsselte DateidatenUUID-benannte verschlüsselte Nutzdaten
Safe-Schlüsseldatei
Die Safe-Schlüsseldatei enthält die zufälligen Schlüssel für Dateidaten und verschlüsselte Datenbanken. Ihre äußere Verschlüsselung verwendet das Format RNCryptor Version 3 mit passwortbasierter Schlüsselableitung.
Neue und migrierte Schlüsseldateien von SimpleumSafe 3 verwenden 1.000.000 PBKDF2-HMAC-SHA-1-Iterationen. Ältere Schlüsseldateien mit 10.000 Iterationen bleiben als Kompatibilitätspfad lesbar und werden nach einem erfolgreichen Öffnen mit der aktuellen Einstellung neu geschrieben.
Für jede passwortgeschützte RNCryptor-Nachricht verwendet SimpleumSafe:
- einen zufälligen 8-Byte-Verschlüsselungs-Salt,
- PBKDF2-HMAC-SHA-1 zur Ableitung eines 32-Byte-Verschlüsselungsschlüssels,
- einen getrennten zufälligen 8-Byte-HMAC-Salt,
- PBKDF2-HMAC-SHA-1 zur Ableitung eines getrennten 32-Byte-HMAC-Schlüssels,
- einen zufälligen 16-Byte-Initialisierungsvektor,
- AES-256 im CBC-Modus zur Verschlüsselung sowie
- HMAC-SHA-256 über Header und Chiffretext zur Authentifizierung.
PBKDF2-HMAC-SHA-1 ist die durch das Format RNCryptor Version 3 vorgegebene Konstruktion zur Schlüsselableitung. SHA-1 dient hier als Pseudozufallsfunktion innerhalb von PBKDF2; HMAC-SHA-256 authentifiziert die resultierende RNCryptor-Nachricht.
Optionale Wiederherstellungsschlüsseldatei
Die Wiederherstellungsschlüsseldatei (r.crypt) enthält dieselbe Art von Safe-Schlüsselmaterial wie die Hauptschlüsseldatei, wird jedoch durch ein getrenntes, zufällig erzeugtes Wiederherstellungspasswort geschützt. Ihre Erstellung erfordert eine Autorisierung mit dem aktuellen Safe-Passwort.
Das Wiederherstellungspasswort wird dem Anwender zur getrennten Aufbewahrung angezeigt. Es kann den Zugriff wiederherstellen, wenn das normale Safe-Passwort vergessen wurde. Wer sowohl die Wiederherstellungsschlüsseldatei als auch ihr Passwort erhält, kann möglicherweise auf den Safe zugreifen. Beides sollte daher nicht gemeinsam aufbewahrt werden.
Verschlüsselte Datenbanken
Dateinamen, Datumsangaben, Ordnerbeziehungen, Tags, Kommentare und weitere Safe-Metadaten werden in verschlüsselten SQLite-Datenbanken gespeichert. SimpleumSafe verwendet SQLCipher mit einem zufällig erzeugten Datenbankschlüssel aus der Safe-Schlüsseldatei.
SQLCipher verschlüsselt Datenbankseiten mit AES-256 und authentifiziert sie. Der Datenbankzugriff bleibt transaktional, während die Datenbankinhalte auf dem Datenträger verschlüsselt sind.
Verschlüsselte Dateidaten
Das Verzeichnis files speichert verschlüsselte Dateinutzdaten. Jede Nutzdatendatei besitzt einen UUID-basierten Namen mit der Endung .data.crypt. Unterverzeichnisse werden aus den ersten beiden UUID-Zeichen abgeleitet, um die Anzahl der Einträge in einem Verzeichnis zu begrenzen.
Dateinutzdaten verwenden den Container RNCryptor Version 3 mit AES-256-CBC-Verschlüsselung und HMAC-SHA-256-Authentifizierung. Die Verschlüsselungs- und Authentifizierungsschlüssel sind zufällige Schlüssel aus der Safe-Schlüsseldatei und werden nicht direkt aus Dateiname oder Safe-Passwort abgeleitet.
Byte-Aufbau von RNCryptor Version 3
Die folgende Tabelle beschreibt den passwortbasierten Container RNCryptor Version 3, der für die Safe-Schlüsseldatei verwendet wird. Die Iterationszahl ist eine Anwendungseinstellung und wird nicht im Container kodiert.
Wischen oder horizontal scrollen, um alle Spalten zu sehen.
| Byte-Bereich | 0 | 1 | 2–9 | 10–17 | 18–33 | 34 … n−33 | n−32 … n−1 |
|---|---|---|---|---|---|---|---|
| Inhalt | Version | Optionen | Verschlüsselungs-Salt | HMAC-Salt | IV | Chiffretext | HMAC |
| Länge | 1 Byte | 1 Byte | 8 Byte | 8 Byte | 16 Byte | Variabel | 32 Byte |
Alle Mehrbyte-Werte werden in Netzwerkreihenfolge gespeichert. Die RNCryptor-Formatversion ist unabhängig von der Schemaversion der SimpleumSafe-Schlüsseldatei und der Anwendungsversion von SimpleumSafe.
Spezifikation von RNCryptor Version 3 lesen
Sicherer temporärer Speicher unter macOS
Einige macOS-Abläufe benötigen eine Dateisystemkopie, beispielsweise wenn Quick Look oder eine externe Anwendung eine Datei öffnet. Beim Start erzeugt SimpleumSafe einen neuen verschlüsselten temporären Arbeitsbereich.
Für eine autorisierte Vorschau oder Bearbeitung führt SimpleumSafe folgende Schritte aus:
- Die Datei wird im verschlüsselten temporären Arbeitsbereich abgelegt.
- Die Vorschau- oder Bearbeitungsanwendung wird mit dieser Arbeitskopie geöffnet.
- SimpleumSafe beobachtet Speichervorgänge und importiert Änderungen zurück in den Safe.
- Nach dem Schließen der externen Anwendung wird die Arbeitskopie entfernt.
Wenn der temporäre Arbeitsbereich außer Betrieb genommen wird, ändert SimpleumSafe sein Passwort auf einen neuen, nicht gespeicherten Zufallswert und verwendet den Arbeitsbereich nicht erneut. Dadurch ist die Anwendung nicht auf das sichere Löschen einzelner Blöcke einer SSD angewiesen.
Autorisierungskontrollen
Sicherheitsrelevante Änderungen wie das Ändern des Safe-Passworts oder ausgewählter Einstellungen zur automatischen Sperrung verlangen eine erneute Autorisierung mit dem aktuellen Safe-Passwort.
Nach einem falschen Passwortversuch verzögert die Oberfläche den nächsten Versuch. Die Verzögerung wächst exponentiell: 2 Sekunden, danach 4, 8, 16, 32 Sekunden und so weiter bei wiederholten Versuchen in derselben Sitzung. Das bremst Rateversuche über die Oberfläche, ersetzt aber weder ein starkes Passwort noch den durch PBKDF2 verursachten Aufwand bei Offline-Angriffen.
Bei der Wahl eines neuen Passworts verwendet SimpleumSafe den Passwortstärke-Schätzer zxcvbn als Rückmeldung. Solche Schätzungen sind eine Orientierung und keine Garantie für die tatsächlich von einem Angreifer benötigte Zeit.
Verschlüsselte Synchronisation
SimpleumSafe unterstützt drei Synchronisationswege:
- iCloud-Synchronisation über CloudKit für Apple-Geräte,
- direkte Synchronisation zwischen Geräten mit Apples Multipeer-Connectivity-Technologien und
- Ordnersynchronisation zwischen Macs über einen gemeinsamen Ordner, beispielsweise auf einem NAS oder Wechseldatenträger.
Simpleum Media betreibt für diese Verfahren keinen eigenen Synchronisationsserver.
Synchronisationsmodell
Jedes Gerät protokolliert Safe-Änderungen in verschlüsselten Transaktionsdaten. Bei der Synchronisation tauschen die Geräte neue Transaktionen aus, integrieren sie und übertragen die zugehörigen verschlüsselten Dateinutzdaten. Metadaten können vor einer großen Dateinutzlast eintreffen; die Oberfläche kann deshalb einen Eintrag anzeigen, bevor dessen Dateiinhalt vollständig übertragen wurde.
Synchronisationsdaten bleiben auf dem Quellgerät, dem Synchronisationsziel und dem empfangenden Gerät verschlüsselt, bis eine autorisierte Safe-Sitzung sie verwendet.
Synchronisationskonfiguration
Eine Synchronisationskonfiguration identifiziert den Safe und das gewählte Synchronisationsverfahren und enthält das vom empfangenden Gerät benötigte Schlüsselmaterial. Sie ist mit dem Safe-Passwort verschlüsselt und wird direkt als Datei oder über eine gerätenahe Netzwerkverbindung übertragen.
Die Synchronisationskonfiguration ist vom normalen Synchronisationsziel getrennt. Sie ist als sensibles Schlüsselmaterial zu behandeln und darf nicht zusammen mit einer nicht vertrauenswürdigen Kopie der Synchronisationsdaten aufbewahrt werden.
Keine Safe-Schlüsseldatei im Synchronisationsziel
Der normale CloudKit-, Ordner- oder Gerät-zu-Gerät-Synchronisationsdatenbestand enthält nicht die separate Safe-Schlüsseldatei. Eine kopierte Synchronisationsdatenmenge und die Kenntnis des Safe-Passworts reichen daher allein nicht aus, um die synchronisierten Safe-Daten zu entschlüsseln.
Diese Grenze gilt nicht mehr, wenn ein Angreifer zusätzlich eine Synchronisationskonfiguration, die Safe-Schlüsseldatei, Wiederherstellungsmaterial, einen entsperrten Endpunkt oder die Kontrolle über ein konfiguriertes Gerät erlangt.
Synchronisation ist kein Backup. Löschungen und unerwünschte Änderungen können auf andere Geräte übertragen werden. Ein unabhängiges, getestetes Backup bleibt daher erforderlich.
Kontrollen in der Softwareentwicklung
Die Entwicklung von SimpleumSafe verwendet Issue-Tracking und Versionskontrolle, um Anforderungen und Codeänderungen nachvollziehbar zu machen. Sicherheitsrelevante Komponenten und Nutzerabläufe werden durch automatisierte Unit- und Oberflächentests abgedeckt. Diese Kontrollen reduzieren Risiken, beweisen aber nicht, dass Software fehlerfrei ist.
Glossar
Mehr erfahren
- So funktioniert SimpleumSafeEin weniger technischer Überblick über Produktarchitektur und tägliche Abläufe.
- Sicherheit von SimpleumSafeSchutzebenen, praktische Sicherheitsmaßnahmen und das Sicherheitscenter.
- VerschlüsselungsmethodenEine kompakte Erklärung von AES-256 und den geschützten Bestandteilen.
- Support und FAQsAntworten, Anleitungen, Versionshinweise und Kontaktmöglichkeiten.
Referenzen
- NIST FIPS 197: Advanced Encryption Standard
- Spezifikation von RNCryptor Version 3
- Sicherheitsdesign von SQLCipher
- Apple-Dokumentation zu CloudKit
Versionshistorie
| Dokumentversion | Gilt für | Veröffentlicht | Änderungen |
|---|---|---|---|
| 3.2 Aktuell | SimpleumSafe 3.8 | Architektur und Sprache geprüft; CloudKit und aktuelle PBKDF2-Einstellungen dokumentiert; responsive Illustrationen ergänzt. | |
| 3.1 | SimpleumSafe 3.5 | PBKDF2-Arbeitsfaktor auf eine Million Iterationen erhöht. | |
| 3.0 | SimpleumSafe 3.0 | Versionsaktualisierung. | |
| 2.0 | SimpleumSafe 2.0 | Synchronisation ergänzt. | |
| 1.1 | SimpleumSafe 1.1.2, 1.0 | Textkorrekturen. | |
| 1.0 | SimpleumSafe 1.0 | Erstfassung. |