सुरक्षा लागू करना

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

Android की सुरक्षा टीम को, Android डिवाइसों पर सुरक्षा से जुड़ी संभावित समस्याओं को रोकने के बारे में जानकारी पाने के लिए, नियमित तौर पर अनुरोध मिलते रहते हैं. हम कभी-कभी डिवाइसों की जांच भी करते हैं. साथ ही, डिवाइस बनाने वाली कंपनियों और जिन पार्टनर पर असर पड़ा है उन्हें संभावित समस्याओं के बारे में बताते हैं.

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

इन सबसे सही तरीकों को अपनाने में आसानी हो, इसके लिए Android की सुरक्षा टीम जहां भी हो सके, Android के साथ काम करने से जुड़े टेस्ट सुइट (CTS) और Android Lint में टेस्ट शामिल करती है. हम डिवाइस इंप्लीमेंटर को ऐसे टेस्ट बनाने के लिए बढ़ावा देते हैं जिनसे Android के अन्य उपयोगकर्ताओं को मदद मिल सके. सुरक्षा से जुड़े टेस्ट देखने के लिए, root/cts/tests/tests/security/src/android/security/cts पर जाएं.

डेवलपमेंट प्रोसेस

डेवलपमेंट प्रोसेस और एनवायरमेंट में, यहां दिए गए सबसे सही तरीकों का इस्तेमाल करें.

सोर्स कोड की समीक्षा करना

सोर्स कोड की समीक्षा से, सुरक्षा से जुड़ी कई तरह की समस्याओं का पता चल सकता है. इनमें, इस दस्तावेज़ में बताई गई समस्याएं भी शामिल हैं. Android, सोर्स कोड की मैन्युअल और ऑटोमेटेड, दोनों तरह की समीक्षा का सुझाव देता है. सबसे सही तरीके:

• Android SDK टूल का इस्तेमाल करके, ऐप्लिकेशन के सभी कोड पर Android Lint चलाएं और बताई गई समस्याओं को ठीक करें.
• नेटिव कोड का विश्लेषण, अपने-आप काम करने वाले ऐसे टूल का इस्तेमाल करके किया जाना चाहिए जो मेमोरी मैनेजमेंट से जुड़ी समस्याओं का पता लगा सकता है. जैसे, बफ़र ओवरफ़्लो और एक से ज़्यादा गड़बड़ियां.
• Android बिल्ड सिस्टम में कई LLVM सैनिटाइज़र काम करते हैं. जैसे, AddressSanitizer और UndefinedBehaviorSanitizer. इनका इस्तेमाल इस काम के लिए किया जा सकता है.

ऑटोमेटेड टेस्टिंग का इस्तेमाल करना

ऑटोमेटेड टेस्टिंग से, सुरक्षा से जुड़ी कई तरह की समस्याओं का पता लगाया जा सकता है. इनमें, यहां बताई गई कई समस्याएं भी शामिल हैं. सबसे सही तरीके:

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

साइन सिस्टम की इमेज

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

• डिवाइसों को ऐसी कुंजी से साइन नहीं किया जाना चाहिए जो सार्वजनिक तौर पर उपलब्ध हो.
• डिवाइसों पर साइन इन करने के लिए इस्तेमाल की जाने वाली कुंजियों को, संवेदनशील कुंजियों को मैनेज करने के लिए इंडस्ट्री के स्टैंडर्ड तरीकों के मुताबिक मैनेज किया जाना चाहिए. इनमें, हार्डवेयर सुरक्षा मॉड्यूल (एचएसएम) भी शामिल है, जो सीमित और ऑडिट किया जा सकने वाला ऐक्सेस देता है.

ऐप्लिकेशन (APKs) पर हस्ताक्षर करना

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

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

ऐप्लिकेशन पब्लिश करना

Google Play, डिवाइस बनाने वाली कंपनियों को यह सुविधा देता है कि वे पूरे सिस्टम को अपडेट किए बिना, ऐप्लिकेशन अपडेट कर सकें. इससे सुरक्षा से जुड़ी समस्याओं को हल करने और नई सुविधाओं को डिलीवर करने में कम समय लगेगा. साथ ही, यह पक्का करने का एक तरीका भी मिलेगा कि आपके ऐप्लिकेशन का पैकेज का नाम यूनीक हो. सबसे सही तरीके:

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

समस्याओं का जवाब देना

बाहरी पक्षों के पास, डिवाइस से जुड़ी सुरक्षा से जुड़ी समस्याओं के बारे में डिवाइस बनाने वाली कंपनियों से संपर्क करने की सुविधा होनी चाहिए. हमारा सुझाव है कि सुरक्षा से जुड़ी समस्याओं को मैनेज करने के लिए, ऐसा ईमेल पता बनाएं जिसे सभी ऐक्सेस कर सकें. सबसे सही तरीके:

• security@your-company.com या मिलता-जुलता कोई ईमेल पता बनाएं और उसका प्रमोशन करें.
• अगर आपको सुरक्षा से जुड़ी कोई ऐसी समस्या पता चलती है जिसका असर Android OS या कई डिवाइस मैन्युफ़ैक्चरर के Android डिवाइसों पर पड़ता है, तो आपको सुरक्षा से जुड़ी गड़बड़ी की शिकायत दर्ज करके, Android की सुरक्षा टीम से संपर्क करना चाहिए.

प्रॉडक्ट लागू करना

किसी प्रॉडक्ट को लागू करते समय, यहां बताए गए सबसे सही तरीकों का इस्तेमाल करें.

रूट प्रोसेस को अलग करना

रूट प्रोसेस, ऐक्सेस लेवल बढ़ाने वाले हमलों का सबसे ज़्यादा टारगेट होती हैं. इसलिए, रूट प्रोसेस की संख्या कम करने से, ऐक्सेस लेवल बढ़ाने वाले हमलों का जोखिम कम हो जाता है. सीटीएस में जानकारी देने वाला एक टेस्ट शामिल होता है, जिसमें रूट प्रोसेस की सूची होती है. सबसे सही तरीके:

• डिवाइसों को कम से कम ज़रूरी कोड को रूट के तौर पर चलाना चाहिए. जहां भी हो सके, रूट प्रोसेस के बजाय सामान्य Android प्रोसेस का इस्तेमाल करें. ICS वाले Galaxy Nexus में सिर्फ़ छह रूट प्रोसेस होती हैं: vold, inetd, zygote, tf_daemon, ueventd, और init. अगर किसी प्रोसेस को डिवाइस पर रूट के तौर पर चलाना ज़रूरी है, तो प्रोसेस की जानकारी को AOSP की सुविधा के अनुरोध में दस्तावेज़ के तौर पर शामिल करें, ताकि उसकी सार्वजनिक तौर पर समीक्षा की जा सके.
• जहां भी हो सके, रूट कोड को अविश्वसनीय डेटा से अलग रखा जाना चाहिए और IPC के ज़रिए ऐक्सेस किया जाना चाहिए. उदाहरण के लिए, रूट फ़ंक्शन को छोटी सेवा में बदलें, जिसे Binder के ज़रिए ऐक्सेस किया जा सके. साथ ही, सेवा को हस्ताक्षर की अनुमति के साथ ऐसे ऐप्लिकेशन के लिए उपलब्ध कराएं जिसके पास नेटवर्क ट्रैफ़िक को मैनेज करने के लिए कम या कोई विशेषाधिकार नहीं है.
• रूट प्रोसेस को नेटवर्क सॉकेट पर सुनना नहीं चाहिए.
• रूट प्रोसेस को ऐप्लिकेशन के लिए सामान्य तौर पर इस्तेमाल होने वाला रनटाइम नहीं देना चाहिए. उदाहरण के लिए, Java VM.

सिस्टम ऐप्लिकेशन को अलग करना

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

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

प्रोसेस को अलग करना

Android ऐप्लिकेशन सैंडबॉक्स की मदद से, ऐप्लिकेशन को सिस्टम पर मौजूद अन्य प्रोसेस से अलग रखा जाता है. इनमें रूट प्रोसेस और डीबगर भी शामिल हैं. जब तक ऐप्लिकेशन और उपयोगकर्ता, डीबग करने की सुविधा को खास तौर पर चालू नहीं करते, तब तक कोई भी ऐप्लिकेशन इस सुविधा का गलत इस्तेमाल नहीं कर सकता. सबसे सही तरीके:

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

एसयूआईडी फ़ाइलों को सुरक्षित करना

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

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

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

सुरक्षित सुनने के सॉकेट

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

• डिवाइस पर कोई भी सुनने वाला पोर्ट नहीं होना चाहिए.
• लिसनिंग पोर्ट को ओटीए के बिना बंद किया जा सकता हो. यह सर्वर या उपयोगकर्ता के डिवाइस के कॉन्फ़िगरेशन में बदलाव हो सकता है.
• रूट प्रोसेस को किसी भी पोर्ट पर सुनना नहीं चाहिए.
• सिस्टम यूआईडी के मालिकाना हक वाली प्रोसेस को किसी भी पोर्ट पर सुनना नहीं चाहिए.
• सॉकेट का इस्तेमाल करके लोकल आईपीसी के लिए, ऐप्लिकेशन को किसी ग्रुप के लिए सीमित ऐक्सेस वाले यूनिक्स डोमेन सॉकेट का इस्तेमाल करना होगा. IPC के लिए फ़ाइल डिस्क्रिप्टर बनाएं और किसी खास UNIX ग्रुप के लिए इसे +RW बनाएं. सभी क्लाइंट ऐप्लिकेशन, उस यूनिक्स ग्रुप में होने चाहिए.
• एक से ज़्यादा प्रोसेसर वाले कुछ डिवाइस (जैसे, ऐप्लिकेशन प्रोसेसर से अलग रेडियो/मॉडेम), प्रोसेसर के बीच कम्यूनिकेट करने के लिए नेटवर्क सॉकेट का इस्तेमाल करते हैं. ऐसे मामलों में, इंटर-प्रोसेसर कम्यूनिकेशन के लिए इस्तेमाल किए जाने वाले नेटवर्क सॉकेट को डिवाइस पर मौजूद ऐसे ऐप्लिकेशन से ऐक्सेस होने से रोकने के लिए, अलग नेटवर्क इंटरफ़ेस का इस्तेमाल करना चाहिए जिनके पास अनुमति नहीं है. इसका मतलब है कि डिवाइस पर मौजूद अन्य ऐप्लिकेशन से ऐक्सेस होने से रोकने के लिए, iptables का इस्तेमाल करें.
• सुनने वाले पोर्ट को मैनेज करने वाले डेमन, गलत डेटा के ख़िलाफ़ मज़बूत होने चाहिए. Google, बिना अनुमति वाले क्लाइंट का इस्तेमाल करके, पोर्ट के लिए फ़ज़ टेस्टिंग कर सकता है. इसके अलावा, जहां संभव हो वहां अनुमति वाले क्लाइंट का इस्तेमाल भी किया जा सकता है. किसी भी क्रैश को, ज़रूरत के हिसाब से गंभीरता के साथ बग के तौर पर दर्ज किया जाता है.

डेटा लॉग करना

डेटा को लॉग करने से, उस डेटा के एक्सपोज़र का जोखिम बढ़ जाता है और सिस्टम की परफ़ॉर्मेंस कम हो जाती है. Android डिवाइसों पर डिफ़ॉल्ट रूप से इंस्टॉल किए गए ऐप्लिकेशन, उपयोगकर्ता का संवेदनशील डेटा लॉग करते हैं. इस वजह से, सार्वजनिक सुरक्षा से जुड़ी कई घटनाएं हुई हैं. सबसे सही तरीके:

• ऐप्लिकेशन या सिस्टम की सेवाओं को, तीसरे पक्ष के ऐप्लिकेशन से मिले ऐसे डेटा को लॉग नहीं करना चाहिए जिसमें संवेदनशील जानकारी शामिल हो सकती है.
• ऐप्लिकेशन को सामान्य कामकाज के दौरान, व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) को लॉग नहीं करना चाहिए.

सीटीएस में ऐसे टेस्ट शामिल होते हैं जो सिस्टम लॉग में संभावित रूप से संवेदनशील जानकारी की मौजूदगी की जांच करते हैं.

डायरेक्ट्री का ऐक्सेस सीमित करना

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

सबसे सही तरीका यह है कि सिस्टम या रूट उपयोगकर्ताओं की बनाई गई डायरेक्ट्री में, सभी के पास लिखने की अनुमति न हो. सीटीएस टेस्ट, जानी-पहचानी डायरेक्ट्री की जांच करके, इस सबसे सही तरीके को लागू करने में मदद करते हैं.

कॉन्फ़िगरेशन फ़ाइलों को सुरक्षित करना

कई ड्राइवर और सेवाएं, /system/etc और /data जैसी डायरेक्ट्री में सेव की गई कॉन्फ़िगरेशन और डेटा फ़ाइलों पर निर्भर करती हैं. अगर इन फ़ाइलों को किसी खास प्रोसेस की मदद से प्रोसेस किया जाता है और ये वर्ल्ड-राइटेबल होती हैं, तो कोई ऐप्लिकेशन इस प्रोसेस में मौजूद किसी कमज़ोरी का फ़ायदा उठा सकता है. इसके लिए, वह वर्ल्ड-राइटेबल फ़ाइल में नुकसान पहुंचाने वाला कॉन्टेंट बनाता है. सबसे सही तरीके:

• खास सुविधाओं वाली प्रोसेस के लिए इस्तेमाल की जाने वाली कॉन्फ़िगरेशन फ़ाइलें, सभी के लिए पढ़ने लायक नहीं होनी चाहिए.
• खास सुविधाओं वाली प्रोसेस के लिए इस्तेमाल की जाने वाली कॉन्फ़िगरेशन फ़ाइलों को सभी के लिए लिखने की अनुमति नहीं दी जानी चाहिए.

नेटिव कोड लाइब्रेरी स्टोर करना

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

डिवाइस ड्राइवर का ऐक्सेस सीमित करना

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

ADB को बंद करना

Android Debug Bridge (adb) एक अहम डेवलपमेंट और डीबगिंग टूल है. हालांकि, इसे कंट्रोल किए गए और सुरक्षित एनवायरमेंट में इस्तेमाल करने के लिए डिज़ाइन किया गया है. इसे सामान्य इस्तेमाल के लिए चालू नहीं किया जाना चाहिए. सबसे सही तरीके:

• ADB डिफ़ॉल्ट रूप से बंद होना चाहिए.
• कनेक्शन स्वीकार करने से पहले, ADB को उपयोगकर्ता से इसे चालू करने के लिए कहना चाहिए.

बूटलोडर अनलॉक करना

कई Android डिवाइसों को अनलॉक किया जा सकता है. इससे डिवाइस के मालिक को सिस्टम के partition में बदलाव करने और/या कस्टम ऑपरेटिंग सिस्टम इंस्टॉल करने की सुविधा मिलती है. आम तौर पर, तीसरे पक्ष का ROM इंस्टॉल करने और डिवाइस पर सिस्टम-लेवल डेवलपमेंट करने के लिए, ADB का इस्तेमाल किया जाता है. उदाहरण के लिए, Google Nexus डिवाइस का मालिक, डिवाइस को अनलॉक करने की प्रोसेस शुरू करने के लिए fastboot oem unlock चला सकता है. इससे उपयोगकर्ता को यह मैसेज दिखता है:

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

• जब उपयोगकर्ता अनलॉक करने के कमांड की पुष्टि करता है, तो डिवाइस को तुरंत डेटा वाइप करना शुरू करना चाहिए. सुरक्षित तरीके से मिटाने की प्रोसेस पूरी होने तक, unlocked फ़्लैग को सेट नहीं किया जाना चाहिए.
• अगर डेटा को सुरक्षित तरीके से मिटाने की प्रोसेस पूरी नहीं हो पाती है, तो डिवाइस को लॉक किया जाना चाहिए.
• अगर ब्लॉक डिवाइस पर काम करता है, तो ioctl(BLKSECDISCARD) या इसके बराबर का इस्तेमाल किया जाना चाहिए. eMMC डिवाइसों के लिए, इसका मतलब है कि सुरक्षित तरीके से मिटाने या सुरक्षित तरीके से काटने के निर्देश का इस्तेमाल करना. eMMC 4.5 और उसके बाद के वर्शन के लिए, इसका मतलब है कि सामान्य तरीके से मिटाने या काटने के बाद, डिवाइस को पूरी तरह से मिटाना.
• अगर ब्लॉक करने वाले डिवाइस पर BLKSECDISCARD काम नहीं करता है, तो इसके बजाय ioctl(BLKDISCARD) का इस्तेमाल किया जाना चाहिए. eMMC डिवाइसों पर, यह ट्रिम करने की सामान्य प्रोसेस है.
• अगर BLKDISCARD काम नहीं करता है, तो ब्लॉक किए गए डिवाइसों को सभी शून्यों से बदला जा सकता है.
• उपयोगकर्ता के पास यह विकल्प होना चाहिए कि वह किसी partition को फ़्लैश करने से पहले, अपने डेटा को मिटा सके. उदाहरण के लिए, Nexus डिवाइसों पर, ऐसा करने के लिए fastboot oem lock कमांड का इस्तेमाल किया जाता है.
• डिवाइस, efuses या मिलती-जुलती सुविधा की मदद से रिकॉर्ड कर सकता है कि डिवाइस को अनलॉक और/या फिर से लॉक किया गया था या नहीं.

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

अनलॉक किए गए डिवाइस को fastboot oem lock कमांड का इस्तेमाल करके, फिर से लॉक किया जा सकता है. बूटलोडर को लॉक करने से, उपयोगकर्ता के डेटा को नए कस्टम ओएस में उतनी ही सुरक्षा मिलती है जितनी डिवाइस बनाने वाली कंपनी के ओरिजनल ओएस में मिलती है. उदाहरण के लिए, डिवाइस को फिर से अनलॉक करने पर, उपयोगकर्ता का डेटा मिट जाएगा.