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) - यदि प्लेटफ़ॉर्म संस्करण इस संख्या से कम है तो इस हस्ताक्षरकर्ता को अनदेखा किया जाना चाहिए।
      • 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 सेंट्रल डायरेक्टरी को ZIP डायरेक्टरी के ZIP एंड के तुरंत बाद रिकॉर्ड किया जाता है।
    3. अधिक डेटा के बाद सेंट्रल डायरेक्टरी के ZIP एंड का पालन नहीं किया जाता है।
  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/