Anwendungsfälle

Dieses Dokument enthält allgemeine Anwendungsfälle für AVF.

Isolierte Zusammenstellung

Als softwaresichere Enklave bietet eine geschützte VM eine sichere Umgebung zum Kompilieren von sicherheitsrelevantem Code. Diese Umgebung ermöglicht das Verschieben der Kompilierung von bootclasspath und Systemserver-JARs (ausgelöst durch eine APEX-Aktualisierung) von einem frühen Start zu vor einem Neustart und verkürzt die Startzeit nach der APEX-Aktualisierung erheblich.

Die Implementierung befindet sich im com.android.compos APEX. Diese Komponente ist optional und kann mit einem Makefile eingebunden werden.

Isolierte Zusammenstellung

Abbildung 1. Kompilieren von JARs auf Mainline-Updates

Das Sicherheitsziel besteht darin, verifizierte Eingaben wahrheitsgemäß zu kompilieren und die Ausgabe isoliert zu produzieren. Android als nicht vertrauenswürdiger Client kann die Kompilierungsausgabe auf keine andere Weise ändern, als dass sie fehlschlägt (wenn Android auf die Kompilierung beim Booten zurückgreift).

Der Kompilierungsdienst in der VM generiert nur dann eine Signatur, wenn während der gesamten Kompilierung kein Fehler aufgetreten ist. 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 von den APEXes und APKs definiert wird, die auf der VM gemountet sind, zusätzlich zu anderen VM-Parametern wie der Debuggbarkeit.

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

Mit dem verifizierten Start der geschützten VM führt der Kompilierungsdienst nur verifizierten Code aus. Der Code kann daher bestimmen, nur Eingaben zu akzeptieren, die bestimmte Bedingungen erfüllen, beispielsweise eine Eingabedatei nur dann akzeptieren, wenn ihr Name und der fs-verity Digest in einer Zulassungsliste definiert sind.

Alle exponierten APIs der VM sind Angriffsflächen. Es wird davon ausgegangen, dass alle Eingabedateien und Parameter von einem nicht vertrauenswürdigen Client stammen und vor der Verarbeitung überprüft und überprüft werden müssen.

Die Integrität der Eingabe-/Ausgabedatei wird von der VM überprüft, wobei die Dateien wie folgt auf Android als nicht vertrauenswürdiger Dateiserver gespeichert werden:

  • Der Inhalt einer Eingabedatei muss vor der Verwendung mit dem fs-verity Algorithmus ü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 Root-Hash kann ein Angreifer die Eingabe nicht manipulieren, ohne entdeckt zu werden.
  • Die Integrität der Ausgabedatei muss in der VM aufrechterhalten werden. Selbst wenn eine Ausgabedatei auf Android gespeichert wird, wird die Integrität während der Generierung 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.