A védelem a feltöltés előtt kezdődik
A natív széfek helyben, Revault-fiók nélkül működnek. A fájltartalmak, fájlnevek, MIME-típusok, miniatűrök, széfnevek, mappák, címkék és kedvencek az eszközön titkosítottak. A helyi használat nem tölt fel széffájlokat a Revaultra. A natív felhőszinkronizálás és a megosztás opcionális, külön műveletek.
A modell megbízható operációs rendszert, telepített alkalmazást és kriptográfiai véletlenforrást feltételez a széf létrehozásakor vagy feloldásakor. Aki csak titkosított fájlokkal és kulcscsomagolókkal rendelkezik, a szükséges titkos kód nélkül nem tudja visszafejteni őket. A kártevő vagy a feltört alkalmazás, amely a széf nyitva tartása közben fut, rögzítheti az egyszerű szöveget és a kulcsokat.
Minden széfhez független kulcsok
Minden széf véletlenszerű 256 bites AES főkulccsal indul, amelyet az operációs rendszer kriptográfiai véletlenforrása generál. A mozdulat nem közvetlenül határozza meg ezt a kulcsot. Minden széf független főkulcs-anyaggal rendelkezik, így az egyik széfkulcs kiszivárgása nem vezet le másikat.
Az eszközminta a rendezett pontsorozatot egy véletlenszerű 256 bites eszköz-titkos kóddal egyesíti. Az eredő bemenetet NFKC-vel normalizálja, majd PBKDF2-HMAC-SHA-256-ra adja át friss 128 bites sóval és 600 000 iterációval. A levezetett 256 bites kulcs AES-256-GCM-mel csomagolja be a főkulcsot. Az alkalmazás nem ment egyszerű szöveges mintát vagy külön mintaujjlenyomatot.
A minták 5 × 5-ös rácsot használnak, hat–25 különböző ponttal, és az ugyanazon az eszközön regisztrált széfek között egyedinek kell lenniük. Az egyező minta csak a saját széfét nyitja meg; a többi széf neve és tartalma rejtve marad. A kiszámítható mozdulatokat továbbra is könnyebb kitalálni. Aki egy eszköz-titkos kódot és annak titkosított csomagolóját is megszerzi, offline tippelgethet a mintára.
A natív széf megnyitásához a helyi mintája vagy egy kifejezett helyreállítási folyamat szükséges, nem Revault-fiók vagy hozzáférési kulcs. Az opcionális felhőszinkronizálás a platform Apple- vagy Google-engedélyezését használja, az áruházi vásárlások pedig a platform számlázási fiókját. Sem a felhőengedélyezés, sem a vásárlás nem ad széf-visszafejtési kulcsot.
| Cél | Felépítés |
|---|---|
| Széf főkulcsa | Véletlenszerű 256 bites AES-kulcs |
| Kulcsbecsomagolás | PBKDF2-HMAC-SHA-256 · 600 000 iteráció · 128 bites só → AES-256-GCM |
| Metaadatok és indexképek | AES-256-GCM · véletlenszerű 96 bites nonce · 128 bites hitelesítési címke |
| Fájlkulcs-származtatás | HKDF-SHA-256 · fájlonkénti véletlenszerű 256 bites só · 256 bites AES-kimenet |
| Helyreállítási titok | Generált: 18 véletlenszerű szó (198 bit); egyéni: legalább 6 különböző szó és 32–512 karakter |
Csak az eszközön lévő kulcsvédelem
iOS-en az eszközzár nem szinkronizálódó Keychain-elemként van tárolva, WhenUnlockedThisDeviceOnly védelemmel. Csak az eszköz feloldott állapotában érhető el, és nem vándorol a Keychain-szinkronizáláson keresztül. A tárolt titkos kód nem Secure Enclave-kulcs.
Androidon az eszközzárat AES-256-GCM titkosítja egy nem exportálható Android Keystore-kulccsal, amelyhez feloldott eszköz szükséges. A titkosított zárfájl az alkalmazás no-backup könyvtárában van. A Keystore hardveres háttere az eszköztől függ; az alkalmazás nem ígéri, hogy minden eszköz hardveres kulcsokat használ.
A helyi feloldó titkos kódok ki vannak zárva a natív felhőszinkronizálásból és a hordozható széf-biztonsági mentésekből. Egy Apple- vagy Google-fiók birtoklása nem hozza létre újra ezeket a titkos kódokat, és nem old fel automatikusan egy visszaállított széfet. Az új eszköznek ellenőriznie kell a független helyreállítási titkos kódot, és regisztrálnia kell a saját mintáját.
Titkosság és manipuláció észlelése
A széf-metaadatok, a fájl-metaadatok, az indexképek és a becsomagolt kulcsok 128 bites hitelesítési címkéjű AES-256-GCM-et használnak. Minden független titkosítás friss, véletlenszerű 96 bites nonce-ot használ. A visszafejtés a nyílt szöveg visszaadása előtt ellenőrzi a címkét; a módosított titkosított adat vagy a hibás kulcs miatt a hitelesítés meghiúsul.
A kiegészítő hitelesített adat minden titkosított objektumot a formátumverzióhoz, a széfazonosítóhoz, az objektumazonosítóhoz és a célhoz köt. Például az indexkép és a fájl-metaadat rekordja eltérő környezetet használ. Egy titkosított objektum másik széfbe helyezése vagy másik objektum helyett való felhasználása megváltoztatja a hitelesített környezetet, és az ellenőrzés sikertelen lesz.
A hitelesített környezet nem rejti el az azonosítókat, és nem bizonyítja a frissességet. Egy érvényes régebbi rekordnak is lehet érvényes címkéje. Az alkalmazás revíziós ellenőrzései észlelik a szokásos párhuzamos frissítéseket, de ez nem kriptográfiai védelem egy olyan rosszindulatú szolgáltatás ellen, amely egy teljes régebbi állapotot játszik vissza.
A nagy fájlok hitelesített szegmenseket használnak
A natív fájltitkosítás a Tink által leírt AES-256-GCM-HKDF-SHA-256 streaming konstrukciót használja. Az iOS a CryptoKitet használja az AES-GCM-hez és a HKDF-hez; az Android a platform kriptográfiai primitívjeit. Minden új stream 40 bájtos fejlécet kap, amely tartalmazza a hosszjelölőt, egy véletlenszerű 32 bájtos sót és egy véletlenszerű hétbájtos nonce-előtagot.
A HKDF külön fájltitkosítási kulcsot származtat a széf főkulcsából. Környezete tartalmazza a széf- és fájlazonosítókat, a nyílt szöveg bájthosszát és a beállított szegmensméretet. Minden szegmens 12 bájtos nonce-a a véletlenszerű előtagot, egy négybájtos szegmensszámlálót és egy utolsó szegmens jelzőt kombinál. A szegmensek 128 bites GCM-címkét hordoznak.
A natív alkalmazások a fájlokat körülbelül 5 MiB-os korlátozott szegmensekben dolgozzák fel. A szegmensszámlálók, az utolsó szegmens jelzője és a várt bájthosszak észlelik a módosított, átrendezett vagy csonkolt szegmenseket. Minden szegmens hitelesítésre kerül a használat előtt, a privát előnézet pedig csak a fájl visszafejtésének befejezése után jelenik meg. A hiányos kimenet hiba esetén eldobásra kerül; az újrapróbálkozások a meglévő titkosított bájtokat viszik át.
A felépítés követi a Tink AES-GCM-HKDF streamelési specifikációját. A Revault megvalósítását és szegmenskonfigurációját a Tink nem auditálta és nem tanúsította függetlenül.
Privát tárhely, importálás és előnézetek
A titkosított széffájlok privát alkalmazástárhelyen vannak. A fájlnevek, MIME-típusok, mappák, címkék, kedvencek és miniatűrök hitelesített titkosított rekordok. A keresés és a címkeszűrés a feloldás után az aktív széf visszafejtett metaadatain működik; nincs egyszerű szöveges szerveroldali keresési index.
A fotó-, videó- és fájlimportok a titkosítás előtt privát ideiglenes előkészítést használhatnak. A széfen belüli kamerás rögzítés automatikusan nem ment másolatot a galériába. A Fotókból vagy más szolgáltatótól való importálás érintetlenül hagyja annak a szolgáltatónak az eredetijét. Az opcionális médiaoptimalizálás helyben, a titkosítás előtt történik, és csak az újonnan importált médiát módosítja.
A privát előnézetekhez nyitva tartásuk alatt ideiglenes egyszerű szövegre van szükség. Az alkalmazások bezáráskor, zároláskor és a következő indításkor eltávolítják az ideiglenes előnézeteket; az iOS teljes fájlvédelmet alkalmaz a visszafejtett előnézeti fájlokra. A kifejezetten egy másik alkalmazásba exportált fájlok elhagyják a széf védelmét. Az ideiglenes fájlok törlése nem garantál kriminalisztikai szintű törlést.
Opcionális natív felhőszinkronizálás
A szinkronizálás alapértelmezés szerint ki van kapcsolva, és széfenként, eszközönként külön engedélyezhető. Az iOS a titkosított rekordokat és fájlszegmenseket a felhasználó iCloudban lévő privát CloudKit-adatbázisában tárolja. Az Android a Google Drive privát appDataFolder mappáját használja. Egyik átviteli mód sem igényel Revault-fiókot, és nem tölt fel natív szinkronadatokat a Revault webes felhőjébe.
A felhő titkosított metaadatokat, fájlszegmenseket és kulcscsomagolókat kap, nem egyszerű szöveges széf-főkulcsot, helyi eszköz-titkos kódot vagy helyreállítási titkos kódot. Egy azonos platformú másik eszköznek ugyanarra a natív felhőfiókra és a széf helyreállítási kulcsára van szüksége a saját helyi mintájának regisztrálásához. Az Apple- és Google-engedélyezés a titkosított rekordokhoz való hozzáférést szabályozza, nem a visszafejtésüket.
A szinkronizálás kikapcsolása leállítja az adott széf további átvitelét az aktuális eszközről; a meglévő titkosított felhőmásolatok megmaradnak. A szinkronizálás módosításokat és törléseket terjeszthet, az egyidejű szerkesztések pedig ütközés-felülvizsgálatot igényelhetnek. Az iCloud és a Google Drive különálló tárolók, automatikus platformok közötti híd nélkül. iPhone és Android között titkosított telefonátvitellel mozoghat.
A helyreállítás második út ugyanahhoz a kulcshoz
A generált helyreállítási kifejezések 18, egymástól függetlenül kiválasztott szót tartalmaznak egy beépített, 2048 szavas listából, ami 198 bit véletlenszerűséget ad. Választhat helyette egyéni kifejezést is, legalább hat különböző szóval és 32–512 karakterrel; ennek erőssége az Ön választásaitól függ. Mindkettőből a PBKDF2-HMAC-SHA-256 és egy új só segítségével egymástól függetlenül burkolókulcs készül, amely AES-256-GCM-mel burkolja ugyanazt a széf-főkulcsot. A kifejezés és a titkosított széf birtokában bárki visszafejtheti azt.
A helyreállítási titkos kód a beállítás során jelenik meg, és nem marad meg a natív alkalmazás tárhelyén, és nem töltődik fel a natív felhőtárhelyre. Tartsa a titkosított fájloktól külön. Egy másik eszköz regisztrálásához az eredeti natív felhőfiókból származó titkosított széf, vagy egy titkosított biztonsági mentés, valamint a helyreállítási kulcs szükséges. Egy titkos kód nem állíthatja vissza a hiányzó fájladatokat, és a Revaultnak nincs a szolgáltatónál lévő visszaállítási kulcsa.
A hordozható .qvault biztonsági mentés titkosított kulcscsomagolókat, hitelesített titkosított leltárt és titkosított fájlszegmenseket tartalmaz. Nem tartalmazza a helyi eszközfeloldó titkos kódot. Az importálás ellenőrzi a leltárt, a metaadatokat és minden szegmenst, mielőtt friss azonosítókkal, főkulccsal, fájlkulcsokkal és új eszközmintával rendelkező széfbe állítaná vissza. A visszaállítás után mentse el az új helyreállítási kulcsot.
Az új helyreállítási kifejezések megőrzik a kis- és nagybetűket, NFKC szerint normalizálják az Unicode-ot, és összevonják a felesleges szóközöket. A régi hexadecimális kulcsok továbbra is támogatottak. Az új kifejezés elmentése után lecserélheti a széf helyreállítási kifejezését a beállításaiban. Ez a jelenlegi helyreállítási burkolót cseréli le; a régi biztonsági mentések és a még nem szinkronizált eszközök továbbra is őrizhetik a régi burkolót. A minta vagy a helyreállítási kifejezés módosítása nem cseréli le a széf főkulcsát, és nem vonja vissza a másolatokat. Ha a kulcsanyag sérül, helyezze át a fájlokat egy új, friss kulcsokkal rendelkező széfbe.
Titkosított átvitel telefonról telefonra
A telefonátvitel hordozható titkosított másolatot hoz létre friss széfazonosítókkal, főkulccsal, fájlkulcsokkal és streamfejlécekkel. A független átviteli titkos kód nem oldhatja fel a forrásszéfet, és a forrás helyreállítási titkos kódja és az eszközfeloldó titkos kód nem szerepel benne. A titkosított csomagot és az átviteli titkos kódot külön kell eljuttatni.
A fogadó alkalmazás hitelesíti a csomagot és annak fájlszegmenseit, majd új széfbe állítja vissza új helyi mintával és helyreállítási kulccsal. Ez iOS és Android között a felhőfiókok áthidalása nélkül működik. Az eredeti a régi eszközön marad; a törlés előtt erősítse meg a visszaállított tartalmat, és mentse el az új helyreállítási kulcsot.
Zárolás és munkamenet-takarítás
A mobilalkalmazások a háttérbe kerüléskor azonnal, alapértelmezés szerint pedig 60 másodperc inaktivitás után zárolnak. Minden széf kiválaszthat 30 másodpercet, 1 percet, 2 percet, 5 percet vagy 10 percet. A megosztott széf a 60 másodperces alapértelmezést használja. A kilépés visszavisz a mintaképernyőre, és befejezi a visszafejtett munkamenetet.
A zárolás megszakítja a munkamenet feladatait, törli a visszafejtett metaadatokat és a keresési állapotot, bezárja az előnézeteket, eltávolítja az ideiglenes fájlokat, és felülírja a birtokolt kulcspuffereket, mielőtt felszabadítaná őket. Az ideiglenes levezetési kulcsok is törlődnek használat után. A Swift és a JVM memóriakezelése, a kriptográfiai könyvtárak és a médiadekóderek másolatokat készíthetnek; minden másolat azonnali törlése nem garantálható.
Az iOS adatvédelmi védőréteggel takarja az alkalmazásváltó pillanatképeit. Az Android a secure-window jelzőt használja a képernyőképek és a legutóbbi alkalmazások előnézeteinek korlátozására. Ezek a platformvédelmek nem akadályozzák meg, hogy valaki lefényképezze a feloldott képernyőt, és nem vonják vissza a korábban egy másik alkalmazásba exportált fájlokat.
Revault Cloud
A Revault Cloud egy opcionális Pro tárhelyszolgáltató a platformok közötti szinkronizáláshoz. A titkosított szegmensek és a titkosított fájlmetaadatok egy álnevesített számlázási telepítéshez kapcsolódnak. A szolgáltatás látja a tárhelyazonosítókat, a méreteket, az ellenőrzőösszegeket, a revíziókat és az átviteli tevékenységet, de nem kap feloldott széfkulcsot vagy helyreállítási kifejezést. Egy különálló, véletlenszerű kapcsolati kód engedélyezi a tárhely-hozzáférést; egy másik eszköz csatlakoztatásához a helyreállítási kifejezés is szükséges. A meglévő felhőadatok a Pro lejárta után is olvashatók maradnak helyreállítás céljából.
Natív megosztási átviteli módok és hozzáférés-vezérlés
iOS-en a privát, csak olvasható CloudKit-meghívó a titkosított pillanatképet külön megosztási rekordhierarchiába helyezi, a személyes szinkronzónán kívül. A meghívóhoz való hozzáférést az Apple szabályozza; a címzettnek továbbra is szüksége van a külön visszafejtési titkos kódra. A CloudKit-meghívók nem kényszerítik ki a szerver hozzáférésimunkamenet-számát, rögzített lejáratát vagy megsemmisítési időzítőjét. A tulajdonos leállíthatja a jövőbeli CloudKit-hozzáférést.
A platformok közötti megosztások titkosított részeket töltenek fel a Revault megosztási szolgáltatásába. A független, véletlenszerű 256 bites olvasási és kezelési jogosultságok SHA-256 hashként vannak tárolva. A weboldal linkje az olvasási jogosultságot a töredékében (fragment) hordozza, nem a visszafejtési titkos kódot. Megnyitása mélylinkkel megosztott széfre vezet, és a feladó titkos kódját kéri; személyes minta vagy meglévő széf nem szükséges. A személyes széfek zárolva maradnak.
Az ellenőrzött szerveres megosztások kikényszerítik a feladó által megadott legfeljebb hozzáférési munkameneteket, a 30 napon belüli rögzített lejáratot, a visszavonást és az opcionális exportálási engedélyt. A munkamenetet atomi módon adja meg a rendszer, és legfeljebb 15 percig tart, a megosztás határidői által korlátozva. A hozzáférés a munkamenet megadásakor beleszámít, még akkor is, ha a letöltés vagy a visszafejtés sikertelen. A megjelenítő ellenőrzi a folyamatos hozzáférést, és a határidőnél bezár.
Az SHA-256 ellenőrző összegek az átvitt részek épségét igazolják, a hitelesített titkosítás pedig a tartalmukét. Ha az exportálás engedélyezett, a megtekintő mentheti a megosztás titkos kódjával megnyitható, titkosított .qvault másolatot. Az exportálás letiltása csak az alkalmazás ezen műveletét szünteti meg; kriptográfiailag nem akadályozhatja meg a képernyőképeket, illetve azt, hogy egy módosított kliens megtartsa a titkosítatlan tartalmat. A forrásfájl törlése nem vonja vissza a tőle függetlenül létrehozott megosztást.
Opcionális széftevékenység
A natív naplók alapértelmezés szerint ki vannak kapcsolva, és eszközönként, széfenként konfigurálhatók. Az utolsó 500 helyi esemény a széf főkulcsával és külön hitelesített környezettel titkosított. Nem tartalmaznak kulcsokat, mintákat, fájltartalmat vagy más széfek adatait, nem szinkronizálódnak, és törölhetők vagy kikapcsolhatók. Nem manipulációbiztos bizonyítékok. A sikertelen feloldások nincsenek széfhez rendelve.
A naplózás bekapcsolásával létrehozott új, szabályozott megosztások legfeljebb 100 hozzáférési munkamenet időbélyegét őrzik meg a megosztási szolgáltatáson. Csak a kezelési képesség tudja lekérni őket; a napló nem tartalmaz címzettazonosítót vagy visszafejtési titkot. A helyi naplózás kikapcsolása a jövőbeli megosztásokat érinti. A meglévő megosztási naplók az eredeti beállításukat megtartják a visszavonásig vagy lejáratig és takarításig.
Opcionális titkosított behatolási fotók
A tulajdonosok eszközönként és széfenként külön kapcsolhatják be a Behatolásjelzéseket. Három nem egyező minta után az előtérben lévő alkalmazás elülső kamerás fotót készíthet, az engedélytől, a kamera elérhetőségétől és az egyperces várakozási időtől függően. A rendszer kameraindikátorai láthatók maradnak. Az utolsó tíz riasztás helyben tárolódik, és soha nem kerül a Fotókba vagy feltöltésre. Egy nem egyező minta nem azonosít célszéfet, ezért minden bekapcsolt széf külön titkosított eszközpróbálkozási rekordot kap.
Egy dedikált RSA-3072 nyilvános kulcs minden riasztáshoz becsomagol egy friss 256 bites AES-GCM-kulcsot OAEP-pel, SHA-256-tal és MGF1-SHA-256-tal. Ez lehetővé teszi a titkosítást, amíg a széf zárolva van. A megfelelő privát kulcsot maga is a széf főkulcsa titkosítja külön hitelesített környezettel. Csak az adott széf feloldása tudja visszafejteni a fotóit. A riasztások a rendes tevékenységnaplózástól függetlenül jelennek meg a széf audit nézetében, és a Behatolásjelzések beállításaiban törölhetők. Nem manipulációbiztos bizonyítékok.
A Biztonságos kilépés eltávolítja a helyi hozzáférést
Az eszközön egy széf jelölhető ki Biztonságos kilépéshez. Ha megadják a mintáját, a széf a megszokott módon megnyílik, a többi helyi széf rekordjait, titkosított adattömbjeit, az eszköz feloldási adatait és a függőben lévő módosításokat viszont eltávolítja a rendszer. Az alkalmazás tartós helyi engedélylistát vezet, hogy a szinkronizálás ne tölthesse vissza csendben a kizárt széfeket. A már folyamatban lévő titkosított átvitelek még befejeződhetnek.
A natív felhőbeli másolatok és a más eszközökön lévő másolatok megmaradnak. A kizárt széf kifejezett helyreállításához az új helyi minta beállítása előtt szükség van a széf helyreállítási kulcsára. A külön biztonsági mentés nélküli, csak offline széf elveszhet. Ez a beállítás az aktuális telepítésre vonatkozik, nem az ugyanazt a felhőfiókot használó összes eszközre.
A Biztonságos kilépés nem garantál törvényszéki szintű törlést vagy elrejtést. A flash tárhely, az operációs rendszer gyorsítótárai, a biztonsági mentések és a korábbi exportok nyomokat őrizhetnek. Az alkalmazásadatok törlése vagy az újratelepítés megszüntetheti a helyi elkülönítést; a felhőbeli rekordok ekkor a natív felhőfiókon keresztül újra felfedezhetők. Ezeket a rekordokat csak a helyreállítási titok oldhatja fel.
Ami látható marad
A titkosítás a tartalmat rejti el, nem minden működési információt. A helyi rekordok és a felhőszolgáltatók láthatják az azonosítókat, a rekordok közötti kapcsolatokat, az objektumok számát, méretét, a revíziókat, az időbélyegeket, a titkosított kulcsburkolókat és az adatfolyam-fejléceket. Az azonosítók UUIDv7 formátumúak, és létrehozási időre utaló információt tartalmaznak; nem titkok. Az Apple vagy a Google a natív szinkronizálási tevékenységet összekapcsolhatja a platformfiókkal.
A Revault ellenőrzött megosztási szolgáltatása láthatja a titkosított csomagok méretét, a részek ellenőrző összegeit, a lejárati beállításokat, a hozzáférési munkamenetek számát és az opcionális munkamenet-időbélyegeket, a külön eljuttatott visszafejtési titkot azonban nem. A CloudKit-megosztás meghívási és résztvevői adatokat tesz láthatóvá az Apple számára. A hálózati és működési naplók kapcsolati információkat fedhetnek fel. A Revault nem biztosít névtelenséget, sem forgalomelemzéssel szembeni ellenállást.
A HTTPS az átvitel közbeni hálózati kéréseket védi. Az eszközön végzett hitelesített titkosítás ettől függetlenül védi a helyben és a felhőben tárolt széftartalmat. Sem az átviteli titkosítás, sem a titkosított adat nem rejt el minden tényt arról, hogy mikor, hol vagy mennyi adat kerül átvitelre.
Használati analitika
Alapértelmezés szerint engedélyezve. A Mixpanel véletlenszerű analitikai azonosítóval kap funkcióhasználati eseményeket. A széf tartalma, a nevek, a minták, a kulcsok és a megosztási titkok kizártak. Az analitikát bármikor kikapcsolhatja ezen a böngészőn vagy eszközön.
Ahol a védelem véget ér
A feloldott széf szükségszerűen visszafejtett információt tár az alkalmazás munkamenete elé. Kártevő, feltört operációs rendszer vagy alkalmazás, a képernyőt figyelő személy vagy megbízhatatlan címzett rögzítheti azt. Az eszközhöz kötött kulcstárolás további védelmi réteg, nem garancia egy teljesen feltört eszközzel szemben. A könnyen kitalálható minta nem biztonságos, amint a helyi titok sérül.
A titkosítás nem akadályozza meg a felhőből való törlést, a zsarolóvírusokat, a helyreállítási titok elvesztését, azt, hogy a szolgáltató visszatartsa a rekordokat, sem egy korábban érvényes teljes titkosított állapot visszagörgetését. Tartson független, titkosított biztonsági mentéseket, és egy régi eszköz eltávolítása előtt ellenőrizze a helyreállítást. A visszavonás nem hívhatja vissza a képernyőképeket, exportokat vagy a másik személynél már megtartott másolatokat.
A Revault nem esett át független biztonsági auditon. Ezek a megvalósított kriptográfiai felépítés leírásai, nem tanúsítvány, és nem garancia minden behatolás ellen.
Kriptográfiai hivatkozások
NIST SP 800-38D — GCM hitelesített titkosításRFC 8018 — PBKDF2RFC 5869 — HKDFMeglévő böngészős széfek
Ez a leírás a natív alkalmazásokra vonatkozik. A meglévő böngészős széfek külön fiók-, eszköztárolási és webes felhőmodellt használnak. A böngészőspecifikus S3-feltöltések és a böngészős megosztási linkek nem natív felhőszinkronizálások. A böngészős fiók nem jelentkeztet be a mobilalkalmazásokba; a meglévő böngészős adatok natív széfbe költöztetéséhez használjon titkosított biztonsági mentést és a hozzá tartozó helyreállítási kulcsot.