الخلاصة

  • يضع كل من RFC 2403 وRFC 2404 أول 96 بتاً من HMAC محسوب في ESP أو AH، رغم اختلاف طول الناتج الكامل وطول المفتاح المطلوب.
  • فصلت الإرشادات اللاحقة بين الخوارزميتين: يسجل RFC 8221 ‏HMAC-MD5-96 بصفة MUST NOT وHMAC-SHA1-96 بصفة MUST-. لم يكن ثبات طول الوسم دليلاً على تطابق التقييم الأمني.

حقل واحد وبنيتان مختلفتان

في نوفمبر 1998، حدد RFC 2403 وRFC 2404 تحويلي مصادقة بمفتاح سري لبروتوكولي IPsec: حمولة الأمان المغلّفة (ESP) وترويسة المصادقة (AH). ربط الأول HMAC بدالة MD5، وربط الثاني HMAC بدالة SHA-1. وكان الغرض من كليهما التحقق من مصدر البيانات وسلامتها عندما يقتصر المفتاح السري على الأطراف المتواصلة. ولم يوفر أي منهما السرية بمفرده.

على مستوى الحزمة بدا الرقم واحداً: 96 بتاً. يبلغ ناتج HMAC-MD5 الكامل في RFC 2403 مقدار 128 بتاً، بينما يبلغ ناتج HMAC-SHA-1 الكامل في RFC 2404 مقدار 160 بتاً. وفي كلا التحويلين يضع المرسل أول 96 بتاً في حقل المصادقة، ثم يحسب المستقبل HMAC كاملاً ويقارن أول 96 بتاً منه. وافق هذا الاختيار الطول الافتراضي لوسم AH، ومنح البنيتين المختلفتين شكلاً مشتركاً على السلك. لكنه لم يحوّل أي ناتج تجزئة كامل إلى تجزئة طولها 96 بتاً.

اختلفت قواعد المفاتيح أيضاً: يشترط RFC 2403 مفتاح HMAC بطول 128 بتاً، ويشترط RFC 2404 مفتاحاً بطول 160 بتاً. وهكذا اجتمع حقل ثابت الطول مع ناتجين كاملين ومفتاحين ثابتَي الطول مختلفين. وظل تحديد التحويل المتفاوض عليه والتعامل الصحيح مع المفتاح أمراً مهماً؛ فعدّ بتات الوسم الظاهرة وحده لا يصف آلية الأمان كاملة.

مقاومة التصادم ليست كل مسألة HMAC

لم تساوِ وثيقتا 1998 بين التصادم في دالة تجزئة غير مفتاحية وبين كسر فوري لـHMAC ذي المفتاح السري. ذكر RFC 2403 أن اعتماد HMAC على مقاومة التصادم القوية أقل مما هو عليه في التواقيع المبنية على MD5، ولم يسجل آنذاك هجوماً عملياً على HMAC-MD5-96. وقدّم RFC 2404 تقييماً مماثلاً لـHMAC-SHA-1-96 وفق معرفة تلك الفترة. كان ذلك تحليلاً مؤرخاً، لا ضماناً للاستخدام مستقبلاً.

تُظهر إرشادات التنفيذ كيف تغير التقييم من دون أن يصبح طول الوسم العامل الحاسم. ففي 2005 جعل RFC 4305 استخدام HMAC-SHA1-96 إلزامياً، وHMAC-MD5-96 اختيارياً. وأبقى RFC 4835 في 2007 على هذا التفريق، مشيراً إلى أن نقاط ضعف التصادم المعروفة حينها لا ينبغي أن تؤثر في أي من دالتي التجزئة عند استعمالهما مع HMAC. وفي 2014 أقر RFC 7321 بنتائج نظرية ضد HMAC-MD5، لكنه قال إنه لا توجد ثغرة عملية ظاهرة وإن إزالة التحويل من البروتوكولات القائمة ليست ملحّة؛ كما واصل اعتبار HMAC-SHA-1 آمناً رغم ضعف مقاومة التصادم في SHA-1.

رسم RFC 8221، المنشور في 2017، خطاً أوضح لمتطلبات تنفيذ ESP وAH: أصبح HMAC-MD5-96 محظوراً (MUST NOT)، وتراجع HMAC-SHA1-96 من إلزامي إلى موصى به بقوة مع استثناءات (MUST-). واستند الحظر إلى ثغرة التصادم المعروفة في MD5، بينما عزا خفض توصية SHA-1 إلى توجه أوسع في القطاع نحو التخلص من استخدامها. ولم يكن ذلك ادعاءً بأن حقل الـ96 بتاً قد تغير أو بأن RFC 2404 بات يحدد وسماً مختلفاً.

جدول الحالة ليس سجل حركة مرور

حدّث RFC 9395 لاحقاً RFC 8221 وعدّل سجل تحويلات IKEv2، ومن ذلك إدراج AUTH_HMAC_MD5_96 بحالة DEPRECATED. لكن هذا السجل ليس هو جدول متطلبات تنفيذ ESP وAH في RFC 8221. فالاسم المتشابه يظهر في سياقين متجاورين من IPsec؛ لذلك ينبغي قراءة تسمية السجل مقرونة بالبروتوكول ونطاق الوثيقة.

تسجل هذه الوثائق معاملات البروتوكول وتوصيات التنفيذ في تواريخ محددة. لكنها لا تحصي الأجهزة المنشورة، ولا تحدد آخر ارتباط أمني جرى التفاوض عليه باستخدام HMAC-MD5، ولا تثبت موعداً موحداً لإنهاء الاستخدام. يحتاج المشغّل إلى تمييز البروتوكول المحدد، ومعرّف التحويل، وقدرات الطرف المقابل، والارتباط الأمني المثبّت، وحركة المرور المرصودة. وسم بطول 96 بتاً ليس سوى جزء من تلك الأدلة.

المصادر