Keymaster 1'de tüm anahtar denetleyicisi anahtarları kriptografik olarak cihaza bağlıydı Güven Kökü veya Doğrulanmış Başlatma anahtarı. Keymaster 2 ve 3'te tümü anahtarları, aynı zamanda sistem görüntüsünün işletim sistemine ve yama düzeyine de bağlıdır. Bu, eski güvenlik açığını tespit eden bir saldırganın sistemin veya TEE yazılımının sürümü, bir cihazı güvenlik açığına geri döndüremez yeni sürümle oluşturulan anahtarları kullanın. Ayrıca anahtar yükseltilmiş bir cihazda kullanılıyorsa yeni bir sürüme veya yama düzeyine yükseltmeniz durumunda, anahtar, ve anahtarın önceki sürümü geçersiz kılındı. Bu şekilde, cihaz yükseltildiğinde, tuşlar "çırpma" yönlendirme yapar, ancak herhangi bir cihazın önceki bir sürüme geri alınması, tuşların bir şablon görevi görür.
Treble'ın modüler yapısını desteklemek ve system.img'in boot.img, Keymaster 4 anahtar sürümü bağlama modelini ayrı yama düzeylerini belirleyebilirsiniz. Bu, her bölümün güncellenmesine olanak tanır ve geri alma koruması sağlar.
Android 9'da boot
, system
ve vendor
her bölümün kendi yama düzeyi vardır.
- Android Doğrulanmış Başlatma (AVB) yüklü cihazlar tüm yama düzeylerini uygulayabilir
ve sistem sürümünü içerir. Böylece bootloader bunları
Keymaster. Zincirli bölümler için bölümün sürüm bilgisi
zincirleme vbmeta içinde olma. Genel olarak, sürüm bilgileri
Doğrulama verilerini içeren
vbmeta struct
(karma veya hashtree) kaldırın. - AVB'si olmayan cihazlarda:
- Doğrulanmış Başlatma uygulamalarının, sürümün bir karmasını sağlaması gerekir meta verileri bootloader'a ekleyin. Böylece bootloader, karmayı Keymaster'a sağlayabilir.
boot.img
, başlıkta yama düzeyini depolamaya devam edebilirsystem.img
, yama düzeyini ve işletim sistemi sürümünü salt okunur olarak depolamaya devam edebilir mülklervendor.img
, yama düzeyini salt okunur mülkte depolarro.vendor.build.version.security_patch
.- Bootloader, doğrulanmış başlatma tarafından doğrulanan tüm verilerin bir karmasını sağlayabilir anahtar ana makinesine.
- Android 9'da, Android 9'da sürüm bilgilerini sağlamak için
şu bölümler:
VENDOR_PATCH_LEVEL
:vendor
bölümBOOT_PATCH_LEVEL
:boot
bölümOS_PATCH_LEVEL
veOS_VERSION
:system
bölümü. (OS_VERSION
, şuradan kaldırıldı:boot.img
üstbilgisi.
-
Keymaster uygulamaları, tüm yama düzeylerini bağımsız olarak işlemelidir. Anahtarlar:
Tüm sürüm bilgileri bir anahtarla ilişkilendirilen değerlerle eşleşirse kullanılabilir ve
IKeymaster::upgradeDevice()
, şu durumlarda daha yüksek bir yama seviyesine geçer: gerekir.
HAL Değişiklikleri
Sürüm bağlama ve sürüm onayını desteklemek için Android 7.1,
Tag::OS_VERSION
ve Tag::OS_PATCHLEVEL
etiketlerinin yanı sıra
configure
ve upgradeKey
yöntemleri. Sürüm etiketleri
Keymaster 2+ uygulamaları tarafından yeni oluşturulan tüm anahtar kelimelere otomatik olarak eklenir
(veya güncellenmiş) anahtar sayısı. Ayrıca, işletim sistemi olmayan bir anahtar kullanma girişimleri
mevcut sistem işletim sistemi sürümü veya yama düzeyiyle eşleşen sürüm ya da yama düzeyi
sırasıyla ErrorCode::KEY_REQUIRES_UPGRADE
ile reddedilir.
Tag::OS_VERSION
, terimi temsil eden UINT
MMmms'ler olarak bir Android sistem sürümünün büyük, küçük ve alt küçük bölümleri
Burada AA ana sürüm, mm alt sürüm, ss alt sürümdür
sürümünü değil. Örneğin 6.1.2, 060102 olarak temsil edilir.
Tag::OS_PATCHLEVEL
, terimi temsil eden UINT
YYYYAA olarak sisteme yapılan son güncellemenin yılı ve ayı; burada YYYY değeri
yıl, dört basamaklı, AA ise iki basamaklı aydır. Örneğin, Mart 2016
201603 olarak temsil edilir.
Yükseltme Anahtarı
Anahtarların, sistemin yeni işletim sistemi sürümüne ve yama düzeyine yükseltilmesine izin vermek için
resmi, Android 7.1 sürümünde HAL'ye upgradeKey
yöntemi eklenmiştir:
Anahtar Yöneticisi 3
upgradeKey(vec keyBlobToUpgrade, vec upgradeParams) generates(ErrorCode error, vec upgradedKeyBlob);
Anahtar Yöneticisi 2
keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev, const keymaster_key_blob_t* key_to_upgrade, const keymaster_key_param_set_t* upgrade_params, keymaster_key_blob_t* upgraded_key);
dev
, cihaz yapısıdırkeyBlobToUpgrade
, yeni sürüme geçirilmesi gereken anahtardırupgradeParams
, anahtarı yeni sürüme geçirmek için gereken parametrelerdir. BuTag::APPLICATION_ID
veTag::APPLICATION_DATA
: anahtarın şifresini çözmek için gerekli blob olarak da gösterilir.upgradedKeyBlob
, anahtar blob'u ekleyin.
upgradeKey
, ayrıştırılamayan bir anahtar blob'uyla çağrılırsa veya
aksi takdirde geçersiz olursa ErrorCode::INVALID_KEY_BLOB
değerini döndürür. Eğer
değeri, yama düzeyi mevcut sistem değerinden yüksek olan bir anahtarla çağrılır.
ErrorCode::INVALID_ARGUMENT
değerini döndürür. Bir anahtarla çağrılırsa
işletim sistemi sürümü mevcut sistem değerinden ve
değeri sıfır değilse ErrorCode::INVALID_ARGUMENT
değerini döndürür. OS sürümü
yükseltmelere izin verilir. Hata olması durumunda
güvenli dünyayla iletişim kurduğunda, uygun bir hata değeri (ör.
ErrorCode::SECURE_HW_ACCESS_DENIED
,
ErrorCode::SECURE_HW_BUSY
) tıklayın. Aksi takdirde
ErrorCode::OK
ve şurada yeni bir anahtar blob'u döndürür:
upgradedKeyBlob
.
keyBlobToUpgrade
, upgradeKey
tarihinden sonra geçerli olmaya devam edecek
çağrısına dahildir ve cihazın eski sürüme geçirilmesi durumunda teorik olarak tekrar kullanılabilir. İçinde
anahtar deposu genellikledeleteKey
Çağrıdan kısa bir süre sonra keyBlobToUpgrade
blob'u
upgradeKey
. keyBlobToUpgrade
için etiket olsaydı
Tag::ROLLBACK_RESISTANT
, ardından upgradedKeyBlob
olması gerekir (geri almaya karşı dayanıklı olmalıdır).
Güvenli yapılandırma
Sürüm bağlamayı uygulamak için anahtar yöneticisi TA'nın güvenli bir şekilde alıp mevcut işletim sistemi sürümünü ve yama düzeyini (sürüm bilgisi) aldığı bilgiler, çalışan denemeyle ilgili bilgilerle güçlü bir şekilde eşleşiyor. bahsedeceğim.
Sürüm bilgilerinin TA'ya güvenli bir şekilde iletilmesini desteklemek için OS_VERSION
alanı, başlatma görüntüsü başlığına eklendi. Başlatma görüntüsü derlemesi
komut dosyası bu alanı otomatik olarak doldurur. OEM'ler ve keymaster TA uygulayıcıları
sürümünü çıkarmak üzere cihaz bootloader'larını değiştirmek için birlikte çalışma
güvenli olmayan dosyadan önce TA'ya iletmesini sağlamak için
başlatılması gerekir. Bu sayede, saldırganlar temel hazırlık işlemine müdahale edemez.
TA'ya geri gönderebilirsiniz.
Ayrıca, sistem görüntüsünün aynı sürüme sahip olduğundan emin olmak önyükleme görüntüsü olarak kaydedin. Bu amaçla yapılandırma yöntemi eklenmiştir. anahtar ana makinesi HAL'sine ekleyin:
keymaster_error_t (*configure)(const struct keymaster2_device* dev, const keymaster_key_param_set_t* params);
params
bağımsız değişkeni Tag::OS_VERSION
ve
Tag::OS_PATCHLEVEL
. Bu yöntem, keymaster2 istemcileri tarafından çağrılır
ancak başka yöntemler çağrılmadan önce yapılır. Başka bir yöntem
çağrısı, yapılandırmadan önce yapılırsa, TA
ErrorCode::KEYMASTER_NOT_CONFIGURED
configure
, cihaz başlatıldıktan sonra ilk kez çağrıldığında
sağlanan sürüm bilgilerinin
bootloader'ı tıklayın. Sürüm bilgileri eşleşmezse
configure
, ErrorCode::INVALID_ARGUMENT
değerini ve tümünü döndürür
diğer keymaster yöntemleri geri dönmeye devam eder
ErrorCode::KEYMASTER_NOT_CONFIGURED
. Bilgiler eşleşiyorsa
configure
, ErrorCode::OK
ve diğer anahtar yöneticisini döndürür
yöntemleri normal şekilde çalışmaya başlar.
configure
için yapılan sonraki çağrılar,
ve keymaster'ın durumunu değiştirmeyin. Bu işlemin
Tüm OTA'ların hem sistem hem de başlatma görüntülerini güncellemesini gerektirir; güncellenemezler
için ayrı ayrı kullanmanız gerekir.
Çünkü configure
, içerikleri olan sistem tarafından çağrılacaktır
olması durumunda, saldırganın doğrulama amacıyla kullanabileceği dar bir fırsat
sistem görüntüsünün güvenliğini ihlal edecek ve bunu, uygulamanızın
ile eşleşir, ancak bu, sistemin gerçek sürümü değildir. İlgili içeriği oluşturmak için kullanılan
başlatma görüntüsü doğrulaması ve sistem görüntüsünün dm-verity doğrulaması kombinasyonu
configure
ürününün daha erken bir tarihte çağrılması
bu fırsat penceresinden yararlanmayı zorlaştıracaktır.