AAOS SDV – Von Grund auf sicher

Bei Google sind wir der Meinung, dass unsere Produkte von Grund auf sicher sein sollten. Deshalb haben wir das Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) auf bestehenden, markterprobten Plattformen entwickelt und dabei Virtualisierungstechnologien wie Cuttlefish genutzt. In unseren Versionshinweisen haben wir uns auf die Funktionen konzentriert. In diesem Blogpost werden einige der Sicherheitskonzepte beschrieben.

Grundlage: Domain-Isolation

Virtualisierung zur Isolation von gemeinsam gehosteten Instanzen

Der aktuelle Trend, Steuergeräte (Electronic Control Units, ECUs) auf einem einzigen Chip zu konsolidieren, verringert die Isolation, da mehrere Domains nebeneinander ausgeführt werden.

AAOS SDV-Instanzen bieten zwar interne Isolationsmechanismen, es ist jedoch oft besser, logische Domains unabhängig voneinander auszuführen. So haben beispielsweise ein Kombiinstrument und ein Infotainmentsystem unterschiedliche Anforderungen. Wir verwenden virtuelle Maschinen, um mehrere Instanzen parallel auszuführen. So wird sichergestellt, dass die Freigabe explizit erfolgt und die Isolation das Standardverhalten ist.

Übernommene Android-Sicherheit

AAOS SDV ist aus Microdroid hervorgegangen, einer minimalistischen Android-Version, die für vertrauliche virtuelle Maschinen (pVM) optimiert ist. Diese Herkunft bietet Android-Plattformentwicklern etablierte Sicherheitsfunktionen, die sie bereits kennen.

Prozessisolation und standardmäßige Ablehnung

AAOS SDV folgt dem auf Android-Nutzer-IDs (UIDs) basierenden Isolationsmodell, um für jede Anwendung eine Sandbox einzurichten. Jeder Dienst wird in einem eigenen Prozess mit einer eindeutigen UID ausgeführt, um Zugriffsrechte, Datenverzeichnisse und andere Einschränkungen zu verwalten. Wir nutzen POSIX-Funktionen (Portable Operating System Interface), um Vorgänge streng zu begrenzen, und kombinieren diese mit Security-Enhanced Linux (SELinux), um eine standardmäßige Ablehnung zu erzwingen. Bei diesem Ansatz wird jeder Dienst auf das absolut erforderliche Minimum beschränkt. Das bedeutet, dass fehlende Konfigurationen den Zugriff blockieren, anstatt ein übermäßig permissives System zu schaffen. Wir wenden dieselbe Strategie auf unser System für Kommunikationsberechtigungen an, wie weiter unten in diesem Artikel erläutert wird.

Bewährte Verwaltung von Sicherheitslücken

AAOS SDV nutzt die ausgereifte Infrastruktur von Android für die Reaktion auf Sicherheitsvorfälle und die Verwaltung von Sicherheitslücken, um Sicherheitsergebnisse zu identifizieren, zu priorisieren, zu beheben und offenzulegen. Dieser Lebenszyklus umfasst kontinuierliche automatisierte Scans, jährliche Penetrationstests und von Partnern bereitgestellte Informationen über den Prozess zur Meldung von Android-Sicherheitslücken. Das Sicherheitsteam priorisiert entdeckte Sicherheitslücken, weist Schweregrade basierend auf dem Risiko zu und verfolgt die Behebung bis zum Abschluss. Wir koordinieren Offenlegungs- und Release-Richtlinien über die monatlichen Android-Sicherheitsbulletins, ergänzt durch strenge regelmäßige Sicherheitsprüfungen und umfassende Architekturprüfungen, um die langfristige Stabilität der Plattform zu gewährleisten.

Integrität: Sichere Softwarebereitstellung

Eine sichere Plattform muss nicht nur die Prozessisolation garantieren, sondern auch die Codeintegrität vor der Ausführung sicherstellen. Wir sichern die Softwarebereitstellung durch die folgenden Ansätze:

Authentifizierte Softwarebereitstellung

AAOS SDV bietet zwei Installationsmethoden. Zuerst installieren wir Software direkt auf schreibgeschützten System-, Produkt- oder Anbieterpartitionen, die bei jedem Start Signaturen validieren. Dadurch werden grundlegende Systemkomponenten gesichert.

Zweitens verwenden wir APEX-Pakete (Android Pony EXpress) für Dienste. Jedes APEX kapselt Software und ihre Abhängigkeiten und behandelt das Paket als Partition mit obligatorischer Signaturvalidierung. In AAOS SDV behandelt APEX die Codesignierung als kontinuierlichen, hardwarebasierten Vertrag. APEX sorgt dafür, dass die Ausführung von schädlichem Code durch vier Kernsäulen minimiert wird: 

1. Unveränderlicher Speicher

• Funktionsweise:Der Android-Kernel schleift die Datei „apex_payload.img“ direkt als rohes Speichergerät über den Nur-Lese-Loopback ein und hängt sie mit dem strikten MS_RDONLY-Flag ein.
• Warum es sicherer ist:Dadurch wird kein Schreibpfad zum Betriebssystem freigegeben, da die Dateien nicht auf dem Speicher des Fahrzeugs entpackt werden. Selbst wenn ein Angreifer Root-Berechtigungen erhält, kann er den ausgeführten APEX-Code nicht ändern, da die Dateisystemebene alle Schreibbefehle ablehnt.

2. Kryptografische Integrität

• Der Mechanismus:Die kryptografische Signatur validiert einen Merkle-Baum des gesamten Dateisystem-Images.
• Warum ist das sicherer? Der Kernel verwendet dm-verity pro Block, um die Signatur für jeden 4‑KB-Datenblock on-the-fly zu prüfen. Wenn ein Angreifer einen Rohblock im Flash-Speicher ändert, erkennt der Kernel die Hash-Abweichung und stoppt die Ausführung sofort.

3. Strikte Isolation

• Mechanismus:Hier werden die Regeln für die Prozessisolation angewendet, wie im Abschnitt „Prozessisolation“ beschrieben, um eine Sandbox zu erstellen. Das APEX wird als dedizierte Partition unter „/apex“ eingebunden.
• Warum ist das sicherer? Jeder Dienst erhält ein eigenes Nutzer- und Datenverzeichnis. Der Zugriff wird eingeschränkt, sofern die Freigabe nicht explizit erfolgt. Durch das Erstellen einer dedizierten Partition richtet Android einen dedizierten Linker-Namespace ein. So wird dafür gesorgt, dass nur explizit bereitgestellte Bibliotheken von nicht privilegierten System-Daemons aus zugänglich sind. Dadurch wird die Angriffsfläche minimiert.

4. Atomare Wiederherstellung

• Der Mechanismus:APEX verwendet ein „Aktiv/Backup“-Design, um Rollbacks mit Double-Buffering zu ermöglichen. Der werkseitig installierte APEX verbleibt auf der unveränderlichen /system-Partition, während sich Updates auf der veränderlichen /data-Partition befinden.
• Warum es sicherer ist:Wenn ein Update fehlschlägt oder als schädlich eingestuft wird, markiert der apexd-Daemon es während des frühen Bootvorgangs als „fehlgeschlagen“. Das System tauscht symbolische Links sofort wieder in die /system-Partition. Diese atomare Wiederherstellung trägt dazu bei, dass das System nicht in einem fehlerhaften Zustand verbleibt.

Ausfallsicherheit: Memory-Safe Development

Durch das überprüfte Laden wird das System vor externen Änderungen geschützt. Die Plattformresilienz hängt jedoch auch davon ab, wie der zugrunde liegende Code erstellt wird. Bei neuen Komponenten, die für AAOS SDV entwickelt wurden, haben wir die Speichersicherheit priorisiert.

Rust als primäre Sprache

AAOS SDV ist auf kleine Systeme mit Anforderungen an die schnelle Verfügbarkeit ausgerichtet. Daher kann nicht auf dem vollständigen Android-Stack aufgebaut werden. Wir haben unseren Umfang auf das native Framework beschränkt. Um die erforderliche Infrastruktur für ein verteiltes System zu schaffen, haben wir zusätzlich zur vorhandenen Infrastruktur mehrere Komponenten entwickelt und Rust als primäre Sprache eingeführt. Wir verwenden Rust auch, um die Geschäftslogik von Diensten zu entwickeln, damit Partner sichere Software schreiben können. Rust nutzt standardmäßig Funktionen zur Speichersicherheit, um häufige Klassen von Sicherheitslücken im Zusammenhang mit der Speichersicherheit zu vermeiden und gleichzeitig den Durchsatz von Teams beim Schreiben von nativem Code zu unterstützen.

Verteiltes Vertrauen: Netzwerk- und Zugriffssteuerung

Softwarebasierte Fahrzeuge erfordern eine sichere Interaktion zwischen isolierten Domains. Die AAOS SDV-Mesh-Bereitstellungsarchitektur begegnet dieser Komplexität, indem sie die Version und den Autor jedes Kommunikationsendpunkts kryptografisch überprüft.

Geräte- und Mesh-Bereitstellung

Das AAOS SDV-Mesh stellt die Authentifizierung her, indem es die Netzwerkidentität jeder Komponente mathematisch an ihren tatsächlichen binären Ausführungsstatus bindet. In diesem Modell wird das implizite Softwarevertrauen durch die hardwarebasierte Überprüfung ersetzt.

Die Mesh-Authentifizierung ist kontinuierlich und kryptografisch. So werden Szenarien verhindert, in denen beispielsweise ein Dienst wie ein Fahrzeug-Gateway einer manipulierten Infotainment-VM nur deshalb vertraut, weil sie die richtige IP-Adresse hat.

Die Plattform wird durch hardwarebasierte Isolation und automatisierte Quarantäneprotokolle geschützt. Peer-Geräte im SDV-Mesh verwenden die DICE-basierte Authentifizierung und Attestierung, wie im folgenden Abschnitt beschrieben, um nicht autorisierte Codeausführung oder Konfigurationsmanipulationen zu erkennen und einzudämmen.

DICE-basiertes TLS zur Sicherung der VM-zu-VM-Kommunikation

Hostidentität in der Realität verankern

Die goldene Regel von DICE (Device Identifier Composition Engine): Wenn sich eine einzelne Zeile Code in der Firmware ändert (auch bei einem kleinen Update oder einem böswilligen Exploit), ändert sich die abgeleitete Compound Device Identifier (CDI) vollständig und es wird ein völlig anderer Alias-Schlüssel generiert.

DICE und TLS (Transport Layer Security) werden integriert, um die grundlegende Herausforderung der Zero-Trust-Architektur zu lösen: die Authentifizierung einer Maschine bei gleichzeitiger Überprüfung der Softwareintegrität.

Durch die Kombination aus der hardwaregestützten Identifizierung von DICE und dem verschlüsselten Handshake von TLS kann ein empfangendes Gerät sowohl die Identität des Anrufers als auch seinen genauen Softwarestatus überprüfen.

Herkömmliche Zertifikate weisen nur den Besitz eines Secrets nach, können aber keine Manipulationen an der Firmware erkennen. DICE löst dieses Problem durch Measured Boot Layering:

• Eindeutiges Gerätesecret (Unique Device Secret, UDS): Ein zufälliges kryptografisches Secret, das während der Fertigung generiert wird. Nur der Bootloader der ersten Phase kann auf den UDS zugreifen. Er bleibt für alle anderen Software- und externen Schnittstellen unzugänglich.
• Geschichtete Messungen (Compound Device Identifier): Das Hardware-ROM initiiert die Kette, indem es den UDS mit dem genauen Code und der Konfiguration der nächsten Firmware-Ebene hasht. Dadurch wird ein CDI erstellt, das sequenziell verkettet wird, wenn jede nachfolgende Ebene gestartet wird.

Strenge Zugriffskontrollen regeln die Dienstinteraktionen im AAOS SDV-Mesh. Wie bei aller AAOS SDV-Software werden diese Zugriffssteuerungen authentifiziert und ihre Integrität wird auf Geräteebene und geräteübergreifend im Mesh durch die DICE-basierte Authentifizierung geschützt.

Mehrschichtige Zugriffssteuerung

AAOS SDV verwendet eine Defense-in-Depth-Strategie, um dynamische Fahrzeugupdates zu ermöglichen, ohne die Zugriffsmechanismen zu beeinträchtigen. Dieses Modell basiert auf zwei primären Vertrauensebenen:

1. Berechtigungen auf Dienstebene:Definieren Sie die spezifischen Ressourcen, auf die ein Dienst auf einer bestimmten VM im Mesh zugreifen oder die er im Mesh verfügbar machen kann.
2. Berechtigungen auf VM-Ebene:Definieren Sie die Grenzen für die VM-übergreifende Kommunikation für alle Dienste, die auf einer bestimmten VM gehostet werden.

Mit diesem Modell können OEMs Sicherheit und Aktualisierbarkeit in Einklang bringen. Bei nicht sicherheitssensiblen Diensten ermöglichen permissive Richtlinien auf VM-Ebene die Installation über einfache APEX-Updates anstelle von vollständigen VM-Neuinstallationen.

Berechtigungen für sicherheitssensible Signale müssen dagegen in jede VM fest codiert werden. Der Nachteil ist, dass für die Einführung eines sicherheitssensiblen Dienstes in einer neuen VM die Berechtigungen auf VM-Ebene systemweit aktualisiert werden müssen. Dazu ist ein Update aller VMs im Mesh erforderlich.

Fazit

AAOS SDV erweitert die Sicherheitsarchitektur von Android, um durch einen Secure-by-Design-Ansatz spezifische Automotive-Anforderungen zu erfüllen. Durch die Nutzung von Virtualisierung für die Domain-Isolation und die Durchsetzung von „deny-by-default“-Zugriffsrichtlinien schafft die Plattform eine robuste Umgebung für softwarebasierte Fahrzeuge. Die kryptografische Integrität wird durch die hardwarebasierte, spontane Überprüfung des ausgeführten Codes aufrechterhalten.

Die Plattform umfasst kontinuierliche Sicherheitslebenszyklen, die von der proaktiven Verwaltung von Sicherheitslücken bis hin zur hardwarebasierten Identitätsüberprüfung über DICE reichen. Diese mehrschichtigen Schutzmaßnahmen ermöglichen es OEMs, die Aktualisierbarkeit fortschrittlicher Funktionen mit der robusten Sicherheit in Einklang zu bringen, die für moderne Automobilumgebungen erforderlich ist. Technische Spezifikationen und Implementierungsdetails finden Sie auf der Übersichtsseite zu AAOS SDV.