Co to jest szyfrowanie zero-knowledge? Prosty przewodnik
Szyfrowanie zero-knowledge oznacza, że dostawca nie może uzyskać dostępu do Twoich danych.
Szyfrowanie z wiedzą zerową to architektura ograniczona do dostawcy, w której usługa nie przechowuje klucza potrzebnego do odszyfrowania przechowywanych treści użytkownika. W przeciwieństwie do standardowego szyfrowania w chmurze, w którym dostawca kontroluje klucz zawartości, szyfrowanie po stronie klienta może zachować tę funkcję na urządzeniach użytkowników. Żądanie prawne, naruszenie lub informacja poufna mogą w dalszym ciągu ujawnić zaszyfrowany tekst, dane dotyczące konta, dane o ruchu lub inne metadane przechowywane przez dostawcę. Wytyczne NIST dotyczące zarządzania kluczami sprawiają, że przechowywanie kluczy jest centralnym punktem dostępu, ale aplikacja kliencka, system operacyjny i odblokowane urządzenie pozostają częścią granicy zaufania.
Jak działa szyfrowanie zero-knowledge
Najprostsza analogia: sejf hotelowy, w którym tylko Ty ustawiasz kombinację, a hotel nigdy jej nie poznaje. Jeśli zapomnisz kombinacji, hotel nie może otworzyć dla Ciebie sejfu. To nie jest wada projektu. To jest projekt.
W kategoriach technicznych szyfrowanie zero-knowledge działa w trzech krokach:
Wyprowadzenie klucza na urządzeniu. Użytkownik podaje dane uwierzytelniające, takie jak hasło, hasło lub wzór. Funkcja wyprowadzania klucza na podstawie hasła łączy go z solą w celu utworzenia klucza na urządzeniu użytkownika. Dobrze odseparowany projekt może wykorzystać ten klucz do odblokowania losowego klucza szyfrowania treści zamiast szyfrowania każdego pliku bezpośrednio przy użyciu ludzkich danych uwierzytelniających.
Szyfrowanie przed transmisją. Wszystkie dane są szyfrowane na urządzeniu przy użyciu wyprowadzonego klucza, zanim opuszczą urządzenie, by trafić do przechowywania w chmurze lub kopii zapasowej. Zaszyfrowane dane (szyfrogramy) są tym, co jest przesyłane.
Dostawca nie otrzymuje klucza zawartości w postaci zwykłego tekstu. Klucze treści muszą koniecznie znajdować się w pamięci klienta podczas użytkowania i mogą być również przechowywane lokalnie lub zdalnie w uwierzytelnionych, zaszyfrowanych kopertach. Dostawca może przechowywać zaszyfrowany tekst i opakowane klucze bez przechowywania sekretu użytkownika potrzebnego do ich otwarcia. Metadane konta, ruchu, rozmiaru rekordu i czasu mogą nadal pozostać widoczne.
Ograniczenie krytyczne: jeśli użytkownik utraci wszystkie ważne dane uwierzytelniające i ścieżki odzyskiwania, zaszyfrowana zawartość stanie się niedostępna. Odzyskiwanie może nadal istnieć, ale należy wyjaśnić jego kluczową opiekę. Jeśli samo zresetowanie poczty e-mail przywróci czytelną treść bez zatwierdzenia starego urządzenia, frazy odzyskiwania, klucza odzyskiwania lub równoważnego sekretu przechowywanego przez użytkownika, dostawca zachował skuteczną drogę z powrotem do zwykłego tekstu.
Szyfrowanie zero-knowledge a inne rodzaje szyfrowania
Termin „szyfrowanie" pojawia się w materiałach marketingowych niemal każdej usługi w chmurze. Różnice między typami są znaczące.
| Typ | Kto posiada klucz | Dostawca może odczytać dane | Przeżywa naruszenie dostawcy | Przykład |
|---|---|---|---|---|
| Brak szyfrowania | Nie dotyczy | Tak | Nie | Dropbox (standardowy poziom) |
| Szyfrowanie w tranzycie (TLS) | Dostawca | Tak (w spoczynku na jego serwerach) | Nie | Google Photos |
| Szyfrowanie po stronie serwera w spoczynku | Dostawca | Tak (posiada klucz deszyfrujący) | Częściowo (zależy od zakresu naruszenia) | iCloud (standard) |
| Kompleksowe szyfrowanie platformy | Urządzenia klienckie i system odzyskiwania konta | Nie poprzez normalną ścieżkę serwisową | Zależy od klienta, odzyskiwania i udostępnienia metadanych | iCloud z zaawansowaną ochroną danych |
| Szyfrowanie po stronie klienta w ciemno przez dostawcę | Ścieżka odzyskiwania kontrolowana przez klienta i użytkownika | Brak klucza zawartości w postaci zwykłego tekstu przechowywanego przez dostawcę | Treść może pozostać zaszyfrowana; metadane i tekst zaszyfrowany mogą nadal wyciekać | Szyfrowane skarbce i systemy kopii zapasowych |
Różnica między „szyfrowaniem w spoczynku" a „szyfrowaniem zero-knowledge" jest najczęściej mylona. Przy szyfrowaniu w spoczynku dostawca szyfruje Twoje dane na swoich serwerach przy użyciu kontrolowanych przez siebie kluczy. Chroni to przed fizyczną kradzieżą sprzętu serwerowego. Nie chroni przed odczytaniem Twoich danych przez dostawcę, wezwaniem sądowym dotyczącym danych i kluczy, ani zagrożeniem wewnętrznym. Dostawca posiada zdolność deszyfrowania.
W przypadku szyfrowania po stronie klienta ślepego dostawcy usługa nie otrzymuje klucza zawartości w postaci zwykłego tekstu za pośrednictwem udokumentowanego protokołu. Przechowywany tekst zaszyfrowany może pozostać niejasny dla tego dostawcy, podczas gdy oprogramowanie klienckie, ścieżka odzyskiwania, metadane konta i kanał dostarczania oprogramowania nadal wymagają zaufania i przeglądu.
Dlaczego szyfrowanie zero-knowledge ma znaczenie
Naruszenia danych dotykają co roku miliardy rekordów
Centrum zasobów dotyczących kradzieży tożsamości zgłosiło w 2023 r. 3205 przypadków naruszenia bezpieczeństwa danych w Stanach Zjednoczonych, które dotknęły około 353 mln osób. Gdy dostawca przechowuje klucze treści, jedno naruszenie może ujawnić zarówno przechowywane dane, jak i ścieżkę do ich odszyfrowania. Szyfrowanie na ślepo dostawcy oddziela te zasoby: naruszenie serwera może w dalszym ciągu ujawnić zaszyfrowany tekst i metadane, ale nie klucz zawartości w postaci zwykłego tekstu przechowywany przez dostawcę. Zgadywanie poświadczeń i naruszenie bezpieczeństwa klienta pozostają odrębnymi zagrożeniami.
Przymus prawny jest realnym zagrożeniem
Dostawcy mogą być zobowiązani do ujawnienia przechowywanych przez siebie danych. Projekt ślepy na dostawcę może ograniczyć tę odpowiedź do tekstu zaszyfrowanego i dostępnych metadanych konta, ruchu, rozliczeń lub usług, ponieważ dostawca nie posiada klucza zawartości w postaci zwykłego tekstu. To, czy inna strona może uzyskać dane uwierzytelniające użytkownika, wykorzystać klienta lub wymusić ujawnienie, to osobna kwestia. Firma Apple wprowadziła zaawansowaną ochronę danych w iOS 16.2 jako opcjonalne rozszerzenie kompleksowego szyfrowania dla iCloud dane.
„Zaufaj nam" nie jest architekturą bezpieczeństwa
Szyfrowanie po stronie serwera opiera się na kluczach i zasadach kontrolowanych przez dostawcę. Szyfrowanie na ślepo przez dostawcę zmienia sposób przechowywania klucza, więc w udokumentowanej ścieżce usługi brakuje klucza zawartości w postaci zwykłego tekstu. Jest to silniejsza granica architektoniczna, ale jej siła nadal zależy od prawidłowego kodu klienta, dostarczania uwierzytelnionego oprogramowania, odzyskiwania dźwięku, bezpiecznych urządzeń i implementacji zgodnej ze specyfikacją.
Standard NIST stojący za kryptografią
AES-GCM został znormalizowany przez Narodowy Instytut Standardów i Technologii w SP 800-38D (2007). Sam AES został wybrany przez NIST w drodze publicznego konkursu w 2001 roku. „256” w AES-256 odnosi się do klucza 256-bitowego. Wyczerpujące wyszukiwanie równomiernie losowego klucza jest niewykonalne obliczeniowo, ale ludzkie hasło lub wzór może zapewnić znacznie mniejszą entropię, nawet jeśli funkcja wyprowadzania klucza zwraca 256 bitów.
GCM (tryb Galois/licznik) dodaje uwierzytelnione szyfrowanie, co oznacza, że proces deszyfrowania wykrywa wszelkie manipulacje przy szyfrogramie. Jeśli zostanie zmieniony choćby jeden bit zaszyfrowanych danych, deszyfrowanie kończy się niepowodzeniem zamiast produkcji uszkodzonych danych. Uniemożliwia to atakującym manipulowanie zaszyfrowanymi danymi bez wykrycia.
PBKDF2 (Funkcja 2 wyprowadzania klucza na podstawie hasła), określona w RFC8018, konwertuje dane uwierzytelniające dostarczone przez człowieka na materiał klucza o stałej długości poprzez wielokrotne wywołania funkcji pseudolosowej. Większa liczba iteracji zwiększa koszt każdego odgadnięcia. Nie dodają entropii do przewidywalnego wzorca lub hasła, więc wybór danych uwierzytelniających i weryfikacja offline nadal mają znaczenie.
Jak Vaultaire wdraża separację klucza dostawcy
Vaultaire’a to zaszyfrowany skarbiec po stronie klienta iPhone. W sensie produktu, często reklamowanym jako „wiedza zerowa”, jego węższe udokumentowane twierdzenie jest takie, że Wraxle nie otrzymuje zawartości skarbca w postaci zwykłego tekstu ani kluczy potrzebnych do jej odszyfrowania. Oto jak działają implementacja i pozostałe granice zaufania w każdej warstwie.
Wyprowadzenie klucza. Użytkownik rysuje wzór na siatce 5x5 składającej się z 25 punktów. PBKDF2-HMAC-SHA512 łączy tę sekwencję w jednym urządzeniu Keychain sól dla 600 000 iteracji, aby uzyskać 256-bitowy klucz skarbca. Klucz skarbca uwierzytelnia zaszyfrowany indeks i otacza oddzielny losowy 256-bitowy klucz główny. Informacje dotyczące odzyskiwania, w tym wzorzec, są przechowywane w pliku AES-GCM zaszyfrowane Keychain bazy danych, a nie plików zwykłego tekstu lub konta Vaultaire.
Szyfrowanie plików. Każdy importowany plik jest szyfrowany za pomocą AES-256-GCM pod losowym kluczem głównym. CryptoKit tworzy uwierzytelnione zapieczętowane pudełka ze świeżymi wartościami jednorazowymi, a format przesyłania strumieniowego wyprowadza odrębną wartość jednorazową dla każdej zamówionej porcji.
Szyfrowanie metadanych. Nazwy plików, MIME chronione są także typy, daty, rekordy indeksu i dane miniatur AES-256-GCM. Vaultaire nie używa ChaCha20 do metadanych skarbca.
Zarządzanie kluczami. Vaultaire przechowuje sól urządzenia i zaszyfrowaną bazę danych odzyskiwania w zwykły sposób iOS Keychain elementy z hasłem ogólnym chronione za pomocą WhenUnlockedThisDeviceOnly klasa dostępności. Klucze skarbca pochodzące ze wzorców i losowe klucze główne są przetwarzane w pamięci aplikacji CryptoKit. Blokowanie usuwa stan aktywnego klucza, ale Swift i iOS nie zapewniają gwarancji, że każda kopia przejściowa zostanie nadpisana.
Odkrycie skarbca. Zwykły interfejs nie wyświetla listy skarbców. W formacie lokalnym przechowywany jest dokładnie 1 zaszyfrowany plik indeksu dla każdego skarbca, a kod obsługi może wyliczyć te pliki. Osoba mająca dostęp do kontenera aplikacji może zatem policzyć zaszyfrowane indeksy, chociaż nazwy plików nie ujawniają wzorców, nazw ani zawartości zwykłego tekstu. Zobacz całość architekturę bezpieczeństwa i wyjaśnienie szyfrowania wzorców.
Jak sprawdzić, czy aplikacja używa prawdziwego szyfrowania zero-knowledge
Zacznij od trzech szybkich testów, a następnie zweryfikuj opublikowaną architekturę:
Test zapomnienia hasła. Jeśli samo resetowanie poczty e-mail przywraca czytelne dane, zapytaj, który mechanizm udostępniany przez dostawcę odzyskał skuteczny klucz zawartości. Frazy odzyskiwania przechowywane przez użytkownika, zatwierdzanie starego urządzenia i resetowanie kontrolowane przez dostawcę to różne projekty.
Test nowego urządzenia. Jeśli nowe urządzenie przywróci czytelną zawartość, zidentyfikuj tajne lub zaufane urządzenie, które je autoryzowało. Samo logowanie na konto sugeruje ścieżkę odzyskiwania kontrolowaną przez dostawcę; fraza odzyskiwania oraz zaszyfrowane rekordy kopii zapasowych mogą zachować separację klucza dostawcy.
Test konta. Adres e-mail lub numer telefonu łączy tożsamość z metadanymi usługi, ale sam w sobie nie dowodzi, że dostawca może odszyfrować treść. Sprawdź hierarchię kluczy, projekt odzyskiwania, kod klienta lub audyt, zasady dotyczące metadanych oraz to, czy uwierzytelniony tekst zaszyfrowany umożliwia weryfikację danych uwierzytelniających w trybie offline.
Testy te są filtrami, a nie dowodem bezpieczeństwa. Spójna specyfikacja powinna zawierać nazwę klucza zawartości, klucza odblokowującego, soli, parametrów wyprowadzania, formatu uwierzytelnionego szyfrowania, reguł jednorazowych, kopert odzyskiwania, lokalnego magazynu tajnych danych, metadanych w chmurze i miejsca, w którym istnieją klucze w postaci zwykłego tekstu. Niezależna recenzja jest mocniejszym dowodem niż etykieta produktu.
Najczęściej zadawane pytania
Czy szyfrowanie zero-knowledge to to samo co szyfrowanie end-to-end?
Pokrywają się, ale nie są identyczne. Szyfrowanie end-to-end (E2EE) oznacza, że dane są szyfrowane na urządzeniu nadawcy i odszyfrowywane tylko na urządzeniu odbiorcy. Szyfrowanie zero-knowledge oznacza, że dostawca nie może uzyskać dostępu do danych. Usługa może być szyfrowana end-to-end bez bycia zero-knowledge, jeśli dostawca wygenerował lub miał dostęp do kluczy w pewnym momencie. Szyfrowanie zero-knowledge jest surowszym standardem.
Co się stanie, jeśli zgubię hasło przy szyfrowaniu zero-knowledge?
Twoje dane staną się trwale niedostępne, jeśli utracone zostaną wszystkie ważne dane uwierzytelniające i koperty odzyskiwania. Kontrolowany przez dostawcę reset lub klucz główny osłabiłby granicę dostawcy, dlatego odzyskiwanie należy zaplanować osobno. Vaultaire’a generuje niestandardową frazę składającą się z 9 oddzielnych słów, której pochodny klucz odzyskiwania otwiera zaszyfrowaną kopertę z kluczem skarbca. Fraza nie regeneruje ani nie koduje klucza, a przywracanie nowego urządzenia również wymaga odpowiedniego zaszyfrowania CloudKit zapisy.
Czy organy ścigania mogą uzyskać dostęp do danych zaszyfrowanych zero-knowledge?
Dostawca może być zmuszony do ujawnienia przechowywanego tekstu zaszyfrowanego oraz przechowywanych przez siebie metadanych konta, ruchu, rozliczeń lub usług. Bez klucza zawartości w postaci zwykłego tekstu, dostawca ten nie może użyć swojej normalnej ścieżki usług do odszyfrowania treści. Wykorzystywanie urządzenia, odkrywanie danych uwierzytelniających, kopie odzyskiwania i przymusowe ujawnianie informacji to odrębne sposoby, których legalność i skuteczność różnią się w zależności od jurysdykcji i faktów.
Czy szyfrowanie zero-knowledge jest wolniejsze niż zwykłe szyfrowanie?
AES-256-GCM wydajność nie zależy od tego, kto trzyma klucz. Wyprowadzanie na podstawie hasła dodaje pracy podczas odblokowywania, a czas jego trwania zależy od algorytmu, liczby iteracji, urządzenia i implementacji. Aplikacje powinny mierzyć ten koszt na obsługiwanym sprzęcie i równoważyć czas reakcji z kosztami nałożonymi na każde przypuszczenie w trybie offline.
Czy zero-knowledge oznacza, że aplikacja w ogóle nie zbiera żadnych danych?
Nie koniecznie. Termin ten dotyczy granicy klucza treści dostawcy, a nie każdego przepływu danych. Aplikacja może nadal przetwarzać dane konta, analizy, raporty o awariach, adresy IP, rozmiary rekordów, czas i inne metadane usług. Vaultaire nie wymaga konta tożsamości i twierdzi, że jego analizy oparte na zgodzie wykluczają zawartość skarbca, wzorce, frazy i klucze deszyfrujące; to polityka prywatności opisuje aktualne zasady gromadzenia i przechowywania.
Jak szyfrowanie zero-knowledge wypada w porównaniu z Apple Advanced Data Protection?
Zaawansowana ochrona danych (ADP) firmy Apple wprowadzona w r iOS 16.2 rozszerza szyfrowanie typu end-to-end o dodatkowe iCloud kategorie i korzysta z modelu odzyskiwania konta Apple. Vaultaire domyślnie przechowuje zawartość skarbca lokalnie i nie wymaga konta tożsamości Vaultaire; opcjonalne tworzenie kopii zapasowych, synchronizacja i udostępnianie zaszyfrowane po stronie klienta CloudKit zapisy na koncie Apple użytkownika. Vaultaire oferuje również dostęp do skarbca z oddzielnymi wzorami i tryb przymusu, z limitami przechowywania i odtwarzania opisanymi w jego dokumentacja wiarygodna i zaprzeczająca.
Podsumowanie
Szyfrowanie z wiedzą zerową najlepiej traktować jako żądanie oddzielenia klucza dostawcy: usługa nie przechowuje klucza w postaci zwykłego tekstu potrzebnego do odszyfrowania przechowywanej zawartości. Jest to silniejsze niż szyfrowanie po stronie serwera przy użyciu kluczy kontrolowanych przez dostawcę, ale nie jest twierdzeniem, że klucze istnieją tylko w pamięci, że metadane znikają lub że każdy kompromis dotyczący klienta i urządzenia zostaje pokonany. Oceniaj produkt na podstawie jego kluczowej hierarchii, projektu odzyskiwania, wdrożenia i niezależnej oceny.