Lanjutkan saat Reboot

Di Android 11, update OTA dapat diterapkan menggunakan mekanisme update A/B atau update A/B virtual , yang dikombinasikan dengan metode kelas RecoverySystem . Setelah perangkat di-boot ulang untuk menerapkan pembaruan OTA, Resume-on-Reboot (RoR) membuka kunci penyimpanan Credential Encrypted (CE) perangkat.

Meskipun mitra dapat memasangkan proses ini dengan fitur sistem OTA yang menerapkan pembaruan saat perangkat diperkirakan dalam keadaan idle di Android 11, di Android 12 mitra tidak memerlukan fitur sistem OTA tambahan. Proses RoR memberikan keamanan dan kenyamanan tambahan bagi pengguna karena pembaruan dapat dilakukan selama waktu idle perangkat, sementara fungsi pembaruan multiklien dan berbasis server Android 12 bersama-sama memberikan keamanan jenis tingkat perangkat keras perangkat.

Meskipun Anda harus memberikan izin perangkat untuk fitur android.hardware.reboot_escrow untuk mendukung RoR di Android 11, Anda tidak perlu melakukan ini untuk mengaktifkan RoR berbasis server di Android 12 dan lebih tinggi, karena mereka tidak menggunakan HAL.

Latar belakang

Dimulai dengan Android 7, Android mendukung Direct Boot , yang memungkinkan aplikasi di perangkat dimulai sebelum penyimpanan CE dibuka kuncinya oleh pengguna. Penerapan dukungan Direct Boot memberikan pengalaman yang lebih baik kepada Pengguna sebelum Lock Screen Knowledge Factor (LSKF) perlu dimasukkan setelah boot.

RoR memungkinkan penyimpanan CE semua aplikasi di perangkat dibuka kuncinya, termasuk aplikasi yang tidak mendukung Direct Boot, saat reboot dimulai setelah pembaruan OTA. Fitur ini memungkinkan pengguna menerima notifikasi dari semua aplikasi yang diinstal, setelah reboot.

Model ancaman

Implementasi RoR harus memastikan bahwa ketika perangkat jatuh ke tangan penyerang, sangat sulit bagi penyerang untuk memulihkan data pengguna yang dienkripsi CE, bahkan jika perangkat dihidupkan, penyimpanan CE tidak terkunci, dan perangkat dibuka kuncinya oleh penyerang. pengguna setelah menerima pembaruan OTA. Resistensi serangan orang dalam harus efektif bahkan jika penyerang memperoleh akses ke kunci penandatanganan kriptografi siaran.

Secara khusus, penyimpanan CE tidak boleh dibaca oleh penyerang yang memiliki perangkat secara fisik, dan memiliki kemampuan serta batasan berikut:

Kemampuan

  • Dapat menggunakan kunci penandatanganan vendor atau perusahaan mana pun untuk menandatangani pesan sewenang-wenang.
  • Dapat menyebabkan perangkat menerima pembaruan OTA.
  • Dapat memodifikasi pengoperasian perangkat keras apa pun (seperti prosesor aplikasi, atau memori flash) - kecuali sebagaimana dirinci dalam Batasan di bawah. (Namun, modifikasi tersebut melibatkan penundaan setidaknya satu jam, dan siklus daya yang merusak konten RAM.)

Keterbatasan

  • Tidak dapat mengubah pengoperasian perangkat keras yang tahan terhadap kerusakan (misalnya, Titan M).
  • Tidak dapat membaca RAM perangkat aktif.
  • Tidak dapat menebak kredensial pengguna (PIN, pola, kata sandi) atau menyebabkannya dimasukkan.

Larutan

Sistem pembaruan RoR Android 12 memberikan keamanan terhadap penyerang yang sangat canggih, dan melakukannya selama sandi dan PIN pada perangkat tetap ada di perangkat—tidak pernah dikirim atau disimpan di server Google. Ini adalah ikhtisar proses yang memastikan tingkat keamanan yang diberikan serupa dengan sistem RoR tingkat perangkat berbasis perangkat keras:

  • Android menerapkan perlindungan kriptografi pada 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 hanya dapat diambil untuk waktu terbatas . Ini berfungsi di seluruh ekosistem Android.
  • Kunci kriptografi, yang dilindungi oleh PIN pengguna, digunakan untuk membuka kunci perangkat dan mendekripsi penyimpanan CE.
    • Saat reboot semalam dijadwalkan, Android meminta pengguna memasukkan PIN, lalu menghitung kata sandi sintetis (SP).
    • Kemudian mengenkripsi SP dua kali: sekali dengan kunci K_s yang disimpan dalam RAM, dan sekali lagi dengan kunci K_k yang disimpan dalam TEE.
    • SP terenkripsi ganda disimpan di disk, dan SP dihapus dari RAM. Kedua kunci baru dibuat dan digunakan untuk satu reboot saja .
  • Saat tiba waktunya untuk reboot, Android mempercayakan K_s ke server. Tanda terima dengan K_k dienkripsi sebelum disimpan di disk.
  • Setelah reboot, Android menggunakan K_k untuk mendekripsi tanda terima, lalu mengirimkannya ke server untuk mengambil K_s .
    • K_k dan K_s digunakan untuk mendekripsi SP yang disimpan di disk.
    • Android menggunakan SP untuk membuka kunci penyimpanan CE dan mengizinkan startup aplikasi normal.
    • K_k dan K_s dibuang.

Pembaruan yang menjaga keamanan ponsel Anda dapat dilakukan pada waktu yang Anda inginkan: saat Anda tidur.

Pemutaran 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 lancar (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 (nomor ICCID dan slot SIM) disimpan bersama dengan aman. PIN yang disimpan dapat diambil dan digunakan untuk verifikasi hanya setelah reboot berhasil tanpa pengawasan. Jika perangkat diamankan, PIN SIM disimpan dengan kunci yang dilindungi oleh LSKF. Jika PIN SIM diaktifkan, 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 hal berikut terjadi:

  • SIM dilepas atau direset.
  • Pengguna menonaktifkan PIN.
  • Reboot yang tidak dimulai oleh RoR telah terjadi.

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 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 multiklien dan berbasis server memberikan beban yang lebih ringan kepada mitra saat mereka mendorong pembaruan OTA. Pembaruan yang diperlukan dapat terjadi selama waktu henti perangkat, misalnya selama jam tidur yang ditentukan.

Untuk memastikan bahwa pembaruan OTA selama jangka waktu tersebut tidak mengganggu pengguna, gunakan mode gelap untuk mengurangi emisi cahaya. Untuk melakukannya, minta bootloader perangkat mencari alasan string unattended . Jika true unattended , alihkan perangkat ke mode gelap. Perlu diperhatikan bahwa setiap OEM bertanggung jawab untuk mengurangi 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 baru.

Ada satu panggilan baru dalam alur multiklien, 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 menerapkan ini, karena HAL sudah tidak digunakan lagi mulai Android 12.

Manajer Telepon

Klien OTA memanggil API sistem TelephonyManager ketika 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 REBOOT Manifest 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 yang memiliki 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:

  1. Jika perangkat keras SoC mendukung persistensi RAM saat reboot, OEM dapat menggunakan implementasi default di AOSP ( Default RAM Escrow ).
  2. Jika perangkat keras atau SoC perangkat mendukung kantong perangkat keras yang aman (koprosesor keamanan terpisah dengan RAM dan ROM-nya sendiri), perangkat tersebut juga harus melakukan hal berikut:
    • Mampu mendeteksi reboot CPU utama.
    • Miliki sumber pengatur waktu perangkat keras yang tetap ada saat reboot. Artinya, enclave harus dapat mendeteksi reboot dan mengakhiri timer yang disetel sebelum reboot.
    • Mendukung penyimpanan kunci escrow di RAM/ROM enclave sehingga tidak dapat dipulihkan dengan serangan offline. Itu harus menyimpan kunci RoR sedemikian rupa sehingga tidak mungkin bagi orang dalam atau penyerang untuk memulihkannya.

Eskro RAM bawaan

AOSP memiliki implementasi RoR HAL menggunakan persistensi RAM. Agar ini berfungsi, OEM harus memastikan bahwa SoC mereka mendukung persistensi RAM saat 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 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 untuk mengimplementasikan RoR. Dengan adanya prasyarat tersebut, alur pembaruan mengikuti langkah-langkah berikut:

  1. Aplikasi klien OTA mengunduh pembaruan.
  2. Aplikasi klien OTA memanggil RecoverySystem#prepareForUnattendedUpdate yang memicu pengguna diminta memasukkan PIN, pola, atau kata sandi di layar kunci selama pembukaan kunci berikutnya.
  3. Pengguna membuka kunci perangkat di layar kunci, dan perangkat siap menerapkan pembaruan.
  4. Aplikasi klien OTA memanggil RecoverySystem#rebootAndApply , yang segera memicu reboot.

Di akhir alur ini, perangkat akan melakukan boot ulang dan mekanisme RoR membuka kunci penyimpanan terenkripsi kredensial (CE). Bagi aplikasi, ini tampak seperti pembukaan kunci pengguna biasa, sehingga aplikasi menerima semua sinyal, seperti ACTION_LOCKED_BOOT_COMPLETED dan ACTION_BOOT_COMPLETED seperti biasanya.

Ubah konfigurasi produk

Produk yang ditandai 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 reboot 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 mencadangkan 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 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