日本の移動通信システムに関わる業界と個人が集結した「モバイルITフォーラム」というグループがある。ここに、7月25日に公開された「MC部会平成14年度活動報告書」という資料がある。その中に「技術専門委員会活動報告 認証WG報告書」という文書がある。この中に「モバイルID」という用語が出てくる。
「モバイルID」という用語が現れる個所を引用すると次のようになる。
モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.42
- 携帯電話で実装される可能性の高いという観点（既述）から、電子メール、Ｗｅｂアクセス、電子署名（ＦＯＲＭ署名）を考える。
- 電子メールでは、メールアドレスがユーザID として一般に利用されている。認証の確実性を上げるための方法としてはS/MIME が一般的であり、S/MIME 用証明書がプロファイルの参考になる。
- Web アクセスにおいては、携帯電話固有のID（ソフトID、ハードID など、以下モバイルID）がユーザID としてE コマースに使われている。これらはモバイルの世界固有の方法で実現されている。PKI ベースの認証が行なわれていないため、証明書のプロファイルは存在しない。
- 電子署名は、市場ニーズは顕在化していないが、法的効力をもたせるために、個人の氏名を含むユーザID が使われると思われる。民生向けの特定認証業務のプロファイルがある。
２．２．２．２ 証明書の位置付けに関するプロファイル
２．２．２．２．１ 証明書発行対象本プロファイルでは、携帯電話契約の「契約」に対して発行することとする。なお、証明書に記載する発行対象は、契約ごとに一意で、かつ証明対象の特定が困難なモバイルID で表現する。
２．２．２．３．２ 証明対象の表現
証明対象は「Subject」にDN(distinguished name)で表現する。以下の項目は共通仕様とし、他の項目(OU 等)は任意とする。
C = jp
O = (オペレータ社名の英語表記)
CN = (モバイルID。フォーマットは任意)
用語集
モバイルID
携帯電話会社が携帯電話契約の「契約」に対して付与するID で、契約ごとに一意で、かつ証明対象の特定が困難なID を意味する。
「モバイルID」とは、KDDIグループ（auおよびツーカー）の「サブスクライバーID」、J-PHONEの「製造番号」ないし「ユーザID」、NTTドコモの「端末ID」などのことを指すようだ。この報告書は、これらのIDが、「証明対象の特定が困難なID」であるという前提をおいている。
この報告書は、モバイルコマースを実現するための認証技術として、どのような方式が適切であるかを議論し、結論をまとめたものだ。この報告書は90ページにもおよぶが、この内容を8ページにまとめたものが、7月18日に開催された、情報処理学会コンピュータセキュリティ研究会と電子情報通信学会情報セキュリティ研究会の合同研究会で、研究会報告論文として発表されている。
その論文から冒頭部分を引用する。
1. はじめに
公開鍵基盤（ＰＫＩ）を認証技術として用いた電子政府の実現にともない、これまでのＰＫＩの様々な技術検討が実サービスとして結実し、その技術の可能性が立証されつつある。一方、携帯電話の普及に伴い、モバイルインターネットサービスが普及し、着信メロディの有料配信サービスのような携帯電話を用いた決済サービス（モバイルコマース）が立ち上がり始めている。このような背景を踏まえ、より安全で信頼性の高いモバイルコマースの実現と、オープンな標準技術によるモバイルコマースへの適用が注目されている。
ＰＫＩは、その技術標準の核となるX.509がITU-T/JTC1で、また、様々な拡張検討がIETFのPKIX-WGで検討されており、現在、ドラフトも含めて膨大な技術仕様ができあがっている。これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、ＰＫＩに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、ＰＫＩ技術の利用促進に大きく寄与すると考えられる。
これらの点を考慮し、非営利団体であるモバイルＩＴフォーラムＭＣ部会の認証ＷＧでは、平成１３年度から、上記に述べたＰＫＩのモバイルコマースへの適用を目的とした技術検討を進めている。本稿では、モバイルコマース部会・認証ＷＧでの１４年度の検討結果であるＰＫＩ技術の現状、ＰＫＩをモバイルコマースへ適用する際の課題とその検討状況について報告する。
2. モバイルＩＴフォーラムＭＣ部会
モバイルＩＴフォーラムは、第４世代移動通信システムやモバイルコマース等の新世代モバイルの早期実現を図るため、新世代モバイルに関する研究開発及び標準化の調査研究、関係機関との連絡調整、情報の収集を目的とした非営利団体であり、その中でも、モバイルコマース部会（ＭＣ部会）は、インターネットにおける標準技術をベースとして携帯電話、モバイル網を対象に、モバイルコマースを実現するためのビジネスおよび技術の側面からの検討を行う作業部会である。
この論文は、まず最初に、モバイルコマースにおけるオンラインクレジット決済の方式を、「データ入力型モデル」と「端末格納型モデル」、「サーバ管理型モデル」に分類し、それぞれにおいて必要となる認証方式を洗い出した後、ドメイン間認証技術を分類し、その後に、共通プロファイルの規定について述べている。
さて、肝心の部分は、3.4.3節「モバイルID」にある。ここには次のように書かれている。
3.4.3. モバイルID
一般に、公開鍵証明書が証明する対象(subject)としては、氏名、電話番号、端末製造番号、契約番号などいろいろな可能性があり、サービス提供者が統一的に扱うためには共通化が必要である。プロファイルの規定に当たっては、証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した。
(1) 加入者のプライバシ保護
公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。
(2) 回線契約業務との整合性
（略）
(3) 端末変更の可能性
（略）
以上の考察により認証ＷＧでは
- リアルの世界で利用者個人を特定する情報（実名、電話番号、住所）が隠蔽される。
- 機種変更時にも連続性を保証される。
という性質を持つIDとして、加入者契約と一対一に対応し匿名性を持つIDを定め「モバイルID」と呼ぶこととした。モバイルIDは上記条件を満たす限りフォーマットは自由である。モバイルIDはオペレータドメイン証明書のSubjectのCNとして用いられる。
つまり、NTTドコモのFOMA向けクライアント認証証明書発行サービス「FirstPass」が、ここで提案されている方式の一実装といえる。
6月24日の日記「通信キャリアの独占型PKIは安全なのか」や、8月17日の日記「「固有ID」の問題なのか「固定ID」の問題なのか」で書いたように、すべてのCP/SP（コンテンツプロバイダ/サービスプロバイダ）ドメインに共通のIDとなる「モバイルID」を使用することは、第三者cookieや、住民票コードの民間利用などと同様のプライバシー問題を生むものである。
しかし、この論文にはそのことが全く考察されていない。「MC部会平成14年度活動報告書」にもその考察はない。
3.5節で考察されているように、現状のモバイル端末がネットワーク的、ハードウェア的に非力であることと、ユーザのリテラシの低さからくる制約は、たしかにあるだろう。3.5.1節には、ドメイン間認証方式として「独立方式」を採用しない理由が次のように述べられている。
独立方式を用いてドメイン間認証を実現する場合には、複数のドメインの証明書を検証するために、ドメインの数だけ認証局証明書をモバイルユーザがポリシーを理解した上で、安全に入手する必要があり、これは、ユーザリテラシ、端末の記憶容量等の観点から問題点が多い。
「独立方式」とは、サービスプロバイダ自身が運営する認証局からユーザ証明書としてクライアント証明書を発行してもらう方式のことで、PCのWebブラウザではこれが標準となっている。6月25日の日記では次のように書いた。
この件で私が言いたいのは、「FirstPass」は大成功するかもしれないが、「クライアント認証ってこういうものなのね」という理解はして欲しくないということだ。
モバイル端末の上記のような制約から、独立方式ではなく、オペレータドメイン（携帯電話事業者）が認証局となる方式を採用せざるを得ないという結論を出すのは、まあ、よいとしよう。プライバシー上の問題があるにもかかわらず、それを採用し、問題点について触れないようにしておくというのは、営利企業の行動としてはしかたのないことだと、諦めるとしよう。「モバイルITフォーラム」が非営利団体だとはいえ、所詮は業界団体なのだからしかたのないことだと、諦めるとしよう。
だが、情報処理学会のコンピュータセキュリティ研究会、電子情報通信学会の情報セキュリティ研究会という、学術発表の場において、問題点の議論を避けるというのは、いかがなものか。
論文では、「証明書発行者がオペレータドメインのCAであることから特に以下の条件を考慮した」として、「加入者のプライバシ保護」を挙げているものの、実名、電話番号、住所をDNに含めないようにしたというだけで、問題は解決しましたと言わんばかりである。
「固定IDのプライバシー問題は程度問題であるから、程度を考察した結果、モバイル端末の制約上、やむを得ない選択といえる」という結論を出したのなら、その過程を書くのが学術発表というものだ。
これが、意図的に問題点を隠蔽したものではないとするならば、固定IDの問題を知らないということなのだろう。
「セキュリティ研究者」といっても様々な分野の人たちがいる。暗号のプライバシー応用の研究をしている者からすれば、モバイルIDが「匿名性を持つID」とは片腹痛い話だろう。セキュリティ脆弱性を研究する者からすれば、第三者cookieのプライバシー問題や、SuperCookies問題といった過去の事例から、モバイルIDがプライバシー上のセキュリティホールと批判されることは容易に予測できるだろう。PKIのセキュリティ研究者は、固定IDの問題を本当に知らないのか？
しかし、2001年11月に掲載されたZDNet JAPANの記事「「勝手サイトのトラフィックを増やしたい」──WAP2.0に賭けるKDDI」という記事に次の記述がある。
またEZweb端末では，加入者情報である「サブスクライバID」がサーバ側で簡単に取得できるのが特徴だ。NTTドコモなどではサブスクライバIDは公式コンテンツ向けにしか提供されず，一般サイトではユーザー認証に工夫が必要。新端末でも「社内で議論はあったが，サブスクライバIDは変わらず取得できる」と保戸田氏は言う。
NTTドコモでは、契約の縛りのある公式サイト内で閉じたドメインでしか、サブスクライバーIDは使われておらず、503i以降で導入された、「端末ID」を非公式サイトにも送信できるようになった機能も、<form>タグに「utn」属性が付けられているページだけで送信されるもので、かつ、ユーザの同意確認付きという配慮がなされている。これは明らかにプライバシーへの配慮であり、同業他社であるKDDIが、その意図を知らないはずがない。「社内で議論はあったが」とは、プライバシーの問題があるとする意見もあったということだろう。
1年半前に既に「社内で議論はあった」という性質の問題について、モバイルITフォーラムのような場で議論されないなどということがあるのだろうか。ましてや、学術発表の場で話題にしないなどということがあっていいのか。
学会発表の日、質疑応答で質問の手を挙げたが、先に出たぬるい質問にのらりくらりと時間をとられ、時間切れで議論にならなかった。セッション終了後に講演者に質問に行ったとき言われたことはこうだった（メモより）。
「ユーザに説明すればよいこと」というが、NTTドコモの「FirstPass Q & A」のページには、当時、次のように書かれていた。
Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか？
A. ユーザ証明書にはお客様の名前や電話番号等個人情報が記載されていません。ユーザ証明書だけでは個人情報が流出することはありません。
その後このページは改定されたようで、現時点の同ページは、次のようになっている。
Q. FirstPassではユーザ証明書を利用して認証を行うようですが、個人情報が流出することはありませんか？
A. ユーザ証明書には重複しない番号が契約者ごとに割り当てられており、お客様の名前や電話番号等のドコモが管理しているお客様情報は記載されておりません。ユーザ証明書から、ドコモの管理するお客様の名前や電話番号等のお客様情報を知ることはできません。
「ドコモの管理するお客さま情報」は知ることはできないというのは、そりゃそうだろう。だが、問題にされているのはそういうことではない。これが、発表者らの言う「ユーザに説明すればよいこと」なのか？ 改定してもこういう説明に終始するわけか。
ユーザに説明すべきことは、まず少なくとも、この図*1の左下の画面にある「ユーザ証明書を送信します はい/いいえ」の確認画面で、「いいえ」を選択すべきなのがどういう場面なのかということだ。「アクセス先のサイトが信頼できないときには「はい」を押さないでください」と説明すべきだ。どうしてそれを説明しないのか。せっかくQ & Aを改定したというのに。
「住民票コードとは別の話ですよね、番号を付けられるのがイヤだとか」という発言には、心底呆れた。住民票コードの民間利用が禁じられた理由を、理解していないということだ。セキュリティ研究者がだ。
「法律で担保すればよい」については、8月3日の日記で述べたとおりだ。
我ながら、こういうことをこういうところに書くのはいかがなものかとも思う。反論があるなら、同じ学会の場で発表するのがスジだろう。だが、そういう悠長なことを言っている場合ではない。これは霞を食う話ではなく、社会に直結した問題だ。加えて言うと、情報処理学会は、そういう問題を議論する場になっていない。淡々と論文発表が積み重ねられているだけで、議論というものが存在しない。「誌上討論」という制度が設けられてはいるが、基礎領域以外の分野で活用されているのを見たことがない。
正直なところ、私もこういうことを書くのはつらい。実はごく身近な方が関係者だったりすることもあるので、こういうところに書くのはつらい。この件は当事者には既に言いたいことを言った。それでもここに書くのは、固定IDのプライバシー問題がかくもきちんと対応されていないという現実を、とりあえず多くの技術者が知ることしか、この問題の解決の道はないと思うからだ。このことについては、7月18日の日記「いろいろな人に会うということ」に書いた。
結城浩氏の日記「「固有IDのシンプル・シナリオ」を書いた経緯」で、氏は
しばらくして高木さんの日記が「はてなダイアリー」で始まり、固有ID（固定ID）の問題がなかなか理解されない、という話題が書かれていました。（中略） 高木さんの書かれている内容もよく理解できました。しかしそれと同時に、高木さんの文章に物足りないものも感じていました。 1つは長いこと。それから話が正確で具体的であるあまり、話の大きな流れが見えにくいこと、それから当事者に対するいらだちがちらちら文章の中に現れるためか、「技術そのもの」よりも「人」にフォーカスがあたりがちだという点です。
と述べている。同氏の「固有IDのシンプルシナリオ」は、この問題の当事者の人の要素を排除したものなのだろう。
だが、これは本質的に「人の問題」なのだ。技術的な理屈はべつにたいした話ではない。問題に薄々感づいていながら、問題がないことにする人、フォーラムや学会の場ですら問題点を整理しようとしない人、「ユーザに説明すればよいこと」と言いながら、ユーザには決して説明することをしない人。そこにこそ問題の本質がある。
学会発表ではこういう「人の問題」は書くわけにはいかないだろう。だから5月5日、このように日記という媒体を使うしかないと決意をしたのだ。
次の部分を考えてみる。
- Web アクセスにおいては、携帯電話固有のID（ソフトID、ハードID など、以下モバイルID）がユーザID としてE コマースに使われている。これらはモバイルの世界固有の方法で実現されている。 モバイルITフォーラム, MC部会平成14年度活動報告書 技術専門委員会活動報告 認証WG報告書, p.42
なぜこれが「モバイルの世界固有の方法」となっているのか。
ひとつには、携帯電話の世界では、必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる<$=fn "携帯電話事業者からコンテンツプロバイダまでのインターネット通信路上でパケット改竄が可能な場合を除く"%>ためだ。PCの世界でそれを実現しようとすると、なりすましを防ぐための何らかのプロトコルが必要となる。Intelは、1999年にPentium IIIにPSN (Processor Serial Number)を導入したが、その目的は、
Q: Why is Intel developing security features for the platform?
A: The increased use of the Internet for communications and electronic commerce is raising PC users' concerns about the confidentiality and integrity of transaction-oriented data. Since computers are the primary connections to the Internet, they are a logical place for companies to add security features. Over the next several years, Intel is adding security building blocks in order to move the industry forward in developing secure solutions for our customers.
Intel(R) Pentium(R) III Processor Processor Serial Number Questions & Answers
と説明されていた。単に、PSNをコマースサイトに対して送信するだけの方式では、実在するPSNがどこか一か所ででも漏れれば、どこからでもなりすましができるようになってしまうのだから、何らかの工夫が必要となる。
もうひとつの理由は、PCの世界では、ユーザのコンピュータに固有の番号を付けて活用しようという動きは、ことごとく批判されて、すべてお蔵入りになってきたという歴史があるためだ。しばしば、「Pentium IIIのPSNは問題とされるのに、ネットワークインターフェイスのMACアドレスはなぜ問題にされないの？」という声を耳にするが、MACアドレスをユーザ認証に使おうとしたメジャーな動きがなかったために批判されなかったにすぎない。IPv6で下位64ビットにMACアドレスをそのまま使うという話が出たときは、プライバシーの問題があるとして批判され、RFC 3041ができたという経緯がある。
ではなぜ「モバイルの世界」では批判されてこなかったか。これは、モバイルコマースが日本で先行して普及しているためではなかろうか。EZweb方式のサブスクライバーIDのHTTP上の名前である「X-UP-Subno」でGoogle検索しても、英語圏のページがあまりヒットしない。ほとんど話題になっていないのだ。日本で先行しているからこそ、「モバイルITフォーラム」というドメスティックなグループが、
これまで、この技術仕様について机上調査あるいは、各種ベンダー製品の相互接続実験に基づいた検討を行うなどの試みがあるが、モバイルコマースという一つのサービスに着目し、その適用性について検討を行った例はなく、ＰＫＩに基づくモバイルコマースの実現性について、課題とその解決法を明確にすることが、モバイルコマースをさらに発展させ、かつ、ＰＫＩ技術の利用促進に大きく寄与すると考えられる。
という先例のない検討を行うことができるわけである。そして、8月16日の日記「蚊帳の外だった日本が初めて患う大人の麻疹」で述べたように、日本ではこれまで固定IDのプライバシーの議論をする機会がなかった（住基ネットの話題を除いて）ため、技術を設計する立場の人たちが見識を持たないまま、ここまできてしまったと思われる。
PKIの話に戻すと、PKIとはそもそも人を特定するための技術であり、プライバシーとは相反するのはある意味当然である。証明書にズバリ実名と住所を書いていたらどうだろうか。ユーザは、住所と氏名を相手に提供する場合にだけ、その証明書を使うことになるだろう。証明書にメールアドレスを記載している場合はどうだろうか。ユーザは、メールを送信する場合など、相手に自分のメールアドレスを伝えて当然である場面で、その証明書を使うだろう。
Webアクセスでは、メールと違い、通常のアクセスでは自分が誰であるかを伝えないのが前提となっている。商品の送り先を指定する際に、住所氏名を送信するようにして使う。もし、携帯電話用のクライアント証明書に、住所氏名が記載されていたらどうなるだろうか。Q & Aには次のような説明が出てくるだろう。
Q. 「証明書を送信しますか？」というプロンプトが出ます。これはどのような場合に「はい」と答えてよいのでしょうか？
A. 証明書にはお客様の氏名と住所が記載されています。送信先のサイトに住所氏名を提供してもかまわない場合にだけ「はい」を押すようにしてください。
これはこれでわかりやすい話だ。消費者は、証明書の取り扱いに注意するだろう。
これに対し、モバイルITフォーラムの論文では、証明書に住所氏名を掲載しなかった理由を次のように述べている。
(1) 加入者のプライバシ保護
公開鍵証明書への個人情報を記載にはプライバシ保護の観点から注意が必要である。署名時あるいは公開鍵証明書の通知時にはユーザプロンプトにより利用者に注意を促すことが一般に行われているが、通信事業者としては携帯電話ユーザのリテラシや電話紛失等の事故を考慮し、証明書の記載事項レベルでより厳密にプライバシを考慮する必要がある。 モバイルコマースにおけるPKIの現状と課題 ―mITFモバイルコマース部会認証ＷＧの活動状況―
つまり、ユーザプロンプトで利用者に注意を促しても、ユーザのリテラシレベルが低すぎるから、なんでも「はい」を押してしまうことを懸念し、紛失時に住所がばれてしまうことも懸念したためとされている。
このことがかえって証明書の取り扱いを曖昧なものにしてしまったと言える。証明書には「証明対象の特定が困難なID」しか書かれていないので、ユーザのリテラシが低くて何でも「はい」を押してしまう状況でもかまわないというわけだ。かまわないのだから、Q & Aにも説明がされない。
ところで、これはもはや「モバイル世界固有の方法」ではないことに注意してほしい。PKIを使わない状況でのモバイルIDは、先に述べたように、
必ず携帯電話事業者のゲートウェイを経由して、かつ、携帯電話事業者のゲートウェイから直接コンテンツプロバイダへアクセスすることになるため、顧客に固有のIDを確実にふることができ、かつ、成りすましを防ぐことができる
ものであるため、「モバイル世界」ならではの方式だったが、PKIの証明書のcommon nameにユニーク番号を付けるというこの方式は、ゲートウェイやネットワーク方式とは無関係であるのだから、モバイル世界固有でもなんでもない。
PKIのWebアクセスのクライアント認証での使われ方を国際的に見渡したとき、このような各ドメイン全域に共通なIDを付与する方式は、他に類を見ないものだろう。それは、モバイルITフォーラムの案が先進的だからなのではなく、単にプライバシーの問題があるから誰もやっていないというだけだろう。「モバイル世界固有の話なので」という釈明は通用しない。国際的な赤っ恥をかく前に、早めに代替案を検討しておいた方がよい。
*1 ZDNet JAPAN, ドコモ、FOMA向けクライアント認証サービス「FirstPass」に掲載の図。
