イーサリアムのTeku・Besu、証明書の欠陥を修正 初期設定ノードは影響なし

インドの認証局eMudhraで起きたセキュリティ事故が、イーサリアムのノードソフトウェアに波及した。イーサリアムのバリデータークライアントTeku（テク）と実行クライアントBesu（ベス）は韓国時間10月27日、eMudhra系のルート証明書を信頼しないようにした新バージョン（Teku 26.10.3、Besu 26.10.2）を公開した。両開発チームは、初期設定で動くメインネットのノードには影響がないとしたが、外部サーバーとHTTPSで接続するノードはアップデートかJavaの点検が必要だと告知した。

1. 2025年4月30日eMudhra、鍵生成の手続きでTLS中間認証局8つを作成
2. 10月17日研究者が公開証明書から秘密鍵を計算できるとアップル・グーグル・マイクロソフト・モジラに同時報告
3. 10月18日eMudhra、中間認証局8つをすべて失効
4. 10月20日OpenJDK、問題の中間認証局を遮断（CVE-2026-91403）
5. 10月23日OpenJDK、eMudhra・セクティゴのルート4つを削除（CVE-2026-114820）
6. 10月27日2時44分Besu 26.10.2公開、Dockerイメージから該当ルートを削除
7. 10月27日13時57分Teku 26.10.3公開、同じ措置
8. 10月28日eMudhra、公開TLS証明書事業から撤退を進めていると明らかに

公開証明書から秘密鍵が割り出された

認証局は、ウェブサイトが本物であることを保証する証明書を発行する機関だ。eMudhraが公式声明で明らかにした経緯によると、2025年4月の鍵生成過程のミスで弱い鍵の組が作られ、それらを使った認証局の証明書がブラウザの信頼リストに登録された。この問題は2回の監査でも見つからなかった。10月17日、ある研究者が公開された証明書だけで中間認証局8つの秘密鍵を復元できると報告した。

eMudhraは、8つのうち7つは一度も使われておらず、残る1つも証明書を発行していないとし、社内システムへの侵入やデータ流出もなかったと説明した。ただしブラウザ側は予防措置として、その上位のルート証明書まで信頼しないことにした。eMudhraは公開TLS証明書事業から自主的に撤退する手続きを進めており、電子署名などほかの事業は続けるとしている。

Javaは失効した証明書も信頼し続けた

ブラウザやOS、Go言語はその後、該当する証明書を遮断した。問題はJavaだ。Tekuの告知によると、Javaは初期設定では証明書の失効を確認しない。このため秘密鍵を手に入れた者は、Javaが本物と受け入れる証明書を作れる。TekuとBesuはいずれもJavaで作られたソフトウェアで、Dockerイメージに入っているEclipse Temurinも対象になる。

Tekuは、26.10.2までのすべてのDockerイメージに修正が適用されていないJavaが入っていると明らかにした。攻撃者がノードと外部サーバーの間の通信を傍受できれば、そのサーバーになりすませるということだ。Tekuが挙げた最悪のケースは2つ。リモートのビーコンノードになりすませば、バリデーターに手数料を攻撃者へ送るブロックを提案させられる。外部署名サーバーになりすませば、取り消せない自発的退出の署名や、手数料を横取りするビルダー登録の署名を得られる。Tekuは実際の攻撃事例は報告されていないとしている。

初期設定のノードは影響なし、リモート接続が焦点

Tekuは、設定にhttpsのアドレスが1つもないメインネットの初期設定ノードは何の対応も不要だとした。外部署名サーバー、リモートのビーコンノード、ビルダー・リレー、リモートの実行クライアント、チェックポイント同期アドレスなど、ほかのサーバーにHTTPSで接続する設定を使う場合だけが対象だ。ノード同士がやり取りするP2P通信は認証局を使わないため関係ない。

Besuは受信側の接続のリスクも指摘した。JSON-RPC TLSで認証局が署名した証明書を持つクライアントを受け入れるオプション（--rpc-http-tls-ca-clients-enabled）を有効にしていれば、通信を傍受しなくても攻撃者が証明書を作って直接接続でき、最も深刻なケースに分類した。Engine APIのポートも同じ設定を使う。

イーサリアムは韓国時間29日午後3時30分時点で、アップビットで310万7000ウォンで取引され、前日比1.7%下落した。