Architektura zero-knowledge: serwer nie widzi Twoich plików

Architektura zero-knowledge oznacza, że dostawca usługi nie ma technicznej możliwości odczytania Twoich plików — klucze szyfrowania nigdy nie trafiają na jego serwery, nie ma klucza głównego, nie ma tylnego wejścia, nie jest wymagane żadne „zaufaj nam". Twoja przeglądarka szyfruje pliki za pomocą AES-256-GCM przed przesłaniem, używając klucza wygenerowanego lokalnie, a klucz ten trafia do odbiorcy wyłącznie przez fragment URL po #, którego przeglądarki nigdy nie przesyłają do serwerów. Nawet na podstawie ważnego nakazu sądowego dostawca może dostarczyć tylko zaszyfrowany tekst. To model stosowany przez Tresorit, Proton, SwissTransfer i HexaTransfer — matematycznie różny od „szyfrowania danych w spoczynku".

Dowód tkwi w tym, co serwer może dostarczyć

Najprostszy test zero-knowledge: co firma mogłaby przekazać, gdyby była do tego zmuszona? W tradycyjnym przechowywaniu w chmurze (Google Drive, Dropbox, OneDrive) odpowiedź brzmi: Twoje pliki, jako czysty tekst. Raport przejrzystości Google z 2023 roku pokazuje, że spełnili 83% wniosków rządowych ze Stanów Zjednoczonych, dostarczając treści użytkowników wszędzie tam, gdzie było to wymagane prawem. To nie jest niedopatrzenie w zabezpieczeniach Google — tak działa ta architektura.

Przy zero-knowledge firma może dostarczyć:

Zaszyfrowane bloki plików (bezużyteczne bez klucza)
Metadane konta (e-mail, IP rejestracji)
Adresy IP przesyłania i pobierania, znaczniki czasu
Informacje o płatności, jeśli dotyczy

Nie może dostarczyć nazw plików, zawartości, tożsamości odbiorcy ani kluczy deszyfrujących. Nie dlatego, że odmawia — bo ich po prostu nie ma.

Sztuczka z fragmentem URL wyjaśniona dokładnie

Kluczowym ruchem technicznym jest użycie fragmentu URL jako ukrytego kanału klucza. Gdy przeglądarka żąda https://hexatransfer.com/d/xyz789#k=BASE64KEY, wysyła do serwera tylko GET /d/xyz789. Fragment pozostaje na pasku adresu przeglądarki. JavaScript wywołuje wówczas window.location.hash, by odczytać klucz, i przekazuje go do crypto.subtle.decrypt().

Ten mechanizm zapoczątkował Mega.nz około 2013 roku, a Firefox Send go udoskonalił, zanim Mozilla zamknęła go w 2020 roku. Wzorzec jest teraz standardem. Logi po stronie serwera — w tym logi dostępu nginx lub Caddy — nigdy nie przechwytują fragmentu, ponieważ RFC 3986 HTTP definiuje go jako wyłącznie po stronie klienta.

Dostawca mógłby teoretycznie rejestrować fragment przez JavaScript po stronie klienta, dlatego usługi zero-knowledge publikują kod klienta do wglądu i często dostarczają go jako podpisane statyczne zasoby serwowane z osobnego źródła.

Dlaczego różni się to od „szyfrowania danych w spoczynku"

Każdy dostawca chmury szyfruje pliki w spoczynku — to minimalna wymagana funkcja, zazwyczaj wymagana przez certyfikaty SOC 2 Type II i ISO 27001. Jednak „szyfrowanie w spoczynku" z kluczami posiadanymi przez dostawcę oznacza, że szyfrowanie jest niewidoczne dla atakujących kradnących dyski i niewidoczne dla Ciebie w tym sensie, że dostawca odszyfrowuje automatycznie na żądanie.

Zero-knowledge odwraca zarządzanie kluczami: Ty posiadasz klucz, dostawca posiada zaszyfrowany tekst. Dostawca nic nie zyska na deszyfrowaniu, ponieważ nie może tego zrobić. Ma to znaczenie w trzech konkretnych scenariuszach zagrożeń:

Nieuczciwy pracownik. Pracownik dostawcy z dostępem do bazy danych widzi tylko zaszyfrowany tekst.
Żądania rządowe. Żądania na podstawie art. 48 RODO oraz US CLOUD Act mogą nakazać ujawnienie, ale nie można ujawnić tego, czego się nie posiada.
Naruszenia serwera. Naruszenie LastPass z 2021 roku ujawniło zaszyfrowane skarbce; słabe hasła główne nadal zostały złamane, ale projekt zero-knowledge zapobiegł masowemu ujawnieniu tekstu jawnego.

Co jest szyfrowane, co jest metadanymi

Naiwna implementacja szyfruje zawartość pliku, ale pozostawia widoczne nazwy plików, rozmiary i strukturę folderów. Prawdziwe zero-knowledge szyfruje też nazwę pliku, zwykle przez dołączenie nagłówka JSON jak {"name": "Q4-finanse.pdf", "type": "application/pdf"} do bajtów pliku przed szyfrowaniem AES-GCM.

Metadane trudne do ukrycia:

Rozmiar pliku — długość zaszyfrowanego tekstu przybliża długość tekstu jawnego. Dopełnianie do stałych kubełków (1 MB, 10 MB, 100 MB, 1 GB) zaciemnia to, ale marnuje przepustowość.
Czas przesyłania — korelowanie znaczników czasu z innymi danymi może ujawniać informacje.
Adresy IP — dostawca widzi, kto przesłał i pobrał plik. Połącz z siecią Tor lub zaufaną siecią VPN, jeśli ma to dla Ciebie znaczenie.

Proton i Tresorit publikują szczegółowe macierze ekspozycji metadanych. SwissTransfer i HexaTransfer przyjmują prostsze podejście: minimalne metadane, krótki czas przechowywania (24 godziny do 7 dni) i brak powiązania z kontem dla bezpłatnych transferów.

Problem uwierzytelniania

Zero-knowledge stwarza wyzwanie: jeśli serwer nie może odszyfrować Twoich plików, jak uwierzytelniać użytkowników, by nieznajomi nie mogli pobierać? Trzy powszechne wzorce:

Uwierzytelnianie przez łącze. Posiadanie URL (i fragmentu) jest autoryzacją. Stosowane przez SwissTransfer, HexaTransfer, Tresorit Send. Proste, działa bez kont.
Łącza chronione hasłem. Fragment URL zawiera sól; rzeczywisty klucz jest wyprowadzany za pomocą PBKDF2 z hasła. Serwer przechowuje weryfikator (skrót klucza), by szybko odrzucać błędne próby.
Zero-knowledge powiązane z kontem. Proton i Tresorit wyprowadzają klucz główny z hasła logowania przez Argon2id, a następnie używają go do odblokowania kluczy per plik przechowywanych w formie zaszyfrowanej na serwerze.

Każde podejście ma swoje kompromisy. Oparte na łączu jest najprostsze, ale ujawnia klucz każdemu, kto zdobędzie URL. Chronione hasłem dodaje drugi czynnik. Powiązane z kontem wymaga zaufania, że kod klienta nie wyeksfiltruje klucza głównego.

Pułapki implementacji, które psują zero-knowledge

Kilka rzeczywistych przypadków wartych poznania:

Podglądy plików po stronie serwera. Jeśli dostawca generuje miniatury lub wyodrębnia tekst do wyszukiwania, potrzebuje tekstu jawnego. Usługi zero-knowledge nie mogą oferować tych funkcji dla zaszyfrowanej zawartości.
Rozwiązywanie konfliktów synchronizacji. Porównywanie zawartości plików między urządzeniami zwykle wymaga tekstu jawnego. Syncthing i Cryptomator obsługują to za pomocą różnic po stronie klienta.
Zestawy SDK analityczne. Skrypty stron trzecich z Google Analytics lub Segment mogą odczytywać window.location.hash w kodzie klienta. Usługi zero-knowledge albo samodzielnie hostują analitykę, albo blokują dostęp do fragmentu.
Resetowanie hasła. Jeśli dostawca może zresetować hasło i nadal zapewnić dostęp do starych plików, musi posiadać klucz odzyskiwania — co łamie zero-knowledge. Proton wyraźnie ostrzega, że resetowanie hasła oznacza utratę zaszyfrowanych danych.

Kto naprawdę dostarcza zero-knowledge

Krótka lista usług z wiarygodnymi deklaracjami zero-knowledge, zweryfikowanymi przez audyty stron trzecich (Cure53, NCC Group, Trail of Bits):

Tresorit — szwajcarska firma, SOC 2 Type II, zero-knowledge synchronizacja plików i Send.
Proton Drive — Szwajcaria, oparty na modelu kryptograficznym Proton Mail.
SwissTransfer — bezpłatny poziom z opcjonalnym E2EE, prowadzony przez Infomaniak.
Mega.nz — Nowa Zelandia, opublikowany biały papier kryptografii.
HexaTransfer — oparty na przeglądarce, bez konta, 10 GB na transfer.

Usługi szyfrowane, ale nie zero-knowledge: Google Drive, Dropbox, OneDrive, Box, iCloud (z wyjątkiem poziomu Advanced Data Protection) i standardowy poziom WeTransfer.

Zastosowanie w praktyce

Przed powierzeniem usłudze wrażliwych plików wykonaj tę listę kontrolną:

Czy polityka prywatności stwierdza, że dostawca nie może odczytać Twoich plików?
Czy istnieje opublikowany biały papier bezpieczeństwa wymieniający AES-256-GCM i KDF?
Czy URL udostępniania zawiera fragment (tekst po #)?
Czy istnieją raporty z audytów stron trzecich z ostatnich 24 miesięcy?
Czy kod klienta jest open source lub przynajmniej audytowalny?

Cztery odpowiedzi twierdzące oznaczają usługę zero-knowledge. Trzy lub mniej — dostawca może widzieć Twoje pliki.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.