Sicherheit

Um zu verhindern, dass beliebige Nutzlasten in einer pVM ausgeführt werden, verwendet das Android Virtualization Framework (AVF) einen mehrschichtigen Sicherheitsansatz, bei dem jede Schicht zusätzliche Sicherheitsmaßnahmen hinzufügt. Im Folgenden finden Sie eine Liste der AVF-Sicherheitsebenen:

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

• Bootloader: Der Bootloader sorgt dafür, dass nur von Google oder Geräteanbietern signierte pVM-Images gebootet werden dürfen, und hält sich an das Android Verified Boot-Verfahren. Diese Architektur impliziert, dass Apps, die pVMs ausführen, keine eigenen Kernel bündeln können.

• pVM bietet Defense-in-Depth, z. B. mit SELinux, für Nutzlasten, die in der pVM ausgeführt werden. Durch die mehrschichtige Sicherheit ist es nicht möglich, Daten als ausführbar (neverallow execmem) zuzuordnen. Außerdem wird sichergestellt, dass W^X für alle Dateitypen gilt.

Sicherheitsmodell

Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade) bilden ein Modell, das als Leitfaden für Richtlinien zur Informationssicherheit dient:

• Vertraulichkeit ist eine Reihe von Regeln, die den Zugriff auf Informationen einschränken.
• Integrität bedeutet, dass die Informationen vertrauenswürdig und korrekt sind.
• Verfügbarkeit ist eine Garantie für den zuverlässigen Zugriff auf die Informationen durch autorisierte Stellen.

Vertraulichkeit und Integrität

Vertraulichkeit ergibt sich aus den Eigenschaften der Speicherisolation, die vom pKVM-Hypervisor erzwungen werden. pKVM verfolgt die Speichereigentümerschaft einzelner physischer Speicherseiten und alle Anfragen von Eigentümern, Seiten freizugeben. pKVM sorgt dafür, dass nur berechtigte pVMs (Host und Gäste) die entsprechende Seite in ihren von Hypervisor gesteuerten Stage 2-Seitentabellen zugeordnet haben. In dieser Architektur bleiben die Inhalte des Speichers, der einer pVM gehört, privat, sofern der Inhaber sie nicht explizit für eine andere pVM freigibt.

Die Einschränkungen zur Wahrung der Vertraulichkeit gelten auch für alle Einheiten im System, die im Namen von pVMs auf den Speicher zugreifen, nämlich DMA-fähige Geräte und Dienste, die in privilegierteren Ebenen ausgeführt werden. SoC-Anbieter (System-on-Chip) müssen eine Reihe neuer Anforderungen erfüllen, bevor sie pKVM unterstützen können. Andernfalls kann keine Vertraulichkeit gewährleistet werden.

Integrität bezieht sich auf Daten im Arbeitsspeicher und auf die Berechnung. pVMs können Folgendes nicht:

• Die Erinnerungen anderer Nutzer ohne deren Einwilligung ändern.
• Sie beeinflussen sich gegenseitig in Bezug auf den CPU-Status.

Diese Anforderungen werden vom Hypervisor erzwungen. Probleme mit der 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 Prozessisolation, die von Linux angeboten wird, wo der Zugriff auf Speicherseiten mit Stage 1-Seitentabellen gesteuert wird und der Kernel zwischen Prozessen wechselt. Der EL2-Teil von pKVM, der diese Eigenschaften erzwingt, hat jedoch eine um drei Größenordnungen geringere Angriffsfläche als der gesamte Linux-Kernel (etwa 10.000 gegenüber 20 Millionen Codezeilen) und bietet daher eine höhere Sicherheit für Anwendungsfälle, die zu sensibel sind, um sich auf die Prozessisolation zu verlassen.

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

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

Hypervisor

pKVM ist ein KVM-basierter Hypervisor, der pVMs und Android in gegenseitig nicht vertrauenswürdige Ausführungsumgebungen isoliert. Diese Eigenschaften gelten auch im Falle einer Kompromittierung einer beliebigen pVM, einschließlich des Hosts. Alternative Hypervisoren, die AVF-kompatibel sind, müssen ähnliche Eigenschaften bieten.

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

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

• Der Speicher aller pVMs und die pVM-Firmware von einem Geräte-Boot werden gelöscht, bevor der OS-Bootloader beim nächsten Geräte-Boot ausgeführt wird.

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

• Die pVM-Firmware wird nicht gestartet, wenn das ursprüngliche Image nicht überprüft werden kann.

• Die pVM-Firmware wird nicht gestartet, wenn die Integrität von instance.img beeinträchtigt ist.

• Die DICE-Zertifikatskette und die Compound Device Identifiers (CDIs), die für eine pVM-Instanz bereitgestellt werden, können nur von dieser Instanz abgeleitet werden.

Gastbetriebssystem

Microdroid ist ein Beispiel für ein Betriebssystem, das auf einer pVM ausgeführt wird. Microdroid besteht aus einem auf U-Boot basierenden Bootloader, GKI, einer Teilmenge des Android-Nutzerbereichs und einem Payload-Launcher. Diese Eigenschaften gelten im Falle einer Sicherheitslücke in einer beliebigen pVM, einschließlich des Hosts. Alternative Betriebssysteme, die auf einer pVM ausgeführt werden, sollten ähnliche Eigenschaften haben.

• Microdroid wird nicht gestartet, wenn boot.img, super.img, vbmeta.img oder vbmeta\_system.img nicht überprüft werden können.

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

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

• Microdroid wird nicht gestartet, wenn einer der APEX-Module die Überprüfung nicht besteht.

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

• Microdroid bietet Attestierung für die Boot-Kette.

• Jede (nicht signierte) Änderung an den mit der Gast-pVM geteilten Datenträger-Images führt zu einem E/A-Fehler auf der pVM-Seite.

• Die DICE-Zertifikatskette und die CDIs, die einer pVM-Instanz bereitgestellt werden, können nur von dieser Instanz abgeleitet werden.

• Schreibvorgänge in ein verschlüsseltes Speichervolume sind vertraulich, es gibt jedoch keinen Rollback-Schutz auf der Granularität eines Verschlüsselungsblocks. Außerdem führt jede andere willkürliche externe Manipulation eines Datenblocks dazu, dass dieser Block für Microdroid als Müll erscheint, anstatt explizit als E/A-Fehler erkannt zu werden.

Android

Dies sind Eigenschaften, die von Android als Host verwaltet werden, aber im Falle einer Host-Gefährdung nicht zutreffen:

• Eine Gast-pVM kann nicht direkt mit anderen Gast-pVMs interagieren, z. B. eine vsock-Verbindung herstellen.

• Nur die VirtualizationService im Host-pVM kann einen Kommunikationskanal zu einem pVM erstellen.

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

• Die Kennung, die beim Einrichten von vsock-Verbindungen zwischen dem Host und der privaten VM verwendet wird, wird nicht wiederverwendet, wenn die private VM des Hosts ausgeführt wird. Diese Kennung wird als Kontext-ID (CID) bezeichnet. Sie können beispielsweise keine laufende pVM durch eine andere ersetzen.

Verfügbarkeit

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

Zu den Aufgaben des Hosts gehört die Planung der virtuellen CPUs der pVM. Im Gegensatz zu herkömmlichen Typ-1-Hypervisoren (z. B. Xen) wird bei KVM die Arbeitslastplanung explizit an den Hostkernel delegiert. Angesichts der Größe und Komplexität der heutigen Scheduler wird durch diese Designentscheidung die Größe der Trusted Computing Base (TCB) erheblich reduziert. Außerdem kann der Host fundiertere Planungsentscheidungen treffen, um die Leistung zu optimieren. Ein böswilliger Host kann jedoch entscheiden, niemals einen Gast einzuplanen.

Ähnlich wie bei pKVM wird auch die Verarbeitung physischer Interrupts an den Hostkernel delegiert, um die Komplexität des Hypervisors zu verringern und dem Host die Planung zu überlassen. Es wird darauf geachtet, dass die Weiterleitung von Gastunterbrechungen nur zu einer Denial of Service führt (zu wenige, zu viele oder falsch weitergeleitete Unterbrechungen).

Schließlich ist der VMM-Prozess (Virtual Machine Monitor) des Hosts für die Zuweisung von Arbeitsspeicher und die Bereitstellung virtueller Geräte wie einer Netzwerkkarte verantwortlich. Ein schädlicher VMM kann dem Gast Ressourcen vorenthalten.

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 immer unterbrechen oder beenden und seine Ressourcen zurückfordern kann.

Secure Boot

Daten sind an Instanzen einer pVM gebunden und Secure Boot sorgt dafür, dass der Zugriff auf die Daten einer Instanz kontrolliert werden kann. Beim ersten Booten einer Instanz wird sie bereitgestellt, indem ein zufälliges geheimes Salt für die pVM generiert und Details wie öffentliche Schlüssel und Hashes für die Überprüfung aus den geladenen Images extrahiert werden. Diese Informationen werden verwendet, um nachfolgende Starts der pVM-Instanz zu überprüfen und dafür zu sorgen, dass die Secrets der Instanz nur für Images freigegeben werden, die die Überprüfung bestehen. Dieser Prozess erfolgt für jede Ladestufe in der pVM: pVM-Firmware, pVM-ABL, Microdroid usw.

DICE stellt jeder Ladestufe ein Attestierungsschlüsselpaar zur Verfügung, dessen öffentlicher Teil im DICE-Zertifikat für diese Stufe zertifiziert ist. Dieses Schlüsselpaar kann sich zwischen den Starts ändern. Daher wird auch ein Sealing Secret abgeleitet, das für die VM-Instanz über Neustarts hinweg stabil ist und sich daher zum Schutz des persistenten Status eignet. Das Sealing-Secret ist für die VM sehr wertvoll und sollte daher nicht direkt verwendet werden. Stattdessen sollten die Versiegelungsschlüssel aus dem Versiegelungs-Secret abgeleitet und das Versiegelungs-Secret so schnell wie möglich vernichtet werden.

In jeder Phase wird ein deterministisch codiertes CBOR-Objekt an die nächste Phase übergeben. Dieses Objekt enthält Secrets und die DICE-Zertifikatkette, 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. So werden Nutzerdaten vor unbefugtem Zugriff geschützt. Daten, die für ein privates Profil vertraulich sind, werden ebenfalls ungültig, wenn ein Gerät entsperrt wird.

Nach dem Entsperren kann der Geräteinhaber Partitionen neu flashen, die normalerweise durch Verified Boot geschützt sind, einschließlich der Partitionen, die pvmfw und die pKVM-Implementierung enthalten. Daher wird ein entsperrtes Gerät nicht als vertrauenswürdig eingestuft, um das Sicherheitsmodell einer pVM aufrechtzuerhalten.

Externe Parteien können diesen potenziell unsicheren Status erkennen, indem sie den Status des verifizierten Bootvorgangs des Geräts in einem Schlüsselattestierungszertifikat prüfen.