الخلاصة

  • يجيز RFC 9879 استخدام PBMAC1 داخل PKCS #12، ويفرض دعماً مشتركاً لـ PBKDF2 مع HMAC-SHA-256، ويصحح ترميز كلمة المرور الوارد في RFC 9579.
  • قد يستمر قارئ قديم إلى المفتاح المشفر بعد عجزه عن فهم فحص MAC، بينما تبقى قوة كلمة المرور ومعلمات KDF مسألتين مستقلتين.
  • يتطلب الانتقال القابل للتدقيق حفظ المعلمات الفعلية ونتيجة MAC وسياسة الفشل ومصير المفتاح، كلٌ كسجل منفصل.

يحمل PKCS #12 شهادات ومفاتيح خاصة وأسراراً أخرى بين الأجهزة والتطبيقات. لكن عبارة «فُتح الملف» لا تحدد ما حدث: هل قُرئت البنية، أم فُك التشفير، أم صحّ MAC، أم اجتازت المعلمات السياسة المحلية، أم دخل المفتاح إلى مخزن معتمد؟ نجاح خطوة لا يثبت التي تليها.

نُشر RFC 9879 في سبتمبر 2025 بوصفه وثيقة معلوماتية من IETF. وهو يلغي RFC 9579 ويحدّث RFC 7292 وRFC 8018. يسمح بأن يكون id-PBMAC1 نوع الخوارزمية داخل DigestInfo، وعند اختياره يجب أن توجد PBMAC1-params متسقة وأن تُحسب قيمة السلامة فوق authSafe وفقها.

تأتي الفائدة من فك الارتباط. كان اشتقاق مفتاح MAC القديم خاصاً بـ PKCS #12 ومحدود المرونة. أما PBMAC1 فيُظهر KDF ودالة المصادقة صراحة. يجب على كل تنفيذ دعم PBKDF2 مع HMAC-SHA-256 للفحص ولدالة PBKDF2 شبه العشوائية. ويوصى بدوال HMAC أخرى من SHA-2، ويمكن دعم scrypt وخيارات أخرى.

إظهار الخيارات يجعل المعلمات جزءاً من القرار. يجب تدوين طول المفتاح المشتق صراحة، ولا يجوز قبول PBKDF2 إذا غاب keyLength. ومع HMAC-SHA-256 ينبغي أن يكون الطول 32 ثمانية. لا يوصى بـ PBKDF2 مع HMAC-SHA-1، وتحظر خوارزميات الملخص الأخرى ذات 160 بتاً أو أقل.

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

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

صحح RFC 9879 أيضاً بايتات كلمة المرور. كان RFC 9579 يطلب BMPString تنتهي بـ NULL. يوضح الخطأ المصحح 7974 أن التنفيذ الذي أنشأ متجهات الاختبار أبقى كلمة المرور بصيغة UTF-8. أصبحت القاعدة UTF-8 من دون NULL نهائي أو BOM. تطابق النص الظاهر لا يكفي إن اختلفت البايتات التي وصلت إلى KDF.

تشمل المتجهات حالات صحيحة مع SHA-256 وSHA-512، وحالات مرفوضة بسبب تكرار أو ملح خاطئ أو غياب طول المفتاح. اجتيازها يثبت عملية حساب محددة. لا يثبت جودة كلمة المرور الفعلية، ولا أن القارئ يغلق عند خوارزمية مجهولة، ولا أن المفتاح بقي في نطاق الحفظ المقصود.

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

ويضيف RFC 8018 القيد الأوسع: تظل المهاجمة غير المتصلة ممكنة في التشفير القائم على كلمة مرور. يرفع الملح والتكرار تكلفة المحاولة، لكنهما لا يصنعان عشوائية في كلمة ضعيفة. يهدف scrypt إلى فرض كلفة ذاكرة تقلل ميزة العتاد المتوازي، غير أن RFC 9879 لا يجعله إلزامياً. اسم PBMAC1 لا يساوي مستوى قوة واحداً.

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

المصادر