En estos momentos, a todos los proveedores de seguridad se les plantea la misma pregunta: si la IA es capaz de escribir código, ¿puede también burlar las medidas de protección? Durante un reciente hackatón interno, Verimatrix decidió dejar de especular y llevar a cabo el experimento. Nos reunimos con el Dr. Klaus Schenk, director técnico de Verimatrix, para hablar de lo que ocurrió cuando su equipo aplicó un modelo de IA de vanguardia a la protección de contenidos del lado del cliente, y de lo que esto les enseñó sobre cómo desarrollar una seguridad resistente a la IA. Principales conclusiones
- La ingeniería inversa asistida por IA funciona, pero solo bajo la supervisión de expertos. Los avances se han logrado gracias a un bucle de corrección adversarial que presupone que la persona que lo maneja ya sabe cómo atacar el sistema.
- No hay atajos para los atacantes sin experiencia. Sin conocimientos sobre el ámbito en cuestión, el resultado es un análisis que parece acertado pero que es erróneo, no una fórmula útil.
- El coste no es el obstáculo; lo es la experiencia. El experimento costó decenas de dólares en el uso del modelo; lo que resultó caro fueron las aproximadamente 25 correcciones realizadas por expertos.
- La IA reduce el tiempo que dedican los expertos, por lo que los diseños de protección deben ser de última generación. Un analista cualificado llega a comprender un sistema más rápidamente gracias a la IA, lo que eleva el listón en cuanto al margen de seguridad que debe tener un diseño.
- Un diseño resistente a la IA implica no dejar ningún vector de ataque conocido que pueda detectarse.
La conclusión no es ni que «la IA no cambia nada» ni que «la IA lo estropea todo», sino que una buena arquitectura de seguridad sigue siendo sólida en una época de IA potente, mientras que una arquitectura débil se verá comprometida más rápidamente.
P: Klaus, ¿por qué se ha llevado a cabo este experimento?
P: ¿Qué le proporcionaste exactamente a la IA?
K: Empezamos dejando que la IA atacara el producto «Trust Tunnel» Counterspynuestro Counterspy, pero, incluso con la orientación de un humano, la IA no encontró vulnerabilidades. Así que redujimos el nivel de seguridad y creamos un esquema de protección del lado del cliente específicamente para el experimento, rebajando deliberadamente la seguridad para ver hasta dónde llegaba la IA.
Para comprender en qué consiste esa reducción de la seguridad, resulta útil saber cómo funciona la concesión de licencias DRM: cuando una aplicación de vídeo quiere reproducir contenido protegido, envía una solicitud de licencia protegida por un token a un servidor y recibe una respuesta de licencia que contiene las claves del contenido protegido que un módulo de acceso condicional (CDM) utiliza para descifrar dicho contenido.
Los vectores de ataque habituales consisten en hacer un uso indebido del token de acceso para permitir que un CDM emulado solicite una respuesta de licencia y, a partir de ahí, desproteja la clave de contenido. En nuestro esquema de pruebas, solo se cifró en exceso la respuesta de licencia. Esto hace que la mera respuesta de licencia cifrada en exceso no sea apta para un ataque con un CDM emulado. Las propias claves cifradas en exceso se gestionaron siguiendo las mejores prácticas en la programación de aplicaciones, incluida la derivación de claves multicomponente, pero sin aplicar el conjunto completo de medidas de protección adicionales.
Sabíamos exactamente en qué puntos habíamos reducido la seguridad, lo que nos permitía evaluar con precisión hasta dónde podía llegar la IA con su análisis, así como cuánta ayuda necesitaba para lograrlo.
P: ¿Cómo preparaste al «atacante»?
K: Proporcionamos al modelo un kit inicial realista que incluía el material que un atacante real recopilaría en primer lugar: el tráfico HTTP capturado entre la aplicación y el servidor de licencias, los paquetes de JavaScript del lado del cliente, una descripción de las vulnerabilidades conocidas y una explicación del flujo básico de datos con vectores de ataque plausibles.
Por lo tanto, el modelo no partió de cero. Empezó exactamente por donde lo haría un atacante humano competente.
P: ¿Y qué pasó realmente?
K: Ocurrieron dos cosas. Y ambas resultaron instructivas. En primer lugar, el modelo se negó rotundamente a intervenir hasta que le proporcionamos una justificación sólida para el trabajo. En nuestro caso, se trataba de una investigación legítima sobre la seguridad de nuestro propio sistema. Una vez que intervino, realizó un análisis estructural realmente útil del cliente y del flujo de datos, y a continuación cometió con total seguridad una serie de errores críticos.
P: ¿Podrías dar un ejemplo de ese tipo de error?
K: El ejemplo más ilustrativo: el modelo tomó un atajo basándose en su propia «experiencia» genérica y supuso que el procesamiento de la respuesta de la licencia debía tener lugar dentro de los hooks de un reproductor multimedia específico, ya que es ahí donde suele ocurrir en los sistemas que ha visto. En nuestro esquema, no fue así.
Esa única suposición errónea provocó una conclusión errónea —el modelo determinó que la respuesta de la licencia no estaba en absoluto sobrecifrada— y llevó todo el análisis a un callejón sin salida. El resultado parecía plausible, se expuso con total seguridad y, sencillamente, era erróneo.
P: ¿Te costó mucho volver a encarrilar el análisis?
K: No se trató de una simple aclaración. Fueron necesarias unas 25 rondas de corrección humana antes de que el modelo identificara el flujo de descifrado real para la respuesta de la licencia. Las aportaciones constructivas a la IA procedieron de dos ingenieros con un total de 35 años de experiencia en hacking ético.
El progreso se logró casi en su totalidad a través de un ciclo de debate —«eso está mal, y este es el motivo» y «¿de verdad funciona así?»— y cada una de esas correcciones requería de una persona que ya supiera cuál era la respuesta correcta. La IA potenciaba el trabajo de un analista experimentado. No lo sustituía.
P: ¿Significa esto que la IA facilita las cosas a los atacantes de los servicios de streaming?
K: Solo dentro de unos límites muy estrechos. El resultado nunca fue una fórmula clara y reproducible. Sin un profundo conocimiento previo del ámbito, un principiante se habría quedado con un análisis que parecía plausible, pero que simplemente era erróneo, y sin forma alguna de darse cuenta. El coste era modesto —unas decenas de dólares por el uso del modelo—, pero la experiencia necesaria no lo era en absoluto.
Lo que sí cambia la IA es la velocidad: reduce considerablemente el tiempo que un ingeniero de ingeniería inversa ya cualificado necesita para comprender un sistema. No pone esa capacidad al alcance de la mayoría de los atacantes ocasionales, ni crea vulnerabilidades donde no las hay.
Sin embargo, resulta sorprendente que el modelo proporcionara más detalles sobre el ataque de los que inicialmente había indicado que ofrecería, basándose principalmente en preguntas como: «¿Entiendo bien que el ataque funciona así y asá?». Pero, una vez más, para obtener estas respuestas era necesario saber cómo atacar al objetivo.
P: Entonces, ¿qué nos dice el experimento sobre la forma correcta de desarrollar una seguridad resistente a la IA?
K: La IA no crea nuevos vectores de ataque. Más bien, bajo la dirección de un atacante experto, puede probar rápidamente ataques conocidos, incluido el análisis del flujo de datos. Una protección bien diseñada sigue siendo eficaz contra todos estos ataques, pero ya no cabe esperar que un atacante equipado con IA no encuentre puntos débiles en poco tiempo.
