r   e   k   l   a   m   a
r   e   k   l   a   m   a

Android o całe lata za iOS-em pod względem zabezpieczeń – nawet Nougat nie pomógł

Strona główna AktualnościBEZPIECZEŃSTWO

Niedawna wypowiedź Adriana Ludwiga, szefa bezpieczeństwa Androida, jakoby nowe smartfony Google Pixel z Androidem 7.1 były równie odporne na ataki co najnowszy iPhone, nie przeszła bez echa. Przypomnijmy – Ludwig uważa, że dla niemal wszystkich typów zagrożeń Android i iOS są praktycznie identyczne w kwestii zabezpieczeń platform. Czy aby jednak na pewno? Deklaracja ta sprowokowała Matthew Greena, słynnego kryptografa z Johns Hopkins University, który szybko wskazał fundamentalny problem z zabezpieczeniami Google’a, wskutek którego Android jest o całe lata za iOS-em, jeśli chodzi o jego bezpieczeństwo.

Podstawowym problemem urządzeń z Androidem jest, zdaniem Greena, potraktowanie ich jak pecetów, mimo że pecetami nie są. Od Androida 4.4 KitKat mobilny system Google’a stosuje szyfrowanie praktycznie takie samo, jak desktopowe systemy linuksowe. Bazuje ono na podsystemie szyfrowania kernela dm-crypt. To rozwiązanie świetne, ale czy właściwe dla smartfonów? Problem tkwi w tym, że całodyskowe szyfrowanie chroni dane na smartfonie… gdy jest on wyłączony. Gdy urządzenie jest włączone, a klucze deszyfrujące znajdują się w pamięci operacyjnej, to tego szyfrowania jakby nie było.

Większość użytkowników urządzeń mobilnych praktycznie jednak ich nie wyłącza. Pomyślano o płynnym przechodzeniu między stanami energooszczędnego czuwania i skoków aktywności, w imię wydłużenia czasu pracy na baterii. Dziś dobre smartfony mogą w ten sposób pracować po kilka dni, a gdy poziom naładowania robi się niski, użytkownicy po prostu podłączają je do ładowarek. Uptime smartfonów może więc sięgać całych miesięcy.

r   e   k   l   a   m   a

Czy dla tak działających urządzeń całodyskowe szyfrowanie jest dobre? Green odpowiada „nie” – i trudno się z nim nie zgodzić. Dbający o swoją prywatność użytkownicy komputerów osobistych nie usypiają ich, tylko wyłączają, mając pewność, że całodyskowe szyfrowanie czyni ich dane niedostępnymi dla osób trzecich. Smartfony nosimy jednak ze sobą cały czas, niewyłączone. Gdy smartfon zgubimy, lub zostanie nam przemocą odebrany, napastnik wciąż dostaje urządzenie z kluczami w RAM, z pełnym dostępem do danych użytkownika. dm-crypt w tym wypadku nic nie daje.

Apple poszło zupełnie inną drogą. Od iOS-a 4 w mobilnym systemie z Cupertino mamy do czynienia z mechanizmem ochrony danych, pozwalającym zaszyfrować dane przechowywane na urządzeniu. Rozumiejąc jednak specyfikę wykorzystania urządzeń mobilnych, Apple postawiło na szyfrowanie plików – każdego z osobna. W tym systemie zawartość każdego pliku jest szyfrowana za pomocą unikatowego klucza (metadane plików są szyfrowane osobno), unikatowe klucze są zaś szyfrowane za pomocą jednego z kluczy klas bezpieczeństwa, wyprowadzonych z hasła użytkownika i danych przechowywanych sprzętowo w procesorze urządzenia.

W ten sposób Apple oferuje precyzyjną kontrolę dostępu do plików iOS-a. Programiści mają dostęp do interfejsu programowania, który pozwala określić, który z kluczy klas bezpieczeństwa ma zostać wykorzystany do zabezpieczenia danego pliku. W ten sposób możemy tworzyć pliki, które są dostępne dla każdego, nawet po restarcie urządzenia przed zalogowaniem się użytkownika, pliki zabezpieczone do momentu pierwszego zalogowania użytkownika, oraz co najważniejsze, pliki, które są zabezpieczone cały czas: są odszyfrowywane tylko na chwilę, gdy urządzenie zostało odblokowane. Po ponownym zablokowaniu, klucz jest usuwany z pamięci urządzenia.

W Androidzie 7 Google ulepszyło swoją strategię. Nowy model, Direct Boot, oferuje dwa konteksty szyfrowania. Pierwszy to sprzętowo zaszyfrowana pamięć (te pliki nie są szyfrowane hasłem użytkownika, co najwyżej są szyfrowane za pomocą danych sprzętowych, a więc są dostępne zaraz po rozruchu, a przed logowaniem), drugi to pamięć szyfrowana poprzez uwierzytelnianie – takie pliki dostępne są tylko po podaniu przez użytkownika swojego hasła. Atutem DirectBoota ma być to, że można skorzystać z różnych kontekstów szyfrowania dla różnych użytkowników smartfonu, choć do końca nie wiadomo, po co to komu – smartfony to jednak raczej jednoosobowe urządzenia.

Pomimo tych zmian, widać, że Android 7 nie oferuje takiego zabezpieczenia jak iOS 10 z usuwaniem kluczy z pamięci dla plików w pełni chronionych. W teorii można by było to wymusić na poziomie aplikacji, tyle że jak zauważa Green, nie ma jasnej metody powiedzenia aplikacjom, kiedy to Android został ponownie zablokowany. Nawet aplikacje systemowe tego nie wiedzą – gdy odetniesz im nagle dostęp do plików, sypią błędami. Co więcej, Android 7 nawet nie próbuje tak naprawdę usunąć kluczy z pamięci po zablokowaniu urządzenia. W kodzie systemu plików ext4 widać, że funkcja mająca zapewnić ich usunięcie z pęku kluczy kernela nie została jeszcze napisana!

Matthew Green zauważa więc na koniec, że ta słabość Androida właściwie nie wiąże się z kryptografią. To problem zarówno architektury systemu, jak i braku należytych wytycznych dla programistów. Podążając w tym kierunku, Google skazuje Androida na całe lata bycia niebezpiecznym. Świetny ruch – szczególnie dziś, gdy władze wielu państw tylko szukają rozwiązań prawnych, które pozwolą im się bez ograniczeń włamywać do urządzeń obywateli. Być może pan Adrian Ludwig nie uważa tego jednak za istotne zagrożenie?

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.