〜インターネットセキュリティの切り札〜
連載：PKI再入門
第2回 PKIにおける信頼とは？
久保彰 電子認証局市民ネットワーク福岡 2003/5/3 |
|
連載第1回の「個人認証とは？」では、電子認証の意味や電子認証を実現するうえで必要な暗号化や署名などのテクノロジを見てきたが、今回は、PKI（Public Key Infrastructure：公開鍵基盤）を利用した電子認証の前提となる“信頼”について解説する。
| 個人認証を行ううえで必要な知識 |
PKIにおける信頼を実現するためには、図1に示す信頼関係の構築が必要となる。
 |
| 図1 信頼を実現するための信頼関係の構築 |
それぞれの意味合いについては、後述していくのでPKIにおける信頼を考える際に図1のような信頼関係を構築する必要があるということだけ覚えておいていただきたい。
 |
PKIを理解または利用するうえで必要とされる概念として“信頼点”がさまざまな文書やインターネット上で必ず取り上げられている。では、この信頼点は何のために必要かをあらためてここで考えていきたいと思う。
そもそも信頼点は、後述する信頼者（検証者）が必要とする概念でありPKIを利用しようとする主体者（加入者）にとっての信頼点はすでに契約により決定されているため、検証者に重要な概念であるといえよう。
信頼点は主体者が提示した公開鍵証明書（PKC：Public Key Certificate）を信頼するか否かを決定するうえで必要な概念である。つまり信頼点は主体者の認証を行った認証者を信頼するか否かを信頼者（検証者）が決定する根拠となるものであるといえる。
では、実際に例を挙げて信頼点の概念を見ていくことにしよう。
 |
| 信頼者が認証者を信頼する（信頼点とする） ことで、信頼者は主体者（加入者）を信頼することが可能となる |
| 図2 信頼できる場合（認証者がTrust Anchorとなる） |
|
| 信頼者が認証者を信頼しない（信頼点としない）場合、信頼者は主体者（加入者）を信頼することができない |
| 図3 信頼できない場合（Untrust） |
図2、図3の例のように信頼点は、通常信頼者により決定され、信頼者ごとに信頼点は異なる。つまり信頼点は不変的なものではなく可変であることが理解できると思う。
|
主体者は、信頼点（認証者）との契約行為を前提にした信頼である。主体者は契約することにより、認証者に主体者自身の公開鍵証明書の発行を依頼するため契約の前提には信頼が必ず発生するため、主体者と認証者とは契約行為に基づく信頼関係が存在する。
しばしばPKIで主体者をSubscriber（登録者）と表現する理由は、この契約に基づく本人の登録行為によるものと考えることができる。
|
信頼者（検証者）は、主体者の提示した公開鍵証明書についてその証明書を信頼するか否かを判断する必要があります。この信頼する／しないの判断の基準として主体者の公開鍵証明書の発行者が信頼できるかが重要なポイントとなる。つまり信頼者（検証者）は自分の信頼する信頼点（認証者）から発行された公開鍵証明書を持つ主体者は信頼することができ、そうでない公開鍵証明書を持つ主体者は信頼できない。
ここで注目すべき点は、信頼者（検証者）は主体者を直接信頼しているわけではなく、信頼しているのはあくまでも認証者になります。主体者の信頼は認証者を信頼することによってもたらされるため、PKIの信頼が間接信頼（つまり第三者信頼）といわれるゆえんがここにある。
しかし信頼者（検証者）は、主体者の提示する公開鍵証明書を無条件で信頼するわけではありません。信頼者（検証者）はその名前のとおり主体者の公開鍵証明書を検証する必要があるのだ。また、検証に関するプロセスはRFC3280（Basic
Path Validation）として公開されているためそのプロセスを参照してほしい。
ここでは簡単に検証のためのプロセスを紹介する。
（1）パス構築
| （a）主体者の公開鍵証明書を基点にして、すべての認証者の公開鍵証明書を取得 |
| （b）主体者の公開鍵証明書の最終認証者が信頼者（検証者）の信頼点であるか？ |
（a）の証明書検索に関してRFC3280では主体者の公開鍵証明書（n）と認証者の公開鍵証明書（1、2、……n-1）の検索方法として（1、2、……n-1）中の証明書（x）に対し（x）のSubjectが（x＋1）のIssuer（発行人）であることを利用した検索方法が定義されている。
 |
| 図4 主体者の公開鍵証明書を基点にして、検索する場合 |
主体者の公開鍵証明書を基点にして、逆順に検索する場合は、（x）のIssuerが（x−1）のSubjectであることが理解できるだろう。
 |
| 図5 主体者の公開鍵証明書を基点にして、逆順に検索する場合 |
（b）では最終的に検索された1番目の認証者の公開鍵証明書が検証者の信頼点であるかどうかをチェックする。1番目の信頼者（検証者）の証明書が、信頼者（検証者）の信頼点でない場合はパス構築が失敗し、その結果として主体者の公開鍵証明書は信頼されない。
 |
| 図6 証明書パスの構築が成功する場合 |
 |
| 図7 証明書パスの構築が失敗する場合 |
（2）証明書検証
（1）で構築されたパス中のすべての公開鍵証明書は、検証時点において以下の条件を満たす場合のみ、主体者の公開鍵証明書を信頼することが可能となる。
| （a）有効期限内である |
| （b）公開鍵証明書が改ざんされていない（認証者の公開鍵証明書により署名検証が成功） |
| （c）失効されていない（証明書失効リストに記載されていない） |
上記（1）（2）のプロセスを経て問題がなければ、主体者の公開鍵証明書は信頼することができる。もし検証過程で期限切れや失効状態であることが検出されれば証明書検証は失敗し、その公開鍵証明書は信頼されない。
このように信頼者（検証者）が行う作業は非常に煩雑であり、主体者になるよりも信頼者（検証者）になるほうが検証に対して非常に大きな労力が必要となる。特に現在運用が開始されつつあるGPKI（政府PKI）やLGPKI（地方自治体PKI）と民間の発行サービスが接続された場合を考えると検証の複雑さはさらに増していくことが容易に予想できるだろう。
そこで信頼者（検証者）に多大な労力とコストを強いる検証作業を代替するための仕様がIETF-PKIX PKIX
Working Groupにて検討されている。RFC3379（Delegated
Path Validation and Delegated Path Discovery Protocol Requirements：DPV／DPD）が作成されている。このDPV／DPDはサーバによる検証を行うためのプロトコル仕様であり、信頼者（検証者）は受け取った公開鍵証明書の検証をこのDPV／DPDサーバに依頼することで検証作業を簡素化することが可能となる。現在はDPD／DPVを実装した製品やサービスは出ていないが今後に期待したい。
またIETF-PKIXではSimple Certificate Validation Protocol（SCVP）が検討されており、公開鍵証明書の有効性確認のためのプロトコルであるOCSP（Online
Certificate Status Protocol：RFC2560）をベースにした拡張プロトコルも検討されている（現在はドラフト）。
そのほかにもDCSP（Data Certification Server Protocol：RFC3029）がある。この仕様は公開鍵証明書だけではなく、ディジタル文書の真正性や電子公証といった範囲の検証までをターゲットに設定している。一般にはDVCS（Data Validation and Certification Service）と呼ばれるもので一部のベンダよりサービスが提供され始めている。
| ● RFC Delegated Path Validation and Delegated Path Discovery Protocol Requirements http://www.ietf.org/rfc/rfc3379.txt ●Internet Draft SCVP：Simple Certificate Validation Protocol http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-12.txt DCSP：Data Certification Server Protocols http://www.ietf.org/rfc/rfc3029.txt DPV and DPD over OCSP http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-dpvdpd-00.txt CVP：Certificate Validation Protocol（証明書検証プロトコル） http://www.ietf.org/internet-drafts/draft-ietf-pkix-cvp-02.txt |
信頼者（検証者）はPKIにおける信頼を構築するうえで重要な役割を担っており、検証作業の簡素化が電子認証基盤の成否を握るということが理解できたかと思う。電子認証基盤の成否を検証者が握っているといっても過言ではないだろう。
◇
次回は、信頼モデルについて詳しく解説する。
 「第1回」へ |
「第3回」へ |
|
||||||||||||
| 関連記事 | |
| 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）対策の観点から考える。
 |
|
|
|
|
