«前の日記(2006年03月10日) 最新 次の日記(2006年03月12日)» 編集

ema log


2006年03月11日 [長年日記]

_ [最近] 鳴尾浜 阪神2軍 vs サーパス

サーパスはオリックスバファローズのファームチームです。

鳴尾浜球場は甲子園と同じサイズ*1なのですが、バックスタンドが無く、また内野からグラウンドがすぐそこだったりして、非常に狭く感じます。また、すぐ横にはタイガースの選手の寮である「虎風荘」があります。3塁側の出入り口が繋がっているみたいです。選手には非常に便利そうな環境です。

土曜日ということもあり、お客さんは満席に近い状態でした。 喜田が3打数3安打だったり、ダーウィン桜井前田大が良かったり。ダーウィンはなかなか良さそうですよ。喜田もどんどん1軍の試合に出て欲しい。

そして、前田大和選手は1年目だそうですが、ショートで守備が非常に上手そうでした。「流れるような」という形容詞がぴったりのように思います。楽しみ。

阪神側の先発メンバーは町田が DH の4番で、先発がダーウィンの↓だったかなぁ。

  1. 前田忠
  2. 前田大
  3. 浅井
  4. 町田
  5. 喜田
  6. 桜井
  7. 赤松
  8. 藤原
  9. 秀太
  10. ダーウィン

相互申し合わせにより7回まで打ち切りで、阪神が1対0で勝利という結果でした。

鳴尾浜球場は出入りが自由、つまり無料(満員の場合、入場制限あり)です。また、駅からは離れていますが、甲子園球場とは違って隣の体育館の駐車場が1日500円で利用できます*2。非常にまったりと、静かに観戦できます。阪神ファン・野球ファンの方は楽しめると思います。

*1 両翼96m、センター120m。他にも土とか色々と合わせてあるらしい

*2 体育館でイベント等がある場合、使用できないこともあるらしい

_ [Linux][apache][Programming] Digest 認証への攻撃方法 〜 盗聴

不正確になりますが、ダイジェストの生成法をより大まかに表現すると、この図のようになります。

前回は実装レベルで説明しましたが、今回はより抽象的なレイヤで説明します。重要なのはこちらなので。

それでは、盗聴・漏洩について検討します。

WRITING SECURE CODE にならい*1 DFD でダイジェスト生成を記述し、それに基づいて説明してみます 。

ダイジェスト計算に使われる値の中で、攻撃者が盗聴で得ることのできない値は「パスワード」です。図では赤く塗ってみました。なぜなら、図より攻撃者がパスワードを得た場合、盗聴で認証を通過できます。

次に、パスワードを用いて計算される A1 があります。これも同様に攻撃者に得られてはなりません。さらに、A1 から ダイジェスト が計算されます。これらも赤く塗りました。

以上のことから、図の中で赤く塗っている要素が攻撃者に漏れると(度合いは異なりますが)認証を乗っ取られることになります。すなわち、「パスワード、A1、ダイジェスト」が漏れると危険です。それぞれについてもう少し詳しく見てみます

それぞれが漏れるとどうなるの?

パスワードが漏れると?

攻撃者は常に認証を突破できます。なぜなら、あらゆるパスワードに基づいた認証方式に共通していますが、認証システム側では正規のユーザとの区別をつけようがありません。

また、同じユーザ名・パスワードを他のサービスでも利用していると連鎖的に問題が発生します。

A1 が漏れると?

攻撃者は常に認証を突破できます。なぜなら、A1 がわかると パスワード が無くてもダイジェストの計算が可能です。A1 はサーバに平文で保存されていることに注意してください。秘密鍵と同様に厳重に管理する必要があります。

ハッシュ関数は破壊的な関数で、ハッシュ値が漏れても即座に元の文字列に戻すことはできません。しかし、オフラインでの総当たり攻撃(brute force attack)が可能になり、その安全性は低下します。

ダイジェスト が漏れると?

攻撃者は今回の認証のみを突破できる場合があります。なぜなら、図中でいう「回数」か「乱数」の値が変わらなければダイジェストの値も変わらないからです。このような攻撃方法を繰り返し攻撃(Replay Attacks)と呼びます(あってます?)。「ものまね士の様に、前回の通信をまねる」ので「繰り返し攻撃」といいます。

ダイジェストは、認証のたびに生成されるパスワードと考えることができます。すなわち、攻撃者はある認証のダイジェストを入手できれば、その認証におけるパスワードを得たと言えます。しかし、「回数」か「乱数」を変更すれば、ダイジェストは簡単には予想できない値へと変化し、前回の古いパスワード(ダイジェスト)では認証されず、繰り返し攻撃は成立しなくなります。

対策方法は?

対繰り返し攻撃耐性をあげる

「回数」か「乱数」の値を変えることで、ダイジェストは変わります。つまり、定期的にこれらの値を変化させれば、繰り返し攻撃は困難になります。例えば、乱数は1回しか使えないなどの方法が考えられます。

しかし、何らかのコストが必要です。

SSL / TLS / IPSec などで盗聴そのものを防止する

より良い解決策はこちらでしょう。パスワードを平文で流さないことも重要ですが、通信経路を保護することがより重要になります。可能であれば、通信の保護を検討します。

ただし、いわゆる「オレオレ証明書」の問題などに注意が必要です。通信が保護されていると思っていたのに、実は偽造された証明書を利用してしまうようでは本末転倒です。

本当に盗聴は危険なの?

はい。危険です。次回は実際のサイトの例として mixi を取り上げて、一般的な認証と盗聴の危険性を検討します。

結論は http://mixi.jp/https://mixi.jp/ にしる!例えば、Gmail は https://gmail.com/ であり、すべての通信が SSL で保護されるような設計。何故、あそこまで個人情報を入力させようとするサイトにもかかわらず、SSL がデフォルトで使用できないのかが意味不明。

盗聴することは難しいのか?

いいえ。パケットモニターやパケットスニファで検索してみてください。サブネット上の暗号化されていないすべての通信の中身を取得することが「TCP-IP の原理上」可能です(合ってます?少なくとも同じ HUB に刺さってたら見えるのは知ってるんですが・・・RFC 嫁?)。有線 LAN だと自動的には暗号化されないのが普通です(これ、なんとかならんかねぇ)。

*1 システムの DFD を作り、そこから脅威ツリーを作成する事が説明されているが、ここでは計算方法を(疑似?) DFD で記述し DFD から直接的に脅威の伝搬を視覚化した。