الخلاصة

  • عامل RFC 3218 نص الخطأ وشكل الاستجابة وزمنها بوصفها مخرجات تشفيرية. فإذا أمكن تمييز كتلة RSAES-PKCS1-v1_5 مشوهة من كتلة سليمة شكلاً تحمل CEK خاطئاً، أمكن استغلال الفرق عبر استعلامات تكيفية متكررة.
  • كان «الملء العشوائي» يستبدل نتيجة فك التغليف غير الصالحة بـ CEK عشوائي جديد بالطول المتوقع، ثم يواصل فك المحتوى وفحوص السلامة. لم يكن المفتاح البديل صحيحاً ولا مستعيداً للبيانات؛ كانت مهمته جعل الفشل المبكر يبدو كفشل عادي سببه مفتاح خاطئ.

لم يكن على المهاجم أن يرى النص الصريح. كان يكفي أن يعرف هل اتخذ النص الصريح المخفي الشكل الذي تتوقعه الآلة.

أثبت Daniel Bleichenbacher عام 1998 أن هذه المعلومة ذات البت الواحد تكفي لبناء هجوم تكيفي بالنص المشفّر المختار على PKCS #1 v1.5. يلتقط المهاجم نصاً مشفراً بـ RSA، ويجري عليه تحويلاً رياضياً، ثم يقدمه إلى الجهة المالكة للمفتاح الخاص. ومن سلوكها يستنتج هل جاءت الكتلة المفكوكة مطابقة للتنسيق. كل إجابة تضيق المجال العددي الذي يمكن أن تقع فيه القيمة السرية. لا يغادر المفتاح الخاص جهاز المستلم، لكن قرارات الجهاز المتعاقبة تؤدي عمل فك التشفير أمام الخارج.

نقل RFC 3218 هذه المشكلة إلى Cryptographic Message Syntax. صدر في يناير 2002 بصفة Informational، ولم يكن تنسيق تشفير جديداً ولا إعلاناً بأن جميع استعمالات RSA متطابقة. عالج واقعاً انتقالياً: كانت تطبيقات CMS القائمة تنقل مفتاح تشفير المحتوى المتماثل عبر RSA PKCS #1 v1.5، ولم يكن ممكناً إلغاء ذلك التنسيق فوراً من دون كسر التشغيل البيني.

للكتلة في v1.5 نحو صارم: تبدأ بـ 00 02، ثم ثمانية ثمانيات عشوائية غير صفرية على الأقل، ثم فاصل 00، ثم القيمة المنقولة. في CMS تكون تلك القيمة الأخيرة هي مفتاح تشفير المحتوى، CEK. لذلك قد تنتهي عملية RSA بالمفتاح الخاص وتنتج بايتات، من دون أن تكون البايتات كتلة نقل صالحة.

تتوزع الحقيقة هنا على مراحل منفصلة. هل انتهت عملية RSA؟ هل كان تنسيق PKCS #1 صحيحاً؟ هل كان طول CEK وخوارزميته كما هو متوقع؟ هل كان هو المفتاح الذي استخدمه المرسل؟ هل أعاد فك المحتوى بايتات؟ هل قبلت الحشوة أو MAC أو التوقيع أو التطبيق تلك البايتات؟ يحتاج النظام إلى هذه الفروق داخلياً، لكنه لا يستطيع تقديمها كواجهة استعلام للخصم.

عبّر اسم Million Message Attack عن المقياس التشغيلي. ينطلق المهاجم من نص مشفّر ملتقط C، ويختار المضاعف S، ثم يرسل قيمة مرتبطة هي C' = C * S^e mod n. قدّر RFC 3218 أن تحويلاً واحداً تقريباً من كل 2^16 ينتج نصاً صريحاً يبدأ بـ 00 02، وأن السيناريو المدروس في CMS قد يحتاج إلى رتبة 2^20 من الرسائل والاستجابات.

لم يكن «المليون» عدداً ثابتاً لكل مفتاح وخادم. كان يشرح كيف تغيّر الأتمتة كلفة الهجوم. مليون تفاعل مع إنسان ستكون واضحة وباهظة. أما وكيل قائمة بريدية أو بوابة أو خدمة غير مراقبة فيمكنه فك كل رسالة وتصنيفها والرد عليها بسرعة الآلة. يقدم المهاجم المرور، ويقدم المستلم قدرة التكرار.

بعد كل استعلام قد تكون كتلة PKCS #1 مشوهة. وقد تكون سليمة شكلاً لكنها تحمل CEK زائفاً. وقد يقود CEK الزائف إلى فشل في السلامة. وإذا لم يكن المحتوى موثق السلامة، فقد تنتهي بايتات عشوائية مصادفة بحشوة CBC تبدو صحيحة. أما استعادة CEK الحقيقي من تحويل هجومي عابر فاحتمال بالغ الضآلة.

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

كانت توصية RFC 3218 الأساسية هي random filling. إذا اكتشفت عملية فك PKCS #1 تنسيقاً غير صالح، لا يتوقف المستلم هناك. بل يولّد CEK عشوائياً تشفيرياً بالطول الذي تتطلبه خوارزمية المحتوى، ويتصرف كأن فك RSA قد أعاد تلك القيمة.

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

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

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

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

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

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

أنشأ طول CEK حداً برمجياً آخر. قد تعرف مكتبة RSA عامة أن الكتلة سليمة نحوياً من دون أن تعرف هل تتوقع خوارزمية المحتوى 8 أو 16 أو 24 أو 32 بايتاً. فإذا أعادت المكتبة القيمة ثم رفضت طبقة CMS طولاً خاطئاً باستثناء مميز، لم يختف الأوراكل؛ بل صعد طبقة واحدة.

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

أوصى RFC بفحوص أدق لرفع كلفة الهجوم: التحقق من جميع ثمانيات الحشوة، ومن طول CEK، ومن بتات التكافؤ في عائلة DES عند انطباقها. تخفض كل حالة احتمال مرور تحويل عشوائي.

لكن الأوراكل النادر يظل أوراكل. إذا أعلن المستلم أي شرط فشل، يمكن للخصم مواصلة الجمع مع دفع عدد أكبر من الاستعلامات.

أظهر CBC غير الموثق أيضاً ضعف عبارة «نجح فك التشفير». قد ينتهي نص عشوائي ببايتات تبدو حشوة. إذا اعتمد التطبيق على البايت الأخير فقط لتحديد مقدار الاقتطاع، قدّر RFC 3218 فرصة النجاح الظاهري بنحو 1/32. أما فحص كل بايتات الحشوة المطلوبة فيخفضها إلى قرب 1/255.

لا تمنح أي مصادفة المحتوى العشوائي معنى. يوفر MAC أو التوقيع نقطة رفض متأخرة أقوى. ومع ذلك لا يبيحان كشف حكم PKCS #1 الأول منفصلاً؛ فجوهر الدفاع هو إذابته في حالات الفشل اللاحقة.

قدّم OAEP اتجاهاً تشفيرياً أنظف. كان PKCS #1 v2.0 قد عرّف RSAES-OAEP، وذكر RFC 3218 أن الهجوم موضع البحث لا ينطبق عليه. لكن OAEP غير متوافق سلكياً مع v1.5. يحتاج المرسلون والمستلمون والشهادات ومعرّفات الخوارزميات وبرامج CMS القائمة إلى اتفاق على التغيير.

لا تختفي البيئة القديمة بمجرد تسمية البديل الأفضل. كان random filling إجراء تعايش: ما دام التنسيق القديم يستقبل المرور، يجب تضييق ما يستطيع مساره أن يخبر به الخارج.

واجه TLS خطراً قريباً في premaster secret المشفّر بـ RSA. طلبت مواصفاته من الخادم متابعة المعالجة بقيمة عشوائية بدلاً من كشف خطأ في التنسيق أو الإصدار. المبدأ متقارب، لكن الآثار ليست متطابقة. مصافحة TLS ورسالة CMS ووكيل البريد لها آلات حالات واستجابات لاحقة مختلفة.

تقع القاعدة العامة فوق RSA: لا ينبغي لمحلل داخلي أن يجيب عن سؤال لا يستطيع البروتوكول الخارجي الإجابة عنه بأمان. يحدد البروتوكول مقدار العمل المستمر، والرفض النهائي الظاهر، والقنوات الجانبية التي يجب تسويتها.

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