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 फाँट जुन जाँचका लागि छ त्यो हटाउँछ; हराएको विश्वासको आधार मर्मत गर्दैन। जडान त्यसबिना चल्छ भनेर कुनै पनि सर्भर प्रमाणपत्र स्वीकार गर्नेमा पनि त्यही लागू हुन्छ।
त्यसपछि ठीक ठाउँमा जाँच्नुहोस्: सामग्री आयात गर्नुहोस्, एकपटक जोडिनुहोस्, र जडान विवरणमा गेटवेको पहिचान अपेक्षित भएको र प्रोफाइलले तपाईंले चाहेको विधि जनाएको पुष्टि गर्नुहोस्। गलत विधिसँग सफल जडान तपाईंले अझै नबुझेको कन्फिगरेसन हो, र अपरेटरले नीति कडा गर्दा त्यो असफल हुनेछ।