Soberanía criptográfica en el intercambio de información con terceros

Resumen ejecutivo

Hoy, toda empresa intercambia información sensible con decenas o cientos de terceros: proveedores, outsourcers de procesos de negocio, fintechs, redes de tarjetas, laboratorios, agencias, servicios en la nube y proveedores especializados. Ese intercambio ya no es una excepción que se gestiona en el borde de la organización. Es la forma en que la organización opera.

El modelo criptográfico que soporta este intercambio no ha evolucionado al mismo ritmo. Cuando una organización necesita que un tercero procese datos protegidos, normalmente hace una de dos cosas: entrega la clave criptográfica, o descifra los datos y entrega el texto en claro. En ambos casos, el control sobre los datos termina en el momento en que se comparten. El propietario no sabe cuándo ni cómo se usa su autoridad criptográfica, no puede revocar el acceso en tiempo real, no dispone de evidencia independiente del uso y, en el primer caso, ya no conserva la única copia de la clave.

Además, la exposición se acumula. Cuando el intercambio es recurrente, como ocurre en la mayoría de los casos, una única clave compartida termina protegiendo todas las entregas que el tercero ha recibido: un año de entregas y cualquier otra cosa cifrada con esa misma clave. Cuanto más larga es la relación, mayor es el radio de impacto de un solo compromiso.

La regulación ha avanzado en la dirección opuesta. DORA, PCI-DSS 4.0, GDPR, SOX y los regímenes bancarios y de protección de datos de distintas jurisdicciones convergen en un mismo principio: el propietario de los datos sigue siendo el responsable último, sin importar qué tercero procese la información. Algunos supervisores ya preguntan de forma explícita por las dependencias criptográficas con terceros. Las brechas más costosas de los últimos años no ocurrieron dentro de las organizaciones que las sufrieron, sino en sus terceros.

El modelo se apoya en un único cambio: pasar de compartir claves a compartir capacidades. Un tercero no recibe material criptográfico. Recibe el derecho a invocar una función criptográfica específica, sobre un material específico, en un contexto de intercambio específico y bajo restricciones explícitas, y cada invocación queda registrada en el dominio del propietario. La revocación es inmediata y unilateral, y no exige volver a cifrar ningún dato. La evidencia la produce la infraestructura del propietario; no la reporta el tercero.

Nada de esto sustituye la forma en que se intercambia la información. Los archivos por transferencia administrada de archivos, los payloads por API, los eventos por plataformas de mensajería y las transacciones entre integraciones de aplicaciones siguen viajando por los canales que la organización ya opera. El modelo actúa en otra capa: quién tiene la autoridad criptográfica para abrir lo que viaja por esos canales y en qué condiciones puede abrirse. El transporte y el control criptográfico son dos planos distintos, y el intercambio soberano opera únicamente sobre el segundo.

Como el tercero invoca una capacidad en lugar de poseer una clave, el propietario puede rotar claves y cambiar algoritmos detrás de esa capacidad con la frecuencia que exija su política, incluso una clave por entrega, sin que el tercero cambie una sola línea de código y sin que el propietario tenga que modificar tampoco sus aplicaciones.

Este es un problema de hoy, no de la era cuántica. La pérdida de control sobre los datos compartidos con un tercero ocurre con RSA, con AES y con los algoritmos que las organizaciones ya utilizan. Resolverlo no requiere una migración poscuántica, un inventario criptográfico completo ni el desacoplamiento previo de cada aplicación. Requiere cambiar la forma en que se ejerce la autoridad criptográfica a través de la frontera de la organización, y eso puede comenzar con los algoritmos y los HSM que ya existen. La preparación poscuántica en las relaciones externas llega después, como consecuencia.

Llevar este modelo a la práctica requiere una capa arquitectónica que ni un módulo de seguridad de hardware, ni un sistema de gestión de claves, ni un API gateway proporcionan por sí solos: un Cryptographic Control Plane. Un HSM almacena claves. Un proxy transporta solicitudes. Un plano de control gobierna: decide quién puede ejercer qué capacidad criptográfica, sobre qué material, en qué contexto y bajo qué restricciones, y produce evidencia criptográfica de cada decisión.

El documento describe las fuerzas que están rompiendo el modelo tradicional de intercambio, define la soberanía criptográfica como una propiedad de la organización y no de la clave, y presenta un modelo conceptual de cinco elementos para el intercambio soberano: Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset y Constraint Policy. Separa el plano de transporte, que la organización conserva, del plano de control criptográfico, que la organización gana. Ilustra el modelo con escenarios bancarios que abarcan los principales canales de intercambio (emisión de tarjetas con múltiples proveedores de embossing, cobranza tercerizada, originación de crédito con una fintech sobre una API existente y entregas recurrentes sobre una plataforma existente de transferencia administrada de archivos) y muestra cómo la misma estructura se aplica en servicios financieros, gobierno, salud, telecomunicaciones, retail y software.

A continuación, describe la alineación regulatoria que produce el modelo, el valor que aporta a la junta directiva, al CISO y al CIO, una ruta de adopción desde el piloto hasta la plataforma, y la forma en que ANKASecure© implementa el modelo como un Cryptographic Control Plane.

Este documento complementa el whitepaper The Cryptographic Control Plane, que presenta la arquitectura y el marco CAPA (Crypto Agility Posture Architecture). La soberanía criptográfica es el segundo de los cinco pilares de CAPA. Este documento desarrolla ese pilar en el contexto donde más importa: el momento en que los datos de una organización cruzan una frontera organizacional.

El problema del intercambio con terceros

Durante la mayor parte de la historia de la seguridad empresarial, la frontera del control coincidió con la frontera de la organización. Los datos que permanecían dentro estaban protegidos por los controles propios de la organización; los que salían quedaban, por definición, expuestos. La criptografía era el mecanismo que permitía que los datos salieran manteniéndose protegidos en tránsito y en reposo, pero solo hasta llegar a una parte que necesitara usarlos.

Esa parte necesitaba una clave. Y la clave, una vez entregada, se llevaba consigo todas las propiedades del control.

2.1 Cuatro fuerzas que rompen el modelo tradicional de intercambio

Cuatro fenómenos simultáneos han convertido esta limitación histórica en un riesgo estructural.

Ecosistemas hiperconectados

Hoy, una empresa típica intercambia datos sensibles con decenas o cientos de partes externas. Un banco emite tarjetas a través de múltiples redes y proveedores de embossing, terceriza la cobranza y el servicio al cliente, reporta a los reguladores, integra fintechs embebidas y participa en esquemas de open banking. Un hospital comparte historias clínicas con laboratorios, aseguradoras y socios de investigación. Un operador de telecomunicaciones intercambia registros de llamadas con socios de roaming, MVNO y proveedores de interconexión. Cada relación implica que información protegida se procesa fuera del dominio del propietario.

Creciente presión regulatoria

DORA en la Unión Europea, PCI-DSS 4.0 en la industria de tarjetas, SOX en Estados Unidos, GDPR y sus equivalentes nacionales, las leyes de residencia de datos y los supervisores bancarios desde el Golfo hasta Asia y las Américas asignan la responsabilidad última al propietario de los datos. Tercerizar un proceso no terceriza la responsabilidad. Los reguladores esperan cada vez más que el propietario demuestre, con evidencia, cómo controla a sus terceros, y no simplemente que existe un contrato.

Riesgo en la cadena de suministro

Las brechas más costosas de los últimos años no ocurrieron en las organizaciones cuyos datos quedaron expuestos, sino en sus terceros: procesadores, proveedores de software, socios de servicios. La superficie de ataque de una organización es hoy la unión de las superficies de ataque de todos los que tienen sus datos o sus claves. El perímetro ya no es algo que la organización pueda defender por sí sola.

La criptografía cuántica en el horizonte

La transición a la criptografía poscuántica no es opcional. Pero una organización que ha distribuido claves y datos en claro entre muchos terceros no puede migrar a su propio ritmo. Cada cambio de algoritmo debe coordinarse bilateralmente con cada contraparte, lo que multiplica la complejidad operativa de una transición que ya es exigente dentro de una sola organización.

2.2 Qué ocurre hoy cuando se comparte información

El modelo tradicional de intercambio tiene dos variantes, y ambas terminan igual, sea cual sea el canal: archivos por SFTP o transferencia administrada de archivos, payloads por API, eventos por plataformas de mensajería o transacciones entre integraciones de aplicaciones.

En la primera, el propietario comparte la clave criptográfica. A partir de ese momento, el tercero puede descifrar, firmar o verificar a voluntad, mientras la clave siga vigente, sobre cualquier dato protegido con ella. El propietario no tiene visibilidad sobre cuándo se usa la clave, no puede revocarla sin coordinar un reemplazo con el tercero y debe confiar en los controles del propio tercero para evitar su duplicación o uso indebido.

En la segunda, el propietario confía únicamente en la protección del canal. La información se descifra antes de salir, o viaja protegida solo por el transporte, y llega en claro a la aplicación del tercero: un archivo entregado por SFTP, un payload de API recibido sobre TLS, un mensaje leído de una cola. El tercero conserva entonces información sensible sin protección en su propia infraestructura. El propietario no tiene un registro independiente de cuándo se abrió ni con qué frecuencia, y revocar el acceso implica modificar todo el pipeline de datos.

En ambas variantes la consecuencia es idéntica: el control termina en el momento en que se comparte.

• El propietario no sabe cuándo, con qué frecuencia ni en qué condiciones se abre la información.
• El propietario no puede revocar el acceso en tiempo real.
• El propietario no dispone de evidencia auditable del uso producida dentro de su propio dominio.
• La clave, o el texto en claro, reside fuera del dominio de control del propietario.

Dónde deja vacíos el intercambio tradicional

Ninguna de las estrategias tradicionales es errónea; cada una resuelve el problema para el que fue diseñada. La protección del transporte hace llegar la información al tercero de forma segura, y el cifrado la mantiene ilegible en tránsito y en reposo. Pero ninguna decide cuándo, en qué condiciones ni con qué frecuencia puede abrirla el tercero.

La última fila resume la diferencia. En las estrategias tradicionales, el tercero decide cuándo descifra; en el intercambio soberano, decide la política del propietario.

2.3 El efecto acumulativo del intercambio recurrente

La mayoría de los intercambios con terceros no son eventos aislados. Son recurrentes: un proveedor recibe un nuevo archivo dos veces al mes, un procesador recibe un lote cada semana, un aliado recibe transacciones a diario. En el modelo tradicional, la clave se entrega una sola vez y luego se reutiliza en cada entrega posterior.

Considere una organización que envía datos protegidos a un proveedor dos veces al mes bajo una clave compartida el día cero. Al cabo de un año, el proveedor tiene en su poder 24 entregas, todas protegidas con la misma clave, y la clave que conserva abre cada una de ellas, en cualquier momento y tantas veces como quiera. Esa misma clave abre además cualquier otra información que se haya cifrado alguna vez con ella, dentro o fuera de esa relación.

Por lo tanto, la exposición crece con la vida de la relación. Un compromiso del tercero en el mes doce no expone una entrega: expone un año de entregas y cualquier otro dato que la clave proteja. Revocar esa clave exige generar una nueva, distribuirla y coordinar su activación en ambos lados, mientras las entregas ya recibidas siguen siendo legibles con la anterior.

2.4 Qué está en juego

La pérdida de soberanía criptográfica no es una debilidad abstracta. Se materializa en tres categorías de riesgo.

Cada uno de estos riesgos es consecuencia directa de un único hecho arquitectónico: la autoridad criptográfica sobre los datos se transfirió junto con los datos. Restablecer el control, por lo tanto, no requiere mejores contratos ni más monitoreo, sino un modelo distinto de cómo se ejerce la autoridad criptográfica a través de las fronteras organizacionales.

2.5 Un problema de hoy, no de la era cuántica

Después de varios años de atención a lo poscuántico, es fácil archivar todo riesgo criptográfico bajo el mismo rótulo. Este no pertenece allí. Una clave entregada a un proveedor está igual de expuesta sea clásica o poscuántica, y el texto en claro enviado por SFTP queda expuesto sin importar el algoritmo que lo protegía antes de ser descifrado.

En consecuencia, resolver el problema del intercambio con terceros no depende de una migración poscuántica, de completar un inventario criptográfico de todo el entorno ni de desacoplar primero cada aplicación de su criptografía. Depende de cambiar quién ostenta la autoridad criptográfica en la frontera de la organización. Las organizaciones pueden abordarlo ahora, con los algoritmos y la infraestructura de claves que ya operan, y tratar la preparación poscuántica de sus relaciones externas como un beneficio que viene después y no como una condición previa.

El principio de soberanía criptográfica

Esta es la tesis del documento, y todo lo que sigue es consecuencia de ella.

3.1 La soberanía como propiedad de la organización, no de la clave

El marco CAPA define la soberanía criptográfica como la capacidad de una organización de conservar la autoridad y el control últimos sobre su confianza criptográfica, sus decisiones criptográficas y el uso de sus capacidades criptográficas, independientemente de dónde operen sus datos, su infraestructura o sus procesos de negocio. Su principio central: conservar el control de la confianza, la elección y la autoridad criptográficas dondequiera que operen sus datos.

La definición es deliberadamente más amplia que la propiedad de las claves. Ser dueño de una clave es necesario, pero no suficiente. Una organización que es dueña de una clave y luego entrega una copia a un procesador sigue siendo dueña de la clave, pero ha perdido la soberanía sobre su uso. La soberanía tiene que ver con la autoridad: quién puede ejercer una capacidad criptográfica, en qué condiciones, durante cuánto tiempo y quién puede retirar esa autoridad.

Por lo tanto, cuando se comparte información protegida con terceros, la soberanía va más allá de la custodia. Gobierna quién puede ejecutar operaciones criptográficas, bajo qué restricciones y cuándo puede revocarse esa autoridad, sin necesidad de la cooperación de la parte a la que se le retira.

3.2 Tres propiedades del intercambio soberano

Un intercambio con terceros preserva la soberanía criptográfica cuando presenta tres propiedades de manera simultánea.

Control soberano

El material de claves permanece en el dominio de control del propietario, siempre protegido por un HSM, un KMS o una raíz de confianza equivalente que el propietario administra. No se transfiere ninguna copia a la contraparte. Esta es la propiedad de custodia: determina dónde se ancla la autoridad criptográfica.

Uso mediado

El tercero nunca ejecuta operaciones criptográficas directamente con el material del propietario. Invoca una capacidad, y la invocación se evalúa, se autoriza y se ejecuta dentro del dominio del propietario. Esta es la propiedad operativa: determina cómo se ejerce la autoridad criptográfica.

Auditabilidad completa

Cada invocación queda registrada con su contexto completo (qué actor, qué capacidad, qué material, qué relación de intercambio, qué restricciones se aplicaron) por la infraestructura del propietario. La evidencia no depende de lo que reporte el tercero. Esta es la propiedad probatoria: determina cómo se demuestra la autoridad criptográfica.

Si se elimina cualquiera de las tres, la soberanía colapsa. Control sin mediación es una clave guardada en una bóveda y luego copiada fuera de ella. Mediación sin evidencia es un servicio cuyo uso no puede demostrarse. Evidencia sin control es un registro de decisiones que el propietario no pudo haber evitado.

3.3 La soberanía no requiere centralización

Es importante distinguir la soberanía de la consolidación. Una organización puede distribuir deliberadamente claves y raíces de confianza entre múltiples HSM, plataformas KMS, proveedores, regiones o dominios organizacionales, por razones de resiliencia, aislamiento de riesgos, jurisdicción o negocio. La soberanía no exige reducir esa distribución a un único repositorio. Exige que, dondequiera que se ancle la confianza, la autoridad para usarla permanezca en manos del propietario y se ejerza mediante una mediación gobernada.

Este es el principio que el whitepaper del Cryptographic Control Plane expresa como gobernanza centralizada, confianza distribuida: las decisiones de política, ciclo de vida y control convergen en una sola capa, mientras las claves, las raíces de confianza y la ejecución permanecen donde la organización las necesita.

3.4 Soberanía sobre la elección

La soberanía también abarca la libertad de la organización para elegir su propia criptografía. Hoy, cuando un aliado, una red de tarjetas o un ecosistema sectorial exige un algoritmo, un formato o un estándar específico, ese requisito suele convertirse en el estándar interno de facto para todos los sistemas que tocan el intercambio. En un modelo soberano, el requisito externo de interoperabilidad se satisface para esa interacción, mientras la postura criptográfica interna sigue siendo una decisión propia de la organización.

3.5 Una prueba práctica

CAPA propone una prueba sencilla para este pilar: ¿puede la organización gobernar la política en todos sus dominios de confianza sin mover claves, y revocar la autoridad criptográfica de un tercero sin volver a cifrar los datos? Una organización que debe volver a cifrar los datos, o coordinar un reemplazo de clave con la contraparte, para retirar la autoridad, ha transferido esa autoridad. Una organización que puede retirarla de forma unilateral, en la siguiente invocación, la ha conservado.

3.6 Control sobre cuándo la información pasa a estar en claro

La soberanía sobre el intercambio con terceros se ejerce en un momento preciso: cuando la información protegida se convierte en texto en claro. Cada descifrado es una invocación autorizada, vinculada a un contexto de intercambio, limitada por ventanas de tiempo, topes de uso y límites de tasa, y registrada como evidencia en el dominio del propietario. Así, el propietario controla cómo, cuándo y bajo qué condiciones un tercero puede obtener información en claro.

La autorización puede retirarse en cualquier momento y surte efecto en la siguiente invocación. Los terceros obtienen solo la información que están autorizados a descifrar, cuando la necesitan, un registro o una entrega a la vez, en lugar de un año de información abierto por una sola clave. La información ya descifrada sigue sujeta a las obligaciones contractuales y de protección de datos que rigen la relación.

El cambio de paradigma: de compartir claves a compartir capacidades

El modelo tradicional y el modelo soberano difieren en una sola decisión: qué se comparte.

4.1 El modelo tradicional: compartir la clave

Cuando se comparte la clave, el tercero posee material criptográfico. Puede usar ese material cuando quiera y para lo que quiera, dentro de los límites técnicos de la clave. Revocar la clave exige coordinación bilateral: debe generarse, distribuirse y activarse una nueva clave, y retirarse la anterior, en ambos lados. La auditoría depende de lo que reporte el tercero, porque las operaciones ocurren en la infraestructura del tercero.

4.2 El modelo soberano: compartir una capacidad

Cuando se comparte una capacidad, el tercero no posee nada criptográfico. Se le otorga el derecho de invocar una función (encrypt, decrypt, sign, verify) bajo la gobernanza del propietario. Solo puede hacer lo que se autorizó, cuando se autorizó, sobre el material y dentro del alcance autorizados. La revocación es inmediata y no depende del tercero: el propietario retira la autorización y la capacidad deja de existir. Cada ejecución queda registrada en el dominio del propietario, porque es allí donde ocurre.

4.3 Por qué se trata de un cambio arquitectónico y no procedimental

Es tentador interpretar el modelo soberano como un contrato más estricto o una política de rotación de claves más exigente. No es ninguna de las dos cosas. Los controles procedimentales operan sobre una clave que ya salió del dominio del propietario; intentan limitar las consecuencias de una transferencia que ya ocurrió. El modelo soberano impide la transferencia.

Esa prevención requiere infraestructura: un componente que se ubique entre el tercero y el material criptográfico del propietario, comprenda la relación de intercambio, evalúe cada solicitud frente a la política, ejecute o coordine la operación dentro del dominio del propietario y registre el resultado. Ese componente es un Cryptographic Control Plane.

4.4 Dos planos: transporte y control criptográfico

El intercambio con terceros implica dos funciones distintas. El plano de transporte lleva la información del propietario al tercero: transferencia administrada de archivos, SFTP, API, plataformas de mensajería e integraciones entre aplicaciones. El plano de control criptográfico decide quién puede abrir lo que viaja, en qué condiciones y con qué evidencia. Ambos son complementarios, y el intercambio soberano solo cambia el segundo.

Los pasos 2 y 3 son el intercambio tal como funciona hoy. Los pasos 1 y 4 son el único elemento nuevo: la aplicación del propietario llama a ANKASecure© para proteger la información, y la aplicación del tercero lo invoca para descifrarla, bajo la política del propietario. Ninguna de las dos llamadas viaja por el canal.

Un Cryptographic Control Plane no se ubica en medio del intercambio. No enruta, transforma, programa ni entrega información, no garantiza la entrega ni traduce protocolos; todo eso sigue siendo trabajo del canal. Se conecta en los extremos: el propietario protege la información antes de enviarla, y el tercero invoca una capacidad criptográfica gobernada cuando necesita usarla.

4.5 La información no son solo archivos

Un archivo es una posible representación de la información protegida, no la que la define. Las organizaciones comparten archivos y lotes, registros individuales, payloads de API en JSON o XML, mensajes y eventos, y transacciones entre aplicaciones. El mismo modelo soberano se aplica a todos ellos.

El plano de control puede gobernar operaciones sobre estos tipos de información siempre que la integración incorpore sus capacidades y que los formatos y flujos específicos estén soportados. La aplicación del propietario protege la información antes de enviarla, y el tercero adapta su integración una sola vez para invocar la capacidad en lugar de descifrar con una clave propia. Tras esa integración inicial, la rotación de claves y los cambios de algoritmo no requieren ningún cambio adicional en ninguno de los dos lados.

El rol del Cryptographic Control Plane

El whitepaper del Cryptographic Control Plane define el plano de control como una capa de infraestructura dedicada que desacopla la política criptográfica, la gestión del ciclo de vida y la ejecución de la implementación de las aplicaciones. Las aplicaciones expresan la intención; la infraestructura gobierna la ejecución.

El intercambio con terceros es el caso en el que esa separación resulta más valiosa, porque la parte que expresa la intención no está bajo el control administrativo del propietario. El plano de control se convierte en la frontera en la que el propietario ejerce su autoridad sobre solicitudes que se originan fuera de su dominio.

5.1 Qué aportan los componentes existentes y qué falta

Los HSM y las plataformas KMS son componentes fundamentales de la infraestructura criptográfica empresarial, y nada en este modelo los reemplaza ni les retira la custodia. Sin embargo, las organizaciones suelen suponer que los componentes existentes ya proporcionan intercambio soberano. Cada uno aporta una parte, y ninguno lo aporta por completo.

Un HSM protege la clave y ejecuta operaciones con ella, pero no tiene noción de una relación de intercambio: autentica a un cliente y realiza la operación. Un KMS gestiona el ciclo de vida de la clave y el acceso a ella, pero su modelo de acceso está diseñado para los propios sistemas del propietario, no para gobernar contrapartes con propósitos, ventanas y límites distintos. Un API gateway puede autenticar solicitudes y limitar su tasa, pero no es criptográfico: transporta la solicitud y no tiene autoridad sobre el material ni sobre la operación.

Los esquemas y bibliotecas de cifrado modernos, como HPKE (RFC 9180) y Tink de Google, son componentes valiosos que hacen que el cifrado sea más seguro y más fácil de implementar. Pero responden a una pregunta distinta. HPKE cifra los datos para el poseedor de una clave privada; en un intercambio con terceros, ese poseedor es el tercero, que puede descifrar cada entrega que recibe, en cualquier momento, fuera de la vista del propietario. Combinadas con un KMS en la nube y políticas de identidad, estas herramientas pueden mantener la clave de envoltura en el dominio del propietario y registrar su uso, pero no modelan la relación de intercambio, no pueden aplicar restricciones por entrega como el uso único, siguen atadas a la infraestructura de identidad y de claves de un único proveedor, y dejan los cambios de algoritmo como un trabajo de ingeniería coordinado en ambos lados. Las bibliotecas de cifrado definen cómo se protegen los datos. Un Cryptographic Control Plane gobierna quién puede usar esa protección, para qué y durante cuánto tiempo.

5.2 Cuatro funciones del plano de control en el intercambio soberano

Custodia soberana

Las claves siempre están protegidas por el HSM o KMS del propietario y nunca salen de su control. El plano de control no exige que la custodia se traslade a él; exige que la custodia nunca se traslade al tercero.

Mediación criptográfica

Cada operación criptográfica es invocada por el consumidor y ejecutada bajo la gobernanza del plano de control, nunca ejecutada directamente por el consumidor con el material del propietario. La mediación es lo que convierte una clave compartida en una capacidad compartida.

Gobernanza basada en políticas

Quién puede invocar, qué puede invocar, sobre qué material, en qué contexto y bajo qué restricciones: todo ello se expresa como política y se evalúa en cada invocación. La política es el mecanismo mediante el cual se hace cumplir la intención del propietario sin que este tenga que participar en cada operación.

Evidencia criptográfica

Cada invocación se registra con su contexto completo y trazabilidad forense. La evidencia se genera donde ocurre la operación, es decir, en el dominio del propietario, y por lo tanto es independiente de la contraparte.

5.3 Cómo funciona: la clave nunca se mueve, la capacidad sí

Considere un dominio de control del propietario que contiene el plano de control, el HSM del propietario y sus políticas. Tres partes externas, por ejemplo dos redes de tarjetas y un proveedor de embossing, necesitan cada una realizar operaciones criptográficas sobre los datos del propietario.

Cada parte invoca una capacidad. La invocación atraviesa cinco etapas dentro del dominio del propietario:

1. Autenticación: el actor que invoca se identifica como un actor criptográfico conocido.
2. Autorización: se confirma que el actor posee una autorización válida para la capacidad solicitada, sobre el material solicitado, en el contexto de intercambio aplicable.
3. Restricciones: se evalúan las restricciones asociadas a la autorización: ventana de tiempo, límites de invocación, alcance de los datos, tasa y condiciones operativas.
4. Mediación: la operación se ejecuta dentro del dominio del propietario, con material que nunca sale de su control y que permanece protegido por su raíz de confianza.
5. Evidencia: la invocación, su contexto y su resultado se registran en la pista de auditoría del propietario.

La clave criptográfica nunca sale del dominio de control del propietario. Su protección permanece anclada a la raíz de confianza del propietario, ya sea que la operación se ejecute dentro de un HSM o KMS o dentro del plano de control bajo esa protección. Lo que cruza la frontera organizacional es una solicitud y un resultado, nunca el material que los conecta.

La revocación opera por la misma vía: retirar una autorización, suspender un actor o cerrar un contexto de intercambio surte efecto en la siguiente invocación, sin ninguna acción por parte del tercero y sin volver a cifrar ningún dato.

5.4 Ejecución y raíces de confianza

La mediación no debe interpretarse como que el plano de control sea simplemente un proxy que reenvía cada operación a un HSM. Un Cryptographic Control Plane puede ejecutar operaciones criptográficas directamente mediante sus propios motores, apoyándose en el HSM, el KMS u otra infraestructura de confianza del propietario para proteger el material de claves, establecer raíces de confianza o realizar operaciones que deban permanecer dentro de esas fronteras de confianza. La ejecución ocurre en el dominio de ejecución adecuado para la operación, la política, la arquitectura de claves y la frontera de confianza.

Para el intercambio soberano, esta distinción es importante. La gobernanza centralizada del acceso de terceros no exige que el plano de control se convierta en la raíz de confianza última. El material de claves puede ser generado, gestionado y utilizado por el plano de control mientras su protección permanece anclada a una infraestructura criptográfica controlada por el propietario. El propietario conserva la raíz de confianza; el plano de control ejerce operaciones gobernadas en su nombre. Esta es una de las manifestaciones más claras de la soberanía criptográfica: la organización puede permitir que un plano de control opere su criptografía sin ceder la autoridad sobre ella.

El modelo de intercambio soberano: cinco componentes fundamentales

Gobernar el intercambio con terceros requiere un vocabulario. La gestión tradicional de claves habla de claves y permisos; ese vocabulario no puede expresar una relación con una contraparte, un propósito, una dirección de intercambio ni un límite de uso. El modelo de intercambio soberano introduce cinco componentes conceptuales que, en conjunto, describen quién puede hacer qué, sobre qué material, en qué contexto y bajo qué condiciones.

6.1 Exchange Context

El Exchange Context es el objeto del que carece la infraestructura criptográfica tradicional. Representa la relación en sí misma: la contraparte, el propósito de negocio, la dirección del intercambio (entrante, saliente o bidireccional), la sensibilidad de los datos involucrados y el régimen regulatorio aplicable. Todos los demás componentes están vinculados a un contexto. La relación de embossing con una red de tarjetas y la relación de cobranza con un BPO son contextos distintos, cada uno con sus propios actores, capacidades, activos y restricciones, incluso cuando involucran los mismos datos subyacentes.

Hacer explícito el contexto es lo que permite al propietario razonar sobre el intercambio en el nivel que esperan los reguladores y auditores: no "qué claves existen", sino "qué relaciones existen, qué se le permite hacer a cada una y qué evidencia lo respalda".

6.2 Cryptographic Actor

El Cryptographic Actor es la identidad operativa que invoca las operaciones: el sistema de integración de un tercero, un servicio específico, un workload. Es distinto de la contraparte como organización. Una contraparte puede operar varios actores; un actor siempre está vinculado a un contexto de intercambio. La autenticación establece qué actor está invocando; la autorización se evalúa por actor y por contexto.

6.3 Capability

Una Capability es una función criptográfica abstracta, desacoplada del material que la implementa. Una autorización de la capacidad "decrypt" en un contexto determinado no expone qué algoritmo, clave o versión de clave realiza el descifrado; estos los gobierna el propietario y pueden cambiar con el tiempo sin ningún cambio en la autorización. Este desacoplamiento es lo que dota de agilidad criptográfica al intercambio soberano: el propietario puede migrar el mecanismo subyacente —incluso hacia algoritmos poscuánticos— mientras los terceros siguen invocando la misma capacidad.

6.4 Cryptographic Asset

El Cryptographic Asset es la clave o el material criptográfico. Siempre está protegido por el HSM, el KMS o la raíz de confianza del propietario y nunca se entrega; solo se media su uso. Un activo puede estar vinculado a uno o muchos contextos, pero el vínculo otorga uso, no posesión. La rotación, el versionado y el retiro del activo son decisiones de ciclo de vida del propietario y resultan invisibles para los actores que invocan capacidades sobre él.

6.5 Constraint Policy

La Constraint Policy expresa las condiciones bajo las cuales una autorización es válida: una ventana de tiempo, un número máximo de invocaciones, un alcance por lote o por registro, un límite de tasa, restricciones de horario hábil, semántica de uso único, revocación automática al vencer. Las restricciones se evalúan en cada invocación, en el dominio del propietario. Son las que convierten una autorización permanente en una acotada operativamente: la diferencia entre "este proveedor puede descifrar" y "este proveedor puede descifrar este lote, una sola vez, dentro de las próximas dos horas".

6.6 Cómo encajan los componentes

Una sola invocación involucra a los cinco. Un actor, en un contexto, invoca una capacidad sobre un activo, sujeta a una política de restricciones. La autorización solo prospera cuando todos los vínculos son válidos; la ejecución ocurre dentro del dominio del propietario; el registro captura los cinco elementos. Juntos responden a la pregunta que gobierna el intercambio soberano: quién puede hacer qué, sobre qué material, en qué contexto y bajo qué condiciones, con evidencia completa.

6.7 Rotación y evolución de algoritmos detrás de una capacidad estable

Como la capacidad está desacoplada del activo, el propietario puede cambiar el activo con la frecuencia que exija su política. Una clave nueva cada mes, una clave nueva por entrega o un algoritmo nuevo cada trimestre son decisiones de ciclo de vida que se toman en el dominio del propietario. El tercero sigue invocando la misma capacidad a través de la misma integración; no necesita saber, ni puede saber, qué clave o algoritmo atiende cada invocación. Las aplicaciones del propietario tampoco cambian, porque también consumen la capacidad y no un mecanismo específico.

Esto convierte la rotación de claves y las transiciones de algoritmo en las relaciones externas de proyectos bilaterales en decisiones de política y, combinado con restricciones de uso único, limita el impacto de cualquier compromiso a la entrega autorizada, y no a todo el historial de la relación.

El intercambio soberano en la práctica

El modelo se entiende mejor a través de los escenarios para los que fue diseñado. Cuatro provienen de la banca, donde la concentración de datos regulados, procesamiento por terceros y dependencia criptográfica es mayor, y se eligieron para cubrir los principales canales de intercambio: archivos por lotes, procesamiento a nivel de registro, integraciones por API y entregas recurrentes mediante transferencia administrada de archivos. En todos los casos, el canal existente se mantiene. Una sección final muestra cómo la misma estructura se aplica en distintas industrias.

7.1 Emisión de tarjetas con múltiples proveedores de embossing

Un banco emite tarjetas de pago a través de varios proveedores: dos redes internacionales de tarjetas y un emisor local. Cada proveedor debe descifrar datos sensibles del tarjetahabiente para producir la tarjeta física o digital. En el modelo tradicional, el banco comparte una clave con cada proveedor o comparte archivos descifrados. Cada proveedor se convierte en depositario de la autoridad criptográfica del banco, y el compromiso de cualquiera de ellos expone el material de todos.

En el modelo soberano, el banco define un Exchange Context por proveedor, cada uno con su propio actor, su autorización de capacidad y sus restricciones:

Todas las claves permanecen bajo el control del banco, protegidas por su HSM. La aplicación de emisión de tarjetas prepara cada lote; cada proveedor invoca la capacidad decrypt para su propio lote, dentro de su propia ventana, a través del plano de control. Lo que gana el banco:

• Aislamiento total entre proveedores. La Red A nunca ve el material de la Red B. Si un proveedor se ve comprometido, el impacto es quirúrgico.
• Ninguna exposición de claves. Ningún proveedor recibe jamás una clave. Solo ejecutan las capacidades que el banco permite.
• Revocación inmediata sin coordinación. Si un proveedor cambia o se produce un incidente, el corte es instantáneo desde el plano de control.
• Evidencia lista para auditoría. Cada invocación queda registrada: qué actor, qué contexto, qué capacidad, qué restricciones.
• Políticas por proveedor. Cada proveedor tiene reglas distintas; el modelo las separa de forma nativa sin duplicar infraestructura.
• Control operativo por lote. Cada lote se autoriza individualmente, con su propia ventana y su propio límite de uso.

7.2 BPO de cobranza y procesamiento tercerizado

Un proveedor de tercerización de procesos de negocio opera en nombre del banco sobre los datos de clientes en mora. Hoy, el banco descifra esa lista de clientes, envía archivos CSV al BPO por SFTP y el BPO opera sobre datos en claro en sus propios servidores. El banco no tiene registro de qué registros se abrieron ni cuándo; los archivos en claro permanecen en la infraestructura del BPO; revocar el acceso implica rediseñar todo el proceso ETL.

El BPO sigue cumpliendo su función y el canal SFTP puede mantenerse. Lo que cambia es lo que viaja por él: información protegida en lugar de archivos en claro. El BPO abre un registro a la vez mediante capacidades gobernadas, dentro de las condiciones que fijó el banco, y el banco conserva la evidencia.

7.3 Originación de crédito con una fintech sobre una API existente

Un banco envía datos de clientes a una fintech aliada a través de una API REST para la evaluación crediticia. Los campos sensibles (identificación, ingresos, cuenta) solo están protegidos por TLS y llegan en claro a la aplicación de la fintech. Si la alianza termina o la fintech sufre un incidente, el banco no tiene forma de impedir el uso posterior de lo que envió, ni evidencia de qué campos se consultaron.

En el modelo soberano, la API, sus contratos y su infraestructura no cambian. La aplicación del banco cifra los campos sensibles dentro del payload JSON antes de enviarlo. El servicio de la fintech invoca la capacidad decrypt solo cuando necesita un campo para evaluar una solicitud.

Los pasos 2 y 3 son el intercambio tal como funciona hoy. Los pasos 1, 4 y 5 son nuevos: los campos se protegen dentro del payload y se abren mediante una invocación gobernada.

El banco decide cuándo y bajo qué condiciones la fintech obtiene cada campo en claro: solo lo que necesita para la solicitud en curso, durante la vigencia de la alianza y con evidencia de cada descifrado. La fintech nunca tiene una clave del banco, y una alianza que termina pierde de inmediato el acceso criptográfico, sin necesidad de coordinar nada con la fintech.

7.4 Entregas recurrentes sobre una plataforma existente de transferencia administrada de archivos

Un banco envía datos protegidos a un proveedor dos veces al mes, por ejemplo para el procesamiento de nómina, reclamaciones o KYC. En el modelo tradicional descrito en la sección 2.3, una única clave compartida abre todas las entregas del año.

Las entregas siguen viajando por la plataforma de transferencia administrada de archivos que el banco ya tiene, con el mismo calendario y el mismo cifrado de transporte. Lo que cambia es lo que viaja y quién decide cuándo puede abrirse.

La plataforma de transferencia administrada de archivos garantiza que cada entrega llegue. El plano de control decide cuándo, bajo qué condiciones y cuántas veces puede abrirse.

En el modelo soberano, el banco define un Exchange Context para la relación y una política para el material que la respalda: una clave nueva cada mes y un algoritmo revisado cada trimestre, avanzando progresivamente de algoritmos clásicos a mecanismos híbridos y poscuánticos. Cada entrega se autoriza con un permiso decrypt de uso único, válido durante una ventana de 48 horas. En un año, esa política produce doce claves y cuatro algoritmos y, una vez que la integración del proveedor invoca la capacidad, no requiere más cambios de código, ni en los sistemas del banco ni en la integración del proveedor. El proveedor hace la misma llamada “decrypt” durante todo el año.

El resultado invierte el efecto de acumulación. En lugar de una relación cuya exposición crece con cada entrega, el banco opera una cuya exposición está acotada, en todo momento, a la entrega autorizada en curso. Si el proveedor se ve comprometido, no hay ninguna clave que robar, y las entregas ya procesadas no pueden volver a abrirse.

7.5 Más allá de la banca

Los escenarios anteriores son instancias de un patrón general: un propietario de los datos, una contraparte que debe realizar operaciones criptográficas sobre los datos del propietario y una expectativa regulatoria de que el propietario mantenga el control. Ese patrón se repite en todas las industrias y en todos los canales: la información puede viajar como archivos, payloads de API, mensajes o transacciones.

Un solo modelo conceptual los cubre a todos. Los componentes no cambian; solo cambian los contextos, los actores y las restricciones.

Alineación regulatoria

El intercambio soberano no está diseñado en torno a una regulación en particular. Está diseñado en torno al principio que esas regulaciones comparten entre jurisdicciones: el propietario de los datos es responsable de cómo los terceros usan sus datos y debe poder demostrar control. Cuando ese principio se implementa en la arquitectura, la alineación con marcos específicos viene por añadidura.

Tres aspectos merecen especial atención. Primero, la evidencia. La mayoría de los marcos exigen que el propietario demuestre el control, no que simplemente lo afirme. La evidencia generada por la infraestructura del propietario para cada operación criptográfica —independiente de los reportes del propio tercero— es cualitativamente distinta de las certificaciones contractuales. Segundo, la revocabilidad. Los marcos que abordan el riesgo de terceros esperan que el propietario pueda terminar el acceso cuando un proveedor se ve comprometido o una relación finaliza. La revocación inmediata y unilateral es una propiedad estructural del modelo soberano, no un procedimiento que dependa de la cooperación de la contraparte. Tercero, la dependencia. Los supervisores han comenzado a preguntar explícitamente por las dependencias de terceros en materia criptográfica. La circular del Banco Central de Arabia Saudita sobre los riesgos de la computación cuántica, vigente desde agosto de 2026, exige a las instituciones financieras identificar, para sus activos criptográficos prioritarios, las restricciones, los desafíos y las dependencias de terceros que afectan su resiliencia criptográfica. Un modelo de intercambio en el que las contrapartes nunca poseen claves elimina toda una clase de esas dependencias.

Valor para el negocio

El valor del intercambio soberano llega a tres audiencias, cada una con una preocupación distinta.

9.1 Dónde se materializa el retorno

El modelo de valor del intercambio soberano puede resumirse en cuatro indicadores.

9.2 Preparación poscuántica como consecuencia, no como requisito previo

El intercambio soberano resuelve un problema que existe hoy con los algoritmos actuales, y las organizaciones pueden adoptarlo antes de iniciar sus programas poscuánticos o mientras los ejecutan. Pero como los terceros invocan capacidades en lugar de poseer claves, el algoritmo y la clave detrás de una capacidad pueden cambiar más adelante sin ningún cambio del lado del tercero. Una migración poscuántica que, en el modelo tradicional, exige coordinación bilateral con cada contraparte se convierte en un cambio de política en el dominio del propietario. Por lo tanto, el modelo de intercambio soberano acelera la adopción poscuántica en las relaciones externas de la organización —la parte de la migración más difícil de programar y coordinar— sin reescribir aplicaciones ni renegociar material criptográfico.

Ruta de adopción

El intercambio soberano no exige reemplazar por completo las relaciones de intercambio existentes, ni contar con una hoja de ruta poscuántica o con un inventario criptográfico completo. Parte de una lista que toda organización ya tiene: sus terceros. Los equipos de compras, riesgo y seguridad saben qué contrapartes reciben hoy claves o archivos. Se adopta un contexto de intercambio a la vez, comenzando donde el problema es más agudo o la urgencia regulatoria es mayor, con los algoritmos y la infraestructura de claves ya existentes, y se amplía progresivamente.

La adopción tampoco reemplaza los canales de intercambio de la organización. La transferencia administrada de archivos, las API, la mensajería y las integraciones se mantienen. La aplicación del propietario protege la información antes de enviarla, y cada tercero adapta su integración una sola vez para invocar la capacidad en lugar de descifrar con una clave propia.

La ruta de adopción se alinea con el programa de modernización descrito en el whitepaper del Cryptographic Control Plane, pero no depende de él. Los intercambios con terceros son candidatos naturales para la línea brownfield crítica: concentran la exposición regulatoria, están bien delimitados y cada contexto migrado elimina del panorama una clave compartida o una transferencia en claro. También pueden abordarse de forma independiente, como el primer uso gobernado de un plano de control.

ANKASecure© y el intercambio soberano

Los capítulos anteriores describen un modelo arquitectónico que puede implementarse de más de una manera. ANKASecure© es una implementación del Cryptographic Control Plane que ofrece el intercambio gobernado con terceros como capacidad nativa: reemplaza las claves privadas de larga vida entregadas a los proveedores por autorizaciones de capacidad revocables.

11.1 Los cinco componentes fundamentales como objetos de primera clase

En ANKASecure©, Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset y Constraint Policy son objetos de primera clase de la plataforma, no convenciones superpuestas a un almacén de claves. Una relación de intercambio se define una sola vez, como un contexto que modela la contraparte, el alcance de las claves y la autoridad operativa otorgada; los actores se inscriben en él; las autorizaciones de capacidad vinculan actores con activos bajo políticas de restricción, y cada invocación se evalúa frente a esos vínculos antes de ejecutarse. La revocación actúa sobre los mismos objetos —una autorización, un actor o un contexto completo— y surte efecto en la siguiente invocación.

Topología de intercambio criptográfico de ANKASecure© para un contexto operativo: intercambios entre aplicaciones de negocio y contrapartes, clasificados por sensibilidad y dirección.

La vista de topología muestra lo que gobierna ANKASecure©: las relaciones de intercambio entre las aplicaciones de la organización y sus contrapartes, ya sea que esas relaciones operen sobre archivos, API, mensajes o canales de reporte regulatorio. El objeto gobernado no es el canal, sino la relación.

11.2 Autorizaciones de capacidades y restricciones aplicadas

Las autorizaciones de capacidad en ANKASecure© se aplican mediante cuatro restricciones: una ventana de tiempo, un límite de usos, un límite de tasa por minuto y una opción de uso único. En conjunto, implementan escenarios como “descifrar esta entrega, una sola vez, dentro de las próximas 48 horas”.

11.3 Federación de identidad de workload

Las contrapartes se autentican con su propia identidad de workload, mediante tokens OIDC emitidos por su propia infraestructura de identidad. No se intercambian credenciales de ANKASecure© con la contraparte, lo que elimina de la relación otra clase de secretos compartidos.

11.4 Custodia, ejecución y raíces de confianza

ANKASecure© no es un proxy de políticas. Proporciona directamente capacidades de ejecución criptográfica y de ciclo de vida de claves, al tiempo que se integra con HSM externos, plataformas KMS y entornos PKCS#11 para la protección de claves, el anclaje de confianza o las operaciones que deben permanecer dentro de esas infraestructuras. Según la operación y el modelo de confianza, la ejecución puede ocurrir dentro del propio ANKASecure© o a través del HSM o KMS del propietario.

En el modelo de intercambio soberano, esto significa que la gobernanza centralizada del acceso de terceros no convierte a ANKASecure© en la raíz de confianza última. El material de claves puede ser generado, administrado y utilizado por ANKASecure©, mientras su protección permanece anclada en infraestructura criptográfica controlada por la organización. El propietario conserva la raíz de confianza; el plano de control ejecuta operaciones gobernadas en su nombre; el tercero nunca posee ninguna de las dos.

11.5 Revocación, evidencia y agilidad criptográfica

La revocación es inmediata y no exige recifrar los datos protegidos. Cada operación, decisión de autorización y aplicación de restricciones queda registrada en una pista de auditoría firmada, con su contexto completo —actor, contexto, capacidad, activo, restricciones y resultado—, lo que produce evidencia independiente de la contraparte y lista para uso en auditorías y análisis forense.

Como las capacidades están desacopladas del material y de los mecanismos que las respaldan, la agilidad criptográfica de ANKASecure© se aplica a las relaciones de intercambio tal como a las aplicaciones internas. Las claves pueden rotarse con la frecuencia que exija la política, y el algoritmo y la clave detrás de una capacidad autorizada pueden evolucionar —incluso hacia mecanismos híbridos y poscuánticos basados en NIST FIPS 203, 204 y 205— por política, sin ningún cambio en la autorización ni en la integración del tercero.

11.6 Tres puertas, una decisión arquitectónica

Las organizaciones llegan a ANKASecure© a partir de una de tres preocupaciones. Sea cual sea la puerta por la que entren, reciben las tres capacidades, porque las tres son propiedades del mismo plano de control.

11.7 Cómo empezar

1. Sesión de descubrimiento técnico: mapeo de los intercambios críticos con terceros de la organización y de su problema más apremiante.
2. Demostración y arquitectura de referencia: ANKASecure© funcionando de extremo a extremo en un caso análogo al de la organización.
3. Plan de piloto acotado: un Exchange Context específico para un piloto de 6–8 semanas, con claves ancladas en el HSM existente de la organización.

Conclusión

Durante décadas, las organizaciones aceptaron que compartir datos con un tercero significaba compartir el control sobre ellos. Esa aceptación no fue una decisión de diseño; fue una limitación de la arquitectura disponible. Una clave, una vez entregada, llevaba consigo la autoridad criptográfica del propietario, y ningún contrato, régimen de monitoreo o calendario de rotación podía recuperar esa autoridad. En las relaciones recurrentes, esa autoridad se extendía a cada entrega que el tercero recibiera.

La soberanía criptográfica elimina esa limitación. Las claves nunca salen del dominio de control del propietario. Los terceros están autorizados a invocar capacidades —funciones específicas, sobre material específico, en un contexto de intercambio específico, bajo restricciones explícitas— y cada invocación se ejecuta y se registra dentro del dominio del propietario. El control no termina en el momento de compartir; se ejerce en cada descifrado.

Nada de esto exige reemplazar la forma en que se mueve la información. Los archivos, los payloads de API, los mensajes y las transacciones siguen circulando por los canales que la organización ya opera; el plano de control gobierna el acceso criptográfico a lo que circula por ellos.

El paso de compartir claves a compartir capacidades requiere un Cryptographic Control Plane: una capa que gobierna, en lugar de almacenar o transportar. Con ella, el propietario obtiene custodia soberana, uso mediado, gobernanza basada en políticas y evidencia criptográfica sobre cada relación externa y, como consecuencia de la misma arquitectura, la capacidad de rotar claves y evolucionar la criptografía detrás de esas relaciones, incluso hacia mecanismos poscuánticos, sin renegociar nada con nadie.

Nada de esto necesita esperar a un programa poscuántico. La exposición existe hoy, con los algoritmos actuales, y la solución también.

Los cinco componentes —Exchange Context, Cryptographic Actor, Capability, Cryptographic Asset y Constraint Policy— ofrecen a las organizaciones un vocabulario para gobernar el intercambio con terceros al nivel que hoy esperan los reguladores, los auditores y las juntas directivas. ANKASecure© implementa ese vocabulario como un Cryptographic Control Plane. La decisión arquitectónica es la misma tanto si una organización llega por el control criptográfico empresarial, por la preparación poscuántica o por la soberanía sobre sus intercambios con terceros: criptografía gobernada como infraestructura, con la raíz de confianza donde la organización la requiera.