Android OS の信頼性をさらに高めるため、Google Play 経由でアップデートとして提供されるすべての Android OS モジュール（Mainline と呼ばれます）を透明性ログに記載することに取り組んでいます。Google は、これらのモジュールに関する主張を検証するために透明性ログを公開しています。インストール済みのモジュールは、Google Pixel バイナリの透明性ですでにカバーされているため、明示的にリストされていません。
脅威モデル
透明性システムは、サプライ チェーン攻撃を検出して阻止するために使用できます。例をいくつか示します。
攻撃者が Mainline モジュール（APEX または APK ファイル）を悪意を持って変更し、Google Play を介した配布に使用される署名鍵で署名することに成功したとします。疑わしいモジュールを受け取ったユーザーは、バイナリ透過性ログをクエリして、モジュールの信頼性を確認できます。Google が対応するモジュール メタデータをログに追加していないことがわかるため、侵害された OS モジュールを信頼しないようにします。
ログへの公開は署名付きのリリース プロセスとは別のプロセスであるため、攻撃者がキーを不正使用するだけでなく、さらにハードルが上がります。
このログを標準の証人プロトコルを使用して証人のパブリック ネットワークに統合することも計画していますが、外部の独立した当事者がこの一般公開されているログの完全性を監視することをおすすめします。これらのパーティは、ログの追記専用プロパティを証明し、改ざんを報告できます。
このような透明性システムが存在し、攻撃の検出可能性が高まることで、悪意のあるアクティビティが抑制されます。OS モジュールが侵害されても、ユーザーがログに記録されているモジュールのみを信頼している場合、侵害されたモジュールを公開する必要があります。これにより、不正使用されたモジュールが存在することが判明する可能性が高まり、その配布を削除する措置を講じることができます。
請求者モデル
クレーム元モデルは、検証可能なシステムでロールとアーティファクトを定義するために使用されるフレームワークです。Android Mainline モジュールの透明性の場合、このログに記録されたモジュール ファイルのハッシュは、一般公開を目的とした公式の Android モジュールの特定のバージョンを表すという主張をします。
- MainlineModule を要求します（I, Google, claim that
$hashModuleis for$mainlineModule）。ここで、
$mainlineModule のコピーがあれば、誰でもこの申し立てを確認できます。このプロセスの詳細な手順については、確認ページをご覧ください。これらの手順は、通常の APK と Mainline モジュール（APK ファイルまたは APEX ファイル）の両方に適用されます。
ログの内容
Google が新しいバージョンの Mainline モジュールをリリースすると、対応するエントリが Mainline モジュール透明性ログに追加されます。
このログの各エントリには、次の 4 つのメタデータが含まれています。
- 署名付き Android Mainline モジュールの APK または APEX のハッシュ。これは、ファイル全体の SHA256 ダイジェストの 16 進文字列です。
- 上記のハッシュのタイプの説明。これは文字列です。
- モジュールのパッケージ名。これは文字列です。
- モジュールのバージョン番号（versionCode）。これはゼロ以外の整数です。
ログエントリの形式は、次の例に示すように、4 つの情報を改行（\n）文字で連結したものです。
hash\nhash_description\npackage_name\npackage_version\n
Mainline モジュールは APK ファイルまたは APEX ファイルのいずれかであるため、ハッシュの説明は SHA256(APK) または SHA256(APEX) のいずれかになります。