सुरक्षा

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

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

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

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

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

सुरक्षा मॉडल

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

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

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

अहम जानकारी: pKVM, सिक्योर वर्ल्ड (EL3 और S-ELx) जैसे कुछ खास अपवाद लेवल पर होने वाले हमलों से असरदार सुरक्षा नहीं देता. pKVM, नुकसान पहुंचाने वाले OEM और SoC वेंडर पर होने वाले हमलों से सुरक्षित नहीं रखता. Android टीम, वेंडर के साथ मिलकर काम कर रही है, ताकि सबसे सही तरीके अपनाए जा सकें और इस तरह के हमलों की संभावना कम की जा सके.

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

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

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

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

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

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

ये ज़रूरी शर्तें, हाइपरवाइजर लागू करता है. हालांकि, वर्चुअल डेटा स्टोरेज में भी डेटा इंटिग्रिटी से जुड़ी समस्याएं आती हैं. ऐसा तब होता है, जब 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 अपनी पहले से बनाई गई कुंजियों को ऐक्सेस नहीं कर सकता.

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

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

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

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

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

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

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

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

• अगर किसी भी 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 ABL, Microdroid वगैरह.

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

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

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

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

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

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