تمامية الرسائل: هل يستطيع الخادم تغيير محادثة مشفرة؟

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

النقاط الأساسية

• يكشف التشفير الموثَّق العبث بالنص المشفر، لكنه لا يحتفظ بالضرورة بتاريخ التعديلات والحذف.
• وفق وثائق Livara التقنية، يحمي AES-256-GCM الرسائل الخاصة مع وسم توثيق؛ ويجب ألا تُفك الحزمة المتلاعب بها بوصفها حزمة صالحة.
• ينبغي أن يكون التعديل المصرح به حدثًا جديدًا مشفرًا من طرف إلى طرف، لا إعادة كتابة سرية للحزمة السابقة من الخادم.
• تساعد أرقام الأمان على فحص مفتاح الطرف الآخر، لا قياس صدقه أو الحجية القانونية للقطة الشاشة.
• في النزاعات الحساسة، احتفظ بالملف الأصلي والأوقات وحالة التعديل والأدلة المستقلة خارج سلسلة المحادثة أيضًا.

ما تمامية الرسائل في تطبيق المراسلة تحديدًا؟

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

الصورة مفاهيمية وتحمل تسميات توضيحية؛ وليست واجهة Livara الفعلية ولا نتيجة اختبار لرفض رسالة متلاعب بها.

وفق وثائق Livara التقنية، تُشفّر الرسائل المباشرة باستخدام LVR1 والمجموعات الخاصة المتوافقة باستخدام LGS1 من طرف إلى طرف. وبحسب صفحة أمن Livara، تبقى المجموعة القديمة غير المتوافقة خارج E2EE بصورة معلنة، ولا تُنشأ المجموعة الجديدة بوسم أنها مشفرة قبل جاهزية جميع الأعضاء. افحص حالة المحادثة نفسها. وتقول الوثائق إن LVR1 يستخدم ECDH P-256 وML-KEM-768 لاشتقاق مفتاح الرسالة. كون أحد المكونات معياريًا لا يعني اعتمادًا مستقلًا للتركيب أو المنتج بأكمله. ثم تستخدم Livara ‏AES-256-GCM لحماية المحتوى.

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

كشف العبث بالرسائل المشفرة وتشفير AES-256-GCM في المراسلة

ينشئ AES-GCM وسم توثيق إلى جانب تشفير المحتوى. وإذا تغير النص المشفر أو البيانات المشمولة بالتوثيق، فيجب أن يفشل فحص الوسم. يعرّف NIST SP 800-38D نمط GCM ويحذر من أن تكرار nonce مع المفتاح نفسه قد يضعف الأمن بشدة.

وفق مواصفات Livara التقنية، تستخدم الرسائل الخاصة AES-256-GCM. وإذا غيّر الخادم جزءًا من الحزمة المحمية، فلن يستطيع إنشاء وسم توثيق جديد دون مفتاح الرسالة؛ لذلك ينبغي ألا يقبل المستلم الحزمة باعتبارها سليمة. والإجابة المختصرة عن سؤال «هل يستطيع الخادم تغيير الرسالة؟» هي: يستطيع الخادم حذف البيانات أو حجزها أو حجبها أو تأخيرها، لكنه ينبغي ألا يستطيع إظهار المحتوى المتلاعب به بوصفه صالحًا.

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

هل يستطيع الخادم تغيير الرسالة أم أن التعديل أمر مختلف؟

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

وفق وثائق Livara، تُحمى التعديلات في المحادثة المباشرة تحت LVR1، وفي المجموعة الخاصة المتوافقة تحت LGS1. ولتقييم الواجهة، افحص هل يعرض التطبيق حالة «معدّلة»؛ ومع ذلك، لا يحتفظ التشفير وحده بالنسخة السابقة إلى الأبد على جميع الأجهزة.

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

ماذا يثبت توثيق رسائل الدردشة؟

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

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

مصادقة الحساب مسألة منفصلة أيضًا. ولا تحل أي آلية دخول، مهما بلغت قوتها، محل تمامية الرسالة أو فحص مفتاح جهة الاتصال أو أمن الجهاز.

تمامية المحتوى ليست ترتيب الرسائل أو حداثتها

قد تحمل حزمة قديمة وسم توثيق صالحًا. ويحتاج منع قبولها مجددًا إلى تصميم بروتوكول وعدادات ومعرّف جلسة وحفظ حالة المستلم؛ فـAES-GCM وحده ليس سجلًا لترتيب المحادثة كلها. وهذا الفرق مهم لتقييم هجمات إعادة الإرسال والرسائل المتأخرة والمزامنة بين أجهزة متعددة.

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

إذا كان نص الرسالة أو حالتها غير متوقعين

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

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

كيف نقيم ادعاء تمامية الرسائل في تطبيق مراسلة؟

لا تكتفِ بعبارة «مشفّر». اسأل:

• أي المحادثات والملفات مشفرة من طرف إلى طرف؟
• أي خوارزمية AEAD تستخدمها الخدمة؟
• كيف تُسجل التعديلات وعمليات الحذف وتُعرض؟
• كيف يكتشف المستخدم تغير مفتاح جهة الاتصال؟
• ما البيانات الوصفية أو المحتوى أو العضويات التي يتحكم فيها الخادم؟
• هل للمكالمات الضمانات نفسها المتاحة للرسائل؟
• هل خضع البروتوكول لتدقيق مستقل؟

تنشر Livara مواصفات وأدوات لفحص بعض ادعاءاتها، ويمكن لمستخدمي Android مقارنة المجموع الاختباري لملف APK باستخدام SHA-256 في Proof Lab لفحص التطبيق دون اتصال. ومع ذلك، لا تقدم هذه المقالة دليلًا على تدقيق مستقل للإصدار الحالي. يساعد نشر المواصفات ومتجهات الاختبار في الفحص، لكنه لا يحل محل التدقيق المستقل.

بالنسبة إلى المحادثات الخاصة، فإن ادعاء Livara الأساسي محدود وواضح: يجب أن يكشف AES-256-GCM العبث بالحزمة، ويجب تشفير التعديلات أيضًا. ولا يعني ذلك سجلًا غير قابل للتغيير أو حذفًا مؤكدًا لكل النسخ أو دليلًا قانونيًا تلقائيًا.

الأسئلة الشائعة

هل يستطيع مدير الخادم تغيير نص الرسالة المشفرة؟

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

هل يثبت وسم «معدّلة» ما كانت عليه النسخة السابقة؟

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

هل يضمن رقم الأمان أصالة جميع الرسائل؟

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

هل يمحو الحذف لدى الجميع الرسالة من كل مكان؟

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