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 پروفائل بلڈر کیا مانگتا ہے
Google کا IKEv2 پروفائل بلڈر ہر توثیقی طریقہ الگ الگ پیش کرتا ہے، ایک واحد سرٹیفکیٹ موڈ کے طور پر نہیں۔ ڈیجیٹل دستخط کا طریقہ صارف کا سرٹیفکیٹ، نجی چابی اور سرور کی جڑ CA لیتا ہے۔ باقی طریقے صارف نام اور پاس ورڈ، یا پہلے سے مشترکہ چابی لیتے ہیں۔
اس دستخط کو غور سے پڑھیں، کیونکہ یہ اوپر بیان کردہ طریقہ کار کو انکوڈ کرتا ہے۔ صارف نام اور پاس ورڈ والے طریقے میں صارف کی نجی چابی کے لیے کوئی فیلڈ نہیں، اور PSK طریقے میں گیٹ وے کے قابل اعتماد اینکر کے لیے کوئی فیلڈ نہیں، سادہ سی وجہ سے کہ یہ طریقے مختلف چیزیں ثابت کرتے ہیں۔ پاس ورڈ کو سرٹیفکیٹ کی فیلڈ میں چپکا کر انہیں ملانا ایسا پروفائل بناتا ہے جو IKE_AUTH پر ناکام ہوتا ہے اور پیغام میں کسی کا نام بھی نہیں ہوتا۔
ڈیجیٹل دستخط کے طریقے کے لیے دستاویزی نجی چابی کی قسم RSA ہے۔ IPsec یا سرٹیفکیٹ کے لیبل والا مینو ECDSA کی حمایت کا مطلب نہیں، اور اس مفروضے پر بنایا گیا پروفائل کہ یہ حمایت موجود ہے، نیٹ ورک کے شامل ہونے سے پہلے ہی پلیٹ فارم کے API پر ناکام ہو جائے گا۔
صرف عوامی صارف سرٹیفکیٹ کیوں کافی نہیں
AUTH پے لوڈ تبادلے پر کلائنٹ کی نجی چابی سے بنایا گیا دستخط ہے۔ عوامی سرٹیفکیٹ رکھنے سے گیٹ وے دستخط جانچ سکتا ہے؛ فون کے لیے اس سے کچھ نہیں ہوتا، کیونکہ اسے دستخط بنانے کے لیے چابی چاہیے۔ صرف .crt درآمد کرنا اور چابی پیچھے چھوڑ دینا اس ناکامی کی سب سے عام شکل ہے۔
Android کی چابی کا ڈھانچہ اسی کی عکاسی کرتا ہے۔ کلائنٹ شناخت منتخب کرنا KeyChain سے گزرتا ہے، جس کے لیے متعلقہ نجی چابی تک رسائی درکار ہے، نہ کہ صرف سرٹیفکیٹ کا اندراج۔ ایسا اندراج پیکج یا ڈیوائس مینجمنٹ کا عمل جو دونوں کو ایک ساتھ نصب کرے، قابل استعمال شناخت حاصل کرنے کا معمول کا طریقہ ہے؛ سرٹیفکیٹ فائل کو ہاتھ سے کاپی کرنا عام طور پر نہیں۔
لہذا پروفائل کی دو اشیاء سرٹیفکیٹ بنڈل اور اس کی نقل نہیں ہیں۔ ایک چابی کا جوڑا ہے جس سے پلیٹ فارم دستخط کر سکے، دوسرا قابل اعتماد اینکر ہے جس سے پلیٹ فارم موازنہ کرتا ہے۔ انہیں دو الگ حقائق کے طور پر جانچیں: کیا یہ پروفائل دستخط کر سکتا ہے، اور کیا یہ جانتا ہے کہ کس پر بھروسہ کرنا ہے؟
قابل اعتماد اینکر ایپلیکیشن کے ہوتے ہیں، فون کے نہیں
صارف کے اسٹور میں جڑ سرٹیفکیٹ نصب کرنے سے ہر Android ایپلیکیشن اس پر بھروسہ نہیں کرنے لگتی: Android 7 سے ایپ کو اپنی نیٹ ورک سیکیورٹی کنفیگریشن کے ذریعے شامل ہونا پڑتا ہے، اور اس ورژن سے پہلے صارف کی نصب کردہ CA زیادہ وسیع پیمانے پر قبول کی جاتی تھیں۔ ایپلیکیشن کی بھروسے کی کنفیگریشن مختلف ہو سکتی ہے، اور وہ VPN کلائنٹ جو اپنا بھروسہ مواد خود سنبھالتا ہے، شاید صارف کے اسٹور کو دیکھے ہی نہیں۔ اسی لیے ایک ہی CA فائل ایک کلائنٹ میں کام کر سکتی ہے اور دوسرے میں نظرانداز لگتی ہے۔
اس سے دو ملکیت کے ماڈل نکلتے ہیں۔ سسٹم کے زیر انتظام VPN پروفائل ڈیوائس کی سرٹیفکیٹ تنصیب یا منتظم کے اندراج کے عمل کو استعمال کرتا ہے، اور پھر پروفائل مطلوبہ CA کا حوالہ دیتا ہے۔ ایپ کے زیر انتظام VPN اپنا بھروسہ مواد رکھتا ہے اور اپنا دستاویزی درآمد استعمال کرتا ہے، جو Android کی ترتیبات کی اسکرین سے بالکل الگ ہو سکتا ہے۔ ٹوٹا ہوا سلسلہ وہیں ٹھیک ہوتا ہے: سسٹم کے زیر انتظام صورت میں CA اسٹور اور پروفائل کے انتخاب میں، ایپ کے زیر انتظام صورت میں کلائنٹ کی اپنی درآمد اسکرین میں۔
کچھ بھی درآمد کرنے سے پہلے طے کریں کہ آپ کس ماڈل میں ہیں، پھر فعال پروفائل کے بھروسے کا انتخاب تصدیق کریں۔ اگر آپریٹر کی ہدایات اور کلائنٹ کا مینو متفق نہ ہوں تو اس تنصیب کے لیے کلائنٹ کا دستاویزی رویہ غالب ہے، لیکن CA پھر بھی آپریٹر سے ایسے ذریعے آنا چاہیے جس کی آپ تصدیق کر سکیں۔ فائل کا نام اس بات کا ثبوت نہیں کہ اسے کس نے جاری کیا۔
پہلے موڈ چنیں، پھر فائلیں
سرٹیفکیٹ موڈ کے لیے کلائنٹ کا چابی جوڑا، گیٹ وے کی طرف جاری کرنے والا CA، گیٹ وے سرٹیفکیٹ کے لیے قابل اعتماد اینکر، اور یہ توقع درکار ہے کہ اس سرٹیفکیٹ میں کون سی شناخت ہونی چاہیے۔ صارف نام اور پاس ورڈ والا موڈ کلائنٹ کے چابی جوڑے کی جگہ اسناد رکھتا ہے لیکن گیٹ وے پر بھروسے کی شرط برقرار رکھتا ہے۔ PSK موڈ دونوں کی جگہ مشترکہ راز رکھتا ہے اور بھروسے کے ماڈل کو آسان بنانے کے بجائے بدل دیتا ہے۔
آپ جو بھی چنیں، معمول کی توثیق کو فعال رکھیں۔ جہاں کلائنٹ یہ پیش کرے، تصدیق نہ کریں کا اختیار وہ جانچ ختم کر دیتا ہے جس کے لیے CA فیلڈ موجود ہے؛ یہ غائب قابل اعتماد اینکر کو ٹھیک نہیں کرتا۔ یہی بات کسی بھی سرور سرٹیفکیٹ کو صرف اس لیے قبول کرنے پر بھی لاگو ہوتی ہے کہ رابطہ اس کے بغیر کام کرتا ہے۔
پھر درست جگہ پر تصدیق کریں: مواد درآمد کریں، ایک بار جڑیں، اور کلائنٹ کی رابطے کی تفصیلات میں تصدیق کریں کہ گیٹ وے کی شناخت وہی ہے جس کی آپ توقع کرتے تھے اور پروفائل وہ توثیقی طریقہ بتا رہا ہے جو آپ استعمال کرنے کا ارادہ رکھتے تھے۔ غلط طریقہ منتخب ہونے کے باوجود کامیاب رابطہ ایسی کنفیگریشن ہے جو آپ ابھی نہیں سمجھتے، اور اگلی بار آپریٹر کے پالیسی سخت کرنے پر یہ ناکام ہو جائے گی۔