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. Cihaz, OTA güncellemesi uygulamak için yeniden başlatıldıktan sonra Yeniden Başlatmada Devam Et (RoR), cihazın Kimlik Bilgisi Şifrelenmiş (CE) depolama alanının kilidini açar.

İş ortakları, Android 11'de cihazın boşta olması beklenen durumlarda güncellemeleri uygulayan bir OTA sistem özelliğiyle bu süreci eşleştirebilir. Ancak Android 12'de iş ortaklarının ek bir OTA sistem özelliğine ihtiyacı yoktur. 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. gösterir. 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, OTA güncellemesinden sonra yeniden başlatma işlemi başlatıldığında, Doğrudan Açılış'ı desteklemeyenler de dahil olmak üzere cihazdaki tüm uygulamaların CE depolama alanının kilidinin açılmasına olanak tanır. 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.

Daha açık belirtmek gerekirse, CE depolama alanı, cihaza fiziksel olarak sahip olan ve aşağıdaki özelliklere ve sınırlamalara sahip bir saldırgan tarafından okunmamalıdır:

Ö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ç). (Ancak bu tür bir değişiklik hem en az bir saatlik bir gecikme hem de RAM içeriğini yok eden bir güç döngüsü içerir.)

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 başka bir şekilde girilmesine neden olamaz.

Çö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, cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında (TEE) saklanan anahtarlarla korunur.
  • TEE, yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamasını (doğrulanmış başlatma) geçerse anahtarları serbest bırakır.
  • Google sunucularında çalışan RoR hizmeti, yalnızca sınırlı bir süre boyunca alınabilen bir gizli anahtar saklayarak CE verilerini korur. Bu tüm Android ekosisteminde işe yarar.
  • Cihazın kilidini açmak ve CE depolama alanının şifresini çözmek için kullanıcının PIN'iyle korunan bir kriptografik anahtar kullanılır.
    • Gece boyunca yeniden başlatma planlandığında Android, kullanıcıdan PIN'ini girmesini 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şturulur 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.
  • Android, yeniden başlatıldıktan sonra makbuzun şifresini çözmek için K_k'ü kullanır ve ardından K_s'ü almak için makbuzu sunucuya gönderir.
    • 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 uygulama başlatmasına izin vermek için SP'yi kullanır.
    • K_k ve K_s atılır.

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. Bu işleme SIM-PIN yeniden oynatma adı verilir.

Etkin PIN'e sahip bir SIM kart, hücresel bağlantıyı (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) geri yüklemek amacıyla, gözetimsiz yeniden başlatma işleminden sonra sorunsuz bir PIN kodu doğrulamasından (SIM-PIN yeniden oynatma) da geçmelidir. SIM PIN'i ve eşleşen SIM kartı bilgileri (ICCID ve SIM yuvası numarası) 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'de PIN etkinse OTA güncellemesi ve sunucu tabanlı RoR için RoR sunucusuyla etkileşimde bulunmak kablosuz bağlantı gerektirir. Bu bağlantı, yeniden başlatma işleminden sonra temel işlevlerin (hücresel bağlantıyla) kullanılmasını sağlar.

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 gerçekleşirse SIM PIN'i atlanır:

  • 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.

Kayıtlı SIM PIN'i, RoR tarafından başlatılan yeniden başlatma işleminden sonra yalnızca bir kez ve yalnızca çok kısa bir süre (20 saniye) boyunca kullanılabilir. Bu süre, SIM kartın ayrıntıları eşleştiği durumlarda geçerlidir. 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 sunucuya dayalı RoR işlevleri, iş ortakları OTA güncellemeleri yayınlarken daha az yük sağlar. Gerekli güncellemeler, cihazın kullanılmadığı uygun zamanlarda (ör. belirlenen uyku saatlerinde) yapılabilir.

Bu tür zamanlarda yapılan OTA güncellemelerinin kullanıcıları kesintiye uğratmaması için ışık emisyonlarını azaltmak amacıyla karanlık modu kullanın. Bunun için cihazın önyükleyicisinin unattended dize nedenini aramasını sağlayın. unattended true ise cihazı koyu moda alın. Ses ve ışık emisyonlarını azaltmanın her OEM'nin sorumluluğu olduğunu unutmayın.

Android 12'ye yükseltme yapıyor veya Android 12 cihazlar kullanıma sunuyorsanız yeni RoR işlevini uygulamak için herhangi bir işlem yapmanız gerekmez.

Ç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.

TelephonyManager

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 sistem API'si, mevcut REBOOT manifest izniyle korunur.

 /**
    * 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'ın 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 çalışması için OEM'lerin, SoC'lerinin yeniden başlatmalarda RAM'i korumayı desteklediğinden emin olması gerekir. Bazı SoC'ler, RAM içeriğini yeniden başlatma sırasında koruyamaz. Bu nedenle OEM'lerin bu varsayılan HAL'i etkinleştirmeden önce SoC iş ortaklarına danışmaları ö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. OTA istemci uygulaması RecoverySystem#prepareForUnattendedUpdate çağrısı yapar. Bu çağrı, bir sonraki kilit açma işlemi sırasında kullanıcıdan kilit ekranında PIN, desen veya şifresi istenmesini tetikler.
  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. Uygulamalar için bu işlem normal bir kullanıcı kilidi açma işlemi olarak görünür. Bu nedenle, normalde aldıkları ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED gibi tüm sinyalleri alırlar.

Ü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).

Teminat özelliği işaretçisini yeniden başlat

Özellik işaretçisi de mevcut olmalı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 (0x10000) bayt ayırmanız gerekir. Hiçbir zaman bu baytları değişken olmayan depolamaya yazarak, güvenlik özelliklerinin ısrarcı olabilir.

Linux çekirdek cihaz ağacında yapılan değişiklikler

Linux çekirdeğinin cihaz ağacında, bir pmem bölgesi için bellek ayırmanız gerekir. Aşağıdaki örnekte 0x50000000'in ayrılmış olduğu 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