الجواب القصير
ويعني التشفير الشامل الذي تم تنفيذه بشكل صحيح أن محتوى الرسالة مشفر على جهاز المرسل ولا يمكن فك تشفيره إلا من خلال نقاط النهاية المتلقية المقصودة. يجب أن تتعامل خدمة التسليم مع النص المشفر، وليس النص العادي أو مفاتيح المحادثة. لكن E2EE يحمي المسار بين نقاط النهاية - فهو لا يجعل نقطة النهاية أو المستلم أو كل جزء من بيانات التعريف أو كل نسخة احتياطية جديرة بالثقة.
ما يعنيه "النهاية إلى النهاية" في الواقع
نقاط النهاية هي الأجهزة أو مثيلات التطبيق التي تحتوي على المفاتيح اللازمة لقراءة المحادثة. يحدث التشفير قبل أن تغادر الرسالة نقطة نهاية المرسل؛ يحدث فك التشفير بعد وصوله إلى نقطة نهاية الاستلام المعتمدة.
هذه الحدود مهمة. تشفير النقل مثل TLS يحمي الاتصال بين الجهاز والخادم. يضيف التشفير من طرف إلى طرف حدًا منفصلاً على مستوى الرسالة يهدف إلى منع الوسيط من استلام مفاتيح النص العادي. يصف معيار أمان طبقة المراسلة الخاص بـ IETF الهدف بأنه جعل الرسائل قابلة للوصول إلى نقاط نهاية الاتصال بدلاً من الخوادم التي تقوم بتوصيلها.
ملصق المنتج وحده ليس دليلاً. تؤثر مصادقة الهوية وإدارة المفاتيح وتغييرات عضوية المجموعة وحذف المفتاح القديم وجودة التنفيذ وسلوك النسخ الاحتياطية على نتيجة الأمان الحقيقية.
ما تم تصميم E2EE لحمايته
تعتمد الضمانات الدقيقة على البروتوكول والتنفيذ، ولكن الهدف من E2EE الحديث والموثق هو معالجة هذه المخاطر:
اعتراض الشبكة
يجب على أي شخص يراقب Wi-Fi أو مزود خدمة الإنترنت أو شبكة وسيطة أن يرى حركة المرور المشفرة بدلاً من محتوى الرسالة القابلة للقراءة.
مقدم خدمة فضولي
يجب ألا تتمكن خدمة التسليم التي لا تحتوي على مفاتيح المحادثة من فتح النص المشفر للرسالة العادية.
حل وسط لخادم التسليم
يمكن أن يحافظ التشفير على مستوى الرسالة على سرية المحتوى حتى في حالة تعرض توجيه البنية التحتية أو وضع النص المشفر في قائمة الانتظار مؤقتًا للخطر.
تغييرات الرسالة غير المكتشفة
يمكن أن يسمح التشفير المعتمد للمستلمين برفض النص المشفر الذي تم تغييره أو تزويره، مع مراعاة مصادقة المفتاح الصحيح وتنفيذه.
بعض التعرض للرسالة الماضية
تقوم البروتوكولات ذات السرية الأمامية بحذف مواد المفتاح القديم أو تطويرها بحيث لا يكشف حل وسط رئيسي لاحق عن جميع الرسائل السابقة تلقائيًا. هذه خاصية بروتوكول إضافية، وليست مرادفة لـ E2EE.
ما لا يحميه E2EE تلقائيًا
تبدأ معظم حالات سوء الفهم الأمني عندما يتم التعامل مع حماية محتوى الرسالة على أنها حماية لنظام الاتصال بأكمله.
نقطة نهاية مخترقة أو غير مقفلة
قد تواجه البرامج الضارة والجهاز المسروق غير المؤمن ومعاينات الإشعارات ولقطات الشاشة ولوحات المفاتيح وخدمات إمكانية الوصول نصًا عاديًا قبل التشفير أو بعد فك التشفير.
الشخص الذي يتلقى الرسالة
يمكن للمستلم المعتمد نسخ أو تصوير أو اقتباس أو إعادة توجيه ما يمكنه قراءته بشكل قانوني. يؤدي اختفاء عناصر التحكم إلى تقليل السجل المحتفظ به؛ لا يمكنهم جعل المتلقي المعادي ينسى.
جميع البيانات الوصفية
يمكن أن يكشف التسليم عن التوقيت أو حجم حركة المرور أو عناوين IP أو الوجهات أو الرموز المميزة للجهاز أو عمليات المجموعة. يمكن للبروتوكولات والبنيات أن تقلل أو تحمي أجزاء من هذه البيانات التعريفية، لكن تشفير المحتوى وحده لا يزيلها.
النسخ الاحتياطية والصادرات غير المشفرة
إذا تم نسخ محفوظات النص العادي أو المفاتيح القابلة للاسترداد إلى نظام آخر، فإن تلك النسخة لها حدود الأمان الخاصة بها. "الدردشة E2EE" لا تثبت أن كل نسخة احتياطية موجودة.
من هو حقا في الطرف الآخر
يمكن أن يؤدي التشفير باستخدام المفتاح الخطأ أو المستبدل إلى إنشاء محادثة مشفرة تمامًا مع الطرف الخطأ. يظل التحقق من المفاتيح وربط الهوية الجديرة بالثقة أمرًا مهمًا.
التوفر والإكراه
لا يزال بإمكان الخدمة تأخير حركة المرور المشفرة أو حظرها أو تحديد معدلها أو حذفها. لا يمكن لـ E2EE أيضًا منع أي شخص من إجباره على فتح نقطة النهاية أو الكشف عما يعرفه.
نموذج التهديد: هل يساعد E2EE؟
هناك سؤال أمني مفيد يسمي الخصم بدلاً من السؤال عما إذا كان التطبيق "مشفراً" ببساطة.
| سيناريو | هل يحمي E2EE المحتوى؟ | ما يهم آخر |
|---|---|---|
| مراقب الشبكة يعترض حركة المرور | عادة نعم | بروتوكول قوي، وتنفيذ آمن، وحدود تحليل حركة المرور |
| تم اختراق خادم التسليم | عادة نعم | يجب أن تظل المفاتيح على نقاط النهاية المعتمدة؛ قد تظل البيانات الوصفية مرئية |
| يتم سرقة الهاتف أثناء فتحه | لا | قفل الجهاز، حماية التخزين المحلي، سياسة الإخطار، الاحتفاظ القصير |
| يقوم المستلم بتسجيل الرسالة عن قصد | لا | الثقة، السياسة، العلامة المائية، الإفصاح المحدود، الضوابط القانونية |
| يستبدل المهاجم مفتاح الهوية | ليس في حد ذاته | التحقق من المفاتيح، والشفافية، والمصادقة، وتغيير التحذيرات |
| الخدمة ترفض تسليم الرسائل | لا | تصميم التوفر والمراقبة وخطة الاتصال البديلة |
كيف يتعامل City of Hats مع هذه الحدود
يتعامل City of Hats مع E2EE كطبقة واحدة في نموذج التهديد الأوسع. تصف البيانات الواردة أدناه بنيتنا المنشورة وسلوك المنتج؛ فهي ليست ادعاءً بأن البرنامج يمكنه القضاء على مخاطر نقطة النهاية أو سلوك المستلم.
التشفير على مستوى الرسالة
يقوم City of Hats بتوثيق E2EE من جانب العميل لرسائل وملفات ومكالمات Hat-to-Hat، باستخدام إنشاء مفتاح X25519 وML-KEM-768 المختلط مع Double Ratchet وAES-256-GCM. تهدف مفاتيح فك تشفير المحادثة إلى البقاء على الأجهزة المعتمدة.
الشفافية التقنية →هوية تسجيل أقل
يمكن إنشاء Hat بدون رقم هاتف أو بريد إلكتروني. تعمل Phrase IDs وHats المتعددة وHats التي يمكن التخلص منها على تقليل الحاجة إلى ربط كل سياق اتصال بهوية ناقل واحد أو صندوق بريد واحد. ولا تجعل الجهاز المخترق أو اتصال الشبكة مجهولاً.
Disposable Hats →ترحيل المكالمات المشفرة
تقوم مستندات City of Hats بنقل الصوت والفيديو حتى لا يتلقى المشارك الآخر عنوان IP مباشر من نظير إلى نظير. يتعامل الترحيل مع الوسائط المشفرة، بينما لا تزال البيانات التعريفية على مستوى الشبكة تتطلب نموذج تهديد واقعيًا.
مكالمات مشفرة →لا يوجد مسار لاستعادة المحادثة
تم تصميم برنامج المراسلة للمستهلك بدون مخزن استرداد الرسائل الذي يحتفظ به الموفر. قد يعني فقدان الجهاز الوحيد المعتمد فقدان سجل الرسائل. يؤدي ذلك إلى تحسين مقاومة متطلبات الاسترداد من جانب الخادم، ولكنه يعد بمثابة مقايضة متعمدة للتوفر.
الخصوصية ومعالجة البيانات →الضوابط بعد التسليم
View Once، وRecall، وGeoLock، وCertified Send، وChannel Seal، وأوضاع الأمان الأخرى يمكن أن تحد من الوصول العادي أو الاحتفاظ. تعمل عناصر التحكم هذه على تقليل التعرض؛ لا يمكنهم هزيمة مستلم معتمد باستخدام كاميرا ثانية أو نقطة نهاية معرضة للاختراق بالفعل.
أوضاع الأمان →سياقات الاتصال القابلة للحرق
يمكن حرق Hats والقنوات أو السماح لها بانتهاء صلاحيتها، لذا فإن الهوية طويلة الأمد وسجل المحادثات غير المحدود ليسا إلزاميين. ويؤدي التدمير إلى تقليص ما يبقى متاحًا لاحقًا؛ ولا يمكنه سحب المعلومات التي تم التقاطها بالفعل خارج النظام المحمي.
Channel Seal →كيفية تقييم رسول مشفر
لا تتوقف عند عبارة "التشفير الشامل". اسأل المزود أو وثائقه:
- ما هي أنواع الاتصالات التي تكون E2EE افتراضيًا - الرسائل والمجموعات والملفات والمكالمات وتفاعلات الأعمال؟
- أين يتم إنشاء المفاتيح وتخزينها وتدويرها ونسخها احتياطيًا وحذفها؟
- كيف يتم التحقق من مفاتيح الهوية، وماذا يحدث عندما يتغير المفتاح؟
- ما المحتوى والبيانات الوصفية التي يمكن للخدمة مراقبتها أو الاحتفاظ بها؟
- ماذا يحدث على جهاز مخترق أو مفقود أو مرتبط حديثًا؟
- هل يمكن للمستلمين تصدير المحتوى أو إعادة توجيهه أو التقاطه أو الاحتفاظ به بشكل دائم؟
- هل تتوفر مواصفات البروتوكول أو الكود المصدري أو عمليات التدقيق أو الأدلة الفنية القابلة للتكرار؟
- ما هي خصائص الأمان المستقلة عن E2EE، مثل السرية الأمامية، وأمان ما بعد الاختراق، ومقاومة بيانات التعريف، والتوفر؟
خلاصة القول
يعد التشفير الشامل أمرًا ضروريًا لأنه يمكنه إزالة خدمة التسليم والشبكة من مجموعة الأطراف الموثوقة بمحتوى الرسالة. إنه ليس نظام الخصوصية بأكمله. يعتمد الاتصال الآمن القوي أيضًا على نقاط النهاية والهوية وبيانات التعريف والاحتفاظ والاسترداد وسلوك المستلم والتوثيق الصادق للمقايضات.
المصادر الأولية ومزيد من القراءة
المعايير والمواد الفنية للطرف الأول المستخدمة في هذه المقالة. تم الوصول إليه في 9 أغسطس 2026.
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
ترتبط بيانات المنتج City of Hats بوثائقنا المنشورة ويجب تقييمها كمطالبات الطرف الأول حتى يتم التحقق منها بشكل مستقل.
← العودة إلى مركز المعرفة