الخلاصة

  • تصف المراجعة 19 من Roughtime بروتوكولًا مقصودًا للمسار Experimental، تستطيع فيه سلسلة تبادلات موقعة إثبات أن خادمًا واحدًا على الأقل قدم وقتًا لا ينسجم مع الترتيب السببي. وقد لا تكشف السلسلة أي خادم كان المخطئ.
  • تحدد المسودة صيغة لقائمة الخوادم الموثوقة وأخرى لتقرير سوء السلوك، لكنها تترك قبول التقارير والفصل فيها واستبعاد الخوادم وصيانة القوائم خارج نطاقها، مع إقرارها بأن هذه الإجراءات أساسية للأمن.
  • ينبغي أن يربط إيصال محمول لسحب الثقة تجزئة التقرير وحدود الإسناد والمراجعة المخولة والقرار وانتقال القائمة الموقّع والتوزيع واعتماد العميل ومسار التصحيح. هذا اقتراح من Daniel Kade وليس مطلبًا من IETF.

صحة التوقيع لا تعني صحة الساعة

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

النص الحالي هو draft-ietf-ntp-roughtime-19، نُشر في 17 مارس/آذار 2026 بنية Experimental. وافقت عليه IESG في اليوم نفسه. ويضعه Datatracker حاليًا في طابور RFC Editor، وانتقلت حالة الإنتاج في 4 سبتمبر/أيلول إلى In Progress (Second Edit). غير أن هذه الخطوات لا تجعله RFC منشورة؛ فما زالت المراجعة Internet-Draft ولم يثبت لها رقم RFC نهائي.

يرسل العميل nonce جديدًا. يرد الخادم بنقطة وسط ونصف قطر يحددان المجال الذي يزعم أن الوقت الحقيقي يقع فيه. يغطي التوقيع التزام Merkle tree مرتبطًا بطلب العميل. وهكذا يمكن إثبات أن حامل المفتاح طويل الأمد أنتج الجواب بعد استلام الطلب.

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

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

هناك فرق بين «وقّع هذا المفتاح هذا الجواب»، و«لا يمكن أن تصح هذه الأجوبة معًا»، و«يجب حذف هذا المفتاح من القائمة». يثبت البروتوكول الوقائع الأولى، أما الثالثة فتحتاج سلطة قرار منفصلة.

تعترف المسودة بحدودها المؤسسية

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

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

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

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

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

قائمة الخوادم سياسة ثقة قابلة للتنفيذ

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

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

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

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

يمارس ناشر القائمة تفويضًا محدودًا من مستخدميه، لا ولاية عامة على الخادم. ولا يصبح قراره واقعًا إلا عندما يستلم العميل القائمة الجديدة ويتحقق منها ويقبلها محليًا.

حماية مستقبل التقرير عند ضغط الإرسال

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

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

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

وينبغي تقليل بيانات العميل. فالتحقق يحتاج الرسائل والمفاتيح، ولا يحتاج بالضرورة هوية الجهاز الدائمة. قابلية حمل الدليل لا تمنح مبررًا لإنشاء سجل للمراقبين.

الإسناد نتيجة متعددة الحالات

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

تعيد المراجعة فحص التواقيع وروابط nonce والمجالات ونصف القطر والثواني الكبيسة واكتمال الجمع. ثم تعلن نتيجة دقيقة: مفتاح محدد، أو مجموعة مرشحين، أو تناقض بلا إسناد.

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

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

يحمي NTS حدًا آخر

تحدد RFC 8915 آلية NTS باستخدام TLS والتشفير الموثق لحماية تبادل NTP. يستطيع العميل التحقق من المصدر والسلامة ومنع الإعادة وفق النموذج، لكنه لا يضمن أن ساعة الخادم الموثق صحيحة.

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

وتقوي Khronos في RFC 9523 اختيار مصادر NTP وترشيحها ضد هجمات إزاحة الوقت. يحمي ذلك العميل محليًا، بينما ينتج Roughtime مادة قابلة للفحص عند طرف ثالث. الاختيار الآمن لا يكتب ملف مساءلة، وملف المساءلة لا يختار القائمة التالية.

وتوصي RFC 8633 بتعدد المصادر والمراقبة، فيما تعرض RFC 7384 تهديدات الوقت واعتماد الشهادات عليه. لا تستخرج أي منها جهة استبعاد عالمية من الخوارزمية.

إيصال محمول لسحب الثقة

يقترح Daniel Kade إيصالًا محمولًا لسحب الثقة يوثق الجسر بعد انتهاء دور البروتوكول. ليس رسالة Roughtime جديدة ولا محكمة مركزية.

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

ثم يسجل حالة الإسناد: مفتاح معين، أو مجموعة مرشحين، أو تناقض غير محسوم. ويسمي المراجع المخول وتعارض المصالح والدليل الخارجي والسبب والثقة والمدة.

ويفصل الإجراء: حجر أو خفض وزن أو حذف أو إعادة. تربط تجزئتا القائمة القديمة والجديدة وتسلسلهما وتوقيعهما ووقت النفاذ الانتقال بعضه ببعض. ينتهي الإجراء المؤقت ما لم يُجدَّد على أساس معلن.

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

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

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

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

المصادر