Half-Moon Cookie: Private, Similarity-Based Blocklisting with TOCTOU-Attack Resilience

Resumen Técnico: Half-Moon Cookie

1. El Problema

El bloqueo de contenido malicioso (blocklisting) es fundamental en ciberseguridad, pero las infraestructuras convencionales presentan dos limitaciones críticas:

1. Privacidad: Los métodos tradicionales requieren que el cliente revele su consulta (el archivo o contenido) al servidor, o que el servidor haga pública su lista de bloqueo. Esto es inaceptable cuando tanto el contenido del cliente (ej. código propietario) como la lista de bloqueo del servidor (ej. firmas de malware) son privados.
2. Vulnerabilidades TOCTOU (Time-of-Check vs. Time-of-Use): Verificar un archivo contra una lista de bloqueo justo antes de su uso es costoso en términos de latencia y recursos. Si se realiza la verificación antes (fuera de la ruta crítica), surge el riesgo de que el archivo sea modificado o que la lista de bloqueo se actualice entre el momento de la verificación y el uso, permitiendo que contenido malicioso eluda la detección.

El objetivo es permitir que un cliente verifique si su contenido es "similar" a elementos maliciosos en una lista privada, sin revelar el contenido al servidor ni la lista al cliente, y hacerlo de manera eficiente para múltiples receptores, mitigando los ataques TOCTOU.

2. Metodología: El Marco Half-Moon Cookie

Los autores proponen un protocolo criptográfico de tres partes (Cliente Emisor $C_{snd}$, Cliente Receptor $C_{rcv}$, Servidor $S$) que se divide en dos fases:

A. Fase de Verificación Explícita (Explicit Check)
Realizada por el cliente emisor antes de distribuir el contenido.

• Objetivo: Determinar si el archivo $w$ está cerca de algún elemento en la lista de bloqueo $U_{blk}$ en un espacio métrico (basado en distancia de Hamming).
• Mecanismo:
  • Embedding (FEM): El cliente y el servidor utilizan un circuito cifrado (Garbled Circuit) reutilizable para calcular una representación (hash) del archivo $w$ en un espacio vectorial $\mathbb{F}^\theta$. Esto asegura que el servidor no vea el archivo original ni la clave de hash, y el cliente no vea la lista. Se utilizan técnicas de Reusable Garbled Circuits (CRGC) para manejar archivos grandes sin que el costo de comunicación escale linealmente con el tamaño del archivo.
  • Test-and-Commit (FTC): Se realiza una intersección de conjuntos privada aproximada (Fuzzy PSI) basada en la distancia de Hamming. Si la distancia es menor que un umbral $T$, el servidor aborta. Si es mayor, el servidor genera un token de ocultación y vinculación ($\gamma$) y lo añade a una lista de permitidos (allowlist).
  • Seguridad: El token $\gamma$ es una combinación lineal que oculta el contenido original pero lo vincula inequívocamente a la verificación exitosa.

B. Fase de Verificación Implícita (Implicit Check)
Realizada por los clientes receptores justo antes de usar el contenido.

• Objetivo: Confirmar rápidamente que el contenido recibido fue previamente verificado explícitamente, sin volver a ejecutar el costoso protocolo de privacidad.
• Mecanismo:
  • El emisor envía el archivo $w$, una máscara $\vec{m}$ y un nonce al receptor.
  • El receptor recalcula localmente los valores derivados de $w$ y envía una solicitud al servidor.
  • El servidor verifica si el token calculado coincide con uno en su lista de permitidos (allowlist).
  • Ventaja: Esta verificación es extremadamente rápida ($O(\theta)$) y no depende del tamaño de la lista de bloqueo, eliminando la latencia de la ruta crítica.

Resiliencia TOCTOU:
El diseño mitiga los ataques TOCTOU de dos formas:

1. Ventana de tiempo reducida: La verificación implícita es tan rápida que la ventana de tiempo para que un atacante modifique el archivo o actualice la lista de bloqueo entre la comprobación y el uso es mínima.
2. Vinculación (Binding): El token $\gamma$ es criptográficamente vinculante. Un atacante no puede tomar un archivo benigno verificado, modificarlo ligeramente para que parezca malicioso (o viceversa), y aún así pasar la verificación implícita, ya que el token no coincidiría.

3. Contribuciones Clave

1. Definición Formal del Primitivo Half-Moon: Un marco que separa la fase de "embedding" (codificación) de la fase de "chequeo", logrando que el costo de rendimiento sea aditivo en lugar de multiplicativo.
2. Protocolos Eficientes para Bloqueo Basado en Similitud: Implementación de verificaciones de proximidad (fuzzy matching) utilizando distancias de Hamming, esenciales para la detección de malware (hashes difusos como TLSH, ssdeep).
3. Optimización con Circuitos Cifrados Reutilizables (CRGC): Se logra desacoplar el costo computacional del tamaño del archivo de entrada, permitiendo el procesamiento de ejecutables grandes sin incurrir en costos prohibitivos de comunicación.
4. Resistencia a TOCTOU sin Terceros de Confianza: Proporciona una solución para evitar ataques de carrera de tiempo sin depender de un tercero de confianza, utilizando criptografía avanzada (OLE, PSI difuso, Random Oracles).
5. Aplicación Práctica en Defensa contra Malware: Demostración de cómo un emisor puede realizar una verificación costosa una vez, permitiendo que múltiples receptores verifiquen la seguridad del archivo de manera eficiente y privada.

4. Resultados Experimentales

Los autores implementaron el sistema en C++ y lo evaluaron en escenarios de detección de malware en adjuntos de correo electrónico:

• Rendimiento de la Verificación Explícita:
  • El uso de Circuitos Cifrados Reutilizables (RGC) redujo el volumen de comunicación en más de dos órdenes de magnitud y el tiempo de respuesta en al menos un orden de magnitud en comparación con circuitos monolíticos tradicionales.
  • Para un archivo de 10 kB y una lista de bloqueo de 100 elementos, el tiempo de respuesta fue de ~19 segundos (escalando a ~250 clientes concurrentes antes de saturar el servidor).
  • La elección del algoritmo de hash difuso es crucial: TLSH mostró el mejor rendimiento general en comparación con ssdeep y sdhash en este contexto.
• Rendimiento de la Verificación Implícita:
  • La verificación implícita es drásticamente más rápida que las alternativas de PSI difuso o exacto.
  • Comparativa: Mientras que un PSI difuso (Chakraborti et al.) tarda ~160 segundos y genera ~34 MB de tráfico, la verificación implícita de Half-Moon tarda 0.19 segundos y genera solo 7.2 KB de tráfico.
  • El costo de la verificación implícita es independiente del tamaño de la lista de bloqueo.

5. Significado e Impacto

El trabajo Half-Moon Cookie representa un avance significativo en la privacidad de la seguridad cibernética:

• Privacidad Equilibrada: Resuelve el dilema de la privacidad en el bloqueo de contenido, permitiendo a las empresas proteger sus listas de amenazas propietarias sin exponer los datos sensibles de sus clientes.
• Escalabilidad: Al mover la carga computacional pesada a una fase previa (emisor) y permitir verificaciones rápidas a los receptores, el sistema escala bien en entornos de distribución masiva (como correos electrónicos o CDNs).
• Seguridad Operativa: Proporciona una defensa práctica contra los ataques TOCTOU, un vector de amenaza común y difícil de mitigar en sistemas distribuidos, sin sacrificar la usabilidad ni la privacidad.
• Viabilidad Práctica: Los resultados demuestran que la criptografía de uso general (como los circuitos cifrados) puede optimizarse para ser práctica en escenarios del mundo real, como la detección de malware en archivos adjuntos, superando las barreras de latencia y ancho de banda que históricamente han limitado su adopción.

En resumen, Half-Moon Cookie ofrece un marco robusto para la verificación de integridad y seguridad de contenido en un entorno de "confianza cero", equilibrando eficiencia, privacidad y resistencia a ataques de tiempo.