Sicherheitsmodell

Der Schutz beginnt vor dem Hochladen

Native Tresore funktionieren lokal ohne ein Revault-Konto. Dateiinhalte, Dateinamen, MIME-Typen, Miniaturansichten, Tresornamen, Ordner, Tags und Favoriten werden auf dem Gerät verschlüsselt. Bei lokaler Verwendung werden keine Tresordateien nach Revault hochgeladen. Native Cloud-Synchronisierung und -Freigabe sind optionale, separate Vorgänge.

Das Modell setzt ein vertrauenswürdiges Betriebssystem, eine installierte App und eine kryptografische Zufallsquelle voraus, wenn ein Tresor erstellt oder entsperrt wird. Jemand, der nur über verschlüsselte Dateien und Schlüsselverpackungen verfügt, kann diese ohne das erforderliche Geheimnis nicht entschlüsseln. Malware oder eine kompromittierte App, die ausgeführt wird, während ein Tresor geöffnet ist, kann Klartext und Schlüssel erfassen.

Unabhängige Schlüssel für jeden Tresor

Jeder Tresor beginnt mit einem zufälligen 256-Bit-Hauptschlüssel AES, der mithilfe der kryptografischen Zufallsquelle des Betriebssystems generiert wird. Die Geste bestimmt diesen Schlüssel nicht direkt. Jeder Tresor verfügt über unabhängiges Hauptschlüsselmaterial, sodass durch die Offenlegung eines Tresorschlüssels kein weiterer Schlüssel entsteht.

Ein Gerätemuster kombiniert seine geordnete Punktfolge mit einem zufälligen 256-Bit-Gerätegeheimnis. Die resultierende Eingabe wird mit NFKC normalisiert und mit einem neuen 128-Bit-Salt und 600.000 Iterationen an PBKDF2-HMAC-SHA-256 übergeben. Der abgeleitete 256-Bit-Schlüssel umschließt den Hauptschlüssel mit AES-256-GCM. Die App speichert kein Klartextmuster oder einen separaten Muster-Fingerabdruck.

Muster verwenden ein 5 × 5-Raster mit sechs bis 25 unterschiedlichen Punkten und müssen für alle Tresore, die auf demselben Gerät registriert sind, eindeutig sein. Ein passendes Muster öffnet nur seinen Tresor; Andere Tresornamen und -inhalte bleiben verborgen. Vorhersehbare Gesten sind immer noch leichter zu erraten. Eine Person, die sowohl ein Gerätegeheimnis als auch den verschlüsselten Wrapper erhält, kann offline versuchen, Muster zu erraten.

Das Öffnen eines nativen Tresors erfordert sein lokales Muster oder einen expliziten Wiederherstellungsablauf, kein Revault-Konto oder Passkey. Für die optionale Cloud-Synchronisierung wird die Autorisierung Apple oder Google der Plattform verwendet, und für Einkäufe im Geschäft wird das Rechnungskonto der Plattform verwendet. Weder eine Cloud-Autorisierung noch ein Kauf liefern einen Tresor-Entschlüsselungsschlüssel.

Gerätespezifischer Schlüsselschutz

Auf iOS wird die Gerätesperre als nicht synchronisierendes Keychain-Element mit WhenUnlockedThisDeviceOnly-Schutz gespeichert. Der Zugriff ist nur bei entsperrtem Gerät möglich und die Migration erfolgt nicht über die Keychain-Synchronisierung. Das gespeicherte Geheimnis ist kein Secure Enclave-Schlüssel.

Auf Android wird die Gerätesperre mit AES-256-GCM unter einem nicht exportierbaren Android Keystore-Schlüssel verschlüsselt, der ein entsperrtes Gerät erfordert. Die verschlüsselte Sperrdatei befindet sich im No-Backup-Verzeichnis der App. Keystore Hardware-Unterstützung hängt vom Gerät ab; Die App verspricht nicht, dass jedes Gerät hardwaregestützte Schlüssel verwendet.

Lokale Entsperrgeheimnisse sind von der nativen Cloud-Synchronisierung und tragbaren Tresorsicherungen ausgeschlossen. Durch den Besitz eines Apple- oder Google-Kontos werden diese Geheimnisse nicht wiederhergestellt und ein wiederhergestellter Tresor wird nicht automatisch entsperrt. Ein neues Gerät muss das unabhängige Wiederherstellungsgeheimnis überprüfen und sein eigenes Muster registrieren.

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

Die native Dateiverschlüsselung verwendet die von Tink beschriebene Streaming-Konstruktion AES-256-GCM-HKDF-SHA-256. iOS verwendet CryptoKit für AES-GCM und HKDF; Android verwendet kryptografische Plattformprimitive. Jeder neue Stream verfügt über einen 40-Byte-Header, der seine Längenmarkierung, einen zufälligen 32-Byte-Salt und ein zufälliges sieben Byte langes 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 nativen Apps verarbeiten Dateien in begrenzten Segmenten von etwa 5 MiB. Segmentzähler, das Endsegment-Flag und erwartete Bytelängen erkennen geänderte, neu angeordnete oder abgeschnittene Segmente. Jedes Segment wird vor der Verwendung authentifiziert und eine private Vorschau wird erst veröffentlicht, nachdem die Entschlüsselung seiner Datei abgeschlossen ist. Bei einem Fehler wird die unvollständige Ausgabe verworfen; Wiederholungsversuche übertragen die vorhandenen verschlüsselten Bytes.

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.

Private Speicherung, Importe und Vorschauen

Verschlüsselte Tresordateien befinden sich im privaten App-Speicher. Dateinamen, MIME-Typen, Ordner, Tags, Favoriten und Miniaturansichten sind authentifizierte verschlüsselte Datensätze. Die Suche und Tag-Filterung erfolgt nach der Entsperrung auf die entschlüsselten Metadaten des aktiven Tresors. Es gibt keinen Klartext-Serversuchindex.

Foto-, Video- und Dateiimporte können vor der Verschlüsselung ein privates temporäres Staging nutzen. Bei der Kameraerfassung im Tresor wird nicht automatisch eine Kopie in der Galerie gespeichert. Beim Importieren von Fotos oder einem anderen Anbieter bleibt das Original dieses Anbieters erhalten. Die optionale Medienoptimierung erfolgt lokal vor der Verschlüsselung und ändert nur neu importierte Medien.

Private Vorschauen erfordern temporären Klartext, während sie geöffnet sind. Die Apps entfernen ihre temporären Vorschauen beim Schließen, Sperren und anschließenden Start; iOS wendet vollständigen Dateischutz auf entschlüsselte Vorschaudateien an. Explizit in eine andere App exportierte Dateien verlassen den Schutz des Tresors. Das vorübergehende Löschen von Dateien ist keine Garantie für eine forensische Löschung.

Optionale native Cloud-Synchronisierung

Die Synchronisierung ist standardmäßig deaktiviert und für jeden Tresor auf jedem Gerät separat aktiviert. iOS speichert verschlüsselte Datensätze und Dateisegmente in der privaten CloudKit-Datenbank des Benutzers in iCloud. Android verwendet das private appDataFolder von Google Drive. Keiner der Transporte erfordert ein Revault-Konto oder lädt native Synchronisierungsdaten in die Web-Cloud von Revault hoch.

Die Cloud empfängt verschlüsselte Metadaten, Dateisegmente und Schlüssel-Wrapper, keinen Klartext-Vault-Hauptschlüssel, ein lokales Gerätegeheimnis oder ein Wiederherstellungsgeheimnis. Ein anderes Gerät auf derselben Plattform benötigt dasselbe native Cloud-Konto und den Vault-Wiederherstellungsschlüssel, um sein eigenes lokales Muster zu registrieren. Die Autorisierung Apple und Google steuert den Zugriff auf die verschlüsselten Datensätze, nicht deren Entschlüsselung.

Wenn Sie die Synchronisierung deaktivieren, werden weitere Übertragungen für diesen Tresor vom aktuellen Gerät gestoppt. Vorhandene verschlüsselte Cloud-Kopien bleiben erhalten. Änderungen und Löschungen bei der Synchronisierung können sich verbreiten und gleichzeitige Bearbeitungen erfordern möglicherweise eine Konfliktprüfung. iCloud und Google Drive sind separate Geschäfte ohne automatische plattformübergreifende Brücke. Verwenden Sie eine verschlüsselte Telefonübertragung, um zwischen iPhone und Android zu wechseln.

Die Wiederherstellung ist ein zweiter Pfad zum gleichen Schlüssel

Revault generiert eine Wiederherstellungsphrase mit 18 unabhängig ausgewählten Wörtern aus einer gebündelten Liste mit 2.048 Wörtern und bietet 198 Bits Zufälligkeit. Die Erstellung bietet keine benutzerdefinierten Phrasen oder Regeneration. Die Phrase leitet unabhängig einen Verpackungsschlüssel mithilfe von PBKDF2-HMAC-SHA-256 und einem frischen Salz ab und umschließt dann den Tresorhauptschlüssel mit AES-256-GCM. Jeder, der über die Phrase und den verschlüsselten Tresor verfügt, kann sie entschlüsseln. Vorhandene benutzerdefinierte Phrasen und hexadezimale Wiederherstellungsschlüssel bleiben mit ihren ursprünglichen Tresoren kompatibel.

Das Wiederherstellungsgeheimnis wird während der Einrichtung angezeigt und nicht im nativen App-Speicher gespeichert oder in den nativen Cloud-Speicher hochgeladen. Bewahren Sie es getrennt von den verschlüsselten Dateien auf. Für die Registrierung eines anderen Geräts ist der verschlüsselte Tresor des ursprünglichen nativen Cloud-Kontos oder ein verschlüsseltes Backup sowie der Wiederherstellungsschlüssel erforderlich. Ein Geheimnis kann fehlende Dateidaten nicht wiederherstellen und Revault verfügt über keinen vom Anbieter gehaltenen Reset-Schlüssel.

Ein portables .qvault-Backup enthält verschlüsselte Schlüssel-Wrapper, ein authentifiziertes verschlüsseltes Inventar und verschlüsselte Dateisegmente. Das Entsperrgeheimnis für das lokale Gerät ist davon ausgenommen. Der Import überprüft das Inventar, die Metadaten und jedes Segment, bevor er in einem Tresor mit neuen Kennungen, Hauptschlüssel, Dateischlüsseln und einem neuen Gerätemuster wiederhergestellt wird. Speichern Sie den neuen Wiederherstellungsschlüssel nach der Wiederherstellung.

Neue Wiederherstellungsphrasen bewahren die Groß-/Kleinschreibung, normalisieren Unicode mit NFKC und reduzieren zusätzliche Leerzeichen. Ältere Hexadezimalschlüssel werden weiterhin unterstützt. Sie können die Wiederherstellungsphrase eines Tresors in den Einstellungen ersetzen, nachdem Sie die neue Phrase gespeichert haben. Dies ersetzt den aktuellen Wiederherstellungs-Wrapper; Alte Backups und Geräte, die nicht synchronisiert wurden, können immer noch den alten Wrapper enthalten. Durch das Ändern eines Musters oder einer Wiederherstellungsphrase wird weder der Tresor-Hauptschlüssel rotiert noch Kopien widerrufen. Wenn das Schlüsselmaterial gefährdet ist, verschieben Sie die Dateien in einen neuen Tresor mit neuen Schlüsseln.

Verschlüsselte Telefon-zu-Telefon-Migration

Durch die Telefonübertragung wird eine tragbare, verschlüsselte Kopie mit neuen Tresor-IDs, Hauptschlüssel, Dateischlüsseln und Stream-Headern erstellt. Sein unabhängiges Übertragungsgeheimnis kann den Quelltresor nicht entsperren, und das Quellwiederherstellungsgeheimnis und das Geräteentsperrgeheimnis sind nicht enthalten. Das verschlüsselte Paket und das Übertragungsgeheimnis müssen separat geliefert werden.

Die empfangende App authentifiziert das Paket und seine Dateisegmente und stellt es dann in einem neuen Tresor mit einem neuen lokalen Muster und Wiederherstellungsschlüssel wieder her. Dies funktioniert zwischen iOS und Android, ohne deren Cloud-Konten zu überbrücken. Das Original verbleibt auf dem Altgerät; Bestätigen Sie den wiederhergestellten Inhalt und speichern Sie den neuen Wiederherstellungsschlüssel, bevor Sie ihn löschen.

Sperren und Sitzungsbereinigung

Die mobilen Apps werden standardmäßig sofort im Hintergrund und nach 60 Sekunden Inaktivität gesperrt. Für jeden Tresor können 30 Sekunden, 1 Minute, 2 Minuten, 5 Minuten oder 10 Minuten ausgewählt werden. Ein gemeinsam genutzter Tresor verwendet den Standardwert von 60 Sekunden. Beim Beenden kehren Sie zum Musterbildschirm zurück und beenden die entschlüsselte Sitzung.

Durch das Sperren wird die Sitzungsarbeit abgebrochen, entschlüsselte Metadaten und Suchstatus gelöscht, Vorschauen geschlossen, temporäre Dateien entfernt und eigene Schlüsselpuffer überschrieben, bevor sie freigegeben werden. Temporäre Ableitungsschlüssel werden nach der Verwendung ebenfalls gelöscht. Swift und JVM Speicherverwaltung, kryptografische Bibliotheken und Mediendecoder können Kopien erstellen; Eine sofortige Löschung jeder Kopie kann nicht garantiert werden.

iOS deckt App-Switcher-Snapshots mit einem Datenschutzschild ab. Android verwendet das Secure-Window-Flag, um Screenshots und Vorschauen aktueller Apps einzuschränken. Diese Plattformschutzmaßnahmen verhindern nicht, dass jemand einen entsperrten Bildschirm fotografiert, und sie ziehen keine Dateien zurück, die zuvor in eine andere App exportiert wurden.

Revault Cloud

Revault Cloud ist ein optionaler Pro-Speicheranbieter für die plattformübergreifende Synchronisierung. Verschlüsselte Segmente und verschlüsselte Dateimetadaten werden mit einer pseudonymen Abrechnungsinstallation verknüpft. Der Dienst kann Speicherkennungen, Größen, Prüfsummen, Revisionen und Übertragungsaktivitäten beobachten, erhält jedoch keinen unverpackten Tresorschlüssel oder Wiederherstellungssatz. Ein separater Zufallsverbindungscode autorisiert den Speicherzugriff; Für das Anschließen eines anderen Geräts ist ebenfalls die Wiederherstellungsphrase erforderlich. Vorhandene Cloud-Daten bleiben nach Ablauf von Pro für die Wiederherstellung lesbar.

Unabhängige Schlüssel für jede Aktie

Bei einer nativen Freigabe handelt es sich um eine Momentaufnahme ausgewählter Dateien, nicht um Zugriff auf den persönlichen Tresor des Besitzers. Standardmäßig leitet die App die ausgewählten Dateiversionsschlüssel ab und umschließt sie mit AES-256-GCM unter einem neuen Freigabehauptschlüssel. Es verwendet die verschlüsselten Dateibytes wieder und verschlüsselt gleichzeitig Metadaten und Miniaturansichten für die Freigabe neu. Ausgenommen sind Quelltresorschlüssel, das Wiederherstellungsgeheimnis, die Ordnerstruktur, Tags und Favoriten.

Die Freigabe verfügt über eine eigene, unabhängig generierte 18-Wörter-Entschlüsselungsphrase und einen Wiederherstellungs-Wrapper. Der Absender gibt dieses Geheimnis vertraulich weiter, getrennt vom Einladungslink. Der Server empfängt verschlüsselte Daten, niemals den Klartext-Freigabeschlüssel oder das Entschlüsselungsgeheimnis. Der Empfänger kann keine nicht freigegebenen Dateischlüssel oder den Hauptschlüssel des Quelltresors aus den ausgewählten Dateischlüsseln ableiten.

Die optionale Einstellung „Extra-Isolation“ verschlüsselt Dateiinhalte mit neuen Schlüsseln und Stream-Headern neu. Die Standardeinstellung ist schneller, da vermieden wird, dass jede Datei neu geschrieben wird. Wiederholter Chiffretext kann Kopien derselben Dateiversion korrelieren. Beide Modi erstellen einen separaten Snapshot und keiner kann Chiffretext und Schlüssel zurückziehen, die bereits von einem Empfänger gespeichert wurden.

Native Sharing-Transporte und Zugriffskontrollen

Am iOS platziert eine private, schreibgeschützte CloudKit-Einladung den verschlüsselten Snapshot in einer separaten Freigabedatensatzhierarchie außerhalb der persönlichen Synchronisierungszone. Apple steuert den Einladungszugriff; Der Empfänger benötigt weiterhin das separate Entschlüsselungsgeheimnis. CloudKit Einladungen erzwingen nicht die Anzahl der Zugriffssitzungen, den festen Ablauf oder den Zerstörungstimer des Servers. Der Eigentümer kann den zukünftigen CloudKit-Zugriff stoppen.

Plattformübergreifende Freigaben laden verschlüsselte Teile zum Freigabedienst von Revault hoch. Unabhängige zufällige 256-Bit-Lese- und Verwaltungsfunktionen werden als SHA-256 Hashes gespeichert. Der Website-Link trägt in seinem Fragment die Lesefähigkeit, nicht das Entschlüsselungsgeheimnis. Beim Öffnen wird ein Deep-Link zu einem gemeinsamen Tresor erstellt und Sie werden zur Eingabe des Geheimnisses des Absenders aufgefordert. Es ist kein persönliches Muster oder ein vorhandener Tresor erforderlich. Persönliche Tresore bleiben verschlossen.

Kontrollierte Serverfreigaben erzwingen die maximalen Zugriffssitzungen des Absenders, einen festen Ablauf innerhalb von 30 Tagen, einen Widerruf und eine optionale Exporterlaubnis. Eine Sitzung wird atomar vergeben und dauert maximal 15 Minuten, begrenzt durch die Fristen der Freigabe. Ein Zugriff zählt, wenn die Sitzung gewährt wird, auch wenn der Download oder die Entschlüsselung fehlschlägt. Der Viewer prüft den laufenden Zugriff und schließt bei Ablauf der Frist.

SHA-256 Prüfsummen überprüfen übertragene Teile, während authentifizierte Verschlüsselung deren Inhalte überprüft. Wenn der Export zulässig ist, kann der Betrachter eine verschlüsselte .qvault-Kopie speichern, die mit dem Freigabegeheimnis geöffnet wird. Durch das Deaktivieren des Exports wird diese Anwendungsaktion entfernt. Es kann kryptografisch nicht verhindern, dass Screenshots oder ein geänderter Client Klartext behalten. Durch das Löschen einer Quelldatei wird eine unabhängig erstellte Freigabe nicht widerrufen.

Eine Frist nach dem ersten Zugriff

Ein Absender kann einen separaten Zerstörungstimer aktivieren. Es startet atomar, wenn die erste Serverzugriffssitzung gewährt wird, auch wenn die Übertragung oder Entschlüsselung später fehlschlägt. Für jede spätere Sitzung gilt dieselbe Frist. Durch erneutes Öffnen wird es nie zurückgesetzt. Es gilt der früheste der folgenden Werte: festes Ablaufdatum, Vernichtungszeitpunkt und Sitzungsablaufdatum. Bei Ablauf der Frist verweigert der Dienst weitere Lesevorgänge und stellt Chiffretext zum Löschen in die Warteschlange, während der native Viewer seine Freigabeschlüssel und temporären Dateien schließt und freigibt. Die Bereinigung erfolgt asynchron und kann keine Screenshots, die beibehaltenen Daten eines geänderten Clients oder zuvor exportierte Kopien löschen.

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.

Safe Exit entfernt den lokalen Zugriff

Ein Tresor auf einem Gerät kann für Safe Exit bestimmt werden. Durch die Eingabe seines Musters wird es normal geöffnet, während die anderen lokalen Tresordatensätze, verschlüsselten Blöcke, Material zum Entsperren des Geräts und Änderungen in der Warteschlange entfernt werden. Die App führt eine permanente lokale Zulassungsliste, sodass die Synchronisierung ausgeschlossene Tresore nicht stillschweigend neu füllen kann. Bereits verschlüsselte Übertragungen im laufenden Betrieb werden möglicherweise noch abgeschlossen.

Es bleiben native Cloud-Kopien und Kopien auf anderen Geräten erhalten. Für die explizite Wiederherstellung ist der Wiederherstellungsschlüssel des ausgeschlossenen Tresors erforderlich, bevor ein neues lokales Muster registriert wird. Ein reiner Offline-Tresor ohne separate Sicherung kann verloren gehen. Diese Einstellung gilt für die aktuelle Installation, nicht für jedes Gerät, das dasselbe Cloud-Konto verwendet.

Safe Exit garantiert keine forensische Löschung oder Verschleierung. Flash-Speicher, Betriebssystem-Caches, Backups und frühere Exporte können Spuren hinterlassen. Durch das Entfernen von App-Daten oder eine Neuinstallation kann die lokale Isolationsgrenze entfernt werden. Cloud-Datensätze können dann wieder über das native Cloud-Konto erkannt werden. Nur das Wiederherstellungsgeheimnis kann diese Datensätze entsperren.

Was sichtbar bleibt

Die Verschlüsselung verbirgt Inhalte, nicht alle Betriebsinformationen. Lokale Datensätze und Cloud-Anbieter können Identifikatoren, Datensatzbeziehungen, Objektanzahlen, Größen, Revisionen, Zeitstempel, verschlüsselte Schlüsselverpackungen und Stream-Header beobachten. Bezeichner verwenden UUIDv7 und enthalten Informationen zum Erstellungszeitpunkt; es sind keine Geheimnisse. Apple oder Google können native Synchronisierungsaktivitäten mit dem Plattformkonto verknüpfen.

Der kontrollierte Freigabedienst von Revault kann verschlüsselte Paketgrößen, Teilprüfsummen, Ablaufeinstellungen, Anzahl der Zugriffssitzungen und optionale Sitzungszeitstempel überwachen, jedoch nicht das separat bereitgestellte Entschlüsselungsgeheimnis. Durch die Weitergabe von CloudKit werden Einladungs- und Teilnehmerinformationen an Apple weitergegeben. Netzwerk- und Betriebsaufzeichnungen können Verbindungsinformationen offenlegen. Revault bietet weder Anonymität noch Widerstand gegen Verkehrsanalysen.

HTTPS schützt Netzwerkanfragen während der Übertragung. Die authentifizierte Verschlüsselung auf dem Gerät schützt die lokal und in der Cloud gespeicherten Tresorinhalte separat. Weder Transportverschlüsselung noch Geheimtext verheimlichen alle Informationen darüber, wann, wo oder wie viele Daten übertragen werden.

Wo der Schutz endet

Ein entsperrter Tresor stellt seiner App-Sitzung zwangsläufig entschlüsselte Informationen zur Verfügung. Malware, ein kompromittiertes Betriebssystem oder eine kompromittierte App, jemand, der den Bildschirm betrachtet, oder ein nicht vertrauenswürdiger Empfänger können es erfassen. Die gerätespezifische Schlüsselspeicherung stellt eine zusätzliche Grenze dar und ist keine Garantie gegen ein vollständig kompromittiertes Gerät. Ein vorhersehbares Muster ist unsicher, sobald sein lokales Geheimnis kompromittiert wird.

Die Verschlüsselung verhindert nicht das Löschen der Cloud, Ransomware, den Verlust eines Wiederherstellungsgeheimnisses, das Zurückhalten von Datensätzen durch einen Anbieter oder das Zurücksetzen eines gesamten zuvor gültigen verschlüsselten Zustands. Bewahren Sie unabhängige verschlüsselte Backups auf und überprüfen Sie die Wiederherstellung, bevor Sie ein altes Gerät entfernen. Der Widerruf kann keine Screenshots, Exporte oder Kopien widerrufen, die bereits von einer anderen Person aufbewahrt wurden.

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.

Vorhandene Browser-Tresore

Diese Referenz beschreibt die nativen Apps. Bestehende Browser-Tresore verfügen über ein separates Konto-, Gerätespeicher- und Web-Cloud-Modell. Browserspezifische S3-Uploads und Browser-Freigabelinks sind keine native Cloud-Synchronisierung. Mit dem Browserkonto werden Sie nicht bei den mobilen Apps angemeldet. Verwenden Sie ein verschlüsseltes Backup und seinen Wiederherstellungsschlüssel, um vorhandene Browserdaten in einen nativen Tresor zu verschieben.