APK हस्ताक्षर योजना v3

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

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

v1 एपीके प्रारूप के साथ पश्च-संगतता बनाए रखने के लिए, v2 और v3 एपीके हस्ताक्षर एक एपीके साइनिंग ब्लॉक के अंदर संग्रहीत किए जाते हैं, जो ज़िप केंद्रीय निर्देशिका से ठीक पहले स्थित होता है।

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

APK हस्ताक्षर योजना v3 ब्लॉक

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

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

प्रारूप

APK हस्ताक्षर योजना v3 ब्लॉक APK आईडी के तहत ब्लॉक साइन इन करना के अंदर संग्रहित 0xf05368c0

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

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

प्रूफ-ऑफ-रोटेशन और आत्म-विश्वसनीय-पुराने-सर्ट संरचनाएं

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

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

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

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

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

प्रारूप

-का-प्रमाण रोटेशन APK हस्ताक्षर योजना आईडी के तहत ब्लॉक v3 के अंदर संग्रहित 0x3ba06f8c । इसका प्रारूप है:

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

एकाधिक प्रमाणपत्र

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

एकाधिक हस्ताक्षरकर्ता प्रूफ-ऑफ-रोटेशन विशेषता

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

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

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

सत्यापन

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

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

चित्र 1 APK हस्ताक्षर सत्यापन प्रक्रिया

APK हस्ताक्षर योजना v3 सत्यापन

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

मान्यकरण

परीक्षण करने के लिए है कि आपके डिवाइस का समर्थन करता है ठीक से V3, चलाने PkgInstallSignatureVerificationTest.java में सीटीएस परीक्षण cts/hostsidetests/appsecurity/src/android/appsecurity/cts/