〜インターネットセキュリティの切り札〜
連載:PKI再入門
第3回 信頼関係構築に必須の「信頼モデル」
久保彰 電子認証局市民ネットワーク福岡 2003/6/12 |
|
「第2回 PKIにおける信頼とは」までは、PKIにおける信頼とは何かということを中心にして、PKIにおける信頼関係を構成するうえで必要な概念の解説を行ってきた。今回はPKIにおける信頼関係を構築するために必要となる信頼モデルについて解説をする。
PKIにおける信頼を構成する各エンティティ(認証者、主体者、信頼者)によりさまざまな信頼関係が形成される。これらが形成する信頼関係を総称して信頼モデルと呼んでいる。
PKIの信頼モデルには、大きく分けて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での実行結果を以下に示す。
|
|
リスト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モデルではあらかじめ信頼点がブラウザにプリインストールされているため、SSLやS/MIMEを使用するうえで一般利用者にも受け入れやすい半面、信頼点を自分で決められないなどの制約も存在する。
なお、企業などで運用するプライベートCAなどのルート証明書を追加して利用するケースもあるが、このような利用方法はWebモデルとは呼ばれない。あくまで事前にインストールされた認証者を信頼するモデルをWebモデルと呼んでいる。
画面7 Webモデルとしてインストールされている認証機関 |
◇
以上で、「信頼モデル」について解説を終了したいと思う。信頼モデルは、PKIによる電子認証基盤を構築する際に必須の知識である。信頼モデルの選択が信頼関係構築のポイントとなり、この選択いかんによっては信頼基盤の構築および拡張が行いにくくなるなどの問題も発生する可能性があるといえるだろう。信頼モデルの選択については十分考慮する必要があるということだけは覚えていただきたいと思う。
次回は公開鍵に基づく信頼について公開鍵の信頼性を中心に解説する予定である。
「第2回」へ | 「第4回」へ |
|
関連記事 | |
5分で絶対に分かるPKI | |
連載:PKIの基礎講座 | |
連載:電子署名導入指南 | |
特集:PKI運用のアウトソーシングの流れ | |
特集:電子政府の現状と今後 | |
特集:GPKIで実現する電子政府構想(GPKIとはなにか?) |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ (2017/7/24)
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に (2017/7/11)
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは (2017/7/10)
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から (2017/7/5)
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃(APT:Advanced Persistent Threat)対策の観点から考える。
|
|