الرحلة الطويلة من RFC 4357 إلى RFC 8645 أو كيفية إدارة مفاتيح التشفير

كما تعلمون ، تعد إدارة المفاتيح واحدة من أصعب المهام في التشفير. في اليوم الآخر فقط ، تم نشر وثيقة "آليات إعادة المفاتيح للمفاتيح المتماثلة" في RFC 8645 . إنه نتاج عامين ونصف من عمل مجموعة أبحاث CFRG ، التي تحدد تطور واستخدام التشفير في IETF ، واستندت إلى سنوات عديدة من البحث وتجربة المتخصصين الروس. بعد ذلك ، سنشرح بإيجاز ما هو جوهر طلب تقديم العروض هذا ولماذا اتضح أن ذلك هو بالضبط.

القليل من الخوف ...

في عام 2016 ، نشر باحثان فرنسيان من معهد إنريا وصفًا لهجوم Sweet32 . الفكرة التي استخدموها بسيطة بشكل فاحش وتستند إلى ما يسمى "مشكلة عيد الميلاد" : إذا قمنا بحساب قيم التعيين العشوائي $$$f: V_n \ rightarrow V_n$ثم في حوالي $$$2 ^ {n / 2}$الاختبارات في التسلسل الناتج لا يقل عن قيمتين تتزامن. من وجهة نظر التشفير ، وهذا يعني أن كتلة التشفير مع طول كتلة $$$ن$لا يمكن تشفير البت على مفتاح واحد بعد الآن $$$2 ^ {n / 2}$كتل غير عادي.



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

ولكن هل طول الكتلة؟

في الواقع ، هل يستحق نبذ الشفرة لمجرد أنه يحتوي على طول كتلة قصيرة: ماذا لو قمت بتغيير المفتاح بشكل دوري؟ يمكن القيام بذلك باستخدام ما يسمى دالة اشتقاق المفتاح ( KDF ). تتيح لك هذه الوظائف الحصول على مفاتيح جديدة بناءً على المفاتيح القديمة ، مع الحفاظ على خاصية العشوائية للمفاتيح (انظر ، على سبيل المثال ، هذه المقالة ). يتم تحديد هذه الوظائف ، على سبيل المثال ، من خلال توصيات التقييس الروسية P 1323565.1.022-2018 و P 50.1.113-2016 . ومع ذلك ، هناك واحد "لكن": هذه تحويلات معقدة للغاية وليست سريعة جدًا مبنية على أساس وظائف التجزئة ، والتي سوف تبطئ سرعة التشفير بشكل كبير.

هل من الممكن فعل شيء أسرع؟

تم إجراء هذه المحاولة في عام 2006 في RFC 4357 ، حيث تم اقتراح آلية تشبك مفتاح تشفير CryptoPro ، والتي تنتج مفتاح مشتق من خلال تشفير ثابت ثابت مع تشفير كتلة في وضع بديل بسيط.



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

اتضح ليس بهذه البساطة

لسوء الحظ ، المعجزات غير موجودة ، وليس من الممكن تقديم آلية سريعة تضاهي KDFs التقليدية ، ومع ذلك ، يمكننا إثبات سلامة العديد من المخططات المعدلة مثل ربط المفاتيح المحدد لكل وضع تشفير محدد. هذه هي الآليات التي تم اقتراحها وتبريرها لوضع CTR gamma المستخدم على نطاق واسع (CTR-ACPKM ، إطالة التشفير المشفر للمواد الأساسية) وتطوير ملحق محاكاة OMAC (OMAC-ACPKM) من المعيار المحلي GOST R 34.13-2015.

يتم الحصول على تقييمات السلامة لهذه الأوضاع باستخدام ما يسمى بالجهاز "توفير المتانة . "

اعتمدت هذه الأساليب في روسيا كتوصيات لتوحيد معايير R 1323565.1.017-2018 .

هذه هي طريقة العمل مع المفاتيح التي تسمح لأدوات التشفير التي تقوم بتطبيق مجموعات تشفير TLS 1.2 الروسية (المحددة في توصيات التقييس R 1323565.1.020-2018 ) لتلبية متطلبات حماية التشفير الروسية للفئات العليا.

العمل في IETF

الآليات المطورة مناسبة تمامًا كإجابة للمناقشة المذكورة في بداية المقالة حول ما إذا كان يجب أن يكون هناك الأصفار مع طول كتلة قصيرة أم لا.

تم إعداد الوثيقة المقابلة ، والتي أصبحت فيما بعد RFC 8645 ، من قبل رئيس CFRG كيني باترسون وأليكسي ميلنيكوف من قبل مجموعة دولية من الخبراء بقيادة ستانيسلاف سميشلييف. قدم المساهمة في تطوير الوثيقة الختامية كل من Evgeny Alekseev و Ekaterina Smyshlyaeva و Lilia Akhmetzyanova (CryptoPro) و Shay Gueron (جامعة حيفا) ودانييل فوكس Franke (Akamai Technologies) وكذلك رئيس IETF Russ سابقًا (Vigil Security). في مراحل مختلفة ، انضم إلى هذا العمل متخصصون رئيسيون مثل Mihir Bellare (جامعة كاليفورنيا) و Scott Fleurer (Cisco) و Yoav Nir (نقطة تفتيش) و Dmitry Belyavsky (Cryptocom) و Paul Hoffman (ICANN).

مقارنة بالتوصيات الروسية ، تمت إضافة آليات ACPKM الخاصة بأنماط مثل CBC و CFB و GCM إلى RFC ، والتي ، كما ربما تكون قد فهمت بالفعل ، تتطلب أدلة منفصلة .

ملخص

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