Yeniden başlatıldığında devam ettirme

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. RoR süreci, güncellemeler cihazın boş olduğu zamanlarda yapılabildiği için kullanıcılara ek güvenlik ve kolaylık sağlar. Android 12'nin çok istemcili ve sunucuya dayalı güncelleme işlevleri ise 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 vermeniz gerekir. Ancak Android 12 ve sonraki sürümlerde sunucu tabanlı RoR'yi etkinleştirmek için bunu yapmanız gerekmez. Çünkü bu sürümlerde HAL kullanılmaz.

Arka plan

Android 7'den itibaren Android, kullanıcı tarafından CE depolama alanının kilidi açılmadan önce cihazdaki uygulamaların başlatılmasını sağlayan Doğrudan Başlatma özelliğini destekledi. Doğrudan önyükleme desteğinin uygulanması, önyükleme işleminden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesi gerekmeden önce kullanıcılara daha iyi bir deneyim 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'nin uygulanması, bir cihaz saldırganın eline geçtiğinde saldırganın, cihaz açık olsa, CE depolama alanının kilidi açılmış olsa ve OTA güncellemesi aldıktan sonra kullanıcı tarafından cihazın kilidi açılmış olsa 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ç etkili 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 iletileri imzalamak için herhangi bir tedarikçinin 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 açıklananlar 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, cihazda depolanan verilere kriptografik korumalar uygular.
• Tüm veriler, güvenilir yürütme ortamında (TEE) saklanan 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 boyunca alınabilen bir gizli anahtar saklayarak CE verilerini korur. Bu özellik Android ekosisteminde kullanılabilir.
• 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.
  • 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 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 içeren makbuz, diske kaydedilmeden ö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, sizin için uygun bir zamanda (uyurken) yapılabilir.

SIM PIN'i yeniden 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. 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 güvendeyse SIM PIN'i, LSKF tarafından korunan anahtarlarla birlikte depolanı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, 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.

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. 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 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 geçirin. 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, aşağıda gösterilen isPreparedForUnattendedUpdate adlı yeni bir çağrı vardır:

@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ız gerekmez.

TelephonyManager

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 root (adb root) olarak çalışırken çalışır.

Yalnızca Android 11

Bu sayfanın geri kalanı 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ş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şlatma işlemlerinde devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, çip, yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanan bir zamanlayıcının süresini doldurmalıdır.
   • Emanet anahtarının, çevrimdışı saldırılarla kurtarılamayacak şekilde çip RAM/ROM'de depolanmasını destekler. 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 kullanan OTA güncellemesi akışı

Telefondaki OTA istemci uygulamasında, RoR'yi uygulamak için gerekli yöntemleri çağırabilmek üzere Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinleri olmalıdır. Bu ön koşul sağlandığında güncelleme akışı aşağıdaki 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ış sonunda cihaz yeniden başlatılır ve RoR mekanizması, şifrelenmiş kimlik bilgisi (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, ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED gibi normalde aldıkları tüm sinyalleri alırlar.

Ürün yapılandırmalarını değiştirme

Android 11'de RoR özelliğini desteklediği işaretlenen bir ürün, RebootEscrow HAL'nin bir uygulamasını ve özellik işaretçisi XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatma kullanan cihazlarda (yeniden başlatma sırasında DRAM'e güç verildiğinde) iyi çalışır.

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

Ö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. Güvenlik özelliklerinin korunmasını sağlamak için bu baytları asla 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, 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 /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ı

Aşağıdaki 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