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 파이프라인의 여러 단계에서 취약점이 발생할 수 있으므로 보안을 보장하는 것이 중요합니다. 종종 간과되는 중요한 구성 요소 중 하나는 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로 변경하여 사용자 입력과 모델 해석 간에 불일치를 만들 수 있습니다. 예를 들어, "거부"라는 단어의 매핑을 "허용"과 연결된 토큰 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.

결과적으로 사용자가 "거부"라는 단어가 포함된 문자열을 입력하면 토크나이저는 이 문자열에 "허용"에 대한 토큰 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.

토크나이저를 표적으로 삼는 데 사용할 수 있는 공격 벡터는 여러 가지가 있습니다. 한 가지 방법은 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 과정을 살펴보세요.