Ochrona rozpoczyna się przed przesłaniem
Skarbce natywne działają lokalnie bez konta Revault. Zawartość plików, nazwy plików, typy MIME, miniatury, nazwy skarbców, foldery, znaczniki i ulubione są szyfrowane na urządzeniu. Do użytku lokalnego nie przesyłane są pliki repozytorium do Revault. Natywna synchronizacja i udostępnianie w chmurze to opcjonalne, osobne operacje.
Model zakłada godny zaufania system operacyjny, zainstalowaną aplikację i losowe źródło kryptograficzne podczas tworzenia lub otwierania skarbca. Ktoś, kto ma tylko zaszyfrowane pliki i opakowania kluczy, nie może ich odszyfrować bez wymaganego sekretu. Złośliwe oprogramowanie lub zainfekowana aplikacja działająca, gdy skarbiec jest otwarty, może przechwytywać zwykły tekst i klucze.
Niezależne klucze do każdego skarbca
Każdy skarbiec zaczyna się od losowego 256-bitowego klucza głównego AES, wygenerowanego przy użyciu losowego źródła kryptograficznego systemu operacyjnego. Gest nie determinuje bezpośrednio tego klucza. Każdy skarbiec zawiera niezależny materiał klucza głównego, zatem ujawnienie jednego klucza skarbca nie powoduje powstania innego.
Wzorzec urządzenia łączy uporządkowaną sekwencję kropek z losowym 256-bitowym kluczem urządzenia. Wynikowe dane wejściowe są normalizowane za pomocą NFKC i przekazywane do PBKDF2-HMAC-SHA-256 ze świeżą 128-bitową solą i 600 000 iteracji. Wyprowadzony klucz 256-bitowy otacza klucz główny za pomocą AES-256-GCM. Aplikacja nie zapisuje wzoru w postaci zwykłego tekstu ani osobnego odcisku palca wzoru.
Wzory wykorzystują siatkę 5 × 5 z sześcioma do 25 różnymi kropkami i muszą być unikalne w przypadku skarbców zarejestrowanych na tym samym urządzeniu. Pasujący wzór otwiera tylko swój skarbiec; inne nazwy i zawartość skarbca pozostają ukryte. Przewidywalne gesty wciąż łatwiej odgadnąć. Osoba, która uzyska zarówno klucz tajny urządzenia, jak i jego zaszyfrowaną otokę, może podjąć próbę odgadnięcia wzorców w trybie offline.
Otwarcie skarbca natywnego wymaga jego lokalnego wzorca lub jawnego przepływu odzyskiwania, a nie konta Revault lub klucza dostępu. Opcjonalna synchronizacja w chmurze korzysta z autoryzacji platformy Apple lub Google, a zakupy w sklepie korzystają z konta rozliczeniowego platformy. Ani autoryzacja w chmurze, ani zakup nie dostarczają klucza deszyfrującego skarbiec.
| Zamiar | Budowa |
|---|---|
| Klucz główny skarbca | Losowy 256-bitowy klucz AES |
| Opakowanie na klucze | PBKDF2-HMAC-SHA-256 · 600 000 iteracji · 128-bitowa sól → AES-256-GCM |
| Metadane i miniatury | AES-256-GCM · Losowa 96-bitowa wartość jednorazowa · 128-bitowy znacznik uwierzytelniający |
| Wyprowadzenie klucza pliku | HKDF-SHA-256 · Losowa 256-bitowa sól na plik · 256-bitowe wyjście AES |
| Sekret odzyskiwania | Wygenerowano: 18 losowych słów (198 bitów); niestandardowy: co najmniej 6 odrębnych słów i 32–512 znaków |
Ochrona kluczy tylko urządzenia
W iOS blokada urządzenia jest przechowywana jako niezsynchronizowany element Keychain przy użyciu zabezpieczenia WhenUnlockedThisDeviceOnly. Jest dostępny tylko wtedy, gdy urządzenie jest odblokowane i nie podlega migracji poprzez Keychain synchronizację. Przechowywany sekret nie jest kluczem Secure Enclave.
W dniu Android blokada urządzenia jest szyfrowana przy użyciu AES-256-GCM pod nieeksportowalnym kluczem Android Keystore, który wymaga odblokowanego urządzenia. Zaszyfrowany plik blokady znajduje się w katalogu aplikacji, w którym nie ma kopii zapasowej. Keystore wsparcie sprzętowe zależy od urządzenia; aplikacja nie obiecuje, że każde urządzenie korzysta z kluczy sprzętowych.
Lokalne klucze odblokowania są wykluczone z natywnej synchronizacji w chmurze i kopii zapasowych skarbca przenośnego. Posiadanie konta Apple lub Google nie powoduje odtworzenia tych sekretów ani automatycznego odblokowania przywróconego skarbca. Nowe urządzenie musi zweryfikować niezależny sekret odzyskiwania i zarejestrować własny wzorzec.
Poufność i wykrywanie manipulacji
Metadane skarbca, metadane plików, miniatury i klucze opakowane korzystają z AES-256-GCM ze 128-bitowymi znacznikami uwierzytelniania. Każde niezależne szyfrowanie wykorzystuje nową losową 96-bitową wartość jednorazową. Deszyfrowanie weryfikuje znacznik przed zwróceniem zwykłego tekstu; zmodyfikowany tekst zaszyfrowany lub zły klucz powodują niepowodzenie uwierzytelnienia.
Dodatkowe uwierzytelnione dane wiążą każdy zaszyfrowany obiekt z jego wersją formatu, identyfikatorem skarbca, identyfikatorem obiektu i przeznaczeniem. Na przykład miniatura i rekord metadanych pliku korzystają z różnych kontekstów. Przeniesienie zaszyfrowanego obiektu do innego skarbca lub zastąpienie go innym obiektem powoduje zmianę uwierzytelnionego kontekstu i weryfikację kończy się niepowodzeniem.
Uwierzytelniony kontekst nie ukrywa identyfikatorów i nie świadczy o świeżości. Prawidłowy starszy rekord może nadal mieć prawidłowy znacznik. Sprawdzanie wersji aplikacji wykrywa zwykłe, równoczesne aktualizacje, ale nie jest to ochrona kryptograficzna przed złośliwą usługą odtwarzającą całkowicie starszy stan.
Duże pliki korzystają z uwierzytelnionych segmentów
Natywne szyfrowanie plików wykorzystuje konstrukcję przesyłania strumieniowego AES-256-GCM-HKDF-SHA-256 opisaną przez Tinka. iOS używa CryptoKit dla AES-GCM i HKDF; Android używa prymitywów kryptograficznych platformy. Każdy nowy strumień ma 40-bajtowy nagłówek zawierający znacznik długości, losową 32-bajtową sól i losowy siedmiobajtowy prefiks nonce.
HKDF uzyskuje oddzielny klucz szyfrowania plików z głównego klucza skarbca. Jego kontekst obejmuje identyfikatory skarbca i pliku, długość bajtów zwykłego tekstu i skonfigurowany rozmiar segmentu. 12-bajtowa wartość nonce każdego segmentu łączy losowy prefiks, czterobajtowy licznik segmentu i flagę ostatniego segmentu. Segmenty zawierają 128-bitowe znaczniki GCM.
Aplikacje natywne przetwarzają pliki w ograniczonych segmentach o wielkości około 5 MiB. Liczniki segmentów, flaga ostatniego segmentu i oczekiwana długość bajtów wykrywają segmenty zmienione, zmienione lub obcięte. Każdy segment jest uwierzytelniany przed użyciem, a prywatny podgląd publikowany jest dopiero po zakończeniu odszyfrowywania jego pliku. Niekompletne dane wyjściowe są odrzucane w przypadku niepowodzenia; ponowne próby przesłania istniejących zaszyfrowanych bajtów.
Konstrukcja jest zgodna z Specyfikacja przesyłania strumieniowego Tink AES-GCM-HKDF. Wdrożenie i konfiguracja segmentu Revault nie zostały poddane niezależnemu audytowi ani certyfikacji przez Tink.
Prywatna pamięć masowa, importy i podglądy
Zaszyfrowane pliki skarbca znajdują się w prywatnej pamięci aplikacji. Nazwy plików, typy MIME, foldery, znaczniki, ulubione i miniatury to uwierzytelnione, zaszyfrowane rekordy. Po odblokowaniu wyszukiwanie i filtrowanie tagów działają na odszyfrowanych metadanych aktywnego skarbca; nie ma indeksu wyszukiwania serwera w postaci zwykłego tekstu.
Import zdjęć, filmów i plików może odbywać się przy użyciu tymczasowego tymczasowego przechowywania danych przed szyfrowaniem. Przechwycenie kamery w skarbcu nie powoduje automatycznego zapisania kopii w galerii. Importowanie ze Zdjęć lub innego dostawcy pozostawia oryginał tego dostawcy w stanie nienaruszonym. Opcjonalna optymalizacja multimediów odbywa się lokalnie przed szyfrowaniem i zmienia tylko nowo zaimportowane multimedia.
Prywatne podglądy wymagają tymczasowego tekstu jawnego, gdy są otwarte. Aplikacje usuwają swoje tymczasowe podglądy po zamknięciu, zablokowaniu i późniejszym uruchomieniu; iOS stosuje pełną ochronę plików do odszyfrowanych plików podglądu. Pliki jawnie wyeksportowane do innej aplikacji opuszczają ochronę skarbca. Usunięcie pliku tymczasowego nie gwarantuje usunięcia danych na potrzeby medycyny sądowej.
Opcjonalna natywna synchronizacja w chmurze
Synchronizacja jest domyślnie wyłączona i włączona oddzielnie dla każdego skarbca na każdym urządzeniu. iOS przechowuje zaszyfrowane rekordy i segmenty plików w prywatnej bazie danych użytkownika CloudKit w iCloud. Android korzysta z prywatnego appDataFolder użytkownika Google Drive. Żaden transport nie wymaga konta Revault ani nie przesyła natywnych danych synchronizacji do chmury internetowej Revault.
Chmura otrzymuje zaszyfrowane metadane, segmenty plików i opakowania kluczy, a nie klucz główny skarbca w postaci zwykłego tekstu, klucz tajny urządzenia lokalnego ani sekret odzyskiwania. Inne urządzenie na tej samej platformie potrzebuje tego samego natywnego konta w chmurze i klucza odzyskiwania skarbca, aby zarejestrować swój własny wzorzec lokalny. Autoryzacja Apple i Google kontroluje dostęp do zaszyfrowanych zapisów, a nie ich odszyfrowanie.
Wyłączenie synchronizacji zatrzymuje dalsze transfery do tego skarbca z bieżącego urządzenia; istniejące zaszyfrowane kopie w chmurze pozostają. Zmiany i usunięcia synchronizacji mogą się rozprzestrzeniać, a jednoczesne zmiany mogą wymagać sprawdzenia konfliktów. iCloud i Google Drive to oddzielne sklepy, bez automatycznego mostu międzyplatformowego. Użyj szyfrowanego transferu telefonu, aby poruszać się między iPhonem a Android.
Odzyskiwanie to druga ścieżka do tego samego klucza
Revault generuje jedną frazę odzyskiwania zawierającą 18 niezależnie wybranych słów z dołączonej listy 2048 słów, zapewniając 198 bitów losowości. Kreacja nie oferuje niestandardowych fraz ani regeneracji. Fraza niezależnie wyprowadza klucz zawijający przy użyciu PBKDF2-HMAC-SHA-256 i świeżej soli, a następnie owija klucz główny skarbca za pomocą AES-256-GCM. Każdy, kto ma frazę i zaszyfrowany skarbiec, może ją odszyfrować. Istniejące niestandardowe frazy i szesnastkowe klucze odzyskiwania pozostają kompatybilne z ich oryginalnymi skarbcami.
Klucz tajny odzyskiwania jest wyświetlany podczas konfiguracji i nie jest utrwalany w natywnej pamięci aplikacji ani przesyłany do natywnej pamięci w chmurze. Trzymaj go oddzielnie od zaszyfrowanych plików. Rejestracja innego urządzenia wymaga zaszyfrowanego skarbca z oryginalnego natywnego konta w chmurze lub zaszyfrowanej kopii zapasowej oraz klucza odzyskiwania. Sekret nie może przywrócić brakujących danych pliku, a Revault nie ma klucza resetowania przechowywanego przez dostawcę.
Przenośna kopia zapasowa .qvault zawiera zaszyfrowane opakowania kluczy, uwierzytelniony zaszyfrowany spis i zaszyfrowane segmenty plików. Wyklucza sekret odblokowania urządzenia lokalnego. Import weryfikuje zasoby, metadane i każdy segment przed przywróceniem do skarbca ze świeżymi identyfikatorami, kluczem głównym, kluczami plików i nowym wzorcem urządzenia. Zapisz nowy klucz odzyskiwania po przywróceniu.
Nowe frazy odzyskiwania zachowują wielkość liter, normalizują Unicode za pomocą NFKC i zwijają dodatkowe białe znaki. Starsze klucze szesnastkowe są nadal obsługiwane. Możesz zastąpić frazę odzyskiwania skarbca w jej ustawieniach po zapisaniu nowej frazy. Zastępuje to obecne opakowanie odzyskiwania; stare kopie zapasowe i urządzenia, które nie zostały zsynchronizowane, mogą nadal zawierać stare opakowanie. Zmiana wzorca lub frazy odzyskiwania nie powoduje rotacji klucza głównego skarbca ani nie unieważnia kopii. Jeśli kluczowy materiał zostanie naruszony, przenieś pliki do nowego skarbca ze świeżymi kluczami.
Szyfrowana migracja z telefonu na telefon
Transfer telefoniczny tworzy przenośną zaszyfrowaną kopię ze świeżymi identyfikatorami skarbca, kluczem głównym, kluczami plików i nagłówkami strumieni. Jego niezależny sekret transferu nie może odblokować skarbca źródłowego, a sekret odzyskiwania źródła i sekret odblokowania urządzenia nie są uwzględnione. Zaszyfrowana paczka i sekret przelewu muszą zostać dostarczone osobno.
Aplikacja odbierająca uwierzytelnia pakiet i jego segmenty plików, a następnie przywraca dane do nowego skarbca przy użyciu nowego lokalnego wzorca i klucza odzyskiwania. Działa to między iOS a Android bez łączenia kont w chmurze. Oryginał pozostaje na starym urządzeniu; potwierdź przywróconą zawartość i zapisz nowy klucz odzyskiwania przed jego usunięciem.
Blokowanie i czyszczenie sesji
Domyślnie aplikacje mobilne blokują się natychmiast po uruchomieniu w tle i po 60 sekundach bezczynności. Każdy skarbiec może wybrać 30 sekund, 1 minutę, 2 minuty, 5 minut lub 10 minut. Skarbiec udostępniony korzysta z domyślnego czasu 60 sekund. Wyjście powoduje powrót do ekranu wzorca i zakończenie odszyfrowanej sesji.
Blokowanie anuluje pracę sesji, czyści odszyfrowane metadane i stan wyszukiwania, zamyka podglądy, usuwa pliki tymczasowe i nadpisuje posiadane bufory kluczy przed ich zwolnieniem. Tymczasowe klucze wyprowadzania są również usuwane po użyciu. Swift i JVM zarządzanie pamięcią, biblioteki kryptograficzne i dekodery multimediów mogą tworzyć kopie; nie można zagwarantować natychmiastowego usunięcia każdej kopii.
iOS obejmuje migawki przełącznika aplikacji z ochroną prywatności. Android używa flagi bezpiecznego okna, aby ograniczyć zrzuty ekranu i podglądy najnowszych aplikacji. Te zabezpieczenia platformy nie zapobiegają fotografowaniu odblokowanego ekranu i nie cofają plików wyeksportowanych wcześniej do innej aplikacji.
Revault Cloud
Revault Cloud to opcjonalny dostawca pamięci masowej Pro do synchronizacji między platformami. Zaszyfrowane segmenty i zaszyfrowane metadane plików są powiązane z pseudonimową instalacją rozliczeniową. Usługa może obserwować identyfikatory, rozmiary, sumy kontrolne, wersje i działania związane z transferem, ale nie otrzymuje rozpakowanego klucza skarbca ani frazy odzyskiwania. Oddzielny losowy kod połączenia upoważnia do dostępu do pamięci; podłączenie innego urządzenia również wymaga frazy odzyskiwania. Istniejące dane w chmurze będą nadal możliwe do odzyskania po wygaśnięciu wersji Pro.
Natywne udostępnianie transportów i kontrola dostępu
W dniu iOS prywatne zaproszenie tylko do odczytu CloudKit umieszcza zaszyfrowaną migawkę w osobnej hierarchii rekordów udostępniania, poza osobistą strefą synchronizacji. Apple kontroluje dostęp do zaproszeń; odbiorca nadal potrzebuje osobnego sekretu deszyfrowania. CloudKit zaproszenia nie wymuszają licznika sesji dostępu serwera, ustalonego czasu wygaśnięcia ani licznika czasu zniszczenia. Właściciel może zatrzymać przyszły CloudKit dostęp.
Udostępnienia międzyplatformowe przesyłają zaszyfrowane części do usługi udostępniania Revault. Niezależne, losowe 256-bitowe możliwości odczytu i zarządzania są przechowywane jako skróty SHA-256. Link do strony internetowej zawiera w swoim fragmencie możliwość odczytu, a nie sekret deszyfrowania. Otwarcie powoduje głębokie odniesienie do udostępnionego skarbca i monit o podanie sekretu nadawcy; nie jest wymagany żaden wzór osobisty ani istniejący skarbiec. Skarbce osobiste pozostają zamknięte.
Kontrolowane udziały serwerów wymuszają maksymalny dostęp do sesji nadawcy, stałe wygaśnięcie w ciągu 30 dni, unieważnienie i opcjonalne zezwolenie na eksport. Sesja udzielana jest atomowo i trwa maksymalnie 15 minut, ograniczona terminami akcji. Dostęp liczy się w momencie przyznania sesji, nawet jeśli pobieranie lub deszyfrowanie nie powiedzie się. Przeglądarka sprawdza bieżący dostęp i zamyka w wyznaczonym terminie.
Sumy kontrolne SHA-256 weryfikują przesyłane części, natomiast uwierzytelnione szyfrowanie weryfikuje ich zawartość. Gdy eksport jest dozwolony, przeglądarka może zapisać zaszyfrowaną .qvault kopię, która otwiera się z kluczem udziału. Wyłączenie eksportu usuwa tę akcję aplikacji; nie może kryptograficznie uniemożliwić zrzutom ekranu lub zmodyfikowanemu klientowi zachowania zwykłego tekstu. Usunięcie pliku źródłowego nie unieważnia niezależnie utworzonego udziału.
Opcjonalna aktywność skarbca
Natywne dzienniki inspekcji są domyślnie wyłączone i konfigurowane dla każdego magazynu na każdym urządzeniu. Za pomocą klucza głównego skarbca i dedykowanego uwierzytelnionego kontekstu szyfrowanych jest 500 ostatnich zdarzeń lokalnych. Wykluczają klucze, wzorce, zawartość plików i dane innych skarbców, nie synchronizują się i można je wyczyścić lub wyłączyć. Nie są one dowodem odpornym na manipulacje. Nieudane odblokowania nie są przypisywane do skarbca.
Nowe kontrolowane udziały utworzone z włączoną funkcją rejestrowania zachowują do 100 znaczników czasu sesji dostępu w usłudze udostępniania. Tylko zdolność zarządzania może je odzyskać; dziennik nie zawiera tożsamości odbiorcy ani tajemnicy deszyfrowania. Wyłączenie lokalnego rejestrowania ma wpływ na przyszłe udziały. Istniejące dzienniki udziałów zachowują swoje oryginalne ustawienia aż do odwołania lub wygaśnięcia i oczyszczenia.
Opcjonalne zaszyfrowane zdjęcia włamań
Właściciele mogą włączyć alerty o włamaniach oddzielnie dla każdego skarbca na każdym urządzeniu. Po trzech niezrównanych wzorach aplikacja działająca na pierwszym planie może zrobić zdjęcie przednim aparatem, pod warunkiem uzyskania pozwolenia, dostępności aparatu i jednominutowego czasu odnowienia. Wskaźniki kamer systemowych pozostają widoczne. Dziesięć ostatnich alertów jest przechowywanych lokalnie i nigdy nie jest dodawanych do Zdjęć ani przesyłanych. Niedopasowany wzorzec nie identyfikuje skarbca docelowego, więc każdy skarbiec, do którego włączono opcję, otrzymuje oddzielnie zaszyfrowany rekord próby użycia urządzenia.
Dedykowany klucz publiczny RSA-3072 otacza nowy 256-bitowy klucz AES-GCM dla każdego alertu przy użyciu OAEP z SHA-256 i MGF1-SHA-256. Umożliwia to szyfrowanie, gdy skarbiec jest zamknięty. Odpowiedni klucz prywatny jest sam w sobie szyfrowany pod kluczem głównym skarbca z dedykowanym uwierzytelnionym kontekstem. Tylko odblokowanie tego skarbca może odszyfrować zawarte w nim zdjęcia. Alerty pojawiają się w widoku audytu niezależnie od zwykłego rejestrowania aktywności i można je wyczyścić w ustawieniach alertów o włamaniach. Nie są one dowodem odpornym na manipulacje.
Safe Exit usuwa dostęp lokalny
Jeden skarbiec na urządzeniu można wyznaczyć dla Safe Exit. Wprowadzenie jego wzorca otwiera go normalnie, jednocześnie usuwając inne rekordy lokalnego skarbca, zaszyfrowane fragmenty, materiały odblokowujące urządzenie i zmiany z kolejki. Aplikacja utrzymuje stałą lokalną listę dozwolonych, więc synchronizacja nie może po cichu ponownie zapełnić wykluczonych skarbców. Szyfrowane transfery już w trakcie lotu mogą nadal zostać zakończone.
Natywne kopie w chmurze i kopie na innych urządzeniach pozostają. Jawne odzyskiwanie wymaga klucza odzyskiwania wykluczonego skarbca przed zarejestrowaniem nowego wzorca lokalnego. Skarbiec działający wyłącznie w trybie offline bez oddzielnej kopii zapasowej może zostać utracony. To ustawienie dotyczy bieżącej instalacji, a nie każdego urządzenia korzystającego z tego samego konta w chmurze.
Safe Exit nie gwarantuje usunięcia lub ukrycia danych w celach kryminalistycznych. Pamięć flash, pamięci podręczne systemu operacyjnego, kopie zapasowe i wcześniejsze eksporty mogą zachować ślady. Usunięcie danych aplikacji lub ponowna instalacja może usunąć lokalną granicę izolacji; rekordy w chmurze można następnie ponownie odkryć za pośrednictwem natywnego konta w chmurze. Tylko sekret odzyskiwania może odblokować te rekordy.
Co pozostaje widoczne
Szyfrowanie ukrywa zawartość, a nie wszystkie informacje operacyjne. Lokalne rekordy i dostawcy usług w chmurze mogą obserwować identyfikatory, powiązania rekordów, liczbę obiektów, rozmiary, wersje, znaczniki czasu, zaszyfrowane opakowania kluczy i nagłówki strumieni. Identyfikatory wykorzystują UUIDv7 i zawierają informacje o czasie utworzenia; nie są to tajemnice. Apple lub Google mogą powiązać aktywność synchronizacji natywnej z kontem platformy.
Usługa kontrolowanego udostępniania Revault może obserwować rozmiary zaszyfrowanych pakietów, częściowe sumy kontrolne, ustawienia wygaśnięcia, liczbę sesji dostępu i opcjonalne znaczniki czasu sesji, ale nie oddzielnie dostarczany sekret deszyfrowania. CloudKit udostępnianie udostępnia informacje o zaproszeniach i uczestnikach Apple. Rekordy sieciowe i operacyjne mogą ujawnić informacje o połączeniu. Revault nie zapewnia anonimowości ani odporności na analizę ruchu.
HTTPS chroni żądania sieciowe podczas przesyłania. Uwierzytelnione szyfrowanie na urządzeniu oddzielnie chroni zawartość skarbca przechowywaną lokalnie i w chmurze. Ani szyfrowanie transportowe, ani tekst zaszyfrowany nie ukrywają wszystkich faktów dotyczących tego, kiedy, gdzie i ile danych jest przesyłanych.
Gdzie kończy się ochrona
Odblokowany skarbiec koniecznie udostępnia odszyfrowane informacje sesji aplikacji. Może to przechwycić złośliwe oprogramowanie, zainfekowany system operacyjny lub aplikacja, osoba przeglądająca ekran lub niezaufany odbiorca. Przechowywanie kluczy tylko na urządzeniu stanowi dodatkową granicę, a nie gwarancję, że urządzenie nie zostanie w pełni zhakowane. Przewidywalny wzorzec jest niebezpieczny, jeśli jego lokalny sekret zostanie naruszony.
Szyfrowanie nie zapobiega usunięciu chmury, oprogramowaniu ransomware, utracie sekretu odzyskiwania, wstrzymaniu zapisów przez dostawcę lub przywróceniu całego, wcześniej ważnego stanu zaszyfrowania. Twórz niezależne zaszyfrowane kopie zapasowe i sprawdzaj odzyskiwanie przed usunięciem starego urządzenia. Odwołanie nie może spowodować wycofania zrzutów ekranu, eksportów lub kopii zatrzymanych już przez inną osobę.
Revault nie przeszedł niezależnego audytu bezpieczeństwa. Są to opisy wdrożonego projektu kryptograficznego, a nie certyfikat czy gwarancja na wypadek każdego włamania.
Odniesienia kryptograficzne
NIST SP 800-38D — szyfrowanie uwierzytelnione GCMRFC 8018 — PBKDF2RFC 5869 — HKDFIstniejące skarbce przeglądarki
W tym dokumencie opisano aplikacje natywne. Istniejące skarbce przeglądarki mają osobne konto, pamięć urządzenia i model chmury internetowej. Przesyłanie S3 specyficzne dla przeglądarki i łącza udostępniania przeglądarki nie są natywną synchronizacją z chmurą. Konto przeglądarki nie umożliwia logowania do aplikacji mobilnych; użyj zaszyfrowanej kopii zapasowej i jej klucza odzyskiwania, aby przenieść istniejące dane przeglądarki do natywnego skarbca.