Copyright © 1996-2003 Sun Microsystems, Inc.All Rights Reserved.
コメントの送付先: java-security@sun.com。これは購読リストではありません。
Java ソフトウェア
JDK 1.1 で、「暗号化サービスプロバイダ」(略して「プロバイダ」) の概念が導入されました。これは、JDK Security API の暗号化に関するサブセットの具体的な実装を提供するパッケージ (またはパッケージセット) です。
JDK 1.1 では、プロバイダには、1 つ以上のデジタル署名アルゴリズム、メッセージダイジェストアルゴリズム、および鍵生成アルゴリズムの実装などを含めることができました。Java 2 SDK では鍵ファクトリ、キーストアの作成および管理、アルゴリズムパラメータの管理、アルゴリズムパラメータの生成、および証明書ファクトリの 5 種類のサービスが追加されています。また、Java 2 SDK では、プロバイダが乱数の生成 (RNG) アルゴリズムを提供できます。これまで、JDK では、特定のアルゴリズムはハードコードされており、RNG もプロバイダベースではありませんでした。
暗号化機能を使用しようとするプログラムは、単に特定のサービス (たとえば DSA 署名アルゴリズム) を実装する特定型のオブジェクト (たとえば Signature オブジェクト) を要求するだけで、インストールされているプロバイダの 1 つから実装を取得できます。特定のプロバイダからの実装が望ましい場合、プログラムはそのプロバイダを名前で要求し、同時に目的のサービスを要求することができます。
SDK では 1 つ以上のプロバイダパッケージがインストールされます。クライアントは異なるプロバイダを用いて実行環境を構成し、各プロバイダの「優先順位」を指定できます。優先順位とは、特定プロバイダの指定がないときに、要求アルゴリズムについてプロバイダを検索する順序です。
Sun が提供する Java Runtime Environment には、SUN という名前のデフォルトのプロバイダが標準で搭載されています。ほかの Java Runtime Environment には、SUN プロバイダが含まれない場合があります。SUN プロバイダパッケージには、以下のものが含まれています。
- NIST FIPS 186 に記述されたデジタル署名アルゴリズム (DSA) の実装
- MD5 (RFC 1321) および SHA-1 (NIST FIPS 180-1) メッセージダイジェストアルゴリズムの実装
- DSA アルゴリズムに適した公開鍵および非公開鍵のペアの生成に必要な DSA 鍵のペアのジェネレータ
- DSA アルゴリズムパラメータジェネレータ
- DSA アルゴリズムパラメータマネージャ
- (不透明な) DSA 非公開鍵および公開鍵オブジェクトとそれらの基本となる鍵データとの双方向変換を可能にする DSA 「鍵ファクトリ」
- IEEE P1363 標準 (Appendix G.7) の推奨に準拠した専用の「SHA1PRNG」擬似乱数生成アルゴリズムの実装
- X.509 証明書の取り消しリスト (CRL) のための「証明書ファクトリ」
- JKS という独自のキーストア型のためのキーストアの実装
新たなプロバイダは、静的にも動的にも追加できます。クライアントは、現在どのプロバイダがインストールされているかを問い合わせることができます。
実装が違うと、特徴も違ってくる場合があります。ソフトウェアベースのものもあれば、ハードウェアベースのものもあります。プラットフォーム独立のものもあれば、プラットフォーム固有のものもあります。また、レビューや評価用に使えるプロバイダコードもあれば、使えないものもあります。
このドキュメントの対象読者
このドキュメントは、暗号化サービス実装を提供する独自のプロバイダパッケージを作成する上級プログラマを対象としています。ここでは、SDK Security API クライアントが、作成されたアルゴリズムや他のサービスを要求する際にそれらを検出できるよう、プロバイダを Java 2 SDK Security に統合するための方法がドキュメント化されています。 SDK Security API を使って既存の暗号化アルゴリズムや他のサービスにアクセスするだけであれば、このドキュメントを読む必要はありません。
関連ドキュメント
このドキュメントは、読者がすでに「Java 暗号化アーキテクチャ API の仕様およびリファレンス」を読んでいることを前提としています。
Java 2 Security API のさまざまなクラスおよびインタフェースについての説明も含まれます。Security API パッケージの完全なリファレンスドキュメントを以下に示します。
「エンジンクラス」は、具体的な実装のない抽象的な方法で暗号化サービスを定義します。
暗号化サービスは、常に特定のアルゴリズムまたは型に関連付けられています。このサービスによって、暗号化の操作 (デジタル署名またはメッセージダイジェスト用など) の提供、暗号化の操作に必要な暗号化データ (鍵またはパラメータ) の生成や提供、あるいは暗号化の操作で使う暗号化鍵を安全にカプセル化するデータオブジェクト (キーストアまたは証明書) の生成が行われます。たとえば、Signature クラスおよび KeyFactory クラスは、エンジンクラスです。Signature クラスは、デジタル署名アルゴリズムの機能へのアクセスを提供します。DSA KeyFactory は、(コード化形式または透明な仕様から) DSA 非公開鍵または公開鍵を、それぞれ DSA Signature オブジェクトの
initSignまたはinitVerifyメソッドから利用可能な形式で提供します。Java 暗号化アーキテクチャには、エンジンクラスなどの、暗号化に関連する Java 2 SDK Security パッケージが含まれています。API のユーザは、エンジンクラスを要求および利用して対応する処理を実行します。Java 2 SDK では、次のエンジンクラスが定義されています。
- MessageDigest: 指定データのメッセージダイジェスト (ハッシュ) の計算に使用する
- Signature: デジタル署名の署名および検証に使用する
- KeyPairGenerator: 指定のアルゴリズムに適合した、公開鍵、非公開鍵ペアの生成に使用する
- KeyFactory: Key 型の不透明な暗号化鍵を「鍵仕様」(背後キーデータの透明な表現) に変換したり、その逆の変換を行うために使用する
- KeyStore: 「キーストア」の作成および管理に使用する。キーストアは、鍵のデータベースである。キーストア内の非公開鍵には、鍵に関連した証明連鎖が存在する。証明連鎖は、対応する公開鍵を認証する。また、キーストアには、信頼できるエンティティからの証明書も格納される
- CertificateFactory: 公開鍵の証明書および証明書の取り消しリスト (CRL) の作成に使用する
- AlgorithmParameters: パラメータの符号化および復号化など、特定のアルゴリズムのパラメータ管理に使用する
- AlgorithmParameterGenerator: 特定のアルゴリズムに適したパラメータセットの生成に使用する
- SecureRandom: 乱数または擬似乱数の生成に使用する
注: 「ジェネレータ (generator)」は、最新の内容でオブジェクトを作成しますが、「ファクトリ (factory)」は既存の構成要素 (符号化法など) からオブジェクトを作成します。
エンジンクラスは、(特定の暗号化アルゴリズムに依存しない) 特定の型の暗号化サービス機能へのインタフェースを提供します。これにより、Application Programming Interface (API) メソッドが定義され、API が提供する特定の種類の暗号化サービスにアプリケーションがアクセスできるようになります。実際の実装 (1 つ以上のプロバイダから) は特定アルゴリズムのためのものです。たとえば Signature エンジンクラスは、デジタル署名アルゴリズムの機能へのアクセスを提供します。SignatureSpi サブクラス (次の段落を参照) に実際に提供される実装は、DSA を使う SHA-1、RSA を使う SHA-1、または RSA を使う MD5 などの特定の種類の署名アルゴリズムとなります。
エンジンクラスが提供するアプリケーションインタフェースは、Service Provider Interface (SPI) に置き換えて実装されます。つまり、各エンジンクラスに対応する抽象 SPI クラスが存在し、抽象 SPI クラスによって暗号化サービスプロバイダが実装しなければならない Service Provider Interface のメソッドが定義されます。
エンジンクラスのインスタンスである「API オブジェクト」は、対応する SPI クラスのインスタンス「SPI オブジェクト」を private フィールドとしてカプセル化します。API オブジェクトのすべての API メソッドは、final として宣言し、それらを実装することによって、カプセル化される SPI オブジェクトの対応する SPI メソッドが呼び出されます。エンジンクラス (およびそれに対応する SPI クラス) のインスタンスは、エンジンクラスの
getInstanceファクトリメソッドへの呼び出しによって作成されます。SPI クラスの名前は、対応するエンジンクラス名のあとに「Spi」を追加した名前になります。たとえば、Signature エンジンクラスに対応する SPI クラスは、SignatureSpi クラスです。
各 SPI クラスは、抽象クラスです。指定したアルゴリズムに対する特定の型のサービスの実装を提供するには、プロバイダは、対応する SPI クラスをサブクラス化して、すべての抽象メソッドの実装を提供する必要があります。
エンジンクラスの別の例に MessageDigest クラスがあります。このクラスは、メッセージダイジェストアルゴリズムへのアクセスを提供します。MessageDigestSpi サブクラスでのこのクラスの実装は、SHA-1、MD5、または MD2 などの各種メッセージダイジェストアルゴリズムにできます。
さらに別の例として、KeyFactory エンジンクラスは、不透明な鍵から透明な鍵仕様への変換、またはその逆の変換をサポートします。(「鍵ファクトリにより要求される鍵仕様のインタフェースおよびクラス」を参照)。KeyFactorySpi サブクラスで提供される現実の実装は、DSA 公開鍵または非公開鍵などの、特定の種類の鍵のための実装です。
SDK Security へのプロバイダの実装および統合までのステップは、次のとおりです。
- ステップ 1: サービス実装コードの記述
- ステップ 2: プロバイダの命名
- ステップ 3: プロバイダのサブクラスである「マスタークラス」の記述
- ステップ 4: コードのコンパイル
- ステップ 5: テストの準備: プロバイダのインストール
- ステップ 6: テストプログラムの記述とコンパイル
- ステップ 7: テストプログラムの実行
- ステップ 8: プロバイダおよびそのサポート対象サービスのドキュメント化
- ステップ 9: クラスファイルおよびドキュメントをクライアントから利用可能にする
ステップ 1: サービス実装コードの記述
最初に行うべきことは、サポートする暗号化サービスのアルゴリズム固有の実装を提供するコードを記述することです。Java 2 SDK では、鍵および証明書ファクトリ、キーストアの作成および管理、アルゴリズムパラメータ管理、およびアルゴリズムパラメータ生成サービスに加え、署名、メッセージダイジェスト、鍵のペア生成、および (擬似) 乱数生成アルゴリズムを提供できます。
暗号化サービスごとに、以下のような適切な SPI クラスのサブクラスを作成する必要があります。SignatureSpi、MessageDigestSpi、KeyPairGeneratorSpi、SecureRandomSpi、AlgorithmParameterGeneratorSpi、AlgorithmParametersSpi、KeyFactorySpi、CertificateFactorySpi、または KeyStoreSpi(「エンジンクラスおよび対応する SPI クラス」を参照)。
サブクラスで、以下を実行する必要があります。
- 通常「engine」で始まる名前を持つ抽象メソッド用の実装の提供。詳細は、「実装の詳細および要件」を参照
- 引数を持たない public コンストラクタの存在の保証。 理由は、サービスの要求時に、SDK Security は、マスタークラス内のプロパティによる指定に従って、そのサービスを実装するサブクラスをルックアップするため (ステップ 3 を参照)。その後、Java 2 SDK Security は、サブクラスに関連付けられた Class オブジェクトを作成し、その Class オブジェクトに対して
newInstanceメソッドを呼び出すことにより、サブクラスのインスタンスを作成する。newInstanceはサブクラスがパラメータを持たない public コンストラクタを保持することを要求するサブクラスがコンストラクタを持たない場合、引数を持たないデフォルトのコンストラクタが自動的に生成されます。ただし、サブクラスがコンストラクタを定義する場合、引数を持たない public コンストラクタを明示的に定義する必要があります。
ステップ 2: プロバイダの命名
使用するプロバイダの名前を特定します。これは、クライアントアプリケーションがプロバイダを参照する際に使用する名前です。ステップ 3: プロバイダのサブクラスである「マスタークラス」の記述
3 番目のステップは、Provider クラスのサブクラスを作成することです。このサブクラスは
finalにする必要があり、そのコンストラクタは以下を実行する必要があります。
superを呼び出して、プロバイダ名 (ステップ 2 を参照)、バージョン番号、およびプロバイダおよびプロバイダがサポートするアルゴリズムに関する情報を指定する。以下に例を示すsuper("ACME", 1.0, "ACME provider v1.0, implementing " + "RSA signing and key generation, SHA-1 and MD5 message digests.");- Java 2 Security API がプロバイダにより実装された暗号化サービスを探すために必要とされる、さまざまなプロパティの値を設定する。プロバイダにより実装されたサービスごとに、サービスの種類 (Signature、MessageDigest、KeyPairGenerator、SecureRandom、KeyFactory、KeyStore、CertificateFactory、AlgorithmParameterGenerator、または AlgorithmParameters) とピリオドに続き、サービスの適用対象のアルゴリズム、証明書のタイプ、またはキーストアタイプを示す名前が付けられたプロパティが存在する必要がある。プロパティの値には、サービスを実装するクラスの完全修飾名を指定する必要がある
次のリストは、さまざまな種類のサービスに合わせて定義する必要のあるプロパティのタイプを示します。実際には、「algName」はアルゴリズム名に、「certType」は証明書のタイプに、「storeType」はキーストアタイプに置き換えられます。
これらのどの場合にも、algName、certType、storeType は、アルゴリズム、証明書のタイプ、キーストアタイプの「標準」名です(使用すべき標準名については、「Java 暗号化アーキテクチャ API 仕様＆リファレンス」の「付録 A」を参照)。
各プロパティの値は、指定されたアルゴリズム、証明書のタイプ、またはキーストアタイプを実装するクラスの完全修飾名である必要があります。つまり、クラス名のあとにピリオドとパッケージ名が記述されていなければなりません。
たとえば、「SUN」という名前のデフォルトプロバイダは、
sun.security.providerパッケージのDSAという名前のクラス内のデジタル署名アルゴリズム (その標準名は「SHA1withDSA」) を実装します。このプロバイダのサブクラス (sun.security.providerパッケージのSunクラス) は、次のようにSignature.SHA1withDSAプロパティを設定して、値「sun.security.provider.DSA」を保持します。put("Signature.SHA1withDSA", "sun.security.provider.DSA")次のリストに、さまざまな種類のサービスに合わせて定義可能なプロパティのタイプをさらに示します。実際には、algName はアルゴリズム名に、certType は証明書のタイプに、storeType はキーストアタイプに置き換えられます。
これらのどの場合にも、algName、certType、storeType、attrName は、アルゴリズム、証明書のタイプ、キーストアタイプ、または属性の「標準」名です (使用標準名については、「Java 暗号化アーキテクチャ API 仕様 & リファレンス」の「付録 A」を参照)。
上記の形式のプロパティの場合、プロパティの値は、対応する属性に応じた値である必要があります (各標準属性の定義については、「Java 暗号化アーキテクチャ API 仕様＆リファレンス」の「付録 A」を参照)。
たとえば、「SUN」という名前のデフォルトプロバイダは、SHA1withDSA デジタル署名アルゴリズムをソフトウェア内で実装します。 プロバイダ「SUN」のマスタークラスでは、次のようにして、「Signature.SHA1withDSA ImplementedIn」が値「Software」を保持するように設定が行われます。
マスタークラスプロパティの設定例の詳細についてさらに情報を得るには、「付録 A」を参照して、現在の Java 2 SDK
Sun.javaのソースファイルを閲覧してください。そこでは、Sunクラスのコンストラクタが「SUN」プロバイダ用のプロパティすべてを設定しています。注: Provider サブクラスは、その情報を必要な場合にはどこでも取得できます。このため、情報は、実行時に (たとえばファイルから) 組み込んだり、取得したりできます。
ステップ 4: コードのコンパイル
実装コードの作成 (ステップ 1)、プロバイダの命名 (ステップ 2)、およびマスタークラスの作成 (ステップ 3) が完了したら、コンパイラを使ってファイルをコンパイルします。ステップ 5: テストの準備: プロバイダのインストール
プロバイダのテスト準備を行うために、プロバイダを使用するクライアントが行うのと同じ方法で、プロバイダをインストールする必要があります。インストールを実行すると、SDK Security はクライアントの要求に応じてアルゴリズムの実装を検出できるようになります。プロバイダのインストールは 2 つの部分に分かれます。つまり、プロバイダパッケージクラスのインストールとプロバイダの構成です。
プロバイダクラスのインストール
最初に行う事柄は、作成したクラスを利用可能にして、要求時に検出できるようにすることです。プロバイダクラスは JAR (Java ARchive) または ZIP ファイルの形式で提供します。プロバイダクラスのインストールには、次の 2 つの方法があります。
- クラスが格納されている zip または JAR ファイルを、CLASSPATH の任意の場所に置く
- プロバイダ JAR ファイルを、「インストールされた」または「バンドルされた」拡張機能として指定する。拡張機能の配置方法の詳細については、「拡張機能の配置」を参照
プロバイダの構成
次の手順では、認可プロバイダのリストにこのプロバイダを追加します。これは、セキュリティプロパティファイルを編集することにより、静的に行われます。
ここで、<java-home> は、実行環境がインストールされているディレクトリを指します。たとえば、J2SDK バージョン 1.4 を Solaris の<java-home>\lib\security\java.security [Win32] <java-home>/lib/security/java.security [Solaris]/home/user1/j2sdk1.4.0というディレクトリにインストールしている場合、または Win32 のC:\j2sdk1.4.0というディレクトリにインストールしている場合は、次のファイルを編集する必要があります。/home/user1/j2sdk1.4.0/jre/lib/security/java.security [Solaris] C:\j2sdk1.4.0\jre\lib\security\java.security [Win32]同様に、Java 2 Runtime Environment バージョン 1.4 を Solaris の
/home/user1/j2re1.4.0ディレクトリにインストールしている場合、または Win32 のC:\j2re1.4.0ディレクトリにインストールしている場合は、次のファイルを編集する必要があります。/home/user1/j2re1.4.0/lib/security/java.security [Solaris] C:\j2re1.4.0\lib\security\java.security [Win32]プロバイダごとに、このファイルは次の形式の文を保持します。
security.provider.n=masterClassNameこれはプロバイダを宣言し、その優先順位 n を指定します。優先順位とは、特定プロバイダの指定がないときに、要求されたアルゴリズムについてプロバイダを検索する順序です。順位は 1 から始まり、1 が最優先で次に 2、3 ...と続きます。
masterClassName には、ステップ 3 で実装したプロバイダの「マスタークラス」の完全修飾名を指定する必要があります。このクラスは、常に Provider クラスのサブクラスです。
Java 2 SDK がインストールされている場合は、いつでも組み込みの (デフォルト) プロバイダが含まれています。これには「SUN」として参照されるプロバイダも含まれます。
java.securityファイルには、「SUN」プロバイダの次のような仕様が含まれています。security.provider.1=sun.security.provider.Sun(「SUN」プロバイダのマスタークラスは、sun.security.providerパッケージ内のSunクラスであることに留意)マスタークラスが
COM.acme.providerパッケージのAcmeクラスであり、作成したプロバイダを優先順位の 2 番目のプロバイダにする場合を考えてみましょう。その場合、java.securityファイルにある「SUN」プロバイダの行の下に次の行を追加して、さらに他のプロバイダの優先順位を 2 より大きくします。security.provider.2=COM.acme.provider.Acme注: プロバイダは、動的に登録することもできます。その場合、プログラム (ステップ 7 で記述したテストプログラムなど) は、SecurityクラスのaddProviderメソッドまたはinsertProviderAtメソッドを呼び出します。この登録は恒久的ではなく、「信頼できる」プログラムでしか実行できません。「Java 暗号化アーキテクチャ API 仕様＆リファレンス」の Security クラスセクションを参照してください。ステップ 6: テストプログラムの記述とコンパイル
Security API へのプロバイダの統合、およびそのアルゴリズムをテストする 1 つ以上のテストプログラムの記述およびコンパイルを実行します。必要に応じて、ハッシュまたは署名の行われるテストデータ用ファイルなどのサポート用ファイルを作成します。プログラムが実行する最初のテストでは、プロバイダの検出、およびその名前、バージョン番号、追加情報が予期されたとおりかどうかを確認します。このために、次のようなコードを記述できます。「MyPro」は、独自のプロバイダ名に置き換えてください。
import java.security.*; Provider p = Security.getProvider("MyPro"); System.out.println("MyPro provider name is " + p.getName()); System.out.println("MyPro provider version # is " + p.getVersion()); System.out.println("MyPro provider info is " + p.getInfo());次に、サービスが検出されることを確認します。たとえば、SHA-1 メッセージダイジェストアルゴリズムを実装した場合には、要求時にこのアルゴリズムが確実に検出されるかどうかを、次のコードを使ってチェックできます (ここでも「MyPro」は、独自のプロバイダ名に置き換える)。
MessageDigest sha = MessageDigest.getInstance("SHA", "MyPro"); System.out.println("My MessageDigest algorithm name is " + sha.getAlgorithm());
getInstanceへの呼び出しでプロバイダ名を指定しない場合、そのアルゴリズムを実装するプロバイダが検出されるまで、登録されたすべてのプロバイダが優先順位に従って検索されます (「プロバイダの構成」を参照)。ステップ 7: テストプログラムの実行
テストプログラムを実行します。コードをデバッグし、必要に応じてテストを続行します。Java 2 Security API がアルゴリズムを検出できないようであれば、上記のステップを確認し、すべてのステップが完了していることを確認してください。ステップ 8: プロバイダおよびそのサポート対象サービスのドキュメント化
次のステップは、クライアント用のドキュメントを記述することです。少なくとも、次の指定を行う必要があります。さらに、ドキュメント内で、デフォルトのアルゴリズムパラメータなどの、クライアントに関係する他の指定も行う必要があります。
- プロバイダの参照に使用する名前プログラム。注: これを執筆している時点で、プロバイダ名の検索は大文字と小文字が区別される。つまり、マスタークラスがプロバイダ名を「ACME」として指定した場合、ユーザが「Acme」を要求しても、プロバイダは見つからない。この動作は、将来変更される可能性があるが、現時点ではクライアントに対して大文字と小文字を正確に指定するように通知する必要がある
- プロバイダが実装するアルゴリズムおよび他のサービスの種類
- プロバイダのインストール方法に関する指示。これは、情報と例がプロバイダ固有のものになることを除き、ステップ 5 で示した指示と同様
メッセージダイジェスト
メッセージダイジェストアルゴリズムごとに、実装が複製可能かどうかを指定します。これは、技術的には必須ではありませんが、複製により中間ハッシュが可能かどうかを指定することになるため、クライアントの費やす時間およびコードの記述にかかる手間が軽減されます。メッセージダイジェストの実装が複製可能かどうかがわからない場合、クライアントは MessageDigest オブジェクトの複製を試みて、発生する可能性のある例外をキャッチすることにより、複製可能かどうかを識別できます。次にその例を示します。
try { // try and clone it /* compute the hash for i1 */ sha.update(i1); byte[] i1Hash = sha.clone().digest(); /* compute the hash for i1 and i2 */ sha.update(i2); byte[] i12Hash = sha.clone().digest(); /* compute the hash for i1, i2 and i3 */ sha.update(i3); byte[] i123Hash = sha.digest(); } catch (CloneNotSupportedException cnse) { // have to use an approach not involving cloning }この例では、
shaは、MessageDigest.getInstanceへの呼び出しを介して要求が行われた場合に、受け取られるメッセージダイジェストオブジェクトである
i1、i2およびi3は、入力バイト配列である
- 以下について、別々のハッシュを計算する
i1i1 および i2i1、i2、および i3署名アルゴリズム
署名アルゴリズムを実装する場合、署名 (
signメソッドの 1 つを使って生成される) を符号化する形式をドキュメント化する必要があります。たとえば、「SUN」プロバイダにより提供される SHA1withDSA 署名アルゴリズムは、署名を、2 つの整数rおよびsの標準 ASN.1 SEQUENCE として符号化します。乱数生成 (SecureRandom) アルゴリズム
乱数生成アルゴリズムの場合、生成される数がどのように「ランダム」なのかを示す情報、および乱数ジェネレータの自己シード時のシードの質に関する情報を提供します。同時に、SecureRandom オブジェクト (およびそのカプセル化された SecureRandomSpi 実装オブジェクト) の直列化解除時に、何が発生するかにも留意してください。復元されたオブジェクトの
nextBytesメソッド (カプセル化された SecureRandomSpi オブジェクトのengineNextBytesメソッドを呼び出す) への続く呼び出しにより、元のオブジェクトが生成するのと正確に同じ (ランダム) バイトが生成される場合、この動作が望ましくないのであれば、setSeedメソッドを呼び出して復元されたランダムオブジェクトにシードをするよう、ユーザに通知してください。鍵ペアジェネレータ
鍵ペアジェネレータアルゴリズムでは、クライアントが (
initializeメソッドの呼び出しを介して) 明示的に鍵ペアジェネレータを初期化しない場合、各プロバイダはデフォルトの初期化を提供およびドキュメント化する必要があります。たとえば、「SUN」プロバイダはデフォルトの 1024 ビットのモジュラスサイズ (強度) を使用します。鍵ファクトリ
プロバイダは、その鍵ファクトリがサポートするすべての鍵仕様をドキュメント化する必要があります。証明書ファクトリ
プロバイダは、ファクトリが作成可能な証明書の種類 (および必要に応じてそのバージョン番号) をドキュメント化する必要があります。キーストア
プロバイダは、キーストアの実装に関するすべての関連情報 (基礎となるデータ形式など) をドキュメント化する必要があります。アルゴリズムパラメータジェネレータ
クライアントが (AlgorithmParameterGenerator エンジンクラスのinitメソッドの呼び出しを介して) アルゴリズムパラメータジェネレータを明示的に初期化しない場合、各プロバイダはデフォルトの初期化を提供およびドキュメント化する必要があります。たとえば、「SUN」プロバイダは、DSA パラメータの生成にデフォルトの 1024 ビットのモジュラスプライムサイズを使用します。ステップ 9: クラスファイルおよびドキュメントをクライアントから利用可能にする
最後のステップは、クラスファイルおよびドキュメントを、適切と考えられる任意の形式 (クラスファイル、zip ファイル、JAR ファイル) および方法 (Web からのダウンロード、フロッピー、メールなど) でクライアントから利用可能にすることです。
別名
多くの暗号化のアルゴリズムおよびタイプには、「Java 暗号化アーキテクチャ API 仕様＆リファレンス」の「付録 A」で定義された公式な「標準名」が 1 つ存在します。たとえば、「MD5」は、RFC 1321 の RSA DSI で定義された RSA-MD5 メッセージダイジェストアルゴリズムの標準名です。
Java 2 SDK では、アルゴリズムまたはタイプへの参照時に、クライアントが標準名ではなく別名を使用することを可能にするエイリアス化方式が存在します。たとえば、「SUN」プロバイダのマスタークラス (
Sun.java) は、標準名が「SHA1withDSA」であるアルゴリズムの別名「SHA1/DSA」を定義します。このため、次の文は同じ意味になります。Signature sig = Signature.getInstance("SHA1withDSA", "SUN"); Signature sig = Signature.getInstance("SHA1/DSA", "SUN");別名は、「マスタークラス」内で定義できます (ステップ 3 を参照)。別名を定義するには、次の名前のプロパティを作成します。Alg.Alias.engineClassName.aliasNameengineClassName にはエンジンクラス (例:
Signature) の名前が、aliasName には設定する別名が当てはまります。プロパティの値は、別名を設定するアルゴリズム (またはタイプ) の標準アルゴリズム (またはタイプ) 名でなければなりません。例として、「SUN」プロバイダが、
Alg.Alias.Signature.SHA1/DSAという名前のプロパティに値SHA1withDSAを設定することにより、標準名が SHA1withDSA である署名アルゴリズムに別名「SHA1/DSA」を定義する場合を考えましょう。次にそのコードを示します。put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA");現在のところ、「SUN」プロバイダにより定義された別名は、クライアントがどのプロバイダを要求するとしても、すべてのクライアントから利用可能です。たとえば、SHA1withDSA アルゴリズムを実装する「MyPro」という名前のプロバイダを作成すると、その別名を定義しなくても、「SUN」により定義された別名「SHA1/DSA」を使用してプロバイダの SHA1withDSA 実装を参照できます。次にその方法を示します。
Signature sig = Signature.getInstance("SHA1/DSA", "MyPro");
警告: エイリアス化方式は、将来のリリースで変更または削除される可能性があります。
サービスの相互依存性
アルゴリズムによっては、他の種類のアルゴリズムの使用を要求することがあります。たとえば、署名アルゴリズムは通常、データの署名および検証にメッセージダイジェストアルゴリズムを使用する必要があります。別のアルゴリズムを要求するアルゴリズムを実装している場合、次のいずれかを実行できます。
- どちらのアルゴリズムにも対応した独自の実装の提供
- SDK の各インストールに含まれるデフォルトの「SUN」プロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにする。たとえば、実装している署名アルゴリズムがメッセージダイジェストアルゴリズムを要求する場合、次の呼び出しを行うことにより、MD5 メッセージダイジェストアルゴリズムを実装するクラスのインスタンスを取得できる
MessageDigest.getInstance("MD5", "SUN")
- 別の特定のプロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにする。これは、プロバイダを使用するすべてのクライアントが、インストールされた他方のプロバイダも保持する場合にだけ有効な方法である
- 別の (無指定の) プロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにする。つまり、アルゴリズムを名前で要求できる。ただし、特定のプロバイダは指定しない。次に例を示す
MessageDigest.getInstance("MD5")これは、プロバイダが使用される各 Java プラットフォームにインストールされた、要求されたアルゴリズムの実装 (この例では MD5) が少なくとも 1 つ存在することが確実な場合にだけ有効な方法である次に、アルゴリズムの相互依存の一般的な種類を示します。
署名アルゴリズムとメッセージダイジェストアルゴリズム
署名アルゴリズムは、メッセージダイジェストアルゴリズムを要求することがあります。たとえば、SHA1withDSA 署名アルゴリズムは、SHA-1 メッセージダイジェストアルゴリズムを要求します。署名アルゴリズムと (擬似) 乱数生成アルゴリズム
署名アルゴリズムは、(擬似) 乱数生成アルゴリズムを要求することがあります。たとえば、DSA 署名を生成するためには、対応する乱数生成アルゴリズムが必要です。鍵のペア生成アルゴリズムとメッセージダイジェストアルゴリズム
鍵のペア生成アルゴリズムは、メッセージダイジェストアルゴリズムを要求することがあります。たとえば、DSA 鍵は、SHA-1 メッセージダイジェストアルゴリズムを使って生成されます。アルゴリズムパラメータ生成とメッセージダイジェストアルゴリズム
アルゴリズムパラメータジェネレータは、メッセージダイジェストアルゴリズムの使用を要求することがあります。たとえば、DSA パラメータは、SHA-1 メッセージダイジェストアルゴリズムを使って生成されます。KeyStores とメッセージダイジェストアルゴリズム
キーストア実装は、メッセージダイジェストアルゴリズムを利用してキーハッシュ (「鍵」はユーザが提供するパスワード) を計算し、キーストアの統合性検査、およびキーストアが改変されていないことを確認することがあります。
鍵のペア生成アルゴリズムとアルゴリズムパラメータジェネレータ
鍵のペア生成アルゴリズムは、新規アルゴリズムパラメータセットの生成を必要とする場合があります。パラメータは、直接生成するか、アルゴリズムパラメータジェネレータを使用して生成できます。
鍵のペア生成、アルゴリズムパラメータ生成、および (擬似) 乱数生成アルゴリズム
鍵のペア生成アルゴリズムは、新しい鍵ペアおよび (場合によっては) 鍵に関連付けられた新規パラメータセットの生成に、乱数の発生源を必要とする場合があります。乱数の発生源は、SecureRandom オブジェクトにより表されます。鍵ペア生成アルゴリズムの実装は、鍵パラメータ自体を生成する場合もあれば、アルゴリズムパラメータジェネレータを使って鍵パラメータを生成する場合もあります。これらの場合、乱数の発生源を使ってアルゴリズムパラメータジェネレータを初期化する場合もあれば、そうでない場合もあります。
アルゴリズムパラメータジェネレータおよびアルゴリズムパラメータ
アルゴリズムパラメータジェネレータの
engineGenerateParametersメソッドは、AlgorithmParameters インスタンスを返す必要があります。署名および鍵ペア生成アルゴリズムまたは鍵ファクトリ
署名アルゴリズムを実装している場合、実装の
engineInitSignメソッドおよびengineInitVerifyメソッドは、基礎となるアルゴリズム (例: DSS アルゴリズム用の DSA 鍵) に対して有効な、引き渡しの行われる鍵を必要とします。次のいずれかを実行できます。
- 適切なインタフェース (例:
java.security.interfacesパッケージから DSAPrivateKey および DSAPublicKey インタフェースを実装するクラス) を実装する独自のクラスも作成し、独自の鍵ペアのジェネレータとこれらのタイプの鍵を返す鍵ファクトリのどちらかまたは両方を作成する。engineInitSignおよびengineInitVerifyに渡される鍵が、実装した鍵 (つまり、鍵ペアジェネレータまたは鍵ファクトリから生成された鍵) と同じタイプである必要がある。または、次の方法も可能である
- 他の鍵ペアジェネレータまたは他の鍵ファクトリから鍵を受け取る。これは、それらが署名の実装が必要な情報 (非公開鍵、公開鍵および鍵パラメータなど) を取得することを可能にする適切なインタフェースのインスタンスである場合に限り有効である。たとえば、DSS Signature クラス用の
engineInitSignメソッドは、java.security.interfaces.DSAPrivateKeyのインスタンスである任意の非公開鍵を受け取ることができるキーストアと 鍵および証明書ファクトリ
キーストアの実装は、鍵ファクトリを利用してキーストアに格納された鍵の構文解析を行うことがあります。また、証明書ファクトリを利用してキーストアに格納された証明書の構文解析を行います。
デフォルトの初期化
クライアントが明示的に鍵ペアジェネレータまたはアルゴリズムパラメータジェネレータを初期化しない場合、これらサービスの各プロバイダはデフォルトの初期化を提供 (およびドキュメント化) する必要があります。たとえば、「SUN」プロバイダは、DSA パラメータの生成に 1024 ビットのデフォルトモジュラスサイズ (強度) を使用します。
デフォルトの鍵ペアジェネレータのパラメータの要件
鍵ペアジェネレータを実装する場合、クライアントがパラメータを指定しない場合は、実装がデフォルトのパラメータを提供する必要があります。提供するドキュメント (ステップ 8) で、デフォルトパラメータを指定する必要があります。たとえば、「SUN」プロバイダの DSA 鍵ペアジェネレータは、512、768、および 1024 ビットの鍵ペア生成用に、コンパイル済みの
p、q、およびgデフォルト値のセットを提供します。次のp、q、およびg値は、1024 ビット DSA 鍵ペア生成用のデフォルト値として使用されます。p = fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 q = 9760508f 15230bcc b292b982 a2eb840b f0581cf5 g = f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a(ここで指定された
pおよびq値は、素数生成標準により、次の 160 ビットのシードを使って生成される。SEED:8d515589 4229d5e6 89ee01e6 018a237e 2cae64cdこのシードでは、カウンタが 92 の時にpおよびqを検出した)Provider.Service クラス
JDK 1.1 リリースに導入されて以来、セキュリティプロバイダは Hashtable エントリに入力された適切なフォーマットのキーと値の String ペアを使用して、サービス情報を公開してきました。この機構はシンプルで簡便ですが、カスタマイズの範囲が限られています。そのため、JDK 5.0 では、2 番目のオプションとして、Provider.Service クラスが導入されました。これを利用して、プロバイダはサービスおよびサポートに、以下で説明するような追加機能を通知できます。この追加機能は、String 値の HashTable エントリを使用する以前の方法と完全な互換性があることに留意してください。JDK 5.0 では、プロバイダはどちらの方法も選択でき、また同時に両方を使用することもできます。Provider.Service オブジェクトは、サービスに関するすべての情報をカプセル化します。このプロバイダは、サービス、型 (「MessageDigest」、「Signature」など)、アルゴリズム名、およびサービスを実装するクラス名を提供します。また、このサービス (別名) および属性に対する代替アルゴリズム名の一覧を持っています。この一覧は、名前と値の String ペアのマップです。さらに、newInstance() および supportsParameter() メソッドを定義します。これらのメソッドはデフォルトで実装されていますが、プロバイダがハードウェアセキュリティトークンとのインタフェースとなる場合は、必要に応じてプロバイダによるオーバーライドが可能です。
newInstance() メソッドは、新しい実装インスタンスを生成する必要がある場合に、セキュリティフレームワークによって使用されます。デフォルトの実装では、リフレクションを使用してサービス各種の標準的なコンストラクタが呼び出されます。「CertStore」を除くすべての標準サービスで、このコンストラクタは引数をとりません。newInstance() の constructorParameter は、この場合 null である必要があります。「CertStore」型のサービスでは、CertStoreParameters オブジェクトを使用するコンストラクタが呼び出されます。constructorParameter は、CertStoreParameters の null 以外のインスタンスである必要があります。セキュリティプロバイダは、newInstance() をオーバーライドして、その実装に適したインスタンス化を実装できます。直接呼び出すことも、Provider インスタンスまたはトークンに固有の追加情報を渡すコンストラクタを呼び出すこともできます。たとえば、システムに複数のスマートカードリーダがある場合、新しく作成されたサービスをどのリーダに関連付けるかという情報を渡すことができます。ただし、カスタマイズした場合でも、すべての実装は、上述の constructorParameter に関する規約に従わなければなりません。
supportsParameter() は、Service が指定されたパラメータを使用できるかどうかをテストします。このサービスがパラメータを使用できない場合、false を返します。このサービスがパラメータを使用できる場合、すばやいチェックが実行できない場合、またはステータスが不明な場合、true を返します。これは、ある種のサービスに対してセキュリティフレームワークにより使用され、一致しない実装が対象からすばやく除外されます。現状では、これは「Signature」、「Cipher」、「Mac」、「KeyAgreement」の標準サービスでのみ定義されています。この場合、parameter は Key のインスタンスである必要があります。たとえば、「Signature」サービスの場合、フレームワークはサービスをインスタンス化する前に、サービスが指定された Key を使用できるかどうかをテストします。デフォルトの実装では、上述のように、属性「SupportedKeyFormats」および「SupportedKeyClasses」が検査されます。ここでも、プロバイダはこのメソッドをオーバーライドして、追加テストを実装できます。
「SupportedKeyFormats」属性は、符号化された鍵 (key.getFormat() によって返される) でサポートされる形式の一覧で、「|」(パイプ) 文字で区切られています。たとえば、「X.509|PKCS#8」のようになります。「SupportedKeyClasses」属性は、インタフェースまたはクラス名の一覧で、「|」文字で区切られています。鍵オブジェクトは、指定されたクラスまたはインタフェースの 1 つ以上に割り当て可能な場合に、受け入れ可能と認識されます。言い換えれば、鍵オブジェクトのクラスがリスト表示されたいずれかのクラスのサブクラス (またはクラス自体) である場合、またはリスト表示されたインタフェースを実装する場合です。たとえば、値「java.security.interfaces.RSAPrivateKey|java.security.interfaces.RSAPublicKey」がこれに該当します。
サービスの追加および検索用の 4 つのメソッドが Provider クラスに追加されました。前述のように、これらのメソッドおよび既存の Properties メソッドの実装は、既存の Provider サブクラスとの互換性を保つように特別に設計されています。次のようにして実現されます。既存の Properties メソッドをエントリの追加に使用する場合、Provider クラスは、プロパティ文字列を解析して等価な Service オブジェクトに変換してから、 getService() を使用して検索するようにします。同様に、putService() メソッドを使用する場合、等価なプロパティ文字列がプロバイダのハッシュテーブルに同時に配置されます。プロバイダ実装が Provider クラス内のメソッドをオーバーライドする場合、実装がこの変換に干渉しないようにする必要があります。問題を防止するため、実装によって Provider クラスのメソッドがオーバーライドされないようにすることをお勧めします。
署名フォーマット
署名アルゴリズムを実装する場合、提供するドキュメント (ステップ 8) で署名 (
signメソッドの 1 つを使って生成される) を符号化する形式を指定する必要があります。たとえば、「SUN」プロバイダにより提供される SHA1withDSA 署名アルゴリズムは、署名を、標準 ASN.1 の 2 つの ASN.1 INTEGER値
rおよびsのシーケンスとして、次の順序で符号化します。SEQUENCE ::= { r INTEGER, s INTEGER }DSA インタフェースおよびその実装要件
Java 2 Security API には、DSA サービスを実装するプログラマが利用しやすいように、(java.security.interfacesパッケージ内の) 次のインタフェースが含まれます。 以降では、これらのインタフェースの実装要件について取り上げます。DSAKeyPairGenerator 実装
このインタフェースは使用されていません。これは、クライアントに対し、実装が提供するデフォルトパラメータの代わりに DSA 固有のパラメータを使用することを可能にする上で必要でした。しかし、AlgorithmParameterSpec パラメータをとる新規 KeyPairGenerator
initializeメソッドにより、クライアントがアルゴリズム固有のパラメータを示すことが可能になったため、Java 2 ではこれは必要ではなくなりました。DSAParams 実装
DSA 鍵ペアジェネレータを実装している場合、
p、q、およびgパラメータを保持したり返したりするために、DSAParams を実装するクラスを必要とします。DSAPrivateKey および DSAPublicKey インタフェースを実装する場合は、DSAParams 実装も必要です。DSAPublicKey および DSAPrivateKey は、どちらも DSAParams オブジェクトを返す
getParamsメソッドを含む DSAKey インタフェースを継承します。詳細は、「DSAPrivateKey および DSAPublicKey 実装」を参照してください。注: SDK に組み込み済みの DSAParams 実装である
java.security.spec.DSAParameterSpecクラスが存在します。DSAPrivateKey および DSAPublicKey 実装
DSA 鍵ペアジェネレータまたは鍵ファクトリを実装する場合、DSAPrivateKey および DSAPublicKey インタフェースを実装するクラスを作成する必要があります。DSA 鍵ペアジェネレータを実装する場合、(KeyPairGeneratorSpi サブクラスの)
generateKeyPairメソッドはこれらのインタフェース実装のインスタンスを返します。DSA 鍵ファクトリを実装する場合、(KeyFactorySpi サブクラスの)
engineGeneratePrivateメソッドは DSAPrivateKey 実装のインスタンスを返し、engineGeneratePublicメソッドは DSAPublicKey 実装のインスタンスを返します。また、
engineGetKeySpecおよびengineTranslateKeyメソッドは、引き渡される鍵が DSAPrivateKey または DSAPublicKey 実装のインスタンスであることを期待します。インタフェース実装により提供されるgetParamsメソッドは、鍵からパラメータを取得および抽出し、その後パラメータを使用する上で有用です。たとえば、DSAParameterSpec コンストラクタへのパラメータとして使用して、DSA 用の KeyPairGenerator オブジェクトの初期化に使用可能なパラメータ値からパラメータ仕様を作成することができます。DSA 署名アルゴリズムを実装する場合、(SignatureSpi サブクラスの)
engineInitSignメソッドは DSAPrivateKey が渡されることを期待し、engineInitVerifyメソッドは DSAPublicKey が渡されることを期待します。注 - DSAPublicKey および DSAPrivateKey インタフェースはそれぞれ、DSA 公開鍵および非公開鍵に対する非常に一般的なプロバイダ非依存のインタフェースを定義します。KeyFactorySpi サブクラスの
engineGetKeySpecおよびengineTranslateKeyメソッドは、引き渡される鍵が実際にプロバイダ独自の DSAPrivateKey または DSAPublicKey 実装のインスタンスであるかどうかを (たとえば、プロバイダ固有の実装の詳細を利用する目的で) チェックすることもできます。SignatureSpi サブクラスの DSA 署名アルゴリズムengineInitSignおよびengineInitVerifyメソッドについても、同様のことが当てはまります。DSAPublicKey および DSAPrivateKey インタフェースを実装するクラスを使ってどんなメソッドを実装する必要があるかについては、次のインタフェース署名に注目してください。
java.security.interfaces パッケージ内: public interface DSAPrivateKey extends DSAKey, java.security.PrivateKey public interface DSAPublicKey extends DSAKey, java.security.PublicKey public interface DSAKey java.security パッケージ内: public interface PrivateKey extends Key public interface PublicKey extends Key public interface Key extends java.io.SerializableDSAPrivateKey および DSAPublicKey インタフェースを実装するためには、これらのインタフェースが定義したメソッド、およびこれらのインタフェースが継承するインタフェースが定義したメソッドを実装する必要があります。
このため、非公開鍵の場合、以下を実装するクラスを提供する必要があります。
- DSAPrivateKey インタフェースから
getXメソッド
- java.security.interfaces.DSAKey インタフェースから
getParamsメソッド。これは、DSAPrivateKey が DSAKey を継承するため。注:getParamsメソッドは、DSAParams オブジェクトを返す。このため、DSAParams 実装も保持する必要がある
- java.security.Key インタフェースから、
getAlgorithm、getEncoded、およびgetFormatメソッド。これは、DSAPrivateKey がjava.security.PrivateKeyを継承し、PrivateKey が Key を継承するため 同様に、公開 DSA 鍵の場合、以下を実装するクラスを提供する必要があります。
- DSAPublicKey インタフェースから
getYメソッド
- java.security.interfaces.DSAKey インタフェースから
getParamsメソッド。これは、DSAPublicKey が DSAKey を継承するため。注:getParamsメソッドは、DSAParams オブジェクトを返す。このため、DSAParams 実装も保持する必要がある
- java.security.Key インタフェースから、
getAlgorithm、getEncoded、およびgetFormatメソッド。これは、DSAPublicKey がjava.security.PublicKeyを継承し、PublicKey が Key を継承するためRSA インタフェースおよびその実装要件
Java 2 SDK Security API には、RSA サービスを実装するプログラマが利用しやすいように、(java.security.interfacesパッケージ内の) 次のインタフェースが含まれます。 以降では、これらのインタフェースの実装要件について取り上げます。RSAPrivateKey、 RSAPrivateCrtKey、および RSAPublicKey 実装
RSA 鍵ペアジェネレータまたは鍵ファクトリを実装する場合、RSAPrivateKey (と RSAPrivateCrtKey のどちらかまたは両方) および RSAPublicKey インタフェースを実装するクラスを作成する必要があります。RSAPrivateCrtKey は、中国剰余定理 (CRT) 表現を使用した、RSA 非公開鍵へのインタフェースです。RSA 鍵ペアジェネレータを実装する場合、(KeyPairGeneratorSpi サブクラスの)
generateKeyPairメソッドはこれらのインタフェース実装のインスタンスを返します。RSA 鍵ファクトリを実装する場合、(KeyFactorySpi サブクラスの)
engineGeneratePrivateメソッドは RSAPrivateKey (または RSAPrivateCrtKey) 実装のインスタンスを返し、engineGeneratePublicメソッドは RSAPublicKey 実装のインスタンスを返します。また、
engineGetKeySpecおよびengineTranslateKeyメソッドは、引き渡される鍵が RSAPrivateKey、RSAPrivateCrtKey、または RSAPublicKey 実装のインスタンスであることを期待します。RSA 署名アルゴリズムを実装する場合、(SignatureSpi サブクラスの)
engineInitSignメソッドは RSAPrivateKey または RSAPrivateCrtKey が渡されることを期待し、engineInitVerifyメソッドは RSAPublicKey が渡されることを期待します。注 - RSAPublicKey、RSAPrivateCrtKey、および RSAPrivateKey インタフェースはそれぞれ、RSA 公開鍵および非公開鍵に対する非常に一般的なプロバイダ非依存のインタフェースを定義します。KeyFactorySpi サブクラスの
engineGetKeySpecおよびengineTranslateKeyメソッドは、引き渡される鍵が実際にプロバイダ独自の RSAPrivateKey、RSAPrivateCrtKey、または RSAPublicKey 実装のインスタンスであるかどうかを (たとえば、プロバイダ固有の実装の詳細を利用する目的で) チェックすることもできます。SignatureSpi サブクラスの RSA 署名アルゴリズムengineInitSignおよびengineInitVerifyメソッドについても、同様のことが当てはまります。RSAPublicKey、RSAPrivateCrtKey、および RSAPrivateKey インタフェースを実装するクラスを使ってどんなメソッドを実装する必要があるかについては、次のインタフェース署名に注目してください。
java.security.interfaces パッケージ内: public interface RSAPrivateKey extends java.security.PrivateKey public interface RSAPrivateCrtKey extends RSAPrivateKey public interface RSAPublicKey extends java.security.PublicKey java.security パッケージ内: public interface PrivateKey extends Key public interface PublicKey extends Key public interface Key extends java.io.SerializableRSAPrivateKey、RSAPrivateCrtKey、および RSAPublicKey インタフェースを実装するためには、これらのインタフェースが定義したメソッド、およびこれらのインタフェースが継承するインタフェースが定義したメソッドを実装する必要があります。
このため、RSA 非公開鍵の場合、以下を実装するクラスを提供する必要があります。
- RSAPrivateKey インタフェースから
getModulusおよびgetPrivateExponentメソッド
- java.security.Key インタフェースから、
getAlgorithm、getEncoded、およびgetFormatメソッド。これは、RSAPrivateKey がjava.security.PrivateKeyを継承し、PrivateKey が Key を継承するため同様に、中国剰余定理 (CRT) 表現を使用する RSA 非公開鍵の場合、以下を実装するクラスを提供する必要があります。
- RSA 非公開鍵用にリストアップした上述のメソッドすべて。これは RSAPrivateCrtKey が
java.security.interfaces.RSAPrivateKeyを継承するため
- RSAPrivateCrtKey インタフェースから
getPublicExponent、getPrimeP、getPrimeQ、getPrimeExponentP、getPrimeExponentQ、およびgetCrtCoefficientメソッド公開 RSA 鍵の場合、以下を実装するクラスを提供する必要があります。
- RSAPublicKey インタフェースから
getModulusおよびgetPublicExponentメソッド
- java.security.Key インタフェースから、
getAlgorithm、getEncoded、およびgetFormatメソッド。これは、RSAPublicKey がjava.security.PublicKeyを継承し、PublicKey が Key を継承するため他のアルゴリズムタイプ用インタフェース
これまでに説明した通り、Java 2 SDK Security API には、DSA および RSA サービスを実装するプログラマの利用に便利なインタフェースが含まれます。現時点では、API には、他のアルゴリズムに対応した同様のインタフェースは含まれません。このため、独自に定義する必要があります。異なるアルゴリズム用の鍵ペアジェネレータを実装する場合、実装が提供するデフォルトパラメータではなく、アルゴリズム固有のパラメータをクライアントが提供して使用する場合にクライアントが呼び出すことのできる 1 つ以上の
initializeメソッドを使ってインタフェースを作成する必要があります。KeyPairGeneratorSpi のサブクラスは、このインタフェースを実装する必要があります。非 DSA および非 RSA アルゴリズム用の非公開鍵および公開鍵の場合、現在のところ
java.security.interfacesに対応する、DSA 用の DSAPrivateKey や DSAPublicKey、および RSA 用の RSAPrivateKey や RSAPublicKey は存在しません。同様のインタフェースを作成して、実装クラスを提供することをお勧めします。公開鍵のインタフェースは、PublicKey インタフェースを継承する必要があります。同様に、非公開鍵のインタフェースは、PrivateKey インタフェースを継承する必要があります。アルゴリズムパラメータの仕様のインタフェースおよびクラス
アルゴリズムパラメータの仕様は、アルゴリズムとともに使われるパラメータのセットの透明な表現です。
パラメータのセットの「透明な」表現とは、対応する仕様クラスに定義された get メソッドの 1 つを使って、各値に個々にアクセスできるということです。たとえば、DSAParameterSpec は、
getP、getQ、およびgetGメソッドを定義して、それぞれ p、q、および g パラメータにアクセスします。これと対照的なのが、AlgorithmParameters エンジンクラスによって提供される場合のような「不透明な」表現です。この場合は、鍵データ値に直接アクセスすることはできません。パラメータセットに関連付けられたアルゴリズム名の取得 (
getAlgorithmによる)、およびそのパラメータセット用のある種の符号化の取得 (getEncodedによる) しかできません。AlgorithmParametersSpi、AlgorithmParameterGeneratorSpi、または KeyPairGeneratorSpi 実装を提供する場合、AlgorithmParameterSpec インタフェースを利用する必要があります。理由は、これら各クラスには、AlgorithmParameterSpec パラメータを取るメソッドが含まれるためです。この種のメソッドは、インタフェースのどの実装が実際に引き渡されるかを判定し、それに応じて動作する必要があります。
Java 2 SDK には 1 つの AlgorithmParameterSpec 実装、DSAParameterSpec クラスが含まれます。DSA アルゴリズムパラメータを対象としている場合、このクラスを利用できます。タイプの異なるアルゴリズムに対応したアルゴリズムパラメータを対象に操作を行う場合、そのタイプのアルゴリズムに適した独自の AlgorithmParameterSpec 実装を提供する必要があります。
Java 2 SDK は、次のアルゴリズムパラメータ仕様インタフェースおよびクラスを、
java.security.specパッケージ内で定義します。AlgorithmParameterSpec インタフェース
AlgorithmParameterSpec は、暗号化パラメータの透明な仕様へのインタフェースです。このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべてのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。すべてのパラメータの仕様で、このインタフェースを実装する必要があります。
DSAParameterSpec クラス
AlgorithmParameterSpec および DSAParams インタフェースを実装するこのクラスは、DSA アルゴリズムで使われるパラメータのセットを指定します。このクラスには、次のメソッドがあります。public BigInteger getP() public BigInteger getQ() public BigInteger getG()これらのメソッドは、DSA アルゴリズムパラメータであるプライムのp、サブプライムのq、およびベースのgを返します。多くの DSA サービスタイプは、このクラスを有用と見なします。たとえば、このクラスは、「SUN」プロバイダが実装する DSA 署名、鍵ペアジェネレータ、アルゴリズムパラメータジェネレータ、およびアルゴリズムパラメータクラスにより利用されます。具体例を挙げると、アルゴリズムパラメータ実装は、AlgorithmParameterSpec を返す
getParameterSpecメソッド用の実装を含む必要があります。「SUN」により提供される DSA アルゴリズムパラメータ実装は、DSAParameterSpec クラスのインスタンスを返します。鍵ファクトリにより要求される鍵仕様のインタフェースおよびクラス
鍵ファクトリは、不透明な鍵 (Key タイプ) と鍵仕様との間の双方向変換を提供します。このため、鍵ファクトリを実装する場合には、鍵仕様を理解して利用することが必要になります。場合によっては、独自の鍵仕様を実装する必要もあります。 鍵仕様、Java 2 SDK で提供されるインタフェースとクラス、および仕様に関する鍵ファクトリの要件についての詳細は、後述します。鍵仕様は、鍵を構成する鍵データの透明な表現です。鍵がハードウェアデバイス上に格納されている場合は、その鍵仕様には、デバイス上の鍵の識別を助ける情報が含まれていることがあります。
鍵の「透明な」表現とは、対応する仕様クラスで定義された get メソッドの 1 つを使って、各鍵データに個々にアクセスできるということです。たとえば、
java.security.spec.DSAPrivateKeySpecは、getX、getP、getQ、およびgetGメソッドを定義して、非公開鍵xおよび鍵の計算に使用する DSA アルゴリズムのパラメータ (プライムのp、サブプライムのqおよびベースのg) にアクセスします。これと対照的なのが、Key インタフェースによって定義されるような、「不透明な」表現です。「不透明な」表現では、パラメータフィールドに直接アクセスできません。つまり、「不透明」さにより、鍵へのアクセスが、Key インタフェースによって定義される
getAlgorithm、getEncoded、およびgetFormatの 3 つのメソッドだけに制限されます。鍵は、アルゴリズム特定型か、またはアルゴリズム独立型の符号化形式 (ASN.1 など) の方法で指定できます。たとえば、DSA 非公開鍵は、非公開鍵のコンポーネント
x、p、q、およびgによって指定するか (DSAPrivateKeySpec を参照)、または、非公開鍵の DER 符号化を使って指定することが可能です (PKCS8EncodedKeySpec を参照)。Java 2 SDK は、次の鍵仕様インタフェースおよびクラスを、
java.security.specパッケージ内で定義します。KeySpec インタフェース
このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべての鍵仕様をグループ化すること (およびそれらのグループに安全な型を提供すること) です。すべての鍵仕様で、このインタフェースを実装する必要があります。
Java 2 SDK は、KeySpec インタフェースであるDSAPrivateKeySpec、DSAPublicKeySpec、RSAPrivateKeySpec、RSAPublicKeySpec、EncodedKeySpec、PKCS8EncodedKeySpec、および X509EncodedKeySpec を実装するいくつかのクラスを提供します。
SDK が対応する KeySpec クラスを提供していない鍵タイプ (例: Your_PublicKey_type および Your_PrivateKey_type) をプロバイダが使用する場合、2 通りの対処方法が考えられます。1 つは、独自の鍵仕様を実装する方法です。
- ユーザが特定の鍵データ値にアクセスする必要が一切ない場合、その鍵タイプ用の KeySpec クラスを提供する必要はない
この方法では、ユーザは常に、プロバイダが提供する該当する鍵タイプ用の適切な KeyPairGenerator を使って Your_PublicKey_type および Your_PrivateKey_type 鍵を作成する。あとで使用する目的で生成された鍵を格納する場合には、(Key インタフェースの
getEncodedメソッドを使って) 鍵の符号化を取得する。符号化から Your_PublicKey_type または Your_PrivateKey_type 鍵を作成する場合 (署名または検証目的で Signature オブジェクトを初期化する場合など) は、符号化から X509EncodedKeySpec または PKCS8EncodedKeySpec のインスタンスを作成して、プロバイダが提供する適切な KeyFactory に渡す。KeyFactory のgeneratePublicおよびgeneratePrivateメソッドは、要求された PublicKey (Your_PublicKey_type のインスタンス) または PrivateKey (Your_PrivateKey_typeのインスタンス) オブジェクトをそれぞれ返す
- ユーザが鍵タイプの特定の鍵データ値にアクセスするか、上記の場合のようにエンコーディングからではなく鍵データおよび関連するパラメータ値から鍵タイプの鍵を構築する必要が予想される場合、適切なコンストラクタメソッドおよび「get」メソッドを使って、新しい KeySpec クラス (KeySpec インタフェースを実装するクラス) を指定して、鍵タイプ用の鍵データフィールドおよび関連するパラメータ値を返すようにする必要がある。これらのクラスは、Java 2 SDK で提供される DSAPrivateKeySpec および DSAPublicKeySpec クラスが行うのと同様の方法で指定する。これらのクラスは、プロバイダクラスとともに (たとえば、プロバイダ JAR ファイルの一部として) 提供する必要がある
DSAPrivateKeySpec クラス
このクラス (KeySpec インタフェースを実装) は、関連付けられたパラメータを使って DSA 非公開鍵を指定します。このクラスには、次のメソッドがあります。public BigInteger getX() public BigInteger getP() public BigInteger getQ() public BigInteger getG()これらのメソッドは、非公開鍵x、および鍵の計算に使用される DSA アルゴリズムパラメータであるプライムのp、サブプライムのq、およびベースのgを返します。DSAPublicKeySpec クラス
このクラス (KeySpec インタフェースを実装) は、関連付けられたパラメータを使って DSA 公開鍵を指定します。このクラスには、次のメソッドがあります。public BigInteger getY() public BigInteger getP() public BigInteger getQ() public BigInteger getG()これらのメソッドは、公開鍵y、および鍵の計算に使用される DSA アルゴリズムパラメータであるプライムのp、サブプライムのq、およびベースのgを返します。RSAPrivateKeySpec クラス
このクラス (KeySpec インタフェースを実装) は、RSA 非公開鍵を指定します。このクラスには、次のメソッドがあります。public BigInteger getModulus() public BigInteger getPrivateExponent()これらのメソッドは、RSA 非公開鍵を構成する RSA モジュラスnおよび非公開指数dの値を返します。RSAPrivateCrtKeySpec クラス
このクラス (RSAPrivateKeySpec クラスを継承) は、PKCS#1 標準で定義されているように、中国剰余定理 (CRT) 情報の値を使って、RSA 非公開鍵を指定します。このクラスには、スーパークラスの RSAPrivateKeySpec から継承したメソッドのほかに、次のメソッドがあります。public BigInteger getPublicExponent() public BigInteger getPrimeP() public BigInteger getPrimeQ() public BigInteger getPrimeExponentP() public BigInteger getPrimeExponentQ() public BigInteger getCrtCoefficient()これらのメソッドは、公開指数eおよび CRT 情報の整数を返します。CRT 情報の整数は、モジュラスnの素因数p、nの素因数q、指数d mod (p-1)、指数d mod (q-1)、および中国剰余定理係数(q の逆数) mod pです。RSA 非公開鍵は、論理的にはモジュラスと非公開の指数だけで構成されます。CRT 値は、効率を向上させる目的で存在します。
RSAPublicKeySpec クラス
このクラス (KeySpec インタフェースを実装) は、RSA 公開鍵を指定します。このクラスには、次のメソッドがあります。public BigInteger getModulus() public BigInteger getPublicExponent()これらのメソッドは、RSA 公開鍵を構成する RSA モジュラスnおよび公開指数eの値を返します。EncodedKeySpec クラス
この abstract クラス (KeySpec インタフェースを実装する) は、符号化された形式の公開鍵または非公開鍵を表します。そのgetEncodedメソッドは、次の符号化された鍵を返します。public abstract byte[] getEncoded();このクラスのgetFormatメソッドは、次の符号化形式の名前を返します。public abstract String getFormat();Java 2 SDK は、EncodedKeySpec インタフェースであるPKCS8EncodedKeySpec および X509EncodedKeySpec を実装する 2 つのクラスを提供します。必要に応じて、これらの、または他の鍵エンコーディング用に独自の EncodedKeySpec 実装を提供することもできます。
PKCS8EncodedKeySpec クラス
このクラスは、EncodedKeySpec のサブクラスで、PKCS #8 標準で指定された形式に従って、非公開鍵の DER 符号化を表現します。このクラスの
getEncodedメソッドは、PKCS #8 標準に従って符号化された鍵のバイトを返します。このクラスのgetFormatメソッドは、文字列 PKCS#8 を返します。X509EncodedKeySpec クラス
このクラスは、EncodedKeySpec のサブクラスで、X.509 標準で指定された形式に従って、公開鍵または非公開鍵の DER 符号化を表現します。このクラスの
getEncodedメソッドは、X.509 標準に従って符号化された鍵のバイトを返します。このクラスのgetFormatメソッドは、文字列 X.509 を返します。新規オブジェクト識別子の追加
以下の情報は、「Java 暗号化アーキテクチャ API 仕様＆リファレンス」の「付録 A」で標準アルゴリズムとして挙げられていないアルゴリズムを提供するプロバイダに当てはまります。OID から名前へのマッピング
JCA が、暗号化アルゴリズム実装について、アルゴリズム識別子から (たとえば、証明書内で符号化されたものとして) インスタンスの生成を行う必要がある場合があります。アルゴリズム識別子には、定義上、アルゴリズムのオブジェクト識別子 (OID) が含まれます。たとえば、X.509 証明書の署名を検証するために、JCA は証明書内で符号化された署名アルゴリズム識別子から署名アルゴリズムを判別し、そのアルゴリズムの Signature オブジェクトについてインスタンスを生成してから、検証のために初期化します。JCA でアルゴリズムを検索するには、プロバイダマスターファイルで、アルゴリズムの別名エントリとしてアルゴリズム識別子を指定します。
put("Alg.Alias.<engine_type>.1.2.3.4.5.6.7.8", "<algorithm_alias_name>");アルゴリズムが複数のオブジェクト識別子で知られている場合、オブジェクト識別子ごとに別名エントリを作成する必要があります。JCA によるこの種のマッピングの例として、アルゴリズム (
Foo) が署名アルゴリズムで、ユーザがkeytoolコマンドを実行して (署名) アルゴリズムの別名を指定する場合を考えます。% keytool -genkey -sigalg 1.2.3.4.5.6.7.8この場合、プロバイダのマスターファイルには、次のエントリを含める必要があります。put("Signature.Foo", "com.xyz.MyFooSignatureImpl"); put("Alg.Alias.Signature.1.2.3.4.5.6.7.8", "Foo");この種のマッピングの別の例として、(1) アルゴリズムがキータイプアルゴリズムで、プログラムが (SUN プロバイダの X.509 実装を使って) 証明書を構文解析し、証明書から公開鍵を抽出して、Signature オブジェクトを初期化する場合、および (2)keytoolユーザが、対応する鍵のペアの生成後に (デジタル署名を実行するために) キータイプの非公開鍵にアクセスしようとする場合、を挙げることができます。これらの場合、プロバイダのマスターファイルには、次のエントリを含める必要があります。put("KeyFactory.Foo", "com.xyz.MyFooKeyFactoryImpl"); put("Alg.Alias.KeyFactory.1.2.3.4.5.6.7.8", "Foo");名前から OID へのマッピング
JCA が逆マッピング (つまり、アルゴリズム名からその関連付けられた OID への) を実行する必要がある場合、アルゴリズムと関連付けられた OID の 1 つに対して、次の形式の別名エントリを提供する必要があります。put("Alg.Alias.Signature.OID.1.2.3.4.5.6.7.8", "MySigAlg");アルゴリズムが複数のオブジェクト識別子で知られている場合、優先度の高いものに接頭辞「OID」を追加します。JCA がこの種のマッピングを実行する一例として、ユーザが
keytoolを、-sigalgオプションを取る任意のモードで実行する場合を挙げることができます。たとえば、-genkeyおよび-certreqコマンドが呼び出されると、ユーザは-sigalgオプションを使って (署名) アルゴリズムを指定できます。
以下に示すのはSun.javaファイルのコピーです。このファイルには、「SUN」という名前のプロバイダ用のマスタークラスであるSunというクラスが含まれます。(このプロバイダは、SDK の各インストールに含まれます。)すべてのマスタークラスの場合と同様、このクラスは Provider のサブクラスです。これは、「SUN」プロバイダが提供するすべての暗号化サービス実装のクラス名およびパッケージ位置を指定します。Java 2 Security は、さまざまなアルゴリズムや他のサービスが要求されると、この情報を使って検索を実行します。
以下に示すコードは、マスタークラスの例です。
/* * @(#)Sun.java 1.28 99/05/27 * * Copyright 1996-1998 by Sun Microsystems, Inc., * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. * All rights reserved. * * This software is the confidential and proprietary information * of Sun Microsystems, Inc. ("Confidential Information").You * shall not disclose such Confidential Information and shall use * it only in accordance with the terms of the license agreement * you entered into with Sun. */ package sun.security.provider; import java.io.*; import java.util.*; import java.security.*; /** * The SUN Security Provider. * * @author Benjamin Renaud * * @version 1.28, 05/27/99 */ /** * Defines the SUN provider. * * Algorithms supported, and their names: * * - SHA is the message digest scheme described in FIPS 180-1. * Aliases for SHA are SHA-1 and SHA1. * * - SHA1withDSA is the signature scheme described in FIPS 186. * (SHA used in DSA is SHA-1:FIPS 186 with Change No 1.) * Aliases for SHA1withDSA are DSA, DSS, SHA/DSA, SHA-1/DSA, SHA1/DSA, * SHAwithDSA, DSAWithSHA1, and the object * identifier strings "OID.1.3.14.3.2.13", "OID.1.3.14.3.2.27" and * "OID.1.2.840.10040.4.3". * * - DSA is the key generation scheme as described in FIPS 186. * Aliases for DSA include the OID strings "OID.1.3.14.3.2.12" * and "OID.1.2.840.10040.4.1". * * - MD5 is the message digest scheme described in RFC 1321. * There are no aliases for MD5. */ public final class Sun extends Provider { private static final String INFO = "SUN " + "(DSA key/parameter generation; DSA signing; " + "SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore)"; public Sun() { /* We are the SUN provider */ super("SUN", 1.2, INFO); AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { /* * Signature engines */ put("Signature.SHA1withDSA", "sun.security.provider.DSA"); put("Alg.Alias.Signature.DSA", "SHA1withDSA"); put("Alg.Alias.Signature.DSS", "SHA1withDSA"); put("Alg.Alias.Signature.SHA/DSA", "SHA1withDSA"); put("Alg.Alias.Signature.SHA-1/DSA", "SHA1withDSA"); put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA"); put("Alg.Alias.Signature.SHAwithDSA", "SHA1withDSA"); put("Alg.Alias.Signature.DSAWithSHA1", "SHA1withDSA"); put("Alg.Alias.Signature.OID.1.2.840.10040.4.3", "SHA1withDSA"); put("Alg.Alias.Signature.1.2.840.10040.4.3", "SHA1withDSA"); put("Alg.Alias.Signature.1.3.14.3.2.13", "SHA1withDSA"); put("Alg.Alias.Signature.1.3.14.3.2.27", "SHA1withDSA"); /* * Key Pair Generator engines */ put("KeyPairGenerator.DSA", "sun.security.provider.DSAKeyPairGenerator"); put("Alg.Alias.KeyPairGenerator.OID.1.2.840.10040.4.1", "DSA"); put("Alg.Alias.KeyPairGenerator.1.2.840.10040.4.1", "DSA"); put("Alg.Alias.KeyPairGenerator.1.3.14.3.2.12", "DSA"); /* * Digest engines */ put("MessageDigest.MD5", "sun.security.provider.MD5"); put("MessageDigest.SHA", "sun.security.provider.SHA"); put("Alg.Alias.MessageDigest.SHA-1", "SHA"); put("Alg.Alias.MessageDigest.SHA1", "SHA"); /* * Algorithm Parameter Generator engines */ put("AlgorithmParameterGenerator.DSA", "sun.security.provider.DSAParameterGenerator"); /* * Algorithm Parameter engines */ put("AlgorithmParameters.DSA", "sun.security.provider.DSAParameters"); put("Alg.Alias.AlgorithmParameters.1.3.14.3.2.12", "DSA"); put("Alg.Alias.AlgorithmParameters.1.2.840.10040.4.1", "DSA"); /* * Key factories */ put("KeyFactory.DSA", "sun.security.provider.DSAKeyFactory"); put("Alg.Alias.KeyFactory.1.3.14.3.2.12", "DSA"); put("Alg.Alias.KeyFactory.1.2.840.10040.4.1", "DSA"); /* * SecureRandom */ put("SecureRandom.SHA1PRNG", "sun.security.provider.SecureRandom"); /* * Certificates */ put("CertificateFactory.X509", "sun.security.provider.X509Factory"); put("Alg.Alias.CertificateFactory.X.509", "X509"); /* * KeyStore */ put("KeyStore.JKS", "sun.security.provider.JavaKeyStore"); /* * KeySize */ put("Signature.SHA1withDSA KeySize", "1024"); put("KeyPairGenerator.DSA KeySize", "1024"); put("AlgorithmParameterGenerator.DSA KeySize", "1024"); /* * Implementation type:software or hardware */ put("Signature.SHA1withDSA ImplementedIn", "Software"); put("KeyPairGenerator.DSA ImplementedIn", "Software"); put("MessageDigest.MD5 ImplementedIn", "Software"); put("MessageDigest.SHA ImplementedIn", "Software"); put("AlgorithmParameterGenerator.DSA ImplementedIn", "Software"); put("AlgorithmParameters.DSA ImplementedIn", "Software"); put("KeyFactory.DSA ImplementedIn", "Software"); put("SecureRandom.SHA1PRNG ImplementedIn", "Software"); put("CertificateFactory.X509 ImplementedIn", "Software"); put("KeyStore.JKS ImplementedIn", "Software"); return null; } }); } }
次に示すのは、java.securityファイルのコピーで、JRE の各インストールに含まれます。このファイルは次の場所にあります。ここで、<java-home> は JRE がインストールされているディレクトリを指します。つまり、J2SDK バージョン 1.4 を Solaris の<java-home>/lib/security/java.security [Solaris] <java-home>\lib\security\java.security [Win32]/home/user1/j2sdk1.4.0ディレクトリにインストールしている場合、または Win32 のC:\j2sdk1.4.0ディレクトリにインストールしている場合は、ファイルは次の場所にあることになります。同様に、Java 2 Runtime Environment バージョン 1.4 を Solaris の/home/user1/j2sdk1.4.0/jre/lib/security/java.security [Solaris] C:\j2sdk1.4.0\jre\lib\security\java.security [Win32]/home/user1/j2re1.4.0ディレクトリにインストールしている場合、または Win32 のC:\j2re1.4.0ディレクトリにインストールしている場合は、ファイルは次の場所にあることになります。このファイルにプロバイダに関する情報を追加する例については、ステップ 5 を参照してください。/home/user1/j2re1.4.0/lib/security/java.security [Solaris] C:\j2re1.4.0\lib\security\java.security [Win32]# # This is the "master security properties file". # # In this file, various security properties are set for use by # java.security classes.This is where users can statically register # Cryptography Package Providers ("providers" for short).The term # "provider" refers to a package or set of packages that supply a # concrete implementation of a subset of the cryptography aspects of # the Java Security API.A provider may, for example, implement one or # more digital signature algorithms or message digest algorithms. # # Each provider must implement a subclass of the Provider class. # To register a provider in this master security properties file, # specify the Provider subclass name and priority in the format # # security.provider.n=className # # This declares a provider, and specifies its preference # order n.The preference order is the order in which providers are # searched for requested algorithms (when no specific provider is # requested).The order is 1-based; 1 is the most preferred, followed # by 2, and so on. # # className must specify the subclass of the Provider class whose # constructor sets the values of various properties that are required # for the Java Security API to look up the algorithms or other # facilities implemented by the provider. # # There must be at least one provider specification in java.security. # There is a default provider that comes standard with the JDK.It # is called the "SUN" provider, and its Provider subclass # named Sun appears in the sun.security.provider package.Thus, the # "SUN" provider is registered via the following: # # security.provider.1=sun.security.provider.Sun # # (The number 1 is used for the default provider.) # # Note:Statically registered Provider subclasses are instantiated # when the system is initialized.Providers can be dynamically # registered instead by calls to either the addProvider or # insertProviderAt method in the Security class. # # List of providers and their preference orders (see above): # security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider security.provider.3=com.sun.rsajca.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider # # Select the source of seed data for SecureRandom.By default it uses # a system/thread activity algorithm.Optionally, if the platform supports # it an entropy gathering device can be selected. # #securerandom.source=file:/dev/random # # The entropy gathering device is described as a URL and can # also be specified with the property "java.security.egd".次に例を示します。 # -Djava.security.egd=file:/dev/urandom # Specifying this property will override the securerandom.source setting. # # Class to instantiate as the system Policy.This is the name of the class # that will be used as the Policy object. # policy.provider=sun.security.provider.PolicyFile # The default is to have a single system-wide policy file, # and a policy file in the user's home directory. policy.url.1=file:${java.home}/lib/security/java.policy policy.url.2=file:${user.home}/.java.policy # whether or not we expand properties in the policy file # if this is set to false, properties (${...}) will not be expanded in policy # files. policy.expandProperties=true # whether or not we allow an extra policy to be passed on the command line # with -Djava.security.policy=somefile.Comment out this line to disable # this feature. policy.allowSystemProperty=true # whether or not we look into the IdentityScope for trusted Identities # when encountering a 1.1 signed JAR file.If the identity is found # and is trusted, we grant it AllPermission. policy.ignoreIdentityScope=false # # Default keystore type. # keystore.type=jks # # Class to instantiate as the system scope: # system.scope=sun.security.provider.IdentityDatabase # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageAccess unless the # corresponding RuntimePermission ("accessClassInPackage."+package) has # been granted. package.access=sun. # # List of comma-separated packages that start with or equal this string # will cause a security exception to be thrown when # passed to checkPackageDefinition unless the # corresponding RuntimePermission ("defineClassInPackage."+package) has # been granted. # # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # #package.definition= # # Determines whether this properties file can be appended to # or overridden on the command line via -Djava.security.properties # security.overridePropertiesFile=true # # Determines the default key and trust manager factory algorithms for # the javax.net.ssl package. # ssl.KeyManagerFactory.algorithm=SunX509 ssl.TrustManagerFactory.algorithm=SunX509 # # Determines the default SSLSocketFactory and SSLServerSocketFactory # provider implementations for the javax.net.ssl package.If, due to # export and/or import regulations, the providers are not allowed to be # replaced, changing these values will produce non-functional # SocketFactory or ServerSocketFactory implementations. # #ssl.SocketFactory.provider= #ssl.ServerSocketFactory.provider=
|
Copyright © 1996-2003 Sun Microsystems, Inc.All Rights Reserved. コメントの送付先: java-security@sun.com。これは購読リストではありません。 |
Java ソフトウェア |