OpenSSL 软件包大约有 30 万行代码,这意味着可能仍然存在大约 299 个错误,现在 Heartbleed 漏洞已被修复——该漏洞几乎允许任何人检索他们通常不应访问的内部状态。
这真的是你需要知道的全部,但你也知道这不会阻止我,对吧?
理论上,保护计算机网络连接并不难。首先,让技术精湛的密码学家设计一些密码学构建块。您将需要一个良好的哈希函数、一个良好的对称块密码和一个良好的非对称密码。接下来,让技术精湛的密码协议设计师定义如何以逐步的方式将这些构建块捆绑在一起。然后,一位技术精湛的 API 设计师定义应用程序如何通过一个经过深思熟虑且抗错误的 API 访问协议,该 API 具有精心选择且可靠的默认值以及良好的错误报告机制。然后,技术精湛的程序员根据 API 以高质量、经过全面审核和分析的库源代码来实现算法和协议。在那之后,应用程序员——通常是任何人都不是技术精湛的人——最终编写代码来打开安全连接。
但我们还没有完全完成。
我们需要确保编译器正确地将高级语言翻译成机器指令。只有技术精湛的编译器程序员才能做到!我们还需要确保计算环境是值得信赖的——系统库或操作系统内核中不能有错误、失误、后门或恶意软件。谁写的?你猜对了,显然是技术精湛的内核程序员!当然,如果 CPU 不能忠实地执行指令,那么这一切都是徒劳的,但技术精湛的 CPU 工程师无疑会注意到这一点。
现在——终于——我们可以安全地将一张猫的照片从一台计算机传输到另一台计算机。
这并没有那么糟糕,不是吗?
像我一样指定一个梦之队并非没有缺陷,因为 OpenSSL 包含以下代码
/*
* 右移 md_size 的目的是为了让编译器
* 不会认为它可以删除 div_spoiler,因为那
* 需要它证明 md_size 始终是偶数,
* 我希望这超出了它的能力范围。
*/
div_spoiler = md_size >> 1;
div_spoiler <<= (sizeof(div_spoiler)-1)*8;
rotate_offset =
(div_spoiler + mac_start - scan_start) % md_size;
老实说——在我向你展示之前,你会认为一个被证明是正确的编译器改进是一种安全风险吗?
当然你不会!它被证明是正确的,不是吗?
这就是我们的安全模型(如果你可以这样称呼它)崩溃的地方。涉及的代码太多了,没有人知道它是否都能正常工作。
在我的计算机上,数字大致是
操作系统内核: 200 万行代码
编译器: 200 万行代码
C 语言运行时库: 50 万行代码
密码库: 30 万行代码
每增加一种编程语言将增加大约一百万行代码。使用图形用户界面大致使数量翻倍,而浏览器几乎再次翻倍。一个合理的估计是,您阅读本文的计算机至少有 100 个,但更可能是 1,000 个漏洞,您的安全可能会因此受到损害。如果这些错误是您的计算机独有的,那还不太糟糕。但事实并非如此,因为它们是数百万台计算机上完全相同的错误,因此,每个错误都具有大流行潜力。而且——似乎任务还不够困难——有些人正在积极破坏结果,以便使“情报收集”更容易且成本更低。显然,我们梦之队中一些技术精湛的工程师和科学家有不可告人的目的——否则 NSA 的领导层将是极其无能的。
然后是证书颁发机构。他们的工作是充当“信任锚”,以便一旦您建立了安全连接,您也知道您在与谁交谈。
CA 的可信度是个笑话。
你信任
TÜRKTRUST BİLGİ İLETİŞİM VE BİLİŞİM GÜVENLİĞİ HİZMETLERİ A.Ş.
来验证与您银行的连接吗?
你甚至不知道 “GÜVENLİĞİ HİZMETLERİ” 是什么意思,对吧?
我当然不知道,我也不信任他们!
2012 年 8 月,他们颁发了伪造的证书,持有者可以使用这些证书声称自己是 Google。当然,TÜRKTRUST 坚称这完全是“一次性错误”,“没有不正当行为”,并且“这种情况永远不会再次发生”。
没有人相信一句话。
然而,您的浏览器仍然默认信任他们,就像它信任数百个其他或多或少可疑的组织说实话一样。因此,我们正在使用臃肿的、有漏洞的软件进行连接,信任阴暗的、政府渗透的 CA 来向我们保证我们正在与谁交谈?
一定有更好的方法,对吧?
好吧,没有。
我们从未找到一种更简单的方法,让两个没有事先联系的各方建立安全的电信渠道。在非对称密码学(1973-1977)发展之前,人们认为这是不可能的。如果您想知道另一端是谁,唯一的方法是信任一些声称知道的第三方。鉴于我们的身份是社会建构,而不是物理现实,因此数学或密码学的突破永远不会改变这一点。
因此,如果我们希望电子商务能够运作,我们就必须让有漏洞的代码能够工作,并且我们应该实施比“CA 黑手党”更值得信赖的东西。
这让我回到了 OpenSSL——它很糟糕。代码一团糟,文档具有误导性,默认值具有欺骗性。此外,它是 30 万行代码,其中充满了您能想象到的几乎所有软件工程疾病
等等等等。
这不是任何人的错。
从来没有人真正负责 OpenSSL,它只是在某种程度上成为了密码学发明原型的默认垃圾填埋场,并且由于它在阳光下拥有所有密码学(在某个地方,如果您能找到使用方法),它也成为了密码学功能的默认来源。
我确信不止一个人认为“没有人因为使用 OpenSSL 而被解雇”。
这就是为什么在我写这篇文章时,每个人都在互联网上恐慌的原因。
即使按照 OpenSSL 中的错误来说,这个错误也非常糟糕,但我在 的专栏作家 Kode Vicious 还是设法找到了一线希望:“因为他们使用了 'short' 整数,所以只暴露了 64 千字节的秘密。”
这既不是 OpenSSL 中的第一个严重错误,也不会是最后一个严重错误,因此,OpenSSL 必须消亡,因为它永远不会变得更好。
我们需要一个精心设计的 API,尽可能简单,以防止人们错误地使用它。我们需要该 API 的多个独立的、高质量的实现,这样,如果一个实现被证明是垃圾,人们可以在几个小时内切换到更好的实现。
拜托了。
喜欢它,讨厌它?请告诉我们
Poul-Henning Kamp ([email protected]) 是 FreeBSD 操作系统的主要开发者之一,他从一开始就致力于该系统的开发。他因其基于 MD5 的密码加扰器而广为人知,该加扰器保护了思科路由器、瞻博网络路由器以及 Linux 和 BSD 系统上的密码。有些人注意到他编写了一个内存分配器、一个设备文件系统和一个实际上可用的磁盘加密方法。Kamp 与他的妻子、儿子、女儿、大约十几台 FreeBSD 计算机以及世界上最精确的 NTP(网络时间协议)时钟一起住在丹麦。他以独立承包商的身份谋生,从事与计算机和网络相关的各种工作。
© 2014 1542-7730/14/0400 $10.00
最初发表于 Queue vol. 12, no. 3—
在 数字图书馆 中评论本文
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信人工智能
安全性、隐私性、问责制、透明度和公平性原则是现代人工智能法规的基石。经典的 FL 在设计时非常强调安全性和隐私性,但以牺牲透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合,弥补了这一差距。此外,CFL 还带来了其他理想的安全属性,例如基于代码的访问控制、模型机密性和推理期间的模型保护。机密计算的最新进展(如机密容器和机密 GPU)意味着现有的 FL 框架可以无缝扩展以支持 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 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要平台硬件和软件方面的创新,但这些创新有可能增强对计算的信任,尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。