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 üzere yeniden başlatıldıktan sonra, Yeniden Başlatmada Devam Ettirme (RoR), cihazın Şifrelenmiş Kimlik Bilgisi (CE) depolama alanı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ğiyle eşleyebilir. Ancak Android 12'deki 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, bir OA güncellemesinden sonra yeniden başlatma başlatıldığında Doğrudan Başlatma'yı desteklemeyenler de dahil olmak üzere bir cihazdaki tüm uygulamaların CE depolama kilidinin açılmasına olanak tanır. Bu özellik, kullanıcıların yeniden başlatma sonrasında yüklü tüm uygulamalardan bildirim almaları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 yayın kriptografik imzalama anahtarlarına erişim sağlasa bile çalışanların saldırılarına karşı direnç etkili olmalıdır.

Özellikle, CE depolama alanı fiziksel olarak cihaza sahip olan, aşağıdaki özelliklere ve sınırlamalara sahip olan bir saldırgan tarafından okumamalı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 ayrıntılı olarak açıklanan durumlar dışında, herhangi bir donanımın (uygulama işlemcisi veya flash bellek gibi) çalışmasını değiştirebilir. (Bununla birlikte, bu tür değiştirme işlemi hem en az bir saatlik gecikmeyi hem de RAM içeriklerini yok eden bir açma döngüsünü içerir.)

Sınırlamalar

  • Değişikliğe karşı korumalı donanımın (ör. Titan M) çalışma şekli değiştirilemez.
  • Canlı cihazın RAM'i okunamıyor.
  • Kullanıcının kimlik bilgilerini (PIN, desen, şifre) tahmin edemez veya bu bilgilerin girilmesine neden olamaz.

Çözüm

Android 12 RoR güncelleme sistemi çok ileri düzey saldırganlara karşı güvenlik sağlar. Cihaz üzerindeki şifreler ve PIN'ler cihazda kalırken bunlar hiçbir zaman Google sunucularına gönderilmez veya saklanmaz. Burada, sağlanan güvenlik düzeylerinin donanım tabanlı, cihaz düzeyindeki 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ğrulamayı geçerse (doğrulanmış başlatma) 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.
    • Daha sonra, SP'yi iki kez şifreler: bir kez RAM'de depolanan bir K_s anahtarı ve ikincisi de TEE'de depolanan bir K_k anahtarı ile.
    • Ç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. K_k ile gönderilen makbuz, diskte depolanmadan ö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 uygulamanın başlatılmasına izin vermek için SP'yi kullanır.
    • K_k ve K_s silindi.

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

SIM-PIN'i tekrar 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. Saklanan PIN yalnızca başarılı bir müdahalesiz yeniden başlatma sonrasında 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, kullanıcı tarafından başarıyla her etkinleştirildiğinde, doğrulandığında veya değiştirdiğinde yeniden şifrelenir ve saklanır. SIM PIN'i, aşağıdakilerden herhangi biri gerçekleşirse silinir:

  • 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 bir kez sonra ve yalnızca çok kısa bir süre (20 saniye) boyunca (SIM kart eşleşmesi ayrıntıları geçerliyse kullanılabilir) kullanılabilir. Saklanan SIM PIN'i, TelephonyManager uygulamasından hiçbir zaman dışarı çı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 aktaran iş ortaklarına daha hafif bir yük sağlar. Gerekli güncellemeler, cihazın uygun kapalı olduğu zamanlarda (ör. belirlenen uyku saatleri sırasında) 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 değeri true ise cihazı koyu moda getirin. 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ılacağı 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 REBOOTManifest 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 etme

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şlatmalar arasında RAM kalıcılığını destekliyorsa OEM'ler AOSP'deki varsayılan uygulamayı (Varsayılan RAM Escrow) kullanabilir.
  2. Cihaz donanımı veya Çip üzerinde sistem (SoC) güvenli bir donanım enclave'yi (kendi RAM'ine ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisini) destekliyorsa ayrıca şunları da yapmalıdır:
    • 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. Diğer bir deyişle, enclave yeniden başlatmayı algılayabilmeli ve yeniden başlatma işleminden önce ayarlanan bir zamanlayıcıyı sürebilmelidir.
    • Çevrimdışı saldırılarla kurtarılamayacak şekilde enclave RAM/ROM'da depolanması desteği. RoR anahtarını, kuruluş içinden kişilerin veya saldırganların kurtarmasını imkansız hale getirecek şekilde depolamalıdır.

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 yeniden başlatmalarda 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üremez. 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ının, RoR'yi uygulamak için gerekli yöntemlerin çağırılması amacıyla Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olması gerekir. 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 numarasını çağırır. Bu çağrı, bir sonraki kilit açma işleminde kullanıcıdan kilit ekranında PIN, desen veya şifresinin istenmesini tetikler.
  3. Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz güncelleme uygulanmaya hazırdır.
  4. RecoverySystem#rebootAndApply işlemine çağrı yapan OTA istemci uygulaması, hemen 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 bu işlem normal bir kullanıcı kilidi olarak görünür. Böylece kullanıcılar, normalde yaptıkları ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED gibi tüm sinyalleri alır.

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

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 /dev/block/pmem0 gibi bir ada (pmem1 veya pmem2) sahip yeni bir cihazı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ı varsayarsak aşağıdaki yeni girişlerin vendor/<oem>/<product>/device.mk ürününe eklenmesini sağlamalı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ı

Ş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