Avances en Técnicas de Ataque de Aprendizaje Automático

Esta sección proporciona información sobre el sistema que usamos en nuestros experimentos. El sistema tiene las siguientes características:

• Configuración del Procesador: Usamos un procesador X86 que corre a 2GHz.
• Tamaño de Caché: El sistema tiene cachés de instrucciones y datos L1, cada una de 1KB de tamaño con un tamaño de bloque de 64B.
• Protocolo de Coherencia: Usamos un protocolo llamado MI para gestionar la consistencia de datos.
• Topología: La configuración tiene una disposición en malla de 8x8.
• Tasa de Chaffing: Establecimos esta tasa en 50%.
• Tasa de Adición de Retrasos: Esta tasa también se establece en 50%.

#Configuración Experimental

Modelamos nuestro ataque basado en aprendizaje automático y sus contramedidas usando una herramienta llamada Gem5, que simula sistemas multicore. Para el aspecto de red, empleamos Garnet 2.0 para entender mejor la interconexión. Nuestro sistema tiene 64 núcleos, y las configuraciones detalladas se describen en una tabla (no incluida aquí).

Usamos una aplicación de referencia llamada Splash-2 así como múltiples patrones de Tráfico Sintético para la evaluación. El modelo de aprendizaje automático se construyó con la biblioteca Pytorch. Para comprobar cómo se desempeña nuestro método en comparación con un método existente llamado ARNoC, implementamos ambos en Verilog y usamos Synopsys Design Compiler para la síntesis. Primero, presentamos los resultados de un ataque a ARNoC, y después, mostramos cuán efectivas son nuestras contramedidas.

#Recolección de Datos

Esta sección explica cómo recopilamos datos en Gem5 para entrenar nuestra red neuronal profunda (DNN). Aunque tanto el tráfico sintético como los benchmarks reales siguen una estructura similar, tienen diferencias inherentes que nos llevaron a dos métodos de recolección de datos.

#Tráfico Sintético

Recopilamos datos usando un patrón de tráfico sintético Uniforme-Aleatorio con cambios específicos. Todos los IPs de origen envían paquetes a destinos aleatorios, excepto por dos IPs designadas que se comunican como un par correlacionado. De todos los paquetes enviados desde el IP de origen, un porcentaje específico va al IP de destino, mientras que el resto se dirige a otros nodos. Por ejemplo, si el 80% va al IP principal y el 20% va a otros lugares, el último grupo actúa como ruido en la comunicación.

Para hacer que nuestro conjunto de datos sea más variado, realizamos experimentos cubriendo varios mapeos de pares correlacionados a nodos de red, resultando en muchas configuraciones. Observamos cuatro porcentajes diferentes para el flujo de comunicación principal siendo 95%, 90%, 85% y 80%, los cuales contribuyeron a diferentes niveles de ruido.

Nuestro conjunto de datos completo para un porcentaje específico consiste en pares de flujo tanto correlacionados como no correlacionados. Nos aseguramos durante la recolección de datos de mantener una distribución uniforme al ofuscar el tráfico. Variamos los retrasos añadidos a los paquetes para evitar comprometer el rendimiento.

Se recopilaron tres categorías de conjuntos de datos: uno solo con chaffing, uno solo con retrasos aleatorios, y una combinación de ambos.

#Tráfico Real

También se recopilaron datos de cinco pares de aplicaciones de referencia Splash-2 usando dos procesadores. Las aplicaciones de referencia incluyeron fft, fmm, lu, barnes y radix. Los controladores de memoria atendieron solicitudes, y cada par de benchmarks fue lo suficientemente distinto como para contribuir a un conjunto de datos más universal.

Al igual que con el tráfico sintético, examinamos diferentes niveles de ruido y creamos numerosas configuraciones para pares correlacionados. Nuestros conjuntos de datos completos para los pares de benchmarks seleccionados consistieron en ambos tipos de pares de flujo, y recopilamos datos ofuscados de manera similar.

#Ajuste de hiperparámetros

Los hiperparámetros se ajustan antes de que comience el entrenamiento para lograr una precisión óptima en el conjunto de datos.

En el ajuste, se probaron diferentes combinaciones para mejorar la tasa de éxito del ataque. Realizamos el proceso de entrenamiento durante diez épocas, manteniendo una tasa de aprendizaje de 0.0001. Se aplicó normalización por lotes, y establecimos un tamaño de lote de 10. Para las capas de convolución, se eligieron tamaños específicos, y las capas completamente conectadas se ajustaron en consecuencia.

El ajuste presentó desafíos, ya que encontrar el equilibrio adecuado entre costo y efectividad fue crucial. Ajustamos la tasa de aprendizaje para evitar mínimos locales, redujimos las épocas de entrenamiento para evadir el sobreajuste, y disminuimos el tamaño del lote para mejorar la estabilidad. Cada capa fue elegida cuidadosamente según sus funciones, asegurando una extracción de características eficiente.

#Entrenamiento y Prueba

El conjunto de datos total se dividió aleatoriamente en un conjunto de entrenamiento y un conjunto de prueba en una proporción de 2:1. Los pares de flujo fueron etiquetados como correlacionados o no correlacionados. Usamos cuatro métricas de evaluación para medir el rendimiento.

Se calculó la puntuación F1 para medir el equilibrio entre precisión y recuperación, que son esenciales para entender el rendimiento del modelo, especialmente con conjuntos de datos desbalanceados.

Con el objetivo de identificar pares correlacionados, las métricas indicaron aspectos significativos de la metodología de ataque. La meta era minimizar la pérdida de oportunidades para ataques debido a falsos negativos, priorizando la recuperación como la métrica crucial.

#Ataque Basado en ML en Tráfico Sintético

Evaluamos nuestro ataque a través de las cuatro distribuciones de tráfico. Se mantuvo una tasa de inyección de tráfico constante y un tamaño específico de matriz IFD. Los resultados mostraron que todas las distribuciones mostraron números sólidos, aunque el rendimiento disminuyó ligeramente con menos concentración en los flujos principales.

Incluso con ruido añadido, nuestro modelo identificó con éxito tanto flujos correlacionados como no correlacionados, demostrando su viabilidad incluso en condiciones difíciles. Las métricas reflejaron un buen rendimiento, destacando la capacidad del modelo en condiciones de ruido variables.

#Estabilidad del Ataque Basado en ML en Tráfico Sintético

Más evaluaciones se centraron en variar parámetros clave para probar la estabilidad de nuestro ataque. Exploramos cambios en las tasas de inyección de tráfico, revelando una ligera disminución en las métricas de rendimiento con tasas crecientes, indicando impactos de congestión.

Al variar el tamaño de la matriz IFD, los resultados mostraron mejoras en precisión hasta cierto punto, después del cual se estableció estabilidad. También un tamaño de red más grande presentó desafíos, aunque nuestro modelo mantuvo métricas de rendimiento sólidas en diferentes configuraciones.

#Ataque Basado en ML en Benchmarks Reales

Se utilizaron dos técnicas para entrenar y probar modelos en tráfico real. Fusionar conjuntos de datos de múltiples benchmarks llevó a un fuerte rendimiento en todas las evaluaciones. Se notó un ligero descenso en las métricas con más ruido, pero los resultados generales fueron prometedores.

Las comparaciones directas entre tráfico real y sintético destacaron la robustez de nuestro ataque utilizando datos del mundo real. La aleatoriedad en el tráfico sintético complicó la detección de correlaciones, mientras que el tráfico real ofreció patrones más definidos.

El segundo enfoque se centró en pares de benchmarks individuales, mostrando tendencias similares en efectividad, aunque pares específicos con menor conteo de instrucciones mostraron un rendimiento ligeramente peor.

#Robustez de la Contramedida Propuesta

Evaluamos nuestra contramedida usando varias configuraciones para medir su efectividad contra ataques en tráfico sintético y real. Usar chaffing, retrasos y combinaciones de ambos métodos nos permitió identificar la efectividad de estas estrategias.

Los resultados indicaron una caída en el rendimiento cuando el modelo se encontró con datos ofuscados, mostrando que nuestras defensas eran sustanciales. Específicamente, la combinación de técnicas no dio mejoras significativas, sugiriendo que el chaffing funcionó de manera efectiva por sí solo.

A través de varias evaluaciones, nuestra contramedida demostró resistencia contra el ataque basado en ML, reduciendo significativamente las oportunidades para que los atacantes tuvieran éxito.

#Sobrecarga de la Contramedida Propuesta

Analizamos la latencia promedio de paquetes y los tiempos de ejecución para nuestra contramedida, concluyendo que nuestro enfoque ofreció una solución ligera.

Al comparar el área y la sobrecarga de potencia contra ARNoC, los resultados mostraron aumentos mínimos, indicando que nuestro método sigue siendo eficiente mientras ofrece una mayor seguridad. En general, los compromisos por mejorar la anonimidad y estabilizar el rendimiento contra ataques de aprendizaje automático justificaron los pequeños costos de sobrecarga.