Android के मेनलाइन मॉड्यूल की पारदर्शिता

Android OS पर लोगों का भरोसा बढ़ाने के लिए, हम हर Android OS मॉड्यूल (जिसे Mainline कहा जाता है) को अपनी पारदर्शिता लॉग में शामिल करने के लिए प्रतिबद्ध हैं. यह मॉड्यूल, Google Play के ज़रिए अपडेट के तौर पर उपलब्ध कराया जाता है. हम इन मॉड्यूल के बारे में किए गए दावों की पुष्टि करने के लिए, पारदर्शिता लॉग पब्लिश करते हैं. पहले से इंस्टॉल किए गए मॉड्यूल को साफ़ तौर पर सूची में शामिल नहीं किया जाता, क्योंकि वे पहले से ही Pixel बाइनरी पारदर्शिता के तहत आते हैं.

खतरे का मॉडल

सप्लाई चेन पर होने वाले हमलों का पता लगाने और उन्हें रोकने के लिए, पारदर्शिता सिस्टम का इस्तेमाल किया जा सकता है. हम कुछ उदाहरणों की मदद से इसे समझाते हैं.

मान लें कि कोई हमलावर, Mainline मॉड्यूल में नुकसान पहुंचाने के इरादे से बदलाव करता है. यह मॉड्यूल, APEX या APK फ़ाइल हो सकती है. साथ ही, वह Google Play के ज़रिए डिस्ट्रिब्यूशन के लिए इस्तेमाल किए जाने वाले साइनिंग पासकोड से, इस मॉड्यूल को साइन भी कर लेता है. जिस व्यक्ति को ऐसा मॉड्यूल मिलता है जिस पर शक हो, वह मॉड्यूल की असलियत की पुष्टि करने के लिए, बाइनरी पारदर्शिता लॉग के बारे में क्वेरी कर सकता है. उसे पता चलेगा कि Google ने लॉग में, इससे जुड़े मॉड्यूल का मेटाडेटा शामिल नहीं किया है. साथ ही, उसे यह भी पता चलेगा कि उसे नुकसान पहुंचाने वाले OS मॉड्यूल पर भरोसा नहीं करना चाहिए.

लॉग में पब्लिश करना, साइनिंग के साथ रिलीज़ करने की प्रोसेस से अलग है. इसलिए, हमलावर के लिए सिर्फ़ पासकोड से समझौता करने के अलावा, और भी चुनौतियां बढ़ जाती हैं.

हमारी योजना है कि इस लॉग को, गवाहों के सार्वजनिक नेटवर्क में भी इंटिग्रेट किया जाए. इसके लिए, गवाहों के स्टैंडर्ड प्रोटोकॉल का इस्तेमाल किया जाएगा. हालांकि, हम बाहरी और स्वतंत्र पक्षों को इस सार्वजनिक तौर पर उपलब्ध लॉग की इंटिग्रिटी की निगरानी करने के लिए बढ़ावा देते हैं. ये पक्ष, लॉग की सिर्फ़ जोड़ने की प्रॉपर्टी की पुष्टि कर सकते हैं. साथ ही, उसमें किसी भी तरह की छेड़छाड़ की शिकायत कर सकते हैं.

इस तरह के पारदर्शिता सिस्टम के होने और हमलों के बारे में ज़्यादा जानकारी मिलने से, नुकसान पहुंचाने वाली गतिविधि को बढ़ावा नहीं मिलता. अगर किसी OS मॉड्यूल से समझौता किया जाता है, लेकिन उपयोगकर्ता सिर्फ़ उन मॉड्यूल पर भरोसा करते हैं जो लॉग में शामिल हैं, तो समझौते किए गए मॉड्यूल को सार्वजनिक तौर पर दिखाना होगा. इससे, समझौते किए गए मॉड्यूल के बारे में पता चलने की संभावना बढ़ जाती है. साथ ही, इसके डिस्ट्रिब्यूशन को रोकने के लिए कार्रवाई की जा सकती है.

दावेदार मॉडल

दावेदार मॉडल, पुष्टि किए जा सकने वाले सिस्टम में भूमिकाओं और आर्टफ़ैक्ट को तय करने के लिए इस्तेमाल किया जाने वाला फ़्रेमवर्क है. Android Mainline मॉड्यूल की पारदर्शिता के मामले में, हमारा दावा है कि इस लॉग में रिकॉर्ड की गई मॉड्यूल फ़ाइल का हैश, सार्वजनिक इस्तेमाल के लिए बने आधिकारिक Android मॉड्यूल के किसी खास वर्शन को दिखाता है.

• Claim^{MainlineModule}: (मैं, Google, दावा करता हूं कि $hashModule के लिए है $mainlineModule). इसमें:
  • $hashModule, $mainlineModule के किसी खास वर्शन की OS मॉड्यूल फ़ाइल का क्रिप्टोग्राफ़िक हैश (उदाहरण के लिए, SHA256) है.
  • $mainlineModule APEX (APEX) या Android पैकेज (APK) है. यह OS मॉड्यूल बनाता है जिसे Google बनाता है, साइन करता है, और डिस्ट्रिब्यूट करता है.

$mainlineModule की कॉपी वाला कोई भी व्यक्ति, इस दावे की पुष्टि कर सकता है. पुष्टि करने वाले पेज पर, इस प्रोसेस के बारे में ज़्यादा जानकारी दी गई है. ये चरण, सामान्य APK और Mainline मॉड्यूल, दोनों पर लागू होते हैं. Mainline मॉड्यूल, APK या APEX फ़ाइलें हो सकती हैं.

लॉग का कॉन्टेंट

जब Google, Mainline मॉड्यूल का नया वर्शन रिलीज़ करता है, तो वह Mainline मॉड्यूल की पारदर्शिता लॉग में उससे जुड़ी एंट्री जोड़ता है.

इस लॉग की हर एंट्री में, चार तरह का मेटाडेटा होता है:

1. साइन किए गए Android Mainline मॉड्यूल के APK या APEX का हैश. यह पूरी फ़ाइल के SHA256 डाइजेस्ट की हेक्स स्ट्रिंग है.
2. ऊपर दिए गए हैश के टाइप की जानकारी. यह एक स्ट्रिंग है.
3. मॉड्यूल का पैकेज नाम. यह एक स्ट्रिंग है.
4. मॉड्यूल का वर्शन नंबर (versionCode). यह शून्य से बड़ा पूर्णांक है.

लॉग एंट्री का फ़ॉर्मैट, जानकारी के चार हिस्सों को नई लाइन (\n) वाले वर्ण के साथ जोड़कर बनाया जाता है. इसे यहां दिखाया गया है:

hash\nhash_description\npackage_name\npackage_version\n

Mainline मॉड्यूल, APK या APEX फ़ाइल हो सकती है. इसलिए, हैश की जानकारी SHA256(APK) या SHA256(APEX) हो सकती है.