AAOS SDV - Secure by Design

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

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

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

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

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

Android की सुरक्षा से जुड़ी सेटिंग इनहेरिट की गई हैं

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

अलग-अलग प्रोसेस के लिए टेक्नोलॉजी और डिफ़ॉल्ट रूप से अनुमति न देना

AAOS SDV, Android के यूज़र आईडी (यूआईडी) पर आधारित आइसोलेशन मॉडल का इस्तेमाल करता है. इससे हर ऐप्लिकेशन के लिए सैंडबॉक्स सेट अप किया जा सकता है. हर सेवा, एक खास प्रोसेस में चलती है. इसमें ऐक्सेस के अधिकारों, डेटा डायरेक्ट्री, और अन्य पाबंदियों को मैनेज करने के लिए, यूनीक यूआईडी होता है. हम पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस (POSIX) की सुविधाओं का इस्तेमाल करते हैं, ताकि कार्रवाइयों को सीमित किया जा सके. साथ ही, इसे Security-Enhanced 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 फ़ाइल को सीधे तौर पर रॉ स्टोरेज डिवाइस के तौर पर लूप करता है. इसके लिए, read-only loopback का इस्तेमाल किया जाता है. साथ ही, इसे MS_RDONLY फ़्लैग के साथ माउंट किया जाता है.
• यह ज़्यादा सुरक्षित क्यों है: इससे ओएस को कोई राइट पाथ नहीं मिलता, क्योंकि फ़ाइलों को वाहन के स्टोरेज में अनपैक नहीं किया जाता. अगर हमलावर को रूट ऐक्सेस मिल भी जाता है, तो भी वह चालू APEX कोड में बदलाव नहीं कर सकता. ऐसा इसलिए, क्योंकि फ़ाइल सिस्टम लेयर, सभी राइट कमांड को अस्वीकार कर देती है.

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

• तरीका: क्रिप्टोग्राफ़िक हस्ताक्षर, पूरे फ़ाइल सिस्टम इमेज के मर्कल ट्री की पुष्टि करता है.
• यह ज़्यादा सुरक्षित क्यों है: कर्नल, हर 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, मेज़र किए गए बूट लेयरिंग की मदद से इस समस्या को हल करता है:

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

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

लेयर के हिसाब से ऐक्सेस कंट्रोल

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

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

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

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

नतीजा

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

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