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 üzere yeniden başlatıldıktan sonra, Yeniden Başlatmada Devam Ettirme (RoR), cihazın Şifrelenmiş Kimlik Bilgisi (CE) depolama alanının kilidini açar.
İş ortakları, bu işlemi, cihazın Android 11'de boşta kalması beklendiğinde güncellemeleri uygulayan bir OTA sistem özelliğiyle eşleyebilir. Ancak Android 12'deki iş ortaklarının ek bir OTA sistem özelliğine ihtiyacı yoktur. Güncellemeler cihazın boşta olduğu zamanlarda yapılabildiği için RoR işlemi kullanıcılara ek güvenlik ve kolaylık sunarken Android 12'nin çok istemcili ve sunucu tabanlı güncelleme işlevleri bir arada 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 gerekir. Ancak HAL kullanmadığı için Android 12 ve sonraki sürümlerde sunucu tabanlı RoR'yi etkinleştirmek için bunu yapmanız gerekmez.
Arka plan
Android 7'den başlayarak Android, kullanıcı CE depolama alanının kilidini açmadan önce cihazdaki uygulamaların başlatılmasını sağlayan Doğrudan Başlatma özelliğini destekliyor. Doğrudan Başlatma desteğinin uygulanması, kullanıcıların başlatma işleminden sonra Kilit Ekranı Bilgi Faktörü'nün (LSKF) girilmesinden önce daha iyi bir deneyim yaşamasını sağladı.
RoR, bir OA güncellemesinden sonra yeniden başlatma başlatıldığında Doğrudan Başlatma'yı desteklemeyenler de dahil olmak üzere bir cihazdaki tüm uygulamaların CE depolama kilidinin açılmasına olanak tanır. Bu özellik, kullanıcıların yeniden başlatma sonrasında yüklü tüm uygulamalardan bildirim almalarını sağlar.
Tehdit modeli
RoR uygulaması, bir cihaz saldırganın eline düştüğünde, cihaz açık, CE depolama alanının ve bir OTA güncellemesi aldıktan sonra kullanıcı tarafından cihazın kilidinin açılsa 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 imzalama anahtarlarına erişim sağlasa bile çalışanların saldırılarına karşı direnç etkili olmalıdır.
Özellikle, CE depolama alanı fiziksel olarak cihaza sahip olan, aşağıdaki özelliklere ve sınırlamalara sahip olan bir saldırgan tarafından okumamalıdır:
Özellikler
- Rastgele mesajları imzalamak için herhangi bir tedarikçi firmanı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 ayrıntılı olarak açıklanan durumlar 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 değiştirme işlemi hem en az bir saatlik gecikmeyi hem de RAM içeriklerini yok eden bir açma döngüsünü içerir.)
Sınırlamalar
- Değişikliğe karşı korumalı donanımın (ör. Titan M) çalışma şekli değiştirilemez.
- Canlı cihazın RAM'i okunamıyor.
- Kullanıcının kimlik bilgilerini (PIN, desen, şifre) tahmin edemez veya bu bilgilerin girilmesine neden olamaz.
Çözüm
Android 12 RoR güncelleme sistemi çok ileri düzey saldırganlara karşı güvenlik sağlar. Cihaz üzerindeki şifreler ve PIN'ler cihazda kalırken bunlar hiçbir zaman Google sunucularına gönderilmez veya saklanmaz. Burada, sağlanan güvenlik düzeylerinin donanım tabanlı, cihaz düzeyindeki bir RoR sistemine benzer olmasını sağlayan sürece genel bir bakış sunulmaktadır:
- Android, bir cihazda depolanan verilere kriptografik korumalar uygular.
- Tüm veriler, güvenilir yürütme ortamında (TEE) depolanan anahtarlarla korunur.
- TEE, anahtarları yalnızca çalışan işletim sistemi kriptografik kimlik doğrulamayı geçerse (doğrulanmış başlatma) serbest bırakır.
- Google sunucularında çalışan RoR hizmeti, yalnızca sınırlı bir süre için alınabilen bir gizli anahtarı depolayarak CE verilerinin güvenliğini sağlar. Bu tüm Android ekosisteminde işe yarar.
- Cihazın kilidini açmak ve CE depolama alanının şifresini çözmek için kullanıcının PIN'i ile korunan bir şifreleme 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.
- Daha sonra, SP'yi iki kez şifreler: bir kez RAM'de depolanan bir
K_s
anahtarı ve ikincisi de TEE'de depolanan birK_k
anahtarı ile. - Çift şifrelenmiş SP diskte depolanır ve servis sağlayıcı da RAM'den silinir. Her iki anahtar da yeni oluşturulmuştur ve yalnızca bir yeniden başlatma için kullanılır.
- Yeniden başlatma zamanı geldiğinde Android,
K_s
sağlayıcısını sunucuya güvenir.K_k
ile gönderilen makbuz, diskte depolanmadan önce şifrelenir. - Yeniden başlatmadan sonra Android, makbuzun şifresini çözmek için
K_k
kullanır, ardındanK_s
kodunu almak için sunucuya gönderir.K_k
veK_s
, diskte depolanan SP'nin şifresini çözmek için kullanılır.- Android, CE depolama alanının kilidini açmak ve normal uygulamanın başlatılmasına izin vermek için SP'yi kullanır.
K_k
veK_s
silindi.
Telefonunuzu güvende tutan güncellemeler, sizin için uygun bir zamanda, yani uyurken gerçekleştirilebilir.
SIM-PIN'i tekrar oynatma
Belirli koşullar altında SIM kartın PIN kodu bir önbellekten doğrulanır. Bu işlem, SIM PIN'ini tekrar oynatma olarak adlandırılır.
PIN etkinleştirilmiş bir SIM kart da, hücresel bağlantının yeniden başlatılması için (telefon aramaları, SMS mesajları ve veri hizmetleri için gereklidir) gözetimsiz yeniden başlatma sonrasında sorunsuz bir PIN kodu doğrulamasından (SIM PIN tekrarı) geçmelidir. SIM PIN'i ve eşleşen SIM kart bilgileri (ICCID ve SIM yuvası numarası) birlikte güvenli bir şekilde saklanır. Saklanan PIN yalnızca başarılı bir müdahalesiz yeniden başlatma sonrasında alınabilir ve doğrulama için kullanılabilir. Cihazın güvenliği sağlandığında SIM PIN'i, LSKF tarafından korunan anahtarlarla birlikte saklanır. SIM'in PIN'i etkinleştirilmişse RoR sunucusuyla etkileşim, OTA güncellemesi için kablosuz bağlantı ve yeniden başlatma sonrasında temel işlevselliği (hücresel bağlantı ile) sağlayan sunucu tabanlı RoR'yi gerektirir.
SIM PIN, kullanıcı tarafından başarıyla her etkinleştirildiğinde, doğrulandığında veya değiştirdiğinde yeniden şifrelenir ve saklanır. SIM PIN'i, aşağıdakilerden herhangi biri gerçekleşirse silinir:
- SIM çıkarılmış 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.
Saklanan SIM PIN'i yalnızca RoR tarafından başlatılan yeniden başlatma işleminden bir kez sonra ve yalnızca çok kısa bir süre (20 saniye) boyunca (SIM kart eşleşmesi ayrıntıları geçerliyse kullanılabilir) kullanılabilir. Saklanan SIM PIN'i, TelephonyManager uygulamasından hiçbir zaman dışarı çı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ı olduğu zamanlarda (ör. belirlenen uyku saatleri sırasında) yapılabilir.
Bu sürelerde OTA güncellemelerinin kullanıcıları rahatsız etmemesi için koyu mod kullanarak ışık emisyonlarını azaltın. Bunu yapmak için cihaz bootloader'ının unattended
dize nedenini aramasını sağlayın. unattended
değeri true
ise
cihazı koyu moda getirin. Ses ve ışık emisyonlarını azaltmanın
OEM'ler kendi sorumluluğunda 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 yeni bir çağrı (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, Android 12 ile birlikte kullanımdan kaldırılacağı için bu yöntemi uygulamanız gerekmez.
Telefon Yöneticisi
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 etme
Yeni API'yi test etmek için şu komutu yürütün:
adb shell cmd phone unattended-reboot
Bu komut yalnızca kabuk, kök (adb root
) olarak çalıştığında çalışır.
Yalnızca Android 11
Bu sayfanın kalan kısmı Android 11 için geçerlidir.
Temmuz 2020 itibarıyla RoR HAL uygulamaları iki kategoriye ayrılır:
- SoC donanımı, yeniden başlatmalar arasında RAM kalıcılığını destekliyorsa OEM'ler AOSP'deki varsayılan uygulamayı (Varsayılan RAM Escrow) kullanabilir.
- Cihaz donanımı veya Çip üzerinde sistem (SoC) güvenli bir donanım enclave'yi (kendi RAM'ine ve ROM'una sahip ayrı bir güvenlik yardımcı işlemcisini) destekliyorsa ayrıca şunları da yapmalıdır:
- Ana CPU yeniden başlatmasını algılayabilme.
- Yeniden başlatma sırasında devam eden bir donanım zamanlayıcı kaynağına sahip olmalıdır. Diğer bir deyişle, enclave yeniden başlatmayı algılayabilmeli ve yeniden başlatma işleminden önce ayarlanan bir zamanlayıcıyı sürebilmelidir.
- Çevrimdışı saldırılarla kurtarılamayacak şekilde enclave RAM/ROM'da depolanması desteği. RoR anahtarını, kuruluş içinden kişilerin veya saldırganların kurtarmasını imkansız hale getirecek şekilde depolamalıdır.
Varsayılan RAM emaneti
AOSP'de, RAM kalıcılığı kullanan bir RoR HAL uygulaması vardır. Bunun işe yaraması için OEM'lerin, SoC'lerinin yeniden başlatmalarda RAM kalıcılığını desteklediğinden emin olması gerekir. Bazı SoC'ler, yeniden başlatma sırasında RAM içeriğini sürdüremez. Bu nedenle, OEM'lerin bu varsayılan HAL'yi etkinleştirmeden önce SoC iş ortaklarına danışması önerilir. Bu konuda standart referans, aşağıdaki bölümde yer almaktadır.
RoR kullanarak OTA güncelleme akışı
Telefondaki OTA istemci uygulamasının, RoR'yi uygulamak için gerekli yöntemlerin çağırılması amacıyla Manifest.permission.REBOOT ve Manifest.permission.RECOVERY
izinlerine sahip olması gerekir. Bu ön koşul yerine getirildiğinde güncelleme akışı şu adımları izler:
- OTA istemci uygulaması güncellemeyi indirir.
- OTA istemci uygulaması
RecoverySystem#prepareForUnattendedUpdate
numarasını çağırır. Bu çağrı, bir sonraki kilit açma işleminde kullanıcıdan kilit ekranında PIN, desen veya şifresinin istenmesini tetikler. - Kullanıcı, kilit ekranında cihazın kilidini açar ve cihaz güncelleme uygulanmaya hazırdır.
RecoverySystem#rebootAndApply
işlemine çağrı yapan OTA istemci uygulaması, hemen yeniden başlatma işlemini 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 bu işlem normal bir kullanıcı kilidi olarak görünür. Böylece kullanıcılar, normalde yaptıkları ACTION_LOCKED_BOOT_COMPLETED ve ACTION_BOOT_COMPLETED gibi tüm sinyalleri alır.
Ürün yapılandırmalarını değiştirme
Android 11'de RoR özelliğini desteklediğini belirten bir ürün, RebootEscrow HAL uygulamasını ve özellik işaretçisi XML dosyasını içermelidir. Varsayılan uygulama, hazır durumda yeniden başlatma kullanan cihazlarda (yeniden başlatma sırasında DRAM'nin gücü açık kaldığında) iyi sonuç verir.
Yeniden başlatma emaneti özellik 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 65.536 (0x10.000) bayt ayırmalısınız. Güvenlik özelliklerinin kalıcı olması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, bir pmem
bölgesi için bellek ayırmanız gerekir.
Aşağıdaki örnekte 0x50000000
rezervasyonu 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 (pmem1
veya pmem2
) 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 aşağıdaki yeni girişlerin vendor/<oem>/<product>/device.mk
ürününe 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ı
Ş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