机密计算支线故事之Intel第12代处理器停止对SGX支持
近期相传已久关于Intel在新处理器中停止对SGX支持的消息得到了确认，第12代处理器（工作站/桌面/笔记本/嵌入式平台，不含服务器）将放弃所有SGX特性：
Intel官方的解释是处于市场的考虑而最终作出的决定，会有包括蓝光防盗版DRM在内的诸多应用受到影响。Intel SGX（software guard extension）是自从2015年发售的第6代处理器Skylake中支持的，其主要目的是为了更好的解决云计算环境下云厂商和租户信任的问题，这种方案被称为飞地（Enclave），SGX自诞生之日起就引起了众多争议，赛博堡垒的可信/机密计算方案中对于SGX的场景化方案一直持非常谨慎的态度，本文会探讨SGX本身的问题。
麻烦的根源：复杂性
Intel SGX是最复杂的飞地实现，Intel为了实现SGX从x86平台各个层面都做了大量的改动：
- 硬件层面，比如传输中硬编码MEE以实现一定程度抗击侵入式攻击
- 微码层面，实现特定指令
- 固件层面，大量使用Intel CSME中的代码模块，另外更换了Intel ME的基础架构
SGX基础描述
- SGX把paging交给了不受信的OS，这一点和BASTION是类似的，主OS可以evict操作。
- SGX使用Intel EPID来实现attestation，这个feature如果使用microcode实现过于复杂，目前评估预计是CSME中的code module作为privileged container被Intel私钥签名并且公钥是硬编码在自身中，EPID是remote attestation的重要功能。
- 除了EPID，SGX也使用其他CSME的code module比如iclsClient使用CLS(Capability Licensing Services)
Remote attestation
- Seal Secret和Provisioning secret存放在e-fuses中，Provisioning Secret由Intel Key Generation Facility生成烧写到CPU后保存于Intel xx service，Seal secret是在CPU内部生成的，理论上讲对Intel是不可知的。
- EGETKEY使用certificate-based identify( MRSIGNER, ISVPRODID, ISVSVN)和SGX实现版本(CPUSVN)得到Provisioning key，这样可以让Intel provisioning service验证Provisioning Enclave被Intel签名，provisioning service也能根据CPUSVN判断是否有漏洞从而拒绝通信。
- 当Provisioning Enclave获得Provisioning key后去跟Intel provisioning service通信并且验证自己后，service生成Attestation key给Provisioning Enclave，enclave使用Provisionging Seal key对AK进行加密然后保存。
- AK使用EPID密码系统，EPID作为group signature scheme为signer提供一定的匿名性，Intel key provisioning service是签发方，它会公布Group Public Key而会自己保存Master Issuing Key，在provisioning enclave向service验证自己后，service会生成一个EPID member private key作为AK然后执行EPID Join protocol去加入group，之后Quoting Enclave使用EPID MPK生成attestation signature。
技术风险：
- issued SIGSTRUCT被泄漏，攻击者可以使用SGX调试特性构建debugging provisiong或者Quoting enclave去修改代码，也可以获得128-bit provisiong key去和Intel service通信
K* of SGX
根据Intel专利的描述，SGX 的实现依赖于 CPU 电路的 global secret keys 的复杂 KDF 过程以及存放在 eFUSE 中，Chipworks报价$50-250k可以完整的提取Intel i5处理器的eFUSE，所以eFUSE内容是由一把master key( 专利中称为"global wrapping logic key")加密的。GWK用于加密一个用于重新生成CPU的EPID key的256-bit的信息和一把128-bit pre-seed key 0，eFUSE也包含了明文保存的128-bit pre-seed key 1和一个32-bit EPID group ID，GWK是硬编码到芯片电路中，所有的芯片生产厂都共享mask set，这样的流程增加了攻击成本，但也有被逆向的可能。
SGX也使用了PUF，用于在provisioning阶段为设备生成对称密钥，PUF key被GWK加密并且传输到key generation server，之后key generation server用PUB key加密芯片的fuse key然后传输给芯片，PUF key增加了获得chip fuse key的成本，攻击者必须同时攻陷provisioning stage。
ME也有一个eFUSE用于保存为fTPM提供的EPID key。CPU和ME之间通过DMI bus传输EPID key不安全，第一种方案是Provision enclave使用provisioning seal key加密DAK，这个方案假设ME是不可信的flash memeory，所以不能使用fTPM。另一种方案是使用key agreement protocol在DMI bus之间建立安全通信频道，ME fw可以用于存储DAK，也可以实现fTPM。
从头错到尾的威胁模型
Intel SGX从一开始就把物理机的拥有者（云厂商，系统管理员等）放进了威胁模型，技术的角度，SGX不信任操作系统和整个固件（除了CSME），但操作系统内核是通向“地下世界”的入口，老派黑客圈有一种说法”不要开地下世界的玩笑“，SGX的大部分漏洞利用的攻击都是基于有内核权限发起的，
靠谱的威胁模型不一定会让你打造出完备的防御方案，但至少是起点。
其他主要问题
* Intel SGX实现当中关于依赖底层固件的部分都是闭源的，这意味着要进行完整的审计代价极高。而SGX高度依赖于Intel CSME，关于CSME中上帝模式的问题可以参考赛博堡垒的Intel CSME风险评估。
* SGX 保护的应用的同时也可以用于保护恶意代码，这让恶意代码检测成为摆设。
* 直到2018 年12月Intel才向非大客户开放了基于SGX的第三方证明服务，从市场和生态的角度，这个决定或许晚了一点。
* SGX的Linux内核主线化进程缓慢，2016年4月，Intel向Linux内核社区提交了第一版SGX补丁，Linux内核社区认为有很多未解决的基础问题，包括ABI兼容性问题以及SGX作为飞地计算最核心的假设：如果Linux内核被攻陷，SGX可以保证应用不被攻击者干扰。即使这个前提是对的，那内核开发者的疑问则是：如果有恶意的飞地应用，那谁来保护内核？况且第一个前提在L1TF被曝光后已经被业界否定（虽然之前也有相关研究揭露但媒体并没有大规模报道），L1TF的曝光和区块链的退潮在2018年破除了不少人对SGX的银弹预期，一系列的问题导致Linux内核直到2021年初的v5.11才合并了SGX，其实那是个时候已经有不少厂商判断Intel大概率会停止SGX的支持。
* 市场的过度宣传
TDX的未来
机密计算行业最关注的问题是TDX的走向，从目前赛博堡垒得到的情报可以肯定的讲，TDX会持续在x86服务器处理器上存在。