AAOS SDV - Secure by Design

W Google uważamy, że nasze produkty powinny być bezpieczne już na etapie projektowania. Dlatego system operacyjny Android Automotive dla pojazdów definiowanych przez oprogramowanie (AAOS SDV) został opracowany na bazie sprawdzonych na rynku platform z wykorzystaniem technologii wirtualizacji, takich jak Cuttlefish. W informacjach o wprowadzeniu skupiliśmy się na funkcjach, a w tym poście na blogu przedstawiamy niektóre koncepcje związane z bezpieczeństwem.

Podstawy: izolacja domeny

Wirtualizacja do izolowania instancji współużytkowanych

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, aby uruchamiać wiele instancji równolegle, dzięki czemu udostępnianie jest jawne, a izolacja jest domyślnym zachowaniem.

Dziedziczone zabezpieczenia Androida

AAOS SDV wywodzi się 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 odrzucanie domyślne

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. Korzystamy z funkcji interfejsu POSIX (Portable Operating System Interface), aby ściśle ograniczać operacje, i łączymy je z systemem SELinux (Security-Enhanced Linux), aby wymuszać zasadę „odmowa domyślna”. Dzięki temu każda usługa ma tylko niezbędne uprawnienia, co oznacza, że brakujące konfiguracje blokują dostęp, zamiast tworzyć system o zbyt szerokich uprawnieniach. Stosujemy tę samą strategię 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ę Androida do reagowania na zagrożenia i zarządzania lukami w zabezpieczeniach, aby identyfikować, klasyfikować, usuwać i ujawniać wyniki dotyczące bezpieczeństwa. Obejmuje on ciągłe automatyczne skanowanie, coroczne szczegółowe testy penetracyjne oraz informacje dostarczane przez 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 eliminowania luk do momentu jego zakończenia. Koordynujemy zasady ujawniania i publikowania informacji za pomocą comiesięcznych biuletynów bezpieczeństwa Androida, uzupełnianych przez rygorystyczne okresowe audyty bezpieczeństwa i kompleksowe przeglądy 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. Zapewniamy bezpieczeństwo dostarczania oprogramowania, stosując te metody:

Uwierzytelnione dostarczanie oprogramowania

AAOS SDV udostępnia 2 metody instalacji. Po pierwsze, instalujemy oprogramowanie bezpośrednio w partycjach systemowych, produktowych lub dostawcy tylko do odczytu, które weryfikują podpisy przy każdym rozruchu. 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 przypadku AAOS SDV APEX traktuje podpisywanie kodu jako ciągłą umowę egzekwowaną przez sprzęt. APEX zapewnia ograniczenie wykonywania złośliwego kodu dzięki 4 głównym filarom: 

1. Niezmienne przechowywanie

• 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 użyciem flagi MS_RDONLY.
• Dlaczego ta metoda jest bezpieczniejsza: nie udostępnia ona ścieżki zapisu do systemu operacyjnego, ponieważ pliki nie są rozpakowywane w pamięci pojazdu. Nawet jeśli atakujący uzyska uprawnienia roota, nie będzie mógł zmodyfikować działającego kodu APEX, ponieważ warstwa systemu plików odrzuca wszystkie polecenia zapisu.

2. Integralność kryptograficzna

• Mechanizm: podpis kryptograficzny weryfikuje drzewo Merklego całego obrazu systemu plików.
• Dlaczego jest bezpieczniejsza: jądro używa dm-verity dla każdego bloku, aby weryfikować podpis każdego bloku danych o rozmiarze 4 KB na bieżąco. Jeśli atakujący zmodyfikuje surowy 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 pakietem APEX zamontowanym jako dedykowana partycja w katalogu /apex.
• Dlaczego jest bezpieczniejsza: 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. Dzięki utworzeniu dedykowanej partycji Android tworzy dedykowaną przestrzeń nazw linkera, dzięki czemu tylko jawnie udostępnione biblioteki są dostępne dla nieuprzywilejowanych demonów systemowych, co minimalizuje powierzchnię ataku.

4. Atomic Recovery

• Mechanizm: APEX korzysta z architektury „Aktywny/Zapasowy”, aby umożliwić wycofywanie zmian z podwójnym buforowaniem. APEX zainstalowany fabrycznie pozostaje na niezmiennej partycji /system, a aktualizacje znajdują się na zmiennej partycji /data.
• Dlaczego jest bezpieczniejsza: jeśli aktualizacja się nie powiedzie lub wygląda na złośliwą, demon apexd oznaczy ją jako „nieudaną” na wczesnym etapie uruchamiania. System natychmiast przywraca linki symboliczne do partycji /system. Ta niepodzielna operacja przywracania pomaga zapobiegać pozostawaniu systemu w stanie uszkodzenia.

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

Weryfikowane wczytywanie chroni system przed zewnętrznymi modyfikacjami, ale odporność platformy zależy też od tego, jak zbudowany jest 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 o krótkim czasie dostępności. Uniemożliwia to tworzenie na pełnym stosie Androida, dlatego ograniczyliśmy nasz zakres do natywnej platformy. Aby utworzyć wymaganą infrastrukturę 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 tworzenia 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, a jednocześnie wspierać wydajność 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 SDV w AAOS rozwiązuje ten problem, kryptograficznie weryfikując wersję i autora każdego punktu końcowego komunikacji.

Obsługa administracyjna urządzeń i sieci mesh

AAOS SDV Mesh 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 w sieci mesh jest ciągłe i kryptograficzne. Zapobiega to sytuacjom, w których np. usługa taka jak brama pojazdu ufa skompromitowanej maszynie wirtualnej systemu informacyjno-rozrywkowego tylko dlatego, że ma ona odpowiedni adres IP.

Platforma jest zabezpieczona przez izolację wymuszoną sprzętowo i automatyczne protokoły kwarantanny. Urządzenia równorzędne w sieci typu mesh SDV korzystają z uwierzytelniania i atestowania opartego na DICE, jak opisano w następnej sekcji, aby identyfikować i ograniczać nieautoryzowane wykonanie kodu lub manipulowanie konfiguracją.

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 w oprogramowaniu układowym zmieni się choćby jedna linia kodu (nawet w wyniku niewielkiej aktualizacji lub złośliwego wykorzystania luki w zabezpieczeniach), wygenerowany złożony identyfikator urządzenia (CDI) całkowicie się zmieni, co spowoduje utworzenie zupełnie innego klucza aliasu.

DICE i TLS (Transport Layer Security) są zintegrowane, aby rozwiązać podstawowy problem architektury opartej na zasadzie 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 urządzeniu odbierającemu weryfikację zarówno tożsamości dzwoniącego, jak i dokładnego stanu oprogramowania.

Tradycyjne certyfikaty potwierdzają tylko posiadanie klucza tajnego, ale nie wykrywają ingerencji w oprogramowanie. DICE rozwiązuje ten problem za pomocą warstwowego pomiaru rozruchu:

• Unikalny tajny klucz urządzenia (UDS): losowy tajny klucz kryptograficzny generowany podczas produkcji. Tylko program rozruchowy pierwszego etapu może uzyskać dostęp do UDS. Pozostałe oprogramowanie i interfejsy zewnętrzne nie mają do niego dostępu.
• Pomiar warstwowy (złożony identyfikator urządzenia): pamięć ROM sprzętu inicjuje łańcuch, haszując UDS za pomocą dokładnego kodu i konfiguracji następnej warstwy oprogramowania sprzętowego. Spowoduje to utworzenie CDI, które następnie są łączone sekwencyjnie podczas uruchamiania każdej kolejnej warstwy.

Interakcje usług w siatce AAOS SDV podlegają ścisłej 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 wszystkich urządzeniach w sieci typu mesh za pomocą uwierzytelniania opartego na DICE.

Warstwowa kontrola dostępu

AAOS SDV wykorzystuje strategię obrony warstwowej, 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śl granice komunikacji między maszynami wirtualnymi dla wszystkich usług hostowanych na konkretnej maszynie wirtualnej.

Ten model umożliwia producentom OEM zachowanie równowagi między bezpieczeństwem a możliwością aktualizacji. W przypadku usług, które nie wymagają szczególnych zabezpieczeń, liberalne zasady na poziomie maszyn wirtualnych umożliwiają instalację za pomocą uproszczonych aktualizacji APEX zamiast pełnego ponownego wdrażania maszyn wirtualnych.

Z kolei uprawnienia do sygnałów związanych z bezpieczeństwem muszą być na stałe zakodowane w każdej maszynie wirtualnej. Wprowadzenie usługi wrażliwej na bezpieczeństwo na nowej maszynie wirtualnej wymaga aktualizacji 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 spełniać specyficzne wymagania motoryzacyjne dzięki podejściu „secure-by-design”. Dzięki wykorzystaniu wirtualizacji do izolacji domen i egzekwowaniu zasad dostępu „odmowa domyślna” platforma tworzy odporne środowisko dla pojazdów definiowanych przez oprogramowanie. Integralność kryptograficzna jest zachowywana dzięki weryfikacji wykonywanego kodu w czasie rzeczywistym, która jest wymuszana przez sprzęt.

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 pozwalają producentom OEM zachować równowagę między możliwością aktualizacji zaawansowanych funkcji a solidnymi zabezpieczeniami niezbędnymi w nowoczesnych środowiskach motoryzacyjnych. Specyfikacje techniczne i szczegóły wdrożenia znajdziesz na stronie z omówieniem SDV w AAOS.