Resumen Técnico: Witnessd: Prueba de Proceso mediante Colapso Adversario

1. Planteamiento del Problema

Los sistemas actuales de evidencia digital sufren una brecha fundamental entre la propiedad y el proceso. Mientras que las firmas digitales prueban la posesión de una clave y la atestación del contenido, no verifican que un humano haya creado físicamente el contenido. Un adversario podría generar texto utilizando un modelo de lenguaje, construir estados intermedios del documento a posteriori y firmar cada hash, creando una cadena de firmas válidas que no demuestra nada sobre el origen del contenido.

Los enfoques existentes fallan al abordar esto en entornos adversarios:

• Los sistemas de detección dependen de un "oráculo de verdad fundamental" que no existe en escenarios contenciosos; un detector con un 95% de precisión es inútil si el adversario controla el 5% de los casos que este ataca.
• La certificación depende de la confianza social en terceros, que puede ser comprometida o coaccionada.
• La integridad criptográfica (firmas) prueba que los bits no fueron modificados después de la firma, pero no que los bits fueron producidos por un proceso físico específico.

El artículo argumenta que los sistemas de evidencia no deben evaluarse por la precisión de la detección o la autoridad de certificación, sino por su capacidad para colapsar el espacio de explicaciones alternativas plausibles.

2. Metodología

El Principio de Colapso Adversario

La contribución teórica central es el Principio de Colapso Adversario. El artículo postula que un sistema de evidencia robusto obliga a cualquier desafiante a pasar de la duda vaga a Alegaciones Específicas.

• Criterio de Alegación Específica: Para disputar la evidencia, un adversario debe nombrar un mecanismo concreto, identificar una ventana de tiempo acotada, implicar un nivel de capacidad específico y realizar afirmaciones que sean independientemente comprobables.
• Colapso Adversario: La evidencia logra el "colapso" cuando refutarla requiere una conjunción de alegaciones específicas contra múltiples componentes que poseen supuestos de confianza independientes. Disputar un componente es insuficiente; disputar el todo requiere alegar una complicidad coordinada a través de distintos límites de confianza (por ejemplo, el kernel, el hardware, anclajes de terceros).

El Jitter Seal (Primitiva de Prueba de Proceso)

El Jitter Seal es una primitiva criptográfica diseñada para probar que ocurrió una interacción física de teclado en tiempo real durante la creación del documento.

• Mecanismo: El sistema inyecta retrasos imperceptibles de microsegundos (500–3000 $\mu$s) en el proceso de generación del documento.
• Vinculación Criptográfica: Cada valor de jitter se deriva mediante HMAC-SHA256 de un secreto de sesión ($S$) y seis componentes de vinculación:
  1. Ordinal de pulsación de tecla ($i$)
  2. Hash del documento ($H_i$)
  3. Marca de tiempo ($t_i$)
  4. Transición de zona ($Z_i$): Codifica las transiciones de región del teclado (8 zonas) sin revelar las teclas específicas.
  5. Cubeta de intervalo ($B_i$): Cuantiza los intervalos entre pulsaciones de tecla en 10 cubetas.
  6. Jitter previo ($J_{i-1}$): Asegura la integridad de la cadena.
• Seguridad: Sin el secreto de sesión, un adversario no puede falsificar la secuencia de valores de jitter. La probabilidad de adivinar valores de jitter válidos para $n$ muestras es $(1/R)^n$, donde $R$ es el rango del jitter.

La Arquitectura Witnessd

Witnessd integra el Jitter Seal con cinco puntos de verificación independientes para aplicar el Principio de Colapso Adversario:

1. Capa 0 (Jitter Seal): Prueba el proceso físico.
2. Capa 1 (Funciones de Retardo Verificables - VDF): Utiliza VDFs de Pietrzak para probar un tiempo mínimo transcurrido entre puntos de control, evitando ataques de compresión de tiempo.
3. Capa 2 (Anclajes Externos): Ancla las marcas de tiempo a fuentes públicas de terceros (cadena de bloques de Bitcoin vía OpenTimestamps o RFC 3161 TSA) para evitar la manipulación del reloj local.
4. Capa 3 (Validación de Fuente Dual): Valida las pulsaciones de teclas mediante la referencia cruzada de flujos a nivel de aplicación (ej. CGEventPost) con flujos a nivel de hardware (USB/Bluetooth HID). Una pulsación de tecla válida debe aparecer en ambos dentro de un margen de 50 ms.
5. Capa 4 (TPM/Enclave Seguro): Atestación de hardware opcional para el estado de la plataforma y contadores monotónicos para prevenir la repetición (replay).
6. Capa 5 (Cadena de Hashes): Almacena la evidencia en una Estructura de Árbol de Merkle de Montaña (MMR) para asegurar la integridad de solo adición (append-only).

3. Contribuciones Clave

1. Principio de Colapso Adversario: Un nuevo criterio de evaluación para sistemas de evidencia que prioriza forzar alegaciones específicas y comprobables en lugar de dudas vagas.
2. Jitter Seal: Una primitiva de prueba de proceso formal que vincula criptográficamente la dinámica de la escritura física (tiempos, transiciones de zona) con los estados del documento.
3. Arquitectura Witnessd: Un sistema multicapa que combina jitter seals, VDFs, anclajes externos y validación de fuente dual para crear límites de confianza independientes.
4. Análisis de Seguridad: Una formalización de los ataques residuales, demostrando que derrotar el sistema requiere capacidades específicas de alto nivel (ej. compromiso del kernel, colusión de terceros) en lugar de una falsificación genérica.
5. Evaluación Empírica: Implementación y pruebas del sistema a través de miles de ensayos.

4. Resultados y Evaluación

El artículo reporta resultados de 31,000 ensayos de jitter seal y más de 700 pruebas del sistema:

• Éxito de Verificación: 1,000 pruebas válidas verificadas con éxito (tasa de éxito del 100%).
• Fallo de Falsificación: 30,000 ensayos de ataque (jitter fabricado, documentos discordantes, secretos incorrectos) fallaron la verificación (tasa de éxito del 0%).
• Probabilidad de Falsificación: Calculada aproximadamente como $(1/2500)^{50} \approx 10^{-170}$ para una secuencia de 50 muestras.
• Rendimiento:
  • Computación de jitter: ~286 ns por muestra.
  • Inyección de jitter: 500–3000 $\mu$s (imperceptible para humanos, 5–27× por debajo de los umbrales de percepción).
  • Verificación de VDF: ~50 ms (proceso en segundo plano).
  • Adición a MMR: < 1 ms.

5. Significado y Reivindicaciones

El artículo afirma modestamente que Witnessd no evita la falsificación por parte de un adversario suficientemente poderoso (específicamente un adversario a nivel de kernel, $C_3$, presente antes de la captura). Si un adversario controla el kernel, puede extraer el secreto de sesión y falsificar la evidencia.

Sin embargo, la importancia del sistema radica en cambiar la carga de la prueba:

• Convierte el escepticismo vago ("Esto podría haber sido falsificado") en alegaciones falsables ("El kernel fue comprometido mediante el CVE-XXXX durante la ventana 14:00–14:47").
• Establece que la evidencia válida requiere que un humano escriba físicamente el contenido (incluso si el contenido es texto generado por IA). El sistema atestigua el proceso de escritura, no el origen cognitivo de las ideas.
• Al requerir la complicidad coordinada de límites de confianza independientes (hardware, SO, anclajes de terceros), el sistema hace que el costo y la especificidad de un ataque exitoso sean significativamente más altos que la procedencia basada en firmas actual.

Los autores concluyen que, en contextos adversarios, la capacidad de forzar alegaciones específicas y comprobables es una contribución distinta y valiosa, cambiando el paradigma de "detectar falsificaciones" a "colapsar la negación plausible".