2003年06月24日
■ 通信キャリアの独占型PKIは安全なのか
「ドコモ、FOMA向けクライアント認証サービス「FirstPass」」(ZDNet JAPAN Mobile, 6月20日) というニュースが出ていた。SSLのクライアント認証が携帯電話で利用できるようになるらしい。
これは携帯電話のWeb機能の安全確保にとって画期的なことだ。なぜなら、これまで、携帯電話向けのWebアプリケーションには、セキュリティ的に怪しげなものが多く、かなりまずい状況ではないかと心配していたからだ。携帯電話の通信キャリア自らが、アクセス制御の欠如したWebアプリを提供していたという事例すらある。
- Re: auのWAP2.0端末によるHTTP_REFERERの誤送信について (BUGTRAQ-JP, 2002年7月30日)
auの携帯電話はWeb上から通話/通信料金の確認を行なう事ができます。このURLは下記のようなもので、実際には"x"の部分には数字が入ります。
http://cs-ez.au.kddi.com/IDOCustomerService?pageId=CMNxxxG&custID=Dxxxxxxx&menuId=CCI
このページが、auの携帯電話だけでなくインターネットにつながっている端末ならどれでも(HDMLでかかれていますが)このURLを指定するだけで、認証なしに料金を参照できるようになっていました。
携帯電話向けWebアプリが危なっかしいのには、いくつかのシステム的な原因が考えられる。ひとつは、cookieをサポートしていない端末があるため、セッション管理をcookieを使わずに怪しげな方式で作ってしまいがちということ、もうひとつは、携帯電話の操作性の限界から、ユーザにとってユーザ名とパスワードを入力することが面倒であるため、そうしたアクセス制限をかけずに、指定のURLにジャンプするだけでアクセスできるという「なんとなく認証」が使われていることがある。
- auのWAP2.0端末によるHTTP_REFERERの誤送信について (BUGTRAQ-JP, 2002年7月25日)
J-Phoneは自社や他社の携帯電話他へ写真を通常のメール以外でもWeb経由で伝えるサービスを行なっている
このサービスは、主に携帯電話向けに送ることを想定しているためかメールや写真が記載されたページを参照するためのパスワード等の認証機能はなく、複雑で予想されにくいURLを生成することで秘匿性を保っている。
こうした状況がある中で、端末にクライアント認証が導入されるというのは、劇的な安全性向上が期待できる。なぜなら、クライアント認証付きのSSL接続では、サーバ側は、アクセスのたびに、クライアント証明書のCN (Common Name)を読み出すだけで、アクセス者が誰であるのかを特定できるため、面倒なセッション管理の仕組み（セッションIDを発行したり、それを元にユーザを特定する検索機能）を実装する必要がない。そのため、これが普及すれば、素人設計の危ないWebアプリケーションは減っていくだろう。
クライアント認証の有効性は、携帯電話だけでなく、一般のWebにおいても同じだ。Webアプリケーションにおけるセッション管理方式として最も安全なのは、クライアント認証である。しかし、現時点ではほとんど使われていないのが実情だ。使われているところというと、野村證券のホームトレードなど、数えるほどしか知らない。
クライアント認証が普及していないのには理由がある。コストが高いからだ。証明書を発行する中間認証局を運営するため、システムを構築（もしくは購入）し、認証局運用規定を整備し、VeriSign等の（一般のブラウザに普及している）ルート認証局から中間認証局の証明書（年間100万円ほど）を購入しなくてはならない。
それに対し、今回のFOMA向けクライアント認証では、ZDNetの記事によると、
初年度で10数万程度の証明書発行を行い、対応サーバ数は数百を見込む。今後登場するすべてのFOMAで対応する予定。料金は無料となっている。... サーバを構築する企業は、事務手数料3000円のみが必要。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
と、激安になっている。社員が外出先から社内システムにログインするシステムなどで大きな需要があり、これは急速に普及するように思える。
しかし、ここで持つべき疑問は、「どうしてこんなうまい話があり得るのだろうか」ということだ。一般のWebで、中間認証局の証明書を購入するのに年間100万円ほどするというのは、高すぎるように思われるかもしれないが、認証局業務には高度な安全性が求められるのであり、それに必要なコストを各事業者が、そしてその各利用者が分担して負担するという仕組みになっている。NTTドコモの今回の「FirstPass」サービスが激安なのは、コストが電話料金に含まれているか、さもなくば、安全対策へのコストが小さくなっているのではないかと考えられる。
もうひとつ疑問に思うべきなのは、
各サービスごとに複数のID・パスワードが必要だった従来のID・パスワード認証よりも簡単な操作で、
ユーザーは複数の証明書をダウンロードする必要なく複数のサイトで利用が可能だ。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
という点だ。つまり、ドコモが発行したクライアント証明書を、異なる複数の事業者のサーバで使用するというのだ。
一般のWebのクライアント認証では、普通こういう使い方をしない。たとえば野村證券のサービスで発行してもらったクライアント証明書は、野村證券のサービスでしか使えない。ブラウザには複数のクライアント証明書を格納できるようになっており、アクセス先がクライアント証明書を要求してきたとき、どれを送るかをユーザが選択するようになっている。
ドコモの「FirstPass」対応FOMA端末では、複数のクライアント証明書を格納できるようになっているのだろうか。ZDNetの記事にある写真からでは、選択なしに「ユーザ証明書を送信します はい/いいえ」となるように見える。ただ、2つ以上の証明書を格納している場合に別の画面が出る可能性もあるので、これは確かではない。
証明書のcommon nameはどうなっているだろうか。一般に、common nameの名前空間は、その証明書を発行した認証局単位に別々となる。つまり、○○証券のサービスが発行するクライアント証明書では、○○証券が自由に名前を付けることができる。偶然に他のサービスと同じ名前の証明書を発行することがあるかもしれないが、各証明書は発行した認証局のサービスでしか使えないので、衝突することはない。つまり、クライアント証明書のcommon nameは、一般的なWebサイトのログインサービスの「ユーザ名」と同じ性質を持つ。あるサービスで使っている名前は、そのサービスでしか有効でないし、ユーザは、サービスごとに異なる名前を使うのが一般的である。
それに対し、ドコモの「FirstPass」では、認証局が唯一つしかなく、各サービスで共通して同じクライアント証明書を使うのであるから、名前は、各サービスで共通とならざるを得ない。具体的にどうなっているかというと、日経IT Proの記事によると、
端末にはあらかじめ，FirstPassが発行した証明書を入れておく必要がある。通常SSLのクライアント認証用証明書にはメールアドレスなどが入っているが，この証明書にはFirstPassが発行する固有のID番号が入っている。携帯電話ユーザーのプライバシーに配慮したためだ。
SSLクライアント証明書をFOMA端末に無償で発行，NTTドコモが携帯初のサービスを開始 (日経IT Pro 日経バイト, 6月23日)
とある。
日経バイトは、「通常SSLのクライアント認証用証明書にはメールアドレスなどが入っているが」と言っているが、それは正しくない。たしかに、電子メール用の証明書（暗号化メールや、署名付きメール用）ではcommon nameは必ずメールアドレスとなるが、SSL用のクライアント証明書では名前は自由に決められる。通常のログインサービスの「ユーザ名」と同じだ。ちなみに、IPAの電子申請システムで発行されるクライアント証明書のcommon nameは、「CertID0000XXXX」という形式だった。ドコモがcommon nameとしてメールアドレスを使わなかったのは、「プライバシーに配慮」という意味で正しい選択であるが、元々「通常…メールアドレス」という習慣があるわけではなく、プライバシーが向上したわけではない。
そして、「固定のID番号」であればプライバシーに問題がないかというと、既にこれまでにいろいろな事例で見てきたとおりだ。「ID番号からお客様を特定することはできません」などと簡単に言えるようなものではない。
ただ、EZwebの「subscriber ID」とは性質が異なる。EZwebでは、非公式サイトを含むあらゆるWebサーバに対して、アクセスしただけで無条件に、つまり、ユーザの確認すらなしに、「X-Up-Subno」というヘッダフィールドで契約者に固定のIDを送信してしまうが、ドコモの「FirstPass」では、「ユーザ証明書を送信します はい/いいえ」という確認ステップがあるし、PIN番号（暗証番号）の入力も必要になっているので、悪意あるサイトに固定IDを送信してしまうことを、ユーザは避けることができる。しかも、ドコモのルート証明書を持っているサーバでないとSSL接続が確立しないので、この「FirstPass」に契約した者しかIDを読むことはできないと思われる。ZDNetの記事によると、
iモード公式サイトと異なり、FirstPassは公序良俗に反するかどうかだけのネガティブチェック。企業内のイントラネットアクセスのような非公式サイトでも利用できる。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
とあり、なんらかの「ネガティブチェック」が行われるようだ。
では、この状況をプライバシーについてどう考えればよいか。これは、「Webのあらゆるログインサービスで、ユーザ名が唯一の機関によって定められている」という状況に近いと言える。つまり、たとえば、Microsoftの「Passport」サービスが独占的に普及した世界を想像すればよい。Windowsを購入すると、無料でPassportサービスにアカウントを作ってもらうことができ、どこのネットショップに行ってもPassportの同じアカウントでログインするという世界だ。さらに、勤務先のイントラネットに外出先からアクセスする際にも、MicrosoftのPassportのアカウントでログインするという世界だ。
実際に、Microsoftは当初、Passportをそのようなものにしようと企てていた様子が見える。これには多くの批判があった。独占的だという指摘だけでなく、プライバシー上の問題でもあると批判され、対抗するものとして「Liberty Alliance」が結成されている。 -Sun主導で「Liberty Alliance」結成，Microsoftに圧力 (ZDNet News, 2001年9月27日)
Liberty Allianceの方式は、さまざまなプライバシー確保の仕組みを導入し、やるべきことをすべてやろうとしているようだ。
同プロジェクトではSSOの実現に，中央集権型の単一のレポジトリではなく，フェデレーション（協調）モデルと呼ばれる手法を採用している。個々のユーザーID情報を管理して認証を行うIdentity Provider（識別プロバイダー：IDP）と，実際にサービスを提供するプロバイダーが，1つの「信頼の輪」の下で協調し，ユーザーの許可に基づいてSSOを実現していくというものだ。
「（フェデレーション型に比べて），マイクロソフトのPassportで採用されているようなグローバルで一意なIDは，管理が難しい。実際，マイクロソフトも，フェデレーションモデルへと移行していくことを発表済みだ」
クライアント認証に話を戻すと、Microsoftでさえ、万能クライアント証明書（どこでも使える証明書）を無料で発行（あるいは、Windowsに出荷時からプリインストール）などということはしてこなかった。もしそんなことをすれば、強い批判にさらされることは見えているし、そもそもPKIとはそのような使い方をするものではないことを技術者が認識しているのだろう。
Windowsには沢山のルート証明書が入っている。Windowsの上で、多数の認証サービスプロバイダーが事業を展開できるようになっている。OSと、通信インフラと、認証サービスとが独立して提供されるという、これこそがPKIの理念ではなかろうか。
ドコモの独占的PKIである「FirstPass」は、はたしてPKIとして妥当なものだろうか。
まず、安全管理の点で考えてみる。ルート証明書の秘密鍵の管理など、認証局の運営には安全管理にコストがかかるはずだが、「FirstPass」の料金はほぼ無料になっている。しかし、ドコモは、電気通信事業者として、元々、さまざまな場面で高い安全管理を求められているわけであり、それらと同時に認証局の管理をすることによって、コストを見えなくしていると考えることができる。つまり、OSと、通信インフラと、認証サービスを一社で提供することにより、コストを低減したものと見ることができる。
次に、プライバシーの点で考えてみる。ZDNetの記事には、
同様のクライアント認証システムとしては、ｉモード公式サイトで利用している方式がある。中村氏は、「（iモード公式サイトのやり方も）ドコモのネットワークが出しているIDなのでセキュリティは高い」と話すが、FirstPassには別のメリットがあると言う。
「iモード公式サイトと異なり、FirstPassは公序良俗に反するかどうかだけのネガティブチェック。企業内のイントラネットアクセスのような非公式サイトでも利用できる。また、ドコモのネットワークを離れてインターネットに出ていく場合、FirstPassのほうがセキュリティが高い。
ドコモ、FOMA向けクライアント認証サービス「FirstPass」 (ZDNet JAPAN Mobile, 6月20日)
とある。たしかに、ｉモードの公式サイトでは、なんらかのIDによってユーザを特定しているようだ。契約者固有番号がドコモのネットワーク内で流れていると思われる。これは、ドコモのネットワークで閉じているので、安全性が確保されているのだろう。非公式サイトに対しても、ドコモは、端末固有番号の送信機能を 503i から導入してる。
端末IDの取得方法は以下の通りだ。 <form action="http://" method="get" utn> という形で，末尾に“utn”の3文字を追加すると，リンク先に飛んだ際に，「携帯電話情報を送信しますか？」という表示が出る。そこで「送信する」を選ぶと，ヘッダーのUser-Agentのところに DoCoMo/1.0/F503i/C10/ser に続いて，端末のIDが表示される。
非公式サイトへ送信されるIDは、インターネットを流れるので、なりすましが可能な場合があり、安全性が低い。クライアント証明書を使えば、SSLで安全性が保証されるので、「FirstPassのほうがセキュリティが高い」ということなのだろう。
つまり、固定IDによるプライバシー低下の問題は、503i が導入された時点で既に生じていた。「携帯電話情報を送信しますか？」という確認ステップを設けているのは、ドコモが固定IDのプライバシー問題を理解していて、それに配慮したことの現れであろう。今回の「FirstPass」でも、同様に「ユーザ証明書を送信します はい/いいえ」という確認ステップを用意しているのだから、503i よりプライバシーレベルが低下することはない。「ネガティブチェック」をパスして、3000円でルート証明書を手に入れた者しか、IDを得られないという点で、その分プライバシーレベルは向上したと言える。
ところで、そもそも公式サイトに契約者番号が送られているというのは、どうなのだろうか。秘密保持契約で縛られていると聞く。ドコモは電気通信事業法の縛りで秘密が確保されているが、それが、契約によって公式サイト群まで拡大されている。これの守秘性はどうなのだろうか。公式サイト数が増えていけば、守秘性は低下していく。どんな契約になっているのか調べてみたいところだ。
その一方、非公式サイトには契約がないので、503i の端末番号のプライバシーは、「送信しますか？」にどう答えるかというユーザの責任となっている。今回の「FirstPass」ではどうだろうか。3000円を支払ってルート証明書を受け取るときに、どのような契約になっているのだろうか。受信したcommon nameを他者に漏らしてはいけないといった守秘義務が規定されているだろうか。
独占的PKIのプライバシー低下については、公的個人認証についても考えてみる必要がある。これについては、またいずれ書くつもりだ。
安全性の話に戻すと、PKIは、独占的なものでは、万が一秘密鍵が危殆化した場合などに、影響が各サービス全域に及んでしまうので、本来ならば複数の認証局が参入できるようにしておくのが普通だ。FOMAではそれを可能にする予定があるのだろうか。つまり、複数のクライアント証明書を端末に格納できるかどうかだ。可能だとしても、認証事業者の新規参入は困難だろう。なぜなら、ドコモが事実上無料で証明書を発行しているからだ。ただ、安全性をドコモ認証局に依存しないことを重視して、コストを払ってでも他の認証局を使うという需要はあるのかもしれない。
他の認証局の存在し得ない完全に独占的なPKIだとすると、これは、一般的な公開鍵認証の安全性を確保したものというよりも、契約者番号による識別システムを、公開鍵暗号の技術を応用して、独自に安全性を高めたものと見るのが妥当かもしれない。