فی ڈیوائس ایک سرٹیفکیٹ کلید کو ڈیوائس سے منسلک نہیں بناتا
ہر ڈیوائس کے لیے الگ سرٹیفکیٹ منتظم کا انتخاب ہے، ڈیوائس کے ساتھ بندھن نہیں۔ بندھن کا فیصلہ یہ کرتا ہے کہ نجی کلید کہاں رہتی ہے، نقل پذیر فائل سے لے کر 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 سے آتی ہے۔ ڈیوائس کے ساتھ بندھن کلید کی حفاظت سے آتا ہے۔ صرف وہ ہارڈویئر جو اپنی کلید برآمد نہیں کر سکتا، فی ڈیوائس ایک سرٹیفکیٹ کو ایسے دعوے میں بدلتا ہے جسے سرور نافذ کرتا ہے، نہ کہ ایسی پالیسی میں جس پر سب متفق ہوں۔