我发现：https ://www.youtube.com/watch?v=0-ISmJNxGiY

观看 11:00-15:30 似乎我对内部 Web 服务器的理论非常接近它的设计方式。

所以这证实了它确实是可能的。这是巨大的：只要我们信任 CPU，我们将能够在不受信任的硬件上运行。所以这个答案确实已经过时了：如何防止托管公司访问虚拟机的加密密钥？答案并不完全错误，因为专门的攻击者可以打开 AMD CPU 并在 CPU 内部连接电线，但这会使攻击变得更加困难——尤其是如果 AMD 主动使 CPU 防篡改。

但由于谷歌似乎没有在 15:00 提供幻灯片中的信息（即我没有得到 PDH，也没有直接与 CPU 对话），谷歌似乎仍然控制着服务器：他们有一个 (毫不掩饰）中间人，即他们的控制面板，这可能是关于您的 VM 是在 AMD CPU 上生成的。

这使我得出结论，谷歌机密计算虚拟机可能很好地防范了来自同一服务器上运行的其他虚拟机的攻击（如https://rambleed.com/），但它们目前还没有防范谷歌的攻击。

但是，如果 Google 允许我访问 PDH，这可能会改变。

借助 AMD 安全处理器的证书，我可以使用 Diffie-Hellmann（芯片背书密钥https://youtu.be/0-ISmJNxGiY?t=728和平台 Diffie-Hellmann https）设置到这个独特 CPU 的安全通道://youtu.be/0-ISmJNxGiY?t=660 ) - 非常类似于 https，您还可以通过遵循其信任链来检查证书是否来自正确的网站。

因此，在使用 https 时，CPU 外部的硬件将类似于互联网：您不需要信任硬件（就像您不需要信任互联网一样），因为它只看到加密数据。

换一种说法：使用普通计算机，我们可以毫无问题地将它们连接到我们认为不可信的互联网：我们使用加密，因此任何人监视进出计算机的数据只会看到加密的数据。我们仍然可以检查我们是否正在使用数字证书与正确的收件人进行通信。

AMD SEV 只是在 CPU 内部移动了这个限制：进出 CPU 的所有内容都将被加密。云客户可以使用数字证书检查他是否正在与独特的 AMD 安全处理器通话。

虚拟机管理程序（这是在机器上启动的第一个操作系统，用于提供对 AMD 安全处理器的 Internet 访问）不必被信任。虚拟机管理程序与虚拟机隔离：虚拟机管理程序可以读取和写入加密内存，但不能读取和写入此加密的密钥（https://youtu.be/0-ISmJNxGiY?t=86）。有点像 VPN：你可以让一个不受信任的连接在其上携带一个受信任的连接。

虚拟机管理程序可以控制虚拟机，但不能为虚拟机设置加密密钥。有点像 ISP，它可以限制您的 Internet 连接而无法解密您的 VPN。

受信任的虚拟机首先具有未加密、不受信任的 BIOS ( https://youtu.be/0-ISmJNxGiY?t=563 )。然后这个 BIOS 由受信任的 CPU 进行散列和加密，并将散列提供给客户。通过这种方式，客户将知道 VM 的 BIOS 是否已更改。如果客户接受哈希正确，他将注入一个秘密（例如加密磁盘映像或打开存储在不受信任存储上的加密磁盘映像的密钥）（https://youtu.be/0-ISmJNxGiY?t= 639），然后VM在加密的RAM中启动。

总结 https 和 AMD SEV 的相似之处：

我会推荐中央情报局在朝鲜的机密云中进行机密数据处理（假设他们有）吗？

否：AMD 的 SEV 使攻击者更难。攻击者不能简单地拍摄快照并使用它。然而，他仍然可以破坏内存，如果他愿意打开 CPU，他也许可以通过连接电线来绕过一些安全措施。但是这些攻击对于普通的云托管提供商来说是遥不可及的。

因此，它不能防止真正专门的恶意托管服务提供商，但它似乎确实可以防止草率的托管服务提供商，他们没有主要资源来攻击客户的数据。

TL;DR：不，这是不可能的。他们拥有为您工作的计算机。他们本可以修改它。他们控制网络访问。他们可以读取您的 TLS 通信，因为他们是收件人。

编辑：OP想要关于未来计算技术的信息，以及这是否会在以后成为现实。这根本不可行。在某些时候，您需要相信某人不会因为您的数据无法访问而撒谎。无论是 CPU 制造商、托管服务提供商还是您的 ISP，您都必须假设他们正在为您提供一台机器的密钥，该机器按照他们所说的去做。你不能保证，除非实际获得一台然后使用那台特定的机器。即使这样，您也需要与假设的攻击者一样多的设备和知识，因为他们至少可以像您找到它一样隐藏它。到那时，你的测试机器可能无论如何都无法在发现中幸存下来，所以你需要一台新的......

从链接的 AMD 站点，密钥是在硬件中生成的……如果它在 BIOS 中启用。否则，操作系统至少会参与该过程，甚至可能创建该密钥（在此期间它很容易受到攻击）并与内存控制器对话以直接加密数据。

然而，在虚拟化的情况下，管理程序（和操作系统）与内存控制器及其密钥集合交互。我不确定这一点，但听起来它确实被配置为虚拟机管理程序实际上无法看到密钥，只是说要使用哪些密钥（并且它们是在 CPU 寄存器中生成的，不能与 VM 映像）。

这听起来很棒，但我会相信吗？也许更多一点，但它仍然不一定安全。密钥不存储在 RAM 中，操作系统或 Google 可能无法访问，但你怎么知道他们实际上正在使用系统？系统中几乎必须存在漏洞（它是新的和复杂的），或者谷歌可能执行了某种硬件模块（它们物理上持有机器，你看不到它们）。也许甚至可以像使用Intel 的 ME 引擎一样物理地停止它，所以它认为它正在运行但实际上什么都不做，或者设置一个中间人 (MITM)，使用另一个 CPU 来获得正确的响应和你的请求在常规 VM 上运行。

就像你在这项技术之前所做的那样，你必须真正相信谷歌“不作恶”。如果您这么担心，也许您还应该想知道 AMD 是否有办法“以防万一”提取这些密钥，而且您需要关注的不仅仅是（或唯一）谷歌。还记得我提到的 Intel ME 吗？它是您计算机所有硬件的永远开启的后门。AMD 也有一个，而且它在你的系统中有更多的卷须，而且更难禁用。几乎可以肯定能够与那个加密的内存控制器对话。Google 可以访问 BIOS ROM，该 ROM 运行执行加密的软件，就此而言，只需拥有机器即可。

最后，它们控制对 VM 的网络访问。他们可以尝试攻击您发送或下载的软件和命令。他们可以 MITM 您的加密连接（他们拥有您用来安全连接的证书）。他们可能能够使用在“安全”虚拟机上运行的操作系统中未修补的错误。如果您的应用程序在 Windows XP 上的 Flash 中运行，为什么还要费心使用硬件攻击（我真的希望不是，但这只是一个例子）？

你提到的规则仍然适用，即使你有一台更高级的电脑。Google 拥有对该机器的完全访问权限。你用它做什么都没关系。没有办法保证这种情况的安全，尤其是面对一个像谷歌一样拥有大量知识、硬件和金钱的假想对手。