الخلاصة

  • فصل RFC 3961 بين المفتاح الأساسي ومفتاح العملية المحددة، وجعل رقم استخدام غير صفري من 32 بت مدخلاً للتشفير والتحقق.
  • اشتق الملف المبسط مفاتيح مستقلة للفحص والتشفير والسلامة؛ وكان النجاح يثبت اتساق ذلك السياق التقني لا سلطة المستخدم ولا نتيجة الخدمة.

رقم الاستخدام في RFC 3961 ليس سرًا. افترض النص أن المهاجم يعرفه. ومع ذلك غيّر الرقم المفتاح المشتق، لأن قيمته الحقيقية كانت في تسمية الوظيفة التي يؤديها المفتاح لا في إخفائها.

نشر المستند سنة 2005 إطارًا يفصل بروتوكول Kerberos عن تفاصيل منظومات التشفير. وجب على كل ملف أن يحدد صيغة المفتاح، وتحويل النص أو العشوائية إلى مفتاح، والاشتقاق، وحالة الشفرة، والتشفير، والسلامة، والدالة شبه العشوائية. أما رقم etype فكان معرفًا لهذا العقد الكامل، لا إثباتًا بأن تطبيقًا يدعمه أو أن خادمًا فعّله أو أن جلسة اختارته.

كانت مواد أقدم ضمن RFC 1510، ثم حل RFC 4120 محله في تعريف Kerberos V5 واستعمل طبقة التشفير المنفصلة. صار بإمكان البروتوكول أن يحدد المفتاح الأساسي ورقم الاستخدام من دون افتراض شكل متجه البدء أو الحشو أو بنية المفتاح الداخلية.

خمسة بايتات فصلت ثلاث وظائف

حدد البروتوكول المستهلك رقمًا علنيًا غير صفري من 32 بت لكل استعمال. وفي الملف المبسط أضيف إلى بايتاته الأربعة بايت أخير: أنتج usage | 0x99 المفتاح Kc للفحص، وأنتج usage | 0xAA المفتاح Ke للتشفير، وأنتج usage | 0x55 المفتاح Ki لسلامة الرسالة المشفرة. وكان دور المفتاح الأساسي أن يشتق هذه المواد فقط.

شرح قسم الأمن الدافع العملي. استخدمت بعض البرمجيات المفاتيح نفسها في Kerberos v4 وv5، فأمكن لوظيفة تشفير في الإصدار القديم أن تصبح oracle ضد الجديد. قلل العنصر العشوائي من قيمة النص المتوقع، وحدّ فصل الاستخدامات من انتقال القدرة بين السياقات. هذا وصف لمسار هجوم، لا تقرير عن حادثة بعينها.

نجاح التحقق إيصال محدود

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

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

بقي الإطار وتغيّرت الخوارزميات

عرّف RFC 3962 أنواع AES داخل الإطار. وفصل RFC 4537 بين قائمة الأنواع المدعومة والاختيار الفعلي. يسجل سجل IANA الأرقام والمراجع، لكنه لا يثبت النشر أو الاختيار.

أوقف RFC 6649 التوصية بـ single DES، وحدّث RFC 8429 RFC 3961 وأقصى خوارزميات قديمة أخرى. وحافظ RFC 8009 على الإطار العام لكنه لم يستخدم الملف المبسط، كي يتحقق من النص المشفر قبل فكّه. تغير البناء وبقي الحد الفاصل صالحًا.

توثق صفحة RFC Editor وسجل Datatracker تاريخ المستند. وتميز صفحة التصحيحات بين تصحيح Unicode مثبت، ومسألة DES مؤجلة للتحديث، واقتراح مرفوض. لا يثبت أي منها وحده عطلًا تشغيليًا.

علّم RFC 3961 الأنظمة أن تسأل: لأي وظيفة نجح المفتاح؟ رقم الاستخدام لم يمنح الإذن؛ بل منع وظائف ذات سلطات مختلفة من الظهور كقدرة تشفير واحدة.

المصادر