AWS Nitro Enclaves安全笔记：攻击面分析
在云应用安全竞赛中，AWS Nitro Enclaves已成为隔离敏感工作负载的利器。但能力越大责任越大——潜在的安全陷阱也随之而来。作为机密计算安全领域的先驱，Trail of Bits团队深入研究了AWS Nitro Enclaves的攻击面，发现即使在这些强化环境中仍存在可能被攻陷的漏洞。
基础威胁模型
首先建立基础威胁模型。Enclave可能遭受来自父级Amazon EC2实例的攻击——这是唯一能直接访问enclave的组件。在enclave攻击场景中，我们应假设父实例的内核（包括其nitro_enclaves驱动）已被攻击者控制。来自实例的DoS攻击并不构成真正威胁，因为父实例随时可以关闭其enclaves。
如果EC2实例转发来自互联网的用户流量，那么对其enclaves的攻击可能来自该方向，并可能涉及所有常见攻击向量（业务逻辑、内存破坏、密码学等）。反方向来看，用户可能遭受恶意EC2实例的伪装攻击。
在信任域方面，enclave应被视为单一信任域。Enclave运行标准Linux系统，理论上可以利用其访问控制特性在内部"划分界限"。但这种做法毫无意义——通过供应链攻击等方式获取enclave内部任何组件的敌对访问权，都将削弱其强隔离和认证的价值。因此，单个enclave组件的沦陷应视为整个enclave的彻底失陷。
最后，hypervisor是被信任的——我们必须假设其行为正确无恶意。
虚拟套接字(Vsocks)
Enclave的主要入口是本地虚拟套接字(vsock)。只有父EC2实例能使用该套接字。Vsock由hypervisor管理——hypervisor为父EC2实例和enclave内核提供/dev/vsock设备节点。
标准套接字相关问题是要重点关注的。开发enclave时需考虑以下方面：
- 是否采用多线程异步接受连接？否则单个用户可能长时间阻塞其他用户访问
- 是否设置连接超时？否则单个用户可能永久占用套接字
- 多线程使用时状态同步是否正确实现？
- 错误处理是否得当？特别是recv方法的读取逻辑需要谨慎处理
随机熵源管理
Enclave必须获取安全随机数。“安全"在此语境下意味着攻击者不知道或无法控制生成随机数据的所有熵源。我们推荐配置enclave显式检查当前RNG(rng_current)是否为nsm-hwrng，确保AWS Nitro RNG已成功注册并被内核定期用于添加熵。
侧信道防护
应用级时序侧信道攻击对enclave构成威胁，就像对其他应用一样。运行在enclave内的应用必须以恒定时间处理机密数据。来自父EC2实例的攻击可以使用近乎系统时钟精度的时间测量，因此不要指望网络抖动能缓解问题。
CPU内存侧信道
最主要的侧信道攻击类型涉及CPU内存。在最坏情况下，enclave会与父EC2实例共享L3缓存。但L3缓存是否真能用于侧信道攻击尚有争议。如果非常关注L3缓存侧信道攻击，可以让enclave运行在完整NUMA节点上。
内存管理
Enclave内存从父EC2实例划分出来。开发者只需关注DoS攻击风险。应用应限制外部用户可存储的数据量，否则单个用户可能耗尽enclave所有可用内存。
时间源安全
较不常见的安全问题来源是enclave的时间源。建议采取三项措施：
- 确保current_clocksource设置为kvm-clock
- 启用精确时间协议(PTP)
- 安全关键功能使用Unix时间
认证实践
加密认证是终端用户的信任来源。除AWS文档所述内容外，开发者还需注意：
- 强制最小nonce长度
- 检查认证中的时间戳
- 避免使用RSA作为public_key特性
NSM驱动安全
开发者需注意应用程序可能误用驱动程序或库。关键建议包括：
- 正确区分锁定与未锁定PCR
- 检查PCR锁定状态属性
- 正确处理CBOR编码
- 避免直接使用nsm_get_random方法
核心要点
- 将enclave视为单一信任域，实施端到端安全
- 通过合理CPU分配和恒定时间处理缓解侧信道风险
- 运行时验证enclave熵源
- 在enclave内使用正确时间源
- 实施健壮的认证实践
通过实施本文建议——从强化虚拟套接字到验证随机熵源——您可以显著降低enclave工作负载被攻陷的风险，为机密计算塑造更安全的未来。