Problemas conocidos del SDK de JCE para AWS CloudHSM

• 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.

• 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 la resolución: puede utilizar el almacén de AWS CloudHSM claves para almacenar los certificados.

Multi-part AES-GCM no se admite el cifrado.

• Impacto: no se puede utilizar AES-GCM para cifrar datos de más de 16.000 bytes.

• Solución alternativa: puede utilizar un mecanismo alternativo, por ejemplo, dividir los AES-CBC datos en partes y cifrar cada una de ellas de forma individual. Si divide los datos, debe administrar el texto cifrado dividido y su descifrado. Como el FIPS requiere que el vector de inicialización (IV) AES-GCM se genere en el HSM, el IV de cada AES-GCM-encrypted dato 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.

• Impacto: Client SDK 3 agrega la funcionalidad ECDH al JCE. Cuando se utiliza la KeyAgreement clase para derivar un 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 alternativa: si está implementando SSL/TLS Offload en AWS CloudHSM, es posible que esta limitación no suponga 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 la resolución: el SDK 5.16 ahora admite ECDH con derivación de claves, que se ejecuta completamente dentro del HSM.

• 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 usar la KeyGenerator clase o KeyAttribute enumeración para generar claves con el proveedor AWS CloudHSM JCE si utiliza las versiones 5.4.0 a 5.4.2 del SDK de cliente.

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

• 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

• 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 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 llame a la API 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.