Transparansi Modul Mainline Android

Untuk lebih meningkatkan kepercayaan pada Android OS, kami berkomitmen untuk mencantumkan setiap modul Android OS (disebut Mainline) yang ditawarkan sebagai update via Google Play di log transparansi kami. Kami memublikasikan log transparansi untuk memverifikasi klaim yang kami buat tentang modul ini. Modul yang telah diinstal sebelumnya tidak dicantumkan secara eksplisit karena sudah tercakup dalam Transparansi Biner Pixel.

Model Ancaman

Sistem transparansi dapat digunakan untuk mendeteksi dan dengan demikian mencegah serangan rantai pasokan. Kami akan memberikan beberapa contoh.

Misalnya, penyerang mengubah modul Mainline secara berbahaya (yang dapat berupa file APEX atau APK) dan bahkan berhasil menandatanganinya dengan kunci penandatanganan yang digunakan untuk distribusi melalui Google Play. Siapa pun yang menerima modul yang dipertanyakan dapat membuat kueri log transparansi biner untuk memverifikasi keaslian modul. Mereka akan menemukan bahwa Google belum menambahkan metadata modul yang sesuai ke log dan akan tahu untuk tidak mempercayai modul OS yang disusupi.

Karena publikasi ke log adalah proses yang terpisah dari proses rilis dengan penandatanganan, hal ini meningkatkan standar bagi penyerang di luar sekadar membahayakan kunci.

Meskipun kami berencana untuk mengintegrasikan log ini ke dalam jaringan saksi publik menggunakan protokol saksi standar, kami mendorong pihak eksternal dan independen untuk memantau integritas log yang tersedia secara publik ini. Pihak-pihak ini dapat membuktikan properti log yang hanya dapat ditambahkan, dan melaporkan setiap upaya perusakan.

Keberadaan sistem transparansi tersebut dan penemuan serangan tambahan akan mencegah aktivitas berbahaya. Jika modul OS disusupi, tetapi pengguna hanya mempercayai modul yang ada di log, modul yang disusupi harus diekspos secara publik. Hal ini meningkatkan kemungkinan penemuan bahwa modul yang disusupi ada, dan tindakan dapat diambil untuk menghapus distribusinya.

Model Penggugat

Model Penggugat adalah framework yang digunakan untuk menentukan peran dan artefak dalam sistem yang dapat diverifikasi. Dalam kasus Transparansi Modul Mainline Android, klaim yang kami buat adalah bahwa hash file modul yang tercatat dalam log ini mewakili versi tertentu dari modul Android resmi yang dimaksudkan untuk konsumsi publik.

  • ClaimMainlineModule: (Saya, Google, mengklaim bahwa $hashModule adalah untuk $mainlineModule), dengan:
    • $hashModule adalah hash kriptografi (misalnya SHA256) dari file modul OS dari versi tertentu $mainlineModule.
    • $mainlineModule adalah APEX atau paket Android (APK) yang membentuk modul OS yang dibuat, ditandatangani, dan didistribusikan oleh Google.

Siapa pun yang memiliki salinan $mainlineModule dapat memverifikasi klaim ini. Halaman verifikasi memberikan petunjuk mendetail untuk proses ini. Langkah-langkah ini berlaku untuk APK reguler dan modul Mainline (yang dapat berupa file APK atau APEX).

Konten Log

Saat Google merilis versi baru modul Mainline, Google akan menambahkan entri yang sesuai ke Log Transparansi Modul Mainline.

Setiap entri dalam log ini berisi empat bagian metadata:

  1. Hash APK atau APEX dari modul Mainline Android yang ditandatangani. Ini adalah string heksadesimal dari ringkasan SHA256 dari seluruh file.
  2. Deskripsi jenis hash di atas. Ini adalah string.
  3. Nama paket modul. Ini adalah string.
  4. Nomor versi (versionCode) modul. Ini adalah bilangan bulat bukan nol.

Format entri log adalah gabungan dari empat bagian informasi dengan karakter baris baru (\n), seperti yang diilustrasikan oleh hal berikut:

hash\nhash_description\npackage_name\npackage_version\n

Karena modul mainline dapat berupa file APK atau APEX, deskripsi hash dapat berupa SHA256(APK) atau SHA256(APEX).