الخلاصة

  • يتيح Base في RFC 9180 التشفير لحائز مفتاح KEM الخاص بالمستلم. نجاح Open() يثبت قبول النص ضمن سياق بعينه، ولا يثبت هوية الطرف البعيد أو ولايته.
  • تضيف PSK وAuth وAuthPSK دليلاً محدوداً على حيازة مادة سرية مهيأة. لا تنشئ تلقائياً سجلاً للهوية أو إطاراً للرسالة أو نافذة لمنع الإعادة أو قراراً بالأثر.
  • يجب أن يفصل سجل التشغيل بين اختيار المفتاح، والمود، والـsuite، والسياق، والغلاف، وتحليل المعنى، والحداثة، والسياسة، والفعل الناتج.

تبدو نتيجة فك التشفير نهائية لأنها تأتي بعد حسابات دقيقة. وصل enc، اختير المفتاح الخاص، بُني السياق، وقبلت دالة Open() النص. لكن هذه السلسلة لا تجيب عن أسئلة الإدارة التي تأتي بعدها: من يملك الحق في طلب هذا النوع من الرسائل؟ هل المفتاح العام الذي استُخدم كان مخصصاً لهذا الغرض؟ هل الرسالة جديدة؟ وهل يسمح وضع العمل الحالي بفعل ما تقوله؟

RFC 9180 لا يدعي أنه يجيب عنها. يعرّف Hybrid Public Key Encryption بوصفه تركيباً من KEM وKDF وAEAD. KEM يتعامل مع تغليف السر المشترك واستعادته؛ KDF يشتق مادة السياق؛ وAEAD يحمي النص والبيانات المرتبطة به. هذه طبقة مشتركة مفيدة، لكنها ليست سجل أشخاص ولا بروتوكول نقل كامل ولا محرك تفويض.

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

ما الذي يمنحه Base فعلاً

في Base يستعمل المرسل المفتاح العام للمستلم pkR والقيمة info التي تقدمها التطبيق. وينشئ تغليفاً يمكن للمستلم معالجته باستخدام enc ومفتاحه الخاص skR. إذا تطابقت المدخلات والخوارزميات، يصل الطرفان إلى سياق يتيح ختم المحتوى أو فتحه.

هذا يثبت سراً موجهاً إلى صاحب المفتاح الخاص. لا يتضمن مفتاحاً خاصاً للمرسل ولا PSK مشتركاً. لذلك يستطيع أي طرف عرف المفتاح العام للمستلم إنشاء ciphertext ملائم لـBase. جدول خصائص RFC 9180 لا يمنح Base مصادقة للمرسل؛ وهذه ليست فجوة عرضية بل وصف دقيق لما يدخل في البناء.

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

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

المصادقة على المادة ليست مصادقة على المؤسسة

يضيف PSK دليلاً على أن المرسل حاز السر المشترك المهيأ. ويضيف Auth دليلاً مرتبطاً بحيازة مفتاح KEM الخاص بالمرسل، ويجمع AuthPSK بينهما. هذه فروق مهمة حين تكون الأسرار موزعة ومحمية ومدارة بصورة صحيحة.

لكن ما تثبته الصيغة هو الحيازة. قد تربط المؤسسة المفتاح بشخص أو حساب خدمة أو جهاز أو دور مشترك أو مورد خارجي. هذا الربط يحتاج سجلات إصدار وحيازة ونطاق وتبديل وسحب؛ لا يستخرج من AuthDecap().

يوضح RFC 9180 أن Auth وAuthPSK يصادقان زوج مفتاح المرسل، لا اسماً آخر. وإذا احتاج التطبيق إلى ربط نطاق أو بريد أو معرف أعمال، فعليه إدخاله في info. أي أن اختيار الاسم والتحقق من معناه وحفظ عمره قرارات تطبيقية ظاهرة، لا افتراضات مخفية في مكتبة التشفير.

كما أن RFC يذكر قيد key-compromise impersonation في متغيرات DHKEM Auth/AuthPSK تحت شروط اختراق مفتاح المستلم التي يحددها. فلا ينبغي أرشفة نتيجة Auth كدليل أبدي على إرادة إنسانية أو كعدم إنكار شامل. إنها ضمان محدد بمفاتيح وحالة وزمن ونموذج خصم.

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

الغلاف والوقت قراران محليان

يتيح HPKE معلومات تطبيق موثقة عند إنشاء السياق عبر info، وعند كل عملية عبر AAD. لكنه لا يعرّف wire format لرسالة HPKE. يجب على التطبيق أن يحدد بصورة غير ملتبسة مكان enc والنصوص المشفرة وترتيبها وأي info غير ضمني، وقد يحتاج إلى تحديد المفتاح العام المختار إذا كان للمستلم أكثر من واحد.

هذا الغلاف ليس تفصيلاً تجميلياً. هو الذي يحدد حدود الرسالة وإصدارها وmode وsuite والسياق الذي ينبغي بناؤه. نجاح فك التشفير لا يصلح غلافاً غامضاً، ولا يعطي للplaintext معنى طلب أو تفويض أو إجراء.

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

ولا يولد التشفير حداثة. يقدم RFC حماية محدودة من الإعادة داخل سياق واحد فقط عندما تقدم النصوص إلى Open() بالترتيب الذي خُتمت به. وخارج ذلك لا توجد حماية إعادة أخرى. يجب على التطبيقات متعددة الرسائل أن تفرض الترتيب وتكتشف الفقد، غالباً بمتتاليات أو معرّفات ثابتة مرتبطة بـAAD.

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

سلسلة دليل لا تقفز من بايت إلى نتيجة

عند اختيار المفتاح، سجل المعرف والمالك والغرض المسموح وقناة التوزيع والتدوير والسحب. وعند التحضير سجل mode وsuite ومصدر PSK أو مفتاح المرسل وinfo وAAD والغلاف وأي دليل تفاوض.

عند الاستقبال، احتفظ بمرجع آمن لـenc وciphertext وبالمفتاح المحدد ونتيجة بناء السياق ونتيجة Open(). هذه الأخيرة حقيقة مستقلة ولا ينبغي أن تكتب فوق حكم المحلل أو السياسة.

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