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. Während sich unsere Versionshinweise auf die Funktionen konzentrierten, werden in diesem Blogpost einige der Sicherheitskonzepte beschrieben.

Grundlage: Domain-Isolation

Virtualisierung zur Isolation von gemeinsam gehosteten Instanzen

Der aktuelle Trend, Steuergeräte in einem einzigen Chip zu konsolidieren, verringert die Isolation, da mehrere Domains nebeneinander ausgeführt werden.

AAOS SDV-Instanzen bieten zwar interne Isolierungsmechanismen, es ist jedoch oft besser, logische Domains unabhängig voneinander auszuführen. So gelten für 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 (privacy virtual machines, pVM) optimiert ist. Diese Abstammung bietet Android-Plattformentwicklern etablierte Sicherheitsfunktionen, die sie bereits kennen.

Prozessisolation und Standardablehnung

AAOS SDV folgt dem auf Android-Nutzer-IDs (UIDs) basierenden Isolationsmodell, um für jede Anwendung eine Sandbox einzurichten. Jeder Dienst wird in einem dedizierten 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 dies mit Security-Enhanced Linux (SELinux), um eine „Standardmäßig verweigern“-Haltung 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 Partnerinformationen über den Prozess zur Meldung von Android-Sicherheitslücken. Das Sicherheitsteam priorisiert erkannte 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 Widerstandsfähigkeit 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 für Dienste APEX-Pakete (Android Pony EXpress). Jedes APEX-Paket kapselt Software und ihre Abhängigkeiten und behandelt das Paket als Partition mit obligatorischer Signaturvalidierung. In AAOS SDV wird die Codesignierung von APEX als fortlaufender, hardwarebasierter Vertrag behandelt. 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 schreibgeschützten Loopback ein und hängt sie mit dem strikten Flag „MS_RDONLY“ ein.
• Warum es sicherer ist:Dadurch wird kein Schreibpfad zum Betriebssystem freigelegt, da die Dateien nicht im 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 spontan zu überprü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. Dadurch wird eine Sandbox erstellt, in der das APEX als dedizierte Partition unter „/apex“ eingebunden ist.
• Warum ist das sicherer? Jeder Dienst erhält ein eigenes Nutzer- und Datenverzeichnis, wodurch der Zugriff eingeschränkt wird, sofern die Freigabe nicht explizit erfolgt. Durch das Erstellen einer dedizierten Partition wird in Android ein dedizierter Linker-Namespace eingerichtet. 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 doppelter Pufferung zu ermöglichen. Der werkseitig installierte APEX verbleibt auf der unveränderlichen Partition „/system“, während sich Updates auf der veränderlichen Partition „/data“ befinden.
• Warum es sicherer ist:Wenn ein Update fehlschlägt oder bösartig erscheint, markiert der apexd-Daemon es während des frühen Starts 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 für kleine Systeme mit Anforderungen an die schnelle Verfügbarkeit vorgesehen. 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 des 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 die Netzwerkidentität jeder Komponente mathematisch an ihren tatsächlichen binären Ausführungsstatus gebunden wird. In diesem Modell wird das implizite Softwarevertrauen durch die hardwarebasierte Überprüfung ersetzt.

Die Mesh-Authentifizierung ist kontinuierlich und kryptografisch. So wird verhindert, dass beispielsweise ein Dienst wie ein Fahrzeug-Gateway einer manipulierten Infotainment-VM vertraut, nur 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 der hardwaregestützten Identifizierung von DICE und des verschlüsselten Handshakes von TLS kann ein empfangendes Gerät sowohl die Identität des Anrufers als auch seinen genauen Softwarestatus überprüfen.

Herkömmliche Zertifikate beweisen nur den Besitz eines Geheimnisses, 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 (zusammengesetzte Geräte-ID): 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 dann sequenziell verkettet wird, wenn die einzelnen nachfolgenden Ebenen gestartet werden.

Strenge Zugriffssteuerungen 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.

Dieses Modell ermöglicht es OEMs, Sicherheit und Aktualisierbarkeit in Einklang zu 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 müssen alle VMs im Mesh aktualisiert werden.

Fazit

AAOS SDV erweitert die Sicherheitsarchitektur von Android, um durch einen Secure-by-Design-Ansatz auf spezifische Automotive-Anforderungen einzugehen. 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.