Sicherheit

Um die Ausführung beliebiger Nutzlasten in einer pVM zu verhindern, verwendet das Android Virtualization Framework (AVF) einen mehrschichtigen Sicherheitsansatz, bei dem jede Schicht zusätzliche Erzwingungen hinzufügt. Es folgt eine Liste der AVF-Sicherheitsebenen:

• Android sorgt dafür, dass nur Anwendungen mit pVM-Berechtigungen pVMs erstellen oder prüfen dürfen.

• Bootloader – Der Bootloader sorgt dafür, dass nur von Google oder Geräteherstellern signierte pVM-Images gestartet werden dürfen, und respektiert das Verfahren Android Verified Boot. Diese Architektur impliziert, dass Anwendungen, die pVMs ausführen, keine eigenen Kernel bündeln können.

• pVM bietet gestaffelte Sicherheitsebenen, z. B. mit SELinux, für Nutzlasten, die in der pVM ausgeführt werden. Defense-in-depth lässt keine Zuordnungsdaten als ausführbar (neverallow execmem) zu und stellt sicher, dass W^X für alle Dateitypen enthalten ist.

Sicherheitsmodell

Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade) bilden ein Modell zur Steuerung von Richtlinien für die Informationssicherheit:

• Die Vertraulichkeit ist ein Regelwerk, das den Zugriff auf Informationen einschränkt.
• Integrität bedeutet, dass die Informationen vertrauenswürdig und korrekt sind.
• Die Verfügbarkeit ist eine Garantie für den zuverlässigen Zugriff auf die Informationen durch autorisierte Stellen.

Vertraulichkeit und Integrität

Die Vertraulichkeit ergibt sich aus den Eigenschaften der Arbeitsspeicherisolation, die vom pKVM-Hypervisor erzwungen werden. pKVM verfolgt die Arbeitsspeicherinhaberschaft einzelner Seiten des physischen Arbeitsspeichers sowie alle Anfragen von Inhabern für freizugebende Seiten. pKVM sorgt dafür, dass nur berechtigte pVMs (Host und Gäste) die jeweilige Seite in ihren Seitentabellen der Phase 2 zugeordnet haben, die vom Hypervisor gesteuert werden. Diese Architektur sorgt dafür, dass die Speicherinhalte einer pVM privat bleiben, es sei denn, der Eigentümer gibt sie ausdrücklich für eine andere pVM frei.

Die Einschränkungen zur Wahrung der Vertraulichkeit gelten auch für alle Entitäten im System, die Arbeitsspeicherzugriffe im Namen von pVMs ausführen, nämlich DMA-fähige Geräte und Dienste, die auf mehr privilegierten Ebenen ausgeführt werden. System-on-Chip-Anbieter (SoC) müssen neue Anforderungen erfüllen, damit sie pKVM unterstützen können. Andernfalls kann keine Vertraulichkeit gewährleistet werden.

Integrität gilt für Daten im Arbeitsspeicher und für Berechnungen. Für pVMs ist Folgendes nicht möglich:

• Das Gedächtnis der anderen ohne Zustimmung verändern.
• gegenseitig ihren CPU-Status beeinflussen

Diese Anforderungen werden vom Hypervisor durchgesetzt. Probleme in Bezug auf die Datenintegrität treten jedoch auch bei der virtuellen Datenspeicherung auf, wenn andere Lösungen wie dm-verity oder AuthFS angewendet werden müssen.

Diese Prinzipien unterscheiden sich nicht von der von Linux angebotenen Prozessisolation, bei der der Zugriff auf Speicherseiten über Seitentabellen der Phase 1 und der Kernel-Kontextwechsel zwischen Prozessen gesteuert wird. Der EL2-Teil der pKVM, der diese Attribute erzwingt, hat jedoch im Vergleich zum gesamten Linux-Kernel drei Größenordnungen weniger Angriffsfläche (etwa 10.000 im Vergleich zu 20 Millionen Codezeilen) und bietet daher mehr Sicherheit für Anwendungsfälle, die zu empfindlich sind, um sich auf die Prozessisolierung verlassen zu können.

Aufgrund seiner Größe eignet sich pKVM für eine formale Überprüfung. Wir unterstützen die akademische Forschung aktiv, die darauf abzielt, diese Eigenschaften auf der tatsächlichen pKVM-Binärdatei formal nachzuweisen.

Im weiteren Verlauf dieser Seite werden die Vertraulichkeits- und Integritätsgarantien behandelt, die jede Komponente um eine pKVM bietet.

Hypervisor

pKVM ist ein KVM-basierter Hypervisor, der pVMs und Android in gegenseitig nicht vertrauenswürdige Ausführungsumgebungen isoliert. Diese Attribute gelten, wenn eine pVM, einschließlich des Hosts, manipuliert wird. Alternative Hypervisoren, die AVF erfüllen, müssen ähnliche Properties bereitstellen.

• Eine pVM kann nicht auf eine Seite zugreifen, die zu einer anderen Entität gehört, z. B. einer pVM oder einem Hypervisor, es sei denn, der Seiteninhaber hat dies explizit freigegeben. Diese Regel umfasst die pVM des Hosts und gilt sowohl für CPU- als auch für DMA-Zugriffe.

• Bevor eine von einer pVM verwendete Seite an den Host zurückgegeben wird, z. B. wenn die pVM gelöscht wird, wird sie gelöscht.

• Der Arbeitsspeicher aller pVMs und die pVM-Firmware eines Gerätestarts wird gelöscht, bevor der Betriebssystem-Bootloader beim nachfolgenden Gerätestart ausgeführt wird.

• Wenn ein Hardware-Debugger wie SJTAG angehängt ist, kann eine pVM nicht auf die zuvor erstellten Schlüssel zugreifen.

• Die pVM-Firmware startet nicht, wenn das anfängliche Image nicht verifiziert werden kann.

• Die pVM-Firmware startet nicht, wenn die Integrität von instance.img kompromittiert ist.

• Eine pVM-Instanz bereitgestellte DICE-Zertifikatskette und CDIs (Compound Device Identifiers) können nur von dieser bestimmten Instanz abgeleitet werden.

Gastbetriebssystem

Microdroid ist ein Beispiel für ein Betriebssystem, das in einer pVM ausgeführt wird. Microdroid besteht aus einem U-Boot-basierten Bootloader, GKI, einem Teil des Android-Nutzerbereichs und einem Nutzlast-Launcher. Diese Attribute gelten, wenn eine pVM, einschließlich des Hosts, gehackt wird. Alternative Betriebssysteme, die in einer pVM ausgeführt werden, sollten ähnliche Eigenschaften haben.

• Microdroid startet nicht, wenn boot.img, super.img, vbmeta.img oder vbmeta\_system.img nicht bestätigt werden kann.

• Microdroid startet nicht, wenn die APK-Überprüfung fehlschlägt.

• Dieselbe Microdroid-Instanz wird nicht gestartet, auch wenn das APK aktualisiert wurde.

• Microdroid startet nicht, wenn eines der APEX-Dateien die Überprüfung nicht besteht.

• Microdroid startet nicht (oder mit einem sauberen Anfangszustand), wenn instance.img außerhalb der Gast-pVM geändert wird.

• Microdroid bestätigt die Bootkette.

• Jede (nicht signierte) Änderung an den für die Gast-pVM freigegebenen Laufwerk-Images führt auf der pVM-Seite zu einem E/A-Fehler.

• Die DICE-Zertifikatskette und die CDIs, die für eine pVM-Instanz bereitgestellt werden, können nur von der jeweiligen Instanz abgeleitet werden.

• Schreibvorgänge auf einem verschlüsselten Speicher-Volume sind vertraulich. Es gibt jedoch keinen Rollback-Schutz mit der Genauigkeit eines Verschlüsselungsblocks. Darüber hinaus führt andere beliebige externe Manipulationen eines Datenblocks dazu, dass dieser Block für Microdroid als Garbage erscheint und nicht explizit als E/A-Fehler erkannt wird.

Android

Diese Eigenschaften werden von Android als Host verwaltet, gelten aber nicht für den Fall einer Hostmanipulation:

• Eine Gast-pVM kann nicht direkt mit anderen Gast-pVMs interagieren, beispielsweise um eine vsock-Verbindung herzustellen.

• Nur der VirtualizationService in der Host-pVM kann einen Kommunikationskanal zu einer pVM machen.

• Nur die Anwendungen, die mit dem Plattformschlüssel signiert sind, können die Berechtigung zum Erstellen, Eigentümer oder Interagieren mit pVMs anfordern.

• Die Kennung, die als Kontextkennung bezeichnet wird und zum Einrichten von vsock-Verbindungen zwischen dem Host und der pVM verwendet wird, wird nicht wiederverwendet, wenn die pVM des Hosts ausgeführt wird. Sie können eine laufende pVM beispielsweise nicht durch eine andere ersetzen.

Verfügbarkeit

Im Kontext von pVMs bezieht sich Verfügbarkeit darauf, dass der Host Gästen genügend Ressourcen zuweist, damit Gäste die Aufgaben ausführen können, für die sie vorgesehen sind.

Zu den Aufgaben des Hosts gehört die Planung der virtuellen CPUs der pVM. Im Gegensatz zu konventionellen Typ-1-Hypervisoren (wie Xen) trifft KVM die ausdrückliche Designentscheidung, die Arbeitslastplanung an den Hostkernel zu delegieren. Angesichts der Größe und Komplexität der heutigen Planer reduziert diese Designentscheidung die Größe der Trusted Computing Base (TCB) erheblich und der Host kann fundiertere Planungsentscheidungen zur Leistungsoptimierung treffen. Ein schädlicher Host kann jedoch entscheiden, keinen Gast zu planen.

In ähnlicher Weise delegiert pKVM auch die Verarbeitung physischer Unterbrechungen an den Hostkernel, um die Komplexität des Hypervisors zu reduzieren und die Planung vom Host zu überlassen. Es wird dafür gesorgt, dass die Weiterleitung von Gastunterbrechungen nur zu einer Dienstverweigerung führt (zu wenige, zu viele oder falsch weitergeleitete Unterbrechungen).

Schließlich ist der VMM-Prozess (Virtual Machine Monitor) des Hosts für die Arbeitsspeicherzuweisung und die Bereitstellung virtueller Geräte, z. B. einer Netzwerkkarte, verantwortlich. Ein schädliches VMM kann Ressourcen vom Gast zurückhalten.

Obwohl pKVM keine Verfügbarkeit für Gäste bietet, schützt das Design die Verfügbarkeit des Hosts vor schädlichen Gästen, da der Host einen Gast jederzeit vorzeitig beenden oder beenden und seine Ressourcen freigeben kann.

Sicherer Start

Daten sind an Instanzen einer pVM gebunden. Secure Boot sorgt dafür, dass der Zugriff auf die Daten einer Instanz gesteuert werden kann. Der erste Start einer Instanz stellt diesen bereit, indem nach dem Zufallsprinzip ein Secret-Salt für die pVM generiert und Details wie öffentliche Verifizierungsschlüssel und Hashes aus den geladenen Images extrahiert werden. Diese Informationen werden verwendet, um nachfolgende Startvorgänge der pVM-Instanz zu verifizieren und sicherzustellen, dass die Secrets der Instanz nur für Images freigegeben werden, die die Prüfung bestehen. Dieser Prozess findet für jede Ladephase innerhalb der pVM statt: pVM-Firmware, pVM ABL, Microdroid usw.

DICE stellt für jede Ladephase ein Attestierungsschlüsselpaar bereit, dessen öffentlicher Teil im DICE-Zertifikat für diese Phase zertifiziert ist. Dieses Schlüsselpaar kann sich zwischen Starts ändern, sodass auch ein Sealing-Secret abgeleitet wird, das für die VM-Instanz auch nach einem Neustart stabil bleibt und sich aus diesem Grund zum Schutz des nichtflüchtigen Zustands eignet. Das Dichtungs-Secret ist für die VM sehr wertvoll und sollte daher nicht direkt verwendet werden. Stattdessen sollten Versiegelungsschlüssel aus dem Versiegelungs-Secret abgeleitet und das Versiegelungsgeheimnis so früh wie möglich gelöscht werden.

In jeder Phase wird ein deterministisch codiertes CBOR-Objekt an die nächste Phase übergeben. Dieses Objekt enthält Secrets und die DICE-Zertifikatskette, die kumulierte Statusinformationen enthält, z. B. ob die letzte Phase sicher geladen wurde.

Entsperrte Geräte

Wenn ein Gerät mit fastboot oem unlock entsperrt wird, werden die Nutzerdaten gelöscht. Dieser Prozess schützt Nutzerdaten vor unbefugtem Zugriff. Daten, die auf einer pVM privat sind, werden auch ungültig, wenn das Gerät entsperrt wird.

Nach dem Entsperren kann der Eigentümer des Geräts Partitionen, die normalerweise durch den verifizierten Bootmodus geschützt sind, neu flashen, einschließlich der Partitionen, die die pKVM-Implementierung enthalten. Daher gilt pKVM auf einem entsperrten Gerät nicht als vertrauenswürdig, um das Sicherheitsmodell aufrechtzuerhalten.

Drittanbieter können diesen potenziell unsicheren Status beobachten, indem sie den bestätigten Bootstatus des Geräts in einem Schlüsselattestierungszertifikat prüfen.