Der Schutz beginnt vor dem Hochladen
Dateiinhalte, Dateinamen, MIME-Typen, Miniaturansichten, Tresornamen sowie Ordnernamen und -struktur werden auf Ihrem Gerät verschlüsselt, bevor sie hochgeladen werden. Der Dienst speichert Chiffretext und verpackte Schlüssel. Ein Eindringling, der nur diese gespeicherten Datensätze erhält, erhält nicht den Klartext-Tresorschlüssel, das Gerätegeheimnis oder Ihren Wiederherstellungsschlüssel.
Dies setzt voraus, dass der Browser, das Betriebssystem, der bereitgestellte Anwendungscode und der Zufallszahlengenerator vertrauenswürdig sind, wenn Sie einen Tresor erstellen oder entsperren. Die Verschlüsselung im Ruhezustand kann einen entsperrten Tresor nicht vor schädlichem Code schützen, der auf Ihrem Gerät ausgeführt wird.
Unabhängige Schlüssel für jeden Tresor
Jeder Tresor beginnt mit einem zufällig generierten 256-Bit-AES-Hauptschlüssel. Der Schlüssel wird vom kryptografischen Zufallszahlengenerator des Browsers generiert und nicht direkt von Ihrer Geste abgeleitet. Separate Tresorschlüssel begrenzen die Auswirkungen der Offenlegung eines einzelnen Tresorschlüssels.
Ein Gerätemuster kombiniert die geordnete Punktfolge mit einem zufälligen 256-Bit-Gerätegeheimnis. PBKDF2 mit HMAC-SHA-256, einem neuen 128-Bit-Salt und 600.000 Iterationen leitet einen 256-Bit-Wrapping-Schlüssel ab. AES-256-GCM verschlüsselt dann den Hauptschlüssel unter diesem Verpackungsschlüssel. Der Dienst empfängt den verschlüsselten Wrapper, seinen Salt und öffentliche Ableitungsparameter. Das Gerätegeheimnis verbleibt in der lokalen IndexedDB-Datenbank dieses Browsers.
Muster verwenden nur ein 5 × 5-Raster und mindestens sechs verschiedene Punkte. Frühere Musterformate werden nicht unterstützt. Vorhandene Tresore benötigen ihre Wiederherstellungsschlüssel, um ein neues Muster zu registrieren. Die Rastergröße ist kein Versprechen für die Passwortstärke: Vorhersehbare Gesten sind immer noch leichter zu erraten. Das Gerätegeheimnis bietet zusätzlichen Schutz vor jemandem, der nur über die Serverdatensätze verfügt, es handelt sich jedoch nicht um einen hardwaregestützten Schlüssel. Jemand, der sowohl das lokale Geheimnis als auch den Wrapper kopiert, kann offline versuchen, Muster zu erraten.
Passkeys authentifizieren Ihr Konto mithilfe von Public-Key-Challenge-Antworten. Bei der Kontoauthentifizierung wird kein Tresorschlüssel abgeleitet und Ihre Dateien werden nicht entschlüsselt. Eine gültige Kontositzung und eine erfolgreiche Tresor-Entsperrung sind separate Anforderungen im normalen Antragsablauf.
| Zweck | Konstruktion |
|---|---|
| Tresorhauptschlüssel | Zufälliger 256-Bit-AES-Schlüssel |
| Schlüsselverpackung | PBKDF2-HMAC-SHA-256 · 600.000 Iterationen · 128-Bit-Salt → AES-256-GCM |
| Metadaten und Miniaturansichten | AES-256-GCM · zufälliges 96-Bit-Nonce · 128-Bit-Authentifizierungs-Tag |
| Ableitung des Dateischlüssels | HKDF-SHA-256 · Zufälliges 256-Bit-Salt pro Datei · 256-Bit-AES-Ausgabe |
| Wiederherstellungsgeheimnis | 192 Zufallsbits, angezeigt als sechs Gruppen hexadezimaler Zeichen |
Vertraulichkeit und Manipulationserkennung
Tresormetadaten, Dateimetadaten, Miniaturansichten und verpackte Schlüssel verwenden AES-256-GCM mit 128-Bit-Authentifizierungstags. Jede unabhängige Verschlüsselung verwendet eine neue zufällige 96-Bit-Nonce. Bei der Entschlüsselung wird das Tag überprüft, bevor Klartext zurückgegeben wird. Ein geänderter Chiffretext oder ein falscher Schlüssel führen dazu, dass die Authentifizierung fehlschlägt.
Zusätzliche authentifizierte Daten binden jedes verschlüsselte Objekt an seine Formatversion, Tresor-ID, Objekt-ID und seinen Zweck. Beispielsweise verwenden eine Miniaturansicht und ein Dateimetadatensatz unterschiedliche Kontexte. Das Verschieben eines verschlüsselten Objekts in einen anderen Tresor oder das Ersetzen durch ein anderes Objekt ändert den authentifizierten Kontext und die Überprüfung schlägt fehl.
Der authentifizierte Kontext verbirgt keine Identifikatoren und beweist nicht die Aktualität. Ein gültiger älterer Datensatz kann immer noch ein gültiges Tag haben. Überprüfungen der Anwendungsrevision erkennen gewöhnliche gleichzeitige Aktualisierungen. Dies stellt jedoch keinen kryptografischen Schutz gegen einen bösartigen Dienst dar, der einen komplett älteren Zustand wiedergibt.
Große Dateien verwenden authentifizierte Segmente
Dateiinhalte verwenden die von Tink beschriebene Streaming-Konstruktion AES-256-GCM-HKDF-SHA-256, die mithilfe kryptografischer Browserprimitive implementiert wird. Jeder neue Dateistream verfügt über einen 40-Byte-Header, der seine Längenmarkierung, einen zufälligen 32-Byte-Salt und ein zufälliges 7-Byte-Nonce-Präfix enthält.
HKDF leitet einen separaten Dateiverschlüsselungsschlüssel vom Tresorhauptschlüssel ab. Zu seinem Kontext gehören die Tresor- und Dateikennungen, die Klartext-Bytelänge und die konfigurierte Segmentgröße. Die 12-Byte-Nonce jedes Segments kombiniert das zufällige Präfix, einen 4-Byte-Segmentzähler und ein Endsegment-Flag. Segmente tragen 128-Bit-GCM-Tags.
Die Anwendung verarbeitet Dateien in begrenzten Segmenten von etwa 5 MiB. Segmentpositionen, das Endsegment-Flag und erwartete Bytelängen führen dazu, dass die Überprüfung vertauschter, geänderter oder abgeschnittener Segmente fehlschlägt. Downloads authentifizieren jedes Segment, bevor sie es veröffentlichen; Ein Fehler zu spät in einem Stream kann zu einem unvollständigen Download führen, daher ist der erfolgreiche Abschluss wichtig. Bei Upload-Wiederholungen werden bereits verschlüsselte Bytes wiederverwendet, anstatt neue Inhalte mit derselben Segment-Nonce zu verschlüsseln.
Der Aufbau folgt dem Tink AES-GCM-HKDF Streaming-Spezifikation. Die Implementierung und Segmentkonfiguration von Revault wurde von Tink nicht unabhängig geprüft oder zertifiziert.
Die Wiederherstellung ist ein zweiter Pfad zum gleichen Schlüssel
Ein Wiederherstellungsgeheimnis wird aus 24 zufälligen Bytes generiert, was 192 Bits zufälliger Eingabe ergibt. Es leitet unabhängig einen Verpackungsschlüssel mithilfe von PBKDF2-HMAC-SHA-256 und seinem eigenen Salt ab und verschlüsselt denselben Tresorhauptschlüssel mit AES-256-GCM. Jeder, der das Wiederherstellungsgeheimnis und eine Kopie des verschlüsselten Tresors erhält, kann diesen Tresor entschlüsseln.
Das Wiederherstellungsgeheimnis wird beim Setup angezeigt und vom Dienst nicht im Klartext gespeichert. Bewahren Sie es getrennt von Ihren verschlüsselten Dateien auf. Durch das Löschen der Browserdaten wird das Gerätegeheimnis entfernt. Für die Wiederherstellung des Zugriffs sind die verschlüsselte Cloud-Kopie Ihres Kontos und der Wiederherstellungsschlüssel oder ein exportiertes verschlüsseltes Backup und der zugehörige Wiederherstellungsschlüssel erforderlich. Es gibt keinen vom Anbieter gehaltenen Master-Entschlüsselungsschlüssel.
Ein Wiederherstellungskit enthält ein Geheimnis und Schlüssel-Wrapper, aber keinen Dateiinhalt. Ein verschlüsseltes Backup enthält ein authentifiziertes Inventar und verschlüsselte Dateisegmente, ohne das Gerätegeheimnis des Browsers. Beim Import werden die verschlüsselten Daten überprüft und ein neuer Tresor mit neuen Kennungen und Schlüsseln erstellt.
Durch das Ändern eines Musters wird der Wrapper dieses Geräts ersetzt. Der Tresor-Hauptschlüssel wird nicht rotiert, ein anderes Gerät wird nicht widerrufen, alte Sicherungen werden ungültig gemacht und ein vorhandenes Wiederherstellungsgeheimnis wird nicht geändert. Wenn ein Tresorschlüssel oder ein Wiederherstellungsgeheimnis kompromittiert ist, verschieben Sie die Daten in einen neuen Tresor mit neuen Schlüsseln.
Native Freigaben verwenden eine unabhängige Verschlüsselung
Mobile Freigaben verpacken standardmäßig die Schlüssel ausgewählter Dateiversionen unter einem neuen Freigabeschlüssel und verwenden vorhandene verschlüsselte Dateibytes. Zusätzliche Isolation verschlüsselt die Dateien optional neu. Quelltresorschlüssel bleiben privat. Identischer Geheimtext kann Freigaben verknüpfen; keine Variante kann eine vom Empfänger gespeicherte Kopie zurückholen.
iOS kann diesen Chiffretext mit einer privaten, schreibgeschützten Einladung in einer separaten CloudKit-Datensatzhierarchie platzieren. Die Synchronisierungszone des Tresors wird nicht gemeinsam genutzt. Plattformübergreifende native Freigaben verwenden begrenzte Serverteile mit SHA-256-Prüfsummen. Unabhängige zufällige 256-Bit-Lese- und Verwaltungsfunktionen werden als Hashes auf dem Server gespeichert. Das Entschlüsselungsgeheimnis wird separat weitergegeben und niemals hochgeladen. Kontrollierte Aktien verfallen zum vom Absender gewählten Zeitpunkt innerhalb von 30 Tagen. Der Dienst zählt Zugriffssitzungen atomar und erzwingt das gewählte Maximum, den Ablauf und den Widerruf. Eine Download-Sitzung dauert höchstens 15 Minuten und niemals länger als der Ablauf der Freigabe.
Empfänger authentifizieren jedes verschlüsselte Segment und öffnen einen isolierten gemeinsamen Tresor mit dem separaten Geheimnis des Absenders. Es ist kein Konto, persönlicher Tresor oder Muster erforderlich. Persönliche Tresore bleiben verschlossen. Wenn der Export zulässig ist, können Empfänger eine verschlüsselte .qvault-Kopie speichern, die mit diesem Freigabegeheimnis geöffnet wird. Ansonsten gibt es keine Exportkontrollen. Die temporäre Sitzung validiert den laufenden Zugriff. Hierbei handelt es sich um Anwendungskontrollen: Screenshots, geänderte Clients und aufbewahrte Kopien können kryptografisch nicht verhindert werden. Freigaben sind Schnappschüsse ohne laufende Quellaktualisierungen. Unbeschränkte CloudKit-Einladungen erzwingen weder Zugriffszahlen noch automatisches Ablaufen; Der Zugriff bleibt bestehen, bis der Eigentümer die Freigabe beendet. Durch das Entfernen eines Originals wird dessen separater Anteil nicht widerrufen, und durch einen Widerruf kann eine bereits aufbewahrte Kopie nicht zurückgerufen werden.
Optionale Tresoraktivität
Native Audit-Protokolle sind standardmäßig deaktiviert und werden pro Tresor auf jedem Gerät konfiguriert. Die letzten 500 lokalen Ereignisse werden mit dem Hauptschlüssel des Tresors und einem dedizierten authentifizierten Kontext verschlüsselt. Sie schließen Schlüssel, Muster, Dateiinhalte und Daten anderer Tresore aus, werden nicht synchronisiert und können gelöscht oder deaktiviert werden. Sie sind kein fälschungssicherer Beweis. Fehlgeschlagene Entsperrungen werden keinem Tresor zugeordnet.
Neue kontrollierte Freigaben, die mit aktivierter Protokollierung erstellt werden, behalten bis zu 100 Zeitstempel der Zugriffssitzungen im Freigabedienst. Nur die Verwaltungsfunktion kann sie abrufen; Das Protokoll enthält keine Empfängeridentität oder kein Entschlüsselungsgeheimnis. Das Deaktivieren der lokalen Protokollierung wirkt sich auf zukünftige Freigaben aus. Vorhandene Freigabeprotokolle behalten ihre ursprüngliche Einstellung bis zum Widerruf oder Ablauf und zur Bereinigung.
Optional verschlüsselte Einbruchsfotos
Besitzer können Einbruchswarnungen für jeden Tresor auf jedem Gerät separat aktivieren. Nach drei unübertroffenen Mustern kann die Vordergrund-App ein Foto der Frontkamera aufnehmen, vorbehaltlich der Erlaubnis, der Verfügbarkeit der Kamera und einer Abklingzeit von einer Minute. Die Anzeigen der Systemkamera bleiben sichtbar. Die letzten zehn Warnungen werden lokal gespeichert und niemals zu Fotos hinzugefügt oder hochgeladen. Ein nicht übereinstimmendes Muster identifiziert keinen Zieltresor, sodass jeder aktivierte Tresor einen separat verschlüsselten Geräteversuchsdatensatz erhält.
Ein dedizierter öffentlicher RSA-3072-Schlüssel umschließt einen neuen 256-Bit-AES-GCM-Schlüssel für jede Warnung unter Verwendung von OAEP mit SHA-256 und MGF1-SHA-256. Dies ermöglicht die Verschlüsselung, während der Tresor gesperrt ist. Der entsprechende private Schlüssel selbst wird unter dem Hauptschlüssel dieses Tresors mit einem dedizierten authentifizierten Kontext verschlüsselt. Nur durch das Entsperren dieses Tresors können seine Fotos entschlüsselt werden. Warnungen werden in der Audit-Ansicht unabhängig von der normalen Aktivitätsprotokollierung angezeigt und können in den Einstellungen für Einbruchswarnungen gelöscht werden. Sie sind kein fälschungssicherer Beweis.
Verschlüsselte Uploads in Ihren eigenen Bucket
Die Speichereinstellungen eines Tresors können diesen Browser direkt mit einem vom Benutzer angegebenen S3-kompatiblen HTTPS-Endpunkt verbinden. Ausgewählte Gerätedateien werden lokal mit derselben Dateikonstruktion verschlüsselt. Jedes wird zu einem separaten, tragbaren .qvault-Objekt, das ein authentifiziertes, verschlüsseltes Inventar und verpackte Tresorschlüssel enthält. Durch zufällige Objektnamen wird vermieden, dass die ursprünglichen Dateinamen offengelegt werden. Für die Wiederherstellung sind das heruntergeladene Objekt und der Tresor-Wiederherstellungsschlüssel erforderlich.
Die Endpunktkonfiguration und die Anmeldeinformationen werden unter dem Vault-Hauptschlüssel mit einem dedizierten authentifizierten Kontext verschlüsselt und im IndexedDB dieses Geräts gespeichert. Sie werden nicht synchronisiert oder an die API von Revault gesendet. Die Anforderungssignierung verwendet AWS Signature Version 4, HMAC-SHA-256, und einen Hash jedes begrenzten Anforderungstexts. Acht-MiB-Multipart-Teile transportieren bereits verschlüsselte Bytes direkt zum Speicheranbieter. Der Bucket-Zugriff unterliegt weiterhin den Berechtigungen und der CORS-Richtlinie dieses Anbieters.
Der Anbieter kann Zugriffsschlüssel-IDs, Objektpfade, Bytegrößen, Upload-Zeiten und Verbindungsinformationen sehen. Halten Sie den Bucket privat und seine Anmeldeinformationen auf die erforderlichen Vorgänge beschränkt. Hochgeladene Objekte sind unabhängig von der Cloud-Synchronisierung und -Freigabe Revault. Sperr- oder Abbruchversuche zum Abbruch nicht abgeschlossener Uploads; Das Schließen von Tabs oder der Verlust der Konnektivität können zu verwaisten Teilen führen. Konfigurieren Sie daher eine Lebenszyklusregel für unvollständige Uploads. Safe Exit entfernt die lokalen Speicheranmeldeinformationen anderer Tresore, löscht jedoch keine Objekte aus ihren Buckets.
Safe Exit entfernt den lokalen Zugriff
Sie können in diesem Browser einen Tresor als Safe Exit-Tresor festlegen. Wenn Sie das Muster dieses Tresors eingeben, wird dieser normal geöffnet, ohne dass eine Auslöserbestätigung oder Abschlussbenachrichtigung erfolgt. Die lokalen Snapshots, verschlüsselten Blöcke, Gerätegeheimnisse und in der Warteschlange befindlichen Änderungen anderer Tresore werden entfernt. Nicht synchronisierte Daten können verloren gehen.
Eine dauerhafte lokale Grenze verhindert, dass diese Tresore automatisch aufgelistet oder durch Synchronisierung in diesem Browser wiederhergestellt werden. Ihre verschlüsselten Cloud-Kopien und Kopien auf anderen Geräten bleiben unverändert. Die Wiederherstellung erfolgt explizit, jeweils für einen Tresor, und erfordert den Wiederherstellungsschlüssel dieses Tresors, bevor ein neues Gerätemuster registriert werden kann.
Dabei handelt es sich um eine lokale Zugriffsentfernung, nicht um eine garantierte physische Löschung oder forensische Verschleierung. Browserprofile, Dateisystem-Snapshots, frühere Downloads, Screenshots, Serviceaufzeichnungen und ein anderes Gerät können Beweise aufbewahren. Durch das Löschen der lokalen Daten dieses Browsers wird auch die lokale Isolationsgrenze gelöscht. Bei einer Neuinstallation können die Cloud-Tresore des Kontos nach der Authentifizierung erneut aufgelistet werden.
Was sichtbar bleibt
Durch die Verschlüsselung werden Inhalte geschützt, nicht jeder Aspekt der Speicherung. Der Dienst kann Kontozuordnungen, zufällige Objektkennungen, Objektanzahlen, Bytegrößen, Revisionen, Zeitstempel, verschlüsselte Wrapper, Stream-Header und Anforderungsaktivitäten beobachten. Netzwerk- und Betriebsaufzeichnungen können Verbindungsinformationen offenlegen. Dies ist kein Anonymitätssystem und bietet keinen Widerstand gegen Verkehrsanalysen.
Die Transportverschlüsselung schützt Anforderungen während der Übertragung, wenn die Anwendung über HTTPS bereitgestellt wird. Dies ist unabhängig von der clientseitigen Verschlüsselung, die gespeicherte Dateiinhalte beim Dienst verschlüsselt hält.
Wo der Schutz endet
Beim privaten Surfen wird normalerweise der lokale Speicher gelöscht, wenn die private Sitzung endet. Eine Anforderung für dauerhaften Speicher macht eine Inkognito-Sitzung nicht dauerhaft. Synchronisierte Cloud-Kopien bleiben erhalten, aber lokale Muster, nicht synchronisierte Änderungen, zwischengespeicherte Dateien und Safe Exit-Einstellungen können verloren gehen. Eine neue private Sitzung erfordert Kontozugriff und Ihren Wiederherstellungsschlüssel, um ein neues Muster zu registrieren.
Die Anwendung löscht ihre In-Memory-Vault-Schlüsselreferenz und widerruft private Vorschau-URLs, wenn sie gesperrt ist. Es wird automatisch gesperrt, wenn es ausgeblendet wird oder nach fünf Minuten Inaktivität. Native Apps werden auch im Hintergrund gesperrt, entfernen temporäre Vorschauen und löschen eigene Schlüsselpuffer, wenn der Vorgang abgeschlossen ist. Die Browser-, Swift- und JVM-Speicherverwaltung kann nicht garantieren, dass jede Schlüsselkopie oder jeder dekodierte Medienpuffer sofort gelöscht wird.
Malware, eine unsichere Erweiterung, kompromittierter Anwendungscode oder jemand, der einen entsperrten Bildschirm betrachtet, kann Klartext und Geheimnisse erfassen. Die Verschlüsselung kann den Denial-of-Service eines Kontos, gelöschte Cloud-Objekte, Ransomware, den Verlust eines Wiederherstellungsgeheimnisses oder das Zurückhalten von Daten durch einen Dienst nicht verhindern. Bewahren Sie ein separates verschlüsseltes Backup auf und schützen Sie das Gerät selbst.
Revault wurde keinem unabhängigen Sicherheitsaudit unterzogen. Hierbei handelt es sich um Beschreibungen des implementierten kryptografischen Designs, nicht um eine Zertifizierung oder eine Garantie gegen jegliches Eindringen.