Yeniden Başlatıldığında Devam Ettir

Android 11'de OTA güncellemeleri A/B güncellemesi kullanılarak uygulanabilir veya sanal A/B güncelleme mekanizmaları, Kurtarma Sistemi sınıf yöntemleri. Bir cihaz OTA güncellemesi uygulamak için yeniden başlatıldıktan sonra Yeniden Başlatmada Devam Ettirme (RoR), cihazın Kimlik Bilgisi Şifrelenmiş (CE) depolama alanının kilidini açar.

İş ortakları, bu işlemi geçerli bir OTA sistemi özelliğiyle eşleştirebilir. Android 11'de cihazın boşta kalması beklendiğinde Android 12 iş ortaklarının ek bir OTA sistemine ihtiyacı yoktur özelliğini kullanabilirsiniz. RoR süreci kullanıcılara ek güvenlik ve kolaylık sağlar, çünkü Güncellemeler, cihazın boşta olduğu zamanlarda yapılabilirken Android 12'de çok istemcili ve sunucu tabanlı güncelleme işlevlerinin bir araya getirilmesiyle donanım seviyesinde güvenlik türü.

android.hardware.reboot_escrow için cihaz izni vermeniz gerekir özelliğini destekleyen bir özellik görürseniz bunu, Android 11'de Android 12 ve sonraki sürümlerde sunucu tabanlı kullanmayın.

Arka plan

Android 7'den itibaren, Android'in desteklediği Doğrudan Başlatma, Böylece, CE depolama alanı kilidi açılmadan önce cihazdaki uygulamalar başlatılır. temsil eder. Doğrudan Başlatma desteğinin uygulanması, kullanıcılara daha iyi deneyimi yerine getirilmesi için kullanılan Kilit Ekranı Bilgi Faktörü'nden (LSKF) sonra kaybolabilir.

RoR, aşağıdakiler de dahil olmak üzere cihazdaki tüm uygulamaların CE depolama alanının kilidinin açılmasına olanak tanır: Doğrudan Başlatma'yı desteklemeyenlerse, başlatıldıktan sonra yeniden başlatma OTA güncellemesi. Bu özellik, kullanıcıların tüm yeniden başlatmadan sonra işlem yapılamaz.

Tehdit modeli

RoR uygulanması, bir cihaz saldırganın saldırganın kullanıcının CE- şifrelenmiş veriler içerebilir. Cihaz açık olsa bile CE depolama alanının kilidi açıktır ve OTA güncellemesi alındıktan sonra cihazın kilidi kullanıcı tarafından açılır. İçeriden Biri saldırı direnci, saldırgan saldırıya uğrasa bile etkili olmalıdır. şifreleme imzalama anahtarlarını yayınlayabilir.

Özellikle, CE depolama alanı, fiziksel olarak sahip olan bir saldırgan tarafından okunmamalıdır. sahip olduğu özellikleri içerir ve aşağıdaki işlevlere ve sınırlamalara sahiptir:

Özellikler

  • Rastgele mesajları imzalamak için herhangi bir tedarikçi firmanın veya şirketin imzalama anahtarını kullanabilir.
  • Cihazın OTA güncellemesi almasına neden olabilir.
  • Herhangi bir donanımın (ör. uygulama işlemcisi, veya flash bellek) kaldırın (aşağıdaki Sınırlamalar bölümünde ayrıntılı olarak açıklanan durumlar hariç). (Bununla birlikte, bu tür değişiklik hem en az bir saatlik gecikmeyi hem de devre dışı bırakmanızı sağlar.)

Sınırlamalar

  • Üzerinde oynanmaya karşı korumalı donanımın (örneğin, Titan M) tıklayın.
  • Canlı cihazın RAM'i okunamıyor.
  • Kullanıcının kimlik bilgilerini (PIN, desen, şifre) tahmin edemez veya bu bilgileri girmeniz gerekir.

Çözüm

Android 12 RoR güncelleme sistemi güvenlik sağlar saldırganlara karşı koruyor. Cihaz üzerindeki şifreler ve PIN'ler cihazda kalır, hiçbir zaman Google sunucularına gönderilmez veya orada depolanmaz. Bu sağlanan güvenlik düzeylerinin test ve kontrol edilmesini sağlayan donanım tabanlı, cihaz düzeyindeki bir RoR sistemine benzer:

  • Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında depolanan anahtarlarla korunur. (TEE) tuşlarına basın.
  • TEE, anahtarları yalnızca çalışan işletim sistemi kriptografik kimlik doğrulama (doğrulanmış başlatma).
  • Google sunucularında çalışan RoR hizmeti, bir gizli anahtar depolayarak CE verilerinin güvenliğini sağlar yalnızca sınırlı bir süre için alınabilir. Bu tüm Android ekosisteminde işe yarar.
  • Cihazın kilidini açmak için kullanıcının PIN'i ile korunan bir şifreleme anahtarı kullanılır ve CE depolamanın şifresini çözün.
    • Gece boyunca yeniden başlatma planlandığında Android, kullanıcıdan giriş yapmasını ister. ve ardından sentetik bir şifre (SP) hesaplar.
    • Daha sonra, SP'yi iki kez şifreler: bir kez RAM'de depolanan bir K_s anahtarı ile ve tekrar TEE'de saklanan bir K_k anahtarı ile görüntülenir.
    • Çift şifrelenmiş SP diskte depolanır ve servis sağlayıcı da RAM'den silinir. Her iki anahtar da yeni oluşturulmuştur ve yalnızca bir yeniden başlatma için kullanılır.
  • Yeniden başlatma zamanı geldiğinde Android, K_s sağlayıcısını sunucuya güvenir. Fatura K_k ile diskte depolanmadan önce şifrelenir.
  • Yeniden başlatma sonrasında Android, makbuzun şifresini çözmek için K_k uygulamasını kullanır, ardından şu cihaza gönderir: K_s almak için sunucuya uygulanır.
    • K_k ve K_s, diskte depolanan SP'nin şifresini çözmek için kullanılır.
    • Android, CE depolama alanının kilidini açmak ve normal uygulamanın başlatılmasına izin vermek için SP'yi kullanır.
    • K_k ve K_s silindi.

Telefonunuzun güvenliğini sağlayan güncellemeler uygun bir zamanda gerçekleştirilebilir sizin için: Uyurken.

SIM-PIN'i tekrar oynatma

Belirli koşullar altında SIM kartın PIN kodu bir önbellekten doğrulanır. SIM-PIN'i tekrar oynatma adı verilen bir işlem.

PIN'i etkinleştirilmiş bir SIM kart da sorunsuz bir PIN kodundan geçmelidir Hücresel verileri geri yüklemek için gözetimsiz bir yeniden başlatma sonrasında doğrulama (SIM-PIN tekrarı) bağlantısı (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası) sayısı) birlikte güvenli bir şekilde saklanır. Saklanan PIN alınabilir ve kullanılabilir yalnızca başarılı bir katılımsız yeniden başlatma sonrasında doğrulama için yeniden başlatılmalıdır. Cihaz SIM PIN'i LSKF tarafından korunan anahtarlarla saklanır. SIM kartta PIN etkin, RoR sunucusuyla etkileşim için kablosuz bağlantı gerekir OTA güncellemesi ve sunucu tabanlı RoR için temel işlevsellik ( hücresel bağlantı) kullandığınızdan emin olun.

SIM PIN'i yeniden şifrelenir ve kullanıcı başarılı bir şekilde her etkinleştirdiğinde saklanır. doğrulama ya da değiştirme. Aşağıdakilerden herhangi biri SIM PIN'i silinir gerçekleşir:

  • SIM çıkarılmış veya sıfırlanır.
  • Kullanıcı PIN'i devre dışı bırakır.
  • RoR tarafından başlatılmayan bir yeniden başlatma işlemi gerçekleşti.

Saklanan SIM PIN'i yalnızca RoR tarafından başlatılan yeniden başlatma işleminden sonra bir kez kullanılabilir ve yalnızca çok kısa bir süre (20 saniye) için (SIM'in ayrıntıları varsa) kart eşleşmesi. Saklanan SIM PIN'i, TelephonyManager uygulamasından çıkmaz ve harici modüller tarafından alınamıyor.

Uygulama yönergeleri

Android 12'de, çok istemcili ve sunucu tabanlı RoR işlevleri, OTA güncellemelerini aktaran iş ortaklarına daha hafif bir yük sağlar. Gerekli güncellemeler, cihazın uygun kapalı kalma zamanlarında (ör. uyku saatleri olarak tanımlayabilirsiniz.

Bu zaman aralıklarındaki OTA güncellemelerinin kullanıcıları rahatsız etmediğinden emin olmak için ışık emisyonlarını azaltmak için koyu mod kullanma. Bunun için cihazın unattended dize nedeni için bootloader araması yapın. unattended değeri true ise koyu moda alabilirim. Not: Değişiklik yapma konusunda her OEM'in ses ve ışık emisyonlarını azaltabilirsiniz.

Android 12'ye yükseltme yapıyor veya Android 12 cihazlar için herhangi bir işlem yapmanıza gerek yoktur. yeni RoR işlevini uygulayabilir.

Çok müşterili akışta yeni bir arama var: isPreparedForUnattendedUpdate, aşağıda gösterilmiştir:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

HAL desteği sonlandırıldığı için bunu uygulamanız gerekmez Android 12.

Telefon Yöneticisi

OTA istemcisi, yeniden başlatma işlemi yaklaştığında TelephonyManager sistem API'sini çağırır kullanıma sunduk. Bu API, önbelleğe alınan tüm PIN kodlarını şuradan taşır: AVAILABLE durumunu REBOOT_READY durumuna getirir. TelephonyManager sistemi API, mevcut REBOOT ile korunuyor Manifest izni.

 /**
    * 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 sistem API'si ayrıcalıklı APK'lar tarafından kullanılır.

Test

Yeni API'yi test etmek için şu komutu yürütün:

    adb shell cmd phone unattended-reboot

Bu komut yalnızca kabuk, kök (adb root) olarak çalıştığında çalışır.

Yalnızca Android 11

Bu sayfanın kalan kısmı Android 11 için geçerlidir.

Temmuz 2020 itibarıyla RoR HAL uygulamaları iki kategoriye ayrılır:

  1. SoC donanımı, yeniden başlatma işlemleri arasında RAM kalıcılığını destekliyorsa OEM'ler AOSP'de varsayılan uygulama (Varsayılan RAM Bloke).
  2. Cihaz donanımı veya Çip üzerinde sistem (SoC) güvenli bir donanım enclave'yi (ayrık güvenlik ek işlemcisi) ve ayrıca takip etmek için:
    • Ana CPU yeniden başlatmasını algılayabilme.
    • Yeniden başlatma sırasında devam eden bir donanım zamanlayıcı kaynağına sahip olmalıdır. Yani, enclave, tekrar başlat.
    • Bloke edilen bir anahtarın enclave RAM/ROM'da depolanamaması için destek çevrimdışı saldırılarla kurtarılabilir. RoR anahtarını Bu nedenle, kuruluş içinden kişilerin veya saldırganların verileri kurtarmasını imkansız hale getirir.

Varsayılan RAM emaneti

AOSP'de, RAM kalıcılığı kullanan bir RoR HAL uygulaması vardır. Bunun işe yaraması için OEM'lerin, SoC'lerinin RAM kalıcılığını desteklediğinden emin olması gerekir. çok daha iyi performans gösterir. Bazı SoC'ler yeniden başlatma sırasında RAM içeriğini koruyamaz, bu nedenle OEM'lerin, bu varsayılan HAL'yi etkinleştirmeden önce SoC iş ortaklarına danışması önerilir. Bu konuda standart referans, aşağıdaki bölümde yer almaktadır.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulamasında Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerini kullanarak gerekli yöntemleri nasıl uygulayacağınızı öğreneceksiniz. Bu ön koşul yerine getirildiğinde, aşağıdaki adımları uygular:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. RecoverySystem#prepareForUnattendedUpdate için OTA istemci uygulaması çağrısı kullanıcıya giriş sayfasında PIN, desen veya şifresinin sorulmasını sırasında kilit ekranını açın.
  3. Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz hazır olur seçeneğine dokunun.
  4. RecoverySystem#rebootAndApply adlı cihaza yapılan OTA istemci uygulaması hemen çağrılıyor bir yeniden başlatma işlemini tetikler.

Bu akışın sonunda cihaz yeniden başlatılır ve RoR mekanizması, kimlik bilgisi ile şifrelenmiş (CE) depolama alanının kilidini açar. Uygulamalara, normal bir kilit açma şekli olarak görünür. Böylece, İŞLEM_KİLİTLİ_BOOT_TAMAMLANDI ve İŞLEM_BOOT_TAMAMLANDI yapabilirler.

Ürün yapılandırmalarını değiştirme

Android 11'de RoR özelliğini destekliyor olarak işaretlenen bir üründe, ve özellik işaretçisi XML dosyasını içermesi gerekir. Varsayılan uygulama, hazır durumda yeniden başlatma kullanan cihazlarda ( yeniden başlatma sırasında DRAM'nin gücü açık kalır).

Yeniden başlatma emaneti özellik işaretçisi

Özellik işaretçisi de bulunmalıdır:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Varsayılan yeniden başlatma emanet HAL uygulaması

Varsayılan uygulamayı kullanmak için 65.536 (0x10.000) bayt ayırmalısınız. Hiçbir zaman bu baytları değişken olmayan depolamaya yazarak, güvenlik özelliklerinin ısrarcı olabilir.

Linux çekirdek cihaz ağacı değişiklikleri

Linux çekirdeğinin cihaz ağacında, bir pmem bölgesi için bellek ayırmanız gerekir. Aşağıdaki örnekte 0x50000000 rezervasyonu gösterilmektedir:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Engelleme dizininde şuna sahip yeni bir cihazınız olduğunu doğrulayın: /dev/block/pmem0 (pmem1 veya pmem2 gibi).

Device.mk değişiklikleri

Önceki adımdaki yeni cihazınızın adının pmem0 olduğunu varsayarsak, aşağıdaki yeni girişlerin vendor/<oem>/<product>/device.mk alanına eklendiğinden emin olun:

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
SELinux kuralları

Şu yeni girişleri cihazın file_contexts bölümüne ekleyin:

/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