Architektura bezpieczeństwa: Pełny stos techniczny

Vaultaire używa AES-256-GCM do uwierzytelnionego szyfrowania indeksów sejfu, opakowanych kluczy, nagłówków plików, treści, miniatur i metadanych. PBKDF2-HMAC-SHA512 wyprowadza lokalny klucz sejfu ze wzoru i soli urządzenia zapisanej w Keychain. Ten klucz sejfu opakowuje oddzielny losowy 256-bitowy klucz główny, którym CryptoKit szyfruje pliki w procesie aplikacji.

Stos kryptograficzny

Vaultaire używa kilku współpracujących mechanizmów kryptograficznych, każdego do określonego zadania. PBKDF2 zamienia ludzkie poświadczenie w klucz sejfu lub klucz odzyskiwania. AES-256-GCM chroni indeksy, opakowania, metadane, miniatury i zawartość plików. Losowy klucz główny oddziela długotrwałe szyfrowanie plików od zmieniającego się wzoru. Keychain i Ochrona danych iOS chronią powiązane z urządzeniem rekordy soli i odzyskiwania, gdy urządzenie jest zablokowane. Żaden klucz deszyfrujący przechowywany przez dostawcę nie daje programiście rutynowego dostępu do tekstu jawnego sejfu.

To nie złożoność dla samej złożoności. Każda warstwa odpowiada na inną powierzchnię ataku. AES-256-GCM łączy poufność z uwierzytelnianiem, więc zmodyfikowany szyfrogram nie przejdzie weryfikacji. PBKDF2 podnosi koszt testowania każdego wzoru lub frazy. Losowy klucz główny oznacza, że zmiana wzoru wymaga ponownego opakowania jednego klucza zamiast ponownego szyfrowania każdego pliku. Ochrona danych w Keychain strzeże lokalnych rekordów soli i odzyskiwania, a aplikacja otwarcie przyznaje, że szyfrowanie symetryczne odbywa się w pamięci procesowej.

Razem te warstwy tworzą obronę wielowarstwową, ale nie wszystkie są niezależnymi barierami. Odgadnięty wzór można sprawdzić względem nazwy pliku indeksu i uwierzytelnienia AES-GCM, a przejęte, odblokowane urządzenie może obserwować klucze lub tekst jawny w procesie aplikacji. Dlatego architektura zależy od entropii poświadczeń, kosztu PBKDF2, ochrony urządzenia w iOS i poprawnej obsługi uwierzytelnionego szyfrowania, a nie tylko od siły samego AES.

AES-256-GCM: Szyfrowanie plików

Każde zdjęcie, film i dokument przechowywane w Vaultaire są szyfrowane AES-256-GCM, czyli Advanced Encryption Standard z 256-bitowym kluczem w trybie Galois/Counter. Vaultaire używa AES-GCM także dla indeksów sejfu, nagłówków plików, miniatur i kopert kluczy. Algorytm i rozmiar klucza są ustandaryzowane; bezpieczeństwo Vaultaire nadal zależy od obsługi wartości jednorazowych, zarządzania kluczami, siły poświadczeń i poprawności implementacji.

Wartość „256” w AES-256 odnosi się do długości klucza w bitach. Klucz 256-bitowy ma 2²⁵⁶ możliwych wartości. Dla porównania: jest ich około 10⁸⁰ atomów w obserwowalnym wszechświecie. Gdyby każdy atom był superkomputerem testującym miliard kluczy na sekundę, działającym od Wielkiego Wybuchu, zbadałby mniej niż jedną bilionową z bilionowej części jednego procenta przestrzeni klucza. AES-256 nie będzie brutalnie wymuszane. Nie dzisiaj. Nie w tym stuleciu. Nie zanim gwiazdy się wypalą.

Dlaczego tryb GCM ma znaczenie

AES to szyfr blokowy; szyfruje dane w 128-bitowych fragmentach. “mode” określa sposób łączenia tych fragmentów. GCM (tryb Galois/Counter) zapewnia dwie funkcje, których nie zapewniają prostsze tryby, takie jak CBC: szyfrowanie równoległe i wbudowane uwierzytelnianie.

Element uwierzytelniający jest krytyczny. GCM generuje znacznik kryptograficzny dla każdego zaszyfrowanego pliku. Ta etykieta pełni funkcję plomby zabezpieczającej. Jeśli nawet pojedynczy bit szyfrogramu zostanie zmodyfikowany, przez złośliwego aktora lub uszkodzony sektor dysku, znacznik uwierzytelniający nie będzie zgodny i deszyfrowanie zakończy się niepowodzeniem. Nie otrzymasz uszkodzonych danych. Otrzymujesz wyraźny sygnał, że coś jest nie tak. Ta właściwość nazywa się szyfrowaniem uwierzytelnionym i zapobiega całej klasie ataków, w których przeciwnik modyfikuje zaszyfrowane dane w celu manipulowania odszyfrowanymi danymi wyjściowymi.

PBKDF2: Wyprowadzanie klucza

Vaultaire wyprowadza różne klucze do różnych zadań. Wzór i sól urządzenia z Keychain trafiają do PBKDF2-HMAC-SHA512, które w 600 000 iteracjach wyprowadza lokalny klucz sejfu. Deterministyczne wyprowadzenie ze wzoru daje oddzielny klucz kopii zapasowej w chmurze. Znormalizowana fraza odzyskiwania przechodzi 800 000 iteracji PBKDF2, które dają klucz koperty odzyskiwania. Żadne z tych wyprowadzeń nie zamienia ludzkiego poświadczenia w 256 bitów entropii tylko dlatego, że wynik ma 256 bitów.

Jak PBKDF2 chroni Twój wzór

Podstawowa idea PBKDF2 to celowy wysiłek obliczeniowy. Funkcja bierze serializowany wzór lub znormalizowaną frazę i wykonuje setki tysięcy iteracji HMAC-SHA512. Uprawniony użytkownik płaci ten koszt raz przy każdej próbie odblokowania lub odzyskania. Atakujący płaci go za każdego kandydata, choć rzeczywiste tempo zgadywania zależy od równoległości, sprzętu i implementacji.

Vaultaire ustawia PBKDF2 na 600 000 iteracji dla kluczy wyprowadzanych ze wzorów. Każda próba jest przez to droższa, ale rzetelna ocena ataku musi uwzględniać zmierzony czas na kandydata i założenia co do sprzętu. Przy dokładnie 1 ms na kandydata 1 000 000 000 prób wykonywanych po kolei zajmuje około 11,6 dnia, a nie lat. Wynik 256-bitowy nie rozszerza entropii przewidywalnego wzoru.

Lokalne wyprowadzenie ze wzoru używa jednej kryptograficznie losowej soli urządzenia, zapisanej jako element Keychain WhenUnlockedThisDeviceOnly. Sól nie jest tajna i wszystkie sejfy na tym urządzeniu używają tej samej. Zapobiega to użyciu tabeli przygotowanej dla jednego urządzenia na innym urządzeniu z inną solą, ale nie zmusza atakującego do rozpoczynania od nowa dla każdego sejfu na tym samym urządzeniu.

AES-256-GCM: ochrona metadanych

Szyfrowanie zawartości pliku nie wystarczy. Nazwy plików, daty utworzenia, wymiary miniatur i struktura sejfu to metadane, a metadane mogą być równie odkrywcze jak same dane. Plik o nazwie “tax-return-2025.pdf” informuje atakującego dokładnie, co znajduje się w środku, nawet jeśli zawartość jest zaszyfrowana. Sygnatura czasowa pokazuje, kiedy korzystałeś ze sejfu. Rozmiar miniatury pokazuje, czy jest to zdjęcie, czy film.

Vaultaire chroni te metadane za pomocą AES-256-GCM, a nie ChaCha20. Nazwy plików i typy MIME są kodowane w zaszyfrowanych nagłówkach plików. Zaszyfrowany indeks sejfu zawiera rekordy plików, daty, informacje o rozmiarze, układ przechowywania i opakowany klucz główny. Dane miniatur są również szyfrowane losowym kluczem głównym.

Dlaczego uwierzytelnione szyfrowanie metadanych?

Metadane wymagają integralności i poufności. AES-GCM tworzy znacznik uwierzytelniający dla każdej zaszyfrowanej wartości, dzięki czemu Vaultaire może odrzucić zmodyfikowany nagłówek, indeks, miniaturę lub kopertę zamiast przyjmować tekst jawny kontrolowany przez atakującego. Projekt celowo używa jednej konstrukcji uwierzytelnionego szyfrowania w tych formatach przechowywania i nie twierdzi, że zyskuje na różnorodności kryptograficznej, której ta implementacja nie ma.

Ten sam szyfr nie oznacza ślepego ponownego użycia tego samego klucza lub tej samej wartości jednorazowej. Klucz sejfu chroni indeks i opakowuje losowy klucz główny; klucz główny chroni materiał pliku. CryptoKit tworzy uwierzytelnione zapieczętowane pakiety z nowymi wartościami jednorazowymi, a format strumieniowy Vaultaire wyprowadza osobną wartość jednorazową dla każdego kolejnego fragmentu. Właściwe gwarancje dają separacja kluczy, dyscyplina wartości jednorazowych i uwierzytelnienie, a nie z drugiego szyfru metadanych.

Architektura zerowej wiedzy

Oto pytanie, które warto zadać w odniesieniu do dowolnej aplikacji zabezpieczającej: co się stanie, jeśli firma, która za nią stoi, zostanie zhakowana, wezwana do sądu lub po prostu stanie się złośliwa?

W przypadku większości aplikacji odpowiedź jest niewygodna. Przechowują Twoje dane, klucze lub jedno i drugie. Nakaz sądu nakazuje im je oddać. Naruszenie danych ujawnia to. Dostęp do niego uzyskuje nieuczciwy pracownik. Bezpieczeństwo aplikacji ’ jest tak silne, jak bezpieczeństwo operacyjne firmy ’, a historia pokazuje, że firmy są regularnie naruszane.

Vaultaire nie obsługuje konta ani usługi przechowywania, która otrzymuje Twój wzór, tajne frazy, klucze odszyfrowujące lub czytelną zawartość sejfu. Szyfrowanie i deszyfrowanie odbywa się w procesie aplikacji na Twoim urządzeniu. Kiedy kopia zapasowa iCloud jest włączona, aplikacja wysyła uwierzytelniony szyfrogram do prywatnej bazy danych CloudKit, a nie do usługi sejfu kontrolowanej przez Vaultaire.

Co oznacza wiedza zerowa w praktyce

Jeśli organ ścigania prześle Vaultaire nakaz sądowy z żądaniem jawnej zawartości sejfu, firma nie posiada wzoru, frazy odzyskiwania, klucza sejfu, klucza kopii zapasowej ani klucza głównego potrzebnych do jego odszyfrowania. Zaszyfrowane rekordy iCloud są w prywatnej bazie danych CloudKit użytkownika. Na urządzeniu materiał odzyskiwania jest jednak przechowywany w zaszyfrowanej bazie danych w Keychain, a klucze symetryczne istnieją w pamięci aplikacji, gdy CryptoKit szyfruje lub deszyfruje otwarty sejf.

Ta granica dostawcy jest właściwością architektury, a nie obietnicą, że każda część środowiska klienta znajduje się poza modelem zaufania. Vaultaire nie ma po stronie serwera klucza deszyfrującego, który mógłby przekazać do rutynowego odzyskania sejfu. Dostarczona aplikacja, iOS, odblokowane urządzenie i implementacja kryptograficzna mogą nadal przetwarzać czytelne dane i należy im odpowiednio ufać.

Keychain i granica procesu aplikacji

Secure Enclave firmy Apple może chronić obsługiwane klucze prywatne i uczestniczy w części architektury bezpieczeństwa platformy, ale jego publiczne API nie przyjmują dowolnego klucza symetrycznego wyprowadzonego przez PBKDF2 ani nie wykonują operacji AES-GCM Vaultaire na plikach wewnątrz koprocesora. Dlatego Vaultaire nie opisuje szyfrowania sejfu jako AES w Secure Enclave.

Vaultaire używa zwykłych elementów iOS Keychain typu hasło ogólne dla losowej soli urządzenia, zaszyfrowanej bazy danych odzyskiwania i losowego klucza chroniącego tę bazę danych. Te elementy korzystają z klasy dostępności WhenUnlockedThisDeviceOnly. Keychain i ochrona danych tworzą znaczącą granicę urządzenia, szczególnie gdy telefon jest zablokowany, ale ta architektura różni się od nieeksportowalnego klucza w Secure Enclave.

Kiedy rysujesz wzór, CommonCrypto wyprowadza klucz sejfu w procesie aplikacji. CryptoKit i CryptoEngine Vaultaire używają następnie w tym procesie bajtów klucza symetrycznego, aby uwierzytelnić i odszyfrować indeks, rozpakować klucz główny i przetwarzać pliki. Aplikacja kasuje stan aktywny po zablokowaniu, ale wystarczająco uprzywilejowany atakujący obserwujący odblokowaną sesję ma inne możliwości niż analityk, który ma tylko szyfrogram z zablokowanego urządzenia.

System operacyjny po jailbreaku lub przejęty w inny sposób może atakować wprowadzane wzory, pamięć aplikacji, odszyfrowane podglądy, eksporty lub ekran. Vaultaire zaleca aktualny iPhone bez jailbreaka, ponieważ projekt opiera się na izolacji procesów w iOS, Keychain i Ochronie danych. Nie twierdzi, że po przejęciu uprawnień roota klucze symetryczne otwartego sejfu pozostają niedostępne.

Wektory inicjujące dla poszczególnych plików

Kiedy szyfrujesz dwa identyczne pliki tym samym kluczem, naiwna implementacja dałaby identyczny szyfrogram. To jest problem. Osoba atakująca, która widzi dwa identyczne zaszyfrowane obiekty blob, wie, bez odszyfrowywania czegokolwiek, że dwa oryginalne pliki są takie same. W sejfie pełnym zdjęć tego rodzaju analiza wzorów może ujawnić informacje nawet poprzez szyfrowanie.

Vaultaire zapobiega deterministycznemu szyfrogramowi, generując nową kryptograficzną wartość jednorazową dla każdej operacji zapieczętowania AES-256-GCM. Nagłówki plików i zawartość plików są zapieczętowane oddzielnie, a duże pliki korzystają z uwierzytelnionego formatu strumieniowego z losową bazową wartością jednorazową i osobną wartością jednorazową dla każdego kolejnego fragmentu. Dlatego dwie kopie tego samego zdjęcia nie dają tej samej zaszyfrowanej reprezentacji.

Wartości jednorazowe są przechowywane razem z szyfrogramem i nie są tajne; ich wymogiem bezpieczeństwa jest unikalność pod danym kluczem. Vaultaire pobiera 96-bitową wartość jednorazową z kryptograficznego generatora losowego Apple dla każdego pojedynczego szyfrowania i zapisuje bazową wartość jednorazową w nagłówku strumienia. Ryzyko kolizji zależy od liczby szyfrowań jednym kluczem, dlatego implementacja generuje nowe wartości i nie przedstawia rozmiaru 96 bitów jako stałej, dożywotniej gwarancji jeden na 2⁹⁶.

Zarządzanie pamięcią: czyszczenie stanu aktywnego klucza

Częstą awarią oprogramowania zabezpieczającego jest pozostawianie wrażliwych danych w pamięci, gdy nie są już potrzebne. Klucze szyfrujące, wygenerowane hasła i odszyfrowane dane mogą pozostać w pamięci RAM długo po tym, jak aplikacja zakończy ich używanie. Narzędzia śledcze mogą zrzucać pamięć urządzenia i wyszukiwać te pozostałości; to technika znana jako atak zimnego rozruchu lub analiza zrzutu pamięci.

Vaultaire ogranicza czas dostępności stanu aktywnego klucza i odszyfrowanych danych interfejsu. Gdy aplikacja się blokuje lub sesja się kończy, kod wykonuje kilka ścieżek czyszczenia:

• Stan aktywnego sejfu jest usuwany. Aplikacja usuwa bieżącą sesję klucza sejfu i wymaga ponownego odblokowania, zanim pokaże zawartość sejfu.
• Obiekty kluczy czyszczą własne bufory. Bezpieczne kontenery bajtów w Vaultaire nadpisują swoje bufory, gdy są zwalniane.
• Klucz główny w pamięci podręcznej jest unieważniany. Odszyfrowany klucz główny przechowywany dla otwartego indeksu jest odrzucany na odpowiednich ścieżkach blokady i resetowania pamięci podręcznej.
• Odszyfrowane pamięci podręczne interfejsu są czyszczone tam, gdzie Vaultaire je kontroluje. Czyszczenie miniatur i podglądów zmniejsza resztkowy stan aplikacji, ale nie obejmuje każdej kopii utworzonej przez Swift, iOS lub inny proces.

Następnym razem, gdy Vaultaire otworzy się w stanie zablokowanym, narysujesz wzór, a aplikacja ponownie wyprowadzi klucz sejfu, zanim będzie mogła uwierzytelnić indeks i rozpakować klucz główny. To jest czyszczenie sesji, a nie twierdzenie, że każda przejściowa kopia pamięci została poddana sprawdzalnemu wieloprzebiegowemu czyszczeniu ani że zniszczono odwołanie do klucza w Secure Enclave. Po awarii iOS odzyskuje proces, ale kod czyszczący nie może się uruchomić po każdym nagłym zakończeniu.