Kann Google auf Daten in seinen Confidential Computing-VMs zugreifen?
Ein Cloud-Betreiber wie Google kann einen Schnappschuss einer normalen VM erstellen. Dies umfasst CPU-Status, RAM und Festplatte. Dies kann dann auf ein anderes physisches kopiert und dort fortgesetzt werden. Oder es kann offline analysiert werden, und alle Kryptokeys im Speicher oder im CPU-Status können extrahiert werden.
Dies bedeutet, dass Sie keine vertraulichen Daten auf diesen VMs verarbeiten sollten, wenn Sie Ihrem Cloud-VM-Anbieter nicht vertrauen (möglicherweise gehört Ihr Cloud-VM-Anbieter Ihrem schlechtesten Konkurrenten).
https://cloud.google.com/confidential-computing scheint AMDs Secure Encrypted Virtualization zu verwenden, die Hardware-RAM-Verschlüsselung enthält: https://developer.amd.com/sev/
Wenn der RAM verschlüsselt ist, wird es schwieriger, Angriffe wie zu verwenden https://rambleed.com/
Aber schützt es auch vor Google?
Es scheint, dass der RAM mit einem Schlüssel verschlüsselt ist, der in der CPU lebt. Aber ist dieser Schlüssel enthalten, wenn Google eine Momentaufnahme des CPU-Status der VM erstellt?
Theoretisch konnte ich sehen, dass es so funktioniert: Die CPU hat einen kleinen Webserver mit einem von AMD signierten TLS-Zertifikat. Ich greife auf den Webserver zu, überprüfe das AMD-Zertifikat und habe jetzt eine sichere Verbindung zur CPU, auf die Google nicht zugreifen kann.
Dann gebe ich der CPU einen geheimen Schlüssel zum Verschlüsseln des RAM. Dann gebe ich ihm ein Disk-Image, das mit demselben Schlüssel verschlüsselt ist. Dann starte ich die VM.
Wenn der geheime Schlüssel die CPU physisch nicht verlassen kann, sollte es Google unmöglich sein, auf meine Daten zuzugreifen: Der RAM wird verschlüsselt, Daten auf der Festplatte und im Netzwerk werden verschlüsselt. Ich muss also weder dem RAM, dem Speicher noch dem Netzwerk vertrauen. Dies bedeutet jedoch auch, dass Google meine VM nicht als Snapshot erstellen und auf einer anderen CPU wiederherstellen kann.
Dies würde auch bedeuten, dass diese Antwort veraltet ist: https://security.stackexchange.com/a/215927/84564
Derzeit sehe ich keine Möglichkeit, etwas Ähnliches wie die Überprüfung des AMD-Zertifikats in der aktuellen Lösung von Google zu tun. Daher sehe ich keine Möglichkeit, einen Schlüssel, auf den Google keinen Zugriff hat, sicher festzulegen.
Kann Google einen Schnappschuss einer laufenden vertraulichen Computer-VM erstellen und wiederherstellen?
Mit AMDs SEV kann die CIA ihre geheimsten Daten sicher in der vertraulichen Cloud Nordkoreas verarbeiten (vorausgesetzt, sie haben diese), ohne dass Nordkorea auf die Daten zugreifen kann - vorausgesetzt, AMD ist vertrauenswürdig, aber alle andere Hardware außer der CPU wird im Norden hergestellt Korea?
Antworten
Ich fand: https://www.youtube.com/watch?v=0-ISmJNxGiY
Wenn ich mir 11: 00-15: 30 anschaue, scheint meine Theorie mit dem internen Webserver ziemlich nahe an der Gestaltung zu liegen.
Dies bestätigt also, dass es tatsächlich möglich ist. Das ist RIESIG : Mit der Zeit können wir auf nicht vertrauenswürdiger Hardware laufen, solange wir der CPU vertrauen. Diese Antwort ist in der Tat veraltet: Wie kann verhindert werden, dass ein Hosting-Unternehmen auf die Verschlüsselungsschlüssel einer VM zugreift? Die Antwort ist nicht ganz falsch, da ein dedizierter Angreifer die AMD-CPU öffnen und Kabel in der CPU anschließen könnte, dies würde den Angriff jedoch erheblich erschweren - insbesondere, wenn AMD die CPU aktiv manipulationssicher macht.
Da Google jedoch die Informationen von der Folie um 15:00 Uhr nicht bereitzustellen scheint (dh ich erhalte den PDH nicht und kann nicht direkt mit der CPU sprechen), scheint Google immer noch die Kontrolle über den Server zu haben: Sie haben einen ( unverstellt) Man-in-the-Middle, nämlich das Control Panel, das möglicherweise darüber lügt, dass Ihre VM auf einer AMD-CPU erzeugt wird.
Dies führt mich zu dem Schluss, dass Google Confidential Computing-VMs wahrscheinlich gut vor Angriffen anderer VMs geschützt sind, die auf demselben Server ausgeführt werden (z https://rambleed.com/), aber sie sind derzeit nicht gegen einen Angriff von Google geschützt.
Wenn Google mir jedoch Zugriff auf die PDH gewährt, kann sich dies ändern.
Mit dem Zertifikat des AMD Secure Processor kann ich mit Diffie-Hellmann (dem Chip-Endorsement-Schlüssel) einen sicheren Kanal zu dieser einzigartigen CPU einrichten https://youtu.be/0-ISmJNxGiY?t=728 und die Plattform Diffie-Hellmann https://youtu.be/0-ISmJNxGiY?t=660) - Ähnlich wie bei https, wo Sie auch überprüfen können, ob das Zertifikat von der richtigen Website stammt, indem Sie der Vertrauenskette folgen.
Die Hardware außerhalb der CPU ähnelt daher dem Internet, wenn https gesprochen wird: Sie müssen der Hardware nicht vertrauen (genau wie Sie dem Internet nicht vertrauen müssen), da nur verschlüsselte Daten angezeigt werden.
Anders gesagt: Bei normalen Computern haben wir kein Problem damit, sie mit dem Internet zu verbinden, was wir nicht für vertrauenswürdig halten: Wir verwenden Verschlüsselung, sodass jeder, der die Daten ausspioniert, die in den Computer ein- und aus dem Computer austreten, nur verschlüsselte Daten sieht. Wir können weiterhin mithilfe digitaler Zertifikate überprüfen, ob wir mit dem richtigen Empfänger kommunizieren.
AMD SEV verschiebt nur diese Grenze innerhalb der CPU: Alles, was in die CPU hinein und aus ihr heraus geht, wird verschlüsselt. Ein Cloud-Kunde kann mithilfe der digitalen Zertifikate überprüfen, ob er mit dem einzigartigen AMD Secure Processor spricht.
Der Hypervisor (das erste Betriebssystem, das auf dem Computer gestartet wird und das zum Bereitstellen des Internetzugangs für den AMD Secure Processor verwendet wird) muss nicht vertrauenswürdig sein. Der Hypervisor ist von der VM isoliert: Der Hypervisor kann den verschlüsselten Speicher lesen und schreiben, jedoch nicht den Schlüssel für diese Verschlüsselung (https://youtu.be/0-ISmJNxGiY?t=86). Ein bisschen wie VPN: Sie können eine nicht vertrauenswürdige Verbindung haben, die eine vertrauenswürdige Verbindung darüber trägt.
Der Hypervisor kann VMs steuern, aber den Verschlüsselungsschlüssel für die VM nicht festlegen. Ein bisschen wie ein ISP, der Ihre Internetverbindung drosseln kann, ohne Ihr VPN entschlüsseln zu können.
Die vertrauenswürdige VM verfügt zunächst über ein unverschlüsseltes, nicht vertrauenswürdiges BIOS (https://youtu.be/0-ISmJNxGiY?t=563). Dieses BIOS wird dann von der vertrauenswürdigen CPU gehasht und verschlüsselt, und der Hash wird dem Kunden übergeben. Auf diese Weise weiß der Kunde, ob das BIOS für die VM geändert wurde. Wenn der Kunde den Hash als korrekt akzeptiert, injiziert er ein Geheimnis (z. B. ein verschlüsseltes Disk-Image oder einen Schlüssel zum Öffnen eines verschlüsselten Disk-Images, das auf einem nicht vertrauenswürdigen Speicher gespeichert ist) (https://youtu.be/0-ISmJNxGiY?t=639), und dann startet die VM im verschlüsselten RAM.
Fassen Sie die Ähnlichkeiten zwischen https und AMD SEV zusammen:
| Feature | HTTPS-SERVER | AMD SEV |
|---|---|---|
| Nicht vertrauenswürdige Funktionen | ||
| Schnelle Lagerung | Vollständig festplattenverschlüsselte SSD | Verschlüsselter RAM |
| Langsame Lagerung | Verschlüsselte Remote-Sicherung | Vollständig festplattenverschlüsselte SSD |
| Steuerkanal ("Netzwerkverkehr") | https verschlüsselt | Diffie Hellman verschlüsselt |
| Vertrauenswürdige Funktionen | Der ganze Server | AMD Secure Processor |
| Zertifikat | TLS-Zertifikat für https | Zertifikat für sicheren Prozessor |
| Zertifizierungsstelle | zB Thawte | AMD |
| Schlüssel für schnelle Lagerung | vollständiger Festplattenverschlüsselungsschlüssel | RAM-Verschlüsselungsschlüssel |
| Schlüssel für langsame Lagerung | Sicherungsverschlüsselungsschlüssel | vollständiger Festplattenverschlüsselungsschlüssel |
| Schlüsselspeicher | kleine Bootdiskette | sicherer verschlüsselter NV-Speicher |
Würde ich der CIA empfehlen, ihre vertraulichen Daten in der vertraulichen Cloud Nordkoreas zu verarbeiten (vorausgesetzt, sie haben eine)?
Nein: AMDs SEV macht es einem Angreifer viel schwerer. Ein Angreifer kann nicht einfach einen Schnappschuss machen und diesen verwenden. Er kann jedoch immer noch den Speicher beschädigen, und wenn er bereit ist, die CPU zu öffnen, kann er möglicherweise einige Sicherheitsvorkehrungen umgehen, indem er Kabel anbringt. Diese Angriffe sind jedoch für einen normalen Cloud-Hosting-Anbieter unerreichbar.
So ist es schützt nicht vor einer wirklich engagierten bösen Hosting - Anbieter, aber es ist offenbar gegen einen schlampig Hosting - Provider zu schützen, die keine großen Ressourcen hat die Daten des Kunden für den Angriff.
TL; DR: Nein, es ist unmöglich zu sichern. Sie besitzen den Computer, der Ihre Arbeit erledigt. Sie hätten es modifizieren können. Sie steuern den Netzwerkzugriff. Sie können Ihre TLS-Kommunikation lesen, weil sie der Empfänger sind.
Bearbeiten: Das OP wollte Informationen über zukünftige Computertechnologien und ob dies später zutreffen könnte. Es ist einfach nicht machbar. Irgendwann müssten Sie jemandem vertrauen, dass er nicht lügt, dass Ihre Daten für ihn unzugänglich sind. Unabhängig davon, ob dies der CPU-Hersteller, der Hosting-Anbieter oder Ihr ISP ist, müssen Sie davon ausgehen, dass er Ihnen einen Schlüssel für einen Computer gibt, der das tut, was er sagt. Sie können dies nicht garantieren, wenn Sie nicht tatsächlich eine erhalten und dann diese bestimmte Maschine verwenden. Selbst dann würden Sie so viel Ausrüstung und Wissen benötigen wie der hypothetische Angreifer, weil er es mindestens so gut verstecken kann, wie Sie es finden können. Und zu diesem Zeitpunkt würde Ihre Testmaschine die Entdeckung wahrscheinlich sowieso nicht überleben, sodass Sie eine neue benötigen würden ...
Von der verknüpften AMD-Site wird der Schlüssel in Hardware generiert ... sofern er im BIOS aktiviert ist. Andernfalls ist das Betriebssystem mindestens in den Prozess involviert und erstellt möglicherweise sogar diesen Schlüssel (während dieser Zeit ist er anfällig) und spricht mit dem Speichercontroller, um die Daten direkt zu verschlüsseln.
Bei der Virtualisierung interagieren der Hypervisor (und das Betriebssystem) jedoch mit dem Speichercontroller und seiner Schlüsselsammlung. Ich bin mir nicht sicher, aber es hört sich so an, als ob es so konfiguriert wurde, dass der Hypervisor die Schlüssel nicht sehen kann. Sagen Sie lediglich, welche verwendet werden sollen (und sie werden in einem CPU-Register generiert, das nicht sein kann mit der VM abgebildet).
Das klingt großartig, aber würde ich ihm vertrauen? Vielleicht ein bisschen mehr, aber es ist immer noch nicht unbedingt sicher. Der Schlüssel ist nicht im RAM gespeichert und nicht an das O oder Google zugänglich sein, aber wie Sie wissen, dass sie tatsächlich mit dem System überhaupt? Es muss fast Schwachstellen im System geben (es ist neu und komplex), oder Google hat Hardware-Mods durchgeführt (sie halten die Maschinen physisch und man kann sie nicht sehen). Vielleicht ist es sogar möglich, es physisch anzuhalten, wie mit Intels ME-Engine , so dass es denkt, dass es läuft, aber wirklich nichts tut, oder ein Man-in-the-Middle (MITM) einzurichten, bei dem eine andere CPU verwendet wird, um die richtigen Antworten und Ihre zu erhalten Die Anforderung wird auf einer regulären VM ausgeführt.
Genau wie vor dieser Technologie müssen Sie Google tatsächlich vertrauen, dass es "nicht böse" ist. Wenn Sie so besorgt sind, sollten Sie sich vielleicht auch fragen, ob AMD eine Möglichkeit hat, diese Schlüssel "nur für den Fall" zu extrahieren, und es ist nicht nur (oder nur) Google, um das Sie sich Sorgen machen müssen. Erinnerst du dich an das Intel ME, was ich erwähnt habe? Es ist eine ständige Tür in die gesamte Hardware Ihres Computers. AMD hat auch eine, und es hat noch mehr Ranken in Ihrem System und ist schwerer zu deaktivieren. Es ist fast sicher, mit diesem verschlüsselten Speichercontroller sprechen zu können. Google hat Zugriff auf das BIOS-ROM, in dem die Software ausgeführt wird, die die Verschlüsselung durch einfaches Besitzen des Computers durchführt.
Und schließlich steuern sie den Netzwerkzugriff auf die VM . Sie können versuchen, die Software und Befehle anzugreifen, die Sie senden oder die sie herunterladen. Sie können Ihre verschlüsselte Verbindung MITM (sie besitzen das Zertifikat, mit dem Sie eine sichere Verbindung herstellen). Sie können möglicherweise nicht gepatchte Fehler in dem Betriebssystem verwenden, das auf dieser "sicheren" VM ausgeführt wird. Warum sollten Sie sich die Mühe machen, einen Hardwareangriff zu verwenden, wenn Ihre App unter Windows XP in Flash ausgeführt wird (ich hoffe wirklich nicht, aber das ist ein Beispiel)?
Die von Ihnen erwähnte Regel gilt auch dann, wenn Sie einen schickeren Computer haben. Google hat vollen Zugriff auf diesen Computer. Es spielt keine Rolle, was Sie damit machen; Es gibt keine Möglichkeit, ein solches Szenario zu schützen, insbesondere nicht gegen einen hypothetischen Gegner mit so viel Wissen, Hardware und Geld wie Google.