체크섬은 바이트를 참조 값과 대조합니다. 서명은 무결성을 키와 연결합니다. 어느 것도 단독으로 소프트웨어의 안전성을 증명하지는 않습니다.
Android APK를 설치하기 전에 다음 세 가지 확인을 구분하세요. 이 파일은 예상한 릴리스와 일치하는가? 예상한 키로 서명되었는가? 독립적인 빌드 수행자가 명시된 소스에서 동일한 결과물을 재현할 수 있는가? SHA-256 체크섬, APK 서명, 재현 가능한 빌드는 각각 다른 방식으로 이 질문에 답합니다.
어느 것도 단독으로 악성코드 여부를 판정하지는 않습니다. 올바르게 서명되었고 빌드를 재현할 수 있는 프로그램에도 보안 버그나 의도적인 유해 동작이 포함될 수 있습니다.
각 검증 방법으로 확인할 수 있는 것
| 확인 방법 | 유용한 결과 | 중요한 한계 |
|---|---|---|
| 파일의 SHA-256 다이제스트 | 파일의 바이트가 특정한 신뢰할 수 있는 다이제스트와 일치함 | 공격자가 파일과 다이제스트를 모두 교체할 수 있다면 이 비교를 무력화할 수 있음 |
| APK 서명 검증 | 패키지의 서명이 해당 서명 인증서를 사용한 검증을 통과함 | 어떤 서명 키가 예상되는지 확인해야 함. 서명이 유효하다는 사실만으로는 배포자의 신원을 확인할 수 없음 |
| 재현 가능한 빌드 비교 | 문서화된 입력으로 지정된 결과물을 다시 생성할 수 있음 | 소스와 바이너리가 일치한다고 해서 소스가 안전하다는 뜻은 아님 |
| 보안 검토 | 특정 설계 또는 구현 문제가 평가되었음 | 검토 범위, 버전, 발견 사항, 미해결 문제가 중요함 |
Android에서는 설치와 업데이트를 위해 APK 서명이 필요합니다. Play App Signing을 사용하면 Google이 앱 서명 키를 관리하고 앱 번들에서 배포용 APK를 생성할 수 있습니다. 이는 문서화된 신뢰 체계이지, 임의의 중개자가 유효한 서명을 유지하면서 패키지를 몰래 변경할 수 있다는 증거가 아닙니다. Android 앱 서명 가이드를 참고하세요.
1단계: 정확히 어떤 결과물인지 확인하기
앱 버전, 릴리스 채널, 파일 이름, 대상 플랫폼 변형을 기록하세요. 요청하지도 않았는데 APK가 함께 전달된 메시지에서 복사한 체크섬이 아니라, 배포자의 공식 배포 페이지를 사용하세요.
배포자에게서 직접 내려받은 APK는 앱 스토어가 특정 기기를 위해 생성한 APK와 다를 수 있습니다. 버전, 아키텍처, 패키징, 서명 방식의 차이로 인해 정당하게 서로 다른 파일 해시가 나올 수 있습니다. 불일치를 변조의 증거로 보기 전에 동일한 조건의 결과물끼리 비교하고 있는지 확인하세요.
실제로 물어야 할 것은 “예상 값은 어디에서 왔으며, 왜 그 출처를 신뢰하는가?”입니다. 해시를 오프라인에서 계산한다고 해서 온라인에서 얻은 다이제스트의 신뢰 문제가 해결되지는 않습니다.
2단계: 로컬에서 SHA-256 계산하기
messenger.apk를 내려받은 파일 이름으로 바꾸세요. 다음 예시는 파일을 읽기만 하며 설치하지는 않습니다.
Linux:
sha256sum messenger.apk
macOS:
shasum -a 256 messenger.apk
Windows 명령 프롬프트:
certutil -hashfile messenger.apk SHA256
표시상의 공백과 영문 대소문자 차이만 무시하고 전체 다이제스트를 비교하세요. 처음이나 마지막 몇 글자만 비교하지 마세요. 같은 비교를 반복할 수 있도록 예상 다이제스트를 해당 릴리스 및 버전 정보와 함께 보관하세요.
값이 다르면 설치 전에 멈추세요. 결과물과 버전을 확인하고, 적절한 경우 신뢰할 수 있는 출처에서 다시 내려받으세요. 설명할 수 없는 불일치는 배포자에게 문의하세요. 우연히 받은 파일에 맞추려고 예상 체크섬을 “수정”해서는 안 됩니다.
3단계: APK 서명 확인하기
Android SDK Build Tools를 사용하는 경우, Google의 apksigner 문서에서 서명 검증과 인증서 정보 출력 방법을 확인할 수 있습니다.
apksigner verify --verbose --print-certs messenger.apk
APK가 지원하는 플랫폼에 대해 검증이 성공해야 합니다. 서명자 인증서 정보를 신뢰할 수 있는 릴리스 기록이나 배포자가 문서화한 서명 키 계보와 비교하세요. 낯선 키로 생성된 서명이 “검증됨”이라는 단어만으로 신뢰할 수 있는 서명이 되지는 않습니다. 정당한 서명 키 교체에도 근거가 필요하며, 단순히 불일치를 무시하라는 지시만으로는 충분하지 않습니다.
APK 파일의 SHA-256 다이제스트와 서명 인증서의 SHA-256 지문은 서로 다른 값입니다. 둘을 서로 비교하지 마세요.
4단계: 재현 가능한 빌드의 근거 찾기
빌드가 재현 가능하다는 주장을 하려면 소스 리비전, 빌드 환경, 지침, 대상 결과물이 정의되어 있어야 합니다. 독립적인 제삼자가 그 결과물을 다시 생성하고 결과를 비교할 수 있어야 합니다. Reproducible Builds 프로젝트의 정의에서도 이러한 입력을 그 주장의 일부로 명시합니다.
메신저의 경우 유용한 릴리스 근거에는 소스 태그, 고정된 의존성과 도구 체인 버전, 빌드 지침, 독립적인 비교 결과가 포함됩니다. 정확히 무엇을 비교했는지 물어보세요. 서명되지 않은 결과물인지, 서명된 APK인지, 패키지 내용 중 일부인지 확인해야 합니다. 소스 코드와 다운로드 파일의 해시가 공개되어 있다는 이유만으로 재현 가능하다고 추정하지 마세요.
재현 가능성은 검토된 소스와 배포되는 코드 사이의 연결을 강화합니다. 하지만 검토되지 않은 구현을 안전한 프로토콜로 바꾸거나, 실행 중인 휴대전화가 침해되지 않았음을 증명하지는 않습니다.
Livara의 Proof Lab이 맡는 역할
Livara의 Proof Lab은 로컬에서 APK 해시를 계산하고 공개된 다이제스트와 비교하는 기능을 제공합니다. 여기서 제공하는 암호 기술 시연의 범위는 전체 메시징 프로토콜 감사보다 좁습니다. 예상 릴리스 및 서명 정보와 함께, 명시된 목적에 맞게 해시 확인을 사용하세요. 이를 재현 가능한 빌드나 백도어 부재에 대한 독립적인 증명으로 취급하지 마세요.
위협 모델은 APK와 화면에 표시되는 다이제스트가 모두 교체될 수 있을 때의 한계를 명시합니다. 따라서 참조 값의 출처는 계산을 정확히 수행하는 것만큼 중요합니다.
자주 묻는 질문
체크섬이 일치하면 APK가 안전하다는 뜻인가요?
아닙니다. 참조 값을 신뢰할 수 있고 해시의 보안 속성이 성립한다는 전제 아래, 참조 다이제스트와의 일치만 확인합니다. 프로그램의 동작을 평가하지는 않습니다.
체크섬이 일치하면 서명 검증은 불필요한가요?
아닙니다. 두 확인 방법은 서로 다른 근거를 제공합니다. 서명은 패키지 무결성을 키와 연결하고, 파일 다이제스트는 특정 바이트 시퀀스를 식별합니다.
스토어에서 내려받은 파일은 웹사이트 APK의 해시와 일치해야 하나요?
원래 동일한 결과물이어야 하는 경우에만 그렇습니다. 먼저 릴리스 채널, 버전, 패키징을 확인하세요. 설명할 수 없는 불일치는 조사할 이유가 되지만, 곧바로 부정을 단정하거나 자동으로 승인할 이유는 아닙니다.
이 확인 방법으로 휴대전화에 이미 설치된 스파이웨어를 탐지할 수 있나요?
아닙니다. 이 방법들은 설치용 결과물을 평가하는 것이지, 기기의 현재 실행 상태를 이루는 모든 구성 요소를 평가하는 것은 아닙니다.
