159

4.4.4.4. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの比較の比較の比較の比較 本項では 2項の分類および 3項の詳細分析結果に基づき、それぞれのカテゴリ内で APIの比較を行う。

4.1 アーキテクチャアーキテクチャアーキテクチャアーキテクチャ (Architecture) MISF (Microsoft) は、3.1.1 MISF (Microsoft) で述べたように、詳細な情報を入手することが不可能であるが、CryptoAPI 2.0 (および CAPICOM) を中心とした Windows OS上のセキュリティ フレームワークを指すと言える。つまり、Microsoft が自社ソフトウェア製品のセキュリティを体系付ける枠組みであり、これを実装する製品がすなわちWindows OSをベースとしたMicrosoftの製品全てと言えるだろう。 Java Security Architecture (Sun) は、3.1.4 Java Security Architecture (Sun) で述べたように、Sun自身でこの用語による明確な Javaにおけるセキュリティのアーキテクチャを解説しておらず、Java フレームワークにおける J2SDKとその拡張パッケージである JCE、JCA、JSSE、JAAS を含めたセキュリティ全体を指すと考えられる (J2SDK V1.4ではこれらの拡張パッケージはJ2SDKのパッケージと統合され、より一体となった)。 MISF と Java Security Architecture の 2つは、どちらも 1社が主導で仕様策定、および開発を行っている、という点で似ている。MISF が Windows というプラットフォームに限定されるのに対し、Java Security Architecture はマルチプラット フォームとは言え Java 実行環境という動作環境に制限されることになる。例えば、本文で述べたように GSS-APIを Javaで実装するプロジェクトが過去にアメリカの大学で行われたが、Sun による正式なリリースによって本流とはなっていない。これと同じ状況がCAPICOM にも言え、前述 3.2.2 CryptoAPI 2.0 (Microsoft) の i) 適用例 で述べたように CryptoAPIを VisualBasic などで利用可能にする製品およびフリーソフトがリリースされたが、 CAPICOM のリリースと共にその存在意義がなくなってしまった。このように、これら 2 つのアーキテクチャは主導権を握る推進企業の定める仕様に適合する限りは、また、これらの動作環境に固定する限り、非常に有効なアーキテクチャと言えるが、逆に、拡張する場合に推進企業の将来の動向に左右され変更や撤退を余儀なくされる可能性がある。 さらにアーキテクチャおよび APIとはいえ、どちらも言語実装と仕様が一体となっており、純粋なアーキテクチャおよび APIとは言いがたい、という点も類似している。 これに比べ、CDSAおよび APKIはベンダーでなく非営利の標準団体が策定しているという点で、さらに仕様とリファレンス実装が分離しているという点から、真の標準と言える。CDSA はマルチプラット フォームで言語に依存しない純粋なアーキテクチャで、しかも拡張性の高いアーキテクチャと言える。CDSA 1.2 (Intel) は初期のバージョンであり、現在標準化されているのは CDSA 2.0 (Open Group) である。CDSA 1.2 から 2.0 への移行ツールが出されるなど過去のものとなっており、もはや CDSA 1.2の導入を検討するのは無意味であろう。 一方、APKI (Open Group) は上記のアーキテクチャと全く性質を異にし、PKIの領域における要求仕様を明確にし、機能単位でコンポーネントに分割すると同時に、それぞれのコンポーネントに適する APIおよびプロトコルを推奨するものである。先の CDSA が低レベルの CSSM API を明確に定め、これをベースにしてボトムアップのアプローチで策定されたアーキテクチャであるのに対し、APKI の場合は要求仕様から世にある API、プロトコルを調査して適する候補を見つけるトップダウンのアプローチにより定められたアーキテクチャである。また、この違いは CDSAが APKIの候補となっており、PKIだけでなく他のセキュリティ機能の実装に利用可能であるのに対し、APKI はセキュリティ領域における PKIに目標を絞っている、という点にも表れている。さらに、APKI の目標としては具体的な APIを定めることではないのに対し、CDSAにおいては CSSM APIの仕様策定、リファレンス実装の開発、また、現仕様から新しいセキュリティ技術の追加が目標となる。

160

GSI (Grid Forum) は Grid コンピュータ処理環境のセキュリティ インフラであり、上記アーキテクチャのようにセキュリティを中心に策定されたアーキテクチャではなく、より広いコンピュータ環境のアーキテクチャの一部 (インフラ) を構成するものである。したがって、今後、Grid およびこの概念を実装した Globus がどれだけ普及していくかにかかっている。いくつかの企業が採用を計画しているなど実際の製品へと普及していくことが期待されるが、現状は大学や研究機関が中心となって研究開発を進めている段階である。GSI および Grid の今後の動向に注目することが必要と思われるが、このためにはセキュリティ関連 APIを超えたより広い範囲での調査が必要となる。 このように、本資料で調査対象としたアーキテクチャは、性質および目標が異なるため同じレベルで比較することができない。さらに、これらのアーキテクチャを前述の 3. 分類に基づく各セキュリティ関連 APIの分析 で述べたように個々の調査項目で定量的に評価し、推奨するアーキテクチャを絞ることも不可能である。

4.2 セセセセキュリティキュリティキュリティキュリティ サービスサービスサービスサービス API (Security Service API) CryptoAPI 2.0 (Microsoft) は Windows プラットフォームにおけるデファクトのセキュリティ サービスAPI標準と言える。Windows プラットフォームでセキュリティ機能を実装する場合にはまず CryptoAPI 2.0 (および CAPICOM) の利用を考慮すべきだろう。1社独自の仕様であるが、CryptoSPI により自社の暗号製品を CryptoAPI 2.0 で利用可能にする拡張性を持っている。 CAPICOM (Microsoft) は 3.2.12 CAPICOM (Microsoft) で述べたように CryptoAPI 2.0の機能を C++以外で提供するためのものであり、機能的には CryptoAPI 2.0 と同じである。ただし、Visual Basic や ASP など EUCでの言語で利用可能なため、これを利用するプログラマの数は CryptoAPI 2.0 を利用するプログラマよりも多いと予想される。 CSSM API (Open Group) は、前述 3.2.3 CSSM API (Open Group) で詳しく述べたように、提供するセキュリティ機能の豊富さではこの分類で最大であり、逆に言うと大規模で複雑と言える。そのサポートする対象の広範さだけでなく、拡張性にも優れている。 GSS-API (Open Group) と IDUP-GSS-API (IETF) は補完的に利用される APIで、GSS-API がセッション型、つまり、オンライン リアルタイム メッセ-ジングのアプリケーションを対象にしているのに対し、IDUP-GSS-API は蓄積交換型、つまり Eメールのアプリケーションを対象にしている。 GSS-API および IDUP-GSS-API は SESAME や OSF DCE のような適用例もあり、また、前述のCryptoAPI 2.0や後述の OPSEC のようなデファクト スタンダードでなく、IETFが中心となって策定を進める真の標準である。GSS-API は更新され続けており、これに関連した標準も何種類か策定されていること、また適用した製品もあることから、普及が進んでいる APIと言えるだろう。ただし、CSSM API に比べるとこの API がサポートするセキュリティ機能は範囲が狭い。また、近年の活動は GSS-API から CDSA (CSSM API) へと移行しており、過去のものとなりつつある。 JCE (Sun) は、暗号機能を中心に鍵生成やMACをサポートする APIである。Javaプラットフォームでこれらの機能を用いる場合、JCEを用いることになるであろう。また、実際の暗号機能は JCE の下に位置する CSPが提供し、Sun以外の企業から JCEに相当するパッケージがリリースされており、Sunからリリースされたデフォルトの JCEを置き換えることが可能である。 一方、JSSE (Sun) は SSL/TLS を Javaで利用可能にするための APIであり、この機能に特化される。 JCE、JSSEは Java Security Architectureの枠組みのコンポーネントであり、Javaプラットフォームのアプリケーション開発ではまずこれらの API の利用を検討することになるであろう。次期版の J2SDK V1.4ではこれらの拡張パッケージが J2SDKに統合され、個々のコンポーネントを個別に検討することは意味がなくなることになる。 COE SS API (MITRE) は、国防情報基盤共通操作環境 DII COE においてセキュリティ サービスを提供する APIである。CDSAをベースにしており、CSSM APIよりも上位の APIを目指している。DII COE上のアプリケーション開発に限定され、一般の企業や組織での利用を想定したものではない。このことか

161

ら、他の民生利用向きの APIと比較するのはあまり意味がないであろう。 Crypto-API (IPA、三菱電機) は、PKI 環境で利用される API の標準である。要求仕様から検討するという点では APKI (Open Group) と似ているが、このプロジェクトでは要求仕様から実際の API仕様策定を目標としている。2001 年度の活動により機能設計書等を作成しており、2002 年度も継続して仕様作成を行っている。このように、現在も活動中であり実際の API仕様や更にそれの適用が公表されていない現時点では、Crypto-API を評価することはできない。今後の進展や動向に注目したい。 OPSEC (CheckPoint Software) は、CryptoAPI 2.0 (Microsoft) と同様に CheckPoint Software が中心となって進めるデファクト スタンダードである。しかも、OPSEC API は CheckPoint Software 社の製品である VPN-1/Firewall-1 を中心としたネットワーク環境においてネットワーク管理を統合することを目的にしたフレームワーク OPSEC のための APIであるため、この項であげた他の APIと性質を異にする。サードパーティが自社製品を VPN-1/Firewall-1 と連携するために OPSEC API を用いることになる。なお、デファクトとは言え、OPSEC Alliance というアライアンス プログラムに 300社以上のパートナーが参加しており、また VPN-1/Firewall-1 が広く利用されているため、今後の普及が予想される。 こ の カ テ ゴ リ で 注 目 す べ き ア ー キ テ ク チ ャ は 、 CryptoAPI 2.0 、 Java (JCE, JSSE) 、GSS-API/IDUP-GSS-API の 3種類であり、特に CryptoAPI 2.0 と Java が重要である。

4.3 暗号暗号暗号暗号 API (Cryptographic API) GCS-API (Open Group) は 3.3.1 GCS-API (Open Group) で述べたように既に更新されておらず、CDSA (CSSM API) に置き換えられる標準である。今後新たに暗号機能を実装する場合に GCS-API を選択することはないであろう。 PKCS#11 (RSA) は提供期間の長さや採用企業の多さの点からいって最も利用実績のある暗号 APIと言える。また、RSA Security Inc. 1社のデファクト スタンダードとはいえ、他の標準やセキュリティ関連 APIから参照されているという点から、暗号 APIの中では最も普及が進んだ APIと言える。 さらに、PKCS#11 ベースのセキュリティ アーキテクチャに触れる資料もあり、低レベルとは言えセキュリティのベースとなる APIである。 JCA (Sun) は Javaプラットフォームにおける暗号機能のベースとなるパッケージである。JCAの下に位置するCSP (Cryptographic Service Provider) により暗号機能が提供され、CSPは SPI (Service Provider Interface) というインタフェースにより結合される。サードベンダーは自社製品を JCAで利用可能にするために、この SPIを用いて CSPを開発することができる。 このカテゴリで注目すべき APIは PKCS#11 と Java (JCA) である。

4.4 認可認可認可認可 API (Authorization API) GAA-API (IETF) および XGSS-API (IETF) はどちらも IETF が標準化を進めながらもインターネット ドラフトが失効しており、かつ、GSS-API と共に使用されて認可機能を提供する、という点で似ている。このように同様の機能を提供する API であると言えるが、 GAA-API と XGSS-API の関係を 3.4.2 XGSS-API (IETF) の n) 他 API との関係 で述べたように補完的であり LDAP サーバでこれら両方の APIを利用することができるため、GAA-API と XGSS-API のどちらを選択すべきかの比較はあまり意味がないであろう。 aznAPI (Open Group) は、これら GAA-API および XGSS-API と異なり、2000年に仕様書が発行され最新に保たれており、また、国際標準 ISO 10181-3 で定義されたアクセス管理フレームワークにも準拠

162

している。純粋な標準で最新に更新されている唯一の認可 API標準である。 JAAS (Sun) は、PAM フレームワークをベースにしており、JAAS ログインモジュールおよび設定ファイルで拡張および設定変更することが可能である。ただし、 他の Java 拡張パッケージに対しても言えることだが、個々の拡張パッケージのみを利用することはできず、また、その採用にあたっては J2SDK を採用するかどうかのレベルで判断することになるため、拡張パッケージを含めた Java Security Architecture のレベルで評価比較を行うことになるであろう。 PAM (SunSoft) は、認証 API (Authentication API) であり、上記の APIとは提供する機能が異なっている。しかし、JAAS が PAMフレームワークをベースに作成されており、JAAS との関係が深いため、敢えて 認可 API のカテゴリに入れてある。Linux を含む UNIX 系の環境では多くのコマンドやパッケージが PAMに対応しており、PAM を用いることによりデフォルトのパスワードによる認証から簡単にセキュリティを高めることが可能である。比較するデータはないが認可 API の中ではもっとも普及が進んでいる APIと言えるであろう。また、PAM の元の仕様は失効しているが、Open Group が PAMを含む形でXSSO-PAM として標準化を行い 1997年に仕様を発行していることを付記しておく。 このカテゴリの API で注目すべきは Java (JAAS)、aznAPI、PAM である (現在市販されている Tivoli SecureWay Policy Director が JAAS と aznAPI に対応していることからもその動向が伺える。また、近年普及が著しい Linux 系の OSでは一般に PAM が組み込まれていることも付記しておく)。

4.5 バイオ認証バイオ認証バイオ認証バイオ認証 API (Biometric API) BioAPI (BioAPI Consortium) は、バイオ認証のハードウェアあるいはソフトウェア製品の開発において、最初に採用を検討することになる APIである。前述 3.5.1 BioAPI (BioAPI Consortium) で述べたように、BAPI および HA-API を含めて活動の歴史も古く、多くのベンダーが参加して現在も活発に活動を継続している標準である。 CDSA/HRS API (Open Group) は、前述の CDSA でバイオ認証を利用可能にするための API であり、BioAPI の仕様をベースに作成している。 これら 2 つの API が提供する機能はほぼどちらも同じであり、基本的な違いはその利用環境にある。CDSA/HRS API を利用する前提として CDSA があるため、CDSA を適用するかどうかが選択判断の基準となる。CDSA は巨大なアーキテクチャであるため、バイオメトリック認証のみに限定するのであれば BioAPI を選択することになるであろう。BioAPI は CDSA/HRS API よりも多くのバイオメトリック ベンダーがサポートしていること、また、古くから活動していることから、より普及が進んでいるとバイオ認証 APIと言える。 備考) 詳細な比較は 3.5.2 CDSA/HRS API (Open Group) の n.2) を参照。

163

5.5.5.5. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの標の標の標の標準化動向準化動向準化動向準化動向 本項では調査対象の様々な API標準化プロセスについて議論する。各々の APIに対して、どこから来ているのか、また標準化に向けてどの段階にあるのか、について説明する。これらの APIは標準化プロセスの様々な段階にあり、標準化が完了していないもの、ずっと昔に標準化されたもの、現在修正中のものなどがある。

5.1 APKI – (Architecture for Public Key Infrastructure) APKI (Architecture for a Public Key Infrastructure) 標準化は Open Groupのメンバーによって作成された。APKIは APIおよびプロトコルを定めた上位のアーキテクチャである。APKI自身は APIではないが、これらの APIおよびプロトコルを論理的なレイヤーに構造化している。APKI の目標は PKI初期段階において PKIの世界を秩序化することである。APKIのそれぞれのレイヤーは特定のサービスを記述している。既に標準が存在する場合には、その標準を APKIに採用している。一方、構造において適切な APIまたはプロトコルが存在しない場合には、新しい APIまたはプロトコルを作成することによって構造化している。 標準化プロセスはそれぞれのレイヤーをどうすべきかと、それぞれのレイヤーに対してどの標準を採用すべきか (あるいは推奨されるべきか) の 2つの同意によって構成される。標準により相互運用が保証されるのに充分な情報が指定されない場合は、APKI はプロファイル、または、標準のサブセットを指定している。 APKI における API およびプロトコルはトラストおよびガバナンスのドメインの確立 (establishment of domains of trust and governance)、機密性 (confidentiality)、完全性 (integrity)、認証 (authentication)、否認防止 (non-repudiation) のサポートが要求される。PKIサービスの監視および監査のサポートが将来必要であろうとみなされている。 APKI のレイヤーは以下の図で示される：

アプリケーション (Applications)

セキュア プロトコル (Secure Protocols)

プロトコル セキュリティ サービス (Protocol Security Services)

長期鍵サービス (Long Term Key Services)

暗号化サービス (Cryptographic Services)

暗号化プリミティブ (Cryptographic Primitives)

システム セキュリティ 実装サービス (System

Security Enabling Services)

(識別 (Identification)、

認証 (authentication)

)

セキュリティ ポリシー サービス

(Security Policy Services) (認可 (authorization))

サポート サービス (Supporting Services) (監査、ディレクトリ、時間 (audit, directory,

time))

164

APKI に関する作業は 1994 年に開始された。その当時では必要な API およびプロトコルの多くはドラフト段階かまたは存在していなかった。APKI は 1999 年 3 月に作成が完了しリリースされた。その仕様書は Open Group の文書番号 G801 で、ISBN は 1-85912-221-3 である。また、HTML 形式のものが次の URLでアクセスできる： http://www.opengroup.org/pubs/catalog/g801.htm . APKIのぞれぞれのレイヤーに対するリリース済みの標準は次の図で示される：

アプリケーション (Applications)

セキュアセキュアセキュアセキュア プロトコルプロトコルプロトコルプロトコル ( ( ( (Secure ProtocolSecure ProtocolSecure ProtocolSecure Protocols)s)s)s) IETF IPSec, IKE インタフェース : セキュア プロトコル (secureprotocol) 毎にそれぞれのインタフェースを持つ。

プロトコルプロトコルプロトコルプロトコル セキュリティセキュリティセキュリティセキュリティ サービスサービスサービスサービス ( ( ( (ProtocolProtocolProtocolProtocolSecurity ServiceSecurity ServiceSecurity ServiceSecurity Services)s)s)s) プロトコル : マルチプロトコル (Multipleprotocols) が必要。 API: セッション型 (Session oriented) – IETFGSS-API, 蓄積交換型 (Store and forward) および 否 認 防 止 (Non-Repudiation) – IETFIDUP-GSS-API プロファイル: 開発が必要。 ネゴシエーション: RFC 2478 で定義された IETFGSS-API

長期鍵サービス長期鍵サービス長期鍵サービス長期鍵サービス ( ( ( (Long Term Key ServiceLong Term Key ServiceLong Term Key ServiceLong Term Key Services)s)s)s) プロトコル: IETF PKIX ファミリー API: CSSM/CDSA プロファイル: IETF PKIX (RFC 2459, 2527)

暗号化サービス暗号化サービス暗号化サービス暗号化サービス ( ( ( (Cryptographic ServiceCryptographic ServiceCryptographic ServiceCryptographic Services)s)s)s) API: CDSA/CSSM API プロファイル:特定の PKI 環境 (CORBA, DCE,Financial, など) のために開発が必要。

暗号化プリミティブ暗号化プリミティブ暗号化プリミティブ暗号化プリミティブ ( ( ( (Cryptographic PrimitiveCryptographic PrimitiveCryptographic PrimitiveCryptographic Primitives)s)s)s) API: CSSM および他の暗号アルゴリズム (RSA,DH, DES, AES, など) Profiles: 依然、必要。(Still Needed)

システムシステムシステムシステムセキュリセキュリセキュリセキュリティ実装ティ実装ティ実装ティ実装サービスサービスサービスサービス((((System System System System Security Security Security Security Enabling Enabling Enabling Enabling ServicesServicesServicesServices) ) ) ) (((( 識 別識 別識 別識 別((((identityidentityidentityidentity))))、 認 証、 認 証、 認 証、 認 証((((authenauthenauthenauthentictictictication)ation)ation)ation)))))

セキュリティセキュリティセキュリティセキュリティ ポリシポリシポリシポリシーーーー サ ー ビ スサ ー ビ スサ ー ビ スサ ー ビ ス((((Security PolicySecurity PolicySecurity PolicySecurity PolicyServiceServiceServiceServices)s)s)s) ((((認可認可認可認可 ( ( ( (authorizationauthorizationauthorizationauthorization)))))))) プロトコル: ANSI X9,OSF DCE, SESAMEお よ び OMGCORBASEC に よ る権 限 属 性 標 準(privilege attributestandards) により定義。

サポートサポートサポートサポート サービスサービスサービスサービス((((Supporting ServicesSupporting ServicesSupporting ServicesSupporting Services)))) プ ロ ト コ ル : IETFSNTP (time) API: Open GroupXDAS ( 分 散 監 査(distributed Audit)) LDAP API (directory) プロファイル : OpenGroup および IETFLDAP の プロフィル

165

必要な機能の全てが実装されているわけではない。特にシステム セキュリティ 実装サービス (System Security Enabling Services) は空になっている。これは標準に対する明確な選択がされていないためであり、部分的な理由としてこれを実現する多くの標準が存在するためである。これらのサービスは通常 OSによって、また場合によってはアプリケーションによって実装されている。 APKI 標準化の現在の作業状況は 1999年 3 月時点の標準化正式発表以降、進展はない。Open Group はAPKI改訂に対する当面の計画を立てていないが、一方、Open Group の幾人かのメンバーは自分達の目的に合うように拡張を行っている。APKI の 成果がセキュリティ パターン (security patterns)iiii に関する Open Group の現在の作業へと繋がっている。 名前名前名前名前 Architecture for Public-Key Infrastructure 公開情報公開情報公開情報公開情報 ISBN 1-85912-221-3、Open Group 文書番号 G801 発行日発行日発行日発行日 1999年 3月 改版履歴改版履歴改版履歴改版履歴 改版なし 推進団体推進団体推進団体推進団体 Open Group, www.opengroup.org 著者著者著者著者 Anne Anderson, Hewlett-Packard Company

Charles Blauner, JP Morgan & Co. Inc. Belinda Fairthorne, Fujitsu-ICL Warwick Ford Robert Jueneman, Novell, Inc. Ellen McDermott, Open Market Howard Melman, formerly OSF Denis Pinkas, Groupe Bull Walt Tuvell, formerly OSF John Wray, Compaq Computer Corporation

入手方法入手方法入手方法入手方法 http://www.opengroup.org/pubs/catalog/g801.htm

5.2 PKCS#11 (Public-Key Cryptography Standard) PKCS #11 (Public-Key Cryptography Standards) は RSA Securityによって作成、管理されている一連の標準の一つである。RSA Security は標準化団体ではないが、PKCS標準ファミリーの作成および修正において外部からの参加を受け入れている。 PKCS#11、別名 Cryptoki (Cryptographic Token Interfaceの略) は、ハードウェア装置やスマートカード (smart card) のようなトークン (token) で用いられる強力な暗号鍵 (cryptographic key) や証明書 (certificate) のためのアーキテクチャを定義すると同時にそのインタフェースを規定する。スマートカードに加えて、PKCS#11 はディスクや PCMCIAカードのような別のタイプのハードウェアで動作するように設計されている。PKCS#11 はアプリケーションと OSの両方に独立した形で設計されている。それは、アプリケーション開発者からハードウェア固有の差異を隠蔽するような低レベルのプログラミング インタフェースを提供する。この APIを用いるアプリケーションはそれらが通信するハードウェアがどのタイプであるかを認識する必要がない。

iiii 用語の簡単な解説を付録7. 用語のセキュリティ パターン (Security Patterns) に載せておいたので、こちらを参照。

166

PKCS#11 は 1994年 1月 12日、スマートカードの iPower シリーズに関する National Semiconductorの発表と併せて、RSA Security によって公開された。最終バージョン 1.0の標準はそれから 1年と少し後の 1995年 4月 28日にリリースされた。この版およびそれ以降の版は全て RSA Securityのサイトである次の URLで入手可能である： http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html . PKCS#11 のバージョン 1 は非常に成功し、この種の標準としては最初のものとなった。そして、その適用によりどこを改良すべきかが明確になった。ここでの改良が約 2 年後には抜本的な改版へとつながり、バージョン 1では 132ページであった仕様書がバージョン 2では 2倍以上のページ数に膨れ上がった。バージョン 2は、ドラフト 1が 1997年 4月 15日に、ドラフト 2が 1997年 7月 1日と、1997年に 2つのドラフトがリリースされた。両方のドラフトは共に最終版標準としてリリースされたものではなく、公式にサポートされなかった。最終的には、最終版として PKCS#11 バージョン 2.01 が 1997 年 12 月 22 日にリリースされた。 バージョン 2.01 では、C++プログラム言語、および、バージョン 1で含まれなかった新しい多くのアルゴリズムをサポートするために、付加機能が追加された。 バージョン 2.10は 1999年 12月にリリースされた。 PKCS#11の最新版は 2.11であるが、これは 2001年末に完成した。バージョン 2.11では付加アルゴリズムをサポートしている。下の表はバージョン 1、2.01、2.11の 3つの版でサポートされているアルゴリズムおよび関数の比較を示したものである。

PKCS #11 v1 PKCS #11 v2.01 PKCS #11 v2.11 公開鍵アルゴリズ公開鍵アルゴリズ公開鍵アルゴリズ公開鍵アルゴリズムムムム ( ( ( (Public/Private Public/Private Public/Private Public/Private Key AlgorithmKey AlgorithmKey AlgorithmKey Algorithm))))

RSA, DSA, DH RSA, DSA, ECDSA, DH, KEA

RSA, DSA, ECDSA, DH, X9.42, KEA

秘密鍵アルゴリズ秘密鍵アルゴリズ秘密鍵アルゴリズ秘密鍵アルゴリズムムムム ( ( ( (Secret Key Secret Key Secret Key Secret Key AlgorithmAlgorithmAlgorithmAlgorithm))))

RC2, RC4, DES, DES2, DES3

RC2, RC4, RC5, DES, DES2, DES3, CAST, CAST3, CAST128, IDEA, CDMF, SKIPJACK, BATON, JUNIPER

RC2, RC4, RC5, AES, DES, DES2, DES3, CAST, CAST3, CAST128, IDEA, CDMF, SKIPJACK, BATON, JUNIPER

ハ ッ シ ュ 関 数ハ ッ シ ュ 関 数ハ ッ シ ュ 関 数ハ ッ シ ュ 関 数((((Hash FunctionHash FunctionHash FunctionHash Function))))

MD2, MD5, SHA-1 MD2, MD5, SHA-1, FASTHASH

MD2, MD5, SHA-1, FASTHASH

バージョン 2.01 で追加された KEA および SKIPJAZCK は 米国政府のキー エスクロー アルゴリズム集に含まれている点に注意。バージョン 2.11 での重要な変更点は ANSI x9.42 と AES (Advanced Encryption Standard) のサポートである。バージョン 2.11は現在、373ページにのぼり、標準アルゴリズムを多くサポートするなど付加機能が加えられている。 2001年 8月にはバージョン 2.11 に対する改版が提案された。この改版では PTD (Personal Trust Devices) と呼ばれる付加装置のサポートが提案された。そこでは PTDを単独ユーザが常時携帯、管理、利用し、高度なセキュリティ機能を有する装置として定義されている。この装置は所有者を認証するためにユーザ入力をサポートする必要もある。このような装置の例には PDAや携帯電話が含まれている。 PKCS#11 の全ての仕様が完全に実装されている訳ではない、ということに注意が必要である。仕様をフレームワークとして使う場合、ハードウェアまたはソフトウェアに含まれる機能のサポートのみを実装する傾向があるからである。同様に仕様に含まれるアルゴリズムのサブセットのみをサポートする傾向もある。

167

名前名前名前名前 PKCS #11: Cryptographic Token Interface Standard 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 1995年 4月 28日 改版履歴改版履歴改版履歴改版履歴 Version 2.01, 1987年 12月

Version 2.10, 1999年 12月 Version 2.11, 2001年 6月

推進団体推進団体推進団体推進団体 RSA Security 著者著者著者著者 Richard Ankney, Fischer International

Ashar Aziz, Sun Microsystems Inc. Ali Bahreman, Bellcore Frank Balluffi, Bankers Trust Sara Bitan, RadGaurd LTD. Eric Blossom, COMSEC Partners John C. Brainard, Security Dynamics Liudvikas Bukys, University of Rochester Steve Burnett, RSA Data Security, Inc. Victor Chang, RSA Data Security, Inc. Bruno Couillard, EMCON Ltd. Greg Dunn, Telequip Corp. Steve Dussé, RSA Data Security, Inc. Alan Eldridge, IRIS Associates Mark H. Etzel, AT&T Bell Laboratories Bill Fox, National Semiconductor Hazem Hassan, Datakey, Inc. Thomas C. Jones, ViaCrypt John Kennedy, Cylink Larry Kilgallen, LJK Software Kevin Kingdon, Novell Scott Lindsay, Mobius Roland Lockhart, BNR Hoa Ly, RSA Data Security, Inc. Thi Nguyen, Secure Communications Inc. Denis Pinkas, Bull Jim Press, ICL P. Rajaram, Bellcore William Rohland, Datakey, Inc. Andrew Ryan, SmartDiskette Limited Paul Schlyter, AU System Wolfgang Schneider, GMD Stephen Seal, CRYPTOCard Don Stephenson, Sun Microsystems, Inc. Bruno Struif, GMD Mandan M. Valluri, National Semiconductor Charlie Watt, SecureWare David E. Wood, DataKey, Inc. Richard R.D. Young, BNR Arthur Zachai, representing Telequip Corp. Neal Ziring, NSA

168

入手方法入手方法入手方法入手方法 http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html

5.3 GCS-API (Generic Cryptographic Services API) GCS-API は X/Open 仮仕様書として X/Open (現在の Open Group) により 1996年 6月にリリースされた。この仕様書に対する Open Group 文書番号は P442 であり、 ISBN は 1-85912-195-0 である。この仕様書は現在、Open Group から http://www.opengroup.org/publications/catalog/p442.htm の URLにより、ハードコピーのみが入手可能となっている。 この標準は 3つのセクションにより構造化されている。第 1節は基本暗号化関数を規定する。第 2節セクションは鍵管理を含む上位関数を記述する。第 3 セクションは一連の付録から成る。これらの付録には仕様の実装例が含まれている。関数は全て C言語シンタックスを用いて記述、規定されている。 GCS-API 標準は X/Open の監督の下、セキュリティ ワーキング グループにより作成された。参加メンバーは大規模システム ベンダー、セキュリティ会社、政府関係機関から構成されている。CGS-API 仮仕様書には仕様実装に対する最小要求事項を規定する準拠事項 (12章) を含んでいる。 GCS-API は X/Open Distributed Security Framework お よ び NIST が 提 案 す る FIPS-Cryptographic Service Calls 仕様を使うことにより恩恵を得ている。 IBM Corporation および ANSI X9F1 委員会もまた重要な貢献を果たしている。 MISPC プログラムの一環として、U.S. NIST は GCS-API のリファレンス実装の開発を行った。詳細は次の URLを参照のこと： http://csrc.nist.gov/pki/mispc/refimp/referenc.htm 。 名前名前名前名前 Generic Cryptographic Services API 公開情報公開情報公開情報公開情報 ISBN 1-85912-195-0, Open Group 文書番号 P442 発行日発行日発行日発行日 1996年 6月 改版履歴改版履歴改版履歴改版履歴 改版なし 推進団体推進団体推進団体推進団体 Open Group, www.opengroup.org 著者著者著者著者 BULL, S.A.

Hewlett Packard International Business Machines Corporation (IBM) International Computers Limited (ICL) USA National Institute of Standards and Technology (NIST) USA National Security Agency (NSA) Olivetti Systems and Networks s.r.l OpenVision Siemens Nixdorf Trusted Information Systems, Inc Fischer International RSA Data Security, Inc

入手方法入手方法入手方法入手方法 http://www.opengroup.org/publications/catalog/p442.htm

169

5.4 CDSA 2.0 (Common Data Security Architecture) CDSA 2.0 標準は 1999 年 12 月、 Open Group より技術標準 (テクニカル スタンダード) として、“Common Security: CDSA and CSSM, Version 2” というタイトルでリリースされた。 この仕様書はOpen Group 文書番号 C902、 ISBN 1-85912-236-1 として出版されている。CDSA は幾つかの暗号、鍵、証明書管理の APIの結合と進化により開発された。この作業は Open Group のセキュリティ プログラム グループのサブセットである PKI タスクグループのメンバーによる活動である。 GCS-API が完了するとほぼ同時に、鍵および証明書の管理と暗号化サービスをサポートする新しい標準APIの必要性が高まった。この作業は Open Group と Intel Corporation がそれぞれ個別に活動を開始した。Intel は Microsoft と協力し Microsoft Crypto API (MS-CAPI) の第１版を作成し、さらにこれを拡張し付加機能を付けたいと考えた。 ここで Intel が CDSA (Common Data Security Architecture) と呼ばれる独自の暗号 APIの開発を始めるにあたり、 Microsoft から多大な協力を受けていることに注意されたい。というのも、広く普及した最初の版が CDSA のバージョン 1.2だからである。 これとほぼ同時期、 Open Group は幾つかの APIを評価しており、それぞれの APIの最良点をひとつのAPIに統合したいと考えていた。候補となった APIには Nortel の CMS-API と NSA の CM API があげられる。1997 年夏の間に、これら 2 つの API が暫定 API としてまとめられた。この暫定 API は後に CDSA 1.2 に統合され、CDSA 2.0 が作成されることになる。この 2社以外に、IBM、TIS、Netscape、日立、Hewlett Packard、Motorola、NIST、Apple が CDSA 2.0に対して重要な貢献をしている。 CDSA は概ね下の図で示された発展を経ている：

Apple Computer は CDSAを AppleのMac X という OSに組み込むことにより、CDSA開発の最終段階で多大な貢献をしている。このプロセスの間に Apple が発見したエラーは全て修正されている。Apple、IBM、その他の企業による修正の結果として、正誤表がリリースされた。この修正は 2000 年 5 月の標準に統合され、CDSA 2.3としてリリースされている。さらに、仕様は重複を削除し使いやすいように再構成された。この仕様書に対しては新しい文書番号(C914) と ISBN (1-85912-202-7) が付けられている。 名前名前名前名前 Common Security: CDSA and CSSM, Version 2.3 公開情報公開情報公開情報公開情報 ISBN 1-85912-202-7, Open Group 文書番号 C914

Intel CDSA 1.2

Nortel CMS-API

NSA CM API

暫定版 (Interim) CM API

Open Group CDSA 2.0, 2.3

他の技術的な貢献団体: Apple, IBM, TIS, Netscape, 日立, HP, Motorola, NIST

170

発行日発行日発行日発行日 2000年 5月 改版履歴改版履歴改版履歴改版履歴 Common Security: CDSA and CSSM, Version 2, 1999年12月, ISBN

1-85912-236-1, Open Group 文書番号 C902 Common Security: CDSA and CSSM, Version 2.3, 2000 年 5 月, Open Group 文書番号 C914, ISBN 1-85912-202-7

推進団体推進団体推進団体推進団体 Open Group, www.opengroup.org 著者著者著者著者 Intel Architecture Labs, Intel Corporation

Apple Computer Corporation IBM Corporation (IBM) Entrust Hewlett-Packard Motorola Netscape Sun Microsystems Trusted Information Systems, Inc.

入手情報入手情報入手情報入手情報 http://www.opengroup.org/publications/catalog/c914.htm 2000 年 5 月、Intel もオープンソースのリファレンス実装をリリースし、次の URL で入手可能である： http://developer.intel.com/ial/security/index.htm IntelはまたCDSA準拠テスト スイート (conformance test suite) も提供している。Intelはこのリファレンス実装をWindowsおよび Linux環境に対して開発している。Intelの CDSAリファレンス プラットフォームのライセンスを受けた他の企業では次のような環境に対するバージョンを開発している：

組織組織組織組織 CDSA CDSA CDSA CDSA 適用適用適用適用 Apple Mac OS Bull Linux Compaq UNIX Hewlett-Packard HP-UX IBM Corporation OS/390, OS/400, AIX Cylink PKI Toolkit Motorola PKI Toolkit Baltimore Technologies PKI Toolkit

さらに、Bull、Caldera、Intel は Intel の Itanium プロセッサを用いて 64 ビット最適化された Linux版を作成した。この版は大規模サーバ市場に向けたものである。 IBM は IBM の拡張 KeyWorks セキュリティ ソリューションにおいて CDSA を用いている。IBM の PKIX 実装と結合した KeyWorks は、APKIで規定されるガイドラインに沿って実装されている。

171

5.5 CDSA/HRS (Common Data Security Architecture/Human Recognition Services) HRS は暗号的にバイオメトリック データを保護するために作成された。HRS は元々、ユーザ認証サービス (UAS: User Authentication Services)と呼ばれ、1998 年初期に開発された。また、それは CSSM (Common Security Services Manager) における EMM (Elective Module Manager) を用いた、CDSA フレームワークへのプラグイン モジュールとして設計されていた。HRS は BioAPI をサポートするスタンドアロン版と並行して開発されている。 HRS はアプリケーション開発者とバイオメトリック技術開発者によって利用されることを想定して設計されている。CDSAと組み合わせることにより、識別 (identification) および認証 (authentication) サービスを提供することができる。 Intel Corporation の John Wilson は Open Group の HRS API と BioAPI Consortium の 2つの版の両方で技術編集を担当していたため、両方の整合性を保つことができた。HRS のバージョン 2は 2001年6月に Open Group テクニカル スタンダードとして正式リリースされている。 HRS v2 は 2000年 3月 20日にバージョン 1.0.8 としてリリースされた BioAPI Consortium による過去の作業をベースにしている。 名前名前名前名前 CDSA/CSSM Authentication: Human Recognition Service (HRS)

API, Version 2 公開情報公開情報公開情報公開情報 Open Group 文書番号 C013 発行日発行日発行日発行日 2001年 6月 改版履歴改版履歴改版履歴改版履歴 改版なし 推進団体推進団体推進団体推進団体 Open Group, www.opengroup.org 著者著者著者著者 John Wilson, Intel

Members of the BioAPI Consortium (BioAPIのリスト参照) 入手方法入手方法入手方法入手方法 http://www.opengroup.org/publications/catalog/c013.htm 詳細な情報はこの資料中、BioAPI Consortium がリリースした BioAPIの項に書かれている。

5.6 BioAPI BioAPI Consortium はバイオメトリック データ用の APIを作成するために 1998年に設立された。1999年、HA-API (Human Authentication API) と呼ばれる同様の API に対する活動を行っている BAPI (Biometric API) ワーキング グループ と BioAPI Consortiumが合併された。 HA-API は元々、米国政府との契約により開発されたものである。米国 NIST がこの API の開発にあたって積極的な役割を果たしている。この合併により BioAPI という名の下でこれら 2つの APIの最適な部分が結合することになった。 同時に、BAPI ワーキング グループからのメンバーを加えて、BioAPI Consortium が再編成された。

172

これとほぼ同時期に、Open Group は BioAPI Consortium と協同で作業を開始し、後に HRS API と呼ばれる APIを開発した。HRS API は現在、BioAPI の一部として統合されている。 BioAPI のある部分は以下の APIに由来している：

• HA-API version 2.0, 1998年 4月 22日 • HA-API version 2.02 extensions, 1999年 2月 17日 • Draft BIOAPI Reference Manual, 1999年 2月 25日 • BAPI SDK Version 1.1 High Level API – Level 3, 1998年 6月 1日 • Draft BioAPI/UAS Specification 1.0 Version 1.2 Release, 1999年 4月

BioAPI の仕様は前述した Open Group の HRS 仕様と似ている。BioAPI の関数が BioAPIというプレフィックスで始まるのと同様に、HRSの関数は CSSM_HRS というプレフィックスで始まる。 名前名前名前名前 BioAPI Specification Version 1.1 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 2001年 3月 16日 改版履歴改版履歴改版履歴改版履歴 BioAPI Specification Version 1.0, 2000年 3月 30日

BioAPI Specification Version 1.1, 2001年 3月 16日 推進団体推進団体推進団体推進団体 The BioAPI Consortium 著者著者著者著者 SAFLINK Corporation, Cathy Tilton, Chair

Unisys Corporation, Fred Herr, Secretary Intel, John Wilson, Technical Editor Compaq Computer Corp., Manny Novoa Iridian Technologies, James Cambier Treasurer NIST, Fernando Podio Mytec Technologies, Inc., Colin Soutar

入手方法入手方法入手方法入手方法 http://www.bioapi.com/BioAPI_home.htm BioAPI は幾つかの組織の作業を併合したものであり、バイオメトリック データ (biometric data) に対する現在入手可能な唯一の標準 APIとなっている。

5.7 GSS-API (General Security Service API) GSS-API は IETF (Internet Engineering Task Force) によって発表された。IETF はその兄弟組織にあたる IRTF (Internet Research Task Force) と共に Internet Society (ISOC) が設立した Internet Architecture Board (IAB) によって管理運営されている。 IETF の組織は 8つのエリアに分かれている。 新しい標準が必要になった場合、適切なエリアにおいてワーキング グループ (WG) が新設される。ワーキング グループは一時的なものと見なされており、活動終了と共に解散される。タスクの難易度がワーキング グループの寿命を左右しており、10年以上続いているワーキンググループもあれば、2年で終わるワーキング グループもある。ワーキング グループは成果を RFC (Request For Comments) 文書として公開する。作業は一連のドラフト文書により進捗管理される。つまり、それぞれにドラフト RFC番号が割り振られ、最終的に RFCとしてリリースされる。ワーキング グループは通常、年 3回開催される IETFミーティングの一つの期間中に、 BoF (Birds of a Feather、類は友を呼ぶ) セッションとして開始される。ワ

173

ーキング グループにおける実際の執筆および他の活動のほとんどは E メールのメーリングリストを通じてオンラインで行われる。IETF ミーティングは審議、非公式調査、情報発表の説明の場として運営されている。 IETF によるほとんどの作業はインターネット プロトコルの作成にさかれている。API は例外であり、必要が生じた時に作成されている。必ずではないが大抵の場合、IETFが策定したセキュリティ関連標準はIETF のセキュリティ エリアに割り当てられる。GSS-API は CAT (Common Authentication Technology) ワーキング グループのメンバーにより策定された。 CAT ワーキング グループは最古の IETF ワーキング グループの一つである。このワーキング グループの主目的は相互運用可能な分散セキュリティ サービスの仕様を策定することである。このサービスには認証 (authentication)、完全性 (integrity)、機密性 (confidentiality) が含まれる。 GSS-API の第 1版は John Linn によって作成され、1993年 9月に完成した。バージョン 2も John Linn が作成し、1997年 1月に完成した。バージョン 2 はバージョン 1に対する付加的な更新であり、バージョン 1 実装の経験から必要とされた変更を元にしている。バージョン 2 のページ数はバージョン 1 の 50ページの 2倍近い約 90ページにものぼる。RFC 2743 で記述された最新版は、John Linn によって作成され 2000年 1月にリリースされた。この版は GSS-API Version 2, Update 1 と呼ばれ、100ページ強の分量になっている。また、前の版に対する小さく付加的な修正にとどまっている。 名前名前名前名前 Generic Security Service Application Program Interface 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 2000年 1月 改版履歴改版履歴改版履歴改版履歴 GSS-API, RFC 1508, 1993年 9月, John Linn

GSS-API v2, RFC 2078, 1997年 1月, John Linn GSS-API v2 update 1, RFC 2743, 2000年 1月, John Linn

推進団体推進団体推進団体推進団体 The Internet Engineering Task Force, www.ietf.org 著者著者著者著者 John Linn 入手方法入手方法入手方法入手方法 http://ietf.org/rfc/rfc2743.txt GSS-API の 2つの改版のリリースに加えて、CAT ワーキング グループは関連する多くの RFCのリリースも行った。CAT ワーキング グループと他の IETFワーキング グループにおける新しい RFCはいまだに GSS-APIを参照ないし依存している。 GSS-API は API内部で利用している特定のセキュイティ機構とは独立しているため、GSS-APIを用いながらこれとは別の特定の機構をどのように使用するかを記述する、幾つかのより低レベルの仕様がリリースされている。GSS-API はまたプログラミング言語独立であり、GSS-API に対する異なる言語バインディング (言語実装) を記述する RFCがリリースされている。 John Linn が作成し 1996 年 6 月にリリースした RFC 1964 は Kerberos バージョン 5 技術を用いてGSS-API をどのように実装するかを記述している。この RFC の大半は GSS-API 実装時に使用されるべき Kerberos のトークンと名前フォーマットを記述している。 Carlisle Adams が作成し 1996 年 10 月にリリースした RFC 2025 は SPKM (Simple Public-Key Mechanism) を用いてGSS-APIを実装する際に従うべき用法と手続きを記述している。SPKM データ フォーマットは実装を容易にするために Kerberosのデータ フォーマットとできる限り同じに設計できるように規定されている。

174

E. Baize と Denis Pinkas が作成し 1998年 12月にリリースした RFC 2478 は GSS-API用のセキュリティ ネゴシエーション メカニズム (security negotiation mechanism) を記述している。Simple and Protected GSS-API Negotiation Mechanism と呼ばれるこのこのメカニズムは、共通のメカニズムで同意するまでの間、お互いをネゴシエート (negotiate) する複数のセキュリティ メカニズムを利用する様々なGSS-APIの実装を可能にする。 GSS-API の C 言語実装は RFC 2744 で、Java 言語実装が RFC 2853 でそれぞれ記述されている。 SASL (Simple Authentication and Security Layer) で GSS-API を用いるドラフトが 2002年 1月現在、CAT ワーキング グループで作業中である。

5.8 IDUP-GSS-API (Individual Data Unit Protection – Generic Security Service API) IDUP-GSS-API は GSS-API を拡張し、データの保護を提供する。GSS-API がセッション情報の保護を目的としているのに対し、IDUP-GSS-API はファイルや E メール メッセージのような個別データ ユニット (individual data units) に保護を適用する。保護には発信元認証 (data origin authentication)、データ完全性保護 (data integrity protection)、データ機密性保護 (data confidentiality protection) が含まれている。 IDUP-GSS-API は IETF の CAT ワーキング グループにより作成された。本項の GSS-APIに関する説明のように、CAT ワーキング グループは IETF の セキュリティ エリアに属している。仕様は 1998年12月にリリースされた RFC 2479 に記述されている。このリリース以降、IDUP-GSS-API に対する改版は出されておらず、これに置き換わる最新版のドラフトは存在していない。 GSS-API と同様に、IDUP-GSS-API はメカニズムから独立しており、別のセキュリティ メカニズムで実装できるような汎用レベルでセキュリティ サービスのセットを記述している。これには公開鍵または秘密鍵システムが含まれる。IDUP-GSS-API はプロトコルからも独立しており、広範囲な環境で利用することができる。 IDUP-GSS-API は GSS-API を参照しており、クレデンシャル (credentials)、トークン、ネーミング、および、セキュリティ メカニズム タイプの記述を GSS-APIに依存している。これら 2つの APIの利用環境における差が生じており、 IDUP-GSS-API が提供する保護を個別データ ユニット に結びつけているのに対し、 GSS-API はセッションや 2点間のセキュリティ アソシエーション (security association) に結びつけている。 名前名前名前名前 Independent Data Unit Protection Generic Security Service

Application Program Interface 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 1998年 12月 改版履歴改版履歴改版履歴改版履歴 改版なし 推進団体推進団体推進団体推進団体 The Internet Engineering Task Force, www.ietf.org 著者著者著者著者 Carlisle Adams, Entrust Technologies 入手方法入手方法入手方法入手方法 http://ietf.org/rfc/rfc2479.txt

175

IDUP-GSS-API は標準 RFC (standard RFC) ではなく、インフォメーショナル RFC (informational RFC) としてリリースされている。

5.9 XGSS-API (Extended GSS-API) XGSS-API 、すなわち、Extended GSS-API の最新版は Denis Pinkas と Tom Parker が１９９８年に書いたインターネット ドラフトをベースにしている。初版は 1995 年 11 月に公開された。ドラフトは GSS-API に 2つの付加機能を追加することにより GSS-APIを拡張している。 この 2つの機能の内、第 1の機能は複数のセキュリティ属性 (multiple security attributes) をサポートする。XGSS ドラフトはセキュリティ属性の異なるタイプをベースにして認可 (authorizations) をどのように行うかを規定している。 第 2の付加機能は、セキュリティ コンテキスト (security context) を受け入れ、権限委譲 (delegation) に対して他の制限を可能とするような権限委譲法の仕様を規定することにより、さらに細かな権限委譲の管理を行うことができる。 XGSS ドラフトは 1998年に IETF の CAT ワーキング グループに提出された。IETF ドラフトは RFC として採用されるか、または、次の改版がリリースされない限り、6ヵ月後に自動的に失効される。XGSS ドラフトは 1999 年 5 月 9 日に失効した。失効したドラフトは IETF の Web サイトには保持されていないが、XGSS-API ドラフトのバージョン 3 (最終版) のコピーを現在、次の URLで参照することができる： http://globecom.net/ietf/draft/draft-ietf-cat-xgssapi-acc-cntrl-03.html 。 XGSS-API ドラフト、後述の GAA-APIおよび aznAPIの 3つの APIが提供する機能の間には、幾つかの関連と重複が存在する。1998年における XGSS-APIと GAA-APIの比較においてはこれらが補完的であるとみなされている。 米国 NSA (National Security Agency) から資金提供を受け、イリノイ大学アーバナ-シャンペイン校 (UIUC、University of Illinois at Urbana-Champaign) で開発された、Nephilim という Java ベースの SESAME 実装では、SESAME セキュリティ メカニズムを実装するために GSS-API と XGSS-API 拡張の両方を用いている。 このドラフトにはこれまでに 4つの版が存在し、最新版は 1998年 11月にリリースされたバージョン 3である。これらのバージョン間での変更は、あったとしても非常に小さなものである。新しいドラフトをリリースする理由は、IETF における CAT ワーキング グループの注意を引いて更なる議論を引き起こすためである。 名前名前名前名前 Extended Generic Security Service APIs: XGSS-APIs Access

Control and Delegation Extensions 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 XGSS-API Version 0, 1995年 11月 21日

XGSS-API Version 1, 1996年 7月 5日 XGSS-API, Version 3, 1998年 11月 9日

改版履歴改版履歴改版履歴改版履歴 XGSS-API V3 9 November 1998

176

推進団体推進団体推進団体推進団体 The Internet Engineering Task Force, www.ietf.org 著者著者著者著者 Tom Parker and Denis Pinkas 入手方法入手方法入手方法入手方法 http://globecom.net/ietf/draft/draft-ietf-cat-xgssapi-acc-cntrl-03.html

5.10 GAA-API (Generic Authorization and Access Control) API GAA-API はアプリケーションによる認可判定 (authorization decisions) を奨励するように設計されている。アプリケーションは GAA-API 関数を用いて、要求されたアクションが認可されるかどうか判断し、さらに、特定のリソースに関する付加的なアクセス管理情報を要求することができる GAA-API 策定作業は南カリフォルニア大学情報科学研究所 (the Information Sciences Institute of the University of Southern California) により GOST (Global Operating Systems Technology) グループの一部として始まった。この活動により 2つのインターネット ドラフトが作成され、後に IETF の CAT ワーキング グループに提出された。現在までに、それぞれのドラフトに対して 6つの版が作成されている。メインのドラフトがアクセス管理フレームワーク (access control framework) を記述し、もう一つのドラフトが GAA-API実装のための C言語実装を規定している。 南カリフォルニア大学 (the University of Southern California) のサイトでは GAA-API プロジェクトに関する Web ページを次の URL で提供している： http://www.isi.edu/gost/info/gaaapi/gaa_api.html 。ドラフト仕様を策定するのに加えて、GAA-APIのリファレンス実装を利用可能にしている。GAA-APIの最新版は v0.6.2 である。 XGSS-API と同じように GAA-API は最終版 RFC (finished RFC) としてリリースされていない。またXGSS-APIと同様に、GAA-API は他のプロジェクトや論文で参照も利用もされてきていない。 名前名前名前名前 Generic Authorization and Access Control API (GAA-API) 公開情報公開情報公開情報公開情報 発行日発行日発行日発行日 2000年 11月 22日 改版履歴改版履歴改版履歴改版履歴 draft-ietf-cat-acc-cntrl-frmw-00.txt, 1998年 8月 7日

draft-ietf-cat-acc-cntrl-frmw-01.txt, 1998年 11月 17b日 draft-ietf-cat-acc-cntrl-frmw-02.txt, 1999年 6月 23日 draft-ietf-cat-acc-cntrl-frmw-03.txt, 2000年 3月 9日 draft-ietf-cat-acc-cntrl-frmw-04.txt, 2000年 7月 11日 draft-ietf-cat-acc-cntrl-frmw-05.txt, 2000年 11月 22日 draft-ietf-cat-gaa-cbind-00.txt, 1998年 8月 7日 draft-ietf-cat-gaa-cbind-01.txt, 1998年 11月 17日 draft-ietf-cat-gaa-cbind-02.txt, 1999年 6月 24日 draft-ietf-cat-gaa-cbind-03.txt, 2000年 3月 9日 draft-ietf-cat-gaa-cbind-04.txt, 2000年 7月 11日 draft-ietf-cat-gaa-cbind-05.txt, 2000年 11月 22日

推進団体推進団体推進団体推進団体 IETF (The Internet Engineering Task Force), www.ietf.org 著者著者著者著者 Tatyana Ryutov and Clifford Neuman 入手方法入手方法入手方法入手方法 http://www.isi.edu/gost/info/gaaapi/doc/doc.html

177

5.11 aznAPI (Advanced Authorization API) Authorization (AZN) API (以降、aznAPIと表記) は Open Group により Open Group テクニカル スタンダードとして 2000年 1月に公開された。この認可 API (Authorization API) に関する作業は 1997年後半に Open Group で始まった。 Open Group の セキュリティ プログラム グループの幾つかは有名な DCE (Distributed Computing Environment) および CORBA (Common Object Request Broker Architecture) のセキュリティおよび認可モデルで有名な、他の認可イニシアチブと関係を持っている。 aznAPI の開発と並行して、 DASCOM は認可製品を開発していた。これにより、APIの機能がテストされ、これに合うように API が調整されるという効果を生んだ。DASCOM Corporation は後に IBM のTivoli 部門に吸収されている。 aznAPI を開発した Open Group のメンバーは IETFで作成されたXGSS-API および GAA-API の成果を利用することもできた。 aznAPI の目標はセキュリティ コンポーネント プロバイダが認可機能を呼び出すことができ、かつ、アプリケーション開発者がセキュリティ実装製品 (security aware applications) を開発するのに利用できる、単純なインタフェースを定義することである。また、認可サービスを集中管理できるように設計されている。aznAPI は ISO/IEC 10181-3 として記述されている ISO認可モデル (authorization model) に従っている。 名前名前名前名前 Authorization (AZN) API (通常は aznAPI と略記) 公開情報公開情報公開情報公開情報 ISBN 1-85912-266-3, Open Group 文書番号 C908 発行日発行日発行日発行日 2000年 1月 改版履歴改版履歴改版履歴改版履歴 推進団体推進団体推進団体推進団体 Open Group, www.opengroup.org 著者著者著者著者 Bob Blakley, DASCOM

Warwick Burrows, DASCOM Greg Clark, DASCOM Adam Murdoch, DASCOM Frank Siebenlist, DASCOM 追加の記述とレビューが次の代表者から： Hewlett-Packard Company IBM Corporation Sun Microsystems Inc. Entrust Technologies Baltimore Technologies

入手方法入手方法入手方法入手方法 http://www.opengroup.org/publications/catalog/c908.htm 現時点では、 aznAPI 仕様に対する改版は発行されていない。

178

5.12 Open Groupの組織体制に関する注記の組織体制に関する注記の組織体制に関する注記の組織体制に関する注記 Open Group は複数の標準化組織が合併してできた組織である。その第一の目的は異なるコンピュータ環境間の相互運用性である。OSF (Open Software Foundation) と X/Open の連合から始まり、1996年春に合併して Open Group となった。これ以降、 Directory Interoperability Forum と Electronic Messaging Association が Open Group に合併している。

Open Group の初期の頃は、個別のプログラム グループに分かれていた。これらのプログラム グループは特定のプロジェクトとして作業する内部的なタスク グループを作っていた。しばしばユーザ コミュニティからの代表者で構成されるタスク グループは要求仕様書を作成し、ベンダー コミュニティからのタスク グループは API、リファレンス実装のコード、他の仕様を作成していた。APKI を始めとする幾つかの仕様は当時の共同作業の成果である。 今日の Open Group は特定の技術領域に焦点を当てた個別のフォーラムに分かれている。現在の Open Group の フォーラムをあげると、アクティブ ロス防止 (Active Loss Prevention)、アーキテクチャ (Architecture)、ディレクトリ相互運用 (Directory Interoperability)、EMA (Electronic Messaging)、エンタープライズ管理 (Enterprise Management)、モバイル管理 (Mobile Management)、プラットフォーム (Platform)、QoS (Quality of Service)、リアルタイム＆組み込みシステム (Real Time & Embedded Systems)、セキュリティ (Security) となる。 Open Group はそれぞれのフォーラムが集まる年 4回のカンファレンスを開催している。最初の 2日間は通常、一般の参加者に開放され、そのテーマはある一つのフォーラムに関連している。フォーラムおよびより小さなタスク グループは、これらの会議以外の場合にしばしば電話ないし Eメールによりコミュニケーションを図っている。 Open Group メンバーは通常、大規模な国際企業から参加しており、ベンダーとカスタマの両方から構成される。このように、 Open Group はカスタマとベンダーが一緒にソリューションを作り出す場を提供している。文書が承認段階に達した時に、投票プロセスに移る。それぞれのメンバー企業には 1 票が与えられている。

Open Software Foundation

X/OPEN

1996 1998 2000

Directory Interoperability Forum

Electronic Messaging Association

179

フォーラムの活動の他に、Open Group はテストおよび認証のプログラムを有している。また、Open Group は他の企業に対する会議およびメンバーシップ サービスも提供している。

5.13 IETFの組織体制に関する注記の組織体制に関する注記の組織体制に関する注記の組織体制に関する注記 IETF (Internet Engineering Task Force) は ISOC (Internet Society) に属する。ISOC は現在、170カ国から 6000人以上のメンバーと 150 社の企業から構成されている。ISOC は IANA (Internet Assigned Numbers Authority) を通じてインターネット アドレスの管理を行い、IRTF (Internet Research Task Force) を通じて将来的なインターネット プロトコルの研究を行い、IETF を通じてインターネット プロトコルの設計を行っている。 IETF はその兄弟組織である IRTF と共に、ISOC により設立された IAB (Internet Architecture Board) の監督下にある。IAB は IESG (Internet Engineering Steering Group) を通じて IETF と連絡を取り、 IRSG (Internet Research Steering Group) を通じて IRTF と連絡を取っている。 IETF は 8つのエリアで組織されており、それぞれのエリアは IAB が任命した 1人ないし２人のエリアディレクターが議長をしている。 IESG メンバーシップはエリア役員 (Area Directors) と IAB が任命した議長 (Chair) から構成されている。8 つのエリアとは、アプリケーション (Applications)、インターネット (Internet)、運用管理 (Operations and Management)、ルーティング (Routing)、セキュリティ (Security)、サブ IP (Sub IP)、トランスポート (Transport)、ユーザ サービス (User Services) の 8つである。

Internet Society ISOC

Internet Assigned Numbers Authority

IANA

Internet Engineering Task Force

IETF

Internet Research Task Force

IRTF

Internet Architecture Board IAB

180

新しい標準に対する要求が生じた時に、ワーキング グループ (WG) が適切なエリアに新設される。ワーキング グループは一時的とみなされており、活動終了と同時に解散される。タスクの複雑さがワーキング グループの活動期間を決定している。10 年近く活動しているワーキング グループが存在する一方で、多くのワーキング グループは 2 年ほどで活動を終了する。ワーキング グループは活動成果を RFC (Request For Comments) 文書として公開する。これは一連のドラフト文書の作成から始まり、それぞれの文書にドラフト RFC番号が割り当てられ、最終的には RFCとしてリリースされる。ワーキング グループは通常、年 3回開催される IETFミーティングの一つの期間中に、 BoF (Birds of a Feather、類は友を呼ぶ) セッションとして開始される。ワーキング グループにおける実際の執筆および他の活動のほとんどは Eメールリストを通じてオフラインで行われる、IETF ミーティングは審議、非公式調査、情報発表の説明の場として運営されている。 IETF によるほとんどの作業はインターネット プロトコルの作成にさかれている。API は例外であり、必要が生じた時に作成されている。また、アーキテクチャ設計も幾つかのワーキング グループで作成されている。必ずではないが大抵の場合、IETFが策定したセキュリティ関連標準はセキュリティ エリアに割り当てられる。現在、セキュリティ エリア以外の 5 つのエリアと IRTF にセキュリティ関連のドラフトおよび RFCが存在している。IETF が作成しこの資料で取り上げられた API の全ては、CAT (Common Authentication Technology) ワーキング グループの活動の一環として作成されたものである。 Authentication, Authorization and Accounting ワーキング グループはいろいろなエリアに異動しており、現在は、運用管理エリア (Operations and Management Area) に所属している。 インターネット ドラフトは IAB および RFC 編集者に提出されてから RFC となる。標準トラックのRFC (Standards track RFCs) の場合、RFC として発行される前に、完全に相互運用可能な実装が 2つ独立して存在することが要求されている。

Internet Engineering Task Force (IETF)

Internet Engineering Steering Group (IESG)

アプリケーションエリア(Applications Area)

セ キ ュ リ テ ィ エ リ ア(Security Area)

ユーザ サービス エリア(User Services Area)

トラン スポー ト エ リア(Transport Area)

ル ー テ ィ ン グ エ リ ア(Routing Area)

運用管理エリア (Operationsand Management Area)

サブ IP エリア (Sub IP Area)イン タ ーネ ット エ リア(Internet Area)

181

IETF は時折、標準を開発するために他の組織とパートナーを組んでいる。最近、W3C (World Wide Web Consortium) と XML デジタル署名 (Digital Signature) 標準を開発するためのパートナーシップが結ばれた。

182

6.6.6.6. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの今後の動向の今後の動向の今後の動向の今後の動向 本項ではそれぞれの API に対する現状の受容レベルと将来予測について論じている。下の表は 1.4.2項で述べた今後の動向を調査する方法に基づき、そこで述べた表をカスタマイズしたものであり、5 項で調査対象にした各 APIの今後の動向をこの表を用いて評価している。ここでは、技術の成熟度を判断するのに用いており、それぞれの APIを評価した表ではその APIの特徴を示す箱に網掛けがしてある。

アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退衰退衰退衰退期期期期 市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定 減少

製品製品製品製品 なし ごく少数 重要なマーケットシェア

マーケット リーダ

減少

6.1 APKI – (Architecture for Public Key Infrastructure) APKI は、上位の PKI アーキテクチャであるため、本資料で論じる他の標準とは異なっている。製品として具体化されない可能性が高いため、APKIの成否を判断するのは非常に困難である。 APKI は多くの大規模で国際的なシステム ベンダー (Compaq, Digital Equipment Corporation, Fujitsu-ICL, Groupe Bull, Hewlett-Packard, IBM, Novell, Siemens, Sun Microsystems, など) や、多くの大規模顧客 (Boeing, Citicorp, JP Morgan, Lockheed-Martin, Shell International, など) および多くの政府関係機関 (Sweden Post, Telecom Finland, U.K. Ministry of Defense, U.S. Jet Propulsion Laboratory, U.S. Department of Defense DISA, U.S. NIST, U.S. Department of Defense NSAなど) の貢献を受けている。従って、PKI 環境をどのように体系付けし完成させるのかに対する幅広いコンセンサスを表している。1990年代後半、IBM は APKIを基に PKI セキュリティ ソリューションを体系付けし、これに対するプロファイル (profiles) と改良版の開発を継続した。TIE (Trust Infrastructure for Europe) プロジェクトは APKI を体系機構として用いている。 APKIの将来の成功と普及はこれが規定するAPIとプロトコルの モジュール性 (modularity) に依存している。APKIの主目的の一つは APIとプロトコルが提供するサービスのセットを、他のサービスに影響を受けることなしに置き換えできるように定義することである。これを達成するために、これらの APIおよびプロトコルによって分離される明確に定義されたレイヤーが必要である。SSL のような一枚岩的方式はこれらのインタフェースを隠蔽し、特定のセキュリティ サービスを置き換えることを困難または不可能に

183

している。本質的に自己完結しかつ明確に定義されたアクセス ポイントを持つ IETF PKIX プロトコルが APKI の上半分を占め、自己完結しかつ境界が明確に定義された CDSA が APKI の下半分を占める。 APKI の有用性に影響を与える第 2 の要因は確定したプロファイルの欠如である。プロファイルとは APIまたはプロトコルの標準から導かれ、利用に際して規定される選択肢を決める仕様のことである。プロファイルの利用は異なるベンダー製品間の相互運用性を高めてくれる。例えば、SMIME v2におけるプロファイルの欠如とあいまいな定義は異なるベンダーが標準に準拠しているにもかかわらず相互運用できない状態を作り出している。 最終的には異なるレイヤーの相互運用性はベンダー自身の活動に左右される。幾つかのベンダーは APKI で規定される APIを実装しているが、これらのインタフェースを外部のプログラマや他のベンダーのセキュリティ ソフトウェアにオープンにされない形で実装してしまっている。これにより、しばしば PKI 製品の全てをベンダー1社に限定させる原因となっている。 その柔軟性のおかげで、APKI は引き続き PKI ベースのセキュリティ システムのアーキテクチャを記述するのに有用であるだろう。API機能のグループ内ではメーカー独自の (プロプライエタリな) システムでさえ定義することが可能である。例えば、Microsoft の Windows 2000 は、セッション型セキュリティ (session oriented security) を提供するために、PKIプロトコルおよび (CDSAの代わりに) MS-CAPI の2つの上に位置するレイヤーで IPSec プロトコルを用いている。 APKI はセキュリティ設計アーキテクチャの一部として利用すべきである。通常、製品やセキュリティ サービスにおいて参照されるものではない。また、顧客が社内の PKI プロジェクトを構成するために使われるものでもないであろう。従って、ベンダーの製品体系においてもっとも言及されるべきものである。 また、APKI の将来的な普及は PKI 自身の成功および普及に依存している。スケール問題 (scaling)、鍵識別の制約条件 (the binding of identities to keys)、 複雑さと相互運用性の問題など、PKI に関する様々な問題は PKI セキュリティ システムの発展と普及を多大に遅らす原因となっている。 APKI を判断するのに用いた基準で述べたように、ライフサイクルの成長期にあたっているが、これは次の段階に進むであろうことを意味していない。成熟度の異なる尺度における APKI のランクについては下の表を参照のこと。

APKI アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方地方地方地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了標準化完了標準化完了標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中改善中改善中改善中 安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

184

結論結論結論結論 － APKIの改版よりも、Open Group におけるセキュリティ パターン (security patterns) 執筆に関する活動をフォローしておくべきである。APKI 自身に対する新しい版や改版がリリースされる可能性は低い。さらに PKIのコンポーネントを体系付けするのに有用なアーキテクチャは他にも存在するからである。

6.2 PKCS#11 (Public-Key Cryptography Standard) PKCS#11 は他の暗号 API (Cryptographic APIs) と比べて非常に成熟した標準である。ほとんど全てのベンダーが PKCS#11 をサポートしており、幾つかのベンダーは準拠テスト プログラム (compliance testing programs) を実施している。多くのソフトウェア アプリケーションがこのインタフェースをそれがサポートするハードウェア トークンを受け付けるメカニズムとして用いている。OCF (Open Card Framework) のような他のスマート カード標準も PKCS#11 を用いている。 ベンダーおよびサードパーティのソリューション プロバイダからのサポートに加え、RSA Security は PKCS#11 ワークショップを主催し、PKCS #11標準の普及とその機能の発展を継続している。 PKCS#11 の特徴は下の表に示されている。

PKCS#11 アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%-30% 飽和飽和飽和飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方 世界的世界的世界的世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了 標準化および標準化および標準化および標準化および改版改版改版改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い低い低い低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数 重要なマーケットシェア

マーケットマーケットマーケットマーケット リーダリーダリーダリーダ

減少

結論結論結論結論 － OS のサービスやセキュリティ アプリケーションとスマート カードや他のハードウェア トークンとのインタフェースを取るために、PKCS#11以外に現実的な選択肢は存在していない。新しい機能の追加や新しい暗号アルゴリズムの追加による定期的な改版により、最新の状態に保たれている。将来的にも強力なサポートがあり、PKCS#11に対する重要な代案は現れないであろう。

185

6.3 GCS-API (Generic Cryptographic Services API) 幾つかの実装が存在するが、新製品および新しい暗号サービスには GCS-API は推奨できない。GCS-API は PKI 技術の初期段階で開発されたものであり、新しく追加された鍵管理機能はサポートしてない。これに欠けている最も重要な機能は証明書 (certificates) のサポートである。 GCS-API 機能に対するニッチ市場は存在するかもしれないが、これには限界がある。GCS-API は暗号サービスのより完全なセットを提供する CDSA に置き換えられてしまっている。この API 作成に関する多くの作業は後の CDSA へと繋がる出発点として用いられた。 GCS-API が仮仕様から最終仕様へと発展することはなかった。 API によって記述される機能はある範囲内では明確に規定されているが、これらの API は今日の多くの要求にマッチするものではない。

GCS-API アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立孤立孤立孤立 局所 地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフ正式なドラフ正式なドラフ正式なドラフトトトト

標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い低い低い低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 – GCS-API は一般利用では推奨されない。この APIでは証明書管理 (certificate management) をサポートしていない。

6.4 CDSA 2.0/2.3 (Common Data Security Architecture) CDSA はある程度の成功を収めていると同時に、その発展速度は遅いものであった。CDSAが開発段階にある時、主要な UNIX ベンダーと専門的なセキュリティ プロバイダの幾つかから強力なサポートを受けることができた。この内、Intel、 IBM、Apple はこの技術に多大な投資を行っていた。 CDSA には APIとサービスの非常に広範囲なセットが含まれている。CDSA はプラグイン コンポーネントをサポートするアーキテクチャにより拡張可能となっている。これにより新しい技術およびアルゴリズムを追加することができる。例えば、鍵リカバリ サービス (key recovery service) は当初、プラグインとして作成された。また、バイオメトリック データ認証サービスもプラグインとして作成され、SPKI (Simple Public-Key Infrastructure) メカニズムも追加された。

186

CDSAのマイナス面は数百にものぼる関数を持つ非常に大規模なAPIということである。これはおそらく、これが目標とする柔軟性と能力を与えるためには不可避であったろう。それにもかかわらず、CDSA は受け入れられている。 CDSA普及を遅らせる第 2の要因は主要な暗号ベンダーがCDSA APIの適用および公開に躊躇していることである。RSA Security、Entrust Technologies、Baltimore Technologiesなどの幾つかの主要なベンダーが CDSA 開発に関与しているが、彼らの多くがいまだに彼ら自身の APIの下に CDSA を隠すか、彼ら独自の (プロプライエタリな) APIのために適用や公開を避けてきた。これが 1990年代後半にベンダーが顧客を縛り付けていた一般的な傾向を示すものであり、かつ最近の PKI 技術セールスが衰退する理由の一つとなっている。 CDSA はいまだに、暗号ベースのセキュリティ サービスに対して最も完全で拡張可能な選択肢であり続けており、ベンダーもそのサポートを継続している。 Intel は彼らの新しい BIS (Boot Integrity Services) サービスのような CDSAに依存した新しいアプリケーションの開発を継続しており、IBM、HP 、Apple も彼らのセキュリティ製品に CDSAを利用するのを継続している。

CDSA アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%5%5%5%----30%30%30%30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方地方地方地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用 オープンオープンオープンオープン ソソソソースースースース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了 標準化および標準化および標準化および標準化および改版改版改版改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い低い低い低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数 重要なマーケ重要なマーケ重要なマーケ重要なマーケットシェアットシェアットシェアットシェア

マーケット リーダ

減少

結論結論結論結論 – CDSA API は暗号ベースのセキュリティ サービスに対する最も完全で柔軟な APIのセットである。これは容易に拡張可能であるが、難点はその大きさと学習曲線である。CDSA の普及は継続して発展していくであろう。

6.5 CDSA/HRS (Common Data Security Architecture/Human Recognition Services) CDSA/HRS API はまだ多く利用されていない。その第一の理由は、バイオメトリック産業 (biometric industry) の成長速度が遅いためである。しかし、近い将来、勢いを増すことが期待されている。長期に渡って、バイオメトリック市場は装置を製造するハードウェア メーカーに先導されてきた。これらの装置

187

を単純なデモ プログラムに統合するのではなく、企業規模のセキュリティ システムに統合していくのには時間がかかるであろう。 PKIシステムへバイオメトリック装置を統合するのに CDSA/HRS を利用することは非常に有望であり、ソフトウェアおよびハードウェアが統合化されたセキュリティ ソリューションを提供するだろう。

CDSA/HRS アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所局所局所局所 地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利限定的な利限定的な利限定的な利用用用用

広範囲な利用

オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了標準化完了標準化完了標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 － CDSA/HRSが CDSA自身の普及に依存することもあって、この領域における成長速度は遅いと思われる。この領域では広範囲に普及したアプリケーションの成功事例が待望されている。CDSA/HRS が (PKIによる) ソフトウェア認証システム (authentication systems) と (バイオメトリック装置による) ハードウェア識別システム (identification systems) の間に共通の基盤を提供することが重要である。現時点ではこれが実現するかどうかは定かではない。

6.6 BioAPI BioAPI は CDSA/HRS API に関連しているけれども、CDSA の普及には依存しておらず、その普及速度は著しく速い。BioAPI実装の標準化は無料で入手できるリファレンス実装により恩恵を得ている。BioAPI Consortium はこれらの製品が標準に準拠しているかどうかを判定する準拠テストを行っていない。 現在、BioAPI に準拠する製品が幾つかリリースされており、顔面認識 (face recognition)、指紋識別 (fingerprint identification)、筆跡認識 (signature recognition) 装置などがある。

BioAPI アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%5%5%5%----30%30%30%30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方地方地方地方 世界的 地域的

188

オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了標準化完了標準化完了標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数 重要なマーケ重要なマーケ重要なマーケ重要なマーケットシェアットシェアットシェアットシェア

マーケット リーダ

減少

結論結論結論結論 － より多くのバイオメトリック装置が利用するようになれば、BioAPI もより優勢になっていくだろう。BioAPI 準拠のハードウェア装置がより多く市場に出てくると期待される。2001 年 9 月に BioAPIが ANSIのファスト トラック標準化プロセス (fast track standard process) に提出された。ANSI 標準化により BioAPIのマーケット シェアが更に拡大するであろう。

6.7 GSS-API (General Security Services API) GSS-API はここ数年の間に着実に利用されてきている。セキュリティ サービスを必要とする新しいセキュリティ プロトコルは GSS-API 仕様を参照する傾向がある。IETF は GSS-API に依存するように新しいプロトコルの開発と既存プロトコルの改善の両方を継続している。 GSS-API準拠をうたったとしても、常にその製品仕様に GSS-API の参照が現れるという訳ではない。上位レベルのセキュリティ サービスがリストに上がる場合、常に GSS-API の参照が言及されている。現在、 GSS-API に対する改良か GSS-API を用いた新しいプロトコルのどちらかを記述する RFC が50近く発行されている。GSS-API 改良に関しては前項、第 5項にて説明している。GSS-API を用いたプロトコルを次にあげておく： RFC 1961 は SOCKS プロトコル バージョン 5で使用される GSS-API ベースの認証 (authentication) 方法 を記述している。 SOCKS プロトコルはファイアウォール経由の認証付きアクセス (authenticated access) を行う場合に利用される。 RFC 1961 は GSS-API の元の版に対応して記述されている。 RFC 2203 はGSS-API を利用するための RPC (Reverse Procedure Call) メカニズムを利用可能にする、 RPCSEC_GSS と呼ばれるプロトコルについて記述している。このプロトコルによってサポートされる RPC メカニズムは、元は Sun Microsystems が定義した ONC (Open Network Computing) RPC であった。後に発行された RFC 2695 はインフォメーショナル RFC (informational RFC) であるが、 RPC メカニズムに対する攻撃が RPCSEC_GSS および GSS-API 標準を用いてどのように防止できるかを記述するために提出された。 RFC 2228 は GSS-API を呼び出すように FTP (File Transfer Protocol) を拡張し、強力な認証 (strong authentication)、完全性 (integrity)、機密性 (confidentiality) サービスを提供することができる。 RFC 2623 は、 NFS (Network File System) がネットワーク ファイル システムにセキュリティを追加するために Kerberos バージョン 5 を用いた RPCSEC_GSS (RFC 2203 で記述され、既に上で述べた)

189

をどのように利用するかを規定している。 RFC 3010 は NFS バージョン 4 を記述した標準であり、これには次の 3つの鍵メカニズム (keying mechanisms) をオプションとして用いた GSS-API の利用方法が含まれている： Kerberos V5, LIPKEY, SPKM。 RFC 2847 は クライアントをパスワードで認証しサーバを公開鍵証明書 (public key certificate) で認証するクライアント サーバ間のセキュア チャネル (secure channel) を提供する GSS-API を用いる方式を記述している。これは SSL (Secure Sockets Layer) や TLS (Transport Layer Security) プロトコルと同様の機能を提供するものである。このメカニズムは LIPKEY – Low Infrastructure Public Key Mechanism と呼ばれている。 RFC 2930 は DNS (Domain Name System) クエリ (queries) を認証し、GSS-API を用いた共有の秘密鍵 (shared secret keys) により応答する方式を規定している。 GSS-API 利用を規定するインターネット ドラフトが現在、幾つか存在している。以下にその幾つかを紹介する： Draft-ietf-ipsec-isakmp-gss-auth-07、IKE (Internet Key Exchange) 鍵管理プロトコルを用いるための GSS-API ベースの認証方式。IKE は IPSec (IP Security) 暗号化を実装する際に現在用いられている鍵管理プロトコルのことである。 IKE はそれ自身、現時点でまだ改版作業中である。 Draft-ietf-cat-iakerb-08、Kerberos Version 5.を用いた GSS-APIを利用する イニシャル アンド パススルー認証 (initial and pass though authentication) システム。 Draft-swift-win2k-krb-user3user-03、 GSS-API および Kerberos バージョン 5 を用いたユーザ対ユーザ認証 (user-to-user authentication) システム。 Draft-galb-secsh-gssapi-01、 GSS-API を用いた SecSH (Secure Shell) プロトコルのための認証方式 (authentication method)。

GSS-API アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%5%5%5%----30%30%30%30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方 世界的世界的世界的世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了 標準化および標準化および標準化および標準化および改版改版改版改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い低い低い低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数 重要なマーケットシェア

マーケットマーケットマーケットマーケット リーダリーダリーダリーダ

減少

190

結論結論結論結論 － GSS-API は汎用のセキュリティ サービスにおけるマーケット リーダーである。新しいプロトコルおよび APIが GSS-API を参照、あるいは GSS-API 関数を呼び出す形で現在も開発が進められているため、今後もマーケット リーダーであり続けるであろう。

6.8 IDUP-GSS-API (Individual Data Unit Protection – Generic Security Services API) IDUP-GSS-API は個別データを保護するように設計されており、主に E メールを保護することを想定している。現時点ではまだ利用するケースは多く現れていない。IDUP を記述している RFC 2479はインフォメーショナル RFC (informational RFC) であり仕様ではない。

IDUP-GSS-API アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所局所局所局所 地方 世界的 地域的 オーナーシップオーナーシップオーナーシップオーナーシップ 寡占 限定的な利

用 広範囲な利広範囲な利広範囲な利広範囲な利用用用用

オ ー プ ン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了標準化完了標準化完了標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間 低い低い低い低い 凍結 ベースとなる技術ベースとなる技術ベースとなる技術ベースとなる技術 創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物 ベースとなる技術ベースとなる技術ベースとなる技術ベースとなる技術の信頼性の信頼性の信頼性の信頼性

未知 不安定 改善中 安定安定安定安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 － IDUP-GSS-API を記述する RFC がインフォメーショナル RFC であるため、これが参照されるケースは少ないであろう。また、E メールが GSS-API を利用するケースは全体のほんの一部であるため、IDUP-GSS-API を参照するケースが増えることは少ないであろう。にもかかわらず、Eメールやデータ ファイルに GSS-API を用いる場合の良い選択肢であり続けると思われる。

6.9 XGSS-API XGSS-API は IETF からは RFC としてリリースされていない。それにもかかわらず、IETF で認可 (authorization) に関する作業に関わった人は、他の認可 API である GAA-API および aznAPI と競合するというよりもこれらを補うものであるという意見を持っている。

191

XGSS-API アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所局所局所局所 地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用

広範囲な利広範囲な利広範囲な利広範囲な利用用用用

オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラ正式なドラ正式なドラ正式なドラフトフトフトフト

標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中発展中発展中発展中 高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中改善中改善中改善中 安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 － XGSS-API は今後、幾つかの製品で利用され、標準としてもある程度受け入れられるであろう。ドラフトは標準としてリリースされていないが、論文で何度も引用または参照されており、今後も影響を与えていくと思われる。

6.10 GAA-API (Generic Authorization and Access Control) API GAA-API はアプリケーションによる認可の判定 (authorization decisions) を容易にするように設計されている。アプリケーションは GAA-API関数を用いて、要求されたアクションが 認可されるかどうかを決定し、また、特定のリソースに関する付加的なアクセス管理情報をリクエストする。 GAA-API は論文で参照され、他の認証 (authentication) 作業で引き継がれていくであろう。また、幾つかの製品で実装され、他の技術で利用されていくであろう。しかし、XGSS-API と同様に、仕様のドラフトは最終 RFC (finished RFCs) としてはリリースされていない。

GAA-API アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%1%1%1%----5%5%5%5% 5%-30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所局所局所局所 地方 世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフ正式なドラフ正式なドラフ正式なドラフトトトト

標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中発展中発展中発展中 高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中改善中改善中改善中 安定 減少

192

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 – GAA-API が大きなマーケット シェアになるケースは少ないであろうが、今後も認可技術 (authorization technology) に影響を及ぼしていくであろう。

6.11 aznAPI (Advanced Authorization API) 本資料で議論される認可標準 (authorization standards) の中で、 aznAPI のみが正式な標準としてリリースされている。 aznAPI 仕様が作成されると同時に、DASCOM によりソフトウェアが開発されたため、その作業中にテストされるという恩恵を受けた。 aznAPI は ISO/IEC 10181-3 に規定された ISO 認可モデル (authorization model) で定義されている、 ADF (Access Decision Functions) と AEF (Access Enforcement Functions) 間のインタフェースを提供している。これが、競合する認可 APIに比べて、多大な柔軟性を aznAPIに提供している。 aznAPI はまた DSCOM 製品、現在は IBM Corporation の Tivoli 部門の製品、という強みがある。この製品は非常によく売れている認可製品の一つであり、幾つかの大規模エンドユーザ企業で採用されている。

aznAPI アイデア期アイデア期アイデア期アイデア期 概念実証期概念実証期概念実証期概念実証期 成長期成長期成長期成長期 成熟期成熟期成熟期成熟期 衰退期衰退期衰退期衰退期

市場浸透度市場浸透度市場浸透度市場浸透度 なし 1%-5% 5%5%5%5%----30%30%30%30% 飽和 衰退 地理的範囲地理的範囲地理的範囲地理的範囲 孤立 局所 地方 世界的世界的世界的世界的 地域的 オーナーシッオーナーシッオーナーシッオーナーシッププププ

寡占 限定的な利用 広範囲な利用広範囲な利用広範囲な利用広範囲な利用 オープン ソース

所有権なし

標準化標準化標準化標準化 なし 非公式 正式なドラフト

標準化完了標準化完了標準化完了標準化完了 標準化および改版

技術の変化技術の変化技術の変化技術の変化 非常に高い 高い 中間中間中間中間 低い 凍結 ベースとなるベースとなるベースとなるベースとなる技術技術技術技術

創世記 発展中 高度に発展高度に発展高度に発展高度に発展 成熟 遺物

ベースとなるベースとなるベースとなるベースとなる技術の信頼性技術の信頼性技術の信頼性技術の信頼性

未知 不安定 改善中改善中改善中改善中 安定 減少

製品製品製品製品 なし ごく少数ごく少数ごく少数ごく少数 重要なマーケットシェア

マーケット リーダ

減少

結論結論結論結論 – aznAPI には、 (IBM Corporation の Tivoli 部門がリリースする Policy Director という) 定評のある認可製品で利用されている、という強みがある。相互運用可能な認可ソリューションを求めている企業が Policy Director 製品を導入していくため、aznAPI の普及が今後も発展していくであろう。

193

6.12 認可標準認可標準認可標準認可標準 (Authorization Standards) に関する注記に関する注記に関する注記に関する注記 本項で議論した認可 API (authorization APIs) の 3つ (XGSS-API、GAA-API、AZN-API) 全てが、アプリケーションにおける標準の認可機能を実装するために実際に使える仕様である。まだこれら 3 つのいずれの APIも幅広く受け入れられておらず、また、この市場領域の成長も非常にゆっくりしたものである。 これは、これら API の欠点が原因というよりも、この領域で幅広く受け入れられるソリューションを作成することの困難さによるものである。認可 (Authorization) は、複数のアプリケーションおよび OS を相互運用するのに必要な標準機能として、これまでに何らかの良い成果を出したとは言えない。これはユーザ コミュニティでこの機能に対するニーズがなかったためでなく、ベンダー コミュニティが細分化 されたことに起因する。 接続性 (connectivity) がより容易になり、認可システム (authorization systems) で必要なサポートを提供する認証システム (authentication systems) が成熟していくので、この状況は今後の 10年間で多分変わるであろう。

194

7.7.7.7. 結論結論結論結論 本資料では、2. セキュリティ関連 APIの分類方法 で分類方法を示し、この方法を基に 3. 分類に基づく各セキュリティ関連 APIの分析 で各 APIの詳細分析、4. セキュリティ関連 APIの比較 で比較の分析結果を示した。さらにその中の重要な APIに関して、5. セキュリティ関連 APIの標準化動向 で標準化の動向、6. セキュリティ関連 APIの今後の動向 で今後の動向を分析調査した結果を示した。 実際のセキュリティ製品実装においてどの APIに着目すれば良いかに対して参考意見をあげておくと、以下の 4つが大きな選択肢になると考えられる。 ① RSA PKCS#11, BSAFE ② Microsoft CryptoAPI, CAPICOM, MISF ③ Java (Java Security Architecture) ④ CDSA (CSSM API) また、適用分野を限定した場合は以下となる。 バイオ認証バイオ認証バイオ認証バイオ認証： BioAPI、CDSA/HRS PKIPKIPKIPKI： Crypto-API、APKI これに関連した記事が [373373373373] にあり、ここでは実際のセキュリティ製品実装に際し、RSA BSAFE Toolkit、Microsoft CryptoAPI、CDSA の 3 つの API の調査および比較を行い、動向や実装工数を比較して RSA BSAFE Toolkit を採用した、と報告している。この記事では、CryptoAPI および CDSA に関して詳しい情報を解説しており、PKI の今後の発展に合わせて CDSA や CryptoAPI のような標準 APIの発展が期待されると述べている。 また、これらの調査を行うにあたり、単に「どの製品や標準を採用すべきか」という観点ではなく、セキュリティに関するアーキテクチャや APIの動向について着目していくことが重要であると思われる。 というのも、これらのセキュリティ関連APIはそれぞれが独立したものではなく、別のAPIに対応したり、他の APIを統合したりする研究や提案もあり、これらのセキュリティ関連 APIのいずれを選択するか、という単純な考え方ができないということが一因である。 この意見をサポートする事実として、Open Groupのこれまでの活動の傾向をあげることができる。Open Group では、低位の暗号 APIである GCS-API の策定からそれよりも上位のセキュリティ サービス APIである GSS-APIへ、そして更にそれよりも上位にあるアーキテクチャの CDSAおよび CSSM APIの策定へと移行した。近年では更にコードから純粋な仕様レベルの APKIへと移行し、現在のプロジェクトでは 次世代のオブジェクト指向プログラマに影響を与えるように、「セキュリティ パターン (security patterns)iiii」の本の執筆を行っている。 本調査ではセキュリティ関連 APIについて多くの情報を提供することにより、セキュリティ製品開発の参考の一助となればと考えている。 今後、電子政府の構築へ向けて PKIをベースにしたセキュリティの普及が望まれている中、セキュリティ関連製品の開発に対するニーズが高まることが予想されている。このような状況において、セキュリティ関連 API の利用がソフトウェア製品開発に貢献すると同時に、ひいては社会へのセキュリティ向上や IT化推進に貢献することが期待される。

iiii 付録 7. 用語 の セキュリティ パターン (Security Patterns) に簡単な説明を行っているが、現状、Open Group から多くの情報が公開されていない。

195

付録付録付録付録

付録付録付録付録 1. 今後の動向の調査方法今後の動向の調査方法今後の動向の調査方法今後の動向の調査方法 (英文英文英文英文) 付録付録付録付録 2. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの標準化動向の標準化動向の標準化動向の標準化動向 (英文英文英文英文) 付録付録付録付録 3. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの今後の動向の今後の動向の今後の動向の今後の動向 (英文英文英文英文) 付録付録付録付録 4. セキュリティ関セキュリティ関セキュリティ関セキュリティ関連連連連 APIの分類と比較の分類と比較の分類と比較の分類と比較 (補足補足補足補足) 付録付録付録付録 5. セキュリティ関連セキュリティ関連セキュリティ関連セキュリティ関連 APIの分析の分析の分析の分析 (補足補足補足補足) 付録付録付録付録 6. ライブラリ、ツールキット、セキュリティライブラリ、ツールキット、セキュリティライブラリ、ツールキット、セキュリティライブラリ、ツールキット、セキュリティ API関連製品関連製品関連製品関連製品 付録付録付録付録 7. 用語用語用語用語 付録付録付録付録 8. 参考資料参考資料参考資料参考資料