画面1 Netscape Navigatorのセキュリティ情報の画面
ゼロから始めるインターネットセキュリティ講座１時間目●PKI概論 講師：宮川祥子 |
WWWでクライアントのアクセス制御とサーバの認証をしたい |
インターネットショッピングもこの１年でかなり普及してきており、日常生活に必要なものからお中元／お歳暮にいたるまで、さまざまな商品が手に入るようになりました。定期的にインターネットショッピングを行なわない方でも、日本では入手しにくい洋書などを“amazon.com”で注文した経験のある方も多いのではないでしょうか。かくいう私も、月に１度は同Webページなどでいろいろなものを注文するユーザーです。最近では、切花を注文できるサイトでガーベラを注文しましたが、注意深く梱包されて新鮮な状態で届き、水をさすとすぐに元気になりました。インターネットショッピングというと、売り手の顔が見えないので不安も多いのですが、このようにお店が買う人の立場に立って親身に考えてくれるところが増えると、インターネットショッピングもますます盛んになっていくのではないでしょうか。
ところで、インターネットショッピングで不安なことの１つに、決済の問題があります。多くのインターネットショップは、決済の手段としてクレジットカードを利用しています。フォームからクレジットカード番号や有効期限を入力することで、実際にカードを機械に通すのと同様のチェックを行なうわけです。クレジットカードの表面に記載されている番号／氏名／有効期限を入力するだけで買い物ができてしまうわけですから（暗証番号は必要ありません）、もしほかの誰かが同じ情報を手に入れたら、自分のクレジットカードの名義で買い物をされてしまうかもしれません。それはカードを紛失するといったことだけにあるのではありません。インターネットでは、通常はパケットと呼ばれるデータの塊を暗号化しない状態で転送しているので、ネットワークの中継地点で誰かがそのデータを覗き見してクレジットカードのデータを盗んでしまうということも考えられます。そこで、このようなデータの漏洩を防ぐ手段が必要となるのです。
インターネットで買い物をして、いよいよ決済というときになって、 画面１ のようなメッセージを目にした方も多いのではないでしょうか。これはクレジットカード番号のような、第三者に漏れると困るデータを送信する際に、これ以降のデータを暗号化して送信し、正当な受信者以外の人には解読できないようにしますよ、という意味のメッセージです。このメッセージに「続ける」と答えると、これ以降の通信は暗号化され、第三者には解読できないようになるので、安心してクレジットカードの番号などが送信できるようになります。Netscape Navigatorであれば、ウィンドウの左下に表示されている鍵が、暗号化された通信を行なっているときにはかかった状態になります（ 画面2 ）。これが「現在暗号化した通信を行なっています」という印です。IEでも暗号化された通信の際には、ブラウザの右下部分に鍵のアイコンが表示されます。
画面1 Netscape Navigatorのセキュリティ情報の画面
画面2 暗号化された通信を行っている際の鍵アイコン
また、これらデータの漏洩とは別に「そのサイトは安全か？」という問題もあります。不正にクレジットカードなどのユーザー情報を入手する目的で、ショッピングサイトのようなWebページを作成したり、ブラウザのセキュリティホールをついたウイルスまがいの動作をするページがないとも限りません。しかし、ブラウザの鍵がつながっている場合は、後述する認証局と呼ばれる第三者により、安全なサイトに接続していることが保証されています。これらはSSL（Secure Socket Layer）と呼ばれる暗号化通信プロトコルが利用されています。SSLの具体的な話は、２時間目以降で説明します。
上の例は「サーバ認証」と呼ばれる暗号技術の応用です。サーバ認証を用いれば、自分が通信したいと思う相手のサーバに、安全／確実にデータを送信することができます。このほかにも、逆にサーバの立場から見て、自分が通信をしたいクライアントを一意に特定する「クライアント認証」と呼ばれる技術もあります。この連載では、これらを使って安全なインターネットショップを開店するための仕組みについて説明していきます。
インターネットで弁当屋を開く |
弁当屋のニーズ
ここではより具体的な例として、インターネットで弁当屋を開店するというケースを想定してみましょう。オフィス街に近い商店街にある弁当屋が、オフィス街のお客さんからインターネットでお昼のお弁当を注文してもらうために、インターネットショップを開店しようと思っています。しかし、隣の商店街にはライバルの弁当屋があり、やはりインターネットショップを開こうとしているようです。もしかしたらライバルの弁当屋がサイト名などを偽ることにより自分の店あての注文を横取りしてしまうかもしれませんし、誰かがいたずらをして嘘の注文をするという可能性もあります。注文どおり弁当30個を配達したのに「うちでは注文していない」といわれてしまったら商売が成り立ちませんので、弁当屋としては誰が注文したのかを確実に知っておく必要もあります。
この弁当屋のニーズをまとめると、
①お客さんに確実に注文してもらいたい
②どのお客さんの注文かを確実に知りたい
ということになります。これは、それぞれサーバ認証／クライアント認証によって実現することができます。
商店街ぐるみでの認証インフラ
さらには、商店街全体で同じようにインターネットで安全確実に買い物ができる仕組みを構築することも可能です。その場合は、各お店ごとにクライアント認証やサーバ認証の仕組みを構築するのではなく、商店街ぐるみでやってしまったほうが便利でしょう。いわば、その商店街で通用する共通の身分証明書を持つようなものです。この場合には、クライアント／サーバ認証の仕組みに加えて、証明書管理の仕組みが必要になります。
PKIの構成要素 |
公開鍵暗号と電子署名
インターネットでこのような認証の機能を提供している基盤のことをPKI（Public Key Infrastructure）と呼びます。PKIは、公開鍵暗号系とよばれる暗号技術を利用しています。公開鍵暗号系では、１つのエンティティ（人やコンピュータなど、認証の対象となる主体）が公開鍵と秘密鍵と呼ばれる鍵のペアを持っています。それぞれの鍵は、データを暗号化／復号化するときに使います。公開鍵とは、文字どおり「外部に公開する鍵」で、メッセージを暗号化するときに使います。逆に秘密鍵は、ほかの人に盗まれないよう厳重に管理しなければなりません。公開鍵によって暗号化されたメッセージは、その公開鍵と対応する秘密鍵でのみ復号化することができます。自分宛てのメッセージを暗号化してほしい場合には、通信相手にあらかじめ自分の公開鍵を渡しておき、その公開鍵でメッセージを暗号化して送ってもらえばいいことになります。暗号化されたメッセージを復号化できるのは自分の秘密鍵だけですから、ほかの人に暗号化メッセージを解読される心配はありません。逆に、相手に暗号化したメッセージを送りたい場合には、あらかじめ相手の公開鍵を入手しておき、その公開鍵を使って送りたいメッセージを暗号化することになります。このように自分の公開鍵を広く配布することによって、多くの人が暗号化されたメッセージを自分宛てに送ることができるようになります。逆に秘密鍵は、他人の手に渡ってしまうと自分宛ての暗号化メッセージを解読されてしまいますから、誰にも盗まれないように厳重に管理しておく必要があります（図1）。
図1 公開鍵暗号を用いたメッセージの暗号化と復号化
公開鍵暗号のもう１つの使い方は、あるデータが本当に発信者からのもので途中で改ざんされていないことを証明することです。これを電子署名といいます。電子署名は、先ほど紹介したデータの暗号化とは逆で、署名をしたい人が自分の秘密鍵を使って行ないます。あるメッセージに署名をする場合、そのメッセージ（あるいはそのメッセージのダイジェスト）と秘密鍵を使って電子署名と呼ばれるバイト列を生成します。電子署名は署名の元となったメッセージとともに相手に送られ、相手があらかじめ入手している、メッセージ発信者の公開鍵を使って復号化されます。相手は、送られてきたメッセージ（あるいはメッセージのダイジェスト）と復号化された文字列を比較して、もし同じであれば、そのメッセージが途中で改ざんされていないことを確認することができます。秘密鍵を持っているのは、鍵ペアの所有者本人だけなので、上の方法で署名が正しく検証できればデータは間違いなく発信者から送られたものであり、途中で改ざんされていないことが証明できます（図2）。
図2 公開鍵暗号を用いた電子署名
公開鍵証明書と認証局（CA）
暗号化された通信を行なったり電子署名を検証する際に「相手の公開鍵をあらかじめ入手しておく」と書きました。しかし、どうやって安全に相手の公開鍵を入手すればよいかという問題が残ります。相手と直接会ってFDなどに入った公開鍵を手渡ししてもらえば安心でしょうが、それでは自宅などから買い物ができるインターネットショッピングのメリットがなくなってしまいます。もし誰かが偽の公開鍵を配布したらどうなるでしょう。そうなると、あなたに送られた暗号化メッセージを自分の秘密鍵で解読することができません。それだけではなく、暗号化してあなたにあてたメッセージを別の誰かが読めることになってしまいます。これでは安心してインターネットショッピングを利用できません。 そこで今度は、自分の公開鍵を正しく配布するための仕組みが必要になります。このための仕組みとして公開鍵証明書というものがあります。公開鍵証明書とは、第三者があなたの公開鍵を「本物です」といって証明してくれるものです。証明を行なってくれる第三者のことを認証局（Certifi-cation Authority：CA）と呼びます。現在いくつかの商用認証局がすでに存在していますし、主として地域住民を対象とした非営利の認証局も立ちあがりつつあります。私もそのような非営利の認証局のメンバーなのですが、これについてはまた後ほど述べることにします。
証明書の検証
公開鍵証明書は、紙に印刷されたものではなくデジタル情報です。公開鍵証明書の中には、公開鍵そのものに加えて、公開鍵の所有者の情報／この公開鍵を証明する認証局の情報／証明書の有効期間／認証局の電子署名、などが含まれています。図3はBさんの公開鍵証明書を受け取ったAさんが、Bさんの公開鍵証明書の正しさを検証するプロセスを示しています。公開鍵証明書を受け取ったAさんは、公開鍵証明書を発行した認証局の電子署名を検証することによって証明書に記載されている公開鍵が本物であるかどうかを確かめることができます。Aさんがあらかじめ持っている認証局の公開鍵証明書が正しいものであるとわかっていれば、その公開鍵証明書を使って電子署名を検証し、Bさんの公開鍵証明書が正しいものであるかどうか判断することができます。
図3 Bさんの公開鍵証明書の検証
しかしここでも問題があります。Bさんの電子署名を検証するのに利用した認証局の公開鍵証明書は、本当に本物でしょうか？ それを確かめるには、認証局の公開鍵証明書の電子署名を検証する必要があります。認証局の公開鍵証明書は、さらに別の認証局によって発行されています。しかしこれでは、認証局の公開鍵証明書を検証するために、その証明書に電子署名をしている認証局の公開鍵さらにが必要で……といった具合に、いつまでたっても公開鍵証明書の検証が終わらないことになってしまいます。
PKIでは、この問題を回避するためにroot CAと呼ばれる特別な認証局を利用します。root CAとは、公開鍵を検証したい人が信頼の拠り所とする認証局のことです。ここでいう信頼とは、
言い方を変えれば、認証局は階層構造を取っており、下位の認証局が上位の認証局に公開鍵を証明してもらう形になっています（図4）。頂点にある認証局は自分の公開鍵を証明してくれる上位認証局がいないので、自分の秘密鍵で自分の公開鍵に署名する自己署名型の公開鍵証明書を持ちます。ある公開鍵証明書を検証するためには、その証明書の電子署名を検証して認証局の階層を下から順番にたどっていき、どこかでroot CAにたどり着けばその公開鍵証明書の検証が完了するということです。頂点にある認証局は自分の正しさを証明する認証局がないので、ほかの手段で信頼性を証明します。たとえば自分の公開鍵のハッシュ値（これを鍵指紋：Fingerprintといいます）を名刺に印刷したり新聞広告などの媒体を利用して広く告知することによって、公開鍵の正しさを「社会的に」広報するなどの手段があります。これについては、２回目以降で詳しく説明したいと思います。
図4 認証局（CA)の階層構造
破棄証明書リスト（CRL）
発行された公開鍵証明書は、さまざまな理由により失効します。たとえば、あるエンティティの秘密鍵が盗まれてしまった場合には、その秘密鍵に対応する公開鍵は無効としなければならないため、公開鍵証明書も失効します。また、学校を卒業すると学生証が無効になるように、ある組織から抜けた場合には、その組織から発行されていた公開鍵証明書を無効にしなければならない場合もあります。そこで、ある公開鍵証明書が有効であるかをチェックする仕組みが必要になります。PKIでは、失効した公開鍵証明書を破棄証明書リスト（Certi-ficate Revocation List：CRL）と呼ばれるリストに登録し証明書の検証の際に参照できるようにしています。
証明書リポジトリ
公開鍵証明書を利用することで、通信したい相手に自分の正しい公開鍵を渡すことができます。しかし上に挙げた弁当屋の場合、注文したい人全員に弁当屋の公開鍵証明書を渡すのはたいへんなことです。もしどこかのWebサイトで公開鍵証明書を掲示することができれば、必要な人はそこから公開鍵証明書を取っていってもらえるので、楽に自分の公開鍵証明書を配布することができます。このためのWebサイト（証明書掲示板）は証明書リポジトリと呼ばれています。先ほどのCRLも、証明書リポジトリに登録されます。ですから、証明書リポジトリに問い合わせれば、通信相手の、正しく、かつ有効な公開鍵証明書が入手できます。
証明書リポジトリは、ディレクトリサーバと呼ばれる仕組みを使って実現されています。ディレクトリサーバとは階層型のディレクトリにデータを保存し、外部からの問い合わせに応じてデータを検索する仕組みのことです。普段使っているOSのディレクトリと構造は同じで、あるディレクトリの下にはデータ（OSの場合はファイル）があったり、下位のディレクトリが存在します。ファイルの識別子がrootからのパスであるのと同様、ディレクトリサーバに登録された公開鍵証明書もDN（Dis-tinguished Name）と呼ばれるrootからのパスによって一意に識別されます。ちょっとややこしいのですが、ここでの“root”は、root CAとは関係ありません。CAもリポジトリも階層構造をとっていますが、この２つはまったく別のものだということを覚えておいてください。
PKIの現状 |
PKIは、現在IETF（Internet Engineering Task Force）のPKIX-wg（Public Key Infrastructure X.509 Working Group）と呼ばれるグループによって規格化が進められています。X.509とはITU（International Telecommunication Unit）およびISO（International Standards Organization）によって提唱された公開鍵証明書やCRLの規格です。PKIX-wgでは、X.509を基本としてPKIの規格化を行なっています。これらの規格はRFC（Request For Comment）にまとめられ、一般に公開されています。2000年２月現在で、おもなものは以下のとおりです。
すでにさまざまな商用認証局が、公開鍵証明書の発行を行なっています。日本ベリサイン（ http://www.versign.co.jp/）はVeriSignの日本法人で、この業界では老舗です。また、エントラストジャパン（ http://www.entrust.co.jp/）や、日本ボルチモアテクノロジーズ（http://www.baltimore.co.jp/)などもあります。これらが海外企業の日本法人や海外企業との提携であるのに対し、日本認証サービス（http://www.jcsinc.co.jp）は、富士通／日立製作所／NECにより設立された認証局です。もちろんこのほかにも海外を中心に多くの認証局が存在します。
また、非営利の認証局も立ち上がりつつあります。CACAnet福岡（電子認証局市民ネットワーク福岡、http://www.cacanet.org/）は、非営利の認証局を運営する市民団体です。商用ソフトウェアに対してオープンソースで開発されたソフトウェアが「ユーザー＝自分たち」にとって幸せな利用環境を作ろうとしているように、この団体はインターネットを使う人々の生活の安全と信用の基盤となるPKIを自らの手で作ってゆくこと、そしてそのための技術開発とPKIの普及を目的としています。具体的には、地域における医療情報や介護情報のプライバシー保護のためのPKIなど、人々の生活に密着したサービスを目指しています。CACAnet福岡は、主として福岡の住民や福岡に所在するシステム関連企業の社員などを中心に活動を行なっており、現在NPO法人化や認証局立ち上げのための準備を行なっています。
公開鍵証明書の正しさは、証明書を発行した認証局の署名の検証によって確認されるので、認証局の公開鍵証明書を持つことはとても重要です。メジャーな認証局の公開鍵証明書は、Netscape NavigatorやIEに最初から組み込まれています。Netscape Navigatorだと「Communicator」メニューから「ツール」-「セキュリティ情報」を選び「署名者」をクリックすると、公開鍵証明書が登録されているCAの一覧が表示されます（画面3）。IEでは「ツール」メニューから「インターネットオプション」を選び「コンテンツ」タブの中の「証明書」で確認できます。「中間証明機関」と「信頼されたルート証明機関」に、公開鍵証明書が登録されている認証局がリストされています。このほかにも、自分の信頼する認証局の公開鍵証明書をあとから追加することもできます。
画面3 公開鍵証明書が登録されているCAの一覧
★
次の講義では、先ほど紹介した弁当屋のサーバを実現するための、具体的な各種ソフトウェアのインストールや設定について解説します。
| この記事は、Ascii Network Pro 2000年5月号に掲載された記事を、株式会社アスキーのご好意によって掲載許可をいただいたものに、若干の加筆訂正を行ったものです。この場を借りて、株式会社アスキーに御礼申し上げます。 |