Zakres ujawnienia zależy od rodzaju klucza i czasu dostępu atakującego; ratchet nie gwarantuje, że zagrożona jest tylko jedna wiadomość.
Silne szyfrowanie wymaga także poprawnego wykonania na urządzeniu. Luka w systemie operacyjnym, implementacji kryptografii lub sprzęcie może otworzyć drogę do wrażliwych danych; jednak samo istnienie badań nad atakami na procesory nie pozwala stwierdzić, że każdy telefon czy komunikator da się zaatakować w ten sam sposób.
Użyteczne pytania brzmią: jaki dostęp ma atakujący, jaki klucz lub tekst może zobaczyć i czy jego dostęp jest chwilowy, czy trwa nadal? Odpowiedzi są ważniejsze niż nazwa algorytmu.
Czym kanał boczny różni się od odczytu pamięci?
Przy bezpośrednim odczycie pamięci atakujący może być w stanie odczytać fragmenty przestrzeni pamięci procesu lub urządzenia. W ataku bocznym kanałem informacje wywnioskuje się ze śladów takich jak czas wykonania operacji czy zachowanie pamięci podręcznej. Te dwie metody nie muszą mieć takich samych warunków wstępnych ani wyników.
Oryginalne badanie FLUSH+RELOAD analizowało zachowanie pamięci podręcznej i współdzielone strony pamięci w określonym środowisku testowym oraz wykazało możliwość wydobycia klucza z pewnej wersji GnuPG. Ten wynik nie jest testem bezpieczeństwa Livara ani dowodem podatności wszystkich procesorów telefonów.
| Rodzaj dostępu | Pytanie potrzebne do oceny |
|---|---|
| Uruchomienie zwykłej aplikacji na tym samym urządzeniu | Czy izolacja procesów i warunki wstępne ataku pozwalają na obserwację? |
| Wysoki poziom uprawnień w systemie operacyjnym | Jakie dane lub operacje na kluczach stają się dostępne atakującemu? |
| Dostęp fizyczny lub laboratoryjny | Jaki jest stan blokady, model sprzętu i ochrona klucza? |
| Trwały dostęp do aplikacji | Czy atakujący może ponownie zbierać nowe teksty lub klucze? |
Ogólne określenie „hakowanie RAM” bez tych szczegółów nie jest wystarczającym wyjaśnieniem technicznym.
Jak pomagają Keystore i bezpieczny sprzęt?
Android Keystore może ograniczać użycie klucza i na odpowiednich urządzeniach wykonywać operacje ze wsparciem sprzętowym. W tym modelu niemożność wydobycia klucza nie jest tym samym co niemożność użycia go przez atakującego: zainfekowana aplikacja może w pewnych warunkach nadużyć dozwolonych operacji klucza, nawet bez wydobycia jego bajtów. Zobacz przewodnik po Android Keystore.
Nie wszystkie klucze i algorytmy automatycznie trafiają do bezpiecznego sprzętu. Należy określić typ klucza, obsługę przez urządzenie i sposób użycia przez aplikację. Stwierdzenie „klucz znajduje się na urządzeniu” samo w sobie nie dowodzi jego lokalizacji ani poziomu ochrony.
Czy ujawniony klucz ujawnia tylko jedną wiadomość?
Czasami ujawnienie niezależnego klucza wiadomości ma ograniczony zakres. Ale jeśli atakujący uzyska klucz łańcucha, stan sesji, klucz tożsamości, czytelną historię lub wiele buforów, wynik jest inny. Bez określenia ujawnionych danych nie można więc mówić, że zagrożona jest „najwyżej jedna wiadomość”.
Zmiana klucza dla każdej wiadomości również nie musi odcinać dostępu atakującego. Jeśli kolejne klucze wyprowadza się ze stanu, który on posiada, albo nadal jest obecny na urządzeniu, może uzyskać dostęp również do kolejnych wiadomości. Ochrona przeszłości i odzyskanie bezpieczeństwa w przyszłości to dwie odrębne właściwości z określonymi założeniami.
Jakie ograniczenia mają ratchet i czyszczenie pamięci?
Mechanizm ratchet może przekształcać klucze w trakcie rozmowy. Odzyskanie bezpieczeństwa po ujawnieniu wymaga wprowadzenia nowych informacji niedostępnych atakującemu; samo wysłanie wiadomości nie dowodzi spełnienia tego warunku. Specyfikacja Double Ratchet oprócz odzyskiwania bezpieczeństwa omawia ryzyko trwałego dostępu i odzyskania usuniętych danych.
Skracanie czasu życia wrażliwych danych i czyszczenie buforów jest użyteczne, ale nie wynika z tego ogólna gwarancja usunięcia wszystkich kopii w RAM. Trzeba zbadać biblioteki, język programowania i ścieżki wyświetlania.
Co można powiedzieć o Livara?
Strona bezpieczeństwa Livara opisuje konstrukcję hybrydową i ewolucję kluczy w LVR1. Ten artykuł nie jest testem kanałów bocznych, audytem pamięci ani potwierdzeniem, że wszystkie klucze korzystają z Keystore. W szczególności publiczna dokumentacja modelu zagrożeń nie gwarantuje ochrony zainfekowanego urządzenia.
Dlatego nie należy przypisywać produktowi obietnic „zneutralizowania włamania sprzętowego przez kolejną wiadomość” lub „ujawnienia najwyżej jednej wiadomości”, chyba że istnieją konkretne dowody dla danej wersji i scenariusza.
Praktyczna decyzja dla użytkownika
Aktualizuj system operacyjny i aplikację, wybieraj urządzenie z aktywnym wsparciem bezpieczeństwa, unikaj niezaufanych instalacji i zbędnych uprawnień oraz stosuj odpowiednią blokadę. Przy podejrzeniu poważnego włamania zmiana komunikatora lub wysłanie nowej wiadomości nie zastępuje zbadania i oczyszczenia urządzenia.
Czytając twierdzenie o bezpieczeństwie, poproś o cztery rzeczy: testowaną wersję, dostęp atakującego, ujawnione dane i ograniczenia wyniku. Sama nazwa procesora lub standardu kryptograficznego nie odpowiada na te cztery pytania.
