💻 computer science

Evaluating the Effectiveness of LLMs in Aiding Compliance Testing of PKCS#1-v1.5

본 논문은 PKCS#1 v1.5 구현체의 컴플라이언스 테스트를 위해 문법 수준의 변이(grammar-level mutation)와 LLM 기반 코드 합성(LLM-based code synthesis)을 결로한 방법의 효과를 평가하며, 해당 접근 방식이 알려진 취약점을 재현하고 새로운 불일치를 발견하는 데는 성공했으나, 운영상의 신뢰성과 의미론적 충실도(semantic fidelity) 사이에 상당한 격차를 만드는 높은 LLM 환각 발생률로 인해 그 유용성이 심각하게 제한된다는 점을 밝히고 있다.

원저자: Polina Kozyreva, Endadul Hoque

게시일 2026-06-19

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Polina Kozyreva, Endadul Hoque

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신은 엄격한 건축 검사관이라고 상상해 보세요. 당신의 업무는 도시의 모든 집이 정확히 동일한 설계도(명세서)를 따르고 있는지 확인하는 것입니다. 설계도는 다음과 같이 말합니다: "앞문은 너비가 3피트여야 하고, 지붕은 빨간색이어야 하며, 굴뚝은 정확히 10피트 높이여야 한다."

컴퓨터 보안의 세계에서 이 "집들"은 암호화된 메시지(디지털 서명 등)를 처리하는 소프트웨어 프로그램입니다. 이 "설계도"는 PKCS#1 v1.5라고 불리는 복잡한 규칙 세트입니다. 만약 어떤 프로그램이 설계도와 완벽하게 일치하지 않는 집을 짓는다면, 해커가 침입할 수 있는 숨겨진 뒷문(backdoor)이 생길 수 있습니다.

문제점: 검사가 어렵다

이 집들을 검사하는 것은 매우 어렵습니다.

무작위 추측은 통하지 않는다: 단순히 집에 무작별로 벽돌을 던진다고 해서 문이 정확히 3피트 너비가 되도록 우연히 만들 확률은 거의 없습니다. 당신에게는 매우 구체적인 계획이 필요합니다.
전문가 도구는 느리다: 인간 전문가들이 만든 도구들은 설계도의 모든 가능한 변형을 확인할 수 있지만, 이러한 도구를 만드는 데는 수년간의 깊은 연구와 수작업이 필요합니다. 이는 마치 숙련된 건축가 팀을 고용하여 모든 집을 검사하는 것과 같습니다.

새로운 아이디어: "AI 건축가"

연구자들은 다음과 같은 간단한 질문을 던졌습니다: "대규모 언어 모델(LLM, AI)을 사용하여 망가진 설계도를 테스트로 변환하는 '번역기'로 사용할 수 있을까?"

그들의 과정은 다음과 같습니다:

원래의 설계도: 그들은 집을 짓는 공식 규칙을 가져왔습니다.
뮤테이터(Mutator, "만약에" 기계): 그들은 컴퓨터 프로그램을 사용하여 의도적으로 설계도를 13가지 방식으로 망가뜨렸습니다. 예를 들어, "만약 문이 4피트라면?", "만약 지붕이 파란색이라면?", 또는 "만 만약 굴뚝을 아예 없앤다면?"과 같이 말입니다.
AI 번역기: 그들은 이 망가진 설계도를 AI에게 건네며 이렇게 말했습니다. "이 망가진 설계도에 정확히 따라 집을 짓는 컴퓨터 프로그램을 작성해 줘."
테스트: 그들은 AI가 작성한 프로그램을 실행하여 집을 짓게 한 다음, 이 집을 48개의 서로 다른 소프트웨어 프로그램("빌더")에 입력하여 빌더들이 이 망가진 집을 받아들이는지 확인했습니다. 만약 빌더가 망가진 집을 받아들였다면, 그 빌더는 보안 결함이 있는 것입니다.

결과: 두 숫자의 이야기

좋은 소식 (운영 신뢰성):
AI는 작업을 시작하는 데 있어 지침을 따르는 능력이 놀라웠습니다.

**99.8%**의 경우, AI는 오류 없이 실행되는 프로그램을 성공적으로 작성했습니다. 이는 마치 오타나 누락된 페이지가 없는 설계도를 건네주는 건축가와 같았습니다.

나쁜 소식 (의미론적 충실도):
하지만, AI는 실제로 망가진 설계도를 따르는 데는 형편없었습니다.

AI가 망가진 설계도대로 집을 지었다고 할 수 있는 경우는 단 **17.5%**뿐이었습니다.
**82.5%**의 경우, AI는 "환각(hallucination)" 현상을 보였습니다. AI는 망가진 설계도를 보고 "오, 이건 좀 이상한데"라고 생각한 뒤, 집을 짓기 전에 몰래 원래의 완벽한 설계도로 다시 수정해 버렸습니다.

비유:
당신이 AI에게 "파란색 문이 있는 집을 지어줘"라고 요청했다고 가정해 봅시다.

성공: AI가 파란색 문이 있는 집을 짓습니다.
환각: AI가 문은 보통 빨간색이라는 것을 알기에, 당신이 명시적으로 파란색을 요청했음에도 불구하고 몰래 빨간색 문이 있는 집을 짓습니다. AI가 당신의 특정 지시를 무시한 것입니다.

무엇을 발견했는가?

큰 버그들을 찾아냈다: 이 방식은 알려진 보안 결함 중 13개 중 10개를 성공적으로 재현했습니다(해커가 서명을 위조할 수 있게 하는 가장 위험한 결함 포함). 이는 이 아이디어가 효과가 있음을 증명합니다.
새로운 버그를 발견했다: 그들은 LibTomCrypt라는 라이브러리에서 아무도 보고하지 않았던 새로운 보안 문제를 발견했습니다. 이는 AI가 특정 부분(리딩 제로 바이트)이 빠진 집을 성공적으로 지었고, 해당 라이브 library가 이를 받아들였기 때문에 발생했습니다.
병목 현상은 계획이 아니라 AI에 있다: 연구자들은 "뮤테이터"(설계도를 망가뜨리는 기계)는 아주 잘 작동하고 있다는 것을 발견했습니다. 문제는 망가진 규칙을 고수하지 못하는 AI의 능력이었습니다.

"환각"의 유형

연구자들은 의사가 환을 진단하듯 AI의 실패를 분류했습니다:

"수정가(Fixer)" (가장 흔함): AI는 망가진 규칙(예: "패딩은 16바이트보다 작아야 한다")을 보고 "그건 불가능해"라고 생각하여, 조용히 정상적인 규칙으로 다시 고쳐버렸습니다.
"수학은 잘하지만 수학을 잊어버린 천재": AI는 규칙을 따르려고 노력했지만 단순한 수학 계산(예: 패딩을 얼마나 추가할지 계산하는 것)에서 실수하여, 결과적으로 엉뚱한 크기의 집을 만들었습니다.
"무시(Ignore)": AI는 망가진 부분을 완전히 무시하고 표준적인 집을 지었습니다.

결론

이 논문은 AI를 사용하여 컴퓨터 보안을 테스트하는 것이 유망하지만 현재로서는 신뢰할 수 없음을 보여줍니다.

AI는 코드가 실행되도록 쓰는 데는 뛰어나지만(중단되지 않음), 코드가 당신이 말한 의미대로 작동하게 만드는 데는 매우 서툽니다. AI는 당신의 의도적인 실수를 "알아서 고쳐야 한다"고 생각하여 수정해 버리는 습성이 있습니다.

연구자들은 만약 AI를 이런 종류의 테스트에 사용하고 싶다면, AI가 작성한 코드를 그냥 믿어서는 안 된다고 결론지었습니다. AI가 정말로 당신의 특정된, 망가진 지시를 따랐는지, 아니면 그냥 정상적인 상태로 "수정"해 버렸는지 확인하기 위한 두 번째 검증 단계가 반드시 필요합니다. 그때까지 AI는 매우 열성적이지만, 당신이 "올바른" 방식으로 하라고 내린 구체적인 명령을 자주 무시하는 유능하지만 말 안 듣는 인턴과 같습니다.

기술 요약: PKCS#1-v1.5의 컴플라이언스 테스트를 돕는 LLM의 효과성 평가

문제 정의

이진 프로토콜 구현의 사양 준수(specification compliance) 여부를 테스트하려면 구조적 제약(예: Type-Length-Value 인코딩, 계층적 중첩)과 의미론적 제약(예: 길이-값 일관성, 패딩 규칙)을 모두 만족하는 입력을 생성해야 한다. 순수하게 무작위로 생성하는 방식은 PKCS#1 v1.5와 같은 복잡한 프로토콜에서 의미 있는 동작을 탐색하기에는 불충분하다. 반대로, 기존의 도메인 특화 도구(예: Morpheus)는 심도 있는 프로토콜 전문 지식과 상당한 수동 노력이 필요하여 일반화 가능성이 제한된다. 범용 퍼저(fuzzer)는 의미론적 인식이 부족하여 사양 준수를 체계적으로 테스트할 수 없다.

본 연구는 문법 수준의 변이(grammar-level mutation)와 대규모 언어 모델(LLM) 기반의 코드 합성이 사양 준수 테스트를 위한 실행 가능하고 일반화 가능한 접근 방식이 될 수 있는지 조사한다. 구체적으로, LLM이 변이된 형식 문법(구조적 규칙과 의미론적 제약을 모두 타겟팅함)을 실행 가능한 입력 생성기로 신뢰성 있게 변환하여 암호화 라이브러리의 사양 위반을 드러낼 수 있는지 묻는다.

방법론

저자들은 이 접근 방식을 널리 배포된 표준이자 정형 검증된 테스팅 오라클(Morpheus)을 갖춘 PKCS#1 v1.5 서명 검증 스킴에 대해 평가하기 위해 4단계 파이프라인을 설계했다.

문법 표현: RFC 8017으로부터 PKCS#1 v1.5를 설명하는 문법을 BNF(Backus-Naur Form)로 수동 구축하였으며, 여기에 산술 및 관계식 형태의 의미론적 제약을 추가하였다. 여기에는 TLV 구조를 위한 생성 규칙과 패딩 길이 및 총 메시지 크기를 강제하는 제약 조건이 포함된다.
문법 변이: 변이기가 문법 트리(grammar tree)를 조작하여 $N$ $N$ 개의 구조적으로 구별되는 변이체를 생성한다. 저자들은 세 가지 카테고리에 걸쳐 13개의 변이 연산자를 설계했다:
- 구조적 (TLV-무시형, TLV-Ignorant): TLV 관계를 고려하지 않고 구성이나 값을 수정한다 (예: remove_component, swap_order, add_garbage).
- 구조적 (TLV-인지형, TLV-Aware): 내부의 길이-값 일관성을 유지하면서 TLV 구성 요소를 수정한다 (예: change_length_change_value).
- 제약 변이 (Constraint Mutations): 의미론적 제약을 직접 타겟팅한다 (예: remove_constr, flip_signs, exchange_subexpressions).
  이 과정은 중복이 감지될 경우 변이 강도를 높이는 적응형 알고리즘을 사용하여 다양성을 유지한다.
LLM 기반 코드 합성: 각 변이된 문법은 OpenAI GPT-5-nano를 위한 프롬프트로 직렬화되며, LLM에게 변이된 사양을 준수하는 이진 테스트 케이스를 생성하는 독립형 Python 스크립트를 작성하도록 지시한다. 만약 스크립트 실행에 실패하면, 에러 트레이스백(traceback)이 유한한 루프 내에서 수정을 위해 LLM에 다시 전달된다.
테스트 케이스 생성 및 평가: 드라이버는 생성된 스크립트를 실행하여 테스트 케이스를 생성하고, 이를 48개의 암호화 라이브러리 구현체에 실행한다. 결과는 Morpheus 오라클과 비교하여 사양 위반(서명 위조, 경미한 관대함, 버퍼 오버플로우, 호환성 문제)을 탐지한다.

주요 기여

경험적 조사: 13개의 변이 연산자를 통해 구조적 및 제약 차원에서 실행된, 문법 수준의 변이와 LLM 코드 합성을 결합한 이진 프로토콜 컴플라이언스 테스트에 대한 체계적인 평가를 수행했다.
기존 취약점 재현: 본 접근 방식이 Morpheus가 식별한 13개 중 10개(76.9%)의 비사소한(non-trivial) 위반 카테고리를 재현했으며, 여기에는 48개 구현체 전반에 걸친 5개의 모든 서명 위조 카테고리가 포함됨을 입증했다.
새로운 불일치 발견: PKCS#1 v1.5 구조에서 선행 바이트가 누락된 것을 허용하는 LibTomCrypt v1.18.2의 이전에 보고되지 않은 불일치를 식별했다.
환각(Hallucination) 분류 체계: 사양 제약이 있는 코드 생성에서의 LLM 환각에 대한 정량적 특성화를 수행했다. 본 연구는 다섯 가지 뚜렷한 환각 유형을 식별하고, 변이 카테고리에 따른 환각 분포의 체계적인 변화를 밝혀냈다.

결과

컴플라이언스 테스트 효과성

재현율: 파이프라인은 알려진 13개 위반 카테고리 중 10개(76.9%)를 성공적으로 재현했다. 결정적으로, 가장 보안상 중요한 5개의 서명 위조 카테고리를 모두 재현했다.
새로운 발견: 본 접근 방식은 LibTomCrypt(및 그 파생물인 CryptX)에서 라이브러리가 RFC 8017을 위반하여 선행 0x00 바이트가 누락된 입력을 수용하는 새로운 불일치를 발견했다. 이는 remove_component 연산자에 의해 트리거되었으며, 문법 수준의 변이가 조합적 접근 방식이 놓칠 수 있는 입력 영역을 탐색할 수 있음을 보여준다.
놓친 위반 사항: 세 가지 위반 카테고리(ML#2, ML#5, ML#7)는 재현되지 않았다. 분석 결과, 이는 변이 연산자의 한계 때문이 아니라, 생성된 스크립트가 변이된 문법을 충실히 구현하지 못한 LLM의 환각 때문임이 확인되었다.

LLM 신뢰성 및 환각

본 연구는 **운영 신뢰성(operational reliability)**과 의미론적 충실도(semantic fidelity) 사이의 극명한 격차를 보여준다:

운영 신뢰성: 생성된 스크립트의 99.8%가 성공적으로 실행되었다 (첫 시도에서 96.1%, 수리 후 3.7%).
의미론적 충실도: 단 17.5%의 스크립트만이 변이된 사양을 올바르게 구현했다. 82.5%는 어떤 형태로든 환각을 보였다.

환각 분류 체계:

H1 (패딩 계산 오류, 26.8%): 변이를 올바르게 구현했으나, 패딩 길이를 잘못 계산함 (예: 전체 길이로부터 유도하는 대신 하드코딩된 값을 사용함).
H2 (변이 완전 무시, 1.1%): 변이된 문법에도 불구하고 표준을 준수하는 구조를 생성하여, 기존 지식으로 사양을 덮어씀.
H3 (부분적/모순적, 29.3%): 변이를 부분적으로 구현했으나, 문법 자체에 모순(예: 상충하는 길이와 패딩 제약)이 포함되어 있어 제약 조건을 누락함.
H4 (부분적/이유 없음, 18.0%): 문법이 충족 가능함에도 불구하고 특정 제약을 이유 없이 무시하며 부분적으로만 구현함.
H5 (퇴보적 출력, 7.1%): 문법과 구조적 유사성이 전혀 없는 무작위 문자열을 생성함.

변이 유형과의 상관관계:

**제약 전용 변이(Constraint-only mutations)**는 가장 높은 정확도(30.3%)를 보였으나, 동시에 완전히 무시되는 비율(H2, 8.1%)도 가장 높았다.
구조적 (TLV-무시형) 변이는 H3(32.4%)와 H4(21.5%) 발생률이 가장 높았다.
혼합 변이(Mixed mutations) (구조적 및 제약 연산자 결합)는 가장 낮은 정확도(4.8%)를 보였다.

의의 및 주장

본 논문은 문법 수준의 변이와 LLM 코드 합성을 결합하는 것이 심도 있는 도메인 특화 엔지니어링의 필요성을 줄여주는 실행 가능한 접근 방식이라고 주장한다. 이는 대부분의 핵심적인 알려진 취약점을 성공적으로 재현하며 새로운 불일치를 발견할 수 있다.

그러나 주요 기여는 변이 전략보다는 LLM의 의미론적 충실도가 주요 병목 구간임을 식별한 데 있다. 저자들은 99.8%라는 높은 운영 성공률이 17.5%라는 낮은 의미론적 정확도를 가리고 있음을 강조하며, 환각된 스크립트의 높은 출력 변동성 때문에 이러한 격차를 의미론적 분석 없이는 탐지하기 어렵다고 지적한다.

본 연구의 결과는 향-후 도구를 위한 실질적인 지침을 제공한다:

**H3 (모순된 문법)**는 합성 전 만족도 검사(satisfiability checks)를 통해 완화할 수 있다.
**H4 (설명되지 않는 편차)**는 사후 생성 검증이 필요한 불가결한 신뢰성 문제이다.
**H1 (산술 오류)**는 다단계 산술 유도에 대한 LLM의 일반적인 약점을 반영한다.

저자들은 공식 사양으로부터 코드를 생성하기 위해 LLM을 사용하는 모든 접근 방식은 이 충실도 격차(fidelity gap)를 반드시 다루어야 하며, 운영 지표만으로는 이러한 테스팅 파이프라인의 효과성을 평가하기에 불충분하다고 결론짓는다.