Anahtar deposu, kriptografik anahtarları kontrollü bir şekilde oluşturmak, depolamak ve kullanmak için daha güvenli bir yer sağlar. Donanım destekli anahtar depolama mevcut olduğunda ve kullanıldığında, anahtar materyali cihazdan çıkarılmaya karşı daha güvenlidir ve Keymaster, yıkılması zor kısıtlamalar uygular.
Ancak bu, yalnızca anahtar deposu anahtarlarının donanım destekli depolamada olduğu biliniyorsa geçerlidir. Keymaster 1'de, uygulamaların veya uzak sunucuların durumun böyle olup olmadığını güvenilir bir şekilde doğrulamasının bir yolu yoktu. Anahtar deposu arka plan programı, mevcut anahtar yöneticisi HAL'ı yükledi ve anahtarların donanım desteğiyle ilgili olarak HAL'ın söylediği her şeye inandı.
Bunu düzeltmek için Keymaster, Android 7.0'da (Keymaster 2)anahtar doğrulamasını ve Android 8.0'da (Keymaster 3) kimlik doğrulamasını tanıttı.
Anahtar doğrulama, asimetrik bir anahtar çiftinin donanım destekli olup olmadığını, anahtarın özelliklerinin neler olduğunu ve kullanımına hangi kısıtlamaların uygulandığını güçlü bir şekilde belirlemenin bir yolunu sağlamayı amaçlar.
Kimlik onayı, cihazın seri numarası veya IMEI gibi donanım tanımlayıcılarının kanıtını sağlamasına olanak tanır.
Anahtar tasdik
Anahtar doğrulamasını desteklemek için Android 7.1, HAL'a bir dizi etiket, tür ve yöntem getirdi.
Etiketler
-
Tag::ATTESTATION_CHALLENGE
-
Tag::INCLUDE_UNIQUE_ID
-
Tag::RESET_SINCE_ID_ROTATION
Tip
Keymaster 2 ve altı
typedef struct { keymaster_blob_t* entries; size_t entry_count; } keymaster_cert_chain_t;
AttestKey
yöntemi
Keymaster 3
attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams) generates(ErrorCode error, vec<vec<uint8_t>> certChain);
Keymaster 2 ve altı
keymaster_error_t (*attest_key)(const struct keymaster2_device* dev, const keymaster_key_blob_t* key_to_attest, const keymaster_key_param_set_t* attest_params, keymaster_cert_chain_t* cert_chain);
-
dev
keymaster cihaz yapısıdır. -
keyToAttest
, kendisi için tasdikin oluşturulacağıgenerateKey
döndürülen anahtar bloğudur. -
attestParams
tasdik için gerekli tüm parametrelerin bir listesidir. BunaTag::ATTESTATION_CHALLENGE
ve muhtemelenTag::RESET_SINCE_ID_ROTATION
ve ayrıcaTag::APPLICATION_ID
veTag::APPLICATION_DATA
dahildir. Son ikisi, anahtar oluşturma sırasında belirtilmişlerse, anahtar bloğunun şifresini çözmek için gereklidir. -
certChain
, bir sertifika dizisi döndüren çıktı parametresidir. Giriş 0, tasdik sertifikasıdır, yanikeyToAttest
gelen anahtarı onaylar ve tasdik uzantısını içerir.
attestKey
yöntemi, herhangi bir zamanda çağrılabileceğinden ve yetkilendirme kısıtlamalarını karşılaması gerekmediğinden, onaylanmış anahtar üzerinde bir ortak anahtar işlemi olarak kabul edilir. Örneğin, tasdik edilen anahtarın kullanım için kullanıcı kimlik doğrulamasına ihtiyacı varsa, kullanıcı kimlik doğrulaması olmadan bir tasdik oluşturulabilir.
tasdik sertifikası
Tasdik sertifikası, tasdik edilen anahtarın açıklamasını içeren isteğe bağlı bir tasdik uzantısına sahip standart bir X.509 sertifikasıdır. Sertifika, onaylı bir tasdik anahtarıyla imzalanır. Tasdik anahtarı, tasdik edilen anahtardan farklı bir algoritma kullanabilir.
Tasdik sertifikası aşağıdaki tablodaki alanları içerir ve herhangi bir ek alan içeremez. Bazı alanlar sabit bir alan değeri belirtir. CTS testleri, sertifika içeriğinin tam olarak tanımlandığı gibi olduğunu doğrular.
Sertifika SIRASI
Alan adı (bkz. RFC 5280 ) | Değer |
---|---|
tbsSertifikası | TBSCertificate SEQUENCE |
imzaAlgoritma | Anahtarı imzalamak için kullanılan algoritmanın AlgorithmIdentifier'ı: EC anahtarları için ECDSA, RSA anahtarları için RSA. |
imzaDeğeri | BIT DİZGİSİ, ASN.1 DER kodlu tbsCertificate üzerinde hesaplanan imza. |
TBSCertificate SEQUENCE
Alan adı (bkz. RFC 5280 ) | Değer |
---|---|
version | INTEGER 2 (v3 sertifikası anlamına gelir) |
serialNumber | INTEGER 1 (sabit değer: tüm sertifikalarda aynı) |
signature | Anahtarı imzalamak için kullanılan algoritmanın AlgorithmIdentifier'ı: EC anahtarları için ECDSA, RSA anahtarları için RSA. |
issuer | Toplu tasdik anahtarının konu alanıyla aynıdır. |
validity | Tag::ACTIVE_DATETIME ve Tag::USAGE_EXPIRE_DATETIME değerlerini içeren iki tarihin DİZİSİ. Bu değerler, 1 Ocak 1970'ten bu yana milisaniye cinsindendir. Sertifikalardaki doğru tarih gösterimleri için RFC 5280'e bakın.Tag::ACTIVE_DATETIME mevcut değilse, Tag::CREATION_DATETIME değerini kullanın. Tag::USAGE_EXPIRE_DATETIME mevcut değilse, toplu tasdik anahtarı sertifikasının sona erme tarihini kullanın. |
subject | CN = "Android Anahtar Deposu Anahtarı" (sabit değer: tüm sertifikalarda aynı) |
subjectPublicKeyInfo | Onaylanmış genel anahtarı içeren SubjectPublicKeyInfo. |
extensions/Key Usage | digitalSignature: anahtarın KeyPurpose::SIGN veya KeyPurpose::VERIFY amacı varsa ayarlayın. Diğer tüm bitler ayarlanmadı. |
extensions/CRL Distribution Points | değer belirsizliği |
extensions/"attestation" | OID, 1.3.6.1.4.1.11129.2.1.17'dir; içerik aşağıdaki Tasdik Uzantısı bölümünde tanımlanmıştır. Tüm X.509 sertifika uzantılarında olduğu gibi içerik, SEQUENCE doğrulamasının DER kodlamasını içeren bir OCTET_STRING olarak temsil edilir. |
Tasdik uzantısı
attestation
uzantısı, Android ve keymaster HAL'de kullanılan yetkilendirme listelerine doğrudan karşılık gelen bir yapıda, anahtarla ilişkili keymaster yetkilerinin eksiksiz bir açıklamasını içerir. Yetkilendirme listesindeki her etiket, keymaster etiket numarasıyla açıkça etiketlenmiş, ancak tip tanımlayıcı (dört yüksek sıralı bit) maskelenmiş bir ASN.1 SEQUENCE
girişi ile temsil edilir.
Örneğin, Keymaster 3'te Tag::PURPOSE
type.hal'de ENUM_REP | 1
. Tasdik uzantısı için ENUM_REP
değeri kaldırılır ve geriye etiket 1
kalır. (Keymaster 2 ve altı için KM_TAG_PURPOSE
, keymaster_defs.h'de tanımlanmıştır.)
Değerler, bu tabloya göre basit bir şekilde ASN.1 türlerine çevrilir:
Keymaster tipi | ASN.1 tipi |
---|---|
ENUM | TAM SAYI |
ENUM_REP | TAM SAYI |
UINT | TAM SAYI |
UINT_REP | TAM SAYI |
ULONG | TAM SAYI |
ULONG_REP | TAM SAYI |
DATE | INTEGER (1 Ocak 1970 00:00:00 GMT'den bu yana milisaniye) |
BOOL | NULL (keymaster'da, etiket mevcut, doğru, yok, yanlış anlamına gelir. Aynı semantik ASN.1 kodlaması için geçerlidir) |
BIGNUM | Şu anda kullanılmamaktadır, bu nedenle eşleme tanımlanmamıştır |
BYTES | OCTET_STRING |
Şema
Tasdik uzantısı içeriği, aşağıdaki ASN.1 şemasıyla açıklanmaktadır.
KeyDescription ::= SEQUENCE { attestationVersion INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3. attestationSecurityLevel SecurityLevel, keymasterVersion INTEGER, keymasterSecurityLevel SecurityLevel, attestationChallenge OCTET_STRING, uniqueId OCTET_STRING, softwareEnforced AuthorizationList, teeEnforced AuthorizationList, } SecurityLevel ::= ENUMERATED { Software (0), TrustedEnvironment (1), StrongBox (2), } AuthorizationList ::= SEQUENCE { purpose [1] EXPLICIT SET OF INTEGER OPTIONAL, algorithm [2] EXPLICIT INTEGER OPTIONAL, keySize [3] EXPLICIT INTEGER OPTIONAL. digest [5] EXPLICIT SET OF INTEGER OPTIONAL, padding [6] EXPLICIT SET OF INTEGER OPTIONAL, ecCurve [10] EXPLICIT INTEGER OPTIONAL, rsaPublicExponent [200] EXPLICIT INTEGER OPTIONAL, rollbackResistance [303] EXPLICIT NULL OPTIONAL, # KM4 activeDateTime [400] EXPLICIT INTEGER OPTIONAL originationExpireDateTime [401] EXPLICIT INTEGER OPTIONAL usageExpireDateTime [402] EXPLICIT INTEGER OPTIONAL noAuthRequired [503] EXPLICIT NULL OPTIONAL, userAuthType [504] EXPLICIT INTEGER OPTIONAL, authTimeout [505] EXPLICIT INTEGER OPTIONAL, allowWhileOnBody [506] EXPLICIT NULL OPTIONAL, trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4 trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4 unlockedDeviceRequired [509] EXPLICIT NULL OPTIONAL, # KM4 allApplications [600] EXPLICIT NULL OPTIONAL, applicationId [601] EXPLICIT OCTET_STRING OPTIONAL, creationDateTime [701] EXPLICIT INTEGER OPTIONAL, origin [702] EXPLICIT INTEGER OPTIONAL, rollbackResistant [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only. rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, osVersion [705] EXPLICIT INTEGER OPTIONAL, osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdBrand [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdDevice [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdProduct [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdSerial [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdImei [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdMeid [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdManufacturer [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdModel [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3 vendorPatchLevel [718] EXPLICIT INTEGER OPTIONAL, # KM4 bootPatchLevel [719] EXPLICIT INTEGER OPTIONAL, # KM4 } RootOfTrust ::= SEQUENCE { verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN, verifiedBootState VerifiedBootState, verifiedBootHash OCTET_STRING, # KM4 } VerifiedBootState ::= ENUMERATED { Verified (0), SelfSigned (1), Unverified (2), Failed (3), }
KeyDescription alanları
keymasterVersion
ve attestationChallenge
alanları, etiket yerine konumsal olarak tanımlanır, bu nedenle kodlanmış formdaki etiketler yalnızca alan türünü belirtir. Kalan alanlar, şemada belirtildiği gibi dolaylı olarak etiketlenir.
Alan adı | Tip | Değer |
---|---|---|
attestationVersion | TAM SAYI | Tasdik şemasının sürümü: 1, 2 veya 3. |
attestationSecurity | Güvenlik seviyesi | Bu tasdik güvenlik düzeyi. Donanım destekli anahtarların yazılım onaylarını almak mümkündür. Android sisteminin güvenliği ihlal edilmişse bu tür tasdiklere güvenilemez. |
keymasterVersion | TAM SAYI | Keymaster cihazının sürümü: 0, 1, 2, 3 veya 4. |
keymasterSecurity | Güvenlik seviyesi | Anahtar yöneticisi uygulamasının güvenlik düzeyi. |
attestationChallenge | OCTET_STRING | Tasdik isteğinde belirtilen Tag::ATTESTATION_CHALLENGE değeri. |
uniqueId | OCTET_STRING | İsteğe bağlı benzersiz kimlik, anahtarda Tag::INCLUDE_UNIQUE_ID varsa mevcut |
softwareEnforced | Yetki Listesi | Varsa, TEE tarafından zorunlu kılınmayan isteğe bağlı keymaster yetkileri. |
teeEnforced | Yetki Listesi | Varsa, TEE tarafından uygulanan isteğe bağlı, Keymaster yetkilendirmeleri. |
Yetkilendirme Listesi alanları
AuthorizationList
alanlarının tümü isteğe bağlıdır ve tür bitleri maskelenerek keymaster etiketi değeriyle tanımlanır. Açık etiketleme kullanılır, böylece alanlar ayrıca daha kolay ayrıştırma için ASN.1 türlerini belirten bir etiket içerir.
Her alanın değerleri hakkında ayrıntılar için, Keymaster 3 için types.hal
ve Keymaster 2 için keymaster_defs.h
ve aşağısına bakın. Keymaster etiket adları, KM_TAG
ön eki atlanarak ve geri kalanı büyük/küçük harf olarak değiştirilerek alan adlarına dönüştürüldü, böylece Tag::KEY_SIZE
keySize
oldu.
RootOfTrust alanları
RootOfTrust
Alanları konumsal olarak tanımlanır.
Alan adı | Tip | Değer |
---|---|---|
verifiedBootKey | OCTET_STRING | Sistem görüntüsünü doğrulamak için kullanılan anahtarın güvenli bir karması. SHA-256 önerilir. |
deviceLocked | BOOLE | Önyükleyici kilitliyse doğrudur; bu, yalnızca imzalı görüntülerin yanıp sönebileceği ve doğrulanmış önyükleme kontrolünün yapıldığı anlamına gelir. |
verifiedBootState | Doğrulanmış Önyükleme Durumu | Doğrulanmış önyükleme durumu. |
verifiedBootHash | OCTET_STRING | Verified Boot tarafından korunan tüm verilerin özeti. Verified Boot'un Android Verified Boot uygulamasını kullanan cihazlar için bu değer, VBMeta struct veya Verified Boot meta veri yapısının özetini içerir. Bu değerin nasıl hesaplanacağı hakkında daha fazla bilgi edinmek için bkz. VBMeta Digest |
VerifiedBootState değerleri
verifiedBootState
değerleri aşağıdaki anlamlara sahiptir:
Değer | Anlam |
---|---|
Verified | Önyükleyiciden, önyükleyici, önyükleme bölümü ve tüm doğrulanmış bölümler dahil olmak üzere doğrulanmış bölümlere uzanan tam bir güven zincirini gösterir. Bu durumda, verifiedBootKey değeri katıştırılmış sertifikanın karmasıdır, yani ROM'a yazılan değiştirilemez sertifikadır.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi yeşil önyükleme durumuna karşılık gelir. |
SelfSigned | Önyükleme bölümünün katıştırılmış sertifika kullanılarak doğrulandığını ve imzanın geçerli olduğunu gösterir. Önyükleyici, önyükleme işleminin devam etmesine izin vermeden önce bir uyarı ve genel anahtarın parmak izini görüntüler. Bu durumda, verifiedBootKey değeri, kendi kendini imzalayan sertifikanın karmasıdır.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi sarı önyükleme durumuna karşılık gelir. |
Unverified | Bir cihazın serbestçe değiştirilebileceğini gösterir. Bant dışı doğrulamak için cihaz bütünlüğü kullanıcıya bırakılmıştır. Önyükleyici, önyükleme işleminin devam etmesine izin vermeden önce kullanıcıya bir uyarı görüntüler. Bu durumda verifiedBootKey değeri boştur.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi turuncu önyükleme durumuna karşılık gelir. |
Failed | Cihazın doğrulamada başarısız olduğunu gösterir. Hiçbir tasdik sertifikası bu değeri içermez, çünkü bu durumda önyükleyici durur. Bütünlük için buraya dahil edilmiştir. Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi kırmızı önyükleme durumuna karşılık gelir. |
Güvenlik Düzeyi değerleri
securityLevel
değerleri aşağıdaki anlamlara sahiptir:
Değer | Anlam |
---|---|
Software | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, Android sisteminde uygulanır ve bu sistemin güvenliği ihlal edilirse değiştirilebilir. |
TrustedEnvironment | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, Güvenilir Yürütme Ortamında (TEE) uygulanır. TEE'nin güvenliği ihlal edilirse değiştirilebilir, ancak TEE uzaktan güvenlik ihlaline karşı oldukça dirençlidir ve doğrudan donanım saldırısı yoluyla güvenlik ihlaline karşı orta düzeyde dirençlidir. |
StrongBox | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, özel bir donanım güvenlik modülünde uygulanır. Donanım güvenlik modülünün güvenliği ihlal edildiğinde değiştirilebilir, ancak uzaktan güvenlik ihlaline karşı oldukça dirençlidir ve doğrudan donanım saldırısı yoluyla güvenlik ihlaline karşı oldukça dirençlidir. |
benzersiz kimlik
Benzersiz Kimlik, cihazı yalnızca sınırlı bir süre için tanımlayan 128 bitlik bir değerdir. Değer şu şekilde hesaplanır:
HMAC_SHA256(T || C || R, HBK)
Nerede:
-
T
,Tag::CREATION_DATETIME
değerinin 2592000000'e bölünmesi ve kalanın çıkarılmasıyla hesaplanan "geçici sayaç değeri"dir.T
her 30 günde bir değişir (2592000000 = 30 * 24 * 60 * 60 * 1000). -
C
Tag::APPLICATION_ID
değeridir -
R
, attest_key çağrısının attest_params parametresindeTag::RESET_SINCE_ID_ROTATION
varsa 1 veya etiket yoksa 0'dır. -
HBK
, Güvenilir Yürütme Ortamı tarafından bilinen ve asla ifşa edilmeyen, donanıma bağlı benzersiz bir sırdır. Sır, en az 128 bit entropi içerir ve bireysel cihaza özgüdür (128 bit entropi verildiğinde olasılıksal benzersizlik kabul edilebilir). HBK, HMAC veya AES_CMAC yoluyla birleştirilmiş anahtar malzemeden türetilmelidir.
HMAC_SHA256 çıkışını 128 bit olarak kısaltın.
Tasdik anahtarları ve sertifikaları
Bir RSA ve bir ECDSA olmak üzere iki anahtar ve karşılık gelen sertifika zincirleri, cihaza güvenli bir şekilde sağlanır.
Android 12, Uzaktan Anahtar Sağlama özelliğini sunar ve Android 13, cihazların bunu uygulamasını gerektirir. Remote Key Provisioning, sahadaki cihazlara uygulama başına ECDSA P256 tasdik sertifikaları sağlar. Bu sertifikalar, fabrika tarafından sağlanan sertifikalardan daha kısa ömürlüdür.
kimlik tasdik
Android 8.0, Keymaster 3'e sahip cihazlar için isteğe bağlı kimlik doğrulama desteği içerir. Kimlik doğrulama, cihazın seri numarası veya IMEI gibi donanım tanımlayıcılarının kanıtını sağlamasına olanak tanır. İsteğe bağlı bir özellik olmasına rağmen, tüm Keymaster 3 uygulamalarının bunu desteklemesi önemle tavsiye edilir çünkü cihazın kimliğini kanıtlayabilmek, gerçek sıfır dokunmalı uzaktan yapılandırma gibi kullanım durumlarının daha güvenli olmasını sağlar (çünkü uzak taraf emin olabilir) kimliğini taklit eden bir cihazla değil, doğru cihazla konuşuyor).
Kimlik doğrulaması, cihazın donanım tanımlayıcılarının, cihaz fabrikadan çıkmadan önce yalnızca Güvenilir Yürütme Ortamının (TEE) erişebileceği kopyalarını oluşturarak çalışır. Bir kullanıcı, cihazın önyükleyicisinin kilidini açabilir ve sistem yazılımını ve Android çerçeveleri tarafından bildirilen tanımlayıcıları değiştirebilir. TEE tarafından tutulan tanımlayıcıların kopyaları bu şekilde manipüle edilemez; bu, cihaz kimliği tasdikinin yalnızca cihazın orijinal donanım tanımlayıcılarını doğrulamasını sağlayarak sahtekarlık girişimlerini engeller.
Kimlik tasdiki için ana API yüzeyi, Keymaster 2 ile sunulan mevcut anahtar tasdik mekanizmasının üzerine kuruludur. Keymaster tarafından tutulan bir anahtar için tasdik sertifikası talep edilirken, arayan kişi cihazın donanım tanımlayıcılarının tasdik sertifikasının meta verilerine dahil edilmesini isteyebilir. Anahtar TEE'de tutulursa, sertifika bilinen bir güven köküne zincirlenir. Böyle bir sertifikanın alıcısı, donanım tanımlayıcıları da dahil olmak üzere sertifikanın ve içeriğinin TEE tarafından yazıldığını doğrulayabilir. Tasdik sertifikasına donanım tanımlayıcılarını dahil etmesi istendiğinde, TEE yalnızca deposunda tutulan, fabrika zemininde doldurulan tanımlayıcıları onaylar.
Depolama özellikleri
Cihazın tanımlayıcılarını tutan depolamanın şu özelliklere sahip olması gerekir:
- Cihazın orijinal tanımlayıcılarından türetilen değerler, cihaz fabrikadan çıkmadan önce depolamaya kopyalanır.
-
destroyAttestationIds()
yöntemi, tanımlayıcıdan türetilen verilerin bu kopyasını kalıcı olarak yok edebilir. Kalıcı imha, verilerin tamamen kaldırılması anlamına gelir, böylece ne fabrika ayarlarına sıfırlama ne de cihazda gerçekleştirilen başka herhangi bir prosedür verileri geri yükleyemez. Bu, özellikle bir kullanıcının önyükleyicinin kilidini açtığı ve sistem yazılımını değiştirdiği ve Android çerçeveleri tarafından döndürülen tanımlayıcıları değiştirdiği cihazlar için önemlidir. - RMA tesisleri, donanım tanımlayıcıdan türetilmiş verilerin yeni kopyalarını oluşturma yeteneğine sahip olmalıdır. Bu sayede RMA'dan geçen bir cihaz yeniden ID tasdiki gerçekleştirebilir. RMA tesisleri tarafından kullanılan mekanizma, sahte kimliklerin onaylarını almalarına izin vereceğinden, kullanıcıların kendileri başlatamayacakları şekilde korunmalıdır.
- TEE'deki Keymaster güvenilir uygulaması dışında hiçbir kod, depoda tutulan tanımlayıcıdan türetilmiş verileri okuyamaz.
- Depolama kurcalamaya karşı korumalıdır: Depolamanın içeriği değiştirilmişse, TEE ona içeriğin kopyaları yok edilmiş gibi davranır ve tüm kimlik doğrulama girişimlerini reddeder. Bu, depolamayı aşağıda açıklandığı gibi imzalayarak veya MAC yaparak uygulanır.
- Depolama, orijinal tanımlayıcıları tutmaz. Kimlik tasdiki bir meydan okuma içerdiğinden, arayan kişi her zaman tasdik edilecek tanımlayıcıları sağlar. TEE'nin yalnızca bunların başlangıçta sahip oldukları değerlerle eşleştiğini doğrulaması gerekir. Değerler yerine orijinal değerlerin güvenli karmalarının saklanması bu doğrulamayı sağlar.
Yapı
Yukarıda listelenen özelliklere sahip bir uygulama oluşturmak için, kimlikten türetilen değerleri aşağıdaki yapı S'de saklayın. Bir cihaz sahibinin kökleme yoluyla değiştirebileceği sistemdeki normal yerler dışında, kimlik değerlerinin diğer kopyalarını saklamayın:
S = D || HMAC(HBK, D)
Neresi:
-
D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
-
HMAC
uygun bir güvenli karmaya sahip HMAC yapısıdır (SHA-256 önerilir) -
HBK
başka herhangi bir amaç için kullanılmayan, donanıma bağlı bir anahtardır. -
ID 1 ...ID n
orijinal ID değerleridir; Belirli bir değerin belirli bir dizinle ilişkilendirilmesi uygulamaya bağlıdır, çünkü farklı cihazlar farklı sayıda tanımlayıcıya sahip olacaktır. -
||
birleştirme temsil eder
HMAC çıktıları sabit boyutta olduğundan, bireysel kimlik karmalarını veya D'nin HMAC'sini bulabilmek için herhangi bir başlık veya başka bir yapı gerekmez. Tasdik gerçekleştirmek için sağlanan değerleri kontrol etmenin yanı sıra, uygulamaların D'yi S'den çıkararak S'yi doğrulaması gerekir. , HMAC(HBK, D)'yi hesaplıyor ve hiçbir bireysel kimliğin değiştirilmediğini/bozulmadığını doğrulamak için bunu S'deki değerle karşılaştırıyor. Ayrıca uygulamalar, tüm bağımsız kimlik öğeleri ve S'nin doğrulanması için sabit zamanlı karşılaştırmalar kullanmalıdır. Karşılaştırma süresi, sağlanan kimlik sayısına ve testin herhangi bir bölümünün doğru eşleşmesine bakılmaksızın sabit olmalıdır.
Donanım tanımlayıcıları
Kimlik doğrulaması, aşağıdaki donanım tanımlayıcılarını destekler:
- Android'de
Build.BRAND
tarafından döndürülen marka adı - Android'de
Build.DEVICE
tarafından döndürülen cihaz adı - Android'de
Build.PRODUCT
tarafından döndürülen ürün adı - Android'de
Build.MANUFACTURER
tarafından döndürülen üretici adı - Android'de
Build.MODEL
tarafından döndürülen model adı - Seri numarası
- Tüm telsizlerin IMEI'leri
- Tüm radyoların MEID'leri
Cihaz kimliği tasdikini desteklemek için bir cihaz bu tanımlayıcıları onaylar. Android çalıştıran tüm cihazlarda ilk altısı vardır ve bu özelliğin çalışması için gereklidirler. Cihazda tümleşik hücresel telsiz varsa, cihazın ayrıca telsizlerin IMEI'leri ve/veya MEID'leri için tasdiki desteklemesi gerekir.
Kimlik doğrulaması, bir anahtar doğrulaması gerçekleştirilerek ve talepte onaylanacak cihaz tanımlayıcıları dahil edilerek talep edilir. Tanımlayıcılar şu şekilde etiketlenir:
-
ATTESTATION_ID_BRAND
-
ATTESTATION_ID_DEVICE
-
ATTESTATION_ID_PRODUCT
-
ATTESTATION_ID_MANUFACTURER
-
ATTESTATION_ID_MODEL
-
ATTESTATION_ID_SERIAL
-
ATTESTATION_ID_IMEI
-
ATTESTATION_ID_MEID
Kanıtlanacak tanımlayıcı, UTF-8 kodlu bir bayt dizisidir. Bu biçim sayısal tanımlayıcılar için de geçerlidir. Onaylanacak her tanımlayıcı, UTF-8 kodlu bir dize olarak ifade edilir.
Cihaz kimlik doğrulamasını desteklemiyorsa (veya daha önce destroyAttestationIds()
çağrılmışsa ve cihaz artık kimliklerini doğrulayamıyorsa), bu etiketlerden birini veya daha fazlasını içeren herhangi bir anahtar doğrulama isteği ErrorCode::CANNOT_ATTEST_IDS
ile başarısız olur.
Cihaz, kimlik tasdikini destekliyorsa ve yukarıdaki etiketlerden biri veya daha fazlası bir anahtar tasdik talebine dahil edilmişse, TEE, etiketlerin her biriyle sağlanan tanımlayıcının, donanım tanımlayıcılarının kopyasıyla eşleştiğini doğrular. Bir veya daha fazla tanımlayıcı eşleşmezse, tüm doğrulama ErrorCode::CANNOT_ATTEST_IDS
ile başarısız olur. Aynı etiketin birden fazla verilmesi için geçerlidir. Bu, örneğin IMEI'leri onaylarken yararlı olabilir: Bir cihazda birden çok IMEI'ye sahip birden çok telsiz olabilir. Her ATTESTATION_ID_IMEI
ile sağlanan değer, cihazın telsizlerinden biriyle eşleşirse bir tasdik talebi geçerlidir. Aynısı diğer tüm etiketler için de geçerlidir.
Tasdik başarılı olursa, yukarıdaki şema kullanılarak, tasdikli kimlikler verilen tasdik sertifikasının tasdik uzantısına (OID 1.3.6.1.4.1.11129.2.1.17) eklenir. Keymaster 2 tasdik şemasındaki değişiklikler, yorumlarla birlikte kalın harflerle yazılmıştır.
Java API'sı
Bu bölüm yalnızca bilgilendirme amaçlıdır. Keymaster uygulayıcıları, Java API'yi ne uygular ne de kullanır. Bu, uygulayıcıların özelliğin uygulamalar tarafından nasıl kullanıldığını anlamalarına yardımcı olmak için sağlanmıştır. Sistem bileşenleri bunu farklı şekilde kullanabilir, bu nedenle bu bölümün normatif olarak değerlendirilmemesi çok önemlidir.
,Anahtar deposu, kriptografik anahtarları kontrollü bir şekilde oluşturmak, depolamak ve kullanmak için daha güvenli bir yer sağlar. Donanım destekli anahtar depolama mevcut olduğunda ve kullanıldığında, anahtar materyali cihazdan çıkarılmaya karşı daha güvenlidir ve Keymaster, yıkılması zor kısıtlamalar uygular.
Ancak bu, yalnızca anahtar deposu anahtarlarının donanım destekli depolamada olduğu biliniyorsa geçerlidir. Keymaster 1'de, uygulamaların veya uzak sunucuların durumun böyle olup olmadığını güvenilir bir şekilde doğrulamasının bir yolu yoktu. Anahtar deposu arka plan programı, mevcut anahtar yöneticisi HAL'ı yükledi ve anahtarların donanım desteğiyle ilgili olarak HAL'ın söylediği her şeye inandı.
Bunu düzeltmek için Keymaster, Android 7.0'da (Keymaster 2)anahtar doğrulamasını ve Android 8.0'da (Keymaster 3) kimlik doğrulamasını tanıttı.
Anahtar doğrulama, asimetrik bir anahtar çiftinin donanım destekli olup olmadığını, anahtarın özelliklerinin neler olduğunu ve kullanımına hangi kısıtlamaların uygulandığını güçlü bir şekilde belirlemenin bir yolunu sağlamayı amaçlar.
Kimlik onayı, cihazın seri numarası veya IMEI gibi donanım tanımlayıcılarının kanıtını sağlamasına olanak tanır.
Anahtar tasdik
Anahtar doğrulamasını desteklemek için Android 7.1, HAL'a bir dizi etiket, tür ve yöntem getirdi.
Etiketler
-
Tag::ATTESTATION_CHALLENGE
-
Tag::INCLUDE_UNIQUE_ID
-
Tag::RESET_SINCE_ID_ROTATION
Tip
Keymaster 2 ve altı
typedef struct { keymaster_blob_t* entries; size_t entry_count; } keymaster_cert_chain_t;
AttestKey
yöntemi
Keymaster 3
attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams) generates(ErrorCode error, vec<vec<uint8_t>> certChain);
Keymaster 2 ve altı
keymaster_error_t (*attest_key)(const struct keymaster2_device* dev, const keymaster_key_blob_t* key_to_attest, const keymaster_key_param_set_t* attest_params, keymaster_cert_chain_t* cert_chain);
-
dev
keymaster cihaz yapısıdır. -
keyToAttest
, kendisi için tasdikin oluşturulacağıgenerateKey
döndürülen anahtar bloğudur. -
attestParams
tasdik için gerekli tüm parametrelerin bir listesidir. BunaTag::ATTESTATION_CHALLENGE
ve muhtemelenTag::RESET_SINCE_ID_ROTATION
ve ayrıcaTag::APPLICATION_ID
veTag::APPLICATION_DATA
dahildir. Son ikisi, anahtar oluşturma sırasında belirtilmişlerse, anahtar bloğunun şifresini çözmek için gereklidir. -
certChain
, bir sertifika dizisi döndüren çıktı parametresidir. Giriş 0, tasdik sertifikasıdır, yanikeyToAttest
gelen anahtarı onaylar ve tasdik uzantısını içerir.
attestKey
yöntemi, herhangi bir zamanda çağrılabileceğinden ve yetkilendirme kısıtlamalarını karşılaması gerekmediğinden, onaylanmış anahtar üzerinde bir ortak anahtar işlemi olarak kabul edilir. Örneğin, tasdik edilen anahtarın kullanım için kullanıcı kimlik doğrulamasına ihtiyacı varsa, kullanıcı kimlik doğrulaması olmadan bir tasdik oluşturulabilir.
tasdik sertifikası
Tasdik sertifikası, tasdik edilen anahtarın açıklamasını içeren isteğe bağlı bir tasdik uzantısına sahip standart bir X.509 sertifikasıdır. Sertifika, onaylı bir tasdik anahtarıyla imzalanır. Tasdik anahtarı, tasdik edilen anahtardan farklı bir algoritma kullanabilir.
Tasdik sertifikası aşağıdaki tablodaki alanları içerir ve herhangi bir ek alan içeremez. Bazı alanlar sabit bir alan değeri belirtir. CTS testleri, sertifika içeriğinin tam olarak tanımlandığı gibi olduğunu doğrular.
Sertifika SIRASI
Alan adı (bkz. RFC 5280 ) | Değer |
---|---|
tbsSertifikası | TBSCertificate SEQUENCE |
imzaAlgoritma | Anahtarı imzalamak için kullanılan algoritmanın AlgorithmIdentifier'ı: EC anahtarları için ECDSA, RSA anahtarları için RSA. |
imzaDeğeri | BIT DİZGİSİ, ASN.1 DER kodlu tbsCertificate üzerinde hesaplanan imza. |
TBSCertificate SEQUENCE
Alan adı (bkz. RFC 5280 ) | Değer |
---|---|
version | INTEGER 2 (v3 sertifikası anlamına gelir) |
serialNumber | INTEGER 1 (sabit değer: tüm sertifikalarda aynı) |
signature | Anahtarı imzalamak için kullanılan algoritmanın AlgorithmIdentifier'ı: EC anahtarları için ECDSA, RSA anahtarları için RSA. |
issuer | Toplu tasdik anahtarının konu alanıyla aynıdır. |
validity | Tag::ACTIVE_DATETIME ve Tag::USAGE_EXPIRE_DATETIME değerlerini içeren iki tarihin DİZİSİ. Bu değerler, 1 Ocak 1970'ten bu yana milisaniye cinsindendir. Sertifikalardaki doğru tarih temsilleri için RFC 5280'e bakın.Tag::ACTIVE_DATETIME mevcut değilse, Tag::CREATION_DATETIME değerini kullanın. Tag::USAGE_EXPIRE_DATETIME mevcut değilse, toplu tasdik anahtarı sertifikasının sona erme tarihini kullanın. |
subject | CN = "Android Anahtar Deposu Anahtarı" (sabit değer: tüm sertifikalarda aynı) |
subjectPublicKeyInfo | Onaylanmış genel anahtarı içeren SubjectPublicKeyInfo. |
extensions/Key Usage | digitalSignature: anahtarın KeyPurpose::SIGN veya KeyPurpose::VERIFY amacı varsa ayarlayın. Diğer tüm bitler ayarlanmadı. |
extensions/CRL Distribution Points | değer belirsizliği |
extensions/"attestation" | OID, 1.3.6.1.4.1.11129.2.1.17'dir; içerik aşağıdaki Tasdik Uzantısı bölümünde tanımlanmıştır. Tüm X.509 sertifika uzantılarında olduğu gibi içerik, SEQUENCE doğrulamasının DER kodlamasını içeren bir OCTET_STRING olarak temsil edilir. |
Tasdik uzantısı
attestation
uzantısı, Android ve keymaster HAL'de kullanılan yetkilendirme listelerine doğrudan karşılık gelen bir yapıda, anahtarla ilişkili keymaster yetkilerinin eksiksiz bir açıklamasını içerir. Yetkilendirme listesindeki her etiket, keymaster etiket numarasıyla açıkça etiketlenmiş, ancak tip tanımlayıcı (dört yüksek sıralı bit) maskelenmiş bir ASN.1 SEQUENCE
girişi ile temsil edilir.
Örneğin, Keymaster 3'te Tag::PURPOSE
type.hal'de ENUM_REP | 1
. Tasdik uzantısı için ENUM_REP
değeri kaldırılır ve geriye etiket 1
kalır. (Keymaster 2 ve altı için KM_TAG_PURPOSE
, keymaster_defs.h'de tanımlanmıştır.)
Değerler, bu tabloya göre basit bir şekilde ASN.1 türlerine çevrilir:
Keymaster tipi | ASN.1 tipi |
---|---|
ENUM | TAM SAYI |
ENUM_REP | TAM SAYI |
UINT | TAM SAYI |
UINT_REP | TAM SAYI |
ULONG | TAM SAYI |
ULONG_REP | TAM SAYI |
DATE | INTEGER (1 Ocak 1970 00:00:00 GMT'den bu yana milisaniye) |
BOOL | NULL (keymaster'da, etiket mevcut, doğru, yok, yanlış anlamına gelir. Aynı semantik ASN.1 kodlaması için geçerlidir) |
BIGNUM | Şu anda kullanılmamaktadır, bu nedenle eşleme tanımlanmamıştır |
BYTES | OCTET_STRING |
Şema
Tasdik uzantısı içeriği, aşağıdaki ASN.1 şemasıyla açıklanmaktadır.
KeyDescription ::= SEQUENCE { attestationVersion INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3. attestationSecurityLevel SecurityLevel, keymasterVersion INTEGER, keymasterSecurityLevel SecurityLevel, attestationChallenge OCTET_STRING, uniqueId OCTET_STRING, softwareEnforced AuthorizationList, teeEnforced AuthorizationList, } SecurityLevel ::= ENUMERATED { Software (0), TrustedEnvironment (1), StrongBox (2), } AuthorizationList ::= SEQUENCE { purpose [1] EXPLICIT SET OF INTEGER OPTIONAL, algorithm [2] EXPLICIT INTEGER OPTIONAL, keySize [3] EXPLICIT INTEGER OPTIONAL. digest [5] EXPLICIT SET OF INTEGER OPTIONAL, padding [6] EXPLICIT SET OF INTEGER OPTIONAL, ecCurve [10] EXPLICIT INTEGER OPTIONAL, rsaPublicExponent [200] EXPLICIT INTEGER OPTIONAL, rollbackResistance [303] EXPLICIT NULL OPTIONAL, # KM4 activeDateTime [400] EXPLICIT INTEGER OPTIONAL originationExpireDateTime [401] EXPLICIT INTEGER OPTIONAL usageExpireDateTime [402] EXPLICIT INTEGER OPTIONAL noAuthRequired [503] EXPLICIT NULL OPTIONAL, userAuthType [504] EXPLICIT INTEGER OPTIONAL, authTimeout [505] EXPLICIT INTEGER OPTIONAL, allowWhileOnBody [506] EXPLICIT NULL OPTIONAL, trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4 trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4 unlockedDeviceRequired [509] EXPLICIT NULL OPTIONAL, # KM4 allApplications [600] EXPLICIT NULL OPTIONAL, applicationId [601] EXPLICIT OCTET_STRING OPTIONAL, creationDateTime [701] EXPLICIT INTEGER OPTIONAL, origin [702] EXPLICIT INTEGER OPTIONAL, rollbackResistant [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only. rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, osVersion [705] EXPLICIT INTEGER OPTIONAL, osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdBrand [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdDevice [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdProduct [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdSerial [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdImei [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdMeid [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdManufacturer [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3 attestationIdModel [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3 vendorPatchLevel [718] EXPLICIT INTEGER OPTIONAL, # KM4 bootPatchLevel [719] EXPLICIT INTEGER OPTIONAL, # KM4 } RootOfTrust ::= SEQUENCE { verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN, verifiedBootState VerifiedBootState, verifiedBootHash OCTET_STRING, # KM4 } VerifiedBootState ::= ENUMERATED { Verified (0), SelfSigned (1), Unverified (2), Failed (3), }
KeyDescription alanları
keymasterVersion
ve attestationChallenge
alanları, etiket yerine konumsal olarak tanımlanır, bu nedenle kodlanmış formdaki etiketler yalnızca alan türünü belirtir. Kalan alanlar, şemada belirtildiği gibi dolaylı olarak etiketlenir.
Alan adı | Tip | Değer |
---|---|---|
attestationVersion | TAM SAYI | Tasdik şemasının sürümü: 1, 2 veya 3. |
attestationSecurity | Güvenlik seviyesi | Bu tasdik güvenlik düzeyi. Donanım destekli anahtarların yazılım onaylarını almak mümkündür. Android sisteminin güvenliği ihlal edilmişse bu tür tasdiklere güvenilemez. |
keymasterVersion | TAM SAYI | Keymaster cihazının sürümü: 0, 1, 2, 3 veya 4. |
keymasterSecurity | Güvenlik seviyesi | Anahtar yöneticisi uygulamasının güvenlik düzeyi. |
attestationChallenge | OCTET_STRING | Tasdik isteğinde belirtilen Tag::ATTESTATION_CHALLENGE değeri. |
uniqueId | OCTET_STRING | İsteğe bağlı benzersiz kimlik, anahtarda Tag::INCLUDE_UNIQUE_ID varsa mevcut |
softwareEnforced | Yetki Listesi | Varsa, TEE tarafından zorunlu kılınmayan isteğe bağlı keymaster yetkileri. |
teeEnforced | Yetki Listesi | Varsa, TEE tarafından uygulanan isteğe bağlı, Keymaster yetkilendirmeleri. |
Yetkilendirme Listesi alanları
AuthorizationList
alanlarının tümü isteğe bağlıdır ve tür bitleri maskelenerek keymaster etiketi değeriyle tanımlanır. Açık etiketleme kullanılır, böylece alanlar ayrıca daha kolay ayrıştırma için ASN.1 türlerini belirten bir etiket içerir.
Her alanın değerleri hakkında ayrıntılar için, Keymaster 3 için types.hal
ve Keymaster 2 için keymaster_defs.h
ve aşağısına bakın. Keymaster etiket adları, KM_TAG
ön eki atlanarak ve geri kalanı büyük/küçük harf olarak değiştirilerek alan adlarına dönüştürüldü, böylece Tag::KEY_SIZE
keySize
oldu.
RootOfTrust alanları
RootOfTrust
Alanları konumsal olarak tanımlanır.
Alan adı | Tip | Değer |
---|---|---|
verifiedBootKey | OCTET_STRING | Sistem görüntüsünü doğrulamak için kullanılan anahtarın güvenli bir karması. SHA-256 önerilir. |
deviceLocked | BOOLE | Önyükleyici kilitliyse doğrudur; bu, yalnızca imzalı görüntülerin yanıp sönebileceği ve doğrulanmış önyükleme kontrolünün yapıldığı anlamına gelir. |
verifiedBootState | Doğrulanmış Önyükleme Durumu | Doğrulanmış önyükleme durumu. |
verifiedBootHash | OCTET_STRING | Verified Boot tarafından korunan tüm verilerin özeti. Verified Boot'un Android Verified Boot uygulamasını kullanan cihazlar için bu değer, VBMeta struct veya Verified Boot meta veri yapısının özetini içerir. Bu değerin nasıl hesaplanacağı hakkında daha fazla bilgi edinmek için bkz. VBMeta Digest |
VerifiedBootState değerleri
verifiedBootState
değerleri aşağıdaki anlamlara sahiptir:
Değer | Anlam |
---|---|
Verified | Önyükleyiciden, önyükleyici, önyükleme bölümü ve tüm doğrulanmış bölümler dahil olmak üzere doğrulanmış bölümlere uzanan tam bir güven zincirini gösterir. Bu durumda, verifiedBootKey değeri katıştırılmış sertifikanın karmasıdır, yani ROM'a yazılan değiştirilemez sertifikadır.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi yeşil önyükleme durumuna karşılık gelir. |
SelfSigned | Önyükleme bölümünün katıştırılmış sertifika kullanılarak doğrulandığını ve imzanın geçerli olduğunu gösterir. Önyükleyici, önyükleme işleminin devam etmesine izin vermeden önce bir uyarı ve genel anahtarın parmak izini görüntüler. Bu durumda, verifiedBootKey değeri, kendi kendini imzalayan sertifikanın karmasıdır.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi sarı önyükleme durumuna karşılık gelir. |
Unverified | Bir cihazın serbestçe değiştirilebileceğini gösterir. Bant dışı doğrulamak için cihaz bütünlüğü kullanıcıya bırakılmıştır. Önyükleyici, önyükleme işleminin devam etmesine izin vermeden önce kullanıcıya bir uyarı görüntüler. Bu durumda verifiedBootKey değeri boştur.Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi turuncu önyükleme durumuna karşılık gelir. |
Failed | Cihazın doğrulamada başarısız olduğunu gösterir. Hiçbir tasdik sertifikası bu değeri içermez, çünkü bu durumda önyükleyici durur. Bütünlük için buraya dahil edilmiştir. Bu durum, doğrulanmış önyükleme akışı belgelerinde belgelendiği gibi kırmızı önyükleme durumuna karşılık gelir. |
Güvenlik Düzeyi değerleri
securityLevel
değerleri aşağıdaki anlamlara sahiptir:
Değer | Anlam |
---|---|
Software | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, Android sisteminde uygulanır ve bu sistemin güvenliği ihlal edilirse değiştirilebilir. |
TrustedEnvironment | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, Güvenilir Yürütme Ortamında (TEE) uygulanır. TEE'nin güvenliği ihlal edilirse değiştirilebilir, ancak TEE uzaktan güvenlik ihlaline karşı oldukça dirençlidir ve doğrudan donanım saldırısı yoluyla güvenlik ihlaline karşı orta düzeyde dirençlidir. |
StrongBox | İlgili öğeyi (onay veya anahtar) oluşturan veya yöneten kod, özel bir donanım güvenlik modülünde uygulanır. It could be altered if the hardware security module is compromised, but it is highly resistant to remote compromise and highly resistant to compromise by direct hardware attack. |
Unique ID
The Unique ID is a 128-bit value that identifies the device, but only for a limited period of time. The value is computed with:
HMAC_SHA256(T || C || R, HBK)
Where:
-
T
is the "temporal counter value", computed by dividing the value ofTag::CREATION_DATETIME
by 2592000000, dropping any remainder.T
changes every 30 days (2592000000 = 30 * 24 * 60 * 60 * 1000). -
C
is the value ofTag::APPLICATION_ID
-
R
is 1 ifTag::RESET_SINCE_ID_ROTATION
is present in the attest_params parameter to the attest_key call, or 0 if the tag is not present. -
HBK
is a unique hardware-bound secret known to the Trusted Execution Environment and never revealed by it. The secret contains at least 128 bits of entropy and is unique to the individual device (probabilistic uniqueness is acceptable given the 128 bits of entropy). HBK should be derived from fused key material via HMAC or AES_CMAC.
Truncate the HMAC_SHA256 output to 128 bits.
Attestation keys and certificates
Two keys, one RSA and one ECDSA, and the corresponding certificate chains, are securely provisioned into the device.
Android 12 introduces Remote Key Provisioning, and Android 13 requires devices implement it. Remote Key Provisioning provides devices in the field with per-application, ECDSA P256 attestation certificates. These certificates are shorter-lived than the factory-provisioned certificates.
ID attestation
Android 8.0 includes optional support for ID attestation for devices with Keymaster 3. ID attestation allows the device to provide proof of its hardware identifiers, such as serial number or IMEI. Although an optional feature, it is highly recommended that all Keymaster 3 implementations provide support for it because being able to prove the device's identity enables use cases such as true zero-touch remote configuration to be more secure (because the remote side can be certain it is talking to the right device, not a device spoofing its identity).
ID attestation works by creating copies of the device's hardware identifiers that only the Trusted Execution Environment (TEE) can access before the device leaves the factory. A user may unlock the device's bootloader and change the system software and the identifiers reported by the Android frameworks. The copies of the identifiers held by the TEE cannot be manipulated in this way, ensuring that device ID attestation will only ever attest to the device's original hardware identifiers thereby thwarting spoofing attempts.
The main API surface for ID attestation builds on top of the existing key attestation mechanism introduced with Keymaster 2. When requesting an attestation certificate for a key held by keymaster, the caller may request that the device's hardware identifiers be included in the attestation certificate's metadata. If the key is held in the TEE, the certificate will chain back to a known root of trust. The recipient of such a certificate can verify that the certificate and its contents, including the hardware identifiers, were written by the TEE. When asked to include hardware identifiers in the attestation certificate, the TEE attests only to the identifiers held in its storage, as populated on the factory floor.
Storage properties
The storage that holds the device's identifiers needs to have these properties:
- The values derived from the device's original identifiers are copied to the storage before the device leaves the factory.
- The
destroyAttestationIds()
method can permanently destroy this copy of the identifier-derived data. Permanent destruction means the data is completely removed so neither a factory reset nor any other procedure performed on the device can restore it. This is especially important for devices where a user has unlocked the bootloader and changed the system software and modified the identifiers returned by Android frameworks. - RMA facilities should have the ability to generate fresh copies of the hardware identifier-derived data. This way, a device that passes through RMA can perform ID attestation again. The mechanism used by RMA facilities must be protected so that users cannot invoke it themselves, as that would allow them to obtain attestations of spoofed IDs.
- No code other than Keymaster trusted app in the TEE is able to read the identifier-derived data kept in the storage.
- The storage is tamper-evident: If the content of the storage has been modified, the TEE treats it the same as if the copies of the content had been destroyed and refuses all ID attestation attempts. This is implemented by signing or MACing the storage as described below .
- The storage does not hold the original identifiers. Because ID attestation involves a challenge, the caller always supplies the identifiers to be attested. The TEE only needs to verify that these match the values they originally had. Storing secure hashes of the original values rather than the values enables this verification.
Construction
To create an implementation that has the properties listed above, store the ID-derived values in the following construction S. Do not store other copies of the ID values, excepting the normal places in the system, which a device owner may modify by rooting:
S = D || HMAC(HBK, D)
where:
-
D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
-
HMAC
is the HMAC construction with an appropriate secure hash (SHA-256 recommended) -
HBK
is a hardware-bound key not used for any other purpose -
ID 1 ...ID n
are the original ID values; association of a particular value to a particular index is implementation-dependent, as different devices will have different numbers of identifiers -
||
represents concatenation
Because the HMAC outputs are fixed size, no headers or other structure are required to be able to find individual ID hashes, or the HMAC of D. In addition to checking provided values to perform attestation, implementations need to validate S by extracting D from S, computing HMAC(HBK, D) and comparing it to the value in S to verify that no individual IDs were modified/corrupted. Also, implementations must use constant-time comparisons for all individual ID elements and the validation of S. Comparison time must be constant regardless of the number of IDs provided and the correct matching of any part of the test.
Hardware identifiers
ID attestation supports the following hardware identifiers:
- Brand name, as returned by
Build.BRAND
in Android - Device name, as returned by
Build.DEVICE
in Android - Product name, as returned by
Build.PRODUCT
in Android - Manufacturer name, as returned by
Build.MANUFACTURER
in Android - Model name, as returned by
Build.MODEL
in Android - Serial number
- IMEIs of all radios
- MEIDs of all radios
To support device ID attestation, a device attests to these identifiers. All devices running Android have the first six and they are necessary for this feature to work. If the device has any integrated cellular radios, the device must also support attestation for the IMEIs and/or MEIDs of the radios.
ID attestation is requested by performing a key attestation and including the device identifiers to attest in the request. The identifiers are tagged as:
-
ATTESTATION_ID_BRAND
-
ATTESTATION_ID_DEVICE
-
ATTESTATION_ID_PRODUCT
-
ATTESTATION_ID_MANUFACTURER
-
ATTESTATION_ID_MODEL
-
ATTESTATION_ID_SERIAL
-
ATTESTATION_ID_IMEI
-
ATTESTATION_ID_MEID
The identifier to attest is a UTF-8 encoded byte string. This format applies to numerical identifiers, as well. Each identifier to attest is expressed as a UTF-8 encoded string.
If the device does not support ID attestation (or destroyAttestationIds()
was previously called and the device can no longer attest its IDs), any key attestation request that includes one or more of these tags fails with ErrorCode::CANNOT_ATTEST_IDS
.
If the device supports ID attestation and one or more of the above tags have been included in a key attestation request, the TEE verifies the identifier supplied with each of the tags matches its copy of the hardware identifiers. If one or more identifiers do not match, the entire attestation fails with ErrorCode::CANNOT_ATTEST_IDS
. It is valid for the same tag to be supplied multiple times. This can be useful, for example, when attesting IMEIs: A device may have multiple radios with multiple IMEIs. An attestation request is valid if the value supplied with each ATTESTATION_ID_IMEI
matches one of the device's radios. The same applies to all other tags.
If attestation is successful, the attested IDs is added to the attestation extension (OID 1.3.6.1.4.1.11129.2.1.17) of the issued attestation certificate, using the schema from above . Changes from the Keymaster 2 attestation schema are bolded , with comments.
Java API
This section is informational only. Keymaster implementers neither implement nor use the Java API. This is provided to help implementers understand how the feature is used by applications. System components may use it differently, which is why it's crucial this section not be treated as normative.