〜インターネットセキュリティの切り札〜
連載:PKI再入門

第3回 信頼関係構築に必須の「信頼モデル」



久保彰
電子認証局市民ネットワーク福岡
2003/6/12
 連載ロードマップ
第1回 個人認証とは?
第2回 PKIにおける信頼とは
第3回 必須の信頼モデル
第4回 公開鍵に基づく信頼
第5回 第三者認証


 「第2回 PKIにおける信頼とは」までは、PKIにおける信頼とは何かということを中心にして、PKIにおける信頼関係を構成するうえで必要な概念の解説を行ってきた。今回はPKIにおける信頼関係を構築するために必要となる信頼モデルについて解説をする。

 PKIにおける信頼を構成する各エンティティ(認証者、主体者、信頼者)によりさまざまな信頼関係が形成される。これらが形成する信頼関係を総称して信頼モデルと呼んでいる。

 PKIの信頼モデルには、大きく分けて3つのモデルがある。

  1. 階層モデル
  2. 相互認証モデル
  3. Webモデル

 また頻繁にPKIの信頼モデルと対比される形で取り上げられるPGP(Pretty Good Privacy)で用いられる直接信頼モデルについても取り上げていきたいと思う。

   PGPとPKIの違いとは?

 PGPとPKIは信頼モデルの違いによりしばしば比較されるものである。ここではPGP/PKIのそれぞれの違いについて信頼モデルを中心に解説していきたい。PGP/PKI共に公開鍵による信頼基盤を構築するものであるが、その信頼モデルや仕様には大きな違いがあることが以下の表からも分かると思う。

PGP
PKI
信頼モデル 直接 間接(第三者信頼)
信頼点 個人 認証者
信頼の連鎖 個人責任 認証者
公開鍵の信ぴょう性 個人責任 認証者による保証
スケーラビリティ 拡大しづらい 拡大が容易
利便性・使いやすさ 直感的であり使いやすい アプリも含め使いづらい

 PGPの信頼は個人をベースに構築されるものである。つまり「友達の友達は友達である」という俗にいう「友達の輪」による信頼モデルである。直接信頼モデルでは信頼点は自分自身であり、自分の信頼するだれかが信頼しただれかを信頼するか否かもすべて自分で判断する必要がある。

 またPGPでもPKIと同様に公開鍵暗号を使用するのであるが、この公開鍵の信頼性や本人同一性については全く保証の限りではない。この点がPGPとPKIの決定的な差であり、主体者の存在や本人性などについては証明が行われない。また使用する公開鍵については本人の公開鍵であるか否かを判断し信頼するための基準が本人に帰着する。

 なお、読者の皆さんも情報交換を目的にメーリングリストなどに参加されているだろうが、メーリングリストに投稿される記事のシグネチャにPGPのフィンガープリント(改ざんされていないことを証明するデータ)が記載されているのをご覧になったことがあるだろう。これは送信者本人の持つ公開鍵の指紋を公開することで、公開鍵の信頼性を確保するために行われる。このほかにもWebサイト上でPGPのフィンガープリントを公開している場合などもある。

 しかし、いずれの場合でも公開鍵の信頼性については、本人の自己申告であるためその申告内容を信頼するか否かについては、自己責任であること自体は変わりはないのだ。

 このような理由からPGPは利用範囲として限られたコミュニティなどで使用することが想定されており、オープンなネットワーク上の不特定の相手との通信には不向きであると考えられる。

 これに対してPKIにおける信頼は、第三者を信頼することによる“間接信頼モデル”である。主体者を認証した第三者を検証者(信頼者)の信頼点とすることにより検証者は主体者を信頼することが可能となる。検証者から見れば、顔さえも見たことのない相手を信頼するには、主体者の存在や身元がハッキリしていることが信頼するうえで最低限必要な要件である。従って匿名や偽名などを使用していたとしても主体者について厳密な身元確認を行うことなく、だれでも簡単に認証してしまうような認証者であれば、怖くて信頼できないのは当たり前である。

 なお筆者も実際に利用しており、電子メールの到達性をもって主体者を認証する認証ポリシーも実在し、実際に利用されていることを確認している。しかし、企業間(BtoB)や企業個人間(BtoC)の取引などでは厳密な本人確認作業が要求されることもあるというのも理解いただけるだろう。

 従って第三者を信頼することにより信頼関係を構成する間接信頼モデルは信頼の範囲を容易に拡張可能(スケーラビリティに富む)であり、オープンなネットワーク上で個人認証を行う必要性がある場合には非常に有効な信頼モデルとなる。

 では次に代表的なPKIの信頼モデルについて考えていこう。

   最も簡単な信頼モデル ―― 階層モデル

 階層モデルは最も簡単な信頼モデルであり、現在運用されているPKIの認証システムで数多く利用されている。

図1 階層モデルの例

 階層モデルは、主体者にも、検証者にも分かりやすく検証などのしやすさなどのメリットがあるため比較的よく用いられる信頼モデルである。このモデルでは信頼点をトップCA(認証局)とすることで、主体者同士および検証者が信頼することが可能となる。

画面1 階層モデルによる信頼関係

   トップCA間で互いに信頼関係を構築する信頼モデル
 ―― 相互認証モデル

 相互認証モデルとは、おのおのの階層モデルの信頼モデルについてトップCA間で互いに信頼関係を構築することにより実現される。

 最近になって政府PKI(GPKI)や地方自治体PKI(LGPKI)といった認証基盤の中で盛んに使われているのでご存じの方も多いと思うが、BCA(ブリッジCA:Bridge CA)による相互接続もこの相互認証モデルに含むことができる。文書によっては相互認証モデルとブリッジモデルを別に扱っているものもあるが、本稿では同一として扱う。

 相互認証モデルでは、認証ポリシーの異なる階層モデルのトップCA同士の信頼関係を構築するため、本来は信頼関係のなかったエンティティ同士の信頼関係もトップCAの相互認証により可能となる。

 相互認証モデルは、互いに信頼し合う双方向信頼と片方向信頼のどちらかが選択可能だ。例えば、ある会社の認証システム(ここではAとする)とライバル会社の認証システム(ここではBとする)があり、A社がB社を吸収した場合を考えてみよう。

 AB互いの認証システムはそれぞれ別々に運用され、AB間には信頼関係はもちろん存在しない。しかしA社とB社が1つの会社になることにより、これまで別々に運用されてきた認証システムを統合する必要が出てくる。

 A社のエンティティがB社の認証システムのトップCA(すなわちB)を信頼点として、またB社のエンティティもA社のトップCA(すなわちA)を信頼点としてしまえば事は足りると思われがちだが、この方式ではABそれぞれのトップCAの更新時期に再度信頼点を更新する必要が互いに発生してしまうので、通常ではAB間に相互認証による信頼関係を構築し、A社B社の統合トップCA(ここではNとする)を新たに構築する。

 このNから主体者に対し新規に公開鍵証明書を発行し、これまで使用してきた公開鍵証明書(旧)と新しい公開鍵証明書(新)を併用する運用が行われる。こうすることにより旧証明書(AB)はお互いに信頼関係が存在し、新証明書についてもほぼ同時期に運用可能となるため、認証システムの切り替えなどの際に有効に両認証システムを活用できる。

図2 相互認証モデルの例

 相互認証では、A⇒B、B⇒A、A⇔Bの3つの認証パターンが考えられる。どちらか一方がもう片方しか信頼しない認証(A⇒BまたはB⇒A)を片方向相互認証と呼び、互いに信頼しあう認証を双方向相互認証と呼ぶ。片方向相互認証の場合どちらか一方からしか信頼関係を構築しないため、例えばA⇒Bの相互認証の場合、A社内のエンティティはB者エンティティを信頼することはできるが、反対にB社内のエンティティはA社内のエンティティを信頼しない。

 相互認証では片方向、双方向を問わず、あるCAが別CAに対し相互認証証明書(X-Cert)を発行し、発行された相互認証証明書を中間認証機関として扱うことにより実現している。例えば、上記の場合の初期状態では、以下のようになっている。

 また、A⇒Bの相互認証を行うと、以下のようにあたかもCA-BがCA-Aの中間CAであるかのようにCA階層が構成される。これによりA社のエンティティはB社エンティティを信頼可能になる。

 さらにB⇒Aの相互認証を行うと以下のようになり、B社エンティティがA社エンティティを信頼可能となる。

 相互認証では、相互認証証明書という中間CAを作成することになるがA社B社とも互いの信頼点が以前と全く変わらないことに注意してほしい。新たに信頼点を追加したりする必要がないため、認証ポリシーが異なる認証システム(通常認証ドメインと呼ばれる)を相互接続する場合、従来の運用を損なうことなく利用可能になる。この運用と併せて新規CAの並列運用も可能なため、新しい認証システムへの移行も簡単になる。ちなみに相互認証証明書(A⇒B)のopensslでの実行結果を以下に示す。

Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number: 1000 (0x3e8)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=JP, O=CA-A, CN=CA-A
    Validity
      Not Before: Jun 7 13:56:07 2003 GMT
      Not After : May 28 13:56:07 2004 GMT
    Subject: C=JP, O=CA-B, CN=CA-B
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      RSA Public Key: (512 bit)
        Modulus (512 bit):
          00:ab:fe:d8:3f:05:3a:12:ee:e5:95:6a:5a:53:32:           64:97:ad:e3:d5:27:0c:d5:0e:17:31:e6:2e:cf:8c:           71:a5:4e:b0:10:38:54:c7:b1:04:4e:b0:01:c1:f2:           ef:6e:cb:ca:be:c8:1e:d8:1e:e4:51:01:5e:29:f6:
          40:7e:a2:e5:5b
        Exponent: 65537 (0x10001)
    X509v3 extensions:
      X509v3 Basic Constraints: critical
        CA:TRUE
      X509v3 Key Usage:
        Digital Signature, Non Repudiation, Certificate Sign, CRL Sign       X509v3 Authority Key Identifier:         keyid:C8:BA:70:CF:DE:E9:28:AF:E0:DB:76:F6:F4:9B:E2:53:3D:D0:D2:D3       X509v3 Subject Key Identifier:         5F:3D:E0:4D:C7:56:39:3E:CF:9C:A6:6E:94:5A:5F:87:96:6D:C2:DA   Signature Algorithm: sha1WithRSAEncryption     d7:5e:97:02:c7:f3:c1:4d:5b:fd:b0:40:ff:28:c1:4e:0e:2e:     2c:f1:0b:4b:3a:37:f8:b0:0b:5f:c0:e7:86:a6:4a:78:61:7b:     ee:74:26:74:5f:21:29:9b:4f:af:eb:74:50:93:86:1f:99:8d:     2e:6e:5e:25:dc:3a:d5:fe:f4:bc
リスト1 相互認証証明書(A⇒B)のopensslでの実行結果
リストの拡大

 では、ここで実際に例を挙げて発行の手順を見ていこう。

  • STEP1
    CA-Aの主体者の証明書階層 CA-Aが信頼点となっている。

    画面2 階層モデルによる信頼関係

  • STEP2
    CA-BはCA-Aの主体者の信頼者(トラストアンカー)でないためCA-Bの主体者の証明書は、CA-Aの主体者から信頼されない。

    画面3 信頼されていない主体者

  • STEP3
    CA-A⇒CA-Bへの相互認証証明書を発行すると、CA-BはCA-Aの中間認証者であるかのように信頼階層が構築される。このモデルの場合、CA-Bが証明書発行要求を作成し、CA-Aが署名することにより相互認証証明書が発行される。

    画面4 相互認証による信頼関係の拡張

  • STEP4
    CA-A⇒CA-Bへの相互認証証明書をインストールすると、CA-Bの主体者の信頼点がCA-Aとなり、CA-Bの主体者を信頼することが可能となる。

    画面5 相互認証による他主体者の信頼


     以上の手順により、CA-A⇒CA-Bの信頼関係が相互認証により構築 されたことがお分かりいただけたかと思う。 最後にCA-Aの主体者の中間証明機関(CA-A⇒CA-B相互認証証明書) および発行された相互認証証明書を以下に示す。

    画面6 中間証明機関としてインストールされた相互認証証明書

    図3 発行された相互認証証明書拡大

   ブラウザにプリインストールされているトップCAを信頼する
 ―― Webモデル

 Webモデルは一般に広く利用されているブラウザ(Internet ExplorerやNetscape Communicator)にプリインストールされているトップCAを信頼するモデルである。信頼といっても信頼点を利用者が選択できるわけではない。

 利用者は各ブラウザメーカーの信頼点選定基準を満たした信頼点を信頼することしかできない。マイクロソフトではWindowsXPで新たに「Microsoftルート証明書プログラム」を基準として設けており、Internet Explorerの「信頼されたルート認証機関」に追加するための選定基準として「WebTrust for CA」またはこれらの認証局監査基準と同等の基準を満たす必要があるとしている。

 このようにWebモデルではあらかじめ信頼点がブラウザにプリインストールされているため、SSLS/MIMEを使用するうえで一般利用者にも受け入れやすい半面、信頼点を自分で決められないなどの制約も存在する。

 なお、企業などで運用するプライベートCAなどのルート証明書を追加して利用するケースもあるが、このような利用方法はWebモデルとは呼ばれない。あくまで事前にインストールされた認証者を信頼するモデルをWebモデルと呼んでいる。

画面7 Webモデルとしてインストールされている認証機関

 以上で、「信頼モデル」について解説を終了したいと思う。信頼モデルは、PKIによる電子認証基盤を構築する際に必須の知識である。信頼モデルの選択が信頼関係構築のポイントとなり、この選択いかんによっては信頼基盤の構築および拡張が行いにくくなるなどの問題も発生する可能性があるといえるだろう。信頼モデルの選択については十分考慮する必要があるということだけは覚えていただきたいと思う。

 次回は公開鍵に基づく信頼について公開鍵の信頼性を中心に解説する予定である。

第2回」へ 第4回」へ

Index

 

第1回 個人認証とは?
  第2回 PKIにおける信頼とは?
第3回 信頼関係構築に必須の「信頼モデル」
  第4回 公開鍵に基づく信頼
  第5回 第三者認証

関連記事
5分で絶対に分かるPKI
連載:PKIの基礎講座
連載:電子署名導入指南
特集:PKI運用のアウトソーシングの流れ
特集:電子政府の現状と今後
特集:GPKIで実現する電子政府構想(GPKIとはなにか?)

Security&Trust記事一覧

@IT Special

- PR -

TechTargetジャパン

Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Security & Trust 記事ランキング

本日 月間
ソリューションFLASH