Android 11'de OTA güncellemeleri A/B güncellemesi kullanılarak uygulanabilir veya sanal A/B güncelleme mekanizmaları, Kurtarma Sistemi sınıf yöntemleri. 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ı, bu işlemi geçerli bir OTA sistemi özelliğiyle eşleştirebilir. Android 11'de cihazın boşta kalması beklendiğinde Android 12 iş ortaklarının ek bir OTA sistemine ihtiyacı yoktur özelliğini kullanabilirsiniz. RoR işlemi, 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'in desteklediği Doğrudan Başlatma, Böylece, CE depolama alanı kilidi açılmadan önce cihazdaki uygulamalar başlatılır. gösterir. Doğrudan Başlatma desteğinin uygulanması, kullanıcılara daha iyi deneyimi yerine getirilmesi için kullanılan Kilit Ekranı Bilgi Faktörü'nden (LSKF) sonra kaybolabilir.
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, cihaz açık olsa, CE depolama alanının kilidi açık olsa ve OTA güncellemesi aldıktan sonra kullanıcı tarafından cihazın kilidi açılsa bile saldırganın 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ç etkin olmalıdır.
Özellikle, CE depolama alanı, fiziksel olarak sahip olan bir saldırgan tarafından okunmamalıdır. sahip olduğu özellikleri içerir ve aşağıdaki işlevlere ve sınırlamalara sahiptir:
Ö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 belirtilenler hariç olmak üzere herhangi bir donanımın (ör. uygulama işlemcisi veya flash bellek) çalışmasını değiştirebilir. (Bununla birlikte, bu tür değişiklik hem en az bir saatlik gecikmeyi hem de devre dışı bırakmanızı sağlar.)
Sınırlamalar
- Üzerinde oynanmaya karşı korumalı donanımın (örneğin, Titan M) tıklayın.
- 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. Bu sağlanan güvenlik düzeylerinin test ve kontrol edilmesini sağlayan donanım tabanlı, cihaz düzeyindeki bir RoR sistemine benzer:
- 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ğrulamasını (doğrulanmış başlatma) geçerse anahtarları serbest bırakır.
- Google sunucularında çalışan RoR hizmeti, bir gizli anahtar depolayarak CE verilerinin güvenliğini sağlar yalnızca sınırlı bir süre için alınabilir. 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_sanahtarıyla, bir kez de TEE'de depolananK_kanahtarıyla. - Çift şifrelenmiş SP diskte depolanır ve servis sağlayıcı da 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_ssağlayıcısını sunucuya güvenir.K_kiçeren makbuz, diske kaydedilmeden önce şifrelenir. - Android, yeniden başlatıldıktan sonra makbuzun şifresini çözmek için
K_k'ü kullanır ve ardındanK_s'ü almak için makbuzu sunucuya gönderir.K_kveK_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_kveK_satı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.
PIN'i etkinleştirilmiş bir SIM kart da sorunsuz bir PIN kodundan geçmelidir Hücresel verileri geri yüklemek için gözetimsiz bir yeniden başlatma sonrasında doğrulama (SIM-PIN tekrarı) bağlantısı (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası) sayısı) birlikte güvenli bir şekilde saklanır. Saklanan PIN alınabilir ve kullanılabilir yalnızca başarılı bir katılımsız yeniden başlatma sonrasında doğrulama için yeniden başlatılmalıdır. Cihaz güvendeyse SIM PIN'i, LSKF tarafından korunan anahtarlarla birlikte depolanır. SIM kartta PIN etkin, RoR sunucusuyla etkileşim için kablosuz bağlantı gerekir OTA güncellemesi ve sunucu tabanlı RoR için temel işlevsellik ( hücresel bağlantı) kullandığınızdan emin olun.
SIM PIN'i yeniden şifrelenir ve kullanıcı başarılı bir şekilde her etkinleştirdiğinde saklanır. doğrulama ya da değiştirme. Aşağıdakilerden herhangi biri SIM PIN'i silinir gerçekleşir:
- 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 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ı kalma zamanlarında (ör. uyku saatleri olarak tanımlayabilirsiniz.
Bu zaman aralıklarındaki OTA güncellemelerinin kullanıcıları rahatsız etmediğinden emin olmak için
ışık emisyonlarını azaltmak için koyu mod kullanma. Bunun için cihazın önyükleyicisinin unattended dize nedenini aramasını sağlayın. unattended true ise cihazı koyu moda alın. 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 için herhangi bir işlem yapmanıza gerek yoktur. yeni RoR işlevini uygulayabilir.
Çok müşterili akışta yeni bir arama var: 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 desteği sonlandırıldığı için bunu uygulamanız gerekmez Android 12.
TelephonyManager
OTA istemcisi, yeniden başlatma işlemi yaklaştığında TelephonyManager sistem API'sini çağırır
kullanıma sunduk. Bu API, önbelleğe alınan tüm PIN kodlarını şuradan taşır:
AVAILABLE durumunu REBOOT_READY durumuna getirir. TelephonyManager sistemi
API, mevcut REBOOT ile korunuyor
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
Yeni API'yi test etmek için şu komutu yürütün:
adb shell cmd phone unattended-rebootBu komut yalnızca kabuk root (adb root) olarak çalışırken çalışır.
Yalnızca Android 11
Bu sayfanın kalan kısmı Android 11 için geçerlidir.
Temmuz 2020 itibarıyla RoR HAL'ın uygulamaları iki kategoriye ayrılır:
- 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.
- 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 sırasında devam eden bir donanım zamanlayıcı kaynağına sahip olmalıdır. 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ı Bu nedenle, kuruluş içinden kişilerin veya saldırganların verileri kurtarmasını imkansız hale getirir.
Varsayılan RAM emanet
AOSP, RAM'de kalıcı olan RoR HAL'i uygular. Bunun işe yaraması için OEM'lerin, SoC'lerinin RAM kalıcılığını desteklediğinden emin olması gerekir. çok daha iyi performans gösterir. 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. Bu konuda standart referans, aşağıdaki bölümde yer almaktadır.
RoR'yi 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:
- OTA istemci uygulaması güncellemeyi indirir.
- OTA istemci uygulaması
RecoverySystem#prepareForUnattendedUpdateçağrısı yapar. Bu çağrı, bir sonraki kilit açma işlemi sırasında kullanıcıdan kilit ekranında PIN, desen veya şifresi istenmesini tetikler. - Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz hazır olur seçeneğine dokunun.
- OTA istemci uygulaması
RecoverySystem#rebootAndApply'e çağrı gönderir ve bu da hemen yeniden başlatmayı 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, normal bir kilit açma şekli olarak görünür. Böylece, İŞLEM_KİLİTLİ_BOOT_TAMAMLANDI ve İŞLEM_BOOT_TAMAMLANDI yapabilirler.
Ürün yapılandırmalarını değiştirme
Android 11'de RoR özelliğini destekliyor olarak işaretlenen bir üründe, ve özellik işaretçisi XML dosyasını içermesi gerekir. Varsayılan uygulama, hazır durumda yeniden başlatma kullanan cihazlarda ( yeniden başlatma sırasında DRAM'nin gücü açık kalır).
Teminat özelliği işaretçisini yeniden başlat
Ö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 korunması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, 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 şuna sahip yeni bir cihazınız olduğunu doğrulayın:
/dev/block/pmem0 (pmem1 veya pmem2 gibi).
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ı
Ş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