APK सिग्नेचर स्कीम v3.1

Android 13 में, APK सिग्नेचर स्कीम v3.1 काम करती है. यह मौजूदा APK सिग्नेचर स्कीम v3 का बेहतर वर्शन है. v3.1 स्कीम में, रोटेशन से जुड़ी APK सिग्नेचर स्कीम v3 की कुछ सामान्य समस्याओं को ठीक किया गया है. खास तौर पर, v3.1 सिग्नेचर स्कीम, एसडीके वर्शन टारगेटिंग के साथ काम करती है. इससे, प्लैटफ़ॉर्म के बाद के रिलीज़ वर्शन को टारगेट करने के लिए रोटेशन की अनुमति मिलती है.

v3.1 सिग्नेचर स्कीम, ऐसे ब्लॉक आईडी का इस्तेमाल करती है जिसे Android 12 या इससे पहले के वर्शन पर नहीं पहचाना जाता. इसलिए, प्लैटफ़ॉर्म पर हस्ताक्षर करने वाले के लिए ये शर्तें लागू होती हैं:

  • Android 13 या इसके बाद के वर्शन पर काम करने वाले डिवाइस, v3.1 ब्लॉक में रोटेट किए गए हस्ताक्षर करने वाले व्यक्ति का इस्तेमाल करते हैं.
  • Android के पुराने वर्शन का इस्तेमाल करने वाले डिवाइस, रोटेट किए गए हस्ताक्षरकर्ता को अनदेखा करते हैं. इसके बजाय, वे v3 ब्लॉक में मौजूद ओरिजनल हस्ताक्षरकर्ता का इस्तेमाल करते हैं.

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

v3.1 का हस्ताक्षर ब्लॉक

v3.1 के साइनिंग ब्लॉक में वही कॉन्टेंट होता है जो v3 के साइनिंग ब्लॉक में होता है. हालांकि, नए ब्लॉक आईडी की वजह से इन सिग्नेचर को सिर्फ़ Android 13 और इसके बाद के वर्शन वाले डिवाइसों पर पहचाना जाता है. इससे ऐप्लिकेशन, अपनी साइनिंग की को सुरक्षित तरीके से रोटेट कर सकते हैं. उन्हें मल्टी-टारगेट वाले APK के बारे में चिंता करने की ज़रूरत नहीं होती, क्योंकि ओरिजनल हस्ताक्षर करने वाले व्यक्ति की पहचान का इस्तेमाल, v3 साइनिंग ब्लॉक में APK पर हस्ताक्षर करने के लिए किया जा सकता है. साथ ही, रोटेट किए गए हस्ताक्षर करने वाले व्यक्ति की पहचान का इस्तेमाल, v3.1 साइनिंग ब्लॉक में APK पर हस्ताक्षर करने के लिए किया जा सकता है. इससे प्लैटफ़ॉर्म को, v3.1 के हस्ताक्षर की पुष्टि करते समय, v3 के हस्ताक्षर वाले ब्लॉक के लिए पुष्टि करने वाले सभी मौजूदा कोड का फिर से इस्तेमाल करने की अनुमति भी मिलती है.

डिफ़ॉल्ट रूप से, apksig लाइब्रेरी, v3.1 साइनिंग ब्लॉक का इस्तेमाल करती है. ऐसा तब होता है, जब साइनिंग कॉन्फ़िग में रोटेट किया गया पासकोड और लीनेज दिया जाता है. अगर किसी ऐप्लिकेशन का minSdkVersion, Android 12 से कम है और रोटेट की गई कुंजी का इस्तेमाल किया जा रहा है, तो ओरिजनल साइनिंग पासकोड भी बताना होगा. इससे v3 साइनिंग ब्लॉक में APK पर साइन करने के लिए, इसका इस्तेमाल किया जा सकेगा. यह मौजूदा तरीके से मिलता-जुलता है. इसमें, अगर APK का टारगेट Android 9 से पहले का वर्शन है, तो ओरिजनल हस्ताक्षर करने वाले व्यक्ति का हस्ताक्षर ज़रूरी होता है.

किसी एसडीके वर्शन से शुरू होने वाले मुख्य रोटेशन को टारगेट करने के लिए, apksig लाइब्रेरी नए एपीआई उपलब्ध कराती है. इनकी मदद से, रोटेशन के लिए एसडीके का कम से कम वर्शन सेट किया जा सकता है. अगर Android 12 से कम के एसडीके वर्शन को रोटेशन की सुविधा के लिए कम से कम वर्शन के तौर पर सेट किया जाता है, तो ओरिजनल v3 ब्लॉक का इस्तेमाल किया जाता है. v3.1 सिग्नेचर ब्लॉक का इस्तेमाल सिर्फ़ रोटेशन की सुविधा के साथ किया जाता है. रोटेशन की सुविधा के लिए, एसडीके का कम से कम वर्शन Android 12 या इसके बाद का होना चाहिए. v3 के सिग्नेचर ब्लॉक में, रोटेशन के लिए एक एट्रिब्यूट होता है. यह एट्रिब्यूट, SDK टूल के कम से कम वर्शन को हटाने से सुरक्षा देता है.

APK में लीनेज शामिल है rotation-min-sdk-version की वैल्यू v3 सिग्नेचर ब्लॉक v3.1 signing block
नहीं डिफ़ॉल्ट या कोई भी वैल्यू (नीचे x के तौर पर दिखाई गई है) Android 9 और इसके बाद के वर्शन को टारगेट करने वाले, ओरिजनल हस्ताक्षरकर्ता के हस्ताक्षर वाला मौजूद नहीं
हां डिफ़ॉल्ट इसे ओरिजनल हस्ताक्षर करने वाले व्यक्ति ने साइन किया है. यह Android 9 से लेकर 12L तक के वर्शन को टारगेट करता है Android 12 और इसके बाद के वर्शन को टारगेट करने वाले, रोटेट किए गए हस्ताक्षरकर्ता के साथ साइन किया गया
हां x < 33 (Android 13) रोटेटेड हस्ताक्षर करने वाले व्यक्ति के हस्ताक्षर किए गए हों और Android 9 या इसके बाद के वर्शन को टारगेट किया गया हो मौजूद नहीं
हां x >= 33 (Android 13) ओरिजनल हस्ताक्षर करने वाले व्यक्ति के हस्ताक्षर के साथ, Android 9 को टारगेट किया जा रहा है - (x-1) रोटेटेड हस्ताक्षरकर्ता के साथ हस्ताक्षर किया गया, टारगेटिंग x+

रोटेशन से जुड़ी समस्याएं

प्लैटफ़ॉर्म में रोटेशन से जुड़ी इन समस्याओं को ठीक कर दिया गया है:

Android 12 में ठीक की गई समस्याएं

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

Android 11 से जुड़ी समस्याएं ठीक की गईं

  • PackageManager#checkSignatures को दो पैकेज की ओरिजनल साइनिंग कुंजियों की जांच करने के लिए, ठीक से अपडेट नहीं किया गया था. इससे, उन ऐप्लिकेशन के लिए इंस्ट्रुमेंटेशन काम नहीं कर रहा है जो रोटेट की गई साइनिंग की का इस्तेमाल करते हैं. साथ ही, इंस्ट्रुमेंटेशन APK के लिए ओरिजनल साइनिंग की का इस्तेमाल करते हैं.
  • sharedUserId के तहत आने वाले पैकेज, अपने हस्ताक्षर की जानकारी शेयर करते हैं. जब भी अपडेट किए गए हस्ताक्षर के लीनेज वाला कोई ऐप्लिकेशन sharedUiserId में इंस्टॉल या अपडेट किया जाता है, तो उस ऐप्लिकेशन का लीनेज, sharedUserId के लिए शेयर किए गए लीनेज की जगह ले लेता है (उदाहरण के लिए, अगर किसी ऐप्लिकेशन के हस्ताक्षर का लीनेज A -> B है और sharedUserId में ऐप्लिकेशन को B -> C लीनेज के साथ अपडेट किया जाता है, तो sharedUserId का लीनेज B -> C से बदल दिया जाएगा). इसी तरह, लीनेज में पिछले हस्ताक्षरकर्ता की क्षमताओं को तब तक अपडेट नहीं किया जा सकता, जब तक कि हस्ताक्षर करने वाले लीनेज को बदल न दिया जाए.

v4 इंटिग्रेशन

v4 सिग्नेचर स्कीम में, apksigner को दिए गए साइनिंग कॉन्फ़िगरेशन का इस्तेमाल किया जाता है. अगर रोटेशन के लिए एक से ज़्यादा साइनिंग कॉन्फ़िगरेशन दिए गए हैं, तो रोटेट किए गए नए साइनिंग कॉन्फ़िगरेशन का इस्तेमाल किया जाता है. v3.1 के आने से पहले, v3 में सिर्फ़ यह रोटेट की गई नई साइनिंग कॉन्फ़िगरेशन शामिल था. इसलिए, v4 इस कॉन्फ़िगरेशन का इस्तेमाल कर सका. इससे v4 सिग्नेचर स्कीम, रोटेशन की सुविधा के साथ काम कर सकी, क्योंकि इसने SigningInfo में रोटेट की गई साइनिंग कुंजी का इस्तेमाल किया था. v4 SigningInfo में, हस्ताक्षर करने वाले सभी लोगों की जानकारी शामिल नहीं होती. हालांकि, यह v3 signing block से यह जानकारी हासिल कर सकता है, ताकि प्लैटफ़ॉर्म किसी भी हस्ताक्षर क्वेरी के लिए, हस्ताक्षर करने वाले सभी लोगों की जानकारी को ऐक्सेस कर सके. अगर रोटेशन-मिन-एसडीके-वर्शन के लिए, v3.1 का इस्तेमाल किया जा रहा है, तो सामान्य v3 कॉन्फ़िगरेशन में ओरिजनल साइनिंग कॉन्फ़िगरेशन और रोटेट किया गया नया साइनिंग कॉन्फ़िगरेशन, दोनों शामिल होते हैं. v4 के सिग्नेचर स्कीम का एक एक्सटेंशन बनाया गया है. इसमें v3.1 ब्लॉक के हर कॉन्फ़िगरेशन पर हस्ताक्षर करने के लिए, अतिरिक्त जानकारी वाले ब्लॉक शामिल हैं.

सत्यापन

v3.1 को लागू करने के बाद, उसकी जांच करने के लिए, PkgInstallSignatureVerificationTest.java में cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ CTS टेस्ट चलाएं.

टेस्टिंग के बारे में ज़्यादा जानकारी के लिए, v3 में पुष्टि सेक्शन देखें.