بحال کیے گئے بیک اپ میں user-1842 کے لیے ایک انکرپٹڈ JSON ریکارڈ موجود ہوتا ہے، لیکن جب حملہ آور ذخیرہ شدہ بائٹس (bytes) کو تبدیل کر دیتا ہے اور بحال شدہ role (کردار) ‘admin’ بن جاتا ہے، تب بھی ایپلی کیشن اسے قبول کر لیتی ہے۔ حملہ آور کو انکرپشن کی یا API تک رسائی کی ضرورت نہیں تھی۔ انہیں صرف ڈیٹا بیس بیک اپ یا اس کے میٹا ڈیٹا میں ‘لکھنے کی رسائی’ (write access) درکار تھی۔ ہمارا زیرِ استعمال آرٹیفیکٹ (artifact) ایک پائتھن ماڈیول ہے جو اس ریکارڈ کی حفاظت کرتا ہے—جس میں id، email، role اور created_at شامل ہیں—جبکہ یہ کلائنٹ، API، ڈیٹا بیس اور بیک اپ کے درمیان منتقل ہوتا ہے۔ سیمیٹرک انکرپشن (Symmetric encryption) اسی خفیہ کلید (secret key) کا استعمال کرتی ہے تاکہ پلین ٹیکسٹ (plaintext) کو سائفر ٹیکسٹ (ciphertext) میں تبدیل کیا جا سکے اور بعد میں پلین ٹیکسٹ کو دوبارہ حاصل کیا جا سکے۔ یہ ریکارڈ کو چھپاتی ہے، لیکن محض چھپانے سے تبدیل شدہ بائٹس قابلِ اعتماد نہیں بن جاتے۔
لہٰذا، دفاع کرنے والے کا سوال اس بات سے کہیں زیادہ مخصوص ہے کہ کس سائفر کا نام سب سے زیادہ مضبوط ہے۔ جب اسٹوریج سے role=admin واپس آتا ہے، تو API یہ کیسے ثابت کر سکتا ہے کہ وہ بائٹس اور ان کے ریکارڈ کا سیاق و سباق (context) بالکل وہی ہیں جو اصل میں محفوظ کیے گئے تھے؟ user-1842 کے لیے حدود یہ ظاہر کرتی ہیں کہ پلین ٹیکسٹ کہاں ختم ہونا چاہیے، کلید کہاں الگ رہنی چاہیے، اور حملہ آور کہاں سائفر ٹیکسٹ کے مندرجات کو جانے بغیر اس میں تبدیلی کر سکتا ہے۔ آئیے ان حدود کے آر پار اس ریکارڈ کا سراغ لگاتے ہیں:
یہ خاکہ ظاہر کرتا ہے کہ ڈیٹا بیس اور بیک اپ کو سائفر ٹیکسٹ (ciphertext)، ایک نونس (nonce)، اور منتخب میٹا ڈیٹا کی ضرورت ہوتی ہے، لیکن انکرپشن کی (encryption key) کی نہیں۔ نونس ایک ایسی قدر (value) ہے جسے کسی مخصوص کی (key) کے ساتھ صرف ایک بار استعمال کیا جاتا ہے تاکہ اس بات کو یقینی بنایا جا سکے کہ تحفظ کے بار بار ہونے والے عمل میں وہی کریپٹوگرافک ان پٹس دوبارہ استعمال نہ ہوں۔ نونس کو سائفر ٹیکسٹ کے ساتھ محفوظ کیا جا سکتا ہے؛ رازداری برقرار رکھنا اس کا کام نہیں ہے۔ کی (key) کو خفیہ رہنا چاہیے اور اسے ریکارڈ یا بیک اپ کے بجائے محفوظ ایپلیکیشن کنفیگریشن سے حاصل کیا جانا چاہیے۔
چونکہ حملہ آور محفوظ شدہ بائٹس (bytes) میں تبدیلی کر سکتا ہے، اس لیے ریکارڈ کے معاہدے میں رازداری اور سالمیت (integrity) دونوں کی ضرورت ہوتی ہے۔ مصدقہ انکرپشن (Authenticated encryption) JSON بائٹس کو انکرپٹ کرتی ہے اور اس بات کی تصدیق کرتی ہے کہ پلین ٹیکسٹ (plaintext) واپس کرنے سے پہلے نہ تو ان بائٹس میں اور نہ ہی منتخب سیاق و سباق (context) میں کوئی تبدیلی ہوئی ہے۔ user-1842 کے لیے، API user_id=user-1842 اور schema_version=1 کی بطور وابستہ ڈیٹا (associated data) تصدیق کرے گا؛ یعنی ایسا میٹا ڈیٹا جس کی تصدیق کریپٹوگرافک عمل کے ذریعے تو کی جاتی ہے لیکن اسے انکرپٹ نہیں کیا جاتا۔ اس کے بعد، کاپی کیے گئے سائفر ٹیکسٹ کو خاموشی سے کسی دوسرے صارف کے ریکارڈ کے طور پر دوبارہ لیبل نہیں کیا جا سکتا، اور تصدیق کے عمل کو ناکام بنائے بغیر اسکیمہ کی قدر (schema value) کو تبدیل نہیں کیا جا سکتا۔
پلین ٹیکسٹ ای میل اور کردار (role) کو براہِ راست ظاہر کر دیتا ہے۔ AES-CTR اور AES-CBC ان فیلڈز کو چھپا تو سکتے ہیں، لیکن ان میں سے کوئی بھی آزادانہ طور پر تبدیلی کو مسترد نہیں کرتا۔ AES-GCM مطلوبہ مصدقہ انکرپشن کا معاہدہ فراہم کرتا ہے بشرطیکہ اسے ایک ہی کی (key) کے تحت ہر انکرپشن کے لیے ایک نئے نونس کے ساتھ استعمال کیا جائے۔ کیا صرف انکرپشن والا موڈ (encryption-only mode) اس بات کا پتہ لگا سکتا ہے کہ API کے role کو پارس (parse) کرنے سے پہلے بیک اپ کے کسی بائٹ میں تبدیلی ہوئی ہے؟ درج ذیل موازنہ اس ضرورت کے پیشِ نظر اسٹوریج کے مختلف طریقوں کا جائزہ لیتا ہے:
یہ موازنہ ڈیزائن کے فیصلے کو حتمی شکل دیتا ہے۔ AES-GCM ترمیم شدہ سائفر ٹیکسٹ (ciphertext)، نونس (nonce)، کلید (key)، یا متعلقہ ڈیٹا کو تصدیق کی ناکامی (authentication failure) کے ساتھ مسترد کر دیتا ہے، جبکہ صرف رازداری (confidentiality-only) پر مبنی انتخاب ایپلی کیشن کو اس ثبوت سے محروم رکھتے ہیں۔ AES-GCM نونس کے دوبارہ استعمال (nonce reuse) کے مسئلے کو خود ٹھیک نہیں کرتا۔ ایک ہی کلید کے ساتھ ایک ہی نونس کا دوبارہ استعمال سیکیورٹی کو خطرے میں ڈالتا ہے، لہذا نونس کی تخلیق کا عمل ‘تحفظ کے عمل’ (protection path) کے اندر ہونا چاہیے نہ کہ اسے کال کرنے والے (caller) کی طرف سے فراہم کردہ میٹا ڈیٹا کے طور پر لیا جائے۔
ریکارڈ کا اصول نونس، سائفر ٹیکسٹ اور متعلقہ ڈیٹا کو ریکارڈ کے ساتھ محفوظ کریں۔ AES کلید کو الگ سے محفوظ کریں اور ہر کلید کے لیے ہر نونس کو منفرد رکھیں۔
معاہدے (contract) کے طے ہو جانے کے بعد، یہ ماڈیول user-1842 کو تحفظ فراہم کر سکتا ہے بغیر اس کے کہ جزوی طور پر تصدیق شدہ ریکارڈ کال کرنے والے (caller) کے سامنے ظاہر ہو۔ JSON سیریلائزر بائٹس (bytes) تیار کرتا ہے کیونکہ AESGCM.encrypt بائٹس پر کام کرتا ہے۔ یہ ماڈیول مثال کے لیے 256-بٹ کی AES کلید تیار کرتا ہے، 12-بائٹ کا نیا نونس بناتا ہے، اور {nonce, ciphertext, ad} کی شکل میں ایک پیکیج محفوظ کرتا ہے۔ ڈیپلائمنٹ (نفاذ) کے دوران، کلید کی تخلیق اور تحویل کا عمل ایپلی کیشن کی منظور شدہ ‘کلید کے انتظام کی حدود’ (key-management boundary) میں منتقل ہو جاتا ہے، جبکہ ریکارڈ پیکیج ڈیٹا بیس اور بیک اپ میں محفوظ کرنے کے لیے محفوظ رہتا ہے۔
یہاں تحفظ اور بحالی کا مختصر ترین مکمل عمل (path) دیا گیا ہے: