AAOS SDV - Secure by Design

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 सुरक्षा बुलेटिन के ज़रिए, जानकारी ज़ाहिर करने और रिलीज़ करने की नीतियों को मैनेज करते हैं. साथ ही, समय-समय पर सुरक्षा से जुड़े ऑडिट और आर्किटेक्चर की समीक्षाएं करते हैं, ताकि प्लैटफ़ॉर्म को लंबे समय तक सुरक्षित रखा जा सके.

इंटेग्रिटी: सॉफ़्टवेयर को सुरक्षित तरीके से डिलीवर करना

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

Authenticated Software Delivery

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, मेजर्ड बूट लेयरिंग की मदद से इस समस्या को हल करता है:

• यूनीक डिवाइस सीक्रेट (यूडीएस): यह मैन्युफ़ैक्चरिंग के दौरान जनरेट किया गया एक रैंडम क्रिप्टोग्राफ़िक सीक्रेट होता है. सिर्फ़ पहले चरण का बूटलोडर, यूडीएस को ऐक्सेस कर सकता है. अन्य सभी सॉफ़्टवेयर और बाहरी इंटरफ़ेस इसे ऐक्सेस नहीं कर सकते.
• लेयर्ड मेज़रमेंट (कंपाउंड डिवाइस आइडेंटिफ़ायर): हार्डवेयर ROM, यूडीएस को अगली फ़र्मवेयर लेयर के सटीक कोड और कॉन्फ़िगरेशन के साथ हैश करके चेन शुरू करता है. इससे एक सीडीआई बनता है. इसके बाद, हर लेयर के बूट होने पर, यह क्रम से चेन होता है.

AAOS SDV मेश में, सेवाओं के बीच होने वाले इंटरैक्शन को ऐक्सेस कंट्रोल की सख्त नीतियों के तहत मैनेज किया जाता है. AAOS SDV के सभी सॉफ़्टवेयर की तरह, इन ऐक्सेस कंट्रोल की पुष्टि की जाती है. साथ ही, डिवाइस के लेवल पर और मेश में मौजूद सभी डिवाइसों पर, DICE पर आधारित पुष्टि करने की सुविधा के ज़रिए इनकी सुरक्षा की जाती है.

लेयर्ड ऐक्सेस कंट्रोल

AAOS SDV, मज़बूत सुरक्षा की रणनीति का इस्तेमाल करता है. इससे ऐक्सेस करने के तरीकों से समझौता किए बिना, वाहन के लिए डाइनैमिक अपडेट चालू किए जा सकते हैं. यह मॉडल, भरोसे की दो मुख्य लेयर पर निर्भर करता है:

1. सेवा-लेवल की अनुमतियां: यह तय करें कि किसी वीएम पर मौजूद सेवा, मेश में किन संसाधनों को ऐक्सेस या एक्सपोज़ कर सकती है.
2. वीएम-लेवल की अनुमतियां: किसी खास वीएम पर होस्ट की गई सभी सेवाओं के लिए, क्रॉस-वीएम कम्यूनिकेशन की सीमाएं तय करें.

इस मॉडल की मदद से, ओईएम सुरक्षा और अपडेट की क्षमता के बीच संतुलन बना सकते हैं. सुरक्षा के लिहाज़ से संवेदनशील नहीं होने वाली सेवाओं के लिए, वीएम-लेवल की अनुमति देने वाली नीतियां, पूरे वीएम को फिर से डिप्लॉय करने के बजाय, लाइटवेट APEX अपडेट के ज़रिए इंस्टॉल करने की सुविधा देती हैं.

इसके उलट, सुरक्षा के लिहाज़ से संवेदनशील सिग्नल के लिए अनुमतियां, हर वीएम में हार्ड-कोड की जानी चाहिए. हालांकि, किसी नए वीएम में सुरक्षा से जुड़ी संवेदनशील सेवा को शामिल करने के लिए, पूरे सिस्टम में वीएम-लेवल की अनुमतियों को अपडेट करना पड़ता है. इसके लिए, मेश में मौजूद सभी वीएम को अपडेट करना ज़रूरी है.

नतीजा

AAOS SDV, Android के सुरक्षा आर्किटेक्चर को बेहतर बनाता है. इससे, ऑटोमोटिव से जुड़ी खास ज़रूरतों को पूरा करने के लिए, सुरक्षा को ध्यान में रखकर तैयार किया गया तरीका अपनाया जाता है. डोमेन आइसोलेशन के लिए वर्चुअलाइज़ेशन का इस्तेमाल करके और "डिफ़ॉल्ट रूप से ऐक्सेस न दें" वाली ऐक्सेस नीतियां लागू करके, यह प्लैटफ़ॉर्म सॉफ़्टवेयर-परिभाषित वाहनों के लिए एक सुरक्षित और भरोसेमंद एनवायरमेंट बनाता है. क्रिप्टोग्राफ़िक इंटेग्रिटी को बनाए रखने के लिए, हार्डवेयर की मदद से कोड की पुष्टि की जाती है.

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