御盾結論と決定条件
- インストール成功、署名検証成功、公式発行元 ID は別個の判断項目であり、前者 2 つで後者を代替することはできません。
- 再署名パッケージは通常、異なる署名 ID でインストールされた公式バージョンの上書き更新ができず、この更新チェーンは異常な成果物を特定するための重要なゲートとなります。
- 最終的な APK では、パッケージ名、バージョン、証明書ダイジェスト、ファイルダイジェスト、ビルドオリジン、およびチャネル処理順序を固定する必要があります。
- サーバーは許可されたバージョンとアプリケーション ID のホワイトリストを維持し、プラットフォーム完全性シグナルを信頼できるデータではなくリスク入力として扱う必要があります。
インストール検証、署名 ID、ビジネス認可の区別
Android では APK の署名が必須です。システムは、インストーラーのパッケージ構造と署名データが、現在のコンテンツが対応する秘密鍵で署名されたことを証明するかを検証します。攻撃者が DEX ファイル、リソース、またはマニフェストを改変し、独自の鍵で完全に再署名した場合、新しいパッケージは暗号的に自己整合性を保ち、新規インストールの条件を満たす可能性があります。
この結果は、現在のパッケージに検証可能な署名があるかのみを示し、署名者が公式発行元であるかは示しません。ブランド認可、正当なチャネル、アカウントログイン権限、高リスクインターフェースへのアクセスはビジネス上の懸念事項であり、アプリケーションとサーバーが別途評価する必要があります。
したがって、テスト報告書において「再署名後のインストール可能状態」を「署名保護の失敗」と同一視したり、「インストール失敗」を「リパッケージングに伴うすべてのリスクが解消されたこと」と同一視したりしてはなりません。問うべき正しい課題は以下の通りです。改変されたパッケージはユーザー端末に到達可能か？アップグレード時に公式バージョンになりすませるか？実サービスへ接続できるか？そしてサーバーはそうしたケースをどのように識別し、処理するか？
| 判断項目 | 回答される問い | 必須証拠 | 拡張解釈できない結論 |
|---|---|---|---|
| パッケージ解析可能 | インストーラーはファイル構造を読み取れるか？ | インストーラーの結果、マニフェスト、およびリソース構造 | 署名の正当性やコードの安全性を証明するものではない |
| 現在の署名が自己整合的 | 現在のコンテンツは、現在の証明書に対応する秘密鍵で署名されているか？ | 署名スキームの検証と証明書のダイジェスト | その証明書が公式エンティティに帰属することを証明するものではない |
| アップグレード時のアイデンティティ継続性 | 既にインストール済みの公式アプリケーションを上書き更新できるか？ | genuine な現行バージョンからのアップグレード実行 | すべてのビジネスインターフェースが異常なクライアントを拒否することを証明するものではない |
| ビジネス認可の通過 | サーバーは当該アカウントとバージョンに対してリソースへのアクセスを許可しているか？ | サーバー側のバージョン、アカウント、完全性、および行動ポリシー | クライアントコードが解析や改変に対して免疫であることを保証するものではない |
再署名済みパッケージが新規インストールのみを許可されることが多い理由
Android はアプリケーションの署名アイデンティティを用いて更新の継続性を維持します。インストール済みアプリケーションが上書きアップグレードを受け入れる際、プラットフォームは新バージョンが既存バージョンに対して署名アイデンティティの規則を満たしていることを確認する必要があります。無関係な証明書で署名された改変パッケージは通常、公式バージョンを直接上書きできず、公式アプリのアンインストール、パッケージ名の変更、あるいはユーザーを別環境でのインストールへ誘導するなどの手順が必要になります。
これが、リパッケージングテストにおいて新規インストールと上書きアップグレードの両方を実行しなければならない理由です。新規インストールのみをテストすると署名の継続性チェックが見落とされ、上書きアップグレードのみをテストすると、異なるパッケージ名やアンインストール・再インストールサイクルを介して偽装パッケージが端末に侵入する経路が見落とされます。両シナリオの結果は別途記録する必要があります。
署名のローテーションと Play アプリ署名はリリースチェーンに複雑さを加えます。チームは現在および過去に許可された証明書 ID、ローテーションルール、アップロード鍵とアプリ署名鍵の責任範囲を維持する必要があります。サーバー側ポリシーは配信手法に一致するデータを使用しなければなりません。開発用証明書、アップロード用証明書、最終配布用証明書を単一のフィールドで混同してはなりません。
- 現行のライブバージョンからオーバーレイアップグレードを実行する
- アンインストール後にクリーンインストールを実施する
- パッケージ名の変更とデータディレクトリへの影響を確認する
- 配信プラットフォームのルールに対して証明書ローテーションを検証する
再パッケージングのガバナンスは最終アーティファクトの ID 特定から開始しなければならない
チームはビルド番号のみを保存し、最終 APK のファイルダイジェストや署名証明書ダイジェストの記録をおろそかにしがちです。チャネルリソースの注入、再調整、再署名、またはパッケージ最適化により、最終ファイルが変更される可能性があります。セキュリティスキャンがチャネル適用前のアーティファクトを分析した場合、ライブユーザーが受信するファイルは同じ証拠によってカバーされません。
すべてのリリース候補に対して、パッケージ名、versionCode、versionName、ファイル SHA-256、証明書 SHA-256、署名スキーム検証結果、ビルド元、チャネル、処理順序、生成タイムスタンプを含む、曖昧さのないアーティファクト記録の生成を推奨します。静的チェック、インストールアップグレード、機能回帰テスト、およびサーバー側の許可ルールはすべてこの記録を参照すべきです。
ファイルダイジェスト自体は保護措置ではありません。その価値は、ワークフロー中にテスト対象が黙って変更されるのを防ぐことにあります。ダイジェスト、署名、またはチャネルシーケンスの任何の変化は新しいリリース候補を示しており、影響を受けるゲートの再実行が必要です。
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 サービスのステータス、または設定により、特定のシグナルが利用できない場合があると明記されています。適切なアプローチは、「利用不可」「失敗」「高リスク」の状態を個別にモデル化し、機能低下時の戦略、二次検証、権限制限、または拒否への対策を準備することです。
Google Play 以外での配布シナリオにおいて、Play 専用シグナルを単純に流用することはできません。企業配布、国内チャネル、プライベート配信では、バージョンのホワイトリスト、証明書との紐付け、アップグレード機制、および異常処理手順を独自に確立する必要があります。プラットフォームシグナルは証拠の一部であり、全チャネルに通用する万能の解答ではありません。
| 入力 | 検証方法 | 取り得る状態 | 推奨アクション |
|---|---|---|---|
| バージョンとパッケージ名 | リリース台帳およびチャネルルールとの照合 | 許可済み、有効期限切れ、不明 | 許可、アップグレード促通、高リスク機能の制限 |
| アプリケーション認識シグナル | プラットフォームが返す署名およびアプリケーション識別結果の検証 | 識別済み、未識別、利用不可 | 通常処理、チャレンジまたは制限、チャネルに応じた機能低下（デグラデーション） |
| アカウントとライセンス | サーバーサイドのアカウント権限および配布ライセンス | 有効、有効期限切れ、異常 | リソース範囲に基づき認可または拒否 |
| リクエスト行動 | レート、リプレイ攻撃、デバイス変更、ビジネスコンテキスト | 正常、疑わしい、高リスク | ログ記録、二次検証、レート制限、またはブロック |
| デバイスと環境 | プラットフォームの判定結果および独自リスクルール | 満たされている、シグナル弱、不明 | 単一点での絶対判断ではなく、リスク段階評価を実施 |
誤ったリリース順序による事前チェックの無効化
最終署名後に DEX、リソース、またはマニフェストを変更すると、署名がカバーする内容が破損します。スキャン後に再ビルドまたは再署名を行うと、スキャン結論と最終ファイルとの整合性が失われます。チャネル処理ツールでパッケージ本体の変更が必要な場合は、最終署名前に完了させ、その順序をアーティファクト台帳で固定する必要があります。
AAB 配信では、アップロードされたアーティファクトとユーザー端末が受信する分割 APK を明確に区別します。チームは配信プラットフォームから実際に配信されたアーティファクトをダウンロードまたは入手し、スポットチェックを実施して、パッケージ名、バージョン、署名 ID、主要リソースがリリース記録と一致することを確認する必要があります。ローカルで生成された汎用 APK は、すべての端末構成を自動的に代表するものではありません。
ロールバックパッケージも、同じ署名およびアップグレード検証を受ける必要があります。インシデント発生時に旧ファイルを一時的に再署名しても、バージョン番号、署名、またはデータ移行要件の不一致により、オーバーレイインストールに失敗する可能性があります。
| ステージ | 入力 | 出力証拠 | 主な失敗条件 |
|---|---|---|---|
| リリースビルド | 固定化されたソースコードと依存関係 | ビルド記録とベースアーティファクト | 依存関係または設定の再現性が確保されていない |
| ハードニング処理 | 明示的な保護設定 | 設定バージョンと候補アーティファクト | 処理対象がターゲットバージョンと一致しない |
| チャネル処理 | チャネルリソースとコンプライアンス情報 | チャネル候補アーティファクト | 署名後にコンテンツが改変された |
| 最終署名 | 管理された鍵と最終パッケージ本体 | 証明書ダイジェストと署名検証結果 | 誤った鍵または環境の使用 |
| 受入リリース | 固有の最終ファイル | インストール、アップグレード、ビジネス、およびサーバー側ゲート | 受入済みオブジェクトが他のファイルに置き換えられた |
再パッケージ化リスクが公開可能な管理下にあると判断する方法
公開可能な結論とは、改変されたパッケージが決してインストールできないことを意味するわけではありません。公式アーティファクトの ID が追跡可能であり、異常なアーティファクトが公式バージョンを静かにオーバーレイできず、サーバーが信頼できないクライアントを識別または制限でき、ユーザーが正規バージョンを入手して復旧する経路を持ち、チームが最終配信ファイルを監査できる状態を指します。
テストでは、成功パスと失敗パスの両方の証拠を保持する必要があります。成功パスには、公式バージョンの通常のインストール・アップグレード、ログイン、主要なビジネスフローが含まれます。異常パスには、無関係な証明書によるオーバーレイアップグレード、不明なバージョンによる高リスクインターフェースへのアクセス、期限切れバージョン、整合性シグナルの欠如、および誤検知からの復旧が含まれます。拒否のみを検証し復旧プロセスを欠くと、実際のユーザーが解決不能な状態に陥ることになります。
本記事は、いかなるハードニング技術単独でも再署名済みインストールを完全に防止できると主張するものではありません。リパッケージング対策は、署名管理、アップグレード制御、アーティファクト管理、クライアントの回復力、プラットフォームシグナル、およびサーバー側ポリシーが連携して実施するシステムエンジニアリングの取り組みです。
- 公式アーティファクトのアイデンティティは独立して監査可能です
- 異常な証明書が公式インストールを静かに上書きすることはありません
- サーバーには未知のクライアントに対する段階的ポリシーが用意されています
- ユーザーは信頼されたリリースチャネルへ復旧できます
- ロールバック用パッケージは事前にアップグレード検証を完了しています
証拠と適用可能性の境界
このセクションでは、文書化されたプラットフォームの事実、技術的な判断、および未検証の製品主張に一般化できない制限を分けて説明します。
| 条文判決 | 事実または工学的根拠 | 適用制限 |
|---|---|---|
| 再署名済みパッケージのインストール可能性は、公式パブリッシャーのアイデンティティと同等ではありません。 | Android では APK に検証可能な署名が必要ですが、攻撃者は改変されたコンテンツに対して自らの鍵を用いて整合性の取れた署名を生成できます。 | インストール可否はパッケージ名、デバイスポリシー、OS バージョン、インストールソースにも影響されるため、設計原則のみから特定のサンプル結果を推測することはできません。 |
| オーバーレイアップグレードでは、署名アイデンティティの連続性を検証する必要があります。 | Android 公式ドキュメントによれば、プラットフォームはアプリ署名鍵を用いて、更新が同一の鍵保有者から提供されたことを確認します。 | 証明書のローテーションと配布プラットフォームの署名ルールは、プロジェクト構成に従って検証する必要があります。 |
| プラットフォーム整合性シグナルはバックエンドで検証し、適切に処理する必要があります。 | Play Integrity の判定結果にはアプリケーション認識、デバイス、アカウント、環境情報が含まれており、公式にはリスクに基づいたバックエンドでの応答を推奨しています。 | Play シグナルはすべての国、チャネル、デバイス、またはオフラインシナリオを網羅しているわけではありません。 |
| 最終配信ファイルはテスト証拠と一対一で対応している必要があります。 | 再ビルド、リソースの改変、または再署名を行うと、アーティファクトのアイデンティティと潜在的なランタイム動作が変化します。 | ファイルダイジェストはアイデンティティの紐付けを確立しますが、それ自体には改ざん防止機能はありません。 |
| インストール失敗だけでは、リパッケージングに関するリスクが解消された証明にはなりません。 | 異常なパッケージは、パッケージ名の変更、アンインストールと再インストールの繰り返し、他のチャネルの利用、あるいはサーバー側バージョンポリシーの不備を悪用することで、依然としてリスクをもたらす可能性があります。 | 具体的な攻撃経路は、実際の配布およびビジネスアーキテクチャに対し、許可されたテスト範囲内で検証する必要があります。 |
エンジニアリングに関する質問
なぜシステムは非公式証明書で署名されたすべての APK を直接拒否しないのですか？
Android インストーラーは現在のパッケージ署名の自己整合性を検証できますが、各ブランドがどの証明書を信頼するかはシステム側では把握できません。正式なアイデンティティは、アップグレードチェーン、配信プラットフォーム、およびビジネスサービスによって共同で決定する必要があります。
再署名済みパッケージの上書きアップデートができない場合、リスクはないのでしょうか。
いいえ。攻撃者はアンインストールと再インストールのサイクルを誘発したり、パッケージ名を変更したり、サーバー側のバージョンポリシーの不備を悪用してビジネスロジックにアクセスする可能性があります。上書きアップデートの防止は、ガバナンスマトリックスにおける単なる一項目に過ぎません。
クライアントが自身の証明書ダイジェストを読み取るだけで十分でしょうか。
いいえ。改ざんされたクライアントは、ローカルチェックや報告ロジックも同時に変更する可能性があります。証明書情報は多層防御の一環として機能しますが、高リスクな認可判断は、検証可能なシグナルを組み合わせてサーバー側で行うべきです。
AAB リリース後、どのファイルダイジェストを保存すべきですか。
アップロードされた AAB の識別情報を保存し、さらに配信プラットフォームから実際に配信されたアーティファクトを取得してスポットチェックを実施してください。デバイスによっては分割 APK が配信される可能性があるため、ローカルで生成された汎用的な APK だけを保存するのは不十分です。
いつリリース結論を下すことができますか。
最終的な署名済みアーティファクトの識別情報が確定し、インストール、現行バージョンからのアップグレード、主要なビジネスフロー、サーバー側ポリシー、対象 OS 範囲、およびロールバック検証がすべて完了した後でなければ、対象範囲に対する結論を下すことはできません。
独自のアプリでこれをテストしてみませんか?
Yudun PoC と互換性評価のために、リリース候補、ターゲット システム、重要なビジネス パスを提出します。