如果您在某人的服务器上运行软件，则会出现问题。你不能确定你的数据和代码没有被观察到，或者更糟的是，你想确认你自身没有被篡改信任是你唯一的保证。
但是，有希望，以可信执行环境（TEE）和TEEOS的形式，将利用TEE来最大限度地减少您在他人硬件上自信运行所需的信任。
本文深入探讨了这个问题，TEE的工作方式及其局限性，提供了TEE入门，并解释了Enarx类似的TEEOS如何解决这些面临原谅的局限性。
可信执行环境解决的问题
未接触TEE之前我们知道有个管理员模式，特权模式。运行软件的一个实质性现实是，同一台计算机上计算堆栈的任何较低层都可以控制和检查运行软件。这适用于操作系统、虚拟机管理器（VMM或虚拟机管理程序）、容器管理堆栈（如果有）和任何其他中间件等层。
因此，任何对计算机具有（合法或未经授权的）root访问权限的人都可以看到、修改、终止和以其他方式操作计算机上运行的任何代码和数据。
对于任何在别人的机器上运行程序的人来说，在安全和隐私方面，这几乎是你所能做到的。
在云环境中，托管数千个虚拟机的数千台物理机器的控制和保护都委托给了服务提供商，一些组织认为缺乏基本的安全和隐私保障是有问题的。
对于任何在别人的机器上运行程序的人来说，在安全和隐私方面，呵呵不值一提，安全啥呢？底裤都被看到是什么颜色了。
受信任的执行环境（TEE）是对“在使用中”（即在运行时（程序执行））保持数据机密性和完整性的需求的回应，无论谁可能拥有或有权访问运行软件的机器。
TEE带来了什么我们以前做不到的？
【可信执行环境（TEE）】是解决其中一些问题的一种相当新的技术方法。
它们允许您在一组内存页中运行应用程序，这些页由主机CPU加密，即使主机系统的所有者也无法窥视或修改TEE实例中正在运行的进程。
所有TEE都为在其中运行的代码和数据提供机密性保证，这意味着从TEE外部无法看到正在运行的工作负载。
隔离、偷窥、看不到
TEE也会提供内存完整性保护（【4】,【5】），这可以防止加载到TEE中的数据从外部被修改（我们将在下面回到这个问题）。
但是TEE不是解决了所有问题。
因为较低的堆栈级别仍然必须能够控制调度和TEE启动，并可以阻止系统调用。
还有各种攻击（包括但不限于 replay, TOCTOU, and Foreshadow）已经成功地针对以前或当前的TEE实现(【3】, 【7】)。
- replay：https://en.wikipedia.org/wiki/Replay_attack
- TOCTOU：https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
- Foreshadow：https://foreshadowattack.eu/
然而，TEE提供了运行操作系统、VMM或中间件不可见的用户空间应用程序的新功能。它们有可能在以前不可用的环境（如云）中为敏感工作负载启用安全和隐私功能。
所以安全这个领域，没有说有什么技术能一劳永逸，只能说不断的增大攻击者的难度。让设备变得更加的安全！
TEE和TPM、HSM之间的区别
用于专门加密目的的其他硬件类别已经存在，特别是可信平台模块（TPM）和硬件安全模块(HSM)。然而，TEE的目的与这些其他类别的加密硬件完全不同。
TPM是一种设计用于通过持有秘密（密钥）来提供“硬件信任根”的芯片，这种方式使得物理地试图打开它或将它从焊接它的计算机主板上移除以访问它的秘密是困难的，并且是显而易见的。
TPM不是为了提供一般的计算能力而设计的。它们确实提供了一些基本的（读作：“slow”）计算能力：它们可以生成随机密钥，用它们持有的秘密加密少量数据，还可以测量系统的组件，并在平台配置寄存器（PCR）中维护这些测量的日志。
您可以在TEE中实现TPM的许多功能，但在TEE内创建“完整”TPM实现是没有意义的：TPM的关键用例之一是使用PCR测量引导序列，而TEE提供了一个通用处理环境。
与TPM不同，TEE并不能成为信任的良好物理基础。TPM的功能也经过了仔细的界定，以满足TCG（可信计算集团，TPM的标准机构）的要求，这比TEE的要求更具限制性。
另一方面，硬件安全模块（HSM）是一种专门提供加密操作的外部物理设备，通常接收明文，用其持有的密钥对其进行加密，并返回密文（加密文本），这样操作系统就不会处理加密密钥。
与TPM一样，它们的设计目的是挫败、检测和/或进行明显的物理篡改，这使它们成为将秘密保存在安全地方的有用工具。它们通常提供比TEE更高级别的保护，但是主CPU和主板的独立模块，可通过PCI总线、网络或类似方式访问。
所有TEE实例和一些HSM（取决于型号）都可以用作通用功能处理单元，或为特定用途编程（例如PKCS#11模块）。与TEE相比，HSM的成本很高（通常为数千美元），而TEE是正常价格芯片组的组成部分。为特定任务编程HSM的工作（超出模块化使用）通常是非常困难和高技能的。
总结这三点，可以说：
- TEE提供了一个通用的处理环境。它们内置在芯片组中。
- TPM提供了信任的物理根源、其他组件的测量和引导序列，并且处理能力有限。它们是许多计算机内置的廉价芯片。
- HSM提供了一个安全的环境来存储机密、处理数据，并可以提供一个通用的处理环境。它们是昂贵的外部设备，通常需要专业知识才能正确使用。
| Device | Processing capabilities | Complexity | Cost |
| TEE | general | high | none (built-in) |
| TPM | limited | average | very low |
| HSM | general | very high | high |
最后，我们应该提到早期的TEE方法，这些方法并不完全符合我们对TEE的定义。
例如，最近的iPhone有一个“Secure Enclave”，一个与主CPU一起运行的完全独立的CPU，而使用ARM芯片的安卓手机包括一个名为TrustZone的系统。
TEE必须提供一个可信的环境，在这个环境中可以从普通操作系统加载软件，但这些早期的模型依赖于与普通操作系统并行运行的第二个操作环境。
这种方法提供了我们想要从TEE中获得的一些功能，但也带来了一些问题和限制，例如限制了普通用户在可信环境中从userland运行软件的能力。
TEE的不同类型
虽然对其目标达成了一些共识，但TEE的架构和实现有多种方法。
不同的方法，但没有标准
如前所述，TEE通过用硬件中保存的密钥（一个或多个密钥）加密一系列存储器来为用户空间软件提供机密性，该密钥对操作系统或任何其他软件都不可用，即使运行在最高特权级别。
然而，除此之外，目前还没有业界对创建TEE的最安全或最有效的方法达成共识，各种硬件制造商已经创建了根本不同的实现方式。
这些实现中的每一个共享的是依赖CPU来创建和强制访问TEE，以及最终用户指定哪些进程应该在加密的内存区域中运行的能力。
从这里开始，该行业目前分为两种不同的TEE模型：基于过程的模型（例如英特尔的SGX（9））和基于虚拟机的模型（如AMD的SEV（10））。值得注意的是，CPU必须专门设计为支持TEE，并提供附带的固件，2019年的大多数CPU都不支持任何类型的TEE。
基于过程的TEE
在基于流程的TEE模型中，需要安全运行的流程分为两个部分：可信（假定为安全）和不可信（假定不安全）。
- 可信组件驻留在加密内存中并处理机密计算，
- 而不可信组件与操作系统接口并将I/O从加密内存传播到系统的其余部分。
数据只能通过预定义的通道进出这个加密区域，并严格检查通过的数据的大小和类型。理想情况下，所有进入或离开加密存储区域的数据也在传输过程中被加密，并且只有在数据到达TEE时才被解密，此时它仅对运行在TEE中的软件可见。
与基于VM的模型相比，该模型的优点包括更小的可信计算库（TCB），因为只有CPU和特定进程的组件是可信的（1）。较小的TCB通常意味着更少的出错空间，因为可信工作中涉及的组件更少。
这也允许对TEE的所有输入和输出进行监控，可以说提高了安全性。此外，目前的实现，如英特尔的SGX，提供内存完整性保护。
该模型的一个经常被提及的缺点是缺乏双向隔离：虽然TEE的进程享有来自其他进程和较低堆栈层的硬件保护，但情况并非如此。
TEE中没有硬件保护，无法阻止软件访问或干扰其他进程或操作系统，而这些进程或系统仅受标准访问权限的保护。
这种片面的保护引起了人们对滥用TEE来容纳恶意软件的严重担忧：由于这些硬件保护，操作系统会发现更难根除TEE中的恶意软件。
**另一个主要缺点是需要专门为这种类型的TEE开发应用程序，**例如为英特尔的SGX SDK开发软件，将程序划分为可信和不可信组件。
尽管在使用VM边界进行过程隔离方面有多年的学术研究和实践经验，但对于基于过程的模型来说，情况却并非如此。对于这是优点还是缺点，存在一些争论，因为破坏传统的分级信任模型和强加新的安全边界会产生不确定性。
目前基于过程的方法的实现包括英特尔的SGX（软件保护扩展）。目前已知的另一种基于流程的TEE是OpenPOWER的Sanctum，在撰写本文时尚未进入市场。
基于VM的TEE
在这个模型中，内存是沿着在VMM之上运行的传统VM边界加密的。
虽然传统的VMs (as well as containers)提供了一定程度的隔离，但该TEE模型中的虚拟机受到基于硬件的加密密钥的保护，这些密钥可以防止恶意VMM的干扰（2）。
当前的实现方式，如AMD的SEV，为每个虚拟机提供单独的短暂加密密钥，因此也保护虚拟机免受彼此的攻击。
该模型的一个显著优点是，它可以在VM和系统之间提供双向隔离，因此不太担心这种类型的TEE包含能够干扰系统其余部分的恶意软件。
AMD对该模型的实现也没有对软件开发提出要求，这意味着开发人员不需要编写特定的API就可以在这种类型的TEE中运行代码。
然而，由于运行软件的VMM必须写入自定义API（8），因此后一个优点被掩盖了。
该模型的几个缺点包括相对较大的TCB，其中包括在VM（1）内部运行的操作系统，这在理论上增加了攻击面。当前的实现方式，如AMD的SEV，允许VMM控制到可信VM（3）的数据输入，这意味着主机仍然可以潜在地改变被认为是安全的工作负载。它还需要在虚拟机中进行内核和硬件仿真，并且相对较重，尤其是对于微服务。
AMD的SEV是该模型开发最全面的实现，尽管也有其他实现，如英特尔的MKTME（Multi-Key Total Memory Encryption，12）。第三个实现是IBM的Protected Execution Facility或“PEF”，它将是开源的（6）。
另外
已经对其他硬件平台上的TEE进行了一些讨论，包括例如MIPS体系结构。
目前的方法高度依赖于特定的技术
正如我们所看到的，可信执行环境有两个广泛的模型。但除此之外，如何真正让代码在其中运行？
这里的情况一点也不简单。
编写TEE应用
鉴于目前缺乏TEE的标准化，TEE的两种不同实现不一定能提供相同的安全性或性能结果。
更糟糕的是，需要在TEE（或应用程序的自定义VMM）中运行的应用程序必须专门针对这些硬件技术中的每一种进行开发。
这对开发来说是不方便的，可能导致软件版本之间缺乏兼容性（那些能够利用TEE的版本与不能够利用的版本），并且在TEE实现高度变化的时候，很难在TEE的实现之间移动。
例如，为英特尔SGX开发应用程序需要定义TEE的所有输入和输出通道，以及可信和不可信组件。
然而，对于在没有TEE功能的CPU上运行的应用程序版本来说，这些定义是毫无意义的，因此TEE兼容和非TEE兼容版本的软件需要分开。最近，对于想要为一些TEE实现编写代码的开发人员来说，已经做出了努力来减少摩擦，最著名的是Open Enclave项目。
开发人员为当前提供的TEE技术编写应用程序所需的努力很可能会再次重复，以利用未来可能提供更好安全或性能优势的TEE。
证明
将软件部署到TEE的一个关键方面是“受信任”部分：确保您确实部署到一个实际的受信任执行环境，而不是伪装成一个环境。本质上，TEE需要证明它是真实的，然后才能被信任：这个过程被称为证明。
只有在真正具有TEE功能的CPU上运行的真正TEE才能创建有效的证明，理想情况下，这应该很容易从验证器端进行检查。云计算示例中的验证器是希望使用云环境在自己不拥有的机器上运行机密工作负载的个人或组织。
尽管证明对于使用TEE的任何安全功能都至关重要，但目前还没有关于证明的标准，创建和实施证明方法的负担落在了开发和部署应用程序的人身上。这使得在实践中使用TEE变得相当困难，并阻止了它们的广泛采用。
尽管两种TEE模型目前都依赖制造商的证书链来证明CPU是真实的，并在发布后报告TEE的测量结果（允许验证TEE的内容），但它们在证书链必须验证的密钥的种类和数量以及认证过程的操作顺序上有所不同。
开发API和证明过程都缺乏标准化，这意味着一旦为与特定平台相关的TEE实现编写了代码，软件的开发人员和用户就会被锁定。
重写软件或运行它的自定义VMM，或者必须为具有不同TEE实现的不同平台重新创建证明验证过程将需要大量的时间投资。这一原则也对云平台的用户以及云服务提供商（CSP）本身产生了负面影响，因为用户无法轻松利用CSP提供的新TEE，他们的软件与不同的物理实现绑定。
结论
人们越来越意识到在休息时（使用全磁盘加密）或传输中（TLS和HTTPS）加密数据的重要性，但我们最近才开发出在运行时加密数据的技术能力。
可信执行环境在保密性方面是一个令人兴奋的进步。在运行时加密数据的能力为软件的开发人员和用户提供了以前不可用的安全和隐私功能。
尽管这对安全来说是一个激动人心的时刻，但目前在这项新技术的标准化方面存在一些巨大的差距。
https://next.redhat.com/2019/12/02/current-trusted-execution-environment-landscape/
