الخلاصة

  • تجعل RFC 9973 السر الخارجي و(EC)DHE مدخلين في جدول مفاتيح TLS 1.3، من دون أن تحل PSK محل المصادقة بالشهادة.
  • يثبت اختيار identity والتحقق من binder أن الطرفين ربطا القيمة نفسها بالعنصر المختار في هذه المصافحة، ولا يثبتان منشأ السر أو انفراده أو حق استعماله.
  • يلزم فصل سجل منشأ السر وحيازته عن سجل تفاوض TLS، ومنهما عن تفويض التطبيق والالتزام والنتيجة المرصودة.

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

RFC 9973 هي معيار IETF من يوليو 2026 يحل محل RFC 8773 التجريبية. وتعرف امتداد tls_cert_with_extern_psk. إذا تم التفاوض عليه بنجاح، يدخل كل من PSK الخارجية المختارة والسر المشترك (EC)DHE في اشتقاق مفاتيح TLS 1.3. أما مصادقة الخادم، ومصادقة العميل عند طلبها، فتبقى مبنية على توقيع يمكن التحقق منه بالمفتاح العام في الشهادة. PSK الناتجة من جلسة سابقة تسمى resumption PSK، أما الناتجة من طريق آخر فهي external PSK؛ ولا يرخص الاسم المشترك خلطهما.

على العميل أن يرسل مع الامتداد key_share وsupported_groups وpsk_key_exchange_modes وpre_shared_key، وألا يرسل early_data. في المصافحة الأولى يلزم psk_dhe_ke، ويجب أن تكون القيم المعروضة PSK خارجية فقط. لا يعيد الخادم الامتداد إلا إذا قبل إحدى القيم المعروضة وسيجري مصادقة بالشهادة. رقم النوع 33 في سجل IANA يجعل الاسم قابلاً للتشغيل البيني؛ لا يثبت وجوده في جهاز بعينه.

ما يقوله binder وما لا يقوله

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

تضع RFC 9973 توليد PSK الخارجية وتوزيعها وإدارتها خارج نطاقها، مع أن ادعاءها المشروط عن سرية طويلة الأجل يعتمد على سرية PSK وإنتروبياها وأصالتها. تطلب وسيلة إدارة آمنة وتحذر من مولد عشوائي ضعيف؛ RFC 4086 توضح معيار التفكير في العشوائية، لا تمنح مصنعاً شهادة جودة.

ولا تنتقل المصادقة إلى PSK. تمنع الوثيقة الاعتماد على PSK الخارجية وحدها للمصادقة، وتبقي وظيفة الشهادة وتوقيعها مستقلة. قد يبقى سر الجلسة بعيداً عن خصم مستقبلي يكسر (EC)DH إذا لم يعرف ذلك الخصم PSK قوية، لكن ذلك لا يصلح تلقائياً مشكلة توقيعات الشهادات أمام هذا الخصم. RFC 9958 يقدم الإطار، لا حكما على منتج أو نشر قائم.

إعادة استعمال السر تغير المعنى أيضاً. السر الذي لا يعرفه إلا طرفان لجلسة واحدة ليس كالسر المعاد استعماله أو المعروف لمجموعة. كما تظهر هوية PSK في ClientHello غير المشفر ويمكن أن تساعد في تتبع اتصالين. الدوران وEncrypted Client Hello تخفيفان محتملان، لكنهما لا يقرران من له أن يطلب هوية جديدة أو كيف يتخلص من القديمة.

سلسلة دليل لا تنسخ السر

يجب أن تسجل الجهة المسؤولة عن المفاتيح غرض السر، فئة توليده أو اشتقاقه، الأطراف المسموح بها، نسخة TLS والهاش، مسار التزويد، الحائزين، قواعد الدوران والحذف. لا حاجة إلى وضع السر نفسه في السجل؛ يكفي ربط آمن يسمح بمراجعة الحيازة. ثم يحفظ مشغل TLS قبول الامتداد، مرجع identity غير كاشف، psk_dhe_ke، قرار التحقق من الشهادة ونتيجة Finished أو alert.

وتحفظ طبقة التطبيق سجلاً آخر: لماذا يحق لهذا الطرف التسجيل أو القراءة أو التعديل، ما شرط الحداثة ومنع الإعادة، هل تم الالتزام فعلاً، وهل شاهد نظام مستقل النتيجة. مبدأ Heng Lu عن أولوية الشفرة العاملة يمنع استبدال هذا المسار الحقيقي بتصريح إعداد. والفرق بين الشكل التقني والسيطرة العملية يفرض سؤالاً صريحاً: من يستطيع اليوم استخراج PSK ولو لم يكن اسمه في خانة المالك؟

المصادر