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 কীচেইনে সংরক্ষণ করে, আর কিছুকে এমন সহায়ক প্রোগ্রামে নির্দেশ করা যায় যা এটি সরবরাহ করে, তাই আপনি কোন আচরণ পাবেন তা ক্লায়েন্ট ও তার কনফিগারেশনের উপর নির্ভর করে, কী ফাইলের উপর নয়।

যদি বারবার প্রম্পটই আসল অভিযোগ হয়, কী থেকে এনক্রিপশন সরানোর আগে ক্লায়েন্টের ক্যাশিং ও প্রমাণীকরণ বিকল্পগুলি পরীক্ষা করুন। পাসফ্রেজ সরিয়ে ফেললে একটি সুরক্ষিত ফাইল সাধারণ টেক্সট কী-তে পরিণত হয়, এবং পুনরায় সংযোগ শান্ত হয় আপনার একমাত্র বিশ্রাম-নিয়ন্ত্রণের খরচে। আরও ভালো উত্তর সাধারণত একটি সমর্থিত ক্রেডেনশিয়াল স্টোর, যাতে সেই একই ফাইল অনুমতি থাকে যা আপনি যেভাবেই ব্যবহার করতেন।

ক্ষতি ও প্রকাশ একই মেরামত নয়

হারানো পাসফ্রেজ সার্টিফিকেট থেকে পুনরুদ্ধার করা যায় না। সার্টিফিকেট হলো একটি নামকে কী-এর সাথে বাঁধা পাবলিক উপাদান; এতে ব্যক্তিগত কী-এর দিকে ফিরে যাওয়ার পথ নেই এবং পাসফ্রেজের কোনো ইঙ্গিত নেই। ব্যবহারিক বিকল্প হলো কী-এর অনুমোদিত ব্যাকআপ, বা অপারেটরের স্বাভাবিক প্রক্রিয়ায় ইস্যু করা নতুন পরিচয়। যে কেউ পাসফ্রেজ 'পুনরুদ্ধার' করার প্রস্তাব দেয়, সে এটি অনুমান করার প্রস্তাব দেয়।

প্রকাশের জন্য ভিন্ন প্রতিক্রিয়া প্রয়োজন। একই কী নতুন পাসফ্রেজ দিয়ে পুনরায় এনক্রিপ্ট করলে কী উপাদান অপরিবর্তিত থাকে, তাই অন্যত্র ইতিমধ্যে আনলক করা একটি কপি এখনও কাজ করে। মেরামত হলো ক্রেডেনশিয়াল প্রত্যাহার বা প্রতিস্থাপন: নতুন কী ও সার্টিফিকেট ইস্যু করুন, বিতরণ করুন, এবং পুরোনোটি সমকক্ষে অবসর দিন। যতক্ষণ তা না হয়, ফাইল পাসওয়ার্ড বদলানো হলো ঘরকন্নার কাজ, নিয়ন্ত্রণ নয়। নতুন পরিচয় কাজ করছে নিশ্চিত হওয়ার পরেই পুরোনো ফাইল ব্যাকআপের বাইরে রাখুন, এবং কোন সিরিয়াল বা ফিঙ্গারপ্রিন্ট এটি প্রতিস্থাপন করেছে তা লিখে রাখুন।