Tous les éditeurs de solutions de sécurité se voient actuellement poser la même question : si l’IA est capable d’écrire du code, peut-elle également contourner les mesures de protection ? Lors d’un récent hackathon interne, Verimatrix a décidé de ne plus se contenter de spéculations et de mener l’expérience. Nous avons rencontré le Dr Klaus Schenk, directeur technique de Verimatrix, pour discuter de ce qui s’est passé lorsque son équipe a utilisé un modèle d’IA de pointe pour s’attaquer à la protection de contenu côté client — et de ce que cela leur a appris sur la mise en place d’une sécurité résistante à l’IA. Principaux enseignements
- La rétro-ingénierie assistée par l'IA fonctionne, mais uniquement sous la supervision d'un expert. Les progrès ont été rendus possibles grâce à une boucle de correction antagoniste qui présuppose que la personne aux commandes sait déjà comment attaquer le système.
- Il n'y a pas de raccourci pour les attaquants inexpérimentés. Sans connaissance du domaine, le résultat est une analyse assurée mais erronée, et non une méthode exploitable.
- Ce n'est pas le coût qui constitue un obstacle, mais l'expertise. L'expérience a coûté quelques dizaines de dollars en frais d'utilisation du modèle ; ce sont les quelque 25 corrections apportées par des experts qui ont représenté le plus gros poste de dépenses.
- L'IA réduit le temps de travail des experts ; les conceptions de protection doivent donc être à la pointe de la technologie. Grâce à l’IA, un analyste expérimenté parvient plus rapidement à comprendre un système, ce qui augmente les exigences en matière de marge de manœuvre dont doit disposer une conception.
- Une conception résistante à l'IA consiste à ne laisser aucun vecteur d'attaque connu à découvrir.
La conclusion n'est ni que « l'IA ne change rien », ni que « l'IA détruit tout » : c'est qu'une architecture de sécurité de qualité reste solide face à une IA puissante, tandis qu'une architecture faible sera mise à mal plus rapidement.
Q : Klaus, pourquoi mener cette expérience ?
Q : Qu'avez-vous exactement présenté à l'IA ?
K : Nous avons commencé par laisser l’IA s’attaquer au produit « Trust Tunnel » Counterspynotre Counterspy, mais même avec l’aide d’un humain, l’IA n’a pas trouvé de failles. Nous avons donc abaissé le niveau de sécurité et mis en place un système de protection côté client spécialement conçu pour l’expérience — en réduisant délibérément la sécurité pour voir jusqu’où l’IA pourrait aller.
Pour comprendre d'où provient cette faille de sécurité, il est utile de savoir comment fonctionne l'octroi de licences DRM : lorsqu'une application vidéo souhaite lire un contenu protégé, elle envoie à un serveur une demande de licence protégée par un jeton et reçoit en retour une réponse contenant les clés du contenu protégé, que le module d'accès conditionnel (CDM) utilise pour déchiffrer ce contenu.
Les vecteurs d’attaque courants consistent à exploiter le jeton d’accès pour permettre à un CDM émulé de demander une réponse de licence et d’en extraire la clé de contenu. Dans notre scénario de test, seule la réponse de licence a fait l’objet d’un surchiffrement. Cela rend la réponse de licence surchiffrée inutilisable pour une attaque impliquant un CDM émulé. Les clés surchiffrées elles-mêmes ont été gérées conformément aux meilleures pratiques de codage d’applications, notamment la dérivation de clés à plusieurs composants, mais sans recourir à l’ensemble des mesures de protection supplémentaires.
Nous savions exactement où nous avions réduit le niveau de sécurité, ce qui nous a permis d'évaluer avec précision jusqu'où l'IA pouvait aller dans son analyse, ainsi que le niveau d'aide dont elle avait besoin pour y parvenir.
Q : Comment avez-vous mis en place l’« attaquant » ?
K : Nous avons fourni au modèle un kit de départ réaliste comprenant les éléments qu’un véritable attaquant se procurerait en premier lieu : le trafic HTTP capturé entre l’application et le serveur de licences, les paquets JavaScript côté client, une description des failles connues, ainsi qu’une explication du flux de données de base avec des vecteurs d’attaque plausibles.
Par conséquent, le modèle n'est pas parti de zéro. Il a commencé exactement là où un pirate humain compétent aurait commencé.
Q : Et que s'est-il réellement passé ?
K : Deux choses se sont produites. Et toutes deux étaient instructives. Premièrement, le modèle a refusé de coopérer tant que nous ne lui avions pas fourni une justification solide pour ce travail. Dans notre cas, il s’agissait d’une recherche légitime en matière de sécurité sur notre propre système. Une fois qu’il s’est mis au travail, il a produit une analyse structurelle véritablement utile du client et du flux de données, puis il a commis, en toute confiance, une série d’erreurs critiques.
Q : Pouvez-vous donner un exemple d'une telle erreur ?
K : Le cas le plus instructif : le modèle a pris un raccourci en se basant sur sa propre « expérience » générique et a supposé que le traitement de la réponse de licence devait se faire au sein des hooks d’un lecteur multimédia spécifique, car c’est là que cela se passe habituellement dans les systèmes qu’il a observés. Dans notre schéma, ce n’était pas le cas.
Cette seule hypothèse erronée a entraîné une conclusion erronée — le modèle a estimé que la réponse relative à la licence n'était pas du tout sur-chiffrée — et a conduit l'ensemble de l'analyse dans une impasse. Le résultat semblait plausible, a été présenté avec une totale assurance, mais était tout simplement faux.
Q : A-t-il été difficile de remettre l'analyse sur les rails ?
K : Il ne s’agissait pas d’une simple clarification. Il a fallu environ 25 itérations de correction humaine avant que le modèle n’identifie le processus de décryptage réel de la réponse de licence. Deux ingénieurs cumulant à eux deux 35 ans d’expérience dans le piratage éthique ont apporté leur contribution constructive à l’IA.
Les progrès ont été réalisés presque exclusivement grâce à un cycle de confrontation — « c'est faux, et voici pourquoi » et « est-ce que ça fonctionne vraiment comme ça ? » — et chacune de ces corrections nécessitait l'intervention d'un humain qui savait déjà à quoi ressemblait la bonne réponse. L’IA a permis à un analyste expérimenté de gagner en efficacité. Elle ne l’a pas remplacé.
Q : Cela signifie-t-il que l'IA facilite la tâche des pirates qui s'attaquent aux contenus multimédias en streaming ?
K : Uniquement dans des limites très restreintes. Le résultat n’a jamais constitué une recette claire et reproductible. Sans une connaissance approfondie préalable du domaine, un novice se serait retrouvé avec une analyse qui semblait plausible mais qui était tout simplement erronée — sans aucun moyen de s’en rendre compte. Le coût était modeste, de l’ordre de quelques dizaines de dollars pour l’utilisation du modèle, mais l’expertise requise ne l’était pas.
Ce que l'IA change, c'est la rapidité: elle réduit considérablement le temps nécessaire à un spécialiste de l'ingénierie inverse déjà expérimenté pour comprendre un système. Elle ne confère pas cette capacité à la population plus large des attaquants occasionnels, et elle ne crée pas de failles là où il n'y en a pas.
Il est toutefois remarquable que le modèle ait fourni davantage de détails sur l'attaque qu'il ne l'avait initialement annoncé, principalement en réponse à des questions telles que : « Ai-je bien compris que l'attaque fonctionne ainsi et ainsi ? » Mais là encore, il fallait disposer de connaissances sur la manière d'attaquer la cible pour obtenir ces réponses.
Q : Que nous apprend donc cette expérience sur la manière adéquate de mettre en place une sécurité résistante à l'IA ?
K : L'IA ne crée pas de nouveaux vecteurs d'attaque. En revanche, sous la houlette d'un pirate expérimenté, elle peut rapidement tester des attaques connues, notamment en analysant les flux de données. Une protection bien conçue reste efficace contre toutes ces attaques, mais il n'y a plus lieu d'espérer qu'un pirate équipé d'une IA ne parvienne pas à trouver des failles en peu de temps.
