「第1回 Webサービスのセキュリティ概要」では、Webサービス・セキュリティのフレームワークを述べ、「第2回 XMLデジタル署名とXML暗号」では、XML署名とXML暗号について述べた。今回は、XMLデジタル署名とXML暗号を処理する際に必要な鍵情報の、登録と検証を、外部のサービスに依頼する仕組みを定めたXKMSと、これらの情報を伝達するためのXMLプロトコルSOAPについて述べる。
XKMSは、XML署名やXML暗号を処理するために必要である複雑な鍵管理の処理を外部に委託することで、Webサービスのセキュリティ・アプリケーションを容易に開発することを可能にする。SOAPはセキュリティのプロトコルではないが、Webサービスのセキュリティのプロトコルを、エンベロープ（付加情報）に包み伝達することができる汎用的なXMLプロトコルである。
ここではWebサービスのセキュリティのプロトコルとSOAPのバインディング方法について簡単に述べておくことにする。
編集注 本記事では、PKIに関連した用語や仕組みが前提知識として解説されております。詳細に関しましては、PKI関連記事もあわせてご参照ください。
XML鍵管理サービス（XKMS）
●XKMS (XML Key Management Specification) の概要
Webサービスのセキュリティの基本はXML署名とXML暗号である。これらを処理するために鍵情報の処理と管理が必要になる。鍵を正しく登録（公開鍵証明書発行）する方法や、XML署名の有効性を検証するためには、PKIのクライアント機能による複雑な処理が必要になる。XKMSの目的は、署名や暗号を扱うWebサービスのアプリケーションから、これらの複雑な処理を外部のサービスに依頼し、アプリケーションの開発を容易にすることである。XKMSの最新の仕様はXKMS 2.0で、W3Cで現在策定中の仕様であるが、ここではこの2.0のバージョンに沿って説明する。
XKMS 2.0（XML Key Management Specification） には、以下に示すように2つのサービスと1つの拡張がある＊1。
| X-KISS（XML Key Information Service Specification） | 鍵情報の有効性検証サービス | X-KISSは、XML署名やXML暗号を用いるアプリケーションから、鍵情報に関する処理を外部サービスに依頼するためのプロトコルである。このサービスには必要な鍵情報の所在を知らせることや、鍵情報の有効性検証を委任することが含まれる。 |
|---|---|---|
| X-KRSS（XML Key Registration Service Specification） | 鍵情報の登録（公開鍵証明書発行）、失効サービス | X-KRSSは、公開鍵ペアの所有者の公開鍵を登録し、公開鍵と所有者の結合（KeyBinding：PKIでの公開鍵証明書発行）を依頼するためのプロトコルである。この登録情報はX-KISSでの鍵情報検証や、次回に述べるSAMLなどのサービスに用いられる。 |
| X-Bulk（XKMS Bulk Operation） | 鍵情報のバルク登録サービス | X-BULKは、ICカード管理などで大量に暗号鍵の登録が行われるときに使われることを想定している。 |
| XKMS 2.0（XML Key Management Specification）のサービス仕様とバルク登録の拡張サービス仕様 | ||
＊1 参照 W3C XML Key Management WG http://www.w3.org/2001/XKMS/
●X-KISS（鍵情報サービス）
公開鍵を用いて、署名検証や、文書を暗号化するための対称鍵の暗号化を行うためには、相手の公開鍵の有効性を検証しなければならない。このためにPKIでは、クライアントアプリケーションは相手の証明書から自分のトラストアンカーのCA（認証局）までの証明書チェーン（認証パス）を構築し、チェーン上にあるすべての証明書が正しいか、失効されていないかを検証しなければならない。この有効性検証はX.509v3証明書や失効情報（CRLやOCSP）の複雑な構文を解析する難しい処理となる。
X-KISSは鍵情報（証明書）の有効性検証を行うために、「第2回 XMLデジタル署名とXML暗号」に述べたXML署名の＜ds:KeyInfo＞要素の処理を、クライアントアプリケーションから信頼できるサービス（Trust Service）に委託するものである。アプリケーションはASN.1でのX.509証明書の構文解析、PKIXの認証パスの処理や証明書の失効の検証を外部サービスに委託することで複雑なPKI処理から解放される。アプリケーションがシンプルになることによって、その信頼性も向上するメリットもある。
IETFのPKIXワーキンググループでは、証明書の検証を外部サーバに委託するためのDPD、DPV、CVPやSCVP2などのプロトコル＊2を策定中である。X-KISSのTrust ServiceのサーバもバックエンドでこれらのPKIXの環境を利用するかもしれない。
＊2 参照 IETF PKIX Working Group
DPD：Delegated Path Development（認証パス構築）
DPV：Delegated Path Verification（認証パス有効性検証）
CVP：Certificate Validation Protocol（証明書検証プロトコル）
SCVP：Simple Certificate Validation Protocol http://www.ietf.org/html.charters/pkix-charter.html
通常、署名者が提供する署名情報には、署名の検証者にとって必要な関連するすべての鍵情報や失効情報は含まれていないことが多い。署名検証者は不足した情報の収集と検証をX-KISSのサービスに任せることにする。またXML暗号を用いるアプリケーションは暗号文の受取人の公開鍵情報を知らないかもしれない。この場合も受取人の公開鍵情報とその有効性をX-KISSのサービスに問い合わせることができる。
X-KISS仕様で、アプリケーションの要求する異なったレベルの問い合わせ処理に対応できるように、Tier 0、Tier 1、Tier 2と3つの処理レベルを用意している。
- Tier 0 ＜ds:RetrievalMethod＞処理
Tier 0のアプリケーションは、Tier 1やTier 2のようなTrust Serviceを利用せず、＜ds:KeyInfo＞の＜ds:RetrievalMethod＞で指定されたサーバから直接鍵情報（X.509証明書）を入手し処理することになる。この場合、ASN.1ベースのX.509証明書の構文解析と検証をクライアント自身が行わなければならない。従って、このサービスはクライアントにとって負担が大きい。
- Tier 1 Locateサービス
Tier 1 LocateサービスはTrust Serviceとしてクライアントが指定した＜ds:KeyInfo＞要素の鍵情報を解決する。しかし、鍵情報の有効性検証のサービスは行わない。
Trust Serviceは＜ds:KeyInfo＞要素の解決のために図1に示すように＜ds:KeyInfo＞要素の＜ds:RetrievalMethod＞が指定するローカルデータまたは外部サーバからX.509証明書を検索する。Locateサービスでは図2のようなクライアントとTrust Serviceの要求と応答のプロトコルを規定している。
XML署名の検証の場合、クライアントは署名者からXML署名文書を受け取る。クライアントはTrust Serviceに対して、XML署名にある＜ds:KeyInfo＞要素の＜ds:RetrievalMethod＞要素を指定して署名者の鍵の名前と公開鍵の値を要求する。Trust ServiceはURIで指定するWebディレクトリからX.509証明書を取得して構文解釈を行い、クライアントに鍵の名前（署名者の名前）と署名を検証するための公開鍵を返す。
クライアントとTrust Service（X-KISS）の要求と応答のプロトコルを以下の図2と図3に示す。要求プロトコルは図2に示すように証明書の参照情報を提供する＜Query＞ブロックと、応答として返してほしい値を指定する＜Respond＞ブロックからなる。
応答のプロトコルは図3に示すように、処理結果の状態を示す要素と要求に対する答えを示す要素からなる。処理が不成功になった場合は要素のみが返され＜Answer＞要素は含まれない。
Trust Serviceはバックエンドで検索したX.509証明書の内容から鍵の名前（署名者の識別名：DN）と公開鍵の値を抽出し、＜ds:KeyName＞と＜ds:KeyValue＞をクライアントに返す。暗号文の送付の場合もクライアントはあて先の公開鍵を同様な要求／応答プロトコルで入手する。
- Tier 2 鍵情報の有効性検証（Validate）サービス
Tier 2のTrust Serviceは図4に示すように、Tier 1のサービスに加えてクライアントが要求する証明書の拡張領域に関する情報や、失効も含めた公開鍵の有効性に関する状態をバックエンドのPKIサービスで検索し、その結果を解析して値をクライアントに返す。
Tier 2の有効性検証は鍵情報の有効性に関するすべての検証をTrust Serviceに委託する。従ってクライアントは、バックエンドのPKIの複雑な処理から一切解放されることになる。以下に署名検証のためのクライアントとTrust Serviceの要求／応答の例を示す。Validateサービスの要求は図5に示すように、指定した鍵の名前と値の結合が信頼でき有効であるかを問い合わせる。
Validateサービスの応答は図6に示すように、結果の状態を示す要素と要求に対する結果を示す要素からなり、要素の子要素には名前と鍵の結合の状態を示す要素に、有効か否かを示すステータスと証明書の有効期間などを含めて答える。
- Trust Serviceへの要求と応答
Trust Serviceへの要求には＜Query＞要素に問い合わせるべき＜ds:KeyInfo＞の内容を指定し、＜Respond＞要素に公開鍵の名前と鍵の値を指定する。
Trust Serviceからの応答には、結果＜Result＞要素にTrust Serviceの操作の結果を示す。この結果コード（ResultCode）に表1に示すコードが返される。
| Success | 操作は成功した |
|---|---|
| NoMach | 要求に合うものがない |
| Incomplete | 要求の一部にしかこたえていない |
| Failure | 操作は失敗した |
| Refused | 操作を拒否した |
| Pending | 操作は将来の処理のためにキューに入れた |
| 表1 結果コード（ResultCode） | |
成功した応答には＜Answer＞要素に結果が返される。Tier 1のLocateサービスは鍵の名前と鍵の値が返されるが、鍵の有効性の検証は行わない。それに対して、Validateサービスでは証明書の内容の検証と失効情報の検証が行われる。従って、＜Answer＞要素にKeyBindingの状態のコードが返される。このコードは＜Status＞要素に示され、表2に示すコードがある。
| Valid | Key Bindingは正しい（鍵は有効である） |
|---|---|
| Invalid | Key Bindingは不正である（鍵は無効である） |
| Indeterminate | Key Bindingは検証できなかった（データが不足しているなど） |
| 表2 ステータスコード | |
- Trust Service応答の有効性
Tier 1とTier 2サービスのクライアントはTrust Serviceの応答の有効性を必ず検証しなければならない。すなわち、応答は正しいTrust Serviceからのものか、応答メッセージは改ざんされていないか、応答は要求に対応したものかをクライアントは確かめなければならない。このためにはXML署名付きの応答とするか、TLSまたはIPsecのセキュリティ環境を用いなければならない。
●X-KRSS（鍵登録サービス）
鍵登録サービスは、公開鍵証明書の発行に関連するサービスである。PKIでいうRA (Registration Authority)に相当するサービスである。このサービスには公開鍵の登録（公開鍵証明書発行）要求、鍵の失効要求、鍵のリカバリ要求に対するサービスがある。鍵登録サービスはクライアントの要求を受け付け、バックエンドのPKI環境（RA／CA）に、鍵登録に関する要求を依頼し、鍵情報とともにクライアントにその結果を返すサービスである。
IETF PKIXではこれらのサービスを行うために、クライアントとRA／CAとの要求／応答のためのASN.1で規定したプロトコルCMP（Certificate Management Protocol：RFC2510）を定めている。X-KRSSはこれと同等なプロトコルをXMLプロトコルで規定するものである。図7にX-KRSSの鍵登録サービスの例を示す。
●鍵登録サービス
鍵の登録（証明書発行）要求を行うクライアントは、事前に鍵登録サービスからセキュアに鍵登録サーバにアクセスする権限を得るためのアクセス承認コードをout-of-bandで入手しておく。鍵登録要求はこのアクセス承認コードを鍵登録サービスに提示することで、サーバはクライアントのアクセスを認めることができる。
鍵登録サービスでは、クライアントは＜Register＞要素の＜Prototype＞要素に公開鍵と所有者名を示し、＜AuthInfo＞要素にアクセス承認コードを含む認証情報を提示する。鍵登録サービスは応答として＜RegisterResult＞要素を返す。ここに証明された＜KeyBinding＞要素として証明書を含むクライアントのクレデンシャル（信用情報）が返される。
鍵登録サービスには2つのサービス形態がある。クライアントが生成した鍵を登録する方法とサービス側で生成した鍵で登録する方法である。
●クライアント生成鍵の登録
クライアントが生成した鍵を登録するには、図8に示すように＜Register＞要求の＜Prototype＞に＜ds:KeyInfo＞要素に登録すべき公開鍵と所有者名を示し、＜AuthInfo＞に所有する私有鍵と公開鍵の対応（PoP：Proof of Possession）を示すための署名を行い、この要求が正当に承認されたものからのものであることを示すために、事前にセキュアに入手した承認コード、例えば“024837”をハッシュ関数で処理した値“Auth”による認証情報を含めている。
要求者の認証は、秘密の承認コード“024837”と認証要求の識別子Authを用いて行われる。ここで、
Auth ＝ HMAC-SHA1(“024837”, 0x1)＊3で、
f(m,k)は、fの方式でメッセージmをkで署名することを示している。
鍵登録サービスはこの要求を承認し、以下のような応答＜RegisterResult＞>を返す。この例では発行されたX.509証明書がWebベースのディレクトリ、URI＝“http://www.PkeyDir.test/Certificate/01293122”に置かれていることを示している。
＊3HMAC-SHA1（ハッシュ関数SHA1ベースのメッセージ認証コード：RFC 2104）Hをハッシュ関数（SHA1）、Kを秘密鍵、MをメッセージとするとHMAC-SHA1の定義式は以下のようになる。ここで、ipad、opadは定められたパディング値でxorは排他ORの操作を示す。
HMAC-SHA1(K, M)＝H(K xor ipad, H(K xor opad, M))
●サービス側生成の鍵ペア登録
サービス側で鍵ペアを生成する場合、生成した鍵ペア（公開鍵と私有鍵）をセキュアに正当な要求者に渡さなければならない。
登録要求の＜Prototype＞要素には＜KeyInfo＞要素の鍵所有者名のみを指定する。認証情報＜AuthInfo＞要素には、＜ProofOfPossession＞要素は必要とせず、要求者の認証情報として事前にout-of-bandで入手した承認コードを用いたHMACが与えられる。
サービス側の応答には、＜answer＞要素の＜KeyInfo＞要素にサービス側で生成した公開鍵と鍵所有者名が返される。そして、＜Private＞要素に私有鍵を承認コードから生成した暗号鍵（対称鍵）で暗号化した値が返される。要求者は自分が所有する秘密の承認コードで生成した暗号鍵（対称鍵）で復号し安全に自分の私有鍵を得ることができる。
●失効要求
鍵登録サービスには、クライアントからの要求ですでに発行した証明書（KeyBinding）を失効させるサービスを含めてもよい。
失効要求の＜Prototype＞には失効させるべき公開鍵と鍵所有者名を指定する。認証情報として＜AuthInfo＞には＜Prototype＞要素にデジタル署名をして鍵の正当な所有者であることを主張する。サービスからの応答には失効が正当に受け付けられたというメッセージが返される。
●鍵リカバリ
利用者は自分の所有する私有鍵を紛失したり、私有鍵にアクセスするためのパスワードやPINを忘れてセキュリティ操作ができなくなってしまうことがある。私有鍵が暗号の復号鍵であった場合、暗号化されたデータは永久に復号できなくなってしまう。このような事態を解決するために、サービス側で私有鍵をバックアップしておき、利用者の要求で鍵のリカバリサービスを行う必要性が生じる。
鍵登録サービスには、このような要求にこたえるために、クライアントからの要求で私有鍵を回復させるサービスを含めてもよい。鍵リカバリの要求者は、まず鍵リカバリ管理者に連絡しout-of-bandで鍵リカバリ要求の承認コードxxxを入手する。鍵リカバリ要求は＜Prototype＞に鍵所有者名を指定し、＜AuthInfo＞に要求者の認証のために承認コードxxxを用いたHMACの値を用いる。そして私有鍵のリカバリを要求する。
サービスの応答は、要求者を認証した後に私有鍵をリカバリし、承認コードに関連させた暗号鍵で私有鍵を暗号化して返す。鍵リカバリサービスは署名用の私有鍵のリカバリサービスに用いることは好ましくない。署名鍵は唯一所有者のみが保持すべきでバックアップした場合、否認防止の効果が疑われることになるかもしれないからである。署名鍵は紛失した場合には再発行すべきである。
●XKMS Bulk Operation（X-Bulk）
鍵登録サービス（X-KRSS）は1つの鍵の登録プロトコルを定義したものである。しかし、サービス側においてICカードの一括発行や大量な証明書のバッチによる発行要求も存在する。
1つの鍵登録とバルク登録では処理の認証方法が異なるので、W3Cではバルク登録のための仕様を別途開発している。X-BulkがX-KRSSと異なるところは、要求や応答に＜batchHeader＞要素でバッチ番号や日付や登録数などを定義し、その後に個々の登録要求のリストが並べられる。そしてこのバルク登録要求とバッチ処理応答に対してデジタル署名を付ける形式をとっている。詳しくはW3CのXKMSのWebサイト＊4を参照のこと。
「第2回」へ
Copyright © ITmedia, Inc. All Rights Reserved.