الخلاصة

  • كوّن RFC 3537 سجلاً من ثمانية طول ومفتاح HMAC وحشو عشوائي، لكي يدخل المفتاح المتغير في تغليف 3DES أو AES.
  • كان فك الغلاف يعيد الثمانيات ويختبر السلامة، لكنه لا يربط خوارزمية HMAC أو الغرض أو صاحب الصلاحية أو المصدر؛ فكل حامل لـ KEK يستطيع صنع غلاف مقبول.

تخيل خزنة تسلم شريطاً بالطول الدقيق. سلامة الختم لا تقول في أي جهاز يسمح باستخدام الشريط. هذا هو الفرق بين القياس والتفويض الذي حافظ عليه RFC 3537.

نشر Proposed Standard في مايو 2003 لمعالجة عدم توافق. صمم RFC 3217 لمفاتيح 3DES ذات قيود التكافؤ، وعالج RFC 3394 كتل 64 بت. أما مفتاح HMAC فمتغير الطول ولا يملك تكافؤ DES. أضاف RFC 3537 سجلاً داخلياً بدلاً من اختراع بدائية جديدة.

كان السجل LENGTH || KEY || PAD: ثمانية واحدة للطول، ثم ذلك العدد من ثمانيات المفتاح، ثم أقل حشو عشوائي للوصول إلى مضاعف ثمانية. يقرأ فك الغلاف LENGTH ويقتطع KEY ويرفض حشواً باقياً يزيد على سبع ثمانيات.

حررت عبارة «طول اعتباطي» المفتاح من المقاسات الثابتة، لكنها لم تجعل حقل الثمانية بلا حد. هذا استنتاج من التمثيل لا رقم أقصى يصرح به النص، لكنه يظل قدرة الصيغة الفعلية.

في 3DES تغطي قيمة تحقق من ثماني ثمانيات الطول والمفتاح والحشو. يجري التشفير بـ IV عشوائي جديد، ثم يسبق IV النص، ويعكس ترتيب الثمانيات، ويعاد التشفير بـ 4adda22c79e82105. وفي AES يمر السجل إلى RFC 3394 ولا يفسر إلا بعد نجاح السلامة. آلية السجل A تخص مقال RFC 3394؛ موضوعنا هو النوع الغائب بعد البوابة.

لا يحمل السجل خوارزمية HMAC اللاحقة ولا البروتوكول أو المستأجر أو الشخص أو المعرّف أو الوقت أو الانتهاء أو فئة الرسالة. PAD محمي بالسلامة لكنه لا يعني الغرض. يحدد LENGTH نهاية المفتاح لا نهاية السلطة.

تسمي OID الخاصة بـ HMAC-with-3DES-wrap وHMAC-with-AES-wrap، مع parameter إلزامي NULL، طريقة التغليف. لا تسمي HMAC-SHA-2 أو الخدمة. استنتاج إذن إنتاجي من «AES wrap» يضيف سياسة غير موجودة.

ينصح RFC 2104 بطول يبلغ خرج الهاش على الأقل، ويحد من فائدة الزيادة الكبيرة فوق حجم الكتلة. لكن فك الغلاف لا يختار الهاش ولا يفرض حده الأدنى. القبول البنيوي ليس حكماً على القوة.

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

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

يجب أن يكون IV في 3DES جديداً كل مرة، والحشو عشوائياً. هذه العشوائية تشكل الغلاف، ولا تصبح وسم HMAC أو nonce للعملية التالية.

يغير التصويب Verified الوحيد PAD في متجه الاختبار من 38be62 إلى be62fe، وهو المتوافق مع السجل المركب. التصويب Editorial ولا يغير الخوارزمية.

تقدم RFC 5652 وRFC 6031 وRFC 4868 وRFC 5649 وNIST SP 800-38F سياقاً خارجياً. لا يكتب أي منها الغرض بأثر رجعي داخل LENGTH || KEY || PAD.

تحفظ سلسلة الإثبات OID وKEK والإذن، والسلامة والطول والثمانيات، وخوارزمية HMAC الموثقة، والمعرّف والغرض وصاحب الصلاحية والمدة، والتنفيذ والتحقق ونتيجة التطبيق. جعل RFC 3537 الاستعادة متوافقة، لا التفويض كله.

المصادر