一、定义
- Enclave和不在平台上的第三方之间的证明过程。
- 一般而言，远程认证的目标是让硬件实体或硬件和软件的组合获得远程服务提供商的信任，以便服务提供商可以放心地向客户端提供所请求的机密。
- 借助英特尔 SGX，远程证明软件包括应用程序的 enclave，以及英特尔提供的 Quoting Enclave (QE) 和 Provisioning Enclave (PvE)。证明硬件是支持 Intel SGX 的 CPU。
- 远程证明提供了对三件事的验证：应用程序的身份、其完整性（未被篡改）以及它是否在启用英特尔 SGX 的平台上的飞地内安全运行。
二、相关概念
2.1 Sigma协议
- Sigma 是一种包括Diffie-Hellman 密钥交换的协议，但也解决了DH的弱点——通过身份认证防御了中间人攻击。
- 英特尔 SGX 使用的协议与常规 Sigma 协议的不同之处在于，英特尔 SGX 平台使用英特尔 EPID进行身份验证，而服务提供商使用公钥基础设施（在常规 Sigma 中，双方都使用 PKI）。最后，密钥交换库要求服务提供商在协议的身份验证部分使用ECDSA而不是 RSA 密钥对，并且库使用 ECDH 进行实际的密钥交换。
- 作为客户端和服务提供商之间的这种交换的结果，在飞地和挑战者之间产生了共享密钥，该共享密钥可用于加密要在飞地中提供的秘密。一旦进入飞地，这些秘密就可以被应用程序解密。
2.2 Intel Enhanced Privacy ID (EPID)
- 它是对现有直接匿名认证(DAA)方案的扩展，增加了一些功能，例如使用SigRL(签名撤销列表)。
- EPID支持签名对象，而不会留下可以唯一回溯到签名者的跟踪，从而使签名过程匿名。这是通过根据签名者的处理器类型将其划分为组(也称为EPID组)来完成的。通过这种方式，他们使用自己的密匙创建签名，但是只能使用签名所属组的公钥来验证签名，这样就可以检查签名者是否属于正确的组，但无法惟一地标识签名者。
- 撤销列表：SGX提供了三种类型的撤销列表(RLs)。
(1) Group-RL 包含所有已撤销的EPID组；
(2) Priv-RL 列出同一EPID组中所有已撤销的私有密钥；
(3) Sig-RL 列出同一EPID组中所有已撤销成员的基名元组及其对应的签名。
2.3 Quoting Enclave（QE）
- 一个特殊的enclave，它的任务完全是处理远程认证。它从其他enclaves接收REPORTs，验证它们并使用认证密钥对它们进行签名，然后将结果(也称为QUOTE)返回给应用程序。
- 由Quoting Enclave创建平台认证的签名密钥EPID(enhanced privacy identification)，这个密钥不仅代表平台，还代表着底层硬件的可信度，并且绑定处理器固件的版本，当 enclave 系统运行时，只有Quoting Enclave才能访问到 EPID 密钥。
2.4 Remote Attestation Modes
- QE支持两种具有不同链接能力属性的Quote签名模式，完全匿名和伪匿名Quotes。
- Quote的链接性属性由使用平台的唯一认证密钥签名的basename参数确定
- 使用相同的认证密钥多次签名相同的basename参数会产生容易链接的伪匿名Quotes。这种模式被服务提供商用来跟踪再次访问的用户，并防止sybil攻击，同时保护用户的隐私。当使用伪匿名Quote时，IAS首先验证所使用的basename是否与特定的服务提供者相关联。IAS的这个角色强制用户在不同的服务提供者之间进行伪匿名隔离。
- 相反，通过在不同的basenames上签名多个签名，在计算上无法确定Quotes是否使用相同的认证密钥生成，从而保持了平台的匿名性。因此，QE使用随机的basenames来签名完全匿名的Quotes。
二、流程
远程认证中既使用了对称密钥也使用了非对称密钥。
- 对称密钥系统用于本地认证中，只有Quoting Enclave和EREPORT指令可以访问认证密钥。
- 非对称密钥系统用于创建可以从其他平台验证的认证。认证密钥本身是不对称的(EPID密钥)。
远程认证中主要包括三方面平台：
（1）The service provide (challenger).
（2）The application with its enclave and its QE.
（3）Intel Attestation Service (IAS) that verifies the enclave.
远程认证
- 首先，ISV enclave(2)向远程服务提供者(1)发送一个初始请求，该请求包括平台声称当前是其成员的EPID组。
1.1 如果服务提供者(1)希望为所声明的组的成员提供服务，则可以向IAS请求更新的SigRL。
1.2 然后，服务提供者(1)构造一个challenge message，该消息由SPID、动态随机nonce、更新的SigRL和一个可选的basename参数(如果需要伪匿名签名)组成。 - 应用程序(2)将challenge传递给其enclave(2)。
- 如果enclave(2)支持请求的签名模式，它将调用EREPORT指令来创建一个针对平台QE的本地可验证REPORT。为了在enclave(2)和服务提供者(1)之间建立经过身份验证的安全通道，可以将新生成的临时公钥添加到REPORT的用户数据字段中。
- 应用程序(2)将REPORT和SP的challenge 都传递给QE(2)。
-
(本地认证发生在这里) QE调用EGETKEY来获取REPORT KEY并验证REPORT，判断该enclave是否运行于同一平台。如果成功，QE将再次调用EGETKEY来接收平台的Provisioning Seal Key，这个key用来解密平台的远程认证密钥(EPID私钥)。
5.1 认证密钥先是用来根据签名模式对challenged的basename或者一个随机值签名来生成一个签名的标识符。如果使用的是非随机的basename，则签名是伪匿名，否则是全匿名的。
5.2 然后使用认证密钥计算平台身份签名(MRENCLAVE)上的两个知识签名。第一个证明身份签名是由英特尔认证的密钥签署的。第二种是一个不可撤销的证明，它证明用于身份签名的密钥没有在challenged的SigRL中列出。
5.3 然后使用IAS的公钥(在QE中是硬编码的)生成并加密最终的QUOTE，并将结果发送回应用程序。QUOTE包含认证enclave的身份、执行模式细节(例如SVN级别)和其他数据。 - 应用程序将QUOTE转发给SP服务提供者(1)来进行验证。
- 由于QUOTE是加密的，它只能由英特尔来验证。因此，SP服务提供者(1)只是将QUOTE转发给IAS进行验证。
- IAS首先根据QUOTE的身份签名验证其EPID证明，从而检查QUOTE。
8.1 然后，验证这个平台没有在Priv-RL这个撤销列表中列出，通过计算撤销列表中每个私钥对Quote 的basename签名，并验证这些签名均不等于Quote的身份签名，从而验证平台未在Priv-RL组中列出。这完成了平台的有效性检查。
8.2 然后IAS创建一个新的认证验证报告作为对SP的响应。认证验证报告包括平台为认证enclave生成的QUOTE结构。
8.3 一个积极的认证验证报告确认飞地作为一个真正的英特尔SGX处理器上运行一个特定的代码片段。然后SP负责验证ISV enclave标识，并向平台提供适当的响应。
三、样例源码分析
SGX RemoteAttestation
- Intel®Software Guard Extensions (Intel®SGX)应用程序通常首先从服务提供商(SP)请求服务(例如，媒体流)，而SP将响应一个挑战。具体函数调用关系如下：
remote attestation
- 该流程从应用程序进入enclave开始，enclave将是KE的端点，传入b_pse（b_pse是一个标志，指示应用程序/enclave是否使用平台服务）。
- 如果b_pse为true，那么isv enclave将使用sgx_create_pse_session()调用受信任的AE支持库，以建立与PSE的会话。
- enclave中的代码调用sgx_ra_init()，传入SP的ECDSA公钥、g_sp_pub_key和b_pse。g_sp_pub_ key是一个公钥，它的完整性非常重要，因此应该将该值构建到isv_ enclave中。
- 如果之前建立了会话，则通过sgx_close_pse_session()关闭PSE会话。要求是，如果应用程序enclave使用Platform Services，则必须在应用程序enclave调用sgx_ra_init()之前建立与PSE的会话。
- sgx_ra_init()将KE context返回给应用程序enclave，而应用程序enclave将context返回给应用程序。
- 应用程序调用sgx_get_extended_epid_group_id()并将p_extended_epid_group_id返回的值发送到msg0中的服务器。
- 服务器检查是否支持扩展的Intel®EPID组ID。如果不支持该ID，服务器将中止远程认证。
- 应用程序调用sgx_ra_get_msg1()，传入这个KE的context和sgx_ra_get_ga。
- sgx_ra_get_msg1() 构建 S1 message= (ga || GID) 并将其返回给应用程序。
- 应用程序通过ra_network_send_receive() 向服务提供者(SP) 发送S1，它将调用sp_ra_proc_msg1_req() 处理S1 并生成S2。
- 应用程序最终收到 S2 = gb||SPID||2-byte TYPE || 2-byte KDF-ID || SigSP(gb, ga) || CMACSMK(gb|| SPID || 2-byte TYPE || 2-byte KDF-ID || SigSP(gb,ga)) || SigRL。
- 应用程序调用sgx_ra_proc_msg1()传入S2和context。
- sgx_ra_proc_msg2()中的代码构建S3 = CMACSMK(M)||M
where M = ga ||PS_SECURITY_PROPERTY|| QUOTE并返回给应用程序，其中仅当应用程序/enclave使用Platform Services时才包含Platform Services Security Information。 - 应用程序通过ra_network_send_ receive()将msg3发送给SP，SP验证msg3。
- SP将验证结果返回给应用程序。
- 此时，会话已经建立并交换了密钥。
- SP是否认为会话是安全的并使用它，取决于平台的安全属性，如 S3 消息所示。 如果平台的安全属性满足服务提供者的标准，那么服务提供者可以使用会话密钥安全地传递secret，并且应用程序enclave可以在通过调用受信任KE库上的sgx_ra_get_keys()检索会话密钥之后的任何时间使用secret。
网友评论