Android IKEv2: उपयोगकर्ता प्रमाणपत्र और CA अलग-अलग काम करते हैं
एक फ़ील्ड साबित करता है कि फ़ोन कौन है, दूसरा तय करता है कि किस गेटवे पर भरोसा करना है। Android का IKEv2 प्रोफ़ाइल दोनों को अलग रखता है।
Android में IKEv2 स्क्रीन जब एक साथ उपयोगकर्ता प्रमाणपत्र और CA प्रमाणपत्र मांगती है, तो लगता है कि वही चीज़ दो बार मांगी जा रही है। ऐसा नहीं है। IKEv2 एक ही आदान-प्रदान में दोनों पक्षों को दोनों दिशाओं में प्रमाणित करता है, और फ़ोन की भूमिका हर दिशा में अलग होती है: उसे साबित करना होता है कि वह कौन है और तय करना होता है कि किस गेटवे पर भरोसा करे। उपयोगकर्ता प्रमाणपत्र पहले प्रश्न का उत्तर देता है, भरोसेमंद CA दूसरे का, और कोई भी दूसरे की जगह नहीं लेता।
एक आदान-प्रदान में प्रमाणन की दो दिशाएँ
IKEv2 दो चरणों में नियंत्रण चैनल बनाता है। पहला चरण एल्गोरिद्म और कुंजियों पर बात करता है; दूसरा, IKE_AUTH, हर पक्ष से एक AUTH पेलोड उसकी पहचान के साथ लाता है। पेलोड आदान-प्रदान पर बनी हस्ताक्षर या MAC है, और इसे उस चीज़ के सामने जाँचा जाता है जिस पर प्राप्तकर्ता पहले से भरोसा करता है।
गेटवे अपने प्रमाणपत्र से खुद को साबित करता है, और फ़ोन श्रृंखला को उस मूल तक जाँचता है जिसे वह स्वीकार करता है तथा देखता है कि प्रमाणपत्र की पहचान उसी गेटवे से मेल खाती है जिस तक पहुँचना था; फ़ोन अपने क्रेडेंशियल से खुद को साबित करता है, और गेटवे उन्हें उस CA के सामने जाँचता है जिसने क्लाइंट प्रमाणपत्र जारी किया।
बस यही पूरी व्यवस्था दोनों फ़ील्डों के पीछे है। उपयोगकर्ता प्रमाणपत्र फ़ोन का अपने बारे में बयान है; CA फ़ील्ड इस बात का बयान है कि वह किस पर विश्वास करेगा। एक के बिना दूसरा होने पर प्रोफ़ाइल पारस्परिक प्रमाणन पूरा नहीं कर सकता, और दोबारा कोशिश करने से कुछ नहीं बदलता। विफलताएँ भी अलग दिखती हैं: उपयोगकर्ता कुंजी के बिना फ़ोन हस्ताक्षर ही नहीं कर सकता, और भरोसा एंकर के बिना गेटवे का प्रमाणपत्र स्वीकार नहीं कर सकता।
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Android का प्रोफ़ाइल बिल्डर क्या मांगता है
Android का IKEv2 प्रोफ़ाइल बिल्डर हर प्रमाणन विधि अलग-अलग देता है, एक ही प्रमाणपत्र मोड के रूप में नहीं। डिजिटल हस्ताक्षर विधि उपयोगकर्ता प्रमाणपत्र, निजी कुंजी और सर्वर की मूल CA लेती है; बाकी उपयोगकर्ता नाम और पासवर्ड, या पहले से साझा कुंजी लेती हैं।
उस हस्ताक्षर को ध्यान से पढ़ें, क्योंकि वही ऊपर की व्यवस्था बताता है। उपयोगकर्ता नाम और पासवर्ड विधि में निजी कुंजी के लिए कोई फ़ील्ड नहीं है, और PSK विधि में गेटवे के भरोसा एंकर के लिए कोई फ़ील्ड नहीं है, क्योंकि ये विधियाँ अलग-अलग चीज़ें साबित करती हैं। प्रमाणपत्र फ़ील्ड में पासवर्ड चिपकाने से ऐसा प्रोफ़ाइल बनता है जो IKE_AUTH पर विफल होता है और संदेश दोनों में से किसी का नाम नहीं लेता।
डिजिटल हस्ताक्षर विधि के लिए दस्तावेज़ित निजी कुंजी प्रकार RSA है। IPsec या प्रमाणपत्र लिखा मेनू ECDSA समर्थन का अर्थ नहीं है, और उस मान्यता पर बना प्रोफ़ाइल नेटवर्क आने से पहले ही प्लेटफ़ॉर्म API पर विफल हो जाता है।
सिर्फ़ सार्वजनिक उपयोगकर्ता प्रमाणपत्र क्यों पर्याप्त नहीं
AUTH पेलोड क्लाइंट की निजी कुंजी से आदान-प्रदान पर बना हस्ताक्षर है। सार्वजनिक प्रमाणपत्र गेटवे को हस्ताक्षर जाँचने देता है, पर फ़ोन के लिए कुछ नहीं करता, क्योंकि हस्ताक्षर बनाने के लिए उसे कुंजी चाहिए। सिर्फ़ .crt आयात करके कुंजी पीछे छोड़ देना इस विफलता का सबसे आम रूप है।
Android की कुंजी संरचना यही दिखाती है: क्लाइंट पहचान चुनना KeyChain से होता है, जिसके लिए संबंधित निजी कुंजी तक पहुँच चाहिए, सिर्फ़ प्रमाणपत्र प्रविष्टि नहीं। जोड़ी को साथ स्थापित करने वाला नामांकन पैकेज या डिवाइस प्रबंधन प्रवाह सामान्य रास्ता है; फ़ाइल हाथ से कॉपी करना आम तौर पर नहीं।
इसलिए प्रोफ़ाइल की दो चीज़ें प्रमाणपत्रों का बंडल और उसकी नकल नहीं हैं। एक कुंजी जोड़ी है जिससे प्लेटफ़ॉर्म को हस्ताक्षर कर सकना चाहिए, दूसरी भरोसा एंकर है जिससे वह तुलना करता है। इन्हें दो अलग तथ्यों की तरह जाँचें: क्या यह प्रोफ़ाइल हस्ताक्षर कर सकता है, और क्या यह जानता है कि किस पर भरोसा करना है?
भरोसा एंकर एप्लिकेशन के हैं, फ़ोन के नहीं
उपयोगकर्ता भंडार में मूल प्रमाणपत्र स्थापित करने से हर Android एप्लिकेशन उस पर भरोसा नहीं करता: Android 7 से एप्लिकेशन को अपने नेटवर्क सुरक्षा कॉन्फ़िगरेशन से यह चुनना होता है, और उस संस्करण से पहले उपयोगकर्ता द्वारा स्थापित CA बहुत अधिक व्यापक रूप से स्वीकार किए जाते थे। भरोसा कॉन्फ़िगरेशन एप्लिकेशन के हिसाब से बदल सकता है, और अपनी भरोसा सामग्री खुद प्रबंधित करने वाला VPN क्लाइंट शायद भंडार को कभी न देखे। इसलिए वही CA फ़ाइल एक क्लाइंट में काम कर सकती है और दूसरे में अनदेखी लग सकती है।
इससे दो स्वामित्व मॉडल निकलते हैं। सिस्टम द्वारा प्रबंधित प्रोफ़ाइल डिवाइस के प्रमाणपत्र इंस्टॉलेशन या प्रशासक नामांकन का उपयोग करता है और फिर इच्छित CA का संदर्भ देता है। एप्लिकेशन द्वारा प्रबंधित VPN अपनी भरोसा सामग्री और अपना दस्तावेज़ित आयात रखता है, जो Android सेटिंग स्क्रीन से पूरी तरह अलग हो सकता है। टूटी श्रृंखला वहीं ठीक होती है।
कुछ भी आयात करने से पहले तय करें कि आप किस मॉडल में हैं, फिर सक्रिय प्रोफ़ाइल का भरोसा चयन पुष्ट करें। अगर ऑपरेटर के निर्देश और क्लाइंट का मेनू मेल न खाएँ, तो उस इंस्टॉलेशन के लिए क्लाइंट का दस्तावेज़ित व्यवहार जीतता है, पर CA फिर भी ऑपरेटर से ऐसे मार्ग से आना चाहिए जिसे आप सत्यापित कर सकें। फ़ाइल का नाम इस बात का प्रमाण नहीं है कि उसे किसने जारी किया।
पहले मोड, फिर फ़ाइलें
प्रमाणपत्र मोड के लिए क्लाइंट की कुंजी जोड़ी, गेटवे की ओर जारी करने वाला CA, गेटवे प्रमाणपत्र के लिए भरोसा एंकर और यह अपेक्षा चाहिए कि वह प्रमाणपत्र कौन-सी पहचान रखेगा। उपयोगकर्ता नाम और पासवर्ड कुंजी जोड़ी की जगह क्रेडेंशियल देते हैं पर गेटवे पर भरोसे की शर्त बनाए रखते हैं। PSK दोनों की जगह साझा रहस्य देता है और भरोसा मॉडल को सरल बनाने के बजाय बदल देता है।
आप जो भी चुनें, सामान्य सत्यापन चालू रखें। बिना जाँच वाला विकल्प उस जाँच को हटा देता है जिसके लिए CA फ़ील्ड है; वह गायब भरोसा एंकर ठीक नहीं करता। यही बात किसी भी सर्वर प्रमाणपत्र को इसलिए स्वीकार करने पर लागू होती है कि कनेक्शन उसके बिना भी चलता है।
फिर सही जगह जाँचें: सामग्री आयात करें, एक बार जुड़ें, और कनेक्शन विवरण में पुष्ट करें कि गेटवे की पहचान वही है जिसकी अपेक्षा थी और प्रोफ़ाइल वही विधि बताता है जो आप चाहते थे। गलत विधि के साथ सफल कनेक्शन ऐसा कॉन्फ़िगरेशन है जिसे आप अभी नहीं समझते, और जब ऑपरेटर नीति कड़ी करेगा तो वह विफल होगा।