Zwinność kryptograficzna to zdolność przeniesienia protokołu z jednego zestawu kryptograficznego na inny bez utraty jasno określonych gwarancji bezpieczeństwa. W komunikatorach oznacza to więcej niż dodanie nazwy nowego algorytmu. Starsze klienty, odbiorcy offline, zapisane wiadomości i połączone urządzenia muszą zachowywać się przewidywalnie podczas przejścia.
Dokument IETF RFC 7696 opisuje zwinność algorytmiczną jako problem migracji obejmujący identyfikatory, implementacje i zmiany operacyjne. Numer wersji pomaga ustalić, co jest używane; sam w sobie nie zapewnia bezpiecznej migracji.
Trzy wersje, które łatwo pomylić
Komunikator może mieć wersję aplikacji, wersję protokołu transmisji i identyfikator zestawu kryptograficznego. Odpowiadają one na różne pytania:
| Identyfikator | Co mówi osobie oceniającej | Czego nie potwierdza |
|---|---|---|
| Wydanie aplikacji | Która kompilacja oprogramowania jest zainstalowana | Że każda rozmowa korzysta z najnowszego protokołu |
| Wersja protokołu | Jaki format wiadomości i jakie reguły stanu obowiązują | Że implementacja prawidłowo przestrzega tych reguł |
| Identyfikator algorytmu lub zestawu | Które komponenty kryptograficzne wybrano | Że nie można wymusić negocjacji słabszego wariantu |
Informacje o wydaniu powinny jasno określać te zależności. „Wprowadzono nowe szyfrowanie” jest niejednoznaczne, jeśli używają go tylko nowo utworzone rozmowy lub jeśli starszy połączony klient powoduje przejście na wcześniejszy wariant.
Co musi określać bezpieczna migracja
Zacznij od konkretnego scenariusza: Alicja aktualizuje aplikację dzisiaj; Bob pozostaje offline na starszym telefonie. Alicja wysyła wiadomość, a później dodaje drugie urządzenie. Co każde urządzenie powinno przyjmować, przechowywać i wyświetlać?
Projekt nadający się do oceny odpowiada co najmniej na te pytania:
- Jak każda ze stron poznaje wersje obsługiwane przez drugą?
- Czy wybrana wersja jest uwierzytelniana jako część sesji?
- Co się dzieje, gdy nie ma wspólnej akceptowalnej wersji?
- Czy złośliwy pośrednik może usunąć informację o możliwości i wymusić słabszy tryb?
- Czy stare wiadomości pozostają czytelne i które stare klucze są nadal potrzebne?
- Czy przywrócenie kopii zapasowej przywraca przestarzały stan protokołu?
- Kiedy wycofywane algorytmy zostaną wyłączone, a nie tylko odradzane?
Widoczny błąd jest często bezpieczniejszy niż ciche przejście do trybu, którego użytkownik nie zamierzał używać. Trzeba jednak udokumentować dokładne zachowanie przy błędzie i odzyskiwaniu działania, aby ludzie nie obchodzili problemu, przechodząc na niezabezpieczony kanał.
Praktyczna macierz testów aktualizacji
Aktualizacja bezpieczeństwa wymaga czegoś więcej niż udanej rozmowy między dwiema nowymi instalacjami. Przetestuj te przypadki z użyciem danych niewrażliwych:
| Test | Dowody do zapisania |
|---|---|
| Nowy klient do starego klienta | Wybrany protokół lub jasny wynik wskazujący niezgodność |
| Odbiorca offline podczas aktualizacji | Zachowanie dostarczania i odszyfrowywania po ponownym połączeniu |
| Powrót starego połączonego urządzenia | Czy może czytać, wysyłać lub wymusić nieoczekiwany tryb |
| Dodanie niezgodnego członka do grupy | Jawne zasady grupy i stan widoczny dla użytkownika |
| Przywrócenie kopii po wycofaniu mechanizmu | Czy nieobsługiwany stan jest odrzucany lub migrowany |
| Zmodyfikowane metadane wersji | Błąd uwierzytelniania zamiast niezauważonego obniżenia zabezpieczeń |
To kryteria oceny, a nie twierdzenia, że konkretny produkt przeszedł te testy. Zachowuj identyfikatory kompilacji i zaobserwowane wyniki, aby późniejszą regresję można było odróżnić od zmiany dokumentacji.
Jak odczytywać nazwy protokołów Livary
Livara używa nazw LVR1 dla czatów bezpośrednich i LGS1 dla grup prywatnych w swojej dokumentacji bezpieczeństwa. Nazwy te rozróżniają zakresy odpowiedzialności; nie należy traktować ich jako dowodu niezależnej standaryzacji lub audytu. Strona omawia także zachowanie klientów lub grup, które nie mogą spełnić wymagań wstępnych trybu szyfrowanego.
Kolejnymi przydatnymi dowodami byłyby wersjonowana specyfikacja, wektory testowe, reguły zgodności i wyniki przeglądów powiązane z konkretnym wydaniem. Proof Lab jasno określa węższy zakres swojej demonstracji. Sprawdzanie prymitywów w przeglądarce nie jest tym samym co testowanie każdej ścieżki migracji w aplikacji.
Co użytkownicy powinni robić podczas aktualizacji szyfrowania
Aktualizuj obsługiwane klienty, czytaj komunikaty bezpieczeństwa dotyczące zgodności urządzeń i zwracaj uwagę na zmiany wskaźników tożsamości lub stanu szyfrowania. Nie zakładaj, że nowa ikona aplikacji oznacza, iż każda stara grupa i kopia zapasowa zyskała nową ochronę. Jeśli produkt nie potrafi wyjaśnić, dla których danych zmieniła się ochrona, zapytaj przed udostępnieniem wrażliwych materiałów.
Dobra zwinność kryptograficzna pozwala sprawdzić zmianę. Wskazuje, co się zmieniło, jak strony uzgadniają tę zmianę, co może pójść nie tak i kiedy stary mechanizm przestaje być akceptowany.
