Zdalne udostępnianie kluczy Google będzie wymagane w systemie Android 13: co to oznacza dla Ciebie

Kluczowy certyfikat Androida stanowi podstawę wielu zaufanych usług na naszych smartfonach, w tym SafetyNet, Digital Car Key i API poświadczeń tożsamości. Jest wymagany jako część systemu Android od wersji Androida 8 Oreo i był zależny od klucza głównego zainstalowanego na urządzeniu fabrycznie. Dostarczenie tych kluczy wymagało zachowania największej tajemnicy ze strony producenta, a jeśli klucz wyciekłby, oznaczałoby to konieczność jego unieważnienia. Spowodowałoby to, że konsument nie byłby w stanie korzystać z żadnej z tych zaufanych usług, co byłoby niefortunne, gdyby kiedykolwiek istniała luka w zabezpieczeniach, która mogłaby je ujawnić. Zdalne udostępnianie kluczy, które będzie wymagane Androida 13, ma na celu rozwiązanie tego problemu.

Komponenty tworzące bieżący łańcuch zaufania w systemie Android

Przed wyjaśnieniem, jak działa nowy system, ważne jest przedstawienie kontekstu, w jaki sposób 

stary (i nadal działa dla wielu urządzeń) system działa. Obecnie wiele telefonów korzysta z poświadczenia klucza sprzętowego, co może być dla Państwa gwoździem do trumny dowolnego rodzaju obejścia SafetyNet. Istnieje kilka pojęć, które należy zrozumieć w kontekście bieżącego stanu kluczowego poświadczenia.

Połączenie tych koncepcji gwarantuje, że programista może mieć pewność, że urządzenie nie zostało naruszone i że jest w stanie obsłużyć poufne informacje w TEE.

Zaufane środowisko wykonawcze

Zaufane środowisko wykonawcze (TEE) to bezpieczny region SoC używany do obsługi krytycznych danych. TEE jest obowiązkowy na urządzeniach z systemem Android 8 Oreo i nowszym, co oznacza, że ​​ma go każdy nowszy smartfon. Wszystko, co nie znajduje się w TEE, jest uważane za „niezaufane” i umożliwia przeglądanie jedynie zaszyfrowanej zawartości. Na przykład zawartość chroniona systemem DRM jest szyfrowana za pomocą kluczy, do których dostęp można uzyskać wyłącznie za pomocą oprogramowania działającego na TEE. Główny procesor widzi jedynie strumień zaszyfrowanej treści, natomiast treść może zostać odszyfrowana przez TEE, a następnie wyświetlona użytkownikowi.

Strefa zaufania ARM

Trusty to bezpieczny system operacyjny, który zapewnia TEE na Androidzie, a na systemach ARM korzysta z Trustzone ARM. Trusty działa na tym samym procesorze, co podstawowy system operacyjny i ma dostęp do pełnej mocy urządzenia, ale jest całkowicie odizolowany od reszty telefonu. Trusty składa się z następujących elementów:

• Małe jądro systemu operacyjnego pochodzące z Małe jądro
• Sterownik jądra Linux do przesyłania danych pomiędzy bezpiecznym środowiskiem a systemem Android
• Biblioteka przestrzeni użytkownika systemu Android umożliwiająca komunikację z zaufanymi aplikacjami (tj. bezpiecznymi zadaniami/usługami) za pośrednictwem sterownika jądra

Przewagą nad zastrzeżonymi systemami TEE jest to, że te systemy TEE mogą być kosztowne, a także powodować niestabilność w ekosystemie Androida. Trusty jest udostępniane partnerskim producentom OEM przez Google bezpłatnie i ma otwarte oprogramowanie. Android obsługuje inne systemy TEE, ale to Trusty jest tym, na który Google naciska najbardziej.

Kasa pancerna

Urządzenia StrongBox to całkowicie oddzielne, specjalnie zaprojektowane i certyfikowane bezpieczne procesory. Mogą one obejmować wbudowane bezpieczne elementy (eSE) lub jednostkę bezpiecznego przetwarzania wbudowaną w SoC (SPU). Google twierdzi, że obecnie „zdecydowanie zaleca się”, aby StrongBox był dołączany do urządzeń uruchamianych z systemem Androida 12 (zgodnie z dokumentem definicji zgodności), ponieważ prawdopodobnie stanie się to wymogiem w przyszłej wersji Androida. Zasadniczo jest to bardziej rygorystyczna implementacja magazynu kluczy wspieranego sprzętowo i można ją wdrożyć razem z TrustZone. Przykładem wdrożenia StrongBox jest chip Titan M w smartfonach Pixel. Niewiele telefonów korzysta z StrongBox, a większość korzysta z Trustzone ARM.

Klucznik TA

Zaufana aplikacja Keymaster (TA) to bezpieczny klucznik, który zarządza i wykonuje wszystkie operacje na magazynie kluczy. Może działać na przykład w TrustZone firmy ARM.

Jak zmienia się atestowanie kluczy w systemach Android 12 i Android 13

Jeśli klucz zostanie ujawniony na smartfonie z Androidem, Google ma obowiązek go unieważnić. Stanowi to problem w przypadku każdego urządzenia, do którego fabrycznie wstrzyknięto klucz — jakikolwiek wyciek ujawniający klucz oznaczałby, że użytkownicy nie będą mogli uzyskać dostępu do niektórych chronionych treści. Może to nawet obejmować odebranie dostępu do usług takich jak Google Pay, na czym polega wiele osób. Jest to niefortunne dla konsumentów, ponieważ bez naprawy telefonu przez producenta nie byłoby możliwości samodzielnej naprawy.

Wprowadź zdalne udostępnianie kluczy. Począwszy od Androida 12, Google zastępuje fabryczne udostępnianie kluczy prywatnych kombinacją Fabryczna ekstrakcja klucza publicznego i bezprzewodowe udostępnianie certyfikatów o krótkotrwałym działaniu certyfikaty. Ten schemat będzie wymagany w systemie Android 13 i wiąże się z nim kilka korzyści. Przede wszystkim uniemożliwia producentom OEM i ODM zarządzanie tajemnicą kluczy w fabryce. Po drugie, umożliwia odzyskanie urządzeń w przypadku kradzieży ich kluczy, co oznacza, że ​​konsumenci nie stracą na zawsze dostępu do chronionych usług. Teraz zamiast korzystać z certyfikatu obliczonego na podstawie klucza znajdującego się na urządzeniu i mogącego wyciekać przez luki w zabezpieczeniach, za każdym razem, gdy usługa wymagająca zaświadczenia, żąda się od Google certyfikatu tymczasowego używany.

Jeśli chodzi o sposób działania, jest on dość prosty. Każde urządzenie generuje unikalną, statyczną parę kluczy, a publiczna część tej pary kluczy jest wyodrębniana przez producenta OEM w jego fabryce i przesyłana na serwery Google. Tam będą służyć jako podstawa zaufania do późniejszego zaopatrzenia. Klucz prywatny nigdy nie opuszcza bezpiecznego środowiska, w którym został wygenerowany.

Gdy urządzenie zostanie po raz pierwszy użyte do połączenia z Internetem, wygeneruje żądanie podpisania certyfikatu wygenerowanych przez siebie kluczy, podpisując go kluczem prywatnym odpowiadającym kluczowi publicznemu zebranemu w fabryka. Serwery backendu Google zweryfikują autentyczność żądania, a następnie podpiszą klucze publiczne, zwracając łańcuchy certyfikatów. Magazyn kluczy na urządzeniu będzie następnie przechowywać te łańcuchy certyfikatów, przypisując je do aplikacji za każdym razem, gdy zostanie zażądane zaświadczenie. Może to być wszystko, od Google Pay po Pokemon Go.

Ten dokładny łańcuch żądań certyfikatów będzie się powtarzał regularnie po wygaśnięciu certyfikatów lub wyczerpaniu bieżącego zapasu kluczy. Każda aplikacja otrzymuje inny klucz atestacyjny, a same klucze są regularnie zmieniane, co zapewnia prywatność. Ponadto serwery zaplecza Google są podzielone w taki sposób, że serwer weryfikujący klucz publiczny urządzenia nie widzi dołączonych kluczy atestacyjnych. Oznacza to, że Google nie może powiązać kluczy atestacyjnych z konkretnym urządzeniem, które je zażądało.

Użytkownicy końcowi nie zauważą żadnych zmian, choć według Google programiści muszą zwrócić uwagę na następujące kwestie.

• Struktura łańcucha certyfikatów
  • Ze względu na charakter naszej nowej infrastruktury świadczenia usług online długość łańcucha jest dłuższa niż poprzednio i może ulec zmianie.
• Korzeń zaufania
  • Katalog główny zaufania zostanie ostatecznie zaktualizowany z bieżącego klucza RSA do klucza ECDSA.
• Wycofanie zaświadczenia RSA
  • Wszystkie klucze wygenerowane i poświadczone przez KeyMint zostaną podpisane kluczem ECDSA i odpowiednim łańcuchem certyfikatów. Wcześniej klucze asymetryczne były podpisywane przez odpowiadający im algorytm.
• Certyfikaty krótkotrwałe i klucze atestacyjne
  • Certyfikaty dostarczane do urządzeń będą zazwyczaj ważne przez maksymalnie dwa miesiące, zanim wygasną i zostaną rotowane.

Skontaktowaliśmy się z Google i zapytaliśmy, czy ma to jakiekolwiek znaczenie dla Widevine DRM i w jaki sposób niektórzy użytkownicy Pixela zgłaszali obniżenie poziomu DRM przy zablokowanym programie ładującym. Zapytaliśmy również, czy można to teraz udostępnić użytkownikom jako aktualizację OTA za pośrednictwem Usług Google Play. Z pewnością zaktualizujemy ten artykuł, jeśli otrzymamy odpowiedź. Nie jest jasne, które elementy obecnego łańcucha zaufania i w jaki sposób zostaną dotknięte.

---

Źródło: Google