الخلاصة

  • عند غياب السمات الموقعة، يوقّع ML-DSA الخالص بايتات المحتوى مباشرة؛ يجب وضع SHA-512 في digestAlgorithm للتوافق، لكن على المدقق تجاهل الحقل.
  • عند وجود السمات الموقعة، يدخل ملخص المحتوى في المادة المحمية، ويلزم إعادة حسابه ومقارنته، وقد يضع مستوى قوته سقفاً لأمن التركيب كله.
  • يفصل سجل الإثبات بين مسار CMS، والبايتات الدقيقة، وOID لمجموعة المعلمات، ومقارنة الملخص، وحماية الخوارزميات، وحدود المفتاح وμ الخارجية، والتفويض، والنتيجة اللاحقة.

يمكن لشاشة الامتثال أن تعرض ثلاث إشارات خضراء: SHA-512، وML-DSA-65، و«التوقيع صالح». قد تكون الإشارات الثلاث صحيحة، لكنها لا تثبت أن SHA-512 لخّص المحتوى الذي عالجه ML-DSA، ولا أن المفتاح الخاص بقي داخل وحدة عتادية، ولا أن صاحب الشهادة مخوّل بالموافقة على الإجراء.

نُشر RFC 9882 في أكتوبر 2025 بصفته معياراً مقترحاً من IETF. وهو يحدد استخدام مجموعات ML-DSA-44 وML-DSA-65 وML-DSA-87، المعرّفة في FIPS 204، داخل Cryptographic Message Syntax. لكل مجموعة OID خاص بخوارزمية التوقيع، ويجب ألا يحتوي AlgorithmIdentifier على معلمات. يغطي النص ML-DSA الخالص، ولا يحدد HashML-DSA في CMS. كما أن الاسم السابق Dilithium لا يعني توافق الصيغتين.

المفتاح إلى فهم النتيجة هو السؤال عن وجود signedAttrs.

إذا غابت السمات الموقعة، تكون مدخلات ML-DSA هي البايتات التي تكوّن قيمة OCTET STRING في encapContentInfo eContent، من دون بايتات الوسم والطول. يعالج ML-DSA الخالص الرسالة نفسها، ولذلك لا يحمل SignerInfo.digestAlgorithm معنى في حساب التوقيع على هذا المسار.

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

يتغير الأمر عند وجود السمات الموقعة. تصبح مدخلات التوقيع هي ترميز DER الكامل لقيمة SignedAttrs، بما فيه الوسم والطول، باستخدام وسم EXPLICIT SET OF بدلاً من وسم IMPLICIT [0] في الرسالة النهائية. يجب أن تتضمن السمات، في الحد الأدنى، نوع المحتوى وملخص الرسالة. يحمل الأخير تجزئة المحتوى، وعلى المستلم إعادة حسابها ومقارنتها. هنا يؤثر اختيار خوارزمية الملخص فعلاً، وقد تقيد خوارزمية ضعيفة قوة المنظومة. دعم SHA-512 إلزامي، ودعم SHAKE256 موصى به، مع غياب معلماته.

ينتج عن اختلاف نحوي صغير معنيان تشغيليان مختلفان. إذا لم يسجل التدقيق أي المسارين استُخدم، فلن يستطيع تفسير digestAlgorithm أو تحديد البايتات التي خضعت لـML-DSA أو إثبات مقارنة المحتوى. عبارة «توقيع صالح» نتيجة رياضية محدودة وليست وصفاً كاملاً لسلسلة القرار.

هوية الخوارزمية تحتاج إلى فحص مستقل. يجب التحقق من OID الخاص بمجموعة ML-DSA ورفض المعلمات المحظورة. يضع CMSAlgorithmProtection المعرّف في RFC 6211 معرفات الخوارزميات ذات الصلة داخل سمة موقعة. ويوصي RFC 9882 بإدراجه لمقاومة استبدال الخوارزمية. وجوده واتساقه حقيقتان منفصلتان لا يمكن استنتاجهما من نجاح التوقيع وحده.

تبقى حيازة المفتاح طبقة أخرى. اختراق المفتاح الخاص لـML-DSA يتيح التزوير. يعرّف FIPS 204 افتراضياً توقيعاً محصناً يجمع عشوائية جديدة ببيانات عشوائية محسوبة مسبقاً في المفتاح، ويسمح أيضاً بالتوقيع الحتمي. يحذر RFC 9882 من النمط الحتمي على المنصات المعرضة لقنوات جانبية أو لهجمات الأعطال. لا تكشف رسالة CMS وحدها عن السياسة الفعلية.

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

يبدأ السجل القابل للدفاع بحفظ كائن CMS نفسه، ثم يسجل وجود السمات ويعيد بناء مدخلات التوقيع ويحدد OID ويرفض المعلمات غير المسموح بها. عند وجود السمات يعيد حساب ملخص المحتوى ويقارنه، ثم يفحص حماية الخوارزميات والتوقيع. وبعد ذلك فقط تُقيّم سياسة العشوائية ومصدر μ ومسار الشهادة والهوية والصلاحية التطبيقية والفعل النهائي كلٌ على حدة.

المصادر