AAOS SDV – bezpieczeństwo przede wszystkim

W Google uważamy, że nasze produkty powinny być bezpieczne już na etapie projektowania. Dlatego stworzyliśmy system operacyjny Android Automotive dla pojazdów definiowanych przez oprogramowanie (AAOS SDV) na podstawie istniejących, sprawdzonych na rynku platform, wykorzystując technologie wirtualizacji, takie jak Cuttlefish. W komunikatach o wydaniu skupiliśmy się na funkcjach, ale w tym poście na blogu przedstawiamy niektóre koncepcje związane z bezpieczeństwem.

Podstawa: izolacja domen

Wirtualizacja do izolowania instancji współdzielonych

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

Chociaż instancje AAOS SDV zapewniają wewnętrzne mechanizmy izolacji, często lepiej jest uruchamiać domeny logiczne niezależnie. Na przykład klaster i system multimedialny mają różne wymagania. Używamy maszyn wirtualnych do równoległego uruchamiania wielu instancji, co zapewnia, że udostępnianie pozostaje jawne, a izolacja jest domyślnym zachowaniem.

Dziedziczone zabezpieczenia Androida

AAOS SDV wyewoluował z Microdroida, minimalistycznej wersji Androida zoptymalizowanej pod kątem maszyn wirtualnych chroniących prywatność (pVM). Dzięki tej historii danych inżynierowie platformy Androida mają dostęp do sprawdzonych funkcji zabezpieczeń, które już znają.

Izolacja procesów i domyślne odrzucanie

AAOS SDV 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 osobnym procesie z unikalnym identyfikatorem UID, który służy do zarządzania prawami dostępu, katalogami danych i innymi ograniczeniami. Wykorzystujemy możliwości interfejsu Portable Operating System Interface (POSIX), aby ściśle ograniczyć operacje, i łączymy je z systemem Security-Enhanced Linux (SELinux), aby wymusić postawę „domyślnego odrzucania”. Dzięki temu każda usługa jest ograniczona do absolutnego minimum, co oznacza, że brakujące konfiguracje blokują dostęp, zamiast tworzyć system o nadmiernych uprawnieniach. Tę samą strategię stosujemy w przypadku naszego systemu 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ć, usuwać i ujawniać problemy z bezpieczeństwem. Ten cykl życia obejmuje ciągłe automatyczne skanowanie, coroczne szczegółowe testy penetracyjne oraz informacje od partnerów przekazywane 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 usuwania problemów aż do jego zakończenia. Koordynujemy zasady ujawniania i wydawania informacji za pomocą comiesięcznych biuletynów bezpieczeństwa Androida, uzupełnianych 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 zapewnić integralność kodu przed jego wykonaniem. Bezpieczne dostarczanie oprogramowania zapewniamy dzięki tym metodom:

Uwierzytelnione dostarczanie oprogramowania

AAOS SDV oferuje 2 metody instalacji. Po pierwsze, instalujemy oprogramowanie bezpośrednio w partycjach systemu, produktu lub dostawcy tylko do odczytu, które sprawdzają 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 pakiet APEX zawiera oprogramowanie i jego zależności, traktując pakiet jako partycję z obowiązkową weryfikacją podpisu. W AAOS SDV pakiet APEX traktuje podpisywanie kodu jako ciągłą umowę wymuszaną przez sprzęt. Pakiet APEX zapewnia, że wykonanie złośliwego kodu jest ograniczone dzięki 4 głównym filarom: 

1. Niezmienny magazyn

• Mechanizm: jądro Androida bezpośrednio zapętla plik apex_payload.img jako surowe urządzenie pamięci masowej za pomocą sprzężenia zwrotnego tylko do odczytu, montując go z rygorystyczną flagą MS_RDONLY.
• Dlaczego jest bezpieczniejszy: nie ma ścieżki zapisu do systemu operacyjnego, ponieważ pliki nie są rozpakowywane w pamięci pojazdu. Nawet jeśli osoba atakująca uzyska uprawnienia roota, nie może 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 bezpieczniejszy: jądro używa dm-verity na poziomie bloku, aby na bieżąco weryfikować podpis każdego bloku danych o rozmiarze 4 KB. Jeśli osoba atakująca zmodyfikuje surowy blok w pamięci flash, jądro wykryje niezgodność skrótu i natychmiast zatrzyma wykonanie.

3. Ścisłe odizolowanie

• Mechanizm: stosuje reguły izolacji procesów opisane w sekcji Izolacja procesów, aby utworzyć piaskownicę, w której pakiet APEX jest zamontowany jako osobna partycja w katalogu /apex.
• Dlaczego jest bezpieczniejszy: każda usługa otrzymuje własny katalog użytkownika i danych, co ogranicza dostęp, chyba że udostępnianie jest jawne. Dzięki utworzeniu osobnej partycji Android tworzy osobną przestrzeń nazw linkera, co zapewnia, że tylko jawnie udostępnione biblioteki są dostępne dla demonów systemowych bez podwyższonych uprawnień, co minimalizuje powierzchnię ataku.

4. Odzyskiwanie atomowe

• Mechanizm: pakiet APEX używa projektu „Aktywny/Zapasowy”, aby umożliwić wycofywanie zmian z podwójnym buforowaniem. Pakiet APEX zainstalowany fabrycznie pozostaje w niezmiennej partycji /system, a aktualizacje znajdują się w zmiennej partycji /data.
• Dlaczego jest bezpieczniejszy: jeśli aktualizacja się nie powiedzie lub wygląda na złośliwą, demon apexd oznaczy ją jako „nieudaną” podczas wczesnego uruchamiania. System natychmiast przełączy linki symboliczne z powrotem do partycji /system. To atomowe odzyskiwanie pomaga zapewnić, że system nie pozostanie w stanie uszkodzenia.

Odporność: tworzenie oprogramowania bezpiecznego dla pamięci

Weryfikacja ładowania chroni system przed modyfikacjami zewnętrznymi, ale odporność platformy zależy też od tego, jak jest zbudowany kod źródłowy. W przypadku nowych komponentów opracowanych dla AAOS SDV priorytetem było bezpieczeństwo pamięci.

Rust jako język podstawowy

AAOS SDV jest przeznaczony dla małych systemów z szybkimi wymaganiami dotyczącymi dostępności. Uniemożliwia to tworzenie oprogramowania na pełnym stosie Androida, dlatego ograniczyliśmy nasz zakres do natywnego frameworka. Aby utworzyć wymaganą infrastrukturę dla systemu rozproszonego, oprócz istniejącej infrastruktury opracowaliśmy wiele komponentów i przyjęliśmy język Rust jako język podstawowy. Używamy też języka Rust do opracowywania logiki biznesowej usług, co pomaga partnerom pisać bezpieczne oprogramowanie. Z założenia Rust wykorzystuje funkcje bezpieczeństwa pamięci, aby zapobiegać typowym klasom luk w zabezpieczeniach pamięci, jednocześnie wspierając przepustowość zespołu podczas pisania kodu natywnego.

Zaufanie rozproszone: kontrola sieci i dostępu

Pojazdy definiowane przez oprogramowanie wymagają bezpiecznych interakcji między odizolowanymi domenami. Architektura udostępniania siatki AAOS SDV rozwiązuje ten problem, kryptograficznie weryfikując wersję i autora każdego punktu końcowego komunikacji.

Udostępnianie urządzeń i siatki

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

Uwierzytelnianie sieci typu mesh jest zaprojektowane tak, aby było ciągłe i kryptograficzne. Zapobiega to sytuacjom, w których np. usługa taka jak brama pojazdu ufa naruszonej maszynie wirtualnej informacyjno-rozrywkowej tylko dlatego, że ma ona prawidłowy adres IP.

Izolacja wymuszana przez sprzęt i automatyczne protokoły kwarantanny zabezpieczają platformę. Urządzenia równorzędne w siatce SDV używają uwierzytelniania i atestacji opartych na DICE, jak opisano w następnej sekcji, aby pomóc w identyfikowaniu i ograniczaniu nieautoryzowanego wykonywania kodu lub manipulowania konfiguracją.

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

Ugruntowanie tożsamości hosta w rzeczywistości

Złota zasada DICE (Device Identifier Composition Engine): jeśli zmieni się choćby jedna linia kodu w oprogramowaniu układowym (nawet drobna aktualizacja lub złośliwy exploit), pochodny złożony identyfikator urządzenia (CDI) zmieni się całkowicie, generując zupełnie inny klucz aliasu.

DICE i TLS (Transport Layer Security) integrują się, aby rozwiązać podstawowy problem architektury zerowego zaufania: uwierzytelnianie maszyny przy jednoczesnej weryfikacji integralności jej oprogramowania.

Połączenie identyfikacji opartej na sprzęcie 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ą tylko posiadanie tajnego klucza. Nie mogą wykryć manipulacji oprogramowaniem układowym. DICE rozwiązuje ten problem za pomocą warstwowego pomiaru rozruchu:

• Unikalny tajny klucz urządzenia (UDS): losowy tajny klucz kryptograficzny wygenerowany podczas produkcji. Tylko program rozruchowy pierwszego etapu może uzyskać dostęp do UDS. Pozostaje on niedostępny dla całego innego oprogramowania i interfejsów zewnętrznych.
• Pomiar warstwowy (złożony identyfikator urządzenia): sprzętowy ROM inicjuje łańcuch, haszując UDS za pomocą dokładnego kodu i konfiguracji następnej warstwy oprogramowania układowego. Tworzy to CDI, który następnie jest łączony sekwencyjnie podczas uruchamiania każdej kolejnej warstwy.

Interakcje usług w siatce AAOS SDV są regulowane przez ścisłe kontrole dostępu. Podobnie jak całe oprogramowanie AAOS SDV, te kontrole dostępu są uwierzytelniane, a ich integralność jest chroniona na poziomie urządzenia i na wszystkich urządzeniach w sieci typu mesh 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 podstawowych warstwach zaufania:

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

Ten model umożliwia producentom OEM zrównoważenie bezpieczeństwa i możliwości aktualizacji. W przypadku usług niewrażliwych na bezpieczeństwo liberalne zasady na poziomie maszyny wirtualnej umożliwiają instalację za pomocą lekkich aktualizacji APEX, a nie pełnego ponownego wdrażania maszyny wirtualnej.

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

Podsumowanie

AAOS SDV rozszerza architekturę zabezpieczeń Androida, aby uwzględnić konkretne wymagania motoryzacyjne, stosując podejście „bezpieczeństwo przede wszystkim”. Dzięki wykorzystaniu wirtualizacji do izolacji domen i wymuszaniu zasad dostępu „domyślne odrzucanie” platforma tworzy odporne środowisko dla pojazdów definiowanych przez oprogramowanie. Integralność kryptograficzna jest utrzymywana dzięki wymuszanej przez sprzęt 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 opartą na sprzęcie za pomocą DICE. Te wielowarstwowe zabezpieczenia umożliwiają producentom OEM zrównoważenie możliwości aktualizacji zaawansowanych funkcji z solidnym bezpieczeństwem niezbędnym w nowoczesnych środowiskach motoryzacyjnych. Specyfikacje techniczne i szczegóły implementacji są dostępne na stronie przeglądu AAOS SDV.