Donanım Destekli Anahtar Deposu

Bir çip üzerinde sistemde (SoC) güvenilir bir yürütme ortamının bulunması, Android cihazların Android OS'e, platform hizmetlerine ve hatta üçüncü taraf uygulamalarına donanım destekli, güçlü güvenlik hizmetleri sunmasına olanak tanır. Android'e özgü uzantıları arayan geliştiriciler android.security.keystore'a gitmelidir.

Android 6.0'tan önce Android'de, 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'si zaten vardı. Anahtar deposu, dijital imzalama ve doğrulama işlemlerinin yanı sıra asimetrik imzalama anahtar çiftlerinin oluşturulması ve içe aktarılması için kullanılır. Bu özellik birçok cihazda zaten uygulanıyor olsa da yalnızca bir imza API'si ile kolayca ulaşılamayacak birçok güvenlik hedefi vardır. Android 6.0'taki Keystore, daha geniş bir özellik yelpazesi sunmak için Keystore API'yi genişletti.

Android 6.0'ta Keystore'a simetrik kriptografik primitifler, AES ve HMAC ile donanım destekli anahtarlar için bir erişim denetimi sistemi eklendi. Erişim denetimleri, anahtar oluşturma sırasında belirtilir ve anahtarın kullanım ömrü boyunca uygulanır. Anahtarlar, yalnızca kullanıcının kimliği doğrulandıktan sonra ve yalnızca belirtilen amaçlarla veya belirtilen kriptografik parametrelerle kullanılacak şekilde kısıtlanabilir. Daha fazla bilgi için Yetkilendirme etiketleri sayfasını inceleyin.

Android 6.0'taki Keystore, kriptografik temel öğelerin kapsamını genişletmenin yanı sıra aşağıdakileri de ekledi:

• Anahtarların kötüye kullanılması nedeniyle güvenlik ihlali riskini azaltmak için anahtar kullanımının sınırlandırılmasına izin veren bir kullanım denetimi şeması
• Anahtarları belirli kullanıcılar, istemciler ve tanımlanmış bir zaman aralığıyla kısıtlamayı etkinleştiren bir erişim denetimi şeması

Android 7.0'da Keymaster 2, anahtar doğrulaması ve sürüm bağlama desteği ekledi. Anahtar tasdiki, anahtarın güvenli donanımda varlığını ve yapılandırmasını uzaktan doğrulanabilir hale getirmek için anahtarın ve erişim denetimlerinin ayrıntılı bir açıklamasını içeren ortak anahtar sertifikaları sağlar.

Sürüm bağlama anahtarları işletim sistemine ve yama düzeyi sürümüne bağlar. Bu sayede, sistemin veya TEE yazılımının eski bir sürümünde zayıflık keşfeden bir saldırgan, cihazı zayıf sürüme geri döndürüp yeni sürümle oluşturulan anahtarları kullanamaz. Ayrıca, belirli bir sürüm ve yamalar düzeyine sahip bir anahtar, daha yeni bir sürüme veya yamalar düzeyine yükseltilmiş bir cihazda kullanıldığında anahtar, kullanılabilmesi için yükseltilir ve anahtarın önceki sürümü geçersiz kılınır. Cihaz yükseltilirken anahtarlar da cihazla birlikte "tırmanarak" ilerler. Ancak cihazın önceki bir sürüme geri döndürülmesi, anahtarların kullanılamamasına neden olur.

Android 8.0'da Keymaster 3, eski C yapısındaki 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çti. Değişiklik kapsamında, bağımsız değişken türlerinin çoğu değişti. Ancak türler ve yöntemler, eski türlerle ve HAL yapı yöntemleriyle bire bir ilişkilidir.

Android 8.0, bu arayüz düzeltmesine ek olarak Keymaster 2'nin doğrulama özelliğini kimlik doğrulamayı desteklemek için genişletti. Kimlik doğrulaması, cihaz seri numarası, ürün adı ve telefon kimliği (IMEI / MEID) gibi donanım tanımlayıcılarının güçlü bir şekilde doğrulanması için sınırlı ve isteğe bağlı bir mekanizma sağlar. Bu eklemeyi uygulamak için Android 8.0, kimlik doğrulamasını eklemek amacıyla ASN.1 doğrulama şemasını değiştirdi. Anahtar yöneticisi uygulamalarının, ilgili veri öğelerini almak için güvenli bir yol bulması ve özelliği güvenli ve kalıcı olarak devre dışı bırakmak için bir mekanizma tanımlaması gerekir.

Android 9'daki güncellemeler arasında şunlar yer alır:

• Keymaster 4'e güncelleme
• Yerleşik Secure Elements desteği
• Güvenli anahtar içe aktarma desteği
• 3DES şifrelemesi desteği
• Sürüm bağlama işleminde yapılan değişiklikler sayesinde boot.img ve system.img'in bağımsız güncellemelere izin vermek için ayrı ayrı ayarlanmış sürümleri var

Sözlük

Aşağıda, anahtar mağazası bileşenlerine ve aralarındaki ilişkilere kısa bir genel bakış verilmiştir.

AndroidKeystore, uygulamaların Keystore işlevine erişmek için kullandığı Android Framework API'si ve bileşenidir. Standart Java Şifreleme Mimarisi API'lerinin bir uzantısı olarak uygulanır ve uygulamanın kendi işlem alanında çalışan Java kodundan oluşur. AndroidKeystore, anahtar deposu davranışıyla ilgili uygulama isteklerini anahtar deposu hizmetine yönlendirerek yerine getirir.

Anahtar deposu hizmet programı, Binder API ile tüm Anahtar Deposu işlevlerine erişim sağlayan bir Android sistem hizmet programıdır. Gerçek gizli anahtar materyalini içeren "anahtar blob'larını" depolamaktan sorumludur. Bu blob'lar, Keystore'un depolayabilmesi ancak kullanamamasının veya göstermemesinin için şifrelenir.

keymasterd, Keymaster TA'ya erişim sağlayan bir HIDL sunucusudur. (Bu ad standart değildir ve kavramsal amaçlarla kullanılmaktadır.)

Keymaster TA (güvenilir uygulama), güvenli bir bağlamda (genellikle ARM SoC'teki TrustZone'da) çalışan, güvenli Keystore işlemlerinin tümünü sağlayan, ham anahtar materyaline erişimi olan, anahtarlardaki tüm erişim denetimi koşullarını doğrulayan vb. yazılımdır.

LockSettingsService, hem şifre hem de parmak izi olmak üzere kullanıcı kimlik doğrulamasından sorumlu Android sistem bileşenidir. Keystore'un bir parçası değildir ancak birçok Keystore anahtar işlemi kullanıcı kimlik doğrulaması gerektirdiği için alakalı bir konudur. LockSettingsService, kimlik doğrulama jetonları almak için Gatekeeper TA ve Fingerprint TA ile etkileşime geçer. Bu jetonlar, anahtar deposu hizmetine sağlanır ve nihayetinde Keymaster TA uygulaması tarafından tüketilir.

Gatekeeper TA (güvenilir uygulama), güvenli bağlamda çalışan başka bir bileşendir. Bu bileşen, kullanıcı şifrelerinin kimliğini doğrulamaktan ve Keymaster TA'ya belirli bir zamanda belirli bir kullanıcı için kimlik doğrulamanın yapıldığını kanıtlamak için kullanılan kimlik doğrulama jetonlarını oluşturmaktan sorumludur.

Parmak izi TA'sı (güvenilir uygulama), güvenli bağlamda çalışan ve kullanıcı parmak izlerinin kimliğini doğrulamaktan ve Keymaster TA'sına belirli bir zamanda belirli bir kullanıcı için kimlik doğrulamanın yapıldığını kanıtlamak için kullanılan kimlik doğrulama jetonlarını oluşturmaktan sorumlu olan başka bir bileşendir.

Mimari

Android Anahtar Deposu API'si ve temel Keymaster HAL, erişim denetimli, donanım destekli anahtarlar kullanılarak protokollerin uygulanmasına olanak tanıyan temel ancak yeterli bir kriptografik temel öğe grubu sağlar.

Keymaster HAL, donanım destekli kriptografik hizmetler sağlamak için Anahtar Deposu hizmeti tarafından kullanılan, OEM tarafından sağlanan, dinamik olarak yüklenebilir bir kitaplıktır. Güvenliği sağlamak için HAL uygulamaları, kullanıcı alanında veya hatta çekirdek alanında herhangi bir hassas işlem gerçekleştirmez. Hassas işlemler, bazı çekirdek arayüzü üzerinden erişilen güvenli bir işlemciye devredilir. Elde edilen mimari şu şekilde görünür:

Şekil 1. Keymaster'a erişim

Android cihazlarda Keymaster HAL'in "istemcisi" birden fazla katmandan (ör. uygulama, çerçeve, Keystore daemon) oluşur ancak bu belgenin amaçları doğrultusunda bu katmanlar yoksayılabilir. Bu, açıklanan Keymaster HAL API'sinin düşük düzeyde olduğu, platform içi bileşenler tarafından kullanıldığı ve uygulama geliştiricilere gösterilmediği anlamına gelir. Daha üst düzey API, Android Developers sitesinde açıklanmaktadır.

Keymaster HAL'in amacı, güvenlik açısından hassas algoritmaları uygulamak değil, yalnızca isteklerini güvenli dünyaya göndermek ve güvenli dünyadan almaktır. Kablo biçimi, uygulamaya göre tanımlanır.

Önceki sürümlerle uyumluluk

Keymaster 1 HAL, daha önce yayınlanan HAL'lerle (ör. Keymaster 0.2 ve 0.3) tamamen uyumlu değildir. Keystore, Android 5.0 ve önceki sürümleri çalıştıran ve eski Keymaster HAL'leri ile kullanıma sunulan cihazlarda birlikte çalışabilirliği kolaylaştırmak için mevcut donanım kitaplığına çağrılar göndererek Keymaster 1 HAL'i uygulayan bir adaptör sağlar. Sonuç, Keymaster 1 HAL'de tüm işlevleri sağlayamaz. Özellikle, yalnızca RSA ve ECDSA algoritmalarını destekler ve tüm anahtar yetkilendirme yaptırımı, güvenli olmayan dünyada bağdaştırıcının gerçekleştirdiği bir işlemdir.

Keymaster 2, get_supported_* yöntemlerini kaldırarak ve finish() yönteminin giriş kabul etmesine izin vererek HAL arayüzünü daha da basitleştirdi. Bu, girişin tek seferde kullanılabildiği durumlarda TEE'ye gidip gelme sayısını azaltır ve AEAD şifre çözme işleminin uygulanmasını kolaylaştırır.

Android 8.0'da Keymaster 3, eski stil C yapısı HAL'den yeni donanım arayüzü tanımlama dilinde (HIDL) bir tanımdan oluşturulan C++ HAL arayüzüne geçti. Oluşturulan IKeymasterDevice sınıfının alt sınıfı oluşturularak ve saf sanal yöntemler uygulanarak yeni tarz bir HAL uygulaması oluşturulur. Değişiklik kapsamında, bağımsız değişken türlerinin çoğu değişti. Bununla birlikte, türler ve yöntemler eski türlerle ve HAL yapı yöntemleriyle bire bir ilişkilidir.

HIDL'ye genel bakış

Donanım Arayüzü Tanımlama Dili (HIDL), donanım arayüzlerini belirtmek için dil bağımsız bir uygulama mekanizması sağlar. HIDL araçları şu anda C++ ve Java arayüzlerinin oluşturulmasını desteklemektedir. Çoğu Güvenilir Yürütme Ortamı (TEE) uygulayıcının C++ araçlarını daha kullanışlı bulmasını beklediğimiz için bu sayfada yalnızca C++ temsili ele alınmaktadır.

HIDL arayüzleri, aşağıdaki şekilde ifade edilen bir dizi yöntemden oluşur:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Çeşitli önceden tanımlanmış türler vardır ve HAL'ler yeni listelenmiş ve yapı türleri tanımlayabilir. HIDL hakkında daha fazla bilgi için Referans bölümüne bakın.

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

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

Bu, keymaster2 HAL'deki aşağıdakine 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, gizli olduğu için kaldırılır. params bağımsız değişkeni artık key_parameter_t nesne dizisine referans veren bir işaretçi içeren bir yapı değil, KeyParameter nesnesi içeren bir vec (vektör) bağımsız değişkenidir. Döndürülen değerler, anahtar blob'u için uint8_t değer vektörü de dahil olmak üzere "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;

Burada generateKey_cb, aşağıdaki ş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, generate yan tümcesinde listelenen döndürülen değerleri 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ğunu unutmayın. Arayan, generateKey işlevini çağırır ve generateKey, sağlanan işlev işaretçisini çağırır. Bu işlev işaretçisi, tamamlanana kadar yürütülür ve kontrolü generateKey uygulamasına, ardından arayana döndürür.

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

Erişim denetimi

Anahtar mağazası erişim denetiminin en temel kuralı, her uygulamanın kendi ad alanının olmasıdır. Ancak her kuralın bir istisnası vardır. Anahtar deposunda, belirli sistem bileşenlerinin belirli diğer ad alanlarında erişmesine izin veren bazı sabit kodlu haritalar bulunur. Bu, bir bileşene başka bir ad alanı üzerinde tam kontrol sağlaması açısından çok keskin bir araçtır. Ayrıca, Keystore'un istemcisi olarak tedarikçi firma bileşenleri de vardır. Şu anda tedarikçi bileşenleri (ör. WPA istemcisi) için bir ad alanı oluşturma imkanımız bulunmuyor.

Tedarikçi bileşenlerini barındırmak ve erişim denetimini sabit kodlu istisnalar olmadan genelleştirmek için Keystore 2.0, alanlar ve SELinux ad alanlarının kullanımını sunar.

Anahtar deposu alanları

Anahtar mağazası alan adlarıyla ad alanlarını UID'lerden ayırabiliriz. Anahtar mağazasındaki bir anahtara erişen istemcilerin erişmek istedikleri alanı, ad alanını ve takma adı belirtmesi gerekir. Bu tuple'i ve arayanın kimliğini temel alarak 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ş alan parametresi kullanıma sunuyoruz. Anahtar tanımlayıcısının ad alanı parametresinin anlamını ve erişim denetiminin nasıl yapıldığını kontrol ederler.

• DOMAIN_APP: Uygulama alanı, eski davranışı kapsar. Java Keystore SPI, varsayılan olarak bu alanı kullanır. Bu alan adı kullanıldığında ad alanı bağımsız değişkeni yok sayılır ve bunun yerine arayanın UID'si kullanılır. Bu alana erişim, SELinux politikasındaki keystore_key sınıfına ait Keystore etiketi tarafından kontrol edilir.
• DOMAIN_SELINUX: Bu alan, ad alanının SELinux politikasında bir etikete sahip olduğunu gösterir. Ad alanı parametresi aranıp hedef bir içeriğe dönüştürülür ve keystore_key sınıfı için çağıran SELinux içeriği için izin kontrolü yapılır. Belirtilen işlem için izin verildiğinde anahtar araması için tam tuple kullanılır.
• DOMAIN_GRANT: Grant alanı, ad alanı parametresinin bir grant tanımlayıcısı olduğunu belirtir. Takma ad parametresi yoksayılır. SELinux kontrolleri, izin oluşturulduğunda gerçekleştirilir. Daha ayrıntılı erişim denetimi yalnızca arayan UID'sinin, istenen bağışın bağış alan UID'siyle eşleşip eşleşmediğini kontrol eder.
• DOMAIN_KEY_ID: Bu alan, ad alanı parametresinin benzersiz bir anahtar kimliği olduğunu belirtir. Anahtar, DOMAIN_APP veya DOMAIN_SELINUX ile oluşturulmuş olabilir. İzin kontrolü, domain ve namespace anahtar veritabanından yüklendikten sonra, blob alan, ad alanı ve takma ad tuple'i tarafından yüklenmiş gibi yapılır. Anahtar kimliği alanının nedeni sürekliliktir. Bir anahtara takma ada göre erişirken yeni bir anahtar oluşturulmuş veya içe aktarılıp bu takmaya bağlanmış olabileceğinden, sonraki çağrılar farklı anahtarlarda çalışabilir. Ancak anahtar kimliği hiçbir zaman değişmez. Bu nedenle, bir anahtar, Keystore veritabanından takma ad kullanılarak bir kez yüklendikten sonra anahtar kimliğine göre kullanıldığında, anahtar kimliği hâlâ mevcut olduğu sürece aynı anahtar olduğundan emin olabilirsiniz. Bu işlev, uygulama geliştiricilere gösterilmez. Bunun yerine, güvenli olmayan bir şekilde eşzamanlı olarak kullanıldığında bile daha tutarlı bir deneyim sunmak için Android Keystore SPI'de kullanılır.
• DOMAIN_BLOB: Blob alanı, arayanın blob'u kendi başına yönettiğini belirtir. Bu, veri bölümü monte edilmeden önce Keystore'a erişmesi gereken istemciler için kullanılır. Anahtar blob'u, anahtar tanımlayıcısının blob alanına dahil edilir.

SELinux alanını kullanarak tedarikçi bileşenlerine, ayarlar iletişim kutusu gibi sistem bileşenleri tarafından paylaşılabilen çok özel anahtar mağazası ad alanlarında erişim verebiliriz.

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 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, uygun bir politika ekleyerek bu alana erişim verebiliriz. Örneğin, wpa_supplicant'ün yeni ad alanında anahtar almasına ve kullanmasına izin vermek için hal_wifi_supplicant.te'e aşağıdaki satırı ekleriz:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Yeni ad alanı oluşturulduktan sonra AndroidKeyStore neredeyse her zamanki gibi kullanılabilir. Tek fark, ad alanı kimliğinin belirtilmesi gerektiğidir. Anahtar Deposu'na anahtar yüklemek ve Anahtar Deposu'ndan anahtar içe 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 anahtar oluşturmak için ad alanı kimliği KeyGenParameterSpec.Builder#setNamespace(): kullanılarak belirtilmelidir.

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

Aşağıdaki bağlam dosyaları, Keystore 2.0 SELinux ad alanlarının yapılandırılması için kullanılabilir. Çakışmaları önlemek için her bölümde 10.000 ad alanı kimliği için farklı bir ayrılmış aralık bulunur.

/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ı (bu durumda "wifi_key") sayısal kimliğiyle isteyerek anahtarı ister.

Bununla birlikte, aşağıdaki ad alanları da tanımlanmıştır. Özel kuralların yerini alıyorlarsa aşağıdaki tabloda, karşılık verdikleri UID gösterilir.

Erişim vektörleri

SELinux sınıfı keystore_key oldukça eskidir ve verify veya sign gibi bazı izinler anlamını yitirmiştir. Anahtar Deposu 2.0'un zorunlu kıldığı yeni izin grubu keystore2_key aşağıda verilmiştir.

Ayrıca, SELinux güvenlik sınıfında keystore2 anahtara özgü olmayan bir dizi anahtar mağazası iznini ayırdık: