Qué revisa tu cliente antes de mandarte sus datos

"Lo corremos en un TEE" es una afirmación. Del otro lado de la mesa hay alguien cuyo trabajo es convertir afirmaciones en comprobaciones, y va a hacer tres preguntas: qué código está corriendo, quién lo dice, y qué hace ese código con mis datos.

La buena noticia es que las tres tienen respuesta mecánica. El trabajo es publicarlas antes de la reunión y no durante.

La lista que corren§

1. Traer la identidad. Un servicio atestiguado publica GET /.well-known/attestation: el documento firmado por la plataforma, la clave pública, el hash del programa y el hash de la configuración bajo la que corre.

2. Verificar el documento. Firma, cadena de certificados hasta la raíz de la plataforma, ventana de validez — fallando cerrado en la primera duda. Con Synsema en el cliente es una sola llamada, con el reloj pasado explícitamente en vez de leído del anfitrión:

let v be attestation_verify(bytes(seen["document"], "base64"),
    {"format": seen["format"], "now": floor(now()),
     "expect": {"measurements": {"pcr0": PINNED}}})

3. Recalcular la atadura. El documento se compromete con sha256(clave_pública ‖ program_sha ‖ config_sha). Un documento que verifica pero ata otra clave u otro programa no vale nada; una clave que coincide pero no tiene documento es apenas una clave. El orden importa: verificar, recalcular, comparar y recién ahí mandar.

4. Leer la configuración. config lleva el techo bajo el que corrió el programa, si las etiquetas de flujo de información estaban prendidas, el perfil, y si la clave anunciada es la que termina el TLS. Su hash está dentro del payload firmado, así que no se puede atestiguar una configuración endurecida y servir una floja.

5. Preguntar qué sale. Esta es la pregunta que el hardware no responde, y la que decide el trato. synsema code check --json lista cada declassify del programa con su línea y la oración que escribió quien lo programó:

"declassify": [
  {"line": 11, "reason": "the yes/no is what the lender asked for; the score stays inside"}
]

Una entrada, una oración, aplicada en tiempo de ejecución: todo lo demás que sea privado se rechaza en la respuesta, en el log y en el archivo — antes de que el efecto ocurra.

Qué publica tu lado§

Poné estas cuatro cosas donde un desconocido pueda encontrarlas sin preguntarte:

• El program_sha de la versión, y la medición esperada de la plataforma (PCR0 en Nitro, MRTD/RTMRs en TDX, measurement en SEV-SNP) tomada del propio paso de construcción de la plataforma.
• La procedencia del motor. gh attestation verify synsema-linux-x86_64 --repo kitecosmic/synsema responde con el workflow, el commit y el tag que produjeron esos bytes exactos. Atestiguar un programa ejecutado por un intérprete de origen desconocido atestigua la mitad equivocada, y quien revisa bien lo sabe.
• La lista de desclasificaciones de la versión que estás corriendo, en palabras.
• Un verificador que puedan correr — veinte líneas, sin SDK, sin cuenta.

Una página con esas cuatro cosas vale más en una conversación de compras que cualquier cantidad de prosa sobre aislamiento por hardware.

Los límites — decilos primero§

Marcar vos mismo el borde es lo que separa una afirmación de ingeniería de una de marketing, y quien revisa lo nota:

• Una atestación prueba qué código corre, no que el código sea bueno. Por eso mismo la lista de desclasificaciones va al lado.
• No impide que el operador niegue el servicio, descarte un pedido o apague la máquina. Confidencialidad y disponibilidad son propiedades distintas.
• Los canales laterales no los cubre una firma. Tiempos, tamaños y la cantidad de líneas que imprime un programa filtran, y por eso el lenguaje trata un print dentro de una rama que dependió de datos privados como una violación en vez de redactarlo — pero nadie debería afirmar que la clase está cerrada.
• El soporte de verificación varía por plataforma. Hoy Synsema verifica documentos de Nitro contra la raíz de AWS fijada; los quotes de TDX y SEV-SNP los produce el motor y se verifican con el material del fabricante del lado del cliente. Decile a la contraparte cuál de los dos le toca.

Quién pide esto§

El patrón se repite en industrias que no se parecen en nada:

• Salas limpias de datos — dos empresas cruzan sus listas de clientes y cada una ve solamente la intersección.
• IA confidencial — un hospital corre el modelo de un tercero sobre registros que el proveedor no debe retener, y los pesos del proveedor tampoco quedan legibles.
• Custodia y firma — una clave que puede usarse y nunca exportarse, con cada uso registrado.
• Matching privado — órdenes que se cruzan sin que nadie vea el libro antes del cruce.

Son la misma arquitectura: un programa chico, datos que nadie de afuera puede leer, y un valor que sale con un motivo adosado.

Por dónde empezar§

Construí primero la versión chica: una ruta, una decisión, las etiquetas prendidas, un documento de identidad y el verificador en manos de un cliente amigo. Todo lo demás — el sitio, el alta, el panel, los jobs, la facturación — es trabajo de producto común que va afuera de la caja, y se despliega acá con un comando.

La referencia del lado del motor es Atestación y Etiquetas de flujo de información.