Bezpečnostní architektura: Kompletní technický základ

Vaultaire používá AES-256-GCM pro ověřené šifrování indexů trezoru, zabalených klíčů, hlaviček souborů, obsahu, náhledů a metadat. PBKDF2-HMAC-SHA512 odvodí místní klíč trezoru ze vzoru a ze soli v Keychain společné pro celé zařízení. Tento klíč trezoru obaluje samostatný náhodný 256bitový hlavní klíč, kterým CryptoKit v procesu aplikace šifruje soubory.

Kryptografický základ

Vaultaire používá několik kryptografických mechanismů, které spolupracují a každý má svůj úkol. PBKDF2 převádí lidský přihlašovací údaj na klíč trezoru nebo klíč pro obnovení. AES-256-GCM chrání indexy, obaly, metadata, náhledy a obsah souborů. Náhodný hlavní klíč odděluje dlouhodobé šifrování souborů od vzoru, který lze změnit. Keychain a Ochrana dat v iOS chrání sůl a záznamy obnovy vázané na zařízení, když je zařízení zamčené. Žádný dešifrovací klíč u poskytovatele nedává vývojáři běžný přístup k otevřenému textu trezoru.

Nejde o složitost pro složitost. Každá vrstva řeší jinou plochu útoku. AES-256-GCM spojuje důvěrnost s ověřením, takže upravený šifrovaný text ověřením neprojde. PBKDF2 prodražuje zkoušení každého vzoru nebo fráze. Díky náhodnému hlavnímu klíči stačí při změně vzoru znovu zabalit jeden klíč místo šifrování každého souboru znovu. Ochrana dat v Keychain hlídá místní sůl a záznamy obnovy, přičemž aplikace otevřeně uvádí, že symetrické šifrování probíhá v paměti procesu.

Tyto vrstvy společně tvoří architekturu ochrany do hloubky, nejsou to ale všechno nezávislé bariéry. Uhádnutý vzor lze ověřit proti názvu indexového souboru a ověření AES-GCM a napadené odemčené zařízení může v procesu aplikace sledovat klíče nebo otevřený text. Architektura proto závisí na entropii přihlašovacích údajů, výpočetní náročnosti PBKDF2, ochraně zařízení v iOS a správném zacházení s ověřeným šifrováním stejně jako na síle samotného AES.

AES-256-GCM: Šifrování souborů

Každá fotka, video a dokument uložený ve Vaultaire je šifrovaný pomocí AES-256-GCM, tedy standardu Advanced Encryption Standard s 256bitovým klíčem v režimu Galois/Counter. Vaultaire používá AES-GCM také pro indexy trezorů, hlavičky souborů, náhledy a obálky klíčů. Algoritmus i velikost klíče jsou standardizované; bezpečnost Vaultaire ale stále závisí na zacházení s nonce, správě klíčů, síle přihlašovacích údajů a správnosti implementace.

Číslo “256” v AES-256 označuje délku klíče v bitech. 256bitový klíč má 2²⁵⁶ možných hodnot. Pro představu: v pozorovatelném vesmíru je přibližně 10⁸⁰ atomů. Kdyby každý atom byl superpočítač testující miliardu klíčů za sekundu a běžel od Velkého třesku, prozkoumaly by méně než bilióntinu bilióntin procenta prostoru klíčů. AES-256 nebude prolomen hrubou silou. Ne dnes. Ne v tomto století. Ne dříve, než vyhasnou hvězdy.

Proč záleží na režimu GCM

AES je bloková šifra: šifruje data v 128bitových blocích. “Režim” určuje, jak jsou tyto bloky kombinovány. GCM (Galois/Counter Mode) poskytuje dvě věci, které jednodušší režimy jako CBC neposkytují: paralelizované šifrování a vestavěnou autentizaci.

Část autentizace je kritická. GCM generuje kryptografickou značku pro každý zašifrovaný soubor. Tato značka funguje jako pečeť proti manipulaci. Pokud je modifikován jediný bit šifrového textu, ať již zlomyslným aktérem nebo poškozeným sektorem disku, autentizační značka nebude odpovídat a dešifrování selže. Nezísknáte poškozená data. Dostanete jasný signál, že je něco špatně. Tato vlastnost se nazývá autentizované šifrování a zabraňuje celé třídě útoků, kde protivník modifikuje šifrovaná data k manipulaci dešifrovaného výstupu.

PBKDF2: Odvozování klíčů

Vaultaire odvozuje pro různé úkoly různé klíče. Vzor a sůl z Keychain společná pro celé zařízení vstupují do PBKDF2-HMAC-SHA512 se 600 000 iteracemi, které vytvoří místní klíč trezoru. Deterministické odvození ze vzoru vytvoří samostatný klíč pro zálohu v cloudu. Normalizovaná fráze pro obnovení projde 800 000 iteracemi PBKDF2 a vznikne klíč pro obálku obnovy. Žádné z těchto odvození nepromění lidský přihlašovací údaj ve 256 bitů entropie jen proto, že výstup má 256 bitů.

Jak PBKDF2 chrání váš vzor

Základní myšlenkou PBKDF2 je záměrná práce. Vezme serializovaný vzor nebo normalizovanou frázi a provede stovky tisíc iterací HMAC-SHA512. Oprávněný uživatel tuto cenu zaplatí jednou při pokusu o odemčení nebo obnovu. Útočník ji platí za každého kandidáta, skutečnou rychlost hádání ale určuje paralelní hardware a volby implementace.

Vaultaire nastavuje PBKDF2 na 600 000 iterací pro klíče odvozené ze vzoru. Každý pokus tím zdraží, odpovědný odhad útoku ale musí uvést naměřený čas na kandidáta a předpoklady o hardwaru. Při přesně 1 ms na kandidáta trvá miliarda sériových pokusů asi 11,6 dne, ne roky. 256bitový výsledek nerozšíří entropii předvídatelného vzoru.

Místní odvození ze vzoru používá jednu kryptograficky náhodnou sůl pro celé zařízení, uloženou jako položka Keychain s třídou WhenUnlockedThisDeviceOnly. Sůl není tajná a sdílejí ji všechny trezory v daném zařízení. Brání tomu, aby tabulka sestavená pro jedno zařízení šla přímo použít na jiné zařízení s jinou solí, nenutí ale útočníka začínat znovu u každého trezoru ve stejném zařízení.

AES-256-GCM: ochrana metadat

Šifrování obsahu souborů nestačí. Názvy souborů, data vytvoření, rozměry miniatur a struktura trezoru jsou metadata, a metadata mohou být stejně odhalující jako samotná data. Soubor s názvem “danove-priznani-2025.pdf” útočníkovi přesně prozradí, co je uvnitř, i když je obsah zašifrován. Časové razítko ukazuje, kdy jste trezor používali. Velikost miniatury prozradí, zda je něco fotografie nebo video.

Vaultaire tato metadata chrání pomocí AES-256-GCM, ne ChaCha20. Názvy souborů a typy MIME jsou zakódované do šifrovaných hlaviček souborů. Šifrovaný index trezoru obsahuje záznamy o souborech, data, údaje o velikosti, rozložení úložiště a zabalený hlavní klíč. Data náhledů jsou také šifrovaná náhodným hlavním klíčem.

Proč ověřené šifrování pro metadata?

Metadata potřebují integritu stejně jako důvěrnost. AES-GCM vytváří pro každou šifrovanou hodnotu ověřovací značku, takže Vaultaire může upravenou hlavičku, index, náhled nebo obálku odmítnout, místo aby přijal otevřený text podvržený útočníkem. Návrh záměrně používá napříč těmito formáty úložiště jedinou konstrukci ověřeného šifrování a netvrdí kryptografickou rozmanitost, kterou implementace neposkytuje.

Stejná šifra neznamená, že se naslepo opakovaně používá stejný klíč nebo nonce. Klíč trezoru chrání index a obaluje náhodný hlavní klíč; hlavní klíč chrání obsah souborů. CryptoKit vytváří ověřené zapečetěné schránky s čerstvými nonce, zatímco streamovací formát Vaultaire odvozuje pro každý blok v pořadí jinou nonce. Podstatné záruky plynou z oddělení klíčů, kázně při práci s nonce a z ověřování, ne z druhé šifry pro metadata.

Architektura nulových znalostí

Zde stojí za to položit otázku ohledně jakékoli bezpečnostní aplikace: co se stane, pokud je společnost za ní hacknutá, předvolána k soudu nebo prostě se obrátí?

U většiny aplikací je odpověď nepříjemná. Drží vaše data, vaše klíče nebo oboje. Soudní příkaz je přinutí je předat. Únik dat je odhalí. Nepoctivý zaměstnanec k nim přistoupí. Bezpečnost aplikace je jen tak silná jako provozní bezpečnost společnosti, a historie ukazuje, že společnosti jsou pravidelně prolomeny.

Vaultaire neprovozuje účet ani úložnou službu, která by přijímala váš vzor, tajnou frázi, dešifrovací klíče nebo čitelný obsah trezoru. Šifrování i dešifrování probíhá v procesu aplikace ve vašem zařízení. Když je zapnutá záloha na iCloud, aplikace odesílá ověřený šifrovaný text do vaší soukromé databáze CloudKit, ne do úložiště řízeného Vaultaire.

Co architektura nulových znalostí v praxi znamená

Pokud orgán činný v trestním řízení doručí Vaultaire předvolání požadující otevřený text trezoru, společnost nemá vzor, frázi pro obnovení, klíč trezoru, záložní klíč ani hlavní klíč, které by k dešifrování potřebovala. Šifrované záznamy na iCloudu leží v soukromé databázi CloudKit uživatele. V zařízení je ale materiál pro obnovu uložený v šifrované databázi v Keychain a symetrické klíče existují v paměti aplikace, zatímco CryptoKit šifruje nebo dešifruje otevřený trezor.

Tato hranice poskytovatele je vlastností architektury, ne slibem, že každá část klientského prostředí leží mimo model důvěry. Vaultaire nedrží na serveru žádný dešifrovací klíč, který by mohl vydat pro běžnou obnovu trezoru. Dodaná aplikace, iOS, odemčené zařízení a kryptografická implementace mohou čitelná data stále zpracovávat a musíte jim podle toho důvěřovat.

Keychain a hranice procesu aplikace

Secure Enclave od Applu umí chránit podporované soukromé klíče a podílí se na částech bezpečnostní architektury platformy, jeho veřejná rozhraní API ale nepřijmou libovolný symetrický klíč odvozený přes PBKDF2 a neprovedou uvnitř koprocesoru operace AES-GCM se soubory Vaultaire. Vaultaire proto svou šifru trezoru nepopisuje jako AES v Secure Enclave.

Vaultaire používá běžné položky iOS Keychain typu generic-password pro náhodnou sůl zařízení, šifrovanou databázi obnovy a náhodný klíč, který tuto databázi chrání. Tyto položky mají třídu přístupnosti WhenUnlockedThisDeviceOnly. Keychain a Ochrana dat vytvářejí smysluplnou hranici zařízení, hlavně když je telefon zamčený, tato architektura se ale liší od neexportovatelného klíče v Secure Enclave.

Když nakreslíte vzor, CommonCrypto odvodí klíč trezoru v procesu aplikace. CryptoKit a CryptoEngine Vaultaire pak v tomto procesu používají bajty symetrického klíče k ověření a dešifrování indexu, rozbalení hlavního klíče a zpracování souborů. Aplikace při zamčení maže aktivní stav, dostatečně privilegovaný útočník sledující odemčenou relaci má ale jiné možnosti než forenzní analytik, který má jen šifrovaný text ze zamčeného zařízení.

Operační systém s jailbreakem nebo jinak napadený může cílit na zadávání vzoru, paměť aplikace, dešifrované náhledy, exporty nebo obrazovku. Vaultaire doporučuje aktuální iPhone bez jailbreaku, protože návrh spoléhá na izolaci procesů v iOS, Keychain a Ochranu dat. Netvrdí, že by při napadení na úrovni roota zůstaly symetrické klíče otevřeného trezoru nedostupné.

Inicializační vektory na soubor

Když zašifrujete dva identické soubory stejným klíčem, naivní implementace by vytvořila identický šifrový text. To je problém. Útočník, který vidí dva identické zašifrované bloby, ví bez dešifrování čehokoli, že dva původní soubory jsou stejné. V trezoru plném fotografií může takový typ analýzy vzorů odhalit informace i přes šifrování.

Vaultaire brání deterministickému šifrovanému textu tím, že pro každou operaci zapečetění AES-256-GCM vygeneruje novou kryptografickou nonce. Hlavičky souborů a obsah souborů se pečetí zvlášť a velké soubory používají ověřený streamovací formát s náhodnou základní nonce a odlišnou nonce pro každý blok v pořadí. Dvě kopie stejné fotky proto nevytvoří stejnou šifrovanou podobu.

Nonce se ukládají spolu se šifrovaným textem a nejsou tajné; bezpečnostním požadavkem je jejich jedinečnost pod daným klíčem. Vaultaire si pro jednorázové šifrování žádá 96bitové nonce od kryptografického generátoru náhodných čísel od Applu a základní nonce zapisuje do hlavičky streamu. Riziko kolize závisí na počtu šifrování pod jedním klíčem, proto implementace generuje pokaždé novou hodnotu, místo aby 96bitovou velikost vydávala za pevnou celoživotní záruku jedna ku 2⁹⁶.

Správa paměti: mazání stavu aktivních klíčů

Běžnou chybou bezpečnostního softwaru je ponechání citlivých dat v paměti déle, než je potřeba. Šifrovací klíče, odvozená hesla a dešifrovaná data mohou v RAM přetrvávat dlouho poté, co je aplikace přestala používat. Forenzní nástroje mohou vypsat paměť zařízení a hledat tyto zbytky, technika známá jako útok studeným spouštěním nebo analýza výpisu paměti.

Vaultaire omezuje, jak dlouho zůstává dostupný stav aktivních klíčů a dešifrovaná data rozhraní. Když se aplikace zamkne nebo se relace ukončí, její kód projde několika cestami úklidu:

• Aktivní stav trezoru se zahodí. Aplikace odstraní aktuální relaci s klíčem trezoru a před zobrazením obsahu trezoru vyžaduje nové odemčení.
• Obaly klíčů mažou své vlastní buffery. Zabezpečené bajtové kontejnery Vaultaire přepíšou buffery, které vlastní, když se tyto kontejnery uvolní.
• Stav hlavního klíče v mezipaměti se zneplatní. Dešifrovaný hlavní klíč držený pro otevřený index se zahodí na příslušných cestách zamčení a vymazání mezipaměti.
• Dešifrované mezipaměti rozhraní se mažou tam, kde je Vaultaire ovládá. Úklid náhledů a miniatur snižuje zbytkový stav aplikace, aniž by tvrdil, že má pod kontrolou každou kopii vytvořenou jazykem Swift, systémem iOS nebo jiným procesem.

Když Vaultaire příště otevřete v zamčeném stavu, nakreslíte vzor a aplikace znovu odvodí klíč trezoru, než může ověřit index a rozbalit hlavní klíč. Jde o úklid relace, ne o tvrzení, že každá dočasná kopie v paměti prošla prokazatelným vícenásobným přepsáním nebo že byl zničen odkaz na klíč v Secure Enclave. Po pádu si iOS proces uvolní, úklidový kód se ale nemůže spustit po každém náhlém ukončení.