

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# すべての HSM インスタンスの既知の問題
<a name="ki-all"></a>

以下の問題は、key\_mgmt\_util コマンドラインツール、PKCS \#11 SDK、JCE SDK、OpenSSL SDK のいずれを使用しているかにかかわらず、すべての AWS CloudHSM ユーザーに影響します。

**Topics**
+ [[問題]: AESキーラッピングでは、ゼロパディング付きのキーラップのスタンダード準拠の実装を提供する代わりに、PKCS\#5 パディングを使用します](#ki-all-1)
+ [問題: クライアントデーモンがクラスターに正常に接続には、その設定ファイル少なくとも 1 つの有効な IP アドレスが必要です](#ki-all-2)
+ [問題: クライアント SDK 3 AWS CloudHSM を使用してハッシュおよび署名できるデータには 16 KB の上限がありました](#ki-all-3)
+ [問題: インポートされたキーをエクスポート不可として指定できませんでした](#ki-all-4)
+ [問題: key\_mgmt\_util の wrapKey コマンドと unWrapKey コマンドのデフォルトのメカニズムが削除されました](#ki-all-5)
+ [問題: クラスターに HSM が 1 つしかない場合、HSM フェイルオーバーが正しく動作しません](#ki-all-6)
+ [問題: クラスター内の HSM のキー容量を短期間で超えた場合、クライアントが処理されないエラー状態に陥ります](#ki-all-7)
+ [問題: 800 バイトを超える HMAC キーを使ったダイジェストオペレーションはサポートされていません](#ki-all-8)
+ [問題 : クライアント SDK 3 で配布された client\_info ツールが、オプションの出力引数で指定されたパスの内容を削除します](#ki-all-9)
+ [問題: コンテナ化された環境で `--cluster-id` 引数を使用して SDK 5 設定ツールを実行すると、エラーが表示されます](#ki-all-10)
+ [問題: 「指定された pfx ファイルから証明書/キーを作成できませんでした。エラー: NotPkcs8」という内容のエラーが表示されます。](#ki-all-11)
+ [問題: SDK 5.16 以降で ECDSA 署名が「無効なメカニズム」エラーで失敗する](#ki-all-12)
+ [問題: 事前にハッシュ化されたデータで署名オペレーションを行うと、インタラクティブモードでセッショントークンが正しくクリアされない](#ki-all-13)
+ [問題: CloudHSM クライアントライブラリのデフォルトのクライアント証明書が 2026 年 1 月 31 日に期限切れになる](#ki-all-14)

## [問題]: AESキーラッピングでは、ゼロパディング付きのキーラップのスタンダード準拠の実装を提供する代わりに、PKCS\#5 パディングを使用します
<a name="ki-all-1"></a>

さらに、パディングなしおよびゼロパディングありのキーラップはサポートされていません。
+ **影響: **このアルゴリズムを使用してラップおよびラップ解除しても影響はありません AWS CloudHSM。ただし、 でラップされたキーは、ページングなし仕様への準拠を期待する他の HSMs またはソフトウェア内でラップ解除 AWS CloudHSM することはできません。これは、標準に準拠したラップ解除中に、8 バイトのパディングデータがキーデータの最後に追加される可能性があるためです。外部ラップされたキーを AWS CloudHSM インスタンスに適切にラップ解除することはできません。
+ **回避策: **AWS CloudHSM インスタンスで PKCS \#5 パディングありの AES キーラップを使用してラップされたキーを外部でラップ解除するには、キーを使用する前に余分なパディングを省きます。これを行うには、ファイルエディターで余分なバイトをトリミングするか、コード内の新しいバッファにキーバイトだけをコピーします。
+ **解決策のステータス: **3.1.0 クライアントおよびソフトウェアリリースで、 AWS CloudHSM に AES キーラップの標準に準拠したオプションが用意されています。詳細については、「[AES キーラップ](manage-aes-key-wrapping.md)」を参照してください。

## 問題: クライアントデーモンがクラスターに正常に接続には、その設定ファイル少なくとも 1 つの有効な IP アドレスが必要です
<a name="ki-all-2"></a>
+ **影響: **クラスター内のすべての HSM を削除し、新しい IP アドレスを取得する別の HSM を追加した場合、クライアントデーモンは元の IP アドレスで HSM を検索し続けます。
+ **解決策:** 断続的なワークロードを実行する場合、[CreateHsm](https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_CreateHsm.html) の関数で `IpAddress` 引数を使用して Elastic Network Interface (ENI) を元の値に設定することをお勧めします。ENI はアベイラビリティーゾーン (AZ) に固有である点に注意してください。代わりに、`/opt/cloudhsm/daemon/1/cluster.info` ファイルを削除した後、新しい HSM クライアントの IP アドレスにクライアント設定をリセットできます。`client -a {{<IP address>}}` コマンドを使用できます。詳細については、「 [クライアントのインストールと設定 (Linux)」または AWS CloudHSM](cmu-install-and-configure-client-linux.md)「 [AWS CloudHSM クライアントのインストールと設定 (Windows)](cmu-install-and-configure-client-win.md)」を参照してください。

## 問題: クライアント SDK 3 AWS CloudHSM を使用してハッシュおよび署名できるデータには 16 KB の上限がありました
<a name="ki-all-3"></a>
+ **解決策のステータス:** サイズが 16 KB 未満のデータは、ハッシュ用に引き続き HSM に送信されます。16～64 KB のサイズのデータをローカルやソフトウェアでハッシュする機能が追加されました。データバッファが 64 KB を超える場合、クライアント SDK 5 は明示的に失敗します。この修正を適用するには、クライアントと SDK を 5.0.0 より新しいバージョンに更新する必要があります。

## 問題: インポートされたキーをエクスポート不可として指定できませんでした
<a name="ki-all-4"></a>
+ **解決策のステータス:** この問題は修正されています。修正を反映させるためにお客様側で必要なアクションはありません。

## 問題: key\_mgmt\_util の wrapKey コマンドと unWrapKey コマンドのデフォルトのメカニズムが削除されました
<a name="ki-all-5"></a>
+ **解決策: **wrapKey コマンドまたは unWrapKey コマンドを使用する場合は、`-m` オプションを使用してメカニズムを指定する必要があります。詳細については、[wrapKey](key_mgmt_util-wrapKey.md) または [unWrapKey](key_mgmt_util-unwrapKey.md) の記事の例を参照してください。

## 問題: クラスターに HSM が 1 つしかない場合、HSM フェイルオーバーが正しく動作しません
<a name="ki-all-6"></a>
+ **影響: **クラスター内に 1 つしかない HSM インスタンスの接続が失われると、後で回復しても、クライアントはインスタンスに再接続しません。
+ **回避方法: **本番稼働用クラスターに少なくとも 2 つの HSM インスタンスを用意することをお勧めします。この構成を使用すれば、この問題の影響を受けません。HSM が 1 つしかないクラスターの場合、クライアントデーモンをバウンスして接続を復元します。
+ **解決策のステータス: ** この問題は、 AWS CloudHSM クライアント 1.1.2 のリリースで解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

## 問題: クラスター内の HSM のキー容量を短期間で超えた場合、クライアントが処理されないエラー状態に陥ります
<a name="ki-all-7"></a>
+ **影響: ** クライアントが処理されないエラー状態になると、フリーズし、再起動が必要になります。
+ **回避方法: **スループットをテストして、クライアントが処理できない速さでセッションキーを作成していないか、確認します。速さを落とすには、クラスターに HSM を追加するか、セッションキーの作成を遅くします。
+ **解決策のステータス: ** この問題は、 AWS CloudHSM クライアント 1.1.2 のリリースで解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

## 問題: 800 バイトを超える HMAC キーを使ったダイジェストオペレーションはサポートされていません
<a name="ki-all-8"></a>
+ **影響:** 800 バイトを上回る HMAC キーが HSM で生成されたり、HSM にインポートされたりする可能性があります。ただし、このような大きなキーを JCE または key\_mgmt\_util を介してダイジェストオペレーションに使用すると、オペレーションが失敗します。PKCS11 を使用している場合、HMAC キーのサイズは 64 バイトに制限されます。
+ **回避方法: **HSM のダイジェストオペレーションに HMAC キーを使用する場合は、必ずサイズが 800 バイト以下のものを使用します。
+ **解決策のステータス: **現時点ではありません。

## 問題 : クライアント SDK 3 で配布された client\_info ツールが、オプションの出力引数で指定されたパスの内容を削除します
<a name="ki-all-9"></a>
+ **影響:** 指定した出力パスの下にある既存のファイルとサブディレクトリはすべて、永久に失われる可能性があります
+ **防止策:** `-output {{path}}` ツールを使用する際、オプションの引数 `client_info` を使用しないでください。
+ **解決策の現状:** この問題は、[クライアント SDK 3.3.2 のリリース](https://docs.aws.amazon.com/cloudhsm/latest/userguide/client-history.html#client-version-3-3-2) によって解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

## 問題: コンテナ化された環境で `--cluster-id` 引数を使用して SDK 5 設定ツールを実行すると、エラーが表示されます
<a name="ki-all-10"></a>

設定ツールで--cluster-id 引数を使用すると、次のエラーが表示されます。

`No credentials in the property bag`

このエラーは、インスタンスメタデータサービスのバージョン 2 (IMDSv2) の更新が原因で発生します。詳細については、「[IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)」のドキュメントを参照してください。
+ **影響:** この問題は、コンテナ化された環境で SDK バージョン 5.5.0 以降の設定ツールを実行し、EC2 インスタンスメタデータを利用して認証情報を提供するユーザーに影響を及ぼします。
+ **回避策:** PUT レスポンスのホップ制限を 2 以上に設定します。この設定方法については、[Configure the instance metadata options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) を参照してください。

## 問題: 「指定された pfx ファイルから証明書/キーを作成できませんでした。エラー: NotPkcs8」という内容のエラーが表示されます。
<a name="ki-all-11"></a>
+ **回避策: **openssl コマンドを使用して、カスタム SSL プライベートキーを PKCS8 形式に変換できます。 `openssl pkcs8 -topk8 -inform PEM -outform PEM -in {{ssl_private_key}} -out {{ssl_private_key_pkcs8}}`
+ **解決策の現状:** この問題は、[クライアント SDK 5.12.0 のリリース](client-version-previous.md#client-version-5-12-0) によって解決されています。この修正のメリットを享受するには、このクライアント バージョン以降にアップグレードする必要があります。

## 問題: SDK 5.16 以降で ECDSA 署名が「無効なメカニズム」エラーで失敗する
<a name="ki-all-12"></a>
+ **影響: **キー強度より弱いハッシュ関数を使用した場合、ECDSA 署名オペレーションが失敗します。この失敗は、[FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf) により「ハッシュ関数はキー強度と同等以上である必要がある」と定められているために発生します。

  クライアントログには、次のようなエラーが表示される場合があります。

  ```
  [cloudhsm_provider::hsm1::session::ecdsa::sign::common][][] Digest security strength (80) is weaker than the key security strength (128)
  ```
+ **回避策: **ハッシュ関数を更新できない場合は、ハッシュ強度要件を適用しない 非 FIPS クラスターへ移行することができます。ただし、FIPS 準拠を維持するためには、ハッシュ関数を更新することをお勧めします。

   さらに追加の回避策として、この要件をバイパスするための設定オプションを追加しています。ただし、弱いハッシュ関数を使用した ECDSA 署名はセキュリティのベストプラクティスに反するため、このオプションは**推奨されません**。このオプションを使用するには、次のコマンドを実行します (使用している SDK に応じて `configure-cli` を適切な設定ツールに置き換えてください: [AWS CloudHSM クライアント SDK 5 設定構文](configure-tool-syntax5.md))。

  ```
  sudo /opt/cloudhsm/bin/configure-cli --enable-ecdsa-with-weak-hash-function
  ```
+ **解決策: **ECDSA キーの強度と同等以上の強度を持つハッシュ関数を使用してください。ハッシュ関数と ECDSA キー強度の詳細については、[NIST SP 800-57 Part 1 Rev 5 の表 2 および表 3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf) を参照してください。

## 問題: 事前にハッシュ化されたデータで署名オペレーションを行うと、インタラクティブモードでセッショントークンが正しくクリアされない
<a name="ki-all-13"></a>
+ **影響: **CloudHSM CLI をインタラクティブモードで使用している場合、SDK バージョン 5.16.1 において、事前にハッシュ化されたデータを使用した署名オペレーションが、セッショントークンを正しくクリアできません。
+ **回避策: **事前にハッシュ化されたデータで署名オペレーションを行う際は、インタラクティブモードではなく単一コマンドモードを使用してください。これにより、各オペレーションの後にトークンが正しくクリーンアップされます。
+ **解決策のステータス:** この問題は、CloudHSM SDK 5.16.2 で解決されています。修正を適用するには、バージョン 5.16.2 以降にアップグレードしてください。

## 問題: CloudHSM クライアントライブラリのデフォルトのクライアント証明書が 2026 年 1 月 31 日に期限切れになる
<a name="ki-all-14"></a>
+ **影響: **2026 年 1 月 31 日以降、お客様への影響はありません。クライアントと HSM 間のすべての通信は、[ここで](client-end-to-end-encryption.md)説明するように、クライアント HSM TLS によって保護されます。クライアント HSM TLS は、クラスターの初期化中に顧客が設定した顧客所有/管理の証明書を使用します。
+ **解決ステータス: **Resolved。