Northwind Traders ہر اس کریپٹوگرافک استعمال کے لیے ایک انوینٹری ریکارڈ برقرار رکھتی ہے جو کاروباری حدود (business boundary) کا تحفظ کرتا ہے، اور ہر ریکارڈ کے لیے ایک مخصوص سسٹم مالک (system owner) مقرر ہوتا ہے جو اس کے منتقلی کے عمل (migration path) کا ذمہ دار ہوتا ہے۔ یہ ریکارڈ مشاہدہ شدہ پروٹوکول، الگورتھم، سرٹیفکیٹ، لائبریری اور ملکیت کے ثبوت کو قبول کرتا ہے، اور پھر سرٹیفکیٹس کی فہرست کے بجائے کوانٹم کے خطرے سے دوچار انحصار (quantum-vulnerable dependencies) کا ایک ایسا نقشہ فراہم کرتا ہے جس کی بنیاد پر فوری فیصلہ کیا جا سکے۔ اس میں بنیادی خطرہ “ابھی ڈیٹا اکٹھا کرو اور بعد میں ڈکرپٹ کرو” (harvest-now-decrypt-later) کی حکمت عملی ہے؛ یعنی صارفین، ادائیگیوں اور انتظامی امور سے متعلق وہ ٹریفک جو آج پبلک-کی کریپٹوگرافی (public-key cryptography) سے محفوظ ہے، اسے مستقبل میں کریپٹوانالٹک صلاحیت کے حامل کوانٹم کمپیوٹر کے ذریعے توڑا جا سکتا ہے۔
Northwind کے اہم ترین عملی راستے (critical paths) اعتماد کی کئی حدود (trust boundaries) کو عبور کرتے ہیں۔ عوامی اسٹور فرنٹ (Storefront) اور موبائل ایپ EdgeGW تک رسائی حاصل کرتے ہیں؛ EdgeGW باہمی TLS (mutual TLS) کے ذریعے Orders سسٹم کی تصدیق (authenticate) کرتا ہے؛ AuthN ان JWTs پر دستخط کرتا ہے جنہیں ایڈمن پورٹل اور APIs قبول کرتے ہیں؛ PayBridge ادائیگی فراہم کرنے والے (payment provider) سے رابطہ کرتا ہے؛ اور CI/CD سسٹم تعیناتی کے لیے تیار آرٹیفیکٹس (deployable artifacts) پر دستخط کرتا ہے۔ کارپوریٹ اور پبلک سرٹیفکیٹ اتھارٹیز اعتماد کی الگ الگ بنیادیں (trust roots) قائم کرتی ہیں۔ اگر کوئی آڈیٹر کسی ایک مقام (edge) پر RSA-2048 سرٹیفکیٹ دریافت کرتا ہے، تو وہ ابھی یہ بتانے سے قاصر ہوتا ہے کہ آیا یہی کریپٹوگرافک عنصر (primitive) سافٹ ویئر ریلیز پر دستخط کرنے، سروسز کی تصدیق کرنے، یا رسائی کے ٹوکنز (access tokens) کی توثیق کرنے کے لیے بھی استعمال ہوتا ہے یا نہیں۔
یہ آرکیٹیکچر اس مجموعے کی حدود (collection boundary) کو اس وقت نمایاں کر دیتا ہے جب ہم اس سے ریکارڈز منسوب (assign) کرتے ہیں:
یہ خاکہ ظاہر کرتا ہے کہ صرف سرٹیفکیٹ کی فہرست (inventory) کیوں ناکافی ہے: TLS، mTLS، JWT کی تصدیق، اور پیکیج کی تصدیق جیسے عمل ‘پبلک-کی کریپٹوگرافی’ (public-key cryptography) کو مختلف پروٹوکول کرداروں اور مختلف مالکان کے ساتھ منسلک کرتے ہیں۔
چونکہ ایک ہی RSA-2048 کی (key) مختلف کام انجام دے سکتی ہے، اس لیے Northwind کریپٹوگرافک استعمال کو ایک ایسے الگورتھم کے طور پر ریکارڈ کرتا ہے جو کسی ایک حد (boundary) پر کسی ایک مقصد کے لیے کام کر رہا ہو۔ TLS سرور سرٹیفکیٹ، ECDH کی ایکسچینج (key exchange)، اور JWT دستخط الگ الگ استعمال (uses) شمار ہوتے ہیں، چاہے وہ ایک ہی پروڈکٹ کے ذریعے فراہم کیے جا رہے ہوں۔ یہ تفریق اس لیے اہم ہے کیونکہ ‘ہائبرڈ کی اسٹیبلشمنٹ’ (hybrid key establishment) معاون TLS راستے میں رازداری کے خطرے (confidentiality exposure) کو کم کر سکتی ہے، جبکہ کوانٹم خطرے کے ماڈل کے تحت تبدیل نہ ہونے والے JWT دستخط کی جعل سازی ممکن رہتی ہے۔
ہر ریکارڈ میں وہ شواہد محفوظ کیے جاتے ہیں جو بعد میں تبدیلی (تبدیلی/متبادل) کا فیصلہ کرنے کے لیے درکار ہوتے ہیں:
مطلوبہ فیلڈز ‘دریافت’ (discovery) اور ‘فیصلہ سازی’ کے درمیان فرق کو واضح کرتی ہیں۔ سائفر سویٹ (cipher-suite) کا جائزہ ECDH کے خطرے (exposure) کی نشاندہی کرتا ہے، لیکن لائبریری کا ورژن اور تبدیلی کا راستہ (change path) یہ طے کرتے ہیں کہ آیا EdgeGW ہائبرڈ نفاذ (hybrid implementation) اپنا سکتا ہے یا نہیں۔ سائننگ ریکارڈ کے لیے تصدیق کنندہ (verifier) کے مقامات کی ضرورت ہوتی ہے کیونکہ ایڈمن پورٹل، API گیٹ وے اور ڈیپلائمنٹ ویریفائر کو تبدیل کیے بغیر سائنر (signer) کو تبدیل کرنے سے اعتماد مجروح ہوتا ہے۔ ذیل میں کیا جانے والا موازنہ ان گمشدہ تفصیلات کا جائزہ لیتا ہے جو اکثر درست انوینٹریز کو روڈ میپ بننے سے روکتی ہیں:
یہ جدول ظاہر کرتا ہے کہ الگورتھم کی دریافت ضروری تو ہے مگر کافی نہیں: ملکیت (ownership)، تصدیق کنندہ کی رسائی (verifier reach)، اور پروڈکٹ کا ورژن اس بات کا تعین کرتے ہیں کہ آیا کسی معیاری متبادل کو عملی طور پر نافذ کیا جا سکتا ہے یا نہیں۔
فیصلہ سازی کا اصول بغیر مقصد اور مالک کے ریکارڈ کا مطلب محض ایک ‘آرٹیفیکٹ’ (artifact) ہے، نہ کہ ایسی کریپٹوگرافک انحصار (cryptographic dependency) جسے منتقل (migrate) کیا جا سکے۔
اسکیما (schema) کے طے ہو جانے کے بعد، Northwind ان حدود (boundaries) سے شروعات کرتا ہے جہاں طویل عرصے تک حساس ڈیٹا موجود رہتا ہے یا سالمیت (integrity) کے اہم فیصلے نافذ کیے جاتے ہیں۔ client→EdgeGW بیرونی TLS کا احاطہ کرتا ہے؛ EdgeGW→Orders اندرونی mTLS کا احاطہ کرتا ہے؛ AuthN JWT سائننگ اور ہر تصدیق کنندہ (verifier) کا احاطہ کرتا ہے؛ PayBridge فریقِ ثالث (third-party) پر انحصار کو ظاہر کرتا ہے؛ اور CI/CD آرٹیفیکٹ سائننگ کا احاطہ کرتا ہے۔ انوینٹری میں ECDH کو AES سے الگ درج کیا جانا چاہیے کیونکہ AES تو مناسب رہ سکتا ہے، جبکہ ECDH کی ‘کلید کے قیام’ (key establishment) کے عمل کو تبدیلی یا ہائبرڈ منتقلی کی ضرورت پڑ سکتی ہے۔
کس اندراج (entry) کو سائنر (signer) کی منتقلی اور تقسیم شدہ تصدیق کنندگان کی انوینٹری، دونوں کی ضرورت ہے: AuthN JWT سائننگ ریکارڈ یا EdgeGW→Orders mTLS ریکارڈ؟
مکمل کی گئی انوینٹری Northwind کی آٹھ دریافتوں کے لیے شواہد پر مبنی ریکارڈز کا استعمال کرتی ہے اور نتائج کو RSA-2048، ECDH، اور ECDSA P-256 کے ایکسپوزر (exposure) کے لحاظ سے گروپس میں تقسیم کرتی ہے: