Google का मानना है कि हमारे प्रॉडक्ट, डिज़ाइन के हिसाब से सुरक्षित होने चाहिए. इसलिए, हमने सॉफ़्टवेयर-डिफ़ाइंड वीइकल के लिए Android Automotive ऑपरेटिंग सिस्टम (AAOS SDV) को मौजूदा, मार्केट में पहले से मौजूद प्लैटफ़ॉर्म पर बनाया है. इसके लिए, हमने Cuttlefish जैसी वर्चुअलाइज़ेशन टेक्नोलॉजी का इस्तेमाल किया है. रिलीज़ की सूचनाओं में, हमने सुविधाओं पर फ़ोकस किया था. हालांकि, इस ब्लॉग पोस्ट में सुरक्षा से जुड़े कुछ कॉन्सेप्ट के बारे में बताया गया है.
बुनियादी: डोमेन आइसोलेशन
को-होस्ट किए गए इंस्टेंस को अलग करने के लिए वर्चुअलाइज़ेशन
इलेक्ट्रॉनिक कंट्रोल यूनिट (ईसीयू) को एक ही चिप में जोड़ने के मौजूदा ट्रेंड की वजह से, कई डोमेन साथ-साथ चलते हैं. इससे आइसोलेशन कम हो जाता है.
AAOS SDV इंस्टेंस, इंटरनल आइसोलेशन मैकेनिज़्म उपलब्ध कराते हैं. हालांकि, लॉजिकल डोमेन को अलग-अलग चलाना ज़्यादा बेहतर होता है. उदाहरण के लिए, क्लस्टर और सूचना और मनोरंजन की सुविधा देने वाले डिवाइस की ज़रूरतें अलग-अलग होती हैं. हम वर्चुअल मशीनों का इस्तेमाल करके, एक साथ कई इंस्टेंस चलाते हैं. इससे यह पक्का होता है कि शेयर किया गया डेटा साफ़ तौर पर दिखे और आइसोलेशन डिफ़ॉल्ट तौर पर काम करे.
इनहेरिट की गई Android की सुरक्षा सुविधा
AAOS SDV को Microdroid से डेवलप किया गया है. यह Android का एक ऐसा वर्शन है जिसमें कम से कम सुविधाएं होती हैं. इसे प्राइवसी वर्चुअल मशीन (pVM) के लिए ऑप्टिमाइज़ किया गया है. इस लीनिएज से, Android प्लैटफ़ॉर्म के इंजीनियर को सुरक्षा से जुड़ी ऐसी सुविधाएं मिलती हैं जिनके बारे में उन्हें पहले से पता होता है.
अलग-अलग प्रोसेस के लिए टेक्नोलॉजी और डिफ़ॉल्ट रूप से अनुमति न देना
AAOS SDV, हर ऐप्लिकेशन के लिए सैंडबॉक्स सेट अप करने के लिए, Android के यूज़र आईडी (यूआईडी) पर आधारित आइसोलेशन मॉडल का इस्तेमाल करता है. हर सेवा, यूनीक यूआईडी के साथ एक खास प्रोसेस में चलती है. इससे ऐक्सेस के अधिकार, डेटा डायरेक्ट्री, और अन्य पाबंदियों को मैनेज किया जाता है. हम पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस (POSIX) की सुविधाओं का इस्तेमाल करते हैं, ताकि कार्रवाइयों को सीमित किया जा सके. साथ ही, हम इसे सिक्योरिटी-एन्हैंस्ड Linux (SELinux) के साथ जोड़ते हैं, ताकि "डिफ़ॉल्ट रूप से अनुमति न दें" की नीति को लागू किया जा सके. इस तरीके से, हर सेवा को सिर्फ़ ज़रूरी ऐक्सेस मिलता है. इसका मतलब है कि कॉन्फ़िगरेशन मौजूद न होने पर ऐक्सेस ब्लॉक हो जाता है, न कि ज़रूरत से ज़्यादा अनुमति वाला सिस्टम बनता है. हम इस रणनीति को कम्यूनिकेशन की अनुमति देने वाले सिस्टम पर भी लागू करते हैं. इसके बारे में इस लेख में आगे बताया गया है.
Proven Vulnerability Management
AAOS SDV, Android के बेहतर सुरक्षा रिस्पॉन्स और जोखिमों को मैनेज करने वाले इन्फ़्रास्ट्रक्चर को इंटिग्रेट करता है. इससे सुरक्षा से जुड़ी समस्याओं का पता लगाने, उन्हें प्राथमिकता देने, उन्हें ठीक करने, और उनके बारे में जानकारी देने में मदद मिलती है. इस लाइफ़साइकल में, लगातार अपने-आप होने वाली स्कैनिंग, हर साल होने वाली डीप-डाइव पेनेट्रेशन टेस्टिंग, और पार्टनर से मिलने वाली जानकारी शामिल होती है. यह जानकारी, Android की सुरक्षा से जुड़ी कमियों की शिकायत करने की प्रोसेस के ज़रिए मिलती है. सुरक्षा टीम, पता लगाए गए जोखिमों की जांच करती है. साथ ही, जोखिम के आधार पर गंभीरता की रेटिंग असाइन करती है और समस्या के हल होने तक उसे ट्रैक करती है. हम हर महीने Android सुरक्षा बुलेटिन के ज़रिए, जानकारी ज़ाहिर करने और रिलीज़ करने की नीतियों को मैनेज करते हैं. साथ ही, समय-समय पर सुरक्षा से जुड़े ऑडिट और आर्किटेक्चर की समीक्षाएं करते हैं, ताकि लंबे समय तक प्लैटफ़ॉर्म को सुरक्षित रखा जा सके.
इंटेग्रिटी: सॉफ़्टवेयर डिलीवरी को सुरक्षित करना
अलग-अलग प्रोसेस के लिए टेक्नोलॉजी की गारंटी देने के अलावा, एक सुरक्षित प्लैटफ़ॉर्म को यह पक्का करना चाहिए कि कोड को एक्ज़ीक्यूट करने से पहले, उसकी सुरक्षा की जांच की जाए. हम सॉफ़्टवेयर डिलीवरी को सुरक्षित रखने के लिए, ये तरीके अपनाते हैं:
पुष्टि किया गया सॉफ़्टवेयर डिलीवर करना
AAOS SDV को इंस्टॉल करने के दो तरीके हैं. सबसे पहले, हम सॉफ़्टवेयर को सीधे रीड-ओनली सिस्टम, प्रॉडक्ट या वेंडर पार्टिशन में इंस्टॉल करते हैं. ये पार्टिशन, हर बार बूट होने पर सिग्नेचर की पुष्टि करते हैं. इससे सिस्टम के बुनियादी कॉम्पोनेंट सुरक्षित रहते हैं.
दूसरा, हम सेवाओं के लिए Android Pony EXpress (APEX) पैकेज का इस्तेमाल करते हैं. हर APEX, सॉफ़्टवेयर और उसकी डिपेंडेंसी को एनकैप्सुलेट करता है. साथ ही, पैकेज को एक ऐसे पार्टिशन के तौर पर ट्रीट करता है जिसके लिए हस्ताक्षर की पुष्टि करना ज़रूरी है. AAOS SDV में, APEX कोड साइनिंग को एक लगातार चलने वाले, हार्डवेयर से लागू किए गए समझौते के तौर पर मानता है. APEX, चार मुख्य तरीकों से यह पक्का करता है कि नुकसान पहुंचाने वाले कोड को एक्ज़ीक्यूट करने से होने वाले जोखिम को कम किया जा सके:
1. इम्यूटेबल स्टोरेज
- मैकेनिज़्म: Android कर्नेल, रीड-ओनली लूपबैक का इस्तेमाल करके, apex_payload.img फ़ाइल को सीधे रॉ स्टोरेज डिवाइस के तौर पर लूप करता है. साथ ही, इसे सख्त MS_RDONLY फ़्लैग के साथ माउंट करता है.
- यह तरीका ज़्यादा सुरक्षित क्यों है: इससे ओएस को कोई राइट पाथ नहीं मिलता, क्योंकि फ़ाइलों को वाहन के स्टोरेज में अनपैक नहीं किया जाता. अगर किसी हैकर को रूट प्रिविलेज मिल भी जाता है, तो भी वह चल रहे APEX कोड में बदलाव नहीं कर सकता. ऐसा इसलिए, क्योंकि फ़ाइल सिस्टम लेयर, डेटा में बदलाव करने के सभी निर्देशों को अस्वीकार कर देती है.
2. क्रिप्टोग्राफ़िक इंटेग्रिटी
- यह कैसे काम करता है: क्रिप्टोग्राफ़िक सिग्नेचर, पूरे फ़ाइल सिस्टम की इमेज के मर्कल ट्री की पुष्टि करता है.
- यह ज़्यादा सुरक्षित क्यों है: कर्नल, हर ब्लॉक के लिए dm-verity का इस्तेमाल करता है, ताकि 4 केबी के हर डेटा ब्लॉक के हस्ताक्षर की तुरंत पुष्टि की जा सके. अगर कोई हमलावर फ़्लैश मेमोरी पर मौजूद रॉ ब्लॉक में बदलाव करता है, तो कर्नेल को हैश के मेल न खाने का पता चलता है और वह प्रोसेस को तुरंत रोक देता है.
3. सख्त आइसोलेशन
- मैकेनिज़्म: यह अलग-अलग प्रोसेस के लिए टेक्नोलॉजी के सेक्शन में बताए गए नियमों को लागू करता है, ताकि सैंडबॉक्स बनाया जा सके. इसमें APEX को /apex के तहत एक खास पार्टिशन के तौर पर माउंट किया जाता है.
- यह ज़्यादा सुरक्षित क्यों है: हर सेवा को अपना उपयोगकर्ता और डेटा डायरेक्ट्री मिलती है. इससे ऐक्सेस तब तक सीमित रहता है, जब तक कि डेटा को साफ़ तौर पर शेयर न किया जाए. एक खास पार्टिशन बनाकर, Android एक खास लिंकर नेमस्पेस बनाता है. इससे यह पक्का होता है कि बिना खास अधिकार वाले सिस्टम डीमन से, सिर्फ़ साफ़ तौर पर ज़ाहिर की गई लाइब्रेरी को ऐक्सेस किया जा सके. इससे हमले की जगह को कम किया जा सकता है.
4. ऐटॉमिक रिकवरी
- यह कैसे काम करता है: APEX, "ऐक्टिव/बैकअप" डिज़ाइन का इस्तेमाल करता है, ताकि डबल-बफ़र किए गए रोलबैक चालू किए जा सकें. फ़ैक्ट्री-फ़्लैश किया गया APEX, /system पार्टिशन में रहता है. इसमें बदलाव नहीं किया जा सकता. वहीं, अपडेट /data पार्टिशन में रहते हैं. इसमें बदलाव किया जा सकता है.
- यह ज़्यादा सुरक्षित क्यों है: अगर कोई अपडेट पूरा नहीं हो पाता है या नुकसान पहुंचाने वाला लगता है, तो अर्ली बूट के दौरान apexd डीमन उसे "पूरा नहीं हुआ" के तौर पर मार्क कर देता है. सिस्टम, सॉफ़्ट लिंक को तुरंत /system पार्टिशन में वापस स्वैप कर देता है. इस तरह की रिकवरी से यह पक्का करने में मदद मिलती है कि सिस्टम खराब स्थिति में न रहे.
लचीलापन: मेमोरी-सेफ़ डेवलपमेंट
वेरिफ़ाइड लोडिंग, सिस्टम को बाहरी बदलावों से सुरक्षित रखती है. हालांकि, प्लैटफ़ॉर्म की सुरक्षा इस बात पर भी निर्भर करती है कि उसका कोड कैसे बनाया गया है. AAOS SDV के लिए बनाए गए नए कॉम्पोनेंट के लिए, हमने मेमोरी की सुरक्षा को प्राथमिकता दी.
मुख्य भाषा के तौर पर Rust
AAOS SDV, छोटे सिस्टम को टारगेट करता है. इसके लिए, ज़रूरी है कि सिस्टम तेज़ी से उपलब्ध हो. इस वजह से, पूरे Android स्टैक पर ऐप्लिकेशन नहीं बनाए जा सकते. इसलिए, हमने अपने दायरे को नेटिव फ़्रेमवर्क तक सीमित कर दिया है. डिस्ट्रिब्यूटेड सिस्टम के लिए ज़रूरी इन्फ़्रास्ट्रक्चर बनाने के लिए, हमने मौजूदा इन्फ़्रास्ट्रक्चर के अलावा कई कॉम्पोनेंट डेवलप किए. साथ ही, Rust को मुख्य भाषा के तौर पर अपनाया. हम सेवाओं के कारोबारी नियम को डेवलप करने के लिए भी Rust का इस्तेमाल करते हैं. इससे पार्टनर को सुरक्षित सॉफ़्टवेयर लिखने में मदद मिलती है. Rust को इस तरह से डिज़ाइन किया गया है कि यह मेमोरी की सुरक्षा से जुड़ी सुविधाओं का इस्तेमाल करता है. इससे मेमोरी की सुरक्षा से जुड़ी आम कमियों को रोकने में मदद मिलती है. साथ ही, नेटिव कोड लिखते समय टीम की परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलती है.
डिस्ट्रिब्यूटेड ट्रस्ट: नेटवर्क और ऐक्सेस कंट्रोल
सॉफ़्टवेयर-परिभाषित वाहनों को अलग-अलग डोमेन के बीच सुरक्षित इंटरैक्शन की ज़रूरत होती है. AAOS SDV मेश प्रोविज़निंग आर्किटेक्चर, इस समस्या को हल करता है. इसके लिए, वह हर कम्यूनिकेशन एंडपॉइंट के वर्शन और लेखक की पुष्टि क्रिप्टोग्राफ़िक तरीके से करता है.
डिवाइस और मेश प्रोविज़निंग
AAOS SDV मेश, हर कॉम्पोनेंट की नेटवर्क आइडेंटिटी को उसके असल बाइनरी एक्ज़ीक्यूशन स्टेट से गणितीय तरीके से जोड़कर, पुष्टि करने की सुविधा सेट अप करता है. यह मॉडल, सॉफ़्टवेयर पर भरोसा करने के बजाय, हार्डवेयर-रूटेड पुष्टि का इस्तेमाल करता है.
मेश ऑथेंटिकेशन को लगातार और क्रिप्टोग्राफ़िक तरीके से काम करने के लिए डिज़ाइन किया गया है. इससे ऐसी स्थितियों से बचा जा सकता है जहां, उदाहरण के लिए, वाहन के गेटवे जैसी कोई सेवा, किसी ऐसे इंफ़ोटेनमेंट वीएम पर भरोसा करती है जिसके साथ छेड़छाड़ की गई है. ऐसा सिर्फ़ इसलिए होता है, क्योंकि उसके पास सही आईपी पता होता है.
हार्डवेयर की मदद से लागू किए गए आइसोलेशन और अपने-आप क्वॉरंटीन करने वाले प्रोटोकॉल, प्लैटफ़ॉर्म को सुरक्षित रखते हैं. एसडीवी मेश में मौजूद पीयर डिवाइस, DICE पर आधारित पुष्टि और अटेस्टेशन का इस्तेमाल करते हैं. इसके बारे में यहां दी गई जानकारी में बताया गया है. इससे, बिना अनुमति के कोड को एक्ज़ीक्यूट करने या कॉन्फ़िगरेशन में छेड़छाड़ करने की पहचान करने और उसे रोकने में मदद मिलती है.
वीएम के बीच होने वाले कम्यूनिकेशन को सुरक्षित रखने के लिए, डीआईसीई पर आधारित टीएलएस
होस्ट की पहचान को असलियत से जोड़ना
डिवाइस आइडेंटिफ़ायर कंपोज़िशन इंजन (डीआईसीई) का गोल्डन रूल: अगर फ़र्मवेयर में कोड की एक लाइन भी बदलती है (चाहे वह मामूली अपडेट हो या नुकसान पहुंचाने वाला कोई एक्सप्लॉइट), तो जनरेट किया गया कंपाउंड डिवाइस आइडेंटिफ़ायर (सीडीआई) पूरी तरह से बदल जाता है. इससे पूरी तरह से अलग एलियस कुंजी जनरेट होती है.
DICE और टीएलएस (ट्रांसपोर्ट लेयर सिक्योरिटी) को इंटिग्रेट करके, ज़ीरो-ट्रस्ट आर्किटेक्चर की बुनियादी समस्या को हल किया जाता है. यह समस्या है: किसी मशीन की पहचान की पुष्टि करने के साथ-साथ, उसके सॉफ़्टवेयर की सुरक्षा की पुष्टि करना.
DICE के हार्डवेयर-आधारित आइडेंटिफ़िकेशन और टीएलएस के एन्क्रिप्ट किए गए हैंडशेक की मदद से, कॉल पाने वाली मशीन, कॉल करने वाले की पहचान और उसके सॉफ़्टवेयर की सटीक स्थिति, दोनों की पुष्टि कर सकती है.
पारंपरिक सर्टिफ़िकेट से सिर्फ़ यह साबित होता है कि आपके पास सीक्रेट है. इनसे फ़र्मवेयर में की गई छेड़छाड़ का पता नहीं लगाया जा सकता. DICE, मेजर्ड बूट लेयरिंग की मदद से ऐसा करता है:
- यूनीक डिवाइस सीक्रेट (यूडीएस): यह मैन्युफ़ैक्चरिंग के दौरान जनरेट किया गया एक रैंडम क्रिप्टोग्राफ़िक सीक्रेट होता है. सिर्फ़ पहले चरण का बूटलोडर, यूडीएस को ऐक्सेस कर सकता है. इसे अन्य सभी सॉफ़्टवेयर और बाहरी इंटरफ़ेस ऐक्सेस नहीं कर सकते.
- लेयर्ड मेज़रमेंट (कंपाउंड डिवाइस आइडेंटिफ़ायर): हार्डवेयर आरओएम, यूडीएस को अगली फ़र्मवेयर लेयर के सटीक कोड और कॉन्फ़िगरेशन के साथ हैश करके चेन शुरू करता है. इससे एक सीडीआई बनता है, जो हर लेयर के बूट होने पर क्रम से चेन बनाता है.
AAOS SDV मेश में, सेवाओं के बीच होने वाले इंटरैक्शन को ऐक्सेस कंट्रोल की सख्त नीतियों के तहत मैनेज किया जाता है. AAOS SDV के सभी सॉफ़्टवेयर की तरह, इन ऐक्सेस कंट्रोल की पुष्टि की जाती है. साथ ही, डिवाइस के लेवल पर और मेश में मौजूद सभी डिवाइसों पर, डीआईसीई पर आधारित पुष्टि करने की सुविधा के ज़रिए इनकी सुरक्षा की जाती है.
लेयर्ड ऐक्सेस कंट्रोल
AAOS SDV, मज़बूत सुरक्षा की रणनीति का इस्तेमाल करता है. इससे ऐक्सेस मैकेनिज़्म से समझौता किए बिना, वाहन के लिए डाइनैमिक अपडेट चालू किए जा सकते हैं. यह मॉडल, भरोसे की दो मुख्य लेयर पर निर्भर करता है:
- सेवा-लेवल की अनुमतियां: यह तय करें कि किसी वीएम पर मौजूद सेवा, मेश में किन संसाधनों को ऐक्सेस या एक्सपोज़ कर सकती है.
- वीएम-लेवल की अनुमतियां: किसी खास वीएम पर होस्ट की गई सभी सेवाओं के लिए, क्रॉस-वीएम कम्यूनिकेशन की सीमाएं तय करें.
इस मॉडल की मदद से, ओईएम सुरक्षा और अपडेट की क्षमता के बीच संतुलन बना सकते हैं. सुरक्षा के लिहाज़ से संवेदनशील न होने वाली सेवाओं के लिए, वीएम-लेवल की अनुमति देने वाली नीतियां, पूरे वीएम को फिर से डिप्लॉय करने के बजाय, लाइटवेट APEX अपडेट के ज़रिए इंस्टॉल करने की सुविधा देती हैं.
इसके उलट, सुरक्षा से जुड़े संवेदनशील सिग्नल के लिए अनुमतियां, हर वीएम में हार्ड-कोड की जानी चाहिए. हालांकि, किसी नए वीएम में सुरक्षा से जुड़ी संवेदनशील सेवा को शामिल करने के लिए, पूरे सिस्टम में वीएम-लेवल की अनुमतियों को अपडेट करना पड़ता है. इस वजह से, मेश में मौजूद सभी वीएम को अपडेट करना ज़रूरी है.
नतीजा
AAOS SDV, Android के सुरक्षा आर्किटेक्चर को बेहतर बनाता है. इससे, वाहन से जुड़ी खास ज़रूरतों को पूरा करने के लिए, सुरक्षा को ध्यान में रखकर तैयार किया गया तरीका अपनाया जाता है. डोमेन आइसोलेशन के लिए वर्चुअलाइज़ेशन का इस्तेमाल करके और "डिफ़ॉल्ट रूप से ऐक्सेस न दें" वाली ऐक्सेस नीतियां लागू करके, यह प्लैटफ़ॉर्म सॉफ़्टवेयर-परिभाषित वाहनों के लिए एक सुरक्षित और भरोसेमंद एनवायरमेंट बनाता है. क्रिप्टोग्राफ़िक इंटेग्रिटी को बनाए रखने के लिए, हार्डवेयर की मदद से कोड की पुष्टि की जाती है.
इस प्लैटफ़ॉर्म में, सुरक्षा से जुड़े लाइफ़साइकल लगातार काम करते रहते हैं. इनमें, कमज़ोरियों को पहले से मैनेज करने से लेकर, डीआईसीई के ज़रिए हार्डवेयर-रूटेड पहचान की पुष्टि करना शामिल है. सुरक्षा की इन कई लेयर की मदद से, ओईएम ऐडवांस सुविधाओं को अपडेट करने की क्षमता और आधुनिक ऑटोमोटिव एनवायरमेंट के लिए ज़रूरी मज़बूत सुरक्षा के बीच संतुलन बना पाते हैं. तकनीकी जानकारी और इसे लागू करने के बारे में जानकारी, AAOS SDV की खास जानकारी वाले पेज पर उपलब्ध है.
-
प्रॉडक्ट से जुड़ी खबरेंआज से, Android Auto और Google की सुविधाओं वाले Android Automotive OS की सुविधा वाली कारों के लिए गेम कैटगरी, बीटा वर्शन से अपग्रेड होकर सामान्य रूप से उपलब्ध हो गई है.
Jan Kleinert • तीन मिनट में पढ़ा जा सकता है -
प्रॉडक्ट से जुड़ी खबरेंदुनिया भर में आधे से ज़्यादा मोबाइल गेम, Unity की मदद से बनाए जाते हैं. इसलिए, पहला इंप्रेशन बहुत मायने रखता है. गेम डेवलपर के लिए, खिलाड़ियों को गेम में शामिल करने का आसान और भरोसेमंद अनुभव देना ज़रूरी है. इससे, गेम लॉन्च होने के पहले दिन से ही खिलाड़ियों को बनाए रखने और लंबे समय तक उनकी दिलचस्पी बनाए रखने में मदद मिलती है.
Michelle Martin • पढ़ने में लगने वाला समय: 1 मिनट -
प्रॉडक्ट से जुड़ी खबरेंAndroid XR पर ऐप्लिकेशन बनाने से, उपयोगकर्ताओं को घर पर इमर्सिव अनुभव मिलता है. साथ ही, उन्हें चलते-फिरते भी ऐप्लिकेशन इस्तेमाल करने का शानदार अनुभव मिलता है. इससे उपयोगकर्ताओं को स्पेशल ऐप्लिकेशन के हर स्पेक्ट्रम में, किसी भी समय बेहतर अनुभव मिलता है. Android डेवलपर समिट में, हमने XREAL AURA को लॉन्च करके एक अहम उपलब्धि हासिल की.
Amy Zeppenfeld, Vinny DaSilva • तीन मिनट में पढ़ा जा सकता है
Android डेवलपमेंट से जुड़ी ताज़ा अहम जानकारी, हर हफ़्ते अपने इनबॉक्स में पाएं.
