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 einen lokalen und einen geräteweiten Tresorschlüssel ab Keychain Salz. Dieser Tresorschlüssel umschließt einen separaten zufälligen 256-Bit-Hauptschlüssel, der die Dateiverschlüsselung durchführt CryptoKit im App-Prozess.

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 iOS Der Datenschutz schützt 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 Vault-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, es handelt sich jedoch nicht alle um unabhängige Barrieren. Ein vermutetes Muster kann anhand des Indexdateinamens und überprüft werden AES-GCM Authentifizierung, und ein kompromittiertes entsperrtes Gerät kann Schlüssel oder Klartext im App-Prozess erkennen. Die Architektur hängt daher von der Credential-Entropie ab. PBKDF2 Kosten, iOS Geräteschutz und korrekte 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 verschlüsselt AES-256-GCM – 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 Salzfutter PBKDF2-HMAC-SHA512 für 600.000 Iterationen, 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 dahinter PBKDF2 ist bewusste Arbeit. Es verwendet das serialisierte Muster oder die normalisierte Phrase und führt Hunderttausende davon aus HMAC-SHA512 Iterationen. 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 Schätzrate bestimmen.

Vaultaire konfiguriert PBKDF2 mit 600.000 Iterationen für musterabgeleitete Schlüssel. Das macht jede Schätzung teurer, aber eine verantwortungsvolle Angriffsschätzung muss eine gemessene Zeit pro Kandidat und Hardwareannahmen enthalten. Bei genau 1 ms pro Kandidat dauern 1.000.000.000 serielle Schätzungen 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 gespeichert wird Keychain Artikel. Das Salz 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 bestellten Block eine eindeutige Nonce ableitet. Die relevanten Garantien ergeben sich aus der Schlüsseltrennung, der Nonce-Disziplinierung 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 Ihre Muster, Geheimphrasen, Entschlüsselungsschlüssel oder lesbaren Tresorinhalte empfängt. Die Verschlüsselung und Entschlüsselung erfolgt im App-Prozess auf Ihrem Gerät. Wann iCloud Wenn die Sicherung aktiviert ist, sendet die App authentifizierten Chiffretext an Ihr privates Konto CloudKit Datenbank 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 Vault-Klartext zustellt, verfügt das Unternehmen nicht über das Muster, die Wiederherstellungsphrase, den Vault-Schlüssel, den Backup-Schlüssel oder den Hauptschlüssel, die zum Entschlüsseln erforderlich sind. Verschlüsselt iCloud Aufzeichnungen leben beim Benutzer CloudKit private Datenbank. Auf dem Gerät wird das Wiederherstellungsmaterial jedoch verschlüsselt gespeichert Keychain Datenbank und symmetrische Schlüssel sind im App-Speicher vorhanden CryptoKit verschlüsselt oder entschlüsselt einen offenen Tresor.

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 akzeptieren jedoch keine willkürlichen Schlüssel PBKDF2-abgeleiteter symmetrischer Schlüssel und führen Sie Vaultaires aus AES-GCM Dateioperationen innerhalb des Coprozessors. Vaultaire bezeichnet seine Tresorchiffre daher nicht als Secure Enclave AES.

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

Wenn Sie das Muster zeichnen, CommonCrypto leitet 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 eine aktuelle Version ohne Jailbreak iPhone weil das Design darauf angewiesen ist iOS Prozessisolation, Keychainund Datenschutz. 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 eine neue kryptografische Nonce generiert AES-256-GCM Versiegelungsvorgang. 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 Eins-zu-2-Größe darzustellen⁹⁶ lebenslange Garantie.

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 ist ungültig. 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 dass die Kontrolle über jede von Swift erstellte Kopie beansprucht wird. iOSoder ein anderer Prozess.

Wenn Vaultaire das nächste Mal im gesperrten Zustand geöffnet wird, zeichnen Sie 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 a Secure Enclave Schlüsselreferenz wurde zerstört. Ein Absturz verursacht iOS um den Prozess wiederherzustellen, aber der Bereinigungscode kann nicht nach jedem abrupten Abbruch ausgeführt werden.