Ważne pytanie o bezpieczeństwo nie brzmi, czy szyfrowanie brzmi mocno, lecz co chroni, kto posiada klucze i jakie dowody potwierdzają to twierdzenie.
„Szyfrowanie klasy wojskowej” to za mało informacji, by ocenić komunikator. To określenie nie mówi, kto posiada klucze, które rozmowy są chronione, czy kopie zapasowe ujawniają tekst jawny ani co dzieje się po przejęciu urządzenia.
Rozsądną reakcją nie jest odrzucenie szyfrowania. Jest nią zastąpienie imponującej etykiety konkretnymi twierdzeniami, które można sprawdzić.
AES-256 to wybór algorytmu, a nie kompletny model bezpieczeństwa
AES jest standardem publicznym, a nie tajną technologią wojskową. FIPS 197 organizacji NIST określa AES-128, AES-192 i AES-256; końcówka oznacza długość klucza. W 2023 roku standard zaktualizowano redakcyjnie, nie zmieniając algorytmu.
Silny szyfr nadal może działać w systemie, który daje usługodawcy dostęp do tekstu jawnego. Pytaj, kto może odszyfrować dane, a nie tylko jak długi jest klucz. Pytaj też, jak klucze są generowane i przechowywane, jak uwierzytelnia się tożsamości i jakie warunki awarii powodują zatrzymanie aplikacji zamiast kontynuowania działania w sposób niezabezpieczony.
Gdy dostawca wymienia AES-GCM, jest to bardziej konkretne niż samo AES: GCM łączy szyfrowanie z uwierzytelnianiem. Poprawna obsługa wartości nonce, weryfikacja znaczników uwierzytelniających i pozostałe wymogi implementacyjne nadal mają znaczenie. Specyfikacja GCM organizacji NIST jest technicznym punktem odniesienia; logo nie dowodzi, że aplikacja implementuje ją poprawnie.
Cztery różne twierdzenia często łączone w marketingu
| Twierdzenie | Czego dotyczy | Czego nie dowodzi |
|---|---|---|
| Szyfrowanie transmisji | Ochrony połączenia, na przykład między aplikacją a serwerem | Że serwer nie może odczytać treści |
| Szyfrowanie danych w spoczynku | Ochrony zapisanych danych w określonym modelu kluczy i dostępu | Że operator nie posiada klucza odszyfrowującego |
| Szyfrowanie end-to-end | Ochrony treści między wyznaczonymi punktami końcowymi | Bezpieczeństwa przejętego punktu końcowego ani uczciwości odbiorcy |
| Postkwantowe ustanawianie kluczy | Odporności na określone zagrożenia kwantowe podczas ustanawiania kluczy | Pełnego audytu aplikacji, anonimowości ani gwarancji przyszłego bezpieczeństwa |
Szyfrowanie transmisji nie oznacza, że każda baza danych dostawcy przechowuje niezaszyfrowany tekst jawny. Usługa może również szyfrować zapisane dane. Istotne jest to, czy dostawca kontroluje klucze lub w inny sposób ma dostęp do czytelnej treści. Zachowuj precyzję zamiast zastępować jedno hasło drugim.
Szersze wprowadzenie znajdziesz w omówieniu tego, co chroni szyfrowanie end-to-end.
„Korzysta ze standardu NIST” nie oznacza „ma walidację FIPS”
FIPS 203 definiuje ML-KEM, mechanizm enkapsulacji klucza. Komunikator może deklarować używanie tego algorytmu bez certyfikacji ani niezależnego przeglądu całej aplikacji. Standardy, testowanie algorytmów, walidacja modułów kryptograficznych i audyty bezpieczeństwa produktu to różne rodzaje dowodów.
Program walidacji modułów kryptograficznych NIST wyraźnie wskazuje, że wdrożenie zatwierdzonych funkcji nie wystarcza do uzyskania walidacji modułu zgodnie z FIPS 140. Jeśli produkt reklamuje taką walidację, poproś o certyfikat, dokładny moduł i wersję, środowisko pracy oraz zatwierdzoną konfigurację. Następnie ustal, którą część produktu rzeczywiście obejmuje certyfikat.
Dlatego również „256-bitowe bezpieczeństwo” nie powinno służyć jako ogólna ocena całego komunikatora. Sposób łączenia protokołów, zarządzanie kluczami i implementacja mogą nakładać różne ograniczenia.
Uwierzytelnianie hasłem nie jest szyfrowaniem wiadomości
Mechanizm logowania rozstrzyga, czy użytkownik może uzyskać dostęp do konta. E2EE rozstrzyga, kto może odczytać chronioną treść wiadomości. Żaden z tych mechanizmów nie zapewnia automatycznie właściwości drugiego.
Na przykład SRP zaprojektowano do uwierzytelniania bez przesyłania samego hasła. Nie oznacza to, że kradzież bazy uwierzytelniania jest nieszkodliwa. Omówienie bezpieczeństwa SRP w RFC 5054 wyjaśnia, że skradziony weryfikator umożliwia ataki polegające na odgadywaniu haseł i wiąże się z innymi zagrożeniami. Unikaj wniosku: „nie ma haseł do kradzieży, więc włamanie na serwer nie może mieć znaczenia”.
Praktycznym kolejnym krokiem dla czytelnika jest pytanie o odzyskiwanie konta, aktywne sesje i związek między dostępem do konta a kluczami szyfrowania. Odpowiedź powtarzająca jedynie „zero knowledge” pozostawia istotne pytania bez rozstrzygnięcia.
Pięć pytań do strony o bezpieczeństwie komunikatora
- Jakie obszary obejmuje ochrona? Rozmowy bezpośrednie, grupy, pliki, połączenia, publiczne wpisy i kopie zapasowe mogą mieć różne granice ochrony.
- Kto posiada klucze nadające się do użycia? Uwzględnij klucze odzyskiwania, połączone urządzenia i tryby przetwarzania po stronie serwera.
- Jak uwierzytelniany jest drugi punkt końcowy? Szukaj weryfikacji kluczy, znaczących ostrzeżeń o zmianach i udokumentowanego modelu zaufania.
- Jakie dowody są dostępne? Specyfikacje, odtwarzalne kompilacje, wektory testowe i niezależne audyty odpowiadają na różne pytania. Pytaj o wersję i zakres każdego z nich.
- Co pozostaje widoczne lub podatne na zagrożenia? Metadane, przejęte urządzenia, skopiowane wiadomości i treści publiczne nie powinny znikać z wyjaśnienia.
Zastosuj ten sam test do Livary. Jej dokumentacja bezpieczeństwa wymienia LVR1 i LGS1 oraz publikuje granice działania ochrony. Traktuj je jako twierdzenia o produkcie wymagające oceny, a nie niezależną certyfikację. Proof Lab oferuje ograniczone demonstracje i sprawdzanie artefaktów, a nie dowód, że każda funkcja lub wersja jest bezpieczna.
Jak czytać niezależny audyt
Sprawdź datę, audytora, rewizję kodu, uwzględnione platformy i wyłączone komponenty. Czytaj ustalenia oraz stan napraw, a nie tylko odznakę podsumowującą. Audyt biblioteki kryptograficznej nie obejmuje automatycznie odzyskiwania konta, aplikacji internetowej, powiadomień ani bezpieczeństwa operacyjnego.
Brak audytu jest luką w zapewnieniu bezpieczeństwa, a nie dowodem konkretnej podatności. Z kolei audyt nie stanowi dożywotniej gwarancji. Użyteczne porównanie dokumentuje dowody i ich ograniczenia, zamiast ogłaszać uniwersalnego „najbezpieczniejszego” zwycięzcę.
Najczęściej zadawane pytania
Czy „klasa wojskowa” zawsze oznacza AES-256?
Nie. Nie wyciągaj z tego określenia wniosku o konkretnym algorytmie ani certyfikacji. Poproś dostawcę o dokładne wyjaśnienie jego znaczenia.
Czy silniejsze szyfrowanie powstrzymuje zrzuty ekranu lub złośliwe oprogramowanie?
Nie powstrzymuje odbiorcy przed kopiowaniem treści ani przejętego urządzenia przed ujawnianiem danych, do których ma dostęp. To inne zagrożenia.
Co jest lepszą oznaką niż hasło o bezpieczeństwie?
Jasny zakres, nazwany protokół, wyraźne ograniczenia i dowody dotyczące dostarczonej implementacji, które można przeanalizować. Wyjaśnienie powinno pomóc zdecydować, czemu zaufać — i co nadal wymaga sprawdzenia.
