你的 MCU 很可能未受 eMudhra 中间 CA 遭入侵事件的影响

# 你的 MCU 很可能未受 eMudhra 中间 CA 泄露事件影响 来源：https://danielmangum.com/posts/mcu-emudhra-intermediate-ca-compromise/ 如果你是一名软件工程师，或者从事科技行业，那么你很可能已经听说了昨天（2026 年 10 月 20 日）披露的 eMudhra 中间 CA 泄露事件 (https://emudhra.we-have-a-problem.com/)，披露信息见 (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE?pli=1)\。如果你还没听说，你可能也已经注意到，自己使用的各种产品最近软件更新变多了\。 我不打算完整介绍这件事的背景，因为已经有很多其他文章介绍了此次泄露的细节，包括 Mozilla 现已公开的漏洞报告 (https://bugzilla.mozilla.org/show_bug.cgi?id=2083449)\。不过，已经有不少人联系我，询问它对物联网设备，特别是微控制器 \(MCU\) 类设备的影响\。其中一些人可能是看到了围绕此次泄露的讨论，例如 Russ Cox 的 Bluesky 帖子 (https://bsky.app/profile/swtch.com/post/3mydfmedrrc2d)，其中写道： > 那些无法更新或不进行更新的物联网设备，现在很容易遭到中间人攻击，而且会永远如此\。 截至撰文时，Scott Helme 的文章 (https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/) 位居 Hacker News 榜首，其中也发出了强烈警告\。 > **物联网、嵌入式和 OT 设备\。**摄像头、路由器、汽车、医疗设备、智能家电、支付终端，以及向后端请求指令和更新的工业控制器\。它们的证书包到 2039 年之前都不会变，这让“无法控制影响范围”的说法变成了现实\。 如今，“物联网”是一个不太容易界定的称谓\。如果你认为 Raspberry Pi 这样的单板计算机 \(或者实际上任何运行 Linux 的设备\) 属于物联网设备，那么上述说法很可能是正确的\。希望你已经为这些设备配备了 OTA 更新方案，而且**你应该尽快更新它们**\。另一方面，如果你管理着一批 MCU，那么你很可能不会受到此次泄露的 \(直接\) 影响\。要理解其中的原因，至少需要对公钥基础设施 \(PKI\)，尤其是 Web PKI，有一个粗略的了解\。 你正在用来阅读这篇文章的设备上，有一个根证书颁发机构 \(CA\) 证书包\。事实上，设备上几乎肯定存在多个 CA 证书包，因为你的平台 \(即操作系统\) 自带一个证书包，而你的浏览器也可能自带一个\。自 Firefox 最初发布 (https://blog.mozilla.org/security/2019/02/14/why-does-mozilla-maintain-our-own-root-certificate-store/) 以来，Mozilla 就一直维护着专门的 CA 证书计划 (https://wiki.mozilla.org/CA)，Chrome 也在 2022 年宣布推出自己的根证书计划 (https://blog.chromium.org/2022/09/announcing-launch-of-chrome-root-program.html)，采取了同样的做法\。这些根证书是“信任锚”，使与你通信的互联网服务能够证明自己的身份\。你在浏览器中通过 HTTPS 访问的每个网站，都会出示一个或多个证书来验证自己的身份，而这些证书都可以追溯到客户端证书包中的某个 CA 证书\。例如，当你访问这篇博客文章时，托管它的服务器向你的浏览器出示了以下证书链\。 `` Certificate chain 0 s:CN=danielmangum.com i:C=US, O=Let's Encrypt, CN=YR1 a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: Aug 24 08:02:52 2026 GMT; NotAfter: Nov 22 08:02:51 2026 GMT 1 s:C=US, O=Let's Encrypt, CN=YR1 i:C=US, O=ISRG, CN=Root YR a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: Sep 3 00:00:00 2025 GMT; NotAfter: Sep 2 23:59:59 2028 GMT 2 s:C=US, O=ISRG, CN=Root YR i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep 2 23:59:59 2032 GMT `` 你可以使用 `openssl s\_client \-showcerts \-verify 5 \-connect danielmangum\.com:443` 自行查看\。 第一个证书 \(`danielmangum\.com`\) 指明它由第二个证书 \(`YR1`\) 签名，而第二个证书由第三个证书 \(`Root YR`\) 签名\。第三个证书指明其颁发者是 `ISRG Root X1`，这是一个*极为*常见的 Let’s Encrypt 根 CA 证书，存在于所有主流信任库中：(https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/root_store.md)、(https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootCertificateReport)、(https://support.apple.com/en-us/126047)、(https://ccadb.my.salesforce-sites.com/microsoft/IncludedCACertificateReportForMSFT)\。由于你的信任库中包含 `ISRG Root X1`，而服务器又向你发送了建立通往该可信根的信任链所需的证书，因此你可以确信，自己确实是在与 `danielmangum\.com` 通信\。Let’s Encrypt 提供了一张实用的图示 (https://letsencrypt.org/certificates/)，用于说明这条信任链\。 与这个网站建立安全连接本身或许并非至关重要，但正是这套系统让我们能够执行发送私人消息、管理银行账户、使用信用卡支付等敏感操作，而不必担心攻击者窃取数据\。在 eMudhra 泄露事件中，八个中间 CA 证书的私钥可以从公共互联网上获取，这些证书类似于上面的 `Root YR` 和 `YR1`\。这些私钥还恰好极其薄弱：P\-384 密钥的高 376 位全为零\。其中一个私钥竟然就是数字 `4` \(`00000100`\)\。这意味着，只要具备中等程度的技术能力，就能轻易为自己签发一个叶证书 \(例如 `danielmangum\.com`\)，然后出示这个叶证书和中间证书，任何包含 eMudhra 根 CA 证书的信任库都会信任它\。不幸的是，上述所有主流根证书计划都包含了该根证书\。 一些客户端，主要是浏览器，还要求叶证书必须被收录到证书透明度 \(CT\) 日志 (https://certificate.transparency.dev/) 中，才会信任它\。因此，主流浏览器能够相对有把握地断言 (https://emudhra.we-have-a-problem.com/#cause)，其软件用户未受影响，而其他软件则很可能受到了影响\。 > CA 在生成这些中间证书的私钥时出现了错误\。这意味着任何人都可以从证书中还原出这些私钥\。 > 自这些证书于 2025 年 4 月创建以来，这种攻击就一直有可能发生\。在此期间，证书透明度日志中没有这些中间证书的相关条目，这表明 Firefox、Chrome、Edge 和 Safari 等强制执行 CT 要求的客户端不可能遭受这类攻击\。 > 然而，浏览器生态系统之外的许多客户端并不强制执行证书透明度要求\。我们不知道攻击者是否利用了有缺陷的密钥生成方式来攻击这些客户端\。 此次泄露披露后，编程语言 (https://groups.google.com/g/golang-announce/c/66pojueaQek)、开发工具 (https://github.com/astral-sh/uv/releases/tag/0.13.4)、操作系统软件包 (https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/2171507)，以及几乎所有涉及建立 TLS 连接 (https://en.wikipedia.org/wiki/Transport_Layer_Security) 的软件，都开始争分夺秒地采取措施，要么过滤掉这些已泄露的中间证书，要么彻底拒绝 eMudhra 根 CA 证书\。说这个问题影响广泛，都算是轻描淡写了\。 那么，为什么 MCU 不太可能受到影响呢？简而言之，是因为资源限制\。在服务器、台式计算机，甚至单板计算机上包含一个或多个 X\.509 (https://en.wikipedia.org/wiki/X.509) 证书包，带来的影响微乎其微 \(区区几 KB 又算得了什么？\)，但对于非易失性存储空间通常不足 1 MB，有时甚至远小于 1 MB 的设备，我们必须精打细算得多\。此外，我们通常需要负责整个系统，要么构建裸机应用程序，要么使用轻量级实时操作系统 \(RTOS\)，而不能依赖操作系统或浏览器厂商来完成评估和监控候选根 CA 证书这一繁琐的过程\。 例如，Zephyr RTOS (https://github.com/zephyrproject-rtos/zephyr) 中的 HTTP GET 示例 (https://github.com/zephyrproject-rtos/zephyr/tree/1405adc9a6042353ff791573d913fa6b202580a6/samples/net/sockets/http_get) 会连接到 `google\.com`\。它的信任链如下\。 `` Certificate chain 0 s:CN=*.google.com i:C=US, O=Google Trust Services, CN=WE2 a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256 v:NotBefore: Sep 28 18:38:33 2026 GMT; NotAfter: Dec 21 18:38:32 2026 GMT 1 s:C=US, O=Google Trust Services, CN=WE2 i:C=US, O=Google Trust Services LLC, CN=GTS Root R4 a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384 v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT 2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R4 i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption v:NotBefore: Nov 15 03:43:21 2023 GMT; NotAfter: Jan 28 00:00:42 2028 GMT `` 这个示例没有包含一组覆盖互联网大部分服务的通用根 CA 证书，而是只包含验证 `google\.com` 所需的那一个根 CA 证书 (https://github.com/zephyrproject-rtos/zephyr/blob/1405adc9a6042353ff791573d913fa6b202580a6/samples/net/sockets/http_get/src/globalsign_r1.der) \(`GlobalSign R1`\)\。仅这一个证书就接近 1 KB \(采用 DER 编码\)，但证书大小并非唯一需要考虑的因素\。启用整条证书链使用的所有签名算法、曲线和哈希算法，也可能显著增加代码体积\。此外，还必须配置足以容纳完整证书链的缓冲区；证书链越长，需要分配的内存就越多\。 这些限制可能导致令人沮丧的错误和复杂的调试过程\。不过，构建一个只专注于完成一组固定、明确定义的任务的系统，也有其可取之处\。当 eMudhra 泄露这样的事件发生时，我会更加欣赏这些设备固有的限制，以及为其构建固件时所投入的审慎思考\。也许，这次事件可以成为一个契机，让我们评估能否将这种审慎思考也应用到其他领域\。 除非你的 MCU 需要连接到某个服务器，而该服务器使用的信任链以 eMudhra 根 CA 证书为根，并且你的固件中包含了该证书 \(或用于交叉签名的 Sectigo 根 CA 证书 (https://emudhra.we-have-a-problem.com/#intermediates)\)，否则你的设备很可能不会受到这一特定漏洞的影响\。现在，你只需要确保为所有 CI 环境、开发工具、云服务和生产力软件打好补丁就行了\。