阿里云 Confidential AI 最佳实践
内容介绍:
1. Confidential AI 技术背景与挑战
2. Confidential AI 技术架构与应用场景
3. Confidential AI 技术实践与未来展望
今天,我演讲的主题是“阿里云 Confidential AI 最佳实践”,副标题是经过深思熟虑后添加的。在准备这个 PPT 和标题时,我感慨很多。今年1月至9月,我的团队一直在进行 Confidential AI 产品的技术研发。该产品背后的技术,实际上源于我们两年前在国际机密容器( Confidential containers ,简称 coco )社区贡献的众多技术。我们将这些技术巧妙地集成和融合,形成了今天的 Confidential AI 最佳实践。这实际上是我们在两年前就积累的技术储备。在准备演讲材料时,我使用了三年前(2021年年底)为实习生确定研发预研方向时的成果。因此,今天分享的材料中的技术也经过了多年的实践。也正因为这项技术较为复杂,至今仍属于前沿技术,所以我今天将其分享给大家。
01. Confidential AI 技术背景与挑战
既然今天讨论的是 Confidential AI ,那么它肯定与 AI 安全主题相关。作为云计算服务提供商,我们非常关注阿里云今年推出的 AI 基础设施如何帮助用户上云并进行 AI 计算。但在上云过程中,尤其是在使用 AI 工作负载时,用户对阿里云当前的 AI 计算基础设施安全也提出了新的挑战。要使 AI 研发基础设施中的模型,尤其是推理模型正常运行,实际上需要多个角色参与。首先是模型提供者,他需要将模型上云。
在上云过程中,隐私保护和知识产权问题尤为突出,模型上云可能导致数据出域,而模型本身就是敏感数据,数据出域存在合规风险,且传统技术如落盘加密无法完全覆盖。落盘加密技术仅在数据落盘时使用云托管的密钥进行加密,当需要读取数据时,再从存储中用密钥解密。然而,在加解密过程中,密钥并非由用户控制,理论上谁拥有密钥,就能看到数据的明文。虽然整个过程是安全的,但存在信任问题。以上是我们明确了模型知识产权保护的风险。
其次,例如,容器不属于推理服务,而是工作负载的一部分。工作负载提供者将推理服务部署到容器中,推理服务本身是代码和容器镜像的结合体.如果代码和容器镜像没有额外的安全保护,很容易被篡改。如果推理服务的代码存在漏洞或后门,可能会记录、收集推理过程中的数据并用于训练,这可能违反模型提供者和使用者的隐私保护要求,这是第二个风险。
第三,推理服务启动后,模型使用者需要调用其 REST API 或 Open API 进行 AIGC 交互。在使用 AI 模型时,推理提示词本身也是一种敏感数据。例如,有些用户可能使用 AIGC 分析律师事务所的法律文书,法律文书包含被告的一些敏感数据。用户非常担心这些隐私数据一旦上传到云端,如果不慎泄露,会造成严重后果。因此,推理提示词的隐私保护是模型使用者的担忧之一。
最后, AI 基础设施包含众多服务和计算资源,将所有敏感数据集中在一个平台进行计算时,如何保障整个平台的安全性也是一个潜在风险。因此, AI 大模型上云时,实际上面临许多以前未曾遇到的新挑战。这些新挑战之所以被称为“新”,并非因为过去的安全技术不足,而是因为它们未能为当今高附加值数据提供信任保护,即我们传统所说的“可信”。今天稍后,我将深入剖析“可信”这一概念在大模型场景或精密计算场景中的理解。
我们目前正在商业化一套 Confidential AI 技术。这张架构图已经经过了大幅精简,但即便如此,依然较为复杂,因此我将从实际应用场景角度进行阐述,而非深入技术细节。例如,我们有一个客户,其敏感数据来源于端侧设备,使用这些设备的用户可能会输入一些敏感的提示词。刚才我已举过这个例子。这些提示词从端侧进行 AI 推理,但由于端侧算力有限,只能运行一些小模型。
因此,如今像苹果的 Apple Intelligence 以及其他手机厂商的 AI 应用和智能终端应用,都遵循一个逻辑:如果推理不适合在端侧小模型上计算,就需要将推理请求发送至云端进行计算。换言之,以往的隐私防护和安全隐私能力主要依赖于端侧的硬件芯片,如 secure boot 等硬件安全机制,以及手机上的一些全自动功能。如今,由于存在数据出域、出手机的需求,客户希望云端的推理服务和推理基础设施能达到与端侧相当的安全能力,实现端云一体的 AI 推理安全和隐私保护。这样,端侧才能放心地将数据以密态形式出域、进行密态计算,同时符合合规要求。因此,端侧用户希望云端具备同等强大的安全能力,保障端云一体推理的安全水位一致。
但这里存在一个显著问题:许多端侧厂商不像苹果那样既做端又做云,他们没有云的能力,自建 IDC 成本高且复杂。
因此,如何让成熟的云基础设施为他们提供一个可控的计算资源和平台,同时具备强大的端侧安全和隐私保护能力,成为亟待解决的问题。这就是我们这些公有云厂商在 AI 场景下面临的一个尖锐问题.因此,在这个方案中,我们设计了一套端到端的密态计算、密态存储和密态网络传输机制,确保模型使用者的推理提示词在需要上云时,通过我们的 Confidential AI ,首先利用端侧与云端的可信网关实现端到云的安全传输。这一过程借助远程证明技术,保证服务器端,即右侧推理服务端的执行环境安全可信,这是第一个场景。
另一个场景则是反过来,有些模型提供者训练模型后,希望数据流通,也即数据要素可信流通,但他们不想因分享模型而丧失所有权,而是希望模型的使用权可以分享,但又不想丧失知识产权保护。因此,针对模型上云,我们的方案很简单:不依赖存储服务的多盘加密,而是采用端侧的落盘加密,将密态模型数据上云存储。数据上云后,必须以密文形式存储,而在用于计算前需解密,因此,我们在中间的精密计算可行执行环境中进行解密和计算。无论是模型使用者还是模型提供者的安全诉求,最终的信任根和信任安全机制的保障都依赖于最中间的可信执行环境,而可信执行环境的安全性背后则依赖于精密计算技术。由于时间有限,我们无法再单独展开精密计算,因为这足以成为一个新的话题,所以今天我们只能粗略地利用 Confidential AI 框架实现真正的端云一体 AI 隐私保护。
我提出三个观点,不再展开。
第一,这套框架表面上看似能处理 AI 数据,但一般的敏感数据上云,无论是存储还是网络传输,其实也可以使用这套架构。
第二,这个产品的能力不一定非要绑定精密计算,因为机密计算依赖硬件,需要 CPU、GPU 的 TE 能力。
但如果有些用户想实施这套方案,却又不想依赖硬件,可以让中间的执行环境,即精密计算实力,换成普通的 VM 实力。虽然信任度会下降一些,但相比今天完全不设防的状态,整套架构和流程其实也更加安全。
02. Confidential AI 技术架构与应用场景
然后我来介绍一下阿里云的产品。无论是 IaaS 还是 PaaS ,阿里云都已经在使用可能的商业化状态技术。 IaaS 解决方案强调为用户提供对资源和云平台的控制权。最简单的 IaaS 形态是用户购买一个实例,然后可以通过 SSA 执行任何命令并注册权限。
PaaS 的用法一般像我们现在做的 ENS 推理服务。用户购买实例后,我们为其创建并启动推理服务,使其立即可用。用户可以直接在浏览器或客户端访问该推理服务,这种服务属于 PaaS 形态,即 ENS 产品。无论是 IaaS 还是 PaaS形态,我们今年12月底都将推出相应的产品邀请测试,届时感兴趣的朋友可以联系我,我会提供一些邀请码。
此外,我们之前也提到过,从开源社区的技术预研到产品研发,我们认为这个领域仍处于初级阶段,尤其是精密计算和 AI 采用了一种新的模式来实现端到端的保护。我们认为,在合规方面,这件事也具有重要意义。如果没有合规性的推动,仅凭大家跟风技术,认为这个东西有用,是无法长久发展的,因此,除了与南湖中科院研究所和赛迪等研究机构共同发布了一篇关于传统 AI 的白皮书,我们计划在下半年以及明年第一季度,继续在其他相关合规领域开展合作,争取将组合 AI 技术从开源阶段推进到产品阶段,最终形成行业或标准上的定义。
我准备了一个演示,展示了 IaaS 型 EGS 产品实例如何使用竞争性AI 。用户通过SSZ登录并部署使用 EGS ,接下来我将进行展示。让我暂停一下,因为这个演示录制得较快,可能有些细节大家会看不太清楚。首先,这里展示了这样一个场景:一个人购买了 EGS 机密虚拟机实例后,从自己的工作控制台登录自己的终端 SSI ,连接到远程的实例终端。因此,下面显示的是他 EGS 实例上的 shell 。看来这个暂停不起作用,暂停后它会自动翻页,所以我无法在演示中边暂停边讲解,只能这样了,我再试一次。如果还是不行,那就没办法了。那么,我会分享这个演示和 PPT ,大家可以之后再观看,有问题也可以联系我。
上半部分主要介绍了传统 A I的一些内容,由于时间有限,未能详细展开其中的许多机密计算细节。但我认为有必要将今天会议的主题——供应链安全——与我们的讨论相对应。精密计算需要向用户展示并证明推理过程中的环境是可信的。如何实现这种可信性呢?我们的答案是,在精密计算中使用远程证明技术。然而,远程证明技术究竟验证了什么?如何让用户从技术上相信推理提示词和模型数据最终是在一个可信任的执行环境中被使用和消费,而这个环境不存在后门,不会记录或窃取敏感数据?这些问题才是用户真正关心的。然而,信任和可信的问题其实早在上一个十年甚至二十年前就应该得到解决,但至今仍未彻底解决。如今,这个问题留给了机密计算,也留给了我们在进行传统AI研究时需要解决。因此,我们对此进行了一些思考,并对这个问题进行了剖析。
首先,图的左侧展示的是我们今天在云上看到的一个经过精简的垂直计算站。在这个计算站中,我们可以看到,今天的云服务模式有三种,或者说不止三种,我仅列举了典型的 IaaS 、PaaS 和 FaaS 。每种服务形态都有一个共享的职责边界。边界以下的部分由云服务提供商负责,而边界以上的运维和安全维护则由用户承担。尤其是相邻的两个层面,有时可能由两个角色共同承担。这里的问题其实非常明确。就是我们今天将这里标记为 TDX ,但所有今天的精密虚拟机形态的 TE 都位于这个边界,即黄色边界,这个边界就是用户进行推理的执行环境边界。由于它与现有的几种云服务模式重叠,用户需要相信这个执行环境。
这个执行环境中有一些组件不是用户自己部署的,而是云服务提供商为了满足右侧的三种服务模式而必须替用户部署的。但是,从信任的角度来看,这些由云服务提供商部署的组件相当于侵入了用户的信任边界,因此用户自然会对这些非自己部署的组件存在信任问题。
例如,用户购买了一个 EGS 实例,该实例使用的 Guest 固件由云服务提供商提供,目前没有云服务提供商允许用户部署自己的 Guest 固件。但如果这个 Guest 固件中存在后门,该如何应对?如果有懂技术的客户提出这个问题,我们该如何回答?他们可能会质疑:你的 Guest 固件是否具有特权或后门,最终目的是窃取我机密虚拟机中的数据、操作系统容器等。因此,我们认为,当前精密计算的信任边界与现有服务模式在信任方面存在一些亟待解决的问题。
接下来,我们将探讨精密计算远程证明的过程,分析其能解决哪些问题,以及是否能够一步到位地解决之前提到的问题。让我们来看一下远程证明的过程。首先,以 TDX guest 为例, TDX attester 生成一个远程证明报告,即 TDX Quote 。 这个远程证明报告需要发送给Attestation Service 远程证明服务进行验证。验证这个报告并非仅凭一个报告输入就能完成。它还需要许多额外的辅助输入,例如背书信息 Collaterals 和参考值信息,以验证报告中声明的制品组件的哈希值是否符合预期,是否可信。需要提供参考值,也就是所谓的“黄金值”。
另外,还需要一个用户定义的验证策略。例如,我要求远程证明通过的条件是 kernel 的哈希值等于 A ,且引入 RD 的函数等于 B,以及其他一些逻辑条件。这就是用户定义的策略。除此之外,今天我将重点介绍一个“ prevents 出入信息”。例如,我们之前就设想,能否通过“ in total ”这种方式,作为供应链所有者向参考知识提供者提供一个“ province ”信息,然后利用这个出库信息来辅助生成参考值. 后面的具体细节我们也会详细讲解。当然,虽然整个架构很早就已经设计好了,但在实际实施过程中仍有很多工作需要完成。目前,我们这套架构中,许多工作(绿色部分)已经在开源社区完成并投入生产,而其他部分(黄色部分)仍在开源社区孵化中。
03. Confidential AI 技术实践与未来展望
从供应链的角度来看,远程证明报告中一个制品具体包含了哪些内容?从技术角度来看,我们称之为度量值。也就是说,在真正要被验证的执行环境中,究竟验证了什么,度量了什么,哪些内容需要进行比较验证?首先,刚才提到的远程证明 Quote 是一个复杂的数据结构,其中的信任和验证关系我就不详细展开了,这个月的动态效果我也跳过了。这就是经过硬件签名的远程证明报告。
同时,我们还有一组Event Log ,因为在远程证明过程中生成之前一定进行了动态度量,这有点类似于 TPM 的 PCI extend 操作。为了进行细粒度的 Event Log 验证,需要针对每个制品生成细粒度的验证 Event Log ,因此这里包括 kernel、 Commandline 、 Initrd 和 Roots 等。甚至在容器场景中, Kata-agent 以及我们在精密信息中放置的远程证明Attestation-agent 组件等都需要进行动态度量,生成 Event Log 甚至应用。所有这些内容都会随着远程证明请求发送给远程证明服务。所有这些信息统称为度量值。
度量值可能包括硬件方面的,如 TDS model 的可信根,也可能包括静态的 Guest 固件度量值,以及一组动态加载的动态度量制品等。所有这些度量值会随着远程证明请求发送过来,然后远程证明服务需要与一组参考值进行比较。因此,远程证明服务的任务是彻底验证一个环境,确保这些组件符合预期,为此需要收集所有相关信息并进行验证。
从远程证明服务的角度来看,其核心任务是将参考值与度量值进行比较。刚才已经详细介绍了度量值,那么我们准备如何处理参考值呢?如果让用户手动编写策略并在其中指定参考值,这几乎是不可能的。这就是过去可信远程证明难以实现的原因之一:如何编写这些参考值?例如,一个 Kernel 的哈希值可能因为管理员的操作或 RPM 更新而改变。如果远程证明策略中的参考值没有及时更新为新的哈希值,远程证明就会失败。失败后,我们无法判断是人为误报运维导致的,还是真正的安全事故,例如攻击者入侵系统并替换了 kernel 二进制文件。
因此,这些问题需要通过工程化和自动化机制来解决。但在解决之前,我们是否有更好的方法?我们提供了两种思路。第一种是结合供应链的源码信息,即谷歌的 source provenance 。其格式大致如下:以一个应用为例,收集该应用来自哪个源码仓库、其分支以及源码的构建方式等信息。
第二种方式是为用户提供一个可重复构建的Docker 环境。在这个环境中,所有源码的下载方式、编译步骤以及所有上下文信息都被包含在内。我们利用这个 Docker 环境,一方面自己构建这些二进制文件,并将其发布部署到机密信息运行时的那些banner 中。因此,我们生成二进制文件的值和控制构建,并将其提供给用户,使用户能够使用可重复构建环境,利用源码信息从源码仓库拉取源码,自行编译出二进制文件,生成二进制文件的参考值,并与我们提供的值进行比较,以确保二者完全一致。
我们利用这种用户可控的可持续性构建环境来生成参考值。这种方法对用户来说具有很高的可信度。然后另一种方式是,不可避免地,机密虚拟机中可能运行了许多内容,其中一些内容无法开源,因此无法提供给用户进行可视化构建。在这种情况下,可以使用供应链所有者签发的数字签名,通过 province 签名来解决。因此,我们无法实现从二进制文件到源码的映射,因为可重复构建相当于建立了二进制文件哈希值与源码的映射关系。但如果无法开源,至少我们有供应链所有者对该组件可信度的背书。
如果将刚才提到的所有技术串联起来,我们可以定义一个名为 VBDA的架构。例如,从我们的构建流水线 DevSecOps 出发,结合一些供应链技术作为源头。一方面,可以生成并发布 Provenance 信息到BPDS 系统中。一些下游的 RVPS 组件实现对该服务的订阅。因此,一旦流水线发布新产品, Provenance 信息会自动发布, RVPS 组件通过订阅模式下载并自动处理 Provenance 信息,通过 subject owner 分析或可重复构建生成参考值,并将其注入到远程证明服务中。
这样,用户就不需要手动编写远程证明服务策略中的参考值了。同时,该流水线还会自动生成制品,并自动将其部署到精密计算 CVMTE 环境中运行。最后,所有数据流在中间的 Relying party 中得到验证和交汇,完成基于软件供应链的 Provenance 自动分发远程证明体系。最终,通过这种方式和代码透明度,解决了我们最初的问题:如何让用户相信系统中的组件没有后门。我们的答案是:我们无法直接证明,但通过远程证明技术尽可能全面地度量出度量值。但是,您只能看到一堆哈希值,而对应的源码是未知的。我们通过可重复构建或供应链的方式来解决这个问题。这些源代码都存储在可重复构建环境中,理论上具备可审计能力。
有人说,不可能有认真的审计。没错,这就是威慑能力。源码已经放在那里了,理论上会有人去审计或使用工具进行审计。如果审计发现问题,那么提供这套源码的 wander ,你的成分是什么,对吧?因此,我们利用这种威慑能力来构建。
最后,我再做个广告。我还有一个身份,是龙蜥社区云原生机密计算的负责人。我们的特点是不在龙蜥社区 Kitty 上放置任何仓库。因为我们的所有开源方案都是直接贡献到上游国际社区的,所以我们的工作都是从国际社区获取贡献,并适配到龙蜥社区。今年,我们最重要的工作之一是将 Confidential AI 方案从商业化转为开源,预计将于一月份在龙蜥社区发布。
另外,在机密计算方面,刚才与一些同事交流时也提到,机密计算技术过于复杂,难以使用。我已经从事这项工作五年了,也有同样的感受。因此,我们启动了一个名为 shelter 的新预研项目。如果有机会,我会在新的会议中与大家分享。这是一项比较前沿的技术,能够大幅降低当前机密计算的使用成本。