Yeniden Başlatmada Devam Etme

Android 11, OTA güncellemeleri kullanılarak uygulanabilir A / B güncelleme ya da sanal bir A / B güncellemesi ile birlikte mekanizmaları, RecoverySystem sınıf yöntemleri. Bir cihaz OTA güncellemeyi uygulamak üzere yeniden başladıktan sonra, Devam-on-Yeniden Başlatma (KO) cihaz kilidini Kimlik Şifreli (CE) depolama .

İş ortakları bu işlemi, cihazın Android 11'de boşta kalması beklendiğinde güncellemeleri uygulayan bir OTA sistem özelliği ile eşleştirebilse de, Android 12'de iş ortaklarının ek bir OTA sistem özelliğine ihtiyacı yoktur. RoR işlemi, güncellemeler cihaz boştayken yapılabildiği için kullanıcılara ek güvenlik ve kolaylık sağlarken, Android 12 çok istemcili ve sunucu tabanlı güncelleme işlevleri birlikte cihaz donanım düzeyinde güvenlik sağlar.

İçin cihaz izni sağlamalıdır rağmen android.hardware.reboot_escrow Android 11'de RoR desteklemeye özelliği, Android 12'de sunucu tabanlı KO etkinleştirmek için bu kadar gerek ve yok daha yüksek, onlar HAL kullanmayın çünkü.

için cihaz izinleri sağlamak android.hardware.reboot_escrow özelliği. Android 12 ve sonraki sürümlerde HAL kullanılmadığından, Android 12'de sunucu tabanlı RoR'yi etkinleştirmek için herhangi bir şey yapmanız gerekmez.

Arka plan

Android 7 başlayarak, Android desteklenen Doğrudan Önyükleme CE depolama kullanıcı tarafından kilidini açmadan önce başlatmak için bir cihazdaki uygulamaları sağlayan,. Doğrudan Önyükleme desteğinin uygulanması, Kullanıcılara, bir önyüklemeden sonra girilmesi gereken Kilit Ekranı Bilgi Faktörü'nün (LSKF) öncesinde 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 izin verir. Bu özellik, kullanıcıların tüm yüklü uygulamalarından, yeniden başlatma sonrasında bildirim almalarını sağlar.

Tehdit modeli

RoR bir uygulama bir cihaz saldırganın eline düştüğünde saldırganın cihaz CE depolama kilidi, açık olsa bile, kullanıcının CE şifreli verileri kurtarmak için, son derece zor olduğunu sağlamalıdır ve cihaz tarafından açıldı Bir OTA güncellemesi aldıktan sonra kullanıcı. Saldırgan, yayın şifreleme imzalama anahtarlarına erişim kazansa bile içeriden saldırı direnci etkili olmalıdır.

Özellikle, CE depolama fiziksel cihazı var ve bu yetenekleri ve sınırlamaları vardır bir saldırgan tarafından okunamaz gerekir:

yetenekler

  • İsteğe bağlı 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.
  • (Bir uygulama işlemcisi veya flaş bellek gibi) herhangi bir donanım çalışmasını değiştirebilir - ayrıntılı olarak dışında Sınırlamalar altında. (Ancak, bu tür bir değişiklik hem en az bir saatlik 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, bir 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 RoR güncelleme sistemi, çok karmaşık 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 bir 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 saklanır tuşları ile korunmaktadır güvenilen yürütme ortamında (TEE).
  • Çalışan işletim sistemi kriptografik kimlik doğrulaması (doğrulanmış önyükleme) geçerse TEE sadece tuşları serbest bırakır.
  • Sadece sınırlı bir süre için alınabilir bir sırrı saklayarak, Google sunucularının güvenlik altına CE verilerine çalışan RoR hizmet. Bu, Android ekosisteminde çalışır.
  • Bir kullanıcının PIN'i tarafından korunan bir şifreleme anahtarı, cihazın kilidini açmak ve CE depolamasının şifresini çözmek için kullanılır.
    • Bir gecede yeniden başlatma planlandığında, Android kullanıcıdan PIN'ini girmesini ister ve ardından sentetik bir şifre (SP) hesaplar.
    • Daha sonra iki kez SP şifreler: bir anahtar ile bir kez K_s bir anahtarla tekrar RAM saklanan ve K_k TEE saklanan.
    • Çift şifreli SP diskte depolanır ve SP RAM'den silinir. Her iki anahtar Yeni oluşturulan ve sadece bir yeniden başlatma için kullanılır.
  • Yeniden başlatma için 's zaman, Android emanet zaman K_s sunucuya. İle makbuz K_k o diskte depolanan önce şifrelenir alır.
  • Yeniden başlattıktan sonra, Android kullanan K_k sonra, makbuz şifresini almak için sunucuya gönderir K_s .
    • K_k ve K_s diskte depolanan SP şifresini çözmek için kullanılır.
    • Android, CE depolamasının kilidini açmak ve normal uygulama başlatmaya 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şebilir.

SIM-PIN tekrar oynatma

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

Etkinleştirilmiş bir PIN'e sahip bir SIM kart, hücresel bağlantıyı (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) yeniden başlatmak için katılımsız bir yeniden başlatmanın ardından sorunsuz bir PIN kodu doğrulamasından (SIM-PIN yeniden yürütme) geçmelidir. SIM PIN kodu ve eşleşen SIM kart bilgileri (ICCID ve SIM yuva numarası) birlikte güvenli bir şekilde saklanır. Depolanan PIN, yalnızca başarılı bir katılımsız yeniden başlatmanın ardından alınabilir ve doğrulama için kullanılabilir. Cihaz güvenliyse, SIM PIN kodu, LSKF tarafından korunan anahtarlarla saklanır. SIM varsa onun PIN RoR sunucusu ile etkileşim yeniden başlatıldıktan sonra (cep telefonu bağlantısıyla) temel işlevlerini sağlayan OTA güncellemesi ve sunucu tabanlı RoR için bir WiFi bağlantısı gerektirir, sağladı.

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

  • SIM çıkarılır veya sıfırlanır.
  • Kullanıcı PIN'i devre dışı bırakır.
  • RoR tarafından başlatılmamış bir yeniden başlatma meydana geldi.

Kayıtlı olduğunu PIN yalnızca KO başlatılan yeniden sonra bir kez kullanılabilir ve sadece çok kısa bir zaman süresi (20 saniye) olabilir - SİM kartı maçın bilgi ise. Depolanan SIM PIN'i TelephonyManager uygulamasından asla ayrılmaz ve harici modüller tarafından alınamaz.

Uygulama yönergeleri

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

Bu tür zaman dilimlerinde OTA güncellemelerinin kullanıcıları kesintiye uğratmadığından emin olmak için ışık emisyonlarını azaltmak için karanlık modu kullanın. Bunu yapmak için, dize nedenle cihaz bootloader bulması unattended . Eğer unattended olduğu true , karanlık modunu kullanarak cihazı koydu. Ses ve ışık emisyonlarını azaltmanın her bir OEM'in sorumluluğunda olduğunu unutmayın.

Android 12'ye yükseltiyorsanız veya Android 12 cihazlarını başlatıyorsanız, yeni RoR işlevini uygulamak için herhangi bir şey yapmanız gerekmez.

Çok müşteri akışı, bir yeni çağrı var isPreparedForUnattendedUpdate Aşağıda gösterilen:

@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 istemci çağırır TelephonyManager yeniden başlatma Android 12. hamle tüm PIN kodlarını önbelleğe Bu API içinde yakın olduğu zaman sistem API AVAILABLE devlet REBOOT_READY devlet. TelephonyManager sistem API mevcut tarafından korunan REBOOT Manifest izni.

 /**
    * 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

Kabuk kökü (aynı çalışırken, bu komut çalışır adb root ).

Yalnızca Android 11

Bu sayfanın geri kalanı Android 11 için geçerlidir.

Temmuz 2020 itibariyle, RoR HAL uygulamaları iki kategoriye ayrılır:

  1. Yeniden doğmuş genelinde SoC donanım destekleri RAM kalıcılık, OEM AOSP varsayılan uygulamasını (kullanabiliyorsa Standart RAM Emanet ).
  2. Aygıt donanımı veya SoC, güvenli bir donanım yerleşim bölgesini (kendi RAM ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisi) destekliyorsa, ek olarak aşağıdakileri yapmalıdır:
    • Ana CPU yeniden başlatmasını algılayabilme.
    • Yeniden başlatmalar arasında devam eden bir donanım zamanlayıcı kaynağına sahip olun. Diğer bir deyişle, yerleşim yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanmış bir zamanlayıcıyı sona erdirebilmelidir.
    • Çevrimdışı saldırılarla kurtarılamayacak şekilde, enclave RAM/ROM'da emanet edilmiş bir anahtarın saklanmasını destekler. RoR anahtarını, içeridekilerin veya saldırganların onu kurtarmasını imkansız kılacak şekilde saklamalıdır.

Varsayılan RAM Emanet

AOSP, RAM kalıcılığını kullanan bir RoR HAL uygulamasına sahiptir. Bunun çalışması için OEM'ler, SoC'lerinin yeniden başlatmalar arasında RAM kalıcılığını desteklediğinden emin olmalıdır. Bazı SoC'ler bir yeniden başlatma sırasında RAM içeriğini sürdüremezler, bu nedenle OEM'lerin bu varsayılan HAL'ı etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Aşağıdaki bölümde bunun için standart referans.

RoR kullanarak OTA güncelleme akışı

Telefonda OTA istemci uygulaması olması gerekir Manifest.permission.REBOOT ve Manifest.permission.RECOVERY RoR uygulamak için gerekli yöntemleri çağırmak için izinleri. Bu ön koşul yerine getirildiğinde, güncelleme akışı şu adımları takip eder:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. İçin OTA istemci uygulaması çağrıları RecoverySystem#prepareForUnattendedUpdate kullanıcıyı tetikler sonraki kilidini sırasında kilit ekranında kendi PIN, desen veya şifre sorulmasını.
  3. Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz, güncellemenin uygulanması için hazırdır.
  4. OTA istemci uygulaması çağrıları RecoverySystem#rebootAndApply hemen yeniden başlatma tetikler.

Bu akışın sonunda, cihaz yeniden başlatılır ve RoR mekanizması, kimlik bilgileri şifreli (CE) depolamasının kilidini açar. Uygulamalar için, normal bir kullanıcı kilidini olarak bu göründüğünde, böylece gibi tüm sinyalleri almak ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED normal şekilde yaptıkları söyledi.

Ürün konfigürasyonlarını değiştirme

Android 11'de RoR özelliğini desteklediği olarak işaretlenen bir ürün, RebootEscrow HAL uygulamasını içermeli ve özellik işaretleyici XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatma 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ç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 65536 (0x10000) bayt ayırmanız gerekir. Güvenlik özelliklerinin kalıcı olduğundan emin olmak için bu baytları asla geçici olmayan depolamaya yazmayın.

Linux çekirdeği aygıt ağacı değişiklikleri

Linux çekirdeğinin aygıt ağacında, bir hafıza ayırmak gerekir pmem bölge. Aşağıdaki örnek, Şekil 0x50000000 rezervlenen:

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

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

Eğer böyle bir isimle blok dizinde yeni bir cihaz olduğunu doğrulayın /dev/block/pmem0 (örneğin pmem1 veya pmem2 ).

Device.mk değişiklikleri

Bir önceki adımdaki yeni cihaz adlı varsayarsak pmem0 , aşağıdaki yeni girişler eklenmiş olsun sağlamalıdır vendor/<oem>/<product>/device.mk :

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
SELinux kuralları

Cihazın bu yeni kayıt ekle file_contexts :

/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