इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

एपीके हस्ताक्षर योजना v2

एपीके सिग्नेचर स्कीम v2 पूरी फाइल सिग्नेचर स्कीम है जो सत्यापन की गति को बढ़ाती है और एपीके के संरक्षित हिस्सों में किसी भी बदलाव का पता लगाकर अखंडता की गारंटी को मजबूत करती है।

एपीके सिग्नेचर स्कीम v2 इंसर्ट का उपयोग करके साइन इन करना, ज़िप सेंट्रल डायरेक्ट्री सेक्शन से ठीक पहले एपीके फाइल में एपीके साइनिंग ब्लॉक । एपीके साइनिंग ब्लॉक के अंदर, वी 2 हस्ताक्षर और हस्ताक्षरकर्ता पहचान जानकारी एक एपीके सिग्नेचर स्कीम v2 ब्लॉक में संग्रहीत की जाती है।

हस्ताक्षर करने से पहले और बाद में एपीके

चित्र 1. हस्ताक्षर करने से पहले और बाद में एपीके

एपीके सिग्नेचर स्कीम v2 को Android 7.0 (Nougat) में पेश किया गया था। एंड्रॉइड 6.0 (मार्शमैलो) और पुराने उपकरणों पर एपीके इंस्टॉल करने के लिए, v2 स्कीम के साथ साइन करने से पहले JAR साइनिंग का उपयोग करके एपीके साइन किया जाना चाहिए।

APK साइनिंग ब्लॉक

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

ब्लॉक में आईडी-वैल्यू जोड़े को इस तरह से लपेटा गया है जिससे एपीके में ब्लॉक का पता लगाना आसान हो जाता है। एपीके का v2 हस्ताक्षर आईडी 0x7109871a के साथ आईडी-मूल्य जोड़ी के रूप में संग्रहीत है।

प्रारूप

एपीके साइनिंग ब्लॉक का प्रारूप इस प्रकार है (सभी संख्यात्मक क्षेत्र थोड़े-से-अंतिम हैं):

  • बाइट्स में size of block (इस क्षेत्र को छोड़कर) (uint64)
  • Uint64 की लंबाई-पूर्व-उपसर्ग आईडी-मूल्य जोड़े की अनुक्रम:
    • ID (uint32)
    • value (चर-लंबाई: जोड़ी की लंबाई - 4 बाइट्स)
  • बाइट्स में size of block - बहुत पहले क्षेत्र के समान (uint64)
  • magic "APK सिग ब्लॉक 42" (16 बाइट्स)

एपीके को पहली बार ज़िप सेंट्रल डायरेक्टरी की शुरुआत (फाइल के अंत में सेंट्रल डायरेक्टरी रिकॉर्ड के ज़िप एंड को ढूंढकर, फिर रिकॉर्ड से सेंट्रल डायरेक्टरी के स्टार्ट ऑफ़सेट को पढ़कर) किया जाता है। magic मान यह स्थापित करने के लिए एक त्वरित तरीका प्रदान करता है कि केंद्रीय निर्देशिका से पहले क्या संभव है एपीके साइनिंग ब्लॉक। size of block वैल्यू का size of block तब कुशलता से फाइल में ब्लॉक की शुरुआत की ओर इशारा करता है।

ब्लॉक की व्याख्या करते समय अज्ञात आईडी वाले आईडी-मूल्य जोड़े को अनदेखा किया जाना चाहिए।

एपीके हस्ताक्षर योजना v2 ब्लॉक

एपीके एक या अधिक हस्ताक्षरकर्ताओं / पहचानकर्ताओं द्वारा हस्ताक्षरित होता है, प्रत्येक एक हस्ताक्षर कुंजी द्वारा दर्शाया जाता है। यह जानकारी एपीके सिग्नेचर स्कीम v2 ब्लॉक के रूप में संग्रहीत है। प्रत्येक हस्ताक्षरकर्ता के लिए, निम्नलिखित जानकारी संग्रहीत है:

  • (सिग्नेचर एल्गोरिथ्म, डाइजेस्ट, सिग्नेचर) ट्यूपल्स। एपीके की सामग्री की अखंडता की जांच से हस्ताक्षर सत्यापन के लिए पाचन को संग्रहीत किया जाता है।
  • X.509 प्रमाणपत्र श्रृंखला हस्ताक्षरकर्ता की पहचान का प्रतिनिधित्व करती है।
  • कुंजी-मूल्य जोड़े के रूप में अतिरिक्त विशेषताएँ।

प्रत्येक हस्ताक्षरकर्ता के लिए, एपीके को प्रदान की गई सूची में से एक समर्थित हस्ताक्षर का उपयोग करके सत्यापित किया गया है। अज्ञात हस्ताक्षर एल्गोरिदम के साथ हस्ताक्षर की अनदेखी की जाती है। यह प्रत्येक कार्यान्वयन पर निर्भर है कि कौन से हस्ताक्षर का उपयोग करने के लिए जब कई समर्थित हस्ताक्षर सामने आते हैं। यह भविष्य में पिछड़े-संगत तरीके से मजबूत हस्ताक्षर विधियों की शुरूआत करने में सक्षम बनाता है। सुझाया गया दृष्टिकोण सबसे मजबूत हस्ताक्षर को सत्यापित करना है।

प्रारूप

0x7109871a हस्ताक्षर योजना v2 ब्लॉक को आईडी 0x7109871a तहत 0x7109871a साइनिंग ब्लॉक में संग्रहीत किया गया है।

एपीके सिग्नेचर स्कीम v2 ब्लॉक का प्रारूप इस प्रकार है (सभी संख्यात्मक मान बहुत कम हैं, सभी लंबाई-उपसर्ग फ़ील्ड लंबाई के लिए uint32 का उपयोग करते हैं):

  • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग signer :
    • लंबाई-पूर्व- signed data :
      • लंबाई-पूर्व-उपसर्ग अनुक्रम लंबाई-पूर्वसंचालित digests :
      • X.509 certificates की लंबाई-उपसर्ग अनुक्रम:
        • लंबाई-उपसर्ग X.509 certificate (ASN.1 DER प्रपत्र)
      • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग additional attributes :
        • ID (uint32)
        • value (चर-लंबाई: अतिरिक्त विशेषता की लंबाई - 4 बाइट्स)
    • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग signatures :
      • signature algorithm ID (uint32)
      • signed data पर लंबाई-उपसर्ग signature
    • लंबाई-उपसर्ग public key (SubjectPublicKeyInfo, ASN.1 DER प्रपत्र)

हस्ताक्षर एल्गोरिदम आईडी

  • 0x0101-RSAA-PSS SHA2-256 डाइजेस्ट के साथ, SHA2-256 MGF1, नमक के 32 बाइट, ट्रेलर: 0xbc
  • 0x0102-RSAA-PSS SHA2-512 डाइजेस्ट के साथ, SHA2-512 MGF1, 64 बाइट्स नमक, ट्रेलर: 0xbc
  • 0x0103 - RSAA-PKCS1-v1_5 SHA2-256 पचाने के साथ। यह बिल्ड सिस्टम के लिए है जिसे नियतात्मक हस्ताक्षर की आवश्यकता होती है।
  • 0x0104- RSASSA-PKCS1-v1_5 SHA2-512 डाइजेस्ट के साथ। यह बिल्ड सिस्टम के लिए है जिसे नियतात्मक हस्ताक्षर की आवश्यकता होती है।
  • 0x0201- ECDSA SHA2-256 पचाने के साथ
  • 0x0202-ECDSA SHA2-512 डाइजेस्ट के साथ
  • 0x0301-SHA2-256 डाइजेस्ट वाला डीएसए

उपरोक्त सभी हस्ताक्षर एल्गोरिदम एंड्रॉइड प्लेटफ़ॉर्म द्वारा समर्थित हैं। साइनिंग टूल एल्गोरिदम के सबसेट को सपोर्ट कर सकते हैं।

समर्थित कुंजी आकार और EC घटता:

  • RSA: 1024, 2048, 4096, 8192, 16384
  • EC: NIST P-256, P-384, P-521
  • DSA: 1024, 2048, 3072

अखंडता-संरक्षित सामग्री

एपीके सामग्री की सुरक्षा के लिए, एपीके में चार खंड होते हैं:

  1. ज़िप प्रविष्टियों की सामग्री (ऑफसेट 0 से एपीके साइनिंग ब्लॉक की शुरुआत तक)
  2. APK साइनिंग ब्लॉक
  3. ज़िप केंद्रीय निर्देशिका
  4. केंद्रीय निर्देशिका का अंत

हस्ताक्षर करने के बाद एपीके सेक्शन

चित्र 2. हस्ताक्षर करने के बाद एपीके सेक्शन

एपीके सिग्नेचर स्कीम v2, सेक्शन 1, 3, 4 की अखंडता की रक्षा करता है, और एपीके सिग्नेचर स्कीम v2 ब्लॉक के signed data ब्लॉक सेक्शन 2 के अंदर समाहित करता है।

खंड 1, 3, और 4 की अखंडता signed data ब्लॉकों में संग्रहीत उनकी सामग्री के एक या एक से अधिक डाइजेस्ट द्वारा संरक्षित है, जो बदले में, एक या अधिक हस्ताक्षर द्वारा संरक्षित हैं।

अनुभाग 1, 3, और 4 के ऊपर पाचन दो-स्तरीय मर्कल के पेड़ के समान गणना की जाती है। प्रत्येक अनुभाग को लगातार 1 एमबी (2 20 बाइट्स) विखंडू में विभाजित किया जाता है। प्रत्येक खंड में अंतिम हिस्सा छोटा हो सकता है। प्रत्येक चंक के पाचन की गणना बाइट 0xa5 के संयोजन से की 0xa5 , 0xa5 में चंक की लंबाई (थोड़ा-एंडियन यूइंट 32), और चंक की सामग्री। शीर्ष-स्तरीय डाइजेस्ट बाइट 0x5a , 0x5a की संख्या (थोड़ा-एंडियन 0x5a पर गणना की जाती है, और क्रम में विखंडू की 0x5a में दिखाई देते हैं। पाचन की गणना चुन्नटदार फैशन में की जाती है, ताकि इसे समानांतर करके गणना को तेज किया जा सके।

एपीके डाइजेस्ट

चित्र 3. एपीके डाइजेस्ट

धारा 4 का संरक्षण (ज़िप एंड ऑफ़ सेंट्रल डायरेक्टरी) ऑफ़ ऑफ़ सेंट्रल डायरेक्टरी वाले सेक्शन से जटिल है। एपीके साइनिंग ब्लॉक का आकार बदलने पर ऑफसेट बदलता है, उदाहरण के लिए, जब एक नया हस्ताक्षर जोड़ा जाता है। इस प्रकार, जब सेंट्रल डाइरेक्टरी के ZIP एंड पर डाइजेस्ट करने के लिए, ZIP सेंट्रल डायरेक्टरी की ऑफ़सेट युक्त फ़ील्ड को एपीके साइनिंग ब्लॉक की ऑफ़सेट युक्त माना जाना चाहिए।

रोलबैक सुरक्षा

एक हमलावर v2- हस्ताक्षरित एपीके को सत्यापित करने का प्रयास कर सकता है जो कि एंड्रॉइड प्लेटफॉर्म पर v1-हस्ताक्षरित एपीके के रूप में सत्यापित है जो v2- हस्ताक्षरित एपीके को सत्यापित करने का समर्थन करता है। इस हमले को कम करने के लिए, v2- हस्ताक्षरित APK जो कि v1-हस्ताक्षरित हैं, उनके META-INF / *। SF फ़ाइलों के मुख्य भाग में एक X-Android-APK-Signed विशेषता होनी चाहिए। विशेषता का मूल्य एपीके हस्ताक्षर योजना आईडी (इस योजना की आईडी 2 है) का अल्पविराम से अलग सेट है। V1 हस्ताक्षर की पुष्टि करते समय, एपीके सत्यापनकर्ता को उन APK को अस्वीकार करने की आवश्यकता होती है, जिनके पास एपीके हस्ताक्षर योजना के लिए हस्ताक्षर नहीं हैं, सत्यापनकर्ता इस सेट से पसंद करता है (जैसे, v2 योजना)। यह सुरक्षा इस तथ्य पर निर्भर करती है कि META-INF / *। SF फ़ाइलों की सामग्री v1 हस्ताक्षर द्वारा सुरक्षित है। JAR हस्ताक्षरित एपीके सत्यापन पर अनुभाग देखें।

एक हमलावर एपीके सिग्नेचर स्कीम v2 ब्लॉक से मजबूत हस्ताक्षर करने का प्रयास कर सकता है। इस हमले को कम करने के लिए, हस्ताक्षर एल्गोरिदम आईडी की सूची जिसके साथ एपीके पर हस्ताक्षर किए जा रहे थे, signed data ब्लॉक में संग्रहीत है जो प्रत्येक हस्ताक्षर द्वारा संरक्षित है।

सत्यापन

एंड्रॉइड 7.0 और बाद में, एपीके को एपीके सिग्नेचर स्कीम v2 + या JAR हस्ताक्षर (v1 स्कीम) के अनुसार सत्यापित किया जा सकता है। पुराने प्लेटफॉर्म v2 हस्ताक्षरों की उपेक्षा करते हैं और केवल v1 हस्ताक्षर सत्यापित करते हैं।

एपीके हस्ताक्षर सत्यापन प्रक्रिया

चित्रा 4. APK हस्ताक्षर सत्यापन प्रक्रिया (लाल रंग में नए कदम)

एपीके हस्ताक्षर योजना v2 सत्यापन

  1. एपीके साइनिंग ब्लॉक का पता लगाएँ और सत्यापित करें कि:
    1. एपीके साइनिंग ब्लॉक के दो आकार के फ़ील्ड में समान मूल्य होते हैं।
    2. ZIP सेंट्रल डायरेक्टरी को ZIP डायरेक्टरी के ZIP एंड के तुरंत बाद रिकॉर्ड किया जाता है।
    3. अधिक डेटा के बाद सेंट्रल डायरेक्ट्री के ज़िप एंड का पालन नहीं किया जाता है।
  2. एपीके साइनिंग ब्लॉक के अंदर पहले एपीके सिग्नेचर स्कीम v2 ब्लॉक का पता लगाएँ। यदि v2 ब्लॉक मौजूद है, तो चरण 3 पर जाएं। अन्यथा, v1 स्कीम का उपयोग करके एपीके को सत्यापित करने के लिए वापस जाएं।
  3. signer सिग्नेचर स्कीम v2 ब्लॉक में प्रत्येक signer के लिए:
    1. सबसे मजबूत समर्थित चुनें signature algorithm ID से signatures । प्रत्येक आदेश / प्लेटफॉर्म संस्करण के लिए ताकत का आदेश देना आवश्यक है।
    2. इसी सत्यापित करें signature से signatures के खिलाफ signed data का उपयोग कर public key । (अब signed data को पार्स करना सुरक्षित है।)
    3. सत्यापित करें कि हस्ताक्षर एल्गोरिदम आईडी की digests और signatures में क्रमबद्ध सूची समान है। (यह हस्ताक्षर स्ट्रिपिंग / जोड़ को रोकने के लिए है।)
    4. एपीके एल्गोरिथ्म द्वारा उपयोग किए जाने वाले डाइजेस्ट एल्गोरिथ्म के रूप में एक ही डाइजेस्ट एल्गोरिथ्म का उपयोग करके एपीके सामग्री के पाचन की गणना करें
    5. सत्यापित करें कि अभिकलन डाइजेस्ट इसी के समान है digest से digests
    6. सत्यापित करें पहली की कि SubjectPublicKeyInfo certificate के certificates के समान है public key
  4. सत्यापन सफल होता है यदि कम से कम एक signer पाया गया था और चरण 3 प्रत्येक पाया signer लिए सफल हुआ।

नोट : एपीके को v1 स्कीम का उपयोग करके सत्यापित नहीं किया जाना चाहिए यदि चरण 3 या 4 में विफलता होती है।

JAR- हस्ताक्षरित APK सत्यापन (v1 योजना)

JAR- हस्ताक्षरित APK एक मानक हस्ताक्षरित JAR है , जिसमें META-INF / MANIFEST.MF में सूचीबद्ध प्रविष्टियाँ अवश्य होनी चाहिए और जहाँ सभी प्रविष्टियों पर हस्ताक्षरकर्ताओं के एक ही समूह द्वारा हस्ताक्षरित होना चाहिए। इसकी अखंडता निम्नानुसार सत्यापित है:

  1. प्रत्येक हस्ताक्षरकर्ता को META-INF / <signer> .SF और META-INF / <signer>? (RSAA DSA | EC) JAR प्रविष्टि द्वारा दर्शाया गया है।
  2. <साइनर>। (आरएसए | डीएसए | ईसी) साइनकेडाटा संरचना के साथ एक पीकेसीएस # 7 सीएमएस कंटेंटइन्फो है जिसका हस्ताक्षर <साइनर> .एसएफ फ़ाइल पर सत्यापित है।
  3. <signer> .SF फ़ाइल में META-INF / MANIFEST.MF की पूरी-पूरी फ़ाइल डाइजेस्ट होती है और META-INF / MANIFEST.MF के प्रत्येक सेक्शन की खुदाई होती है। MANIFEST.MF की संपूर्ण-फ़ाइल डाइजेस्ट सत्यापित है। यदि वह विफल रहता है, तो प्रत्येक MANIFEST.MF अनुभाग का पाचन इसके बजाय सत्यापित होता है।
  4. META-INF / MANIFEST.MF में प्रत्येक अखंडता-संरक्षित JAR प्रविष्टि के लिए, एक समान रूप से नामित अनुभाग होता है जिसमें प्रविष्टि की असम्पीडित सामग्री का पाचन होता है। ये सभी डाइजेस्ट सत्यापित हैं।
  5. एपीके सत्यापन में विफल रहता है अगर एपीके में जेएआर प्रविष्टियां होती हैं जो मैनिफेस्ट.एमएफ में सूचीबद्ध नहीं होती हैं और जेएआर हस्ताक्षर का हिस्सा नहीं होती हैं।

सुरक्षा श्रृंखला इस प्रकार है <signer>। (RSA | DSA | EC) -> <signer> .SF -> MANIFEST.MF -> प्रत्येक अखंडता-सुरक्षित JAR प्रविष्टि की सामग्री।