JCE SDK の既知の問題

問題: 非対称キーペアを使用する場合、明示的にキーを作成またはインポートしない場合でも、キー容量が占有されます。

• 影響: この問題により、HSM が予期せずキー領域を使い果たすことがあります。この問題は、アプリケーションが暗号化オペレーションに CaviumKey オブジェクトではなく標準の JCE キーオブジェクトを使用する場合に発生します。標準の JCE キーオブジェクトを使用する場合、CaviumProvider によって暗黙的にそのキーが HSM にインポートされ、アプリケーションが終了するまでセッションキーによってこのキーは削除されません。その結果、アプリケーションの実行中にキーが蓄積され、HSM の空きキー領域が不足して、アプリケーションがフリーズする可能性があります。

• 回避策: CaviumSignature クラス、CaviumCipher クラス、CaviumMac クラス、または CaviumKeyAgreement クラスを使用する場合は、標準の JCE キーオブジェクトではなく CaviumKey としてキーを指定してください。

  CaviumKey クラスを使用して通常のキーを ImportKey に手動で変更し、オペレーションの完了後にキーを手動で削除できます。

• 解決策のステータス: 暗黙的なインポートを適切に管理するために、CaviumProvider を更新中です。修正は、利用可能なバージョン履歴ページで告知されます。

問題: JCE KeyStore は読み取り専用です

• 影響: 現在、HSM でサポートされていないオブジェクトタイプを JCE KeyStore に保存することはできません。具体的には、キーストアに証明書を保存することはできません。これにより、キーストア内で証明書を見つけることを期待する jarsigner などのツールとの相互運用性が妨げられます。

• [Workaround(回避策)]: キーストアではなく、ローカルファイルまたは S3 バケットの場所から証明書をロードするようにコードを修正することができます。

• [Resolution status( 解決策のステータス )]: キーストアに証明書ストレージのサポートを追加しています。機能は、利用可能なバージョン履歴ページで告知されます。

問題: AES-GCM 暗号化のバッファが 16,000 バイトを超えることはできません

マルチパート AES-GCM 暗号化は対応していません。

• 影響 : AES-GCM を使用して 16,000 バイトを超えるデータを暗号化することができません。

• 回避策: AES-CBC などの代替メカニズムを使用するか、データを複数部分に分割して各部分を別々に暗号化できます。データを分割する場合、分割された暗号化テキストとその復号化を管理する必要があります。FIPS では AES-GCM の初期化ベクター (IV) を HSM で生成する必要があるため、AES-GCM で暗号化された部分的データはそれぞれ IV が異なります。

• 解決策のステータス: SDK を修正し、データバッファが大きすぎる場合は明示的に失敗するようにします。マルチパート暗号化を使用しなくても大きいバッファをサポートできる代替方法を評価しています。更新は AWS CloudHSM フォーラムとバージョン履歴ページで告知されます。

問題: 楕円曲線ディフィーヘルマン (ECDH) キーの導出が、HSM 内で部分的に実行されます

EC プライベートキーは常に HSM にありますが、キーの取得手順は複数のステップで実行されます。その結果、各ステップの中間結果がクライアントに存在します。ECDH キー導出サンプルは Java コードサンプルで入手できます。

• 影響: Client SDK 3 は ECDH 機能を JCE に追加します。KeyAgreement クラスを使用して を取得すると SecretKey、まずクライアントで使用でき、次に HSM にインポートされます。その後、キーのハンドルがアプリケーションに返されます。

• 回避策: で SSL/TLS オフロードを実装している場合 AWS CloudHSM、この制限は問題にならない可能性があります。アプリケーションでキーが常に FIPS 境界内に留まる必要がある場合、ECDH キー取得に依存しない代替プロトコルの使用を検討してください。

• 解決策のステータス: ECDH キー取得を完全に HSM 内部で実行するオプションを開発中です。利用可能な場合は、バージョン履歴ページで更新された実装をお知らせします。

問題: KeyGenerator キーサイズパラメータをビット数ではなくバイト数として KeyAttribute 誤って解釈する

KeyGenerator クラスの init関数または列挙型 の SIZE 属性を使用してキーを生成する場合、API は 引数がキービット数であるべきときに、誤ってキーバイト数であると想定します。 AWS CloudHSM KeyAttribute

• 影響: Client SDK バージョン 5.4.0～5.4.2 では、指定した API にキーサイズがバイトとして提供されることを誤って想定しています。

• 回避策: Client SDK バージョン 5.4.0 から 5.4.2 を使用している場合、 KeyGenerator クラスまたは KeyAttribute 列挙型を使用して AWS CloudHSM JCE プロバイダーを使用してキーを生成する前に、キーサイズをビットからバイトに変換します。

• 解決ステータス: クライアント SDK バージョンを 5.5.0 以降にアップグレードします。これには、 KeyGenerator クラスまたは KeyAttribute 列挙型を使用してキーを生成するときに、ビット単位でキーサイズを正しく想定する修正が含まれています。

問題: Client SDK 5 から「不正な反射アクセスオペレーションが発生しました」という警告が表示されます

Java 11 で Client SDK 5 を使用すると、CloudHSM から次の Java 警告が表示されます。

```
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore (file:/opt/cloudhsm/java/cloudhsm-jce-5.6.0.jar) to field java.security .KeyStore.keyStoreSpi
WARNING: Please consider reporting this to the maintainers of com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
```

これらの警告は影響しません。この問題は認識済みであり、現在、問題の解決に取り組んでいます。解決策も回避策も必要ありません。

問題: JCE セッションプールが使い果たされています

影響: 次のメッセージが表示されると、JCE で操作を実行できなくなる可能性があります。

com.amazonaws.cloudhsm.jce.jni.exception.InternalException: There are too many operations 
happening at the same time: Reached max number of sessions in session pool: 1000

回避方法:

• 影響が出ている場合は、JCE アプリケーションを再起動してください。

• オペレーションを実行する場合、オペレーションへの参照が失われる前に JCE オペレーションを完了する必要がある場合があります。

  注記

  オペレーションによっては、完了方法が必要な場合があります。

  操作	完了方法
  暗号	暗号化モードまたは復号モードの doFinal() ラップモードの wrap() アンラップモードの unwrap()
  KeyAgreement	generateSecret() または generateSecret(String)
  KeyPairGenerator	generateKeyPair()、genKeyPair()、または reset()
  KeyStore	メソッド不要
  MAC	doFinal() または reset()
  MessageDigest	digest() または reset()
  SecretKeyFactory	メソッド不要
  SecureRandom	メソッド不要
  署名	サインモードの sign() 検証モードの verify()

解決策のステータス: この問題は、Client SDK 5.9.0 以降で解決に向けて積極的に取り組んでいます。この問題を解決するには、Client SDK を以下のバージョンのいずれかにアップグレードしてください。

問題: getKey オペレーションによるクライアント SDK 5 メモリリーク

• 影響: API getKeyオペレーションでは、クライアント SDK バージョン 5.10.0 以前の JCE でメモリリークが発生しています。アプリケーションで getKey API を複数回使用すると、メモリが増加し、その結果、アプリケーションのメモリフットプリントが増加します。時間が経つと、スロットリングエラーが発生したり、アプリケーションを再起動する必要がある場合があります。

• 回避策: Client SDK 5.11.0 にアップグレードすることをお勧めします。これを実行できない場合は、アプリケーションで getKey API を複数回呼び出さないことをお勧めします。代わりに、前のgetKeyオペレーションから以前に返されたキーを可能な限り再利用します。

• 解決ステータス: クライアント SDK バージョンを 5.11.0 以降にアップグレードします。これには、この問題の修正が含まれています。