IKEv1 مقابل IKEv2: مصادقة المفتاح المشترك مسبقًا وما يختلف بينهما

بوابتان مهيأتان بالمفتاح المشترك مسبقًا نفسه تُكملان المصافحة، ولا يُظهر التقاط الحزم أي سر يعبر الشبكة. هذا هو الجزء الذي يتذكره الناس. الجزء المثير للاهتمام هو ما يحسبه كل إصدار فعليًا لإثبات معرفة السر، لأن IKEv1 وIKEv2 يبنيان ذلك الإثبات من مدخلات مختلفة ويكشفان معلومات مختلفة أثناء ذلك. اقرأ الأثرين جنبًا إلى جنب وستجد أن الفرق لم يعد شكليًا.

ما يجب أن يحققه الإثبات

يمنح ديفي-هيلمان الطرفين قيمة مشتركة يستطيع أي مراقب أيضًا حساب النصفين العلنيين منها. هذا وحده لا يثبت شيئًا عن الهوية: فالمهاجم الذي يكمل تبادل المفاتيح يملك القيمة المشتركة نفسها التي تملكها بوابتك. وخطوة المصادقة موجودة لربط ذلك التبادل بسر لا يملكه إلا الطرفان المقصودان، وبالهويات والمعاملات التي اتفقا عليها.

هذا الربط هو سبب تغطية التجزئة لما هو أكثر من المفتاح. فلو غطّت السر فقط، لأمكن للمهاجم إعادة تشغيلها في تبادل مختلف بهويات أو مقترحات مختلفة.

الوضع الرئيسي في IKEv1: اشتقاق SKEYID ثم إثباته

يشغّل الوضع الرئيسي ست رسائل. الزوج الأول يتفاوض على اقتران الأمان، والثاني يتبادل قيم ديفي-هيلمان العلنية والأرقام العشوائية، والثالث يحمل الهويات إضافة إلى تجزئات المصادقة تحت التشفير الذي أُنشئ للتو. يعرّف RFC 2409 البناء: مع المصادقة بالمفتاح المشترك مسبقًا، يُشتق SKEYID من السر ومن الأرقام العشوائية كليهما، وتُشتق مادة المفاتيح اللاحقة من SKEYID وقيمة ديفي-هيلمان المشتركة والكوكيز والثوابت.

تُحسب التجزئة في الرسالتين الخامسة والسادسة على قيمة ديفي-هيلمان والكوكيزين والمقترح وهوية المرسل، بمفتاح SKEYID. ويعيد المستقبل حسابها بالسر المهيأ لديه. وأي عدم تطابق ينهي التبادل، ولا يكون السر نفسه حمولة في أي لحظة.

يضغط الوضع العدواني العمل نفسه في ثلاث رسائل، ما يعني أن الهويات وتجزئة المصادقة تنتقل قبل وجود قناة مشفرة. وهذا تعرض حقيقي لسر قابل للتخمين، وهو منفصل عن مسألة ما إذا كان السر قد أُرسل. وقد أهمل RFC 9395 الإصدار IKEv1، لذا فإن أثرًا قديمًا يمثل تمرينًا تشخيصيًا لا هدفًا للنشر.

IKEv2: اشتقاق مختلف وحمولة AUTH مختلفة

لا يعيد IKEv2 استخدام جدول مفاتيح IKEv1. تأتي مفاتيح IKE الأولية من بذرة مبنية من الأرقام العشوائية وقيمة ديفي-هيلمان المشتركة، وتُشتق منها اقترانات الأمان الفرعية. ولا يغذي المفتاح المشترك مسبقًا البذرة إطلاقًا.

تظهر المصادقة بعد ذلك كحمولة AUTH. وبالنسبة للمصادقة بالمفتاح المشترك، يحدد RFC 7296 صيغة حشو للسر، تُنتج بتجزئة السر مع السلسلة الثابتة Key Pad for IKEv2، ثم تجزئة بيانات التبادل الموقعة والهوية بذلك المفتاح المحشو. ويستطيع المدقق إعادة بناء القيمة نفسها؛ أما المراقب فلا يستطيع دون السر.

لاحظ ما تغير. في IKEv1 يُدمج السر في جدول المفاتيح قبل وجود تجزئة المصادقة؛ وفي IKEv2 يكون جدول المفاتيح مستقلًا عن السر والإثبات حمولة منفصلة مرتبطة بالبايتات الموقعة. الضمان المفهومي نفسه، لكن الآلية مختلفة، ولهذا لا تتطابق أسماء المعاملات والالتقاطات واحدًا بواحد.

ما يتعلمه المراقب فعليًا

قيم ديفي-هيلمان العلنية والمقترحات والأرقام العشوائية والكوكيز مرئية في الإصدارين. والهويات مرئية في الوضع العدواني من IKEv1 ومحمية في الحالات الأخرى. أما السر فغير مرئي أبدًا.

لهذه الجملة الأخيرة حد يستحق الذكر. فالسر الضعيف الذي يختاره الإنسان يمكن مهاجمته بالتخمين: يحسب المهاجم قيمة المصادقة التي ستنتج عن سر مرشح ثم يقارن. والوضع العدواني في IKEv1 يجعل ذلك أرخص الجميع لأن الدليل في العراء، وتحذر المعايير عمومًا من الأسر منخفضة الإنتروبيا. وعدم إرسال السر أبدًا ليس هو نفسه جعل سر سيئ آمنًا.

ما الذي تفعله بهذه المقارنة

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

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