Cloudflare و IETF يمنعان هجمات التخفيض الكمي في IPsec

أعلنت Cloudflare خلال Birthday Week أنها طورت، بالتعاون مع IETF، آلية لمكافحة هجوم التخفيض الكمي على بروتوكول IPsec. وقد فعّلتها الشركة بالفعل في وضع تجريبي داخل منتجات IPsec الخاصة بها.

تنتقل الصناعة إلى التشفير ما بعد الكمي (PQ): إذ يُستبدل تبادل مفاتيح Diffie-Hellman ب ML-KEM، بينما تُستبدل مخططات التوقيع الكلاسيكية ECDSA وRSA ب ML-DSA. وإلى أن يتم تحديث كل الأجهزة، يجب أن تحافظ على دعم التشفير الكلاسيكي.

هذا التوافق تحديدًا هو ما يستغله هجوم التخفيض: فالمهاجم الموجود في الشبكة يعدّل الرسائل المتبادلة بين العميل والخادم ويقنع الطرفين بأن نظيرهما لا يدعم التشفير ما بعد الكمي إطلاقًا. وهكذا يعود الاتصال إلى الخوارزميات الكلاسيكية ويصبح متاحًا للحاسوب الكمي.

خلل في تصميم IPsec

لذلك لا يكفي مجرد إضافة خوارزميات ما بعد كمية. فـ IPsec، مثل TLS، عرضة لهجوم التخفيض، لكن Cloudflare اكتشفت أيضًا نسخة أكثر تعقيدًا تعمل بصرف النظر عن طريقة المصادقة. في بروتوكول IKEv2، يوقّع كل طرف على رسالته الصادرة فقط، وليس على الحوار البروتوكولي كاملًا كما في TLS 1.3. وبسبب ذلك يستطيع المهاجم أن يرسم لكل طرف صورة مختلفة، ويفك تشفير حركة المرور بين أجهزة تدعم التشفير ما بعد الكمي.

من الصعب عمليًا تنفيذ الهجوم، لأن الحوسبة الكمية يجب أن تتم في الوقت الفعلي قبل اكتمال الاتفاق. ويختلف ذلك عن هجمات من نوع «سجّل اليوم، وفكّ التشفير لاحقًا»، حيث تجري الحوسبة دون اتصال. ومع ذلك، قلّصت Cloudflare موعد الانتقال ما بعد الكمي إلى 2029.

مصادقة النص الكامل للجلسة

للحماية، طُوّر بالتعاون مع فريق العمل IPSECME التابع لـ IETF امتداد IKEv2 باسم IKE_SA_INIT_FULL_TRANSCRIPT_AUTH، يضيف إلى البروتوكول مصادقة الحوار الكامل. ويوقّع الطرفان على النص الكامل للتبادل ويتوقعان الشيء نفسه من الشريك.

يُعلَن دعم الامتداد أثناء أول تبادل عبر رسالة notify، وتُرسَل هذه الرسالة بلا شرط: فالمبادر يُعلِم دائمًا، والمستجيب يُعلِم أيضًا حتى لو لم يفعل الطرف الآخر ذلك. وإذا أسقط المهاجم إحدى الرسالتين، ينتقل الطرفان إلى منطقين مختلفين، فلا تتطابق التوقيعات وتفشل المصادقة برسالة AUTHENTICATION_FAILURE. أما إسقاط الرسالتين معًا فيتطلب من المهاجم أيضًا تزوير توقيع المستجيب إلى جانب توقيع المبادر، وهو أمر مستحيل عمليًا. وفي مفاوضات IKE، يؤدي Cloudflare دور المستجيب فقط.

كيف سيُفعَّل

الوظيفة مقيّدة لكل حساب مستخدم عبر feature flag. ويمكن للعملاء المهتمين أن يطلبوا من مدير الحساب تفعيل العلامة `ipsec_downgrade_protection`. وبعد اختبار تجريبي كافٍ، ستُفعّلها Cloudflare لجميع الحسابات. والدعم التجريبي متاح بالفعل لـ Cloudflare WAN وMagic Transit.

تتجه الوثيقة نحو نيل حالة RFC. ومن بين مؤلفيها المشاركين Valery Smyslov، الذي اقترح أيضًا طريقة لحماية الامتداد من التخفيض. هذا الخلل في IPsec معروف منذ 10 سنوات على الأقل، وترى Cloudflare أن أخطاء مشابهة قد تكون مخفية في بروتوكولات أخرى أيضًا.