Szyfrowane przechowywanie oddziela bajty pliku od uprawnienia do odszyfrowania, lecz odbiorcy, metadane i lokalne kopie pozostają częścią modelu zagrożeń.
Załącznik zaszyfrowany end-to-end można przechowywać na serwerze bez udostępniania mu pliku w postaci jawnej. Typowy projekt szyfruje plik na urządzeniu nadawcy świeżym kluczem treści, wysyła szyfrogram i przekazuje klucz zamierzonym odbiorcom wewnątrz uwierzytelnionej, zaszyfrowanej wiadomości.
To rozdzielenie jest przydatne, ale „przechowywanie zero-knowledge” nie jest pełną specyfikacją. Nadal trzeba pytać o obsługę kluczy, odwołań do plików, nazw plików, kontroli dostępu i pobranych kopii.
Cykl życia załącznika
- Przygotuj plik. Nadawca wybiera zdjęcie, film lub dokument. Usuwanie metadanych lub transkodowanie to osobny krok; samo szyfrowanie nie usuwa EXIF ani właściwości dokumentu.
- Utwórz materiał szyfrujący. Bezpieczna implementacja generuje wymagany klucz i nonce zgodnie z wybranym schematem.
- Zaszyfruj przed wysłaniem. Usługa przechowywania otrzymuje zaszyfrowane bajty zamiast pierwotnej treści.
- Dostarcz uwierzytelnione odwołanie. Zaszyfrowana wiadomość czatu przenosi informacje potrzebne odbiorcom, takie jak lokalizator pliku, klucz deszyfrujący i odpowiednie metadane integralności.
- Pobierz i sprawdź. Klient odbiorcy pobiera obiekt danych i sprawdza uwierzytelnienie, zanim uzna wynik za prawidłową treść.
- Zarządzaj lokalnymi kopiami. Wyświetlanie, eksportowanie, edycja lub zapisywanie w galerii może tworzyć kopie poza pierwotną granicą szyfrowanego przechowywania.
Klucz może przechodzić przez infrastrukturę tego samego dostawcy w zaszyfrowanej kopercie. Nazywanie tego „kanałem pozapasmowym” może mylić: jest logicznie oddzielone od przechowywania obiektu, ale niekoniecznie dostarczane niezależnym kanałem komunikacji.
Co wnosi szyfrowanie uwierzytelnione
Schemat szyfrowania uwierzytelnionego chroni poufność i wykrywa nieautoryzowane zmiany w uwierzytelnianym zakresie. Specyfikacja GCM NIST definiuje jedną z takich konstrukcji i jej wymagania. Prawidłowa obsługa klucza i nonce oraz sprawdzanie wyniku uwierzytelnienia są niezbędne; uznana nazwa algorytmu nie czyni każdej implementacji bezpieczną.
Aplikacja musi też powiązać plik z właściwą wiadomością i rozmową. Prawidłowy zaszyfrowany obiekt sam w sobie nie dowodzi, że należy do tego konkretnego czatu. Identyfikatory plików, oczekiwany rozmiar, kolejność fragmentów i metadane załączników wymagają odpowiedniego projektu uwierzytelniania.
Czego usługa przechowywania może nadal się dowiedzieć
| Informacja | Czy samo szyfrowanie treści ją ukrywa? |
|---|---|
| Pierwotne bajty pliku | Taki jest jego cel wobec stron bez klucza |
| Przybliżony rozmiar po zaszyfrowaniu | Zwykle nie |
| Czas wysyłania i pobierania | Zwykle nie |
| Które konto żąda pliku | Zależy od projektu routingu i kontroli dostępu |
| Nazwa pliku i podpis | Tylko jeśli protokół także je chroni |
| Kopia zapisana przez odbiorcę | Nie; odbiorca ma już dostęp do postaci jawnej |
Kontrola dostępu ma znaczenie także wtedy, gdy obiekty są zaszyfrowane. Może ograniczać niechciane pobieranie, nadużycia i ujawnianie identyfikatorów. Szyfrowanie nie zastępuje autoryzacji, zasad przechowywania ani dostępności.
Duże pliki wymagają więcej niż jednego sloganu
Projekt obsługi dużych plików może przesyłać dane strumieniowo lub dzielić je na uwierzytelnione fragmenty. Może to zmniejszyć użycie pamięci, ale trzeba zdefiniować numerację fragmentów, końcową długość, ponawianie prób i obsługę ucięcia. Nie wymyślaj danych o wydajności ani nie twierdź, że umieszczenie pliku w wiadomości nieuchronnie powoduje „rozrost stanu ratchet”; wyniki zależą od implementacji.
Przydatny test obejmuje prawidłowy plik, zmieniony bajt, ucięte pobranie, fragment w zmienionej kolejności i nieautoryzowaną próbę pobrania. Takie testy wykonuj wyłącznie w uprawnionym środowisku testowym z niewrażliwymi plikami. Zapisz, czy klient odrzuca nieprawidłowe dane przed ich otwarciem.
Co dokumentuje Livara
Strona bezpieczeństwa Livary opisuje szyfrowanie przed wysłaniem, losowy klucz dla każdego pliku przenoszony w chronionej sesji oraz ochronę nazw plików i podpisów w rozmowach z aktywnym E2EE, w tym zgodnych grupach prywatnych. Starsze niezgodne grupy są jawnie wyłączone z tej ochrony. Dokumentacja odróżnia chronione rozmowy od publicznych kanałów nadawczych. To udokumentowane deklaracje produktu, a nie nowy audyt implementacji przeprowadzony w tym artykule.
Model zagrożeń uwzględnia też możliwość ujawnienia czytelnej treści przez odbiorcę lub przejęte urządzenie. Szyfrowane przechowywanie nie może więc obiecać, że obraz zniknie z każdego urządzenia po usunięciu wiadomości z czatu.
Pytania przed udostępnieniem wrażliwych plików
Sprawdź, czy dany typ rozmowy obsługuje E2EE, czy ufasz wszystkim zamierzonym odbiorcom i czy sam plik zawiera metadane identyfikujące. Osobno przejrzyj automatyczne zapisywanie w galerii i kopie zdjęć w chmurze. W przypadku dokumentu rozważ usunięcie przed wysłaniem komentarzy, historii zmian lub osadzonych właściwości.
Na koniec zrozum usuwanie i odzyskiwanie. Usunięcie obiektu z serwera może uniemożliwić przyszłe pobranie, ale nie cofa istniejącej kopii odbiorcy. Utrata wymaganego klucza może uczynić pozostały zaszyfrowany plik nieczytelnym. Dobry projekt załączników jasno wyjaśnia oba skutki.
