Reproducible Firmware Build는 같은 소스 코드, 환경, 절차로 미리 정한 출력을 바이트 단위까지 동일하게 만드는 빌드입니다. 특히 배포본에 추가 서명이 들어 있으면 버전, 기기 모델, 비교 범위를 명시해야 합니다.
주장은 펌웨어 이미지처럼 지정된 출력에 해당하며 모든 파일이나 로그에 자동으로 적용되지는 않습니다. 프로그램 동작이 같다는 것만으로 부족합니다. 검증은 보통 암호학적 해시를 이용하여 바이트가 같은지 확인합니다. 반복 가능한 빌드 없이 소스만 공개되어 있다고 해서 배포 바이너리와의 대응 관계가 입증되지는 않습니다. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
정확한 commit, 의존성과 버전, 컴파일러, 빌드 옵션, 관련 환경 변수, 대상 모델을 기록해야 합니다. 프로젝트 이름이나 계속 바뀌는 브랜치만으로는 부족합니다. 반복에 필요한 정보는 공개하거나 빌드 중에 기록해야 합니다. 그렇지 않으면 차이를 신뢰성 있게 평가할 수 없습니다. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]
컴파일러는 작업 디렉터리 경로를 디버그 정보에 넣을 수 있습니다. 같은 소스를 두 위치에 두면 서로 다른 파일이 나올 수 있습니다. 경로를 미리 정하거나 지원되는 방식으로 정규화할 수 있습니다. 이 규칙은 빌드 절차에 포함되어야 하며, 나중에 알 수 없는 차이를 삭제하면 검증의 의미가 사라집니다. [Reproducible Builds — Build paths]
유효한 서명은 특정 신뢰 모델에서 배포본을 해당 서명 키와 연결합니다. 독립 빌드는 소스와 바이너리 출력의 관계를 살펴봅니다. 공식 서명 파일에는 로컬 미서명 빌드에 없는 데이터가 들어 있을 수 있습니다. 따라서 전체 파일을 단순 비교하는 것이 주장된 재현성을 검사하는 올바른 방법이 아닐 수 있습니다. [Trezor — Reproducible build verification]
Trezor 문서는 버전과 모델을 선택하고 정해진 환경에서 이미지를 만든 뒤 공식 배포본과 비교합니다. 비교 전에 정확히 지정한 서명 필드를 영으로 채우는 절차를 설명하며, 오래된 형식은 헤더도 다릅니다. 구조는 모델과 버전에 따라 달라집니다. 한 이미지의 절차를 다른 이미지에 무조건 적용해서는 안 되며 원래 서명은 별도로 검증해야 합니다. [Trezor — Reproducible build verification]
먼저 리비전, 모델, 펌웨어 변형, 의존성, 선언된 이미지 변환이 같은지 확인합니다. 원본 파일과 차이 기록을 보관합니다. 불일치는 절차나 환경 오류일 수도, 배포 바이너리의 변경일 수도 있습니다. 그것만으로 원인이 정해지지는 않습니다. 차이를 설명하고 검사를 반복하기 전까지 출력을 검증 완료로 표시하면 안 됩니다. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]
결함이나 악성 동작이 있는 소스도 완벽하게 재현될 수 있습니다. 공통으로 쓰는 신뢰할 수 없는 컴파일러가 모든 결과에 같은 변경을 넣을 수 있습니다. 같은 도구를 반복 실행하는 것은 독립적인 컴파일러 감사가 아닙니다. 비공개 바이너리 구성 요소는 공개된 소스에서 다시 만들 수 있는 범위를 제한합니다. 파일 일치는 하드웨어의 진위나 특정 기기에 실제로 설치된 내용도 검증하지 않습니다. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]
유용한 기록에는 누가 어느 commit에서 어떤 절차와 모델로 빌드했고 어떤 파일을 비교했는지가 들어갑니다. 해시 알고리즘, 결과, 서명 데이터에 대한 정확한 예외 범위도 추가합니다. 독립적인 빌드 수행자가 늘면 단일 배포자에 대한 의존은 줄지만, 소스 검토와 업데이트 과정 및 기기 전체의 보안 검토를 대신하지는 못합니다. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]
같은 코드, 다른 서명 영역
두 사람이 같은 commit, 모델, 환경을 사용합니다. 로컬 이미지의 SHA-256은 같지만 공식 서명 이미지의 값은 다릅니다. 문서가 서명 필드를 정확히 정의한다면 정해진 변환을 복사본에 적용한 뒤 비교합니다. 일치는 이렇게 정의된 내용에만 해당하며 원래 서명은 따로 검증합니다. 다른 차이를 단순히 삭제해서는 안 됩니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Hardware Wallet, 개인 키, Cold Storage, Secure Element. 다음 항목에서도 이 글을 참조합니다 COLDCARD RNG Incident (2026).
01해시가 같으면 펌웨어가 안전하다고 결론 내릴 수 있나요?+
아니요. 일치는 특정 비교의 결과를 보여 줄 뿐 결함의 부재를 보여 주지 않습니다. 악성 소스나 공통으로 쓰는 신뢰할 수 없는 컴파일러도 같은 출력을 만들 수 있습니다. 빌드 검증, 소스 검토, 기기에 대한 신뢰를 구분해야 합니다.
02서명된 배포본의 해시가 다르면 무조건 공격인가요?+
아니요. 서명된 이미지에는 미리 문서화된 다른 서명 필드나 헤더가 있을 수 있습니다. 먼저 올바른 버전, 모델, 비교 절차를 확인하세요. 하지만 설명되지 않은 불일치를 검증 성공으로 처리하거나 바이트를 임의로 지워 우회해서는 안 됩니다.