Sicherheit

Um zu verhindern, dass beliebige Payloads innerhalb einer pVM ausgeführt werden, verwendet Android Virtualization Framework (AVF) einen mehrschichtigen Sicherheitsansatz, bei dem jede Schicht zusätzliche Durchsetzungen hinzufügt. Es folgt 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 booten dürfen, 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 Tiefenverteidigung, wie z. B. mit SELinux , für Nutzlasten, die in der pVM ausgeführt werden. Defense-in-Depth verbietet Zuordnungsdaten als ausführbar ( 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 entwickelt wurde, um Informationssicherheitsrichtlinien zu leiten:

  • Vertraulichkeit ist eine Reihe von Regeln, die den Zugang zu Informationen einschränken.
  • Integrität ist die Zusicherung, 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 entwickelt wurde, um die Vertraulichkeit und Integrität, aber nicht die Verfügbarkeit von Gästen zu wahren. Diese Prinzipien beeinflussen Designentscheidungen, die alle Aspekte der Architektur umfassen, vom Hypervisor bis zu den Komponenten des Benutzerbereichs.

Vertraulichkeit und Integrität

Die Vertraulichkeit ergibt sich aus den Speicherisolationseigenschaften, die vom pKVM-Hypervisor erzwungen werden. pKVM verfolgt den Speicherbesitz einzelner physischer Speicherseiten und alle Anfragen von Eigentümern nach gemeinsam zu nutzenden Seiten. pKVM stellt sicher, dass nur berechtigte pVMs (Host und Gäste) die gegebene Seite in ihren vom Hypervisor gesteuerten Seitentabellen der Stufe 2 abgebildet haben. Diese Architektur behält bei, dass der Inhalt des Speichers, der einer pVM gehört, privat bleibt, es sei denn, der Besitzer teilt ihn explizit mit einer anderen pVM.

Einschränkungen zur Wahrung der Vertraulichkeit erstrecken sich auch auf alle Entitäten im System, die Speicherzugriffe im Auftrag von pVMs 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, da sonst keine Vertraulichkeit gewährleistet werden kann.

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-Zustand der anderen nicht beeinflussen.

Diese Anforderungen werden vom Hypervisor durchgesetzt. Aber auch bei der virtuellen Datenspeicherung treten Probleme hinsichtlich der Datenintegrität auf, wo 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, hat jedoch im Vergleich zum gesamten Linux-Kernel ungefähr die Hälfte der Angriffsfläche (ungefähr 10.000 gegenüber 20 Millionen Codezeilen) und bietet daher eine stärkere Sicherheit für Anwendungsfälle, auf die man sich nicht verlassen kann auf Prozessisolierung.

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 formal 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 misstrauten Ausführungsumgebungen isoliert. Diese Eigenschaften gelten im Falle einer Kompromittierung innerhalb einer beliebigen pVM, einschließlich des Hosts. Alternative Hypervisoren, die AVF entsprechen, müssen ähnliche Eigenschaften bereitstellen.

  • Eine pVM kann nicht auf eine Seite zugreifen, die zu einer anderen Entität gehört, wie z. B. einer pVM oder einem Hypervisor, es sei denn, der Seiteneigentümer hat dies ausdrücklich freigegeben. Diese Regel schließt die Host-pVM ein 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 der pVM-Firmware von einem Gerätestart wird gelöscht, bevor der OS-Bootloader beim nachfolgenden Gerätestart ausgeführt wird.
  • Wenn ein Hardware-Debugger wie SJTAG angeschlossen ist, kann eine pVM nicht auf ihre zuvor geprägten Schlüssel zugreifen.
  • Die pVM-Firmware bootet nicht, wenn sie das ursprüngliche Image nicht überprüfen kann.
  • Die pVM-Firmware startet nicht, wenn die Integrität von „ instance.img “ gefährdet 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 und einer Teilmenge des Android-Benutzerbereichs sowie einem Payload-Launcher. Diese Eigenschaften gelten im Falle einer Kompromittierung innerhalb einer beliebigen pVM, einschließlich des Hosts. Alternative Betriebssysteme, die in einer pVM ausgeführt werden, sollten ähnliche Eigenschaften bieten.

  • Microdroid bootet nicht, wenn boot.img , super.img , vbmeta.img oder vbmeta\_system.img nicht verifiziert werden können.
  • Microdroid bootet nicht, wenn die APK-Verifizierung fehlschlägt.
  • Dieselbe Microdroid-Instanz startet nicht, selbst wenn das APK aktualisiert wurde.
  • Microdroid bootet nicht, wenn eines der APEXs die Überprüfung nicht besteht.
  • Microdroid bootet nicht (oder bootet mit einem sauberen Anfangszustand), wenn die instance.img außerhalb der Gast-pVM geändert wird.
  • Microdroid stellt eine Bestätigung für die Boot-Kette bereit.
  • Jede (nicht signierte) Änderung an den Disk-Images, die für die Gast-pVM freigegeben werden, verursacht einen 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.

Android

Dies sind Eigenschaften, die von Android als Host gepflegt 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 zu ihnen 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 Berechtigung zum Erstellen, Besitzen oder Interagieren mit pVMs anfordern.
  • Die Kennung, Kontextkennung (CID) genannt, die beim Einrichten von Vsock- Verbindungen zwischen Host und pVM verwendet wird, wird nicht wiederverwendet, während die Host-pVM läuft. Beispielsweise ist es nicht möglich, eine laufende pVM durch eine andere zu ersetzen.

Verfügbarkeit

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

Zu den Verantwortlichkeiten des Hosts gehört das Scheduling der virtuellen CPUs der pVM. KVM trifft im Gegensatz zu herkömmlichen Typ-1-Hypervisoren wie Xen die explizite Designentscheidung, die Arbeitslastplanung an den Host-Kernel 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 zu treffen, um die Leistung zu optimieren. Ein böswilliger Host kann sich jedoch dafür entscheiden, niemals einen Gast zu planen.

In ähnlicher Weise delegiert pKVM auch die physische Interrupt-Behandlung an den Host-Kernel, um die Komplexität des Hypervisors zu reduzieren und dem Host die Verantwortung für die Planung zu überlassen. Es werden Anstrengungen unternommen, um sicherzustellen, dass die Weiterleitung von Gastunterbrechungen nur zu einer Dienstverweigerung führt (zu wenige, zu viele oder fehlgeleitete Unterbrechungen).

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

Obwohl pKVM keine Verfügbarkeit für Gäste bereitstellt, schützt das Design die Verfügbarkeit des Hosts vor böswilligen Gästen, da der Host einen Gast jederzeit vorbelegen oder beenden und seine Ressourcen zurückfordern kann.

Sicherer Startvorgang

Daten sind an Instanzen einer pVM gebunden, und sicheres Booten stellt sicher, dass der Zugriff auf die Daten einer Instanz kontrolliert werden kann. Beim ersten Booten einer Instanz wird diese bereitgestellt, indem zufällig ein geheimes Salt für die pVM generiert wird und Details wie öffentliche Verifizierungsschlüssel und Hashes aus den geladenen Images extrahiert werden. Diese Informationen werden verwendet, um nachfolgende Starts 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 Prozess findet für jede Ladephase innerhalb der pVM statt: pVM-Firmware, pVM ABL, Microdroid und so weiter.

DICE versieht jede Ladephase mit einem Beglaubigungsschlüsselpaar, dessen öffentlicher Teil im BCC-Eintrag für diese Phase zertifiziert ist. Dieses Schlüsselpaar kann sich zwischen Bootvorgängen ändern, sodass auch ein Versiegelungsgeheimnis abgeleitet wird, das für die VM-Instanz über Neustarts hinweg stabil ist und als solches zum Schutz des persistenten Zustands geeignet ist. Das Versiegelungsgeheimnis ist für die VM sehr wertvoll, daher sollte es nicht direkt verwendet werden. Stattdessen sollten aus dem Siegelgeheimnis Siegelschlüssel abgeleitet und das Siegelgeheimnis so früh wie möglich 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, beispielsweise ob die letzte Stufe sicher geladen wurde.

Entsperrte Geräte

Wenn ein Gerät mit fastboot oem unlock wird, werden Benutzerdaten gelöscht. Dieser Vorgang schützt Benutzerdaten vor unbefugtem Zugriff. Daten, die für eine pVM privat sind, werden auch ungültig gemacht, wenn eine Geräteentsperrung erfolgt.

Nach dem Entsperren steht es dem Besitzer des Geräts frei, Partitionen neu zu flashen, die normalerweise durch verifiziertes Booten geschützt sind, einschließlich Partitionen, die die pKVM-Implementierung enthalten. Daher wird pKVM auf einem entsperrten Gerät nicht vertraut, um das Sicherheitsmodell aufrechtzuerhalten.

Remote-Parteien können diesen potenziell unsicheren Zustand beobachten, indem sie den verifizierten Startzustand des Geräts in einem Schlüsselbeglaubigungszertifikat untersuchen.