高木浩光＠自宅の日記

■ 忙しすぎる

忙しすぎる。だが日記は書く。

■ RFIDの最長応答可能距離

4月のトレーサビリティー勉強会で「本来ミューチップのコンセプトはアンテナを組み込むことだったので現在試作を行っている」とうかがっていたものが発表された。

ただしアンテナが小さい分、ICタグのデータを読み書きする装置であるリーダー/ライターとの通信距離は短くなる。データを読み取る際にはリーダー/ライターと数ミリの範囲で「密着」させることが必要だ。その一方で、セキュリティ上のメリットもあると井村氏は指摘する。「離れた機器から自動的に読み取られることがなくなるので、心配されるプライバシの保護にも役立つはずだ」（同）。

日経コンピュータ, 日立製作所、0.4mm角のICタグを開発

このように事業を推進する側がプライバシー上のメリットを示すことは重要だ。

それでもなお、「電波を強く」したらなどという不安の声が出てくる。いくらリーダの出力を大きくしたところで、タグの応答の出力は制限されているのだろうから、距離がそんなにのびるとは思えない。それでもリーダの感度を上げれば少しはのびるのかもしれない。それがどのくらいなのか、1ミリなのか、5ミリなのか、1センチなのか、5センチなのかよくわからない。

そこで思ったのだが、RFIDの製品仕様には、運用時の標準通信距離だけでなしに、悪用された際を想定した最長応答可能距離も併記するようにしてはどうだろうか。

昨日もRFIDを推進する立場のある方のお話をうかがっている際に、プライバシーの話の流れの中で、「Suicaだって1センチに近づけないと読めないんです。他のクレジットカードとかと重ねていたらそれだけで読めなくなるんです。」という発言が出てきた。

Suica改札機の事例では、距離が利用者にとって明白になっていないとエラーが発生する使い方をされてしまいがちなため、「タッチアンドゴー」という利用者に明白な方法にしたという話をよく耳にする。運用時の実用通信距離が短いからといって、カードが能力として持つ最長応答可能距離が短いとは限らない。

近接型規格（ISO/IEC 14443）は通信距離が10センチ以下とされているが、こういう話もある。

ICカードとリーダ/ライタとの通信距離は、Suicaが約10センチ、Edyが3ミリと意外に短い。

「実はこの数値は、ユーザーが非接触型ICカードを“能動的”に使うための最適な距離。FeliCa自体は、技術的には1.5メートル離れても届く仕様になっているが、通信範囲があまりにも広いと別のユーザーのカードにも反応してしまう」（ソニー担当者）。

ZDNet JAPAN, 非接触型から顔の“鍵”まで――ICカードフェア2002

たしかにSuicaをPaSoRiやCLIEで使うと、カードを裸にした状態で1センチの距離からしか読めない。しかし、PaSoRiを分解して裸のアンテナで試すと2センチの距離から読める。FeliCaのリーダ/ライタのカタログスペックによると、RC-S480Aは2センチと書かれている。しかし、RC-S440Cの方は10センチとなっている（アンテナサイズは10.4 x 6.7センチ）わけで、カードの能力としては少なくとも10センチはあるということになる。カードの方のカタログスペックを見ると、RC-S440C使用時が10センチで、RC-S440A使用時は5ミリと書かれている。この表示方法だと、10センチより遠くからの読取が不可能なのかどうかがはっきりしない。

「他のクレジットカードとかと重ねていたらそれだけで読めなくなるんです。」と発言した人物にとっての「読める/読めない」は、確実に読めるかどうかを話している点に注意したい。しばしば、事業を推進する側から、「そんな夢のような使い方ができたらこっちが嬉しい。そんなうまくはいかないものだ。」という発言が出てくることがあるが、一般に、セキュリティを語る上でそういう思考をしてはいけない。実用の話と悪用の話は別だ。10パーセントの確率でエラーになるのが実用にならないのだとしても、悪用されるのを避けたい消費者にとって、90パーセントの確率で読み出し可能な事態を許容できるのかという議論だ。

以前にも書いたが、私はあくまでも技術が普及することを願ってこうした議論を続けている。デジタルコアはあくまでも日経なのだからそうであるはずだ。消費者に不安を抱かせることなく事業を展開するには、突っ込まれる余地のある不用意な発言を推進側がしないことが重要である。最悪時のスペックを示すことは他の工業製品でも一般的に行われていることであり、プライバシーの懸念が出ているからには、RFIDでもそれを示すことは消費者を納得させるために必要なことではなかろうか。

ちなみに、念のために補足しておくと、RFIDのプライバシー懸念は、第三者のリーダで遠いところから読まれることだけではない。もうひとつの、第二者が設置したリーダが消費者の期待と異なる目的でIDを使用する懸念（4月のネット時評の安ホテルと高級ホテルのシナリオ）を忘れてはならない。

■ 同定不能プロトコルの資料

8月10日の日記に書いた、

未確認情報であるが、「同定不能プロトコル」として坂村先生の講演で紹介されているようだ。

38枚目のスライドに次のようにある。

■新しいプロトコルが必要

不正なアクセスに対しては、毎回異なる同定不能の回答をする必要

坂村健, ユビキタスIDセンター

同会合の議事要旨にはつぎの記録がある。

・電子タグの普及に何年かかるかという話は、私はどうやっても１０年はかかると思う。それくらいかけなければ、セキュリティポリシーや、セキュリティの問題に関してコンセンサスが得られないし、リーズナブルな価格にもならない。電子タグを様々な用途に用いると、プライバシーや、セキュリティが問題となるので、十分な時間をかけてセキュリティポリシー等をディスカッションする必要がある。

・タグのセキュリティの問題と、リーダーライターのセキュリティの問題が、往々にして混同されてしまう。リーダーライターのセキュリティの問題は、別途ユビキタス端末のセキュリティの問題として考えなければならないが、この場で議論しなければならないのは、タグそのもののセキュリティの問題だろう。

・様々な物にタグが付き、至る所にリーダが設置されると、特定の持ち物の番号から特定の人物が同定できてしまい、問題だと言われている。それらに対応するセキュリティポリシーを丹念に作っておく必要がある。それをわかった上で、さらにコストを掛ける等の対応をしなければならない。言い方を少し間違えただけで、大きな産業になるマーケットになるものをだめにしてしまう。

総務省情報通信政策局技術政策課, ユビキタスネットワーク時代における 電子タグの高度利活用に関する調査研究会 第2回, 議事要旨

すばらしい。安心した。「言い方を少し間違えただけで」……そう、そこだ。

その一方で、いまだにこんなことを言っている有識者の方もおられるようだ。

・電子タグのＩＤセンターの話は住基ネットの番号を付番しているところと似ている。住基の番号自体はなんの意味も持たず、属性情報が付くから意味があるのであり、タグの問題も同じだろう。

住民票コードの民間利用禁止の意味も理解しておられないようだが、どの委員だろうか。

■ 追記

おっと、この議事録は、8月22日の日記で引用した中間報告の研究会の議論だった。

5月末のことだったようなので「いまだに」の部分は取り消すことにする。

■ ネタメモ

日立

パスポートやビザの個人情報が電子化されることに対して外国では反対が起きないのでしょうか。アメリカでは「9.11」があって、ホームランド・セキュリティということになれば、個人情報が行政側に把握されるのはある程度仕方がないと考える人も多いのでしょう。それに、海外では個人番号を付けるのは当たり前ですね。 海外から見ると、日本で行われているセキュリティや個人情報についての議論はある意味異様に思われているのかもしれません。ただ、まだ理解できない個人の安心としては、横浜方式はなかなか良いやり方だといった意見が聞かれます。住基ネットにつなぐかつながないかを本人が選べるわけですから。

スペシャルインタビュー, 住基カードに秘められた可能性

海外では早い時期から個人番号が普及した結果、濫用されるようになって問題が指摘されているという状況なんだがなあ。日本はそこから学んで住民票コードの民間利用を禁止にしたわけだが。

大山教授

搭載されているマイクロチップとアンテナで無線通信を使う識別技術のRFID (Radio Frequency IDentification)も重要ですが、タグ(荷札)ですから機能的には単純です。利用者の意思を反映できるチップがセキュアチップとすれば、RFIDタグは意思を反映できないチップと言えます。ICカードは、持っている人の代わりにその人の意思に従って機能します。ネットワークで、カードが本人の行動を代行するわけです。たとえば、ネットワーク申請時に電子署名をカードでするのは、本人の意思が伝わるからであって、RFIDタグでは本人の意思は伝わりません。

ですから、RFIDタグは物を識別するには適していますが、人の意思を識別するのはタグではないと思っています。意思表示ができない状態での患者さんの取り違いがないように、センサーに対してRFIDタグで本人情報を送るのは良いのですが、正常な意識状態で使うのはどうでしょう。

スペシャルインタビュー, 住基カードをめぐる展望

そう、まずは本人の意思によるものかそうでないかだ。だから、「セキュアチップ」もカード固有の固定IDが意識なしに取り出されることのないようにしないといけない。固定IDを持たないようにすればよい。

■ シングルサインオンにおける共通ID化の回避

日経IT Proの「今週のSecurity Check[一般編]」に、「“進化”するシングル・サインオン」という記事が出ている。SAMLとLiberty Allianceのことについて書かれたものだが、Libertyの本質が説明されていない。

この記事は、シングルサインオンの意義について、

利便性が高まる分，1回の認証をくぐり抜けられると，複数のシステムにアクセスされてしまう恐れはある。しかし，ユーザーとしては，1つのパスワードさえ管理すればよいので，複数持っている場合よりも，きちんと管理できるだろう。（中略）

SSOはセキュリティを確保しつつ，利便性を提供できる仕組みといえる。

とした後、現状の問題点として、

しかし，現状では問題がいくつかある。その一つが製品間の相互運用性の問題である。各ベンダーは独自の方法でSSOを実現させているので，異なるベンダーの製品間では，認証の連携を行えない場合がある。このため，閉じた企業内では問題なくSSOを実現できても，複数の企業間あるいは，Webサービスに代表されるビジネス連携フレームワークの中で，SSOを実現することが難しい。

という点を挙げ、それを解決するものとして、

そこで，2002年の後半以降，業界では，SSOの標準化や認証連携の実現へ向けた動きが始まっている。代表的なキーワードは，「SAML（Security Assertion Markup Language）」と「Liberty Alliance Project」である。

と、Libertyのことを挙げている。

この記事はLibertyの意義を過小評価している。Libertyのプライバシー確保の面をまったく説明していない。

まずは、Liberty AllianceのID-Federation Frameworkがどういうものか、Libertyアーキテクチャ概要に掲載されている「ユーザ体験の例」を見るとよい。

ここではまず、Joe Selfという人物が、「Airline.inc」と「CarRental.inc」という2つのサービスプロバイダそれぞれ用に、独立に作成したアカウント「JoeS」と「Joe123」を持つ状況を前提としている。最初に同氏が、Airline.incにJoeSアカウントでログインし、数時間以内にCarRental.incにJoe123でログインすると、「CarRental.incのアイデンティティをAirline.incのアイデンティティと連携させますか？ はい/いいえ」という選択肢が現れる（2.1節）。ここで「はい」を選択したとすると、後日Airline.incかまたはCarRental.incにログインしたときに、もう一方にアクセスするとログイン手続を省略してアクセスできる（シングルサインオンが実現される）というわけだ（2.2節）。

このとき、Airline.incにはJoe Self氏のAirline.inc用のアカウントである「JoeS」というユーザIDしか伝えられず、CarRental.incにはCarRental.inc用の「Joe123」というユーザIDしか伝えられないという点がミソである。アイデンティティ連携を実施するステップで、CarRental.incにアクセスしたとき「あなたはAirline.incにサインオン中です」と表示されるのは、Webブラウザが直接Airline.incにアクセスして認証済みであるという情報だけをCarRental.incに送信しているためであり、連携しますか？に「はい」と答えた際に、Airline.incのアイデンティティ(ID)プロバイダのサービスに、Airline.incの「JoeS」がCarRental.incの「Joe123」と連携するという設定が記録されるが、このとき「Joe123」というユーザIDをそのまま使うのではなく、ランダムに生成した「ハンドル」を使う（図14）。このハンドルは、p.36によると、「ユーザーハンドルは定期的に更新する必要があります」となっている。

そして図15のように、複数のサービスプロバイダのアカウントをひとつのIDプロバイダーに連携させることができる。このとき、ユーザはサービスプロバイダAとBにシングルサインオンできる状態になるが、この仕組みにより、サービスプロバイダAとBが仮に結託したとしても、それが同じユーザのログインだということを判別できないようになる。

この方式が、日本の携帯電話事業者がやろうとしている「モバイルID」のような共通ID方式よりプライバシーの保護レベルが高いことは明らかだろう。

仮にIDプロバイダが悪意を持ち、各サービスプロバイダと結託するとどうしようもないという話は残るように思えるが、これはどうしようもないか。しかし、図16のように複数のIDプロバイダを利用することもできるため、完全にひとつのIDプロバイダに託すのではなく、複数のIDプロバイダにリスクを分散させることができそうだ。この点がMicrosoftの初期のPassportとは異なるように思えるが、Passportもその後進化しているようなので、最近はどうか知らない。

具体的な使い方としてはこんな感じだろうか。ユーザは、航空会社やレンタカー会社に個別にユーザ登録をする。この際、各会社へのユーザ登録に必要な最小限の情報を登録をする。ある日、航空会社Aを利用したときついでにレンタカー会社XとID連携の設定をしておく。別の日、別の航空会社Bを利用したときに同じレンタカー会社Xと連携設定する。さらに別の日、同じBを利用したときに別のレンタカー会社Yと連携させたとしよう。予約開始にあたり航空会社から使い始めるのであれば、航空会社AかBにログインして作業を始めると、そのままシングルサインオンの状態でレンタカー会社XやYを使える（AでログインしたときはYは使えない）。このとき、万が一航空会社Aがレンタカー会社XとYと結託したとしても、Yにおけるユーザのアカウントは、XやAのアカウントと同一人物だということは判別されずにすむ。

このように、Libertyはシステムアーキテクチャとして、ユーザのプライバシーを可能な限り失わせずに済むことを実現している。なのに、IT Proの記事では、この仕組みが「異なるベンダーの製品同士の連携が可能となるのだ」という視点でしか書かれていない。

Libertyのプライバシー面での意義を解説した記事は少ないようだ。プライバシーを無視するのであれば、こんな複雑な仕組みを使うまでもなく、共通ID方式にすればシングルサインオンは簡単に実現できるだろう。複雑にせざるを得ない理由を「異なるベンダーの製品同士の連携」のためだと理解することも可能だが、それは副次的なもので、プライバシー確保のためが第一の目的だろう。

この意義があまり重視されていないようで嫌な予感がするが、共通ID方式のプライバシー上の問題点がセキュリティ技術者たちに理解されていないことの現われではないかと心配だ。

セキュリティ技術者がプライバシーを語るときに、「暗号で保護する」といったように、情報の盗み出しを防止するという観点でしか語られないことが多いように思える。例えば、8月16日の日記に

「e-Japan重点計画-2003」のp.45に次の記述がある。

(2) インターネット端末やインターネット家電が普及し、それらがインターネットに常時接続されることを想定し、十分なアドレス空間を備え、プライバシーとセキュリティの保護がしやすいＩＰv6を備えたインターネット網への移行を推進する。

e-Japan重点計画-2003, III重点政策5分野, 1.世界最高水準の高度情報通信ネットワークの形成

IPv6が「プライバシーの保護がしやすい」ものだというのは、初めて目にした。どういう根拠なのだろうか。ちゃんとわかっている人が書いているのかどうか、不安になる。

ということを書いたが、ひとつの憶測は、IPv6が標準でIPsecを提供するため、暗号による通信のセキュリティの確保ができ、その結果プライバシーが確保されるということを言っているのではないかという解釈だ。日本のIT屋の間ではプライバシーがそういう観点でしか語られていないという疑いがある。

Libertyは、以下の記事にあるように、セキュリティとプライバシーと利便性の3つを同時に実現しようとするものだ。

インターネットが個人の生活に普及しつつある中、さらなる浸透のために解決すべき課題が、アイデンティティ・マネジメントといえる。......

さらには、次世代のアプリケーションであるWebサービス対応のアプリケーションの提供が本格化した場合、認証関連で普及が阻害されるということも考えられる。だが、ユーザーのプライバシー保護懸念の声も考慮しなければならない。この課題には、業界全体、場合によっては政府も巻き込んだ形で取り組み、より良いモデルを見出していかねばならない。
 「アイデンティティ・マネジメントはインターネットの次の大きなチャレンジ。ソフトウェア開発者、セキュリティのエキスパート、企業の経営陣、そしてユーザー、すべてが関心を払わなければならない課題だ」とシュネル氏は言う。

@IT, [RSA Security 2002開催] セキュリティ、プライバシー、利便性が個人情報管理のキー

ここで言う「プライバシーは」、セキュリティの結果としてのプライバシー（情報の盗難防止）のことではない。安易なシステムアーキテクチャの下では、むしろセキュリティ強化はプライバシーを低下させる（同一性を不必要に記録可能にさせる）ものであり、両者は元々相反する性質のものだ。情報セキュリティに携わる者はこのことを基礎的な素養として心得ておくべきである。Libertyは、工夫されたシステムアーキテクチャによってこれらを可能な限り両立させようという試みだろう。

■ パソコンメーカは穴のあいた製品を店頭に並べていてよいのか

日経Windowsプロからすばらしい記事が出ていた。

• NEC，Blasterワームのセキュリティ・ホールを修正済みのパソコン発売

  通常，パソコンにプリインストールされるWindows OSへの修正は，Service Pack（SP）のレベルなことが多い。しかし，現在はMS03-026のセキュリティ・ホールを狙ったBlasterワームや，「Nachi（Welchia）」ワームが蔓延しているため，「買ってきたパソコンをインターネットに接続するだけでワームに感染する」という状況になっている。このような状況でも安心して利用するため，NECではWindows XPの新SPの提供を待たずに，自社で修正パッチをあらかじめWindows XPに適用して，新製品を出荷する。出荷開始日はいずれも9月11日である。

  同様の取り組みは，富士通やソニーも秋冬モデルの新製品から実施する予定である。ただし，NECのパソコンにしても，現在店頭に並んでいるモデルは，セキュリティ・ホールが無修正のままだ。......

• 中田 敦＝日経Windowsプロ, マイクロソフトはサービス・パックの提供を早めるべきだ

  
 重いPCベンダーの「責任」

  Microsoftだけでなく，「Windowsプレインストール・パソコン」という最終製品を販売しているPCベンダーにも努力が求められる。PCベンダーは，Microsoftから“調達”したWindows XPに自社でソフトウエアを追加して販売している。それと同じように，MS03-26の修正モジュールもあらかじめ製品にインストールすればよいのだ。

  実は，PCベンダーにはそのような修正を加える権利がMicrosoftから与えられている。実際にNECや富士通，ソニーといった大手ベンダーは，9月〜10月に発売する予定の秋冬モデルの新製品から，MS03-26の修正モジュールをあらかじめ追加して製品を販売する予定である。

  Windowsパソコンという最終製品を販売しているのは，MicrosoftではなくPCベンダーである。消費者に対する責任を果たすために，一刻も早くセキュリティ修正を施したパソコンを出荷するべきである。

パッチを適用したパソコンを出荷するのは大変よいことだが、Blasterワームが流行していてやむにやまれずといったところだろう。ユーザサポートのコストを下げる意味もあるに違いない。

パッチを事前に適用しておくのが、MS03-026だけなのか、他も全部なのかが興味深いところだ。また、今後も継続して最新パッチを適用した上で出荷するのかも興味深い。

ワームに感染する穴でなければあけたまま出荷してもよいというものではないだろう。個別のターゲットを狙った攻撃による被害の可能性は依然として残る。

パッチが出ているにもかかわらずそれらを適用せずに出荷したパソコンメーカーは、欠陥による損害が予見できたはずであり、損害賠償訴訟を起こされたら負けるのではなかろうか。というか、負けるようでないと世の中、このままではダメなんではないか？ 誰か一度、判例作りのために試したらどうか。あいにく私は損害を被っていないので訴えられないが。

マイクロソフト日本法人は，Blaster対策CD-ROMを20万枚配布するといった対策を発表しているが，年間1000万台パソコンが出荷される日本においては，焼け石に水である（関連記事）

中田 敦＝日経Windowsプロ, マイクロソフトはサービス・パックの提供を早めるべきだ

焼け石に水という以前に、そもそも、パソコンメーカーが現在店頭に置いている製品を、修正CDを添付せずに販売し続けることが、違法でないことがおかしい。マイクロソフトの20万枚など、ただのポーズだろう。配布のコストもセキュリティベンダーの宣伝費でまかなったに過ぎない。

ちなみに、2002年にソニーのVAIOにプリインストールされていたソニー製のソフトウェアに任意コマンド実行のセキュリティ欠陥が発覚したときには、

ソニーによると、...... 1月24日にこちらのWebサイトからセキュリティ・プログラムを無償ダウンロードできるようにしたほか、希望するユーザーには、CD-ROMの配布も行う。また、店頭にある在庫については、アップデート用CD-ROMを商品に添付する。

なお、1月26日以降に発売する機種については全モデルに対策用プログラムを付属、またはインストールして販売するとしている。

日経BizTech, ソニー、「バイオ」専用プログラムにセキュリティ・ホール

という極めて適切な対応がとられた。というか、これが当たり前ではないのか？

■ 今日の日記

今日はRIETIに行ったので、帰りがけに池田信夫さんと1時間ほどさしでお話をしてきた。内容は内緒だ。

■ そろそろ潮時か

この日記の役目もそろそろ終えたかなあと感じる今日この頃。

当初言いたかったことは順々に書いてきてほぼ書き終わった。途中、予期せぬ出来事も起きてネタが増えたりもした。

まだ終えていないのは、


• Pentium IIIのPSN問題。なにをやろうとしていたのか、誰がどのように批判していたか、どうして中止に追い込まれたか、日本ではどういう反応だったか。
• MACアドレスの問題。サブネット内にしか飛ばない(?)ので通常は問題にならないが、ホットスポットではどんなドメインに読まれるのか。既に対策が取られていたり対策法の研究事例があるか。Bluetoothにも同じ問題があるか。

など。情報募集中。

■ Googleは日記を過大評価しすぎ？

住民基本台帳カードの「I'm Feeling Lucky」がこの日記だというのは、いかがなものなのか(^_^;)。Googleの表示順は、日記を過大評価しすぎではないか？ 8月23日に書いた件も、勤務先を日本語にしたり画像をテキストにしてみたが、元に戻らなかったしなあ。

■ 「欠陥」なのか「脆弱性」なのか

夜9時のNHKニュースに「ウィンドウズに新たな欠陥」が流れたようだ。録画してあった7時のニュースには流れていなかったが、実家の母からの電話によるとそうらしい。

報道の内容はこうだ。

マイクロソフト社製の基本ソフトWindows XPなどに、インターネットを通じて侵入される深刻な欠陥が新たに見つかり、マイクロソフト社では、先月と同じようなコンピュータウイルスによる被害がおきるおそれがあるとして、欠陥を急いで修復するよう、利用者に呼びかけています。

新たな欠陥が見つかったのは、マイクロソフト社製の基本ソフトWindows XPやWindows 2000などです。マイクロソフト社によりますと、今回見つかった欠陥をそのままにしておくと、インターネットを通じてパソコンに侵入され、重要な情報を盗まれたり消されたりするおそれがあるということです。

また、先月、ブラスターと呼ばれるコンピュータウイルスによる被害が相次ぎましたが、今回見つかった欠陥を狙って、同じようなウイルスによる被害がおきるおそれもあるということです。

マイクロソフト社では、欠陥を修復するソフトを今日からホームページで公開し、利用者に欠陥を急いで直して欲しいと呼びかけています。

NHKニュース, ウィンドウズに新たな欠陥, 2003年9月11日

すばらしい。さすがNHK、的確だ。（欠陥を「修復」というのは日本語として変だとは思うが。壊れたものを元に戻すわけではないのだから。「修理」でどうだろうか。）

ところで、ようやくこのように報道されるようになったわけだが、「欠陥」と報道することに対して、「欠陥という表現は不適切だ」といった趣旨の抗議の発言が出たことがあるらしいという情報を入手したことがある。なんでもその人物の言い分は、「コンピュータには専門の言い方があるのだから」というのだ。それ以上の詳しいことは聞いていないが、おそらく「『脆弱性』と言え」ということなのだろう。誰だか知らないが、「おまえは馬鹿か？」と言いたい。

「脆弱性」という言葉が使われるのには訳がある。セキュリティ上の問題点には、いろいろなものがあり、直ちに「欠陥」とはいえないが、あまりよろしくないこと（たとえば、別の何かと組み合わせた特定の条件下でだけ攻撃が成立するものや、十分な時間をかければ突破できるといった強度が低いという部類もの）が見つかった場合に、それをなんと呼べばよいだろうか。「欠陥」という用語でリストを作っていると、欠陥ではないものをリストに入れられなくなる。だから、より広い意味*1の言葉である「vulnerability」（日本語で、「弱点」ないし「脆弱性」）をリストの名称として使い、できるだけ多くの（危険性の低いものも含めて）リストに掲載するわけだ。

つまり「脆弱性」とは、欠陥である脆弱性と、欠陥でない脆弱性の両方を包括的に指す呼称なのだ。

自動車のいわゆる「リコール」にも、「リコール」の他に、「改善対策」と「サービスキャンペーン」という呼称がある。例えば本田技研工業の解説から引用すると、

＜リコール＞　自動車が道路運送車両の保安基準に適合しなくなるおそれがある状態で、その原因が設計または製作の過程にある場合、国土交通省に届け出て自動車等を無料で修理します。

＜改善対策＞　保安基準不適合状態ではないが、安全上または公害防止上放置できなくなるおそれがあり、その原因が設計または製作の過程にある場合、国土交通省に届け出て自動車等を無料で修理します。

＜サービスキャンペーン＞　リコールまたは改善対策に該当しない場合であり、商品性や品質の改善のためにメーカーが行う修理・改修で、国土交通省の通達に基づく制度です。

リコール制度・改善対策制度とは

先に述べた「欠陥でない脆弱性」へのパッチは、自動車で言う「改善対策」に相当するだろう。「サービスキャンペーン」は、セキュリティに関係しない通常のパッチといったところか。

欠陥と言える脆弱性のことを「欠陥」と呼んで何が悪いのか。一般に、特定の事象を説明するには、できるだけ狭義の言葉を使って説明するのが優れた説明である。どうして欠陥である脆弱性のことを、わざわざ「脆弱性」などという広い意味の言葉で言えというのか。
 そして、MS03-026やMS03-039は、Microsoft自身が「緊急」と位置づけているのであるから、当然それは「欠陥」である。これが欠陥でないならば、欠陥は存在し得ないことになる。

もしかすると、「ソフトウェアはPL法の対象外だから『欠陥』と呼ぶべきでない」とかいう意味なのかもしれないが、「欠陥」というのは法律専用の言葉ではない。一般庶民も使う普通の日本語だ。むしろ、PL法の対象外だというのなら、欠陥と呼ばれたって問題なかろう。

同様のパターンとして、明らかに事故が起きたのに、「こういうのはインシデントと言うんですよ」などとぬかす奴もいる。

ちなみに、新聞の報道はどうか。

• 読売新聞, ウィンドウズにまた欠陥
• 朝日新聞, ウィンドウズに新たな欠陥、対策重要度は最高の「緊急」
• 日経新聞, マイクロソフト、ウィンドウズに新たな欠陥
• 毎日新聞 DIGITALトゥディ, ウィンドウズに「緊急」のセキュリティーホール
• 日経IT Pro, Windowsにまたもや“超特大”のセキュリティ・ホール，すぐにWindows Updateの実施を
• INTERNET Watch, Windows RPCSSに任意のコードが実行される脆弱性「MS03-039」

IT専門性の高いメディアほど、「欠陥」という言葉を使っていないようだ。それは、IT専門性の高いメディアでは、読者も専門用語を理解できるからだろう。一般の消費者に、「セキュリティホール」と言っても意味がわからないとするならば、「安全上の欠陥」と書くべきであり、それを「脆弱性と言え」などと抗議するのは愚の骨頂だ。

■ 取扱説明書に記載されないWindows Updateの必要性

8月20日にマイクロソフトの記者会見があり、その様子が以下のように伝えられていた。

マイクロソフトでは、最初にBlasterウイルスが検出されたのは日本時間で8月12日。（略）14日・15日と報道機関に対し、セキュリティ窓口の24時間対応や特設Webページのアナウンスを行ない、パソコン以外のアクセス方法として、FAX対応やiモードサイトなどもスタート。全国紙に“対策告知広告”も掲載した。

INTERNET Watch, マイクロソフト、Blasterウイルスの記者説明会開催

マイクロソフトは今後の施策として、短期的には（1）緊急対策用無償CD-ROMの配布、（2）告知広告展開、（3）25日までの24時間サポート、を行う方針。

ZDNet JAPAN, マイクロソフトとセキュリティベンダー、MSBlastワーム緊急対策用CDの無償配布を決定

新聞への告知広告は、8月15日の夕刊各紙と、8月22日の朝刊各紙に掲載されていたようだ。以下の引用は、15日の日経新聞夕刊と、22日の読売新聞朝刊のもの。前者は6面、後者は第1社会面に載っていた。

日本経済新聞2003年8月15日夕刊6面

読売新聞2003年8月22日朝刊29面

ここに書かれているのは、Windows XPの場合の対処方法で、「(1)パソコンの電源を切る→(2)ネットワークケーブルを抜く→(3)電源を入れる→(4)「インターネット接続ファイアウォール(ICF)を有効にする→(5)ネットワークケーブルをつなげる→(6)Webサイトを見て、ウイルス対策を行う」ということが書かれている。図は(4)の手順を図解したもの。(6)の案内先として http://www.microsoft.com/japan/technet/security/virus/blaster.asp のURLが紹介されている。その他、フリーダイヤルとFAX情報サービスの電話番号、iモード版の案内のURLが掲載されている。

告知広告を出すと聞いて、Windows Updateの重要性を説いたり、今後新たな脆弱性が発覚したときに新聞広告での告知が行われるようになるのかなと期待していたが、上のものは、Blasterワーム対策のための緊急告知のようだ。それだけ切迫した状況があったということだろうか。

ところで、同じ8月22日にこんな記事も出ていた。

日本経済新聞2003年8月22日朝刊

これはMS03-032のことだと思われるが、この文面からそれがわかるだろうか。「緊急」にランクされるIEのセキュリティホールはしょっちゅう見つかっているわけで、この記事が1か月前、1年前のものだと言われても、そう見えてしまうだろう。

この記事が新聞記者が自らの意思で書いたものなのか、それともマイクロソフトからの連絡を受けて書かれた記事なのかはわからないが、この調子で、毎週に近いペースで同じ文面の記事が出るとなると、読者はどう感じるだろうか。

じゃあどうすればよいのかというと、名案を思いつかない。番号を書いても普通の人にはわからないだろう。欠陥の内容の特徴を少しでも書くとよいだろうが、読者には意味のわからない用語を使わざるを得ないだろう。脆弱性にニックネームを付けてはどうかなどという話もあったが、はたしてどうか。

「Windows Updateを使いましょう」と周知するというのはもちろんやるべきことだが、そもそもそれは新聞広告ですることではなく、製品の取扱説明書でやっておくのが当然のはずだ。

Windows XPの「ファーストステップガイド」を見てみたが、Windows Updateを使う必要性についての説明はないし、「自動更新」の説明も見当たらない。

Windows XP ファーストステップガイド 表紙

Windows XP ファーストステップガイド 目次

このガイド中、Windows Updateという言葉が出てくるのは、次の2か所しかない。

Windows XP ファーストステップガイド トラブルシューティング情報の参照先

Windows XP ファーストステップガイド 詳細情報を入手する

どちらも「情報を得たいならば見よ」ということを言っているだけで、Windows Updateが安全上、必須のものであるとは全く言っていない。

パソコンメーカはどうか。VAIOの取扱説明書（2002年購入モデル付属のもの）を見てみたが、Windows Updateに関する説明は全くない。「電子メールをやりとりする」といったことまで説明している説明書であるにもかかわらずだ。最初に「安全のために」というページがあるわけだが、ここは火災や感電につながる危険の話しか書いていない。

VAIO取扱説明書 表紙

VAIO取扱説明書 目次, 安全のために

VAIOの取扱説明書には、「インターネットを始める」という章の中に、「インターネット上のトラブルについて」という説明ページがある。

VAIO取扱説明書 インターネット上のトラブルについて

何もないよりはましだが、ここで書かれているのはかなり抽象的な話にすぎず、知らない人に何かを知らせるという効果があるとは思えない。

「情報の機密性について」という部分には次のように書かれている。

情報の機密性について

ソフトウェアやOSなどの不具合により、コンピュータの情報などがインターネット上にもれ出すことがあります。悪意を持った人たちの標的になりやすいため対応することが必要です。

ウェブブラウザやOSの各ソフトウェアの情報が、開発元のホームページなどに掲載されていますので、不具合情報をこまめに確認することをおすすめします。

また、電子メールには完全な機密性はありません。送信する内容にはご注意ください。

これはひどい文章だ。

まず、「開発元のホームページなどに掲載」というのは、具体的にどこに掲載されているというのか。それを説明するのがこのページの役割ではないのか？ 最低でも、ソニーの製品についてはURLを書くべきではないのか？ なぜ書かないのか？ わざと書かないようにする何かしらの意図があるのだろうか。

電子メールに機密性がない話をここで同列に扱うセンスも理解し難い。電子メールが盗聴され得るものであるのは仕様だが、上の話は不具合の話だろう。不具合があるのも仕様だと言いたいのだろうか。

「悪意を持った人たちの標的になりやすいため」というのがなんだか稚拙な文に見えるが、「ソフトウェアやOSなどの不具合により」とは、まったく他人事のような物言いだ。「各ソフトウェア」をインストールした行為主体は誰なのか。

「OS」とは何なのか。Windowsのことだろう。なぜWindowsと書かないのか。「OS」などと書いて、普通の読者にわかるわけあるまい。新聞では使われない言葉だ。なぜこのページだけ専門用語が出てくるのか不思議だ。

先週、MicrosoftのScott Charney氏の講演を2度も聴く機会があったが、彼のひとつの言い分は、コストとのバランスというものだった。つまり、セキュリティ対策にコストをかけすぎれば製品の価格が高くなるがそれでよいのかという話だ。だが、最初から製品マニュアルにWindows Updateの必要性を記載しておくことにどれほどのコストがかかるというのか。ゼロに等しいだろう。

ソニーにしても、「インターネット上のトラブルについて」などという中途半端な文章を差し込む暇があるなら、各プレインストール製品ごとのアップデート方法を説明すべきではないのか。それにかかるコストはそんなに莫大なものか？

きちんとした説明がなされない理由は、コストにあるのではなく、あえて避けたい意図があるように思えてならない。たとえば、

• Windows Updateをすると動かなくなる部分が出ることがあり、そうなるとそのサポートコストが増大するので、できるだけお客さんにはWindows Updateして欲しくない。（ワームのような大規模被害が出るとサポートコストが増大するのでそれは避けたいが、個別のお客さんの被害のことは気づかれやしないので無視しておけばよい。）
• 製品名を特定して、不具合を直す必要性を説明すると、その製品に欠陥があるということを自ら認めることになる。それは避ける必要があるので、曖昧にしてごまかしておく。

といったことが考えられる。

■ 警察庁の頑張り

@policeからメールマガジンが来たのだが、

@policeメルマガ No.7     2003/09/17


目次：1. 人気コンテンツ 月間ベスト3
           8月の第1位も、「重要なお知らせ」
...
--------------------------------------------------------------------------
 1. 人気コンテンツ 月間ベスト3
--------------------------------------------------------------------------
 8月の@police人気コンテンツ ベスト3は


 1位 重要なお知らせ
 2位 キッズ！
 3位 セキュリティ講座　入門講座


 　となりました。3カ月連続「重要なお知らせ」が第1位です。キッズ！とセキュ
 リティ講座が入れ替わりました。

寒すぎる。書かされている人も大変だ。

INTERNET Watchにはこんな記事が。

架空請求メール事件では、「いくら身に覚えがあったとしても、請求元のドメインとブラウザの“履歴機能”に残っているドメインを比較・参照すれば、自分が利用していないことが簡単に分かるはずだ。このような機能を利用して、安易に振り込まないでほしい」と訴えた。

INTERNET Watch, 光インターネットでは1台のPCがネット上の“立派な凶器”になり得る 〜セキュリティ問題特別講演会で警察庁宮城氏, 2003年9月12日

んなアホな。

• 「履歴機能」ってどれのこと？ 何日保存されている？ どうやってアクセスしていないことを確認する？
• 請求元とアクセス履歴のドメインが一致した場合、どうなの？

根本的に間違ったアドバイスだなこれは。

■ まだやっている日経コンピュータ

日経コンピュータ誌の栗原雅氏による記事「ICタグによるプライバシ侵害を巡る海外の議論は意識すべき」が出ていた。野村総研のコンサルタントの発言とのことで、栗原氏個人に対するアドバイスか？と思ってしまったが、そうではなく、報道陣向けセミナーがあったようだ。

こうした期待がある一方で、「ICタグを付けた商品が流通すると、当該商品に関連する個人情報が盗まれる可能性がある」といったプライバシ侵害を懸念する消費者の声が、特に欧米で大きくなっている。

栗原 雅＝日経コンピュータ, 「ICタグによるプライバシ侵害を巡る海外の議論は意識すべき」, 2003年9月8日

あいかわらずこの人の認識は「当該商品に関する情報が盗まれる」であって、IDによるトラッキングのことは頭にないようだ。あるいは、そういうことにしたいのか。

ただし、渡辺氏は「ICタグが消費者の手にわたるようになるまでには時間がかかる」と指摘。「そう考えると、欧米でのプライバシ侵害の議論は現時点ではやや先走っている感じがする」との見解も示した。

栗原 雅＝日経コンピュータ, 「ICタグによるプライバシ侵害を巡る海外の議論は意識すべき」, 2003年9月8日

これはどういう意味なのだろうか。消費者の手にわたるようになった時点で議論を始めればよいということだろうか。野村総研の上級コンサルタントがそんな馬鹿な発言をするわけがないので、記者の取り違えだろう。議論と反対運動を区別できないような人がマスメディアの力を持つのは社会にとって有害と言える。

ちなみに同じセミナーのレポートがCNET Japanにも出ているが、だいぶ異なる内容になっている。

RFIDの普及に向け、もっとも大きな問題となるのは、消費者にRFIDが受け入れられるかという点だ。RFIDタグが商品に付けられることで、自分の購入した商品を第3者に追跡されるのではないかという不安感が消費者にあると渡辺氏は指摘する。

CNET Japan, 野村総研が指摘する、RFIDの普及に向けた3つの課題とは？, 2003年9月8日

こちらでは、懸念されているのがトラッキングの問題であることがきちんと書かれている。

ところで、続く部分には日経コンピュータがとりあげなかった次の発言が報告されている。

一方藤吉氏は、ベンダー主体の実験だけではなく、エンドユーザーの視点を取り入れた実験が必要だと訴える。実際に利用されるような環境で実験を行い、実績を積み重ねることで、消費者が抱える不安感を払拭しなくてはならないとした。渡辺氏も「一般生活者も参画した形で実証実験を行い、RFIDタグのメリットを一般の人に理解してもらうことが重要だ」と訴え、中長期的な取り組みが必要になると語った。

CNET Japan, 野村総研が指摘する、RFIDの普及に向けた3つの課題とは？, 2003年9月8日

エンドユーザの視点も重要だが、どんなプライバシー攻撃が起きるか（起きないか）を実験で確認するには、エンドユーザの視点では駄目だろう。エンドユーザ（特に日本の）は、被害が出てからしか問題を理解できない人が大半だろう。

別のニュースについて、日経コンピュータと日経システム構築が同じネタをとりあげているのを比較してみる。

• 日経システム構築, キャベツなど食品にICタグを付ける実験が開始へ, 2003年9月19日

  マルエツは今回の実験で100人の消費者モニターを募集する。消費者モニターには，自分の嗜好などを情報センターに登録してもらう。ただし，プライバシーの問題に配慮し，登録するのは嗜好のほか年代や性別など個人が特定されない情報にとどめる。

• 日経コンピュータ, マルエツ、ICタグ5万枚を使った実証実験を開始, 2003年9月19日

  (3)のICタグは消費者モニターに持ってもらい、その消費者の趣味や嗜好（しこう）に応じた情報を提供するのに利用する。消費者モニターは約100人に依頼する見込み。「消費者が便利だと感じるのか、または抵抗を感じるのかなど、消費者の反応を分析したい」（高橋部長）。

日経コンピュータの方の記事では、「抵抗を感じるのか」が具体的に何のことを指しているのかが不明な文章になっている。

■ 噂のRFIDタグ搭載本

噂に聞いていた本が出たらしい。

しかし、タグを読み取るためのリーダが世の中に普及していない今だからこそ、街が個体識別技術であふれる世界が現実のものとなった時、どのような問題が起き得るのか、それはどのように解決していけばよいのか、限定された状況下で行なうシミュレーションによって確かめることができる」と実験の狙いについて述べている。

INTERNET Watch, Auto-IDセンター規格準拠のRFID付き書籍が出版〜世界で初の試み, 2003年9月18日

問題が起きないことを確かめるのは難しいのだから、問題が起きることを示す実験なのだろうか。

■ はてなへの寄付

はてなにはずいぶんとお世話になったので、はてなポイントで寄付をした。ポイントの購入の画面に行き、クレジットカードでポイントを購入して、はてなダイアリー日記にある「はてなダイアリー運営費捻出のための寄付にご協力ください」のリンクから寄付をした。一度に1000ポイントまでしか送信できないが、何回でも送信できる。5パーセントの手数料が別途かかるのと、残ポイントが300ポイントを下回るような送信はできないので、必要なポイント購入額を事前に計算しておいた方がよい。

はてなは時々止まることがあるし、はてなダイアリーが資源確保に見合うだけの収益を得られているとは思えなかったので寄付をしたい気持ちになったが、これは個人的な印象であって、本当に寄付が必要な状況なのかどうかはわからない。（などと書くのは無粋か。）自分が受けた恩恵に見合うと思える額を寄付した。

ちなみに、私が5月にWeb日記を始めるにあたってはてなを選んだ経緯は、まずは自分でシステムを設置しようと思ったが、個人の立場で書くことが重要であるため勤務先の資源を使うことを避け、しかしながら契約している接続プロバイダのWebページサービスではCGIを使えないため、自宅サーバを確保するしかなかった。面倒なのと時間がなかったのでそれを諦め、tdiary.netを使いたかったが募集が終わっていたので、はてなを使うことになった。

■ はてなの安全性を考える

以前から気になっていたのがここのアクセス制御の弱さだ。致命的ではなく、対策方法はそう単純ではないため対応してもらえない可能性があるので、また悪意ある者には既にわかりきったことであろうから、ここに書くことにする。5月12日の日記に頂いたコメントによれば、「はてなダイアリーへの要望」というキーワードをこのように本文中に書いておくと、運営者の目にも触れるらしい。

はてなにログインすると、「rk」という名前のcookieが発行される。その内容は、

rk=e3ver6k2e587nuyiu6o38rjwww84m3

この30文字をキーとしてセッション追跡（アクセス制御）が行われているわけだが、この30文字は、ログアウトしてログインし直しても、再び同じ値のキーが指定される。ログインを越えて不変の値であるので、これは「セッションID」ではない。

パスワードを変更した後、再ログインしてみても、同じ値のキーが使われる。したがって、パスワードを暗号化やハッシュしたものなどでもない。

実は、この30文字は、最初にユーザ登録したときに「仮登録のご案内」として送られてくるメールの、

下記URLに接続してユーザー登録を完了させてください。
http://www.hatena.ne.jp/register?mode=register&mail=...&randomkey=e3ver6k2e587nuyiu6o38rjwww84m3

どうやら、ユーザ登録した直後に生成されたランダムキー（もしくはアカウント名を暗号化したものかもしれない）が、永久に認証用として使われているようだ。

ということは、一度この値を盗まれるともうどうしようもなくなるということだ。パスワードを変更しても乗っ取られる状態は続いてしまう。アカウントを放棄するしかない。

この安全レベルは、はてなの当初の「人力検索サイト」のサービスでは、それなりに妥当なものだったかもしれないが、はてなダイアリーにとっては、ちょっと不十分であるように思える。

解決方法にはいろいろ考えられるが、標準的な方法は、セッションIDを使うことだ。ログイン時に、新たにランダムな文字列（セッションID）を生成して、cookieにセットし、そのIDからユーザを検索できる管理表をサーバ側で管理する。ブラウザからのアクセスがあると、cookieとしてセッションIDが送られてくるので、それを元にユーザを検索して、ユーザごとの処理を実行する。

ただ、この改善が、現行システムの都合で簡単ではない可能性がある。その場合に、とりあえずの対処として、（本当にこのシステムでうまく実現できるかどうかはわからないが、）現在使用している30文字のランダムキーをログインの度に変更してしまう方法が考えられる。

ユーザの自衛策としては、

• こまめにログアウトしてcookieを消去しておくことにより、cookieを盗まれる機会を減らす。
• cookieを盗まれるセキュリティホールが発覚していながらパッチがまだリリースされていないブラウザを使うのを避ける。

ことなどが挙げられる。

■ はてなダイアリーへの要望

以前に書いたように、リンク元表示は350件程度を超えるとそれ以上追加されなくなるのだが、最近、この日記では、2日ほどでそれが埋まってしまうペースになってきた。やむを得ず、空っぽの日記を書いて別の日にリンク元を収集しては消すということを繰り返している。せっかく見に来ていただいても空っぽで申し訳ないところだ。

リンク元を埋め尽くすURLの大半はアンテナであり、それらをリンク元表示に含めない機能が欲しいところだ。以前書いたように、とりあえず、はてなアンテナを含めない機能は簡単に実現できるだろう。

さらにd.hatena.ne.jpも外せる機能が欲しい。はてなダイアリー内からのリンクは別のところにリストされるので外しても困らない（アクセス件数は不明になるが）。一方で、日記ページ上にアンテナモジュールを設置している方からのジャンプがリンク元表示に記録されることで、リンクされていない日記がリンク元として表示されるのが邪魔になっている。

さらに、パワーユーザ向けに、排除するURLのパターンを正規表現で登録できるようにすることもそう難しくはないと考えられる。

■ 追記

をを、東浩紀さんからリンクされているぞ。東さんとは近々お会いする予定があって楽しみだ（何なのかはしばらく内緒）。そもそもこの日記を始めた当初、情報自由論への感想を述べることを最終ゴールとして必要な論点を積み重ねていたのだった。結局その後、言いたいことを別の形で述べてしまったため、そこに達しなかった。後日それを書きたいと思う。

■ 3年半という一区切り

毎日新聞DIGITALトゥデイの太田阿利佐記者が夕刊担当に配置換えだという。

思えば今をさること3年半前の2000年4月、パソコンの中に何が入っているかすらよく理解しないまま、辞令1枚でインターネット記者になってしまった。世界中がIT革命に浮かれる中、...(略)

10月からIT担当を外れ、新聞の夕刊担当になる。でも、ICTが私たちの生活に入り込んでいる今、引き続きICTを取材する機会も多いだろう。これまで取材でお世話になった皆さん、そして厳しい指摘や励ましをいただいた読者に、この場を借りてお礼を申し上げたい。そして、これからもどうぞよろしく、と。

太田阿利佐, あの子にメールを送りたい, 毎日新聞DIGITALトゥデイ

「太田阿利佐」という名前を初めて記憶に留めた出来事は、2000年12月、セキュリティホールmemoでこうとりあげられたときだったのを今でも鮮明に覚えている。

・おいおい、何をいまごろ MS00-045 をまじめに取りあげてるんだ毎日は。 太田阿利佐ってどういう人?

セキュリティホールmemo - 2000.12

これは何だったかというと、2000年7月に公開されていたMS00-045の脆弱性が、12月になって

マイクロソフトは1日、電子メールソフトOutlook Expressにセキュリティホールが見つかったとして、対策のための修正プログラムを公開した。

Outlook Expressに穴　MSが対策公開, 毎日新聞DIGITALトゥデイ

と報道されてしまったものだ。これは、MS00-045の文書が12月に改定されたため、最新の文書として脆弱性リストのトップに躍り出たのが原因だったと記憶している。たしか、当時の脆弱性文書は初出の日付を表示していなかったんじゃなかったか。やっぱりそうだ。archive.orgでそれが確認できる。改定日なのに「登録日」などと書かれている。だからこれはマイクロソフトが悪かった。ちなみに2001年6月の時点では、「登録日 : 2000/07/28, 更新日 : 2001/03/05」という表示に改善されている。ああ、懐かしいねこの話。

これが印象深かったのは、当時は、日本の新聞メディアが脆弱性情報を報道するということはけっしてなかった中で、ついに日本でも報道される時代になったかと感激したとたん、なんだか違うぞというオチがついていたからだ。その後、しばらくの間、結局、脆弱性情報が逐一報道されることはなかったように記憶している。「なぜMS00-045だけが？」という謎が残った。

そして現在、「ワームが来るぞ」というわかりやすい危機に追い込まれるようになったこともあり、脆弱性情報が普通に報道される時代になった。そして、似通った報道をどう区別して市民に伝えるかという新たな課題が積み残されている。そういえば、私がセキュリティ問題に首を突っ込んだのも3年半ちょっと前、2000年の1月末からだ。ここに来てひとつの区切りが付いた感がある。配置換えのタイミングは偶然の一致だろうか。

太田記者の記事をはじめ、DIGITALトゥデイの記事は、技術面で比較的正しく書かれているという点で安心して読める数少ない一般紙メディアとして貴重だったと思う。検索してみると、数々の情報セキュリティ侵害事件の報道が今でも読める貴重な資料館となっていることがわかる。これは私の想像だが、専門的すぎるという理由で新聞ではボツになるITネタが、DIGITALトゥデイの場でうまく活かされてきたのではなかろうか。

その太田記者が2000年4月の時点で、コンピュータのど素人さんだったということに驚く。そんな氏の取材を勤務先で受けたことがある。1年半くらい前だっただろうか。ずいぶん長く考えを述べた気がするが、結局それは記事にならなかった。電話取材を受け、話したことと違うことを書かれて痛い思いをする経験もした。研究者は、喜んで取材に応じる反面、どう書かれるのやらと戦々恐々とする面があるように思う。学会発表の場に駆けつけてきていらしていてびっくりしたこともあった。

太田記者はコラムのコーナーでなんとも味わい深い記事を書かれてきた。特に好きだったのはコレ。

• 太田阿利佐, 桜のはなびら, 毎日新聞DIGITALトゥデイ

こちらも別の意味で面白かったかな。不謹慎ながら。

• 太田阿利佐, 片山総務相に期待, 毎日新聞DIGITALトゥデイ*1

今回のコラムもなかなか……。

「あの子にメールを送りたい」というのは、新しくて古い、きっととても自然な感情なのだ。一連の技術が、管理や監視ではなく、個々人のプライバシーを守りながら、コミュニケーションと相互理解を深める方向に発展していくことを願ってやまない。そのためにネットワークをデザインしていく役目は、もはや技術者だけでなく、私たちみんなに課されている。

太田阿利佐, あの子にメールを送りたい, 毎日新聞DIGITALトゥデイ

夕刊の購読申し込みってどうやるのかな。

■ アンテナ除けの設置

9月23日の日記には、

リンク元表示は350件程度を超えるとそれ以上追加されなくなるのだが、最近、この日記では、2日ほどでそれが埋まってしまうペースになってきた。

しかし、アンテナ除けに記録されるリンク元が満杯になると、新たなリンクが記録されたかは、過去のそれぞれの日のリンク元を確認しなくてはならなくなる。つまり、はてなダイアリーの設定項目にある「リンク元の記録を、『最新とリンク先の両方の日付の日記』に対して行う」の機能が役に立たなくなる。

そこではてなダイアリーへの要望だが、このリンク元の記録方法の選択肢に、「トップページへのリンクは記録しない」というオプションを加えてはどうだろうか。ここで言う「トップページ」とは、日付を指定しないURL（私の日記の場合の http://d.hatena.ne.jp/HiromitsuTakagi/ ）のこと。これでアンテナは一掃できるはずだ。アンテナ除けもいらなくなる。この要望は、アンテナらしきURLを記録しないという機能を設ける要望よりは簡単に実現できるもののように思える。

■ 追記 (9月28日)

tDiaryでは早速対応されるもよう。と思ったら、はてなでも早速対応していただけた。すばやいご対応に感謝。というわけで、「アンテナ除け」は撤去した。

■ 絶対に見つけられないWebアプリ攻撃は存在する

7月に伊原さんからケーキオフの「WebAppへの攻撃は見つけられるのか？」の回への議論参加のお誘いを頂いていたのだが、ずいぶんはるか先の話だなあと思っているうちに忘れてしまい、それが今日だったことを知った。あれからもう2か月が過ぎ去ったのか。突っ込みコメントできることはありそうだったので行きたかったのだが、痛恨。

というわけで、資料とビデオを拝見した上で、以下コメント。

最後の「まとめ」として、「絶対に見つけられない攻撃は存在しないはず」と述べられているが、それは正しくない。

セッションIDを盗むまでもなくパスワードなしにログイン状態に入れてしまうタイプの欠陥を突いた攻撃については、一定時間以内前にパスワード送信のアクセスがあったかどうかをログから調べれば攻撃の有無を調べられるだろう。しかし、正規ユーザがログイン中のタイミングでのセッションハイジャック攻撃は、その方法では攻撃の有無を調べることができない。

国分氏の講演では、セッションハイジャックを見つける方法として、「Set-Cookie: で発行したセッションIDと異なる Cookie: が送られてきた場合を探す」ということが述べられているが、攻撃者は、そもそも Set-Cookie: を発生させるようなアクセス（通常、これはパスワード送信時に起きる）をすることなしに、最初から直接に、他人用のセッションIDを Cookie: としたリクエストを送信するのだから、この方法では検出できないだろう。

また、「同じユーザから何度もアクセスがある中で、セッションIDが途中から違っているものを見つけられるかもしれない」ということも述べられているが、問題は、「同じユーザ」というのをどうやって判別するのかだ。そもそも、同じユーザであることを識別するためにセッションIDを必要としているのであるから、「同じユーザからのセッションIDが変化した」ということを完全に検出することは本質的にできない。

では、「同じユーザ」を、同じIPアドレスからのアクセスかどうかで判別する方法はどうだろうか。

まず、同じIPアドレスから異なるセッションIDが飛んでくることは、ごく日常的な事態のはずだ。企業内ユーザのProxyサーバ経由のアクセスや、規模の大きなNATごしのアクセス（一部のケーブルテレビ接続の場合など）の場合には、当該ドメインから複数のユーザがログインしていれば、そうした事態は普通に起きる。それを攻撃とみなすわけにはいかないだろう。

次に、同じセッションIDが異なるIPアドレスから飛んできた場合を攻撃とみなすという考え方がある。しかし、ダイヤルアップ接続のユーザならば、一旦電話を切ってデータ入力をし、再び接続してボタンを押すという、ケチケチアクセスをするかもしれない。その場合、同じセッションIDが異なるIPアドレスからやってくることになるので、これを攻撃とみなすわけにはいかない。

これを「攻撃の可能性がある」とみなしてアクセスを拒否してしまうという対策はアリかもしれない。しかし、そうした対策をとっているサイトは極めて少ないようだ。

まず、企業内ユーザからのProxy経由のアクセスは、アクセスごとにIPアドレスが微妙に変化することが多い。Proxyが複数台のサーバで負荷分散されている場合に、アクセスごとに異なるIPアドレスのサーバを経由することがあるからだ。（この現象は、普通のWebサーバのアクセスログから、大手企業からのアクセスのログを探して、ざっと眺めてみるだけでも知ることができる。）したがって、単純に完全にIPアドレスが一致するかどうかで判別すると、Webアプリが正常に動かなくなってしまう。そこで、一定のアドレスブロックの範囲内であれば同一とみなすという対策が考えられる。こうした対策をとっているところは、少数派ではあるが、存在はする。しかし、同じダイヤルアップ接続プロバイダ内からの攻撃を判別することができない。より厳密に対策したければ、アクセス元が接続プロバイダなのかProxyなのかといった情報などから、細かく条件別に判別するようにするしかないだろう。

そして、この方法で対策をとったとしても、セッションハイジャック攻撃を完全に防げるわけではない。なぜなら、同一企業内、同一接続プロバイダ内、同一NAT内からの、第三者アクセスを判別することはできないからだ。同様に、事後に攻撃がなかったことを証明することも不可能だ。

では、セッションIDを盗み出す時点で攻撃を見つけるというのはどうだろうか。当該サーバのクロスサイトスクリプティング脆弱性を突いた攻撃は、POSTアクションも含めたログから検出することができるだろう。しかし、cookieを盗まれるのは、サーバ側のクロスサイトスクリプティング脆弱性だけではない。ブラウザのセキュリティホールによって盗まれることもあるし、ユーザ側のProxyのクロスサイトスクリプティング脆弱性によって盗まれることもあるし、secure属性の付いていないcookieをパケット盗聴で盗まれることもある。これらはサーバ側では検出できない。

次に考えられる対策は、セッションIDとは別に、シーケンス番号をcookieなどでブラウザに渡す方法だ。ここで言うシーケンス番号とは、アクセス1ページごとに変化させるもので、同じセッションIDに対して同じシーケンス番号のアクセスが2度以上きたら異常事態とみなして、アクセスを拒否する方法だ。攻撃者がセッションハイジャックするとき、正規ユーザよりも先に「次ページ」をアクセスした場合には、残念ながらアクセス拒否とならないが、正規ユーザがその後に「次ページ」にアクセスした時点で異常は検出できる。

しかしこの対策がとられていたとしても、ユーザがログアウトボタンを押さずにウィンドウを閉じた場合には、攻撃者はその後を見計らってハイジャックアクセスするようにすれば、バレることなく攻撃を成功できてしまう。特に、パケット盗聴が可能な状況では、そうしたタイミングを見計らうこともできるだろうし、ブラウザのセキュリティホールを突いてcookieを盗む場合には、盗んだ後ブラウザを終了させてしまうこともできるだろう。

講演では、「ひとり分の情報だけ吸い出して満足することはないだろうから、次々と連続して複数のアカウントのデータを吸い出すだろうから、そうしたアクセスを見つける方法がある」と述べられていたが、それはその通りだろう。攻撃者が、一人分で満足する場合にはその限りでない。

総合的に言うと次のシナリオが最もバレない攻撃となる。攻撃者が被害者のパケットを盗聴できる状況にいる場合。この場合には、同じIPアドレスブロックから攻撃のアクセスができる場合が多いだろう。仮にシーケンス番号対策がとられていたとしても、ユーザのアクセス行動をウォッチできるのだから、シーケンス番号対策を回避できる。そして、攻撃対象Webアプリに、セッションID用cookieにsecure属性を付けてない欠陥があるならば、それを盗聴してセッションハイジャックされると、攻撃を検出できない。

一方、安全なWebアプリを作ることはできる。cookieでセッション追跡を実装すると、仮にWebアプリに欠陥がなくても、ユーザのブラウザのセキュリティホールを突いてセッションIDを盗まれる可能性があるが、セッションハイジャックされても、重要な情報を盗まれないような画面構成にすればよい。すなわち、重要な画面に入るには再度のパスワード入力が必要なようにし、そこのセッション追跡にcookieを使わないようにする。もちろん、その部分の仕組みに別の欠陥があってはならないのだが。