La plataforma permite a organizaciones definir qué variantes del esquema FIPS 204 pueden usarse en sus entornos, con controles preventivos y detectivos a nivel de cuenta
AWS publicó la segunda parte de su serie técnica sobre firma resistente a cuántica, enfocada esta vez en la gobernanza: cómo traducir una política criptográfica organizacional en controles ejecutables que impidan la creación o uso de variantes no aprobadas del esquema ML-DSA (FIPS 204). El esquema, estandarizado por NIST como parte de su programa de criptografía post-cuántica, está disponible en AWS KMS en tres conjuntos de parámetros — ML-DSA-44, ML-DSA-65 y ML-DSA-87 — que apuntan a las categorías de seguridad NIST 2, 3 y 5 respectivamente. La publicación documenta cómo una organización que haya decidido estandarizar en ML-DSA-65 y ML-DSA-87 puede hacer cumplir esa decisión de forma consistente en toda su infraestructura AWS, bloqueando la introducción de ML-DSA-44 sin afectar la operación de las variantes aprobadas.
Tres variantes, tres compromisos entre tamaño y margen de seguridad
ML-DSA-44 produce una clave pública de 1312 bytes y una firma de 2420 bytes, siendo la variante más compacta y rápida de las tres. ML-DSA-65 y ML-DSA-87 generan claves y firmas más grandes, pero ofrecen un margen de seguridad mayor — la cantidad de fortaleza criptográfica que un conjunto de parámetros mantiene en reserva por encima de su categoría de seguridad objetivo. Ese margen adicional es lo que se busca para firmas que deben permanecer confiables durante toda su vida útil, como las de autoridades de certificación raíz o claves de firma de código de larga vigencia.
La arquitectura presentada en la primera parte de la serie desplegaba ML-DSA-87 para la autoridad de certificación raíz y ML-DSA-65 para la CA subordinada y la clave de firma de código. La segunda parte toma esa decisión de diseño y la convierte en política ejecutable: el ejemplo de control organizacional que documenta AWS estandariza en ML-DSA-65 y ML-DSA-87, excluyendo ML-DSA-44 del conjunto aprobado. AWS aclara que esto es una decisión de estandarización, no un juicio sobre la seguridad de ML-DSA-44 — la variante de categoría 2 es un parámetro plenamente válido según FIPS 204, con seguridad clásica equivalente a 128 bits, y es la opción más adecuada para dispositivos con recursos limitados, firmas de alto volumen o escenarios sensibles al ancho de banda.
Controles preventivos en tres capas de la API de AWS
Los controles operan sobre las superficies de API de AWS KMS, AWS Private Certificate Authority y AWS Certificate Manager. El objetivo concreto es que ningún principal dentro del alcance pueda crear material de clave ML-DSA-44, usar claves ML-DSA-44 existentes para firma o verificación, ni establecer autoridades de certificación privadas que introduzcan esa variante. AWS propone una combinación de Service Control Policies a nivel de organización o unidad organizacional, políticas de IAM y permission boundaries a nivel de cuenta, según el grado de prescripción que requiera el modelo operativo de cada organización.
Las SCP aplicadas en la raíz de la organización impiden que cuentas miembro creen o usen claves ML-DSA-44 — las SCP no se aplican a la cuenta de administración, por lo que las cargas de trabajo ahí no quedan restringidas. Una SCP aplicada solo a una unidad organizacional de producción restringe únicamente las cuentas de ese entorno. Si se necesita flexibilidad dentro de una cuenta específica, AWS recomienda usar permission boundaries de IAM en lugar de configuraciones a nivel de cuenta impuestas por SCP. Los ejemplos de política están escritos para aplicarse en todas las regiones de AWS; si se requiere alcance regional, se agrega una condición aws:RequestedRegion.
Qué queda fuera del alcance de estos controles
Los controles no gobiernan criptografía que se ejecute en cómputo controlado por el cliente. Una aplicación o biblioteca como OpenSSL puede realizar firma ML-DSA-44 dentro de una instancia EC2, un contenedor o una función Lambda sin que las SCP o políticas de IAM puedan impedirlo. El uso a nivel de protocolo — como la autenticación de clave pública híbrida ssh-mldsa44-ed25519 de OpenSSH — también está fuera del alcance. El material de certificado importado a través de acm:ImportCertificate o iam:UploadServerCertificate no es consciente del algoritmo, por lo que no puede ser filtrado por estos mecanismos. Otros servicios de terminación TLS o firma, como CloudFront y API Gateway, y servicios como IAM Roles Anywhere no están cubiertos en esta publicación y deben evaluarse por separado.
AWS posiciona estos controles como defensa en profundidad, aplicables en su totalidad o en subconjuntos según el nivel de prescripción que requiera cada organización. Las políticas documentadas son puntos de partida ilustrativos — la autoría, validación y mantenimiento de las SCP, políticas de IAM y permission boundaries específicas para cada entorno es responsabilidad del cliente, y AWS recomienda probar todas las políticas en un entorno no productivo antes del despliegue.
Impacto en organizaciones de América Latina con infraestructura AWS
Organizaciones en Brasil, México, Argentina y Chile que operan cargas de trabajo reguladas en AWS — especialmente en sectores financiero, salud y gobierno — enfrentan el mismo problema de gobernanza criptográfica que motivó esta publicación: cómo asegurar que una decisión de estandarización tomada por equipos de seguridad o cumplimiento se traduzca en controles técnicos ejecutables, sin depender de revisión manual o auditoría posterior. La disponibilidad de controles preventivos a nivel de API permite que esa estandarización se aplique de forma consistente en entornos multi-cuenta, algo particularmente relevante en organizaciones con estructuras descentralizadas o equipos de desarrollo distribuidos geográficamente.
El caso de uso documentado — una cadena de suministro de software con firma de binarios, imágenes de contenedor y SBOM usando ML-DSA — es directamente aplicable a organizaciones que están construyendo pipelines de CI/CD con requisitos de integridad verificable, un patrón cada vez más común en implementaciones de DevSecOps en la región. La capacidad de definir qué variantes de un esquema post-cuántico pueden usarse en producción, mientras se permite experimentación con otras variantes en entornos de desarrollo, es un requisito operativo que no tiene equivalente directo en esquemas de firma clásicos como RSA o ECDSA, donde la decisión de política se reduce a longitud de clave.
Nuestro análisis
Esta publicación documenta un patrón de control que va a repetirse con cada esquema criptográfico post-cuántico que AWS y otros proveedores de nube incorporen: la necesidad de traducir decisiones de estandarización en controles de API ejecutables, porque la diversidad de parámetros dentro de un mismo esquema estandarizado — tres variantes en el caso de ML-DSA, pero potencialmente más en esquemas futuros — convierte la gobernanza criptográfica en un problema de política técnica, no solo de configuración. El hecho de que AWS haya publicado esto como segunda parte de una serie técnica, separando la implementación de la gobernanza, refleja que la adopción de criptografía post-cuántica en entornos empresariales no es solo un problema de ingeniería de software — es un problema de arquitectura de control.
Lo que esta publicación no resuelve, y lo declara explícitamente, es el problema de criptografía que se ejecuta fuera de las API gestionadas de AWS: cualquier cosa que corra en cómputo controlado por el cliente queda fuera del alcance de estos controles. Eso incluye casos de uso tan comunes como autenticación SSH con claves post-cuánticas o firma de artefactos dentro de contenedores. Para organizaciones que necesiten gobernanza criptográfica de extremo a extremo, estos controles de API son un primer paso necesario pero no suficiente — el siguiente paso, que AWS no documenta aquí, es cómo extender esa política a criptografía que se ejecuta en el plano de datos, no en el plano de control. ¿Qué pasaría si una organización estandariza en ML-DSA-65 y ML-DSA-87 a nivel de política de AWS, pero sus aplicaciones siguen usando ML-DSA-44 en cómputo propio porque nadie auditó las dependencias de las imágenes de contenedor?