GoogleのAndroidアプリ公開検証は署名済みの別物を見つける仕組み

TL;DR

対象 2026年5月1日以降にリリースされたGoogle製Androidアプリ、Google Play Services、Android Mainlineモジュール

変化 Googleの署名に加えて、公開された透明性ログ上のSHA-256、パッケージ名、versionCodeで本番リリースか検証可能

限界対象はGoogle製ソフトウェアのみ。更新前のAPK、他社アプリ、端末メーカー独自アプリまではそのまま広がらない

GoogleがAndroid向けのBinary Transparencyを広げた。
対象はGoogle製アプリとAndroid Mainlineモジュールで、2026年5月1日以降の本番リリースには公開ログ上の暗号学的な記録が付く。
The Hacker Newsの記事はサプライチェーン攻撃対策として紹介していたが、元になっているGoogle公式ブログとDevelopersの検証ページを読むと、狙いは「署名されているから正規品」と見る癖を1段ずらすところにある。

アプリにGoogleの署名が付いていても、それだけでは「Googleがそのバイナリを本番配布するつもりだった」ことまでは分からない。
署名鍵の悪用、内部ビルドの流出、リリース経路の汚染が起きた場合、署名は通ってしまう。
今回の公開検証は、そのAPKやAPEXがGoogleの本番リリースとして公開ログに載っているかを見る。

署名は出自、公開ログはリリース意図を見る

Googleの説明で一番大きいのは、署名とBinary Transparencyの役割を分けている点だ。
署名は「この鍵で作られたもの」を示す。
公開ログは「このハッシュのバイナリをGoogleが本番リリースとして扱った」ことを、後から第三者が検証できる形で残す。

透明性ログは追記専用で、Merkle tree（ハッシュ値の木構造で履歴全体の一貫性を検証する仕組み）を使って改ざん検出できる構造になっている。
ログ内のエントリにはAPK全体のSHA-256、ハッシュ種別、パッケージ名、versionCodeが入る。
端末からAPKを取り出して同じ情報を作り、ログの包含証明（あるエントリがログ内に存在することの暗号学的な証拠）を確認すれば、そのファイルが公開ログに含まれるか判断できる。

この差分は地味だけど効きどころが違う。
たとえば攻撃者が署名鍵を使えたとしても、公開ログに載らない一回限りのAPKを配布すれば、そのズレは検出対象になる。
逆にログに載っていないGoogle署名アプリは、Googleが本番ソフトウェアとしてリリースしたものではない、という判断材料になる。

対象はGoogleアプリとMainlineから始まる

今回の拡大で対象に入るのは、Google Play Servicesを含むGoogle製アプリと、OSの一部として動的更新されるMainlineモジュールだ。
Pixelのシステムイメージ向けには以前からPixel Binary Transparencyがあり、今回の発表はアプリ層とMainline層へ広げる動きになる。

Androidのセキュリティ更新は、端末メーカーのOTAだけで完結しない。
MainlineモジュールやGoogle Play system updateでOS部品が後から更新されるし、Google Play Servicesは多くの端末で基盤機能を担う。
直近ではWireless ADBのCVE-2026-0073のようにMainline側の更新日付も確認対象になるケースがあり、Androidでは「どの層が、どの経路で、いつ更新されたか」を見る必要がある。

ただし、これでAndroidアプリ全体が検証可能になったわけではない。
Google Developersのページでも、Google 1st Party Apps Transparencyとして扱われているのはGoogle製APKだ。
サードパーティアプリ、端末メーカーの独自アプリ、2026年5月1日より前に最後の更新が止まっているアプリは、このログだけでは判断できない。

検証ツールは研究者向けの温度感

Googleは android/android-binary-transparency リポジトリで検証用コードを公開している。
ただ、利用手順は一般ユーザーがスマホ上でワンタップ確認するようなものではない。

Google Play Servicesの例では、ADBで端末からAPKとsplit APKを取り出し、aapt2 でパッケージ名とversionCodeを読み、sha256sum でAPKごとのハッシュを計算し、ログ検証ツールに渡す。
split APKは端末構成によって数が変わるため、base APKだけ見れば終わりではない。

ここは実用面で誤読しやすい。
Googleが「誰でも検証できる」と言うと、ユーザー保護機能が端末UIに入ったように見えるが、現時点で見えているのは研究者、企業のモバイル管理担当、フォレンジック（デジタル証拠の調査・分析）担当が不審なAPKを調べるための道具だ。
日常的な防御としては、Google Play Protectや端末更新とは別レイヤーにある。

サプライチェーン攻撃への効き方は限定的だが現実的

このブログでは最近、npmやIDE拡張機能を狙うサプライチェーン攻撃を何度も追っている。
偽Strapiプラグインのnpm攻撃はパッケージ公開経路そのものを悪用し、GlassWormのIDE横断感染は信頼されがちな開発ツール拡張にネイティブバイナリを混ぜていた。
どちらも「インストール元がそれっぽい」「署名や配布経路が一見正しい」だけでは足りない例だ。

AndroidのBinary Transparencyは、こうした攻撃全部を止める仕組みではない。
偽パッケージ名、悪意あるサードパーティアプリ、ユーザーが別経路から入れた野良APKをまとめて判定するものでもない。
効くのは、Google製ソフトウェアについて「このハッシュはGoogleが本番として公開したものか」を外部から確かめる場面だ。

それでも、署名済みバイナリを盲信しないための公開基盤としては意味がある。
CI/CDやパッケージレジストリでも、GitHub Actionsの2026年セキュリティロードマップが依存関係ロックや実行テレメトリを入れようとしていた。
配布物の内容と意図を後から検証できるようにする流れは、モバイルOSだけの話ではなくなっている。

まだ見えていない部分

気になるのは、ログ監視がどれだけ外部に根付くかだ。
Google Developersの検証ページでは、将来的に公開 witness network へ統合する計画が触れられている。
witnessはログのチェックポイントを外部から継続的に確認し、ログ運営者だけで過去を書き換えられないようにする役割を持つ。

現時点では、検証ツールとログが公開された段階に近い。
企業MDM（モバイル端末管理）、Androidセキュリティ製品、研究者コミュニティがこれをどの程度自動監視に組み込むかで、実際の検出力は変わる。
Googleが自社アプリから始めたのは妥当だが、Androidエコシステム全体のサプライチェーン検証として見るなら、他社アプリやOEM更新に同じ考え方が広がるかが次の焦点になる。