<前の日記(2005-07-07) 次の日記(2005-07-10)> 最新

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


2005-07-09

[Security] セキュリティ技術に関する的を外した議論を見分けよ

いきなり挑戦的だなぁ(笑)パクリくさいし(笑)(*)

たとえば昨日「orz」した UNIX USER の例の記事の Part 2 コラムも そうだし、高木さんなんかも たとえばこの辺 で「混乱させる」とか「不適切な対応の例」とかでいくつか指摘しているが、 セキュリティ対策業界では割と的を外した議論とか対策法の提案とかが 多い気がします。 これらを産み出している構造的欠陥ってなんだろうなぁ、と日頃思っているわけですが、 つまるところ、議論を組み立てるときにきちんと

  1. 前提となる(既に保全されている)セキュリティのレベルを設定し、
  2. 議論の想定する攻撃の範囲を設定し、
  3. そのなかであり得るあらゆる攻撃を想定して考える

というステップを踏んでいないのではないかなぁ、と思うわけです。 2. と 3. はほぼ同値ですが、よくある誤りに「攻撃の過大評価」と「攻撃の過小評価」 があるんで、敢えて分けてみました。

例えば、

  1. スパイウェアが入っていたら、ルート証明書ストアは信用できないから、 自分で証明書を確認して、確実な認証状態を確認すべきである
  2. CSRF 対策でセッション鍵をフォームに埋め込んで確認しても、Cookie は盗聴されるから安全ではない
  3. SSL ではオレオレ証明書を何も確認せずに使っていても盗聴はされていない

なんかは、それぞれの段階の欠如の例として作ってみた例ですが、 それぞれダメな理由はわかりますよね? 念のため確認しておくと、

  1. そもそもスパイウェアが動作している状態では、 ブラウザに介入して証明書の表示自体を偽造可能だから、 証明書を表示して認証状態だけ確認しても意味がない。 更に言えば、キー入力とかを盗めるので暗号化通信自体も意味がない。
  2. 素の HTTP の通信上での認証を議論するときは、 通信路上の盗聴・差し換え攻撃などは想定していない。 (差し換えができるなら、そもそも認証後のリクエスト本体だけ 差し換えてしまえば認証など意味がない) また、CSRF の防護をするときに、(認証前の段階で攻撃可能な)XSS などが ないことも前提となる。*1
  3. 通信路上の攻撃があることを想定するならば、受動的な盗聴攻撃だけでなく、 能動的な攻撃を想定すべきである。通信パケットを窃取して Man-in-the-middle 攻撃をしかければ、実質的に盗聴と全く同じ効果を 得ることが可能である。

ですが、ここの読者には書くまでもなかったかな?

良心的な間違っている記事も結構多いんで、このタイトルの挑戦的さはあとで不便になる (そして改題する) かも しれませんいきなり改題しました(笑)が、これからしばらく、この視点でいろいろな問題点を指摘していきたいと思います。 最近だと高木さんも書いている通り、CSRF とか XSS などの対策でも間違った記述が多いので、 (記事を書く余裕があれば)結構多岐にわたって議論できるのではないかと思っています。

[Security] ……でもって、例のコラムの問題。

で、例の問題のコラムの話なんですが、ツッコム前に上の前提を再確認しておきましょう。 SSL の安全性の議論をするときは、

  1. セキュリティ上の前提として、
    • 最終的な相手方の Web サーバは健全である。
    • 相手方やCAの秘密鍵は漏洩していない。
    • 手元の OS、ブラウザ など、データを暗号化して送出するまでの部分は健全である。
    • ↑の一貫として、ルート証明書のリストには信頼できるCAのみが保持されている。
    の4点は担保されている。
  2. 攻撃としては、DNS、ルーティング を含むあらゆる通信路上の攻撃を 想定する。すなわち、双方が送ったパケットはすべて攻撃者に取得され、 必要なら改竄され、相手方に届いたり届かなかったりする。 送ってもいないパケットすら届くかも知れない。 また、DNS で返ってくる値も、何も信用できない。
    あえて想定していない攻撃を挙げるとすれば、 消費電力の微妙な増減を誰かが監視してるとか、それ系。

という前提を一般に置きます。

その前提でコラムを読むと、まずは「誰が署名したかまでは確認できてない」 と書いてあって、まぁ「そりゃ確認してないよなぁ」と思うわけです。 そこでまず、証明書を見るわけですが、ここで最初の誤りがあるわけです。 電子署名の検証の段階で、署名者をブラウザが「確認済み、OK」とした段階で、 ブラウザが保持している正しい署名者のリストと照合していますから、 基本的にそれ以上の検証は不要です。 署名者のフィンガープリントが一致しなければ、それは署名者の公開鍵と 署名が一致しないことを意味しますから、「怪しいことになる」などと 人が思うまでもなく、ブラウザは「署名が一致しない」警告を出します。 *2 これ、ブラウザの SSL/PKI 実装のもっとも基本的な部分です。

そして、「フィンガープリントの値が一致しただけでは」の段落は、 はっきり言って意味不明ですね。「偽証」の意味がそもそもわかりませんが、 「フィンガープリントが一致する/しない」ことが、 現状のハッシュ関数解読の進捗状況でどういうことを意味するのか *3、 筆者は理解していないんでしょう。Web ブラウザに偽の証明書を 食わせることのできる(ローカルにソフトウェアをインストールさせられる)環境なら、 もっといろいろな攻撃が可能ですから、 フィンガープリントのチェックなんて意味無いし、攻撃者は わざわざ偽の証明書でユーザに攻撃を気付く余地を与えるなんて阿呆なことはしないでしょう。 一方で、いくつか手動でオレオレ認証機関鍵を入れた場合、 前の記事では「諦めろ」と切り捨てましたが、この問題に限定すれば 証明書みて発行者が「自分の導入したオレオレ認証機関」でないことを 確認すれば十分足ります。*4

一方で、偽の証明書を正式CAから取得できてしまうかどうか、という件は、インターネットの PKIモデルの議論になりますんで、別項でもっと議論したいと思いますが、 その手の社会的攻撃を意図しているのなら、その先に書いてある フィンガープリントの検証なんて無意味ですから、いずれにしろ意味無いんです。

そして、そこから先がさらに阿呆で、わざわざ Entrust の HTTP のサイトに行って、 Fingerprint の値なんて調べてるわけですが、SSL を使う話の議論をしている以上、 通信路は全く信用できないという前提なんで、これも愚かです。 こんな方法で確認できるんなら、「そもそも SSL など不要」なんですから。 IP アドレスを確認したところで、通信路上で相手に伝わってる保証なんてないんで、 意味無いです。多分この人には最近の DNS 系の攻撃が頭に染み付いてて、 Web の内容を差し換えるには IP アドレスを偽証しなきゃいけない、とでも思ったんでしょうね。

で、本人は意図していないと思いますが、結論を慎重に読解すると、結局 「何をやっても無駄です」になっちゃうわけで。コラム全体の意味がないですよ。 以上。まぁひょっとしたら「オレオレの議論を Part 1 でやります」、と編集側に言われて 混乱したのかも知れないけど、総じて技術を理解せずに書いている印象がしました。 こんなんだったらコラムの部分の紙数くらい僕に書かせて欲しかったなぁ……。 今回自分の部分の文章長すぎて校正段階で結構削ったのです。

そして、Part 3 への批判でも書いたけど、そこまでルート証明書を信じられないっていうなら、 完全なルート証明書の署名のリストを、確実なルートを使って調べて、 雑誌記事という形で掲載すればいいんですよ。本当にまじめにそういうことを やれば、ある意味すごく貴重ですよ。但し、これは Internet Explorer の ルート証明書を信用しないということですから、「情報が MS のホログラム入り CD より 信頼できること」が条件です。まぁこの記事 (Part 2〜3) 全体に曖昧な記述が蔓延ってますから、 どうやっても期待できないでしょうが。

*1 一方で、URL は様々な場面、例えば Referer などで漏れると思った方が良い。

*2 Part 1 の図13を作る段階で (ローカルで) いろいろと怪しい証明書を作って 食わせる作業をしましたから、実際にそんな感じの警告も見ました。

*3 もっとも MD5 の衝突は徐々に現実っぽい応用が出つつあるようですし、 SHA-1 もまもなくという感じですが、少なくとも SHA-1 に関してはまだ今日の時点では 実用的なデータに於いてハッシュ値が一致しても同一性を信じられない、という段階には来ていないです。 というか、来たら大パニック必至なので暗号屋はそうなる前に対策を練るべく努力しているわけですが。

*4 但し、Part 1 図13 で示した通り、 中間証明者を偽装できるので、署名の全 Path を検査する必要がある。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20050709 (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)