المحتويات
البنية التقنية للتطبيق المحمول

البنية التقنية للتطبيق المحمول

تشرح هذه الصفحة كيف ينشئ تطبيق Crisis Connect المحمول الثقة، وينقل الرسائل والمكالمات مشفرة من طرف إلى طرف أثناء توفر الإنترنت، ويستمر عبر Bluetooth المباشر عند تعطل الشبكات، ويرقي المستجيبين إلى مسارات آمنة.

مفتوح المصدرemirhan-duman/Crisis-Connect
BLE + RFCOMM
مسار الحادث الافتراضي
Wi-Fi Aware + GATT
طبقات التوسعة المنضبطة
AES-GCM + ECDH
ملف ثقة آمن
Android 1.0.4 · iOS 1.1.0
إصدارات المتاجر العامة
Crisis Connect نظام اتصالات طوارئ يعمل محلياً أولاً. أثناء توفر الإنترنت يقدم مراسلة مشفرة من طرف إلى طرف ومكالمات صوتية ومرئية؛ وعندما تفشل أو تزدحم بنية الإنترنت والاتصالات الخلوية، يستمر التطبيق نفسه بالعمل عبر أجهزة الراديو قصيرة المدى للهواتف القريبة. يبقي أساس بنية Android مسار الحادث على Bluetooth محلياً، ويبني الطبقة المتصلة على مظاريف مشفرة من طرف إلى طرف، ولا يضيف طبقات التوسعة إلا عندما تسمح السياسة بذلك، ويعامل السحابة كمستوى تسليم وثقة لا يرى المحتوى النصي مطلقاً.

ملخص النظام

مسار الرسالة المحلي أولاً: تكتشف الأجهزة القريبة بعضها عبر Bluetooth، ثم تتبادل حمولات آمنة عبر نقل محلي من نقطة إلى نقطة دون الاعتماد على الإنترنت
الطبقة المتصلة: أثناء توفر الإنترنت تسافر الرسائل كمظاريف مشفرة من طرف إلى طرف، وتعمل المكالمات الفردية عبر WebRTC، وتصل تقارير SOS إلى لوحات الاستجابة المصرح بها
تهيئة ثقة صريحة: تُجهز جهات الاتصال المعروفة خارج النطاق بواسطة QR، بينما يرقي وضع الإنقاذ المستجيبين المتحقق منهم فقط إلى دردشة آمنة ثنائية الاتجاه
نموذج توسعة منضبط: توجد شبكة المستجيبين المصرح لهم والتنسيق العام الواسع، لكنهما منفصلان ومحكومان ببوابات ولا يعاملان عمداً كالمسار الافتراضي
السحابة لا ترى المحتوى: تعالج الخدمات الخلفية إصدار الشهادات وتوزيع مرتكزات الثقة ومزامنة القياس عن بعد وتسليم المظاريف المشفرة؛ ولا يمكنها في أي وقت قراءة المحتوى المشفر من طرف إلى طرف
01

نموذج التشغيل

الافتراضات والنطاق وحد القدرة الحالي
صُمم Crisis Connect ليكون مفيداً في الحالتين: مراسلة ومكالمات يومية مشفرة من طرف إلى طرف أثناء توفر الإنترنت، وتنسيق محلي يستمر عند تعطل الشبكات واسعة النطاق. يرتكز وزن القرارات المعمارية على اللحظة الثانية: تستمر الهواتف القريبة في العمل ويحتاج المشغلون طبقة تنسيق محلية منضبطة لا غير محدودة.
افتراض المحلي أولاً: صُمم التطبيق للحوادث التي يتعذر فيها أو يزدحم الإنترنت والخدمة الخلوية، لكن الهواتف الذكية القريبة لا تزال تملك بطارية وأجهزة راديو قابلة للاستخدام.
عميل مثبّت مسبقاً: تفترض مشاركة المدنيين وجود إصدار تطبيق متوافق مثبت قبل فقد الاتصال، أو إمكانية توزيعه عبر سير عمل محلي معتمد ما دام التثبيت ممكناً.
نطاق الراديو المحلي: الاتصال قائم على القرب. Bluetooth هو المسار الافتراضي، بينما يُحجز Wi-Fi Aware لجلسات شبكة المستجيبين المصرح لهم على الأجهزة المدعومة.
مجموعة القدرات الحالية: تحديثات نصية وموقع آمنة، وصوت اختياري من نقطة إلى نقطة، ووضع الإنقاذ، ودردشة شبكة للمستجيبين المصرح لهم، ومراسلة إنترنت مشفرة من طرف إلى طرف، ومكالمات WebRTC صوتية ومرئية، ومزامنة اختيارية لقياس Crisis Link عن بعد تقع ضمن النطاق الحالي.
نهج احتواء الشائعات: مراسلة المدنيين افتراضياً لجهات الاتصال المعروفة، وSOS مفتوحة للاكتشاف لكن متحقق منها للدردشة الآمنة، والتنسيق العام الواسع اختياري ومحدود.
02

مبادئ التصميم

المحلي قبل السحابة

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

المباشر قبل الشبكة

السلوك الافتراضي هو Bluetooth من نقطة إلى نقطة. لا تُضاف أوضاع الوصول الأوسع إلا ضمن ضوابط صريحة للدور والقدرة والمشغل.

تشغيل محدود

يفترض التصميم طاقة محدودة وظروفاً ميدانية غير مستقرة، لذا فإن حدود الطابور وإعادة المحاولة وخدمات المقدمة ونطاق المكالمة الصوتية الواحدة مقصودة.

الثقة صريحة

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

03

حزمة الراديو الأساسية

اكتشاف وتحكم BLE فوق نقل حمولة RFCOMM
يجمع مسار الحادث الافتراضي طبقتي Bluetooth بوظيفتين مختلفتين. يعالج BLE الاكتشاف الخفيف وإشارات الخدمة وتبادلات تحكم الإنقاذ، بينما يحمل Bluetooth Classic RFCOMM حركة الحمولة الأثقل من نقطة إلى نقطة للنص والموقع والوسائط والصوت الاختياري.
طبقة الاكتشاف والتحكم
BLE (GAP/GATT)
إشارات الوجود وتبادلات التحكم القصيرة وإعلان وضع الإنقاذ والاكتشاف منخفض الطاقة
اكتشاف الزملاء منخفض الطاقة وبث الوجود المحلي للأجهزة القريبة
تبادلات مصادقة وتحكم تجهز الجلسات الآمنة قبل نقل الحمولة الثقيلة
سلوك منارة SOS وإشارات مستوى الخدمة لسير عمل وضع الإنقاذ
طبقة نقل الحمولة
Bluetooth Classic RFCOMM/SPP
نقل موثوق من نقطة إلى نقطة للنص والموقع والوسائط والصوت الاختياري
جلسات مباشرة أعلى إنتاجية بين الزملاء القريبين بعد نجاح الاكتشاف
نقل آمن للرسائل والصور والملفات والصوت عبر بروتوكول محدد في التطبيق
قد يشمل التوافق بدائل مقابس آمنة أو غير آمنة، لذا يُفرض أمان الرسالة فوق المقبس
نطاق التشغيل: المدى الإرشادي نحو 50-150 م في خط رؤية مفتوح، و30-80 م في العوائق الحضرية أو المختلطة، و10-30 م داخل المباني، و5-20 م في عوائق شبيهة بالأنقاض. ولأن المدى وسلوك المقبس يختلفان بين الأجهزة، تُرسخ السرية في طبقة التطبيق بدلاً من افتراضها من وضع RFCOMM وحده.
04

توسعات منضبطة

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

شبكة المستجيبين المصرح لهم

يتضمن خط إصدار Android توسعة اختيارية لدردشة جماعية آمنة عبر Wi-Fi Aware لأدوار الإدارة والفريق الميداني المصرح لها. تبقى معطلة ما لم ينجح فحص شهادة الدور وقدرة المنصة معاً.

قناة GATT عامة اختيارية

يمكن تفعيل شبكة Public GATT منفصلة من الإعدادات المتقدمة للدردشة والإعلانات العامة القريبة. وهي واسعة المدى عمداً ويجب التعامل معها كحركة تنسيق غير سرية.

بوابات تفعيل صريحة

تتطلب شبكة المستجيبين وضع دور محلي صالحاً وعتاداً مدعوماً. تبقى الشبكة العامة معطلة ما لم يفعّل المستخدم وضع الشبكة العامة صراحةً.

ضوابط إساءة محدودة

يثبت ملف القناة العامة المعلن حد القفزات عند 4، ويفرض نافذة زمنية وميزانية إغراق لكل مصدر وحدود حجم الرسالة وكبح التكرارات وطابور ترحيل محدوداً.
05

تهيئة الثقة

تجهيز QR قبل الحادث
تُضاف جهات الاتصال المعروفة قبل الحادث عبر تبادل QR. الهدف هو إخراج إنشاء الثقة من مسار الطوارئ كي لا يعتمد الاتصال الأول على إنترنت مباشر أو تهيئة مفاتيح مرتجلة داخل النطاق.
تجهيز خارج النطاق: يحمل تبادل QR مواد الثقة المطلوبة لتفعيل جهة الاتصال المعروفة، ما يقلل عمل التهيئة أثناء الحادث الفعلي.
قبول مرن للحمولة: يقبل أساس Android صيغة JSON القياسية `dcs://{...}` ومتغيرات JSON المشفرة كـ URI والحمولات القديمة المفصولة بخطوط عمودية لتقليل الفشل الميداني.
سياسة الاكتشاف: يستخدم الاقتران نافذة اسم الجهاز الأساسية لمدة 15 ثانية، ونافذة مرشح احتياطية لمدة 8 ثوانٍ، وبوابة تحدٍ واستجابة لمدة 10 ثوانٍ بعد الاقتران.
التفعيل التشغيلي: لا تُعلّم جهة الاتصال جاهزة لمجرد نجاح مسح QR. يجب أن ينجح أولاً اقتران مستوى نظام التشغيل وتأكيد الحيوية المشفر.
سير العمل هذا عملي لمجموعة ثقة محدودة مثل العائلة أو فريق الاستجابة أو قائمة أجهزة مُدارة. ليس نموذج اقتران مرتجل بحجم السكان، ويفترض نشره للمدنيين تثبيت التطبيق قبل فقد الاتصال.
06

نموذج الهوية والثقة

PSK لجهات الاتصال، وشهادات للمستجيبين
يستخدم Crisis Connect مسارات ثقة مختلفة للعلاقات المختلفة. لا تشترك جهات الاتصال المعروفة والمستجيبون المتحقق منهم في نموذج التهيئة أو التفويض أو الاسترداد نفسه.

المسار الآمن لجهة الاتصال المعروفة

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

مصادقة المستجيب

تتحقق تفاعلات الإنقاذ من شهادات الدور ECDSA محلياً مقابل مفتاح عام لسلطة مثبتة، بفحص التوقيع وUID المالك ونطاق الدور ونافذة الصلاحية قبل الترقية الآمنة.

أهلية الشبكة

تتطلب جلسات شبكة Wi-Fi Aware المصرح بها شهادة دور محلية صالحة ودعم المنصة معاً. تُرفض محاولات الانضمام غير المصرح بها قبل تفعيل دردشة الشبكة.

دورة حياة المفتاح والشهادة

شهادات الدور قصيرة العمر في الأساس (ملف المُصدر الحالي: TTL لمدة 72 ساعة). تعيش مفاتيح الهوية المحلية في AndroidKeyStore، وتحمي التخزينات المشفرة المواد الحساسة الأخرى، ويفرض وضع المستجيب المفقود أو المنتهي التحديث أو التجهيز من جديد.
07

دورة حياة الرسالة

من الاكتشاف إلى تقدم ACK
يغطي هذا القسم دورة حياة المسارات الآمنة القريبة (Bluetooth)؛ وتغطي فقرة الطبقة المتصلة مراسلة الإنترنت. في المسار القريب تُشفر البيانات على جهاز المرسل وتفك على جهاز المستلم. إذا كان الزميل غير متصل أو خارج المدى مؤقتاً، ينتظر التسليم رابطاً محلياً بدلاً من الهروب إلى ترحيل سحابي.
01يشير اكتشاف BLE وإشارات التحكم إلى توفر الزميل ويجهزان الجلسة المحلية.
02يفتح إعداد رابط RFCOMM النقل الأعلى إنتاجية المستخدم للنص والموقع والوسائط والصوت الاختياري.
03يستخدم تفعيل جهة الاتصال المعروفة إطارات التحدي والاستجابة `HSK_REQ` و`HSK_ACK`؛ ولا تصبح الجلسة نشطة إلا بعد نجاح تحقق محدود بمهلة.
04تحمل إطارات `SEC_MSG` حمولات مشفرة عند المرسل تحدد بواسطة UUID للرسالة وIV والنص المشفر؛ ويتحقق المستلم من AEAD قبل التخزين المحلي.
05يدفع تقدم `ACK` الرسائل في الطابور عبر دلالات التسليم والقراءة دون تكرار السجلات المحفوظة بـ UUID.
06تنتقل عمليات نقل الصوت والصور والملفات إلى عائلات سجلات JSON محددة النوع مع التجزئة ونوافذ إعادة المحاولة وفحوص سلامة نهاية النقل.
07تعتمد قواعد إعادة التشغيل والتكرار وعدم التكرار على تفرد UUID وذاكرات تخزين مؤقت محدودة وسلوك رفض لدى المستلم بدلاً من افتراض رابط مثالي.
08قناة GATT العامة منفصلة منطقياً عن هذه المسارات الآمنة المحددة ولا ينبغي اعتبارها نقلاً سرياً.
وضع البروتوكول: في أساس Android، تكون حركة RFCOMM سجلات UTF-8 محددة بسطر جديد مع خطوط تحكم مفصولة بخط عمودي وعائلات JSON محددة النوع لتدفقات وسائط أو تحكم مكالمات أغنى.
08

مسار الصوت

Opus عبر Bluetooth من نقطة إلى نقطة
الصوت اختياري ومحافظ عن قصد. يعمل كتدفق زميل إلى زميل في الوقت الفعلي عبر نقل من نقطة إلى نقطة، ويُشفر قبل الإرسال، ويجب تقييمه مقابل البطارية واستقرار RF معاً.

ملف الصوت

الترميزOpus
معدل العينات16 kHz
الإطار / الحزمة10 ms x 5 = ~50 ms
أهداف معدل البت20 kbps WB / 16 kbps NB
مخزن التذبذب20-50 ms (30 ms default)
هدف التخزين المؤقت~70-100 ms

تسلسل المكالمة

01يُلتقط الصوت ويشفر بـ Opus ويُشفّر ويرسل عبر رابط RFCOMM النشط بدلاً من حزمة وسائط إنترنت منفصلة.
02يفترض نطاق الأساس جلسة صوت نشطة واحدة لكل رابط من نقطة إلى نقطة؛ المكالمات الصوتية المتزامنة المتعددة على جهاز واحد خارج النطاق.
03يمكن لحلقة تحكم مدتها ثانية التبديل بين ملفات النطاق العريض والضيق، مع فترة تهدئة ست ثوانٍ وإقرارات ACK للإعداد المتفاوض عليه قبل سريان تغيرات الملف.
04يجب أن تعرض أدلة التجربة وقت إعداد المكالمة والفقدان وتوزيع زمن الانتقال وتأثير البطارية الإضافي في ظروف سيناريو محددة، بدلاً من مجرد استمرارية قصصية.

سياسة تكيفية

ينتقل التنفيذ من WB إلى NB عند ارتفاع أزمنة الكتابة أو تكرار نقص البيانات أو عدم استقرار عمق التذبذب؛ ولا يعود للترقية إلا بعد تعافٍ مستمر. هذه سياسة استمرارية محدودة وليست ضمان QoS عاماً.

09

الطبقة المتصلة

مراسلة ومكالمات مشفرة من طرف إلى طرف أثناء توفر الإنترنت
مع اتصال الإنترنت، يعمل Crisis Connect كتطبيق مراسلة يمكنك استخدامه يومياً: دردشة مشفرة من طرف إلى طرف ومكالمات صوتية ومرئية وإبلاغ SOS يصل إلى لوحات الاستجابة المصرح بها. لا تستبدل هذه الطبقة البنية المحلية؛ بل تقع فوقها وفق المبدأ نفسه: يُشفر المحتوى على الجهاز ولا تعالج الخوادم إلا المظاريف المشفرة والبيانات الوصفية اللازمة للتسليم.

مراسلة مشفرة من طرف إلى طرف

لا تغادر الرسائل والملاحظات الصوتية والمرفقات الجهاز إلا كمظاريف مشفرة من طرف إلى طرف؛ لا تستطيع الخوادم فتحها. عندما يدعم الطرفان ذلك، تعمل الجلسة على بروتوكول Signal عبر libsignal (Double Ratchet مع اتفاق مفاتيح PQXDH ما بعد الكم) بسرية أمامية. يغطي ظرف ECIES موثق (ECDH P-256 + HKDF-SHA-256 + AES-256-GCM) العملاء الأقدم؛ ولا يوفر سرية أمامية، وتُرفض محاولات الرجوع إلى تلك الصيغة بمجرد وجود جلسة Signal. يعيش مفتاح الهوية P-256 القديم في AndroidKeyStore مدعوم عتادياً على الأجهزة المدعومة؛ ويخزن مفتاح هوية Signal مشفراً في وضع السكون تحت مفتاح Keystore. يمكن التحقق من جهات الاتصال برقم أمان من 60 رقماً.

مكالمات WebRTC الصوتية والمرئية

تعمل المكالمات الفردية على WebRTC: صوت Opus وفيديو كاميرا حتى 720p ومشاركة شاشة. تُشفر الوسائط بـ DTLS-SRTP، ولا تعبر إشارات SDP وICE الخادم كنص صريح أيضاً — بل تنتقل داخل مظاريف رسائل مشفرة من طرف إلى طرف. عند تعذر الاتصال المباشر، تمر الوسائط المشفرة عبر ترحيل Cloudflare TURN؛ تُنشأ بيانات اعتماد TURN على جانب الخادم بعمر قصير، وإذا تعذر الوصول إلى الخدمة تعود المكالمة إلى اتصال مباشر عبر STUN.

SOS عبر الإنترنت

مع توفر الإنترنت، تسير SOS على مسارين منفصلين. يحمل التقرير المرسل إلى لوحات الاستجابة المصرح بها الموقع والدقة ومستوى البطارية والبلد، ولا يُشفر عمداً من طرف إلى طرف كي تستطيع اللوحات قراءته. ينتقل تنبيه SOS وتحديثات الموقع المباشر المرسلة إلى جهات اتصال الطوارئ كمظاريف مشفرة من طرف إلى طرف مثل أي رسالة أخرى. من دون اتصال يُصف التقرير ويرسل عند عودة الإنترنت؛ وتبقى منارة BLE SOS عاملة كالمسار المحلي الأساسي في كل الحالات.
اختيار النقل تلقائي: إذا كان رابط Bluetooth إلى الزميل متاحاً، تسلك الرسالة المسار المحلي؛ وإلا يُستخدم الإنترنت؛ وإذا لم يتوفر أي منهما تنتظر في طابور التخزين وإعادة التوجيه وتستمر الدردشة نفسها كمحادثة واحدة. الحد الصريح: يبقى المحتوى مشفراً من طرف إلى طرف، لكن تعالج الخوادم البيانات الوصفية للتسليم والإشارات (معرفات المرسل والمستلم والطوابع الزمنية وعناوين IP)؛ وتُحذف نسخ الخادم من المظاريف المؤكدة وتُنقّى غير المسلمة بعد مدة محدودة.
10

وضع الإنقاذ

بث SOS والتحقق من المستجيب وترقية الدردشة الآمنة
يفصل وضع الإنقاذ عمداً بين قابلية الاكتشاف والثقة. يمكن العثور على الضحية دون اقتران مسبق، لكن دردشة الإنقاذ الآمنة ثنائية الاتجاه لا تبدأ إلا بعد نجاح التحقق من المستجيب.
01 Signal

إشارات SOS

  • تضع SOS التي يطلقها المستخدم الجهاز في حالة استغاثة محلية وتبث إعلانات BLE قابلة للاتصال لخدمة الإنقاذ `0xCC00`.
  • يبقى محتوى الإعلان ضئيلاً في الأساس: تعرض إشارة الراديو قابلية اكتشاف مستوى الخدمة لا هوية موثقة كاملة.
  • صُمم بث SOS لتحسين اكتشاف المستجيبين القريبين أثناء عمليات تمشيط القطاعات عند تعطل الشبكات واسعة النطاق.
  • تكلفة الخصوصية صريحة: تزداد قابلية الاكتشاف في وضع SOS، لذلك تهم الموافقة وحالة الواجهة الواضحة وضوابط المعدل.
02 Verify

التحقق من المستجيب

  • بعد الاتصال يتبادل المستجيب والضحية تحدي واستجابة المصادقة على `0xCC10` و`0xCC11` ويشتقان مفتاح جلسة ECDH عابراً.
  • يصل إثبات الدور المشفر على `0xCC20` ويجب أن يشمل مرجع الشهادة ونطاق الدور ووقت الإصدار والانتهاء.
  • يفحص التحقق التوقيع ومرتكز الثقة وربط النص وانتهاء الصلاحية وتفويض الدور قبل السماح بأي ترقية آمنة.
  • تُرفض الإثباتات المنتهية أو المشوهة أو خاطئة النطاق عند البوابة بدلاً من تخفيضها إلى دردشة إنقاذ.
03 Connect

دردشة إنقاذ آمنة

  • لا تبث الضحية `OK` على `0xCC21`، لفتح المسار الآمن، إلا بعد تحقق ناجح.
  • تتابع بعدها دردشة الإنقاذ المشفرة ثنائية الاتجاه على `0xCC30` و`0xCC31` بدلالات ACK لـ `DELIVERED` و`READ`.
  • تشمل قيود الأساس الحالية حجم حزمة إثبات دور محدوداً وتجزئة مدركة لـ MTU وغلاف حزمة دردشة آمنة كبيراً لكن منتهياً.
  • لا يصل العملاء غير المتحقق منهم مطلقاً إلى قناة الكتابة الآمنة؛ بوابة الترقية حد صارم وليست واجهة إرشادية.
خاصية الأمان الأساسية هي أن وضع الإنقاذ لا يساوي قابلية الاكتشاف بالثقة. الاكتشاف القريب مفتوح بما يكفي للعثور على الضحايا؛ ودردشة الإنقاذ الآمنة ليست كذلك.
11

خدمات الخلفية

عمليات تشغيل المقدمة ونطاق المنصة
يبقى وقت التشغيل المؤسسي المتحقق الأساسي هو بنية خدمات Android. يتوفر عميل iOS منفصل علناً بمراسلة متمحورة حول BLE ومنطق إنقاذ محكوم بالمستجيبين، لكن يجب مع ذلك مراجعة أدلة النشر بدرجة المستجيب لكل منصة.
SVC-01

RfcommForegroundService

يحافظ على مستمع النقل الكلاسيكي وإشارات المكالمات ودورات حياة نقل الوسائط أو الملفات للجلسات المباشرة القريبة.

SVC-02

GattSOSServerService

يستضيف مذيع SOS لوضع الإنقاذ ونقطة نهاية تفاعل المستجيب الآمنة التي تستخدمها الضحايا في تدفقات إنقاذ BLE.

SVC-03

GattRescueClientService + MeshAwareService

يعالج جلسات إنقاذ BLE من جانب المستجيب، وعند التفويض اكتشاف ومصادقة شبكة Wi-Fi Aware بسلوك إعادة اتصال محدود.

SVC-04

CrisisLink والأدوات المحلية وملاحظة iOS

يفرغ CrisisLinkForegroundService القياس عن بعد في الطابور بعد استعادة إنترنت متحقق منها، ويدير OfflineDownloadService مناطق الخرائط المحلية، ويظل عميل iOS المنفصل فعلياً لكنه وراء بوابات الجاهزية الخاصة به.

12

التشفير ونموذج التهديد

ضمانات طبقة التطبيق فوق ظروف الراديو غير المستقرة
يختلف سلوك مقبس Bluetooth وظروف RF بين الأجهزة، لذا تُحدد ضمانات المسار الآمن في طبقة التطبيق. الملف التشفيري وافتراضات التهديد ونموذج حيازة المفتاح أجزاء صريحة من البنية.
LAYER 01
المسار الآمن لجهة الاتصال: تستخدم جهات الاتصال المجهزة بـ QR AES-256-GCM مع IV بطول 96 بت ووسوم بطول 128 بت؛ ولم تعد إطارات المصافحة المقواة تحمل مواد مفاتيح داخل النطاق.
LAYER 02
شهادات المستجيب: يتحقق وضع الإنقاذ من شهادات دور ECDSA P-256 محلياً مقابل مفتاح عام لسلطة مثبتة قبل ترقية الدردشة الآمنة.
LAYER 03
مفاتيح شبكة المستجيب: تستخدم شبكة Wi-Fi Aware المصرح بها مفتاح مجموعة مشتركاً؛ وتشتق مصافحة الدردشة الآمنة للإنقاذ (GATT) مفاتيح جلسة لكل زميل عبر ECDH P-256 عابر مع HKDF-SHA-256 وتُشفر الدردشة بـ AES-256-GCM مع AAD مرتبط بالرسالة.
LAYER 04
سياسة nonce وإعادة التشغيل: تتطلب IV مولدة بـ CSPRNG وحزم محدودة لكل مفتاح وتحديثاً عند البدء أو إعادة المصافحة وذاكرات إعادة تشغيل وعدم تكرار UUID للحفاظ على أمان AES-GCM تشغيلياً.
LAYER 05
حيازة المفتاح: تعيش مفاتيح توقيع هوية الجهاز في AndroidKeyStore (`dcs_attested_signing_key`)، بينما تخزن المواد المتماثلة الحساسة في تفضيلات مشفرة ويبقى النسخ الاحتياطي معطلاً.
LAYER 06
حد القناة العامة: قد تحمل حزم Public GATT ظرف AES-GCM للسلامة وتقوية الصيغة، لكن القناة تظل حركة تنسيق عامة غير سرية.
LAYER 07
ظرف رسائل الإنترنت: المسار المفضل لرسائل الإنترنت هو بروتوكول Signal عبر libsignal (Double Ratchet + PQXDH ما بعد الكم)؛ يستخدم ظرف التوافق ECDH P-256 + HKDF-SHA-256 + AES-256-GCM مع AAD مرتبط بالمرسل والمستلم والمحادثة، وتُرفض العودة إلى الصيغة القديمة بمجرد وجود جلسة Signal.
LAYER 08
وسائط المكالمات وTURN: تستخدم مكالمات WebRTC وسائط مشفرة بـ DTLS-SRTP مع إشارات المكالمة داخل مظاريف مشفرة من طرف إلى طرف؛ وترحّل TURN الحزم المشفرة فقط، وتُنشأ بيانات الاعتماد على جانب الخادم بعمر قصير.
LAYER 09
نموذج التهديد: يفترض التصميم تنصت RF سلبيّاً إضافة إلى محاولات إعادة التشغيل النشطة والانتحال والتشويش وإغراق الجهاز وتعطيل مستوى التحكم السحابي. في مسار الإنترنت تعامل الخوادم والبنية المرحّلة على أنها غير موثوقة للمحتوى: لا يصل النص الصريح إلى خادم، بينما تبقى بيانات التسليم الوصفية مرئية.
LAYER 010
استثناءات صريحة: يبقى الاختراق الكامل لنظام التشغيل وإكراه المستخدم وتشويش RF على نطاق دولة خارج النطاق، لذا لا ينبغي لادعاءات النشر أن توحي بحماية هناك.
يعني الدفاع المتعمق هنا تشفير جهاز المرسل والتحقق من جانب المستلم وبوابات دور صريحة وسياسة بيانات وصفية محدودة. وهو لا يمحو أثر الخصوصية الناجم عن قابلية الاكتشاف عبر الراديو.
13

الخصوصية والحوكمة

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

نظافة المعلومات

يبقى اتصال المدنيين الافتراضي ضمن جهات الاتصال المجهزة مسبقاً، ويفصل اكتشاف SOS عن الدردشة الآمنة، ويجب أن تحجز Public GATT التعليمات الرسمية لصيغ الإعلانات المتحقق منها من المستجيبين.

سياسة البيانات الوصفية على الهواء

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

الاحتفاظ وإخفاء الهوية

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

ملكية التحكم

تحتاج السلطات المشغلة إلى مالكين صريحين لإصدار الشهادات وإيقاع قائمة الرفض وتدوير المفاتيح والإبطال الطارئ وقطع الأدلة المستخدمة في مراجعة Go أو No-Go.
وضع الإعلان الموثوق على Public GATT هو اليوم عقد حوكمة أكثر من كونه ضماناً لمنتج مغلق؛ تبقى أدلة التخفيض وتغطية المحلل عناصر مراجعة مفتوحة.
14

مستوى الثقة المدعوم بالسحابة

خارج مسار الطوارئ القريب؛ مظاريف مشفرة فقط في المسار المتصل
يمكن لـ Crisis Connect العمل محلياً بالكامل لاتصال جهة الاتصال بجهة الاتصال القريب. تؤدي خدمات السحابة مهمتين: إنشاء الثقة مع دعم القياس عن بعد التشغيلي، وتسليم المظاريف المشفرة لمراسلة الإنترنت. لا تستطيع الخوادم في أي وقت فتح المحتوى المشفر من طرف إلى طرف، ويستمر مسار الطوارئ القريب في العمل دون السحابة.
Identity
الهوية والإصدار: تستطيع السلطات إصدار شهادات دور المستجيب وتدوير المفاتيح ودمج سير عمل الثقة مع IAM مؤسسي أو IdP مستضاف ذاتياً مثل Keycloak.
Verification
دعم التحقق المحلي: تخزن الأجهزة مرتكزات الثقة وحزم السياسة محلياً كي يستمر تحقق المستجيب دون إمكانية الوصول المباشر للسحابة؛ ولقطات قائمة الرفض توسعة نشر لنوافذ الاتصال.
Setup
قياس Crisis Link عن بعد: قد يصف المستجيبون المصرح لهم لقطات قياس إنقاذ عن بعد ويزامنونها لاحقاً عند عودة الإنترنت، لكن هذه القناة لا تحمل حمولات دردشة الطوارئ.
Delivery
تسليم الظرف المشفر: لمراسلة الإنترنت، تخزن الخلفية المظاريف المشفرة وبيانات التوجيه الوصفية فقط كي تصل الرسائل إلى المستلمين غير المتصلين؛ وتُحذف نسخ الخادم بعد تأكيد التسليم وتُنقّى المظاريف غير المسلمة بعد TTL محدود.
تقسيم مستوى الثقة: يبقى محتوى الطوارئ القريب على BLE أو RFCOMM أو Wi-Fi Aware أو قناة Public GATT الاختيارية؛
بينما تعالج الأنظمة السحابية دورة حياة الشهادة وتوزيع مرتكز الثقة ومزامنة القياس عن بعد وتسليم المظاريف المشفرة لرسائل الإنترنت.
ينبغي أن تبقي عمليات النشر الإنتاجية مفاتيح التوقيع خارج الكود المصدري وخلف ضوابط على نمط HSM أو KMS أو Secret Manager.
15

أدلة التجربة وبوابات القبول

ما يجب قياسه قبل النشر الأوسع
ينبغي الحكم على ادعاءات البنية هنا مقابل الأدلة الميدانية لا نية البروتوكول وحدها. يجب أن تستند موافقة التجربة إلى بيانات السيناريو لا إلى نية التصميم.
نجاح تسليم الرسالة: 95% على الأقل خلال 30 ثانية في السيناريوهات الداخلية أو الحضرية و85% في الظروف الشبيهة بالأنقاض.
زمن انتقال النص: يجب أن يبقى زمن انتقال الرسالة من طرف إلى طرف P95 عند 5 ثوانٍ أو أقل عبر نطاقات التشغيل المخططة.
نطاق الصوت: يجب أن يكون متوسط زمن الانتقال أحادي الاتجاه عند 150 مللي ثانية أو أقل مع فقد حزم مستمر عند 3% أو أقل خلال المكالمات النشطة.
أثر الطاقة: يجب أن يبقى اكتشاف الاستعداد واستنزاف النقل أو الصوت النشط ضمن الحدود المحددة للمهمة؛ وأدلة استعداد Pixel 7a الحالية مكملة وليست لإغلاق البوابة.
سير عمل المستجيب: ينبغي أن تنجح SOS وإثبات الدور وتبادل الرسائل الآمن وتفعيل الشبكة المصرح بها في 100% من سيناريوهات التحقق المبرمجة.
احتواء إساءة القناة العامة: يجب إسقاط الحزم العامة المشوهة أو خارج النافذة قبل الترحيل بنسبة >=99%، ويجب ألا تظهر إعلانات المستجيبين غير المتحقق منهم قط كتنبيهات موثوقة.

تسلسل التجربة الموصى به

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

وضع الأدلة الحالي

اعتباراً من 2 يونيو 2026، إصدارات المتاجر العامة هي Android 1.0.4 وiOS 1.1.0. تظل أدلة أساس Android لشهر مارس 2026 أدلة مكملة لطاقة الاستعداد والصوت مع اختبارات وحدات محلية ناجحة، بينما تبقى عدة بوابات مؤسسية قيد المراجعة أو معلقة بدلاً من أن تكون مغلقة بالكامل. الوضع المؤسسي الصحيح هو استخدام تجريبي منضبط لا نشر واسع غير مشروط.
16

الفجوات التقنية المفتوحة

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

الإبطال المحلي

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

نطاق الشبكة

هل Wi-Fi Aware طبقة نقل عامة لكل مستخدم؟
الوضع الحالي
لا. شبكة Wi-Fi Aware الآمنة توسعة للمستجيبين المصرح لهم على أجهزة Android المدعومة، وهي منفصلة عن قناة Public GATT الاختيارية ومنفصلة مرة أخرى عن جلسات الاتصال المباشرة عبر Bluetooth.
ما لا يزال مفتوحاً
لا تزال المؤسسات تحتاج تغطية قدرات الأجهزة وإجراءات تشغيل قياسية للمشغلين وسياسة واضحة لتوقيت تفعيل شبكة المستجيبين أو كبحها.

أدلة الطاقة

هل تغلق أرقام البطارية الحالية بوابة الطاقة؟
الوضع الحالي
لا. أظهرت مقارنة مقترنة لـ Pixel 7a في 15 مارس 2026 نحو 14.1 mW حملاً إضافياً في الاستعداد ضمن تشغيل تصحيح مضبوط يعمل بالتيار المتردد، وهو دليل مكمل مفيد فقط.
ما لا يزال مفتوحاً
لا يزال إغلاق البوابة يحتاج مقارنات أساس مقابل نشط مكافئة للإصدار وغير موصولة ومتعددة الأجهزة في ظروف ميدانية مسماة.

إساءة القناة العامة

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

نطاق المدى والصوت

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

أدلة الطبقة المتصلة

هل تُحتجز الطبقة المتصلة لمعيار الأدلة نفسه؟
الوضع الحالي
تبنى مراسلة الإنترنت والمكالمات الفردية على مكونات ناضجة واسعة المراجعة: libsignal وWebRTC وCloudflare TURN ببيانات اعتماد قصيرة العمر. وتُحدد صيغ المظاريف ورفض التخفيض والتحقق برقم الأمان على مستوى الكود.
ما لا يزال مفتوحاً
لا توجد مكالمات جماعية في المنتج اليوم: مكالمات جماعية قائمة على MLS ‏(RFC 9420) عبر SFU قيد التطوير في قاعدة الكود وتتطلب أدلة متحققاً منها من الجهاز قبل الإصدار. كما تبقى مراجعة مستقلة تغطي الطبقة المتصلة مفتوحة.
17

القيود وملاحظات السلامة

ما لا يعد به النظام
يبقى Bluetooth قائماً على القرب؛ وتحد البيئة والعوائق والعتاد وسياسة طاقة نظام التشغيل التغطية.
يدعم النظام تنسيق القطاعات المحلية، لا وصولاً مضموناً إلى كل ضحية في جميع ظروف الأنقاض.
تعتمد تدفقات المدنيين الافتراضية على الروابط المحلية المباشرة؛ وتتطلب أوضاع الشبكة عتاداً متوافقاً وتفعيلاً صريحاً وقرب راديو محلياً.
شبكة Public GATT اختيارية ومعطلة افتراضياً ولا يوصى بها كإعداد دائم لكل ملف مستخدم.
ينبغي أن يبقى المحتوى التشغيلي الحساس على مسارات آمنة محددة أو قنوات مستجيبين محكومة بالدور بدلاً من أسطح التنسيق العام الواسعة.
يبقى الترحيل أو التخزين وإعادة التوجيه غير المُدار وغير المحدود خارج نطاق الأساس المتحقق.
تتمحور أدلة النشر المؤسسي المتحقق الحالية حول خط إصدار Android؛ وiOS متاح علناً لكنه لا يزال يحتاج أدلة الجاهزية بدرجة المستجيب الخاصة به.
يمكن لاختلاف إدارة البطارية بين الجهاز ونظام التشغيل والشركة المصنعة أن يغير السلوك جوهرياً، لذا يجب أن تقيس التجارب الأساطيل بدلاً من افتراض تعميم نتائج هاتف واحد.
تعتمد الطبقة المتصلة على بنية الإنترنت؛ وعند فشلها يغلق ذلك المسار ويعود التطبيق إلى مسار Bluetooth القريب. لهذا ما زالت إضافة جهات الاتصال قبل الحادث مهمة.
في مسار الإنترنت، يبقى المحتوى مشفراً من طرف إلى طرف، لكن تعالج الخوادم وبنية TURN البيانات الوصفية للتسليم والإشارات والترحيل — المعرفات والطوابع الزمنية وعناوين IP.
السلامةلا يحل Crisis Connect محل خدمات الطوارئ الرسمية. عند توفر أي مسار واسع النطاق، ينبغي للمستخدمين محاولة رقم الطوارئ المحلي مثل 112 أو 911 أو المكافئ المعين وطنياً.
18

سيناريوهات النشر

مراسلة يومية مشفرة من طرف إلى طرف مع مكالمات صوتية ومرئية مع الأحبة البعيدين أثناء توفر الإنترنت
اتصال عائلة أو فريق أو قائمة مجهز مسبقاً باستخدام جهات اتصال موثوقة منشأة بواسطة QR
مراسلة محلية ومشاركة موقع دون اتصال أثناء سفر خارج الشبكة أو عمل ميداني بعيد
عمليات تمشيط زلزال أو انهيار بنية حيث تظهر الضحايا إشارات SOS ويتحقق المستجيبون قبل الدردشة الآمنة
ضحايا متصلون بالإنترنت تُوجّه تقارير SOS الخاصة بهم إلى لوحات الاستجابة المصرح بها
دردشة جماعية آمنة للمستجيبين فقط عبر Wi-Fi Aware على عتاد Android المدعوم
تنسيق قريب واسع وإعلانات عامة عبر شبكة Public GATT الاختيارية عند تفعيلها صراحةً
مكالمات صوتية عبر روابط Bluetooth مباشرة عندما يسمح نطاق RF والطاقة
تنزيل خرائط محلية وأدوات نجاة أو منفعة محلية وسير عمل جاهزية للطوارئ على عملاء محمولين مدعومين
مزامنة اختيارية لقياس Crisis Link عن بعد مع الخلفيات المؤسسية بعد استعادة إنترنت متحقق منها

نتيجة البنية

بنية Crisis Connect المحمولة محافظة عن قصد: أثناء توفر الإنترنت يسافر المحتوى في مظاريف مشفرة من طرف إلى طرف وتبقى الخوادم عمياء عنه؛ وعند فشل الشبكات يكون Bluetooth المباشر مسار الحادث الافتراضي، وتُهيأ الثقة خارج النطاق، وتُحكم تدفقات المستجيبين الآمنة بالشهادات، وتبقى السحابة خارج مسار الطوارئ القريب. النظام مناسب لتجارب مؤسسية قائمة على الأدلة حول خط إصدار Android، بينما ينبغي أن ينتظر النشر الأوسع بدرجة المستجيب تحققاً ميدانياً مقابل بوابات القبول المعلنة.
البنية التقنية للتطبيق المحمول | Crisis Connect