インドのある認証機関が秘密鍵を8本作った。そのうち1本の値は4だった。
先週金曜の午後8時6分、Wayneという研究者がこの件をFirefoxとChromeに報告した。同日午後9時48分、Mozillaのスタッフは自分たちで8本すべての鍵を割り出した。相手がどんな方法を使ったのかは聞かなかった。午後10時59分には、ブロックリストがFirefoxのデフォルト設定に反映された。3時間もかからなかった。
これらは本来、P-384曲線の秘密鍵で、通常なら探索空間は10進数で116桁に相当する。
実測値はそれぞれ4、56、115。最大のものでも237しかなく、すべて256未満だった。研究者のScott Helmeによると、公開証明書から8本すべてを取り出すのに1秒もかからなかったという。取り出した。あっという間に。
証明書の問題が起きると、ハッキングされたと思う人は多い。今回は違う。実際、データセンターに侵入者はおらず、データも失われず、物理的・論理的な管理体制もすべて健全だった。eMudhraがムンバイ証券取引所とインド国立証券取引所に提出した発表には、そう書かれている。では、なぜこの鍵は弱くなったのか。鍵生成スクリプトに誤りがあった。昨年4月30日の鍵生成セレモニーは、FIPS 140-2レベル3のハードウェアモジュールを使い、手順どおりに最後まで行われた。その最中に、wrapとunwrapの工程で弱い鍵がもう一組作られてしまった。しかもラベルがよく似ていた。その後、署名要求を作る際に取り違え、弱いほうを送ってしまった。
監査は2年連続で合格し、その時点、つまり2025年半ばには、ブラウザーの信頼リストにも入っていた。それなのに18か月もの間、誰も気づかなかった。監査で確認するのは、手順が文書どおりに実施されたかどうかであって、その鍵のランダム性が十分かどうかではない。
問題は信頼チェーンの構造にもある。中間CAが署名した証明書は、下流がすべて受け入れる。8本の中間鍵のうち6本はTLS用、2本はコード署名用だった。Security BrigadeのYash Kadakiaは、現在も使われている正規の証明書が約3万枚、移行を迫られると見積もっている。また、世界のインターネットの信頼チェーンでは、ある企業の失敗によって、その企業と一度も取引したことのない組織まで巻き添えになると話した。
4社のブラウザーがどれだけ速く対応したか、見てみよう。ChromeとFirefoxは17日中にブロック。Appleは19日。Microsoftは20日。Cloudflareは19日に報告を受け、20日にレポートを公開した。Googleがブロックしたのは公開鍵のハッシュだったので、同じ鍵で作られたクロス署名証明書もまとめてブロックされた。再起動すら必要なかった。この対応は見事だった。
本当にカバーできていないのは、ブラウザーの外だ。Goで書かれたサービス、certifiを使うPythonプログラム、Rustのwebpki-roots、独自の証明書ストアを同梱した多数のAndroidアプリ、データセンターの古いJavaシステム、企業ゲートウェイ、カメラ、ルーター。これらの信頼リストはChromeのものとはまったく別だ。ブラウザー側は3時間で直ったが、こうしたコンポーネントはそれぞれのバージョンが更新されるのを待つしかない。修正が早いかどうかは、そのコンポーネントがどれくらいの頻度で更新されるか次第で、事故の規模とはあまり関係がない。あなたの家のルーターは、どれくらいの頻度で更新されているか知っているだろうか。誰も集計していないし、今のところ確かな答えもない。
MozillaのDennis Jacksonは、クライアントがまだこれらの証明書を信頼しているか確認できるテストページを公開した。数十秒で済む。自分でアクセスしてみてほしい。
残りの部分こそ、考える価値がある。HTTPS全体は、実のところリストの上に成り立っている。「私が信頼する企業のリストを渡す。リストにない企業は信頼しない」という仕組みだ。問題が起きたあとにできる最も強力な対応は、その名前をリストから消すこと。消すことはできる。リストを握っているのはブラウザーであって、問題を起こした企業ではない。
ブロックチェーンの仕組みは逆だ。ビットコインでは、どこかの企業が署名すれば全員がそれを信頼する、ということはない。各ノードが最初の取引から、すべての履歴を自分で検証する。遅い。愚直だ。電力も食う。だが、問題が起きても、4社のブラウザーがそれぞれリストを発行するのを待つ必要はない。その代償も現実的だ。ブロックチェーンにはそもそも取り消しという仕組みがなく、間違って発行されたものは台帳に永久に残る。
クロスチェーンブリッジのマルチシグ、オラクルの価格フィード、ステーブルコインの準備金証明がしていることは、中間CAとまったく同じだ。上流が署名すれば、下流は信頼する。問題が起きれば、今回とさほど変わらない構図になる。
違いは、事後に再検証できるかどうかだけだ。証明書のチェーンでは、リストが更新されるのを待つしかない。台帳のチェーンでは、取引を一つひとつ再検証できる。
実際にやることは2つ。普段使っているサービスを一通り確認し、古い証明書1枚に頼っているものが残っていないか調べる。次に、ウォレットや取引所で出金先のホワイトリストを確認する。マルチシグの署名者3人は、同じオフィス、同じクラウド、同じ電話番号で管理されていないか。この3つのうち2つが重なっていたら、残る安全性は1つ分しかない。
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #証明書チェーン
先週金曜の午後8時6分、Wayneという研究者がこの件をFirefoxとChromeに報告した。同日午後9時48分、Mozillaのスタッフは自分たちで8本すべての鍵を割り出した。相手がどんな方法を使ったのかは聞かなかった。午後10時59分には、ブロックリストがFirefoxのデフォルト設定に反映された。3時間もかからなかった。
これらは本来、P-384曲線の秘密鍵で、通常なら探索空間は10進数で116桁に相当する。
実測値はそれぞれ4、56、115。最大のものでも237しかなく、すべて256未満だった。研究者のScott Helmeによると、公開証明書から8本すべてを取り出すのに1秒もかからなかったという。取り出した。あっという間に。
証明書の問題が起きると、ハッキングされたと思う人は多い。今回は違う。実際、データセンターに侵入者はおらず、データも失われず、物理的・論理的な管理体制もすべて健全だった。eMudhraがムンバイ証券取引所とインド国立証券取引所に提出した発表には、そう書かれている。では、なぜこの鍵は弱くなったのか。鍵生成スクリプトに誤りがあった。昨年4月30日の鍵生成セレモニーは、FIPS 140-2レベル3のハードウェアモジュールを使い、手順どおりに最後まで行われた。その最中に、wrapとunwrapの工程で弱い鍵がもう一組作られてしまった。しかもラベルがよく似ていた。その後、署名要求を作る際に取り違え、弱いほうを送ってしまった。
監査は2年連続で合格し、その時点、つまり2025年半ばには、ブラウザーの信頼リストにも入っていた。それなのに18か月もの間、誰も気づかなかった。監査で確認するのは、手順が文書どおりに実施されたかどうかであって、その鍵のランダム性が十分かどうかではない。
問題は信頼チェーンの構造にもある。中間CAが署名した証明書は、下流がすべて受け入れる。8本の中間鍵のうち6本はTLS用、2本はコード署名用だった。Security BrigadeのYash Kadakiaは、現在も使われている正規の証明書が約3万枚、移行を迫られると見積もっている。また、世界のインターネットの信頼チェーンでは、ある企業の失敗によって、その企業と一度も取引したことのない組織まで巻き添えになると話した。
4社のブラウザーがどれだけ速く対応したか、見てみよう。ChromeとFirefoxは17日中にブロック。Appleは19日。Microsoftは20日。Cloudflareは19日に報告を受け、20日にレポートを公開した。Googleがブロックしたのは公開鍵のハッシュだったので、同じ鍵で作られたクロス署名証明書もまとめてブロックされた。再起動すら必要なかった。この対応は見事だった。
本当にカバーできていないのは、ブラウザーの外だ。Goで書かれたサービス、certifiを使うPythonプログラム、Rustのwebpki-roots、独自の証明書ストアを同梱した多数のAndroidアプリ、データセンターの古いJavaシステム、企業ゲートウェイ、カメラ、ルーター。これらの信頼リストはChromeのものとはまったく別だ。ブラウザー側は3時間で直ったが、こうしたコンポーネントはそれぞれのバージョンが更新されるのを待つしかない。修正が早いかどうかは、そのコンポーネントがどれくらいの頻度で更新されるか次第で、事故の規模とはあまり関係がない。あなたの家のルーターは、どれくらいの頻度で更新されているか知っているだろうか。誰も集計していないし、今のところ確かな答えもない。
MozillaのDennis Jacksonは、クライアントがまだこれらの証明書を信頼しているか確認できるテストページを公開した。数十秒で済む。自分でアクセスしてみてほしい。
残りの部分こそ、考える価値がある。HTTPS全体は、実のところリストの上に成り立っている。「私が信頼する企業のリストを渡す。リストにない企業は信頼しない」という仕組みだ。問題が起きたあとにできる最も強力な対応は、その名前をリストから消すこと。消すことはできる。リストを握っているのはブラウザーであって、問題を起こした企業ではない。
ブロックチェーンの仕組みは逆だ。ビットコインでは、どこかの企業が署名すれば全員がそれを信頼する、ということはない。各ノードが最初の取引から、すべての履歴を自分で検証する。遅い。愚直だ。電力も食う。だが、問題が起きても、4社のブラウザーがそれぞれリストを発行するのを待つ必要はない。その代償も現実的だ。ブロックチェーンにはそもそも取り消しという仕組みがなく、間違って発行されたものは台帳に永久に残る。
クロスチェーンブリッジのマルチシグ、オラクルの価格フィード、ステーブルコインの準備金証明がしていることは、中間CAとまったく同じだ。上流が署名すれば、下流は信頼する。問題が起きれば、今回とさほど変わらない構図になる。
違いは、事後に再検証できるかどうかだけだ。証明書のチェーンでは、リストが更新されるのを待つしかない。台帳のチェーンでは、取引を一つひとつ再検証できる。
実際にやることは2つ。普段使っているサービスを一通り確認し、古い証明書1枚に頼っているものが残っていないか調べる。次に、ウォレットや取引所で出金先のホワイトリストを確認する。マルチシグの署名者3人は、同じオフィス、同じクラウド、同じ電話番号で管理されていないか。この3つのうち2つが重なっていたら、残る安全性は1つ分しかない。
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #証明書チェーン