すべての HSM インスタンスの既知の問題

影響: AWS CloudHSM 内でこのアルゴリズムを使用してラップおよびラップ解除しても影響はありません。ただし、AWS CloudHSM でラップされたキーは、パディングを使用しない仕様への準拠を想定する他の HSM またはソフトウェア内でラップ解除することはできません。これは、標準に準拠したラップ解除中に、8 バイトのパディングデータがキーデータの最後に追加される可能性があるためです。外部ラップされたキーは、AWS CloudHSM インスタンスに適切にラップ解除することはできません。

回避策: AWS CloudHSM インスタンスで PKCS #5 パディングありの AES キーラップを使用してラップされたキーを外部でラップ解除するには、キーを使用する前に余分なパディングを省きます。これを行うには、ファイルエディターで余分なバイトをトリミングするか、コード内の新しいバッファにキーバイトだけをコピーします。

解決策のステータス: 3.1.0 クライアントおよびソフトウェアリリースで、AWS CloudHSM に AES キーラップの標準に準拠したオプションが用意されています。詳細については、「AES キーラップ」を参照してください。

影響: クラスター内のすべての HSM を削除し、新しい IP アドレスを取得する別の HSM を追加した場合、クライアントデーモンは元の IP アドレスで HSM を検索し続けます。

解決策: 断続的なワークロードを実行する場合、CreateHsm の関数で IpAddress 引数を使用して Elastic Network Interface (ENI) を元の値に設定することをお勧めします。ENI はアベイラビリティーゾーン (AZ) に固有である点に注意してください。代わりに、/opt/cloudhsm/daemon/1/cluster.info ファイルを削除した後、新しい HSM クライアントの IP アドレスにクライアント設定をリセットできます。client -a <IP address> コマンドを使用できます。詳細については、「AWS CloudHSM クライアント (Linux) のインストールと設定」または「AWS CloudHSM クライアント (Windows) のインストールと設定」を参照してください。

解決策のステータス: サイズが 16 KB 未満のデータは、ハッシュ用に引き続き HSM に送信されます。16～64 KB のサイズのデータをローカルやソフトウェアでハッシュする機能が追加されました。データバッファが 64 KB を超える場合、クライアント SDK 5 は明示的に失敗します。この修正を適用するには、クライアントと SDK を 5.0.0 より新しいバージョンに更新する必要があります。

解決策のステータス: この問題は修正されています。修正を反映させるためにお客様側で必要なアクションはありません。

解決策: wrapKey コマンドまたは unWrapKey コマンドを使用する場合は、-m オプションを使用してメカニズムを指定する必要があります。詳細については、wrapKey または unWrapKey の記事の例を参照してください。

影響: クラスター内に 1 つしかない HSM インスタンスの接続が失われると、後で回復しても、クライアントはインスタンスに再接続しません。

回避方法: 本番稼働用クラスターに少なくとも 2 つの HSM インスタンスを用意することをお勧めします。この構成を使用すれば、この問題の影響を受けません。HSM が 1 つしかないクラスターの場合、クライアントデーモンをバウンスして接続を復元します。

解決策のステータス: この問題は、AWS CloudHSM クライアント 1.1.2 のリリースで解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

影響: クライアントが処理されないエラー状態になると、フリーズし、再起動が必要になります。

回避方法: スループットをテストして、クライアントが処理できない速さでセッションキーを作成していないか、確認します。速さを落とすには、クラスターに HSM を追加するか、セッションキーの作成を遅くします。

解決策のステータス: この問題は、AWS CloudHSM クライアント 1.1.2 のリリースで解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

影響: 800 バイトを上回る HMAC キーが HSM で生成されたり、HSM にインポートされたりする可能性があります。ただし、このような大きなキーを JCE または key_mgmt_util を介してダイジェストオペレーションに使用すると、オペレーションが失敗します。PKCS11 を使用している場合、HMAC キーのサイズは 64 バイトに制限されます。

回避方法: HSM のダイジェストオペレーションに HMAC キーを使用する場合は、必ずサイズが 800 バイト以下のものを使用します。

解決策のステータス: 現時点ではありません。

影響: 指定した出力パスの下にある既存のファイルとサブディレクトリはすべて、永久に失われる可能性があります

防止策: -output path ツールを使用する際、オプションの引数 client_info を使用しないでください。

解決策の現状: この問題は、クライアント SDK 3.3.2 のリリース によって解決されています。修正のメリットを享受するには、このクライアントにアップグレードする必要があります。

影響: この問題は、コンテナ化された環境で SDK バージョン 5.5.0 以降の設定ツールを実行し、EC2 インスタンスメタデータを利用して認証情報を提供するユーザーに影響を及ぼします。

回避策: PUT レスポンスのホップ制限を 2 以上に設定します。この設定方法については、Configure the instance metadata options を参照してください。

回避策: openssl コマンドを使用して、カスタム SSL プライベートキーを PKCS8 形式に変換できます。 openssl pkcs8 -topk8 -inform PEM -outform PEM -in ssl_private_key -out ssl_private_key_pkcs8

解決策の現状: この問題は、クライアント SDK 5.12.0 のリリース によって解決されています。この修正のメリットを享受するには、このクライアント バージョン以降にアップグレードする必要があります。

影響: キー強度より弱いハッシュ関数を使用した場合、ECDSA 署名オペレーションが失敗します。この失敗は、FIPS 186-5 により「ハッシュ関数はキー強度と同等以上である必要がある」と定められているために発生します。

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

[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 設定構文)。

sudo /opt/cloudhsm/bin/configure-cli --enable-ecdsa-with-weak-hash-function

解決策: ECDSA キーの強度と同等以上の強度を持つハッシュ関数を使用してください。ハッシュ関数と ECDSA キー強度の詳細については、NIST SP 800-57 Part 1 Rev 5 の表 2 および表 3 を参照してください。

影響: CloudHSM CLI をインタラクティブモードで使用している場合、SDK バージョン 5.16.1 において、事前にハッシュ化されたデータを使用した署名オペレーションが、セッショントークンを正しくクリアできません。

回避策: 事前にハッシュ化されたデータで署名オペレーションを行う際は、インタラクティブモードではなく単一コマンドモードを使用してください。これにより、各オペレーションの後にトークンが正しくクリーンアップされます。

解決策のステータス: この問題は、CloudHSM SDK 5.16.2 で解決されています。修正を適用するには、バージョン 5.16.2 以降にアップグレードしてください。