JavaTM 暗号化アーキテクチャ

API の仕様およびリファレンス


最終更新日: 2004 年 7 月 25 日

はじめに
設計方針
アーキテクチャ
概念
 
Java 2 Platform Standard Edition 5 の JCE の新機能
 
コアクラスとインタフェース
Provider クラス
プロバイダ実装の要求および獲得方法
プロバイダのインストール
Security クラス
MessageDigest クラス
Signature クラス
アルゴリズムパラメータのクラス
アプリケーションの暗号化制限の「免責」を取得する方法
コード例
MessageDigest オブジェクトの計算
鍵のペアの生成
生成された鍵を使った署名の生成および検証
鍵仕様および KeyFactory を使った署名の生成と検証
2 つの鍵の同一性の判定
Base64−符号化された証明書の読み取り
認証応答の解析
暗号化の使用
パスワードベース暗号化の使用
鍵協定の使用
付録 A: 標準名

付録 B: アルゴリズム

付録 C: SunJCE のキーサイズ制限

付録 D: 管轄ポリシーファイルの形式

付録 E: 「強力」な管轄ポリシーファイルにより許可される最大キーサイズ

付録 F: サンプルプログラム
2 つのパーティ間の Diffie-Hellman 鍵交換
3 つのパーティ間の Diffie-Hellman 鍵交換
Blowfish の例
HMAC-MD5 の例

はじめに

Security API は Java プログラミング言語のコア API で、java.security パッケージ (およびそのサブパッケージ) に組み込まれています。この API は、開発者が低レベルと高レベルの両方のセキュリティ機能をプログラムに組み込めるように設計されています。

JDK 1.1 で Security API が初めてリリースされた際、「Java 暗号化アーキテクチャ」(JCA) が導入されました。JCA とは、Java プラットフォームに暗号機能を開発し、これにアクセスするためのフレームワークのことです。JDK 1.1 では、JCA にデジタル署名とメッセージダイジェストの API が含められました。

続いてリリースされた Java 2 SDK では、このドキュメントで説明するように、Java 暗号化アーキテクチャが著しく拡張されています。また、X.509 v3 証明書をサポートする証明書管理インフラストラクチャがアップグレードされ、柔軟性と拡張性があり、適合性が高く細かいアクセス制御が可能な新しい Java セキュリティアーキテクチャが導入されています。

Java 暗号化アーキテクチャは、Java 2 SDK Security API の暗号化に関連する部分を組み込んでいます。また、このドキュメントに記載されている一連の規則と仕様も取り入れました。複数の暗号の実装とその相互運用を可能にする「プロバイダ」アーキテクチャも含まれています。

JavaTM 暗号化拡張機能 (JCE) は、暗号化、鍵生成と鍵協定、およびメッセージ認証コード (MAC) アルゴリズム用のフレームワークおよび実装を提供します。暗号化サポートには、対称、非対称、ブロック、およびストリーム暗号が含まれます。このソフトウェアは、セキュリティ保護されたストリームおよびシールされたオブジェクトもサポートします。

JavaTM 2 SDK, Standard Edition (Java 2 SDK) バージョン 1.2.x および 1.3.x では、JCE はオプションパッケージ (拡張機能) でした。Java 2 SDK 1.4 リリース以降では JCE が統合されています。

JCE API には、以下が含まれます。

Java 2 SDK, v 5.0 リリースには、SunJCE という名前の標準 JCE プロバイダがあらかじめインストールおよび登録されています。SunJCE は、次の暗号化サービスを提供します。

用語に関する注記

Java 2 SDK, v 5.0 の JCE には、次の 2 つのソフトウェアコンポーネントが含まれます。

このドキュメントでは、「JCE」という語は、Java 2 SDK, v 5.0 の JCE フレームワークを指して使われています。Java 2 SDK, v 5.0 とともに提供される JCE プロバイダに言及する場合、常に「SunJCE」プロバイダのことを明示的に指しています。
注: この JCA 仕様の最新版については、次のサイトを参照してください。http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html

設計方針

Java 暗号化アーキテクチャ (JCA) は、以下の方針に基づいて設計されました。

実装の独立性とアルゴリズムの独立性は相補関係にあります。そのため、デジタル署名やメッセージダイジェストなどの暗号化サービスを、実装の詳細やこれらの概念の基になるアルゴリズムを意識しないで使用できます。完全なアルゴリズムの独立性が不可能なときは、JCA は標準化された、アルゴリズム依存の API を提供します。実装の独立性が望ましくない場合、JCA では、開発者が特定の実装を指定できます。

アルゴリズムの独立性は、暗号化「エンジン」(サービス) の型を定義し、これらの暗号化エンジンの機能を提供するクラスを定義することにより実現しています。これらのクラスは「エンジンクラス」と呼ばれ、MessageDigest クラス、Signature クラス、KeyFactory クラス、および KeyPairGenerator クラスがこれに含まれます。

実装の独立性は、「プロバイダ」ベースのアーキテクチャを使って実現されます。暗号化サービスプロバイダ (このドキュメントでは「プロバイダ」とも呼ばれる) とは、デジタル署名アルゴリズム、メッセージダイジェスト、および鍵の変換サービスなどの 1 つ以上の暗号化を実行するパッケージやパッケージセットを意味します。プログラムは単に、特定のサービス (たとえば DSA 署名アルゴリズム) を実行する特定型のオブジェクト (たとえば Signature オブジェクト) を要求するだけで、インストールされているプロバイダの 1 つから実装を獲得できます。必要に応じて、プログラムは特定プロバイダから実装を要求することもできます。たとえば、より高速で安全性の高いバージョンが利用できるときは、プロバイダをアプリケーションに対して透過的に更新することができます。

実装の相互操作性とは、さまざまな実装が互いに機能でき、互いの鍵を使ったり、互いの署名を検証できることを意味します。つまり、1 つのプロバイダが生成した同じアルゴリズムや鍵を別のプロバイダが使ったり、あるプロバイダが生成した署名を別のプロバイダが検証するということです。

アルゴリズムの拡張性とは、サポートされるエンジンクラスの 1 つに当てはまる新規アルゴリズムを容易に追加できることを意味します。

アーキテクチャ

暗号化サービスプロバイダ

Java 暗号化アーキテクチャに、「暗号化サービスプロバイダ」(このドキュメントでは「プロバイダ」とも呼ばれる) の概念が導入されました。これは、Security API の暗号化に関するサブセットの固定実装を提供するパッケージ (またはパッケージセット) です。

たとえば、JDK 1.1 では、プロバイダには、1 つ以上のデジタル署名アルゴリズム、メッセージダイジェストアルゴリズム、および鍵生成アルゴリズムの実装などを含めることができました。Java 2 SDK では鍵ファクトリ、キーストアの作成および管理、アルゴリズムパラメータの管理、アルゴリズムパラメータの生成、および証明書ファクトリの 5 種類のサービスが追加されています。また、Java 2 SDK では、プロバイダが乱数の生成 (RNG) アルゴリズムを提供できます。これまで、JDK では、特定のアルゴリズムはハードコードされており、RNG もプロバイダベースではありませんでした。

すでに説明したように、プログラムは単に、特定サービス (たとえば DSA 署名アルゴリズム) 用の特定型のオブジェクト (たとえば Signature オブジェクト) を要求するだけで、インストールされているプロバイダの 1 つから実装を獲得できます。あるいは、特定プロバイダのオブジェクトを要求することもできます(各プロバイダは、それぞれの参照名を持つ)。

Sun が提供する Java Runtime Environment には、SUN という名前のデフォルトのプロバイダが標準で搭載されています。ほかの Java Runtime Environment には、SUN プロバイダが含まれない場合があります。SUN プロバイダパッケージには、以下のものが含まれています。

SDK では 1 つ以上のプロバイダパッケージがインストールされます。新規プロバイダは静的または動的に追加できます (Provider クラスと Security クラスを参照)。Java 暗号化アーキテクチャには、インストールされているプロバイダおよびそれらがサポートするサービスについて、ユーザが問い合わせることができる API セットがあります。

クライアントは異なるプロバイダを用いて実行環境を構成し、各プロバイダの「優先順位」を指定できます。優先順位とは、特定プロバイダの指定がない場合に、要求されたサービスに関して検索されるプロバイダの順位です。

鍵管理

「キーストア」と呼ばれるデータベースは、鍵および証明書のリポジトリを管理するために使用できます。キーストアは、証明書または署名の目的でキーストアが必要なアプリケーションで利用できます。

アプリケーションは、KeyStore クラスの実装を経由してキーストアにアクセスできます。キーストアクラスの実装は、java.security パッケージ内にあります。デフォルトのキーストアの実装は、米国 Sun Microsystems, Inc によって提供されます。これは、JKS という名前の独自のキーストアタイプ (形式) を使用するもので、キーストアをファイルとして実装しています。

アプリケーションでは、KeyStore クラスで提供される getInstance ファクトリメソッドを使って、異なるプロバイダから提供される数種類のキーストア実装から選択できます。

詳細は、「鍵管理」の項を参照してください。

概念

この項では、API に導入された重要な概念について説明します。

エンジンクラスとアルゴリズム

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

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

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

Java 2 SDK のリリース 1.4 では、次の新しいエンジンが追加されました。
注: 「ジェネレータ (generator)」は、最新の内容でオブジェクトを作成しますが、「ファクトリ (factory)」は既存の構成要素 (符号化法など) からオブジェクトを作成します。
エンジンクラスは、(特定の暗号化アルゴリズムに依存しない) 特定の型の暗号化サービス機能へのインタフェースを提供します。これにより、Application Programming Interface (API) メソッドが定義され、API が提供する特定の種類の暗号化サービスにアプリケーションがアクセスできるようになります。実際の実装 (1 つ以上のプロバイダから) は特定アルゴリズムのためのものです。たとえば Signature エンジンクラスは、デジタル署名アルゴリズムの機能へのアクセスを提供します。SignatureSpi サブクラスに実際に提供される実装は、DSA を使う SHA-1、RSA を使う SHA-1、または RSA を使う MD5 などの特定の種類の署名アルゴリズムとなります。

エンジンクラスが提供するアプリケーションインタフェースは、Service Provider Interface (SPI) として実装されます。つまり、各エンジンクラスに対応する抽象 SPI クラスが存在し、この抽象 SPI クラスによって暗号化サービスプロバイダが実装しなければならない SPI メソッドが定義されます。

エンジンクラスのインスタンスである 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 公開鍵や DSA 非公開鍵などの特定の種類の鍵の実際の実装を提供します。

実装とプロバイダ

各種暗号化サービスの実装は、JCA 暗号化サービスプロバイダが提供します。暗号化サービスプロバイダとは、1 つまたは複数の暗号化サービスの実装を提供する基本パッケージです。「エンジンクラスとアルゴリズム」には、Java 2 SDK のデフォルトのプロバイダである SUN が提供する実装の一覧が記載されています。

その他のプロバイダは、上記のサービスまたはその他のサービス (RSA ベースの署名アルゴリズムや MD2 メッセージダイジェストアルゴリズムなど) について、独自の実装を定義できます。

実装のインスタンスを獲得するためのファクトリメソッド

API の各エンジンクラスについては、エンジンクラス特有の「ファクトリメソッド」を呼び出すことによって特定の実装が要求され、インスタンスが生成されます。ファクトリメソッドは、クラスのインスタンスを返す static メソッドです。

たとえば、該当の Signature オブジェクト獲得機構は次のとおりです。ユーザは Signature クラスの getInstance メソッドを呼び出して、オブジェクトを要求します。署名アルゴリズム名 (SHA1withDSA など) を指定し、オプションでプロバイダまたは Provider クラスの名前も指定します。getInstance メソッドが、指定のアルゴリズムおよびプロバイダのパラメータを満たす実装を検索します。プロバイダの指定がない場合、getInstance は優先順位に従って登録プロバイダを検索し、指定のアルゴリズムを満たす実装を見つけ出します。プロバイダの登録の詳細は、Provider クラスを参照してください。

暗号化の概要

このセクションでは、API により実装される概念、および API 仕様で使用される技術用語の正確な意味に関する高度な説明を提供します。

暗号化および暗号解読

暗号化とは、データ (「クリアテキスト」と呼ばれる) および短い文字列 (「キー」) を受け取って、鍵を知らないサードパーティにとって無意味なデータ (「暗号テキスト」) を生成する処理です。暗号解読とはその逆で、暗号テキストおよび短い鍵文字列を受け取り、クリアテキストを生成する処理です。

パスワードベース暗号化

パスワードベース暗号化 (PBE) では、パスワードから暗号化鍵を導き出します。パスワードから暗号化鍵を取得しようとする攻撃者のタスクを非常に時間のかかるものにするため、大半の PBE 実装では、キーの作成時に乱数への混入 (salt と呼ばれる) が行われます。

暗号

暗号化および暗号解読は、暗号を使って行われます。暗号とは、暗号化方式に従って暗号化および暗号解読を実行可能なオブジェクトのことです。

鍵協定

鍵協定とは、複数のパーティが秘密情報を交換しなくても同じ暗号化鍵を確立可能なプロトコルを指します。

メッセージ認証コード

メッセージ認証コード (MAC) は、信頼できない媒体に送信または格納された情報の完全性を、秘密鍵に基づいてチェックする方法を提供します。一般に、メッセージ認証コードは、秘密鍵を共有する 2 つのパーティ間で送信される情報の有効性を検証する場合に使用されます。

暗号化ハッシュ機能に基づくMAC 機構は、HMAC と呼ばれます。HMAC は、秘密共有鍵と組み合わせて、MD5 や SHA-1 などの任意の暗号化ハッシュ機能で使用できます。HMAC については、RFC 2104 で規定されています。

Java 2 SDK, v 5.0 における JCE の新機能

v1.4 と v5.0 での JCE の相違点を次に示します。

PKCS #11 ベースの暗号プロバイダのサポート

5.0 では、ネイティブの PKCS#11 API に対する汎用ゲートウェイとして動作する JCA/JCE プロバイダ、SunPKCS11 が実装されました。PKCS #11 は暗号アクセラレータのデファクトスタンダードで、暗号化スマートカードへのアクセスに広く使用されています。管理者およびユーザは、このプロバイダを設定して、任意の PKCS#1 v2.x 互換トークンと通信できます。

設定ファイル形式の例を示します。

Solaris 暗号化フレームワークの統合

デフォルトの Java セキュリティプロバイダ設定が 5.0 で変更され、Solaris 10 では Solaris 暗号化フレームワークを使用する SunPKCS11 プロバイダのインスタンスが含まれるようになりました。これは最高の優先度をもつプロバイダで、既存のアプリケーションすべてが Solaris 10 でパフォーマンス向上のメリットを享受できます。Solaris 8 および Solaris 9 での動作に変更はありません。

この変更のため、すべての Solaris 10 システムでは、多くの暗号化演算が以前の何倍もの速度で実行されるようになります。暗号によるハードウェア高速化を搭載したシステムでは、100 倍のパフォーマンス向上を見込めます。

ECC アルゴリズムのサポート

5.0 より前では、JCA/JCE フレームワークでは、ECC 関連の暗号化アルゴリズムのクラスはサポートされていませんでした。ECC を利用するユーザは、ECC を実装したサードパーティのライブラリに頼らなければなりませんでした。しかし、このようなライブラリは既存の JCA/JCE フレームワークとはうまく統合されませんでした。

5.0 以降は、ECC をサポートするプロバイダ用の ECC クラスが完全にサポートされるようになりました。

次のインタフェースが追加されました。

次のクラスが追加されました。

ByteBuffer API サポートの追加

ByteBuffer 引数をとるメソッドが、バルクデータの処理に使用する JCE API および SPI クラスに追加されました。ByteBuffer を byte[] より効率的に処理できる場合、プロバイダは engine* メソッドをオーバーライドできます。

次の JCE メソッドが ByteBuffer のサポートのために追加されました。 

    javax.crypto.Mac.update(ByteBuffer input)
    javax.crypto.MacSpi.engineUpdate(ByteBuffer input)
    javax.crypto.Cipher.update(ByteBuffer input, ByteBuffer output)
    javax.crypto.Cipher.doFinal(ByteBuffer input, ByteBuffer output)
    javax.crypto.CipherSpi.engineUpdate(ByteBuffer input, ByteBuffer output)
    javax.crypto.CipherSpi.engineDoFinal(ByteBuffer input, ByteBuffer output)
次の JCA メソッドが ByteBuffer のサポートのために追加されました。 
    java.security.MessageDigest.update(ByteBuffer input)
    java.security.Signature.update(ByteBuffer data)
    java.security.SignatureSpi.engineUpdate(ByteBuffer data)
    java.security.MessageDigestSpi.engineUpdate(ByteBuffer input)

RC2ParameterSpec のサポート

5.0 では RC2 アルゴリズム実装が拡張され、入力された鍵の長さとは異なる有効な鍵サイズをサポートします。

XML 暗号化 RSA-OAEP アルゴリズムの完全サポート

5.0 より前のJCE では、PKCS#1 v2.1 および W3C Recommendation for XML Encryption の RSA-OAEP 鍵転送アルゴリズムに定義されているように、OAEP および PSS パディングで使用されるデフォルト以外の値を指定するパラメータクラスが定義されていませんでした。したがって、OAEP および PSS パディングに使用されたデフォルト以外の値をアプリケーションで指定する一般的な方法はありませんでした。

5.0 では、新しいパラメータクラスが追加され、OAEP パディングが完全にサポートされます。また、PSS パラメータクラスが拡張されて、API が RSA PSS シグニチャー実装を完全にサポートします。さらに、SunJCE プロバイダが拡張され、OAEPPadding が使用された場合に、OAEPParameterSpec を受け入れるようになりました。

次のクラスが追加されました。

次のメソッドおよびフィールドが、java.security.spec.PSSParameterSpec に追加されました。 

    public static final PSSParameterSpec DEFAULT
    public PSSParameterSpec(String mdName, String mgfName,
                            AlgorithmParameterSpec mgfSpec,
                            int saltLen, int trailerField)
    public String getDigestAlgorithm()
    public String getMGFAlgorithm()
    public AlgorithmParameterSpec getMGFParameters()
    public int getTrailerField()

javax.crypto.EncryptedPrivateKeyInfo からの PKCS8EncodedKeySpec の取得の簡略化

5.0 では、javax.crypto.EncryptedPrivateKeyInfo はただ 1 つのメソッド getKeySpec(Cipher) を持ち、暗号化されたデータから PKCS8EncodedKeySpec を取得します。この制限のため、ユーザは暗号解読鍵およびパラメータで初期化される暗号を指定する必要があります。ユーザが暗号解読鍵のみを持つ場合、まずパラメータをこの EncryptedPrivateKeyInfo オブジェクトから取得し、適合する Cipher 実装を確保し、初期化し、そして getKeySpec(Cipher) メソッドを呼び出さなければなりません。

EncyptedPrivateKeyInfo の使用をより簡単にし、API に javax.crypto.SealedObject と一貫性を持たせるため、次のメソッドが javax.crypto.EncryptedPrivateKeyInfo に追加されました。 

    getKeySpec(Key decryptKey)
    getKeySpec(Key decryptKey, String provider)

鍵の最大許容長の動的判定

1.4.2 では、J2SE にバンドルされた暗号化管轄ポリシーファイルによって、暗号/暗号解読に使用する鍵の最大長が制限されます。また、ある種の暗号アルゴリズムのパラメータ値も制限されます。制限のない暗号化管轄ファイルを使用したいユーザは、ファイルを個別にダウンロードする必要があります。

また、Cipher インスタンスが、暗号化管轄ファイルで許容された最大値を超える鍵 (またはある種の暗号アルゴリズムのパラメータ) で初期化されると、例外がスローされます。

5.0 では、Cipher クラスが更新され、管轄ポリシーファイルで設定された鍵の最大長およびパラメータを定義するようになったため、デフォルトの (強度の制限された) 管轄ポリシーファイルがインストールされている場合、アプリケーションはより短かい鍵を使用できます。

次のメソッドが javax.crypto.Cipher に追加されました。 

    public static final int getMaxAllowedKeyLength(String transformation)
             throws NoSuchAlgorithmException

    public static final AlgorithmParameterSpec
             getMaxAllowedParameterSpec(String transformation)
             throws NoSuchAlgorithmException;

HmacSHA256、HmacSHA384、および HmacSHA512 のサポート

HmacSHA-256、HmacSHA-384、および HmacSHA-512 アルゴリズムのサポートが 5.0 で追加されました。

SunJCE プロバイダへの RSA 暗号のサポート

一般にアクセスできる RSA 暗号化実装が、SunJCE プロバイダに追加されました。

SunJCE プロバイダへの RC2 および ARCFOUR 暗号のサポート

SunJCE プロバイダに、RC2 (RFC 2268) および ARCFOUR (RC4TM 互換アルゴリズム) 暗号が実装されました。

「PBEWithSHA1AndDESede」と「PBEWithSHA1AndRC2_40」暗号のサポート

SunJCE プロバイダに、PBEWithSHA1AndDESede と PBEWithSHA1AndRC2_40 暗号のサポートが追加されました。

JCE Block Encryption 暗号での XML Encryption Padding アルゴリズムのサポート

W3C XML 暗号で、新しいパディングアルゴリズム、ブロック暗号に対する「ISO10126Padding」が定義されます。詳細については、「5.2 Block Encryption Algorithms」を参照してください。

Sun のプロバイダを XML 暗号実装および JSR 106 プロバイダで使用できるようにするため、5.0 ではこのパディングに対するサポートが追加されました。

コアクラスとインタフェース

この項では、Java 暗号化アーキテクチャで提供するコアクラスとインタフェースについて説明します。

エンジン クラス

  • Key インタフェースおよびクラス

  • 「アルゴリズムパラメータの仕様のインタフェースおよびクラス」および「鍵仕様のインタフェースおよびクラス」

    この項では、各クラスおよびインタフェースのメインメソッドの署名を示します。該当する例の項には、クラス (MessageDigest、Signature、KeyPairGenerator、SecureRandom、KeyFactory、および鍵仕様クラス) の例があります。 Security API パッケージの完全なリファレンスドキュメントを以下に示します。

    • Provider クラス

    「暗号化サービスプロバイダ」(このドキュメントでは「プロバイダ」とも呼ばれる) とは、Java 2 SDK Security API の暗号化機能のサブセットの固定実装を提供するパッケージまたはパッケージセットです。Provider クラスは、このようなパッケージやパッケージセットへのインタフェースです。プロバイダ名、バージョン番号、その他の情報にアクセスするためのメソッドを備えています。Provider クラスを使用すると、暗号化サービスの実装を登録するだけでなく、その他のセキュリティサービスの実装を登録することもできます。その他のセキュリティサービスは、Java 2 SDK Security API またはその拡張機能の 1 つの一部として定義されている場合があります。

    暗号化サービスの実装を提供するには、エンティティ (たとえば開発グループ) は実装コードを作成し、Provider クラスのサブクラスを生成します。Provider サブクラスのコンストラクタは、プロバイダが実装したサービスを検索するために Java 2 SDK Security API が使用する各種プロパティの値を設定します。つまり、サブクラスは、サービスを実装するクラス名を指定します。

    プロバイダパッケージが実装できるサービスには、さまざまな種類があります。詳細については、「エンジンクラスとアルゴリズム」を参照してください。

    実装が違うと、特徴も違ってくる場合があります。ソフトウェアベースのものもあれば、ハードウェアベースのものもあります。プラットフォーム独立のものもあれば、プラットフォーム固有のものもあります。また、レビューや評価用に使えるプロバイダコードもあれば、使えないものもあります。Java 暗号化アーキテクチャ (JCA) では、エンドユーザと開発者の双方が独自のニーズを決定できます。

    この項では、エンドユーザのための暗号実装のインストール方法とニーズへの合わせ方、および開発者のための必要な実装の要求方法を説明します。

    注: プロバイダの実装の詳細は、「Java 暗号化アーキテクチャ用プロバイダの実装方法」を参照してください。

    プロバイダ実装の要求および獲得方法

    この API の各エンジンクラスについては、特定の実装が要求され、そのエンジンクラスの getInstance メソッドを呼び出してインスタンスが生成されます。このときに、希望するアルゴリズムの名前と、実装したいプロバイダ (または Provider クラス) の名前 (オプション) を指定します。

    プロバイダを指定しない場合、getInstance は、指定されたアルゴリズムに関連する、要求された暗号化サービスの実装に対応する登録プロバイダを検索します。どの Java 仮想マシン (JVM) でも、プロバイダは指定の「優先順位」でインストールされます。優先順位とは、特定プロバイダの指定がない場合に、プロバイダリストが検索される順位です。たとえば、JVM に、PROVIDER_1 と PROVIDER_2 という 2 つのプロバイダがインストールされ、次のようになっていると仮定します。

    ここで、3 つのシナリオについて見てみます。
    1. MD5 実装を検索するとする。どちらのプロバイダもこの実装を供給する。PROVIDER_1 が最高の優先順位を持ち最初に検索されるので、PROVIDER_1 実装が返される
    2. MD5withRSA 署名アルゴリズムを検索する場合、まず最初に PROVIDER_1 が検索される。実装が見つからないので次に PROVIDER_2 が検索される。実装が見つかるので、このプロバイダが返される
    3. SHA1withRSA 署名アルゴリズムを検索する場合を想定する。これを実装するプロバイダはインストールされていないので、NoSuchAlgorithmException がスローされる

    プロバイダ引数を持つ getInstance メソッドは、必要なアルゴリズムを提供するプロバイダを指定したい開発者のためのものです。たとえば、連邦証明書を受け取ったプロバイダ実装を連邦局が使いたいとします。PROVIDER_1 の SHA1withDSA 実装はこの証明書を受け取っていないのに対し、PROVIDER_2 の DSA 実装がこれを受け取っていると仮定します。

    連邦局のプログラムは以下の呼び出しを実行します。PROVIDER_2 が認証された実装を持つため、これを指定します。 

    Signature dsa = Signature.getInstance("SHA1withDSA", "PROVIDER_2");

    この場合、PROVIDER_2 がインストールされていないと、インストールされている別のプロバイダが要求アルゴリズムを実装している場合であっても、NoSuchProviderException がスローされます。

    プログラムは、(Security クラスの getProviders メソッドを使って) インストールされているプロバイダの一覧を獲得し、一覧から選択することもできます。

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

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

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

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

    1. クラスが格納されている zip または JAR ファイルを、classpath の任意の場所に置く

    2. プロバイダ JAR ファイルを、「インストールされた」または「バンドルされた」拡張機能として指定する。拡張機能の配置方法の詳細については、「拡張機能の配置」を参照

    プロバイダの構成

    次の手順では、認可プロバイダのリストにこのプロバイダを追加します。この手順は、SDK の lib/security ディレクトリにある java.security ファイルを編集することによって静的に行うことができます。つまり、SDK が j2sdk1.2 というディレクトリにインストールされている場合、ファイルの位置は j2sdk1.2/lib/security/java.security になります。 java.security で設定できるプロパティの例を次に示します。 

    security.provider.n=masterClassName

    これはプロバイダを宣言し、その優先順位 n を指定します。優先順位とは、特定プロバイダの指定がない場合に、要求されたサービスに関して検索されるプロバイダの順位です。順位は 1 から始まり、1 が最優先で次に 2、3 ... と続きます。

    masterClassName には、プロバイダのマスタークラスを指定する必要があります。プロバイダのドキュメントでそのマスタークラスを指定します。このクラスは、常に Provider クラスのサブクラスです。サブクラスコンストラクタは、プロバイダが実装したアルゴリズムやその他の機能を検索するために Java 暗号化 API に必要な各種プロパティの値を設定します。

    マスタークラスが COM.acme.provider.Acme で、優先順位が第 3 位のプロバイダとして Acme を構成したいとします。このためには、次の行を java.security ファイルに追加します。 

    security.provider.3=COM.acme.provider.Acme
    プロバイダは、動的に登録することもできます。このためには、Security クラスの addProvider または insertProviderAt のどちらかのメソッドを呼び出します。この登録は恒久的ではなく、「信頼できる」プログラムでしか実行できません。Security クラスを参照してください。

    Provider クラスのメソッド

    各 Provider クラスインタフェースは、名前 (現時点では大文字と小文字を区別する)、バージョン番号、およびプロバイダとそのサービスの文字列記述を持ちます。以下のメソッドを呼び出して、これらの情報について Provider のインスタンスを照会できます。 

    public String getName()
public double getVersion()
public String getInfo()

    Security クラス

    Security クラスは、インストールされているプロバイダおよびセキュリティに関するプロパティを管理します。このクラスに含まれるのは、インスタンスが生成されない static メソッドだけです。 プロバイダの追加または削除、および Security プロパティの設定用メソッドは、信頼できるプログラムによってしか実行できません。現時点での「信頼できるプログラム」は、以下のどれかです。

    あるコードが、実行しようとしているアクション (プロバイダの追加など) を行うことができるような、信頼できるコードであると判断するには、そのアクションを行う権限がそのアプレットに与えられている必要があります。

    たとえば、Policy のリファレンス実装では、SDK インストールのポリシー構成ファイルには、指定されたコードソースのコードにより許可された権限 (システムリソースへのアクセスの種類) を指定します。詳細は、以降の説明および「デフォルトの Policy の実装とポリシーファイルの構文」と「Java セキュリティアーキテクチャ」を参照してください。

    実行されるコードは、常に、特定の「コードソース」から来ると考えられます。コードソースには、そのアプレットの元の場所 (URL) だけでなく、コードの署名に使われた非公開鍵に対応する公開鍵への参照も含まれています。コードソース内の公開鍵は、ユーザのキーストアの別名 (記号名) で参照します。

    ポリシー構成ファイル内では、コードソースは、コードベース (URL)、および (signedBy で始まる) 別名の 2 つのコンポーネントで表されます。別名は、コードの署名の検証に使う必要のある公開鍵を含んだキーストアのエントリを識別します。

    このようなファイル内の各「許可」文は、指定されたコードソースにアクセス権のセットを与え、許可された処理を指定します。

    次に、ポリシー構成ファイルの例を示します。 

    grant codeBase "file:/home/sysadmin/", signedBy "sysadmin" {
permission java.security.SecurityPermission "insertProvider.*";
permission java.security.SecurityPermission "removeProvider.*";
permission java.security.SecurityPermission "putProviderProperty.*";
};
    この構成ファイルは、ローカルファイルシステム上の /home/sysadmin/ ディレクトリ内の署名された JAR ファイルからロードされたコードだけが、プロバイダの追加または削除、あるいはプロバイダのプロパティの設定ができることを示します。JAR ファイルの署名は、ユーザのキーストア内の別名 sysadmin で参照する公開鍵を使って検証できます。

    コードソースを指定する要素は、どちらも (または両方を) 省略可能です。次に、codeBase を省略した構成ファイルの例を示します。 

    grant signedBy "sysadmin" {
permission java.security.SecurityPermission "insertProvider.*";
permission java.security.SecurityPermission "removeProvider.*";
};
    このポリシーが施行された場合、sysadmin によって署名された JAR ファイルのコードによるプロバイダの追加または削除が可能になります。JAR ファイルの場所は関係ありません。

    次に、署名者を省略した例を示します。 

    grant codeBase "file:/home/sysadmin/" {
permission java.security.SecurityPermission "insertProvider.*";
permission java.security.SecurityPermission "removeProvider.*";
};
    この場合、ローカルファイルシステムの /home/sysadmin/ ディレクトリ内に置かれたコードは、プロバイダの追加と削除を行うことができます。コードに署名は必要ありません。

    codeBase と signedBy を両方とも省略した例を次に示します。 

    grant {
permission java.security.SecurityPermission "insertProvider.*";
permission java.security.SecurityPermission "removeProvider.*";
};
    この例では、コードソースを指定する要素がどちらも省略されています。したがって、出所がどこか、署名が付いているか、誰の署名が付いているかに関係なく、どのコードでもプロバイダの追加と削除が行えます。

    プロバイダの管理

    次の表に、Security クラス内のメソッドのうち、インストールされているプロバイダを照会するために使用できるメソッドと、実行時にプロバイダをインストールまたは削除するためのメソッドの要約を示します。

    プロバイダの照会
    メソッド 説明
    static Provider[] getProviders() インストールされているすべてのプロバイダを含む配列 (つまり、各パッケージプロバイダの Provider サブクラス) を返す。配列内のプロバイダの順序は、優先順位に従う
    static Provider getProvider
    (String providerName)    		 このメソッドは、providerName という名前のプロバイダを返す。このプロバイダが見つからないと null を返す

    プロバイダの追加
    メソッド 説明 
    static int 
    addProvider(Provider provider)
    		 インストールされたプロバイダ一覧の末尾にプロバイダを追加する。プロバイダが追加された優先順位を返すか、すでにインストールされているためにプロバイダが追加されなかった場合は -1 を返す
    static int insertProviderAt
    (Provider provider, int position)

    指定された位置に新規のプロバイダを追加する。あるプロバイダが要求された場所にインストールされた場合は、それまでその場所にあったプロバイダ、および position よりあとの位置のすべてのプロバイダの順位は、1 つあとになり、一覧の最後尾に向かって 1 つ移動する。このメソッドは、プロバイダが追加された優先順位を返すか、すでにインストールされているためにプロバイダ が追加されなかった場合は -1 を返す

    プロバイダの削除
     メソッド  説明
    static void removeProvider(String name) 指定した名前のプロバイダを削除する。プロバイダがインストールされていない場合は、何もせず復帰する。指定されたプロバイダが削除されると、そのプロバイダよりもあとの位置にあるすべてのプロバイダの位置が 1 つ前になり、インストールされたプロバイダ一覧の先頭に向かって 1 つ移動する

    注: プロバイダの優先順位を変更する場合は、まず目的のプロバイダを削除してから、希望する優先順位の位置に挿入し直す必要があります。

    セキュリティのプロパティ

    Security クラスは、システムに関するセキュリティのプロパティリストを保持します。これらのプロパティは、以下のメソッドを使って、信頼できるプログラムからアクセスして設定できます。 

    static String getProperty(String key)
static void setProperty(String key, String datum)

    MessageDigest クラス

    MessageDigest クラスはエンジンクラスで、安全な暗号化メッセージダイジェスト (SHA-1 や MD5 など) の機能を提供するように設計されています。安全な暗号化メッセージダイジェストは、任意サイズの入力 (バイト配列) を取り、固定サイズ出力を生成します。これを「ダイジェスト」または「ハッシュ」と言います。ダイジェストには次の 2 つの特徴があります。

    メッセージダイジェストを使い、一意で、信頼できるデータ識別子を生成します。データ識別子をデータの「デジタル指紋」と呼ぶこともあります。

    MessageDigest オブジェクトの生成

    ダイジェスト計算では、まず最初にメッセージダイジェストのインスタンスを生成します。どのエンジンクラスの場合も同様に、MessageDigest クラスの static ファクトリメソッド getInstance を呼び出して、特定型のメッセージダイジェストアルゴリズムの MessageDigest オブジェクトを獲得します。 

    static MessageDigest getInstance(String algorithm)
    注: アルゴリズム名の大文字と小文字は区別されません。たとえば、次の呼び出しはすべて等価と見なされます。 
    MessageDigest.getInstance("SHA-1")
MessageDigest.getInstance("sha-1")
MessageDigest.getInstance("sHa-1")

    呼び出し側は、任意でプロバイダまたは Provider インスタンスの名前を指定できます。プロバイダ名を指定すると、要求するアルゴリズムの実装を確実に指定プロバイダから取得できます。 

    static MessageDigest getInstance(String algorithm, String provider)
static MessageDigest getInstance(String algorithm, Provider provider)

    getInstance を呼び出すと、初期化されたメッセージダイジェストオブジェクトが返ります。したがって、このあとで初期化を行う必要はありません。

    メッセージダイジェストオブジェクトのアップデート

    データのダイジェストを計算するための次の手順は、初期化したメッセージダイジェストオブジェクトにデータを入れることです。これは、次のいずれかの update メソッドを呼び出すことによって実行します。 

    void update(byte input)
void update(byte[] input)
void update(byte[] input, int offset, int len)

    ダイジェストの計算

    update メソッドを呼び出してデータを入れたあとで、次の digest メソッドのうちのどれか 1 つを使ってダイジェストを計算します。 

    byte[] digest()
byte[] digest(byte[] input)
int digest(byte[] buf, int offset, int len)

    最初の 2 つのメソッドは、計算されたダイジェストを返します。最後のメソッドは、オフセット位置 offset から開始する提供バッファ buf 内に算出ダイジェストを格納します。len は、ダイジェストに割り当てられた buf 内のバイト数です。このメソッドは、実際に buf 内に格納されたバイト数を返します。

    入力バイトの配列を引数に取る digest メソッドの呼び出しは、以下の呼び出しと等価です。 

    void update(byte[] input)
    入力を指定し、そのあとに引数を持たない digest メソッドの呼び出しが続きます。

    詳細は、例を参照してください。

    Signature クラス

    Signature クラスはエンジンクラスで、DSA や MD5 を使う RSA などの暗号化デジタル署名機能を提供するように設計されています。安全な暗号化署名アルゴリズムは、任意サイズの入力と非公開鍵を取り、「署名」と呼ばれる比較的短い (固定サイズの場合もよくある) バイト文字列を生成します。このプロパティは次のとおりです。

    Signature オブジェクトを使って、データに署名を付けることができます。また、指定の署名が、関連データの実際の認証署名かどうかを検証することもできます。 データの署名および検証の例は、例の項を参照してください。

    Signature オブジェクトの状態

    Signature オブジェクトはモデルオブジェクトです。つまり、Signature オブジェクトは、常に指定の状態にあり、この状態で 1 つの型の操作だけを実行できます。状態は、個々のクラスで定義した final (ファイナル) 整数の定数で表されます。

    Signature オブジェクトに可能な状態は、次の 3 つです。

    Signature オブジェクトが初めて生成されるときは、UNINITIALIZED の状態です。Signature クラスは、状態を SIGN に変更する initSign と、状態を VERIFY に変更する initVerify の 2 つの初期化メソッドを定義します。

    Signature オブジェクトの生成

    署名を付けたり、検証したりするには、最初に Signature のインスタンスを生成します。どのエンジンクラスの場合も同様に、Signature クラスの static ファクトリメソッド getInstance を呼び出して、特定型のメッセージ署名アルゴリズムの Signature オブジェクトを獲得します。 
    static Signature getInstance(String algorithm)
    注: アルゴリズム名の大文字と小文字は区別されません。
    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求するアルゴリズムの実装を確実に指定プロバイダから取得できます。 

    static Signature getInstance(String algorithm, String provider)
static Signature getInstance(String algorithm, Provider provider)

    Signature オブジェクトの初期化

    Signature オブジェクトを使うには、最初に必ずこれを初期化します。初期化メソッドは、オブジェクトを署名用に使うか検証用に使うかに応じて異なります。

    署名で使う場合、オブジェクトは最初に、署名を生成するエンティティの非公開鍵を使って初期化する必要があります。この初期化は、以下のメソッドを呼び出して実行します。 

    final void initSign(PrivateKey privateKey)
    このメソッドでは、Signature オブジェクトは SIGN 状態になります。

    Signature オブジェクトを検証で使う場合は、まず最初に、署名を検証するエンティティの公開鍵を使って初期化する必要があります。この初期化は、以下のいずれかのメソッドを呼び出して実行します。 

    final void initVerify(PublicKey publicKey)

final void initVerify(Certificate certificate)

    このメソッドでは、Signature オブジェクトは VERIFY 状態になります。

    署名

    Signature オブジェクトを署名用に初期化した場合 (このオブジェクトが SIGN 状態の場合)、署名を付けるデータをオブジェクトに入れることができます。これは、以下の update メソッドのどれか 1 つを 1 回または複数回呼び出して実行します。 

    final void update(byte b)
final void update(byte[] data)
final void update(byte[] data, int off, int len)

    署名を付けるデータがすべて Signature オブジェクトに入るまで、update メソッドを呼び出します。

    署名を生成するには、sign メソッドの 1 つを呼び出すだけです。 

    final byte[] sign()
final int sign(byte[] outbuf, int offset, int len)

    最初のメソッドは、署名の結果をバイト配列で返します。2 番目のメソッドは、オフセット位置 offset から開始する提供バッファ outbuf 内に署名の結果を格納します。len は、署名に割り当てられた outbuf 内のバイト数です。このメソッドは、実際に格納されたバイト数を返します。

    署名の符号化は、アルゴリズムに依存します。Java 暗号化アーキテクチャでの ASN.1 符号化の使用方法については、「付録 B」を参照してください。

    sign メソッドを呼び出すと、signature (署名) オブジェクトは、initSign を呼び出して最初に署名用に初期化されたときの状態にリセットされます。つまり、オブジェクトをリセットするので、必要であれば update と sign を呼び出して、同じ非公開鍵を使って別の署名を生成できます。

    あるいは異なる非公開鍵を指定し、initSign への新規呼び出しを作成したり、(署名を検証するために Signature オブジェクトを初期化する目的で) initVerify への新規呼び出しを作成したりできます。

    検証

    Signature オブジェクトを検証用に初期化した場合 (VERIFY 状態にある場合) は、指定の署名が、それに関連したデータの実際の認証署名であるかどうかを検証できます。この処理を開始するには、検証データ (署名自体ではない) をオブジェクトに入れます。データは、次のいずれかの update メソッドを呼び出すことによってオブジェクトに渡されます。 

    final void update(byte b)
final void update(byte[] data)
final void update(byte[] data, int off, int len)

    検証するデータがすべて Signature オブジェクトに入るまで、update メソッドを呼び出します。これで、次のいずれかの verify メソッドを呼び出して署名を検証できます。 

    final boolean verify(byte[] signature)

final boolean verify(byte[] signature, int offset, int length)

    引数は、署名を含むバイト配列である必要があります。引数は、署名を含むバイト配列である必要があります。このバイト配列は、前にいずれかの sign メソッドの呼び出しによって返された署名バイトを保持します。

    verify メソッドは、コード化した署名が update メソッドに入れたデータの認証署名かどうかを示す boolean を返します。

    verify メソッドを呼び出すと、signature (署名) オブジェクトは、initVerify を呼び出して検証用に初期化されたときの状態にリセットされます。つまり、オブジェクトをリセットするので、initVerify への呼び出しで指定した公開鍵を持つ識別の別の署名を検証できます。

    あるいは異なる非公開鍵を指定し、(異なるエンティティの署名を検証するために Signature オブジェクトを初期化する目的で) initVerify への新規呼び出しを作成したり、(署名を生成するために Signature オブジェクトを初期化する目的で) initSign への新規呼び出しを作成したりできます。

    アルゴリズムパラメータのクラス

    アルゴリズムパラメータの仕様のインタフェースおよびクラス

    アルゴリズムパラメータの仕様は、アルゴリズムとともに使われるパラメータのセットの透明な表現です。

    パラメータのセットの「透明な」表現とは、セットの各パラメータの値に個別にアクセスできることを意味します。これらの値には、対応する仕様クラスに定義された get メソッドの 1 つを使ってアクセスできます (たとえば、DSAParameterSpec では、getP、getQ、および getG メソッドを定義して、それぞれ p、q、および g にアクセスする)。

    これに対して、AlgorithmParameters クラスは「不透明な」表現を提供します。「不透明な」表現では、パラメータフィールドに直接アクセスできません。パラメータセットに関連付けられたアルゴリズム名の取得 (getAlgorithm による)、およびそのパラメータセット用のある種の符号化の取得 (getEncoded による) しかできません。

    以下は、java.security.spec パッケージに含まれるアルゴリズムパラメータ仕様のインタフェースおよびクラスの説明です。

    AlgorithmParameterSpec インタフェース

    AlgorithmParameterSpec は、暗号化パラメータの透明な仕様へのインタフェースです。

    このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべてのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。すべてのパラメータの仕様で、このインタフェースを実装する必要があります。

    DSAParameterSpec クラス

    AlgorithmParameterSpec インタフェースを実装するこのクラスは、DSA アルゴリズムで使われるパラメータのセットを指定します。このクラスには、次のメソッドがあります。 
    BigInteger getP()
BigInteger getQ()
BigInteger getG()
    これらのメソッドは、DSA アルゴリズムパラメータであるプライムの p、サブプライムの q、およびベースの g を返します。

    AlgorithmParameters クラス

    AlgorithmParameters クラスは、暗号化パラメータの不透明な表現を提供するエンジンクラスです。

    「不透明な」表現では、パラメータフィールドに直接アクセスすることはできません。パラメータセットに関連付けられたアルゴリズム名の取得、およびそのパラメータセット用のある種の符号化の取得しかできません。これと対照的なのが、パラメータの「透明な」表現です。この場合、対応する仕様クラスで定義された get メソッドの 1 つを使って、値に個々にアクセスできます。AlgorithmParameters に getParameterSpec メソッドを呼び出して、AlgorithmParameters オブジェクトを透明な仕様に変換できます (以下を参照)。

    AlgorithmParameters オブジェクトの作成

    どのエンジンクラスの場合も同様に、AlgorithmParameters クラスの static ファクトリメソッド getInstance を呼び出して、特定型のアルゴリズムの AlgorithmParameters オブジェクトを獲得します。 

    static AlgorithmParameters getInstance(String algorithm)
    注: アルゴリズム名の大文字と小文字は区別されません。
    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求するアルゴリズムパラメータの実装を確実に指定プロバイダから取得できます。 
    static AlgorithmParameters getInstance(String algorithm, String provider)
static AlgorithmParameters getInstance(String algorithm, Provider provider)

    AlgorithmParameters オブジェクトの初期化

    AlgorithmParameters オブジェクトのインスタンスが生成されたら、適切なパラメータの仕様またはパラメータの符号化を使って、init への呼び出しによる初期化を行う必要があります。 

    void init(AlgorithmParameterSpec paramSpec)
void init(byte[] params)
void init(byte[] params, String format)
    これらの init メソッドで、 params は、符号化されたパラメータを含む配列で、format は、復号化形式の名前です。params 引数を指定し、format 引数を指定しない init メソッドでは、パラメータのプライマリ復号化形式が使われます。パラメータの ASN.1 仕様が存在する場合は、プライマリ復号化形式は、ASN.1 です。
    注: AlgorithmParametersオブジェクトは、1 回だけ初期化できます。再利用はできません。

    符号化されたパラメータの取得

    AlgorithmParameters オブジェクトで表現されるパラメータのバイト符号化は、getEncoded への呼び出しによって取得できます。 

    byte[] getEncoded()
    このメソッドは、パラメータをプライマリ符号化形式で返します。この種のパラメータの ASN.1 仕様が存在する場合は、プライマリ復号化形式は、ASN.1 です。

    特定の形式でパラメータが返されるようにするには、次のように記述します。 

    byte[] getEncoded(String format)
    format が null の場合は、ほかの getEncoded メソッドと同様に、プライマリ復号化形式が使われます。
    注: Sun プロバイダによって提供されるデフォルトの AlgorithmParameters の実装では、format 引数は、現在のところ無視されます。

    AlgorithmParameters オブジェクトから透明な仕様への変換

    アルゴリズムパラメータの透明なパラメータの仕様は、getParameterSpec への呼び出しにより、AlgorithmParameters オブジェクトから取得できます。 

    AlgorithmParameterSpec getParameterSpec(Class paramSpec)
    paramSpec は、パラメータが返されるべき仕様クラスを識別します。たとえば、仕様クラス DSAPublicKeySpec.class が識別された場合、パラメータが DSAParameterSpec クラスのインスタンスに返されるべきであることを指示します。このクラスは、java.security.spec パッケージに含まれます。

    AlgorithmParameterGenerator クラス

    AlgorithmParameterGenerator クラスは、特定のアルゴリズム (AlgorithmParameterGenerator のインスタンスの作成時に指定されるアルゴリズム) に適したパラメータのセットの生成に使用されるエンジンクラスです。

    AlgorithmParameterGenerator オブジェクトの作成

    どのエンジンクラスの場合も同様に、AlgorithmParameterGenerator クラスの static ファクトリメソッド getInstance を呼び出して、特定型のアルゴリズムの AlgorithmParameterGenerator オブジェクトを獲得します。 

    static AlgorithmParameterGenerator getInstance(
String algorithm)
    注: アルゴリズム名の大文字と小文字は区別されません。

    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、アルゴリズムパラメータジェネレータの実装を確実に指定プロバイダから取得できます。 

    static AlgorithmParameterGenerator getInstance(
String algorithm,
String provider)

static AlgorithmParameterGenerator getInstance(
String algorithm,
Provider provider)

    AlgorithmParameterGenerator オブジェクトの初期化

    AlgorithmParameterGenerator オブジェクトは、アルゴリズム独立型、またはアルゴリズム特定型の 2 種類の方法で初期化できます。

    アルゴリズム独立型の方法では、すべてのパラメータジェネレータが「サイズ」および乱数の発生源という概念を共有するという特性を利用します。サイズの単位は、すべてアルゴリズムパラメータで普遍的に共通していますが、その解釈はアルゴリズムにより異なります。たとえば、DSA アルゴリズムのパラメータの場合、「サイズ」はプライムモジュラスのビット数のサイズに一致します。特定のアルゴリズムのサイズについては、付録 B の「アルゴリズム」を参照してください。この方法を使うと、アルゴリズム特定型のパラメータの生成値が (ある場合は)、デフォルト基準値になります。 普遍的に共有されるこれら 2 つの引数の型をとる init メソッドが 1 つあります。 

    void init(int size, SecureRandom random)
    また、size 引数だけをとり、システムが提供する乱数の発生源を使用する init メソッドもあります。 
    void init(int size)

    3 番目の方法では、パラメータジェネレータオブジェクトの初期化にアルゴリズム特定型のセマンティクスを使います。アルゴリズム特定型のセマンティクスは、AlgorithmParameterSpec オブジェクト内に提供されるアルゴリズム特定型のパラメータ生成値のセットによって表されます。 

    void init(AlgorithmParameterSpec genParamSpec,
SecureRandom random)

void init(AlgorithmParameterSpec genParamSpec)
    たとえば、Diffie-Hellman システムパラメータを生成するには、通常、パラメータ生成値は、プライムモジュラスおよびランダム指数のサイズで構成されます。どちらのサイズもビット数で指定します。Diffie-Hellman アルゴリズムは、JCE 1.2 から JCE の一部として提供されています。

    アルゴリズムパラメータの生成

    AlgorithmParameterGenerator オブジェクトを作成および初期化したら、generateParameters メソッドを使ってアルゴリズムパラメータを生成できます。 
    AlgorithmParameters generateParameters()

    Key インタフェース

    Key インタフェースは、すべての不透明な鍵に関するトップレベルのインタフェースです。すべての不透明な鍵オブジェクトが共有する機能を定義します。

    「不透明な」鍵の表現では、鍵を構成する鍵データに直接アクセスできません。つまり、「不透明」さにより、鍵へのアクセスが、Key インタフェースによって定義される getAlgorithm、getEncoded、および getFormat の 3 つのメソッドだけに制限されます。 これと対照的なのが「透明な」表現で、この場合は、対応する仕様クラス内に定義された get メソッドの 1 つを使って、各鍵データの値に個々にアクセスできます。

    不透明な鍵はすべて、次の 3 つの特性を持ちます。

    アルゴリズム
    鍵に対する鍵のアルゴリズムです。通常、鍵のアルゴリズムは、暗号化または非対称操作アルゴリズム (DSA や RSA など) で、これらのアルゴリズムや関連アルゴリズム (RSA を使う MD5、RSA を使う SHA-1 など) と連携して機能します。鍵のアルゴリズム名は、以下のメソッドを使って獲得します。 
    String getAlgorithm()
    コード化形式
    鍵の外部コード化形式は、鍵を別の組織に転送する場合など、鍵の標準表示が Java 仮想マシンの外部で必要なときに使います。鍵は標準形式 (X.509 や PKCS #8 など) に従ってコード化され、以下のメソッドを使って返されます。 

    byte[] getEncoded()
    フォーマット
    コード化した鍵のフォーマット名です。以下のメソッドから返されます。 
    String getFormat()
    鍵は一般的に、鍵ジェネレータ、証明書、鍵仕様 (KeyFactory を使用) または鍵管理で使うキーストアデータベースにアクセスする KeyStore の実装から獲得します。

    KeyFactory を使って、アルゴリズム依存型の方法で符号化された鍵を解析することが可能です。

    また、CertificateFactory を使って、証明書を解析することも可能です。

    次に、java.security.interfaces パッケージ内の Key インタフェースを拡張するインタフェースのリストを示します。

    PublicKey および PrivateKey インタフェース

    PublicKey および PrivateKey インタフェースはどちらも Key インタフェースを継承しますが、これらはメソッドを使わないインタフェースで、型の安全性および型の識別に使用します。

    鍵仕様のインタフェースおよびクラス

    鍵仕様は、鍵を構成する鍵データの透明な表現です。鍵がハードウェアデバイス上に格納されている場合は、その鍵仕様には、デバイス上の鍵の識別を助ける情報が含まれていることがあります。

    鍵の「透明な」表現とは、対応する仕様クラスで定義された get メソッドの 1 つを使って、各鍵データに個々にアクセスできるということです。たとえば、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.security.spec パッケージ内に含まれる鍵仕様のインタフェースおよびクラスについて説明します。

    KeySpec インタフェース

    このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべての鍵仕様をグループ化することおよびそれらのグループに安全な型を提供することです。すべての鍵仕様で、このインタフェースを実装する必要があります。

    DSAPrivateKeySpec クラス

    このクラス (KeySpec インタフェースを実装) は、関連付けられたパラメータを使って DSA 非公開鍵を指定します。DSAPrivateKeySpec クラスには、次のメソッドがあります。 
    BigInteger getX()
BigInteger getP()
BigInteger getQ()
BigInteger getG()
    これらのメソッドは、非公開鍵 x、および鍵の計算に使用される DSA アルゴリズムパラメータであるプライムの p、サブプライムの q、およびベースの g を返します。

    DSAPublicKeySpec クラス

    このクラス (KeySpec インタフェースを実装) は、関連付けられたパラメータを使って DSA 公開鍵を指定します。DSAPublicKeySpec クラスには、次のメソッドがあります。 
    BigInteger getY()
BigInteger getP()
BigInteger getQ()
BigInteger getG()
    これらのメソッドは、公開鍵 y、および鍵の計算に使用される DSA アルゴリズムパラメータであるプライムの p、サブプライムの q、およびベースの g を返します。

    RSAPrivateKeySpec クラス

    このクラス (KeySpec インタフェースを実装) は、RSA 非公開鍵を指定します。RSAPrivateKeySpec クラスには、次のメソッドがあります。 
    BigInteger getModulus()
BigInteger getPrivateExponent()
    これらのメソッドは、RSA 非公開鍵を構成する RSA モジュラス n および非公開指数 d の値を返します。

    RSAPrivateCrtKeySpec クラス

    このクラス (RSAPrivateKeySpec クラスを継承) は、PKCS #1 標準で定義されているように、中国剰余定理 (CRT) 情報の値を使って、RSA 非公開鍵を指定します。RSAPrivateCrtKeySpec クラスには、スーパークラスの RSAPrivateKeySpec から継承したメソッドのほかに、次のメソッドがあります。 
    BigInteger getPublicExponent()
BigInteger getPrimeP()
BigInteger getPrimeQ()
BigInteger getPrimeExponentP()
BigInteger getPrimeExponentQ()
BigInteger getCrtCoefficient()
    これらのメソッドは、公開指数 e および CRT 情報の整数を返します。CRT 情報の整数は、モジュラス n の素因数 p、n の素因数 q、指数 d mod (p-1)、指数 d mod (q-1)、および中国剰余定理係数 (q の逆数) mod p です。

    RSA 非公開鍵は、論理的にはモジュラスと非公開の指数だけで構成されます。CRT 値は、効率を向上させる目的で存在します。

    RSAMultiPrimePrivateCrtKeySpec クラス

    このクラス (RSAPrivateKeySpec クラスを継承) は、PKCS#1 v2.1 で定義されているように、中国剰余定理 (CRT) 情報の値を使って、RSA マルチプライム非公開鍵を指定します。 RSAMultiPrimePrivateCrtKeySpec クラスには、スーパークラスの RSAPrivateKeySpec から継承したメソッドのほかに、次のメソッドがあります。 
    BigInteger getPublicExponent()
BigInteger getPrimeP()
BigInteger getPrimeQ()
BigInteger getPrimeExponentP()
BigInteger getPrimeExponentQ()
BigInteger getCrtCoefficient()
RSAOtherPrimeInfo[] getOtherPrimeInfo()
    これらのメソッドは、公開指数 e および CRT 情報の整数を返します。CRT 情報の整数は、モジュラス n の素因数 p、n の素因数 q、指数 d mod (p-1)、指数 d mod (q-1)、および中国剰余定理係数 (q の逆数) mod p です。

    getOtherPrimeInfo メソッドは、otherPrimeInfo (PKCS#1 v 2.1 に定義されている) を返すか、または、素因数が 2 つ (p および q) しかない場合は、null を返します。

    RSA 非公開鍵は、論理的にはモジュラスと非公開の指数だけで構成されます。CRT 値は、効率を向上させる目的で存在します。

    RSAPublicKeySpec クラス

    このクラス (KeySpec インタフェースを実装) は、RSA 公開鍵を指定します。RSAPublicKeySpec クラスには、次のメソッドがあります。 
    BigInteger getModulus()
BigInteger getPublicExponent()
    これらのメソッドは、RSA 公開鍵を構成する RSA モジュラス n および公開指数 e の値を返します。

    EncodedKeySpec クラス

    この abstract クラス (KeySpec インタフェースを実装する) は、符号化された形式の公開鍵または非公開鍵を表します。その getEncoded メソッドは、次の符号化された鍵を返します。 
    abstract byte[] getEncoded();
    このクラスの getFormat メソッドは、次の符号化形式の名前を返します。 
    abstract String getFormat();

    具体的な実装 PKCS8EncodedKeySpec および X509EncodedKeySpec については、次の節を参照してください。

    PKCS8EncodedKeySpec クラス

    このクラスは、EncodedKeySpec のサブクラスで、PKCS #8 標準で指定された形式に従って、非公開鍵の DER 符号化を表現します。 このクラスの getEncoded メソッドは、PKCS #8 標準に従って符号化された鍵のバイトを返します。このクラスの getFormat メソッドは、文字列 PKCS#8 を返します。

    X509EncodedKeySpec クラス

    このクラスは、EncodedKeySpec のサブクラスで、X.509 標準で指定された形式に従って、公開鍵の DER 符号化を表現します。 このクラスの getEncoded メソッドは、X.509 標準に従って符号化された鍵のバイトを返します。このクラスの getFormat メソッドは、文字列 X.509 を返します。

    KeyFactory クラス

    KeyFactory クラスは、不透明な暗号化鍵 (Key 型) と、鍵仕様 (背後の鍵データの透明な表現) 間の変換を提供する目的で設計されたエンジンクラスです。

    鍵ファクトリは、双方向性があります。つまり、これによって、与えられた鍵仕様 (鍵のデータ) から不透明な鍵オブジェクトを構築することも、鍵オブジェクトの背後の鍵データを適切な形式で取得することもできます。

    同一の鍵に対して、複数の互換性のある鍵仕様を存在させることもできます。たとえば、DSA 公開鍵は、コンポーネント y、p、q、および g によって指定することも (DSAPublicKeySpec を参照)、X.509 標準に従って DER 符号化を使って指定することもできます (X509EncodedKeySpec を参照)。

    鍵ファクトリは、互換性のある鍵仕様間の変換に使用できます。互換性のある鍵仕様間の変換では、鍵の構文解析が行われます。たとえば、X509EncodedKeySpec を DSAPublicKeySpec に変換する場合は、基本的に符号化された鍵をコンポーネント単位で解釈処理します。例については、「鍵仕様および KeyFactory を使った署名の生成と検証」の最後を参照してください。

    KeyFactory オブジェクトの作成

    どのエンジンクラスの場合も同様に、KeyFactory クラスの static ファクトリメソッド getInstance を呼び出して、特定型の鍵アルゴリズムの KeyFactory オブジェクトを獲得します。 

    static KeyFactory getInstance(String algorithm)
    注: アルゴリズム名の大文字と小文字は区別されません。
    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求する鍵ファクトリの実装を確実に指定プロバイダから取得できます。 
    static KeyFactory getInstance(String algorithm, String provider)
static KeyFactory getInstance(String algorithm, Provider provider)

    鍵仕様と Key オブジェクト間の変換

    公開鍵用の鍵仕様がある場合は、generatePublic メソッドを使って、その仕様から不透明な PublicKey オブジェクトを取得できます。 

    PublicKey generatePublic(KeySpec keySpec)

    同様に、非公開鍵用の鍵仕様がある場合は、generatePrivate メソッドを使って、その仕様から不透明な PrivateKey オブジェクトを取得できます。 

    PrivateKey generatePrivate(KeySpec keySpec)

    Key オブジェクトと鍵仕様間の変換

    Key オブジェクトがある場合は、getKeySpec メソッドの呼び出しによって、対応する鍵仕様を取得できます。 

    KeySpec getKeySpec(Key key, Class keySpec)
    keySpec は、鍵のデータが返されるべき仕様クラスを識別します。たとえば、DSAPublicKeySpec.class は、鍵のデータが DSAPublicKeySpec クラスのインスタンスに返されるべきであることを指示します。

    詳細は、例を参照してください。

    CertificateFactory クラス

    CertificateFactory クラスは、証明書ファクトリの機能を定義するエンジンクラスです。証明書ファクトリは、証明書および証明書の取り消しリスト (CRL) オブジェクトをその符号化から生成するために使用されます。

    X.509 の証明書ファクトリは、java.security.cert.X509Certificate のインスタンスである証明書、および java.security.cert.X509CRL のインスタンスである CRL を返します。

    CertificateFactory オブジェクトの作成

    どのエンジンクラスの場合も同様に、CertificateFactory クラスの static ファクトリメソッド getInstance を呼び出して、特定型の証明書または CRL の CertificateFactory オブジェクトを獲得します。 

    static CertificateFactory getInstance(String type)
    注: 型の名前の大文字と小文字は区別されません。
    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求する証明書ファクトリの実装を確実に指定プロバイダから取得できます。 
    static CertificateFactory getInstance(String type, String provider)

static CertificateFactory getInstance(String type, Provider provider)

    証明書オブジェクトの生成

    証明書オブジェクトを生成し、入力ストリームから読み込まれたデータを使って初期化するには、generateCertificate メソッドを使います。 
    final Certificate generateCertificate(InputStream inStream)
    特定の入力ストリームから読み込まれた証明書のコレクションビュー (空の可能性もある) を返すには、generateCertificates メソッドを使います。 
    final Collection generateCertificates(InputStream inStream)

    CRL オブジェクトの生成

    (CRL) 証明書の取り消しリストオブジェクトを生成し、入力ストリームから読み込まれたデータを使って初期化するには、generateCRL メソッドを使います。 
    final CRL generateCRL(InputStream inStream)
    特定の入力ストリームから読み込まれた CRL のコレクションビュー (空の可能性もある) を返すには、generateCRLs メソッドを使います。 
    final Collection generateCRLs(InputStream inStream)

    CertPath オブジェクトの生成

    CertPath オブジェクトを生成し、そのオブジェクトを入力ストリームから読み込まれたデータを使って初期化するには、次のいずれかの generateCertPath メソッドを使用します (必要に応じて、データに対して使用するエンコーディングを指定する)。 
    final CertPath generateCertPath(InputStream inStream)

final CertPath generateCertPath(InputStream inStream,
String encoding)
    CertPath オブジェクトを生成し、証明書のリストを使用して初期化するには、次のメソッドを使用します。 
    final CertPath generateCertPath(List certificates)
    証明書ファクトリでサポートされている CertPath エンコーディングのリストを取得するには、getCertPathEncodings メソッドを呼び出します。 
    final Iterator getCertPathEncodings()
    初めにデフォルトのエンコーディングが一覧表示されます。

    KeyPair クラス

    KeyPair クラスは鍵のペア (公開鍵と非公開鍵) の簡単なホルダーです。これには 2 つの public メソッドがあります。1 つは非公開鍵を返し、もう 1 つは公開鍵を返します。 

    PrivateKey getPrivate()
PublicKey getPublic()

    KeyPairGenerator クラス

    KeyPairGenerator クラスはエンジンクラスで、公開鍵と非公開鍵のペアの生成に使います。

    鍵のペアの生成方法には、アルゴリズム独立型とアルゴリズム特定型の 2 つがあります。この 2 つの唯一の相違点は、オブジェクトの初期化にあります。

    以下のメソッドの呼び出し例は、例の項を参照してください。

    KeyPairGenerator の生成

    すべての鍵のペアは、まず最初に KeyPairGenerator を使って生成します。この生成は、KeyPairGenerator の以下のファクトリメソッドのどれか 1 つを使って実行します。 

    static KeyPairGenerator getInstance(String algorithm)
static KeyPairGenerator getInstance(String algorithm,
String provider)
static KeyPairGenerator getInstance(String algorithm,
Provider provider)
    注: アルゴリズム名の大文字と小文字は区別されません。

    KeyPairGenerator の初期化

    特定のアルゴリズム用の鍵のペアのジェネレータは、そのアルゴリズムで使うことができる公開鍵または非公開鍵を作成します。また、アルゴリズム特定型のパラメータを生成された各鍵に関連付けます。

    まず、鍵のペアを初期化してからでなければ、鍵のペアは鍵を生成できません。ほとんどの場合、アルゴリズム独立型の初期化で十分です。ただし、アルゴリズム特定型の初期化を使用する必要のある場合もあります。

    アルゴリズム独立型の初期化

    すべての鍵ジェネレータは、キーサイズおよび乱数の発生源の概念を共有します。キーサイズは、アルゴリズムごとに解釈が異なります。たとえば、DSA アルゴリズムの場合、キーサイズはモジュラスの長さと一致します。特定のアルゴリズムのキーサイズについては、「付録 B: アルゴリズム」を参照してください。

    普遍的に共有されるこれら 2 つの引数の型をとる initialize メソッドがあります。 

    void initialize(int keysize, SecureRandom random)
    また、keysize 引数だけをとり、システムが提供する乱数の発生源を使用する initialize メソッドもあります。 
    void initialize(int keysize)

    上のアルゴリズム独立型 initialize メソッドを呼び出すときは、その他のパラメータは指定しないため、各鍵に関連付けられるアルゴリズム特定型のパラメータがある場合は、そのパラメータの処理は、プロバイダによって異なります。

    アルゴリズムが DSA アルゴリズムで、モジュラスのサイズ (キーサイズ) が 512、768、または 1024 の場合は、SUN プロバイダは p、q、および g パラメータ用に事前に計算した値を使います。モジュラスのサイズが上記の値の 1 つでない場合は、SUN プロバイダは、新しいパラメータのセットを作成します。これらの 3 つのモジュラスサイズ以外の、事前に計算されたパラメータセットを持つプロバイダが存在する可能性もあります。また、事前に計算されたパラメータがなく、常に新しいパラメータセットを作成するプロバイダが存在する可能性もあります。

    アルゴリズム特定型の初期化

    アルゴリズム特定型パラメータのセットがすでに存在する状況では (DSA の「コミュニティパラメータ」など)、AlgorithmParameterSpec 引数をとる initialize メソッドが 2 つあります。このうちの一方は SecureRandom 引数もとりますが、他方では、乱数の発生源はシステムによって提供されます。 

    void initialize(AlgorithmParameterSpec params,
SecureRandom random)

void initialize(AlgorithmParameterSpec params)
    詳細は例の項を参照してください。

    鍵のペアの生成

    鍵のペアの生成手順は、初期化 (およびアルゴリズム) に関係なく、常に同じです。必ず KeyPairGenerator から以下のメソッドを呼び出します。 

    KeyPair generateKeyPair()
    generateKeyPair を呼び出すたびに、異なる鍵のペアが作られます。

    鍵管理

    「キーストア」と呼ばれるデータベースは、鍵および証明書のリポジトリを管理するために使用できます。「証明書」は、あるエンティティからのデジタルに署名された文で、別のあるエンティティの公開鍵に特定の値が含まれていることを示します。

    キーストアの場所

    キーストアは、デフォルトではユーザのホームディレクトリの .keystore という名前のファイルに格納されます。ユーザのホームディレクトリは、user.home システムプロパティによって決まります。Solaris システムの場合、user.home はデフォルトでユーザのホームディレクトリになっています。Win32 システムの場合、ユーザ名が「uName」の場合、user.home のデフォルトは次のように設定されます。

    • C:\Winnt\Profiles\uName - マルチユーザ Windows NT システムの場合
    • C:\Windows\Profiles\uName - マルチユーザ Windows 95/98/2000 システムの場合
    • C:\Windows - シングルユーザ Windows 95/98/2000 システムの場合

    キーストアの実装

    KeyStore クラスは、キーストア内の情報へのアクセスおよび情報の変更を行うための、明確に定義されたインタフェースを提供します。キーストアの固定実装としては、それぞれが特定の「タイプ」のキーストアを対象とする複数の異なる実装が存在可能です。

    キーストアを利用するコマンド行ツールには、keytool と jarsigner の 2 つがあります。 また、GUI ベースの policytool というツールもあります。さまざまなソースのコードに対して (システムリソースへの) アクセス権を指定するポリシーファイルを処理する場合、このツールは Policy のリファレンス実装によっても使われます。KeyStore は public として使用可能なので、SDK ユーザは KeyStore を使ったほかのセキュリティアプリケーションも作成できます。

    キーストアには、Sun が提供する組み込みのデフォルトの実装があります。これは、JKS という名前の独自のキーストアタイプ (形式) を利用するもので、キーストアをファイルとして実装しています。この実装では、個々の非公開鍵は個別のパスワードによって保護され、キーストア全体の完全性も (非公開鍵とは別の) パスワードによって保護されます。

    キーストアの実装は、プロバイダベースです。具体的には、KeyStore が提供するアプリケーションインタフェースは、Service Provider Interface (SPI) という形で実装されています。つまり、対応する KeystoreSpi 抽象クラス (これも java.security パッケージに含まれている) があり、このクラスが SPI のメソッドを定義しています。これらのメソッドは、「プロバイダ」が実装しなければなりません。「プロバイダ」とは、Java 2 SDK Security API によってアクセス可能なサービスのサブセットの固定実装を提供するパッケージまたはパッケージのセットのことです。したがって、キーストアの実装を提供するには、「Java(TM) 暗号化アーキテクチャ用プロバイダの実装方法」で説明しているように、クライアントが「プロバイダ」を実装し、KeystoreSpi サブクラスの実装を提供する必要があります。

    アプリケーションでは、KeyStore クラスの getInstance ファクトリメソッドを使うことで、さまざまなプロバイダから異なる「タイプ」のキーストアの実装を選択できます。キーストアのタイプは、キーストア情報の格納形式とデータ形式を定義するとともに、キーストア内の非公開鍵とキーストア自体の完全性を保護するために使われるアルゴリズムを定義します。異なるタイプのキーストアの実装には、互換性はありません。

    キーストアのデフォルトタイプは、SUN プロバイダによって提供されるキーストア実装専用の jks です。これは、セキュリティプロパティファイル内の次の行によって指定されています。 

    keystore.type=jks
    ツールおよびほかのアプリケーションでデフォルト以外のキーストア実装を利用するには、この行を変更して別のタイプのキーストアを指定します。また、作成するツールおよびアプリケーションのユーザにキーストアのタイプを指定させて、その値をキーストアの getInstance メソッドに渡すという方法もあります。

    最初の方法の例を次に示します。pkcs12 というタイプのキーストア実装を提供するプロバイダパッケージがある場合は、この行を次のように変更します。 

    keystore.type=pkcs12
    注: キーストアのタイプの指定では、大文字と小文字は区別されません。たとえば、JKS と jks は同じものとして扱われます。

    KeyStore クラス

    KeyStore クラスは、キーストア内の情報へのアクセスおよび情報の変更を行うための明確に定義されたインタフェースを提供するエンジンクラスです。

    このクラスは、メモリ内の鍵および証明書のコレクションを表すもので、次の 2 種類のエントリを管理します。

    鍵エントリ

    このタイプのキーストアエントリには、非常に重要な暗号化鍵の情報が保持されます。情報は、保護された形式で格納され、権限のないアクセスを防ぎます。通常、この種類のエントリで格納される鍵は非公開鍵で、対応する公開鍵を証明する証明連鎖が伴います。

    非公開鍵および証明連鎖は、デジタル署名を使った自己認証用に特定のエンティティが使用します。たとえば、ソフトウェア配布団体は、リリースまたはライセンスするソフトウェアの一部として JAR ファイルにデジタル署名を付けます。

    信頼できる証明書エントリ

    この種類のエントリには、別の組織に属する単一の公開鍵が含まれ、「信頼できる証明書」と呼ばれます。これは、キーストアの所有者が、証明書内の公開鍵が実際に証明書の「被認証者」(所有者) によって識別されたアイデンティティに属することを信頼するためです。

    この種類のエントリは、ほかの組織の認証に使うことができます。

    キーストア内の各エントリは、「別名」文字列によって識別されます。非公開鍵とそれに関連付けられた証明連鎖の場合は、これらの文字列は、エンティティ自体が認証するというように、方法別に区別されます。たとえば、エンティティが異なる証明書発行局を使ったり、異なる公開鍵アルゴリズムを使ったりして、エンティティ自体を認証することも可能です。

    キーストアが持続性があるかどうか、および持続性がある場合に使われる機構は、ここでは指定されません。この規則により、重要な (秘密または非公開) 鍵を保護するためのさまざまな技術を使うことができます。スマートカードまたはその他の統合暗号化エンジン (SafeKeyper) を使うことも 1 つの方法です。また、ファイルなどのより単純な機構をさまざまな形式で使うこともできます。

    主要な KeyStore メソッドを以下で説明します。

    KeyStore オブジェクトの作成

    ほかのエンジンクラスと同様に、KeyStore オブジェクトを取得するには、KeyStore クラスの getInstance static ファクトリメソッドを呼び出します。 

    static KeyStore getInstance(String type)

    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求するタイプの実装を確実に指定プロバイダから取得できます。 

    static KeyStore getInstance(String type, String provider)
static KeyStore getInstance(String type, Provider provider)

    特定キーストアのメモリへのロード

    KeyStore オブジェクトを使う前に、load メソッドによってメモリ内に実際のキーストアデータをロードする必要があります。 
    final void load(InputStream stream, char[] password)
    オプションのパスワードを使って、キーストアデータの整合性をチェックします。パスワードが提供されない場合は、整合性のチェックは行われません。

    空のキーストアを作成するには、InputStream 引数として null を load メソッドに渡します。

    キーストアの別名一覧の取得

    キーストアエントリには、すべて一意の「別名」 (aliases) からアクセスします。aliases メソッドは、キーストア内の別名の列挙を返します。 

    final Enumeration aliases()

    キーストアエントリの種類の決定

    「キーストアクラス」で説明したように、キーストアのエントリには、2 種類あります。

    次のメソッドは、与えられた別名によって指定されたエントリが、それぞれ鍵または証明書か、信頼できる証明書エントリであることを決定します。 

    final boolean isKeyEntry(String alias)
final boolean isCertificateEntry(String alias)

    キーストアエントリの追加、設定、および削除

    setCertificateEntry メソッドは、証明書を指定された別名に割り当てます。 
    final void setCertificateEntry(String alias, Certificate cert)
    alias が存在しない場合は、その別名のついた信頼できる証明書のエントリが作成されます。alias が存在し、信頼できる証明書のエントリが識別された場合は、それに関連付けられた証明書が cert によって置き換えられます。

    setKeyEntry メソッドは、alias がまだ存在しない場合に、鍵のエントリの追加または設定を行います。 

    final void setKeyEntry(String alias,
Key key,
char[] password,
Certificate[] chain)

final void setKeyEntry(String alias,
byte[] key,
Certificate[] chain)
    バイト配列として key を取るメソッドでは、この引数は、保護された形式の鍵のバイトです。たとえば、Sun プロバイダによって提供されるキーストアの実装では、key バイト配列は、PKCS #8 標準の定義に従って EncryptedPrivateKeyInfo として符号化された、保護された非公開鍵を格納します。もう一方のメソッドの password は、鍵の保護に使うパスワードです。

    deleteEntry メソッドは、エントリを削除します。 

    final void deleteEntry(String alias)

    キーストアからの情報の取得

    getKey メソッドは、与えられた別名に関連付けられた鍵を返します。鍵は、与えられたパスワードを使って復元されます。 
    final Key getKey(String alias, char[] password)
    次のメソッドは、与えられた別名に関連付けられた証明書、または証明連鎖をそれぞれ返します。 
    final Certificate getCertificate(String alias)
final Certificate[] getCertificateChain(String alias)
    次の文を使って、与えられた証明書と一致した最初のエントリの名前 (別名) を決定できます。 
    final String getCertificateAlias(Certificate cert)

    キーストアの保存

    メモリ内のキーストアを、store メソッドを使って保存できます。 
    final void store(OutputStream stream, char[] password)
    パスワードは、キーストアデータの統合チェックサムの計算に使われます。統合チェックサムは、キーストアデータのあとに追加されます。

    SecureRandom クラス

    SecureRandom クラスは、乱数ジェネレータの機能を提供するエンジンクラスです。

    SecureRandom オブジェクトの作成

    ほかのエンジンクラスと同様に、SecureRandom オブジェクトを取得するには、SecureRandom クラスの getInstance static ファクトリメソッドを呼び出します。 

    static SecureRandom getInstance(String algorithm)

    呼び出し側は、任意でプロバイダまたは Provider クラスの名前を指定できます。プロバイダ名を指定すると、要求する乱数生成 (RNG) アルゴリズムの実装を確実に指定プロバイダから取得できます。 

    static final SecureRandom getInstance(String algorithm,
String provider)
static final SecureRandom getInstance(String algorithm,
Provider provider)

    SecureRandom オブジェクトのシードまたは再シード

    呼び出し側が、setSeed メソッドの 1 つへの呼び出しで、getInstance メソッドへの呼び出しに従う場合以外は、SecureRandom の実装は、ジェネレータの内部状態自体を完全にランダム化しようとします。 

    synchronized public void setSeed(byte[] seed)
public void setSeed(long seed)
    SecureRandom オブジェクトに一度シードが入れられると、これはオリジナルのシードと同じようにランダムにビットを生成します。

    SecureRandom オブジェクトは、setSeed メソッドの 1 つを使って常に再シードされる可能性があります。指定されたシードは、既存のシードと置き換えられるのではなく、既存のシードに追加されます。したがって、呼び出しを繰り返しても、ランダム性が減少しないことが保証されます。

    SecureRandom オブジェクトの使い方

    ランダムバイトを得るには、呼び出し側は単純に任意の長さの配列を渡します。すると、この配列にランダムバイトが入ります。 

    synchronized public void nextBytes(byte[] bytes)

    シードバイトの生成

    ほかの乱数ジェネレータにシードを入れる場合など、必要な場合は、generateSeed メソッドを呼び出して、与えられた数のシードバイトを生成できます。 
    byte[] generateSeed(int numBytes)