

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

# の PKCS \$111 ライブラリの既知の問題 AWS CloudHSM
<a name="ki-pkcs11-sdk"></a>

次の問題は、 の PKCS \$111 ライブラリに影響します AWS CloudHSM。

**Topics**
+ [問題: PKCS \$111 ライブラリのバージョン 3.0.0 での AES キーラップが、使用前に IV を検証しません](#ki-pkcs11-1)
+ [問題: PKCS \$111 SDK 2.0.4 以前のバージョンでは、AES キーのラップとラップ解除に常に `0xA6A6A6A6A6A6A6A6` のデフォルトの IV が使用されていました。](#ki-pkcs11-2)
+ [問題: `CKA_DERIVE` 属性はサポート外だったため、処理されませんでした](#ki-pkcs11-3)
+ [問題: `CKA_SENSITIVE` 属性はサポート外だったため、処理されませんでした](#ki-pkcs11-4)
+ [問題: マルチパートのハッシュおよび署名がサポートされていません](#ki-pkcs11-5)
+ [問題: `C_GenerateKeyPair` は、プライベートテンプレートで標準に従った方法で は、`CKA_MODULUS_BITS` や `CKA_PUBLIC_EXPONENT` を処理しません](#ki-pkcs11-6)
+ [問題: `C_Encrypt` メカニズムを使用している場合、 `C_Decrypt` および `CKM_AES_GCM` API オペレーションのバッファが 16 KB を超えることができません](#ki-pkcs11-8)
+ [問題: 楕円曲線ディフィーヘルマン (ECDH) キーの導出が、HSM 内で部分的に実行されます](#ki-pkcs11-9)
+ [問題: CentOS6 や RHEL 6 などの EL6 プラットフォームで secp256k1 署名の検証が失敗します](#ki-pkcs11-10)
+ [問題 : 関数呼び出しの順序が正しくないと、失敗する代わりに未定義の結果が得られる。](#ki-pkcs11-11)
+ [問題 : SDK 5 では読み取り専用セッションは対応していません](#ki-pkcs11-13)
+ [問題: `cryptoki.h`ヘッダーファイルは Windows 専用です](#ki-pkcs11-14)

## 問題: PKCS \$111 ライブラリのバージョン 3.0.0 での AES キーラップが、使用前に IV を検証しません
<a name="ki-pkcs11-1"></a>

長さが 8 バイトより短い IV を指定すると、使用前に予測不可能なバイトが埋め込まれます。

**注記**  
これは `CKM_AES_KEY_WRAP` メカニズムがある `C_WrapKey` にのみ影響します。
+ **影響:** PKCS \$111 バージョン 3.0.0 で 8 バイトより短い IV を指定した場合、キーをラップ解除できない可能性があります。
+ **回避方法: **
  + PKCS \$111 バージョン 3.0.1 以降にアップグレードすることを強くお勧めします。これにより、AES キーラップ時に IV の長さが適切に適用されます。ラップコードを修正して NULL IV を渡すか、`0xA6A6A6A6A6A6A6A6` のデフォルトの IV を指定します。詳細情報は、「[トラブルシューティングガイド : AESキーラップ用非対応長さのCustom IV](troubleshooting-aes-keys.md)」を参照してください。
  + 8 バイトより短い IV を使用して PKCS \$111 ba-jon 3.0.0 でキーをラップした場合は、弊社 [サポートデスク](https://aws.amazon.com/support) へご連絡ください。
+ **解決策のステータス:** この問題は PKCS \$111 SDK バージョン 3.0.1 で解決されています。AES キーラップを使用してキーをラップするには、NULL または 8 バイトの長さの IV を指定します。

## 問題: PKCS \$111 SDK 2.0.4 以前のバージョンでは、AES キーのラップとラップ解除に常に `0xA6A6A6A6A6A6A6A6` のデフォルトの IV が使用されていました。
<a name="ki-pkcs11-2"></a>

ユーザーが指定した IV はそのまま無視されていました。

**注記**  
これは `CKM_AES_KEY_WRAP` メカニズムがある `C_WrapKey` にのみ影響します。
+ **影響:** 
  + PKCS \$111 SDK 2.0.4 以前のバージョンとユーザーが指定した IV を使用した場合、キーは `0xA6A6A6A6A6A6A6A6` のデフォルトの IV でラップされます。
  + PKCS \$111 SDK 3.0.0 以降とユーザーが指定した IV を使用した場合、キーはユーザーが指定した IV でラップされます。
+ **回避方法:**
  + PKCS \$111 SDK 2.0.4 以前でラップされたキーをラップ解除するには、`0xA6A6A6A6A6A6A6A6` のデフォルトの IV を使用します。
  + PKCS \$111 SDK 3.0.0 以降でラップされたキーをラップ解除するには、ユーザーが指定した IV を使用します。
+ **解決策のステータス:** ラップおよびラップ解除コードを修正して NULL IV を渡すか、`0xA6A6A6A6A6A6A6A6` のデフォルトの IV を指定することを強くお勧めします。

## 問題: `CKA_DERIVE` 属性はサポート外だったため、処理されませんでした
<a name="ki-pkcs11-3"></a>
+ **解決策のステータス:** `FALSE` が設定されている場合は、`CKA_DERIVE` を受け付けるように修正を実装し ます。 AWS CloudHSMにキー取得関数サポートが追加されるまで、`TRUE` に設定された `CKA_DERIVE` はサポートされません。この修正を適用するには、クライアントと SDK をバージョン 1.1.1 以上に更新する必要があります。

## 問題: `CKA_SENSITIVE` 属性はサポート外だったため、処理されませんでした
<a name="ki-pkcs11-4"></a>
+ **解決策のステータス:** `CKA_SENSITIVE` 属性を受け入れ、適切に遵守するように修正を実装しました。この修正を適用するには、クライアントと SDK をバージョン 1.1.1 以上に更新する必要があります。

## 問題: マルチパートのハッシュおよび署名がサポートされていません
<a name="ki-pkcs11-5"></a>
+ **影響:** `C_DigestUpdate` および `C_DigestFinal` は実装されません。`C_SignFinal` も実装されていないため、`NULL` 以外のバッファでは `CKR_ARGUMENTS_BAD` でエラーが発生します。
+ **回避策: **アプリケーション内でデータをハッシュし、ハッシュの署名 AWS CloudHSM にのみ使用します。
+ **解決策のステータス: **クライアントと SDK を修正し、マルチパートハッシュを正しく実装する予定です。更新は AWS CloudHSM フォーラムとバージョン履歴ページで告知されます。

## 問題: `C_GenerateKeyPair` は、プライベートテンプレートで標準に従った方法で は、`CKA_MODULUS_BITS` や `CKA_PUBLIC_EXPONENT` を処理しません
<a name="ki-pkcs11-6"></a>
+ **影響: プライベートテンプレートに ** または `C_GenerateKeyPair` が含まれている場合、`CKA_TEMPLATE_INCONSISTENT``CKA_MODULUS_BITS` は `CKA_PUBLIC_EXPONENT` を返します。代わりに、すべてのフィールドが `FALSE` に設定されているプライベートキーを生成します。キーは使用できません。
+ **解決策: **アプリケーションによって、エラーコードに加えて使用状況フィールドの値をチェックすることをお勧めします。
+ **解決策のステータス: **修正を実装し、間違ったプライベートキーテンプレートが使用されている場合に適切なエラーメッセージを返すようにします。更新された PKCS\$111 ライブラリは、バージョン履歴ページで告知されます。

## 問題: `C_Encrypt` メカニズムを使用している場合、 `C_Decrypt` および `CKM_AES_GCM` API オペレーションのバッファが 16 KB を超えることができません
<a name="ki-pkcs11-8"></a>

AWS CloudHSM はマルチパート AES-GCM 暗号化をサポートしていません。
+ **影響: **`CKM_AES_GCM` メカニズムを使用して 16 KB を超えるデータを暗号化することができません。
+ **回避策: **`CKM_AES_CBC`、`CKM_AES_CBC_PAD` などの代替メカニズムを使用するか、データを複数部分に分割し、`AES_GCM` を使用して各部分を個別に暗号化できます。を使用している場合は`AES_GCM`、データの分割とその後の暗号化を管理する必要があります。 AWS CloudHSM はマルチパート AES-GCM 暗号化を実行しません。FIPS では、`AES-GCM` の初期化ベクター (IV) を HSM で生成する必要があります。したがって、AES-GCM 暗号化データの各部分の IV は異なります。
+ **解決策のステータス: ** SDK を修正し、データバッファが大きすぎる場合は明示的に失敗するようにします。`C_EncryptUpdate` および `C_DecryptUpdate` API オペレーションに `CKR_MECHANISM_INVALID` を返します。マルチパート暗号化を使用しなくても大きいバッファをサポートできる代替方法を評価しています。更新は、 AWS CloudHSM フォーラムとバージョン履歴ページで発表されます。

## 問題: 楕円曲線ディフィーヘルマン (ECDH) キーの導出が、HSM 内で部分的に実行されます
<a name="ki-pkcs11-9"></a>

EC プライベートキーは常に HSM にありますが、キーの取得手順は複数のステップで実行されます。その結果、各ステップの中間結果がクライアントに存在します。
+ ** 影響: **クライアント SDK 3 では、`CKM_ECDH1_DERIVE` メカニズムを使用して得られたキーは、まずクライアントで使用可能になり、その後 HSM 内にインポートされます。その後、キーのハンドルがアプリケーションに返されます。
+ **回避策:** AWS CloudHSMに SSL/TLS のオフロードを実装すると、この制限が問題とはならない場合があります。アプリケーションでキーが常に FIPS 境界内に留まる必要がある場合、ECDH キー取得に依存しない代替プロトコルの使用を検討してください。
+ **解決策のステータス: **SDK 5.16 は、ECDH とキー導出をサポートしており、これらの処理はすべて HSM 内で実行されます。

## 問題: CentOS6 や RHEL 6 などの EL6 プラットフォームで secp256k1 署名の検証が失敗します
<a name="ki-pkcs11-10"></a>

 これは、CloudHSM PKCS\$111 ライブラリが、OpenSSL を使用して EC 曲線データを検証することにより、検証操作の初期化中にネットワークの呼び出しを回避するために発生します。Secp256k1 は EL6 プラットフォームのデフォルトの OpenSSL パッケージでサポートされていないため、初期化は失敗します。
+ **影響: ** Secp256k1 署名検証が EL6 プラットフォームで失敗します。検証呼び出しは、`CKR_HOST_MEMORY` エラーで失敗します。
+ **回避策: ** PKCS\$111 アプリケーションで secp256k1 の署名を検証する必要がある場合は、Amazon Linux 1 または任意の EL7 プラットフォームを使用することをお勧めします。または、secp256k1 曲線 をサポートする OpenSSL パッケージのバージョンにアップグレードすることもできます。
+ **解決策のステータス: ** ローカル曲線検証が利用できない場合に HSM にフォールバックするための修正を実装中です。更新された PKCS\$111 ライブラリは、[バージョン履歴](client-history.md)ページで告知されます。

## 問題 : 関数呼び出しの順序が正しくないと、失敗する代わりに未定義の結果が得られる。
<a name="ki-pkcs11-11"></a>
+ **影響** : 誤った一連の関数を呼び出すと、個々の関数呼び出しの返しが成功しても、最終的な結果は正しくありません。例えば、復号化されたデータが元のプレーンテキストと一致しない場合や、署名が検証できない場合があります。この問題は、シングルパートとマルチパートの両方のオペレーションに影響します。

  誤った関数シーケンスの例 :
  + `C_EncryptInit` / `C_EncryptUpdate` の後に `C_Encrypt` が続きます
  + `C_DecryptInit` / `C_DecryptUpdate` の後に `C_Decrypt` が続きます
  + `C_SignInit` / `C_SignUpdate` の後に `C_Sign` が続きます
  + `C_VerifyInit` / `C_VerifyUpdate` の後に `C_Verify` が続きます
  + `C_FindObjectsInit` は `C_FindObjectsInit` の後に続きます
+  **防止策**: アプリケーションを PKCS \$111 仕様に準拠して、シングルパートとマルチパートの両方のオペレーションに適切な関数呼び出しを使用する必要があります。この状況では、アプリケーションが CloudHSM PKCS \$111 ライブラリに依存してエラーを返す必要はありません。

## 問題 : SDK 5 では読み取り専用セッションは対応していません
<a name="ki-pkcs11-13"></a>
+ **問題:** SDK 5 では、`C_OpenSession` で読み取り専用セッションを開くことはできません。
+ **影響:** `C_OpenSession` 未対応で `CKF_RW_SESSION` を呼び出ししようとした場合、呼び出しは失敗し、エラー `CKR_FUNCTION_FAILED` が返されます。
+ **防止策:** セッションを開く際、`CKF_SERIAL_SESSION | CKF_RW_SESSION` 関数呼び出しに `C_OpenSession` フラグを渡す必要があります。

## 問題: `cryptoki.h`ヘッダーファイルは Windows 専用です
<a name="ki-pkcs11-14"></a>
+ **問題: **Linux の AWS CloudHSM クライアント SDK 5 バージョン 5.0.0 から 5.4.0 では、ヘッダーファイルは Windows オペレーティングシステムとのみ互換性`/opt/cloudhsm/include/pkcs11/cryptoki.h`があります。
+ **影響: **Linux ベースのオペレーティングシステム上のアプリケーションにこのヘッダーファイルを含めようとすると、問題が発生する可能性があります。
+ **解決ステータス: **このヘッダーファイルの Linux 互換バージョンを含む AWS CloudHSM クライアント SDK 5 バージョン 5.4.1 以降にアップグレードします。