حُذف العضو من السجل، لكن المفتاح أبقاه داخل الدائرة

الخلاصة

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

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

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

سلطة المالك وعمل الوكيل

ينشئ مالك قائمة المجموعة، GLO، القائمة ويختار إن كانت غير مُدارة أو مُدارة أو مغلقة، ويحدد قواعد العضوية وإعادة التوليد. أما وكيل قائمة المجموعة، GLA، فيؤدي وظائف إدارة القائمة والمفاتيح ويوقّع رسائل glKey التي تحمل مفاتيح تشفير المفاتيح المشتركة، KEK.

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

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

ستة حدود بدلاً من إشارة نجاح واحدة

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

عملياً توجد ست حالات يجب ألا تندمج: قبول أمر الحذف؛ نفاذ جيل عضوية لا يحتوي أي هوية للعضو؛ توليد مفاتيح لهذا الجيل؛ تسليمها لكل عضو مستمر مع إبقاء الفشل ظاهراً؛ انتقال المرسلين والمستلمين إلى الجيل الجديد؛ وإيقاف المفاتيح القديمة أو الموزعة سلفاً حيث يمكن فرض ذلك.

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

مخزون الاستمرارية هو مخزون صلاحيات مستقبلية

يحدد generationCounter عدد المفاتيح الموزعة أو الباقية قيد الاستخدام المستقبلي، فيما تحدد duration مدة صلاحية كل مفتاح. ويُوزع مفتاحان على الأقل في البداية حتى لا تتوقف المجموعة عند انتهاء الأول.

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

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

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

لا تكفي صحة التوقيع من دون سياق محفوظ

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

وينطبق الأمر على الحماية من الإعادة. لا تفيد nonce وsigningTime إلا إذا احتفظت الأطراف بحالة كافية للمقارنة مع الرسائل السابقة. قد تنحرف الساعات، وتحدد السياسة المحلية نافذة القبول، ويجب معالجة الرسائل التي تدعي زمناً مستقبلياً. الزمن الموقّع بلا ذاكرة ليس دليلاً على الجِدة.

لا تمحو الحدود الجديدة ما خرج قبلها

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

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

إيصال خروج يبيّن ما حدث فعلاً

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

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