الخلاصة

  • أخضع RFC 1446 رسالة SNMPv2 لاختبارين منفصلين: مطابقة ملخص MD5 المحسوب بسر مشترك، ثم التحقق من أن الطابع الزمني يقع ضمن مدة الحياة التي حددها المسؤول. صحة الملخص لم تكن برهانًا على أن الرسالة ما زالت حديثة.
  • كان على partyAuthClock ألا ينخفض ما دام المفتاح الخاص للمصادقة نفسه مستخدمًا. فالرجوع بالساعة وحدها يفتح مجالًا زمنيًا أُغلق من قبل، ويمكن أن يعيد أهلية رسائل قديمة محفوظة.
  • كان التعافي يتطلب حفظ عصر أمني يجمع هوية الطرف وجيل المفتاح والزمن أحادي الاتجاه. واعتمد RFC 3414 لاحقًا هوية المحرّك صاحب السلطة وعدّاد الإقلاع غير المتطاير ووقت الإقلاع الحالي، مع إبقاء التحقق المشفّر واختبار الآنية منفصلين.

الرسالة القديمة لم تتغير، لكن الحاضر هو الذي تحرك

لنفترض أن وكيل إدارة توقف عندما بلغ سجل ساعة المصادقة لطرف ما 44,000. قبل التوقف، سُجلت رسالة تحمل الطابع 43,500. وإذا كانت مدة الحياة 300 ثانية، فإن النسخة تصبح أقدم من المقبول بعد أن يتجاوز تصور المتلقي للساعة 43,800.

عند الإقلاع التالي يستعيد الجهاز نسخة محفوظة عند 43,400، بينما يظل المفتاح الخاص كما كان. فجأة تعود الرسالة ذات الطابع 43,500 إلى داخل النافذة. لم يرسلها صاحبها مرة أخرى، ولم تتبدل بايتاتها، ولم يُصنع لها ملخص جديد. المتلقي هو الذي تراجع عن معرفته بأن ذلك الجزء من الزمن قد انقضى.

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

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

للمصادقة بوابتان قبل الوصول إلى الإذن

نُشر RFC 1446 في أبريل 1993 ضمن Standards Track، وأصبح تصنيفه اليوم Historic. وقد عرّف بروتوكولًا للمصادقة وآخر للخصوصية في SNMPv2. وفي ملف v2md5AuthProtocol استخدم الطرف 16 ثمانيًا من مادة المصادقة الخاصة، وأنتج MD5 ملخصًا من 128 بتًا.

كان المصدر يضع السر مؤقتًا في حقل الملخص، ثم يرمّز صيغة الرسالة المصدق عليها ويحسِب ملخصها، ويستبدل السر بالنتيجة قبل الإرسال. أما المتلقي فيستخرج الملخص المرسل، ويعيد بناء الصيغة بوضع نسخته المحلية من المفتاح الخاص في الحقل، ثم يحسب ويقارن. وإذا اختلفت النتيجتان زاد snmpStatsWrongDigestValues ورُفضت الرسالة.

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

authSrcTimestamp + مدة الحياة < ساعة المصادقة المحلية

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

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

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

مدة الحياة قرار مخاطر وليست قياسًا طبيعيًا

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

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

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

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

المفتاح الجديد أغلق الطريق أمام الملخص القديم

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

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

كرر RFC 1447 القاعدة في تعريف partyAuthClock: لا يجوز إنقاص القيمة إلا إذا تغير المفتاح الخاص لمصادقة الطرف في الوقت نفسه. وسجل partyAuthLifetime المدة المقبولة بالثواني. لم تكن تلك حقول جرد مستقلة، بل أجزاء من حد أمني واحد.

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

لذلك يثبت سجل «قُبل طلب التغيير» حدثًا واحدًا فقط. لا يثبت أن الطرف حفظ المفتاح الجديد، ولا أن مديرًا آخر تعلمه، ولا أن التخلص من القديم أصبح آمنًا. التخلص المبكر يسبب انقطاعًا؛ والاحتفاظ غير المحدود يطيل زمنًا تعمل فيه عصور ثقة متعددة.

قراءة غير موثقة يمكن أن ترشد، لكنها لا تثبت

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

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

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

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

لا قيمة للزمن أحادي الاتجاه إذا ضاع عند انقطاع الكهرباء

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

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

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

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

عدّاد الإقلاع سمح للثواني بأن تبدأ من الصفر

نظم نموذج الأمن القائم على المستخدم في RFC 3414 الآنية لاحقًا حول محرّك SNMP صاحب السلطة. يحدد snmpEngineID المحرّك، ويعد snmpEngineBoots مرات الإقلاع أو إعادة التهيئة، ويقيس snmpEngineTime الثواني داخل الإقلاع الحالي. وكان على هوية المحرّك وعدّاد الإقلاع البقاء في تخزين غير متطاير.

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

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

لم يحل RFC 3414 محل RFC 1446 مباشرة؛ مرت عائلة SNMP بمراحل وسيطة. المقارنة هنا معمارية: حمى RFC 1446 ساعة مستمرة من الرجوع بربطها بتغيير المفتاح، بينما سمح RFC 3414 لمؤقت قصير بأن يعاد إلى الصفر لأن عدادًا دائمًا يميز العصر. وفي الحالتين، لا يكفي أن تتوافق الرسالة مع السر؛ يجب أن تنتمي أيضًا إلى تاريخ المتلقي الحالي.

المصادر