ハッシュ、署名、再現可能なビルド、監査は、それぞれ異なる問いに答えるものです。
オープンソースであればコードを調べられますが、それだけでは、インストール済みのアプリがそのコードと同じであることや、脆弱性が一切ないことは証明できません。メッセンジャーを評価する際は、ソースコード、ビルド手順、ファイル署名、プロトコルのテスト、監査報告書という複数の証拠を分けて考えるとよいでしょう。
それぞれの証拠は何を示す？
| 証拠 | 主な役割 | それだけでは証明できないこと |
|---|---|---|
| 読めるソースコード | 設計と実装を調べられる | インストールファイルとの一致や、すべてのバグの不在 |
| 再現可能なビルド | 指定のソースと環境から得た出力を比較できる | コード自体の安全性 |
| APK 署名 | 署名と、信頼する署名者の鍵へのファイルの結び付きを確認する | アプリの動作が無害であること |
| SHA-256 ハッシュ | 信頼するダイジェストとのバイトの違いを検出する | 攻撃者がファイルとダイジェストを両方差し替えた場合の真正性 |
| テストベクトル | 特定の入力と出力について、所定の動作を確認する | すべての状態と実行経路の網羅 |
| 独立監査 | 特定の範囲とバージョンを調べた結果 | 将来のすべてのバージョンへの恒久的な保証 |
再現可能なビルドと、ハッシュが一致するファイルのダウンロードは別物
Reproducible Builds の定義によれば、再現可能性とは、指定のソース、環境、手順から同一の出力をビルドできることです。ダウンロードしたファイルを開発者が公開したハッシュと比較しただけなら、それは完全性の確認です。まだ自分でコードからファイルをビルドしたわけではありません。
再現可能という主張を評価するには、コードのバージョン、依存関係、ビルド手順、別の人が結果を再現した報告を求めましょう。「ソースは GitHub にある」という言葉は、これらの証拠の代わりにはなりません。
APK の検証をどう正しく解釈する？
- 公式の経路から、特定バージョンのファイルを入手する。
- 真正性を信頼できる情報源から、ダイジェストと署名者の情報を得る。
- ファイルのハッシュを計算し、同じバージョンの情報と比較する。
- 技術的な確認では署名も検証する。公式ツール apksigner はこの検証に対応している。
- 不一致があればインストールを止めて原因を明らかにする。エラーを回避するためにファイルを再署名しない。
Android SDK Build Tools を持つ専門家向けの検証コマンド例：
apksigner verify --verbose --print-certs app.apk
app.apk という名前は単なる例です。コマンドが成功しても、発行者の正しい鍵を把握する必要はなくなりません。
Proof Lab の役割は？
Livara の Proof Lab は、特定の確認のためのツールを提供します。各実験の範囲を読んでください。ファイルのハッシュ、鍵合意の例、改ざんデータの拒否は、それぞれ別の問いです。暗号のデモが成功しても、インストール済みアプリ全体、サーバー、更新、アカウント管理の監査にはなりません。
Livara の脅威モデル も、攻撃者が APK ファイルと表示されるダイジェストを両方差し替えた場合、ハッシュの一致だけでは真正性を証明できないと明記しています。これはハッシュ検証全般の限界であり、特定のメッセンジャー固有の性質ではありません。
監査報告書を読むときに何を問う？
- どの組織または誰が調査し、公開報告書はどこにあるか？
- どのバージョンとコミットを調べたか？
- どの部分が対象範囲外だったか？
- 重要な指摘はどのように修正され、再テストされたか？
- 自分がインストールしたバージョンは同じものか、またはその修正を含んでいるか？
これらに答えがないまま、「承認済み」などの言葉から断定しないでください。標準アルゴリズムの使用も、製品全体が規格に基づく認証を受けたこととは同じではありません。
メッセンジャー選びへの結論
オープンソースと検証可能性は競合するものではなく、相互に補完する証拠です。主張が正確で追跡でき、適用範囲が明確な製品を選びましょう。そのうえで、グループ、ウェブ版、バックアップ、リンク済み端末など、自分が使う形態にも同じ検証を広げてください。1回のテスト成功から絶対的な安全性を導いてはいけません。
