Android में सेलुलर बेसबैंड्स को हार्डन करना
Android के सेलुलर “बेसबैंड” प्रोसेसर एक प्रमुख सुरक्षा कमजोर कड़ी के रूप में उभर रहे हैं, क्योंकि वे अपारदर्शी, proprietary फ़र्मवेयर चलाते हैं और हार्डवेयर तथा कभी-कभी सिस्टम मेमोरी तक गहरी पहुँच रखते हैं। टिप्पणीकारों का तर्क है कि Google की प्रस्तावित hardening तकनीकें (sanitizers, safer toolchains) तब तक अधिकतम क्रमिक सुधार ही हैं, जब तक बेसबैंड बंद न रहें, IOMMU के माध्यम से ठीक से isolate न किए जाएँ, और पेटेंट तथा नियामकीय गतिशीलताओं से सीमित कुछ vendors के oligopoly द्वारा नियंत्रित न हों। कई लोग अधिक मौलिक बदलावों—FOSS baseband stacks, VoLTE/IMS जैसे जटिल प्रोटोकॉल को auditable userspace code में स्थानांतरित करना, और कड़े hardware isolation—को remote compromise जोखिम को सार्थक रूप से सीमित करने का एकमात्र तरीका मानते हैं.
बेसबैंड आर्किटेक्चर और जोखिम प्रोफ़ाइल
- बेसबैंड अलग प्रोसेसर होते हैं जिनका अपना फ़र्मवेयर और OS होता है; ये अक्सर मुख्य CPU जितने शक्तिशाली होते हैं और Google तथा उपयोगकर्ताओं के लिए काफी हद तक अपारदर्शी रहते हैं।
- यदि बेसबैंड फ़र्मवेयर को बिना प्रतिबंध मेमोरी एक्सेस मिल जाए, तो उसका समझौता पूरे डिवाइस के समझौते को सक्षम कर सकता है; कुछ रिपोर्टों में राज्य-समर्थित पक्षों द्वारा वास्तविक-विश्व में जासूसी के लिए इसके उपयोग का उल्लेख है।
- अन्य लोग बताते हैं कि प्रभाव इंटरकनेक्ट और आइसोलेशन पर निर्भर करता है: कुछ प्लेटफ़ॉर्म MMU/IOMMU का उपयोग करते हैं, इसलिए बेसबैंड कोड निष्पादन मुख्यतः रेडियो ट्रैफ़िक और लोकेशन को उजागर करता है, पूरे सिस्टम को नहीं।
आइसोलेशन, IOMMU, और DMA
- कई टिप्पणीकार तर्क देते हैं कि उचित IOMMU उपयोग और बेसबैंड को अविश्वसनीय मानना, बढ़ते हुए कंपाइलर हार्डनिंग से अधिक महत्वपूर्ण है।
- कुछ फ़ोनों में कथित तौर पर बेसबैंड सीधे सिस्टम RAM या PCI से IOMMU के बिना जुड़े होते हैं, जिससे शोषण “गेम ओवर” बन जाता है।
- आधुनिक Pixels और iPhones को उदाहरण के रूप में उद्धृत किया जाता है जहाँ DMA को सीमित करने के लिए IOMMU/MMU का उपयोग किया जाता है, हालांकि विवरण और पूर्णता पर बहस होती है।
- बेसबैंड ड्राइवरों को VMs या अलग-थलग kernels में चलाने की वकालत भी की जाती है; अन्य लोग नोट करते हैं कि यह पहले से आंशिक रूप से हो रहा है या हार्डवेयर/रीयल-टाइम बाधाएँ इसे जटिल बनाती हैं।
प्रोप्राइटरी इकोसिस्टम, पेटेंट, और “सिक्योरिटी थिएटर”
- बंद, उपयोगकर्ता-नियंत्रित न किए जा सकने वाले बेसबैंड फ़र्मवेयर को मूल समस्या माना जाता है; वेंडर के “remote access” बैकडोर्स का भी उल्लेख किया गया है।
- Qualcomm/Mediatek/Samsung के ओलिगोपॉली और पेटेंट/पूल राजनीति को प्रतिस्पर्धा की कमी और धीमे सुरक्षा सुधारों के लिए दोषी ठहराया जाता है।
- कुछ लोग सरकारी दबाव में जानबूझकर कमज़ोरी की आशंका जताते हैं; अन्य इसे अक्षमता और असंगत प्रोत्साहनों का परिणाम मानते हैं। उपलब्ध साक्ष्य को बड़े पैमाने पर परिस्थितिजन्य माना जाता है।
- कई लोगों के लिए Google की हार्डनिंग सलाह उपयोगी है, लेकिन अंततः FOSS बेसबैंड और सच्चे आइसोलेशन के बिना यह सीमित “security theater” ही है।
फ़ंक्शनैलिटी को बेसबैंड से बाहर ले जाना
- एक थ्रेड का तर्क है कि असली समाधान यह है कि जटिल स्टैक्स (IMS/VoLTE/VoWiFi, SIP, TCP/IP, DNS, XML parsing) को बेसबैंड के अंदर रखना बंद किया जाए।
- प्रस्तावित मॉडल: IMS/VoLTE/VoWiFi को ओपन-सोर्स, userspace ऐप्स के रूप में लागू करना (उदाहरण: Kotlin IMS प्रोजेक्ट) और एक “dumb” modem के साथ न्यूनतम सहयोग रखना।
- इसे सुरक्षा, डिबगयोग्यता और फीचर चपलता में सुधार के रूप में देखा जाता है, हालांकि कुछ लोग रीयल-टाइम और QoS बाधाओं तथा उन हिस्सों की ओर इशारा करते हैं जिन्हें modem पर ही रहना होगा।
डिवाइसेज़, प्रोजेक्ट्स, और प्रयोग
- PinePhone/PinePhone Pro, non-Qualcomm SoCs, और कुछ Pixels को प्रयोग या आइसोलेशन के लिए अपेक्षाकृत बेहतर माना जाता है; अन्य लोग उनके IOMMU सपोर्ट पर सवाल उठाते हैं।
- Open baseband प्रयासों (जैसे Osmocom, PinePhone modem images) का उल्लेख किया गया है, लेकिन टिप्पणीकार कहते हैं कि आधुनिक 3G+/5G modems अभी भी अधिकांशतः sealed black boxes हैं।