ANKASecure©: el Plano de Control Criptográfico en operación

Resumen ejecutivo

La mayoría de las empresas todavía trata la criptografía como código. El algoritmo se elige cuando se escribe una aplicación, queda incrustado en ella y solo cambia cuando cambia la aplicación. El resultado es una estructura de costos que hoy reconoce cualquier responsable de seguridad: cada cambio criptográfico se convierte en un proyecto de ingeniería, que se repite en cada aplicación que depende de él.

Ese modelo se quedó sin tiempo. En octubre de 2026 NIST publicó la versión final del IR 8547, que declara obsoleta la criptografía de clave pública vulnerable a la computación cuántica después de 2030 y la prohíbe después de 2035 ^[1]. Las directivas federales de Estados Unidos fijan fechas más tempranas para los sistemas de alto valor ^[2], y la Unión Europea estableció sus propios hitos para 2030 y 2035 ^[3]. Al mismo tiempo, el criptoanálisis clásico sigue retirando algoritmos que se consideraban seguros. La pregunta para las organizaciones ya no es qué algoritmo adoptar, sino cuánto tardan en abandonar el que tienen.

ANKASecure© es un Plano de Control Criptográfico (Cryptographic Control Plane) que pone en operación este modelo. No delega la política en un tercero: ejecuta la operación criptográfica, gestiona el material de claves y registra evidencia firmada, mientras la raíz de confianza permanece en el HSM o el KMS en la nube del propio cliente. La arquitectura de referencia que implementa se describe en el documento complementario The Cryptographic Control Plane ^[4], y las capacidades que entrega se organizan según el marco CAPA.

Este documento describe lo que ANKASecure© hace hoy:

• Una sola política para la criptografía. La disponibilidad de algoritmos, la rotación y el ciclo de vida de las claves se gobiernan por política, definida por despliegue y ajustable por tenant, aplicada antes de cada operación y con rechazo por defecto (fail-closed).
• Más de 125 algoritmos en un solo catálogo, incluidos más de 30 algoritmos post-cuánticos y 41 combinaciones híbridas compuestas, alineados con más de 14 organismos de estandarización internacionales.
• Migración sin exponer el texto en claro. Los datos existentes se vuelven a cifrar y a firmar con nuevos algoritmos dentro del plano de control, en modo streaming y a cualquier tamaño, sin la aplicación que los originó.
• Custodia soberana. Cada tenant elige su raíz de confianza. La clave de cifrado de claves que protege sus claves nunca sale del HSM o de la cuenta en la nube del cliente.
• Autoridad gobernada. Los terceros reciben permisos de capacidad revocables y con restricciones explícitas, en lugar de claves.
• Evidencia por defecto. Cada operación, rechazo, cambio de política y acción administrativa queda registrada en una auditoría firmada y encadenada, que se puede verificar de forma independiente.

Estas capacidades se empaquetan en siete soluciones. Cada una atiende un problema de negocio concreto y todas funcionan sobre la misma plataforma. Normalmente las organizaciones entran por una necesidad urgente y luego extienden el uso a las demás sin añadir infraestructura.

1.1 Sobre esta versión

Este documento reemplaza la versión 1.0 del whitepaper de ANKASecure© (febrero de 2026). Se reescribió desde cero para reflejar la plataforma tal como se entrega hoy, alinearse con la terminología de la arquitectura de referencia The Cryptographic Control Plane y del marco CAPA, y describir las soluciones en las que se ofrece la plataforma. Cuando una capacidad la prestan los socios de canal de ANKATech y no la plataforma misma, el documento lo indica.

Por qué ahora

2.1 El reloj ya está escrito

Durante varios años la transición post-cuántica se discutió como un tema de planeación a futuro. Esa etapa terminó. Los estándares están publicados, las fechas de obsolescencia están fijadas y los reguladores de ambos lados del Atlántico convirtieron las recomendaciones en calendarios.

Las transiciones criptográficas anteriores han tomado entre diez y veinte años ^[1]. La ventana que queda hasta 2030 es más corta que el tiempo que la mayoría de las organizaciones necesita para cambiar una criptografía incrustada en cientos de aplicaciones.

2.2 Cosechar ahora, descifrar después

Un adversario no necesita hoy un computador cuántico para generar exposición hoy. Los datos cifrados que se capturen ahora se pueden almacenar y descifrar cuando exista un computador cuántico criptográficamente relevante. Para los datos que deben seguir siendo confidenciales durante diez, veinte o más años (registros financieros, información de salud, datos de identidad, propiedad intelectual, archivos gubernamentales), la exposición empezó cuando se cifraron por primera vez con un algoritmo vulnerable, y crece con cada nuevo registro que se escribe de la misma manera.

Por eso el establecimiento de claves y el cifrado de datos se migran primero, y por eso el problema no se limita a los datos nuevos. Los datos que ya están almacenados, cifrados con claves vulnerables, también forman parte del pasivo.

2.3 No todas las rupturas son cuánticas

La computación cuántica es el motor más visible, pero no el único. Los algoritmos salen de servicio por muchas razones, y varios ejemplos recientes no necesitaron ningún computador cuántico:

• Rainbow, finalista de firma en el proceso de NIST, cayó en 2022 ante un ataque clásico de recuperación de claves que se ejecutó en un portátil ^[8].
• SIKE, que acababa de pasar a la cuarta ronda del proceso de NIST, fue roto por un ataque clásico en cuestión de semanas en 2022 ^[9].
• Classic McEliece fue estandarizado por ISO en junio de 2026 ^[10] y, en octubre de 2026, el BSI alemán desaconsejó su uso en nuevos desarrollos tras avances significativos en su criptoanálisis ^[11]. La protección existente no se volvió ilegible, pero la protección nueva tuvo que cambiar de algoritmo.

Cada uno de estos eventos obligó a todas las organizaciones que usaban el algoritmo afectado a hacerse la misma pregunta: ¿cuánto vamos a tardar en dejar de usarlo? La respuesta depende mucho menos del algoritmo que de la arquitectura que lo rodea.

2.4 La variable real es el tiempo de respuesta

ANKATech llama Brecha de Respuesta Criptográfica (Cryptographic Response Gap) al intervalo entre T0, el momento en que cambia la aceptabilidad de un algoritmo para un uso determinado (una obsolescencia, un ataque publicado, un nuevo requisito regulatorio, un cuestionario de un cliente), y T1, el momento en que la remediación termina en todo el entorno. La brecha extiende la clásica ventana de exposición y corresponde al término de tiempo de migración de la desigualdad de Mosca ^[12]: si el tiempo necesario para migrar más el tiempo durante el cual los datos deben seguir siendo secretos supera el tiempo que falta para que la amenaza se materialice, los datos ya están en riesgo.

Cuando la criptografía está incrustada en el código, la brecha se mide en trimestres o en años, porque cerrarla exige cambios de código, pruebas de regresión, validación de seguridad y una nueva versión, aplicación por aplicación. Completar una migración post-cuántica no cambia eso. Reemplaza el algoritmo, pero el siguiente cambio costará lo mismo. La agilidad criptográfica es la capacidad de que el siguiente cambio sea barato.

La migración cambia el algoritmo. La agilidad cambia lo que cuesta el siguiente cambio.

De la arquitectura a la operación

3.1 El Plano de Control Criptográfico

La infraestructura empresarial ha resuelto varias veces el mismo problema estructural de la misma manera. Las credenciales incrustadas en las aplicaciones se convirtieron en infraestructura de identidad. La configuración de red incrustada en los dispositivos se convirtió en redes definidas por software. Los secretos en archivos de configuración pasaron a bóvedas. En cada caso, una capacidad que cada aplicación implementaba por separado se trasladó a una capa gobernada, y las aplicaciones empezaron a consumirla en lugar de implementarla.

El Plano de Control Criptográfico aplica ese patrón a la criptografía. Separa la intención criptográfica, que expresan las aplicaciones, de la ejecución criptográfica, que se gobierna por política. Centraliza el gobierno sin exigir que se centralicen la ejecución o la custodia de las claves: las claves, las raíces de confianza y los dominios de ejecución pueden seguir distribuidos entre HSM, plataformas KMS en la nube, regiones y jurisdicciones, mientras la política, el ciclo de vida y la evidencia se coordinan en un solo lugar. La arquitectura se describe completa, en términos neutrales respecto a proveedores, en el whitepaper The Cryptographic Control Plane y en cryptographiccontrolplane.org ^[4].

3.2 CAPA: las capacidades que exige una postura

CAPA, Crypto Agility Posture Architecture, define las capacidades que necesita una organización para sostener el cambio criptográfico ^[4]. Se organiza en cinco pilares:

CAPA define además un modelo de madurez de seis niveles, desde la criptografía embebida hasta la evolución criptográfica continua. La madurez se mide por capacidad, es decir, por lo que la organización puede hacer hoy ante una vulnerabilidad o un cambio de estándar, y no por cuánta migración heredada queda pendiente. El capítulo 9 ubica a ANKASecure© en ese modelo.

3.3 Dónde encaja ANKASecure©

ANKASecure© es una implementación del Plano de Control Criptográfico y la implementación de origen de CAPA. La relación entre sus capacidades y los pilares de CAPA es complementaria, no uno a uno: una sola función de la plataforma, como el motor de políticas, contribuye a varios pilares, y cada pilar depende de varias funciones que trabajan juntas.

3.4 Principios de diseño

Seis principios determinan cómo está construida la plataforma y cómo se debe evaluar:

• Ejecutar, no intermediar. ANKASecure© realiza por sí mismo el cifrado, el descifrado, la firma, la verificación, el re-cifrado y la re-firma, y gestiona el material de claves. Cuando el modelo de confianza lo exige, la ejecución puede ocurrir en un HSM, un KMS o un motor externo, según lo determine la política.
• Gobierno central, confianza distribuida. Centralizar el gobierno del ciclo de vida no convierte a ANKASecure© en la raíz de confianza última. La organización conserva ese papel en infraestructura que ella controla.
• Rechazo por defecto. Una política ilegible, un tenant que no se puede resolver o un token no verificado producen un rechazo, nunca un comportamiento permisivo por defecto.
• La evidencia no es opcional. Cada operación, rechazo y cambio produce un registro firmado. El cumplimiento se demuestra consultando el plano de control, no reconstruyéndolo a partir de los logs de las aplicaciones.
• Integrarse hacia afuera. El HSM, el proveedor de identidad, el SIEM y la plataforma de observabilidad del cliente siguen siendo la autoridad. ANKASecure© se conecta con ellos en lugar de reemplazarlos.
• Declarar el alcance con honestidad. La plataforma gobierna las operaciones que se le confían. Lo que no hace se indica de forma explícita en el capítulo 10.

Arquitectura de la plataforma

4.1 Intención y ejecución

Una aplicación llama a ANKASecure© con dos elementos: un identificador de clave estable y los datos. Nunca nombra un algoritmo. El plano de control autentica a quien llama, resuelve los metadatos de la clave y la política vigente, verifica el estado de ciclo de vida de la clave y la autoridad de quien llama, ejecuta la operación y registra la evidencia. La respuesta indica qué algoritmo se usó, para que la aplicación pueda registrarlo, pero no necesita conocerlo de antemano.

Como el identificador es estable, la clave que está detrás puede cambiar. La rotación lleva una clave a una nueva versión de material con el mismo identificador, posiblemente con un algoritmo distinto de la misma familia de propósito. Las operaciones nuevas usan la nueva versión de inmediato; los datos protegidos con versiones anteriores se siguen descifrando y verificando con la versión que los escribió.

4.2 Dos superficies por ambiente

Cada instalación expone dos superficies separadas. La superficie Runtime atiende las operaciones criptográficas de aplicaciones y cargas de trabajo. La superficie Management atiende la consola y la administración de tenants, claves, políticas y permisos. Cada superficie expone solo sus propias operaciones, en su propia dirección. Así, las aplicaciones nunca alcanzan funciones administrativas y las herramientas de administración nunca quedan en la ruta de los datos.

Una instalación nueva no trae administrador. El primer administrador reclama la instancia con un código de un solo uso, de modo que nunca existe una credencial por defecto.

4.3 Motores de ejecución

Las operaciones criptográficas se ejecutan en dos servicios dedicados: uno para operaciones compactas sobre datos en memoria y otro para operaciones en streaming sobre objetos grandes. Las operaciones en streaming procesan los datos por bloques con memoria acotada, de modo que un archivo de varios gigabytes y un registro pequeño usan la misma operación y el mismo consumo de memoria.

Las operaciones se admiten según un presupuesto de memoria. Ningún tenant puede consumir más de la mitad; las solicitudes que lo exceden reciben una respuesta para reintentar, en lugar de degradar el servicio para todos. En un despliegue multi-tenant, esto evita que la carga de un tenant afecte la disponibilidad de otro.

4.4 Catálogo criptográfico

El catálogo abarca más de 125 algoritmos, incluidos más de 30 algoritmos post-cuánticos y 41 combinaciones híbridas compuestas, alineados con más de 14 organismos de estandarización internacionales: NIST, NSA CNSA 2.0, ETSI, ENISA, BSI, ANSSI, CRYPTREC, KISA, MySEAL 2.0, ISO/IEC, IETF y NESSIE, entre otros.

Las claves compuestas usan descifrado AND: deben funcionar tanto el componente clásico como el post-cuántico. ANKASecure© no implementa a propósito el descifrado OR, que solo sería tan fuerte como el componente más débil. Del mismo modo, las firmas compuestas exigen que ambos componentes verifiquen.

El catálogo también está gobernado. Cuando el BSI desaconsejó el uso nuevo de Classic McEliece ^[11], la plataforma pasó el algoritmo a estado heredado: las claves existentes siguieron descifrando, pero dejó de ofrecerse para proteger datos nuevos. Es el mismo mecanismo que la plataforma ofrece a los clientes para sus propias políticas.

4.5 Representación de los resultados

Los resultados cifrados y firmados usan estructuras basadas en la familia JOSE, JWE y JWS ^[13], con identificadores de algoritmo extendidos para los mecanismos que los registros JOSE estándar todavía no definen. Esto da a las aplicaciones gobernadas una representación coherente aunque cambie el algoritmo subyacente, y evita que los datos protegidos queden atados a un formato propietario.

Esto no debe entenderse como interoperabilidad JOSE universal. Una implementación externa solo puede procesar una representación si admite los algoritmos, los identificadores y los perfiles utilizados. Cuando una contraparte exige un perfil estándar concreto, ese requisito pasa a formar parte del contexto de interoperabilidad gobernado.

4.6 Multi-tenancy y aislamiento

Un mismo despliegue atiende muchos tenants, cada uno de los cuales representa una unidad de negocio, una filial, un cliente o una jurisdicción. Cada tenant tiene su propio almacén de claves, sus propias políticas dentro de los límites del despliegue, su propia auditoría y su propia clave de cifrado de claves, protegida por la raíz de confianza que elija. Cada tenant puede usar además su propio SIEM, su propia plataforma de observabilidad y su propio proveedor de identidad. El filtrado de datos por tenant se aplica a todas las lecturas, incluidas las lecturas por identificador, y los nombres de tenant rechazan caracteres invisibles que podrían servir para suplantar a otro.

Cuando se requiere una separación más fuerte, un despliegue dedicado de un solo tenant ofrece aislamiento completo de infraestructura.

4.7 Despliegue y operación

ANKASecure© se despliega como SaaS operado por ANKATech, en la nube privada del cliente o en sus instalaciones (on-premise), incluso en ambientes aislados (air-gapped). También está disponible en AWS Marketplace con licenciamiento por hora. La custodia es una decisión independiente: cualquier modelo de despliegue se puede combinar con cualquier raíz de confianza admitida.

• Actualizaciones en sitio, con la opción de volver a la versión anterior hasta confirmar la actualización.
• Respaldo y restauración con un inventario firmado de la custodia de claves; una restauración rota las claves que firman los tokens.
• Perfiles de capacidad dimensionados según la máquina, e instalación por nombre de dominio o por dirección IP.
• Visibilidad operativa: verificaciones de salud, búsqueda de logs de la plataforma desde la consola, trazabilidad distribuida de las llamadas internas y exportación de telemetría por OTLP.

Política, ciclo de vida y custodia

5.1 El motor de políticas

La política criptográfica de ANKASecure© tiene tres capas:

• Disponibilidad de algoritmos: controla qué algoritmos se pueden usar, por lista explícita, familia, categoría (clásico, post-cuántico, híbrido), nivel de seguridad, organismo de estandarización u operación. Admite perfiles solo híbridos.
• Rotación: define las transiciones y los intervalos permitidos, por ejemplo bloquear una reducción de seguridad o un regreso de post-cuántico a clásico, y rechazar intervalos de rotación que superen el criptoperíodo máximo.
• Ciclo de vida: define qué operaciones permite cada estado de una clave.

Las políticas se definen por despliegue y se pueden ajustar por tenant. La plataforma incluye 37 plantillas: 29 de disponibilidad de algoritmos, alineadas con NIST, NSA CNSA 2.0, BSI, ANSSI, ETSI, CRYPTREC y otros organismos; 6 de rotación y 2 de ciclo de vida. También admite políticas personalizadas.

La aplicación de la política ocurre antes de la operación, no después. La generación de claves, la rotación y cada operación criptográfica se verifican contra la política activa; una infracción se rechaza con un motivo, no se registra y se deja pasar. Los cambios de política llegan a todas las instancias del servicio en menos de un segundo, sin reinicio ni redespliegue.

El motor de políticas también se protege a sí mismo:

• Las políticas de un tenant no pueden quedar por debajo de la fortaleza mínima de seguridad del despliegue.
• Un despliegue bloqueado por cumplimiento rechaza los cambios a su propia política.
• Un quórum opcional exige un segundo aprobador para cualquier cambio que debilite la política de algoritmos, de rotación o de ciclo de vida, o los límites de las claves.
• Los cambios de política son, a su vez, eventos de auditoría firmados.

5.2 Aceptabilidad, no roto o seguro

Los algoritmos rara vez pasan de seguros a rotos en un solo paso. NIST SP 800-131A ^[14] trata la aceptabilidad como un estado por operación, y ANKASecure© la aplica de la misma forma:

Antes de cualquier rotación, el servidor calcula su admisibilidad frente a la política de rotación y devuelve un veredicto y un código de motivo para cada algoritmo candidato. Los operadores pueden ver de antemano qué transiciones permitirá la política.

5.3 Ciclo de vida de las claves

Cada clave sigue un ciclo de vida de siete estados gobernado por política. Dos distinciones son centrales:

• Retirar no es destruir. Las claves reemplazadas y retiradas siguen descifrando y verificando, mientras que el cifrado y la firma nuevos se rechazan. Los datos escritos con una clave antigua siguen siendo legibles durante y después de la migración.
• El motivo de la revocación importa. Una clave revocada porque su algoritmo quedó obsoleto mantiene legible el historial. Una clave revocada por compromiso queda sellada.

La destrucción es un paso aparte y deliberado. Requiere la aprobación de personas designadas distintas de quien la solicita (M de N) y un periodo de espera de 7 a 365 días. Un identificador de clave nunca se reutiliza. El estado de las claves está sellado: un cambio hecho por fuera de la plataforma se rechaza.

Las claves pueden tener un límite de uso y un límite suave que avisa antes de alcanzarlo, una fecha de vencimiento y una regla sobre si el material puede exportarse alguna vez. La rotación puede ser programada a nivel de despliegue, tenant o clave, dentro de los periodos que fija el paquete de cumplimiento aplicable, o por uso, activada al llegar al límite suave o al límite máximo. La rotación programada se ejecuta exactamente una vez, aunque haya reinicios o caídas. Cada evento de límite produce un evento de auditoría firmado, un evento para el SIEM y una notificación.

5.4 Custodia soberana

La raíz de confianza de cada tenant se resuelve en tres niveles, deteniéndose en el primero que esté declarado: el backend propio del tenant, el backend administrado que asigna su edición licenciada o el backend por defecto del despliegue. Las claves se protegen con cifrado de sobre (envelope encryption): las claves de datos se envuelven con una clave de cifrado de claves (KEK) por tenant que nunca sale del backend elegido.

• Traiga su propia clave (BYOK). Un tenant declara una clave en su propia cuenta de AWS KMS, Google Cloud KMS, Azure Key Vault o Azure Managed HSM, o en un HSM mediante PKCS#11, con su propia credencial. ANKASecure© ejecuta una prueba de ida y vuelta en vivo contra el backend antes de aceptar la declaración.
• Doble registro. Cada operación de envolver y desenvolver llama al backend del tenant, así que aparece tanto en la auditoría firmada de ANKASecure© como en el log del propio proveedor.
• KEK reforzadas. Las KEK generadas en un HSM se crean de solo lectura. Se emite una alerta si el backend de un tenant rechaza su KEK.
• Custodia que se puede mover. La custodia de un tenant se puede trasladar a otro backend: su KEK rota en línea y sus claves se mueven en una ventana de mantenimiento, sin recrear el tenant. Las KEK alojadas en un KMS administrado rotan según el calendario del proveedor.

ANKATech no opera el HSM ni la cuenta en la nube del cliente. El cliente conserva el backend, su credencial y su disponibilidad.

Autoridad, evidencia y cumplimiento

6.1 Separación de autoridad

ANKASecure© separa tres tipos de autoridad: la plataforma, que opera el despliegue; el tenant, que es dueño de sus claves y políticas; y el operador, que ejecuta tareas en nombre del tenant. Quien otorga una capacidad no es quien la ejerce.

• Las personas inician sesión con passkeys, con contraseña y autenticador, o con el proveedor de identidad de la organización mediante OIDC, SAML o LDAP. Los administradores de plataforma entran solo con passkey, y en SaaS el inicio de sesión local usa solo passkeys. Los cambios sensibles exigen confirmar la identidad, y existe un procedimiento de acceso de emergencia.
• La automatización se autentica con una identidad no humana propia, nunca con las credenciales de una persona.
• Las cargas de trabajo se autentican con el token que emite su propia plataforma, mediante federación de identidad de cargas de trabajo. ANKASecure© no emite ninguna credencial que una carga de trabajo deba guardar o rotar.
• El acceso de soporte es consentido. En SaaS, el personal de ANKATech solo puede leer la auditoría de un tenant dentro de una sesión de soporte que el tenant autorizó, y los cambios hechos en esa sesión se atribuyen al operador de plataforma que los realizó.

6.2 Permisos de capacidad y contextos de intercambio

Los permisos para usar claves se modelan como permisos de capacidad (capability grants). Un permiso nombra a un actor, las operaciones que puede realizar y las claves que abarca. Puede llevar una política de restricción con cuatro dimensiones que se hacen cumplir: una ventana de validez, un tope total de uso, un límite de frecuencia por minuto y un uso único.

Cada permiso pertenece a un contexto de intercambio (exchange context), que nombra a la contraparte, su tipo, las claves que abarca y un dueño, y que tiene su propio ciclo de vida (creado, activo, suspendido, cerrado). Así la organización puede responder en cualquier momento quién intercambia qué, con quién y bajo qué límites. El uso se descuenta cuando la operación criptográfica se ejecuta realmente. Revocar un permiso o suspender un contexto bloquea la siguiente llamada de inmediato, sin volver a cifrar los datos que gobernaba.

Una vista de topología de intercambios en la consola muestra cada contexto y su actividad, y un Cryptographic Playground permite a un administrador ejecutar una operación real con un permiso para probarlo antes de que lo use la contraparte.

6.3 Evidencia firmada

Cada operación criptográfica, administrativa y de autenticación queda registrada con su algoritmo, clave, resultado (éxito, falla o denegación) y motivo, en una auditoría firmada y encadenada. Se registra cada lectura de material protegido, cada tarea programada que termina y cada lectura de la propia auditoría. Las tablas firmadas son de una sola escritura para los roles de ejecución. La auditoría se conserva al menos doce meses.

La auditoría se puede consultar por tenant, por aplicación, por contexto de intercambio, por política de restricción y por actor, y se puede exportar. Los eventos se envían al SIEM del cliente en CEF u OCSF conservando la firma y la preimagen canónica, de modo que un auditor puede verificarlos sin depender de ANKASecure©. Las firmas pueden llevar sellos de tiempo RFC 3161 ^[15] de cualquier autoridad de sellado, verificables fuera de línea.

6.4 Postura, paquetes de cumplimiento y CBOM

La consola calcula la postura criptográfica de la organización a partir del entorno real, en los pilares de CAPA: si la custodia está declarada y vinculada, qué parte del entorno está modernizada, cuántos tenants gobiernan deliberadamente con una política declarada y cuántas claves gobernadas cumplen la política vigente.

Seis paquetes de cumplimiento añaden evaluaciones de postura específicas por marco, evidencia firmada y planes de remediación: NIST PQC Transition (según la versión final del NIST IR 8547 ^[1]), NSA CNSA 2.0 ^[7], EU PQC Roadmap ^[3], BSI TR-02102-1 ^[16], ANSSI PQC ^[17] y NIST CSWP 39 ^[18]. Cada paquete puede generar un paquete de evidencia firmado que incluye un inventario criptográfico (CBOM, Cryptography Bill of Materials) en formato CycloneDX ^[19], con las claves vivas del tenant, su algoritmo, estado, fechas y custodia, sin material de claves.

ANKASecure© no es una herramienta de descubrimiento. No recorre el entorno buscando criptografía que no se le haya confiado. Complementa el descubrimiento: el CBOM que produce describe con precisión el entorno gobernado y alimenta el inventario general de la organización.

6.5 Alineación regulatoria

Los controles de la plataforma se corresponden con los requisitos criptográficos de los principales marcos regulatorios:

Soluciones

La plataforma se ofrece en siete soluciones. Cada una parte de un problema de negocio que un responsable concreto reconoce, y todas funcionan sobre el mismo plano de control, la misma política y la misma evidencia. Una organización que adopta una solución ya tiene desplegada la base para las demás.

7.1 Crypto-Agility

El problema

Hoy, cambiar un algoritmo implica un cambio de código, un ciclo de regresión, una validación de seguridad y una nueva versión, repetidos en cada aplicación que lo usa. Los equipos aplazan el cambio y los entornos siguen funcionando con algoritmos que deberían haberse retirado.

Cómo lo resuelve ANKASecure©

Las aplicaciones invocan capacidades estables sobre identificadores de clave estables. Las políticas de disponibilidad, rotación y ciclo de vida deciden qué algoritmo atiende cada llamada; la admisibilidad se calcula antes de cualquier rotación; las claves retiradas mantienen legibles los datos históricos; y el re-cifrado y la re-firma llevan los datos protegidos al nuevo algoritmo sin las aplicaciones originales. Los cambios de política llegan a todas las instancias en menos de un segundo.

Casos de uso típicos

• Hay que retirar un algoritmo tras una obsolescencia, un ataque publicado o el rechazo de un cliente en un cuestionario de seguridad.
• Dos jurisdicciones exigen listas distintas de algoritmos aprobados para la misma aplicación.
• La organización quiere mejorar su postura antes de que llegue un evento que la obligue.

7.2 Post-Quantum Migration

El problema

Pasar a algoritmos post-cuánticos normalmente exige descifrar primero los datos existentes, lo que expone el texto en claro y obliga a cambiar las aplicaciones dueñas de los datos. Mientras tanto, cada registro escrito con un algoritmo vulnerable aumenta el pasivo de "cosechar ahora, descifrar después".

Cómo lo resuelve ANKASecure©

El objetivo se declara una sola vez, con una plantilla de política como NIST, CNSA 2.0, BSI o ANSSI, y el material de claves que no cumple se rechaza en todas partes sin publicar ninguna versión de aplicación. Los almacenes de claves PKCS#12 y JKS existentes se importan mediante una validación de siete etapas. Los datos se vuelven a cifrar dentro del plano de control: la clave de datos se desenvuelve y se vuelve a envolver, y el contenido nunca se escribe en almacenamiento, logs ni en quien llama (patente en trámite). Las claves híbridas compuestas cubren el riesgo de una debilidad en cualquiera de los dos componentes.

Casos de uso típicos

• Datos de retención larga cuyo periodo de confidencialidad supera la vida segura de los algoritmos actuales.
• Un plazo regulatorio o un requisito de compras que exige FIPS 203, 204 y 205.
• Una transición híbrida en la que deben coexistir la protección clásica y la post-cuántica.

7.3 Enterprise Cryptographic Control

El problema

Las decisiones criptográficas se toman dentro de cada aplicación, así que nadie puede decir con certeza qué algoritmos protegen qué datos. Los gestores de claves, los gestores de certificados y las herramientas de descubrimiento cubren cada uno una parte del panorama, pero ninguno decide si una operación está permitida. Un estándar puede adoptarse en papel sin que ningún sistema pueda rechazar una infracción.

Cómo lo resuelve ANKASecure©

El motor de políticas de tres capas hace cumplir el estándar antes de cada operación y rechaza las infracciones con un motivo. La autoridad es explícita, mediante permisos revocables sobre un modelo de roles que separa plataforma, tenant y operador. Cada decisión queda registrada como evidencia firmada, y la postura se calcula a partir del entorno real.

Casos de uso típicos

• Hacer cumplir un estándar criptográfico interno en varias unidades de negocio.
• Responder con una consulta a la pregunta de un auditor sobre qué política se aplicó a una operación concreta.
• Gobernar con aprobación por quórum los cambios que debilitan la política.

7.4 Legacy Cryptography Modernization

El problema

Los archivos cifrados o firmados hace años en PKCS#7 o CMS sobreviven a las aplicaciones que los escribieron y, a veces, a los proveedores que estaban detrás. Los certificados vencen mucho antes de que termine el periodo de retención. Los scripts de descifrar y volver a cifrar dejan texto en claro en disco y en logs; dejar los datos donde están deja el riesgo donde está.

Cómo lo resuelve ANKASecure©

Las claves se importan mientras siguen vigentes, con el estado y la ruta de migración de cada certificado, y las anclas de confianza se identifican antes de importar. Los archivos se analizan antes de tocarlos. Los sobres se convierten a la representación JOSE en modo streaming, se vuelven a cifrar con una nueva clave de contenido dentro del plano de control y luego pasan a claves post-cuánticas o compuestas según la política de rotación. Las claves antiguas se retiran, no se destruyen, así que los sobres originales siguen siendo legibles hasta que termina la migración. El operador de la migración solo tiene un permiso de re-cifrado y nunca ve el contenido. Los firmantes con SHA-1 y MD5 se rechazan salvo autorización explícita.

Casos de uso típicos

• Registros cuyo sistema de origen fue dado de baja.
• Archivos atados a un certificado que vencerá mucho antes de que termine el periodo de retención.
• Programas de modernización de plataforma detenidos en los datos cifrados con el esquema anterior.

7.5 Governed Third-Party Exchange

El problema

Tercerizar un proceso (nómina, reclamaciones, KYC, impresión, analítica) o intercambiar datos con otras instituciones suele implicar entregar una clave privada de larga duración a una contraparte. Esa clave no se puede acotar, medir ni recuperar sin volver a cifrar todo lo que protegía, así que muchas veces se deja tal cual. Un acuerdo de tratamiento de datos no limita una clave.

Cómo lo resuelve ANKASecure©

La relación se modela como un contexto de intercambio. La contraparte recibe un permiso de capacidad, no una clave, con ventana de validez, tope de uso, límite de frecuencia y uso único opcional. Su carga de trabajo se autentica con el token de su propia plataforma. Cada uso se registra con su permiso y la decisión de restricción; la revocación surte efecto en la siguiente llamada. El principio es simple: compartir capacidades, no claves. ANKASecure© gobierna el acceso criptográfico, no el transporte de los datos.

Casos de uso típicos

• Procesamiento tercerizado de datos sensibles por parte de un proveedor de servicios.
• Intercambio de datos protegidos entre instituciones dentro de un ecosistema regulado.
• Terminar la relación con un proveedor sin volver a cifrar los datos a los que tenía acceso.

7.6 Sovereign Key Custody

El problema

Los reguladores, las juntas directivas y los contratos con clientes exigen cada vez más que el material de claves nunca salga del HSM o de la jurisdicción de la organización. Cualquier plataforma que tenga la raíz de confianza queda descartada desde el principio. Las migraciones a la nube y las filiales con reglas distintas añaden más restricciones.

Cómo lo resuelve ANKASecure©

Cada tenant elige su raíz de confianza mediante la precedencia de tres niveles. Con BYOK, el tenant declara una clave en su propia cuenta, validada con una prueba de ida y vuelta en vivo. La KEK nunca sale del backend; cada operación de envolver y desenvolver aparece en ambos registros de auditoría. El modelo de despliegue y la custodia son decisiones independientes, y la custodia se puede trasladar a un nuevo backend como una operación gobernada.

Casos de uso típicos

• Una cláusula de cumplimiento que exige la custodia en el HSM o en la cuenta en la nube de la propia organización.
• Una migración a la nube en la que las cargas de trabajo se mueven pero las claves deben seguir bajo control de la organización.
• Filiales que necesitan modelos de custodia distintos en una misma instalación.

7.7 Digital Signatures & Long-Term Evidence

El problema

Los contratos, las declaraciones regulatorias y los registros clínicos deben poder verificarse durante una década o más, pero el algoritmo que los firma hoy tiene fecha de retiro. Una firma prueba quién firmó, no cuándo; sin un sello de tiempo independiente, "firmado antes de que la clave se viera comprometida" es solo una afirmación.

Cómo lo resuelve ANKASecure©

La política elige el algoritmo de firma: ML-DSA, SLH-DSA, FALCON, esquemas basados en hash con estado, familias clásicas o firmas compuestas. Las firmas se sellan en el tiempo con cualquier autoridad RFC 3161 ^[15], con una política por tenant que lo hace obligatorio, opcional o desactivado, y el token se incrusta como perfil JAdES B-T (ETSI TS 119 182-1) ^[23]. Cuando un algoritmo se retira, la operación RESIGN vuelve a firmar las firmas existentes con un algoritmo aprobado y registra el linaje, de modo que la nueva firma es, de forma verificable, la sucesora de la anterior.

Casos de uso típicos

• Registros de retención larga con valor legal o regulatorio.
• Volver a anclar firmas existentes antes de la fecha de obsolescencia de un algoritmo.
• Establecer prueba de tiempo para transacciones y documentos firmados.

Integraciones y experiencia de desarrollo

8.1 Ecosistema de integraciones

ANKASecure© se integra con 45 sistemas externos en ocho categorías. Cada familia de integración tiene un plano de configuración, un plano de ejecución y un ajuste por tenant. Cada integración se marca como certificada cuando se ha ejecutado una prueba completa de ida y vuelta contra el producto real del fabricante, o como experimental cuando el adaptador se entrega y la certificación está en curso. Hoy están certificadas 25 de las 45, y la certificación avanza de forma continua.

La entrega de notificaciones incluye conmutación por error y una ruta de mensajes no entregados. En SaaS, cada tenant recibe solo su propia telemetría.

8.2 Para desarrolladores

Una llamada criptográfica necesita dos campos, el identificador de clave y los datos, y cada operación admite los algoritmos de FIPS 203, 204 y 205 cuando la política los selecciona. Las aplicaciones usan 29 operaciones del plano de datos; la plataforma expone 547 operaciones en total, todas disponibles fuera de la consola.

• Runtime SDK y CLI para las operaciones criptográficas, y Key Management SDK y CLI para claves, tenants y permisos. Los SDK de Java se publican en Maven Central; los CLI funcionan en Windows, macOS y Linux.
• APIs REST con especificaciones OpenAPI 3.0 para cualquier otro lenguaje, con ejemplos de referencia en 20 lenguajes.
• Recetas para tareas comunes, como rotar de RSA-2048 a ML-KEM-768, firmar y verificar con ML-DSA-87, y firmar y luego cifrar con JWE y JWS anidados.
• SDK que protegen los secretos: las credenciales y el material de claves se enmascaran en mensajes, excepciones y logs.
• Documentación que responde preguntas. La documentación para clientes tiene versiones por release y se puede consultar en lenguaje natural desde asistentes de IA mediante un conector MCP, que responde solo con la documentación a la que el usuario tiene acceso.

8.3 Para operadores

La consola, disponible en inglés y español, cubre tenants, identidades, claves, políticas, permisos, contextos de intercambio, auditoría y postura. Muestra la próxima rotación de cada clave y la causa de cada versión, la actividad por aplicación, por contexto de intercambio y por actor, y fichas completas de aplicaciones, actores y contextos con dueño, contactos, clasificación de datos y nivel de riesgo. Las acciones destructivas piden confirmación, y al cerrar sesión se borran los datos en caché del navegador.

Madurez y adopción

9.1 El modelo de madurez CAPA

El modelo de madurez CAPA describe seis niveles ^[4]. Lo rigen dos principios. La madurez se mide por capacidad, así que un entorno heredado en migración activa es trabajo en curso, no un déficit. Y la criptografía post-cuántica no es el último nivel: es una dimensión que mejora en cada nivel desde el momento en que existe un plano de control.

Desplegar ANKASecure© establece el nivel 3 para los sistemas que gobierna. Avanzar a los niveles 4 y 5 es cuestión de cobertura: incorporar más aplicaciones, migrar más datos protegidos y llevar más partes del entorno a la misma política.

9.2 Tres puertas de entrada, una plataforma

Normalmente las organizaciones llegan a ANKASecure© por una de tres puertas de entrada, cada una impulsada por una urgencia distinta:

• Control criptográfico empresarial: un estándar que hay que hacer cumplir y evidenciar.
• Preparación post-cuántica: un plazo, un regulador o un cuestionario de un cliente.
• Soberanía criptográfica: un requisito de custodia o un tercero que necesita acceso sin recibir claves.

Las tres convergen en el mismo plano de control. Una vez que la plataforma gobierna una necesidad, la segunda es una nueva política, un nuevo tenant o un nuevo contexto de intercambio, no un nuevo proyecto de infraestructura.

9.3 Una ruta por fases

Posicionamiento y alcance

10.1 Dónde se ubica ANKASecure©

ANKASecure© no reemplaza los componentes en los que las organizaciones ya confían. Opera en otra capa y aporta más valor cuando esos componentes siguen en su lugar.

10.2 Lo que ANKASecure© no hace

Declarar los límites es parte del diseño:

• Gobierna solo las operaciones que se le confían. Las aplicaciones que no se han incorporado no están cubiertas, e incorporarlas es un trabajo real.
• No descubre por sí mismo la criptografía del entorno; el descubrimiento lo prestan los socios de canal.
• No puede recuperar datos cuyas claves se perdieron, convertir archivos cuyas claves vencieron ni alcanzar datos que estén en sistemas que no deleguen la operación.
• No protege el texto en claro que se entrega legítimamente a una contraparte, ni ve lo que una contraparte hace con los resultados.
• No opera el HSM ni la cuenta en la nube del cliente, y no mueve material de claves entre backends sin una operación gobernada.
• La agilidad criptográfica de la organización no garantiza que los sistemas externos admitan los mismos algoritmos.
• No es un prestador cualificado de servicios de confianza y no archiva documentos.
• Hace cumplir la aceptabilidad; quienes son dueños del riesgo criptográfico deciden qué es aceptable. No certifica el cumplimiento.

Conclusión

La transición post-cuántica tiene un calendario, y no será la última transición. Las organizaciones que la traten como una migración más la terminarán y se encontrarán exactamente donde empezaron: con la criptografía todavía incrustada en el código y el siguiente cambio con el mismo costo que este.

La alternativa es arquitectónica. Sacar la decisión criptográfica de la aplicación, gobernarla como política, mantener la raíz de confianza donde la organización la controla y registrar evidencia de cada operación. Eso es lo que hace un Plano de Control Criptográfico, lo que mide CAPA y lo que ANKASecure© entrega hoy: una plataforma que ejecuta, gobierna y evidencia la criptografía en algoritmos clásicos, post-cuánticos e híbridos, desplegada como SaaS, en nube privada o en las instalaciones del cliente.

Referencias

1. [1] National Institute of Standards and Technology. NIST IR 8547, Transition to Post-Quantum Cryptography Standards. Versión final, 27 de octubre de 2026.
2. [2] The White House. Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, 22 de junio de 2026; y Office of Management and Budget, Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography, 24 de junio de 2026.
3. [3] NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, versión 1.0. Junio de 2025.
4. [4] ANKATech Solutions INC. The Cryptographic Control Plane: A New Architecture for Continuous Cryptographic Evolution, versión 2. Noviembre de 2026. cryptographiccontrolplane.org.
5. [5] National Institute of Standards and Technology. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard; FIPS 204, Module-Lattice-Based Digital Signature Standard; FIPS 205, Stateless Hash-Based Digital Signature Standard. 13 de agosto de 2024.
6. [6] Reglamento (UE) 2022/2554 sobre la resiliencia operativa digital del sector financiero (DORA), y Reglamento Delegado (UE) 2024/1774 de la Comisión (normas técnicas de regulación sobre el marco de gestión del riesgo de TIC).
7. [7] National Security Agency. Announcing the Commercial National Security Algorithm Suite 2.0, septiembre de 2022; y The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ, versión 2.1, diciembre de 2024.
8. [8] W. Beullens. Breaking Rainbow Takes a Weekend on a Laptop. CRYPTO 2022.
9. [9] W. Castryck y T. Decru. An Efficient Key Recovery Attack on SIDH. EUROCRYPT 2023 (IACR ePrint 2022/975, julio de 2022).
10. [10] ISO/IEC 18033-2:2006/Amd 2:2026, Information technology. Security techniques. Encryption algorithms. Part 2: Asymmetric ciphers. Amendment 2. Junio de 2026.
11. [11] Bundesamt für Sicherheit in der Informationstechnik (BSI). Nota sobre Classic McEliece, que desaconseja su uso en nuevos desarrollos. 1 de octubre de 2026. bsi.bund.de.
12. [12] M. Mosca. Cybersecurity in an Era with Quantum Computers: Will We Be Ready? IEEE Security & Privacy, 16(5), 2018.
13. [13] IETF. RFC 7516, JSON Web Encryption (JWE), y RFC 7515, JSON Web Signature (JWS). Mayo de 2015.
14. [14] National Institute of Standards and Technology. SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Marzo de 2019.
15. [15] IETF. RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). Agosto de 2001.
16. [16] Bundesamt für Sicherheit in der Informationstechnik (BSI). Technical Guideline TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths. Edición vigente.
17. [17] Agence nationale de la sécurité des systèmes d'information (ANSSI). ANSSI views on the Post-Quantum Cryptography transition. 2022, con actualización de 2023.
18. [18] National Institute of Standards and Technology. CSWP 39, Considerations for Achieving Crypto Agility: Strategies and Practices. 19 de diciembre de 2025 (actualización 1, junio de 2026).
19. [19] Ecma International. ECMA-424, CycloneDX Bill of Materials Specification.
20. [20] Directiva (UE) 2022/2555 (NIS2), y Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024.
21. [21] PCI Security Standards Council. Payment Card Industry Data Security Standard, v4.0.1. Junio de 2024.
22. [22] Reglamento (UE) 2016/679, Reglamento General de Protección de Datos (RGPD).
23. [23] ETSI TS 119 182-1, JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures.

Acerca de ANKATech ANKATech Solutions INC es una compañía constituida en Delaware que desarrolla ANKASecure©, un Plano de Control Criptográfico para gobernar, migrar y evidenciar la criptografía en algoritmos clásicos, post-cuánticos e híbridos. ANKATech es autora de la arquitectura de referencia The Cryptographic Control Plane y del marco CAPA, publicados bajo licencia abierta en cryptographiccontrolplane.org. ANKATech es miembro del PKI Consortium y de la Cloud Security Alliance, y trabaja con socios de canal que prestan servicios de descubrimiento, evaluación y migración criptográfica.

www.ankatech.co · contactus@ankatech.co

ANKASecure© es una marca registrada de ANKATech Solutions INC. Patente en trámite. Este documento describe las capacidades de la plataforma tal como se entregan en la fecha de publicación y no constituye un compromiso contractual. Las determinaciones de cumplimiento corresponden a cada organización y a sus auditores.