Di Android 11, update OTA dapat diterapkan menggunakan mekanisme update A/B atau update A/B virtual, yang dikombinasikan dengan metode class RecoverySystem. Setelah perangkat dimulai ulang untuk menerapkan update OTA, Lanjutkan setelah Mulai Ulang (RoR) akan membuka kunci penyimpanan Enkripsi Kredensial (CE) perangkat.
Meskipun partner dapat memasangkan proses ini dengan fitur sistem OTA yang menerapkan update saat perangkat diperkirakan dalam kondisi tidak digunakan di Android 11, di Android 12, partner tidak memerlukan fitur sistem OTA tambahan. Proses RoR memberikan keamanan dan kenyamanan tambahan bagi pengguna karena update dapat dilakukan selama waktu tunggu perangkat, sementara fungsi update berbasis server dan multi-klien Android 12 secara bersama-sama memberikan keamanan tingkat hardware perangkat.
Meskipun Anda harus memberikan izin perangkat agar fitur android.hardware.reboot_escrow
dapat mendukung RoR di Android 11, Anda tidak perlu melakukannya untuk mengaktifkan
RoR berbasis server di Android 12 dan yang lebih tinggi, karena fitur tersebut
tidak menggunakan HAL.
Latar belakang
Mulai Android 7, Android mendukung Direct Boot, yang memungkinkan aplikasi di perangkat dimulai sebelum penyimpanan CE dibuka kuncinya oleh pengguna. Penerapan dukungan Booting Langsung memberikan pengalaman yang lebih baik kepada Pengguna sebelum Faktor Pengetahuan Layar Kunci (LSKF) perlu dimasukkan setelah booting.
RoR memungkinkan penyimpanan CE semua aplikasi di perangkat dibuka kuncinya, termasuk aplikasi yang tidak mendukung Direct Boot, saat perangkat dimulai ulang setelah update OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari semua aplikasi yang diinstal, setelah perangkat dimulai ulang.
Model ancaman
Penerapan RoR harus memastikan bahwa saat perangkat jatuh ke tangan penyerang, penyerang akan sangat sulit memulihkan data yang dienkripsi CE pengguna, meskipun perangkat dihidupkan, penyimpanan CE dibuka kuncinya, dan perangkat dibuka kuncinya oleh pengguna setelah menerima update OTA. Ketahanan terhadap serangan orang dalam harus efektif meskipun penyerang mendapatkan akses ke kunci penandatanganan kriptografi siaran.
Secara khusus, penyimpanan CE tidak boleh dibaca oleh penyerang yang secara fisik memiliki perangkat, dan memiliki kemampuan serta batasan berikut:
Capabilities
- Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani pesan arbitrer.
- Dapat menyebabkan perangkat menerima update OTA.
- Dapat mengubah operasi hardware 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 siklus daya yang menghancurkan konten RAM.)
Batasan
- Tidak dapat mengubah operasi hardware yang tahan terhadap gangguan (misalnya, Titan M).
- Tidak dapat membaca RAM perangkat aktif.
- Tidak dapat menebak kredensial pengguna (PIN, pola, sandi) atau menyebabkan kredensial tersebut dimasukkan.
Solusi
Sistem update RoR Android 12 memberikan keamanan terhadap penyerang yang sangat canggih, dan melakukannya saat sandi dan PIN di perangkat tetap berada di perangkat—sandi dan PIN tersebut tidak pernah dikirimkan ke atau disimpan di server Google. Berikut ringkasan proses yang memastikan tingkat keamanan yang diberikan serupa dengan sistem RoR level perangkat berbasis hardware:
- Android menerapkan perlindungan kriptografi pada data yang disimpan di perangkat.
- Semua data dilindungi oleh kunci yang disimpan di trusted execution environment (TEE).
- TEE hanya merilis kunci jika sistem operasi yang berjalan lulus autentikasi kriptografi (booting terverifikasi).
- Layanan RoR yang berjalan di server Google mengamankan data CE dengan menyimpan rahasia yang dapat diambil hanya untuk waktu terbatas. Fitur ini berfungsi di seluruh ekosistem Android.
- Kunci kriptografi, yang dilindungi oleh PIN pengguna, digunakan untuk membuka kunci perangkat dan mendekripsi penyimpanan CE.
- Saat memulai ulang semalam dijadwalkan, Android akan meminta pengguna memasukkan PIN mereka, lalu menghitung sandi sintetis (SP).
- Kemudian, SP dienkripsi dua kali: sekali dengan kunci
K_syang disimpan di RAM, dan sekali lagi dengan kunciK_kyang disimpan di TEE. - SP yang dienkripsi ganda disimpan di disk, dan SP dihapus dari RAM. Kedua kunci baru dibuat dan digunakan untuk satu kali reboot saja.
- Saat waktunya memulai ulang, Android mempercayakan
K_ske server. Tanda terima denganK_kdienkripsi sebelum disimpan di disk. - Setelah perangkat dimulai 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_sdibuang.
Update yang menjaga keamanan ponsel Anda dapat terjadi pada waktu yang nyaman bagi Anda: saat Anda tidur.
Pemutaran ulang SIM-PIN
Dalam kondisi tertentu, kode PIN kartu SIM diverifikasi dari cache, proses yang disebut pemutaran ulang PIN SIM.
Kartu SIM dengan PIN yang diaktifkan juga harus menjalani verifikasi kode PIN yang lancar (pemutaran ulang PIN SIM) setelah perangkat dimulai ulang tanpa pengawasan untuk memulihkan konektivitas seluler (diperlukan untuk panggilan telepon, pesan SMS, dan layanan data). PIN SIM dan informasi kartu SIM yang cocok (ICCID dan nomor slot SIM) disimpan bersama secara aman. PIN yang disimpan dapat diambil dan digunakan untuk verifikasi hanya setelah memulai ulang tanpa pengawasan yang berhasil. Jika perangkat diamankan, PIN SIM akan disimpan dengan kunci yang dilindungi oleh LSKF. Jika PIN SIM diaktifkan, interaksi dengan server RoR memerlukan koneksi WiFi untuk update OTA dan RoR berbasis server, yang memastikan fungsi dasar (dengan konektivitas seluler) setelah dimulai ulang.
PIN SIM dienkripsi ulang dan disimpan setiap kali pengguna berhasil mengaktifkan, memverifikasi, atau mengubahnya. PIN SIM akan dibatalkan jika salah satu dari hal berikut terjadi:
- SIM dikeluarkan atau direset.
- Pengguna menonaktifkan PIN.
- Reboot yang tidak dimulai oleh RoR telah terjadi.
PIN SIM yang tersimpan hanya dapat digunakan sekali setelah perangkat dimulai ulang yang diprakarsai oleh RoR, dan hanya untuk durasi waktu yang sangat singkat (20 detik)–jika detail kartu SIM cocok. PIN SIM yang disimpan tidak pernah keluar dari aplikasi TelephonyManager dan tidak dapat diambil oleh modul eksternal.
Panduan penerapan
Di Android 12, fungsi RoR berbasis server dan multi-klien memberikan beban yang lebih ringan kepada partner saat mereka mengirimkan update OTA. Update yang diperlukan dapat terjadi selama periode nonaktif perangkat yang nyaman, seperti selama jam tidur yang ditentukan.
Untuk memastikan bahwa update OTA selama periode waktu tersebut tidak mengganggu pengguna, gunakan mode gelap untuk mengurangi emisi cahaya. Untuk melakukannya, minta bootloader perangkat menelusuri string alasan unattended. Jika unattended adalah true,
setel perangkat ke 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 tindakan apa pun untuk menerapkan fungsi RoR baru.
Ada satu panggilan baru dalam alur multi-klien, isPreparedForUnattendedUpdate,
seperti yang ditunjukkan di bawah:
@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.
TelephonyManager
Klien OTA memanggil API sistem TelephonyManager saat mulai ulang akan segera dilakukan
di Android 12. API ini memindahkan semua kode PIN yang di-cache dari
status AVAILABLE ke status REBOOT_READY. API sistem TelephonyManager
dilindungi oleh izin Manifes REBOOT
yang ada.
/**
* 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()
TelephonyManager system API digunakan oleh APK yang memiliki hak istimewa.
Pengujian
Untuk menguji API baru, jalankan perintah ini:
adb shell cmd phone unattended-rebootPerintah 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 dibagi menjadi dua kategori:
- Jika hardware SoC mendukung persistensi RAM di seluruh proses booting ulang, OEM dapat menggunakan implementasi default di AOSP (Pengamanan RAM Default).
- Jika hardware atau SoC perangkat mendukung enklave hardware yang aman (coprosesor keamanan diskret dengan RAM dan ROM-nya sendiri), perangkat tersebut juga harus melakukan hal berikut:
- Dapat mendeteksi reboot CPU utama.
- Memiliki sumber timer hardware yang tetap ada saat perangkat dimulai ulang. Artinya, enclave harus dapat mendeteksi mulai ulang dan mengakhiri masa berlaku timer yang disetel sebelum mulai ulang.
- Mendukung penyimpanan kunci yang di-escrow di RAM/ROM enclave sehingga tidak dapat dipulihkan dengan serangan offline. Kunci RoR harus disimpan dengan cara yang membuat orang dalam atau penyerang tidak dapat memulihkannya.
Escrow RAM default
AOSP memiliki implementasi RoR HAL menggunakan persistensi RAM. Agar fitur ini berfungsi, OEM harus memastikan bahwa SoC mereka mendukung persistensi RAM di seluruh proses booting ulang. Beberapa SoC tidak dapat mempertahankan konten RAM saat melakukan reboot, jadi OEM disarankan untuk berkonsultasi dengan partner SoC mereka sebelum mengaktifkan HAL default ini. Referensi kanonis untuk hal ini ada di bagian berikut.
Alur update OTA menggunakan RoR
Aplikasi klien OTA di ponsel harus memiliki izin
Manifest.permission.REBOOT
dan Manifest.permission.RECOVERY untuk memanggil metode yang diperlukan guna
menerapkan RoR. Dengan prasyarat tersebut, alur update mengikuti langkah-langkah berikut:
- Aplikasi klien OTA mendownload update.
- Panggilan aplikasi klien OTA ke
RecoverySystem#prepareForUnattendedUpdateyang memicu pengguna untuk diminta memasukkan PIN, pola, atau sandi mereka di layar kunci selama pembukaan kunci berikutnya. - Pengguna membuka kunci perangkat di layar kunci, dan perangkat siap untuk menerapkan update.
- Panggilan aplikasi klien OTA ke
RecoverySystem#rebootAndApply, yang segera memicu mulai ulang.
Di akhir alur ini, perangkat akan di-reboot dan mekanisme RoR akan membuka kunci penyimpanan yang dienkripsi dengan kredensial (CE). Bagi aplikasi, hal ini tampak seperti pembukaan kunci pengguna normal, sehingga aplikasi menerima semua sinyal, seperti ACTION_LOCKED_BOOT_COMPLETED dan ACTION_BOOT_COMPLETED yang biasanya mereka lakukan.
Mengubah konfigurasi produk
Produk yang ditandai sebagai mendukung fitur RoR di Android 11 harus menyertakan implementasi HAL RebootEscrow dan menyertakan file XML penanda fitur. Implementasi default berfungsi dengan baik di perangkat yang menggunakan reboot hangat (saat daya ke DRAM tetap aktif selama reboot).
Penanda fitur escrow mulai ulang
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 pengamanan booting ulang default
Untuk menggunakan implementasi default, Anda harus mencadangkan 65536 (0x10000) byte. Jangan pernah menulis byte ini ke penyimpanan non-volatile untuk memastikan properti keamanan tetap ada.
Perubahan device tree kernel Linux
Di device tree 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>;
};
Pastikan 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 Anda dari langkah sebelumnya diberi nama pmem0, Anda harus
memastikan 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