Yeniden Başlatmada Devam Etme

Koleksiyonlar ile düzeninizi koruyun İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.

Android 11'de OTA güncellemeleri, RecoverySystem sınıf yöntemleriyle birlikte A/B güncellemesi veya sanal A/B güncelleme mekanizmaları kullanılarak uygulanabilir. Bir cihaz, OTA güncellemesi uygulamak için yeniden başlatıldıktan sonra, Yeniden Başlatmada Devam Etme (RoR), cihazın Kimlik Bilgileri Şifreli (CE) depolamasının kilidini açar.

İş ortakları bu işlemi, cihazın Android 11'de boşta kalması beklendiğinde güncellemeleri uygulayan bir OTA sistem özelliği ile eşleştirebilse de, Android 12'de iş ortaklarının ek bir OTA sistem özelliğine ihtiyacı yoktur. RoR işlemi, güncellemeler cihaz boştayken yapılabildiği için kullanıcılara ek güvenlik ve kolaylık sağlarken, Android 12 çok istemcili ve sunucu tabanlı güncelleme işlevleri birlikte cihaz donanım düzeyinde güvenlik sağlar.

Android 11'de RoR'yi desteklemek için android.hardware.reboot_escrow özelliği için cihaz izni sağlamanız gerekse de, HAL kullanmadıkları için Android 12 ve sonraki sürümlerde sunucu tabanlı RoR'yi etkinleştirmek için buna ihtiyacınız yoktur.

android.hardware.reboot_escrow özelliği için cihaz izinleri sağlayın. Android 12 ve sonraki sürümlerde HAL kullanılmadığından, Android 12'de sunucu tabanlı RoR'yi etkinleştirmek için herhangi bir şey yapmanız gerekmez.

Arka fon

Android 7'den başlayarak, bir cihazdaki uygulamaların kullanıcı tarafından CE depolamasının kilidi açılmadan önce başlatılmasını sağlayan Android destekli Direct Boot . Doğrudan Önyükleme desteğinin uygulanması, Kullanıcılara, bir önyüklemeden sonra girilmesi gereken Kilit Ekranı Bilgi Faktörü'nün (LSKF) öncesinde daha iyi bir deneyim sağladı.

RoR, bir OTA güncellemesinin ardından yeniden başlatma başlatıldığında, Doğrudan Önyüklemeyi desteklemeyenler de dahil olmak üzere, bir cihazdaki tüm uygulamaların CE depolamasının kilidinin açılmasına izin verir. Bu özellik, kullanıcıların yeniden başlatma sonrasında tüm yüklü uygulamalarından bildirim almalarını sağlar.

tehdit modeli

Bir RoR uygulaması, bir cihaz bir saldırganın eline geçtiğinde, cihaz açık olsa, CE depolamasının kilidi açılmış olsa ve cihaz tarafından kilidi açılmış olsa bile, saldırganın kullanıcının CE ile şifrelenmiş verilerini kurtarmasının son derece zor olmasını sağlamalıdır. Bir OTA güncellemesi aldıktan sonra kullanıcı. Saldırgan yayın kriptografik imzalama anahtarlarına erişim kazansa bile içeriden saldırı direnci etkili olmalıdır.

Spesifik olarak, CE depolaması, cihaza fiziksel olarak sahip olan ve şu yeteneklere ve sınırlamalara sahip bir saldırgan tarafından okunmamalıdır :

yetenekler

  • İsteğe bağlı mesajları imzalamak için herhangi bir satıcının veya şirketin imzalama anahtarını kullanabilir.
  • Cihazın OTA güncellemesi almasına neden olabilir.
  • Aşağıdaki Sınırlamalar bölümünde ayrıntıları verilenler dışında, herhangi bir donanımın (bir uygulama işlemcisi veya flash bellek gibi) çalışmasını değiştirebilir. (Ancak, bu tür bir değişiklik hem en az bir saatlik gecikmeyi hem de RAM içeriğini yok eden bir güç döngüsünü içerir.)

sınırlamalar

  • Kurcalamaya dayanıklı donanımın (örneğin, bir Titan M) çalışmasını değiştiremez.
  • 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, çok karmaşık saldırganlara karşı güvenlik sağlar ve bunu, cihazdaki şifreler ve PIN'ler cihazda kalırken yapar; bunlar hiçbir zaman Google sunucularına gönderilmez veya burada saklanmaz. Bu, sağlanan güvenlik düzeylerinin donanım tabanlı, cihaz düzeyinde bir RoR sistemine benzer olmasını sağlayan sürece genel bir bakıştır:

  • Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında (TEE) depolanan anahtarlarla korunur.
  • TEE, anahtarları yalnızca, çalışan işletim sistemi şifreleme kimlik doğrulamasından geçerse ( doğrulanmış önyükleme ) serbest bırakır.
  • Google sunucularında çalışan RoR hizmeti, yalnızca sınırlı bir süre için alınabilecek bir sır saklayarak CE verilerini güvence altına alır. Bu, Android ekosisteminde çalışır.
  • Bir kullanıcının PIN'i tarafından korunan bir şifreleme anahtarı, cihazın kilidini açmak ve CE depolamasının şifresini çözmek için kullanılır.
    • Bir gecede yeniden başlatma planlandığında, Android kullanıcıdan PIN'ini girmesini ister ve ardından sentetik bir şifre (SP) hesaplar.
    • Ardından SP'yi iki kez şifreler: bir kez RAM'de depolanan bir K_s anahtarıyla ve tekrar TEE'de depolanan bir K_k anahtarıyla.
    • Çift şifreli SP diskte depolanır ve SP 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 sunucuya emanet eder. K_k ile alınan makbuz, diskte depolanmadan önce şifrelenir.
  • Yeniden başlatmanın ardından Android, makbuzun şifresini çözmek için K_k kullanır ve ardından K_s almak için onu sunucuya gönderir.
    • K_k ve K_s , diskte depolanan SP'nin şifresini çözmek için kullanılır.
    • Android, CE depolamasının kilidini açmak ve normal uygulama başlatmaya izin vermek için SP'yi kullanır.
    • K_k ve K_s atılır.

Telefonunuzu güvende tutan güncellemeler, sizin için uygun olan bir zamanda, yani siz uyurken gerçekleşebilir.

SIM-PIN tekrar oynatma

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

Etkinleştirilmiş bir PIN'e sahip bir SIM kart, hücresel bağlantıyı (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) yeniden başlatmak için katılımsız bir yeniden başlatmanın ardından sorunsuz bir PIN kodu doğrulamasından (SIM-PIN yeniden yürütme) geçmelidir. SIM PIN kodu ve eşleşen SIM kart bilgileri (ICCID ve SIM yuva numarası) birlikte güvenli bir şekilde saklanır. Depolanan PIN, yalnızca başarılı bir katılımsız yeniden başlatmanın ardından alınabilir ve doğrulama için kullanılabilir. Cihaz güvenliyse, SIM PIN kodu, LSKF tarafından korunan anahtarlarla birlikte saklanır. SIM'in PIN'i etkinse, RoR sunucusuyla etkileşim, OTA güncellemesi için bir WiFi bağlantısı ve yeniden başlatmanın ardından temel işlevsellik (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR gerektirir.

SIM PIN'i, kullanıcı her başarıyla etkinleştirdiğinde, doğruladığında veya değiştirdiğinde yeniden şifrelenir ve saklanır. Aşağıdakilerden herhangi biri meydana gelirse SIM PIN'i atılır:

  • SIM çıkarılır veya sıfırlanır.
  • Kullanıcı PIN'i devre dışı bırakır.
  • RoR tarafından başlatılmamış bir yeniden başlatma meydana geldi.

Saklanan SIM PIN'i, RoR tarafından başlatılan yeniden başlatmanın ardından yalnızca bir kez ve yalnızca çok kısa bir süre (20 saniye) için kullanılabilir – SIM kartının ayrıntıları eşleşirse. Depolanan SIM PIN'i TelephonyManager uygulamasından asla ayrılmaz ve harici modüller tarafından alınamaz.

Uygulama yönergeleri

Android 12'de, çok istemcili ve sunucu tabanlı RoR işlevleri, ortaklar OTA güncellemelerini zorladıklarında daha hafif bir yük sağlar. Belirlenen uyku saatleri gibi uygun cihaz kesintileri sırasında gerekli güncellemeler yapılabilir.

Bu tür zaman dilimlerinde OTA güncellemelerinin kullanıcıları kesintiye uğratmadığından emin olmak için ışık emisyonlarını azaltmak için karanlık modu kullanın. Bunu yapmak için, aygıt önyükleyicisinin unattended dize nedenini aramasını sağlayın. unattended true , cihazı karanlık moda getirin. Ses ve ışık emisyonlarını azaltmanın her bir OEM'in sorumluluğunda olduğunu unutmayın.

Android 12'ye yükseltiyorsanız veya Android 12 cihazlarını başlatıyorsanız, yeni RoR işlevini uygulamak için herhangi bir şey yapmanız gerekmez.

Çok müşterili akışta, aşağıda gösterilen isPreparedForUnattendedUpdate adlı yeni bir çağrı var:

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

HAL, Android 12'den itibaren kullanımdan kaldırıldığı için bunu uygulamanıza gerek yoktur.

Telefon Yöneticisi

OTA istemcisi, Android 12'de yeniden başlatma yaklaştığında TelephonyManager sistem API'sini çağırır. Bu API, önbelleğe alınmış tüm PIN kodlarını AVAILABLE durumundan REBOOT_READY durumuna taşır. TelephonyManager sistem API'si, mevcut REBOOT Manifest izniyle korunmaktadır.

 /**
    * 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 yapmak

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

    adb shell cmd phone unattended-reboot

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

Yalnızca Android 11

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

Temmuz 2020 itibariyle, RoR HAL uygulamaları iki kategoriye ayrılır:

  1. SoC donanımı, yeniden başlatmalar arasında RAM kalıcılığını destekliyorsa, OEM'ler AOSP'deki ( Varsayılan RAM Escrow ) varsayılan uygulamayı kullanabilir.
  2. Aygıt donanımı veya SoC, güvenli bir donanım yerleşim bölgesini (kendi RAM ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisi) destekliyorsa, ek olarak aşağıdakileri yapmalıdır:
    • Ana CPU yeniden başlatmasını algılayabilme.
    • Yeniden başlatmalar arasında devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, yerleşim bölgesi yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanmış bir zamanlayıcıyı sona erdirebilmelidir.
    • Çevrimdışı saldırılarla kurtarılamayacak şekilde, enclave RAM/ROM'da emanet edilmiş bir anahtarın saklanmasını destekler. RoR anahtarını, içeridekilerin veya saldırganların onu kurtarmasını imkansız kılacak şekilde saklamalıdır.

Varsayılan RAM Emanet

AOSP, RAM kalıcılığını kullanan bir RoR HAL uygulamasına sahiptir. Bunun çalışması için OEM'ler, SoC'lerinin yeniden başlatmalar arasında RAM kalıcılığını desteklediğinden emin olmalıdır. Bazı SoC'ler bir yeniden başlatma sırasında RAM içeriğini sürdüremezler, bu nedenle OEM'lerin bu varsayılan HAL'ı etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Aşağıdaki bölümde bunun için standart referans.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulaması, RoR'yi uygulamak için gerekli yöntemleri çağırmak için Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olmalıdır. Bu ön koşul yerine getirildiğinde, bir güncellemenin akışı şu adımları takip eder:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. OTA istemci uygulaması RecoverySystem#prepareForUnattendedUpdate çağırır ve bu, bir sonraki kilit açma işlemi sırasında kullanıcıdan PIN'i, deseni veya parolasının kilit ekranında sorulmasını tetikler.
  3. Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz, güncellemenin uygulanması için hazırdır.
  4. OTA istemci uygulaması, hemen yeniden başlatmayı tetikleyen RecoverySystem#rebootAndApply çağırır.

Bu akışın sonunda, cihaz yeniden başlatılır ve RoR mekanizması, kimlik bilgileri şifreli (CE) depolamasının kilidini açar. Uygulamalar için bu, normal bir kullanıcı kilidi açma işlemi olarak görünür, böylece normalde yaptıkları ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED gibi tüm sinyalleri alırlar.

Ürün konfigürasyonlarını değiştirme

Android 11'de RoR özelliğini desteklediği olarak işaretlenen bir ürün, RebootEscrow HAL uygulamasını içermeli ve özellik işaretleyici XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatma kullanan cihazlarda iyi çalışır (yeniden başlatma sırasında DRAM'in gücü açık kaldığında).

Emanet ö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 65536 (0x10000) bayt ayırmanız gerekir. Güvenlik özelliklerinin kalıcı olduğundan emin olmak için bu baytları asla geçici olmayan depolamaya yazmayın.

Linux çekirdeği aygıt ağacı değişiklikleri

Linux çekirdeğinin aygıt ağacında, bir pmem bölgesi için bellek ayırmanız gerekir. Aşağıdaki örnek, 0x50000000 rezerve edildiğini gösterir:

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

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

Blok dizininde /dev/block/pmem0 gibi bir ada sahip ( pmem1 veya pmem2 gibi) yeni bir aygıtınız olduğunu doğrulayın.

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 :

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

Bu yeni girişleri cihazın 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