Amenazas de ciberseguridad en los Endpoints de sistemas de Inteligencia Artificial (IA)

Dado que los Endpoints de IA (o TinyML) se encuentran en las etapas iniciales y la industria la adopta lentamente, más empresas están incorporando IA en sus sistemas, como para el mantenimiento predictivo en fábricas o la detección de palabras clave en productos electrónicos de consumo. Pero con la adición de un componente de IA en su sistema IoT, se deben considerar nuevas medidas de seguridad. IoT ha madurado hasta el punto en que puede lanzar productos de manera fiable en campo con tranquilidad, con certificaciones como PSA Certified ™ que brindan la garantía de que su IP puede protegerse a través de una variedad de técnicas como motores de seguridad aislados, clave criptográfica segura almacenamiento y uso de Arm® TrustZone®. Dichas garantías se pueden encontrar en los microcontroladores (MCU) diseñados teniendo en cuenta la seguridad con características de seguridad escalables basadas en hardware, como la familia RA de Renesas. Sin embargo, la incorporación de la IA conduce a la introducción de nuevas amenazas que se infestan en áreas seguras, concretamente en forma de ataques de adversarios.

Los ataques de adversarios apuntan a la complejidad de los modelos de aprendizaje profundo y las matemáticas estadísticas subyacentes para crear debilidades y explotarlas en el campo, lo que lleva a que se filtren partes del modelo, se filtren datos de entrenamiento o se generen resultados inesperados. Esto se debe a la naturaleza de caja negra de las redes neuronales profundas (DNN), donde la toma de decisiones en las DNN no es transparente, es decir, «capas ocultas» y los clientes no están dispuestos a arriesgar sus sistemas al agregar una función de IA, lo que ralentiza la proliferación de Endpoints. Los ataques de adversarios son diferentes a los ataques cibernéticos convencionales, ya que en las amenazas de seguridad cibernética tradicionales, los analistas de seguridad pueden corregir el error en el código fuente y documentarlo ampliamente. Dado que en los DNN no hay una línea específica de códigos que pueda abordar, se vuelve comprensiblemente difícil.

Los ataques adversarios en la cultura pop se pueden ver en Star Wars. Durante las guerras de los clones, la Orden 66 puede verse como un ataque adversario en el que los clones se comportaron como se esperaba durante la guerra, pero una vez que se les dio la orden, cambiaron, lo que provocó una marea en la guerra.

Se pueden encontrar ejemplos notables en muchas aplicaciones, como un equipo de investigadores que pega pegatinas en las señales de stop, lo que hace que la IA lo prediga como una señal de velocidad [1]. Tal clasificación errónea puede provocar accidentes de tráfico y una mayor desconfianza pública en el uso de IA en los sistemas. Los investigadores lograron obtener un 100 % de errores de clasificación en un entorno de laboratorio y un 84,8 % en pruebas de campo, lo que demuestra que las pegatinas eran bastante efectivas. Los algoritmos engañados se basaron en redes neuronales de convolución (CNN), por lo que se puede extender a otros casos de uso utilizando CNN como base, como la detección de objetos y la detección de palabras clave.

Otro ejemplo de investigadores de la Universidad de California, Berkley, mostró que, al agregar ruido o perturbación a cualquier música o discurso, el modelo de IA lo malinterpretaría como algo diferente a la música reproducida o transcribiría algo completamente diferente, pero esa perturbación es inaudible para el oído humano [2]. Esto se puede usar maliciosamente en asistentes inteligentes o servicios de transcripción de IA. Los investigadores han reproducido la forma de onda de audio que es más del 99,9 % similar al archivo de audio original, pero pueden transcribir cualquier archivo de audio de su elección con una tasa de éxito del 100 % en el algoritmo DeepSpeech de Mozilla.

Tipos de ataques adversarios

Para comprender los muchos tipos de ataques adversarios, se debe observar la canalización de desarrollo convencional de TinyML, como se muestra en la figura 3. Donde inicialmente, el entrenamiento se realiza fuera de línea, generalmente en la nube, seguido por el ejecutable binario pulido final que se muestra en la MCU y utilizado a través de llamadas a la API. El flujo de trabajo requiere un ingeniero de aprendizaje automático y un ingeniero integrado. Dado que esos ingenieros tienden a trabajar en equipos separados, el nuevo panorama de seguridad puede generar confusión sobre la división de responsabilidades entre las distintas partes interesadas.

Los ataques adversarios pueden ocurrir en las fases de entrenamiento o inferencia. Durante el entrenamiento, un atacante malintencionado podría intentar el «envenenamiento de modelos», que puede ser de tipo dirigido o no dirigido. En el envenenamiento de modelos dirigidos, un atacante contaminaría el conjunto de datos de entrenamiento/modelo base de IA, lo que daría como resultado una «puerta trasera» que puede activarse mediante una entrada arbitraria para obtener una salida particular, pero que funciona correctamente con las entradas esperadas. La contaminación podría ser una pequeña perturbación que no afecta la operación esperada (como la precisión del modelo, las velocidades de inferencia, etc.) del modelo y daría la impresión de que no hay problemas. Esto tampoco requiere que el atacante tome e implemente un clon del sistema de entrenamiento para verificar la operación, ya que el sistema en sí estaba contaminado y afectaría de manera ubicua a cualquier sistema que use el modelo/conjunto de datos envenenado. Este fue el ataque utilizado contra los clones en Star Wars.

El envenenamiento de modelos sin objetivo o los ataques bizantinos se producen cuando el atacante tiene la intención de reducir el rendimiento (precisión) del modelo y estanca el entrenamiento. Esto requeriría volver a un punto antes de que el modelo/conjunto de datos se haya visto comprometido (potencialmente desde el principio).

Además del entrenamiento fuera de línea, el aprendizaje federado, una técnica en la que los datos recopilados de los puntos finales se utilizan para volver a entrenar/mejorar el modelo de nube, es intrínsecamente vulnerable debido a su naturaleza descentralizada de procesamiento, lo que permite a los atacantes participar con dispositivos de punto final comprometidos que conducen a la nube. el modelo se ve comprometido. Esto podría tener grandes implicaciones, ya que ese mismo modelo de nube podría usarse en millones de dispositivos.

Durante la fase de inferencia, un pirata informático puede optar por la técnica de «evasión del modelo», en la que consulta interactivamente el modelo (por ejemplo, una imagen) y agrega algo de ruido a la entrada para comprender cómo se comporta el modelo. De tal manera, el pirata informático podría obtener potencialmente un resultado específico/requerido, es decir, una decisión lógica después de ajustar su entrada suficientes veces sin usar la entrada esperada. Dicha consulta también podría usarse para la «inversión del modelo», donde la información sobre el modelo o los datos de entrenamiento se extraen de manera similar.

Análisis de riesgos durante su desarrollo AI TinyML

Para la fase de inferencia, los ataques adversarios en modelos de IA son un campo activo de investigación, donde la academia y la industria se han alineado para trabajar en esos temas y desarrollaron «ATLAS – Adversarial Threat Landscape for Artificial-Intelligence Systems!», que es una matriz que permitir que los analistas de ciberseguridad evalúen el riesgo de sus modelos. También consta de casos de uso en toda la industria, incluida la inteligencia artificial perimetral. Aprender de los estudios de casos proporcionados proporcionará a los desarrolladores/propietarios de productos una comprensión de cómo afectaría su caso de uso, evaluará los riesgos y tomará medidas de seguridad de precaución adicionales para aliviar las preocupaciones de los clientes. Los modelos de IA deben verse como propensos a tales ataques y varias partes interesadas deben realizar una evaluación cuidadosa del riesgo.

Para la fase de capacitación, garantizar que los conjuntos de datos y los modelos provengan de fuentes confiables mitigaría el riesgo de envenenamiento de datos/modelos. Dichos modelos/datos generalmente deben ser proporcionados por proveedores de software fiables. Un modelo ML también se puede entrenar teniendo en cuenta la seguridad, lo que hace que el modelo sea más robusto, como un enfoque de fuerza bruta de entrenamiento contradictorio donde el modelo se entrena en muchos ejemplos contradictorios y aprende a defenderse de ellos. Cleverhans, una biblioteca de capacitación de código abierto que se utiliza para construir tales ejemplos para atacar, defender y comparar un modelo para ataques adversarios, se ha desarrollado y utilizado en el mundo académico. La destilación de defensa es otro método en el que se entrena un modelo a partir de un modelo más grande para generar probabilidades de diferentes clases en lugar de decisiones difíciles que dificultan que el adversario explote el modelo. Sin embargo, ambos métodos se pueden desglosar con suficiente potencia computacional.

Mantén segura la propiedad intelectual de tu IA

A veces, las empresas se preocupan por las intenciones maliciosas de los competidores de robar la característica/IP del modelo que está almacenada en un dispositivo en el que la empresa ha gastado el presupuesto de I+D. Una vez que el modelo está entrenado y pulido, se convierte en un ejecutable binario almacenado en la MCU y puede protegerse con las medidas de seguridad convencionales de IoT, como la protección de las interfaces físicas del chip, el cifrado del software y el uso de TrustZone. Sin embargo, una cosa importante a tener en cuenta, incluso si el ejecutable binario fuera robado, es solo el modelo pulido final que está diseñado para un caso de uso específico que puede identificarse fácilmente como una violación de derechos de autor, y la ingeniería inversa requeriría más esfuerzo que comenzando con un modelo base desde cero.

Además, en el desarrollo de TinyML, los modelos de IA tienden a ser conocidos y de código abierto, como MobileNet, que luego se pueden optimizar a través de una variedad de hiperparámetros. Los conjuntos de datos, por otro lado, se mantienen seguros, ya que son tesoros valiosos en los que las empresas gastan recursos para adquirirlos y son específicos para un caso de uso determinado. Por ejemplo, agregar cuadros delimitadores a las regiones de interés en las imágenes. Los conjuntos de datos generalizados también están disponibles como código abierto, como CIFAR, ImageNet, etc. Son buenos para comparar diferentes modelos, pero los conjuntos de datos personalizados deben usarse para el desarrollo de casos de uso específicos. Por ejemplo, para una palabra de activación visual en un entorno de oficina, un conjunto de datos aislado en un entorno de oficina daría el resultado óptimo.

Resumen

Como TinyML sigue creciendo, es bueno estar al tanto de varios ataques que pueden ocurrir en modelos de IA, cómo podrían afectar su desarrollo de TinyML y casos de uso específicos. Los modelos de ML ahora han alcanzado una alta precisión, pero para la implementación, es importante asegurarse de que sus modelos también sean sólidos. Durante el desarrollo, ambas partes (ingenieros de ML e ingenieros integrados) comparten la responsabilidad de los asuntos de ciberseguridad, incluida la IA. Donde los ingenieros de ML se concentrarían en los ataques durante el entrenamiento y los ingenieros integrados garantizarían la protección contra los ataques de inferencia.

Para el modelo de propiedad intelectual (IP),  un elemento crucial es garantizar que los conjuntos de datos de entrenamiento se mantengan seguros para evitar que los competidores puedan desarrollar modelos similares para casos de uso similares. En cuanto al binario ejecutable, es decir, el modelo de IP en el dispositivo, se puede proteger con las mejores medidas de seguridad de IoT de su clase por las que la familia RA de Renesas es reconocida, lo que hace que sea muy difícil acceder a información segura de forma maliciosa.