يظل سجل العميل المشفر والمحفوظ في نسخة احتياطية طويلة الأمد غير قابل للقراءة اليوم، حتى لو قام مهاجم بنسخ تلك النسخة من وحدة تخزين الكائنات (object storage) قبل سنوات؛ إذ لم يكن المهاجم بحاجة إلى الوصول لقاعدة البيانات أو التطبيق أو مفتاح التشفير. وإذا كان مفتاح تشفير بيانات النسخة الاحتياطية قد أُنشئ أو حُمي باستخدام خوارزميات RSA أو تشفير المنحنى الإهليلجي (ECC)، فقد يتمكن حاسوب كمي ذو قدرات تحليل تشفيري (CRQC) في المستقبل من استعادة ذلك المفتاح وكشف البيانات المحفوظة. لذا، فإن السؤال الذي يواجه المدافع ليس “متى سيتم اختراق نقطة النهاية؟”، بل “هل ستظل البيانات المشفرة اليوم بحاجة إلى السرية بعد أن يصبح التحليل التشفيري القائم على الحوسبة الكمية أمراً ممكناً؟”.
تنطبق المشكلة ذاتها على حركة مرور بيانات بروتوكول TLS التي يتم اعتراضها أو التقاطها من مسار الشبكة. فبينما يمكن لجلسة محمية بآليات إنشاء المفاتيح التقليدية (القائمة على المفتاح العام) الحفاظ على سرية معرف العميل (customer_id=48291) أثناء تشغيل الجلسة، إلا أن البيانات الملتقطة والمحفوظة قد تصبح قابلة لفك التشفير لاحقاً إذا سقطت حماية المفتاح العام أمام هجوم كمي. يُعرف هذا النمط بـ “الجمع الآن وفك التشفير لاحقاً” (Harvest Now, Decrypt Later)، أي جمع البيانات المحمية حالياً لفك تشفيرها عندما تتوفر قدرات حوسبة أقوى. وتعتمد خطورة هذا الأمر على المدة الزمنية التي تتطلبها سرية البيانات، وليس فقط على التاريخ المتوقع لظهور الحاسوب الكمي.
يوم Q (Q-Day)
يُقصد بـ يوم Q (Q-Day) تلك اللحظة التي يتمكن فيها حاسوب كمي ذو قدرات تحليل تشفيري (CRQC) عملياً من تقويض افتراضات التشفير بالمفتاح العام التي لا يزال النظام يعتمد عليها. وبالنسبة لمالك النظام، يمثل “يوم Q” معياراً للتخطيط وليس مجرد توقع لتاريخ تقويمي محدد. وتشير المعهد الوطني للمعايير والتقنية (NIST) إلى أن التقديرات المتعلقة بظهور حاسوب CRQC تتفاوت بشكل كبير، في حين أن عمليات الانتقال إلى أنظمة تشفير جديدة تستغرق تاريخياً سنوات لدمجها وتطبيقها عبر المنتجات والخدمات والبنية التحتية.
يتناول هذا المقرر الدراسي التهديد المذكور بتركيز ودقة محددين. تُشكّل خوارزمية “شور” (Shor’s algorithm) تهديداً لعمليات المفتاح العام القائمة على خوارزميتي RSA والمنحنى الإهليلجي (Elliptic-curve)، والمستخدمة في تأسيس المفاتيح والتوقيعات الرقمية. ومع ذلك، لا يعني هذا أن كل بايت مُشفَّر يصبح ضعيفاً بنفس الدرجة؛ إذ تظل عوامل مثل التشفير المتماثل، ودوال التجزئة (hashes)، وتخزين المفاتيح، وإعدادات البروتوكول، ودورة حياة الشهادة، وسياسات الاحتفاظ بالبيانات هي التي تحدد ما إذا كان الاعتماد على مفتاح عام -معرَّض لمخاطر الحوسبة الكمومية- يُعرِّض أصلاً فعلياً للخطر.
نظراً لأن النسخ الاحتياطي وعمليات التقاط بيانات بروتوكول TLS يمثلان مسارين مختلفين للوصول إلى النظام نفسه، تبدأ عملية الانتقال بتحديد كافة المواقع التي تُرسِّخ فيها تقنيات التشفير بالمفتاح العام مبدأ الثقة. ففي الخدمة النموذجية، يتصل المتصفح بواجهة أمامية للويب، وتستدعي هذه الواجهة واجهة برمجة تطبيقات (API)، التي تقوم بدورها بقراءة قاعدة بيانات. كما تتضمن البنية التحتية للنظام تخزين النسخ الاحتياطية، وصلاحيات الوصول الإداري، وتوقيع حزم البناء (build signing)، وسجلات الأحداث، وعمليات التكامل الخارجي. لذا، يجب أن يتضمن سجل جرد التشفير تفاصيل البروتوكول، والخوارزمية، والمكتبة البرمجية، والشهادة، ومالك المفتاح، وفترة بقاء البيانات المرتبطة بكل مسار.
يستخدم بروتوكول TLS عادةً خوارزميتي RSA أو ECC للمصادقة، وكذلك لتأسيس المفاتيح (اعتماداً على إعدادات البروتوكول المُطبَّقة). ويمكن لمفاتيح توقيع رموز JWT استخدام توقيعات RSA أو المنحنى الإهليلجي لتمكين واجهة برمجة التطبيقات (API) من التحقق من مصدر الرمز المميز (token) وسلامته. وتُستخدم شهادات توقيع الكود (code-signing certificates) للتحقق مما إذا كان ملف الإصدار البرمجي صادراً عن ناشر مُصرَّح له، بينما تُستخدم مفاتيح مضيف SSH لمصادقة الخادم الذي يتصل به المسؤولون. ونظراً لأن هذه الضوابط تخدم أهدافاً أمنية مختلفة، فإن استبدالها لا يقتصر على مجرد تغيير خوارزمية بأخرى بشكل موحد.
تفصل البنية الموضحة أدناه بين نقاط التفاعل التي تعتمد على المفتاح العام وآليات الحماية المتماثلة، وهو تمييز جوهري يجب أن يحافظ عليه سجل الجرد:
يوضح هذا الرسم البياني كيف يمكن لقاعدة بيانات مُشفَّرة باستخدام مفتاح بيانات متناظر (symmetric key) أن تظل عرضة للمخاطر الكمومية عبر آلية المفتاح العام التي تُنشئ ذلك المفتاح أو تنقله أو تحميه. كما يكشف الرسم عن تبعيات (dependencies) يسهل إغفالها، ولا سيما عمليات التوقيع في مسارات التكامل والنشر المستمرين (CI/CD) وإدارة الأنظمة عبر بروتوكول SSH، حيث تكون الخسارة الأساسية هنا هي فقدان الموثوقية (authenticity) وليس مجرد انكشاف السرية لاحقاً.
بمجرد أن تحدد البنية التقنية كل تبعية، فإن المخرج المطلوب هو قرار انتقال قابل للتبرير والتدعيم، وليس مجرد ادعاء عام بأن النظام “جاهز للعصر الكمومي”. يجب علينا تحديد اللبنات التشفيرية (primitives) التي تهددها خوارزمية “شور” (Shor)، والتمييز بين عمليات إنشاء المفاتيح وعمليات التوقيع، وربط كل لبنة تشفيرية معرضة للخطر بالأصل (asset) وحدود الثقة (trust boundary) التي تحميها. وقد اعتمد المعهد الوطني للمعايير والتقنية (NIST) ثلاث خوارزميات أساسية للتشفير المقاوم للحوسبة الكمومية (PQC) في أغسطس 2024، وهي: FIPS 203 ML-KEM لإنشاء المفاتيح، وFIPS 204 ML-DSA للتوقيعات الرقمية، وFIPS 205 SLH-DSA للتوقيعات القائمة على التجزئة (hash-based) وغير المعتمدة على الحالة (stateless).
ستعمل الدروس اللاحقة على بناء أربع قدرات عملية:
المرونة التشفيرية (Crypto agility) هي القدرة على استبدال الخوارزميات التشفيرية والمفاتيح والتبعيات المرتبطة بها دون التسبب في اضطراب غير مقبول أو فقدان للقدرة على التشغيل البيني (interoperability). إنها سمة من سمات النظام المحيط - بما في ذلك الإعدادات، ومعالجة الشهادات، ودعم الموردين، والتفاوض على البروتوكولات - وليست مجرد خاصية توفرها الخوارزمية وحدها.
ما هي نقاط التفاعل (touchpoints) التي تنطوي على خطر فقدان السرية مستقبلاً فيما يتعلق بالبيانات المحفوظة، وأيها يشكل خطراً رئيسياً يتمثل في تزوير الهوية أو المساس بسلامة البيانات (integrity) بعد حلول “اليوم الكمومي” (Q-Day)؟ تفصل المقارنة بين تلك القرارات.