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) के साथ जोड़ते हैं, ताकि "डिफ़ॉल्ट रूप से अनुमति न दें" सिद्धांत को लागू किया जा सके. इस तरीके से, हर सेवा को सिर्फ़ उतनी ही अनुमति मिलती है जितनी ज़रूरी है. इसका मतलब है कि कॉन्फ़िगरेशन मौजूद न होने पर, सिस्टम को ज़्यादा अनुमति देने के बजाय ऐक्सेस ब्लॉक कर दिया जाता है. हम इसी रणनीति को, कम्यूनिकेशन की अनुमति देने वाले सिस्टम पर भी लागू करते हैं. इसके बारे में इस लेख में बाद में बताया गया है.

जोखिम की आशंका का मैनेजमेंट

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. क्रिप्टोग्राफ़िक इंटिग्रिटी

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

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

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

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

मेज़बान की पहचान को असलियत से जोड़ना

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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