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 ঘরটি যে কাজের জন্য আছে সেই পরীক্ষাটি সরিয়ে দেয়; অনুপস্থিত বিশ্বাসভিত্তি ঠিক করে না। সংযোগটি তা ছাড়াও চলে বলে যেকোনো সার্ভার সার্টিফিকেট মেনে নেওয়ার ক্ষেত্রেও একই কথা।
তারপর সঠিক জায়গায় যাচাই করুন: উপকরণ আমদানি করুন, একবার সংযোগ করুন, আর ক্লায়েন্টের সংযোগের বিবরণে নিশ্চিত করুন যে গেটওয়ের পরিচয় আপনার প্রত্যাশিতটিই এবং প্রোফাইল আপনার ইচ্ছাকৃত পদ্ধতিটিই জানাচ্ছে। ভুল পদ্ধতিতে সফল সংযোগ এমন একটি কনফিগারেশন যা আপনি এখনো বোঝেন না, আর অপারেটর নীতি কঠোর করলে তা ব্যর্থ হবে।