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 zerową wiedzą to architektura, w której dostawca usługi 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 zatrzymać ten klucz na urządzeniach użytkowników. Nakaz prawny, włamanie lub osoba z wewnątrz mogą w dalszym ciągu ujawnić szyfrogram, dane dotyczące konta, dane o ruchu lub inne metadane przechowywane przez dostawcę. Wytyczne NIST dotyczące zarządzania kluczami stawiają przechowywanie kluczy w centrum kontroli 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 poświadczenia, takie jak hasło, fraza hasła 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 poświadczeń.
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 jawnej. 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ć szyfrogram 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 poświadczenia i ścieżki odzyskiwania, zaszyfrowana zawartość stanie się niedostępna. Odzyskiwanie może nadal istnieć, ale należy wyjaśnić, kto przechowuje jego klucze. 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 tekstu jawnego.
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) |
| Szyfrowanie end-to-end 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 jawnej przechowywanego przez dostawcę | Treść może pozostać zaszyfrowana; metadane i szyfrogram mogą nadal wyciekać | Szyfrowane sejfy i systemy kopii zapasowych |
Różnica między „szyfrowaniem w spoczynku” a „szyfrowaniem z zerową wiedzą” 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 jawnej za pośrednictwem udokumentowanego protokołu. Przechowywany szyfrogram 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 bez dostępu dostawcy do kluczy rozdziela te zasoby: naruszenie serwera może w dalszym ciągu ujawnić szyfrogram i metadane, ale nie klucz zawartości w postaci jawnej 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 bez dostępu dostawcy do kluczy może ograniczyć tę odpowiedź do szyfrogramu i dostępnych metadanych konta, ruchu, rozliczeń lub usług, ponieważ dostawca nie posiada klucza zawartości w postaci jawnej. To, czy inna strona może uzyskać poświadczenia użytkownika, wykorzystać klienta lub wymusić ujawnienie, to osobna kwestia. Apple wprowadził Zaawansowaną ochronę danych w iOS 16.2 jako opcjonalne rozszerzenie szyfrowania end-to-end na dane iCloud.
„Zaufaj nam” nie jest architekturą bezpieczeństwa
Szyfrowanie po stronie serwera opiera się na kluczach i zasadach kontrolowanych przez dostawcę. Szyfrowanie bez dostępu dostawcy do kluczy zmienia miejsce przechowywania klucza, więc w udokumentowanej ścieżce usługi brakuje klucza zawartości w postaci jawnej. Jest to silniejsza granica architektoniczna, ale jej siła nadal zależy od prawidłowego kodu klienta, dostarczania uwierzytelnionego oprogramowania, solidnego odzyskiwania, 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 (Password-Based Key Derivation Function 2), określona w RFC8018, konwertuje poświadczenia 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. Iteracje nie dodają jednak entropii do przewidywalnego wzoru lub hasła, więc wybór poświadczeń i weryfikacja offline nadal mają znaczenie.
Jak Vaultaire wdraża separację klucza dostawcy
Vaultaire to sejf na iPhone’a szyfrowany po stronie klienta. W marketingu często nazywa się to „zerową wiedzą”, ale węższe udokumentowane twierdzenie brzmi tak: Wraxle nie otrzymuje zawartości sejfu w postaci jawnej 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ę z solą urządzenia z Keychain w 600 000 iteracjach, aby wyprowadzić 256-bitowy klucz sejfu. Klucz sejfu uwierzytelnia zaszyfrowany indeks i opakowuje oddzielny losowy 256-bitowy klucz główny. Informacje dotyczące odzyskiwania, w tym wzór, są przechowywane w bazie danych Keychain zaszyfrowanej AES-GCM, a nie w plikach z tekstem jawnym ani na koncie Vaultaire.
Szyfrowanie plików. Każdy importowany plik jest szyfrowany za pomocą AES-256-GCM pod losowym kluczem głównym. CryptoKit tworzy uwierzytelnione pakiety sealed box ze świeżymi wartościami jednorazowymi, a format przesyłania strumieniowego wyprowadza odrębną wartość jednorazową dla każdego kolejnego fragmentu.
Szyfrowanie metadanych. Nazwy plików, typy MIME, daty, rekordy indeksu i dane miniatur również chroni AES-256-GCM. Vaultaire nie używa ChaCha20 do metadanych sejfu.
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 sejfu pochodzące ze wzoró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 sejfu. Zwykły interfejs nie wyświetla listy sejfów. Format lokalny tworzy jeden katalog przechowywania na sejf, a kod obsługi może je wyliczyć. Osoba mająca dostęp do kontenera aplikacji może zatem policzyć sejfy, chociaż nazwy plików nie ujawniają wzorów, nazw ani zawartości tekstu jawnego. Zobacz pełną architekturę bezpieczeństwa i wyjaśnienie szyfrowania wzorów.
Jak sprawdzić, czy aplikacja używa prawdziwego szyfrowania zero-knowledge
Zacznij od trzech szybkich testów, a następnie zweryfikuj opublikowaną architekturę:
Test zapomnianego hasła. Jeśli samo resetowanie poczty e-mail przywraca czytelne dane, zapytaj, jaki mechanizm dostawcy odtworzył faktyczny klucz treś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ść, ustal, jaki sekret lub zaufane urządzenie to autoryzowało. Samo logowanie na konto sugeruje ścieżkę odzyskiwania kontrolowaną przez dostawcę; fraza odzyskiwania oraz zaszyfrowane rekordy kopii zapasowej 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 szyfrogram umożliwia weryfikację poświadczeń w trybie offline.
Testy te są filtrami, a nie dowodem bezpieczeństwa. Spójna specyfikacja powinna nazywać klucz treści, klucz odblokowujący, sól, parametry wyprowadzania, format uwierzytelnionego szyfrowania, reguły wartości jednorazowych, koperty odzyskiwania, lokalny magazyn sekretów, metadane w chmurze i miejsca, w których istnieją klucze w postaci jawnej. 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 poświadczenia i koperty odzyskiwania. Kontrolowany przez dostawcę reset lub klucz główny osłabiłby granicę dostawcy, dlatego odzyskiwanie należy zaplanować osobno. Vaultaire generuje własną frazę z dziewięciu słów, której pochodny klucz odzyskiwania otwiera zaszyfrowaną kopertę z kluczem sejfu. Fraza nie regeneruje ani nie koduje klucza, a przywracanie nowego urządzenia również wymaga pasujących zaszyfrowanych rekordów CloudKit.
Czy organy ścigania mogą uzyskać dostęp do danych zaszyfrowanych zero-knowledge?
Dostawca może być zmuszony do ujawnienia przechowywanego szyfrogramu oraz przechowywanych przez siebie metadanych konta, ruchu, rozliczeń lub usług. Bez klucza zawartości w postaci jawnej, dostawca ten nie może użyć swojej normalnej ścieżki usług do odszyfrowania treści. Włamanie do urządzenia, zdobycie poświadczeń, kopie odzyskiwania i wymuszone ujawnienie to odrębne ścieżki, 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?
Wydajność AES-256-GCM 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ć szybkość reakcji z kosztem każdej próby odgadnięcia offline.
Czy zero-knowledge oznacza, że aplikacja w ogóle nie zbiera żadnych danych?
Niekoniecznie. Termin ten dotyczy granicy klucza treści dostawcy, a nie każdego przepływu danych. Aplikacja może nadal przetwarzać dane konta, dane analityczne, raporty o awariach, adresy IP, rozmiary rekordów, czas i inne metadane usług. Vaultaire nie wymaga konta tożsamości. Analityka aplikacji i diagnostyka awarii są domyślnie włączone i można je wyłączyć za pomocą opcji „Udostępniaj błędy anonimowo” w Ustawieniach. Udokumentowana polityka dotycząca zdarzeń nie obejmuje zawartości sejfu, wzorów, fraz i kluczy deszyfrujących; polityka prywatności opisuje aktualne zasady gromadzenia i przechowywania.
Jak szyfrowanie zero-knowledge wypada w porównaniu z Apple Zaawansowana ochrona danych?
Zaawansowana ochrona danych (ADP) firmy Apple, wprowadzona w iOS 16.2, rozszerza szyfrowanie end-to-end na kolejne kategorie danych iCloud i korzysta z modelu odzyskiwania konta Apple. Vaultaire szyfruje zawartość sejfu na urządzeniu i nie wymaga konta tożsamości Vaultaire; kopia zapasowa (domyślnie włączona, można ją wyłączyć), synchronizacja i udostępnianie korzystają z rekordów CloudKit szyfrowanych po stronie klienta na koncie Apple użytkownika. Vaultaire oferuje również dostęp do sejfu z oddzielnymi wzorami i tryb przymusu, z limitami przechowywania i odzyskiwania opisanymi w dokumentacji wiarygodnego zaprzeczenia.
Podsumowanie
Szyfrowanie z zerową wiedzą najlepiej traktować jako twierdzenie o oddzieleniu kluczy od dostawcy: usługa nie przechowuje klucza w postaci jawnej 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ą ani że chroni przed każdym przejęciem klienta lub urządzenia. Oceniaj produkt na podstawie jego hierarchii kluczy, projektu odzyskiwania, implementacji i niezależnej oceny.