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

影響: このアルゴリズムを使用してラップおよびラップ解除しても影響はありません AWS CloudHSM。ただし、 でラップされたキーは、パディングなしの仕様への準拠が予想される他の HSMs またはソフトウェア内でラップ解除 AWS CloudHSM することはできません。これは、標準に準拠したラップ解除中に、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> コマンドを使用できます。詳細については、「 クライアントのインストールと設定 (Linux) AWS CloudHSM」または「 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 に設定します。これを行う方法については、「インスタンスメタデータオプションの設定」を参照してください。

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

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