Di Android 11, pembaruan OTA dapat diterapkan menggunakan pembaruan A/B atau mekanisme pembaruan A/B virtual , yang dikombinasikan dengan metode kelas Sistem Pemulihan . Setelah perangkat di-boot ulang untuk menerapkan pembaruan OTA, Resume-on-Reboot (RoR) membuka kunci penyimpanan Perangkat Terenkripsi Kredensial (CE) .
Meskipun mitra dapat memasangkan proses ini dengan fitur sistem OTA yang menerapkan pembaruan saat perangkat diharapkan tidak aktif di Android 11, di Android 12 mitra tidak memerlukan fitur sistem OTA tambahan. Proses RoR memberikan keamanan dan kenyamanan tambahan kepada pengguna karena pembaruan dapat dilakukan selama waktu idle perangkat, sementara fungsi pembaruan berbasis server dan multiklien Android 12 bersama-sama memberikan keamanan jenis perangkat keras tingkat perangkat.
Meskipun Anda harus memberikan izin perangkat untuk fitur 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 mereka tidak menggunakan HAL.
memberikan izin perangkat untuk fitur android.hardware.reboot_escrow . Anda tidak perlu melakukan apa pun untuk mengaktifkan RoR berbasis server di Android 12, karena Android 12 dan yang lebih tinggi tidak menggunakan HAL.
Latar belakang
Dimulai dengan Android 7, Android mendukung Direct Boot , yang memungkinkan aplikasi pada perangkat untuk memulai sebelum penyimpanan CE dibuka oleh pengguna. Implementasi dukungan Direct Boot memberikan pengalaman yang lebih baik kepada Pengguna sebelum Lock Screen Knowledge Factor (LSKF) perlu dimasukkan setelah boot.
RoR memungkinkan penyimpanan CE dari semua aplikasi di perangkat untuk dibuka, termasuk yang tidak mendukung Direct Boot, saat reboot dimulai setelah pembaruan OTA. Fitur ini memungkinkan pengguna untuk menerima pemberitahuan dari semua aplikasi yang mereka instal, setelah reboot.
Model ancaman
Implementasi RoR harus memastikan bahwa ketika perangkat jatuh ke tangan penyerang, sangat sulit bagi penyerang untuk memulihkan data terenkripsi CE pengguna, bahkan jika perangkat dihidupkan, penyimpanan CE tidak terkunci, dan perangkat dibuka kuncinya oleh pengguna setelah menerima pembaruan OTA. Resistensi serangan orang dalam harus efektif bahkan jika penyerang mendapatkan akses ke kunci penandatanganan kriptografik siaran.
Secara khusus, penyimpanan CE tidak boleh dibaca oleh penyerang yang secara fisik memiliki perangkat, dan memiliki kemampuan serta batasan berikut:
Kemampuan
- Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani pesan arbitrer.
- Dapat menyebabkan perangkat menerima pembaruan OTA.
- Dapat memodifikasi pengoperasian perangkat keras apa pun (seperti prosesor aplikasi, atau memori flash) - kecuali seperti yang dijelaskan dalam Batasan di bawah ini. (Namun, modifikasi tersebut melibatkan penundaan setidaknya satu jam, dan siklus daya yang menghancurkan isi RAM.)
Keterbatasan
- Tidak dapat mengubah pengoperasian perangkat keras yang tahan terhadap kerusakan (misalnya, Titan M).
- Tidak dapat membaca RAM perangkat langsung.
- Tidak dapat menebak kredensial pengguna (PIN, pola, kata sandi) atau menyebabkan mereka dimasukkan.
Larutan
Sistem pembaruan Android 12 RoR memberikan keamanan terhadap penyerang yang sangat canggih, dan melakukannya saat sandi dan PIN di perangkat tetap berada di perangkat—mereka tidak pernah dikirim ke atau disimpan di server Google. Ini adalah ikhtisar proses yang memastikan tingkat keamanan yang disediakan serupa dengan sistem RoR tingkat perangkat berbasis perangkat keras:
- Android menerapkan perlindungan kriptografi ke data yang disimpan di perangkat.
- Semua data dilindungi oleh kunci yang disimpan di lingkungan eksekusi tepercaya (TEE).
- TEE hanya melepaskan kunci jika sistem operasi yang berjalan melewati otentikasi kriptografi ( boot terverifikasi ).
- Layanan RoR yang berjalan di server Google mengamankan data CE dengan menyimpan rahasia yang dapat diambil hanya dalam waktu terbatas . Ini berfungsi di seluruh ekosistem Android.
- Kunci kriptografi, dilindungi oleh PIN pengguna, digunakan untuk membuka kunci perangkat dan mendekripsi penyimpanan CE.
- Saat reboot semalam dijadwalkan, Android meminta pengguna untuk memasukkan PIN mereka, lalu menghitung kata sandi sintetis (SP).
- Kemudian mengenkripsi SP dua kali: sekali dengan kunci
K_sdisimpan dalam RAM, dan sekali lagi dengan kunciK_kdisimpan di TEE. - SP terenkripsi ganda disimpan di disk, dan SP dihapus dari RAM. Kedua kunci baru saja dibuat dan digunakan untuk satu kali reboot saja .
- Saat waktunya reboot, Android menitipkan
K_ske server. Tanda terima denganK_kdienkripsi sebelum disimpan di disk. - Setelah reboot, 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.
-
Pembaruan yang menjaga keamanan ponsel Anda dapat terjadi pada waktu yang nyaman bagi Anda: saat Anda tidur.
Putar ulang SIM-PIN
Dalam kondisi tertentu, kode PIN kartu SIM diverifikasi dari cache, sebuah proses yang disebut pemutaran ulang SIM-PIN.
Kartu SIM dengan PIN yang diaktifkan juga harus menjalani verifikasi kode PIN yang mulus (pemutaran ulang SIM-PIN) setelah reboot 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 dengan aman, bersama-sama. PIN yang disimpan dapat diambil dan digunakan untuk verifikasi hanya setelah reboot tanpa pengawasan yang berhasil. Jika perangkat diamankan, PIN SIM disimpan dengan kunci yang dilindungi oleh LSKF. Jika SIM mengaktifkan PIN, interaksi dengan server RoR memerlukan koneksi WiFi 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 memodifikasinya. PIN SIM dibuang jika salah satu dari yang berikut terjadi:
- SIM dihapus atau diatur ulang.
- Pengguna menonaktifkan PIN.
- Reboot yang tidak dimulai dengan RoR telah terjadi.
PIN SIM yang disimpan hanya dapat digunakan sekali setelah boot ulang yang dimulai 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.
Pedoman pelaksanaan
Di Android 12, fungsi RoR multi-klien dan berbasis server memberikan beban yang lebih ringan kepada mitra saat mereka mendorong pembaruan OTA. Pembaruan yang diperlukan dapat terjadi selama waktu henti perangkat yang nyaman, seperti selama jam tidur yang ditentukan.
Untuk memastikan bahwa pembaruan OTA selama periode waktu tersebut tidak mengganggu pengguna, gunakan mode gelap untuk mengurangi emisi cahaya. Untuk melakukannya, minta bootloader perangkat mencari alasan string unattended . Jika unattended true , letakkan perangkat dalam mode gelap. Perhatikan bahwa setiap OEM bertanggung jawab untuk mengurangi emisi suara dan cahaya.
Jika Anda meningkatkan ke Android 12, atau meluncurkan perangkat Android 12, Anda tidak perlu melakukan apa pun untuk menerapkan fungsi RoR yang baru.
Ada satu panggilan baru dalam alur multi-klien, isPreparedForUnattendedUpdate , yang ditunjukkan di bawah ini:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Anda tidak perlu mengimplementasikan ini, karena HAL tidak digunakan lagi pada Android 12.
Manajer Telepon
Klien OTA memanggil API sistem TelephonyManager saat reboot akan segera terjadi 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()
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 ketika shell dijalankan sebagai root ( adb root ).
Hanya Android 11
Sisa halaman ini berlaku untuk Android 11.
Pada Juli 2020, implementasi RoR HAL terbagi dalam dua kategori:
- Jika perangkat keras SoC mendukung persistensi RAM di seluruh reboot, OEM dapat menggunakan implementasi default di AOSP ( Default RAM Escrow ).
- Jika perangkat keras perangkat atau SoC mendukung enklave perangkat keras yang aman (koprosesor keamanan diskrit dengan RAM dan ROM-nya sendiri), selain itu harus melakukan hal berikut:
- Mampu mendeteksi reboot CPU utama.
- Miliki sumber pengatur waktu perangkat keras yang tetap ada di seluruh reboot. Artinya, enklave harus dapat mendeteksi reboot dan kedaluwarsa timer yang disetel sebelum reboot.
- Dukungan menyimpan kunci escrow di enclave RAM/ROM sehingga tidak dapat dipulihkan dengan serangan offline. Itu harus menyimpan kunci RoR dengan cara yang tidak memungkinkan orang dalam atau penyerang untuk memulihkannya.
Escrow RAM bawaan
AOSP memiliki implementasi RoR HAL menggunakan persistensi RAM. Agar ini berfungsi, OEM harus memastikan bahwa SoC mereka mendukung kegigihan RAM di seluruh reboot. Beberapa SoC tidak dapat mempertahankan konten RAM saat reboot, jadi OEM disarankan untuk berkonsultasi dengan mitra SoC mereka sebelum mengaktifkan HAL default ini. Referensi kanonik untuk ini di bagian berikut.
Alur pembaruan OTA menggunakan RoR
Aplikasi klien OTA di ponsel harus memiliki izin Manifest.permission.REBOOT dan Manifest.permission.RECOVERY untuk memanggil metode yang diperlukan untuk mengimplementasikan RoR. Dengan prasyarat tersebut, alur pembaruan mengikuti langkah-langkah berikut:
- Aplikasi klien OTA mengunduh pembaruan.
- Aplikasi klien OTA memanggil
RecoverySystem#prepareForUnattendedUpdateyang memicu pengguna untuk dimintai PIN, pola, atau kata sandi mereka di layar kunci selama pembukaan kunci berikutnya. - Pengguna membuka kunci perangkat di layar kunci, dan perangkat siap menerapkan pembaruan.
- Aplikasi klien OTA memanggil
RecoverySystem#rebootAndApply, yang segera memicu reboot.
Di akhir alur ini, perangkat melakukan boot ulang dan mekanisme RoR membuka kunci penyimpanan terenkripsi kredensial (CE). Untuk aplikasi, ini muncul sebagai pengguna biasa membuka kunci, sehingga mereka menerima semua sinyal, seperti ACTION_LOCKED_BOOT_COMPLETED dan ACTION_BOOT_COMPLETED yang biasanya mereka lakukan.
Memodifikasi 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 bekerja dengan baik pada perangkat yang menggunakan boot ulang hangat (ketika daya ke DRAM tetap menyala selama reboot).
Reboot penanda fitur escrow
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. Jangan pernah menulis byte ini ke penyimpanan non-volatil untuk memastikan bahwa properti keamanan tetap ada.
Perubahan pohon perangkat kernel Linux
Di pohon perangkat kernel Linux, Anda harus memesan memori untuk wilayah pmem . Contoh berikut menunjukkan 0x50000000 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 perangkat.mk
Dengan asumsi bahwa perangkat baru Anda dari langkah sebelumnya bernama 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