認証機関の秘密鍵が極端に短く、ミリ秒で解読可能だったと海外で話題
姉妹サイトの新着
インドの認証機関eMudhraが発行した中間CAの秘密鍵が、ごく小さな整数しか使っておらずミリ秒で解析できるレベルだったことが分かり、Hacker Newsで話題になっている。この件は以前にも別スレ(947ポイント、408コメント)で大きく取り上げられており、今回はその続報記事への反応。レスでは「単なる不手際か、意図的なものか」で意見が分かれ、さらに元記事自体がAIで書かれているのではという指摘まで出て議論が広がった。
信頼のわずか8ビット――eMudhraのCA鍵はミリ秒で解読された
出典: scotthelme.co.uk / 元記事はこちら
今になって思うと、信頼する認証機関(CA)を100個も置いていたのはさすがに多すぎたかもしれない。
>>2 今になって思うと、ちょっとした能力チェックすら設けていなかったのは手落ちだったかもね。
関連スレ：「eMudhraの中間CAが危殆化」｜947ポイント｜19時間前｜408コメント
誰かあの『常に同じ値しか返さない乱数生成器』を使ったんじゃないか。(random.orgの分析ページへのリンクあり)
そりゃ簡単に解けるに決まってる、4は素数でもないんだから！
>>5 弁護すると、たぶん本当はメルセンヌ素数の2^2-1を狙っていて、タイプミスしただけじゃないか。
>>5 その前に使っていた3つの秘密鍵の値にも誰も気づかなかったのは、ある意味すごい。
>>5 おい、それ俺のスーツケースの番号と同じじゃないか！
影響範囲について、あと2点補足しておく。Flatpakは(たしか)選択したランタイムに組み込まれた信頼ストアを使うので、システムのパッケージを更新してもアプリ側は影響を受けたままになりうる。コンテナもホストの信頼ストアを継承せず、ベースイメージのものを使うので同様に注意が必要。
近いうちに『これは故意だった』と判明しても驚かない。
>>7 それは微妙だと思う。本当に故意にやるなら、自分でコントロールできてかつ怪しまれない値を選ぶはず。『98761316832165974216498789746』のような値なら誰もランダムじゃないと疑わないけど、『000000000000000123』みたいな値は逆に怪しく見える。
>>7 単に手順がひどく杜撰だっただけに聞こえる。しかも残念なことに、CA業界ではそれが珍しくないんじゃないかと思う。
>>7 なぜ故意だと思うんだ？
これはもう過失というレベルじゃない、重過失だろう。8ビットなんて正気じゃない！
>>8 『4』――おいChatGPT、秘密鍵って何だっけ？
どの鍵の値も384未満だった。まさかそんなわけ…
こんなに盛大に壊れて、しかもその原因がバカバカしいほど単純だと、むしろちょっと安心する部分がある。例えるなら[人為的な大惨事]が、実は『三ばか大将』のエピソードが原因だったみたいな感じ。
秘密鍵を手で選んだんじゃないかって気がしてくる。
>>11 職人技の暗号技術だな。オーガニック素材のナンスで味付けした、手摘みの秘密鍵ってやつだ。
>>11 昔はワンタイムパッドも、球形の抽選機から女性が番号付きの玉を手で取り出して選んでいたものだよ。
HNは投稿記事をPangram(AI判定ツール)に通すようにしてくれないか。読者がうんざりするAI臭い文章を読まされずに済むように。
>>13 自分には普通に読めたけど。もしAIが書いているなら、どのAIか教えてほしい、自分も使いたいから。
>>32 自分にも違和感なく読めたけど、Pangramでは『混在』判定が出てる。『秘密鍵とは実際に何か』のセクションや『なぜ“封じ込め”できないのか』のセクションなどがAI生成と判定されてる。
>>32 たぶん人間とAIの混在文章だと思う。楕円曲線鍵の仕組みを説明している部分が特にイライラする書き方なんだけど、困ったことに自分にとって新しい情報が得られたのもそこだけだった。
はは！0x000…0は『誰もそんな値を試そうとは思わない』からこそ一番安全な秘密鍵だ！まさに自分の銀行の暗証番号が1234なのと同じ理屈だな！
『これらのCAに連なるTLS証明書はCT(証明書の透明性ログ)に一件も出てこなかった』とあるけど、1年前に作られてから証明書を一枚も発行していないCAを、なぜブラウザは信頼し続けているんだ？
>>15 これらは中間CAで、信頼されたルート証明書によって署名されている。だからOSやブラウザからの信頼は、そのルートを信頼している時点で暗黙的に付与されている。
これはあまり出来のいい記事じゃない。昨日の議論の方がデータも良くて、自己宣伝も少なくて、『数字が小さい』と言うだけでなく、実際になぜそうなったのかをきちんと問うていた。
他サイトの新着
eMudhra側の説明はMozillaのBugzilla(バグ管理システム)に出ている。ただ、バグがあったからといって、なぜそこまで酷い鍵のペアが二度も生成され、しかも人間がそれを実際に使ってしまったのか理解しづらい。『悪意で説明できることを愚かさのせいにしてはいけない』とは言うものの、今回は正直疑いたくなる。
>>17 十分に巧妙な悪意は、愚かさと見分けがつかない。
>>17 それに加えて、エコシステム全体にも同じくらいの愚かさがある。CAを信頼リストに追加する前に、エントロピーが8ビットしかないといった初歩的な欠陥を検出する『ユニットテスト』すら存在しないらしい。次は公開鍵をググったら2年前のPastebinに秘密鍵が転がっているのが見つかる、なんてことになるんじゃないか。
まあ、少なくとも覚えやすい鍵だったな…
>>12 まさにこれ、彼らが使った手順そのものだろう。
>>20 『弁護すると、メルセンヌ素数の2^2-1を狙ってタイプミスしたんだろう』――コンピュータサイエンスには2つの難問がある。名前付けと、キャッシュの無効化、そしてオフバイワンエラーだ。
>>21 実際には気づいていたと思うけど、公表されなかったんじゃないかな。
>>24 どうしてその多くが怪しく見えるんだ？
>>26 CAの鍵を手に入れたら何ができるか、本当に一つ一つ説明しないと分からないか？
>>27 『1から10の間で数字を思いついて』と言われたときの“正解”はだいたい7になる、というあの法則を当て込んでいたのかもね。
>>29 ブルックリン発。オーバーオール姿でワックスで固めた口ひげのおじさんが、一つずつビットを手渡ししてくれるタイプの店だな。
>>29 愛情込めて手作り。
この話題の背景と論点
CA(認証機関)はブラウザやOSが「このサーバー証明書は本物」と判断する際に信頼している発行元で、世界でおよそ100前後の組織がこの立場にある。Mozillaのバグ管理システム(Bugzilla)はCAの信頼プログラムの運用にも使われており、eMudhra側の説明もそこに記載されている。スレで意見が割れたのは、秘密鍵の値が極端に小さかった原因を「ずさんな鍵生成手順によるミス」と見るか「何らかの意図があった」と見るかの点。一方で、今回の技術的な経緯自体は元記事でも十分に説明されておらず、その元記事がAIによって書かれた疑いがあるという別の議論も並行して起きている点は、本文だけでは見落としやすい。
※本記事は海外掲示板 Hacker News のスレッド「Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。