الخلاصة

  • استطاع عدّاد الاتساق ذي الاثنتي عشرة بت في RFC 3078 كشف فقد حزمة MPPE أو انقطاع ترتيبها، لكنه لم يُعد بناء النص المشفّر المفقود ولم يثبت وصول البيانات إلى التطبيق.
  • أمكن للنمط عديم الحالة تقديم المفتاح بمقدار الفجوة. أما النمط ذو الحالة ففرض إسقاط الحزم وإرسال CCP Reset-Request وانتظار حزمة FLUSHED قبل الوثوق بحالة التشفير من جديد.

الحزمة التي كشفت الحقيقة لم تكن صالحة للاستخدام

توقّع المستقبل قيمة للعدّاد، لكنه رأى قيمة أخرى. أثبت الرأس أن جزءاً من التاريخ المحلي غائب، غير أن المرسل ربما كان قد عبر نقطة تغيير مفتاح لم يرها المستقبل. لم تحمل القيمة الجديدة معها حالة RC4 الصحيحة.

طلب RFC 3078 في النمط ذي الحالة إسقاط تلك الحزمة، وإرسال CCP Reset-Request بلا بيانات، ثم إسقاط ما يلي بصمت حتى ظهور FLUSHED. وبعد تلقي الطلب، يعيد المرسل تهيئة جداول RC4 ويضع العلامة على الحزمة التالية. لم يحتج الانتقال إلى Reset-Ack مستقل؛ كان تغيّر سلوك المرسل هو الإيصال الفعلي.

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

سبقت التشفير قرارات متعددة

نُشر RFC 3078 في مارس 2001 بوصفه RFC معلوماتياً. وصف Microsoft Point-to-Point Encryption لحركة PPP، وحدّث استخدام الخيار المشترك مع MPPC في RFC 2118. لم يكن معيار إنترنت.

تفاوض الطرفان على MPPE من خلال الخيار 18 في Compression Control Protocol. يعرض المبادر الخيارات التي يدعمها، ويختار الطرف الآخر عادة خياراً واحداً من 128 أو 56 أو 40 بت. وكان هناك بت مستقل لطلب النمط عديم الحالة. إذا لم تبدأ المفاوضة بقي الاتصال بلا تشفير افتراضياً؛ وإذا بدأت وفشلت، أوصى النص بإنهاء الوصلة.

قبل إرسال بيانات MPPE، كان على PPP بلوغ مرحلة Network-Layer Protocol وعلى CCP بلوغ Opened. نجاح المصادقة ليس Opened. وصول مفتاح لا يختار النمط. عرض 128 بت لا يثبت قبولها. وسياسة تقول إن التشفير مطلوب لا تشفّر أول حزمة بذاتها.

قسّمت الوثائق المجاورة المسؤولية صراحة. نقل RFC 2548 مفاتيح MPPE المختلفة بحسب الاتجاه عبر RADIUS. وشرح RFC 3079 اشتقاق المفاتيح. وقدّم RFC 1962 تفاوض CCP وإعادة الضبط، بينما عرّف RFC 1661 مراحل PPP. ركّز RFC 3078 على حالة الحزم المشفّرة وهي تعمل فعلاً.

حفظت اثنتا عشرة بت الموضع لا المحتوى

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

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

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

كما أن نطاقاً محدداً فقط من بروتوكولات PPP كان يمر عبر MPPE. ولم يكن بت البيانات المشفّرة دليلاً محمياً بالنزاهة. رؤية حزمة تبدو MPPE لا تجيب وحدها عمّا كان يجب حمايته أو عمّا فُك فعلاً.

لحق النمط عديم الحالة بموضع المفتاح

في النمط عديم الحالة تغيّر مفتاح الجلسة كلما تغيّر العدّاد، أي عادة مع كل حزمة. يقدّم المرسل المفتاح قبل التشفير، ويقدّمه المستقبل بعد قراءة القيمة وقبل فكها. وتحمل كل حزمة مشفّرة FLUSHED.

إذا كانت آخر قيمة اثنتين ووصلت خمس، ينفذ المستقبل ثلاثة تغييرات للمفتاح ثم يحاول فك الحزمة الخامسة. لا يحتاج إلى Reset-Request كي يلحق بالمرسل، لكن محتوى الحزمتين الثالثة والرابعة لا يعود.

لم يكن «عديم الحالة» يعني غياب الحالة المشتركة. بقي الطرفان معتمدين على مفتاح بدء واحد، ودالة تطور واحدة، ومعنى مشترك للعدّاد، ونمط متفق عليه. أعطت كل حزمة حدّاً يمكن منه إعادة بناء الموضع محلياً فحسب.

جعل النمط ذو الحالة طريق العودة جزءاً من فك التشفير

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

أدخل Reset-Request المسار العكسي في تعافي بيانات المسار الأمامي. قد يرى مراقب أحادي الاتجاه الفجوة ثم FLUSHED، لكنه لا يثبت أي مستقبل أرسل أي طلب. ورؤية الطلب وحدها لا تثبت استجابة المرسل ولا أول نص واضح صالح. يجب وصل الاتجاهين مع نتيجة فك التشفير.

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

لم تكن المفاوضة نفسها محمية بالنزاهة

أمكن لمهاجم نشط تعديل Supported Bits والتأثير في القوة الظاهرة. تقلل تهيئة محلية ترفض الأنماط غير المقبولة الأثر، لكنها لا تجعل المحادثة موثقة المصدر.

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

ويتطلب التاريخ الدقة في شأن RC4. وصف RFC 4345 لاحقاً أنماط Arcfour محسنة في SSH، وهو بناء مختلف. يذكّرنا بأن طول المفتاح الاسمي لا يكفي لتقييم الأمن، لكنه لا يثبت أن MPPE هاجر أو بقي منتشراً أو اكتسب خصائص لاحقة.

الإيصال الصحيح سلسلة من التحولات

ينبغي حفظ جلسة PPP وهوية الطرفين، ونتيجة المصادقة، ومصدر المفتاح وجيله من دون كشف السر، وعروض CCP وردودها، والقوة والنمط المختارين، ووقت Opened. ولكل اتجاه تُحفظ القيم المتوقعة والمرصودة، والعودة بعد 4095، والفجوات، وFLUSHED، وحدود 0xFF، وعدد الحزم المسقطة، وإرسال Reset-Request وتلقيه، وفترة الانتظار، وأول نص واضح ناجح بعد الاستعادة.

ثم يستمر السجل إلى الطبقة العليا: التسلسل وإعادة الإرسال والإقرار والأثر. تزامن جداول RC4 لا يعيد رسالة غابت.

يعزل منظور طبقات الواقع لدى Lu Heng الأفعال: المصادقة، واشتقاق المفتاح، ونقله، والتفاوض، والاستقبال، وكشف الفقد، واستعادة الحالة، وفك التشفير، والتسليم. يربطها الكود العامل عندما تقع فعلاً؛ لا يدمجها بت واحد.

المصادر