Google 致力于为黑人社区推动种族平等。查看具体举措
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

एंड्रॉइड 9 एपीके की रोटेशन का समर्थन करता है, जो ऐप को एपीके अपडेट के हिस्से के रूप में अपनी साइनिंग कुंजी को बदलने की क्षमता देता है। रोटेशन को व्यावहारिक बनाने के लिए, APK को नई और पुरानी साइनिंग कुंजी के बीच विश्वास के स्तर को इंगित करना चाहिए। कुंजी रोटेशन का समर्थन करने के लिए, हमने नई और पुरानी कुंजी का उपयोग करने की अनुमति देने के लिए v2 से v3 तक एपीके हस्ताक्षर योजना को अपडेट किया। V3 समर्थित एसडीके संस्करणों और एपीके साइनिंग ब्लॉक के लिए एक सबूत-से-रोटेशन संरचना के बारे में जानकारी जोड़ता है।

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

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

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

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

V3 योजना को v2 योजना के समान बनाया गया है। इसका एक ही सामान्य प्रारूप है और एक ही हस्ताक्षर एल्गोरिदम आईडी , मुख्य आकार और ईसी घटता का समर्थन करता है।

हालाँकि, v3 योजना समर्थित SDK संस्करणों और प्रूफ-ऑफ-रोटेशन संरचना के बारे में जानकारी जोड़ती है।

स्वरूप

0xf05368c0 सिग्नेचर स्कीम v3 ब्लॉक को आईडी 0xf05368c0 तहत 0xf05368c0 साइनिंग ब्लॉक में संग्रहीत किया गया है।

एपीके सिग्नेचर स्कीम v3 ब्लॉक का प्रारूप v2 का अनुसरण करता है:

  • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग signer :
    • लंबाई-पूर्व- signed data :
      • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्गों की digests :
        • signature algorithm ID (4 बाइट्स)
        • digest (लंबाई-उपसर्ग)
      • X.509 certificates की लंबाई-उपसर्ग अनुक्रम:
        • लंबाई-उपसर्ग X.509 certificate (ASN.1 DER फॉर्म)
      • minSDK (uint32) - इस minSDK को अनदेखा किया जाना चाहिए यदि प्लेटफ़ॉर्म संस्करण इस संख्या से नीचे है।
      • maxSDK (uint32) - यदि प्लेटफ़ॉर्म संस्करण इस संख्या से ऊपर है तो इस हस्ताक्षरकर्ता को अनदेखा किया जाना चाहिए।
      • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग additional attributes :
        • ID (uint32)
        • value (चर-लंबाई: अतिरिक्त विशेषता की लंबाई - 4 बाइट्स)
        • ID - 0x3ba06f8c
        • value - सबूत-रोटेशन संरचना
    • minSDK (uint32) - हस्ताक्षरित डेटा अनुभाग में minSDK मूल्य का डुप्लिकेट - वर्तमान प्लेटफ़ॉर्म की सीमा में नहीं होने पर इस हस्ताक्षर के सत्यापन को छोड़ने के लिए उपयोग किया जाता है। हस्ताक्षर किए गए डेटा मान से मेल खाना चाहिए।
    • maxSDK (uint32) - हस्ताक्षरित डेटा अनुभाग में maxSDK मूल्य का डुप्लिकेट - वर्तमान प्लेटफ़ॉर्म सीमा में नहीं होने पर इस हस्ताक्षर के सत्यापन को छोड़ने के लिए उपयोग किया जाता है। हस्ताक्षर किए गए डेटा मान से मेल खाना चाहिए।
    • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग signatures :
      • signature algorithm ID (uint32)
      • signed data पर लंबाई-उपसर्ग signature
    • लंबाई-उपसर्ग public key (SubjectPublicKeyInfo, ASN.1 DER प्रपत्र)

प्रूफ-ऑफ-रोटेशन और सेल्फ-ट्रस्टेड-ओल्ड-सेर्ट्स स्ट्रक्चर

रोटेशन-स्ट्रक्चर का प्रूफ-इन ऐप्स को उन ऐप पर साइन किए बिना अपने साइनिंग सर्टिफिकेट को घुमाने की अनुमति देता है, जिनके साथ वे संवाद करते हैं। इसे पूरा करने के लिए, एप्लिकेशन हस्ताक्षरों में दो नए डेटा होते हैं:

  • तीसरे पक्ष के लिए दावा है कि ऐप के हस्ताक्षरित प्रमाण पत्र पर भरोसा किया जा सकता है जहां भी उसके पूर्ववर्तियों पर भरोसा किया जाता है
  • ऐप के पुराने साइनिंग सेर्ट्स जो ऐप पर अभी भी भरोसा करते हैं

हस्ताक्षरित-डेटा अनुभाग में प्रूफ-ऑफ-रोटेशन विशेषता में एक एकल-लिंक की गई सूची होती है, जिसमें प्रत्येक नोड में एप्लिकेशन के पिछले संस्करणों पर हस्ताक्षर करने के लिए हस्ताक्षरित प्रमाण पत्र होता है। यह विशेषता वैचारिक प्रमाण-रोटेशन और स्व-विश्वसनीय-पुराने-सेर्ट्स डेटा संरचनाओं को समाहित करने के लिए है। सूची रूट नोड के अनुरूप सबसे पुराने हस्ताक्षरित प्रमाण पत्र के साथ संस्करण द्वारा आदेशित है। प्रूफ-ऑफ-रोटेशन डेटा संरचना प्रत्येक नोड में प्रमाण पत्र को सूची में अगले पर हस्ताक्षर करके बनाया गया है, और इस प्रकार प्रत्येक नई कुंजी को सबूतों के साथ बनाया गया है कि इसे पुरानी कुंजी (एस) के रूप में विश्वसनीय होना चाहिए।

स्व-विश्वसनीय-पुराने-सेरेट्स डेटा संरचना का निर्माण प्रत्येक नोड में झंडे जोड़कर किया जाता है जो सेट में इसकी सदस्यता और गुणों को दर्शाता है। उदाहरण के लिए, एक ध्वज यह दर्शाता है कि एंड्रॉइड हस्ताक्षर की अनुमति प्राप्त करने के लिए किसी दिए गए नोड पर हस्ताक्षर प्रमाणपत्र पर भरोसा किया जा सकता है। यह ध्वज पुराने प्रमाणपत्र द्वारा हस्ताक्षरित अन्य ऐप्स को अभी भी हस्ताक्षर करने की अनुमति देता है जिसे नए हस्ताक्षर प्रमाणपत्र के साथ हस्ताक्षर किए गए एप्लिकेशन द्वारा परिभाषित किया गया है। चूँकि संपूर्ण प्रूफ-ऑफ-रोटेशन विशेषता v3 signer फ़ील्ड के हस्ताक्षरित डेटा सेक्शन में रहती है, इसलिए इसे signer युक्त साइन करने के लिए उपयोग की जाने वाली कुंजी द्वारा संरक्षित किया जाता है।

यह प्रारूप एक से अधिक हस्ताक्षर करने की कुंजी और एक साथ कई पूर्वजों के हस्ताक्षर प्रमाणपत्रों (एक प्रारंभिक सिंक के लिए कई नोड्स) के अभिसरण को रोकता है।

स्वरूप

प्रूफ-ऑफ-रोटेशन 0x3ba06f8c तहत 0x3ba06f8c सिग्नेचर स्कीम v3 ब्लॉक के अंदर संग्रहीत है। इसका प्रारूप है:

  • लंबाई-पहले से जुड़ा हुआ की लंबाई-उपसर्ग के अनुक्रम levels :
    • लंबाई-पूर्व- signed data (पिछले प्रमाण द्वारा - यदि मौजूद है)
      • लंबाई-उपसर्ग X.509 certificate (ASN.1 DER फॉर्म)
      • signature algorithm ID (uint32) - पिछले स्तर में प्रमाणित द्वारा उपयोग किया जाने वाला एल्गोरिदम
    • flags (uint32) - झंडे यह संकेत देते हैं कि यह प्रमाण-पत्र स्व-विश्वसनीय-पुराने-सेरेट्स संरचना में होना चाहिए, या किन कार्यों के लिए।
    • signature algorithm ID (uint32) - अगले स्तर में हस्ताक्षरित डेटा अनुभाग से एक से मेल खाना चाहिए।
    • उपरोक्त signed data पर लंबाई-पूर्व- signature

कई प्रमाण पत्र

एंड्रॉइड वर्तमान में एपीके को कई प्रमाणपत्रों के साथ हस्ताक्षरित मानता है, जिसमें एक विशिष्ट हस्ताक्षर पहचान शामिल है, जिसमें शामिल सीट्स हैं। इस प्रकार, हस्ताक्षर किए गए डेटा अनुभाग में प्रूफ-ऑफ-रोटेशन विशेषता एक निर्देशित एसाइक्लिक ग्राफ बनाता है, जिसे एक एकल नोड का प्रतिनिधित्व करने वाले दिए गए संस्करण के लिए साइनर्स के प्रत्येक सेट के साथ एक एकल-लिंक की गई सूची के रूप में देखा जा सकता है। यह प्रूफ-ऑफ-रोटेशन स्ट्रक्चर (नीचे मल्टी-साइनर संस्करण) में अतिरिक्त जटिलता जोड़ता है। विशेष रूप से, आदेश एक चिंता का विषय बन जाता है। क्या अधिक है, अब स्वतंत्र रूप से एपीके पर हस्ताक्षर करना संभव नहीं है, क्योंकि प्रूफ-ऑफ-रोटेशन संरचना में पुराने हस्ताक्षर वाले सीट्स को एक-एक करके हस्ताक्षर करने के बजाय, नए सेट के सेटर्स होने चाहिए। उदाहरण के लिए, कुंजी A द्वारा हस्ताक्षरित एक एपीके जिस पर दो नई कुंजियों B और C द्वारा हस्ताक्षर किए जाने की इच्छा है, B हस्ताक्षरकर्ता के पास A या B द्वारा केवल एक हस्ताक्षर शामिल नहीं हो सकता है, क्योंकि यह B और C. की तुलना में एक अलग हस्ताक्षर करने वाली पहचान है। इसका मतलब है कि हस्ताक्षरकर्ताओं को इस तरह की संरचना बनाने से पहले समन्वय करना चाहिए।

मल्टीपल साइनर्स प्रूफ-ऑफ-रोटेशन विशेषता

  • लंबाई-पहले से जुड़ा हुआ की लंबाई-उपसर्ग के अनुक्रम sets :
    • signed data (पिछले सेट द्वारा - यदि मौजूद है)
      • certificates की लंबाई-उपसर्ग अनुक्रम
        • लंबाई-उपसर्ग X.509 certificate (ASN.1 DER प्रपत्र)
      • signature algorithm IDs (uint32) की अनुक्रम - पिछले सेट से प्रत्येक प्रमाण पत्र के लिए एक ही क्रम में।
    • flags (uint32) - झंडे का संकेत है कि यह सेटों का सेट आत्म-विश्वसनीय-पुराने-सेर्ट्स संरचना में होना चाहिए और किन कार्यों के लिए।
    • लंबाई-उपसर्ग अनुक्रम लंबाई-उपसर्ग signatures :
      • signature algorithm ID (uint32) - हस्ताक्षरित डेटा अनुभाग से एक से मेल खाना चाहिए
      • उपर्युक्त signed data पर लंबाई-उपसर्ग signature

प्रूफ-ऑफ-रोटेशन संरचना में कई पूर्वजों

v3 योजना भी एक ही ऐप के लिए एक ही हस्ताक्षर करने वाली कुंजी को घुमाने वाली दो अलग-अलग कुंजियों को संभालती नहीं है। यह अधिग्रहण के मामले से अलग है, जहां अधिग्रहण करने वाली कंपनी अनुमतियों को साझा करने के लिए अपनी हस्ताक्षरित कुंजी का उपयोग करने के लिए अधिग्रहीत ऐप को स्थानांतरित करना चाहेगी। अधिग्रहण को एक समर्थित उपयोग-मामले के रूप में देखा जाता है क्योंकि नया ऐप इसके पैकेज नाम से अलग होगा और इसमें अपना स्वयं का प्रूफ-रोटेटिंग स्ट्रक्चर हो सकता है। असमर्थित मामला, एक ही ऐप के दो अलग-अलग रास्तों पर एक ही प्रमाणपत्र प्राप्त करने के लिए, कुंजी रोटेशन डिज़ाइन में बनाई गई बहुत सी मान्यताओं को तोड़ता है।

सत्यापन

एंड्रॉइड 9 और उच्चतर में, एपीके को एपीके सिग्नेचर स्कीम v3, v2 स्कीम, या v1 स्कीम के अनुसार सत्यापित किया जा सकता है। पुराने प्लेटफॉर्म v3 हस्ताक्षरों की उपेक्षा करते हैं और v2 हस्ताक्षरों को सत्यापित करने का प्रयास करते हैं, फिर v1।

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

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

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

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

मान्यकरण

यह जांचने के लिए कि आपका डिवाइस v3 को ठीक से सपोर्ट करता है, PkgInstallSignatureVerificationTest.java CTS टेस्ट को cts/hostsidetests/appsecurity/src/android/appsecurity/cts/