یہ کوئی راز نہیں ہے کہ عام طور پر استعمال ہونے والے معاون آلات میں سے ایک، جس کے بغیر کھلے نیٹ ورکس میں ڈیٹا کی حفاظت ناممکن ہے، ڈیجیٹل سرٹیفکیٹ ٹیکنالوجی ہے۔ تاہم، یہ کوئی راز نہیں ہے کہ ٹیکنالوجی کی بنیادی خرابی ڈیجیٹل سرٹیفکیٹ جاری کرنے والے مراکز پر غیر مشروط اعتماد ہے۔ ENCRY میں ٹیکنالوجی اور انوویشن کے ڈائریکٹر آندرے چمورا نے تنظیم سازی کے لیے ایک نیا طریقہ تجویز کیا۔ عوامی کلیدی بنیادی ڈھانچہ (عوامی کلیدی بنیادی ڈھانچہ، PKI)، جو موجودہ کوتاہیوں کو ختم کرنے میں مدد کرے گا اور جو تقسیم شدہ لیجر (بلاک چین) ٹیکنالوجی کا استعمال کرتا ہے۔ لیکن سب سے پہلے چیزیں.
اگر آپ اس بات سے واقف ہیں کہ آپ کا موجودہ عوامی کلیدی بنیادی ڈھانچہ کس طرح کام کرتا ہے اور اس کی اہم کوتاہیوں کو جانتے ہیں، تو آپ اس پر آگے بڑھ سکتے ہیں جسے ہم ذیل میں تبدیل کرنے کی تجویز کر رہے ہیں۔
ڈیجیٹل دستخط اور سرٹیفکیٹ کیا ہیں؟انٹرنیٹ پر تعامل میں ہمیشہ ڈیٹا کی منتقلی شامل ہوتی ہے۔ ہم سب کو اس بات کو یقینی بنانے میں دلچسپی ہے کہ ڈیٹا کو محفوظ طریقے سے منتقل کیا جائے۔ لیکن سیکورٹی کیا ہے؟ سب سے زیادہ مطلوب سیکورٹی خدمات رازداری، سالمیت اور صداقت ہیں۔ اس مقصد کے لیے، غیر متناسب خفیہ نگاری، یا عوامی کلید کے ساتھ خفیہ نگاری کے طریقے فی الحال استعمال کیے جاتے ہیں۔
آئیے اس حقیقت کے ساتھ شروع کریں کہ ان طریقوں کو استعمال کرنے کے لیے، تعامل کے مضامین میں دو انفرادی جوڑی والی چابیاں ہونی چاہئیں - عوامی اور خفیہ۔ ان کی مدد سے، ہم نے اوپر ذکر کردہ حفاظتی خدمات فراہم کی ہیں۔
معلومات کی منتقلی کی رازداری کیسے حاصل کی جاتی ہے؟ ڈیٹا بھیجنے سے پہلے، بھیجنے والا سبسکرائبر وصول کنندہ کی عوامی کلید کا استعمال کرتے ہوئے کھلے ڈیٹا کو خفیہ کرتا ہے (کرپٹوگرافی طور پر تبدیل کرتا ہے)، اور وصول کنندہ جوڑی کی خفیہ کلید کا استعمال کرتے ہوئے موصولہ سائفر ٹیکسٹ کو ڈکرپٹ کرتا ہے۔
منتقل شدہ معلومات کی سالمیت اور صداقت کیسے حاصل کی جاتی ہے؟ اس مسئلے کو حل کرنے کے لیے ایک اور طریقہ کار بنایا گیا۔ کھلا ڈیٹا انکرپٹڈ نہیں ہے، لیکن کرپٹوگرافک ہیش فنکشن کو لاگو کرنے کا نتیجہ - ان پٹ ڈیٹا کی ترتیب کی ایک "کمپریسڈ" تصویر - کو انکرپٹڈ شکل میں منتقل کیا جاتا ہے۔ اس طرح کے ہیشنگ کے نتیجے کو "ڈائجسٹ" کہا جاتا ہے، اور اسے بھیجنے والے سبسکرائبر ("گواہ") کی خفیہ کلید کا استعمال کرتے ہوئے انکرپٹ کیا جاتا ہے۔ ڈائجسٹ کو خفیہ کرنے کے نتیجے میں، ایک ڈیجیٹل دستخط حاصل کیا جاتا ہے. یہ، واضح متن کے ساتھ، وصول کنندہ سبسکرائبر ("تصدیق کنندہ") کو منتقل کیا جاتا ہے۔ وہ گواہ کی عوامی کلید پر ڈیجیٹل دستخط کو ڈکرپٹ کرتا ہے اور اس کا موازنہ کرپٹوگرافک ہیش فنکشن کو لاگو کرنے کے نتیجے سے کرتا ہے، جس کا تصدیق کنندہ موصول شدہ کھلے ڈیٹا کی بنیاد پر آزادانہ طور پر حساب کرتا ہے۔ اگر وہ مماثل ہیں، تو اس سے ظاہر ہوتا ہے کہ ڈیٹا بھیجنے والے سبسکرائبر کے ذریعے مستند اور مکمل شکل میں منتقل کیا گیا تھا، اور حملہ آور کے ذریعے اس میں ترمیم نہیں کی گئی تھی۔
زیادہ تر وسائل جو ذاتی ڈیٹا اور ادائیگی کی معلومات کے ساتھ کام کرتے ہیں (بینک، انشورنس کمپنیاں، ایئر لائنز، ادائیگی کے نظام کے ساتھ ساتھ ٹیکس سروس جیسے سرکاری پورٹل) فعال طور پر غیر متناسب خفیہ نگاری کے طریقے استعمال کرتے ہیں۔
ڈیجیٹل سرٹیفکیٹ کا اس سے کیا تعلق ہے؟ یہ آسان ہے. پہلی اور دوسری دونوں کارروائیوں میں عوامی چابیاں شامل ہوتی ہیں، اور چونکہ وہ مرکزی کردار ادا کرتی ہیں، اس لیے یہ یقینی بنانا بہت ضروری ہے کہ چابیاں درحقیقت بھیجنے والے (گواہ، دستخط کی توثیق کی صورت میں) یا وصول کنندہ کی ہیں، اور نہیں ہیں۔ حملہ آوروں کی چابیاں سے تبدیل کر دیا گیا۔ یہی وجہ ہے کہ عوامی کلید کی صداقت اور سالمیت کو یقینی بنانے کے لیے ڈیجیٹل سرٹیفکیٹس موجود ہیں۔
نوٹ: عوامی کلید کی صداقت اور سالمیت کی تصدیق بالکل اسی طرح کی جاتی ہے جیسے عوامی ڈیٹا کی صداقت اور سالمیت، یعنی الیکٹرانک ڈیجیٹل دستخط (EDS) کا استعمال کرتے ہوئے۔
ڈیجیٹل سرٹیفکیٹ کہاں سے آتے ہیں؟قابل اعتماد سرٹیفیکیشن اتھارٹیز، یا سرٹیفیکیشن اتھارٹیز (CAs) ڈیجیٹل سرٹیفکیٹ جاری کرنے اور برقرار رکھنے کے ذمہ دار ہیں۔ درخواست دہندہ CA سے سرٹیفکیٹ جاری کرنے کی درخواست کرتا ہے، رجسٹریشن سینٹر (CR) میں شناخت سے گزرتا ہے اور CA سے سرٹیفکیٹ حاصل کرتا ہے۔ CA اس بات کی ضمانت دیتا ہے کہ سرٹیفکیٹ کی عوامی کلید بالکل اسی ہستی سے تعلق رکھتی ہے جس کے لیے اسے جاری کیا گیا تھا۔
اگر آپ عوامی کلید کی صداقت کی تصدیق نہیں کرتے ہیں، تو اس کلید کی منتقلی/ذخیرہ کرنے کے دوران حملہ آور اسے اپنی کلید سے بدل سکتا ہے۔ اگر متبادل ہو گیا ہے تو حملہ آور ہر اس چیز کو ڈکرپٹ کر سکے گا جسے بھیجنے والا سبسکرائبر وصول کنندہ کو منتقل کرتا ہے، یا کھلے ڈیٹا کو اپنی صوابدید پر تبدیل کر سکتا ہے۔
ڈیجیٹل سرٹیفکیٹ استعمال کیے جاتے ہیں جہاں بھی غیر متناسب خفیہ نگاری دستیاب ہے۔ سب سے عام ڈیجیٹل سرٹیفکیٹس میں سے ایک HTTPS پروٹوکول پر محفوظ مواصلت کے لیے SSL سرٹیفکیٹ ہے۔ مختلف دائرہ اختیار میں رجسٹرڈ سینکڑوں کمپنیاں SSL سرٹیفکیٹ جاری کرنے میں ملوث ہیں۔ اہم حصہ پانچ سے دس بڑے قابل اعتماد مراکز پر آتا ہے: IdenTrust، Comodo، GoDaddy، GlobalSign، DigiCert، CERTUM، Actalis، Secom، Trustwave۔
CA اور CR PKI کے اجزاء ہیں، جس میں یہ بھی شامل ہیں:
- ڈائرکٹری کھولیں۔ - ایک عوامی ڈیٹا بیس جو ڈیجیٹل سرٹیفکیٹس کا محفوظ ذخیرہ فراہم کرتا ہے۔
- سرٹیفکیٹ منسوخی کی فہرست - ایک عوامی ڈیٹا بیس جو منسوخ شدہ عوامی کلیدوں کے ڈیجیٹل سرٹیفکیٹس کا محفوظ ذخیرہ فراہم کرتا ہے (مثال کے طور پر، جوڑی کی گئی نجی کلید کے سمجھوتہ کی وجہ سے)۔ انفراسٹرکچر کے مضامین آزادانہ طور پر اس ڈیٹا بیس تک رسائی حاصل کرسکتے ہیں، یا وہ خصوصی آن لائن سرٹیفیکیشن اسٹیٹس پروٹوکول (OCSP) استعمال کرسکتے ہیں، جو تصدیق کے عمل کو آسان بناتا ہے۔
- سرٹیفکیٹ صارفین - سروس شدہ PKI مضامین جنہوں نے CA کے ساتھ صارف کا معاہدہ کیا ہے اور سرٹیفکیٹ سے عوامی کلید کی بنیاد پر ڈیجیٹل دستخط اور/یا انکرپٹ ڈیٹا کی تصدیق کرتے ہیں۔
- صارفین - PKI مضامین کی خدمت کی جو سرٹیفکیٹ کی عوامی کلید کے ساتھ جوڑی کی خفیہ کلید کے مالک ہیں، اور جنہوں نے CA کے ساتھ سبسکرائبر معاہدہ کیا ہے۔ سبسکرائبر بیک وقت سرٹیفکیٹ کا صارف بن سکتا ہے۔
اس طرح، عوامی کلیدی بنیادی ڈھانچے کے قابل اعتماد ادارے، جن میں CAs، CRs اور اوپن ڈائریکٹریز شامل ہیں، اس کے لیے ذمہ دار ہیں:
1. درخواست گزار کی شناخت کی صداقت کی تصدیق۔
2. عوامی کلید کے سرٹیفکیٹ کی پروفائلنگ۔
3. کسی ایسے درخواست دہندہ کے لیے عوامی کلید کا سرٹیفکیٹ جاری کرنا جس کی شناخت کی معتبر تصدیق ہو چکی ہو۔
4. عوامی کلید کے سرٹیفکیٹ کی حیثیت کو تبدیل کریں۔
5. عوامی کلیدی سرٹیفکیٹ کی موجودہ حیثیت کے بارے میں معلومات فراہم کرنا۔
PKI کے نقصانات، وہ کیا ہیں؟PKI کی بنیادی خامی قابل اعتماد اداروں کی موجودگی ہے۔
صارفین کو غیر مشروط طور پر CA اور CR پر اعتماد کرنا چاہیے۔. لیکن، جیسا کہ پریکٹس سے پتہ چلتا ہے، غیر مشروط اعتماد سنگین نتائج سے بھرا ہوا ہے۔
پچھلے دس سالوں میں، اس علاقے میں بنیادی ڈھانچے کی کمزوری سے متعلق کئی بڑے اسکینڈل سامنے آئے ہیں۔
— 2010 میں، Stuxnet میلویئر آن لائن پھیلنا شروع ہوا، جس پر RealTek اور JMicron سے چوری شدہ ڈیجیٹل سرٹیفکیٹس کا استعمال کرتے ہوئے دستخط کیے گئے۔
- 2017 میں، گوگل نے سیمنٹیک پر بڑی تعداد میں جعلی سرٹیفکیٹ جاری کرنے کا الزام لگایا۔ اس وقت، Symantec پیداوار کے حجم کے لحاظ سے سب سے بڑے CAs میں سے ایک تھا۔ گوگل کروم 70 براؤزر میں، اس کمپنی اور اس سے منسلک مراکز جیو ٹرسٹ اور تھاوٹے کی طرف سے جاری کردہ سرٹیفکیٹس کے لیے سپورٹ کو 1 دسمبر 2017 سے پہلے روک دیا گیا تھا۔
CAs سے سمجھوتہ کیا گیا، اور اس کے نتیجے میں سب کو نقصان اٹھانا پڑا - خود CAs کے ساتھ ساتھ صارفین اور سبسکرائبرز۔ انفراسٹرکچر پر اعتماد کو مجروح کیا گیا ہے۔ اس کے علاوہ، سیاسی تنازعات کے تناظر میں ڈیجیٹل سرٹیفکیٹس کو بلاک کیا جا سکتا ہے، جس سے بہت سے وسائل کا آپریشن بھی متاثر ہوگا۔ یہ بالکل وہی ہے جس کا خدشہ کئی سال پہلے روسی صدارتی انتظامیہ میں تھا، جہاں انہوں نے 2016 میں ریاستی سرٹیفیکیشن سینٹر بنانے کے امکان پر تبادلہ خیال کیا تھا جو RuNet پر سائٹس کو SSL سرٹیفکیٹ جاری کرے گا۔ معاملات کی موجودہ حالت ایسی ہے کہ روس میں ریاستی پورٹل بھی امریکی کمپنیوں کوموڈو یا تھاوٹے (Symantec کی ذیلی کمپنی) کی طرف سے جاری کردہ ڈیجیٹل سرٹیفکیٹ۔
ایک اور مسئلہ ہے - سوال صارفین کی بنیادی توثیق (تصدیق). کسی ایسے صارف کی شناخت کیسے کی جائے جس نے براہ راست ذاتی رابطے کے بغیر ڈیجیٹل سرٹیفکیٹ جاری کرنے کی درخواست کے ساتھ CA سے رابطہ کیا ہے؟ اب یہ بنیادی ڈھانچے کی صلاحیتوں کے لحاظ سے صورتحال کے لحاظ سے حل کیا جاتا ہے۔ کھلے رجسٹروں سے کچھ لیا جاتا ہے (مثال کے طور پر، سرٹیفکیٹ کی درخواست کرنے والے قانونی اداروں کے بارے میں معلومات)؛ ایسی صورتوں میں جہاں درخواست دہندگان افراد ہوں، بینک کے دفاتر یا پوسٹ آفس استعمال کیے جا سکتے ہیں، جہاں شناختی دستاویزات کے ذریعے ان کی شناخت کی تصدیق کی جاتی ہے، مثال کے طور پر، پاسپورٹ۔
نقالی کے مقصد کے لیے جعلی اسناد کا مسئلہ ایک بنیادی مسئلہ ہے۔ آئیے نوٹ کریں کہ معلوماتی نظریاتی وجوہات کی بنا پر اس مسئلے کا کوئی مکمل حل نہیں ہے: قابل اعتماد معلومات کو ترجیح دیے بغیر، کسی خاص موضوع کی صداقت کی تصدیق یا تردید کرنا ناممکن ہے۔ ایک اصول کے طور پر، تصدیق کے لیے ضروری ہے کہ درخواست گزار کی شناخت ثابت کرنے والے دستاویزات کا ایک سیٹ پیش کیا جائے۔ تصدیق کے بہت سے طریقے ہیں، لیکن ان میں سے کوئی بھی دستاویزات کی صداقت کی مکمل ضمانت فراہم نہیں کرتا ہے۔ اس کے مطابق، درخواست گزار کی شناخت کی صداقت کی بھی ضمانت نہیں دی جا سکتی۔
ان خامیوں کو کیسے دور کیا جا سکتا ہے؟اگر PKI کے مسائل کو اس کی موجودہ حالت میں مرکزیت کے ذریعے بیان کیا جا سکتا ہے، تو یہ سمجھنا منطقی ہے کہ وکندریقرت شناخت شدہ خامیوں کو جزوی طور پر ختم کرنے میں مدد کرے گی۔
وکندریقرت کا مطلب قابل اعتماد اداروں کی موجودگی نہیں ہے - اگر آپ تخلیق کرتے ہیں۔ وکندریقرت عوامی کلیدی بنیادی ڈھانچہ (ڈی سینٹرلائزڈ پبلک کلیدی انفراسٹرکچر، ڈی پی کے آئی)، پھر نہ تو CA اور نہ ہی CR کی ضرورت ہے۔ آئیے ڈیجیٹل سرٹیفکیٹ کے تصور کو ترک کریں اور عوامی کلیدوں کے بارے میں معلومات کو ذخیرہ کرنے کے لیے تقسیم شدہ رجسٹری کا استعمال کریں۔ ہمارے معاملے میں، ہم ایک رجسٹر کو ایک لکیری ڈیٹا بیس کہتے ہیں جس میں بلاک چین ٹیکنالوجی کا استعمال کرتے ہوئے منسلک انفرادی ریکارڈ (بلاکس) ہوتے ہیں۔ ڈیجیٹل سرٹیفکیٹ کے بجائے، ہم "اطلاع" کا تصور متعارف کرائیں گے۔
مجوزہ DPKI میں اطلاعات وصول کرنے، تصدیق کرنے اور منسوخ کرنے کا عمل کیسا نظر آئے گا:
1. ہر درخواست دہندہ رجسٹریشن کے دوران ایک فارم کو پُر کرکے آزادانہ طور پر نوٹیفکیشن کے لیے درخواست جمع کراتا ہے، جس کے بعد وہ ایک ٹرانزیکشن بناتا ہے جسے ایک خصوصی پول میں محفوظ کیا جاتا ہے۔
2. عوامی کلید کے بارے میں معلومات، مالک کی تفصیلات اور دیگر میٹا ڈیٹا کے ساتھ، تقسیم شدہ رجسٹری میں محفوظ کی جاتی ہے، نہ کہ ڈیجیٹل سرٹیفکیٹ میں، جس کے اجراء کے لیے مرکزی PKI میں CA ذمہ دار ہے۔
3. درخواست گزار کی شناخت کی صداقت کی تصدیق حقیقت کے بعد DPKI صارف برادری کی مشترکہ کوششوں سے کی جاتی ہے، نہ کہ CR کے ذریعے۔
4. صرف ایسی اطلاع کا مالک ہی عوامی کلید کی حیثیت کو تبدیل کر سکتا ہے۔
5. کوئی بھی تقسیم شدہ لیجر تک رسائی حاصل کر سکتا ہے اور عوامی کلید کی موجودہ حیثیت کی جانچ کر سکتا ہے۔
نوٹ: درخواست گزار کی شناخت کی کمیونٹی تصدیق پہلی نظر میں ناقابل اعتبار لگ سکتی ہے۔ لیکن ہمیں یاد رکھنا چاہیے کہ آج کل ڈیجیٹل سروسز کے تمام صارفین لامحالہ ڈیجیٹل نقش چھوڑتے ہیں، اور یہ عمل صرف رفتار حاصل کرتا رہے گا۔ قانونی اداروں کے الیکٹرانک رجسٹر کھولیں، نقشے، خطوں کی تصاویر کی ڈیجیٹائزیشن، سوشل نیٹ ورکس - یہ سب عوامی طور پر دستیاب ٹولز ہیں۔ صحافیوں اور قانون نافذ کرنے والے اداروں دونوں کی طرف سے تحقیقات کے دوران انہیں پہلے ہی کامیابی سے استعمال کیا جا چکا ہے۔ مثال کے طور پر، بیلنگ کیٹ یا مشترکہ تحقیقاتی ٹیم جے آئی ٹی کی تحقیقات کو یاد کرنا کافی ہے، جو ملائیشین بوئنگ کے حادثے کے حالات کا مطالعہ کر رہی ہے۔
تو ایک وکندریقرت عوامی کلیدی بنیادی ڈھانچہ عملی طور پر کیسے کام کرے گا؟ آئیے ہم اس ٹیکنالوجی کی تفصیل پر غور کرتے ہیں، جسے ہم 2018 میں پیٹنٹ اور ہم اسے بجا طور پر اپنی جانکاری سمجھتے ہیں۔
تصور کریں کہ کوئی ایسا مالک ہے جو بہت ساری عوامی کلیدوں کا مالک ہے، جہاں ہر کلید ایک مخصوص لین دین ہے جو رجسٹری میں محفوظ ہے۔ CA کی غیر موجودگی میں، آپ کیسے سمجھ سکتے ہیں کہ تمام چابیاں اس مخصوص مالک کی ہیں؟ اس مسئلے کو حل کرنے کے لیے، ایک صفر ٹرانزیکشن بنایا جاتا ہے، جس میں مالک اور اس کے بٹوے کے بارے میں معلومات ہوتی ہیں (جس سے رجسٹری میں لین دین کرنے کا کمیشن ڈیبٹ کیا جاتا ہے)۔ null ٹرانزیکشن ایک قسم کا "اینکر" ہے جس میں پبلک کیز کے ڈیٹا کے ساتھ درج ذیل ٹرانزیکشنز منسلک ہوں گی۔ اس طرح کے ہر لین دین میں ایک خصوصی ڈیٹا ڈھانچہ، یا دوسرے لفظوں میں، ایک اطلاع ہوتی ہے۔
نوٹیفکیشن ڈیٹا کا ایک منظم سیٹ ہے جس میں فنکشنل فیلڈز شامل ہیں اور اس میں مالک کی عوامی کلید کے بارے میں معلومات بھی شامل ہیں، جس کی برقراری کی ضمانت تقسیم شدہ رجسٹری کے متعلقہ ریکارڈز میں سے کسی ایک میں جگہ کے ذریعے دی جاتی ہے۔
اگلا منطقی سوال یہ ہے کہ صفر لین دین کیسے بنتا ہے؟ کالعدم لین دین — جیسے کہ بعد میں — چھ ڈیٹا فیلڈز کا مجموعہ ہے۔ صفر لین دین کی تشکیل کے دوران، بٹوے کا کلیدی جوڑا شامل ہوتا ہے (عوامی اور جوڑی خفیہ چابیاں)۔ چابیاں کا یہ جوڑا اس وقت ظاہر ہوتا ہے جب صارف اپنے بٹوے کو رجسٹر کرتا ہے، جس سے رجسٹری میں صفر لین دین کرنے کا کمیشن اور، بعد میں، اطلاعات کے ساتھ آپریشنز ڈیبٹ کیے جائیں گے۔
جیسا کہ تصویر میں دکھایا گیا ہے، ایک والیٹ پبلک کی ڈائجسٹ ترتیب وار SHA256 اور RIPEMD160 ہیش فنکشنز کو لاگو کرکے تیار کیا جاتا ہے۔ یہاں RIPEMD160 ڈیٹا کی کمپیکٹ نمائندگی کے لیے ذمہ دار ہے، جس کی چوڑائی 160 بٹس سے زیادہ نہیں ہے۔ یہ ضروری ہے کیونکہ رجسٹری کوئی سستا ڈیٹا بیس نہیں ہے۔ عوامی کلید خود پانچویں فیلڈ میں داخل ہوتی ہے۔ پہلی فیلڈ میں ڈیٹا ہوتا ہے جو پچھلے لین دین سے کنکشن قائم کرتا ہے۔ صفر ٹرانزیکشن کے لیے، اس فیلڈ میں کچھ بھی نہیں ہے، جو اسے بعد کے لین دین سے ممتاز کرتا ہے۔ دوسرا فیلڈ لین دین کے کنیکٹیویٹی کی جانچ کے لیے ڈیٹا ہے۔ اختصار کے لیے، ہم پہلے اور دوسرے فیلڈ میں ڈیٹا کو بالترتیب "لنک" اور "چیک" کہیں گے۔ ان فیلڈز کے مشمولات تکراری ہیشنگ کے ذریعے تیار کیے گئے ہیں، جیسا کہ ذیل کے اعداد و شمار میں دوسرے اور تیسرے لین دین کو جوڑ کر دکھایا گیا ہے۔
پہلے پانچ فیلڈز کا ڈیٹا الیکٹرانک دستخط سے تصدیق شدہ ہے، جو بٹوے کی خفیہ کلید کا استعمال کرتے ہوئے تیار کیا جاتا ہے۔
بس، کالعدم لین دین کو پول میں بھیج دیا جاتا ہے اور کامیاب تصدیق کے بعد رجسٹری میں داخل کیا جاتا ہے۔ اب آپ درج ذیل لین دین کو اس سے "لنک" کر سکتے ہیں۔ آئیے غور کریں کہ صفر کے علاوہ دیگر لین دین کیسے بنتے ہیں۔
پہلی چیز جس نے شاید آپ کی آنکھ کو پکڑا وہ ہے کلیدی جوڑوں کی کثرت۔ پہلے سے واقف بٹوے کی کلید کے جوڑے کے علاوہ، عام اور سروس کلید کے جوڑے استعمال کیے جاتے ہیں۔
ایک عام عوامی کلید وہ ہے جس کے لیے سب کچھ شروع کیا گیا تھا۔ یہ کلید بیرونی دنیا (بینکنگ اور دیگر لین دین، دستاویز کا بہاؤ، وغیرہ) میں سامنے آنے والے مختلف طریقہ کار اور عمل میں شامل ہے۔ مثال کے طور پر، ایک عام جوڑے کی ایک خفیہ کلید کو مختلف دستاویزات - ادائیگی کے آرڈرز وغیرہ کے لیے ڈیجیٹل دستخط بنانے کے لیے استعمال کیا جا سکتا ہے، اور ایک عوامی کلید کو ان ہدایات پر عمل درآمد کے ساتھ اس ڈیجیٹل دستخط کی تصدیق کے لیے استعمال کیا جا سکتا ہے، بشرطیکہ یہ درست ہے.
سروس جوڑا رجسٹرڈ DPKI مضمون کو جاری کیا جاتا ہے۔ اس جوڑے کا نام اس کے مقصد کے مطابق ہے۔ نوٹ کریں کہ صفر لین دین کی تشکیل/چیک کرتے وقت، سروس کیز استعمال نہیں کی جاتی ہیں۔
آئیے ایک بار پھر چابیاں کا مقصد واضح کرتے ہیں:
- والیٹ کیز کا استعمال null ٹرانزیکشن اور کسی بھی دوسرے غیر null ٹرانزیکشن دونوں کو بنانے/تصدیق کرنے کے لیے کیا جاتا ہے۔ بٹوے کی پرائیویٹ کلید صرف پرس کے مالک کو معلوم ہوتی ہے، جو بہت سی عام پبلک کیز کا بھی مالک ہوتا ہے۔
- ایک عام عوامی کلید ایک عوامی کلید کی طرح ہے جس کے لیے مرکزی PKI میں ایک سرٹیفکیٹ جاری کیا جاتا ہے۔
- سروس کلید کا جوڑا DPKI سے تعلق رکھتا ہے۔ خفیہ کلید رجسٹرڈ اداروں کو جاری کی جاتی ہے اور لین دین کے لیے ڈیجیٹل دستخط تیار کرتے وقت استعمال کی جاتی ہے (سوائے صفر لین دین کے)۔ عوام کا استعمال رجسٹری میں پوسٹ کرنے سے پہلے کسی لین دین کے الیکٹرانک ڈیجیٹل دستخط کی تصدیق کے لیے کیا جاتا ہے۔
اس طرح، چابیاں کے دو گروہ ہیں. پہلی میں سروس کیز اور والیٹ کیز شامل ہیں - یہ صرف DPKI کے تناظر میں معنی رکھتی ہیں۔ دوسرے گروپ میں عام کلیدیں شامل ہیں - ان کا دائرہ کار مختلف ہوسکتا ہے اور اس کا تعین ان ایپلیکیشن کے کاموں سے ہوتا ہے جن میں وہ استعمال ہوتی ہیں۔ ایک ہی وقت میں، DPKI عام پبلک کیز کی صداقت اور صداقت کو یقینی بناتا ہے۔
نوٹ: سروس کلید کا جوڑا مختلف DPKI اداروں کو معلوم ہو سکتا ہے۔ مثال کے طور پر، یہ سب کے لیے یکساں ہو سکتا ہے۔ یہی وجہ ہے کہ ہر غیر صفر لین دین کے دستخط تیار کرتے وقت، دو خفیہ چابیاں استعمال کی جاتی ہیں، جن میں سے ایک بٹوے کی چابی ہے - یہ صرف پرس کے مالک کو معلوم ہے، جو بہت سے عام لین دین کا بھی مالک ہے۔ عوامی چابیاں تمام چابیاں اپنے اپنے معنی رکھتی ہیں۔ مثال کے طور پر، یہ ثابت کرنا ہمیشہ ممکن ہوتا ہے کہ لین دین رجسٹری میں رجسٹرڈ DPKI مضمون کے ذریعے داخل کیا گیا تھا، کیونکہ دستخط بھی خفیہ سروس کی کلید پر بنائے گئے تھے۔ اور کوئی غلط استعمال نہیں ہو سکتا، جیسا کہ DOS حملے، کیونکہ مالک ہر لین دین کی ادائیگی کرتا ہے۔
تمام ٹرانزیکشنز جو صفر کی پیروی کرتے ہیں اسی طرح بنتے ہیں: عوامی کلید (والیٹ نہیں، جیسا کہ صفر ٹرانزیکشن کے معاملے میں، لیکن ایک عام کلیدی جوڑے سے) دو ہیش فنکشنز SHA256 اور RIPEMD160 کے ذریعے چلائی جاتی ہے۔ اس طرح تیسرے فیلڈ کا ڈیٹا بنتا ہے۔ چوتھے فیلڈ میں ساتھ کی معلومات ہوتی ہیں (مثال کے طور پر، موجودہ حیثیت کے بارے میں معلومات، میعاد ختم ہونے کی تاریخیں، ٹائم اسٹیمپ، استعمال شدہ کرپٹو الگورتھم کے شناخت کنندگان وغیرہ)۔ پانچویں فیلڈ میں سروس کلید کے جوڑے سے عوامی کلید شامل ہے۔ اس کی مدد سے، پھر ڈیجیٹل دستخط کی جانچ پڑتال کی جائے گی، لہذا اسے نقل کیا جائے گا. آئیے اس طرح کے نقطہ نظر کی ضرورت کا جواز پیش کریں۔
یاد رکھیں کہ ایک لین دین پول میں داخل ہوتا ہے اور اس پر کارروائی ہونے تک وہاں ذخیرہ ہوتا ہے۔ پول میں ذخیرہ کرنا ایک خاص خطرے سے وابستہ ہے - لین دین کے ڈیٹا کو غلط ثابت کیا جا سکتا ہے۔ مالک الیکٹرانک ڈیجیٹل دستخط کے ساتھ لین دین کے ڈیٹا کی تصدیق کرتا ہے۔ اس ڈیجیٹل دستخط کی تصدیق کے لیے عوامی کلید کو لین دین کے کسی ایک فیلڈ میں واضح طور پر ظاہر کیا جاتا ہے اور بعد میں اسے رجسٹری میں داخل کیا جاتا ہے۔ ٹرانزیکشن پروسیسنگ کی خصوصیات ایسی ہیں کہ حملہ آور اپنی صوابدید پر ڈیٹا کو تبدیل کرنے اور پھر اپنی خفیہ کلید کا استعمال کرتے ہوئے اس کی تصدیق کرنے کے قابل ہوتا ہے، اور لین دین میں ڈیجیٹل دستخط کی تصدیق کے لیے جوڑی والی عوامی کلید کی نشاندہی کرتا ہے۔ اگر صداقت اور سالمیت کو خصوصی طور پر ڈیجیٹل دستخط کے ذریعے یقینی بنایا جائے تو ایسی جعلسازی کسی کا دھیان نہیں جائے گی۔ تاہم، اگر، ڈیجیٹل دستخط کے علاوہ، ایک اضافی طریقہ کار موجود ہے جو ذخیرہ شدہ معلومات کو محفوظ کرنے اور برقرار رکھنے دونوں کو یقینی بناتا ہے، تو جعلسازی کا پتہ لگایا جا سکتا ہے۔ ایسا کرنے کے لیے، رجسٹری میں مالک کی حقیقی عوامی کلید داخل کرنا کافی ہے۔ آئیے وضاحت کریں کہ یہ کیسے کام کرتا ہے۔
حملہ آور کو لین دین کا ڈیٹا جعلی بنانے دیں۔ چابیاں اور ڈیجیٹل دستخطوں کے نقطہ نظر سے، درج ذیل اختیارات ممکن ہیں:
1. حملہ آور لین دین میں اپنی عوامی کلید رکھتا ہے جبکہ مالک کے ڈیجیٹل دستخط میں کوئی تبدیلی نہیں ہوتی ہے۔
2. حملہ آور اپنی نجی کلید پر ڈیجیٹل دستخط بناتا ہے، لیکن مالک کی عوامی کلید کو بغیر کسی تبدیلی کے چھوڑ دیتا ہے۔
3. حملہ آور اپنی نجی کلید پر ایک ڈیجیٹل دستخط بناتا ہے اور لین دین میں ایک جوڑا عوامی کلید رکھتا ہے۔
ظاہر ہے، اختیارات 1 اور 2 بے معنی ہیں، کیونکہ ڈیجیٹل دستخط کی تصدیق کے دوران ان کا ہمیشہ پتہ چل جائے گا۔ صرف آپشن 3 ہی معنی رکھتا ہے، اور اگر کوئی حملہ آور اپنی خفیہ کلید پر ڈیجیٹل دستخط بناتا ہے، تو وہ لین دین میں جوڑی والی عوامی کلید کو محفوظ کرنے پر مجبور ہوتا ہے، جو مالک کی عوامی کلید سے مختلف ہوتی ہے۔ یہ ایک حملہ آور کے لیے غلط ڈیٹا کو مسلط کرنے کا واحد طریقہ ہے۔
آئیے فرض کریں کہ مالک کے پاس چابیاں کا ایک مقررہ جوڑا ہے - نجی اور عوامی۔ اس جوڑے کی خفیہ کلید کا استعمال کرتے ہوئے ڈیٹا کو ڈیجیٹل دستخط کے ذریعے تصدیق شدہ ہونے دیں، اور لین دین میں عوامی کلید کی نشاندہی کی گئی ہے۔ آئیے یہ بھی مان لیں کہ اس عوامی کلید کو پہلے رجسٹری میں داخل کیا جا چکا ہے اور اس کی صداقت کی معتبر طریقے سے تصدیق کی گئی ہے۔ پھر ایک جعلسازی کی نشاندہی اس حقیقت سے کی جائے گی کہ لین دین کی عوامی کلید رجسٹری کی عوامی کلید سے مطابقت نہیں رکھتی۔
چلتے ہیں. مالک کے پہلے لین دین کے ڈیٹا پر کارروائی کرتے وقت، رجسٹری میں درج عوامی کلید کی صداقت کی تصدیق کرنا ضروری ہے۔ ایسا کرنے کے لیے، رجسٹری سے کلید کو پڑھیں اور سیکیورٹی کے دائرے میں موجود مالک کی حقیقی عوامی کلید سے اس کا موازنہ کریں (متعلقہ ناقابل تسخیریت کا علاقہ)۔ اگر کلید کی صداقت کی تصدیق ہو جاتی ہے اور پلیسمنٹ کے بعد اس کی برقراری کی ضمانت دی جاتی ہے، تو بعد میں ہونے والے لین دین سے کلید کی صداقت کی رجسٹری کی کلید سے موازنہ کر کے آسانی سے تصدیق/تردید کی جا سکتی ہے۔ دوسرے لفظوں میں، رجسٹری کی کلید بطور حوالہ نمونہ استعمال ہوتی ہے۔ دیگر تمام مالک کے لین دین پر اسی طرح کارروائی کی جاتی ہے۔
لین دین ایک الیکٹرانک ڈیجیٹل دستخط سے تصدیق شدہ ہے - یہ وہ جگہ ہے جہاں خفیہ کلیدوں کی ضرورت ہوتی ہے، اور ایک نہیں، بلکہ ایک ساتھ دو - ایک سروس کی اور ایک بٹوے کی چابی۔ دو خفیہ کلیدوں کے استعمال کی بدولت، سیکیورٹی کی ضروری سطح کو یقینی بنایا جاتا ہے - سب کے بعد، سروس کی خفیہ کلید دوسرے صارفین کو معلوم ہوسکتی ہے، جبکہ بٹوے کی خفیہ کلید صرف عام چابی کے جوڑے کے مالک کو معلوم ہوتی ہے۔ ہم نے اس طرح کے دو کلیدی دستخط کو "متحدہ" ڈیجیٹل دستخط کہا۔
غیر صفر لین دین کی تصدیق دو عوامی کلیدوں کا استعمال کرتے ہوئے کی جاتی ہے: والیٹ اور سروس کلید۔ تصدیق کے عمل کو دو اہم مراحل میں تقسیم کیا جا سکتا ہے: پہلا بٹوے کی عوامی کلید کے ڈائجسٹ کی جانچ پڑتال کر رہا ہے، اور دوسرا لین دین کے الیکٹرانک ڈیجیٹل دستخط کی جانچ کر رہا ہے، وہی مضبوط جو دو خفیہ کلیدوں کا استعمال کرتے ہوئے تشکیل دیا گیا تھا ( پرس اور خدمت)۔ اگر ڈیجیٹل دستخط کی درستگی کی تصدیق ہو جاتی ہے، تو اضافی تصدیق کے بعد لین دین کو رجسٹر میں داخل کیا جاتا ہے۔
ایک منطقی سوال پیدا ہو سکتا ہے: یہ کیسے چیک کیا جائے کہ آیا کوئی لین دین صفر ٹرانزیکشن کی صورت میں "روٹ" کے ساتھ کسی مخصوص سلسلہ سے تعلق رکھتا ہے؟ اس مقصد کے لیے توثیق کے عمل کو ایک اور مرحلے یعنی کنیکٹیویٹی چیکنگ کے ساتھ پورا کیا جاتا ہے۔ یہ وہ جگہ ہے جہاں ہمیں پہلے دو فیلڈز کے ڈیٹا کی ضرورت ہوگی، جسے ہم نے اب تک نظر انداز کیا ہے۔
آئیے تصور کریں کہ ہمیں یہ چیک کرنے کی ضرورت ہے کہ آیا ٹرانزیکشن نمبر 3 درحقیقت ٹرانزیکشن نمبر 2 کے بعد آتا ہے۔ ایسا کرنے کے لیے، مشترکہ ہیشنگ کا طریقہ استعمال کرتے ہوئے، ہیش فنکشن ویلیو کو ٹرانزیکشن نمبر 2 کے تیسرے، چوتھے اور پانچویں فیلڈ کے ڈیٹا کے لیے شمار کیا جاتا ہے۔ اس کے بعد ٹرانزیکشن نمبر 3 کے پہلے فیلڈ سے ڈیٹا اور ٹرانزیکشن نمبر 2 کے تیسرے، چوتھے اور پانچویں فیلڈ کے ڈیٹا کے لیے پہلے سے حاصل کی گئی مشترکہ ہیش فنکشن ویلیو کو جوڑ دیا جاتا ہے۔ یہ سب دو ہیش فنکشنز SHA256 اور RIPEMD160 کے ذریعے بھی چلایا جاتا ہے۔ اگر موصول ہونے والی قیمت ٹرانزیکشن نمبر 2 کے دوسرے فیلڈ میں موجود ڈیٹا سے ملتی ہے، تو چیک پاس ہو جاتا ہے اور کنکشن کی تصدیق ہو جاتی ہے۔ یہ ذیل کے اعداد و شمار میں زیادہ واضح طور پر دکھایا گیا ہے۔
عام اصطلاحات میں، رجسٹر میں نوٹیفکیشن بنانے اور داخل کرنے کی ٹیکنالوجی بالکل اس طرح نظر آتی ہے۔ اطلاعات کی ایک زنجیر بنانے کے عمل کی ایک بصری مثال درج ذیل تصویر میں پیش کی گئی ہے۔
اس متن میں، ہم ان تفصیلات پر غور نہیں کریں گے، جو بلاشبہ موجود ہیں، اور ایک وکندریقرت عوامی کلیدی بنیادی ڈھانچے کے بالکل خیال پر بات کرنے پر واپس آئیں گے۔
لہذا، چونکہ درخواست دہندہ خود نوٹیفیکیشن کے اندراج کے لیے درخواست جمع کرتا ہے، جو CA ڈیٹا بیس میں نہیں، بلکہ رجسٹری میں محفوظ ہے، اس لیے DPKI کے اہم تعمیراتی اجزاء پر غور کیا جانا چاہیے:
1. درست اطلاعات کا رجسٹر (RDN)۔
2. منسوخ شدہ اطلاعات کا رجسٹر (RON)۔
3. معطل شدہ اطلاعات کا رجسٹر (RPN)۔
پبلک کیز کے بارے میں معلومات RDN/RON/RPN میں ہیش فنکشن ویلیوز کی شکل میں محفوظ کی جاتی ہیں۔ یہ بات بھی قابل توجہ ہے کہ یہ یا تو مختلف رجسٹریاں ہو سکتی ہیں، یا مختلف زنجیریں، یا ایک ہی رجسٹری کے حصے کے طور پر ایک سلسلہ بھی ہو سکتا ہے، جب ایک عام عوامی کلید (منسوخی، معطلی، وغیرہ) کی حیثیت کے بارے میں معلومات درج کی جاتی ہیں۔ متعلقہ کوڈ ویلیو کی شکل میں ڈیٹا سٹرکچر کا چوتھا فیلڈ۔ DPKI کے آرکیٹیکچرل نفاذ کے لیے بہت سے مختلف آپشنز ہیں، اور ایک یا دوسرے کا انتخاب کئی عوامل پر منحصر ہے، مثال کے طور پر، عوامی کیز کو ذخیرہ کرنے کے لیے طویل مدتی میموری کی لاگت کے طور پر اصلاح کا معیار وغیرہ۔
اس طرح، DPKI، اگر آسان نہیں، تو کم از کم تعمیراتی پیچیدگی کے لحاظ سے ایک مرکزی حل سے موازنہ کرنے کے قابل ہو سکتا ہے۔
اہم سوال باقی ہے - ٹیکنالوجی کو لاگو کرنے کے لیے کون سی رجسٹری موزوں ہے؟
رجسٹری کے لیے بنیادی ضرورت کسی بھی قسم کے لین دین کو پیدا کرنے کی صلاحیت ہے۔ لیجر کی سب سے مشہور مثال بٹ کوائن نیٹ ورک ہے۔ لیکن اوپر بیان کی گئی ٹیکنالوجی کو لاگو کرتے وقت، کچھ مشکلات پیدا ہوتی ہیں: موجودہ اسکرپٹنگ لینگویج کی حدود، ڈیٹا کے صوابدیدی سیٹوں کو پروسیس کرنے کے لیے ضروری میکانزم کی کمی، صوابدیدی قسم کے لین دین کو پیدا کرنے کے طریقے، اور بہت کچھ۔
ہم نے ENCRY میں مذکورہ مسائل کو حل کرنے کی کوشش کی اور ایک رجسٹری تیار کی، جس کے، ہماری رائے میں، بہت سے فوائد ہیں، یعنی:
- متعدد قسم کے لین دین کی حمایت کرتا ہے: یہ دونوں اثاثوں کا تبادلہ کر سکتا ہے (یعنی مالی لین دین کر سکتا ہے) اور من مانی ڈھانچے کے ساتھ لین دین کر سکتا ہے،
- ڈویلپرز کی ملکیتی پروگرامنگ زبان PrismLang تک رسائی ہوتی ہے، جو مختلف تکنیکی مسائل کو حل کرتے وقت ضروری لچک فراہم کرتی ہے،
- صوابدیدی ڈیٹا سیٹ پر کارروائی کرنے کا طریقہ کار فراہم کیا گیا ہے۔
اگر ہم ایک آسان طریقہ اختیار کرتے ہیں، تو عمل کی مندرجہ ذیل ترتیب ہوتی ہے:
- درخواست دہندہ DPKI کے ساتھ رجسٹر ہوتا ہے اور ایک ڈیجیٹل والیٹ وصول کرتا ہے۔ والیٹ ایڈریس والیٹ کی عوامی کلید کی ہیش ویلیو ہے۔ پرس کی پرائیویٹ کلید صرف درخواست گزار کو معلوم ہوتی ہے۔
- رجسٹرڈ مضمون کو سروس کی خفیہ کلید تک رسائی دی جاتی ہے۔
- موضوع صفر ٹرانزیکشن تیار کرتا ہے اور بٹوے کی خفیہ کلید کا استعمال کرتے ہوئے ڈیجیٹل دستخط کے ساتھ اس کی تصدیق کرتا ہے۔
- اگر صفر کے علاوہ کوئی لین دین بنتا ہے، تو اسے دو خفیہ کلیدوں کا استعمال کرتے ہوئے الیکٹرانک ڈیجیٹل دستخط سے تصدیق کی جاتی ہے: ایک پرس اور ایک سروس۔
- موضوع پول میں لین دین جمع کراتا ہے۔
- ENCRY نیٹ ورک نوڈ پول سے لین دین کو پڑھتا ہے اور ڈیجیٹل دستخط کے ساتھ ساتھ لین دین کے کنیکٹیویٹی کو بھی چیک کرتا ہے۔
- اگر ڈیجیٹل دستخط درست ہے اور کنکشن کی تصدیق ہو جاتی ہے، تو یہ لین دین کو رجسٹر میں داخل کرنے کے لیے تیار کرتا ہے۔
یہاں رجسٹری ایک تقسیم شدہ ڈیٹا بیس کے طور پر کام کرتی ہے جو درست، منسوخ شدہ اور معطل شدہ اطلاعات کے بارے میں معلومات کو ذخیرہ کرتی ہے۔
بلاشبہ، وکندریقرت کوئی علاج نہیں ہے۔ بنیادی صارف کی توثیق کا بنیادی مسئلہ کہیں بھی غائب نہیں ہوتا: اگر فی الحال درخواست گزار کی تصدیق CR کے ذریعے کی جاتی ہے، تو DPKI میں یہ تجویز ہے کہ تصدیق کو کمیونٹی کے اراکین کو سونپے، اور سرگرمی کو تیز کرنے کے لیے مالی محرکات کا استعمال کرے۔ اوپن سورس کی توثیق ٹیکنالوجی اچھی طرح سے جانا جاتا ہے. عملی طور پر اس طرح کی تصدیق کی تاثیر کی تصدیق کی گئی ہے۔ آئیے ایک بار پھر آن لائن پبلیکیشن بیلنگ کیٹ کی کئی ہائی پروفائل تحقیقات کو یاد کرتے ہیں۔
لیکن عام طور پر، مندرجہ ذیل تصویر ابھرتی ہے: DPKI درست کرنے کا ایک موقع ہے، اگر تمام نہیں، تو مرکزی PKI کی بہت سی خامیاں۔
ہمارے Habrablog کو سبسکرائب کریں، ہم اپنی تحقیق اور ترقی کو فعال طور پر کور کرنے اور اس کی پیروی کرنے کا ارادہ رکھتے ہیں۔ ، اگر آپ ENCRY منصوبوں کے بارے میں دوسری خبروں سے محروم نہیں رہنا چاہتے ہیں۔
ماخذ: www.habr.com