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
Revault létrehoz egy helyreállítási kifejezést, amely 18 egymástól függetlenül választott szót tartalmaz egy 2048 szavas listából, amely 198 bites véletlenszerűséget biztosít. A teremtés nem kínál egyedi kifejezéseket vagy regenerálást. A kifejezés egymástól függetlenül származtat egy burkolókulcsot az PBKDF2-HMAC-SHA-256 és egy friss só használatával, majd becsomagolja a trezor főkulcsát a AES-256-GCM segítségével. Bárki, aki rendelkezik a kifejezéssel és a titkosított tárolóval, visszafejtheti azt. A meglévő egyéni kifejezések és hexadecimális helyreállítási kulcsok továbbra is kompatibilisek az eredeti tárolókkal.
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.
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.