AAOS SDV - Secure by Design

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 bazie sprawdzonych na rynku platform, wykorzystując technologie wirtualizacji, takie jak Cuttlefish. W ogłoszeniach o wprowadzeniu nowych funkcji 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 do równoległego uruchamiania wielu instancji, dzięki czemu udostępnianie jest zawsze 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 temu inżynierowie platformy Android mają do dyspozycji sprawdzone funkcje 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. Korzystamy z funkcji interfejsu POSIX (Portable Operating System Interface), aby ściśle ograniczać operacje, i łączymy je z technologią SELinux (Security-Enhanced Linux), aby wymuszać zasadę „odmowa domyślna”. Takie 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. 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 incydenty związane z bezpieczeństwem i zarządzania lukami w zabezpieczeniach, aby identyfikować, klasyfikować, usuwać i ujawniać problemy z bezpieczeństwem. Obejmuje on 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 eliminowania luk do momentu jego zakończenia. Koordynujemy zasady ujawniania i publikowania informacji za pomocą comiesięcznych biuletynów bezpieczeństwa Androida, uzupełnianych o rygorystyczne okresowe audyty bezpieczeństwa i szczegółowe 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 systemu, produktu 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 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 urządzenie pamięci masowej w trybie 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 Merkle całego obrazu systemu plików.
• Dlaczego jest bezpieczniejsza: 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 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 APEX-em zamontowanym jako dedykowana partycja w katalogu /apex.
• Dlaczego jest 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. Dzięki utworzeniu dedykowanej partycji Android tworzy dedykowaną przestrzeń nazw linkera, co zapewnia, że tylko jawnie udostępnione biblioteki są dostępne dla nieuprzywilejowanych demonów systemowych, a tym samym 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ą” podczas wczesnego uruchamiania. System natychmiast przywraca linki symboliczne do partycji /system. Ta niepodzielna operacja przywracania pomaga zapewnić, że system nie pozostanie 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 stworzyć wymaganą infrastrukturę systemu rozproszonego, opracowaliśmy wiele komponentów, które uzupełniają istniejącą infrastrukturę. Jako podstawowy język programowania wybraliśmy Rust. 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

Siatka AAOS SDV ustanawia uwierzytelnianie przez matematyczne powiązanie tożsamości sieciowej każdego komponentu z 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 na przykład usługa taka jak brama pojazdu ufa przejętej maszynie wirtualnej systemu infotainment 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

Potwierdzanie tożsamości gospodarza

Złota zasada DICE (Device Identifier Composition Engine): jeśli w oprogramowaniu układowym zmieni się jedna linia kodu (nawet w wyniku niewielkiej aktualizacji lub złośliwego wykorzystania luki w zabezpieczeniach), wynikowy złożony identyfikator urządzenia (CDI) całkowicie się zmieni, generując zupełnie inny klucz 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 połączenia 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 sprzętowe. DICE rozwiązuje ten problem za pomocą warstwowego pomiaru rozruchu:

• Unikalny klucz urządzenia (UDS): losowy klucz kryptograficzny generowany podczas produkcji. Dostęp do UDS ma tylko program rozruchowy pierwszego etapu. 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 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 mieć 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 uprawnień na poziomie maszyny wirtualnej w całym systemie. Wymaga to zaktualizowania 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 solidnym zabezpieczeniem niezbędnym w nowoczesnych środowiskach motoryzacyjnych. Specyfikacje techniczne i szczegóły wdrożenia znajdziesz na stronie z omówieniem AAOS SDV.