フォレンジックの結果は、データベースやアルゴリズムの名前だけでなく、端末と鍵の実際の状態に左右されます。
エンドツーエンド暗号化とローカルデータの保護は、関連はあっても異なる問題です。ネットワーク上で保護されたメッセージも、端末で表示するには読める状態にする必要があります。フォレンジック調査の結果は、端末の状態、アクセスの種類、OS とアプリのバージョン、鍵の所在に左右されます。アルゴリズムの名前だけで結果は決まりません。
そのため、「物理的に触れられれば全てすぐ読める」という主張にも、「抽出は絶対に不可能」という約束にも慎重さが必要です。
四つの保護層を別々に確認しましょう
| 層 | 主な役割 | 重要な限界 |
|---|---|---|
| メッセージの E2EE | 参加者の端末間で内容を保護する | 端末の健全性やローカルコピーの保護は保証しない |
| アプリの分離 | 通常のアプリによる相互のデータアクセスを制限する | 高い権限のアクセスや脆弱性によってモデルが変わり得る |
| ファイルまたはディスクの暗号化 | 特定の条件下で保存データを保護する | ロック状態と鍵の利用可能性が重要 |
| アプリ内のデータベース暗号化 | データベースファイルに追加の境界を設ける | 鍵の保存方法と使用方法が決定的 |
Android の FBE 文書は、ユーザーの認証情報に依存する領域と Direct Boot で利用できる領域を区別しています。「端末がロックされている」だけでは全ての鍵の状態は分かりません。起動後に初めてロック解除する前か後かも重要な場合があります。
SQLite ファイルは何を証明するのでしょうか？
SQLite は保存形式とエンジンであり、全ての保護の有無を単独で示すラベルではありません。ファイルは OS の暗号化領域内にある場合も、別の仕組みで保護されている場合もあります。
また、一行を削除しても、全てのファイルからその痕跡が全て消えるとは限りません。SQLite の文書は、安全な削除の設定と仮想テーブルの制限を説明しています。データのライフサイクルを調べる際には、補助ファイルとバックアップも考慮する必要があります。これは、どの端末でも削除済みメッセージを全て復元できるという保証ではありません。
アプリを理解せずに、実データへデータベース保守コマンドを実行しないでください。アプリのファイルを直接変更すると、データが壊れたり証拠が変わったりする可能性があります。
SQLCipher と Keystore は手段であり、無敵の証明ではありません
SQLCipher は透過的なデータベース暗号化のためのものですが、仕様はバージョンと併せて読む必要があります。SQLCipher の設計ページは認証を伴う AES-CBC 構造を説明していますが、2026 年 9 月のバージョン 5 ベータの紹介では AES-GCM への変更を説明しています。一つの暗号モードを全バージョンに当てはめるのは正確ではありません。
Android Keystore も鍵の保護と使用制御を提供できますが、アプリが実際にどの機能とハードウェアレベルを使っているかを明らかにする必要があります。記事に StrongBox と書かれているだけでは、製品が使っている証拠にはなりません。Keystore ガイドを参照してください。
抽出できない鍵でも、条件によっては許可された操作を通じて使用できる場合があります。「鍵をコピーできない」と「攻撃者は何のデータも復号できない」は同じ主張ではありません。
RAM とラチェットは何をするのでしょうか？
鍵や機微な平文の生存期間を短くすると、漏えいの機会を減らせます。ただし、一つのバッファーを消去しても、ライブラリー、プレビュー、表示処理に他のコピーが残っていないとは証明できません。
ラチェットの効果範囲も、漏えいした鍵の種類と攻撃者のアクセスが続いているかによって異なります。「メッセージごとに別の鍵」から、一度のメモリー取得で漏れるのは最大一通と結論づけることはできません。端末上の読める履歴の保存は、伝送用の鍵とは別の問題です。
Livara について何が確認されていないのでしょうか？
Livara の脅威モデルは、感染した端末やロック解除済み端末の保護を保証していません。本記事は、特定バージョンの Livara による SQLCipher や StrongBox の使用、RAM の完全な消去、ローカル通話データの不在を独立に確認していません。試験報告と実装の証拠なしに、これらを製品の特性として述べるべきではありません。
また、セキュリティ文書の ID 復元パッケージは、履歴のバックアップとは異なります。Proof Lab で APK のハッシュを確認すれば、ファイルが信頼するハッシュと一致するかを示せます。その結果は、保存方式の監査やフォレンジック耐性試験ではありません。
信頼できるフォレンジックの主張にはどんな情報が必要でしょうか？
端末モデル、OS とアプリのバージョン、ロック状態、アクセス方法と権限レベル、取得したデータの種類、試験の限界を求めてください。一つのツールが一度の試験で失敗しても、全ての方法が不可能な証拠にはなりません。限定的な成功も、全利用者へ一般化してよい理由にはなりません。
一般の利用者には、更新、強いロック、余分なメディアコピーの削減、復元手段の保護が優先事項です。重大な事案では、データや証拠を変える行動を取る前に、権限を持つ専門家の支援を受けてください。
