वर्शन बाइंडिंग

कीमास्टर 1 में, सभी कीमास्टर कुंजियां, क्रिप्टोग्राफ़िक तरीके से डिवाइस से जुड़ी हुई थीं रूट ऑफ़ ट्रस्ट या वेरिफ़ाइड बूट बटन. कीमास्टर 2 और 3 में, सभी कुंजियां, ऑपरेटिंग सिस्टम और सिस्टम इमेज के पैच लेवल से भी जुड़ी होती हैं. इससे यह पक्का होता है कि जिस हमलावर को पुराने ज़माने की कमी का पता चलता है Android या TEE सॉफ़्टवेयर के वर्शन को वर्शन और नए वर्शन की मदद से बनाई गई कुंजियों का इस्तेमाल करें. इसके अलावा, जब किसी कुंजी का इस्तेमाल जिस डिवाइस को अपग्रेड किया गया है उस पर, दिए गए वर्शन और पैच लेवल का इस्तेमाल किया जाता है तो पासकोड को इस्तेमाल करने से पहले अपग्रेड किया जाता है, और कुंजी का पिछला वर्शन अमान्य हो गया था. इस तरह, जैसे-जैसे डिवाइस को अपग्रेड करने के बाद, चाबियां "शाच" हो जाएंगी डिवाइस के साथ आगे, लेकिन किसी भी समय डिवाइस को पिछली रिलीज़ पर वापस ले जाने की वजह से, पासकोड उपयोगी नहीं है.

ट्रेबल के मॉड्यूलर स्ट्रक्चर को सपोर्ट करने और System.img की बाइंडिंग को बूट.img, KeyMaster 4 ने की वर्शन बाइंडिंग मॉडल को बदलकर एक अलग पैच लेवल हैं. इससे हर सेगमेंट को अपडेट किया जा सकता है स्वतंत्र रूप से काम करता है, जबकि रोलबैक सुरक्षा उपलब्ध कराता है.

Android 9 में boot, system, और vendor हर सेगमेंट का अपना पैच लेवल होता है.

  • Android वेरिफ़ाइड बूट (एवीबी) की सुविधा वाले डिवाइस, सभी पैच लेवल लागू कर सकते हैं और सिस्टम वर्शन vbmeta में, ताकि बूटलोडर उन्हें कीमास्टर. चेन वाले हिस्सों के लिए, सेगमेंट की वर्शन जानकारी चेन जैसे vbmeta में. सामान्य रूप से, वर्शन की जानकारी vbmeta struct जिसमें पुष्टि करने के लिए डेटा शामिल है (हैश या हैशट्री) अलग-अलग किया जा सकता है.
  • बिना एवीबी वाले डिवाइसों पर:
    • वेरिफ़ाइड बूट लागू करने के तरीके के लिए वर्शन का हैश देना ज़रूरी है बूटलोडर को मेटाडेटा देना होगा, ताकि बूटलोडर KeyMaster को हैश उपलब्ध करा सके.
    • boot.img, हेडर में पैच लेवल को सेव करना जारी रख सकता है
    • system.img सिर्फ़ रीड-ओनली मोड में पैच लेवल और ओएस वर्शन को सेव करना जारी रख सकता है प्रॉपर्टी
    • vendor.img, पैच लेवल को रीड-ओनली प्रॉपर्टी में सेव करता है ro.vendor.build.version.security_patch.
    • बूटलोडर, वेरिफ़ाइड बूट के ज़रिए पुष्टि किए गए पूरे डेटा का हैश उपलब्ध करा सकता है से लेकर, कीमास्टर तक.
  • Android 9 के वर्शन की जानकारी देने के लिए, नीचे दिए गए टैग का इस्तेमाल करें ये सेगमेंट शामिल किए गए हैं:
    • VENDOR_PATCH_LEVEL: vendor विभाजन
    • BOOT_PATCH_LEVEL: boot विभाजन
    • OS_PATCH_LEVEL और OS_VERSION: system विभाजन. (OS_VERSION को यहां से निकाला गया boot.img हेडर.
  • KeyMaster लागू करने की प्रोसेस में सभी पैच लेवल को अलग-अलग तरीके से इस्तेमाल किया जाना चाहिए. कुंजियां हैं का इस्तेमाल तब किया जा सकता है, जब वर्शन की सारी जानकारी कुंजी से जुड़ी वैल्यू से मेल खाती हो और IKeymaster::upgradeDevice() उच्च पैच लेवल पर रोल करता है, अगर की ज़रूरत नहीं है.

एचएएल में बदलाव

वर्शन बाइंडिंग और वर्शन की पुष्टि करने के लिए, Android 7.1 ने टैग Tag::OS_VERSION और Tag::OS_PATCHLEVEL और configure और upgradeKey तरीके. वर्शन टैग कीमास्टर 2+ का इस्तेमाल करके, ये सभी नए जनरेट किए गए डेटा में अपने-आप जुड़ जाते हैं (या अपडेट की गई) कुंजियां. इसके अलावा, ऐसे पासकोड का इस्तेमाल करने की कोशिश जिसमें ओएस नहीं है वर्शन या पैच लेवल, मौजूदा सिस्टम ओएस वर्शन या पैच लेवल से मेल खाते हों, ErrorCode::KEY_REQUIRES_UPGRADE से अस्वीकार किया गया है.

Tag::OS_VERSION एक UINT वैल्यू है, जो MMmms के रूप में Android सिस्टम वर्शन के बड़े, छोटे, और सब-माइनर हिस्से, इसमें MM मेजर वर्शन है, mm माइनर वर्शन है और ss सब-माइनर है वर्शन है. उदाहरण के लिए, 6.1.2 को 060102 के तौर पर दिखाया जाएगा.

Tag::OS_PATCHLEVEL एक UINT वैल्यू है, जो सिस्टम पर आखिरी बार अपडेट किए जाने का साल और महीना YYYYMM के रूप में, जहां YYYY है चार अंकों वाला साल और MM दो अंकों वाला महीना होता है. उदाहरण के लिए, मार्च 2016 के लिए 201603 के तौर पर दिखाया जाता है.

अपग्रेड कुंजी

कुंजियों को सिस्टम के नए ओएस वर्शन और पैच लेवल पर अपग्रेड होने की अनुमति देने के लिए इमेज, Android 7.1 ने एचएएल में upgradeKey तरीका जोड़ा है:

कीमास्टर 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

कीमास्टर 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);
  • dev, डिवाइस का स्ट्रक्चर है
  • keyBlobToUpgrade ऐसी कुंजी है जिसे अपग्रेड करने की ज़रूरत है
  • upgradeParams कुंजी को अपग्रेड करने के लिए ज़रूरी पैरामीटर हैं. ये Tag::APPLICATION_ID और Tag::APPLICATION_DATA. ये कुंजी को डिक्रिप्ट करने के लिए ज़रूरी हैं BLOB, अगर उन्हें जनरेशन के दौरान दिया गया हो.
  • upgradedKeyBlob एक आउटपुट पैरामीटर है, जिसका इस्तेमाल नया की ब्लॉब.

अगर upgradeKey को किसी ऐसे कुंजी ब्लॉब के साथ कॉल किया जाता है जिसे पार्स नहीं किया जा सकता या अमान्य है, तो यह ErrorCode::INVALID_KEY_BLOB दिखाता है. अगर यह को किसी ऐसी कुंजी के साथ कॉल किया जाता है जिसका पैच लेवल मौजूदा सिस्टम वैल्यू से ज़्यादा है, यह ErrorCode::INVALID_ARGUMENT दिखाता है. अगर कुंजी की मदद से कॉल किया जाता है जिसका ओएस वर्शन, मौजूदा सिस्टम वैल्यू से ज़्यादा हो और सिस्टम की वैल्यू शून्य नहीं है, यह ErrorCode::INVALID_ARGUMENT दिखाता है. ओएस वर्शन शून्य से शून्य तक अपग्रेड करने की अनुमति है. गड़बड़ियां होने पर सुरक्षित दुनिया से संपर्क करने पर, यह गड़बड़ी वाली सही वैल्यू दिखाता है (उदाहरण के लिए, ErrorCode::SECURE_HW_ACCESS_DENIED, ErrorCode::SECURE_HW_BUSY). ऐसा न करने पर, यह वापस आ जाता है ErrorCode::OK और एक नया कुंजी ब्लॉब वापस लौटाता है upgradedKeyBlob.

upgradeKey के बाद keyBlobToUpgrade मान्य रहेगा कॉल करता है. साथ ही, डिवाइस डाउनग्रेड हो जाने पर, सैद्धांतिक तौर पर इसका दोबारा इस्तेमाल किया जा सकता है. तय सीमा में प्रैक्टिस करता है, तो कीस्टोर आम तौर पर deleteKey को कॉल के तुरंत बाद keyBlobToUpgrade ब्लॉब upgradeKey. अगर keyBlobToUpgrade में टैग था Tag::ROLLBACK_RESISTANT, फिर upgradedKeyBlob को यह करना चाहिए यह भी आपके पास है (और इसे रोलबैक नहीं करना चाहिए).

सुरक्षित कॉन्फ़िगरेशन

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

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

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

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

params आर्ग्युमेंट में Tag::OS_VERSION और Tag::OS_PATCHLEVEL. इस तरीके को keyMaster2 क्लाइंट कॉल करते हैं एचएएल को खोलने से पहले, लेकिन किसी दूसरे तरीके से कॉल करने से पहले. अगर किसी और तरीके से कॉन्फ़िगर करने से पहले कॉल किया जाता है, तो TA वापस ErrorCode::KEYMASTER_NOT_CONFIGURED.

डिवाइस के चालू होने के बाद, पहली बार configure को कॉल किया जाता है को इस बात की पुष्टि करनी चाहिए कि जो वर्शन जानकारी दी गई है वह बूटलोडर पर क्लिक करें. अगर वर्शन की जानकारी मेल नहीं खाती है, configure, ErrorCode::INVALID_ARGUMENT और सभी वैल्यू दिखाता है अन्य कीमास्टर तरीके वापस आते रहते हैं ErrorCode::KEYMASTER_NOT_CONFIGURED. अगर जानकारी मेल खाती है, तो configure, ErrorCode::OK और अन्य कीमास्टर दिखाता है तरीके सामान्य रूप से काम करना शुरू कर देते हैं.

configure को बाद में किए जाने वाले कॉल, वही मान दिखाते हैं जो और कीमास्टर की स्थिति को नहीं बदलें. ध्यान दें कि यह प्रोसेस सभी ओटीए के लिए ज़रूरी है कि वे सिस्टम और बूट इमेज, दोनों को अपडेट करें; उन्हें अपडेट नहीं किया जा सकता अलग से सिंक करने की ज़रूरत नहीं होती.

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