Sicherung großer Sprachmodell-Tokenizer zum Schutz von KI-Anwendungen

In einem aktuellen Blogbeitrag hat das AI Red Team von NVIDIA potenzielle Schwachstellen in LLM-Tokenizern (Large Language Model) beleuchtet und Strategien zur Minderung dieser Risiken bereitgestellt.

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.

Große Sprachmodelle (LLMs) haben in verschiedenen KI-Anwendungen schnell an Bedeutung gewonnen. Die Gewährleistung ihrer Sicherheit ist jedoch von entscheidender Bedeutung, da Schwachstellen in verschiedenen Phasen der LLM-Pipeline auftreten können. Eine wichtige Komponente, die oft übersehen wird, ist der Tokenizer, der eine entscheidende Rolle bei der Vorbereitung von Eingabezeichenfolgen für die LLM-Verarbeitung spielt. Wenn Tokenizer nicht ausreichend gesichert sind, können sie potenzielle Risiken mit sich bringen, die möglicherweise unbemerkt bleiben.

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.

In einem aktuellen Blogbeitrag beleuchtet das AI Red Team von NVIDIA diese Schwachstellen und bietet Strategien zu deren Behebung. Hier finden Sie eine Zusammenfassung ihrer Erkenntnisse und Empfehlungen.

Understanding the Vulnerability

Die Schwachstelle verstehen

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.

Die meisten LLMs, beispielsweise die von OpenAI und NVIDIA, verfügen über eine gemeinsame Architektur, die aus einem Tokenizer, Encoder, Decoder und einer Verlustfunktion besteht. Unter diesen Komponenten wird der Tokenizer typischerweise über mehrere Modelle hinweg wiederverwendet und normalerweise als Klartext-.json-Datei im Modellverzeichnis gespeichert.

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.

Dieses Design ist aus praktischer Sicht sinnvoll, da es die Notwendigkeit eliminiert, die Daten für jedes Modell erneut zu tokenisieren, und die Gesamtgröße des Modells reduziert. Es stellt jedoch auch eine Sicherheitslücke dar, da jeder mit ausreichenden Rechten auf die Tokenizer-Konfiguration zugreifen und diese ändern kann.

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.”

Ein Angreifer könnte möglicherweise die Zuordnung von Zeichenfolgen zu Token-IDs durch den Tokenizer ändern und so zu Diskrepanzen zwischen der Eingabe des Benutzers und der Interpretation des Modells führen. Sie könnten beispielsweise die Zuordnung des Wortes „deny“ zur Token-ID ändern, die mit „allow“ verknüpft ist.

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.

Wenn ein Benutzer daher eine Zeichenfolge eingibt, die das Wort „deny“ enthält, weist ihm der Tokenizer die Token-ID für „allow“ zu, wodurch sich die Bedeutung der Eingabe grundlegend ändert. Dieses Szenario veranschaulicht einen Codierungsangriff, bei dem das Modell eine veränderte Version der beabsichtigten Eingabe des Benutzers verarbeitet.

Attack Vectors and Exploitation

Angriffsvektoren und Ausbeutung

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.

Es gibt mehrere Angriffsvektoren, mit denen Tokenizer gezielt angegriffen werden können. Eine Methode besteht darin, ein Skript im Jupyter-Startverzeichnis abzulegen, um den Tokenizer zu ändern, bevor die Pipeline initialisiert wird. Dieser Ansatz würde es einem Angreifer ermöglichen, die Tokenizer-Konfiguration zu ändern, ohne direkt auf den Modellcode zuzugreifen.

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.

Eine andere Strategie könnte darin bestehen, Tokenizer-Dateien während des Container-Erstellungsprozesses zu ändern und so einen Angriff auf die Lieferkette zu erleichtern. Beispielsweise könnte ein Angreifer eine Hintertür in den Tokenizer einführen, indem er eine benutzerdefinierte Zuordnung hinzufügt, die einer bestimmten Zeichenfolge eine eindeutige Token-ID zuweist.

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.

Diese Hintertür könnte dann verwendet werden, um ein bestimmtes Verhalten oder eine bestimmte Reaktion des Modells auszulösen, selbst wenn die Eingabezeichenfolge von anderen Parteien geändert wird. Solche Techniken unterstreichen die Bedeutung der Aufrechterhaltung einer sicheren und kontrollierten Bauumgebung.

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.

Darüber hinaus könnten Angreifer versuchen, Cache-Verhalten auszunutzen, indem sie das System anweisen, ein Cache-Verzeichnis unter ihrer Kontrolle zu verwenden, wodurch sie schädliche Konfigurationen einschleusen können. Diese Maßnahmen unterstreichen die Notwendigkeit von Überprüfungen der Laufzeitintegrität als Ergänzung zu statischen Konfigurationsprüfungen.

Mitigation Strategies

Minderungsstrategien

To counter these threats, NVIDIA recommends several mitigation strategies.

Um diesen Bedrohungen entgegenzuwirken, empfiehlt NVIDIA mehrere Abwehrstrategien.

1. Strong Versioning and Auditing:

1. Starke Versionierung und Prüfung:

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.

Wenn Tokenizer als Upstream-Abhängigkeiten vererbt werden, sollten ihre Versionen explizit angegeben und geprüft werden, um sicherzustellen, dass sie mit der beabsichtigten Modellkonfiguration übereinstimmen. Diese Vorgehensweise trägt dazu bei, die Übernahme veralteter oder kompromittierter Tokenizer-Versionen zu verhindern.

2. Runtime Integrity Checks:

2. Laufzeitintegritätsprüfungen:

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.

Die Implementierung von Laufzeitintegritätsprüfungen kann dazu beitragen, nicht autorisierte Änderungen am Tokenizer zur Laufzeit zu erkennen. Diese Prüfungen können die Integrität der Tokenizer-Datei und ihres Inhalts überprüfen und so sicherstellen, dass sie wie vorgesehen funktioniert und während der Ausführung nicht manipuliert wurde.

3. Logging Practices:

3. Protokollierungspraktiken:

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.

Protokollierungspraktiken können bei der forensischen Analyse hilfreich sein, indem sie eine klare Aufzeichnung der Eingabe- und Ausgabezeichenfolgen liefern und dabei helfen, etwaige Anomalien zu identifizieren, die aus der Manipulation des Tokenizers resultieren. Protokolle sollten sowohl die ursprüngliche Eingabezeichenfolge als auch die tokenisierte Ausgabe erfassen, damit Ermittler etwaige Unstimmigkeiten schnell lokalisieren können.

Conclusion

Abschluss

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.

Die Sicherheit von LLM-Tokenizern ist für die Aufrechterhaltung der Integrität von KI-Anwendungen von größter Bedeutung. Böswillige Änderungen an Tokenizer-Konfigurationen können zu schwerwiegenden Diskrepanzen zwischen Benutzerabsicht und Modellinterpretation führen und die Zuverlässigkeit von LLMs beeinträchtigen.

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.

Durch die Einführung robuster Sicherheitsmaßnahmen, einschließlich Versionskontrolle, Auditierung und Laufzeitüberprüfung, können Unternehmen ihre KI-Systeme vor solchen Schwachstellen schützen. Für weitere Einblicke in die KI-Sicherheit und um über die neuesten Entwicklungen auf dem Laufenden zu bleiben, sollten Sie den kommenden Kurs des NVIDIA Deep Learning Institute zum Thema Adversarial Machine Learning in Betracht ziehen.