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

Android 11'de OTA güncellemeleri, A/B güncelleme veya sanal A/B güncelleme mekanizmaları kullanılarak RecoverySystem sınıfı yöntemleriyle birlikte uygulanabilir. Bir cihaz, OTA güncellemesini uygulamak için yeniden başlatıldıktan sonra, yeniden başlatmada devam ettirme (RoR) özelliği cihazın kimlik bilgisi şifrelenmiş (CE) depolama alanının kilidini açar.

İş ortakları bu süreci, Android 11'de cihazın boşta kalması beklendiği zaman güncellemeleri uygulayan bir OTA sistem özelliğiyle eşleştirebilse de Android 12'de ek bir OTA sistem özelliğine ihtiyaç duymazlar. RoR süreci, güncellemeler cihaz boşta kaldığı zamanlarda yapılabildiğinden kullanıcılara ek güvenlik ve kolaylık sağlar. Android 12'nin çok istemcili ve sunucu tabanlı güncelleme işlevleri ise 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 gerekse de Android 12 ve sonraki sürümlerde sunucu tabanlı RoR'yi etkinleştirmek için bu izni vermeniz gerekmez. Bunun nedeni, bu sürümlerde HAL'in kullanılmamasıdır.

Arka plan

Android 7'den itibaren Android, Doğrudan Başlatma'yı desteklemeye başladı. Bu özellik, cihazdaki uygulamaların kullanıcı tarafından CE depolama alanı kilidi açılmadan önce başlatılmasını sağlar. Doğrudan başlatma desteğinin uygulanması, kullanıcılara başlatma işleminden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesi gerekmeden önce daha iyi bir deneyim sunuyordu.

RoR, bir OTA güncellemesinden sonra yeniden başlatma işlemi yapıldığında, Direct Boot'u desteklemeyenler de dahil olmak üzere bir 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 almalarını sağlar.

Tehdit modeli

RoR uygulaması, bir cihaz saldırganın eline geçtiğinde saldırganın, cihaz açık olsa, CE depolama alanı kilidi açılmış olsa ve cihaz OTA güncellemesi aldıktan sonra kullanıcı tarafından 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, yayın kriptografik imza anahtarlarına erişse bile içeriden saldırıya karşı direnç etkili olmalıdır.

Özellikle, 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 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 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, en az bir saatlik gecikmenin yanı sıra RAM içeriklerini yok eden bir güç döngüsü içerir.)

Sınırlamalar

• Kurcalamaya karşı korumalı donanımın (ör. Titan M) çalışması değiştirilemez.
• Canlı cihazın RAM'i okunamıyor.
• Kullanıcının kimlik bilgilerini (PIN, desen, şifre) tahmin edemez veya başka bir şekilde girilmelerine neden olamaz.

Çözüm

Android 12 RoR güncelleme sistemi, çok karmaşık saldırganlara karşı güvenlik sağlar. Bunu yaparken cihazdaki şifreler ve PIN'ler cihazda kalır. Hiçbir zaman Google sunucularına gönderilmez veya bu sunucularda depolanmaz. Bu, sağlanan güvenlik düzeylerinin donanıma dayalı, cihaz düzeyinde bir RoR sistemiyle benzer olmasını sağlayan sürecin genel bir bakışıdır:

• Android, 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ış başlatma) geçerse anahtarları yayınlar.
• Google sunucularında çalışan RoR hizmeti, yalnızca sınırlı bir süre için alınabilen bir sır saklayarak CE verilerini güvence altına alır. 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 şifreleme anahtarı kullanılır.
  • Gece yeniden başlatma işlemi 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 anahtarla K_s, bir kez de TEE'de depolanan bir anahtarla K_k.
  • Ç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şlemi için kullanılır.
• Yeniden başlatma zamanı geldiğinde Android, K_s değerini sunucuya emanet eder. K_k içeren makbuz, diske depolanmadan önce şifrelenir.
• Yeniden başlatma işleminden sonra Android, makbuzu şifre çözmek için K_k kullanır ve ardından K_s almak üzere 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 uygulamaların normal şekilde başlatılması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, size uygun bir zamanda (ör. uyurken) yapılabilir.

SIM PIN'ini yeniden oynatma

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

PIN'i etkinleştirilmiş bir SIM kartın, hücresel bağlantıyı geri yüklemek için (telefon görüşmeleri, SMS mesajları ve veri hizmetleri için gereklidir) gözetimsiz yeniden başlatma işleminden sonra sorunsuz bir PIN kodu doğrulaması (SIM PIN'i tekrarı) yapması da gerekir. 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 başarılı bir katılımsız yeniden başlatma işleminden sonra alınabilir ve doğrulama için kullanılabilir. Cihaz güvenli ise SIM PIN, LSKF tarafından korunan anahtarlarla birlikte depolanır. SIM kartın PIN'i etkinse OTA güncellemesi ve sunucu tabanlı RoR için RoR sunucusuyla etkileşimde bulunmak için kablosuz bağlantı gerekir. Bu, yeniden başlatmanın ardından temel işlevlerin (hücresel bağlantıyla) kullanılabilmesini sağlar.

SIM PIN kodu, kullanıcı tarafından her başarıyla etkinleştirildiğinde, doğrulandığında veya değiştirildiğinde yeniden şifrelenir ve saklanır. Aşağıdakilerden herhangi biri gerçekleşirse SIM PIN atılır:

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

Depolanan SIM PIN, 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) için kullanılabilir. Bu durum, SIM kartın ayrıntıları eşleştiği takdirde geçerlidir. Depolanan 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üncellemeleri gönderilirken iş ortaklarına daha az yük bindirir. Gerekli güncellemeler, cihazın uygun şekilde kapalı olduğu zamanlarda (ör. uyku saatlerinde) yapılabilir.

Bu tür dönemlerde OTA güncellemelerinin kullanıcıları kesintiye uğratmaması için ışık emisyonunu azaltmak üzere koyu modu kullanın. Bunu yapmak için cihazın önyükleyicisinin unattended dizesini aramasını sağlayın. unattended, true ise cihazı koyu moda geçirin. Ses ve ışık emisyonlarını azaltmanın her OEM'nin sorumluluğunda olduğunu unutmayın.

Android 12'ye yükseltme yapıyorsanız 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ı var: isPreparedForUnattendedUpdate. Bu çağrı aşağıda gösterilmiştir:

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

Android 12'den itibaren HAL desteği sonlandırıldığından 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ınmış tüm PIN kodlarını AVAILABLE durumundan REBOOT_READY durumuna taşır. TelephonyManager sistemi 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 olarak çalışırken (adb root) kullanılabilir.

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şlatma işlemleri sırasında RAM kalıcılığını destekliyorsa OEM'ler AOSP'deki varsayılan uygulamayı (Varsayılan RAM Emaneti) kullanabilir.
2. Cihaz donanımı veya SoC, güvenli donanım alanı (kendi RAM ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisi) destekliyorsa ek olarak aşağıdakileri yapması gerekir:
   • Ana CPU'nun yeniden başlatıldığını algılayabilme
   • Yeniden başlatma işlemlerinde kalıcı olan bir donanım zamanlayıcı kaynağına sahip olmalıdır. Yani güvenli alan, yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanan bir zamanlayıcının süresini sona erdirebilmelidir.
   • Bir emanet anahtarının, çevrimdışı saldırılarla kurtarılamayacak şekilde güvenli bölge RAM/ROM'unda depolanmasını destekler. RoR anahtarını, içerideki kişilerin veya saldırganların kurtarmasını imkansız kılacak şekilde saklamalıdır.

Varsayılan RAM emaneti

AOSP'de RAM kalıcılığı kullanılarak RoR HAL'nin bir uygulaması bulunur. Bu özelliğin çalışması için OEM'lerin, SoC'lerinin yeniden başlatma işlemleri sırasında RAM kalıcılığını desteklediğinden emin olması gerekir. Bazı çip üzerinde sistemler, yeniden başlatma işlemi sırasında RAM içeriklerini koruyamaz. Bu nedenle, OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce çip üzerinde sistem iş ortaklarına danışmaları önerilir. Bu konudaki resmi referans, aşağıdaki bölümde verilmiştir.

RoR kullanılarak OTA güncelleme akışı

Telefondaki OTA istemci uygulamasının, RoR'yi uygulamak için gerekli yöntemleri çağırmak üzere Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olması gerekir. Bu ön koşul karşılandığında, güncelleme akışı şu adımları izler:

1. OTA istemci uygulaması güncellemeyi indirir.
2. OTA istemci uygulaması, RecoverySystem#prepareForUnattendedUpdate numaralı telefonu aradığında kullanıcıdan bir sonraki kilit açma işleminde kilit ekranında PIN, desen veya şifre girmesi istenir.
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'yı çağırır ve bu işlem hemen yeniden başlatmayı tetikler.

Bu akışın sonunda cihaz yeniden başlatılır ve RoR mekanizması, kimliği şifrelenmiş (CE) depolama alanının kilidini açar. Bu işlem, uygulamalar için normal bir kullanıcı kilidi açma işlemi olarak görünür. Bu nedenle, uygulamalar normalde aldıkları tüm sinyalleri (ör. ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED) alır.

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

Android 11'de RoR özelliğini desteklediği belirtilen bir üründe RebootEscrow HAL uygulaması ve özellik işaretleyici XML dosyası bulunmalıdır. Varsayılan uygulama, sıcak yeniden başlatma kullanan cihazlarda iyi çalışır (yeniden başlatma sırasında DRAM'e güç verilmeye devam eder).

Yeniden başlatma emanet özelliği 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 65536 (0x10000) bayt ayırmanız gerekir. Güvenlik özelliklerinin kalıcı olması için bu baytları asla kalıcı olmayan depolama alanına yazmayın.

Linux çekirdek cihaz ağacı değişiklikleri

Linux çekirdeğinin cihaz ağacında, pmem bölgesi için bellek ayırmanız gerekir. Aşağıdaki örnekte 0x50000000 öğesinin nasıl ayrıldığı 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 (ör. pmem1 veya pmem2) gibi bir ada 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 vendor/<oem>/<product>/device.mk'ye 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ı

Bu 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