「日本のインターネットが終了する日」という大層なタイトルを冠した記事が公開されたが， どうやら docomo の「iモードID」やイー・モバイルの「EMnet」を起点にした話のようだ。

iモードID に関しては 「『iモードID』の提供開始について」 によると，

• iモードをご利用のお客様の携帯電話番号毎に一つ付与されるiモード用のユニークなIDとなります。
• iモード対応サイトにおいて、アクセス先URL内に予めiモードID用のパラメータを記述しておくことにより、お客様がサイトアクセスした際にiモードIDの通知が行われます。

とあり， これが契約者ごとの固定 ID であり， i-mode 内の公式サイト以外のいわゆる「勝手サイト」でも iモードID が利用できることを示している。 2番目の説明は分かりにくいかもしれないが， URL に特定の書式のパラメータを付加することにより i-mode センタ内で iモードID に変換され， 任意のサイトに送信されるということらしい。 例えば i-mode サイトを乗っ取ったり Phishing メールを送ったり， あるいは広告のリンクに iモードID 用のパラメータを埋め込むことで iモードID 収集サイトに誘導して集め放題というわけだ。 行動ターゲティング広告については既に取り組みが始まっている。

• ドコモ　利用者の居場所・嗜好反映　今秋「生活支援型」で情報配信 （明確に iモードID を使ってるとは書いてないけど，まぁ間違いないだろう）
• ウノウ子会社のサノウ、「iモードID」などを利用したモバイル向け広告サービスを運用開始

このことによる問題は2つある。

ひとつは， iモードID が契約者（＝携帯電話番号）ごとに割り振られる値であるため， この ID をキーに個人情報を「名寄せ」される可能性である（「名寄せ」は Google を使ってもある程度できるらしい）。 もうひとつは， iモードID をキーにして契約者の行動を比較的簡単にトレースできることである。 PC 等で Cookie を使った行動のトレースは個別に Cookie を無効にすることによってある程度防ぐことが出来るが （最近のスパイウェア防止ソフトはこれらの Cookie を削除してくれる）， iモードID をサイトごとに無効にする機能はない。 （iモードID の通知については， 「iメニューサイトはユーザID用のパラメータと両方記述することにより両方の通知が行われます」 とあるので， au の Subscriber ID のように公式のメニューまで使えなくなるといったバカなことは起こらないと思う。 私は docomo のユーザではないので確かめようがないけど）

契約者固有 ID への対策としては， もっとも確実なのは契約者固有 ID を無効にすることである。 au の Subscriber ID や EMnet のように， それが難しい場合は， 「日本のインターネットが終了する日」の勧告を守るべきであろう。 以下に引用しておく。

• ケータイWebにおいては、絶対に住所氏名を入力しない。
  • 商品配送先として住所氏名の入力が必要となるネットショップは利用しない。（着メロ等のダウンロード購入のように、住所氏名を送信する必要のないショッピングしかしないようにする。）
  • どうしても物を買いたいときは、携帯電話会社が運営するショップを使う。（携帯電話会社は、ユーザIDを流用することはないので。）
• ケータイWebにおいては、完全に匿名で使うことを覚悟するか、又は、常に非匿名であることを前提に行動する。
  • 匿名を選択する場合は、自分が誰であるかわかるようなことを、どのサイトでも明らかにしないようにする。
  • 非匿名を選択する場合は、自分が誰であるかはどのサイトでも知られ得ると覚悟して、それでもかまわない行動しかとらないようにする。

私は au ユーザで Subscriber ID の問題についても知っていたため， ケータイから Web へのアクセスは最小限に抑えている。 ただし私のケータイには「PC サイトビューアー」というモードがあり（中身は組み込み版 Opera）， これを使えば Subscriber ID は送られないようである。 MIAU ではケータイ利用を中心に教育用の小冊子を作ってるみたいだけど， この辺の話はチェックしておくべきだと思う。

で， 問題は， 今になってこの仕組みが実装されたことに関する疑念と， そこから派生して， この仕組みがケータイ以外の日本のネット全体に組み込まれる可能性があるのか， 組み込まれるとしてどのような脅威がどの程度のリスクで顕れるかということだろうか。 セキュリティ専門家達がこの辺をどう評価するのかちょっと見ものである。

参考：

• 日本のインターネットを終了しますか？
• 固有IDのシンプル・シナリオ

• パスワード相互認証プロトコルの技術評価用ソフトウェアを公開
• 誕生！フィッシング防止ブラウザ （Yahoo!オークション - 安全対策研究所）
• 2008年6月27日「フィッシング詐欺防止技術の公開テスト開始」　サイエンスポータル編集ニュース

恥ずかしながらこの話， 全くノーチェックでした。 昨年の時点で相互認証プロトコルを IETF へ Internet Draft として提出しているようです。 アンテナ感度落ちたなぁ... orz

個人的には IE や Firefox じゃなくて Lunascape というのが気になります。 既に Firefox 用の「MutualTestFox」とかも用意されているのに（Firefox 3 には対応してなさそうだけど）。 ブラウザの作者が日本人で連携しやすいからとか？ それとも実証実験なので一般的なブラウザは使いたくないとか？

で， ここでも書かれているのですが， なんぼなんでも「アドレスバーの入力欄なら URL を確認せずにいきなり入力しても大丈夫」ってのは言い過ぎだろう， と思うのですが， ほんじゃあどういう仕組みなんだ？ と思って少し調べてみました。 幸い（英語の資料を読まなくても）「暗号と情報セキュリティシンポジウム（SCIS） 2008」の講演論文が PDF で公開されていて， これがなかなか分かりやすかったので， 以降はこの論文をベースに考えていきます。

そもそも， Phishing というのはソーシャル・エンジニアリングの一種であり， それっぽい Web ページを演出することによってパスワードやクレジットカード番号などの秘密情報を盗み出そうとするものです。 論文では Phishing の手口を5つ挙げています。 すなわち

1. 認証を要求せずに，直接クレジットカード番号や個人情報等を入力させ，これを騙し取る。
2. 認証を要求し，入力されたユーザID とパスワードを騙し取る。
3. 認証を要求するが，入力したパスワードによらず認証が成功したと見せかけ，続く画面でクレジットカード番号や個人情報等を入力させ，これを騙し取る。
4. 認証を要求し，入力されたパスワードを正規サイトに中継し，パスワードが正しいときだけ， 1 および 2 と同様にパスワードやクレジットカード番号等を騙し取る。
5. 認証を含むすべての通信内容を正規サイトに中継し，通信内容の窃取，セッション識別情報を窃用したセッションハイジャック，リクエスト内容の改竄等を行う。

です。 最後の2つは中間者攻撃（man-in-the-middle attack）と呼ばれるもので， 一番最後の手口では， ワンタイムパスワードなどを用いた， いわゆる「2要素認証」も突破できます。

Phishing は今や完全に組織犯罪化している点は注目すべきです。 サイエンスポータルの記事によると， Phishing の被害についても

「国家公安委員会などが毎年公表する「不正アクセス行為の発生状況」によると、2007年に検挙された不正アクセス事件1,438件のうち1,157件がフィッシングでパスワードを詐取した手口によるもので、インターネットオークションのサービスが標的とされたケースが大半を占めている。」

そうです。 中間者攻撃は Script Kiddy が安易に手を出せるようなものではなく， それなりのリソースを用意する必要がありますが， Phishing が組織犯罪化している現在， それだけのことをするインセンティブが存在するというわけです。

産総研が発表した「フィッシング対策のための HTTP 相互認証プロトコル」（面倒なので，以降 MutualAuth と略称します）では， 上述の5つの手口のうち2～5を防ぐことができます。 残念ながら最初の手口は防ぐことができません。 これは認証を伴わないアクセスだからです。 したがって， やはり「アドレスバーの入力欄なら URL を確認せずにいきなり入力しても大丈夫」ってのは言い過ぎな気がします。 まぁ， 認証も行わずに秘密情報を入力させるようなサービスは使わないほうがいいと思いますが。

MutualAuth は PAKE （Password Authenticated Key Exchange; ISO/IEC 11770-4）の一種である KAM3 （Key Agreement Mechanism 3）をベースにしています。 MutualAuth の特徴は以下のとおりです。

• クライアント（ブラウザ）とサーバが事前に同じパスワードを共有し，この情報を相互に確認しあうことで認証を行う。
• 認証の過程においてパスワードを直接送信することがなく，パスワード情報が盗聴者および中継者によって盗まれることが無い。また，窃取した情報を元にオフライン攻撃による全探索を行った場合でも，正規のパスワードに関する情報を入手することが不可能。
• 通信の暗号化機能はなく，既存の TLS を用いる。
• クライアント側は，ホスト名・（ホストから送られて来る） realm 値・ユーザ名・パスワードを組み合わせ Hash した値を weak secret として用いる。ホスト名を結びつけることで中間者攻撃を防ぐことができる。

また， ユーザ名およびパスワードの入力インタフェースについても， アドレスバーの横に配置することで入力欄を詐称しにくくしています。 認証が成功すると結果が同じくアドレスバーの横に表示されます。 ユーザはその部分を見ることで認証済みのサイトかどうか確認できるわけです。

ざっと見た感じでは仕組み自体はとてもよくできていると思います。 Phishing の何が問題かというと， サーバからユーザを認証する仕組みはあるのにユーザからサーバを認証する統一的な仕組みがないことです。 SSL/TLS があるじゃないか， と言う人もいると思いますが， 件の論文にも書かれているように， 証明書が（CA で証明された）正しいものであることは Phishing サイトでないことを保証しませんし （EV SSL も審査基準をどこに置くかでどうにでもなる。 個人的には EV SSL も， なるべく多くのサイトで使えるようにするために， 審査基準を甘くせざるを得なくなるようになり， 文字通り「屋上屋を架す」結果になりそうな気がするのだが）， クライアント認証を使うにしても鍵の管理が煩雑になって（鍵は使用するマシンごとに個別に管理する必要がある）あまり使い勝手が良くありません。

MutualAuth の問題は普及率がどうなるかだと思います。 上述のように MutualAuth ではユーザ操作も変わってきます。 認証方式が新旧混在の状態だとユーザの意識もなかなか変わらず， うっかり Phishing ページを踏んでしまう事故も減らないのではないでしょうか。 あと， Web サービス側がつくりを変更しなければならないのも問題でしょう。 決済系のサービスから地道に啓蒙していくのがいいかもしれません。 そのためには日本のサイトじゃなくて国外のサイト（Yahoo! Japan じゃなくて Yahoo! とか PayPal とか）にアピールすべきと思います。 わたしも Yahoo! Japan の認証が必要なサービスは全く使ってないので， 実証実験に参加することはないでしょう。

まっ， 今後の動向には期待しています。 まずはドラフト案を通して RFC として認可されるところからでしょうか。

いわゆる「認証」については， 前に読書禄でも紹介している。 いわゆる「認証」を考えるとき， 私たちは以下の3つの要素の組み合わせで考える。

• 識別（identification）： あなたは誰？
• 認証（authentication）： 証明しろ
• 許可（authorization）： この範囲のことはしてもよい

例えば， 運転免許証番号は識別トークン， 運転免許証の顔写真は認証トークン， 運転免許証自体は許可トークン， といった具合である。 識別・認証・許可は必ずしもセットになっている必要はない。 『セキュリティはなぜやぶられたのか』 でも例示されているが， 乗り物の乗車券やコンサートのチケットは許可トークンだ。 この許可トークンに対しては， 識別や認証は必ずしも必要ない。 それを持っている人なら誰でも目的のサービスを受けられる。

ここで， 応用として taspo について考えてみる。 taspo については本格的な運用が始まってから色々マヌケな事例が起きていて， Tumblr では散々悪口を書いているのだが， ちゃんと調べてみたら誤解している部分も結構あったので， ここで一回整理しておく。

taspo についてはあまり技術的な記事が見つからない。 ここでは以下の記事を参考に考えてみる。

• 「たばこ自販機成人識別施策」への取り組みについて （NTTドコモ）
• taspo - Wikipedia
• ピデル - Wikipedia

taspo のシステムは， IC カード， カード読み取り端末， 通信インフラ， バックエンドのデータセンタ（DC）， といった要素で構成されている。 IC カードおよびカード読み取り端末は日本で普及している FeliCa ではなく MIFARE らしい （MIFARE のどの種類かは不明）。 通信インフラは FOMA だそうだ。 つまりタバコ自販機から FOMA を経由して DC とリンクしているらしい。 taspo 設置には十数万かかるそうだが， それ以外にもランニングコストとして固定費をさっぴかれている可能性はある（けどその辺の情報は見当たらない）。

taspo には電子マネー「Pidel」が組み込まれている。 Pidel はプリペイド式の電子マネーで， チャージはタバコ自販機でのみ可能。 Pidel の電子マネー情報はカード側ではなく DC 側で管理されている。 従って taspo カードを紛失しても新しいカードを作れば残高等が引き継がれる。 当然購入履歴も全て DC に保存される。 しかしタバコしか買えない電子マネーにどんな市場的意義があるのか甚だ疑問。 （nanaco でタバコも買えるってのならともかく）

ここからは想像だけど， taspo カード自体には識別トークンのみが入っているんじゃないだろうか。 taspo カードを読み取り端末にかざすと， 識別トークンを DC に照会して与信情報や Pidel の残高情報を引き出す。 その後， 与信 OK なら購入手続き・決済に入るわけだ。

taspo は成人認証システムと言われているけど， 自販機での購入プロセスが上記のとおりであれば， 識別・認証・許可のうち肝心の認証をすっ飛ばしていることになる。 taspo カードの識別の後いきなり許可を与えている。 自販機ではカードの持ち主が正しいかどうか証明できないのだ。 taspo カードには顔写真と会員番号等の情報が印刷されているため， 対面販売であれば顔写真と会員番号等を基に認証を行うことは可能であるが， もし対面販売なら IC カードである必然性は薄い。 （taspo カードを読み込ませて与信情報を引き出すことはできるけど， 対面販売でそこまでするかっちう気もする。 普通は顔写真のみで確認を済ませるだろう）

taspo の申し込み書類を見る限り， 商品購入時に認証情報として使えるのは顔写真しかない。 つまり taspo はシステム設計段階から認証を考慮していない可能性がある。 それで「成人認証」を名乗っているのだから笑ってしまう。

私は taspo ってもっとオモチャみたいなものかと思ってたけど， 要素技術は意外とまとも。 でも， 肝心の認証がダメダメで， その一点で taspo は破綻しているといっていいだろう。 ちなみに私は， 未成年の喫煙を抑制したいのであれば， こんなへんてこりんなシステムなどなくても， もっと簡単にタバコ自販機自体を撤去してしまえばいいと思う。 タバコは対面販売のみとして， どうしても成人認証が必要なら顔写真入りのペラペラのラミネートのカードで十分である。 まぁ taspo の運用コストが見合わなくて， 結果的に自販機が続々撤去されていくというのなら， それはそれで構わないけど（笑）

私はタバコは吸わないので， タバコ依存者から巻き上げたお金でどんな無駄なシステムを構築しようが知ったこっちゃないけど， こんな似非「成人認証」システムをタバコ以外に応用しようとか恐ろしいことは絶対に考えないでいただきたい， と切に願うのだった。

AddClips のボタンを新しいのにしたら， 各 SBM サービスのブックマーク数が表示されるようになっていた。 で， はてなブックマークの kmachu さんのコメントが気になったので， 追記しておく。

「「taspo カード自体には識別トークンのみが入っている…肝心の認証をすっ飛ばして」←ちょっと違和感。カードは認証しているけどカード所有者は認証していないと言うべきかも。カードが偽造できる訳じゃないから。」

私が認証を識別・認証・許可の3つに分けたのは， この手の混乱を避けようと思ったから。 日本語の「認証」は様々なニュアンスで使われるので， あまり使い勝手のいい言葉ではない。

最初に運転免許証を例に出したのは taspo カードと運転免許証は構造が似ているからだが， kmachu さんが指摘されるとおり， 識別であれ認証であれ許可であれ， トークンを用いる際には， トークンに対する認証が必要である。 もっともここで言う認証は authentication というよりは certification （もしくは validation）とでも言うべきものだろう。

上述したように taspo システムの詳細はよく分からないが， 識別トークンである会員番号には当然 check digit が埋め込まれているだろうし（でなければアホ過ぎる）， おそらく DC に問い合わせることで（与信処理）， そのトークンの有効性を確認することもできる。 顔写真等の認証トークンについては申請時の書類によって証明できるはず （であるが， 申し込み方法を見る限りいくらでもなりすまし可能なように思えるのだが...）。 許可トークンである taspo カードには MIFARE が使われている。 taspo カードが MIFARE のどれを使ってるかは不明だが， ものによっては Common Criteria の EAL+5 の認証を受けているものもある。

（Common Criteria については IPA の記事を参照のこと。 ちなみに FeliCa も CC EAL+4 の認証を受けている。 まっ， MIFARE にせよ FeliCa にせよ， 上に乗ってるアプリケーションは別物だけど。 著作権の世界で CC といえば Creative Commons だが， エンジニアの世界で CC といえば Common Criteria のことである。 なんちゃって）

• JPCERT/CC RSS
• 情報処理推進機構：情報セキュリティ 緊急対策情報
• Japan Vulnerability Notes
• X-Force セキュリティアラート＆アドバイザリ
• del.icio.us/spiegel/Security+Vulnerability （6/3 追加： 上述4つのフィードでは漏れが多いため， 私のブックマーク情報を追加してみるテスト） （6/11: del.icio.us 側の日本語処理が上手くないようなので停止中）
• National Vulnerability Database （6/5 追加）
• US-CERT Vulnerability Notes （6/11 追加）
• CIAC （Computer Incident Advisory Capability） （6/11 追加）
• SANS Internet Storm Center （6/11 追加）
• XSSed Advisories （6/14 追加）

集約するフィードは， セキュリティ・インシデントの情報を中心に， 順次追加する予定ですが， 特定のプラットフォームに偏らないように配慮するつもりです。 （有用なフィードがあれば教えてください）

いやぁ， 自分のものは何ひとつ使わずこういうことができてしまうんだから， 楽な世の中になったよなぁ... そうそう， twitter/security_inci のアバターアイコンを募集中です。

• RFC 4880: OpenPGP Message Format

これに伴い RFC の 1991, 2440 は Obsolete になります。 まっ GnuPG とかは RFC 2440bis の頃から新しい仕様を積極的に取り入れてきたから， これによって大きく変わるということはないだろうけど。 あっ， でも， --openpgp オプションの意味は変わるかな。

RFC 2440 から比べるといろいろ変わっているわけだが， 最近の大きな変更といえば SHA-1 の取り扱いと DSA のアルゴリズム変更だろう。 この辺は RFC 4880 の 13.6 章に詳しく書かれているので興味がある人は読んでみるとよい。 ちなみに FIPS186-3 はまだドラフト状態のままだ。 最後のドラフト案が出てから1年半以上経ってる。 パブコメ募集も終わってるし何やってるんだろ， NIST。

参考記事：

• 暗号の危殆化と新しいアルゴリズム
• OpenPGP で利用可能なアルゴリズム一覧

• 複数の脆弱性を使用する攻撃ツール MPack に関する注意喚起

MPack についてはすでに様々な記事が出ているので， いくつか挙げておきましょう。

• 1万を超えるWebサイトを支配する“史上空前”のサイバー攻撃が発生「世界中に蔓延する危険も」――セキュリティ・ベンダー各社が警告
• Webからの大規模ウイルス感染がイタリアで発生

MPack は複数の脆弱性を組み合わせて攻撃する感染力の強い攻撃ツール（エクスプロイト・パッケージ）で， まず Web サーバを乗っ取り， そのサイトを見に来たユーザのマシンに（既知の脆弱性があれば）入り込んだ上で更に MPack をばら撒きます。

ただし， 今のところ MPack は既知の脆弱性のみを突いてくるのでユーザ側で対策をしておけば問題ありません。 殆どは Windows の脆弱性ですが WinZip の脆弱性や Quick Time の脆弱性も突いてくるようなので， 「Windows Update で最新にしてるから」とか「私は Windows じゃないから」といった油断は禁物です。 また新しい脆弱性を突くモジュールもばら撒かれる可能性があるので， 使用しているソフトウェアの脆弱性が見つかった場合はこまめにアップデートしてください。

以下に JPCERT/CC で紹介しているユーザ側の対策を引用しておきます。

現在確認されている MPack は修正済みの脆弱性を使用しています。 以下の対策を行うことで、被害にあう可能性を減らすことが可能です。

- OS とアプリケーションを最新の状態に保つ
- ウイルス対策ソフトを使用する

• 初のフルカーネルマルウェア？　スパム送信もカーネルモードで実行

• A Complete Guide to the Common Vulnerability Scoring System Version 2.0
• 共通脆弱性評価システムCVSS v2概説

あぁ， それから， 今回も JavaScript で作ったデモページを作っているので興味のある方は是非どうぞ。 「ドキュメント読むよりは実際にコードを書いたほうが理解しやすいしね」 という程度の品質だけど。

v1 との違いは

1. 各評価項目値の調整
2. 環境評価基準（Environmental Metrics）に機密性／完全性／可用性の要求度（Confidentiality/Integrity/Availability Requirement）を追加
3. ベクタ（Base, Temporal, Environmental Vectors）の追加

といったところか。 今回の目玉は環境評価基準に追加された3つの項目だろう。 機密性，完全性，可用性については基本評価基準（Base Metrics）に影響度（Impact）として組み込まれているが（現在もある）， 実際にはこれらの項目は環境評価基準（つまりユーザが行う評価）にも関係してくる。 例えば， 基本評価基準では機密性への影響（すなわち情報漏えいの可能性）は低めに見積もられていたとしても， ユーザが運用するシステムにおいて機密性への要求が非常に高い場合は実際の影響度はもう少し高めに見積もったほうがいい （逆のパターンもあるだろう）。 要するに基本評価基準の影響度に対してバイアスをかけるのである。 （今回の項目追加によって基本評価基準にあった Impact Bias 項目は削除された）

ベクタというのは評価項目とその値について簡単な文字列で表記する方法を指す。 書式は以下に示すようにコロンとスラッシュの2つのデリミタを使う。

評価項目1:評価値1/評価項目2:評価値2/ ... /評価項目n:評価値n

具体的には以下のような感じになる。 （“A Complete Guide to the Common Vulnerability Scoring System Version 2.0” より引用）

適当なパーサさえあれば各ベクタを読み込ませて評価を行うことができる。 上述したように環境評価基準では各影響度にバイアスをかけて再評価するロジックがあるため， 各評価基準の値（Metrics Score）が分かっているだけではダメで， 各項目の値（Metric Value）も把握しておく必要がある。 なのでこのベクタ表記は結構重要である。 （IPA/ISEC の資料には言及がないけどw）

• APOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について
• JVN#19445002 APOP におけるパスワード漏えいの脆弱性

IPA/ISEC および JVN の解説は簡潔すぎて要領を得ないので，以下のページを参考にするとよい。

• Message Freedom in MD4 and MD5 Collisions: Application to APOP
• APOP
• APOP Broken?

注意しなければならないのは， これはあくまでメール（POP）サーバへアクセスする際の認証プロトコルの問題であり， メール本文が盗み見されたり改竄されたりといった問題とは無関係ということだ。 っていうか， よく言われるように電子メールは郵便で言えば葉書と同じようなものであり， 第三者が本文を覗き見したり改竄することは以前から可能である （たとえ MUA-MTA 間の通信を暗号化しても MTA-MTA 間は平文のまま流通する）。 それをリスクと感じるなら PGP/MIME や S/MIME 等でメール本文を署名・暗号化する必要がある。

さて， 今回の手法は「Man-in-the-middle 攻撃」と呼ばれるものの一種。 ユーザと POP サーバの間に割り込んで（ユーザから見て）サーバになりすます。 そうして APOP のやり取りを記録しパスワードの一部を割り出すわけだ。 パスワードの一部といっても最大31文字まで割り出せるそうなので， ほとんどの人は完全なパスワードをぶっこ抜かれてしまうのではないだろうか。

何故 APOP が狙われているかというと，おそらく3つポイントがある。

• APOP がセキュアな MAC （Message Authentication Code）ではない。
• APOP で使われる MD5 （ハッシュ関数の一種）はいくつかの攻略法が発見されていて既に危殆化している。 （ハッシュ関数の危殆化の問題については拙文を参照のこと）
• アルゴリズムの危殆化が考慮されておらず MD5 以外の選択肢がない。

多くの人は POP 認証を自動化しているはずで， 全く気付かないうちにパスワード情報をぶっこ抜かれている可能性もある。 この攻撃によってパスワードを知られてしまうことによりメールサーバへの不正アクセスを許してしまうのはもちろんだが （POP 認証と SMTP 認証では同じパスワードになっていることが多いが， そうすると取得したパスワードを使って spam をばら撒くこともできそうだ）， そのパスワードを他のサービスでも使っている場合， まとめて侵入を許してしまうことにもなりかねない。 これは「Twitterとソーシャルハッキング」で書かれているような話と構図としては同じで， いわゆる「クラスブレイク」が発生している状況である。

ここまでが APOP の脆弱性によって予想される脅威（ハザード）。 しかし私たちが知りたいのは脅威ではなくリスクだ。 JVN のレポートによると， CVSS の基本値は 4.0 でそれほど高くない。 現状値や環境値は状況によって違うと思うので各自で確かめて欲しいが （一応 JavaScript によるデモがある）， そんなに酷い値にはならないと思う。 これは Man-in-the-middle 攻撃自体の実現性がそれほど高くないからだと思う （Base Metrics の Access Complexity も high だもんな）。 とはいえ放置できるほど軽微でもないので， ユーザやメールサーバの管理者（ISP を含む）は何らかの手を打つ必要がある。

APOP 自体は標準のプロトコルであり， これを変更することはコストがかかりすぎる。 MUA 側でできる手っ取り早い（ただし消極的な）対応としては， 送られてくるチャレンジコードをチェックしバイナリ値を含む場合には認証を中断するというものだ。 いっそ POP を捨てて IMAP にすれば CRAM-MD5 等の認証プロトコルが使える （CRAM-MD5 では HMAC を使う）。 可能であればこういった方法に切り替える手もあるだろう。

IPA/ISEC のレポートでは POP over SSL や Web メールを利用する方法が紹介されている。 SSL/TLS で通信を暗号化した上で認証を行うというわけだ。 しかし， 個人的な印象では（Web メールはともかく） SSL/TLS をメールサーバにアクセスするためだけに使うには高価すぎる気がする。 現在の SSL/TLS は X.509 ベースの PKI を構築している。 X.509 は多対多または1対多での証明には向いているが（例えば Web）， 1対1の証明に使うにはコスト（特にランニングコスト）がかかりすぎる。 「APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に」では

「それにしても、上のオレオレ事業者たちは、なぜ普通にサーバ証明書を買わないのだろうか？」

と書かれているが， そんなのは簡単な話で， メールサーバだけのために証明書を調達する（ランニング）コストに比べて， （それによってもたらされる）リスク・ベネフィットのバランスの改善が小さくて見合わないと思っているからだ。 “Beyond Fear” 風に言うなら「トレードオフ」による判断であり， 『環境リスク学』風に言うなら「意思決定のためのリスク」評価だ。 この辺の状況は電子メールだけじゃなくて Jabber なんかでも同じ。 （4/30 訂正あり。文末の追記を参照）

（念のために書いておくが， 私はオレオレ証明書を容認しているわけではない。 SSL/TLS が X.509 ベースの PKI で運用されている限り， 規模の大小に関わらず， オレオレ証明書を使うことは SSL/TLS の信用モデルを根底から覆す。 まぁ “GnuTLS OpenPGP key support” が標準になれば状況も変わるかもしれないが）

しかし， まぁ， これが5年前くらいの話だったらもう少し真剣に考えるところだろうけど， 電子メールなんて今ほとんど使わないからなぁ。 プライベートなやり取りなら IM や mixi 等の SNS についてるメッセージ機能のほうが手軽で使いやすいし。 どうしてもメールのやり取りが必要なら Gmail 使えばいいし。

（4/30 追記）

Twitter で指摘されたのですが， サーバ証明書でワイルドカードが使えることを完全に失念していました。 つまりさくらインターネットが提供しているような共用レンタルサーバでもそれほどコストをかけずにサーバ証明書を導入することは可能であるということですね。 指摘してくださった方に感謝＆申し訳ないです。

暗号技術入門-秘密の国のアリス

結城 浩

ソフトバンククリエイティブ 2003-09-30

評価

by G-Tools , 2007/04/21

「日本なんたら協会」の処分の妥当性についてはここでは論じない。 っていうか私は「プライバシー・マーク」の意義すら疑っているので， そんなものがあろうとなかろうとどうでもいい。

今の社会は「信頼」を取引できる。 ここで言ってるのは金融商品としての「信用」じゃないよ。 「社会的な信頼」ってやつだ。 「ISO なんたら」とか「プライバシー・マーク」とかいうのは商品だ。 企業はそれを取得するために膨大なコストを支払う。 でも， 本当は「社会的な信頼」が取引できる筈はないのだ。 信頼というのは関係性を示す言葉だ。 まずある関係があってその関係の上に信頼が構築されているかどうかなのである。

確かに今回， 大日本印刷はどえらいことをやらかしちゃったけど， そのペナルティは関係する企業間で行うものだ。 多分相当なペナルティを支払う羽目になっているだろう。 もしそうしない取引企業がいたら， その企業はエンド・ユーザである私たち消費者をナメてるということであり， そのような態度をとる企業に対し消費者は断固とした要求をすべきだ（金をくれって言ってるんじゃないよ）。 しかるにそういう情報は全然聞こえてこない。 私のアンテナの性能が悪くて聞こえないだけなのか， それともどこの馬の骨とも分からん「日本なんたら協会」の処分で「手打ち」にしてしまうつもりなのか。 例えば私は au のユーザだけど， 情報漏洩の事実についてのニュースリリースは比較的早く出されていて， （実際はどうか知らないが）「同社員以外の第三者への流出や当該情報の悪用はない」ということで， まぁ一安心だったんだけど， その後大日本印刷に対してどうするつもりなのか全くアナウンスがない。 取引を（一時的にでも）制限するのか， あるいは何らかの改善要求を出すのか。 au が大日本印刷に対する態度を表明することは， au と顧客の間の信頼関係を修復する大事なステップであるとは思わないのだろうか。

「ISO なんたら」とか「プライバシー・マーク」が商品としてもてはやされる背景には， 企業間の取引においてリスクを外部化しようとする心理のようなものが働いてるんじゃないのか。 取引先からは商品だけ調達できればよく， その過程で何らかのセキュリティ・インシデントが発生してもそれは取引先の問題であって自分とこの問題じゃないという鈍感さ。 「ISO なんたら」や「プライバシー・マーク」が要求しているから対策するという本末転倒な発想。 本当はお互いがリスクを（外部化ではなく）共有するための手段として「ISO なんたら」や「プライバシー・マーク」といった標準があるはずなのに。 （まぁ「プライバシー・マーク」が標準といえるかどうかは相当怪しいが）

• ナイトライダー的な未来

今や自動車は数十個の ECU （Electronic Control Unit）で制御され， ECU 同士はネットワークで繋がっている。 これが車載 LAN だ。 車載 LAN として割と標準的なのが CAN （Controller Area Network）であるが， 他にも色々ある。 とりあえず CAN でググったら色々出てくるだろう。 日本語の資料としてまとまっているのは三菱自動車のテクニカルレビューかな。

• 新車内通信システムの開発 （PDF）
• 新世代ダイアグノシス機能の開発 （PDF）

これではなんのこっちゃわからんという人はルネサスのサイトが参考になるかも。 このシステムブロック図を見るだけでも最近の自動車がいかに「チップだらけ」なのか分かると思う。 もともと車載 LAN はハーネス省線化の要求から来ている。 個々の ECU において Programmable なリソースは限られているため， 車載 LAN のプロトコル・スタックはチップレベルで埋め込まれているのが普通だ。 またネットワーク自体が車内で閉じているため， ノイズ以上の外部からの干渉はあまり考慮に入れられていない。

さて， これだけ見て件の Autoblog の記事を見ると「おおっ，なるほど」って思うでしょ。 まぁ Inilex のような例は極端だが， 例えばカーナビの中には車載 LAN 上の情報を拾って車内のステータスを表示する機能を持ったものもある。 インテリジェントな機能を持ったカーナビが Bluetooth や無線 LAN と結びついたらどうなるんだろうねぇ， などとドキドキワクワクな日々である。

• 電子キャビネットの非接触ICはFeliCaが主流に
• FeliCaチップで“共連れ”を防ぐ

ずいぶん昔に聞いた話なので今は違うかもしれないけど， クリーンルームにはいくつかのレベルがあるらしい。 私は一番低いレベルのクリーンルームにしか入ったことがないけど， これは防塵服を着て（変な帽子も被ってマスクもする）2重扉の間でエアシャワーを浴びてやっと入れるというもの。 トイレに行くのにも（手順をやり直さなければならないので）エラい大変だった覚えがある。 機材の搬入とかのチェックも厳しかった。 一番厳密なクリーンルームは人の出入りを絶対的に禁止する。 作業は別の部屋（もっと低レベルのクリーンルーム）で遠隔操作によって行う（もしくは遠隔操作もなくて完全な自動運転）らしい。

今の情報セキュリティもこのクリーンルームの発想に近い。 より厳密な情報管理が求められるほど， そしてその要求にアーキテクチャが応えれば応えるほど「人」の存在がネックになる。 完全にセキュアな環境とはすなわち「人」が存在しない環境なのである。

まず「外部」との接点によって環境の汚染度を定量的に評価し， 汚染度によってドメインを分ける。

インターネットに接続できるドメインは最も汚染度が高い。 このドメインを他のドメインから物理的に切り離さなければならないだろう。 もちろんこのドメインに機密情報を永続的に置くことは許されない。 おそらくこのドメインに置かれる端末は定期的に（OS レベルで）再インストールする必要がある （もしくは完全にディスクレスで動作しシャットダウンによって機密情報もメモリから消えるようにするとか）。 「外部」との間で行う情報の持ち出し／持ち込みはこのドメイン以外では禁止する。 もちろん私物パソコン（ケータイ・PDA を含む）を持ち込んだり家に帰って仕事をするなどもってのほかである。

次に汚染度が高いのは「人」が機密情報にアクセスできるドメイン。 普段の仕事はこのドメインで行う。 このドメインでは機密情報に「ファイル」の形でアクセスできる。 ただしアクセスの前に必ずチェックアウト手続きを行う。 この手続きによって誰がいつどの情報にアクセスしたか管理者側が把握できるようにする。 もちろん使い終わった情報はチェックイン手続きによって結果（複製や配布情報も含めて）を報告する。 情報の検疫もチェックイン手続きで行う。 先ほどのインターネットに接続できるドメインとは物理的に切り離されていることが重要。 これによってネットではなく「人」の出入りを監視することで機密性を高めることができる。 当然ウソをつく「人」にはペナルティを与え， このドメインへのアクセス権を剥奪する。 また情報の機密性に応じてこのドメインを更に細分化することもできるだろう。

もっとも汚染度が低いのは「人」が情報に直接アクセスできないドメイン。 「人」は検索用の端末から必要最小限のサマリを「閲覧」できるだけ。 作業はソフトウェアによって自動化される。

とまぁ妄想を繰り広げてみたけど， 情報セキュリティに本気で取り組んでるとか豪語する大手の企業や組織は当然この程度（もしくはそれ以上）のことはやっているに違いない （って真に受けないでね。 リスクは常に全体で最小になるように再配分されなければならない。 「人」を除外（＝外部化）したために全体のリスクが引き上げられるのなら， その方法は失敗なのである）

まずは関連するページを列挙する。

• Complete CVSS Guide
• 共通脆弱性評価システムCVSS概説
• CVSS Calculator
• ソフトウェア等におけるセキュリティ上の弱点の深刻度評価の試行について

CVSS （Common Vulnerability Scoring System； 共通脆弱性評価システム）は情報システム脆弱性を定量的に評価するための方法・手順を示したもので， オープンでかつ特定のセキュリティ・ベンダに依らない汎用的な仕様になっているのが特徴。 CVSS には大きく3つの Metrics がある。

• Base Metrics （基本評価基準）： 脆弱性そのものの特性
• Temporal Metrics （現状評価基準）： 現在の深刻度
• Environmental Metrics （環境評価基準）： 利用者の最終的な深刻度

これらの Metrics を基に Score を算出する。 Base Metrics からは Base Score （基本値）が算出される。 Base Score に Temporal Metrics を加味したものが Temporal Score （現状値）。 Temporal Score に Environmental Metrics を加味したものが Environmental Score （環境値）。

Metrics が何故このように分かれているかというと， それぞれの Metrics を評価する人（あるいは組織）が異なるためだ。 すなわち Base Metrics の評価は脆弱性の報告者が行い， Temporal Metrics の評価は対象となる製品のベンダが行い， Environmental Metrics は製品の利用者自身が行うわけだ。 従って「脆弱性の報告者」側に立つ IPA は Base Score を公表することになる。 Base Score を受けてベンダは Temporal Score （あるいは Temporal Score の推移）を公表し， 利用者は Temporal Score を基に最終的な判断を行うことができるのである。

このように CVSS による評価は上から何やらありがたいご神託が降りてくるわけではなく， 利用者自身もその評価に加わる必要がある。 そこで JVNRSS では簡単に評価ができる CVSS Calculator を公開している。 何やらかっこいい画面が表示されるが， 計算式自体はそんなに難しくないので JavaScript でも組めそうな感じだ。

文字数のわりに盛り沢山な内容。 以下に抜き書きしてみる。

• 「「Winnyは著作権侵害よりもむしろ、名誉毀損やプライバシー侵害にあたるような映像の拡散が止められないといった観点からの懸念がある」」
  • 「たとえ多くの人が流通するのは問題であると考えているファイルでも、それを止めることが出来ない点が問題」
• 「キャッシュの中身を知ることは送信可能化権の侵害を自覚することにつながるため、ユーザーの側でもキャッシュの中身を知ろうとはしない」
• 「現在では他の技術も存在することから「既に必要な技術ではない」と主張」
• squirtの仕組みでは、著作権者などからファイルの削除要求が来た場合には、それに応じなければ著作権侵害の意図があると見なされてしまうためで、「結局、著作権侵害を続けたいと考えている人が多いということではないか」
• 「「日本では送信可能化権の整備や刑事処罰などを進めたことで、逆にWinnyのようなソフトが必要とされる結果となってしまい、同時に流出したプライバシー情報の流通も止められなくなってしまった」」
• 「「作者が幇助罪で処罰されるのはおかしい」という意見とWinny自体の問題は独立して考えるべきだ」
  • 「「会社から情報を持ち出す行為が悪い」「ウイルスを作成して流す行為が悪い」という主張があるが、それを理由にして「Winnyは悪くない」というのはおかしい」
• 「「ウイルス対策ソフトで防げるはずだ」「リテラシーの向上で防げるはずだ」といった意見に対しては、「未知の脆弱性を悪用するようなゼロデイ攻撃であれば、自分にも防ぎようがない」」
• 「Winnyのプロトコルは既に解析されており、ウイルス自身がWinnyプロトコルでファイルを放流するという可能性」
• 「ウイルス頒布の処罰化が現在検討されているのと同様に、Winnyネットワーク等の稼動（Winnyの使用）の違法化についても検討すべき」
  • 「「Winnyネットワーク等」の定義をどうするのかの線引きは難しい」

Winny （面倒なのでその他の Winny コンセプト・ツールも含める）によって構築されるネットワークが大きな社会的リスクを抱えていることは間違いない。 そこに異論がある人はあまりいないと思う。 Winny には「消費主体」であるユーザが素朴に欲望するものを塞き止める障壁がない。 最初に挙げた記事はまるで Winny ユーザが意図的に著作権を侵害する行為を繰り返しているかのような記述だが、 おそらくそうではないだろう。 今の時代にそんな根性の入ったアナーキストが何万何十万もいるとは思えない。 彼らは（消費に耽溺するために）ただ無視しているのだ。 彼らが従っているのは「4つのコード」のうち Winny というコードのみで、 他の「法」や「規範」や「市場」なんてものは華麗にスルーしている。 そんな怖いことが実現できてしまう（実現されてしまった）のが Winny というソフトウェアだ。 そういうユーザに善悪の別やリテラシーを説くのは意味がないばかりか、 彼らの「正しさ」を補強することにもなりかねない。

そういう意味で（とりあえず Winny 自身ではなく） Winny の利用を違法とみなすというアイデアは面白いとは思う。 Winny を利用することに対し何らかのペナルティを科すことで彼らのインセンティブを変えられるかも知れない（アングラ化するだけかも知れないが）。 まぁ現実問題として合法と違法の間の線引きはかなり難しい（ってか殆ど無理な）んじゃないかという気もするけど、 何か凄いアイデアがあるのかもしれない。

しかし、 それはそれとして、 現状をどうするかだよなぁ。 前にも紹介けど Winny はもはや「開いてしまったパンドラの箱」であって、 今更なかったことにはできない。 「ウイルス自身がWinnyプロトコルでファイルを放流するという可能性」自体も怖いけど、 それが犯罪に使われる可能性もある。 例えば放流するファイルを暗号化し「復号鍵を公開されたくなければ金をくれ」と脅されるパターンなんていかにもありそうだ。 （そしてそういう犯罪が増えれば、それを騙った詐欺も頻発する）

そうそう， 「たとえ多くの人が流通するのは問題であると考えているファイルでも、それを止めることが出来ない」っていうのは多分言い過ぎ。 本当に「多くの人」が問題ありと判断してアップロードしなければそれは拡散されないだろう （このたとえ話だけ読んで反応しないように。 私は Winny に違法コンテンツの流通を抑止するコミュニティがあると言っているわけでも， あるいは啓蒙やキャンペーンでどうにかなると言っているわけでもない）。 「Winnyへの情報漏洩も早期であれば対処可能、ネットエージェント杉浦氏講演」によれば， 漏洩した情報の半分くらいは2週間以内に消えるらしい。 ダウンロードしたファイルをアップロードフォルダに入れずキャッシュも手動でマメに消している， といったユーザの実像が紹介されている。

]]> http://www.baldanders.info/spiegel/log2/000286.shtml コンピュータやネットワークのセキュリティは「ウイルス対策ソフトやファイアウォールを入れておけば安心」という時代ではなくなった。 というか情報の可搬性が増すにつれ， それを扱う人の問題になってきた。 Security Spiegel 2007-02-17T23:08:31+09:00 最近なかなか印象的な記事が出た。

• 【RSA Conference 2007】「専業セキュリティ・ベンダーは無くなる」，RSA社長が語る
• 【レポート】情報セキュリティは抽象論の時代から実効性の時代へ - 岡村弁護士

コンピュータやネットワークのセキュリティは「ウイルス対策ソフトやファイアウォールを入れておけば安心」という時代ではなくなった。 というか情報の可搬性が増すにつれ， それを扱う人の問題になってきた。 日本でそれを象徴的に示したのが Winny （ここでは Share 等の Winny 系ファイル共有ツールも含む）およびそれを媒体とするウイルス（ここではワームやトロイの木馬等も含む）による情報漏洩騒ぎだ。 しかも某政治家や一部のセキュリティ専門家が「Winny を使わなきゃいい」みたいな（実際にそう言ったわけではないが，そう受け取られかねない）発言をするもんだから話が捩れる捩れる。 そして現在にいたってもその被害は収束する気配がない。 なんでこうなってしまったのか。

（これまで何度も書いたことだが）セキュリティはハザードではなくリスクで考えなければならない。 しかし人は「科学的評価リスク」ではなく「リスク不安」で行動する（「科学的評価リスク」や「リスク不安」などについては一年前の記事を参照）。 そして， ここが大切なのだが， コンピュータやネットワークのセキュリティ・リスクには「科学的評価リスク」が存在しない。 そこにあるリスクを定量的に表すことができないのである。 （2/24 追記： 全くないわけではない（忘れていたが）。例えば脆弱性情報に関しては CVSS による定量的な評価が可能。 もっともセキュリティの要件は脆弱性だけじゃないけどね）

一年前の記事で挙げた「リスク不安が増大する理由」のひとつに「非自発的にさらされている」という項目がある。 例えば喫煙リスクは（喫煙者にとっては）自発的な行為（と思い込んでるもの）なので， リスクが低めに見積もられる傾向があるそうだ。 Winny も同じ。 コンピュータ・ソフトウェアというものは殆どの場合は自発的にインストールして利用するものだ（まぁ「パソコン」を共有している場合は他人が勝手にインストールしちゃうこともあるだろうけど）。 つまり， そのユーザはインストールしたソフトをコントロールできていると思い込んでいるわけだ。 しかし今時の特にネットワークに繋がるソフトでソフト自体やその上で交わされる情報が完全にユーザにコントロールできるものなどほぼないと言っていいだろう。 別の言い方をするならユーザは（そのソフトから得られる）利便性と引き換えに自ら進んで情報のコントロールを手放している（つまりセキュリティ・リスクを増大させている）わけだ。

まぁこれが個人の話なら近年流行りの「自己責任」とやらで片付く話かもしれないが （実際にはここで言う「自己責任」なるものは『下流志向』で言う「自己決定フェティシズム」であり， 私から見れば嗜癖者の典型的行動パターン（コントロールの幻想）だ。 「嗜癖は中毒ではない。人は好きで嗜癖する」）， 企業やその他の組織ではそういうわけにはいかない。

これまでセキュリティ専門家やセキュリティ対策企業が提供してきたものは， あるインシデントが発生した際の事後処理（インシデント・レスポンス）の方法である。 それはあくまでも「再発防止」という観点で構築されるものだ。 ウイルス対策ソフトやファイアウォールといったセキュリティ関連ツールも「再発防止」という観点で設計・運用される。 もちろん「再発防止」は大事なことだ。 しかし「再発防止」で防げるのはあくまでもハザードだけだ。 しかもなんでもかんでもハザードで片付けようとするから運用が捩れてくる。

Winny 騒動がもたらした教訓は， リスクを引き上げる主な要因になっているものは（上述したように）人の活動であり， それゆえに「完璧なセキュリティは不可能」だということだ。 そこでようやく最初に挙げた2つの記事にたどり着く。 この2つの記事が示しているものは， 製造業ではトヨタを筆頭に導入されつつある「未然防止」の考え方だ。

「未然防止」といっても， あるんだかないんだか分からないものを防止することはできない。 だから「未然防止」ではまず「あるんだかないんだか分からないもの」の輪郭をはっきりさせ見えるようにする。 セキュリティ対策の費用対効果， 「守れないルール」は何故守られないか， 等々。 そういったことを洗い出していく過程でインシデントの発生メカニズムを明らかにし， それを「未然防止」する業務プロセスを構築していくのである。

「セキュリティはプロセスである」とはよく言われることだが， これまでセキュリティ専門家もセキュリティ対策企業も本当の意味でセキュリティをプロセスとして捉えていなかった。 それは某政治家の「情報漏洩を防ぐ最も確実な対策は、PCでWinnyを使わないことです」なんてな発言に端的にあらわれている。 Winny を使う人はリスクを知らないで使っているのではなくリスクを引き受けることを「自己決定」しているのだから， 「Winny を使うな」という啓蒙活動に効果があるはずもないのだ。

まぁ（専門家はともかく）セキュリティ対策企業が今後どう変わっていくかは分からない。 おそらくツールやインシデント情報の提供だけではなく， もっと業務プロセスに踏み込んだコンサルタント的な内容にシフトしていくんだろうけど， 変な方向にずれていく可能性もありうる。 今年はそういった部分も注目かもしれない。

最後に毎度のことながら， この本を参考文献として挙げておく。

トヨタ式未然防止手法・ＧＤ３

posted with 簡単リンクくん at 2007. 2.17

吉村 達彦著
日科技連出版社 (2002.9)
通常2-3日以内に発送します。

オンライン書店ビーケーワンで詳細を見る

すみません。 頭が悪いので意味が分かりません。 記事を読む限り「屋上屋を架す」ようにしか見えません。 Wikipedia の説明でも同様。 VeriSign の FAQ なんか更にわけ分かりません。

どなたか分かるように説明してください。