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 फील्ड ज्या तपासणीसाठी आहे ती काढून टाकतो; गहाळ विश्वासाचा आधार दुरुस्त करत नाही. कनेक्शन त्याशिवाय चालते म्हणून कोणतेही सर्व्हर प्रमाणपत्र स्वीकारण्यावरही तेच लागू.
नंतर योग्य ठिकाणी पडताळा: सामग्री आयात करा, एकदा जोडा, आणि कनेक्शनच्या तपशिलात गेटवेची ओळख अपेक्षित असल्याची व प्रोफाइल तुम्ही ठरवलेली पद्धत सांगत असल्याची पुष्टी करा. चुकीच्या पद्धतीने यशस्वी झालेले कनेक्शन हे अजून न समजलेले संरचना आहे, आणि ऑपरेटरने धोरण कडक केल्यावर ते अपयशी होईल.