El 1 de enero de 2024 marcó un hito en la historia de la criptografía moderna: El algoritmo Triple DES (3DES/TDES o TDEA) fue catalogado como «obsoleto» por NIST. Esta noticia hace parte de los esfuerzos de la migración hacia algoritmos más seguros en la carrera hacia la criptografía post-cuántica (PQC), pero afectará múltiples entornos que hacían uso de este algoritmo, principalmente en la industria financiera. En este artículo se analiza su impacto en la seguridad y en el cumplimiento de los estándares del PCI SSC.

Introducción

Mediante el uso de la criptografía se pretende proteger un mensaje confidencial empleando de un algoritmo y una clave. No obstante, no todos los algoritmos y no todas las claves ofrecen los mismos niveles de seguridad. La búsqueda de las debilidades de estos elementos se conoce como «criptoanálisis».

En términos prácticos, la fortaleza de un sistema de cifrado se expresa en un valor conocido como «factor de trabajo» que puede ser medido en horas de tiempo computacional o el coste económico de los recursos invertidos para romper el cifrado. Si el factor de trabajo es suficientemente alto, se considera que el sistema de encriptación es «invulnerable». Obviamente, esta afirmación solamente es válida para un periodo de tiempo particular, ya que se debe tener en cuenta la evolución tecnológica, el abaratamiento de recursos de hardware y las vulnerabilidades propias de los algoritmos que hacen que la «invulnerabilidad» de un criptosistema al día de hoy lo hagan vulnerable en un futuro próximo. Ejemplos claros son la ruptura del cifrado de la máquina ENIGMA, los ataques de fuerza bruta al algoritmo RC4 de 40 bits de Netscape, la «máquina para romper DES» de la EFF, Crack.sh: The World’s Fastest DES Cracker, entre otros.

Es por ello que, para proteger de forma eficaz la confidencialidad y la integridad de los activos de información de una organización, se hace indispensable el uso de algoritmos robustos y longitudes de clave lo suficientemente largas, en conjunto con una evaluación periódica de vulnerabilidades para garantizar que se cuenta con un nivel de seguridad tolerable para la organización en función de los niveles de criticidad de los datos protegidos.

Historia de Triple DES (TDEA)

Uno de los algoritmos de encriptación de cifrado por bloques que más se usó en el ámbito financiero a lo largo del siglo pasado fue el algoritmo Data Encryption Standard (DES), también conocido como Data Encryption Algorithm (DEA). DES, en conjunto con Lucifer, fueron originalmente desarrollados por Horst Feistel cuando trabajaba en el laboratorio Yorktown Heights de IBM. Años después, estos algoritmos fueron patentados por IBM y posteriormente DES fue publicado como estándar en 1975.

Patente de DES (H. Feistel, 1974)

DES usaba una longitud de clave de 64 bits (56 bits reales de clave y 8 bits de paridad) con bloques de datos de 64 bits, lo cual, después de un tiempo, lo haría vulnerable a diferentes ataques.

Estructura de una clave DES: 64 bits, de los cuales el último bit de cada octeto se usa como bit de paridad

Como respuesta a este problema, se empezó a hacer uso de dos algoritmos que empleaban la misma base de DES pero que agregaban nueva complejidad al proceso usando iteraciones y claves adicionales:

• Double-DES (2DES o 2DEA) usa dos instancias de DES en el mismo bloque de texto en claro. En cada instancia usa diferentes claves de cifrado. Actualmente, este algoritmo está obsoleto.

Double DES (K1 ≠ K2)

• Triple-DES (3DES o TDEA) usa tres instancias de DES en el mismo texto en claro, dividido en bloques de 64 bits cada uno. Triple DES opera en tres pasos: Encrypt-Decrypt-Encrypt (EDE). Funciona tomando tres claves de 56 bits (K1, K2 y K3) conocidas como key bundle y cifrando primero con K1, descifrando a continuación con K2 y cifrando una última vez con K3 (triple-length o three-key TDEA). Existe una versión de Triple DES de dos claves (double-length o two-key TDEA), en la que el mismo algoritmo se ejecuta tres veces pero se utiliza K1 para el primer y el último paso.

Double-length TDEA (K1 ≠ K2)

Triple-length TDEA (K1 ≠ K2 ≠ K3)

Dada su facilidad de implementación, Triple DES se convirtió en el estándar de facto para el cifrado de datos en bloques. Uno de los elementos que más aportó al uso y a la masificación de este algoritmo fue el desarrollo de dispositivos de seguridad de hardware (Hardware Security Modules – HSMs), que facilitaron las actividades de gestión de claves y de cifrado/descifrado en entornos seguros, principalmente en el sector financiero.

Vulnerabilidades en Triple DES (TDEA)

Cuando se utiliza Triple DES con tres claves independientes se tiene una longitud de clave de 168 bits (tres claves DES de 56 bits ((64 bits – 8 bits de paridad) x 3 claves = 168 bits de clave independientes). Sin embargo, debido a los ataques «meet-in-the-middle«, la seguridad efectiva que proporciona 3TDEA es de sólo 112 bits. Además, el tamaño del bloque de datos empleado (64 bits) lo hace vulnerable a ataques de colisión de bloques cuando se utiliza para cifrar grandes cantidades de datos con la misma clave, como una sesión HTTPS.

La seguridad de un cifrado por bloques suele reducirse al tamaño de la clave k: el mejor ataque debería ser la búsqueda exhaustiva de la clave, con una complejidad 2^k. Sin embargo, el tamaño de bloque n también es un parámetro de seguridad importante, ya que define la cantidad de datos que pueden cifrarse con la misma clave. Cuando la cantidad de datos cifrados con una clave fija se aproxima a este límite, las garantías de seguridad del modo de funcionamiento empiezan a degradarse.

Los cifrados DES y Triple DES tienen un límite de aproximadamente cuatro mil millones de bloques (aproximadamente 32 GB), lo que facilita a los atacantes remotos la potencial obtención de datos en texto claro mediante un ataque de cumpleaños (birthday attack) contra una sesión cifrada de larga duración, como una sesión HTTPS/TLS, SSH o IPSEC.

En el año 2016 varios investigadores lograron explotar esta vulnerabilidad asociada al tamaño de bloque en los algoritmos Triple DES y Blowfish, la cual afectó soluciones de seguridad que implementaban estos algoritmos, incluyendo plataformas de VPN, HTTPS/TLS, canales de telefonia 3G (UMTS), SSH, etc. Este ataque se denominó «Sweet 32» (catalogado bajo el CVE-2016-2183) y, como resultado de la comprobación de su viabilidad, el National Institute of Standards and Technology (NIST) restringió el uso de Triple DES en 2017 a solamente 2²⁰ bloques de 64 bits de datos utilizando un único juego de claves (key bundle) en el documento NIST SP 800-67 Rev. 2 – Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher. Esto significaba que ya no podía utilizarse eficazmente para TLS, IPsec, SSH o el cifrado de archivos de gran tamaño. Restricciones similares en los límites de bloques de datos producidos ya habían sido publicadas por el NIST en años anteriores:

• 2²⁰ bloques cuando dos de las tres claves son las mismas (2TDEA) en 2012
• 2³² bloques cuando las tres claves son únicas (3TDEA) en 2012, and
• 2²⁰ bloques para 3TDEA en 2017.

Debido en gran parte a esta vulnerabilidad, y para darle el impulso final que necesitaba Advanced Encryption Standard (AES) para convertirse en el remplazo de Triple DES, en el año 2018 el NIST estableció una fecha para la obsolescencia de Triple DES: finales de 2023.

DES (bloques de 64 bits) vs. AES (bloques variables desde 128 bits) – fuente: Techtarget

Obsolescencia de Triple DES (TDEA)

El National Institute of Standards and Technology (NIST) ha catalogado los algoritmos de cifrado y sus longitudes de clave en 6 grupos (NIST Special Publication 800-57 Part 1: Recommendation for Key Management -Part 1: General):

• Aprobado (Approved): El algoritmo se encuentra especificado en los documentos del NIST o hace parte de los algoritmos acreditados por el FIPS (Federal Information Processing Standard – Estándares Federales de Procesamiento de la Información) y puede ser empleado sin restricciones.
  
• Aceptable (Acceptable): El algoritmo y sus longitudes de clave son seguros para el uso y no se conocen riesgos de seguridad en ese momento
• Obsoleto (Deprecated): El uso del algoritmo y de la longitud de clave es permitido pero el usuario debe aceptar algunos riesgos.
• Restringido (Restricted): El uso del algoritmo o de la longitud de la clave está obsoleto y hay restricciones adicionales requeridas para procesos de protección criptográfica de datos. Desde el año 2015 esta categoría ya no se utiliza.
• Uso heredado (Legacy-use): El algoritmo o la longitud de clave puede ser usado para procesar datos previamente protegidos (desencriptar datos o verificar una firma digital) pero pueden existir riesgos en este proceso.
• No permitido (Disallowed): El algoritmo o la longitud de clave no son aceptados debido a los riesgos asociados.

Estados de aprobación de algoritmos de cifrado según NIST

Recurrentemente el NIST publica los cambios en la categorización de los algoritmos con base en estos grupos. En marzo de 2019, el NIST publicó el documento NIST Special Publication 800-131A Revision 2 – Transitioning the Use of Cryptographic Algorithms and Key Lengths en donde anunciaba los cambios de categoría de diferentes elementos criptográficos (cifrado simétrico en bloques, firmas digitales, generadores de números aleatorios, funciones de hash, etc.), incluyendo las fechas de obsolescencia para el algoritmo TDEA:

Estatus de aprobación de algoritmos simétricos usados para cifrado y descifrado (NIST SP-800-131Ar2)

Las restricciones de uso para TDEA de doble y triple clave son:

Two-key TDEA

• El cifrado de datos empleando two-key TDEA no está permitido (Disallowed).
• El descifrado de datos empleando two-key TDEA está permitido como uso heredado (legacy-use), por ejemplo para descifrar en el futuro copias de seguridad o datos almacenados protegidos con ese algoritmo.

Three-key TDEA

• A partir del 31 de diciembre de 2023 three-key TDEA no está permitido (Disallowed) para el cifrado de datos a menos que sea permitido por otras guías del NIST.
• El descifrado de datos empleando three-key TDEA está permitido como uso heredado (legacy-use), por ejemplo para descifrar en el futuro copias de seguridad o datos almacenados que fueron protegidos con ese algoritmo antes de su fecha de retirada.

Implicaciones e impacto de la obsolescencia de Triple DES (TDEA) en FIPS

A pesar de que el ámbito de operación del National Institute of Standards and Technology (NIST) se restringe a Estados Unidos, el anuncio de la obsolescencia de TDEA afecta muchas otras áreas, entre ellas la certificación de productos en el estándar FIPS (Federal Information Processing Standards), empleadas por las agencias del gobierno no militares y por contratistas en Estados Unidos y Canadá.

Uno de los estándares insignia de FIPS es el FIPS 140, que define los requerimientos en materia de seguridad para componentes criptográficos de hardware y de software que deben ser usados por departamentos y agencias del gobierno federal de Estados Unidos y Canadá, catalogando los productos en cuatro niveles de seguridad, del más bajo (1) al más alto (4). En el sitio web del NIST se mantiene un listado de productos validados en este estándar bajo el programa Cryptographic Module Validation Program (CMVP).

Los estándares FIPS 140-2 y FIPS 140-3 se encuentran actualmente activos y se han definido las siguientes fechas para la retirada de FIPS 140-2:

Estatus de FIPS 140-2 y FIPS 140-3

Estas fechas son importantes, ya que FIPS 140-2 y FIPS 140-3 incluyen un listado de algoritmos soportados. A partir del 31 de diciembre de 2023, las evaluaciones bajo FIPS 140-3 ya no podrán incluir TDEA, mientras que los dispositivos validados en FIPS 140-2 que usen TDEA solo lo podrán emplear para descifrado. Igualmente, a partir de septiembre de 2026 todos los módulos certificados en FIPS 140-2 serán catalogados como «históricos», solo usados bajo restricciones especiales.

En esencia, si se requiere criptografía, ésta debe validarse periódicamente. El NIST considera que la criptografía no validada no proporciona protección a la información o los datos o, lo que es lo mismo, los datos se considerarían texto sin formato no protegido. Si una agencia especifica que su información debe estar protegida criptográficamente, se deberán aplicar los estándares FIPS 140-2 o FIPS 140-3. Si se revoca el módulo criptográfico usado, la seguridad proporcionada por dicho módulo será considerada irrelevante.

Implicaciones e impacto de la obsolescencia de Triple DES (TDEA) en los estándares del PCI SSC

Como se había indicado anteriormente, el ámbito de aplicación de las consideraciones del NIST y de sus estándares FIPS se restringe a Estados Unidos y Canadá. No obstante, el PCI SSC (Payment Card Industry Security Standards Council) ha usado tradicionalmente referencias a las publicaciones del NIST como guías para la implementación de sus controles de seguridad, incluyendo criptografía.

De hecho, el concepto de criptografía robusta (strong cryptography) empleado en todos los estándares del PCI SSC (incluyendo PCI DSS) hace referencia explícita al documento NIST Special Publication 800-57 Part 1:

Significado de «criptografía robusta» (strong cryptography) según el PCI SSC

No obstante, este mismo estándar (NIST 800-57) indica que TDEA es un algoritmo obsoleto a partir del 1 de enero de 2024, :

Obsolescencia de TDEA en NIST Special Publication 800-57 Part 1 (pág. 54)

Por otro lado, el PCI SSC también usa FIPS 140-2 y FIPS 140-3 como elemento de validación para usar hardware criptográfico de seguridad (Hardware Security Module – HSM) en sus entornos:

PCI PIN:

FIPS 140-2/FIPS 140-3 en PCI PIN v3.1

PCI P2PE:

FIPS 140-2/FIPS 140-3 en P2PE v3.1

PCI 3DS:

FIPS 140-2 en PCI 3DS v1.0

PCI TSP:

FIPS 140-2 en PCI TSP v1.0

Teniendo en cuenta esto, si una entidad usa un dispositivo HSM validado en FIPS 140 las siguientes restricciones deberían aplicar:

• Si el dispositivo es FIPS 140-2, TDEA solamente se debería usar para descifrado.
• Si el dispositivo es FIPS 140-3, el uso de TDEA está obsoleto. De hecho, no se podría utilizar al no estar dentro de la lista de algoritmos aprobados.

Sin embargo, el PCI SSC ha sido flexible (hasta el día de hoy) con el uso de TDEA, permitiendo su implementación en la protección de datos sensibles en transacciones de pago mientras que se apliquen las siguientes restricciones, como se describe en el artículo «PCI SSC Cryptography Expert on Triple DEA» de su blog:

• Deshabilitar el parámetro de configuración de sesión KeepAlive y forzar nuevas claves de sesión mucho antes de que se transmita el umbral de 32 GB de datos. Nota: Aunque esta alternativa mitiga la vulnerabilidad «Sweet32», no refuerza el algoritmo criptográfico subyacente ni soluciona otros problemas del protocolo.
• Cifrar los datos en la capa de aplicación utilizando un cifrado más potente -por ejemplo, AES 256- en lugar de confiar en TDEA para la protección de los datos.
• Cambiar las claves TDEA con regularidad (por ejemplo, cada 256 transacciones o diariamente, lo que sea más frecuente).

De igual manera, en el mismo artículo se indica:

Además, el concepto de «criptografía robusta» en PCI DSS y otras normas PCI se basa en la aceptación por parte de organismos autorizados, incluido el NIST. Una vez que la TDEA sea totalmente desautorizada por dichas autoridades, dejará de ser considerada «criptografía fuerte» por el PCI SSC.

Aunque es probable que las excepciones heredadas para las implementaciones de hardware de PIN se eliminen gradualmente a lo largo de un período de tiempo más largo, las organizaciones deben considerar la planificación de la transición para todas las demás implementaciones de TDEA.

De forma complementaria, el PCI SSC publicó la FAQ #1570 (Does TDEA meet the requirements of “strong cryptography” as defined in PCI DSS?) que indica lo siguiente:

A finales de 2023, el NIST prohíbe el uso de TDEA de tres claves para proteger datos sensibles desde el punto de vista de la seguridad en los sistemas de información federales de Estados Unidos. Sin embargo, según NIST SP800-57 parte 1, TDEA utilizando tres claves todavía puede proporcionar una fuerza efectiva de 112 bits cuando se aplica utilizando una gestión de claves y modos de operación apropiados.

La definición de «criptografía robusta» se actualizó en PCI DSS v4.0 para hacer referencia al tamaño efectivo de la clave de la combinación algoritmo/clave en lugar de a algoritmos específicos; en concreto, la fuerza efectiva de la clave es de un mínimo de 112 bits, con la recomendación de utilizar sistemas que proporcionen una fuerza efectiva de 128 bits. Además, la «criptografía fuerte» requiere el uso de algoritmos probados y aceptados por la industria y prácticas adecuadas de gestión de claves.

En conclusión, la confirmación de la obsolescencia de TDEA por parte del PCI SSC es inevitable, aunque aún no se han establecido fechas formales.

Recomendaciones del asesor QSA

David Acosta (asesor cualificado para PCI DSS, PCI PIN, PCI 3DS, P2PE y PCI TSP), autor de este artículo, recomienda a título personal a todas las entidades que usan TDEA o dispositivos HSM validados por FIPS en sus entornos de cumplimiento que implementen las siguientes acciones proactivas ANTES de que el PCI SSC establezca fechas obligatorias para la retirada de TDEA:

Para PCI PIN/P2PE:

• En entornos de procesamiento de PIN sujetos al cumplimiento del estándar PCI PIN, empezar CUANTO ANTES con el soporte al formato 4 de ISO para el bloque de PIN (ISO 4 PIN block format) con el fin de emplear el algoritmo AES para el cifrado del PIN. De hecho, el PCI SSC publicó hace algunos años un Information Supplement en donde se describen todas las actividades a tener en cuenta antes, durante y después de este proceso: Information Supplement: Implementing ISO Format 4 PIN Blocks.
• Si se emplea Derived Unique Key Per Transaction (DUKPT) basado en ANSI X9.24 part 1, el riesgo de exposición de los datos protegidos por una clave TDEA se minimiza debido al uso de claves únicas por transacción. Por esta razón DUKPT permite el uso de TDEA de doble y triple clave. Sin embargo, es muy recomendable empezar a usar AES como algoritmo en DUKPT (AES DUKPT) y proceder con el remplazo de las claves base de derivación (Base Derivation Key – BDK).
• La migración de TDEA a AES también afecta el formato de bloques de claves (key blocks). En este caso, en vez de usar ANSI X9.143 (TR-31) que aplica a TDEA, se debe emplear un proceso de verificación de integridad que sea parte implícita del proceso de cifrado de claves, como se especifica en ANSI X9.102 «Symmetric Key Cryptography for the Financial Services Industry – Wrapping of Keys and Associated Data«.
• Igualmente, es importante recordar que en PCI PIN está prohibido el uso de claves fijas TDEA para el cifrado de PIN en dispositivos de puntos de interacción (Point-of-Interaction) y comunicaciones host-to-host desde enero de 2023.

Para PCI DSS:

• Si se emplea TDEA como parte de los conjuntos de cifrado de TLS, se recomienda remplazarlos por AES para evitar inconvenientes durante los escaneos internos y escaneos ASV (ver FAQ #1452: How does Triple DEA (TDEA) impact ASV Scan results?). La misma recomendación aplica para otros protocolos como IPSEC o SSH.
• Confirmar con los diferentes fabricantes de soluciones de hardware y software que incluyen rutinas criptográficas si soportan AES. De ser así, implementar la migración de TDEA a AES y actualizar las guías de configuración segura (req. 2.2.1 de PCI DSS v4.0).
• A pesar de que el requisito 12.3.3 de PCI DSS v4.0 entra en vigor a partir del 31 de marzo de 2025, se recomienda implementarlo cuanto antes para identificar los activos que usan TDEA y establecer un plan de acción proactivo para su migración:

Requisito 12.3.3 de PCI DSS v4.

En general:

• Si se emplean dispositivos HSM, es altamente recomendable revisar si el dispositivo está validado bajo PCI HSM aparte de estarlo bajo FIPS 140. Si este es el caso, configurar el dispositivo para que opere en modo PCI HSM (o modo PCI) en vez de FIPS, ya que bajo ese modo estará alineado con las restricciones propias del PCI SSC respecto al uso de TDEA.
• Como norma general, emplear AES (como mínimo de 128 bits, 256 bits recomendable) en vez de TDEA para cualquier implementación de software que se despliegue en producción, ya sea para la protección de datos en tránsito o en almacenamiento.

Como se puede concluir, la implementación de las anteriores recomendaciones le permitirán a la entidad adelantar el trabajo de migración de TDEA antes de que se defina una fecha límite por parte del PCI SSC, que seguramente será en el corto plazo. Todo esto con el fin de minimizar el impacto de esta migración en la operación y en la integración con otros sistemas tecnológicos y/o proveedores de servicio.

¿Tienes dudas respecto a la migración de TDEA a AES? Deja tus inquietudes en el formulario de comentarios.