安全利器！龙蜥推出机密计算远程证明服务—OAAS 诚邀广大用户测试

2024-02-20
北京
本文字数：5010 字
阅读完需：约 16 分钟

龙蜥社区机密计算推出的最新社区产品——服务化的远程证明服务中心 OAAS。OAAS 具有极高的安全性和灵活性，并在内部实现了策略引擎，旨在为使用可信执行环境 (TEE) 的用户提供一个安全高效的远程证明免部署解决方案，满足在各类机密计算应用场景下的核心信任需求。在2023 龙蜥操作系统大会上，龙蜥社区机密计算 SIG Maintainer 张家乐从背景、定位功能和使用方法、技术架构及应用场景和未来展望等 4 个方面全面介绍了 OAAS。以下为本次分享原文：

（图/龙蜥社区机密计算 SIG Maintainer 张家乐）

01 背景介绍

相信大家对于机密计算都比较熟悉了，它的本质上是通过硬件支持的可信执行环境对运行时的数据进行机密性和完整性的保护。对于现在的终端的使用用户和现有的云原生技术体系，机密计算技术底层的特殊性存在技术应用门槛高、部署复杂、用户不知道其功能的问题。龙蜥社区成立云原生机密计算 SIG（Special Interest Group），希望通过构建机密计算的底层基础设施的开源技术栈，降低机密计算的使用门槛，简化机密计算技术在云上的场景部署和应用，最终通过培养用户的心智拓展使用场景。在南向生态上积极和几家主流的芯片厂商建立紧密的合作关系，和合作方一起在上游社区推出一系列的组件级的开源软件。在龙蜥社区基于组件级的开源软件推出一系列解决方案或者社区产品。今天要重点介绍的 OAAS 就属于这一类，最终以上方案或者产品和社区伙伴共同打磨下具备产品级的安全能力，最终落地到共同的终端用户的实际场景中。

如果要在实际的落地场景中使用机密计算，归根结底是对业务的安全性有比较高的要求。这样一来，关键的问题就出现了，机密计算这种基于硬件的安全特性来提供的安全声明，怎么样向真正的用户证明安全属性是真正基于硬件的而不是软件模拟的，因此，龙蜥社区就引入了机密计算的远程证明技术。换言之，机密计算落地前提的必要条件是基于硬件的安全属性被真正的应用程序所有者感知和验证。关于如何去证明目标环境的安全属性是符合预期的，现在业界有一套通用的抽象标准，就是 RFC 9334 的这套标准，我们一般简称它为 RATS，叫 RATS 架构。这套标准它提供了一个对一般性的远程证明系统的体系结构和协议内容的中立化模型，而在最底层的硬件层面，现在几家主流芯片厂商的 TEE 平台都提供了一些原生的支持能力，比如英特尔的 DCAP PCK 密码学体系，AMD 的证书链以及 Arm Veraison 服务等等。

在实际的云原生机密计算的复杂场景下，仅仅有基本的原生软件支持很多时候是不够的。我们的伙伴和用户更希望看到一个中立化运营的、使用便捷的远程证明服务，来帮实际的终端用户解决技术门槛高、软件流程复杂和不同平台差异大的远程证明问题，并且对验证结果的信任做统一控制收口。

大家可以看到上图左边是直接在方案中集成原生远程证明体系，需要在 TEE 侧和依赖方侧部署很多特定于 TEE 类型的软件包和程序，在依赖方的本地运行复杂的证据验证流程，并且需要和硬件厂商进行交互以获得信任根验证素材，最后才能获得一个证明结果。在这个过程中，信任完全来自于对本地程序和硬件厂商。

而上图右边是使用一个服务化的远程证明系统，TEE 侧仅仅需要一个客户端，把证据发送给远程证服务，而依赖方侧则不需要任何额外的配置和部署，可以直接从远程证明服务拿到目标 TEE 的证明结果。在这个过程中，方案中集成的远程证明系统不再特定于 TEE 类型，而且流程简洁清晰，另外信任成本也解耦到了远程证明服务这里，服务的所有者对所有的信任输入做统一的收口控制。

02 OAAS 功能介绍

OAAS 的定位是一个社区提供的安全高效、通用可控的公开远程证明服务中心，以统一的形式兼容多种 TEE 类型。它的目标就是要简化远程证明在机密计算方案中的集成和部署，解决远程证明技术门槛高、软件流程复杂和平台差异性大的问题，并且能够对证明信任做收口控制。

在功能上，OAAS 不仅支持多平台 TEE 硬件报告的验证，还能自定义验证目标环境的固件和软件栈度量值，这得益于 OAAS 内部高度灵活可定制的验证策略引擎，而最终返回给调用者的证明结果是一个标准完备的结果报告令牌。

由于 OAAS 在机密计算方案中会扮演一个信任依赖的角色，因此这个服务自身的安全性也是我们的一个考虑重点。在服务实现上，我们使用海光 CSV 安全虚拟化来保护服务实例，并且能够支持真实性的自证明。同时，验证完成后返回给调用者的证明结果报告上会携带龙蜥社区的签名，并且服务程序会由机密计算 SIG 技术团队进行维护。最后，服务本身的核心功能模块代码都是在放在中立化的国际社区开源的，可以随时进行代码审计。

那么具体来说，在机密计算方案中使用和集成 OAAS，相比于直接集成 TEE 的原生远程证明软件配套，它的优势体现在以下四个方面。

首先，我们前面讲需求来源的时候也提到了，OAAS 它是一个服务化的远程证明体系，能够让方案中集成的远程证明相关的模块大大简化，也就是说方案使用者不用再自己去搭建和运行特定于硬件的远程证明程序，而只是在目标环境中访问一下龙蜥社区的这个服务，就可以直接拿到证明结果。

其次，在方案中使用 OAAS 可以做到对多种 TEE 的同时兼容，OAAS 本身在内部是把特定于 TEE 类型的验证逻辑进行了封装抽象，对外提供统一参数格式和统一调用接口，而输出的结果报告也是标准的统一格式。换句话说，对于 OAAS 的用户来说，远程证明系统下层特定于 TEE 平台的技术细节相当于是被抽象隐藏掉了。

另外，OAAS 内部基于 OPA 实现的策略引擎，让用户可以在基本的硬件真实性验证的基础上，通过编写和设置策略来细粒度的定制每一个证据字段的验证逻辑，同时还可以在验证中同时管理和控制多个策略。

最后，OAAS 作为一个服务化的远程证明验证中心，它相当于是在基本的硬件厂商背书的基础上做了一个信任收口，从原来的用户和硬件厂商的二方信任建立引入了一个中立化的第三方，提供了独立于特定硬件提供商的额外信任链条，在某些特殊的场景下，能够实现国内我们说的自主可控的系统安全认证。

对于社区用户来说，使用 OAAS 来进行远程证明是一个非常简单高效的操作，在这下图里把开始使用 OAAS 总结为四步快速开始。

首先我们需要访问 OAAS 的主页。点击创建实例按钮，在登陆社区帐号之后就可以一键创建出来自己的 OAAS 实例，并且拿到相应的实例访问地址。然后我们可以通过使用给 OAAS 实例设置自定义的 Attestation 策略，这是一个可选的步骤。在此之后需要在 TEE 内收集证明证据，这一步可以手动完成，也可以使用 OAAS 提供的自动化工具一键完成。最后只需要访问一下 OAAS 的认证端点发送证据，验证通过之后就可以拿到一个 JWT 格式的令牌，令牌的内容中就包含了远程证明结果。

可以看到在整个使用过程中，不需要用户做任何额外的环境配置和软件搭建，远程证明过程变得非常简单高效。

03 OAAS 技术架构

下面从技术的层面给大家分享一下 OAAS 内部的实现。

OAAS 本身的核心组件都是开源的，所以主要从整体架构、内部的策略引擎、最终认证令牌的格式和内容，这三个角度向大家详细介绍。

首先上图是 OAAS 实例在服务侧的一个整体的模块架构图。大家可以看到在实现上，我们把服务实例从内部划分为两个大的模块群，左边是 Web API Server，负责处理一些前端的业务逻辑，而右边是 Attestation 核心，负责执行真正涉及信任的证明验证逻辑。这样的划分有助于在部署的时候采取不同的安全保护级别。

OAAS 实例会向用户开放 HTTPS RESTful API，在需要对 TEE 执行 Attestation 时，访问 OAAS 的 API 提供收集的 TEE 证据，证据会转发到后端的核心模块进行验证。

在后端，我们通过统一接口插件化的机制把不同平台 TEE 证据报告的解析过程统一封装抽象掉，插件本身会负责识别和解析来自不同硬件厂商的 TEE 证据内容，并对特定于硬件平台的证据签名进行验证，而硬件厂商的密码学基础服务会为 TEE 插件池提供验证背书。在完成基本的硬件验证之后，会将证据解析为统一可读的格式，交给后端的 OPA 策略引擎进行细粒度的逻辑验证。而用户可以通过访问前端的 RESTful API 来对这里的验证策略进行自定义设置和管理，访问 API 的时候，OAAS 实例会验证用户的身份，以确保只有服务的 Owner 才能对策略进行修改。

后端的策略引擎验证完成后，会将策略引擎输出的报告和解析后的证据内容打包为一个令牌，通过 HTTPS 响应返回给 TEE，这个令牌表征了 OAAS 对 TEE 可信度的认证结果。在格式上，这个令牌我们采用了 JWT 格式的标准令牌，包含了 OpenAnolis 密钥签名的密码学保护。

我们前面一再提到，OAAS 内置了一个高度灵活可定制的策略引擎验证环节，下图就是策略引擎模块的技术架构。解释策略和执行验证逻辑的核心我们是采用了 CNCF 的毕业开源项目 Open Policy Agent 来实现。OPA 是一种强大灵活的策略引擎实现，它定义的 Rego 策略语法能够让用户根据需求编写任意复杂的验证判断逻辑，并且 Rego 它有很多生态模块能够实现一些功能性的逻辑处理。

在输入端，OAAS 会把经过 TEE 验证插件处理和解析之后的序列化的证据内容和用户指定的本次验证的策略列表一同交付给 OPA 核心，这里序列化的证据内容 OAAS 定义了一种简单统一的 JSON 格式。

在接收到输入之后，模块会根据输入中指定的本次验证所需求的策略 ID，从策略存储表中检索对应的策略并加载到 OPA 核心中。同时最上面的参考值提供服务，会从一些上游的软件供应链安全系统订阅获得某些特殊证据字段的可信参考值，例如 kernel 和固件的度量值，然后提供给 OPA 核心。最后 OPA 核心根据策略执行验证逻辑，并输出一份评估报告，这份评估报告会和输入中的序列化证据内容一起打包签名成一个 JWT 令牌，作为最终的输出结果。

下图是 OAAS 的认证结果令牌的详细内容，由于它是一个 JWT 格式的标准令牌，因此左边大家可以看到它包含了 JWT 所要求的一些基本的安全字段，比如过期时间、生效时间、防重放随机数等等。需要关注的是下面用红框标出的自定义区域中填充的三项内容。

首先是证明评估报告字段。这是一个包含多个结构体项的 JSON 数组，每一项分别对应着一个特定的策略验证结果，比如输入中指定这次验证使用三个不同的策略，那这里就会有三项。结构体项内部的字段指明了策略的 ID 和这个策略的验证结果，也就是 true or false，另外还包含了 OPA 的输出报告，用户可以通过合适的策略编写来控制这里输出报告的具体格式和内容。

其次是 TCB Status 字段。这里就是策略引擎拿到的输入，也就是 TEE 验证插件解析和处理之后的序列化证据内容。

最后是一个 JWK 格式的 RSA 公钥。这个公钥可以用来验证令牌最后的 RS384 签名，值得一提的是，在 JWK 的 x5u 字段上，指向了这个公钥对应的证书链下载地址，这个证书链的根证书就是龙蜥社区的证书，因此这里的签名实际上是表征了龙蜥社区 OAAS 的背书。

04 应用场景 &未来展望

总体来说，OAAS 在云上机密计算的应用场景非常广泛。首先这套系统可以为用户提供各种云上机密计算实例的灵活高效的自主安全验证，能够很好的符合机密计算的安全目标，也就是在不相信云厂商的前提下提供信任建立的渠道，并且能够提供高效免部署的友好的使用体感。

其次是借助 OAAS 的认证令牌验证和令牌中包含的 TEE 密钥，我们可以实现向 TEE 中可信并且高效的注入秘密数据，比如镜像或者磁盘的解密密钥，以及一些证书和安全策略。

最后就是在未来随着机密计算应用规模增大，OAAS 可以作为异构 TEE 节点分布式互联场景下起到信任派发中心的作用，从而支持基于 OAAS 的异构 TEE 机密互联。

上图是一个典型的使用 OAAS 向 TEE 实例安全的进行数据注入的场景案例。在这个案例中，大家可以看到我们的 OAAS 服务在左下角，通过前面提到的四步快速开始，用户创建出自己的 OAAS 实例。

在方案流程上，首先是 TEE 内的 OAAS client 访问 OAAS 实例执行证明获得令牌，然后 TEE 将令牌提供给机密数据存储服务器，存储服务器通过验证令牌，就可以知道这个 TEE 的真实性和安全性是经过 OAAS 验证和担保的，因此可以将机密数据通过加密信道返回给 TEE。这就是借助 OAAS 的证明能力实现的安全数据注入。