El problema fundamental que ABP aborda es cómo permitir que un cliente consulte una base de datos de URLs maliciosas alojada en un servidor, sin que el servidor aprenda qué URL está consultando el cliente. Esto es crítico en el contexto de la mensajería cifrada de extremo a extremo (E2EE), donde la privacidad del contenido del mensaje se extiende a la privacidad de las interacciones con los enlaces compartidos. La necesidad surge de la proliferación de ataques de phishing y malware distribuidos a través de enlaces, incluso en entornos de comunicación supuestamente seguros.
Tradicionalmente, la verificación de enlaces maliciosos implica enviar el enlace a un servicio centralizado, lo que inherentemente filtra información sobre el interés del usuario. ABP busca romper este vínculo entre la consulta y la identidad del usuario o el contenido de la consulta, utilizando técnicas criptográficas avanzadas para lograr un equilibrio entre seguridad, privacidad y eficiencia a escala de hyperscaler. La solución se basa en el principio de Private Information Retrieval (PIR), adaptado para manejar las complejidades de las consultas de prefijos de URL y las limitaciones de rendimiento y escalabilidad de las construcciones criptográficas puras.
Arquitectura del Sistema
La arquitectura de ABP se centra en un protocolo de Private Information Retrieval (PIR) modificado para manejar consultas de prefijos de URL. El sistema consta de un cliente (dispositivo del usuario) y un servidor que mantiene una base de datos de URLs maliciosas. La base de datos del servidor se organiza en 'buckets' mediante un proceso de pre-procesamiento iterativo que genera un 'ruleset'. Este ruleset, que es una serie de reglas de hashing basadas en prefijos de URL, se distribuye a los clientes para equilibrar el tamaño de los buckets y permitir que el cliente derive un identificador de bucket.
Para la consulta, el cliente calcula el identificador del bucket y una serie de elementos ciegos (blinded elements) usando una Oblivious Pseudorandom Function (OPRF) para cada segmento de ruta de la URL. Estos se envían al servidor a través de un proxy de terceros que implementa Oblivious HTTP (OHTTP) para desidentificar la solicitud. El servidor, que ejecuta su lógica dentro de una Confidential Virtual Machine (CVM) protegida por AMD SEV-SNP, descifra el identificador del bucket y utiliza Oblivious RAM (ORAM) para acceder al contenido del bucket sin revelar el patrón de acceso a un observador privilegiado. El servidor devuelve los contenidos del bucket y las respuestas OPRF ciegas al cliente, que luego las descifra y evalúa localmente para determinar si hay una coincidencia con una URL maliciosa. El uso de ORAM y CVMs aborda las preocupaciones sobre la fuga de información a través de patrones de acceso a memoria o a través del propio servidor.
Ciclo de Vida de una Solicitud ABP
- 1 Servidor: Pre-procesamiento Actualiza la base de datos de URLs, calcula ruleset para balancear buckets, c...
- 2 TEE: Generación de Claves Genera par de claves, incrusta clave pública en informe de atestación (AMD SE...
- 3 Cliente: Obtención de Reglas Solicita informe de atestación y ruleset (vía proxy), verifica firmas y almac...
- 4 Cliente: Clic en Enlace Calcula identificador de bucket y OPRF requests (ciegas) para la URL.
- 5 Cliente -> Proxy -> Servidor Envía identificador de bucket cifrado y OPRF requests (ciegas) vía OHTTP.
- 6 Servidor (CVM): Procesamiento Precomputa OPRF responses, descifra bucket ID, usa ORAM para buscar contenido...
- 7 Servidor (CVM) -> Cliente Devuelve OPRF responses y contenido del bucket cifrados con clave pública del...
- 8 Cliente: Verificación Descifra respuesta, completa evaluación OPRF y determina si hay coincidencia ...
| Capa | Tecnología | Justificación |
|---|---|---|
| security | Private Information Retrieval (PIR) | Permite al cliente consultar una base de datos sin revelar la consulta al servidor. |
| security | Oblivious Pseudorandom Function (OPRF) | Permite al cliente obtener la evaluación de una función sin revelar la entrada, y al servidor evaluar sin conocer la entrada del cliente. |
| security | Oblivious RAM (ORAM) | Oculta los patrones de acceso a la memoria del servidor, evitando que un observador privilegiado infiera la consulta del cliente. |
| security | AMD SEV-SNP (Confidential Computing) | Proporciona un entorno de ejecución confiable (CVM) para el código del servidor, protegiendo los datos en uso y la lógica de la aplicación de accesos no autorizados. |
| networking | Oblivious HTTP (OHTTP) | Desidentifica las solicitudes del cliente al servidor mediante un proxy de terceros, ocultando información como la dirección IP del cliente. |
| data-processing | Ruleset (algoritmo propietario) | Algoritmo de pre-procesamiento que balancea los buckets de la base de datos de URLs para optimizar el rendimiento y la privacidad. |
Trade-offs
Ganancias
- ▲ Privacidad del cliente (contenido de la consulta)
- ▲ Seguridad contra enlaces maliciosos
- ▲ Protección contra observadores privilegiados en el servidor
Costes
- ▲ Complejidad del sistema
- ▲ Overhead computacional y de ancho de banda (por padding y ORAM)
- △ Dependencia de hardware específico (TEE)
Fundamentos Teóricos
El concepto central de Private Information Retrieval (PIR) fue introducido por Chor, Goldreich, Kushilevitz y Sudan en su paper de 1995, "Private Information Retrieval". Este trabajo sentó las bases para la capacidad de un cliente de recuperar un elemento de una base de datos de un servidor sin revelar qué elemento se recuperó. La adaptación de PIR para manejar consultas de prefijos, en lugar de coincidencias exactas, es una extensión práctica necesaria para el filtrado de URLs.
La integración de Oblivious Pseudorandom Functions (OPRFs) se basa en trabajos como el de Bellare, Canetti, Krawczyk y Tsudik sobre funciones pseudoaleatorias y sus aplicaciones criptográficas. Las OPRFs permiten que un cliente obtenga la evaluación de una función en una entrada sin revelar la entrada al servidor, y el servidor evalúe la función sin aprender la entrada del cliente. Finalmente, el uso de Oblivious RAM (ORAM) se remonta al trabajo seminal de Goldreich y Ostrovsky en 1987, "Software Protection and Simulation on Oblivious RAMs", que propuso técnicas para ocultar los patrones de acceso a la memoria de un programa, un desafío crítico para la privacidad en entornos donde un atacante podría observar el acceso a la memoria.