代码角度理解SGX的认证机制（三）：远程认证

1. SGX 远程证明
   1.  和EPID证明协议不同，SGX不允许信任各方充当EPID验证的角色。而是由intel提供一个全球在线验证机构叫做intel 认证服务 (IAS)。
   2. EPID认证协议涉及两个intel控制的服务，和两个独立单元。两个intel控制的服务为一个QE和一个IAS，充当认证提供者和验证者。两个独立单元中，ISV认证enclave充当认证提供者，证明服务充当认证者。
   3. The Quoting Enclave：提供远程认证的一个架构enclave，佳作Quotes。它被平台的attestation key签名。因为attestation key被平台的Provisioning Seal key封装，因此仅PvE和QE可以获取attestation key。通过在intel签名的SIGSTRUCT中配置属性为这两个enclave提供此特权。
   4. 为了确保Quotes运行在一个合适的enclave模式，QE服务仅作为本地证明使用，它接收一个本地认证的EREPORT并验证它，如果EREPORT合法，QE就用平台attestation key对本地报告签名，转换到Quote中。
   5. SGX service providers：称为服务提供商的参与方，可以是没有SGX的硬件。 服务提供商应向IAS注册并满足一组Intel定义的要求，以便为IAS验证提交证明证据。该注册将服务提供商的TLS证书绑定到一个唯一的服务通过商ID（SPID），并允许访问IAS服务。这些服务主要包括：ISVenclave Quotes，更新的认证撤销列表，过去的IAS验证报告。
   6. Remote attestation modes：QE支持两种具有不同链接属性的Quote签名模式，全匿名和伪匿名。
      1. 简单来说，intel 需要enclave对basename属性签名，如果basename是不可变的则，通过attestation key对basename多次签名结果也不变，通过这种方式，可以区分不同的用户，这种叫做伪匿名；如果basename是随机生成的则无法通过签名结果区分是不是来自同一个用户，这种叫做完全匿名。
      2. enclave的可链接性属性由使用平台唯一的attestation key签名的basename 参数确定。使用相同的attestation key对相同的basename参数进行多次签名会产生易于链接的伪匿名。服务提供商使用此模式来跟踪用户，并在防止用户攻击的同时保护用户的隐私。当使用伪匿名Quote时，IAS首先验证所使用的basename 已与该特定服务提供商相关联[6]。 IAS的这一角色强制了用户在不同服务提供商之间的匿名隔离。相比之下，通过在不同的basename 上签名多个签名的方案，要确定在enclave中是否使用了相同的 attestation key是不可行的，从而保留了平台的匿名性。因此，使用随机的basename 来签署完全匿名的Quotes。
   7. Revocation lists：SGX目前有三个类型的撤销列表(RLs):Group-RL（EPID组撤销列表），Priv-RL（一个EPID组里的所有被撤销的私钥），Sig-RL（一个元组，包含一个basename及它相应的同一EPID组已撤销的所有成员的签名）
2. 远程证明协议
   1. 首先，ISV enclave将初始请求发送到所需的远程服务提供商。 该请求包括EPID，标识该平台属于该组。
   2. 如果服务提供商希望为要求保护的小组的成员提供服务，则可以通过向IAS请求更新的Sig-RL（与平台的特定小组相对应）来继续。
   3. 然后，服务提供商将构造一个challenge消息，该challenge消息包括其SPID，随机数nonce，更新的组Sig-RL和可选的basename 参数（如果需要伪匿名签名）
   4. 如果enclave支持请求的签名模式，则用EREPORT指令去生成一个本地验证报告交个平台的QE。为了在enclave和服务提供商之间建立一个认证安全通道，会将一个新生成的临时公钥添加到本地报告的附加数据域。这个EREPORT和服务提供商的challenge一起发送到QE。
   5. QE用EGETKEY指令获取report key验证EREPORT。
      1. 成功的话，QE使用EGETKEY指令获取平台的Provisioning Seal Key，这个key用来解密平台的远程 attestation key(EPID private key)。
      2. attestation key先是用来根据签名模式对challenged的basename或者一个随机值签名来生成一个签名的标识符。如果使用的是非随机的basename，则签名是伪匿名，否则是全匿名的。
      3. attestation key再用来计算平台身份签名（MRENCLAVE）上的两个知识签名。第一个证明身份签名是由英特尔认证的密钥签名的。 第二个是非撤销的证据，它证明用于身份签名的密钥没有在challenged Sig-RL中列出。 然后，Quotes使用IAS的公钥进行加密，IAS的公钥在QE代码中硬编码，然后将结果发送回证明区域。
      4. QUOTE 中包含认证enclave的身份标识，执行模式（例如svn等级），认证enclave的相关的附加数据。
   6. enclave然后转发Quote到服务提供商去验证。
   7. 因为Quote是加密的，需要intel去验证。服务提供商把Quote发送到IAS去验证。
   8. IAS通过首先根据其身份签名验证其EPID证明来检查Quote。 然后，验证这个平台没有在Priv-RL这个撤销列表中列出，通过计算撤销列表中每个私钥对Quote 的basename签名，并验证这些签名均不等于Quote的身份签名，从而验证平台未在Priv-RL组中列出。 这样就完成了平台的有效性检查，然后IAS创建一个新的证明验证报告（verification report）作为对服务提供商（SP）的响应。 证明验证报告包括平台为证明Quote提供的Quote结构。
   9. 一个合法的认证验证报告说明enclave运行在一个真实的Intel SGX 处理器上边。然后，SP负责验证ISV enclave身份并向平台提供适当的响应。