Sicherheit

Um das Ausführen 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. Im Folgenden findest du eine Liste der AVF-Sicherheitsschichten:

  • 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 gestartet werden dürfen. Dabei wird das Verfahren Android Verified Boot eingehalten. Bei dieser Architektur können Apps, die pVMs ausführen, keine eigenen Kernel bündeln.

  • pVM bietet Defense-in-Depth-Maßnahmen, z. B. mit SELinux, für Nutzlasten, die in der pVM ausgeführt werden. Mit der mehrschichtigen Verteidigung ist es nicht zulässig, 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: Eine Reihe von Regeln, die den Zugriff auf Informationen einschränken.
  • 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 Rechtssubjekte.

Vertraulichkeit und Integrität

Die Vertraulichkeit ergibt sich aus den Eigenschaften der Arbeitsspeicherisolation, die vom pKVM-Hypervisor erzwungen werden. pKVM überwacht die Eigentümerschaft des Arbeitsspeichers einzelner physischer Arbeitsspeicherseiten und alle Anfragen von Eigentümern zur Freigabe von Seiten. pKVM sorgt dafür, dass nur berechtigte pVMs (Host und Gäste) die jeweilige Seite in ihren Seitentabellen der Stufe 2 zugeordnet haben, die vom Hypervisor gesteuert werden. Bei dieser Architektur bleibt der Inhalt des Arbeitsspeichers einer pVM privat, es sei denn, der Eigentümer gibt ihn explizit für eine andere pVM frei.

Die Einschränkungen zum Schutz der Vertraulichkeit gelten auch für alle Entitäten im System, die im Namen von pVMs Speicherzugriffe ausführen, nämlich DMA-fähige Geräte und Dienste, die in privilegierteren Schichten ausgeführt werden. Anbieter von System-on-Chips (SoC) müssen eine Reihe neuer Anforderungen erfüllen, bevor sie pKVM unterstützen können. Andernfalls kann keine Vertraulichkeit gewahrt werden.

Die Integrität gilt für Daten im Arbeitsspeicher und für die Berechnung. Für pVMs gilt Folgendes nicht:

  • Das Gedächtnis anderer ohne deren Einwilligung zu ändern.
  • Sie beeinflussen den CPU-Status der anderen.

Diese Anforderungen werden vom Hypervisor erzwungen. Probleme mit der Datenintegrität können jedoch auch beim virtuellen Datenspeicher auftreten, wenn andere Lösungen wie dm-verity oder AuthFS angewendet werden müssen.

Diese Prinzipien unterscheiden sich nicht von der Prozessisolierung von Linux, bei der der Zugriff auf Speicherseiten mit Seitentabellen der Stufe 1 gesteuert wird und der Kernel Kontextwechsel zwischen Prozessen vornimmt. Der EL2-Teil von pKVM, der diese Eigenschaften erzwingt, hat jedoch im Vergleich zum gesamten Linux-Kernel eine um drei Größenordnungen kleinere Angriffsfläche (ungefähr 10.000 im Vergleich zu 20 Millionen Codezeilen) und bietet daher eine stärkere Absicherung für Anwendungsfälle, die zu sensibel sind, um sich auf die Prozessisolierung zu verlassen.

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

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

Hypervisor

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

  • Eine pVM kann nur dann auf eine Seite zugreifen, die zu einer anderen Entität gehört, z. B. einer pVM oder einem Hypervisor, wenn sie vom Inhaber der Seite ausdrücklich freigegeben wurde. Diese Regel umfasst die Host-pVM 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 zerstört wird, wird sie gelöscht.

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

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

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

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

  • Die DICE-Zertifikatskette und die zusammengesetzten Geräte-IDs (Compound Device Identifiers, CDIs), die einer pVM-Instanz bereitgestellt werden, 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 Eigenschaften gelten im Falle einer Manipulation in einer beliebigen pVM, einschließlich des Hosts. Alternative Betriebssysteme, die in einer pVM ausgeführt werden, sollten ähnliche Eigenschaften bieten.

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

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

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

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

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

  • Microdroid stellt eine Attestierung für die Bootkette bereit.

  • Jede (unsignierte) Änderung an den Laufwerk-Images, die für die Gast-VM freigegeben wurden, führt zu einem I/O-Fehler auf der VM-Seite.

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

  • Schreibvorgänge auf ein verschlüsseltes Speichervolume sind vertraulich. Es gibt jedoch keinen Rollback-Schutz auf Ebene eines Verschlüsselungsblocks. Außerdem wird ein Datenblock, der auf andere Weise extern manipuliert wurde, von Microdroid als Müll behandelt, anstatt explizit als I/O-Fehler erkannt zu werden.

Android

Das sind Eigenschaften, die von Android als Host verwaltet werden, aber im Falle eines Host-Hacks nicht zutreffen:

  • Eine Gast-VM kann nicht direkt mit anderen Gast-VMs interagieren, z. B. um eine vsock-Verbindung herzustellen.

  • Nur die VirtualizationService in der Host-VM kann einen Kommunikationskanal zu einer VM herstellen.

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

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

Verfügbarkeit

Im Zusammenhang mit pVMs bezieht sich die Verfügbarkeit darauf, dass der Host den Gästen ausreichend Ressourcen zuweist, damit sie die vorgesehenen Aufgaben ausführen können.

Zu den Aufgaben des Hosts gehört die Planung der virtuellen CPUs der pVM. Anders als herkömmliche Type-1-Hypervisoren (z. B. Xen) wird bei KVM die explizite Designentscheidung getroffen, die Arbeitslastplanung an den Hostkernel zu delegieren. Angesichts der Größe und Komplexität der heutigen Scheduler reduziert diese Designentscheidung die Größe der Trusted Computing Base (TCB) erheblich und ermöglicht es dem Host, fundiertere Planungsentscheidungen zur Optimierung der Leistung zu treffen. Ein böswilliger Host kann jedoch festlegen, dass nie ein Gast geplant wird.

Ebenso delegiert pKVM die physische Interrupt-Verarbeitung an den Hostkernel, um die Komplexität des Hypervisors zu reduzieren und dem Host die Zuweisung zu überlassen. Wir bemühen uns, dafür zu sorgen, dass die Weiterleitung von Gastunterbrechungen nur zu einer Dienstverweigerung führt (zu wenige, zu viele oder falsch weitergeleitete Unterbrechungen).

Der VMM-Prozess (Virtual Machine Monitor) des Hosts ist schließlich 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 jederzeit vorzeitig beenden oder beenden und seine Ressourcen zurückfordern kann.

Sicherer Start

Daten sind an Instanzen einer pVM gebunden und Secure Boot sorgt dafür, dass der Zugriff auf die Daten einer Instanz gesteuert werden kann. Beim ersten Starten einer Instanz wird sie bereitgestellt, indem ein zufälliger geheimer Salt für die pVM generiert und Details wie öffentliche Verifizierungsschlüssel und Hashes aus den geladenen Images extrahiert werden. Anhand dieser Informationen werden nachfolgende Starts der pVM-Instanz verifiziert und sichergestellt, dass die Secrets der Instanz nur für Images freigegeben werden, die die Überprüfung bestehen. Dieser Vorgang wird für jede Ladephase innerhalb der pVM ausgeführt: pVM-Firmware, pVM-ABL, Microdroid usw.

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

Jede Phase übergibt der nächsten Phase ein deterministisch codiertes CBOR-Objekt. Dieses Objekt enthält Secrets und die DICE-Zertifikatskette, die kumulative Statusinformationen enthält, z. B. ob die letzte Stufe 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 eine pVM vertraulich sind, werden ebenfalls ungültig, wenn das Gerät entsperrt wird.

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

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