Java プラットフォームは、言語の安全性、暗号化、公開鍵インフラストラクチャー、認証、安全な通信、アクセス制御など、セキュリティーに重点を置いています。
JCA はプラットフォームの主要な部分であり、「プロバイダ」アーキテクチャー、デジタル署名、メッセージダイジェスト (ハッシュ)、証明書と証明書検証、暗号化 (対称/非対称ブロック/ストリーム暗号)、鍵の生成と管理、安全な乱数生成などのための一連の API が含まれています。これらの API によって、開発者はアプリケーションコードにセキュリティーを簡単に統合できます。アーキテクチャーは、次の方針に基づいて設計されました。
- 実装の独立性
- アプリケーションでセキュリティーアルゴリズムを実装する必要はありません。Java プラットフォームからセキュリティーサービスを要求できます。セキュリティーサービスはプロバイダ (下記を参照) に実装されています。プロバイダは、標準インタフェースによって Java プラットフォームにプラグインされます。アプリケーションのセキュリティー機能は、複数の独立したプロバイダに依存している場合があります。
- 実装の相互運用性
- プロバイダは、アプリケーション間で相互運用できます。具体的には、アプリケーションは特定のプロバイダにバインドされず、プロバイダは特定のアプリケーションにバインドされません。
- アルゴリズムの拡張性
- Java プラットフォームには、現在広く使用されている基本的なセキュリティーサービスを実装する多数の組み込みプロバイダが含まれています。ただし、一部のアプリケーションは、まだ実装されていない普及しつつある規格や独自のサービスに依存している場合があります。Java プラットフォームは、そのようなサービスを実装するカスタムプロバイダのインストールをサポートしています。
JDK で使用できるその他の暗号化通信ライブラリは JCA プロバイダアーキテクチャーを使用しますが、これらについては別途説明します。JavaTM Secure Socket Extension (JSSE) は、Secure Socket Layer (SSL) および Transport Layer Security (TLS) の実装へのアクセスを提供します。通信しているアプリケーション間で安全にメッセージを交換するために、Java Generic Security Services (JGSS) (Kerberos による) API、および Simple Authentication and Security Layer (SASL) を使用することもできます。
警告:JCA を使用すると、アプリケーションへのセキュリティー機能の組み込みが簡単になります。ただし、このドキュメントでは、API の説明に必要な概念の基本的な紹介以外、セキュリティー/暗号化の理論については説明しません。このドキュメントでは、特定のアルゴリズムの長所と弱点やプロトコルの設計についても説明しません。暗号化は高度なトピックであり、これらのツールを最適に使用するには、信頼できる、可能なかぎり最近のリファレンスを参照するようにしてください。
実行している内容とその理由を常に理解している必要があります。ランダムコードを単純にコピーし、それが用途を満たす筋書きを完全に解決してくれるとは考えないでください。間違ったツールまたはアルゴリズムが選択されたため、セキュリティーまたはパフォーマンスに重大な問題があるアプリケーションが数多く配備されています。
JCA は、次の方針に基づいて設計されました。
- 実装の独立性と相互操作性
- アルゴリズムの独立性と拡張性
実装の独立性とアルゴリズムの独立性は相補関係にあります。そのため、デジタル署名やメッセージダイジェストなどの暗号化サービスを、実装の詳細やこれらの概念の基になるアルゴリズムを意識しないで使用できます。完全なアルゴリズムの独立性は不可能ですが、JCA は標準化された、アルゴリズム依存の API を提供します。実装の独立性が望ましくない場合、JCA では、開発者が特定の実装を指定できます。
アルゴリズムの独立性は、暗号化「エンジン」(サービス) の型を定義し、これらの暗号化エンジンの機能を提供するクラスを定義することにより実現しています。これらのクラスは「エンジンクラス」と呼ばれ、MessageDigest クラス、Signature クラス、KeyFactory クラス、KeyPairGenerator クラス、および Cipher クラスがこれに含まれます。
実装の独立性は、「プロバイダ」ベースのアーキテクチャーを使って実現されます。暗号化サービスプロバイダ (CSP) (このドキュメントでは「プロバイダ」とも呼ばれる) とは、デジタル署名アルゴリズム、メッセージダイジェスト、鍵の変換サービスなどの 1 つ以上の暗号化を実行するパッケージやパッケージセットを意味します。プログラムは単に、特定のサービス (たとえば DSA 署名アルゴリズム) を実行する特定型のオブジェクト (たとえば Signature オブジェクト) を要求するだけで、インストールされているプロバイダの 1 つから実装を獲得できます。必要に応じて、プログラムは特定プロバイダから実装を要求することもできます。たとえば、より高速で安全性の高いバージョンが利用できるときは、プロバイダをアプリケーションに対して透過的に更新することができます。
実装の相互操作性とは、さまざまな実装が互いに機能でき、互いの鍵を使ったり、互いの署名を検証できることを意味します。つまり、1 つのプロバイダが生成した同じアルゴリズムや鍵を別のプロバイダが使ったり、あるプロバイダが生成した署名を別のプロバイダが検証するということです。
アルゴリズムの拡張性とは、サポートされるエンジンクラスの 1 つに当てはまる新規アルゴリズムを容易に追加できることを意味します。
java.security.Provider は、すべてのセキュリティープロバイダの基底クラスです。各 CSP はこのクラスのインスタンスを含みます。インスタンスはプロバイダの名前を含み、実装するセキュリティーサービス/アルゴリズムをすべて一覧表示します。特定のアルゴリズムのインスタンスが必要な場合、JCA フレームワークはプロバイダのデータベースに問い合わせ、一致するものが見つかった場合はそのインスタンスが作成されます。
プロバイダは、公開されている暗号化アルゴリズムの固定実装を提供するパッケージ (または、パッケージのセット) を含みます。各 JDK のインストールでは、1 つ以上のプロバイダがインストールされ、デフォルトで構成されます。追加プロバイダは静的または動的に追加できます (Provider クラスと Security クラスを参照)。クライアントは実行環境を構成し、プロバイダの「優先順位」を指定できます。優先順位とは、特定プロバイダの指定がない場合に、要求されたサービスに関して検索されるプロバイダの順位です。
JCA を使用するには、アプリケーションは特定のオブジェクトの型 (たとえば MessageDigest) と特定のアルゴリズムまたはサービス (たとえば「MD5」アルゴリズム) を要求し、インストールされているプロバイダのうちの 1 つから実装を獲得します。あるいは、特定プロバイダのオブジェクトを要求することもできます各プロバイダは、それぞれの参照名を持ちます。
md = MessageDigest.getInstance("MD5");
md = MessageDigest.getInstance("MD5", "ProviderC");
次の図は、「MD5」メッセージダイジェスト実装の要求を示しています。この図は、さまざまなメッセージダイジェストアルゴリズム (「SHA-1」、「MD5」、「SHA-256」、および「SHA-256」) を実装する 3 つの異なるプロバイダを示しています。プロバイダは、左から右への優先順位 (1～3) で並べられています。最初の図では、アプリケーションはプロバイダ名を指定せずに MD5 アルゴリズム実装を要求しています。プロバイダが優先順位に従って検索され、そのアルゴリズムを提供する最初のプロバイダ ProviderB から実装が返されます。2 番目の図では、アプリケーションは特定のプロバイダ ProviderC から MD5 アルゴリズム実装を要求しています。この場合は、優先順位の高いプロバイダ ProviderB も MD5 実装を提供しますが、ProviderC から実装が返されます。
Sun JDK での暗号化実装は、さまざまなプロバイダ (Sun、SunJSSE、SunJCE、SunRsaSign) によって配布されます。これは主に歴史的な理由によりますが、それらが提供する機能およびアルゴリズムのタイプによるところもあります。その他の Java 実行環境は、必ずしもこれらの Sun プロバイダを含みません。したがって、特定のプロバイダが使用可能になることがわかっている場合を除き、アプリケーションはプロバイダ固有の実装を要求しないようにする必要があります。
JCA には、インストールされているプロバイダおよびそれらがサポートするサービスについて、ユーザーが問い合わせることができる API セットがあります。
このアーキテクチャーを使用すると、エンドユーザーがプロバイダを追加することも簡単になります。多くのサードパーティーのプロバイダ実装がすでに使用可能です。プロバイダの記述、インストール、および登録の方法の詳細は、「Provider クラス」を参照してください。
プロバイダの実際の実装方法
前述のように、アルゴリズムの独立性は、サービスタイプにアクセスするためにすべてのアプリケーションが使用する汎用で高レベルの Application Programming Interface (API) を定義することによって実現されます。実装の独立性は、すべてのプロバイダ実装を、明確に定義されたインタフェースに準拠させることによって実現されます。したがって、エンジンクラスのインスタンスは、同じメソッドシグニチャーを持つ実装クラスに基づいています。アプリケーション呼び出しはエンジンクラスによって渡され、基盤となる実装に伝送されます。実装は要求を処理し、正しい結果を返します。
各エンジンクラス内のアプリケーション API メソッドは、対応する Service Provider Interface (SPI) を実装するクラスによってプロバイダの実装に渡されます。つまり、各エンジンクラスに対応する抽象 SPI クラスが存在し、この抽象 SPI クラスによって各暗号化サービスプロバイダのアルゴリズムが実装する必要があるメソッドが定義されます。SPI クラスの名前は、対応するエンジンクラス名のあとに Spi を追加した名前になります。たとえば Signature エンジンクラスは、デジタル署名アルゴリズムの機能へのアクセスを提供します。実際のプロバイダ実装は、SignatureSpi のサブクラス内で提供されます。アプリケーションは各エンジンクラスの API メソッドを呼び出し、API メソッドは実際の実装内の SPI メソッドを呼び出します。
各 SPI クラスは、抽象クラスです。指定したアルゴリズムに対する特定の型のサービスの実装を提供するには、プロバイダは、対応する SPI クラスをサブクラス化して、すべての抽象メソッドの実装を提供する必要があります。
API の各エンジンクラスについては、エンジンクラス特有の getInstance()「ファクトリメソッド」を呼び出すことによって実装インスタンスが要求され、インスタンスが生成されます。ファクトリメソッドは、クラスのインスタンスを返す static メソッドです。エンジンクラスは、前述のフレームワークプロバイダ選択機構を使用して実際の基盤となる実装 (SPI) を取得し、実際のエンジンオブジェクトを作成します。エンジンクラスの各インスタンスは、SPI オブジェクトと呼ばれる対応する SPI クラスのインスタンスを、private フィールドとしてカプセル化します。API オブジェクトのすべての API メソッドは、final として宣言し、それらを実装することによって、カプセル化される SPI オブジェクトの対応する SPI メソッドが呼び出されます。
これを明確にするために、次のコードと図を確認してください。
import javax.crypto.*;
Cipher c = Cipher.getInstance("AES");
c.init(ENCRYPT_MODE, key);
ここで、アプリケーションは「AES」javax.crypto.Cipher インスタンスを必要とし、使用するプロバイダは問題となりません。アプリケーションは Cipher エンジンクラスの getInstance() ファクトリメソッドを呼び出し、ファクトリメソッドは JCA フレームワークに「AES」をサポートする最初のプロバイダインスタンスを見つけることを要求します。フレームワークはインストールされている各プロバイダに問い合わせ、Provider クラスのプロバイダのインスタンスを取得します。Provider クラスは、使用可能なアルゴリズムのデータベースです。フレームワークは各プロバイダを検索し、最終的に CSP3 で適切なエントリを見つけます。このデータベースエントリは、CipherSpi を拡張する実装クラス com.foo.AESCipher を指定し、したがって Cipher エンジンクラスによる使用に適しています。com.foo.AESCipher のインスタンスが作成され、javax.crypto.Cipher の新しく作成されるインスタンスにカプセル化されます。新しく作成されるインスタンスがアプリケーションに返されます。アプリケーションが Cipher インスタンス上で init() オペレーションを実行すると、Cipher エンジンクラスはその要求を com.foo.AESCipher クラス内の対応する engineInit() バッキングメソッドに渡します。
「付録 A」には、Java 環境に対して定義されている標準名が一覧表示されています。ほかのサードパーティープロバイダが、これらのサービスまたは追加サービスの独自の実装を定義している場合があります。
鍵管理
「キーストア」と呼ばれるデータベースは、鍵および証明書のリポジトリを管理するために使用できます。キーストアは、認証、暗号化、または署名の目的でデータが必要なアプリケーションで利用できます。
アプリケーションは、KeyStore クラスの実装を経由してキーストアにアクセスできます。キーストアクラスの実装は、java.security パッケージ内にあります。デフォルトのキーストアの実装は、米国 Sun Microsystems, Inc によって提供されます。これは、「jks」という名前の独自のキーストアタイプ (形式) を使用するもので、キーストアをファイルとして実装しています。その他のキーストア形式も使用できます。「jks」よりも大幅に強力な暗号化を備えた独自の代替キーストア形式である「jceks」やRSA PKCS12 Personal Information Exchange Syntax Standard に基づいた「pkcs12」などです。
アプリケーションは、前述の同じプロバイダ機構を使用して、異なるプロバイダから異なるキーストア実装を選択できます。
詳細は、「鍵管理」の項を参照してください。
この項では、主要な JCA API について説明します。
エンジンクラスは、特定の暗号化アルゴリズムまたはプロバイダに依存しない、特定の型の暗号化サービスへのインタフェースを提供します。エンジンは、次のいずれかを提供します。
- 暗号化操作 (暗号化、デジタル署名、メッセージダイジェストなど)
- 暗号化データ (鍵およびアルゴリズムパラメータ) のジェネレータまたはコンバータ
- 暗号化データをカプセル化し、上位の抽象レイヤーで使用できるオブジェクト (キーストアまたは証明書)
次のエンジンクラスが使用可能です。
注: 「ジェネレータ (generator)」は、最新の内容でオブジェクトを作成しますが、「ファクトリ (factory)」は既存の構成要素 (符号化法など) からオブジェクトを作成します。
この項では、JCA で提供するコアクラスとインタフェースについて説明します。
このガイドでは、もっとも有用な高レベルのクラスについて最初に説明し (Provider、Security、SecureRandom、MessageDigest、Signature、Cipher、および Mac)、次にさまざまなサポートクラスについて説明します。現時点では、鍵 (公開、非公開、および秘密) はさまざまな JCA クラスによって生成および表現され、高レベルのクラスによってその操作の一部として使用されるという説明だけで十分です。
この項では、各クラスおよびインタフェースのメインメソッドの署名を示します。該当する例の項には、クラス (MessageDigest、Signature、KeyPairGenerator、SecureRandom、KeyFactory、および鍵仕様クラス) の例があります。
関連する Security API パッケージの完全なリファレンスドキュメントは、次のパッケージの概要にあります。
「暗号化サービスプロバイダ」(このドキュメントでは「プロバイダ」とも呼ばれる) とは、JDK Security API の暗号化機能のサブセットの固定実装を提供するパッケージまたはパッケージセットです。Provider クラスは、このようなパッケージやパッケージセットへのインタフェースです。プロバイダ名、バージョン番号、その他の情報にアクセスするためのメソッドを備えています。Provider クラスを使用すると、暗号化サービスの実装を登録するだけでなく、その他のセキュリティーサービスの実装を登録することもできます。その他のセキュリティーサービスは、JDK Security API またはその拡張機能の 1 つの一部として定義されている場合があります。
暗号化サービスの実装を提供するには、エンティティー (開発グループなど) は実装コードを作成し、Provider クラスのサブクラスを生成します。Provider サブクラスのコンストラクタは、プロバイダが実装したサービスを検索するために JDK Security API が使用する各種プロパティーの値を設定します。つまり、サブクラスは、サービスを実装するクラス名を指定します。
プロバイダパッケージが実装できるサービスには、さまざまな種類があります。詳細については、「エンジンクラスとアルゴリズム」を参照してください。
実装が違うと、特徴も違ってくる場合があります。ソフトウェアベースのものもあれば、ハードウェアベースのものもあります。プラットフォーム独立のものもあれば、プラットフォーム固有のものもあります。また、レビューや評価用に使えるプロバイダコードもあれば、使えないものもあります。JCA では、エンドユーザーと開発者の双方が独自のニーズを決定できます。
この項では、エンドユーザーのための暗号実装のインストール方法とニーズへの合わせ方、および開発者のための必要な実装の要求方法を説明します。
注:プロバイダの実装の詳細は、「Java 暗号化アーキテクチャー用プロバイダの実装方法」を参照してください。
この API の各エンジンクラスについては、実装インスタンスが要求され、そのエンジンクラスの getInstance メソッドの 1 つを呼び出してインスタンスが生成されます。このときに、希望するアルゴリズムの名前と実装するプロバイダ (または Provider クラス) の名前 (オプション) を指定します。
static EngineClassName getInstance(String algorithm)
throws NoSuchAlgorithmException
static EngineClassName getInstance(String algorithm, String provider)
throws NoSuchAlgorithmException, NoSuchProviderException
static EngineClassName getInstance(String algorithm, Provider provider)
throws NoSuchAlgorithmException
EngineClassName は、必要なエンジンタイプ (MessageDigest/Cipher/その他) です。例を示します。
MessageDigest md = MessageDigest.getInstance("MD5");
KeyAgreement ka = KeyAgreement.getInstance("DH", "SunJCE");
それぞれ、「MD5」MessageDigest および「DH」KeyAgreement オブジェクトのインスタンスを返します。
「付録 A」には、Java 環境での使用について標準化されている名前のリストがあります。一部のプロバイダには、同じアルゴリズムを参照する別名がある場合もあります。たとえば、「SHA-1」アルゴリズムが「SHA1」として参照される場合があります。必ずしもすべてのプロバイダが同じようにアルゴリズム名の別名を持つわけではないため、アプリケーションは別名ではなく標準名を使用する必要があります。
注:アルゴリズム名の大文字と小文字は区別されません。たとえば、次の呼び出しはすべて等価とみなされます。
MessageDigest.getInstance("SHA-1")
MessageDigest.getInstance("sha-1")
MessageDigest.getInstance("sHa-1")
プロバイダを指定しない場合、getInstance は、指定されたアルゴリズムに関連する、要求された暗号化サービスの実装に対応する登録プロバイダを検索します。どの Java 仮想マシン (JVM) でも、プロバイダは指定の「優先順位」でインストールされます。優先順位とは、特定プロバイダの指定がない場合に、プロバイダリストが検索される順位です。たとえば、JVM に、PROVIDER_1 と PROVIDER_2という 2 つのプロバイダがインストールされ、次のようになっていると仮定します。
PROVIDER_1 は SHA1withDSA、SHA-1、MD5、DES、DES3 を実装
PROVIDER_1 の優先順位が 1 (最高の優先順位)
PROVIDER_2 は SHA1withDSA、MD5withRSA、MD2withRSA、MD2、MD5、RC4、RC5、DES、RSA を実装
PROVIDER_2 の優先順位は 2
ここで、3 つのシナリオについて見てみます。
- MD5 実装を検索するとする。どちらのプロバイダもこの実装を供給する。
PROVIDER_1 が最高の優先順位を持ち最初に検索されるので、PROVIDER_1 実装が返される
- MD5withRSA 署名アルゴリズムを検索する場合、まず最初に
PROVIDER_1 が検索される。実装が見つからないので次に PROVIDER_2 が検索される。実装が見つかるので、このプロバイダが返される
-
SHA1withRSA 署名アルゴリズムを検索する場合を想定する。これを実装するプロバイダはインストールされていないので、
NoSuchAlgorithmException がスローされる
プロバイダ引数を持つ getInstance メソッドは、必要なアルゴリズムを提供するプロバイダを指定したい開発者のためのものです。たとえば、連邦証明書を受け取ったプロバイダ実装を連邦局が使いたいとします。PROVIDER_1 の SHA1withDSA 実装はこの証明書を受け取っていないのに対し、PROVIDER_2 の DSA 実装がこれを受け取っていると仮定します。
連邦局のプログラムは以下の呼び出しを実行します。PROVIDER_2 が認証された実装を持つため、これを指定します。
Signature dsa = Signature.getInstance("SHA1withDSA", "PROVIDER_2");
この場合、PROVIDER_2 がインストールされていないと、インストールされている別のプロバイダが要求アルゴリズムを実装している場合であっても、NoSuchProviderException がスローされます。
プログラムは、(Security クラスの getProviders メソッドを使用して) インストールされているプロバイダのリストを獲得し、リストから選択することもできます。
注:
汎用アプリケーションは、特定のプロバイダから暗号化サービスを要求しないようにする必要があります。要求を行うと、アプリケーションはほかの Java 実装で使用できない可能性がある特定のプロバイダに結び付けられます。特定の要求されたプロバイダよりも優先順位が高い、使用可能な最適化されたプロバイダ (たとえば、PKCS11 によるハードウェアアクセラレータまたは Microsoft の MSCAPI などのネイティブ OS 実装) を利用できない場合もあります。
暗号化プロバイダを使用するには、最初にインストールし、次に静的または動的に登録します。さまざまな Sun プロバイダがこのリリースに同梱されており (SUN、SunJCE、SunJSSE、SunRsaSign など)、すでにインストールおよび登録されています。以降の項では、追加プロバイダのインストールおよび登録方法について説明します。
プロバイダクラスのインストール
プロバイダクラスのインストールには、次の 2 つの方法があります。
- 通常の Java classpath
クラスが格納されている zip または JAR ファイルを、classpath の任意の場所に置く。一部のアルゴリズムタイプ (暗号) では、プロバイダは署名された JAR ファイルである必要があります。
- インストール/バンドルされた拡張機能
プロバイダは、標準の拡張機能ディレクトリに配置された場合、「インストール型」拡張機能と見なされます。Sun の JDK では、次の場所に配置されます。
<java-home>/lib/ext [Unix]
<java-home>\lib\ext [Windows]
ここで、<java-home> は、ランタイムソフトウェアのインストール先ディレクトリ (JavaTM Runtime Environment (JRE) のトップレベルディレクトリまたは JavaTM JDK ソフトウェアの jre ディレクトリ) を指します。たとえば、JDK 6 を /home/user1/JDK1.6.0 ディレクトリ (Solaris)、または C:\Java\JDK1.6.0 ディレクトリ (Microsoft Windows) にインストールした場合、JAR ファイルを次のディレクトリにインストールする必要があります。
/home/user1/JDK1.6.0/jre/lib/ext [Unix]
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 [Unix]
C:\jre1.6.0\lib\ext [Windows]
拡張機能の配置方法の詳細は、「拡張機能の配置」を参照してください。
プロバイダの登録
次の手順では、登録済みプロバイダのリストにプロバイダを追加します。プロバイダは、Java アプリケーションを実行する前にセキュリティープロパティー構成ファイルを編集して静的に登録するか、または実行時にメソッドを呼び出して動的に登録できます。破壊行為を行うプロバイダのインストールが実行環境に追加されるのを防ぐために、プロバイダを動的に登録しようとするアプリケーションは適切な実行特権を保持している必要があります。
静的登録
構成ファイルは、次のディレクトリに格納されています。
<java-home>/lib/security/java.security [Unix]
<java-home>\lib\security\java.security [Windows]
登録されたプロバイダごとに、このファイルは次の形式の文を保持します。
security.provider.n=masterClassName
これはプロバイダを宣言し、その優先順位 n を指定します。優先順位とは、特定プロバイダの指定がない場合に、要求されたサービスに関して検索されるプロバイダの順位です。順位は 1 から始まります。1 が最優先で次に 2、3 ...と続きます。
masterClassName には、プロバイダの「マスタークラス」を完全修飾名で指定します。プロバイダのドキュメントでそのマスタークラスを指定します。このクラスは、常に Provider クラスのサブクラスです。サブクラスコンストラクタは、プロバイダが実装したアルゴリズムやその他の機能を検索するために Java 暗号化 API に必要な各種プロパティーの値を設定します。
JDK には、「SUN」や「SunJCE」など、標準で自動的にインストールおよび構成されるプロバイダが付随します。「SUN」プロバイダのマスタークラスは、sun.security.provider パッケージ内の SUN クラスです。対応する java.security ファイルエントリは、次のとおりです。
security.provider.5=sun.security.provider.Sun
別の JCA プロバイダを利用する場合、代替プロバイダを参照する行を追加し、優先順位を指定します。必要に応じてほかのプロバイダの順序も調整します。
CompanyX のプロバイダのマスタークラスが com.companyx.provider.ProviderX で、このプロバイダを優先順位が第 8 位のプロバイダとして構成するとします。このためには、次の行を java.security ファイルに追加します。
security.provider.8=com.companyx.provider.ProviderX
動的登録
プロバイダを動的に登録するには、アプリケーションは Security クラスの addProvider または insertProviderAt のどちらかのメソッドを呼び出します。この登録は VM インスタンス間で持続的ではなく、適切な特権を持つ「信頼できる」プログラムでしか実行できません。Security クラスを参照してください。
暗号化プロバイダが使用され (つまり、Cipher、KeyAgreement、KeyGenerator、Mac、または SecretKeyFactory の実装を提供するプロバイダ)、プロバイダがインストール済み拡張機能ではない場合、JCA を使用するアプレットまたはアプリケーションをセキュリティーマネージャーがインストールされている環境で実行するときはアクセス権を付与する必要がある場合があります。通常、アプレットの実行時にはセキュリティーマネージャーが常にインストールされます。アプリケーションの場合でも、アプリケーション自体のコード内またはコマンド行引数で指定することにより、セキュリティーマネージャーをインストールできます。デフォルトシステムのポリシー構成ファイルは、インストール型拡張機能 (つまり、拡張機能ディレクトリにインストールされている) にすべてのアクセス権を付与するため、インストール型拡張機能にアクセス権を設定する必要はありません。
ベンダーの提供する各プロバイダ用ドキュメントには、必須のアクセス権やそれを付与する方法が記載されています。たとえば、拡張機能がインストール型ではなく、セキュリティーマネージャーがインストールされている場合、プロバイダに次のアクセス権を付与する必要があります。
-
java.lang.RuntimePermission "getProtectionDomain" (クラス保護ドメインを取得するため)。プロバイダは、自己整合性チェックの実行過程で、独自の保護ドメインの取得が必要になる場合があります。
java.security.SecurityPermission "putProviderProperty.{name}" (プロバイダプロパティーを設定するため、{name} には実際のプロバイダ名を指定)
たとえば、名前が「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";
};
Provider クラスのメソッド
各 Provider クラスインタフェースは、名前 (現時点では大文字小文字を区別する)、バージョン番号、およびプロバイダとそのサービスの文字列記述を持ちます。以下のメソッドを呼び出して、これらの情報について Provider のインスタンスを照会できます。
public String getName()
public double getVersion()
public String getInfo()
Security クラスは、インストールされているプロバイダおよびセキュリティーに関するプロパティーを管理します。このクラスに含まれるのは、インスタンスが生成されない static メソッドだけです。
プロバイダの追加または削除、および Security プロパティーの設定用メソッドは、信頼できるプログラムによってしか実行できません。現時点での「信頼できるプログラム」は、以下のどれかです。
- セキュリティーマネージャーの下で動作していないローカルアプリケーション
- 指定されたメソッドを実行する権限のあるアプレットまたはアプリケーション (以下を参照)
あるコードが、実行しようとしているアクション (プロバイダの追加など) を行うことができるような、信頼できるコードであると判断するには、そのアクションを行う適切な権限がそのアプレットに与えられている必要があります。インストールした JDK のポリシー構成ファイルでは、指定されたコードソースからのコードに対し、どのようなアクセス権 (システムリソースへのアクセスの種類) を与えるかを指定します。詳細は、以降の説明および「デフォルトの 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.*";
};
この例では、コードソースを指定する要素がどちらも省略されています。したがって、出所がどこか、署名が付いているか、誰の署名が付いているかに関係なく、どのコードでもプロバイダの追加と削除が行えます。この付与はセキュリティーホールを作り出す可能性があるため、絶対にお勧めしません。信頼されていないコードによってプロバイダがインストールされるため、適切に機能する実装に依存する後続のコードに影響する可能性があります。たとえば、破壊行為を行う Cipher オブジェクトが、受信した機密情報を取り込んで格納する場合があります。
プロバイダの管理
次の表に、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 クラスは、システムに関するセキュリティーのプロパティーリストを保持します。これらのプロパティーは System プロパティーに似ていますが、セキュリティー関連です。これらのプロパティーは、静的にも動的にも設定できます。静的セキュリティープロパティーの例 ("security.provider.i" セキュリティープロパティーによるプロバイダの静的な登録) についてはすでに説明しました。プロパティーを動的に設定する場合、信頼できるプログラムは次のメソッドを使用できます。
static String getProperty(String key)
static void setProperty(String key, String datum)
注:セキュリティープロバイダのリストは、VM の起動中に確立されます。したがって、前述のメソッドは、プロバイダリストを変更する場合に使用してください。
構成ファイルは、次のディレクトリに格納されています。
<java-home>/lib/security/java.security [Unix]
<java-home>\lib\security\java.security [Windows]
SecureRandom クラスは、乱数ジェネレータ (RNG) の機能を提供するエンジンクラスです。強力な暗号化による乱数を生成する点が Random クラスとは異なります。ジェネレータのランダム性が不十分な場合、保護機構が簡単に脅かされることになります。暗号化鍵の生成やアルゴリズムのパラメータなど、乱数は暗号化全体で使用されます。
SecureRandom オブジェクトの作成
ほかのエンジンクラスと同様に、SecureRandom オブジェクトを取得するには、SecureRandom クラスの getInstance() static ファクトリメソッドの 1 つを呼び出します。
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)
MessageDigest クラスはエンジンクラスで、安全な暗号化メッセージダイジェスト (SHA-1 や MD5 など) の機能を提供するように設計されています。安全な暗号化メッセージダイジェストは、任意サイズの入力 (バイト配列) を取り、固定サイズ出力を生成します。これを「ダイジェスト」または「ハッシュ」と言います。
たとえば、MD5 のアルゴリズムは 16 バイトのダイジェストを生成し、SHA1 のアルゴリズムは 20 バイトのダイジェストを生成します。
ダイジェストには次の 2 つの特徴があります。
- 計算によって、同じ値にハッシュされた 2 つのメッセージを検索できない
- ダイジェストの生成に使った入力情報を明らかにしない
メッセージダイジェストを使い、一意で、信頼できるデータ識別子を生成します。データ識別子をデータの「チェックサム」または「デジタル指紋」と呼ぶこともあります。メッセージのうちの 1 ビットを変更するだけで、異なるダイジェスト値が生成されます。
メッセージダイジェストには多くの用途があり、意図的かどうかにかかわらず、いつデータが変更されたかを判断できます。近年、一般的なアルゴリズムに弱点があるかどうかを判断するために大きな努力が払われていますが、結果はさまざまです。ダイジェストアルゴリズムを選択する場合は、最近のリファレンスを調べて、その状況と当面のタスクでの妥当性を判断する必要があります。
MessageDigest オブジェクトの生成
ダイジェスト計算では、まず最初にメッセージダイジェストのインスタンスを生成します。MessageDigest オブジェクトは、MessageDigest クラスの getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。ファクトリメソッドは、初期化されたメッセージダイジェストオブジェクトを返します。したがって、このあとで初期化を行う必要はありません。
メッセージダイジェストオブジェクトのアップデート
データのダイジェストを計算するための次の手順は、初期化したメッセージダイジェストオブジェクトにデータを入れることです。すべてを一度に、またはチャンクで入れることができます。次のいずれかの 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 番目のメソッドは、ダイジェストのバイト配列を返す digest() を呼び出す前に、入力バイトの配列で最後の update(input) を行います。最後のメソッドは、オフセット位置 offset から開始する提供バッファー buf 内に算出ダイジェストを格納します。len は、ダイジェストに割り当てられた buf 内のバイト数です。このメソッドは、実際に buf 内に格納されたバイト数を返します。バッファー内に十分な領域がない場合、メソッドは例外をスローします。
詳細は、「コード例」の項の MessageDigest の計算の例を参照してください。
Signature クラスはエンジンクラスであり、DSA や RSAwithMD5 などの暗号化デジタル署名機能を提供するように設計されています。安全な暗号化署名アルゴリズムは、任意サイズの入力と非公開鍵を取り、「署名」と呼ばれる比較的短い (固定サイズの場合もよくある) バイト文字列を生成します。このプロパティーは次のとおりです。
- 公開鍵と非公開鍵のペアの所有者のみが署名を作成できます。計算によって、公開鍵を保持する人が非公開鍵を回復することはできません。
- 署名の生成に使う非公開鍵に対応する公開鍵が与えられる。これは入力の認証性および整合性を検証できる
- 署名および公開鍵は、非公開鍵に関する情報を明らかにはしない
また、指定の署名が、関連データの実際の認証署名かどうかを検証することもできます。
Signature オブジェクトは、非公開鍵での署名に対して初期化され、署名するデータを与えられます。結果の署名バイトは、通常は署名されたデータとともに保持されます。検証が必要な場合、別の Signature オブジェクトが作成され、検証に対して初期化されて対応する公開鍵を与えられます。データおよび署名バイトは signature (署名) オブジェクトに渡され、データと署名が一致した場合に、Signature オブジェクトは成功を報告します。
署名はメッセージダイジェストに似ていますが、提供する保護の種類の点で目的が大きく異なっています。実際、「SHA1WithRSA」などのアルゴリズムは、メッセージダイジェスト「SHA1」を使用して最初に大きなデータセットを管理しやすい形式に「圧縮」し、次に「RSA」アルゴリズムで結果の 20 バイトのメッセージダイジェストに署名します。
データの署名および検証の例は、例の項を参照してください。
Signature オブジェクトの状態
Signature オブジェクトはモデルオブジェクトです。つまり、Signature オブジェクトは、常に指定の状態にあり、この状態で 1 つの型のオペレーションだけを実行できます。状態は、個々のクラスで定義した final (ファイナル) 整数の定数で表されます。
Signature オブジェクトに可能な状態は、次の 3 つです。
UNINITIALIZED
SIGN
VERIFY
Signature オブジェクトが初めて生成されるときは、UNINITIALIZED の状態です。Signature クラスは、状態を SIGN に変更する initSign と、状態を VERIFY に変更する initVerify の 2 つの初期化メソッドを定義します。
Signature オブジェクトの生成
署名を付けたり、検証したりするには、最初に Signature のインスタンスを生成します。Signature オブジェクトは、Signature getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
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 符号化の使用方法については、標準名のドキュメントを参照してください。
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 への新規呼び出しを作成したりできます。
Cipher クラスは、暗号化および暗号解読で使用される暗号機能を提供します。暗号化とは、データ (「クリアテキスト」と呼ばれる) および「キー」を受け取って、鍵を知らないサードパーティーにとって無意味なデータ (「暗号テキスト」) を生成する処理のことです。復号化はその逆で、暗号テキストおよび鍵を受け取り、クリアテキストを生成する処理です。
対称暗号化方式と非対称暗号方式
暗号化には、対称 (秘密鍵とも呼ばれる) と非対称 (または公開鍵暗号方式) という 2 つの主要なタイプがあります。対称暗号化方式では、同じ秘密鍵がデータの暗号化と復号化の両方を行います。データの機密性を保持するには、鍵を非公開にすることが重要となります。一方、非対称暗号方式は、公開鍵と非公開鍵のペアを使用してデータを暗号化します。一方の鍵で暗号化されたデータは、他方の鍵で復号化されます。ユーザーは最初に公開鍵と非公開鍵のペアを生成し、誰でもアクセスできる信頼できるデータベースに公開鍵を発行します。そのユーザーと安全に通信することを希望するユーザーは、取得した公開鍵を使用してデータを暗号化します。非公開鍵の保有者のみが復号化できます。この方式では、非公開鍵を機密にすることが重要となります。
RSA などの非対称アルゴリズムは、通常、対称アルゴリズムよりも大幅に遅くなります。これらのアルゴリズムは、大量データを効率的に保護するように設計されていません。実際には、非対称アルゴリズムは、対称アルゴリズムを初期化するために使用される少量の秘密鍵を交換する場合に使用されます。
ストリーム暗号とブロック暗号
ブロックとストリームという 2 つの主要な暗号タイプがあります。ブロック暗号は、ブロック全体を一度に処理します。通常は長いバイト長になります。完全な入力ブロックを作成するのにデータが不足する場合は、データのパディングが必要です。つまり、暗号化の前に、ダミーバイトを追加して暗号のブロックサイズの倍数にします。これらのバイトは、復号化の段階で削除されます。パディングは、アプリケーションか、または「PKCS5PADDING」などのパディングタイプを使用するように暗号を初期化することによって実行できます。これに対して、ストリーム暗号は入力データを一度に 1 つの小さい単位 (通常はバイト、またはビットの場合もある) で処理します。これにより、暗号は任意の量のデータをパディングを行わずに処理できます。
操作モード
単純なブロック暗号を使用して暗号化する場合、2 つの同じプレーンテキストのブロックは、常に同じ暗号テキストのブロックを生成します。暗号テキストを破ろうとする暗号解読者が繰り返しのテキストのブロックに気付くと、簡単に解読されてしまいます。テキストに複雑さを加えるために、フィードバックモードは、暗号化アルゴリズムを適用する前に、以前の出力ブロックを使用して入力ブロックを変更します。最初のブロックには初期値が必要です。この値は、初期化ベクトル (IV) と呼ばれます。IV は暗号化の前に単純にデータを変更するため、IV はランダムである必要がありますが、必ずしも秘密である必要はありません。CBC (Cipher Block Chaining)、CFB (Cipher Feedback Mode)、OFB (Output Feedback Mode) など、さまざまなモードがあります。ECB (Electronic Cookbook Mode) は、フィードバックのないモードです。
AES や RSA などの一部のアルゴリズムでは異なる長さの鍵が可能ですが、それ以外 (DES や 3DES など) は固定です。長い鍵を使用する暗号化は、一般にメッセージ復元に対して抵抗力が強いことを意味します。いつものように、セキュリティーと時間という相反するものの間で折り合いを付けるため、適切な鍵の長さを選択します。
ほとんどのアルゴリズムは、バイナリ鍵を使用します。ほとんどの人は、16 進数で表現されていても、長いバイナリの数値を記憶できません。文字のパスワードのほうが記憶するのは簡単です。通常、文字のパスワードは少数の文字 ([a-zA-Z0-9] など) から選択されるため、「パスワードベースの暗号化」(PBE) などのプロトコルは、文字のパスワードを取得して強力なバイナリ鍵を生成するように定義されています。パスワードから暗号化鍵を取得しようとする攻撃者のタスク (一般の辞書の「単語->値」のマッピングが事前に計算されている、いわゆる「ディクショナリ攻撃」による) を非常に時間のかかるものにするために、大半の PBE 実装では、鍵のランダム性を高めるために乱数への混入 (salt と呼ばれる) が行われます。
Cipher オブジェクトの作成
Cipher オブジェクトは、Cipher getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。ここでのアルゴリズム名は、アルゴリズム名だけでなく「変換」を指定する点で、ほかのエンジンクラスの場合と少し異なります。変換は、指定された入力に対して実行し、何らかの出力を生成する操作 (または操作のセット) を説明する文字列です。変換には、暗号化アルゴリズム (DES など) の名前が必ず含まれます。それにモードおよびパディング方式が続く場合もあります。 変換は、次の書式で記述されます。
- "algorithm/mode/padding" または
- "algorithm"
たとえば、以下は有効な変換です。
"DES/CBC/PKCS5Padding"
"DES"
変換名だけを指定すると、要求された変換の実装がその環境で使用可能かどうかをシステムが判別し、複数の実装が存在する場合には優先度の高い実装が存在することを返します。
変換名とパッケージプロバイダの両方を指定すると、システムは要求されたパッケージ内に要求された変換の実装が存在するかどうかを確認し、存在しない場合には例外をスローします。
モードやパディングを指定しない場合、モードおよびパディング方式のプロバイダ固有のデフォルト値が使用されます。たとえば、SunJCE プロバイダは、DES、DES-EDE、および Blowfish 暗号のデフォルトモードとして ECB を、デフォルトパディング方式として PKCS5Padding を使用します。このため、SunJCE プロバイダでは、
Cipher c1 = Cipher.getInstance("DES/ECB/PKCS5Padding");
および
Cipher c1 = Cipher.getInstance("DES");
の 2 つの文は、等価になります。
CFB や OFB などのモードを使用すると、ブロック暗号は暗号の実際のブロックサイズよりも小さい単位でデータを暗号化できます。このようなモードを要求する場合、「DES/CFB8/NoPadding」および「DES/OFB32/PKCS5Padding」変換に示されるように、この数値をモード名に追加することにより、一度に処理するビット数をオプションで指定できます。数値を指定しない場合、プロバイダ固有のデフォルトが使用されますたとえば、SunJCE プロバイダではデフォルトの 64 ビットが DES で使用されます。したがって、ブロック暗号は、CFB8 や OFB8 などの 8 ビットモードを使用して、バイト指向のストリーム暗号に変換できます。
このドキュメントの「付録 A」には、変換のアルゴリズム名、モード、およびパディング方式コンポーネントの指定に使用可能な標準名のリストが掲載されています。
ファクトリメソッドにより返されるオブジェクトは初期化されていないため、使用する前に初期化する必要があります。
getInstance を介して取得された Cipher オブジェクトは、次の 4 つのモードのいずれかで初期化する必要があります。これらのモードは、Cipher クラスの final (ファイナル) 整数の定数として定義されます。モードは、シンボル名で参照できます。次に、各モードのシンボル名および目的を示します。
- ENCRYPT_MODE
- データの暗号化
- DECRYPT_MODE
- データの暗号解読
- WRAP_MODE
- 安全に転送するために
java.security.Key をラッピングする
- UNWRAP_MODE
- ラッピングされた鍵を
java.security.Key オブジェクトにアンラッピングする
Cipher 初期化メソッドは、それぞれ操作モードパラメータ (opmode) を取り、そのモード用の Cipher オブジェクトを初期化します。他のパラメータには、鍵 (key) または鍵を含む証明書 (certificate)、アルゴリズムパラメータ (params)、および乱数の発生源 (random) が含まれます。
Cipher オブジェクトを初期化する場合、次のいずれかの init メソッドを呼び出します。
public void init(int opmode, Key key);
public void init(int opmode, Certificate certificate);
public void init(int opmode, Key key, SecureRandom random);
public void init(int opmode, Certificate certificate,
SecureRandom random);
public void init(int opmode, Key key,
AlgorithmParameterSpec params);
public void init(int opmode, Key key,
AlgorithmParameterSpec params, SecureRandom random);
public void init(int opmode, Key key,
AlgorithmParameters params);
public void init(int opmode, Key key,
AlgorithmParameters params, SecureRandom random);
初期化ベクトルなどのパラメータを必要とする Cipher オブジェクトを暗号化用に初期化する場合、init メソッドにパラメータを何も指定しないと、ランダムパラメータを生成するか、プロバイダ固有のパラメータセット (デフォルト) を使用することにより、基盤となる暗号実装が必須パラメータを提供すると見なされます。
ただし、パラメータを必要とする Cipher オブジェクトを暗号解読用に初期化する場合、init メソッドにパラメータを何も指定しないと、使用した init メソッドに応じて InvalidKeyException または InvalidAlgorithmParameterException 例外が発生します。
詳細は、「アルゴリズムパラメータの管理」に関するセクションを参照してください。
暗号解読には、暗号化に使用したのと同じパラメータを使用する必要があります。
Cipher オブジェクトを初期化すると、それまでに獲得した状態がすべて失われることに留意してください。つまり、Cipher を初期化することは、その Cipher の新規インスタンスを作成して初期化することと等価です。たとえば、指定された鍵で暗号解読を行うために Cipher を初期化してから、暗号化を行うために初期化すると、暗号解読モードで獲得した状態はすべて失われます。
データの暗号化または暗号解読は、1 つのステップで実行 (「単一部分操作」) することも 、複数のステップで実行 (「複数部分操作」) することもできます。データの長さが不明な場合、またはデータが長すぎて一度にメモリに格納できない場合に、複数部分操作は有用です。
単独のステップでデータの暗号化または暗号解読を行う場合、次のいずれかの doFinal メソッドを呼び出します。
public byte[] doFinal(byte[] input);
public byte[] doFinal(byte[] input, int inputOffset, int inputLen);
public int doFinal(byte[] input, int inputOffset,
int inputLen, byte[] output);
public int doFinal(byte[] input, int inputOffset,
int inputLen, byte[] output, int outputOffset)
複数のステップでデータの暗号化または暗号解読を行うには、次のいずれかの update メソッドを呼び出します。
public byte[] update(byte[] input);
public byte[] update(byte[] input, int inputOffset, int inputLen);
public int update(byte[] input, int inputOffset, int inputLen,
byte[] output);
public int update(byte[] input, int inputOffset, int inputLen,
byte[] output, int outputOffset)
複数部分操作は、上記の doFinal メソッドのいずれか (最後のステップで入力データが残される場合)、または次の doFinal メソッドのいずれか (最後のステップで入力データが残らない場合) を使って終了させます。
public byte[] doFinal();
public int doFinal(byte[] output, int outputOffset);
指定された変換の一部としてパディング (またはアンパディング) が要求された場合、すべての doFinal メソッドで、必要なパディング (またはアンパディング) 操作がすべて処理されます。
doFinal を呼び出すと、Cipher オブジェクトは init を呼び出して初期化した時の状態にリセットされます。つまり、Cipher はリセットされて、データをさらに暗号化または暗号解読 (init の呼び出しで指定された操作モードに基づく) できるようになります。
鍵をラッピングすると、ある場所から別の場所へ安全に転送できます。
wrap/unwrap API は鍵オブジェクトに対して直接機能するため、この API を使用するとコードの記述が容易になります。次のメソッドを使用すると、ハードウェアベースの鍵の安全な転送も可能になります。
Key を wrap する場合、まず WRAP_MODE の Cipher オブジェクトを初期化し、次のメソッドを呼び出します。
public final byte[] wrap(Key key);
ラップされた鍵のバイト (wrap を呼び出した結果) を、そのラップを解除する他のユーザーに提供する場合、受信者が unwrap を実行するのに必要な、次の追加情報も送信する必要があります。
- 鍵アルゴリズムの名前
- ラップされた鍵の型 (
Cipher.SECRET_KEY、Cipher.PRIVATE_KEY、または Cipher.PUBLIC_KEY のいずれか)
鍵アルゴリズム名は、次に示すように Key インタフェースから getAlgorithm メソッドを呼び出すことにより確認できます。
public String getAlgorithm();
wrap への呼び出しにより返されたバイトのラップを解除するには、UNWRAP_MODE の Cipher オブジェクトを初期化してから、以下を呼び出します。
public final Key unwrap(byte[] wrappedKey,
String wrappedKeyAlgorithm,
int wrappedKeyType));
ここで、wrappedKey はラップへの呼び出しにより返されたバイトを、wrappedKeyAlgorithm はラップされた鍵に関連付けられたアルゴリズムを、wrappedKeyType はラップされた鍵の型をそれぞれ指します。これは、Cipher.SECRET_KEY、Cipher.PRIVATE_KEY、または Cipher.PUBLIC_KEY のいずれかでなければなりません。
基盤となる Cipher 実装により使用されるパラメータ (アプリケーションにより init メソッドに明示的に渡されたか、基盤となる実装自体により生成された) は、getParameters メソッドを呼び出すことにより Cipher オブジェクトから取得できます。このメソッドは、パラメータを java.security.AlgorithmParameters オブジェクト (パラメータが使用されない場合は null) として返します。パラメータが初期化ベクトル (IV) の場合、getIV メソッドを呼び出すことによりパラメータを取得できます。
次の例では、パスワードベース暗号化 (PBE) を実装する Cipher オブジェクトを、パラメータを使用せずに鍵のみを使用して初期化します。ただし、選択されたパスワードベース暗号化用に選択されたアルゴリズムは、salt および iteration count という 2 つのパラメータを必要とします。これらは、基盤となるアルゴリズム実装自体により生成されます。アプリケーションは、生成されたパラメータを以下の方法で Cipher オブジェクトから取得できます。
import javax.crypto.*;
import java.security.AlgorithmParameters;
// get cipher object for password-based encryption
Cipher c = Cipher.getInstance("PBEWithMD5AndDES");
// initialize cipher for encryption, without supplying
// any parameters. Here, "myKey" is assumed to refer
// to an already-generated key.
c.init(Cipher.ENCRYPT_MODE, myKey);
// encrypt some data and store away ciphertext
// for later decryption
byte[] cipherText = c.doFinal("This is just an example".getBytes());
// retrieve parameters generated by underlying cipher
// implementation
AlgorithmParameters algParams = c.getParameters();
// get parameter encoding and store it away
byte[] encodedAlgParams = algParams.getEncoded();
暗号解読には、暗号化に使用したのと同じパラメータを使用する必要があります。これらは、エンコーディングからインスタンス化することが可能であり、次に示すように、対応する Cipher オブジェクトを暗号解読用に初期化する際に使用できます。
import javax.crypto.*;
import java.security.AlgorithmParameters;
// get parameter object for password-based encryption
AlgorithmParameters algParams;
algParams = AlgorithmParameters.getInstance("PBEWithMD5AndDES");
// initialize with parameter encoding from above
algParams.init(encodedAlgParams);
// get cipher object for password-based encryption
Cipher c = Cipher.getInstance("PBEWithMD5AndDES");
// initialize cipher for decryption, using one of the
// init() methods that takes an AlgorithmParameters
// object, and pass it the algParams object from above
c.init(Cipher.DECRYPT_MODE, myKey, algParams);
Cipher オブジェクトの初期化時にパラメータを一切指定せず、基盤となる実装がいずれかのパラメータを使用するかどうか不明な場合、Cipher オブジェクトの getParameters メソッドを呼び出して、返される値をチェックするだけで確認できます。戻り値が null の場合、パラメータが使用されなかったことを示します。
SunJCE プロバイダにより実装される次の暗号アルゴリズムは、パラメータを使用します。
- DES、DES-EDE、および Blowfish は、フィードバック (つまり CBC、CFB、OFB、または PCBC) モードでの使用時に、初期化ベクトル (IV) を使用します。
javax.crypto.spec.IvParameterSpec クラスは、指定された IV での Cipher オブジェクトの初期化に使用できます。
- PBEWithMD5AndDES は、salt および iteration count で構成されるパラメータセットを使用します。
javax.crypto.spec.PBEParameterSpec クラスは、指定された salt および iteration count を使って PBEWithMD5AndDES を実装する Cipher オブジェクトを初期化する場合に使用できます。
SealedObject クラスを使用する場合、暗号解読操作に使用するアルゴリズムパラメータの格納または転送について心配する必要はありません。このクラスは、シール (暗号化) に使用されるパラメータを暗号化されたオブジェクトコンテンツに添付します。また、アンシール (暗号解読) でも同じパラメータを使用します。
暗号出力時の考慮事項
Cipher の update および doFinal の中には、呼び出し側による出力バッファーの指定が可能なものがあります。暗号化または暗号解読されたデータは、このバッファー内に出力されます。この場合、暗号化または暗号解読操作の結果を保持できるだけの大きさのバッファーを渡すことは重要です。
Cipher 内の次のメソッドを使用して、設定すべき出力バッファーのサイズを確認できます。
public int getOutputSize(int inputLen)
Cipher を内部的に使用して共通の暗号使用への簡単なアクセスを提供する、いくつかのヘルパークラスがあります。
既存の InputStream/OutputStream と Cipher オブジェクトを結合することによって、単純で安全なストリームベースの通信オブジェクトを作成できます。
このクラスは、通過するデータの暗号化または暗号解読を行う FilterInputStream です。これは、InputStream またはそのサブクラスのいずれか、および Cipher で構成されます。CipherInputStream は、Cipher オブジェクトの挿入先の、セキュリティー保護された入力ストリームを表します。CipherInputStream の read メソッドは、基盤となる InputStream から読み取られ、埋め込まれた Cipher オブジェクトによりさらに処理されたデータを返します。Cipher オブジェクトは、CipherInputStream で使用する前に完全に初期化する必要があります。
たとえば、埋め込まれた Cipher が暗号解読用に初期化されている場合、CipherInputStream は基盤となる InputStream から読み込んだデータの暗号解読を試みてから、データをアプリケーションに返します。
このクラスは、上位クラス java.io.FilterInputStream および java.io.InputStream のセマンティクス (特にエラーに関するセマンティクス) に厳密に準拠します。このクラスは、上位クラスで指定されたメソッドを正確に保持し、それらすべてをオーバーライドします。このため、埋め込まれた暗号によるデータの追加処理が可能になります。さらに、このクラスは、上位クラスがスローしない例外をすべてキャッチします。特に、skip(long) メソッドは、Cipher により処理されたデータだけを無視します。
このクラスを使用するプログラマにとって、このクラスが定義またはオーバーライドされていないメソッド (上位クラスのいずれかにあとで追加された新規メソッドまたはコンストラクタ) を使用しないようにすることは重要です。これらのメソッド実装は、CipherInputStream へのセキュリティー面の影響を考慮に入れていないためです。
使用方法の一例として、cipher1 が暗号化用に初期化されている場合を考えてみましょう。以下のコードは、暗号および FileInputStream を含む CipherInputStream を使用して、入力ストリームデータを暗号化する方法を示します。
FileInputStream fis;
FileOutputStream fos;
CipherInputStream cis;
fis = new FileInputStream("/tmp/a.txt");
cis = new CipherInputStream(fis, cipher1);
fos = new FileOutputStream("/tmp/b.txt");
byte[] b = new byte[8];
int i = cis.read(b);
while (i != -1) {
fos.write(b, 0, i);
i = cis.read(b);
}
fos.close();
上記のプログラムは、ファイル /tmp/a.txt からコンテンツを読み取って暗号化し、結果 (暗号化されたバイト) を /tmp/b.txt に格納します。
次の例は、CipherInputStream および FileInputStream の複数インスタンスを簡単に接続する方法を示します。この例では、cipher1 および cipher2 が、それぞれ暗号化および暗号解読用に (対応する鍵を使用して) 初期化されているものとします。
FileInputStream fis;
FileOutputStream fos;
CipherInputStream cis1, cis2;
fis = new FileInputStream("/tmp/a.txt");
cis1 = new CipherInputStream(fis, cipher1);
cis2 = new CipherInputStream(cis1, cipher2);
fos = new FileOutputStream("/tmp/b.txt");
byte[] b = new byte[8];
int i = cis2.read(b);
while (i != -1) {
fos.write(b, 0, i);
i = cis2.read(b);
}
fos.close();
上記のプログラムは、ファイル /tmp/a.txt の内容を /tmp/b.txt にコピーします。ただし、/tmp/a.txt からの読み取り時に、最初に内容の暗号化、次に暗号解読が行われます。実際のところ、このプログラムはテキストを暗号化した後、すぐに暗号解読を行うため、CipherInputStreams のチェーンをわかりやすく示す以外は特に有用なものではありません。
CipherInputStream の読み取りメソッドは、基盤となる暗号からデータが返されるまでブロックします。ブロック暗号が使用される場合、基盤となる InputStream から暗号テキストの完全なブロックが取得される必要があります。
このクラスは、通過するデータの暗号化または暗号解読を行う FilterOutputStream です。これは、OutputStream またはそのサブクラスのいずれか、および Cipher で構成されます。CipherOutputStream は、Cipher オブジェクトの挿入先の、セキュリティー保護された出力ストリームを表します。CipherOutputStream の write メソッドは、埋め込まれた Cipher オブジェクトを使ってデータを処理してから、基盤となる OutputStream にデータを書き出します。Cipher オブジェクトは、CipherOutputStream で使用する前に完全に初期化する必要があります。
たとえば、埋め込まれた Cipher が暗号化用に初期化されている場合、CipherOutputStream はデータを暗号化してから、基盤となる出力ストリームに書き出します。
このクラスは、上位クラス java.io.OutputStream および java.io.FilterOutputStream のセマンティクス (特にエラーに関するセマンティクス) に厳密に準拠します。このクラスは、上位クラスで指定されたメソッドを正確に保持し、それらすべてをオーバーライドします。このため、埋め込まれた暗号によるすべてのデータの追加処理が可能になります。さらに、このクラスは、上位クラスがスローしない例外をすべてキャッチします。
このクラスを使用するプログラマにとって、このクラスが定義またはオーバーライドされていないメソッド (上位クラスのいずれかにあとで追加された新規メソッドまたはコンストラクタ) を使用しないようにすることは重要です。これらのメソッド実装は、CipherOutputStream へのセキュリティー面の影響を考慮に入れていないためです。
使用方法の一例として、cipher1 が暗号化用に初期化されている場合を考えてみましょう。以下のコードは、暗号および FileOutputStream を含む CipherOutputStream を使用して、暗号化されたデータを出力ストリームに書き出す方法を示します。
FileInputStream fis;
FileOutputStream fos;
CipherOutputStream cos;
fis = new FileInputStream("/tmp/a.txt");
fos = new FileOutputStream("/tmp/b.txt");
cos = new CipherOutputStream(fos, cipher1);
byte[] b = new byte[8];
int i = fis.read(b);
while (i != -1) {
cos.write(b, 0, i);
i = fis.read(b);
}
cos.flush();
上記のプログラムは、ファイル /tmp/a.txt からコンテンツを読み取って暗号化し、結果 (暗号化されたバイト) を /tmp/b.txt に格納します。
次の例は、CipherOutputStream および FileOutputStream の複数インスタンスを簡単に接続する方法を示します。この例では、cipher1 および cipher2 が、それぞれ暗号解読および暗号化用に (対応する鍵を使用して) 初期化されているものとします。
FileInputStream fis;
FileOutputStream fos;
CipherOutputStream cos1, cos2;
fis = new FileInputStream("/tmp/a.txt");
fos = new FileOutputStream("/tmp/b.txt");
cos1 = new CipherOutputStream(fos, cipher1);
cos2 = new CipherOutputStream(cos1, cipher2);
byte[] b = new byte[8];
int i = fis.read(b);
while (i != -1) {
cos2.write(b, 0, i);
i = fis.read(b);
}
cos2.flush();
上記のプログラムは、ファイル /tmp/a.txt の内容を /tmp/b.txt にコピーします。ただし、/tmp/b.txt に書き込む前に、内容の暗号化および暗号解読が行われます。
ブロック暗号アルゴリズムを使用する場合は、データが暗号化されて基盤となる出力ストリームに送信される前に、プレーンテキストデータの完全なブロックを CipherOutputStream に与える必要があります。
このクラスの flush と close メソッドには、ほかに 1 つの重要な相違点があります。カプセル化された Cipher オブジェクトがパディングを有効にしてブロック暗号アルゴリズムを実装する場合、この相違点に特に留意する必要があります。
flush は、カプセル化された Cipher オブジェクトにより処理済みのバッファリングされた出力バイトをすべて強制的に書き出すことにより、基盤となる OutputStream をフラッシュします。カプセル化された Cipher オブジェクトによりバッファリングされ、処理待ち状態にあるバイトは、書き出されません。 close は、基盤となる OutputStream を閉じて、関連付けられたすべてのシステムリソースを解放します。カプセル化された Cipher オブジェクトの doFinal メソッドを呼び出して、このオブジェクトによりバッファリングされたすべてのバイトを処理します。さらに flush メソッドを呼び出して、処理したバイトを基盤となるストリームに書き出します。
プログラマは、このクラスを使用してオブジェクトを作成し、暗号化アルゴリズムを利用してその機密性を保護することができます。
java.io.Serializable インタフェースを実装するオブジェクトが指定された場合、元のオブジェクトを直列化形式 (「ディープコピー」) でカプセル化する SealedObject を作成し、DES などの暗号化アルゴリズムを使用して直列化された内容をシール (暗号化) することにより、機密性を保護できます。その後、暗号化された内容の暗号解読 (適正な暗号解読鍵を使用)、および直列化解除を行うことにより、元のオブジェクトを復元できます。
一般的な使用法を、次のコード例に示します。オブジェクトをシールする場合、シール対象のオブジェクトから SealedObject を作成し、直列化されたオブジェクト内容を暗号化する、完全に初期化された Cipher オブジェクトを作成します。この例では、文字列「This is a secret」が DES アルゴリズムを使用してシールされます。シール操作に使用されるすべてのアルゴリズムパラメータは、SealedObject の内部に格納されることに留意してください。
// create Cipher object
// NOTE: sKey is assumed to refer to an already-generated
// secret DES key.
Cipher c = Cipher.getInstance("DES");
c.init(Cipher.ENCRYPT_MODE, sKey);
// do the sealing
SealedObject so = new SealedObject("This is a secret", c);
シールされた元のオブジェクトは、次の異なる 2 つの方法で復元可能です。
- 厳密に同一のアルゴリズム、鍵、パディング方式などで初期化され、オブジェクトのシールに使用された
Cipher オブジェクトを使用する方法
c.init(Cipher.DECRYPT_MODE, sKey);
try {
String s = (String)so.getObject(c);
} catch (Exception e) {
// do something
};
この方法には、暗号解読鍵に関する知識がなくても、シールされたオブジェクトのアンシールを実行できるという利点があります。たとえば、あるパーティーが暗号オブジェクトを必須の暗号解読鍵を使って初期化したあとで、別のパーティーに渡すと、そのパーティーはシールされたオブジェクトをアンシールできます。
- 適切な暗号解読鍵を使用する方法 (DES は対称暗号化アルゴリズムであるため、シールとアンシールに同じ鍵を使用できる)
try {
String s = (String)so.getObject(sKey);
} catch (Exception e) {
// do something
};
この方法では、getObject メソッドは、適切な暗号解読アルゴリズム用の暗号オブジェクトを作成し、シール済みのオブジェクトに格納された暗号解読鍵およびアルゴリズムパラメータ (存在する場合) を使用して初期化を行います。この方法の利点は、オブジェクトをアンシールするパーティーが、オブジェクトのシールに使用したパラメータ (IV など) を追跡する必要がないことです。
MessageDigest と同様に、メッセージ認証コード (MAC) は、送信された情報や信頼できないメディアに保存されている情報の整合性をチェックする方法を提供しますが、秘密鍵が計算に含まれます。適切な鍵を持つ人だけが、受信したメッセージを検証できます。一般に、メッセージ認証コードは、秘密鍵を共有する 2 つのパーティー間で送信される情報の有効性を検証する場合に使用されます。
暗号化ハッシュ機能に基づくMAC 機構は、HMAC と呼ばれます。HMAC は、秘密共有鍵と組み合わせて、MD5 や SHA-1 などの任意の暗号化ハッシュ機能で使用できます。
Mac クラスは、メッセージ認証コード (MAC) の機能を提供します。「コード例」を参照してください。
Mac オブジェクトの作成
Mac オブジェクトは、Mac getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
Mac オブジェクトの初期化
Mac オブジェクトは、常に (秘密) 鍵を使って初期化されます。また、基盤となる MAC アルゴリズムによっては、パラメータセットを使って初期化することもできます。
Mac オブジェクトを初期化する場合、次のいずれかの init メソッドを呼び出します。
public void init(Key key);
public void init(Key key, AlgorithmParameterSpec params);
javax.crypto.SecretKey インタフェースを実装する任意の (秘密) 鍵オブジェクトを使って、Mac オブジェクトを初期化できます。これは、javax.crypto.KeyGenerator.generateKey() が返すオブジェクト、javax.crypto.KeyAgreement.generateSecret() などが返す鍵協定プロトコルの結果生成されるオブジェクト、または javax.crypto.spec.SecretKeySpec のインスタンスです。
MAC アルゴリズムの中には、Mac オブジェクトの初期化に使用される (秘密) 鍵オブジェクトに関連付けられた (秘密) 鍵アルゴリズムが重要ではないものがあります (SunJCE プロバイダの HMAC-MD5 および HMAC-SHA1 実装の場合)。ただし、それ以外の場合、(秘密) 鍵アルゴリズムは重要であり、(秘密) 鍵オブジェクトが不適切な (秘密) 鍵アルゴリズムで使用されると、InvalidKeyException がスローされます。
MAC の計算
MAC は、1 つのステップで計算 (「単一部分操作」) することも 、複数のステップで計算 (「複数部分操作」) することもできます。データの長さが不明な場合、またはデータが長すぎて一度にメモリに格納できない場合に、複数部分操作は有用です。
あるデータの MAC を 1 回のステップで計算するには、次の doFinal メソッドを呼び出します。
public byte[] doFinal(byte[] input);
複数のステップでデータの MAC を計算するには、次のいずれかの update メソッドを呼び出します。
public void update(byte input);
public void update(byte[] input);
public void update(byte[] input, int inputOffset, int inputLen);
複数部分操作は、上記の doFinal メソッド (最後のステップで入力データが残される場合)、または次の doFinal メソッドのいずれか (最後のステップで入力データが残らない場合) を使って終了させます。
public byte[] doFinal();
public void doFinal(byte[] output, int outOffset);
ここまでは、鍵とは何か、鍵はどのように生成および表現されるかについて詳細は説明せずに、JCA の高レベルの使用に重点を置いてきました。ここでは鍵に注意を向けます。
java.security.Key インタフェースは、すべての不透明な鍵に関するトップレベルのインタフェースです。すべての不透明な鍵オブジェクトが共有する機能を定義します。
「不透明な」鍵の表現では、鍵を構成する鍵データに直接アクセスできません。つまり、「不透明」さにより、鍵へのアクセスが、Key インタフェースによって定義されるgetAlgorithm、getEncoded、および getFormat の 3 つのメソッドだけに制限されます。
これと対照的なのが「透明な」表現で、この場合は、対応する仕様クラス内に定義された get メソッドの 1 つを使用して、各鍵データの値に個々にアクセスできます。
不透明な鍵はすべて、次の 3 つの特性を持ちます。
- アルゴリズム
-
鍵に対する鍵のアルゴリズムです。通常、鍵のアルゴリズムは、暗号化または非対称オペレーションアルゴリズム (
AES、DSA、RSA など) で、これらのアルゴリズムや関連アルゴリズム (MD5withRSA、SHA1withRSA など) と連携して機能します。鍵のアルゴリズム名は、次のメソッドを使用して獲得します。
String getAlgorithm()
- コード化形式
-
鍵の外部コード化形式は、鍵を別の組織に転送する場合など、鍵の標準表示が Java 仮想マシンの外部で必要なときに使います。鍵は標準形式 (X.509 や PKCS8 など) に従ってコード化され、次のメソッドを使用して返されます。
byte[] getEncoded()
- フォーマット
-
コード化した鍵のフォーマット名です。以下のメソッドから返されます。
String getFormat()
鍵は一般的に、KeyGenerator や KeyPairGenerator などの鍵ジェネレータ、証明書、鍵仕様 (KeyFactory を使用)、または鍵管理で使用するキーストアデータベースにアクセスする KeyStore の実装から獲得します。KeyFactory を使って、アルゴリズム依存型の方法で符号化された鍵を解析することが可能です。
また、CertificateFactory を使って、認証を解析することも可能です。
次に、java.security.interfaces および javax.crypto.interfaces パッケージ内の Key インタフェースを拡張するインタフェースのリストを示します。
PublicKey および PrivateKey インタフェース
PublicKey および PrivateKey インタフェースはどちらも Key インタフェースを継承しますが、これらはメソッドを使わないインタフェースで、型の安全性および型の識別に使用します。
KeyPair クラスは鍵のペア (公開鍵と非公開鍵) の簡単なホルダーです。これには 2 つの public メソッドがあります。1 つは非公開鍵を返し、もう 1 つは公開鍵を返します。
PrivateKey getPrivate()
PublicKey getPublic()
Key オブジェクトと鍵仕様 (KeySpec) は、鍵データの異なる 2 つの表現です。Cipher は Key オブジェクトを使用して暗号化アルゴリズムを初期化しますが、伝送または格納のために鍵を移植性の高い形式に変換する必要がある場合があります。
鍵の「透明な」表現とは、対応する仕様クラスで定義された get メソッドの 1 つを使って、各鍵データに個々にアクセスできるということです。たとえば、DSAPrivateKeySpec は、getX、getP、getQ、および getG メソッドを定義し、非公開鍵 x および鍵の計算に使う DSA アルゴリズムのパラメータ (プライムの p、サブプライムの q およびベースの g)プライムの p、サブプライムの q、およびベースの g を返します。鍵がハードウェアデバイス上に格納されている場合は、その鍵仕様には、デバイス上の鍵の識別を助ける情報が含まれていることがあります。
この表現と対照的なのが、Key インタフェースによって定義されるような、「不透明な」表現です。「不透明な」鍵の表現では、鍵要素フィールドに直接アクセスできません。つまり、「不透明」さにより、鍵へのアクセスが、Key インタフェースによって定義されるgetAlgorithm、getEncoded、および getFormat の 3 つのメソッドだけに制限されます。
鍵は、アルゴリズム特定型か、またはアルゴリズム独立型の符号化形式 (ASN.1 など) の方法で指定できます。たとえば、DSA 非公開鍵は、非公開鍵のコンポーネント x、p、q、および g によって指定するか (DSAPrivateKeySpec を参照)、または、非公開鍵の DER 符号化を使って指定することが可能です (PKCS8EncodedKeySpec を参照)。
KeyFactory および SecretKeyFactory クラスは、不透明な鍵の表現と透明な鍵の表現の間 (つまり、Key と KeySpec の間。操作が可能であると想定) で変換を行うために使用できます。たとえば、スマートカード上の非公開鍵は、カードから取り出せない場合があります。そのような Key は変換不可能です。
次に、java.security.spec パッケージ内に含まれる鍵仕様のインタフェースおよびクラスについて説明します。
このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべての鍵仕様をグループ化することおよびそれらのグループに安全な型を提供することです。すべての鍵仕様で、このインタフェースを実装する必要があります。
Key インタフェースと同じように、KeySpec インタフェースの同様のセットがあります。
この abstract クラス (KeySpec インタフェースを実装する) は、符号化された形式の公開鍵または非公開鍵を表します。その getEncoded メソッドは、次の符号化された鍵を返します。
abstract byte[] getEncoded();
このクラスの getFormat メソッドは、次の符号化形式の名前を返します。
abstract String getFormat();
具体的な実装 PKCS8EncodedKeySpec および X509EncodedKeySpec については、次の節を参照してください。
このクラスは、EncodedKeySpec のサブクラスで、PKCS8 標準で指定された形式に従って、非公開鍵の DER 符号化を表現します。
このクラスの getEncoded メソッドは、PKCS8 標準に従って符号化された鍵のバイトを返します。このクラスの getFormat メソッドは、文字列 PKCS#8 を返します。
このクラスは、EncodedKeySpec のサブクラスで、X.509 標準で指定された形式に従って、公開鍵の DER 符号化を表現します。
このクラスの getEncoded メソッドは、X.509 標準に従って符号化された鍵のバイトを返します。このクラスの getFormat メソッドは、文字列 X.509 を返します。
Java および JCA API を初めて使用する人は、ジェネレータとファクトリの区別がつかない場合があります。
ジェネレータは、新しいオブジェクトを生成する場合に使用されます。ジェネレータは、アルゴリズム依存またはアルゴリズム非依存で初期化できます。たとえば、Diffie-Hellman (DH) 鍵ペアを作成するために、アプリケーションは必要な P および G 値を指定できます。または、ジェネレータを適切な鍵の長さで単純に初期化できます。ジェネレータは適切な P および G 値を選択します。どちらの場合も、ジェネレータはパラメータに基づいて新しい鍵を生成します。
一方、ファクトリは、既存のオブジェクト型から別のオブジェクト型へデータを変換する場合に使用されます。たとえば、アプリケーションに DH 非公開鍵の使用可能なコンポーネントがある場合があります。アプリケーションは、それらを KeySpec としてパッケージ化できますが、KeyAgreement オブジェクトが使用できるよう PrivateKey オブジェクトに変換する必要があります。または逆の変換が必要な場合もあります。または、それらに証明書のバイト配列があるが、CertificateFactory を使用して X509Certificate オブジェクトに変換する必要がある場合があります。アプリケーションは、変換を行うためにファクトリオブジェクトを使用します。
KeyFactory クラスは、不透明な暗号化 Key と鍵仕様 (背後の鍵データの透明な表現) 間の変換を実行する目的で設計されたエンジンクラスです。
鍵ファクトリは、双方向性があります。つまり、これによって、与えられた鍵仕様 (鍵のデータ) から不透明な鍵オブジェクトを構築することも、鍵オブジェクトの背後の鍵データを適切な形式で取得することもできます。
同一の鍵に対して、複数の互換性のある鍵仕様を存在させることもできます。たとえば、DSA 公開鍵は、コンポーネント y、p、q、および g によって指定することも (java.security.spec.DSAPublicKeySpec を参照)、X.509 標準に従って DER 符号化を使用して指定することも (X509EncodedKeySpec を参照) できます。
鍵ファクトリは、互換性のある鍵仕様間の変換に使用できます。互換性のある鍵仕様間の変換では、鍵の構文解析が行われます。たとえば、X509EncodedKeySpec を DSAPublicKeySpec に変換する場合は、基本的に符号化された鍵をコンポーネント単位で解釈処理します。例については、「鍵仕様および KeyFactory を使った署名の生成と検証」の最後を参照してください。
KeyFactory オブジェクトの作成
KeyFactory オブジェクトは、KeyFactory getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
鍵仕様と 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 クラスのインスタンスに返されるべきであることを指示します。
詳細は、例を参照してください。
このクラスは、秘密鍵のファクトリを表します。KeyFactory とは異なり、javax.crypto.SecretKeyFactory オブジェクトは秘密 (対称) 鍵のみを処理し、一方、java.security.KeyFactory オブジェクトは鍵ペアの公開鍵および非公開鍵コンポーネントを処理します。
鍵ファクトリは、Key (java.security.Key 型の不透明な暗号化鍵) を鍵仕様 (背後の鍵データの適切な形式の透明表現) に変換したり、その逆の変換を行うために使用します。
java.security.Key 型のオブジェクト (java.security.PublicKey、java.security.PrivateKey、および javax.crypto.SecretKey はそのサブクラス) は、その実装方法が不明であるため、不透明な鍵オブジェクトになります。基盤となる実装はプロバイダ依存であるため、ソフトウェアベースにもハードウェアベースにもできます。鍵ファクトリを使用すると、プロバイダは独自の暗号化鍵実装を提供できるようになります。
たとえば、公開値 y、プライム係数 p、ベース g で構成される Diffie Hellman 公開鍵の鍵仕様を保持しており、同じ仕様を別のプロバイダの Diffie-Hellman 鍵ファクトリに送る場合、生成される PublicKey オブジェクトは大抵、異なる基盤実装を保持するようになります。
プロバイダは、秘密鍵ファクトリがサポートする鍵仕様をドキュメント化する必要があります。たとえば、SunJCE プロバイダにより提供される DES 鍵の SecretKeyFactory は、DESKeySpec を DES 鍵の透明表現としてサポートします。また、DES-EDE 鍵の SecretKeyFactory は DESedeKeySpec を DES-EDE 鍵の透明表現として、PBE の SecretKeyFactory は PBEKeySpec を基盤となるパスワードの透明表現として、それぞれサポートします。
次の例は、SecretKeyFactory を使用して秘密鍵データを SecretKey オブジェクトに変換する方法を示します。これは、以降の Cipher 操作で使用できます。
// Note the following bytes are not realistic secret key data
// bytes but are simply supplied as an illustration of using data
// bytes (key material) you already have to build a DESKeySpec.
byte[] desKeyData = { (byte)0x01, (byte)0x02, (byte)0x03,
(byte)0x04, (byte)0x05, (byte)0x06, (byte)0x07, (byte)0x08 };
DESKeySpec desKeySpec = new DESKeySpec(desKeyData);
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
SecretKey secretKey = keyFactory.generateSecret(desKeySpec);
この場合、SecretKey の基盤実装は、KeyFactory のプロバイダに基づきます。
別の方法として、プロバイダに依存せずに、同じ鍵データから等価な機能を持つ SecretKey オブジェクトを作成することも可能です。その場合、javax.crypto.SecretKey インタフェースを実装する javax.crypto.spec.SecretKeySpec クラスを使用します。
byte[] desKeyData = { (byte)0x01, (byte)0x02, ...};
SecretKeySpec secretKey = new SecretKeySpec(desKeyData, "DES");
SecretKeyFactory オブジェクトの作成
SecretKeyFactory オブジェクトは、SecretKeyFactory getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
鍵仕様と Secret Key オブジェクト間の変換
秘密鍵用の鍵仕様がある場合は、generateSecret メソッドを使用して、その仕様から不透明な SecretKey オブジェクトを取得できます。
SecretKey generateSecret(KeySpec keySpec)
Secret Key オブジェクトと鍵仕様間の変換
Secret Key オブジェクトがある場合は、getKeySpec メソッドの呼び出しによって、対応する鍵仕様を取得できます。
KeySpec getKeySpec(Key key, Class keySpec)
keySpec は、鍵のデータが返されるべき仕様クラスを識別します。たとえば、DESKeySpec.class は、鍵のデータが DESKeySpec クラスのインスタンスに返される必要があることを指示します。
KeyPairGenerator クラスはエンジンクラスで、公開鍵と非公開鍵のペアの生成に使います。
鍵のペアの生成方法には、アルゴリズム独立型とアルゴリズム特定型の 2 つがあります。この 2 つの唯一の相違点は、オブジェクトの初期化にあります。
以下のメソッドの呼び出し例は、例の項を参照してください。
KeyPairGenerator の生成
すべての鍵のペアは、まず最初に KeyPairGenerator を使って生成します。KeyPairGenerator オブジェクトは、KeyPairGenerator getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
KeyPairGenerator の初期化
特定のアルゴリズム用の鍵のペアのジェネレータは、そのアルゴリズムで使うことができる公開鍵または非公開鍵を作成します。また、アルゴリズム特定型のパラメータを生成された各鍵に関連付けます。
まず、鍵のペアを初期化してからでなければ、鍵のペアは鍵を生成できません。ほとんどの場合、アルゴリズム独立型の初期化で十分です。ただし、その他の場合は、アルゴリズム特定型の初期化を使用できます。
アルゴリズム独立型の初期化
すべての鍵ジェネレータは、キーサイズおよび乱数の発生源の概念を共有します。キーサイズは、アルゴリズムごとに解釈が異なります。たとえば、DSA アルゴリズムの場合、キーサイズはモジュラスの長さと一致します。特定のアルゴリズムのキーサイズについては、標準名のドキュメントを参照してください。
普遍的に共有されるこれら 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 を呼び出すたびに、異なる鍵のペアが作られます。
鍵ジェネレータは、対称アルゴリズム用の秘密鍵を生成します。
KeyGenerator の作成
KeyGenerator オブジェクトは、KeyGenerator getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
KeyGenerator オブジェクトの初期化
特定の対称鍵アルゴリズムの鍵ジェレネータは、そのアルゴリズムで使用可能な対称鍵を作成します。また、生成された鍵に、アルゴリズムに特定のパラメータ (存在する場合) を関連付けます。
鍵の生成方法には、アルゴリズム独立型とアルゴリズム特定型の 2 つがあります。この 2 つの唯一の相違点は、オブジェクトの初期化にあります。
- アルゴリズム独立型の初期化
すべての鍵ジェネレータは、「キーサイズ」および「乱数の発生源」の概念を共有します。普遍的に共有されるこれら 2 つの引数の型をとる init メソッドが存在します。また、keysize 引数のみをとり、システムにより提供される乱数の発生源を使用する init メソッドや、乱数の発生源だけをとる init メソッドも存在します。
public void init(SecureRandom random);
public void init(int keysize);
public void init(int keysize, SecureRandom random);
上のアルゴリズムに依存しない init メソッドを呼び出すときは、その他のパラメータは指定しないため、生成された鍵に関連付けられるアルゴリズムに特定のパラメータが存在する場合、そのパラメータの処理は、プロバイダによって異なります。
- アルゴリズム特定型の初期化
アルゴリズムに特定のパラメータのセットがすでに存在する状況では、AlgorithmParameterSpec 引数を取る init メソッドが 2 つあります。このうちの一方は SecureRandom 引数も取りますが、他方では、乱数の発生源はシステムによって提供されます。
public void init(AlgorithmParameterSpec params);
public void init(AlgorithmParameterSpec params, SecureRandom random);
クライアントが (init メソッドの呼び出しを介して) KeyGenerator を明示的に初期化しない場合、各プロバイダはデフォルトの初期化を提供およびドキュメント化する必要があります。
鍵の作成
次のメソッドにより、秘密鍵が生成されます。
public SecretKey generateKey();
鍵協定とは、複数のパーティーが秘密情報を交換しなくても同じ暗号化鍵を確立可能なプロトコルを指します。
各パーティーは、非公開鍵によって鍵協定オブジェクトを初期化し、通信に参加する各パーティーの公開鍵を入力します。ほとんどの場合は 2 つのパーティーのみですが、Diffie-Hellman などのアルゴリズムでは 3 つ以上のパーティーの参加が可能です。公開鍵がすべて入力されると、各 KeyAgreement オブジェクトは同じ鍵を生成 (合意) します。
KeyAgreement クラスは、鍵協定プロトコルの機能を提供します。共有の秘密作成に関係する鍵は、KeyPairGenerator または KeyGenerator のいずれかの鍵ジェネレータか、KeyFactory により、または鍵協定プロトコルの中間フェーズの結果として作成されます。
KeyAgreement オブジェクトの作成
鍵協定に関係する各パーティーは、KeyAgreement オブジェクトを作成する必要があります。KeyAgreement オブジェクトは、KeyAgreement getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
KeyAgreement オブジェクトの初期化
非公開情報を使用して KeyAgreement オブジェクトを初期化できます。Diffie-Hellman の場合、Diffie-Hellman 非公開鍵を使用して初期化します。補足的な初期化情報には、乱数の発生源、アルゴリズムパラメータのセットが含まれます。要求された鍵協定アルゴリズムで、アルゴリズムパラメータを指定する必要があり、また KeyAgreement オブジェクトの初期化にパラメータではなく鍵だけが提供される場合、必須のアルゴリズムパラメータを鍵に含める必要があります。たとえば、Diffie-Hellman アルゴリズムは、プライム係数 p およびベースジェネレータ g をパラメータとして使用します。
KeyAgreement オブジェクトを初期化する場合、次のいずれかの init メソッドを呼び出します。
public void init(Key key);
public void init(Key key, SecureRandom random);
public void init(Key key, AlgorithmParameterSpec params);
public void init(Key key, AlgorithmParameterSpec params,
SecureRandom random);
KeyAgreement フェーズの実行
各協定プロトコルは、鍵協定に関係する各パーティーが実行する必要のある多数のフェーズで構成されます。
鍵協定の次のフェーズを実行するには、doPhase メソッドを呼び出します。
public Key doPhase(Key key, boolean lastPhase);
key パラメータには、そのフェーズで処理する鍵が含まれます。大抵の場合、これは、鍵協定に関係する他のパーティーのいずれかの公開鍵、または前のフェーズで生成された中間鍵です。doPhase は、この鍵協定の他のパーティーに送信する必要のある中間鍵を返すため、続くフェーズでその鍵を処理できます。
lastPhase パラメータには、実行するフェーズが鍵協定の最後のフェーズかどうかを指定します。値 FALSE は、これが鍵協定の最後のフェーズではない (この後にフェーズが続く) ことを示します。値 TRUE は、これが鍵協定の最後のフェーズであり、鍵協定が完了する (次に generateSecret が呼び出される) ことを示します。
2 つのパーティー間の Diffie-Hellman の例では、lastPhase を TRUE に設定して doPhase を呼び出します。Diffie-Hellman で 3 つのパーティーが存在する場合、doPhase を 2 度呼び出します。最初は lastPhase を FALSE に設定し、2 度目には lastPhase を TRUE に設定します。
共有される秘密の生成
各パーティーがすべての必須鍵協定フェーズを実行したあとで、generateSecret メソッドのいずれかを呼び出して共有される秘密を計算できます。
public byte[] generateSecret();
public int generateSecret(byte[] sharedSecret, int offset);
public SecretKey generateSecret(String algorithm);
「キーストア」と呼ばれるデータベースは、鍵および証明書のリポジトリを管理するために使用できます。「証明書」は、あるエンティティーからのデジタルに署名された文で、別のあるエンティティーの公開鍵に特定の値が含まれていることを示します。
ユーザーキーストアは、デフォルトではユーザーのホームディレクトリの .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 システムの場合
キーストアファイルは必要な場所に配置できます。環境によっては、複数のキーストアが存在することに意味がある場合があります。たとえば、JSSE (SSL/TLS) では、1 つのキーストアがユーザーの非公開鍵を保持し、別のキーストアが信頼関係を確立するために使用される証明書を保持する場合があります。
ユーザーのキーストア以外に、Sun JDK は、さまざまな証明書発行局 (CA) からの信頼できる証明書を格納するために使用されるシステム全体のキーストアも保持します。これらの CA 証明書は、信頼性の判定を行う場合に使用できます。たとえば、SSL/TLS で SunJSSE プロバイダがリモートピアから証明書を提示された場合、デフォルトのトラストマネージャーは、
<java-home>/lib/ext/cacerts [Unix]、または
<java-home>\lib\ext\cacerts [Windows]
ファイルに問い合わせて、接続が信頼できるかどうかを判断します。システム全体の cacerts キーストアを使用する代わりに、アプリケーションは独自のキーストアを設定して使用するか、前述のユーザーキーストアを使用できます。
キーストアクラスは、キーストア内の情報へのアクセスおよび情報の変更を行うための、明確に定義されたインタフェースを提供します。キーストアの固定実装としては、それぞれが特定の「タイプ」のキーストアを対象とする複数の異なる実装が存在可能です。
現在、キーストアを利用するコマンド行ツールには、keytool と jarsigner の 2 つがあります。また、GUI ベースの policytool というツールもあります。さまざまなソースのコードに対して (システムリソースへの) アクセス権を指定するポリシーファイルを処理する場合、このツールは Policy のリファレンス実装によっても使われます。KeyStore は public として使用可能なので、JDK ユーザーは KeyStore を使ったほかのセキュリティーアプリケーションも作成できます。
アプリケーションでは、KeyStore クラスの getInstance ファクトリメソッドを使うことで、さまざまなプロバイダから異なる「タイプ」のキーストアの実装を選択できます。キーストアのタイプは、キーストア情報の格納形式とデータ形式を定義するとともに、キーストア内の非公開鍵とキーストア自体の整合性を保護するために使われるアルゴリズムを定義します。異なるタイプのキーストアの実装には、互換性はありません。
Sun が提供する jks という組み込みのデフォルトのキーストア実装タイプがあります。これは、独自のキーストアタイプ (形式) を利用するもので、キーストアをファイルとして実装しています。この実装では、個々の非公開鍵は独自の個別のパスワードによって保護され、キーストア全体の整合性も (非公開鍵とは別の) パスワードによって保護されます。デフォルトは、セキュリティープロパティーファイル内の次の行によって指定されています。
keystore.type=jks
ツールおよびほかのアプリケーションで異なるデフォルトのキーストア実装を使用するには、この行を変更してデフォルトのタイプを指定します。jceks というタイプのキーストア実装を提供するプロバイダパッケージがある場合は、この行を次のように変更します。
keystore.type=jceks
keytool などの一部のアプリケーションでも、-storetype コマンド行パラメータによって、デフォルトのキーストアタイプをオーバーライドできます。
注:キーストアのタイプの指定では、大文字と小文字は区別されません。たとえば、JKS と jks は同じものとして扱われます。
ほかに 2 つのタイプのキーストアが、Sun JDK 実装に付属しています。
-
jceks
は、jks に対する独自の代替キーストア形式であり、トリプル DES によるパスワードベースの暗号化形式の、大幅に強力な暗号化を使用します。
Sun の jceks 実装は、jks キーストアファイルを解析して jceks 形式に変換できます。キーストア内の非公開鍵エントリのパスワードを変更し、キーストアタイプとして "-storetype jceks" を指定することによって、jks タイプのキーストアを jceks タイプのキーストアにアップグレードできます。提供される (より) 強力な暗号化による鍵保護を、デフォルトキーストア内の「signkey」という名前の非公開鍵に適用する場合は、次のコマンドを入力します。このコマンドにより、旧パスワードおよび新規パスワードの指定が求められます。
keytool -keypasswd -alias signkey -storetype jceks
keytool とキーストア、およびその管理方法の詳細は、「セキュリティーツール」を参照してください。
-
pkcs12 がもう一つのオプションです。これは、RSA PKCS12 Personal Information Exchange Syntax Standard に基づくクロスプラットフォームキーストアです。この規格は、ユーザーの非公開鍵、証明書、その他の秘密を格納および転送することを主な目的としています。JDK 6 では、信頼できる証明書を pkcs12 に格納する規格はまだ確立されていないため、jks または jceks を信頼できる証明書に使用する必要があります。
キーストアの実装は、プロバイダベースです。独自のキーストア実装を記述することに関心がある開発者は、「Java 暗号化アーキテクチャー用プロバイダの実装方法」でこのトピックの詳細を参照してください。
キーストアクラスは、キーストア内の情報へのアクセスおよび情報の変更を行うための明確に定義されたインタフェースを提供するエンジンクラスです。
キーストアクラスは、メモリ内の鍵および証明書のコレクションを表すもので、次の 2 種類のエントリを管理します。
- 鍵エントリ
-
このタイプのキーストアエントリには、非常に重要な暗号化鍵の情報が保持されます。情報は、保護された形式で格納され、権限のないアクセスを防ぎます。通常、この種類のエントリで格納される鍵は非公開鍵で、対応する公開鍵を証明する証明書チェーンが伴います。
非公開鍵および証明書チェーンは、デジタル署名を使った自己認証用に特定のエンティティーが使用します。たとえば、ソフトウェア配布団体は、リリースまたはライセンスするソフトウェアの一部として JAR ファイルにデジタル署名を付けます。
- 信頼できる証明書エントリ
-
この種類のエントリには、別の組織に属する単一の公開鍵が含まれ、「信頼できる証明書」と呼ばれます。これは、キーストアの所有者が、証明書内の公開鍵が実際に証明書の「サブジェクト」(所有者) によって識別されたアイデンティティーに属することを信頼するためです。
この種類のエントリは、ほかの組織の認証に使うことができます。
キーストア内の各エントリは、「別名」文字列によって識別されます。非公開鍵とそれに関連付けられた証明書チェーンの場合は、これらの文字列は、エンティティー自体が認証するというように、方法別に区別されます。たとえば、エンティティーが異なる証明書発行局を使ったり、異なる公開鍵アルゴリズムを使ったりして、エンティティー自体を認証することも可能です。
キーストアが持続性があるかどうか、および持続性がある場合に使われる機構は、ここでは指定されません。この規則により、重要な (秘密または非公開) 鍵を保護するためのさまざまな技術を使うことができます。スマートカードまたはその他の統合暗号化エンジン (SafeKeyper) を使うことも 1 つの方法です。また、ファイルなどのより単純な機構をさまざまな形式で使うこともできます。
主要なキーストアメソッドを以下で説明します。
キーストアオブジェクトの作成
KeyStore オブジェクトは、KeyStore getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
特定キーストアのメモリへのロード
キーストアオブジェクトを使う前に、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 バイト配列は、PKCS8 標準の定義に従って 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)
パスワードは、キーストアデータの統合チェックサムの計算に使われます。統合チェックサムは、キーストアデータのあとに追加されます。
Key および Keyspec と同様に、アルゴリズムの初期化パラメータは AlgorithmParameter または AlgorithmParameterSpec によって表されます。使用状況に応じて、アルゴリズムはパラメータを直接使用できます。または、伝送または格納のためにパラメータを移植性の高い形式に変換する必要がある場合があります。
AlgorithmParameterSpec によるパラメータのセットの「透明な」表現とは、セットの各パラメータの値に個別にアクセスできることを意味します。これらの値には、対応する仕様クラスに定義された get メソッドの 1 つを使ってアクセスできます (DSAParameterSpec では、getP、getQ、および getG メソッドを定義して、それぞれ p、q、および g にアクセスするなど)。
これに対して、AlgorithmParameters クラスは「不透明な」表現を提供します。「不透明な」表現では、パラメータフィールドに直接アクセスできません。パラメータセットに関連付けられたアルゴリズム名の取得 (getAlgorithm による)、およびそのパラメータセット用のある種の符号化の取得 (getEncoded による) しかできません。
AlgorithmParameterSpec は、暗号化パラメータの透明な仕様へのインタフェースです。このインタフェースには、メソッドまたは定数が含まれていません。このインタフェースの唯一の目的は、すべてのパラメータの仕様をグループ化すること (およびそれらのパラメータに安全な型を提供すること) です。すべてのパラメータの仕様で、このインタフェースを実装する必要があります。
java.security.spec および javax.crypto.spec パッケージに含まれるアルゴリズムパラメータ仕様のインタフェースおよびクラスについては、JDK javadoc で説明されています。
次のアルゴリズムパラメータ仕様は、JSR 105 の一部として特にデジタル署名に使用されます。
AlgorithmParameters クラスは、暗号化パラメータの不透明な表現を提供するエンジンクラスです。特定の AlgorithmParameterSpec オブジェクトを使用するか、または認識される書式でパラメータをエンコードすることによって、AlgorithmParameters クラスを初期化できます。結果の仕様を getParameterSpec メソッドで取得できます (次の項を参照)。
AlgorithmParameters オブジェクトの作成
AlgorithmParameters オブジェクトは、AlgorithmParameters getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
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 getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
AlgorithmParameterGenerator オブジェクトの初期化
AlgorithmParameterGenerator オブジェクトは、アルゴリズム独立型、またはアルゴリズム特定型の 2 種類の方法で初期化できます。
アルゴリズム独立型の方法では、すべてのパラメータジェネレータが「サイズ」および乱数の発生源という概念を共有するという特性を利用します。サイズの単位は、すべてアルゴリズムパラメータで普遍的に共通していますが、その解釈はアルゴリズムにより異なります。たとえば、DSA アルゴリズムのパラメータの場合、「サイズ」はプライムモジュラスのビット数のサイズに一致します。特定のアルゴリズムのサイズについては、標準名のドキュメントを参照してください。この方法を使うと、アルゴリズム特定型のパラメータの生成値が (ある場合は)、デフォルト基準値になります。
普遍的に共有されるこれら 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 システムパラメータを生成するには、通常、パラメータ生成値は、プライムモジュラスおよびランダム指数のサイズで構成されます。どちらのサイズもビット数で指定します。
アルゴリズムパラメータの生成
AlgorithmParameterGenerator オブジェクトを作成および初期化したら、generateParameters メソッドを使ってアルゴリズムパラメータを生成できます。
AlgorithmParameters generateParameters()
CertificateFactory クラスは、証明書ファクトリの機能を定義するエンジンクラスです。証明書ファクトリは、証明書および証明書の取り消しリスト (CRL) オブジェクトをその符号化から生成するために使用されます。
X.509 の証明書ファクトリは、java.security.cert.X509Certificate のインスタンスである証明書、および java.security.cert.X509CRL のインスタンスである CRL を返します。
CertificateFactory オブジェクトの作成
CertificateFactory オブジェクトは、getInstance() static ファクトリメソッドの 1 つを使用することによって取得されます。
証明書オブジェクトの生成
証明書オブジェクトを生成し、入力ストリームから読み込まれたデータを使って初期化するには、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 オブジェクトの生成
PKIX 用の証明書パスビルダーおよびバリデータは、「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」RFC 3280 によって定義されます。
PKIX LDAP V2 スキーマを使用して証明書と CRL を Collection ディレクトリおよび LDAP ディレクトリから取得するための証明書ストアの実装も、RFC 2587 として IETF から使用可能です。
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()
初めにデフォルトのエンコーディングが一覧表示されます。
JCA のクラスについて理解したため、次に、これらのクラスがどのように結合されて SSL/TLS のような高度なネットワークプロトコルを実装するかについて考えます。「JSSE リファレンスガイド」の SSL/TLS の概要の項に、プロトコルの機能の高レベルの説明があります。非対称 (公開鍵) 暗号操作は対称操作 (秘密鍵) よりも大幅に遅いため、公開鍵暗号方式は、実際のアプリケーションデータを保護するために使用される秘密鍵を確立する場合に使用されます。非常に単純に言うと、SSL/TLS ハンドシェークには、初期化データの交換、いくつかの公開鍵操作の実行による秘密鍵への到達、およびその鍵を使用したその後のトラフィックの暗号化が含まれます。
注: ここで説明する詳細では、単純に、前述のクラスがどのように使用されるかを示します。この項では、SSL/TLS 実装を構築するための十分な情報は提供しません。詳細は、「JSSE リファレンスガイド」および「RFC 2246: The TLS Protocol」を参照してください。
この SSL/TLS 実装が JSSE プロバイダとして使用可能になるとします。Provider クラスの固定実装が最初に記述され、最終的にプロバイダの Security クラスのリストに登録されます。このプロバイダは、主に、アルゴリズム名から実際の実装クラスへのマッピングを提供します。たとえば、「SSLContext.TLS」->「com.foo.TLSImpl」です。アプリケーションが SSLContext.getInstance("TLS") によって「TLS」インスタンスを要求すると、要求されたアルゴリズムがプロバイダのリストに問い合わせされ、適切なインスタンスが作成されます。
実際のハンドシェークの詳細を説明する前に、JSSE のアーキテクチャーのいくつかを簡単に確認する必要があります。JSSE アーキテクチャーの中心は、SSLContext です。コンテキストは、最終的に SSL/TLS プロトコルを実際に実装する最終オブジェクト (SSLSocket および SSLEngine) を作成します。SSLContext は、2 つのコールバッククラス KeyManager および TrustManager によって初期化されます。これらを使用すると、アプリケーションは送信する認証データを最初に選択し、次にピアによって送信された証明書を検証できます。
JSSE KeyManager は、ピアに提示する証明書の選択を行います。多くのアルゴリズムが可能ですが、一般的な方法は、RSA または DSA 公開鍵と非公開鍵のペアを、ディスクファイルに基づく KeyStore 内の X509Certificate とともに保持することです。KeyStore オブジェクトが初期化されてファイルからロードされると、ファイルの未変換のバイトは KeyFactory を使用して PublicKey および PrivateKey オブジェクトに変換され、証明書チェーンのバイトは CertificateFactory を使用して変換されます。資格が必要な場合、KeyManager は単純にこの KeyStore オブジェクトに問い合わせ、どの資格を提示するかを判断します。
KeyStore の内容は、最初に keytool などのユーティリティーを使用して作成されている場合があります。keytool は、RSA または DSA KeyPairGenerator を作成し、適切なキーサイズで初期化します。このジェネレータは、次に、keytool が新しく作成された証明書とともに KeyStore に格納する KeyPair (最終的にディスクに書き込まれる) を作成する場合に使用されます。
JSSE TrustManager は、ピアから受信した資格の検証を行います。資格の検証には多数の方法があります。その一つは、CertPath オブジェクトを作成し、JDK の組み込み公開鍵インフラストラクチャー (PKI) フレームワークで検証を処理する方法です。内部的に、CertPath 実装は Signature オブジェクトを作成し、それを使用して証明書チェーン内のそれぞれの署名を検証する場合があります。
アーキテクチャーの基本について理解することによって、SSL/TLS ハンドシェークの手順のいくつかを調べることができます。クライアントは、ClientHello メッセージをサーバーに送信することによって開始します。サーバーは使用する暗号群を選択し、ServerHello メッセージ内でそれを返信し、暗号群の選択に基づいて JCA オブジェクトの作成を開始します。次の例では、サーバーのみの認証を使用します。
最初の例では、サーバーは TLS_RSA_WITH_AES_128_CBC_SHA などの RSA ベースの暗号群を使用しようとします。サーバーの KeyManager がクエリーされ、適切な RSA エントリを返します。サーバーの資格 (つまり、証明書/公開鍵) がサーバーの Certificate メッセージ内で送信されます。クライアントの TrustManager はサーバーの証明書を検証し、受け入れた場合、クライアントは SecureRandom オブジェクトを使用していくつかのランダムバイトを生成します。次に、サーバーの証明書内で見つかった PublicKey によって初期化された暗号化非対称 RSA Cipher オブジェクトを使用して暗号化されます。この暗号化されたデータは、Client Key Exchange メッセージ内で送信されます。サーバーは、対応する PrivateKey を使用し、同様の Cipher を復号モードで使用してバイトを回復します。これらのバイトは、実際の暗号化鍵を確立する場合に使用されます。
別の例では、一時的な Diffie-Hellman 鍵協定アルゴリズムと TLS_DHE_DSS_WITH_AES_128_CBC_SHA などの DSA 署名アルゴリズムが選択されます。両方の側でそれぞれ、KeyPairGenerator を使用して、新しい一時的な DH 公開鍵と非公開鍵のペアを確立します。各ジェネレータは、KeyFactory および DHPublicKeySpec クラスを使用して、さらに細かく変換できる DH 鍵を作成します。それぞれの側は、次に KeyAgreement オブジェクトを作成し、それぞれの DH PrivateKey によって初期化します。サーバーはその公開鍵を ServerKeyExchange メッセージ内で送信し (DSA 署名アルゴリズムによって保護される)、クライアントはその公開鍵を ClientKeyExchange メッセージ内で送信します。公開鍵が別の KeyFactory を使用して再度組み立てられると、これらは協定オブジェクトに渡されます。KeyAgreement オブジェクトは、実際の暗号化鍵を確立する場合に使用される合意済みのバイトを生成します。
実際の暗号化鍵が確立されると、対称 Cipher オブジェクトを初期化するために秘密鍵が使用され、この暗号が送信中のすべてのデータを保護する場合に使用されます。データが変更されたかどうかを判断できるように MessageDigest が作成され、ネットワークに送信されるデータのコピーを受信します。パケットが完全な場合、ダイジェスト (ハッシュ) がデータのあとに付加され、パケット全体が Cipher によって暗号化されます。AES などのブロック暗号が使用される場合は、データにパディングを行って完全なブロックにします。リモート側では、手順は単純に逆になります。
| ヘッダー |
データ |
ダイジェスト |
パディング (存在する場合) |
これは非常に単純化されていますが、これらのクラスがどのように結合されて高レベルのプロトコルを作成するかを示しています。
次に示すのは、JCA 機構のいくつかの使用を説明する短い例です。また、全体を示す実際の例が「付録 D」にあります。
まず最初に、以下の例のようにして MessageDigest を生成します。
MessageDigest sha = MessageDigest.getInstance("SHA-1");
この呼び出しは、正しく初期化されたメッセージダイジェストオブジェクトを変数 sha に代入します。この実装は、National Institute for Standards and Technology (NIST) の FIPS 180-2 ドキュメントの定義に従って、Secure Hash アルゴリズム (SHA-2) を実装します。標準名とアルゴリズムに関する詳細は、「付録 A」を参照してください。
次に、3 つのバイト配列 i1、i2、および i3 があるとします。計算するメッセージダイジェストを持つ合計入力は、この 3 つの配列から形成されます。このダイジェスト (または「ハッシュ」) は、以下の呼び出しを使って計算できます。
sha.update(i1);
sha.update(i2);
sha.update(i3);
byte[] hash = sha.digest();
以下の一連の呼び出しを使っても同じです。
sha.update(i1);
sha.update(i2);
byte[] hash = sha.digest(i3);
メッセージダイジェストが計算されると、メッセージダイジェストオブジェクトは自動的にリセットされ、新しいデータをレビューしてそのダイジェストを計算できる状態になります。以前の状態 (たとえば update 呼び出しで入れたデータ) はすべて失われます。
ハッシュ実装によっては、複製 (コピー) を介して中間ハッシュをサポートするものもあります。次について、別々のハッシュを計算すると仮定します。
i1
i1 および i2
i1、i2、および i3
次のように処理します。
/* 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();
このコードは、SHA-1 実装が複製 (コピー) 可能な場合にだけ機能します。メッセージダイジェストの実装の中には、複製 (コピー) 可能なものもあれば、不可能なものもあります。複製 (コピー) が可能かどうかを判断するには、次のように MessageDigest オブジェクトを複製し、発生する可能性のある例外をキャッチします。
try {
// try and clone it
/* compute the hash for i1 */
sha.update(i1);
byte[] i1Hash = sha.clone().digest();
. . .
byte[] i123hash = sha.digest();
} catch (CloneNotSupportedException cnse) {
// do something else, such as the code shown below
}
メッセージダイジェストが複製 (コピー) 不可能な場合は、別の多少複雑な方法を使います。つまり、複数のダイジェストを生成して中間ダイジェストを計算します。この場合、計算する中間ダイジェストの数をあらかじめ知っておく必要があります。
MessageDigest sha1 = MessageDigest.getInstance("SHA-1");
MessageDigest sha12 = MessageDigest.getInstance("SHA-1");
MessageDigest sha123 = MessageDigest.getInstance("SHA-1");
byte[] i1Hash = sha1.digest(i1);
sha12.update(i1);
byte[] i12Hash = sha12.digest(i2);
sha123.update(i1);
sha123.update(i2);
byte[] i123Hash = sha123.digest(i3);
この例では、「DSA」(デジタル署名アルゴリズム) という名前のアルゴリズムについて、「公開 - 非公開」の鍵のペアを生成し、この鍵のペアをその後の例で使用します。鍵は、1024 ビットモジュラスで生成します。ここでは、アルゴリズム実装を提供するプロバイダは考慮しません。
最初の手順は、DSA アルゴリズムの鍵を生成するための鍵のペアジェネレータオブジェクトの獲得です。
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA");
KeyPairGenerator の初期化
次の手順は、鍵のペアジェネレータの初期化です。たいていの場合、アルゴリズム独立型の初期化で十分ですが、アルゴリズム特定型の初期化を使う必要がある場合もあります。
アルゴリズム独立型の初期化
すべての鍵ジェネレータは、キーサイズおよび乱数の発生源の概念を共有します。KeyPairGenerator クラス初期化メソッドには、最低限キーサイズが必要です。乱数の発生源が明示的に提供されない場合、もっとも高い優先順位でインストールされているプロバイダの SecureRandom 実装が使用されます。したがって、キーサイズ 1024 で鍵を生成するには、次のコードを呼び出すだけです。
SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");
keyGen.initialize(1024, random);
次のコードは、特定の、追加でシードされる SecureRandom オブジェクトを使用する方法を示しています。
SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");
random.setSeed(userSeed);
keyGen.initialize(1024, random);
上のアルゴリズム独立型 initialize メソッドを呼び出すときは、その他のパラメータは指定しないため、各鍵に関連付けられるアルゴリズム特定型のパラメータがある場合は、パラメータをどうするかは、プロバイダによって異なります。プロバイダは、事前に計算されたパラメータ値を使うことも、新しい値を生成することもできます。
アルゴリズム特定型の初期化
アルゴリズム特定型パラメータのセットがすでに存在する状況では (DSA の「コミュニティーパラメータ」など)、AlgorithmParameterSpec 引数を取る initialize メソッドが 2 つあります。鍵のペアのジェネレータが DSA アルゴリズムのジェネレータで、DSA 特定パラメータのセット p、q、および g があり、これを使って鍵のペアを生成したいとします。次のコードを実行して鍵のペアのジェネレータを初期化できます。DSAParameterSpec は AlgorithmParameterSpec です。
DSAParameterSpec dsaSpec = new DSAParameterSpec(p, q, g);
SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");
random.setSeed(userSeed);
keyGen.initialize(dsaSpec, random);
注:名前が p のパラメータは、長さがモジュラスの長さ (サイズ) のプライム数です。したがって、モジュラスの長さを指定するために他のメソッドを呼び出す必要はありません。
鍵のペアの生成
最終手順は、鍵のペアの実際の生成です。使用した初期化の型 (アルゴリズム独立型またはアルゴリズム特定型) に関係なく、同じコードを使って鍵のペアを生成します。
KeyPair pair = keyGen.generateKeyPair();
次の署名の生成および検証の例では、前述の鍵のペアの例で生成された KeyPair を利用しています。
署名の生成
まず最初に署名オブジェクトを生成します。
Signature dsa = Signature.getInstance("SHA1withDSA");
鍵のペアの例で生成した鍵のペアを使い、非公開鍵を指定してオブジェクトを初期化します。このあとで data というバイト配列に署名を付けます。
/* Initializing the object with a private key */
PrivateKey priv = pair.getPrivate();
dsa.initSign(priv);
/* Update and sign the data */
dsa.update(data);
byte[] sig = dsa.sign();
署名の検証は簡単です。ここでも、鍵のペアの例で生成した鍵のペアを使います。
/* Initializing the object with the public key */
PublicKey pub = pair.getPublic();
dsa.initVerify(pub);
/* Update and verify the data */
dsa.update(data);
boolean verifies = dsa.verify(sig);
System.out.println("signature verifies: " + verifies);
前述の鍵のペアの例で生成したような公開鍵と非公開鍵のペアを使うよりも、単に DSA 非公開鍵のコンポーネント x (非公開鍵)、p (プライム)、q (サブプライム)、および g (ベース) を使うとします。
さらに、非公開鍵を使って someData というバイト配列内のあるデータにデジタル署名を付けたいとします。次の手順を実行します。この手順は、鍵仕様の作成、および鍵ファクトリを使って鍵仕様から PrivateKey を取得する方法も示しています。initSign には PrivateKey が必要です。
DSAPrivateKeySpec dsaPrivKeySpec = new DSAPrivateKeySpec(x, p, q, g);
KeyFactory keyFactory = KeyFactory.getInstance("DSA");
PrivateKey privKey = keyFactory.generatePrivate(dsaPrivKeySpec);
Signature sig = Signature.getInstance("SHA1withDSA");
sig.initSign(privKey);
sig.update(someData);
byte[] signature = sig.sign();
Alice が署名したデータを使いたいとします。彼女がそのデータを使うため、および署名を検証するためには、彼女に次の 3 つのものを送る必要があります。
- データ
- 署名
- データの署名に使った非公開鍵に対応する公開鍵
someData バイトをあるファイルに格納し、signature バイトを別のファイルに格納し、両方を Alice に送ることができます。
公開鍵に関しては、上の署名の例のように、データの署名に使った DSA 非公開鍵に対応する DSA 公開鍵のコンポーネントを持っていると想定します。この場合は、コンポーネントから DSAPublicKeySpec を作成できます。
DSAPublicKeySpec dsaPubKeySpec = new DSAPublicKeySpec(y, p, q, g);
ただし、鍵バイトをファイルに記述できるように、鍵バイトを抽出する必要があります。このためには、まず、上の例ですでに作成した DSA 鍵ファクトリの generatePublic メソッドを呼び出します。
PublicKey pubKey = keyFactory.generatePublic(dsaPubKeySpec);
次に、以下のコードを使って符号化された鍵バイトを抽出します。
byte[] encKey = pubKey.getEncoded();
この時点でバイトをファイルに保存し、データおよび署名を保存したファイルと一緒に Alice に送ることができます。
ここで、Alice がこれらのファイルを受け取り、データファイルのデータバイトを data というバイト配列に、署名ファイルの署名バイトを signature というバイト配列に、公開鍵ファイルの符号化された公開鍵バイトを encodedPubKey というバイト配列にコピーしたとします。
Alice は、次のコードを実行して署名を検証できます。このコードは、符号化された状態から DSA 公開鍵のインスタンスを生成するために、鍵ファクトリを使う方法も示しています。initVerify には PublicKey が必要です。
X509EncodedKeySpec pubKeySpec = new X509EncodedKeySpec(encodedPubKey);
KeyFactory keyFactory = KeyFactory.getInstance("DSA");
PublicKey pubKey = keyFactory.generatePublic(pubKeySpec);
Signature sig = Signature.getInstance("SHA1withDSA");
sig.initVerify(pubKey);
sig.update(data);
sig.verify(signature);
注:上のコードでは、initVerify が PublicKey を必要とするため、Alice は符号化された鍵ビットから PublicKey を生成する必要がありました。PublicKey を取得したら、KeyFactory getKeySpec メソッドを使って、PublicKey を DSAPublicKeySpec に変換して、必要な場合にコンポーネントにアクセスすることが可能です。
DSAPublicKeySpec dsaPubKeySpec =
(DSAPublicKeySpec)keyFactory.getKeySpec(pubKey,
DSAPublicKeySpec.class)
これで Alice は、DSA 公開鍵コンポーネント y、p、q、および g に、DSAPublicKeySpec クラスの対応する get メソッド (getY、getP、getQ、および getG) を使ってアクセスできます。
2 つの鍵の同一性の判定
しばしば、2 つの鍵の同一性の判定が必要になることがありますが、デフォルトのjava.lang.Object.equals メソッドでは、必要な結果が得られない場合があります。プロバイダに対する依存度が最も少ない方法は、符号化された鍵を比較する方法です。この方法で適切に比較できない場合 (たとえば、RSAPrivateKey と RSAPrivateCrtKey を比較する場合)、各コンポーネントを比較する必要があります。その方法を示すコードを次に示します。
static boolean keysEqual(Key key1, Key key2) {
if (key1.equals(key2)) {
return true;
}
if (Arrays.equals(key1.getEncoded(), key2.getEncoded())) {
return true;
}
// More code for different types of keys here.
// For example, the following code can check if
// an RSAPrivateKey and an RSAPrivateCrtKey are equal:
// if ((key1 instanceof RSAPrivateKey) &&
// (key2 instanceof RSAPrivateKey)) {
// if ((key1.getModulus().equals(key2.getModulus())) &&
// (key1.getPrivateExponent().equals(
// key2.getPrivateExponent()))) {
// return true;
// }
// }
return false;
}
次の例は、Base64- 符号化された証明書を読み取ります。認証の開始は、次のコードで指定されます。
-----BEGIN CERTIFICATE-----
最後は、次の行で終わります。
-----END CERTIFICATE-----
FileInputStream (mark および reset をサポートしない) を ByteArrayInputStream (mark および reset をサポートする) に変換し、generateCertificate への各呼び出しに証明書が 1 つだけ使われて、入力ストリームの読み取られた位置がファイル内の次の証明書に配置されるようにします。
FileInputStream fis = new FileInputStream(filename);
BufferedInputStream bis = new BufferedInputStream(fis);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
while (bis.available() > 0) {
Certificate cert = cf.generateCertificate(bis);
System.out.println(cert.toString());
}
次の例は、ファイル内に保存された PKCS7 形式の認証応答を解析し、そこから証明書をすべて抽出します。
FileInputStream fis = new FileInputStream(filename);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
Collection c = cf.generateCertificates(fis);
Iterator i = c.iterator();
while (i.hasNext()) {
Certificate cert = (Certificate)i.next();
System.out.println(cert);
}
このセクションでは、鍵の生成、Cipher オブジェクトの作成と初期化、およびファイルの暗号化と暗号解読という一連の処理について説明します。この例全体で、Advanced Encryption Standard (AES) を使用します。
鍵の生成
AES 鍵を作成するには、AES 用の KeyGenerator をインスタンス化する必要があります。特定の AES 鍵生成実装について考慮する必要はないため、プロバイダは指定しません。KeyGenerator を初期化しないため、AES 鍵の作成にはシステム提供の乱数発生源およびデフォルトのキーサイズが使用されます。
KeyGenerator keygen = KeyGenerator.getInstance("AES");
SecretKey aesKey = keygen.generateKey();
鍵を生成した後、同じ KeyGenerator を使用して他の鍵を再度作成できます。
Cipher の作成
次のステップは、Cipher インスタンスの作成です。これには、Cipher クラスのいずれかの getInstance ファクトリメソッドを使用します。次のコンポーネントを含む必須の変換名を、スラッシュ (/) で区切って指定する必要があります。
- アルゴリズム名
- モード (オプション)
- パディング方式 (オプション)
この例では、Electronic Codebook モードおよび PKCS5 パディング方式で AES 暗号を作成します。特定の必須変換の実装について考慮する必要はないため、プロバイダは指定しません。
AES の標準アルゴリズム名は「AES」、Electronic Codebook モードの標準名は「ECB」、PKCS5 パディング方式の標準名は「PKCS5Padding」です。
Cipher aesCipher;
// Create the cipher
aesCipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
上で生成された aesKey を使用して、Cipher オブジェクトを暗号化用に初期化します。
// Initialize the cipher for encryption
aesCipher.init(Cipher.ENCRYPT_MODE, aesKey);
// Our cleartext
byte[] cleartext = "This is just an example".getBytes();
// Encrypt the cleartext
byte[] ciphertext = aesCipher.doFinal(cleartext);
// Initialize the same cipher for decryption
aesCipher.init(Cipher.DECRYPT_MODE, aesKey);
// Decrypt the ciphertext
byte[] cleartext1 = aesCipher.doFinal(ciphertext);
cleartext と cleartext1 は、同一です。
この例では、ユーザーにパスワードを要求し、暗号化鍵をそのパスワードから導き出します。
java.lang.String 型のオブジェクトにパスワードを収集および格納するのは、適切と考えられます。ただし、注意すべき点があります。それは、String 型のオブジェクトは不変であるということです。このため、使用後に String の内容を変更 (上書き) またはゼロにするようなメソッドは存在しません。この機能のために、String オブジェクトは、ユーザーパスワードなどセキュリティー上重要な情報の格納には適しません。セキュリティー関連の情報は、常に char 型の配列に収集および格納するようにしてください。
この理由で、javax.crypto.spec.PBEKeySpec クラスは、パスワードを char 型の配列として受け取り、返します。入力ストリームから文字配列パスワードを読み込む 1 つの方法として、「付録 D」のサンプルコード内の ReadPassword クラスを参照してください。
PKCS5 で定義されたパスワードベース暗号化 (PBE) を使用するには、salt および iteration count を指定する必要があります。暗号解読時にも、暗号化時と同じ salt および繰り返し処理の回数を使用する必要があります。
PBEKeySpec pbeKeySpec;
PBEParameterSpec pbeParamSpec;
SecretKeyFactory keyFac;
// Salt
byte[] salt = {
(byte)0xc7, (byte)0x73, (byte)0x21, (byte)0x8c,
(byte)0x7e, (byte)0xc8, (byte)0xee, (byte)0x99
};
// Iteration count
int count = 20;
// Create PBE parameter set
pbeParamSpec = new PBEParameterSpec(salt, count);
// Prompt user for encryption password.
// Collect user password as char array (using the
// "readPassword" method from above), and convert
// it into a SecretKey object, using a PBE key
// factory.
System.out.print("Enter encryption password: ");
System.out.flush();
pbeKeySpec = new PBEKeySpec(readPassword(System.in));
keyFac = SecretKeyFactory.getInstance("PBEWithMD5AndDES");
SecretKey pbeKey = keyFac.generateSecret(pbeKeySpec);
// Create PBE Cipher
Cipher pbeCipher = Cipher.getInstance("PBEWithMD5AndDES");
// Initialize PBE Cipher with key and parameters
pbeCipher.init(Cipher.ENCRYPT_MODE, pbeKey, pbeParamSpec);
// Our cleartext
byte[] cleartext = "This is another example".getBytes();
// Encrypt the cleartext
byte[] ciphertext = pbeCipher.doFinal(cleartext);
2 つおよび 3 つのパーティー間で Diffie-Hellman 鍵交換を実行するサンプルプログラムに関しては、「付録 D」を参照してください。
JCA の管轄ポリシーファイルは、Java 形式のポリシーファイル (対応するアクセス権を指定する文を含む) で表されます。「デフォルトの Policy の実装とポリシーファイルの構文」に説明されているように、Java ポリシーファイルでは、指定されたコードソースからコードに付与するアクセス権を指定します。アクセス権は、システムリソースへのアクセスを表します。JCA の場合、「リソース」は暗号化アルゴリズムです。また、暗号化制限はすべてのコードに適用されるため、コードソースを指定する必要はありません。
管轄ポリシーファイルは、1 つ以上の「アクセス権エントリ」を含む、非常に基本的な「付与エントリ」で構成されます。
grant {
<permission entries>;
};
次に、管轄ポリシーファイルのアクセス権エントリの書式を示します。
permission <crypto permission class name>[ <alg_name>
[[, <exemption mechanism name>][, <maxKeySize>
[, <AlgorithmParameterSpec class name>,
<parameters for constructing an
AlgorithmParameterSpec object>]]]];
次に、「Blowfish」アルゴリズムを 64 ビットの最大キーサイズに制限する、管轄ポリシーファイルのサンプルを示します。
grant {
permission javax.crypto.CryptoPermission "Blowfish", 64;
. . .;
};
アクセス権エントリは、permission で始まります。上記のテンプレート内の <crypto permission class name> には、javax.crypto.CryptoPermission などの具体的なアクセス権クラス名を指定します。暗号化アクセス権クラスは、特定の環境下で特定のキーサイズを使用するアプリケーション/アプレットの機能に対応します。暗号化アクセス権クラスには、CryptoPermission および CryptoAllPermission の 2 つが存在します。特別な CryptoAllPermission クラスは、暗号化関連のアクセス権すべてを表します。つまり、暗号化関連の制限はないことを示します。
<alg_name> を指定する場合、"DES" や "RSA" など暗号化アルゴリズムの標準名を表す文字列 (「付録 A」を参照) を引用符で囲んで指定します。
<免責機構名> を指定する場合、免責機構を指す文字列を引用符で囲んで指定します。免責機構を実施すると、暗号化制限が緩和されます。使用可能な免責機構名には、「KeyRecovery」、「KeyEscrow」、および「KeyWeakening」が含まれます。
<maxKeySize> には、指定したアルゴリズムに許可する最大鍵サイズ (ビット) を示す整数値を指定します。
アルゴリズムによっては、キーサイズでアルゴリズムの強度を指定するだけでは不十分な場合があります。たとえば、"RC5" アルゴリズムの場合には、ラウンド数も考慮する必要があります。アルゴリズムの強度をキーサイズだけで表現するのでは不十分な場合、アクセス権エントリで AlgorithmParameterSpec クラス名 (javax.crypto.spec.RC5ParameterSpec など)、および指定された AlgorithmParameterSpec オブジェクトの構築用パラメータリストも指定する必要があります。
アクセス権エントリの各項目は、指定された順序で記述する必要があります。各エントリはセミコロンで終わります。
識別子 (grant、permission) では大文字と小文字は区別されませんが、<crypto permission class name>、および値として引き渡される文字列では大文字と小文字が区別されます。
注:「*」は、すべてのアクセス権エントリオプションでワイルドカードとして使用できます。たとえば、<alg_name> オプションに「*」を指定すると、「すべてのアルゴリズム」という意味になります。
-
2 つのパーティー間の Diffie-Hellman 鍵交換
/*
* Copyright 1997-2001 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.
*/
import java.io.*;
import java.math.BigInteger;
import java.security.*;
import java.security.spec.*;
import java.security.interfaces.*;
import javax.crypto.*;
import javax.crypto.spec.*;
import javax.crypto.interfaces.*;
import com.sun.crypto.provider.SunJCE;
/**
* This program executes the Diffie-Hellman key agreement protocol
* between 2 parties: Alice and Bob.
*
* By default, preconfigured parameters (1024-bit prime modulus and base
* generator used by SKIP) are used.
* If this program is called with the "-gen" option, a new set of
* parameters is created.
*/
public class DHKeyAgreement2 {
private DHKeyAgreement2() {}
public static void main(String argv[]) {
try {
String mode = "USE_SKIP_DH_PARAMS";
DHKeyAgreement2 keyAgree = new DHKeyAgreement2();
if (argv.length > 1) {
keyAgree.usage();
throw new Exception("Wrong number of command options");
} else if (argv.length == 1) {
if (!(argv[0].equals("-gen"))) {
keyAgree.usage();
throw new Exception("Unrecognized flag: " + argv[0]);
}
mode = "GENERATE_DH_PARAMS";
}
keyAgree.run(mode);
} catch (Exception e) {
System.err.println("Error: " + e);
System.exit(1);
}
}
private void run(String mode) throws Exception {
DHParameterSpec dhSkipParamSpec;
if (mode.equals("GENERATE_DH_PARAMS")) {
// Some central authority creates new DH parameters
System.out.println
("Creating Diffie-Hellman parameters (takes VERY long) ...");
AlgorithmParameterGenerator paramGen
= AlgorithmParameterGenerator.getInstance("DH");
paramGen.init(512);
AlgorithmParameters params = paramGen.generateParameters();
dhSkipParamSpec = (DHParameterSpec)params.getParameterSpec
(DHParameterSpec.class);
} else {
// use some pre-generated, default DH parameters
System.out.println("Using SKIP Diffie-Hellman parameters");
dhSkipParamSpec = new DHParameterSpec(skip1024Modulus,
skip1024Base);
}
/*
* Alice creates her own DH key pair, using the DH parameters from
* above
*/
System.out.println("ALICE: Generate DH keypair ...");
KeyPairGenerator aliceKpairGen = KeyPairGenerator.getInstance("DH");
aliceKpairGen.initialize(dhSkipParamSpec);
KeyPair aliceKpair = aliceKpairGen.generateKeyPair();
// Alice creates and initializes her DH KeyAgreement object
System.out.println("ALICE: Initialization ...");
KeyAgreement aliceKeyAgree = KeyAgreement.getInstance("DH");
aliceKeyAgree.init(aliceKpair.getPrivate());
// Alice encodes her public key, and sends it over to Bob.
byte[] alicePubKeyEnc = aliceKpair.getPublic().getEncoded();
/*
* Let's turn over to Bob. Bob has received Alice's public key
* in encoded format.
* He instantiates a DH public key from the encoded key material.
*/
KeyFactory bobKeyFac = KeyFactory.getInstance("DH");
X509EncodedKeySpec x509KeySpec = new X509EncodedKeySpec
(alicePubKeyEnc);
PublicKey alicePubKey = bobKeyFac.generatePublic(x509KeySpec);
/*
* Bob gets the DH parameters associated with Alice's public key.
* He must use the same parameters when he generates his own key
* pair.
*/
DHParameterSpec dhParamSpec = ((DHPublicKey)alicePubKey).getParams();
// Bob creates his own DH key pair
System.out.println("BOB: Generate DH keypair ...");
KeyPairGenerator bobKpairGen = KeyPairGenerator.getInstance("DH");
bobKpairGen.initialize(dhParamSpec);
KeyPair bobKpair = bobKpairGen.generateKeyPair();
// Bob creates and initializes his DH KeyAgreement object
System.out.println("BOB: Initialization ...");
KeyAgreement bobKeyAgree = KeyAgreement.getInstance("DH");
bobKeyAgree.init(bobKpair.getPrivate());
// Bob encodes his public key, and sends it over to Alice.
byte[] bobPubKeyEnc = bobKpair.getPublic().getEncoded();
/*
* Alice uses Bob's public key for the first (and only) phase
* of her version of the DH
* protocol.
* Before she can do so, she has to instantiate a DH public key
* from Bob's encoded key material.
*/
KeyFactory aliceKeyFac = KeyFactory.getInstance("DH");
x509KeySpec = new X509EncodedKeySpec(bobPubKeyEnc);
PublicKey bobPubKey = aliceKeyFac.generatePublic(x509KeySpec);
System.out.println("ALICE: Execute PHASE1 ...");
aliceKeyAgree.doPhase(bobPubKey, true);
/*
* Bob uses Alice's public key for the first (and only) phase
* of his version of the DH
* protocol.
*/
System.out.println("BOB: Execute PHASE1 ...");
bobKeyAgree.doPhase(alicePubKey, true);
/*
* At this stage, both Alice and Bob have completed the DH key
* agreement protocol.
* Both generate the (same) shared secret.
*/
byte[] aliceSharedSecret = aliceKeyAgree.generateSecret();
int aliceLen = aliceSharedSecret.length;
byte[] bobSharedSecret = new byte[aliceLen];
int bobLen;
try {
// show example of what happens if you
// provide an output buffer that is too short
bobLen = bobKeyAgree.generateSecret(bobSharedSecret, 1);
} catch (ShortBufferException e) {
System.out.println(e.getMessage());
}
// provide output buffer of required size
bobLen = bobKeyAgree.generateSecret(bobSharedSecret, 0);
System.out.println("Alice secret: " +
toHexString(aliceSharedSecret));
System.out.println("Bob secret: " +
toHexString(bobSharedSecret));
if (!java.util.Arrays.equals(aliceSharedSecret, bobSharedSecret))
throw new Exception("Shared secrets differ");
System.out.println("Shared secrets are the same");
/*
* Now let's return the shared secret as a SecretKey object
* and use it for encryption. First, we generate SecretKeys for the
* "DES" algorithm (based on the raw shared secret data) and
* then we use DES in ECB mode
* as the encryption algorithm. DES in ECB mode does not require any
* parameters.
*
* Then we use DES in CBC mode, which requires an initialization
* vector (IV) parameter. In CBC mode, you need to initialize the
* Cipher object with an IV, which can be supplied using the
* javax.crypto.spec.IvParameterSpec class. Note that you have to use
* the same IV for encryption and decryption: If you use a different
* IV for decryption than you used for encryption, decryption will
* fail.
*
* NOTE: If you do not specify an IV when you initialize the
* Cipher object for encryption, the underlying implementation
* will generate a random one, which you have to retrieve using the
* javax.crypto.Cipher.getParameters() method, which returns an
* instance of java.security.AlgorithmParameters. You need to transfer
* the contents of that object (e.g., in encoded format, obtained via
* the AlgorithmParameters.getEncoded() method) to the party who will
* do the decryption. When initializing the Cipher for decryption,
* the (reinstantiated) AlgorithmParameters object must be passed to
* the Cipher.init() method.
*/
System.out.println("Return shared secret as SecretKey object ...");
// Bob
// NOTE: The call to bobKeyAgree.generateSecret above reset the key
// agreement object, so we call doPhase again prior to another
// generateSecret call
bobKeyAgree.doPhase(alicePubKey, true);
SecretKey bobDesKey = bobKeyAgree.generateSecret("DES");
// Alice
// NOTE: The call to aliceKeyAgree.generateSecret above reset the key
// agreement object, so we call doPhase again prior to another
// generateSecret call
aliceKeyAgree.doPhase(bobPubKey, true);
SecretKey aliceDesKey = aliceKeyAgree.generateSecret("DES");
/*
* Bob encrypts, using DES in ECB mode
*/
Cipher bobCipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
bobCipher.init(Cipher.ENCRYPT_MODE, bobDesKey);
byte[] cleartext = "This is just an example".getBytes();
byte[] ciphertext = bobCipher.doFinal(cleartext);
/*
* Alice decrypts, using DES in ECB mode
*/
Cipher aliceCipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
aliceCipher.init(Cipher.DECRYPT_MODE, aliceDesKey);
byte[] recovered = aliceCipher.doFinal(ciphertext);
if (!java.util.Arrays.equals(cleartext, recovered))
throw new Exception("DES in CBC mode recovered text is " +
"different from cleartext");
System.out.println("DES in ECB mode recovered text is " +
"same as cleartext");
/*
* Bob encrypts, using DES in CBC mode
*/
bobCipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
bobCipher.init(Cipher.ENCRYPT_MODE, bobDesKey);
cleartext = "This is just an example".getBytes();
ciphertext = bobCipher.doFinal(cleartext);
// Retrieve the parameter that was used, and transfer it to Alice in
// encoded format
byte[] encodedParams = bobCipher.getParameters().getEncoded();
/*
* Alice decrypts, using DES in CBC mode
*/
// Instantiate AlgorithmParameters object from parameter encoding
// obtained from Bob
AlgorithmParameters params = AlgorithmParameters.getInstance("DES");
params.init(encodedParams);
aliceCipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
aliceCipher.init(Cipher.DECRYPT_MODE, aliceDesKey, params);
recovered = aliceCipher.doFinal(ciphertext);
if (!java.util.Arrays.equals(cleartext, recovered))
throw new Exception("DES in CBC mode recovered text is " +
"different from cleartext");
System.out.println("DES in CBC mode recovered text is " +
"same as cleartext");
}
/*
* Converts a byte to hex digit and writes to the supplied buffer
*/
private void byte2hex(byte b, StringBuffer buf) {
char[] hexChars = { '0', '1', '2', '3', '4', '5', '6', '7', '8',
'9', 'A', 'B', 'C', 'D', 'E', 'F' };
int high = ((b & 0xf0) >> 4);
int low = (b & 0x0f);
buf.append(hexChars[high]);
buf.append(hexChars[low]);
}
/*
* Converts a byte array to hex string
*/
private String toHexString(byte[] block) {
StringBuffer buf = new StringBuffer();
int len = block.length;
for (int i = 0; i < len; i++) {
byte2hex(block[i], buf);
if (i < len-1) {
buf.append(":");
}
}
return buf.toString();
}
/*
* Prints the usage of this test.
*/
private void usage() {
System.err.print("DHKeyAgreement usage: ");
System.err.println("[-gen]");
}
// The 1024 bit Diffie-Hellman modulus values used by SKIP
private static final byte skip1024ModulusBytes[] = {
(byte)0xF4, (byte)0x88, (byte)0xFD, (byte)0x58,
(byte)0x4E, (byte)0x49, (byte)0xDB, (byte)0xCD,
(byte)0x20, (byte)0xB4, (byte)0x9D, (byte)0xE4,
(byte)0x91, (byte)0x07, (byte)0x36, (byte)0x6B,
(byte)0x33, (byte)0x6C, (byte)0x38, (byte)0x0D,
(byte)0x45, (byte)0x1D, (byte)0x0F, (byte)0x7C,
(byte)0x88, (byte)0xB3, (byte)0x1C, (byte)0x7C,
(byte)0x5B, (byte)0x2D, (byte)0x8E, (byte)0xF6,
(byte)0xF3, (byte)0xC9, (byte)0x23, (byte)0xC0,
(byte)0x43, (byte)0xF0, (byte)0xA5, (byte)0x5B,
(byte)0x18, (byte)0x8D, (byte)0x8E, (byte)0xBB,
(byte)0x55, (byte)0x8C, (byte)0xB8, (byte)0x5D,
(byte)0x38, (byte)0xD3, (byte)0x34, (byte)0xFD,
(byte)0x7C, (byte)0x17, (byte)0x57, (byte)0x43,
(byte)0xA3, (byte)0x1D, (byte)0x18, (byte)0x6C,
(byte)0xDE, (byte)0x33, (byte)0x21, (byte)0x2C,
(byte)0xB5, (byte)0x2A, (byte)0xFF, (byte)0x3C,
(byte)0xE1, (byte)0xB1, (byte)0x29, (byte)0x40,
(byte)0x18, (byte)0x11, (byte)0x8D, (byte)0x7C,
(byte)0x84, (byte)0xA7, (byte)0x0A, (byte)0x72,
(byte)0xD6, (byte)0x86, (byte)0xC4, (byte)0x03,
(byte)0x19, (byte)0xC8, (byte)0x07, (byte)0x29,
(byte)0x7A, (byte)0xCA, (byte)0x95, (byte)0x0C,
(byte)0xD9, (byte)0x96, (byte)0x9F, (byte)0xAB,
(byte)0xD0, (byte)0x0A, (byte)0x50, (byte)0x9B,
(byte)0x02, (byte)0x46, (byte)0xD3, (byte)0x08,
(byte)0x3D, (byte)0x66, (byte)0xA4, (byte)0x5D,
(byte)0x41, (byte)0x9F, (byte)0x9C, (byte)0x7C,
(byte)0xBD, (byte)0x89, (byte)0x4B, (byte)0x22,
(byte)0x19, (byte)0x26, (byte)0xBA, (byte)0xAB,
(byte)0xA2, (byte)0x5E, (byte)0xC3, (byte)0x55,
(byte)0xE9, (byte)0x2F, (byte)0x78, (byte)0xC7
};
// The SKIP 1024 bit modulus
private static final BigInteger skip1024Modulus
= new BigInteger(1, skip1024ModulusBytes);
// The base used with the SKIP 1024 bit modulus
private static final BigInteger skip1024Base = BigInteger.valueOf(2);
}
-
3 つのパーティー間の Diffie-Hellman 鍵交換
/*
* Copyright 1997-2001 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.
*/
import java.io.*;
import java.math.BigInteger;
import java.security.*;
import java.security.spec.*;
import java.security.interfaces.*;
import javax.crypto.*;
import javax.crypto.spec.*;
import javax.crypto.interfaces.*;
import com.sun.crypto.provider.SunJCE;
/**
* This program executes the Diffie-Hellman key agreement protocol
* between 3 parties: Alice, Bob, and Carol.
*
* We use the same 1024-bit prime modulus and base generator that are
* used by SKIP.
*/
public class DHKeyAgreement3 {
private DHKeyAgreement3() {}
public static void main(String argv[]) {
try {
DHKeyAgreement3 keyAgree = new DHKeyAgreement3();
keyAgree.run();
} catch (Exception e) {
System.err.println("Error: " + e);
System.exit(1);
}
}
private void run() throws Exception {
DHParameterSpec dhSkipParamSpec;
System.out.println("Using SKIP Diffie-Hellman parameters");
dhSkipParamSpec = new DHParameterSpec(skip1024Modulus, skip1024Base);
// Alice creates her own DH key pair
System.out.println("ALICE: Generate DH keypair ...");
KeyPairGenerator aliceKpairGen = KeyPairGenerator.getInstance("DH");
aliceKpairGen.initialize(dhSkipParamSpec);
KeyPair aliceKpair = aliceKpairGen.generateKeyPair();
// Bob creates his own DH key pair
System.out.println("BOB: Generate DH keypair ...");
KeyPairGenerator bobKpairGen = KeyPairGenerator.getInstance("DH");
bobKpairGen.initialize(dhSkipParamSpec);
KeyPair bobKpair = bobKpairGen.generateKeyPair();
// Carol creates her own DH key pair
System.out.println("CAROL: Generate DH keypair ...");
KeyPairGenerator carolKpairGen = KeyPairGenerator.getInstance("DH");
carolKpairGen.initialize(dhSkipParamSpec);
KeyPair carolKpair = carolKpairGen.generateKeyPair();
// Alice initialize
System.out.println("ALICE: Initialize ...");
KeyAgreement aliceKeyAgree = KeyAgreement.getInstance("DH");
aliceKeyAgree.init(aliceKpair.getPrivate());
// Bob initialize
System.out.println("BOB: Initialize ...");
KeyAgreement bobKeyAgree = KeyAgreement.getInstance("DH");
bobKeyAgree.init(bobKpair.getPrivate());
// Carol initialize
System.out.println("CAROL: Initialize ...");
KeyAgreement carolKeyAgree = KeyAgreement.getInstance("DH");
carolKeyAgree.init(carolKpair.getPrivate());
// Alice uses Carol's public key
Key ac = aliceKeyAgree.doPhase(carolKpair.getPublic(), false);
// Bob uses Alice's public key
Key ba = bobKeyAgree.doPhase(aliceKpair.getPublic(), false);
// Carol uses Bob's public key
Key cb = carolKeyAgree.doPhase(bobKpair.getPublic(), false);
// Alice uses Carol's result from above
aliceKeyAgree.doPhase(cb, true);
// Bob uses Alice's result from above
bobKeyAgree.doPhase(ac, true);
// Carol uses Bob's result from above
carolKeyAgree.doPhase(ba, true);
// Alice, Bob and Carol compute their secrets
byte[] aliceSharedSecret = aliceKeyAgree.generateSecret();
System.out.println("Alice secret: " + toHexString(aliceSharedSecret));
byte[] bobSharedSecret = bobKeyAgree.generateSecret();
System.out.println("Bob secret: " + toHexString(bobSharedSecret));
byte[] carolSharedSecret = carolKeyAgree.generateSecret();
System.out.println("Carol secret: " + toHexString(carolSharedSecret));
// Compare Alice and Bob
if (!java.util.Arrays.equals(aliceSharedSecret, bobSharedSecret))
throw new Exception("Alice and Bob differ");
System.out.println("Alice and Bob are the same");
// Compare Bob and Carol
if (!java.util.Arrays.equals(bobSharedSecret, carolSharedSecret))
throw new Exception("Bob and Carol differ");
System.out.println("Bob and Carol are the same");
}
/*
* Converts a byte to hex digit and writes to the supplied buffer
*/
private void byte2hex(byte b, StringBuffer buf) {
char[] hexChars = { '0', '1', '2', '3', '4', '5', '6', '7', '8',
'9', 'A', 'B', 'C', 'D', 'E', 'F' };
int high = ((b & 0xf0) >> 4);
int low = (b & 0x0f);
buf.append(hexChars[high]);
buf.append(hexChars[low]);
}
/*
* Converts a byte array to hex string
*/
private String toHexString(byte[] block) {
StringBuffer buf = new StringBuffer();
int len = block.length;
for (int i = 0; i < len; i++) {
byte2hex(block[i], buf);
if (i < len-1) {
buf.append(":");
}
}
return buf.toString();
}
/*
* Prints the usage of this test.
*/
private void usage() {
System.err.print("DHKeyAgreement usage: ");
System.err.println("[-gen]");
}
// The 1024 bit Diffie-Hellman modulus values used by SKIP
private static final byte skip1024ModulusBytes[] = {
(byte)0xF4, (byte)0x88, (byte)0xFD, (byte)0x58,
(byte)0x4E, (byte)0x49, (byte)0xDB, (byte)0xCD,
(byte)0x20, (byte)0xB4, (byte)0x9D, (byte)0xE4,
(byte)0x91, (byte)0x07, (byte)0x36, (byte)0x6B,
(byte)0x33, (byte)0x6C, (byte)0x38, (byte)0x0D,
(byte)0x45, (byte)0x1D, (byte)0x0F, (byte)0x7C,
(byte)0x88, (byte)0xB3, (byte)0x1C, (byte)0x7C,
(byte)0x5B, (byte)0x2D, (byte)0x8E, (byte)0xF6,
(byte)0xF3, (byte)0xC9, (byte)0x23, (byte)0xC0,
(byte)0x43, (byte)0xF0, (byte)0xA5, (byte)0x5B,
(byte)0x18, (byte)0x8D, (byte)0x8E, (byte)0xBB,
(byte)0x55, (byte)0x8C, (byte)0xB8, (byte)0x5D,
(byte)0x38, (byte)0xD3, (byte)0x34, (byte)0xFD,
(byte)0x7C, (byte)0x17, (byte)0x57, (byte)0x43,
(byte)0xA3, (byte)0x1D, (byte)0x18, (byte)0x6C,
(byte)0xDE, (byte)0x33, (byte)0x21, (byte)0x2C,
(byte)0xB5, (byte)0x2A, (byte)0xFF, (byte)0x3C,
(byte)0xE1, (byte)0xB1, (byte)0x29, (byte)0x40,
(byte)0x18, (byte)0x11, (byte)0x8D, (byte)0x7C,
(byte)0x84, (byte)0xA7, (byte)0x0A, (byte)0x72,
(byte)0xD6, (byte)0x86, (byte)0xC4, (byte)0x03,
(byte)0x19, (byte)0xC8, (byte)0x07, (byte)0x29,
(byte)0x7A, (byte)0xCA, (byte)0x95, (byte)0x0C,
(byte)0xD9, (byte)0x96, (byte)0x9F, (byte)0xAB,
(byte)0xD0, (byte)0x0A, (byte)0x50, (byte)0x9B,
(byte)0x02, (byte)0x46, (byte)0xD3, (byte)0x08,
(byte)0x3D, (byte)0x66, (byte)0xA4, (byte)0x5D,
(byte)0x41, (byte)0x9F, (byte)0x9C, (byte)0x7C,
(byte)0xBD, (byte)0x89, (byte)0x4B, (byte)0x22,
(byte)0x19, (byte)0x26, (byte)0xBA, (byte)0xAB,
(byte)0xA2, (byte)0x5E, (byte)0xC3, (byte)0x55,
(byte)0xE9, (byte)0x2F, (byte)0x78, (byte)0xC7
};
// The SKIP 1024 bit modulus
private static final BigInteger skip1024Modulus
= new BigInteger(1, skip1024ModulusBytes);
// The base used with the SKIP 1024 bit modulus
private static final BigInteger skip1024Base = BigInteger.valueOf(2);
}
-
Blowfish 暗号の例
/*
* Copyright 1997-2001 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.
*/
import java.security.*;
import javax.crypto.*;
import javax.crypto.spec.*;
/**
* This program generates a Blowfish key, retrieves its raw bytes, and
* then reinstantiates a Blowfish key from the key bytes.
* The reinstantiated key is used to initialize a Blowfish cipher for
* encryption.
*/
public class BlowfishKey {
public static void main(String[] args) throws Exception {
KeyGenerator kgen = KeyGenerator.getInstance("Blowfish");
SecretKey skey = kgen.generateKey();
byte[] raw = skey.getEncoded();
SecretKeySpec skeySpec = new SecretKeySpec(raw, "Blowfish");
Cipher cipher = Cipher.getInstance("Blowfish");
cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
byte[] encrypted =
cipher.doFinal("This is just an example".getBytes());
}
}
-
HMAC-MD5 の例
/*
* Copyright 1997-2001 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.
*/
import java.security.*;
import javax.crypto.*;
/**
* This program demonstrates how to generate a secret-key object for
* HMAC-MD5, and initialize an HMAC-MD5 object with it.
*/
public class initMac {
public static void main(String[] args) throws Exception {
// Generate secret key for HMAC-MD5
KeyGenerator kg = KeyGenerator.getInstance("HmacMD5");
SecretKey sk = kg.generateKey();
// Get instance of Mac object implementing HMAC-MD5, and
// initialize it with the above secret key
Mac mac = Mac.getInstance("HmacMD5");
mac.init(sk);
byte[] result = mac.doFinal("Hi There".getBytes());
}
}
-
InputStream から ASCII パスワードを読み取る例
/*
* @(#)ReadPassword.java 1.1 06/06/07
*
* Copyright 2006 Sun Microsystems, Inc. All rights reserved.
* SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
*/
import java.util.*;
import java.io.*;
import java.security.*;
public class ReadPassword {
/**
* Read a password from the InputStream "in".
* <p>
* As Strings are immutable, passwords should be stored as an array
* of characters, which can be blanked out when no longer needed.
* <p>
* If the provided InputStream is the System's Console, this method
* uses the non-echoing readPassword() method of java.io.Console
* (new to JDK 6). If not, a fallback implementation is used.
* <p>
* NOTE: For expository purposes, and because some applications do
* not understand multi-byte characters, only 8-bit ASCII passwords
* are handled here.
* <p>
* NOTE: If a SecurityManager is used, the default standard
* java.policy file found in Sun's JDK (i.e.
* /lib/security/java.policy) allows reading the
* line.separator property. If your environment is different, this
* code will need to be granted the appropriate privilege.
*
* @param in
* the InputStream used to obtain the password.
*
* @return A character array containing the password or passphrase,
* not including the line-termination characters,
* or null if an end of stream has been reached.
*
* @throws IOException
* if an I/O problem occurs
*/
public static final char[] readPassword(InputStream in)
throws IOException {
/*
* If available, directly use the java.io.Console class to
* avoid character echoing.
*/
if (in == System.in && System.console() != null) {
// readPassword returns "" if you just print ENTER,
return System.console().readPassword();
}
/*
* If a console is not available, read the InputStream
* directly. This approach may cause password echoing.
*
* Since different operating systems have different End-Of-Line
* (EOL) sequences, this algorithm should allow for
* platform-independent implementations. Typical EOL sequences
* are a single line feed ('\n'), or a carriage return/linefeed
* combination ('\r\n'). However, some OS's use a single
* a carriage return ('\r'), which complicates portability.
*
* Since we may not have the ability to push bytes back into the
* InputStream, another approach is used here. The javadoc for
* java.lang.System.getProperties() specifies that
* the set of system properties will contain a system-specific
* value for the "line.separator". Scan for this character
* sequence instead of hard-coding a particular sequence.
*/
/*
* Enclose the getProperty in a doPrivileged block to minimize
* the call stack permission required.
*/
char [] EOL = AccessController.doPrivileged(
new PrivilegedAction() {
public char[] run() {
String s = System.getProperty("line.separator");
// Shouldn't happen.
if (s == null) {
throw new RuntimeException(
"line.separator not defined");
}
return s.toCharArray();
}
});
char [] buffer = new char[128];
try {
int len = 0; // len of data in buffer.
boolean done = false; // found the EOL sequence
int b; // byte read
while (!done) {
/*
* realloc if necessary
*/
if (len >= buffer.length) {
char [] newbuffer = new char[len + 128];
System.arraycopy(buffer, 0, newbuffer, 0, len);
Arrays.fill(buffer, ' ');
buffer = newbuffer;
}
/*
* End-of-Stream?
*/
if ((b = in.read()) == -1) {
// Return as much as we have, null otherwise.
if (len == 0) {
return null;
}
break;
} else {
/*
* NOTE: In the simple PBE example here,
* only 8 bit ASCII characters are handled.
*/
buffer[len++] = (char) b;
}
/*
* check for the EOL sequence. Do we have enough bytes?
*/
if (len >= EOL.length) {
int i = 0;
for (i = 0; i < EOL.length; i++) {
if (buffer[len - EOL.length + i] != EOL[i]) {
break;
}
}
done = (i == EOL.length);
}
}
/*
* If we found the EOL, strip the EOL chars.
*/
char [] result = new char[done ? len - EOL.length : len];
System.arraycopy(buffer, 0, result, 0, result.length);
return result;
} finally {
/*
* Zero out the buffer.
*/
if (buffer != null) {
Arrays.fill(buffer, ' ');
}
}
}
}