संस्करण बाध्यकारी

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

ट्रेबल की मॉड्यूलर संरचना का समर्थन करने और system.img से boot.img के बंधन को तोड़ने के लिए, कीमास्टर 4 ने प्रत्येक विभाजन के लिए अलग पैच स्तर रखने के लिए कुंजी संस्करण बाइंडिंग मॉडल को बदल दिया। यह रोलबैक सुरक्षा प्रदान करते हुए, प्रत्येक विभाजन को स्वतंत्र रूप से अद्यतन करने की अनुमति देता है।

एंड्रॉइड 9 में boot , system और vendor विभाजन प्रत्येक का अपना पैच स्तर होता है।

• Android सत्यापित बूट (AVB) वाले उपकरण सभी पैच स्तरों और सिस्टम संस्करण को vbmeta में रख सकते हैं, इसलिए बूटलोडर उन्हें Keymaster को प्रदान कर सकता है। जंजीर विभाजन के लिए, विभाजन के लिए संस्करण जानकारी जंजीर vbmeta में होगी। सामान्य तौर पर, संस्करण की जानकारी vbmeta struct में होनी चाहिए जिसमें किसी दिए गए विभाजन के लिए सत्यापन डेटा (हैश या हैशट्री) होता है।
• AVB के बिना डिवाइस पर:
  • सत्यापित बूट कार्यान्वयन को बूटलोडर को संस्करण मेटाडेटा का हैश प्रदान करने की आवश्यकता है, ताकि बूटलोडर कीमास्टर को हैश प्रदान कर सके।
  • boot.img हेडर में पैच लेवल को स्टोर करना जारी रख सकता है
  • system.img केवल-पढ़ने के लिए गुणों में पैच स्तर और OS संस्करण को संग्रहीत करना जारी रख सकता है
  • विक्रेता.आईएमजी पैच स्तर को केवल-पढ़ने के लिए संपत्ति 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 हेडर से हटा दिया जाता है।
• कीमास्टर कार्यान्वयन को सभी पैच स्तरों को स्वतंत्र रूप से व्यवहार करना चाहिए। यदि सभी संस्करण जानकारी एक कुंजी से जुड़े मूल्यों से मेल खाती है, और यदि आवश्यक हो तो IKeymaster::upgradeDevice() एक उच्च पैच स्तर पर रोल करता है, तो कुंजियाँ उपयोग योग्य होती हैं।

एचएएल परिवर्तन

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

Tag::OS_VERSION एक UINT मान है जो MMmmss के रूप में Android सिस्टम संस्करण के प्रमुख, लघु और उप-मामूली भागों का प्रतिनिधित्व करता है, जहां MM प्रमुख संस्करण है, mm लघु संस्करण है और ss उप-मामूली संस्करण है। उदाहरण के लिए 6.1.2 को 060102 के रूप में दर्शाया जाएगा।

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

अपग्रेडकी

कुंजियों को नए OS संस्करण और सिस्टम छवि के पैच स्तर में अपग्रेड करने की अनुमति देने के लिए, Android 7.1 ने HAL में 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 शामिल होंगे, जो कुंजी ब्लॉब को डिक्रिप्ट करने के लिए आवश्यक हैं, यदि वे पीढ़ी के दौरान प्रदान किए गए थे।
• upgradedKeyBlob आउटपुट पैरामीटर है, जिसका उपयोग नई कुंजी ब्लॉब को वापस करने के लिए किया जाता है।

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

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

सुरक्षित विन्यास

संस्करण बाइंडिंग को लागू करने के लिए, कीमास्टर टीए को वर्तमान ओएस संस्करण और पैच स्तर (संस्करण जानकारी) को सुरक्षित रूप से प्राप्त करने के लिए एक तरीके की आवश्यकता होती है, और यह सुनिश्चित करने के लिए कि इसे प्राप्त होने वाली जानकारी चल रहे सिस्टम के बारे में जानकारी से दृढ़ता से मेल खाती है।

TA को संस्करण जानकारी के सुरक्षित वितरण का समर्थन करने के लिए, एक OS_VERSION फ़ील्ड को बूट इमेज हेडर में जोड़ा गया है। बूट इमेज बिल्ड स्क्रिप्ट स्वचालित रूप से इस फ़ील्ड को पॉप्युलेट करती है। ओईएम और कीमास्टर टीए कार्यान्वयनकर्ताओं को बूट छवि से संस्करण जानकारी निकालने के लिए डिवाइस बूटलोडर को संशोधित करने के लिए एक साथ काम करने की जरूरत है और गैर-सुरक्षित सिस्टम बूट होने से पहले इसे टीए को पास करना होगा। यह सुनिश्चित करता है कि हमलावर टीए को संस्करण जानकारी के प्रावधान में हस्तक्षेप नहीं कर सकते हैं।

यह सुनिश्चित करना भी आवश्यक है कि सिस्टम छवि में बूट छवि के समान संस्करण जानकारी है। इसके लिए, कॉन्फ़िगर विधि को कीमास्टर एचएएल में जोड़ा गया है:

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 कहा जाता है, इसे सत्यापित करना चाहिए कि प्रदान की गई संस्करण जानकारी बूटलोडर द्वारा प्रदान की गई जानकारी से मेल खाती है। यदि संस्करण की जानकारी मेल नहीं खाती है, तो रिटर्न ErrorCode::INVALID_ARGUMENT configure , और अन्य सभी कीमास्टर विधियां ErrorCode::KEYMASTER_NOT_CONFIGURED । यदि जानकारी मेल खाती है, तो रिटर्न ErrorCode ErrorCode::OK configure , और अन्य कीमास्टर विधियां सामान्य रूप से कार्य करना शुरू कर देती हैं।

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

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