ステップ 1: サービス実装コードの記述

ステップ 1.1: 暗号化実装のための JCA プロバイダの追加要件および推奨事項

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

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

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

ステップ 5: JAR ファイルへのプロバイダの記述

ステップ 6: オプション -- JAR ファイルの署名

ステップ 6.1: コード署名証明書の取得

ステップ 6.2: プロバイダの署名

ステップ 7: テストの準備

ステップ 7.1: プロバイダのインストール

ステップ 7.2: プロバイダアクセス権の設定

ステップ 8: テストプログラムの記述とコンパイル

ステップ 9: テストプログラムの実行

ステップ 10: 米国政府による輸出承認の申請 (必要な場合)

ステップ 11: プロバイダおよびそのサポート対象サービスのドキュメント化

ステップ 12: クラスファイルおよびドキュメントをクライアントから利用可能にする

ステップ 1: サービス実装コードの記述

最初に、サポートする暗号化サービスのアルゴリズム固有の実装を提供するコードを記述する必要があります。

プロバイダは、JDK の 1 つ以上のセキュリティーコンポーネントですでに使用可能になっている暗号化サービス実装を提供できます。

JCA には定義されていない暗号化サービス (署名やメッセージダイジェストなど) に関しては、「Java 暗号化アーキテクチャーリファレンスガイド」を参照してください。

実装する暗号化サービスごとに、適切な SPI クラスのサブクラスを作成します。JCA は、次のエンジンクラスを定義します。

• SignatureSpi
• MessageDigestSpi
• KeyPairGeneratorSpi
• SecureRandomSpi
• AlgorithmParameterGeneratorSpi
• AlgorithmParametersSpi
• KeyFactorySpi
• CertificateFactorySpi
• KeyStoreSpi
• CipherSpi
• KeyAgreementSpi
• KeyGeneratorSpi
• MacSpi
• SecretKeyFactorySpi
• ExemptionMechanismSpi

JCA およびその他の暗号化クラスについては、このドキュメントの「エンジンクラスおよび対応する SPI クラス」を参照してください。

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

1. 通常 engine で始まる名前を持つ抽象メソッド用の実装を提供します。詳細は、「実装の詳細および要件」を参照してください。
2. 引数を持たない public コンストラクタの存在を確認します。理由は次のとおりです。これが必要な理由は、サービスの要求時に、Java Security が、マスタークラス内のプロパティーによる指定に従って、そのサービスを実装するサブクラスをルックアップするためです (ステップ 3 を参照)。その後、Java Security は、サブクラスに関連付けられた Class オブジェクトを作成し、その Class オブジェクトに対して newInstance メソッドを呼び出すことにより、サブクラスのインスタンスを作成します。newInstance はサブクラスがパラメータを持たない public コンストラクタを保持することを要求します。
3. サブクラスがコンストラクタを持たない場合、引数を持たないデフォルトのコンストラクタが自動的に生成されます。ただし、サブクラスがコンストラクタを定義する場合、引数を持たない public コンストラクタを明示的に定義する必要があります。

プロバイダによる Cipher、KeyAgreement、KeyGenerator、MAC、または SecretKey ファクトリの実装 (クラス) をインスタンス化する際、フレームワークはプロバイダのコードベース (JAR ファイル) を判定し、その署名を検証します。このようにして、JCA はプロバイダを認証して、信頼されたエンティティーにより署名されたプロバイダだけが JCA にプラグインできるようにします。このため、暗号化プロバイダは署名付きにする必要があります。詳細はあとのステップで説明します。

また、各プロバイダは自己整合性チェックを実行して、プロバイダメソッドを JCA を介さずに直接呼び出そうとして、コードを含む JAR ファイルが操作されていないことを保証する必要があります。詳細は、「プロバイダによる自己整合性チェックの実行方法」を参照してください。

JCA を介さずに直接アプリケーションからインスタンス化が行われた場合に、プロバイダクラスを使用不可にするため、プロバイダは次の実装を行う必要があります。

• プロバイダパッケージ内のすべての SPI 実装クラスを final として宣言し (サブクラス化できないように)、SPI 実装メソッドを protected として宣言する必要があります。
• プロバイダパッケージ内の暗号化関連ヘルパークラスはすべて、プロバイダパッケージ外からアクセスできないように、パッケージ独自のスコープを保持する必要があります。

プロバイダを米国以外に輸出する場合、CipherSpi 実装に、Key を指定すると鍵のサイズを返す engineGetKeySize メソッドの実装を含める必要があります。管轄ポリシーファイルで指定された利用可能な暗号化強度に制限が設定されている場合、Cipher 初期化メソッドは engineGetKeySize を呼び出して、実行中のアプレットまたはアプリケーションの特定位置および状況での鍵の最大有効サイズと結果を比較します。鍵のサイズが大きすぎる場合には、初期化メソッドにより例外がスローされます。

プロバイダが実装可能な「オプション」機能を、次に示します。

• CipherSpi の engineWrap メソッドと engineUnwrap メソッド。 鍵をラッピングすると、ある場所から別の場所へ安全に転送できます。鍵のラップおよびラップの解除の詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「鍵のラッピングとアンラッピング」を参照してください。

• 1 つ以上の「免責機構」。免責機構には、鍵復元、鍵エスクロー、鍵弱化などが含まれます。この機構を実装および実行すると、これを利用するアプリケーション (またはアプレット) に対する暗号化の制限を緩めることができます。免責機構を利用するアプリケーションの要件に関する詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「アプリケーションの暗号化制限の「免責」を取得する方法」を参照してください。

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

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

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

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

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

• super を呼び出して、プロバイダ名 (ステップ 2 を参照)、バージョン番号、およびプロバイダおよびプロバイダがサポートするアルゴリズムに関する情報を指定します。例を示します。

      super("CryptoX", 1.0, "CryptoX provider v1.0, implementing " +
  	"RSA encryption and key pair generation, and DES encryption.");
  

• Java Security API がプロバイダにより実装された暗号化サービスを探すために必要とされる、さまざまなプロパティーの値を設定します。プロバイダによるサービス実装ごとに、サービスの型 (たとえば、Signature、MessageDigest、Cipher、KeyAgreement) Signature、MessageDigest、KeyPairGenerator、SecureRandom、KeyFactory、KeyStore、CertificateFactory、AlgorithmParameterGenerator、AlgorithmParameters、 Cipher、KeyAgreement、KeyGenerator、Mac、SecretKeyFactory、ExemptionMechanism) とピリオド、さらにサービスが適用されるアルゴリズム名で構成される名前のプロパティーが存在する必要があります。プロパティーの値には、サービスを実装するクラスの完全修飾名を指定する必要があります。

  次のリストに、JCA サービスのさまざまな型を示します。algName は、実際のアルゴリズム名に置き換えてください。

  • Signature.algName
  • MessageDigest.algName
  • KeyPairGenerator.algName
  • SecureRandom.algName
  • AlgorithmParameterGenerator.algName
  • AlgorithmParameters.algName
  • KeyFactory.algName
  • CertificateFactory.algName
  • KeyStore.algName
  • Cipher.algName
  • KeyAgreement.algName
  • KeyGenerator.algName
  • Mac.algName
  • SecretKeyFactory.algName
  • ExemptionMechanism.algName

  ExemptionMechanism および Cipher を除き、これらのどの場合にも、algName、certType、または storeType は、アルゴリズム、証明書のタイプ、またはキーストアタイプの「標準」名です。使用する必要がある標準名については、「Java 暗号化アーキテクチャーリファレンスガイド」の「付録 A」を参照してください。

  ExemptionMechanism の場合、algName は例外機構の名前を参照します。たとえば、KeyRecovery、KeyEscrow、KeyWeakening などです。大文字小文字は区別されません。

  Cipher の場合、algName は実際には変換を表します。これは、アルゴリズム名、指定されたモード、およびパディング方式で構成されます。詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「付録 A」を参照してください。

  各プロパティーの値は、指定されたアルゴリズム、証明書のタイプ、またはキーストアタイプを実装するクラスの完全修飾名である必要があります。つまり、クラス名の後にピリオドとパッケージ名が記述されていなければなりません。

  たとえば、SUN という名前のデフォルトプロバイダは、sun.security.provider パッケージの DSA という名前のクラス内のデジタル署名アルゴリズム (その標準名は SHA1withDSA) を実装します。Provider のサブクラス (sun.security.provider パッケージの Sun クラス) は、次のように Signature.SHA1withDSA プロパティーを設定して、値 sun.security.provider.DSA を保持します。

      put("Signature.SHA1withDSA", "sun.security.provider.DSA")

  次のリストに、さまざまな種類のサービスに合わせて定義可能なプロパティーのタイプをさらに示します。実際には、algName はアルゴリズム名に、certType は証明書のタイプに、storeType はキーストアタイプに、attrName は属性名に置き換えられます。

  • Signature.algName [1 つ以上の空白] attrName
  • MessageDigest.algName [1 つ以上の空白] attrName
  • KeyPairGenerator.algName [1 つ以上の空白] attrName
  • SecureRandom.algName [1 つ以上の空白] attrName
  • KeyFactory.algName [1 つ以上の空白] attrName
  • CertificateFactory.certType [1 つ以上の空白] attrName
  • KeyStore.storeType [1 つ以上の空白] attrName
  • AlgorithmParameterGenerator.algName [1 つ以上の空白] attrName
  • AlgorithmParameters.algName [1 つ以上の空白] attrName
  • Cipher.algName [1 つ以上の空白] attrName
  • KeyAgreement.algName [1 つ以上の空白] attrName
  • KeyGenerator.algName [1 つ以上の空白] attrName
  • Mac.algName [1 つ以上の空白] attrName
  • SecretKeyFactory.algName [1 つ以上の空白] attrName
  • ExemptionMechanism.algName [1 つ以上の空白] attrName

これらのどの場合にも、algName、certType、storeType、または attrName は、アルゴリズム、証明書のタイプ、キーストアタイプ、または属性の「標準」名です。使用する必要がある標準名については、「Java 暗号化アーキテクチャーリファレンスガイド」の「付録 A」を参照してください。

上記の形式のプロパティーの場合、プロパティーの値は、対応する属性に応じた値である必要があります。(各標準属性の定義については、「Java 暗号化アーキテクチャー API 仕様＆リファレンス」の「付録 A」を参照してください。)

たとえば、SUN という名前のデフォルトプロバイダは、SHA1withDSA デジタル署名アルゴリズムをソフトウェア内で実装します。プロバイダ SUN のマスタークラスでは、次のようにして、Signature.SHA1withDSA ImplementedIn が値 Software を保持するように設定が行われます。

    put("Signature.SHA1withDSA ImplementedIn", "Software")

マスタークラスプロパティーの設定例の詳細は、「付録 A」を参照して現在の Sun.java のソースファイルを閲覧するか、「付録 B」を参照して SunJCE プロバイダを参照してください。これらのファイルでは、Sun および SunJCE プロバイダがプロパティーをどのように設定しているかがわかります。

すでに説明したように、Cipher プロパティーの場合、algName は実際には「変換」を表します。「変換」は、指定された入力に対して Cipher オブジェクトによって実行される操作 (または操作のセット) を説明する文字列です。変換には、暗号化アルゴリズム (DES など) の名前が必ず含まれます。それにモードおよびパディング方式が続く場合もあります。

変換は、次の書式で記述されます。

• algorithm/mode/padding または
• algorithm

後者の場合、モードおよびパディング方式には、プロバイダ固有のデフォルト値が使用されます。たとえば、以下は有効な変換です。

    Cipher c = Cipher.getInstance("DES/CBC/PKCS5Padding"); 

ストリーム暗号モードでブロック暗号を要求する (たとえば CFB または OFB モードで DES を要求する) 場合、クライアントは、数値をモード名に追加することにより、一度に処理するビット数をオプションで指定できます。次に変換のサンプルを示します。

    Cipher c1 = Cipher.getInstance("DES/CFB8/NoPadding");
    Cipher c2 = Cipher.getInstance("DES/OFB32/PKCS5Padding");

数値がストリーム暗号モードに準拠していない場合、プロバイダ固有のデフォルト値が使用されます。たとえば、SunJCE プロバイダではデフォルトの 64 ビットが使用されます。

プロバイダは、algorithm/mode/padding の組み合わせごとに別々のクラスを提供できます。または、algorithm、algorithm/mode、algorithm//padding (ダブルスラッシュを使用する点に注意) のいずれかに対応する下位変換を表すより一般的なクラスを提供できます。この場合、要求されたモードやパディングは、Cipher の getInstance メソッドによって自動的に設定されます。getInstance メソッドは、プロバイダの CipherSpi のサブクラスから engineSetMode メソッドと engineSetPadding メソッドを呼び出します。

つまり、プロバイダマスタークラスの Cipher プロパティーは、以下の表に示すいずれかの形式になります。

使用する必要がある標準アルゴリズム名、モード、およびパディング方式については、「Java 暗号化アーキテクチャーリファレンスガイド」の「付録 A」を参照してください。

たとえば、プロバイダは DES/ECB/PKCS5Padding、DES/CBC/PKCS5Padding、DES/CFB/PKCS5Padding、さらに DES/OFB/PKCS5Padding をそれぞれ実装する CipherSpi のサブクラスを提供可能です。このプロバイダは、マスタークラス内に次の Cipher プロパティーを保持します。

• Cipher.DES/ECB/PKCS5Padding
• Cipher.DES/CBC/PKCS5Padding
• Cipher.DES/CFB/PKCS5Padding
• Cipher.DES/OFB/PKCS5Padding

別のプロバイダは、上記の各モードに対応したクラス (ECB、CBC、CFB、および OFB 用にそれぞれ 1 つのクラス) を実装できます。また、PKCS5Padding に対応する 1 つのクラス、および CipherSpi からサブクラス化された総称 DES クラスも実装できます。このプロバイダは、マスタークラス内に次の Cipher プロパティーを保持します。

• Cipher.DES
• Cipher.DES SupportedModes
  例: "ECB|CBC|CFB|OFB"
• Cipher.DES SupportedPaddings
  例: "NOPADDING|PKCS5Padding"

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

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

ステップ 5: JAR ファイルへのプロバイダの記述

次のステップ (JAR ファイルへの署名) の準備として、JAR ファイルにプロバイダコードを記載します。jar ツールの詳細については、jar (Solaris 用) (Microsoft Windows 用) を参照してください。

    jar cvf <JAR file name> <list of classes, separated by spaces>

このコマンドにより、指定されたクラスを含む、指定された名前の JAR ファイルが作成されます。

ステップ 6: オプション -- JAR ファイルの署名

プロバイダが Cipher KeyAgreement、KeyGenerator、Mac、または SecretKeyFactory クラスによって暗号化アルゴリズムを提供している場合、実行時に JCA がコードを認証できるように、JAR ファイルに署名する必要があります。詳細は、ステップ 1.1 を参照してください。このタイプの実装を提供してない場合は、このステップはスキップできます。

ステップ 6.1: コード署名証明書の取得

次のステップは、コード署名証明書の要求です。テストに先立ち、コード署名証明書を使用してプロバイダへの署名を行います。証明書は、テスト環境と製作環境の両方で利用できます。有効期間は 5 年間です。

次に、コード署名証明書の取得方法を示します。keytool ツールの詳細は、keytool (Solaris 用) (Microsoft Windows 用) を参照してください。

1. keytool を使用して、DSA 鍵ペアを生成します。例として、DSA アルゴリズムを使用します。

       keytool -genkeypair -alias <alias> \
   	-keyalg DSA -keysize 1024 \
   	-dname "cn=<Company Name>, \
   	ou=Java Software Code Signing,\
   	o=Sun Microsystems Inc" \
   	-keystore <keystore file name>\
   	-storepass <keystore password>
   	

   これにより、DSA 鍵ペア (公開鍵および関連する非公開鍵) が生成され、指定されたキーストアのエントリに格納されます。公開鍵は、自己署名証明書に格納されます。これ以降、キーストアのエントリには、指定された別名を使用してアクセスできます。
   
   角括弧 (「<」 と「>」) 内のオプション値には、実際の値を指定する必要があります。たとえば、<alias> は、新しく生成するキーストアのエントリを参照する際に使用する任意の別名で置き換え、<keystore file name> は、使用するキーストアの名前で置き換えます。注: 実際の値には、角括弧を付けないでください。たとえば、別名を myTestAlias にする場合、-alias オプションを次のように指定します。

       -alias myTestAlias

   まだ存在しないキーストアを指定すると、そのキーストアが作成されます。
   
   

   ---

   注: 入力するコマンド行を、実行する keytool -genkeypair コマンドと同じ長さにできない場合 (Microsoft Windows の DOS プロンプトに入力する場合など)、コマンドを含むプレーンテキストのバッチファイルを作成して実行できます。つまり、keytool -genkeypair コマンドだけを含むテキストファイルを新規作成します。なお、コマンドは、全体を 1 行に入力してください。拡張子 .bat を付けてファイルを保存します。DOS ウィンドウで、ファイル名を (必要に応じてパスを付けて) 入力します。これで、バッチファイルに記述されたコマンドが実行されます。

   ---

   
   
2. keytool を使用して、証明書署名要求を生成します。

       keytool -certreq -alias <alias> \
   	-file <csr file name> \
   	-keystore <keystore file name> \
   	-storepass <keystore password> 

   ここで、<alias> には、前のステップで作成した DSA 鍵ペアエントリの別名を指定します。このコマンドにより、証明書署名要求 (CSR) が PKCS#10 形式で生成されます。<csr file name> で指定した名前のファイルに CSR が格納されます。
3. CSR、連絡情報、および他の必須ドキュメントを JCA コード署名証明書発行局に送ります。CSR および連絡情報 (以下を参照) を、電子メールで javasoft-cert-request@sun.com に送ってください。電子メールメッセージの件名行には、以下を入力します。

       Request a Certificate for Signing a JCA Provider 

   メッセージの本文に連絡情報を入力し、メッセージに CSR ファイルを添付して送信します。添付に使用するエンコーディングを指定するオプションがメールソフトに存在する場合、「MIME」を選択します。
   
   

   ---

   注: CSR ファイルは、Base 64 でエンコーディングされたプレーンテキストです。人間が読むことができるのは、最初と最後の行だけです。
   
   メッセージの本文に次の連絡情報を含めます。
• Company Name
• Street Address (Not a post office box)
• City
• State/Province
• 国
• Company Telephone Number
• Company Fax Number
• Requester Name
• Requester Telephone Number
• Requester Email Address
• Brief description of your company (size, line of business, etc.)

上記の情報をすべて入力する必要があります。

4. 電子メールメッセージを受信すると、JCA コード署名証明書発行局は、要求番号を電子メールで返信します。処理に 5 営業日かかります。
   
   この要求番号を受信したら、Certification Form for CSPs を印刷して記入し、送ります。このフォームは、以下のアドレスに郵送します。フォームに要求番号を記入し、郵送したフォームが電子メールのメッセージに記載した CSR および連絡先情報と一致するようにします。
   
   Sun Microsystems, Inc.
   International Trade Services/Export Compliance
   Attn:Encryption Export
   10 Network Circle MS:UMPK10-144
   Menlo Park, CA 94025
   U.S.A.
   JCA コード署名証明書は、電子メールメッセージと必要なフォームの両方を受信後に、要求者の認証を行います。その後、5 年間有効なコード署名証明書を作成および署名します。2 つのプレーンテキストファイルの添付された電子メールメッセージが要求者に送信されます。1 つはこのコード署名証明書を含むファイルで、もう 1 つは独自の CA 証明書を含むファイルで公開鍵の認証に使用します。要求を受け取ってから、処理に 5 営業日かかります。
5. keytool を使用して CA から受信した証明書をインポートします。
   
   JCA コード署名証明書発行局から 2 つの証明書を受信したら、keytool を使用してキーストアにそれらをインポートできます。
   
   最初に、CA の証明書を「信頼できる証明書」としてインポートします。

       keytool -import -alias <alias for the CA cert> \
   	-file <CA cert file name> \
   	-keystore <keystore file name> \
   	-storepass <keystore password>

   次に、コード署名証明書をインポートします。

       keytool -import -alias <alias> \
   	-file <code-signing cert file name> \
   	-keystore <keystore file name> \
   	-storepass <keystore password>

   ここで、<alias> にはステップ 1 (DSA 鍵ペアの生成) で作成したのと同じ別名を指定します。このコマンドにより、<alias> で指定されたキーストアエントリ内の自己署名証明書が、JCA コード署名証明書発行局が署名した証明書で置き換えられます。

これで、JCA により信頼されたエンティティー (JCA コード署名証明書発行局) からの証明書がキーストア内に保存されたため、JAR ファイル内にプロバイダコードを記述し (ステップ 5)、この証明書を使用して JAR ファイルに署名できます (ステップ 6.2)。

ステップ 6.2: プロバイダの署名

ステップ 6 で取得したコード署名証明書を使用して、ステップ 5 で作成した JAR ファイルに署名します。jarsigner ツールの詳細は、jarsigner (Solaris 用) (Microsoft Windows 用) を参照してください。

    jarsigner -keystore <keystore file name> \
	-storepass <keystore password> \
	<JAR file name> <alias>

ここで、<alias> には、JCA コード署名証明書発行局から受け取ったコード署名証明書を含むエントリ用キーストアの別名 (ステップ 6.1 のコマンドで指定した別名) を指定します。

次の方法で、署名を検証できます。

    jarsigner -verify <JAR file name> 

検証が成功すると、「jar verified」というテキストが表示されます。

ステップ 7: テストの準備

次の手順では、新しいプロバイダを JCA で使用できるようにインストールおよび構成する方法について説明します。

ステップ 7.1: プロバイダのインストール

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

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

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

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

プロバイダクラスのインストール方法は 2 種類あります。

• プロバイダクラスを含む JAR ファイルを、「インストール型」または「バンドル型」の拡張機能としてインストールする方法
• プロバイダクラスを含む JAR ファイルを CLASSPATH に含める方法

プロバイダ JAR ファイルは、次に示すインストール型拡張機能 JAR ファイルの標準位置に配置された場合、インストール型拡張機能と見なされます。

    <java-home>/lib/ext		[Solaris]
    <java-home>\lib\ext		[Windows]

ここで、<java-home> は、ランタイムソフトウェアのインストール先ディレクトリ (Java^TM 2 Runtime Environment (JRE) のトップレベルディレクトリまたは Java^TM SE (JDK) ソフトウェアの jre ディレクトリ) を指します。たとえば、JDK 6 を /home/user1/jdk1.6.0 ディレクトリ (Solaris)、または C:\jdk1.6.0 ディレクトリ (Microsoft Windows) にインストールした場合、JAR ファイルを次のディレクトリにインストールする必要があります。

    /home/user1/jdk1.6.0/jre/lib/ext	[Solaris]
    C:\jdk1.6.0\jre\lib\ext		[Windows]

同様に、JRE 6 を /home/user1/jre1.6.0 ディレクトリ (Solaris)、または C:\jre1.6.0 ディレクトリ (Microsoft Windows) にインストールした場合、JAR ファイルを次のディレクトリにインストールする必要があります。

    /home/user1/jre1.6.0/lib/ext	[Solaris]
    C:\jre1.6.0\lib\ext			[Windows]

「インストール型」拡張機能の詳細は、「インストール型拡張機能」を参照してください。

「バンドル型」拡張機能の詳細は、「バンドル型拡張機能」を参照してください。

プロバイダの構成

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

    <java-home>/lib/security/java.security	[Solaris]
    <java-home>\lib\security\java.security	[Windows]

ここで、<java-home> は JRE がインストールされているディレクトリを指します。たとえば、JDK 6 を /home/user1/jdk1.6.0 ディレクトリ (Solaris)、または C:\jdk1.6.0 ディレクトリ (Microsoft Windows) にインストールした場合、次のファイルを編集する必要があります。

    /home/user1/jdk1.6.0/jre/lib/security/java.security	[Solaris]
    C:\jdk1.6.0\jre\lib\security\java.security		[Windows]

同様に、JRE 6 を Solaris の /home/user1/jre1.6.0 ディレクトリにインストールしている場合、または Windows の C:\jre1.6.0 ディレクトリにインストールしている場合は、次のファイルを編集する必要があります。

    /home/user1/jre1.6.0/lib/security/java.security	[Solaris]
    C:\jre1.6.0\lib\security\java.security		[Windows]

プロバイダごとに、このファイルは次の形式の文を保持します。

    security.provider.n=masterClassName 

これはプロバイダを宣言し、その優先順位 n を指定します。優先順位とは、特定プロバイダの指定がないときに、要求されたアルゴリズムについてプロバイダを検索する順序です。順位は 1 から始まり、1 が最優先で次に 2、3 ...と続きます。

masterClassName には、ステップ 3 で実装したプロバイダの「マスタークラス」の完全修飾名を指定する必要があります。このクラスは、常に Provider クラスのサブクラスです。

    security.provider.2=sun.security.provider.Sun
    security.provider.3=sun.security.rsa.SunRsaSign
    security.provider.4=sun.security.provider.SunJCE

    security.provider.2=sun.security.provider.Sun
    security.provider.3=sun.security.rsa.SunRsaSign
    security.provider.4=com.cryptox.provider.CryptoX
    security.provider.5=sun.security.provider.SunJCE

注: プロバイダは動的に登録することもできます。その場合、プログラム (ステップ 8 で記述したテストプログラムなど) は、Security クラスの addProvider メソッドまたは insertProviderAt メソッドを呼び出します。こうした登録は持続的なものではありません。また、実行できるのは次の権限を付与されたコードだけです。

    java.security.SecurityPermission "insertProvider.{name}"

ここで、{name} には実際のプロバイダ名を指定します。

たとえば、プロバイダ名が「MyJCE」であり、プロバイダのコードが /localWork ディレクトリの myjce_provider.jar ファイル内に存在する場合、アクセス権を付与するサンプルポリシーファイルの grant 文は次のようになります。

    grant codeBase "file:/localWork/myjce_provider.jar" {
	permission java.security.SecurityPermission
	    "insertProvider.MyJCE";
    };

ステップ 7.2: プロバイダアクセス権の設定

プロバイダがインストール型拡張機能ではない場合、セキュリティーマネージャーがインストール済みの状態で、アプレットまたはアプリケーションを実行する際、常にプロバイダにアクセス権を付与する必要があります。通常、アプレットの実行時にはセキュリティーマネージャーが常にインストールされます。アプリケーションの場合でも、アプリケーション自体のコード内またはコマンド行引数で指定することにより、セキュリティーマネージャーをインストールできます。デフォルトシステムポリシーファイルは、インストール型拡張機能にすべてのアクセス権を付与するため、インストール型拡張機能にはアクセス権を付与する必要はありません。

クライアントがプロバイダをインストール型拡張機能としてインストールしない場合、クライアント環境で次のアクセス権をプロバイダに常に付与する必要があります。

• java.lang.RuntimePermission (クラス保護ドメインを取得するため)。プロバイダは、自己整合性チェックの実行過程で、独自の保護ドメインの取得が必要になる場合があります。
• java.security.SecurityPermission (プロバイダプロパティーの設定用)

セキュリティーマネージャーがインストールされていて、プロバイダがインストール型拡張機能でない場合は、プロバイダが正しく機能するかどうかを確認するため、インストールおよび実行環境をテストする必要があります。なお、テストを実施する前に、プロバイダとこのプロバイダが使用するすべてのプロバイダに適切なアクセス権を付与しておく必要があります。たとえば、名前が「MyJCE」で、コードが myjce_provider.jar 内に存在するプロバイダにアクセス権を付与するサンプルコードを次に示します。この種の文は、ポリシーファイルに記述されます。この例では、myjce_provider.jar ファイルは /localWork ディレクトリに格納されるものとします。

    grant codeBase "file:/localWork/myjce_provider.jar" {
	permission java.lang.RuntimePermission "getProtectionDomain";
	permission java.security.SecurityPermission
	    "putProviderProperty.MyJCE";
    };

ステップ 8: テストプログラムの記述とコンパイル

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());

次に、サービスが検出されることを確認します。たとえば、DES 暗号化アルゴリズムを実装した場合には、要求時にこのアルゴリズムが確実に検出されるかどうかを、次のコードを使ってチェックできます (ここでも「MyPro」は、独自のプロバイダ名に置き換えてください)。

    Cipher c = Cipher.getInstance("DES", "MyPro");

    System.out.println("My Cipher algorithm name is " + c.getAlgorithm());

getInstance への呼び出しでプロバイダ名を指定しない場合、そのアルゴリズムを実装するプロバイダが検出されるまで、登録されたすべてのプロバイダが優先順位に従って検索されます (「プロバイダの構成」を参照)。

プロバイダが免責機構を実装している場合、免責機構を使用するテストアプレットまたはアプリケーションを記述する必要があります。この種のアプレット/アプリケーションにも、署名、および「アクセス権ポリシーファイル」のバンドルが必要です。アプリケーションの作成およびテスト方法の詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「アプリケーションの暗号化制限の「免責」を取得する方法」を参照してください。

ステップ 9: テストプログラムの実行

テストプログラムを実行します。コードをデバッグし、必要に応じてテストを続行します。Java Security API がアルゴリズムを検出できないようであれば、上記のステップを確認し、すべてのステップが完了していることを確認してください。

複数のインストールオプション (プロバイダをインストール型拡張機能にする、またはクラスパス内に配置するなど) および実行環境 (セキュリティー管理を実行する、または実行しない) を使用して、プログラムを確実にテストしてください。インストールオプションの詳細は、ステップ 7.1 を参照してください。特に、セキュリティーマネージャーをインストールし、かつプロバイダがインストール型拡張機能ではない (つまり、プロバイダにアクセス権を付与する必要がある) 場合、プロバイダが正しく機能するかどうかを確認するため、ステップ 7.2 の手順に従ってプロバイダおよびそのプロバイダが使用するほかのプロバイダに必要なアクセス権を付与したあと、インストールおよび実行環境をテストする必要があります。

テストの結果、コードの修正が必要になった場合には、変更および再コンパイル (ステップ 4)、JAR ファイルへの更新されたプロバイダコードの記載 (ステップ 6)、必要に応じた JAR ファイルへの署名 (ステップ 6.2)、プロバイダの再インストール (ステップ 7.1)、必要に応じたアクセス権の修正または追加 (Step 7.2) を実行してから、プログラムを再テストします。その後、必要に応じてこれらのステップを繰り返します。

ステップ 10: 米国政府による輸出承認の申請 (必要な場合)

プロバイダを米国外に輸出する可能性のある米国内のベンダーはすべて、米国商務省産業安全保障局に輸出承認申請を行う必要があります。詳細は、輸出問題を担当する顧問弁護士に確認してください。

注: プロバイダが Cipher.getInstance() を呼び出し、返される Cipher オブジェクトで、ユーザーがダウンロードした管轄ポリシーファイルで許可されている暗号化の強度に関係なく強力な暗号化を実行する必要がある場合は、その暗号化強度に対応したアクセス権が指定されている、JAR ファイルにバンドルする予定の cryptoPerms アクセス権ポリシーファイルのコピーを含める必要があります。このファイルが必要な理由は、アプレットおよびアプリケーションが暗号化制限を「免除される」ために、JAR ファイルに cryptoPerms アクセス権ポリシーファイルを含める必要があるのと同じ理由です。このようなファイルの作成と組み込みの詳細は、「Java 暗号化アーキテクチャーリファレンスガイド」の「アプリケーションの暗号化制限の「免責」を取得する方法」を参照してください。

役に立つと思われる URL を 2 つ紹介しておきます。

• 米国商務省: http://www.commerce.gov

• 産業安全保障局: http://www.bis.doc.gov

ステップ 11: プロバイダおよびそのサポート対象サービスのドキュメント化

次のステップは、クライアント用のドキュメントを記述することです。少なくとも、次の指定が必要です。

• プロバイダの参照に使用する名前プログラム。注: このドキュメントを執筆している現時点では、プロバイダ名の検索で大文字と小文字が区別されます。つまり、マスタークラスがプロバイダ名を「CryptoX」として指定した場合、ユーザーが「CRYPTOx」を要求しても、プロバイダは見つかりません。この動作は、将来変更される可能性がありますが、現時点ではクライアントに対して大文字小文字を正確に指定するように通知してください。

• プロバイダが実装するアルゴリズムおよび他のサービスの種類。

• プロバイダのインストール方法に関する指示。これは、情報と例がプロバイダ固有のものになることを除き、ステップ 7.1 で示した指示と同様です。

• プロバイダがインストール型拡張機能としてインストールされておらず、セキュリティーマネージャーが稼動している場合に必要なアクセス権 (ステップ 7.2)。

さらに、ドキュメント内で、デフォルトのアルゴリズムパラメータなどの、クライアントに関係する他の指定も行う必要があります。

メッセージダイジェストおよび MAC

    try {
	// try and clone it
	/* compute the MAC for i1 */
	mac.update(i1);
	byte[] i1Mac = mac.clone().doFinal();

	/* compute the MAC for i1 and i2 */
	mac.update(i2);
	byte[] i12Mac = mac.clone().doFinal();

	/* compute the MAC for i1, i2 and i3 */
	mac.update(i3);
	byte[] i123Mac = mac.doFinal();
    } catch (CloneNotSupportedException cnse) {
	// have to use an approach not involving cloning
    } 

プロバイダによる自己整合性チェックの実行方法

各プロバイダは自己整合性チェックを実行して、プロバイダメソッドを JCA を介さずに直接呼び出すなどの操作により、コードを含む JAR ファイルが改変されていないことを保証する必要があります。暗号化サービス (Cipher、KeyAgreement、KeyGenerator、MAC、または SecretKey ファクトリ) の実装を提供するプロバイダは、デジタル署名され、「信頼できる」証明書発行局が発行する証明書で署名されている必要があります。現状では、次の 2 種類の証明書発行局が「信頼できる」とされています。

• Sun Microsystems の JCA コード署名証明書発行局
• IBM の JCA コード署名証明書発行局

Sun Microsystems の JCA コード署名 CA からコード署名証明書を取得する方法については、ステップ 6.2 を参照してください。

署名済み証明書を上記の証明書発行局から入手したあと、プロバイダパッケージに署名する証明書用のバイトを埋め込む必要があります。 たとえば、後述する「個々の署名者の識別と信頼できる署名者の特定」で解説する、bytesOfProviderCert 配列のような配列です。実行時には、埋め込まれた証明書を使用して、プロバイダコードが認証されたものかどうかが判断されます。

プロバイダが自らの整合性チェックに使用する基本的な方法を、次に示します。

1. プロバイダコードを含む JAR ファイルの URL を特定します。
2. JAR ファイルのデジタル署名を検証して、JAR ファイルの各エントリの少なくとも 1 つの署名者が信頼できることを確認します。

以下のセクションでは、具体的な手順を示します。

サンプルコードについて

注: サンプルコード MyJCE.java は、これらのステップを実装する完全なコード例です。このコードは参照用としてダウンロードできます。上記の概念がどのようにしてサンプルコードに実装されているかについては、「サンプルコードについて」を参照してください。

重要: JCE 1.2.x (JDK 1.2.x および 1.3.x とともに使用される) のバンドルされていないバージョンでは、プラグインする JCA の整合性および信頼性を保証するため、JCA フレームワークの認証用コードをプロバイダに含める必要がありました。JDK 6 では、これは必要なくなりました。

これにより、JCE フレームワークコードはプロバイダの期待する場所に存在しなくなるため、プロバイダの JCE フレームワーク認証チェックが機能しなくなります。このため、JCE 1.2.2 専用に記述されたプロバイダは、JDK 6 では動作しなくなります。プロバイダが JDK 6 でのみ動作するようにするには、JCE フレームワークを認証するコードをプロバイダに含めないようにしてください。プロバイダを JCE 1.2.2 と JDK 6 の両方で動作させる場合は、条件文を追加します。こうしておけば、プロバイダを JCE 1.2.2 で実行する場合にのみ JCE フレームワークを認証するプロバイダコードが実行されるようになります。次に、サンプルコードを示します。

    Class cipherCls = Class.forName("javax.crypto.Cipher");

    CodeSource cs = cipherCls.getProtectionDomain().getCodeSource();
    if (cs != null) {
	// Authenticate JCE framework

	 . . .
    } 

プロバイダ JAR ファイルの検索: 基本

プロバイダの JAR ファイル URL の確認

プロバイダの JAR ファイルの URL は、プロバイダの CodeSource を確認し、CodeSource に対して getLocation メソッドを呼び出すことにより取得できます。

    URL providerURL = (URL) AccessController.doPrivileged(
	new PrivilegedAction) {
	    public Object run() {
		CodeSource cs =
		    MyJCE.class.getProtectionDomain().getCodeSource();
		return cs.getLocation();
	    }
	}); 

JAR ファイルを参照する JarFile の作成

プロバイダの JAR ファイルの URL を取得したら、JAR ファイルを参照する java.util.jar.JarFile を作成できます。これは、「プロバイダ JAR ファイルの検証」で必要になります。

JAR ファイルを作成するには、まず、openConnection メソッドを呼び出し、指定された URL への接続を確立します。URL は JAR URL であるため、java.net.JarURLConnection 型になります。標準的なコードは以下のとおりです。

    // Prep the url with the appropriate protocol.
    jarURL =
	url.getProtocol().equalsIgnoreCase("jar") ? url :
	    new URL("jar:" + url.toString() + "!/");

    // Retrieve the jar file using JarURLConnection
    JarFile jf = (JarFile) AccessController.doPrivileged(
	new PrivilegedExceptionAction() {
	    public Object run() throws Exception {
		JarURLConnection conn =
		    (JarURLConnection) jarURL.openConnection();
	...  

JarURLConnection を取得できたら、getJarFile メソッドを呼び出して JAR ファイルを取得します。

    // Always get a fresh copy, so we don't have to
    // worry about the stale file handle when the
    // cached jar is closed by some other application.
    conn.setUseCaches(false);
    jf = conn.getJarFile(); 

プロバイダ JAR ファイルの検証: 基本

上記のステップに従ってプロバイダ JAR ファイルの URL を確認し、JAR ファイルを参照する JarFile を作成したら、ファイルの検証を行います。

基本的な方法は以下のとおりです。

1. 各エントリの署名者の証明書の少なくとも 1 つが、プロバイダ自身のコード署名証明書と等価であることを確認します。
2. JAR ファイルのすべてのエントリを確認して、各エントリの署名が適切であることを検証します。
3. 各エントリの署名者の証明書の少なくとも 1 つから、信頼できる証明書発行局までたどれることを確認します。

これらのステップで使用するサンプルコードについては、以下のセクションを参照してください。

検証の設定

ここでは、クラス JarVerifier を定義して指定された URL からの JAR ファイル取得を処理し、JAR ファイルが指定された証明書で署名されているかどうかを検証します。

JarVerifier のコンストラクタはプロバイダ URL をパラメータとして取ります。 これを使用して、JAR ファイルが取得されます。

実際の JAR 検証は、プロバイダコード署名証明書をパラメータとする verify メソッドで実装されます。

    public void verify(X509Certificate targetCert) throws IOException {
	// variable 'jarFile' is a JarFile object created
	// from the provider's Jar URL.
	...
	Vector entriesVec = new Vector(); 

verify は、基本的に JAR ファイルエントリを 2 回使用します。1 回目は各エントリの署名をチェックし、2 回目は署名者が信頼できることを検証します。

注: このコードでは、jarFile 変数は、プロバイダの jar ファイルの JarFile オブジェクトです。

JAR ファイル署名のチェック

認証されたプロバイダ JAR ファイルが署名されます。このため、署名されない JAR ファイルは、改変されています。

    // Ensure the jar file is signed.
    Manifest man = jarFile.getManifest();
    if (man == null) {
	throw new SecurityException("The provider is not signed");
    } 

署名の検証

次のステップでは、JAR ファイルのすべてのエントリを確認して、各エントリの署名が適切であることを検証します。JAR ファイルエントリの署名を検証する 1 つの方法は、単純なファイルの読み取りです。JAR ファイルが署名されていると、read メソッドが自動的に署名の検証を実行します。サンプルコードを次に示します。

    // Ensure all the entries' signatures verify correctly
    byte[] buffer = new byte[8192];
    Enumeration entries = jarFile.entries();

    while (entries.hasMoreElements()) {
	JarEntry je = (JarEntry) entries.nextElement();

	// Skip directories.
	if (je.isDirectory())
	    continue;

	entriesVec.addElement(je);
	InputStream is = jarFile.getInputStream(je);

	// Read in each jar entry. A security exception will
	// be thrown if a signature/digest check fails.
	int n;
	while ((n = is.read(buffer, 0, buffer.length)) != -1) {
	    // Don't care
	}
	is.close();
    }
    

署名者の信頼性の確認

前のセクションのコードでは、すべてのプロバイダ JAR ファイルエントリの署名を検証しました。すべてを適正に検証することは必須ですが、JAR ファイルの認証を確認するだけでは十分ではありません。最終的に、署名がこのプロバイダを構築したものと同じエントリから生成されたことを確認する必要があります。署名が信頼できることをテストするために、JAR ファイル内の各エントリをループ処理し (今回は前のステップで作成した entriesVec を使用)、署名の必要なエントリ (META-INF ディレクトリ内に存在しないディレクトリ以外のエントリ) ごとに次の操作を実行します。

1. エントリの署名者証明書のリストを取得します。
2. 個々の証明書チェーンを特定し、信頼できる証明書チェーンがあるかどうかを判定します。信頼できる証明書チェーンが 1 つ以上存在しなければなりません。

ループの設定方法を、次に示します。

    Enumeration e = entriesVec.elements();
    while (e.hasMoreElements()) {
	JarEntry je = (JarEntry) e.nextElement();
	...
    } 

証明書リストの取得

JAR ファイルエントリ JarEntry の署名者の証明書は、JarEntry の getCertificates メソッドを呼び出すだけで取得できます。

    Certificate[] certs = je.getCertificates();

前のループ設定コードに、上記のコードおよび META-INF ディレクトリ内のディレクトリおよびファイルを無視するコードを追加すると、次のようになります。

    while (e.hasMoreElements()) {
	JarEntry je = (JarEntry) e.nextElement();

	// Every file must be signed except files in META-INF.
	Certificate[] certs = je.getCertificates();
	if ((certs == null) || (certs.length == 0)) {
	    if (!je.getName().startsWith("META-INF"))
		throw new SecurityException(
		    "The provider has unsigned class files.");
	    } else {
		// Check whether the file is signed by the expected
		// signer. The jar may be signed by multiple signers.
		// See if one of the signers is 'targetCert'.
		...
	    }
	...  

個々の署名者の識別と信頼できる署名者の特定

JarEntry の getCertificates メソッドが返す証明書配列には、1 つ以上の証明書チェーンが含まれます。エントリの署名者ごとに 1 つのチェーンが存在します。各チェーンには、1 つ以上の証明書が含まれます。チェーン内の各証明書は、前の証明書の公開鍵を認証します。

チェーン内の最初の証明書には、エントリの署名に実際に使用される非公開鍵に対応する公開鍵を含む、署名者の証明書です。そのあとに続く証明書は、それぞれ前の証明書の発行者の証明書になります。自己整合性チェックは、JAR ファイルがプロバイダの署名証明書で署名されているかどうかを基準にしているため、信頼性の判断は最初の証明書である署名者の証明書のみで決定されます。

証明書チェーンの配列内で、「信頼できる」エンティティーが見つかるまで各チェーンおよび関連する署名者をチェックします。JAR ファイルエントリごとに、信頼できる署名者が少なくとも 1 人必要です。署名者が「信頼できる」と判断されるのは、証明書が、埋め込まれたプロバイダ署名証明書と等価である場合に限ります。

次のサンプルコードでは、すべての証明書チェーンでループ処理を行い、チェーンの最初の証明書と埋め込まれたプロバイダ署名証明書とを比較し、一致した場合に true だけを返します。

    int startIndex = 0;
    X509Certificate[] certChain;
    boolean signedAsExpected = false;

    while ((certChain = getAChain(certs, startIndex)) != null) {
	if (certChain[0].equals(targetCert)) {
	    // Stop since one trusted signer is found.
	    signedAsExpected = true;
	    break;
	}

	// Proceed to the next chain.
	startIndex += certChain.length;
    }

    if (!signedAsExpected) {
	throw new SecurityException(
	    "The provider is not signed by a trusted signer");
    }
    

getAChain メソッドは、次のように定義されます。

    /**
     * Extracts ONE certificate chain from the specified certificate array
     * which may contain multiple certificate chains, starting from index
     * 'startIndex'.
     */
    private static X509Certificate[] getAChain(
	    Certificate[] certs, int startIndex) {

	if (startIndex > certs.length - 1)
	    return null;

	int i;
	// Keep going until the next certificate is not the
	// issuer of this certificate.
	for (i = startIndex; i < certs.length - 1; i++) {
	    if (!((X509Certificate)certs[i + 1]).getSubjectDN().
		    equals(((X509Certificate)certs[i]).getIssuerDN())) {
		break;
	    }
	}

	// Construct and return the found certificate chain.
	int certChainSize = (i-startIndex) + 1;
	X509Certificate[] ret = new X509Certificate[certChainSize];
	for (int j = 0; j < certChainSize; j++ ) {
	    ret[j] = (X509Certificate) certs[startIndex + j];
	}
	return ret;
    }
    

myJCE コードサンプルについて

サンプルコード MyJCE.java は、自動的に整合性チェックを実行する selfIntegrityChecking メソッドを備えたサンプルプロバイダです。このコードは、まず固有のプロバイダ JAR ファイルの URL を特定します。 次に、このプロバイダ JAR ファイルに、組み込み済みのコード署名証明書による署名があるかどうかを検証します。

注: selfIntegrityChecking メソッドは、整合性を確保するため、その暗号化エンジンクラスの全コンストラクタによって呼び出されます。

プロバイダ MyJCE は、次のステップで自動的に整合性チェックを行います。

1. 固有のクラス MyJCE.class を使ってプロバイダ JAR ファイルにアクセスするための URL を特定する

2. ステップ 1 で特定したプロバイダ URL を使って JarVerifier オブジェクトをインスタンス化します。

3. 組み込みバイト配列 bytesOfProviderCert から X509Certificate オブジェクトを作成します。

4. JarVerifier.verify メソッドを呼び出し、プロバイダ JAR ファイル内のすべてのエントリに、ステップ 3 でインスタンス化した同じ証明書による署名があることを検証する

注: JarVerifier クラスは、所定の URL から JAR ファイルを取得し、その JAR ファイルに署名があるか、すべてのエントリに有効な署名があるか、これらのエントリに指定された X509Certificate による署名があるかどうかを検証します。

場合によっては、JarVerifier.verify によってセキュリティー例外がスローされます。

• verify とされた証明書が null (無効) である場合
• 所定の URL から JAR ファイルを取得できない場合
• プロバイダに署名がない場合(jar がマニフェストを持たない)
• プロバイダのクラスファイルの中に未署名のものがある場合
• プロバイダに指定された証明書による署名がない場合

サンプルコード MyJCE.java は、上記のコードで構成されます。さらに、エラー処理、サンプルコード署名証明書バイト、埋め込まれたサンプルコード署名証明書バイトからX509Certificate オブジェクトをインスタンス化するコードが含まれています。

AccessController.doPrivileged の使用については、「特権ブロックのための API」で doPrivileged の使用に関する説明を参照してください。

実装の詳細および要件

    Signature sig = Signature.getInstance("SHA1withDSA", "SUN");

    Signature sig = Signature.getInstance("SHA1/DSA", "SUN");

    Alg.Alias.engineClassName.aliasName

    put("Alg.Alias.Signature.SHA1/DSA", "SHA1withDSA");

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

SEED:  8d515589 4229d5e6 89ee01e6 018a237e 2cae64cd

SEQUENCE ::= {
	r INTEGER,
	s INTEGER }

   public interface DSAPrivateKey extends DSAKey,
		java.security.PrivateKey

   public interface DSAPublicKey extends DSAKey,
		java.security.PublicKey

   public interface DSAKey 

   public interface PrivateKey extends Key

   public interface PublicKey extends Key

   public interface Key extends java.io.Serializable