侵害されたTLS証明書

インドの認証局eMudhra Limitedが発行したTLS証明書8枚に、あきれるほど脆弱な秘密鍵が使われていたことが判明しました。

侵害されたeMudhraの鍵は、この問題を調べている多くのエンジニアの想像を超えるレベルの欠陥を抱えていました。NIST P-384楕円曲線暗号の秘密鍵は通常、約384ビットのエントロピーを持ち、2³⁸⁴通り、つまり116桁の数に及ぶ組み合わせが考えられます。ところが、侵害された鍵の秘密鍵サイズは3〜8ビットしかありませんでした。驚くべきことに、秘密鍵の値は4、56、66、115、155、156、230、237でした。

「これは『あり得ないはず』というカテゴリーの極みです」とValdorda氏は語ります。「非常に危険な鍵生成インターフェースに『サイズ』パラメータがあり、誤って1に設定してしまったのでは？」

BGP.toolsのディレクターを務めるBen Cartwright-Cox氏は次のように述べています。「サンプルコードが誤って本番環境に流出したのだと思いますが、確かなことは分かりません。ただ、誰も気づかなかったのは常軌を逸しています」

現時点で最も差し迫った脅威は、VPNの利用者に及ぶとみられます。特に、政府が悪意を持って通信を傍受する可能性が高い国では注意が必要です。ほかにも懸念されるケースは多いでしょう。エンドユーザーにできる対策はほとんどなく、更新が適用されたとの保証を得るまで、ブラウザ以外のTLS通信の多くの利用を控えるしかありません。

証明書の仕組み全体が、以前から混乱を抱えてきました。

今回の件は、TLSの仕組みに致命的な欠陥があることを改めて示しました。TLSは最も弱い部分の強度でしか守れず、今回それはeMudhraでした。幸い、証明書の透明性ログが問題の多くを捕捉しましたが、この対策では関係者が膨大なフィードを自ら監視する必要があります。しかも、不正な証明書が発行された後でなければ機能しません。eMudhraの担当者には、すぐには取材に応じてもらえませんでした。

ただし、注意点があります。侵害された証明書を悪用するには、中間者攻撃を仕掛ける必要があります。攻撃者はTLS通信を行う2者の間でプロキシとして動作し、暗号化された通信を受信して復号し、再び暗号化して相手に送らなければなりません。こうした能力は、場合によっては、潤沢なリソースを持つ攻撃者に限られるのが一般的です。一方、カフェや大学などの組織でローカルネットワークを掌握している人物にとっては、はるかに容易な攻撃です。

この後始末もまた、混乱を極めそうです。しかも、PHPの脆弱性への対応とちょうど重なっています。

関連情報として、こちら、こちら、こちらもご覧ください。