AAOS SDV - सुरक्षा को ध्यान में रखकर डिज़ाइन किया गया

Google का मानना है कि हमारे प्रॉडक्ट को सुरक्षा को ध्यान में रखकर डिज़ाइन किया जाना चाहिए. इसलिए, हमने सॉफ़्टवेयर-डिफ़ाइंड व्हीकल (एसडीवी) के लिए Android Automotive ऑपरेटिंग सिस्टम (AAOS SDV) को, बाज़ार में पहले से मौजूद और साबित हो चुके प्लैटफ़ॉर्म पर बनाया है. इसके लिए, हमने Cuttlefish जैसी वर्चुअलाइज़ेशन टेक्नोलॉजी का इस्तेमाल किया है. हमारे रिलीज़ से जुड़े एलान में, सुविधाओं पर फ़ोकस किया गया है. हालांकि, इस ब्लॉग पोस्ट में सुरक्षा से जुड़े कुछ कॉन्सेप्ट के बारे में बताया गया है.

आधार: डोमेन आइसोलेशन

को-होस्ट किए गए इंस्टेंस को अलग करने के लिए वर्चुअलाइज़ेशन

इलेक्ट्रॉनिक कंट्रोल यूनिट (ईसीयू) को एक ही चिप में कंसोलिडेट करने के मौजूदा ट्रेंड से, आइसोलेशन कम हो जाता है. ऐसा इसलिए, क्योंकि इसमें एक साथ कई डोमेन चलते हैं.

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

Android की सुरक्षा से जुड़ी सुविधाएं

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

प्रोसेस आइसोलेशन और डिफ़ॉल्ट रूप से अनुमति न देना

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

जोखिम की आशंका के मैनेजमेंट का साबित हो चुका तरीका

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

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

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

सॉफ़्टवेयर की पुष्टि करके डिलीवरी करना

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

दूसरा तरीका यह है कि हम सेवाओं के लिए, Android Pony EXpress (APEX) पैकेज का इस्तेमाल करते हैं. हर APEX में सॉफ़्टवेयर और उसकी डिपेंडेंसी शामिल होती हैं. इसमें पैकेज को, ज़रूरी सिग्नेचर की पुष्टि के साथ एक पार्टीशन के तौर पर माना जाता है. AAOS SDV में, APEX, कोड साइनिंग को लगातार चलने वाले और हार्डवेयर से लागू किए जाने वाले कॉन्ट्रैक्ट के तौर पर मानता है. APEX, नुकसान पहुंचाने वाले कोड के एक्ज़ीक्यूशन को चार मुख्य पिलर के ज़रिए कम करता है: 

1. बदलाव न किया जा सकने वाला स्टोरेज

• मैकेनिज़्म: Android कर्नल, apex_payload.img फ़ाइल को सीधे तौर पर, रॉ स्टोरेज डिवाइस के तौर पर लूप करता है. इसके लिए, सिर्फ़ पढ़ने के लिए उपलब्ध लूपबैक का इस्तेमाल किया जाता है. साथ ही, इसे MS_RDONLY फ़्लैग के साथ माउंट किया जाता है.
• यह ज़्यादा सुरक्षित क्यों है: इससे ओएस के लिए कोई राइट पाथ नहीं दिखता, क्योंकि फ़ाइलों को वाहन के स्टोरेज में अनपैक नहीं किया जाता. अगर किसी हमलावर को रूट के विशेषाधिकार मिल जाते हैं, तब भी वे चालू APEX कोड में बदलाव नहीं कर सकते, क्योंकि फ़ाइल सिस्टम लेयर, सभी राइट कमांड को अस्वीकार कर देती है.

2. क्रिप्टोग्राफ़िक इंटेग्रिटी

• मैकेनिज़्म: क्रिप्टोग्राफ़िक सिग्नेचर, पूरे फ़ाइल सिस्टम इमेज के मर्कल ट्री की पुष्टि करता है.
• यह ज़्यादा सुरक्षित क्यों है: कर्नल, हर 4 केबी डेटा ब्लॉक के लिए, ऑन-द-फ़्लाई सिग्नेचर की पुष्टि करने के लिए, पर-ब्लॉक dm-verity का इस्तेमाल करता है. अगर कोई हमलावर, फ़्लैश मेमोरी पर किसी रॉ ब्लॉक में बदलाव करता है, तो कर्नल, हैश के मेल न खाने का पता लगाता है और तुरंत एक्ज़ीक्यूशन रोक देता है.

3. सख्त आइसोलेशन

• मैकेनिज़्म: यह, प्रोसेस आइसोलेशन सेक्शन में बताए गए प्रोसेस आइसोलेशन के नियमों को लागू करके, सैंडबॉक्स बनाता है. इसमें APEX को /apex के तहत एक अलग पार्टीशन के तौर पर माउंट किया जाता है.
• यह ज़्यादा सुरक्षित क्यों है: हर सेवा को अपना यूज़र और डेटा डायरेक्ट्री मिलती है. इससे, साफ़ तौर पर शेयरिंग किए बिना, ऐक्सेस सीमित हो जाता है. एक अलग पार्टीशन बनाकर, Android एक अलग लिंकर नेमस्पेस बनाता है. इससे यह पक्का होता है कि बिना विशेषाधिकार वाले सिस्टम डेमॉन से, सिर्फ़ साफ़ तौर पर दिखाई गई लाइब्रेरी को ऐक्सेस किया जा सके. इस तरह, हमले की संभावना कम हो जाती है.

4. ऐटॉमिक रिकवरी

• मैकेनिज़्म: APEX, "ऐक्टिव/बैकअप" डिज़ाइन का इस्तेमाल करके, डबल-बफ़र्ड रोलबैक की सुविधा देता है. फ़ैक्ट्री-फ़्लैश किया गया APEX, /system पार्टीशन पर मौजूद रहता है. इसमें बदलाव नहीं किया जा सकता. वहीं, अपडेट, /data पार्टीशन पर मौजूद रहते हैं. इनमें बदलाव किया जा सकता है.
• यह ज़्यादा सुरक्षित क्यों है: अगर कोई अपडेट फ़ेल हो जाता है या नुकसान पहुंचाने वाला लगता है, तो apexd डेमॉन, शुरुआती बूट के दौरान उसे "फ़ेल" के तौर पर मार्क करता है. सिस्टम, सिम्बॉलिक लिंक को तुरंत /system पार्टीशन पर वापस ले जाता है. ऐटॉमिक रिकवरी से यह पक्का करने में मदद मिलती है कि सिस्टम, खराब स्थिति में न रहे.

रेज़िलियंस: मेमोरी-सेफ़ डेवलपमेंट

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

Rust को मुख्य भाषा के तौर पर इस्तेमाल करना

AAOS SDV, छोटे सिस्टम के लिए है. साथ ही, इसे तुरंत उपलब्ध कराने की ज़रूरत होती है. इसलिए, इसे Android के पूरे स्टैक पर नहीं बनाया जा सकता. इसलिए, हमने अपना दायरा नेटिव फ़्रेमवर्क तक सीमित रखा. डिस्ट्रिब्यूट किए गए सिस्टम के लिए ज़रूरी इन्फ़्रास्ट्रक्चर बनाने के लिए, हमने मौजूदा इन्फ़्रास्ट्रक्चर के अलावा कई कॉम्पोनेंट बनाए. साथ ही, Rust को मुख्य भाषा के तौर पर इस्तेमाल किया. हम सेवाओं के कारोबारी नियम डेवलप करने के लिए भी Rust का इस्तेमाल करते हैं. इससे पार्टनर को सुरक्षित सॉफ़्टवेयर लिखने में मदद मिलती है. By design, Rust, मेमोरी की सुरक्षा से जुड़ी सुविधाओं का इस्तेमाल करके, मेमोरी की सुरक्षा से जुड़े जोखिमों की आम कैटगरी से बचने में मदद करता है. साथ ही, नेटिव कोड लिखते समय, टीम के थ्रूपुट को भी बेहतर बनाता है.

डिस्ट्रिब्यूटेड ट्रस्ट: नेटवर्क और ऐक्सेस कंट्रोल

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

डिवाइस और मेश प्रोविज़निंग

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

मेश ऑथेंटिकेशन को लगातार और क्रिप्टोग्राफ़िक तरीके से डिज़ाइन किया गया है. इससे ऐसी स्थितियां नहीं बनतीं जिनमें, उदाहरण के लिए, वाहन के गेटवे जैसी कोई सेवा, किसी ऐसे इंफ़ोटेन्मेंट वीएम पर भरोसा करती है जिसे हैक कर लिया गया है. ऐसा सिर्फ़ इसलिए होता है, क्योंकि उसके पास सही आईपी पता होता है.

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

वीएम-टू-वीएम कम्यूनिकेशन को सुरक्षित करने के लिए, DICE पर आधारित TLS

होस्ट आइडेंटिटी को असलियत में दिखाना

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

DICE और TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) को इंटिग्रेट करके, ज़ीरो-ट्रस्ट आर्किटेक्चर की बुनियादी चुनौती को हल किया जाता है. यह चुनौती, किसी मशीन की पुष्टि करने के साथ-साथ, उसके सॉफ़्टवेयर की इंटेग्रिटी की पुष्टि करने से जुड़ी है.

DICE के हार्डवेयर-बैकड आइडेंटिफ़िकेशन और TLS के एन्क्रिप्ट (सुरक्षित) किए गए हैंडशेक के कॉम्बिनेशन से, रिसीव करने वाली मशीन, कॉल करने वाले की आइडेंटिटी और उसके सॉफ़्टवेयर की सटीक स्थिति, दोनों की पुष्टि कर सकती है.

पारंपरिक सर्टिफ़िकेट से सिर्फ़ किसी सीक्रेट के पज़ेशन का सबूत मिलता है. इनसे फ़र्मवेयर में छेड़छाड़ का पता नहीं लगाया जा सकता. DICE, मेज़र्ड बूट लेयरिंग के ज़रिए इस समस्या को हल करता है:

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

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

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

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

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

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

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

नतीजा

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

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