Yeniden Başlatmada Devam Etme

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

İş ortakları bu süreci, Android 11'de cihazın boşta kalması beklendiğinde güncellemeleri uygulayan bir OTA sistemi özelliğiyle eşleştirebilse de, Android 12'de iş ortaklarının ek bir OTA sistemi özelliğine ihtiyacı yoktur. RoR işlemi, güncellemeler cihazın boşta kaldığı sürelerde yapılabildiği için kullanıcılara ek güvenlik ve kolaylık sağlarken, Android 12 çoklu istemci ve sunucu tabanlı güncelleme işlevleri birlikte cihaz donanım düzeyinde türde güvenlik sağlıyor.

Android 11'de RoR'u desteklemek için android.hardware.reboot_escrow özelliği için cihaz izni vermeniz gerekse de Android 12 ve üzeri sürümlerde sunucu tabanlı RoR'u etkinleştirmek için bunu yapmanıza gerek yoktur çünkü bunlar HAL kullanmaz.

Arka plan

Android 7'den başlayarak, Android, CE depolamasının kilidi kullanıcı tarafından açılmadan önce cihazdaki uygulamaların başlatılmasını sağlayan Direct Boot'u destekledi. Doğrudan Önyükleme desteğinin uygulanması, önyükleme sonrasında Kilit Ekranı Bilgi Faktörünün (LSKF) girilmesi gerekmeden önce Kullanıcılara 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 olanak tanır. Bu özellik, kullanıcıların yüklü tüm uygulamalarından ve yeniden başlatma sonrasında bildirim almalarına olanak tanır.

Tehdit modeli

RoR uygulaması, bir cihaz saldırganın eline geçtiğinde, cihaz açık olsa, CE depolamasının kilidi açılmış olsa ve cihazın kilidi açık olsa bile saldırganın kullanıcının CE şifreli 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 gelen saldırı direncinin etkili olması gerekir.

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

Yetenekler

  • Rastgele 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ılı olarak açıklananlar dışında, herhangi bir donanımın (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 bir 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 Titan M) çalışması değiştirilemez.
  • Canlı cihazın RAM'i okunamıyor.
  • Kullanıcının kimlik bilgileri (PIN, desen, şifre) tahmin edilemez veya başka bir şekilde girilmesine neden olunamaz.

Çözüm

Android 12 RoR güncelleme sistemi, çok gelişmiş 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 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) saklanan anahtarlarla korunur.
  • TEE, yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamayı ( doğrulanmış önyükleme ) geçerse anahtarları 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ırrı saklayarak CE verilerini korur. Bu, Android ekosisteminde çalışır.
  • Kullanıcının PIN koduyla korunan bir şifreleme anahtarı, cihazın kilidini açmak ve CE deposunun şifresini çözmek için 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 saklanan bir K_s anahtarıyla ve tekrar TEE'de saklanan bir K_k anahtarıyla.
    • Çift şifreli SP diskte saklanır ve SP RAM'den silinir. Her iki anahtar da yeni oluşturuldu ve yalnızca bir yeniden başlatma için kullanıldı.
  • Yeniden başlatma zamanı geldiğinde Android, K_s sunucuya emanet eder. K_k içeren makbuz, diskte saklanmadan ö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 bunu 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 uygulamanın normal şekilde başlatılmasına 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ştirilebilir.

SIM-PIN tekrarı

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

Etkin PIN'e sahip bir SIM kartın, hücresel bağlantıyı (telefon çağrıları, SMS mesajları ve veri hizmetleri için gerekli) geri yüklemek için gözetimsiz bir yeniden başlatmanın ardından kesintisiz bir PIN kodu doğrulamasından (SIM-PIN tekrarı) geçmesi gerekir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Saklanan PIN, yalnızca başarılı bir gözetimsiz yeniden başlatmanın ardından alınabilir ve doğrulama için kullanılabilir. Cihaz güvenliyse SIM PIN'i, 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şlevleri (hücresel bağlantıyla) sağlayan sunucu tabanlı RoR gerektirir .

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

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

Saklanan SIM PIN, 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 için (20 saniye) kullanılabilir; SIM kartın ayrıntıları eşleşirse . Saklanan SIM PIN hiçbir zaman TelephonyManager uygulamasından çıkmaz ve harici modüller tarafından alınamaz.

Uygulama yönergeleri

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

Bu tür zaman aralıklarında OTA güncellemelerinin kullanıcıları kesintiye uğratmamasını sağlamak amacıyla ışık emisyonlarını azaltmak için karanlık modu kullanın. Bunu yapmak için, cihazın önyükleyicisinin, unattended dizesinin nedenini aramasını sağlayın. unattended true cihazı karanlık moda geçirin. Ses ve ışık emisyonlarını azaltmanın her OEM'in sorumluluğunda olduğunu unutmayın.

Android 12'ye yükseltme yapıyorsanız veya Android 12 cihazlarını başlatıyorsanız yeni RoR işlevini uygulamak için herhangi bir şey yapmanıza gerek yoktur.

Çok istemcili akışta aşağıda gösterilen isPreparedForUnattendedUpdate 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 sistemi 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 itibarıyla RoR HAL uygulamaları iki kategoriye ayrılmaktadır:

  1. SoC donanımı, yeniden başlatmalar sırasında RAM kalıcılığını destekliyorsa, OEM'ler AOSP'deki ( Varsayılan RAM Escrow ) varsayılan uygulamayı kullanabilir.
  2. Cihaz donanımı veya SoC, güvenli bir donanım bölgesini (kendi RAM ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisi) destekliyorsa, ayrıca aşağıdakileri de yapmalıdır:
    • Ana CPU'nun yeniden başlatılmasını tespit edebilme.
    • Yeniden başlatmalarda devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, yerleşim biriminin yeniden başlatmayı algılayabilmesi ve yeniden başlatmadan önce ayarlanan zamanlayıcının süresini doldurabilmesi gerekir.
    • Emanet edilmiş bir anahtarın, çevrimdışı saldırılarla kurtarılamayacak şekilde RAM/ROM'da saklanmasını destekleyin. RoR anahtarını, içerideki kişilerin veya saldırganların onu kurtarmasını imkansız kılacak şekilde saklamalıdır.

Varsayılan RAM emaneti

AOSP, RAM kalıcılığını kullanan bir RoR HAL uygulamasına sahiptir. Bunun işe yaraması için OEM'lerin SoC'lerinin yeniden başlatmalar sırasında RAM kalıcılığını desteklediğinden emin olması gerekir. Bazı SoC'ler, yeniden başlatma sırasında RAM içeriğini sürdüremediğinden, OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Bunun için kanonik referans aşağıdaki bölümde yer almaktadır.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulamasının, RoR'yi uygulamaya yönelik gerekli yöntemleri çağırabilmesi için Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olması gerekir. Bu önkoşul yerine getirildiğinde güncelleme akışı şu adımları izler:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. OTA istemci uygulaması RecoverySystem#prepareForUnattendedUpdate çağırır ve bu, bir sonraki kilit açma sırasında kullanıcıya kilit ekranında PIN'inin, deseninin veya şifresinin sorulmasını tetikler.
  3. Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz, güncellemenin uygulanmasına hazır hale gelir.
  4. OTA istemci uygulaması, hemen yeniden başlatmayı tetikleyen RecoverySystem#rebootAndApply öğesini çağırır.

Bu akışın sonunda cihaz yeniden başlatılır ve RoR mekanizması kimlik bilgileri şifreli (CE) depolamanın kilidini açar. Uygulamalar için bu, normal bir kullanıcı kilidi açma işlemi olarak görünür, dolayısıyla 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ştirin

Android 11'de RoR özelliğini desteklediği şeklinde işaretlenen bir ürün, RebootEscrow HAL'nin bir uygulamasını içermeli ve özellik işaretleyici XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatmayı 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çisinin de mevcut olması gerekir:

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ırmalısınız. Güvenlik özelliklerinin devam etmesini sağlamak için bu baytları asla kalıcı 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 örnekte 0x50000000 rezerve edildiği gösterilmektedir:

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

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

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

Device.mk değişiklikleri

Önceki adımdaki yeni cihazınızın pmem0 olarak adlandırıldığını varsayarak, vendor/<oem>/<product>/device.mk dosyasına aşağıdaki yeni girişlerin eklendiğinden emin olmalısınız:

# 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 dosyasına 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