क्यों UEFI सिक्योर बूट लिनक्स के लिए एक कठिनाई है

यूईएफआई प्रतिबंधों के बारे में हबेरा पर हाल ही में प्रकाशित एक विस्तृत चर्चा हुई, विषय की निरंतरता में, मैं मैथ्यू गैरेट के ब्लॉग से वर्तमान पोस्ट का अनुवाद साझा करना चाहता हूं, जो रेडहैट के डेवलपर्स में से एक है।

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

सुरक्षित बूट के लिए आवश्यक है कि हार्डवेयर के साथ इंटरैक्ट करने वाले सभी कोड पर भरोसा किया जाए।

वर्तमान में, यदि आप OS को लोड करने से पहले अविश्वसनीय कोड निष्पादित कर सकते हैं, तो आप ओएस के साथ जो चाहें कर सकते हैं। सुरक्षित बूट एक ऐसा तंत्र प्रदान करता है जो यह सुनिश्चित करता है कि आप केवल विश्वसनीय कोड चलाते हैं, जो ऐसे परिदृश्यों से बचाने के लिए बनाया गया है। तो, आपके UEFI ड्राइवर डिजिटल रूप से हस्ताक्षरित हैं, बूटलोडर भी डिजिटल हस्ताक्षरित है और केवल एक हस्ताक्षरित कर्नेल लोड कर सकता है। यदि आपने डाउनलोड करने के लिए केवल विश्वसनीय कोड का उपयोग किया है, तो आप सुनिश्चित कर सकते हैं कि आपका ओएस सुरक्षित है। लेकिन, विश्वसनीय कोड डाउनलोड करने के विपरीत, सिक्योर बूट आपको यह सुनिश्चित करने की अनुमति नहीं देता है कि केवल विश्वसनीय कोड निष्पादित किया गया है। यह ओएस नीतियों द्वारा प्रदान किया जाना चाहिए।

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

एक हस्ताक्षरित कर्नेल पर्याप्त नहीं है। एक हस्ताक्षरित लिनक्स कर्नेल को किसी भी अहस्ताक्षरित कर्नेल मॉड्यूल के लोड को रोकना चाहिए। लिनक्स पर वर्चुअलबॉक्स? नमस्कार। एनवीडिया बाइनरी ड्राइवर? नमस्कार। जो कुछ भी मानक कर्नेल मॉड्यूल से परे जाता है? अगली बार तक भी। नए ड्राइवरों का स्व-संयोजन? एक और समय। यह सब स्पष्ट रूप से लोगों को खुश नहीं करेगा।

(वही, विंडोज पर लागू होता है। विंडोज 7 आपको ड्राइवरों के डिजिटल हस्ताक्षर सत्यापन को प्रतिबंधित करने की अनुमति देता है, लेकिन अगर सिस्टम सुरक्षित बूट तंत्र का उपयोग करता है तो विंडोज 8 इसे अनुमति नहीं देगा)।

लाइसेंस

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

कुंजी वितरण

यूईएफआई विनिर्देश परिभाषित नहीं करता है कि केंद्रीय प्रमाणन प्राधिकरण कौन होगा। Microsoft जोर देकर कहता है कि हर किसी की अपनी कुंजी है। बेशक, हम अपनी खुद की कुंजी उत्पन्न कर सकते हैं, लेकिन यह उपकरण निर्माताओं के साथ इतना सरल नहीं है। यह सुनिश्चित करने का कोई तरीका नहीं है कि सभी लौह उत्पादक उनका समर्थन करें। और, जाहिर है, अगर हम एक कुंजी उत्पन्न करते हैं, तो हम केवल इसके निजी हिस्से को तीसरे पक्ष को स्थानांतरित करने में सक्षम नहीं होंगे। इसका मतलब है कि लोगों के लिए अपनी निजी कुंजी प्राप्त किए बिना दूसरों के आधार पर अपने स्वयं के वितरण जारी करना असंभव हो जाएगा। कुंजी प्राप्त करने के लिए कुछ प्रकार की पहचान सत्यापन प्रक्रिया की आवश्यकता होगी, जो महंगा होने की संभावना है, और यह भी संभावना है कि पहचान सत्यापन सुनिश्चित करने के लिए कानूनी रूप से पंजीकृत संगठन की आवश्यकता हो सकती है। मुझे लगता है कि यह विस्तारित सत्यापन प्रमाणपत्र होगा, न कि स्टार्टअपलेस फ्री। इस प्रकार, उत्साही लोगों द्वारा निर्मित लिनक्स वितरण अतीत की बात होगी।

क्या कस्टम मोड इस समस्या को हल नहीं करता है?

Microsoft प्रमाणन आवश्यकताओं से संकेत मिलता है कि सभी प्रणालियों को कस्टम मोड का समर्थन करना चाहिए, इस फ़ंक्शन के कार्यान्वयन से उपयोगकर्ताओं को अपनी चाबियाँ सेट करने की क्षमता प्रदान करनी चाहिए। लिनक्स निर्माता वितरण के साथ अपनी स्वयं की चाबियाँ प्रदान करने और अपनी स्वयं की नीतियां निर्धारित करने में सक्षम होंगे। हर कोई खुश है। वास्तव में, सब कुछ इतना अच्छा नहीं है। ड्राइव में सीडी डालने के बजाय, लोगों को लिनक्स स्थापित करने के लिए एक अविश्वसनीय समय और प्रयास खर्च करना होगा। फ़र्मवेयर को बदलने और इसके पुन: संयोजन की आवश्यकता एक अतिरिक्त अवरोध को जोड़ती है और केवल अधिक तकनीकी रूप से सक्षम उपयोगकर्ताओं के लिए लिनक्स स्थापित करने की क्षमता को सीमित करती है। और यह और भी बुरा है। यहाँ कस्टम मोड के लिए आवश्यकताओं का पूरा विवरण दिया गया है:
1. डिवाइस के पीछे भौतिक रूप से स्थित उपयोगकर्ता के लिए, सुरक्षित बूट और पीके हस्ताक्षर (अनुवादक के नोट: पीके - निजी कुंजी) के डेटाबेस की सामग्री को संशोधित करने के लिए कस्टम मोड का उपयोग करना संभव होना चाहिए।
2. यदि उपयोगकर्ता पीके को हटाता है, तो कस्टम मोड से बाहर निकलने पर, सिस्टम डिफ़ॉल्ट रूप से सुरक्षित बूट अक्षम के साथ सेटअप मोड में कार्य करेगा।
3. फर्मवेयर सेटिंग्स मेनू आपको सूचित करना चाहिए कि सुरक्षित बूट सक्षम है, साथ ही साथ मानक या कस्टम मोड के ऑपरेटिंग मोड भी। फ़ैक्टरी मेनू को फ़ैक्टरी डिफ़ॉल्ट सेटिंग्स की बहाली के साथ कस्टम से मानक मोड में लौटने का अवसर भी प्रदान करना चाहिए।

यहाँ कुछ याद आ रहा है, उदाहरण के लिए:
- UI का कोई भी विवरण। यह पहला कदम (क) भ्रमित और (बी) विक्रेता-विशिष्ट होने पर लिनक्स इंस्टॉलेशन प्रक्रिया को दस्तावेज करना लगभग असंभव बना देता है। आयरन निर्माता अपने स्वयं के अनूठे फर्मवेयर इंटरफेस की पेशकश करके खुद को अलग करने की कोशिश कर रहे हैं। उनमें कस्टम मोड पूरी तरह से अलग दिख सकता है।
- कुंजी प्रारूप का कोई भी विवरण। सरल बाइनरी कुंजी प्रतिनिधित्व? या एक EFI_SIGNATURE_DATA संरचना? Base64 एन्कोडेड कुंजी, ROT13 द्वारा संरक्षित है? हम नहीं जानते।
- ओएस स्थापना के अप्राप्य संस्करण के साथ कस्टम मोड का उपयोग करने का कोई भी तरीका। फर्मवेयर इंटरफ़ेस को उपयोगकर्ता की भौतिक उपस्थिति की आवश्यकता होती है। क्या आप नेटवर्क पर कई हज़ार मशीनों पर OS स्थापित करना चाहेंगे? यह एक स्केलेबल दृष्टिकोण नहीं है।
- ... और एक तिपहिया, वास्तव में, उपयोगकर्ता के लिए खुद की कुंजी जोड़ने के लिए कहीं भी कोई आवश्यकता नहीं है, लोहे के निर्माता इसका लाभ उठा सकते हैं, जिससे केवल चाबियाँ हटाने की अनुमति मिलती है। यह तब तक खराब नहीं है जब तक उपयोगकर्ता पीके को हटा सकते हैं, क्योंकि तब वे सेटअप मोड पर लौट आएंगे और इंस्टॉलर से हमारी चाबियाँ स्थापित करने में सक्षम होंगे, लेकिन व्यवहार में यह अभी भी समस्या पैदा करेगा।

सभी समान, कस्टम मोड सभी समस्याओं का समाधान नहीं करता है। कड़ाई से परिभाषित यूआई और कुंजी प्रारूप के साथ कस्टम मोड बहुत बेहतर होगा, लेकिन फिर भी ओएस स्थापना के स्वचालित अप्राप्य संस्करण के साथ समस्या को हल नहीं करेगा।

निष्कर्ष

हम कम समय में लिनक्स पर सुरक्षित बूट का समर्थन करने के लिए आवश्यक कोड लिख सकते हैं - वास्तव में, इसका अधिकांश हिस्सा पहले ही पूरा हो चुका है। लेकिन महत्वपूर्ण व्यावहारिक समस्याएं बनी हुई हैं, और आज तक हमारे पास उनमें से किसी के लिए भी काम करने का हल नहीं है।