다양한 이중 컴파일로 신뢰의 함정 완전 차단

본 논문은 1974년 Karger와 Schell, 그리고 1984년 Ken Thompson이 제시한 “trusting‑trust” 공격이 현대 컴퓨팅 시스템에 미치는 위협을 재조명한다. 이 공격은 컴파일러 자체에 트로이 목마를 삽입하고, 그 컴파일러가 자신을 재컴파일할 때도 변조된 코드를 지속적으로 삽입하도록 설계된다. 결과적으로 소스 코드 검토만으로는 악성 코드를 발견할 수 없으며, 재컴파일을 통한 검증도 무용지물이 된다. 논문은 기존의 방어 시도—수동 비교, 자동 비교, 두 번째 컴파일러 사용, 인터프리터 전환 등—가 실용성 부족, 비결정성, 최적화 복잡성, 혹은 새로운 신뢰 경로를 생성한다는 한계가 있음을 지적한다. 특히, 기존의 “컴파일러 부트스트랩 테스트”는 두 번 동일한 컴파일러로 재컴파일해 결과가 일치하는지만 확인하므로, 변조된 컴파일러가 동일한 변조를 반복해도 통과될 수 있다. 이에 대한 해결책으로 저자는 “Diverse Double‑Compiling”(DDC) 기법을 제안한다. DDC는 (1) 신뢰할 수 있는 ‘다양한’ 컴파일러를 사용해 대상 컴파일러의 상위 컴파일러(부모)의 소스를 컴파일하고, (2) 그 결과물을 이용해 대상 컴파일러의 소스를 다시 컴파일한다. 최종적으로 얻은 실행 파일과 원본 대상 컴파일러 실행 파일을 비트‑대‑비트로 비교한다. 이 과정에서 두 가지 핵심 전제가 필요하다. 첫째, 사용된 신뢰 컴파일러와 실행 환경이 결정적이어야 하며, 둘째, 신뢰 컴파일러 자체가 변조되지 않아야 한다. 이러한 전제가 충족되면, 결과가 일치할 경우 소스와 실행 파일이 정확히 대응한다는 강력한 결론을 도출할 수 있다. 형식적 증명에서는 컴파일 함수 c(s,b)를 정의하고, 결정성(determinism), 무결성(integrity), 그리고 다양성(diversity)이라는 세 가지 가정을 명시한다. 증명은 두 개의 독립적인 컴파일 경로가 동일한 비트스트림을 산출한다면, 중간에 삽입된 악성 변조가 존재할 수 없음을 수학적으로 증명한다. 특히, 변조가 어느 한 단계에만 존재한다면, 다른 단계에서 사용된 독립적인 컴파일러가 그 변조를 복제하지 못해 결과가 달라지게 된다. 실험에서는 네 개의 컴파일러에 DDC를 적용하였다. (1) 작은 C 컴파일러, (2) 작은 Lisp 컴파일러, (3) 의도적으로 변조된 Lisp 컴파일러, (4) 대형 산업용 GCC 컴파일러이다. 변조된 Lisp 컴파일러는 트로이 목마를 삽입하도록 수정되었으며, DDC 결과 원본 실행 파일과 불일치해 변조를 성공적으로 탐지했다. GCC에 대해서는 서로 다른 플랫폼(x86‑Linux, ARM‑MacOS)과 서로 다른 버전의 Clang을 신뢰 컴파일러로 사용해 동일한 비트스트림을 재현함으로써, 실제 산업 환경에서도 DDC가 적용 가능함을 입증하였다. 다양성 확보 방안으로는 구현 언어 차이, 컴파일 옵션 차이, 하드웨어·운영체제 차이, 그리고 오픈소스·폐쇄소스·형식 검증된 컴파일러 등 여러 축을 제시한다. 또한, 신뢰 컴파일러 자체가 변조될 위험을 최소화하기 위해 ‘다중 독립 검증자’ 모델을 제안하고, 검증 체인을 블록체인·투명 로그에 기록하는 방법을 논의한다. 실무 적용 시 비결정적 요소(시간 스탬프, 파일 경로, 난수 초기화)와 최적화 단계가 비트 일치를 방해할 수 있기에, 재현성을 보장하기 위한 빌드 환경 고정화와 ‘deterministic build’ 기술이 필수임을 강조한다. CI/CD 파이프라인에 DDC를 자동화하고, 검증 결과를 정책적으로 활용하는 방안도 제시한다. 결론적으로, DDC는 기존의 ‘소스만 믿는다’ 접근을 넘어, 소스와 실행 파일 사이의 일관성을 수학적으로 보증하는 실용적이면서도 강력한 방어 메커니즘이다. 이는 신뢰 체인 전체를 재구성하고, 악성 변조가 존재할 경우 최소 한 단계에서 검출될 수 있음을 의미한다. 따라서 금융, 인프라, 군사, 기업 시스템 등 고신뢰성이 요구되는 분야에서 DDC를 표준 검증 절차로 채택한다면, “trusting‑trust” 공격을 실질적으로 차단할 수 있다.