Anwendungsfälle

Auf dieser Seite finden Sie gängige Anwendungsfälle für AVF.

Isolierte Kompilierung

Als softwaregesicherte Enklave bietet eine geschützte virtuelle Maschine (VM) eine sichere Umgebung zum Kompilieren sicherheitssensiblen Codes. In dieser Umgebung kann die Kompilierung von bootclasspath- und Systemserver-JARs (die durch ein APEX-Update ausgelöst wird) vom frühen Bootvorgang auf die Zeit vor dem Neustart verschoben werden. Dadurch wird die Bootzeit nach dem APEX-Update erheblich verkürzt.

Die Implementierung befindet sich im APEX com.android.compos. Diese Komponente ist optional und kann über ein Makefile eingebunden werden.

Das Sicherheitsziel besteht darin, überprüfte Eingaben wahrheitsgemäß zu kompilieren und die Ausgabe isoliert zu erstellen. Android als nicht vertrauenswürdiger Client kann die Kompilierungsausgabe in keiner Weise ändern, außer dass sie fehlschlägt (wenn Android auf die Kompilierung zur Bootzeit zurückgreift).

Der Kompilierungsservice in der VM generiert eine Signatur nur, wenn während der gesamten Kompilierung kein Fehler auftritt. Android kann den öffentlichen Schlüssel zur Signaturprüfung von der VM abrufen.

Der Schlüssel der VM wird aus dem DICE-Profil der VM generiert, das durch die in der VM eingebundenen APEX-Dateien und APKs sowie durch andere VM-Parameter wie die Debugging-Fähigkeit definiert wird.

Um festzustellen, ob der öffentliche Schlüssel nicht von einer unerwarteten VM stammt, startet Android die VM, um zu prüfen, ob der Schlüssel korrekt ist. Die VM wird nach jedem APEX-Update frühzeitig gestartet.

Mit Verified Boot von Protected VMs wird im Kompilierungsdienst nur geprüfter Code ausgeführt. Der Code kann daher nur Eingaben akzeptieren, die bestimmte Bedingungen erfüllen, z. B. eine Eingabedatei nur dann akzeptieren, wenn ihr Name und der fs-verity-Digest in einer Zulassungsliste definiert sind.

Alle freigegebenen APIs der VM sind Angriffsflächen. Alle Eingabedateien und Parameter stammen von einem nicht vertrauenswürdigen Client und müssen vor der Verarbeitung überprüft und genehmigt werden.

Die Integrität von Ein- und Ausgabedateien wird von der VM überprüft. Die Dateien werden auf Android als nicht vertrauenswürdiger Dateiserver gespeichert.

• Der Inhalt einer Eingabedatei muss vor der Verwendung mit dem fs-verity-Algorithmus überprüft werden. Damit eine Eingabedatei in der VM verfügbar ist, muss ihr Stamm-Hash in einem Container (APK) angegeben werden, der zum DICE-Profil der VM beiträgt. Mit dem vertrauenswürdigen Stamm-Hash kann ein Angreifer die Eingabe nicht unbemerkt manipulieren.
• Die Integrität der Ausgabedatei muss in der VM gewahrt werden. Auch wenn eine Ausgabedatei auf Android gespeichert wird, wird während der Generierung die Integrität mit demselben fs-verity-Baumformat beibehalten, kann aber dynamisch aktualisiert werden. Die endgültige Ausgabedatei kann anhand des Stamm-Hash identifiziert werden, der in der VM isoliert ist. Der Dienst in der VM schützt die Ausgabedateien durch Signaturen.

Linux-Entwicklungsumgebung

Android war bisher das einzige große Betriebssystem, auf dem Nutzer keine Apps entwickeln konnten. Mit der Einführung der Linux-Entwicklungsumgebung möchten wir Android-Nutzern, die Entwickler sind, eine Linux-basierte Entwicklungsumgebung zur Verfügung stellen. In Zukunft möchten wir die Bemühungen ausweiten, um es unseren Partnern zu ermöglichen, innovative VM-Anwendungsfälle wie das Ausführen von Apps mit grafischer Benutzeroberfläche und sogar Spielen zu implementieren.

Die Linux-Entwicklungsumgebung ist auf ausgewählten Geräten verfügbar und wird auf einer nicht geschützten virtuellen Maschine ausgeführt.

Der allgemeine Ablauf sieht so aus:

1. Wenn Sie die Linux-Entwicklungsumgebung verwenden möchten, müssen Sie die Entwickleroptionen aktivieren.
2. Nachdem Sie die Entwickleroptionen aktiviert haben, wird die Terminal App im Launcher auf dem Startbildschirm angezeigt.
3. Öffnen Sie die Terminal App über den Startbildschirm.
4. Bei Bedarf lädt die Terminal-App das Betriebssystem-Image von Play herunter.
5. Die Terminal App verwendet das Android Virtualization Framework (AVF), um eine VM zu erstellen.
6. AVF führt dann die VM mit dem Betriebssystem-Image aus.
7. Die virtuelle Maschine startet das Betriebssystem aus dem Image.
8. Nach dem Starten der VM stellt die WebView in der Terminal-App eine Verbindung zu einem Webdienst auf der virtuellen Maschine her. Dieser Dienst bietet Terminalzugriff über HTTP.
9. Sie interagieren mit dem Terminal, indem Sie Befehle eingeben und die Ausgabe in der App ansehen.

Die allgemeinen Komponenten der Linux-VM sind:

• Terminal-App:Eine Android-Anwendung, die eine Terminalschnittstelle bietet. Für die Interaktion wird eine WebView-Komponente verwendet, um eine Verbindung zu einem Webdienst herzustellen, der auf der VM ausgeführt wird. Diese App ist standardmäßig deaktiviert. Aktivieren Sie die Funktion in den Entwicklereinstellungen.
• Android Virtualization Framework (AVF): Das vorhandene Subsystem von Android für die Erstellung und Verwaltung von VMs. Es sind nur minimale Änderungen erforderlich, um benutzerdefinierte Betriebssystem-Images für diese Funktion zu unterstützen.
• Virtuelle Maschine:Eine VM, die von AVF generiert wird. Es hostet den Terminaldienst und wird von AVF speziell für die Funktionen der Terminal-App erstellt.
• Betriebssystem-Image: Ein leicht modifiziertes Debian-basiertes Betriebssystem-Image von Upstream-Debian. Die Terminal App lädt dieses Bild von einem externen Google-Server herunter. Sie dient als Grundlage für den Betrieb der VM.
• Gast-Agent:Neue Software auf der VM. Es meldet den Status des Betriebssystems an AVF und ermöglicht die Steuerung der virtuellen Maschine.
• ttyd: Open-Source-Software, die in der VM ausgeführt wird und die Terminalemulation über HTTP implementiert. Die WebView der Terminal-App stellt eine Verbindung dazu her.
• Tethering Manager:Ein vorhandenes Android-Subsystem. Sie ermöglicht den Netzwerkzugriff auf die VM, indem die VM an das Android-Gerät angebunden wird.

Sicherheit von Inhalten auf dem Gerät

Content Safety On-device ist eine datenschutzfreundliche Lösung für die Sicherheit von Inhalten, die vom Content Safety On-device-Team entwickelt wurde. SafetyCore führt die Klassifizierung der Inhaltssicherheit für verschiedene Google-Produkte auf Geräten von Erst- und Drittanbietern durch und schützt mehr als 1 Milliarde Nutzer vor missbräuchlichen Inhalten, ohne dass Nutzerdaten an Google-Server zurückgesendet werden müssen. Es wurde entwickelt, um die PCC-Grundsätze (Private Compute Core) einzuhalten und eine transparente und datenschutzfreundliche Kommunikation zwischen dem Client und der VM zu ermöglichen und jegliche Exfiltration von Nutzerdaten zu verhindern. Sie kann beispielsweise verwendet werden, um die Missbrauchserkennung auf Geräten zu aktivieren, z. B. die Live-Erkennung von Bedrohungen durch Play Protect.

In diesem Anwendungsfall nutzt das System geschützte virtuelle Maschinen, um die Modellklassifizierung für die Live-Erkennung von Bedrohungen durch Play Protect auszuführen. Dadurch wird die Sicherheit der Modelle und des Schutzes erheblich verbessert. Dadurch werden Reverse Engineering und Manipulationen durch Angreifer verhindert, auch auf gerooteten Geräten. Es wird nur genehmigter Code ausgeführt und die Vorgänge sind vor externen Prozessen verborgen.

Die allgemeinen Abläufe sind wie folgt:

1. Die Live-Erkennung von Bedrohungen pingt Private Compute Services, um die VM zu starten. Private Compute Services ist ein datenschutzorientierter Vermittler zwischen dem PCC und dem Cloud-Server.
2. Private Compute Services startet die VM und ruft den öffentlichen Schlüssel von der VM ab.
3. Private Compute Services übergibt den VM-Inhaber an die Live-Erkennung von Bedrohungen durch Play Protect
4. Private Compute Services sendet Attestierung und öffentlichen Schlüssel an den Server
5. Der Server überprüft die Attestierung und verschlüsselt die Schutzmaßnahmen mit dem öffentlichen VM-Schlüssel.
6. Der Server sendet die verschlüsselten Schutzmaßnahmen dann zurück an das Gerät.
7. Die Live-Erkennung von Bedrohungen auf dem Gerät kann dann verschlüsselten Schutz in der VM nutzen. Die VM ist die einzige Einheit mit dem privaten Schlüssel, die die Schutzmaßnahmen entschlüsseln kann.

Die allgemeinen Komponenten sind:

• Server: Verschlüsseln und Bereitstellen verschlüsselter Schutzmaßnahmen für die VM
• Private Compute Services: Werden verwendet, um die VM zu starten, die Kommunikation mit der VM zu vermitteln und zu zeigen, dass keine Nutzerdaten über Astrea zum Server übertragen werden.
• Live-Erkennung von Bedrohungen durch Play Protect:
  • Enthält und verwendet Modellklassifizierer, die von Content Safety auf dem Gerät bereitgestellt werden
  • Übernimmt das Eigentum an der VM und behält es für die Klassifizierung bei
  • Die VM wird nach Bedarf gestartet und beendet.

OEMs

Ein OEM kann das AVF für benutzerdefinierte Anwendungsfälle verwenden. OPPO verwendet AVF beispielsweise, um den AI Private Computing Space zu aktivieren. Die erste Anwendung dieses Bereichs bietet eine On-Device-Lösung zur Risikokontrolle für App-Clients, die auf einer virtuellen Maschine ausgeführt werden. Das System wehrt Bedrohungen durch illegale Aktivitäten ab und bietet Schutz vor verschiedenen Gefahren.