VPN की निजी कुंजी पर पासफ़्रेज़ वास्तव में क्या सुरक्षित करता है

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

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

एक संवाद, कई अलग रहस्य

निजी कुंजी का पासफ़्रेज़ एक फ़ाइल को डिक्रिप्ट करता है। खाता पासवर्ड आपको किसी सेवा के सामने प्रमाणित करता है। PKCS#12 आयात पासवर्ड उस बंडल को डिक्रिप्ट करता है जिसमें एक कुंजी और उसका प्रमाणपत्र होता है, और हो सकता है कि वह कुंजी के अपने पासफ़्रेज़ जैसी ही स्ट्रिंग न हो। ये प्रॉम्प्ट लगभग एक जैसे दिख सकते हैं, और यह अनुमान लगाना कि कौन सा रहस्य कहाँ जाता है, कुंजियों के गलत फ़ील्ड में चिपके रहने का कारण है।

सुरंग का अपना एन्क्रिप्शन चौथी चीज़ है। डेटा चैनल हैंडशेक के दौरान बातचीत किए गए सत्र कुंजियों का उपयोग करता है; निजी कुंजी के पासफ़्रेज़ की व्यक्तिगत पैकेट की सुरक्षा में कोई भूमिका नहीं है। अगर कोई कुंजी फ़ाइल पढ़ सकता है, तो वह पासफ़्रेज़ का ऑफ़लाइन अनुमान लगाने की कोशिश कर सकता है, लेकिन अगर वह पैकेट पढ़ सकता है, तो पासफ़्रेज़ अप्रासंगिक है।

डिस्क पर एन्क्रिप्शन क्या कवर करता है

एन्क्रिप्टेड PEM कुंजी दो रूपों में आती है, और हेडर बताता है कि आपके पास कौन सा है। आधुनिक PKCS#8 रूप -----BEGIN ENCRYPTED PRIVATE KEY----- से शुरू होता है; पुराना PEM रूप, जो पुराने OpenVPN सेटअप में अभी भी आम है, -----BEGIN RSA PRIVATE KEY----- से शुरू होता है और उसके ठीक नीचे Proc-Type: 4,ENCRYPTED और एक DEK-Info पंक्ति रखता है। फ़ाइल निजी कुंजी को आपके पासफ़्रेज़ से प्राप्त कुंजी के अंतर्गत एन्क्रिप्ट करके रखती है, आमतौर पर पासवर्ड-आधारित KDF के माध्यम से जिसमें बताई गई पुनरावृत्ति संख्या या कार्य कारक होता है। OpenSSL pkey दस्तावेज़ उन प्रारूपों और पासफ़्रेज़ विकल्पों को कवर करते हैं जो पढ़ते समय लागू होते हैं।

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

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 हेडर दिखाता है और पुरानी फ़ाइल में एन्क्रिप्शन साबित करने वाली Proc-Type और DEK-Info पंक्तियाँ दिखाता है; अकेली एक पंक्ति किसी भी दिशा में प्रमाण नहीं है। pkey पंक्ति पासफ़्रेज़ माँगती है और केवल सार्वजनिक आधा हिस्सा छापती है, जो साबित करता है कि फ़ाइल और पासफ़्रेज़ काम करते हैं निजी कुंजी को उजागर किए बिना। उस जाँच के लिए -text का उपयोग न करें: यह निजी घटकों, privateExponent, prime1, prime2 और बाकी को छापता है, और वह आउटपुट कभी कहीं चिपकाया नहीं जाना चाहिए, न टिकट में, न चैट में, न लॉग में। PKCS#12 कमांड यह भी बताता है कि बंडल में अलग MAC या एन्क्रिप्शन पासवर्ड है या नहीं, जो किसी सहकर्मी को देने से पहले जानना उपयोगी है।

कुंजी लोड होने के बाद यह क्या सुरक्षित करना बंद कर देता है

अनलॉक करना उस प्रक्रिया के लिए एकतरफा घटना है। क्लाइंट KDF से कुंजी माँगता है, फ़ाइल को डिक्रिप्ट करता है, और जब तक ज़रूरत हो निजी कुंजी को स्मृति में रखता है। उस क्षण से पासफ़्रेज़ चल रहे सत्र के बारे में कुछ भी सुरक्षित नहीं करता: न प्रक्रिया की स्मृति, न कोर डंप, न क्लाइंट से जुड़ा डिबगिंग सत्र, और न कुंजी के उपयोग के दौरान लिया गया मशीन का बैकअप।

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

प्रॉम्प्ट बार-बार क्यों लौटता है

हर पुनः कनेक्शन पर फिर पूछने वाला क्लाइंट जरूरी नहीं कि टूटा हो। कुछ क्लाइंट सत्र के लिए पासफ़्रेज़ कैश करते हैं, कुछ उसे OS की कुंजीपेटी में संग्रहीत करते हैं, और कुछ को ऐसे सहायक की ओर इंगित किया जा सकता है जो उसे प्रदान करता है, इसलिए आपको कौन सा व्यवहार मिलता है यह क्लाइंट और उसके कॉन्फ़िगरेशन पर निर्भर करता है, कुंजी फ़ाइल पर नहीं।

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

हानि और प्रदर्शन एक ही मरम्मत नहीं हैं

खोया हुआ पासफ़्रेज़ प्रमाणपत्र से पुनर्प्राप्त नहीं किया जा सकता। प्रमाणपत्र सार्वजनिक सामग्री है जो एक नाम को कुंजी से बाँधती है; इसमें निजी कुंजी तक वापसी का कोई रास्ता नहीं है और पासफ़्रेज़ के बारे में कोई संकेत नहीं है। व्यावहारिक विकल्प कुंजी का अधिकृत बैकअप, या ऑपरेटर की सामान्य प्रक्रिया से जारी नई पहचान है। पासफ़्रेज़ को 'पुनर्प्राप्त' करने का प्रस्ताव देने वाला हर व्यक्ति उसका अनुमान लगाने का प्रस्ताव दे रहा है।

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