Anwendungsfälle

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

Isolierte Zusammenstellung

Als softwaresichere Enklave bietet eine geschützte VM eine sichere Umgebung zum Kompilieren sicherheitsrelevanten Codes. Diese Umgebung ermöglicht das Verschieben der Kompilierung von bootclasspath und Systemserver-JARs (ausgelöst durch ein APEX-Update) vom frühen Start auf vor dem Neustart und verkürzt die Startzeit nach dem APEX-Update erheblich.

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

Das Sicherheitsziel besteht darin, verifizierte Eingaben wahrheitsgemäß zu kompilieren und die Ausgabe isoliert zu produzieren. Als nicht vertrauenswürdiger Client kann Android die Kompilierungsausgabe auf keine andere Weise ändern, als sie zum Scheitern zu bringen (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 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 auf der VM gemounteten APEXes und APKs definiert wird, zusätzlich zu anderen VM-Parametern, wie z. B. der Debugbarkeit.

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 Start gestartet.

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

Alle offengelegten 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-/Ausgabedateien wird von der VM überprüft, wobei die Dateien auf Android als nicht vertrauenswürdiger Dateiserver wie folgt 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 unbemerkt manipulieren.
• Die Integrität der Ausgabedatei muss in der VM gewahrt bleiben. Selbst wenn eine Ausgabedatei auf Android gespeichert wird, bleibt die Integrität während der Generierung mit demselben fs-verity Baumformat erhalten, kann jedoch 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.

,

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

Isolierte Zusammenstellung

Als softwaresichere Enklave bietet eine geschützte VM eine sichere Umgebung zum Kompilieren sicherheitsrelevanten Codes. Diese Umgebung ermöglicht das Verschieben der Kompilierung von bootclasspath und Systemserver-JARs (ausgelöst durch ein APEX-Update) vom frühen Start auf vor dem Neustart und verkürzt die Startzeit nach dem APEX-Update erheblich.

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

Das Sicherheitsziel besteht darin, verifizierte Eingaben wahrheitsgemäß zu kompilieren und die Ausgabe isoliert zu produzieren; Als nicht vertrauenswürdiger Client kann Android die Kompilierungsausgabe auf keine andere Weise ändern, als sie zum Scheitern zu bringen (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 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 auf der VM gemounteten APEXes und APKs definiert wird, zusätzlich zu anderen VM-Parametern, wie z. B. der Debugbarkeit.

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 Start gestartet.

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

Alle offengelegten 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 geprüft werden müssen.

Die Integrität der Eingabe-/Ausgabedateien wird von der VM überprüft, wobei die Dateien auf Android als nicht vertrauenswürdiger Dateiserver wie folgt 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 unbemerkt manipulieren.
• Die Integrität der Ausgabedatei muss in der VM gewahrt bleiben. Selbst wenn eine Ausgabedatei auf Android gespeichert wird, bleibt die Integrität während der Generierung mit demselben fs-verity Baumformat erhalten, kann jedoch 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.