- El proyecto de seguridad de hardware del MIT reprodujo un ataque de canal lateral asistido por aprendizaje automático posible desde el navegador web, y al hacerlo dejó al descubierto una trampa: una alta precisión del modelo no demuestra cuál es la causa real
- La investigación previa sobre fingerprinting de sitios web atribuía la causa a la contención de caché de CPU, pero un método que elimina los accesos a la caché y solo incrementa un contador simple logró mayor precisión en varios entornos
- El equipo de investigación fue descartando, en orden, la hipótesis de escalado de frecuencia de CPU, la contención entre núcleos de CPU y la hipótesis de la caché; con instrumentación mediante eBPF confirmó que más del 99% de las pausas de más de 100 ns correspondían al manejo de interrupciones
- Solo con las señales de interrupciones del sistema ya se revelaba la actividad de carga de sitios web, y en Chrome/Linux la precisión para identificar el sitio víctima entre 100 sitios llegó hasta 96.6%
- Para diseñar defensas, primero hace falta un análisis que confirme el mecanismo real del canal lateral, más allá del hecho de que el modelo haya acertado
Cómo comenzó la investigación
- En 2020, en la clase Secure Hardware Design del MIT, comenzó un proyecto para reimplementar un ataque de fingerprinting de sitios web a partir de experiencia en desarrollo web y aprendizaje automático
- Mengjia Yan vio que había algo que no cuadraba en la investigación reciente sobre fingerprinting de sitios web que atacaba debilidades de hardware con aprendizaje automático, y propuso reimplementarla
- El proyecto luego dio lugar al artículo There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
- El artículo ganó el primer lugar en el Intel 2024 Hardware Security Academic Award y fue incluido en IEEE Micro Top Picks de 2023
- La investigación aborda tres ejes: ataques desde el navegador, filtración por interrupciones del sistema y errores de interpretación en aprendizaje automático
Canales laterales y fingerprinting de sitios web
- El aislamiento de procesos separa la memoria y los recursos de las aplicaciones, pero en una computadora real siguen compartiéndose recursos como la tarjeta de red, la GPU y la CPU
- Los recursos compartidos pueden filtrar sin querer información sobre la actividad del usuario
- Si alguien que usa el mismo router Wi‑Fi ve un video pesado, el tiempo de descarga de otro usuario puede volverse más lento
- Los cambios en el consumo eléctrico o las emisiones electromagnéticas también pueden convertirse en canales laterales para inferir claves criptográficas o actividad del usuario
- El fingerprinting de sitios web es un ataque en el que un sitio web atacante en una pestaña intenta identificar el sitio víctima abierto en otra pestaña
- La investigación previa de Shusterman et al. presentó un ataque que usaba la caché de CPU para adivinar cuál sitio estaba abierto entre 100 candidatos
- El atacante crea un arreglo del tamaño de la caché de CPU y lo llena con 1
- Mientras el sitio víctima se carga, mide cada 2 ms el tiempo de acceso al arreglo
- Durante 15 segundos recoge un total de 7,500 mediciones
- Como los scripts, imágenes, hojas de estilo y patrones de renderizado se repiten de forma parecida en cada sitio web, la traza de mediciones puede usarse como una huella
- Se reúnen 100 trazas por cada uno de 100 sitios web para formar un conjunto de datos etiquetado de 10,000 muestras y entrenar un modelo de aprendizaje automático
- Se obtuvo hasta 91.4% de precisión en varios navegadores y sistemas operativos
El ataque del contador sin caché
- En la reimplementación inicial, clasificar 4 sitios web era fácil, y se obtuvo 98% de precisión con un clasificador Random Forest simple
- Cuando el experimento se amplió a 10 sitios web, al principio la precisión fue de 75%, pero luego mejoró hasta abarcar clasificaciones de 10, 50 y 100 sitios
- El cambio decisivo fue eliminar el acceso al arreglo de caché y hacer que el atacante repitiera
value++lo más rápido posible- Si se guarda el valor del contador a intervalos regulares, queda una traza de cuánto pudo ejecutarse la computadora durante ese periodo
- Otras actividades, como redimensionar la ventana del navegador o abrir una pestaña nueva, también se reflejan en la traza del contador
- En el artículo, se guarda el valor cada 5 ms para obtener más información en un tiempo fijo
- El modelo entrenado con trazas del contador mostró mayor precisión al identificar sitios web que el basado en trazas de latencia de caché
- Este resultado hizo dudar de si el ataque previo realmente aprovechaba la contención de caché, y llevó a un análisis para encontrar la causa
La brecha entre la precisión del modelo y el análisis causal
- En los ataques de canal lateral asistidos por aprendizaje automático, que un modelo prediga de forma estable la actividad del usuario solo demuestra la existencia de una señal
- Una alta precisión no prueba de qué canal lateral provino esa señal
- Aunque el modelo de Shusterman et al. acertara el sitio víctima con 91.4% de precisión, eso no significa que hubiera capturado contención de caché de CPU
- Lo que encuentra el modelo son correlaciones, no una explicación de la causa de la señal
- Un análisis causal equivocado puede desviar el diseño de defensas
- Los investigadores diseñan defensas para hacer las computadoras más seguras basándose en artículos sobre ataques
- Si se entiende mal la causa del ataque, puede desperdiciarse tiempo y esfuerzo
Verificación de hipótesis: frecuencia, núcleos e interrupciones
- El equipo comparó el ataque previo basado en caché y el nuevo basado en contador en varios entornos
- En la tarea de identificar 100 sitios web, el ataque basado en contador logró mayor precisión en casi todas las configuraciones experimentales
- En Safari sobre macOS, el ataque de caché alcanzó 72.6% y el de contador 96.6% de precisión
- En la configuración base, identificó la respuesta correcta entre 100 sitios con 95.2% de precisión
-
Hipótesis del escalado de frecuencia de CPU
- Las CPU modernas suben o bajan su frecuencia según la carga de trabajo para ahorrar energía
- Se planteó la hipótesis de que durante la carga del sitio víctima cambiara la frecuencia de CPU y eso alterara el valor del contador
- Después de desactivar el escalado de frecuencia en el BIOS, se recolectaron nuevos datos y se entrenó el modelo
- La precisión solo bajó de 95.2% a 94.2%, una diferencia de 1 punto porcentual, por lo que era difícil explicar la variación del contador por cambios en la frecuencia de CPU
-
Hipótesis de contención entre núcleos de CPU
- Si la pestaña atacante y la víctima se ejecutan en el mismo núcleo de CPU, la carga de la víctima podría reducir el tiempo de ejecución del contador del atacante
- Con
taskseten Linux se fijó al atacante y a la víctima para que corrieran en núcleos distintos - Incluso con el escalado de frecuencia desactivado, la precisión se mantuvo en 94.0%
- La contención entre núcleos tampoco parecía ser la causa principal
-
Hipótesis de interrupciones del sistema
- La siguiente hipótesis fue que las interrupciones del sistema eran la señal del ataque basado en contador
- El sistema operativo usa interrupciones para comunicarse con dispositivos de hardware como teclado, mouse, pantalla y tarjeta de red
- Cuando una interrupción llega a un núcleo de CPU, el programa que se ejecuta en ese núcleo se detiene de inmediato y se ejecuta el manejador de interrupciones
- Mientras el sitio víctima se carga, distintos dispositivos como la red o los gráficos generan interrupciones, y si se procesan en el mismo núcleo que el atacante, el valor del contador del atacante puede bajar
- En Linux, el manejo de interrupciones puede verse con
cat /proc/interrupts
Interrupciones migrables y no migrables
- Linux puede enrutar algunas interrupciones migrables a un núcleo específico
- Aquí entran las interrupciones con identificador numérico
- A menudo provienen de dispositivos de hardware externos como el teclado o la tarjeta de red
- Muchas interrupciones no migrables no pueden aislarse en un núcleo específico
- Aquí entran las interrupciones con identificador de tres letras
- Como se usan para sincronizar actividad entre núcleos de CPU, deben procesarse en todos los núcleos
- En el entorno experimental representaban la mayor parte de la actividad de interrupciones
- Con
irqbalancese enviaron las interrupciones migrables al núcleo 1, y contasksetse hizo que atacante y víctima corrieran en los núcleos 2 y 3 - Con la frecuencia de CPU también fijada, la precisión cayó casi 6 puntos porcentuales, lo que hizo más creíble la hipótesis de las interrupciones
La causa real confirmada con eBPF
- Como no era posible, por la estructura del sistema operativo, hacer un experimento que aislara por completo incluso las interrupciones no migrables, se instrumentó la ejecución con eBPF
- Con eBPF se registraron dos tipos de momentos
- Cuándo el programa atacante comenzaba y se detenía
- Cuándo el manejador de interrupciones comenzaba y se detenía
- Como la frecuencia de CPU estaba fijada, si el atacante no sufría interferencia debería ejecutar casi la misma cantidad de instrucciones en un tiempo fijo
- Con el código eBPF escrito por Jonathan Behrens se compararon los intervalos en que el atacante se detenía con los intervalos de procesamiento de interrupciones
- Se confirmó que más del 99% de las pausas en la ejecución del atacante que duraban más de 100 ns correspondían a tiempo de procesamiento de interrupciones
- En la práctica, el núcleo de CPU del atacante estaba haciendo una de dos cosas: ejecutar el código de conteo o procesar interrupciones; cuando el tiempo de interrupciones bajaba, el valor del contador subía, y cuando aumentaba, bajaba
Los dos resultados principales del artículo
- El primer resultado es que las interrupciones del sistema filtran actividad del usuario
- Las propiedades de seguridad de las interrupciones del sistema no se habían estudiado en la literatura previa
- El equipo analizó por primera vez un canal lateral basado en interrupciones del sistema
- El segundo resultado es que los ataques de canal lateral asistidos por aprendizaje automático deben analizarse con cuidado
- Los modelos de aprendizaje automático pueden producir ataques potentes incluso sin entender el canal lateral
- Sin instrumentar el sistema operativo, no habría sido posible concluir qué canal lateral se estaba usando
- Las defensas previas contra ataques basados en caché consistían en expulsar repetidamente la caché de CPU para introducir ruido
- Una defensa que genera muchas interrupciones, por ejemplo enviando solicitudes de red a una dirección IP local, funcionó mejor tanto contra el ataque basado en caché como contra el basado en contador
- Esta comparación refuerza la evidencia de que el ataque de Shusterman et al. aprovechaba sobre todo señales de interrupciones y no de caché
Experimentos adicionales y posibilidades de defensa
- El artículo también incluye resultados adicionales
- Propone una forma de mitigar por completo el ataque modificando el reloj del navegador que se ofrece a JavaScript
- Realiza un experimento de aislamiento poniendo al atacante y a la víctima en máquinas virtuales separadas
- Analiza la frecuencia y el tiempo de procesamiento de varias interrupciones no migrables
- Los navegadores reducen la precisión del reloj disponible para JavaScript para dificultar ataques basados en temporización de alta precisión
- Chrome redondea a 0.1 ms y agrega ruido aleatorio
- Firefox y Safari redondean a 1 ms
- Tor Browser redondea a 100 ms y baja la precisión del ataque de 96.6% en Chrome a 49.8%
- Reducir la precisión del reloj tiene trade-offs
- Los motores de juegos en el navegador necesitan temporizadores de alta precisión para renderizado y animación
- A la mayoría de usuarios de Tor Browser les resulta difícil jugar la mayoría de juegos, pero para usuarios que priorizan la seguridad eso quizá no sea un problema
Preguntas de investigación que siguen abiertas
- Las interrupciones del sistema están conectadas con mecanismos de hardware profundos de las computadoras modernas, como Spectre y Meltdown
- Hoy no se puede implementar una defensa que aísle las interrupciones no migrables del atacante, y no está claro cómo habría que rediseñar las computadoras para hacerlo posible
- Tampoco se entiende bien la relación entre la actividad de un sitio web y las interrupciones
- weather.com provocaba muchas rescheduling interrupt, pero nytimes.com y amazon.com no
- No se analizó cómo afectan a la traza del contador las imágenes adicionales, anuncios y scripts
- El ataque podría volverse más fuerte
- El artículo se parece más a un “artículo de análisis” que a un “artículo de ataque”
- El 96.6% de precisión obtenido en Chrome/Linux podría no ser un techo sino un piso
- Sigue abierta la posibilidad de aplicarlo con mejores modelos u otras metodologías a tareas como clasificar 1,000 sitios web, detectar si alguien está viendo una película, si usa VPN o con qué frecuencia revisa Robinhood
- Las defensas desde el navegador también deben implementarse en navegadores reales y evaluarse para ver si son prácticas para usuarios comunes
El impacto del proyecto en la trayectoria personal
- Antes de este proyecto, cursar un posgrado no era una opción seria, y después de una pasantía de investigación en deep learning en NVIDIA se pensaba más bien en trabajar en una gran tecnológica o en una startup de IA
- Después del proyecto quedó la experiencia de que investigar puede ser divertido y hermoso
- Tras graduarse del MIT, continuó un año más en el programa MEng de ciencias de la computación y luego estudió dos años en la University of Oxford con una Rhodes scholarship
- El próximo año comenzará un PhD de seis años en ciencias de la computación en MIT
1 comentarios
Comentarios de Hacker News
Buen artículo, y la investigación detrás también está prolija.
Creo que el aporte del paper en realidad no tiene mucho que ver con el machine learning, sino con haber encontrado un nuevo canal lateral usando interrupciones.
Aquí el machine learning más bien cumple el rol de atraer más lectores; probablemente no habría habido mucha diferencia si lo hubieran llamado “estadística”.
Me recuerda a algo que decía mi antiguo asesor: “cuando entiendas de qué trata realmente tu paper, reescríbelo y quítale las partes que antes pensabas que eran el tema”.
Creo que el título de este paper debería haberse enfocado en el nuevo canal lateral más que en la historia de machine learning. Aun así, es una objeción menor; es un trabajo excelente.
El hallazgo sobre el malentendido del machine learning es especialmente importante porque pone en duda buena parte de la investigación en arquitectura de computadoras existente.
Antes, para realizar este tipo de ataques había que entender a fondo el canal lateral que se estaba explotando, pero los modelos de machine learning —en este caso, un LSTM— permiten una precisión mucho mayor que la simple “estadística”, y facilitan crear ataques potentes que explotan canales laterales mal comprendidos.
Hoy existen bastantes ataques asistidos por machine learning construidos de esta manera, y solo el paper de Shusterman et al. recibió casi 200 citas, una cifra enorme para un paper de arquitectura de computadoras.
El objetivo de publicar este tipo de investigación es entender mejor los sistemas para crear defensas más sólidas, y el costo de entender mal el problema y desorientar a la comunidad es alto.
Esto seguiría siendo cierto aunque se hubiera descubierto que la causa del ataque anterior era, al final, la caché; pero el hecho de haber encontrado un nuevo canal lateral en el proceso hizo que el mensaje quedara mucho más claro. El post del blog podría haber enfatizado más esta parte.
En la práctica, cuando uno se pierde en un mar de datos, este sentido común puede desaparecer entre una avalancha de correlaciones, pero un buen diseño experimental y la revisión por pares deberían filtrar conclusiones e interpretaciones débiles.
En ese sentido, este estudio de reproducción hizo un trabajo excelente.
Excelente artículo. No pensé que un ataque de canal lateral pudiera explicarse de forma tan fácil de entender.
Se leyó como una novela de misterio de asesinato en la que desde el principio sabes quién es el villano, pero vas descubriendo “cómo lo hizo”.
Lo guardé en favoritos.
Pero gracias a esta reacción lo leí, y de verdad estuvo muy bueno.
Me sorprendió la parte que dice: “El próximo año volveré al MIT para empezar un doctorado de seis años en ciencias de la computación. ¡No podría estar más emocionado!”.
Es impresionante que todo empezara con una idea afortunada del autor: probar algo al azar, como usar contadores, en vez del ataque de expulsión de caché mucho más sofisticado del ataque de canal lateral original, y que eso funcionara gracias a conceptos que en ese momento no conocía.
Probablemente yo fui una de esas miles de personas que no tuvieron esa suerte, así que abandoné pronto la idea de quedarme en la academia y me fui a la industria, donde hice una carrera bastante normal.
Empecé un Honours Degree australiano en ciencias de la computación, algo parecido a una maestría, y alrededor de 2010, mucho antes del auge actual de la IA, quería escribir un paper de inteligencia artificial basado en casos de aplicación que había aprendido en una materia formal de IA.
Quería partir de cómo las bodegas usaban IA para mejorar la calidad y la producción del vino y aplicarlo a usos más “generales”, pero el asesor que me asignaron no tenía ningún interés en ayudarme y no había otro apoyo, así que se volvió difícil continuar.
Además, tenía una oferta de trabajo de tiempo completo con un sueldo bastante bueno, y aun si hubiera seguido, probablemente no habría logrado gran cosa.
Como dice el autor, las cosas salieron adelante gracias al asesor y al apoyo de su entorno; hacerlo solo requiere un impulso y un talento enormes, y creo que a mí me faltaban ambas cosas.
Durante mi primer doctorado en Japón, durante tres años mi profesor y la gente a mi alrededor solo criticaban todo lo que proponía, sin aportar ideas viables.
Al profesor del laboratorio de al lado le gustaba mi investigación, pero me enteré demasiado tarde como para cambiarme de laboratorio.
Ahora estoy en un lugar donde puedo trabajar con la mitad de las personas del país —es decir, dos en total— que entienden completamente mi otro proyecto y se preocupan por él, y sus datos ya han mejorado el proyecto.
Al director también le caigo bien, así que me incluye en las actividades del laboratorio aunque no tenga una afiliación oficial.
En un entorno así sí puedo tener éxito. Encontrar el entorno y la gente adecuados es difícil, pero es decisivo; de lo contrario, incluso un trabajo muy bueno puede terminar siendo esfuerzo desperdiciado.
El artículo estuvo bueno.
Como queja muy menor sobre la página, el estilo de separador con puntos grandes en fila me confundió porque parecía un indicador de posición de un carrusel de imágenes.
El artículo es excelente, la explicación es muy accesible y la demo interactiva también está muy buena.
También me gustó que contaran el contexto de cómo terminaron empezando este trabajo.
Muy interesante y bien explicado. Si la investigación salió hace dos años, los recolectores de datos interesados seguramente ya la tuvieron en cuenta.
Olvídense de los hackers. Esto es un exploit para empresas y gobiernos.
¿Un sitio web que prioriza la privacidad podría distribuir un paquete que genere interrupciones aleatorias? ¿Una extensión de navegador podría hacer eso para todos los sitios?
Nuestra contramedida que genera interrupciones aleatorias está implementada como una extensión de navegador, y el código fuente está aquí: https://github.com/jackcook/bigger-fish
Dicho eso, no recomendaría usarla a diario. En las pruebas, si mal no recuerdo, los tiempos de carga de las páginas se ralentizaron alrededor de un 10%.
Algunas sí cambiaron bastante cuando la computadora estaba bajo mucha carga, pero parece posible que Safari ya incluya algunas mitigaciones.
Aun así, el paper es realmente genial.