Sécuriser les tokeniseurs de grands modèles de langage pour protéger les applications d'IA

Dans un récent article de blog, l'équipe AI Red Team de NVIDIA a mis en lumière les vulnérabilités potentielles des tokenizers Large Language Model (LLM) et a fourni des stratégies pour atténuer ces risques.

Large language models (LLMs) have rapidly gained prominence in various AI applications. However, ensuring their security is crucial, as vulnerabilities can arise at different stages of the LLM pipeline. One critical component that often goes overlooked is the tokenizer, which plays a pivotal role in preparing input strings for LLM processing. If not adequately secured, tokenizers can introduce potential risks that might go unnoticed.

Les grands modèles de langage (LLM) ont rapidement pris de l'importance dans diverses applications d'IA. Cependant, garantir leur sécurité est crucial, car des vulnérabilités peuvent survenir à différentes étapes du pipeline LLM. Un composant essentiel qui est souvent négligé est le tokenizer, qui joue un rôle central dans la préparation des chaînes d'entrée pour le traitement LLM. S’ils ne sont pas correctement sécurisés, les tokeniseurs peuvent introduire des risques potentiels qui pourraient passer inaperçus.

In a recent blog post, NVIDIA's AI Red Team sheds light on these vulnerabilities and provides strategies to mitigate them. Here's a summary of their findings and recommendations.

Dans un récent article de blog, l'AI Red Team de NVIDIA met en lumière ces vulnérabilités et propose des stratégies pour les atténuer. Voici un résumé de leurs conclusions et recommandations.

Understanding the Vulnerability

Comprendre la vulnérabilité

Most LLMs, such as those from OpenAI and NVIDIA, share a common architecture, consisting of a tokenizer, encoder, decoder, and loss function. Among these components, the tokenizer is typically reused across multiple models and is usually stored as a plaintext .json file in the model directory.

La plupart des LLM, tels que ceux d'OpenAI et de NVIDIA, partagent une architecture commune, composée d'un tokenizer, d'un encodeur, d'un décodeur et d'une fonction de perte. Parmi ces composants, le tokenizer est généralement réutilisé sur plusieurs modèles et est généralement stocké sous forme de fichier .json en texte brut dans le répertoire du modèle.

This design makes sense from a practical standpoint, as it eliminates the need to re-tokenize data for each model and reduces overall model size. However, it also introduces a vulnerability, as anyone with sufficient privileges can access and modify the tokenizer configuration.

Cette conception est logique d'un point de vue pratique, car elle élimine le besoin de retokeniser les données pour chaque modèle et réduit la taille globale du modèle. Cependant, cela introduit également une vulnérabilité, car toute personne disposant de privilèges suffisants peut accéder et modifier la configuration du tokenizer.

An attacker could potentially alter the tokenizer's mapping of strings to token IDs, creating discrepancies between the user's input and the model's interpretation. For example, they could change the mapping of the word “deny” to the token ID associated with “allow.”

Un attaquant pourrait potentiellement modifier le mappage des chaînes du tokenizer avec les ID de jeton, créant ainsi des écarts entre l'entrée de l'utilisateur et l'interprétation du modèle. Par exemple, ils pourraient modifier le mappage du mot « refuser » avec l'ID de jeton associé à « autoriser ».

As a result, when a user inputs a string containing the word “deny,” the tokenizer would assign it the token ID for “allow,” fundamentally changing the meaning of the input. This scenario exemplifies an encoding attack, where the model processes an altered version of the user's intended input.

En conséquence, lorsqu'un utilisateur saisit une chaîne contenant le mot « refuser », le tokenizer lui attribue l'ID de jeton pour « autoriser », modifiant fondamentalement la signification de l'entrée. Ce scénario illustre une attaque de codage, dans laquelle le modèle traite une version modifiée de l'entrée prévue de l'utilisateur.

Attack Vectors and Exploitation

Vecteurs d’attaque et exploitation

There are several attack vectors that can be used to target tokenizers. One method involves placing a script in the Jupyter startup directory to modify the tokenizer before the pipeline initializes. This approach would enable an attacker to alter the tokenizer configuration without directly accessing the model code.

Il existe plusieurs vecteurs d’attaque qui peuvent être utilisés pour cibler les tokenizers. Une méthode consiste à placer un script dans le répertoire de démarrage de Jupyter pour modifier le tokenizer avant l'initialisation du pipeline. Cette approche permettrait à un attaquant de modifier la configuration du tokenizer sans accéder directement au code du modèle.

Another strategy could involve modifying tokenizer files during the container build process, facilitating a supply chain attack. For instance, an attacker might introduce a backdoor into the tokenizer by adding a custom mapping that assigns a unique token ID to a specific string.

Une autre stratégie pourrait impliquer de modifier les fichiers du tokenizer pendant le processus de création du conteneur, facilitant ainsi une attaque de la chaîne d'approvisionnement. Par exemple, un attaquant pourrait introduire une porte dérobée dans le tokenizer en ajoutant un mappage personnalisé qui attribue un ID de token unique à une chaîne spécifique.

This backdoor could then be used to trigger a particular behavior or response from the model, even if the input string is modified by other parties. Such techniques highlight the importance of maintaining a secure and controlled build environment.

Cette porte dérobée pourrait ensuite être utilisée pour déclencher un comportement ou une réponse particulière de la part du modèle, même si la chaîne d'entrée est modifiée par d'autres parties. De telles techniques soulignent l’importance de maintenir un environnement de construction sécurisé et contrôlé.

Moreover, attackers might attempt to exploit cache behaviors by directing the system to use a cache directory under their control, enabling them to inject malicious configurations. These actions emphasize the need for runtime integrity verifications to complement static configuration checks.

De plus, les attaquants pourraient tenter d'exploiter les comportements du cache en demandant au système d'utiliser un répertoire de cache sous leur contrôle, leur permettant ainsi d'injecter des configurations malveillantes. Ces actions soulignent la nécessité de vérifications de l'intégrité d'exécution pour compléter les vérifications de configuration statique.

Mitigation Strategies

Stratégies d'atténuation

To counter these threats, NVIDIA recommends several mitigation strategies.

Pour contrer ces menaces, NVIDIA recommande plusieurs stratégies d'atténuation.

1. Strong Versioning and Auditing:

1. Gestion des versions et audit solides :

When tokenizers are inherited as upstream dependencies, their versions should be explicitly specified and audited to ensure they align with the intended model configuration. This practice helps prevent inheriting outdated or compromised tokenizer versions.

Lorsque les tokenizers sont hérités en tant que dépendances en amont, leurs versions doivent être explicitement spécifiées et auditées pour garantir qu'elles correspondent à la configuration du modèle prévue. Cette pratique permet d’éviter d’hériter de versions de tokenizer obsolètes ou compromises.

2. Runtime Integrity Checks:

2. Vérifications de l'intégrité d'exécution :

Implementing runtime integrity checks can help detect unauthorized modifications to the tokenizer at runtime. These checks can verify the integrity of the tokenizer file and its contents, ensuring that it operates as intended and has not been tampered with during execution.

La mise en œuvre de contrôles d'intégrité à l'exécution peut aider à détecter les modifications non autorisées du tokenizer au moment de l'exécution. Ces contrôles peuvent vérifier l'intégrité du fichier tokenizer et de son contenu, garantissant qu'il fonctionne comme prévu et n'a pas été falsifié pendant l'exécution.

3. Logging Practices:

3. Pratiques d'exploitation forestière :

Logging practices can aid in forensic analysis by providing a clear record of input and output strings, helping to identify any anomalies resulting from tokenizer manipulation. Logs should capture both the original input string and the tokenized output, enabling investigators to quickly pinpoint any discrepancies.

Les pratiques de journalisation peuvent faciliter l'analyse médico-légale en fournissant un enregistrement clair des chaînes d'entrée et de sortie, aidant ainsi à identifier toute anomalie résultant de la manipulation du tokenizer. Les journaux doivent capturer à la fois la chaîne d'entrée d'origine et la sortie tokenisée, permettant aux enquêteurs d'identifier rapidement toute anomalie.

Conclusion

Conclusion

The security of LLM tokenizers is paramount to maintaining the integrity of AI applications. Malicious modifications to tokenizer configurations can lead to severe discrepancies between user intent and model interpretation, undermining the reliability of LLMs.

La sécurité des tokeniseurs LLM est primordiale pour maintenir l’intégrité des applications d’IA. Des modifications malveillantes apportées aux configurations du tokenizer peuvent entraîner de graves écarts entre l'intention de l'utilisateur et l'interprétation du modèle, compromettant ainsi la fiabilité des LLM.

By adopting robust security measures, including version control, auditing, and runtime verification, organizations can safeguard their AI systems against such vulnerabilities. For more insights on AI security and to stay updated on the latest developments, consider exploring the upcoming NVIDIA Deep Learning Institute course on Adversarial Machine Learning.

En adoptant des mesures de sécurité robustes, notamment le contrôle des versions, l'audit et la vérification de l'exécution, les organisations peuvent protéger leurs systèmes d'IA contre de telles vulnérabilités. Pour plus d’informations sur la sécurité de l’IA et pour rester informé des derniers développements, envisagez d’explorer le prochain cours du NVIDIA Deep Learning Institute sur l’apprentissage automatique contradictoire.