Di Android 11, update OTA dapat diterapkan menggunakan update A/B atau mekanisme update A/B virtual, yang dikombinasikan dengan RecoverySystem metode class lainnya. Setelah perangkat dimulai ulang untuk menerapkan pembaruan OTA, Resume-on-Reboot (RoR) akan membuka penyimpanan yang Dienkripsi Kredensial (CE) perangkat.
Meskipun partner dapat memasangkan proses ini dengan fitur sistem OTA yang berlaku update saat perangkat diperkirakan tidak ada aktivitas di Android 11, di Partner Android 12 tidak memerlukan sistem OTA tambahan aplikasi baru. Proses RoR memberikan keamanan dan kenyamanan tambahan bagi pengguna karena update dapat dilakukan selama waktu tidak ada aktivitas perangkat, sedangkan Android 12 fungsi pembaruan berbasis server dan multiklien bersama-sama menyediakan keamanan jenis tingkat hardware.
Meskipun demikian Anda harus memberikan izin perangkat untuk android.hardware.reboot_escrow
untuk mendukung RoR di Android 11, Anda tidak perlu melakukannya untuk mengaktifkan
RoR berbasis server di Android 12 dan yang lebih tinggi, karena
jangan gunakan HAL.
Latar belakang
Mulai Android 7, Android mendukung Direct Boot, yang memungkinkan aplikasi pada perangkat untuk dimulai sebelum penyimpanan CE dibuka oleh pengguna. Implementasi dukungan Direct Boot memberikan pengalaman pengguna sebelum kunci harus dimasukkan dalam {i>Key Screen Knowledge Factor <i}(LSKF) setelah booting.
RoR memungkinkan penyimpanan CE semua aplikasi di perangkat untuk dibuka, termasuk komputer yang tidak mendukung Direct Boot, ketika {i>reboot<i} dimulai setelah update OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari semua aplikasi yang terinstal, setelah dimulai ulang.
Model ancaman
Implementasi RoR harus memastikan bahwa ketika perangkat jatuh ke dalam Namun, akan sangat sulit bagi penyerang untuk mendapatkan kembali kunci keamanan data terenkripsi, meskipun perangkat dinyalakan, penyimpanan CE tidak terkunci, dan perangkat dibuka kuncinya oleh pengguna setelah menerima update OTA. Orang dalam serangan terhadap serangan harus efektif bahkan jika penyerang mendapatkan akses ke kunci penandatanganan kriptografis broadcast.
Khususnya, penyimpanan CE tidak boleh dibaca oleh penyerang yang secara fisik perangkat serta memiliki kemampuan dan batasan berikut:
Kemampuan
- Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani pesan arbitrer.
- Dapat menyebabkan perangkat menerima update OTA.
- Dapat memodifikasi operasi perangkat keras apa pun (seperti prosesor aplikasi, atau memori flash) - kecuali seperti yang dijelaskan dalam Batasan di bawah. (Namun, modifikasi tersebut melibatkan penundaan setidaknya satu jam, dan {i>power cycle<i} yang menghancurkan isi RAM.)
Batasan
- Tidak dapat memodifikasi pengoperasian perangkat keras yang tahan perusakan (misalnya, Titan M).
- Tidak dapat membaca RAM perangkat aktif.
- Tidak dapat menebak kredensial pengguna (PIN, pola, sandi) atau penyebab lainnya mereka untuk dimasukkan.
Solusi
Sistem update RoR Android 12 memberikan keamanan terhadap penyerang yang sangat canggih, dan melakukannya saat menggunakan {i>password<i} dan PIN tetap berada di perangkat—PIN tidak pernah dikirim ke atau disimpan di server Google. Ini adalah ikhtisar dari proses yang memastikan tingkat keamanan yang diberikan mirip dengan sistem RoR tingkat perangkat berbasis perangkat keras:
- Android menerapkan perlindungan kriptografis pada data yang disimpan di perangkat.
- Semua data dilindungi oleh kunci yang disimpan di trusted execution environment (TEE).
- TEE hanya melepaskan tombol jika sistem operasi yang sedang berjalan lulus autentikasi kriptografi (booting terverifikasi).
- Layanan RoR yang berjalan di server Google mengamankan data CE dengan menyimpan yang dapat diambil untuk waktu yang terbatas. Hal ini berfungsi di seluruh ekosistem Android.
- Kunci kriptografis, yang dilindungi oleh PIN pengguna, digunakan untuk membuka kunci perangkat
dan membongkar enkripsi
penyimpanan CE.
- Saat mulai ulang semalam dijadwalkan, Android akan meminta pengguna untuk memasukkan PIN mereka, kemudian menghitung {i>password<i} sintetis (SP).
- Kemudian, metode ini mengenkripsi SP dua kali: sekali dengan kunci
K_syang disimpan dalam RAM, dan sekali lagi dengan kunciK_kyang disimpan di TEE. - SP terenkripsi ganda disimpan di {i>disk<i}, dan SP dihapus dari RAM. Kedua kunci baru dibuat dan digunakan untuk satu kali mulai ulang saja.
- Saat tiba waktunya untuk memulai ulang, Android akan mempercayakan
K_ske server. Tanda terima denganK_kdienkripsi sebelum disimpan di disk. - Setelah mulai ulang, Android menggunakan
K_kuntuk mendekripsi tanda terima, lalu mengirimkannya ke server untuk mengambilK_s.K_kdanK_sdigunakan untuk mendekripsi SP yang disimpan di disk.- Android menggunakan SP untuk membuka kunci penyimpanan CE dan memungkinkan startup aplikasi normal.
K_kdanK_sdihapus.
Update yang menjaga keamanan ponsel Anda dapat dilakukan pada waktu yang sesuai untuk Anda: saat Anda tidur.
Pemutaran ulang SIM-PIN
Dalam kondisi tertentu, kode PIN kartu SIM diverifikasi dari {i>cache<i}, proses yang disebut {i>replay<i} SIM-PIN.
Kartu SIM dengan PIN yang diaktifkan juga harus menjalani kode PIN yang lancar verifikasi (pemutaran ulang SIM-PIN) setelah reboot tanpa pengawasan untuk memulihkan data seluler konektivitas (diperlukan untuk panggilan telepon, pesan SMS, dan layanan data). PIN SIM dan informasi kartu SIM yang sesuai (ICCID dan slot SIM) nomor) disimpan dengan aman, bersama-sama. PIN yang disimpan dapat diambil dan digunakan untuk verifikasi hanya setelah {i>reboot <i}tanpa pengawasan berhasil. Jika perangkat aman, PIN SIM disimpan dengan kunci yang dilindungi oleh LSKF. Jika SIM memiliki PIN diaktifkan, interaksi dengan server RoR memerlukan koneksi Wi-Fi untuk pembaruan OTA dan RoR berbasis server, yang memastikan fungsionalitas dasar (dengan konektivitas seluler) setelah reboot.
PIN SIM dienkripsi ulang dan disimpan setiap kali pengguna berhasil mengaktifkan, memverifikasi, atau mengubahnya. PIN SIM akan dibuang jika salah satu hal berikut terjadi:
- SIM akan dikeluarkan atau direset.
- Pengguna menonaktifkan PIN.
- Telah terjadi {i>reboot <i}yang tidak dimulai oleh RoR.
PIN SIM yang disimpan hanya dapat digunakan satu kali setelah reboot yang dimulai oleh RoR, dan hanya untuk durasi waktu yang sangat singkat (20 detik)–jika detail SIM pencocokan kartu. PIN SIM yang disimpan tidak pernah keluar dari aplikasi TelephonyManager dan tidak dapat diambil oleh modul eksternal.
Panduan penerapan
Di Android 12, RoR berbasis server dan multiklien memberikan beban yang lebih ringan bagi partner saat mereka mendorong update OTA. Update yang diperlukan dapat terjadi selama periode nonaktif perangkat yang praktis, seperti selama jam tidur yang ditentukan.
Untuk memastikan bahwa pembaruan OTA selama jangka waktu tersebut tidak mengganggu pengguna,
menggunakan mode gelap untuk mengurangi emisi cahaya. Untuk melakukannya, siapkan perangkat
penelusuran bootloader untuk alasan string unattended. Jika unattended adalah true,
menyetel perangkat dalam mode gelap. Perhatikan bahwa setiap OEM bertanggung jawab untuk
memitigasi emisi suara dan cahaya.
Jika Anda mengupgrade ke Android 12 atau meluncurkan Perangkat Android 12, Anda tidak perlu melakukan apa pun untuk mengimplementasikan fungsi RoR yang baru.
Ada satu panggilan baru di alur multiklien, isPreparedForUnattendedUpdate,
yang ditampilkan di bawah ini:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Anda tidak perlu menerapkan ini, karena HAL tidak digunakan lagi mulai Android 12.
Pengelola Telepon
Klien OTA memanggil API sistem TelephonyManager saat mulai ulang akan segera terjadi
di Android 12. API ini memindahkan semua kode PIN yang di-cache dari
status AVAILABLE menjadi status REBOOT_READY. Sistem TelephonyManager
API dilindungi oleh REBOOT yang ada
Izin manifes.
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
API sistem TelephonyManager digunakan oleh APK dengan hak istimewa.
Pengujian
Untuk menguji API baru, jalankan perintah ini:
adb shell cmd phone unattended-reboot
Perintah ini hanya berfungsi jika shell berjalan sebagai root (adb root).
Khusus Android 11
Bagian selanjutnya dari halaman ini berlaku untuk Android 11.
Mulai Juli 2020, implementasi RoR HAL terbagi dalam dua kategori:
- Jika hardware SoC mendukung persistensi RAM meskipun proses mulai ulang, OEM dapat menggunakan implementasi default di AOSP (Escrow RAM Default).
- Jika perangkat keras perangkat atau SoC mendukung kantong
perangkat keras yang aman (sebuah
koprosesor keamanan dengan RAM dan ROM-nya sendiri),
berikut ini:
- Dapat mendeteksi mulai ulang CPU utama.
- Memiliki sumber timer hardware yang tetap ada meskipun telah dimulai ulang. Yaitu, enklave harus dapat mendeteksi {i>reboot<i} dan mengakhiri {i>timer<i} yang diatur sebelum memulai ulang.
- Mendukung penyimpanan kunci yang di-escrowed di dalam RAM/ROM enklave sehingga tidak dapat dapat dipulihkan dengan serangan offline. Kunci itu harus menyimpan kunci RoR sedemikian rupa sehingga membuat orang dalam atau penyerang tidak mungkin memulihkannya.
Dana jaminan RAM default
AOSP memiliki implementasi RoR HAL menggunakan persistensi RAM. Agar hal ini berfungsi, OEM harus memastikan bahwa SoC mereka mendukung persistensi RAM setelah melakukan {i>reboot<i}. Beberapa SoC tidak dapat mempertahankan konten RAM saat {i>reboot<i}, jadi OEM disarankan untuk berkonsultasi dengan partner SoC mereka sebelum mengaktifkan HAL default ini. Referensi kanonis untuk hal ini di bagian berikut.
Alur update OTA menggunakan RoR
Aplikasi klien OTA di ponsel harus memiliki
Manifest.permission.REBOOT
dan izin Manifest.permission.RECOVERY untuk memanggil metode yang diperlukan untuk
mengimplementasikan RoR. Dengan adanya prasyarat tersebut,
update mengikuti langkah-langkah berikut:
- Aplikasi klien OTA mengunduh pembaruan.
- Aplikasi klien OTA memanggil
RecoverySystem#prepareForUnattendedUpdateyang membuat pengguna dimintai PIN, pola, atau {i>password<i} pada layar saat membuka kunci berikutnya. - Pengguna membuka kunci perangkat di layar kunci, dan perangkat siap digunakan agar pembaruan diterapkan.
- Aplikasi klien OTA memanggil
RecoverySystem#rebootAndApply, yang segera akan memicu {i>reboot<i}.
Di akhir alur ini, perangkat melakukan {i>reboot <i}dan RoR membuka kunci penyimpanan yang dienkripsi dengan kredensial (CE). Untuk aplikasi, ini muncul sebagai pembuka kunci normal, sehingga mereka menerima semua sinyal, seperti ACTION_LOCKED_BOOT_COMPLETED dan ACTION_BOOT_COMPLETED yang biasa mereka lakukan.
Mengubah konfigurasi produk
Produk yang ditandai sebagai mendukung fitur RoR di Android 11 harus menyertakan implementasi RebootEscrow HAL dan menyertakan file XML penanda fitur. Implementasi default berfungsi dengan baik pada perangkat yang menggunakan warm reboot (saat daya ke DRAM tetap aktif selama reboot).
Mulai ulang penanda fitur dana jaminan
Penanda fitur juga harus ada:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
Implementasi HAL escrow reboot default
Untuk menggunakan implementasi default, Anda harus mencadangkan 65536 (0x10000) byte. Tidak Pernah menulis byte ini ke penyimpanan non-volatil untuk memastikan bahwa properti keamanan akan dipertahankan.
Perubahan hierarki perangkat kernel Linux
Dalam hierarki perangkat kernel Linux, Anda harus mencadangkan memori untuk region pmem.
Contoh berikut menunjukkan 0x50000000 yang dicadangkan:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
Verifikasi bahwa Anda memiliki perangkat baru di
direktori blok dengan nama seperti
/dev/block/pmem0 (seperti pmem1 atau pmem2).
Perubahan device.mk
Dengan asumsi bahwa perangkat baru dari langkah sebelumnya diberi nama pmem0, Anda harus
pastikan entri baru berikut ditambahkan ke vendor/<oem>/<product>/device.mk:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
Aturan SELinux
Tambahkan entri baru ini ke file_contexts perangkat:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0