SGX Attestation

叶卡捷琳堡

已于 2023-12-04 12:43:25 修改

阅读量403

点赞数

文章标签： sgx attestation

于 2023-12-04 12:43:07 首次发布

原文链接：https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation

版权

Attestation

有时，由于不同的原因，飞地需要与同一平台上的其他飞地协作，例如，如果飞地太小而无法容纳所有信息，则进行数据交换，或者与英特尔保留的飞地通信以执行特定的英特尔服务。

因此，这两个交换飞地必须向对方证明他们是可以信任的。在其他情况下，当启用SGX的ISV客户端向其ISV客户端（例如密码管理服务）请求机密时，客户端必须向服务器证明客户端应用程序运行在可以安全处理机密的可信平台上。这两个条件都需要安全执行环境的证明，Intel SGX将此证明过程称为证明。

对于上述两种情况，有两种类型的证明：本地证明和远程证明。

本地认证的成功结果为运行在同一平台上的两个飞地之间提供了一个经过身份验证的断言，即它们可以相互信任并安全地交换信息，而远程认证则为ISV客户端向服务器提供这种验证，使ISV服务器可以自信地向客户端提供其请求的机密。

在深入研究认证的细节之前，我们需要澄清一些所需的说明和数据。

Device Root Keys

有两个设备根密钥在生产时与SGX CPU融合。

Root Provisioning Key (RPK)

此密钥是在一个名为“英特尔密钥生成设备”（iKGF）的专用设备内的专用硬件安全模块（HSM）上随机生成的，该设备保证是一个保护良好的离线生产设备。英特尔还负责维护HSM生成的所有密钥的数据库。RPK被交付到不同的工厂设施，英特尔的正式出版物将其命名为“大批量制造系统”，以集成到处理器的保险丝中。
英特尔存储所有RPK，因为它们是SGX处理器如何通过在线供应协议证明其真实性的基础。因此，iKGF还将每个RPK的不同派生转发到英特尔的在线服务器。

Root Sealing Key (RSK)

该密钥是在生产过程中在CPU内部自动随机生成的，以在统计上因零件而异。英特尔声明，它试图擦除该密钥的所有生产线残留物，以便每个平台都假设其RSK值是唯一的，并且只有自己知道。飞地的可信接口提供的大多数密钥都是基于平台的RSK派生的，因此没有其他方可以知道这些密钥。

在这里插入图片描述

Enclave Measurement (aka Software TCB)

构建并初始化飞地后，Intel SGX将生成所有构建活动的加密日志，包括：

内容：代码、数据、堆栈、堆
飞地内每个页面的位置
正在使用的安全标志

“飞地标识”是日志的256位散列摘要，作为飞地的软件TCB存储为MRENCLAVE。为了验证软件TCB，应首先安全地获得飞地的软件TCB、然后安全地获得预期飞地的程序TCB并比较这两个值。

Two user instructions

REPORT Contains following data

飞地中代码和数据的测量。
飞地初始化时提供的ISV证书中公钥的哈希。
用户数据。
其他与安全相关的状态信息（此处未描述）。
上述数据的签名块，可以由生成报告的同一平台验证。

EREPORT

此指令生成一个称为REPORT的加密结构，将MRENCLAVE绑定到目标飞地的REPORT KEY。

REPORT KEY

EREPORT用于签署在该特定平台上生成并发送给该飞地的所有报告。
Used by EREPORT to sign all reports generated on that specific platform and destined that for that enclave.

EGETKEY

Enclaves可以使用EGETKEY指令来获取设备密钥的衍生物。EGETKEY根据调用飞地属性和请求的密钥类型为不同的目的生成对称密钥。有五种不同的密钥类型。其中两个是可用于所有飞地的密封和报告密钥。其余仅限于SGX体系结构飞地。

EGETKEY使用请求包围区指定的安全版本号（SVN）来定义请求的密钥特性。反映处理器微码版本的CPU SVN，或反映飞地软件版本的ISV SVN。EGETKEY将这些值与SIGSTRUCT中存储的值进行检查，并且只允许获得SVN值低于或等于调用飞地的SVN值的密钥，以便同一软件的升级版本可以检索以前版本创建的密钥。

SIGSTRUCT

飞地的证书被称为SIGSTRUCT，是发射任何飞地的强制性补充。SIGSTRUCT将飞地的MRENCLAVE与其他飞地属性一起保存。SIGSTRUCT由ISV用其私钥签名，该私钥最初由SGX发布机构签名。英特尔被视为主要飞地发布机构，但平台所有者可以信任其他实体来授权飞地的发布。受尊重的发布权限由Intel签名并存储在平台上的公钥哈希指定。

我们首先阐明了本地认证和远程认证的过程。

Local Attestation

在同一平台上多个飞地相互协作之前，一个飞地必须使用Intel SGX Report机制对另一个进行本地身份验证，以通过应用基于Report的Diffie-Hellman密钥交换来验证对方是否在同一TCB平台上运行。此过程称为英特尔的本地认证。本地认证的成功结果将在两个本地飞地之间提供一个受保护的通道，并保证机密性、完整性和重放保护。

Local Attestation Abstract

在这里插入图片描述

同一平台上有两个飞地，称为飞地A和飞地B。我们假设它们已经在彼此之间建立了通信路径，并且该路径不需要信任。W.l.o.g我们假设B要求A证明它与B在同一平台上运行。
首先，B检索其MRENCLAVE值，并通过不可信通道将其发送给A。
A使用EREPORT指令，使用B的MRENCLAVE为B生成报告。然后A将该报告发送回B。A还可以在报告中包括Diffie-Hellman密钥交换数据，作为未来创建可信通道的用户数据。
B收到A的REPORT后，调用EGETKEY指令获取REPORT KEY，对REPORT进行验证。如果REPORT可以用REPORT KEY进行验证，则B确保A与B在同一平台上，因为REPORT KEY是特定于该平台的。
然后B使用从A的REPORT接收的MRENCLAVE为A创建另一个REPORT，并将REPORT发送给A。
然后A也可以执行与步骤4相同的操作，以验证B与A在同一平台上。
通过利用REPORT的用户数据字段，A和B可以使用Diffie-Hellman密钥交换创建安全通道。信息交换可以通过共享对称密钥进行加密。

Remote Attestation Primitives

本节介绍Intel提供的远程认证服务的设计细节。

Overall View of Intel SGX Infrastructure Services

在这里插入图片描述

Platform Provisioning

为了将本地REPORT转换为可远程验证的QUOTE，Quoting Enclave使用平台唯一的非对称证明密钥。然后，远程方可以使用相应的公钥验证QUOTE。

那么，QE首先是如何获得这个认证密钥的呢？在本教程中，我们将解释SGX平台接收其远程证明密钥的配置过程。

供应是SGX设备向Intel展示其真实性及其CPU SVN和其他系统组件属性的过程，以便接收反映其SGX真实版本和TCB版本的适当证明密钥。通常，资源调配是在平台初始设置阶段完成的，但由于固件、BIOS或微码等关键系统组件存在漏洞，因此也可以在购买后执行重新资源调配。在这种情况下，可以替换证明密钥以反映平台更新的TCB安全级别。

证明密钥是SGX生态系统中的核心资产。依赖方将有效的证明签名视为英特尔签名的证书，以保证平台的真实性。为了方便SGX资源调配服务，英特尔运营了一个专用的在线资源调配基础设施。SGX供应和远程证明协议遵循Intel开发的名为增强隐私ID（EPID）的组签名方案。为了实现EPID供应过程，Intel提供了一个称为供应飞地（PvE）的体系结构飞地。

Provisioning Enclave (PvE)

PvE负责在平台上针对英特尔的在线资源调配服务器执行资源调配过程。在这个过程中，PvE证明了它有一个密钥，英特尔将其放入一个真正的SGX处理器中，作为回报，它为未来的远程验证提供了一个独特的平台证明。双方实施EPID方案加入协议；PvE充当新的加入成员，而Intel充当发布新的组成员证书的组成员颁发者。

PvE通过使用几种SGX特权密钥类型来证明其真实性，这些密钥类型只能由SGX体系结构飞地通过EGETKEY指令访问。其中两个密钥是供应密钥（PK）和供应密封密钥（PSK）。PvE和QE的唯一性基于其由Intel（MRSIGNER）签署的SIGSTRUCT证书。因此，这些飞地被授权以特权属性启动，以便稍后通过执行EGETKEY指令来获得特殊密钥。

PK的推导过程包括两个阶段：首先，将根配置密钥绑定到硬件TCB。TCB密钥发生在处理器引导期间，通过使用反映平台固件组件的当前平台SVN补丁级别在PRF上循环。其次，将SW属性添加到生成的PK中。当调用EGETKEY并使用TCB密钥作为派生基础时，就会发生这种情况。PvE的软件元素由EGETKEY输入参数反映。在这种情况下，将忽略根签名密钥和所有者Epoch值，以呈现相同的平台特定密钥，而不管其当前所有者如何。由此产生的PK是反映SGX平台的硬件和软件组件的唯一密钥。此过程还最大限度地减少了根配置密钥的暴露。

Provisioning Protocol

在获得PK后，平台可以启动供应过程（provisioning）来获得证明密钥。

1.Enclave Hello

一旦我们有了TCB特定的PK，PvE就会生成两个值来启动供应协议。第一个是PK的散列，称为平台配置ID（PPID）。第二个反映了基于当前SVN的所声称的TCB水平。两者都使用IPS的公钥加密并发送到IPS。

2.Server Challenge

Intel使用PPID来确定平台之前是否已配置。如果是，则将先前生成的证明密钥的加密版本添加到服务器的质询中。如果不是，则服务器确定该平台的EPID组，并将EPID组参数与活跃度随机数和预先计算的TCB质询一起添加到发送回平台的消息中。

由于所有RPK都由离线英特尔密钥生成设备（iKGF）存储，因此它可以在每个SGX设备上使用EGETKEY（如何获取软件属性？）执行与PvE相同的硬件和软件TCB特定派生过程，以生成自己的供应密钥（如何知道哪个SGX是哪个？）。此PK用于加密随机值，以生成特定于平台的TCB质询。所有预先计算的挑战都会发送到英特尔的在线服务器，以支持供应协议。

3.Enclave Response

在PvE用其PK解密TCB质询后，它使用它通过使用TCB质询作为CMAC（从Intel接收的随机数）的密钥来生成TCB证明。接下来，PvE生成一个随机的EPID成员密钥，并根据EPID协议对其进行数学隐藏，使IPS无法学习成员密钥。

为了方便未来的证明密钥检索服务，非隐藏成员密钥由PvE使用另一种特殊密钥PSK加密。PSK派生不包括所有者Epoch，而是使用RSK作为派生的根密钥。因此，PSK不受平台所有者变更的影响，并且仅限于该特定平台。

如果平台以前已经被提供，并且正在进行的协议是证明密钥检索或TCB更新，则平台必须证明它在过去从未被撤销。这是通过使用PSK解密从服务器获得的备份证明密钥副本，并使用它们对英特尔选择的选定消息进行签名来实现的。

发送隐藏的和加密的EPID成员密钥，以及TCB和未撤销的证明。

4.Completion

收到响应后，IPS首先使用从iKGF收到的值验证TCB证明，并在成功时继续EPID Join协议。对隐藏的成员身份密钥进行处理，以创建一个使用EPID组颁发者密钥签名的唯一证书，并将其与加密成员身份密钥一起存储，以备将来重新配置事件使用。完成协议的最终消息随后由包含签名证书的服务器发送。

平台的成员密钥与匹配的签名证书一起形成唯一的EPID私钥。由于证明密钥是由双方合作构建的，因此任何人都无法伪造平台生成的有效会员签名。

5.Final

PvE使用PSK对证明密钥进行加密，并存储在平台上以备将来使用。由于EPID组是根据TCB级别进行分类的，因此EPID签名可以作为用户来表示平台的SGX真实性及其TCB级别。

Remote Attestation Process

一般来说，远程认证的目标是硬件实体或硬件和软件的组合获得远程服务提供商的信任，以便服务提供商能够自信地向客户端提供所请求的秘密。使用英特尔SGX，远程认证软件包括应用程序的飞地，以及英特尔提供的报价飞地（QE）和资源调配飞地（PvE）。证明硬件是启用了英特尔SGX的CPU。远程证明提供了三个方面的验证：应用程序的身份、其完整性（未被篡改）以及在支持英特尔SGX的平台上的飞地内安全运行。

Sigma protocol

Sigma协议包括Diffie-Hellman密钥交换，但也解决了DH的弱点。Intel SGX使用的协议与常规Sigma协议的不同之处在于，Intel SGX平台使用Intel EPID进行身份验证，而服务提供商使用公钥基础结构（在常规Sigma中，双方都使用PKI）。最后，密钥交换库要求服务提供商在协议的身份验证部分使用ECDSA而不是RSA密钥对，并且这些库使用ECDH进行实际的密钥交换。

作为客户端和服务提供商之间的这种交换的结果，产生了包围区和挑战者之间的共享密钥，该共享密钥可用于加密要在包围区中提供的秘密。一旦进入飞地，这些秘密就可以由应用程序解密。

Diffie-Hellman Key Exchange (DHKE)

一种在公共信道上交换密钥而不将实际密钥泄露给其他侦听器的方法。这里解释密码算法。

Intel Enhanced Privacy ID (EPID)

它是对现有直接匿名认证（DAA）方案的扩展，添加了一些内容，例如使用SigRL（签名撤销列表）。EPID可以在不留下可唯一回溯到签名者的跟踪的情况下对对象进行签名，从而使签名过程匿名。这是通过根据签名者的处理器类型将其划分为多个组（也称为EPID组）来实现的。通过这种方式，他们使用自己的密钥创建签名，但签名只能使用所属组的公钥进行验证，从而可以检查签名者是否属于正确的组，但无法唯一识别签名者。

Revocation Lists

SGX提供了三种类型的吊销列表（RL）：组RL，它保存所有已吊销的EPID组，Priv RL列出同一EPID组的所有已吊销私钥，Sig RL列出相同EPID组中所有已吊销成员的基名称元组及其相应签名。

Trusted Computing Base (TCB)

负责保护提供给飞地的秘密（包括软件和硬件）的实体。

Quoting Enclave (QE)

每个SQX处理器上的一个特殊飞地，完全负责处理远程证明。它接收来自其他飞地的REPORT，对其进行验证并使用证明密钥对其进行签名，然后将结果（也称为QUOTE）返回给应用程序。

SGX Service Providers

依赖方被称为服务提供商，不必持有支持SGX的硬件。服务提供商应注册到IAS，并满足英特尔定义的一系列要求，以便提交证明证据进行IAS验证。此注册将服务提供商的传输层安全性（TLS）证书绑定到唯一的服务提供商ID（SPID），并允许访问IAS服务。其中一些主要的IAS服务是：验证ISV飞地报价、请求更新的证明吊销列表以及检索与报价相关联的断言信息历史记录。

Remote Attestation Modes

QE支持两种具有不同链接能力属性的报价签名模式，即完全匿名报价和假名报价。报价的链接能力属性由使用平台的唯一证明密钥签名的basename参数决定。使用相同的证明密钥多次对相同的basename参数进行签名会产生易于链接的假名引号。服务提供商使用此模式来跟踪重新访问用户，防止sybil攻击，同时保护用户的隐私。当使用假名报价时，IAS首先验证所使用的基本名称是否与该特定服务提供商相关联。IAS的这个角色强制不同服务提供商之间的用户假名分离。相比之下，通过在不同的基础名称上签署多个签名，在计算上不可能确定报价是否使用相同的证明密钥生成，从而保持平台的匿名性。因此，QE使用随机基名称来签署完全匿名的报价。

Remote Attestation Abstract

在这里插入图片描述
对于远程证明，同时使用对称和非对称密钥系统。对称密钥系统用于本地证明，其中只有引用包围区和EREPORT指令可以访问认证密钥。非对称密钥系统用于创建可以从其他平台验证的证明。证明密钥本身是不对称的（EPID密钥）。

远程认证主要涉及三个平台：

服务提供商（挑战者）
应用程序及其飞地及其量化宽松
验证飞地阶段的Intel验证服务（IAS）

Detailed Stages

首先，ISV飞地向远程服务提供商发送初始请求，其中包括平台声称当前是其成员的EPID组。
如果服务提供商希望为所声称的组的成员提供服务，则其可以通过向IAS请求更新的SigRL来进行。
服务提供商然后构造质询消息，该质询消息包括其SPID、活跃度随机随机随机数、更新的SigRL和可选的基本名称参数（如果需要假名签名）。
如果飞地支持请求的签名模式，它会调用EREPORT指令来创建一个本地可验证的报告，该报告指向平台的QE。为了在飞地和服务提供商之间建立经过验证的安全通道，可以将新生成的临时公钥添加到报告的用户数据字段中。报告和标普的质疑被发送给量化宽松。
（此处发生本地验证）QE调用EGETKEY以获取REPORT KEY并验证报告。如果成功，QE将再次调用EGETKEY以接收平台的Provisioning Seal Key，从而解密平台的远程证明密钥（EPID私钥）。根据所请求的证明模式，证明密钥首先用于通过对被质疑的基名称或随机值进行签名来产生身份签名。
然后，证明密钥用于计算平台的身份签名MRENCLAVE上的两个知识签名。第一个证明身份签名是用英特尔认证的密钥签名的。第二种是非撤销证明，证明用于身份签名的密钥不会创建被质疑的SigRL中列出的任何身份签名。然后，使用IAS的公钥生成并加密最终报价，该公钥在QE中进行硬编码，结果被发送回证明飞地。QUOTE包含证明飞地的标识、执行模式详细信息（例如SVN级别）和附加数据。
然后，飞地将报价转发给SP进行验证。
由于QUOTE是加密的，因此它只能由英特尔进行验证。因此，服务提供商只需将报价转发给IAS进行验证。
IAS通过首先根据其身份签名验证其EPID证明来检查报价。然后，它通过计算列表中每个私钥的QUOTE基名称上的身份签名，并验证它们都不等于QUOTE的身份签名来验证平台是否未列在Priv RL组中。这就完成了平台的有效性检查，然后IAS创建一个新的证明验证报告作为对SP的响应。证明验证报告包括平台为证明飞地生成的QUOTE结构。
一份肯定的证明验证报告证实飞地在真正的英特尔SGX处理器上运行特定的代码。然后，SP负责验证ISV飞地标识，并向平台提供适当的响应。