सुरक्षा

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

• Android यह पक्का करता है कि सिर्फ़ उन ऐप्लिकेशन को pVM बनाने या उनकी जांच करने की अनुमति है जिनके पास pVM की अनुमतियां हैं.

• बूटलोडर – बूटलोडर यह पक्का करता है कि सिर्फ़ Google या डिवाइस वेंडर की ओर से हस्ताक्षर की गई pVM इमेज को ही बूट करने की अनुमति है. साथ ही, यह Android Verified Boot प्रोसेस का पालन करता है. इस आर्किटेक्चर का मतलब है कि pVM चलाने वाले ऐप्लिकेशन, अपने खुद के कोर को बंडल नहीं कर सकते.

• pVM, SELinux जैसे बेहतर सुरक्षा उपाय उपलब्ध कराता है. ये उपाय, pVM में चलने वाले पेलोड के लिए होते हैं. बेहतर सुरक्षा की सुविधा, डेटा को मैप करने की अनुमति नहीं देती, क्योंकि यह एक्ज़ीक्यूटेबल (neverallow execmem) है. साथ ही, यह पक्का करती है कि सभी फ़ाइल टाइप के लिए W^X लागू हो.

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

सुरक्षा मॉडल

गोपनीयता, अखंडता, और उपलब्धता (सीआईए ट्रायड), एक ऐसा मॉडल है जिसे जानकारी की सुरक्षा से जुड़ी नीतियों को तैयार करने के लिए डिज़ाइन किया गया है:

• गोपनीयता, नियमों का एक सेट है. इससे जानकारी के ऐक्सेस पर पाबंदी लगती है.
• इंटिग्रिटी का मतलब है कि जानकारी भरोसेमंद और सटीक हो.
• उपलब्धता से यह पक्का होता है कि अनुमति वाली इकाइयां, जानकारी को भरोसेमंद तरीके से ऐक्सेस कर सकती हैं.

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

अहम जानकारी: pKVM को, होस्ट Android ऑपरेटिंग सिस्टम को टारगेट करने वाले हमलों से अतिरिक्त सुरक्षा देने के लिए डिज़ाइन किया गया है. हालांकि, डिवाइस की सप्लाई चेन का ऐक्सेस रखने वाले एजेंट, जैसे कि OEM और SoC वेंडर पर अब भी भरोसा किया जाता है. Android, ऐसी बेहतर टेक्नोलॉजी पर काम कर रहा है जो हाइपरवाइजर और हार्डवेयर आर्किटेक्चर प्रॉपर्टी के अलग-अलग होने की पुष्टि करती हैं

गोपनीयता और पूरी सुरक्षा

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

गोपनीयता बनाए रखने से जुड़ी पाबंदियां, सिस्टम में मौजूद उन सभी इकाइयों पर भी लागू होती हैं जो pVM की ओर से मेमोरी ऐक्सेस करती हैं. जैसे, डीएमए की सुविधा वाले डिवाइस और ज़्यादा खास लेयर में चलने वाली सेवाएं. सिस्टम-ऑन-चिप (SoC) वेंडर को pKVM की सुविधा देने से पहले, नई शर्तों को पूरा करना होगा. अगर ऐसा नहीं किया जाता है, तो गोपनीयता की गारंटी नहीं दी जा सकती.

इंटिग्रिटी, मेमोरी में मौजूद डेटा और कैलकुलेशन पर लागू होती है. pVMs ये काम नहीं कर सकते:

• सहमति के बिना, एक-दूसरे की याददाश्त में बदलाव करना.
• एक-दूसरे के सीपीयू स्टेटस पर असर डालते हैं.

ये ज़रूरी शर्तें, हाइपरवाइजर लागू करता है. हालांकि, वर्चुअल डेटा स्टोरेज में भी डेटा इंटिग्रिटी से जुड़ी समस्याएं आती हैं. ऐसा तब होता है, जब dm-verity या AuthFS जैसे अन्य समाधान लागू करने पड़ते हैं.

ये सिद्धांत, Linux के प्रोसेस अलगाव से अलग नहीं हैं. यहां मेमोरी पेजों का ऐक्सेस, पहले चरण की पेज टेबल और प्रोसेस के बीच कर्नेल कॉन्टेक्स्ट-स्विच से कंट्रोल किया जाता है. हालांकि, pKVM के EL2 हिस्से में इन प्रॉपर्टी को लागू किया जाता है. इसमें, पूरे Linux kernel की तुलना में, अटैक के लिए ज़्यादा जगह नहीं होती. उदाहरण के लिए, कोड की 20 लाख लाइनों के मुकाबले, इसमें करीब 10 हज़ार लाइनें होती हैं. इसलिए, यह उन इस्तेमाल के उदाहरणों के लिए ज़्यादा भरोसेमंद है जो प्रोसेस अलगाव पर भरोसा करने के लिए बहुत संवेदनशील हैं.

pKVM के साइज़ को देखते हुए, इसकी पुष्टि की जा सकती है. हम रिसर्च के लिए, ज़रूरी संसाधन उपलब्ध करा रहे हैं. इसका मकसद, असल pKVM बाइनरी पर इन प्रॉपर्टी को आधिकारिक तौर पर साबित करना है.

इस पेज के बाकी हिस्से में, गोपनीयता और सुरक्षा की उन गारंटी के बारे में बताया गया है जो pKVM के हर कॉम्पोनेंट से मिलती हैं.

हाइपरवाइजर

pKVM, KVM पर आधारित हाइपरवाइजर है. यह pVM और Android को एक-दूसरे से अलग, एक-दूसरे पर भरोसा न करने वाले एक्ज़ीक्यूशन एनवायरमेंट में अलग-अलग रखता है. ये प्रॉपर्टी, होस्ट के साथ-साथ किसी भी पीवीएम में समझौता होने की स्थिति में काम करती हैं. AVF का पालन करने वाले अन्य हाइपरवाइजर को मिलती-जुलती प्रॉपर्टी देनी होंगी.

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

• pVM का इस्तेमाल किए गए पेज को होस्ट को वापस करने से पहले, उसे मिटा दिया जाता है. जैसे, pVM को बंद करने पर.

• डिवाइस के बूट होने के बाद, ओएस बूटलोडर के चलने से पहले, सभी pVM की मेमोरी और pVM फ़र्मवेयर मिटा दिया जाता है.

• SJTAG जैसे हार्डवेयर डीबगर को अटैच करने पर, pVM अपनी पहले से बनाई गई कुंजियों को ऐक्सेस नहीं कर सकता.

• अगर pVM फ़र्मवेयर, शुरुआती इमेज की पुष्टि नहीं कर पाता है, तो वह बूट नहीं होता.

• अगर instance.img के साथ छेड़छाड़ की जाती है, तो pVM फ़र्मवेयर बूट नहीं होता.

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

मेहमान के लिए ओएस

Microdroid, pVM में चलने वाले ओएस का एक उदाहरण है. Microdroid में U-boot पर आधारित बूटलोडर, GKI, Android यूज़रस्पेस का सबसेट, और पेलोड लॉन्चर शामिल होता है. ये प्रॉपर्टी, होस्ट के साथ-साथ किसी भी पीवीएम में समझौता होने की स्थिति में काम करती हैं. pVM में चल रहे अन्य ओएस, मिलती-जुलती प्रॉपर्टी उपलब्ध कराते हैं.

• अगर boot.img, super.img, vbmeta.img या vbmeta\_system.img की पुष्टि नहीं की जा सकती, तो Microdroid बूट नहीं होगा.

• अगर APK की पुष्टि नहीं हो पाती है, तो Microdroid बूट नहीं होगा.

• APK अपडेट होने के बावजूद, वही Microdroid इंस्टेंस बूट नहीं होगा.

• अगर किसी भी APEX की पुष्टि नहीं हो पाती है, तो Microdroid बूट नहीं होगा.

• अगर instance.img में मेहमान pVM के बाहर बदलाव किया जाता है, तो Microdroid बूट नहीं होगा या शुरुआती स्थिति में बूट होगा.

• Microdroid, बूट चेन की पुष्टि करता है.

• मेहमान पीवीएम के साथ शेयर की गई डिस्क इमेज में कोई भी बदलाव (बिना हस्ताक्षर वाला) करने पर, पीवीएम साइड पर I/O गड़बड़ी होती है.

• किसी pVM इंस्टेंस को दी गई डीआईसीई सर्टिफ़िकेट चेन और सीडीआई का इस्तेमाल, सिर्फ़ उसी इंस्टेंस में किया जा सकता है.

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

Android

ये प्रॉपर्टी, होस्ट के तौर पर Android के पास होती हैं. हालांकि, होस्ट के पास ऐक्सेस होने पर ये काम नहीं करतीं:

• कोई मेहमान पीवीएम, सीधे तौर पर दूसरे मेहमान पीवीएम के साथ इंटरैक्ट नहीं कर सकता. जैसे, vsock कनेक्शन बनाना.

• होस्ट pVM में मौजूद VirtualizationService ही किसी pVM के लिए कम्यूनिकेशन चैनल बना सकता है.

  ध्यान दें: यह चैनल, किसी दूसरे व्यक्ति को ट्रांसफ़र किया जा सकता है.

• सिर्फ़ वे ऐप्लिकेशन, pVM बनाने, उनका मालिकाना हक रखने या उनसे इंटरैक्ट करने की अनुमति का अनुरोध कर सकते हैं जिनमें प्लैटफ़ॉर्म कुंजी से हस्ताक्षर किए गए हों.

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

उपलब्धता

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

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

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

आखिर में, होस्ट की वर्चुअल मशीन मॉनिटर (VMM) प्रोसेस, मेमोरी को असाइन करने और नेटवर्क कार्ड जैसे वर्चुअल डिवाइसों को उपलब्ध कराने के लिए ज़िम्मेदार होती है. नुकसान पहुंचाने वाला VMM, मेहमान से संसाधन छिपा सकता है.

हालांकि, pKVM में मेहमानों को होस्ट के कंप्यूटर का ऐक्सेस नहीं दिया जाता, लेकिन इस डिज़ाइन की मदद से होस्ट को नुकसान पहुंचाने वाले मेहमानों से बचाया जा सकता है. ऐसा इसलिए, क्योंकि होस्ट कभी भी किसी मेहमान को ऐक्सेस देने से पहले रोक सकता है या ऐक्सेस खत्म कर सकता है. साथ ही, वह अपने संसाधनों को वापस पा सकता है.

सिक्योर बूट

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

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

हर चरण, अगले चरण को डिटरमिनिस्टिक तरीके से कोड किए गए CBOR ऑब्जेक्ट को सौंपता है. इस ऑब्जेक्ट में, गोपनीय जानकारी और DICE सर्टिफ़िकेट चेन होती है. इसमें, इकट्ठा की गई स्थिति की जानकारी होती है. जैसे, आखिरी चरण सुरक्षित तरीके से लोड हुआ या नहीं.

अनलॉक किए गए डिवाइस

जब किसी डिवाइस को fastboot oem unlock से अनलॉक किया जाता है, तो उपयोगकर्ता का डेटा मिटा दिया जाता है. इस प्रोसेस से, उपयोगकर्ता के डेटा को बिना अनुमति के ऐक्सेस होने से बचाया जाता है. डिवाइस अनलॉक होने पर, pVM के लिए निजी डेटा भी अमान्य हो जाता है.

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

रिमोट पार्टियां, कुंजी की पुष्टि करने वाले सर्टिफ़िकेट में डिवाइस की पुष्टि की गई बूट स्टेटस की जांच करके, इस संभावित रूप से असुरक्षित स्थिति को देख सकती हैं.