Problemas conocidos para el SDK de JCE en AWS CloudHSM - AWS CloudHSM
Problema: si trabaja con pares de claves asimétricas, verá que la capacidad para las claves está ocupada aunque no esté creando o importando las claves explícitamente.Problema: el KeyStore de JCE es de solo lectura.Problema: los búferes para el cifrado AES-GCM no pueden superar los 16 000 bytes. Problema: la derivación de claves Diffie-Hellman (ECDH) de curva elíptica se ejecuta parcialmente en el HSM.Problema: KeyGenerator y KeyAttribute interpretan incorrectamente el parámetro de tamaño de la clave como número de bytes en lugar de bits.Problema: SDK 5 de cliente muestra la advertencia «Se ha producido una operación ilegal de acceso reflexivo».Problema: el grupo de sesiones de JCE está agotado.Problema: pérdida de memoria de Client SDK 5 con operaciones de getKey

Problemas conocidos para el SDK de JCE en AWS CloudHSM

Los siguientes problemas afectan al SDK de JCE en AWS CloudHSM.

Problema: si trabaja con pares de claves asimétricas, verá que la capacidad para las claves está ocupada aunque no esté creando o importando las claves explícitamente.

  • Impacto: este problema puede provocar que los HSM se queden sin espacio para las claves de forma inesperada y se produce cuando la aplicación utiliza un objeto de clave JCE estándar para las operaciones de criptografía en lugar de un objeto CaviumKey. Si utiliza un objeto de clave JCE estándar, CaviumProvider importa implícitamente esa clave en el HSM como una clave de sesión y no elimina esta clave hasta que se cierra la aplicación. Como resultado, las claves se acumulan mientras la aplicación se está ejecutando y pueden hacer que los HSM se queden sin espacio libre para las claves, lo que bloquea la aplicación.

  • Solución: si utiliza la clase CaviumSignature, la clase CaviumCipher, la clase CaviumMac o la clase CaviumKeyAgreement, debe proporcionar la clave como un objeto CaviumKey en lugar que como un objeto de clave JCE estándar.

    Puede convertir manualmente una clave normal en un objeto CaviumKey utilizando la clase ImportKey y puede eliminar manualmente la clave una vez que se haya completado la operación.

  • Estado de la resolución: estamos actualizando CaviumProvider para administrar correctamente las importaciones implícitas. La corrección se anunciará en la página del historial de versiones una vez que esté disponible.

Problema: el KeyStore de JCE es de solo lectura.

  • Impacto: en la actualidad no puede almacenar un tipo de objeto que no sea compatible con HSM en el almacén de claves de JCE. En concreto, no puede almacenar certificados en el almacén de claves. Esto impide la interoperabilidad con herramientas como jarsigner, que espera encontrar el certificado en el almacén de claves.

  • Solución: puede rehacer el código para cargar los certificados desde archivos locales o desde una ubicación de bucket de S3 en lugar de hacerlo desde el almacén de claves.

  • Estado de resolución: estamos añadiendo compatibilidad con el almacenamiento de certificados en el almacén de claves. La característica se anunciará en la página de historial de versiones una vez que esté disponible.

Problema: los búferes para el cifrado AES-GCM no pueden superar los 16 000 bytes.

Además, no se admite el cifrado AES-GCM multiparte.

  • Impacto: no puede usar AES-GCM para cifrar datos que superen los 16 000 bytes.

  • Solución: puede usar un mecanismo alternativo como AES-CBC o puede dividir los datos en partes y cifrar cada parte individualmente. Si divide los datos, debe administrar el texto cifrado dividido y su descifrado. Como FIPS requiere que el vector de inicialización (IV) para AES-GCM se genere en el HSM, el IV de cada elemento de datos con cifrado AES-GCM será diferente.

  • Estado de resolución: estamos corrigiendo los SDK para que produzcan un error de forma explícita si el búfer de datos es demasiado grande. Estamos evaluando alternativas que admitan búferes más grandes sin recurrir al cifrado multiparte. Las actualizaciones se anunciarán en el foro de AWS CloudHSM y en la página de historial de versiones.

Problema: la derivación de claves Diffie-Hellman (ECDH) de curva elíptica se ejecuta parcialmente en el HSM.

Su clave privada EC permanece dentro del HSM en todo momento, pero el proceso de generación de la clave se realiza en varios pasos. Como resultado, los resultados intermedios de cada paso están disponibles en el cliente. Encontrará una muestra de la derivación de claves de ECDH en los ejemplos de código de Java.

  • Impacto: Client SDK 3 agrega la funcionalidad ECDH al JCE. Cuando se usa la clase KeyAgreement para derivar una SecretKey, primero está disponible en el cliente y, a continuación, se importa al HSM. Un identificador de clave se devuelve después a su aplicación.

  • Solución: si implementa una descarga de SSL/TLS en AWS CloudHSM, es posible que esta limitación no represente un problema. Si su aplicación requiere que su clave permanezca dentro de un límite FIPS en todo momento, considere el uso de un protocolo alternativo que no se base en la generación de la clave ECDH.

  • Estado de resolución: desarrollamos la opción para llevar a cabo la generación de la clave ECDH en su totalidad dentro del HSM. Cuando esté disponible, anunciaremos la implementación actualizada en la página del historial de versiones.

Problema: KeyGenerator y KeyAttribute interpretan incorrectamente el parámetro de tamaño de la clave como número de bytes en lugar de bits.

Al generar una clave mediante la función init de la clase KeyGenerator o el SIZE atributo de la enumeración de AWS CloudHSM de KeyAttribute, la API espera erróneamente que el argumento sea el número de bytes de la clave, cuando debería ser el número de bits de la clave.

  • Impacto: las versiones 5.4.0 a 5.4.2 de SDK de cliente esperaban erróneamente que el tamaño de la clave se proporcionara a las API especificadas en bytes.

  • Solución alternativa: convierta el tamaño de la clave de bits a bytes antes de utilizar la clase KeyGenerator o la enumeración KeyAttribute para generar claves con el proveedor de AWS CloudHSM JCE si utiliza las versiones 5.4.0 a 5.4.2 del SDK de cliente.

  • Estado de la resolución: actualice a la versión 5.5.0 o posterior de SDK de cliente, que incluye una corrección para calcular correctamente los tamaños de las claves en bits al utilizar la clase KeyGenerator o la enumeración KeyAttribute para generar claves.

Problema: SDK 5 de cliente muestra la advertencia «Se ha producido una operación ilegal de acceso reflexivo».

Al usar SDK 5 de cliente con Java 11, CloudHSM lanza la siguiente advertencia de Java: 

```
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore (file:/opt/cloudhsm/java/cloudhsm-jce-5.6.0.jar) to field java.security .KeyStore.keyStoreSpi
WARNING: Please consider reporting this to the maintainers of com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
```

Estas advertencias no tienen ningún efecto. Somos conscientes de este problema y estamos trabajando para resolverlo. No se necesita ninguna acción ni solución alternativa.

Problema: el grupo de sesiones de JCE está agotado.

Impacto: es posible que no pueda realizar operaciones en JCE después de ver el siguiente mensaje:

com.amazonaws.cloudhsm.jce.jni.exception.InternalException: There are too many operations 
happening at the same time: Reached max number of sessions in session pool: 1000

Soluciones provisionales:

  • Reinicie la aplicación JCE si está experimentando algún impacto.

  • Al realizar una operación, es posible que tenga que finalizar la operación de JCE antes de perder la referencia a la operación.

    nota

    En función de la operación, puede ser necesario un método de finalización.

    Operación Método/s de finalización
    Cifrado

    doFinal() en modo de cifrado o descifrado

    wrap() en modo de encapsulamiento

    unwrap() en modo de desencapsulamiento
    KeyAgreement

    generateSecret() o generateSecret(String)
    KeyPairGenerator

    generateKeyPair() , genKeyPair(), o reset()
    KeyStore No se necesita ningún método.
    MAC

    doFinal() o reset()
    MessageDigest

    digest() o reset()
    SecretKeyFactory No se necesita ningún método.
    SecureRandom No se necesita ningún método.
    Signature

    sign() en modo de señal

    verify() en modo de verificación

Estado de la resolución: hemos resuelto este problema en el SDK del cliente 5.9.0 y versiones posteriores. Para solucionar este problema, actualice su SDK del cliente a una de estas versiones.

Problema: pérdida de memoria de Client SDK 5 con operaciones de getKey

  • Impacto: la operación getKey de la API tiene una pérdida de memoria en la JCE en las versiones 5.10.0 y anteriores de Client SDK. Si usa la API de getKey varias veces en su aplicación, esto aumentará el crecimiento de la memoria y, en consecuencia, aumentará el consumo de memoria de la aplicación. Con el tiempo, esto puede provocar errores de limitación o requerir el reinicio de la aplicación.

  • Solución alternativa: recomendamos actualizar a Client SDK 5.11.0. Si esto no es posible, recomendamos que no llames a la API de getKey varias veces en la aplicación. En cambio, reutilice la clave devuelta anteriormente de la operación getKey anterior en la medida de lo posible.

  • Estado de la resolución: actualice el SDK del cliente a la versión 5.11.0 o posterior, que incluye una corrección para este problema.