الخلاصة

  • تعرّف RFC 10042 ثلاث طرق هجينة ML-KEM/ECDH لطبقة نقل SSH، وتشتق سراً واحداً من مكوّنين مؤقتين.
  • يحمل رد الخادم مفتاح المضيف وتوقيعاً على transcript، لكن الثقة بأن المفتاح يعود إلى المضيف المقصود لا تزال تحتاج قراراً محلياً مستقلاً.

من المفيد أن يبدأ التحليل من ما تقوله الحزمة فعلاً. يرسل العميل SSH_MSG_KEX_HYBRID_INIT وفيه C_INIT، وهو وصل لمفتاح ML-KEM عام ومفتاح عام كلاسيكي. ويرسل الخادم SSH_MSG_KEX_HYBRID_REPLY مع مفتاح المضيف العام K_S وS_REPLY، الذي يصل ciphertext لـ ML-KEM بالمفتاح الكلاسيكي للخادم، وتوقيعاً على هَشّ التبادل. ينتج عن المسارين سر تقليدي K_CL وسر ما بعد كمي K_PQ، ثم تفرض RFC 10042 تمثيلات ثابتة الطول وهَشّاً لتوليد K المستخدم في اشتقاق مفاتيح SSH.

هذه حدود تقنية ذات أثر حقيقي. يجب على الخادم فحص طول C_INIT قبل encapsulation، وعلى العميل فحص طول S_REPLY قبل decapsulation. فشل أي فحص أو فشل decapsulation يوجب قطع الاتصال بسبب فشل تبادل المفاتيح. كما تتطلب المواصفة زوج مفاتيح ECDH وML-KEM مؤقتاً جديداً لكل اتصال، وتحظر إعادة استخدام عشوائية ciphertext الخاص بـ ML-KEM. ولا يهدف الترميز ثابت الطول إلى التجميل؛ بل يقلل احتمال أن تتحول أطوال الأسرار إلى إشارة جانبية قابلة للرصد.

لكن هذه الضوابط لا تجيب عن سؤال: هل هذا هو المضيف الذي قصده العميل؟ تستخدم طبقة نقل SSH توقيع مفتاح المضيف لربط التبادل بالخادم، إلا أن RFC 4251 تقول إن العميل يحتاج معرفة سابقة بمفتاح المضيف العام. قد تكون المعرفة من قاعدة محلية تربط اسم المضيف بالمفتاح، أو من شهادة صادرة عن CA يقبلها العميل. وتوضح RFC 4253 أن العميل يتحقق من K_S باستخدام شهادة أو قاعدة محلية، وأن قبول المفتاح بلا تحقق يبقي البروتوكول عرضة للهجمات النشطة. RFC 10042 تعيد استخدام هذا الإطار؛ ولا تختار جذور الثقة ولا تفصل في صحة اسم المضيف أو سياسته.

الهَشّ يوضح ما هو مثبت وما هو غائب. فهو يشمل سلسلتي تعريف العميل والخادم، وحمولتي KEXINIT، وK_S، وC_INIT، وS_REPLY، وK. لذلك يستطيع ربط مواد إنشاء المفاتيح التي دخلت في تلك الجلسة. لكنه لا يحمل طلب SSH_MSG_USERAUTH_REQUEST، ولا سجل قبول مستخدم، ولا قاعدة محلية تحدد صلاحيات حساب، ولا طلب قناة ولا نتيجة أمر. تضع معمارية SSH مصادقة المستخدم فوق طبقة النقل، وتلزم الخادم بأن يطبق سياسته المحلية عند تقرير طرق المصادقة والوصول المقبول.

حتى أسماء الطرق الثلاثة — mlkem768nistp256-sha256 وmlkem1024nistp384-sha384 وmlkem768x25519-sha256 — لا تتجاوز وظيفتها الدقيقة. وجودها في سجل IANA أو في تهيئة عميل يبين أن آلية قابلة للتفاوض موجودة. ظهورها في KEXINIT يبين عرضاً. أما اختيار مشترك، وفحوص الطول، واشتقاق مكتمل، والتحقق من مفتاح المضيف، ومصادقة مستخدم، وإجراء لاحق فهي وقائع مختلفة. لا ينبغي أن يتحول سجل آلية إلى ادعاء موحد عن هوية أو سلطة.