قارن كلفة عملية محددة والأدلة على مواجهة تهديد محدد، لا مجرد رسم شجرة برسم لمفاتيح المرسلين.
ليست Messaging Layer Security (MLS) وLGS1 من Livara شهادتين قابلتين للتبادل لسلامة المحادثات الجماعية. MLS معيار بروتوكول من IETF؛ أما LGS1 فهو تصميم خاص بمنتج Livara وموثق من طرفها. وتتطلب المقارنة المنصفة الفصل بين البنية وأدلة التنفيذ والسلوك الذي يختبره المستخدمون فعلياً.
الفارق الأساسي هو حالة المجموعة المشتركة القائمة على شجرة، مقابل مفاتيح مرسلين توزَّع عبر جلسات ثنائية. ولا يكشف أي من الاسمين وحده ما إذا كان تطبيق معين يتعامل بطريقة صحيحة مع عضو مُزال أو جهاز ذي حالة قديمة أو مفتاح مخترق.
الاختلاف البنيوي
تحدد RFC 9420 بروتوكول MLS لإنشاء مفاتيح المجموعات بصورة غير متزامنة. ويستخدم شجرة تحديث متدرج وحقباً للمجموعة، مع السرية الأمامية والأمان بعد الاختراق وفق شروط معلنة. وتقلل بنيته الشجرية بعض تكاليف تحديث المفاتيح مع ازدياد حجم المجموعة.
تصف وثائق أمان Livara بروتوكول LGS1 بأنه سلسلة مرسل موقّعة لكل عضو، تُوزَّع عبر جلسات LVR1 ثنائية وتُدوَّر عند تغير العضوية. هذا ادعاء للمنتج، وليس دليلاً على توافق LGS1 مع MLS أو خضوعه للتحليل نفسه.
| السؤال | MLS | وثائق Livara LGS1 |
|---|---|---|
| البنية المشتركة | شجرة تحديث متدرج وحقب | سلاسل لكل مرسل |
| تحديث المفاتيح | تثبيت تغييرات حالة المجموعة في حقبة جديدة | توزيع مفاتيح مرسل جديدة على الأعضاء |
| وضع المواصفة | معيار IETF، وهو RFC9420 | وصف منشور خاص بالمنتج |
| ما الذي لا يزال يحتاج إلى تقييم؟ | الدمج في التطبيق والتنفيذ | المواصفة الكاملة والتنفيذ والأدلة المستقلة |
يصف هذا الجدول فئات تصميم، وليس اختبار أداء أو ترتيباً أمنياً.
ما الذي تعنيه «لوغاريتمي» وما الذي لا تعنيه؟
قد يستخدم تحديث تشفيري عدداً لوغاريتمياً من مكونات مسار الشجرة المشفرة دون أن يجعل كل العمل في النظام لوغاريتمياً. فلا تزال الرسائل بحاجة إلى التوزيع، ويحتفظ العملاء بالحالة، ويتوقف السلوك على بنية المجموعة والعمليات. وقد خلطت المقارنة القديمة «يحتاج MLS إلى O(log N) من الرسائل، بينما كل شيء أسرع في LGS1» بين تكاليف مختلفة ولم تقدم قياسات.
تتعامل بنية MLS في RFC 9750 مع خدمة التسليم بصورة منفصلة عن إنشاء المفاتيح التشفيري، وتناقش توزيع الرسائل وترتيب تغييرات المجموعة. وهذا الفصل مهم: فحسابات العميل، وبايتات عملية التثبيت، وإجمالي إرسال الخادم إلى المستلمين، وحركة إعادة الاتصال مقاييس مختلفة.
ينبغي أن يحدد تقرير الأداء المفيد ما يلي:
- حجم المجموعة وعدد الأجهزة لكل شخص؛
- هل العملية رسالة عادية أم إزالة عضو أم تحديث مفتاح أم إعادة اتصال؛
- البايتات التي يرسلها العميل المبادر مقابل إجمالي حركة التسليم؛
- الزمن المنقضي وطراز الجهاز وإصدار التنفيذ وظروف الشبكة؛
- كلفة التحديثات الفائتة وتغييرات العضوية المتكررة.
دون هذه التفاصيل، لا تثبت ادعاءات «ميلي ثانية» أو «كلفة منخفضة لإدارة الحالة» أو التفوق عند حجم معين للمجموعة.
إزالة عضو اختبار لدورة الحياة
إزالة المشرف لحساب ليست سوى جزء من القصة الأمنية. يجب أن يتفق العملاء على حالة العضوية الجديدة، ويستخدموا مفاتيح جديدة مناسبة، ويتجنبوا تسليمها إلى الأجهزة المستبعدة. وقد يحتفظ من يملك نصوصاً صريحة أو مفاتيح قديمة بإمكانية الوصول إلى محتوى قديم؛ فالإزالة لا تمحو نسخه.
في أي من النظامين، يسأل الاختبار المفيد: بعد اكتمال الإزالة، هل يستطيع الجهاز المُزال فك تشفير رسالة اختبار غير حساسة جديدة؟ هل يلحق العضو الذي كان غير متصل بالتحديثات بأمان؟ هل تُعالَج جميع أجهزة الحساب؟ هل تُظهر الواجهة الإخفاقات أو تغييرات العضوية؟
هذه أسئلة تقييم مقترحة، وليست نتائج اختبارات أُجريت هنا. ينبغي أن تنشر مقارنة المنتجات النتيجة المرصودة وإصدار الاختبار، لا أن تساوي بين نجاح نقرة المشرف والاستبعاد التشفيري.
السرية الأمامية والتعافي مشروطان
يتوقف استمرار حماية الرسائل القديمة بعد اختراق لاحق على إخراج المواد السرية القديمة من الخدمة. ويتوقف استرداد حماية الرسائل المستقبلية على إدماج أسرار جديدة بعد فقدان المهاجم إمكانية الوصول ذات الصلة. وفي MLS، تُعد معالجة تحديثات المجموعة جزءاً من التعافي؛ فمجرد إرسال تحديث لا يعني أن جميع الأعضاء طبقوه. راجع الاعتبارات الأمنية في RFC 9420.
في تصميم مفاتيح المرسلين، اسأل كيف تُستبدل الحالة المخترقة لكل مرسل وتُعاد توزيعها. لا ينبغي وصف سلسلة أحادية الاتجاه وحدها بأنها تتعافى تلقائياً من مهاجم يعرف حالتها الحالية. الحماية الثنائية المستخدمة عند إعادة التوزيع ذات صلة، لكنها لا تستبدل تحليلاً كاملاً على مستوى المجموعة.
ادعاءات ما بعد الكم تحتاج إلى حزمة تشفير ونطاق محددين
تستخدم حزم التشفير المحددة في RFC9420 الأساسي آليات مفاتيح عامة تقليدية. لكن MLS قابل للتوسعة، لذا ينبغي أن يحدد الادعاء المتعلق بتنفيذ معين حزمته وامتداداته الفعلية، لا أن يعلن أن جميع عمليات نشر MLS ستظل تقليدية إلى الأبد.
استخدام LGS1 الموثق لتوزيع هجين عبر LVR1 ادعاء مختلف عن ضمان ما بعد كمي خضع لتحليل مستقل لكل عملية جماعية. تضع FIPS 203 معيار ML-KEM؛ ولا تعتمد البروتوكول الجماعي الكامل الذي يدمجها. قيّم المصادقة وتغييرات العضوية واختراق المفاتيح والتنفيذ معاً، لا اسم KEM وحده.
ما الذي تطلبه قبل اتخاذ قرار بشأن المنتج؟
اطلب المواصفة الحالية للبروتوكول ومتجهات الاختبار والمراجعة المستقلة الخاصة بالإصدار، بما فيها النتائج التي لم تُعالج. ثم قارن متطلبات المنتج المعتادة: الأجهزة المدعومة وسلوك التحديث والتعافي وأدوار الإشراف والبيانات التي تحتفظ بها الخوادم.
تتناول بنية MLS صراحة خدمات التطبيقات وافتراضات الثقة فيها. وبالمثل، ينبغي قراءة نموذج تهديد Livara بجانب ادعاءات المنتج. لا يجعل التشفير المشاركين المصرح لهم جديرين بالثقة، ولا يمنع لقطات الشاشة، ولا يزيل كل أشكال البيانات الوصفية.
إذا غابت الأدلة، فسجّل «غير مثبت» بدلاً من وصف التصميم تلقائياً بأنه غير آمن أو متفوق. ينبغي أن يعكس القرار مخاطر مجموعتك وجودة الأدلة المتاحة.
أسئلة شائعة
هل LGS1 تنفيذ لـ MLS؟
تعرض الأوصاف المنشورة بنيتين مختلفتين. لا يعرّف هذا المقال LGS1 بوصفه تنفيذاً لـ MLS ولا يدّعي قابلية التشغيل البيني.
هل يتطلب MLS أن يكون جميع الأعضاء متصلين في الوقت نفسه؟
لا. الاستخدام غير المتزامن جزء من تصميمه. ومع ذلك تحتاج التطبيقات إلى سياسات للتحديثات المتأخرة والحالة القديمة والأعضاء الذين يبقون غير متصلين طويلاً.
هل يحسم توزيع المفاتيح ما بعد الكمي أمان المجموعة؟
لا. فهو يعالج جزءاً من إنشاء المفاتيح. ولا تزال الهوية والعضوية ودورة حياة المفاتيح وأمان نقاط النهاية والتنفيذ تحتاج إلى أدلة.
أي التصميمين أسرع؟
لا يتضمن هذا المقال اختبار أداء يثبت فائزاً. قِس العمليات وبيئة النشر التي تهم مجموعتك.
