Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Lanjutkan-on-Reboot

Di Android 11, update OTA dapat diterapkan dengan menggunakan A / update B atau A / B pembaruan maya mekanisme, dikombinasikan dengan RecoverySystem metode kelas. Setelah perangkat reboot untuk menerapkan pembaruan OTA, Lanjutkan-on-Reboot (RoR) membuka perangkat Credential Encrypted (CE) penyimpanan .

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 android.hardware.reboot_escrow fitur untuk mendukung RoR di Android 11, Anda tidak perlu untuk ini untuk mengaktifkan server berbasis RoR di Android 12 dan lebih tinggi, karena mereka tidak menggunakan HAL tersebut.

memberikan izin perangkat untuk android.hardware.reboot_escrow fitur. 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 didukung langsung 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

Sebuah implementasi dari RoR harus memastikan bahwa ketika perangkat jatuh ke tangan penyerang, itu sangat sulit bagi penyerang untuk memulihkan CE dienkripsi data pengguna, bahkan jika perangkat dinyalakan, penyimpanan CE tidak terkunci, dan perangkat dibuka dengan 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 secara fisik memiliki perangkat, dan memiliki kemampuan ini dan keterbatasan:

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 (seperti prosesor aplikasi, atau memori flash) - kecuali seperti yang dijelaskan dalam Keterbatasan bawah. (Namun, modifikasi tersebut melibatkan penundaan setidaknya satu jam, dan siklus daya yang menghancurkan isi RAM.)

Keterbatasan

  • Tidak dapat mengubah pengoperasian perangkat keras tahan gangguan (misalnya, Titan M).
  • Tidak dapat membaca RAM perangkat langsung.
  • Tidak dapat menebak kredensial pengguna (PIN, pola, kata sandi) atau menyebabkannya 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 disimpan dalam lingkungan eksekusi dipercaya (TEE).
  • TEE hanya melepaskan kunci jika sistem operasi berjalan melewati otentikasi kriptografi (diverifikasi boot).
  • The RoR layanan yang berjalan pada data CE server Google mengamankan dengan menyimpan sebuah rahasia yang dapat diambil untuk waktu yang terbatas saja. 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_s disimpan di RAM, dan lagi dengan kunci K_k disimpan di TEE.
    • SP terenkripsi ganda disimpan di disk, dan SP dihapus dari RAM. Kedua tombol yang baru dihasilkan dan digunakan untuk satu reboot saja.
  • Ketika waktu untuk reboot, Android mempercayakan K_s ke server. Penerimaan dengan K_k akan dienkripsi sebelum disimpan pada disk.
  • Setelah reboot, Android menggunakan K_k untuk mendekripsi tanda terima, kemudian mengirimkannya ke server untuk mengambil K_s .
    • K_k dan K_s digunakan untuk mendekripsi SP disimpan pada disk.
    • Android menggunakan SP untuk membuka kunci penyimpanan CE dan memungkinkan startup aplikasi normal.
    • K_k dan K_s dibuang.

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 memiliki nya PIN diaktifkan, interaksi dengan server RoR memerlukan koneksi WiFi untuk update OTA dan berbasis server yang RoR, yang menjamin fungsi 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 tersimpan hanya dapat digunakan sekali setelah reboot RoR-dimulai, dan hanya untuk durasi waktu yang sangat singkat (20 detik) - jika rincian pertandingan kartu SIM. 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 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, memiliki pencarian perangkat bootloader untuk alasan string yang unattended . Jika unattended adalah true , menempatkan perangkat dalam modus 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 aliran multi-client, isPreparedForUnattendedUpdate , 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 tidak digunakan lagi pada Android 12.

Manajer Telepon

OTA client memanggil TelephonyManager sistem API saat reboot sudah dekat di Android 12. API ini bergerak semua cache kode PIN dari AVAILABLE negara ke REBOOT_READY negara. The TelephonyManager sistem API dilindungi oleh yang ada REBOOT izin Manifest.

 /**
    * 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 bekerja ketika shell berjalan 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 dukungan hardware SoC RAM ketekunan di reboot, OEM dapat menggunakan implementasi standar di AOSP ( RAM default Escrow ).
  2. 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

OTA client aplikasi di telepon harus memiliki Manifest.permission.REBOOT dan Manifest.permission.RECOVERY izin untuk memanggil metode yang diperlukan untuk melaksanakan RoR. Dengan prasyarat tersebut, alur pembaruan mengikuti langkah-langkah berikut:

  1. Aplikasi klien OTA mengunduh pembaruan.
  2. Aplikasi klien OTA panggilan ke RecoverySystem#prepareForUnattendedUpdate yang memicu pengguna untuk diminta untuk PIN mereka, pola, atau sandi pada layar kunci selama unlock berikutnya.
  3. Pengguna membuka kunci perangkat di layar kunci, dan perangkat siap menerapkan pembaruan.
  4. OTA aplikasi klien panggilan ke 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 membuka normal, sehingga mereka menerima semua sinyal, seperti ACTION_LOCKED_BOOT_COMPLETED dan ACTION_BOOT_COMPLETED bahwa mereka biasanya 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 berfungsi 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

Dalam pohon perangkat Linux kernel, Anda harus memesan memori untuk pmem daerah. Contoh berikut menunjukkan 0x50000000 yang disediakan:

  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 mengikuti entri baru akan 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

Menambahkan entri-entri baru untuk perangkat file_contexts :

/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