本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# PKCS \$111 库的已知问题 AWS CloudHSM
<a name="ki-pkcs11-sdk"></a>

以下问题会影响的 PKCS \$111 库。 AWS CloudHSM

**Topics**
+ [问题：PKCS \$111 库版本 3.0.0 中的 AES 密钥封装在使用前无法验证 IVs](#ki-pkcs11-1)
+ [问题：PKCS \$111 SDK 2.0.4 以及更早版本始终使用 `0xA6A6A6A6A6A6A6A6` 的默认 IV 来执行 AES 密钥包装和解包](#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)
+ [问题：在使用 `CKM_AES_GCM` 机制时，用于执行 `C_Encrypt` 和 `C_Decrypt` API 操作的缓冲区不能超过 16 KB](#ki-pkcs11-8)
+ [问题：在 HSM 内部分执行椭圆曲线迪菲-赫尔曼 (ECDH, Elliptic-curve Diffie-Hellman) 密钥派生](#ki-pkcs11-9)
+ [问题：在 Cent 和 RHEL 6 等 EL6 平台上验证 secp256k1 签名失败 OS6](#ki-pkcs11-10)
+ [问题：错误的函数调用时序会给出未定义的结果而不是导致失败](#ki-pkcs11-11)
+ [问题：SDK 5 不支持只读会话](#ki-pkcs11-13)
+ [问题：`cryptoki.h` 标头文件仅适用于 Windows](#ki-pkcs11-14)

## 问题：PKCS \$111 库版本 3.0.0 中的 AES 密钥封装在使用前无法验证 IVs
<a name="ki-pkcs11-1"></a>

如果您指定长度小于 8 字节的 IV，则在使用之前会填充不可预知的字节。

**注意**  
这只会对使用 `CKM_AES_KEY_WRAP` 的 `C_WrapKey` 机制产生影响。
+ **影响：**如果您在 PKCS \$111 库 3.0.0 版本中提供的 IV 小于 8 字节，则可能无法对密钥进行解包。
+ **解决方法：**
  + 我们强烈建议您升级到 PKCS \$111 库 3.0.1 版或更高版本，以便在 AES 密钥包装期间正确地强制执行 IV 长度。修改包装代码以便传递 NULL IV，或者指定默认 IV `0xA6A6A6A6A6A6A6A6`。有关更多信息，请参阅 [AES 密钥封装长度不合规的自定义 IVs ](troubleshooting-aes-keys.md)。
  + 如果您使用短于 8 字节的 IV，通过 PKCS \$111 库 3.0.0 版来包装任何密钥，请联系我们以获取[支持](https://aws.amazon.com/support)。
+ **解决状态：**此问题已在 PKCS \$111 库 3.0.1 版中解决。要使用 AES 密钥包装来包装密钥，请指定 NULL 或长度为 8 字节的 IV。

## 问题：PKCS \$111 SDK 2.0.4 以及更早版本始终使用 `0xA6A6A6A6A6A6A6A6` 的默认 IV 来执行 AES 密钥包装和解包
<a name="ki-pkcs11-2"></a>

用户提供的 IVs 被默默忽略。

**注意**  
这只会对使用 `CKM_AES_KEY_WRAP` 的 `C_WrapKey` 机制产生影响。
+ **影响：**
  + 如果您使用 PKCS \$111 开发工具包 2.0.4 或早期版本以及用户提供的 IV，则您的密钥将使用默认 IV `0xA6A6A6A6A6A6A6A6` 进行包装。
  + 如果您使用 PKCS \$111 开发工具包 3.0.0 或更高版本以及用户提供的 IV，则您的密钥将使用用户提供的 IV 进行包装。
+ **解决方法：**
  + 要解包使用 PKCS \$111 开发工具包 2.0.4 或更早版本包装的密钥，请使用默认 IV `0xA6A6A6A6A6A6A6A6`。
  + 要解包使用 PKCS \$111 开发工具包 3.0.0 或更高版本包装的密钥，请使用用户提供的 IV。
+ **解决状态：**我们强烈建议您修改包装和解包代码，以便传递 NULL IV，或者指定默认 IV `0xA6A6A6A6A6A6A6A6`。

## 问题：不支持且不处理 `CKA_DERIVE` 属性
<a name="ki-pkcs11-3"></a>
+ **解决状态：**我们已经实施修复，以便接受 `CKA_DERIVE`（如果它设置为 `FALSE`）。在我们开始为 AWS CloudHSM增加密钥派生函数支持之前，不支持将 `CKA_DERIVE` 设置为 `TRUE` 您必须将客户端和开发工具包更新至版本 1.1.1 或更高版本，才能从修复获益。

## 问题：不支持且不处理 `CKA_SENSITIVE` 属性
<a name="ki-pkcs11-4"></a>
+ **解决状态：**我们已实施修改，以便接受并正确处理 `CKA_SENSITIVE` 属性。您必须将客户端和开发工具包更新至版本 1.1.1 或更高版本，才能从修复获益。

## 问题：不支持多部分哈希和签名
<a name="ki-pkcs11-5"></a>
+ **影响：**`C_DigestUpdate` 和 `C_DigestFinal` 不会实施。`C_SignFinal` 也不会实施，并且对于非 `NULL` 缓冲区将会失败并显示 `CKR_ARGUMENTS_BAD`。
+ **解决方法：**在应用程序中对数据进行哈希处理， AWS CloudHSM 仅用于对哈希进行签名。
+ **解析状态：**我们正在修复客户端和 SDKs以正确实现多部分哈希。将在 AWS CloudHSM 论坛和版本历史记录页面中公布更新。

## 问题：`C_GenerateKeyPair` 不以符合标准的方式处理私有模板中的 `CKA_MODULUS_BITS` 或 `CKA_PUBLIC_EXPONENT`
<a name="ki-pkcs11-6"></a>
+ **影响：**`C_GenerateKeyPair` 应在私有模板包含 `CKA_MODULUS_BITS` 或 `CKA_PUBLIC_EXPONENT` 时返回 `CKA_TEMPLATE_INCONSISTENT`。相反，它生成了一个所有用法字段都设置为 `FALSE` 的私有密钥。无法使用该密钥。
+ **解决方法：**建议您的应用程序检查用法字段值以及错误代码。
+ **解析状态：**我们正在实施修复，以在使用了不正确的私有密钥模板时返回正确的错误消息。将在版本历史记录页面中公布更新后的 PKCS\$111 库。

## 问题：在使用 `CKM_AES_GCM` 机制时，用于执行 `C_Encrypt` 和 `C_Decrypt` 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 要求在 HSM 上生成 `AES-GCM` 的初始化向量 (IV)。因此，您的 AES-GCM 加密数据的每个部分的 IV 将不同。
+ **解决状态：**我们正在修复开发工具包，以在数据缓冲区过大时显式失败。我们将为 `C_EncryptUpdate` 和 `C_DecryptUpdate` API 操作返回 `CKR_MECHANISM_INVALID`。我们正在评估替代方法来支持较大的缓冲区，而不依靠多部分加密。更新将在 AWS CloudHSM 论坛和版本历史记录页面上公布。

## 问题：在 HSM 内部分执行椭圆曲线迪菲-赫尔曼 (ECDH, Elliptic-curve Diffie-Hellman) 密钥派生
<a name="ki-pkcs11-9"></a>

您的 EC 私有密钥始终保留在 HSM 中，但密钥派生过程分多步执行。因此，客户端上可以提供每个步骤的中间结果。
+ **影响：**在 Client SDK 3 中，采用 `CKM_ECDH1_DERIVE` 机制派生的密钥先在客户端上提供，随后导入到 HSM。密钥句柄随后会返回到您的应用程序。
+ **解决办法：**如果您在中实现 SSL/TLS Offload AWS CloudHSM，则此限制可能不是问题。如果您的应用程序需要将您的密钥始终保持在 FIPS 边界内，请考虑使用不依赖 ECDH 密钥派生的替代协议。
+ **解决状态：**SDK 5.16 现在支持带密钥派生的 ECDH，该密钥派生完全在 HSM 中执行。

## 问题：在 Cent 和 RHEL 6 等 EL6 平台上验证 secp256k1 签名失败 OS6
<a name="ki-pkcs11-10"></a>

 这是因为 CloudHSM PKCS\$111 库通过使用 OpenSSL 来验证 EC 曲线数据，在初始化验证操作的过程中避免网络调用。由于平台上的默认 OpenSSL 包不支持 secp256k1，因此初始化失败。EL6 
+ **影响：**Secp256k1 签名验证将在平台上失败。 EL6验证调用失败，并显示 `CKR_HOST_MEMORY` 错误。
+ **解决办法：**如果您的 PKCS \$111 应用程序需要验证 secp256k1 签名，我们建议您使用 Amazon Linux 1 或任何 EL7 平台。或者，升级到支持 secp256k1 曲线的 OpenSSL 软件包版本。
+ **解决状态：**我们正在实施修复，如果本地曲线验证不可用，则回退到 HSM。将在[版本历史记录](client-history.md)页面中公布更新后的 PKCS\$111 库。

## 问题：错误的函数调用时序会给出未定义的结果而不是导致失败
<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` 打开只读会话。
+ **影响：**如果您在未提供 `CKF_RW_SESSION` 的情况下尝试调用 `C_OpenSession`，则调用将失败并显示错误 `CKR_FUNCTION_FAILED`。
+ **解决办法：**打开会话时，必须将 `CKF_SERIAL_SESSION | CKF_RW_SESSION` 标记传递给 `C_OpenSession` 函数调用。

## 问题：`cryptoki.h` 标头文件仅适用于 Windows
<a name="ki-pkcs11-14"></a>
+ **问题：**在 Linux 上的 AWS CloudHSM Client SDK 5 版本 5.0.0 到 5.4.0 中，头文件`/opt/cloudhsm/include/pkcs11/cryptoki.h`仅与 Windows 操作系统兼容。
+ **影响：**当您在基于 Linux 的操作系统的应用程序中尝试包含此标头文件时，您可能会遇到问题。
+ **解析状态：**升级到 AWS CloudHSM Client SDK 5 版本 5.4.1 或更高版本，其中包括此头文件的 Linux 兼容版本。