Planteamiento y contexto
Una empresa cuenta con clientes móviles, web, dispositivos y APIs de terceros que todavía utilizan RSA o criptografía de curva elíptica. Diseña un plan de migración a criptografía poscuántica y explica la compatibilidad, el rendimiento, la rotación de claves y el rollback.
El NIST ha publicado los estándares FIPS 203, 204 y 205 para ML-KEM, ML-DSA y SLH-DSA. Esta entrevista no es un simple ejercicio de memorización de nombres: evalúa si puedes transformar la confidencialidad a largo plazo, los ciclos de vida de los clientes y el riesgo operativo en decisiones estructuradas por fases. Un borrador de TLS híbrido del IETF sigue siendo un borrador, por lo que no constituye una promesa universal de compatibilidad.
Qué está evaluando el entrevistador
El entrevistador busca ver un inventario de activos criptográficos reales, una distinción clara entre el establecimiento de claves y las firmas, una explicación del riesgo de «recolectar ahora para descifrar después» (harvest-now-decrypt-later), un diseño para la agilidad criptográfica y compuertas medibles de compatibilidad, tasa de fallos y rendimiento. También debes identificar qué decisiones requieren la revisión de los equipos de seguridad, cumplimiento, proveedores y producto.
Preguntas para aclarar primero
- ¿Qué datos deben permanecer confidenciales durante diez años o más y qué firmas requieren verificación a largo plazo?
- ¿Cómo se distribuyen las versiones de los clientes, las rutas de actualización de firmware, los períodos offline y las dependencias de terceros?
- ¿Dónde se encuentran los puntos de llamada a RSA, ECDH y ECDSA, las cadenas de certificados, los HSM y las copias de seguridad?
- ¿Tienen ciclos de vida independientes las claves de transporte, datos en reposo, firma de código y firma de tokens?
- ¿Cuáles son los presupuestos para la latencia del handshake, el tamaño de los mensajes, la CPU, la memoria y la tasa de fallos?
- ¿Puede mantenerse un algoritmo antiguo durante un periodo acotado y quién aprueba la degradación y el rollback de emergencia?
Una respuesta de 30 segundos
«Primero haría un inventario de los activos criptográficos y los tiempos de vida de confidencialidad para luego clasificarlos por exposición, dificultad de reemplazo y capacidad de actualización de los clientes. Separaría el establecimiento de claves de las firmas y utilizaría suites de algoritmos versionadas con detección de capacidades para modos clásicos, poscuánticos o híbridos, prohibiendo cualquier degradación silenciosa. Realizaría despliegues canary en servicios controlables y nuevos clientes mientras mido el éxito del handshake, el tamaño de respuesta, la CPU, el fallback y las métricas de rotación de claves. Solo expandiría la adopción tras superar las compuertas de compatibilidad, rendimiento, auditoría y rollback, conservando las claves de verificación antiguas sin emitir nuevas credenciales con el formato anterior.»
Respuesta detallada paso a paso
Paso 1: Inventariar algoritmos y tiempos de vida de los datos
Escanea TLS, VPN, RPC entre servicios, cifrado de bases de datos, copias de seguridad, firmas, certificados, firmware y puntos de llamada a SDKs de terceros. Para cada activo, registra el algoritmo, el tamaño de clave, el propósito, el responsable, el método de rotación, las versiones de cliente y el tiempo de vida de confidencialidad. Prioriza el tráfico que pueda recopilarse ahora y requiera secreto a largo plazo, seguido de las firmas que deban verificarse durante muchos años.
Paso 2: Crear niveles de riesgo y una línea base objetivo
Evalúa la criticidad del activo, la viabilidad de ataques, las ventanas de migración, la proporción de clientes no actualizables y el costo de reemplazo. La línea base debe definir qué conexiones nuevas requieren protección poscuántica o híbrida y cuáles conexiones antiguas pueden continuar únicamente dentro de una ventana de compatibilidad aprobada, corta y monitoreada. No conviertas la fecha de una computadora cuántica práctica en la única variable de decisión.
Paso 3: Convertir la criptografía en una capacidad reemplazable
Mantén el código de negocio independiente de las bibliotecas criptográficas mediante suites de algoritmos versionadas, tipos de clave y políticas de certificados. El servidor puede evaluar una declaración de capacidades, pero los clientes no deben elegir algoritmos débiles; un servicio de políticas debe ser capaz de pausar una suite, cambiar de proveedor y registrar el alcance. Los metadatos de texto cifrado y firma deben incluir una versión para que los formatos históricos sigan siendo identificables.
Paso 4: Seleccionar las rutas de establecimiento de claves y firmas
ML-KEM se utiliza para la encapsulación de claves, mientras que ML-DSA y SLH-DSA son estándares de firma; sus claves, certificados y rendimiento difieren. Para TLS, evalúa un handshake híbrido clásico más ML-KEM solo después de comprobar la implementación, el estado del borrador y el soporte en pasarelas y endpoints. Valida el tamaño de la cadena de certificados, el costo de verificación y los requisitos de archivado por separado para las firmas.
Paso 5: Definir límites de compatibilidad y rollback
Permite que los clientes nuevos seleccionen una suite mediante la detección de capacidades y ubica a los clientes antiguos en un pool de compatibilidad explícito. La degradación debe ser observable, acotada en el tiempo y aprobada por inquilino (tenant) o dispositivo; un handshake fallido no debe desencadenar un fallback ilimitado. El rollback debe retirar el nuevo punto de entrada de tráfico sin eliminar las claves públicas antiguas que aún se necesitan para la verificación. Registra el motivo, el alcance y los criterios de reactivación.
Paso 6: Medir costos con experimentos canary
Prueba el éxito de las conexiones, la latencia del handshake, el tamaño de los mensajes, la CPU, la memoria, el ancho de banda, el almacenamiento en caché de certificados y el rendimiento del HSM en servicios internos, clientes móviles actualizables e inquilinos de bajo riesgo. Realiza pruebas de carga en picos de tráfico, redes inestables, recuperación offline y múltiples regiones. Compara la sobrecarga poscuántica con los SLO de negocio; responde según la versión y el tipo de cliente en lugar de desactivar la política de seguridad a nivel global.
Paso 7: Coordinar claves, proveedores y auditoría
Define los periodos de generación, custodia, rotación, revocación, respaldo y destrucción para claves nuevas y antiguas. Verifica el soporte para el formato objetivo en HSMs, KMS de la nube, autoridades certificadoras, proxies y SDKs de terceros; registra los cambios de suite como eventos de auditoría. Seguridad es dueña de la política, Plataforma de la implementación, y Legal o Cumplimiento confirma los requisitos aplicables de retención y evidencias.
Paso 8: Establecer compuertas de lanzamiento y una salida a largo plazo
Las compuertas de lanzamiento deben incluir el éxito de compatibilidad, el presupuesto de rendimiento, la proporción de tráfico con algoritmos antiguos, el fallback anormal, el éxito de la rotación y la completitud de las auditorías. Asigna una línea de parada (stop line) y un responsable a cada etapa. Una vez que el tráfico en formato antiguo esté por debajo de su umbral, deja de emitir credenciales con el formato antiguo y luego revoca su aceptación tras una ventana de verificación. Conserva los registros de migración para que el próximo reemplazo de algoritmos comience con evidencia sólida.
Compensaciones y límites
Modo híbrido frente a modo puramente poscuántico
El modo híbrido reduce la dependencia de un único algoritmo nuevo, pero incrementa el tamaño del handshake, la complejidad de implementación y las pruebas de negociación. El modo puramente poscuántico plasma el objetivo más directamente, pero puede excluir a clientes no actualizables. Deja que la matriz de compatibilidad y las compuertas de riesgo tomen la decisión.
Nivel de seguridad frente a presupuesto de rendimiento
Claves, textos cifrados o firmas más grandes afectan la MTU, los handshakes, los cachés y el rendimiento del HSM. Mide el tráfico real y reserva un margen para redes móviles, CPUs de dispositivos y picos de concurrencia. La optimización del rendimiento no debe lograrse mediante una degradación silenciosa.
Rollback frente a retención de claves antiguas
El punto de entrada para el rollback y la destrucción de claves son decisiones independientes. Es posible que aún se requieran claves públicas antiguas para validar firmas históricas, por lo que un rollback no debe eliminarlas de inmediato. Detén la emisión de nuevas credenciales, restringe las nuevas conexiones, conserva la verificación de solo lectura y destruye las claves únicamente cuando haya suficiente evidencia.
Simulacros de fallos y plan de evolución
Un dispositivo antiguo no se puede actualizar
Construye un inventario de versiones de dispositivos, una pasarela aislada y una fecha de expiración explícita. Verifica que el aislamiento impida que la suite débil se propague a nuevos clientes y ofrece a los propietarios una ruta de actualización o reemplazo.
Un handshake más grande interrumpe las conexiones
Prueba la fragmentación, MTU, tiempos de espera (timeouts) y reintentos mediante proxies reales, balanceadores de carga y redes móviles. Si la nueva suite falla, regresa al pool de compatibilidad aprobado y emite una alerta; el cliente no debe intentar suites débiles adicionales por su cuenta.
Un proveedor solo admite firmas antiguas
Proporciona al proveedor una interfaz versionada y un certificado de transición, con tiempo de vida y permisos limitados para firmas antiguas. Incluye el compromiso de actualización en el contrato y en las métricas de aceptación en lugar de ocultar una dependencia descontrolada como «trabajo futuro».
Errores comunes y preguntas de seguimiento
Error 1: Tratar el reemplazo de algoritmos como un simple cambio de configuración
Seguimiento: ¿Cómo encuentras cada punto de llamada criptográfica, copia de seguridad y dispositivo offline? Una respuesta sólida menciona un inventario de activos, un grafo de dependencias y un responsable.
Error 2: Considerar la publicación de FIPS como soporte universal de clientes
Seguimiento: ¿Dónde se evidencia el soporte para la biblioteca de destino, la autoridad certificadora, el HSM, la pasarela y el navegador? Separa un estándar finalizado de una implementación de producto lista para usarse.
Error 3: Realizar un fallback silencioso a RSA
Seguimiento: ¿Quién aprueba la degradación, cuánto dura, cómo se alerta y qué le pone fin? Define una ventana de compatibilidad auditable.
Error 4: Medir únicamente la latencia promedio
Seguimiento: ¿Cómo pruebas la concurrencia máxima, redes inestables, tamaño de paquetes, CPU, memoria y almacenamiento en caché de certificados? Describe pruebas de carga en capas y líneas de parada.
Preguntas de seguimiento y respuestas
¿Por qué migrar el establecimiento de claves y las firmas por separado?
El establecimiento de claves protege la confidencialidad de la sesión; las firmas protegen la identidad y la integridad. Sus algoritmos, cadenas de certificados, tamaños de clave y tiempos de verificación son diferentes, por lo que realizar despliegues canary independientes evita bloquear todas las cargas de trabajo por un solo reemplazo.
¿Cómo demuestras agilidad criptográfica?
Muestra suites versionadas, cambio de políticas, metadatos de claves, reemplazo de proveedores, una matriz de compatibilidad, eventos de auditoría y simulacros de rollback. Editar un único archivo de configuración no demuestra que el código de negocio, los certificados y las rutas de dispositivos sean reemplazables.
¿Cuándo puedes dejar de aceptar un algoritmo antiguo?
Una vez que se superen las compuertas de cobertura de nuevos clientes, éxito de conexión, rendimiento y auditoría, se atribuya el tráfico antiguo y los propietarios completen sus actualizaciones, detén primero la emisión de nuevas credenciales. Tras una ventana de verificación de solo lectura, revoca la aceptación. Cada paso necesita una condición de rollback y un responsable asignado.