真实世界密码学2022主题 - Trail of Bits博客

William Woodruff
2022年5月3日
编译器, 密码学, 研究实践

上周，全球500多名密码学家齐聚阿姆斯特丹，参加2022年真实世界密码学会议，这是两年多来首次线下聚会。

与往年一样，我们派遣多名研究员和工程师参加会议，聆听演讲，并观察当前密码学研究和实际工程之间的主导主题。

以下是我们从真实世界密码学2022中收集到的主要主题：

可信硬件并不可信

可信硬件（无论是可信执行环境（TEE）、硬件安全模块（HSM）还是安全飞地）的实现者继续犯下工程错误，从根本上违反了硬件所做的完整性承诺。

安全工具仍然太难使用

或者“你可以把马带到水边，但你不能让它运行./configure && make && make install。”

无处不在的侧信道

当上帝关上一扇门时，他会打开一个侧信道。

密码学背景下的LANGSEC

弄清楚你在说什么协议是计算机科学中的第三个难题。

让我们开始吧！

可信硬件并不可信

可信硬件中的基本非密码学漏洞并不是什么新鲜事。多年的漏洞导致英特尔决定从其下一代消费级CPU中移除SGX，而ROCA在2017年影响了四分之一的TPM。

新的是可信硬件在面向消费者的角色中的普及。普通用户越来越多地（并且不知不觉地！）通过密码管理器和2FA方案（如手机和电脑上的WebAuthn）与安全飞地和TEE交互。这从根本上扩大了与可信硬件漏洞相关的风险：可信硬件的中断现在对个人用户构成直接风险。

这就是我们来自RWC 2022的第一个亮点：“信任死于黑暗：揭示三星TrustZone密码设计”（幻灯片，视频，论文）。在本环节中，演讲者描述了三星TrustZone OS实现TEEGRIS中的两个关键弱点：一个IV重用攻击，允许攻击者提取硬件保护的密钥，以及一个降级攻击，使即使是最新和修补过的三星旗舰设备也容易受到第一次攻击。我们将看看两者。

TEEGRIS中的IV重用

TEEGRIS是一个完全独立的OS，与“正常”主机OS（Android）隔离并行运行。为了与主机通信，TEEGRIS提供了一个可信应用程序（TA），该程序在TEE内运行，但通过Keymaster（一个由Google标准化的命令和响应协议）向正常主机暴露资源。

Keymaster包括“blob”的概念：加密密钥本身已使用TEE的密钥材料加密（“包装”）并存储在主机OS上。因为包装的密钥存储在主机上，它们的安全性最终取决于TEE在密钥包装期间正确应用加密的安全性。

那么TEEGRIS Keymaster如何包装密钥？使用AES-GCM！

如您所知，块密码（AES）与操作模式（GCM）结合通常有三个参数：

• 用于初始化块密码的密钥
• 用于扰动密文并防止我们的朋友ECB企鹅的初始化向量（IV）
• 我们打算加密的明文本身（在这种情况下，是另一个加密密钥）

AES-GCM的安全性取决于一个IV永远不会对同一个密钥重用的假设。因此，能够强制密钥和IV在多个“会话”（在这种情况下是密钥包装）中使用的攻击者可以违反AES-GCM的安全性。演讲者发现了三星Keymaster实现中的错误，这些错误违反了两个安全假设：密钥派生函数（KDF）不能被操纵多次产生相同的密钥，并且攻击者不能控制IV。方法如下：

在Galaxy S8和S9上，用于生成密钥的KDF仅使用攻击者控制的输入。换句话说，攻击者可以强制给定Android应用程序的所有加密blob使用完全相同的AES密钥。在这种情况下，只要攻击者不能强制IV重用，这是可以接受的，除了……

Android应用程序在生成或导入密钥时可以设置IV！Galaxy S9上的三星Keymaster实现信任主机传递的IV，允许攻击者多次使用相同的IV。

此时，流密码本身的属性为攻击者提供了从另一个blob恢复加密密钥所需的一切：恶意blob、恶意密钥和目标（受害者）blob的XOR产生目标的明文，即未包装的加密密钥！

最终，演讲者确定这种特定攻击仅适用于Galaxy S9：S8的Keymaster TA从攻击者控制的输入生成密钥，但不使用攻击者提供的IV，防止了IV重用。

演讲者于2021年3月报告了这个错误，并被分配了CVE-2021-25444。

降级攻击

作为对三星TrustZone实现分析的一部分，演讲者发现Galaxy S10、S20和S21设备上的Keymaster TA默认使用较新的blob格式（“v20-s10”）。这种新格式改变了用于种子KDF的数据：不是完全由攻击者控制，而是混合了随机字节（来自TEE本身），防止了密钥重用。

但别急：S10、S20和S21上的TEE默认使用“v20-s10”格式，但允许应用程序指定使用不同的blob版本。没有任何随机盐的版本（“v15”）是有效选项之一，因此我们又回到了可预测密钥生成的起点。

演讲者于2021年7月报告了这个错误，并被分配了CVE-2021-25490。

要点

TEE并不特殊：它们受到与其他所有东西相同的密码工程要求的约束。硬件保证仅与运行在其上的软件一样好，软件应该（1）使用具有抗误用操作模式的现代密码，（2）最小化攻击者对密钥和密钥派生材料的潜在影响，以及（3）消除攻击者降级格式和协议的能力，这些格式和协议应该对主机OS完全 opaque。

安全工具仍然太难使用

我们Trail of Bits是自动化安全工具的忠实粉丝：这就是我们编写和开源工具如dylint、pip-audit、siderophile和Echidna的原因。

这就是为什么我们对“‘它们并不难缓解’：密码库开发者对定时攻击的看法”（幻灯片，视频，论文）中的调查结果感到悲伤：在27个主要开源密码项目的44名密码学家中，只有17人实际使用过自动化工具来查找定时漏洞，尽管100%的参与者都知道定时漏洞及其潜在严重性。以下是参与者选择不使用自动化工具的一些原因：

• 对风险的怀疑：许多参与者表示怀疑他们需要额外的工具来帮助缓解定时攻击，或者存在实际的世界攻击证明缓解所需的努力是合理的。
• 安装或使用困难：许多调查的工具具有复杂的安装、编译和使用说明。开源维护者在尝试使具有过时依赖项的项目在现代系统上工作时感到沮丧，特别是在它们最有用的情况下（CI/CD中的自动化测试）。
• 维护状态：许多调查的工具是学术工作的源工件，要么未维护，要么维护非常松散。其他工具没有容易发现的源工件，只有二进制版本，或者具有商业或其他限制性许可。
• 侵入性：许多工具对它们分析的程序引入了额外要求，如特定的构建结构（或程序表示，如仅C/C++或某些二进制格式）和用于指示秘密和公共值的特殊DSL。这使得许多工具不适用于用Python、Rust和Go等语言编写的新项目。
• 开销：许多工具涉及显著的学习曲线，会占用开发者本已有限的时间。许多工具即使在使用后也需要大量时间，如手动审查和消除误报和漏报，调整工具以提高真阳性率等。

也许不直观的是，对工具的认识与它们的使用并不相关：大多数 surveyed 开发者（33/44）知道一个或多个工具，但只有一半的人实际选择使用它们。

要点

用演讲者的话说，从对定时漏洞的认识（几乎普遍），到工具认识（大多数开发者），再到实际工具使用（一小部分开发者），存在明显的“泄漏管道”。阻止这些泄漏需要工具变得：

• 更容易安装和使用：这将减少在选择工具和实际能够应用它之间所需的认知开销。
• 容易获得：工具必须可以在不需要深入了解活跃密码学研究的情况下发现；工具应该可以从知名来源（如公共Git主机）下载。

此外，演讲者将编译器本身确定为一个重要的新前沿：编译器始终存在，开发者已经熟悉，并且是引入更高级技术（如秘密类型）的理想场所。我们Trail of Bits恰好同意！

无处不在的侧信道

侧信道漏洞的伟大之处在于它们的惊人普遍性：似乎有无穷无尽的越来越有创意的技术从目标机器提取信息。

侧信道通常沿两个维度描述：被动-主动（即，攻击者是否需要与目标交互，以及到什么程度？）和本地-远程（即，攻击者是否需要位于目标的物理附近？）。因此，远程、被动侧信道从攻击者的角度来看是“两全其美”：它们完全隐蔽，不需要物理存在，使它们（原则上）受害者无法检测。

我们喜欢“借我你的耳朵：PC上的被动远程物理侧信道”（视频，论文）中描述的侧信道。总结如下：

• 演讲者观察到，在笔记本电脑上，板载麦克风物理连接到音频接口（因此连接到CPU）。数字逻辑控制有意的数据流，但它都只是电线，因此是下面的无意噪声。
• 实际上，这意味着板载麦克风可能充当CPU本身的EM探头！
• 我们在互联网上与可能不受信任的方共享音频：公司会议、会议、与朋友和家人的VoIP、视频游戏的语音聊天等。
• ……那么我们能从这些数据中提取任何感兴趣的东西吗？

演讲者提供了三个案例研究：

• 网站识别：受害者在通过VoIP交谈时浏览网站，攻击者（与受害者通话）想知道受害者当前在哪个网站上。 结果：使用具有14路分类器（针对14个流行新闻网站）的卷积神经网络，演讲者能够达到96%的准确率。
• 密码密钥恢复：受害者在本地机器上执行ECDSA签名，同时通过VoIP交谈，攻击者想要 exfiltrate 用于签名的秘密密钥。 结果：演讲者能够使用与Minerva相同的侧信道弱点，但无需本地仪器。即使有后处理噪声，他们在大约20,000次签名操作后演示了密钥提取。
• CS:GO wallhacks：受害者在玩在线第一人称射击游戏时通过VoIP与其他玩家交谈，攻击者想知道受害者在游戏地图上的物理位置。 结果：当受害者隐藏在 opaque 游戏对象（如汽车）后面时，在频谱图中视觉上可识别 distinct “斑马图案”。演讲者观察到这绕过了标准的“反作弊”缓解措施，因为没有操纵客户端代码来揭示受害者的游戏内位置。

要点

侧信道是不断给予的礼物：它们难以预测和缓解，并且它们 compromise 在抽象中完全健全的密码方案。

演讲者正确指出，这种特定攻击颠覆了关于物理侧信道的传统假设：它们不能远程利用，因此可以从攻击者纯粹远程的威胁模型中排除。

密码学背景下的LANGSEC

LANGSEC是“安全性的语言理论方法”：它将许多（大多数？）可利用的软件错误归因于对可能不受信任的输入的临时解释，并建议我们通过将不受信任的输入与仅从有效或预期输入派生的形式语言进行比较来解析它们。

这种方法与在应用密码学中经常出现的错误类型 extremely 相关：

• 具有复杂底层格式（如DER）的复杂方案（如PKCS#1 v1.5）继续产生可利用的错误：Bleichenbacher的2006年攻击年复一年地出现。
• 复杂协议（如TLS）和升级/降级行为也产生可利用的错误：POODLE降级到SSL 3.0，并且实现错误可能允许TLS 1.3降级。

我们在今年的RWC上看到了不是一次，而是两次LANGSEC相关的演讲！

应用层协议混淆

“ALPACA：应用层协议混淆—分析和缓解TLS认证中的裂缝”（幻灯片，视频，论文）的演讲者从他们对TLS中设计决策的观察开始：因为TLS从根本上独立于应用和协议，它没有直接概念两个端点应该如何通信。换句话说，TLS只关心在两台机器之间建立加密通道，而不（必然）关心哪些机器或这些机器上的哪些服务实际在通信。

在它们在Web上的使用中，TLS证书通常绑定到域，防止攻击者将 intended for safe.com 的流量重定向到 malicious.biz。但这并不总是足够的：

• 通配符证书很常见：控制 malicious.example.com 的攻击者可能能够重定向来自 safe.example.com 的流量，如果该流量使用允许 *.example.com 的证书加密。
• 证书可以声称许多主机，包括已被恶意攻击者获得或 compromise 的主机：safe.example.com 的证书可能也允许 safe.example.net，攻击者可能控制它。
• 最后，也许最有趣的是，证书不指定它们期望与哪个服务和/或端口进行身份验证，为攻击者创造了将流量重定向到同一主机上的不同服务的机会。

为了使攻击者更容易，主机经常运行多个协议大致类似于HTTP的服务。演讲者针对四种（FTP、SMTP、IMAP和POP3）评估了三种不同的攻击技术：

• 反射：MiTM攻击者将跨源HTTPS请求重定向到同一主机上的不同服务，导致该服务将受信任的响应“反射”回受害者。
• 下载：攻击者在运行同一主机的服务上存储恶意数据，并欺骗后续HTTPS请求下载并呈现该数据，类似于存储的XSS攻击。
• 上传：攻击者 compromise 运行在同一主机上的服务，并将后续HTTPS请求重定向到该服务，导致敏感内容（如cookie头）上传到该服务以供以后检索。

接下来，演讲者评估了流行Web浏览器和FTP、SMTP、IMAP和POP3的应用服务器，并确定：

• 所有浏览器都容易受到至少两种攻击技术（FTP上传 + FTP下载）针对一个或多个FTP服务器包的影响。
• Internet Explorer和Microsoft Edge特别 vulnerable：所有利用方法都适用于一个或多个服务器包。

这一切都很 terrible great，但有多少实际服务器是 vulnerable？事实证明，相当多：在200万运行TLS启用应用服务器（如FTP或SMTP）的独特主机中，超过140万（或69%）也运行HTTPS，使它们可能容易受到一般跨协议攻击。演讲者进一步将其缩小到具有已知可利用应用服务器（如旧版本的ProFTPD）的主机，并识别了超过114,000个可被攻击的HTTPS主机。

那么我们对此能做些什么？演讲者有一些想法：

• 在应用服务器级别，我们可以应用一些合理的对策：像FTP这样的协议应该更严格地接受什么（例如，拒绝看起来像HTTP的请求），并且应该更积极地终止不像有效FTP会话的请求。
• 在证书级别，组织应该警惕通配符和多域证书，并应避免为TLS启用的应用程序共享主机。
• 最后，在协议级别，像ALPN这样的TLS扩展允许客户端指定它们期望与之通信的应用级协议，可能允许目标应用服务器（如SMTP）拒绝重定向的连接。这要求应用服务器不忽略ALPN，它们经常这样做。

要点

尽管已知并 well understood 多年，跨协议攻击今天仍然可能！更糟糕的是，琐碎的扫描揭示了数十万个运行在共享HTTPS上的可利用应用服务器，使利用的门槛非常低。

这个空间尚未 fully explored：像SMTP和FTP这样的应用协议是明显目标，因为它们与HTTP相似，但新协议也出现在互联网服务中，如VPN协议和DTLS。

“隔离安全，组合时 vulnerable”：OpenPGP中的ElGamal

“论OpenPGP中ElGamal的（不）安全性”（幻灯片，视频，论文）的演讲者涵盖了另一个LANGSEC相关问题：单独安全但在互操作时不安全的标准或协议。

演讲者考虑了OpenPGP（RFC 4880）实现中的ElGamal，因为它在OpenPGP要求的不对称方案中具有（ahem）独特地位：

• 与RSA（PKCS#1）和ECDH（RFC 6637）不同，ElGamal没有正式或官方规范！
• ElGamal的两个“官方”参考文献是原始论文本身和1997年版的《应用密码学手册》，它们在参数选择技术上不同意！OpenPGP RFC引用了两者；演讲者得出结论，RFC意图原始论文是权威的。

（顺便说一句，您知道这仍然是密码协议的常见问题，包括零知识、MPC和阈值方案吗？如果这听起来可怕（它是）并且像您想避免的东西（它是），您应该查看ZKDocs！我们已经完成了理解零知识生态系统中协议和方案设计最佳实践的艰苦工作，因此您不必这样做。）

演讲者评估了三个支持ElGamal密钥生成的PGP实现（GnuPG、Botan和libcrypto++），并发现没有一个遵守RFC 4880关于参数选择：所有三个使用不同的素数生成方法。

但这仅仅是开始：许多OpenPGP实现是专有的或受到长期变化的影响，使得仅从开源代码库评估真实世界与标准的偏差变得困难。为了了解真实世界，演讲者调查了超过800,000个真实世界的ElGamal密钥，并发现：

• 大多数密钥似乎使用“安全素数”技术生成。
• 很大一部分似乎使用Lim-Lee素数。
• 一小部分似乎使用Schnorr或类似素数。
• 仅5%似乎使用“准安全”素数，可能表明意图符合RFC 4880的素数生成要求。

这些素数生成技术中的每一个单独（可能）是安全的……但组合时不是：Go、GnuPG和libcrypto++的针对ElGamal公钥的加密实现都容易受到侧信道攻击，因为野外ElGamal密钥使用的意外素数生成技术导致明文恢复。

底线：在大约800,000个 surveyed 密钥中，大约2,000个由于用于生成它们的“短指数”优化而容易受到实际明文恢复。为了验证其攻击的可行性，演讲者在GPG执行加密的大约2.5小时侧信道分析后成功恢复了加密消息的明文。

要点

ElGamal是一个古老、 well understood 的密码系统，其参数和安全属性在纸面上是直接的（很像RSA），但在实际实现中受到显著模糊性和多样性的影响。标准对安全很重要，ElGamal需要一个真正的标准！

密码系统安全是 pernicious：通过自己的输入意识到潜在的侧信道是不够的；签名和加密方案还必须抵抗不良（或甚至只是不寻常）生成的密钥、证书等。

荣誉提名

今年的RWC有很多非常棒的演讲—太多无法在一篇博客文章中突出显示。我们真正喜欢的其他一些包括：

• “零知识中间盒”（幻灯片，视频，论文）：公司目前依赖TLS中间盒（和其他网络管理技术，如DNS过滤）来执行公司数据和安全策略。中间盒是强大的工具，容易受到隐私滥用（以及随后 savvy