Co to jest szyfrowanie end-to-end? Jak chroni twoje zdjęcia
Szyfrowanie end-to-end sprawia, że czytelna zawartość zdjęć i klucze treści w postaci jawnej są niedostępne dla dostawcy pamięci masowej.
Szyfrowanie typu end-to-end (E2EE) to model bezpieczeństwa, w którym tekst jawny jest szyfrowany w jednym autoryzowanym punkcie końcowym i odszyfrowywany w innym. Dostawca magazynu lub dostawcy transportu nie przechowuje klucza zawartości w postaci jawnej. Ta granica chroni zawartość przed bezpośrednim odczytaniem po stronie serwera, ale nie ukrywa każdego elementu metadanych ani nie chroni zaatakowanego punktu końcowego, poświadczeń odzyskiwania, udostępnionego odbiorcy ani aktualizacji złośliwego klienta.
W przypadku przechowywania zdjęć szyfrowanie end-to-end oznacza, że telefon szyfruje zawartość zdjęć przed przesłaniem, a chmura przechowuje szyfrogram, a nie czytelne obrazy. Odszyfrowanie wymaga klucza dostępnego za pośrednictwem autoryzowanego urządzenia lub ścieżki odzyskiwania. Rozmiar pliku, czas, dane konta, relacje udostępniania i inne metadane mogą pozostać widoczne. W tym przewodniku wyjaśniono granice i porównano typowe modele usług.
Jak działa szyfrowanie end-to-end
Główny mechanizm obejmuje trzy etapy: generowanie klucza, szyfrowanie i deszyfrowanie.
Generowanie klucza
Urządzenie użytkownika generuje klucz kryptograficzny. W szyfrowaniu symetrycznym (jak AES-256) ten sam klucz szyfruje i odszyfrowuje. W szyfrowaniu asymetrycznym (jak RSA) klucz publiczny szyfruje, a klucz prywatny odszyfrowuje. Wiele systemów E2EE łączy oba: szyfrowanie asymetryczne wymienia symetryczny klucz sesji, który następnie obsługuje szyfrowanie zbiorcze.
Aplikacje do przechowywania zdjęć korzystają z kilku projektów zarządzania kluczami. Niektóre wyprowadzają klucz pliku bezpośrednio z hasła; mocniejsze projekty warstwowe mogą używać klucza odblokowującego opartego na poświadczeniach, aby opakować losowy klucz pliku. Vaultaire wykorzystuje PBKDF2-HMAC-SHA512, aby wyprowadzić 256-bitowy klucz sejfu na podstawie wzoru 5x5 i soli urządzenia. Ten klucz sejfu uwierzytelnia zaszyfrowany indeks i rozpakowuje oddzielny losowy klucz główny używany do szyfrowania plików.
Szyfrowanie
Tekst jawny (twoje zdjęcie) jest przekształcany w szyfrogram za pomocą klucza szyfrowania i algorytmu szyfrowania. AES-256-GCM to najszerzej używany szyfr symetryczny do tego celu. GCM (Galois/Counter Mode) zapewnia uwierzytelnione szyfrowanie -- zarówno szyfruje dane, jak i generuje znacznik uwierzytelniający, który wykrywa jakiekolwiek manipulacje. Każdy plik otrzymuje unikalny wektor inicjalizacyjny (IV), zapewniając, że identyczne pliki tworzą różny szyfrogram.
Deszyfrowanie
Urządzenie odbiorcy używa tego samego klucza (symetryczny) lub pasującego klucza prywatnego (asymetryczny) do odwrócenia transformacji. Bez prawidłowego klucza szyfrogram jest nieodróżnialny od losowych danych. Nie ma matematycznych skrótów. AES-256 ma 2^256 możliwych kluczy -- więcej niż szacowana liczba atomów w obserwowalnym wszechświecie.
Szyfrowanie end-to-end a inne modele szyfrowania
Nie wszystkie szyfrowania są end-to-end. Różnice określają, kto może uzyskać dostęp do twoich danych.
Szyfrowanie podczas transmisji (TLS/SSL)
Dane są szyfrowane między twoim urządzeniem a serwerem. Serwer odszyfrowuje je po otrzymaniu. Chroni to przed podsłuchiwaniem podczas transmisji, ale pozostawia dane czytelne na serwerze. Każda główna usługa chmurowa używa szyfrowania podczas transmisji. To punkt wyjścia, nie standard.
Szyfrowanie w spoczynku (po stronie serwera)
Serwer szyfruje przechowywane dane za pomocą kluczy, którymi zarządza serwer. Chroni to przed fizyczną kradzieżą sprzętu serwerowego, ale nie przed samym dostawcą usługi, jego pracownikami ani żądaniami prawnymi skierowanymi do dostawcy. iCloud, Google Drive i Dropbox wszystkie używają szyfrowania po stronie serwera w spoczynku. Dostawca trzyma klucze.
Szyfrowanie end-to-end
Dane są szyfrowane w autoryzowanym punkcie końcowym, zanim zostaną odebrane przez dostawcę pamięci masowej. Solidny projekt sprawia, że klucz zawartości w postaci jawnej pozostaje poza rutynowym dostępem dostawcy po stronie serwera, więc włamanie wyłącznie do magazynu lub prawne żądanie dotyczące przechowywanej zawartości daje szyfrogram, a nie czytelne zdjęcia. Dostawca może nadal dostarczać szyfrogram i metadane, dystrybuować oprogramowanie klienckie lub obsługiwać systemy odzyskiwania i udostępniania, które muszą być uwzględnione w modelu zagrożenia.
| Model szyfrowania | Kto trzyma klucze | Dostawca może czytać dane? | Chroni przed dostawcą? |
|---|---|---|---|
| Tylko podczas transmisji (TLS) | Serwer | Tak | Nie |
| W spoczynku (po stronie serwera) | Serwer | Tak | Nie |
| End-to-end | Autoryzowane punkty końcowe lub posiadacze odzyskiwania | Nie z samego przechowywanego szyfrogramu | Chroni zawartość przed kluczami magazynu przechowywanymi przez dostawcę |
| Szyfrowanie po stronie klienta niedostępne dla dostawcy | Klient i udokumentowane ścieżki odzyskiwania | Z założenia brak dostępu do treści w postaci jawnej | Chroni zawartość; metadane i zaufanie klientów pozostają |
Jak usługi przechowywania zdjęć obsługują szyfrowanie
Model szyfrowania różni się znacznie między usługami przechowywania zdjęć. Niektóre reklamują „szyfrowanie” bez określenia modelu, co może wprowadzać użytkowników w błąd, by wierzyli, że ich zdjęcia są E2EE, gdy tak nie jest.
Zdjęcia iCloud
Apple używa szyfrowania podczas transmisji i w spoczynku. Apple domyślnie trzyma klucze szyfrowania. Przy ważnym żądaniu prawnym Apple może dostarczyć dane ze Zdjęć iCloud. Wyjątek: Zaawansowana ochrona danych (ADP) Apple, dostępna od grudnia 2022, dodaje szyfrowanie end-to-end do Zdjęć iCloud. ADP musi być wyraźnie włączone w Ustawieniach. Po włączeniu Apple nie może uzyskać dostępu do danych ze Zdjęć iCloud. Większość użytkowników nie włączyła ADP.
Google Photos
Google używa szyfrowania podczas transmisji i w spoczynku z kluczami po stronie serwera. Google trzyma klucze szyfrowania dla wszystkich danych Google Photos, w tym zawartości Zablokowanego folderu. Google może spełniać prawne żądania danych. Google nie oferuje opcji szyfrowania end-to-end dla Google Photos.
Dropbox
Szyfrowanie podczas transmisji (TLS 1.2+) i w spoczynku (AES-256 z kluczami zarządzanymi przez Dropbox). Dropbox trzyma klucze i może uzyskać dostęp do twoich plików. Dropbox był przedmiotem naruszeń danych (2012, 68 milionów kont). Dropbox Vault (płatna funkcja) dodaje ochronę PIN, ale nie szyfrowanie end-to-end.
OneDrive
Microsoft używa szyfrowania podczas transmisji i w spoczynku z kluczami zarządzanymi przez Microsoft. Microsoft trzyma klucze. OneDrive Personal Vault dodaje weryfikację tożsamości (2FA), ale nie szyfrowanie end-to-end -- Microsoft nadal może uzyskać dostęp do danych. Dla klientów korporacyjnych dostępne są klucze zarządzane przez klienta.
Vaultaire
Szyfrowanie po stronie klienta bez kluczy przechowywanych przez dostawcę. Vaultaire szyfruje zdjęcia i metadane na urządzeniu za pomocą AES-256-GCM przed jakimkolwiek przesłaniem do chmury. Losowy klucz główny szyfruje dane sejfu. Lokalny klucz sejfu wyprowadzony ze wzoru użytkownika i soli urządzenia opakowuje ten klucz główny, podczas gdy oddzielny klucz kopii zapasowej wyprowadzony ze wzoru chroni prywatne rekordy kopii zapasowej CloudKit. Vaultaire nie obsługuje serwera treści ani nie otrzymuje tych kluczy, więc nie może zamienić rekordów CloudKit w tekst jawny. Aplikacja, iOS i odblokowane urządzenie pozostają w granicach zaufania, a na podstawie prawnego żądania nadal można uzyskać metadane konta lub usługi przechowywane przez odpowiedniego dostawcę.
| Usługa | Szyfrowanie podczas transmisji | Szyfrowanie w spoczynku | Szyfrowanie end-to-end | Dostawca może uzyskać dostęp |
|---|---|---|---|---|
| Zdjęcia iCloud (domyślnie) | Tak | Tak (klucze Apple) | Nie | Tak |
| Zdjęcia iCloud (ADP włączone) | Tak | Tak | Tak | Nie |
| Google Photos | Tak | Tak (klucze Google) | Nie | Tak |
| Dropbox | Tak | Tak (klucze Dropbox) | Nie | Tak |
| OneDrive | Tak | Tak (klucze Microsoft) | Nie | Tak |
| Vaultaire | Tak | Tak | Kopia zapasowa szyfrowana po stronie klienta, domyślnie włączona | Brak klucza treści w postaci jawnej; metadane CloudKit pozostają |
Dlaczego szyfrowanie end-to-end ma znaczenie dla zdjęć
Zdjęcia to wyjątkowo wrażliwe dane. Zawierają twarze, lokalizacje (metadane GPS), znaczniki czasu i wizualne zapisy prywatnych chwil. Naruszenie twojej biblioteki zdjęć ujawnia więcej danych osobowych niż prawie każdy inny typ danych.
Naruszenia danych
Gdy usługodawca przechowuje zdjęcia za pomocą kluczy po stronie serwera, naruszenie zarówno miejsca przechowywania, jak i ścieżki zarządzania kluczami może spowodować ujawnienie czytelnej zawartości. Dzięki solidnemu E2EE naruszenie wyłącznie pamięci masowej skutkuje szyfrogramem i wszelkimi metadanymi przechowywanymi przez usługę. Naruszenie punktu końcowego, kradzież poświadczeń do odzyskiwania, złośliwe oprogramowanie klienckie i wady usług zarządzania kluczami to oddzielne drogi do tekstu jawnego.
Dostęp prawny i rządowy
Od usługodawców można wymagać przedstawienia posiadanych danych. W przypadku E2EE może to obejmować szyfrogram, informacje o koncie, dzienniki dostępu, rozmiary rekordów, czas i metadane udostępniania, a nie czytelną treść zdjęć. To, czy żądanie może dotrzeć do urządzenia, metody odzyskiwania, odbiorcy lub przyszłego zachowania klienta, to inna kwestia prawna i techniczna.
Wewnętrzny dostęp
Pracownicy lub osoby atakujące mające dostęp do kluczy magazynu zarządzanych przez dostawcę mogą uzyskać dostęp do treści zaszyfrowanych po stronie serwera. E2EE usuwa tę bezpośrednią ścieżkę klucza magazynu, gdy dostawca nie ma kluczy zawartości w postaci jawnej. Nie uniemożliwia to kategorycznie nadużyć ze strony osób wewnątrz firmy, ponieważ dostawcy mogą kontrolować dystrybucję klientów, stan konta, metadane, udostępnianie lub elementy odzyskiwania.
Ochrona metadanych
Niektóre implementacje E2EE szyfrują tylko zawartość plików, pozostawiając metadane, takie jak nazwy plików i daty, bez ochrony. Vaultaire chroni nagłówki plików, typy MIME, indeksy, miniatury i inne metadane sejfu uwierzytelnionym szyfrowaniem AES-256-GCM. Długość przechowywanego szyfrogramu i liczba katalogów przechowywania sejfów mogą w dalszym ciągu ujawnić informacje strukturalne osobie mającej dostęp do kontenera aplikacji.
Częste nieporozumienia dotyczące E2EE
„Moje przechowywanie w chmurze jest zaszyfrowane, więc moje zdjęcia są bezpieczne." Szyfrowanie po stronie serwera chroni przed zewnętrznymi naruszeniami sprzętu serwerowego. Nie chroni przed samym dostawcą, żądaniami prawnymi ani wewnętrznymi zagrożeniami. Dostawca trzyma klucze.
„HTTPS oznacza, że moje zdjęcia są szyfrowane end-to-end." HTTPS (TLS) szyfruje dane podczas transmisji między twoim urządzeniem a serwerem. Gdy dane dotrą do serwera, są odszyfrowane. HTTPS to szyfrowanie rury, nie szyfrowanie danych.
„Szyfrowanie end-to-end oznacza, że nikt nigdy nie może zobaczyć moich zdjęć." E2EE oznacza, że nikt bez klucza nie może zobaczyć twoich zdjęć. Jeśli ktoś ma twoje hasło lub klucz, może odszyfrować dane. Zarządzanie kluczami i silne hasła są nadal niezbędne.
„Apple/Google nie mogą widzieć moich zdjęć." Domyślnie obie firmy trzymają klucze szyfrowania dla twoich zdjęć przechowywanych w chmurze. Apple oferuje Zaawansowaną ochronę danych jako opt-in. Google w ogóle nie oferuje opcji E2EE dla Google Photos.
Jak Vaultaire implementuje szyfrowanie end-to-end
Vaultaire używa warstwowego podejścia E2EE:
- AES-256-GCM szyfruje całą zawartość pliku. Każdy plik otrzymuje unikalny wektor inicjalizacyjny. Uwierzytelnione szyfrowanie wykrywa manipulacje.
- PBKDF2 z HMAC-SHA512 wyprowadza lokalny klucz sejfu na podstawie narysowanego przez użytkownika wzoru i soli urządzenia. Współczynnik pracy zwiększa koszt każdego odgadnięcia w trybie offline bez dodawania entropii do wzoru. Ten klucz sejfu uwierzytelnia zaszyfrowany indeks i rozpakowuje losowy klucz główny używany w danych plików.
- AES-256-GCM dla metadanych chroni nazwy plików, daty, wymiary, indeksy i miniatury w ramach uwierzytelnionego szyfrowania.
- iOS Keychain i Ochrona danych iOS chronią sól urządzenia i zaszyfrowaną bazę danych odzyskiwania. Operacje AES-GCM i aktywne klucze symetryczne pozostają w procesie aplikacji, gdy sejf jest otwarty.
- Separacja klucza dostawcy oznacza, że Wraxle nie otrzymuje klucza sejfu, klucza głównego, kopii zapasowej ani odzyskiwania w postaci jawnej. Kopia zapasowa CloudKit (domyślnie włączona), synchronizacja i udostępnianie przechowują rekordy szyfrogramu i zaszyfrowane koperty z kluczami, podczas gdy Apple może nadal obserwować metadane usług. Vaultaire nie wymaga konta tożsamości Vaultaire.
Vaultaire przechowuje informacje dotyczące odzyskiwania, w tym wzór, w zaszyfrowanej AES-GCM bazie danych przechowywanej w iOS Keychain. Nie są zapisywane w plikach z tekstem jawnym ani wysyłany do usługi konta Vaultaire. Jeśli nie pozostał użyteczny wzór, fraza odzyskiwania ani już odblokowane urządzenie, Vaultaire nie posiada klucza odzyskiwania dostawcy, który mógłby przywrócić dostęp.
Najczęściej zadawane pytania
Czy szyfrowanie end-to-end jest legalne?
Sytuacja prawna szyfrowania, dostępu przymusowego i usług szyfrowanych różni się w zależności od jurysdykcji i może ulec zmianie. W tym przewodniku opisano model techniczny, a nie poradę prawną. Sprawdź aktualne prawo lokalne, jeśli Twoje użycie wiąże się z przeszukaniem na granicy, nakazami sądowymi, rejestrami regulowanymi lub innymi sytuacjami wysokiego ryzyka.
Czy organy ścigania mogą złamać szyfrowanie end-to-end?
Ataki rzadko wymagają pełnego przeszukania przestrzeni kluczy AES-256. Atakujący może obrać za cel słabe hasło lub wzór, odblokowany punkt końcowy, pamięć, frazę odzyskiwania, odbiorcę, kopię zapasową lub wadę implementacji. Poprawnie zaimplementowane AES-256-GCM z losowym kluczem o wysokiej entropii jest zaprojektowane tak, aby było odporne na bezpośrednie wyszukiwanie klucza, ale to tylko jedna część systemu.
Jaka jest różnica między E2EE a szyfrowaniem z zerową wiedzą?
E2EE opisuje, gdzie następuje szyfrowanie i deszyfrowanie tekstu jawnego oraz kto przechowuje użyteczne klucze treści. „Zerowa wiedza” jest często używana w marketingu produktów na określenie szyfrowania, którego dostawca nie może odczytać, ale nie należy jej czytać dosłownie: usługa może nie mieć kluczy w postaci jawnej, a mimo to widzieć szyfrogram, dane konta, rozmiary, czas, relacje udostępniania i inne metadane. Oceń udokumentowane klucze i ścieżki odzyskiwania zamiast samej etykiety.
Czy szyfrowanie end-to-end spowalnia mój telefon?
Nowoczesne urządzenia wydajnie obsługują AES-256 dzięki przyspieszeniu sprzętowemu udostępnianemu przez systemowe biblioteki kryptograficzne. Na iPhonie Vaultaire wykonuje AES-GCM w procesie aplikacji za pomocą CryptoKit. Publiczne interfejsy API Secure Enclave firmy Apple nie są dowolnym silnikiem AES-GCM do szyfrowania plików. Narzut związany z szyfrowaniem i deszyfrowaniem zależy od rozmiaru pliku i urządzenia, ale został zaprojektowany tak, aby nie przeszkadzał podczas normalnego użytkowania.
Co się stanie, jeśli stracę klucz szyfrowania?
Utrata wszystkich możliwych do wykorzystania ścieżek deszyfrowania i odzyskiwania sprawia, że zaszyfrowanych danych nie da się odzyskać. Dlatego wiele systemów E2EE wykorzystuje frazy odzyskiwania, zaufane urządzenia, kontakty ratunkowe, zestawy ratunkowe lub zaszyfrowane koperty z kluczami. Mechanizmy te chronią dostęp, ale każdy z nich staje się także częścią modelu bezpieczeństwa.
Podsumowanie
Szyfrowanie end-to-end może odebrać dostawcy pamięci masowej dostęp do klucza w postaci jawnej, jeśli szyfrowanie odbywa się w autoryzowanym punkcie końcowym przed przesłaniem. Jest to znacząca ochrona, a nie gwarancja całego systemu. Sprawdź przechowywanie klucza zawartości, odzyskiwanie, metadane, aktualizacje klientów, bezpieczeństwo punktów końcowych i udostępnianie, zanim zaufasz usłudze z prywatnymi zdjęciami.
Vaultaire implementuje szyfrowanie po stronie klienta w iOS. Twoje zdjęcia i metadane sejfu są szyfrowane na urządzeniu za pomocą AES-256-GCM przed kopią zapasową (domyślnie włączoną) lub synchronizacją. Vaultaire nie otrzymuje kluczy deszyfrujących ani nie obsługuje serwera, który mógłby przekształcić te zaszyfrowane rekordy w Twoje zdjęcia. Ta granica dostawcy nie czyni przejętego ani odblokowanego iPhone’a godnym zaufania.