Apple słabe z kryptografii: szyfrowanie w komunikatorze iMessage jest do niczego

Apple powinno wyłączyć swój komunikator iMessage i zbudowaćzupełnie nowe narzędzie do wiadomości błyskawicznych –przynajmniej jeśli firmie z Cupertino zależy na bezpieczeństwie iprywatności swoich użytkowników. Tak przynajmniej uważa MatthewGreen, ekspert od kryptografii z John Hopkins University, któryprzez ostatnie miesiące prowadził kompleksowe badania nad tąusługą. Aktualizacje nic nie pomogą, tych błędów nie da się poprostu naprawić.

Podczas gdy władze Stanów Zjednoczonych robią co mogą, byzakończyć kryptograficzną rewolucję, która oddała w ręceobywateli odporne nawet na wojskowych analityków technikiszyfrowania, Apple jednoznacznie opowiada się za prawem doprywatności, deklarując, że jego urządzenia i oprogramowaniepozostaną zamkniętą czarną skrzynką dla każdego, kto nie jestuprawnionym ich użytkownikiem. Deklaracje natury politycznej tojednak jedno, umiejętności techniczne to zupełnie inna sprawa.

Na łamach swojegobloga profesor Matthew Green opisał atak na iMessage, którymożliwy był ze względu na błąd w samej architekturzekomunikatora Apple'a. Jest to dość ciekawy przykład na to, jaknawet drobne pomyłki w założeniach kryptosystemu mogą zemścićsię na jego projektantach. Pokazuje też, że to co dziś jest przezekspertów rekomendowane, jutro może okazać się z gruntuniebezpieczne – jeszcze bowiem w 2011 roku Green chwalił Apple zaiMessage, pisząc że jest to pierwszy powszechnie wykorzystywanykomunikator, stosujący w jakimś stopniu szyfrowanie end-to-end.

Odkryte przez Greena i jego studentów błędy pozwalają naodszyfrowanie załączników ze zdjęciami i filmami przesyłanymiprzez iMessage i wynikają z zastosowania centralnego serwera kluczy– coś, czego w prawdziwym szyfrowaniu end-to-end nie powinno być.Przyjrzyjmy się bliżej problemowi: aby zaszyfrować wiadomość,iMessage pobiera klucz publiczny adresata, a następnie generujelosowy klucz AES *k, szyfrując nim wiadomość w blokowymtrybie CTR. Następnie szyfruje k *zapomocą klucza adresata, a następnie całość podpisuje kluczemECDSA nadawcy, by uniknąć nieuprawnionego zmodyfikowaniawiadomości.

To jednak, jak zauważyłkryptograf, nie wystarczy. Przedstawia scenariusz ataku, w którymnapastnik, który ma własne konto iMessage przechwycił powyższąwiadomość. Usuwa z niej podpis ECDSA, zastępując go swoimpodpisem, a następnie wysyła nowo podpisaną wiadomość doodbiorcy ze swojego konta. Odbiorca otrzymuje wiadomość, deszyfrujeją – i widzi, że przybyła od napastnika, a nie od oczekiwanegonadawcy. Nic strasznego, prawda? Jednak poprzez zastąpienie podpisuswoim, napastnik zyskuje możliwość manipulowania szyfrogramem, niezabezpieczonym za pomocą kodu uwierzytelniania wiadomości (MAC).Zmieniając w nim bity, zmienia zawartość wiadomości do odbiorcy,mimo że sam nie może jej odczytać.

Teraz poprzez manipulowaniezawartością szyfrogramu, wysyłanie wielkiej liczby zmodyfikowanychwariantów wiadomości, stopniowo napastnik może uzyskać wgląd wzawartość oryginalnej wiadomości – i od razu powiedzmy, że jestto bardzoskomplikowany atak, wykorzystujący też podatność wwykorzystywanym algorytmie kompresji wiadomości, a zarazemobchodzący liczne zabezpieczenia iOS-a. W praktyce aby odszyfrowaćwiadomość, trzeba zdobyć jej kopię, następnie wysłać ok. 218niewidzialnych zaszyfrowanych wiadomości na atakowane urządzenie,jednocześnie ustalając, czy te wiadomości zostały poprawnieodszyfrowane, czy nie.

Atak jest więc wysoce akademicki– trzeba by było przechwycić połączenie TLS korzystając zeskradzionego certyfikatu (co jest trudne ze względu na mechanizmprzypinania certyfikatów w iOS-ie 9), albo wręcz przejąć serwerpowiadomień Push Apple'a (co wymaga działańzinstytucjonalizowanego napastnika, np. agencji o trzyliterowejnazwie). Trzeba byłoby znaleźć też sposób na uzyskanieinformacji o reakcjach na zmanipulowaną wiadomość – tymczasemiMessage takich wiadomości nigdzie nie udziela.

Sytuację zmienia wykorzystaniezałączników. Są one bowiem obsługiwane inaczej niż wiadomości.Przesyłając zdjęcie przez iMessage, jest ono szyfrowane losowym256-bitowym kluczem AES, następnie zaś wyliczana jest funkcjaskrótu SHA1, a całość wgrywana do chmury iCloud. Nadawca wysyłaodbiorcy w wiadomości nie tyle zdjęcie, co adres do zaszyfrowanegozdjęcia, skrót i klucz deszyfrujący. Jeśli wszystko jestpoprawne, to komunikator u adresata automatycznie spróbuje pobraćzdjęcie. Jeśli gdzieś jest błąd, komunikator tego nie robi. I towłaśnie jest sygnałem dla napastnika o tym, czy odszyfrowanie siępowiodło.

Napastnik może teraz wykryćpróbę pobrania załącznika czy to podglądając ruch sieciowyofiary, czy też fałszując URL w szyfrogramie, tak by prowadził onnie do iCloud.com, ale na serwer przez siebie kontrolowany – nietrzeba do tego mieć dostępu do sieci ofiary. W ten sposóbprzechwytując wiadomość z załącznikiem, manipulując nią imonitorując próby pobrania załącznika przez urządzenie ofiary,można odzyskać wszystkie cyfry klucza przechowywanego w załączniku.Gdy to już nastąpi, napastnik sięga po prostu do iCloud, samemupobierając załącznik.

Atak taki przy użyciu testowego,niezoptymalizowanego oprogramowania zajmuje obecnie około 70 godzin,ale prof. Green wierzy, że odpowiednia optymalizacja kodupozwoliłaby przyspieszyć go o rząd wielkości, do ułamka dnia. Cowięcej, błąd ten mógłby być wykorzystany przeciwko innymwiadomościom, nie tylko tylko tym z załącznikami – wszystko tokwestia znalezienia innego sposobu sygnalizacji o staniedeszyfrowania. Sytuacja jest tym gorsza, że niedostarczone dane naserwerach Apple'a przechowywane są przez 30 dni, co daje sporo czasunapastnikowi.

Z pomocą dla Apple'a przyszedłuczeń Greena, Ian Miers, który zaproponował wykorzystanieniepodatnej na manipulację części szyfrogramu AES (RSA-OAEP), abystworzyć zawierający je bufor i odrzucać w ten sposób wszystkiepowtarzające się szyfrogramy (takie, jakie byłyby wysyłane przeznapastnika). Poprawkę tę zastosowano w najnowszym iOS-ie9.3, ale na dłuższą metę zdaniem eksperta nie ma ona wartości –to jedynie słaba łatka dla złego kryptosystemu. Naukowiec uważa,że Apple powinno jak najszybciej wyrzucić iMessage i przejść naprotokół Axolotl (wykorzystywany m.in. przez komunikator Signal).