チェックサムはバイト列を参照値と照合します。署名は完全性を鍵に結びつけます。どちらも単独ではソフトウェアの安全性を証明しません。
Android の APK をインストールする前に、次の 3 つの確認を区別してください。このファイルは想定したリリースと一致するか。想定した鍵で署名されているか。独立したビルド実施者が、明示されたソースから同じ成果物を再現できるか。 SHA-256 チェックサム、APK 署名、再現可能なビルドは、それぞれ異なる形でこれらの問いに答えます。
いずれも、単独でマルウェアかどうかを判定するものではありません。正しく署名され、ビルドを再現できるプログラムでも、セキュリティ上の不具合や意図的な有害動作を含むことがあります。
それぞれの検証方法で確認できること
| 確認方法 | 得られる有用な結果 | 重要な限界 |
|---|---|---|
| ファイルの SHA-256 ダイジェスト | 手元のバイト列が、特定の信頼できるダイジェストと一致する | 攻撃者がファイルとダイジェストの両方を置き換えられる場合、この比較をすり抜けられる |
| APK 署名の検証 | パッケージの署名が、その署名証明書による検証に成功する | 想定される署名鍵を特定する必要がある。有効であることだけでは、発行者の身元は確認できない |
| 再現可能なビルドの比較 | 文書化された入力から、指定の成果物を再作成できる | ソースとバイナリの一致は、ソースの安全性を証明しない |
| セキュリティレビュー | 特定の設計または実装上の問題が評価されている | 対象範囲、バージョン、指摘事項、未解決の問題を確認する必要がある |
Android では、インストールと更新に APK の署名が必要です。Play App Signing では、Google がアプリ署名鍵を管理し、アプリバンドルから配布用 APK を生成できます。これは文書化された信頼の仕組みであり、任意の仲介者が有効な署名を保ったままパッケージを密かに改変できる証拠ではありません。Android のアプリ署名ガイドを参照してください。
ステップ 1：確認する成果物を正確に特定する
アプリのバージョン、リリースチャネル、ファイル名、対象プラットフォームの種類を記録します。頼んでもいないのに APK が送られてきたメッセージに記載されたチェックサムを使うのではなく、発行者の公式配布ページを使用してください。
発行者から直接ダウンロードした APK は、アプリストアが特定の端末向けに生成した APK と異なる場合があります。バージョン、アーキテクチャ、パッケージング、署名の仕組みが違えば、正当な理由でファイルのハッシュ値が異なることがあります。不一致を改ざんの証拠とみなす前に、同じ条件の成果物同士を比較していることを確認してください。
実際に問うべきなのは、「期待値はどこから得たのか。その情報源をなぜ信頼するのか」です。ハッシュをオフラインで計算しても、オンラインで入手したダイジェストの信頼性の問題は解決しません。
ステップ 2：SHA-256 をローカルで計算する
messenger.apk を、ダウンロードしたファイルの名前に置き換えます。以下の例はファイルを読み取るだけで、インストールは行いません。
Linux：
sha256sum messenger.apk
macOS：
shasum -a 256 messenger.apk
Windows のコマンドプロンプト：
certutil -hashfile messenger.apk SHA256
表示上の空白と英字の大文字・小文字の違いだけを無視し、ダイジェスト全体を比較してください。先頭や末尾の数文字だけで比較しないでください。同じ比較を繰り返せるよう、期待するダイジェストは対応するリリース・バージョン情報と一緒に保存します。
値が異なる場合は、インストール前に作業を止めてください。成果物とバージョンを確認し、必要に応じて信頼できる配布元から再度ダウンロードし、説明のつかない不一致について発行者に問い合わせてください。たまたま受け取ったファイルに合わせて、期待するチェックサムを「修正」してはいけません。
ステップ 3：APK の署名を確認する
Android SDK Build Tools を利用できる場合、Google の apksigner のドキュメントに署名の検証方法と証明書情報の出力方法が説明されています。
apksigner verify --verbose --print-certs messenger.apk
APK がサポートするプラットフォームについて、検証が成功する必要があります。署名者の証明書情報を、信頼できるリリース記録、または発行者が文書化した署名鍵の継承履歴と比較してください。見慣れない鍵による署名が、「検証済み」という言葉だけで信頼できるものになるわけではありません。正当な署名鍵のローテーションにも根拠が必要であり、不一致を無視するよう指示するだけでは不十分です。
APK ファイルの SHA-256 ダイジェストと、署名証明書の SHA-256 フィンガープリントは別の値です。一方を他方と比較しないでください。
ステップ 4：再現可能なビルドの根拠を探す
ビルドが再現可能であると主張するには、ソースのリビジョン、ビルド環境、手順、対象成果物を定義する必要があります。独立した第三者が、その成果物を再作成して結果を比較できなければなりません。Reproducible Builds プロジェクトの定義でも、これらの入力は主張の一部とされています。
メッセンジャーの場合、有用なリリースの根拠には、ソースのタグ、固定された依存関係とツールチェーンのバージョン、ビルド手順、独立した比較結果などがあります。何を比較したのかを具体的に確認してください。署名前の成果物なのか、署名済み APK なのか、それともパッケージ内の一部の内容なのか。ソースコードとダウンロード用ファイルのハッシュが公開されているだけで、再現可能だと判断してはいけません。
再現可能性は、レビューされたソースと配布されるコードの対応関係を強めます。しかし、未レビューの実装を安全なプロトコルに変えるものでも、動作中のスマートフォンが侵害されていないことを証明するものでもありません。
Livara の Proof Lab の位置づけ
Livara の Proof Labでは、APK のハッシュをローカルで計算し、公開されているダイジェストと照合できます。そこでの暗号技術のデモンストレーションは、メッセージングプロトコル全体の監査よりも限定的なものです。想定するリリースや署名の情報と併せて、明示された目的のためにハッシュ検証を利用してください。再現可能なビルドやバックドアの不在を示す、独立した証明として扱わないでください。
脅威モデルには、APK と表示されるダイジェストの両方が置き換えられる場合の限界が明記されています。だからこそ、参照値の出所は、計算を正しく実行することと同じくらい重要です。
よくある質問
チェックサムが一致すれば、APK は安全だと証明できますか？
いいえ。信頼できる参照値とハッシュ関数の安全性を前提として、参照ダイジェストとの一致を確認できるだけです。プログラムの動作を評価するものではありません。
チェックサムが一致していれば、署名の検証は不要ですか？
いいえ。両者が提供する根拠は異なります。署名はパッケージの完全性を鍵に結びつけ、ファイルのダイジェストは特定のバイト列を識別します。
ストアからのダウンロードは、ウェブサイトの APK ハッシュと一致する必要がありますか？
同じ成果物であるはずの場合に限ります。まずリリースチャネル、バージョン、パッケージングを確認してください。説明のつかない不一致は調査すべきですが、自動的に不正と決めつけたり、無条件で承認したりするべきではありません。
これらの確認で、すでにスマートフォンにあるスパイウェアを検出できますか？
いいえ。確認するのはインストール用の成果物であり、端末の現在の実行状態を構成するすべての要素ではありません。
