Known Issues for the JCE SDK - AWS CloudHSM

Known Issues for the JCE SDK

Issue: When working with asymmetric key pairs, you see occupied key capacity even when you are not explicitly creating or importing keys

  • Impact: This issue can cause your HSMs to unexpectedly run out of key space and occurs when your application uses a standard JCE key object for crypto operations instead of a CaviumKey object. When you use a standard JCE key object, CaviumProvider implicitly imports that key into the HSM as a session key and does not delete this key until the application exits. As a result, keys build up while the application is running and can cause your HSMs to run out of free key space, thus freezing your application.

  • Workaround: When using the CaviumSignature class, CaviumCipher class, CaviumMac class, or the CaviumKeyAgreement class, you should supply the key as a CaviumKey instead of a standard JCE key object.

    You can manually convert a normal key to a CaviumKey using the ImportKey class, and can then manually delete the key after the operation is complete.

  • Resolution status: We are updating the CaviumProvider to properly manage implicit imports. The fix will be announced on the version history page once available.

Issue: You cannot specify attributes when unwrapping keys

  • Impact: All keys are unwrapped as exportable session keys.

  • Workaround: You can script key_mgmt_util to unwrap keys with limited attribute customization, or use the PKCS #11 library to unwrap keys with full template support.

  • Resolution status: We are planning to add full key parameter specification for the JCE SDK's unwrap command in a future release. The update will be announced on the version history page once available.

Issue: The JCE KeyStore is read only

  • Impact: You cannot store an object type that is not supported by the HSM in the JCE keystore today. Specifically, you cannot store certificates in the keystore. This precludes interoperability with tools like jarsigner, which expect to find the certificate in the keystore.

  • Workaround: You can rework your code to load certificates from local files or from an S3 bucket location instead of from the keystore.

  • Resolution status: We are adding support for certificate storage in the keystore. The feature will be announced on the version history page once available.

Issue: Buffers for AES-GCM encryption cannot exceed 16,000 bytes

Multi-part AES-GCM encryption is not supported.

  • Impact: You cannot use AES-GCM to encrypt data larger than 16,000 bytes.

  • Workaround: You can use an alternative mechanism, such as AES-CBC, or you can divide your data into pieces and encrypt each piece individually. If you divide the data, you must manage the divided ciphertext and its decryption. Because FIPS requires that the initialization vector (IV) for AES-GCM be generated on the HSM, the IV for each AES-GCM-encrypted piece of data will be different.

  • Resolution status: We are fixing the SDK to fail explicitly if the data buffer is too large. We are evaluating alternatives that support larger buffers without relying on multi-part encryption. Updates will be announced in the AWS CloudHSM forum and on the version history page.

Issue: Elliptic-curve Diffie-Hellman (ECDH) key derivation is executed partially within the HSM

Your EC private key remains within the HSM at all times, but the key derivation process is performed in multiple steps. As a result, intermediate results from each step are available on the client. An ECDH key derivation sample is available in the Java code samples.

  • Impact: Software version 3.0 adds ECDH functionality to the JCE. When you use the CKM_ECDH1_DERIVE mechanism to derive the key, it is first available on the client and is then imported into the HSM. A key handle is then returned to your application.

  • Workaround: If you are implementing SSL/TLS Offload in AWS CloudHSM, this limitation may not be an issue. If your application requires your key to remain within an FIPS boundary at all times, consider using an alternative protocol that does not rely on ECDH key derivation.

  • Resolution status: We are developing the option to perform ECDH key derivation entirely within the HSM. When available, we'll announce the updated implementation on the version history page.