الخلاصة

  • يوزّع RFC 9771 الأوصاف الشائعة لـ AEAD على أربع عائلات من الادعاءات؛ والخلط بينها قد يجعل عبارة صحيحة عن الخوارزمية مضللة عند حدود النظام.
  • يحتاج قرار الشراء أو الاعتماد القابل للدفاع عنه إلى «إيصال خاصية» يصل المفهوم الأمني الدقيق بالبنية والإصدار وسلوك API والاختبارات السلبية ودورة حياة المفاتيح ودمج البروتوكول.

الصفة ليست ضماناً

توحي عبارة «التعمية الموثَّقة» بأن القرار الأمني قد اكتمل. لكنها في الحقيقة أداة أولية تعتمد حمايتها على عقد بين الخوارزمية وانضباط المفاتيح وnonce والبيانات المصاحبة والواجهة وحالة البروتوكول المحيط. تكمن أهمية RFC 9771، الذي نشرته مجموعة Crypto Forum Research Group التابعة لـ IRTF في مايو/أيار 2025، في رفضه اختزال ذلك العقد في علامة جودة واحدة.

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

تأخذ الواجهة التقليدية الواردة في RFC 5116 مفتاحاً وnonce وبيانات مصاحبة ونصاً صريحاً؛ ويعيد فك التعمية النص أو الفشل. حتى هذه الواجهة الموجزة تخفي التزاماً تشغيلياً: يجب أن يكون nonce فريداً لكل استدعاء تحت المفتاح نفسه. لا تخبر عبارة «AES-GCM» في ورقة المواصفات من يملك مسؤولية التفرد، أو ما إذا كان يصمد بعد استعادة لقطة، أو كيف يقسّم مرسلون متزامنون المجال، أو ما إذا كان المسرّع والمسار البرمجي الاحتياطي يتشاركان الحالة.

يوسّع RFC 9771 المفردات من دون أن يلغي هذه الأسئلة. فهو ليس قائمة تؤدي فيها كثرة الصفات تلقائياً إلى مزيد من الأمان، بل خريطة لالتزامات إثبات مختلفة.

أربع عائلات وأربعة أنواع من الأدلة

العائلة ما الذي يتغير الدليل المصاحب
الأمن التقليدي هدف السرية وسلامة النص المعمّى الأساسي البنية والمعلمات والمفهوم الرسمي والحدود الفعلية ومتجهات الاختبار وحدود الاستخدام
خاصية أمنية إضافية يحصل الخصم على تكرار nonce أو تعدد المستخدمين أو التسريب أو النص المبكر ادعاءان منفصلان للسرية والسلامة، والمفهوم الرسمي، وفروق عدم التكافؤ، واختبارات سوء الاستخدام
خاصية تنفيذ طريقة إجراء الحساب المسار المقاس والذاكرة وعدد المرور وحد التحقق وتكافؤ العتاد مع المسار الاحتياطي
وظيفة إضافية واجهة جديدة مثل التحديث أو اختيار تمدد النص المعمّى عقد API جديد، ومفهوم أمني منقّح، وانتقالات الحالة، والتوافق، ودلالة الفشل

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

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

تجعل الوظائف الإضافية الحد أوضح. يضع RFC 9771 التعمية الموثقة التزايدية وrobust authenticated encryption في ملحق لأنهما تحتاجان إلى واجهات تتجاوز AEAD التقليدي. في الثانية يختار المستدعي مقدار تمدد النص المعمّى، فيبادل الطول بأقوى سلامة ممكنة عند ذلك التمدد. ولا تعني robust هنا «متانة المفتاح»، وهي عبارة تستخدم أحياناً مرادفاً للالتزام بالمفتاح. إذا احتفظ سجل الاعتماد بالكلمة وحدها فقد ضاع الفرق المهم.

تكمن الافتراضات في الكلمات المتقاربة

تبدو nonce-misuse resilience وnonce-misuse resistance مترادفتين، لكن RFC 9771 يميّز بينهما. تحمي resilience الرسائل ذات nonce الجديد حتى لو أجبر الخصم التكرار في مواضع أخرى. أما resistance فتحمي كذلك الرسائل التي وقع فيها التكرار فعلاً، باستثناء التسريب الحتمي عند تكرار النص نفسه تحت nonce نفسه. تستلزم resistance وجود resilience، وليس العكس.

يغيّر ذلك خطة الاختبار. في ادعاء resilience يجب إثبات أن الحادث لا يلوث حركة nonce الجديد. وفي ادعاء resistance يجب أيضاً توصيف الحركة المتضررة نفسها. يمثل AES-GCM-SIV في RFC 8452 بنية معيارية مقاومة لسوء الاستخدام، لكن خاصيتها لا تنتقل إلى GCM العادي، ولا تثبت طريقة تعامل النظام المحيط مع المفاتيح أو الأخطاء.

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

من ادعاء الخاصية إلى إيصالها

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

ثم يثبّت الإيصال موضوع الدليل: الخوارزمية والبنية والمعلمات وطول الوسم والمزوّد أو المكتبة والإصدار والبناء ومسار المعالج أو المسرّع والمسار الاحتياطي. يجيب برهان التصميم واختبار الملف التنفيذي عن سؤالين مختلفين؛ لذا يلزم كلاهما.

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

يجب اشتقاق الاختبارات السلبية من الخاصية: nonce مكرر، ومفتاح خاطئ، وبيانات مصاحبة معدلة، ونص من سياق آخر، ووسم مبتور أو مزور، وأجزاء معاد ترتيبها، وإخراج مبكر، ورجوع للحالة، واستعادة، ونفاد العداد، وانتقال طور المفتاح، واختلاف البرمجيات عن offload. يراقب الاختبار السلوك ولا يستبدل البرهان؛ ولا يثبت البرهان أن API حافظت على مقدماته.

تشمل دورة حياة المفتاح التوليد والاشتقاق والهوية ونطاق nonce والتسلسل والتزامن والحدود والتدوير والإتلاف والنسخ الاحتياطي والاستعادة والتجميع عبر المستخدمين. يصف RFC 8645 آليات إعادة إدخال المفاتيح، لكن على النشر إظهار المحفز المختار وكيف تتداخل الحالتان القديمة والجديدة. يجب أن ينتهي الإيصال عند تغيير المزوّد أو offload أو موزع nonce أو نموذج الاستدامة أو سياسة التدوير.

وأخيراً تسدّ أدلة البروتوكول الفجوة بين الأداة الأولية والشبكة. يبني TLS 1.3 nonce للسجلات من حالة التسلسل، ويضيف QUIC رقم الحزمة وطور المفتاح. تحتاج إعادة المحاولة ومنع الإعادة والاسترداد والهجرة والتأطير وربط السياق والتوافق والإنهاء العتادي إلى تحقق مستقل.

ما يستطيع المشتري طلبه الآن

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

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

المصادر