Summary

  • نُشرت المراجعة 27 من draft-ietf-cose-hpke في 12 سبتمبر، وما زالت في متابعة مدير المجال. إنها مسودة إنترنت ضمن مسار المعايير، وليست RFC ولا ملف نشر مُعتمداً.
  • وجود psk_id في ترويسة محمية يختار وضع PSK؛ أما غيابه فيختار الوضع الأساسي، الذي يشفّر لحائز مفتاح المستلم الخاص من دون توثيق المرسل في KEM الخاص بـHPKE.
  • يشير kid إلى مفتاح المستلم لا إلى هوية المرسل. يقترح Daniel Kade إيصالاً مقتصداً للخصوصية يسجل مسار التوثيق والتفويض الفعلي من دون حفظ PSK أو النص الصريح؛ وهذا تحليل تحريري لا مطلب من IETF.

النجاح التشفيري لا يسمّي صاحب الفعل

ظهرت المراجعة 27 في 12 سبتمبر. ويبين سجل Datatracker أن الوثيقة، بعد تقديمها إلى IESG للنشر على مسار المعايير، ما زالت في حالة AD Evaluation::AD Followup. وشددت الصياغة الجديدة على أن HPKE يحتاج إلى مصدر عشوائية آمن تشفيرياً، وأن مفتاح تشفير المحتوى في نمط Key Encryption يجب أن يُولد بالطريقة نفسها.

هذا تشديد معياري، لكنه ليس نهاية المسار. يمكن أن يتغير السجل الحالي، ولا تزال أرقام IANA في المسودة افتراضية، ولم تصدر وثيقة RFC. إلا أن حدود الدلالة واضحة الآن: نجاح عملية الفتح لا يمنح تلقائياً هوية للمرسل.

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

بنية التشفير وخيار التوثيق محوران منفصلان

تحدد المسودة بنيتين. في Integrated Encryption يحمي HPKE النص الصريح مباشرة داخل COSE_Encrypt0 لمستلم واحد. أما Key Encryption فيحمي المحتوى بمفتاح تشفير محتوى، ثم يغلّف HPKE ذلك المفتاح في طبقة المستلم، وبذلك يمكن خدمة عدة مستلمين.

يربط كل معرّف خوارزمية COSE مقترح تركيبة كاملة من KEM وKDF وAEAD بالبنية المخصصة لها. ويمنع هذا الربط خلط المكونات بصمت أو استعمال معرّف الطبقة المتكاملة في طبقة تغليف المفتاح.

لكن وضع توثيق المرسل لا يوجد في رقم الحزمة. إذا ظهر psk_id محمياً استُخدم mode_psk، وإذا غاب استُخدم mode_base. وتشير المسودة صراحة إلى أن الوضع لا يُذكر بذاته في معرّف الحزمة التشفيرية.

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

kid يساعد المستلم على اختيار مفتاحه

توصي المسودة باستخدام kid لتحديد المفتاح العام الثابت للمستلم الذي اختاره المرسل. ويمكن للمستلم استعماله للوصول إلى المفتاح الخاص المقابل أثناء التدوير أو عند تزامن عدة أجيال من المفاتيح. لكنه لا يحدد صاحب الرسالة.

توزيع المفتاح العام خارج نطاق الوثيقة. لذا يجب على التطبيق أن يحتفظ بمصدر المفتاح ونطاقه التنظيمي وتاريخ صلاحيته. وقد يكون المفتاح صحيحاً حسابياً لكنه من دليل مستأجر آخر؛ عندها ينجح HPKE في حماية مدخل تنظيمي خاطئ.

كذلك لا يمثل psk_id السر نفسه. فالمعرّف محمي، بينما تدخل PSK من الخارج ولا يجوز تضمينها في كائن COSE. يثبت النجاح حيازة السر، لا هوية شخص بعينه ولا استمرار دوره ولا صلاحية طلبه. وتحذر مسودة HPKE الحالية من المفاتيح منخفضة العشوائية؛ فكلمة مرور ضعيفة لا تصبح PSK سليمة لمجرد اشتقاقها أو وضع معرّفها في ترويسة محمية.

ربط السياق لا يكتب سياسة التطبيق

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

إلا أن البنية تحمي ما يختاره التطبيق فقط. هل يلزم إدخال المستأجر أو الغرض أو تاريخ الانتهاء أو نسخة السياسة أو رقم الطلب؟ يقرر ملف الاستخدام ذلك. وقد يكون السياق الفارغ صحيحاً من ناحية الترميز وغير كافٍ لتفويض محلي.

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

ويظهر حد آخر مع النص المشفّر المنفصل. لا تغطي توقيعات COSE أو MAC المضافة لاحقاً البايتات المنفصلة تلقائياً. تطلب المسودة ضمان سلامتها أيضاً. عبارة «التوقيع صحيح» لا تكفي ما لم يسجل النظام أي محتوى شمله التوقيع.

الوضع الأساسي خيار مشروع إذا كان مقصوداً

قد يحتاج صندوق استقبال سري إلى قبول إرسال مجهول، أو قد يوثق بروتوكول آخر المرسل في طبقة منفصلة. تذكر المسودة COSE_Sign وCOSE_Sign1 وCOSE_Mac وCOSE_Mac0 كوسائل لإضافة التوثيق.

المشكلة ليست في الوضع الأساسي، بل في منحه دلالة لم يعد بها. كما لا يحل وضع PSK كل شيء: قد يمثل السر جهازاً أو أسطولاً أو فريقاً كاملاً. حيازته لا تحدد تلقائياً التفويض أو الإنابة أو الإلغاء.

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

إيصال يشرح سبب القبول

يقترح Daniel Kade إيصال توثيق المرسل لكل كائن COSE HPKE مقبول. يسجل نسخة المسودة أو ملف التشغيل، وIntegrated أو Key Encryption، والحزمة التشفيرية، ووضع HPKE الفعلي، وبصمة مفتاح المستلم ومصدر توزيعه. وفي وضع PSK يضيف بصمة أحادية الاتجاه لـpsk_id ونسخة غير سرية للمفتاح وحالته في دورة الحياة. وفي الوضع الأساسي يحدد التوقيع أو MAC أو القناة أو هوية التطبيق التي جرى التحقق منها، أو يصرح بأن الاستقبال المجهول مسموح.

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

هذا الإيصال ليس مطلوباً في المسودة أو RFC 9052 أو RFC 8937 أو سجل COSE لدى IANA. إنه دليل تنظيمي يفصل نتيجة الآلية عن السلطة، وفق Policy Mirror لـHeng Lu. وتدعم فكرة المواصفة الأولية الدنيا إبقاء السجل المشترك صغيراً، بينما تمنع قاعدة BTW التحريرية تحويل مراجعة مسودة إلى ادعاء عن حادثة أو فشل تشغيلي.

Sources

  1. COSE HPKE، المراجعة 27
  2. COSE HPKE، المراجعة 26
  3. سجل Datatracker الحالي
  4. تاريخ الوثيقة
  5. HPKE، المراجعة 04
  6. RFC 9052 — بنى COSE ومعالجتها
  7. RFC 8937 — تحسين العشوائية
  8. سجل COSE لدى IANA
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists