零知识证明 (ZKP) 是一种通用的密码学算法,为机密数据的计算提供强大的隐私和完整性保证。例如,它们已被用于实现匿名凭证,并作为更复杂应用程序(如电子投票和去中心化金融)的构建块。
机密计算 (CC) 同样提供隐私和完整性保证,但遵循不同的基于系统的方法:机密数据的计算在配备硬件机制的处理器内部执行,这些硬件机制可以将计算与平台的其余部分隔离,并测量其代码。由此产生的认证报告与密码学证明具有相同的目的:它们允许远程方验证计算是否已正确执行,而无需泄露其机密数据。为了便于与 ZKP 进行比较,基于硬件的认证报告被称为机密计算证明 (CCP)。这并不表示它们是完美的数学证明,或者可以与 ZKP 互换;在这两种情况下,论证或证据可能比证明更准确,但不太常用。
本文试图关联 ZKP 和 CCP 的概念。这是一项具有挑战性的任务,因为它们是由不同的社区在非常不同的信任假设下开发的,并且两者都在快速进步并探索新的用例。本文首先描述如何使用 CCP 提供类似于 ZKP 的功能。然后,它描述了它们在安全性、性能、可用性和可扩展性方面提供的权衡。文章还通过一个实际用例来说明它们的应用,其中两种方法都适用。这种并排比较旨在促进 ZKP 和 CC 专家之间的讨论,并对那些考虑实际部署它们的人有所帮助。
假设 Alice 正在计划一个梦想假期,并想租一艘豪华帆船。Bob 有一艘帆船想要出租,但他有具体的要求:潜在的租户必须至少 30 岁,持有合适的航海执照,有足够的资金支付租金,并且已经获得保险或有能力自保。Alice 符合 Bob 的所有要求,但她不想透露具体细节。她担心因身份而受到歧视,并且不想透露她的资产来自保这艘昂贵的船。
像这样的场景并不新鲜。五十年前,唯一可用的方法是可信第三方 (TTP)。只要 Alice 信任代理人维护她的隐私,Bob 信任代理人执行必要的验证并为 Alice 的凭证担保,托管代理人就可以充当 TTP。
四十年前,引入了零知识协议,通过用数学假设取代 TTP,使得这种“证明”得以实现。自那时以来,我们对 ZKP 的理解不断加深,其功能不断扩展,并且开发了更高效的实例化。然而,ZKP 过程通常仍然复杂且繁琐,并且支持 Alice 租船等场景的基础设施根本不存在。
与此同时,硬件基础设施得到了改进,现在是重新审视现代版本的 TTP 是否可以在某些场景中可行的好时机。具体而言,现在有各种可信执行环境 (TEE) 可用,它们有可能通过应用不同的假设,更轻松、更高效地解决 Alice 的租船需求。例如,云提供商可能会提供 Alice 和 Bob 可以使用的 TEE 服务。Bob 的要求可以编码到一个程序中,Alice 可以检查该程序。如果 Alice 和 Bob 愿意接受 TEE 的假设,他们甚至可以在云提供商不知情的情况下执行他们的协议。
TEE 并非适用于所有证明应用。它们的信任假设与密码学 ZKP 所需的信任假设不同;表 1 的并排比较中描述了许多其他权衡。然而,在某些情况下,TEE 可能提供有吸引力的替代方案。为此,本文介绍了 CCP,并探讨了它们作为证明系统的特性。
首先,让我们根据现有密码学理想功能,指定证明的含义,而不管其实现方式如何。考虑双方,证明者和验证者,他们就感兴趣的属性达成一致,该属性表示为一个纯布尔函数,由公共输入(定义属性的实例)和私有输入(为该实例提供证据)参数化。
给定实例和证据,使得属性成立(即,布尔函数返回“true”),证明者可以生成证明,以说服验证者它知道该实例的一些证据,而无需向验证者泄露其证据。
一个证明系统是健全的,当任何人在不知道有效证据的情况下都无法伪造任何实例的证明。当证明不产生关于证明者使用的证据的任何信息时(除了它们满足实例这一事实之外),它是零知识的。这里的重点是非交互式、普遍可验证的证明,这意味着证明者在不与验证者通信的情况下生成证明,并且任何一方都可以在给定属性实例的情况下验证证明。
直观地说,该属性可以描述一个谜题,证据可以描述一个解决方案,而证明可以使一方说服其他人,它已经解决了这个谜题,而无需泄露其解决方案。
例如,公共输入可以包括哈希值、数据库查询及其结果;私有输入可以包括数据库的全部内容;该函数可以验证 (1) 哈希值是否是数据库的密码学摘要;以及 (2) 在此数据库上评估查询是否产生此结果。验证者可以使用哈希值来验证数据库(例如,它可以由可信方给出或签名),并确保同一数据库用于回答一系列查询。
此示例说明了证明的两个常见动机。
• 证明者的隐私。 感谢零知识,证明者可以精确控制其泄露关于数据库的哪些信息,例如授权其执行和证明的一系列查询。证明者可以确信,证明不会泄露关于数据库的任何信息,超出从查询响应中可以了解到的内容。
• 验证者的完整性和性能。 只有证明者需要运行计算并维护可能很大的数据库。相比之下,验证者仅在其关心的输入、输出和证明上操作,这可能要简单得多。这种形式的委托对于能力有限的验证者特别有用,即使隐私不是必需的。
该示例还表明,许多属性在其定义中已经涉及某种形式的密码学。值得注意的是,公共输入通常包括对私有数据的密码学承诺,例如,可用于关联共享某些私有状态的多个证明——此处为数据库的整个状态。
关于 ZKP 的定义性论文发表于 1985 年。6 不久之后引入的非交互式 ZKP 与数字签名密切相关。4 实际上,一些 ZKP(如 Schnorr 证明)产生了实用的签名方案,如 EdDSA(Edwards 曲线数字签名算法)。直观地说,签名是一种基本的证明,其中消息和验证密钥是公共输入,而签名密钥是私有输入。通用 ZKP 支持对其输入的任意计算。
密码学证明通常提供完美的信息论隐私,这意味着证明在统计上独立于用于生成它的证据;以及计算健全性,这意味着计算资源有限的攻击者只能以可忽略的概率伪造证明。此保证的常见形式化称为知识健全性,其中显示能够输出验证者接受的证明的对手必须知道证据。(如何证明对手“知道”证据是一个有趣的问题,超出了本文的范围;Oded Goldreich 的著作《密码学基础》提供了可访问的解释。5)
经典的密码学 ZKP 构造针对简单的、固定的属性,可以使用例如线性或二次函数来表示。直观地说,证明者和验证者都通过在承诺而不是明文值上进行计算来评估函数,并且证明仅提供足够的辅助值,以将其中一些承诺与函数的公共输入和输出进行匹配。虽然生成的证明在属性大小上是线性的,并且对于双方来说开销都很大,但对于涉及简单函数的许多应用程序来说,这些构造是实用的。
更高级的 ZKP 构造10,12 涉及更简洁的证明,使得整个计算可以在对密码学承诺的对数甚至常数次操作中验证。虽然这对于验证者来说非常高效,有时可以以类似于普通签名验证的成本验证数百万次操作,但这需要更高级的算法,并给证明者带来额外的成本。
独立于核心证明系统,还有大量工作将感兴趣的属性(例如,用 C 或 LLVM 代码的子集表示)编译成这些密码学算法支持的线性或二次方程组。即使编译适用于任意属性,生成的方程组也可能比属性的源代码大得多(因此,证明成本更高)。这种开销也很难预测,因为某些操作是直接编码的,而其他操作则需要为其操作数的每个位使用一个方程。
证明者通常在自定义模式下执行已编译的属性,其中计算的每个步骤都产生证据,这些证据累积在生成的证明中。由于每个步骤都涉及密码学计算(例如,椭圆曲线上的操作),因此与本机执行相比,这通常需要几个数量级的性能开销。
机密计算于 2014 年随着软件保护扩展 (SGX) enclave 的一些首批应用而引入。13 它利用硬件对 TEE 的支持来保护计算的隐私和完整性。硬件确保 TEE 的内容对 TEE 外部的任何一方都是不可见且无法修改的,包括虚拟机监控程序和其他特权软件,甚至可能访问 TEE 物理设备的一方。
在 TEE 内部运行的计算可以请求 TEE 生成其代码和初始配置的认证,以及运行时选择的消息。认证通常通过使用唯一、硬件控制的密钥签署记录来实现,该密钥绑定到设备,并由硬件供应商提供的平台证书背书。认证实际上是一个证明,证明 TEE 是使用此代码和配置启动的,然后从该代码接收到请求以认证此消息。给定认证,验证者可以独立审查其代码和配置——例如,确认认证的消息是否满足某些属性。
CC 特别适用于保护计算免受其托管环境(如云提供商)的侵害,并允许多方共同计算数据,而无需与其他方共享该数据。CC 的吸引力很大程度上归功于它的实用性:与高级密码学计算技术(如 ZKP、多方计算和同态加密)不同,TEE 与现有软件高度兼容,并且通常具有较低的性能开销。
继续我们对证明的定义,假设证明者和验证者就一个程序达成一致,该程序 (1) 从其初始内存中读取实例;(2) 从不受信任的主机读取其证据;(3) 验证属性;以及 (4) 如果验证成功,则请求并返回其认证报告,作为属性成立的证明。
证明者创建一个 TEE,为该实例运行该程序,然后提供证据并收集生成的证明。此证明只是对属性实例规范的签名,而不是(其执行的密码学编码)。
CCP 验证涉及三个检查,验证:
• 证明是来自可信硬件平台的有效认证报告。
• 程序正确实现了属性,并与认证报告中的代码测量值匹配。
• 实例已正确编码在认证报告中的初始内存测量值中。
在较高层面上,密码学证明的验证也涉及类似的步骤:
• 证明相对于从设置阶段获得的公共参数是有效的。
• 属性已使用这些参数正确编码。
• 实例已使用这些参数正确编码。
如果硬件是可信的,则 CCP 是健全的,因为证明者只有通过为此程序和此实例创建 TEE,然后为其提供正确的证据,才能获得通过这三个步骤的认证报告;并且 CCP 是零知识的,因为它们是在向 TEE 提供证据之前对测量值进行的签名,因此,它们不携带关于这些证据的任何信息。
由于 TEE 可以运行其硬件处理器支持的任何程序,因此它们在生成证明的方式上提供了灵活性。如下所示,运行更大、更复杂的程序可能更方便,但也增加了验证者必须信任的代码量。
证明者可以创建一个 TEE,运行一个小型解释器,并将属性及其实例都作为经过认证的输入,而不是将属性编译成其自己的经过认证的代码。这简化了验证,因为 TEE 执行的代码可以一次性审查和编译。(本文后面采用了这种方法。)
证明者可以创建一个 TEE 来处理多个请求,每个请求都包括一个实例及其证据,并且(假设验证成功)为每个实例返回一个认证,而不是为每个证明创建一个 TEE。
到目前为止,假设被信任请求机密性的证明者充当生成其证明的 TEE 的本地主机;更一般而言,如果 TEE 在远程服务器上运行,则其代码可能还包括终止传输层安全 (TLS) 连接的代码,例如。还隐含地假设属性是一个纯粹的(确定性的、非交互式的)函数;可以通过使用系统功能扩展 TEE 来解除此限制——例如,与主机交互,甚至打开与其他方的连接。
表 1 比较了 CCP 和 ZKP 在安全性、性能和可用性方面的差异。
两种证明(CCP 和 ZKP)都涉及对密码学的某种信任,尽管 ZKP 通常涉及更高级的密码学原语和安全假设。因此,认证报告通常依赖于传统的公钥基础设施 (PKI) 来获取平台证书,而 ZKP 方案可能依赖于可信设置来生成和分发公共参数。
从根本上讲,CCP 的健全性基于对硬件的信任,包括其设计、制造、供应链和操作(TEE 可能容易受到故障、物理攻击和侧信道攻击)。例如,如果宇宙射线或过热导致未被检测到的位翻转,则 CCP 证明者可能会产生不健全的证明,而 ZKP 证明者将产生无法验证的证明。
这些风险可以通过多种方式部分缓解,例如,要求已安装关键固件更新;将配置到受信任数据中心以托管 TEE 的 CPU 的平台证书列入白名单;以及在 TEE 代码中构建一些冗余检查。验证者可以将所有这些要求作为其认证策略的一部分严格执行。更一般而言,现代 CPU 非常复杂,但对于大多数应用程序来说,在某种程度上已经被信任。具体而言,对于 CCP 和 ZKP,运行验证者的平台都被隐含地信任。
对于两种证明,软件 TCB 至少包括验证者的代码和要验证的属性的代码。验证者审查属性是否在所有情况下都得到正确实现至关重要,因为(根据隐私设计)它将无法审查用于生成证明的运行的详细信息。虽然代码审查可能具有挑战性,但通过使用形式化验证的代码(特别是对于密码学7 和解析11)和代码透明服务2,可以促进此任务。
TCB 的其他部分是特定于证明技术的。对于 ZKP,它们包括使用的自定义工具链,例如,用于将属性编译为算术电路,以及包含手写算术电路的密码学小工具库。对于 CCP,它们包括标准工具链以及 TEE 中包含的任何固件和运行时支持。
关于机密性,TEE 旨在保护其代码和数据免受所有其他方的侵害,包括其主机。这超出了零知识的范围,零知识(严格来说)仅保护访问证明的证据,但将证明者本身的保护作为一个单独的问题。更一般而言,CCP 允许证明,其中多方各自将其自己的私有输入贡献给 TEE(在验证其认证之后),并且 TEE 最终返回选定的结果和证明,而 ZKP 要求每个证明者都被信任所有私有输入,以生成其证明。
以后量子 (PQ) 安全性为例,让我们现在考虑如果需要更改,这两个系统的敏捷性。对于 CCP,这在概念上很简单——认证和 PKI 需要新的标准 PQ 安全算法——但这需要许多方进行协调更改,并且可能需要更新的硬件,因此很难快速进行此类更改。相比之下,ZKP 纯粹是软件,并且可以快速更新证明者和验证者库和参数。但是,更改不太直接,因为 PQ 安全的零知识构造效率较低且不成熟。
证明者性能显然更有利于 CCP。直观地说,TEE 的运行速度与 CPU 上的任何其他计算速度相同,创建和认证 TEE 的固定成本略有增加,并且 CPU 和 DRAM(动态随机存取存储器)之间加密/解密数据的线性成本略有增加。除了非常短的计算外,相对创建开销可以忽略不计。对于所有 I/O,线速硬件加密可以消除线性开销,而服务器 CPU 上的门数量和功耗预算成本较低(占很小的百分比),但在小型设备上可能更成问题。
尽管最初的 TEE 受到系统限制(例如,限制了它们可以使用的内存量),但最近的 TEE 使机密计算能够像普通计算一样扩展,开销小于 10%,这使得可验证的机密计算成为许多应用程序的安全默认选择。
ZKP 的证明者性能是一个积极的研究课题,并且持续取得稳步进展,但生成证明仍然比计算本身昂贵几个数量级14,并且最有效的证明者需要额外的内存来保存中间值、密钥和预计算。虽然最近的算法在理论上提供了出色的可扩展性,并且可以利用强大的硬件来加速证明的生成,但这些额外成本限制了它们的通用应用,并限制了可以在实践中证明的计算形状(例如,表示为同一算术电路的迭代评估)。
CCP 和 ZKP 都产生简洁的证明,即使在小型设备上也可以有效地验证,其大小和验证性能接近普通公钥密码学的预期,与正在验证的计算大小无关。例如,Intel SGX 和 AMD SEV-SNP(安全加密虚拟化-安全嵌套分页)的压缩认证报告分别约为 2,355 字节和约 640 字节,在笔记本电脑上验证分别需要 27 毫秒和 13 毫秒。基本 ZKP 可能小至 64 字节,验证时间少于 1 毫秒,而大型电路的 Nova 压缩证明约为 9 KB,验证时间约为 100 毫秒。10
证明验证需要自定义代码:CCP 需要特定的库来处理它们信任的 TEE 平台的硬件认证,而 ZKP 需要特定的库来处理它们的密码学算法。此代码还需要更新和正确配置,例如,使用 TEE 的硬件供应商证书和 ZKP 的公共参数。预计这些库的可用性和可用性会随着时间的推移而提高。
在证明者方面,CCP 需要支持 TEE 的硬件,最初这种硬件稀缺且受到限制,而 ZKP 可以纯粹在软件中实现。主要的云提供商现在提供一系列托管 TEE 平台,降低了至少云部署的采用门槛,并提高了它们的可用性——例如,通过处理固件更新和平台证书缓存。同样,手机和笔记本电脑等设备也越来越多地提供 TEE 功能。
ZKP 使用自定义编译器工具链,最初需要密码学家编写自定义应用程序代码。随着算术电路的共享编译器和格式的采用,情况正在改善,但它们的正确使用仍然涉及大量的专业知识和代码重构。虽然 CCP 隐式支持重用现有运行时和软件堆栈(包括遗留和专有软件)的状态交互式计算,但 ZKP 本身仅支持纯计算,并且需要为其余部分进行重构。一些 ZKP 系统在可用性和性能之间做出不同的权衡,通过解释现有架构,例如 ISA 或语言运行时。因此,例如,可以支持任意机器代码或以太坊合约,但成本更高——它们的初始实现可能每秒只能运行少量指令。
让我们回到引言中概述的帆船租赁示例。作为帆船的所有者,Bob 想要验证 Alice 是否具有符合他的租赁政策的各种凭证。这些凭证可能包括有效的身份证明形式,如驾驶执照或护照;能力证明,如认可学校的航海证书;支付租金的财务健全性证明;以及涵盖某些航海风险的保险证明,或具有足够资产进行自保的证明。
方便的是,此类文件越来越多地以数字格式提供,使得在线完成租赁协议成为可能。例如,数字驾驶执照9 和电子保险凭证正变得越来越实用,这要归功于正在进行的标准化努力。
与此同时,数字凭证也带来了新的隐私风险。随意传播经过身份验证的个人信息,包括年龄、性别、地址、联系信息和身份证照片(以及第三方可能对其进行的聚合)可能会助长身份盗窃、在线跟踪和定向广告。在这种情况下,Bob 不需要也不应该关心 Alice 凭证的详细信息,只要他可以验证它们是否符合他的政策即可。Bob 也不需要知道 Alice 是否已获得保险或正在自保。Alice 能否在不泄露这些文件和敏感财务数据的情况下提供此类政策合规性证明?
图 1 显示了 Alice 为了满足 Bob 的租赁政策而提供的示例凭证;其他凭证可能包括航海学校认证、保险凭证、偿付能力证明等。如图 1 所示,身份提供商和其他可信机构以签名声明集的形式(以某种标准格式,如 X.509 证书或 JSON Web 令牌)颁发凭证和其他文件。在实践中,凭证可以交付到凭证所有者的数字钱包中,该钱包位于个人设备(如手机或笔记本电脑)上,该设备可以使用生物特征认证等方式识别所有者,然后再解锁其凭证。
凭证通常包括来自颁发者的签名,以保护其完整性。为了将凭证呈现给第三方,其所有者可能需要提供另一个签名以证明拥有凭证并防止其重复使用。另一方面,这些凭证不假设具有任何自定义隐私功能,就像更高级的匿名凭证一样。
对于验证者——在本例中为船主 Bob——要满足的政策可以表示为一个简单的程序或脚本,使用特定于领域的政策语言(如 Rego)或 JavaScript 的子集。图 2 显示了一个示例政策,该政策强制执行 Bob 的帆船租赁要求;当前日期和会话标识符将政策评估绑定到 Alice 的请求。如图 2 所示,此类政策可以将一些参数作为输入,如时间戳和会话 ID。它们可以由验证者创建,并可能由监管机构或隐私监督机构认可。它们应该足够简单,以便凭证所有者——在本例中为 Alice——能够审查它们并评估其隐私风险。
一些基本政策可能只需要证明拥有具有给定属性的单个凭证,例如“我的护照有效期超过六个月”,而无需泄露其全部内容。Bob 的帆船租赁政策涉及更彻底的验证,跨越多个凭证。例如,Bob 必须验证在满足政策的文件中使用了相同的名称,它们当前是否都有效,以及它们是否都由他信任的机构签名。此验证可能反过来涉及对辅助声明的检查(图中省略),例如 Alice 航海学校的认证或认可 DMV(车辆管理局)密钥的证书链,该密钥用于签署她的驾驶执照。
虽然政策细节应由验证者仔细编写,并且可能会增加到数十行代码,但 Alice 可以根据具体情况审查政策,考虑她需要提供的实际凭证以及可能泄露的信息的敏感性。此审查发生在 Alice 决定继续之前,并且除非实际满足政策要求,否则不会泄露任何信息。
另一方面,凭证所有者和验证者都不需要审查底层的 CCP 或 ZKP 技术,因为其固定的 TCB 可以独立审查,而与所涉及的实际政策和凭证无关。
本节描述了 Alice 和 Bob 之间使用 CCP 的简单租赁协议,然后简要概述了使用 ZKP 的类似协议。该协议涉及三个角色。
• 身份提供商和其他可信机构在协议开始之前颁发各种凭证;它们在协议中处于离线状态,因此不会了解其凭证的使用情况。
• Alice 充当证明者。她将凭证保存在数字钱包中并控制其使用;她应依赖方的合法请求出示其中一些凭证,但希望保护她的隐私。为此,创建和控制 TEE 以生成其属性的证明。
• Bob 充当验证者。他保护对资源(他的船)的访问,创建相应的授权政策,并确保符合这些政策。
Alice 钱包的细节在这里并不重要,假设它受到 Alice 及其凭证颁发者的信任,因此重点应放在 Alice 和 Bob 之间的会话上,以确保帆船租赁的安全。图 3 显示了基于 Alice 的凭证证明符合 Bob 的租赁政策的消息流程,而无需泄露其详细信息。合规性证明绑定到 TLS 连接和当前时间。
如图 3 所示,他们首先建立一个安全通信通道,这允许 Alice 验证 Bob 的身份,并为本次协议运行提供一个新的会话标识符。(这一点很重要,以使合规性证明特定于本次运行,否则 Bob 可能会将此证明重用于其他目的,例如从竞争对手处租用另一艘船。)然后,Alice 可以查看 Bob 的船只详细信息并获取他的租赁政策(见图 2)。假设她认为此政策可以接受,她会专门创建一个 TEE,用于评估她实际凭据上的政策并证明其结果。TEE 返回一个 CCP,然后终止。Alice 将 CCP 转发给 Bob,Bob 验证其有效性;然后他们可以完成交易。作为协议的可选最后一步,Bob 可以签发一份签署的租赁协议,该协议可以添加到 Alice 的钱包中,并用于满足进一步的文件要求——例如,申请巡航许可证。
虽然概念上很简单,但 TEE 需要运行大量的可信代码来评估这种策略。
• 如图所示,策略本身应该足够简单,以便所有各方都能审查。使用高级的、特定于领域的策略语言可以促进这一点。
• 其余代码复杂但通用。例如,它可能包括用于评估策略的基本语言运行时、用于加密原语和协议的库,以及用于解析所有受支持凭据格式的代码(包括用于令牌的 JSON 和用于 X.509 证书的 ASN.1)。这段代码可以一次性地进行测试、审查,甚至形式化验证。
此协议中的策略合规性证明也可以纯粹在软件中实现,使用通用的简洁 ZKP 方案代替 CCP,而不会影响协议的其余部分(除了证明格式)。不幸的是,此处描述的“复杂但通用”代码使这项任务变得复杂。例如,正确地从 JSON 令牌中解析出名称字段,而不泄露其位置和长度,就需要定制技术。再举一个例子,Cinderella 描述了如何在零知识的情况下证明拥有有效的证书链1(示例租赁策略的通用子任务,涉及 ASN.1 解析和签名验证)。对真实世界 Web 证书链的支持涉及一个包含 300 万个等式的自定义算术电路,使用更新的证明系统进行证明将需要一到两分钟。3
这些困难很大程度上是由遗留凭据格式引起的。现在有更高效的协议可用于 ZKP 友好的格式,但正确地实现此类安全关键操作,以及策略的语言运行时,仍然需要前沿的 ZKP 手工制作。
受信任的 TEE,用于评估策略并证明其结果,可以位于用户设备上(如图 3 所示)或托管在云端。这两种方法都有其优点。
• 在可用时,设备上受多因素身份验证机制保护的个人 TEE 提供清晰的隐私保证,并避免了对在线服务的需求。它为设备所有者提供出色的凭据保护,但其 TEE 技术必须得到其他各方(及其监管机构)的充分信任。
个人 TEE 也可能带来额外的隐私风险,因为验证者可能要求识别 TEE 的主机,以便信任其证明,例如检查它是否已被撤销。(可以使用零知识来证明 TEE 不是由被撤销的主机实例化的,但这种方法尚未得到广泛支持。)
通过这种方式可链接的证明,依赖方可以串通起来跨服务跟踪用户,并将他们的交易与持久标识符链接起来。虽然这种风险对于示例帆船租赁来说似乎可以接受,但在许多情况下,匿名或更强的假名性最有利于用户隐私。
• 或者,使用 CCP 云服务可以为各种客户端设备提供统一的硬件保护(包括物理数据中心保护)。与个人设备上的 TEE 相比,信誉良好的云提供商托管的 TEE 可能更受验证者和依赖方的信任。对于需要在线检查的策略(例如交互式用户登录或证书吊销列表中的查找),它也可能很方便。关于隐私,可以进行代码审查以确保 TEE 除了它们生成的 CCP 之外,不会泄露有关客户端凭据的任何信息。虽然仍然可能观察到客户端向 CCP 服务发出请求,并将其与客户端和依赖方之间的会话相关联,但这种风险可以在传输层使用例如 Oblivious HTTP 来缓解。
证明是用于完整性和隐私的强大工具,使验证者能够委托计算并仍然验证其正确执行,并使证明者能够保持计算细节的私密性。CCP 和 ZKP 都可以实现可靠性和零知识,但存在重要差异。CCP 依赖于硬件信任假设,这带来了高性能和对证明者额外的机密性保护,但对于某些应用来说可能是不可接受的。CCP 通常也更易于使用,特别是对于现有代码,而 ZKP 则带来了大量的证明者开销,这对于某些应用来说可能是不切实际的。
随着这些技术获得更广泛的采用,应用程序很可能越来越多地利用 CCP 和 ZKP 中的一种或两种来进行计算。例如,可以在 TEE 内部生成 ZKP 以获得额外的证明者保护,而 TEE 可以采用 ZKP 以获得额外的证明隐私——例如,隐藏运行计算并生成其证明的 TEE 的硬件身份。8 从更广泛的角度来看,个人和政府越来越关注保护数据隐私,我们相信保护隐私的证明将有助于创建一个默认情况下隐私受到保护的世界。
1. Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Parno, B. 2016. Cinderella: turning shabby X.509 certificates into elegant anonymous credentials with the magic of verifiable computation. In Proceedings of the IEEE Symposium on Security and Privacy, 235–254; https://ieeexplore.ieee.org/document/7546505.
2. Delignat-Lavaud, A., Fournet, C., Vaswani, K., Clebsch, S., Riechert, M., Costa, M., Russinovich, M. 2023. Why should I trust your code? Communications of the 67 (1), 68–76; https://dl.acm.org/doi/10.1145/3624578.
3. Ernstberger, J., Chaliasos, S., Kadianakis, G., Steinhorst, S., Jovanovic, P., Gervais, A., Livshits, B., Orrù, M. 2023. zk-Bench: a toolset for comparative evaluation and performance benchmarking of SNARKs; https://eprint.iacr.org/2023/1503.pdf.
4. Fiat, A., Shamir, A. 1986. How to prove yourself: practical solutions to identification and signature problems. In Proceedings of Advances in Cryptology (CRYPTO), 186–194; https://dl.acm.org/doi/10.5555/36664.36676.
5. Goldreich, O. 2001. Foundations of Cryptography, Volume 1: Basic Tools. Cambridge University Press.
6. Goldwasser, S., Micali, S., Rackoff, C. 1985. The knowledge complexity of interactive proof-systems. In Proceedings of the 17th Annual Symposium on Theory of Computing (STOC), 291–304; https://dl.acm.org/doi/10.1145/22145.22178.
7. High Assurance Cryptographic Library – HACL* and EverCrypt Manual; https://hacl-star.github.io.
8. Intel. 2021. Intel Enhanced Privacy ID (EPID) Security Technology; https://www.intel.com/content/www/us/en/developer/articles/technical/intel-enhanced-privacy-id-epid-security-technology.html.
9. ISO. 2021. ISO/IEC 18013-5:2021 – Personal identification – ISO-compliant driving license; https://www.iso.org/standard/69084.html.
10. Kothapalli, A., Setty, S., Tzialla, I. 2022. Nova: recursive zero-knowledge arguments from folding schemes. In Proceedings of Advances in Cryptology, 42nd Annual International Cryptology Conference (CRYPTO), 359–388; https://dl.acm.org/doi/abs/10.1007/978-3-031-15985-5_13.
11. Ni, H., Delignat-Lavaud, A. Fournet, C., Ramananandro, T., Swamy, N. ASN1*: Provably correct, non-malleable parsing for ASN.1 DER. In Proceedings of the 12th SIGPLAN International Conference on Certified Programs and Proofs, 275–289; https://dl.acm.org/doi/10.1145/3573105.3575684.
12. Parno, B., Howell, J., Gentry, C., Raykova, M. 2013. Pinocchio: nearly practical verifiable computation. In Proceedings of the IEEE Symposium on Security and Privacy, 238–252; https://ieeexplore.ieee.org/document/6547113.
13. Schuster, F., Costa, M., Fournet, C., Gkantsidis, C., Peinado, M., Mainar-Ruiz, G., Russinovich, M. 2015. VC3: trustworthy data analytics in the cloud using SGX. In Proceedings of the IEEE Symposium on Security and Privacy, 38–54; https://dl.acm.org/doi/10.1109/SP.2015.10.
14. Walfish, M., Blumberg, A. J. 2015. Verifying computations without reexecuting them: from theoretical possibility to near practicality. Communications of the 58 (2), 74–84; https://dl.acm.org/doi/10.1145/2641562.
马克·鲁西诺维奇 (Mark Russinovich) 是微软 Azure 的首席技术官,他在那里领导微软云计算平台的技术战略和架构。
塞德里克·富尔内 (Cédric Fournet) 是微软剑桥 Azure 研究院的高级首席研究经理。他对安全性、隐私、密码学、分布式系统和形式化验证感兴趣。
格雷格·扎韦鲁查 (Greg Zaverucha) 是微软研究院的软件工程师和研究员。他从事应用密码学研究,实现密码学原语和系统,并帮助产品团队安全地使用密码学。
乔希·贝纳洛 (Josh Benaloh) 是微软研究院的高级密码学家。他的研究主要集中在多方协议,尤其是那些支持可验证选举技术的协议。
布兰登·默多克 (Brandon Murdoch) 是微软安全部门(英国伦敦)的工程总监,他在那里领导授权和去中心化身份方面的工作,重点是保护隐私的技术。
曼努埃尔·科斯塔 (Manuel Costa) 是微软的副总裁兼杰出工程师,他在那里领导 Azure 研究院的安全和隐私研究。他对推进安全性、隐私、计算机系统和编程语言的最新技术感兴趣。
Copyright © 2024 held by owner/author. Publication rights licensed to .
最初发表于 Queue vol. 22, no. 4—
在 数字图书馆 中评论本文
Raphael Auer, Rainer Böhme, Jeremy Clark, Didem Demirag - 央行数字货币隐私格局图
随着世界各国央行纷纷将现金数字化,隐私问题需要提到首位。所采取的路径可能取决于每个利益相关者群体的需求:注重隐私的用户、数据持有者和执法部门。
Sutapa Mondal, Mangesh S. Gharote, Sachin P. Lodha - 个人信息隐私
每次与外部服务的在线互动都会创建关于用户的数字记录和存储的数据。这些外部服务可能是信用卡交易、医疗咨询、人口普查数据收集、选民登记等。尽管表面上收集数据是为了向公民提供更好的服务,但个人的隐私不可避免地会受到威胁。随着互联网覆盖范围的扩大和生成数据量的增加,数据保护,特别是保护个人隐私,已变得尤为重要。
Kallista Bonawitz, Peter Kairouz, Brendan McMahan, Daniel Ramage - 联邦学习与隐私
集中式数据收集可能会使个人面临隐私风险,如果数据管理不当,组织也会面临法律风险。联邦学习是一种机器学习设置,其中多个实体在中央服务器或服务提供商的协调下协作解决机器学习问题。每个客户端的原始数据都存储在本地,不会交换或传输;相反,旨在立即聚合的重点更新用于实现学习目标。
Mark Russinovich, Manuel Costa, Cédric Fournet, David Chisnall, Antoine Delignat-Lavaud, Sylvan Clebsch, Kapil Vaswani, Vikas Bhatia - 迈向保密云计算
尽管现代云的发展主要由规模经济驱动,但也提高了安全性。大型数据中心提供聚合的可用性、可靠性和安全保证。确保操作系统、数据库和其他服务具有安全配置的运营成本可以在所有租户之间分摊,从而使云提供商能够聘请负责安全的专家;这对于小型企业来说通常是不可行的,在小型企业中,系统管理员的角色通常与许多其他角色混淆。