SGX本地认证

一、定义

• 同一个平台上的两个不同enclave之间认证。
• 本地认证有两种形式：
  · 其一，两个enclave同属于一个app，消息流程通过api调用即可完成；
  · 另一种，两个enclave分别属于各自的app，但在同一平台上，消息可通过socket等方式同步。

二、流程

1. 应用程序A承载enclaveA，应用程序B承载enclaveB。Encalve A是Claimer，Enclave B是验证方。当不受信任的应用程序A和B在两个飞地之间建立了通信路径后，Enclave B将其MRENCLAVE标识发送给Enclave A。

通信路径：

• 进程内：Intel SGX SDK中sample code中LocalAttestation，三个 enclave 位于同一个应用进程内，即进程内。所需的数据结构通过使用目标飞地 EnclaveID调用到目标飞地中来传递。
• 进程间：如果两个 enclave 位于不同的应用程序进程中，则它们将无法访问彼此的证明处理 API（attestation-handling APIs）。因此，不受信任的通信路径需要额外的间接层，可以是 IPC（共享内存）、TLS 等。需要向不受信任的应用程序添加额外的数据传输逻辑，以便为 ECDH 和证明过程传递必要的数据结构。在进程间本地证明结束时，我们应该达到与进程内本地证明相同的点，即从 SGX 密钥生成的共享 EDCH secret，用于确保两个 enclave 之间未来的安全通信，以及彼此的相互身份验证。

2. Enclave A要求硬件使用从Enclave B接收到的MRENCLAVE值生成一个EREPORT结构，Enclave A通过Untrusted code将其报告发送给Enclave B。
3. 安全区B调用EGETKEY检索其报告密钥并验证EREPORT结构的MAC，如果有效，则该Enclave应为预期的并在合法平台上运行。然后Enclave B使用这个ERPORT中的MRENCLAVE值为Enclave A生成一个自己的EREPORT结构并将这个report传送给Enclave A。EnclaveA同样验证这个report来确认Enclave B和它在同一个平台上。

本地认证图

三、源码分析

3.1 目录结构分析

目录依赖关系图

• Untrusted_LocalAttestation/：DH安全信道的建立的OCALL函数
• LocalAttestationCode/：DH安全信道的建立
• App/：应用程序的入口点

3.2 流程分析

Sample

1. Initiator enclave 调用Intel ECDH密钥交换库以发起具有发起者角色的会话。
2. 发起者通过OCALL进入不受信任的代码，请求Diffie-Hellman的Msg1和session id。
3. Untrusted Code调用ECALL进入到响应者Enclave。
   3.1 响应者enclave转而调用ECDH密钥交换库来启动具有响应者角色的会话。
   3.2 响应者enclave调用密钥交换库来生成DH
   Message 1 ga || TARGETINFO。
4. DH Msg1从响应者enclave发回给发送者enclave。
   7.发起者enclave使用密钥交换库API处理Msg1，并生成DH Message 2 gb||[Report Enclave 1(h(ga || gb))]SMK.。
5. DH Msg2通过OCALL发送给不被信任的一端。
6. Untrusted Code通过ECALL将DH Msg2给了响应者enclave并请求DH Msg3。
   9.1 响应者enclave使用密钥交换库API来处理DH Msg2，并生成DH Message 3 [ReportEnclave2(h(gb|| ga)) || Optional Payload]SMK.。
7. DH Msg3从响应者enclave发回给发送者enclave。
8. 发起者enclave使用密钥交换库来处理DH Msg3并建立会话。
   受AEK保护的通信信道建立。
   
   Intel Doc