最新 追記

高木浩光＠自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1824   昨日: 1295

2007年12月01日

■ PKIよくある勘違い(10)「正規の証明書でやっているので警告が出たとしてもそれは安全だ」

「サーバをオレオレ証明書で運用するのはケシカランことだ」という認識が普及してくると、こんどは逆に、こんな説明が流行するようになるのかもしれない。今のところ「よくある」という状況ではなく、稀にしかないようだが、こんな事例があった。

図1: 「サイバー大学SNS」に現時点で書かれている注意書き

「セキュリティの警告」画面が表示される場合があります。

実際にログインしてご利用いただくサーバの証明書には問題はなく、セキュリティ上の心配はございません。「はい」をクリックしてご利用をお続けください。

このサイトは、実際のところ「Cybertrust Japan Public CA」発行の正規の証明書が正しく設定されているようだ。正しいサーバ証明書で運用されているのだから、利用者のブラウザ上でオレオレ警告が現れたなら、それはまさに盗聴されているときだ。それなのに、「はい」をクリックせよという。*1

おそらく「セキュリティの警告」というのは別の警告ダイアログのことなのだろうが、「証明書には問題はなく」「『はい』をクリック」などと書いていると、利用者は誤った理解をしてしまうだろう。

よけいなことは書かないようにするか、もしくはきっちりと説明するしかない（どの警告はよくて、どの警告は駄目なのか）。

■ オレオレ警告を無視させている大学

IE 7の強烈な警告メッセージを無視させている（もしくは無視させていた形跡のある）ところは、さすがに少なく、11月17日の日記の追記に書いたところくらいしかみあたらなかったが、キーワードを変えてもう少し調べてみたところ、もう1か所見つかった。

「○○にアクセスしていることを確認して」という作業は何の確認にもなっていない。サーバ証明書の役割がフィッシング対策だと勘違いしているのだろう。

その他、IE 6について無視する指示を出しているものを探してみたところ、現在でもまだけっこうあるようだ。

現在も第一種オレオレ証明書で運用中で警告を無視させているところ
  • 北星学園大学, 資料請求

    ・資料等請求のお申し込み・キャンパス説明会のお申し込み

    ※セキュリティの警告ウィンドウが表示されますが、セキュリティについては何ら問題ありませんので、安心して警告ウィンドウ中の『はい』をクリックしてください。

    発行者：E = (略), CN = localhost.localdomain, OU = SomeOrganizationalUnit, O = SomeOrganization, L = SomeCity, S = SomeState, C = --
    発行先：E = (略), CN = localhost.localdomain, OU = SomeOrganizationalUnit, O = SomeOrganization, L = SomeCity, S = SomeState, C = --
    有効期限：2006年2月3日 12:12:26

  • 名城大学, 学生ポータルサイト 使用上の注意

    ４．学外からの学生ポータルサイトへのアクセス

    2.セキュリティの警告
    [はい]をクリックする

    学内及び学外から学生ポータルサイトへのアクセス マニュアル, 名城大学

    発行先：E = (略), CN = ccmoon.meijo-u.ac.jp, OU = Information Center, O = Meijo University, L = Nagoya, S = Aichi, C = JP
    発行者：E = (略), CN = ccmoon.meijo-u.ac.jp, OU = Information Center, O = Meijo University, L = Nagoya, S = Aichi, C = JP

  • 横浜市立大学 キャンパスメイト 履修申請・確認・成績照会

    ※上記サイトはＳＳＬを使用したサイトです。
    セキュリティ警告の画面が出ますが、「はい」あるいは「続行」をクリックしてそのまま進んでください。

    発行者：E = (略), CN = web-server1, OU = office, O = yokohama-cu, L = yokohama, S = kanagawa, C = JP
    発行先：E = (略), CN = web-server1, OU = yokohama-cu.ac.jp, O = yokohama-cu, L = yokohama, S = kanagawa, C = JP

  • 京都外国語大学, WebメールシステムFAQ

    Q２．学外からのログイン時に、セキュリティーの警告メッセージがでるのですが？

    A２．学外からアクセスする際には、ユーザーＩＤとパスワードを盗み取られることのないよう暗号化しています。このメッセージは、これにかかわるメッセージですので何ら問題はありません。メッセージは、以下のとおり２種類(図１・２)あり、図１・図２の順番で表示されますが、ともに“はい”で次に進んでください。

    発行者：CN = webmail.kufs.ac.jp, O = Kyoto University of Foreign Studies, L = Kyoto, S = Kyoto, C = JP
    発行先：CN = webmail.kufs.ac.jp, O = Kyoto University of Foreign Studies, L = Kyoto, S = Kyoto, C = JP

  • 女子栄養大学食文化栄養学科 Webmailの使い方

    Active!mail　へアクセスすると、『セキュリティの警告』（図１）というダイアログが表示されますので、かならず『はい』をクリックしてください。

    発行者：E = (略), CN = webml.eiyo.ac.jp, OU = Certificate Authority, O = Joshi Eiyo Univ., L = Sakado-shi, S = Saitama-ken, C = JP
    発行先：E = (略), CN = webml.eiyo.ac.jp, O = Joshi Eiyo Univ., L = Sakado-shi, S = Saitama-ken, C = JP

  • 九州大学 留学生センター 「セキュリティの警告」について

    本サイトにアクセスすると「セキュリティの警告」ウィンドウが表示されますが、問題はありませんのでご安心ください。

    本サイトではセキュリティ対策の一環として通信内容の暗号化（SSL）を行っています。この機能を利用するにはサーバにセキュリティ証明書をインストールする必要がありますが、この証明書を自分で発行していることにより「セキュリティ警告」ウィンドウが表示されます。

    通常の商用サイトなどでは、認証機関（ベリサイン社など）が発行したセキュリティ証明書を利用することで悪意の無い、実態のあるサービスであることを第三者（認証機関）に証明してもらいます。これは不特定多数が利用するサイトでは有効な手段です。 しかし、本サイトはお互いの存在が分かっている方が利用されますので、自ら発行したセキュリティ証明書を利用しています。

    珍しい思い込み。

    発行者：CN = alumni, OU = alumni, O = alumni, L = fukuoka, S = fukuoka, C = JP
    発行先：CN = alumni, OU = alumni, O = alumni, L = fukuoka, S = fukuoka, C = JP
    有効期限：2007年11月15日 16:01:40

  • 新潟工科大学 ブラウザでメール

    「セキュリティの警告」ウィンドウが開くので「はい」をクリックする

    発行者：E = (略), CN = Snake Oil CA, OU = Certificate Authority, O = Snake Oil, Ltd, L = Snake Town, S = Snake Desert, C = XY
    発行先：E = (略), CN = edumail.cc.niit.ac.jp, OU = Webserver Team, O = niit, L = Kashiwazaki, S = Niigata, C = JP

  • 三重大学工学部情報工学科 Black Board e-Learningシステム イントロダクション

    学科外からアクセスした場合，セキュリティに関する警告が表示されますが無視して「OK」等のボタンをクリックし，先に進んで下さい．

    発行者：E = (略), CN = el.info.mie-u.ac.jp, OU = FAC ENG, O = MIE UNIV, L = TSU, S = MIE, C = JP
    発行先：E = (略), CN = el.info.mie-u.ac.jp, OU = FAC ENG, O = MIE UNIV, L = TSU, S = MIE, C = JP

現在も第二種オレオレ証明書で運用中で警告を無視させているところ
  • 東京経済大学 情報システム課 VPN接続サービス

    1．クリックすると、以下のような警告画面が出るので「はい（続ける）」をクリック。

    ※警告画面を出したくない方はこちらより証明書を取得してください。（証明書インストール後、ブラウザを再起動要）

    http:// からのダウンロードでインストールさせており安全でない。フィンガープリントの確認をさせているわけでもない。

    発行者：E = ??, CN = secure.tku.ac.jp, OU = ??, O = TOKYO KEIZAI UNIVERSITY, L = ??, S = ??, C = ??
    発行先：E = ??, CN = secure.tku.ac.jp, OU = ??, O = TOKYO KEIZAI UNIVERSITY, L = ??, S = ??, C = ??

  • 梅花女子大学 学内者向け(CCS) 外部からのアクセス方法について 証明書のインストールについて

    「セキュリティの警告」という画面が表示されたら、「証明書の表示」をクリックして、証明書のインストールを行います。

    （中略）

    次に、以下の画面が表示されたら、「はい」をクリックします。

    （中略）

    「セキュリティの警告」画面に戻ってきますので「はい」をクリックします。

    そのままインストールさせており安全でない。フィンガープリントの確認をさせているわけでもない。

    発行者：E = (略), CN = localhost.localdomain, OU = SomeOrganizationalUnit, O = SomeOrganization, L = SomeCity, S = SomeState, C = --
    発行先：E = (略), CN = localhost.localdomain, OU = SomeOrganizationalUnit, O = SomeOrganization, L = SomeCity, S = SomeState, C = --

  • 東京富士大学 学外での学生用ウェブメール使用方法

    2. 右の「セキュリティの警告」ウインドウが表示されます

    3. とりあえず、Ａの「はい」ボタンを押せば東京富士大学ウェブメールのログイン画面になります。

    4. 自宅のパソコンで毎回アクセスする度にこのウィンドウが表示されるのを回避するには、Ｂの「証明書の表示」ボタンを押します。

    5. 右の「証明書」のウィンドウが表示されますので「証明書のインストール」ボタンを押して画面の指示通りに実行します。

    6. 以上の作業で次回から「セキュリティの警告」ウィンドウは表示されなくなります。

    そのままインストールさせており安全でない。フィンガープリントの確認をさせているわけでもない。

    発行者：E = (略), CN = email.fuji.ac.jp, O = email.fuji.ac.jp, L = Shinjuku, S = Tokyo, C = JP
    発行先：E = (略), CN = email.fuji.ac.jp, O = email.fuji.ac.jp, L = Shinjuku, S = Tokyo, C = JP

過去にオレオレ証明書を無視させていて、誤りを訂正していないところ
  • 福岡大学 総合情報処理センター

    10月3日(水)8時頃より電子メールサービス（@fukuoka-u.ac.jp）における暗号化通信のための更新作業を行いましたが、 NetScape・FireFox等　一部ブラウザにおいて、警告メッセージが表示される現象が発生しています。現在原因を調査中ですが、暗号化通信についての問題は一切ありません。

    1.図1の画面が表示されるので、「この証明書をこのセッションのために一時的に受け入れる」にチェックをいれ、「OK」を押します。

  • 山形大学 学術情報基盤センター WebMailの利用方法

    以下のような「セキュリティの警告」ウィンドウが2回表示されますが、それぞれ"OK""はい"をクリックしてください。（画像）

    現在はVeriSign発行のサーバ証明書で運用されているようだが、オレオレ警告を無視するように説明している。

  • 東京学芸大学 WebClassについてよくある質問とその答え

    ログインやメニューのクリック時に「セキュリティの警告」「セキュリティ情報」等のウィンドウが表示されるが，問題ないか。

    WebClassと皆さんのコンピュータとが安全にやり取りできるよう，情報が保護されているために出てくる表示です。安心して「はい」をクリックしてください。（画像）

    現在はRSA Data Security, Inc.発行のサーバ証明書で運用されているようだが、オレオレ警告を無視するように説明している。

  • 愛知淑徳大学 SSL-VPNサービスを利用した学内サーバへのアクセス（学生用）

    セキュリティ警告の画面が表示される場合、すべて「はい」もしくは「OK」をクリックしてください。（画像）

    現在はRSA Data Security, Inc.発行のサーバ証明書で運用されているようだが、オレオレ警告を無視するように説明している。

  • 成城大学 メディアネットワークセンター

    アクセス時にセキュリティ警告が表示された場合は、証明書を受け入れてください。

    ipsCA発行の正規のサーバ証明書で運用されているようだが、オレオレ警告を無視するように説明している。（サイバー大学SNSのケースと同じパターンか？）

他にも、オレオレ警告が出る状態を放置している大学があるかもしれないが（実際、学生さんからタレコミが来たりする）、無視せよと明確な指示をしているものしか、ここでは取り上げられない。（手渡して証明書を配布している可能性もあるのだから。）

*1 ちなみに、「実際にログインしてご利用いただくサーバの証明書には問題はなく」で検索してみたところ、同じ文面の書かれているサイトが1か所あった。

本日のリンク元 TrackBacks(90)

2007年12月02日

■ 「UPKIイニシアティブ」でサーバ証明書発行プロジェクト

昨夜気付いたのだが、UPKI（全国大学共同電子認証基盤）が既に今年からサーバ証明書の発行を開始していた。「UPKIイニシアティブ」のサイトに説明文書と資料が公開されている。

実は私も2年前に東工大の客員の仕事として東工大経由でUPKIの設計に意見を挟ませて頂いたことがある。GPKIとLGPKIの失敗を繰り返さないため、Web用のSSLサーバ証明書については、構築する独自PKIとは分けるべきである旨を意見した。2つの選択肢があり、1つは、Web用のSSLサーバ証明書については普通に既存のCAから買って済ませる方法、もう1つは、Webブラウザで初めから利用できる状態にある形の認証局を構築して発行する方法である。

どうなったかは、「サーバ証明書発行・導入における啓発・評価研究プロジェクト」にある資料から窺い知れる。2007年6月8日のワークショップの資料によると、図1のように、Webサーバ用とS/MIME用の「Public PKI」と、「University PKI」とが分けられている。

図1: 片岡俊幸,「これからのPKI: 〜さまざまな大学内サービスの認証・認可の統合〜」, p6 より

https://upki-portal.nii.ac.jp/のサーバ証明書を見てみると、「NII Open Domain CA」という認証局からサーバ証明書が発行されており、図2の認証パスになっているようだ。

図2: UPKI発行のサーバ証明書の例

これは正しい。GPKIのような「○○省運用支援認証局」などというわけのわからない認証局*1ではない。

プロジェクトのFAQによると、SINETに加入している大学等に参加資格があり、無料でサーバ証明書の発行を受けられるようだ。ただし、研究という位置付けになっているためか、期間限定であり、発行されるサーバ証明書の有効期限は、2009年3月末のようだ。その先については、

平成21年度以降については、事業化を目指してはいますが、本年度のプロジェクトの評価等を踏まえ、平成20年5月ごろに決定する予定です。

とされている。事業化にあたっては、費用負担をどうするのかとか、最終的に既存の民間CAから買うのと比べて安いのかどうか、セキュリティ上達成できている性質に優位性があるのかといったあたりが評価の軸となると思われる。

これまでにいくつの大学等に発行されたのかはわからなかったが、参加大学はまだ少ないようだ。少なくともここに参加している大学は、オレオレ証明書で運用するなどという状況は生じていないのではないか。

チュートリアル資料には、「オレオレ証明書」という言葉も使われて説明されていた（図3）。

図3: 島岡政基, 「身近なPKI: サーバ証明書の重要性」, p8, 10より

日記予定

  • PKIよくある勘違い(11)「うちより下等な会社に認証してもらうなど言語道断だ」

*1 しかも、2002年に始まった当初のGPKIには「運用支援認証局」という名前すらなく、CP/CPSに定義されていない証明書を勝手にテキトーに発行しているという酷い状況だった。[memo:3458]

本日のリンク元 TrackBacks(3)

2007年12月08日

■ EZwebブラウザの「お気に入り登録」は偽サイトを見分ける手段にならない

6月6日の日記「Upcoming Advisories」で書いていた、脆弱性届出「IPA#45031375」*1*2の件について、製品開発者がFAQとして事実を公開し、IPA#45031375 は11月26日に取り扱い終了となった。

  • EZwebで表示中のページのURLを確認する方法はありますか？, KDDI, よくあるご質問/お問い合わせ, 公表日不明*3

    質問： EZwebで表示中のページのURLを確認する方法はありますか？

    回答： 確認方法はございません。

    なお、お気に入り登録時にURLが表示されますが、そのURLはサイト提供者が任意に指定することができるため、必ずしも閲覧中のサイトと一致しない場合があります。

    PCサイトビューアーの場合、「メニュー」から「ページ情報」で確認が可能です。

FAQには掲載されたものの、「お知らせ」ページ等には掲載されていないようだ。FAQというのは、それを探している人の目にしか触れないのであり、これではとても「周知を行った」とは言えない。微力ながら私から周知をしたい*4。

6月24日の日記でも改めてまとめていたように、携帯電話はアドレスバーを欠いているためphishingに騙される危険がPCに比べて高い。これは以前から言ってきたことだが、auについてこれを言うと、決まって「お気に入り登録で確認できるよ」という声が出ていた。

ところが今年3月、「お気に入り登録」では確認にならないという情報を得た。EZwebでは、以下のタグを記述することで、「お気に入り登録」の操作をした際に表示されるURLを、現在のページとは別のURLに指定することができるというのだ。 

<meta name="vnd.up.bookmark" content="任意のURL" />

なるほど、いかにも携帯電話業界の連中の考えそうなセンスの悪い機能だ。他にも、 

<meta name="vnd.up.markable" content="false" />

と書くことでブックマーク禁止にできるという*5。禁止して何が嬉しいのだろうか。無断リンク禁止のような話なのか。好意的に解釈すれば、「リテラシーの低いユーザが途中ページをブックマークして、ブックマークから開いたときにエラー画面になってしまうことを防ぎたい」ということなのかもしれない。そんなのは、一度失敗して理解すればよいことで、余計なお世話だ。「トップページをブックマークさせたい」というのであれば、Microsoftの「AddFavorite」の方がましな設計だろう。

これはWAPの仕様のようだが、「vnd.up.bookmark」で検索してみるといくつか解説が見つかるものの、あまり広くは知られていないようだった。

実際、私も過去に「auお客様センター」に電話した際*6に、「アドレスはお気に入り登録で確認できる」という説明を受けていたので、それで確認になると思い込まされていた。

「お客様センター」がそのような説明をしているのであれば、これは「脆弱性」と言える（「URL偽装の脆弱性」と言える）と考え、3月に再度「auお客様センターに」電話で質問してみると、やはり「アドレスはお気に入り登録で確認できる」という説明を受けた。念のため、「Eメールお問い合わせ窓口」に以下の質問を送ったところ、すぐにメールで次の回答が得られた。 

EZwebブラウザで現在見ているサイトのアドレス(URL)を確認する方法を教えて
ください。

フィッシング詐欺の被害に遭わないためには、パスワードや個人情報を入力す
る際に、入力する欄のあるページで、現在見ているサイトのアドレス(URL)を
確認することが必要とされています。
参考： http://www.rcis.aist.go.jp/special/websafety2007/

EZwebブラウザにはアドレスバーがありません。EZwebブラウザで現在見ている
サイトのアドレス(URL)を確認する方法を教えてください。


From: "au by KDDI" <(略)@csmail.kddi.com>
To: (略)@takagi-hiromitsu.jp
Date: Wed, 28 Mar 2007 12:32:28 +0900
Subject: [042007032800092] お問い合わせについて

（挨拶部略）

EZwebでブラウジングしているサイトのURLについては
ブラウジング中に[ブラウザメニュー]から[お気に入り登録]を選ぶことで
表示させることが可能です。

以上のご案内をお役立ていただければ幸いです。

（挨拶部略）

＊＊＊＊＊＊
KDDI au Eメールお問い合わせ窓口
（略）

この時点で、脆弱性として届け出ることにした。3月28日のこと。届出では次のことを書いた。 

4) 再現手順

■背景
------
まず背景を説明する。

EZwebブラウザにはアドレスバーがない。そこで、auの問い合わせ窓口に以下
の質問をした。
（略）

これに対し、以下の回答が得られた。
（略）

「お気に入り登録を選ぶことで表示できる」という回答は、過去に2回、電話
でカスタマーセンターに問い合わせた際にも、同じ回答があったことから、
auは他の者からの同様の問い合わせに対して同じ回答をしていると考えられる。

■脆弱性
--------
EZwebでは、以下のタグを記述することで、「お気に入り登録を選ぶ」操作を
した際に表示されるURLを、現在のページとは別のURLに偽装することができる。

<meta name="vnd.up.bookmark" p:forua="true" content="任意のURL" />

たとえば、IPAの画面を模した偽サイトのページに、
<meta name="vnd.up.bookmark" p:forua="true" content="http://www.ipa.go.jp/" />
のタグが書かれている場合、利用者が、auに案内されたアドレスの確認方法に
従って「お気に入り登録を選ぶ」の操作を行うと、http://www.ipa.go.jp/ と
いうアドレスが表示されるため、IPAの本物サイトを見ていると錯誤すること
になる。

（略）

9) その他

<meta name="vnd.up.bookmark" p:forua="true" content="任意のURL" />
という記述で、「お気に入り登録」の登録するURLを任意のものに変更できる
のは、不具合ではなく、WAP 2.0 の仕様らしい。
参照: http://www.google.co.jp/search?q=vnd.up.bookmark

したがって、この問題は、次の2つのどちらかである。

(a) meta vnd.up.bookmark という機能の仕様上の欠陥（脆弱性）であり、
    修正されるべきもの。

(b) auカスタマーセンターが利用者に回答している、「お気に入り登録を選ぶ
    ことで表示できる」という案内が誤りであり、このような回答を中止する
    とともに、この方法では確認にならない旨を周知するべきもの。

現実的には (b) であると思われるので、KDDIは、これまでの案内に誤りがあっ
たことを告知し、「お気に入り登録を選ぶことで表示」されるものは、現在の
ページを示すとは限らない旨を周知するべきである。

そのような告知と周知をKDDIが行わないのであれば、meta vnd.up.bookmark 
という機能の仕様上の欠陥（脆弱性）であり、修正するべきである。

いずれの処置も行われない場合には、JVNがこの事実を周知するべきものと考
える。

これについて、6月6日の日記「Upcoming Advisories」で、

状況: 調整機関は4月5日に製品開発者に通知したとのこと。製品開発者は誤った説明を5月上旬に中止したとの話を、届出機関から5月21日に連絡を受けたが、中止したというのは事実でないことを6月1日に確認した。

評価: 修正による対応は現実的でないため、事実の周知が対応策となる。（誤った説明を中止し、過去の説明を撤回し、正しい情報を周知すること。）周知するだけの作業の実現に60日以上もかかるというのは、組織の脆弱性対応体制に不備があるのではないか。

と書いていたのはどういうことかというと、「誤った説明を5月上旬に中止した」というのは、5月21日に届出機関からの連絡で、KDDIは「auお客様センター」で同様の問い合わせに対して、ゴールデンウィーク明けからは「確認方法はございません」という回答をするように案内方法を変更したと、経過報告の説明を受けたことを指す。そして、6月1日に再び「auお客様センター」に同じ質問をしてみたところ、対応に変化はなかった。

6月1日には以下の事実を届出機関に伝えた。

本日、「auお客さまサポート」（関東地区）に電話で再び問い合わせました。

一回目（男性）

「フィッシング詐欺でないことを見分けるために現在見ているページのアドレスを確認したいが、パソコンのブラウザにならばアドレス欄があるが、EZwebにはアドレス欄がない。どうやったら、現在見ているページのアドレスを確認できるか？」という質問に対し、コールセンターのオペレータ（男性）は、「『お気に入り』に登録する操作で現在見ているページのURLを確認できる」と即答した。

二回目（女性）

「フィッシング詐欺でないことを見分けるために現在見ているページのアドレスを確認したいが、パソコンのブラウザにならばアドレス欄があるが、EZwebにはアドレス欄がない。どうやったら、現在見ているページのアドレスを確認できるか？」という質問に対し、コールセンターのオペレータ（女性）は、答えることができなかったため、「しばらくお待ちください」として、数分待たされた。

戻ってきたオペレータからの回答は、「『お気に入り』に登録する操作で確認できる」というものだった。

そこで、オペレータに次のように尋ねた。「このような質問にはこのように回答することになっているのですか？」「その回答は、あなたのこれまでの経験、記憶に基づくものですか、それとも、今「お待ちください」と言って、何かを調べてきた上での回答ですか？」

それに対するオペレータの回答は、「今、確認してきた回答です。」だった。

> 確認方法はございません。
> と案内方法を変更。

という措置は実施されていないようです。

その後どうなったかは確認していない。11月22日になって、前述のFAQが掲載されたという連絡が届出機関からあった。

さっさと5月の時点で公表すればいいものを、どうしてたったこれだけのことがすぐにできないのか？ 顧客の安全よりも優先させているのは何なのか？

■ 落穂拾い ―― PKI屋は馬鹿の巣窟か

6月6日の日記に書いていた「日記予定」で、まだ書いてなかったものがあったので、いくつか、簡単に書いておく。

JPNICによると「自己署名の検証」というものが可能らしい

JPNICが「JPNIC認証局」なるものを運営しているが、「JPNICプライマリルート認証局」なる認証局のルート証明書を配布しているようで、どうやって安全に配布しているのだろうかと、「JPNICプライマリルート認証局証明書の入手と確認の手順」というPDFファイルを読んでみると、こんな記述があった。

11.”証明のパス”タブを選択すると、証明のパスが最上位に記載されます。

「この証明書は問題ありません。」というメッセージが確認できれば（b. 自己署名の検証）ができていることになります。

「自己署名の検証」などというものができるとは初耳だ。もちろん、これは誤った説明である。

以上。

PKI製品の配布でPKI技術の存在意義を否定している日立製作所

自治体の電子申請システムなどで使われている「EUR Form Client」というソフトウェアがある。なんでも、ISO 15408 の認証を得たそうで、

EUR Form Clientは、情報システムや製品がセキュリティの観点から正しく設計・実装されているかを評価する、国際規格ISO15408の認証を2006年12月に取得いたしました。

EUR Version5: EUR Form Client, 日立製作所

と説明されている。「EUR Form Client - Signature Option」という機能があり、これはPKI製品である。

それなのに、このソフトのダウンロードページにはこんな記述があるのだ（図1）。

図1: EUR Form Client ダウンロードのページに書かれている説明

［詳細］タブを選択し［拇印］をクリックします。表示された文字が、次のどれかであることを確認してください。なお、表示された文字は、拇印を表示するソフトウェアの種類またはバージョンによって、大文字、小文字の相違、スペースの付加など、表示方法が異なることがあります。

・bf 68 08 f2 66 e9 cd 6b 13 3b 43 06 a8 a2 86 9c da 3b eb ab
・ad c1 42 f0 ec a8 95 9c ee eb f3 26 81 9b 36 89 a7 4b dc 40

確認後、［OK］ボタンを押下し、ActiveXのインストールを実施してください。（略）

EUR Form Client ダウンロード, 日立製作所

これはひどい。

Internet ExplorerでActiveXインストール時に出る「このソフトウェアをインストールしますか？」の警告ダイアログで、発行元が表示されている（上の図で「Hitachi, Ltd.」と表示されている）ときは、既に、ダウンロードしたファイルのコード署名の署名検証が正常に完了していることを意味しているのであり、ユーザはこの「発行元」の部分さえ確認すればよい。

それなのに、フィンガープリントを確認せよというのだ。PKI製品の配布でPKI技術の存在意義を否定してどうする？

しかも、フィンガープリントの確認手順で、http:// ページ上に記載した文字列と見比べろというのだから、そもそも確認にならない誤った方法を説明している。教育上有害だ。

ISO 15408 認証を取得するような製品でさえこの体たらくだ。嘆かわしい。

「フィンガープリント症候群」とでも呼ぼうか。2002年に総務省が撒き散らした病原菌が、これほどまでにプロ達の思考を蝕んでいる。

以上。

*1 「IPA#XXXXXXXX」は、届出が受理された時点で割り振られる受付番号で、届出者に通知されている。

*2 もうひとつの IPA#33593387 の方は既に、「JVN#33593387: KDDI 製ダウンロード CGI サンプルプログラムにおけるディレクトリトラバーサルの脆弱性」として公表されている。

*3 公表日は不明だが、IPAからの通知は11月22日だったことから、せいぜいその数週間前以内のことと思われる。

*4 ちなみに、スラッシュドットの7月11日のコメントにこれと同じ話題が書かれているが、これは私が書いたものではない。脆弱性届出窓口に届け出た以上、基本的に口外することはない。誰が書いたかわからないが、そもそもこれは元から存在する仕様通りの機能なので、知っている人には当たり前のことだったのだと思われる。

*5 それまで、ブックマークできないページがあることは知っていたが、てっきり、WMLで複数画面を1ファイルにしたときに途中ページをブックマークできないとか、そういうことかと想像していたが、そうではなく、こんなアホな機能があったわけだ。

*6 6月24日の日記で書いた、検索結果にURLが表示されない件について、昨年12月に問い合わせた際。

本日のリンク元 TrackBacks(100)

2007年12月09日

■ IETFに行ってきた

先週はIETF 70に行ってきた。本業の件でプロジェクトメンバー達と。IETFに参加したのは今回が初めて。初日のレセプションではたくさんの日本人を見かけた。面識のない方々がほとんどだった。自分達が参加したHTTPの分野とTLSの分野では日本人はほとんどみかけなかった。ネットワーク系の人々が大半なのだろうか。

本業のことはここにはあまり書かないポリシーだが、少し書くと、行ってみて感じたことは、コミュニティの分断。

phishingの問題は日本の状況とは比較にならないほど英語圏では深刻なのだから、もっと皆、連携するなりして多方面から解決しようとしているのではないかと推測していたが、どうもそんな感じがしない。10月にAPWGに行ったときに感じたのは、APWGの人たちは技術による解決にはあまり関心がないようで、犯人達を分析することや被害者の行動を分析することに注視している様子だった。まあそれはそうかもしれん。我々のプロトコルとて全てのケースを解決するものではないわけで、それで取り残されるような人々も救うことがAPWG的関心事だろう。

一方、IETFではどうか。security areaの directorである Sam Hartmanが、draft-hartman-webauth-phishing を去年から書いているのをmailing listで見ていたので、IETFでも phishing解決をする機運があるのだろうと思っていたが、行ってみるとそれほどでもない感じだった。この draftは基本的に Sam Hartmanが一人でやっているという感じがした。HTTP関係者の間では、Webの認証方式がここ何年も進歩していないから何かしなきゃという機運はあるものの、それは、Digest認証が不完全なまま放置されている件をどうにかするかしないかとか、Webアプリケーションの認証がいい加減なのをどうにかするかしないかとか、そんなところが話題に挙がるものの、phisihingについてはUIの問題でプロトコル屋の範疇ではないという認識も少なくない様子だった。（ちなみに、Webアプリケーションの問題については、IETFでは扱いきれない話題でここで扱う話ではないという声も出ていた。それはそうであろう。議論のたたき台も、cookieの使い方のガイドラインといった、Webアプリケーションセキュリティの話としてはレベルの低い話しか出ていない。）

今回の流れで、phising防止の為という理由付けが各自の提案するプロトコルの錦の御旗になることから、各々が各々の持ちネタこそがphishing対策になると主張し始めた。たとえば、TLS WGの chairである Eric Rescorlaは、phishing対策には、TLS-PSK (RFC 4279) とか TLS-SRP (RFC 5054) でいいじゃないか（HTTPレイヤでやる意味がねえ）とか言う。最近では、TLS-EAP などという draftも出ている。それはそれで用途があるだろうけども、Webアプリケーションじゃ使えないよねというのが我々の考え。HTTPの人々とTLSの人々の間にも分断があるようにも感じた。さらには、Libertyの人が SAMLこそがphishingを解決するのだと言い出すし、SASLで解決するのが美しいなどという話も……。

我々としては論点は膨大にあるので、ちゃんと全部論文で書かないと伝え切れんなという認識を持って帰ることに。

その他、phishingに取り組んでいるコミュニティには、TIPPIとW3CのWeb security context WGがあるのを把握しているが、これらとIETFともあまり関係がない様子だった。

ちなみに、別件で大岩くんが活躍した。httpbis WGでは、HTTP/1.1のRFC 2616を改訂する議論が始まっていて、RFC 2616の曖昧なところや不都合なところを潰していこうという話なのだが、これはまさに、HTTP Request Smugglingの問題をRFCの改訂で解決できる機会だぞということで、大岩くんが意見を出していた。ここでもコミュニティの分断を感じる。脆弱性発見コミュニティの人たちはIETFには来ていないわけで。

月曜の夜には itojun氏を偲ぶ会が開かれていた。私はitojun氏とは面識がなく彼のWebサイトを見た記憶があるという程度の認識だったが、実は近々彼とお会いする計画があり、どんな方なのかと彼のWeb日記を読んでいた。その直後に訃報を知ったものだから、大きなショックを受けた。偲ぶ会にはたくさんの人たちが集まり部屋に入りきれないほどだった。村井先生から彼のIETFへの貢献の歴史が語られ、大事な人を失ってしまったのだなということがよくわかった。

Vancouverは、初日は雪だったが翌日からは雨になりさほど寒くはなかった。会場の向かいの角にBlue Tree Cafeという店があり、店頭のメニューに「Matcha Latte」とあったので、へー抹茶ラテも今や世界に通用するのかと思いきや、日本人経営の店だった。店員さんがいつも美人の日本人の方だったのが印象的。スモークサーモンのサンドイッチがうまかった。「Blue Tree」とは青木建設のことだとか。

右の写真は、帰りのAir Canadaの飛行機で、前のシートに付いているタッチパネル式のマルチメディア端末を適当にタップしていたら、contextメニューが出て、save dialogが出てしまった様子。なんとなくnew folderボタンを押したら、ルートディレクトリに新しいフォルダができてしまった。ディレクトリを辿ると、/etc/passwd を上書きできるような感じだったが、やめておいた。その上の写真は、泊まったホテルから見下ろした会場方面。

本日のリンク元 TrackBacks(5)

2007年12月12日

■ 第六種オレオレ証明書が今後増加するおそれ

リンク元を辿ったところ、東京証券取引所の「適時開示情報閲覧サービス」のサイトと、民主党のご意見送信フォームの送信先サーバ*1でオレオレ証明書が使われているという話を立て続けに見かけた。

これらはどちらも、中間認証局から取得したサーバ証明書なのに、中間認証局の証明書をサーバに設置していないという、第六種オレオレ証明書の状態になっているようだ。

この場合、Internet Explorerアクセスするとオレオレ警告が出ないため、サーバ管理者が気づいていないのだと思われる。

IEで警告が出ないのは、IEには独自の機能が搭載されているからで、サーバ証明書に記載の「Authority Information Access」拡張フィールドにあるURLから、検証に必要な中間認証局の証明書を、別途自動でダウンロードして取得する機能があるためだ。図1は、民主党のサイトで提示されるサーバ証明書の、Authority Information Access拡張フィールドの値を表示させた様子である。

図1: 中間認証局証明書のダウンロード先を記したサーバ証明書の例

http://SVR1024Secure-aia.verisign.com/SVR1024Secure2007-aia.cer が中間認証局の証明書の置かれているURLである。この証明書はルート認証局から署名されているので（はずなので）、（検証すれば）安全にダウンロードすることができる。IEは、これをダウンロードすると、「中間証明機関」という証明書ストア（図2）に格納し、その後もそれを（cacheとして）使用するようになっている。

図2: IEにおける中間認証局証明書の「cache」

通常、中間認証局から発行されたサーバ証明書をサーバにインストールする場合、認証局から送られてくる中間認証局証明書も合わせてインストールするのが常識なのだが、IEではそれをサボっても警告が出ない場合があるのは、この機能が働くためだ。この場合、SSLの接続は正常に確立する。

何年か前に、microsoft.com 上に存在する SSL対応のWebサーバで、オレオレ警告が出ることが度々話題になったのは、これが原因で、「IEでは警告が出ないが Firefoxでは警告が出る」という騒ぎだった。

ところが（15日訂正）その後、最近になってのことだろうか、 Firefoxでもこの機能がサポートされたようだ。上記の東京証券取引所と民主党のサイトを Firefox2.0.0.11 でアクセスしても、オレオレ警告は出ずに正常にSSL接続が確立する。

Firefoxがどのバージョンからこの機能をサポートしたかは確認していない。

しかし、Safariや Operaなどの他のブラウザはこの機能をサポートしていないので、オレオレ警告が出る。これは、それらのブラウザでは SSLの接続が正常に確立しないことを意味する。つまり、通信路上の盗聴者が偽のサーバ証明書を提示している状況と区別できないので、安全な通信ができない。

Safariや Operaでのアクセスをお断りしているといった特別な事情があるサイトを除いて、このようなサイト運用は誤りであろう。

IEだけでなく Firefoxでも正常に接続できるようになったことから、今後この設定ミスに気づかないサイトが増えるおそれがある。

■ 訂正（15日）

上で「Firefoxでもこの機能がサポートされたようだ」と書いたのは早とちりだった。はてなブックマークコメントに「Forefoxでも警告は出た」というたくさんの指摘を頂いたため、手元のFirefoxを再起動して試したところ警告が出るようになった。考えられる原因を想定してひとつひとつ確認していったところ原因が判明した。確認した現象は以下の通り。

12日の日記を書く直前にこれら2つのサイトを訪れていた。東京証券取引所（異常な設定）は専修大学（正常な設定）と同じ中間認証局「VeriSign Class 3 Secure Server CA」から発行されたサーバ証明書を使っており、民主党（異常な設定）は西日本シティ銀行（正常な設定）と同じ中間認証局「VeriSign Class 3 Secure Server 1024-bit CA」から発行されたサーバ証明書を使っている。

どうやら、Firefoxは、正常な設定のサイトを訪れたときに当該サイトから取得した中間認証局証明書を（再起動までの間）メモリ上に残すようになっており、異常な設定のサイトを訪れたときに、そのメモリ上の中間認証局証明書を使って認証パスを検証してしまうようだ。（Firefox 3 beta 1でも同じ現象が起きた。）

これは、トラックバックでご指摘頂いたように、MozillaのBugID:399045として報告されているバグのようだ。

なお、これは脆弱性に分類されるバグではない。警告が出ないのは、証明書の認証パスの検証をサボったからではなく、（たまたま）検証できたからなのであり、したがって、SSL暗号化通信は正常に機能している。

つまり、東京証券取引所や民主党のサイトをFirefoxで安全に利用したい人は、それぞれ利用前に専修大学か西日本シティ銀行のサイトを訪れてからにすれば、SSL暗号化された通信で利用できる。

もちろん、東京証券取引所や民主党のサイトがそのような利用手順を利用者に強要するのは誤りであり、サーバの設定を直すべきである。現時点でも直っていないようだが、直さないのなら、少なくとも「Internet ExplorerでしかSSL暗号化通信をご利用できません」という断り書きが必要だろう。

*1 ちなみに、民主党のご意見送信フォームは別の点でもセキュリティ上の不備がある。送信先は https:// になっているものの、フォームのHTMLは http:// で配布されている。「このフォームは、SSL(Secure Sockets Layer) 技術で暗号化しています」と書かれているが、文章で書いても無意味だ。通信路上でそのHTMLが改竄されれば、入力データは暗号化せずに送信されてしまう（関連：SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも、安全なWebサイト利用の鉄則 - よくある質問と答え）。もっとも、それを理解しているユーザは、フォームのページでアドレスバーを編集して自力で https:// でアクセスしなおせば安全に使えるのではあるが。

本日のリンク元 TrackBacks(100)

2007年12月15日

■ 日立の銀行用ソフトウェアキーボードが利用者の危険を増大させている

Internet Explorerの独自機能である「スクリプトによる貼り付け処理」が危険なものであることは、いろいろな場面で何度も言い続けてきた。

この問題は、Internet Explorer 7 と Windows Vista においてようやくそれなりに一応の解決がなされた。2006年5月13日の日記に書いていたように、「スクリプトによる貼り付け処理の許可」のデフォルト設定は、「ダイアログを表示する」に変更されているのである。

当時、「こんな解決方法じゃ、設定を元に戻させる糞サイトが登場して元の木阿弥にされてしまう」との心配が頭をよぎったが、その懸念が早くも現実のものとなっていた。それも、よりによって、銀行の手によってである。

図1は、西日本シティ銀行による「ソフトウェアキーボード」の解説である。（「セキュリティキーボード」と呼ぶ銀行もある。）

図1: 西日本シティ銀行「ソフトウェアキーボードとは」

ソフトウェアキーボードのボタン押下時にブラウザの設定により下記のダイアログが表示される場合があります。ダイアログの表示は下記の設定により回避が可能です。

【回避方法】

「ツール」→「インターネットオプション」→「セキュリティ」→「セキュリティのカスタマイズ」→「レベルのカスタマイズ」→「スクリプトの貼り付け処理の許可」を有効に設定することにより表示を抑止できます。

キーロガー対策のために「ソフトウェアキーボード」を使えと言いながら、クリップボードの盗聴を万人に許可する設定にせよ……というのである。

キーロガー対策として「ソフトウェアキーボード」を導入する銀行は多いが、これが役に立たないものであること（キーロガーを仕掛けられるという状況の前提では、他のもっと効果的で簡単なマルウェアを仕掛けることも可能である）は、Web技術者なら誰でも知っているだろう（関連記事）。一部の銀行はそれを承知でこれを導入しているようで、これは「対策してます」というポーズなんだという話がある。ある銀行の担当者は講演で、「これによりセキュリティ意識の必要性に気付いていただけるというメリットがある」という趣旨のことを話しており、なるほどそれ自体を非難することはできないだろう*1。

だが、「スクリプトによる貼り付け処理」のセキュリティ設定をデフォルトより危険な設定に変更させてしまうのでは、こんなものは有害なだけである。本末転倒も甚だしい。

検索して調べてみると、他にも同様の指示を出している銀行が何か所も見つかる。

図2: 泉州銀行「IE7.0とWindows Vistaの制限事項」

ソフトウェアキーボードのボタン押下時にクリップボードへのアクセス許可ダイアログが表示されます。（略）「スクリプトの貼り付け処理の許可」を有効に設定してご利用ください。

図3: 肥後銀行「Internet Explorer 7.0 ご利用時の注意」

＜事象２＞ ソフトウェアキーボードを押した際に、「クリップボードへのアクセス許可」のダイアログが表示される。

＜対　応＞ （略）以下のようにブラウザの設定を変更すると、次回よりダイアログが表示されません。

・「F10キー押下」-「ツール」-「インターネットオプション」-「セキュリティ」-「レベルのカスタマイズ」-「スクリプトの貼り付け処理の許可」を有効に設定

図4: 北洋銀行「推奨ＯＳ／ブラウザ」

＜Internet Explorer 7.0をご利用の場合＞

・ ソフトウェアキーボードのボタン押下時に、「このWebページがクリップボードへアクセスするのを許可しますか？」というメッセージが表示される場合があります。この場合、「アクセスを許可する」をその都度選択してご利用いただくか、ブラウザの設定を以下のとおり変更してご利用ください。

＜ブラウザの設定＞

「ツール」→「インターネットオプション」→「セキュリティ」→「レベルのカスタマイズ」→「スクリプトの貼り付け処理の許可」を有効に設定してください。

これらの銀行がどんなシステムを使っているのか、ログイン画面に行って見ると、それぞれ次の特徴があり、共通点があった。

  • 西日本シティ銀行, bb1.finemax.net, アドレスバー隠蔽, 「右クリックは禁止です。」
  • 泉州銀行, www2.ib-center.gr.jp, 「右クリックは禁止です。」
  • 肥後銀行, www2.ib-center.gr.jp, アドレスバー隠蔽, 「右クリックは禁止です。」
  • 北洋銀行, bb1.finemax.net, 「右クリックは禁止です。」

「finemax.net」も「ib-center.gr.jp」も日立製作所 金融システム事業部が提供しているサービスらしい。*2

そもそも、技術的に言って、「ソフトウェアキーボード」機能を実現するために「スクリプトによる貼り付け処理」は必要なのか？

「ソフトウェアキーボード」は（役に立たないのに）たくさんの銀行が導入しているので、各行で、「スクリプトによる貼り付け処理」を「ダイアログを表示する」に設定（IE 7およびWindows Vistaのデフォルト設定）しているとどうなるか調べてみた。（Googleで「銀行」で検索したときの出現順。）

  • イーバンク銀行, ダイアログは出ない
  • みずほ銀行, ダイアログは出ない
  • 三菱東京UFJ銀行, ソフトウェアキーボードを採用していない
  • 三井住友銀行, ダイアログは出ない
  • 新生銀行, ダイアログは出ない
  • りそな銀行(anser.or.jp), ダイアログは出ない
  • ジャパンネット銀行, ソフトウェアキーボードを採用していない
  • 東京スター銀行, ソフトウェアキーボードを採用していない
  • ソニー銀行, ダイアログは出ない
  • セブン銀行, ダイアログは出ない
  • ゆうちょ銀行, ダイアログは出ない
  • スルガ銀行, ダイアログは出ない
  • 横浜銀行 (finemax.net), ダイアログが出る
  • 関西アーバン銀行 (anser.or.jp), ダイアログは出ない
  • 東京都民銀行 (anser.or.jp), ダイアログは出ない
  • 京都銀行 (anser.or.jp), ダイアログは出ない
  • 住友信託銀行, ソフトウェアキーボードを採用していない
  • 中央三井信託銀行, ダイアログは出ない
  • 千葉銀行 (finemax.net), ダイアログが出る

つまり、「スクリプトによる貼り付け処理」を使っているのは、日立のシステムだけだ。

技術的に直せるものなのに、どうして直さないのか？ 直しもしないで、ユーザのセキュリティ設定を劣化させてお茶を濁そうとしているのは、誰の責任なのか？

設定変更の指示を書いているのは、銀行が独自に書いたものだろうか？ いや、そうではなさそうだ。というのも、上の図1〜4に挙げた各銀行の説明をよく読むと特徴的な文がある。

「スクリプトの貼り付け処理の許可」を有効に設定してください。

実はInternet Explorerに「スクリプトの貼り付け処理の許可」などという設定項目は存在しない。正しくは「スクリプトによる貼り付け」だ。

つまり、どこかの誰かが各銀行に例文を配布したために、それを真に受けてコピーしてしまった銀行があったということだ。

汚染源はどこなのか？ 普通に憶測すれば「FINEMAX」の運営主体である日立製作所だろう。

いいかげんこんなことが続くようなら、安全なインターネットバンキングサイトの作り方にそろそろこれを加えないといけないのではなかろうか。

「例えば、FINEMAXを避ける。」

また、ユーザの立場での注意点はこうだと言える。例えば、「右クリックは禁止です」などと不遜なエラーを出すシステムを採用している銀行、それらを避ける。

関連：

■ オレオレ警告を無視せよと指示する金融機関が他にも

「オレオレ証明書で問題ありませんと言う銀行」について11月17日の日記で2つの銀行を挙げたが、他にもやっているところがあるとの指摘が見つかった。

  • オレオレ証明書宣言 -インターネットバンキングの迷路-, なべのさかやき, 2006年8月21日

    私が既に通帳を持っている銀行で、インターネットバンキングのＱ＆Ａを読んでいたら、こんな一文が載っていました。

    （略）

    たぶんこのサイトは、かつて資料請求フォームだけオレオレ証明書で運用されていた時代があり、不審に感じた利用者の問い合わせが多いためにＱ＆Ａに「オレオレ証明書宣言」を追加したのでしょう。その後、オレオレ詐欺状態が解消したのにＱ＆Ａがメンテナンスされていなかったものと思われます。

検索してみたところ、現在もそれが掲載されていた。

図5: ろうきん インターネットバンキング「Q & A お申し込み」

Ｑ6 ホームページから資料請求を行おうとすると、「このサイトのセキュリティ証明書には問題があります。（Internet Explorerの場合）」（Netscape Navigatorの場合：「Netscape は、証明書に署名した発行人を認識できません。」）と表示されますが、どうしたらいいのですか？ これは、ＳＳＬに使う電子証明書の発行元が全国労働金庫協会であることによるものです。

したがって、Internet Explorerでは「続行する」、Netscape Navigatorでは「次へ」「次へ」「次へ」「次へ」「完了」「続ける」として電子証明書をインストールしてください。このお手続きは、通信経路を暗号化してお客様の個人情報を保護するために必要ですのでご了承願います。

その「資料請求」のページは、現在ではたしかに正常なサーバ証明書で運営されているようだ。しかし、サーバ側が正常になったからといって、この誤った説明を放置していてよいことにはならない。

なぜなら、ユーザ側でこの警告が出ることはいつでも起き得るからである。つまり、まさに盗聴されているときにその警告が出るのであり、それを見分けるための警告なのだから、「続行する」だの、「次へ」「次へ」「次へ」「次へ」「完了」「続ける」だのと出鱈目な嘘を教えてはいけない。

実際に、この誤った解説を真に受けて操作した利用者が、外出先などでインターネットバンキングを利用したとき、警告を無視して操作して被害が出たら、その責任をとるつもりなのか？

なお、11月17日の日記で挙げた2つの銀行は、現在もなお虚偽の説明を訂正していないばかりか、削除すらしていない。

関連：

*1 もし、「ソフトウェアキーボードでスパイウェア対策は万全です」などと宣伝している銀行があれば、それは事実に反するので非難されてしかるべき（2005年10月17日の日記、2006年10月21日の日記参照）だが、たとえば西日本シティ銀行の説明では、「キーボードからの入力情報を盗み取るタイプのスパイウェアよりパスワードなどの入力情報を守ることができます」とか、「ソフトウェアキーボードのご利用により、安全が保証されるものではありません」などと、それなりに慎重な説明がなされている。

*2 「finemax」で検索してみると悪い評判が見られる。

本日のリンク元 TrackBacks(6)

2007年12月16日

■ 一太郎Zero-day攻撃発覚経緯の謎 ―― 非国民は誰？

目次

  • 一太郎zero-day攻撃発覚経緯の謎
  • Symantecは脆弱性分析のプロではない
  • 日本人Symantec社員は非日本国民か
  • 非国民は誰？
  • ジャストシステム社も経済産業省告示を無視？
  • 現行の届出制度はzero-day攻撃に対応していない

一太郎zero-day攻撃発覚経緯の謎

先週こんな報道があった。

またか。

「また一太郎か」という意味ではなく、「また Symantec か」という意味でだ。

一太郎関連製品のバッファオーバーフロー系の脆弱性はこれまでに8回見つかっており、うち3回は、攻撃に悪用される前にIPAとJPCERT/CCを通じて事前に修正されたもの（JVN#90815371, JVN#47272891, JVN#29211062）で、残りの5回はいずれもzero-day攻撃が発生した中で発覚している。その際の報道を並べてみると次のようになる。（24日追記：ITmediaとマイコミジャーナルを追加した。）

このように、第一報はすべて「シマンテックが」「Symantecが」だ。なぜこうなるのだろう？ 偶然にしては不自然ではないか？

これはこういうことが起きているのではないだろうか。

まず、Symantecの当該ウイルスデータベースを見てみると、いずれも「Wild Level: Low, Number of Infections: 0 - 49, Number of Sites: 0 - 2」となっている（例えば、最も古いTrojan.Tarodropを参照）ことから、おそらく、どれも 1件の報告（ウイルス検体の提供）があっただけなのだろう。

次に、ウイルス対策ソフト会社は数社あるにも関わらず、すべてSymantecに検体が提供されたということは、おそらく、検体の提供元は同じ人物ないし、同じ組織ではないだろうか。

つまり、典型的な targeted attackが昨年から継続して仕掛けられており、しかもそのターゲットが同じ組織に絞られているのではないか。

ここで思い出すのが、2006年5月の「第10回 コンピュータ犯罪に関する白浜シンポジウム」で聴講した警察庁担当者の講演内容だ。これは次の通り報道されている。

  • 「警察を標的にしたスピア型フィッシング・メールが増加」---警察庁 坂明氏, 日経IT Pro, 2006年5月29日

    「警察や防衛庁を標的とする，特定の対象を狙った偽装メール，いわゆるスピア型フィッシング・メールが増加，かつきわめて精巧になってきている」--- 警察庁 生活安全局 情報技術犯罪 対策課（サイバー犯罪対策課）課長 坂明氏は5月26日から28日にかけて開催された「第10回 コンピュータ犯罪に関する白浜シンポジウム」の講演で，警察庁を標的とする攻撃が増加していることを明らかにした。

じつは私も勤務先のメールアドレスは go.jp で終わるものなので、それらしきメールを受信したことがある。2005年6月のことで、これは [memo:8513] で報告した記録がある。このときは、少し後に非政府の個人アドレスにも届いているという報告もあった。その後何度かは同様のメールを見かけたものの、2006年の白浜シンポジウムで上記の講演を聴講した時点では、もはや見かけなくなっていた。一太郎の添付ファイルの付いたメールも見たことがない。zero-day攻撃は、かなり対象を絞って、密かに行われているのではないだろうか。

一太郎の未知の脆弱性を突いたzero-day攻撃は、ごく限られた組織に対してだけ行われているのではないかと憶測する。それが、警察庁なのか、防衛省なのか、他の政府組織なのか、もしかすると民間組織なのか、その情報は持っていないの知らないが、狙われやすいのは重要な任務を担う政府の担当者のアドレスだと考えるのが普通だろう。

標的にされているその組織が、あるいはその組織の情報システム管理者が、毎度、ウイルス検体をシマンテック社に提供しているとすればどうだろうか。報告先としてシマンテックを選択している理由も単に、その組織の情報システム御用達のウイルス対策ソフトがシマンテック製だとすると、どうだろう。

というと、こういう疑問が出てくるかもしれない。つまり、「ウイルスメールを見つけた情報システム管理者が契約先のウイルス対策ソフト会社に報告する――それのどこがいけないのか？」と。

それはやっぱり駄目だろう。少なくとも政府機関がそんなことでは駄目ではないか。

Symantecは脆弱性分析のプロではない

まず第一に、結果として皆が不利益を被っているという実害が生じている。それは何かというと、10月30日の日記「一太郎plug-inをIEとFirefoxで無効に 〜 ジャストシステムは本当の脅威を教えてくれない」の件である。

10月30日の日記に書いたように、一太郎の脆弱性は、（おそらく過去の8件の何れも）Webブラウザ用一太郎plug-inの脆弱性でもあり、悪意あるWebサイトを訪れただけで攻撃が成功するという、危険度の高い脆弱性であるのだが、ジャストシステムはそのように発表せず、「出所の不明な一太郎文書ファイルを開かないようご注意ください」などと、あたかも、ローカルファイルを開かなければ問題ないかのような誤った情報を流していた。

これは、ジャストシステム社に脆弱性分析能力が欠けている（あるいは、脆弱性情報を正しく利用者に伝えることについての社会的責任の認識が欠けている）ことも原因の一つであるが、一次情報源である Symantecがそう言っていることも原因になっているのだろう。一太郎zero-day攻撃のニュースは、次のように、いつも Symantecの blog「Security Response Weblog」が一次情報源になっている。

この中で、利用者向けの注意として「出所の不明な一太郎文書ファイルを開かないようご注意」ということが書かれている。

Since this vulnerability has yet to be patched, you should be extra careful when using Ichitaro and refrain from opening Ichitaro files received from untrusted sources. Also remember to keep your security software up-to-date and follow safe computing practices.

New fiscal year in Japan, new zero-day in Justsystem's Ichitaro, Joji Hamada, Symantec, 2007年4月7日

We are not currently aware of any patches available to fix this issue, so until JustSystems releases a patch, we would advise all Ichitaro users to treat unsolicited .jtd files with extreme caution.

Zero-day Vulnerabilities: Following the Trailblazers, Hon Lau, Symantec, 2007年12月13日

先週発覚した最新の件でも、「we would advise all Ichitaro users to treat unsolicited .jtd files with extreme caution」などと言っており、これは、日本での報道内容に影を落としている。

このように、報道では「信頼できないファイルは開かないといった心構えで回避」できることになってしまっているのは、Symantecの一次情報がそう書いているからだろう。日経BPの勝村記者なんぞはこれを自分の考えとして書いてしまっている。一方、INTERNET Watchの記事では「Symantecでは……呼びかけている」と、あくまでもSymantecがそう言っているということを伝えるに止めているが、読者は、それで回避できる程度の危険度の低い脆弱性だと読むだろう。（ちなみに、ITmediaの記事は回避方法について触れていない。）

ジャストシステム社は今回、このことについて、次のように発表した。

現象とその対処方法

2007年12月13日、当社製品の多くが共用しているプログラムライブラリファイルに脆弱性が確認されました。この脆弱性が悪用されると任意のコードが実行され、パソコンが不正に操作される危険性があります。

悪意の攻撃者は不正に改ざんしたファイルを作成するなどし、そのようなファイルを電子メールの添付ファイルにして送りつけたり、 Webサイトに置くことで攻撃を仕掛けます。お客様がそのようなファイルを開いたり、リンクをクリックすることで、意図せず不正な文書ファイルを読み込み、悪意の攻撃を実行させてしまう恐れがあります。

本モジュールは今回発見された脆弱性を修正するもので、これを導入することにより原因となる箇所において不正な動作は発生しなくなります。

セキュリティ更新モジュール導入にかかわらず、身に覚えのない電子メールに添付されている文書ファイル、並びに、信頼性が保証されていないWebサイトなどにある、出所の不明な文書ファイルを開かないよう、ご注意ください。

ジャストシステム製品の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, 2007年12月14日

いちおう、「リンクをクリックすることで」と書かれている。これの意味するところを見逃さなければ、正しい報道ができるはずなのに、誰もやっていない。

それは、ジャストシステムのこの発表文の出来が悪いことを意味する。「リンクをクリックした後、ダウンロードの確認画面で『開く』を選択すると」という意味だと誤解する読者もいるだろう。伝えるべきは、「悪意あるWebサイトを訪れただけで」ということなのだが、それを書いていない。

「経営判断」でわざとそれを書かないようにしているのかとも思えるところだが、実際のところ、この発表文は10月のときの発表文をコピペしただけだ。

もし、一次情報源である Symantecが「悪意あるWebサイトを訪れただけで」と書いてくれたなら、危険性は正しく周知されただろう。

Symantecにそれができないのは、彼らは脆弱性分析のプロではないからだ。彼らは、個々のマルウェアの挙動を分析するリバースエンジニアリングのプロフェッショナルではあるが、脆弱性の影響範囲を評価するプロではない。彼らの仕事は、ウイルス対策ソフトを売ることであり、脆弱性の危険性を社会に伝えることではない。同じ1つの脆弱性を突く複数のマルウェアが次々と登場すれば、それらひとつひとつがウイルス対策ソフトのパターンファイルに登録され、それは彼らのソフトの対策能力の向上を意味するが、それを脆弱性単位でひと括りにしてはむしろ損になってしまう。また、ウイルスは脆弱性を突かなくても感染し得るものなので、彼らのビジネスにとって脆弱性分析は必要ではない。

Symantecが脆弱性について素人であることは、彼らが「stack overflow」と誤った用語を使っていることからもわかる。スタックがオーバーフローするわけではない。彼らのblog記事からリンクされているSecurityFocusの脆弱性データベースでは「Stack Buffer Overflow Vulnerability」と書かれており、もう少し正確に言うときは「stack-based buffer overflow」と言う。オーバーフローするのはバッファであり、当該バッファがスタック上にあるタイプ（ヒープではなく）という意味である。

The malicious document uses a unicode stack overflow to execute its code on the system, dropping and executing a Trojan horse named Backdoor.Papi.

Justsystem's Ichitaro zero-day used to propogate Trojan, John Canavan, Symantec, 2007年12月13日

The exploit causes a stack overflow in the application (JustSystem Ichitaro JSGCI.DLL Unspecified Stack Buffer Overflow Vulnerability) and then seizes execution control to drop a Backdoor.

Zero-day Vulnerabilities: Following the Trailblazers, Hon Lau, Symantec, 2007年12月13日

あるいは、彼らにとって、日本でしか使われていないソフトウェアの脆弱性は、どうでもよいことなのかもしれない。この脆弱性の影響範囲を知るには、一太郎を入手してインストールするなどして、plug-inの存在に気づく必要があるが、マルウェアがバッファオーバーフロー脆弱性を突いていることは、一太郎を入手しなくても分析できる。一太郎を入手してまでその影響範囲を探ることは、外国企業である彼らにとって関心のないことなのかもしれない。

日本人Symantec社員は非日本国民か

もうひとつの問題は、主に日本国に影響を及ぼす脆弱性でありながら、その影響分析が外国の企業でしか行えない状態になっていることである。

ウイルス検体は、基本的に、ウイルス対策ソフトベンダーの外に提供されることはないだろう。今回のようなケースでは、一太郎の製造元であるジャストシステムに対して、脆弱性を修正するのに必要な情報として検体が提供されているだろうが、ジャストシステムも、それを外部に提供することはないだろう。

そうすると、他の誰も脆弱性の詳細を確認することができず、影響範囲について憶測でしか語ることができなくなってしまう。8月のときの私のように。

日本国は、経済産業省の告示に基づき、脆弱性情報の取り扱い体制を構築している。告示は、「発見者基準」を次のように定めている。

  • ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号

    �検ニ楷霆爐療�用範囲

    本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が不特定多数の者に影響を及ぼし得るものに適用する。

    １．日本国内で利用されているソフトウエア製品
    （ソフトウエア製品において通信プロトコル等の仕様を実装した部分を含む。）

    ２．主に日本国内からのアクセスが想定されているウェブサイトで稼働するウェブアプリケーション

    �后ヂ仂櫃�ソフトウエア製品である場合の脆弱性関連情報取扱基準

    一．発見者が製品開発者ではない、又は、発見者が製品開発者であり発見若しくは取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限らない場合

    対象がソフトウエア製品であり、かつ、発見者が製品開発者ではない、又は、発見者が製品 開発者であり発見若しくは取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限 らない場合における脆弱性関連情報の取扱いの流れを以下に示す。

    （�顱鉾�見者は、脆弱性関連情報を受付機関に届け出る。

    （略）

    １．発見者基準

    （１）発見者（自ら開発等を行ったソフトウエア製品に影響範囲が限られると認められる脆弱性関連情報を発見又は取得した製品開発者を除く。）は、発見又は取得した脆弱性関連情報を経済産業大臣が別に指定する受付機関に届け出ること。ただし、当該製品開発者に対し同じ内容を届け出ることを妨げない。

    （２）発見者は、以下の点を明示した上で脆弱性関連情報を届け出ること。（略）

    （３）違法な方法により脆弱性関連情報を発見又は取得しないこと。

    （４）発見者は、当該脆弱性情報が受付機関及び調整機関から公表されるまでの間、当該脆弱性関連情報を第三者に漏えいしないよう適切に管理すること。ただし、当該脆弱性関連情報 を正当な理由により第三者に開示する場合、あらかじめ受付機関に問い合わせをすること。

    （略）

一太郎の脆弱性は 8件発覚しているわけだが、悪用される前に発見された 3件*1を除く、zero-day攻撃に悪用された 5件の脆弱性について見てみると、そのどれも、脆弱性関連情報取扱基準に則った処理が行われていないようだ。JVNの VN-JPを見ると、悪用される前に発見されて届け出られた 3件のものしか掲載されていない。

つまり、脆弱性の発見者である Symantecは、IPAに脆弱性情報を届けていないと推定される。

もっとも、日本国の経済産業省告示が、米国の会社には及ぶことはないのかもしれない。だが、前述の Symantec Security Response Weblog の著者を見ると、外国人氏名の名前に並んで、「Shunichi Imano」、「Joji Hamada」という日本人ふうの名前がある。

もっとも、この2名が日本国民かはわからないし、日本に居住しているか、勤務先が日本に存在するのかもわからないので、経済産業省告示の及ぶ対象かどうかはわからない。

非国民は誰？

では、zero-day攻撃の標的にされた、ウイルス検体の提供者であるところの、謎の組織はどうだろうか。それが日本の政府機関である可能性は高いし、少なくとも日本に関係する組織であることは疑いの余地がないだろう。

日本の政府組織が、経済産業省告示を無視して、外国企業に情報提供しているのだろうか？ まさかそれはないだろう。せいぜい、単に、日本の政府組織に所属する情報システム管理者が、独断で Symantecに情報を流している可能性の方があり得そうな話だ。

ただ、受信したウイルスを Symantecに提供する行為は、直ちに、告示を無視した背信行為とまでは言えない。なぜなら、「脆弱性を発見したわけではない」という抗弁が可能だからだ。脆弱性の発見者は Symantec社であり、検体の提供者は脆弱性の発見をしていないのだと。

しかしどうだろう？ 2006年8月の初回はそのような考え方も理解できるが、その後、同様に繰り返し起きた 4件についてはどうか。同じ組織ないし人物が提供しているのなら、「新たな未知の脆弱性を突くものかもしれない」と認識しつつ、Symantecに提供したのではなかろうか？

外国企業に情報提供することが悪いことと言っているのではない。少なくとも、告示の基準に従うべきだろう。民間人ならまだしも、公務員なら当然に。

とはいえ、そう責められるものでもないかもしれない。ウイルス検体を Symantecに提供している人物が、単なる IT素人なだけかもしれない。「セキュリティといえばウイルス対策ソフト」という認識の素人であれば、シマンテックやトレンドマイクロに相談すれば話はすべて解決してくれると思っているのではなかろうか。

ジャストシステム社も経済産業省告示を無視？

その意味では、一太郎の製造元であるジャストシステム社も、「セキュリティといえばウイルス対策ソフトのこと」という認識の IT素人である疑いがある。これについては10月30日の日記の「パソコン初心者並みの認識のソフト会社」の節で書いた。シマンテックがウイルスの感染状況を「Risk Level 1: Very Low」と発表したものを、脆弱性の危険性と取り違えて「危険度判定：低」などと発表する素人ぶりだった。

それだけではない。ジャストシステム社も経済産業省告示を無視していると言えるかもしれない。この告示には次の定めもある。

  • ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示第235号

    二．発見者が製品開発者であり、発見又は取得した脆弱性関連情報の影響範囲が自社のソフトウエア製品に限られる場合

    対象がソフトウエア製品であり、かつ、発見者が製品開発者であり、発見又は取得した脆弱 性関連情報の影響範囲が自社のソフトウエア製品に限られる場合における関係者の行動基準を 以下に定める。

    （１）製品開発者は、自ら開発等を行ったソフトウエア製品に影響が限られると認められる脆弱性関連情報を発見又は取得した場合、対策方法を作成し、当該脆弱性関連情報及び対策方法を受付機関及び調整機関に通知すること。

    （２）受付機関及び調整機関は、（１）による通知を受けたときは、当該脆弱性情報及び対策方法をインターネット等を通じて公表すること。ただし、調整機関はそれらを公表すべき日について、当該製品開発者から意見を聴取した上で定めること。

ここで解釈が微妙になるのは、発見者が外国企業であって、国内で初めてその事実を知らされたのが製品開発者である場合に、製品開発者は「発見者」と言えるのかどうかだ。

また、既に他から公表されている情報を元に知った場合に「発見者」と言えるのかどうかという点もある。届出様式には「情報の入手先」の選択肢として「ウェブサイトから入手」も用意されていることから、必ずしも公知の情報を届け出てはならないわけではなさそうだが、公知の同じ案件がたくさんの人によって届け出られるというのも冗長であろうから、基本的には初期段階で知った者が「発見者」であろう。

だが、常識的に考えて、ジャストシステム社は「発見者」に該当するだろう。なぜなら、脆弱性の存在自体は公知になっていても、脆弱性の再現手順（届出様式で必須の記入項目）を知っているのは Symantecとジャストシステムだけだからだ。

そして、その「脆弱性の再現手順」が Symantec社とジャストシステム社の手にしかないが故に、脆弱性の影響範囲を正しく日本国民に伝えることが不可能となり、日本国にとっての公益が損なわれている。

とはいえ、ジャストシステム社は、ウイルスの感染状況と脆弱性の危険度を混同するような IT素人なので、しかたがない。

現行の届出制度はzero-day攻撃に対応していない

そうすると、現状で欠けている問題の根本はこうだろう。

zero-day攻撃の標的にされた組織が、そこに未知の脆弱性があると発見するに至らなかったにしても、検体をウイルス対策ソフト会社に提供するのではなく、国内の適切なところに届け出るような仕組みになっていれば、それでよいはずだ。未知の脆弱性が突かれているかは、届出を受けた機関が分析すればよい。

ウイルスの届出といえば、IPAが既にやっている。

これは1990年から行われているもので、平成7年通商産業省告示第429号「コンピュータウイルス対策基準」に基づくものである。

しかし、その内容は、基本的に、ウイルス感染事故発生時の各自の対策のあり方を示すものであり、「事後対応」として、「ウイルス被害の拡大及び再発を防止するため、必要な情報を経済産業大臣が別に指定する者に届け出ること」という記述はあるものの、これは、zero-day攻撃時の脆弱性分析を目的としたものではない。

実際、この「届け出ること」という定めは形骸化しており、ウイルスを見かけても届けない人、ネットワーク管理者、企業は少なくないだろう。それは、昔のウイルスは感染することで手にするものが大半だったのに対し、2000年以降は、メールで届くワームのように、感染する前に手元に届くようになったため、「被害に遭ってもいないないのに、受信しただけで一々届け出るなんて、妥当性がない」と考えられるようになったためだと思う。

この制度が役に立っているのは、定期的に発表される届出件数の数字だけで、ウイルスが増えたか減ったかといった実態把握の目的にしかなっていない。（感染機能を持たない単発型のトロイが増えている最近では、この増減状況の情報さえ信頼性が低下していると思われる。）

また、このウイルスの届出と、脆弱性の届出は連携しておらず、組織も別々になっていると私は理解している（あまりよく知らないけども）。

ウイルス届出窓口の目的は、「こんなウイルスが流行っています！」と注意喚起することにあるため、窓口の関心事は、ある程度の規模で拡散しているウイルスの情報にあり、targeted attackのように個別に専用に作られたマルウェアにはおそらく関心が低いであろう。そこに、zero-day脆弱性という貴重な情報が潜んでいても、ウイルス届出窓口の関心事ではないと思われる。

つまり、今必要なことは、未知の脆弱性を突いたマルウェアを収集できるよう、届出の仕組みを変えることではないだろうか。

もっとも、IPAに、マルウェアの分析をする能力はないかもしれない。分析を外注するしかないかもしれない。

結局は民間のウイルス対策ソフト会社に分析を外注することになる（コスト的にそれが妥当）のだとしても、それは、被害者から直接Symantecに検体が提供されてしまっている現状と同じことではない。なぜなら、通常、ウイルス対策ソフト会社の仕事はパターンファイルを作ることであり、提供された検体はパターンファイルの作成にのみ利用されるところ、IPA等からの発注で行われる分析では、公益に資するよう分析内容を指定し、脆弱性発見時に脆弱性の詳細を報告することを役務として指定できるはずだからだ。

zero-day攻撃を見つけるためにすべてのウイルスを集めて分析するというのは現実的でないが、少なくとも、政府機関に送り付けられたウイルスについては自国で分析するのが当然ではないか。外注先が外資系企業で、実際の分析が外国で行われることは、まあ、しかたないにしても、国の発注によって分析させることが必要であろう。ましてや、zero-day攻撃の一次情報が、外国企業の blogで他人事のように暴露された記事（Symantecは入手元を明らかにしていないが）というのは、国辱ととらえてしかるべきではないか。

■ 明後日、「SecurityDay2007」でパネル討論

明後日18日は、SecurityDay2007というイベントで、パネル討論に登壇する。会場は「青山TEPIA 4階ホール」とのこと。

■ 追記（24日）

18日のパネル討論のスライドが以下にある。

また、上の「報道を並べてみる」のところに追記した。

*1 同時期に公表された複数の脆弱性を1件としてカウントしている。

本日のリンク元 TrackBack(0)

2007年12月22日

■ はてなブックマークを禁止する技術的方法

ある属性を持つ人々にとって、はてなブックマークは、必要な情報源を巡回するための効率的なツールとなっている。もはや「はてブ」されない記事は存在しないのも同然となってしまている人もいるかもしれない。ソーシャルブックマークサービスはなにも「はてな」だけではないのだが、事実上「はてな」が独占状態にあり（少なくとも一部の分野においては）、「はてなブックマーク」でないと情報源となり得ない状況になっている。この状況はアーキテクチャ的に望ましい状態ではないと思うが、しかたない。

そういう中で一つ問題がある。情報セキュリティの話題を追いかけるには「セキュリティ」タグを見ていればよいわけだが、ここに「JVN」のエントリが出てこない。

JVNの認知度が高まらないのにはいろいろな要因があって、JVNのサイトデザインが最悪だ（ユーザビリティを何も考えていない）という問題もあり、私も研究会の席でそのような指摘をしているけれども、一向に治る気配がない。どこが悪いかは、たとえば「水無月ばけらのえび日記」の2007年4月25日のエントリでも指摘されていたが、他にもおかしいところがいっぱいある。表示されている項目の読み方が直感的でない。特に酷いと思うのは「JPCERT/CCによる脆弱性分析結果」の項目。改善の余地はいくらでもあるのに、直さないのは愛がないからだろう。使いにくいという声は読者からもっとあっていいと思う。

であるにしても、「はてなブックマーク」にJVNが現れて来ないのは異常だ。

じつは、これには技術的な原因がある。それは、JVNは「はてブ」不能にされているからだ。

たとえば、「JVN#50876069」を「はてなブックマーク」に登録する操作をして、ブックマークコメントを見ようとコメント一覧のURLにアクセスしても、「このページはまだブックマークされていません」と表示される。

これは、JVN側でファイル名に「#」が含まれているために生じている。そもそも、Webでファイル名に「#」を使うという、JVNサイト実装者のセンスのなさに呆れるところだが、それが原因でブックマークできなくなってしまうのは「はてな」側のバグであろう。

このバグのせいで、日本のセキュリティ向上がいくらか阻害されていると言ってよいかもしれない。

このバグは1年半以上前から「はてなアイデア」に登録されている。私も投票したのだが、効果なかったようで、無念だ。

直りそうにないので、発想を転換して、これを使ってブックマーク不可能なブログを作ってはどうか。

池田先生には朗報だ。「http://blog.goo.ne.jp/ikedanobuo%23/」というアドレスでブログを開設すれば望みはかなう。（もっとも、gooで「#」や「%」を含むIDは取得できないかもしれないが。）

■ 追記

と、これだけではナニなので、直し方を考えてみる。

こうなってしまう原因は、パーセントエンコードされたURLのデコードとエンコードをどこで行うかが、明確な方針に従って設計されておらず、場当たり的に実装されているために、ちぐはぐになって矛盾が生じてしまっているからだろう。

まず最初に決めなくてはならないのは、http://jvn.jp/jp/JVN%2350876069/index.html のブックマークコメントを見るためのURLは、次のどちらとするのかだ。 

http://b.hatena.ne.jp/entry/http%3A//jvn.jp/jp/JVN%2350876069/index.html ――(A)
http://b.hatena.ne.jp/entry/http%3A//jvn.jp/jp/JVN%252350876069/index.html ――(B)

普通に考えると、(B)のように「%」を「%25」にエンコードしておかないとやっかいなことになりそうなのは直感できる。

実際、はてな公式の「はてなブックマークレット」に「はてブコメント表示」というブックマークレットがあるが、その内容が、 

javascript:location.href='http://b.hatena.ne.jp/entry/'+escape(location.href); ――(C)

となっているように、これは (B)の方針で設計されているように見える。しかし、たとえばWikipediaの日本語エントリ名のブックマークではそうなっていない。 

http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%93%E3%83%8B%E6%95%AC%E8%AA%9E
――(D)

に対して、(C)のブックマークレットを適用すると、 

http://b.hatena.ne.jp/entry/http%3A//ja.wikipedia.org/wiki/%25E3%2582%25B3%25E3%2583%25B3...
――(E)

にジャンプするが、そこは「このページはまだブックマークされていません」となっている。それなのに、このエントリは、 

http://b.hatena.ne.jp/entry/http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%93%E3%83%8B%E6%95%AC%E8%AA%9E
――(F)

で閲覧でき、221 users もの人々にブックマークされている。これはどういうことかというと、はてなツールバーでは、(A)の方針になっているようで、(D)のページで「はてなツールバー」の「↑B」ボタンを押したときは、(F)のURLにジャンプするようになっている。

この時点で、少なくとも「はてブコメント表示」機能について、「はてなツールバー」と「はてなブックマークレット」のどちらかが間違っていることになる。

仮に「はてなツールバー」の方が正しい、つまり (A)の方針で設計されているのだとしよう。しかし、(A) のURLにアクセスすると図1の画面になる。

図1: はてなブックマークのバグ

矢印部分は「%23」となっていなくてはならないのに、「#」とデコードされているのがおかしい。このリンクにジャンプすると、「Not Found The requested URL /jp/JVN was not found on this server.」となってしまう。

(A)の方針で設計されているのなら、ここはデコードしてはいけない。

しかし、ここがこうなっているのは、フラグメント識別子指定用としての「#」に配慮したためであろう。もしこの画面で（すべての）「%23」をデコードしないようにしたら、「http://……/diary/20071222.html#p01」などをブックマークしたときに、リンク先が「…….html%23p01」となり 404 Not Found になってしまう。

ここを、(A)の方針に従いつつフラグメント識別子にも配慮するとなると、エンコードされたURL中の「%23」が、フラグメント識別子用なのかそうでないのかを区別しなければならないが、一旦同じ「%23」としてエンコードされてしまうと単純には区別できそうにない。

いや、そもそも、(A)の方針であれば、フラグメント識別子用の「#」を「%23」にエンコードすることもしないようにするのが自然だ。しかし、そうすると今度は、「http://……/diary/20071222.html#p01」用のブックマークエントリのURLが、 

http://b.hatena.ne.jp/entry/http%3A//.../diary/20071222.html#p01

となってしまい、「#p01」部分がブラウザ上で解釈されてしまい、サーバ側に届かない。この不具合は過去に起きたようで、idea:7628などで指摘され対処されている。これへの対処が、「#」を「%23」にエンコードする方法であるため、フラグメント識別子用の「#」とそれ以外の「%23」とが区別できなくなってしまっている。

つまり、はてはの設計方針は、(A)でも (B)でもなく、(A)' なのだ。(A) を基本としながら「#」だけは「%23」にエンコードするという方針になっているようだ。

そのため、図1の画面では、「%23」だけが特別扱いされてデコードされているのだろう。(F)のエントリのように他の「%XX」はデコードされていない。

これを直すには、(B)の設計で全体を作り直す……というのは現実的でないだろうから、(A)の方針のまま、URL中の「%23」がフラグメント識別子用なのかどうかを区別する手段を見つけ出すしかなさそうに思える。

しかし、この問題は、図1の画面におけるリンク先URLをどうするかの問題であって、「このページはまだブックマークされていません」となるのは、別の問題であり、おかしい。

実際、http://jvn.jp/jp/JVN%2350876069/index.html のページを「はてなツールバー」または「はてなブックマークレット」を用いてブックマーク登録しようとすると、そこには「2 users」と既に2名がブックマークしていると表示される（図2）。

図2: ブックマーク登録はされている様子

登録自体はできているのに、ブックマークコメントを表示しようとすると、「このページはまだブックマークされていません」と図1の画面が出てしまうわけだ。

なぜこうなるのだろう？ それはもしかして、こういうことではないか。データベース登録時には「JVN%23…」の方のURLをキーにして登録しているのに、コメント表示でデータベースから検索する際には「JVN#…」の方のURLをキーにしてしまっているとか。

つまり、フラグメント識別子用の「#」への配慮として図1の画面で「%23」だけ特別扱いでデコードしているところ、そのデコードをした後のURLを使ってデータベースを検索しているのではないか。

だとすれば、それは明らかなバグだ。「%23」を特別扱いしてデコードする必要があるのは、ブラウザ向けの都合であって、データベースには関係がない。（エスケープを出力直前で行わずに入力直後で行おうとする「サニタイズ脳」問題と似ている。）

フラグメント識別子かどうか区別する方法が見つからないのだとしても、とりあえず、データベースの検索部分は直すことができるのではないか。図1のリンク先が正常に機能しないにしても、コメント一覧は表示できるようになると思われる。

■ 追記2 （23日）

この話は、「変な記号使ったJVNのために修正すんの？」という話ではない。普遍的に不具合を生じさせているバグだ。たとえば、「はてな」内でも、フラグメント識別子指定付きURLのページのブックマークに対するブックマーク（メタブックマーク）ができなくなっている。 

http://.../diary/20071222.html#p01 ――(G)

のブックマークページは、 

http://b.hatena.ne.jp/entry/http%3A//.../diary/20071222.html%23p01 ――(H)

となるが、メタブックマークは、 

http://b.hatena.ne.jp/entry/http://b.hatena.ne.jp/entry/http%3A//.../diary/20071222.html%23p01
――(I)

となるため、ここで「このページはまだブックマークされていません」となって閲覧できない。ちなみに、(I)の画面に作られるリンク先URL（つまり(H)のURL）にある「%23」は、デコードすると誤りになる。(H)の画面では末尾の「%23」をデコードする必要があることと食い違っており、やはりフラグメント識別子かどうかの判別はそう簡単にはできそうにない。エンコード時に「#」だけ「%23」にエンコードするようにしたのが大間違いだったと言える。

他にも、「はてなツールバー v1.6.0」でも(G)のページで「↑B」を押すと、 

http://b.hatena.ne.jp/entry/http://.../diary/20071222.html#p01

に移動してしまい、期待したブックマークエントリが出ないというバグもあるようだ。「:」の扱いもバラバラで「%3A」になるときもあれば「:」のままのときもあるようで、もうグダグダで調べる気がしない。

一度全体を見渡しながら「設計」をするべきではないか。

本日のリンク元 TrackBacks(7)

2007年12月25日

■ 「ダウンロード違法化」で漏洩情報のWinny流通を抑止できるか

11月の情報ネットワーク法学会大会の個別発表で、「匿名ファイル交換ソフトで違法複製物をダウンロードした者の法的責任」というご発表があった。その際に私は質問をしたのであるが、その意味するところは聴衆の方々にもわかりにくいものだったと思われるので、その趣旨をここに書き留めておくことにする。その前に、その考察に至る背景から。

「ダウンロード違法化」を望むのは権利者だけではない

いわゆる「ダウンロードの違法化」、つまり、違法複製物又は違法配信からの録音録画を著作権法30条の適用対象外とする著作権法改正に向けた文化審議会著作権分科会私的録音録画小委員会の検討は、昨今の反対派の論調では単純に「権利者（流通業者）の横暴」とみなされているようだが、私には、それとは別の動機によって（を伴って）推進されているように感じられる。

それはつまり、公務員がWinnyを使用して機密情報を漏らす事故を無くすため、職員にWinnyの使用を禁止する法的根拠を必要としているのではないか――ということだ。

昨今の「ダウンロード違法化」に反対する意見からは、権利者の利益保護の観点からは実効性に疑問があるとの声が聞こえてくる。「違法着うたサイト」については公衆送信権侵害ないし送信可能化権侵害で従来通りに取り締まることはできるはずであるし、Winny等でのファイル共有の問題は、今回の「ダウンロード違法化」案では実効性がないという指摘だ。

しかし、警察官や自衛官のWinny使用を止めさせるという観点からは、有効であるかもしれない。

Winny対策としてダウンロードを違法化するという空気は、ずいぶん前から感じていた。Winnyでの情報流出事故がニュースとなるとき、必ずといってよいほど、「巡査長はWinnyを音楽ファイルのダウンロードに使っていた」などの表現で報道されてきたが、これはミスリーディングな表現である。

Winnyはその仕組み上、ダウンロードすると同時にアップロード可能にする構造になっているのであるから、本当は、送信可能化権侵害で違法性がある。もちろん、その仕組みを知らなければ故意が認められないことになるが、それならば、その仕組みを周知徹底すればよい。

私は、Winnyが事件化して以来、何度かテレビや新聞から取材を受けたが、その都度、「ダウンロードするとアップロード可能にすることになる」ことを説明して、それを伝えてもらうよう試みてきた。しかし、残念ながら、いつもどういうわけかその部分を使ってもらえなかった。マスコミはなぜそこを伝えようとしないのか。何か狙いがあるのか、それとも天然なのか。

陰謀論的視点に立てば、「マスコミは著作権を強化したい人たちだから、ダウンロード違法化の機運を作り出すために、あえて『Winnyでダウンロードすることは、道徳的にいかがなものかと思われるが、現行法では違法でない』ということにしたかったのだ。だから、各メディアは、『Winnyでダウンロードするとアップロード可能にすることになる』という事実に触れないよう各社で申し合わせているのだ」と、妄想することもできる。あるいは、情報漏洩事件を伝えるためにマスコミ自身がWinnyを使って情報収集していた（あるいは手先の者にさせていた）ことから、その行為の違法性を問われては都合が悪いので、その部分に触れたくなかったのだという空想も可能だ。

だが、実際のところは、単に何も考えていないためにそうなるのだろうと思う。一昨年2月の「フィッシング報道に見るテレビによる啓発の限界」や、昨年12月の「新聞の意味不明な識者コメントはデスクの解釈で捏造される」でも書いたように、テレビや新聞という超大手メディアでは、一般の人が普通に思っていることしか伝えない構造になっている。一般の人たちの理解において、Winnyで「ダウンロード」する行為が、まさに単にダウンロードするだけのものであるという認識である限り、テレビや新聞はその認識に合わせた表現しかできないのだ。

その結果、テレビや新聞で流出事故のニュースを見た人々は、「警察官も音楽ファイルをダウンロードしてるんだ」「違法じゃないんだね」「じゃあ俺達も使っていいよね」ということになってしまっている。

そうすると、その状況に憤慨する人々が出てくる。それは誰かというと、もちろん著作権の権利者たちもそうであろうが（彼らにとっては昔からの話であってイマサラ感があるはずだ）、もうひとつは、公務員の信用失墜を憂える人たちだ。

これは空想だけれども、たとえば警察の上層部で、「警察官が音楽ファイルをダウンロードとは何事だ！」と怒り心頭の幹部がいたかもしれない。コンピュータの苦手な方からすれば、有料で販売されている音楽を無料で入手すること自体が、直感的に、万引きと同じように感じられるのは不思議でない。しかしそれに対し、警察の法律専門家は、著作権法30条の私的使用に該当するとか、直ちに違法とは言えないといった説明することになるだろう。

そしてその後も、同様の事故が何度も繰り返され、そのたびに「○○県警の捜査情報がWinnyに流出」「巡査は音楽ファイルをダウンロードするためにWinnyを使っていた」と報道される。

これは真に屈辱的なことであろう。となると、著作権法30条がおかしいんじゃないか――という発想が強化されていくのも自然な流れであるように思える。

警察は、職員に対してWinnyの使用を禁ずるにあたり、その根拠の正当性を確保するのに難儀していたのではないかと思う。職場での使用は簡単に禁止できるが、家庭でWinnyを使用することをどういう根拠で禁止できるのか。各地方警察は、内部規定でWinnyの使用を禁止する通達を出していたようだが、それでも使う職員がいて流出事故を起こし続けた。警視庁の大規模流出事件で初めて懲戒免職処分が出たが、免職の根拠は結果責任を問うものであり、「ウイルス作者の悪意が根本の原因であり不可抗力だ」といった理由で不当解雇だと主張されたらどうなっていたことだろう。

そんな中、先週、警察庁が懲戒処分の指針を改正する発表をした。

図1: 警察庁 長官官房人事課 懲戒処分の指針の改正について, 2007年12月20日

これでやっと処分にお墨付きが与えられるのだろう。しかし、警察庁のこの発表を見ると、図1のように「関連刑罰法令等」が空欄になっているところに無理矢理感がある。実際、過去に公表された「懲戒処分の指針の改正について（平成14年7月15日）」を見てみると、免職が含まれるものは必ず「関連刑罰法令等」に刑法なり国家公務員法なりの刑罰が挙げられており、ここが空欄な項目はすべて、減給あるいは戒告、ごく一部でも停職のレベルに止まっていることから、刑罰法規がないのに免職というのは異例なのではないか。

本来ならば、図1のこの欄に「著作権法○○条」と書いておきたいところではないだろうか。

もし、著作権法30条を改正し、ダウンロードを違法化できたならば、職員の規律を正すことはやりやすくなる。「Winnyで音楽ファイルをダウンロードするのは違法だ」「警察官たる者、違法行為をしてはならん」と単純に言えるようになる。報道でも、これまでのような「巡査は音楽ファイルをダウンロードするためにWinnyを使用していた」という表現はされなくなり、「巡査はWinnyで違法なダウンロード行為をしていた」とズバリ言われるようになるだろう。そして、すぐに「懲戒免職処分にした」と発表して切り捨てることができるようになる。

そんな考えがあってかどうかは知らないが、官房長官が「Winnyを使わないで」と異例の呼びかけをした衝撃の2006年3月から8か月が経った同年11月、

政府の知的財産戦略本部（本部長・安倍首相）は音楽や映像を違法コピーした「海賊版」をインターネット上からダウンロードすることを全面禁止する著作権法改正に着手する。２７日に開く知財本部コンテンツ専門調査会に事務局案を提案。罰則も設け、０８年通常国会に提出をめざしている改正案に盛り込む。

海賊版の音楽や映像、ネットでの入手禁止 法改正検討, 朝日新聞, 2006年11月24日朝刊

という報道があり、今年5月に発表された「知的財産推進計画2007」に「私的複製の許容範囲から除外することについて」検討することが盛り込まれ、そして今般の文化庁のパブコメ騒動へと展開しているわけである。

ちなみに、国会議事録を探してみたところ、官房長官が「Winnyを使わないで」と呼びかける一週間前、海上自衛隊から流出した事件について次のやりとりがあったようだ。

○浅野勝人君 （略）海上自衛隊のマル秘文書を含む膨大な業務用データがインターネット上に流出していた問題について、事情をつまびらかにしたいと存じます。

情報が流出したのはファイル交換ソフト、ウィニーのネットワークです。ウィニーは、手に入れたい映画や音楽を検索させると、世界じゅう走り回って、持っていっていいですよとアップロードしている、公開している人のフォルダからもらってきて、こちらのフォルダにダウンロードさせるソフトです。ただし、だれが譲ってくれたかは分からない。つまり、だれか分からない人の郵便受けから映画や音楽をこちらの郵便受けへ無料で運んできてくれるソフトです。逆に、自分の保存している映画や音楽をウィニーにどうぞ持っていってくださいと公開しておくことができます。

（中略）

○浅野勝人君 文化庁に確かめておきますが、ウィニーを使って映画や音楽をただでダウンロードさせるのは著作権の侵害、著作権法違反になりませんか。

○政府参考人（加茂川幸夫君） ウィニーと著作権法の関係についてのお尋ねでございます。

まず、インターネットを通じまして一般的に映画でございますとか音楽でございますとか著作物をダウンロードする行為についてでございますが、これにつきましては、いわゆる私的複製という例外がございまして、一定の範囲内であれば違法に陥ることなく私的複製が許されるわけでございます。

ただ、今お話にございましたいわゆるウィニーを使った場合でございますが、ウィニーはいわゆる不特定多数のコンピューター間でファイルデータを共有、交換するためのプログラムでございますので、これを利用しまして他人の著作物を権利者の許諾なく不特定多数の者に著作物を送信できるような状態に置いた場合、先ほどおっしゃいましたアップロード状態に置くことでございますが、この場合には著作権法上の権利侵害になると考えられるわけでございます。ウィニーの一般的な利用形態はこういうものでございますので、著作権法上問題があると言わざるを得ないと思っております。

○浅野勝人君 分かりやすい。今の説明だと、ウィニーを使って映画や音楽をただでもらってくるのは私的複製で合法だけれども、持っていっていいですよとアップロードするのは著作権法に違反するということですね。

ところが、だれが公開しているのか分からないんですよ。違法行為をしている人が一杯いるのに特定できない、これどうします。

○政府参考人（加茂川幸夫君） 今おっしゃいましたように、ウィニーの利用形態を考えますときに、大変著作権侵害のおそれが高いわけでございますが、著作権侵害を特定します前提となります又は著作権侵害を取り締まる前提となります被害の実態、すなわち、どういう著作物がどのようにして侵害されたかという対象物の特定、あるいは侵害者、だれがこの著作物を侵害したのかといった著作権侵害を認定します構成要件の特定が大変難しいわけでございまして、著作権法上問題があると考えておりますけれども、こういった難しい環境、課題があることも是非御了解をいただきたいと思います。

○浅野勝人君 正直な答弁です。そう思います。全く手を焼いて、手を焼いてて困ったもんだなと思っているという答弁ですよね。世界じゅうそうだから、文化庁で解決できる問題ではない。これからの課題として指摘をしておきますし、取り組む、考えているという答弁だと理解しました。

長官、四十一歳の海曹長は、映画や音楽を交換するためにウィニーを使っていたと言っていると聞いています。これはデータをもらったりあげたりしていたという意味ですよね。著作権法違反の認識はなかったんですか。それはどんな報告を受けてますか。

○政府参考人（西川徹矢君） お答えを申し上げます。

これまで当方の方でこの当該隊員からいろいろ事情聴取をしておりました。その範囲では、彼の目的は映画、音楽データ等の収集を、これを目的として同僚からそういうソフトを譲り受けたと、こういうふうに言っておりまして、そしてまた彼自身も、海自、海上自衛隊そのものでも、実は去年来から何度かこういうウィニーは危険だという講習も受けておりました。

ただ、本人はパソコンについても相当知識がございまして、ウイルスバスターですね、いわゆるそのセキュリティーのソフト等も入れて、ある程度そういうことを自分なりにやっているという気持ちもあったかと思いますが、本人はウィニーによるデータの交換そのものが著作権に違反する可能性はあるということは認識しておりました。しかし、ただ広く世間で使われていることでもあり、特に、いわゆる強いと申しますか、特にこの罪の意識ということが強く持っていたということではなくてこういう事態を起こしたということで、こういう供述の仕方をしている、こういうふうな報告を受けております。

参議院会議録情報 第164回国会 予算委員会 第7号, 2006年3月8日

このやり取りをみても、Winnyで音楽ファイルを入手する行為が、ケシカラン行為であると認識されながらも、はっきりと違法だと言えない状況が見て取れる。この状況から、こうした行為を明確に違法なものと位置付けたいと考えるのは自然な流れであろう。

私もこれまでに何度か、Winnyでの漏洩情報流通の問題を解決するには、Winnyの使用自体を法律で禁止する以外にないということを書いてきた。昨年12月の「Winnyの問題で作者を罪に問おうとしたことが社会に残した禍根」では次のように書いた。

Winnyは、そのような意思を隠せる、あるいはそのような意思をあえて持たないでいられるように工夫されたシステムであったからこそ、今の日本の法制度上、普及したのであり、この性質をなくせば使われないのであるし、この性質をなくさない限り、情報流出事故の被害拡散の防止が実現できない。

つまり、この性質を備えるソフトウェアの使用を法律で禁止する立法を検討するべきだと私は考える。（「squirt」はこの性質を満たさないので対象外となる。）

この性質を備えるWinnyなどのソフトウェアは、コンピュータウイルス（ワーム）と同じ性質を持っていることに注意したい。ウイルス（ワーム）は、害を及ぼす、人の意思に反する動作をさせるなどの特徴の他に、（システム管理者の管理範囲を越えた）自動複製拡散機能を持つことが特徴である。 Winnyは、ワームが止められない（止めにくい）のと同様の原理によって、任意のファイルの自動複製拡散機能を実現していると言える。

Antinnyなどの暴露ウイルスは自動複製拡散機能まで備えていない。Winnyの自動複製拡散機能（管理者の管理範囲を越えた）を利用しているからだ。言わば、Winnyはウイルス（ワーム）プラットフォームであり、（前記の性質を持つ）そのようなソフトウェアの使用は社会的に危険なものと見なすべきである。

（略）

このままでは、著作権の必要性からだけでなく、漏洩情報が流通し続ける社会的危険を回避すべきとの理由まで含めて、ダウンロード行為自体（現行法では自由）を違法なものとして法改正する動きになっていってしまいかねない。ダウンロードは自由であるべきであり、意図せずたらい回しになる仕組みを危険と見なすべきである。

Winnyの問題で作者を罪に問おうとしたことが社会に残した禍根, 2006年12月12日の日記

つまり、私としては、「ダウンロード違法化」以外の法規制によってWinny問題を解決できないだろうかと考えた。（朝日新聞の「ダウンロードを全面禁止する著作権法改正に着手する」という報道を目にして、半月後にこれを書いていた。）

しかし、私が考えるような方法では実現が難しそうなのは承知している。私は現在、「ダウンロード違法化」反対運動に参加しているわけではないので、「ダウンロード違法化」で情報流出問題が解決するなら、それもいいかもしれないとは思う。

ただ、それは、「ダウンロード違法化」による法的副作用による害が無ければの話である。そこで、私も、私的録音録画小委員会中間整理に対する意見を提出した。これについては、11月15日の日記に書いたとおりである。

本件私的録音録画小委員会中間整理の打ち出した著作権法見直し案に従って第30条が改正された場合、P2Pネットワークから情を知ってファイルをダウンロードすることが違法とされることから、ウイルス発見の調査を適法に行うことが不可能となるおそれがあると考える。（一部のP2Pネットワークにおいては、その流通するファイルの大半が違法に送信可能化されているものと指摘されているので、そこからファイルを無作為に入手する行為が「情を知って」複製する行為とみなされてしまう。）

私的録音録画小委員会中間整理に対する意見, 2007年11月15日の日記

「ダウンロード違法化」でWinny流通は抑止されるか

Winnyでのファイルダウンロードは（一部のコアなマニアを除くと）、「地曳」と俗称されるように、キーワードを指定して、そのワードをファイル名に含むファイルを無差別にダウンロードして、後から必要なファイルだけ鑑賞するという、「自動ダウンロード」のスタイルが主流になっている。そして、Winnyをしばらく使っていれば、Winnyにどんなファイルが流れているかは認知することになるから、「自動ダウンロード」を行っていると、キーワードにマッチしてダウンロードしてくるファイルの中に、違法に送信されている著作物も含まれ得ることは、誰でも予見するだろう。

つまり、著作権法が改正されて「ダウンロード違法化」が実現されると、ほとんどの場合、地曳でダウンロードする行為は、違法複製物を「情を知って」ダウンロードする行為となる。

Winnyによるファイル流通はこうした無差別ダウンロードによる拡散が骨格となっているので、これが違法行為となれば、ファイルの拡散が抑制され、流通が縮小すると期待できる。

ところが、そううまくはいかないだろうと私は予想する。（ここからが、情報ネットワーク法学会での質問内容。）

今般の「ダウンロード違法化」の検討では、当初（2006年11月の朝日新聞報道）の「ダウンロードすることを全面禁止する」という威勢のよさとは違って、ずいぶんと限定されたものになっている。それはもちろん、「知的財産推進計画2007」でも、「個人の著作物の利用を過度に萎縮させることのないよう留意しながら検討」とされていたように、違法化することによる副作用に配慮したためであろう。

その最大の譲歩は、ストリーミングは除外するとされた点であろう。「ダウンロード」という言葉が定義を明確にしないままに使われているため混乱が生じしているが、違法化されようとしているのは、インターネットから「ダウンロード（純粋に技術的な意味での）」によって得たデータを、複製物として固定化することを「ダウンロード」と呼んでいるようだ。

そもそも著作権とはcopyrightというくらいで、コピーを作る権利を指すのが基本であったように、コピーを作らないで閲覧する行為と、コピーを作る行為との間には、法律論的に有意な差があるのだろう。

これが、技術の視点で語られると、閲覧するだけの「ストリーミング」であっても、ファイルとしてコピーが作られるような実装もあり得るため、「それも複製じゃないのか」という屁理屈も登場するわけだ。だが、システム的に管理された一時的固定は「複製物を作成するに至っていない」と法的な線引きをすることは可能だろう。cacheフォルダからファイルを取り出すことは出来てしまう場合であっても、それは、取り出した時点で利用者が複製を行ったと見なせばよい。

「ダウンロード違法化」反対派の意見の中には、「ストリーミングとダウンロードは区別できないから」という理由を挙げているものもあるようだが、文化庁は、これを区別することを前提にしようとしているようである。

  • 「ダウンロード違法化」なぜ必要　文化庁の配付資料全文, ITmedia, 2007年12月20日

    【3】キャッシュの取扱い

    ストリーミングに伴うキャッシュについては、著作権分科会報告書（平成18年1月）における一時的固定に関する議論の内容等を踏まえた上で、必要に応じ法改正すれば問題がないと考えられるがどうか。

もっとも、反対派の言い分としては、「そんな区別ができるはずがない」とか、「本当にちゃんと区別してから違法化するのか、信用できない」といった指摘もあるのかもしれない。

ここでは、そうした区別が行われた上で「ダウンロード違法化」が実現されると仮定する。

さて、その場合に、Winnyで「ダウンロード」するのに伴って作成される「Cache」フォルダ内のファイルは、違法複製物にあたるだろうか？ YouTubeやニコニコ動画の閲覧で作成されるファイルを複製物でない扱いにする線引きをするならば、Winnyの「Cache」フォルダ内に作成されるファイルも、同様に複製物でない扱いになるだろう。

ここで、図2に示すWinnyの設定項目が問題となる。

図2: Winnyの設定項目「ダウン完了時に変換タスクを起動しない」

この設定はデフォルトでは、チェックなしの状態、つまり、ダウンロード完了時に変換タスクを自動的に起動するようになっている。「変換タスク」とは、「Cache」フォルダ内のファイル（暗号化されている）を復号して、元のファイルに戻す処理のことを指す。

Winnyでファイルの「ダウンロード」操作を行うと、まずは、取得されるデータは「Cache」フォルダ内に置かれる。1つのファイル全体の取得が完了したとき、デフォルト設定では自動的に「変換タスク」が起動し、「Cache」フォルダ内のそのファイルが復号されて、「Down」フォルダに復元されたファイルが作られる。

「ダウンロード違法化」が実現されたとき、そこで言う「ダウンロード」行為とは、「Down」フォルダに複製物を作成した時点で成立するのだと思う。

つまり、図2の「ダウン完了時に変換タスクを起動しない」の設定項目で、「起動しない」設定にしている場合には、キーワード指定で地曳ダウンロードをしても、ファイルは「Cache」フォルダに作られるだけで「Down」フォルダには作成されないのであるから、「ダウンロード違法化」で言うところの「ダウンロード」行為は成立しないことになる。

もちろん、「Down」フォルダにファイルを復元しなければ鑑賞できないのだから、利用者は、必要なファイルを1つ1つ選択して「変換タスク」を起動することになる。そこで、違法なファイルであると「情を知って」変換すれば、違法行為となるであろう。だが、違法でないと確信できるファイルだけ選択的に変換するようにすれば、Winnyで地曳ダウンロードをしても、「ダウンロード違法化」の影響を受けないことになる――と考えられる。

このことは、著作権の権利者達にとっては（直接的には）困らないことだ。なぜなら、「Down」フォルダに復元されないのなら、その著作物は鑑賞されることもないのだからだ。

しかし、漏洩情報のWinny流通を抑止したいという情報セキュリティ屋の立場からすると、これは、「ダウンロード違法化」によって期待した効果は得られないことを意味する。なぜなら、「ダウンロード違法化」が実現されても、地曳ダウンロード（「Cache」内までの）は従来通りに行われることを意味し、ファイルの拡散は抑制されないからだ。

もちろん、権利者たちにとっても、著作物がWinnyネットワークに広く拡散することは損失であるから、復元されなくても「Cache」フォルダに入るだけで「困る」わけだが、その困り方は、従来と同じである。つまり、「Cache」に格納されて拡散していくことが「困る」点は、まさに公衆送信権侵害ないし送信可能化権侵害であり、既に現行法で違法化されている。

以上をまとめると次のとおり。

「ダウンロード違法化」は、著作権の権利者だけでなく、漏洩情報のWinny流通の問題の解決を望む人たちにも期待されているかもしれない。なぜなら、Winnyの自動ダウンロードは「情を知って」違法複製物をダウンロードする結果を招くため、ざっくりとWinnyの利用全般を違法化できるからだ。しかし、「ダウンロード違法化」が複製を伴わない閲覧を除外する前提でなされるなら、Winnyに「ダウン完了時に変換タスクを起動しない」機能が存在することにより、その期待される効果は回避されてしまうかもしれない。となると、「ダウンロード違法化」の効果は、入手する個々のファイルについてそれが違法に送信されていると認識している場合についてであるから、それならば、現行法でも「Winnyでファイルをダウンロードするとそれは同時にアップロード可能にするものであり送信可能化権侵害に当たる」という事実を周知すればよいはずである。したがって、「ダウンロード違法化」の得失を検討する際には、情報漏洩問題の解決になるとは期待せずに、著作権のあり方の問題を優先するのがよいと思う。

関連：

本日のリンク元 TrackBacks(100)

2007年12月28日

■ Winny稼動ノード数が減少中

先週、「ファイル交換ソフト利用者が急増」というニュースが流れた。

これには疑問の声が挙がっていたが、昨日、ネットエージェントからWinnyノード数は減少しているという発表があり、報道された。

私も減少しているという認識を持っていた。昨年8月末から自宅の空きPCで観測を始めていたWinny稼動ノード数調査は、その後も続けていたのでときどき数字は見ていた。前回は1年前の12月21日の日記でグラフを示した。

それと同じ方法で集計したその後のデータのグラフを以下の図1に示す。

図1: Winny稼動ノード数の推移

昨年の11月末から12月末にかけての大きな減少が見られるが、これは、違法な送信可能化をしている利用者にISP経由で警告通知を行う活動が開始された時期と一致している（「ACCSがプロバイダを介してWinnyユーザに警告メールを送付」参照）。その後、年明けにぶり返し、1月末までは増加傾向が見られる。しかし、3月の頭から再び減少に転じ、ゴールデンウィーク中に若干ぶり返しつつも、その後は単調な減少傾向が見られる。3月頭に何かあったのかは不明だが、ニコニコ動画が「β」を終了し「γ」として新規ID登録を開始してサービス再開したのが3月6日だったようだ。（参考：INTERNET Watchの3月6日の記事、Alexaのページビュー履歴におけるニコニコ動画のグラフ）。

ところで、この観測データの信頼性について検討しておかなければならない。

まず、絶対値について。私の観測値はいつもネットエージェントが発表している値より小さくなっている。今回のネットエージェントの発表では、24日に35万ノードだったとされているのに対し、図1のグラフでは27万ノードくらいになっている。観測開始当初の値も、ネットエージェントの値が40万ノードに対して、私の観測は35万ノードくらいとなっている（2006年12月11日の日記参照）。この原因はまだはっきりしないが、観測方法と集計方法についての相違が原因となっている可能性の他に、調査プログラムの性能が測定制度に影響を及ぼしている可能性がある。

私のプログラムは、Javaによる記述で、スレッド数1300、Windows XP SP2 + Biot無制限設定で動作しており、1秒間に平均57接続を試みる性能になっているのだが、スレッド数を少なくすることでこの接続性能をわざと少なくして同じ測定を行ってみたところ、観測されるノード数は少なくなった。このことから、何らかの方法で性能をさらに上げることができれば、観測されるノード数が増える可能性がある。ちなみに、今回の日本レコード協会らの調査では、「9月28日17時から9月29日17時までの24時間」で「26万4,000ノード」とのことだったが、この値は図1のグラフと概ね一致している。

ちなみに、そもそも「稼動ノード数」を完全に実測するのは不可能である。なぜなら、これら「ノード数」の定義は、24時間以内に一度でもWinnyネットワークに参加したノードの数であるから、「5分間だけ使った」というようなユーザを観測するには、5分でネットワークを一巡するくらいの性能が必要で、それはなかなか難しい（私のプログラムでは約1時間半で一巡する）。したがって、性能を変えながら測定して、究極的性能時の値を推定するという方法が考えられる。これについては既にデータはとってあるので、いずれまとめたい。

次に、相対値について。上に述べたように、観測プログラムの性能が観測ノード数に影響してしまうことから、例えば、インターネットのネットワーク自体の性能が低下することが、観測ノード数に影響してしまう可能性が否定できない。つまり、図1のグラフで減少傾向が見られる原因が、実はユーザが減っているのではなくて、インターネットがつながりにくくなっているためだという可能性がなくもない。ただ、上で「1秒間に平均57接続を試みる性能」と示した性能値で見ると、調査開始から現在までほとんど変化していない（図2）ことから、そのような影響はないのではないかと考えることもできる。

図2: 測定性能（接続数/秒）の変化*1

ちなみに、逆に、実際のノード数が減少すると、それに比例して一巡するのに要する時間が短くなるため、見落とすノード数の割合が減少して測定精度がいくらか向上することになるはずであるから、実際のノード数が減少しているときには、観測されるノード数の減少率は実際よりも緩くなってしまっている可能性もある。つまり、実際には図1より激しく減少している可能性がある。ただ、その影響がどの程度表れるかはまだ計算していない。

さて、日本レコード協会らが「利用者が急増」と発表したことに対して、疑問の声が挙がっているわけだが、このアンケート調査における「利用者数」の定義に注意が必要である。

日本レコード協会らの調査が言う「現在利用者」とは、過去1年間で使用したことのある経験者数である。したがって、「24時間の稼動ノード数」が単調に減少しているにもかかわらず、「過去1年間で使用したことのある経験者数」が「急増する」ということは、同時に起こり得る。たとえば、次などの場合にそのような結果となる可能性がある。

  • 「現在利用者」に占める「ちょっとだけ使ってみてすぐに使うのをやめてしまうタイプの人」の割合が「急増」している。
  • 新たに使い始める人もいれば、使うのをやめていく人もいる中で、入れ替わりが激しくなってきている。

調査の目的において「使用経験者数」の増加が重要であるなら、そのような調査結果も有意義であろう。ただ、それならば、1年間に新たに使い始めた人の増減を調査する方がよいだろう。

また、日本レコード協会らの調査結果は、現状を示すものとしては情報が1年くらい遅れたものになっていることにも注意が必要だ。

つまり、今回発表された調査は 9月に実施されたもので、「現在利用者」とは2006年9月からの約1年間での経験者数であるし、比較対象となっている前年の調査は2005年7月からの約1年間での経験者数であることから、もし、2006年9月ごろがWinny稼動ノード数のピークであったとすれば、この1年4か月の減少傾向は、日本レコード協会らの調査にまだ反映されていない可能性がある。

最近の情勢変化を調べるのが目的であるなら、「現在利用者」は、「過去1年間に」ではなく「過去1か月に」くらいの短い期間での利用経験を問うアンケート内容とした方がよいだろう。もちろんそれだけでは足りないので、「過去1か月の間に使用した」「過去3か月の間に使用した」「過去6か月の間に使用した」「過去1年の間に使用した」「過去2年の間に使用した」「過去4年の間に使用した」「過去8年の間に使用した」のそれぞれを問うようにすれば、全体像の把握が可能なデータが得られるだろう。この調査は今からでも可能である。

追記

別の視点からの分析が以下にあった。2005年以前の同調査との比較が検討されていて、興味深い。

  • ファイル交換ソフトの利用者は急増しているのか?, 監査とセキュリティのあいだ, 2007年12月27日

    「現在利用者」の定義の変更(徐々に定義が拡大)。

    • 2002年の調査では特に説明なし。
    • 2003年と2004年の調査では、ファイル交換ソフトを利用していると回答した利用者と定義。
    • 2005年の調査では、アンケート時より半年以内にファイル交換ソフトを利用したことがあると回答した利用者と定義。
    • 2006年と2007年の調査では、アンケート時より約1年以内にファイル交換ソフトを利用したことがあると回答した利用者と定義。

これはひどい……。

修正（2008年1月6日）

上の「ファイル交換ソフトの利用者は急増しているのか?」引用部で、リンク先の元記事で表現が一部修正されたのに合わせ、引用部も修正した。

*1 極端に小さな値が記録されている部分は、マシントラブルで測定が中断したときの再起動時の中途半端な値が記録されたもの。

本日のリンク元 TrackBacks(100)

2007年12月31日

■ 懐かしのPC-8001を復活させたいのだが……

実家に帰省すると、蔵の不要物を整理することに。

奥の方にしまってあった PC-8001が出てきたので、この際復活させようと部屋に持ってきた。モニタディスプレイとフロッピーディスクドライブ、ケーブルも見つかったので、接続しておそるおそる電源を入れてみると……

PC-8001とPCG-8100と自作の台

モニタとフロッピーディスクドライブ

だめだ。モニタも本体も壊れているもよう。ガックリ。フロッピーディスク内のデータを吸い出したいのだが残念。PC-8801mkIIの復活も試みてみよう。そっちで読めるかも。

とりあえず思い出は写真に収めておこう。デジカメの進歩に感謝。

本体内

行き当たりばったりで改造した本体内。行きつけのゲームセンターのおじさんから譲り受けた8方向レバースイッチを、そのままキーボードの「2」「4」「6」「8」に接続。つないだリード線を固定しないという杜撰さがお子様的。

PCG-8100のサブ基盤とADDCOMサウンドユニット

D780C-1（Z80A互換品）が載っている左の写真は PCG-8100の一部。CPUをソケットから外して換わりにこの基盤を挿し、基板上のソケットにCPUを挿せという構造。上部のフラットケーブルでPCG-8100本体とつながっている。この基盤を外したのが右の写真。下にはADDCOMサウンドユニットが挿さっている。

PCG-8100はPC-8001と同時に購入したのだが、後から買ったADDCOMサウンドユニットの封を開けて愕然。CPUを外してサウンドユニットを挟めという、PCGと同じ構造。両方使うにはどうしたらいいのかと。「これは二段重ねにするしかない……しかしそんな接続して大丈夫なの？」と不安。一晩迷った上、大丈夫なはずだと確信して挿してみるとちゃんと動いたのだった。後から思えばずいぶんな大博打だったなと。

メモリ部

左に並んでいるのがメインメモリ。D416C が16個。16KビットのDRAMだ。

キャラクタジェネレータ周辺部

キャラクタROMがPCG本体に移設され、青いケーブルでつながれている。その他の杜撰な接続は独自改造部分。青いコネクタ左下角から出ている白いリード線は、青いコネクタのピンを1本折ってしまったために別途自力で接続したもの。

裏側の様子

サウンドユニットとPCGを二段重ねにしたため蓋が閉まらなくなってしまった。上の写真のように、本体基盤のへりに蓋を乗っける状態でいつも使っていた。ときどきガタンと外れたりしていたが、よくそれで壊れなかったなと。もうちょっと工夫のしようがあっただろうにと今は思うが、そこはお子様だった。

拡張バスにはフロッピーディスクドライブ用のI/Oポートユニットを接続し、その間に自作の8KバイトSRAMボード（6000-7FFF用）を挟んだ。こういう接続がアリなのか今もよくわかっていない。

PCG-8100の内部

PCG-8100をフルドットカラーに改造*1した様子。本体前部のスイッチが ON-OFF-ONの6Pタイプに付け替えられているところがミソ。右に倒すとPCGオフ、中立位置で通常のPCG、左に倒すとフルドットカラーのPCGとなるようになっていた。

PCG-8100の改造部分

ケーブルコネクタを買い忘れたため、ICソケットでコネクタ代わりにするという杜撰さ。動けばいい。繋げば動くだろうというノリだった。ケーブルもICの足に直付け。

*1 月刊I/O誌、1983年12月号掲載。

本日のリンク元 TrackBack(1)
最新 追記

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
最新 追記
Generated by tDiary version 2.0.2' + patch-2
Powered by Ruby version 1.8.7