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 Verfahren Android Verified Boot. Diese Architektur bedeutet, 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 ist die Gewährleistung, 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 vom Hypervisor gesteuerten Stage 2-Seitentabellen zugeordnet haben. Bei dieser Architektur bleiben die Inhalte des Speichers einer privaten VM privat, sofern der Inhaber sie nicht explizit für eine andere private VM freigibt.

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 den CPU-Status des jeweils anderen.

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 Stufe-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 nur dann auf eine Seite zugreifen, die zu einer anderen Einheit gehört, z. B. einer PVM oder einem Hypervisor, wenn sie vom Seiteninhaber explizit freigegeben wurde. Diese Regel umfasst den 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 Betriebssystem-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 U-Boot-basierten Bootloader, einem GKI, einer Teilmenge des Android-Nutzerbereichs und einem Payload-Launcher. Diese Eigenschaften gelten im Falle einer Kompromittierung einer beliebigen pVM, einschließlich des Hosts. Alternative Betriebssysteme, die auf einer pVM ausgeführt werden, sollten ähnliche Eigenschaften bieten.

  • Microdroid wird nicht gestartet, wenn boot.img, super.img, vbmeta.img oder vbmeta\_system.img nicht bestätigt werden können.

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

  • 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 auf 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 eine laufende pVM nicht 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 explizite Designentscheidung getroffen, die Planung von Arbeitslasten an den Hostkernel zu delegieren. Angesichts der Größe und Komplexität heutiger 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 einem 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.

Sicherer Start

Daten sind an Instanzen einer pVM gebunden und durch Secure Boot wird sichergestellt, 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 wird für jede Ladestufe in der pVM durchlaufen: 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 Versiegelungs-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 beobachten, indem sie den Status des verifizierten Bootvorgangs des Geräts in einem Schlüsselattestierungszertifikat prüfen.