大規模言語モデルのトークナイザーを保護して AI アプリケーションを保護する

最近のブログ投稿で、NVIDIA の AI レッド チームは、大規模言語モデル (LLM) トークナイザーの潜在的な脆弱性を明らかにし、これらのリスクを軽減する戦略を提供しました。

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.

大規模言語モデル (LLM) は、さまざまな AI アプリケーションで急速に注目を集めています。ただし、LLM パイプラインのさまざまな段階で脆弱性が発生する可能性があるため、セキュリティを確保することが重要です。見落とされがちな重要なコンポーネントの 1 つはトークナイザーです。トークナイザーは、LLM 処理用の入力文字列を準備する際に重要な役割を果たします。適切に保護されていない場合、トークナイザーは気づかれない潜在的なリスクを引き起こす可能性があります。

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.

NVIDIA の AI Red Team は、最近のブログ投稿でこれらの脆弱性を明らかにし、それらを軽減する戦略を提供しています。ここでは、彼らの調査結果と推奨事項の概要を示します。

Understanding the Vulnerability

脆弱性を理解する

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.

OpenAI や NVIDIA の LLM など、ほとんどの LLM は、トークナイザー、エンコーダー、デコーダー、損失関数で構成される共通のアーキテクチャを共有しています。これらのコンポーネントのうち、トークナイザーは通常、複数のモデル間で再利用され、通常はモデル ディレクトリにプレーンテキストの .json ファイルとして保存されます。

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.

この設計は、モデルごとにデータを再トークン化する必要がなくなり、モデル全体のサイズが削減されるため、実用的な観点からは理にかなっています。ただし、十分な権限を持つユーザーであれば誰でもトークナイザー構成にアクセスして変更できるため、脆弱性も生じます。

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

攻撃者はトークナイザーによる文字列のトークン ID へのマッピングを変更し、ユーザーの入力とモデルの解釈との間に矛盾が生じる可能性があります。たとえば、「deny」という単語の「allow」に関連付けられたトークン ID へのマッピングを変更できます。

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.

その結果、ユーザーが「deny」という単語を含む文字列を入力すると、トークナイザーはそれに「allow」のトークン ID を割り当て、入力の意味を根本的に変更します。このシナリオは、ユーザーの意図した入力の変更されたバージョンをモデルが処理するエンコード攻撃の例です。

Attack Vectors and 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.

トークナイザーをターゲットにするために使用できる攻撃ベクトルがいくつかあります。 1 つの方法では、Jupyter 起動ディレクトリにスクリプトを配置して、パイプラインが初期化される前にトークナイザーを変更します。このアプローチにより、攻撃者はモデル コードに直接アクセスせずにトークナイザー構成を変更できます。

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.

別の戦略には、コンテナ構築プロセス中にトークナイザー ファイルを変更して、サプライ チェーン攻撃を容易にすることが含まれる可能性があります。たとえば、攻撃者は、特定の文字列に一意のトークン ID を割り当てるカスタム マッピングを追加することによって、トークナイザーにバックドアを導入する可能性があります。

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.

このバックドアは、入力文字列が他の当事者によって変更された場合でも、モデルからの特定の動作や応答をトリガーするために使用される可能性があります。このような手法は、安全で制御されたビルド環境を維持することの重要性を強調しています。

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.

さらに、攻撃者は、システムに自分の制御下にあるキャッシュ ディレクトリを使用するよう指示することでキャッシュの動作を悪用し、悪意のある構成を挿入できるようにする可能性があります。これらのアクションは、静的構成チェックを補完するランタイム整合性検証の必要性を強調しています。

Mitigation Strategies

緩和戦略

To counter these threats, NVIDIA recommends several mitigation strategies.

これらの脅威に対抗するために、NVIDIA はいくつかの軽減戦略を推奨しています。

1. Strong Versioning and Auditing:

1. 強力なバージョニングと監査:

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.

トークナイザーが上流の依存関係として継承される場合、そのバージョンを明示的に指定して監査し、意図したモデル構成と一致していることを確認する必要があります。これにより、古いバージョンや侵害されたトークナイザー バージョンの継承を防ぐことができます。

2. Runtime Integrity Checks:

2. 実行時の整合性チェック:

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.

実行時整合性チェックを実装すると、実行時にトークナイザーへの不正な変更を検出するのに役立ちます。これらのチェックでは、トークナイザー ファイルとその内容の整合性を検証し、意図したとおりに動作し、実行中に改ざんされていないことを確認できます。

3. Logging Practices:

3. ロギングの実践:

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.

ロギングの実践は、入力文字列と出力文字列の明確な記録を提供することでフォレンジック分析に役立ち、トークナイザーの操作に起因する異常を特定するのに役立ちます。ログには元の入力文字列とトークン化された出力の両方が記録され、調査員が矛盾を迅速に特定できるようにする必要があります。

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.

LLM トークナイザーのセキュリティは、AI アプリケーションの整合性を維持するために最も重要です。トークナイザー構成に対する悪意のある変更は、ユーザーの意図とモデルの解釈の間に重大な矛盾をもたらし、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.

バージョン管理、監査、実行時検証などの堅牢なセキュリティ対策を採用することで、組織は AI システムをそのような脆弱性から保護できます。 AI セキュリティについてさらに詳しく知り、最新の開発状況を常に把握するには、今後開催される敵対的機械学習に関する NVIDIA Deep Learning Institute コースを検討することを検討してください。