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

Android 17 (एपीआई लेवल 37) में, APK सिग्नेचर स्कीम v3.2 लॉन्च की गई है. यह एक हाइब्रिड सिग्नेचर स्कीम है, जिसे Android इकोसिस्टम को पोस्ट-क्वांटम क्रिप्टोग्राफ़ी (पीक्यूसी) पर ले जाने के लिए डिज़ाइन किया गया है.

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

मकसद और जानकारी

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

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

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

ट्रांज़िशन करने के लिए सबसे सही तरीके

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

क्लासिकल फ़ॉलबैक कॉन्फ़िगरेशन

पीक्यूसी ट्रांज़िशन के दौरान, सुरक्षा बनाए रखने के लिए, क्लासिकल फ़ॉलबैक कॉन्फ़िगरेशन लागू करें.

• मौजूदा ऐप्लिकेशन: ऐप्लिकेशन का मौजूदा साइनिंग पासकोड, K0, इस फ़ॉलबैक के लिए एक बुनियादी पासकोड के तौर पर काम करता है.
• नए ऐप्लिकेशन: शुरुआती आइडेंटिटी सेट अप करने के लिए, नए हाइब्रिड पासकोड, C_K1 और PQC_K1 के साथ, क्लासिकल का एक बुनियादी पासकोड, K0 जनरेट करें.

दोनों ही स्थितियों में, APK में एक स्टैंडर्ड v3.0 या v3.1 सिग्नेचर ब्लॉक शामिल होना चाहिए. इस ब्लॉक पर, क्लासिकल पासकोड, K0 से साइन किया गया हो. साथ ही, v3.2 हाइब्रिड ब्लॉक पर, नए हाइब्रिड पासकोड, C_K1 और PQC_K1 से साइन किया गया हो.

v3.2 स्कीम को शुरू में डिप्लॉय करने के दौरान, हाइब्रिड ब्लॉक के साइनिंग लीनेज में, K0 को ROLLBACK की सुविधा मिलनी चाहिए. अगर डिप्लॉयमेंट से जुड़ी समस्याएं आती हैं, तो इस सुविधा की मदद से, उपयोगकर्ता के अपडेट में रुकावट डाले बिना, ऐप्लिकेशन को क्लासिकल सिग्नेचर पर वापस लाया जा सकता है. जब रनटाइम डेटा से यह पुष्टि हो जाती है कि हाइब्रिड डिप्लॉयमेंट स्थिर है, तब हम ROLLBACK की सुविधा को बाद के अपडेट में हटाने का सुझाव देते हैं, ताकि आपके नए पासकोड पूरी तरह से सुरक्षित हो सकें.

लंबे समय तक इस्तेमाल करने के लिए कॉन्फ़िगरेशन से जुड़ी ज़रूरी शर्तें

आपको इस हाइब्रिड साइनिंग कॉन्फ़िगरेशन को तब तक बनाए रखना होगा, जब तक आपका ऐप्लिकेशन ऐसे प्लैटफ़ॉर्म रिलीज़ को टारगेट करता है जो सिर्फ़ हाइब्रिड स्कीम के साथ काम करता है. भले ही, प्लैटफ़ॉर्म का कोई वर्शन, एक ही पासकोड वाले पीक्यूसी पासकोड के साथ काम करता हो, लेकिन आपको ऐसे किसी भी APK पर, दोनों पासकोड से साइन करना होगा जो ऐसे रिलीज़ को टारगेट करता है जिसके लिए v3.2 हाइब्रिड ब्लॉक की ज़रूरत होती है.

APK सिग्नेचर स्कीम v3.2 ब्लॉक

APK साइनिंग ब्लॉक में, v3.2 सिग्नेचर ब्लॉक के साथ-साथ, v2, v3.0, और v3.1 सिग्नेचर ब्लॉक भी सेव किए जाते हैं.

v3.2 ब्लॉक का स्ट्रक्चर, v3.0 जैसा ही होता है. हालांकि, इसमें एक नया ब्लॉक आईडी, 0x70e1c89f इस्तेमाल किया जाता है, ताकि यह पता चल सके कि यह एक हाइब्रिड ब्लॉक है. मान्य v3.2 ब्लॉक में, ठीक दो साइनर होने चाहिए.

साथ काम करने वाले एल्गोरिदम

v3.2 स्कीम, शुरू में पीक्यूसी के इन सिग्नेचर एल्गोरिदम के साथ काम करती है:

• ML-DSA-65
• ML-DSA-87

हाइब्रिड ब्लॉक बनाने के लिए, इन्हें क्लासिकल के स्टैंडर्ड सिग्नेचर एल्गोरिदम के साथ जोड़ा जाता है. जैसे, v3.0 और v3.1 में काम करने वाले एल्गोरिदम.

फ़ॉर्मैट

APK साइनिंग ब्लॉक में, APK सिग्नेचर स्कीम v3.2 ब्लॉक को आईडी 0x70e1c89f के तहत सेव किया जाता है.

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

• length-prefixed sequence of length-prefixed signer:
  
  • length-prefixed signer (Classical)
  • length-prefixed signer (PQC)

हर साइनर, v3 के स्टैंडर्ड फ़ॉर्मैट का इस्तेमाल करता है:

• length-prefixed signed data:
  
  • length-prefixed sequence of length-prefixed digests:
  • signature algorithm ID (4 bytes)
  • digest (length-prefixed)
  • length-prefixed sequence of certificates:
  • length-prefixed X.509 certificate (ASN.1 DER form)
  • minSDK (uint32)
  • maxSDK (uint32)
  • length-prefixed sequence of length-prefixed additional attributes:
  • ID (uint32)
  • value (variable-length: length of the additional attribute - 4 bytes)
• minSDK (uint32)
• maxSDK (uint32)
• length-prefixed sequence of length-prefixed signatures:
  
  • signature algorithm ID (4 bytes)
  • length-prefixed signature over signed data
• length-prefixed public key (SubjectPublicKeyInfo, ASN.1 DER form)

पुष्टि

Android 17 (एपीआई लेवल 37) और इसके बाद के वर्शन पर, v3.2 सिग्नेचर की पुष्टि करने के लिए, प्लैटफ़ॉर्म क्लासिकल और पीक्यूसी, दोनों साइनर की पुष्टि करता है. साथ ही, उनकी कंपैटिबिलिटी की पुष्टि करता है और अपने-आप पासकोड बदलने के लीनेज की जांच करता है. Android 16 (एपीआई लेवल 36) और इससे पहले के प्लैटफ़ॉर्म रिलीज़ पर, प्लैटफ़ॉर्म इस हाइब्रिड सिग्नेचर ब्लॉक को प्रोसेस नहीं करता. इसके बजाय, पिछली स्कीम का इस्तेमाल करता है.

पूरी प्रोसेस इस तरह है:

1. APK सिग्नेचर स्कीम v3.2 ब्लॉक (आईडी 0x70e1c89f) ढूंढें.
2. पुष्टि करें कि ब्लॉक में ठीक दो साइनर हों. अगर दो से कम या ज़्यादा साइनर हैं, तो पुष्टि नहीं हो पाएगी.
3. पुष्टि करें कि एक हस्ताक्षर करने वाला व्यक्ति, क्लासिकल सिग्नेचर एल्गोरिदम का इस्तेमाल करता हो और दूसरा, पीक्यूसी सिग्नेचर एल्गोरिदम का इस्तेमाल करता हो. अगर दोनों क्लासिकल हैं या दोनों पीक्यूसी हैं, तो पुष्टि नहीं हो पाएगी.
4. पुष्टि करें कि दोनों साइनर, एसडीके की एक ही रेंज (minSdkVersion और maxSdkVersion) को टारगेट करते हों.
5. दोनों साइनर के लिए, v3 की स्टैंडर्ड पुष्टि करें:
   
   1. सिग्नेचर में से, सबसे मज़बूत सिग्नेचर एल्गोरिदम आईडी चुनें.
   2. सार्वजनिक पासकोड का इस्तेमाल करके, साइन किए गए डेटा के मुकाबले, सिग्नेचर में मौजूद संबंधित सिग्नेचर की पुष्टि करें.
   3. पुष्टि करें कि साइन किए गए डेटा में मौजूद minSdkVersion और maxSdkVersion, साइन न किए गए minSdkVersion और maxSdkVersion से मेल खाते हों.
   4. सर्टिफ़िकेट पार्स करें और पुष्टि करें कि पहला सर्टिफ़िकेट, सार्वजनिक पासकोड से मेल खाता हो.
   5. रोटेशन के सबूत के स्ट्रक्चर निकालने के लिए, अन्य एट्रिब्यूट पार्स करें.
6. साइनिंग हिस्ट्री (रोटेशन का सबूत) की पुष्टि करें:
   
   1. पक्का करें कि दोनों साइनर की पिछली साइनिंग हिस्ट्री एक जैसी हो.
   2. लीनेज की लंबाई एक जैसी होनी चाहिए. साथ ही, मौजूदा साइनर तक के सभी सर्टिफ़िकेट और केपबिलिटी फ़्लैग एक जैसे होने चाहिए.
   3. अगर हिस्ट्री मेल खाती हैं, तो लीनेज मर्ज करें: क्लासिकल साइनर के सर्टिफ़िकेट को पीक्यूसी साइनर के सर्टिफ़िकेट का पूर्ववर्ती मानें. साथ ही, पीक्यूसी साइनर को मौजूदा टर्मिनल नोड के तौर पर असाइन करें.
7. कॉन्टेंट डाइजेस्ट की पुष्टि करें:
   
   1. दोनों साइनर के लिए, डाइजेस्ट मैप को दोहराएं.
   2. पुष्टि करें कि मेल खाने वाले किसी भी डाइजेस्ट एल्गोरिदम के लिए, क्लासिकल और पीक्यूसी साइनर के बीच, कैलकुलेट की गई डाइजेस्ट वैल्यू एक जैसी हों.
8. पुष्टि किए गए साइनर के मेल खाने वाले डाइजेस्ट का इस्तेमाल करके, APK के कॉन्टेंट की इंटिग्रिटी की पुष्टि करें. यह प्रोसेस, v2 और v3 जैसी ही होती है.
1. अगर ऐप्लिकेशन पहले से इंस्टॉल है, तो पैकेज अपडेट लीनेज की पुष्टि करें:
2. एक ही पासकोड वाले साइनर से अपडेट करना: अगर इंस्टॉल किया गया ऐप्लिकेशन, क्लासिकल के एक ही पासकोड से साइन किया गया था, तो वह पासकोड, नए हाइब्रिड ब्लॉक के साइनिंग लीनेज में, हाइब्रिड साइनर के पूर्ववर्ती के तौर पर मौजूद होना चाहिए.
3. हाइब्रिड साइनर से अपडेट करके, हाइब्रिड पर बने रहना: अगर इंस्टॉल किया गया ऐप्लिकेशन, v3.2 हाइब्रिड ब्लॉक से साइन किया गया था, तो पिछले क्लासिकल और पीक्यूसी, दोनों पासकोड, अपडेट किए गए APK के v3.2 ब्लॉक में मौजूदा ऐक्टिव साइनर बने रहने चाहिए. इसके अलावा, दोनों पासकोड, नए साइनिंग लीनेज में मौजूद होने चाहिए. इससे, नए रोटेट किए गए हाइब्रिड पासकोड की पुष्टि होती है.
4. हाइब्रिड साइनर से ट्रांज़िशन करके, एक ही पासकोड वाले साइनर पर जाना: अगर इंस्टॉल किया गया ऐप्लिकेशन, v3.2 हाइब्रिड ब्लॉक से साइन किया गया था और अपडेट किया गया APK, वापस एक ही पासकोड वाले साइनर (पीक्यूसी या क्लासिकल) पर ट्रांज़िशन करता है, तो पिछले दोनों हाइब्रिड साइनर, अपडेट किए गए APK के साइनिंग लीनेज में मौजूद होने चाहिए. साथ ही, नए एक ही पासकोड वाले साइनिंग पासकोड की पुष्टि करनी चाहिए.
5. अपडेट के अमान्य पाथ: अगर कोई डेवलपर, हाइब्रिड-साइन किए गए ऐप्लिकेशन को अपडेट करने के लिए, रोटेशन की सही प्रोसेस के बिना, हाइब्रिड पासकोड में से सिर्फ़ एक का इस्तेमाल करता है, तो अपडेट नहीं हो पाएगा. डाउनग्रेड करने वाले हमलों से बचने के लिए, किसी भी ट्रांज़िशन में, दोनों पासकोड का साफ़ तौर पर इस्तेमाल किया जाना चाहिए.
9. अगर कोई भी चरण पूरा नहीं होता है, तो पुष्टि नहीं हो पाएगी.

स्ट्रिपिंग से सुरक्षा

v3.2 स्कीम में, स्ट्रिपिंग से सुरक्षा के एट्रिब्यूट शामिल हैं. ये एट्रिब्यूट, पिछली स्कीम के वर्शन में मौजूद एट्रिब्यूट की तरह ही हैं. इनकी मदद से, पुराने वर्शन की सिग्नेचर स्कीम पर डाउनग्रेड करने वाले हमलों से बचा जा सकता है.

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

• एसडीके के कम से कम वर्शन का एट्रिब्यूट (आईडी 0xbf940529): इस एट्रिब्यूट की वैल्यू से, एसडीके के उस कम से कम वर्शन के बारे में पता चलता है जिस पर हाइब्रिड साइनिंग ब्लॉक काम करता है.
• एसडीके के ज़्यादा से ज़्यादा वर्शन का एट्रिब्यूट (आईडी 0x9f06b79c): इस एट्रिब्यूट की वैल्यू से, एसडीके के उस ज़्यादा से ज़्यादा वर्शन के बारे में पता चलता है जिस पर हाइब्रिड साइनिंग ब्लॉक काम करता है. इस एट्रिब्यूट की मदद से, एक ही हस्ताक्षर करने वाले व्यक्ति वाले कॉन्फ़िगरेशन पर ट्रांज़िशन किया जा सकता है. ऐसा तब किया जा सकता है, जब प्लैटफ़ॉर्म के नए वर्शन के लिए, हाइब्रिड सिग्नेचर की ज़रूरत न हो.

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

• मौजूदगी और रेंज की पुष्टि: अगर v3.0 या v3.1 सिग्नेचर ब्लॉक में, एसडीके के कम से कम वर्शन का एट्रिब्यूट (आईडी 0xbf940529, वैल्यू X) या एसडीके के ज़्यादा से ज़्यादा वर्शन का एट्रिब्यूट (आईडी 0x9f06b79c, वैल्यू Y) मौजूद है, तो प्लैटफ़ॉर्म के लिए यह ज़रूरी है कि APK में v3.2 हाइब्रिड ब्लॉक मौजूद हो. प्लैटफ़ॉर्म, हाइब्रिड ब्लॉक को पढ़कर यह पुष्टि करता है कि उसका टारगेट एसडीके रेंज, इन एट्रिब्यूट से तय की गई सीमाओं से मेल खाती है. अगर v3.2 ब्लॉक मौजूद नहीं है या एसडीके के कम से कम और ज़्यादा से ज़्यादा टारगेट वैल्यू, X और Y के बराबर नहीं हैं, तो प्लैटफ़ॉर्म इंस्टॉलेशन को अस्वीकार कर देता है.
• रेंज के अंदर लागू करना: अगर डिवाइस के एसडीके का वर्शन, इन एट्रिब्यूट से तय की गई मान्य रेंज के अंदर आता है, तो प्लैटफ़ॉर्म के लिए यह ज़रूरी है कि सिग्नेचर की पुष्टि के लिए, v3.2 हाइब्रिड ब्लॉक का इस्तेमाल किया जाए. मान्य रेंज, X से ज़्यादा या उसके बराबर होती है. साथ ही, जब ज़्यादा से ज़्यादा एट्रिब्यूट की वैल्यू दी जाती है, तब यह Y से कम या उसके बराबर होती है. अगर प्लैटफ़ॉर्म, एसडीके की इस टारगेट रेंज में मौजूद किसी डिवाइस पर, v3.0 या v3.1 ब्लॉक की पुष्टि करता है, तो प्लैटफ़ॉर्म, इंस्टॉलेशन को अस्वीकार कर देता है. ऐसा इसलिए, क्योंकि v3.2 ब्लॉक को गलत तरीके से बाईपास किया गया है या स्ट्रिप किया गया है.

इन सीमाओं को लागू करके, प्लैटफ़ॉर्म यह तय करता है कि किसी APK में v3.2 ब्लॉक कब होना चाहिए. अगर ब्लॉक को स्ट्रिप किया गया है, तो प्लैटफ़ॉर्म, डाउनग्रेड करने वाले हमले से बचने के लिए, इंस्टॉलेशन को अस्वीकार कर देता है.

लागू करने की पुष्टि करना

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

इन टेस्ट में, कई तरह के परिदृश्य शामिल होते हैं. जैसे, इंस्टॉल करने में सफलता मिलना, क्लासिक-ओनली वर्शन से अपडेट करना, ROLLBACK केपबिलिटी का इस्तेमाल करके रोलबैक ट्रांज़िशन करना, और स्ट्रिपिंग के हमलों से बचाव की पुष्टि करना.