APK 署名スキーム v3.2

Android 17（API レベル 37）では、APK 署名スキーム v3.2 が導入されています。これは、Android エコシステムのポスト量子暗号（PQC）への移行をサポートするように設計されたハイブリッド署名スキームです。

業界で PQC アルゴリズムが大規模にデプロイされるにつれて、v3.2 スキームは多層防御を提供します。APK に署名するには、RSA や ECDSA などの従来型アルゴリズムと PQC アルゴリズムの両方を使用する必要があります。このハイブリッド アプローチでは、従来型の暗号化を使用して APK を保護しながら、量子コンピュータからの脅威を防ぎます。

目的と詳細

v3.2 スキームは、業界標準に準拠した移行メカニズムとして機能します。このハイブリッド アプローチでは、PQC の量子耐性というメリットを得ながら、従来型の署名アルゴリズムの確かなセキュリティを引き続き利用できます。新しく標準化された PQC アルゴリズムが大規模な運用成熟度を確立したら、このハイブリッド構成から単一の PQC 署名鍵に移行できます。v3.2 署名スキームのプラットフォーム サポートは Android 17 から始まります。Android の古いバージョンでは、v3.2 ブロックがスキップされ、署名検証に以前のスキームが使用されます。

この移行期間中にセキュリティを維持し、ダウングレード攻撃を防ぐため、v3.2 スキームでは次の動作が強制されます。

  • 新しい鍵マテリアル: ハイブリッド ブロックに移行するには、従来型鍵と PQC 鍵を新たに生成する必要があります。 ハイブリッド構成と非ハイブリッド構成の間で鍵マテリアルを再利用しないでください。
  • 暗黙的なローテーション: プラットフォームは、ハイブリッド ブロックを暗黙的な鍵ローテーションとして扱います。プラットフォームは、新しい従来型鍵をアプリの既存の署名リネージに最後から 2 番目の鍵として追加し、新しい 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 署名ブロックには、v3.2 署名ブロックが v2、v3.0、v3.1 の署名ブロックとともに格納されます。

v3.2 ブロック構造は v3.0 と似ていますが、新しいブロック ID 0x70e1c89f を使用して、ハイブリッド ブロックであることを示します。有効な v3.2 ブロックには、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 バージョンをターゲットとするエントリが 2 つ含まれている必要があります。

  • 長さプレフィックス付き署名者の長さプレフィックス付きシーケンス:
    • 長さプレフィックス付き署名者（従来型）
    • 長さプレフィックス付き署名者（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. ブロックに2 つの 署名者が含まれていることを確認します。2 つより少ない場合、または 2 つより多い場合は、検証に失敗します。
  3. 一方の署名者が従来型署名アルゴリズムを使用し、もう一方の署名者が PQC 署名アルゴリズムを使用していることを確認します。両方が従来型の場合、または両方が PQC の場合は、検証に失敗します。
  4. 両方の署名者がまったく同じ SDK 範囲（minSdkVersion と maxSdkVersion）をターゲットにしていることを確認します。
  5. 2 つの署名者ごとに、標準の v3 検証を行います。
    1. signatures から、サポートされている最も強力な署名アルゴリズム ID を選択します。
    2. 公開鍵を使用して、署名データに対して signatures の対応する署名を検証します。
    3. 署名データの minSdkVersion と maxSdkVersion が、署名なしの minSdkVersion と maxSdkVersion と一致していることを確認します。
    4. 証明書を解析し、最初の証明書が公開鍵と一致していることを確認します。
    5. 追加属性を解析して、proof-of-rotation 構造を抽出します。
  6. 署名履歴（proof-of-rotation）を確認します。
    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. 無効なアップデート パス: デベロッパーが適切なローテーションを行わずに、ハイブリッド鍵の 1 つのみを単一署名者として使用してハイブリッド署名アプリをアップデートしようとすると、アップデートは失敗します。ダウングレード攻撃を防ぐため、両方の鍵を明示的に移行に関与させる必要があります。
  9. いずれかのステップが失敗すると、検証に失敗します。

保護の削除

古い署名スキームへのダウングレード攻撃を防ぐため、v3.2 スキームには、以前のスキームの反復処理と同様の保護属性の削除が含まれています。

署名ツールは、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 ターゲット値と 最大 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 機能を使用したロールバック移行、削除攻撃の緩和策の検証など、包括的なシナリオがカバーされています。