لا تسأل فقط إن كانت المكالمة مشفرة؛ اسأل أين ينتهي التشفير وما الذي يغيّره التسجيل.
لا يثبت تشفير الدردشة وحده أن الصوت أو الفيديو أو مشاركة الشاشة أو تسجيل المكالمة يحظى بالحماية نفسها. لتقييم المكالمات، عليك أن تسأل: إلى أين تظل الوسائط مشفرة، ومن يملك المفتاح، وما الذي يتغير عند تفعيل ميزات مثل التسجيل؟
يقسّم هذا الدليل الادعاءات الأمنية إلى طبقات يمكن فحصها؛ فلا يحل اسم بروتوكول أو رمز قفل محل الإجابة عن هذه الأسئلة.
ثلاثة مسارات مختلفة داخل تطبيق واحد
| المسار | أمثلة على البيانات | السؤال الأمني |
|---|---|---|
| الرسائل المخزّنة | النص والصور والملفات والملاحظات الصوتية | من يستطيع قراءة النسخ الموجودة على الجهاز والخادم وفي النسخ الاحتياطية؟ |
| الوسائط المباشرة | صوت الميكروفون والفيديو ومشاركة الشاشة | هل ينتهي التشفير على جهاز الطرف الآخر أم على خادم وسيط؟ |
| الإشارات | دعوة المكالمة والرد ومعلومات تنسيق الاتصال | من يستطيع تغيير رسائل التحكم أو هوية الطرف المقصود؟ |
الملاحظة الصوتية المرسلة في الدردشة ملف، أما المكالمة الصوتية فهي تدفق مباشر. وقد يستخدم المنتج مفاتيح وآليات مختلفة لكل منهما. كذلك لا تدل جودة الصوت الجيدة أو عدم وصول رسالة نصية، بحد ذاتهما، على أمان المسار الآخر.
ما الذي يوضحه DTLS-SRTP؟
في WebRTC، يحمي SRTP تدفق الوسائط، ويوفر DTLS-SRTP طريقة لإنشاء مواد المفاتيح الخاصة به. يشرح RFC 5764 آلية DTLS-SRTP، ويشرح RFC 3711 حماية حزم الوسائط.
لكن عبارة «نستخدم WebRTC» لا تجيب وحدها عما إذا كان خادم المؤتمرات يفك تشفير الوسائط أم لا. يجب توضيح نقاط نهاية التشفير وكيفية التحقق من هويتها. قد يكون الاتصال بين المستخدم والخادم مشفراً، بينما يستطيع الخادم الوصول إلى المحتوى بعد فك تشفيره لمعالجته أو تسجيله. وهذا ليس هو E2EE بين المشاركين.
توضح بنية أمان WebRTC في RFC 8827 أيضاً أهمية الثقة بتطبيق الويب ومسار الإشارات وهوية الطرف الآخر، إلى جانب حماية الوسائط. تشفير الحزم لا يعني أن كل مكونات المنتج جديرة بالثقة.
لماذا يجب تقييم الإشارات بصورة منفصلة؟
تنسّق الإشارات من يتصل بمن وكيف يُنشأ الاتصال. حتى إذا كان التطبيق يحمي رسائل التحكم، فلا بد من فحص كيفية ارتباط هذه الحماية بالهوية الفعلية للمشاركين وبمفاتيح الوسائط.
عند قراءة الوثائق، تكفي ثلاثة أسئلة:
- هل تُحمى الدعوات والردود ومعلومات المفاتيح من التعديل؟
- كيف يعرف المستخدم أن المفتاح يعود إلى الشخص الذي يقصد الاتصال به؟
- ما التحذير الذي يظهر عند تغير المفتاح أو الجهاز؟
قد يعرف مزود الخدمة معلومات التوجيه والتوقيت والمشاركين حتى في مكالمة E2EE. يتناول شرح البيانات الوصفية في المراسلة هذا الفرق.
تسجيل المكالمة ينشئ حدوداً أمنية جديدة
لا تقدم عبارة «مكالمة مشفرة» إجابة كاملة عن النسخة المسجلة. يستطيع أحد المشاركين تسجيل الصوت أو الفيديو بجهازه. ويجب كذلك توثيق التسجيل على الخادم بصورة منفصلة: هل يحصل الخادم على وسائط مقروءة كي يسجلها؟ ومن يحتفظ بالملف؟ ومتى يُحذف؟
إذا كان تفعيل التسجيل يغيّر الوضع الأمني، فيجب أن يكون هذا التغيير واضحاً للمشاركين. قبل محادثة حساسة، تحقق من حالة التسجيل ومن موافقة الأشخاص؛ فعدم ظهور مؤشر التسجيل المدمج لا يضمن أن أحداً لا يسجل بوسيلة أخرى.
كيف نقرأ وثائق ليفارا الحالية؟
تصف صفحة أمان ليفارا المكالمات المباشرة والجماعية بأنها E2EE، لكنها تستثني التسجيل الاختياري على الخادم: في وضع REC الظاهر للمشاركين، تتغير حماية المكالمة إلى تشفير النقل. هذا ادعاء في وثائق المنتج، وليس نتيجة اختبار أو تدقيق مستقل أجراه هذا المقال.
تقييد جميع المكالمات الجماعية بـ«شخصين إلى ستة أشخاص على أندرويد» في النص القديم لا يتفق مع الوثائق الحالية، ولا يعتمد عليه هذا الدليل. لمعرفة السعة والمنصة والإصدار المعني، يجب مراجعة الدليل الحالي والسلوك الفعلي للتطبيق؛ ولا يقدم هذا المقال اختباراً للسعة.
كذلك لا تثبت أسماء خوارزميات الدردشة مثل ML-KEM وحدها استخدام الخوارزمية نفسها لوسائط المكالمة. يتطلب الادعاء بأن المكالمة مقاومة للحوسبة الكمية أدلة تخص مسار الوسائط والتحقق من الهوية. اقرأ نموذج تهديدات ليفارا إلى جانب صفحة الميزات، لا بوصفه بديلاً عن الاختبار المستقل.
قائمة قصيرة قبل مقارنة خدمتين
لكل إجابة بـ«نعم»، دوّن أيضاً اسم الإصدار والمصدر:
- هل تُوصف المكالمات الثنائية والجماعية ومشاركة الشاشة كلٌّ على حدة؟
- هل يتضح إن كان الخادم ينقل الحزم فقط أم يستطيع فك تشفير الوسائط؟
- هل يمكن التحقق من هوية المشارك ومفتاحه؟
- هل تظهر بوضوح تغييرات الجهاز وإضافة المشاركين وتفعيل التسجيل؟
- هل مسار المكالمة واحد في الويب والتطبيق أم توجد اختلافات؟
- هل يُشرح الاحتفاظ بملف التسجيل والبيانات الوصفية؟
- هل تتعلق أدلة الاختبار أو التدقيق بالإصدار والميزة نفسيهما؟
إذا لم تجد الإجابة في الوثائق، فاكتب «غير معروف»؛ غياب الإجابة ليس إثباتاً للأمان ولا إثباتاً للتنصت.
الأسئلة الشائعة
هل تمنع مكالمة E2EE الطرف الآخر من التسجيل؟
لا. يستطيع المستلم المصرح له الوصول إلى المحتوى المقروء، وقد يسجله بأداة برمجية أو بجهاز آخر.
هل تشفير النقل سيئ؟
يوفر تشفير النقل حماية مهمة من التنصت على مسار الاتصال. الفرق أن الخدمة التي تمثل نقطة النهاية تستطيع الوصول إلى المحتوى بعد فك تشفيره؛ ولا ينبغي تسمية ذلك E2EE بين المستخدمين.
هل يجعل استخدام تشفير مقاوم للحوسبة الكمية في الدردشة المكالمة مقاومة لها أيضاً؟
لا. يجب أن يتعلق الادعاء بالطبقة والخوارزميات وإصدار التنفيذ المعني. قيّم الدردشة والمكالمة كلّاً على حدة.
