セキュリティのフレームワーク - IPA 独立行政法人 情報処理推進機構

3. 分類に基づく各セキュリティ関連 API の分析
前述、2. セキュリティ関連 API の分類方法 の項で説明した分類方法に基づき、洗い出しを行ったそれ
ぞれのセキュリティ関連 API に対し、1.4.1 セキュリティ関連 API の詳細分析 の項で説明した分析項目
に基づいて詳細分析を行った結果を説明する。
3.1 アーキテクチャ (Architecture)
3.1.1 MISF (Microsoft)
1) API 名
MISF (Microsoft Internet Security Framework)
2) 概説
MISF は公開鍵セキュリティ技術の包括的なセットを提供する、Microsoft により作成されたセキュリティ
のフレームワークである。
インターネットの標準をサポートすることにより、クロスプラットフォームでの相互運用性を保証する
(後述の k) 準拠する標準 を参照)。
また、柔軟性を持ったアーキテクチャであるため、開発者が新しい標準を追加したり、暗号化分野での変
化に合った変更を行ったりすることができる。
3) 備考
Microsoft がサイトで提供する MISF に関する資料は、関連資料にあげた[3] および[4] のみで非常に情報
量が少ない。過去の資料 ([2]など) では CryptoAPI 1.0 および 2.0 を中心にした MISF の構成図が引用さ
れているが、現在公開されている資料には掲載されておらず、また詳細な記述も見つけることができない。
また、これらの資料は、過去の CryptoAPI 1.0 および 2.0 が現在の CryptoAPI 2.0 に統合される前の情報
であり、現在の仕様を反映するものではない。
参考として、統合前の古い MISF の構成を示す 2 つの図を資料[2] から引用する。
14
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
(Application)
|
CryptoAPI
|
CSP
備考) この構成図は 3.2.2 CryptoAPI 2.0 (Microsoft) の項で記述したものと同一である。
また、過去の MISF を示す構成図であるが、参考として以下に引用しておく。
b) 提供するセキュリティの機能
提供するセキュリティの機能
•
•
•
•
•
プライベートなコミュニケーションの保証
インターネット上の個人認証 (Verify Identity)
情報およびリソースに対するアクセス管理
セキュアなトランザクション処理
ソフトウェアの説明可能性 (accountability) および完全性 (integrity)
15
•
確固としたセキュリティの基盤の提供
(資料[3])
c) API 数
API は後述の CryptoAPI が提供する。
d) ベースとなる技術
•
CryptoAPI
•
Secure Channel Services (SSL 2.0/3.0 および PCT 1.0)
•
Client and Server Authentication (SSL 2.0/3.0 および PCT 1.0、X.509v3 Certificates)
•
Microsoft Certificate Server
•
Microsoft Wallet、PFX (Personal Information Exchange)
•
Smart Cards
•
Secure Payment
•
Authenticode
•
Windows Trust Verification Services (WinTrust API)
(資料[4]、[5]より)
e) 利用対象アプリケーション
資料[4] では、セキュア コミュニケーション、インターネット コマース、情報やリソースへのアクセス管
理などのさまざまなアプリケーションで利用可能、としている。
備考) 資料[4] では、Microsoft の インターネットの EC 戦略 (Internet Commerce Strategy) が説明され
ているが、この資料で MISF が取り上げられていることから判断すると、この戦略における重要な技術基
盤として位置付けられるだろう。
f) アプリケーション開発の容易さ
MISF はライブラリではないため、開発の容易さについて説明することは適切ではないが、MISF のベー
スとなる CryptoAPI 2.0 および CAPICOM の利用のしやすさ、あるいは、各ベンダーが CSP を開発し
て自社製品を接続可能にする、といった観点から考えると、1 社独占の技術・体系とは言え、利用しやす
いと言える。
g) ポータビリティ
Windows のみ。しかし、後述のインターネット標準をサポートしているので、他のプラットフォームのソ
フトウェアと相互運用することはできる。
h) プラットフォーム
Windows2000、WindowsNT 4.0 など。
i) 適用例
Windows および WindowsNT、Microsoft Internet Explorer および Microsoft Internet Information
Server は MISF の重要な基盤であり、同時に適用例としてあげることができるだろう。
また、Microsoft Platform SDK に同梱の MISF ツールにより、アプリケーションを作り直すことなく、ア
プリケーションおよびネットワーク セキュリティに公開鍵のセキュリティを利用可能に拡張することが
できる。
また、MISF に関連した適用例を以下にあげる。
16
•
Hewlett Packard が ICF (International Cryptographic Framework) i 技術を利用できるように
CryptoAPI を利用している。
•
Microsoft と VeriFone が WindowsNT 向けに統合決済ソリューションと、VeriFone の vPOS 決済シ
ステムを用いた Merchant Server をリリースした。
(資料[3])
また、資料[3] には、PC/SC Workgroup に参加し、PC に Smart Card を統合する活動を行っており、
CryptoAPI および Smart Card CSP を提供することにより Windows および WindowsNT で Smart Card
および Smart Card リーダが利用可能にする予定、とある。
資料[3] には RSA が BSAFE およびセキュリティ ツールキットにより CryptoAPI をリリースする予定、
と書かれているが、RSA Security Inc.のサイト(資料[6]) ではそのような情報を見つけることができなかっ
た。
j) 推進団体または提案した会社
Microsoft
記事[7] によると、RSA と Microsoft がセキュリティ技術に関してクロスライセンスの契約を行い、MISF
に対する強力なサポートを提供する、とある。
また、資料[3] では、VISA および MasterCard と協力してオンラインでクレジットカードのトランザクシ
ョン処理を可能とするよう協力している、とある。
k) 準拠する標準
•
SSL 2.0/3.0
•
S/MIME
•
SET
•
X.509v3、PKCS#7 電子署名フォーマット、PKCS#10 証明書カプセル化
(資料[3]、[5])
資料[4] では、SSL の発展である、IETF が策定中 (1997 年 5 月当時) の TLS も対応予定。
このようなインターネット セキュリティ標準に準拠していることにより、MISF を「クロス プラットフ
ォームでかつ、相互運用可能なセキュリティ技術」と説明している。
l) 利用コスト
MISF は CryptoAPI を中心とした Microsoft のセキュリティの枠組みを指しているため、特定の製品や
開発環境を指すものではない。
Windows2000 などの Microsoft の OS に密接した形でバンドルされているため、MISF のみのコスト
は発生しない。
なお、nCipher や Intel など各ベンダーが提供する CryptoAPI 用の CSP およびそのハード、ソフト製品
については、各ベンダーから購入が必要である。
m) 関連文書の入手可否
Microsoft のサイトから現在入手可能な資料は、資料[3]および[4]の 2 種類のみであり、MISF について詳
しく説明されているのは資料[3]であるが、この記事は 1996 年と古く、CryptoAPI 1.0 と 2.0 が統合され
る前、Internet Explorer 4.0 の当時の資料となっている。このため、現在、CryptoAPI 2.0 と統合された
状況での MISF をどのように捉えているか、を正確に示す資料は入手不可能となっている。
n) 他 API との関係
n.1) Microsoft CryptoAPI 2.0
i
HP の ICF については付録 A5.1.2 ICF (HP) にて概説。
17
CryptoAPI は MISF の中心的な役割を果たす。CryptoAPI 2.0 は後述 3.2.2 CryptoAPI 2.0 (Microsoft)
で詳しく解説している。
o) 拡張性
MISF 自身の拡張性に触れた資料は見つからなかった。ただし、3.2.2 CryptoAPI 2.0 (Microsoft) の o) 拡
張性 で述べるように CryptoAPI 2.0 が拡張性を有する。
3.1.2 CDSA 1.2 (Intel)
1) API 名
CDSA (Common Data Security Architecture) V1.2
2) 概説
CDSA の概説については、3.1.3 CDSA 2.0 (Open Group) の項にて説明しているので、そちらを参照され
たい。なお、現在、CDSA バージョン 1.2 の仕様書については Intel からは入手することが不可能である。
3) 歴史
CDSA2.0 までの歴史は以下 ([8])。
•
Intel Architecture Labs が CDSA 1.0 および CDSA 1.1 の定義およびプロトタイプ開発を行う。
•
CDSA 1.2 仕様書を Open Group に提出し、標準として採用
•
Open Group を通して、Intel が以下のリーダ的役割を果たす；
­
CDSA 2.0 仕様の定義
­
CDSA および CSSM を Open Group 仕様として採用
なお、CDSA V1.2 と V2.0 の違いについては後述 n.1) で説明している。
4) CDSA V3.0
記事[9] に Intel の CDSA に対する取り組みに関しての最新情報が紹介されており、CDSA バージョン 3.0
について触れられている (これに関する日本語の記事は [10] および [11])。
備考) Intel サイトで検索する限り、Version 3.0 に関しての情報はこれらの記事のみであった。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
CDSA2.0 と同じ 4 階層構造 ([8])。フレームワークの概略を説明したものが次の図であり、
18
モジュールを含めた詳細なアーキテクチャを示す図が次である ([8])。
b) 提供するセキュリティの機能
a)の構成図のように、CDSA 1.2 の CSSM では以下の 4 つのモジュールから構成されており、CDSA 2.0
で追加されたモジュール追加機能である EMM (Elective Module Manager) を持ってないため、これら 4
つのモジュールが提供する機能のみをサポートする。
•
Cryptographic Service Provider (CSP) modules
•
Trust Policy (TP) modules
•
Certificate Library (CL) modules
•
Data Storage Library (DL) modules
c) API 数
CDSA 自身は API を提供しない。CDSA のレイヤー3 (第 3 層) である CSSM が API を提供。このため、
CDSA 1.2 の API 数は 3.2.3 CSSM API (Open Group) の項に記述してある。
d) ベースとなる技術
基本的には CDSA 2.0 と同じ。
e) 利用対象アプリケーション
基本的には CDSA 2.0 と同じ。ただし、1.2 と 2.0 で機能差があるため、当然ながら 2.0 よりも適用領域が
狭い。
f) アプリケーション開発の容易さ
基本的には CDSA 2.0 と同じであるが、EMM による拡張性がないため新しいセキュリティサービスを追
加することができない。このため、適用領域は CDSA 1.2 が提供するセキュリティ サービスに制限され
る。
19
g) ポータビリティ
CDSA 2.0 と同じであり、対象は C 言語。
h) プラットフォーム
基本的には CDSA 2.0 と同じであると思われるが、既に 1.2 に関しての情報が入手できないため正確な情
報については記述できない。
i) 適用例
CDSA を採用した会社については、参考資料[12] の Adopters にリストアップされている。
i.1) ソリューション プロバイダ
•
•
•
•
•
•
•
•
Apple、http://www.apple.com/
補足) Apple における CDSA ベースのセキュリティに関する取り組みの資料が[13] にある。この資料で
"Apple's Security Architecture (ASA)" という名前が出てくるが、現在の Apple のサイトではこのキー
ワードで検索できる情報はない。
Caldera、http://www.caldera.com/
Caldera 社が開発している OpenLinux 3.1 には CDSA のパッケージが含まれている。
補足) 該当記事が見つからないが、Caldera のサイトに掲載されている 2000 年 9 月 25 日の記事に、
"Caldera、Intel and Bull Bring Intel's Common Data Security Architecture - CDSA - to Linux;
Caldera Will be First to Include CDSA in Linux Business Solutions" の記事がある。
Compaq、http://www.compaq.com/
Compaq 社が開発している Tru64 UNIX は CDSA 2.0 をサポートする最初の OS とされている (資料
[14])。
補足) Compaq のサイトの Press Release には 1999 年 2 月 24 日の記事として、"Compaq Adopts CDSA
and Licenses Intel's CSSM 2.0 Reference Implementation" の記事がある。
Bull, S.A..、http://www.eis.bull.com/
BULL Infrastucture & Systems 社 Division of BULL S.A. は TrustWay Software Framework とい
う PKI ベースのアプリケーション開発環境を提供しており、Linux 上の最初の CDSA 2.0 を実装したソ
フトである。
補足) TrustWay ソフトウェア フレームワークは PKI 実装セキュリティ アプリケーション開発を単純
で短期に実現できる独自のソフトウェアである。
これは、
Open Group セキュリティ標準である CDSA の
世界で最初に Linux 上に実装したものである。CDSA 技術は既に多くの商用製品に統合されており、
これを用いてマルチ プラットフォームのセキュリティ アプリケーションを開発することが可能である。
Hewlett-Packard、http://www.hp.com/security/
1996 年 6 月 16 日付けの記事によると、Hewlett-Packard 社は HP-UX 11 用に HP Praesidium CDSA
Version 1.2 として無償提供すると、同時に AT&T 社の暗号技術を用いた 3 つの CSP のライセンスを提
供した。
補足) Hewlett-Packard の HP-UX の CDSA 1.2 対応に関するプレゼン資料が [15] にある。
IBM、http://www-3.ibm.com/security/standards/st_cdsa.shtml
Open Group における CDSA Version 2 のレビューおよび是認においてリーダーシップを取り、この仕
様に IBM が提案するキーリカバリの改善が含まれている。
また、IBM が開発する UNIX である AIX 上の KeyWorks API は、CSSM を用いている。
補足) IBM の KeyWorks に関する資料が [16] にある。
SuSE、http://www.suse.com/
記事[17] によると、Intel の CDSA は多くのハードウェア ベンダーや Linux ディストリビュータによっ
て実装されており、現在の 32 ビット オープンソース実装が Caldera Inc の OpenLinux 7.x、 SuSE
Linux 7.1、 TurboLinux Inc の Workstation 6.1 に含まれる予定である。また、これらの 3 社は 64 ビ
ット OS に CDSA を統合することに同意した、という記事が掲載されている。
の記事が掲載されている。
TurboLinux、http://www.turbolinux.com/
20
上記の記事[17] にあるように、TurboLinux Inc の Workstation 6.1 に含まれる予定である。
i.2) CDSA ベース ツールキット
•
Baltimore、http://www.baltimore.com/
Crypto Systems Toolkit (CST) は CDSA 準拠である。
•
Cylink、http://www.cylink.com/
•
Motorola、http://www.motorola.com/
補足) Motorola の CypherNET Software Developer's Kit が CDSA1.2 に対応しており、これのプレゼ
ン資料が [18] にある。
i.3) CDSA サービス プロバイダ (Service Provider) の開発企業
•
•
•
Certicom、http://www.certicom.com/
Chrysalis-ITS、http://www.chrysalis-its.com/
ISC (Information Security Corporation)、http://www.infoseccorp.com/
AT&T/ISC CDSA 1.2 Cryptographic Service Providers (CSPs)
http://www.infoseccorp.com/products/cdsacsp.htm
Hewlett-Packard の HP-UX 11.0 用に配布される Praesidium CDSA 1.2 CSP (Cryptographic Service
Providers) は、 ISC が開発およびサポートをし、AT&T がライセンスを行う。
•
Rainbow Technologies、http://www.rainbow.com/
•
ValiCert、http://www.valicert.com/
注) なお上記は Open Group の CDSA 2.0 の実装製品が含まれると同時に、Open Group の CDSA 2.0
の適用製品としてあげたものと重なる。
j) 推進団体または提案した会社
Intel、特に Intel Architecture Labs ([19]) が中心となって仕様作成、リファレンス実装開発などを行って
いる。
k) 準拠する標準
バージョン 2.0 が Open Group として標準化されているが、1.2 自身は標準化されていない。
l) 利用コスト
無料。ただし、現在、1.2 のソースおよび仕様書の入手方法が不明だが、後述の CDSA 2.0 により CDSA
1.2 を利用する機会はほとんどないと思われる。
m) 関連文書の入手可否
現在 2.0 が正式版であり、Intel のサイトから第 1.2 版の仕様書を入手することはできない。
ただし、第 1.0 版の仕様書のコピーが [20] から入手できる。
n) 他 API との関係
他の API との関係は CDSA1.2 と 2.0 で同じであるため後述の 3.1.3 CDSA 2.0 (Open Group) で説明し、
ここでは CDSA1.2 と CDSA 2.0 との違いを説明する。
n.1) CDSA 2.0
CDSA のバージョン 1.2 とバージョン 2.0 の違いについては、文献[21] および資料[22] に解説がある。
1.2 から 2.0 へのバージョンアップの変更点は以下 (資料[22])。
•
28 関数、15 データ構造の変更
•
新規の 51 関数、11 データ構造の追加
•
3 関数の削除 (他の関数と統合)
また、大きな機能追加としては以下がある(資料[21])。
•
プラットフォーム独立のディレクトリ サービスを提供する MDS (Module Directory Service) コンポ
ーネントとこれに関連する signed manifest credentials
•
Elective Security Service Modules 追加による拡張性
21
•
•
Elective Security Service としてのキーリカバリ (Key Recovery)
政府の輸出入規制を定義、適用する Exemption tag
これを CDSA アーキテクチャの図で表示したものが次の図である ([8])。
ただし、CDSA 1.2 から 2.0 への移行期にあたる 1998 年当時には、資料[21] の付録 B にある「1.2 から 2.0
への移行」や、資料[22] にある「アプローチ方法」の記述が重要性を持ったが、現在はバージョン 2.0(最
新版は Version 2 Release 3.14) が普及、バージョンアップされる段階にあるため、バージョン 1.2 の重要
性は低くなった。また、Open Group において Intel が中心として活動しているので、Intel、Open Group
という切り分けは無意味である。
3.1.3 CDSA 2.0 (Open Group)
1) API 名
CDSA (Common Data Security Architecture) 2.0
2) 概説
CDSA は、アプリ-ケーションがセキュリティ サービスに選択的で動的にアクセスできるオープンで拡張
可能なアーキテクチャを定義する ([21])。最新版は V2.3 である。
3) 歴史
Intel の策定した CDSA を Open Group が採用。現在は、Intel 中心となって Open Group が仕様策定を行
っている。また、Intel などの Open Group のメンバーが CDSA 2.0 のリファレンス実装を行い、オープン
ソースとして公開している。
•
1997 年 Intel により最初の CDSA が開発
•
1997 年 12 月 Open Group により標準として採用
(資料[23])
なお、詳しい歴史は資料[24] の "CDSA Evolution" のページに掲載されている。
4) 特徴
•
レイヤー アーキテクチャ
22
- 暗号化、トラスト ポリシー、データ保存、認証サービスに対する API
- セキュリティ管理者が選択するセキュリティ モジュールを追加可能
•
アプリケーションおよびセキュリティ サービス ライブラリに対する様々なインタフェース
•
付加機能が豊富
- アドイン モジュールの認証・識別を確証、モジュールの登録機能、ユーザ セキュリティ コンテ
キストのキャッシュ
- アプリケーションのためのメモリ管理
(資料[23])
また、以下の特徴を持つ ([21])。
① オープンなアーキテクチャ
完全に情報公開され、標準化され、業界に採用されている。
オープンな仕様はベンダーに依存しない組織である Open Group によって採用されている。
② モジュラー (modular) で拡張可能
各レイヤーのコンポーネントは別個のモジュールとして選択することができる。
拡張可能なフレームワークはモジュール マネージャ (module managers) のサポートにより、新しい任
意のカテゴリのセキュリティサービスに対してモジュール追加することができる。
拡張性は、それぞれのサービス モジュールに対して追加機能の開発、性能競争による実装を業界に促進
させる働きをする。
アプリケーションは異なるサービス プロバイダ (service provider) のライブラリをそのアプリケーシ
ョンのコードを変更することなしに選択・利用することができる。
③ セキュリティ プログラミングのコストを下げる。
CDSA がセキュリティの細かなことを管理してくるため、個々のアプリケーションはセキュリティ関連
の詳細なことに気を使う必要がない。
CSSM API はセキュリティ サービスの論理的なカテゴリを定義して、開発者がアプリケーションに容
易にセキュリティを追加することができるようにしている。
プログラマは CSSM が提供する (機能のための) コードを書く必要がない。このため、ソフトウェア開
発はより楽により安価になる。
④ CDSA は今後に現れる新技術に対応できる。
CDSA はデータ セキュリティのための新しい技術を統合することができる。
基 本 的 な 技 術 は ポ ー タ ブ ル な デ ジ タ ル ト ー ク ン (digital token) と デ ジ タ ル 証 明 書 (digital
certificates)を含んでいる。将来に選択可能なモジュールの技術として、ユーザ認証と汎用のオブジェク
ト統合サービス (object integrity service) のためのバイオメトリック装置 (biometric device) をあげ
ることができる。
画期的な技術がコンピュータ業界の短い歴史にかかわらず十分多く出ているが、進歩のペースが早過ぎ
て各ベンダーがそう望むにも関わらず協調するのが困難なほどである。
ソフトウェア開発者は、どの技術が優勢を占めていくのか予測することができないため、複数の技術を
包含する能力をもったアーキテクチャのためにプログラミングするのがベストな解である。
5) PKI のアーキテクチャに対して CDSA が優位な点
•
輸出入可能 (Exportable/Importable)
•
マルチプラットフォームのサポート
•
オープン、拡張性 (extensible)、スケーラビリティ (scalable)
•
十分なセキュリティ サービス セット
•
業界による検討およびレビュー
([21])
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
以下の 4 層構造 ([21])。
レイヤー1:
レイヤー1: アプリケーション
レイヤー2:
レイヤー2: ミドルウェアおよびレイヤード サービス
ツールや言語インタフェース アダプタ (language-interface adapter) を含む。
23
特に、アプリケーション開発言語のトランスレーション ソフトウェアに適する。
レイヤー3
3: Common Security Services Manager (CSSM) インフラストラクチャ
レイヤー
レイヤー1 および 2 は CSSM の上に位置する CSSM API を通して、レイヤー4 の機能にアクセス
する。
レイヤー4:
レイヤー4: Security Service Provider Modules
CSP (Cryptographic Service Provider) や Certificate Library など。
上記 3 の CSSM については、3.2.3 CSSM API (Open Group) の項に別途記述した。
通常 CDSA2.0 のアーキテクチャを示す図は以下 ([24])。
後述の 3.5.2 CDSA/HRS API (Open Group) で述べる CDSA/HRS を含んだ図も以下に引用しておく ([25])。
24
b) 提供するセキュリティの機能
CDSA は良い抽象レベルで完全なセキュリティ モデルを表現しており、X.509 v3、PGP、SPKI などの複
数の証明書モデル (Certificate model) とフォーマットをサポートしている ([21])。
また、デジタル証明書 (digital certificates)、鍵管理メカニズム (key management mechanisms)、より上
位レベルでの SSL、S/MIME、SET などのセキュア トランザクション プロトコル (secure transaction
protocol) のセキュリティ サービスを提供する。
特に、近年普及が期待されるスマートカードのようなデジタル トークン (digital token) のサポートを対
象としている ([21])。
c) API 数
CDSA 自身は API を提供しない。CDSA のレイヤー3 (第 3 層) である CSSM が API を提供。
このため、CDSA 2.0 の API 数は 3.2.3 CSSM API (Open Group) の項に記述してある。
d) ベースとなる技術
実際の暗号化などの技術はベンダーが開発する CSP が提供することになるため、CDSA 自身が提供するも
のではない。ただし、世に出ている様々なセキュリティ技術を統一した API で利用可能にするために、こ
れらを考慮した抽象化を行っている。
CDSA アーキテクチャモデルは、デジタル トークン (digital token) とデジタル証明書 (digital
certificates) の概念の上に構築されている ([21])。
e) 利用対象アプリケーション
CDSA が対象とするアプリケーションは以下([21])。
•
B2B および B2C における E コマース業務アプリケーション。これは選択可能な範囲のセキュリティ
ソリューションを包含する。
•
価値や脅威が全く異なるような、プライベートな E メール、ホーム バンキング、金融取引でのビジ
ネスおよび個人的な活動のための安全確保。
•
新しいアルゴリズムやプロトコルを必要とする、ソフトウェア、参考情報、教材やエンターテイメン
ト情報のコンテンツ配信。
•
コンテンツ、サービス、あるいはその両方の計測や、状態と価値の安全な保存に対する要求。
CDSA 上に構築可能なセキュリティ サービスは以下 ([21])。
•
セキュア E メール (Secure email)
­
S/MIME
­
Open PGP (PGP/MIME)
•
セキュア コミュニケーション (Secure Communications)
­
SSL
­
TLS
•
認証サービス (Authentication Services)
•
セキュア ペイメント (Secure payments)
- SET
- マイクロ ペイメント (Micro Payments)
- 電子小切手 (E-Checks)
•
証明書管理 (Certificate management)
- 生成 (Creation)
- 失効 (Revocation)
- トラスト モデル (Trust models)
また、E コマースに有望な PKI 環境に重要な役割を果たし、その環境ではトラスト ドメイン (trust
domain) のサービス、署名 (signing) と封印 (sealing)、否認防止 (non-repudiation) がシームレスで効
果的に機能するように要求される([21])。
25
Intel によるリファレンス実装には以下のサンプル アプリケーションが含まれる ([21])。
•
KeyKeeper
共通鍵鍵暗号のサンプルで、単一のマスタ パスワードにより全パスワードを保護・管理することができ
る。つまり、パスワードなどの秘密情報のリストを保管する金庫とみなせる。単一の鍵、つまり、マス
タ パスワードにより金庫の中にある全ての秘密にアクセスすることができる。
•
Certificate Manager
エンドユーザが既存のデジタル証明書を参照し、新しくデジタル証明書を作成するサンプル アプリケー
ション。
いくつかの証明書は CA 局 (Certificate Authority) から入手する。
例えば、First Western Bank
証明書はあなたの個人的な証明書にチェーンされている (chained) ため、 Big East Federal Bank は
あなたの個人的な First Western Bank の証明書を受け入れることができる。Certificate Manager に
よりユーザは、証明書チェーン (Certificate chain) を辿り、証明書チェーンの参照および構築をするこ
とができる。このアプリケーションは完全な Certification Authority アプリケーションによって提供さ
せるサービスの最小セットを提供するものである。
•
Electronic Shrink Wrapper
シュリンクラップは、ソフトウェア製品から医薬品まで製品を包むために使われている。
包装はラップされた中身を外部の干渉から保護することはできないが,以下のようなセキュアで信頼で
きるメカニズムを提供する。
- ラップされたコンテンツの完全性を保証する
- ラッピングが改ざんされたときに消費者に警告を出す
ラッピングが無傷であれば消費者は製品が製造されラップされてから変わっていないことを確信するこ
とができる。さらに、シュリンクラップは信頼性の高い製品を売っている企業の評判を保護してくれる。
Electronic Shrink Wrapper アプリケーションはデータの集合に対し電子的なシュリンクラップを施す。
電子的なシュリンクラップはデータ オブジェクトの論理的なラッピングであり、ラップの保証性の利点
を破壊することなく、繰り返しデータオブジェクトを確認およびアクセスを可能とする。
シュリンクラップの完全性を確認することは、すなわち、対象となっているそれぞれのデータオブジェ
クトの中身が変更されておらず、対象がオリジナルのデータオブジェクトの集合を含んでいることをユ
ーザに確信させる。
電子的なシュリンクラップはまた、付加的な利点を提供する。つまり、データオブジェクトをラップし
た個人あるいは組織の身元 (ID) を確実に確かめることができる。
f) アプリケーション開発の容易さ
CSSM を用いたミドルウェア (レイヤー2) や、これを用いたアプリケーション (レイヤー1) を構築するこ
とができ、より上位のレベルでアプリケーションを構築することができる。つまり、ベースとなる暗号技
術などの高度なセキュリティに関する専門知識がなくてもアプリケーション開発できることを示している。
また、実際の暗号技術など低位レベルのセキュリティ機能を自社のハードウェアまたはソフトウェアでレ
イヤー4 のセキュリティ サービス プロバイダの SPI を用いて開発することにより、ベンダーが自社製品
を CDSA で利用可能にすることができる。
これにより、ユーザはベンダーが開発した多くのセキュリティ サービス プロバイダから自分のアプリケ
ーションに適するものを選択し、あるいは開発後に切り替えるといった柔軟性を得ることができる。
g) ポータビリティ
言語は C。Java 対応も提案されている ([26])。
4 階層によるアーキテクチャにより、ポータブルで適応性があり、モジュラーな (modular) 環境となって
いる ([21])。
h) プラットフォーム
プラットフォーム
資料[21] では、Apple, OS4000, MVS, UNIX, Microsoft Windows, WindowsNT とし、資料[27] では、
Apple (Mac OS), Bull (Linux), Compaq (UNIX), HP (HP-UX), IBM (OS/390, OS/400, AIX), and
Baltimore (PKI toolkit) としている。
Linux 32 ビットおよび Windows 32 ビット用の CDSA。また、Bull、Caldera、Intel が Linux 64 ビッ
26
ト用 (Itanium プロセッサに最適化した) の CDSA を開発 ([28])。
i) 適用例
文献[21]、Appendix D, "Co-Travelers"に挙げてある会社とその適用製品を以下にリストアップする。
Company
CDSAProduct
oduct Type
CDSA-Related Pr
Further Information
Apple Computer, Apple OSs, PowerTalk, KeyChain, SSL v3 over CDSA
Inc.
Baltimore
PKI-Plus SDK
Technologies
Certicom
Elliptic curve Software, CSP
www.apple.com
Compaq
Computer
Corporation
Chrysalis-ITS
www.compaq.com
Cylink
Digital UNIX
www.BaltimoreInc.com
www.certicom.com
CSP (Luna2, LunaCA, LunaCA^3, Luna VPN www.chrysalis-its.com
hardware tokens and accelerators)+C7
CryptoKit toolkit, PrivateSafe SmartCard readers, www.cylink.com
PrivateCard SmartCard
Specification Contributor
www.entrust.com
Entrust
Technologies, Inc.
Hewlett-Packard HP-UX 11.0
www.hp.com
Company
IBM Corporation IBM KeyWorks for AIX, WindowsNT, OS/400 and www.ibm.com/security
OS/390 Operating Systems, IBM Vault Registry, IBM
eNetwork Firewall for AIX and WindowsNT, Lotus
PKIX Reference Implementation, and Specification
Contributor
Information
Software CSP
www.infoseccorp.com
Security
Corporation
Intel Corporation Creator of CDSA and reference implementation and www.intel.com/ial/
included CDSA technology in LANDesk Management
Suite 6
Motorola
CipherNET SDK, CipherNET 1000, Registrar 2.0, ciphernet.motorola.com
CipherNET 1000, Certificate Authority Server 2.0
RSA Data
RSA Certificate Security Suite
www.rsa.com
Security
Security
SecurSight Enterprise, Security Products
www.securitydynamics.com
Dynamics
Rainbow
CSP (CryptoSwift and CryptoSwift II Hardware isg.rainbow.com
Cryptographic accelerators)
Trusted
Specification Contributor
www.tis.com
Information
Systems
ValiCert
Trust Policy Service Provider (Certificate Validation www.valicert.com
Module for CDSA)
27
Veridicom
Developing Fingerprint Reader, Biometric Service www.veridicom.com
Provider for CDSA through the User Authentication
Services
なお、本情報は 1998 年の出版当時の情報であり、また、Intel CDSA 1.2 の報告で挙げた適用と重なる部
分があることを明記しておく。
i.1) OpenSSL
Intel が OpenSSL に CDSA を適用している ([29], [30])。
i.2) Bull, TrustWay
TrustWay Software Framework は CDSA Version 2.0 ベース ([31])。
j) 推進団体または提案した会社
Open Group, http://www.opengroup.org/
Open Group の中の CDSA working team に参加する以下のコアメンバーと
•
Intel Corporation
•
IBM Corporation
•
Trusted Information Systems (現、Network Associates)
•
Entrust Technologies Inc.
•
Netscape Communications Corporation
以下のベンダーが CDSA の策定を行っている(参考文献[21])。
•
日立
•
Hewlett-Packard Company
•
Motorola
•
National Institute of Standards and Technology (NIST)
•
United States National Security Agency (NSA)
また、Open Group フォーラムでは多くの組織が CDSA 開発に寄与している。
さ ら に 、 Shell Petroleum International Company (SPIC) (www.shell.com) 、 J. P. Morgan
(www.jpmorgan.com) が仕様策定の支援に参加している。
他に、TESI (Trusted European Security Initiative) が CDSA ベースの相互運用可能なセキュリティ コ
ンポーネントの開発を行っている ([28])。
k) 準拠する標準
Open Group により仕様書[32] として標準化。また、SSL、X.509V3、PKCS-11 などの他の標準も包含し
ている ([33])。
CSSM ベンダー、サービス プロバイダ ベンダー、アプリケーション ベンダーに対して、CDSA 準拠で
あるかどうかをテストするために CTS (Conformance Test Suite) がリリースされている ([34])。
また、
Open Group が CDSA 準拠および相互運用性に対する Certification Program を行っている ([35])。
ま た 、 次 世 代 の 認 可 証 明 書 (Authorization Certificate) を 利 用 す る 、 SPKI (Simple Public Key
Infrastructure) をサポート ([28])。
l) 利用コスト
無料。
CDSA のオープンソースが参考資料[36]、SourceForge より入手可能。
上記のソースは、Intel および各社のリファレンス実装を含むソースである。また、MacOS X 用のソース
コードが [37] より入手することができる。
28
m) 関連文書の入手可否
仕様書 ([32]) は Open Group のサイトよりダウンロード可能。
n) 他 API との関係
n.1) CDSA 1.2 (Intel)
Open Group 採択前に Intel が作成した CDSA の前バージョンの CDSA。 CDSA 1.2 と 2.0 との違いは
3.1.2 CDSA 1.2 (Intel) で説明。
n.2) CSSM API (Open Group)
CDSA の 4 層構造のレイヤー3 を占める API の仕様。3.1.3 CDSA 2.0 (Open Group) の項にて別途調査。
n.3) PAM (UAS)
資料[38] では、1998 年当時の今後の計画として、ユーザ認証サービス API として、CDSA のフレームワ
ークで CSSM API に相当する UAS (User Authentication Services) API を提案している。
UAS API は、パスワード、スマートカード、バイオ認証、の 3 つのユーザ認証をサポートし、登録、更新、
確証 (Verify)、確証&更新、識別 (Identity) の 5 種類の API を提供する。
この資料で、別項で説明の PAM との関係を
PAM Framework
|
PAM Auth Modules
|
CSSM/UAS Framework
|
UAS Authentication Service Providers
という構成で捉え、PAM フレームワークのベースとして CDSA が適用可能であることを示している。(が、
この計画がその後どうなったかは未調査)。また、PAM については、後述の 3.4.5 PAM (SunSoft) を参照。
n.4) APKI
資料[39] を参照。また、3.1.5 APKI (Open Group) の項で説明している。
n.5) Cryptoki (RSA PKCS#11)
資料[23] では、CDSA と Cryptoki の違いについて説明すると同時に、Cryptoki を CDSA に適合するため
のアーキテクチャと、CSSM と Cryptoki ライブラリを繋ぐための Cryptoki Adaptation Layer について
解説している。
この資料中、Intel が 1998 年に Cryptoki Adaptation Layer のデモを行った、と書かれており、この方式
に従えば、Cryptoki ライブラリが CDSA における CSP の一つに位置付けることができる。なお、Cryptoki
(PKCS#11) については後述の 3.3.2 PKCS#11 (RSA) の項で説明している。
n.6) JCA/JCE および Java-CDSA
CDSA 1.2 の 1998 年当時、Intel は以下の 2 つのアプローチを検討している ([40])。
・ Intel の Java-CDSA ベース
・ Sun の JCA/JCE ベース
Intel の Java-CDSA とは CSSM に Java でアクセスできる Adaptation Layer を設け、これにより
Java-CDSA API と呼ばれる API で Java アプリケーションがアクセスする方式である。
[21]によると、Intel は CDSA 1.2 ベースの J-CDSA の仕様およびリファレンス実装をリリースした。
また、Trusted European Security Infrastructure (TESI) のサブプロジェクト TESI/Java interface によ
る、Java、CDSA 間インタフェース ([41])。
次の図は [26]から引用した Java の CDSM への適用の図である。
29
n.7) SPKI
SPKI は認可 (authorization) のために、新しい認可証明書 (Authorization certificates) を含む複数の証
明書 (Certificate) フォーマットを利用する必要がある。SPKI 機能は CDSA の CL、TP、AC モジュール
に含まれる。CL は証明 (Certificate) を行い、TP は証明 (certificate) を確証し (validate)、AC は認可結
果(authorization result) を生成する ([25])。
SPKI は、IETF の spki ワーキンググループの、公開鍵証明書、関連する署名など様々なフォーマットや
鍵取得のプロトコルの標準を定める活動と、この活動で開発された仕様を指す。また、SPKI については
付録 A5.7.5 SPKI にも解説を載せている。
n.8) PKCS#11
3.3.2 PKCS#11 (RSA) にて説明。
o) 拡張性
CDSA が CSSM により提供する拡張性は次の 2 種類。
o.1) EMM (Elective Module Manager)
EMM により新しいセキュリティ サービスを追加することができる。例えば、別途記述の CDSA/HRS の
ような。これを説明する図を以下に載せる ([42])。
•
•
•
EMM により標準を修正することなしに、CDSA にセキュリティ機能を追加することができる。
EMM Service Provider (SP) は他の SP と同じ構造を共有する。
アプリケーションは他の (セキュリティ) サービスタイプと同じ方法で EMM 関数を呼び出す。
30
EMM の制限としては以下 ([42])。
•
EMM は 1 回に一つの CSSM としか通信できない。
- EMM API は CSSM の GUID を attach handle と一緒にとるため。
•
アプリケーションは静的に EMM ライブラリをバインドできない。
- CSSM はある attach に利用される EMM を動的に決めるため。
EMM はセキュリティ サービスのカテゴリ毎に一つ追加されるので、複数の EMM を追加することが可能
である。新しいサービスに対して追加される EMM の API は、標準化されることが望ましい ([21])。
例えば、CDSA 2.0 では Key Recovery Module Manager (KRMM)が EMM の機能で追加された (なお、
2.3 では標準仕様の中に含まれる)。
o.2) アドイン セキュリティ モジュール
ベンダーが開発した複数の中から CSP などのセキュリティ サービス モジュールを複数利用することが
できる。このため、アプリケーションを改造することなく、別のセキュリティ メカニズムや暗号アルゴリ
ズムなどを利用することができ、複数のベンダーから提供される競合製品から自由に選択することを許す
([21])。
最後に、利用者自身の拡張性でなく、CSSM API を用いてより上位の API をレイヤー2 として設計、開発
できることを補足しておく。このケースの例が後述の 3.2.6 COE SS API (MITRE) である。
3.1.4 Java Security Architecture (Sun)
1) API 名
Java Security Architecture (JSA)
2) 概説
Java セキュリティ アーキテクチャは開発者が安全な Java アプリケーションを作成するための標準ベー
スのインタフェースを提供する ([43])。
Java セキュリティモデルは Java 2 において柔軟なポリシーベースのセキュリティモデルに拡張された。
セキュリティ アーキテクチャ (Java Security Architecture) の用語は通常、Sandbox モデルと Java2 で
拡張された Protection-Domain-Based Security Architecture を指す。
また、本資料では正式版の最新である Java2 Platform, Standard Edition (J2SDK) V1.3 を調査対象とし
ている (なお、現在、V1.4 のβ3 が公開されている)。
別項で説明する JSSE、JAS、JCE などの Optional Packages のコンポーネントは、V1.4 において Java
2 SDK に含まれることになった。Java 2 プラットフォーム (Java 1.2 とも呼ばれる) においてセキュリテ
ィの大枠を示すために使われている。
3) 歴史
3.1) Java セキュリティ アーキテクチャの歴史
•
•
•
([44])
"Java Security Architecture Version 1.0" - Java 2 SDK, Standard Edition, Version 1.2
"Java 2 Platform Security Architecture Version 1.0" - Java 2 Platform, Standard Edition v1.3
(J2SE 1.3)
"Java 2 Platform Security Architecture Version 1.1" - Java 2 SDK, Standard Edition, v1.4
3.2) Java のセキュリティの歴史
のセキュリティの歴史
•
JDK 1.0: サンドボックス (Sandbox)
•
JDK 1.1: コード署名 (Code-Signing)
•
JDK 1.2: 変更可能なセキュリティ ポリシー (Configurable Security Policy)
([45])
31
Java2.0 におけるセキュリティモデルの図は以下。
•
Java 1.0 Sandbox
•
Java 1.1 Security Model
•
J2SE 1.2 Platform: Security Model
•
J2SE 1.3 Platform:
([46])
4) 備考
資料[47] のように比較的新しい資料においても、"Java Security Architecture"という用語が使われており、
ネットワーク上で"Java Security Architecture (JSA)"というキーワードで検索しこの用語は一般に使われ
ているようである。
しかし、Sun のサイトには JSA という用語が使われたページおよび文書は存在しない。また、J2SE のバ
ージョンにより、"Java Security Architecture" と "Java 2 Platform Security Architecture" の 2 種類の
名称が使われている。
本項では、JCE などのコンポーネントを含めた Java Security Architecture 全体と、J2SDK のコア部分
のみの両方を指して使っている。
また、JSSE FAQ に以下の記述があるため、J2SDK v1.3 においては「Java Security Architecture」が大
きな枠組み、「core SDK における Java 2 Security Architecture」が core JSA と分類できると思われる。
JSSE は Java Security Architecture における最新の開発パッケージであり、core SDK における
Java 2 Security Architecture 、 Java Cryptography Extension (JCE), Java Authentication and
Authorization Service (JAAS)、および Java セキュリティ ツール上に構築されている。詳しくは Java
2 Security Architecture ドキュメントを参照のこと。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
JCE、JSSE、JAAS は J2SDK v1.3 ではオプション パッケージとしてリリースされたが、J2SDK v1.4
では J2SDK に含まれた形でリリースされている ([46])。
32
備考) この図における、
「Java セキュリティ アーキテクチャ」および「コア Java 2.0 セキュリティ アー
キテクチャ」は Java サイト[44] の資料では使用されていない用語である。
b) 提供するセキュリティの機能
以下の機能 (文献[48])。
•
JCA による暗号化機能
­
秘密鍵暗号、公開鍵暗号
•
鍵管理、デジタル証明書
•
メッセージダイジェスト、デジタル署名
Java 2 プラットフォームの一部である JCA は、データおよびプログラムに対する完全性とアイデンティ
ティの保護を、サービスプロバイダベースのプラグ アンド プレイ方式によって提供する。
また、JCE、JSSE といった Java プラットフォーム拡張により機密性の保護を提供し、JAAS により認証
とアクセス権の許可による保護機能を拡張する ([43])。
主なセキュリティアーキテクチャのうち、否認防止とセキュリティ監査のための標準インタフェースを備
えているのは、現在 Java がサポートしているものだけである。
c) API 数
以下の合計 52 クラス、327 メソッド ([49])。
•
Access Control Classes (以下の 23 クラス、70 メソッド)
・ Permission Classes (以下の 15 クラス、35 メソッド)
Permission (8 メソッド)
PermissionCollection (7 メソッド)
Permissions (4 メソッド)
UnresolvedPermission (7 メソッド)
FilePermission
SocketPermission
BasicPermission
PropertyPermission
RuntimePermission
AWTPermission
NetPermission
ReflectPermission
SerializablePermission
SecurityPermission (2 メソッド)
AllPermission (7 メソッド)
Policy (5 メソッド)
AccessController (6 メソッド)
AccessControlContext (6 メソッド)
PrivilegedAction (1 メソッド)
PrivilegedExceptionAction (1 メソッド)
CodeSoure (7 メソッド)
33
ProtectionDomain (5 メソッド)
SecureClassLoader (4 メソッド)
•
Cryptography Classes (以下の 27 クラス、205 メソッド)
Provider (13 メソッド)
Signature (20 メソッド)
MessageDigest (16 メソッド)
・ Key Interfaces and Classes (以下の 7 クラス、49 メソッド)
Key (4 メソッド)
PublicKey (0 メソッド)
PrivateKey (0 メソッド)
KeyPair (3 メソッド)
KeyPairGenerator (11 メソッド)
KeyFactory (9 メソッド)
KeyStore (22 メソッド)
・ Key Specification Interfaces and Classes (以下の 9 クラス、32 メソッド)
KeySpec (0 メソッド)
DSAPrivateKeySpec (5 メソッド)
DSAPublicKeySpec (5 メソッド)
RSAPrivateKeySpec (3 メソッド)
RSAPrivateCrtKeySpec (7 メソッド)
RSAPublicKeySpec (3 メソッド)
EncodedKeySpec (3 メソッド)
PKCS8EncodedKeySpec (3 メソッド)
X509EncodedKeySpec (3 メソッド)
・ Algorithm Parameter Classes (以下の 2 クラス、22 メソッド)
AlgorithmParameters (12 メソッド)
AlgorithmParameterGenerator (10 メソッド)
・ Algorithm Parameter Specification Interfaces and Classes (以下の 2 クラス、4 メソッド)
AlgorithmParameterSpec (0 メソッド)
DSAParameterSpec (4 メソッド)
・ Certificate Classes (以下の 3 クラス、37 メソッド)
Certificate (10 メソッド)
CertificateFactory (9 メソッド)
X509Certificate (18 メソッド)
SecureRandom (12 メソッド)
Security (10 メソッド)
SecurityManager (42 メソッド、ただし、java.lang パッケージ)
備考) 上記 API は、Tutorial の API Summary から抜き出し、Security API Specification でメソッド数
を調べたものである。
これらの API は JCE などと重複するものがあるし、
また、Security API Specification
でリストされる全てのクラスを網羅していない。また、J2SDK v1.4 の API は省略。
d) ベースとなる技術
Java セキュリティの中核を形成するアーキテクチャには以下がある ([43])。
•
バイトコード ベリファイア
•
クラスローダ
•
セキュリティマネージャ
•
アクセスコントローラ
•
アクセス権
•
セキュリティポリシー
•
保護ドメイン
34
また、以下のコンポーネントを含む ([43])。
•
JCA アーキテクチャ (暗号化エンジン、暗号化サービスプロバイダ)
•
アクセス制御 (アクセス制御アーキテクチャ、保護されたオブジェクト)
Java セキュリティ アーキテクチャは開発者が安全な Java アプリケーションを作成するための標準ベー
スのインタフェースを提供する ([43])。
コア Java セキュリティ アーキテクチャは、バイトコード ベリファイア、1 つ以上のクラスローダ、セキ
ュリティマネージャ/アクセスコントローラフレームワークから構成される。
バイトコードベリファイアは下位レベルにおけるオブジェクトの破壊を防ぐためのチェックをサポートす
る。クラスローダは信頼できるコードの認証をより確実に保護する。セキュリティマネージャとアクセス
コントローラは、権限の許可による保護を提供する。
e) 利用対象アプリケーション
安全な分散型 Java アプリケーションを構築する ([43])。
f) アプリケーション開発の容易さ
Java 言語とセキュリティの基礎知識は Java のセキュリティアーキテクチャを理解する上で必須である。
また、文献[48] で解説されている Java のセキュリティアーキテクチャの理解と、その利用方法が理解でき
ないと基本的に開発することは難しい。
g) ポータビリティ
後述のプラットフォームで示された J2SDK が動作する環境に対してポーティリティを有している。Java
自身がプラットフォーム独立の言語であるため。
h) プラットフォーム
Sun からは J2SDK v1.3.1_02 の Solaris SPARC/x86, Linux x86, Microsoft Windows 用のコードがリ
リースされている ([50])。
また、 "Java Platform Ports" ([51]) には AIX (IBM)、HP-UX (Hewlett-Packard)、Linux (Blackdown.org)、
MacOS (Apple) などポーティングされた OS がリストアップされている。
i) 適用例
i.1) GemStone/J
[52] 参照。
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
CSP は X.509 や PKCS#12 などをサポートする ([48])。
l) 利用コスト
J2SE Platform および JRE は無料でダウンロード可能であり、製品開発利用にコストはかからない ([53])。
ただし、J2EE についてはライセンスが必要。
また、Solaris SPARC/x86, Linux x86, Microsoft Windows 用のコードが [50] からダウンロードできる。
35
m) 関連文書の入手可否
J2SE 1.3 の仕様書が [54] から入手可能で、J2SE 1.3 のセキュリティ関連の文書は [55] であり、オンライ
ンでアクセスできる。
n) 他 API との関係
n.1) Java2 Platform, Standard Edition (J2SDK) V1.4 (現在、β
現在、β3)
現在、β
JAAS, JCE, and JSSE security features have been integrated into the J2SDK, v 1.4.
また、V1.4 により以下の 2 点が機能追加された。
① 証明書パスの構築と検証のための Java Certification Path API
② Kerberos を使って通信するアプリケーション間でメッセージをセキュアに交換するための Java
GSS-API
o) 拡張性
Java においては、下記のようなセキュリティの変更や拡張方法が備わっている。
① セキュリティポリシーの設定
システムセキュリティファイルおよびセキュリティポリシーファイルの編集により、プログラミングせ
ずに既存のセキュリティを変更することが可能。
② セキュリティパッケージ (セキュリティプロバイダ) の切り替え (あるいは独自開発)
たとえば、Sun JCE の代わりに Cryptix JCE を利用する、など。
③ プログラミングによる拡張
Java の場合、クラス拡張によるプログラミングにより、固有のセキュリティ機能を実装することができ
る。
3.1.5 APKI (Open Group)
1) API 名
Architecture for Public-Key Infrastructure (APKI)
2)
概説
Requirements for a Public-Key Infrastructure (PKI)
APKI は PKI に対する要求仕様を明確にし、PKI 仕様の標準化の基礎資料となることを期待して作成され
ているものである。標準化により最終的に、PKI の各コンポーネントのインタフェース仕様とプロトコル
仕様が決定される。
なお、APKI 仕様書中、各コンポーネントのインタフェース仕様とプロトコル仕様に対する候補が現在提
案ないし普及している標準プロトコル、標準仕様、製品で挙げられている ([56])。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
以下の 8 つのコンポーネントから構成される。
•
システム セキュリティ 実装サービス (System Security-enabling Services)
これは、システムにおけるユーザあるいは他のプリンシパル (principal) の ID (identity) によりそれら
の活動を確立し関連付ける機能を提供する。
•
暗号化プリミティブ (Cryptographic Primitives)
•
暗号化サービス (Cryptographic Services)
これは、公開鍵暗号 (DES のような秘密鍵のプリミティブを含む) の元になる暗号機能を提供する。
•
長期鍵サービス (Long-term Key Services)
36
•
•
•
•
これはユーザや他のプリンシパル (principals) がそれら自身の長期鍵および証明書を管理し、他のプリ
ンシパルの証明書を検索し検証する (validity) ことを可能にする。
プロトコル セキュリティ サービス (Protocol Security Services)
これは、セキュア プロトコル (as secure protocols) のような実装に高度なセキュリティ知識の必要な
(security-aware) アプ リ ケーショ ンの開 発者が 利 用するの に適す る、デ ー タ元認証 (data origin
authentication)、データ完全性保護 (data integrity protection) データ プライバシー保護 (data
privacy protection)、否認防止 ( non-repudiation) といったセキュリティ機能を提供する。
セキュア プロトコル (Secure Protocols)
これは、セキュリティを意識しない (security-unaware) あるいはより高位のレベルの API を用いる
("mildly" security-aware) アプリケーションに対して、セキュアなアプリケーション間通信(secure
inter-application communications) を提供する。
セキュリティ ポリシー サービス (Security Policy Services)
これは、アクセス管理を可能とするためにセキュア プロトコル (secure protocols) で送られるポリシー
関連情報を提供し、また、実装に高度なセキュリティ知識の必要な (security-aware) アプリケーション
がポリシーを強制するためのセキュリティアクセス管理チェック機能を提供する。
サポート サービス (Supporting Services)
これは、セキュアなオペレーション (secure operation) に要求されるが、直接セキュリティ ポリシー
の強制 (security policy enforcement) に関係しない機能を提供する。
備 考 ) 図 は [56], [ 57 ], [ 58 ] の 資 料 を 参 照 。 ま た 、 後 述 5.1 APKI – (Architecture for Public Key
Infrastructure) に構成を示す 2 つの図を載せているので、詳細はこちらの図を参照されたい。
最下層の Cryptographic Primitives のインタフェースには、RSA の BSAFE ライブラリ、X/Open の
GCS-API、Microsoft の CryptoAPI 1.0、Fortezza, IBM CCA をサポート。
また、その上の層、Cryptographic Service Components のインタフェースとして、X/Open の GCS-API、
Microsoft の CryptoAPI1.0、SESAMI CSF API、Cryptoki、RSA の BSAFE がサポート可能。
さらにその上の層、Long-Term Key Services Components のインタフェースとして、
Virtual SmartCard Services:
Services SESAME CFS API, PSM, Microsoft Wallet
PublicPublic-Key Delivery&Verification:
Delivery&Verification SESAME PKM-API, NSA CM-API, Nortel CMS-API, Microsoft
CryptoAPI, Intel CDSA
をサポートする ([2])。
b) 提供するセキュリティの機能
APKI は PKI に対する要求仕様を満たすアーキテクチャと個々のコンポーネントのプロトコル・インタフ
ェース仕様をまとめたものである。APKI で PKI が満たすべき要求を以下にあげる。
b.1) 要求されるサービス
•
•
•
•
•
トラスト ドメインおよびガバナンスの確立 (Establishment of domains of trust and governance)
機密性 (Confidentiality) (封印 (sealing))
完全性 (Integrity) および 認証 (authentication) (署名 (signing))
否認防止 (Non-repudiation)
エンドツーエンドの監視および報告 (End-to-end monitoring, reporting)、PKI サービスの監査
(auditing of PKI services)
b.2) 要求される機能と特徴
•
•
鍵ライフサイクル管理 (Key Lifecycle Management)
① 鍵生成機能 (Key Generation Facility)
② 鍵配布 (Key Distribution)、失効 (Revocation)、一時停止 (Suspension)、否認 (Repudiation)、
保管 (Archive)
③ 鍵リカバリ機能 (Key Recovery Facilities)
分散証明書管理構造 (Distributed Certificate Management Structure)
① ポ リ シ ー 生 成 (Policing) と ポ リ シ ー 強 制 (policy enforcement) ( ガ バ ナ ン ス モ デ ル
(governance model))
② 複数ポリシーの並列サポート (Concurrent support of multiple policies)
③ 証明書交換 (Exchange of certificates)
37
一つの CA からの他の CA に証明書サービスを移行する際のサービス継続性のサポート (Support
for continuance of service in the event of transfer of certificate services from one CA to
another)
⑤ CA 間のクロス証明を確立するための CA ポリシー マッピング サービス (CA policy mapping
services to establish cross-certification between Cas)
⑥ 複数の競合する証明書パスがある場合に証明書の受け入れを決定するための調停のサポート
(Support for arbitration to determine acceptability of certificates in the event of multiple
conflicting certification paths)
⑦ CA 機能とリポジトリ機能の分離のサポート。但し、証明書リポジトリに対するガバナンスポリ
シーの変更に合致するようにそれらはトランザクショナル(例えば 2 フェーズコミットによって)
である必要がある。 (Support for separation of the CA and repository functions in accordance
with the governance policy-changes to certificate repositories must be transactional (for
example, two-phase commits))
PKI のセキュリティ (Security of the PKI)
① 例えば、鍵生成、鍵配布、鍵保管のような、PKI サービスの機密性、完全性、可用性の保護 (Protect
the confidentiality, integrity, and availability of the PKI services; for example, key
generation, key distribution, and key storage)
② 証 明 書 サ ー ビ ス の ア ク シ ョ ン に 対 す る 強 力 な 否 認 防 止 サ ー ビ ス の 提 供 (Provide strong
non-repudiation services for actions of certificate services)
③ PKI サービス自身が自分自身のアクションを否認するのを防止する (Prevent PKI services
themselves from repudiating their own actions)
④ ユーザや受信者が彼らのアクションを否認するのを防止する (Prevent users and subscribers
from repudiating their own actions)
時間サービス (Time Service)
相互運用性 (Interoperability)
① 証明書および関連データに対する国際標準のサポート (Support international standards for
certificates and associated data)
② 証明書サービスに対する国際標準のサポート (Support international standards for certificate
services)
③ 全ての証明書と関連データに対する国際化のサポート (Support internationalization of all
certificates and associated data)
④ 全 て の 証 明 書 サ ー ビ ス に 対 す る 国 際 化 の サ ポ ー ト (Support internationalization of all
certificate services)
④
•
•
•
c) API 数
PKI に対するアーキテクチャとコンポーネントの要求仕様を定めるものであり、現段階で個々のコンポー
ネントの仕様は定まっていない。
d) ベースとなる技術
PKI アーキテクチャ。また、PKI の実装に必要となる以下の標準を推奨している (資料[56])。
d.1) プロトコル
IETF PKIX 管理プロトコル (management protocols)
•
IETF RFC 2511: Internet X.509 Certificate Request Message Format
•
Internet X.509 Public Key Infrastructure Certificate Management Message Formats
•
IETF RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols
•
Certificate Management Messages over CMS
IETF PKIX オペレーション プロトコル(operational protocols)
•
Internet X.509 Public Key Infrastructure Online Certificate Status Protocol
•
Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
•
Internet X.509 Public Key Infrastructure Operational Protocols: LDAPv2
•
Internet X.509 Public Key Infrastructure LDAPv2 Schema
セキュア プロトコル (Secure protocols)
•
IPsec (see Referenced Documents) and IKE (see IETF RFC 2409: The Internet Key Exchange
38
(IKE))
セキュリティ ポリシー サービス (Security Policy Services)
•
Privilege attribute format definitions defined by ANSI X9, OSF DCE, SESAME, and the OMG
CORBASEC1 standard
サポート サービス (Supporting Services)
•
Distributed Audit Service (XDAS)
•
IETF RFC 2030: Simple Network Time Protocol (SNTP)
•
IETF RFC 2251: Lightweight Directory Access Protocol, Version 3 (LDAPv3)
d.2) インタフェース
•
•
•
•
•
•
CDSA 2.0
CA Agent
Local Registration Authority
IETF RFC 2078: The GSS-API, Version 2
XDAS Distributed Audit Service API
C LDAP Application Program Interface
d.3) プロファイル
•
•
•
•
IETF RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
IETF RFC 2478: The Simple and Protected GSSI Negotiation Mechanism
Web transaction security protocols (例えば、SHTTP, HTTPS, HTTP-over-GSS-API, など)
Open Group and IETF based upon the LDAP protocol
e) 利用対象アプリケーション
PKI を実装する様々なプラットフォームのソフトウェア、ハードウェア製品。
f) アプリケーション開発の容易さ
要求仕様を規定するものであるため、具体的な開発の容易さには関係しない。
g) ポータビリティ
APKI は個々の製品に対する仕様を決めるものでないため、ポータビリティを規定するものではない。
ただし、相互運用性は要求されており、これは標準 API と PKI のコンポーネント サービス間のプロトコ
ルの定義に依存性がある、としている ([56])。
h) プラットフォーム
上記 g) と同様、プラットフォームを規定するものではない。
特に、各組織毎に採用あるいは実装する PKI が異なるため、個々のプロファイルを利用する必要がある (資
料[56])。
i) 適用例
APKI は標準仕様策定のための資料であり、今後、PKI に対する標準化が進められていくのと同時に、
APKI の採用する企業、組織が現れると思われる。
j) 推進団体または提案した会社
Open Group の PKI Task Group が作成。
資料に [59] によると、IETF、CommerceNet、European Commission funded projects 等と連携しなが
ら策定をしている、とある。
備考) なお、これとは異なり、NIST、FDIC を推進団体と記述した資料が存在する。
k) 準拠する標準
PKI 開発における証明書 (certificates) のベースとしての X.509v3 ([56])。
39
特に、CDSA 2.0 で定義される サービス インタフェースと IETF ドラフト標準の PKIX シリーズで定
義されるプロトコルを採用。
APKI は以下の標準を使うように推奨している (資料[60])。
•
The PKIX standards
•
The XDAS Distributed Audit Service
•
The LDAP Lightweight Directory Access Protocol
•
The IETF S/MIME Cryptographic Message Syntax (CMS), version 3
•
The IETF (RFC2030) Simple Network Time Protocol (SNTP)
l) 利用コスト
APKI は要求仕様であり特にコストは不要と思われるが、特にライセンスなどコストに関する情報は入手
できなかった。
m) 関連文書の入手可否
最新の仕様書である 1999 年 3 月発行版は Open Group のサイトで参照可能 ([56])。
1997 年 5 月発行の Draft 1 であれば PDF が資料 [57] より入手することができる。
n) 他 API との関係
n.1) CDSA 2.0
APKI は以下の標準の仕様を推奨している (資料[60])。
•
The CDSA 2.0 Common Data Security Architecture
•
The GSS-API Generic Security API and its extensions (XGSS-API)
o) 拡張性
APKI は PKI に対する要求仕様とその候補となるプロトコル、API などを調査・推奨するものであるため、
具体的な拡張性については言及することができない。
ただし、現状世に出ている様々な PKI の部品、製品に対応できるように、拡張性を考慮して検討を進めて
いる。
3.1.6 GSI (Grid Forum)
1) API 名
Grid Security Infrastructure (GSI)
2) 概説
GSI は、サイト間のセキュリティ、つまりローカルで使用可能な最高のセキュリティ・インフラを利用す
るよう設計されている。PACI テストベッドのすべてのサイトが Kerberos を使わなくてもよくするとい
う政治的かつ実用的なニーズから発展した。同様に、サイト・マネージャが常に自分のリソースをコント
ロールできるようにするものであり、それが Grid のインフラを受け入れる要点となっている。
GSI は 1 回のサインオンで Globus ネットワークに入ることができる。
GSI は、ユーザ、リソースまたはプログラムなど各エンティティの ID を表す信用証明を基礎としている。
公的な証明書発行機関は、証明書に署名することにより 1 対の公開キーに ID を結びつける。各リソース
は、入って来るリクエストをどのように受け付けるかというポリシーを指定することができる。そうする
と、GSI は世界的な ID を検証する責任を負い、ローカル・サイトのサブジェクト・ネーム上にこれを位
置付け、アクセス コントロールをそこに委ねる。
40
GSI は、複数の公的信用証明機関と協同で作業し、ユーザの個人カギを IC カードに記憶させることができ
る。GSI を標準的な Web ブラウザに安全に連結する体系がある ([61])。
3) Grid および Globus
Grid は、極めて異質な WAN にあるデータ、コンピュータ処理ができるリソースおよび人間に対する均一
性とアクセスを提供するよう設計されたコンピュータおよびネットワークのインフラストラクチャである。
Globus プロジェクトの狙いは、Grid コンピュータ処理環境を支援するミドルウェア・サービスの提供で
ある。Globus は、現在は膨大な並列処理、膨大な量のデータの操作を必要とするコンピュータ処理作業、
および同期した音楽や動画のストリームが必要な tele-immersion のアプリケーションに使われている
([61])。
Globus には、4 つの主要なコンポーネントがある：
① Grid Security Infrastructure (GSI)
これは、公開鍵のインフラまたは Kerberos を使って認証および認可サービスを提供する。
② Globus Resource Management アーキテクチャ
これは、アプリケーションの要求条件を指定する言語と即時または事前のリソース予約のためのメカニ
ズムを提供する。リモート・マシンにジョブを提出するメカニズムもいくつかある。
③ Globus Information Management アーキテクチャ
これは、リソース情報の発行と閲覧をするための情報サーバの分散型集合体を提供する。リソースの発
見、スケジューリングおよび構成を行う高レベルのサービスによりアクセスする。
④ Globus Data Management アーキテクチャ
これは、GridFTP と呼ばれるユニバーサル・データ伝送プロトコルと共有データ・セットの複数のコピ
ーを管理する複製管理インフラという 2 つのコンポーネントを持っている。
Globus は、Unix 上で使う C-ライブラリのセットである。Globus サービスの中にはマシン上で実行する
のにデーモンを要求するものがある。Globus は、"ツール・バッグ" として、すなわちそれぞれのパーツ
が互いに独立して使えるようにすることを目標に設計されている。
備考) Grid の基本概念については文献[62] が参考になる。
4) Globus
Globus は、広域計算システムのためのツールキットであり、通信ライブラリやディレクトリサービスやリ
ソース管理機構など、比較的低位の機構を提供している。ユーザは Globus の上に実際に使用するシステ
ムを構築する ([63])。
Globus は、認証機構として GSI (Globus Security Infrastructure) を提供している。 GSI には、各サイ
トのローカルセキュリティポリシは変更しない、子プロセスへのアクセス権の伝搬が可能、といった特徴
がある。 Globus にはグローバルな単一のユーザ名空間があり、これをサイトローカルなユーザ名空間に
マップする。サイト内ではサイトローカルのセキュリティ ポリシーにしたがってアクセスコントロールが
行われる。ローカル空間へのマッピングの際に、 Globus が運用する発行機関による証明書にもとづいた
認証が行われる。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
GSI のレイヤード アーキテクチャを示す図を以下に示す ([64])。
41
GSI はセキュリティのインフラストラクチャであるが、これのセキュリティ API として Grid Security
API が定義されている ([65])。
•
既存の標準
- GSS-API (RFC 2743)
•
新しい Grid Forum のドラフト
- GSS-API Extension for the Grid
- GSI Shell API
- GSI GSS-API Mechanism
•
将来
- IDUP-GSS-API (RFC 2479)
- GSI IDUP−GSS-API Mechanism (Grid Forum ドラフト)
Globus Toolkit は この Grid Security API の仕様を元に実装されたライブラリであり、Globus プロジェ
クトが開発を行っている。また、オープンソースのリファレンス実装であり、ツール開発者および Grids 製
造における広いユーザが利用する ([66])。
Globus Toolkit は Release 1.1.3 が最新版であるが、次期版である Globus Toolkit 2.0 β がリリースさ
れている ([67])。
b) 提供するセキュリティの機能
GSI は一言で言うと、アクセスする他のサイトとクレデンシャル (credential) を受け入れるのために統一
した認証と認可のメカニズムを提供する ([68])。
GSI が提供するセキュリティ機能としては以下 ([69])。
•
複数組織の環境における、統一した認証および認可、およびメッセージ保護メカニズム
•
シングル サインオン、権限委譲、ID マッピング (identity mapping)
•
公開鍵技術、SSL、X.509、GSS-API
•
インフラストラクチャのサポート： CA (Certificate Authorities)、証明書および鍵の管理など
Grid セキュリティ サービス として以下があげられる ([65])。
•
SSL-K5, PKINIT
•
K5Cert
•
MyProxy
備考) これらはプロトコルと API によって定義される。
42
Globus Toolkit は、GSI プロトコル上の GSS-API と、証明書管理、ログイン/ログアウトなどのためのツ
ールを提供する ([70])。
c) API 数
RFC2743 の GSI 拡張である draft-ggf-gss-extensions-04.txt は、以下の 5 種類、7 関数 ([71])。
•
Credential Export and Import (2)
gss_export_cred, gss_import_cred
•
Delegation At Any Time (2)
gss_init_delegation, gss_accept_delegation
•
Restricted Delegation Handling (1)
gss_inquire_sec_context_by_oid
•
Context options (1)
gss_set_sec_context_option
•
Housekeeping functions (1)
gss_release_buffer_set
d) ベースとなる技術
Framework API として、Globus の共通ライブラリが次のようなポータビリティと利便のための基本サー
ビスを提供している ([66])。
•
モジュール起動/終了 (Module activation/deactivation)
•
スレッド (Threads)
•
排他制御 (Mutual Exclusion)
•
条件 (Conditions)
•
コールバック (Callbacks)
•
Globus libc
•
利便のためのモジュール (データ構造)
また、GSI のリファレンス実装である Globus Toolkit は以下 ([66])。
•
SSLeay/OpenSSL + GSS-API + SSO/delegation
•
ローカル セキュリティに対するインタフェースのためのツールおよびサービス
- 単純な ACL : Kerberos 5 および AFS にアクセスするための SSLK5/PKINIT など
•
クレデンシャル管理のためのツール
- ログイン、ログアウトなど
- スマートカード
- MyProxy: Web ポータル ログインおよび権限委譲 (delegation)
- K5cert: オートマチック X.509 証明書生成
e) 利用対象アプリケーション
Grid コンピュータ処理環境においてリソース共有を必要とするアプリケーション。
前述したように Globus では、現在は膨大な並列処理、膨大な量のデータの操作を必要とするコンピュー
タ処理作業、および同期した音楽や動画のストリームが必要な tele-immersion のアプリケーションに使
われている ([61])。
f) アプリケーション開発の容易さ
GSS-API は特定のセキュリティ実装に依存しないように作られているため、使いやすくない ([70])。
Globus Toolkit の GSS-API は、Kerberos 5 GSS-API とほぼ同じであるため、同じアプリケーションで
はほぼ修正なくどちらかに置き換えることができる。
GSS-API に比べて Globus Toolkit は使いやすく、簡単にセキュリティ機能を追加することができる。例
えば、GSS-API の単純なラッパーである globus_gss_assist 関数をあげることができる。
43
また、資料[69] では、GSI の採用が数 100 サイト、数 1000 ユーザにのぼるとしている。
g) ポータビリティ
Globus Toolkit は C++でなく C で実装されている ([64])。それは、以下の理由からである。
•
ポータビリティ
- C++コンパイラーのほとんどが完全な ANSI C++標準をサポートしていない。
- これは改善されるが、現状の C++は高度にポータブルなコードを作成するのは苦手である。
•
リンケージ
- C++ライブラリでは Fortran とのリンクが難しい
•
言語固有の性質
- C++よりも良い C のコーディング方法で充分
なお、GSS-API は Kerberos と PKI の両方に対応しており、GSS-API で開発したからと言ってこれらの
相互運用性は保証されない。一方、Globus Toolkit が提供する GSP (Grid Security Protocols) により
Kerberos と PKI の両方の相互運用性が保証される。
また、[72] に GSI の Java 言語実装に関する資料がある。
h) プラットフォーム
Globus Toolkit, Release 1.1.3 のプラットフォームは以下 ([73])。
•
AIX 4.2.1
•
Red Hat Linux 6.1
•
IRIX 6.5
•
Solaris 7
•
UNICOS/mk 2.0.4 (Cray T3E)
•
AIX 4.3.3 (IBM SP)
「Globus インストールマニュアル日本語版」によると以下 ([74])。
•
AIX 4.2.1, AIX 4.3
•
FreeBSD
•
HPUX 10.x, 11.01
•
Digital UNIX 4.0
•
IRIX 6.4, IRIX 6.5
•
Linux (requires GNU Libc 2 or greater for threads)
•
SPP-UX 5.3 (Convex Exemplar)
•
Solaris 2.5, Solaris 2.5.1, Solaris 2.6
•
UNICOS/mk 2.0.3.39 on Cray T3E (MLS to be supported in Globus 1.0.2)
i) 適用例
関連プロジェクトの一覧 ([75])：
Grid Infrastructure R&D Projects
•
The EcoGRID (Economy Grid) project at Monash University
•
The Legion project at the University of Virginia
•
The Polder project at the University of Amsterdam
•
The MOL project at the University of Paderborn
Computational Grids (活動中または開発中のもの)
•
The ASCI Distributed Resource Management (DRM) Environment
•
The Earth Systems Grid (ESG)
•
The European DataGrid
•
The Grid Physics Network (GriPhyN)
•
The NASA Information Power Grid (IPG)
•
The National Computational Science Alliance
44
•
The National Partnership in Advanced Computational Infrastructure
•
The Network for Earthquake Engineering Simulation Grid
Grid アプリケーションおよびライブラリ
•
AppLeS (University of California at San Diego)
•
The Cactus Computational Toolkit
•
CAVERNsoft (University of Illinois at Chicago)
•
Condor (University of Wisconsin at Madison)
•
Grid Application Development Software (GrADS)
•
Grid Portals Collaboration (NASA, NCSA, SDSC)
•
NEOS (Argonne National Laboratory)
•
Netsolve (University of Tennessee)
•
Nimrod/G (Monash University)
•
PUNCH (Purdue University)
商用の Grid 活動
•
Avaki
•
Entropia
•
Gridware (Sun Microsystems)
i.1) 推進企業
[76] にあるように、米国の Compaq、Cray、SGI、Sun Microsystems、Veridian、日本の富士通、日立、
NEC、の 8 つの企業が Globus Toolkit の採用を計画している。また、Entropia、IBM、Microsoft とい
う米国企業がこれまで以上に推進することを発表している。
Platform Computing Inc on Nov. 7 announced that it will collaborate with Globus to provide a
commercially supported version of the Globus Toolkit.
のように合計 12 の企業が Globus Toolkit をサポートする。
i.2) GSI アプリケーション
•
•
•
•
Globus Toolkit は、認証のためにリソース管理、データ管理などの全ての関数により GSI を利用して
いる。
多くのツール
- Condor, SRB, MPICH-G2 など
商用およびオープンソースのツール
- Condor, SRB, MPICH-G2 など
- SecureCRT (Win32 ssh クライアント)
次で使われる X.509 のクレデンシャル
- Web アクセス、LDAP サーバ アクセスなど
([66])
i.3) Grid プログラミング技術の例
•
MPICHMPICH-G2:
G2 Grid 対応のメッセージ パッシング (message passing)
•
CoG Kits, GridPort:
GridPort N-tier アーキテクチャをベースにしたポータル構築
•
GDMP, Data Grid Tools, SRB:
SRB レプリカ管理、コレクション管理
•
CondorCondor-G: ワークフロー管理
•
Legion:
Legion Grid コンピューティングのためのオブジェクト モデル
•
Cactus:
Cactus Grid 対応の数値計算フレームワーク (numerical solver framework)
上記はプレゼン資料[69] からの引用であるが、これらの適用例に関するさらに詳しい情報も [69] に掲載さ
れている。
j) 推進団体または提案した会社
j.1) Globus プロジェクト
Globus プロジェクトのサイトは [77] である。
Globus プロジェクトは 科学および工学におけるコンピュータ利用に対し Grid コンセプトの適用に焦
点を当てた R&D プロジェクトである ([78])。現在、世界中のチームが Globus Toolkit を用いて Grids を
45
構築したり、Grid アプリケーションを開発したりしている。
Globus Project の研究はこれらの活動からあがってくる技術的な課題にターゲットを絞っている。
典型的な研究対象は、リソース管理、データ管理、アクセス管理、アプリケーション開発環境、情報サー
ビス、セキュリティである。
Globus Project のソフトウェア開発の成果が Globus Toolkit という、Grids と Grid アプリケーション
をサポートするための サービスおよびソフトウェアのセットである。このツールキットには、セキュリテ
ィ、情報 インフラストラクチャ、リソース管理、データ管理、コミュニケーション、フォールト ディテ
クション、ポータビリティのためのソフトウェアが含まれている。
Globus プロジェクトチームは、Argonne National Laboratory、The University of Chicago、University
of Southern California Information Sciences Institute 、High Performance Computing Laboratory
Northern Illinois University、National Center for Supercomputing Applications at the University of
Illinois Urbana-Champaign、onal Aeronautics and Space Administration から参加 ([79])。また、協力
者 ([80]) とスポンサー ([81]) がいる。
j.2) Grid Forum
Global Grid Forum, Grid Security Infrastructure (GSI) Working Group, Grid Forum Security Area
で GSI に関する活動が行われている (サイトは[82])。
資料[68] によると、Grid Computing を実現するために、情報交換や提言、メンバー間のリソース共有を
目的に創設されたセミフォーマルの組織である。
前述 j.1) の Globus や IPG, NTG, DISCOM, Legion, CORBA などの特定のイニシアチブには焦点を当
てておらず、むしろ Grid Computing を成功させるためのインフラやアイデアに焦点を当てたオープンで
包括的な組織であり、IETF のような「ラフなコンセンサスと実行コード」に焦点を当てている。
1998 年に創設され、2001 年の GGF-3 の時点で、220 の登録者、150 の組織、20 の国が参加している。
スポンサーには、企業から Sun Microsystems、Microsoft、Compaq、Intel、富士通などが参加し、企業
以外からは Argonne/UChicago、NASA NAS/IPG、WTCW、NCSA、DOE-OSCR などが参加している。
k) 準拠する標準
準拠する標準
GSI は SSL/TLS、PKIX(X.509 など)、GSS-API の標準をベースにし、シングル サインオン (Single
Sign-on) と権限委譲 (Delegation) のためにこれらを拡張している ([65])。
Security API は GSS-API の draft-ietf-cat-gssv2-cbind-04.txt に準拠 ([83])。
また、標準ではないが、Information Service API は OpenLDAP Version1.2 を利用。
GSI 用に RFC 2743 を拡張した 「GSS-API 拡張 (GSS-API Extension)」 の仕様を策定している ([84])。
関連する IETF 文書として以下があがっている ([82])。
•
Cryptographic Message Syntax (RFC 2630)
•
Generic Security Service Application Program Interface, Version 2, Update 1 (RFC 2743)
•
Generic Security Service API Version 2: C-bindings (RFC 2744)
•
Independent Data Unit Protection Generic Security Service Application Program Interface
(IDUP-GSS-API) (RFC 2479)
•
The Kerberos Network Authentication Service (V5) (RFC 1510)
•
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol ? OCSP (RFC 2560)
•
Internet X.509 Public Key Infrastructure, Certificate Management Protocols (RFC 2510)
•
The Simple Public-Key GSS-API Mechanism (SPKM) (RFC 2025)
•
The TLS Protocol, Version 1.0 (RFC 2246)
•
Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 2459)
l) 利用コスト
GSI はバージョン 1.1.3a が [85] から入手できる。
46
the Grid Security Infrastructure (GSI) は Globus Metcomputing Toolkit のサブセットであり、以下の
コンポーネントを含む ([85]の README.GSI)。
•
The Globus SSLeay GSSAPI library for authentication and communication integrity protection.
•
The Globus GAA library for authorization control.
•
Tools for managing X509 certificates for use with the GSSAPI library.
Globus Toolkit は最新版 Relase 1.1.3 および 次期版、Globus Toolkit 2.0 Beta Release が [67] から入手
できる。
m) 関連文書の入手可否
GSI に関連する仕様書などの文書が Grid Forum のサイト [82] からダウンロードできる。また、Globus
の [86] からも説明資料や仕様書などの参考資料が入手できる。
また、Globus Toolkit の関連文書は [87] から無料でダウンロードできる。
n) 他 API との関係
n.1) GSS-API
前述のように、Grid Security API は GSS-API をベースにこれを拡張している。
n.2) GAA-API
Globus 1.1 では、CA Signing Policy のために GAA-API を利用しており、将来その利用を拡張する予定
である ([88])。
o) 拡張性
GSI に関して拡張性に触れた資料はこれまでの調査で見つかっていない。
3.2 セキュリティ サービス API (Security Service API)
3.2.1 GSS-API (Open Group)
1) API 名
Generic Security Service API (GSS-API)
2) 概説
GSS-API は,さまざまな異なったセキュリティメカニズムによって供給されるサービスへの汎用的なイン
タフェースを提供するものである。
GSS-API の基本的な目的は以下ものである。
•
メカニズム独立:
メカニズム独立 GSS-API は基盤となるメカニズムとは独立した他のセキュリティサービスに対する
一般的なレベルのインタフェースを定義する。 例えば GSS-API-provided サービスは秘密鍵技術(例
えば Kerberos)、あるいは公開鍵アプローチ (例えば X.509) によって実装される。
•
プロトコル環境独立:
プロトコル環境独立 GSS-API は通信プロトコルと独立で,広範囲なプロトコル環境で使うことがで
きる。
•
プロトコル アソシエーション独立
アソシエーション独立:
エーション独立 GSS-API のセキュリティコンテキストの構築は, 通信プロトコル
のアソシエーションの構築とは独立である。 この特徴は,様々な呼び出しプロトコルによって利用さ
れる単一の GSS-API 実装を可能にする。
47
•
広範囲な実装配置への適合性:
広範囲な実装配置への適合性 GSS-API クライアントはトラステッド コンピューティング ベース
(TCB) 内に存在することを強制されない。
(資料[2])
GSSAPI はセキュアなアプリケーション開発を効率化する汎用インタフェースを提供する。
GSS-API 自身がセキュリティを提供するものではない。GSS-API はネットワーク上で通信を行うアプリ
ケーションが必要とする ID 認証 (identity authentication) とメッセージ保護 (message protection) と
いう実際のサービスを提供する基礎となる技術に依存している。このような技術は GSS-API セキュリテ
ィ メカニズムと呼ばれている。アプリケーションは特定のメカニズムをインストールないし要求して利用
するか、または GSS-API 実装によって提供されるデフォルトのメカニズムを利用する。デフォルトのメカ
ニズムは一般的には Kerberos である ([89])。
セキュリティ メカニズムはグローバルに一意であるオブジェクト識別子、OID によって識別される。例
えば、Kerberos メカニズムの OID は“1.2.840.113554.1.2.2”、SPKM-1 の OID は “1.3.6.1.5.5.1.1”
である。
GSS-API は ネ ッ ト ワ ー ク 認 証 (network authentication) お よ び セ キ ュ ア メ ッ セ - ジ ン グ (secure
messaging) を汎用インタフェースにより提供する。この活動の参加者はプリンシパル (principal) と呼ば
れる。プリンシパル (principal) は名前によって識別され、実ユーザまたは無人サービス (unattended
service) のどちらかとされる。
プリンシパル (principal) の識別を確証するプロセスは 認証 (authentication) および クレデンシャルに
よる結果 (results in credentials) と呼ばれる。プリンシパルは GSS-API ピアツーピア認証で使われるメ
カニズム固有のクレデンシャル (credentials) を得るために、メカニズム固有の認証を受ける。このため、
次の 3 種類の GSS-API クレデンシャルが存在する:
•
コンテキスト初期化のための Initiator credentials
•
コンテキスト受け入れのための Acceptor credentials
•
コンテキストの初期化および受け入れの両方に使われる Initiator and acceptor credentials
GSS-API は IETF (Internet Engineering Task Force) により開発され、Open Group でも採用されている
API である。この仕様は認証、完全性、秘密性用に 20 個の API が用意されている ([2])。
3) 背景
ネットワーク上のエンティティ間の認証およびセキュアなメッセージ交換の必要性が長い間認識されてお
り、この問題を解決するために、今日、数多くのセキュリティおよび暗号化のメカニズムが存在する。
このメカニズムは、秘密鍵 (secret-key)、公開鍵 (public-key)、あるいは、これ以外のセキュリティ技術
を用いている。
共通鍵 (秘密鍵) メカニズムの例に Kerberos V5 GSS-API があり、公開鍵メカニズムに Simple Public
Key GSS-API Mechanism (SPKM) があり、秘密鍵および公開鍵の両方の技術を提供するメカニズムに
Secure European System for Applications in a Multi-vendor Environment (SESAME) がある (資料
[89])。
4) 歴史
GSS-API は Internet Engineering Task Force (IETF) の Common Authentication Technology
Working Group (cat-wg) で開発されているドラフトインターネット標準である。 GSS-API の最初の仕様
が 1993 年 9 月に RFC 1508 と RFC 1509 として発行された。この仕様は X/Open でも採用されている。
また KerberosV5 GSS-API やいくつかの修正が RFC として標準の過程にあり,さらに IDUP-GSS-API
や XGSS-API などのドラフトが発行されて仕様の策定が進められている。
X/Open はその後、RFC 1508 と 1509 をマージして、文書番号 C441 という仕様書を発行した ([90])。
C441 は RFC 1508/1509 の関数名変更をしただけで仕様見直しは行われておらず、
また、
IETF の GSS-API
との整合性も考慮されていない。この不満足な状況を改善するために、C441 に対する正誤表の発行が期待
48
された。
5) GSS-API の適用
GSS-API は汎用の API であり、これを特定の分野に適合した仕様として以下の 2 種類がある。
•
RFC 1964、"The Kerberos Version 5 GSS-API Mechanism" ([91])
•
RFC 2025、"The Simple Public-Key GSS-API Mechanism" ([92])
以下に、この 2 つを比較した説明を資料 [93] から引用する。
5.1) Kerberos
Kerberos はイントラネット サイズのネットワーク (初期には MIT ネットワークの認証・認可メカニズム
として) 利用されることを想定して設計された。これは共通鍵アルゴリズム (例えば DES) をベースにし
ているため、鍵配布は公開鍵メカニズム (特に大規模ネットワークで) の場合よりも非常に複雑である。
5.2) SPKM
一方、SPKM はインターネット サイズのネットワークに適応した標準である。すなわち、X.509 証明書
(X.509 certificates) と公開鍵暗号 (asymmetric cryptography) を用いる X.509 認証フレームワーク
(authentication framework) インターネット サイズのネットワークをサポートする成熟度と能力は、PKI
(X.509) (pkix) IETF ワーキンググループで示されており、これは X.509 ベースの PKI をサポートする必
要のあるインターネット標準の策定に功を奏している。
鍵 管 理 と 認 証 に PKI を 用 い る 必 要 性 か ら Kerberos IETF ワ ー キ ン グ グ ル ー プ は Public Key
Cryptography for Initial Authentication in Kerberos (PKINIT) というインターネット標準を公開した。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
GSS-API の構成を示すものではないが、APKI に関するプレゼン資料 [58] の 19P に、GSS-API、
IDUP-GSS-API、GSS-NEGO、XGSS-API (Extended GSS-API) と Kerberos、SPKM、SESAME の関
係を図示した構成図があるので、これを下に引用する。
49
b) 提供するセキュリティの機能
認証、完全性、機密性。
Base GSS-API は以下の機能をアプリケーションに提供する([90])。
•
ピア アプリケーション (peer application) に関連しプリンシパル アイデンティティ (principal
identity) の認証 (Authenticate)
•
ピアに対する権利の委任 (Delegate)
•
機密性および完全性のようなセキュリティ サービスをメッセージ単位ごと (per-message basis) に
適用する。
また、GSS-API を改善 (エンハンス) する以下の補足的なインタフェースが提案された。
•
PACi と認可 (Authorization) サービスの利用
•
セキュリティ属性 (Security Attribute) と委任 (Delegation) のためのインタフェース追加
c) API 数
以下の 4 種類、34 関数([94])。
•
Credential management calls (5 関数)
•
Context-level calls (9 関数)
•
Per-message calls (4 関数)
•
Support calls (16 関数)
備考) 資料[2]では、次の 20 個の API、とされていた:
GSS_Acquire_cred,
GSS_Release_cred,
GSS_Inquire_cred,
GSS_Init_sec_context,
GSS_Accept_sec_context, GSS_Delete_sec_context, GSS_Process_context_token, GSS_Context_time,
GSS_Sign, GSS_Verify, GSS_Seal, GSS_Unseal, GSS_Display_status, GSS_Indicate_mechs,
GSS_Compare_name,
GSS_Display_name,
GSS_Import_name,
GSS_Release_name,
GSS_Release_buffer, GSS_Release_oid_set
d) ベースとなる技術
[95]では、下図のように SPKM および Kerberos をベースとしその上のインタフェースとして定義されて
いる。
i
PAC は Privilege Attribute Certificate のことで、詳しくは用語 PAC で解説している。
50
e) 利用対象アプリケーション
分散処理サービスにセキュリティを導入する必要のあるアプリケーション ([90])。
f) アプリケーション開発の容易さ
後述の「メカニズム独立」などにより抽象的なレベルのインタフェースを使って容易にアプリケーション
にセキュリティ機能を実装することができる。
その一方で、多すぎるパラメータや、パラメータ構造における多過ぎるネスティングなどのため、
「複雑過
ぎる」という評価があるが、多くの場合デフォルト値が決まっているのでこれを考慮する必要がない ([96])。
g) ポータビリティ
RFC 2744 が C 言語、RFC 2853 が Java に適用した仕様である。また、オープンシステムに適する ([90])。
GSS-API は呼び出し側に汎用的な形式でセキュリティ サービスを提供し、基礎となるメカニズムおよび
技術をサポートし、異なる環境に対してソースレベルのポータビリティを与える ([94])。
h) プラットフォーム
マルチプラットフォーム。ただし、C 言語および Java 言語で仕様が規定。
i) 適用例
1996 年当時の文献 [90] による適用製品としては以下。
•
OSF DCE1.1
RPC 非対応アプリケーションが DCE セキュリティ サービスにアクセスできるように、OSF DCE1.1
には GSS-API 実装が含まれる。OSF/DCE1.1 ベンダーが DCE1.1 上に実装する予定。
•
Microsoft Windows NT
1995 年、Microsoft Windows NT 上に Kerberos V5 対応の GSS-API が実装される予定。
•
IBM NetSP
1996 年当時、KryptoKnight 上に IBM NetSP を実装中。
•
OCSG/CyberSafe Kerberos
1996 年当時、Kerberos V5 上に OCSG/CyberSafe Kerberos を実装中。
•
SESAME ベンダーが SESAME 上に実装
i.1) Sun, Solaris 8
http://www.sun.co.jp/products/newprod/2000/06/0323.html
i.2) EVIDIAN (Subsidiary of Groupe Bull), AccessMaster
http://www.evidian.com/accessmaster/secpol/features.htm
i.3) "PyGSS"
GSS-API の Python 言語実装 (Pyhton bindings for the GSS-API)、つまり Python 言語で GSS-API を
利用可能にするもの ([97])。
初期の GSS-API の Python 言語実装は MIT の Kerberos V5 GSS-API メカニズム上のラッパー インタ
フェースであった。
i.4) NEC、
、SecureWare/認証キット
認証キット
インターネットおよびイントラネット上でのクライアント/サーバ間のユーザ認証やデータ暗号化機能を
実現するためのセキュリティライブラリを提供する。特に、インターネット上で SOCKS による VPN
(Virtual Private Network) を構築する際に、よりセキュリティ強度を高めるために高度な認証/暗号を施
す ([2])。
i.5) SECUDE
51
SECUDE の Toolkit が GSS-API を含む ([98])。
i.6) Entrust、
、Entrust Authority
GSS-API Toolkit for C ([99])
i.7) SunSoft、
、WebNFS
RFC 2203 ([ 100 ])は GSS-API にアクセス可能にする RPC プロトコルの仕様であるが、Solaris NFS
Security Framework および WebNFS Security Framework はこの RFC 2203 である RPCSEC_GSS
に準拠している。
j) 推進団体または提案した会社
IETF CAT WG が最初の仕様を RFC1508 および RFC1509 として作成し(資料[101]、[102])、その後の仕様
の拡張、バージョンアップを行っている。
なお、RFC 1508 は RFC 2078 により無効になっており、さらに RFC 2048 は RFC 2743 により無効にな
っている。
また、Open Group では IETF の策定した仕様を "GSS-API (Base)" Preliminary Specification として採
用している。
備考) Open Group の出版する仕様書では IETF のものの名前を変更するのみで、基本的な仕様については
IETF が定める仕様に従っている。
k) 準拠する標準
IETF の RFC 2743 ([94])、RFC 2744 ([103])、RFC 2853 ([104])として標準化されている。
SPNEGO (Simple And Protected GSS-API Negotiation Mechanism) が RFC 2478 として提案 ([105])。
また、GSS-API 適用に関する標準に、前述の IETF RFC 1964、2025 がある。
l) 利用コスト
仕様書の入手および利用に関しては無料である。
リファレンス実装については公的機関からリリースされているフリーのものを検索できなかった。
m) 関連文書の入手可否
RFC については、IETF のサイト (資料[106]) より入手可能。(また、RFC については資料[107] であげたサ
イトからも検索、ダウンロードが可能である) 。
Open Group の出版する仕様書[21]、文献[108]、仕様書[90]、などは [109] のサイトから資料を取り寄せるこ
とができる。また、仕様書[90] については文献[108] に同梱の CD-ROM に PDF および PostScript 形式の
電子ファイルとして納められている。
n) 他 API との関係
n.1) IDUP-GSS-API
3.2.5 IDUP-GSS-API (IETF) に記述。
n.2) SGSS-API
SESAME GSS-API の略。
UIUC SESAME は Java でフル実装された SESAME のポータブル版である。
SESAME は GSS-API 標準を採用しているため、UIUC SESAME のために SESAME GSS-API の Java
実装が必要となった。
これは、UIUC SESAME を利用するアプリケーションのためのインタフェースを提供すると同時に、開発
者から UIUC SESAME 実装の詳細を隠す働きをしてくれる ([110])。
n.3) GSI (Grid Security Infrastructure)
3.4.1 GAA-API (IETF) における n.3) GSI の説明を参照。
52
n.4) SASL GSSAPI
[111] 参照。
n.5) Java SASL API
Java SASL API は SASL メカニズムのためのクラスとインタフェースを定義する。これは、開発者が
SASL を用いたコネクション ベースのプロトコル用の認証サポートを追加するために使われる ([112])。
n.6) SESAME
SESAME プロジェクトは、ECMA TC36/TG9 "Security in Open Systems" の作業をベースにしており、
GSS-API のサポートとこれの拡張を利用している (文献[90])。また、ECMA TC36/TG9 グループは、
Association Context Management スタンダードの開発にあたり、 GSS-API サポートを考慮して作成し
た。
o) 拡張性
拡張性ではないが、相互運用性として、1996 年当時、Kerberos V5 ベースの実装、DCE 1.1 ベースまたは
SESAME ベースの実装、との相互運用性のみ対応 ([108])。
拡張性は上述 h) で書かれたメカニズム独立の特徴により、Kerberos や SPKM などの特定のメカニズムへ
の対応をサポートできる点にある。
3.2.2 CryptoAPI 2.0 (Microsoft)
1) API 名
Microsoft CryptoAPI
2) 概説
Microsoft Windows の暗号レイヤーで、その下にある Cryptographic Service Providers (CSP) が実際の
暗号化タスクを実行する ([113])。
Microsoft 社から提供される CSP には以下の 2 つを始め、8 つの CSP が提供されている (資料[114])。
① Microsoft Base Cryptographic Provider
② Microsoft Enhanced Cryptographic Provider
この内、Microsoft Base Cryptographic Provider が CryptoAPI に同梱されており、他の CSP を指定しな
い場合のデフォルトの CSP として使われる。
また、CSP は各ベンダーがより強力な暗号アルゴリズムを提供したり、スマートカードなどのハードウェ
アをサポートしたりするために提供される。
3) 歴史
資料[2] によると、現在の CryptoAPI 2.0、および、CAPICOM が提供される前の段階では、CryptoAPI 1.0
と CryptoAPI 2.0 が並存し、これが資料[2]にある CryptoAPI アーキテクチャを構成する形を取っていた。
しかし、現在、Microsoft からは、CryptoAPI 1.0 の仕様は公開されておらず、また、CryptoAPI 2.0 の
仕様は、過去の CryptoAPI 1.0 および 2.0 と異なる以下の対応となっている。
•
過去の (つまり、オリジナルの) CryptoAPI 1.0 が現在の CryptoAPI 2.0 の "Base Cryptography
Functions" に移行し、なおかつ、新しい関数が追加された。
•
過去の (つまり、オリジナルの) CryptoAPI 2.0 が現在の CryptoAPI 2.0 の "Certificate and
Certificate Store Functions " など残りの分類の関数に移行、分類され、さらに新しい関数が追加さ
れた。
つまり、過去の CryptoAPI 1.0 および 2.0 がマージされ、かつ、機能強化され、現在の CryptoAPI 2.0 の
仕様を構成している、と言うことが可能である。
この事情は、Microsoft からは資料[113]の "What's New in CryptoAPI" のページに簡単に説明されている。
53
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
(Application)
|
CryptoAPI 2.0
|
CSP
また、[113] の "CryptoAPI System Architecture" より CryptoAPI 2.0 の構成図を引用しておく。
また、関数の機能別分類はリファレンスに書かれた分類を後述の c) API 数 に挙げているが、資料 [113] の
図中で使われている以下をあげておく。
•
•
•
•
•
•
基本暗号化関数 (Base Cryptographic Functions)
CSP に接続するためのコンテキスト関数 (Context Functions)。
これらの関数はアプリケーションが特定の CSP を名前で選択できるようにしたり、必要な機能のクラス
を提供する特定の CSP を設定したりということを可能にする。
備考) コンテキスト、クラスという概念については説明が必要かもしれない。しかし、文献[115]にあるよ
うな説明をしないと簡単に説明するのは難しい。
暗号化鍵 (Cryptographic keys) を生成、格納するための鍵生成関数 (Key generation functions)。
この関数には、Chaining modes、initialization vectors などの暗号化に必要な機能を含んでいる。
この関数が後述の "Key Generation and Exchange Functions" の分類に属す。
鍵を交換、送信するための鍵交換関数 (Key exchange functions)。
この関数が後述の "Key Generation and Exchange Functions" の分類に属す。
証明書エンコード/デコード関数 (Certificate encode/decode functions)
データのエンコード、デコードに使われる関数。これには、データをハッシュする関数が含まれる。
この関数が後述の "Data Encryption/Decryption Functions" の分類に属す。
証明書保管関数 (Certificate store functions)
デジタル証明書 (Digital Certificates)の集合を管理する関数。
54
この関数が後述の"Certificate Store Functions"の分類に属す。
単純化メッセージ関数 (Simplified message functions)
メッセージおよびデータの暗号化、復号化を行う関数。メッセージおよびデータに署名 (Sign) を行う
関数。受信メッセージおよび関連データの証明 (signatures) の真正性 (Authenticity) を確認するため
の関数。この関数がこの "Simplified Message Functions" に属す。
•
低レベル メッセージ関数 (Low-level message functions)
単純化メッセージ関数 (simplified message functions) によって実行されるタスクを処理するのに使わ
れる関数。
低レベル メッセージ関数 (Low-level message functions) は 単純化メッセージ関数 (simplified
message functions) より柔軟性があるが、より多くの関数呼び出しを必要とする。この関数がこの
"Low-Level Message Functions" に属す。
•
備考) 資料[2]などで CryptoAPI のアーキテクチャを説明する図が過去の資料で引用されているが、前述
のように現時点の CryptoAPI では CryptoAPI 1.0 と 2.0 が統合されて CryptoAPI 2.0 に一本化されて
いるため、この図はもはや現状に即していない図となっている。
b) 提供するセキュリティの機能
•
•
•
•
•
基本的な暗号化機能 (Cryptography)
これは、後述の 基本暗号化関数 (Base Cryptography Functions) に属する関数により提供される。
デジタル証明書 (Digital Certificate)
PKCS#7 のエンコード、デコード
証明書ストア (Certificate Store)
メッセージ管理 (Message Management)
下の 4 つの機能は CryptoAPI 2.0 で追加された関数。(ただし、Microsoft のページでは元の CryptoAPI
2.0 なのか現状の CryptoAPI 2.0 かの区別がされていない)。
また、セキュア コミュニケーションにおける 3 つの重要な要素である以下と上記は次のような対応となる。
•
プライバシー (Privacy)
− 暗号化機能
•
完全性 (Integrity)
− 暗号化機能
•
認証 (Authentication)
− デジタル署名
Microsoft が提供する CSP により、以下の暗号化を提供する。
•
RSA public-key signature algorithm 512 bits、 1,024 bits
•
RSA public-key exchange algorithm 512 bits、 1,024 bits
•
RC2 block encryption algorithm 40 bits、 128 bits
•
RC4 stream encryption algorithm 40 bits、 128 bits
•
DES 56 bits
•
Triple DES (2 key)
•
Triple DES (3 key)
c) API 数
CryptoAPI 2.0 が提供する関数は以下の 5 種類に大きく分類されており、合計 246 関数を含んでいる([113])。
c.1) Base Cryptography Functions (40 関数)
関数
基本的な暗号化関数で、以下の 5 種類に分類されている。
•
Service Provider Functions (12 関数)
CSP との接続/切断
•
Key Generation and Exchange Functions (11 関数)
暗号鍵 (cryptographic key) の生成、構成、破壊を行う鍵生成 (Key Generation Function) と他のユー
ザと鍵交換するか鍵交換関数 (Key Exchange Function)。
•
CryptEncodeObject/CryptDecodeObject Functions (4 関数)
汎用のエンコード、デコード関数で、証明書 (certificates)、CRL (certificate revocation lists)、証明書
リクエスト (certificate requests)、証明書拡張 (certificate extensions) をエンコード、デコードするの
55
に使われる。
Data Encryption/Decryption Functions (4 関数)
暗号化、復号を行う。
•
Hash and Digital Signature Functions (9 関数)
ハッシュ (メッセージ ダイジェスト) の計算、デジタル署名の生成および確証を行う。
•
c.2) Certificate and Certificate Store Functions (70 関数)
関数
証明書 (certificates)、CRL (certificate revocation lists)、CTL (certificate trust lists) の使用、格納、 検
索を行う。
•
Certificate Store Functions (17 関数)
証明書に格納された情報の検索、列挙、確証、および利用。
•
General Maintenance Functions (5 関数)
汎用の certificate 関数および certificate store 関数。
•
Certificate Functions (17 関数)
証明書に関連する関数で、CRL および CTL を操作する。
•
Certificate Revocation List Functions (12 関数)
CRL (certificate revocation lists) の格納、検索を行う関数。
•
Certificate Trust List Functions (10 関数)
CTL (certificate trust lists) の格納、検索を行う関数。
•
Extended Property Functions (9 関数)
証明書、CRL、CTL の拡張プロパティを操作する関数。
c.3) Certificate Verification Functions (14 関数)
関数
証明書確証のための関数で、CTL と certificate chains を用いるものの 2 種類がある。
•
Functions Using CTLs (4 関数)
確証プロセスにて CTL を使う関数。
•
Certificate Chain Verification Functions (10 関数)
証明書チェーン (certificate chains) は個人認証に関しての信用できる情報を提供するために構築され
る。この証明書チェーン (certificate chains) を作成し操作する関数。
c.4) Message Functions (25 関数)
関数
メッセージ関数で下の 2 種類に分類される。
•
Low-Level Message Functions (12 関数)
PKCS #7 メッセージを直接、作成、操作する関数。PKCS #7 データのコード化、デコード化を行った
り、受信メッセージの証明書の復号および確証を行ったりする。
•
Simplified Message Functions (13 関数)
Low-Level Message Functions よ り 上位 の関 数 で 、い くつ か の low-level message functions と
certificate functions を組み合わせて一つの関数にしたもの。
メッセージ暗号化 (message encryption)、復号化 (decryption) 、署名 (signing) および署名確 証
(signature verification) 関数のようなメッセージ管理関数 (Message management functions)。単純化
メッセージ関数 (Simplified message functions) は基本暗号化関数 (base cryptographic functions) や
低レベル メッセージ関数 (low-level message functions) よりも上位のレベルで処理を行う。単純化メ
ッセージ関数 (Simplified message functions) は基本暗号関数、低レベル メッセージ関数、証明関数
(certificate functions) のいくつかを、PKCS #7 メッセージやメッセージの署名 (signing a message) の
ような特定の方法で特定のタスクを実行する単一の関数にラップする。
c.5) Auxiliary Functions (97 関数)
関数
上記の分類に含まれない付加的な関数。
•
Data Management Functions (32 関数)
データと証明書の管理を行うために使う補助関数。
•
Data Conversion Functions (9 関数)
証明書の構造メンバー (structure members) を別の形式に変換する関数。
•
Enhanced Key Usage Functions (4 関数)
enhanced key usage (EKU) 拡張と証明書 EKU 拡張プロパティを操作する関数。
EKU 拡張と拡張プロパティは証明書の正当な利用法を規定し制限する。
証明書拡張プロパティ (Certificate extended properties) はアプリケーションに設定される証明書に関
連した値を指す。
56
•
•
•
•
•
Key Identifier Functions (4 関数)
キー識別子 (key identifier) の生成、設定、検索、特定を行う関数。
キー識別子 (key identifier) とは公開/秘密鍵のペアを一意に識別する識別子である。
Certificate Store Provider Callback Functions (24 関数)
アプリケーション固有の certificate store provider を登録、すなわち、インストールし、関連する機能
を実行するために使うコールバック関数である。
コールバック関数 (Callback functions) とはアプリケーションとしてプログラミングされ、CryptoAPI
の関数から呼び出される。
OID Support Functions (17 関数)
オブジェクト識別子 (OID) をサポートする関数。
OID のインストール、登録、ディスパッチを行い、型固有の関数 (type-specific functions) をエンコー
ドする。
Remote Object Retrieval Functions (2 関数)
Public Key Infrastructure (PKI) オブジェクトを検索し、証明書 (certificate) や CTL、CRL の URL
取り出しや、オブジェクトからの URL 抽出を行う。
PFX Functions (5 関数)
PFX BLOBs をサポートする関数。
d) ベースとなる技術
実際の CSP により暗号技術が提供されるため、各ベンダーが提供する CSP により提供される暗号技術が
異なるが、Microsoft から提供される CSP では以下の暗号技術が提供されている。
•
RC2
•
RC4
•
DES
•
Triple DES
e) 利用対象アプリケーション
Windows 上のアプリケーションで C++で開発されるソフトウェア。
実際、Microsoft は Internet Explorer などの自社製品を CryptoAPI により開発している。
なお、セキュリティ関連のハードウェアを Windows で利用可能にするためには、資料[116] の CryptoSPI
というプログラム インタフェースを用いて CSP を開発する必要がある。
f) アプリケーション開発の容易さ
CryptoAPI は C++ で の み 利 用 可 能 で あ る が 、 CryptoAPI 上 に 構 築 さ れ た 後 述 3.2.12 CAPICOM
(Microsoft) の CAPICOM を利用することにより、Visual Basic, Visual Basic Script, Active Server
Pages, Microsoft JScript, C++ など多くの言語で利用可能であるため、さまざまな言語のプログラマによ
り利用されうる。
文献[115] で言われるように、C++ よりも Visual Basic や Visual Basic Script などの方が容易であり、
プログラマの数としても多い。このため、実際の利用の場面では EUC に近いほど CAPICOM とその利用
可能言語である Visual Basic や Active Server Pages などで利用する頻度が高いと思われる。
一方、論文[117] による API の比較においては、Cryptographic Awareness という尺度、すなわち、プロ
グラマが API を利用するにあたりどの程度の暗号の知識が必要か、の観点で比較した結果、Cryptoki、
CSSM-SPI、CryptoAPI、GSS/IDUP の順で高度な知識が必要と評価している。
この評価を使うと、それ程、高度の暗号化の知識を必要とせずにプログラミングが可能である。
実際、資料[113]の "Using CryptoAPI" には多くの CryptoAPI を利用したサンプルコードが提供されてお
り、これが実際のプログラミングの場面でかなり有用である。
備考) 文献[115]には、CryptoAPI 利用において、Provider Type、Context などの分かり難い概念や、アン
ドキュメンテッドな複数 Context の場合における関数の振る舞いなどについて説明されている。プログラ
ミングにおいてはこれらの情報が有益である。
57
g) ポータビリティ
Windows OS のみ。さらに、後述の h) プラットフォーム で述べるように Windows のバージョンによっ
て提供される機能が異なる。
h) プラットフォーム
資料[113] では、Windows NT, Windows 2000, Windows XP としている。
ただし、各関数により対応する Windows の版が異なるので注意が必要。
備考) 後述 3.2.12 CAPICOM (Microsoft) の CAPICOM では上記と異なるプラットフォームが掲載され
ている。
i) 適用例
ライブラリおよび実装言語：
i.0) CAPICOM
文献[115] 執筆当初あるいは i.2)、i.3)で述べる製品開発当時には、CryptoAPI を Visual Basic などで利用
できるような COM ラッパーが Microsoft より提供されていなかった。
その後、CAPICOM という COM (Component Object Model) クライアントが ActiveX および COM オ
ブジェクトとして Microsoft より提供されている。
これにより、 CryptoAPI の関数が Visual Basic, Visual Basic Script, Active Server Pages, Microsoft
JScript, C++ など多くの言語で利用可能となった (資料[113])。詳細は 3.2.12 CAPICOM (Microsoft) を参
照。
i.1) WCCO 1.0
文献[115] では Visual Basic で利用可能な WCCO (Wiley CryptoAPI COM Objects) 1.0 という COM ラ
ッパーをオープンソースで提供している。これを用いて Visual Basic から CryptoAPI を利用することが可
能である。なお、WCCO では CryptoAPI 2.0 の内、Base Cryptography Functions (40 関数) のみを実装
し、次期版で他の関数を実装する予定であったが、現時点で資料[118] のサイトでは次期版以降のリリース
やその後の更新情報などが提供されていない。(CAPICOM の公開により活動を停止、ないし、縮小したと
考えられる)。
i.2) CryptoObject 1.0
CryptoObject 社は、VBScript により IIS/ASP から CryptoAPI 1.0 を利用可能にする COM ラッパー、
CryptoObject 1.0 という製品をリリースしている。
[119] のサイトより、30 日間無料の試用版がダウンロードできるが、購入はサーバライセンス $10、サイ
トライセンス $100 である。
i.3) AspEncrypt 2.1
PERSITS SOFTWARE INC 社が提供する製品で、IIS/ASP または VB で利用できる Active Server コン
ポーネントである。
[120] のサイトより、30 日間無料の試用版がダウンロードできるが、購入はサーバライセンス $249、サイ
トライセンス $899 である。
製品：
i.4) Microsoft Windows2000
CryptoAPI 2.0 が同梱され、Internet Explorer などのアプリケーション、
Microsoft Authenticode によるファイルの署名などに使う CryptoAPI Tools (資料[121]) などの開発ツー
ルで利用されている。
i.5) Intel
Intel は Intel Random Generator を利用可能にする CryptoAPI 向け CSP を開発している (資料[122])。
i.6) Compaq
Compaq TrustMaster CSP という製品は、Compaq が提供する WindowsNT 4.0、Windows2000 向けのセ
キュリティを提供するハードウェア暗号化エンジンである (資料[123])。
サポート会社：
資料[124] には、CryptoAPI をサポートする会社名として以下があげられている。
Atalla (a Tandem Company), BBN Corporation, Cylink, Datakey, E-Lock Technologies,
58
Flat Connections, Hewlett Packard, Information Resource Engineering (IRE),
Microsoft, PC/SC Workgroup, Querisoft, Rainbow Technologies, Real Software,
SPYRUS, Trusted Information Systems, Inc. (TIS)
j) 推進団体または提案した会社
提案：
Microsoft Corporation、http://www.microsoft.com/
パートナーシップ：
j.1)
nCipher、
、http://www.ncipher.com/
nCipher が開発した nShield Hardware Security Modules (HSMs) は、2000 年 1 月時点で Microsoft が
署名した最初で唯一のハードウェア セキュリティ モジュールである。
Microsoft 社と nCipher 社はパートナーシップを組み、Windows2000 PKI ソリューションを提供する
([125])。
また、論文[126]では、nCipher が開発する HSM と Windows2000 を用いた PKI の提供に関する説明がさ
れている。これによると、nCipher の HSM は CryptoAPI 用の CSP を提供することにより、Windows2000
のセキュリティ機能と統合されている。
k) 準拠する標準
•
X509.v3
•
ASN.1
資料[127] に Microsoft としての標準化への取り組みが説明されているが、具体的に CryptoAPI が準拠する
標準については触れられていない。
l) 利用コスト
無料。
CryptoAPI、CAPICOM の仕様書、サンプルなどは Platform SDK として資料[128] のページよりダウンロ
ード可能である。
また、Platform SDK の CD-ROM が資料[129] のページからオンラインで注文し、配送料金のみで入手で
きる。
m) 関連文書の入手可否
仕様書などの文書は[130] であげたサイトからネットワークでアクセス可能であるが、上述 l) 利用コスト
の Platform SDK によりファイルとして入手することもできる。
n) 他 API との関係
n.1) MISF
3.1.1 MISF (Microsoft) で述べた MISF の中心的なコンポーネントが CryptoAPI である。
n.2) CAPICOM
前述したが、Visual Basic などから利用可能な CAPICOM という COM ラッパーが提供されている。
n.3) Cryptoki、
、RSA BSAFE を用いた CAPI の提案
プレゼン資料[131] によると、以下のような構成の CAPI (Cryptographic API) が提案されている。
(General Apps)
|
Microsoft CryptoAPI
Base RSA.DLL
BSAFE
BSAFE Translation
Cryptoki DLL
59
n.4) CryptoAPI 1.0
3) 歴史 で説明したように現在の CryptoAPI 2.0 は、過去、CryptoAPI 1.0 と 2.0 が並存した状態から、
現在の 2.0 へと統合されている。過去の状況と現在の 2.0 との比較は情報が少ないためできない。
また、Microsoft から過去の仕様書を入手することができないが、他のサイト[132] で第 1 版の仕様書を入
手することができる。
o) 拡張性
実際の暗号機能は CSP で提供されており Microsoft 自身が CSP を提供しているが ([114])、サード パー
ティーが自社の暗号製品を CryptoAPI で利用可能にするための CryptoSPI というプログラム インタ
フェースが提供されている ([116])。これにより Microsoft が提供する暗号機能以外の暗号機能を利用する
ことができる。
3.2.3 CSSM API (Open Group)
1) API 名
CSSM (Common Security Services Manager)
2) 概説
CSSM は CDSA の第 3 層に位置するコンポーネントで、CDSA のコアである([32])。
CSSM はセキュリティ サービスのカテゴリを管理し、サービス単位で複数の実装をアドイン モジュール
として管理する。
•
セキュリティ サービスにアクセスするための API を定義する
•
セキュリティ サービス モジュールのための SPI (Service Provider Interface) を定義する
•
アプリケーションに対する拡張セキュリティ周辺 (extended security perimeter) を維持しながら、
アプリケーションに可能なセキュリティ サービスを動的に拡張する
•
トラステッド コンピューティング (trusted computing) ベースのカーネルを含み、動的環境の完全
性監視役 (integrity watch-dog) として機能する。
CSSM は CDSA のバージョンにより差があるため、本調査では CDSA v2 の CSSM について記述する (資
料[32])。
3) CSSM Core
•
サービス プロバイダ (Service Provider) モジュール管理
- サービス プロバイダ モジュールの動的ロードおよびアタッチ
- EMM のサポート
•
統合サービス (Integrity Services)
- ロード時のサービス プロバイダ モジュールのチェック
- アプリケーション コール毎にセキュア リンケージ (secure linkage) を実行
- サービス プロバイダからアプリケーションへのプロキシ コールバック (Proxy callbacks)
•
コンテキスト管理 (Context Management)
- 暗号機能 (crypto functions) に対するコンテキストの生成と管理
- attached module info と共に格納するコンテキスト
([133])
CSSM のモジュール管理には以下の 2 種類がある。
•
CSSM Module Managers
­
CSP、TP、AC、CL、DL の 5 種類毎に存在し、それぞれの CSP モジュールの管理を行う。
•
EMM (Elective Module Manager)
­
上記 5 種類以外の新しいセキュリティ サービスを追加する際に、そのモジュールを管理するた
60
めの機構。
Integrity Credentials のチェック
•
EISL (Embedded Integrity Services Library) 上に構築
•
トラスト ペリミタ (trust perimeter) を確立するために self_check を使用
•
トラスト ペリミタ (trust perimeter) を動的にアタッチするコンポーネントに拡張するために、証明
書ベースの双方向認証プロシージャ (credential-based bilateral authentication procedure) を用い
る。
補足) "bilateral authentication" の解説が資料[24] にある。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
CDSA フレームワークにおける CSSM の位置付けは 3.1.3 CDSA 2.0 (Open Group) の項で説明。
CSSM は以下の 5 種類の基本モジュールより上位に位置し、共通の API を与えるものである。
実際のセキュリティ機能は下位のモジュールが実行する。
•
Cryptographic Service Provider (CSP) modules
CSPs バルク暗号化 (bulk encrypting)、ダイジェスト (digesting)、デジタル署名 (digital signatures) な
どの暗号化操作を実行する。
更に、私有鍵 (private keys) を保管する。CSP は CDSA 構造における「錠と鍵」とみなせる。
•
Trust Policy (TP) modules
TPs は認証機関 (authorities and institutions) により定義されたポリシーを定義し、
(手形を発行したり、
機密の知的財産へのアクセスをえたり、などの) 特定の行動を達成するのに必要なトラストレベルを設定
する。
モジュラー概念により TP モジュールが特定機関の要求に関連付けることができる。
例えば、クレジットカード発行会社は政府関係機関とは異なるトラスト ポリシー (trust policies) を持つ。
•
Certificate Library (CL) modules
CLs は保存された証明書 (stored certificates) と失効リスト (revocation lists) の操作のシンタックスと、
認証機関 CA (Certification Authorities) のようなリモート署名 (remote signing) の能力に対するアクセ
スを提供する。
•
Data Storage Library (DL) modules
DLs は、証明書 (certificates)、暗号鍵 (cryptographic keys)、ポリシー オブジェクト (policy objects) と
いったセキュリティ関連データ オブジェクトの安定した保管 (storage) を提供する。
実際の保管は商用で利用可能なデータベース、ネイティブのファイルシステム、カスタムのハードウェア
装置、およびその他の装置に格納される。
DLs はセキュリティ データのための「ファイル キャビネット」に類似する。
•
Authorization Computation (AC) modules
ACs は、証拠の集合 (credentials) およびサンプルが特定のオブジェクトに対して特定の操作を実行する
ための認可を与える、汎用の認可評価サービス (general authorization evaluation service) を定義する。
全ての認可評価 (authorization evaluation) 機能は AC サービス プロバイダにより実装される。
CSSM は上記 5 つの基本モジュールを管理するために、以下のコンポーネントを含む([32])。
•
Cryptographic Services Manager
•
Trust Policy Services Manager
•
Certificate Library Services Manager
•
Data Storage Library Services Manager
•
Authorization Services Manager
61
また、CDSA 2.0 のバージョンアップに伴い、以下のサービスが追加された([21])。
•
Key Recovery (KR) modules
KRs は鍵復旧 (Key Recovery) サービスを提供するモジュールである。
b) 提供するセキュリティの機能
以下、プレゼン資料[134] による。
b.1) CSSM API
•
•
•
•
•
デジタル署名 (digital signature)
公開鍵 配布 (delivery) & 確証 (validation)
証明書管理 (certificate management)
暗号サービス (crypto services)
オプションとして鍵リカバリ (key recovery)
b.2) CSSM SPI
•
•
•
•
暗号 (Crypto)
データ保存 (Data Storage)
証明書ライブラリ (Certificate Library)
トラスト ポリシー (Trust Policy)
c) API 数
セキュリティに関連する 6 個の CSP (CSP, TP, AC, CL, KR, DL) の API 185 関数と、その他のコンポーネ
ント (Core, MDS, EISL, EMM) の API 85 関数の合計 270 関数 ([32])。
c.1) CSSM Core Services (14 関数)
関数
•
•
•
•
Core Functions (2 関数)
CSSM_Init, CSSM_Terminate
Module Mangament Functions (10 関数)
CSSM_ModuleLoad, CSSM_ModuleUnload, CSSM_Introduce, CSSM_UnIntroduce,
CSSM_ModuleAttach, CSSM_ModuleDetach, CSSM_SetPrivilege, CSSM_GetPrivilege,
CSSM_GetModuleGUIDFromHandle, CSSM_GetSubserviceUIDFromHandle
EMM Module Management Functions (1 関数)
CSSM_ListAttachedModuleManagers
Utility Functions (1 関数)
CSSM_GetAPIMemoryFunctions
Cryptographic Service Providers (CSP)
c.2) Cryptographic Services (81 関数)
関数
•
Cryptographic Context Operations (16 関数)
CSSM_CSP_CreateSignatureContext, CSSM_CSP_CreateSymmetricContext,
CSSM_CSP_CreateDigestContext, CSSM_CSP_CreateMacContext,
62
•
•
•
•
•
CSSM_CSP_CreateRandomGenContext, CSSM_CSP_CreateAsymmetricContext,
CSSM_CSP_CreateDeriveKeyContext, CSSM_CSP_CreateKeyGenContext,
CSSM_CSP_CreatePassThroughContext, CSSM_GetContext, CSSM_FreeContext,
CSSM_SetContext, CSSM_DeleteContext, CSSM_GetContextAttribute,
CSSM_UpdateContextAttribultes, CSSM_DeleteContextAttributes
Cryptographic Sessions and Controlled Access to Keys (10 関数)
CSSM_CSP_Login, CSSM_CSP_Logout, CSSM_CSP_GetLoginAcl,
CSSM_CSP_ChangeLoginAcl, CSSM_GetKeyAcl, CSSM_ChangeKeyAcl,
CSSM_GetKeyOwner, CSSM_ChangeKeyOwner, CSSM_CSP_GetLoginOwner,
CSSM_CSP_ChangeLoginOwner
Cryptographic Operations (48 関数)
SignData, SignDataInit, SignDataUpdate, SignDataFinal,
VerifyData, VerifyDataInit, VerifyDataUpdate, VerifyDataFinal,
DigestData, DigestDataInit, DigestDataUpdate, DigestDataFinal,
GenerateMac, GenerateMacInit, GenerateMacUpdate, GenerateMacFinal,
VerifyMac, VerifyMacInit, VerifyMacUpdate, VerifyMacFinal, QuerySize,
EncryptData, EncryptDataP, EncryptDataInit, EncryptDataInitP, EncryptDataUpdate,
EncryptDataFinal,
DecryptData, DecryptDataP, DecryptDataInit, DecryptDataInitP, DecryptDataUpdate,
DecryptDataFinal,
QueryKeySizeInBits,
GenerateKey, GenerateKeyP, GenerateKeyPair, GenerateKeyPairP, GenerateRandom,
ObtainPrivateKeyFromPublicKey,
WrapKey, WrapKeyP, UnwrapKey, UnwrapKeyP, DeriveKey, FreeKey,
GenerateAlgorithmParams
Miscellaneous Functions (5 関数)
GetOperationalStatistics, GetTimeValue, RetrieveUniqueID, RetrieveCounter, VerifyDevice
Extensibility Function (1 関数)
PassThrough
Module Management Function (1 関数)
CSP_EventNotify
Trust Policy (TP) Services
c.3) Trust Policy Services API (23 関数)
関数
•
•
•
•
Trust Policy Operations (8 関数)
TP_SubmitCredRequest, CSSM_TP_RetrieveCredResult, TP_ConfirmCredResult,
TP_CertReclaimKey, TP_CertReclaimAbort, TP_FromRequest, TP_FromSubmit
Local Application-Domain-Specific Trust Policy Functions (10 関数)
TP_CertGroupVerify, TP_CertCreateTemplate, TP_CertGetAllTemplateFields,
TP_CertSign, TP_CertSign, TP_CrlVerify, TP_CrlCreateTemplate,
TP_CertRevoke, TP_CertRemoveFromCrlTemplate, TP_CrlSign, TP_ApplyCrlToDb
Group Functions (4 関数)
TP_CertGroupConstruct, TP_CertGroupPrune, TP_CertGroupToTupleGroup,
TP_TupleGroupToCertGroup
Extensibility Functions (1 関数)
TP_PassThrough
Authorization Computation (AC) Services
c.4) Authorization Computation Services (2 関数)
関数
•
•
Authorization Computation Operations (1 関数)
AC_AuthCompute
Extensibility Functions (1 関数)
AC_PassThrough
Certificate Library (CL) Services
c.5) Cetificate Library Services (39 関数)
関数
63
•
•
•
Certificate Operations (19 関数)
CL_CertCreateTemplate, CL_CertGetAllTemplateFields,
CL_CertSign, CL_CertVerify, CL_CertVerifyWithKey,
CL_CertGetFirstFieldValue, CL_CertGetNextFieldValue,
CL_CertAbortQuery, CL_CertGetKeyInfo, CL_CertGetAllFields,
CL_FreeFields, CL_FreeFieldValue, CL_CertCache,
CL_CertGetFirstCachedFieldValue, CL_CertGetNextCachedFieldValue,
CL_CertAbortCache, CL_CertGroupToSignedBundle,
CL_CertGroupFromVerifiedBundle, CL_CertDescribeFormat
Certficiate Revocation List Operations (19 関数)
CL_CrlCreateTemplate, CL_CrlSetFields, CL_CrlAddCert,
CL_CrlRemoveCert, CL_CrlSign, CL_CrlVerify, CL_CrlVerifyWithKey,
CL_IsCertInCrl, CL_CrlGetFirstFieldValue, CL_CrlGetNextFieldValue,
CL_CrlAbortQuery, CL_CrlGetAllFields, CL_CrlCache, CL_IsCertInCachedCrl,
CL_CrlGetFirstCachedFieldValue, CL_CrlGetNextCachedFieldValue,
CL_CrlAbortCache, CL_CrlDescribeFormat
Extensibility Functions (1 関数)
CL_PassThrough
Data Storage Library (DL) Services
c.6) Data Storage Library Services (23 関数)
関数
•
•
•
•
Data Storage Library Operations (5 関数)
DL_Authenticate, DL_GetDbAcl, DL¥ChangeDbAcl, DL_CertDbOwner, DL_ChangeDbOwner
Data Storage Operations (9 関数)
DL_DbOpen, DL_DbClose, DL_DbCreate, DL_DbDelete,
DL_CreateRelataion, DL_DestroyRelation, DL_GetDbNames, DL_GetDbNameFromHandle,
DL_FreeNameList
Data Record Operations (8 関数)
DL_DataInsert, DL_DataDelete, DL_DataModify, DL_DataGetFirst, DL_DataGetNext,
DL_DataAbortQuery, DL_DataGetFromUniqueRecordId, DL_FreeUniqueRecord
Extensibility Functions (1 関数)
DL_PassThrough
Module Directory Servcie (MDS)
c.7) Module Directory Services APIs (4 関数)
関数
•
•
MDS Context APIs (2 関数)
MDS_Initialize, MDS_Terminate
MDS Installation APIs (2 関数)
MDS_Install, MDS_UnInstall
Key Recovery (KR) Services
c.8) Key Recovery Interfaces (17 関数)
関数
•
•
•
•
•
Key Recovery Module Management Operations (1 関数)
CSSM_KR_SetEnterpriseRecoveryPolicy
Key Recovery Context Operations (4 関数)
CSSM_KR_CreateRecoveryRegistrationContext,
CSSM_KR_CreateRecoveryEnablementContext,
CSSM_KR_CreateRecoveryRequestContext,
CSSM_KR_GetPolicyInfo
Key Recovery Registration Operations (2 関数)
KR_RegistrationRequest, KR_RegistrationRetrieve
Key Recovery Enablement Operations (2 関数)
KR_GenerateRecoveryFields, KR_ProcessRecoveryFields
Key Recovery Request Operations (6 関数)
KR_RecoveryRequest, KR_RecoveryRetrieev, KR_GetRecoveredObject,
KR_RecoveryRequestAbort, CSSM_KR_QueryPolicyInfo, CSSM_KR_FreePolicyInfo
64
•
•
Privileged Context Operation (1 関数)
KRSP_PassPrivFunc
Extensibility Functions (1 関数)
KR_PassThrough
Embedded
Embedded Integrity Services Library (EISL)
c.9) EISL Functions (55 関数)
関数
•
•
•
•
•
•
Credential and Attribute Verification Services (13 関数)
EISL_SelfCheck,
EISL_VerifyAndLoadModuleAndCredentialData,
EISL_VerifyAndLoadModuleAndCredDataWithCert,
EISL_VerifyAndLoadModuleAndCredentials,
EISL_VerifyAndLoadModuleAndCredentialsWithCert,
EISL_VerifyLoadedModuleAndCredentialData,
EISL_VerifyLoadedModuleAndCredDataWithCert,
EISL_VerifyLoadedModuleAndCredentials,
EISL_VerifyLoadedModuleAndCredentialsWithCert,
EISL_GetCertificateChain, EISL_ContinueVerification,
EISL_DuplicateVerfiedModulePtr, EISL_RecycleVerfiedModuleCredentials
Signature Root Methods (19 関数)
EISL_CreateVerifiedSignatureRootWithCredentialData,
EISL_CreateVerifiedSigRootWithCredDataAndCert,
EISL_CreateVerifiedSignatureRoot, EISL_CreateVerifiedSignatureRootWithCertificate,
EISL_FindManifestSection, EISL_CreateManifestSectionEnumerator,
EISL_GetNextManifestSection, EISL_RecycleManifestSectionEnumerator,
EISL_FindManifestAttribute, EISL_CreateManifestAttributeEnumerator,
EISL_FindSignerInfoAttribute, EISL_CreateSignerInfoAttributeEnumerator,
EISL_GetNextAttribute, EISL_RecycleAttributeEnumerator,
EISL_FindSignatureAttribute, EISL_CreateSignatureAttributeEnumerator,
EISL_GetNextSignatureAttribute, EISL_RecycleSignatureAttributeEnumerator,
EISL_RecycleVerifiedSignatureRoot
Certificate Chain Methods (6 関数)
EISL_CreateCertificateChainWithCredentialData,
EISL_CreateCertificateChainWithCredDataAndCert,
EISL_CreateCertificateChain,
EISL_CreateCertificateChainWithCertificate,
EISL_CopyCertificateChain,
EISL_RecycleVerifiedCertificateChain
Certificate Attribute Methods (4 関数)
EISL_FindCertificateAttribute, EISL_CreateCertificateAttributeEnumerator,
EISL_GetNextCertificateAttribute, EISL_RecycleCertificateAttributeEnumerator
Manifest Section Object Methods (8 関数)
EISL_GetManifestSignatureRoot, EISL_VerifyAndLoadModule,
EISL_VerifyLoadedModule,
EISL_FindManifestSectionAttribute, EISL_CreateManifestSectionAttributeEnumerator,
EISL_GetNextManifestSectionAttribute, EISL_RecycleManifestSectionAttributeEnumerator,
EISL_GetModuleManifestSection
Secure Linkage Servcies (5 関数)
EISL_LocateProcedureAddress, EISL_GetReturnAddress,
EISL_CheckAddressWithinModule, EISL_CheckDataAddressWithinModule,
EISL_GetLibHandle
CSSM Elective Module Manager (EMM)
c.19) Elective Module Manager Operations (12 関数)
関数
•
Elective Module Manager Functions (7 関数)
Initialize, Terminate, ModuleManagerAuthenticate,
RegisterDispatchTable, DeregisterDispatchTable,
65
•
EventNotifyManager, RefreshFunctionTable
CSSM Service Functions used by an EMM (5 関数)
cssm_GetAttachFunctions, cssm_ReleaseAttachFunctions,
cssm_GetAppMemoryFunctions, cssm_IsFuncCallValid, cssm_DeregisterManagerServices
d) ベースとなる技術
「CMMS コアサービス (CMMS Core Services)」と呼ばれるコンポーネントが次の基本的な
機能を提供している ([24])。
•
モジュール管理
­
サービス プロバイダ モジュール (Service Provider Module) の動的ロードおよびアタッチ
­
EMM のサポート
•
統合サービス (Integrity Services)
­
ロード時のサービス プロバイダの完全性 (Integrity) チェック
­
アプリケーション コール毎のセキュア リンケージ チェック (Secure Linkage Check) の実行
­
サービス プロバイダからアプリケーションへのプロキシ コールバック (Proxy Callback)
セキュリティ確保のために、CSSM は自分自身を危険から保護する必要がある ([21])。
CSSM は Signed Manifests を クレデンシャル (Credentials) として用い、
セルフチェックとアドイン モ
ジュールのチェックを行う。CDSA はアプリケーション以外の全てのコンポーネントがそのコンポーネン
ト の 完 全 性 (Integrity) と 真 正 性 (Authenticity) を 保 証 す る た め に 、 関 連 す る Signed Manifest
Credential を持つことを規定している。
完全性チェック (Integrity Check) が CDSA のコンポーネントがウィルスの侵入などにより、製品リリー
ス以降に何の変更もされていないことを保証する。
Embedded Integrity Services Library (EISL) は、実行時にこれらのクレデンシャル (Credentials) を確
証 (Verify) するのに使われる。
これは、完全性のセルフチェック、モジュールの双方向認証 (Bilateral Authentication) や他の統合サー
ビス (Integrity Services) を提供する。
CSSM はサービス マネージャおよび EMM を用いて、
CSSM 自身と全ての CDSA サービス プロバイダ モ
ジュールの完全性を維持するように設計されている。
セルフチェックに失敗すれば CSSM はそれ以上処理を進めないし、モジュール確証 (Verification) に失敗
したモジュールの処理を実行しない。
また、上記と並び、「CSSM モジュール マネージャ (CSSM Module Managers)」という基本的なコンポ
ーネントがあり、それぞれのマネージャは CDSA のサブセットをサポートし、SPI によりそれぞれのサー
ビス プロバイダ モジュールを結合すると同時に、API を通じてアプリケーションにサービス プロバイダ
モジュールの機能を提供する ([24])。
モジュールマネージャは以下の 2 種類がある。
•
基本モジュール マネージャ
CSP、DL、CL、TP、AC の基本モジュール マネージャは CDSA のサブセットをサポートし、この時、
上記の統合サービス (Integrity Services) によりセキュリティ上の安全性を維持する働きを行う。
•
Elective Module Manager (EMM)
EMM は、基本モジュール マネージャと同じ位置付けでこれを拡張し、ユーザが HRS のような新しい
セキュリティ サービスを追加することを可能とする。
なお、CDSA 1.2 の CSSM は EMM の機能を持っていない。
サービス プロバイダ モジュールは、共有ライブラリ、別名、ダイナミックリンク ライブラリで実現され
ており、CSSM のコアとなるモジュール管理はこの技術を用いて実装されている。
CSP は、BSAFE、GCS-API、PKCS#11、Fortezza などの API をサポートし、CL は、X.509、SET、X9、
SDSI、SPKI、PGP という多くの Certificate Type をサポートする ([24])。
4 つのコア アドイン モジュールは以下のような技術をサポートする ([21])。
66
d.1) CSP
以下の暗号アルゴリズムおよび暗号化機能を提供。
•
Bulk encryption algorithm
•
Digital signature algorithm
•
Cryptographic hash algorithm
•
Unique identification number
•
Random number generator
•
Secure key storage
•
Custom facilities unique to the CSP
•
Key generation or key import
•
Secure storage for cryptographic keys and variables that have been entrusted to the CSP for use
or storage
d.2) TP
Certificate-based trust domain のために以下の 3 つの基本活動。
•
Actions on certificates
•
Actions on certificate revocation lists
•
Domain-specific actions (such as issuing a check or writing to a file)
d.3) CL
X.509、SPKI などの Certificate データフォーマットの操作
d.4) DL
セキュリティ関連データオブジェクトの保管は以下の記憶装置を使う。
•
商用で利用可能なデータベース管理システム製品
•
ネイティブのファイルシステム
•
カスタムのハードウェアベースの記憶装置
•
リモート ディレクトリ サービス (Remote Directory Service)
•
インメモリ記憶 (In-memory Storage)
また、アドインモジュールに関しては CSSM により以下の特徴 (機能) がサポートされる ([21])。
•
マルチサービス ライブラリ モジュール (Multi-Service Library Module)
アドイン セキュリティ モジュールは、CSP など複数のカテゴリの機能を一つのモジュールで提供する
ことができる。これを「マルチサービス ライブラリ モジュール」または「マルチサービスアドイン モ
ジュール」と呼ぶ。
アプリケーションはこれのコピーを一回ロードするだけで、これが提供する複数のカテゴリから独立し
てサービスを選択することができる。
•
サービス プロバイダ再利用 (Service Provider Reuse)
サービス モジュールで提供される機能は、アプリケーションからだけでなく、同じレイヤーの他のサー
ビス モジュールでも利用することができる。これを「サービス プロバイダ再利用」と呼んでいる。
この機能を実装するために、CSSM はリエントラント (re-entrant) に実装する必要がある。
新しいセキュリティ サービスを実装する際に威力を発揮し、これは EMM 上で標準化された API を通
して提供される。
e) 利用対象アプリケーション
CDSA と同じ。
f) アプリケーション開発の容易さ
3.1.2 CDSA 1.2 (Intel) および 3.1.3 CDSA 2.0 (Open Group) にて記述。
g) ポータビリティ
CDSA と同じ。
67
h) プラットフォーム
プラットフォーム
CDSA と同じ。
i) 適用例
3.1.3 CDSA 2.0 (Open Group) にて記述。
j) 推進団体または提案した会社
Intel が策定し、Open Group が採用。現在、Intel を中心とした Open Group による活動により推進され
ている。
k) 準拠する標準
Open Group により仕様書[32]として標準化。
l) 利用コスト
無料。
CDSA のオープンソースが資料[36]、SourceForge より入手可能。
m) 関連文書の入手可否
仕様書 (資料[32]) は Open Group のサイトよりダウンロード可能。
また、開発者用ドキュメントが上述のオープンソース (資料[36]) のサイトからダウンロードできる。
n) 他 API との関係
n.1) GCS-API (Open Group)
文献[21] の用語集 (Glossary) によると、
「GCS は CDSA の前身 (predate) である。GCS の要求仕様は初
期のハードウェア ベースの暗号装置で暗号鍵が装置内に格納されるもの、が元になっている。インターネ
ットのアプリケーションはさらに暗号鍵の安全な転送 (secure transmission) が要求される。DSA の
Cryptographic Services API はこれら両方のタイプの要求を満たしている。
」と説明されている。
Open Group において GCS-API 策定が現在も続けられているのか、あるいは、CDSA、CSSM に吸収さ
れてしまったのか、については未調査。
n.2) CDSA
CSSM は CDSA のレイヤー3 に位置する。(一部資料では「第 2 層」と書かれている)。
n.3) CDSA/HRS
バイオメトリック認証に CDSA を適用 (拡張) した仕様。 3.5.2 CDSA/HRS API (Open Group) にて詳細に
説明。
o) 拡張性
3.1.3 CDSA 2.0 (Open Group) の o) 拡張性 でも記述したが、CSSM は EMM により新しいセキュリテ
ィサービスを追加することができる ([32])。
68
3.2.5 IDUP-GSS-API (IETF)
1) API 名
Independent Data Unit Protection Generic Security Service API (IDUP-GSS-API)
2) 概説
GSS-API [RFC-2078] の拡張であり、さまざまな蓄積交換方式 (Store-and-Forward) の環境において保
護 (protection) および非保護 (nonprotection) のサービスを提供する汎用的で柔軟な方法を提供する
([96])。
IDUP-GSS-API は GSS-API に 似 て い る が 、 独 立 デ ー タ ユ ニ ッ ト 保 護 (Independent Data Unit
Protection) 用に設計された API である。これは、GSS-API を (ファイルやメッセージのような) 汎用デ
ータユニットの保護が必要なアプリケーションに適合するように拡張したものである。
一つのデータユニットの保護は、他のデータ ユニットの保護とは独立であり、そのデータ ユニットの指
定された受け取り側 (receiver) との任意の並列コンタクトと独立である。
3) 歴史
IDUP-GSS-API は、C. Adams (Bell-Northern Research) により 1995 年 3 月 31 日に、インターネット ド
ラフト、draft-ietf-cat-idup-gss-01.txt、"Independent Data Unit Protection Generic Security Service
Application Program Interface (IDUP-GSS-API)" として IETF に提出。その後、1998 年 3 月に
draft-ietf-cat-idup-gss-10.txt までバージョンアップされた後、RFC 2479 として標準化された ([135])。
4) GSS-API との関係
GSS-API と IDUP-GSS-API は類似の API であるが、次のような異なる環境のために設計されている；
•
GSS-API
セッション方式 、オンライン リアルタイム メッセージング環境をターゲットする。
•
IDUP-GSS-API
蓄積交換方式 (Store-and-Forward) 、E メール タイプの環境 (指定されたメッセージの受け取り者と
の任意のオンライン コミュニケーションと独立にメッセージが保護されるような) に特に適合する。
両方の API とも利用が容易なように設計されており、 (SPKM および PIMi のような) 公開鍵メカニズム
を用いてコミュニケーションのセキュリティを提供する。
i
PIM は Protocol Independent Multicast のことであり、詳しくは用語 PIM (Protocol Independent Multicast) に
て解説。
69
a) ライブラリ構成、アーキテクチャ
ライブラリ構成、アーキテクチャ/フレームワーク構成
クチャ フレームワーク構成
3.2.1 GSS-API (Open Group) にて説明。
b) 提供するセキュリティの機能
蓄積交換方式 (Store-and-Forward) の環境向け API であり、以下の汎用プロテクション サービス
(general protection services) に対するインタフェースを提供する ([96])。
•
機密性 (confidentiality)
•
データ送信元認証 (data origin authentication)
•
完全性 (integrity)
•
否認拒否防止 (non-repudiation)
c) API 数
以下の 5 分類、52 関数 ([135])。
•
Credential management calls (GSS-API と同じ 5 関数)
•
Environment-level calls (3 関数)
•
Per-IDU protection/unprotection calls (以下の 3 種類、20 関数)
- SE (SIGN,ENCRYPT) CALLS (7 関数)
- EV (EVIDENCE) CALLS (7 関数)
- GP (GENERAL PROTECTION) CALLS (6 関数)
•
Special-Purpose calls (1 関数)
•
Support calls (GSS-API と同じ 19 関数＋4 関数)
なお、IDUP-GSS-API が参考にする GSS-API は RFC2078 の Version2.0 であるため、Support calls の個
数が RFC 2743 と異なっている。
d) ベースとなる技術
3.2.6 COE SS API (MITRE) の a) ライブラリ構成、アーキテクチャ/フレームワーク構成 で引用した図に
あるように、MSPi および S/MIME をベースとしその上のインタフェースとして定義されている。
また、3.4.2 XGSS-API (IETF) の a) ライブラリ構成、アーキテクチャ/フレームワーク構成 で引用した
図も参考になる。
実際の機能は基礎となる上記のようなメカニズムが提供する ([96])。
また、目標は呼び出し側アプリケーションに影響を与えることなくメカニズムを切り替えることである
([96])。
e) 利用対象アプリケーション
より広範囲の E-mail、特に、E コマースで必要とされる機能を提供している ([96])。
f) アプリケーション開発の容易さ
GSS-API の拡張であり、GSS-API と同じ。
g) ポータビリティ
GSS-API と同じ。
h) プラットフォーム
GSS-API と同じ。
i
MSP とは Message Security Protocol のことであり、詳しくは用語 MSP (Messaging Security Protocol) で解説。
70
i) 適用例
Ingris, Secuer Office Client は、PKCS#11、PKCS#7 (S/MIME)、MS-CAPI、GSS-API、IDUP-GSS-API
をサポートする ([136])。
また、[96] によると以下の IDUP メカニズム仕様が検討されている。
•
PEM-Based IDUP Mechanism (PIM)
提案が実験的 (Experimental) RFC として提出
•
MSP-Based IDUP Mechanism
Nortel の内部仕様
•
MOSS-Based IDUP Mechanism
近いうちに提案されるか？
•
PKCS #7-Based IDUP Mechanism (p7im)
S/MIME-enabling mechanism がちょうど提出された
また同資料によると、パブリックドメインでない以下の実装が行われた。
•
PEM-Based Mechanism
開発中(ほぼ半分が完了)
•
MSP-Based Mechanism
完了
•
PKCS #7-Based Mechanism
α版のコードが完了
•
MOSS-Based Mechanism
進行中？
j) 推進団体または提案した会社
IETF
k) 準拠する標準
IDUP-GSS-API 自身は RFC2479 として IETF が標準化 ([135])。
インターネット ドラフトは draft-ietf-cat-idup-gss-07.txt ([137])。
また、IDUP-GSS-API の C 言語実装がインターネット ドラフト、draft-ietf-cat-idup-cbind-03.txt とし
て 1997 年 5 月 1 日に提出されたが、1997 年 11 月 1 日に失効している ([138])。
l) 利用コスト
GSS-API と同じ。
m) 関連文書の入手可否
RFC については、IETF のサイト (資料[106]) より入手可能 (また、RFC については資料[107] であげたサ
イトからも検索、ダウンロードが可能である)。
n) 他 API との関係
n.1) GSS-API
GSS-API [RFC-2078] の拡張。また、GSS-API とは分離されない([96])。
o) 拡張性
これまでの調査では拡張性に関する情報が入手できていないが、GSS-API と同じと思われる。
71
3.2.6 COE SS API (MITRE)
1) API 名
COE Security Services API (COE SS API)
2) 概説
COE SS API は Security Services Application Framework (SSAF) ([139]) と呼ばれるフレームワークを
構成する要素である ([140])。
SSAF フレームワークは Open Group の CDSA の一適用 (adaptation) である。
SSAF は DoD PKI の GOTS アプリケーションのインタフェースとなる ([141])。
(言い換えると、SSF は GOTS アプリケーションを PK 対応にする。また、これには、30 行のコードと 5
個の API で実現される)。
3) 特徴
以下の特徴を有する([139])。
•
Socket ライクのセキュア コネクションを通してハイレベルの抽象化を提供
•
アプリケーションに対してシステム セキュリティ ポリシー (System Security Policy) を提供
- 首尾一貫したシステム セキュリティ ポリシー
- ポリシー変更によりアプリケーションを変更する必要がない
•
セキュリティ製品 (例、Netscape Security Services NSS) と COE アプリケーション間に薄く独立し
た (thin isolation) レイヤーを提供することにより、ポータビリティを与える。
4) DII COE SSAF (Security Service Architecture Framework)
DISA DII COE アプリケーション ([139])。
5) DII COE
DII COE はオープン システム構築の基礎を提供するものであり、サーバ/クライアント モデルむけに設計
された「プラグ アンド プレイ (plug and play)」によるオープン アーキテクチャである ([142])。
DII COE はミッション アプリケーション独立であり、以下のものである ([143])：
•
アーキテクチャ
•
アプローチ
•
再利用可能なソフトウェアの集合
•
ソフトウェア インフラ
•
ガイドラインと標準の集合
国防情報基盤共通操作環境（DII COE）([144])。
DII COE の認証プロセスによって、SGI など POSIX をベースとするアプリケーション･プラットフォーム
のベンダーは、国防総省（DOD）の指揮統制環境へ共通オペレーティング･システム･インタフェースを提
供する機会を得ることができるようになる。
DII COE は「プラグ・アンド・プレイ」に対応した、クライアント/サーバ型モデル周辺のオープン･アー
キテクチャであり、DOD の各組識や複数のプラットフォーム間で相互運用可能なオープン システムの構
築基盤を提供する。KPC プログラムによって、DISA は特定のプラットフォームが業界標準であるか、商
用テスティングに適合しているか、また、DISA に定めるインターオペラビリティ、セキュリティおよび
機能を満たしているかなど、DII COE への適合基準に準拠しているかを検証することができる。
6) 歴史
以下、資料[145]より引用。
98 年第 2 四半期：
Netscape が方向転換し、CDSA へ支援中止を決定
98 年 5 月：
DISA は DOD JTA Version2.0 を提出
- RFC-2078 GSS-API, Version2.0 を含む
- IETF Draft IDUP-GSS-API
72
98 年 5 月：
98 年 6 月：
98 年 8 月：
98 年 9 月：
DISA は DII COE として MITRE に SS API (Security Services API)戦略研究を発注
DISA DII COE チーフエンジニア が DII COE SSAPI の構築を決定
DII COE SSAPI version1.0 仕様が発表
SSTWG が SSAPI COE 賛成に投票
COE SSAPI の最初の実装は、1999 年 10 月の COE4.1 のリリースから利用可能になった ([145])。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
COE SSAF のアーキテクチャ図は以下([95])。
また、SSAPI アーキテクチャ図を以下に示す ([145])。
73
b) 提供するセキュリティの機能
COE SS API が提供するセキュリティ機能は以下 ([146])。
•
相互認証 (mutual authentication)
•
データ完全性 (data integrity)
•
データ機密性 (data confidentiality)
た だ し 、 現 版 で は セ キ ュ ア ポ イ ン ト ツ ー ポ イ ン ト コ ミ ュ ニ ケ ー シ ョ ン (secure point-to-point
communication) のみに限定されている ([139])。が、将来的には n-tier アプリケーションに対応する予定
である ([95])。
SSAF V1.1 は次のセキュリティ サービスを提供する ([141])。
•
相互、2 ファクター 認証 (Mutual, two factor authentication)
•
暗号化 (Encryption)
•
データ完全性 (Data Integrity)
c) API 数
資料[95] は Java のクラス仕様で SSAPI が定義されており、これをベースにすると以下の 6 クラス、36 メ
ソッド。
•
Credential クラス (5 メソッド)
•
SecurityContext クラス (14 メソッド)
•
SecureConnection クラス (8 メソッド)
•
SecurityException クラス (2 メソッド)
•
IllegalValueException クラス (2 メソッド)
•
SecurityFactory クラス (5 メソッド)
C マッピングは合計 22 関数 ([95])。
d) ベースとなる技術
SS API の 4 要素 ([146])。
•
システム セキュリティ ポリシー (System Security Policy)
セキュリティ コンテキスト生成を統治するセキュリティ パラメタを詳述するポリシー。
•
セキュリティ コンテキスト (Security Context)
クライアントおよびサーバ アプリケーションがセキュア コネクションをオープンおよびクローズする
フレームワーク。
•
クレデンシャル (Credentials)
クライアント、サーバ アプリケーションが互いを認証する方法。
•
セキュア コネクション (Secure Connection)
クライアント、サーバ間で作成されるコネクションで、データのセキュアな送受信が可能となる。
また、SSAF V1.1 は以下の技術をベースとする ([141])。
•
Netscape Security Services V3.1 (for Secure Sockets Layer)
•
DoD PKI certificates (server mandatory, client optional)
NSS はポイントツーポイント (point-to-point) ネットワーク コネクション上のデータの相互認証
(mutual Authentication)、データ完全性、データ機密性保護を提供するために SSL プロトコルを用いてい
る ([95])。
e) 利用対象アプリケーション
DII COE が対象とするアプリケーション。DII COE は DISA 向けのシステムを想定している。
COE SSAPI は厳密に GOTS ソリューションである ([145])。
74
•
•
•
他のベンダーのセキュリティ サービスや暗号技術を利用するために、適切な「結合(bindings)」を開
発するための新たな努力を必要とする。
NSS は DoD のセキュリティ要求を全て満たしていない。
ア ク セ ス 管 理 サ ー ビ ス (reference SDN.801) お よ び Certificate Path Processing (reference
SDN.706)
f) アプリケーション開発の容易さ
ベースとなるセキュリティ インフラストラクチャについての知識なしに、セキュリティを実装する
(Security-aware) アプリケーションを開発することができる ([146])。
アーキテクチャ図が示すように、CDSA、GSS-API よりも更に上位の API を提供するため、これらの API
よりも簡単にアプリケーションを構築することができる。しかし、対象アプリケーションが DII COE と政
府 (軍) 向けの特定システムが対象であるため、この対象のアプリケーションでしか適用できない。また、
COE が厳密に規定するプラットフォーム上に構築する必要がある。
g) ポータビリティ
Java 1/2 and ‘C’ interfaces for all deliveries ([141])。
API は基礎となるセキュリティサービスから独立しており、セキュリティサービスをカプセル化するため
に COE 特有の API を提供する ([145])。
h) プラットフォーム
2001 年 10 月 5 日リリースの COE 4.5 が想定するプラットフォームは、Solaris 7、Solaris 8、
HP-UX 11.0、
Windows NT、Windows2000 ([147])。
COE Version 4.5 などのリリース情報は [148] にある。
i) 適用例
i.1) NSS (Netscape Security Services) 2.0
•
•
最初の API 実装は NSS 2.0 を用いた ([146])。
- NSS 2.0 は以下のために SSL サポートを提供するライブラリの集まりである；
認証 (Authentication)
改ざん検知 (Tamper Detection)
PKCS #11
プラットフォーム
- WindowsNT 4.0
- Solaris 7.0
- HP-UX 10.20
また、JDK 1.1.6 を用いた Java API 実装を提供している。
75
i.2) SSAFAP
セキュアな telnet および ftp サービスに対応した SSAF アプリケーション ([149])。
j) 推進団体または提案した会社
MITRE ([150])。
MITRE は非営利の国家的な技術機関で、政府に対するシステム エンジニアリング、研究開発、IT のサ
ポートを行うことを目的としている。
Bedford、Massachusetts、Northern Virginia に主要な機関を置く、国防総省 (DOD)、FAA、IRS のため
連邦から基金提供を受けた R&D センターとして機能している。
また、DII COE 自身は、DEFENSE INFORMATION SYSTEMS AGENCY (DISA) ([151]) で管理され
ている。防衛情報システム局（The Defense Information Systems Agency – DISA） ([152])。
76
k) 準拠する標準
アークテクチャとしては CDSA や GSS-API などの他の標準を意識しているが、SSAPI 自身は標準ベース
の API ではない ([145])。
l) 利用コスト
関 連 文 書 に つ い て は [142] か ら 入 手 可 能 な よ う だ が 、 Electronic Delivery や access to CMDOCS
(non-released documents) のためには、DISA フォーム 41 記入の上、ユーザ登録が必要。なお、DII COE
関連の入手およびコストの詳細については現在不明。
m) 関連文書の入手可否
仕様書は MITRE のページ[140] から入手可能 ([95])。
COE Version 4.5 などのリリース情報は [148] にあり、関連する開発情報は [142] から入手できる。
n) 他 API との関係
n.1) SSAF
COE SS API は SSAF の要素である ([139]、[95])。前述の a) であげた図および以下の図を参照。
n.2) CDSA
SS API は CDSA のハイレベル API の種子となることを目指している ([139])。
MITRE は Open Group ミーティングにて CDSA の標準のハイレベル API を定義するように Open
Group のアクションアイテム (活動項目) とするように SSAF および COE SS API を提案した ([95])。
n.3) GSS-API、
、IDUP-GSS-API
上述の SSAF アーキテクチャ図にあるように、GSS-API および IDUP-GSS-API の上に SS API を構築
するアーキテクチャが検討されている。
77
o) 拡張性
CDSA と同じ。
3.2.7 JCE (Sun)
1) API 名
Java Cryptography Extension (JCE)
2) 概説
JCE は暗号化 (encryption)、鍵生成 (key generation)、鍵アグリーメント (key agreement)、MAC
(Message Authentication Code) のアルゴリズムのフレームワークおよび実装を提供するためのパッケー
ジ セットである ([153])。
暗号は、共通鍵暗号 (symmetric)、公開鍵暗号 (asymmetric)、ブロック暗号 (block)、ストリーム暗号
(stream cipher) をサポートする。
3) 歴史
JCE 1.2.1 は J2SDK, versions 1.2.x および 1.3.x のオプション パッケージとしてリリースされている
([154])。また、これより一つ前の JCE 1.2 は、J2SDK, versions 1.2.x および 1.3.x のオプション パッケー
ジであるが、アメリカ合衆国およびカナダのみで利用可能 ([155])。
一方、JCE 1.2.1 および J2SDK v1.4 用 JCE (JCE for J2SDK v1.4) は輸出可能である。
なお、最新版である J2SDK v1.4 は現在、βリリースであるが、J2SDK のパッケージに含まれているた
め、これまでのように別に入手およびインストールする必要がなくなった ([156])。
4) 特徴
下記は、[154] より引用。
•
ピュア Java 実装
•
プラグ可能フレームワーク アーキテクチャ (Pluggable framework architecture)。これにより、クオ
リファイド プロバイダ (qualified providers) のみプラグインされる。
•
輸出可能 (バイナリ形式のみ)
•
JCE 1.2.1 ソフトウェアは Sun Microsystems から US 国内および海外ユーザに対して単一の配布物
で提供される。暗号アルゴリズムおよび暗号強度を jurisdiction policy files の設定により制限するこ
とができるが、この配布物にバンドルされている jurisdiction policy files では、暗号強度に対する制
限は指定されていない。
•
暗号 (ciphers)、鍵アグリーメント (key agreements)、MAC などの実装およびインタフェース
•
SunJCE プロバイダにより以下のアルゴリズムがサポートされる:
- DES
- DESede
- Blowfish
- PBEWithMD5AndDES
- PBEWithMD5AndTripleDES
- Diffie-Hellman key agreement among multiple parties
- HmacMD5
- HmacSHA1
5) パッケージ
•
javax.crypto
•
javax.crypto.interfaces
•
javax.crypto.spec
これは、JCE 1.2、1.2.1、J2SDK v1.4 用 JCE のいずれも同じ。
78
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
Java Security Architecture において、パッケージ間の関係を示す構成は以下のようになる (文献[43])。
アプリケーション
|
JCE
|
|
コア Java JCA
また、JCE Architecture としては以下の図が使われる ([157])。
(ただし、この図は主に輸出可能にするためにどのような機能を提供しているかの説明が主眼)。
複数の CSP に対応したプロバイダ ベースのアーキテクチャを取っている ([157])。
JSSE 1.2.1 には SunJCE と呼ばれるプロバイダが同梱されている。
ただし、JSSE 1.2.1 は輸出用にプロバイダ分離版になっている。
輸出可能であることを確実にするために、以下の特徴を持っている。
•
認可されていないプロバイダ (Un-approved provider) は JCE 1.2 にプラグできない。
•
プロバイダは JCE 1.2.1 フレームワーク以外で利用不可能。
•
jurisdiction policy file で設定可能な柔軟な暗号強度。
•
署名付アプリケーション (signed application) のみが高い暗号を使うことができる。
b) 提供するセキュリティの機能
•
•
•
•
暗号化 (encryption)
鍵生成 (key generation)
鍵アグリーメント (key agreement)
MAC (Message Authentication Code)
c) API 数
JCE 1.2.1 の API は以下のように 8 クラス、99 メソッド ([158]、[159])。
Core Classes
Classes (8 クラス、99 メソッド):
•
Cipher Class (30 メソッド)
79
•
•
•
•
•
•
•
Cipher Stream Classes (以下の 2 クラスを Cipher Stream Class と呼ぶ)
CipherInputStream Class (9 メソッド)
CipherOutputStream Class (7 メソッド)
KeyGenerator Class (11 メソッド)
SecretKeyFactory Class (8 メソッド)
SealedObject Class (5 メソッド)
KeyAgreement Class (13 メソッド)
Mac Class (16 メソッド)
J2SDK v1.4 用 JCE の API は以下の 8 クラス、105 メソッド ([160])。
Core Classes (8 クラス、105 メソッド):
•
Cipher Class (31 メソッド)
Cipher Stream Classes (以下の 2 クラスを含む)
•
CipherInputStream Class (9 メソッド)
•
CipherOutputStream Class (7 メソッド)
•
KeyGenerator Class (12 メソッド)
•
SecretKeyFactory Class (9 メソッド)
•
SealedObject Class (6 メソッド)
•
KeyAgreement Class (14 メソッド)
•
Mac Class (17 メソッド)
注) 上記のメソッド数には上位クラスから継承するメソッドは含んでいない。
d) ベースとなる技術
実際の暗号化機能は、API ではなくその下のプロバイダが提供する。
例えば、Cryptix Foundation ([161]) の開発する Cryptix JCE では、以下の技術を提供している ([162])。
•
Ciphers
Blowfish, CAST5, DES, IDEA, MARS, RC2, RC4, RC6, Rijndael, Serpent, SKIPJACK, Square,
TripleDES, Twofish
•
KeyAgreements
Diffie-Hellman
•
Modes
CBC, CFB-(8, 16, 24, ..., blocksize), ECB, OFB-(blocksize), openpgpCFB
•
Hashes
MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-0, SHA-1, SHA-256/384/512, Tiger
•
MACs
HMAC-MD2,
HMAC-MD4,
HMAC-MD5,
HMAC-RIPEMD-128,
HMAC-RIPEMD-160,
HMAC-SHA-0, HMAC-SHA-1, HMAC-Tiger
•
Signatures
RawDSA, RSASSA-PKCS1, RSASSA-PSS
•
Asymmetric ciphers
RSA/PKCS#1, ElGamal/PKCS#1
e) 利用対象アプリケーション
低レベルの暗号機能を提供するパッケージであり、これよりも上位の JSSE、JCE を用いた方がアプリケ
ーションを容易に構築できる。JCE そのものを用いるのは、JSSE、JCE のような上位パッケージを開発
するか、あるいは、より高度なカスタマイズを行いたい場合であろう。
ただし、
自社の暗号化ソフトウェア・ハードウェア製品を JCE で利用可能にするために、
ベンダーは [163]
の仕様を元にプロバイダを開発することができるので、プロバイダの開発で JCE SPI を利用する (正確に
は JCE SPI に基づいてプロバイダを開発する) ケースが多いと思われる。
80
f) アプリケーション開発の容易さ
低位のコア Java 2.0 Security Architecture と JCA の上位に位置し、暗号機能を実装するために設計され
た API であるため、これら下位の API に比べて実装が容易。
プロバイダが提供する暗号化機能を利用するために、ベースとする秘密鍵暗号、公開鍵暗号などの暗号、
メッセージダイジェスト、デジタル署名、デジタル証明書といった暗号化の基礎知識を必要とする。
また、Java Security Architecture など Java セキュリティのフレームワーク、Java プログラミングなど
の知識がないと、JCA のプログラミングを理解するのは困難と思われる。
g) ポータビリティ
Java プラットフォームが実装されていれば、UNIX、Windows など OS に依存しない。
ただし、下記 h) のように JAAS は Java 2 SDK, Standard Edition, v 1.2.1 以降で実装されている。
h) プラットフォーム
JCE 1.2.1 は Java 2 SDK v 1.2.1 以降か Java 2 Runtime Environment v 1.2.1 以降が必要 ([156])。
なお、JCE の最新版はβリリースされた J2SDK v1.4 に含まれる。
i) 適用例
[164] には、JCE 1.2.1 における Cryptographic Service Providers (CSP) および JCE 1.2 のクリーンルー
ム実装を提供する会社とその製品がリストアップされている。
•
IBM、IBM WebSphere preview technologies for Windows
http://www7b.boulder.ibm.com/wsdd/wspvtindex.html
は、以下のセキュリティ コンポーネントを含んでいる。
- Java Cryptography Extension (JCE) 1.2.1
- Certificate Management Protocol (CMP)
- Public Key Cryptography Standards (PKCS)
- Secure Multi-Purpose Internet Mail Extensions (S/MIME)
- Java Secure Sockets Extension (JSSE)
- The Java Authentication and Authorization Service (JAAS)
Developer Kit Package を用いることにより、JCE 1.2.1、JSSE、CMP、PKCS、S/MIME をアプリケ
ーションに組み込むことができる
http://www7b.boulder.ibm.com/wsdd/wspvtdevkit-info.html
•
Legion of the Bouncy Castle
後述 i.2) を参照。
•
RSA Security, Inc
http://www.rsasecurity.com/
http://www.rsasecurity.com/japan/news/data/199903161.html
によると、RSA BSAFE Crypto-J は
- JCA（Java Cryptography Architecture）と JCE（Java Crypto Extensionｓ）プロバイダをサ
ポート
と JCA、JCE プロバイダをサポートしていることが書かれている (が、JCA に触れているのは RSA
Security で唯一このページだけ)。
また [165] には、JCE 1.2 における Cryptographic Service Providers (CSP) および JCE 1.2 のクリーンル
ーム実装を提供する会社とその製品がリストアップされている。以下がそのリストである。
•
Cryptix、Cryptix JCE
http://www.cryptix.org/products/jce/index.html
•
DSTC Security、JCSI (Java Crypto and Security Implementation)
http://security.dstc.edu.au/projects/java/release3.html
•
Entrust(R) Technologies、Entrust/Toolkit Java Edition
http://www.entrust.com/news/files/03_16_98.htm に記事があるが、現在上記の名の製品はサイトの製品情報
に掲載されていない。
•
eSec Limited (前の社名は Australian Business Access)
81
http://www.esec.net.au/
[165]では、eSec Limited が JCE 1.2 のクリーンルーム実装を提供していて、URL を下記にしているが、
このページでは「このプロジェクトは今や消滅している」と書かれている。
OpenJCE.org
http://www.openjce.org/jce.html
OpenJCE.org の 1 年以上前のリリースである openjce provider を提供するサイトとして、
Wumpus Consulting、Java Cryptography Extension (JCE) Source
http://www.wumpus.com.au/crypto/aba.html
のサイトが紹介されており、ABA JCE V 1.1 ベースの JCE パッケージがリリースされている。
(が、このプロジェクトは既に活動していない) 。
また、現在活動しているプロジェクトとして後述の i.2) が紹介されている。
なお、OpenJCE.org のページには、
「このサイトは eSec Limited と全く関係ない」と書かれており、[165]
でリンクしている情報が誤っている。
•
Forge Research
http://www.forge.com.au/
Forge Research が開発している Protekt Encryption は、TLS v1 の Java 実装であり、JCE を用いて任
意の JCA 1.2 Security Provider にプラグインできるように設計されている。
Protekt Encryption
http://www.protekt.com/
上記サイトの Comments に下記のようなユーザからのコメントが掲載されており、JSSE の競合製品で
あることを示している。
「この開発に関する疑問に対して活発な反応があるために JSSE と競合するのを諦め、Forge 製品に
移 行 す る こ と に し た 。」 ("Your on-the-ball responsiveness to development questions was the
primary reason we gave up mucking around with JSSE (!) and switched to the Forge product.")
•
IAIK、IAIK-JCE
IAIK Java Cryptography Extension (IAIK-JCE) は API と暗号化関数 (cryptographic functions) の実
装の集合である。暗号化関数には、共通鍵暗号、公開鍵暗号、ストリームおよびブロック暗号が含まれ
る。
これはデフォルトの Java セキュリティ機能である JDK 1.1.x / JDK 1.2 を補い、それ自身が (DSA と
いう) デジタル署名 (digital signatures) と (MD5, SHA の) メッセージ ダイジェスト (message
digests) を含んでいる。
IAIK-JCE (jce - toolkit)
http://jcewww.iaik.at/products/jce/index.php
なお、利用にあたって有料のライセンスが必要である。
•
Phaos Technology、Phaos Crypto Toolkit
http://www.phaos.com/
Phaos Crypto
http://www.phaos.com/e_security/prod_crypt.html
Phaos Crypto は Java における暗号化のためのコアのアルゴリズムを提供する。Phaos Crypto は RSA
公開鍵暗号システム (RSA public key cryptosystem)、ARCFOUR (RC4) ストリーム暗号 (stream
cipher) 、 DES お よ び ト リ プ ル DES 暗 号 、 MD5 お よ び SHA メ ッ セ ー ジ ダ イ ジ ェ ス ト 、
Diffie-Hellman 鍵アグリーメント (Key Agreement) などの Java 実装を含んでいる。
Phaos Crypto に
より、一度書いたコードを JDK 1.1 から JDK 1.4 の任意の版の Java 上で実行することができる (Java
の標語である “write once, and run anywhere” とかけている)。
Phaos Crypto は JCE 1.2 provider を提供し、無料でダウンロードすることができる。
•
RSA Data Security, Inc. (RSA DSI)
現在、RSA Security, Inc.と社名が変わっている。また、対応製品については上述。
なお、上記の [165] に掲載された情報は古く、Entrust、eSec Limited などの記述が現状に則していない。
このため、下記に最新の情報で補足する。
i.1) Entrust、
、Entrust Authority Security Toolkit for Java
https://www.entrust.com/developer/java/index.htm
i.2) Legion of the Bouncy Castle、
、Bouncy Castle Crypto APIs
http://www.bouncycastle.org/
82
i.3) Bouncy Castle Crypto APIs
以下のコンポーネントを含む。
•
A lightweight cryptography API in Java.
•
A provider for the JCE and JCA.
•
A clean room implementation of the JCE 1.2.1.
•
Generators for Version 1 and Version 3 X.509 certificates and PKCS12 files.
•
A signed jar version suitable for JDK 1.4 (Beta) and the Sun JCE.
Lightweight API は J2ME から JDK 1.3 までのすべてで動作する。
i.4) Cryptix Foundation, LTD、
、Cryptix JCE
Cryptix JCE は Cryptix Foundation ([166]) が開発している JCE 1.2 完全互換ライブラリである ([167])。
Cryptix Foundation はオープンソースの暗号化ソフトウェア ライブラリを提供する国際的なボランティ
ア組織である。実際、RSA や PGP など、Sun の JCE 1.2 にない追加の暗号化アルゴリズムが提供されて
いる ([43])。
文献[43] では、JCE 1.2 は米国の輸出規制法で入手できないため、この規制にかからない全世界で使用可
能な JCE の別バージョンである Cryptix JCE の入手を勧めている。さらに、上記のように、JCE 1.2 にな
い追加の暗号化アルゴリズムを含んでいるため、Sun の JCE を入手できるかどうかにかかわらず、Cryptix
パッケージの入手を勧めている。
しかし、この文献出版後にリリースされた JCE 1.2.1 および J2SDK v1.4 用 JCE は輸出規制法に制限さ
れないため、日本でも入手が可能である。なお、 SUN JCE 1.2.1 と Cryptix JCE 1.3 では提供する機能
が異なる点に注意。
サイト[167] からは暫定版のパッケージ cryptix-jce-20011118-snap.zip (783 KB) がダウンロードできる。
また、過去に JCE 1.1 対応の製品として Cryptix 3 をリリース ([168]) しているが、Cryptix JCE の最終
リリース後には過去の遺物となる、と明記されている。
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
現在までにこの項に関する情報は入手できていない。
l) 利用コスト
商用の利用が無料 ([169])。なお、詳細はソフトウェア ラインセンスを参照 ([170])。
JCE 1.2.1 のソースコードおよびドキュメントが [171] から入手できる。
また、J2SDK v1.4 版 JSSE は、[189] から J2SDK v1.4 一式を入手すれば良い。
一つ古い JCE 1.2 は、ドキュメントが [172] からダウンロードできるが、ソフトウェアはアメリカ合衆国
およびカナダのみ [173] からダウンロードできる。
m) 関連文書の入手可否
JCE 1.2.1 は [154] から、また J2SDK v1.4 用の JCE は [156] から入手できる。
(さらに、一つ古い版の JCE 1.2 は [155] で参照可能)。
n) 他 API との関係
n.1) JCA
JCE は 、 JCA API を 拡 張 し て 、 暗 号 化 (encryption) 、 鍵 交 換 (key exchange) 、 MAC (Message
Authentication Code) の API を提供する。
つまり、JCE と SDK の暗号化機能が一緒になって、完全でプラットフォーム非依存の暗号 API
(cryptography API) を提供することができる ([263])。
83
o) 拡張性
暗号化の API を規定しているので、プロバイダを取り替えることにより、様々な暗号アルゴリズムを共通
のインタフェースで用いることができる。
また、Jurisdiction Policy File により暗号化強度に対する制限を変更することができる。
J2SDK, v 1.4 と同梱の Jurisdiction Policy File では、(特定の国に対する) 米国輸出規制で制限される暗
号機能しか使用できない。が、規制に該当しないほとんどの国では、[174] から強度無制限の Jurisdiction
Policy File を入手し、
これを用いることにより JCE が提供する強度の高い暗号化機能が使用できる ([156])。
JCE 1.2.1 の場合は配布物の中に強度無制限の Jurisdiction Policy Files が同梱されている ([154])。
3.2.8 JSSE (Sun)
1) API 名
Java Secure Socket Extension (JSSE)
2) 概説
JSSE はセキュアなインターネット コミュニケーションを可能とする Java パッケージのセットである。
Java 版の SSL (Secure Sockets Layer) および TLS (Transport Layer Security) プロトコルを実装し、デ
ータ暗号化 (data encryption) 、サーバ認証 (server authentication) 、メッセージ完全性 (message
integrity)、オプションのクライアント認証 (optional client authentication) のための機能をサポートする。
JSSE を使うことにより、開発者は TCP/IP 上の HTTP、Telnet、NNTP、FTP のようなアプリケーショ
ン プロトコルが使えるクライアント サーバ間のセキュアなデータ交換の機能を組み込むことができる
([175])。
3) 歴史
現版の J2SDK v1.3 においては、JSSE 1.0.2 がオプションのパッケージとしてリリースされている。
JSSE 1.0.1 から JSSE 1.0.2 にバージョンアップされる際に、PersonalJava 3.1 ([176]) 対応と、アメリカ
合衆国の輸出規制に対する最近の修正(緩和)を反映し、海外版により強力な暗号アルゴリズムを組み込んだ。
国内版と海外版の差は、海外版が Sun SSL provider のみの対応に対し、国内版は別の SSL security
providers に対応していることである ([177])。
次期版である J2SDK v1.4 はβ版が公開されているが、
v1.4 においては J2SDK の中に組み込まれる ([175])。
4) 特徴
以下、資料[178]より引用。
•
Pure Java implementation
•
Exportable
•
Secure Sockets Layer (SSL) v3 support
•
Transport Layer Security (TLS) 1.0 support
•
私有鍵のセキュアな暗号格納と CA サポートを含む、鍵および証明書管理のための基本ユーティリテ
ィ (Basic utilities for key and certificate management, including securely encrypted storage of
private keys and Certificate Authority (CA) support)
•
セ キ ュ ア チ ャ ン ネ ル を 作 成 す る た め に イ ン ス タ ン ス 生 成 さ れ る 、 SSLSocket お よ び
SSLServerSocket クラス
•
セキュア通信の初期化および確証を行う SSL ハンドシェイクを実行する、暗号スイート ネゴシエー
ション (Cipher Suite negotiation, which performs SSL "handshaking" to initiate or verify secure
communications)
•
標準の SSL ハンドシェイク の一部としての、クライアントおよびサーバの認証
•
HTTPS サポート: HTTPS を通じての HTML ページのようなデータへアクセスする能力
•
セッションのキャッシュを管理するための サーバ セッション管理 (Server Session Management)
•
RSA 暗号化アルゴリズム (cryptography algorithms) -- JSSE 実装は RSA Data Security からライ
84
•
センスされたコードを含んでいる。
以下を含む、暗号化スイート (Cryptographic suites):
Domestic and Global
Global
Cryptographic Suite
Key Length
RSA public key
(authentication and key agreement)
2048 bits (authentication),
2048 bits (key agreement)
RC4 (bulk encryption)
DES (bulk encryption)
128 bits
64 bits (56 effective)
Triple DES (bulk encryption)
Diffie-Hellman public key (key agreement)
192 bits (112 effective)
1024 bits
DSA public key (authentication)
2048 bits
5) パッケージ
•
•
•
•
com.sun.net.ssl
javax.net
javax.net.ssl
javax.security.cert
J2SDK v1.4 では com.sun.net.ssl でなく、上記のパッケージの下 3 つのパッケージに統合されている。
6) Java SSL
資料[179]には Java SSL パッケージとして以下の 3 つが紹介されている。
•
IAIK JCE/iSaSiLk; http://jcewww.iaik.tu-graz.ac.at/
IAIK は オ ー ス ト リ ア に お け る 応 用 情 報 処 理 お よ び 通 信 の た め の 機 関 で あ る 。 JCE は Java
Cryptography Extension であり、 IAIK-iSaSiLk は SSLv3 の Java 実装である。JCE および IAIKい SaSiLk は Java による完全な SSL 機能を提供するのに必要である。
•
Claymore Systems' PureTLS/Cryptix; http://www.rtfm.com/puretls/ http://www.cryptix.org/
Claymore の PureTLS パッケージは Cryptix の暗号化ソフトウェア パッケージを必要とする。また、
ASN.1 ソフトウェアのいくつかに対してパッチを当てる必要もある。
•
Sun の JSSE package; http://developer.java.sun.com/developer/earlyAccess/jsse/
Sun の JSSE (Java Secure Socket Extension) は初期のアクセス方法により最近リリースされた。
これら 3 つは JCA を用いているが、API 仕様はそれぞれ異なっている。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
アプリケーション
|
JSSE
|
|
core Java 2.0
JCA
上記は文献[43] の図より引用。
JSSE 1.0.2 は "SunJSSE" という名前の Cryptographic Service Provider を用いる ([191])。
SunJSSE プロバイダが提供するセキュリティ サービスは以下。
•
Java 2 プラットフォームの署名関連 JCA 機能 (signature-related JCA features) に対する RSA サ
ポート。
•
SSL 3.0 および TLS 1.0 セキュリティ プロトコルの実装。
•
認証 (authentication)、鍵アグリーメント (key agreement)、暗号化 (encryption) および完全性保護
(integrity protection) の組み合わせを包含する、最も一般的な SSL および TLS 暗号スイート
(cipher suites) の実装。
85
•
•
•
標準の JCA KeyStore から適切な認証鍵 (authentication keys) を選ぶ、X.509 ベースの鍵マネージ
ャ (key manager) の実装。
証明書チェーン パス確証 (certificate chain path validation) のための RFC 2459 ルールのサブセ
ットを実装する、X.509 ベースの トラスト マネージャ (trust manager) の実装。
JCA keystore type "pkcs12" としての PKCS12 の実装。
JSSE は SSL ソケットの API を定義するだけで、Sun は JSSE のリファレンス実装によりこの API のデ
フォルト実装を提供している。理論的には、サードパーティの JSSE 実装を入手して JSSE フレームワー
クにプラグすることができますが、実際にある特定の操作を実行するために Sun 実装固有のクラスを使う
必要がある。よって、JSSE を使うアプリケーションは必ずしも実装非依存ではない。Sun の JSSE リフ
ァレンス実装は SSL 3.0 と TLS 1.0 のみサポートする ([48])。
b) 提供するセキュリティの機能
以下を含むセキュアなインターネット コミュニケーションを提供する ([180])。
•
データ暗号化 (Data encryption)
•
認証 (Authentication)
•
メッセージ完全性 (Message integrity)
また、Sun のリファレンス実装には、以下を含む ([180])。
•
SSL v3.0、TLS v1.0
•
組み込みアルゴリズム
- RSA、RC4、DES、3DES、DH、DSA、SHA、MD5
- ただし、これらのアルゴリズムに直接アクセスすることはできない (JCA)
•
https サポート
c) API 数
以下の 18 クラス、125 メソッド ([191]、[181])。
Core Classes and Interfaces (7 クラス、62
クラス、62 メソッド):
メソッド):
•
SSLSocket Class (18 メソッド)
•
SSLServerSocket Class (12 メソッド)
•
SocketFactory Class (6 メソッド)
•
ServerSocketFactory Class (5 メソッド)
•
SSLSocketFactory Class (5 メソッド)
•
SSLServerSocketFactory Class (4 メソッド)
•
SSLSession Interface (12 メソッド)
Support Classes and Interfaces (6 クラス、27
クラス、27 メソッド):
メソッド):
•
SSLSessionContext Interface (2 メソッド)
•
SSLSessionBindingListener Interface (2 メソッド)
•
SSLSessionBindingEvent Class (3 メソッド)
•
HandShakeCompletedListener Interface (1 メソッド)
•
HandShakeCompletedEvent Class (5 メソッド)
•
X509Certificate Class (14 メソッド)
Reference Implementation Cla
Classes
sses and Interfaces (5 クラス、36
クラス、36 メソッド):
メソッド):
•
SSLContext Class (9 メソッド)
•
TrustManagerFactory Class (9 メソッド)
•
X509TrustManager Interface (3 メソッド)
•
KeyManagerFactory Class (9 メソッド)
•
X509KeyManager Interface (6 メソッド)
注) 上位クラスからの継承するメソッドを含まず。
また、J2SDK v1.4 用の JSSE では、19 クラス、140 メソッド ([182])。
86
Core Classes and Interfaces (7 クラス、61
クラス、61 メソッド):
メソッド):
•
SocketFactory Class (7 メソッド)
•
ServerSocketFactory Classe (6 メソッド)
•
SSLSocket Class (18 メソッド)
•
SSLServerSocket Classe (6 メソッド)
•
SSLSocketFactory Class (5 メソッド)
•
SSLServerSocketFactory Classe (4 メソッド)
•
SSLSession Interface (15 メソッド)
Support Classes and Interfaces (5 クラス、34
クラス、34 メソッド):
メソッド):
•
SLContext Class (11 メソッド)
•
TrustManagerFactory Class (10 メソッド)
•
X509TrustManager Interface (3 メソッド)
•
KeyManagerFactory Class (10 メソッド)
•
X509KeyManager Interface (6 メソッド)
Secondary Support Classes and Interfaces
Interfaces (7 クラス、45
クラス、45 メソッド):
メソッド):
•
SSLSessionContext Interface (6 メソッド)
•
SSLSessionBindingListener Interface (2 メソッド)
•
SSLSessionBindingEvent Class (3 メソッド)
•
HandShakeCompletedListener Interface (1 メソッド)
•
HandShakeCompletedEvent Class (7 メソッド)
•
X509Certificate Class (14 メソッド)
•
HttpsURLConnection Class (12 メソッド)
d) ベースとなる技術
SSL v3.0、TLS v1.0
e) 利用対象アプリケーション
SSL または TLS で通信するアプリケーション。特に HTTPS を利用した Web アプリケーション ([43])。
f) アプリケーション開発の容易さ
SSL または TLS という固有の領域に限定されており、これらのプロトコルの知識と JSSE のプログラミ
ングの知識を文献[43] または[48] などで習得することにより容易に開発することができる。(ただし、Java
プログラミングおよび Java セキュリティに関しての知識がないと習得が難しいと思われる) 。
また、普通の HTTP サーバと通信するためのコードと同じコードを用いて、HTTPS サーバと通信するア
プリケーションを容易に開発することができる ([48])。
g) ポータビリティ
Java プラットフォームが実装されていれば、UNIX、Windows など OS に依存しない。
ただし、下記 h) のように JAAS は Java 2 SDK, Standard Edition, v 1.2.1 以降で実装されている。
h) プラットフォーム
Sun のリファレンス実装は Java 2 SDK, Standard Edition, version 1.2.1 以降をサポート。
また、JSSE API は JDK 1.1.x または Java 2 Platform, Standard Edition 上に実装可能である ([177])。
i) 適用例
i.1) iPlanet
以下の製品は JSSE 対応 ([183])。
•
iPlanet Application Server (iAS EPE) ([184])
•
iPlanet BuyerXpert ([185])
87
i.2) igloo, the eSec Electronic Commerce Framework
http://www.igloo.esec.com.au/
Igloo, the eSec Electronic Commerce Framework は、E サービスおよび E マーケットプレイスを開発、
展開するための設計モデル、ソフトウェア開発ツールキットである。
Igloo の特徴としては、
•
エージェント ベース(Agent Based)
•
オープンソース (Open Source)
であり、上記のサイトからドキュメントおよびソースコードを入手することができる。
このソフトは Sun JSSE のためのサードパーティの jar ファイルが必要。
eSec Limited
http://www.esec.net.au/
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
Secure Sockets Layer (SSL) v3 および Transport Layer Security (TLS) 1.0 ([177])。
l) 利用コスト
商用の利用が無料 ([177])。なお、詳細はソフトウェア ラインセンスを参照 ([186])。
ソースコードおよびドキュメントが[178]から入手できる。
(米国の輸出規制があるため、US/CANADA 国内版 ([187]) と海外版 ([188]) の 2 種類があるが、どちらもダ
ウンロードにユーザ登録が必要)。
また、J2SDK v1.4 版 JSSE は、ページ[189] から J2SDK v1.4 一式を入手すれば良い。
m) 関連文書の入手可否
JSSE 1.0.2 の関連文書は [178] から入手できる。また、J2SDK v1.4 の JSSE の関連文書は [190] から入手
できる。
n) 他 API との関係
n.1) JCA
実際の暗号アルゴリズムはその下のレイヤーの JCA を用いる。JSSE は JCA の SPI を用いている ([180])。
o) 拡張性
JSSE 1.0.2 へのバージョンアップにより、ユーザが利用できるリファレンス実装を含むため、以下の 2 つ
の設定などを行うことによりユーザがカスタマイズできるようになった ([191])。
•
システムプロパティの設定
•
セキュリティプロパティの設定
なお、カスタマイズ可能な項目などの詳細については、[191] の "JSSE 1.0.2 Customization" の表を参照。
ただし、このプラグ可能 (pluggability) は国内版のみでしか使えない。
88
3.2.9 Java GSS-API (Sun)
1) API 名
Java GSS-API
2) 概説
Java GSS-API は通信アプリケーション (communicating applications) 間の安全なメッセージ交換
(securely exchanging messages) の機能を提供する。
Java GSS-API には RFC 2853 として定義されている "Generic Security Services Application Program
Interface (GSS-API)の Java 実装 (Java Bindings)" が含まれる。
GSS-API はアプリケーション開発者がセキュリティ サービスに対する統一的なアクセスができるように、
Kerberos を含む様々な基本的セキュリティ機構の上部に位置している (資料[192])。(なお、資料[46]などで
は JGSS と略記されている)。
Java GSS-API は 認 証 (authentication) 、 デ ー タ 完 全 性 (data integrity) 、 デ ー タ 機 密 性 (data
confidentiality) というセキュリティ サービスを、Kerberos のような下位に位置する様々なセキュリティ
メカニズムを API により利用可能にする。
アプリケーションが利用するセキュリティ メカニズムは一意のオブジェクト識別子によって識別される。
例えば、Kerberos v5 GSS-API メカニズムの場合、オブジェクト識別子は 1.2.840.113554.1.2.2 である。
このメカニズムは GSSManager クラスのデフォルト インスタンスにより提供される。
3) 歴史
Java 2 SDK, Standard Edition (J2SDK), v 1.4 で新規に追加された (資料[193])。
GSS-API の歴史については 3. GSS-API で説明している。
4) 標準化
資料[104] では、IETF の RFC 2853 として GSS-API の Java 言語実装 (Java Bindings) が提案されてお
り、この Java GSS-API には RFC 2853 が統合されている。
5) パッケージ
以下の 2 種類のパッケージに存在する。
•
org.ietf.jgss
•
com.sun.security.jgss
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
アプリケーション
|
Java GSS-API
|
JCA および JCE
b) 提供するセキュリティの機能
通信アプリケーション間のセキュアなメッセージ交換。
c) API 数
以下の 9 クラス、117 メソッド (資料[193])。
•
GSSContext (40 メソッド)
•
GSSCredential (12 メソッド)
•
GSSName (9 メソッド)
•
ChannelBinding (7 メソッド)
•
GSSManager (17 メソッド)
89
•
MessageProp (13 メソッド)
•
Oid (8 メソッド)
•
GSSException (9 メソッド)
•
GSSUtil (2 メソッド)
備考) ただし、上記から継承したメソッドを含まず。
GSS-API Java Bindings では以下の 8 クラス、105 メソッドになっている ([104])。
•
GSSContext (40 メソッド)
•
GSSCredential (11 メソッド)
•
GSSName (8 メソッド)
•
ChannelBinding (5 メソッド)
•
GSSManager (16 メソッド)
•
MessageProp (12 メソッド)
•
Oid (5 メソッド)
•
GSSException (8 メソッド)
備考) 上記では関数の種類を数えているのに対し、Java GSS-API ではメソッドの個数を数えているため
引数が異なるものもカウントしている。
d) ベースとなる技術
GSS-API 自身は特定のセキュリティメカニズムを提供するものではなく、汎用のインタフェースである。
ただし、GSS-API の下位に位置するプロバイダ (Provider) が特定のセキュリティ メカニズムを提供する
ため、Kerberos v5 や SPKM をサポートするプロバイダを用いることによりこれらのセキュリティ メカ
ニズムを提供することができる ([104])。
e) 利用対象アプリケーション
Kerberos ないし SPKM を用いてセキュリティを実装する製品。
f) アプリケーション開発の容易さ
GSS-API 自身はセキュリティの高度な知識が必要とせずにプログラミングできるような上位のレベルの
API になっている。このため、アプリケーション開発は低レベルの API を用いた場合よりも容易に開発で
きる。
が、Java プログラミングおよび Java セキュリティに関して知識のないプログラマは難しさを感じると思
われる。また、ベースとする Kerberos および SPKM を用いるため、これらの技術的知識および用いる
環境に関する知識を必要とする。
さらに、後述の i.1) のような開発環境を用いることにより開発作業が効率化される。
g) ポータビリティ
Java プラットフォームが実装されていれば、UNIX、Windows など OS に依存しない。
ただし、下記 h) のように Java GSS-API は Java 2 SDK, Standard Edition, v 1.4 以降で実装されている。
h) プラットフォーム
Java GSS-API は Java 2 SDK, Standard Edition, v 1.4 または Java 2 Runtime Environment v 1.4 が
プラットフォーム (資料[193])。
i) 適用例
i.1) Systinet
Systinet ([194]) 社の Web サービス開発展開環境である "WASP Server Advanced for Java" は Java ベー
スの GSS/SPKM すなわち Java GSS-API を用いている ([195])。
また、この環境がベースとする "WASP Security Framework" という枠組みでは、Java の標準 API であ
90
る JAAS、JCE、JSSE、JGSS を用いている ([196])。
また、[197] によると、SPKM ベースの Java GSS-API v2 実装をリリースし、以下の特徴を持つ。
Full JCE 1.2.1 compatibility
•
Generic Security Service (GSS) API implementation in Java
•
SPKM compatibility
•
Free download
この実装は上記の製品で使われ、WASP 2.0 のセキュリティ レイヤーを構成する。
i.2) JGSS Package
イリノイ大学 (University of Illinois) システム ソフトウェア リサーチ グループ (Systems Software
Research Group) により RFC-1508 を実装した Java パッケージ ([198])。本項で述べているように Java
GSS-API の実装は Sun が Java 2 SDK, v1.4 で行っており、このパッケージは Sun のリリース前の実装
となる。資料[198] では JGSS Package を利用して active capability security and protection model の実
装中、と書かれているため、敢えて適用例にあげた。
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
IETF RFC2853、"Generic Security Service API Version 2 : Java Bindings" に準拠 (資料[104])。
また、IETF RFC2853 は RFC2743、GSS-API ([94]) の Java 言語実装である。
l) 利用コスト
Java 2 SDK, v1.4 に GSS-API/Kerberos v5 が含まれるため、Java 2 SDK, v1.4 を資料[189] から無料で入
手することができる ([199])。
m) 関連文書の入手可否
仕様書はオンラインで[193] よりアクセスできるが、[189] からダウンロード可能なドキュメント一式の中に
含まれる。また、JAAS および Java GSS-API のチュートリアルが [192] にあり、このページから関連す
る情報を入手することができる。
n) 他 API との関係
n.1) JAAS
[192], [200], [201], [202] を参照。
Java GSS-API を用いたセキュア コミュニケーションの前に JAAS 認証 (authentication) が典型的に実
行される。このように JAAS と Java GSS-API は関係があり、しばしば同時に利用される。しかし、Java
GSS-API なしで JAAS を利用するアプリケーションもあれば、JAAS なしで Java GSS-API を利用するア
プリケーションもありうる。さらに、JAAS 自身は単に認証か、あるいは、認証と認可の両方に利用でき
る (資料[192])。
v1.4 に Krb5LoginModule ログインモジュールを追加することにより、JAAS アプリケーションが
Kerberos 5 によるユーザ認証が可能となる。
n.2) JSSE
JSSE も Java GSS-API のどちらもセキュア コミュニケーションで利用される(資料[192])。
JSSE も Java GSS-API のどちらも、以下の 2 つの機能を提供するが、
•
クライアント サーバ認証 (Client-server authentication)
•
転送データの暗号化と完全性保護 (Encryption and integrity protection of transmitted data)
以下の 5 つの点で違いがある (資料[203])。
① Kerberos Single SignSign-On Support
Java 2 Standard Edition では、GSS-API は Kerberos サポートを必須のセキュリティ機構として含んで
いる。
91
これは、デスクトップが Kerberos をサポートしているのであれば、ユーザにパスワードを問い合わせな
い Java GSS-API ベースのアプリケーションを書くことができる、ということを意味している。
② Communications API
JSSE はソケットベースの API を提供する。JSSE Sockets は java.net の socket クラスを拡張し、JSSE
socket factories は java.net の socket factories を拡張する。
このため、利用するアプリケーションが socket factory を通じてセキュリティを設定するように書かれ
ているのであれば、JSSE がより適する。JSSE Sockets はより信頼性のあるトランスポート (Transport)
を使う必要があり、一般的な実装では TCP を利用する。
一方、Java GSS-API はトークンベースの API で、通信を行うアプリケーションに依存する。
③ Credential Delegation
Kerberos を用いる Java GSS-API であれば、クライアントがそのクレデンシャル (credentials) をサー
バに委任 (delegate) することができる。
仲介者 (intermediaries) がバックエンド レイヤーと通信するクライアントを体現する必要のあるよう
な多層環境 (multi-tier environment) では、Java GSS-API がより適する。
④ Selective Encryption
Java GSS-API はトークン ベースなので、メッセージを抜粋して暗号化するのを選ぶことができる。
平文 (plaintext) と暗号文 (ciphertext) が混在するメッセージを使うアプリケーションの場合は、Java
GSS-API が適する。
⑤ Protocol Requirements
JSSE は RFC 2246 で定義された TLS プロトコルを実装しているが、Java GSS-API は
RFC 1964 で
定義された Kerberos Version 5 メカニズム (Win32 プラットフォームでは SSPI with Kerberos として
知られている) を含む、RFC 2853 で定義された GSS-API フレームワークを実装している。
HTTPS サーバは TLS が必要であるため JSSE が適しており、SASL を用いた LDAP サーバでは
GSS-API with Kerberos が必要であるため Java GSS-API が適する。
n.3) Kerberos V5 GSSAPI Mechanism
秘密鍵メカニズムの例が Kerberos V5 GSSAPI Mechanism. である (資料[204])。
n.4) Simple Public Key GSSAPI Mechanism (SPKM)
公開鍵メカニズムの例が Simple Public Key GSSAPI Mechanism (SPKM) である (資料[204])。
n.5) Secure European System for Applications in a Multi-vendor Environment (SESAME)
秘密鍵および公開鍵の両方を提供するメカニズムが Secure European System for Applications in a
Multi-vendor Environment (SESAME) である (資料[204])。
o) 拡張性
JCA/JCE をベースにしているためこれらが提供する拡張性と同じく、GSS-API の下位に位置するプロバ
イダ (Provider) が特定のセキュリティ メカニズムを実装し、このプロバイダにより拡張性を有する。ま
た、仕様上 GSS-API と同じ拡張性を有すると思われる。
3.2.10 Crypto-API (IPA、三菱電機
、三菱電機)
、三菱電機
1) API 名
Crypto-API
2) 概説
IPA ([205]) が実施した「平成 12 年度 電子政府情報セキュリティ基盤技術開発」の一環として、三菱電機
株式会社が実施機関として「Crypto-API の開発」のテーマで行ったプロジェクトの成果である ([206])。
電子政府や電子調達などの電子政府システムの多くは、PKI（公開鍵基盤）に基づいて構築されようとし
ている。これらの電子政府システムの開発・保守性及び相互運用性を高めるために、電子政府対応の利用
92
者側認証システム構築に用いられる PKI ライブラリの標準仕様を確立することが重要である。
また、電子政府認証基盤用の暗号を利用可能とするとともに、今後のより良い暗号に容易に切り替えられ
る仕組み等が必要である。
本プロジェクトでは、これらのニーズに応えるような PKI ライブラリの標準的 API 仕様を開発し広く公
開して行くことを目標としている。平成 12 年度は、PKI ライブラリのモデル化、セキュリティ機能要件
検討及びアーキテクチャ設計を経て、PKI ライブラリの機能設計を実施した。
3) 最新情報
平成 12 年度に行われた活動は平成 13 年度も引き続き継続している ([207])。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
仕様書 ([210], [211], [211]) から構成に関する図をいかに引用する。
「PKI ライブラリの論理機能構成」
「API-SP 構造と暗号アルゴリズムの実装関係の例」
93
「Crypto−API のライブラリ・モジュール構成概念」
b) 提供するセキュリティの機能
API 層におけるモジュール群の論理名と機能概要を以下に示す ([208])。
•
基本暗号処理機能
公開鍵暗号アルゴリズムの公開鍵・秘密鍵を用いた暗号化と復号を行う。
共通鍵暗号アルゴリズムの共通鍵の生成、共通鍵を用いた暗号化と復号を行う。
ハッシュアルゴリズムを用いたハッシュ値の生成を行う。
•
鍵管理機能
公開鍵暗号アルゴリズムの公開鍵と秘密鍵の対を、鍵管理媒体を用いて保管・管理する。
94
•
•
•
•
•
•
•
•
また、鍵管理媒体上の秘密鍵を用いた暗号処理を行う。
認証書管理機能
認証書を保管・管理する。認証書には、利用者の認証書、認証局(CA)の認証書、他人の認証書を含む。
信頼点に相当する認証書を管理するために、認証書を安全に保管・管理するための機能を含む。
失効情報管理機能
CRL を保管・管理する。安全に保管・管理するための機能を含む。
鍵対生成機能
公開鍵暗号アルゴリズムの公開鍵と秘密鍵の対を生成する。公開鍵と秘密鍵の対は、計算機の主記憶上、
または鍵管理媒体上に生成する。また、アルゴリズム仕様に定義された鍵の標準形式として生成する。
署名生成機能
公開鍵暗号アルゴリズムの秘密鍵を用いて、署名アルゴリズムに従った署名の生成を行う。
秘密鍵は、計算機の主記憶上の秘密鍵、または鍵管理媒体上の秘密鍵を用いる。
署名検証機能
公開鍵暗号アルゴリズムの公開鍵を用いて、署名アルゴリズムに従った署名の検証を行う。公開鍵は、
計算機の主記憶上の公開鍵を用いる。
親展機能
公開鍵暗号アルゴリズムの公開鍵と共通鍵暗号アルゴリズムの共通鍵を用いて、親展データを生成する。
公開鍵は、計算機の主記憶上の公開鍵を用いる。
認証書検証機能
使用する認証書の正当性を確認する。検証する認証書、信頼点の認証書などを用いて認証パスを構築す
る機能、失効情報などを用いて認証パスに含まれる確認証書を検証する機能を含む。
SP 管理機能
Service Provider の登録・削除などの管理を行う。
c) API 数
現段階では具体的な API に至る設計まで進んでいないため、API 数を報告することはできない。
d) ベースとなる技術
PKI。また、暗号アルゴリズム独立機構の実現にオブジェクト指向と抽象データ型の概念を導入している
([208])。
e) 利用対象アプリケーション
Crypt-API 仕様に準拠した PKI ライブラリを用いて利用者側認証システムを構築することにより、電子政
府システム構築が容易になるとともに、次のような相互運用性・保守性が向上することが期待される ([209])。
•
マルチベンダー環境によるシステム構築が可能
•
暗号アルゴリズム独立、暗号ライブラリ独立、電子政府認証基盤指定の暗号サポート
•
秘密鍵・認証書・失効情報の管理媒体独立 (HDD、IC カード、鍵管理装置等)
•
認証書検証仕様独立
f) アプリケーション開発の容易さ
具体的な関数レベルまで設計が進んでいないため、開発の容易さについて触れることはできない。今後の
設計に依存する。
g) ポータビリティ
PKI に沿った相互運用性を含むポータビリティを提供するが、具体的なポータビリティについては現段階
で情報入手することができない。
h) プラットフォーム
Windows 系または UNIX 系 OS に、HDD、IC カード、HSM のような秘密鍵保管媒体の装置 ([209])。
95
また、Crypto-API が想定する外部動作環境は、下図「論理モデルの外部環境」を参照 ([209])。
i) 適用例
平成 12 年度の報告書[209] に書かれている通り、現在、仕様策定および実証実験の継続段階にあり、
Crypto-API 準拠の製品開発は今後の課題とされている。
今後、Crypto-API 準拠の PKI ライブラリ関連製品が用意され、主要ベンダー各社の賛同と自主開発への
協力が期待される。
また、最終目標である電子政府システムが Crypto-API を用いて開発されることが期待される。
j) 推進団体または提案した会社
IPA/ISEC がスポンサーとなり、三菱電機株式会社が実施機関。
また、プロジェクトメンバーに、東京工業大学、(株)NTT データ、(株)日立製作所、日本電気(株)が参画し
ている ([209])。
k) 準拠する標準
認証書検証仕様独立機構が想定する証明書は、国際標準規格、ITU-T 勧告 X.509 に準拠 ([208])。
l) 利用コスト
現状入手できる情報で利用コストやライセンス関する情報が含まれていないが、無料で公開されると予想
される。また、リファレンス実装が無料で利用できるようにすることが望まれる。
m) 関連文書の入手可否
平成 12 年度の成果は「Crypto-API の開発」という題の報告書が入手可能 ([209])。
なお、4 種類の設計書が作成されているが、これらは一般公開されておらず、本プロジェクトでは IPA を
通じて入手した ([208], [210], [211], [212])。
n) 他 API との関係
n.1) CDSA
検討にあたり CDSA を参考にしている ([209])。
96
o) 拡張性
以下の独立性などに起因する拡張性を持っている ([209])。
•
マルチベンダーシステム (PKI ベンダー独立)
複数ベンダーの PKI 製品からなるシステムを構築可能。また、PKI ベンダー/製品を切り替え可能。
•
暗号アルゴリズム独立システム
暗号アルゴリズムおよび暗号アルゴリズムを実装した暗号ライブラリを動的/静的に切り替え可能。
•
管理媒体独立システム
秘密鍵、認証書、失効情報の管理媒体とし、HDD、IC カード、耐タンパー秘密鍵管理装置等を切り替
え可能。
•
複数 CA ドメインから成る認証システム
ブリッジ CA を介した相互認証を含む複雑な認証経路での汎用的な認証書検証が可能。
•
マルチアプリケーション システム (認証書検証仕様独立)
多様なアプリケーションのニーズに応じて、認証書検証機能を切替え可能。
3.2.11 OPSEC (CheckPoint Software)
1) API 名
OPSEC (the Open Platform for Security) API
2) 概説
CheckPoint Software 社が提唱するセキュリティのオープンプラットフォームである OPSEC に含まれる
API ([213])。
OPSEC (Open Platform for Security) はネットワーク セキュリティのさまざまな面を統合管理するため
のオープンで拡張可能な管理フレームワークである。
Check Point Software Technologies によって開発され、真にエンタープライズ ワイドのセキュリティ統
合をポリシーレベルで達成する、デファクトの業界標準のプラット-フォームとなった ([214])。
OPSEC は VPN-1/FireWall-1 を中心にしたネットワーク環境で、主にポリシーベースでネットワーク管理
を統合するためのフレームワークである ([215])。
OPSEC は CheckPoint 社製品を中心にマルチベンダーでネットワーク環境を構築し、後述の API によっ
て製品を結合することができる。
この協調は CheckPoint が主導する OPSEC Alliance というアライアンスによって行われており、現在、
300 社以上が加盟し、OPSEC Certified という認証体制も整えられている。
先ほど述べたように現状の OPSEC はセキュリティ製品を開発するためのフレームワーク、および API を
提供するというよりも、CheckPoint 社製品、特に VPN-1/FireWall-1 製品を中心としてネットワークに以
下に自社製品を統合し、ネットワーク管理を統合するか、という点に焦点が集中している。このため、CDSA
のようなセキュリティ サービスを実装するという今回の調査対象とは性質が異なる。
3) OPSEC SDK Features
OPSEC SDK の特徴は以下 ([214])。
•
統合のために必要な全ての OPSEC API を定義する
•
C ライブラリ、ヘッダ ファイル、関連文書を含む
•
業界標準プロトコルのサポート
•
セキュアな TCP/IP 接続により、統合アプリケーションの分散配布 (distributed deployment) を可能
にする
•
開発およびデバッグの助けになるようなツールとサンプル コードの提供
97
4) OPSEC SDK Benefits
OPSEC SDK の利点は以下 ([214])。
•
アプリケーションを Check Point 製品に素早く簡単に統合する
•
API レベルで Check Point 製品に統合することにより、将来的な相互運用性を保証しながらメンテ
ナンス コストを最小にする
•
アプリケーションを最高クラスのセキュリティ製品とポリシー レベルで統合する
5) 競合フレームワーク
OPSEC に競合するベンダー主導のフレームワークは以下の表 ([215])。
企業
Network Associates
Axent
IBM
フレームワーク
Active Security ([216])
Smart Security Architecture ([217])
FirstSecure ([218])
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
OPSEC フレームワーク は、サードパーティのセ キュリティ アプリケー ションを統合する一方、
VPN-1/FireWall-1 の集中的な構成および管理を提供する ([219])。
図 1. 分散 VPN-1/FireWall-1 構成
OPSEC は強力なメッセージ ベースでレイヤー化された環境を提供する ([219])。
OPSEC API は以下を開発するのに適する非同期のインタフェースを定義している；
•
一つ以上の OPSEC セキュリティタスクを実装するサーバ
•
OPSEC サーバを用いるクライアント
OPSEC API はクライアント、サーバ間のコネクションを開き、モニターするのに使う関数を含んでいる。
OPSEC Transport Layer はコネクションに渡るメッセージをイベントに変換する。これらの関数は
OPSEC アプリケーションの全てに共通である。
OPSE アプリケーションの全てで使用される共通 API 関数に加えて、特定のアプリケーションは固有の
API 関数を利用する。これを図示したものが次の図 2 である。
98
図 2. OPSEC API ヒエラルキー
OPSEC SDK は、Check Point 製品ファミリーと密接に統合される、商用製品とカスタム ソリューショ
ンを構築するのに必要なツールを含んでいる。文書、インタフェース仕様、API ライブラリには、次のコ
ンポーネントがある ([220]):
CVP, UFP, LEA, ELA, SAM, CPMI, AMON, UAA, SCV.
また、[214] の表 1、"The OPSEC APIs " に API 一覧がある。そこから抜粋すると以下の 12 コンポーネン
ト。
•
CPMI (Check Point Management Interface)
•
AMON (Application Monitoring)
•
CVP (Content Vectoring Protocol)
•
UFP (URL Filtering Protocol)
•
UAM (User Address Mapping)
•
SAM (Suspicious Activities Monitoring)
•
LEA (Log Export API)
•
ELA (Event Logging API)
•
OMI (Object Management Interface)
•
SAA (Secure Authentication API)
•
SCV (Security Configuration Verification API)
•
UAA (User Authority API)
備考) OMI はサポート外になるので、CPMI に移行が必要。
b) 提供するセキュリティの機能
OPSEC フレームワークにより開発されるアプリケーションのサブセットは以下 ([215])。
•
侵入検知 (Intrusion Detection)
•
コンテンツ セキュリティ (Content Security)
•
Web フィルタリング (Web Filtering)
•
認証と認可 (Authentication and Authorization)
これの他に以下がある。
•
ログ エクスポート (Log Exporting)
•
エベント ログ (Event Logging)
•
管理と分析 (Management and Analysis)
•
VPN-1 クライアント認証
99
c) API 数
仕様書が入手できる以下の 9 コンポーネントで合計 160 関数。
•
OPSEC API
37 関数 ([219])
•
SAA
8 関数 ([221])
•
CVP
11 関数 ([222])
•
ELA
14 関数 ([223])
•
LEA
14 関数 ([224])
•
OMI
32 関数 ([225])
•
SAM
6 関数 ([226])
•
UAA
22 関数 ([227])
•
UFP
16 関数 ([228])
d) ベースとなる技術
自社製品の FireWall-1、VPN-1 が基本となったネットワーク環境を想定。
また、Secure Virtual Network (SVN) という Check Point 全製品がベースとするアーキテクチャ ([229])。
他にアプリケーションと統合する方法である、Stateful Inspection Technology である。([215])
Stateful Inspection は INSPECT というハイレベルのプログラミング言語を用いた新しいアプリケーショ
ンをサポートする。この INSPECT はコンパイルおよびダウンロードされ、セキュリティ ポリシーに従っ
て実行される。
INSPECT 言語は、ロードすべき別のソフトウェアや全てのアプリケーション サービスのための別のプロ
キシを要求することなく、新しいアプリケーション、サービス、プロトコルを統合するためのスクリプト
である。
e) 利用対象アプリケーション
API は、完全なクライアント、サーバ コミュニケーション インフラを提供する、ベースとなるアーキテ
クチャの複雑さに落ち込むことなしに、CheckPoint 製品の FireWall-1、VPN-1、Meta IP との統合を可
能にする ([220])。
適用対象アプリケーション分野は b) で記述している。
f) アプリケーション開発の容易さ
[214] の "Pre-requisites for Using the SDK" に OPSEC SDK を利用するプログラマに対する要求事項が
書かれている。
OPSEC SDK は Check Point 製品、Check Point 技術、および C プログラミングを理解したソフトウェア
開発者の利用を想定している。また、OPSEC SDK やこれ以外のセキュリティ製品の実装経験や、TCP/IP、
LDAP、RADIUS のようなネットワークおよび通信プロトコルを用いた実装経験を持っていることが推奨
される。
g) ポータビリティ
下記プラットフォームの SDK が提供されており仕様が標準化されているため、対応プラットフォームのポ
ータビリティは保証される。
h) プラットフォーム
NG OPSEC SDK のプラットフォームは以下 ([220])。
•
Microsoft Windows NT 4.0 or higher、Visual C++ 4.0 or higher
•
Solaris 2.5 or greater、Sun Visual Workshop or GCC
•
Red Hat Linux 6.1、GCC version 2.95.1
100
i) 適用例
[230] に Check Point 製品、および、OPSEC Certified 製品の内、無料でダウンロードできるものがリス
トアップされている。
j) 推進団体または提案した会社
Check Point Software Technologies が仕様作成および SDK 開発を行っている ([214])。
また、OPSEC の推進のために、OPSEC Alliance というアライアンス プログラムを行っており、300 以
上のパートナーが加盟している ([231])。パートナーのリストは [232] に出ている。
代表的なパートナーには、 Microsoft、 IBM、Computer Associates International、Novell が含まれる
([215])。
k) 準拠する標準
OPSEC は Check Point が定めるデファクト スタンダードである ([215])。
サポートする標準プロトコル一覧が、[214]の表 2、"Supported Standard Protocols"にある。
そこから抜粋すると以下。
•
RADIUS
•
LDAP
•
CRL (X509 v.2 Certificate Revocation List)
•
PKCS#10
•
PKCS#12
•
PKCS#7
•
PKCS#11
•
Microsoft's Cryptographic API v2.0
l) 利用コスト
[220]から OPSEC SDK 4.1.2 のパッケージが無料で (ただし、ユーザ登録が必要)、ダウンロード可能。
API、標準プロトコル インタフェース定義、C ライブラリのセットにより、OPSEC 準拠製品を開発する
ことができる ([214])。なお、OPSEC Alliance への加入も無料である。
m) 関連文書の入手可否
[220]から以下のドキュメントが入手できる。(ただし、ユーザ登録が必要)。
•
SDK Documentation with Hotfix (SDK412Documentation.zip)
•
SAA Interface 4.1.2 PDF file (SAA.pdf)
•
OPSEC SDK Hotfix Release Notes (OPSEC_SDK_412_HF1_ReleaseNotes.pdf)
n) 他 API との関係
n.1) PKCS#11
PKCS#11 は VPN-1 が暗号情報を保持し暗号機能を実行する装置にアクセスするのを可能とする ([214])。
n.2) Microsoft's Cryptographic API v2.0
Microsoft CryptoAPI 2.0 は SR/SC に暗号 (cryptography) と証明書管理 (certificate management) の機
能を提供する ([214])。
o) 拡張性
サードパーティのアプリケーションが API により OPSEC フレームワークに結合 (plug into) される。そ
して、OPSEC フレームワークに統合されると、これらのアプリケーションのセキュリティ機能がセキュ
リティ ポリシー エディタを用いた中心点から構成、管理することができる ([219])。
101
3.2.12 CAPICOM (Microsoft)
1) API 名
CAPICOM
2) 概説
アプリケーションにデジタル署名 (digital signing) および暗号化 (cryptography) を用意に統合できる、
Microsoft Visual Basic, Visual Basic Script, ASP, C++ で利用可能なインタフェースで、Microsoft
CryptoAPI に対する COM インタフェースを提供する ActiveX である。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
(Application)
|
CAPICOM
|
CryptoAPI 2.0
|
CSP
Microsoft のサイトには明確に CAPICOM を図解する資料はないが、CryptoAPI の図を拡張し上記のよ
うに図解できる。
b) 提供するセキュリティの機能
データ署名 (signing data)、署名確証 (verifying signatures)、メッセージの封印 (enveloping messages)、
封印メッセージの復号化 (decrypting enveloped messages)、データ暗号化 (encryption of data)、データ
復号化 (decryption of data)、およで自他府証明書の確証 (checking the validity of digital certificates) の
ような基本的な暗号化タスクを実行する。
また、以下のような機能を提供する (資料[233])。
•
スマートカードやソフトウェア鍵によるデジタル署名されたデータ (Digitally sign data)
•
デジタル署名データの確証 (Verify digitally signed data)
•
証明書情報のグラフィカルな表示 (Graphically display certificate information)
•
サブジェクト名や失効日のような証明書属性を検査する (Inspect certificate properties such as
subject name or expiration date)
•
証明書ストアに対する証明書の追加削除 (Add and remove certificates from the certificate stores)
•
パスワードによるデータ暗号化と復号化 (Encrypt and decrypt data with a password)
•
公開鍵および証明書によるデータの暗号化と復号化 (Encrypt and decrypt data using public keys
and certificates)
暗号アルゴリズムとしては CryptoAPI と同じく下記をサポート。
•
RC2
•
RC4
•
DES
•
Triple DES
c) API 数
CAPICOM は Visual Basic から利用可能にするために、ライブラリとしてではなく、オブジェクト指向の
クラスとして提供されている。
102
全部で 19 クラスのオブジェクトが合計 46 プロパティ、31 メソッドを提供する。
(ただし、Collection クラスから継承されたプロパティを除く)。
このため、以下の説明では関数仕様でなくクラス仕様を説明する。また、クラス分類は以下の c-1) から
c-5) までの 5 分類で、各分類にそれぞれのクラスが分類されている ([234])。
c-1) Certificate Store Objects (5 クラス、計 12 プロパティ、16
プロパティ、 メソッド)
メソッド
certificate stores とその中に格納された証明書 (certificates) を処理するオブジェクト。
CAPICOM は Current User、Local Machine、Memory、Active Directory certificate stores の利用をサ
ポートする。
Object Description：
Description
•
Certificate (7 プロパティ、9 メソッド)
A single digital certificate.
•
Certificates (3 プロパティ、ただし、上位クラスの Collection クラスから継承したプロパティ)
Collection of Certificate objects.
•
CertificateStatus (2 プロパティ、1 メソッド)
Provides status information on a certificate.
•
Chain (2 プロパティ、1 メソッド)
Creates and checks a certificate validation chain based on a digital certificate.
•
Store (1 プロパティ、5 メソッド)
Provides the properties and methods to choose, manage, and use certificate stores and the
certificates in those stores.
c-2) Digital Signature Objects (3 クラス、計 4 プロパティ、4
プロパティ、 メソッド)
メソッド
exported to digitally sign data and to verify digital signatures.
Object Description
Description：
•
SignedData (2 プロパティ、4 メソッド)
Object used to sign data and to verify the signature on signed data.
•
Signer (2 プロパティ)
Information on a single data signer, including the signer's certificate.
•
Signers (3 プロパティ、ただし、上位クラスの Collection クラスから継承したプロパティ)
Collection of Signer objects.
c-3) Enveloped Data Objects (2 クラス、計 3 プロパティ、5
プロパティ、 メソッド)
メソッド
exported to create enveloped data messages for privacy and to decrypt data in enveloped messages.
Object Description：
Description
•
EnvelopedData (3 プロパティ、2 メソッド)
Objects used to create, send, and receive enveloped data. Enveloped data is encrypted so that only
the intended recipients can decrypt it.
•
Recipients (3 プロパティ、ただし、上位クラスの Collection クラスから継承したプロパティ、3 メソ
ッド)
Collection of the Certificate objects of the intended recipients of an enveloped message.
c-4) Data Encryption Objects (1 クラス、計 2 プロパティ、3
プロパティ、 メソッド)
メソッド
exported to encrypt arbitrary data for privacy and to decrypt encrypted data.
Object Description：
Description
•
EncryptedData (2 プロパティ、3 メソッド)
Objects used to encrypt data. Encrypted data in an EncryptedData object can be decrypted.
c-5) Auxiliary Objects (8 クラス、計 25 プロパティ、3
プロパティ、 メソッド)
メソッド
to change default behaviors of other objects and to manage certificates, certificate stores, and
messages.
103
Object Description：
Description
•
Algorithm (2 プロパティ)
Sets the algorithm and key length to be used in cryptographic operations.
•
Attribute (3 プロパティ、ただし、上位クラスの Collection クラスから継承したプロパティ、3 メソ
ッド)
Provides a single piece of added information about a signature, such as the time of signing.
Attributes Collection of Attribute objects.
•
BasicConstraints (5 プロパティ)
Provides read-only access to basic constraints on the uses of a certificate.
•
EKU (2 プロパティ)
Provides access to EKU properties of certificates.
•
EKUS (3 プロパティ、ただし、上位クラスの Collection クラスから継承したプロパティ)
Collection of EKU objects.
•
ExtendedKeyUsage (3 プロパティ)
Provides read-only access to the extended key usage properties of certificates.
•
KeyUsage (11 プロパティ)
Provides read-only access to key usage properties of certificates.
•
Settings (2 プロパティ)
Enables or disables dialog boxes to prompt for signer or sender identity if that identity is not
specified.
d) ベースとなる技術
ActiveX (COM オブジェクト) として実装され、オートメーションをサポートする COM クライアントと位
置付けられる。
e) 利用対象アプリケーション
Visual Basic Script, Active Server Pages, Microsoft Jscript で利用可能なため、これらで開発される Web
ベースのアプリケーション。
また、Visual Basic で開発される Windows 上の EUC アプリケーションも対象となる。
C++ で開発した場合、CryptoAPI と異なりクラスライブラリとして利用可能となると思われる。
f) アプリケーション開発の容易さ
Visual Basic, Visual Basic Script, Active Server Pages, Microsoft JScript, C++ など多くの言語で利用
可能である。これらの言語は、C++ に比べてアプリケーション寄りで開発が容易な言語であり、プログラ
マの数も多い。このため、CryptoAPI よりも利用者および利用場面が多くなると予想される。
g) ポータビリティ
後述 h) プラットフォームで述べた Windows 環境でのみ利用可能。
h) プラットフォーム
•
Microsoft Windows 95 以上で、Microsoft Internet Explorer version 5.0 以上
•
Microsoft Windows 98 以上で、Microsoft Internet Explorer version 5.0 以上
•
Microsoft Windows 98 SE
•
Microsoft Windows Millennium Edition
•
Microsoft Windows NT version 4.0 の Service Pack 4 以上
•
Microsoft Windows 2000
(資料[233]より引用。ただし、この記述は資料[235]とは異なる)。
104
i) 適用例
i-1) 実装された言語
Visual Basic, Visual Basic Script, Active Server Pages, Microsoft JScript, C++
j) 推進団体または提案した会社
Microsoft
k) 準拠する標準
CryptoAPI 2.0 と同じ。
l) 利用コスト
無料。
Platform SDK として無料でダウンロード可能である (資料[128]、[129])。
また、Platform SDK を納めた CD-ROM が送料で入手可能である。
m) 関連文書の入手可否
仕様書については、Microsoft のサイトにおいてページ[236]で参照可能 ([234])。また、ここには、"Using
CAPICOM" として CAPICOM を用いた多くのサンプルコードが提供されている。
n) 他 API との関係
n.1) CryptoAPI 2.0
上述したが、CAPICOM は CryptoAPI 2.0 上に COM クライアントとして開発されている。
o) 拡張性
拡張性
CAPICOM 独自の拡張性はないが、3.2.2 CryptoAPI 2.0 (Microsoft) で述べた拡張性がある。
3.3 暗号 API (Cryptographic API)
3.3.1 GCS-API (Open Group)
1) API 名
Generic Cryptographic Service API (GCS-API)
2) 概説
GCS-API は Microsoft CryptoAPI と同様な API であり、Open Group により定義された。
GCS-API には、アプリケーションを開発する者を対象としたセキュリティサービス仕様の基本部と、暗号
の知識を必要とするアプリケーションを開発するものを対象としたセキュリティサービス仕様の拡張部が
ある ([2])。
基本部が暗号化サービス (cryptographic service) を利用する汎用アプリケーションの要求を満たすため、
ほとんどのアプリケーション開発者は基本部の利用で十分である。
一方、拡張部はより詳細な概念およびデータ構造を表現し、関数の追加セットを提供しているため、暗号
105
化ポリシー (cryptographic policy) の管理や長期の鍵および暗号サービス自身を管理するアプリケーショ
ンでの利用を想定している ([237])。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
仕様書[238] より、
「GCS-API プログラミング モデル」を引用する。
GCS-API は、実装依存の多くの異なる暗号化アルゴリズム (Cryptographic Algorithm) をサポートする
Cryptographic Support Facility (CSF) に対するインタフェースの集合である。
また、個々のアプリケーションのための鍵管理 (Key Management) とアプリケーション間の共有鍵管理
(Shared Key Management) もサポートする。
GCS-API アルゴリズム独立は Cryptographic Context (CC) の概念を用いることにより達成されている
([238])。
CC は GCS-API 呼び出し側に透明な保護されたオブジェクトであり、実行さえる暗号化操作のコンテキス
トに関係する全ての情報をカプセル化する。CC はアルゴリズム識別子、アルゴリズム固有パラメータ、鍵
固有パラメータ、およびオプションとして鍵を含んでいる。
CSF は CC のデータベースを管理する。CSF サービスの図が
または
106
にあるが、以下のカテゴリに分類される ([238])。
•
汎用の暗号化サービス (General Cryptographic Services)
•
保護された鍵管理サービス (Protected Key Management Services)
•
クリアな鍵管理サービス (Clear Key Management Services)
•
暗号化サービスの初期化および構成サービス (Configuration Services)
CSF は次の 2 つのプログラミング インタフェースを提供する。
•
API (Application Program Interface)
API は次のコンポーネントから構成される。
- 汎用暗号化サービス (General Cryptographic Services)
データ暗号化、復号、チェックバリュー (シールまたは署名) の生成、確証を提供し、CSF 呼び出
し側や鍵管理サポート用の CSF 内部関数から呼び出される。
- 保護鍵管理サポートサービス (Protected Key Management Support Services)
呼び出し側が選択する暗号化ポリシー (Cryptographic Policy)、および、鍵生成 (Key generation)、
保管 (storage)、配布 (distribution)サービスを提供することにより、ユーザに強制する鍵利用ポリ
シー (Key Usage Policy) をサポートする。
•
SPI (System Program Interface)
SPI は次のコンポーネントから構成される。
- クリア鍵管理 (Clear Key Management)サービス
クリア鍵 (Clear Key) の生成 (generation)、保管 (storage)、配布 (distribution) サービスを提供
することにより、ユーザに強制させる 鍵保護ポリシー (Key Protection Policy) を提供する。
b) 提供するセキュリティの機能
暗号処理、完全性の確認、鍵管理 ([2])。
また、拡張部には上記に加え、暗号ポリシーの選択が可能となる。
基本部の機能 ([239])
General Application Cryptographic Services という用語で示される以下；
•
Data encipherment and decipherment
•
Integrity checkvalue generation and verification
107
•
Production of irreversible hash of data
•
Generation of random numbers
鍵管理 (Key management) アプリケーションはさらに以下の機能が必要；
•
Generation, derivation and deletion of keys
•
Export and import of keys
拡張部の機能 ([240])
General Application Cryptographic Services という用語で示される以下；
•
Integrity checkvalue generation and verification
•
Data encipherment and decipherment
•
Production of irreversible hash of data
•
Generation of random numbers
•
Inquiry of available keys and key related data
鍵管理(Key management)アプリケーションはさらに以下の機能が必要；
•
Generation, derivation and deletion of keys, including public parameters
•
Export and import of keys
•
Storage and retrieval of keys and associated information.
•
Archive and retrieval of keys and key related data
c) API 数
以下の 3 種類、51 関数 ([238]、[240])。
c.1) 基本部 (Basic) (23 関数)
関数
•
•
•
•
•
•
•
•
Session Management Functions (2)
gcs_initialise_session, gcs_terminate_session
Cryptographic Context Retrieval Functions (3)
gcs_delete_cc, gcs_list_cc, gcs_retrieve_cc
Key Creation Functions (2)
gcs_derive_key, gcs_generate_key
Hash and Signature Functions (4)
gcs_generate_checkvalue,
gcs_verify_checkvalue,
gcs_generate_random_number
Data Encipherment Functions (Encipher and Decipher Functions) (4)
gcs_encipher_data, gcs_decipher_data, gcs_protect_data, gcs_decipher_verify
Cryptographic Context Storage Functions (Keys Storage Functions) (2)
gcs_store_cc, gcs_remove_cc
Key Exchange Functions (3)
gcs_export_key, gcs_import_key, gcs_key_agreement
Utility Functions (3)
gcs_get_csf_param, gcs_release_buffer, gcs_release_bit_string
gcs_generate_hash,
c.2) 拡張部 (Advanced) (22 関数)
関数
•
•
•
•
•
Creation of CC (Cryptographic Context Creation Functions) (7)
gcs_create_ac, gcs_delete_ac, gcs_set_ac, gcs_create_kc, gcs_delete_kc, gcs_set_kc, gcs_create_cc
Cryptographic Context Modification Functions (4)
gcs_get_cc, get_retrieve_cc, gcs_set_cc, gcs_store_cc
Additional Key Management Functions (2)
gcs_combine_key, gcs_load_public_key
Key State Management Functions (5)
gcs_advance_key_state,
gcs_get_key_validity,
gcs_reduce_key_usage,
gcs_revoke_key,
gcs_set_key_validity
Supplementary CC Management Functions (4)
gcs_archive_cc, gcs_restore_cc, gcs_generate_key_pattern, gcs_verify_key_pattern
c.3) System Programming Interface (SPI) (6 関数)
関数
108
gcs_decipher_key,
gcs_encipher_key,
gcs_load_clear_key, gcs_split_clear_key
gcs_derive_clear_key,
gcs_generate_clear_key,
備考) 主に [238] を利用、括弧内の名称は [237] で使われているもの。
基本部と拡張部で gcs_retrieve_cc、gcs_store_cc が重複しているが、[238] の Chapter2、8 の記述に従っ
た。また、[2] では基本部 22 個、拡張部 26 個とされているが、最新の仕様書 [238] に従う。
d) ベースとなる技術
暗号化サービス (Cryptographic services) は以下の暗号化関数から構成される ([238])。
•
暗号化 (Encipher) および復号 (Decipher) 関数 (Functions)
•
共通鍵 (Symmetric-Key) および公開鍵 (Asymmetric-Key) 暗号 (Encipherment)
•
ハッシュ関数 (Hash Functions)
•
デジタル署名関数 (Digital Signature Functions)
•
鍵管理関数 (Key Management Functions)
e) 利用対象アプリケーション
E コマースなど暗号が必要なアプリケーション ([237])。
f) アプリケーション開発の容易さ
基本部は暗号アルゴリズムに詳しくない開発者の利用を想定しているため、基本部のみを利用する汎用の
アプリケーション開発が容易である ([237])。
し か も 、 対 象 ア プ リ ケ ー シ ョ ン は 暗 号 化 サ ー ビ ス (cryptographic services) 鍵 管 理 サ ー ビ ス (key
management services) にのみ依存することになる。
g) ポータビリティ
GCS-API の規定するインタフェースは、以下の 2 つによりポータブルなアプリケーション開発をサポート
する ([238])。
•
アルゴリズム独立 (Algorithm Independent)
API 利用側 (caller) から詳細、複雑さ、特定のアルゴリズムを隠蔽する。
例えば、API 利用側は暗号化関数 (encipher function) を呼び出す際に、どのアルゴリズムが使われて
いるか、とか、そのアルゴリズムに必要な特定のパラメータを意識する必要がない。しかし、GCS-API
は特定のアルゴリズムのセットを使うために必要な、アルゴリズム固有の関数呼び出し (algorithm
specific caller) もサポートしている。
•
実装独立 (Implementation Independent)
GCS-API は利用側から実装の詳細を隠蔽する。例えば、ソフトウェア、ハードウェア、あるいはその両
方で実装される。ゆえに、アプリケーションはハードウェア実装にアクセスするために物理装置にアク
セスする必要性を意識しないで済む。
h) プラットフォーム
仕様は C 言語を想定して書かれている。他の言語および特定のプラットフォームに関する情報は入手でき
なかった。
i) 適用例
NSA は 1996 年当時、GSS/IDUP、GCS-API、Microsoft CryptoAPI などセキュリティ関連 API の調査比
較を行っており、これらの仕様に基づくプロトタイプ実装を行っていた ([241])。
これ以外の具体的な製品、リファレンス実装などの情報は入手できていない。
109
j) 推進団体または提案した会社
推進団体または提案した会社
現 Open Group 統合前の X/Open における Security Working Group (SWG) が作成 ([242])。
1996 年当時に以下のキー パートナーがいた ([237])。
•
National Institute of Standards and Technology (NIST)
•
Trusted Information Systems, Inc
•
USA National Security Agency (NSA)
•
RSA Data Security, Inc
•
Fischer International
これらのパートナーの他に、Open Group コミュニティの BULL, Hewlett Packard, IBM, ICL, Olivetti,
OpenVision, Siemens Nixdorf といった企業が参加していた。
また、ICE (International Cryptography Experiment) や企業が GCS-API の実装を行っていた。
k) 準拠する標準
Open Group 統合前の X/Open が標準化として仕様策定し、Open Group により管理 ([243])。
ただし、1996 年 6 月に最終版の仕様書[238] が発行されて以降、更新されていない。
l) 利用コスト
仕様は標準化されているので利用は無料だが、リファレンス実装は見つからなかった。
GCS-API は CDSA へと発展しているので、これを利用する方が良いと思われる。
m) 関連文書の入手可否
現時点では Open Group のサイトから GCS-API の仕様書を入手することはできない。
[243] に書かれた 1996 年発行の書籍を購入するか、あるいは、書籍[108] に添付の CD-ROM に PDF 形式フ
ァイルが含まれているためこの書籍を購入する。
または、Open Group 統合前の過去 (1996 年当時) の情報として、[237] に GCS 関連の情報が
公開されている (Open Group のトップから辿れないため正式な公開ではないようだが)。
n) 他 API との関係
n.1) Microsoft CryptoAPI 1.0
[244] に GCS-API と Microsoft CryptoAPI 1.0 の比較が紹介されている。
o) 拡張性
単一の Cryptographic Support Facility (CSF) と呼ばれる仕様により、(実装依存の) 任意の数のアルゴリ
ズムをサポートできる ([244])。
アルゴリズムとオペレーションのモード (modes of operation) はテンプレート暗号化コンテキスト
(template cryptographic contexts) のセットの定義によりコントロールされる。テンプレート暗号化コン
テキストのセットが実装により前もって定義されるか、または、組織がそれ自身のテンプレート暗号化コ
ンテキストのセットを定義することによって実装が関数のセットをサポートするか、のどちらかが必要が
ある。
110
3.3.2 PKCS#11 (RSA)
1) API 名
PKCS #11: Cryptographic Token Interface Standard
2) 概説
暗号アプリケーションプログラムインタフェース Cryptoki。
PKCS (Public-Key Cryptography Standards) は、Apple や Microsoft、DEC、Lotus、Sun、MIT 等と
の非公式コンソーシアムによる協同作業の結果として RSA Laboratories が纏めた、公開鍵暗号に関係す
る各種規格のセットである。PKCS は、PEM (Privacy Enhanced Mail) や ITU-T X.509 等の他規格とも
互換性があり、OSI 規格実現の方法として、 NIST/OSI Implementors' Workshop (OIW) の協賛を得てい
る。また、PKCS には特定のアルゴリズムにディペンドした規格とアルゴリズムからは独立した規格とが
あり、後者を利用すれば、どのようなアルゴリズムを用いた場合でも規格に準拠することができ、相互運
用性を保持できる ([245])。
各規格の概要を以下に示す。
•
PKCS #1:
#1 RSA Encryption Standard
RSA 暗号を使った暗号化方法および署名方法。
•
PKCS #3:
#3 Diffie-Hellman Key-Agreement Standard
Diffie-Hellman 方式による鍵交換プロトコル。
•
PKCS #5:
#5 Password-Based Encryption Standard
password から生成した秘密鍵を使った暗号化方法。
•
PKCS #6:
#6 Extended-Certificate Syntax Standard
X.509 公開鍵証明書の拡張フォーマットの構文。
•
PKCS #7:
#7 Cryptographic Message Syntax Standard
暗号化や署名を施したデータの構文。
•
PKCS #8:
#8 Private-Key Information Syntax Standard
公開鍵暗号における秘密鍵関連情報の構文。
•
PKCS #9:
#9 Selected Attribute Types
PKCS #6, #7, #8, #10 で使用する Attribute Type。
•
PKCS #10:
#10 Certification Request Syntax Standard
CA(Certificate Authority)に対する証明書発行要求メッセージの構文。
•
PKCS #11:
#11 Cryptographic Token Interface Standard
暗号アプリケーションプログラムインタフェース Cryptoki。
•
PKCS #12:
#12 Personal Information Exchange Syntax Standard
保存や送信のための個人情報 (秘密鍵、公開鍵証明書等) のフォーマット。
PKCS は、RSA 暗号というデファクトスタンダードな公開鍵暗号を所有する RSA Data Security Inc. が
定めた規格のため、標準化が進められる以前から広く利用されており、PKCS 自体の標準化よりも他の標
準の中で PKCS が参照されることが多かった。
実際の標準化活動については、現在、IETF において PKCS #1, #7, #10 の標準化が検討されている。
PKCS#11 は暗号情報や暗号関数を持つデバイスのための API として RSA により定義された。この仕様に
は鍵管理、暗号処理、デジタル署名、一般処理用に 58 個の API が用意されている。PKCS#11 は他の暗号
API に比べて、より暗号アルゴリズムに近い API である ([2])。
この標準は、暗号化情報を保持し暗号化機能を実行する装置に対して、 Cryptoki と呼ばれる API を定義
する。Cryptoki はクリプトキー (crypto-key) と発音し、 cryptographic token interface を略したもので
あるが、単純なオブジェクト指向アプローチに従い、(任意のデバイスの) テクノロジー独立、リソース共
有 (複数デバイスにアクセスする複数アプリケーション) の目標を目指し、アプリケーションに対して暗号
化トークン (cryptographic token) と呼ばれる装置の論理的な共通のビューを与える ([246])。
111
3) 歴史
PKCS (Public-Key Cryptography Standards) は世界中のセキュア システム開発者の協力の下で、公開鍵
暗号の普及を加速する目的で RSA Laboratories が作成した仕様である。初版が 1991 年、公開鍵技術の
初期の採用社からの小さなグループ ミーテインィグの結果として公開され、PKCS 文書は広く参照され
実装されてきている。PKCS シリーズによる貢献が、ANSI X9 文書、PKIX、SET、S/MIME、SSL のよ
うな多くの正式なデファクト スタンダードの一部となっている ([247])。
Cryptoki の歴史 ([248])。
•
1994 年 1 月にアナウンス
•
1994 年 5 月 19-20 日のワークショップで発表
•
1995 年 4 月 28 日に v1.0 がリリース
•
1996 年 7 月 9-10 日のワークショップで上記を発表
•
v1.1 ファイナル仕様書を作成中 (96 年当時)
また[248] には、v1.0 から v1.1 仕様におけるメカニズムの違いや v2.0 で追加予定の機能などについて解説
されている。
a) ライブラリ構成、アーキテクチャ/フレーム
ライブラリ構成、アーキテクチャ フレームワーク構成
フレームワーク構成
仕様書[249] に書かれた General Cryptoki Model の図が次の図。
Cryptoki はスロット (slot) を通して 1 つ以上の暗号装置 (cryptographic device) に対するインタフェー
スを提供する。暗号装置が読取装置 (reader) に現れた時に、トークン (token) がスロット (slot) に現れ
る、とみなされる。
b) 提供するセキュリティの機能
鍵管理、暗号処理、デジタル署名 ([2])。
以下、[249]より引用。
b.1) 証明書 (CERTIFICATE)
X.509 public key certificate、X.509 attribute certificate
112
b.2) 公開鍵 (PUBLIC KEY)
RSA、DSA、ECDSA、Diffie-Hellman、X9.42 Diffie-Hellman、KEA
b.3) 私有鍵 (PRIVATE KEY)
RSA、DSA、Elliptic curve、Diffie-Hellman、X9.42 Diffie-Hellman、KEA
b.4) 秘密鍵 (SECRET KEY)
RC2、RC4、RC5、AES、DES、DES2、DES3、CAST、CAST3、CAST128 (CAST5)、IDEA、CDMF、
SKIPJACK、BATON、JUNIPER
b.5) ドメイン パラメタ (DOMAIN PARAMETER)
DSA、Diffie-Hellman、X9.42 Diffie-Hellman
c) API 数
以下の 13 種類、68 関数 ([249])。
•
general-purpose functions (4 関数)
•
slot and token management functions (9 関数)
•
session management functions (8 関数)
•
object management functions (9 関数)
•
encryption functions (4 関数)
•
decryption functions (4 関数)
•
message digesting functions (5 関数)
•
signing and MACing functions (6 関数)
•
functions for verifying signatures and MACs (6 関数)
•
dual-purpose cryptographic functions (4 関数)
•
key management functions (5 関数)
•
random number generation functions (2 関数)
•
parallel function management functions (2 関数)
API の概説は仕様書[249] の表 8 にある。
Table 8, Summary of Cryptoki Functions
Category
General
purpose
functions
Function
C_Initialize
C_Finalize
C_GetInfo
C_GetFunctionList
Slot and token
management
functions
C_GetSlotList
C_GetSlotInfo
C_GetTokenInfo
C_WaitForSlotEvent
C_GetMechanismList
C_GetMechanismInfo
Session
management
C_InitToken
C_InitPIN
C_SetPIN
C_OpenSession
Description
initializes Cryptoki
clean up miscellaneous Cryptoki-associated
resources
obtains general information about Cryptoki
obtains entry points of Cryptoki library
functions
obtains a list of slots in the system
obtains information about a particular slot
obtains information about a particular token
waits for a slot event (token insertion,
removal, etc.) to occur
obtains a list of mechanisms supported by a
token
obtains information about a particular
mechanism
initializes a token
initializes the normal user’s PIN
modifies the PIN of the current user
opens a connection between an application
and a particular token or sets up an
113
functions
C_VerifyInit
application callback for token insertion
closes a session
closes all sessions with a token
obtains information about the session
obtains the cryptographic operations state of
a session
sets the cryptographic operations state of a
session
logs into a token
logs out from a token
creates an object
creates a copy of an object
destroys an object
obtains the size of an object in bytes
obtains an attribute value of an object
modifies an attribute value of an object
initializes an object search operation
continues an object search operation
finishes an object search operation
initializes an encryption operation
encrypts single-part data
continues a multiple-part encryption
operation
finishes a multiple-part encryption operation
initializes a decryption operation
decrypts single-part encrypted data
continues a multiple-part decryption
operation
finishes a multiple-part decryption operation
initializes a message-digesting operation
digests single-part data
continues a multiple-part digesting operation
digests a key
finishes a multiple-part digesting operation
initializes a signature operation
signs single-part data
continues a multiple-part signature
operation
finishes a multiple-part signature operation
initializes a signature operation, where the
data can be recovered from the signature
signs single-part data, where the data can be
recovered from the signature
initializes a verification operation
C_Verify
C_VerifyUpdate
verifies a signature on single-part data
continues a multiple-part verification
C_CloseSession
C_CloseAllSessions
C_GetSessionInfo
C_GetOperationState
C_SetOperationState
Object
management
functions
Encryption
functions
Decryption
functions
Message
digesting
functions
Signing
and MACing
functions
C_Login
C_Logout
C_CreateObject
C_CopyObject
C_DestroyObject
C_GetObjectSize
C_GetAttributeValue
C_SetAttributeValue
C_FindObjectsInit
C_FindObjects
C_FindObjectsFinal
C_EncryptInit
C_Encrypt
C_EncryptUpdate
C_EncryptFinal
C_DecryptInit
C_Decrypt
C_DecryptUpdate
C_DecryptFinal
C_DigestInit
C_Digest
C_DigestUpdate
C_DigestKey
C_DigestFinal
C_SignInit
C_Sign
C_SignUpdate
C_SignFinal
C_SignRecoverInit
C_SignRecover
Functions for
verifying
signatures
and MACs
114
C_VerifyFinal
C_VerifyRecoverInit
C_VerifyRecover
Dual-purpose
cryptographic
functions
C_DigestEncryptUpdate
C_DecryptDigestUpdate
C_SignEncryptUpdate
C_DecryptVerifyUpdate
Key
management
functions
Random
number
generation
functions
Parallel
function
management
functions
C_GenerateKey
C_GenerateKeyPair
C_WrapKey
C_UnwrapKey
C_DeriveKey
C_SeedRandom
operation
finishes a multiple-part verification
operation
initializes a verification operation where the
data is recovered from the signature
verifies a signature on single-part data,
where the data is recovered from the
signature
continues simultaneous multiple-part
digesting and encryption operations
continues simultaneous multiple-part
decryption and digesting operations
continues simultaneous multiple-part
signature and encryption operations
continues simultaneous multiple-part
decryption and verification operations
generates a secret key
generates a public-key/private-key pair
wraps (encrypts) a key
unwraps (decrypts) a key
derives a key from a base key
mixes in additional seed material to the
random number generator
C_GenerateRandom
C_GetFunctionStatus
generates random data
legacy function which always returns
CKR_FUNCTION_NOT_PARALLEL
C_CancelFunction
legacy function which always returns
CKR_FUNCTION_NOT_PARALLEL
application-supplied function to process
notifications from Cryptoki
Callback
function
d) ベースとなる技術
Cryptoki はアプリケーションに直接リンクされるか、または、共有ライブラリ、別名、ダイナミックリン
ク ライブラリとして動的にリンクされる ([249])。
e) 利用対象アプリケーション
PKCS#11 は任意のアプリケーショが、暗号化、複合化、署名 (signing)、確証 (verifying) などの暗号化
操作を実行するシステムと通信するためのインタフェースを定義する。トークンと呼ばれるこれらのシス
テムは (適切な読み取り装置と一緒に使う) スマートカード、別個のハードウェア システムや純粋なソフ
トウェア実装を指す ([250])。
f) アプリケーション開発の容易さ
ANSI C 言語で開発を行う ([249])。
Cryptoki は非常に低レベルの API であるため、利用する暗号アルゴリズムに関しての知識が必要となる。
また、暗号化のみをサポートする API であり、対象領域が限定される。
115
g) ポータビリティ
UNIX 版の PKCS#11 実装である gpkcs11 ([250]) は GNU のポータビリティに従いポーティングが容易と
思われるが、Windows と UNIX 間のポータビリティについては定かではない。仕様書[249] には Win32、
Win16、UNIX における Cryptoki のヘッダに関する情報が掲載されているのみ。
h) プラットフォーム
PKCS#11 自身はプラットフォームを規定しない。
TrustCenter が開発しているリファレンス実装の最新版は、Solaris 2.5.1/SPARC、Linux 2.0.36/i386 で
動作確認され、他の UNIX プラットフォームでも動作すると思われる ([250])。
また、最新版は Windows2000/NT にも対応しており、 Win16、 Win32 でコンパイルすることができる
([251])。
i) 適用例
[252] のページには、以下のような PKCS#11 対応製品がリストアップされている。
•
PKCS#11 Smartcards
Crypto Safe (Bull)、The Rosetta Smart Card (SPYRUS)、PKCS#11 Smart Card (Netscape)など。
•
PKCS#11 USB Tokens
Cylink MiniKey (Algorithmic Research)、iKey 2000 (Rainbow Technologies)、Rosetta USB (SPYRUS)
など。
•
PKCS#11 Soft token
Mozilla Open Source pkcs#11-implementation Netscape's Soft token
•
PKCS#11 PCMCIA Cards
Chrysalis-ITS Luna2、Chrysalis-ITS LunaCA3
•
PKCS#11 PCI-boards
CryptoSwift PCI (Rainbow Technologies)など
•
PKCS#11 Ethernet-devices
CryptoSwift EN (Rainbow Technologies)
•
PKCS#11 SCSI-devices
nCipher products
•
その他の PKCS#11 tokens/devices
PKCS 11 Implementation for the Java(tm)-Powered iButton(tm) 、CeloCom's Smart Card Reader
i.1) TrustCenter によるリファレンス実装 - GPKCS11
TrustCenter ([253]) が開発中の PKCS #11 リファレンス実装が GNU General Public License (GPL) とし
て公開されている ([250])。
i.2) RSA Security Inc.
BSAFE および TIPEM ツールキット。また、Lotus Notes, Apple's System 7 Pro, Novell NetWare のよ
うな RSA-enabled アプリケーションも ([254])。
i.3) IBM, PKCS#11 拡張
IBM's Global Smart Card Solution Division は 、 IBM SignCard の よ う な 暗 号 化 コ プ ロ セ ッ サ
(cryptographic coprocessors) を持つ ISO 7816 コンパチブルのスマートカードをベースにした Digital
Signature Solution を提供している。
この開発にあたり必要となった PKCS#11 Version 2.01 標準に対する拡張を提案している ([255])。
i.4) ICE
ICE では暗号 API (CAPI) を用いたデモ開発をしながら CAPI やこれをベースにしたアーキテクチャの検
討などを行っている。そこにおいて Cryptoki を用いたセキュアなメーラのデモ開発が行われた ([256])。
i.5) Netscape、
、Netscape Security Library
Netscape Security Library は PKCS #11 version 2.0 を実装している。
Communicator の Version 4.05 は PKCS #11 2.01 をサポートする予定だが、スレッド ロッキング
(thread locking) をサポートしない。
116
とういのも、Communicator は PKCS #11 に関しシングル スレッドで実行するからである。
Netscape Servers の Version 4.0 は PKCS #11 version 2.01 に準拠する予定である。
例えば、 C_Initialize 関数は CK_INITIALIZE_ARGS structure を受け取る。
仕様におけるこの変更は、元々、Netscape Servers で使う PKCS #11 モジュールにおいてスレッドの安全
性をサポートするために Netscape から要求されたものであった ([257])。
なお、Netscape Security Library およびこれに関する詳細は[258]を参照。
i.5) cryptlib
cryptlib というセキュリティ ツールキットは、PKCS #11 対応の装置をサポートしている ([259])。
i.6) IBM, PKCS11 API for Java
RSA Data Security, Inc. からリリースされている PKCS11 API for C (Cryptoki) を Java にマップした
もの ([260])。
これは、本格的なオブジェクト指向 API ではないが、Cryptoki に慣れたプログラマであれば理解できるで
あろう、と書かれている。
•
プラットフォームは以下。
AIX, Windows NT, Windows 95, Windows 98, Linux, Solaris Sparc, Win XP
•
以下は詳細の原文を訳したものである。
C 言語用の PKCS11 API 標準は、暗号情報を保持し暗号化機能を実行する装置のための Cryptoki と
呼ばれる API を規定する。Cryptoki (crypto-key と発音し、cryptographic token interface を略したも
の) は単純なオブジェクト ベースのアプローチに従って、(任意の種類の装置における) 技術独立と (複
数装置にアクセスする複数アプリケーションにおける) リソース共有の目標を達成し、アプリケーショ
ンに対し 暗号化トークン (cryptographic token) と呼ばれる装置の共通で論理的なビューを提供する。
Java 言語用の PKCS11 API は (com.ibm.pkcs11 パッケージという) 抽象 Java クラスのセットとし
て表現され、インタフェースを定義するがそれ自身では機能を提供しない。パッケージ
com.ibm.pkcs11.nat は抽象クラスの実装を提供し、Java API をネイティブの PKCS11 ライブラリの
関数に対してマップする。 (一つの DLL により) PKCS11 をサポートする暗号化トークン (crypto
token) は Java からアクセスするためにこのパッケージと一緒に使用される。
j) 推進団体または提案した会社
RSA Security Inc. が中心となって活動しているが、Apple や Microsoft、DEC、Lotus、Sun、MIT 等と
の非公式コンソーシアムによる協同作業の結果として RSA Laboratories が仕様をまとめた。
k) 準拠する標準
RSA Data Security Inc. が策定したデファクトスタンダードであり、現在、IETF において PKCS #1, #7,
#10 の標準化が検討されている。
また、Cryptoki は汎用の暗号 API を目標としておらず、GSS-API や GCS-API を補足する位置付けとな
る ([249])。
l) 利用コスト
前述のように、TrustCenter ([253]) の PKCS #11 リファレンス実装である GPKCS1 1 は、GNU General
Public License (GPL) として公開されており、利用は無料 ([250])。
m) 関連文書の入手可否
最新版 V2.11 の仕様書が RSA Laboratories の PKCS#11 サイト[246] から無料でダウンロードできる
([249])。
n) 他 API との関係
n.1) CDSA (CSSM)
[261] では PKCS #11 を CDSA に適用するために、PKCS #11 のサービス プロバイダについて説明されて
いる。
また、[262] では Generic Cryptoki Adaptation Layer (GENCAL) という CDSA で Cryptoki (PKCS #11)
117
を利用可能とするインタフェースで、この資料作成時に PKCS #11 v1.0 の機構を全てエクスポートし、
GPK2000 SmartCard 用の RSA w/MD5 (Gemplus) と Luna PCMCIA 用の CAST および CAST3
(Chrysalis-ITS) の暗号をサポートする。また、その時点で 5 つのベンダーがサポートする 7 つのトーク
ンに対応している。
他に[23]では、NSA が CDSA と Cryptoki の比較を行い、CDSA フレームワークで Cryptoki を利用可
能にするための Cryptoki adaptation layer を説明している。これは、1998 年に Intel がこれのデモを行
っており、Cryptoki ライブラリが Cryptoki adaptation layer により CSSM SPI にマッピングされ、CSP
として CDSA モデルに適合することを証明した。
n.2) Microsoft CryptoAPI 1.0
[256]では ICE における WindowsNT および 95 上の Secure E-mail CAPI デモについて説明しており、こ
のデモは Microsoft CryptoAPI 1.0 を用いて開発されている。このとき、RSA Cryptoki を用いて開発さ
れた
•
TIS Crypto SmartDisk CSP
•
TIS Fortezza CSP
•
TIS RecoverKey CSP
の CSP と Microsoft CryptoAPI 1.0 を繋ぐ、
汎用の CryptoAPI-to-Cryptoki translator を開発している。
n.3) FORTEZZA CIPG, Rev. 1.52
[249] では次の標準を元に FORTEZZA CIPG, Rev. 1.52 と PKCS#11 との比較を行っている。
•
ANSI N13-94 - Guideline X9.TG-12-199X, Using Tessera in Financial Systems: An Application
Programming Interface, April 29, 1994
仕様書 FORTEZZA CIPG, Rev. 1.52 は FORTEZZA PCMCIA Crypto Card に対する API を定義してお
り、Cryptoki と同じレベルを提供している。仕様書[249]には関数レベルの比較表が掲載されている。
n.4) GCS-API
[249] では次の標準を元に GCS-API と PKCS#11 との比較を行っている。
•
X/Open GCS-API - Generic Cryptographic Service API, Draft 2, February 14, 1995
GCS-API は Cryptoki よりも上位のセキュリティ サービスに対する API を定義しており、GCS-API の
それぞれの関数に対して Cryptoki の複数の関数を対応させた対応表が [249] に掲載されている。また、
空欄があり、GCS-API のフルサポートが Cryptoki の今後のバージョンアップに残されていることが但し
書きしてある。
o) 拡張性
PKCS#11 自身に関しての拡張性に関する情報は入手できなかった。
3.3.3 JCA (Sun)
1) API 名
Java Cryptography Architecture (JCA)
2) 概説
Java 暗号化アーキテクチャ (JCA) は基本的な暗号化機能を Java プラットフォームで実行するためのイ
ンフラストラクチャを提供する ([43])。暗号化機能の目的には暗号化のための基本的な関数とアルゴリズム
を用いてデータの破壊を防ぎ、データの完全性を保つことなどがある。
JCA にはデータやコードの送信元の識別に使用される、暗号化の署名生成アルゴリズムも組み込まれてい
る。
鍵と証明書もまた、送信元の識別に欠かせない存在であることから、これらの機能を扱う API も JCA の
中に組み込まれている。
JCA は、コア Java 2 セキュリティ アーキテクチャ機能として Java に組み込まれる、セキュリティパッ
ケージの一部だが、JCA 独自のサービスプロバイダ インタフェースの上位に位置することから、その他
のコア API から区別される。つまり、JCA のフレームワークに JCA 以外の暗号化が組み込まれて実装さ
118
れたとしても、Java のアプリケーションは同じ JCA インタフェースに準拠することができる。ただし、
Sun はデフォルトの暗号化機能のセットを JCA に備えている。
3) 歴史
JDK 1.1 における JDK Security の最初のリリースで Java Cryptography Architecture (JCA) が導入
された。
JCA は Java プラットフォームで暗号機能にアクセスし、かつ、開発するためのフレームワークを参照す
る ([263])。
JDK 1.1 における JCA はデジタル署名とメッセージ ダイジェストのための API を含んでいた。
Java 2 SDK は JCA を大幅に拡張し、X.509 v3 certificates をサポートするための証明書管理インフラ
(certificate management infrastructure) へとアップグレードしている。
JCA は暗号に関連する Java 2 SDK Security API の一部を含んでいる。また、複数、かつ、相互運用可
能な暗号実装を可能とする Provider アーキテクチャもまた含んでいる。
JCE は JCA を拡張し、暗号化、鍵交換、MAC のための API を含んでいる。JCE と SDK の暗号機能によ
り完全でプラットフォーム独立の暗号 API を提供している。
5) パッケージ
•
•
•
java.security package
java.security.spec package
java.security.interfaces
a) ライブラリ構成、アーキテクチャ
ライブラリ構成、アーキテクチャ/フレームワーク構成
クチャ フレームワーク構成
Java Security Architecture において、パッケージ間の関係を示す構成は以下のようになる (文献[43])。
アプリケーション
|
JCE
|
|
コア Java JCA
次の図は様々な JCA モジュールを図示したものである ([264])。
SPI (service provider interface) レイヤーは、CSP (Cryptographic service provider) によって実装される
メソッドを表現するものであり、特定の暗号アルゴリズムを実装する CSP は SPI をインタフェースとして
開発される。
119
JCA は次の 2 つを包含している ([47])。
•
JDK 1.2 Security Cryptography
•
JCE 1.2
b) 提供するセキュリティの機能
•
•
•
•
•
•
•
Digital signaturing
Message digesting
Key generation
Keystore creation and managing
Algorithm parameter generation and managing
Certificate generation and verification
Random number generation
c) API 数
以下の 19 クラス、176 メソッド ([263])。
•
Core Classes and Interfaces
Provider Class (13 メソッド)
Security Class (10 メソッド)
MessageDigest Class (16 メソッド)
Signature Class (20 メソッド)
- Algorithm Parameters Classes
・ Algorithm Parameter Specification Interfaces and Classes
AlgorithmParameterSpec Interface
DSAParameterSpec Class
AlgorithmParameters Class (12 メソッド)
AlgorithmParameterGenerator Class (10 メソッド)
Key Interfaces
- Key Specification Interfaces and Classes
・ KeySpec Interface
DSAPrivateKeySpec Class (5 メソッド)
DSAPublicKeySpec Class (5 メソッド)
RSAPrivateKeySpec Class (3 メソッド)
RSAPrivateCrtKeySpec Class (7 メソッド)
RSAPublicKeySpec Class (3 メソッド)
EncodedKeySpec Class
PKCS8EncodedKeySpec Class (3 メソッド)
X509EncodedKeySpec Class (3 メソッド)
KeyFactory Class (9 メソッド)
CertificateFactory Class (9 メソッド)
KeyPair Class (3 メソッド)
KeyPairGenerator Class (11 メソッド)
Key Management
KeyStore Class (22 メソッド)
SecureRandom Class (12 メソッド)
備考) v1.4 の API 数については省略。
d) ベースとなる技術
JCA はデフォルトでデジタル署名用パッケージ (NIST FIPS 186) とメッセージダイジェスト用パッケー
ジ (MD5:RFC1321 と SHA-1:NIST FIPS 180-1) が実装されている。
また、Sun という名前のデフォルトプロバイダは以下を含む ([263])；
•
NIST FIPS 186 で規定される Digital Signature Algorithm (DSA) の実装
120
•
•
•
•
•
•
•
•
MD5 (RFC 1321) および SHA-1 (NIST FIPS 180-1) メッセージ ダイジェスト アルゴリズム
DSA アルゴリズムに適する公開鍵と私有鍵のペアを生成するための DSA 鍵ペア ジェネレータ (key
pair generator)
DSA アルゴリズム パラメータ ジェネレータ (parameter generator)
DSA アルゴリズム パラメータ マネージャ(parameter manager)
(opaque) DSA 私有鍵と公開鍵のオブジェクト間の双方向変換と、基礎となるキー マテリアル (key
material) を提供する DSA "key factory"
IEEE P1363 標 準 に お け る 推 奨 に 従 っ た 、 "SHA1PRNG" 疑 似 乱 数 生 成 ア ル ゴ リ ズ ム
(pseudo-random number generation algorithm) のメーカー独自の実装。
X.509 証明書 (X.509 certificates) と CRL (Certificate Revocation Lists) のための "certificate
factory”
“JKS” という名のメーカー独自の keystore type のための keystore 実装。
e) 利用対象アプリケーション
暗号機能を利用するアプリケーション。
f) アプリケーション開発の容易さ
JCA の設計原理は以下 ([263])。
•
実装独立と相互運用可能
•
アルゴリズム独立と拡張性
これによりユーザは特定の実装やアルゴリズムに注意を払うことなく、デジタル署名やメッセージ ダイジ
ェストといった暗号の概念を利用してプログラミングすることができる。
ただし、完全なアルゴリズム独立が不可能な場合は、JCA は標準化されたアルゴリズム固有の API を提
供し、また、実装独立が望ましくない場合は、それらが必要とする特定の実装を指定することを許す。
g) ポータビリティ
JCA は以下の 2 つの基本方針で設計されている ([47])；
•
アルゴリズム独立と拡張性
KeyFactory および Signature のようなサービス クラスによる
•
実装独立と相互運用性
プロバイダ ベースのアーキテクチャによる
上記の独立によりポータビリティ(と相互運用性)を達成している。
また、下記プラットフォームで述べた実行環境であれば特定の OS に依存しない。
h) プラットフォーム
JDK1.1 以上で追加された。JCA は J2SDK の一部である。
i) 適用例
3.2.7 JCE (Sun) で述べた RSA Security、Forge Research。
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
上記ベースとなる技術で述べた以下の標準。ただし、これらはプロバイダが実装している。
•
セキュア ハッシュ標準、 NIST FIPS 180-1
•
RFC 1319 で定義された MD2 メッセージ ダイジェスト アルゴリズム
•
RFC 1321 で定義された MD5 メッセージ ダイジェスト アルゴリズム
121
•
•
•
•
•
PKCS#1 で定義された RSA 暗号化アルゴリズム
FIPS PUB 186 で定義されたデジタル署名アルゴリズム (Digital Signature Algorithm)
IEEE P1363 準拠の疑似乱数生成 (PRNG: pseudo-random number generation) アルゴリズム
X.509 で定義された証明書タイプ (Certificate type)
PKCS#12 で定義された個人識別情報のための変換シンタックス (Transfer syntax for personal
identity information)
l) 利用コスト
J2SDK v1.3 の中に含まれるため、J2SDK v1.3 を入手すれば良い ([50])。
J2SDK v1.4 は、[189] から J2SDK v1.4 一式を入手すれば良い。
暗号プロバイダおよびツールキット企業に完全にオープン ([265]) であるため、利用が無料であるし、更に
自社製品を JCA で利用可能にするためのプロバイダも開発可能である ([266])。
m) 関連文書の入手可否
J2SDK v1.3 対応である JCA の仕様書が [263] でアクセスできる。また、J2SDK v1.4 対応の JCA の仕様
書は [267] でアクセスできる。
n) 他 API との関係
JCE との関係が 3.2.7 JCE (Sun) に記述。
o) 拡張性
JCA により導入された Cryptographic Service Provider は、実際の暗号機能を提供するコンポーネントで
あり、Sun またはベンダーから提供されるプロバイダを切り替えることが可能 ([263])。
3.4 認可 API (Authorization API)
3.4.1 GAA-API (IETF)
1) API 名
GAA-API (Generic Authorization and Access Control API)
2) 概説
GAA-API は分散環境でのアプリケーションに対する Authorization decision をサポートする。
アプリケーションは、要求されたオペレーションまたはオペレーション セットが認可されたかどうか、あ
るいは、付加的なチェックが必要かどうか、決定するために GAA-API の関数を呼び出す。GAA-API はま
た、特定のリソースについてのアクセス管理情報を要求するのに使われる。
オブジェクトまたはリソースに対するプリンシパル (principal) のアクセス権を得るのに使え、ほとんど
の ア プ リ ケ ー シ ョ ン の ニ ー ズ を サ ポ ー ト す る 。 開 発 者 は 独 自 の 認 可 メ カ ニ ズ ム (authorization
mechanism) を設計する必要はない ([268])。
①
②
認可ポリシーを表現する標準手順
GSS-API のような認証プロセスから来るセキュリティそのようなポリシーをチェックする標準 API
122
3) 特徴
•
•
EACL (Extended Access Control Lists) ＋ API
API は非常にシンプル
get policy, evaluate policy, get info
•
EACL
- オブジェクト指向
- その方法はコールバックの呼び出し形式で partial validation
- セマンティックスが不明確
- リストへの追加シークエンス
([269])
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
GAA-API の全モジュールのリストは以下 ([270])。
•
gaa
•
internal gaa routines
•
gaacoer routines
•
gaa plugin implementation
また、GAA-API ライブラリは以下の 6 個のライブラリから構成される ([270])。
libgaa_core.so
libgaa_plugin.so
libgaa_simple.so
libgaa_pthread.so
libgaa_util.so
libgaa_supp.so
b) 提供するセキュリティの機能
GAA-API はアクセス管理サービスを提供する ([270])。
アプリケーションがターゲットと成るリソースに関連するアクセス管理ポリシーをベースにしたアクセス
管理を決定することを可能とする。
また、以下を提供する：
•
公開鍵暗号 (public key cryptosystems) および秘密鍵暗号 (secret key cryptosystems) をベースに
した様々なセキュリティ メカニズム
•
異なる認可モデル (authorization model)
•
異種環境 (heterogeneous) のセキュリティ ポリシー
•
様々なアクセス権
c) API 数
以下の 4 モジュール、114 関数 ([270])。
•
gaa (70 関数)
•
internal gaa routines (14 関数)
•
gaacoer routines (7 関数)
•
gaa plugin implementation (23 関数)
d) ベースとなる技術
EACL (Extended Access Control Lists) と呼ばれる単純なポリシー言語をサポートするために一つのモ
ジュールが提供される。ここで、EACL はユーザレベルの認可ポリシーを記述するために設計されている。
認可権 (authorized rights) 上の制限を規定するために、それぞれの ACL エントリー (entry) に対してオ
プションのフィールドを持つように従来の ACL が拡張されている。GAA-API は EACL が評価される汎
用の実行環境を提供する。 EACL は GAA-API によってサポートされるポリシー言語の選択肢の一つで
ある。GAA-API の基礎となるアーキテクチャは異なるポリシー言語が一つの実行環境で共存することを許
123
す ([271])。
GAA コンポーネント ([272])。
•
ポリシー言語 (Policy Language)
- トークン (token) ベース
- EACL と能力 (capability) のために利用
•
Functional API
- 3 つの main calls
•
セキュリティ コンテキスト (Security Context)
- ユーザ ID と証明書 (Credentials) を含む
- アプリケーション固有の検索 (retrieval) と評価 (evaluation) 関数
ポリシー言語 (Policy Language)
•
トークンの順序付リスト
- トークン型
- 定義オーソリティ (defining authority)
- 値 (value)
•
EACL (Extended ACL)
- ACL の概念を拡張し、条件付き認可ポリシー (conditional authorization policy) の仕様を許す
e) 利用対象アプリケーション
アクセス管理サービスを行うアプリケーション ([270])。
f) アプリケーション開発の容易さ
[269] にあるように API は非常に単純で、また、適用領域も認可 (Authorization) に限定されている。
g) ポータビリティ
C 言語で利用可能であり、特定のプラットフォームには依存していない。
ただし、現状、h) プラットフォームでのリファレンス実装が提供されているため、このプラットフォーム
上での利用が前提となる。
h) プラットフォーム
最新版 v0.6.2 のリファレンス実装では Linux および Solaris のみ対応 ([271])。
[273] では、 Solaris v2.6 およびこれより前の版に対応、と書かれている。
また、仕様書[270] のコンパイル方法では、Solaris2.5.1、Solaris2.7、Linux2.4 で動作確認、となっている。
i) 適用例
GAA-API の C 言語実装 (C-bindings) が Internet Draft [274] として提案された。
また、[275] から C によるリファレンス実装が入手できる。
さらに、Tatyana V. Ryutov のテスト実装と思われるが C ([276]) および Java 言語実装 ([277]) が入手でき
る ([278])。
なお、[279] には、
GAA-API controlled IPSec for Linux FreeS/WAN implementation
という語が出ているが、Linux FreeS/WAN [280]のサイトを調べる限り、GAA-API に関しての情報は出て
こない。
j) 推進団体または提案した会社
University of Southern California (http://cwis.usc.edu/) 大 学 の Information Sciences Institute
124
(http://www.isi.edu/) 、Computer Networks Division の学部、スタッフ、学生らにより非公式に組織さ
れた GOST グループ ([281]) が IETF 仕様に基づき、リファレンス実装を行っている ([282])。
USC/ISI の GAA-API 開発者は Xerox と協同で、GAA テクノロジーを CORBA に統合する作業を行って
いる (資料[283])。
k) 準拠する標準
2000 年 12 月 22 日に
"Generic Authorization and Access control Application Program Interface: C-bindings",
draft-ietf-cat-gaa-cbind-05.txt
として標準化されたが、2001 年 4 月に Expire されている ([274])。
また、"Generic Authorization and Access control APIs (GAA-API)", draft-ietf-cat-acc-cntrl-frmw-01.txt
がとして提案され ([284])、
2000 年 12 月 28 日、"Access Control Framework for Distributed Applications",
draft-ietf-cat-acc-cntrl-frmw-05.txt ([285]) に改版されたが、こちらも IETF のインターネットドラフトと
して失効された。
アプリケーションに認可 (authorization) を追加する IETF のドラフト スタンダード (API + policy
language) は、ポリシー評価の複数実装 (multiple implementations of policy evaluation) をサポートす
ることができる。
l) 利用コスト
C 言語によるリファレンス実装が[275]により無料で入手できる ([271])。
GAA-API の C 言語実装のインターネットドラフトを元にしている ([273])。
m) 関連文書の入手可否
関連文書は [286] から無料で入手可能。この内、仕様書は [270]。
また、関連する IETF 標準は [286] にリストアップされており、ここから入手できる。
n) 他 API との関係
n.1) NodeOS API
NodeOS API は、GAA-API、GSS-API、PAM API を組み合わせて、認証、認可、完全性、
アクセス管理をサポートする (資料[268])。
125
また、上記と同一の、NAI LABS の Seraphim API Architecture。
n.2) GSS-API
GSS-API が認証 (Authentication) をサポートするのに対し、GAA-API が認可 (Authorization) をサポ
ートするため、相補的な関係にある。
n.3) GSI (Grid Security Infrastructure) ([287])
GAA-API のリファレンス実装の以前のバージョンである Version 0.4, 0.5, 0.6.1 は GSI と統合されてい
たが、最新版 v0.6.2 では GSI から分離し、スタンドアロン版として存在している ([273])。
現在、GSI では X.509 Certificate Validity の確証 (Verify) のために GAA API を用いている。
GAA-API が認可 (Authorization)、GSS-API が認証 (Authentication) の API として採用される予定
([288])。
o) 拡張性
GAA-API は新しい条件や制限のために付加モジュールをサポートし、現状のアプリケーションから既存
の複数認可データベースの利用を可能にするよう構造化されている ([271])。
3.4.2 XGSS-API (IETF)
1) API 名
Extended Generic Security Service API (XGSS-API)
2) 概説
IETF にインターネット ドラフト draft-ietf-cat-xgssapi-acc-cntrl-03.txt として提案された GSS-API の
拡張仕様。
なお、GSS-API の仕様は RFC2743、Version 2, Update 1 が最新版であるが、XGSS-API は既に失効され
ており、策定当時の RFC-1508 の GSS-API を元にしている。
XGSS-API は権限委譲 (delegation) と ID 以外の付加的なセキュリティ属性の関連 (association) を許
126
す。属性の例は、役割、特権、グループ、制限が含まれる。
3) 歴史
draft-ietf-cat-xgssapi-acc-cntrl-00.txt が Tom Parker (ICL) および Denis Pinkas (Bull) により 1995 年
11 月 21 日に IETF の CAT-WG に提出。
その後、July 5, 1996 年 7 月 5 日に draft-ietf-cat-xgssapi-acc-cntrl-01.txt が、そして、1997 年 3 月 25
日 に draft-ietf-cat-xgssapi-acc-cntrl-02.txt が 提 出 さ れ 、 最 終 的 に は 1998 年 11 月 9 日 に
draft-ietf-cat-xgssapi-acc-cntrl-03.txt が提出されたが、失効された。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
3.2.1 GSS-API (Open Group) の a) ライブラリ構成、アーキテクチャ/フレームワーク構成 で述べたよう
に、APKI に関するプレゼン資料[58] の 19P に、GSS-API、IDUP-GSS-API、GSS-NEGO、XGSS-API
(Extended GSS-API) と Kerberos、SPKM、SESAME の関係を図示した構成図がある。
b) 提供するセキュリティの機能
資料[58] によると特権および権限委譲の管理。
GSS-API は 呼 び 出 し 側 ア プ リ ケ ー シ ョ ン が ピ ア ア プ リ ケ ー シ ョ ン (peer application) に 関 す る
principal identity 認証し、ピアに権利を権限委譲 (delegate) し、単一メッセージ ベース (a per-message
basis) の機密性と完全性のようなセキュリティ サービスを適用するのを可能にする ([289]) 。
GSS-API プ リ ミ テ ィ ブ (primitives) は 現 状 、 single identity 以 外 の セ キ ュ リ テ ィ 属 性 (security
attributes) をサポートせず、権限委譲の微調整を許可しない ([289])。
XGSS-API は次をサポートする；
•
様々なセキュリティ属性の交換とこれらの属性を用いた認可機能 (authorization functions) の構築、
権限委譲されたもの、(attribute handling support functions) を含む。
•
権限委譲メソッド
セキュリティ コンテキストのアクセプター、アクセプター管理とサポート機能 (acceptor control and
support functions) に適用されるタイプと制限、の仕様により許可される権限委譲に対する微調整。
c) API 数
RFC1508 ベースの draft-ietf-cat-xgssapi-acc-cntrl-03.txt では、以下の 3 種類、6 関数 ([289])。
•
ATTRIBUTE HANDLING SUPPORT FUNCTIONS (2 関数)
GSS_Set_cred_attributes、 GSS_Get_sec_attributes
•
CONTEXT ACCEPTOR SUPPORT FUNCTION (1 関数)
GSS_Get_received_creds
•
CONTEXT ACCEPTOR CONTROL FUNCTIONS (3 関数)
GSS_Set_cred_controls、GSS_Get_sec_controls、GSS_Compound_creds
d) ベースとなる技術
資料[58]によると、PAC の生成、使用、保護、確証、権限委譲。
e) 利用対象アプリケーション
利用対象アプリケーション
GSS-API が想定する利用対象アプリケーションと同じであるが、上述のセキュリティ機能で述べた
GSS-API の不足を補う形で利用する。
f) アプリケーション開発の容易さ
API が 3 種類 6 関数と少なく、GSS-API を補うものであるため容易。
127
g) ポータビリティ
GSS-API と同じ。
h) プラットフォーム
GSS-API と同じ。
i) 適用例
XGSS-API を実装した製品およびリファレンス実装についての情報は入手できなかった。
3.2.1 GSS-API (Open Group) の a) ライブラリ構成、アーキテクチャ/フレームワーク構成 で述べたよう
に、APKI の検討の中で GSS-API、IDUP-GSS-API、GSS-NEGO と並列に Privilege、Delegation
Management のために XGSS-API を候補にあげている ([58]) 。
j) 推進団体または提案した会社
IETF CAT WG にて、参考資料[289] の Internet Draft として XGSS-API が提案された。
しかし、参考資料[290] によるとこのドラフトは既に失効されている。
また、Open Group が資料[291] のように仕様書としてまとめている。
その後、GSS-API および XGSS-API を元に、SGSS-API (SESAME GSS-API) が作成。
備考) SGSS-API については別途、付録 A5.2.3 SGSS-API にて説明。
k) 準拠する標準
GSS-API の拡張として作成され、Internet Draft として標準化が提案されたが ([289]) 失効されており、現
時点で IETF としての標準化はない。
l) 利用コスト
GSS-API と同じ。
m) 関連文書の入手可否
仕様書は[289] から無料で入手可能である。
n) 他 API との関係
調査する範囲では GSS-API の拡張に 3 種類、4 標準ある。
•
XGSS-API (Extended Generic Security Service API)、draft-ietf-cat-xgssapi-acc-cntrl-03.txt、IETF
([289])
•
GSS-API Extension、draft-ggf-gss-extensions-04.txt、Grid ([292])
Grid 拡張。
•
SGSS-API (SESAME GSS-API)、SESAME (付録で解説)
SESAME が European Commission に
"An Extended Generic Security API", SES/Pap/010, 25JUN94.
という文書で提出した GSS-API の SESAME 拡張である。
これが現在、V4 として仕様化されているが、現在、SESAME GSS-API という名になっている。
また、IETF にインターネット ドラフト、draft-ietf-cat-sesamemech-00.txt として 1995 年 11 月 21
日に提出され、次の文書までアップデートされたがこれを最後に Expire されている([293])。
また、X/Open が上記の SESAME 拡張を標準として採用し、
"X/Open Security Attribute and Delegation Extensions Snapshot Specification"
として 1994 年に出版された。 (ISBN: 1-85912-026-1)
(上記説明は資料[294]から引用)
128
•
GSS-API Security Attribute and Delegation Extension、S307、Open Group ([90])
上記によると、
Piers McMahon, SESAME (Bull-ICL-SNI), "An Extended Generic Security Services API",
Issue 4, July 23, 1993.
を X/Open で標準化した、とある。SGSS-API と元は同じであるが、SGSS-API はその後も活動を続け、
IETF にインターネット ドラフトを提出すると同時に、V4 として改版を行っていた。しかし、SESAME
自身も活動を縮小しており、今後の改版については望み薄の状態である。
n.1) GAA-API
[295] に XGSS-API と GAA-API に関する記述が出ており、これら 2 つはどちらも ISO 10181-3 で
定義されるアクセス管理モデルをベースにしている。このアクセス管理モデルは、Access Enforcement
Function と Access Decision Function の 2 つのファンクショナル エンティティを規定している。結論
として、両方の API は実際に相補的であり、LDAP サーバはこれら両方の API を利用することが可能であ
る。
以下は Yahoo! Groups に投稿された記事の引用。
XGSS および GAA は異なるアプローチに従っている。 XGSS がクレデンシャル (credentials) から
特権 (privileges) を抽出するのに対し、GAA はクレデンシャルを不透明な構造 (opaque structure) と
みなし、そのオブジェクトにアタッチされた認可データ (authorization data) とそれらを比較する。そ
のオブジェクトに対して実行された操作が表れた場合、イエスかノーの答えが返される。そのオブジェ
クトに対して何の操作も表れなかった場合、そのオブジェクトに対して許可された全ての操作が返され
る。XGGS では認可データ (authorization data) が未定義のままであるのに対し、GAA では構造化さ
れていなければならない。現在の GAA の制限の一つに、ACL 構造に対して認可データをそのスキーム
(scheme) が ACL 依存になるように制限される、という制限がある。最小限の機能を提供するという点
では良いのだが、XGSS に比べて全ての場合に対して認可データが柔軟でない。このために、両方のア
プローチを採用する余地が残されている。
さらに、XGSS は、クレデンシャルをどこにフォワードできるか調べるために、権限委譲の役割
(delegation role) においてイニシエータ (initiator) として振舞う方法を提供する。GAA は現時点では
この種の機能をサポートしていない。
n.2) GSI (GSS-API Extensions)
draft-ggf-gss-extensions-04.txt として GSI で標準化が検討されている。
"GSS-API Extensions" は、GSS-API を用いて効果的な Grid プログラミングを行うために提案されたテ
クニカル仕様書のドラフトである ([71])。
n.3) GSS-API
仕様書([94])中に、
もしそうでないならば、
これらの権限委譲されたクレデンシャルは GSS V2 定義外の別の関数 (例えば、
XGSS-API 関数) を通して得ることができる。
“unless those delegated credentials are obtained through separate routines (e.g., XGSS-API calls)
outside the GSS-V2 definition.”
のように、例としてあげられている。
o) 拡張性
XGSS-API に関しては仕様書である draft-ietf-cat-xgssapi-acc-cntrl-03.txt 以外にほとんど情報がなく、
XGSS-API の拡張性に関する情報はこれまでのところ見つかっていない。
129
3.4.3 JAAS (Sun)
1) API 名
Java Authentication and Authorization Service (JAAS)
2) 概説
JAAS はサービスに対する認証、および、
ユーザ毎のアクセス管理を提供する Java のパッケージである (資
料[296]によると "jazz" (ジャズ) と発音する)。
JAAS は標準の PAM (Pluggable Authentication Module) フレームワークの Java 版を実装し、ユーザベ
ースの認可をサポートする (資料[297])。
また、以下の特徴を持つ (資料[350])。
•
ピュア Java 実装 (Pure Java implementation)
•
ユーザ認証のための PAM (Pluggable Authentication Module) フレームワークの実装
既存のアプリケーションに認証モジュールをプラグすることにより、新しい認証サービスが利用可能と
なる。
•
シングル サインオン (Single sign-on) のサポート
いろいろな方法でシングルサインオン (single signon) を提供する。
これは、まず一つは LoginModules により、2 つ目には Subjects にクレデンシャル (credentials) を
関連付けることにより、提供される。
•
ユーザ ベース、グループ ベース、役割ベースの認可 (authorization) による柔軟なアクセス管理ポ
リシー
•
以下を用いたサンプルの認証 (authentication) モジュール:
- JNDI (Java Naming and Directory Interface)
- Solaris Operating Environment
- Windows NT
また、以下を提供する (資料[298])。
•
スタック可能アーキテクチャ (Stackable Architecture)
同時に複数のサービスの認証を可能とする。これは、複数の異なる認証機構が同時に存在するような異
種環境 (heterogeneous environments) で必要となる。
この Stacked authentication は、複数モジュールによるコンフィグレーション ポリシーによって実現
される ([299])。
例えば、以下のコンフィグレーションファイル (設定ファイル) 。
Login2 {
sample.SampleLoginModule required;
com.sun.security.auth.module.NTLoginModule sufficient;
com.foo.SmartCard requisite debug=true;
com.foo.Kerberos optional debug=true;
};
3) 歴史
JAAS は Java2 SDK, Standard Edition (J2SDK), v 1.3 で初めてサポートされ、JAAS 1.0 というオプ
ションのパッケージ として導入された (資料[298])。
(資料[296] によると 1999 年 4 月 4 日に JavaSoft が公開)。
しかし、現在βリリースされている J2SDK, v 1.4 では、外部のコンポーネントでなく、本体の SDK に組
み込まれている (資料[297])。
JAAS 1.0 と J2SDK v1.4 の差は、資料[300] の "What's New in JAAS in the J2SDK, v 1.4" に書かれてい
る。
4) 利点
JAAS は特に分散エンタープライズ環境において、カスタムな JAAS セキュリティポリシーを実現する場
合に効果を発揮する。J2EE 仕様の今後のバージョンでは、J2EE 環境における認証とアクセス権付与の管
理を行うために、JAAS が組み込まれる予定である。この統合が実現すれば、JAAS は主に J2EE 環境の
ベンダーによって使用され、アプリケーション環境を下位の認証テクノロジーと独立させておくことが可
130
能となる。
J2EE 環境のアプリケーション開発者が JAAS を使ってプログラミングを行うことによる最も大きな利
点は、アプリケーションを下位の認証テクノロジーの用件から切り離して構築できることである。さらに、
これを使用するスタンドアロンアプリケーションでは、認証されたサブジェクトに基づく JAAS のアクセ
ス権付与機能により、よりきめ細かなアクセス制御を行うことができる (資料[43])。
5) JAAS の目標
•
単純でプラグ可能な認証 (simple, pluggable authentication)
これは認証インタフェースができる限り複雑さを隠すように設定されていることを意味する。
"Pluggable authentication”は、アプリケーションがセキュリティを考慮することなく別の認証機構に
より置き換え可能なほどインタフェースが抽象化されていることを意味する、
•
ポリシーベース認証 (policy-based authentication)
これはアプリケーションが現在使用されている認証機構に関して感知する必要がないことを意味する。
JAAS に対するデフォルトのログイン設定機構 (login configuration mechanism) は設定ファイル
(configuration file) であるため、アプリケーションはどの認証が使われているかを気にする必要がない。
•
スタック可能な認証 (stackable authentication)
こ れ は 多 重 認 証 機 構 (multiple authentication mechanisms) が 承 認 コ ン テ キ ス ト (authorized
context) が確立する前に成功する必要があることを意味している。例えば、
“testDB2”アプリケーショ
ンを起動するためには、Kerberos ログインおよび DB2 ログインが必要となる。
•
現版の単純な拡張によるユーザベースのパーミッション (user-based permissions to be a “simple
extension” of the current permission model)
これは現版の Java 2 パーミッション モデルが保持されると同時に、拡張可能で容易に理解可能な方法
で付加的な機能が提供されることを意味する。
(資料[296])
6) 備考
JAAS は以下の 4 つのパッケージで構成されている (資料[43])。
•
javax.security.auth
•
javax.security.auth.callback
•
javax.security.auth.login
•
javax.security.auth.spi
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
131
(上図は資料[301], [302]から引用)。
また、JAAS は以下の 2 つのメイン コンポーネントに分割される (資料[303])。
① 認証 (authentication) コンポーネント
誰が Java コードを実行しているかを特定する能力を提供。
② 認可 (authorization) コンポーネント
センシティブなタスクを行う Java コードの実行をコードソースと誰が認証されたかにより制限するこ
とにより、既存の Java 2 Security Framework を補う。
Java 認証はプラグ可能 (pluggable) であり、Java アプリケーションをベースとする認証技術から非依存
にする。
ユーザ認証は、下位のログインモジュールが行い、ユーザに ID、パスワードを問い合わせたり、あるいは
ユーザの環境に存在する情報を用いたりしてユーザを認証する (資料[297])。
ログインモジュールは次の 2 つの特徴を持つ。
① プラグ可能 (Pluggable)
② スタック可能 (Stackable)
b) 提供するセキュリティの機能
•
プラグ可能なユーザ認証 (Pluggable Authentication)
信 頼 で き て セ キ ュ ア に 誰 が Java コ ー ド を 実 行 し て い る か 判 断 す る た め の 、 ユ ー ザ 認 証
(authentication of users)
•
ユーザベースの認可 (User-Based Authorization)
認証したユーザがセキュリティにセンシティブな操作を要求するアクセス管理権 (パーミッション) を
持つことを確かめるための、ユーザ認可 (authorization of users)
上記は資料[302] より引用。なお、これら 2 つの機能のチュートリアルが資料[304] と [305] にそれぞれ掲載
されている。
c) API 数
JAAS v1.0 コアクラスは以下の 3 種類に分類され、10 クラス、46 メソッド (資料[303])。
•
Common Classes (3 クラス、18 メソッド)
Subject (18 メソッド)
Principal (0 メソッド)
Credential (コア JAAS クラスライブラリには public および private の Credential クラスを含まない。
しかし、4 メソッドを実装する必要がある。)
•
Authentication Classes (4 クラス、13 メソッド)
LoginContext (7 メソッド)
LoginModule (5 メソッド)
CallbackHandler (1 メソッド)
Callback (0 メソッド)
•
Authorization Classes (3 クラス、15 メソッド)
Policy (抽象クラスで実際は PolicyFile がデフォルト。5 メソッド)
AuthPermission (2 メソッド)
PrivateCredentialPermission (8 メソッド)
注) 上位クラスから継承したメソッドは含まず。
d) ベースとなる技術
JAAS 自身がベースとする技術は特に示すことができないが、Java セキュリティアーキテクチャでコア
Java 2.0 セキュリティアーキテクチャ上に実装されている。
また、JAAS 自身は認証・認可機能を提供せず、これらの機能は JAAS の下位に位置する認証モジュール
が提供する。認証モジュールは、JAAS SPI (仕様は[306]) を用いて JAAS に組み込みを行い、Kerberos,
132
SmartCard, Biometric などの認証機能を実装する。
また、これらの機構自身は、PAM アーキテクチャを参考にしている。
e) 利用対象アプリケーション
ユーザ認証 (Authentication)、アクセス管理 (認可、Authorization) を行うアプリケーション。
f) アプリケーション開発の容易さ
資料[297] によると後述 o) のようにシステム管理者が設定する作業が増える代わりに、プログラマの作業
量が少なくなる、とされている。
しかし、JAAS のプログラミングを解説する資料[43]、[48] を読む限り、これらで説明された JAAS のクラ
スアーキテクチャや各クラスの仕様をよく理解した Java プログラマでないと、クラス拡張してアプリケー
ション固有のセキュリティを実装するのは困難に感じる。
g) ポータビリティ
Java プラットフォームが実装されていれば、UNIX、Windows など OS に依存しない。
ただし、下記 h) のように JAAS は Java 2 SDK, Standard Edition, v 1.3 以降で実装されている。
h) プラットフォーム
JAAS 1.0 は Java 2 SDK, Standard Edition, v 1.3 または Java 2 Runtime Environment v 1.3 がプラ
ットフォーム (資料[350])。
i) 適用例
Java 言語により実装。
IBM は、
IBM プラットフォームと Linux のために IBM 開発キット、Java Technology Edition, V 1.3 に
より JAAS 1.0 を、また、IBM プラットフォームのために IBM 開発キット、Java Technology Edition,
V 1.2.2 により少し修正された JAAS を、それぞれ提供する予定である (資料[296])。
IBM OS/2 Warp Developer Kit, Java 2 Technology Edition, Version 1.3 (資料[307]) および IBM OS/390
(資料[308]) は、JAAS をサポートする。
Pramati Technologies ([309]) が開発する以下の製品は JAAS をサポートする ([310])。
•
Pramati Server 2.5 (J2EE ベースのアプリケーション サーバ)
•
Pramati Studio 2.5 (J2EE アプリケーション開発ツール)
•
OpenLDAP 2.0.18
j) 推進団体または提案した会社
Sun Microsystems, Inc.
k) 準拠する標準
標準の Pluggable Authentication Module (PAM) フレームワークの Java 版 (資料[297])。
l) 利用コスト
JAAS 1.0 のリファレンス実装バイナリコードの最終リリース版は商用での利用および再配布が無料であ
る (資料[298])。
また、商用アプリケーションの一部としてロイヤリティ フリーで使うことができる (資料[350])。
また、JAAS はアメリカ合衆国の輸出規制に該当しないため、日本でも利用可能である (資料[298])。
ソースコード、マニュアルは資料[350] から無料でダウンロードが可能である。
133
m) 関連文書の入手可否
仕様書、マニュアルなど関連文書が資料[350] からダウンロード可能である。
JAAS v1.0 の API 仕様が[303]、J2SDK v1.4 用 JAAS の API 仕様が[300] でアクセスできる。
n) 他 API との関係
n.0) Java Security Architecture
JAAS は Java Security Architecture において、core SDK における javax.security パッケージ、JSSE
(Java Secure Socket Extension)、JCE (Java Cryptography Extension)、および Java Security Tools 上
に構築された最新の開発物である (資料[298])。
n.1) Java GSS-API
3.2.9 Java GSS-API (Sun) にて説明。また、資料[192]、[311] を参照。
n.2) PAM
標準の Pluggable Authentication Module (PAM) フレームワークの Java 版 (資料[297])。
o) 拡張性
JAAS はシステム管理者が以下の 2 種類の設定を行うことにより、セキュリティに関する設定を変更する
ことができる ([312])。
o.1) JAAS のプラグ可能な (pluggable) モジュールのインストールおよび設定
システム管理者は必要とする JAAS ログインモジュールをインストール、設定する。
JAAS はログインモジュールを含まない。しかし、Sun のウェブサイトから以下の 3 種類のモジュールを
2 種類のダウンロードで (Solaris+JNDI または NT+JNDI) 入手することができる (資料[297])。
•
Solaris login module
•
NT login module
•
JNDI login module
備考) この情報は JAAS v1.0 の情報であり、J2SDK v1.4 用の JAAS に関してのログインモジュールにつ
いては情報を入手することができなかった。また、JAAS v1.0 に対応する JNDI のバージョンは 1.2 であ
る。
o.2) JAAS ログイン設定ファイル (JAAS Login Configuration File)
<entry name> {
<LoginModule> <flag> <LoginModule options>;
<LoginModule> <flag> <LoginModule options>;
...
};
例えば、以下にサンプルを示す。
Login {
com.sun.security.auth.module.UnixLoginModule required;
com.sun.security.auth.module.Krb5LoginModule optional
useTicketCache="true"
ticketCache="${user.home}${/}tickets";
};
o.3) Java ポリシーファイル (Java Policy File)
JAAS 認証プロバイダはシステムの高度なセキュリティ部分にあたるため、Java ポリシーファイルに
JAAS 用の以下のような設定をする必要がある。
//file conf/JAASProvider.policy
//trust the provider
grant codeBase "file:./provider/" {
permission java.security.AllPermission;
};
//trust JAAS
grant codeBase "file:/java/jaas1_0/lib/jaas.jar" {
permission java.security.AllPermission;
};
134
//these permissions are needed by the client
grant codeBase "file:./client/" {
permission javax.security.auth.AuthPermission
"createLoginContext";
permission
javax.security.auth.AuthPermission "doAs";
permission java.util.PropertyPermission
"user.home", "read";
};
o.4) JAAS ポリシーファイル (Java Policy File)
JAAS 用の設定を JAAS ポリシーフィルに記述する。以下に例を示す。
//file conf/SimpleJAAS.policy
grant Principal SimplePrincipal "Jack" {
permission java.util.PropertyPermission
"user.home", "read";
};
なお、J2SDK v1.4 では JAAS ポリシーファイルは Java ポリシーファイルに統合され、JAAS ポリシーフ
ァイルは不要になる。
また、プログラマは API で示したクラスを拡張することにより、アプリケーション固有のセキュリティを
実装することができる (資料[43]、[48])。
3.4.4 aznAPI (Open Group)
1) API 名
Authorization (AZN) API、aznAPI と略記
2) 概説
Authorization API - 認証フレームワークのための汎用 API ([313])。
国際標準 ISO 10181-3 (アクセス管理フレームワーク) で定義されるアーキテクチャのフレームワークに
準拠するアクセス管理装置を利用したシステムで、アクセス管理のための汎用 API を提供する。仕様書で
定義される API は特権属性管理 (privilege attribute administration) を提供しないが、対象の特権属性
(privilege attributes) の内のどれを特定のアクセス要求を認可するために使うかを管理する機能を対象に
与える機能を提供する (そのような機能をしばしば 「最小特権 (least privilege)」と呼ぶ)。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
システム構成図を以下に示す ([314])。
135
図. aznAPI システム構造
aznAPI を用いるシステムにおけるリソース要求は、Access Enforcement Functions (AEF) によって調整
される。
AEF は、しばしば認証サービス (Authentication Services) を用いてユーザを認証する。
また、 アクセス管理情報 (ACI、Access Control Information) を Authorization API (aznAPI) に渡すこ
とによってリソース要求を認可する。認可された要求を受け付け、認可されない要求を拒否する。
aznAPI は AEF から受け取った ACI をアクセス管理決定情報 (Access Control Decision Information、
ADI) に翻訳する。また、アクセス決定関数 (Access Decision Functions、ADF) を用いて、アクセス決定
を実行する。
ADF は ADI とアクセス ポリシー ルール (Access Policy Rules)を用いて、最初の要求 (initiator's
request) がターゲットの操作を実行するのに許可されるか拒否されるかを決定 する。
b) 提供するセキュリティの機能
アクセス管理 ([314])。
ただ し 、特 権 属性 管 理 (privilege attribute administration) は 提供 し ない が、 「 最小 特 権 (least
privilege)」 と呼ばれる、つまり、特権属性 (privilege attributes) のどれを特定のアクセス要求を認可
(authorize) するのに使うかを管理する機能を提供する。
aznAPI の目標 ([314])。
•
ポリシーに対するアプリケーション透過な評価がアクセス決定を可能とする。
•
アプリケーションのポリシー独立の中央管理を可能とする。
•
広範囲の 認可ポリシー ルール (authorization policy rule)。例えば、ACLs, capabilities, labels,
logical predicates, 等) のシンタックスおよびセマンティックスを等価的にサポートする。
•
認可 (Authorization) から認証 (Authentication) を切り離す。
•
合理的な認可属性型 (例えば、access identities, groups, roles, clearances 等) を等価的にサポートす
136
•
•
•
•
•
•
る。
multi-tiered アプリケーションにおける認可 (authorization)。
multi-tier アプリケーション構成での利用のための認可属性の体現 ( externalization) を許す。
リソースに適用可能なセキュリティ ポリシー (entitlement) 情報へのアプリケーションによるアク
セスを可能にする。
API 実装として様々なアクセス コントロール メカニズムをサポートする。
マルチ 認証、認可サービス (multiple authentication and authorization services) のシングル アプ
リケーションによる並列利用 (simultaneous use) を可能にする。
認可サービス (authorization service) の操作に関する監査データ (audit data) へのアプリケーショ
ン アクセスを可能にする。
c) API 数
以下の 39 関数 ([314])。
•
Function Call Definitions
azn_attrlist_add_entry
azn_attrlist_add_entry_buffer
azn_attrlist_create
azn_attrlist_delete
azn_attrlist_get_entry_buffer_value
azn_attrlist_get_entry_string_value
azn_attrlist_get_names
azn_attrlist_name_get_num
azn_authority_get_authorities
azn_authority_get_entitlements_svcs
azn_authority_get_labeling_schemes
azn_authority_get_mechanisms
azn_authority_get_mod_svcs
azn_authority_get_pac_svcs
azn_creds_combine
azn_creds_create
azn_creds_delete
azn_creds_for_subject
azn_creds_get_attrlist_for_subject
azn_creds_get_pac
azn_creds_modify
azn_creds_num_of_subjects
azn_decision_access_allowed
azn_decision_access_allowed_ext
azn_decision_has_clearance
azn_entitlement_get_entitlements
azn_entitlement_get_labels
azn_entitlement_get_operations
azn_entitlement_get_operations_ext
azn_error_major
azn_error_minor
azn_error_minor_get_string
azn_id_get_creds
azn_initialize
azn_pac_get_creds
azn_release_buffer
azn_release_string
azn_release_strings
azn_shutdown
次に主な関数の説明表を参考に添付する ([314])。
137
Interface Family Name Prefix
azn_initialize, azn_shutdown
Interface Family Supported Functions
Initialize aznAPI implementation
azn_creds
Clean up aznAPI implementation in preparation for shutdown
Create, delete, modify, and combine credentials chains
Get information from credentials chains
azn_id
azn_decision
azn_entitlement
azn_pac
azn_error
azn_authority
azn_attrlist
Build PAC based on credentials chain
Build credentials chain based on authenticated identity produced by
an authentication service
Make an access decision
Get access control policy information
Build credentials chain based on PAC produced by an authorization
service
Retrieve error information from status values returned by aznAPI
functions
Discover authentication, authorization, and credentials, label, and
pac mechanisms supported by aznAPI implementation
Create and delete attribute/value pair list
Write parameter data into attribute/value pair list
Read parameter data from attribute/value pair list
Release data allocated by aznAPI implementation
表: aznAPI 関数
azn_release
ただし、仕様に準拠するために、次表に示さされた実装必須関数以外の関数については実装が必要だが、
仕様書 ([314]) に明記された機能の全てをサポートする必要がないとしている。
azn_attrlist_* /* all attrlist calls */
azn_creds_create
azn_creds_delete
azn_decision_access_allowed
azn_error_* /* all error calls */
azn_id_get_creds
azn_initialize
azn_release_* /* all release calls */
azn_shutdown
表 "Mandatory Function Calls in Conformant aznAPI Implementation"
d) ベースとなる技術
技術といえないが、ISO 10181-3 Access Control Framework 。
また、PKI、Kerberos、LDAP や DCE、SESAME、CDSA などの要素技術を利用する ([315])。
e) 利用対象アプリケーション
認可 (Authorization)、アクセス管理を必要とするアプリケーション。
aznAPI がベースとする ISO 10181-3 アクセス管理フレームワーク (access control framework) はスタ
ンドアロンおよびネットワーク化されたシステムの両方においてアクセス管理をサポートする ([313])。
f) アプリケーション開発の容易さ
ISO 10181-3 Access Control Framework で規定されたアーキテクチャ フレームワーク (下図) で使われ
138
ることを想定しており、これに関しての情報とこれの実施方法の情報が仕様理解に必要である ([314])。
図: ISO 10181-3 Access Control Framework
しかし、対象領域が固定され、上述のように関数の個数が限られているため、ISO 10181-3 の概念とこれ
をベースにした関数の利用方法が理解できれば比較的容易と思われる。
g) ポータビリティ
アプリケーションが aznAPI の利用を仕様書の "Required Functionality" の節で規定される機能に制限
する場合には、aznAPI 実装に渡ってポータブルであると言える ([314])。
このとき、これらの実装はリソース名および操作名 (resource and operation names) をサポートする場合
に限られるが、この仕様書では保護リソースや保護操作 (protected resources or operations) に対する標
準の名前空間 (namespaces) や名前シンタックスを定義していない。
h) プラットフォーム
特にプラットフォームに関する情報は入手できていないが、仕様自身は C 言語が使われている。
i) 適用例
i.1) IBM (旧
旧 Tivoli), Tivoli SecureWay Policy Director
Tivoli ([316]) が開発した Tivoli SecureWay Policy Director ([317]、[318])。
Tivoli SecureWay Policy Director のコンポーネントに "Policy Director Authorization API" が存在する
が、これは aznAPI に準拠し、認証と認可というセキュリティ機能を提供する。
また、Java 2 および JAAS もサポートしていることを付記しておく。
つまり、プログラマに対して以下の 2 つの言語をサポートしている。
•
JAAS による Java
•
aznAPI による C、C++
i.2) GCSS-AF (Global Combat Support System - Air Force)
"Authorization Decision Model" に aznAPI を採用している ([319], [320])。
GCSS-AF は米国 DoD の契約により開発を行っている空軍防衛システムである。
j) 推進団体または提案した会社
Open Group
k) 準拠する標準
本 API を 利 用 す る シ ス テ ム の ア ク セ ス 管 理 (access control) は 、 ISO 10181-3 - Access Control
Framework で規定されるアーキテクチャに準拠するように設計されている ([314])。
139
なお、ここで言う「アクセス管理 (access control)」は、ISO 7498-2, the ISO Security Architecture によ
る定義である以下の定義を用いている；
認可されない方法によるリース利用の防止を含む、リソースに対する認可されていない利用の防止。
(The prevention of unauthorized use of a resource, including the prevention of use of a resource in
an unauthorized manner.)
l) 利用コスト
仕様の利用は無料。リファレンス実装については情報入手できなかった。
m) 関連文書の入手可否
仕様書は Open Group の [313] のページより[314] としてオンラインでアクセスが可能である。
なお、ISO 10181-3 標準のプリントアウトの入手は有料である。
n) 他 API との関係
具体的に他の API との関係に関する情報は入手できなかった。
敢えて指摘するとすれば以下の情報である。
n.1) GAA-API
GAA-API と同じ認可の機能を提供する ([321])。
n.2) PERMIS API
PERMIS API は aznAPI をベースにしている。付録 A5.4.2 PERMIS API を参照。
o) 拡張性
複数の認証および認可サービスの単一アプリケーションにより並列利用を可能にする ([314])。
3.4.5 PAM (SunSoft)
1) API 名
Pluggable Authentication Modules (PAM)
2) 概説
ユーザ認証の柔軟なメカニズム ([322])。
ユーザ認証においてはパスワードによる認証が組み込まれているが、これに置き換わる、スマートカード
などのハードウェアやより高度なセキュリティを持ったソフトウェアによる認証など様々な認証方式が出
始めている。
もし新しい認証スキーム毎に関連する login や ftpd などのプログラムをすべて修正していたのでは、非常
に多くの手間がかかってしまう。PAM は認証スキームに依存しないプログラムを開発するための方式を提
供してくれる。
そのために、実行時に動的にアタッチされる「認証モジュール (authentication modules)」が必要になる。
どの認証モジュールがアタッチされるかは、ローカルシステムの環境設定に依存し、これはローカルシス
テムのシステム管理者が管理することになる。
PAM を使用する場合は、設定ファイルを編集することによってプログラムにモジュールをプラグインす
る方法を制御することになる。
つまり、ユーザ認証が必要な各アプリケーションを改造することなく、システム管理者が必要なモジュー
ルをインストールし設定ファイルを変更することにより、さまざまなユーザ認証をシステムで利用(ユーザ
に提供)することが可能となる。
3) PAM の利点
•
各種アプリケーションとともに使用できる共通の認証設定。
140
•
•
•
PAM をサポートするためにアプリケーションを再コンパイルする必要がなく、あらゆるアプリケーシ
ョンとともに実装できる。
システム管理者とアプリケーション開発者のための、認証に対する優れた柔軟性と制御性。
アプリケーション開発者が、プログラムを開発する際に特殊な認証設定を使用する必要がないこと。
そのため、純粋にプログラムの細部の開発に集中することができます。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
簡単な図は SunSoft の説明資料にある以下の図である ([323])。
また、資料[341] の PAM フレームワークの図が以下の図である。
141
PAM がサポートするサービス モジュールは以下の 5 種類。
•
認証 (Authentication)
•
アカウント管理 (Account Management)
•
セッション管理 (Session Management)
•
パスワード管理 (Password Management)
•
マッピング (Mapping)
b) 提供するセキュリティの機能
•
ユーザ認証
•
アクセス管理
また、PAM が提供する機能はセキュリティ機能を含めて以下 ([323])。
•
システム エントリー サービス (System Entry Services) に対してユーザ認証を行う汎用の方法を
提供する
•
マシンおよびアプリケーション固有のポリシーをサポートする
•
複数のメカニズムでシングル-パスワード ログイン (single-passwd login) を可能にする
•
マルチ ベンダー サポート
PAM は単一の高レベルの API を通して実行時にアプリケーションに接続することにより、複数の低レベ
ルの認証メカニズム (multiple low-level authentication mechanisms) を統合する。PAM 技術は単に認
証 (authentication) を扱うだけでなく、アカウント管理、セッション管理、パスワード管理のような他の
システム アクセス サービスを処理することができる。ローカルおよびリモート ログイン、ファイル転送、
リモート実行を用いるバラバラのアプリケーションやパスワード変更プログラムは全てシステム アクセ
ス API として PAM を用いることができるため、PAM の統一セキュリティ インフラストラクチャ から
システム全体の恩恵を得ることができる。PAM はキャラクタ ベースおよびグラフィック ベースの両方
のシステムをサポートしている (資料[324])。
c) API 数
XSSO-PAM 仕様 (資料[341]) で、以下の 6 分類、22 関数。
① PAM Framework Layer Functions (11 関数)
pam_start()
pam_end()
pam_get_data()
pam_set_data()
pam_get_item()
pam_set_item()
pam_getenv()
pam_getenvlist()
pam_putenv()
pam_strerror()
pam_get_user()
② Authentication Functions (3 関数)
pam_authenticate()
pam_authenticate_secondary()
pam_setcred()
③ Account Management Functions (1 関数)
pam_acct_mgmt()
④ Session Management Functions (2 関数)
pam_open_session()
pam_close_session()
⑤ Password Management Functions (1 関数)
pam_chauthtok()
⑥ Mapping Functions (4 関数)
142
pam_get_mapped_username()
pam_get_mapped_authtok()
pam_set_mapped_username()
pam_set_mapped_authtok()
なお、上記は資料[341] の PAM-API から引用したものであり、RFC 86.0 (資料[339]) では以下の API は含
まれない。
① pam_getenv(), pam_getenvlist(), pam_putenv(), pam_get_user()
② pam_authenticate_secondary()
⑥ pam_get_mapped_username(), pam_get_mapped_authtok(), pam_set_mapped_username(),
pam_set_mapped_authtok()
また、RFC 86.0 の API は Sun の Service API man pages (資料[325]) と同一である。
この場合、5 分類、22-9=13 関数の API が提供。
また、Linux-PAM の仕様書[326] では、上記の仕様に以下の関数が追加され、
① pam_fail_delay()
以下が含まれない。
① pam_get_data(), pam_set_data(), pam_get_user()
② pam_authenticate_secondary()
この仕様では、22-4+1=19 関数の API が提供される。
さらに、資料[341] と論文[327] の仕様を比較すると、論文[327] に以下の関数が含まれない。
② pam_authenticate_secondary()
⑥ pam_get_mapped_username(), pam_get_mapped_authtok(), pam_set_mapped_username(),
pam_set_mapped_authtok()
この場合、22-4=18 関数の API が提供される。
d) ベースとなる技術
認証モジュールとして以下のものが利用可能であり、これらモジュールが提供するユーザ認証がベースと
なる。ただし、PAM の API によりモジュールを開発することができるので、これ以外にベンダーやプロ
グラマが PAM モジュールを追加することができる。
•
パスワード
•
Kerberos
•
S/Key
•
SmartCard
e) 利用対象アプリケーション
login などユーザ認証が必要なプログラム。
これらの基本的なコマンドは OS に同梱されるため、通常は OS が PAM ライブラリとこれを利用するユー
ザ認証のコマンドと一緒にリリースする形態を取る。
f) アプリケーション開発の容易さ
PAM 自身は 13 から 22 個の API が提供されるだけで、非常に分かり易い API である。
また、後述 i) に示すように、Linux を含む UNIX 系のコマンドやアプリケーションでは、PAM を利用し
たものが非常に多く提供されており、標準の /etc/passwd 認証の代わりに PAM ベースのユーザ認証に簡
単に切り替えることができるようになっている。
g) ポータビリティ
基本的には、Solaris、AIX などの UNIX 系製品、あるいは、RedHat などの Linux 系 OS で利用できる。
が、PAM を実装するライブラリは OS 依存のため、各 OS 用に作成された製品がそのまま他の OS に移植
できるかどうかは定かではない。上記 c) で調査する限り、PAM ライブラリが提供する API が OS や仕様
143
により少しずつ異なるため、完全なポータビリティを提供するものではないようだ。
また、相互運用性 (Interoperability) の観点で言うと、PAM SMB (資料[ 328 ]) により、SMB サーバ
(Windows NT および Samba サーバで Windows95 または Windows98 を含む) の認証を UNIX で用い
ることができる。
h) プラットフォーム
Linux-PAM プロジェクトのポーティング OS (資料[329])。
•
Caldera (since ?) (???)
•
Debian 2.2 (alpha, arm, i386, ppc and sparc, sparc64)
•
FreeBSD 3.2 (???)
•
Red Hat Linux 3.0.4(?) (all platforms that they support)
•
SuSE Linux 6.2 (all platforms that they support)
•
Apple OS-X has embraced (and 'extended') it.
また、資料[19]では以下の OS で可能。
•
RedHat since version 5.0
•
Mandrake since 5.2
•
Debian since version 2.1 (partial support in 2.1 -- complete support in 2.2)
•
Caldera since version 1.3
•
Turbolinux since version 3.6
•
SuSE since version 6.2
また、Sun の Solaris 2.6 (資料[330])、IBM の AIX 5.1L (資料[331]) に組み込まれている。
1998 年 1 月 28 日更新の資料[332]には、「HP-UX 9.0 に移植中」とある。
OSF の 1995 年リリースの CDE 1.0 に組み込まれ、1996 年リリースの Common Desktop Environment
(CDE)/Motif に組み込まれる予定とある (資料[324])。
WindowsNT に PAM ライクのユーザ認証を GINA に提供する GINA モジュールを開発するプロジェクト
がある (資料[333])。
i) 適用例
Linux への移植は Linux-PAM プロジェクトが行っている (資料[322])。
Linux 上のモジュール/アプリケーションで PAM ライブラリを適用したもののリストが資料[334]にあり、
以下のものがある。
•
pam_mount
•
Kerberos
•
SAMBA
•
chroot
•
pam_ssh
•
SecurID
•
Radius
•
SafeWord
•
SQL database based authentication
•
iButtons
•
IMAP
•
pam_netgroups
•
LDAP
•
Cryptocard module
•
Netscape web server ns-api
•
pam_tcpd
•
TACACS+
•
Netware
•
PHP
•
misc solaris stuff
144
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
u/wtmp handling
pam_console
mod_auth_pam
PAM_su
Misc - a bunch of toolkit modules (pam_make など)
Rhosts
S/KEY
crypt2g
CODA
Enterprise Suitespot
pam_pwdfile
pam_pwgen
Python
NewsCache
pam_unix (alternatives)
sudo
Squid
Perl
AFS (Andrew Filesystem)
pam_if
pam_xauth
ProFTPD
Pamrelay
NRL OPIE
i.1) Sun, Solaris
PAM は Solaris 2.6 に統合されている ([335])。
i.2) IBM, AIX 5.1
AIX 5.1 は XSSO PAM のネイティブ (Native) 実装が追加されている ([336])。
i.3) SCO (現、
現、CALDERA),
OpenLinux 3.1.
現、
OpenLinux 3.1.1 は PAM を統合している ([337])。
i.4) RedHat 4.0
Linux PAM は RedHat4.0 の一部として配布されている ([338])。
j) 推進団体または提案した会社
SunSoft により作成された仕様が標準化のため DCE/OSF-RFC 86.0 として採択され、CDE に採用された
(資料[338])。
また、Linux-PAM プロジェクト (資料[322]) が Linux 上の PAM の移植を行っている (なお、Linux-PAM
プロジェクトの活動については資料[338] のプレゼン資料が分かり易い)。
また、Open Group が XSSO-PAM として PAM を含んだ形で標準化作業を行っているが、現時点では正式
な標準ではなくドラフトの段階である (資料[341])。
k) 準拠する標準
PAM 自身が準拠する標準はない。PAM 自身の標準化に関する情報を、以下にあげる。
SunSoft のスタッフにより DCE/OSF-RFC 86.0 として標準化され (資料[339])、 OSF CDE 1.0 に採用さ
れた。
また、クライアント サーバ プログラミングモデルに PAM を汎用化する仕様として提出されている (資料
[340]) が、この仕様は June 13, 2000 に Expire された。
また、Open Group が XSSO-PAM として PAM を含む形で標準化を行っている (資料[341])。
l) 利用コスト
Linux-PAM に関連するファイルは全て資料 [342] からダウンロードでき、ライブラリのソースコードは
tar+圧縮形式で [343] から入手できる。また、開発中の最新コードは、資料 [344] から無料で入手できる(パ
145
ッケージ化されていないため、
[344] のトップページではなく CVS で個々のファイルを [345] から入手する)。
Solaris、AIX、RedHat などは OS に同梱されているため、改めて入手する必要はない。
もし Linux 系の PAM モジュールが必要な場合は、RPM 形式のファイルを検索可能な資料[346] のサイト
から検索およびダウンロード可能である。
m) 関連文書の入手可否
Linux-PAM は以下の 3 種類のドキュメントがオンラインで資料[347] よりアクセス可能。
•
The System Administrators' Guide
•
The Module Writers' Manual
•
The Application developers' Manual
また、上記を含む Linux-PAM のドキュメント一式が資料[348] からダウンロードできる (いずれも無料)。
Sun (資料[330]) からは Solaris PAM の文書一式が入手できる。
•
White paper: based on the paper published at the Third ACM Conference on Computer
Communications and Security, March 1996 (PostScript or PDF)
•
Library man pages (PostScript or PDF)
•
Service API man pages (PostScript or PDF)
•
Configuration file man page (PostScript or PDF)
•
Applications man pages (PostScript or PDF)
•
Admin documentation (PostScript or PDF)
n) 他 API との関係
n.1) Personal Security Module (PSM) API
Personal Security Module API (PSM API) は PAM に SmartCard を統合するための API として提案され
たもの (資料[349])。
n.2) XSSO-PAM (Open Group)
"X/Open Single Sign-on Service (XSSO) - Pluggable Authentication Modules"
資料[341] よりドキュメントが入手可能。
(上記資料の古い 1997 年 3 月版であれば PS 形式のファイルが[348] よりダウンロードできる)。
n.3) JAAS 1.0
The Java Authentication and Authorization Service (JAAS) 1.0 は、認証とアクセス管理を提供する
Java パッケージであるが、標準の PAM フレームワークの Java 版を実装するものである (資料[350])。
n.4) Pluggable Non Interactive Authentication Modules (PNIAM)
PAM と PNIAM の主な違いはそのターゲットである。PNIAM のターゲットはインターネット サーバ
に対するクリアで信頼できる認証スキーム (authentication scheme)。インターネット プロトコルは通常、
サーバ、クライアント間の要求と応答の固定したセットを規定している。これがインターラクティブな認
証 (interactive authentication) を可能にするのは困難である。PNIAM はユーザとインターラクトする
よりも要求と応答のセットを扱う。このため、この標準の名前に ”Non Interactive” という語が付いてい
る (資料[351])。付録 A5.4.1 Pluggable Non Interactive Authentication Modules (PNIAM) を参照。
n.5) GSS-API
PMA は GSS-API に対して補足的な機能を提供する。PAM がそのマシン上の任意の新しいシステムレベ
ルの認証サービスに対するユーザ認証を行う機構を提供し、GSS-API はそれに続いてクレデンシャル
(credentials) を用いてそのネットワーク上にある他のアプリケーションレベルのサービスと認証され安
全な通信を行う (資料[327])。
o) 拡張性
システム管理者がプラグ可能なモジュールを追加し、設定ファイルを修正することにより (システムを修
正することなく)、別の (新しい) 認証サービスを用いることができる。
コンフィグレーション ファイル (Linux では /etc/pam.conf ) は以下の形式に従う。
service-name module-type control-flag
module-path arguments
以下に Linux の設定ファイルのサンプルを示す。
auth
required
/lib/security/pam_securetty.so
146
auth
auth
account
password
password
session
required
required
required
required
required
required
/lib/security/pam_unix.so shadow nullok
/lib/security/pam_nologin.so
/lib/security/pam_unix.so
/lib/security/pam_cracklib.so
/lib/security/pam_unix.so shadow nullok use_authtok
/lib/security/pam_unix.so
3.5 バイオ認証 API (Biometric API)
3.5.1 BioAPI (BioAPI Consortium)
1) API 名
BioAPI
2) 概説
BioAPI は、1998 年 4 月に Compaq Computer 社, IBM 社, Identicator Technology 社、Microsoft 社、
Miros 社、 Novell 社が推進主体となって組織された BioAPI コンソーシアムで開発されたバイオメトリ
ック技術のための標準 API 仕様である。コンソーシアムには、HA-API の National Registry 社、BAPI
の I/O Software 社、NSA（National Security Agency）や NIST（National Institute of Standards and
Technology）情報技術研究所の政府関係者のほか、様々な分野の組織が参加し、活動に貢献している。
BioAPI のドラフトは、プラットフォームやデバイスに依存しないマルチレベル API を実現する仕様とし
て、1998 年 12 月にコンソーシアムのメンバーに対して公表されている ([353])。
BioAPI 仕様はソフトウェア アプリケーションが共通の方法で幅広いバイオメトリック技術による通信を
行うことができるオープンシステムの標準 API を定義する。また、BioAPI は指紋 (fingerprint imaging)、
発話者認識 (speaker verification)、顔の識別 (facial recognition)、網膜スキャン (iris scanning)、ダイナ
ミック署名 (dynamic signature)、手形 (hand geometry) といった幅広いバイオメトリック技術をサポー
トする。
携帯電話のような埋め込み装置から国家的な ID システムのような大規模な識別システムまで、また、コン
ピュータとネットワークのアクセスに関連したユーザ認証 (user authentication) のアプリケーションを
含む、幅広いアプリケーションに適用可能なように設計されている。
バイオメトリック業界、政府、主要な IT ベンダーによるコンソーシアム メンバーの数年間に渡る活動の
成果である。
3) 歴史
•
1998 年 12 月、BioAPI の前身である BAPI グループが設立。
•
1999 年 3 月、HA-API グループが BioAPI と合併。
HA-API V2 仕様に続く全ての作業が BioAPI 仕様に統合。
仕様の 1.1 版がメンバーにより承認され、2000 年 3 月に公開。
1.1 版の仕様およびリファレンス実装 (Reference Implementation) が 2001 年 3 月にリリース。
4) 利点
以下、[352]より引用。
BioAPI の実装により以下が可能となる:
•
バイオメトリックを用いるアプリケーションの短期開発
•
プラットフォームおよび OS にまたがるバイオメトリックの柔軟な展開
•
バイオメトリックにおけるコストパフォーマンスを高めるような改善能力
•
(指紋、正門、網膜などの) 複数のバイオメトリックの選択肢による洗練された実装
147
BioAPI は以下を提供することによりこれらのビジネスに恩恵を与える:
•
単純なアプリケーション インタフェース
•
バイオメトリック関数/アルゴリズム/装置に対する、標準のモジュラー アクセス (Standard modular
access)
•
セキュアでロバストなバイオメトリック データ管理と保管 (Secured and robust biometric data
management and storage)
•
バイオメトリック データと装置タイプを区別するための標準的な方法
•
分散コンピュータ環境におけるバイオメトリック識別 (biometric identification) のサポート
5) 標準化
1998 年 12 月、BAPI の設立主体である I/O Software 社が BioAPI の推進主体の一員として加わること
になり、BAPI は Version 1 の完成を持って作業を終了し、その仕様は BioAPI に引き継がれる形で統合
されることになった。さらに、1999 年 2 月、NIST の仲立ちにより、 BioAPI コンソーシアムと HA-API
のワーキンググループとの間で仕様統一に向けた会合が持たれ、1999 年 3 月には両者の仕様を統合する
ことが合意された。HA-API は Version2.0 で凍結され、その後の活動は BioAPI の策定に注がれること
になっている。こうして、新 BioAPI は、BAPI、旧 BioAPI、HA-API の 3 つの API を統合した仕様と
して、2000 年第 1 四半期末までに Version1.0 の完成を目指し、現在、作業が進行している。
また、これに合わせて BioAPI コンソーシアムは改組され、国内標準あるいは国際標準の策定プロセスに
ならい、すべての参加組織がフラットな投票権限をもつように変更された。さらに、BioAPI コンソーシ
アムは外部の標準化団体ともリエゾン関係を設け、Open Group の CDSA/UAS (Common Data Security
Architecture / User Authentication System) 等、主要なコンピュータ・セキュリティの枠組にバイオメト
リック認証サービスを付加する標準仕様の策定に対して影響力を持っている (論文[355])。
なお、日本では 1999 年 5 月セキュリティベンダー8 社 31 が「本人認証規格統一協議会」を設立し、バ
イオメトリック認証の API や共通評価基準策定のほか、米国の BioAPI に対し、日本の意見・要望を提出
する活動を行っている。一方、ISO などの国際標準としては、個々にバイオメトリック認証に関する提案
が行われているのが実態である。ISO/IEC JTC1/SC17/WG4 (接触端子つき IC カード) では、NWI (New
Work Item) として接触式 IC カードを使用したバイオメトリック認証の API 標準化の作業を行うことが
決まっている。
6) 補足
1999 年 11 月時点の調査結果が論文[353] により日本語でまとめられている。この論文では執筆当時の API
の標準化動向と各 API の解説がされている。
148
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
図のように、以下の構成をとる ([354])。
また、参考として文献[355]より別の構成図を引用しておく。
なお、図中の BSP は、Biometric Service Provider を指す。
b) 提供するセキュリティの機能
BioAPI 仕様は次のようなシンプルなバイオメトリック アプリケーションの仕様を提供する ([356])；
•
バイオメトリックの関数、アルゴリズムおよび装置への標準のアクセスメソッド
•
セキュアでロバストなバイオメトリック データ管理と記憶 (secured and robust biometric data
management and storage)
•
バ イ オ メ ト リ ッ ク デ ー タ や 装 置 タ イ プ を 識 別 す る 標 準 的 な 方 法 (standard methods of
differentiating biometric data and device types)
•
分 散 コ ン ピ ュ ー タ 環 境 に お け る バ イ オ メ ト リ ッ ク 識 別 の サ ポ ー ト (support for biometric
149
identification in distributed computing environments)
c) API 数
Version 1.1 の API は次のような合計 36 関数である ([357])。
フレームワーク操作 (以下の 8 関数)：
•
BioAPI_Init
•
BioAPI_Terminate
•
BioAPI_EnumModules
•
BioAPI_ModuleLoad
•
BioAPI_ModuleUnlod
•
BioAPI_ModuleAttach
•
BioAPI_ModuleDetach
•
BioAPI_QueryDevice
BSP 操作 (以下の 4 種類、28 関数)：
ハンドル操作 (以下の 3 関数)：
•
BioAPI_FreeBIRHandle
•
BioAPI_GetBIRFromHandle
•
BioAPI_GetHeaderFromHandle
コールバックおよびイベント操作 (以下の 4 関数)：
•
BioAPI_EnableEvents
•
BioAPI_SetGUICallbacks
•
BioAPI_SetStreamCallback
•
BioAPI_StreamInputOutput
バイオメトリック操作 (以下の 10 関数)：
•
BioAPI_Capture
•
BioAPI_CreateTemplate
•
BioAPI_Process
•
BioAPI_VerifyMatch
•
BioAPI_IdentifyMatch
•
BioAPI_Enroll
•
BioAPI_Verify
•
BioAPI_Identity
•
BioAPI_Import
•
BioAPI_SetPowerMode
データベース操作 (以下の 11 関数)：
•
BioAPI_DbOpen
•
BioAPI_DbClose
•
BioAPI_DbCreate
•
BioAPI_DbDelete
•
BioAPI_DbSetCursor
•
BioAPI_DbFreeCursor
•
BioAPI_DbStoreBIR
•
BioAPI_DbGetBIR
•
BioAPI_DbGetNextBIR
•
BioAPI_DbQueryBIR
•
BioAPI_DbDeleteBIR
また、これら関数の簡単な説明が資料[358]にあるので、詳細は参照のこと。
なお、以下の 4 種類の基本関数と
•
BSP Management Functions (ModuleLoad、ModuleAttach)
•
Enroll User (Enroll)
•
Verify asserted identity (Verify)
•
Discover User's Identity (Identity)
150
下記の 6 種類のプリミティブ関数があり ([359])、
•
Capture
•
CreateTemplate
•
Process
•
VerifyMatch
•
IdentityMatch
•
Import
下記のようにプリミティブ関数の組み合わせで基本関数ができあがっているため ([360])、
•
Enroll = Capture + CreateTemplate
•
Verify = Capture + Process + VerifyMatch
基本関数の利用により基本操作を行うことができる。
d) ベースとなる技術
BioAPI は指紋 (fingerprint imaging)、発話者認識 (speaker verification)、
顔の識別 (facial recognition)、
虹彩スキャン (iris scanning)、ダイナミック署名 (dynamic signature)、手形 (hand geometry)といった
幅広いバイオメトリック技術 ([356])。
e) 利用対象アプリケーション
バイオメトリック認証を用いるアプリケーション。
f) アプリケーション開発の容易さ
アプリケーション開発の容易さ
多くの潜在的なソフトウェア アプリケーションで利用可能なハイレベルの抽象化を提供することにより、
個別のバイオメトリック技術や特定のベンダーの実装・製品・装置に固有の側面を隠してくれる ([361)。
また、BioAPI は以下のようなハイレベルの開発環境を提供する ([361])。
•
照合 (Verification) と 識別 (Identification) のサポート
•
次の 3 つの基本的なハイレベルの抽象化；
- Enroll、Verify、Identify
•
それぞれの BSP に対しベンダー固有の実装に適した GUI がベンダーから供給される
これにより、バイオメトリックを利用する識別・照合 (identification and verification) のアプリケーショ
ンを短期開発 (Rapid development) することができる ([352])。
また、(指紋、声紋、顔、虹彩などの) 複数のバイオメトリック技術に対して洗練された実装方法を提供す
る。
さらに、上述の c) のように、基本関数により簡単にインタフェースを利用できるので、プリミティブ関数
を利用するのに比べて簡単に開発することができる。
g) ポータビリティ
h) で述べるように、プラットフォームおよびオペレーティングシステムに渡って柔軟に展開できる ([352])。
h) プラットフォーム
仕様としてはオープンシステムとしてクロスプラットフォームを意図しており、それには Windows オペレ
ーティングシステム、および、Linux や Unix のような他の環境を含む ([356])。
Version 1.1 のフレームワーク リファレンス実装は、Microsoft Windows NT, 95, 98, Windows 2000 とい
った Win32 オペレーティングシステムをサポートしている。
しかし、他のオペレーティング システムへも簡単にポーティングできるよう設計されており、近い内に
Linux 版がリリースされる計画がある。
また、近い将来、BioAPI 準拠のバイオメトリック モジュールやアプリケーションがベンダーから数多く
リリースされると予想されている。
151
i) 適用例
以下、[362]より引用。
•
Visionics', www.visionics.com ,
FaceIt という名前の製品で、 a facial recognition BSP (Biometric Service Provider) である。
•
SoftPro GmbH & Co. KG , www.softpro.de ,
SignPlus という名前の製品でこれは 署名(signature) BSP である。
•
Wondernet's , www.wondernet.co.il ,
PenFlow という名前の製品で、a signature authentication system である。
•
Dermalog GmbH Identification Systems, www.dermalog.de ,
指紋をベースにした製品群 (Fingerprint BSP) 。
j) 推進団体または提案した会社
BioAPI Consortium。
メンバーは、資料[363]にあがった 84 社。この内、Steering Committee member は以下。
•
Compaq、http://www.compaq.com/
•
Intel Corporation、http://www.intel.com/
•
Iridian Technologies、http://www.iriscan.com/
•
Mytec Technologies、http://www.mytec.com/
•
NIST、http://www.nist.gov/
•
SAFLink、http://www.saflink.com/
•
Unisys、http://www.unisys.com/
また、日本のベンダーとして参加している企業は以下。
•
OKI
•
NEC Corporation
k) 準拠する標準
BioAPI Consortium が標準化。
この仕様を外部の標準化グループに提出する活動がされてきた ([364])。
この成果として、最近リリースされた、あるいは近いうちにリリース予定の以下の標準と互換性がある
([356])；
•
Common Biometric Exchange File Format (CBEFF)
•
NIST Publication NISTIR 6529
•
American National Standards Institute ANSI X9.84 standard
•
"Biometric Management and Security for the Financial Services Industry"
記事[ 365 ] による最新の情報では、BioAPI Specification, Version 1.1 を ANSI (American National
Standards Institute) 標準とするための、National Committee for Information Technology Standards
(NCITS) の Fast Track Process に入ったことがアナウンスされた。
l) 利用コスト
[366] より Version 1.1 のリファレンス実装のバイナリおよびソースコードを入手できる。
仕様およびリファレンス実装はパブリックドメイン (public domain) として公開されており、リファレン
ス実装はオープンソースのソフトウェア (open source software) として無料で利用することができる
([356])。
m) 関連文書の入手可否
最新版である Version 1.2 が[357]から入手可能。
152
n) 他 API との関係
n.1) CDSA/HRS
3.5.2 CDSA/HRS API (Open Group) で別途説明。
セキュリティに関して考慮すべき事項が BioAPI 標準のアプリケーションと装置レベルの両方における開
発の中心事項になっている。
BioAPI と 、CDSA/UAS 、PAM/XSSO 、 MS CAPI のようなバイオメトリ ックを統合する他 の識別
(identification) および認証 (authentication) 標準との関係は、前述の(5)で説明したように外部の連絡会
議で考慮すべきトピックとなりつつある。
n.2) HA-API
BioAPI Version 1.0 は、HA-API コンパチ モードを包括することにより既在の HA-API 実装をサポート
する予定である。このため、現版である HA-API Version 1.03 のアプリケーションは修正なしで、最新の
BioAPI 準拠のバイオメトリック技術を用いて動作することができる。
([364])。
HA-API は Human Authentication API の 略 で 、 NSA の INFOSEC Research and Engineering
Organization により作業が開始され、NRI (現在の SAFLINK)により第 1 版の仕様が作成された ([367])。
また、HA-API Steering Committee が第 2 版の仕様を作成したが、3) 歴史で述べたように HA-API と Bio
Consortium が合併し、第 2 版以降の活動は BioAPI に統合されている。
n.3) I/O Software’
’s Biometric API (BAPI)
以下、[368]より引用。
2000 年 5 月 2 日の Microsoft による「I/O Software の BAPI (Biometric API) を将来リリースする
Windows OS に統合する」という発表に応えて、BioAPI Consortium Steering Committee は以下の声明
を発表した:
BioAPI Consortium は Microsoft が バ イ オ メ ト リ ッ ク 技 術 を 強 力 な ユ ー ザ 認 証 (strong user
authentication) のロバストな方法として支持したことを非常に喜ぶと共に、これがバイオメトリック産業
に成長をもたらすであろうことを期待している。しかしながら、Microsoft が業界で広くコンセンサスの
取れた最新のバイオメトリック標準である BioAPI を Windows OS にバイオメトリックを統合するベー
スとして採用しなかったことは残念である。BioAPI 仕様はパブリック ドメインで利用可能な仕様であり、
全ての関係者に無償提供される (royalty-free)。また、広範囲のコンピュータ環境にわたって利用されるこ
とを意図した、クロス プラットフォームを保証する「オープン システム (open systems)」の仕様である。
これには、Windows OS と共に UNIX や Linux のような他の環境も含まれる。
n.4) BAPI
BioAPI は HA-API と BAPI の最善の統合である ([354])。1998 年 12 月に BioAPI と統合 ([369])。
o) 拡張性
これまでの調査で拡張性に関する情報は入手できていない。
3.5.2 CDSA/HRS API (Open Group)
1) API 名
CDSA (Common Data Security Architecture) / Human Recognition Service (HRS)
2) 概説
CDSA/HRS API は CDSA CSSM のフレームワークにおける EMM 機能を用いて、CDSA に汎用の認証サ
ービスを提供する ([370])。
概要をまとめると以下 ([42])。
•
HRS は EMM (Elective Module Manager) コンセプトの実現。すなわち、フルに機能をサポートする
最初の EMM である。
153
•
•
HRS は CDSA に汎用の認証 (generic authentication) 機能を提供している
HRS は CDSA に BioAPI を統合したものである。
3) 歴史
CDSA/HRS は、1998 年に Intel が CDSA/UAS (User Authentication Services) (資料[5]) として活動して
いた。
その後、 BioAPI Consortium が 2000 年 3 月 30 日に定めた Version 1.0 8 の仕様を 2000 年 6 月 5 日に
Open Group にファストトラックとして提出し、これをベースにして現在の HRS の仕様を公開されてい
る。
4) 特徴
HRS 仕様は以下の特徴がある ([42])。
•
BioAPI Consortium の活動をベースにしている。
•
ファストトラックの標準化として Open Group に提出された。
•
Enroll、Verify、Identify という (バイオ認証の) 基本的な機能をサポートしている。
- また、特別のデータベース機能を追加している。
a) ライブラリ構成、アーキテクチャ/フレームワーク構成
ライブラリ構成、アーキテクチャ フレームワーク構成
HRS は CDSA フレームワークにおいて CSSM の EMM コンポーネントとして位置付けられる。
別項 CDSA におけるアーキテクチャの図には HRS を含めた構成図をのせているが、 HRS のみに焦点を
与えた図を示すと次の図になる ([42])。
備考) なお、この図は Enroll の関数呼び出しシークエンス (Call Sequence) を解説したものであるため、
矢印に Enroll 呼び出しに関連する CSSM の関数名が付記してある。
b) 提供するセキュリティの機能
様々なタイプのヒューマン認証に適合するようなハイレベルのヒューマン認証 (human authentication)
モデルを提供する ([370])。
特に、バイオ認証における基本的な機能である Enrollment、Verification、Identification と、BSP
(Biometric Service Provider) が最適性能で identification population を管理できるようにするデータベ
ース インタフェースを含んでいる。
また、アプリケーションがクライアント上のサンプル入手(capture)を管理したり、サーバ上の Enrollment、
Verification、Identification の機能を管理したりするのを可能とするプリミティブも提供する。
さらに、複数の認証方法 (authentication methods) をサポートするように設計されており、単一の認証方
法や混合方法、つまり「レイヤー化方式」で利用することができる。
154
c) API 数
API は以下の 4 種類、30 関数 ([370])。
•
Handle Operations (3 関数)：
CSSM_HRS_FreeBIRHandle
CSSM_HRS_GetBIRFromHandle
CSSM_HRS_GetHeaderFromHandle
•
Callback and Event Operations (6 関数)：
CSSM_HRS_EnableEvents
CSSM_HRS_SetGUICallbacks
CSSM_HRS_CancelGUICallbacks
CSSM_HRS_SetStreamCallback
CSSM_HRS_CancelStreamCallbacks
CSSM_HRS_StreamInputOutput
•
Biometric Operations (10 関数)：
CSSM_HRS_Capture
CSSM_HRS_CreateTemplate
CSSM_HRS_Process
CSSM_HRS_VerifyMatch
CSSM_HRS_IdentifyMatch
CSSM_HRS_Enroll
CSSM_HRS_Verify
CSSM_HRS_Identify
CSSM_HRS_Import
CSSM_HRS_SetPowerMode
•
Database Operations (11 関数)：
CSSM_HRS_DbOpen
CSSM_HRS_DbClose
CSSM_HRS_DbCreate
CSSM_HRS_DbDelete
CSSM_HRS_DbSetCursor
CSSM_HRS_DbFreeCursor
CSSM_HRS_DbStoreBIR
CSSM_HRS_DbGetBIR
CSSM_HRS_DbGetNextBIR
CSSM_HRS_DbQueryBIR
CSSM_HRS_DbDeleteBIR
なお、資料[42] では、以下の分類を使っている。
•
Basic APIs (3 関数)：
•
Configuration APIs (7 関数)：
•
Utility APIs (4 関数)：
•
Primitives (5 関数)：
•
Utility APIs (11 関数)：
d) ベースとなる技術
CDSA フレームワークの EMM。
e) 利用対象アプリケーション
バイオメトリック認証を行うアプリケーション。
f) アプリケーション開発の容易さ
その API は基本的に BioAPI と同じであるが、非常にシンプルな API を提供しているため、バイオメトリ
155
ック認証をアプリケーションに容易に組み込むことができる。
また、CDSA という統一したフレームワークの中で、他のモジュールの機能と同一の枠組みでアプリケー
ションを開発できるメリットも有している。
また、ベンダーが自社のバイオメトリック製品を CDSA に組み込む場合、仕様書[370] の HRS SPI (Service
Provider Interface) の API により結合するサービス プロバイダモジュールを開発することにより CDSA
に統合することができる。
ユーザは HRS の API により、様々なベンダーのバイオメトリック製品を統一した API で利用することが
できる。
g) ポータビリティ
CDSA と同じ。
h) プラットフォーム
CDSA と同じ。Windows および Linux 用がリリースされている ([28])。
i) 適用例
CDSA/HRS を採用した会社については、参考資料[12]の Adopters にリストアップされている。
•
Mytec、http://www.mytec.com/
•
SAFLINK、http://www.saflink.com/
•
Veridicom、http://www.saflink.com/
•
Iridian Technology、http://www.sensar.com/
j) 推進団体または提案した会社
Open Group, http://www.opengroup.org/
k) 準拠する標準
CDSA 2.0 および BioAPI。
l) 利用コスト
無料。
CDSA のオープンソースが参考資料[36]、SourceForge より入手可能。
m) 関連文書の入手可否
仕様書 (参考資料[370]) は Open Group のサイトよりダウンロード可能。
また、IAL (Intel Architecture Labs) のサイト[12] より関連文書を入手することができる。
n) 他 API との関係
n.1) CDSA 2.0 (Open Group)
HRS (Human Recognition Services) は、以前、User Authentication Services (UAS) と呼ばれていたも
ので、CDSA フレームワークの EMM (Elective Module Manager) 拡張である ([371])。
HRS の基本的な目的は、パスワードの記憶とバイオメトリックの計測という 2 つの組み合わせにより、人
物の認証を行うことである ([371])。
n.2) BioAPI
バイオメトリック処理における単一の業界標準 API を作成するために、CDSA に対する HRS 拡張は最近
公開された BioAPI 標準をベースにしている ([371])。
BioAPI は、HA-API ワークグループと BioAPI Consortium の前身との合併により形成された BioAPI
Consortium (http://www.bioapi.org/) によって開発され、CSSM との整合性を保つため関数名のみが変更
156
された。
HRS EMM サポートは BioAPI によって現状サポートされない CDSA スタックの統合機能をサポートして
いる。
CDSA/HRS と BioAPI は理想的にはバイオメトリック技術の開発とバイオメトリックをアプリケーショ
ンおよびミドルウェアに組み込むための両方に適合する。
確証 (verification) と識別 (identification) は完全にサポートされ、最適性能のためにデータベース
(population database) を管理するためのバイオメトリック サービス プロバイダが提供される。
CDSA/HRS と BioAPI の関係をまとめると以下のようになる ([372])。
•
BioAPI は CDSA から導かれる以下の Module Management 関数を含んでいる。
- BioAPI_Init
- BioAPI_Terminate
- BioAPI_ModuleLoad
- BioAPI_ModuleUnload
- BioAPI_ModuleAttach
- BioAPI_ModuleDetach
•
BioAPI Device = CDSA SubService
•
BioAPI は CDSA イベントアーキテクチャを用いる (2 つのイベントタイプを付加し)
•
BioAPI は (現時点では) CDSA の統合機能を有していない
•
BioAPI は MDS を利用していない
•
CDSA/HRS は CSSM EMM であり、この API は BioAPI と同じ。
- CDSA/HRS は BioAPI Adaptation Layers を持つ予定。
- そして、HA-API Adaptation Layers も持つ予定。
一番下の項目を図示した構成図が次の図になる。
また、BioAPI と CDSA/HRS の歴史的な関係を示す図が次。
157
HRS と BioAPI の違いは以下の 2 点 ([42])。
•
基本的な違いは環境の Integrity にある。
•
BioAPI は HRS の仕様が規定するパラメータをリザーブしている (つまり、使っていない)。
HRS と BioAPI の長所・短所は以下 ([42])。
•
HRS は高レベルの統合環境を提供している。
•
HRS は他の CDSA モジュールからの利用、および、CDSA モジュールの利用が容易。
•
BioAPI はより小さな足跡 (footprint) を残す。
•
現時点ではより多くのバイオメトリック ベンダーがサポートしている。
o) 拡張性
CDSA/HRS の拡張性に関する情報は見つかっていないが、3.1.3 CDSA 2.0 (Open Group) の o) 拡張性 で
述べたように CDSA 自身に拡張性がある。
158