最新

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


2005-09-02

[Work] 書類φ(..)

Wnn8で「かきかき」って変換するとこうなるのか……。

ここ1週間で申請書2本書いて提出。通るといいなぁ。

知り合いのあちこちの大学の助手(及び助手だった人達)に聞くと 口々に忙しい忙しいと言っていたけど、仕事になってみると 助手さん達ほどではないにしろやっぱり研究関連業務は大変。 学生の間の(ほぼ)研究だけやってれば良かったのは気楽だったんだなぁと 思うと共に、先生・助手ともに大学時代のスタッフのみなさんには改めて頭が下がる思い。

次はシンポジウムの 発表原稿書きとか、そこで配るパンフレットのチーム紹介原稿書きとか、研究チームのホームページ作成とか。 やっぱり忙しいぞ。研究者の能力で一番重要なのって研究時間を確保する能力っぽい。

[Misc] Y-00 論争

今日研究所に行くと、なんか新聞を広げている人たちが。 と思ったら、フジサンケイ系の経済紙(?)に 『 新量子暗号「Y−00」は旧式並み? 安全性否定論文で大論争 』 とかいう記事が。専門紙とはいえ、「産総研 情報セキュリティ研究センター」の名前が (秋葉原サイト全体の紹介以外で) 新聞にでかでかと載ったのはひょっとしたら初めてかな? 紹介されている内容もこの手の一般産業紙としてはかなり正確っぽいなぁ。 *1

C|netにも 転載されている模様。 折角ならリンク張ってくれれば良かったのに……ってまだこんな整備途中のページじゃ 張ってもしょうがないか……。 こういう情報も含めて、ホームページ整備していかないとねぇ。

肝心の内容ですが、まぁ正直言って勉強中です(笑)。 何が問題になっているのか位は理解できますが、 肝心の証明の数式部分は僕程度の知識じゃ全然追えないなぁ……。

[Misc] で、今週の週末の宿題は……

CRYPTREC 2001年レポート。こういうのはとりあえず小説のように先頭から最後まで読み下だして、 貪欲に記憶中枢に放り込んで、あとから使い方考えるというのが僕のポリシー。 「脳みそががらくたで埋まっている男」を自認してますので :-)。

とはいえ、さすがにソフトウェアの研究が本業なのに こんなのに平日を使うわけにも行かないし……、というわけで週末の宿題 :-)。 しかし239ページもあるなぁ……

追記 (9/3)

半分くらい読んだ。いや、この仕事はマジ大変だわ。頭が下がる。 本来暗号の評価だけならいらなさそうな、暗号の概要についても結構 詳しく紹介されているので、結構勉強になる。

いくつか安全性が否定されているものもあるのだが、容赦無さがいいね。 特に暗号はこういうことをちゃんとやらないと、信頼が置けないからね。

*1 勿論「正確」ってのは「両者の主張がかなり正確に紹介されている」って話ね。 ここで僕みたいな門外漢が安易に「はい、うちの側が正しいです」なんて断言できる訳ないんで。

本日のツッコミ(全2件) [メッセージを送る]

すえなが [ダイビルに入りたいってそれだけの理由で、シンポジウム聞きに行こうかなーって思ってます。ロンドンから帰国した翌日なので..]

おおいわ [ぜひぜひ。多分僕の話以外はかなり末永君には目新しい話だと思うんで、面白いと思いますよ。 ]


2005-09-03

[Misc] ペアプログラミング

奥君が自分のブログに有効性についての疑念を書いているのだが、 *1 個人的な経験を語るとすれば、状況によっては*2結構有効。……Extreme programming の諸発想ってあまり好きじゃない ものが多い(否定的なものと食わず嫌いなものと両方)なのだが、これに関しては割と肯定的。

とはいえ、その時の状況が、

  • 開発時間: 問題解析・設計・実装・デバッグ・リリース・食事・雑談・休憩・睡眠 諸々込みで72時間
  • 開発言語: Objective Caml (当然!)
  • 開発規模: ML で 1567行 (多分他言語だと 3000行クラス以上)
  • 開発陣容: 僕と超一流な研究者3名

とかいう状況だったので、特殊っちゃ特殊。……もう判った人もいるかも知れませんが、 某年の ICFP Programming Contest です (ちなみに負けた年 (;_;))。

この時は、3日間ずっと1部屋にマシン4台を持ち込んで、 4人でミーティング→2チームに分かれてペア開発→結合→ミーティング→(以下略) な開発過程を採用しました。 4人で並列化するほどの作業がないというのも要因としてはありますが、 結構成功したと思っています。

ML を開発言語にしたおかげで文法・単純なデータ処理誤りレベルのバグは 1人でも簡単に潰せるんですが、やっぱり後ろから『他人の眼で』見ていることで、 アルゴリズムとか仕様レベルの高度な誤りとかもかなり防げるので、結合がほとんど失敗しなくなるんですね。 実際、Unit テストに相当する段階でその手のバグは全くといっていいほど発生しませんでした。 ケアレスミスにしても、コンパイラにかける前にかなり潰せるので、 開発時間短縮にも貢献しました。 発生バグの絶対数が少ないので、精神衛生的にもとっても快適 ;-) *3

まぁ、実質的には形式的テストの手間を省けている辺りが一番大きいのかなとも思うので、 「十分気をつけて 正しく書けば、テストはごく簡単に済ませてもバグが混入しない」 という確信が持ててないと、意味がないですね。 ペアプロは太字 の部分にしか貢献できないわけなので。 この辺りは ML (+ ML に慣れている我々) の強みかも。

あとは、ミーティングの時間の削減かなぁ。実際72時間の時限コンテストの場合、 アルゴリズムにしても大局的作戦だけ事前に考えておいて、 細かい詳細は書きながら詰めたりもしますが、その時に 2人で作業しているとちゃんといい知恵が出てくるので、 1人で開発している場合と比べて、事前検討で詰めておかなければいけない部分が かなり少なかった気もします。何分4年前なのでその辺りの記憶はあやふやですが。

実際コンテストには負けてしまったのですが、最終的にエンバグしてしまったルーチンは、締切間際の 土壇場でペアプログラミングを解除してから捩じ込んだルーチンでした (;_;/。 しかも、ペアプログラミング続けていれば潰せたバグだったしなぁ……。 お遊びとは言えちょっと悔しい。まぁ、あのバグがなくても勝てなかったんだけど。

で、この事例は奥君の否定的な3類型にはどれにもマッチしないと思いますが、 じゃぁ一般の web アプリ開発に適応できるかといわれると………、やっぱり特殊かなぁ。

*1 ま〜た例によって exblog は trackback を受け付けてくれないよ……。

*2 かつ、状況によってはその場に合わせて全体の開発過程をカスタマイズすれば。

*3 ま、これは「2人で喋っているだけでも楽しい」くらいに人間関係がうまく行っていないと、そうは思えないかもねぇ。 2人がプログラミング技量的にも人間関係的にもほぼ対等じゃないと、単なる傍観者(前が上位の場合)または 単なる指導関係(後ろが上位の場合)になっちゃうような気がする。

本日のツッコミ(全1件) [メッセージを送る]

kazuho [ふむふむ。 設計が困難で、同時に実装を進めるようなケース (なおかつ、技術者の質が揃っている場合) では有効ってこと..]


2005-09-05

[Security] 第四種オレオレ証明書

……なんか新概念が(笑)。 オレオレ証明書はすっかり定着したが、さすがにこれは無理だろうなぁ(笑)。

さて、www.oiwa.jp は基本的には第四種オレオレ証明書(自家使用専用オレオレ証明書)なわけだが、 純技術的理由(サーバ設定上の理由)で Subversion Repository が https で提供されていたわけだ。 さて、これは第何種オレオレ証明書だろう(笑)。状況を分かって http 同等と割りきっている人には第1種、 名刺で真面目にPGP文書を確認した人には第3種、そうじゃない人には第2種に見えるんだろうな。

実験と称して本物のCA発行証明書取得に トライしていたりしたわけだが、最近問題を解決する見込みもないので、えいやっと設定を書き換えて http でも Subversion repository にアクセスできるようにしてみた。 問題はアクセス制限だが、数通り試行錯誤してうまく行った模様。

そういうわけで、Regexp/OCaml のリポジトリパスを書き換えました。 私の名刺を持っている人には引き続き第三種オレオレ証明書(真贋確認手段付きオレオレ証明書)による SVN/https も提供されてますんで、お好みでどうぞ。 *1

[Misc] 忘れ物

ぐわ、大事なものを大江戸線構内で紛失した。降車駅で問い合わせたところ、 無事に赤羽橋駅で保護されたらしい。しかし、朝9:30を過ぎると大門駅に転送されてしまうらしい。

……ってことは明日も某シンポジウムに朝から出ろと言うお告げか?(ぉ

*1 初回のなりすましは覚悟して、2回目以降保護されるだけでも http よりマシ(まぁ事実ではある)だと思う人は 本人責任で第2種での利用も可。


2005-09-07

[Security] ドメイン管理

なんか PukiWiki 公式サイトのあったドメインが悲惨なことになっているようで……。 /.J とかを見ているだけだと経緯の真相がイマイチ見えてこない*1のだが、 結果として grace period での奪還に失敗してドメイン販売業者に渡ってしまったということのよう ……ってなんで grace period で取り返せなかったのか真相がわからん……。

で、この影響について書こうかと思ったのだが、15秒くらい考えただけで3通りか4通りくらいは 悪用の仕方が思いついてしまった……。 最悪の場合は結構やばいことが起こり得るなぁ。 というわけで最も懸念される事態は書かないでおきます(苦笑)。 そんなにやばくない悪用としては、まぁ数回転売した挙げ句に アダルトサイトへの転送リンク設置するとか、まぁそれ系かな。

まぁ今やるべき事は、とにかく作者公式アナウンスで状況の説明と リンク解除のお願いをして回ることくらいか。 インターネット系メディアとかを活用するのもいいかもねぇ。

で、これに限らず結構ドメインのいい加減な管理をしているところって多い気がする。 最近のネタで最も有名なのは某議員の .cx ドメインの話だが、 あれも単なる*2アダルト業者 だったからまだよかったものの、偽政治献金募集とかのページを 設置されていたらかなり面倒くさいことになっていただろう。

今回のと議員さんのは明らかに管理ミスあるいは(恒久性の怪しい TLD を選択した)管理戦略上の誤りなわけだが、 実際には、意図して似たような状況にしているドメインが山ほどあるのが実情だったりする。 CDの時限キャンペーンサイトとかで、一時的に com ドメインを取得して、 イベントが終了したらあとはほったらかして登録解除、という例は結構見掛ける。しかし、 そこへリンクが張られる(あるいはパンフレットなどの物理媒体に印刷され固定される)限り、 偽販売ページに差し換えられたら あっというまにフィッシング被害出まくりの危険性があるわけで、 適切な運用とは言いがたい。そういう時限ドメインを使いたいならば、 せめて一度運用したドメインは未来永劫*3キープし続ける必要があるだろう。 もちろん、この辺 (6/23)にも書いたけど、ちゃんとラベルとして 意味がある恒久的なドメインを利用することが フィッシング対策としても重要なのは言うまでもない。

聞いた話だと、某大手企業では、接続されているネットワーク上のトポロジに関わらず、 その企業の活動として運営するすべての web サイト(一時的なキャンペーンサイトを含む)は、 すべて自社のメインのドメインの下で運用することを強制するルールになっているらしい。 現在の企業にとってのリスクがマシンへの攻撃よりも偽物の出現のほうが高くなっていると 考えるならば、極めて正しい戦略といえる。

[Misc] 日本語ドメイン

で、日本語ドメインのおかげでまた偽物対策がややこしくなって、 東京大学とかは使う予定のないドメインを、少なくとも正式名称に限っては 余計に金を払って押えている、という話も書いた。

僕は個人的には日本語ドメインなど興味はないので気にしていなかったのだが、 ふと自分の苗字で whois を引いてみると、あるじゃないですか……。

Domain Information: [ドメイン情報]
[ドメイン名]                    大岩.JP
[Domain Name]                   XN--PSSO5F.JP

[登録者名]                      大岩
[Registrant]                    oiwa

[Name Server]                   redirect1.jpdirect.jp
[Name Server]                   redirect2.jpdirect.jp
[Name Server]                   redirect3.jpdirect.jp

げ、転送かよ……。と思って登録者を見ると……、

Contact Information: [公開連絡窓口]
[名前]                          ぴあ株式会社
[Name]                          PIA corporation

んんん??……。一瞬本物か偽物か判断に迷いましたが、どうやら有名なチケット販売の「ぴあ」で間違いないようです。 というわけで、アクセスしてみると……そういうサービスまでぴあはやってるのか(笑)。 至れり尽くせりというか何と言うか。

……金沢かぁ。なんかすごい近く(香林坊の裏の飲食街)まで行ったことがあるなぁ。

今度行ってみるかな(笑)。

[Comp] 仮想マシン整備

ここ2日の間に MSDN と VMware が一気に届いて、机の上が箱とCDだらけになった(笑)。 MSDN は DVD を選んだのだが、それでもこの量かよ……という枚数のディスクが届く。

とりあえず MSDN の方は今日はバインダにいれて眺めるだけにしておいて、 VMware を自分の Linux マシンに入れて、環境をちまちまと整備開始。 VMware 5.0 の GTK UI だが、sarge にはなんの問題もなくサクッと入ったようだ。 とりあえず今日整備する環境は事務作業用なので、ゲストには MSDN じゃない Windows XP をちゃんと入れる :-)。 しかし、VMware 入れると一気にマシンが重く感じるねぇ。メモリ増やそうかな……。

某社の VPN Client は VMware の NAT ではちゃんと動かない……。ひょっとして TCP/IP を使うモードにしていても最初のネゴは直接 IPSec パケット飛んでいたりする? しょうがないので ブリッジ+HostOnly の dual home 構成で代用中。この問題は解決しないとなぁ。

で、中のOSだが、Office とか Acrobat とか窓使いの憂鬱とか Putty とか Unison とか、 入れなきゃいけないものが山ほどあるぞ………。面倒くさいー。 とりあえずシンポジウム終わるまでは保留か。

*1 特に、主開発者とドメイン保有者の関係の辺り。

*2 勿論、当該議員の主張政策との関係上、十分嫌な事態だったわけだが……。

*3 それが駄目ならせめてほとぼりが十分覚めきって、そこへ参照するリンクが0になるまで。


2005-09-09

[Comp] Apache バージョンアップ

2.0.54-5ベース の自家バックポートに更新。patchutils を使うとパッチ間の差分が取れることが この間判ったので、

2.0.54 + (2.0.54-5.diff + (2.0.52-2.backports.org.1.diff - 2.0.52-3.diff))

とかやって、自家版 backport をでっち上げる。

……いい加減 sarge に乗り換えないと、メンテがどんどん大変になるなぁ。


2005-09-10

[Security] SSL 2.0 と輸出強度暗号

Mozilla が SSL 2.0 廃止になるという話あち こち 話題になっている。 例のSSL記事を書いたときに、finished メッセージ内の「謎のハッシュ値」の意義や 可能なアタックについてはある程度調べていたわけだが、 ここ1月くらい、職場の一部で「SSL 2.0 ってそもそも何が危なかったんだっけー」 「もう20世紀のプロトコルの話なんて危なかったってことしか覚えてないよ(ぉ&やや誇張」 「例の finished の話がまさにソレなのかー」と話題にしていたところに タイムリーすぎる。まぁ、いまさら SSL 2.0 をサポートする理由なんてないよねぇ、と敢えて断言したい。 ついでに言えば輸出強度暗号も(少なくとも128ビット暗号が使える世界では)ね。

で、SSL 2.0 の問題はいくつかあって、調べた限りではやばい(と僕が勝手に判断した)順に、

  1. 暗号パラメータのネゴシエーションが改竄に対して保護されないので、 複数の強度の暗号をサポートする場合、中間者が暗号強度を意図的に40bit (輸出強度) に弱める攻撃が可能
  2. パケットの構造に問題があるので、 通信中の各 SSL Record の末尾から任意のバイト数を削る攻撃が中間者によって可能
  3. クライアント証明書を使う場合に、暗号化鍵が一定時間内に破られると クライアント証明書を中間者による別のログインに流用される危険がある
  4. 暗号鍵と改竄検出鍵が同一強度のため、暗号鍵がその場でリアルタイムに破られると、 MAC の部分も辻褄が合わせられて、盗聴だけでなく中間者による通信内容の改竄まで可能になる *1
  5. 通信途中に外部からTCPを切断されても、正常切断と区別が付かない
  6. 改竄防止アルゴリズム (MAC) の使い方に問題がある(が、暗号化後なのでそんなに問題なし?)

という話のようだ。いずれも TLS 1.0 までに補正済。 実質的に我々が普段影響を受けるのは 1 (と 4) かなぁ。 実はプロトコルと実装をここ数時間眺めていて、4. の攻撃が可能な状況では もうちょっと別の攻撃もできそうな気がしてきているのだが、まぁ現状だと 40ビット暗号の解読が数秒ってことはまだ無いのかなぁ。新しい情報募集中。

とりあえず、SSL 2.0 と128ビット以下の暗号は無効にしておきましょう。 この設定で僕が困ったのって1箇所くらいしかない。

ところで、Mozilla には受け入れる暗号強度を設定できるダイアログが あるのだが、IE はともかく Firefox にすら見つからないのはどういうことだ? 僕が見落としてる?

[Security] TLS1.0 / SSL3.0 の SSL2.0 下位互換機構

で、↑なんてものがあるわけです。勉強中に、最初 TLS 1.0 の仕様と 実際のパケットの内容を見ていてどうも食い違うのに首をかしげていたわけですが、 それはこれだったのですね。SSL 2.0 と SSL 3.0 以降では全然パケットの構造が違うので、 SSL2 も 3 以降も両方受け入れるつもりのクライアントは、 SSL3/TLS1 の最初の ClientHello パケットを、SSL2 のパケットに無理やりエンコードして 投げることになってるわけで、まぁ道理で TLS の仕様書だけ見てても理解できないわけだ。 高木さんの日記にある パケットがまさにそれで、最初のパケットが "80 8c 01 03 01" で始まっているのが、 SSL2 形式の TLS1.0 ネゴシエーションに当たる (4〜5バイト目の 0x0301 が、TLS1.0 のバージョン番号)。 返答パケットの "84 80 04 00 01 00 02" が、SSL 2.0 の ServerHello (6〜7 バイト目の 0x0002 が SSL2.0 のバージョン番号)。

で、じゃぁ他の例を見てみると、まず OpenSSL から TLS 対応のサーバに接続すると、

write to 080AFFD0 [080B0018] (142 bytes => 142 (0x8E))
0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00
...
read from 080AFFD0 [080B5578] (7 bytes => 7 (0x7))
0000 - 16 03 01 00 4a 02
...

となる。最初のパケットはさっきと同じ形式でエンコードされていて、一方で次のパケットは それとは全く違う TLS 1.0 形式になっているのがわかる (03 01 がバージョン番号) *2

じゃぁ SSL2 を無効にすると変わるのかなぁと -no_ssl2 オプションをつけてみると、

write to 080AFFD0 [080B0018] (142 bytes => 142 (0x8E))
0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00
...

………あれ? SSL2 フォーマットだなぁ。-no_ssl2 -no_ssl3 でも同じだった。 一方で -tls1 オプションとか -ssl3 オプションとかをつけると、

0000 - 16 03 00 00 5f 01 00 00-5b 03 00 43 22 fe 90 12

あるいは

0000 - 16 03 01 00 5f 01 00 00-5b 03 01 43 22 fe 21 7b

と SSL3 ネイティブ形式になる。これは no 系のオプションは パケットフォーマットに影響しない実装になってるのかな? いまいち謎だ。

次に調べたのは Mozilla (Linux 版)。こちらは、

  • 初回は設定に関わらず SSL2 エンコード形式で接続する。
  • 2回目以降(再利用可能セッションがある場合?)は その再利用するセッションのプロトコルバージョンのネイティブ形式で接続する。

という実装になっているようだ。ちょっと意地悪をしてみたのだが、

  • 最初に SSLv3 のみの設定で接続、SSLv3/TLSv1 の設定に切り替えてリロード
    → SSLv3 のセッションを再利用
  • 最初に SSLv3 のみの設定で接続、TLSv1 のみ設定に切り替えてリロード
    → 新規 TLSv1 セッションを確立
  • 最初に全部ありの設定で TLSv1 接続、サーバを SSLv2 のみの設定に切り替えてリロード
    → TLSv1 セッションを再利用しようとし、パケットを理解できない v2 サーバに接続拒絶され、 直後に SSLv2 エンコードで接続リトライする

というわけで、問題はあまりなさそうだった。

MSIE は調べるの面倒なので簡単に調べたところ、SSLv3/TLSv1 のみに設定されている場合、 TLSv1 ネイティブ形式 (SSLv3とは互換性がある) でパケットを投げてきたようだ。 やっぱりこの手の実装って個性が出るなぁ。

*1 いわゆる「輸出強度暗号」は解読可能性だけが求められていて、 改竄可能性までは求められていなかったのに……ってことだと思う。

*2 ……「と言われたって解らねーよ」という方、ご尤です。とりあえず、 ネゴシエーションの最初の2パケットに限っては、

  • SSL2: 最初のバイトの MSB は1になる。最初の2パケットでは4〜5バイト目にバージョン番号が入る。
  • SSL3以降: 最初のバイトはパケット種別で、ネゴ中は16。次の2バイトがバージョン番号。
が成立しますので、そこで判別可能。


2005-09-22

[Work] [Misc] 発足記念シンポジウム + TXショーケース

立て続けに2つのイベントがありました。詳細は RCISの終了イベント情報など。

……というわけで、2週間も日記が空いてしまいました。いそがしかったー。

溜ったネタを徐々に放出するかな。


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 [firefoxでもRC4なのですか。大昔の記憶ではライセンスの問題があったような記憶があるのですが... ]

おおいわ [RC4 については、確かにグレーな要素がありますね。 http://en.wikipedia.org/wiki/Ar..]


2005-09-24

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

昨日の続き。

なんと、Firefox には SSL2 無効化はあっても弱い暗号の無効化設定がないっ! というわけで、困ったちゃんなのですが、どうやら Mozilla Suite と同じ設定項目は 裏に隠れているようなので、こんな感じでよいようです。

user_pref("security.enable_ssl2", false);
user_pref("security.ssl2.des_64", false);
user_pref("security.ssl2.rc2_128", false);
user_pref("security.ssl2.rc2_40", false);
user_pref("security.ssl2.rc4_128", false);
user_pref("security.ssl2.rc4_40", false);
user_pref("security.ssl3.dhe_dss_des_sha", false);
user_pref("security.ssl3.dhe_rsa_des_sha", false);
user_pref("security.ssl3.rsa_1024_des_cbc_sha", false);
user_pref("security.ssl3.rsa_1024_rc4_56_sha", false);
user_pref("security.ssl3.rsa_des_sha", false);
user_pref("security.ssl3.rsa_fips_des_sha", false);
user_pref("security.ssl3.rsa_rc2_40_md5", false);
user_pref("security.ssl3.rsa_rc4_128_md5", false);
user_pref("security.ssl3.rsa_rc4_128_sha", false);
user_pref("security.ssl3.rsa_rc4_40_md5", false);

これを、プロファイルディレクトリにある prefs.js に書き込むか、 about:config を開いて、該当項目の値を適当にダブルクリックして false にしていけばよいようです。 くれぐれも近くにある "null" の含まれる項目とか true にしないように。

ssl2.rc4_128 と ssl3.rsa_rc4_128_sha に関しては、どうしても必要なら true のままでも よいかも……というのは、昨日のエントリ参照。

ちなみに、Internet Explorer は………、該当レジストリエントリまでは見つけたんですが、 本当にここを強気にいじっちゃっていいのか判断がつかない……。

本日のツッコミ(全2件) [メッセージを送る]

通りすがり [prefs.jsではなくuser.jsに書き込むのが正しいと思うのですが。 ]

おおいわ [> prefs.jsではなくuser.jsに書き込むのが正しいと思うのですが。 ええと、半年前に書いた記事なんでイマ..]


2005-09-25

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

一昨日昨日の続き。但し、今回は爆弾を抱えているので、 よ〜く読んでくださいね。

読む? ...

2005-09-29

[Misc] 夏(?)休み

7〜9月中に取得すべき夏休みを全然取っていなかったので、 月末ぎりぎりの昨日・今日2日間を休むことにした。

……でも職場に忘れ物をしたことに気が付いて結局職場に出かける羽目に(ぉぃ。

丁度いいのでこれまで何度も通りつつちゃんと見ていなかった アキバヨドバシの中をゆっくりと探索する。 水平方向が広すぎて結構廻るのが大変だな。

[Security] JVN 2件

立て続けに出ました。

特に前者については、多分 JVN や Mozilla の Advisory だけだと意味が判らない*1と思うのだが、 とりあえず現段階ではBugzilla に転載された バグレポート (#12, #26) を参照してもらうのが、 近道かな。夏休み中で気合い抜けモードなので解説書くのめんどくさいんすよ……(ぉぃ

Ruby の方は、IPAの解説が 「これって攻撃方法ばらしてないか?」ってくらい細かく書いてあるので、そちらを参照。

しかし、Ruby の件は CVEが 割り当てられている のに、Mozilla の方はないのか……。それとも、CERT/CC 側でハンドリングしたから 判っていないだけで、実はもう既にあったりするのかな?

*1 っていうか、正直 Mozilla 側の解説はちょっと的外れだと思う。やっぱりちゃんと問題点理解されてなかったのかなぁ。(;_;/


2005-09-30

[Comp] Mozilla Suite

Mozilla Suite 1.7.12 にしたら旧版の ContextMenu Extensions がうまく動かなくなってしまった。 trunk が Firefox 前提になった時点でいつかは使えなくなるとは思っていたが、 痛いなぁ。誰かサクッと直し方みつけてくれないだろうか。

いい加減 Firefox にすべきなのかも知れないが、よく使う機能がことごとく省略されてるので 致命的に使いづらいんだよなぁ……。

あと、自宅環境が woody だってのも致命的。

追記 (10/1)

新版と旧版見比べつつ printf デバッグして原因 (content/ctxextensions/extCommonUtils.js:findParentNodeWithAttr) を見つけた。そこだけ backport して解決 (^^;


大岩 寛 (おおいわ ゆたか) <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)