SGX developer guide
Introduction to SGX
terms:
EPC - Enclave Page Cache
uRTS - Untrusted Run-Time System
tRTS - Trusted Run-Time System
Trusted Thread Context-
The context for a thread running inside the enclave. This is composed of:
l Thread Control Structure (TCS)
l Thread Data/Thread Local Storage – data within the enclave and specific to the thread
l State Save Area (SSA) – a data buffer which holds register state when an enclave must exit due to an interrupt or exception
l Stack – a stack located within the enclave
Untrusted - Refers to any code or construct that runs in the applications “untrusted” environment (outside of the enclave)
| ECall | “Enclave Call” a call made into an interface function within the enclave |
| Enclave | A container |
| OCall | “Out Call” a call made from within the enclave to the outside application |
| Trusted | Refers to any code or construct that runs inside an enclave in a “trusted” envir onment |
Edge Routines – functions that may run outside the enclave (untrusted edge routines) or inside the enclave (trusted edge routines) and serve to bind a call from the application with a function inside the enclave or a call from the enclave with a function in the application.
DOCS:
Intel® Software Guard Extensions Developer Guide
this guide will help you to develop your own application enclaves.
sgx可用用来attestation, provisioning and sealing （证明，供应和密封 ）
Measurement: As an enclave is instantiated in a trusted environment, an accurate and protected recording of its identity is taken.
Attestation: Demonstrating to other entities that a particular environment was instantiated in the correct manner.
Sealing: Enabling data belonging to the trusted environment to be bound to it such that it can be restored only when the trusted environment is restored.
inclave内外的code没有区别，只是特权代码或者untrust 代码不能读取enclave的数据。
飞地（enclave）包含了一个来自飞地作者的自签名证书SIGSTRUCT。签名包含的信息，允许intel的SGX体系结构能够探测到飞地文件是否被篡改（tempered)。 使得飞地能够保证文件被正确的加载到了EPC中，并且是受信任的。
Enclave File Format
包含 Intel SGX specific data structure, the enclave metadata. Metadta 不加载到EPC，知识告诉untrust loader怎么进行加载。
Metadta定义了 trusted thread context的数量。
trusted thread context包含了trusted stack, and a trusted heap, trusted heap 在enclave 初始化的时候，由trusted runtime system 来初始化。
Trusted thread contexts and trusted heap 要求支持trusted执行环境。
The metadata 也包含了enclave 签名, 是enclave原件和真实性(authenticity)的至关重要的证明。
measurement
256-bit hash，用来标识enclave中的code/数据，这些数据一放入EPC进行初始化，CPU就会先计算measurement ，并放在MRENCLAVE 寄存器中。CPU会比较MRENCLAVE 和SIGSTRUCT，匹配才能进行初始化。
硬件只是在enclave装载的时候验证 enclave measurement。这意味着任何人可以修改enclave并且使用自己的key进行签名。为了防止这种攻击，enclave签名也来标识enclave author. enclave 签名包含了几个重要的字段，对于enclave证明外部entity至关重要。
enclave 初始化成功，CPU将author’s public key 的hash放入MRSIGNER 中。用同样的key验证的所有的enclaves有放在MRSIGNER 中的同样数据。
The Security Version Number of the Enclave (ISVSVN) ，enclave author 给enclave的每个version分配了一个SVN，SVN反映了enclave安全属性的级别，会随着安全属性的提高而单调增加。成功完成安全区域初始化后，CPU会记录SVN，可在证明过程中使用该SVN。具有相同安全属性的安全区的不同版本应分配有相同的SVN。例如，具有与安全无关的错误修复的新飞地应具有与旧版本相同的SVN。
Product ID of the Enclave (ISVPRODID)， enclave author 还为每个enclave分配了一个产品ID。产品ID允许enclave author 使用相同的enclave author ID对飞地进行分片segment 。安全区成功初始化后，CPU将记录产品ID，该ID可在证明过程中使用。
enclave开发人员必须提供enclave的security版本和产品ID，以及签名密钥对，以生成enclave签名。 对enclave签名使用私钥， CPU通过公共密钥来identify enclave作者的身份。必须对放置在enclave的代码和初始数据，放置它们的预期顺序和位置以及这些页面的安全properties 来执行enclave measurement的计算。放置在enclave 内的代码和初始数据以及这些页面的安全properties 由编译器生成，而它们在enclave中的放置则由enclave加载器控制。有关将代码和初始数据放置在enclave中的方式，measurement计算必须遵循enclave 加载器的预期行为。
保护enclave签名密钥
enclave签名密钥是enclave标识的一部分，对于保护其机密至关重要。攻击者破坏了ISV的专用签名密钥，则可以：
- 编写一个可以成功证明合法 身份的恶意enclave ，
和/或
- 编写使用恶意软件，使用恶意enclave 破坏individual平台上封印的数据。
应采用正确的密钥管理做法来保护私有签名密钥，例如：
- 保持对私有签名密钥的最小访问。
- 使用另一个enclave 或硬件安全模块（HSM）存储私有签名密钥并执行安全区签名。
- 使用单独的密钥对将测试签名与发布签名分开。
ISV将提供一个用于对enclave 进行签名的工具，例如，一个用于获取enclave 文件的工具, 并将英特尔SGX架构要求的enclave 签名添加上去。该工具应支持使用测试签名私钥在本地系统上进行测试签名，以及支持涉及签名发布设施的多步发布签名过程，其中发布签名私钥受到保护。
保持开发平台干净
ISV必须始终保持开发环境中没有恶意软件和其他潜在线程。 如果开发平台遭到破坏，您将无法继续使用Intel SGX支持软件，因为它可能会被用来破坏建立在该平台上的enclave的完整性。 此时，ISV必须先清理（sanitize ）平台，然后才能继续进行开发。
证明
证明是展示在平台上建立了一个软件的过程。对于Intel SGX，它是一种机制，通过该机制建立第三方实体，在Intel SGX平台上，内受保护的软件实体先运行后， 再为软件提供机密和受保护的数据 。证明依赖于平台产生能够准确反映enclave签名的凭证的能力，其中包括encalve安全特性的信息。英特尔SGX架构提供了支持两种形式的证明的机制。有一种机制可以在运行于同一平台上的enclaves 之间创建基本声明，以支持本地或平台内证明，然后还有另一种机制可以为enclave与远程第三方之间的证明提供基础。
本地（平台内）证明
应用程序开发人员可能希望编写可以相互协作以执行某些高级功能的enclaves。为此，开发人员需要一种机制，允许enclave向本地平台内的另一方证明其身份和真实性。英特尔SGX为此提供了一种受信任的基于硬件的机制。一个enclave可以要求硬件生成证书，也称为报告，其中包括该enclave在平台上的加密证明。该报告可以提供给另一个enclave，该enclave可以验证enclave报告是在同一平台上生成的。用于平台内enclave认证的身份验证机制使用对称密钥系统，其中只有enclave验证报告结构，enclave硬件创建报告才能知道密钥，该密钥嵌入在硬件平台中。飞地报告包含以下数据：
- enclave中代码和数据的measurement。
- enclave初始化时显示的ISV证书中公钥的哈希值。
- 用户数据。
- 其他与安全性相关的状态信息（此处未描述）。
- 上述数据的签名块，可以由生成报告的同一平台进行验证。
此图是同一个平台上，俩个Enclave 之间互相认证的过程。
Application A and B can be same Application.
1. enclave B 发送它的 MRENCLAVE identity 给 enclave A
- Application B 可以从enclave B的enclave certificate中取出MRENCLAVE的值，
- Enclave B 提供一个接口来暴露这个值，该值通过创建带有随机MRENCLAVE目标measurement的报告来获取。
2. Enclave A 请求硬件使用从enclave B接收到的MRENCLAVE值来生成发往enclave B的报告结构。enclave A通过不受信任的应用程序将其报告传输到enclave B。
作为报告请求的一部分，enclave A也可以传入其选择的数据块，即用户数据。将用户数据包含在报告中提供了基本原语，该基本原语使受信任的通道可以在enclave 终止。
3. 接收到enclave A的报告后，enclave B要求硬件验证该报告，以确认enclave A与enclave B在同一平台上。enclave B随后可以通过使用刚收到的报告中的MRENCLAVE值为enclave A创建自己的报告来进行往复（reciprocate ）。enclave B向enclave A发送报告。
4. 然后，enclave A验证报告以确认enclave B与enclave A位于同一平台上。
远程（平台间）证明
enclave 的应用程序也可以要求enclave 生成报告，然后将该报告传递到平台服务以生成反映enclave 和平台状态的凭证类型。此凭据称为引用（quote）。然后可以将此报价传递给平台之外的实体，并使用Intel EPID签名验证技术进行验证。结果，CPU密钥永远不会直接暴露在平台外部。
引用中包含以下数据：
- enclave 中的代码和数据 的Measurement。
- enclave 初始化时显示的ISV证书中的公钥散列。
- enclave 的产品ID和安全版本号（SVN）。
- enclave 的属性，例如，enclave 是否以调试模式运行。
- enclave 包括在报告结构的数据部分中的用户数据。允许建立绑定到远程证明过程的安全通道，因此远程服务器可以将机密提供给已证明的实体。
- 对以上数据的签名块，由英特尔EPID组密钥签名
包含在报价单中的enclave 数据（MRENCLAVE，MRSIGNER，ISVPRODID，ISVSVN，ATTRIBUTES等）在证明过程结束时提供给远程服务提供商。这是服务提供商将其与可信任配置进行比较的数据，以决定是否将服务呈现给enclave 。
英特尔（R）增强的隐私ID（Intel（R）EPID）
当在平台的整个生命周期中使用小数字（ small number）密钥时，使用标准的非对称密码签名算法进行证明会引起众所周知的隐私问题。因为用于签署报价的密钥需要与执行报价操作的硬件相关联，所以它允许第三方合谋并跟踪用户访问过哪些站点。为了克服此问题，英特尔引入了一种匿名签名技术，该技术被称为英特尔®增强隐私ID（英特尔®EPID），用于对enclave引用进行签名。
英特尔EPID是一种组签名方案，该方案允许平台对对象进行加密签名，同时保留签名者的隐私。使用Intel EPID签名方案，组中的每个签名人都有自己的私钥来签名，但是验证者使用相同的组公钥来验证各个签名。因此，如果与同一方签署两个交易，则无法唯一标识用户，因为验证者无法检测到该组中的哪个成员签署了引用。对于Intel SGX，该组是支持Intel SGX的平台的集合。
引用enclave
英特尔提供的安全区，称为引用enclave（QE），会验证已创建到MRENCLAVE measurement 值的报告，然后使用特定于设备的非对称密钥（英特尔EPID密钥）对其进行转换和签名。此过程的输出称为引用，可以在平台外部进行验证。enclave系统运行时，只有QE可以访问Intel EPID密钥。因此，可以看到引用是从硬件本身发出的，但是CPU密钥永远不会暴露在平台外部.
远程认证过程
下图显示了一个示例，该示例说明了将应用程序分为两个组成部分的应用程序如何向具有挑战性的服务提供商提供证明，以从中获得一些增值服务.
远程证明示例图显示了规范enclave证明中涉及的基本步骤。此图中包括引用enclave（QE）。图中的步骤如下所述：
1.当应用程序需要平台外部的服务时，它首先与服务提供系统建立通信。服务提供商向应用程序发出挑战，以证明它确实在一个或多个enclave中运行其自身的必要组件。挑战本身包含一个用于活动目的的随机数。
2.应用程序向其应用区域请求报告，并向挑战者传递随机数。
3.安全区生成报告结构，并将此结构以及清单返回给应用程序。
a。清单包含报表的用户数据部分中包含的那些值。
b。清单可以包括随机数和短暂生成的公钥，供挑战者用于将秘密传达回enclave。
4.该报告将交付给引用区进行签名。
a。引用区对报告进行身份验证。
b。引用区域将报告正文转换为引用，并使用Intel EPID密钥对其进行签名。
5.引用区域返回请求的引用结构。
6.应用程序将引用结构和支持数据的任何关联清单返回给服务质询者。
7.质询者使用EPID公钥证书来验证引用上的签名，或者可以选择使用EPID验证服务来执行此功能。
8.质询者将引用中的enclave信息与可信配置进行比较，并且仅在enclave信息与可信配置匹配时才将服务提供给应用程序。挑战者可能会执行不同的信任策略，例如，仅信任通过测量enclave中的代码和数据而确定的enclave的特定版本，或信任具有特定enclave作者的特定产品ID的所有enclave，该特定enclave由特定enclave作者的公钥哈希标识ISV证书。信任策略必须包括enclave作者身份和属性检查。例如，永远不要以任何机密信任调试区域。
这些步骤作为示例说明远程实体可以证明enclave的一种可能方式。
上方步骤8中提到的受信任配置通常由enclave作者提供给服务提供商。服务提供商获取可信配置的机制不在远程证明的范围之内。一种可能的机制是，服务提供商在接受可信配置信息之前，利用现有的PKI基础结构来验证提供可信配置信息的实体的身份。
隐私
基于EPID名称name based （NB）的引用仅使平台使用Intel公钥加密。
NB签名（作为唯一ID）的恶意使用只有在服务提供商（SP）以某种方式串通时才会发生，例如，通过说谎识别或共享私钥。
- SP与证明服务之间的许可协议将禁止串通，因为Attestation Service通过不再验证证明来撤销有问题的SP会受到处罚。
NB引用被视为唯一标识符；注意：仅对单个服务提供商有意义的引用不足以放弃这一点。因此，在发送用户之前仍然需要用户选择加入。
- SP与证明服务之间的许可协议将要求与SP进行通信的SGX应用程序负责使用户选择退出，因为证明服务通过不再验证证明来撤销有问题的SP /应用。
- 选择加入必须“超出” EULA接受范围
区分正在运行的飞地实例
Intel SGX不提供直接机制（例如，通过自动生成的REPORT字段）来区分enclave的两个（或多个）运行实例。一个enclave的两个正在运行的实例无法通过仅在其REPORT中自动生成的数据来区分。为此，必须在用于在基础（underlying ）enclave建立信任的协议中添加随机数（nonce）。要建立对基础enclave的信任，请使用硬件的RDRAND功能，并确保将其提交（直接或间接通过加密哈希）作为enclave之间交换的REPORT中包含的userdata字段的一部分。有关RDRAND功能的更多信息，请参见随机数生成。
Secret Provisioning(秘密配置)
远程证明完成后，远程实体可以向enclave提供一些秘密。通常，秘密供应是通过安全通道进行的。安全通道的建立必须绑定到远程证明过程。否则，远程服务器可能会将机密提供给除已证明的encalve以外的其他实体。
证明流程中的步骤3.b引用了包含公共密钥以促进创建可信通道的能力。为此，在步骤3中，安全区可能希望先对服务器进行身份验证，以确保服务器即将接收到来自受信任实体的机密。例如，可以在安全区代码或初始化数据中嵌入一个已知的良好根证书，以使安全区可以验证服务器。一旦对服务器进行了身份验证，安全区域可以生成临时的公共/专用密钥对，并将公共密钥包括在报告的用户数据部分中。
在证明流程的第7步中验证了安全区之后，服务器可以生成加密密钥E，并使用安全区的公钥P对其进行加密，然后通过通道将P（E）发送给应用程序。通道本身不需要保护，因为机密已加密。
一旦应用程序接收到P（E），就可以将其传递到安全区域。然后，在安全区内部，它可以解密P（E），因为它拥有与此短暂的公钥/私钥对关联的私钥，因此现在质询者和安全区都拥有加密密钥E。
类似于证明，这不是可以在安全区和远程实体之间建立可信通道以交换秘密的唯一方法，仅是一个示例。
在提供任何秘密之前，远程证明的验证者必须检查签名者（MRSIGNER）的身份。实例化安全区时，英特尔SGX架构不会验证证书链。硬件仅验证飞地测量（MRENCLAVE），并将包含在飞地签名中的ISV公钥的哈希保存在MRSIGNER中。这意味着任何人都可以修改飞地并重新签名。同样，验证者还必须检查安全区属性，以防止例如将任何秘密提供给调试安全区。
一旦建立了安全通道，便可以将秘密提供给飞地。质询者现在可以使用密钥E加密机密S，然后将E（S）发送到应用程序，然后由应用程序将其传递到安全区域。现在，安全区可以使用E解密E（S），现在它拥有S。这很不方便，但是，每次安全区被实例化时，都要求安全区连接到远程实体以进行秘密配置。相反，飞地可以选择使用下一部分中讨论的密封技术将机密存储在非易失性存储中。即使将机密密封在飞地之外，对于任何人，除了密封它的飞地以外，其他任何人都无法访问，并且只能在密封它的平台上进行。
秘密配置是英特尔SGX技术支持的一项关键功能。它允许建造的围墙比当前的防篡改软件（TRS）更坚固。 TRS通常通过模糊性来提供安全性，例如，它会模糊可执行文件中的秘密，以试图使秘密免受未经授权的观察。但是，此方法仅使提取嵌入在TRS二进制文件中的秘密变得很耗时，但并非不可能。此外，它是开发人员使用的复杂技术，不建议其实践。
调试（选择加入）安全区注意事项/Debug (Opt-in) Enclave Considerations
调配到调试区域的数据不是秘密的。调试区域的内存不受硬件保护，因此可以按照英特尔SGX调试说明进行检查和修改。包含调试标志的安全区属性包含在提供安全区凭据的报告和报价中。为了保护提供给生产区域的所有机密，本地和远程实体必须在开发过程中检查区域的属性并交换特殊的调试机密，但不要将任何机密提供给调试区域。
处理飞地秘密
妥善密封秘密区域后，可以将其秘密地安全地存储在该区域的外部。但是，在某些情况下，需要将某些信息（例如印章钥匙）丢弃在飞地内部。飞地作者必须使用memset_s（）函数清除包含机密数据的任何变量。使用此函数可确保编译器不会优化此函数调用预期的对内存的写操作，从而确保清除机密数据。当秘密数据存储在动态分配的缓冲区中时，使用memset_s（）特别重要。释放此类缓冲区后，可以重新分配缓冲区，如果缓冲区中的先前内容未删除，则可能会泄漏到安全区域之外。 memset_s（）的实现未进行性能优化，因此使用memset（）可以初始化缓冲区和清除不包含机密数据的缓冲区。
封印
实例化安全区时，它通过将数据保持在安全区的边界内来为数据提供（机密性和完整性）保护。飞地开发人员应确定飞地数据和/或状态，这些数据和/或状态被认为是秘密的，并且可能需要在以下事件之间保留（飞地被破坏时）：
-
- *应用程序已在飞地中完成并关闭。
- *应用程序本身已关闭。
- *该平台处于休眠或关闭状态。
通常，在关闭安全区时，提供给安全区的秘密会丢失。但是，如果需要在这些事件之一期间保留机密数据以供将来在安全区域内使用，则必须在关闭安全区域之前将其存储在安全区域边界之外。为了保护和保存数据，已建立了一种机制，该机制允许安全区域软件检索该安全区域唯一的密钥。该密钥只能由该特定平台上的该飞地生成。 Enclave软件使用该密钥对平台上的数据进行加密或对平台上已有的数据进行解密。我们将这些加密和解密操作分别称为密封和解封，因为数据被加密密封到安全区域和平台
REF:
