<前の日記(2005-09-22) 次の日記(2005-09-24)> 最新

おおいわのこめんと (2005-09-23)


2005-09-23

[Security] 40ビット暗号の攻撃可能性

SSL の話がだいぶあちこちで話題になっているようで、例えば もりぶさんの日記 などでもこんな疑問が出ている。

Firefox 1.0.6やSeaMonkeyで接続すると「低程度な暗号化を使ったページを要求しています」という警告出るんだけれど、これは安全なのでしょうか? 特に問題無いならどうでもいい話ですが。

というわけで、果たして現実に40ビット暗号はどれくらい攻撃可能なのか? というのを 検証してみようというのが今日のお題。今回は SSL2 の 40bit RC4 暗号化をターゲットにする。

[SSL2 の RC4-40 鍵生成]

まず、SSL2.0 の 40ビット RC4 暗号化での暗号鍵の作り方をざっとおさらいしておくと、

  1. クライアントが
    • 88ビットの乱数を平文で
    • 40ビットの乱数をRSA暗号化して
    サーバに送信
  2. サーバとクライアントはそれぞれ、それらを結合した128ビット乱数 (master key) と、 セッションのパラメータ(平文で送られている)を MD5 にかけて、 128ビットの RC4 鍵 (session key) を作る
  3. この鍵を使って RC4 乱数ストリームを作り、平文とXORすることで通信を暗号化する

という過程になる。HTTPS での一般的な利用を考えると、平文の一部は十分に推測 できると考えられるので、平文と暗号文のペアが1つ存在すると 仮定してよいだろう。RC4 の性質上、平文が解っていれば、乱数ストリームは 直ちに得られるので、あとは使用中の乱数ストリームがどの鍵に対応するかを調べれば、 session key が得られる。

ただ、実は40ビット暗号化でも暗号鍵自体は128ビットあるので、これは辞書を使っても 全探索するのは現実的でない。従って、実際には session key を辞書攻撃するより、 40bit の秘密 master key の方を全探索してやるほうが効率がよいと思われる。 こちらはセッションのパラメータが入力に含まれているため、辞書は使えず、その場で 全部計算してやることになる。

そうすると、1つの鍵を調べるのに、RC4 1回と、MD5 1回の操作が必要となる。 MD5 の入力データ長は57〜81バイト (MD5の性質上120バイトに切り上げ)。 RC4 の方は一致/不一致を判定するまででいいので、 数バイト程度。手元のマシン (Pentium 4 3.4GHz) で測定してみると、

[yutaka@bluewind] (4) ~>/usr/local/src/test-target/ssl/openssl-0.9.8/apps/openssl speed rc4
Doing rc4 for 3s on 16 size blocks: 46574804 rc4's in 3.00s
^C
[yutaka@bluewind] (5) ~>/usr/local/src/test-target/ssl/openssl-0.9.8/apps/openssl speed md5
Doing md5 for 3s on 16 size blocks: 4069045 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3472681 md5's in 3.00s
^C

というわけで、MD5 が支配的*1。 1秒間に大体 1M (220) 個の鍵が処理できると考えると、 240 の鍵を探索するには 220 秒程度の時間がかかる……12日ですね。 まぁそこらへんのマシンをちょこっと掻き集めてくれば、1日以内で十分破れます。 大学の学生が普通に使えるクラスタでも数時間ですね。発見時間の期待値としてはそれらの半分。

TLS1.0 の場合はまたこんど。MD5 の危殆化を想定して、鍵生成周りが MD5 と SHA-1 を混合した 関数になっているけれど、まぁ処理回数から見て桁が1つ以上増えることは有り得ないと思われ。

で、実際の脅威ですが、form ベースのパスワード認証とか Basic 認証とかをしているようなサイ トだと、ログイン付近の一連の通信をキャプチャしておいてその前後の通信の いずれかの master key を破れば、サクッとパスワードが盗れます *2その場で暗号化を破らなくても、 同じパスワードを使っている期間に解読できれば十分というのに注意。 数時間〜10日ごとにパスワードを変えるなんてのは現実的じゃないので、 この値だけを見ても、40bit 暗号はもう使うべきでない、といえるでしょう。

そして、SSL2.0 の場合、暗号ダウングレード攻撃が可能ということは、 たとえ入力フォームが128ビット暗号で暗号化されていても、肝心のデータを 送受信するときだけ*340ビット暗号に差し換えられる 可能性があることになります。 もりぶさんの日記 で触れられているダイアログには恐ろしいことに「キャンセル」ボタンがないので、

「えーーー、ちょっと待てー
なんで低程度の暗号化なんだよー
さっきまで違ったじゃんかー」

という悲鳴を上げる側から 40bit 暗号化で貴重なデータが送られるという悪夢が有り得ます(笑) *4。 ま、Mozilla Suite だと個々の暗号化の種類を選べるんで、SSL2.0 と 127bit 以下の暗号化は 設定画面で無効にしておきましょう。他のブラウザでもとりあえず SSL2.0 は無効に。

[Security] Mozilla Suite における弱い暗号化を無効化する設定

それでは、どの暗号を有効にすればいいのか、というのが次の話。 とりあえずまぁ「127ビット以下」という基準で悪くはないのだが、 実際には鍵が長くても暗号自体が弱ければ意味がないので、何か基準を………ということで、 CRYPTREC電子政府推奨暗号リストを参考にすることにした。

まず、鍵共有についてはリストにすべて含まれているので問題なし。 *5

次に暗号化だが、こちらは実際の実装との共通項は

  • AES
  • 3-key Triple DES (注4)
  • 128-bit RC4 (注5)

となっていて、なんか「注」が多い。このうち、3DES については、 当面の利用を認めることになっているが、128-bit RC4 については、 利用形態が「SSL3.0/TLS1.0 以上に限定」されることになっていて、 かつ「別の暗号が利用できるのであれば、そちらを使用することが望ましい」 となっている。現実問題として、比較的新しい AES に限定してしまうと 相互運用に問題が出る可能性があるものの、RC4 に対応していながら 3DES に対応していない処理系はまずないと思われるので、 RC4 を積極的に有効にする理由はないと思われる。

最後に MAC だが、上記のリストで限定すると自動的に SHA-1 になるので、 問題なし。

というわけで、僕個人的にお勧めの設定は次の通り。

SSL の設定

まず、SSL 2.0 は無効にする。ついで、その右の「Edit Ciphers」を開く。

SSL3.0/TLS1.0 の暗号設定(1)

「SSL3/TLS」の画面で有効にするのは、168-bit Triple DES の2つのみ。 128-bit RC4 は、特定相手で不具合が出るなら有効にしてもよいだろう。 56bit, 40bit の暗号化は切っておくことを推奨。

SSL3.0/TLS1.0 の暗号設定(2)

「Extra SSL3/TLS」では、AES と 168-bit Triple DES を有効にする。 56-bit 暗号化を有効にするのは推奨できないし、まして 下の No encryption は絶対に有効にしてはならない

なお、SSL2 は全体設定で無効にしてしまったのでもはや関係ないが、 使わざるを得ない事情があるならば、168-bit Triple DES のみを 有効にしておこう。MAC は MD5 になってしまうが、やむを得ない。 RC4 は事情によっては使ってもよいが、 RC2 は推奨されない (128bit の強度はないことが判明している)。 SSL2 には暗号ダウングレード攻撃があるので、 56-bit DES, 40-bit RC2/RC4 は絶対に無効にしておくことを 強く推奨する。こんな感じになるはず。

で、この設定をすると上の記事のリンク先で名指しされていた 某サイトは繋がらなくなってしまうのだが、まぁ仕方ないよね………。 試してみたところ、SSLv3 の EXP-RC4-MD5 (と、SSLv2 では EXP-RC4-MD5, EXP-RC2-CBC-MD5)のみをサポートしているようなのだが……。

*1 実際は入力値がかなり固定されているので、 もっと最適化可能だろう。

*2 SSL は、負荷の重い RSA 計算をサボるため一連のセッションの間はしばらく同一 の master key を使い回すため。

*3 通信のバイト数やタイミングの情報は盗聴者に筒抜けなので、 このタイミングは予測可能。

*4 ま、パスワードだったら変えれば済むんですが、そうはいかないデータもあるよね。

*5 もっとも、RSA をそのまま使う鍵共有については、ここで使われる RSAES-PKCS1-v1_5 は 「SSL3.0/TLS1.0 で使用実績があることから当面の利用を認める。」 となっているので一応注意なのだが、 恐らくこれは「新規アプリケーションには RSA-OAEP を使え」ということなのだろう。 DHE-RSA 及び DHE-DSA については問題ない。

本日のツッコミ(全2件) [メッセージを送る]
yoriyuki (2005-09-24 22:06)

firefoxでもRC4なのですか。大昔の記憶ではライセンスの問題があったような記憶があるのですが...

おおいわ (2005-09-25 00:00)

RC4 については、確かにグレーな要素がありますね。
http://en.wikipedia.org/wiki/Arcfour 辺りに書いてありますが、もともと RSA 社の商業機密だった RC4 と互換の出自不明コードが、1994年にメーリングリストに匿名で投稿され、通称 "arcfour" として公になってしまったという経緯があるようです。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20050923 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)