Sebastien Rousseau
Contactar ›

Infraestructura de pagos poscuántica: por qué los bancos reemplazarán los carriles heredados en lugar de adaptarlos

ML-KEM y ML-DSA no encajan limpiamente en los carriles que transportan SWIFT MT e ISO 20022. La respuesta honesta de ingeniería es que la adaptación es un plan de migración controlado con vida útil corta, y el reemplazo es el único destino estable.

13 min de lectura

Infraestructura de pagos poscuántica: por qué los bancos reemplazarán los carriles heredados en lugar de adaptarlos

Las primitivas criptográficas que autentican hoy cada pago mayorista en producción —RSA, ECDSA, ECDH— tienen fecha de caducidad. La Quantum Computing Cybersecurity Preparedness Act ⧉ estadounidense inscribió esa caducidad en la ley federal de adquisiciones a finales de 2022. El BIS Working Paper N.º 1208 ⧉ trasladó la misma caducidad al marco supervisor de los bancos centrales. NIST FIPS 203 ⧉ y FIPS 204 ⧉ publicaron los reemplazos en agosto de 2024.

La infraestructura de pagos todavía no ha asimilado lo que eso significa.

Este artículo es la defensa de ingeniería del reemplazo frente a la adaptación. Está escrito para arquitectos que ya entienden los algoritmos y deben decidir qué hacer con SWIFT MT, los mensajes pacs y pain de ISO 20022, las interfaces RTGS, los parques de HSM y las jerarquías de certificados que sostienen todo lo anterior.

Resumen ejecutivo / Conclusiones clave

  • Recolectar-ahora-descifrar-después (HNDL) es la amenaza operativa. Los adversarios graban hoy tráfico de pagos cifrado para descifrarlo cuando exista un computador cuántico criptoanalíticamente relevante (CRQC). El tráfico capturado incluye instrucciones de liquidación, datos de beneficiarios y material de autenticación con sensibilidad de larga duración.
  • NIST ha estandarizado los reemplazos. ML-KEM (FIPS 203) para encapsulamiento de clave y ML-DSA (FIPS 204) para firma digital son las opciones por defecto. SLH-DSA (FIPS 205) cubre el respaldo sin estado basado en funciones hash.
  • El delta de tamaño rompe los supuestos heredados. Las claves públicas y las firmas son entre 5 y 20 veces mayores que sus equivalentes RSA-2048. Eso choca con la MTU de las redes de pagos, con los supuestos de búfer fijo de los gestores de mensajes MT y con el rendimiento criptográfico de los parques de HSM instalados.
  • El híbrido (clásico + PQC) es el vehículo de migración, no el destino. TLS híbrido y X.509 híbrido compran entre dos y tres años de interoperabilidad mientras se reemplazan los carriles de producción. No resuelven el problema de capacidad subyacente.
  • La PKI es el muro de carga. Una autoridad de certificación cuyo algoritmo de firma pueda falsificarse invalida todos los certificados que cuelguen de ella. La exposición institucional del banco es la cadena, no ningún extremo individual.
  • La cripto-agilidad es la propiedad arquitectónica que hay que diseñar. Los identificadores de algoritmo, los formatos de clave, los envoltorios de firma y las particiones de HSM deben ser parametrizables. Todo lo que esté fijado a RSA en tiempo de compilación es deuda técnica que vencerá de golpe.

Recolectar ahora, descifrar después: el modelo de amenaza que elimina la opción de esperar #

HNDL invierte la línea temporal criptográfica habitual. La evaluación de riesgos convencional pregunta cuándo se materializa la amenaza. HNDL pregunta cuándo los datos capturados hoy le resultan útiles al adversario. Para los mensajes de pago —identidades de beneficiarios, números de cuenta, datos estructurados de remesa, cargas para cribado de sanciones, instrucciones de liquidación intrabancarias— la ventana de sensibilidad va de años a décadas. La mayor parte de ese tráfico está siendo grabado en algún sitio ahora mismo.

El calendario de CNSA 2.0 de la NSA ⧉ da a los sistemas de seguridad nacional hasta 2035 para completar la transición. Los supervisores financieros van más rápido: las expectativas de la PRA sobre resiliencia operativa ⧉ tratan la agilidad criptográfica como un riesgo de concentración con terceros. La expectativa en 2026 es que los carriles de pago materiales publiquen su plan de migración a PQC dentro de su auto-atestación de resiliencia.

El adversario HNDL no necesita un CRQC hoy. El adversario necesita:

  1. Posición de red. Las escuchas en cable submarino, la captura a nivel de ISP y los middleboxes comprometidos entran en alcance. El tráfico de pagos mayoristas se concentra en un número reducido de rutas de red.
  2. Almacenamiento. Un petabyte de datos estructurados de pagos es un archivo manejable en 2026.
  3. Paciencia. La captura cuesta cero por mensaje interceptado. El rendimiento llega después.

El argumento de migración no es, por tanto, «los computadores cuánticos pueden llegar en 2035». Es «toda sesión TLS que se complete esta noche con intercambio de claves RSA-2048 queda expuesta durante todo el tiempo en que los datos que contiene sigan siendo sensibles».

El problema de tamaño es el problema de ingeniería #

El debate público sobre la migración a PQC suele centrarse en la elección del algoritmo. El problema más duro es dimensional.

Primitiva Clave pública Firma / texto cifrado
RSA-2048 256 bytes 256 bytes (firma)
ECDSA P-256 64 bytes 64 bytes (firma)
ML-KEM-768 1.184 bytes 1.088 bytes (texto cifrado)
ML-DSA-65 1.952 bytes 3.309 bytes (firma)
SLH-DSA-128f 32 bytes 17.088 bytes (firma)

Esas cifras se traducen directamente en modos de fallo para los que nunca se diseñó la infraestructura de pagos heredada:

La vía de adaptación consiste en triar esas restricciones una a una —búferes más grandes aquí, HSM más rápidos allá, tolerancia a la fragmentación en los middleboxes—. Es un puente defendible de seis meses. No es una arquitectura.

Adaptación frente a reemplazo: la decisión que define el programa #

El planteamiento honesto es que la adaptación es un plan de migración controlado con vida útil corta, y el reemplazo es el único destino estable. La decisión es cuál financia primero el banco y cuánto tiempo permanece abierta la ventana de adaptación antes de convertirse en un apaño permanente.

Adaptar significa:

Ese trabajo se puede hacer. No corrige el problema de fondo: SWIFT MT y muchas implementaciones de ISO 20022 codifican el envoltorio criptográfico dentro de un formato de mensaje que fija el algoritmo. La siguiente transición de algoritmo —y la habrá, cuando ML-KEM acabe mostrando debilidad o cuando un nuevo estándar la supere— vuelve a correr la misma migración sobre los mismos carriles.

Reemplazar significa aceptar que la capa criptográfica no es una propiedad del formato de mensaje. Es una propiedad de un servicio de envoltorio separable al que invoca el formato de mensaje. En concreto:

El diseño de reemplazo sobrevive al siguiente cambio de algoritmo sin volver a tocar el carril.

La arquitectura cripto-ágil, capa a capa #

Las capas de infraestructura que importan para la migración PQC no son las capas de negocio de «datos, control, economía» que encajan en una narrativa bancaria genérica. Las capas que importan son criptográficas.

Capa Qué hace La pregunta PQC Directriz arquitectónica
HSM / gestión de claves Genera, almacena y opera sobre material de clave bajo aislamiento hardware ¿El firmware del HSM instalado admite ML-KEM, ML-DSA y una API de encapsulamiento de clave híbrida? ¿Cuál es el delta de rendimiento de firma frente a ECDSA en el mismo hardware? Inventariar cada partición de HSM por soporte de algoritmo y capacidad por segundo. Desmantelar todo lo que esté fijado a RSA sin vía firmware. Levantar particiones PQC dedicadas antes del corte a producción.
PKI / autoridad de certificación Emite, revoca y encadena confianza mediante certificados X.509 ¿Puede la CA firmar hoy con ML-DSA? ¿Existe un proceso probado de rotación de la raíz y reemisión de la cadena? ¿Están los respondedores CRL y OCSP dimensionados para el peso de firma ML-DSA? Tratar la pila de CA como muro de carga. Establecer ya una subordinada con capacidad PQC. Programar la rotación de la raíz por la dependencia de certificado más longeva, no por conveniencia.
Transporte / red Termina TLS, IPsec y MACsec entre los extremos de pago ¿El balanceador, el WAF y la ruta de middleboxes toleran handshakes híbridos que superan la MTU heredada? ¿Los tickets de reanudación de sesión están dimensionados para claves PQC? Trasladar la terminación TLS a una frontera cripto-ágil (sidecar o malla). Subir la política de MTU en las VPN de pagos. Probar la ruta completa induciendo fragmentación deliberada.
Aplicación / carga de mensaje Transporta mensajes SWIFT MT, ISO 20022 pacs / pain / camt y sus envoltorios criptográficos ¿El gestor de mensajes del carril tolera envoltorios firmados del tamaño de ML-DSA? ¿Son los analizadores intermedios conscientes del algoritmo o truncan por longitud? Separar envoltorio y carga. Firmar en una frontera de servicio, no dentro del gestor del formato de mensaje. Tratar los identificadores de algoritmo como datos, no como esquema.
Auditoría / evidencia Produce la cadena criptográfica de custodia en la que confían supervisores y clientes ¿Siguen siendo verificables los registros firmados históricos cuando el algoritmo de firma queda obsoleto? ¿Hay plan de firma de archivo a largo plazo? Contrafirmar los archivos con una primitiva basada en hash (SLH-DSA) para una garantía que sobreviva a la rotura de cualquier algoritmo individual. Tratar la cadena de auditoría como artefacto regulado, no como subproducto del build.

La disciplina consiste en convertir cada elección de algoritmo, en cada capa, en un valor de configuración. La institución que codifique RSA-2048 a fuego en cualquiera de esas capas hereda un evento coordinado de fin de vida cuando ese algoritmo caiga.

Qué significa esto por tipo de banco #

El perfil de exposición difiere según la institución. Las directrices también.

Bancos globales #

Los bancos globales operan los parques de HSM más grandes, las cadenas de certificados más largas y las rutas de red más complejas entre contrapartes. El riesgo dominante no es la elección del algoritmo: es el coste de coordinación de cambiar algoritmos en cientos de servicios internos y decenas de contrapartes externas a la vez.

La directriz es financiar la CA con capacidad PQC, la frontera de transporte cripto-ágil y el servicio de firma parametrizado por algoritmo como trabajo de 2026, antes de adaptar ningún carril. La adaptación se convierte entonces en un cambio rutinario de producción dentro de un marco conocido. Sin ese marco, cada adaptación de carril vuelve a litigar las mismas decisiones arquitectónicas.

Bancos regionales #

Los bancos regionales tienen menos superficie algorítmica, pero proporcionalmente menos personal especializado. El riesgo dominante es el bloqueo a un proveedor de HSM que no se ha comprometido a soportar los algoritmos requeridos.

La directriz es incluir el soporte PQC —en concreto ML-KEM y ML-DSA, con vía de actualización de firmware probada— en cada renovación de contrato de HSM desde 2026 en adelante. Los bancos sin esa cláusula heredan una sustitución forzada de hardware en el calendario del proveedor, no en el suyo.

Fintechs y PSP #

Los proveedores de servicios de pago y las fintech suelen situarse entre una contraparte bancaria y un sistema de comercio o de usuario final. Su exposición criptográfica es la frontera de API en ambos lados.

La directriz es publicar una interfaz TLS híbrida —clásica más ML-KEM— en el lado bancario como requisito de partida en las conversaciones comerciales de 2026. La fintech que llega con la interoperabilidad PQC ya demostrada gana ciclos de integración frente a la que aún no ha empezado.

Tesoreros corporativos #

Los tesoreros no operan directamente infraestructura criptográfica. Sí la consumen: cada API bancaria, cada transferencia segura de fichero, cada confirmación firmada depende de la PKI del banco.

La directriz es añadir tres preguntas a cada RFP bancaria en 2026: qué algoritmos PQC usa el banco hoy en TLS de cara al cliente, cuál es el plan del banco para confirmaciones de pago firmadas con ML-DSA y cómo piensa el banco preservar la verificabilidad de los registros firmados históricos una vez RSA quede obsoleto. Los bancos que no puedan responder esas preguntas están señalando algo sobre su preparación de ingeniería subyacente.

Qué viene a continuación #

La primera ola de despliegue PQC en pagos será invisible para el usuario final. TLS híbrido aparece en el handshake, las cadenas de certificados crecen, la latencia de firma del HSM sube unos milisegundos y los carriles siguen operando. Esa es la vía del éxito.

Los fallos visibles vendrán por el lado de la adaptación: un carril que no acepta un envoltorio firmado con ML-DSA sin truncarlo, una CA cuyo punto de distribución CRL se atraganta con el nuevo peso de firma, un middlebox que fragmenta los handshakes híbridos en ClientHellos reordenados. Esos fallos aterrizarán en producción a lo largo de 2027.

La decisión arquitectónica de 2026 es si se financia la infraestructura de reemplazo que vuelve irrelevante a la adaptación, o si se financia una secuencia de arreglos por carril que individualmente parecen más baratos y que en conjunto suman una migración más larga y más cara. El banco que elija el primer camino correrá operaciones más silenciosas durante la transición. El que elija el segundo pasará el resto de la década explicando revisiones de incidentes a los supervisores.

La PQC no es un problema de criptografía disfrazado de problema de infraestructura. Es un problema de infraestructura que la criptografía resulta haber iniciado.

Preguntas frecuentes #

¿Hay un plazo que obligue a este trabajo?

Los plazos regulatorios duros son jurisdiccionales. La Quantum Computing Cybersecurity Preparedness Act ⧉ estadounidense vincula a los sistemas federales. El calendario CNSA 2.0 de la NSA ⧉ apunta a 2035 para los sistemas de seguridad nacional. La publicación del BIS Project Leap ⧉ y el programa de trabajo del FSB están adelantando ese horizonte para la infraestructura de pagos sistémica. HNDL implica que el reloj operativo empezó a correr mucho antes de cualquiera de esas fechas nominales.

¿Por qué se recomienda ML-KEM como encapsulamiento de clave en lugar de algo más rápido?

ML-KEM (la versión estandarizada de CRYSTALS-Kyber) ofrecía la mejor combinación de texto cifrado y tamaño de clave reducidos entre los candidatos basados en retículos, con implementaciones maduras y endurecimiento frente a canales laterales. NIST lo publicó como FIPS 203 ⧉. Existen candidatos más rápidos, pero acarrean mayor tamaño o intervalos de confianza más débiles sobre los parámetros de seguridad.

¿Por qué no usar SLH-DSA en todas partes en lugar de ML-DSA?

SLH-DSA (la versión estandarizada de SPHINCS+) está basada en funciones hash y, por tanto, solo depende de la seguridad de la función hash, que es el supuesto más conservador disponible. Sus firmas son entre 5 y 20 veces mayores que las de ML-DSA. Eso es aceptable para contrafirma de archivo, pero inviable para firma transaccional, donde el tamaño cuenta por mensaje. El patrón estándar es ML-DSA para firma de producción y SLH-DSA para garantía de archivo.

¿Puede un banco esperar a que los carriles publiquen perfiles PQC?

El banco que espera hereda la ventana de migración que publique el carril, que es más corta que su propio ciclo interno de cambio. Cuando SWIFT, el operador local de RTGS y los CCPs relevantes publiquen cada uno su perfil PQC, la ventana de migración será de doce a veinticuatro meses. Los bancos que no hayan preconstruido su capacidad de CA, transporte y HSM no la cumplirán sin atajos operativos.

¿Cuál es el único elemento de mayor palanca que financiar primero?

Una autoridad de certificación subordinada con capacidad PQC, integrada en la PKI existente, capaz de emitir certificados de doble algoritmo (RSA más ML-DSA) sin alterar la confianza en producción. Eso establece la primitiva de rotación. Todo lo demás —actualizaciones de transporte, planificación de particiones de HSM, cambios en los envoltorios de mensaje— se puede programar a su alrededor.

Referencias #

Última revisión .

Última revisión .