कीमास्टर के फ़ंक्शन

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

लागू करने के सामान्य दिशा-निर्देश

एपीआई में मौजूद सभी फ़ंक्शन पर नीचे दिए गए दिशा-निर्देश लागू होते हैं.

इनपुट पॉइंटर पैरामीटर

वर्शन: 1, 2

ऐसे इनपुट पॉइंटर पैरामीटर जो किसी दिए गए कॉल के लिए इस्तेमाल नहीं किए गए हैं, वे हो सकते हैं NULL. कॉलर को प्लेसहोल्डर देने की ज़रूरत नहीं है. उदाहरण के लिए, हो सकता है कि कुछ कुंजी टाइप और मोड, inParams आर्ग्युमेंट शुरू करने के लिए, ताकि कॉलर हो सकता है inParams को NULL पर सेट करें या कोई खाली पैरामीटर दें सेट. कॉलर, इस्तेमाल न किए गए पैरामीटर भी दे सकते हैं और KeyMaster तरीकों को नहीं होने चाहिए.

अगर ज़रूरी इनपुट पैरामीटर शून्य है, तो कीमास्टर तरीके से काम करना चाहिए ErrorCode::UNEXPECTED_NULL_POINTER.

कीमास्टर 3 से शुरू होने वाला कोई पॉइंटर पैरामीटर नहीं होता. सभी पैरामीटर को वैल्यू या कॉन्सट रेफ़रंस के ज़रिए पास किया जाता है.

आउटपुट पॉइंटर के पैरामीटर

वर्शन: 1, 2

इनपुट पॉइंटर पैरामीटर की तरह ही, इस्तेमाल नहीं किए गए आउटपुट पॉइंटर पैरामीटर NULL हो सकती है. अगर किसी तरीके को आउटपुट में डेटा देना हो पैरामीटर NULL मिला, यह वापस आना चाहिए ErrorCode::OUTPUT_PARAMETER_NULL.

कीमास्टर 3 से शुरू होने वाला कोई पॉइंटर पैरामीटर नहीं होता. सभी पैरामीटर को वैल्यू या कॉन्सट रेफ़रंस के ज़रिए पास किया जाता है.

एपीआई का गलत इस्तेमाल

वर्शन: 1, 2, 3

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

ऐप्लिकेशन, फ़्रेमवर्क, और Android कीस्टोर की ज़िम्मेदारी है कि यह सुनिश्चित करना चाहिए कि KeyMaster मॉड्यूल को किए जाने वाले कॉल सही और उपयोगी हैं.

फ़ंक्शन

हार्डवेयर की सुविधाएं पाएं

वर्शन: 3

getHardwareFeatures के नए तरीके से, कुछ क्लाइंट को में मौजूद सिक्योर हार्डवेयर की खास विशेषताओं के बारे में बताया है. यह तरीका कोई तर्क नहीं लेता और चार मान दिखाता है, यानी सभी बूलियन:

  • अगर कुंजियां यहां सेव की जाती हैं, तो isSecure true है जैसे कि वे सुरक्षित हार्डवेयर (TEE वगैरह) को सुरक्षित रखते हैं और इसे कभी नहीं रखते.
  • supportsEllipticCurve true है, अगर हार्डवेयर, एनआईएसटी कर्व (P-224, P-256, P-384, और P-521).
  • supportsSymmetricCryptography true है अगर हार्डवेयर, एईएस और एचएमएसी के साथ-साथ सिमेट्रिक क्रिप्टोग्राफ़ी का इस्तेमाल करता है.
  • supportsAttestation true है, अगर हार्डवेयर, KeyMaster सार्वजनिक पासकोड की पुष्टि करने के सर्टिफ़िकेट जनरेट करने की सुविधा देता है, सुरक्षित तरीके से इंजेक्ट की गई कुंजी से साइन किया जाता है.

इस तरीके से सिर्फ़ ErrorCode:OK गड़बड़ी कोड दिख सकते हैं. ErrorCode::KEYMASTER_NOT_CONFIGURED या कोई एक गड़बड़ी कोड जो सुरक्षित हार्डवेयर के साथ संपर्क करने में गड़बड़ी का संकेत देता है.

getHardwareFeatures()
    generates(bool isSecure, bool supportsEllipticCurve, bool supportsSymmetricCryptography,
              bool supportsAttestation, bool supportsAllDigests, string keymasterName,
              string keymasterAuthorName);

कॉन्फ़िगर करो

वर्शन: 2

यह फ़ंक्शन KeyMaster 2 में शुरू किया गया था और KeyMaster में इसे बंद कर दिया गया था 3, क्योंकि यह जानकारी सिस्टम की प्रॉपर्टी फ़ाइलों और मैन्युफ़ैक्चरर से लागू करने की सुविधा, स्टार्टअप के दौरान उन फ़ाइलों को पढ़ती है.

कीमास्टर को कॉन्फ़िगर करता है. डिवाइस खोलने के बाद, इस तरीके का इस्तेमाल सिर्फ़ एक बार किया जाता है और इस्तेमाल करने से पहले कर लें. इसका इस्तेमाल इन कामों के लिए किया जाता है KM_TAG_OS_VERSION और KM_TAG_OS_PATCHLEVEL से कीमास्टर. जब तक इस तरीके को कॉल नहीं किया जाता, तब तक दूसरे सभी तरीके वापस आते हैं KM_ERROR_KEYMASTER_NOT_CONFIGURED. इसके ज़रिए दिए गए मान तरीके को कीमास्टर हर बूट के लिए सिर्फ़ एक बार स्वीकार करते हैं. बाद का कॉल KM_ERROR_OK लौटाते हैं, लेकिन कुछ नहीं करते.

अगर पासकोड को लागू करने का तरीका, सुरक्षित हार्डवेयर और ओएस वर्शन में है और पैच लेवल की वैल्यू, सुरक्षित बूटलोडर का हार्डवेयर (या अगर बूटलोडर ने वैल्यू न दी हो), तो यह तरीका KM_ERROR_INVALID_ARGUMENT और बाकी सभी नतीजे दिखाता है तरीके KM_ERROR_KEYMASTER_NOT_CONFIGURED लौटाते रहते हैं.

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
                               const keymaster_key_param_set_t* params);

ऐडRngEntropy

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में add_rng_entropy के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

यह विकल्प, कॉलर की दी गई एंट्रॉपी को उस पूल में जोड़ता है जिसका इस्तेमाल KeyMaster 1 को लागू करने के लिए किया जाता है कुंजियों, IVs वगैरह के लिए रैंडम नंबर जनरेट करने के लिए.

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

Key पता लगाने की टेक्नोलॉजी की मदद से, एंट्रॉपी का अनुमान लगाने की कोशिश करते हैं आंतरिक पूल को यह मान लिया जाता है कि addRngEntropy में कोई एंट्रॉपी नहीं है. KeyMaster लागू करने की सुविधा अगर दो से ज़्यादा वैल्यू दी जाती हैं, तो ErrorCode::INVALID_INPUT_LENGTH वापस करना एक कॉल में डेटा का KiB.

जनरेट की

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में generate_key के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

नई क्रिप्टोग्राफ़िक कुंजी जनरेट करता है, जिसमें इससे जुड़ी अनुमतियां तय की जाती हैं, जो हमेशा कुंजी से जुड़े रहते हैं. KeyMaster लागू करने की सुविधा से यह काम करना आसान बनाता है ऐसे किसी भी तरीके से कुंजी का इस्तेमाल करना मुमकिन नहीं है जो अनुमति देने के हिसाब से सही न हो जेनरेशन समय पर दर्ज किया गया है. ऐसे प्राधिकरणों के संबंध में जिन्हें सुरक्षित हार्डवेयर लागू नहीं कर सकता, सुरक्षित हार्डवेयर की जवाबदेही यह पक्का करना कि कुंजी के साथ जुड़े, लागू न किए जा सकने वाले प्राधिकरण, बदला जा सकता है, ताकि getKeyCharacteristics मूल वैल्यू दिखाता है. इसके अलावा, इसके ज़रिए दिखाई गई विशेषताएं generateKey हार्डवेयर-प्रवर्तित और सॉफ़्टवेयर-प्रवर्तित सूचियां. यहां जाएं: ज़्यादा जानकारी के लिए, getKeyCharacteristics.

generateKey के लिए दिए गए पैरामीटर, इस बात पर निर्भर करते हैं कि कुंजी किस तरह की है जनरेट किए जा रहे हैं. इस सेक्शन में, विज्ञापन देने वालों के लिए ज़रूरी और वैकल्पिक टैग की खास जानकारी दी गई है का उपयोग कर रहे हैं. टैग::एल्गोरिदम हमेशा आवश्यक होता है, ताकि टाइप बताया जा सके.

आरएसए कुंजियां

आरएसए कुंजी जनरेट करने के लिए, ये पैरामीटर ज़रूरी हैं.

  • टैग::KEY_SIZE सार्वजनिक मॉड्यूलस का साइज़ बिट में बताता है. अगर इसे छोड़ दिया जाता है, तो यह तरीका ErrorCode::UNSUPPORTED_KEY_SIZE दिखाता है. इसके लिए, 1024, 2048, 3072, और 4096 वैल्यू डाली जा सकती हैं. सुझाई गई वैल्यू सभी मुख्य साइज़ हैं जो आठ के मल्टीपल हैं.
  • टैग::RSA_PUBLIC_EXPONENT आरएसए की पब्लिक एक्सपोनेंट वैल्यू तय करता है. अगर इसे छोड़ दिया जाता है, तो यह तरीका ErrorCode::INVALID_ARGUMENT दिखाता है. इसके लिए, 3 और 65537 वैल्यू का इस्तेमाल किया जा सकता है. सुझाई गई वैल्यू ये हैं 2^64 तक की सभी प्राइम वैल्यू.

आरएसए कुंजी जनरेट करने के लिए, इन पैरामीटर की ज़रूरत नहीं है, लेकिन उनके बिना आरएसए कुंजी बनाने से, ऐसी कुंजी बनती है जो इस्तेमाल नहीं की जा सकती. हालांकि, अगर ये पैरामीटर हैं, तो generateKey फ़ंक्शन गड़बड़ी नहीं दिखाता है शामिल नहीं किए गए हैं.

  • Tag::PURPOSE से पता चलता है अनुमति नहीं है. आरएसए कुंजियों के लिए सभी मकसद काम करने चाहिए कोई भी कॉम्बिनेशन इस्तेमाल करें.
  • टैग::DIGEST से पता चलता है डाइजेस्ट एल्गोरिदम, जिन्हें नई कुंजी के साथ इस्तेमाल किया जा सकता है. लागू करना जो डाइजेस्ट एल्गोरिदम के साथ काम नहीं करते हैं उन्हें कुंजी जनरेट करने की प्रोसेस को स्वीकार करना होगा ऐसे अनुरोध जिनमें काम न करने वाले डाइजेस्ट शामिल हैं. काम न करने वाले डाइजेस्ट होने चाहिए सॉफ़्टवेयर के नियंत्रण में होने की वजह से की जानकारी दी गई है. ऐसा इसलिए है, क्योंकि अन्य डाइजेस्ट के साथ कुंजी का उपयोग किया जा सकता है, लेकिन डाइजेस्टिंग सॉफ़्टवेयर के मामले में ऐसा किया गया. इसके बाद, कार्रवाई करने के लिए हार्डवेयर को कॉल किया जाता है Digest::NONE के साथ.
  • Tag::PADDING, कन्वर्ज़न ट्रैकिंग की रणनीति का इस्तेमाल पैडिंग मोड जिन्हें नई कुंजी के साथ इस्तेमाल किया जा सकता है. लागू करना जो डाइजेस्ट एल्गोरिदम के साथ काम नहीं करते हैं उन्हें PaddingMode::RSA_PSS और PaddingMode::RSA_OAEP इंच अगर काम का नहीं है, तो सॉफ़्टवेयर की मदद से लागू की गई मुख्य विशेषताओं की सूची डाइजेस्ट एल्गोरिदम की जानकारी दी गई है.

ECDSA कुंजियां

सिर्फ़ टैग::KEY_SIZE ECDSA कुंजी जनरेट करने के लिए ज़रूरी है. इसका इस्तेमाल ईसी ग्रुप को चुनने के लिए किया जाता है. इसका मान 224, 256, 384, और 521 है, जिससे पता चलता है कि एनआईएसटी p-224, p-256, p-384, और p521 कर्व क्रम से.

टैग::DIGEST एक उपयोगी ECDSA कुंजी के लिए भी ज़रूरी है, हालांकि, जनरेट करने के लिए इसकी ज़रूरत नहीं है.

AES कुंजियां

सिर्फ़ टैग::KEY_SIZE AES कुंजी जनरेट करने के लिए ज़रूरी है. अगर इसे छोड़ दिया जाता है, तो यह तरीका वापस आ जाता है ErrorCode::UNSUPPORTED_KEY_SIZE. इन वैल्यू का इस्तेमाल किया जा सकता है 128 और 256, 192-बिट AES कुंजियों के लिए वैकल्पिक सहायता के साथ.

नीचे दिए गए पैरामीटर खास तौर पर AES कुंजियों के लिए काम के हैं, लेकिन इसे जनरेट करने के लिए ज़रूरी है:

  • Tag::BLOCK_MODE में उन ब्लॉक मोड के बारे में बताया जाता है जिनसे तो नई कुंजी का इस्तेमाल किया जा सकता है.
  • Tag::PADDING में पैडिंग मोड के बारे में बताया गया है, जो इस्तेमाल किया गया. यह सिर्फ़ ईसीबी और सीबीसी मोड के लिए काम का है.

यदि GCM ब्लॉक मोड तय किया गया है, तो टैग::MIN_MAC_LENGTH. अगर इसे छोड़ दिया जाता है, तो यह तरीका ErrorCode::MISSING_MIN_MAC_LENGTH दिखाता है. टैग की वैल्यू 8 का गुणांक है और यह 96 और 128 के बीच होती है.

एचएमएसी बटन

एचएमएसी कुंजी जनरेट करने के लिए ये पैरामीटर ज़रूरी हैं:

  • टैग::KEY_SIZE कुंजी का साइज़ बिट में बताता है. वैल्यू 64 से कम है और वे वैल्यू जो 8 के मल्टीपल नहीं हैं, उन्हें इस्तेमाल नहीं किया जा सकता. सभी वैल्यू 6 (64 से 512) के बीच के 8 के मल्टीपल का इस्तेमाल किया जा सकता है. बड़े मान समर्थित हैं.
  • टैग::MIN_MAC_LENGTH तय की गई कम से कम लंबाई इस कुंजी से जनरेट किए जा सकने वाले या इसकी पुष्टि करने वाले MAC. मान एक है 8 और कम से कम 64 का मल्टीपल.
  • टैग::DIGEST इस कुंजी के लिए डाइजेस्ट एल्गोरिदम तय करता है. सटीक एक डाइजेस्ट चुना गया है, नहीं तो वापस करें ErrorCode::UNSUPPORTED_DIGEST. अगर डाइजेस्ट काम नहीं कर रहा है ट्रस्टलेट की मदद से, वापस जाएं ErrorCode::UNSUPPORTED_DIGEST.

मुख्य विशेषताएं

अगर विशेषता तर्क शून्य या शून्य नहीं है, तो generateKey फ़ंक्शन को नतीजे के तौर पर दिखाता है जनरेट की गई नई कुंजी की विशेषताओं को, कैटगरी में सही तरीके से बांटा गया है हार्डवेयर-प्रवर्तित और सॉफ़्टवेयर-प्रवर्तित सूचियां. यहां जाएं: ब्यौरे के लिए getKeyCharacteristics किन विशेषताओं को किस सूची में शामिल किया जाए. प्रॉडक्ट की खासियतों से मिले नतीजे कुंजी जेनरेशन के लिए तय किए गए सभी पैरामीटर शामिल करें, सिवाय इसके कि टैग::APPLICATION_ID और टैग::APPLICATION_DATA. अगर ये टैग मुख्य पैरामीटर में शामिल किए गए थे, तो वे यहां से हटा दिए जाते हैं ताकि उनके मान को खोजा न जा सके इसके लिए, रिटर्न की गई कुंजी की ब्लॉब की जांच की जाती है. हालांकि, ये क्रिप्टोग्राफ़िक तौर पर होते हैं आप कुंजी ब्लॉब तक ले जा सकते हैं, ताकि कुंजी के ठीक बाद में इस्तेमाल नहीं किया गया. इसी तरह, टैग::ROOT_OF_TRUST कुंजी को क्रिप्टोग्राफ़िक तौर पर जोड़ा गया है, लेकिन हो सकता है कि इसे कुंजी बनाने या इंपोर्ट करने की सुविधा मिलती है और इसे कभी वापस नहीं लाया जाता.

दिए गए टैग के अलावा, ट्रस्टलेट टैग::ऑरिजिन जोड़ता है, इसका मान KeyOrigin::GENERATED है, और अगर कुंजी को रोलबैक से बचने की क्षमता है,

टैग::ROLLBACK_RESISTANT.

रोलबैक रेज़िस्टेंस (कुंजी का दोबारा इस्तेमाल न हो पाना)

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

अगर सुरक्षित हार्डवेयर कॉन्टेंट को मिटाने की गारंटी देता है, तो कुंजी का रोलबैक नहीं होता कुंजियों को बाद में वापस नहीं लाया जा सकता. आम तौर पर एक और कुंजी सेव करके ऐसा किया जाता है किसी भरोसेमंद जगह पर मौजूद ऐसा मेटाडेटा जिसमें कोई हमलावर छेड़छाड़ न कर सके. चालू है है, तो इसके लिए इस्तेमाल किया जाने वाला तरीका आम तौर पर, सुरक्षित मेमोरी को फिर से चलाएं ब्लॉक (RPMB). क्योंकि बनाई जा सकने वाली कुंजियों की संख्या ज़रूरी है अनबाउंड है. साथ ही, रोलबैक रेज़िस्टेंस के लिए इस्तेमाल होने वाला भरोसेमंद स्टोरेज सीमित हो सकता है तो इस तरीके को कामयाब होने की ज़रूरत है. भले ही, रॉलबैक रेज़िस्टेंस हो नई कुंजी के लिए नहीं दिया जा सकता. ऐसी स्थिति में, टैग::ROLLBACK_RESISTANT को मुख्य विशेषताओं में नहीं जोड़ा जाना चाहिए.

'GetKeyKeyCharacteristics')

वर्शन: 1, 2, 3

इस फ़ंक्शन को कीमास्टर 1 में इस तौर पर पेश किया गया था get_key_characteristics में अपग्रेड किया गया है और इसका नाम KeyMaster 3 में बदला गया है.

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

अगर कुंजी जनरेट करने के दौरान Tag::APPLICATION_ID दिया गया था या आयात करते हैं, तो वही मान clientId आर्ग्युमेंट में इस तरीके का इस्तेमाल करें. या फिर, तरीका ErrorCode::INVALID_KEY_BLOB दिखाता है. इसी तरह, अगर Tag::APPLICATION_DATA जनरेशन के दौरान दिया गया था या आयात करते हैं, तो वही मान appData आर्ग्युमेंट में इस तरीके का इस्तेमाल करें.

इस विधि से मिलने वाली विशेषताएं, बताई गई कुंजी का इस्तेमाल.

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

  • Tag::एल्गोरिदम, टैग::KEY_SIZE, और टैग::RSA_PUBLIC_EXPONENT कुंजी के मूल गुण हैं. हार्डवेयर के ज़रिए सुरक्षित की गई किसी भी कुंजी के लिए, ये टैग हार्डवेयर के ज़रिए लागू की गई सूची में होंगे.
  • टैग::DIGEST वैल्यू जो सुरक्षित हार्डवेयर के साथ काम करते हैं उन्हें इसमें रखा जाता है हार्डवेयर वाले डिवाइसों की सूची. काम न करने वाले डाइजेस्ट, सॉफ़्टवेयर के साथ काम करने वाली सूची में शामिल होते हैं.
  • टैग::PADDING वैल्यू आम तौर पर हार्डवेयर से चलने वाली सूची में शामिल होता है, जब तक कि सॉफ़्टवेयर की मदद से कोई खास पैडिंग मोड लागू करना पड़ सकता है. इस स्थिति में, वे सॉफ़्टवेयर के अनुसार लागू की गई सूची में जाते हैं. ऐसी संभावना यह विकल्प उन आरएसए कुंजियों के लिए पैदा होता है जो डाइजेस्ट एल्गोरिदम के साथ पीएसएस या ओएईपी पैडिंग की अनुमति देती हैं जो सुरक्षित हार्डवेयर पर काम नहीं करते हैं.
  • टैग::USER_SECURE_ID और टैग::USER_AUTH_TYPE हार्डवेयर की मदद से सिर्फ़ तब लागू होती है, जब उपयोगकर्ता की पुष्टि करने की प्रोसेस हार्डवेयर से जुड़ी हो. यहां की यात्रा पर हूं को हासिल करने के लिए, कीमास्टर ट्रस्टलेट और प्रासंगिक प्रमाणीकरण ट्रस्टलेट, दोनों को सुरक्षित रहना चाहिए. साथ ही, एक सीक्रेट एचएमएसी कुंजी शेयर करनी चाहिए जिसका इस्तेमाल हस्ताक्षर करने और पुष्टि करने वाले टोकन की पुष्टि करें. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी के लिए, पुष्टि करने के पेज पर जाएं.
  • टैग::ACTIVE_DATETIME, टैग::OriginATION_EXPIRE_DATETIME, और टैग::USAGE_EXPIRE_DATETIME टैग दीवार पर दी गई सही घड़ी का ऐक्सेस ज़रूरी है. सबसे सुरक्षित हार्डवेयर इसे सिर्फ़ असुरक्षित ओएस से मिले समय की जानकारी का ऐक्सेस मिलता है, का मतलब है कि टैग सॉफ़्टवेयर से जुड़े हैं.
  • टैग::Origin हार्डवेयर सूची में हमेशा शामिल होना चाहिए. समाचार नेटवर्क में इसकी मौजूदगी सूची वह तरीका है जिससे उच्च लेयर यह तय करती हैं कि कोई कुंजी हार्डवेयर-आधारित है.

ImportKey

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में import_key के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

मुख्य सामग्री को कीमास्टर हार्डवेयर में आयात करता है. मुख्य परिभाषा के पैरामीटर और आउटपुट एट्रिब्यूट को उसी तरह मैनेज किया जाता है जैसे generateKey के लिए किया जाता है. इसमें ये अपवाद शामिल हैं:

  • टैग::KEY_SIZE और टैग::RSA_PUBLIC_EXPONENT इनपुट पैरामीटर में (सिर्फ़ आरएसए कुंजियों के लिए) ज़रूरी नहीं है. अगर यह पैरामीटर उपलब्ध नहीं कराया गया है, ट्रस्टलेट, उपलब्ध कराई गई मुख्य कॉन्टेंट से वैल्यू निकालता है और सही टैग और वैल्यू सेट करें. अगर पैरामीटर अगर यह नीति उल्लंघन के दायरे में आती है, तो ट्रस्टलेट की मदद से उस जानकारी की पुष्टि की जाएगी. इस इवेंट मेल नहीं खाता है, तो यह तरीका ErrorCode::IMPORT_PARAMETER_MISMATCH दिखाता है.
  • लौटाए गए टैग::ऑरिजिन में यह एट्रिब्यूट है KeyOrigin::IMPORTED के समान मान.

ExportKey

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में export_key के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

किसी कीमास्टर आरएसए या ईसी कुंजी के जोड़े से सार्वजनिक कुंजी एक्सपोर्ट करता है.

अगर Tag::APPLICATION_ID, कुंजी जनरेट करने के दौरान दिया गया था या आयात करता है, तो इस प्रक्रिया को वही मान दिया जाता है जो clientId आर्ग्युमेंट. अगर ऐसा नहीं होता है, तो यह तरीका ErrorCode::INVALID_KEY_BLOB. इसी तरह, अगर Tag::APPLICATION_DATA अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है जनरेट या इंपोर्ट के दौरान दिया गया था, तो वही वैल्यू appData आर्ग्युमेंट में इस तरीके का इस्तेमाल करें.

DeleteKey

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में delete_key के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

दी गई कुंजी को मिटाता है. यह तरीका ज़रूरी नहीं है. को KeyMaster मॉड्यूल की मदद से लागू किया गया है, जो रोलबैक रेज़िस्टेंस उपलब्ध कराता है.

DeleteAllKeys

वर्शन: 1, 2, 3

यह फ़ंक्शन कीमास्टर 1 में delete_all_keys के रूप में पेश किया गया था और का नाम बदलकर कीमास्टर 3 कर दिया गया है.

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

प्रमाणित करने वाले आईडी बंद करें

वर्शन: 3

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

इस तरीके से सिर्फ़ ये गड़बड़ी कोड दिख सकते हैं: ErrorCode::UNIMPLEMENTED (अगर आईडी की पुष्टि करने की सुविधा काम नहीं करती है), ErrorCode:OK, ErrorCode::KEYMASTER_NOT_CONFIGURED या इनमें से एक गड़बड़ी कोड है, जो बताता है कि सुरक्षित सिग्नल की मदद से कम्यूनिकेट करने में हार्डवेयर.

शुरू करें

वर्शन: 1, 2, 3

खास जानकारी के लिए, बताई गई कुंजी का इस्तेमाल करके क्रिप्टोग्राफ़िक ऑपरेशन शुरू करता है का इस्तेमाल करता है, और ऑपरेशन हैंडल, जिसका इस्तेमाल कार्रवाई पूरी करने के लिए अपडेट और खत्म के साथ किया जाता है. यह ऑपरेशन हैंडल है इसे "चैलेंज" के तौर पर भी इस्तेमाल किया जाता है पुष्टि की गई कार्रवाइयों में टोकन शामिल है और ऑपरेशन को इसके challenge फ़ील्ड में शामिल किया जाता है पुष्टि करने वाला टोकन.

KeyMaster लागू करने की सुविधा, एक साथ कम से कम 16 खातों के साथ काम करती है कार्रवाइयां. कीस्टोर 15 तक का उपयोग करता है, एक को पासवर्ड के लिए उपयोग करने के लिए vold के लिए छोड़ दिया जाता है एन्क्रिप्ट करने का तरीका. जब कीस्टोर में 15 कार्रवाइयां चल रही हों (begin ने कॉल किया गया है, लेकिन finish या abort को अब तक कॉल किया जाता है) और उसे 16 तारीख शुरू करने का अनुरोध मिलता है, abort हाल ही में इस्तेमाल किए गए ऑपरेशन पर begin को कॉल करने से पहले, 14 पर ऐक्टिव ऑपरेशन शुरू करें नई कार्रवाई का अनुरोध किया गया.

अगर टैग::APPLICATION_ID या Tag::APPLICATION_DATA के बारे में बताया गया था कुंजी जनरेट या इंपोर्ट करने के दौरान, begin को किए गए कॉल में वे शामिल होते हैं inParams आर्ग्युमेंट में मूल रूप से बताई गई वैल्यू के साथ टैग इस तरीके का इस्तेमाल करें.

अनुमति लागू करने का तरीका

इस विधि के दौरान, ट्रस्टलेट, अगर लागू करने की प्रोसेस से उन्हें "हार्डवेयर से लागू" में रखा जाता है विशेषताओं के साथ-साथ यह भी बताएं कि वह कार्रवाई सार्वजनिक पासकोड से जुड़ी कार्रवाई नहीं है. सार्वजनिक पासकोड ऑपरेशन, मतलब KeyPurpose::ENCRYPT और KeyPurpose::VERIFY, वे आरएसए या ईसी कुंजियों के साथ काम करते हों, जिन्हें अनुमति मिलने के बावजूद सफल हो ज़रूरी शर्तें पूरी नहीं की गई हैं.

  • Tag::PURPOSE: मकसद begin() कॉल में बताए गए मकसद में से किसी एक से मैच होना चाहिए कुंजी की अनुमतियों में, जब तक कि अनुरोध की गई कार्रवाई एक सार्वजनिक कुंजी न हो कार्रवाई. अगर बताया गया मकसद मेल नहीं खाता है और कार्रवाई सार्वजनिक पासकोड से जुड़ी कार्रवाई करने पर, begin वापस आ जाएगा ErrorCode::UNSUPPORTED_PURPOSE. सार्वजनिक पासकोड से जुड़ी कार्रवाइयां एसिमेट्रिक एन्क्रिप्शन या पुष्टि करने की कार्रवाइयां.
  • टैग::ACTIVE_DATETIME को सिर्फ़ तब लागू किया जा सकता है, जब कोई भरोसेमंद यूटीसी टाइम सोर्स उपलब्ध हो. अगर वर्तमान तारीख और समय टैग मान से पहले का है, तो विधि वापस ErrorCode::KEY_NOT_YET_VALID.
  • टैग::OriginATION_EXPIRE_DATETIME को सिर्फ़ तब लागू किया जा सकता है, जब कोई भरोसेमंद यूटीसी टाइम सोर्स उपलब्ध हो. अगर वर्तमान तारीख और समय टैग मान के बाद का है और उद्देश्य यह है KeyPurpose::ENCRYPT या KeyPurpose::SIGN, तरीका ErrorCode::KEY_EXPIRED दिखाता है.
  • टैग::USAGE_EXPIRE_DATETIME को सिर्फ़ तब लागू किया जा सकता है, जब कोई भरोसेमंद यूटीसी टाइम सोर्स उपलब्ध हो. अगर वर्तमान तारीख और समय टैग मान के बाद का है और उद्देश्य यह है KeyPurpose::DECRYPT या KeyPurpose::VERIFY, तरीका ErrorCode::KEY_EXPIRED दिखाता है.
  • टैग::MIN_SECONDS_BETWEEN_OPS की तुलना एक भरोसेमंद रिलेटिव टाइमर से की जाती है, जो बताता है कि आखिरी बार सुरक्षा कुंजी. अगर आखिरी बार इस्तेमाल किए जाने का समय और टैग की वैल्यू, मौजूदा समय से कम है, यह तरीका ErrorCode::KEY_RATE_LIMIT_EXCEEDED दिखाता है. ज़्यादा जानकारी के लिए, टैग का ब्यौरा पर जाएं.
  • टैग::MAX_USES_PER_BOOT की तुलना एक ऐसे सुरक्षित काउंटर से की जाती है जो कुंजी के इस्तेमाल को ट्रैक करता है बूट समय के बाद से. अगर पिछले इस्तेमाल की संख्या टैग की वैल्यू से ज़्यादा है, तो तरीका ErrorCode::KEY_MAX_OPS_EXCEEDED दिखाता है.
  • टैग::USER_SECURE_ID इस तरीके से सिर्फ़ तब लागू किया जाता है, जब कुंजी में टैग::AUTH_SECONDS. अगर कुंजी में दोनों हैं, तो इस तरीके को Tag::AUTH_TOKEN inParams. पुष्टि करने वाला टोकन मान्य होने के लिए, ये सभी काम करें सत्य होना चाहिए:
    • एचएमएसी फ़ील्ड सही तरीके से पुष्टि करता है.
    • कम से कम एक टैग::USER_SECURE_ID कुंजी में मौजूद मान कम से कम एक सुरक्षित आईडी टोकन.
    • कुंजी में टैग::USER_AUTH_TYPE जो टोकन में मौजूद ऑथराइज़ेशन टाइप से मेल खाता हो.

    अगर इनमें से कोई भी शर्त पूरी नहीं होती, तो यह तरीका वापस इस्तेमाल किया जाता है ErrorCode::KEY_USER_NOT_AUTHENTICATED.

  • टैग::CALLER_NONCE कॉलर को नॉन्स या इनिशलाइज़ेशन वेक्टर (IV) तय करने की अनुमति देता है. अगर कुंजी के पास यह टैग नहीं है, लेकिन कॉलर ने दिया है इस तरीके से Tag::NONCE किया जा सकता है, ErrorCode::CALLER_NONCE_PROHIBITED लौटाया जाता है.
  • टैग::BOOTLOADER_ONLY इससे पता चलता है कि कुंजी का इस्तेमाल सिर्फ़ बूटलोडर कर सकता है. अगर यह तरीका जब बूटलोडर का काम पूरा हो जाने के बाद, सिर्फ़ बूटलोडर वाली कुंजी का इस्तेमाल किया जाता है, यह ErrorCode::INVALID_KEY_BLOB दिखाता है.

आरएसए कुंजियां

आरएसए कुंजी से जुड़ी सभी कार्रवाइयां, inParams में सिर्फ़ एक पैडिंग मोड के बारे में बताती हैं. अगर कोई जानकारी नहीं दी गई है या एक से ज़्यादा बार बताया गया है, तो तरीका ErrorCode::UNSUPPORTED_PADDING_MODE.

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

निजी पासकोड से जुड़ी कार्रवाइयां (KeyPurpose::DECYPT और KeyPurpose::SIGN) को डाइजेस्ट और पैडिंग के लिए अनुमति की ज़रूरत होती है, इसका मतलब है कि मुख्य ऑथराइज़ेशन इसमें तय किए गए मान शामिल होने चाहिए. अगर ऐसा नहीं है, तो यह तरीका इस्तेमाल करने पर ErrorCode::INCOMPATIBLE_DIGEST अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है या ErrorCode::INCOMPATIBLE_PADDING, जैसा उचित हो. सार्वजनिक पासकोड से जुड़ी कार्रवाइयां (KeyPurpose::ENCRYPT और KeyPurpose::VERIFY) को इनके साथ अनुमति है बिना अनुमति के डाइजेस्ट या पैडिंग.

PaddingMode::NONE को छोड़कर, सभी आरएसए पैडिंग मोड और विज्ञापन सिर्फ़ कुछ मकसद के लिए ही लागू होते हैं. खास तौर पर, PaddingMode::RSA_PKCS1_1_5_SIGN और PaddingMode::RSA_PSS सिर्फ़ हस्ताक्षर और पुष्टि करने की सुविधा मिलती है, PaddingMode::RSA_PKCS1_1_1_5_ENCRYPT पर और PaddingMode::RSA_OAEP में सिर्फ़ एन्क्रिप्ट (सुरक्षित) करने और डिक्रिप्ट करने की सुविधा काम करती है. यह तरीका ErrorCode::UNSUPPORTED_PADDING_MODE दिखाता है, अगर बताए गए मोड में बताए गए मकसद को पूरा नहीं किया जा सकता.

पैडिंग मोड और डाइजेस्ट के बीच कुछ अहम इंटरैक्शन होते हैं:

  • PaddingMode::NONE बताता है कि "रॉ" आरएसए ऑपरेशन है प्रदर्शन किया. अगर हस्ताक्षर कर रहे हैं या पुष्टि कर रहे हैं, तो Digest::NONE डाइजेस्ट के लिए तय किया गया. बिना पैड वाले एन्क्रिप्ट (सुरक्षित) करने के तरीके के लिए, कोई डाइजेस्ट ज़रूरी नहीं है या डिक्रिप्शन.
  • PaddingMode::RSA_PKCS1_1_5_SIGN पैडिंग के लिए, डाइजेस्ट की ज़रूरत होती है. कॉन्टेंट बनाने डाइजेस्ट Digest::NONE हो सकता है और इस मामले में कीमास्टर लागू करने पर PKCS#1 v1.5 के हस्ताक्षर का सही स्ट्रक्चर नहीं बनाया जा सकेगा, क्योंकि यह DigstInfo स्ट्रक्चर को नहीं जोड़ सकता. इसके बजाय, लागू करने का तरीका 0x00 || 0x01 || PS || 0x00 || M का निर्माण करता है, जहां M दिया गया मैसेज और PS पैडिंग स्ट्रिंग है. आरएसए कुंजी का साइज़ फ़ाइल का साइज़, मैसेज से कम से कम 11 बाइट ज़्यादा होना चाहिए. अगर ऐसा नहीं होता है, तो इस तरीके से नतीजे पाने के लिए ErrorCode::INVALID_INPUT_LENGTH.
  • PaddingMode::RSA_PKCS1_1_1_5_ENCRYPT पैडिंग के लिए डाइजेस्ट की ज़रूरत नहीं होती.
  • PaddingMode::RSA_PSS पैडिंग के लिए एक डाइजेस्ट की ज़रूरत होती है, जो Digest::NONE. अगर Digest::NONE तय किया गया है, तो तरीका ErrorCode::INCOMPATIBLE_DIGEST दिखाता है. इसके अलावा, आरएसए कुंजी का साइज़, आउटपुट से कम से कम 2 + D बाइट होना चाहिए डाइजेस्ट का आकार, जहां D डाइजेस्ट का आकार है, बाइट में. शर्तें पूरी न करने पर यह हो सकता है यह तरीका ErrorCode::INCOMPATIBLE_DIGEST दिखाता है. नमक का साइज़ डी॰
  • PaddingMode::RSA_OAEP पैडिंग के लिए एक डाइजेस्ट की ज़रूरत होती है, जो Digest::NONE. अगर Digest::NONE तय किया गया है, तो तरीका ErrorCode::INCOMPATIBLE_DIGEST दिखाता है.

ईसी बटन

EC पासकोड से जुड़ी कार्रवाइयां, inParams में सिर्फ़ एक पैडिंग मोड के बारे में बताती हैं. यदि अनिर्दिष्ट या एक से अधिक बार निर्दिष्ट किया गया हो, तो ErrorCode::UNSUPPORTED_PADDING_MODE दिखाता है.

निजी कुंजी कार्रवाइयों (KeyPurpose::SIGN) के लिए अनुमति लेना ज़रूरी है डाइजेस्ट और पैडिंग के, इसका मतलब है कि मुख्य ऑथेंटिकेशन इसमें तय किए गए मान शामिल होने चाहिए. अगर ऐसा नहीं है, तो वापस कर दें ErrorCode::INCOMPATIBLE_DIGEST. सार्वजनिक पासकोड से जुड़ी कार्रवाइयां (KeyPurpose::VERIFY) को बिना अनुमति के डाइजेस्ट या पैडिंग के साथ इस्तेमाल करने की अनुमति है.

AES कुंजियां

AES कुंजी से जुड़ी कार्रवाइयों में सिर्फ़ एक ब्लॉक मोड और एक पैडिंग मोड चुना जाता है inParams में. अगर दोनों में से कोई भी वैल्यू नहीं बताई गई है या ज़्यादा जानकारी दी गई है एक बार से ज़्यादा है, तो ErrorCode::UNSUPPORTED_BLOCK_MODE या ErrorCode::UNSUPPORTED_PADDING_MODE. बताए गए मोड को कुंजी से अनुमति मिलती है, नहीं तो यह तरीका वापस आ जाता है ErrorCode::INCOMPATIBLE_BLOCK_MODE या ErrorCode::INCOMPATIBLE_PADDING_MODE.

अगर ब्लॉक मोड BlockMode::GCM है, तो inParams Tag::MAC_LENGTH दर्ज करता है, और दिया गया मान 8 का गुणज है जो 128 से बड़ा नहीं है या Tag::MIN_MAC_LENGTH के मान से कम की अनुमति दे सकते हैं. MAC की 128 से ज़्यादा लंबाई या इसके नॉन-मल्टीपल्स के लिए 8, ErrorCode::UNSUPPORTED_MAC_LENGTH वापसी. कम वैल्यू के लिए कुंजी की कम से कम लंबाई से ज़्यादा, ErrorCode::INVALID_MAC_LENGTH दें.

अगर ब्लॉक मोड BlockMode::GCM या BlockMode::CTR है, तो बताया गया पैडिंग मोड PaddingMode::NONE होना चाहिए. BlockMode::ECB या BlockMode::CBC के लिए, मोड ऐसा हो सकता है PaddingMode::NONE या PaddingMode::PKCS7. अगर पैडिंग मोड इन शर्तों को पूरा नहीं करता है, ErrorCode::INCOMPATIBLE_PADDING_MODE दिखाएं.

अगर ब्लॉक मोड BlockMode::CBC, BlockMode::CTR है, तो या BlockMode::GCM, इनिशलाइज़ेशन वेक्टर या नॉन्स की ज़रूरत होती है. ज़्यादातर मामलों में, कॉलर को IV या नॉन्स नहीं देना चाहिए. ऐसी स्थिति में, KeyMaster लागू करने पर एक रैंडम IV या नॉन्स जनरेट होता है और यह इसके ज़रिए वापस करता है outParams में Tag::NONCE. CBC और CTR IVs 16 बाइट होते हैं. GCM नॉन्स 12 बाइट हैं. अगर कुंजी अनुमतियों में ये शामिल हैं टैग::CALLER_NONCE, तो कॉलर टैग::NONCE inParams में. अगर नॉन्स टैग::CALLER_NONCE अनुमति नहीं है, ErrorCode::CALLER_NONCE_PROHIBITED वापस करें. अगर नॉन्स नहीं दिया गया है टैग::CALLER_NONCE अनुमति प्राप्त है, तो यादृच्छिक IV/nos जनरेट करें.

एचएमएसी बटन

inParams में एचएमएसी कुंजी से जुड़ी कार्रवाइयों के लिए Tag::MAC_LENGTH तय करें. दिया गया मान 8 का ऐसा गुणज होना चाहिए जो डाइजेस्ट की लंबाई या Tag::MIN_MAC_LENGTH की वैल्यू से कम के लिए, 'ज़रूरी अधिकार' में रखें. MAC लंबाई के लिए डाइजेस्ट की लंबाई से ज़्यादा या 8 के नॉन-मल्टिपल, ErrorCode::UNSUPPORTED_MAC_LENGTH दिखाता है. कुंजी की कम से कम लंबाई से कम वैल्यू के लिए, वापस जाएं ErrorCode::INVALID_MAC_LENGTH.

अपडेट करें

वर्शन: 1, 2, 3

begin से शुरू की गई, चल रही कार्रवाई को प्रोसेस करने के लिए डेटा देता है. यह कार्रवाई, operationHandle पैरामीटर से तय होती है.

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

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

गड़बड़ी ठीक करना

अगर यह तरीका ErrorCode::OK के अलावा कोई गड़बड़ी कोड दिखाता है, तो कार्रवाई रद्द कर दी गई है और ऑपरेशन हैंडल अमान्य हो गया है. कोई भी आने वाले समय में, इस तरीके से हैंडल का इस्तेमाल खत्म या रद्द करने, ErrorCode::INVALID_OPERATION_HANDLE दिखाता है.

अनुमति लागू करने का तरीका

कुंजी की पुष्टि करने का तरीका (एनफ़ोर्समेंट) मुख्य रूप से शुरुआत में किया जाता है. एक अपवाद यह है कि कुंजी में:

इस मामले में, कुंजी को हर कार्रवाई के लिए अनुमति की ज़रूरत होती है और अपडेट के मुताबिक तरीके को Tag::AUTH_TOKEN मिलता है inParams आर्ग्युमेंट में दी गई वैल्यू डालें. एचएमएसी पुष्टि करता है कि टोकन मान्य है या नहीं. साथ ही, इसमें यह शामिल है का मिलान करती है, जो कुंजी की टैग::USER_AUTH_TYPE, और इसमें मौजूदा ऑपरेशन का ऑपरेशन हैंडल शामिल होता है चैलेंज फ़ील्ड. अगर ये शर्तें पूरी नहीं होती हैं, तो वापस जाएं ErrorCode::KEY_USER_NOT_AUTHENTICATED.

कॉलर, अपडेट करने के लिए हर कॉल के लिए पुष्टि करने वाला टोकन देता है और finish. अगर टोकन लागू करना है, तो उसे सिर्फ़ एक बार पुष्टि करने की ज़रूरत है.

आरएसए कुंजियां

Digest::NONE के साथ साइन करने और पुष्टि करने की कार्रवाइयों के लिए, यह तरीका पूरे ब्लॉक को एक ही बार में हस्ताक्षर या पुष्टि करने के लिए स्वीकार करता है अपडेट. ऐसा हो सकता है कि यह ब्लॉक के सिर्फ़ एक हिस्से का इस्तेमाल न करे. हालांकि, अगर कॉलर अगर यह विकल्प चुना जाता है कि डेटा को एक से ज़्यादा अपडेट में दिया जाए, तो यह तरीका इसे स्वीकार करता है. अगर कॉलर, हस्ताक्षर करने के लिए इस्तेमाल किए जा सकने वाले डेटा से ज़्यादा डेटा उपलब्ध कराता है, तो डेटा, आरएसए कुंजी के साइज़ से ज़्यादा हो गया है), ErrorCode::INVALID_INPUT_LENGTH रिटर्न करें.

ECDSA कुंजियां

Digest::NONE के साथ साइन करने और पुष्टि करने की कार्रवाइयों के लिए, यह तरीका पूरे ब्लॉक को एक ही बार में हस्ताक्षर या पुष्टि करने के लिए स्वीकार करता है अपडेट. इस तरीके से ब्लॉक का सिर्फ़ एक हिस्सा इस्तेमाल नहीं किया जा सकता.

हालांकि, अगर कॉल करने वाला (कॉलर) एक से ज़्यादा अपडेट में डेटा देने का विकल्प चुनता है, तो इस विधि से इसे स्वीकार किया जाता है. अगर कॉल करने वाला (कॉलर) हस्ताक्षर करने के लिए ज़्यादा डेटा देता है कि उनका इस्तेमाल नहीं किया जा सकता हो, तो डेटा में चुपचाप काट-छांट की जाती है. (यह इस तरह के आरएसए ऑपरेशन में ज़्यादा डेटा को हैंडल करने का तरीका. इसकी वजह पुराने क्लाइंट के साथ काम करता है.)

AES कुंजियां

AES GCM मोड "इससे जुड़ा ऑथेंटिकेशन डेटा", के द्वारा प्रदान किया गया है टैग::ASSOCIATED_DATA टैग के लिए inParams आर्ग्युमेंट के तौर पर लिखें. संबंधित डेटा बार-बार किए जाने वाले कॉल में दिया जा सकता है (यदि महत्वपूर्ण है तो एक ब्लॉक में भेजने के लिए डेटा बहुत बड़ा है) लेकिन यह हमेशा डेटा से पहले होता है एन्क्रिप्ट (सुरक्षित) या डिक्रिप्ट किया जा सकता है. अपडेट कॉल में दोनों तरह का डेटा शामिल हो सकता है और एन्क्रिप्ट/डिक्रिप्ट करने के लिए डेटा, लेकिन हो सकता है कि बाद के अपडेट में डेटा शामिल है. अगर कॉलर, कॉल के बाद अपडेट कॉल से जुड़ा डेटा देता है जिसमें एन्क्रिप्ट/डिक्रिप्ट किया जाने वाला डेटा शामिल हो, रिटर्न ErrorCode::INVALID_TAG.

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

पूरा करें

वर्शन: 1, 2, 3

begin से शुरू की गई प्रोसेस को पूरा करता है, उस डेटा को प्रोसेस करेगा जिसे फ़िलहाल प्रोसेस नहीं किया गया है. अपडेट.

किसी कार्रवाई में यह आखिरी तरीका है, इसलिए सभी प्रोसेस किया गया डेटा वापस कर दिया जाता है.

अगर यह प्रोसेस पूरी हो जाती है या इससे कोई गड़बड़ी मिलती है, तो इस तरीके को फ़ाइनल किया जाता है कार्रवाई को ट्रैक करने की सुविधा मिलती है और इसलिए दिया गया ऑपरेशन हैंडल अमान्य हो जाता है. कोई भी आने वाले समय में, इस तरीके से हैंडल का इस्तेमाल करें या अपडेट करें या abort, ErrorCode::INVALID_OPERATION_HANDLE दिखाता है.

हस्ताक्षर की कार्रवाई करने पर, आउटपुट के तौर पर हस्ताक्षर दिखता है. पुष्टि की कार्रवाइयां signature पैरामीटर में हस्ताक्षर स्वीकार करें और कोई आउटपुट न दें.

अनुमति लागू करने का तरीका

पुष्टि करने की कुंजी को लागू करने का तरीका, मुख्य रूप से यहां लागू किया जाता है: शुरू करें. एक अपवाद यह है कि कुंजी में:

इस मामले में, कुंजी को हर कार्रवाई के लिए अनुमति की ज़रूरत होती है और अपडेट के मुताबिक तरीके को Tag::AUTH_TOKEN मिलता है inParams आर्ग्युमेंट में दी गई वैल्यू डालें. एचएमएसी इस बात की पुष्टि करता है कि टोकन मान्य है और उसमें मेल खाने वाला एक सुरक्षित यूज़र आईडी है, जो की से मेल खाता है टैग::USER_AUTH_TYPE और इसमें मौजूदा कार्रवाई का ऑपरेशन हैंडल शामिल है चैलेंज फ़ील्ड. अगर ये शर्तें पूरी नहीं होती हैं, तो वापस जाएं ErrorCode::KEY_USER_NOT_AUTHENTICATED.

कॉलर प्रत्येक कॉल के लिए प्रमाणीकरण टोकन उपलब्ध कराता है update और खत्म करें. अगर टोकन लागू करना है, तो उसे सिर्फ़ एक बार पुष्टि करने की ज़रूरत है.

आरएसए कुंजियां

पैडिंग मोड के आधार पर, कुछ और ज़रूरी शर्तें:

  • PaddingMode::NONE. बिना पैड वाली साइन इन और एन्क्रिप्ट (सुरक्षित) करने की सुविधाएं इस्तेमाल करने के लिए, अगर दिया गया डेटा कुंजी से छोटा है, तो डेटा को बिना किसी पैडिंग वाले बाईं ओर होना चाहिए. अगर डेटा की लंबाई कुंजी के बराबर है, तो लेकिन अंकों के हिसाब से, ErrorCode::INVALID_ARGUMENT दिखाएं. इसके लिए करने के लिए डिज़ाइन किया गया है, तो डेटा सटीक रूप से इतना लंबा होना चाहिए का इस्तेमाल किया जा सकता है. अगर ऐसा नहीं है, तो ErrorCode::INVALID_INPUT_LENGTH. को वापस करें
  • PaddingMode::RSA_PSS. पीएसएस की मदद से किए गए हस्ताक्षर से जुड़ी कार्रवाइयों के लिए, पीएसएस सॉल्ट, मैसेज डाइजेस्ट का साइज़ होता है और यह बिना किसी क्रम के जनरेट होता है. डाइजेस्ट जो टैग::DIGEST के साथ बताया गया है inputParams में शुरुआत को PSS डाइजेस्ट के रूप में इस्तेमाल किया जाता है और MGF1 डाइजेस्ट एल्गोरिदम के तौर पर भी काम करते हैं.
  • PaddingMode::RSA_OAEP. इससे तय किया गया डाइजेस्ट इसमें Tag::DIGEST begin पर inputParams का इस्तेमाल OAEP के तौर पर किया जाता है डाइजेस्ट एल्गोरिदम और SHA1 का इस्तेमाल MGF1 डाइजेस्ट एल्गोरिदम के तौर पर किया जाता है.

ECDSA कुंजियां

अगर हस्ताक्षर नहीं करने या पुष्टि करने के लिए दिया गया डेटा बहुत लंबा है, तो इसमें काट-छांट करें इसे.

AES कुंजियां

ब्लॉक मोड के आधार पर, कुछ अन्य शर्तें:

  • BlockMode::ECB या BlockMode::CBC. अगर पैडिंग PaddingMode::NONE है और डेटा की लंबाई एईएस ब्लॉक के आकार का गुणज नहीं है, ErrorCode::INVALID_INPUT_LENGTH. अगर पैडिंग (जगह) PaddingMode::PKCS7, PKCS#7 विशेषता के अनुसार डेटा पैड करें. ध्यान दें कि PKCS#7 का सुझाव है कि आप एक और पैडिंग ब्लॉक जोड़ें अगर डेटा, ब्लॉक की लंबाई के गुणज है.
  • BlockMode::GCM. एन्क्रिप्शन के दौरान, प्रोसेसिंग के बाद सभी सादा टेक्स्ट, टैग की गणना करें (टैग::MAC_LENGTH बाइट) और उसे लौटाए गए सादे टेक्स्ट में जोड़ें. डिक्रिप्शन के दौरान, प्रोसेस करें आखिरी टैग::MAC_LENGTH बाइट टैग करने के लिए भी कहा जाता है. अगर टैग की पुष्टि नहीं हो पाती है, तो वापस जाएं ErrorCode::VERIFICATION_FAILED.

रहने दो

वर्शन: 1, 2, 3

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

get_supported_algorithms

वर्शन: 1

कीमास्टर हार्डवेयर के साथ काम करने वाले एल्गोरिदम की सूची दिखाता है लागू करना. सॉफ़्टवेयर लागू करने पर एक खाली सूची मिलती है; हाइब्रिड लागू करने पर सिर्फ़ उन एल्गोरिदम की सूची मिलती है जिन्हें हार्डवेयर द्वारा समर्थित.

KeyMaster 1 लागू करने के तरीके आरएसए, ईसी, एईएस, और एचएमएसी के साथ काम करते हैं.

get_supported_block_modes

वर्शन: 1

यह नीति, KeyMaster हार्डवेयर के साथ काम करने वाले AES ब्लॉक मोड की सूची दिखाती है किसी खास एल्गोरिदम और मकसद के लिए लागू करना.

आरएसए, ईसी, और एचएमएसी के लिए, जो साइफ़र ब्लॉक नहीं हैं, यह तरीका नतीजे के तौर पर सभी मान्य कामों के लिए खाली सूची होनी चाहिए. अमान्य मकसद की वजह से, वापसी ErrorCode::INVALID_PURPOSE.

KeyMaster 1 को लागू करने के तरीके ईसीबी, सीबीसी, क्लिक मिलने की दर (सीटीआर), और एईएस के लिए GCM के साथ काम करते हैं एन्क्रिप्ट और डिक्रिप्शन के लिए इस्तेमाल किया जाता है.

get_supported_पैडिंग मोड

वर्शन: 1

KeyMaster हार्डवेयर के साथ काम करने वाले पैडिंग मोड की सूची दिखाता है किसी खास एल्गोरिदम और मकसद के लिए लागू करना.

एचएमएसी और ईसी में पैडिंग (जगह) जैसी कोई जानकारी नहीं है. इसलिए, यह तरीका खाली सूची दिखाता है सभी मान्य मकसद के लिए. अमान्य मकसद की वजह से, यह तरीका वापस मिल जाएगा ErrorCode::INVALID_PURPOSE.

आरएसए के लिए, कीमास्टर 1 को लागू करने के तरीके:

  • बिना जोड़े एन्क्रिप्शन, डिक्रिप्शन, साइन इन, और पुष्टि करने की सुविधा. बिना पैड वाले के लिए एन्क्रिप्ट (सुरक्षित) करने और हस्ताक्षर करने के लिए किया जाता है. अगर मैसेज सार्वजनिक मॉड्यूल से छोटा है, तो लागू करने के लिए इसे शून्य के साथ बाएं-पैड करना होगा. बिना पैड वाले डिक्रिप्शन के लिए और पुष्टि के लिए, इनपुट की लंबाई सार्वजनिक मॉड्यूलस साइज़ से मेल खानी चाहिए.
  • PKCS#1 v1.5 एन्क्रिप्शन और साइनिंग पैडिंग मोड
  • PSS, जिसमें कम से कम 20 नमक की लंबाई हो
  • ओएईपी

ईसीबी और सीबीसी मोड में एईएस के लिए, KeyMaster 1 को लागू करने के लिए पैडिंग और PKCS#7-पैडिंग. क्लिक मिलने की दर (सीटीआर) और GCM मोड में सिर्फ़ पैडिंग (जगह) नहीं है.

get_supported_डाइजेस्टs

वर्शन: 1

KeyMaster हार्डवेयर के साथ काम करने वाले डाइजेस्ट मोड की सूची दिखाता है किसी खास एल्गोरिदम और मकसद के लिए लागू करना.

कोई भी एईएस मोड काम नहीं करता या डाइजेस्ट करने की ज़रूरत नहीं होती, इसलिए यह तरीका 'खाली है' के तौर पर दिखाता है मान्य मकसद के लिए सूची बनाएं.

KeyMaster 1 लागू करने पर, डाइजेस्ट. लागू करने पर SHA-256 मिलता है और ये MD5, SHA1, SHA-224, SHA-256, SHA384, और SHA512 (तय किए गए डाइजेस्ट का पूरा सेट).

get_supported_Import_formats

वर्शन: 1

KeyMaster हार्डवेयर के साथ काम करने वाले इंपोर्ट फ़ॉर्मैट की सूची दिखाता है किसी खास एल्गोरिदम को लागू करना.

कीमास्टर 1 कार्यान्वयन PKCS#8 प्रारूप (बिना पासवर्ड के) का समर्थन करते हैं सुरक्षा) और आरएसए और EC कुंजी जोड़े को इंपोर्ट करने के लिए, और एईएस और एचएमएसी का अहम कॉन्टेंट.

get_supported_export_formats

वर्शन: 1

यह नीति KeyMaster हार्डवेयर के साथ काम करने वाले एक्सपोर्ट फ़ॉर्मैट की सूची दिखाता है किसी खास एल्गोरिदम को लागू करना.

KeyMaster1 लागू करने की सुविधा, आरएसए और EC सार्वजनिक कुंजियां. निजी या एसिमेट्रिक कुंजियों का एक्सपोर्ट नहीं किया जा सकता.

ऐतिहासिक काम

कीमास्टर 0

ये फ़ंक्शन, मुख्य कीमास्टर 0 डेफ़िनिशन से जुड़े हैं. वे ये कीमास्टर 1 स्ट्रक्ट keyMaster1_device_t में मौजूद थे. हालांकि, KeyMaster में 1.0 के बाद उन्हें लागू नहीं किया गया और उनके फ़ंक्शन पॉइंटर को शून्य पर सेट कर दिया गया.

  • generate_keypair
  • import_keypair
  • get_keypair_public
  • delete_keypair
  • delete_all
  • sign_data
  • Verify_data

कीमास्टर 1

नीचे दिए गए फ़ंक्शन कीमास्टर 1 परिभाषा से जुड़े हैं, लेकिन ये को कीमास्टर 2 में हटा दिया गया है. साथ ही, ऊपर दिए गए कीमास्टर 0 फ़ंक्शन भी शामिल हैं.

  • get_supported_algorithms
  • get_supported_block_modes
  • get_supported_padding_modes
  • get_supported_digests
  • get_supported_import_formats
  • get_supported_export_formats

कीमास्टर 2

नीचे दिए गए फ़ंक्शन की-मास्टर 2 परिभाषा से जुड़े हैं, लेकिन ये को कीमास्टर 3 के साथ-साथ ऊपर सूची में दिए गए कीमास्टर 1 फ़ंक्शन को हटाया गया.

  • configure