AAOS SDV – Von Grund auf sicher

Wir bei Google sind der Meinung, dass unsere Produkte von Grund auf sicher sein sollten. Deshalb haben wir das Android Automotive Operating System für Software Defined Vehicle (AAOS SDV) auf bestehenden, markterprobten Plattformen entwickelt und nutzen Virtualisierungstechnologien wie Cuttlefish. In unseren Release-Ankündigungen ging es vor allem um die Funktionen. In diesem Blogpost werden einige der Sicherheitskonzepte beschrieben.

Grundlage: Domainisolation

Virtualisierung zur Isolation von gemeinsam gehosteten Instanzen

Der aktuelle Trend, elektronische Steuergeräte (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. Ein Kombiinstrument und ein Infotainmentsystem haben beispielsweise unterschiedliche Anforderungen. Wir verwenden virtuelle Maschinen, um mehrere Instanzen parallel auszuführen. So wird sichergestellt, dass die Freigabe explizit bleibt und die Isolation das Standardverhalten ist.

Übernommene Android-Sicherheit

AAOS SDV wurde aus Microdroid entwickelt, einer minimalistischen Android-Version, die für private 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 Nutzer-ID-basierten Isolationsmodell von Android, 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 verwenden POSIX-Funktionen (Portable Operating System Interface), um Vorgänge strikt einzuschränken, und kombinieren dies mit Security-Enhanced Linux (SELinux), um eine „Standardmäßig ablehnen“-Richtlinie durchzusetzen. Bei diesem Ansatz wird jeder Dienst auf das absolute Minimum beschränkt. Das bedeutet, dass fehlende Konfigurationen den Zugriff blockieren, anstatt ein System mit zu vielen Berechtigungen zu erstellen. Dieselbe Strategie wenden wir auch 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 detaillierte Penetrationstests und partnergestützte Informationen über den Prozess zur Meldung von Sicherheitslücken in Android. Das Sicherheitsteam priorisiert erkannte Sicherheitslücken, weist Schweregrade basierend auf dem Risiko zu und verfolgt die Behebung bis zum Abschluss. Wir koordinieren die Offenlegungs- und Veröffentlichungsrichtlinien über die monatlichen Sicherheitsbulletins für Android. Diese werden durch strenge regelmäßige Sicherheitsaudits und umfassende Architekturprüfungen ergänzt, 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

Für AAOS SDV gibt es 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 Android Pony EXpress-Pakete (APEX) für Dienste. Jedes APEX-Paket enthält Software und ihre Abhängigkeiten und wird als Partition mit obligatorischer Signaturvalidierung behandelt. In AAOS SDV behandelt APEX die Codesignatur als einen kontinuierlichen, hardwareerzwungenen Vertrag. APEX sorgt dafür, dass die Ausführung von schädlichem Code durch vier Kernbereiche minimiert wird: 

1. Unveränderlicher Speicher

• Der Mechanismus:Der Android-Kernel führt die Datei „apex_payload.img“ direkt als Rohspeichergerät über das schreibgeschützte Loopback aus und stellt sie mit dem strikten Flag „MS_RDONLY“ bereit.
• Warum es sicherer ist:Es wird kein Schreibpfad für das Betriebssystem verfügbar gemacht, 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 es sicherer ist:Der Kernel verwendet dm-verity pro Block, um die Signatur für jeden 4-KB-Datenblock on the fly zu überprüfen. Wenn ein Angreifer einen Rohblock im Flash-Speicher ändert, erkennt der Kernel die Hash-Abweichung und bricht die Ausführung sofort ab.

3. Strikte Isolation

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

4. Atomare Wiederherstellung

• Der Mechanismus:APEX verwendet ein „Aktiv/Backup“-Design, um doppelt gepufferte Rollbacks zu ermöglichen. Das werkseitig geflashte APEX-Paket verbleibt auf der unveränderlichen Partition „/system“, während Updates auf der veränderlichen Partition „/data“ gespeichert werden.
• Warum es sicherer ist:Wenn ein Update fehlschlägt oder bösartig erscheint, markiert der apexd-Daemon es während der frühen Startphase als „fehlgeschlagen“. Das System tauscht symbolische Links sofort wieder mit der Partition „/system“ aus. Diese atomare Wiederherstellung trägt dazu bei, dass das System nicht in einem fehlerhaften Zustand verbleibt.

Ausfallsicherheit: Speichersichere Entwicklung

Das verifizierte Laden schützt das System vor externen Änderungen, aber die Ausfallsicherheit der Plattform hängt 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 eine schnelle Verfügbarkeit gedacht. Das verhindert die Entwicklung auf dem vollständigen Android-Stack, weshalb wir uns auf das native Framework beschränkt haben. Um die erforderliche Infrastruktur für ein verteiltes System zu erstellen, 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, und helfen Partnern so, sichere Software zu schreiben. Rust nutzt Funktionen zur Speichersicherheit, um gängige Arten von Sicherheitslücken im Zusammenhang mit der Speichersicherheit zu vermeiden, und unterstützt gleichzeitig den Teamdurchsatz beim Schreiben von nativem Code.

Verteiltes Vertrauen: Netzwerk- und Zugriffssteuerung

Softwarebasierte Fahrzeuge erfordern sichere Interaktionen zwischen isolierten Domains. Die AAOS-SDV-Mesh-Bereitstellungsarchitektur löst dieses Problem, indem sie die Version und den Autor jedes Kommunikationsendpunkts kryptografisch verifiziert.

Geräte- und Mesh-Bereitstellung

Das AAOS-SDV-Mesh authentifiziert sich, indem es die Netzwerkidentität jeder Komponente mathematisch an ihren tatsächlichen binären Ausführungsstatus bindet. Dieses Modell ersetzt implizites Softwarevertrauen durch hardwarebasierte Verifizierung.

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.

Hardwaregestützte Isolation und automatisierte Quarantäneprotokolle sichern die Plattform. Peer-Geräte im SDV-Mesh verwenden die DICE-basierte Authentifizierung und Attestierung, wie im folgenden Abschnitt beschrieben, um die Ausführung von nicht autorisiertem Code oder die Manipulation von Konfigurationen zu erkennen und einzudämmen.

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

Die Identität des Hosts in der Realität verankern

Die goldene Regel von DICE (Device Identifier Composition Engine): Wenn sich auch nur eine einzige Zeile Code in der Firmware ändert (selbst bei einem kleinen Update oder einem bösartigen Exploit), ändert sich der 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 kombiniert, um die grundlegende Herausforderung der Zero-Trust-Architektur zu lösen: die Authentifizierung eines Geräts bei gleichzeitiger Überprüfung der Softwareintegrität.

Die Kombination aus der hardwaregestützten Identifizierung von DICE und dem verschlüsselten Handshake von TLS ermöglicht es einer empfangenden Maschine, sowohl die Identität des Aufrufers als auch den genauen Softwarestatus zu überprüfen.

Herkömmliche Zertifikate belegen nur den Besitz eines Secrets, können aber keine Manipulationen an der Firmware erkennen. DICE löst dieses Problem durch gemessene Boot-Ebenen:

• Unique Device Secret (UDS): Ein zufälliges kryptografisches Secret, das während der Herstellung generiert wird. Nur der Bootloader der ersten Stufe kann auf den UDS zugreifen. Für alle anderen Software- und externen Schnittstellen bleibt er unzugänglich.
• Mehrschichtige 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 eine CDI erstellt, die dann sequenziell verkettet wird, wenn jede nachfolgende Ebene gestartet wird.

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

Mehrstufige 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, ein Gleichgewicht zwischen Sicherheit und Aktualisierbarkeit zu finden. Bei nicht sicherheitsrelevanten Diensten ermöglichen weniger strenge Richtlinien auf VM-Ebene die Installation über einfache APEX-Updates anstelle einer vollständigen erneuten Bereitstellung der VM.

Berechtigungen für sicherheitsrelevante Signale müssen dagegen in jeder VM hartcodiert sein. Der Nachteil ist, dass die Einführung eines sicherheitsrelevanten Dienstes auf einer neuen VM eine systemweite Aktualisierung der Berechtigungen auf VM-Ebene erfordert. Dazu müssen alle VMs im Mesh aktualisiert werden.

Fazit

AAOS SDV erweitert die Sicherheitsarchitektur von Android, um spezifische Anforderungen für Fahrzeuge durch einen Secure-by-Design-Ansatz zu erfüllen. Durch die Nutzung der Virtualisierung für die Domainisolation und die Durchsetzung von „Standardmäßig ablehnen“-Zugriffsrichtlinien wird eine robuste Umgebung für softwarebasierte Fahrzeuge geschaffen. Die kryptografische Integrität wird durch eine hardwaregestützte, dynamische Überprüfung des ausgeführten Codes gewährleistet.

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