제로지식 컴파일을 활용한 소프트웨어 아티팩트 검증 가능성

초록

본 논문은 컴파일러를 제로지식 가상머신(zkVM) 안에서 실행해 소스 코드, 컴파일러 바이너리, 그리고 생성된 바이너리를 하나의 암호학적 증명으로 묶는다. RISC Zero와 ChibiCC를 이용한 구현으로 200개의 합성 프로그램과 OpenSSL·libsodium 실세계 파일을 검증했으며, 컴파일러 대체, 소스 변조, 바이너리 변조, 재사용 공격을 모두 차단함을 보였다. 재현 가능한 빌드의 복잡성을 피하면서 강력한 공급망 보안을 제공한다.

상세 분석

이 논문은 기존의 재현 가능한 빌드(reproducible builds)와 하드웨어 기반 TEE(Trusted Execution Environment) 방식이 갖는 한계를 극복하기 위해 제로지식 가상머신(zkVM) 위에서 컴파일 과정을 증명 가능한 형태로 전환한다는 근본적인 아이디어를 제시한다. 핵심은 컴파일러 자체를 일반적인 바이너리 형태로 유지하면서, 해당 바이너리를 RISC Zero zkVM에 로드해 실행하고, 실행 중 발생하는 모든 명령어, 레지스터 변화, 메모리 접근을 다항식 제약식으로 변환한다는 점이다. 이렇게 생성된 제약식에 대해 SNARK 형태의 영지식 증명을 생성하면, 검증자는 소스 코드와 컴파일러 해시, 그리고 최종 어셈블리 출력만을 공개 입력으로 제공받아 짧은 증명을 빠르게 검증할 수 있다.

보안 모델에서는 네 가지 주요 위협을 정의한다. 첫째, 소스 코드 변조는 컴파일 전·중에 발생할 수 있는 악의적 수정이며, 증명에 포함된 소스 해시가 일치하지 않으면 검증이 실패한다. 둘째, 컴파일러 대체 공격은 악성 컴파일러가 정당한 컴파일러와 동일한 해시를 가졌다고 주장하는 경우인데, zkVM 내부에서 실행된 실제 바이너리와 사전 합의된 컴파일러 해시가 매칭되지 않으면 탐지된다. 셋째, 바이너리 변조는 컴파일 후 배포 단계에서 발생하는데, 증명은 출력 어셈블리와 정확히 일치해야 하므로 임의 수정은 검증 단계에서 거부된다. 넷째, 재사용(Replay) 공격은 이전에 생성된 유효 증명을 새로운 바이너리에 연결하려는 시도로, 증명에 포함된 출력 해시가 최신 바이너리와 다르면 검증이 불가능하다.

시스템은 세 단계로 구성된다. 1) 컴파일러 핸드쉐이크 단계에서 prover와 verifier가 동일한 컴파일러 바이너리와 그 해시를 사전에 합의한다. 2) zkVM 내부에서 컴파일을 수행하며, 실행 트레이스를 기록하고 영지식 증명을 생성한다. 3) verifier는 공개된 소스, 컴파일러 해시, 출력 어셈블리와 증명을 받아 zkVM 검증 알고리즘으로 신속히 검증한다. 이 과정은 재현 가능한 빌드에서 요구되는 전체 툴체인 재구축을 필요로 하지 않으며, 하드웨어 TEE가 요구하는 특수 칩이나 공급망 신뢰를 요구하지 않는다.

구현에서는 RISC Zero zkVM과 경량 C 컴파일러인 ChibiCC를 선택했는데, ChibiCC는 소스‑투‑어셈블리 파이프라인이 비교적 단순해 zkVM에 적합했다. 실험에서는 Csmith으로 생성한 200개의 무작위 C 프로그램, OpenSSL 31개 파일, libsodium 21개 파일을 대상으로 성공적인 zk‑컴파일 및 검증을 수행했으며, 평균 증명 생성 시간은 수십 초, 검증 시간은 밀리초 수준이었다. 모든 공격 시나리오에 대해 검증이 거부되었으며, 증명의 크기는 수백 바이트에 불과해 배포 비용이 낮았다.

가정으로는 영지식 증명 체계의 암호학적 강도, zkVM 구현의 정확성, 그리고 prover와 verifier가 사전에 합의한 공통 아티팩트에 대한 신뢰가 있다. 이러한 가정이 깨질 경우 증명 위조나 검증 오류가 발생할 수 있다. 논문은 또한 현재 zkVM이 메모리 집약적인 컴파일러에 대해 성능 병목이 될 수 있음을 인정하고, 더 효율적인 arithmetization 기법이나 하드웨어 가속을 통한 확장을 제안한다.