Donanım Destekli Anahtar Deposu

Çip üzerindeki bir sistemde güvenilir yürütme ortamının kullanılabilirliği (SoC), Android cihazlara donanım destekli, donanım destekli Android OS'ten platform hizmetlerine ve hatta üçüncü taraf uygulamaları. Android'e özel uzantılar arayan geliştiricilerin web sitesini ziyaret etmesi gerekir android.security.keystore adresine gönderin.

Android 6.0'dan önce Android'de donanım destekli basit bir kripto zaten vardı Keymaster Donanım sürümünün 0.2 ve 0.3 sürümleri tarafından sağlanan hizmetler API'si Soyutlama Katmanı (HAL). Anahtar deposu tarafından sağlanan dijital imzalama ve doğrulama işlemleri, ayrıca asimetrik imzalama anahtar çiftlerinin oluşturulması ve içe aktarılması. Bu ancak çoğu cihazda uygulanmasına rağmen, yalnızca bir imza API'sıyla gerçekleştirilemez. Android 6.0'da anahtar deposu Keystore API'yi daha geniş bir özellik yelpazesi sunmak için genişletti.

Android 6.0'da, Anahtar Deposu eklendi simetrik kriptografik temel öğeleri, AES ve HMAC ile donanım destekli anahtarlar için bir erişim kontrol sistemi. Erişme Kontroller, anahtar oluşturma sırasında belirtilir ve gerekir. Anahtarlar, yalnızca kullanıcı işlemi gerçekleştirildikten sonra kullanılabilir ve yalnızca belirtilen amaçlar için veya belirtilen kriptografik özellik ile parametreleridir. Daha fazla bilgi için Yetkilendirme Etiketleri ve İşlevler sayfaları

Temel kriptografi öğelerinin kapsamını genişletmenin yanı sıra Android 6.0'a aşağıdaki özellikler eklendi:

• Anahtar kullanımının kısıtlanmasını sağlayarak anahtarların hatalı kullanımından kaynaklanan güvenlik ihlali riski
• Anahtarların belirli kullanıcılarla kısıtlanmasını sağlayan bir erişim kontrol şeması ve tanımlanmış bir zaman aralığı

Android 7.0'da Keymaster 2, anahtar onayı ve sürümü için destek ekledi bağlama'yı tıklayın. Anahtar onayı anahtarın ayrıntılı açıklamasını içeren ortak anahtar sertifikalarını sağlar ve erişim denetimlerini kullanarak anahtarın güvenli donanım ve donanım üzerindeki varlığını uzaktan doğrulanabilir.

Sürüm bağlama anahtarları, işletim sistemine ve yama düzeyindeki sürüme bağlar. Böylece proje daha sistemin eski bir sürümünde bir zayıflık olduğunu keşfeden veya TEE yazılımları bir cihazı güvenlik açığı içeren sürüme geri döndüremez ve anahtarları kullanamaz yeni sürümle oluşturulur. Ayrıca, belirli bir sürüme sahip bir anahtar Daha yeni bir sürüme geçirilen cihazlarda yama düzeyi kullanılıyorsa anahtarın kullanılmadan önce yeni sürüme geçirilmesi ve anahtar sürümü geçersiz kılındı. Cihaz yükseltilirken "mandallı" tuşları cihazla birlikte yönlendirilmelidir, ancak cihazın önceki bir sürüme geri döndürülmesi anahtarların kullanılamaz hale gelmesine neden olur.

Android 8.0'da Keymaster 3, eski stil C yapısında bulunan Donanımdan geçiş yaptı Bir tanımdan oluşturulan C++ HAL arayüzüne soyutlama katmanı (HAL) yeni Donanım Arayüzü Tanımlama Dili'nde (HIDL) bulabilirsiniz. Bu değişikliğin bir parçası olarak, birçok bağımsız değişken türü değişti, ancak tür ve yöntemler bire bir eski türlerle ve HAL yapı yöntemleriyle yazışmaktır. Bkz. Daha fazlası için İşlevler sayfasında bolca fırsat sunuyor.

Bu arayüz düzeltmesine ek olarak, Android 8.0 genişletilmiş Keymaster 2 onay özelliğini kullanarak Kimlik onayı. Kimlik onayı, güçlü onay için sınırlı ve isteğe bağlı bir mekanizma sağlar cihaz seri numarası, ürün adı ve telefon gibi donanım tanımlayıcılarına kimliği (IMEI / MEID). Android 8.0, bu eklemeyi uygulamak için ASN.1'i değiştirdi. onay şeması oluşturun. Keymaster uygulamalarının yanı sıra ilgili veri öğelerini almanın güvenli bir yolunu bulmanın yanı sıra, özelliği güvenli ve kalıcı olarak devre dışı bırakma mekanizmasıdır.

Android 9'da güncellemeler şunları içeriyordu:

• Şu sürüme güncelle: Anahtar Yöneticisi 4
• Yerleştirilmiş Güvenlik Unsuru desteği
• Güvenli anahtarı içe aktarma desteği
• 3DES şifreleme desteği
• Sürüm bağlamada yapılan, boot.img ve system.img komutlarını içeren değişiklikler bağımsız güncellemelere olanak tanımak için sürümleri ayrı ayrı ayarlayın

Sözlük

Keystore bileşenleri ve bunların ilişkilerine hızlıca genel bir bakışı burada bulabilirsiniz.

AndroidKeystore, Android Framework API ve kullanılan bileşendir Anahtar Deposu işlevine erişmek için uygulamalar tarafından etkinleştirilir. Gelecekteki projelerinizde API'lerden oluşur ve geliştirilen Java kodundan oluşur. uygulamanın kendi işlem alanında çalışır. AndroidKeystore, uygulamayı karşılıyor anahtar deposu arka plan programına yönlendirerek Anahtar Deposu davranışı isteklerinden bahsedeceğiz.

keystore arka plan programı bir Android sistem arka plan programıdır; Binder API aracılığıyla tüm Anahtar Deposu işlevlerine erişebilir. Bunlar, anahtar blob'ları depolamak için gerçek gizli anahtar materyalini içerir. Anahtar Deposu bunları depolayabilir, ancak açıklamayacaktır.

keymasterd, şuraya erişim sağlayan bir HIDL sunucusudur: Keymaster TA. (Bu ad standart hale getirilmemiştir ve kavram amaçlıdır.)

Keymaster TA (güvenilir uygulama) sağlayan, ARM SoC'deki TrustZone'da genellikle anahtar deposu işlemlerini gerçekleştirmenize yardımcı olur, ham anahtar materyaline erişebilir, tüm anahtarlardaki erişim denetimi koşulları gibi.

LockSettingsService, bu programdan sorumlu Android sistem bileşenidir (kullanıcı kimlik doğrulaması için) (hem şifre hem de parmak izi) destekler. Bu hizmet, Anahtar deposu, ancak birçok Anahtar Deposu anahtar işlemi kullanıcı gerektirdiği için önemlidir kimlik doğrulama. LockSettingsService, Kapı Görevlisi ile etkileşim kuruyor TA ve Parmak İzi TA'nın kimlik doğrulama jetonlarını alması için anahtar deposu arka plan programıdır ve nihai olarak Keymaster TA tarafından kullanılan bir uygulamadır.

Gatekeeper TA (güvenilir uygulama) başka bir bileşendir. kullanıcı kimliğini doğrulamaktan sorumlu olan güvenli bağlamda Keymaster TA'ya bunu kanıtlamak için kullanılan şifreler ve kimlik doğrulama jetonları oluşturma bir kullanıcı için kimlik doğrulamasının belli bir noktada yapıldığını gerekir.

Parmak İzi TA (güvenilir uygulama) başka bir bileşendir kullanıcının kimliğini doğrulamaktan sorumlu güvenli bağlamda çalışan Keymaster'a kendini kanıtlamak için kullanılan dijital parmak izleri ve kimlik doğrulama jetonları oluşturma TA, bir kimlik doğrulama işleminin belirli bir noktada belirli bir kullanıcı için yapıldığını gösterir gerekiyor.

Mimari

Android Keystore API ve temel Keymaster HAL verilerin şifrelenmesine izin vermek için temel ancak yeterli miktarda temel kriptografi Protokollerin uygulanması için erişim kontrollü, donanım destekli anahtarlar kullanır.

Keymaster HAL, OEM tarafından sağlanan ve dinamik olarak yüklenebilen bir kitaplıktır. Anahtar Deposu hizmetini kullanarak donanım destekli şifreleme hizmetleri sunabilirsiniz. Saklamak için HAL uygulamaları, başka hiçbir veri deposunda hassas işlemler hatta çekirdek alanında bile olmayabilir. Hassas işlemler bir güvenli işlemciye kadar (ör. belirli çekirdek arayüzleri) Elde edilen mimari şöyle görünür:

Şekil 1. Keymaster'a Erişim

Android cihazlarda "istemci" Keymaster HAL şunlardan oluşur: birden fazla katman (ör. uygulama, çerçeve, Keystore arka plan programı) içerir, ancak bu yoksayılabilir bu belgenin amaçları doğrultusunda kullanılması. Bu, açıklanan Keymaster HAL'nin API alt düzey olup dahili platform bileşenleri tarafından kullanılır ve uygulamaya açılmaz birlikte çalışır. Üst düzey API, Android Developers sitesinde açıklanmaktadır.

Keymaster HAL'nin amacı, güvenlik açısından hassas güvenli dünyaya sunmaları için yalnızca marşal ve mareşal kaldırma talepleri ile çalışmaktadır. İlgili içeriği oluşturmak için kullanılan kablo biçimi, uygulama tarafından tanımlanmıştır.

Önceki sürümle uyumluluk sürümler

Keymaster 1 HAL, önceden yayınlanan HAL'ler (ör. Keymaster 0.2 ve 0.3. Kolaylaştırmak için Android 5.0 ve önceki sürümleri çalıştıran cihazlarda birlikte çalışabilirlik Keymaster HAL'lerini geride bırakırken Keystore, Mevcut donanım kitaplığına yapılan çağrıları olan Keymaster 1 HAL. Sonuç, Keymaster 1 HAL'de tüm işlevleri sunar. Özellikle, yalnızca RSA ve ECDSA algoritmalarını ve tüm anahtar yetkilendirme işlevlerini destekler. güvenli olmayan ortamda bağdaştırıcı tarafından uygulanır.

Keymaster 2, get_supported_* yöntemleri ve finish() izin verdiği için yöntemini kullanın. Bu da TEE'ye yapılan gidiş dönüş sayısının tüm bunların aynı anda kullanılabilir olduğu ve proje yaşam döngüsünün AEAD şifre çözme.

Android 8.0'da Keymaster 3, eski stil C yapısından geçiş yaptı Yeni Donanım Arayüzü Tanımlama Dili (HIDL). Yeni tarz bir HAL uygulama, oluşturulan verinin alt sınıflandırılmasıyla IKeymasterDevice sınıf ve saf sanal uygulama yöntemlerine göz atın. Bu değişiklik kapsamında, birçok bağımsız değişken türü değişti. ancak türler ve yöntemler eski öğelerle bire bir ve HAL struct yöntemleridir.

HIDL'ye genel bakış

Donanım Arayüzü Tanımlama Dili (HIDL), sistemdeki donanım arayüzlerini belirtmek için dilden bağımsız bir mekanizma. HIDL araçları şu anda C++ ve Java arayüzlerinin oluşturulmasını desteklemektedir. Bu beklenen bir şey En Güvenilir Yürütme Ortamı (TEE) uygulayıcılarının C++ kullanımına daha uygun olduğu için bu belgede yalnızca C++ temsili ele alınmaktadır.

HIDL arayüzleri, şu şekilde ifade edilen bir dizi yöntemden oluşur:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Önceden tanımlanmış çeşitli türler vardır ve HAL'ler, yeni numaralandırılmış ve yapılandırabilirsiniz. HIDL hakkında daha fazla bilgi için Referans bölümüne göz atın.

Keymaster 3 IKeymasterDevice.hal'deki örnek bir yöntem şunlardır:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Bu, keymaster2 HAL'deki aşağıdakilere eşdeğerdir:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

HIDL sürümünde dev bağımsız değişkeni kapalıdır. params bağımsız değişkeni artık key_parameter_t nesne dizisine referans veren işaretçi, ancak KeyParameter nesne içeren vec (vektör). İlgili içeriği oluşturmak için kullanılan dönüş değerleri "generates" içinde listeleniyor her bir açıklamanın anahtar blobu için uint8_t değerlerinin vektörü.

HIDL derleyicisi tarafından oluşturulan C++ sanal yöntemi:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Burada generateKey_cb, şu şekilde tanımlanan bir işlev işaretçisidir:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Yani generateKey_cb, döndürülen değerleri alan bir işlevdir create yan tümcesinde listelenir. HAL uygulama sınıfı bunu geçersiz kılar generateKey yöntemini kullanır ve generateKey_cb işlevini çağırır işaretçisini kullanın. Fonksiyonu not edin İşaretçi çağrısı eşzamanlıdır. Arayan generateKey ve generateKey, sağlanan çağrıyı yapar sonuna kadar yürütülen fonksiyon işaretçisini kullanın ve kontrolü generateKey uygulanması, daha sonra çağrıya geri döner.

Ayrıntılı bir örnek için hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp Varsayılan uygulama, Keymaster0, keymaster1 veya keymaster2 HALS.

Erişim denetimi

Anahtar deposu erişim denetiminin en temel kuralı, her uygulamanın kendi ad alanına sahip olmanız gerekir. Ancak her kuralın bir istisnası vardır. Anahtar deposunda ve diğer belirli sistem bileşenlerinin sistem bileşenlerine erişmesine olanak ad alanları. Bu, tek bir bileşene sahip olduğu başka bir ad alanı üzerinde tam kontrol sahibidir. İkincisi de teslimatları yapmak, istemci olarak ele alacağız. Elimizde şu an için hiçbir şekilde bir WPA tedarikçisi gibi tedarikçi bileşenleri için ad alanı.

Tedarikçi firma bileşenlerini yerleştirmek ve erişim kontrolünü genelleştirmek için Keystore 2.0, sabit kodlu istisnalar olmadan, alan adlarını ve SELinux'u kullanıma sunar ad alanları.

Anahtar Deposu Alan Adları

Anahtar deposu alan adlarıyla, ad alanlarını UID'lerden ayırabiliriz. Müşteriler Anahtar Deposu'nda bir anahtara erişmek; alan adını, ad alanını ve takma adı belirtmelidir otomatik olarak oluşturabilirsiniz. Bu unsura ve arayan kişinin kimliğine dayanarak arayanın hangi tuşa erişmek istediğini ve bunun uygun olup olmadığını belirleyebilir izin verir.

Anahtarlara nasıl erişilebileceğini belirleyen beş alan parametresini kullanıma sunduk. Anahtar tanımlayıcının ad alanı parametresinin anlamını kontrol eder ve nasıl gerçekleştirileceğini anlatır.

• DOMAIN_APP: Uygulama alanı, eski davranış. Java Anahtar Deposu SSA'sı varsayılan olarak bu alan adını kullanır. Bu alan adı kullanılırsa ad alanı bağımsız değişkeni yoksayılır ve çağrıyı yapanın UID'si kullanılır. Bu alana erişim, SELinux politikasındaki keystore_key sınıfı.
• DOMAIN_SELINUX: Bu alan adı, ad alanının SELinux politikasında bir etiketi vardır. Ad alanı parametresi çevrildiğini ve hedef bağlama çevrildiğini düşünmesinin ardından keystore_key sınıfı için çağrı yapan SELinux bağlamı. belirtilen işlem için izin oluşturulduysa, söz konusu işlem için tam defter kullanılır kontrol edebilirsiniz.
• DOMAIN_GRANT: Hibe alan adı, ad alanı parametresi bir izin tanımlayıcısıdır. Takma ad parametresi yoksayılır. SELinux denetimleri izin oluşturulduğunda gerçekleştirilir. Daha fazla erişim denetimi yalnızca arayan UID'sinin, istenen iznin alan UID'si ile eşleşip eşleşmediğini kontrol eder.
• DOMAIN_KEY_ID: Bu alan adı, ad alanı parametresi, benzersiz bir anahtar kimliğidir. Anahtarın kendisi oluşturulmuş olabilir DOMAIN_APP veya DOMAIN_SELINUX ile. İzin Kontrol, domain ve namespace sonrasında yapılır blob'un yüklenmesi ile aynı şekilde anahtar veritabanından yüklenmiş olmalıdır. alan adı, ad alanı ve takma ad grubuna göre belirlenir. Anahtar kimliği alanının gerekçesi devamlılıktır. Bir anahtara takma adla erişildiğinde, sonraki çağrılar Çünkü yeni bir anahtar oluşturulmuş veya içe aktarılmış ve bağlanmış olabilir. bu takma ada. Ancak anahtar kimliği hiçbir zaman değişmez. Anahtar kimliğine göre bir anahtar kullanırken takma adı kullanarak Anahtar Deposu veritabanından yüklendikten sonra, ikinci bir anahtar kimliği mevcut olduğu sürece bu anahtarın aynı anahtar olduğundan emin olabilir. Bu işlevselliği, uygulama geliştiricilere sunulmaz. Bunun yerine, Kullanılsa bile daha tutarlı bir deneyim sağlamak için Android Anahtar Deposu SSA'sı güvenli bir şekilde eş zamanlı olarak kaybetmez.
• DOMAIN_BLOB: Blob alanı, blob'u kendisi yönetir. Bu bölüm, şunları yapması gereken müşteriler için kullanılır: Anahtar Deposu'na erişim sağlayabilirsiniz. Temel blob anahtar tanımlayıcının blob alanına eklenir.

SELinux alanını kullanarak tedarikçi bileşenlerinin Örneğin, iletişim kutusunu açar.

keystore_key için SELinux politikası

Ad alanı etiketleri, keystore2_key_context kullanılarak yapılandırılır. dosyası olarak kaydedebilirsiniz.
. Bu dosyalardaki her satır, bir sayısal ad alanı kimliğini bir SELinux etiketiyle eşler. Örneğin,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

Bu şekilde yeni bir anahtar ad alanı oluşturduktan sonra bu anahtar ad alanına erişim verebiliriz. uygun bir politika ekleyerek. Örneğin, Yeni ad alanında anahtarları alıp kullanmak için wpa_supplicant şu satırı hal_wifi_supplicant.te öğesine ekleyin:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Yeni ad alanını oluşturduktan sonra, AndroidKeyStore neredeyse her zamanki gibi. Tek fark, ad alanı kimliğinin belirtilmesidir. Örneğin, Anahtarlar'dan ve Anahtar Deposu'na anahtarlar yüklenirken ve içe aktarılırken, ad alanı kimliği (AndroidKeyStoreLoadStoreParameter) kullanarak. Örneğin,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

Belirli bir ad alanında anahtar oluşturmak için ad alanı kimliği sağlanmalıdır KeyGenParameterSpec.Builder#setNamespace(): kullanılıyor

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

Aşağıdaki bağlam dosyaları, Keystore 2.0 SELinux'u yapılandırmak için kullanılabilir ad alanları. Her bölümün 10.000 ad alanılık farklı ayrılmış bir aralığı vardır kimlikler kullanılır.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

İstemci SELinux alanını ve istenen sanal ad alanını sayısal kimliğine göre (bu örnekte "wifi_key") belirtir.

Bunların üzerinde aşağıdaki ad alanları tanımlanmıştır. Değiştirilirse benzersiz kuralların bulunduğu UID, aşağıdaki tabloda .

Vektörlere erişme

keystore_key SELinux sınıfı epey zaman geçti ve verify veya sign gibi izinler kayboldu anlamları vardır. Yeni izin grubu olan keystore2_key aşağıda verilmiştir Anahtar Deposu 2.0'ın zorunlu kılacağından emin olun.

Ayrıca, anahtarlara özgü olmayan bir dizi anahtar deposu iznini SELinux güvenlik sınıfı keystore2: