Wiadomości o usłudze

AAOS SDV - Secure by Design

Czas czytania: 5 min
3 Autorzy
Markus Vill, Sean Keys, István Nádor

W Google uważamy, że nasze usługi powinny być bezpieczne już na etapie projektowania. Dlatego stworzyliśmy system operacyjny Android Automotive dla pojazdów definiowanych programowo (AAOS SDV) na istniejących, sprawdzonych na rynku platformach, wykorzystując technologie wirtualizacji, takie jak Cuttlefish. Nasze ogłoszenia o nowych wersjach skupiają się na funkcjach, ale w tym poście na blogu przedstawiamy niektóre koncepcje dotyczące bezpieczeństwa.

Podstawowy: izolacja domeny

Wirtualizacja w celu izolowania instancji współhostowanych

Obecny trend polegający na konsolidacji elektronicznych jednostek sterujących (ECU) w jednym układzie scalonym zmniejsza izolację, ponieważ wiele domen działa obok siebie.

Chociaż instancje SDV AAOS zapewniają wewnętrzne mechanizmy izolacji, często lepiej jest uruchamiać domeny logiczne niezależnie. Na przykład panel wskaźników i system multimedialny mają różne wymagania. Używamy maszyn wirtualnych do równoległego uruchamiania wielu instancji, dzięki czemu udostępnianie pozostaje wyraźne, a izolacja jest działaniem domyślnym.

Dziedziczone zabezpieczenia Androida

AAOS SDV powstał na bazie Microdroida, minimalistycznej wersji Androida zoptymalizowanej pod kątem prywatnych maszyn wirtualnych (pVM). Ta linia zapewnia inżynierom platformy Androida sprawdzone funkcje zabezpieczeń, które już znają.

Izolacja procesów i domyślne odrzucanie

SDV AAOS korzysta z modelu izolacji opartego na identyfikatorze użytkownika (UID) Androida, aby skonfigurować piaskownicę dla każdej aplikacji. Każda usługa działa w dedykowanym procesie z unikalnym identyfikatorem UID, który służy do zarządzania uprawnieniami dostępu, katalogami danych i innymi ograniczeniami. Używamy funkcji POSIX (Portable Operating System Interface), aby ściśle ograniczyć operacje, i łączymy je z systemem Security-Enhanced Linux (SELinux), aby wymusić postawę „domyślnej odmowy”. To podejście ogranicza każdą usługę do absolutnego minimum, co oznacza, że brakujące konfiguracje blokują dostęp, zamiast tworzyć system o zbyt szerokich uprawnieniach. Tę samą strategię stosujemy w naszym systemie uprawnień do komunikacji, co wyjaśniamy w dalszej części tego artykułu.

Sprawdzone zarządzanie lukami w zabezpieczeniach

AAOS SDV integruje dojrzałą infrastrukturę reagowania na zagrożenia i zarządzania lukami w zabezpieczeniach Androida, aby identyfikować, klasyfikować, eliminować i ujawniać wyniki dotyczące bezpieczeństwa. Ten cykl życia obejmuje ciągłe automatyczne skanowanie, coroczne szczegółowe testy penetracyjne i analizy partnerów w ramach procesu zgłaszania luk w zabezpieczeniach Androida. Zespół ds. bezpieczeństwa klasyfikuje wykryte luki w zabezpieczeniach, przypisuje im oceny ważności na podstawie ryzyka i śledzi proces ich eliminowania aż do zakończenia. Koordynujemy zasady ujawniania i publikowania informacji za pomocą comiesięcznych Biuletynów bezpieczeństwa w Androidzie, które są uzupełniane rygorystycznymi okresowymi audytami bezpieczeństwa i kompleksowymi przeglądami architektury, aby zapewnić długoterminową odporność platformy.

Integralność: bezpieczne dostarczanie oprogramowania

Oprócz gwarancji izolacji procesów bezpieczna platforma musi zapewniać integralność kodu przed jego wykonaniem. Zabezpieczamy dostarczanie oprogramowania za pomocą tych metod:

Uwierzytelnione dostarczanie oprogramowania

AAOS SDV udostępnia 2 metody instalacji. Po pierwsze instalujemy oprogramowanie bezpośrednio na partycjach systemowych, produktowych lub dostawcy, które są tylko do odczytu i weryfikują podpisy przy każdym uruchomieniu. Zabezpiecza to podstawowe komponenty systemu.

Po drugie, w przypadku usług używamy pakietów Android Pony EXpress (APEX). Każdy plik APEX zawiera oprogramowanie i jego zależności, traktując pakiet jako partycję z obowiązkową weryfikacją podpisu. W SDV AAOS APEX traktuje podpisywanie kodu jako ciągłą umowę egzekwowaną przez sprzęt. APEX ogranicza wykonywanie złośliwego kodu dzięki 4 głównym filarom: 

1. Niezmienne miejsce na dane

  • Mechanizm: jądro Androida zapętla plik apex_payload.img bezpośrednio jako nieprzetworzone urządzenie pamięci masowej, używając sprzężenia zwrotnego tylko do odczytu i montując go z flagą MS_RDONLY.
  • Dlaczego ta metoda jest bezpieczniejsza: nie ujawnia ścieżki zapisu systemowi operacyjnemu, ponieważ pliki nie są rozpakowywane w pamięci pojazdu. Nawet jeśli atakujący uzyska uprawnienia administratora, nie będzie mógł zmodyfikować uruchomionego kodu APEX, ponieważ warstwa systemu plików odrzuca wszystkie polecenia zapisu.

2. Integralność kryptograficzna

  • Mechanizm: podpis kryptograficzny weryfikuje drzewo Merkle całego obrazu systemu plików.
  • Dlaczego jest to bezpieczniejsze: jądro używa dm-verity dla każdego bloku, aby na bieżąco weryfikować podpis każdego bloku danych o rozmiarze 4 KB. Jeśli haker zmodyfikuje nieprzetworzony blok w pamięci flash, jądro wykryje niezgodność skrótu i natychmiast zatrzyma wykonywanie.

3. Ścisłe odizolowanie

  • Mechanizm: stosuje reguły izolacji procesów opisane w sekcji Izolacja procesów, aby utworzyć piaskownicę z APEX zamontowanym jako dedykowana partycja w katalogu /apex.
  • Dlaczego jest to bezpieczniejsze: każda usługa otrzymuje własny katalog użytkowników i danych, co ogranicza dostęp, chyba że udostępnianie jest wyraźnie dozwolone. Tworząc dedykowaną partycję, Android ustanawia dedykowaną przestrzeń nazw linkera, dzięki czemu tylko jawnie udostępnione biblioteki są dostępne z poziomu demonów systemowych bez uprawnień, co minimalizuje powierzchnię ataku.

4. Odzyskiwanie niepodzielne

  • Mechanizm: APEX używa modelu „Aktywny/Kopia zapasowa”, aby umożliwić przywracanie z podwójnym buforowaniem. Zainstalowany fabrycznie APEX pozostaje na niezmiennej partycji /system, a aktualizacje znajdują się na zmiennej partycji /data.
  • Dlaczego jest to bezpieczniejsze: jeśli aktualizacja się nie powiedzie lub okaże się szkodliwa, demon apexd oznaczy ją jako „nieudaną” podczas wczesnego rozruchu. System natychmiast zamienia łącza symboliczne z powrotem na partycję /system. To niepodzielne przywracanie pomaga zapewnić, że system nie pozostanie w stanie uszkodzenia.

Odporność: programowanie z bezpiecznym zarządzaniem pamięcią

Weryfikowane wczytywanie chroni system przed modyfikacjami zewnętrznymi, ale odporność platformy zależy też od sposobu utworzenia kodu bazowego. W przypadku nowych komponentów opracowanych na potrzeby SDV AAOS priorytetem było bezpieczeństwo pamięci.

Rust jako główny język

AAOS SDV jest przeznaczony dla małych systemów, które muszą być szybko dostępne. Uniemożliwia to tworzenie na pełnym stosie Androida, dlatego ograniczyliśmy zakres do platformy natywnej. Aby utworzyć infrastrukturę wymaganą dla systemu rozproszonego, opracowaliśmy kilka komponentów oprócz istniejącej infrastruktury i przyjęliśmy Rust jako główny język. Używamy też języka Rust do tworzenia logiki biznesowej usług, co pomaga partnerom pisać bezpieczne oprogramowanie. Rust wykorzystuje funkcje bezpieczeństwa pamięci, aby zapobiegać typowym klasom luk w zabezpieczeniach pamięci, a jednocześnie wspierać przepustowość zespołu podczas pisania kodu natywnego.

Zaufanie rozproszone: sieć i kontrola dostępu

Pojazdy definiowane programowo wymagają bezpiecznych interakcji między odizolowanymi domenami. Architektura obsługi sieci SDV w systemie AAOS rozwiązuje ten problem, weryfikując kryptograficznie wersję i autora każdego punktu końcowego komunikacji.

Udostępnianie urządzeń i siatki

Siatka SDV AAOS ustanawia uwierzytelnianie przez matematyczne powiązanie tożsamości sieciowej każdego komponentu z jego rzeczywistym stanem wykonywania kodu binarnego. Ten model zastępuje domyślne zaufanie do oprogramowania weryfikacją opartą na sprzęcie.

Uwierzytelnianie w sieci kratowej jest ciągłe i kryptograficzne. Zapobiega to sytuacjom, w których np. usługa taka jak brama pojazdu ufa przejętej maszynie wirtualnej systemu multimedialno-rozrywkowego tylko dlatego, że ma ona prawidłowy adres IP.

Platforma jest zabezpieczona przez izolację wymuszaną sprzętowo i automatyczne protokoły kwarantanny. Urządzenia równorzędne w sieci SDV korzystają z uwierzytelniania i atestacji opartej na DICE, jak opisano w następnej sekcji, aby ułatwić identyfikację i ograniczenie nieautoryzowanego wykonywania kodu lub manipulowania konfiguracją.

Protokół TLS oparty na DICE do zabezpieczania komunikacji między maszynami wirtualnymi

Ugruntowanie tożsamości gospodarza w rzeczywistości

Złota zasada DICE (Device Identifier Composition Engine): jeśli zmieni się choćby jedna linijka kodu w oprogramowaniu układowym (nawet w przypadku drobnej aktualizacji lub złośliwego exploita), pochodny identyfikator urządzenia złożonego (CDI) zmieni się całkowicie, generując zupełnie inny klucz aliasu.

DICE i TLS (Transport Layer Security) są zintegrowane, aby rozwiązać podstawowe wyzwanie związane z architekturą zero-trust: uwierzytelnianie komputera przy jednoczesnej weryfikacji integralności jego oprogramowania.

Połączenie identyfikacji sprzętowej DICE i szyfrowanego uzgadniania TLS umożliwia maszynie odbierającej zweryfikowanie zarówno tożsamości dzwoniącego, jak i dokładnego stanu oprogramowania.

Tradycyjne certyfikaty potwierdzają jedynie posiadanie obiektu tajnego, ale nie mogą wykryć ingerencji w oprogramowanie układowe. DICE rozwiązuje ten problem za pomocą warstw rozruchu mierzonego:

  • Unikalny klucz tajny urządzenia (UDS): losowy klucz kryptograficzny generowany podczas produkcji. Tylko program rozruchowy pierwszego etapu ma dostęp do UDS. Pozostaje on niedostępny dla wszystkich innych programów i interfejsów zewnętrznych.
  • Pomiary warstwowe (identyfikator urządzenia złożonego): sprzętowa pamięć ROM inicjuje łańcuch, haszując UDS z dokładnym kodem i konfiguracją następnej warstwy oprogramowania układowego. W ten sposób tworzony jest identyfikator CDI, który następnie jest sekwencyjnie łączony w łańcuch podczas uruchamiania każdej kolejnej warstwy.

Interakcje usług w ramach sieci SDV AAOS są regulowane przez rygorystyczne mechanizmy kontroli dostępu. Podobnie jak w przypadku całego oprogramowania SDV w AAOS, te mechanizmy kontroli dostępu są uwierzytelniane, a ich integralność jest chroniona na poziomie urządzenia i na różnych urządzeniach w sieci kratowej za pomocą uwierzytelniania opartego na DICE.

Warstwowa kontrola dostępu

AAOS SDV stosuje strategię obrony w głąb, aby umożliwić dynamiczne aktualizacje pojazdu bez naruszania mechanizmów dostępu. Ten model opiera się na 2 głównych warstwach zaufania:

  1. Uprawnienia na poziomie usługi: określają konkretne zasoby, do których usługa na danej maszynie wirtualnej może uzyskiwać dostęp lub które może udostępniać w siatce.
  2. Uprawnienia na poziomie maszyny wirtualnej: określają granice komunikacji między maszynami wirtualnymi w przypadku wszystkich usług hostowanych na konkretnej maszynie wirtualnej.

Ten model pozwala producentom OEM zachować równowagę między bezpieczeństwem a możliwością aktualizacji. W przypadku usług, które nie są wrażliwe pod względem bezpieczeństwa, mniej restrykcyjne zasady na poziomie maszyny wirtualnej umożliwiają instalację za pomocą uproszczonych aktualizacji APEX, a nie pełnego ponownego wdrażania maszyny wirtualnej.

Z kolei uprawnienia do sygnałów związanych z bezpieczeństwem muszą być zakodowane na stałe w każdej maszynie wirtualnej. Wadą jest to, że wprowadzenie usługi związanej z bezpieczeństwem do nowej maszyny wirtualnej wymaga aktualizacji uprawnień na poziomie maszyny wirtualnej w całym systemie. Wymaga to aktualizacji wszystkich maszyn wirtualnych w siatce.

Podsumowanie

image.png

AAOS SDV rozszerza architekturę zabezpieczeń Androida, aby spełniać określone wymagania motoryzacyjne dzięki podejściu „bezpieczeństwo od podstaw”. Dzięki wykorzystaniu wirtualizacji do izolacji domen i egzekwowaniu zasad dostępu „domyślnie odmawiaj” platforma tworzy odporne środowisko dla pojazdów definiowanych programowo. Integralność kryptograficzna jest utrzymywana dzięki wymuszanej sprzętowo weryfikacji wykonywanego kodu na bieżąco.

Platforma integruje ciągłe cykle życia zabezpieczeń, od proaktywnego zarządzania lukami w zabezpieczeniach po weryfikację tożsamości na poziomie sprzętowym za pomocą DICE. Te wielowarstwowe zabezpieczenia pozwalają producentom OEM zachować równowagę między możliwością aktualizowania zaawansowanych funkcji a solidnymi zabezpieczeniami niezbędnymi w nowoczesnych środowiskach motoryzacyjnych. Dane techniczne i szczegóły implementacji znajdziesz na stronie z omówieniem SDV w AAOS.

Autor:
Czytaj dalej