تشفير النص مرة واحدة لا يلغي تكلفة توزيع المفاتيح وإيصال الرسالة إلى جميع الأعضاء.
في بنية «مفتاح المُرسِل» أو Sender Key، لا يحتاج المُرسِل إلى تشفير النص نفسه بصورة منفصلة لكل عضو في المجموعة. لكل مُرسِل سلسلة مفاتيح خاصة به، ويُوصل المفتاح اللازم لقراءة رسائله إلى الأعضاء المخوّلين عبر مسار آمن. يقلّل هذا الأسلوب تكلفة تشفير النص، لكن تكاليف توزيع المفاتيح وإيصال الرسائل وإدارة العضوية تبقى قائمة.
كيف تصف Livara بروتوكول LGS1؟
وفقًا لـوثائق أمان Livara، يستخدم LGS1 سلسلة ومفتاح توقيع منفصلين لكل مُرسِل لرسائل المجموعات الخاصة المتوافقة التي تعمل بوضع E2EE. تُوزَّع مفاتيح المُرسِلين عبر جلسات LVR1 الثنائية، ثم يُشتق مفتاح رسالة لكل موضع في السلسلة. وتصف الوثائق أيضًا تدوير المفاتيح بعد انضمام الأعضاء أو مغادرتهم. هذا وصف لبنية المنتج، وليس نتيجة اختبار أداء أو تدقيق مستقل أجراه هذا المقال.
مسار رسالة المجموعة خطوة بخطوة
- تهيئة الأعضاء: يجب على الجهاز التحقق من الهوية التشفيرية للمستلمين ومن عضويتهم المخوّلة.
- توزيع مفتاح المُرسِل: تصل المعلومات اللازمة إلى الأعضاء عبر جلسات خاصة. هذه المرحلة ليست بلا تكلفة في المجموعة الكبيرة، ولا مستقلة عن عدد الأعضاء.
- اشتقاق مفتاح الرسالة: تتقدم السلسلة حتى لا تُشفَّر النصوص المختلفة بمفتاح الرسالة نفسه.
- التشفير والتحقق من الأصالة: يُشفَّر النص، ويجب على المستلم التحقق من أصالة الرسالة وهوية المُرسِل.
- تغيّر العضوية: يجب ألا تتاح مفاتيح الحقبة التالية إلا للأعضاء المخوّلين المتبقّين.
لا ينبغي مساواة «مفتاح المُرسِل» بالاستخدام الدائم لمفتاح AES واحد لجميع الرسائل. حالة السلسلة ورقم الرسالة وحقبة المفتاح أجزاء من التصميم الآمن.
أي تكلفة تنخفض وأيها تبقى؟
| جزء العمل | أثر بنية مفتاح المُرسِل |
|---|---|
| تشفير محتوى رسالة عادية | يمكن إجراؤه مرة واحدة بدلًا من إنشاء نسخة مشفّرة منفصلة لكل مستلم |
| توزيع المفتاح الأولي أو مفتاح جديد | يجب أن يشمل الأعضاء المخوّلين؛ وعدد الأعضاء والأجهزة مهم |
| الإرسال عبر الشبكة إلى جميع الأعضاء | يظل بحاجة إلى إيصال البيانات إلى المستلمين |
| مغادرة عضو وجهاز غير متصل | يحتاجان إلى إدارة الحقب والتنسيق وسلوك واضح عند الأخطاء |
لذلك فإن عبارة «تنخفض التكلفة الكلية للمجموعة من O(N) إلى O(1)» غير دقيقة. يمكن الحديث عن عملية محددة، لا عن الشبكة كلها. كما ينبغي قياس السرعة واستهلاك البطارية والبيانات على إصدار محدد من التطبيق، وعدد محدد من الأعضاء، وأجهزة محددة.
أين تدخل الحماية ما بعد الكمية؟
تربط Livara توزيع مفاتيح المجموعة بجلسات LVR1 الهجينة. وجود مكوّن ما بعد كمي لا يثبت وحده جميع خصائص المجموعة؛ فدمج المفاتيح والتوقيعات وحفظ الحالة والتحقق من العضوية مهمة أيضًا. اعتماد خوارزمية معيارية يختلف عن إقرار أمان تطبيق مراسلة كامل.
ولمقارنة البنى، تُعد RFC 9420 الخاصة بـ MLS مثالًا على مواصفات رسمية لإدارة مفاتيح المجموعات. لا ينبغي تقديم LGS1 بوصفه MLS نفسه أو تنفيذًا له؛ بل يجب استقاء ضمانات كل منهما من مواصفات ذلك البروتوكول وأدلته الخاصة.
ما الذي ينبغي التحقق منه قبل الوثوق بمجموعة خاصة؟
- هل تعمل المجموعة نفسها فعلًا بوضع التشفير من طرف إلى طرف؟ تقول وثائق Livara إن المجموعة القديمة غير المتوافقة لا ينبغي أن تحمل وصفًا بالتشفير بلا مبرر.
- من يستطيع إضافة عضو، وكيف يُبلَّغ الأعضاء بالتغيير؟
- هل يستطيع العضو الجديد الوصول إلى السجل السابق أم إلى الرسائل المستقبلية فقط؟ تحقّق من الإجابة في إصدار التطبيق نفسه.
- هل تتغير حقبة المفتاح بعد إزالة عضو؟ الإزالة من القائمة وحدها ليست دليلًا على استبدال المفتاح.
- هل يستطيع الأعضاء الحاليون نسخ الرسالة؟ نعم؛ فالتشفير لا يلغي الحاجة إلى الثقة بالمستلم.
أسئلة شائعة
هل تؤدي إزالة العضو إلى محو رسائله القديمة؟
لا. يهدف تدوير المفاتيح إلى تقييد الوصول المستقبلي؛ أما النسخة التي استُلمت أو حُفظت سابقًا فلا تختفي بالضرورة من جهاز العضو المُزال.
هل يُوصل LGS1 الرسالة عند انقطاع الشبكة تمامًا؟
التشفير لا ينشئ مسار اتصال. يتطلب إيصال الرسائل وصول الأجهزة إلى الخدمة وإلى مسار الشبكة؛ افصل أمان المحتوى عن التوافر.
هل يعني ذلك أن الخادم لا يملك أي معلومات عن المجموعة؟
وفقًا لـالحدود المعلنة لدى Livara، لا تعني سرية المحتوى إخفاء جميع المعلومات التشغيلية. عند اختيار المجموعة، اقرأ أيضًا سياسة العضوية والبيانات الوصفية.
