龙蜥社区秘密计算推出的最新社区产品——服务化的近程证实服务中心 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 的证实能力实现的平安数据注入。

当初 OAAS 处于测试阶段。下面是 OAAS 的邀测群，大家如果退出邀测群提供本人的组织信息和社区账号的邮箱，都会给大家凋谢应用 OAAS 的测试的权限。欢送大家关注和扫码加群。谢谢大家。

更多视频回放、课件获取：

2023 龙蜥操作系统大会直播回放及技术 PPT上线啦，欢送点击下方链接观看~

回放链接：https://openanolis.cn/openanolisconference

技术 PPT ：关注龙蜥gz号【OpenAnolis 龙蜥】，回复“龙蜥课件”获取。

—— 完 ——