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. Diese Architektur impliziert, dass Anwendungen, die pVMs ausführen, keine eigenen Kernel bündeln können.

  • pVM bietet gestaffelte Sicherheitsebenen, 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 zur Steuerung von Richtlinien für die Informationssicherheit:

  • 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 zur Wahrung der Vertraulichkeit gelten auch für alle Entitäten im System, die Arbeitsspeicherzugriffe im Namen von pVMs ausführen, nämlich DMA-fähige Geräte und Dienste, die auf mehr privilegierten Ebenen 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 gewährleistet werden.

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

  • Das Gedächtnis anderer ohne deren Einwilligung zu verändern.
  • gegenseitig ihren CPU-Status beeinflussen

Diese Anforderungen werden vom Hypervisor erzwungen. Probleme mit der Datenintegrität treten jedoch auch beim virtuellen Datenspeicher auf, 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 und dem Kernel-Kontextwechsel zwischen Prozessen gesteuert wird. 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 eine formale Überprüfung. Wir unterstützen aktiv akademische Forschung, die darauf abzielt, diese Eigenschaften für die tatsächliche pKVM-Binärdatei formal nachzuweisen.

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

Hypervisor

pKVM ist ein KVM-basierter Hypervisor, der pVMs und Android in gegenseitig nicht vertrauenswürdigen 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 pVM des Hosts 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 gelöscht 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 angehängt ist, kann eine pVM nicht auf die zuvor erstellten Schlüssel zugreifen.

  • Die pVM-Firmware startet nicht, wenn das anfängliche Image nicht verifiziert 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 Attribute gelten, wenn eine pVM, einschließlich des Hosts, gehackt wird. 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 wird nicht gestartet, 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 für eine 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 durch eine andere willkürliche externe Manipulation manipuliert wurde, von Microdroid als Müll betrachtet, anstatt explizit als I/O-Fehler erkannt zu werden.

Android

Diese Eigenschaften werden von Android als Host verwaltet, gelten jedoch nicht im Falle einer Hostmanipulation:

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

  • Nur die VirtualizationService in der Host-pVM kann einen Kommunikationskanal zu einer pVM machen.

  • 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 eine laufende pVM beispielsweise 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 schädlicher Host kann jedoch entscheiden, keinen Gast zu planen.

In ähnlicher Weise delegiert pKVM auch die Verarbeitung physischer Unterbrechungen an den Hostkernel, um die Komplexität des Hypervisors zu reduzieren und die Planung vom Host 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 freigeben 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. Der erste Start einer Instanz wird bereitgestellt, indem nach dem Zufallsprinzip ein Secret-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 für jede Ladephase ein Attestierungsschlüsselpaar bereit, dessen öffentlicher Teil im DICE-Zertifikat für diese Phase zertifiziert ist. Dieses Schlüsselpaar kann sich zwischen Starts ändern, sodass auch ein Sealing-Secret abgeleitet wird, das für die VM-Instanz auch nach einem Neustart stabil bleibt und sich aus diesem Grund zum Schutz des nichtflüchtigen Zustands eignet. Das Siegel-Secret ist für die VM sehr wertvoll und sollte daher nicht direkt verwendet werden. Stattdessen sollten Versiegelungsschlüssel aus dem Versiegelungs-Secret abgeleitet und das Versiegelungsgeheimnis so früh wie möglich gelöscht werden.

Jede Phase übergibt der nächsten Phase ein deterministisch codiertes CBOR-Objekt. Dieses Objekt enthält Secrets und die DICE-Zertifikatskette, 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 auf einer pVM privat sind, werden auch 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 gilt pKVM auf einem entsperrten Gerät nicht als vertrauenswürdig, um das Sicherheitsmodell aufrechtzuerhalten.

Externe Parteien können diesen potenziell unsicheren Zustand beobachten, indem sie den bestätigten Boot-Status des Geräts in einem Schlüsselattestierungszertifikat prüfen.