APK 서명 체계 v3.2

Android 17 (API 수준 37)에서는 양자 내성 암호 (PQC)로의 Android 생태계 전환을 지원하도록 설계된 하이브리드 서명 체계인 APK 서명 체계 v3.2를 도입합니다.

업계에서 PQC 알고리즘을 대규모로 배포함에 따라 v3.2 체계는 심층 방어를 제공합니다. RSA 또는 ECDSA와 같은 기존 알고리즘과 PQC 알고리즘을 모두 사용하여 APK에 서명해야 합니다. 이 하이브리드 접근 방식은 기존 암호화를 사용하여 APK를 보호하는 동시에 양자 컴퓨터의 위협으로부터 방어합니다.

목적 및 세부정보

v3.2 체계는 업계 표준 전환 메커니즘으로 작동합니다. 이 하이브리드 접근 방식을 사용하면 기존 서명 알고리즘의 입증된 보안에 계속 의존하면서 PQC의 양자 내성 이점을 얻을 수 있습니다. 새로 표준화된 PQC 알고리즘이 대규모로 운영 성숙도를 확립하면 이 하이브리드 구성에서 단일 PQC 서명 키로 전환할 수 있습니다. v3.2 서명 체계에 대한 플랫폼 지원은 Android 17부터 시작됩니다. 이전 Android 버전은 v3.2 블록을 건너뛰고 서명 확인을 위해 이전 체계를 사용합니다.

이 전환 중에 보안을 유지하고 다운그레이드 공격을 방지하기 위해 v3.2 체계는 다음 동작을 적용합니다.

  • 새 키 자료: 하이브리드 블록으로 전환하려면 새 기존 키와 PQC 키를 생성해야 합니다. 하이브리드 구성과 비하이브리드 구성 간에 키 자료를 재사용하지 마세요.
  • 암시적 순환: 플랫폼은 하이브리드 블록을 암시적 키 순환으로 취급합니다. 플랫폼은 새 기존 키를 앱의 기존 서명 계보에 마지막에서 두 번째 키로 추가하고 새 PQC 키를 앱의 현재 서명 ID로 취급합니다.
  • 공유 계보: 암시적 순환을 성공적으로 실행하려면 하이브리드 블록 내의 새 기존 키와 새 PQC 키가 모두 동일한 서명 계보를 공유해야 합니다. 새 하이브리드 서명자 모두를 위해 앱의 기존 서명 기록(단일 원래 키 또는 이전에 순환된 키의 계보)을 복제해야 합니다. 플랫폼은 이 공유 계보를 사용하여 앱을 하이브리드 체계로 전환하는 항목이 앱의 현재 서명 ID의 합법적인 소유자인지 확인합니다.
  • PQC 단일 서명자 제한: PQC의 초기 출시 중에 Android는 PQC 알고리즘의 사용을 v3.2 하이브리드 블록으로 명시적으로 제한합니다. 플랫폼은 v2, v3.0 또는 v3.1과 같은 이전 서명 체계를 사용하여 단일 서명자 PQC 구성을 확인하지 않습니다.
  • 다시 전환: v3.2 하이브리드 블록에서 단일 서명자 블록(향후 출시에서 지원되는 경우 기존 서명자 또는 PQC 서명자)으로 다시 전환할 때 플랫폼은 하이브리드 블록의 기존 키와 PQC 키가 모두 새 서명 계보에 있고 새 단일 서명자를 증명하는지 확인합니다.

전환을 위한 권장사항

이전 Android 버전과의 호환성을 유지하고 PQC 서명으로 전환하는 동안 안전한 업그레이드 경로를 제공하려면 APK에 단일 기존 키로 서명된 표준 v3.0 또는 v3.1 서명 블록이 계속 포함되어야 합니다. Android 17 (API 수준 37) 이상만 v3.2 하이브리드 체계를 지원하므로 이 요구사항을 통해 이전 버전을 실행하는 기기에서 앱을 확인하고 설치할 수 있습니다.

기존 대체 구성

PQC 전환 중에 운영 안전망을 제공하려면 기존 대체 구성을 구현하세요.

  • 기존 앱: 앱의 현재 설정된 서명 키인 K0은 이 대체의 자연스러운 기반 역할을 합니다.
  • 새 앱: 새 하이브리드 키인 C_K1 및 PQC_K1과 함께 기준 기존 서명 키인 K0을 생성하여 초기 ID를 설정합니다.

두 시나리오 모두에서 APK에는 새 하이브리드 키인 C_K1 및 PQC_K1로 서명된 v3.2 하이브리드 블록과 함께 기존 키인 K0으로 서명된 표준 v3.0 또는 v3.1 서명 블록이 포함되어야 합니다.

v3.2 체계의 초기 배포 중에 하이브리드 블록의 서명 계보는 K0에 ROLLBACK 기능을 부여해야 합니다. 배포 문제가 발생하면 이 기능을 통해 사용자 업데이트를 중단하지 않고 앱을 기존 서명으로 대체할 수 있습니다. 충분한 런타임 데이터로 하이브리드 배포가 안정적인 것으로 확인되면 후속 업데이트에서 ROLLBACK 기능을 삭제하여 새 키를 완전히 보호하는 것이 좋습니다.

장기 구성 요구사항

앱이 하이브리드 체계만 지원하는 플랫폼 출시를 타겟팅하는 한 이 하이브리드 서명 구성을 유지해야 합니다. 플랫폼 버전이 단일 서명자 PQC 키를 지원하더라도 v3.2 하이브리드 블록이 필요한 출시를 타겟팅하는 모든 APK에 두 키로 서명해야 합니다.

APK 서명 체계 v3.2 블록

APK 서명 블록은 v2, v3.0, v3.1 서명 블록과 함께 v3.2 서명 블록을 저장합니다.

v3.2 블록 구조는 v3.0과 비슷하지만 새 블록 ID인 0x70e1c89f를 사용하여 하이브리드 블록임을 나타냅니다. 유효한 v3.2 블록에는 정확히 두 개의 서명자가 포함되어야 합니다.

지원되는 알고리즘

v3.2 체계는 처음에는 다음 PQC 서명 알고리즘을 지원합니다.

  • ML-DSA-65
  • ML-DSA-87

이러한 알고리즘은 v3.0 및 v3.1에서 지원되는 것과 같은 표준 기존 서명 알고리즘과 페어링되어 하이브리드 블록을 형성합니다.

형식

APK 서명 블록은 ID 0x70e1c89f 아래에 APK 서명 체계 v3.2 블록을 저장합니다.

v3.2 블록의 형식은 v3.0과 동일하지만 서명자 요소의 최상위 시퀀스에는 동일한 SDK 버전을 타겟팅하는 항목이 정확히 두 개 포함되어야 합니다.

  • 길이가 접두사로 지정된 signer의 길이가 접두사로 지정된 시퀀스:
    • 길이가 접두사로 지정된 signer (기존)
    • 길이가 접두사로 지정된 signer (PQC)

각 서명자는 표준 v3 형식을 사용합니다.

  • 길이가 접두사로 지정된 signed data:
    • 길이가 접두사로 지정된 digests의 길이가 접두사로 지정된 시퀀스:
    • signature algorithm ID (4바이트)
    • digest (길이가 접두사로 지정됨)
    • certificates의 길이가 접두사로 지정된 시퀀스:
    • 길이가 접두사로 지정된 X.509 certificate (ASN.1 DER 형식)
    • minSDK (uint32)
    • maxSDK (uint32)
    • 길이가 접두사로 지정된 additional attributes의 길이가 접두사로 지정된 시퀀스:
    • ID (uint32)
    • value (가변 길이: 추가 속성 길이 - 4바이트)
  • minSDK (uint32)
  • maxSDK (uint32)
  • 길이가 접두사로 지정된 signatures의 길이가 접두사로 지정된 시퀀스:
    • signature algorithm ID (4바이트)
    • signature에 대한 길이가 접두사로 지정된 signed data
  • 길이가 접두사로 지정된 public key (SubjectPublicKeyInfo, ASN.1 DER 형식)

인증

Android 17 (API 수준 37) 이상에서 v3.2 서명을 확인하기 위해 플랫폼은 기존 서명자와 PQC 서명자를 모두 확인하고 호환성을 확인하며 암시적 순환 계보를 확인합니다. Android 16 (API 수준 36) 이하 플랫폼 출시에서는 플랫폼이 이 하이브리드 서명 블록을 처리하지 않고 대신 이전 체계를 사용합니다.

전반적인 프로세스는 다음과 같습니다.

  1. APK 서명 체계 v3.2 블록 (ID 0x70e1c89f)을 찾습니다.
  2. 블록에 정확히 두 개 의 서명자가 포함되어 있는지 확인합니다. 서명자가 두 개보다 적거나 많으면 인증이 실패합니다.
  3. 한 서명자는 기존 서명 알고리즘을 사용하고 다른 서명자는 PQC 서명 알고리즘을 사용하는지 확인합니다. 둘 다 기존 서명자이거나 둘 다 PQC 서명자인 경우 인증이 실패합니다.
  4. 두 서명자가 모두 정확히 동일한 SDK 범위 (minSdkVersion 및 maxSdkVersion)를 타겟팅하는지 확인합니다.
  5. 두 서명자 각각에 대해 표준 v3 인증을 실행합니다.
    1. signatures에서 가장 강하게 지원되는 signature algorithm ID를 선택합니다.
    2. signatures에서 signed data에 해당하는 signature를 확인하고, 이때 public key를 사용합니다.
    3. signed data의 minSdkVersion 및 maxSdkVersion이 서명되지 않은 minSdkVersion 및 maxSdkVersion과 일치하는지 확인합니다.
    4. 인증서를 파싱하고 첫 번째 인증서가 public key와 일치하는지 확인합니다.
    5. 추가 속성을 파싱하여 키 순환 증빙 자료 구조를 추출합니다.
  6. 서명 기록 (키 순환 증빙 자료)을 확인합니다.
    1. 두 서명자의 이전 서명 기록이 동일한지 확인합니다.
    2. 계보 길이가 일치해야 하며 현재 서명자까지의 모든 인증서와 기능 플래그가 동일해야 합니다.
    3. 기록이 일치하면 계보를 병합합니다. 기존 서명자의 인증서를 PQC 서명자의 인증서의 선행자로 취급하고 PQC 서명자를 현재 터미널 노드로 할당합니다.
  7. 콘텐츠 다이제스트를 확인합니다.
    1. 두 서명자의 다이제스트 맵을 반복합니다.
    2. 일치하는 다이제스트 알고리즘의 경우 계산된 다이제스트 값이 기존 서명자와 PQC 서명자 간에 동일한지 확인합니다.
  8. 인증된 서명자의 일치하는 다이제스트를 사용하여 APK 콘텐츠의 무결성을 확인합니다(v2 및 v3와 유사).
    1. 앱이 이미 설치된 경우 패키지 업데이트 계보를 확인합니다.
    2. 단일 서명자에서 업데이트: 설치된 앱이 단일 기존 키로 서명된 경우 해당 키는 새 하이브리드 블록의 서명 계보에 하이브리드 서명자의 선행자로 있어야 합니다.
    3. 하이브리드 서명자에서 업데이트하여 하이브리드를 계속 사용: 설치된 앱이 v3.2 하이브리드 블록으로 서명된 경우 이전 기존 키와 PQC 키가 모두 업데이트 APK의 v3.2 블록에서 현재 활성 서명자로 유지되거나 새로 순환된 하이브리드 키를 증명하는 새 서명 계보에 모두 있어야 합니다.
    4. 하이브리드 서명자에서 전환: 설치된 앱이 v3.2 하이브리드 블록으로 서명되고 업데이트 APK가 단일 서명자 (PQC 또는 기존)로 다시 전환되는 경우 이전 하이브리드 서명자가 모두 업데이트 APK의 서명 계보에 있고 새 단일 서명 키를 증명해야 합니다.
    5. 잘못된 업데이트 경로: 개발자가 적절한 순환 없이 하이브리드 키 중 하나만 단일 서명자로 사용하여 하이브리드 서명된 앱을 업데이트하려고 하면 업데이트가 실패합니다. 다운그레이드 공격을 방지하려면 전환에 두 키가 모두 명시적으로 관여해야 합니다.
  9. 단계가 실패하면 인증이 실패합니다.

제거 보호 조치

이전 서명 체계로의 다운그레이드 공격을 방지하기 위해 v3.2 체계에는 이전 체계 반복과 유사한 제거 보호 속성이 포함되어 있습니다.

서명 도구는 두 가지 특정 하이브리드 제거 보호 속성을 v3.0 및 v3.1 서명 블록의 추가 속성에 작성합니다. 이러한 속성은 v3.2 하이브리드 블록이 있어야 하고 확인해야 하는 정확한 SDK 버전 경계를 정의합니다.

  • 최소 SDK 버전 속성 (ID 0xbf940529): 이 속성의 값은 하이브리드 서명 블록에서 지원하는 최소 SDK 버전을 지정합니다.
  • 최대 SDK 버전 속성 (ID 0x9f06b79c): 이 속성의 값은 하이브리드 서명 블록에서 지원하는 최대 SDK 버전을 지정합니다. 이 속성을 사용하면 상위 플랫폼 출시에서 하이브리드 서명이 필요하지 않을 때 단일 서명자 구성으로 전환할 수 있습니다.

블록이 없거나 SDK 범위가 기기에 적용되지 않아 플랫폼이 v3.2 인증을 건너뛰는 경우 플랫폼은 있는 다음 블록에 대해 APK를 인증합니다. 이전 블록에 이러한 제거 보호 속성이 포함되어 있으면 플랫폼은 다음 검사를 적용합니다.

  • 존재 및 범위 인증: v3.0 또는 v3.1 서명 블록에 최소 SDK 속성 (ID 0xbf940529, 값 X) 또는 최대 SDK 속성 (ID 0x9f06b79c, 값 Y)이 포함되어 있으면 플랫폼은 APK 내에 v3.2 하이브리드 블록이 있어야 합니다. 플랫폼은 하이브리드 블록을 읽어 타겟팅된 SDK 범위가 이러한 속성으로 지정된 경계와 일치하는지 확인합니다. v3.2 블록이 없거나 내부 최소 및 최대 SDK 타겟 값이 X 및 Y와 같지 않으면 플랫폼은 설치를 거부합니다.
  • 범위 내 적용: 기기의 SDK 버전이 이러한 속성으로 지정된 유효한 범위(최대 속성을 제공할 때 X보다 크거나 같고 Y보다 작거나 같음)에 속하는 경우 플랫폼은 서명 인증을 위해 v3.2 하이브리드 블록을 엄격하게 요구합니다. 플랫폼이 이 타겟 SDK 범위 내의 기기에서 v3.0 또는 v3.1 블록을 인증하는 경우 v3.2 블록이 악의적으로 우회되거나 제거되었으므로 플랫폼은 설치를 거부합니다.

이러한 경계를 적용하여 플랫폼은 APK에 v3.2 블록이 포함되어야 하는 시점을 결정합니다. 블록이 제거된 경우 플랫폼은 다운그레이드 공격을 방지하기 위해 설치를 거부합니다.

구현 확인

v3.2 서명 체계의 구현을 테스트하려면 cts/hostsidetests/appsecurity/src/android/appsecurity/cts/에 있는 HybridSignatureVerificationTest.java CTS 테스트를 실행하세요.

이러한 테스트는 성공적인 설치, 기존 전용 버전에서의 업데이트, ROLLBACK 기능을 사용한 롤백 전환, 제거 공격 완화 확인 등 포괄적인 시나리오를 다룹니다.