APK 簽署配置 v3.2

Android 17 (API 級別 37) 推出 APK 簽署配置 v3.2，這項混合式簽署配置旨在支援 Android 生態系統過渡至後量子密碼術 (PQC)。

隨著業界大規模部署 PQC 演算法，3.2 版架構可提供深層防禦。您必須使用傳統演算法 (例如 RSA 或 ECDSA) 和 PQC 演算法簽署 APK。這種混合式做法會使用傳統密碼編譯技術保護 APK，同時防範量子電腦的威脅。

目的和詳細資料

3.2 版架構是符合業界標準的過渡機制。採用這種混合式做法，您就能享有 PQC 的抗量子優勢，同時繼續仰賴傳統簽章演算法的可靠安全性。一旦新標準化的 PQC 演算法大規模建立作業成熟度，您就可以從這個混合設定轉換為單一 PQC 簽署金鑰。平台從 Android 17 開始支援 v3.2 簽署配置。較舊的 Android 版本會略過 v3.2 區塊，並使用先前的配置進行簽名驗證。

為確保安全，並在轉換期間防範降級攻擊，v3.2 配置會強制執行下列行為：

  • 新金鑰內容：如要轉換為混合區塊，必須產生新的傳統和 PQC 金鑰。請勿在混合型和非混合型設定之間重複使用金鑰材料。
  • 隱含輪替：平台會將混合區塊視為隱含金鑰輪替。平台會將新的傳統金鑰附加至應用程式現有的簽署沿襲，做為倒數第二個金鑰，並將新的 PQC 金鑰視為應用程式目前的簽署身分。
  • 共用歷程：如要順利執行隱含輪換，混合型區塊中的新傳統版金鑰和新 PQC 金鑰必須共用相同的簽署祖系。您必須為兩個新的混合簽署者，複製應用程式現有的簽署記錄 (無論是單一原始金鑰，還是先前輪替的金鑰沿襲)。平台會使用這個共用沿襲來驗證將應用程式轉換為混合式配置的實體，是否為應用程式目前簽署身分的合法擁有者。
  • PQC 單一簽署者限制：在 PQC 首次推出期間，Android 會明確限制只能在 v3.2 混合式區塊中使用 PQC 演算法。平台不會使用先前的簽署配置 (例如 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，是這項備援功能的自然基礎。
  • 新應用程式：產生基準傳統簽署金鑰 K0，以及新的混合式金鑰 C_K1 和 PQC_K1，建立初始身分。

在這兩種情況下，APK 都必須包含以傳統金鑰 K0 簽署的標準 v3.0 或 v3.1 簽章區塊，以及以新混合金鑰 C_K1 和 PQC_K1 簽署的 v3.2 混合區塊。

在 v3.2 方案的初始部署期間，混合式區塊的簽署沿襲應將 ROLLBACK 功能授予 K0。如果發生部署問題，應用程式可透過這項功能回復為傳統簽章，不會中斷使用者更新。一旦有足夠的執行階段資料確認混合式部署穩定，建議您在後續更新中移除 ROLLBACK 功能，充分保護新金鑰。

長期設定需求

只要應用程式是以僅支援混合式簽署配置的平台版本為目標，就必須維持這項配置。即使平台版本支援單一簽署者 PQC 金鑰，您也必須使用這兩把金鑰，簽署以需要 v3.2 混合區塊的版本為目標的任何 APK。

APK 簽署配置 v3.2 區塊

APK 簽署區塊會儲存 v3.2 簽署區塊，以及任何 v2、v3.0 和 v3.1 簽署區塊。

v3.2 區塊結構與 v3.0 類似，但使用新的區塊 ID 0x70e1c89f，表示這是混合式區塊。有效的 v3.2 區塊必須包含兩個簽署者。

支援的演算法

v3.2 配置最初支援下列 PQC 簽署演算法：

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

這些演算法會與標準古典簽章演算法配對 (例如 v3.0 和 v3.1 支援的演算法)，形成混合區塊。

格式

APK 簽署區塊會將 APK 簽署配置 v3.2 區塊儲存在 ID 0x70e1c89f 下。

v3.2 區塊的格式與 v3.0 相同，但簽署者元素頂層序列必須包含兩個以相同 SDK 版本為目標的項目：

  • 以長度為前置字元的簽署者序列 (以長度為前置字元)：
    • 長度前置簽署者 (傳統)
    • 長度前置簽署者 (PQC)

每位簽署者都使用標準 v3 格式：

  • 長度前置簽署資料：
    • 長度前置摘要的長度前置序列：
    • 簽章演算法 ID (4 個位元組)
    • 摘要 (長度前置)
    • 以長度為前置字元的憑證序列：
    • 以長度為前置字元的 X.509 憑證 (ASN.1 DER 格式)
    • minSDK (uint32)
    • maxSDK (uint32)
    • 以長度為前置字串的序列，其中包含以長度為前置字串的其他屬性：
    • ID (uint32)
    • 值 (長度可變：額外屬性的長度 - 4 個位元組)
  • minSDK (uint32)
  • maxSDK (uint32)
  • 長度前置簽章的長度前置序列：
    • 簽章演算法 ID (4 個位元組)
    • 簽署資料的長度前置簽章
  • 以長度為前置字元的公開金鑰 (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. 針對兩位簽署者，分別執行標準的第 3 版驗證：
    1. 從簽章中選擇支援的最強簽章演算法 ID。
    2. 使用公開金鑰，根據簽名驗證簽署資料的對應簽名。
    3. 確認簽署資料中的 minSdkVersion 和 maxSdkVersion 與未簽署的 minSdkVersion 和 maxSdkVersion 相符。
    4. 剖析憑證，並確認第一個憑證與公開金鑰相符。
    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 簽章區塊的額外屬性。這些屬性會定義確切的 SDK 版本界線，v3.2 混合區塊必須存在於這些界線內，且經過驗證：

  • 最低 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 功能進行復原轉換，以及驗證剝除攻擊的緩解措施。