简介
在软件和服务通过互联网部署的时代，英特尔 SGX 和英特尔构架扩展使得服务提供商能够通过有线或无线方式为应用程序提供敏感内容，并自信地认为他们的秘密得到妥善保护。为此，服务提供商必须能够确定地知道远程平台上正在运行什么软件以及它在哪个环境中执行。
软件周期
支持英特尔 SGX 的软件不附带敏感数据。安装软件后，它会联系服务提供商以将数据远程提供给 enclave。然后，该软件会加密数据并将其存储以备将来使用。如下图：
- enclave 启动 —— 不受信任的应用程序启动 enclave 环境以保护服务提供商的软件。在构建 enclave 后，会记录一个安全日志，反映 enclave 的内容及其加载方式，该安全日志称为 enclave 的“度量”。
- attestation —— enclave 联系服务提供商以将其敏感数据提供给 enclave，此时平台产生一个安全断言，用于识别硬件环境和 enclave。
- provisioning —— 服务提供商评估 enclave 的可信度，它使用 attestation 来建立安全通信并向 enclave 提供敏感数据，使用安全通道，服务提供商将数据发送到 enclave 。
- sealing/unsealing —— enclave 使用持久的基于硬件的加密密钥来安全地加密和存储其敏感数据，以确保只有在受信任的环境恢复时才能检索数据。
- 软件升级 —— 服务提供商可能需要 enclave 软件更新。为了简化数据从旧软件版本到新版本的迁移，软件可以请求旧版本的密封密钥来解封数据并请求新版本的密封，这样密封的数据将无法用于以前版本的软件。
最后，当平台所有者计划转让平台所有权时，应将其所有权期间可用的秘密设为不可访问。英特尔 SGX 包含一个用户拥有的特殊持久值，该值在更改时会更改软件可用的所有密钥。
安全模式
希望向远程平台提供机密的服务提供商必须事先知道远程平台的保护策略满足要部署的机密的保护要求。根据英特尔 SGX 的安全模型，负责保护机密的可信计算基础 (TCB) 包括处理器的固件和硬件，以及 enclave 内的软件。enclave 编程者可以使用 Intel SGX 专用的密封和认证组件，这些组件支持以下安全模型断言，以向服务提供商证明机密将根据预期的安全级别得到保护：
- 英特尔 SGX 为 enclave 实例提供了从 enclave 身份平台请求安全断言的方法。
- 英特尔 SGX 为 enclave 实例提供了验证源自同一平台上其他 enclave 实例的断言的方法。
- 英特尔 SGX 为远程实体提供了验证来自 enclave 实例的断言的方法。
- 英特尔 SGX 允许 encalve 实例获取绑定到平台和 enclave 的密钥。
Intel SGX 指令
英特尔 SGX 架构提供硬件指令 EREPORT 和 EGETKEY，以支持证明和密封。接受 SGX 安全模型的机密所有者可以根据这些指令向负责系统安全的 TCB 报告。
为了创建 enclave 环境，不受信任的软件使用英特尔 SGX 指令，这些指令还计算已启动的环境的加密度量。
为了启用 attestation 和 sealing，硬件提供了两个额外的指令 EREPORT 和 EGETKEY。EREPORT 指令提供了一个证据结构，该结构以加密方式绑定到硬件以供 attestation 验证者使用。EGETKEY 为 enclave 软件提供了对 attestation 和 sealing 过程中使用到的 Report 密钥和 seal 密钥的访问权限。
度量
英特尔 SGX 架构负责为 attestation 和 sealing 建立身份标识符。对于每个 enclave，它提供两个度量寄存器，MRENCLAVE 和 MRSIGNER：MRENCLAVE 提供了 enclave 代码和数据的身份标识，像在构建时一样；而 MRSIGNER 提供了 enclave 的密封机构的身份标识符。
MRENCLAVE - Enclave Identity
“Enclave Identity”是 MRENCLAVE 的值，它是内部日志的 SHA-256 摘要，记录了在构建 enclave 时完成的所有活动。该日志包含以下信息：
- 页面内容（代码段、数据段、堆、栈）
- 页面在 enclave 中的相对位置
- 与页面相关联的任何安全标志
一旦 enclave 通过 EINIT 指令完成初始化，MRENCLAVE 将不会再进行更新。MRENCLAVE 的最终值是一个 SHA-256 摘要，以加密方式标识 enclave 内的代码、数据和栈、enclave 页面的放置顺序和位置以及每个页面的安全属性。对这些变量中的任何一个进行任何更改都会导致 MRENCLAVE 中的值不同。
MRSIGNER - Sealing Identity
enclave 具有用于数据保护的第二个身份，称为“Sealing Identity”。Sealing Identity 包括“密封机构”、产品 ID 和版本号。密封机构是在 enclave 发布之前对其进行签名的实体，通常是 enclave 创建者。enclave 创建者向硬件提供使用 RSA 算法签名的 enclave 证书 (SIGSTRUCT)，其中包含 enclave 身份的预期值、MRENCLAVE 和密封机构的公钥。硬件使用其中包含的公钥检查证书上的签名，然后将计算出的 MRENCLAVE 值与签名版本中的对应值进行比较。这些检查通过后，密封机构的公钥的散列值将会被存储在 MRSIGNER 寄存器中。需要注意的是，如果多个 enclave 由同一个 Sealing Authority 签名，则它们都将具有相同的 MRSIGNER 值。Sealing Identity 的值可用于密封数据，其方式是来自同一密封机构的 enclave（例如，同一 enclave 的不同版本）可以共享和迁移其密封数据。
证明
attestation 是证明某个软件在平台上已正确实例化的过程，它是第三方可以确信正确的软件在启用英特尔 SGX 技术的平台上的 enclave 内安全运行的一种机制。为此，英特尔 SGX 架构会生成一个证明断言，该断言传达以下信息：
- 将被证明的软件环境的身份
- 任何不可测量状态的详细信息（例如软件环境可能运行的模式）
- 软件环境希望与其自身相关联的数据
- 为生成断言，与平台 TCB 绑定的加密信息
英特尔 SGX 架构提供了一种机制，用于在同一平台上运行的两个 enclave 之间创建通过身份验证的断言（本地证明），以及另一种扩展本地证明以向平台外的第 3 方提供断言的机制（远程证明）。
最后，为了在系统中获得最大的可信度，认证密钥应该只绑定到特定的平台TCB。如果平台 TCB 发生变化，比如通过微码更新，平台证明密钥应该被替换，以正确代表 TCB 的可信度。
平台内 enclave 认证
应用程序开发人员可能希望编写可以相互协作以执行某些更高级别功能的 enclave。为了做到这一点，他们需要一种让 enclave 相互验证的机制。为此，英特尔 SGX 架构提供了 EREPORT 指令。
当被 enclave 调用时，EREPORT 创建一个签名结构，称为 REPORT。REPORT 结构包含 enclave 的两个身份标识符、与 enclave 关联的属性（属性标识模式和在 ECREATE 期间建立的其他属性）、硬件 TCB 的可信度以及 enclave 开发人员希望传递给目标 enclave 的附加信息，以及消息验证码 (MAC) 标签。目标 enclave 是验证 REPORT 结构 MAC 信息的 enclave，以确定创建 REPORT 的 enclave 在同一平台上运行。
这里的 MAC 使用称为“Report Key”的密钥生成，如下表所示，Report Key 仅对目标 enclave 和 EREPORT 指令已知。验证（目标）enclave 可以使用 EGETKEY 指令检索其自己的 Report Key。EGETKEY 为 enclave 提供密钥，其中包括 Report Key，可用于对称加密和身份验证。目标 enclave 使用 Report Key 重新计算 Report 数据结构上的 MAC，并验证 Report 是由证明（报告）enclave 生成的。英特尔 SGX 架构使用 AES128-CMAC 作为 MAC 算法。
每个 REPORT 结构还包括一个用于用户数据的 256 位字段，该字段将 enclave 内的数据绑定到 enclave 身份（如 REPORT 中所表达的那样）。这个字段可以用来扩展带有辅助数据的 REPORT，方法是用辅助数据的散列摘要填充它，然后与 REPORT 一起提供。用户数据字段的使用使 enclave 能够构建更高级别的协议，以在其自身与另一个实体之间形成安全通道。
例如，通过交换认证公共 Diffie-Hellman 密钥的 REPORT，这些密钥是使用相互同意的参数在 enclave 内随机生成的，enclave 可以生成经过身份验证的共享秘密，并使用它来保护它们之间的进一步通信。英特尔架构支持通过可供 enclave 软件使用的 RDRAND 指令生成真随机数。
下图显示的示例流程说明了，同一平台上的两个 enclave 如何相互验证，并验证对方是否在同一平台上的 enclave 内运行，从而满足英特尔 SGX 的安全模型。
- 在 enclave A 和 B 之间的通信路径建立后，enclave A 获得 enclave B 的 MRENCLAVE 值。请注意，此步骤中的通信路径不必是安全的。
- enclave A 用 enclave B 的 MRENCLAVE 调用 EREPORT 指令以创建目的地为 enclave B 的签名 REPORT，enclave A 通过不受信任的通信路径将其 REPORT 发送到 enclave B。
- 收到 enclave A 的 REPORT 后：
-
- enclave B 调用 EGETKEY 来检索它的 Report Key，在 REPORT 结构上重新计算 MAC，并将结果与 REPORT 中的 MAC 进行比较。如果 MAC 值匹配，则确认 A 确实是一个与 enclave B 在同一平台上运行的 enclave，因此 A 在遵守英特尔 SGX 安全模型的环境中运行。
- 一旦验证了 TCB 的固件和硬件组件，enclave B 就可以检查 enclave A 的 REPORT 以验证 TCB 的软件组件：（1）MRENCLAVE 反映了在 enclave 内运行的软件镜像的内容（2）MRSIGNER 反映了密封者的身份
- 然后，enclave B 可以通过使用它刚刚收到的 REPORT 中的 MRENCLAVE 值，为 enclave A 创建 REPORT 来回报。
- enclave B 将其 REPORT 传输到 enclave A。enclave A 可以用与 enclave B 类似的方式验证 REPORT，确认 enclave B 与 enclave A 存在于同一平台上。
跨平台 enclave 认证
用于平台内 enclave 认证的身份验证机制使用对称密钥系统，其中只有验证 REPORT 结构的 enclave 和创建 REPORT 的 EREPORT 指令才能访问身份验证密钥。创建可以在平台外验证的证明需要使用非对称加密。英特尔 SGX 启用了一个特殊的 enclave，称为 quoting enclave，专门用于远程认证。quoting enclave 使用上述平台内 enclave 证明方法验证来自平台上其他 enclave 的 REPORT，然后用设备特定（私有）非对称密钥创建的签名替换这些 REPORT 上的 MAC，此过程的输出称为 QUOTE。
- Intel Enhanced Privacy ID (EPID)
当在平台的整个生命周期中使用少量密钥时，使用标准非对称签名方案的证明会引起隐私问题。为了克服这个问题，英特尔引入了一个直接匿名认证方案的扩展，该方案由TPM使用，称为“英特尔增强隐私ID（EPID）”，用于 quoting enclave 签署 enclave 认证。EPID 是一种组签名方案，它允许平台在不唯一标识平台或链接不同签名的情况下对对象进行签名。相反，每个签名者都属于一个“组”，验证者使用该组的公钥来验证签名。EPID 支持两种签名模式：在 EPID 的全匿名模式下，验证者无法将给定的签名与组的特定成员相关联；在伪匿名模式下，EPID 验证器能够确定它之前是否已验证过平台。
- The Quoting Enclave
quoting enclave 创建用于签署平台证明的 EPID 密钥，然后由 EPID 后端基础设施进行验证。EPID 密钥不仅代表平台，还代表底层硬件的可信度。
当 enclave 系统运行时，只有 quoting enclave 可以访问 EPID 密钥，并且 EPID 密钥与处理器固件的版本绑定。因此，可以看到 QUOTE 是由处理器本身发出的。
- Example Remote Attestation Process
下图显示了，在用户平台上具有安全处理元件的应用程序如何向具有挑战性的服务提供商提供证明，以便从提供商那里获得一些增值服务。请注意，大多数用法中，很少使用此过程（例如，在注册时）为 enclave 提供通信密钥，然后在后续连接中直接使用该密钥。
- 最初，应用程序需要来自平台外部的服务，并与服务提供系统建立通信。服务提供商向应用程序发出挑战，以证明它确实在一个或多个 enclave 内运行了必要的组件，挑战本身包含一个用于活跃性目的的随机数。
- 应用程序提供了 quoting enclave 的标识符，并将其与提供者的挑战一起传递给应用程序的 enclave。
- enclave 生成一个清单，其中包括对挑战的响应和临时生成的公钥，供挑战者用于将秘密传送回 enclave。然后它生成清单的哈希摘要，并将其作为 EREPORT 指令的用户数据包含在内，该指令将生成将清单绑定到 enclave 的 REPORT。最后 enclave 将 REPORT 发送回应用程序。
- 应用程序将 REPORT 转发到 quoting enclave 进行签名。
- quoting enclave 使用 EGETKEY 指令检索其 Report Key 并验证 REPORT。quoting enclave 创建 QUOTE 结构并使用其 EPID 密钥对其进行签名。quoting enclave 将 QUOTE 结构返回给应用程序。
- 应用程序将 QUOTE 结构和任何相关的支持数据清单发送给服务挑战者。
- 挑战者使用 EPID 公钥证书和吊销信息或证明验证服务来验证 QUOTE 上的签名。然后，它使用 USERDATA 验证清单的完整性，并检查清单以获取对它在步骤 1 中发送的挑战的响应。
密封
当 enclave 被实例化时，其数据被维护在 enclave 边界内，硬件为其提供保护（机密性和完整性）。但是，当 enclave 进程退出时，enclave 将被破坏，并且 enclave 内受保护的任何数据都将丢失。如果数据打算在以后重新使用，则 enclave 必须进行特殊安排以将数据存储在 enclave 之外。
上面的表格显示，EGETKEY 提供对永久性密封密钥的访问，enclave 软件可以使用这些密钥加密和保护数据的完整性。英特尔 SGX 对 enclave 使用的加密方案没有限制。当与平台提供的其他服务（例如单调计数器）结合使用时，也可以对数据进行重放保护。
英特尔 SGX 支持的密封策略
调用EGETKEY时，enclave 会选择标准或策略，enclave 可以为其访问此密钥。这些策略有助于控制敏感数据对 enclave 未来版本的可访问性。
英特尔 SGX 支持两种密封密钥策略：
- 密封 enclave 身份
- 密封 sealing 标识
密封 enclave 的身份会生成一个密钥，该密钥可用于该确定 enclave 的任何实例。这不允许未来的软件访问这个 enclave 的秘密。密封 enclave 的密封标识会产生一个密钥，该密钥可用于由同一密封机构签署的其他一些 enclave。这可用于允许较新的 enclave 访问先前版本存储的数据。
只有使用相同策略规范执行 EGETKEY 的后续 enclave 实例，才能检索密封密钥，并解密出先前的 enclave 实例使用该密钥密封的数据。
- 密封 Enclave Identity
当密封 enclave 的 Enclave Identity 时，EGETKEY 将基于 enclave 的 MRENCLAVE 的值。任何影响 enclave 度量的更改都会产生不同的密钥。这导致每个 enclave 使用不同的密钥，从而在 enclave 之间提供完全隔离。使用此策略的一个副产品是，同一个 enclave 的不同版本也会有不同的密封密钥，从而阻止了离线数据迁移。
此策略对于发现漏洞后不应使用旧数据的用途非常有用。例如，如果数据是身份验证凭证，则服务提供商可以撤销这些凭证并提供新的凭证，访问旧凭证可能有害。
- 密封 Sealing Identity
当密封 enclave 的 Sealing Identity 时，EGETKEY 基于 enclave 的 MRSIGNER 的值和 enclave 的版本来确定密钥。MRSIGNER 反映了签名 enclave 证书的密封机构的密钥/身份。
密封 Sealing Identity 比 Enclave Identity 的优势在于它允许在 enclave 版本之间离线迁移密封数据。密封机构可以签署多个 enclave 并使它们能够检索出相同的密封密钥，这些 enclave 可以透明地访问被另一个 enclave 密封的数据。
Sealing Idnetity 密封时，不应允许旧软件访问新软件创建的数据。当发布新软件的原因是为了解决安全问题时，情况确实如此。为方便起见，密封机构可以选择规定一个安全版本号 (SVN) 作为密封标识的一部分。EGETKEY 允许 enclave 指定在生成 Seal Key 时使用哪个 SVN，它将只允许 enclave 为其密封标识或以前的标识指定 SVN。当 enclave 密封数据时，它可以选择设置允许访问该密封密钥的 enclave 的最小 SVN 值。他可以保护未来的机密不被旧的易受攻击的软件访问，但仍然可以实现无缝升级过渡，其中所有以前的机密在升级后都可用。
SVN 与产品版本号不同。一个产品可能有多个版本，具有不同的功能，但具有相同的 SVN。飞地编写者有责任与他们的客户沟通（如有必要），哪些产品版本具有相同的安全等效性。
从平台中删除秘密
Intel SGX 架构提出了一种机制，称为 OwnerEpoch，它使平台所有者可以通过更改单个值来更改系统中的所有密钥。由于通过 EGETKEY 指令请求密钥时会自动包含 OwnerEpoch，因此使用特定 OwnerEpoch 值密封的数据对象只有在 OwnerEpoch 设置为相同值时才能解封。
该机制的主要目的是允许平台所有者在将平台转让给其他人（永久或暂时）之前，以简单且可恢复的步骤拒绝访问平台上的所有密封秘密。在转移平台之前，平台所有者可以使用 OEM 提供的钩子将 OwnerEpoch 更改为不同的值。在临时转移的情况下（例如平台维护），一旦平台归还，平台所有者可以将 OwnerEpoch 恢复到其原始值，并可以恢复对密封秘密的访问。