Neuigkeiten zum Produkt

AAOS SDV – Von Grund auf sicher

5 Minuten Lesezeit
3 Autoren
Markus Vill, Sean Keys, István Nádor

Bei Google sind wir 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 dabei Virtualisierungstechnologien wie Cuttlefish genutzt. In unseren Ankündigungen zu neuen Versionen haben wir uns auf die Funktionen konzentriert. In diesem Blogpost werden einige der Sicherheitskonzepte erläutert.

Grundlage: Domainisolation

Virtualisierung zur Isolation von gemeinsam gehosteten Instanzen

Der aktuelle Trend, elektronische Steuergeräte (Electronic Control Units, ECUs) in 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 vorzuziehen, logische Domains unabhängig voneinander auszuführen. Ein Cluster 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.

Geerbte Android-Sicherheit

AAOS SDV wurde aus Microdroid entwickelt, einer minimalistischen Android-Version, die für virtuelle Maschinen mit Datenschutz (Privacy Virtual Machines, pVMs) optimiert ist. Diese Abstammung bietet Android-Plattformentwicklern etablierte Sicherheitsfunktionen, die sie bereits kennen.

Prozessisolation und Standardablehnung

AAOS SDV folgt dem Android-Isolationsmodell auf Basis der Nutzer-ID (User ID, UID), 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 die Funktionen der Portable Operating System Interface (POSIX), um Vorgänge streng zu begrenzen, und kombinieren dies mit Security-Enhanced Linux (SELinux), um eine Standardablehnung 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 zu permissives System zu schaffen. Wir wenden diese Strategie auch auf unser System für Kommunikationsberechtigungen an, wie später in diesem Artikel erläutert.

Bewährtes Schwachstellenmanagement

AAOS SDV integriert die ausgereifte Sicherheitsreaktion und die Infrastruktur für das Schwachstellenmanagement von Android, um Sicherheitsergebnisse zu identifizieren, zu priorisieren, zu beheben und offenzulegen. Dieser Lebenszyklus umfasst kontinuierliche automatisierte Scans, jährliche umfassende 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 Release-Richtlinien über die monatlichen Android-Sicherheitsbulletins. Ergänzt werden diese durch strenge regelmäßige Sicherheitsaudits und umfassende Architekturprüfungen, um die langfristige Plattformresilienz zu gewährleisten.

Integrität: Sichere Softwarebereitstellung

Neben der Gewährleistung der Prozessisolation muss eine sichere Plattform die Codeintegrität vor der Ausführung sicherstellen. Wir sichern die Softwarebereitstellung mit den folgenden Ansätzen:

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. So 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 Codesignierung als kontinuierlichen, hardwaregestützten Vertrag. APEX trägt durch vier Kernsäulen dazu bei, die Ausführung von schädlichem Code zu verhindern: 

1. Unveränderlicher Speicher

  • Der Mechanismus: Der Android-Kernel loop die Datei „apex_payload.img“ direkt als Raw-Speichergerät mit dem schreibgeschützten Loopback und mount sie mit dem strengen Flag „MS_RDONLY“.
  • Warum ist das sicherer? Es wird kein Schreibpfad zum Betriebssystem offengelegt, 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-Image.
  • Warum ist das sicherer? Der Kernel verwendet dm-verity pro Block, um die Signatur für jeden 4-KB-Datenblock im laufenden Betrieb zu überprüfen. Wenn ein Angreifer einen Raw-Block im Flash-Speicher ändert, erkennt der Kernel die Hash-Abweichung und beendet die Ausführung sofort.

3. Strikte Isolation

  • Der Mechanismus: Hier werden die Regeln für die Prozessisolation angewendet, wie im Abschnitt Prozessisolation beschrieben, um eine Sandbox zu erstellen, wobei das APEX als eigene Partition unter „/apex“ gemountet wird.
  • Warum ist das sicherer? Jeder Dienst erhält ein eigenes Nutzer- und Datenverzeichnis, wodurch der Zugriff eingeschränkt wird, es sei denn, die Freigabe ist explizit. Durch das Erstellen einer eigenen Partition richtet Android einen eigenen Linker-Namespace ein. So wird sichergestellt, dass nur explizit freigegebene Bibliotheken von nicht privilegierten System-Daemons aus zugänglich sind, wodurch die Angriffsfläche minimiert wird.

4. Atomare Wiederherstellung

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

Resilienz: Speichersichere Entwicklung

Das verifizierte Laden schützt das System vor externen Änderungen. Die Plattformresilienz hängt jedoch auch davon ab, wie der zugrunde liegende Code erstellt wurde. Bei neuen Komponenten, die für AAOS SDV entwickelt wurden, haben wir der Speichersicherheit Priorität eingeräumt.

Rust als primäre Sprache

AAOS SDV ist für kleine Systeme mit hohen Anforderungen an die Verfügbarkeit konzipiert. Daher ist es nicht möglich, auf dem vollständigen Android-Stack aufzubauen. Wir haben uns auf das native Framework beschränkt. Um die erforderliche Infrastruktur für ein verteiltes System zu schaffen, haben wir zusätzlich zur bestehenden 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 Partnern so zu helfen, sichere Software zu schreiben.  Rust nutzt standardmäßig Funktionen zur Speichersicherheit, um häufige Arten von Sicherheitslücken im Zusammenhang mit der Speichersicherheit zu verhindern. Gleichzeitig wird der Durchsatz des Teams beim Schreiben von nativem Code unterstützt.

Verteiltes Vertrauen: Netzwerk- und Zugriffskontrolle

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

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ührungszustand bindet. Dieses Modell ersetzt das implizite Softwarevertrauen durch eine hardwarebasierte Verifizierung.

Die Mesh-Authentifizierung ist kontinuierlich und kryptografisch. So werden Szenarien verhindert, in denen beispielsweise ein Dienst wie ein Fahrzeuggateway einer kompromittierten Infotainment-VM vertraut, nur 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 unbefugte 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 Codezeile in der Firmware ändert (auch bei einem kleinen Update oder einem schädlichen Exploit), ändert sich die abgeleitete zusammengesetzte Geräte-ID (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 und gleichzeitig die Überprüfung der Softwareintegrität.

Durch die Kombination aus der hardwaregestützten Identifizierung von DICE und dem verschlüsselten Handshake von TLS kann eine empfangende Maschine sowohl die Identität des Anrufers als auch den genauen Softwarezustand überprüfen.

Traditionelle Zertifikate beweisen nur den Besitz eines Geheimnisses. Sie können keine Manipulationen an der Firmware erkennen. DICE begegnet diesem Problem durch geschichtete Messungen beim Start:

  • Das eindeutige Gerätesecret (Unique Device Secret, UDS) : Ein zufälliges kryptografisches Secret, das während der Herstellung generiert wird. Nur der Bootloader der ersten Stufe kann auf das UDS zugreifen. Es bleibt für alle anderen Software und externen Schnittstellen unzugänglich.
  • Geschichtete Messungen (die zusammengesetzte Geräte-ID): Das Hardware-ROM initiiert die Kette, indem es das UDS mit dem genauen Code und der Konfiguration der nächsten Firmware-Ebene hasht. So wird eine CDI erstellt, die dann sequenziell verkettet wird, wenn jede nachfolgende Ebene gestartet wird.

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

Geschichtete Zugriffskontrolle

AAOS SDV verwendet eine umfassende Sicherheitsstrategie, 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 zugreifen oder die er im Mesh verfügbar machen kann.
  2. Berechtigungen auf VM-Ebene:Definieren Sie die Grenzen der VM-übergreifenden 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. Für nicht sicherheitskritische Dienste ermöglichen permissive Richtlinien auf VM-Ebene die Installation über einfache APEX-Updates anstelle von vollständigen VM-Neubereitstellungen.

Umgekehrt müssen Berechtigungen für sicherheitskritische Signale in jede VM fest codiert werden. Der Nachteil ist, dass die Einführung eines sicherheitskritischen Dienstes in einer neuen VM eine systemweite Aktualisierung des Berechtigungssystems auf VM-Ebene erfordert. Dazu müssen alle VMs im Mesh aktualisiert werden.

Fazit

image.png

AAOS SDV erweitert die Sicherheitsarchitektur von Android, um spezifische Anforderungen der Automobilindustrie durch einen „Secure by Design“-Ansatz zu erfüllen. Durch die Nutzung der Virtualisierung für die Domainisolation und die Erzwingung von Standardablehnungs-Zugriffsrichtlinien schafft die Plattform eine resiliente Umgebung für softwarebasierte Fahrzeuge. Die kryptografische Integrität wird durch die hardwaregestützte, On-the-Fly-Überprüfung des ausgeführten Codes aufrechterhalten.

Die Plattform integriert kontinuierliche Sicherheitslebenszyklen, die von der proaktiven Verwaltung von Sicherheitslücken bis hin zur hardwarebasierten Identitätsüberprüfung über DICE reichen. Diese mehrschichtigen Abwehrmechanismen ermöglichen es OEMs, die Aktualisierbarkeit erweiterter Funktionen mit der robusten Sicherheit in Einklang zu bringen, die für moderne Automotive-Umgebungen erforderlich ist. Technische Spezifikationen und Implementierungsdetails finden Sie auf der Seite AAOS SDV – Übersicht.

Geschrieben von:
Weiterlesen