JavaTM 暗号化アーキテクチャ用プロバイダの実装方法


最終更新日:2001 年 5 月 1 日

はじめに
このドキュメントの対象読者
関連ドキュメント


エンジンクラスおよび対応する SPI クラス


プロバイダの実装および統合までのステップ
ステップ 1: サービス実装コードの記述
ステップ 2: プロバイダの命名
ステップ 3: プロバイダのサブクラスである「マスタークラス」の記述
ステップ 4: コードのコンパイル
ステップ 5: テストの準備:プロバイダのインストール
ステップ 6: テストプログラムの記述とコンパイル
ステップ 7: テストプログラムの実行
ステップ 8: プロバイダおよびそのサポート対象サービスのドキュメント化
ステップ 9: クラスファイルおよびドキュメントをクライアントから利用可能にする


実装の詳細および要件
別名
サービスの相互依存性
デフォルトの初期化
デフォルトの鍵ペアジェネレータのパラメータの要件
署名フォーマット
DSA インタフェースおよびその実装要件
RSA インタフェースおよびその実装要件
他のアルゴリズムタイプ用インタフェース
アルゴリズムパラメータ仕様のインタフェースおよびクラス
鍵ファクトリにより要求される鍵仕様のインタフェースおよびクラス
新規オブジェクト識別子の追加


付録 A: 「SUN」プロバイダのマスタークラス

付録 B: java.security プロパティファイル

はじめに

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 プロバイダパッケージには、以下のものが含まれています。

新たなプロバイダは、静的にも動的にも追加できます。クライアントは、現在どのプロバイダがインストールされているかを問い合わせることができます。

実装が違うと、特徴も違ってくる場合があります。ソフトウェアベースのものもあれば、ハードウェアベースのものもあります。プラットフォーム独立のものもあれば、プラットフォーム固有のものもあります。また、レビューや評価用に使えるプロバイダコードもあれば、使えないものもあります。

このドキュメントの対象読者

このドキュメントは、暗号化サービス実装を提供する独自のプロバイダパッケージを作成する上級プログラマを対象としています。ここでは、SDK Security API クライアントが、作成されたアルゴリズムや他のサービスを要求する際にそれらを検出できるよう、プロバイダを Java 2 SDK Security に統合するための方法がドキュメント化されています。 SDK Security API を使って既存の暗号化アルゴリズムや他のサービスにアクセスするだけであれば、このドキュメントを読む必要はありません。

関連ドキュメント

このドキュメントは、読者がすでに「Java 暗号化アーキテクチャ API の仕様およびリファレンス」を読んでいることを前提としています。

Java 2 Security API のさまざまなクラスおよびインタフェースについての説明も含まれます。Security API パッケージの完全なリファレンスドキュメントを以下に示します。

エンジンクラスおよび対応する Service Provider Interface クラス

「エンジンクラス」は、具体的な実装のない抽象的な方法で暗号化サービスを定義します。

暗号化サービスは、常に特定のアルゴリズムまたは型に関連付けられています。このサービスによって、暗号化の操作 (デジタル署名またはメッセージダイジェスト用など) の提供、暗号化の操作に必要な暗号化データ (鍵またはパラメータ) の生成や提供、あるいは暗号化の操作で使う暗号化鍵を安全にカプセル化するデータオブジェクト (キーストアまたは証明書) の生成が行われます。たとえば、Signature クラスおよび KeyFactory クラスは、エンジンクラスです。Signature クラスは、デジタル署名アルゴリズムの機能へのアクセスを提供します。DSA KeyFactory は、(コード化形式または透明な仕様から) DSA 非公開鍵または公開鍵を、それぞれ DSA Signature オブジェクトの initSign または initVerify メソッドから利用可能な形式で提供します。

Java 暗号化アーキテクチャには、エンジンクラスなどの、暗号化に関連する Java 2 SDK Security パッケージが含まれています。API のユーザは、エンジンクラスを要求および利用して対応する処理を実行します。Java 2 SDK では、次のエンジンクラスが定義されています。

注 - 「ジェネレータ (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: サービス実装コードの記述

最初に行うべきことは、サポートする暗号化サービスのアルゴリズム固有の実装を提供するコードを記述することです。

Java 2 SDK では、鍵および証明書ファクトリ、キーストアの作成および管理、アルゴリズムパラメータ管理、およびアルゴリズムパラメータ生成サービスに加え、署名、メッセージダイジェスト、鍵のペア生成、および (擬似) 乱数生成アルゴリズムを提供できます。

暗号化サービスごとに、以下のような適切な SPI クラスのサブクラスを作成する必要があります。SignatureSpi、MessageDigestSpi、KeyPairGeneratorSpi、SecureRandomSpi、AlgorithmParameterGeneratorSpi、AlgorithmParametersSpi、KeyFactorySpi、CertificateFactorySpi、または KeyStoreSpi(「エンジンクラスおよび対応する SPI クラス」を参照)。

サブクラスで、以下を実行する必要があります。

  1. 通常「engine」で始まる名前を持つ抽象メソッド用の実装の提供。詳細は、「実装の詳細および要件」を参照してください。

  2. 引数を持たない public コンストラクタの存在の保証。この理由は、サービスの要求時に、SDK Security は、マスタークラス内のプロパティによる指定に従って、そのサービスを実装するサブクラスをルックアップするためです (ステップ 3 を参照)。その後、Java 2 SDK Security は、サブクラスに関連付けられた Class オブジェクトを作成し、その Class オブジェクトに対して newInstance メソッドを呼び出すことにより、サブクラスのインスタンスを作成します。newInstance はサブクラスがパラメータを持たない public コンストラクタを保持することを要求します。

    サブクラスがコンストラクタを持たない場合、引数を持たないデフォルトのコンストラクタが自動的に生成されます。ただし、サブクラスがコンストラクタを定義する場合、引数を持たない public コンストラクタを明示的に定義する必要があります。

ステップ 2: プロバイダの命名

使用するプロバイダの名前を特定します。これは、クライアントアプリケーションがプロバイダを参照する際に使用する名前です。

ステップ 3: プロバイダのサブクラスである「マスタークラス」の記述

3 番目のステップは、Provider クラスのサブクラスを作成することです。

このサブクラスは final にする必要があり、そのコンストラクタは以下を実行する必要があります。

マスタークラスプロパティの設定例の詳細についてさらに情報を得るには、「付録 A」を参照して、現在の Java 2 SDK Sun.java のソースファイルを閲覧してください。そこでは、Sun クラスのコンストラクタが「SUN」プロバイダ用のプロパティすべてを設定しています。

注 - Provider サブクラスは、その情報を必要な場合にはどこでも取得できます。このため、情報は、実行時に (たとえばファイルから) 組み込んだり、取得したりできます。

ステップ 4: コードのコンパイル

実装コードの作成 (ステップ 1)、プロバイダの命名 (ステップ 2)、およびマスタークラスの作成 (ステップ 3) が完了したら、コンパイラを使ってファイルをコンパイルします。

ステップ 5: テストの準備:プロバイダのインストール

プロバイダのテスト準備を行うために、プロバイダを使用するクライアントが行うのと同じ方法で、プロバイダをインストールする必要があります。インストールを実行すると、SDK Security はクライアントの要求に応じてアルゴリズムの実装を検出できるようになります。

プロバイダのインストールは 2 つの部分に分かれます。つまり、プロバイダパッケージクラスのインストールとプロバイダの構成です。

プロバイダクラスのインストール

最初に行う事柄は、作成したクラスを利用可能にして、要求時に検出できるようにすることです。プロバイダクラスは Jar (Java ARchive) または ZIP ファイルの形式で提供します。

プロバイダクラスのインストールには、次の 2 つの方法があります。

プロバイダの構成

次の手順では、認可プロバイダのリストにこのプロバイダを追加します。これは、セキュリティプロパティファイルを編集することにより、静的に行われます。 

<java-home>¥lib¥security¥java.security         [Win32]
<java-home>/lib/security/java.security         [Solaris]
ここで、<java-home> は、実行環境がインストールされているディレクトリを指します。 たとえば、J2SDK バージョン 1.4 を 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: プロバイダおよびそのサポート対象サービスのドキュメント化

次のステップは、クライアント用のドキュメントを記述することです。少なくとも、次の指定を行う必要があります。 さらに、ドキュメント内で、デフォルトのアルゴリズムパラメータなどの、クライアントに関係する他の指定も行う必要があります。

メッセージダイジェスト

メッセージダイジェストアルゴリズムごとに、実装が複製可能かどうかを指定します。これは、技術的には必須ではありませんが、複製により中間ハッシュが可能かどうかを指定することになるため、クライアントの費やす時間およびコードの記述にかかる手間が軽減されます。メッセージダイジェストの実装が複製可能かどうかがわからない場合、クライアントは 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
}
ここで、

署名アルゴリズム

署名アルゴリズムを実装する場合、署名 (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.aliasName

engineClassName にはエンジンクラス (例: 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");
警告:エイリアス化方式は、将来のリリースで変更または削除される可能性があります。

サービスの相互依存性

アルゴリズムによっては、他の種類のアルゴリズムの使用を要求することがあります。たとえば、署名アルゴリズムは通常、データの署名および検証にメッセージダイジェストアルゴリズムを使用する必要があります。

別のアルゴリズムを要求するアルゴリズムを実装している場合、次のいずれかを実行できます。

  1. どちらのアルゴリズムにも対応した独自の実装の提供。

  2. SDK の各インストールに含まれるデフォルトの「SUN」プロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにします。たとえば、実装している署名アルゴリズムがメッセージダイジェストアルゴリズムを要求する場合、次の呼び出しを行うことにより、MD5 メッセージダイジェストアルゴリズムを実装するクラスのインスタンスを取得できます。 
        MessageDigest.getInstance("MD5", "SUN")

  3. 別の特定のプロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにします。これは、プロバイダを使用するすべてのクライアントが、インストールされた他方のプロバイダも保持する場合にだけ有効な方法です。

  4. 別の (無指定の) プロバイダにより提供される場合のように、一方のアルゴリズムの実装が他方のアルゴリズムのインスタンスを使用するようにします。つまり、アルゴリズムを名前で要求できます。ただし、特定のプロバイダは指定しません。次に例を示します。 
        MessageDigest.getInstance("MD5")
    これは、プロバイダが使用される各 Java プラットフォームにインストールされた、要求されたアルゴリズムの実装 (この例では MD5) が少なくとも 1 つ存在することが確実な場合にだけ有効な方法です。

次に、アルゴリズムの相互依存の一般的な種類を示します。

署名アルゴリズムとメッセージダイジェストアルゴリズム

署名アルゴリズムは、メッセージダイジェストアルゴリズムを要求することがあります。たとえば、SHA1withDSA 署名アルゴリズムは、SHA-1 メッセージダイジェストアルゴリズムを要求します。

署名アルゴリズムと (擬似) 乱数生成アルゴリズム

署名アルゴリズムは、(擬似) 乱数生成アルゴリズムを要求することがあります。たとえば、DSA 署名を生成するためには、対応する乱数生成アルゴリズムが必要です。

鍵のペア生成アルゴリズムとメッセージダイジェストアルゴリズム

鍵のペア生成アルゴリズムは、メッセージダイジェストアルゴリズムを要求することがあります。たとえば、DSA 鍵は、SHA-1 メッセージダイジェストアルゴリズムを使って生成されます。

アルゴリズムパラメータ生成とメッセージダイジェストアルゴリズム

アルゴリズムパラメータジェネレータは、メッセージダイジェストアルゴリズムの使用を要求することがあります。たとえば、DSA パラメータは、SHA-1 メッセージダイジェストアルゴリズムを使って生成されます。

KeyStores とメッセージダイジェストアルゴリズム

キーストア実装は、メッセージダイジェストアルゴリズムを利用してキーハッシュ (「鍵」はユーザが提供するパスワード) を計算し、キーストアの統合性検査、およびキーストアが改変されていないことを確認することがあります。

鍵のペア生成アルゴリズムとアルゴリズムパラメータジェネレータ

鍵のペア生成アルゴリズムは、新規アルゴリズムパラメータセットの生成を必要とする場合があります。パラメータは、直接生成するか、アルゴリズムパラメータジェネレータを使用して生成できます。

鍵のペア生成、アルゴリズムパラメータ生成、および (擬似) 乱数生成アルゴリズム

鍵のペア生成アルゴリズムは、新しい鍵ペアおよび (場合によっては) 鍵に関連付けられた新規パラメータセットの生成に、乱数の発生源を必要とする場合があります。乱数の発生源は、SecureRandom オブジェクトにより表されます。鍵ペア生成アルゴリズムの実装は、鍵パラメータ自体を生成する場合もあれば、アルゴリズムパラメータジェネレータを使って鍵パラメータを生成する場合もあります。これらの場合、乱数の発生源を使ってアルゴリズムパラメータジェネレータを初期化する場合もあれば、そうでない場合もあります。

アルゴリズムパラメータジェネレータおよびアルゴリズムパラメータ

アルゴリズムパラメータジェネレータの engineGenerateParameters メソッドは、AlgorithmParameters インスタンスを返す必要があります。

署名および鍵ペア生成アルゴリズムまたは鍵ファクトリ

署名アルゴリズムを実装している場合、実装の engineInitSign メソッドおよび engineInitVerify メソッドは、基礎となるアルゴリズム (例: DSS アルゴリズム用の DSA 鍵) に対して有効な、引き渡しの行われる鍵を必要とします。次のいずれかを実行できます。

  1. 適切なインタフェース (例: java.security.interfaces パッケージから DSAPrivateKey および DSAPublicKey インタフェースを実装するクラス) を実装する独自のクラスも作成し、独自の鍵ペアのジェネレータとこれらのタイプの鍵を返す鍵ファクトリのどちらかまたは両方を作成します。engineInitSign および engineInitVerify に渡される鍵が、実装した鍵 (つまり、鍵ペアジェネレータまたは鍵ファクトリから生成された鍵) と同じタイプである必要があります。または、次の方法も可能です。

  2. 他の鍵ペアジェネレータまたは他の鍵ファクトリから鍵を受け取ります。これは、それらが署名の実装が必要な情報 (非公開鍵、公開鍵および鍵パラメータなど) を取得することを可能にする適切なインタフェースのインスタンスである場合に限り有効です。たとえば、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 を検出しました。)

署名フォーマット

署名アルゴリズムを実装する場合、提供するドキュメント (ステップ 8) で署名 (sign メソッドの 1 つを使って生成される) を符号化する形式を指定する必要があります。

たとえば、「SUN」プロバイダにより提供される SHA1withDSA 署名アルゴリズムは、署名を2 つの ASN.1 INTEGER値 r および s の標準 ASN.1 シーケンスとして、次の順序で符号化します。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.Serializable

DSAPrivateKey および 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.Serializable

RSAPrivateKey、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 つは、独自の鍵仕様を実装する方法です。

  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のインスタンス) オブジェクトをそれぞれ返します。

  2. ユーザが鍵タイプの特定の鍵データ値にアクセスするか、上記の場合のようにエンコーディングからではなく鍵データおよび関連するパラメータ値から鍵タイプの鍵を構築する必要が予想される場合、適切なコンストラクタメソッドおよび「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 がアルゴリズムを検出できるようにする必要があります。

たとえば、プロバイダ実装が「com.xyz」パッケージ内にあり、アルゴリズムが <engine_type> タイプで、オブジェクト識別子「1.2.3.4.5.6.7.8」を使って (文字列表記で) 「MyAlg」と命名されている場合、プロバイダのマスターファイルは次のエントリを保持します。 

    put("<engine_type>.MyAlg", "com.xyz.MyAlg");
    put("Alg.Alias.<engine_type>.1.2.3.4.5.6.7.8", "MyAlg");
アルゴリズムが複数のオブジェクト識別子で知られている場合、オブジェクト識別子ごとに別名エントリを作成する必要があります。

JCA によるこの種のマッピングの例として、アルゴリズムが署名アルゴリズムで、ユーザが keytool -genkey コマンドを実行し、-sigalg オプションを使って (署名) アルゴリズムを指定する場合を考えます。この場合、プロバイダのマスターファイルには、次のエントリを含める必要があります。 

    put("Signature.MyAlg", "com.xyz.MyAlg");
    put("Alg.Alias.Signature.1.2.3.4.5.6.7.8", "MyAlg");
この種のマッピングの別の例として、(1) アルゴリズムがキータイプアルゴリズムで、プログラムが (SUN プロバイダの X.509 実装を使って) 証明書を構文解析し、証明書から公開鍵を抽出して、Signature オブジェクトを初期化する場合、および (2) keytool ユーザが、対応する鍵のペアの生成後に (デジタル署名を実行するために) キータイプの非公開鍵にアクセスしようとする場合、を挙げることができます。これらの場合、プロバイダのマスターファイルには、次のエントリを含める必要があります。 
    put("KeyFactory.MyAlg", "com.xyz.MyAlg");
    put("Alg.Alias.KeyFactory.1.2.3.4.5.6.7.8", "MyAlg");

名前から 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 オプションを使って (署名) アルゴリズムを指定できます。



付録 A: 「SUN」プロバイダのマスタークラス

以下に示すのは 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;
	    }
	});
    }
}


付録 B: java.security プロパティファイル

次に示すのは、java.security ファイルのコピーで、JRE の各インストールに含まれます。 このファイルは次の場所にあります。 
<java-home>/lib/security/java.security         [Solaris]
<java-home>¥lib¥security¥java.security         [Win32]
ここで、<java-home> は JRE がインストールされているディレクトリを指します。 つまり、J2SDK バージョン 1.4 を 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]
このファイルにプロバイダに関する情報を追加する例については、ステップ 5 を参照してください。 
#
# 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". For example,
#   -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-2001 Sun Microsystems, Inc.All Rights Reserved.

コメントの送付先:java-security@sun.com。これは購読リストではありません。 		Sun
Java ソフトウェア