Klucz dla konkretnego pliku nie oznacza jednorazowego wyświetlenia ani możliwości odebrania kopii odbiorcy.
Aby chronić załącznik, komunikator może zaszyfrować plik na urządzeniu nadawcy losowym kluczem, przesłać zaszyfrowaną wersję do usługi przechowywania i dostarczyć klucz pliku odbiorcy w wiadomości szyfrowanej end-to-end. Ten schemat bywa nazywany szyfrowaniem kopertowym: duży plik i niewielka ilość informacji potrzebna do jego otwarcia podążają różnymi, lecz powiązanymi drogami.
Ten opis dotyczy załączników w rozmowie z E2EE; wysyłanie plików w dowolnej aplikacji lub dowolnym rodzaju kanału nie musi zapewniać takiej samej ochrony.
Droga prywatnego zdjęcia od urządzenia do odbiorcy
- Urządzenie nadawcy generuje klucz treści dla pliku.
- Plik jest szyfrowany za pomocą szyfrowania uwierzytelnionego; odbiorca musi wykrywać nieuprawnione zmiany danych.
- Zaszyfrowana wersja trafia do usługi przechowywania plików.
- Adres lub identyfikator pliku oraz potrzebny klucz są przesyłane odbiorcy w chronionej wiadomości.
- Urządzenie odbiorcy pobiera plik, sprawdza jego poprawność, a następnie go otwiera.
Dokumentacja bezpieczeństwa Livara opisuje losowy klucz przypisany do konkretnego pliku załącznika i przekazywanie go w sesji wiadomości. Artykuł wyjaśnia tę deklarowaną architekturę, a nie wyniki audytu implementacji.
„Klucz dla konkretnego pliku” nie oznacza, że „plik można otworzyć tylko raz”
Klucz wygenerowany dla jednego pliku może być potrzebny do wielokrotnego odczytania tego samego pliku. Osobny klucz nie oznacza jego natychmiastowego odrzucenia po pierwszym wyświetleniu, automatycznego usunięcia pliku ani uniemożliwienia odbiorcy zapisania go.
Jednorazowość klucza wiadomości i wykorzystanie klucza treści do załącznika to również dwa różne pojęcia. Funkcji takich jak jednorazowe wyświetlenie czy znikające wiadomości nie należy wnioskować wyłącznie z nazwy algorytmu.
Dlaczego znaczenie mają zarówno klucz, jak i nonce?
AES-GCM zapewnia oprócz poufności kontrolę autentyczności danych, ale wymaga prawidłowego użycia. Standard NIST SP 800-38D opisuje zasady GCM. Ponowne użycie tej samej pary klucz–nonce dla różnych danych może zagrozić bezpieczeństwu.
Dla użytkownika praktyczny wniosek jest następujący: samo określenie „AES-256” nie wystarczy. Należy sprawdzić również specyfikacje zarządzania kluczami, generowania losowego, walidacji plików i obsługi błędów. Zmiana jednego bajtu powinna prowadzić do odrzucenia nieprawidłowego pliku, a nie wyświetlenia zmodyfikowanej treści jako poprawnego pliku.
Co widzą odbiorca, serwer i aplikacja galerii?
| Miejsce | Pytanie dotyczące bezpieczeństwa |
|---|---|
| Usługa przechowywania plików | Czy ma tylko zaszyfrowane bajty, czy także dostęp do klucza? |
| Wiadomość zawierająca klucz | Czy klucz, nazwa pliku i jego opis są chronione w rozmowie E2EE? |
| Urządzenie odbiorcy | Gdzie pozostaje plik po otwarciu: w pamięci, pamięci podręcznej czy galerii? |
| Kopia zapasowa w chmurze | Czy zapisana kopia trafia do kopii zapasowej zdjęć i jak jest chroniona ta kopia zapasowa? |
Szyfrowanie podczas przesyłania nie kontroluje kopii zapisanej przez odbiorcę w galerii. Przed wysłaniem poufnego dokumentu sprawdź także zbędne fragmenty zdjęcia, napisy w tle i informacje o lokalizacji zawarte w pliku.
Co zmienia się w przypadku pliku w prywatnej grupie?
Rośnie liczba uprawnionych posiadaczy klucza. Livara opisuje w LGS1 obsługę załączników w zgodnych prywatnych grupach w trybie E2EE; nie należy rozszerzać tej deklaracji na kanały publiczne. Każdy członek, który otrzymał plik, może zachować kopię. Usunięcie członka lub rotacja przyszłych kluczy nie odbiera mu wcześniejszej kopii.
Lista kontrolna przed wysłaniem poufnego pliku
- Ponownie sprawdź przestrzeń rozmowy i jej uczestników.
- Jeśli tożsamość rozmówcy jest ważna, zweryfikuj odcisk klucza zaufaną drogą.
- Wysyłaj tylko niezbędne informacje; zdjęcie całego dokumentu nie zawsze jest potrzebne.
- Uzgodnij z odbiorcą zasady zapisywania w galerii, automatycznego pobierania i kopii zapasowych w chmurze.
- Nie pozostawiaj odszyfrowanego pliku na współdzielonym lub niezablokowanym urządzeniu.
Najczęstsze pytania
Czy klucz dla konkretnego pliku gwarantuje bezpieczne wysłanie?
Nie. Potrzebne są również bezpieczne urządzenia, uwierzytelnienie odbiorcy i prawidłowa implementacja. Przeczytaj model zagrożeń Livara wraz ze specyfikacją szyfrowania.
Czy zdjęcie w kanale publicznym ma taką samą ochronę?
Zgodnie z granicą deklarowaną przez Livara kanały są publiczne i można je odczytać; nie obiecuje się dla nich poufności prywatnych załączników.
Czy sam link do pliku wystarczy?
To zależy od projektu usługi. Rozpatruj link, klucz i uprawnienia dostępu osobno; sama długość lub losowość adresu URL nie dowodzi E2EE.
