Sürüm Bağlama

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 edebilir
    • system.img, yama düzeyini ve işletim sistemi sürümünü salt okunur olarak depolamaya devam edebilir mülkler
    • vendor.img, yama düzeyini salt okunur mülkte depolar ro.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üm
    • BOOT_PATCH_LEVEL: boot bölüm
    • OS_PATCH_LEVEL ve OS_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ır
  • keyBlobToUpgrade, yeni sürüme geçirilmesi gereken anahtardır
  • upgradeParams, anahtarı yeni sürüme geçirmek için gereken parametrelerdir. Bu Tag::APPLICATION_ID ve Tag::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.