Sicherheit

Um die Ausführung willkürlicher Nutzlasten innerhalb einer pVM zu verhindern, verwendet Android Virtualization Framework (AVF) einen mehrschichtigen Sicherheitsansatz, bei dem jede Schicht zusätzliche Durchsetzungsmaßnahmen hinzufügt. Im Folgenden finden Sie eine Liste der AVF-Sicherheitsebenen:

  • Android – Android stellt sicher, dass nur Apps mit pVM-Berechtigungen pVMs erstellen oder prüfen dürfen.

  • Bootloader – Der Bootloader stellt sicher, dass nur von Google oder Geräteherstellern signierte pVM-Images zum Booten zugelassen werden, und respektiert das Android Verified Boot- Verfahren. Diese Architektur impliziert, dass Apps, auf denen pVMs ausgeführt werden, ihre eigenen Kernel nicht bündeln können.

  • pVM – Die pVM bietet eine tiefgreifende Verteidigung, beispielsweise mit SELinux , für Nutzlasten, die in der pVM ausgeführt werden. Die Tiefenverteidigung verbietet die Zuordnung von Daten als ausführbare Datei ( neverallow execmem ) und stellt sicher, dass W^X für alle Dateitypen gilt.

Sicherheitsmodell

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

  • Vertraulichkeit ist eine Reihe von Regeln, die den Zugang zu Informationen einschränken.
  • Integrität ist die Gewissheit, 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.

Beachten Sie, dass pKVM zur Wahrung der Vertraulichkeit und Integrität, nicht aber der Verfügbarkeit von Gästen konzipiert wurde. Diese Prinzipien beeinflussen Designentscheidungen, die alle Aspekte der Architektur umfassen, vom Hypervisor bis zu den User-Space-Komponenten.

Vertraulichkeit und Integrität

Die Vertraulichkeit ergibt sich aus den vom pKVM-Hypervisor erzwungenen Speicherisolationseigenschaften. pKVM verfolgt den Speicherbesitz einzelner physischer Speicherseiten und alle Anfragen von Eigentümern nach der gemeinsamen Nutzung von Seiten. pKVM stellt sicher, dass nur berechtigten pVMs (Host und Gästen) die angegebene Seite in ihren Seitentabellen der Stufe 2 zugeordnet ist, die vom Hypervisor gesteuert werden. Diese Architektur stellt sicher, dass der Inhalt des Speichers, der einer pVM gehört, privat bleibt, es sei denn, der Eigentümer teilt ihn ausdrücklich mit einer anderen pVM.

Einschränkungen zur Wahrung der Vertraulichkeit erstrecken sich auch auf alle Einheiten im System, die im Auftrag von pVMs Speicherzugriffe durchführen, nämlich DMA-fähige Geräte und Dienste, die in privilegierteren Schichten ausgeführt werden . SoC-Anbieter müssen eine Reihe neuer Anforderungen erfüllen, bevor sie pKVM unterstützen können, andernfalls kann die Vertraulichkeit nicht gewährleistet werden.

Integrität gilt sowohl für Daten im Speicher als auch für Berechnungen:

  • pVMs können den Speicher des anderen nicht ohne Zustimmung ändern.
  • pVMs können den CPU-Status der anderen nicht beeinflussen.

Diese Anforderungen werden vom Hypervisor durchgesetzt. Aber auch bei der virtuellen Datenspeicherung treten Probleme hinsichtlich der Datenintegrität auf, wenn andere Lösungen wie dm-verity oder AuthFS zum Einsatz kommen müssen.

Diese Prinzipien unterscheiden sich nicht von der von Linux angebotenen Prozessisolation, bei der der Zugriff auf Speicherseiten mit Seitentabellen der Stufe 1 gesteuert wird und der Kernel-Kontext zwischen Prozessen wechselt. Der EL2-Teil von pKVM, der diese Eigenschaften erzwingt, verfügt jedoch im Vergleich zum gesamten Linux-Kernel über etwa die Hälfte der Angriffsfläche (ungefähr 10.000 gegenüber 20 Millionen Codezeilen) und bietet daher eine höhere Sicherheit für Anwendungsfälle, die zu sensibel sind, als dass man sich darauf verlassen könnte zur Prozessisolation.

Aufgrund seiner Größe eignet sich ein pKVM für eine formale Verifizierung. Wir unterstützen aktiv die akademische Forschung, die darauf abzielt, diese Eigenschaften an der tatsächlichen pKVM-Binärdatei offiziell zu beweisen.

Der Rest dieses Dokuments behandelt die Vertraulichkeits- und Integritätsgarantien, die jede Komponente rund um ein pKVM bietet.

Hypervisor

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

  • 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, dies wird vom Seiteneigentümer ausdrücklich freigegeben. 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, beispielsweise wenn die pVM zerstört wird, wird sie gelöscht.
  • Der Speicher aller pVMs und die pVM-Firmware von einem Gerätestart werden gelöscht, bevor der Betriebssystem-Bootloader beim nachfolgenden 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 startet nicht, wenn sie das ursprüngliche Image nicht überprüfen kann.
  • Die pVM-Firmware startet nicht, wenn die Integrität der instance.img beeinträchtigt ist.
  • Boot Certificate Chain (BCC) und 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, einer Teilmenge des Android-Benutzerbereichs und einem Payload-Launcher. Diese Eigenschaften gelten auch im Falle einer Kompromittierung innerhalb einer 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 überprüft werden kann.
  • Microdroid startet nicht, wenn die APK-Überprüfung fehlschlägt.
  • Dieselbe Microdroid-Instanz startet nicht, selbst wenn das APK aktualisiert wurde.
  • Microdroid startet nicht, wenn eines der APEXes die Überprüfung nicht besteht.
  • Microdroid startet nicht (oder startet mit einem sauberen Anfangszustand), wenn die instance.img außerhalb der Gast-pVM geändert wird.
  • Microdroid bietet einen Nachweis der Boot-Kette.
  • Jede (nicht signierte) Änderung an den Festplatten-Images, die für die Gast-pVM freigegeben sind, führt zu einem E/A-Fehler auf der pVM-Seite.
  • BCC und 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 der Granularität eines Verschlüsselungsblocks. Darüber hinaus führen andere willkürliche externe Manipulationen an einem Datenblock dazu, dass dieser Block für Microdroid als Müll erscheint und nicht explizit als E/A-Fehler erkannt wird.

Android

Dies sind Eigenschaften, die von Android als Host verwaltet werden, aber im Falle einer Host-Kompromittierung nicht gelten:

  • Eine Gast-pVM kann nicht direkt mit anderen Gast-pVMs interagieren (z. B. eine vsock-Verbindung herstellen).
  • Nur der VirtualizationService in der Host-pVM kann einen Kommunikationskanal zu einer pVM herstellen (Hinweis: Er kann den eingerichteten Kanal an andere weitergeben).
  • Nur die Apps, die mit dem Plattformschlüssel signiert sind, können die Erlaubnis zum Erstellen, Besitzen oder Interagieren mit pVMs anfordern.
  • Der als Kontext-ID (Context Identifier, CID) bezeichnete Bezeichner, der beim Einrichten von vsock- Verbindungen zwischen Host und pVM verwendet wird, wird nicht wiederverwendet, während die Host-pVM ausgeführt wird. Beispielsweise ist es nicht möglich, eine laufende pVM durch eine andere zu ersetzen.

Verfügbarkeit

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

Zu den Aufgaben des Hosts gehört die Planung der virtuellen CPUs der pVM. Im Gegensatz zu herkömmlichen Typ-1-Hypervisoren wie Xen trifft KVM die explizite Designentscheidung, die Arbeitslastplanung an den Host-Kernel zu delegieren. Angesichts der Größe und Komplexität heutiger 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 sich jedoch dafür entscheiden, niemals einen Gast einzuplanen.

In ähnlicher Weise delegiert pKVM auch die physische Interrupt-Verarbeitung an den Host-Kernel, um die Komplexität des Hypervisors zu reduzieren und die Planung dem Host zu überlassen. Es wird darauf geachtet, dass die Weiterleitung von Gast-Interrupts nur zu einem Denial-of-Service führt (zu wenige, zu viele oder fehlgeleitete Interrupts).

Schließlich ist der Virtual Machine Monitor (VMM)-Prozess des Hosts für die Speicherzuweisung und die Bereitstellung virtueller Geräte, beispielsweise einer Netzwerkkarte, verantwortlich. Ein böswilliger VMM kann dem Gast Ressourcen vorenthalten.

Obwohl pKVM Gästen keine Verfügbarkeit bietet, schützt das Design die Verfügbarkeit des Hosts vor böswilligen Gästen, da der Host einem Gast jederzeit zuvorkommen oder ihn beenden und seine Ressourcen zurückfordern kann.

Sicherer Startvorgang

Daten sind an Instanzen einer pVM gebunden, und der sichere Start stellt sicher, dass der Zugriff auf die Daten einer Instanz kontrolliert werden kann. Beim ersten Start einer Instanz wird diese bereitgestellt, indem zufällig ein geheimer Salt für die pVM generiert und Details wie öffentliche Verifizierungsschlüssel und Hashes aus den geladenen Bildern extrahiert werden. Diese Informationen werden verwendet, um nachfolgende Startvorgänge der pVM-Instanz zu überprüfen und sicherzustellen, dass die Geheimnisse der Instanz nur für Images freigegeben werden, die die Überprüfung bestehen. Dieser Vorgang findet für jede Ladephase innerhalb der pVM statt: pVM-Firmware, pVM ABL, Microdroid usw.

DICE stellt jeder Ladestufe ein Attestierungsschlüsselpaar zur Verfügung, dessen öffentlicher Teil im BCC-Eintrag für diese Stufe zertifiziert wird. Dieses Schlüsselpaar kann sich zwischen den Starts ändern, sodass auch ein Versiegelungsgeheimnis abgeleitet wird, das für die VM-Instanz über Neustarts hinweg stabil ist und sich daher zum Schutz des persistenten Zustands eignet. Das Siegelgeheimnis ist für die VM sehr wertvoll und sollte daher nicht direkt verwendet werden. Stattdessen sollten Siegelschlüssel aus dem Siegelgeheimnis abgeleitet werden und das Siegelgeheimnis möglichst frühzeitig vernichtet werden.

Jede Stufe übergibt ein deterministisch codiertes CBOR- Objekt an die nächste Stufe. Dieses Objekt enthält Geheimnisse und den BCC, der gesammelte 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 Benutzerdaten gelöscht. Dieser Prozess schützt Benutzerdaten vor unbefugtem Zugriff. Daten, die für eine pVM privat sind, werden auch ungültig, wenn eine Geräteentsperrung erfolgt.

Nach der Entsperrung steht es dem Besitzer des Geräts frei, Partitionen neu zu flashen, die normalerweise durch verifizierten Start geschützt sind, einschließlich Partitionen, die die pKVM-Implementierung enthalten. Daher wird pKVM auf einem entsperrten Gerät nicht als vertrauenswürdig eingestuft, um das Sicherheitsmodell aufrechtzuerhalten.

Remote-Parteien können diesen potenziell unsicheren Zustand beobachten, indem sie den verifizierten Startstatus des Geräts in einem Schlüsselbescheinigungszertifikat überprüfen.