تغيّر مرحلة المفتاح في QUIC يثبت نجاح المفاتيح الجديدة لا سبب تغييرها

Summary

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

تسجل لوحة المراقبة انقلاب مرحلة المفتاح أثناء نشر برمجي، فتصفه قناة الحادث فوراً بأنه تدوير أمني. تزامن الوقت يستحق الفحص، لكن البت نفسه لا يحمل هذا التفسير.

تمنح الفقرة 6 من RFC 9001 بت Key Phase وظيفة محددة: بيان أي جيل من مفاتيح حماية الحزم استُخدم لحزمة 1-RTT. يبدأ بصفر وينقلب مع كل تحديث. يستخدم QUIC آليته الخاصة بدلاً من رسالة TLS KeyUpdate. تحدد الإشارة أي مفاتيح ينبغي أن تعمل، لا القرار التشغيلي وراء استخدامها.

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

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

تشرح الفقرة 6.3 والفقرة 6.5 سبب الاحتفاظ المؤقت بالمفاتيح الحالية والتالية، وأحياناً السابقة، مع تفادي إشارات التوقيت. قد يفرض بت مزور عملاً حسابياً؛ وفشل فك الحماية لا يثبت تحديثاً مشروعاً ولا هجوماً.

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