기술 요약: DSL 기반 및 LLM 보조 패칭을 통한 TEE 파티셔닝 문제의 자동 복구

1. 문제 정의

신뢰 실행 환경 (TEE) 은 민감한 데이터와 연산을 신뢰할 수 없는 운영체제로부터 보호하기 위해 하드웨어 기반 격리를 제공합니다. 그러나 TEE 애플리케이션은 소프트웨어 인터페이스 (SDK) 를 통해 신뢰할 수 없는 OS 와 상호작용해야 합니다. "일반 측 (신뢰할 수 없는)"과 "보안 측 (신뢰할 수 있는)" 사이의 부적절한 파티셔닝은 나쁜 파티셔닝 문제라고 통칭되는 심각한 취약점을 초래합니다. 이러한 문제에는 다음이 포함됩니다:

1. 암호화되지 않은 데이터 출력: 키, 토큰과 같은 민감한 데이터가 암호화 없이 TEE 에서 일반 측으로 전송되는 경우.
2. 입력 유효성 검사 약점: 일반 측에서 전달된 입력에 대한 검사 부족으로 인해 TEE 내부에서 버퍼 오버플로우 또는 메모리 손상 발생.
3. 공유 메모리의 직접 사용: 무결성 검증 없이 신뢰할 수 없는 OS 가 제어하는 공유 메모리 영역에 의존하여 변조가 가능해지는 경우.

정적 분석 도구가 이러한 문제를 탐지하는 데 존재하지만, 세 가지 특정 도전 과제로 인해 자동 복구는 여전히 largely 미개척 상태로 남아 있습니다:

• 표준 가이드라인 부재: 일반적인 소프트웨어 보안 (예: OWASP) 과 달리 TEE 개발에는 표준화된 안전한 파티셔닝 관행이 부족하여 복구를 위한 신뢰할 수 있는 기준 (ground truths) 을 정의하기 어렵습니다.
• 의미 추출의 어려움: TEE 애플리케이션은 종종 저수준 C 로 작성되며, 여기서 버퍼 크기나 유효한 인덱스 범위와 같은 의미 정보가 암시적이거나 동적이어서 정적 도구가 올바른 복구 매개변수를 추론하기 어렵습니다.
• 성숙한 테스트 부재: TEE 환경은 디버깅 및 모니터링을 제한합니다. 대부분의 프로젝트는 단위 테스트나 회귀 테스트 스위트가 부족하며, 교차 컴파일 요구사항으로 인해 생성 - 컴파일 - 테스트 사이클이 비싸고 복잡합니다.

2. 방법론: TEERepair

저자들은 복구 규칙을 인코딩하기 위한 도메인 특화 언어 (DSL) 와 컨텍스트 인식 의미 합성을 위한 대규모 언어 모델 (LLM) 을 결합한 TEERepair 프레임워크를 제안합니다. 워크플로우는 여섯 단계로 구성됩니다:

A. DSL 기반 복구 템플릿

가이드라인 부족 문제를 해결하기 위해 저자들은 안전한 TEE 파티셔닝 패턴을 공식적으로 인코딩하는 DSL 을 설계했습니다.

• 문법: DSL 은 일반적인 TEE 연산 (예: COPY, MALLOC, ENC, HASH) 과 조건부 가드 (IF) 에 대한 노드를 정의합니다.
• 복구 규칙: DSL 은 취약점 카테고리에 해당하는 세 가지 유형의 변환 규칙을 인코딩합니다:
  • 규칙 1 (암호화): 직접 데이터 복사를 메모리 할당, 암호화 (ENC), 그리고 암호문 복사 시퀀스로 대체합니다.
  • 규칙 2 (유효성 검사): 데이터 사용 전에 버퍼 크기나 배열 인덱스를 경계와 비교하여 확인하는 조건부 가드 (IF) 를 삽입합니다.
  • 규칙 3 (공유 메모리): 공유 메모리의 얕은 복사를 TEE 내부 버퍼로의 깊은 복사 (deep copies) 로 대체한 후, 사용 전 무결성 검사 (해싱) 를 수행합니다.
• 템플릿: 이러한 DSL 규칙은 컨텍스트별 변수를 위한 자리 표시자 (예: $cipher, $len) 를 포함하는 패치 템플릿으로 인스턴스화됩니다.

B. LLM 보조 자리 표시자 합성

저수준 C 코드에서 의미 정보를 추출하는 어려움에 대응하기 위해:

• 프롬프트 구성: 시스템은 취약한 코드 스니펫, 문제 유형, 그리고 DSL 로 생성된 패치 템플릿을 포함하는 프롬프트를 구성합니다.
• 추론: LLM(특히 gpt-4.1-mini) 은 코드 컨텍스트를 분석하여 자리 표시자에 대한 올바른 값을 추론합니다 (예: 어떤 변수가 버퍼 크기를 나타내는지 또는 어떤 암호화 키를 사용해야 하는지 식별).
• 제약: LLM 은 처음부터 코드를 생성하는 대신 자리 표시자만 채우도록 제한되어, 구문 오류와 환각 (hallucinations) 의 위험을 줄입니다.

C. 2 단계 검증 파이프라인

성숙한 테스트와 하드웨어 제약의 부족을 해결하기 위해:

1. 1 단계: 정적 피드백 (복구 단계): 정적 분석기 (DITING) 가 패치된 코드를 재분석하여 취약 패턴이 제거되었는지 확인합니다. 문제가 지속되면 LLM 에게 피드백을 제공하여 정제합니다. 이는 하드웨어 실행 없이 수행됩니다.
2. 2 단계: 런타임 검증 (기능 단계): 정적 분석이 통과되면, 시스템은 TEE 소스 코드의 진입점과 매개변수를 기반으로 테스트 클라이언트(일반 측 프로그램) 를 자동으로 합성합니다. 이 클라이언트는 실제 TEE 하드웨어 (예: TrustZone 이 탑재된 Raspberry Pi 3B) 에서 컴파일되고 실행되어 패치가 컴파일되고 실행되며 예상된 보안 출력 (예: 올바른 암호문, 잘못된 입력에 대한 적절한 오류 코드) 을 생성하는지 확인합니다.

3. 주요 기여

• TEERepair 프레임워크: 정적 탐지와 자동 수정 사이의 간극을 해소하는 TEE 나쁜 파티셔닝 문제를 위해 특별히 설계된 최초의 자동 복구 프레임워크.
• TEE 보안을 위한 DSL: 표준 가이드라인 부재 상황에서 신뢰할 수 있는 기준을 제공하기 위해 안전한 파티셔닝 패턴을 구조화된 변환으로 인코딩하는 새로운 도메인 특화 언어.
• LLM-DSL 시너지: DSL 이 구조적 보안 지식을 제공하고 LLM 이 저수준 C 코드의 컨텍스트 의존적 의미 모호성을 해결하는 하이브리드 접근법.
• 자동화된 테스트 클라이언트 생성: 기존 테스트 스위트의 부족을 극복하기 위해 TEE 애플리케이션에 대한 테스트 클라이언트 및 검증 사례를 자동으로 생성하는 방법.
• 벤치마크 및 평가: 여러 프로젝트에 걸친 89 개의 실제 나쁜 파티셔닝 사례를 포함하는 PartitioningE-Bench에 TEERepair 를 적용한 결과.

4. 실험 결과

저자들은 TEERepair 를 PartitioningE-Bench 에서 평가하고, 템플릿 기반 도구 (TBar, Prophet), 학습 기반 도구 (VulMaster), 그리고 LLM 기반 도구 (ChatRepair, SAN2PATCH) 를 포함한 베이스라인과 비교했습니다.

• 복구 성공률: TEERepair 는 **87.6%**의 성공률 (89 개 취약점 중 78 개 정확히 수정) 을 달성했습니다.
  • 암호화되지 않은 데이터 출력: 94.3% (33/35).
  • 입력 유효성 검사 약점: 67.0% (20/29).
  • 공유 메모리의 직접 사용: 100% (25/25).
• 베이스라인 성능: 다음으로 가장 좋은 성능을 보인 TBar 는 19.1% (17/89) 에 그쳤습니다. 다른 도구들은 훨씬 더 나쁜 성능을 보였으며, 많은 도구들이 공유 메모리 문제에 대해 올바른 패치를 전혀 생성하지 못했습니다.
• 절대적 연구 (Ablation Study): DSL 또는 LLM 중 하나를 제거하면 성능이 급격히 저하되었습니다 (DSL 만: 22.5%; LLM 만: 13.4%). 이는 두 구성 요소 모두 필수적임을 확인시켜 주었습니다.
• 실제 세계 검증: 저자들은 TEERepair 를 실제 GitHub 프로젝트에 적용했습니다. 그들은 5 개의 풀 리퀘스트를 제출했으며, 그중 2 개는 프로젝트 유지 관리자들에 의해 확인되고 병합되었습니다 (프로젝트 basicAlg_use 및 PPFL 내).

5. 중요성과 주장

이 논문은 TEERepair 가 가이드라인과 테스트 인프라 부족으로 인해 이전에는 자동 도구에 너무 어렵다고 여겨졌던 TEE 애플리케이션의 복잡하고 보안이 중요한 취약점 복구의 실현 가능성을 보여준다고 주장합니다.

• 실용적 적용 가능성: 실제 저장소에 패치가 성공적으로 병합되었다는 사실은 생성된 수정 사항이 구문적으로 정확할 뿐만 아니라 의미적으로 유효하고 인간 개발자들에게도 수용 가능함을 나타냅니다.
• 방법론적 신규성: 이 작업은 구조화된 도메인 지식 (DSL) 과 LLM 의 의미 추론 능력을 결합하는 것이 전통적인 정적 분석이 필요한 컨텍스트를 추론하지 못하는 저수준 보안 민감 코드를 복구하는 데 유효한 전략임을 강조합니다.
• 확장성: 이 프레임워크는 복구 로직 (정적 분석) 과 최종 검증 (하드웨어 실행) 을 분리함으로써 "교차 컴파일" 및 "하드웨어 격리" 문제를 해결하여 실용적인 복구 루프를 가능하게 합니다.

저자들은 현재 ARM TrustZone 에 초점을 맞추고 있다는 점 (DSL 은 플랫폼 중립적이지만) 과 TEE 환경에서의 자동화된 퍼징 (fuzzing) 의 어려움으로 인해 수동으로 구성된 테스트 사례에 의존한다는 점 등 한계를 지적합니다. 그러나 그들은 이 접근법이 TEE 생태계를 보호하는 데 있어 중요한 진전을 제공한다고 주장합니다.