प्रति डिवाइस एक प्रमाणपत्र कुंजी को डिवाइस से बद्ध नहीं करता
प्रति डिवाइस प्रमाणपत्र एक प्रशासनिक विकल्प है, डिवाइस से बंधन नहीं। बंधन तय करता है कि निजी कुंजी कहाँ रहती है, एक प्रतिलिपि-योग्य फ़ाइल से TPM तक।
आप हर लैपटॉप के लिए अलग प्रमाणपत्र जारी करते हैं, इसलिए मान लेते हैं कि VPN उन्हें अलग पहचान सकता है। नहीं पहचान सकता। क्लाइंट प्रमाणपत्र साबित करता है कि जो जुड़ता है उसके पास मेल खाती निजी कुंजी है, और प्रतिलिपि की गई प्रोफ़ाइल के पास भी वह होती है।
प्रति डिवाइस प्रमाणपत्र फिर भी अच्छा विचार है। यह बस वह काम नहीं करता जो ज़्यादातर लोग उम्मीद करते हैं।
क्लाइंट प्रमाणपत्र वास्तव में क्या साबित करता है
हैंडशेक के दौरान क्लाइंट अपने प्रमाणपत्र से मेल खाती निजी कुंजी से हस्ताक्षर करता है, और सर्वर उस हस्ताक्षर को उस CA के सामने सत्यापित करता है जिस पर वह भरोसा करता है। उस आदान-प्रदान में मशीन का कोई वर्णन नहीं है। प्रमाणपत्र और कुंजी दोनों रखने वाला कोई भी डिवाइस एक जैसा हस्ताक्षर बनाता है, इसलिए दूसरे लैपटॉप पर प्रतिलिपि की गई प्रोफ़ाइल बिल्कुल मूल जैसी दिखती है। प्रमाणपत्र किसी पहचान का नाम देता है; हार्डवेयर का नाम नहीं देता।
प्रति डिवाइस विशिष्टता अब भी काम की है, क्योंकि यह निरसन को सटीक बनाती है। यह प्रशासनिक गुण है, तकनीकी ताला नहीं।
कुंजी भंडारण के तीन स्तर
पहला स्तर डिस्क पर कुंजी फ़ाइल है। यह डिज़ाइन से ही पोर्टेबल है, और ज़्यादातर OpenVPN प्रोफ़ाइल वहीं रहती हैं।
दूसरा स्तर वह कुंजी है जिसे ऑपरेटिंग सिस्टम निर्यात-अयोग्य चिह्नित करता है। Windows अपने प्रमाणपत्र भंडार में डिवाइस कुंजी बना सकता है और सामान्य निर्यात से मना कर सकता है, जो आकस्मिक प्रतिलिपि रोकता है। यह हार्डवेयर-समर्थित नहीं है, और मशीन तक पर्याप्त पहुँच होने पर ऐसी कुंजियाँ वापस पाई जा सकती हैं, इसलिए यह दीवार बनाने के बजाय मेहनत बढ़ाता है।
तीसरा स्तर सुरक्षा हार्डवेयर के भीतर बनी कुंजी है: TPM, स्मार्ट कार्ड, SIM या PIV टोकन। उन मॉड्यूल में अपनी बनाई कुंजी निर्यात करने का परिपथ नहीं होता, और हस्ताक्षर मॉड्यूल के भीतर ही होता है। कुंजी कभी ऐसी फ़ाइल नहीं बनती जिसे कोई भी प्रतिलिपि कर सके।
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
वह तालिका तीन पंक्तियों में पूरा तर्क है।
easy-rsa क्या कर सकता है और क्या नहीं
प्रति डिवाइस प्रमाणपत्र जारी करना सीधा है। उसी CA के सामने हर डिवाइस के लिए अलग सामान्य नाम बनाएँ, जैसे ./easyrsa build-client-full laptop-a nopass, और हर डिवाइस के लिए दोहराएँ। लिख लें कि कौन-सा सामान्य नाम किस व्यक्ति और मशीन का है।
निरसन भी उतना ही सीधा है: ./easyrsa revoke laptop-a, ./easyrsa gen-crl से CRL फिर बनाएँ, और सुनिश्चित करें कि सर्वर वास्तव में crl-verify के ज़रिए उसे पढ़ता है।
CA जो नहीं कर सकता वह है यह सत्यापित करना कि निजी कुंजी बाद में कहाँ रहती है। यदि आप कुंजी CA होस्ट पर बनाकर डिवाइस पर प्रतिलिपि करते हैं, तो जारी करते समय दूसरी प्रतिलिपि बना दी। निर्यात-अयोग्य कुंजी डिवाइस पर ही बननी चाहिए, या ऐसे हार्डवेयर में आयात होनी चाहिए जो उसे छोड़ेगा नहीं।
प्रतिलिपि की गई प्रोफ़ाइल में टिकने वाले नियंत्रण
मान लें कि प्रोफ़ाइल की प्रतिलिपि हो सकती है और उसी हिसाब से रचना करें। खाते को दूसरे कारक से बाँधें ताकि अकेला प्रमाणपत्र पर्याप्त न हो। हर डिवाइस को उसकी अपनी नीति दें ताकि एक पहचान की पहुँच सीमित रहे। और उसी सामान्य नाम को एक साथ दो पतों से जुड़ते देखें, क्योंकि कनेक्शन लॉग में साझा प्रोफ़ाइल ऐसी ही दिखती है।
तेज़ और प्रलेखित निरसन वही नियंत्रण है जो प्रतिलिपि हो जाने के बाद भी काम करता है। बाकी सब रोकथाम है।
वह दावा जिस पर सर्वर वास्तव में भरोसा कर सकता है
विशिष्टता CA से आती है। डिवाइस से बंधन कुंजी भंडारण से आता है। केवल वही हार्डवेयर जो अपनी कुंजी निर्यात नहीं कर सकता, प्रति डिवाइस एक प्रमाणपत्र को सबकी सहमत नीति के बजाय सर्वर द्वारा लागू दावे में बदलता है।