بلغ التشفير حدّه قبل انتهاء الجلسة: RFC 7146

الخلاصة

• استبدل RFC 7146 شرط RFC 3723 الخاص بتنفيذ 3DES-CBC بشرط تنفيذ AES-CBC بوصفه خط أساس إلزامياً لتوافق IPsec عند حماية بروتوكولات التخزين الكتلي.
• يوضح مثال 3 GiB هامشاً يقارب عشرة أضعاف دون حدّ عيد الميلاد البالغ 32 GiB لتشفير كتلي ذي 64 بت؛ وليس قاعدة عامة لتجديد المفتاح ولا تقريراً عن هجوم وقع.

سبق حجم البيانات نهاية الجلسة

قد تحمل رابطة أمنية في IPsec جلسة تخزين تعمل بصورة طبيعية، ومع ذلك تقترب من حدّ تشفيري قبل انتهاء الجلسة. عالج RFC 7146، المنشور في أبريل 2014، هذا التفاوت تحديداً: كان متوقعاً أن تعمل بروتوكولات التخزين الكتلي بسرعات تبلغ عدة غيغابتات في الثانية، في حين يعالج 3DES كتلًا من 64 بت. لذا لم يعد عمر المفتاح وحده هو المقياس؛ بل أصبح مقدار البيانات التي عولجت تحت المفتاح نفسه محورياً أيضاً.

حدّثت الوثيقة متطلبات IPsec الواردة في RFC 3723. كان المعيار السابق يفرض على التطبيقات دعم 3DES بنمط CBC، ويوصي بتنفيذ AES بنمط العداد (AES-CTR). جعل RFC 7146 كليهما اختياري التنفيذ، وفرض تنفيذ AES-CBC بدلاً منهما. وأبقى شرط دعم التشفير NULL؛ إذ يتيح روابط أمنية توفر المصادقة وسلامة البيانات من دون السرية. هذه متطلبات لما ينبغي أن تدعمه البرمجية، وليست أمراً باستخدام خوارزمية بعينها في كل نشر.

الحدّ ليس مؤقّتاً

يضع RFC 7146 حدّ عيد الميلاد لتشفير ذي كتلة من 64 بت عند 32 GiB. وينصح بتجديد المفتاح قبل ذلك بوقت كافٍ، لأن مواطن الضعف تبدأ بالظهور مع اقتراب حجم البيانات المشفرة بمفتاح واحد من هذا الحد. ويطرح مثالاً: التجديد بعد 3 GiB يوفر هامشاً من رتبة عشر مرات على وصلة متعددة الغيغابتات في الثانية. يشرح الرقم العبء التشغيلي، لكنه ليس عتبة مفروضة على كل نظام.

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

تستخدم AES كتلًا من 128 بت؛ ويذكر RFC 7146 حدّ عيد ميلاد أكبر بكثير قدره 2^68 بايت. لذا أصبحت AES-CBC بديل التنفيذ الإلزامي للتوافق. ولا يعني ذلك أن أنماط AES متبادلة: فالوثيقة توصي بأن تنفذ الأنظمة التي تدعم IKEv2 نمط AES-GCM أيضاً. أما تغيير وضع AES-CTR فله سبب مختلف؛ إذ صارت اعتبارات العتاد ترجح GCM. ولم يصف RFC ذلك بأنه إخفاق أمني في CTR.

ما الذي غيّره تحديث المتطلبات؟

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

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

المصادر: RFC 7146؛ معلومات RFC 7146؛ تصويبات RFC 7146؛ RFC 3723؛ RFC 4106؛ RFC 3602؛ RFC 4303؛ RFC 4301؛ RFC 8221؛ RFC 6071؛ RFC 6176.