PKCS#11 库的已知问题 AWS CloudHSM - AWS CloudHSM

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

PKCS#11 库的已知问题 AWS CloudHSM

以下问题会影响的 PKCS #11 库 AWS CloudHSM。

问题:PKCS#11 库 3.0.0 版中的AES密钥换行在使用前未进行验证 IVs

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

注意

这只会对使用 CKM_AES_KEY_WRAPC_WrapKey 机制产生影响。

问题:PKCS#11 SDK 2.0.4 及更早版本始终使用默认 IV 0xA6A6A6A6A6A6A6A6 进行AES密钥换行和解包

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

注意

这只会对使用 CKM_AES_KEY_WRAPC_WrapKey 机制产生影响。

  • 影响:

    • 如果您使用的是 PKCS #11 SDK 2.0.4 或更早版本以及用户提供的 IV,则您的密钥将使用默认 IV 进行封装。0xA6A6A6A6A6A6A6A6

    • 如果您使用的是 PKCS #11 SDK 3.0.0 或更高版本以及用户提供的 IV,则您的密钥将使用用户提供的 IV 封装。

  • 解决方法:

    • 要解开用 PKCS #11 SDK 2.0.4 或更早版本封装的密钥,请使用默认的 IV。0xA6A6A6A6A6A6A6A6

    • 要解开用 PKCS #11 SDK 3.0.0 或更高版本封装的密钥,请使用用户提供的 IV。

  • 解决状态:我们强烈建议您修改包装和解包代码以通过 NULL IV,或者指定默认 IV 为。0xA6A6A6A6A6A6A6A6

问题:不支持且不处理 CKA_DERIVE 属性

  • 解决状态:我们已经实施修复,以便接受 CKA_DERIVE(如果它设置为 FALSE)。在我们开始为 AWS CloudHSM增加密钥派生函数支持之前,不支持将 CKA_DERIVE 设置为 TRUE 您必须将您的客户端和SDK(s)更新到 1.1.1 或更高版本才能从此修复中受益。

问题:不支持且不处理 CKA_SENSITIVE 属性

  • 解决状态:我们已实施修改,以便接受并正确处理 CKA_SENSITIVE 属性。您必须将您的客户端和SDK(s)更新到 1.1.1 或更高版本才能从此修复中受益。

问题:不支持多部分哈希和签名

  • 影响:C_DigestUpdateC_DigestFinal 不会实施。C_SignFinal 也不会实施,并且对于非 NULL 缓冲区将会失败并显示 CKR_ARGUMENTS_BAD

  • 解决办法:在应用程序中对数据进行哈希处理, AWS CloudHSM 仅用于对哈希进行签名。

  • 解析状态:我们正在修复客户端和SDKs以正确实现多部分哈希。将在 AWS CloudHSM 论坛和版本历史记录页面中公布更新。

问题:C_GenerateKeyPair 不以符合标准的方式处理私有模板中的 CKA_MODULUS_BITSCKA_PUBLIC_EXPONENT

  • 影响:C_GenerateKeyPair 应在私有模板包含 CKA_MODULUS_BITSCKA_PUBLIC_EXPONENT 时返回 CKA_TEMPLATE_INCONSISTENT。相反,它生成了一个所有用法字段都设置为 FALSE 的私有密钥。无法使用该密钥。

  • 解决方法:建议您的应用程序检查用法字段值以及错误代码。

  • 解析状态:我们正在实施修复,以在使用了不正确的私有密钥模板时返回正确的错误消息。更新后的 PKCS #11 库将在版本历史记录页面上公布。

问题:使用机制时,C_EncryptC_DecryptAPI操作的缓冲区不能超过 16 KB CKM_AES_GCM

AWS CloudHSM 不支持多部分AES加GCM密。

  • 影响:您不能使用 CKM_AES_GCM 机制加密大于 16 KB 的数据。

  • 变通办法:您可以使用一个替代机制 (如 CKM_AES_CBCCKM_AES_CBC_PAD),也可以将数据拆分为多个部分并用 AES_GCM 为各个部分分别加密。如果您正在使用AES_GCM,则必须管理数据的划分和随后的加密。 AWS CloudHSM 不会为您执行多部分AES加GCM密。请注意,这FIPS要求在上生成初始化向量 (IV) HSM。AES-GCM因此,您的AES每条GCM加密数据的 IV 都会有所不同。

  • 解析状态:如果数据缓冲区太大,我们将修复为显式失败。SDK我们回CKR_MECHANISM_INVALID来进行C_EncryptUpdateC_DecryptUpdateAPI操作。我们正在评估替代方法来支持较大的缓冲区,而不依靠多部分加密。更新将在 AWS CloudHSM 论坛和版本历史记录页面上公布。

问题:椭圆曲线 Diffie-Hellman () ECDH 密钥派生部分在 HSM

您的 EC 私钥始终保持HSM在内,但密钥派生过程是分多个步骤执行的。因此,客户端上可以提供每个步骤的中间结果。

  • 影响:在客户端 SDK 3 中,使用该CKM_ECDH1_DERIVE机制派生的密钥首先在客户端上可用,然后导入到HSM。密钥句柄随后会返回到您的应用程序。

  • 解决办法:如果您在中实现SSL/TLSOffload AWS CloudHSM,则此限制可能不是问题。如果您的应用程序要求密钥始终保持在FIPS边界内,请考虑使用不依赖ECDH密钥派生的替代协议。

  • 解析状态:我们正在开发完全在内执行ECDH密钥派生的HSM选项。更新的实施将在版本历史记录页面中公布。

问题:在 Cent 和 6 等EL6平台上验证 secp256k1 签名失败 OS6 RHEL

之所以发生这种情况,是因为 Cloud HSM PKCS #11 库通过使用 Open SSL 来验证 EC 曲线数据,从而避免了验证操作初始化期间的网络调用。由于EL6平台上的默认 Open SSL 包不支持 secp256k1,因此初始化失败。

  • 影响:Secp256k1 签名验证将在平台上失败。EL6验证调用失败,并显示 CKR_HOST_MEMORY 错误。

  • 解决办法:如果您的 PKCS #11 应用程序需要验证 secp256k1 签名,我们建议您使用 Amazon Linux 1 或任何EL7平台。或者,升级到支持 secp256k1 曲SSL线的 Open 软件包版本。

  • 分辨率状态:HSM如果局部曲线验证不可用,我们正在实施修复程序,以回退到该状态。更新后的 PKCS #11 库将在版本历史记录页面上公布。

问题:错误的函数调用时序会给出未定义的结果而不是导致失败

  • 影响:如果您函数调用的顺序不正确,即使单个函数调用返回成功,最终结果也是不正确的。例如,解密后的数据可能与原始明文不匹配,或者签名可能无法验证。此问题会影响单部件和多部分操作。

    不正确的函数顺序示例:

    • 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 #11 规范,对单部分和多部分操作使用正确的函数调用顺序。在这种情况下,您的应用程序不应依赖 Cloud HSM PKCS #11 库来返回错误。

问题:SDK5 中不支持只读会话

  • 问题:SDK5 不支持使用打开只读会话C_OpenSession

  • 影响:如果您在未提供 CKF_RW_SESSION 的情况下尝试调用 C_OpenSession,则调用将失败并显示错误 CKR_FUNCTION_FAILED

  • 解决办法:打开会话时,必须将 CKF_SERIAL_SESSION | CKF_RW_SESSION 标记传递给 C_OpenSession 函数调用。

问题:cryptoki.h 标头文件仅适用于 Windows

  • 问题:在 Linux 上的 AWS CloudHSM Client SDK 5 版本 5.0.0 到 5.4.0 中,头文件/opt/cloudhsm/include/pkcs11/cryptoki.h仅与 Windows 操作系统兼容。

  • 影响:当您在基于 Linux 的操作系统的应用程序中尝试包含此标头文件时,您可能会遇到问题。

  • 解析状态:升级到 AWS CloudHSM 客户端 SDK 5 版本 5.4.1 或更高版本,其中包括此头文件的 Linux 兼容版本。