Keymaster के अनुमति टैग

इस पेज पर, Keymaster HAL लागू करने वालों की मदद करने के लिए जानकारी दी गई है. यह HAL में हर टैग को कवर करता है, जो की-मास्टर वर्शन है वह टैग उपलब्ध है में है और क्या टैग दोहराया जा सकता है. टैग के ब्यौरे में जो जानकारी दी गई है उसे छोड़कर, नीचे दिए गए सभी टैग, कुंजी जेनरेशन के दौरान विशेषताएं.

Keymaster 4 के लिए, टैग platform/hardware/interfaces/keymaster/keymaster-version/types.hal में तय किए जाते हैं. जैसे, Keymaster 3 के लिए 3.0/types.hal और Keymaster 4 के लिए 4.0/types.hal. Keymaster 2 और उससे पहले के वर्शन के लिए, टैग को platform/hardware/libhardware/include/hardware/keymaster_defs.h में तय किया जाता है.

फ़ंक्शन के बारे में जानने के लिए, Keymaster फ़ंक्शन पेज पर जाएं.

Tag::ACTIVE_DATETIME

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे उस तारीख और समय के बारे में पता चलता है जब पासकोड चालू हो जाता है. इस समय से पहले, कुंजी का इस्तेमाल करने की कोशिश करने पर, ErrorCode::KEY_NOT_YET_VALID दिखता है.

यह वैल्यू 64-बिट पूर्णांक है, जो 1 जनवरी से मिलीसेकंड को दिखाता है. 1970 में लॉन्च किया गया.

टैग::ALGORITHM

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह उस क्रिप्टोग्राफ़िक एल्गोरिदम के बारे में बताता है जिसका इस्तेमाल कुंजी के साथ किया जाता है.

संभावित वैल्यू, नीचे दिए गए एनोटेशन से तय होती हैं:

कीमास्टर 3 
enum class Algorithm : uint32_t {
    RSA = 1,
    EC = 3,
    AES = 32,
    HMAC = 128,
};
Keymaster 2 और इससे पहले के वर्शन 
typedef enum {
    KM_ALGORITHM_RSA = 1,
    KM_ALGORITHM_EC = 3,
    KM_ALGORITHM_AES = 32,
    KM_ALGORITHM_HMAC = 128,
} keymaster_algorithm_t;

टैग::ALL_APPLICATIONS

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

आने वाले समय में इस्तेमाल के लिए रिज़र्व किया गया.

Tag::ALLOW_WHILE_ON_BODY

वर्शन: 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह टैग सिर्फ़ उन Android Wear डिवाइसों पर लागू होता है जिनमें बॉडी सेंसर होते हैं. पर नहीं हो सकता है कि कोई TEE, सुरक्षित ऐक्सेस ऑन-बॉडी सेंसर या ऑन-बॉडी सेंसर बहुत सुरक्षित होते हैं. इसलिए, पूरी तरह से सॉफ़्टवेयर पर निर्भर सुविधा होने की उम्मीद की जाती है.

टैग::ALL_USERS

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

आने वाले समय में इस्तेमाल के लिए रिज़र्व किया गया.

Tag::APPLICATION_DATA

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

इसे कब दिया जाता है generateKey या importKey, इस टैग में उस डेटा के बारे में बताया जाता है जो कुंजी के सभी इस्तेमाल के दौरान ज़रूरी होता है. खास तौर पर, exportKey और getKeyCharacteristics को clientId पैरामीटर के लिए एक ही वैल्यू देनी होगी. साथ ही, begin को inParams सेट के हिस्से के तौर पर, यह टैग और उससे जुड़ा डेटा देना होगा. अगर सही डेटा नहीं दिया जाता है, तो फ़ंक्शन ErrorCode::INVALID_KEY_BLOB दिखाता है.

इस टैग का कॉन्टेंट, क्रिप्टोग्राफ़िक तरीके से कुंजी से जुड़ा होता है. इसका मतलब है कि दुनिया के सभी सुरक्षित रहस्यों का ऐक्सेस रखने वाले किसी व्यक्ति के पास, टैग के कॉन्टेंट का ऐक्सेस न होने पर, टैग के कॉन्टेंट को ब्रूट-फ़ोर्स किए बिना कुंजी को डिक्रिप्ट (सुरक्षित) करना मुमकिन नहीं होना चाहिए. ऐप्लिकेशन, ज़रूरत के मुताबिक ज़्यादा एन्ट्रॉपी वाले कॉन्टेंट का इस्तेमाल करके, इस तरह की समस्या से बच सकते हैं.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::APPLICATION_ID

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इसे कब दिया जाता है generateKey या importKey, इस टैग में उस डेटा के बारे में बताया जाता है जो कुंजी के सभी इस्तेमाल के दौरान ज़रूरी होता है. खास तौर पर, exportKey और getKeyCharacteristics को clientId पैरामीटर में एक ही वैल्यू देनी होगी. साथ ही, begin को inParams सेट के हिस्से के तौर पर, यह टैग और उससे जुड़ा डेटा देना होगा. अगर सही डेटा नहीं दिया जाता है, तो फ़ंक्शन ErrorCode::INVALID_KEY_BLOB दिखाता है.

इस टैग का कॉन्टेंट, क्रिप्टोग्राफ़िक तरीके से कुंजी से जुड़ा होता है. इसका मतलब है कि दुनिया के सभी सुरक्षित रहस्यों को ऐक्सेस करने वाला कोई व्यक्ति, टैग के कॉन्टेंट को ऐक्सेस नहीं कर सकता. साथ ही, वह टैग के कॉन्टेंट को ब्रूट-फ़ोर्स किए बिना, कुंजी को डिक्रिप्ट नहीं कर सकता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

Tag::ASSOCIATED_DATA

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

AES-GCM एन्क्रिप्शन या डिक्रिप्शन के लिए, "मिलता-जुलता डेटा" उपलब्ध कराता है. यह टैग है अपडेट के लिए दिया गया और ऐसा डेटा बताता है जो एन्क्रिप्ट (सुरक्षित) नहीं किया गया है या डिक्रिप्ट नहीं किया गया है, लेकिन इसका इस्तेमाल कंप्यूटिंग में किया जाता है को GCM टैग के साथ जोड़ा जा सकता है.

वैल्यू एक ब्लॉब होती है, जो बाइट का एक अरे होता है. इसकी लंबाई कोई भी हो सकती है.

Tag::ATTESTATION_APPLICATION_ID

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इस एट्रिब्यूट का इस्तेमाल, उन संभावित ऐप्लिकेशन के सेट की पहचान करने के लिए किया जाता है जिनमें से किसी एक ने पासकोड की पुष्टि की प्रक्रिया शुरू की है.

वैल्यू एक ब्लॉब होती है, जो बाइट के किसी भी लंबाई के अरे होती है.

टैग::ATTESTATION_CHALLENGE

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

प्रमाणित करने में चैलेंज देने के लिए इस्तेमाल किया जाता है.

वैल्यू एक ब्लॉब होती है, जो बाइट के किसी भी लंबाई के अरे होती है.

टैग::ATTESTATION_ID_BRAND

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? नहीं

Android में Build.BRAND के ज़रिए दिखाया गया, डिवाइस के ब्रैंड का नाम दिखाता है. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब सेव किया जाता है.

अगर डिवाइस पर आईडी की पुष्टि करने की सुविधा काम नहीं करती है (या पहले destroyAttestationIds() को कॉल किया गया था और डिवाइस अब अपने आईडी की पुष्टि नहीं कर सकता), तो इस टैग को शामिल करने वाला कुंजी की पुष्टि करने का कोई भी अनुरोध ErrorCode::CANNOT_ATTEST_IDS के साथ पूरा नहीं होता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::ATTESTATION_ID_DEVICE

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

डिवाइस का नाम बताता है, जैसा कि Build.DEVICE से जानकारी मिलती है Android में. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी की पुष्टि करने की सुविधा काम नहीं करती है (या पहले destroyAttestationIds() को कॉल किया गया था और डिवाइस अब अपने आईडी की पुष्टि नहीं कर सकता), तो इस टैग को शामिल करने वाला कुंजी की पुष्टि करने का कोई भी अनुरोध ErrorCode::CANNOT_ATTEST_IDS के साथ पूरा नहीं होता.

वैल्यू एक ब्लॉब होती है, जो बाइट का एक अरे होता है. इसकी लंबाई कोई भी हो सकती है.

Tag::ATTESTATION_ID_IMEI

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? हां

इससे डिवाइस पर मौजूद सभी रेडियो के IMEI नंबर की जानकारी मिलती है. यह फ़ील्ड सिर्फ़ सेट है डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध करते समय.

अगर डिवाइस पर आईडी की पुष्टि करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::ATTESTATION_ID_MANUFACTURER

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? नहीं

डिवाइस बनाने वाली कंपनी का नाम दिखाता है. यह नाम, Android में Build.MANUFACTURER से मिलता है. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी प्रमाणित करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::ATTESTATION_ID_MEID

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? हां

डिवाइस पर सभी रेडियो के लिए MEID देता है. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी की पुष्टि करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::ATTESTATION_ID_MODEL

वर्शन: 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे डिवाइस के मॉडल का नाम मिलता है, जो Android में Build.MODEL. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी प्रमाणित करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक ब्लॉब होती है, जो बाइट का एक अरे होता है. इसकी लंबाई कोई भी हो सकती है.

Tag::ATTESTATION_ID_PRODUCT

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

डिवाइस का प्रॉडक्ट नाम देता है, जैसा कि इनके ज़रिए दिया जाता है: Android में Build.PRODUCT. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी प्रमाणित करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

टैग::ATTESTATION_ID_SERIAL

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

डिवाइस का सीरियल नंबर दिखाता है. यह फ़ील्ड सिर्फ़ तब सेट किया जाता है, जब डिवाइस के आइडेंटिफ़ायर की पुष्टि का अनुरोध किया जाता है.

अगर डिवाइस पर आईडी प्रमाणित करने की सुविधा काम नहीं करती (या destroyAttestationIds() को पहले कॉल किया गया था और डिवाइस ये काम कर सकता है अब अपनी आईडी प्रमाणित नहीं करता है), तो पुष्टि करने का कोई भी मुख्य अनुरोध जिसमें ये शामिल हों यह टैग ErrorCode::CANNOT_ATTEST_IDS से काम नहीं करता.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

Tag::AUTH_TIMEOUT

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

पुष्टि करने के बाद, कुंजी को इस्तेमाल करने के लिए अनुमति कितने सेकंड के लिए दी गई है, यह बताता है. अगर Tag::USER_SECURE_ID मौजूद है और यह टैग नहीं है, तो हर बार इस्तेमाल करने के लिए कुंजी की पुष्टि की ज़रूरत होती है. हर कार्रवाई के लिए पुष्टि करने के फ़्लो की जानकारी के लिए, begin देखें.

वैल्यू 32-बिट पूर्णांक होती है, जो वैल्यू के तौर पर पुष्टि करने के तरीके से, टैग::USER_SECURE_ID के ज़रिए तय किए गए उपयोगकर्ता की पुष्टि करें Tag::USER_AUTH_TYPE से बताया गया है कि कुंजी ये हो सकती है इस्तेमाल किया गया.

Tag::AUTH_TOKEN

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

शुरू करने, अपडेट करने या पूरा करने के लिए, पुष्टि करने वाला टोकन उपलब्ध कराता है. इससे, कुंजी के उस ऑपरेशन के लिए उपयोगकर्ता की पुष्टि की जा सकती है जिसके लिए ज़रूरी है (कुंजी में Tag::USER_SECURE_ID है).

वैल्यू एक ब्लॉब है, जिसमें hw_auth_token_t स्ट्रक्चर शामिल है.

टैग::BLOB_USAGE_REQUIREMENTS

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

जनरेट किए गए इवेंट के लिए, सिस्टम एनवायरमेंट की ज़रूरी शर्तें तय करता है का इस्तेमाल किया जा सकता है.

संभावित वैल्यू, यहां दी गई गिनती के आधार पर तय की जाती हैं:

Keymaster 3 
enum class KeyBlobUsageRequirements : uint32_t {
    STANDALONE = 0,
    REQUIRES_FILE_SYSTEM = 1,
};
KeyMaster 2 और इससे पहले के वर्शन 
typedef enum {
    KM_BLOB_STANDALONE = 0,
    KM_BLOB_REQUIRES_FILE_SYSTEM = 1,
} keymaster_key_blob_usage_requirements_t;

पासकोड जनरेट करने के दौरान, इस टैग की जानकारी दी जा सकती है, ताकि पासकोड को तय की गई शर्तों में इस्तेमाल किया जा सके. इसे generateKey और getKeyCharacteristics से मिली, पासकोड की मुख्य विशेषताओं के साथ दिखाना होगा. अगर कॉल करने वाला (कॉलर) Tag::BLOB_USAGE_REQUIREMENTS को वैल्यू KeyBlobUsageRequirements::STANDALONE, ट्रस्टलेट कुंजी ब्लॉब लौटाता है जिसे फ़ाइल सिस्टम की सुविधा के बिना इस्तेमाल किया जा सकता है. डिवाइसों के लिए यह ज़रूरी है में एन्क्रिप्ट (सुरक्षित) की गई डिस्क शामिल हैं, जहां हो सकता है कि फ़ाइल सिस्टम के बाद, डिस्क को डिक्रिप्ट करने के लिए KeyMaster कुंजी का इस्तेमाल किया जाता है.

Tag::BLOCK_MODE

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? हां

ब्लॉक सिफर मोड के बारे में बताता है जिनके साथ कुंजी का इस्तेमाल किया जा सकता है. यह टैग सिर्फ़ AES पासकोड के लिए काम करता है.

संभावित वैल्यू, यहां दी गई गिनती के आधार पर तय की जाती हैं:

कीमास्टर 3 
enum class BlockMode : uint32_t {
    ECB = 1,
    CBC = 2,
    CTR = 3,
    GCM = 32,
};
Keymaster 2 और उससे पहले के वर्शन 
typedef enum {
    KM_MODE_ECB = 1,
    KM_MODE_CBC = 2,
    KM_MODE_CTR = 3,
    KM_MODE_GCM = 32,
} keymaster_block_mode_t;

इस टैग को दोहराया जा सकता है. साथ ही, एईएस पासकोड के ऑपरेशन के लिए, begin के additionalParams आर्ग्युमेंट में कोई मोड तय करें. अगर बताया गया मोड, कुंजी से जुड़े मोड में नहीं है, तो ErrorCode::INCOMPATIBLE_BLOCK_MODE से कार्रवाई नहीं की जा सकी.

टैग::BOOT_PATCHLEVEL

वर्शन: 4

Tag::BOOT_PATCHLEVEL, बूट इमेज (कर्नल) के सुरक्षा पैच लेवल के बारे में बताता है, जिसका इस्तेमाल कुंजी के साथ किया जा सकता है. यह टैग की-मास्टर TA को कभी नहीं भेजा जाता, लेकिन को टीए की ओर से हार्डवेयर के तहत लागू की गई अनुमति सूची में जोड़ दिया जाता है. ऐसा करने की कोई भी कोशिश ऐसी कुंजी का इस्तेमाल करें जिसका Tag::BOOT_PATCHLEVEL मान, अभी चल रहे सिस्टम पैचलेवल की वजह से begin(), वापसी के लिए getKeyCharacteristics() या exportKey() ErrorCode::KEY_REQUIRES_UPGRADE. ज़्यादा जानकारी के लिए, upgradeKey() पर जाएं.

टैग का मान, YYYYMMDD रूप का पूर्णांक होता है, जहां YYYY आखिरी अपडेट के चार अंकों वाला साल, MM दो अंकों वाला महीना है और DD आखिरी अपडेट के बाद का दो अंकों वाला दिन. उदाहरण के लिए, अगर किसी Android डिवाइस पर जनरेट की गई पासकोड की वैल्यू 5 जून, 2018 को अपडेट की गई थी, तो उसकी वैल्यू 20180605 होगी. अगर दिन की जानकारी नहीं है, तो 00 का इस्तेमाल किया जा सकता है.

हर बूट के दौरान, बूटलोडर को बूट इमेज का पैच लेवल देना होगा को सुरक्षित माहौल में रखा जा सके (यह प्रोसेस, लागू करने के तरीके को तय करती है).

यह हार्डवेयर से लागू होना चाहिए.

Tag::BOOTLOADER_ONLY

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे पता चलता है कि सिर्फ़ बूटलोडर, कुंजी का इस्तेमाल कर सकता है.

यह टैग बूलियन है, इसलिए संभावित मान सही हैं (अगर टैग मौजूद है) और गलत (अगर टैग मौजूद नहीं है).

Android सिस्टम में Tag::BOOTLOADER_ONLY वाली कुंजी का इस्तेमाल करने की कोशिश करने पर, ErrorCode::INVALID_KEY_BLOB दिखता है.

Tag::CALLER_NONCE

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे पता चलता है कि कॉलर नॉन्स की ज़रूरत के हिसाब से काम करने के लिए नॉन्स उपलब्ध करा सकता है.

यह टैग बूलियन है. इसलिए, इसकी संभावित वैल्यू 'सही' (अगर टैग मौजूद है) और 'गलत' (अगर टैग मौजूद नहीं है) हो सकती हैं.

इस टैग का इस्तेमाल सिर्फ़ AES कुंजियों के लिए किया जाता है. यह सिर्फ़ CBC, CTR, और GCM ब्लॉक मोड के लिए काम आता है. अगर टैग मौजूद नहीं है, तो लागू करने की प्रोसेस को ErrorCode::CALLER_NONCE_PROHIBITED से शुरू करने के लिए, Tag::NONCE देने वाले किसी भी ऑपरेशन को अस्वीकार करना चाहिए.

Tag::CREATION_DATETIME

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे, कुंजी बनाने की तारीख और समय का पता चलता है. यह समय, 1 जनवरी, 1970 से लेकर अब तक के मिलीसेकंड में होता है. यह टैग ज़रूरी नहीं है और सिर्फ़ जानकारी देने के लिए है.

Tag::DIGEST

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? हां

ऐसे डाइजेस्ट एल्गोरिदम की जानकारी देता है जिनका इस्तेमाल, हस्ताक्षर करने और पुष्टि करने के लिए कुंजी के साथ किया जा सकता है. यह टैग आरएसए, ईसीडीएसए, और एचएमएसी कुंजियां.

संभावित वैल्यू, नीचे दिए गए एनोटेशन से तय होती हैं:

कीमास्टर 3 
enum class Digest : uint32_t {
    NONE = 0,
    MD5 = 1,
    SHA1 = 2,
    SHA_2_224 = 3,
    SHA_2_256 = 4,
    SHA_2_384 = 5,
    SHA_2_512 = 6,
};
KeyMaster 2 और इससे पहले के वर्शन 
typedef enum {
    KM_DIGEST_NONE = 0,
    KM_DIGEST_MD5 = 1,
    KM_DIGEST_SHA1 = 2,
    KM_DIGEST_SHA_2_224 = 3,
    KM_DIGEST_SHA_2_256 = 4,
    KM_DIGEST_SHA_2_384 = 5,
    KM_DIGEST_SHA_2_512 = 6,
}
keymaster_digest_t;

इस टैग को दोहराया जा सकता है. हस्ताक्षर करने और पुष्टि करने की कार्रवाइयों के लिए, begin के additionalParams आर्ग्युमेंट में डाइजेस्ट डालें. अगर बताया गया डाइजेस्ट कुंजी से जुड़े डाइजेस्ट में नहीं है, तो ErrorCode::INCOMPATIBLE_DIGEST से कार्रवाई नहीं की जा सकी.

Tag::EC_CURVE

वर्शन: 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

कीमास्टर 1 में, EC कुंजियों के लिए इस्तेमाल किए जाने वाले कर्व का अनुमान खास कुंजी से लगाया गया था साइज़. आने वाले समय में, ज़रूरत के हिसाब से बेहतर सुविधा पाने के लिए, KeyMaster 2 में तय करें. ईसी कुंजी जनरेशन के अनुरोधों में Tag::EC_CURVE, Tag::KEY_SIZE या दोनों हो सकते हैं.

संभावित वैल्यू, नीचे दिए गए एनोटेशन से तय होती हैं:

कीमास्टर 3 
enum class EcCurve : uint32_t {
    P_224 = 0,
    P_256 = 1,
    P_384 = 2,
    P_521 = 3,
};
Keymaster 2 और उससे पहले के वर्शन 
enum class EcCurve : uint32_t {
    P_224 = 0,
    P_256 = 1,
    P_384 = 2,
P_521 = 3,
};

अगर जनरेट करने के अनुरोध में सिर्फ़ Tag::KEY_SIZE है, तो सही एनआईएसटी कर्व चुनकर, KeyMaster 1 लॉजिक पर वापस जाएं.

अगर अनुरोध में सिर्फ़ Tag::EC_CURVE शामिल है, तो चुना गया कर्व. कीमास्टर 3 और उसके बाद के वर्शन के लिए, कर्व EcCurve. Keymaster 2 और उससे पहले के वर्शन के लिए, कर्व keymaster_ec_curve_t में तय किए जाते हैं.

अगर अनुरोध में दोनों हैं, तो इससे तय किए गए कर्व का इस्तेमाल करें Tag::EC_CURVE. साथ ही, पुष्टि करें कि तय किया गया कुंजी का साइज़ उस वक्र के लिए सही है. अगर ऐसा नहीं है, तो ErrorCode::INVALID_ARGUMENT दिखाएं.

Tag::INCLUDE_UNIQUE_ID

वर्शन: 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इस टैग को कुंजी जनरेट करने के दौरान बताया जाता है, ताकि यह बताया जा सके कि पुष्टि करने की प्रक्रिया जनरेट की गई कुंजी के सर्टिफ़िकेट में ऐप्लिकेशन के स्कोप वाला स्कोप और टाइम-बाउंड डिवाइस-यूनीक आईडी, जैसा कि नीचे बताया गया है टैग::UNIQUE_ID.

यह टैग बूलियन है, इसलिए संभावित मान सही हैं (अगर टैग मौजूद है) और गलत (अगर टैग मौजूद नहीं है).

टैग::KEY_SIZE

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह कुंजी के एल्गोरिदम के लिए सामान्य तरीके से मेज़र करके, बिट में कुंजी का साइज़ बताता है. उदाहरण के लिए, आरएसए कुंजियों के लिए, Tag::KEY_SIZE तय करता है कि सार्वजनिक मापांक का साइज़. AES कुंजियों के लिए, यह सीक्रेट कुंजी के कॉन्टेंट की लंबाई बताता है.

टैग::MAC_LENGTH

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

MAC या GCM की पुष्टि करने वाले टैग की अनुरोध की गई लंबाई को बिट में देता है.

यह वैल्यू, बिट में एमएसी की लंबाई होती है. यह 8 का मल्टीपल होता है और कम से कम उतना ही बड़ा होता है जितना कि कुंजी से जुड़े Tag::MIN_MAC_LENGTH की वैल्यू होती है.

टैग::MAX_USES_PER_BOOT

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

इस नीति से तय होता है कि सिस्टम के बीच किसी कुंजी का इस्तेमाल ज़्यादा से ज़्यादा कितनी बार किया जा सकता है फिर से चालू करता है. यह कुंजी के इस्तेमाल की दर को सीमित करने का एक और तरीका है.

वैल्यू 32-बिट पूर्णांक है, जो हर बूट के लिए इस्तेमाल के बारे में बताती है.

जब किसी कार्रवाई में इस टैग वाली कुंजी का इस्तेमाल किया जाता है, तो कुंजी से जुड़ा काउंटर को इस अवधि के दौरान बढ़ाना चाहिए कॉल शुरू करें. कुंजी का काउंटर इस वैल्यू से ज़्यादा होने के बाद, कुंजी का इस्तेमाल करने की सभी कोशिशें ErrorCode::MAX_OPS_EXCEEDED के साथ तब तक विफल होती रहेंगी, जब तक डिवाइस को रीस्टार्ट नहीं किया जाता. इसका मतलब है कि ट्रस्टलेट, इस टैग वाली कुंजियों के लिए इस्तेमाल के काउंटर की टेबल रखता है. Keymaster की मेमोरी अक्सर सीमित होती है. इसलिए, इस टेबल का साइज़ तय हो सकता है. साथ ही, टेबल के भर जाने पर, Keymaster इस टैग के साथ कुंजियों का इस्तेमाल करने की कोशिश करने वाले ऑपरेशन को पूरा नहीं कर सकता. टेबल में कम से कम 16 बटन होने चाहिए. अगर टेबल भर जाने की वजह से कोई कार्रवाई पूरी नहीं हो पाती है, तो Keymaster ErrorCode::TOO_MANY_OPERATIONS दिखाता है.

टैग::MIN_MAC_LENGTH

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह टैग, मैसेज की पुष्टि करने के लिए इस्तेमाल होने वाले मैसेज आइडेंटिफ़ायर (एमएसी) की कम से कम लंबाई तय करता है. इसकी मदद से, GCM मोड के साथ काम करने वाली एचएमएसी कुंजियों और एईएस कुंजियों के लिए, एमएसी का अनुरोध किया जा सकता है या उसकी पुष्टि की जा सकती है.

यह वैल्यू, एमएसी की कम से कम लंबाई को बिट में दिखाती है. यह 8 का गुणक हो. HMAC पासकोड के लिए, वैल्यू कम से कम 64 होनी चाहिए. GCM पासकोड की वैल्यू कम से कम 96 और ज़्यादा से ज़्यादा 128 होनी चाहिए.

Tag::MIN_SECONDS_BETWEEN_OPS

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

तय किए गए समय के बीच कम से कम बीतने वाले समय की जानकारी देता है संक्रियाएं करते हैं. इसका इस्तेमाल, उन संदर्भों में कुंजियों के इस्तेमाल की दर को सीमित करने के लिए किया जा सकता है जहां अनलिमिटेड इस्तेमाल से ब्रूट फ़ोर्स अटैक हो सकते हैं.

वैल्यू, 32-बिट पूर्णांक है, जो कि मंज़ूर किए गए सेकंड के बीच में दिखाता है कार्रवाइयां.

जब किसी कार्रवाई में इस टैग वाली कुंजी का इस्तेमाल किया जाए, तो टाइमर शुरू करें खत्म होने के दौरान या रद्द करने की कॉल. कोई भी इसे शुरू करने के लिए कॉल करो टाइमर से पहले मिलने वाला यह संकेत देता है कि Tag::MIN_SECONDS_BETWEEN_OPS इस समय से विफल रहा ErrorCode::KEY_RATE_LIMIT_EXCEEDED. यह इसका मतलब है कि ट्रस्टलेट इस टैग वाली कुंजियों के लिए उपयोग काउंटर की एक तालिका रखता है. कीमास्टर मेमोरी अक्सर सीमित होने की वजह से, इस टेबल में तय ज़्यादा से ज़्यादा मेमोरी हो सकती है आकार और KeyMaster उन कार्रवाइयों को विफल कर सकते है जो इस टैग के साथ कुंजियों का इस्तेमाल करने की कोशिश करते हैं जब टेबल भर जाएगी. टेबल में, इस्तेमाल में चल रही कम से कम 32 कुंजियां होनी चाहिए. साथ ही, कुंजी के इस्तेमाल के कम से कम अंतराल की समयसीमा खत्म होने पर, टेबल स्लॉट का बार-बार इस्तेमाल किया जाना चाहिए. यदि तालिका के भर जाने के कारण कोई कार्रवाई विफल होती है, तो कीमास्टर वापस आ जाती है ErrorCode::TOO_MANY_OPERATIONS.

Tag::NO_AUTH_REQUIRED

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे पता चलता है कि इस कुंजी का इस्तेमाल करने के लिए, पुष्टि करने की ज़रूरत नहीं है. यह टैग, Tag::USER_SECURE_ID के साथ इस्तेमाल नहीं किया जा सकता.

यह टैग बूलियन है, इसलिए संभावित मान सही हैं (अगर टैग मौजूद है) और गलत (अगर टैग मौजूद नहीं है).

Tag::NONCE

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

एईएस GCM, सीबीसी या सीटीआर एन्क्रिप्शन या डिक्रिप्शन के लिए, नॉन्स या इनिशलाइज़ेशन वेक्टर (IV) उपलब्ध कराता है या दिखाता है. एन्क्रिप्ट और डिक्रिप्ट करने की प्रोसेस के दौरान, शुरू करने के लिए यह टैग दिया जाता है. यह सिर्फ़ तब शुरू करने के लिए दिया जाता है, जब कुंजी में Tag::CALLER_NONCE हो. अगर यह पैरामीटर उपलब्ध नहीं कराया गया है, सही नॉन्स या IV, रैंडम तरीके से जनरेट किया गया है KeyMaster और शुरुआत से वापस लौटा दिया गया है.

वैल्यू एक ब्लॉब होती है, जो बाइट के किसी भी लंबाई के अरे होती है. अनुमति वाली लंबाई, मोड पर निर्भर करती है: GCM नॉन्स की लंबाई 12 बाइट होती है; CBC और CTR IV की लंबाई 16 बाइट होती है.

Tag::ORIGIN

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

अगर कुंजी के बारे में जानकारी है, तो यह बताता है कि कुंजी कहां बनाई गई थी. कुंजी जनरेट करने या इंपोर्ट करने के दौरान, इस टैग की जानकारी नहीं दी जा सकती. साथ ही, ट्रस्टलेट को कुंजी की मुख्य विशेषताओं में इसे जोड़ना होगा.

Keymaster 3

संभावित वैल्यू यहां दी गई हैं android::hardware::keymaster::v3_0::KeyOrigin:

enum class KeyOrigin : uint32_t {
    GENERATED = 0,
    DERIVED = 1,
    IMPORTED = 2,
    UNKNOWN = 3,
};
Keymaster 2 और उससे पहले के वर्शन

संभावित वैल्यू keymaster_origin_t में दी गई हैं:

typedef enum {
    KM_ORIGIN_GENERATED = 0,
    KM_ORIGIN_IMPORTED = 2,
    KM_ORIGIN_UNKNOWN = 3,
} keymaster_key_origin_t

वैल्यू का पूरा मतलब सिर्फ़ वैल्यू पर ही नहीं, बल्कि इस बात पर निर्भर करता है कि यह हार्डवेयर के ज़रिए लागू की गई या सॉफ़्टवेयर के ज़रिए लागू की गई विशेषताओं की सूची में मौजूद होता है.

GENERATED से पता चलता है कि Keymaster ने कुंजी जनरेट की है. अगर पासकी, हार्डवेयर से जुड़ी सूची में है, तो इसका मतलब है कि पासकी को सुरक्षित हार्डवेयर में जनरेट किया गया है और यह हमेशा हार्डवेयर से जुड़ी रहती है. अगर आपने यह कुंजी सॉफ़्टवेयर के ज़रिए लागू की गई सूची में, SoftKeyMaster में जनरेट की गई थी और यह हार्डवेयर बाउंड नहीं है.

DERIVED से पता चलता है कि कुंजी, कीमास्टर के ज़रिए ली गई थी. ऐसा हो सकता है कि डिवाइस के पास मौजूद न हो.

IMPORTED से पता चलता है कि पासकोड, Keymaster के बाहर जनरेट किया गया था और Keymaster में इंपोर्ट किया गया था. अगर कोई पासकोड, हार्डवेयर से जुड़ी सूची में है, तो वह हमेशा के लिए हार्डवेयर से जुड़ा रहेगा. हालांकि, सुरक्षित हार्डवेयर के बाहर उसकी कॉपी मौजूद हो सकती हैं. अगर सॉफ़्टवेयर से लागू होने वाली सूची में, कुंजी को SoftKeymaster में इंपोर्ट किया गया था और वह हार्डवेयर से बंधी नहीं है.

UNKNOWN सिर्फ़ हार्डवेयर के ज़रिए लागू की गई सूची में ही दिखना चाहिए. इससे पता चलता है कि कुंजी हार्डवेयर बाउंड है, लेकिन यह ज्ञात नहीं है कि कुंजी मूल रूप से यहां जनरेट की गई थी या नहीं सुरक्षित हार्डवेयर हो या उसे इंपोर्ट किया गया हो. ऐसा सिर्फ़ तब होता है, जब keymaster0 हार्डवेयर का इस्तेमाल, keymaster1 सेवाओं को एमुलेट करने के लिए किया जा रहा हो.

Tag::ORIGINATION_EXPIRE_DATETIME

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

यह तारीख और समय बताता है कि हस्ताक्षर करने और एन्क्रिप्ट करने के लिए, पासकोड की समयसीमा कब खत्म होगी. इसके बाद, अगर किसी कुंजी का इस्तेमाल किया जा रहा है, तो Keypurpose::SIGN या Keypurpose::ENCRYPT दिया गया शुरू करने में गड़बड़ी हुई ErrorCode::KEY_EXPIRED के साथ.

वैल्यू 64-बिट पूर्णांक है, जो मिलीसेकंड को दिखाता है 1 जनवरी, 1970.

टैग::OS_PATCHLEVEL

वर्शन: 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह टैग, कभी भी पासकोड मैनेजर टीए को नहीं भेजा जाता. हालांकि, इसे टीए, हार्डवेयर से लागू की गई अनुमति की सूची में जोड़ देता है.

टैग का मान YYYYMM फ़ॉर्म का पूर्णांक होता है, जहां YYYY होता है. पिछले अपडेट का चार अंकों वाला साल और MM आखिरी अपडेट का दो अंकों वाला महीना है अपडेट. उदाहरण के लिए, Android डिवाइस पर जनरेट किए गए उस पासकोड के लिए जिसे पिछली बार दिसंबर 2015, मान 201512 हो जाएगा.

जिन पासकोड का पैच लेवल, मौजूदा पैच लेवल से अलग है उनका इस्तेमाल नहीं किया जा सकता. ऐसी कुंजी का इस्तेमाल करने पर, begin, getKeyCharacteristics या exportKey फ़ंक्शन ErrorCode::KEY_REQUIRES_UPGRADE दिखाता है. यहां जाएं: ज़्यादा के लिए वर्शन बाइंडिंग विवरण.

Tag::OS_VERSION

वर्शन: 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

यह टैग, कभी भी पासकोड मैनेजर टीए को नहीं भेजा जाता. हालांकि, इसे टीए, हार्डवेयर से लागू की गई अनुमति की सूची में जोड़ता है.

टैग का मान MMmmss के रूप में पूर्णांक होता है, जहां MM प्रमुख होता है वर्शन नंबर, mm वर्शन नंबर है और ss सब-माइनर वर्शन है जोड़ें. उदाहरण के लिए, Android वर्शन 4.0.3 पर जनरेट की गई कुंजी के लिए, वैल्यू 040003 होगी.

Tag::PADDING

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? हां

यह उन पैडिंग मोड के बारे में बताता है जिनका इस्तेमाल कुंजी के साथ किया जा सकता है. यह टैग, RSA और AES कुंजियों के लिए काम का है.

संभावित वैल्यू, नीचे दिए गए एनोटेशन से तय होती हैं:

Keymaster 3 
enum class PaddingMode : uint32_t {
    NONE = 1,
    RSA_OAEP = 2,
    RSA_PSS = 3,
    RSA_PKCS1_1_5_ENCRYPT = 4,
    RSA_PKCS1_1_5_SIGN = 5,
    PKCS7 = 64,
};
KeyMaster 2 और इससे पहले के वर्शन 
typedef enum {
    KM_PAD_NONE = 1,
    KM_PAD_RSA_OAEP = 2,
    KM_PAD_RSA_PSS = 3,
    KM_PAD_RSA_PKCS1_1_5_ENCRYPT = 4,
    KM_PAD_RSA_PKCS1_1_5_SIGN = 5,
    KM_PAD_PKCS7 = 64,
} keymaster_padding_t;

PaddingMode::RSA_OAEP और PaddingMode::RSA_PKCS1_1_5_ENCRYPT का इस्तेमाल सिर्फ़ आरएसए एन्क्रिप्शन/डिक्रिप्शन कुंजियों के लिए किया जाता है. साथ ही, ये RSA PKCS#1v2 OAEP पैडिंग और RSA PKCS#1 v1.5 रैंडमाइज़्ड पैडिंग के बारे में बताते हैं. PaddingMode::RSA_PSS और PaddingMode::RSA_PKCS1_1_5_SIGN का इस्तेमाल सिर्फ़ आरएसए साइनिंग/पुष्टि करने वाली कुंजियों के लिए किया जाता है. साथ ही, ये आरएसए PKCS#1v2 PSS पैडिंग और आरएसए PKCS#1 v1.5 डिटरमिनिस्टिक पैडिंग के बारे में बताते हैं.

PaddingMode::NONE का इस्तेमाल आरएसए या आरएसए के साथ किया जा सकता है AES कुंजियां. एईएस कुंजियों के लिए, अगर PaddingMode::NONE का इस्तेमाल ब्लॉक मोड ईसीबी या सीबीसी के साथ किया जाता है और एन्क्रिप्ट या डिक्रिप्ट किया जाने वाला डेटा, एईएस ब्लॉक साइज़ के मल्टीपल नहीं है, तो ErrorCode::INVALID_INPUT_LENGTH के साथ फ़िनिश करने का कॉल पूरा नहीं होता.

PaddingMode::PKCS7 का इस्तेमाल सिर्फ़ एईएस कुंजियों के साथ किया जा सकता है. साथ ही, इसका इस्तेमाल सिर्फ़ ईसीबी और सीबीसी मोड के साथ किया जा सकता है.

इस टैग को दोहराया जा सकता है. शुरू करने के लिए, कॉल में पैडिंग मोड की जानकारी देना ज़रूरी है. अगर बताए गए मोड में कुंजी लगाने की अनुमति नहीं है, तो कार्रवाई नहीं हो पाती ErrorCode::INCOMPATIBLE_BLOCK_MODE के साथ.

टैग::PURPOSE

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? हां

उन मकसद के बारे में बताता है जिनके लिए कुंजी का इस्तेमाल किया जा सकता है.

संभावित वैल्यू, यहां दी गई गिनती के आधार पर तय की जाती हैं:

कीमास्टर 3 
enum class KeyPurpose : uint32_t {
    ENCRYPT = 0,
    DECRYPT = 1,
    SIGN = 2,
    VERIFY = 3,
    DERIVE_KEY = 4,  // since 3.0
    WRAP_KEY = 5,    // since 3.0
};
KeyMaster 2 और इससे पहले के वर्शन 
typedef enum {
    KM_PURPOSE_ENCRYPT = 0,
    KM_PURPOSE_DECRYPT = 1,
    KM_PURPOSE_SIGN = 2,
    KM_PURPOSE_VERIFY = 3,
} keymaster_purpose_t;

इस टैग को दोहराया जा सकता है. एक से ज़्यादा वैल्यू के साथ कुंजियां जनरेट की जा सकती हैं. हालांकि, किसी ऑपरेशन का एक ही मकसद होता है. जब begin फ़ंक्शन को कॉल किया जाता है कोई कार्रवाई शुरू करने के लिए, कार्रवाई का मकसद बताया गया है. अगर ऑपरेशन के लिए बताए गए मकसद को पासकोड से अनुमति नहीं दी गई है, तो ऑपरेशन ErrorCode::INCOMPATIBLE_PURPOSE के साथ पूरा नहीं होता.

टैग::RESET_started_ID_ROTATION

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

इससे पता चलता है कि आखिरी बार यूनीक आईडी बदलने के बाद, डिवाइस को फ़ैक्ट्री सेटिंग पर रीसेट किया गया है या नहीं. इसका इस्तेमाल, पासकोड की पुष्टि करने के लिए किया जाता है.

यह टैग बूलियन है, इसलिए संभावित मान सही हैं (अगर टैग मौजूद है) और गलत (अगर टैग मौजूद नहीं है).

टैग::ROLLBACK_RESISTANT

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे पता चलता है कि कुंजी पर रोल बैक नहीं किया जा सकता. इसका मतलब है कि कुंजी को मिटाने पर deleteKey के ज़रिए या deleteAllKeys, कुंजी के हमेशा के लिए मिट जाने और इसका इस्तेमाल करने की गारंटी नहीं है. ऐसा हो सकता है कि इस टैग के बिना कुंजियों को मिटा दिया जाए और फिर बैकअप से वापस लाया जाए.

यह टैग बूलियन है, इसलिए संभावित मान सही हैं (अगर टैग मौजूद है) और गलत (अगर टैग मौजूद नहीं है).

Tag::ROOT_OF_TRUST

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

रूट ऑफ़ ट्रस्ट की जानकारी देता है. यह वह कुंजी होती है जिसका इस्तेमाल, पुष्टि किए गए बूट की सुविधा, बूट किए गए ऑपरेटिंग सिस्टम (अगर कोई हो) की पुष्टि करने के लिए करती है. यह टैग, मुख्य विशेषताओं में Keymaster को कभी नहीं दिया जाता या उससे कभी नहीं लौटाया जाता.

Tag::RSA_PUBLIC_EXPONENT

वर्शन: 1, 2, 3, 4

दोहराया जा सकता है? नहीं

यह किसी आरएसए कुंजी जोड़े के लिए, सार्वजनिक एक्सपोनेंट की वैल्यू बताता है. यह टैग है यह सिर्फ़ आरएसए कुंजियों के लिए काम का है और सभी आरएसए कुंजियों के लिए ज़रूरी है.

यह वैल्यू, 64-बिट का बिना साइन वाला पूर्णांक होता है. यह वैल्यू, आरएसए पब्लिक एक्सपोनेंट की ज़रूरी शर्तों को पूरा करता है. यह वैल्यू कोई अभाज्य संख्या होनी चाहिए. ट्रस्टलेट वैल्यू 2^16+1 है और वह दूसरी उचित वैल्यू दिखा सकती है, खास तौर पर वैल्यू 3. यदि कोई घातांक तय नहीं है या तय घातांक समर्थित नहीं है, तो ErrorCode::INVALID_ARGUMENT के साथ कुंजी नहीं बनाना.

Tag::UNIQUE_ID

वर्शन: 3, 4

दोहराया जा सकता है? नहीं

इसका इस्तेमाल, प्रमाणित करने के लिए यूनीक आईडी देने के लिए किया जाता है.

वैल्यू एक BLOB है, जो बाइट की आर्बिट्रेरी लंबाई वाला कलेक्शन है.

Tag::USAGE_EXPIRE_DATETIME

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इससे उस तारीख और समय के बारे में पता चलता है जब पुष्टि करने और डिक्रिप्ट करने के लिए, पासकोड की समयसीमा खत्म हो जाती है. इसके बाद, अगर किसी कुंजी का इस्तेमाल किया जा रहा है, तो मुख्य मकसद::पुष्टि करें या मुख्य मकसद::decRYPT इन कामों के लिए दिया गया शुरुआत नहीं हो पाई ErrorCode::KEY_EXPIRED के साथ.

यह वैल्यू 64-बिट का पूर्णांक होती है, जो 1 जनवरी, 1970 से लेकर अब तक के मिलीसेकंड दिखाती है.

टैग::USER_AUTH_TYPE

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? नहीं

इस नीति से पता चलता है कि उपयोगकर्ता की पुष्टि करने वाले किस तरह के टूल इस्तेमाल किए जा सकते हैं बटन दबाएं. जब Keymaster से इस टैग वाली कुंजी का इस्तेमाल करके कोई कार्रवाई करने के लिए कहा जाता है, तो उसे पुष्टि करने वाला टोकन मिलता है. साथ ही, टोकन के authenticator_type फ़ील्ड की वैल्यू, टैग में मौजूद वैल्यू से मेल खानी चाहिए. उदाहरण के लिए, (ntoh(token.authenticator_type) & auth_type_tag_value) != 0, जहां ntoh एक फ़ंक्शन है, जो नेटवर्क के क्रम में लगाए गए पूर्णांकों को होस्ट के क्रम में लगाए गए पूर्णांकों में बदलता है और auth_type_tag_value इस टैग की वैल्यू है.

यह वैल्यू, एन्यूमरेशन की वैल्यू का 32-बिट इंटिजर बिटमास्क है:

कीमास्टर 3 
enum class HardwareAuthenticatorType : uint32_t {
    NONE = 0u, // 0
    PASSWORD = 1 << 0,
    FINGERPRINT = 1 << 1,
    ANY = UINT32_MAX,
};
KeyMaster 2 और इससे पहले के वर्शन 
typedef enum {
    HW_AUTH_NONE = 0,
    HW_AUTH_PASSWORD = 1 << 0,
    HW_AUTH_FINGERPRINT = 1 << 1,
    // Additional entries should be powers of 2.
    HW_AUTH_ANY = UINT32_MAX,
} hw_authenticator_type_t;

Tag::USER_SECURE_ID

वर्शन: 1, 2, 3, 4

क्या इसे दोहराया जा सकता है? हां

इससे पता चलता है कि किसी कुंजी का इस्तेमाल, सिर्फ़ उपयोगकर्ता की पुष्टि करने के लिए, सुरक्षित तरीके से किया जा सकता है. यह टैग म्यूचुअली एक्सक्लूसिव है टैग::NO_AUTH_REQUIRED के साथ.

यह वैल्यू 64-बिट का पूर्णांक होती है, जो पुष्टि करने की नीति की स्थिति की वैल्यू बताती है. इस वैल्यू को पुष्टि करने वाले टोकन में मौजूद होना चाहिए, ताकि कुंजी के इस्तेमाल की अनुमति दी जा सके. Tag::AUTH_TOKEN से शुरू करने के लिए, यह टोकन दिया जाता है. इस टैग वाली ऐसी कुंजी के साथ शुरू करें कॉल करने पर, पुष्टि करने वाला टोकन नहीं मिलता या नीति की स्थिति से मैच करने वाली वैल्यू के बिना पुष्टि करने वाला टोकन मिलता है.

इस टैग को दोहराया जा सकता है. अगर दी गई कोई भी वैल्यू, पुष्टि करने वाले टोकन में मौजूद नीति की किसी भी वैल्यू से मेल खाती है, तो पासकोड का इस्तेमाल करने की अनुमति दी जाती है. अगर ऐसा नहीं होता है, तो कार्रवाई इसके साथ पूरी नहीं हो पाती ErrorCode::KEY_USER_NOT_AUTHENTICATED.

टैग::विक्रेता_PATCHLEVEL

वर्शन: 4

यह टैग, वेंडर इमेज के लिए सिक्योरिटी पैच लेवल के बारे में बताता है, जिसमें कुंजी इस्तेमाल किया जा सकता है. यह टैग कभी भी keyMaster TA को नहीं भेजा जाता, बल्कि इसे टीए की ओर से हार्डवेयर-लागू होने वाली अनुमति की सूची. अगर किसी ऐसी कुंजी का इस्तेमाल किया जाता है जिसकी Tag::VENDOR_PATCHLEVEL वैल्यू, फ़िलहाल चल रहे सिस्टम के पैच लेवल से अलग है, तो begin(), getKeyCharacteristics() या exportKey() के तौर पर ErrorCode::KEY_REQUIRES_UPGRADE दिखेगा. upgradeKey() देखें देखें.

टैग की वैल्यू, YYYYMMDD फ़ॉर्मैट में एक पूर्णांक होती है. इसमें YYYY, आखिरी अपडेट के साल के चार अंक होते हैं, MM, महीने के दो अंक होते हैं, और DD, आखिरी अपडेट के दिन के दो अंक होते हैं. उदाहरण के लिए, अगर किसी Android डिवाइस पर जनरेट की गई पासकोड की वैल्यू 5 जून, 2018 को अपडेट की गई थी, तो उसकी वैल्यू 20180605 होगी.

IKeymasterDevice HAL को सिस्टम प्रॉपर्टी ro.vendor.build.security_patch से, वेंडर का मौजूदा पैच लेवल पढ़ना होगा. साथ ही, HAL को पहली बार लोड होने पर, उसे सुरक्षित एनवायरमेंट में डिलीवर करना होगा. यह तरीका, लागू करने के तरीके के हिसाब से तय किया जाता है. अगले बूट होने तक, सुरक्षित एनवायरमेंट में कोई दूसरा पैच लेवल स्वीकार नहीं किया जाना चाहिए.

हार्डवेयर की मदद से लागू होना चाहिए.