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

Android 11'de OTA güncellemeleri, RecoverySystem sınıfı yöntemleriyle birlikte A/B güncelleme veya sanal A/B güncelleme mekanizmaları kullanılarak uygulanabilir. 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. Güncellemeler cihazın boşta olduğu zamanlarda yapılabildiği için RoR işlemi kullanıcılara ek güvenlik ve kolaylık sunarken Android 12'nin çok istemcili ve sunucu tabanlı güncelleme işlevleri bir arada cihaz donanım düzeyinde güvenlik sağlar.

Android 11'de RoR'yi desteklemek için android.hardware.reboot_escrow özelliğine cihaz izni vermeniz gerekir. Ancak HAL kullanmadığı için Android 12 ve sonraki sürümlerde sunucu tabanlı RoR'yi etkinleştirmek için bunu yapmanız gerekmez.

Arka plan

Android 7'den başlayarak Android, kullanıcı CE depolama alanının kilidini açmadan önce cihazdaki uygulamaların başlatılmasını sağlayan Doğrudan Başlatma özelliğini destekliyor. Doğrudan Başlatma desteğinin uygulanması, kullanıcıların başlatma işleminden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesinden önce daha iyi bir deneyim yaşamasını sağladı.

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 yeniden başlatma işleminden sonra yüklü tüm uygulamalarından bildirim almasını sağlar.

Tehdit modeli

RoR uygulaması, bir cihaz saldırganın eline düştüğünde, cihaz açık, CE depolama alanının ve bir OTA güncellemesi aldıktan sonra kullanıcı tarafından cihazın kilidinin açılsa bile kullanıcının CE ile şifrelenmiş verilerini kurtarmasının son derece zor olmasını sağlamalıdır. Saldırgan, şifreleme anahtarlarına erişse bile kuruluş içinden saldırılara karşı direnç etkin olmalıdır.

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.
  • Aşağıdaki Sınırlamalar bölümünde belirtilenler hariç olmak üzere herhangi bir donanımın (ör. uygulama işlemcisi veya flash bellek) çalışmasını değiştirebilir. (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

  • Kurcalamaya dayanıklı donanımın (ör. 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'deki RoR güncelleme sistemi, çok gelişmiş saldırganlara karşı güvenlik sağlar. Bu işlemi yaparken cihazdaki şifreler ve PIN'ler cihazda kalır, hiçbir zaman Google sunucularına gönderilmez veya bu sunucularda saklanmaz. Aşağıda, 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ış sunulmaktadı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 kriptografik kimlik doğrulamasını (doğrulanmış başlatma) geçerse serbest bırakır.
  • Google sunucularında çalışan RoR hizmeti, yalnızca sınırlı bir süre için alınabilen bir gizli anahtarı depolayarak CE verilerinin güvenliğini sağlar. 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'i ile korunan bir şifreleme 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.
    • Ardından SP'yi iki kez şifreler: Bir kez RAM'de depolanan K_s anahtarıyla, bir kez de TEE'de depolanan K_k anahtarıyla.
    • Çift şifrelenmiş SP diskte depolanır ve servis sağlayıcı da RAM'den silinir. Her iki anahtar da yeni oluşturulmuş 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. K_k içeren makbuz, diske kaydedilmeden önce şifrelenir.
  • Yeniden başlatmadan sonra Android, makbuzun şifresini çözmek için K_k kullanır, ardından K_s kodunu almak için 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.

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

SIM PIN'i yeniden oynatma

Belirli koşullar altında SIM kartın PIN kodu bir önbellekten doğrulanır. Bu işlem, SIM PIN'ini tekrar oynatma olarak adlandırılır.

PIN etkinleştirilmiş bir SIM kart da, hücresel bağlantının yeniden başlatılması için (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) gözetimsiz yeniden başlatma sonrasında sorunsuz bir PIN kodu doğrulamasından (SIM PIN tekrarı) geçmelidir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Depolanan PIN, yalnızca gözetimsiz olarak başarıyla yeniden başlatıldıktan sonra alınabilir ve doğrulama için kullanılabilir. Cihazın güvenliği sağlandığında SIM PIN'i, LSKF tarafından korunan anahtarlarla birlikte saklanır. SIM'in PIN'i etkinleştirilmişse RoR sunucusuyla etkileşim, OTA güncellemesi için kablosuz bağlantı ve yeniden başlatma sonrasında temel işlevselliği (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR'yi gerektirir.

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

  • SIM kart çıkarılır 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 bir kez sonra ve yalnızca çok kısa bir süre (20 saniye) boyunca (SIM kartın ayrıntıları uyuştuğunda kullanılabilir) kullanılabilir. Depolanan SIM PIN'i hiçbir zaman TelephonyManager uygulamasından çıkmaz ve harici modüller tarafından alınamaz.

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 sürelerde OTA güncellemelerinin kullanıcıları rahatsız etmemesi için koyu mod kullanarak ışık emisyonlarını azaltın. Bunu yapmak için cihaz bootloader'ının unattended dize nedenini aramasını sağlayın. unattended true ise cihazı koyu moda alın. Ses ve ışık emisyonlarını azaltmanın OEM'ler kendi sorumluluğunda 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 çağrı (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, Android 12 ile birlikte kullanımdan kaldırıldığı için bu yöntemi uygulamanız gerekmez.

Telefon Yöneticisi

OTA istemcisi, Android 12'de yeniden başlatma işlemi yaklaştığında TelephonyManager sistem API'sini çağırır. Bu API, önbelleğe alınan tüm PIN kodlarını AVAILABLE durumundan REBOOT_READY durumuna taşır. 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 geri kalanı Android 11 için geçerlidir.

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

  1. SoC donanımı, yeniden başlatmalarda RAM'in kalıcılığını destekliyorsa OEM'ler AOSP'deki varsayılan uygulamayı (Varsayılan RAM Escrow) kullanabilir.
  2. Cihaz donanımı veya SoC, güvenli donanım korumalı alanını (kendi RAM ve ROM'u olan ayrı bir güvenlik yardımcı işlemcisi) destekliyorsa aşağıdakileri de yapmalıdır:
    • Ana CPU'nun yeniden başlatıldığını algılayabilir.
    • Yeniden başlatmalarda devam eden bir donanım zamanlayıcı kaynağına sahip olun. Diğer bir deyişle, enclave yeniden başlatma işlemini algılayabilmeli ve yeniden başlatma işleminden önce ayarlanan bir zamanlayıcıyı sona erdirebilmelidir.
    • Çevrimdışı saldırılarla kurtarılamayacak şekilde enclave RAM/ROM'da depolanması desteği. RoR anahtarını, şirket içinden kişilerin veya saldırganların kurtarmasını imkansız kılacak şekilde saklamalıdır.

Varsayılan RAM emanet

AOSP, RAM'de kalıcı olan RoR HAL'i uygular. 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. Bunun için kanon referansı aşağıdaki bölümde verilmiştir.

RoR'yi kullanan OTA güncellemesi akışı

Telefondaki OTA istemci uygulaması, RoR'yi uygulamak için gerekli yöntemlerin çağırılması amacıyla Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olmalıdır. Bu ön koş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. Bu, 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, güncellemenin uygulanmasına hazır olur.
  4. OTA istemci uygulaması RecoverySystem#rebootAndApply'e çağrı gönderir ve bu da hemen yeniden başlatmayı 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 desteklediğini belirten bir ürün, RebootEscrow HAL uygulamasını ve özellik işaretçisi XML dosyasını içermelidir. Varsayılan uygulama, hazır durumda yeniden başlatma kullanan cihazlarda (yeniden başlatma sırasında DRAM'nin gücü açık kaldığında) iyi sonuç verir.

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 (0x10000) bayt ayırmanız gerekir. Güvenlik özelliklerinin korunmasını sağlamak için bu baytları hiçbir zaman kalıcı olmayan depolama alanına yazmayın.

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 rezervasyonu gösterilmektedir:

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

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

Engelleme dizininde /dev/block/pmem0 gibi bir ada (ör. pmem1 veya pmem2) sahip yeni bir cihazınızın 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 vendor/<oem>/<product>/device.mk'a aşağıdaki yeni girişlerin eklendiğinden emin olmanız gerekir:

# 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