El problema real: confianza e IP en la transformación de código fuente

La migración de código fuente entre organizaciones introduce un conflicto estructural de confianza bilateral.

  • Cliente A posee código VB6 estratégico (propiedad intelectual, algoritmos, lógica de negocio).

  • Proveedor B dispone de una herramienta propietaria para transformar código a .NET (su propio activo de IP).

Ambas partes necesitan colaborar, pero ninguna puede permitirse exponer su IP a la otra.

Los mecanismos tradicionales —NDAs, auditorías, ejecución supervisada, confianza contractual— no ofrecen garantías técnicas y dependen de personas y procesos, no de verificabilidad criptográfica.

La pregunta correcta no es “¿en quién confiamos?”, sino:

¿Cómo diseñamos un sistema donde no sea necesario confiar en nadie?

Azure Confidential Computing: protección de datos en uso

Azure Confidential Computing introduce un cambio fundamental: los datos permanecen cifrados incluso mientras se procesan.

Esto se logra mediante Trusted Execution Environments (TEE) basados en hardware (AMD SEV-SNP, Intel TDX / SGX), donde:

  • El código y los datos solo se descifran dentro de la CPU segura

  • Ni el sistema operativo, ni el hipervisor, ni los administradores cloud pueden acceder al contenido

  • La integridad del entorno puede verificarse criptográficamente

Componentes relevantes

  • Confidential VMs: máquinas virtuales cuya memoria está cifrada y aislada del hipervisor.

  • Enclaves de aplicación: ejecución aislada a nivel de proceso o contenedor.

  • Azure Attestation: verificación remota y criptográfica de que el entorno es genuino y ejecuta exactamente el código esperado.

Clean Room técnica: colaboración sin exposición de IP

Un clean room técnico es un entorno donde:

  • Cliente A nunca expone su código VB6

  • Proveedor B nunca expone su algoritmo de conversión

  • Ninguna parte puede inspeccionar la IP de la otra

  • Todo es verificable mediante atestación, no promesas

Propiedades clave

  1. Aislamiento completo

    • El código VB6 solo existe en claro dentro del enclave

    • El binario de conversión de B tampoco es accesible por A

  2. Atestación previa obligatoria

    • A valida el hash del software de B antes de enviar datos

    • Si la atestación falla → el proceso se aborta

  3. Cifrado extremo a extremo

    • Entrada cifrada para el enclave

    • Salida cifrada solo para A

    • B actúa únicamente como operador de infraestructura

  4. Ejecución restringida

    • Sin acceso a Internet

    • Sin I/O no autorizado

    • Superficie mínima de ataque

Flujo de migración .NET → Java en enclave confidencial

Gestión de claves (punto crítico)

La arquitectura solo es válida si las claves:

  • Nunca están en manos de B

  • Solo se liberan al enclave tras atestación válida

  • Se gestionan mediante HSM o Azure Key Vault con políticas de attestation-based release

Sin este punto, el modelo se rompe.

¿Qué protege realmente esta arquitectura?

Sí protege

  • Código fuente original de Cliente A

  • Código .NET convertido

  • Algoritmo de transformación de Proveedor B

  • Integridad del proceso

  • Trazabilidad y evidencia auditada

Riesgos

  1. IP funcional

    • Si A decide compartirlo, la confidencialidad se pierde

  2. Side-channels avanzados

    • Riesgo bajo, no cero; para que se entienda, podemos mitigar muchos ataques pero los malos siempre estan por delante de nosotros

    • Mitigable con SEV-SNP / TDX y buenas prácticas; esta sería la tecnología y procedimientos que intenta ayudar contra los malos

    • Mala higiene de claves en el cliente

      • El enclave no protege errores en el endpoint de A; para que se entienda no protege el portatil del programado de A que envia el código

    Comparación con alternativas

    Enfoque Exposición IP Verificable Práctico
    NDAs / confianza Alta No Sí
    Clean room humano Media No No
    Tool on-prem IP de B expuesta No Sí
    FHE / SMPC Baja Sí No (hoy)
    Confidential Computing Mínima Sí Sí

    Requisitos no negociables para que sea válido

    1. Atestación obligatoria antes de liberar datos

    2. Gestión de claves basada en enclave

    3. Código de enclave mínimo y auditado

    4. Red y salidas estrictamente controladas

    5. Enclaves efímeros (destrucción post-ejecución)

    6. Contratos alineados con la arquitectura

    7. Uso de hardware y firmware actualizados

    ¿Qué es FHE/SMPC?

      Existen alternativas criptográficas puras como el Fully Homomorphic Encryption (FHE) o el Secure Multi-Party Computation (SMPC), que permiten procesar datos sin descifrarlos nunca. Sin embargo, su coste computacional y sus limitaciones funcionales hacen que hoy sean impracticables para escenarios complejos como la transformación de código fuente. Frente a ello, los enclaves de Confidential Computing ofrecen una solución viable en producción: los datos se descifran únicamente dentro de hardware aislado, manteniendo garantías fuertes con rendimiento cercano al nativo.

      Si te interesa el tema del FHE te dejo una librería: Microsoft SEAL.

      Conclusión

      Esta arquitectura no es marketing ni teoría criptográfica.

      Es una solución práctica, verificable y hoy disponible para resolver un problema que antes solo podía abordarse con confianza ciega.

      El valor clave no es Azure, sino el cambio de modelo mental:

      La confianza deja de ser organizativa y pasa a ser criptográfica.