Yeniden Başlatmada Devam Etme

Android 11'de OTA güncellemeleri, RecoverySystem sınıf yöntemleriyle birleştirilmiş A/B güncellemesi veya sanal A/B güncelleme mekanizmaları kullanılarak uygulanabilir. Bir cihaz, bir OTA güncellemesini uygulamak için yeniden başlatıldıktan sonra, Yeniden Başlatıldığında Devam Etme (RoR), cihazın Kimlik Bilgileri Şifrelemeli (CE) deposunun kilidini açar.

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

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

Arka plan

Android 7'den başlayarak, Android, cihazdaki uygulamaların CE depolamanın kilidi kullanıcı tarafından açılmadan önce başlatılmasını sağlayan Direct Boot'u destekledi. Doğrudan Önyükleme desteğinin uygulanması, bir önyüklemeden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesi gerekmeden önce Kullanıcılara 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 olanak tanır. Bu özellik, kullanıcıların yeniden başlattıktan sonra yüklü tüm uygulamalarından bildirim almalarını sağlar.

Tehdit modeli

Bir RoR uygulaması, bir cihaz bir saldırganın eline geçtiğinde, cihaz açık olsa, CE depolamanın kilidi açılmış ve cihazın kilidi şu kişi tarafından açılmış olsa bile, saldırganın kullanıcının CE şifreli verilerini kurtarmasının son derece zor olmasını sağlamalıdır: kullanıcı bir OTA güncellemesi aldıktan sonra. Saldırgan yayın kriptografik imzalama anahtarlarına erişim elde etse bile içeriden saldırı direnci etkili olmalıdır.

Özellikle CE depolaması, cihaza fiziksel olarak sahip olan ve şu yeteneklere ve sınırlamalara sahip bir saldırgan tarafından okunmamalıdır :

Yetenekler

  • İsteğe bağlı mesajları imzalamak için herhangi bir satıcının veya şirketin imzalama anahtarını kullanabilir.
  • Cihazın bir OTA güncellemesi almasına neden olabilir.
  • Aşağıdaki Sınırlamalar'da ayrıntıları verilenler 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 bir değişiklik hem en az bir saatlik bir gecikmeyi hem de RAM içeriğini yok eden bir güç çevrimini içerir.)

sınırlamalar

  • Kurcalamaya dayanıklı donanımın (örneğin, 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 bunların girilmesine neden olamaz.

Çözüm

Android 12 RoR güncelleme sistemi, çok gelişmiş 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ış niteliğindedir:

  • Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında (TEE) depolanan anahtarlarla korunur.
  • TEE, yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamayı ( doğrulanmış önyükleme ) geçerse anahtarları serbest bırakır.
  • 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, Android ekosisteminde çalışır.
  • Bir kullanıcının PIN'iyle korunan bir kriptografik anahtar, cihazın kilidini açmak ve CE deposunun şifresini çözmek için kullanılır.
    • Bir gecede yeniden başlatma planlandığında, Android kullanıcıdan PIN'ini girmesini ister, ardından sentetik bir parola (SP) hesaplar.
    • Daha sonra SP'yi iki kez şifreler: bir kez RAM'de saklanan bir K_s anahtarıyla ve tekrar TEE'de saklanan bir K_k anahtarıyla.
    • Çift şifreli SP diskte depolanır ve SP RAM'den silinir. Her iki anahtar da yeni oluşturulur ve yalnızca bir kez yeniden başlatma için kullanılır.
  • Yeniden başlatma zamanı geldiğinde Android, K_s sunucuya emanet eder. K_k makbuz, diskte depolanmadan önce şifrelenir.
  • Yeniden başlatmanın ardından Android, makbuzun şifresini çözmek için K_k kullanır ve ardından K_s almak için sunucuya gönderir.
    • K_k ve K_s diskte saklanan SP'nin şifresini çözmek için kullanılır.
    • Android, CE deposunun 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ı

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.

PIN'i etkinleştirilmiş bir SIM kartın, hücresel bağlantıyı geri yüklemek için katılımsız bir yeniden başlatmanın ardından (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) kesintisiz bir PIN kodu doğrulamasından (SIM-PIN tekrarı) geçmesi gerekir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Kaydedilen 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 birlikte saklanır. SIM'in PIN'i etkinleştirilmişse, RoR sunucusuyla etkileşim, OTA güncellemesi için bir WiFi bağlantısı ve yeniden başlattıktan sonra temel işlevsellik (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR gerektirir .

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ılmayan bir yeniden başlatma gerçekleşti.

Kaydedilen SIM PIN'i, RoR tarafından başlatılan yeniden başlatmanın ardından yalnızca bir kez ve yalnızca çok kısa bir süre için (20 saniye) kullanılabilir – eğer SIM kartın ayrıntıları eşleşirse. Saklanan 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, OTA güncellemelerini gönderdiklerinde iş ortaklarına daha hafif bir yük sağlar. Belirlenen uyku saatleri gibi uygun cihaz kapalı kalma süreleri sırasında gerekli güncellemeler yapılabilir.

Bu tür zaman dilimlerinde OTA güncellemelerinin kullanıcıları kesintiye uğratmamasını sağlamak için ışık emisyonlarını azaltmak amacıyla karanlık modu kullanın. Bunu yapmak için, cihazın önyükleyicisinin Reason unattended dizesini aramasını sağlayın. unattended true ise, cihazı karanlık moda geçirin. Ses ve ışık emisyonlarını azaltmanın her 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üşterili akışta, aşağıda gösterilen isPreparedForUnattendedUpdate yeni bir çağrı var:

@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 istemcisi, Android 12'de yeniden başlatma 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 sistem API'si, mevcut REBOOT Manifest izniyle korunmaktadır.

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

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 itibariyle, RoR HAL uygulamaları iki kategoriye ayrılıyor:

  1. SoC donanımı, yeniden başlatmalar boyunca RAM kalıcılığını destekliyorsa, OEM'ler AOSP'deki ( Varsayılan RAM Emanet ) varsayılan uygulamayı kullanabilir.
  2. Aygıt donanımı veya SoC, güvenli bir donanım bölgesini (kendi RAM'i ve ROM'u olan 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 boyunca devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, yerleşim bölgesi yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanan bir zamanlayıcının süresini doldurabilmelidir.
    • Emanet edilen bir anahtarın, çevrimdışı saldırılarla kurtarılamayacak şekilde yerleşim RAM/ROM'unda 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 boyunca RAM kalıcılığını desteklediğinden emin olmalıdır. Bazı SoC'ler yeniden başlatma sırasında RAM içeriklerini sürdüremezler, bu nedenle OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Aşağıdaki bölümde bunun için kanonik referans.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulaması, RoR'u uygulamak için gerekli yöntemleri çağırmak üzere Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olmalıdır. Bu önkoşul yerine getirildiğinde, güncelleme akışı şu adımları takip eder:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. OTA istemci uygulaması RecoverySystem#prepareForUnattendedUpdate çağırır ve bu, kullanıcının bir sonraki kilit açma işlemi sırasında kilit ekranında PIN'inin, düzeninin veya şifresinin sorulmasını tetikler.
  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ı, hemen yeniden başlatmayı tetikleyen RecoverySystem#rebootAndApply öğesini çağırır.

Bu akışın sonunda, cihaz yeniden başlatılır ve RoR mekanizması kimlik bilgisi şifreli (CE) depolamanın kilidini açar. Uygulamalar için bu, normal bir kullanıcı kilidi açma işlemi olarak görünür, dolayısıyla 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 destekliyor olarak işaretlenen bir ürün, RebootEscrow HAL uygulamasını ve özellik işaretleyici XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatmayı kullanan cihazlarda iyi çalışır (yeniden başlatma sırasında DRAM'in gücü açık kaldığında).

Emanet özellik 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ırmalısınız. Güvenlik özelliklerinin devam etmesini sağlamak için bu baytları asla geçici olmayan depolamaya yazmayın.

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

Linux çekirdeğinin aygıt ağacında, bir pmem bölgesi için bellek ayırmalısınız. Aşağıdaki örnek, 0x50000000 rezerve edildiğini gösterir:

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

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

Blok dizininde /dev/block/pmem0 ( pmem1 veya pmem2 gibi) gibi bir ada sahip yeni bir aygıtınız 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, aşağıdaki yeni girişlerin vendor/<oem>/<product>/device.mk 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ı

Bu yeni girişleri cihazın file_contexts dosyasına 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
,

Android 11'de OTA güncellemeleri, RecoverySystem sınıf yöntemleriyle birleştirilmiş A/B güncellemesi veya sanal A/B güncelleme mekanizmaları kullanılarak uygulanabilir. Bir cihaz, bir OTA güncellemesini uygulamak için yeniden başlatıldıktan sonra, Yeniden Başlatıldığında Devam Etme (RoR), cihazın Kimlik Bilgileri Şifrelemeli (CE) deposunun kilidini açar.

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

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

Arka plan

Android 7'den başlayarak, Android, cihazdaki uygulamaların CE depolamanın kilidi kullanıcı tarafından açılmadan önce başlatılmasını sağlayan Direct Boot'u destekledi. Doğrudan Önyükleme desteğinin uygulanması, bir önyüklemeden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesi gerekmeden önce Kullanıcılara 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 olanak tanır. Bu özellik, kullanıcıların yeniden başlattıktan sonra yüklü tüm uygulamalarından bildirim almalarını sağlar.

Tehdit modeli

Bir RoR uygulaması, bir cihaz bir saldırganın eline geçtiğinde, cihaz açık olsa, CE depolamanın kilidi açılmış ve cihazın kilidi şu kişi tarafından açılmış olsa bile, saldırganın kullanıcının CE şifreli verilerini kurtarmasının son derece zor olmasını sağlamalıdır: kullanıcı bir OTA güncellemesi aldıktan sonra. Saldırgan yayın kriptografik imzalama anahtarlarına erişim elde etse bile içeriden saldırı direnci etkili olmalıdır.

Özellikle CE depolaması, cihaza fiziksel olarak sahip olan ve şu yeteneklere ve sınırlamalara sahip bir saldırgan tarafından okunmamalıdır :

Yetenekler

  • İsteğe bağlı mesajları imzalamak için herhangi bir satıcının veya şirketin imzalama anahtarını kullanabilir.
  • Cihazın bir OTA güncellemesi almasına neden olabilir.
  • Aşağıdaki Sınırlamalar'da ayrıntıları verilenler 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 bir değişiklik hem en az bir saatlik bir gecikmeyi hem de RAM içeriğini yok eden bir güç çevrimini içerir.)

sınırlamalar

  • Kurcalamaya dayanıklı donanımın (örneğin, 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 bunların girilmesine neden olamaz.

Çözüm

Android 12 RoR güncelleme sistemi, çok gelişmiş 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ış niteliğindedir:

  • Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında (TEE) depolanan anahtarlarla korunur.
  • TEE, yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamayı ( doğrulanmış önyükleme ) geçerse anahtarları serbest bırakır.
  • 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, Android ekosisteminde çalışır.
  • Bir kullanıcının PIN'iyle korunan bir kriptografik anahtar, cihazın kilidini açmak ve CE deposunun şifresini çözmek için kullanılır.
    • Bir gecede yeniden başlatma planlandığında, Android kullanıcıdan PIN'ini girmesini ister, ardından sentetik bir parola (SP) hesaplar.
    • Daha sonra SP'yi iki kez şifreler: bir kez RAM'de saklanan bir K_s anahtarıyla ve tekrar TEE'de saklanan bir K_k anahtarıyla.
    • Çift şifreli SP diskte depolanır ve SP RAM'den silinir. Her iki anahtar da yeni oluşturulur ve yalnızca bir kez yeniden başlatma için kullanılır.
  • Yeniden başlatma zamanı geldiğinde Android, K_s sunucuya emanet eder. K_k makbuz, diskte depolanmadan önce şifrelenir.
  • Yeniden başlatmanın ardından Android, makbuzun şifresini çözmek için K_k kullanır ve ardından K_s almak için sunucuya gönderir.
    • K_k ve K_s diskte saklanan SP'nin şifresini çözmek için kullanılır.
    • Android, CE deposunun 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ı

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.

PIN'i etkinleştirilmiş bir SIM kartın, hücresel bağlantıyı geri yüklemek için katılımsız bir yeniden başlatmanın ardından (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) kesintisiz bir PIN kodu doğrulamasından (SIM-PIN tekrarı) geçmesi gerekir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Kaydedilen 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 birlikte saklanır. SIM'in PIN'i etkinleştirilmişse, RoR sunucusuyla etkileşim, OTA güncellemesi için bir WiFi bağlantısı ve yeniden başlattıktan sonra temel işlevsellik (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR gerektirir .

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ılmayan bir yeniden başlatma gerçekleşti.

Kaydedilen SIM PIN'i, RoR tarafından başlatılan yeniden başlatmanın ardından yalnızca bir kez ve yalnızca çok kısa bir süre için (20 saniye) kullanılabilir – eğer SIM kartın ayrıntıları eşleşirse. Saklanan 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, OTA güncellemelerini gönderdiklerinde iş ortaklarına daha hafif bir yük sağlar. Belirlenen uyku saatleri gibi uygun cihaz kapalı kalma süreleri sırasında gerekli güncellemeler yapılabilir.

Bu tür zaman dilimlerinde OTA güncellemelerinin kullanıcıları kesintiye uğratmamasını sağlamak için ışık emisyonlarını azaltmak amacıyla karanlık modu kullanın. Bunu yapmak için, cihazın önyükleyicisinin Reason unattended dizesini aramasını sağlayın. unattended true ise, cihazı karanlık moda geçirin. Ses ve ışık emisyonlarını azaltmanın her 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üşterili akışta, aşağıda gösterilen isPreparedForUnattendedUpdate yeni bir çağrı var:

@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 istemcisi, Android 12'de yeniden başlatma 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 sistem API'si, mevcut REBOOT Manifest izniyle korunmaktadır.

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

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 itibariyle, RoR HAL uygulamaları iki kategoriye ayrılıyor:

  1. SoC donanımı, yeniden başlatmalar boyunca RAM kalıcılığını destekliyorsa, OEM'ler AOSP'deki ( Varsayılan RAM Emanet ) varsayılan uygulamayı kullanabilir.
  2. Aygıt donanımı veya SoC, güvenli bir donanım bölgesini (kendi RAM'i ve ROM'u olan 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 boyunca devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, yerleşim bölgesi yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanan bir zamanlayıcının süresini doldurabilmelidir.
    • Emanet edilen bir anahtarın, çevrimdışı saldırılarla kurtarılamayacak şekilde yerleşim RAM/ROM'unda 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 boyunca RAM kalıcılığını desteklediğinden emin olmalıdır. Bazı SoC'ler yeniden başlatma sırasında RAM içeriklerini sürdüremezler, bu nedenle OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Aşağıdaki bölümde bunun için kanonik referans.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulaması, RoR'u uygulamak için gerekli yöntemleri çağırmak üzere Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olmalıdır. Bu önkoşul yerine getirildiğinde, güncelleme akışı şu adımları takip eder:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. OTA istemci uygulaması RecoverySystem#prepareForUnattendedUpdate çağırır ve bu, kullanıcının bir sonraki kilit açma işlemi sırasında kilit ekranında PIN'inin, düzeninin veya şifresinin sorulmasını tetikler.
  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ı, hemen yeniden başlatmayı tetikleyen RecoverySystem#rebootAndApply öğesini çağırır.

Bu akışın sonunda, cihaz yeniden başlatılır ve RoR mekanizması kimlik bilgisi şifreli (CE) depolamanın kilidini açar. Uygulamalar için bu, normal bir kullanıcı kilidi açma işlemi olarak görünür, dolayısıyla 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 destekliyor olarak işaretlenen bir ürün, RebootEscrow HAL uygulamasını ve özellik işaretleyici XML dosyasını içermelidir. Varsayılan uygulama, sıcak yeniden başlatmayı kullanan cihazlarda iyi çalışır (yeniden başlatma sırasında DRAM'in gücü açık kaldığında).

Emanet özellik 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ırmalısınız. Güvenlik özelliklerinin devam etmesini sağlamak için bu baytları asla geçici olmayan depolamaya yazmayın.

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

Linux çekirdeğinin aygıt ağacında, bir pmem bölgesi için bellek ayırmalısınız. Aşağıdaki örnek, 0x50000000 rezerve edildiğini gösterir:

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

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

Blok dizininde /dev/block/pmem0 ( pmem1 veya pmem2 gibi) gibi bir ada sahip yeni bir aygıtınız 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, aşağıdaki yeni girişlerin vendor/<oem>/<product>/device.mk 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ı

Bu yeni girişleri cihazın file_contexts dosyasına 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
,

Android 11'de OTA güncellemeleri, RecoverySystem sınıf yöntemleriyle birleştirilmiş A/B güncellemesi veya sanal A/B güncelleme mekanizmaları kullanılarak uygulanabilir. Bir cihaz, bir OTA güncellemesini uygulamak için yeniden başlatıldıktan sonra, Yeniden Başlatıldığında Devam Etme (RoR), cihazın Kimlik Bilgileri Şifrelemeli (CE) deposunun kilidini açar.

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

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

Arka plan

Android 7'den başlayarak, Android, cihazdaki uygulamaların CE depolamanın kilidi kullanıcı tarafından açılmadan önce başlatılmasını sağlayan Direct Boot'u destekledi. Doğrudan Önyükleme desteğinin uygulanması, bir önyüklemeden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesi gerekmeden önce Kullanıcılara 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 olanak tanır. Bu özellik, kullanıcıların yeniden başlattıktan sonra yüklü tüm uygulamalarından bildirim almalarını sağlar.

Tehdit modeli

Bir RoR uygulaması, bir cihaz bir saldırganın eline geçtiğinde, cihaz açık olsa, CE depolamanın kilidi açılmış ve cihazın kilidi şu kişi tarafından açılmış olsa bile, saldırganın kullanıcının CE şifreli verilerini kurtarmasının son derece zor olmasını sağlamalıdır: kullanıcı bir OTA güncellemesi aldıktan sonra. Saldırgan yayın kriptografik imzalama anahtarlarına erişim elde etse bile içeriden saldırı direnci etkili olmalıdır.

Özellikle CE depolaması, cihaza fiziksel olarak sahip olan ve şu yeteneklere ve sınırlamalara sahip bir saldırgan tarafından okunmamalıdır :

Yetenekler

  • İsteğe bağlı mesajları imzalamak için herhangi bir satıcının veya şirketin imzalama anahtarını kullanabilir.
  • Cihazın bir OTA güncellemesi almasına neden olabilir.
  • Aşağıdaki Sınırlamalar'da ayrıntıları verilenler 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 bir değişiklik hem en az bir saatlik bir gecikmeyi hem de RAM içeriğini yok eden bir güç çevrimini içerir.)

sınırlamalar

  • Kurcalamaya dayanıklı donanımın (örneğin, 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 bunların girilmesine neden olamaz.

Çözüm

Android 12 RoR güncelleme sistemi, çok gelişmiş 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ış niteliğindedir:

  • Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
  • Tüm veriler, güvenilir yürütme ortamında (TEE) depolanan anahtarlarla korunur.
  • TEE, yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamayı ( doğrulanmış önyükleme ) geçerse anahtarları serbest bırakır.
  • 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, Android ekosisteminde çalışır.
  • Bir kullanıcının PIN'iyle korunan bir kriptografik anahtar, cihazın kilidini açmak ve CE deposunun şifresini çözmek için kullanılır.
    • Bir gecede yeniden başlatma planlandığında, Android kullanıcıdan PIN'ini girmesini ister, ardından sentetik bir parola (SP) hesaplar.
    • Daha sonra SP'yi iki kez şifreler: bir kez RAM'de saklanan bir K_s anahtarıyla ve tekrar TEE'de saklanan bir K_k anahtarıyla.
    • Çift şifreli SP diskte depolanır ve SP RAM'den silinir. Her iki anahtar da yeni oluşturulur ve yalnızca bir kez yeniden başlatma için kullanılır.
  • Yeniden başlatma zamanı geldiğinde Android, K_s sunucuya emanet eder. K_k makbuz, diskte depolanmadan önce şifrelenir.
  • Yeniden başlatmanın ardından Android, makbuzun şifresini çözmek için K_k kullanır ve ardından K_s almak için sunucuya gönderir.
    • K_k ve K_s diskte saklanan SP'nin şifresini çözmek için kullanılır.
    • Android, CE deposunun 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ı

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.

PIN'i etkinleştirilmiş bir SIM kartın, hücresel bağlantıyı geri yüklemek için katılımsız bir yeniden başlatmanın ardından (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) kesintisiz bir PIN kodu doğrulamasından (SIM-PIN tekrarı) geçmesi gerekir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Kaydedilen 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 birlikte saklanır. SIM'in PIN'i etkinleştirilmişse, RoR sunucusuyla etkileşim, OTA güncellemesi için bir WiFi bağlantısı ve yeniden başlattıktan sonra temel işlevsellik (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR gerektirir .

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ılmayan bir yeniden başlatma gerçekleşti.

Kaydedilen SIM PIN'i, RoR tarafından başlatılan yeniden başlatmanın ardından yalnızca bir kez ve yalnızca çok kısa bir süre için (20 saniye) kullanılabilir – eğer SIM kartın ayrıntıları eşleşirse. Saklanan 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, OTA güncellemelerini gönderdiklerinde iş ortaklarına daha hafif bir yük sağlar. Belirlenen uyku saatleri gibi uygun cihaz kapalı kalma süreleri sırasında gerekli güncellemeler yapılabilir.

Bu tür zaman dilimlerinde OTA güncellemelerinin kullanıcıları kesintiye uğratmamasını sağlamak için ışık emisyonlarını azaltmak amacıyla karanlık modu kullanın. Bunu yapmak için, cihazın önyükleyicisinin Reason unattended dizesini aramasını sağlayın. unattended true ise, cihazı karanlık moda geçirin. Ses ve ışık emisyonlarını azaltmanın her 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üşterili akışta, aşağıda gösterilen isPreparedForUnattendedUpdate yeni bir çağrı var:

@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 istemcisi, Android 12'de yeniden başlatma 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 sistem API'si, mevcut REBOOT Manifest izniyle korunmaktadır.

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

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 itibariyle, RoR HAL uygulamaları iki kategoriye ayrılıyor:

  1. SoC donanımı, yeniden başlatmalar boyunca RAM kalıcılığını destekliyorsa, OEM'ler AOSP'deki ( Varsayılan RAM Emanet ) varsayılan uygulamayı kullanabilir.
  2. Aygıt donanımı veya SoC, güvenli bir donanım bölgesini (kendi RAM'i ve ROM'u olan 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 boyunca devam eden bir donanım zamanlayıcı kaynağına sahip olun. Yani, yerleşim bölgesi yeniden başlatmayı algılayabilmeli ve yeniden başlatmadan önce ayarlanan bir zamanlayıcının süresini doldurabilmelidir.
    • Emanet edilen bir anahtarın, çevrimdışı saldırılarla kurtarılamayacak şekilde yerleşim RAM/ROM'unda 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 boyunca RAM kalıcılığını desteklediğinden emin olmalıdır. Bazı SoC'ler yeniden başlatma sırasında RAM içeriklerini sürdüremezler, bu nedenle OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce SoC ortaklarına danışmaları önerilir. Aşağıdaki bölümde bunun için kanonik referans.

RoR kullanarak OTA güncelleme akışı

Telefondaki OTA istemci uygulaması, RoR'u uygulamak için gerekli yöntemleri çağırmak üzere Manifest.permission.REBOOT ve Manifest.permission.RECOVERY izinlerine sahip olmalıdır. Bu önkoşul yerine getirildiğinde, güncelleme akışı şu adımları takip eder:

  1. OTA istemci uygulaması güncellemeyi indirir.
  2. OTA client app calls to RecoverySystem#prepareForUnattendedUpdate which triggers the user to be prompted for their PIN, pattern, or password on the lock screen during the next unlock.
  3. The user unlocks the device at the lockscreen, and the device is ready to have the update applied.
  4. OTA client app calls to RecoverySystem#rebootAndApply , which immediately triggers a reboot.

At the end of this flow, the device reboots and the RoR mechanism unlocks the credential encrypted (CE) storage. To apps, this appears as a normal user unlock, so they receive all the signals, such as ACTION_LOCKED_BOOT_COMPLETED and ACTION_BOOT_COMPLETED that they normally do.

Modifying product configurations

A product marked as supporting the RoR feature in Android 11 must include an implementation of the RebootEscrow HAL and include the feature marker XML file. The default implementation works well on devices that use warm reboot (when the power to DRAM remains on during reboot).

Reboot escrow feature marker

The feature marker must also be present:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Default reboot escrow HAL implementation

To use the default implementation, you must reserve 65536 (0x10000) bytes. Never write these bytes to non-volatile storage to ensure that the security properties persist.

Linux kernel device tree changes

In the Linux kernel's device tree, you must reserve memory for a pmem region. The following example shows 0x50000000 being reserved:

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

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

Verify that you have a new device in the block directory with a name like /dev/block/pmem0 (such as pmem1 or pmem2 ).

Device.mk changes

Assuming that your new device from the previous step is named pmem0 , you must ensure the following new entries get added to 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 rules

Add these new entries to the device's 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