電子政府情報セキュリティ相互運用支援技術の開発
− Chal l engePKI 2002 プロジェクト −
石垣陽
**稲田龍
+漆島賢二
**澤野弘幸
*篠田和幹
***島岡政基
**林田秀和
**増田健作
++松本泰
**村山麻子
**安田直義
+++吉田裕之
**若山公威
****オレンジソフト株式会社 **セコムトラストネット株式会社 ***名古屋工業大学 +富士ゼロックス株式会社
++富士ゼロックス情報システム株式会社 +++NPO 日本ネットワークセキュリティ協会(JNSA)・株式会社ディアイティ 要旨：政府認証基盤(GPKI)で採用されているブリッジモデルは、高度な相互運用技術が要求され、GPKI 対応アプリケーション開発 の妨げになっていると考えられる。そこで本プロジェクトでは、(1) GPKI に関わる仕様・標準の解説、(2) GPKI のテスト環境とテ ストケース、(3)アプリケーション開発の参考となるサンプル実装、の３つを開発・公開した。さらに、これらの成果を IETF などの 標準化団体へフィードバックした。今後は、テスト環境の海外への配布、テスト標準化の提言、テストケースのInformational RFC 化などを検討している。Challenge PKI 2002 プロジェクトの成果は、PKI/GPKI のアプリケーションの開発の促進と、世界レベルで の標準化の策定の促進に寄与するものと期待している。
１． はじめに
日本政府は､行政手続きの効率化と国民負担の軽減を目 標に、国民と行政機関の間の申請・届出・通知などといっ た手続きを電子化する「電子政府」の構築を目指している。 そのセキュアな情報流通の基盤として構築されている政 府認証基盤(GPKI) [GPKI]では、ブリッジモデルと呼ばれる 信頼モデルが使用されている（Fig.1）。ブリッジモデルは、 主体者が異なるマルチドメイン PKI を実現する手段とし て柔軟性のあるモデルであるが、その反面、ドメイン間で の相互運用性を確保するために高度な技術を要する。
電子政府における共通の認証環境として GPKI が機能 し、多くのユーザに利用されるためには、以下が必要だと 考えられる。
・ 相互運用性が確保された PKI/GPKI 対応電子政府アプ リケーション開発が活発に行われる。
・商用製品として、使いやすくセキュアな電子政府対応ア プリケーションが流通する。
Fig.1 GPKI のブリッジ型信頼モデル[GPKI]
しかし現在、相互運用性が確保されたアプリケーション 開発を行おうとすると、参考になる実装、テスト環境ある いは開発環境がないという状況に直面する。本プロジェク トでは、この状況を打開することが、GPKI を機能させる ための課題と捉えた。
GPKI 相互運用性の課題を解決することで、GPKI 対応 の電子政府アプリケーションの開発を促進し、その結果、 GPKI を認証基盤とした広範囲なセキュリティを適正コ ストで実現できることにつながると考えられる。
本稿は、この課題に取り組むべく、情報処理振興事業協 会（IPA）が「情報セキュリティ関連の調査・開発」のテ ーマのひとつである「電子政府情報セキュリティ相互運用 支援技術の開発」として公募した開発の成果を概観したも のである。
２． 研究開発の目標と内容
ChallengePKI2002 プロジェクトでは、以下の３つを開 発・公開することを目的とする。
(1) GPKI に関わる仕様・標準の解説（報告書） (2) GPKI のテスト環境とテストケース
(3)アプリケーション開発の参考となるサンプル実装
諸外国で既に行われているPKI 相互運用実験としては、 EEMA イニシアチブが推進する、PKI チャレンジ(pkiC) が挙げられる。pkiC では、異なるポリシを持つ組織間で セキュアなメッセージ交換を実現するためのフレームワ
アプリケーション
暗号技術 共通鍵暗号 公開鍵暗号 ハッシュ関数・乱数生成 標準化技術 X .509 R F C 3280 実装技術 J DK / J C E C ryptoAP I 相互運用
テスト が必要
テスト ケース
報告書 相互運用
テスト スィート
相互運用テストフレームワーク C ryptoAP I
J DK 1.4/ J C E を拡張した サンプル実装
電子政府 アプリケーション
電子政府 アプリケーション
Fig.2 ChallengePKI2002 の範疇
ーク作成が進められている[PKIC]。また米国政府は、ブリッ ジCA モデルにより、政府と民間との PKI の相互運用性 の可能性に着目し、政府とベンダが協調してブリッジCA モデル の PKI 環境を開発し、検証事業を支援している
[BCATD]。日本国内においては、電子政府に関する暗号技術
の議論[CREC]や、電子政府対応アプリケーションの実証実
験[EGOV]が行われている。しかし、X.509 や RFC3280 な
どの汎用的な標準化技術と、GPKI アプリケーションのた めの実装技術との相互運用性に関する調査・開発は少ない。
Fig.2 に、本プロジェクトの位置づけを示す。本プロジ ェクトは、GPKI 対応アプリケーション開発時に参考とな る実装とテスト環境を整備することで、GPKI に対応した アプリケーションの開発が促進されることを目標とする。
３． 本年度の活動状況
３．１ GPKI に関わる仕様・標準の解説
GPKI に対応したアプリケーションを開発する際に必 要となる仕様・標準として、以下の６つの点に着目した報 告書を作成した。
(1) パス構築・検証
(2) パス構築・検証のテストクライテリアの動向 (3) CRL/及び OCSP による失効検証
(4) GPKI 相互運用性仕様書
(5) パス構築・検証サーバなどの新しいモデル (6) パス構築・検証クライアントの実装方法
(1)では、証明書・CRL に関する ITU-T の最新仕様であ るX.509 4th Edition [X509.4]と、IETF PKIX-WG の
Fig.3 X.509、RFC3280 及び GPKI 証明書プロファイル
RFC3280 [RFC3280]との違いに注目した（Fig.3）。両者はほ ぼ同じ目的で作られた仕様だが、パス構築・検証の実装を 進める上で微妙な違いがあり、GPKI アプリケーションの 開発者はこの違いを把握する必要がある。報告書では、以 下の３つの視点から、両仕様の違いについて説明した。
・パス構築に必要なディレクトリスキーマ
・リポジトリへアクセスするプロトコル
・認証パス構築とポリシ検証のアルゴリズム
(3)では、両仕様において、CRL を用いた証明書の失効 検証アルゴリズムの違いを説明し、さらに OCSP(オンラ インによる証明書の状況確認プロトコル) [RFC2560]におけ る要求・応答手順と信頼性モデルについて説明した。
(4)では、GPKI 相互運用性仕様書[GCSPEC]についての解 説を行った。GPKI は米国の連邦公開鍵基盤(FPKI)を参考 につくられたモデルであり、府省・民間CA が相互認証す るために、ブリッジCA を介している。そのため、異なる PKI ドメインを経由した相互認証が要求され、Fig.3 に示 すGPKI の枠組みの中で、共通の仕様に従った処理が必要 となる（Fig.4）。
Fig.4 BCA を介する相互運用性の概念図
申請者
申請文書 (署名文書）
証明書検証サーバ
官職E E 署名検証 民間C A
OC S P レスポンダ
統合リポジトリ 民間ＣＡリポジトリ
LDAP
LDAP
ＯＣＳＰ
L DA P アクセス機能 OC S P アクセス機能
証明書パス構築 証明書パス検証
証明書検証サーバアクセス
OC S P +独自拡張 証明書検証サーバは、
E E からの証明書の検 証要求に、自分の署名 を付けて応答する。
Fig.5 証明書検証サーバ(GCVS)の構成
そこで(4)では、GPKI を構成するコンポーネントとアプ リケーションにおいて、相互運用性を確保するために必要 となる主な機能要件をそれぞれ示した。
(5)では、証明書や CRL/ARL 等の必要な情報を利用者 に代わって収集し、認証パス構築・検証をサーバサイドで 行うプロトコルの要件であるDPV/DPD [RFC3379]について 説明した。さらに、DPV/DPD の実装プロトコルとして、 IETF により DPV/DPD の実装として採用された SCVP を 初めとする、５つのプロトコルについて解説した。
さらに、GPKI で既に用いられている証明書検証サーバ
（Fig.5）についても取り上げ、OCSP の拡張である専用 プロトコルについて、詳しく説明した。
３．２ GPKI のテスト環境
本プロジェクトでは、GPKI のテスト環境として、任意 の仕様の認証局を複数模擬することができる、汎用的な相 互運用テストスイートの開発を行った（Fig.6）。
このテストスイートは、GPKI で要求される任意のプロ ファイルの証明書、CRL/ARL 及び OCSP レスポンダメッ セージを生成することができ、GPKI の認証局であるブリ ッジ認証局、既存の府省認証局、民間認証局及び商業登記 認証局の全てを模擬することができる。
テストスイートは、テスト結果の集積についても考慮さ れている。Fig.6 に示す通り、テストスイートを利用して 様々な実装をテストすることで、結果レポートを蓄積する ことが可能である。その結果レポートを元に標準・仕様へ のフィードバックを行い、標準・仕様の変更に応じてさら にテストケースを修正することで、GPKI テスト環境の開 発サイクルを形成することができると考えられる。
テスト DB
テスト データ 生成
鍵群 C R L 群
証明書群
テスト実行スクリプト テスト対象
（パス検証 コマンド）
テスト結果 データローダ 結果
レポート
テスト 構成ファイル テスト
ケース 編集 ツール
テスト 結果 テスト
ケース テスト ケース
GP KI テスト ケース
標準や相互運用 のための仕様書 R F C 3280
X .509 GP KI相互運用仕様書
etc .
標準への フィードバック
実装への フィードバック テストケースを順次
追加できる構造
Fig.6 相互運用テストスイートの概要
Fig.7 テストケースの編集画面（画面は日本語版）
テストケースの編集機能は、Fig.7 に示すユーザインタ フェースをもち、全ての操作をブラウザから行えるように 設計・実装した。
テストスイートの実行部分はPerl 言語で書かれており、 様々なプラットフォームで利用することができる。現在、 RedHat Linux 及び Windows2000/XP での動作を確認し ている。テストデータ生成プログラムは、名古屋工業大学 岩田研究室と株式会社 CTI によって共同開発された暗号 ライブラリAiCrypto [AiCrypto]を利用して作成した。
３．３ テストケース
本プロジェクトでは、以下に示す３種類のテストケース を開発した。
(1) NIST テストケース（全 130 テストケース）
NIST テストケースは、米国国立標準技術研究所の公表 し て い る FPKI 用のテストケースである、X.509 Path
Validation Test Suite[NIST]を模倣したものである。 各テストにはテストレベル（テストの難易度）が設定さ れており、実装の際の目安となっている。
(2) GPKI テストケース（全 81 テストケース）
GPKI テストケースでは、政府認証基盤における様々な パス検証のシチュエーションが考慮されている。各テスト で用いる証明書及びCRL/ARL は、実稼働している GPKI のリポジトリ等から取得したデータを元に作成されてい る。テストケースによっては、OCSP や GCVS を利用す るものも存在する。27 種類のテストケースそれぞれにつ いて正常系・失効系・期限切れ系の３つのパターンが存在 する構成となっている（Fig.8）。
(3) オリジナルテストケース（全 45 テストケース） オリジナルテストケースは、本プロジェクト独自に開発 したものである。NameRollover や KeyUpdate といった 作業を含む、高度なパス検証を実験するためのテストケー スである（Fig.9）。
Fig.8 GPKI テストケースの構成（正常系の例）
C RL 3000020
Issuer: C A(Printable)
thisUpdate: now
nextUpdate: now+365days
EE証明書 3000299
S ubjec t: EE 01(Any)
Issuer: C A(UT F 8)
公開鍵B 自己署名証明書
3001910
S ubject: C A(UT F 8)
Issuer: C A(P rintable)
公開鍵A 相互認証証明書
3000101
S ubjec t: C A(Printable)
Issuer: T A(P rintable)
公開鍵A
Fig.9 オリジナルテストケースの例※
※Name rollorver のみを行った CA が EE を破棄した場合、発行 した時期に関わらず破棄情報を正しく認識することを確認する。
３．４ GPKI 対応アプリケーションのサンプル実装 本 プ ロ ジ ェ ク ト で は 、Microsoft CryptoAPI 及 び Java/JDK の２種類のコンポーネントを利用し、パス構 築・検証のサンプル実装を行った。Fig.10 に、CryptoAPI、 JDK 1.4 及び GPKI で要求される主な仕様の関係を示す。
Microsoft CryptoAPI と Java/JDK では、セキュリティ フレームワークにおけるプロバイダの形で、パス構築・検 証機能が実装されている。サンプル実装では、このプロバ イダを、GPKI 対応のプロバイダに置き換えることにより、 GPKI の機能を実現した。こうしたサンプル実装を提供す ることで、既存のPKI アプリケーションの GPKI への対 応を、アプリケーション自体の変更なしに行うことができ るようになると考えられる。
GPKI 対応プロバイダには、GPKI 相互運用性仕様書で 要求される以下の３つの機能を実装した。
・X.509 証明書 v3 拡張
・X.509 証明書 CRLv2 拡張
・OCSP による証明書失効検証
Sun の JDK 1.4 では、PKIX(RFC3280)に対応したパ ス検証ライブラリのレファレンス実装が提供されている。 Fig.11 に、パス検証ライブラリと、GPKI に対応したプロ バイダの構成を示す。
Microsoft の CryptoAPI では、暗号モジュールの入れ替 えを、アプリケーションに依存せずに行うことができる。 サンプル実装ではこの方式を利用し、証明書検証に関して、 Revocation Providers と呼ばれるパス検証ライブラリを、 GPKI に対応したものに置き換えた（Fig.12）。
Fig.10 各種実装が提供する機能
0 5 10 15 20 25 30 35 40
03/ 2/ 18 03/ 2/ 25 03/ 3/ 4 03/ 3/ 11 03/ 3/ 18 03/ 3/ 25
日付
ＮＧ数
合計 J ava C ryptoAPI
C ertP athBuilder
C ertific ateF ac tory
X .509 P rovider
C ertP athV alidator
P KIX P rovider
KeyS tore C ertS tore Issuer:C A2
S ubjec t:ボブ ボブの公開鍵
Issuer:C A1 S ubjec t:C A2 C A2の公開鍵
外部のリポジトリ L DAP サーバなど 信頼ポイント
などを格納
V alid Invalid
P KIX プロバイ ダーを拡張した GP KI対応プロ バイダに置き 換え
Fig.11 Java によるサンプル実装
３．５ サンプル実装によるテスト結果
Java と CryptoAPI それぞれのサンプル実装の開発は、 実際にテストスイートを用いて行った。Fig.13 は、それぞ れの実装において、結果がテストの期待値通りとならなか ったケースの数（NG 数）の推移である。テストスイート を利用することで、NG となるパターンが明確化でき、確 実にNG 数を減少させることができた。
Fig.14 に、開発終了時点での、各実装の NG 数を示す。 開発終了時において、CryptoAPI によるサンプル実装で 28 ケース、Java によるサンプル実装で 8 ケースが NG と なっており、これらの原因について考察を行った。
４． 外部発表及び成果物
55th IETF(アトランタ)において、Challenge PKI 2002 のコンセプトを発表し、56 th IETF（サンフランシスコ） においてプロジェクト概要の説明と、テストスイートのデ モンストレーションを行った。
IPA への今年度の納品物件は以下の通りである。
・電子政府情報セキュリティ相互運用支援技術の開発 (PKI 相互運用フレームワークの開発)
Fig.13 NG 数の収束グラフ
MS C ryptoAP I IE
Outlook E xpress
3rd party AP L .
Base C ryptographic
P rovider
R evoc ation P roviders Enhanc ed
C ryptographic P rovider
C ryptographic S ervic e P roviders ( C S P ) 3rd party C ryptographic
P rovider
3rd party R evoc ation
P roviders V P N
c lient 802.1x supplic ant Outlook
OC S P 対応、相互認証証明書ペアを使用したパス構築など に対応したR evoc ation P rovider に置き換える
Fig.12 CryptoAPI によるサンプル実装
５． 今後の課題
本プロジェクトの成果を標準化団体へフィードバック するため、次のことを行う予定である。
・ 実装・テストを通じ、X.509 や RFC3280 に代表され る標準の曖昧さを明確にして、IETF/PKIX などの標準 化団体へのフィードバックを引き続き行う。
・ 2003 年 6 月までに、本プロジェクトの英語版の報告 書を作成し、公開する予定である。
マルチドメイン PKI のテスト環境構築が困難であるの は、日本のGPKI に限ったことではない。相互運用性を確 保するため、世界共通に使用できるテストプラットフォー ムが必要とされている。本成果を広く世界に公開し、多く のコメント・情報交換を受けるため、次のことを検討して いる。
・テストスイートを海外へ配布
・IETF 等へテストの標準化を提言
実装の種類 テストケース NG 数（割合） 合計（割合）
NIST 6 (4.6%) GPKI 3 (3.7%) CryptoAPI によ
るサンプル実装
オリジナル 19 (42%)
28 (11%) NIST 0 (0.0%)
GPKI 3 (3.7%) Java による
サンプル実装
オリジナル 5 (11%)
8 (3.1%) NIST 0 (0.0%)
GPKI 27 (33%) Sun JDK1.4
オリジナル 10 (22%)
31 (14%) NIST 41 (31%)
GPKI 未実施
Windows2000
オリジナル 未実施
41 (31%) NIST 27 (21%)
GPKI 未実施
WindowsXP
オリジナル 未実施
27 (21%) Fig.14 各実装ごとの NG 数
・テストケースのInformational RFC 化
・テストケースのXML 化
・NIST とテストケースの標準化について協議
さらに、今後はGPKI だけでなく、地方公共団体組織認 証基盤（LGPKI）、公的個人認証基盤、更に海外との相互 認証なども視野に入れたテストケース開発を行いたい。
６． まとめ
本プロジェクトでは、GPKI に関わる仕様・標準につい て解説した報告書を作成し、テストスイートとサンプル実 装の開発を行った。さらにサンプル実装によるテストを、 実 際 に テ ス ト ス イ ー ト を 用 い て 行 い 、Java 及 び CryptoAPI による実装上の問題点について考察した。こ れらの成果は56thIETF において発表され、さらに 2003 年6 月には報告書を英語化し、広く公開する予定である。 これによって、テストの実行、標準・仕様へのフィードバ ック、そしてテストケースの更新という、GPKI テスト環 境の開発サイクルを形成しつつあるということができる。
RFC3365 では、IETF 標準プロトコルが適切な強いセ キ ュ リ テ ィ メ カ ニ ズ ム を 利 用 し な け れ ば な ら な い
（MUST）としている。インターネットのプロトコルの多 くは、シンプルさを特長として成長してきた。しかし昨今、 セキュリティは無視できない要件であり、シンプルな標準、 シンプルな実装でプロトタイプの開発を繰り返すといっ た手法だけでは、新たなプロトコルの開発は、困難になっ ている。
そのため、これまでのように、既に実装された製品間で の相互運用実験を行うのではなく、相互運用を達成するた めに、標準自体を検証するための体系を初めから用意する ことが必要だと考えられる。
このような手法を採用すると、標準の曖昧さなどの問題 をより早くフィードバックし、ドラフト段階で、標準の曖 昧さを容易に減少させることができる。さらに、標準の実 装段階において、個々の実装者がテストケースを設計する ことは、負担が大きいだけでなく、独自のテストケースの 氾濫と、標準に対するカバレッジを下げる可能性がある。 テストケースの共有化によって、こうした問題を解決でき
ると考えられる。
電子政府を成功させるためには、国内での仕様を取りま とめていくだけでなく、この仕様を基に、世界での標準の 策定に積極的に関与して行くといったことが重要である。 Challenge PKI 2002 プロジェクトの成果が、PKI/GPKI のアプリケーションの開発の促進、そして、世界レベルで の標準化の策定の促進に寄与できれば、プロジェクトの意 義が確認されることになる。
７． 参考文献
[EGOV] 峯尾・金子ほか：電子申請用認証局のシステム高度化及 び実証実験，IPA 電子政府行政情報化事業報告書，2002 [CREC] 暗号技術評価事業ホームページ,
http://www.ipa.go.jp/security/enc/CRYPTREC/ [PKIC] PKI Challenge ホームページ,
https://www.eema.org/pki-challenge/
[BCATD] US Department of Defense (DoD): BCA Phase II Technology Demonstration, 2001
[X509.4] ITU-T Recommendation X.509 (2000) ISO/IEC 9594-8:2001, Information Systems - Open Systems Inter connection - The Directory: Public key and attribute certificate frameworks, March 2000
[RFC3280] W.Polk, W.Ford, D.Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile,RFC3280,April 2002, http://www.ietf.org/rfc/rfc3280.txt [RFC2560] M.Myers, R.Ankney, A.Malpani, S.Galperin, C.Adams: X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol - OCSP, RFC3280, June 1999, http://www.ietf.org/rfc/rfc2560.txt
[RFC3379] D. Pinkas, R. Housley: Delegated Path Validation and Delegated Path Discovery Protocol Requirements, RFC3379, September 2002, http://www.ietf.org/rfc/rfc3379.txt [GCSPEC] 政 府 認 証 基 盤 (GPKI) 相 互 運 用 性 仕 様 書 , 2003, http://www.gpki. go.jp/session/CompatibilitySpecifications.pdf [NIST] Peter Hesse: Conformance Testing of Relying Party Client Certificate Path Processing Logic, 2001,
http://csrc.nist.gov/pki/testing/x509paths.html
[AiCrypto] 名古屋工業大学岩田研究室：AiCrypto ホームページ, http://mars.elcom.nitech.ac.jp/Research/MM/security/aicrypto. html
[GPKI] 政府認証基盤ホームページ, http://www.gpki.go.jp
