مرونة التشفير هي القدرة على نقل بروتوكول من مجموعة تشفير إلى أخرى دون فقدان التزامات أمنية واضحة. وفي المراسلة، يعني ذلك أكثر من إضافة اسم خوارزمية جديدة. فالعملاء القدامى، والمستلمون غير المتصلين، والرسائل المخزنة، والأجهزة المرتبطة، يجب أن تتصرف جميعها بطريقة يمكن التنبؤ بها أثناء الانتقال.
تصف وثيقة RFC 7696 الصادرة عن IETF مرونة الخوارزميات بأنها مسألة انتقال تشمل المعرّفات والتنفيذات والتغييرات التشغيلية. يساعد رقم الإصدار على تحديد ما يُستخدم، لكنه لا يجعل الانتقال آمنًا بمفرده.
ثلاثة إصدارات يسهل الخلط بينها
قد يكون لتطبيق المراسلة إصدار للتطبيق وإصدار لبروتوكول الاتصال ومعرّف لمجموعة التشفير. وهي تجيب عن أسئلة مختلفة:
| المعرّف | ما يوضحه للمراجع | ما لا يثبته |
|---|---|---|
| إصدار التطبيق | أي بناء من البرنامج مثبت | أن كل محادثة تستخدم أحدث بروتوكول |
| إصدار البروتوكول | صيغة الرسائل وقواعد الحالة التي تنطبق | أن التنفيذ يتبع تلك القواعد بشكل صحيح |
| معرّف الخوارزمية أو المجموعة | مكونات التشفير المختارة | أن التفاوض لا يمكن خفض مستواه |
ينبغي أن توضح ملاحظات الإصدار العلاقة بينها صراحةً. فعبارة «طُرح تشفير جديد» مبهمة إذا كانت المحادثات المنشأة حديثًا وحدها تستخدمه، أو إذا كان عميل مرتبط أقدم يؤدي إلى الرجوع إلى وضع سابق.
ما الذي يجب أن يحدده الانتقال الآمن
ابدأ بسيناريو محدد: تحدّث أليس تطبيقها اليوم، بينما يظل بوب غير متصل على هاتف أقدم. ترسل أليس رسالة ثم تضيف جهازًا ثانيًا لاحقًا. ما الذي ينبغي لكل جهاز قبوله وتخزينه وعرضه؟
يجيب التصميم القابل للمراجعة عن هذه الأسئلة على الأقل:
- كيف يعرف كل طرف الإصدارات التي يدعمها الطرف الآخر؟
- هل يجري التحقق من أصالة الإصدار المختار بوصفه جزءًا من الجلسة؟
- ماذا يحدث عندما لا يوجد إصدار مقبول مشترك؟
- هل يستطيع وسيط ترحيل خبيث حذف معلومات عن إحدى القدرات والتسبب في استخدام وضع أضعف؟
- هل تظل الرسائل القديمة قابلة للقراءة، وأي مفاتيح قديمة تبقى ضرورية؟
- هل تؤدي استعادة نسخة احتياطية إلى إحياء حالة بروتوكول متقادمة؟
- متى ستُعطَّل الخوارزميات المهجورة بدلًا من الاكتفاء بعدم التشجيع على استخدامها؟
غالبًا ما يكون الإخفاق الظاهر أكثر أمانًا من الانتقال الصامت إلى وضع لم يقصده المستخدم. لكن ينبغي توثيق سلوك الإخفاق والاستعادة بدقة، حتى لا يتحايل الناس على المشكلة بالانتقال إلى قناة غير محمية.
مصفوفة عملية لاختبار الترقية
تحتاج الترقية الأمنية إلى أكثر من محادثة ناجحة بين تثبيتين جديدين. اختبر هذه الحالات باستخدام بيانات غير حساسة:
| الاختبار | الأدلة المطلوب تسجيلها |
|---|---|
| عميل جديد يتواصل مع عميل قديم | البروتوكول المختار أو نتيجة واضحة لعدم التوافق |
| المستلم غير متصل أثناء الترقية | سلوك التسليم وفك التشفير بعد إعادة الاتصال |
| عودة جهاز مرتبط قديم | ما إذا كان يستطيع القراءة أو الإرسال أو فرض وضع غير متوقع |
| إضافة عضو غير متوافق إلى مجموعة | سياسة المجموعة الصريحة والحالة التي يراها المستخدم |
| استعادة نسخة احتياطية بعد إيقاف آلية قديمة | ما إذا كانت الحالة غير المدعومة تُرفض أم تُرحَّل |
| العبث ببيانات الإصدار الوصفية | فشل التحقق من الأصالة بدلًا من خفض مستوى لا يُلاحظ |
هذه معايير تقييم، وليست ادعاءات بأن منتجًا محددًا اجتاز الاختبارات. احتفظ بمعرّفات البناء والنتائج المرصودة حتى يمكن التمييز بين تراجع لاحق في السلوك وتغيير في التوثيق.
كيفية فهم أسماء بروتوكولات Livara
تستخدم Livara في توثيقها الأمني اسم LVR1 للدردشات المباشرة واسم LGS1 للمجموعات الخاصة. تميز هذه الأسماء بين المسؤوليات؛ ولا ينبغي قراءتها بوصفها دليلًا على توحيد معياري مستقل أو تدقيق مستقل. وتناقش الصفحة أيضًا سلوك العملاء أو المجموعات التي لا تستطيع استيفاء متطلبات الوضع المشفر.
الأدلة المفيدة التالية ستكون مواصفات ذات إصدارات، ومتجهات اختبار، وقواعد توافق، ونتائج مراجعة مرتبطة بإصدار معين. ويوضح Proof Lab صراحةً أن نطاق عرضه أضيق. فتشغيل اللبنات الأساسية للتشفير داخل متصفح ليس هو نفسه اختبار كل مسار انتقال داخل التطبيق.
ما الذي ينبغي للمستخدمين فعله أثناء ترقية التشفير
حافظ على تحديث العملاء المدعومين، واقرأ الإشعارات الأمنية المتعلقة بتوافق الأجهزة، وانتبه إلى تغيّر مؤشرات الهوية أو حالة التشفير. لا تفترض أن أيقونة تطبيق جديدة تعني أن كل مجموعة قديمة ونسخة احتياطية قديمة حصلت على حماية جديدة. إذا لم يستطع المنتج توضيح البيانات التي تغيرت حمايتها، فاسأل قبل مشاركة مواد حساسة.
مرونة التشفير الجيدة تجعل التغيير قابلًا للفحص. فهي تحدد ما الذي تغير، وكيف يتفق طرفا الاتصال عليه، وما الذي قد يحدث على نحو خاطئ، ومتى تتوقف الآلية القديمة عن أن تكون مقبولة.
