PDF安全问题解决了吗？
许多安全问题的解决方案已经存在，那么为什么我们仍然如此脆弱？
JOHN VIEGA，安全软件公司
有很多安全问题已经有了解决方案。然而，我们的安全问题似乎并没有消失。这里出了什么问题？是消费者被提供了假药并拒绝了吗？是他们没有采纳他们应该采纳的解决方案吗？还是完全有其他原因在起作用？我们将考察一些世界本可以变得更好但却没有变得更好的地方，并建立一些关于原因的见解。
为什么我们无法战胜缓冲区溢出？
对于大多数技术人员来说，缓冲区溢出是一个受到关注的问题。当程序向内存缓冲区写入的数据超过为该缓冲区分配的空间时，就会发生缓冲区溢出。在 C、C++ 和汇编语言中，程序会继续覆盖下一个内存。如果下一个内存恰好是指向可执行内容的地址，那么攻击者可以用指向他们自己代码的指针来覆盖它。例如，如果您的调用堆栈上分配了一个缓冲区，攻击者可能能够覆盖保存的指令指针，该指针指示系统在当前函数返回时应跳转到的位置。如果攻击者也在那里放置了一些代码，然后用该代码的地址覆盖保存的指令指针，则攻击者的代码将运行。这段代码可以被精心设计来做几乎任何事情。攻击者通常会给自己一个命令提示符或安装用于远程计算机控制的软件。
缓冲区溢出是世界似乎知道如何解决的一个问题，Java、C# 和 Python 等语言就证明了这一点，这些语言不易受到此问题的影响。从表面上看，我们仍然受到这个问题困扰的原因显而易见：我们在许多应用程序中仍然使用 C、C++ 和汇编语言。
安全行业抱怨开发组织为了效率而过于急于放弃高级语言。这在某种程度上是事实，但是用低级语言编写代码有很多合理的需要。有时，关注点确实是效率（例如，您不希望微软用 C# 编写其整个操作系统）。有时，只有通过低级 API 才能合理地访问某些功能。在编写大型遗留代码库时，无论是扩展还是维护它，通常都是这种情况。此外，将精通 C 语言的专家团队转换为他们不太熟悉的语言，仅仅为了安全考虑，也会产生一定的成本。
归根结底，不使用 C、C++ 或汇编语言只是部分解决方案。安全需求不是系统唯一的需求，通常甚至不是最重要的需求。值得庆幸的是，安全行业的大部分已经认识到这一点，并为这些环境寻找解决方案。
显而易见的做法是在编译器中添加自动边界检查，这在效率不是大问题的情况下会有所帮助。但是，人们的看法（无论对错）是这会成为一个大问题，因此有大量的技术试图以更有效的方式来防止这个问题。
字符串处理库。 示例包括 C++ String 类和 C 程序的 SafeStr 库 (www.zork.org/safestr)。这些库需要程序员的勤奋，他们可能会忘记使用这些 API。在某些情况下，如果不小心，这些 API 也可能被滥用。此外，许多缓冲区溢出问题并不涉及字符串处理，其中一些问题可能是可利用的。
静态分析工具。 这些工具不仅可以查找缓冲区溢出，还可以查找应用程序中的许多其他安全问题。一些优秀的工具正在商业化。但是，通常您需要源代码才能获得高质量的结果，实际缓解潜在问题可能需要资源，并且并非每个开发环境都支持好的工具。
不可执行堆栈。 作为最早引入的技术之一，不可执行堆栈消除了将缓冲区溢出转化为漏洞的最简单途径，但这很少是唯一的方法——更不用说如果可以溢出的缓冲区分配在执行堆栈之外的任何位置（例如，动态分配），则这种方法根本无济于事）。
基于金丝雀的技术。 这些技术，例如 StackGuard 和 Microsoft Visual Studio 编译器中的 /GS 标志，在堆栈上放置特殊值，这些值应该是攻击者无法猜测的，然后通过查看这些值在不应该更改时是否更改来尝试检测堆栈溢出。这并不能阻止每种类型的缓冲区溢出，甚至不能阻止每种类型的堆栈溢出。事实上，就在今年，有一篇论文介绍了如何有时利用 /GS 标志的代码来对抗自身。
随机化技术。 在随机化技术中，重要的内存部分（例如堆栈的起始位置和堆的起始位置）在程序启动时会被随机化。因此，确实发生缓冲区溢出的攻击者必须对内存中重要事物的位置进行更多的猜测（特别是，要执行的代码的内存地址，或为了执行而要操作的任何其他数据，例如存储的返回地址）。这些技术的问题在于，可能值的空间不是很大。在许多情况下，攻击者可以自动化攻击，并不断尝试直到成功。即使攻击者必须在利用程序之前崩溃程序 1000 次，这通常也不是问题。
不可执行内存页。 这是最新的 AMD 和 Intel 处理器的功能。它非常类似于不可执行堆栈，但是可以将任何内存页标记为仅数据。这里的基本思想是将所有可执行代码归入到几个不包含数据的页面中，然后将所有其他页面标记为不可执行。当使用这种技术时，它可能非常有效，但并非每个程序都可以使用它。这种技术也不是普遍有效的。即使程序不能执行代码段中没有的任何内容，仍然可以通过简单地注入数据来做恶意的事情。例如，绕过这些机制的常见技术之一是制作恶意数据来调用重要的系统调用。在 Unix 系统上，常见的技术是“返回到 libc”，程序员使用缓冲区溢出来使执行跳转到标准库调用，例如 exec()。此外，他们设置执行堆栈，以便在调用这些函数时，它们会使用攻击者的恶意参数进行调用。基本上，这种技术允许攻击者以与易受攻击的程序相同的权限在机器上运行任何程序。而且，攻击者可以选择程序的调用方式。
其中一些技术需要在编译时应用，特别是基于金丝雀的技术。这使得开源开发人员很难确保他们的程序是安全的，因为通常是用户编译代码。大多数其他技术也存在类似的问题，因为它们依赖于最终用户使用特定的硬件平台并运行特定的操作系统版本。
现实世界的需求
确实，开发团队可能比他们应该的更重视效率。对于这样做的团队，现在有一个研究项目提供了一个名为 Cyclone 的安全 C 版本。如果这种解决方案实现工业化，它可能会在开发人员的角度找到更好的平衡。不幸的是，这可能还需要很长时间。安全语言可能仍然明显不如汇编语言和最快的语言有效率。
同样显而易见的是，安全性很少是开发组织最重要的需求。最安全的解决方案通常不是最理想的。但是，当您无法做到最安全时，您可以轻松获得的安全性的下降幅度可能会变得非常陡峭。
身份验证系统就是一个很好的例子。这是我们拥有相当好的解决方案的另一个领域。安全社区会建议您使用多因素身份验证，其中可能包括生物特征扫描、智能卡上持有的加密令牌和密码。如果所有这些机制都到位并始终应用，那么您最终可以得到一个非常强大的系统。但是，存在一些问题。您最终会得到一个昂贵的解决方案（如果您希望整个互联网成为您的客户群，那么它可能会太昂贵——您不会想花钱在每个人的办公桌上放一个指纹扫描仪）。此外，许多人会发现由此产生的系统无法使用。必须做所有这些事情可能非常麻烦——用户会抱怨、寻找变通方法，甚至拒绝使用该系统。
人们想要安全，但他们也希望他们的系统易于使用。因此，他们会更喜欢安全性不如最佳的解决方案。即使必须管理大量的身份验证凭据（例如密码）也可能是一件苦差事——因此，单点登录解决方案的市场不断增长。
让我们看看密码。为了提供尽可能好的安全性，密码通常应该难以猜测，并且不应在多个地方使用相同的密码。问题是，用户讨厌选择难以猜测的密码，因为这样他们更容易忘记密码。无论您告诉他们什么，他们也可能会在多个地方使用相同的密码。有些人会写下密码，安全专家试图劝阻这种做法——别人很容易在您的键盘下找到您留在那里的纸条。
在高保证领域，例如金融界，最终用户的痛苦仍在继续。为了最大限度地减少漏洞窗口，密码需要每隔几个月更改一次，而且您不能循环使用一些喜欢的密码，因为这些系统会保留足够的内存来检测您何时重复使用某些内容。
另一个问题是在线密码猜测。eBay 希望阻止攻击者编写程序，通过暴力破解来猜测用户的密码，即尝试登录直到获得正确的密码。这通常是一种非常有效的技术，因为存在很多糟糕的密码。为了防止这种情况，一些系统在短时间内只允许有限的尝试次数。结果，人们总是将自己锁定在自己的帐户之外。这最终可能变成拒绝服务攻击。
可用性和安全性
很明显，安全性通常会与其他重要的需求（尤其是可用性）相权衡。是否总是必须这样？实际上，并非如此。可用性和安全性可以齐头并进，即使是密码系统也是如此。特别是，一类称为零知识协议的密码协议（参见侧边栏）避免了传统密码系统几乎所有主要问题。这些协议经过精心设计，不会向攻击者泄露任何关于密码的不必要信息。
例如，对于传统的密码协议，能够看到协议消息的攻击者可以将这些消息离线存储，并尝试使用大量不同的密码选择来重放协议，以查看是否会生成捕获的消息集。对于只是通过线路发送密码的密码协议，这可能非常容易。
使用良好的零知识协议，这种类型的攻击（称为离线“字典”或“暴力破解”攻击）不起作用。仍然有可能进行猜测，特别是通过尝试使用猜测直接登录服务器。不同之处在于，攻击者每次猜测都需要参与协议一次。攻击者无法使用离线信息做任何事情。
限制使用帐户的尝试次数很容易。虽然这种类型的限制可能会导致拒绝服务，但它可以使非常弱的密码变得非常强大，因为攻击者可以进行的猜测次数非常有限。例如，如果我的密码是众所周知的三个字母的单词，全部小写，那么可能性并不多。但是，如果攻击者只能猜一次，那么几率仍然很小。使用这样的方案，用户只需要稍加指导就可以想出好的密码。
尽管如此，零知识密码协议并没有得到广泛使用，这部分是安全社区的错，因为社区中的许多人甚至不知道它们的存在（包括安全供应商）。了解它们的人往往不会推广它们，因为大多数领域都有专利覆盖。最流行的协议（例如 SRP（安全远程密码））受多项专利保护。只有少数晦涩的协议（例如 PDM（密码派生模数））可能不受这些限制，但是存在足够的不确定性，以至于许多人干脆避开整个协议类别，而寻找其他方法来降低风险。这些解决方案应该得到更好的推广，并获得库的更好支持。软件开发组织应该确定他们是想获得专利许可，还是想使用像 PDM 这样可能没有专利的东西，并可以选择在以后有人提出强有力的主张时更换它。
当然，即使您使用零知识密码协议，甚至更强大的身份验证系统，仍然会存在风险。最大的风险之一是社会工程学：例如，用户说服技术支持人员重置密码。人类通常是链条中最薄弱的环节，因此安全社区试图尽可能地将他们排除在外。例如，对于密码，安全人员开始推动称为个人熵的概念，即使用个人问题（例如，“您最喜欢的宠物叫什么名字？”）作为备份身份验证形式。安全社区在教人们如何很好地应用这项技术方面做得还不够。特别是，您不能使用少量问题，因为通常不难找到某人的母亲的娘家姓或宠物的名字。巴黎·希尔顿的手机被“黑客入侵”就是一个引人注目的例子。攻击者通过知道她最喜欢的宠物是她的狗 Tinkerbell（这是众所周知的）而得以进入希尔顿的 T-Mobile 在线帐户。尽管如此，使用神秘的个人信息可能仍然有效，特别是对于不像她那样引人注目的用户而言。
社会工程学攻击通常不必太复杂就能奏效。例如，如果您打电话给某人，声称来自一家合法的研究机构，正在进行一项关于人们如何使用和选择密码的研究，大多数人都会泄露他们的 PIN 和密码，特别是如果提供报酬以换取参与。在大多数情况下，所需要的只是专业的姿态。这是一个似乎没有理想技术解决方案的问题。安全行业建议使用多种类型的身份验证（称为多因素身份验证），其中一个因素通常是密码，另一个因素通常是智能卡（包括流行的 RSA SecurID 产品）和生物特征设备。这样，即使密码泄露，攻击者也需要找到另一种方法来破坏另一层身份验证。
多因素身份验证机制的问题在于，密码之外的每种解决方案都存在某种现实世界的约束，使得人们不想使用它。通常，这是成本，尤其是生物特征设备。即使是基于令牌的系统，例如 SecurID 或基于 Java 的智能卡，也需要大量的基础设施成本，用于部署昂贵的卡和读卡器，如果为整个互联网编写软件供使用，则基本上是不切实际的。可以通过使用 PKI（公钥基础设施）凭据来添加另一个无需物理设备的身份验证因素。PKI 只需要以一堆比特的形式存在。但是，用户很难使用这些系统，因为它们使得在机器之间迁移变得困难。
由于密码可能始终是最流行的身份验证选项，因此似乎有理由继续寻找技术和教育方法来阻止人们泄露密码。例如，研究人员可能想弄清楚如何阻止人们在登录系统遇到问题时向系统管理员泄露密码。这可能不需要任何重大的技术突破，而只需要规范和标准化。例如，我们可以轻松构建一个协议，用户可以为自己的帐户设置临时密码，然后可以将其提供给系统管理员。这些密码可以是随机选择的、短的且简单的。如果这些类型的零知识和密码重置协议得到标准化和广泛部署，我们可以理所当然地告诉用户，他们在任何情况下都没有理由泄露密码。
如果我们有 SSL，为什么保护数据通信仍然很困难？
总而言之，对于许多安全问题，都有安全且可用的解决方案，但是安全社区在可用性方面做得不够好，无法在没有重大安全权衡的情况下为用户提供他们可以而且应该提供的功能。例如，看看 SSL/TLS。最终用户希望抽象尽可能接近传统套接字的直接替代品。SSL 似乎就是这样工作的——代码将是功能性的，但不幸的是，它不会是安全的。没有 SSL 套接字库执行适当的身份验证检查来建立安全连接。有些库可能会检查服务器证书是否已过期，甚至可能会检查该证书是否由已知的证书颁发机构签名，但是它们都没有检查证书是否实际上映射到客户端尝试连接的主机。您要么必须安装您自己的有效证书白名单，要么手动验证证书的内容，这通常需要相当多的代码。但是，绝对没有理由不能将此作为 SSL 库中的默认设置，并提供钩子来允许您在有特殊需求时自定义您的检查。
然而，SSL 引入了其他烦恼，例如需要为服务器获取签名证书，并在 SSL 连接之上构建客户端身份验证系统，以确保双方都相互验证。不幸的是，最终用户最终会认为他们的安全需求得到了满足，而实际上并没有，因为他们不了解问题。
他们为什么要了解呢？如果有更好的解决方案需要更少的理解，那么安全社区应该做得更好，提供这些解决方案，并让最终用户意识到它们。例如，零知识密码协议实际上可以对双方进行身份验证，并进行加密密钥交换。将这样的协议与用于保护线路上的数据的通用方法结合使用，为用户提供一个真正简单的“安全通道”接口，这将很容易。这将满足大多数应用程序的安全需求，特别是如果基于标准组件（例如 AES（高级加密标准）块密码（由美国国家标准与技术研究院标准化））构建的话。几种块密码操作模式可以与 AES 一起使用，以提供基本的安全保证（例如，GCM，目前在 IPsec 中标准化，并有望在 802.1ae 中标准化）。
问题在于需要一个简单的接口来将所有内容捆绑在一起，从身份验证协议到正在进行的数据的加密和身份验证。这应该在消除常见风险的同时完成。例如，如果正确使用 GCM 等模式，它们可以防止一类称为捕获-重放的攻击，但并非每个人都需要防止此类攻击，因此不强制您避免它们。因此，有可能使用 GCM 而不防止此类攻击。这里的目标是将所有内容捆绑到一个足够简单的库中，这样就不会太担心底层库中潜伏的安全风险（有几个加密库，虽然加密效果很好，但在避免其他安全问题（例如缓冲区溢出）方面编写得不好）。
还有什么问题？
安全行业可以通过为危险操作提供简单、可用的接口来很好地解决许多其他问题。例如，应该有通用的框架来防止 SQL 注入攻击、跨站脚本攻击等等。归根结底，可用性是安全行业应该具备但一直缺乏的基本技能。但是，可用性并不是唯一的问题。
首先，商业安全部门非常可以理解地过于关注底线，而没有为客户提供符合他们长期最佳利益的东西。也就是说，他们专注于可以改善世界的唾手可得的成果，而不是提出解决问题的根本解决方案。例如，尽管电子商务在 1997 年开始兴起，但为了缓解软件漏洞，商业世界直到最近才完全专注于网络安全机制，例如防火墙和入侵检测系统。基于网络的解决方案易于构建，但不能完全解决问题。
最终，我们必须让人们编写更安全的代码。这需要为他们提供更好的教育和更好的抽象，以从根本上简化工作，同时仍然满足开发部门真正需要的业务需求。但是，企业界直到最近两年才开始朝着这个方向发展。公平地说，即使学术界也没有真正开始深入研究这个问题，直到这十年，但是话又说回来，那个社区在很大程度上是由行业的短期需求驱动的，并且也倾向于采用唾手可得的成果策略。
追求核心安全解决方案的学术界也没有完全找对方向。它需要更多地关注安全与现实世界的需求和担忧之间的平衡。例如，用于解决未知软件安全问题（例如缓冲区溢出）的第一个工具是基于 Web 的扫描器。许多组织购买了这些工具，承诺在很大程度上自动化他们以前无法做到的事情（手动审查太昂贵，而且很难做好，因为没有多少人拥有广度、耐心或记忆力来理解庞大、复杂的系统及其交互）。
购买第一波工具的公司了解到，很好地使用这些工具存在巨大的隐性成本。首先，这些工具倾向于产生大量的输出，但是弄清楚如何处理问题需要人来完成。对这些输出进行优先级排序是一项艰巨的任务，特别是考虑到大多数问题通常是误报。此外，由于这些工具是黑盒工具，因此它们无法很好地了解问题可能位于代码中的哪个位置，这意味着通常需要大量的准备工作。
最终，企业正在努力解决安全社区一直迟迟未能回答的更根本的问题。例如，开发部门现在可以找到一套工具来帮助他们解决软件安全问题，但是他们通常仍然不了解他们应该如何作为企业来解决这个问题。应该在何时、何地以及如何使用这些工具（例如，在开发期间、在每日构建期间还是在 beta 期间）？应该执行哪些其他类型的活动，这些活动无法通过工具自动化，例如在最初设计软件时进行安全审查？在这些不同的活动中，相对投资应该是多少？
安全开发的业务流程非常重要，但还没有达到应有的水平。该领域的首批书籍实际上并没有涉及流程本身，而是最佳实践的集合。
值得庆幸的是，该领域的工作现在正在加速进行。微软和其他一些公司已经制定了一些流程来执行架构安全审查。截至今年，软件安全有一个完整的生命周期流程，从需求提取到架构和实现审查，一直到测试和部署：Secure Software 的 CLASP（Comprehensive, Lightweight Application Security Process，综合、轻量级应用程序安全流程）。但是，由于该领域的工作做得很少，因此安全社区仍然需要解决许多未解决的问题，例如开发更有效的指标来帮助企业做出关于软件安全的业务决策。
安全解决方案并非凭空存在
安全社区知道如何解决一些在实践中尚未解决的真正的大问题。例如，我们有解决缓冲区溢出问题的技术解决方案，并且知道如何解决密码使用中的许多实际问题。我们可以解决难题，但是显然在部署实际有效的解决方案方面存在一些困难。
根本问题是安全社区经常忽略系统的现实世界需求。其设计通常假设安全是唯一的需求或最重要的需求。有些领域没有任何明确的安全功能需求，但有隐含的需求（特别是可用性）。在这些情况下，安全社区似乎忽略了这些担忧的影响。
这很不幸，因为可用性是安全性的关键考虑因素。如果安全功能不容易安全地使用，那么人们就不会安全地使用它们。同样，如果需要安全功能，但系统不可用，那么人们会寻找一种关闭该功能的方法，或者会使用其他功能。这是一个很难把握的平衡，安全行业通常不会花费太多精力来寻找它。可用性似乎是一门简单的学科，因为设计师通常认为他们对事物应该如何工作的直觉是最可用的方式。但情况很少如此。已经发展出一门独立的工程学科来帮助设计师弄清楚如何使事物真正易于使用（例如，参见 Jakob Nielson 的《Usability Engineering》（可用性工程），Elsevier Science and Technology Books，1995 年）。
安全社区需要扩大其正在解决的业务需求的范围。它需要理解，解决安全问题的技术解决方案并非凭空存在，并且仅仅以最小化最终用户长期风险的方式捆绑这些解决方案可能是一项艰苦的工作。当然，人们已经意识到这些问题，但是进展并没有像应该的那样快。稍加努力，我们应该能够做一些简单的事情，例如创建安全的网络连接或使用数据库而没有 SQL 注入的风险。在我们能够做到这些事情之前，世界其他地方有责任通过成为苛刻的客户来塑造安全世界。
JOHN VIEGA 是 Secure Software 的首席技术官兼创始人，他在那里负责公司的核心流程和安全分析算法。他还致力于为开发人员推广更好的安全实践，并且是该主题的常任讲师。他与人合著了该领域的三本书，包括《Building Secure Software》（构建安全软件）（Addison Wesley，2001 年）、《Network Security with OpenSSL》（使用 OpenSSL 的网络安全）（O'Reilly，2002 年）和《Secure Programming Cookbook for C and C++》（C 和 C++ 安全编程食谱）（O'Reilly，2003 年）。Viega 是 GCM 的合著者，GCM 是一种加密模式，它包含在 802.1ae 标准草案中。他是 GNU 邮件列表管理器 Mailman 的原始作者。他拥有弗吉尼亚大学的计算机科学学士和硕士学位。
零知识基础知识
考虑一个客户端-服务器场景，其中 Alice 希望使用零知识密码协议与她的银行交谈。在这样的协议中，Alice 和银行共享一个共同点，即 Alice 的密码。实际上，银行不会直接存储她的密码。相反，它将存储她的密码的某些函数，这是密码存储的最佳实践。此值称为验证器，因为银行将使用它来验证 Alice 是否是她所说的人。
传统的密码协议要么直接通过网络发送密码，要么发送密码的某些函数。在这些情况下，如果 Mallory（攻击者）可以捕获网络流量，她要么直接获得密码，要么能够运行暴力破解攻击。
零知识协议不会通过网络发送密码，也不会发送任何泄露密码信息的数据。但是，Alice 和银行仍然可以相互证明他们都知道密码，而 Alice 无需透露她的密码。
这很不直观，但是我们可以使用一个经典的现实世界示例来解释它，即阿里巴巴的洞穴（图 1）。R 和 S 之间的线是一扇门，只能用秘密密码打开。银行希望证明 Alice 知道密码，但是如果 Alice 实际上没有与银行交谈，Alice 不想透露任何密码。他们可以使用以下协议来做到这一点
银行首先站在P点，而Alice则前往R或S。Alice选择R或S，但不会透露她的选择。因为银行看不到Q，所以无从得知。当Alice有足够时间做出选择后，银行移动到Q点。然后它随机选择“左”或“右”，并喊出声。假设它喊出“左”。如果Alice已经在左侧隧道中，她直接走出来。如果她不在左侧隧道中，她会对着门轻声说出秘密密码，以免银行听到。然后她穿过门，进入左侧隧道。
如果Alice从右侧出来，银行可以肯定这个人不知道密码。如果Alice从左侧出来，则无法确定她是否知道密码，因为她有50%的几率猜对。
但是，如果他们重复这个协议20次，那么Alice在不知道密码的情况下每次挑战都成功的几率将低于百万分之一。也就是说，如果Alice正确地走了20次相同的路径，银行可以相当肯定她知道密码。
如果挑战者不是银行，而是Mallory，Alice不会泄露任何关于密码的信息。当然，她确实证明了自己知道正确的密码；否则，她永远无法回答这些挑战。
但是请注意，如果Alice不知道密码，她仍然可以至少尝试一次密码，甚至可能更多次。在实际方案中，可以将Alice的猜测次数限制为整个协议一次。同样，如果Alice是合法的，但不知何故被诱骗尝试向Mallory进行身份验证（例如，通过所谓的网络钓鱼攻击），那么Mallory仍然只能进行一次猜测。一般来说，Alice会向Mallory发出“挑战”，正确的答案可以证明她知道密码。Mallory无法从Alice那里获得关于密码的任何信息，除了她的猜测是否正确。
最初发表于Queue vol. 3, no. 5—
在数字图书馆中评论这篇文章
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信AI
安全性、隐私性、问责制、透明度和公平性原则是现代人工智能法规的基石。经典的联邦学习在设计时非常强调安全性和隐私性，但以牺牲透明度和问责制为代价。CFL 通过将联邦学习与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密计算的最新进展（如机密容器和机密 GPU）意味着现有的联邦学习框架可以无缝扩展以支持具有低开销的 CFL。
Raluca Ada Popa - 机密计算还是密码学计算？
通过 MPC/同态加密与硬件飞地进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您心中想到的工作负载非常重要。对于简单的求和、低度多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中使用，但对于复杂的计算（如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件飞地方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处展示的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保了容器组所有可达状态的安全不变性，这植根于证明报告。这允许外部第三方与容器安全地通信，从而支持各种需要机密访问安全数据的容器化工作流程。公司获得了在云中运行最机密工作流程的优势，而无需在其安全要求上妥协。
Charles Garcia-Tobin, Mark Knight - 利用 Arm CCA 提升安全性
机密计算具有巨大的潜力，可以通过将监管系统从 TCB 中移除来提高通用计算平台的安全性，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要平台硬件和软件方面的创新，但这些创新有可能提高对计算的信任，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要对他们选择信任的平台做出自己的决定。
© 保留所有权利。