Biztonsági felépítés: a teljes technikai háttér

A Vaultaire AES-256-GCM-et használ hitelesített titkosításra a széfindexekben, a becsomagolt kulcsokban, a fájlfejlécekben, a tartalomban, a bélyegképekben és a metaadatokban. A PBKDF2-HMAC-SHA512 a mintából és egy az egész eszközre érvényes kulcskarika-sóból helyi széfkulcsot származtat. Ez a széfkulcs becsomagol egy külön, véletlenszerű 256 bites mesterkulcsot, amely a CryptoKiten keresztül, az alkalmazás folyamatában végzi a fájltitkosítást.

A kriptográfiai rétegek

A Vaultaire több, összehangoltan működő kriptográfiai mechanizmust használ, mindegyiket konkrét feladatra választva. A PBKDF2 egy emberi hitelesítő adatból széf- vagy helyreállítási kulcsot készít. Az AES-256-GCM védi az indexeket, a burkokat, a metaadatokat, a bélyegképeket és a fájlok tartalmát. A véletlenszerű mesterkulcs elválasztja a hosszú életű fájltitkosítást a módosítható mintától. A kulcskarika és az iOS adatvédelme az eszköz zárolt állapotában védi az eszközhöz kötött sót és a helyreállítási rekordokat. Nincs szolgáltatónál tartott visszafejtő kulcs, amely rendszeres hozzáférést adna a fejlesztőnek a széf nyílt szövegéhez.

Ez nem öncélú bonyolultság. Minden réteg más támadási felületet kezel. Az AES-256-GCM a bizalmasságot hitelesítéssel ötvözi, így a módosított titkosított szöveg elbukik az ellenőrzésen. A PBKDF2 megdrágítja minden minta vagy kifejezés kipróbálását. A véletlenszerű mesterkulcs miatt mintaváltáskor elég egy kulcsot újracsomagolni, nem kell minden fájlt újratitkosítani. A kulcskarika adatvédelme őrzi a helyi sót és a helyreállítási rekordokat, az alkalmazás ugyanakkor nyíltan kimondja, hogy a szimmetrikus titkosítás a folyamat memóriájában történik.

Ezek a rétegek együtt mélységi védelmet alkotnak, de nem mindegyik független akadály. Egy kitalált minta ellenőrizhető az index fájlnevével és az AES-GCM-hitelesítéssel, egy kompromittált, feloldott eszköz pedig megfigyelheti a kulcsokat vagy a nyílt szöveget az alkalmazás folyamatában. A felépítés ezért a hitelesítő adat entrópiáján, a PBKDF2 költségén, az iOS eszközvédelmén és a hitelesített titkosítás helyes kezelésén is múlik, nem csak az AES erősségén.

AES-256-GCM: fájltitkosítás

Minden Vaultaire-ben tárolt fotó, videó és dokumentum AES-256-GCM-mel van titkosítva: ez az Advanced Encryption Standard 256 bites kulccsal, Galois/Counter módban. A Vaultaire az AES-GCM-et a széfindexekhez, a fájlfejlécekhez, a bélyegképekhez és a kulcsborítékokhoz is használja. Az algoritmus és a kulcsméret szabványos; a Vaultaire biztonsága ettől még a nonce-kezelésen, a kulcskezelésen, a hitelesítő adat erősségén és a megvalósítás helyességén múlik.

Az AES-256-ban a „256” a kulcs bitben mért hossza. Egy 256 bites kulcsnak 2²⁵⁶ lehetséges értéke van. Hogy érzékeltessük ezt a számot: a megfigyelhető univerzumban nagyjából 10⁸⁰ atom van. Ha minden atom egy szuperszámítógép lenne, amely másodpercenként egymilliárd kulcsot próbál ki az ősrobbanás óta, a kulcstér egybilliomod részének egybilliomod részénél is kevesebbet járták volna be. Az AES-256 nyers erővel nem törhető fel. Ma sem. Ebben az évszázadban sem. Addig sem, amíg a csillagok ki nem hunynak.

Miért számít a GCM mód?

Az AES blokktitkosító: 128 bites darabokban titkosítja az adatokat. A „mód” határozza meg, hogyan kapcsolódnak össze ezek a darabok. A GCM (Galois/Counter Mode) két dolgot ad, amit az egyszerűbb módok, például a CBC, nem: párhuzamosítható titkosítást és beépített hitelesítést.

A hitelesítés döntő. A GCM minden titkosított fájlhoz kriptográfiai címkét készít. Ez a címke sértetlenségi pecsétként működik. Ha a titkosított szövegnek akár egyetlen bitje is megváltozik (akár rosszindulatú szereplő, akár sérült lemezszektor miatt), a hitelesítési címke nem fog egyezni, és a visszafejtés meghiúsul. Nem sérült adatot kapsz, hanem egyértelmű jelzést, hogy valami nincs rendben. Ezt a tulajdonságot hitelesített titkosításnak hívják, és megakadályozza azoknak a támadásoknak az egész osztályát, amelyekben a támadó a titkosított adat módosításával próbálja befolyásolni a visszafejtett kimenetet.

PBKDF2: kulcsszármaztatás

A Vaultaire különböző feladatokhoz különböző kulcsokat származtat. A minta és egy az egész eszközre érvényes kulcskarika-só 600 000 iterációs PBKDF2-HMAC-SHA512-be kerül, amely a helyi széfkulcsot adja. Egy determinisztikus mintaszármaztatás adja a külön felhős mentési kulcsot. A normalizált helyreállítási kifejezés 800 000 PBKDF2-iteráción fut át, és egy helyreállítási boríték kulcsát adja. Egyik származtatás sem alakít egy emberi hitelesítő adatot 256 bitnyi entrópiává csak azért, mert a kimenet 256 bit hosszú.

Hogyan védi a PBKDF2 a mintádat?

A PBKDF2 alapötlete a szándékos munka. Veszi a sorba rendezett mintát vagy a normalizált kifejezést, és több százezer HMAC-SHA512-iterációt futtat. A jogosult felhasználó ezt a költséget egy feloldási vagy helyreállítási kísérlet során egyszer fizeti meg. A támadó minden jelöltnél megfizeti, bár a valós tippelési sebességet a párhuzamos hardver és a megvalósítási döntések határozzák meg.

A Vaultaire a mintából származtatott kulcsokhoz 600 000 iterációra állítja a PBKDF2-t. Ez drágábbá teszi az egyes tippeket, de egy felelős támadásbecslésnek meg kell adnia a jelöltenként mért időt és a hardverfeltevéseket. Pontosan egy ezredmásodperc jelöltenként mellett egymilliárd soros tipp körülbelül 11,6 nap, nem évek. A 256 bites eredmény nem növeli egy kiszámítható minta entrópiáját.

A helyi mintaszármaztatás egyetlen, kriptográfiailag véletlenszerű sót használ az eszközhöz, WhenUnlockedThisDeviceOnly kulcskarika-elemként tárolva. A só nem titkos, és az eszközön lévő széfek közösen használják. Megakadályozza, hogy egy eszközre épített tábla közvetlenül alkalmazható legyen egy másik, eltérő sójú eszközre, de nem kényszeríti a támadót arra, hogy ugyanazon az eszközön minden széfnél elölről kezdje.

AES-256-GCM: a metaadatok védelme

A fájltartalom titkosítása nem elég. A fájlnevek, a létrehozási dátumok, a bélyegképek méretei és a széf szerkezete mind metaadatok, és a metaadatok ugyanannyit elárulhatnak, mint maguk az adatok. Egy „adobevallas-2025.pdf” nevű fájl pontosan megmondja a támadónak, mi van benne, még ha a tartalom titkosított is. Egy időbélyeg megmutatja, mikor használtad a széfet. Egy bélyegkép mérete elárulja, hogy fotóról vagy videóról van-e szó.

A Vaultaire ezeket a metaadatokat AES-256-GCM-mel védi, nem ChaCha20-szal. A fájlnevek és a MIME-típusok titkosított fájlfejlécekbe kerülnek. A titkosított széfindex tartalmazza a fájlrekordokat, a dátumokat, a méretadatokat, a tárolási elrendezést és a becsomagolt mesterkulcsot. A bélyegképadatok is a véletlenszerű mesterkulccsal vannak titkosítva.

Miért hitelesített titkosítás a metaadatokhoz?

A metaadatoknak a bizalmasság mellett sértetlenség is kell. Az AES-GCM minden titkosított értékhez hitelesítési címkét készít, így a Vaultaire elutasíthat egy módosított fejlécet, indexet, bélyegképet vagy borítékot, ahelyett hogy a támadó által irányított nyílt szöveget fogadná el. A felépítés szándékosan egyetlen hitelesített titkosítási konstrukciót használ ezekben a tárolási formátumokban, ahelyett hogy olyan kriptográfiai sokszínűséget állítana, amelyet a megvalósítás nem ad.

Az azonos titkosító nem jelenti ugyanannak a kulcsnak vagy nonce-nak a vak újrahasznosítását. A széfkulcs védi az indexet, és becsomagolja a véletlenszerű mesterkulcsot; a mesterkulcs a fájlanyagot védi. A CryptoKit friss nonce-okkal hoz létre hitelesített lezárt dobozokat, a Vaultaire folyamatos (streaming) formátuma pedig minden sorrendbe állított darabhoz külön nonce-ot származtat. A lényeges garanciák a kulcsok szétválasztásából, a nonce-fegyelemből és a hitelesítésből fakadnak, nem egy második metaadat-titkosítóból.

Zero-knowledge architektúra

Íme egy kérdés, amelyet bármely biztonsági alkalmazásnál érdemes feltenni: mi történik, ha a mögötte álló céget feltörik, bírósági felszólítást kap, vagy egyszerűen rosszindulatúvá válik?

A legtöbb alkalmazásnál kellemetlen a válasz. Náluk van az adatod, a kulcsod vagy mindkettő. Egy bírósági végzés kötelezi őket a kiadásra. Egy adatszivárgás nyilvánosságra hozza. Egy rosszhiszemű alkalmazott hozzáfér. Az alkalmazás biztonsága csak annyira erős, mint a cég működési biztonsága, a történelem pedig azt mutatja, hogy cégeket rendszeresen feltörnek.

A Vaultaire nem üzemeltet olyan fiók- vagy tárolási szolgáltatást, amely megkapná a mintádat, a titkos kifejezésedet, a visszafejtő kulcsaidat vagy a széfed olvasható tartalmát. A titkosítás és a visszafejtés az alkalmazás folyamatában, az eszközödön történik. Ha az iCloud-mentés be van kapcsolva, az alkalmazás hitelesített titkosított szöveget küld a privát CloudKit-adatbázisodba, nem egy Vaultaire által irányított széfszolgáltatásba.

Mit jelent a gyakorlatban a zero-knowledge?

Ha egy bűnüldöző szerv bírósági felszólítással a széf nyílt szövegét követeli a Vaultaire-től, a cégnél nincs meg a visszafejtéshez szükséges minta, helyreállítási kifejezés, széfkulcs, mentési kulcs vagy mesterkulcs. A titkosított iCloud-rekordok a felhasználó privát CloudKit-adatbázisában vannak. Az eszközön viszont a helyreállítási anyag egy titkosított kulcskarika-adatbázisban van, a szimmetrikus kulcsok pedig az alkalmazás memóriájában léteznek, amíg a CryptoKit egy nyitott széfet titkosít vagy visszafejt.

Ez a szolgáltatói határ szerkezeti tulajdonság, nem annak ígérete, hogy a kliensoldali környezet minden része kívül esik a bizalmi modellen. A Vaultaire nem tart szerveroldali visszafejtő kulcsot, amelyet a széfek szokásos helyreállításához kiadhatna. A kiadott alkalmazás, az iOS, a feloldott eszköz és a kriptográfiai megvalósítás továbbra is kezelhet olvasható adatokat, ezért ennek megfelelően meg kell bízni bennük.

A kulcskarika és az alkalmazásfolyamat határa

Az Apple Secure Enclave-je védhet bizonyos támogatott privát kulcsokat, és részt vesz a platform biztonsági felépítésének egyes részeiben, a nyilvános API-jai azonban nem fogadnak el tetszőleges, PBKDF2-vel származtatott szimmetrikus kulcsot, és nem végzik el a Vaultaire AES-GCM-fájlműveleteit a társprocesszoron belül. A Vaultaire ezért nem nevezi a széftitkosítóját Secure Enclave-es AES-nek.

A Vaultaire hagyományos iOS-kulcskarika általános jelszóelemeket használ a véletlenszerű eszközsóhoz, a titkosított helyreállítási adatbázishoz és az adatbázist védő véletlenszerű kulcshoz. Ezek az elemek a WhenUnlockedThisDeviceOnly elérhetőségi osztályt használják. A kulcskarika és az adatvédelem érdemi eszközhatárt ad, különösen amíg a telefon zárolva van, ez a felépítés azonban különbözik egy nem exportálható Secure Enclave-kulcstól.

Amikor lerajzolod a mintát, a CommonCrypto az alkalmazás folyamatában származtatja a széfkulcsot. A CryptoKit és a Vaultaire CryptoEngine-je ezután ebben a folyamatban használja a szimmetrikus kulcs bájtjait az index hitelesítéséhez és visszafejtéséhez, a mesterkulcs kicsomagolásához és a fájlok feldolgozásához. Az alkalmazás zároláskor törli az aktív állapotot, de egy feloldott munkamenetet megfigyelő, kellően kiváltságos támadónak más lehetősége van, mint egy vizsgálónak, akinél csak a zárolt eszköz titkosított szövege van.

Egy jailbreakelt vagy más módon kompromittált operációs rendszer célba veheti a mintabevitelt, az alkalmazás memóriáját, a visszafejtett előnézeteket, az exportokat vagy a képernyőt. A Vaultaire naprakész, nem jailbreakelt iPhone-t javasol, mert a felépítés az iOS folyamatelkülönítésére, a kulcskarikára és az adatvédelemre támaszkodik. Nem állítja, hogy root szintű kompromittálás esetén egy nyitott széf szimmetrikus kulcsai elérhetetlenek maradnak.

Fájlonkénti inicializálóvektorok

Ha két azonos fájlt ugyanazzal a kulccsal titkosítasz, egy naiv megvalósítás azonos titkosított szöveget adna. Ez probléma. Egy támadó, aki két azonos titkosított blobot lát, visszafejtés nélkül is tudja, hogy a két eredeti fájl ugyanaz. Egy fotókkal teli széfben az ilyen mintázatelemzés a titkosításon át is információt fedhet fel.

A Vaultaire minden AES-256-GCM-lezáráshoz friss kriptográfiai nonce-ot generál, így elkerüli a determinisztikus titkosított szöveget. A fájlfejlécek és a fájltartalom külön vannak lezárva, a nagy fájlok pedig hitelesített folyamatos formátumot használnak, véletlenszerű alap-nonce-szal és minden sorrendbe állított darabhoz külön nonce-szal. Ugyanannak a fotónak két példánya ezért nem ad azonos titkosított ábrázolást.

A nonce-ok a titkosított szöveggel együtt tárolódnak, és nem titkosak; biztonsági követelményük az, hogy egy adott kulcs alatt egyediek legyenek. A Vaultaire az egylépéses titkosításhoz 96 bites nonce-okat kér az Apple kriptográfiai véletlenszám-generátorától, és a folyamatos fejlécben rögzíti az alap-nonce-ot. Az ütközési kockázatot az egy kulcs alatti titkosítások száma határozza meg, ezért a megvalósítás friss értéket generál, ahelyett hogy a 96 bites méretet rögzített, egy a 2⁹⁶-hoz élettartam-garanciaként mutatná be.

Memóriakezelés: az aktív kulcsállapot törlése

A biztonsági szoftverek gyakori hibája, hogy az érzékeny adatokat akkor is a memóriában hagyják, amikor már nincs rájuk szükség. A titkosítási kulcsok, a származtatott jelszavak és a visszafejtett adatok jóval azután is a RAM-ban maradhatnak, hogy az alkalmazás befejezte a használatukat. Törvényszéki eszközök kiírhatják az eszköz memóriáját, és ilyen maradványokat kereshetnek benne. Ezt hideg rendszerindításos támadásnak vagy memóriakép-elemzésnek hívják.

A Vaultaire korlátozza, meddig marad elérhető az aktív kulcsállapot és a visszafejtett felületi adat. Amikor az alkalmazás zárol, vagy a munkamenet lezárul, a kódja több tisztítási útvonalat követ:

• Az aktív széfállapot megszűnik. Az alkalmazás eltávolítja a jelenlegi széfkulcs-munkamenetet, és újabb feloldást kér, mielőtt széftartalmat mutatna.
• A kulcsburkok törlik a saját puffereiket. A Vaultaire biztonságos bájttárolói felülírják a saját puffereiket, amikor felszabadulnak.
• A gyorsítótárazott mesterkulcs-állapot érvénytelenné válik. A nyitott indexhez tartott visszafejtett mesterkulcs a megfelelő zárolási és gyorsítótár-törlési útvonalakon eldobódik.
• A visszafejtett felületi gyorsítótárak törlődnek, ahol a Vaultaire irányítja őket. A bélyegképek és előnézetek törlése csökkenti az alkalmazás visszamaradó állapotát, anélkül hogy a Swift, az iOS vagy egy másik folyamat által készített minden másolat feletti irányítást állítaná.

Amikor a Vaultaire legközelebb zárolt állapotban nyílik meg, lerajzolod a mintát, és az alkalmazás újra származtatja a széfkulcsot, mielőtt hitelesíthetné az indexet és kicsomagolhatná a mesterkulcsot. Ez munkamenet-tisztítás, nem annak állítása, hogy minden átmeneti memóriamásolat bizonyíthatóan többmenetes törlést kapott, vagy hogy egy Secure Enclave-kulcshivatkozás megsemmisült. Összeomláskor az iOS visszaveszi a folyamatot, a tisztító kód azonban nem futhat le minden hirtelen leállás után.