الخلاصة

  • قد يحدد كائن AuthEnvelopedData خوارزمية AES-GCM بصورة صحيحة ويحمل معاملات سليمة وينجح في فحص وسم المصادقة، من دون أن يثبت أن زوج المفتاح وnonce لم يتكرر في كائن آخر.
  • لذلك تلزم RFC 5084 إدارة آلية للمفاتيح، وتعرض مفتاح CEK جديداً لكل محتوى بوصفه بناءً آمناً؛ دعم الخوارزمية ليس دليلاً على سلامة دورة حياتها.

يتلقى المستلم رسالة واحدة، يفك بنية CMS، يتعرف إلى AES-GCM، ويجد nonce بطول اثني عشر ثُمانية، ثم ينجح فحص الوسم. هذا إثبات مهم لكنه محدود: لا يستطيع المستلم أن يرى رسالة أخرى أصدرها خادم مختلف بالمفتاح نفسه قبل أسبوع.

تربط RFC 5084 خوارزميتي AES-CCM وAES-GCM بنوع المحتوى AuthEnvelopedData في CMS. فهي تعين معرفات مستقلة لأحجام مفاتيح AES الثلاثة، وتلزم وجود المعاملات، وتحدد أطوال قيمة التحقق، وتجعل السمات الموثقة بيانات إضافية موثقة في عملية AEAD.

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

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

تفرض RFC 5084 استخدام نظام آلي لإدارة المفاتيح. وتصف نقل المفتاح، واتفاق المفتاح، ومفاتيح تشفير المفاتيح المتماثلة، والمفاتيح المشتقة من كلمة مرور أو سر مشترك. تحقق هذه المسارات الشرط عندما يُنشأ مفتاح تشفير موثق للمحتوى، CEK، جديد لكل محتوى.

المفتاح الجديد لكل محتوى يقلص مساحة التاريخ المشترك. تكرار بايتات nonce تحت مفتاحين مختلفين حقاً لا يعيد الزوج المحظور. أما اختيار CEK طويل العمر فينشئ التزاماً آخر: مُخصص nonce ذري ودائم يغطي كل العمليات والمناطق وعمليات الاستعادة ضمن عمر ذلك المفتاح.

تبقى معاملات الكائن قيوداً حقيقية. يحمل GCMParameters قيمة nonce وطول ICV من اثني عشر إلى ستة عشر ثُمانية؛ الاثنا عشر هي القيمة الافتراضية والموصى بها، ويجب أن يطابق الطول حقل mac. وفي CCM يتراوح nonce بين سبعة وثلاثة عشر ثُمانية، وتكون أطوال ICV زوجية من أربعة إلى ستة عشر مع التوصية باثني عشر. كما يرتبط طول nonce هناك بسعة تمثيل طول المحتوى.

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

تعرف RFC 5083 الحاوية. وفي RFC 5084 تصبح السمات الموثقة هي AAD: تُحمى من التعديل ولا تُخفى. يغطي الوسم تلك السمات والمحتوى المشفر. أما السمة غير الموثقة فلا تكتسب سلطة لمجرد وجودها في الظرف نفسه.

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

تستقبل واجهة AEAD في RFC 5116 المفتاح وnonce والنص والبيانات المصاحبة. لا تبحث الخوارزمية في سجل تاريخي خارجي. كذلك تعد NIST SP 800-38D تفرد IV شرطاً تشغيلياً حاسماً في GCM.

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

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

تفصل سلسلة الإثبات بين بايتات CMS؛ معرف الخوارزمية ومعاملاتها؛ حقبة CEK أو سجل إنشاء مفتاح جديد؛ تخصيص nonce؛ AAD الدقيق؛ النص المشفر والوسم؛ المستلم وفرع إدارة المفتاح؛ نتائج التحليل وفتح المفتاح والتحقق؛ البحث التاريخي؛ قرار تحرير النص؛ وترخيص التطبيق ونتيجته.

هذه توصية تشغيلية وليست صياغة جديدة تضاف إلى RFC 5084. وفق انضباط طبقات الواقع لدى Heng Lu، اسم الخوارزمية والكائن والوسم والتفرد التاريخي وقرار المستلم والنتيجة التجارية سجلات متجاورة لا سجل واحد.

المصادر