IPsec, OpenVPN और WireGuard में पहले से साझा कुंजी क्या करती है

पहले से साझा कुंजी शब्द IPsec, OpenVPN और WireGuard के दस्तावेज़ों में आते हैं, पर तीन अलग वस्तुओं की ओर संकेत करते हैं। एक प्रमाणन का रहस्य है, दूसरी एक नियंत्रण चैनल की रक्षा करती है, और तीसरी उन हाथ मिलाने में सामग्री जोड़ती है जिनके पास पहले से पहचान हैं। इन्हें विनिमेय मानना ऐसा कनेक्शन बनाता है जो ऐसे चरण पर विफल होता है जिसकी किसी ने अपेक्षा नहीं की थी। मान उसमें नकल करने से पहले पढ़ें कि वह फ़ील्ड उस प्रोटोकॉल में क्या करती है।

तीन प्रोटोकॉल, तीन अर्थ

हर प्रोटोकॉल कुंजी का काम अपने विनिर्देश में तय करता है और ये काम एक-दूसरे पर नहीं चढ़ते। प्रमाणन का रहस्य सिद्ध करता है कि दो पक्ष एक ही मान जानते हैं। नियंत्रण चैनल की कुंजी उसके बाद होने वाली बातचीत की रक्षा करती है। हाथ मिलाने का अतिरिक्त हिस्सा कुंजी-अनुसूची बदलता है, बिना यह बदले कि पक्ष कौन हैं।

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

IPsec और OpenVPN इस शब्द का अलग ढंग से उपयोग करते हैं

IKEv2 किसी पक्ष का प्रमाणन प्रमाणपत्रों की जगह पहले से साझा रहस्य से कर सकता है, और मान दोनों सिरों पर मेल खाना चाहिए। चूँकि वही रहस्य आमतौर पर पक्षों के एक समूह के लिए सेट होता है, कोई भी धारक बाक़ियों का रूप धर सकता है, और अदला-बदली को उन पहचान कुंजियों से आगे की गोपनीयता नहीं मिलती जो उसके पास कभी नहीं थीं।

OpenVPN के tls-auth और tls-crypt विकल्प नियंत्रण चैनल से एक स्थिर कुंजी जोड़ते हैं, या HMAC हस्ताक्षर जोड़ते हैं या स्वयं बातचीत को एन्क्रिप्ट करते हैं। वह कुंजी उपयोगकर्ता पासवर्ड नहीं है और क्लाइंट प्रमाणपत्र की जगह नहीं लेती। दोनों में अंतर नवीनीकरण के समय मायने रखता है, जब पासवर्ड बदलने से नियंत्रण चैनल की कुंजी अछूती रह जाती है।

WireGuard की PSK जोड़ती है, पहचान नहीं देती

WireGuard के पक्षों के पास पहले से Curve25519 की सार्वजनिक और निजी कुंजियाँ हैं और हाथ मिलाना इन पहचानों का प्रमाणन करता है। वैकल्पिक पहले से साझा कुंजी श्रृंखला-कुंजी में मिलाई जाती है और सार्वजनिक कुंजियों की अदला-बदली के ऊपर सममित सामग्री जोड़ती है।

यह अपने आप में न पहचान देती है न उपयोगकर्ता खाता, इसलिए ऑपरेटर दो धारकों को उनकी PSK से नहीं पहचान सकता। दोनों सिरों पर एक ही मान होना चाहिए, वरना हाथ मिलाना किसी उपयोगी त्रुटि संदेश के बिना विफल हो जाता है। इसीलिए रोटेशन की योजना दोनों पक्षों के लिए एक साथ बनानी होती है, न कि एक फ़ाइल संपादित करने के रूप में।

वितरण, रोटेशन और हटाने की जाँच करें

वितरण हर उस डिज़ाइन का कमज़ोर बिंदु है जो एक रहस्य को कई जगहों पर उपयोग करता है। ऐसा मान जो चैट विंडो में चिपकाया जाए, भंडार में सहेजा जाए या वातावरणों के बीच दोबारा उपयोग हो, ऐसी प्रतियाँ जमा करता है जिन्हें कोई गिन नहीं सकता, और हर प्रति चुपचाप नुकसान का दायरा बढ़ाती है।

Base64 पाठ एन्क्रिप्शन नहीं है। उसी फ़ोल्डर में सार्वजनिक प्रमाणपत्र के बग़ल में रखा रहस्य अब भी खुले पाठ में रहस्य है।

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

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

दर्ज करें कि कौन-सा रहस्य किस चरण की रक्षा करता है, ताकि पासवर्ड रीसेट कभी क्रिप्टोग्राफ़िक कुंजी के नवीनीकरण से न मिलाया जाए। वह एक पंक्ति हर बार एक घंटा बचाती है जब कोई परिनियोजन की समीक्षा करता है।