재서명한 APK 가 여전히 설치되는 이유와 잠재적 위험

설치 검증, 서명 신원, 비즈니스 권한 부여 구분

Android 는 APK 서명을 요구합니다. 시스템은 인스톨러 패키지 구조와 서명 데이터가 현재 콘텐츠를 해당 개인 키로 서명했음을 증명하는지 검증합니다. 공격자가 DEX 파일, 리소스 또는 매니페스트를 수정한 후 자신의 키로 완전히 재서명하면 새로운 패키지는 암호학적으로 자체 일관성을 갖추어 신선한 설치 조건을 충족할 수 있습니다.

이 결과는 현재 패키지에 검증 가능한 서명이 있는지 여부만 답변할 뿐 서명자가 공식 퍼블리셔인지 여부는 답변하지 못합니다. 브랜드 권한 부여, 합법적 채널, 계정 로그인 권한, 고위험 인터페이스 접근성은 애플리케이션과 서버가 별도로 평가해야 하는 비즈니스 영역의 문제입니다.

따라서 테스트 보고서에서 '재서명 후 설치 가능'을 '서명 보호 실패'와 동일시하거나, '설치 실패'를 '모든 리패키징 위험이 차단됨'으로 해석해서는 안 됩니다. 올바른 질문은 다음과 같습니다. 변조된 패키지가 사용자 기기에 도달할 수 있는가? 업그레이드 시 공식 버전을 사칭할 수 있는가? 실제 서비스에 연결할 수 있는가? 그리고 서버는 이러한 사례를 어떻게 식별하고 처리하는가?

재서명된 패키지가 종종 새로 설치만 허용되는 이유

안드로이드는 업데이트 연속성을 유지하기 위해 애플리케이션 서명 신원을 사용합니다. 설치된 애플리케이션이 인플레이스 업그레이드를 수락할 때, 플랫폼은 새 버전이 기존 버전과 관련하여 서명 신원 규칙을 만족하는지 확인해야 합니다. 무관한 인증서로 서명된 변조된 패키지는 일반적으로 공식 버전을 직접 오버레이할 수 없으며, 먼저 공식 앱을 제거하거나 패키지 이름을 변경하거나 사용자가 별도의 환경에 설치하도록 유도해야 합니다.

이것이 리패키징 테스트에서 새로 설치와 인플레이스 업그레이드를 모두 수행해야 하는 이유입니다. 새로 설치만 테스트하면 서명 연속성 검증을 놓치게 되고, 인플레이스 업그레이드만 테스트하면 다른 패키지 이름이나 제거 - 재설치 주기를 통해 위조된 패키지가 기기에 유입되는 경로를 놓치게 됩니다. 두 시나리오에 대한 결과를 별도로 기록해야 합니다.

서명 로테이션과 Play 앱 서명은 릴리스 체인의 복잡성을 증가시킵니다. 팀은 현재 및 과거에 허용된 인증서 신원, 로테이션 규칙, 업로드 키와 앱 서명 키의 책임을 명확히 구분해야 합니다. 서버 측 정책은 배포 방식과 일치하는 데이터를 사용해야 하며, 개발용 인증서, 업로드 인증서, 최종 배포 인증서를 단일 필드로 혼동해서는 안 됩니다.

• 현재 운영 버전에서 인플레이스 업그레이드 실행
• 제거 후 새로 설치 수행
• 패키지 이름 변경 여부 및 데이터 디렉터리 영향 확인
• 배포 플랫폼 규칙에 따른 인증서 로테이션 검증

재패키징 거버넌스는 최종 아티팩트 신원 식별부터 시작해야 함

팀들은 종종 빌드 번호만 저장하고 최종 APK 의 파일 다이제스트 및 서명 인증서 다이제스트 기록을 누락하곤 합니다. 채널 리소스 주입, 재배열, 재서명 또는 패키지 최적화 과정은 최종 파일을 변경할 수 있습니다. 보안 스캔이 채널 적용 전 아티팩트를 분석한다면, 실제 사용자가 수신하는 파일은 동일한 증거 범위 내에 포함되지 않습니다.

모든 릴리스 후보 (release candidate) 에 대해 모호함 없는 아티팩트 기록을 생성할 것을 권장합니다. 기록 항목에는 패키지 이름, versionCode, versionName, 파일 SHA-256, 인증서 SHA-256, 서명 스키마 검증 결과, 빌드 출처, 채널, 처리 순서, 생성 타임스탬프가 포함되어야 합니다. 정적 검사, 설치 업그레이드, 기능 회귀 테스트 (regression testing), 서버 측 허용 규칙은 모두 이 기록을 참조해야 합니다.

파일 다이제스트는 자체적으로 보호 조치가 아니며, 그 가치는 워크플로우 중에 테스트 대상이 조용히 변경되는 것을 방지하는 데 있습니다. 다이제스트, 서명 또는 채널 순서의 변경은 새로운 릴리스 후보를 나타내며, 영향을 받은 게이트의 재실행을 요구합니다.

artifact:
  package: com.example.redacted
  version_code: 240
  version_name: 2.4.0
  sha256: REDACTED
signing:
  certificate_sha256: REDACTED
  schemes: [v2, v3]
  distribution: managed-channel
pipeline:
  - build-release
  - harden-candidate
  - channel-resources
  - final-sign
acceptance:
  install_fresh: required
  upgrade_from_production: required
  server_policy_check: required

서버는 비정상 클라이언트를 정책 문제로 취급해야 함

클라이언트는 패키지 이름, 버전, 인증서 또는 무결성 자료를 보고할 수 있지만, 변조된 클라이언트는 이러한 표준 보고 필드를 조작할 수도 있습니다. 서버는 단일 클라이언트 보고 불리언 값을 신뢰하기보다 계정 상태, 버전, 요청 행동, 디바이스 위험도, 배포 환경을 종합하여 정책을 수립하고 검증 가능한 신호를 우선시해야 합니다.

Play Integrity 는 애플리케이션 인식, 디바이스 무결성, 계정 라이선싱, 환경 위험에 대한 판정을 반환할 수 있습니다. 공식 문서에 따르면 OS 버전, 디바이스 폼팩터, 배포 소스, Play 서비스 상태 또는 구성에 따라 특정 신호를 사용할 수 없을 수 있습니다. 올바른 접근 방식은 '사용 불가', '실패', '고위험' 상태를 별도로 모델링하여 기능 저하, 2 차 검증, 권한 제한 또는 거부를 위한 전략을 수립하는 것입니다.

Google Play 외 배포 시나리오에서는 Play 전용 신호를 단순히 복제할 수 없습니다. 엔터프라이즈 배포, 국내 채널, 사내 전달의 경우 자체 버전 허용 목록, 인증서 매핑, 업그레이드 메커니즘 및 이상 처리 절차를 구축해야 합니다. 플랫폼 신호는 증거의 일부일 뿐 모든 채널에 적용되는 보편적 해답이 아닙니다.

잘못된 릴리스 순서로 인해 이전 검사 무효화

최종 서명 후 DEX, 리소스 또는 Manifest 를 수정하면 서명이 커버하는 내용이 손상되며, 스캔 후 재빌드하거나 재서명하면 스캔 결론과 최종 파일이 분리됩니다. 채널 처리 도구가 패키지 본문을 수정해야 한다면 최종 서명 전에 작업을 완료해야 하며, 아티팩트 원장에 해당 순서를 고정해야 합니다.

AAB 배포는 업로드된 아티팩트와 사용자 기기가 수신한 분할 APK 를 명확히 구분합니다. 팀은 배포 플랫폼에서 실제 전달된 아티팩트를 다운로드하거나 확보하여 샘플 검수를 수행해야 하며, 패키지 이름, 버전, 서명 식별자 및 주요 리소스가 릴리스 기록과 일치하는지 확인해야 합니다. 로컬에서 생성된 일반 APK 는 모든 기기 구성을 자동으로 대표할 수 없습니다.

롤백 패키지도 동일한 서명 및 업그레이드 검증을 거쳐야 합니다. 사고 발생 시 구형 파일을 임시로 재서명하더라도 버전 번호, 서명 또는 데이터 마이그레이션 요구 사항의 불일치로 인해 오버레이 설치가 실패할 수 있습니다.

재패키징 위험이 릴리스 가능한 통제 하에 있는지 판단하는 방법

릴리스 가능한 결론이란 변조된 패키지가 절대 설치되지 않는다는 의미가 아닙니다. 이는 공식 아티팩트의 신원을 추적 가능하게 하고, 비정상 아티팩트가 공식 버전을 몰래 오버레이하지 못하게 하며, 서버가 신뢰할 수 없는 클라이언트를 식별하거나 제한하고, 사용자가 정품 버전을 확보하여 복구할 경로를 가지며, 팀이 최종 전달 파일을 감사할 수 있음을 의미합니다.

테스트는 성공 경로와 실패 경로 모두에 대한 증거를 보존해야 합니다. 성공 경로에는 공식 버전의 정상 설치/업그레이드, 로그인 및 주요 비즈니스 흐름이 포함됩니다. 이상 경로에는 무관한 인증서를 사용한 인플레이스 업그레이드, 알 수 없는 버전의 고위험 인터페이스 접근, 만료된 버전, 무결성 신호 부재 및 오탐지 복구가 포함됩니다. 거부만 검증하고 복구 프로세스를 갖추지 않으면 실제 사용자가 해결 불가능한 상태에 갇히게 됩니다.

본 문서는 어떤 단일 애플리케이션 강화 기술로도 재서명된 설치 사례를 모두 차단할 수 있다고 주장하지 않습니다. 리패키징 거버넌스는 서명 관리, 업그레이드 제어, 아티팩트 관리, 클라이언트 복원력, 플랫폼 신호, 서버 측 정책이 공동으로 수행하는 시스템 엔지니어링 작업입니다.

• 공식 아티팩트의 신원은 독립적으로 감사 가능합니다.
• 비정상적인 인증서가 공식 설치본 위에 조용히 덮어씌워질 수 없습니다.
• 서버는 알 수 없는 클라이언트에 대해 등급별 정책을 적용합니다.
• 사용자는 신뢰할 수 있는 릴리스 채널로 복구할 수 있습니다.
• 롤백 패키지는 사전에 업그레이드 검증을 완료했습니다.