PDF在苹果中发现不止一条虫子
如果你看到什么，就说出来。
Mike Bland
在二月份，苹果公司披露并修复了一个SSL（安全套接层）漏洞，该漏洞自2012年9月iOS 6.0发布以来一直未被发现。由于复制了一个goto语句，它使SSL/TLS（传输层安全）握手算法中出现短路，从而使用户容易受到中间人攻击。自从发现这个非常严重的错误以来，许多人已经撰写了关于潜在原因的文章。然而，仔细检查代码不仅揭示了如何编写单元测试来捕获该错误，还揭示了如何重构现有代码以使算法可测试，以及更多关于错误性质和产生错误的环境的线索。
本文探讨了关于SSL漏洞的五个重要问题：什么是漏洞（以及为什么它很糟糕）？它是如何发生的（以及如何没有发生的）？测试如何捕获它？为什么测试没有捕获它？我们如何修复根本原因？
什么是漏洞（以及为什么它很糟糕）？
苹果SSL漏洞，正式标记为CVE-2014-1266，是由包含一个虚假的、无条件的goto语句产生的，该语句绕过了SSL/TLS握手算法的最后一步。根据国家漏洞数据库（http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1266）和CVE（通用漏洞和披露）标准漏洞条目（http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266），该漏洞存在于表1所示的iOS、OS X和Apple TV操作系统版本中。
这些正式报告将该错误描述如下：“SSLVerifySignedServerKeyExchangelibsecurity_ssl/lib/sslKeyExchange.c中的函数，位于数据安全组件的安全传输功能中...不检查TLS服务器密钥交换消息中的签名，这使得中间人攻击者可以通过（1）使用任意私钥进行签名步骤或（2）省略签名步骤来欺骗SSL服务器。” 通过在苹果发布的开源代码中搜索函数名称（http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c）并查找以下语句序列，可以发现此错误
if ((err = SSLHashSHA1.update(
&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
熟悉C编程语言的人会认识到第一个goto fail绑定到if语句紧随其后；第二个是无条件执行的。这是因为用于嵌套条件语句以提高人类可读性的空格被C编译器忽略；当多个语句适用时，花括号必须括起绑定到if语句的所有语句。
算法中出现的其他>goto fail语句是C语言中常见的惯用法，用于在函数在完成之前遇到致命错误时释放资源。在有缺陷的代码中，成功的update()调用将导致无条件跳转到函数末尾，在算法的最后一步之前；并且返回值将指示握手成功。本质上，算法被短路了。
对于受影响平台上使用Apple Safari和其他基于安全传输应用程序的用户来说，“安全”连接容易受到中间人攻击，即能够将消息从客户端中继到互联网上的“安全”服务器的攻击者可以冒充服务器并拦截伪造握手后的所有通信。（使用包含自己SSL/TLS实现的产品（如Google Chrome和Mozilla Firefox）的用户未受影响。）尽管尚不清楚此漏洞是否曾被利用，但它使数亿台设备（和用户）在17个月的时间里处于易受攻击的状态。
苹果公司因在2014年2月21日星期五修补iOS设备和Apple TV的漏洞而受到批评，这使得漏洞知识广泛传播，但将OS X Mavericks的补丁推迟到下周二。这个四天的窗口使用户在不了解iOS补丁的情况下容易受到现在非常公开的漏洞利用。
它是如何发生的（以及如何没有发生的）？
许多人已经注意到可能捕获该错误的明显缺失的因素。编码标准——特别是那些强制使用缩进和花括号的标准——结合自动化样式检查工具和代码审查，可能已经引起了对重复语句的注意。自动合并可能产生了冒犯性的额外行，并且开发人员可能缺乏足够的经验来检测它。如果收集了覆盖率数据，它将突出显示无法访问的代码。编译器和静态分析警告也可能检测到无法访问的代码，尽管如果尚未定期使用此类工具，则虚假警告可能会淹没信号。
其他人指出，代码似乎缺少单元测试，单元测试很可能已经捕获了该错误。虽然许多其他工具和实践可能足以防止这种特定的漏洞，但一个更深层次的问题，最终产生了重复的goto语句，本可以通过适当的单元测试规范来防止。
有些人质疑是否进行了足够的系统测试，而另一些人则认为，由于系统测试无法找到每个错误，这仅仅是一个不幸的案例，碰巧溜走了。另一些人则声称，goto语句的使用和/或蓄意破坏是罪魁祸首。这些说法都经不起推敲。
Goto 并非“被认为有害”
由于它是更流行的理论之一，让我们驳斥关于>goto是此漏洞的罪魁祸首的论点。许多人提到了流行的概念，即goto是“被认为有害的”，这是基于Edsger Dijkstra于1968年3月在通讯上发表的信。以下是Dijkstra在“反对GO TO语句的案例”中实际说的话：“我并不声称所提及的子句是详尽无遗的，因为它们将满足所有需求；但是，无论建议什么子句（例如，中止子句），它们都应满足程序员独立的坐标系可以被维护以以有益且可管理的方式描述过程的要求。”9 换句话说，“中止子句”以释放函数的资源可能仍然依赖于>goto，在没有其他直接语言支持的情况下。
这种C语言“中止子句”惯用法是合法且广为人知的，并且受到其他语言的直接支持。例如，在C++中，自动析构函数实现了RAII（资源获取即初始化）惯用法；Java采用>try/catch/finally块（http://docs.oracle.com/javase/tutorial/essential/exceptions/handling.html）；Go提供了defer(), panic()和recover()机制（http://blog.golang.org/defer-panic-and-recover）；Python具有try/except/finally块（https://docs.pythonlang.cn/3/reference/compound_stmts.html#try）和with语句，该语句用于实现RAII（https://docs.pythonlang.cn/3/reference/compound_stmts.html#the-with-statement）。在没有这些机制的情况下，在C语言中，这仍然是goto语句的合法应用，否则代码会因重复语句而变得臃肿，或者控制结构变得嵌套太深，以至于妨碍了可读性和可维护性。
事实上，放错位置的>return语句可能会产生相同的效果。想象一下，如果定义了如下宏
#define ERROR_EXIT {\
SSLFreeBuffer(&hashCtx);\
return err; }
那么，该错误可能会以这种形式出现
if ((err = SSLHashSHA1.update(
&hashCtx, &signedParams)) != 0)
ERROR_EXIT
ERROR_EXIT
即使强制使用花括号也可能无法防止错误，因为它们可能不匹配
if ((err = SSLHashSHA1.update(
&hashCtx, &signedParams)) != 0)
{
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(
&hashCtx, &hashOut)) != 0)
goto fail;
}
此漏洞的责任不在于goto语句。无论如何编写，适当的单元测试都会捕获该错误。
代码重复
额外的goto语句出现的握手算法在代码中重复了六次。图1显示了包含重复>goto fail行的算法，因为它出现在SSLVerifySignedServerKeyExchange()函数中。图2显示了紧接此算法之前的代码块。这种重复是导致漏洞显现的关键因素，它可以直接追溯到缺乏单元测试规范——因为缺乏可测试代码所需的工艺和设计感。考虑到单元测试编写代码的人会确保只存在一个算法副本——不仅因为理论上更合适，还因为这将更容易测试。
编码人员在编写代码时——或第二次、第三次、第四次、第五次或第六次复制代码时，无法“嗅到”（http://blog.codinghorror.com/code-smells/）重复代码！这表明随着时间的推移，不良习惯的模式，而不是一次粗心的错误。最终，这说明了一个文化问题，而不是个人的瞬间错误。
测试如何捕获它？
Landon Fuller发布了一个用Objective-C实现的的概念验证单元测试10，使用了Xcode Testing Framework2。 Fuller指出，“没有理由或借口不针对所有潜在的错误条件对[SSLVerifySignedServerKeyExchange()函数]进行全面测试”。然而，这个概念验证错失了深入研究代码并为此特别关键的算法提供完整测试覆盖率的机会——该算法非常关键，以至于在同一个文件中出现了六次。
正确测试算法的第一步是将其提取到一个单独的函数中——这本身可能已经防止了导致错误的重复goto fail，因为单个代码块比六个几乎相同的代码块（图3）更不容易受到编辑或自动合并错误的影响。
来自SSLVerifySignedServerKeyExchange()的两个较早的代码块现在显示如下
if(isRsa) {
/* ... */
if ((err = HashHandshake(
&SSLHashMD5, &clientRandom,
&serverRandom,
&signedParams, &hashOut))
!= 0)
goto fail;
} else {...}
...
if ((err = HashHandshake(
&SSLHashSHA1, &clientRandom,
&serverRandom, &signedParams,
&hashOut)) != 0)
goto fail;
这是可行的，因为>HashReference是一个“跳转表”结构，并且SSLHashMD5和SSLHashSHA1是HashReference的实例，它们指向特定的哈希算法实现。>HashReference接口使得编写一个小测试来练习通过隔离的HashHandshake()算法的每条路径变得简单明了，使用HashReference桩，并验证它是否会捕获这个特定的错误
+ build/libsecurity_ssl.build/.../
x86_64/tls_digest_test
TestHandshakeFinalFailure 失败
预期 FINAL_FAILURE，
接收到 SUCCESS
1 个测试失败
的tls_digest_test.c的代码可在http://goo.gl/tnvIUm查看，其中包含我所有的概念验证更改；build.sh自动化了下载代码、应用补丁以及使用单个命令构建和运行测试的过程。测试和补丁都是非常快速的工作，但可以作为独立的演示，而无需构建整个库所需的全部依赖项。诚然，该演示并未解决代码中存在的进一步重复或其他问题。
所有这一切的重点是，如果一位已经离开行业两年半的前程序员可以在几个小时内成功地重构和测试这段代码，而且以前从未见过它，那么负责这段代码的工程师或团队为什么在17个月前没有正确地测试它？
为什么测试没有捕获它？
几篇文章试图解释为什么苹果SSL漏洞通过了苹果可能拥有的任何测试、工具和流程，但这些解释是不合理的，特别是考虑到上述在工作代码中的相反演示。在发布之前未能检测到此漏洞的最终责任不在于任何个人程序员，而在于产生代码的文化。让我们回顾一下最突出的解释样本，并说明它们为何不足。
Adam Langley经常被引用的博客文章13讨论了该错误的精确技术后果，但退缩了关于自动化测试会捕获它的断言：“测试用例可以捕获它，但它很困难，因为它深入到握手中。需要编写一个完全独立的TLS堆栈，其中包含许多用于发送无效握手的选项。”
这种“太难测试”的无奈补充了谷歌测试雇佣兵（我是其中一员）经常听到的“我没有时间测试”的借口（尽管，在我们解散时，测试已经在谷歌根深蒂固，并且很少再听到这个借口）。11 然而，正如已经证明的那样，单元测试绝对会捕获它，而没有过度的困难。有效地测试算法不需要“完全独立的TLS堆栈”；精心设计的测试练习精心设计的代码会捕获错误——事实上，测试的想法很可能完全阻止了它。
不幸的是，有些人采用了Langley的立场，而没有考虑到在系统级别测试一切的不可行性是小、中、大型测试规模模式存在的原因（如图4所示，对于谷歌以外的大多数世界来说，那是单元、集成和系统）。5 在持续集成系统（例如，谷歌的TAP、Solano CI）下运行的不同规模的自动化测试正在成为整个行业的标准实践。人们会期望这成为像苹果这样的大型软件开发操作的核心功能，尤其是在涉及其产品的安全关键组件时。
David Auerbach为Slate撰写文章，为非程序员分解了该缺陷，并推测该错误可能是由合并错误引起的（基于此diff：https://gist.github.com/alexyakoubian/9151610/revisions；查找绿色第631行），但随后得出结论：“我认为按照今天的标准，代码相当不错。如果苹果的代码不好，他们就不会将其作为开源发布，即使他们发布了，如果开源社区查看过并发现它是垃圾，也会引起轩然大波。”3
Auerbach的结论假设苹果发布的所有东西在定义上都是高质量的，它拥有所有合理的控制措施来确保如此高质量，并且所有开源代码都受到大量程序员的集中审查（感谢Stephen Vance在他的关于我早期演示的评论中专门指出这一点，这启发了本文）——至少是那些有动力报告安全漏洞的程序员。然而，实际代码表明缺乏自动化测试规范和随之而来的工艺，以及缺乏其他质量控制，而不是Auerbach想象的苹果已经应用的现有规范的缺陷。
安全专家Bruce Schneier指出，“该缺陷是微妙的，并且在扫描代码时难以发现。很容易想象这可能是如何因错误发生的... 这是故意的吗？我不知道。但是，如果我想故意做类似的事情，这就是我的做法。”15 Schneier的重点是安全性，而不是代码质量，因此他的观点是可以理解的；但证据严重倾向于程序员错误和缺乏质量控制。
代尔夫特大学计算机科学教授Arie van Deursen指出了许多可以捕获该错误的行业标准工具和实践；但是，尽管自我认定为单元测试的坚定拥护者，但他拒绝断言应该应用该实践：“在当前代码中，函数很长，并且它们涵盖了不同条件分支中的许多情况。这使得难以调用特定行为... 因此，鉴于当前的代码结构，单元测试将很困难。”16 然而，正如已经证明的那样，这一个特定的关键算法很容易提取和测试。可以更改软件结构以促进许多目的，包括提高可测试性。推广此类更改是谷歌测试雇佣兵的工作。
我的前测试雇佣兵同事C. Keith Ray在他的关于van Deursen帖子的评论和他自己的博客中都指出：“大多数试图在设计糟糕、未经单元测试的项目中使用TDD[测试驱动开发]的开发人员会发现TDD在这种环境中很难做到，并且会放弃。如果他们尝试进行‘测试后’（与TDD的先测试实践相反），他们也会发现它在这种环境中很难做到并放弃。这会产生恶性循环：未经测试的糟糕代码会鼓励更多未经测试的糟糕代码。”14
我基本上同意Ray的说法，但希望他可能会抓住机会提及明显的重复代码坏味道以及如何消除它。再说一遍，那是我们作为测试雇佣兵的拿手好戏。过去缺乏TDD并不妨碍现在使代码更具可测试性，我们有责任演示如何做到这一点。
哥伦比亚大学计算机科学教授Steven M. Bellovin提供了对该错误及其后果的另一种透彻解释，但当他问“为什么他们一开始没有捕获该错误”时，他的重点仍然放在详尽的系统级测试的不可行性上：“无论你测试多少，你都不可能测试所有可能导致失败的输入组合；这在组合上是不可能的。”4
正如所证明的那样，此漏洞不是系统测试不足的结果；而是单元测试不足的结果。Keith Ray本人撰写了一篇“厕所上的测试”8文章“测试过多”11，解释了如何将复杂逻辑分解为小的、可测试的函数，以避免输入的组合爆炸，并且仍然实现对关键角落案例的覆盖（“等价类划分”）。鉴于TLS算法的复杂性，单元测试应该是第一道防线，而不是系统测试。当存在相同算法的六个副本时，系统测试人员就注定要失败。
这种缺乏开发人员测试规范的证据，特别是对于安全关键代码，表明工程和/或企业文化未能认识到单元测试和代码质量的重要性及影响，以及易于预防的失败的实际成本——以及激励经过良好测试的代码而不是未经测试的代码。《卫报》2中Charles Arthur引用的匿名苹果前雇员的评论支持了这一说法
“为什么苹果没有更早发现该错误？
“那里的前程序员说，‘苹果没有强大的测试或测试驱动开发文化。苹果过度依赖内部试用[使用自己的产品]进行质量流程，这在安全情况下是不合适的...
“从这件事中吸取了什么教训？
“但苹果的前工作人员表示，除非公司引入更好的测试机制——静态代码分析、单元测试、回归测试——‘我对这件事并不感到惊讶... 迟早会有另一颗这样的炸弹爆炸。’ 唯一的——最小的——安慰：‘我怀疑它是恶意的。’”
评论员Antoine Picard评论了此安全漏洞与报告的苹果MacBook电源线问题之间的相似之处，他指出：“当一切都只关乎设计时，其他一切都会受苦。”12
我们如何修复根本原因？
那些有单元测试经验的人了解其超出风险预防的生产力优势；但是，当没有经验的人仍然顽固地不相信时，像这样的高可见性错误可以证明单元测试的具体价值——在工作代码中。
抓住教学时刻！撰写文章、博客文章、传单，发表演讲，开始对话；在可能的情况下贡献可工作的单元测试；并让开发人员、团队和公司对代码质量负责。
随着时间的推移，通过逐步努力，文化可以改变。苹果的缺陷和2014年4月在OpenSSL中发现的Heartbleed漏洞——在本文最初起草之后——本可以通过相同的单元测试方法来预防，我的测试小组（http://mike-bland.com/tags/testing-grouplet.html）、测试认证6、“厕所上的测试”和测试雇佣兵合作伙伴多年来努力向谷歌工程部门展示。到我们完成时，彻底的单元测试已成为预期的文化规范。（我对Heartbleed的评论，带有工作代码，可在http://mike-bland.com/tags/heartbleed.html获得。）
文化变革并非易事，但它是可能的。如果志同道合的开发人员跨团队、跨公司，甚至跨行业联合起来——例如，波士顿自动化测试聚会（http://www.meetup.com/Automated-Testing-Boston/）、其在纽约、旧金山和费城的姊妹团体以及AutoTest Central社区博客（http://autotestcentral.com/）正在开始发生的那样——并参与创造性活动以提高对此类问题及其解决方案的认识，随着时间的推移，变革将会到来。
目标是这篇和即将发表的文章（包括Martin Fowler发表的我的“Goto Fail、Heartbleed和单元测试文化”文章，https://martinfowler.com.cn/articles/testing-culture.html）将推动围绕苹果SSL和Heartbleed漏洞的讨论，传播意识并提高话语质量——不仅围绕这些特定漏洞，而且围绕单元测试和代码质量的主题。这些漏洞是各种因素的完美风暴，使其成为此类讨论的理想选择
• 就苹果漏洞而言，实际缺陷非常明显，而Heartbleed缺陷只需要少量技术解释。
• 可以预防它们的单元测试方法是直接明了的。
• 用户对缺陷及其严重性的认识甚至比其他众所周知的软件缺陷更广泛，从而产生了大众和技术媒体。
• 现有解释要么驳斥单元测试发现此类错误的能力，要么以其他方式为缺陷辩解，这些解释显然是不合理的。
如果我们不抓住这些机会，为自动化测试、代码质量和工程文化的重要性及影响提出强有力的理由，并让公司和同事对可避免的缺陷负责，那么还会发生多少可预防的、大规模传播的漏洞和失败？如果我们不采取适当的纠正措施来应对>goto fail和Heartbleed，我们将面临什么样的命运？借口会持续多久，最终它们会给我们带来什么？
如果人们拒绝解决导致容易预防的灾难性缺陷的真正问题，那么开源软件经常被引用的基石原则——Linus定律——“只要有足够的眼球，所有错误都是肤浅的”——又有什么好处呢？
我一直致力于根据多年的经验和确凿的证据制作合理的推理成果——以苹果补丁和测试tarball和heartbleed_test.c（http://goo.gl/w1bGyR）的形式提供工作代码——以支持我相当简单的声明：单元测试文化很可能可以预防灾难性的>goto fail和Heartbleed安全漏洞。
苹果SSL/TLS漏洞和Heartbleed漏洞等备受瞩目的失败是展示自动化测试在具体方面的优势的绝佳机会；展示人们可以应用于现有代码的技术方法；并说明导致不良习惯和错误的更大、通常是文化上的根本原因。鉴于现代社会在多大程度上依赖于软件，软件从业人员社区必须让其成员对未能遵守旨在减少可预防缺陷发生的基本最佳实践负责，无论这种责任是非正式的，并且必须挺身而出，不是为了惩罚错误，而是为了帮助解决导致此类缺陷的根本原因。如果你看到什么，就说出来！
致谢/进一步阅读
本文基于我的演示文稿“在苹果中发现不止一条相同的虫子”（http://goo.gl/F0URUR）和相应的一页受“厕所上的测试”启发的处理（http://goo.gl/Lshkmj）。这些是基于我的博客条目“测试雇佣兵（略微回归）”（http://mike-bland.com/2014/03/04/test-mercenary-slight-return.html）和我的AutoTest Central文章“在苹果发货之前发现虫子”（http://autotestcentral.com/finding-the-worm-before-the-apple-has-shipped）。结论部分还使用了我的博客文章“官方苹果SSL漏洞‘厕所上的测试’剧集”（http://mike-bland.com/2014/04/15/goto-fail-tott.html）的摘录。所有内容均在Creative Commons Attribution 4.0国际许可协议（http://creativecommons.org/licenses/by/4.0/deed.en_US）下发布。
图4中显示的小型、中型和大型测试金字塔图像由Catherine Laplace创作，基于作者为Google新工程师绘制的测试小组/EngEDU Noogler单元测试讲座幻灯片中的图像草图。
犯罪同伙
我最深切的感谢扩展到我的前谷歌同事、波士顿自动化测试聚会的新同事以及我仅在网上认识的慷慨的熟人：David Plass、Isaac Truett、Stephen Vance、RT Carpenter、Gleb Bahmutov、Col Willis、Chris Lopez和Antoine Picard。他们为幻灯片和一页处理提供了巨大的投入，产生了这些作品和本文中明显的结构和重点。
我想感谢波士顿自动化测试聚会的Sarah Foster和AutoTest Central博客，他们提供了讨论此问题的论坛，并提供了与其他志同道合的开发人员联系的机会。
最后，我不知道我将如何偿还Python和Dropbox的Guido van Rossum，感谢他代表我倡导在上发表本文，以及ThoughtWorks的Martin Fowler，感谢他邀请我撰写“Goto Fail、Heartbleed和单元测试文化”文章。
参考文献
1. Apple Inc. 2014. Xcode overview; https://developer.apple.com/library/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/Xcode_Overview.pdf.
2. Arthur, C. 2014. Apple's SSL iPhone vulnerability: how did it happen, and what next? The Guardian, (February 25); http://www.theguardian.com/technology/2014/feb/25/apples-ssl-iphone-vulnerability-how-did-it-happen-and-what-next.
3. Auerbach, D. 2014. An extraordinary kind of stupid. Slate (February 25); http://www.slate.com/articles/technology/bitwise/2014/02/apple_security_bug_a_critical_flaw_was_extraordinarily_simple.html.
4. Bellovin, S. M. 2014. Goto Fail. SMBlog (February 23); https://www.cs.columbia.edu/~smb/blog/2014-02/2014-02-23.html.
5. Bland, M. 2014. AutoTest Central; http://autotestcentral.com/small-medium-and-large-test-sizes.
6. Bland, M. 2011. Test Certified; http://mike-bland.com/2011/10/18/test-certified.html.
7. Bland, M. 2012. Test Mercenaries; http://mike-bland.com/2012/07/10/test-mercenaries.html.
8. Bland, M. 2011. Testing on the Toilet; http://mike-bland.com/2011/10/25/testing-on-the-toilet.html.
9. Dijkstra, E. 1968. A case against the GO TO statement. Communications of the 11 (3): 147-148; http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF.
10. Fuller, L. 2014. TestableSecurity: demonstrating thatSSLVerifySignedServerKeyExchange()易于测试；https://github.com/landonf/Testability-CVE-2014-1266。
11. Google, Inc. 2008. 测试过多。Google Testing Blog（2月21日）；http://googletesting.blogspot.com/2008/02/in-movie-amadeus-austrian-emperor.html。
12. Greenfield, R. 2012. 为什么Apple的电源线总是断裂。The Wire（7月30日）；http://www.thewire.com/technology/2012/07/why-apples-power-cords-keep-breaking/55202/。
13. Langley, A. 2014. Apple的SSL/TLS漏洞。Imperial Violet（2月22日）；https://www.imperialviolet.org/2014/02/22/applebug.html。
14. Ray, C. K. 2014. TDD和签名的SSLVerifySignedServerKeyExchange。Exploring Agile Solutions: Software Development with Agile Practices（2月23日）；http://agilesolutionspace.blogspot.com/2014/02/tdd-and-signed-sslverifysignedserverkey.html。
15. Schneier, B. 2014. iOS SSL缺陷是故意的吗？Schneier on Security: A Blog Covering Security and Security Technology（2月27日）；https://www.schneier.com/blog/archives/2014/02/was_the_ios_ssl.html。
16. van Deursen, A. 2014. 从Apple的#gotofail安全漏洞中学习。Arie van Deursen: Software Engineering in Theory and Practice（2月22日）；http://avandeursen.com/2014/02/22/gotofail-security/。
喜欢它，讨厌它？请告诉我们
Mike Bland 在2005年至2011年期间是Google的软件工程师。在从事网络搜索基础设施工作之前，他领导了测试和Fixit Grouplets；是Test Mercenaries、Testing Tech和Build Tools团队的成员；并在促成工程文化变革方面发挥了重要作用，这种变革使彻底的开发者测试成为公认的文化规范。他不代表Google，而是伯克利音乐学院的学生。http://mike-bland.com/。
© 2014 1542-7730/14/0500 $10.00
最初发表于Queue vol. 12, no. 5—
在数字图书馆中评论这篇文章
更多相关文章
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的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。