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

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

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

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

• एंड्रॉइड सत्यापित बूट (एवीबी) वाले डिवाइस सभी पैच स्तरों और सिस्टम संस्करण को वीबीमेटा में डाल सकते हैं, ताकि बूटलोडर उन्हें कीमास्टर को प्रदान कर सके। शृंखलाबद्ध विभाजन के लिए, विभाजन की संस्करण जानकारी शृंखलाबद्ध vbmeta में होगी। सामान्य तौर पर, संस्करण की जानकारी vbmeta struct में होनी चाहिए जिसमें किसी दिए गए विभाजन के लिए सत्यापन डेटा (हैश या हैशट्री) शामिल हो।
• AVB रहित डिवाइस पर:
  • सत्यापित बूट कार्यान्वयन को बूटलोडर को संस्करण मेटाडेटा का हैश प्रदान करने की आवश्यकता होती है, ताकि बूटलोडर कीमास्टर को हैश प्रदान कर सके।
  • boot.img हेडर में पैच स्तर संग्रहीत करना जारी रख सकता है
  • system.img केवल पढ़ने योग्य गुणों में पैच स्तर और OS संस्करण को संग्रहीत करना जारी रख सकता है
  • vendor.img पैच स्तर को केवल पढ़ने योग्य संपत्ति ro.vendor.build.version.security_patch में संग्रहीत करता है।
  • बूटलोडर कीमास्टर को सत्यापित बूट द्वारा मान्य सभी डेटा का हैश प्रदान कर सकता है।
• एंड्रॉइड 9 में, निम्नलिखित विभाजनों के लिए संस्करण जानकारी प्रदान करने के लिए निम्नलिखित टैग का उपयोग करें:
  • VENDOR_PATCH_LEVEL : vendor विभाजन
  • BOOT_PATCH_LEVEL : boot विभाजन
  • OS_PATCH_LEVEL और OS_VERSION : system विभाजन। ( OS_VERSION को boot.img हेडर से हटा दिया गया है।
• कीमास्टर कार्यान्वयन को सभी पैच स्तरों का स्वतंत्र रूप से इलाज करना चाहिए। यदि सभी संस्करण की जानकारी कुंजी से जुड़े मानों से मेल खाती है, तो कुंजियाँ प्रयोग करने योग्य होती हैं, और यदि आवश्यक हो तो IKeymaster::upgradeDevice() उच्च पैच स्तर पर रोल करता है।

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

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

Tag::OS_VERSION एक UINT मान है जो एंड्रॉइड सिस्टम संस्करण के प्रमुख, लघु और उप-लघु भागों को MMmmss के रूप में दर्शाता है, जहां 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 लौटाता है। ओएस संस्करण को गैर-शून्य से शून्य तक अपग्रेड करने की अनुमति है। सुरक्षित दुनिया के साथ संचार करने में त्रुटियों की स्थिति में, यह एक उचित त्रुटि मान देता है (उदाहरण के लिए ErrorCode::SECURE_HW_ACCESS_DENIED , ErrorCode::SECURE_HW_BUSY )। अन्यथा, यह ErrorCode::OK लौटाता है और upgradedKeyBlob में एक नई कुंजी ब्लॉब लौटाता है।

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

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

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

टीए को संस्करण जानकारी की सुरक्षित डिलीवरी का समर्थन करने के लिए, बूट छवि हेडर में एक 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 क्लाइंट द्वारा HAL खोलने के बाद, लेकिन किसी अन्य विधि को कॉल करने से पहले कॉल किया जाता है। यदि कॉन्फ़िगर करने से पहले किसी अन्य विधि को कॉल किया जाता है, तो TA ErrorCode::KEYMASTER_NOT_CONFIGURED लौटाता है।

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

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

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