الخلاصة

  • وصفت النسخة 00 من AuthKEM مساراً من أربع رسائل يرسل ID_CRED_I مكشوفاً في الرسالة الأولى، وصرّحت بأن ذلك يضحّي بحماية هوية الطرف البادئ. هذه الفقرة غير موجودة في النسخة 01 المؤرخة 28 سبتمبر.
  • تحدد النسخة الجديدة خمس رسائل إلزامية. لا يكتمل تحقق الطرف المستجيب من البادئ واشتقاقه مفاتيح التطبيق إلا بعد فحص الرسالة الخامسة.
  • الرقم 5 لقيمة أسلوب المصادقة مقترح لا مخصص من IANA. كما أن وصف الأسلوب بأنه قائم على KEM لا يجعله تلقائياً مقاوماً للهجمات الكمّية؛ نوع الخوارزمية المستخدمة هو الحاسم.

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

في نسخة 28 سبتمبر حُذفت الفقرة الخاصة بهذا البديل، بينما تسرد فقرة نظرة البروتوكول العامة message_1 وmessage_2 وmessage_3 وmessage_4_KEM وmessage_5_KEM بوصفها رسائل إلزامية. ليس معنى ذلك أن فكرة الخمس رسائل وُلدت في سبتمبر؛ فقد ظهرت في النسخة السابقة أيضاً. ولا تسمح المقارنة باستنتاج سبب قرار المحررين أو باستبعاد كل تصميم محتمل من أربع رسائل. المعلومة المحددة هي أن المسودة الجارية لم تعد تقدم الاختصار الذي كشفت النسخة القديمة أثره على الخصوصية.

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

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

أما طلب التسجيل فتغير نطاقه. اقترحت نسخة يوليو قيماً لخوارزميات ML-KEM في COSE، وحزماً تشفيرية في EDHOC، وقيمة لأسلوب المصادقة. قسم IANA في النسخة 01 يقترح قيمة الأسلوب وحدها، ويصف «5» بأنها مقترحة، مع الإحالة إلى مسودات منفصلة عن تمثيل KEM وحزم LAKE المقاومة للكم. حذف المقترحات من هذه الوثيقة لا يثبت اعتمادها في مكان آخر. والوثيقة نفسها تؤكد أن الأسلوب لا يفرض خوارزمية KEM بعينها؛ لذا لا تصح دعوى مقاومة الكم إلا عند اختيار خوارزمية مناسبة بالفعل.

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

المصادر