Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Notificaciones de obsolescencia
<a name="compliance-dep-notif"></a>

De vez en cuando, AWS CloudHSM puede dejar de funcionar una funcionalidad para seguir cumpliendo con los requisitos de la FIPS 140,,, PCI-DSS PCI-PIN PCI-3DS, SOC2 o debido a la finalización del soporte del hardware. Esta página detalla los cambios que se aplican actualmente.

## Obsolescencia de HSM1
<a name="hsm-dep-1"></a>

 El soporte del tipo de instancia AWS CloudHSM hsm1.medium finalizará el 31 de marzo de 2026. Para garantizar la continuidad del servicio, presentamos los siguientes cambios: 
+  A partir de abril de 2025, ya no podrá crear nuevos clústeres hsm1.medium. 
+  A partir de enero de 2026, comenzaremos a migrar automáticamente los clústeres hsm1.medium existentes al nuevo tipo de instancia hsm2m.medium. 

 El tipo de instancia hsm2m.medium es compatible con tu tipo de instancia actual y ofrece un rendimiento mejorado. AWS CloudHSM Para evitar interrupciones en las aplicaciones, debe actualizar a la versión más reciente del SDK de cliente. Para obtener instrucciones de actualización, consulte [Migración del SDK de AWS CloudHSM cliente 3 al SDK de cliente 5](client-sdk-migration.md). 

 Tiene dos opciones para la migración: 

1.  Opte por una CloudHSM-managed migración cuando esté listo. Para obtener más información, [Migración de hsm1.medium a hsm2m.medium](hsm1-to-hsm2-migration.md). 

1.  Crear un nuevo clúster hsm2m.medium a partir de una copia de seguridad del clúster hsm1 y redirigir la aplicación al nuevo clúster. Recomendamos utilizar una estrategia blue/green de despliegue para este enfoque. Para obtener más información, consulte [Crear AWS CloudHSM clústeres a partir de copias de seguridad](create-cluster-from-backup.md). 

## Cumplimiento de la normativa FIPS 140: anulación de mecanismo 2024
<a name="compliance-dep-notif-1"></a>

El Instituto Nacional de Estándares y Tecnología (NIST) [1](#dep-notif-1) recomienda no admitir el cifrado triple DES (DeSede, 3DES, DES3) ni el encapsulado y desencapsulado de claves RSA con padding PKCS \#1 v1.5 a partir del 31 de diciembre de 2023. Por lo tanto, la compatibilidad con ellos finalizará el 1 de enero de 2024 en nuestros clústeres conformes al Federal Information Processing Standard (FIPS). La compatibilidad con ellos seguirá siendo para clústeres en modo no FIPS.

Esta guía se aplica a las siguientes operaciones criptográficas:
+ Generación de claves Triple DES
  + `CKM_DES3_KEY_GEN` para la biblioteca PKCS \#11
  + `DESede` Keygen para el proveedor de JCE
  + `genSymKey` con `-t=21` para KMU
+ Cifrado con claves Triple DES (nota: se permiten operaciones de descifrado)
  + Para la biblioteca PKCS \#11: cifrado `CKM_DES3_CBC`, cifrado `CKM_DES3_CBC_PAD` y cifrado `CKM_DES3_ECB`
  + Para el proveedor de JCE: cifrado `DESede/CBC/PKCS5Padding`, cifrado `DESede/CBC/NoPadding`, cifrado `DESede/ECB/Padding` y cifrado `DESede/ECB/NoPadding`
+ Encapsulado, desencapsulado, cifrado y descifrado de claves RSA con padding PKCS\#1 v1.5
  + Encapsulado, desencapsulado, cifrado y descifrado de `CKM_RSA_PKCS` para el SDK de PKCS\#11
  + Encapsulado, desencapsulado, cifrado y descifrado de `RSA/ECB/PKCS1Padding` para el SDK de JCE
  + `wrapKey` y `unWrapKey` con `-m 12` para KMU (tenga en cuenta que `12` es el valor del mecanismo `RSA_PKCS`)

[1] Para obtener más información sobre este cambio, consulte las tablas 1 y 5 de la sección [Transición en el uso de algoritmos criptográficos y longitudes de clave](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf).