Sicherheitsarchitektur: Der vollständige technische Stack

Vaultaire verwendet AES-256-GCM für die authentifizierte Verschlüsselung von Tresorindizes, verpackten Schlüsseln, Dateikopfzeilen, Inhalten, Miniaturansichten und Metadaten. PBKDF2-HMAC-SHA512 leitet aus dem Muster und einem geräteweiten Keychain-Salt einen lokalen Tresorschlüssel ab. Dieser Tresorschlüssel umschließt einen separaten zufälligen 256-Bit-Hauptschlüssel, der die Dateiverschlüsselung über CryptoKit im App-Prozess durchführt.

Der kryptografische Stack

Vaultaire verwendet mehrere zusammenarbeitende kryptografische Mechanismen, die jeweils für eine bestimmte Aufgabe ausgewählt werden. PBKDF2 verwandelt einen menschlichen Berechtigungsnachweis in einen Tresor- oder Wiederherstellungsschlüssel. AES-256-GCM schützt Indizes, Wrapper, Metadaten, Miniaturansichten und Dateiinhalte. Ein zufälliger Hauptschlüssel trennt die langlebige Dateiverschlüsselung von einem veränderbaren Muster. Keychain und der iOS-Datenschutz schützen gerätegebundene Salt- und Wiederherstellungsdatensätze, während das Gerät gesperrt ist. Kein vom Anbieter bereitgestellter Entschlüsselungsschlüssel ermöglicht dem Entwickler routinemäßigen Zugriff auf den Tresor-Klartext.

Das ist keine Komplexität an sich. Jede Schicht adressiert eine andere Angriffsfläche. AES-256-GCM kombiniert Vertraulichkeit mit Authentifizierung, sodass geänderter Chiffretext die Überprüfung nicht besteht. PBKDF2 erhöht die Kosten für das Testen jedes Musters oder jeder Phrase. Der zufällige Hauptschlüssel bedeutet, dass bei einer Musteränderung ein Schlüssel neu verpackt werden kann, anstatt jede Datei neu zu verschlüsseln. Keychain-Datenschutz schützt lokale Salt- und Wiederherstellungsdatensätze, während die App weiterhin anerkennt, dass die symmetrische Verschlüsselung im Prozessspeicher erfolgt.

Zusammen bilden diese Schichten eine Defense-in-Depth-Architektur, doch nicht alle Schichten sind unabhängige Barrieren. Ein geratenes Muster kann anhand des Indexdateinamens und der AES-GCM-Authentifizierung überprüft werden, und ein kompromittiertes entsperrtes Gerät kann Schlüssel oder Klartext im App-Prozess erkennen. Die Architektur hängt daher von der Entropie des Berechtigungsnachweises ab, von PBKDF2-Kosten, iOS-Geräteschutz und korrekter Handhabung der authentifizierten Verschlüsselung sowie die Stärke von AES selbst.

AES-256-GCM: Dateiverschlüsselung

Jedes in Vaultaire gespeicherte Foto, Video und Dokument ist mit AES-256-GCM verschlüsselt – der Advanced Encryption Standard mit einem 256-Bit-Schlüssel Galois/Counter-Modus. Vaultaire verwendet auch AES-GCM für Tresorindizes, Dateikopfzeilen, Miniaturansichten und Schlüsselumschläge. Der Algorithmus und die Schlüsselgröße sind standardisiert; die Sicherheit von Vaultaire hängt immer noch von der Nonce-Verwaltung, der Schlüsselverwaltung, der Stärke der Anmeldeinformationen und der korrekten Implementierung ab.

Die “256” in AES-256 bezieht sich auf die Schlüssellänge in Bits. Ein 256-Bit-Schlüssel hat 2²⁵⁶ mögliche Werte. Um diese Zahl einzuordnen: Es gibt ungefähr 10⁸⁰ Atome im beobachtbaren Universum. Wäre jedes Atom ein Supercomputer, der eine Milliarde Schlüssel pro Sekunde testet, und das seit dem Urknall, hätten sie weniger als ein Billionstel eines Billionstels von einem Prozent des Schlüsselraums erkundet. AES-256 wird nicht per Brute Force geknackt. Nicht heute. Nicht in diesem Jahrhundert. Nicht bevor die Sterne erlöschen.

Warum der GCM-Modus wichtig ist

AES ist eine Block-Chiffre — sie verschlüsselt Daten in 128-Bit-Blöcken. Der “Modus” bestimmt, wie diese Blöcke kombiniert werden. GCM (Galois/Counter Mode) bietet zwei Dinge, die einfachere Modi wie CBC nicht haben: parallelisierte Verschlüsselung und eingebaute Authentifizierung.

Der Authentifizierungs-Teil ist entscheidend. GCM erzeugt einen kryptografischen Tag für jede verschlüsselte Datei. Dieser Tag funktioniert wie ein Manipulationssiegel. Wird auch nur ein einziges Bit des Chiffretexts verändert — ob durch einen böswilligen Akteur oder einen beschädigten Festplattensektor — stimmt der Authentifizierungs-Tag nicht mehr, und die Entschlüsselung schlägt fehl. Du bekommst keine beschädigten Daten. Du bekommst ein klares Signal, dass etwas nicht stimmt. Diese Eigenschaft nennt sich authentifizierte Verschlüsselung, und sie verhindert eine ganze Klasse von Angriffen, bei denen ein Gegner verschlüsselte Daten manipuliert, um die entschlüsselte Ausgabe zu beeinflussen.

PBKDF2: Schlüsselableitung

Vaultaire leitet unterschiedliche Schlüssel für unterschiedliche Aufgaben ab. Das Muster und ein geräteweites Keychain-Salt fließen für 600.000 Iterationen in PBKDF2-HMAC-SHA512 ein, um den lokalen Tresorschlüssel zu erzeugen. Eine deterministische Musterableitung erzeugt den separaten Cloud-Backup-Schlüssel. Die normalisierte Wiederherstellungsphrase läuft über 800.000 PBKDF2-Iterationen, um den Schlüssel für einen Wiederherstellungsumschlag zu erstellen. Keine dieser Ableitungen wandelt einen menschlichen Berechtigungsnachweis in 256 Bit Entropie um, nur weil die Ausgabe 256 Bit lang ist.

Wie PBKDF2 dein Muster schützt

Die Kernidee hinter PBKDF2 ist bewusster Rechenaufwand. Es nimmt das serialisierte Muster oder die normalisierte Phrase und führt Hunderttausende HMAC-SHA512-Iterationen aus. Ein legitimer Benutzer zahlt diese Kosten einmalig während eines Entsperr- oder Wiederherstellungsversuchs. Ein Angreifer zahlt es für jeden Kandidaten, obwohl parallele Hardware- und Implementierungsoptionen die tatsächliche Rate der Rateversuche bestimmen.

Vaultaire konfiguriert PBKDF2 mit 600.000 Iterationen für musterabgeleitete Schlüssel. Das macht jeden Rateversuch teurer, aber eine seriöse Schätzung der Angriffsdauer muss eine gemessene Zeit pro Kandidat und Hardwareannahmen enthalten. Bei genau 1 ms pro Kandidat dauern 1.000.000.000 serielle Rateversuche etwa 11,6 Tage, nicht Jahre. Das 256-Bit-Ergebnis erweitert nicht die Entropie eines vorhersehbaren Musters.

Bei der lokalen Musterableitung wird ein kryptografisch zufälliger Salt für das Gerät verwendet, der als WhenUnlockedThisDeviceOnly-Keychain-Element gespeichert wird. Das Salt ist nicht geheim und wird von den Tresoren auf diesem Gerät gemeinsam genutzt. Es verhindert, dass eine für ein Gerät erstellte Tabelle direkt auf ein anderes Gerät mit einem anderen Salt angewendet wird, zwingt einen Angreifer jedoch nicht dazu, für jeden Tresor auf demselben Gerät von vorne zu beginnen.

AES-256-GCM: Metadatenschutz

Dateiinhalte zu verschlüsseln reicht nicht. Dateinamen, Erstellungsdaten, Thumbnail-Abmessungen und Tresor-Struktur sind alles Metadaten — und Metadaten können genauso viel verraten wie die Daten selbst. Eine Datei namens “steuererklärung-2025.pdf” sagt einem Angreifer genau, was drin ist, selbst wenn der Inhalt verschlüsselt ist. Ein Zeitstempel zeigt, wann du den Tresor genutzt hast. Eine Thumbnail-Größe verrät, ob etwas ein Foto oder ein Video ist.

Vaultaire schützt diese Metadaten mit AES-256-GCM, nicht ChaCha20. Dateinamen und MIME-Typen werden in verschlüsselte Dateiheader codiert. Der verschlüsselte Tresorindex enthält Dateidatensätze, Daten, Größeninformationen, Speicherlayout und den verpackten Hauptschlüssel. Miniaturbilddaten werden ebenfalls unter dem zufälligen Hauptschlüssel verschlüsselt.

Warum authentifizierte Verschlüsselung für Metadaten?

Metadaten benötigen sowohl Integrität als auch Vertraulichkeit. AES-GCM erstellt für jeden verschlüsselten Wert ein Authentifizierungs-Tag, sodass Vaultaire einen geänderten Header, Index, eine Miniaturansicht oder einen Umschlag ablehnen kann, anstatt vom Angreifer kontrollierten Klartext zu akzeptieren. Das Design verwendet bewusst eine authentifizierte Verschlüsselungskonstruktion für alle diese Speicherformate, anstatt kryptografische Vielfalt zu beanspruchen, die die Implementierung nicht bietet.

Die gleiche Chiffre bedeutet nicht, dass der gleiche Schlüssel oder die gleiche Nonce blind wiederverwendet wird. Der Tresorschlüssel schützt den Index und umschließt den zufälligen Hauptschlüssel. Der Hauptschlüssel schützt das Dateimaterial. CryptoKit erstellt authentifizierte, versiegelte Boxen mit neuen Nonces, während das Streaming-Format von Vaultaire für jeden geordneten Block eine eindeutige Nonce ableitet. Die relevanten Garantien ergeben sich aus der Schlüsseltrennung, der Nonce-Disziplin und der Authentifizierung, nicht aus einer zweiten Metadatenverschlüsselung.

Zero-Knowledge-Architektur

Hier ist eine Frage, die sich bei jeder Sicherheits-App zu stellen lohnt: Was passiert, wenn das Unternehmen dahinter gehackt, vorgeladen oder einfach böswillig wird?

Bei den meisten Apps ist die Antwort unbequem. Sie halten deine Daten, deine Schlüssel oder beides. Ein Gerichtsbeschluss zwingt sie zur Herausgabe. Ein Datenleck legt es offen. Ein abtrünniger Mitarbeiter greift darauf zu. Die Sicherheit der App ist nur so stark wie die Betriebssicherheit des Unternehmens — und die Geschichte zeigt, dass Unternehmen regelmäßig kompromittiert werden.

Vaultaire betreibt keinen Konto- oder Speicherdienst, der deine Muster, Geheimphrasen, Entschlüsselungsschlüssel oder lesbaren Tresorinhalte empfängt. Die Verschlüsselung und Entschlüsselung erfolgt im App-Prozess auf deinem Gerät. Wenn die iCloud-Sicherung aktiviert ist, sendet die App authentifizierten Chiffretext an die private CloudKit-Datenbank deines Kontos statt an einen von Vaultaire kontrollierten Tresordienst.

Was Zero-Knowledge in der Praxis bedeutet

Wenn eine Strafverfolgungsbehörde Vaultaire eine Vorladung mit der Forderung nach Tresor-Klartext zustellt, verfügt das Unternehmen nicht über das Muster, die Wiederherstellungsphrase, den Tresorschlüssel, den Backup-Schlüssel oder den Hauptschlüssel, die zum Entschlüsseln erforderlich sind. Verschlüsselte iCloud-Datensätze liegen in der privaten CloudKit-Datenbank des Benutzers. Auf dem Gerät liegt das Wiederherstellungsmaterial jedoch in einer verschlüsselten Keychain-Datenbank, und symmetrische Schlüssel sind im App-Speicher vorhanden, während CryptoKit einen offenen Tresor ver- oder entschlüsselt.

Diese Anbietergrenze ist eine architektonische Eigenschaft und kein Versprechen, dass jeder Teil der Clientumgebung außerhalb des Vertrauensmodells liegt. Vaultaire verfügt nicht über einen serverseitigen Entschlüsselungsschlüssel, den es für die routinemäßige Wiederherstellung des Tresors weitergeben kann. Die ausgelieferte App, iOS, das entsperrte Gerät und die kryptografische Implementierung können weiterhin lesbare Daten verarbeiten und müssen entsprechend vertrauenswürdig sein.

Keychain und die App-Prozessgrenze

Apples Secure Enclave kann unterstützte private Schlüssel schützen und beteiligt sich an Teilen der Sicherheitsarchitektur der Plattform, seine öffentlichen APIs nehmen jedoch keine beliebigen per PBKDF2 abgeleiteten symmetrischen Schlüssel an und führen Vaultaires AES-GCM-Dateioperationen nicht im Coprozessor aus. Vaultaire bezeichnet seine Tresorchiffre daher nicht als Secure Enclave AES.

Vaultaire verwendet gewöhnliche generische Passwortelemente im iOS-Keychain für das zufällige Geräte-Salt, die verschlüsselte Wiederherstellungsdatenbank und den zufälligen Schlüssel, der diese Datenbank schützt. Diese Elemente verwenden die Zugriffsklasse „WhenUnlockedThisDeviceOnly“. Keychain und Datenschutz schaffen eine sinnvolle Gerätegrenze, insbesondere wenn das Telefon gesperrt ist. Diese Architektur unterscheidet sich jedoch von einem nicht exportierbaren Secure-Enclave-Schlüssel.

Wenn du das Muster zeichnest, leitet CommonCrypto den Tresorschlüssel im App-Prozess ab. CryptoKit und die CryptoEngine von Vaultaire verwenden dann in diesem Prozess symmetrische Schlüsselbytes, um den Index zu authentifizieren und zu entschlüsseln, den Hauptschlüssel zu entpacken und Dateien zu verarbeiten. Die App löscht den aktiven Status, wenn sie gesperrt wird, aber ein ausreichend privilegierter Angreifer, der eine entsperrte Sitzung beobachtet, hat andere Möglichkeiten als ein Prüfer, der nur Chiffretext des gesperrten Geräts besitzt.

Ein Betriebssystem mit Jailbreak oder auf andere Weise kompromittiert kann Mustereingaben, App-Speicher, entschlüsselte Vorschauen, Exporte oder den Bildschirm angreifen. Vaultaire empfiehlt ein aktuelles iPhone ohne Jailbreak, weil das Design auf iOS-Prozessisolation, Keychain und Datenschutz angewiesen ist. Es wird nicht behauptet, dass eine Root-Kompromittierung die symmetrischen Schlüssel eines offenen Tresors unzugänglich macht.

Initialisierungsvektoren pro Datei

Wenn du zwei identische Dateien mit demselben Schlüssel verschlüsselst, würde eine naive Implementierung identischen Chiffretext erzeugen. Das ist ein Problem. Ein Angreifer, der zwei identische verschlüsselte Blobs sieht, weiß — ohne irgendetwas zu entschlüsseln — dass die beiden Originaldateien identisch sind. In einem Tresor voller Fotos kann diese Art von Musteranalyse Informationen selbst durch Verschlüsselung hindurch offenlegen.

Vaultaire verhindert deterministischen Chiffretext, indem es für jeden AES-256-GCM-Versiegelungsvorgang eine neue kryptografische Nonce erzeugt. Dateiheader und Dateiinhalt werden separat versiegelt, und große Dateien verwenden ein authentifiziertes Streaming-Format mit einer zufälligen Basis-Nonce und einer eindeutigen Nonce für jeden geordneten Block. Zwei Kopien desselben Fotos ergeben daher nicht die gleiche verschlüsselte Darstellung.

Die Nonces werden mit dem Chiffretext gespeichert und sind nicht geheim; ihre Sicherheitsanforderung ist die Einzigartigkeit unter einem bestimmten Schlüssel. Vaultaire fordert 96-Bit-Nonces vom kryptografischen Zufallsgenerator von Apple für die Single-Shot-Verschlüsselung an und zeichnet die Basis-Nonces im Streaming-Header auf. Das Kollisionsrisiko wird durch die Anzahl der Verschlüsselungen unter einem Schlüssel bestimmt, sodass die Implementierung einen neuen Wert generiert, anstatt die 96-Bit-Größe als feste lebenslange Garantie von 1 zu 2⁹⁶ darzustellen.

Speicherverwaltung: Aktiven Schlüsselstatus löschen

Ein häufiger Fehler in Sicherheitssoftware ist, sensible Daten im Speicher zu belassen, nachdem sie nicht mehr gebraucht werden. Verschlüsselungs-Schlüssel, abgeleitete Passwörter und entschlüsselte Daten können im RAM verbleiben, lange nachdem die App sie nicht mehr braucht. Forensische Werkzeuge können den Gerätespeicher dumpen und nach diesen Überbleibseln suchen.

Vaultaire begrenzt, wie lange der aktive Schlüsselstatus und entschlüsselte UI-Daten verfügbar bleiben. Wenn die App gesperrt oder die Sitzung abgebrochen wird, folgt ihr Code mehreren Bereinigungspfaden:

• Der aktive Tresorstatus wird gelöscht. Die App entfernt ihre aktuelle Tresorschlüsselsitzung und erfordert eine erneute Entsperrung, bevor Tresorinhalte angezeigt werden.
• Schlüssel-Wrapper löschen eigene Puffer. Die sicheren Byte-Container von Vaultaire überschreiben die Puffer, die sie besitzen, wenn die Zuordnung dieser Container aufgehoben wird.
• Der zwischengespeicherte Hauptschlüsselstatus wird verworfen. Der entschlüsselte Hauptschlüssel für den offenen Index wird auf den entsprechenden Sperr- und Cache-Reset-Pfaden verworfen.
• Entschlüsselte UI-Caches werden dort gelöscht, wo Vaultaire dies kontrolliert. Durch die Bereinigung von Miniaturansichten und Vorschauen wird der verbleibende Anwendungsstatus reduziert, ohne die Kontrolle über jede Kopie zu beanspruchen, die Swift, iOS oder ein anderer Prozess erstellt.

Wenn Vaultaire das nächste Mal im gesperrten Zustand geöffnet wird, zeichnest du das Muster und die App leitet den Tresorschlüssel erneut ab, bevor sie den Index authentifizieren und den Hauptschlüssel entpacken kann. Hierbei handelt es sich um eine Sitzungsbereinigung, nicht um die Behauptung, dass jede vorübergehende Speicherkopie eine nachweisbare Löschung in mehreren Durchgängen erhalten hat oder dass eine Secure-Enclave-Schlüsselreferenz zerstört wurde. Nach einem Absturz gibt iOS den Prozess frei, aber der Bereinigungscode kann nicht nach jedem abrupten Abbruch ausgeführt werden.