Donanım destekli Anahtar Deposu

Bir çip üzerindeki bir sistemde (SoC) güvenilir bir yürütme ortamının bulunması, Android cihazların Android işletim sistemine, platform hizmetlerine ve hatta üçüncü taraf uygulamalara donanım destekli, güçlü güvenlik hizmetleri sağlama fırsatı sunar. Android'e özgü uzantıları arayan geliştiriciler, android.security.keystore adresine gitmelidir.

Android 6.0'dan önce Android, Keymaster Donanım Soyutlama Katmanı'nın (HAL) 0.2 ve 0.3 sürümleri tarafından sağlanan basit, donanım destekli bir kripto hizmetleri API'sine sahipti. Anahtar deposu, dijital imzalama ve doğrulama işlemlerinin yanı sıra asimetrik imzalama anahtar çiftlerinin oluşturulmasını ve içe aktarılmasını sağladı. Bu zaten birçok cihazda uygulanmaktadır, ancak yalnızca bir imza API'si ile kolayca ulaşılamayan birçok güvenlik hedefi vardır. Android 6.0'daki anahtar deposu, daha geniş bir yetenek yelpazesi sağlamak için Anahtar Deposu API'sini genişletti.

Android 6.0'da Keystore, simetrik şifreleme ilkelleri , AES ve HMAC ve donanım destekli anahtarlar için bir erişim kontrol sistemi ekledi. Erişim denetimleri, anahtar oluşturma sırasında belirlenir ve anahtarın ömrü boyunca uygulanır. Anahtarlar, yalnızca kullanıcının kimliği doğrulandıktan sonra ve yalnızca belirtilen amaçlar için veya belirtilen şifreleme parametreleriyle kullanılabilir olacak şekilde kısıtlanabilir. Daha fazla bilgi için Yetkilendirme Etiketleri ve İşlevler sayfalarına bakın.

Android 6.0'daki Keystore, şifreleme temel öğelerinin kapsamını genişletmeye ek olarak şunları ekledi:

• Anahtarların yanlış kullanımından kaynaklanan güvenlik ihlali riskini azaltmak için anahtar kullanımının sınırlandırılmasına izin veren bir kullanım kontrol şeması
• Anahtarların belirli kullanıcılara, istemcilere ve tanımlanmış bir zaman aralığına kısıtlanmasını sağlayan bir erişim kontrol şeması

Android 7.0'da Keymaster 2, anahtar doğrulama ve sürüm bağlama desteği ekledi. Anahtar onayı, anahtarın güvenli donanımdaki varlığını ve yapılandırmasını uzaktan doğrulanabilir kılmak için anahtarın ve erişim kontrollerinin ayrıntılı bir tanımını içeren ortak anahtar sertifikaları sağlar.

Sürüm bağlama , anahtarları işletim sistemine ve yama düzeyindeki sürüme bağlar. Bu, sistemin eski bir sürümünde veya TEE yazılımında bir zayıflık keşfeden bir saldırganın, bir cihazı savunmasız sürüme geri almamasını ve daha yeni sürümle oluşturulan anahtarları kullanmamasını sağlar. Ayrıca, daha yeni bir sürüme veya yama düzeyine yükseltilmiş bir cihazda belirli bir sürüm ve yama düzeyine sahip bir anahtar kullanıldığında, anahtar kullanılmadan önce yükseltilir ve anahtarın önceki sürümü geçersiz kılınır. Cihaz yükseltilirken, tuşlar cihazla birlikte "mandallanır", ancak cihazın herhangi bir önceki sürüme döndürülmesi, tuşların kullanılamaz hale gelmesine neden olur.

Android 8.0'da Keymaster 3, eski tarz C yapısı Donanım Soyutlama Katmanından (HAL) yeni Donanım Arayüzü Tanımlama Dili'ndeki (HIDL) bir tanımdan oluşturulan C++ HAL arayüzüne geçiş yaptı. Değişikliğin bir parçası olarak, argüman türlerinin çoğu değişti, ancak türler ve yöntemler, eski türler ve HAL yapı yöntemleriyle birebir örtüşüyor. Daha fazla ayrıntı için İşlevler sayfasına bakın.

Bu arayüz revizyonuna ek olarak, Android 8.0, Keymaster 2'nin doğrulama özelliğini kimlik doğrulamasını destekleyecek şekilde genişletti. Kimlik onayı, aygıt seri numarası, ürün adı ve telefon kimliği (IMEI / MEID) gibi donanım tanımlayıcılarını güçlü bir şekilde doğrulamak için sınırlı ve isteğe bağlı bir mekanizma sağlar. Bu eklemeyi uygulamak için Android 8.0, ASN.1 onay şemasını kimlik onayı eklemek üzere değiştirdi. Keymaster uygulamalarının, ilgili veri öğelerini almanın güvenli bir yolunu bulması ve özelliği güvenli ve kalıcı olarak devre dışı bırakmak için bir mekanizma tanımlaması gerekir.

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

• Keymaster 4'e güncelleme
• Yerleşik Güvenli Öğeler için destek
• Güvenli anahtar içe aktarma desteği
• 3DES şifreleme desteği
• Boot.img ve system.img'nin bağımsız güncellemelere izin vermek için ayrı ayrı ayarlanmış sürümleri olması için sürüm bağlamada yapılan değişiklikler

Sözlük

Anahtar deposu bileşenlerine ve ilişkilerine hızlı bir genel bakış burada.

AndroidKeystore , Android Framework API'si ve uygulamalar tarafından Anahtar Deposu işlevine erişmek için kullanılan bileşendir. Standart Java Kriptografi Mimarisi API'lerinin bir uzantısı olarak uygulanır ve uygulamanın kendi işlem alanında çalışan Java kodundan oluşur. AndroidKeystore , Keystore davranışına yönelik uygulama isteklerini anahtar deposu arka plan programına ileterek karşılar.

Anahtar deposu arka plan programı , bir Binder API aracılığıyla tüm Anahtar Deposu işlevlerine erişim sağlayan bir Android sistem arka plan programıdır. Gerçek gizli anahtar malzemesini içeren "anahtar bloblarını" saklamaktan sorumludur, böylece Keystore bunları saklayabilir, ancak kullanamaz veya gösteremez.

keymasterd , Keymaster TA'ya erişim sağlayan bir HIDL sunucusudur. (Bu isim standart değildir ve kavramsal amaçlar içindir.)

Keymaster TA (güvenilir uygulama), güvenli bir bağlamda, çoğunlukla bir ARM SoC'de TrustZone'da çalışan, tüm güvenli Anahtar Deposu işlemlerini sağlayan, ham anahtar malzemesine erişimi olan, anahtarlar üzerindeki tüm erişim kontrol koşullarını doğrulayan yazılımdır. , vb.

LockSettingsService , hem şifre hem de parmak izi olmak üzere kullanıcı kimlik doğrulamasından sorumlu Android sistem bileşenidir. Anahtar Deposu'nun bir parçası değildir, ancak birçok Anahtar Deposu anahtar işlemi kullanıcı kimlik doğrulaması gerektirdiğinden alakalıdır. LockSettingsService , anahtar deposu arka plan programına sağladığı ve nihai olarak Keymaster TA uygulaması tarafından tüketilen kimlik doğrulama belirteçlerini elde etmek için Gatekeeper TA ve Fingerprint TA ile etkileşime girer.

Gatekeeper TA (güvenilir uygulama), güvenli bağlamda çalışan ve kullanıcı parolalarının kimliğinin doğrulanmasından ve belirli bir zamanda belirli bir kullanıcı için bir kimlik doğrulamasının yapıldığını Keymaster TA'ya kanıtlamak için kullanılan kimlik doğrulama belirteçlerinin oluşturulmasından sorumlu olan başka bir bileşendir.

Parmak İzi TA (güvenilir uygulama), kullanıcının parmak izlerinin doğrulanmasından ve belirli bir zamanda belirli bir kullanıcı için bir kimlik doğrulamasının yapıldığını Keymaster TA'ya kanıtlamak için kullanılan kimlik doğrulama belirteçlerinin üretilmesinden sorumlu olan güvenli bağlamda çalışan başka bir bileşendir.

Mimari

Android Anahtar Deposu API'si ve temeldeki Keymaster HAL, erişim kontrollü, donanım destekli anahtarlar kullanılarak protokollerin uygulanmasına izin vermek için temel ancak yeterli bir şifreleme ilkel kümesi sağlar.

Keymaster HAL, donanım destekli şifreleme hizmetleri sağlamak için Keystore hizmeti tarafından kullanılan, OEM tarafından sağlanan, dinamik olarak yüklenebilir bir kitaplıktır. İşleri güvende tutmak için, HAL uygulamaları kullanıcı alanında ve hatta çekirdek alanında herhangi bir hassas işlem gerçekleştirmez. Hassas işlemler, bazı çekirdek arabirimleri aracılığıyla ulaşılan güvenli bir işlemciye devredilir. Ortaya çıkan mimari şöyle görünür:

Şekil 1. Keymaster'a Erişim

Bir Android aygıtında, Keymaster HAL'nin "istemcisi" birden çok katmandan oluşur (örn. uygulama, çerçeve, Anahtar deposu arka plan programı), ancak bu belgenin amaçları doğrultusunda bu katmanlar göz ardı edilebilir. Bu, açıklanan Keymaster HAL API'sinin düşük seviyeli olduğu, platformun dahili bileşenleri tarafından kullanıldığı ve uygulama geliştiricilerine açık olmadığı anlamına gelir. Üst düzey API, Android Geliştirici sitesinde açıklanmaktadır.

Keymaster HAL'ın amacı, güvenliğe duyarlı algoritmaları uygulamak değil, yalnızca güvenli dünyaya yönelik istekleri sıraya koymak ve sıraya koymaktır. Tel formatı uygulama tanımlıdır.

Önceki sürümlerle uyumluluk

Keymaster 1 HAL, daha önce yayınlanan HAL'lerle, örneğin Keymaster 0.2 ve 0.3 ile tamamen uyumsuzdur. Eski Keymaster HAL'leri ile başlatılan Android 5.0 ve önceki sürümleri çalıştıran cihazlarda birlikte çalışabilirliği kolaylaştırmak için Keystore, mevcut donanım kitaplığına yapılan çağrılarla Keymaster 1 HAL'ı uygulayan bir bağdaştırıcı sağlar. Sonuç, Keymaster 1 HAL'de tam işlevsellik sağlayamaz. Özellikle, yalnızca RSA ve ECDSA algoritmalarını destekler ve tüm anahtar yetkilendirme zorlaması, güvenli olmayan dünyada adaptör tarafından gerçekleştirilir.

Keymaster 2, get_supported_* yöntemlerini kaldırarak ve finish() yönteminin girişi kabul etmesine izin vererek HAL arabirimini daha da basitleştirdi. Bu, girdinin tamamının aynı anda mevcut olduğu durumlarda TEE'ye gidiş dönüş sayısını azaltır ve AEAD şifre çözme uygulamasını basitleştirir.

Android 8.0'da Keymaster 3, eski tarz C yapısı HAL'den yeni Donanım Arayüzü Tanımlama Dili'ndeki (HIDL) bir tanımdan oluşturulan C++ HAL arayüzüne geçiş yaptı. Oluşturulan IKeymasterDevice sınıfının alt sınıflanması ve saf sanal yöntemlerin uygulanmasıyla yeni stil bir HAL uygulaması oluşturulur. Değişikliğin bir parçası olarak, argüman türlerinin çoğu değişti, ancak türler ve yöntemler, eski türler ve HAL yapı yöntemleriyle birebir örtüşüyor.

HIDL'ye genel bakış

Donanım Arabirim Tanımlama Dili (HIDL), donanım arabirimlerini belirtmek için uygulama dilinden bağımsız bir mekanizma sağlar. HIDL araçları şu anda C++ ve Java arabirimlerinin oluşturulmasını desteklemektedir. Çoğu Güvenilir Yürütme Ortamı (TEE) uygulayıcısının C++ araçlarını daha uygun bulması beklenir, bu nedenle bu belgede yalnızca C++ gösterimi ele alınmaktadır.

HIDL arayüzleri, şu şekilde ifade edilen bir dizi metottan 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ı türleri tanımlayabilir. HIDL hakkında daha fazla ayrıntı için Referans bölümüne bakın .

Keymaster 3 IKeymasterDevice.hal örnek bir yöntem:

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

Bu, keymaster2 HAL'den aşağıdakilerin eşdeğeridir:

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, örtük olduğu için dev argümanı kaldırılmıştır. params argümanı artık KeyParameter nesnelerinin bir dizisine başvuran bir işaretçi içeren bir yapı değil, key_parameter_t nesnelerini içeren bir vec (vektör). Anahtar blobu için uint8_t değerlerinin bir vektörü de dahil olmak üzere, dönüş değerleri " generates " yan tümcesinde listelenir.

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

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

generateKey_cb şu şekilde tanımlanan bir işlev işaretçisi olduğu yerde:

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

Yani, generateKey_cb , create yan tümcesinde listelenen dönüş değerlerini alan bir işlevdir. HAL uygulama sınıfı, bu generateKey yöntemini geçersiz kılar ve işlemin sonucunu arayana döndürmek için generateKey_cb işlev işaretçisini çağırır. İşlev işaretçisi çağrısının eşzamanlı olduğuna dikkat edin. Çağıran, generateKey çağırır ve generateKey , sağlanan işlev işaretçisini çağırır; bu, tamamlanana kadar yürütülür ve denetimi, generateKey uygulamasına geri döndürür ve ardından, arayana geri döner.

Ayrıntılı bir örnek için, hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp içindeki varsayılan uygulamaya bakın. Varsayılan uygulama, eski tarz keymaster0, keymaster1 veya keymaster2 HALS ile cihazlar için geriye dönük uyumluluk sağlar.

Giriş kontrolu

Anahtar deposu erişim denetiminin en temel kuralı, her uygulamanın kendi ad alanına sahip olmasıdır. Ancak her kuralın bir istisnası vardır. Anahtar deposu, belirli sistem bileşenlerinin belirli diğer ad alanlarına erişmesine izin veren bazı sabit kodlanmış haritalara sahiptir. Bu, bir bileşene başka bir ad alanı üzerinde tam kontrol sağladığı için çok kör bir araçtır. Ve sonra, Keystore'un istemcileri olarak satıcı bileşenleri meselesi var. Şu anda, örneğin WPA sağlayıcısı gibi satıcı bileşenleri için bir ad alanı oluşturma yolumuz yok.

Satıcı bileşenlerini barındırmak ve sabit kodlanmış istisnalar olmadan erişim kontrolünü genelleştirmek için Keystore 2.0, etki alanlarını ve SELinux ad alanlarını sunar.

Anahtar Deposu Etki Alanları

Anahtar deposu etki alanları ile ad alanlarını UID'lerden ayırabiliriz. Anahtar Deposunda bir anahtara erişen istemciler, erişmek istedikleri etki alanını, ad alanını ve diğer adı belirtmelidir. Bu demete ve arayanın kimliğine dayanarak, arayanın hangi anahtara erişmek istediğini ve uygun izinlere sahip olup olmadığını belirleyebiliriz.

Anahtarlara nasıl erişilebileceğini yöneten beş etki alanı parametresi sunuyoruz. Anahtar tanımlayıcının ad alanı parametresinin anlamını ve erişim denetiminin nasıl gerçekleştirildiğini kontrol ederler.

• DOMAIN_APP : Uygulama etki alanı, eski davranışı kapsar. Java Anahtar Deposu SPI, varsayılan olarak bu etki alanını kullanır. Bu etki alanı kullanıldığında, ad alanı argümanı yok sayılır ve bunun yerine arayanın UID'si kullanılır. Bu etki alanına erişim, SELinux ilkesindeki keystore_key sınıfının Keystore etiketi tarafından kontrol edilir.
• DOMAIN_SELINUX : Bu etki alanı, ad alanının SELinux politikasında bir etiketi olduğunu gösterir. Ad alanı parametresi aranır ve bir hedef bağlama çevrilir ve keystore_key sınıfı için çağıran SELinux bağlamı için bir izin denetimi gerçekleştirilir. Verilen işlem için izin oluşturulduğunda, anahtar araması için tam demet kullanılır.
• DOMAIN_GRANT : Hibe etki alanı, ad alanı parametresinin bir hibe tanımlayıcısı olduğunu belirtir. Diğer ad parametresi yoksayılır. SELinux kontrolleri, hibe oluşturulduğunda gerçekleştirilir. Daha fazla erişim kontrolü, yalnızca arayan UID'sinin, talep edilen iznin verilen UID'si ile eşleşip eşleşmediğini kontrol eder.
• DOMAIN_KEY_ID : Bu etki alanı, ad alanı parametresinin benzersiz bir anahtar kimliği olduğunu gösterir. Anahtarın kendisi DOMAIN_APP veya DOMAIN_SELINUX ile oluşturulmuş olabilir. İzin denetimi, domain ve namespace , blob etki alanı, ad alanı ve diğer ad demeti tarafından yüklenmiş gibi, anahtar veritabanından yüklendikten sonra gerçekleştirilir. Anahtar kimlik alanının mantığı sürekliliktir. Bir anahtara takma adla erişilirken, sonraki çağrılar farklı anahtarlarda çalışabilir, çünkü yeni bir anahtar oluşturulmuş veya içe aktarılmış ve bu takma adla ilişkilendirilmiş olabilir. Ancak anahtar kimliği asla değişmez. Bu nedenle, takma ad kullanılarak Anahtar Deposu veritabanından yüklendikten sonra anahtar kimliğine göre bir anahtar kullanıldığında, anahtar kimliği hala var olduğu sürece bunun aynı anahtar olduğundan emin olunabilir. Bu işlevsellik, uygulama geliştiricilerine açık değildir. Bunun yerine, aynı anda güvenli olmayan bir şekilde kullanıldığında bile daha tutarlı bir deneyim sağlamak için Android Keystore SPI içinde kullanılır.
• DOMAIN_BLOB : Blob etki alanı, arayanın blobu kendi başına yönettiğini gösterir. Bu, veri bölümü monte edilmeden önce Anahtar Deposuna erişmesi gereken istemciler için kullanılır. Anahtar blob, anahtar tanımlayıcısının blob alanına dahil edilir.

SELinux etki alanını kullanarak, satıcı bileşenlerine, ayarlar iletişim kutusu gibi sistem bileşenleri tarafından paylaşılabilen çok özel Anahtar Deposu ad alanlarına erişim sağlayabiliriz.

keystore_key için SELinux politikası

Ad alanı etiketleri, keystore2_key_context dosyası kullanılarak yapılandırılır.
Bu dosyalardaki her satır, sayısal bir ad alanı kimliğini bir SELinux etiketine 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 key namespace ayarladıktan sonra uygun bir politika ekleyerek ona erişim verebiliriz. Örneğin, wpa_supplicant yeni ad alanında anahtarları almasına ve kullanmasına izin vermek için hal_wifi_supplicant.te aşağıdaki satırı ekleriz:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Yeni ad alanını ayarladıktan sonra, AndroidKeyStore neredeyse her zamanki gibi kullanılabilir. Tek fark, ad alanı kimliğinin belirtilmesi gerektiğidir. Anahtarları Keystore'dan yüklemek ve Keystore'a aktarmak için ad alanı kimliği AndroidKeyStoreLoadStoreParameter kullanılarak belirtilir. Ö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 bir anahtar oluşturmak için, KeyGenParameterSpec.Builder#setNamespace():

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

Keystore 2.0 SELinux ad alanlarını yapılandırmak için aşağıdaki bağlam dosyaları kullanılabilir. Her bölüm, çarpışmaları önlemek için farklı bir ayrılmış 10.000 ad alanı kimliği aralığına sahiptir.

/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 etki alanını ve bu durumda "wifi_key" istenen sanal ad alanını sayısal kimliğiyle talep ederek anahtarı ister.

Bunun üzerinde, aşağıdaki ad alanları tanımlanmıştır. Özel kuralların yerini alırlarsa, aşağıdaki tablo, karşılık gelen UID'yi gösterir.

Vektörlere Erişim

SELinux sınıfı keystore_key biraz eskidi ve verify veya sign gibi bazı izinler anlamlarını kaybetti. Keystore 2.0'ın uygulayacağı yeni izinler keystore2_key buradadır.

Ek olarak, SELinux güvenlik sınıfı keystore2 bir dizi anahtara özgü olmayan anahtar deposu izinlerini böldük: