SHARE THE PERSPECTIVE
نسخة القرص والتحكم المباشر بالخادم والوصول إلى الهاتف ثلاثة سيناريوهات مختلفة؛ لا يكفي ضمان عام واحد لتغطيتها جميعًا.

إذا جرى الاستيلاء على خادم تطبيق مراسلة، فإن الإجابة الدقيقة عن سؤال «ما الذي ينكشف؟» تعتمد على البيانات المخزّنة ومكان المفاتيح ونوع وصول المهاجم. الحصول على نسخة من القرص ليس مثل التحكم المباشر بالخدمة ومسار توزيع التطبيق.

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

لنحدّد أولًا نوع الوصول

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

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

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

ما البيانات التي تظهر على الخادم وفق وثائق ليفارا؟

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

فئة البيانات الحدّ الموثّق والنتيجة المحتملة
النص والمرفقات في المحادثة المحمية يحتفظ الخادم بنسخة مشفّرة؛ وقراءتها تتطلب المفتاح المناسب
البيانات الوصفية للاتصال تتاح للخدمة معلومات مثل الأطراف والوقت والحجم وحالة التسليم
عضوية المجموعة جزء من المعلومات والصلاحيات التشغيلية للخادم
القناة العامة محتواها عام وقابل للقراءة من جانب الخادم
حزمة استعادة الهوية v7 تُشفّر قبل رفعها وتتطلب سرّ استعادة منفصلًا
وضع التسجيل الاختياري على الخادم يتميّز بعلامة REC عن وضع E2EE، ولا ينبغي افتراض خصوصية من طرف إلى طرف فيه

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

يصف هذا الجدول ادعاءات المنتج، وليس نتيجة اختبار مصادرة حقيقية أو تدقيق مستقل في جميع نسخ قاعدة البيانات.

ما مدى أهمية البيانات الوصفية؟

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

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

ما خطر التحكم بالخادم على الرسائل المقبلة؟

ينبغي في المراجعة الأمنية اختبار التلاعب بقائمة الأعضاء وتقديم مفتاح هوية مختلف ومنع التحديثات وتوزيع تطبيق عميل خبيث، كلٌّ على حدة. يعتمد أثر كل منها على التحقق من جانب العميل وإظهار التغييرات وتأكيد الهوية.

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

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

ماذا تضيف مقاومة الحوسبة الكمومية؟

يساعد معيار NIST FIPS 203 الخاص بـ ML-KEM على إنشاء سرّ مشترك. ويمكن لاستخدامه الصحيح ضمن تركيب هجين أن يقلّل خطر بعض الهجمات المستقبلية على تبادل المفاتيح. لكنه لا يحلّ محل أمان الجهاز أو الاحتفاظ المحدود بالبيانات الوصفية أو التحكم في الوصول إلى الخادم.

ولا يعرض Proof Lab سوى بعض العمليات المحلية لـ P-256 وHKDF وAES-GCM، ويستثني التركيب الكامل لـ LVR1/LGS1 من ذلك الاختبار. نجاحه لا يضمن مقاومة المنتج بأكمله للاستيلاء على البنية التحتية.

ماذا نفعل في تقييم أو حادث فعلي؟

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

يجب أن تحدّد النتيجة الموثوقة أي بيانات حُميت، وفي أي إصدار، وفي مواجهة أي نوع من الوصول. عبارة «لن يحدث شيء حتى لو صودر الخادم» لا تقوم مقام هذه الإجابة.

اقرأ نموذج التهديدات في ليفارا
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗