Anwendungsfälle

In diesem Dokument werden gängige Anwendungsfälle für AVF beschrieben.

Isolierte Kompilierung

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

Die Implementierung befindet sich in der APEX-Datei com.android.compos. Diese Komponente ist optional und kann mit einem Makefile eingefügt werden.

Abbildung 1. JARs bei Mainline-Updates kompilieren

Das Sicherheitsziel besteht darin, die bestätigte Eingabe wahrheitsgemäß zu kompilieren und die Ausgabe isoliert zu generieren. Android kann als nicht vertrauenswürdiger Client die Kompilierungsausgabe nur auf eine Weise ändern, die zu einem Fehler führt (wenn Android zur Kompilierung zur Bootzeit zurückkehrt).

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

Der Schlüssel der VM wird aus dem DICE-Profil der VM generiert, das durch die APEXes und APKs definiert wird, die auf der VM bereitgestellt werden, sowie durch andere VM-Parameter wie die Debuggbarkeit.

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 beim frühen Start gestartet.

Bei der geschützten VM mit dem verifizierten Start wird vom Kompilierungsservice nur verifizierter Code ausgeführt. Der Code kann daher festlegen, dass nur Eingaben akzeptiert werden, die bestimmte Bedingungen erfüllen. Beispielsweise kann eine Eingabedatei nur akzeptiert werden, 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 werden als von einem nicht vertrauenswürdigen Client stammend betrachtet und müssen vor der Verarbeitung überprüft werden.

Die Integrität von Eingabe-/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 Algorithmus fs-verity überprüft werden. Damit eine Eingabedatei in der VM verfügbar wird, muss ihr Root-Hash in einem Container (APK) bereitgestellt werden, der zum DICE-Profil der VM beiträgt. Mit dem vertrauenswürdigen Stamm-Hash kann ein Angreifer nicht unbemerkt die Eingabe manipulieren.
• Die Integrität der Ausgabedatei muss in der VM aufrechterhalten 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 mit dem Root-Hash identifiziert werden, der in der VM isoliert ist. Der Dienst in der VM schützt die Ausgabedateien durch Signatur.