あなたのMCUはおそらくeMudhra中間CAの侵害を免れた

あなたのMCUはおそらくeMudhra中間CAの侵害を免れた

あなたがソフトウェアエンジニアであるか、あるいは一般的にテクノロジー業界で働いているなら、昨日（2026年10月20日）に開示されたeMudhra中間CAの侵害について耳にした可能性が高いでしょう。もし耳にしていないなら、あなたが使用している様々な製品のソフトウェアアップデートの増加に気づいたかもしれません。

この状況の全容については、侵害の詳細を説明しているMozillaの公開されたバグレポートを含む、他の多くの投稿があるのでここでは触れません。しかし、IoTデバイス、特にマイクロコントローラー（MCU）クラスのデバイスへの影響について、多くの人々から問い合わせを受けています。中には、Russ CoxのBluesky投稿にあるような、侵害を巡る議論に動機づけられた人もいるかもしれません。

更新できない、または更新しないIoTボックスは、永遠に容易にMITM（中間者攻撃）可能になります。

執筆時点でHacker NewsのトップにいるScott Helmeの投稿も、強い警告を含んでいました。

IoT、組み込み、OTデバイス。 カメラ、ルーター、車、医療機器、スマート家電、決済端末、そしてコマンドやアップデートのために通信する産業用コントローラー。それらのバンドルは2039年まで凍結されており、「封じ込め不可能」という現実が実現します。

今日、IoTという言葉は扱いにくいものです。Raspberry Piのようなシングルボードコンピューター（あるいはLinuxが動作するほぼ全てのデバイス）をIoTデバイスと見なすなら、上記の主張が正しい可能性が高いです。これらのデバイスにはOTAアップデートソリューションがあると期待しており、できるだけ早く更新すべきです。一方で、もしあなたがMCUのフリートを持っているなら、おそらく（直接的には）侵害の影響を受けていないでしょう。その理由を理解するには、公開鍵基盤（PKI）、特にWeb PKIについて最低限の知識を持つ必要があります。

この投稿を読んでいるデバイス上には、ルート証明書認証局（CA）証明書のバンドルがあります。実際、あなたのプラットフォーム（つまりオペレーティングシステム）がバンドルを出荷し、ブラウザも同様であるため、複数のCA証明書バンドルがほぼ確実に存在します。MozillaはFirefoxの初期リリース以来、専用のCA証明書プログラムを維持しており、Chromeも2022年にルートプログラムを発表して追随しました。これらのルート証明書は、「信頼のアンカー」として機能し、あなたが通信するインターネットサービスが、それが誰であるかを証明できるようにします。ブラウザでアクセスする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）は2番目（YR1）によって署名されていることを指定し、2番目は3番目（Root YR）によって署名されています。3番目は発行者をISRG Root X1と指定しており、これはあらゆる 主要な 信頼 ストアに含まれている、非常に一般的なLet's EncryptのルートCA証明書です。ISRG Root X1があなたのトラストストアに含まれており、サーバーが信頼できるルートへの信頼チェーンを確立するために必要な証明書セットを提示したため、あなたが実際にdanielmangum.comと通信していると確信できます。Let's Encryptには、この信頼チェーンを説明する役立つ図があります。

このサイトとの安全な接続確立自体が重要でないかもしれませんが、このシステムは、攻撃者にデータを盗まれる恐れなく、プライベートメッセージの送信、銀行口座の管理、クレジットカードでの支払いといった機密性の高い操作を実行することを可能にしています。eMudhraの侵害では、上記Root YRやYR1に似た8つの中間CA証明書の秘密鍵が、公開インターネット上でアクセス可能になっていました。秘密鍵は非常に弱く、P-384鍵のトップ376ビットはすべてゼロでした。秘密鍵の一つは文字通り数字の4（00000100）でした。これは、中程度の技術力を持つ人でも容易にリーフ証明書（danielmangum.comのようなもの）を発行でき、その後リーフと中間証明書を提示すれば、eMudhraのルートCA証明書を含んでいたすべてのトラストストアによって信頼されることを意味します。残念ながら、それにはすべての主要なルートプログラムが含まれていました。

一部のクライアント、特にブラウザは、信頼を得るためにリーフ証明書が証明書透明性（CT）ログに含まれていることも要求します。これにより、主要なブラウザは、ソフトウェアのユーザーが影響を受けなかったと比較的自信を持って主張できるようになりましたが、他のソフトウェアは影響を受けた可能性が十分にあります。

中間証明書の秘密鍵は、CAによって誤って生成されました。これは、誰でも証明書からそれらを復元できることを意味します。

証明書は2025年4月に作成されたため、これは可能でした。この期間の中間証明書については、証明書透明性ログにエントリがないため、Firefox、Chrome、Edge、SafariのようなCT強制クライアントは攻撃されなかったことを示しています。

しかし、ブラウザエコシステムの外部にある多くのクライアントは、証明書透明性を強制しません。攻撃者が欠陥のある鍵生成を利用してこれらのクライアントを標的にしたかどうかは不明です。

この侵害の開示は、プログラミング言語、開発者ツール、OSパッケージ、そして本質的にTLS接続に関わるあらゆるソフトウェアの間で、これらの侵害された中間証明書をフィルタリングするか、eMudhraルートCA証明書を完全に拒否するための駆け込み作業を引き起こしました。この問題が広範囲に及んでいると言っても過言ではありません。

では、なぜMCUは影響を受けにくいのでしょうか？簡単に言えば、リソースの制約のためです。サーバー、デスクトップマシン、あるいはシングルボードコンピューターにX.509証明書のバンドル、または複数のバンドルを含めることは、取るに足らない影響（数キロバイトが何になるというのか？）ですが、1MB未満、時にはそれよりはるかに少ない不揮発性ストレージしか持たないデバイスをターゲットにする場合、私たちははるかに慎重にならなければなりません。さらに、OSやブラウザベンダーが候補となるルートCA証明書の評価と監視という骨の折れるプロセスを経ることに依存するのではなく、ベアメタルアプリケーションを構築するか、軽量リアルタイムオペレーティングシステム（RTOS）を活用するかによって、通常はシステム全体に責任を負います。

例えば、Zephyr RTOSの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証明書（GlobalSign R1）のみを含んでいます。それ自体で約1KB（DERエンコード）ですが、証明書のサイズだけが考慮事項ではありません。証明書チェーン全体で使用されるすべての署名アルゴリズム、曲線、ハッシュアルゴリズムを有効にすると、コードサイズにも大きな影響を与える可能性があります。さらに、バッファサイズは完全なチェーンに対応するように設定する必要があります。チェーンが長いほど、割り当てる必要のあるメモリが増えます。

これらの制約は、イライラするエラーや複雑なデバッグセッションにつながる可能性があります。しかし、固定された、明確に定義されたタスクのセットを達成することに特化したシステムを構築することには、何か価値があると言えます。eMudhraの侵害のような状況が発生したとき、私はこれらのデバイスの固有の制限と、それらを動かすファームウェアを構築する際の意図に感謝するようになります。おそらく、このイベントは、その意図の一部を他のドメインに適用できるかどうかを評価する機会となるでしょう。

あなたのMCUがeMudhraルートCA証明書に根ざした信頼チェーンを使用するサーバーに接続する必要があり、それをファームウェアに含めた（またはクロス署用に使用されたSectigoルートCA証明書を含めた）場合を除き、あなたのデバイスはこの特定の脆弱性から安全である可能性が高いです。さて、あとは、すべてのCI環境、開発者ツール、クラウドサービス、および生産性ソフトウェアをパッチすることを確実にすることだけです。