بنية الأمان في Remio، بوضوح.

§01 · الملخص التنفيذي

Remio تطبيق سطح مكتب بعيد مبني على بنية ند لند بمعرفة صفرية. محتوى الشاشة وبيانات الإدخال وتدفقات الصوت مشفّرة من طرف إلى طرف بين الأجهزة باستخدام DTLS-SRTP القياسي في الصناعة — نموذج الأمان نفسه الذي يعتمد عليه كل منتج قائم على WebRTC. وخلافًا للحلول المركزية، لا يسهّل خادم الإشارة (signaling) في Remio سوى إنشاء الاتصال الأولي — ولا يرى بيانات الجلسة ولا يعالجها ولا يخزّنها أبدًا.

لا حاجة إلى حسابات، ولا كلمات مرور يمكن اختراقها، ولا قاعدة بيانات مركزية لبيانات الاعتماد. يستخدم اقتران الأجهزة رمز QR أو معرّف جهاز وPIN يُقرآن من شاشة المضيف نفسه، وكل مفاتيح الجلسة مؤقتة مع سرية أمامية مثالية (Perfect Forward Secrecy): حتى لو اختُرق مفتاح تبقى الجلسات السابقة واللاحقة آمنة تشفيريًا. تلغي هذه البنية فئات كاملة من الهجمات التي ابتُليت بها المنافسات — لأنه ببساطة لا يوجد ما يُسرق.

§02 · نموذج التهديدات

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

التهديدات التي نحمي منها

• التنصت. تُشفَّر كل الوسائط (الفيديو والصوت) وقنوات البيانات (الإدخال ولوحة المفاتيح والمؤشر) بـ SRTP وDTLS على التوالي. لا يرى مراقب الشبكة سوى حزم مشفّرة دون قدرة على إعادة بناء محتوى الجلسة.
• هجوم الوسيط (MITM). تمنع مصافحة DTLS مع التحقق من بصمة الشهادة الاعتراض. وتستخدم قناة الإشارة TLS 1.3 مع سرية أمامية مثالية.
• اختراق الخادم. حتى لو اختُرق خادم الإشارة لدينا بالكامل، لا يحصل المهاجمون إلا على بيانات وصفية للاتصال (عناوين IP والطوابع الزمنية). لا يمر محتوى الجلسة عبر خوادمنا ولا يُخزَّن عليها أبدًا.
• الوصول غير المصرّح به. يتطلب الاقتران مسح رمز QR الخاص بالمضيف، أو كتابة معرّف الجهاز وPIN اللذين يعرضهما، أو تسجيل الدخول إلى حساب Remio نفسه على الجهازين. لا توجد قاعدة بيانات اعتماد يمكن الوصول إليها عن بُعد لمهاجمتها.
• سرقة بيانات الاعتماد. لا كلمات مرور ولا حسابات ولا مخزن اعتماد مركزي. تُنشأ ثقة الجهاز عبر اقتران PIN؛ ورموز الجلسة (JWT) قصيرة العمر ومرتبطة بالجهاز.
• إعادة تشغيل الجلسة. تمنع حماية إعادة التشغيل المدمجة في SRTP وأرقام تسلسل DTLS إعادة تشغيل الحزم الملتقطة.
• هجمات سلسلة التوريد. كل ملفات Remio التنفيذية موقّعة رقميًا. تُوثَّق إصدارات macOS (notarization) من Apple. وتُوزَّع إصدارات iOS حصريًا عبر App Store.

حدود الثقة

يحدد نموذج التهديدات لدينا صراحةً ثلاث حدود للثقة:

1. حد الجهاز. لا يُوثق بكل جهاز إلا بعد التحقق من PIN. وتحمي حمايات مستوى نظام التشغيل (العزل والتخزين المحمي في كل نظام، مثل Keychain) البيانات على الجهاز.
2. حد الشبكة. كل البيانات أثناء النقل مشفّرة. ونفترض أن الشبكة معادية.
3. حد الخادم. تُعامَل خوادمنا كمرحّلات غير موثوقة. تسهّل الاتصالات لكنها لا تستطيع فحص المحتوى.

§03 · نظرة عامة على البنية

يفصل Remio مستوى الإشارة (إعداد الاتصال) عن مستوى البيانات (البث). هذا الفصل أساسي في تصميمنا ذي المعرفة الصفرية — فالخادم الذي يساعدك على الاتصال لا يلمس البيانات التي تتبادلها أبدًا.

الإشارة مقابل مستوى البيانات

مسؤولية خادم الإشارة الوحيدة هي تمرير عروض/ردود SDP ومرشحي ICE بين الأجهزة أثناء إعداد الاتصال. وبعد إنشاء اتصال P2P لا يعود خادم الإشارة معنيًا.

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

§04 · طبقات التشفير

يعتمد Remio استراتيجية تشفير متعددة الطبقات تستخدم فيها كل قناة اتصال البروتوكول التشفيري الأنسب لمتطلباتها.

السرية الأمامية المثالية

تولّد كل جلسة Remio مجموعة فريدة من مفاتيح التشفير المؤقتة عبر تبادل مفاتيح ECDHE.

• اختراق مفتاح الجلسة الحالية لا يكشف الجلسات السابقة.
• اختراق مفتاح الجلسة الحالية لا يكشف الجلسات اللاحقة.
• يوجد كل زوج مفاتيح طوال مدة جلسة واحدة فقط.
• لا تُخزَّن المفاتيح على القرص أبدًا — توجد في الذاكرة فقط.

مجموعات الشيفرات

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

تدوير المفاتيح

تُدوَّر المفاتيح تلقائيًا عند الحدود التالية:

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

§05 · المصادقة والاقتران

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

الاقتران القائم على PIN

حين يريد عميل الاتصال بمضيف للمرة الأولى، تجري العملية كالتالي:

1. يعرض المضيف رقم PIN رقميًا قصيرًا على شاشته (أو كرمز QR).
2. يُدخل العميل الـ PIN، ويُرسَل عبر قناة الإشارة إلى المضيف.
3. يتحقق المضيف من الـ PIN ويؤكد الاقتران أو يرفضه.
4. عند النجاح تُنشأ علاقة ثقة بالجهاز.
5. لا تتطلب الاتصالات اللاحقة من الجهاز نفسه إعادة اقتران.

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

بعد الاقتران يُعرَّف كل جهاز بـ معرّف جهاز فريد. ويحتفظ المضيف بقائمة محلية بالأجهزة الموثوقة. وعلاقة الثقة هذه:

• مخزّنة محليًا على جهاز المضيف فقط، في التخزين المحمي الذي يوفره نظامه — Keychain على Mac والتخزين المشفّر للنظام على Windows وملف خاص على Linux.
• لا تُرسَل أبدًا — لا يعرف الخادم أي الأجهزة موثوقة.
• قابلة للإلغاء — يستطيع المضيف إزالة جهاز موثوق في أي وقت.

رموز الجلسة (JWT)

بعد الاقتران تُستخدم رموز موقّعة قصيرة العمر (صلاحية 24 ساعة) لمصادقة خادم الإشارة.

تصادق هذه الرموز جهازًا لدى خادم الإشارة لإنشاء الغرف وتمرير الرسائل. وهي لا تمنح وصولًا إلى محتوى الجلسة المحمي بمصافحة DTLS منفصلة.

وصول وكلاء الذكاء الاصطناعي (خادم Remio MCP)

يمدّ Remio نموذج الثقة نفسه إلى وكلاء الذكاء الاصطناعي. تستطيع أدوات مثل Claude Code أو Codex أو تطبيق Claude تشغيل أجهزتك عن بُعد عبر خادم Remio MCP — وحد الأمان مطابق لما يعبره عميل بشري:

• كل شيء مقيّد بتسجيل دخولك. لا يستطيع الوكيل الوصول إلا إلى المضيفين المتصلين والمقترنين بالحساب الذي صادقتَ به أنت (تسجيل الدخول بـ Google أو Apple عبر OAuth). لا حساب موثّق، لا أدوات.
• Remio وسيط لا مشغّل. مهمة خادم MCP الوحيدة هي كشف مجموعة أدوات محصورة بحسابك الموثّق وتسليمها لأداة الذكاء الاصطناعي التي اخترتَ أنت ربطها. لا يستطيع Remio بدء جلسة مع جهازك من تلقاء نفسه — فلا يقبل المضيف إلا اتصالات تقدّم إثباتًا لتفويض حسابك، تمامًا كنموذج ثقة الجهاز أعلاه.
• النقل المشفّر نفسه. تعمل جلسات الوكلاء على قنوات التشفير من طرف إلى طرف نفسها الموصوفة في §04. لا تزال خوادمنا ترى كتلًا مشفّرة فقط — وتنطبق خصائص المعرفة الصفرية في §06 دون تغيير.
• مرئية وقابلة للإنهاء ومدقَّقة. تُعرض جلسة الوكيل على المضيف أثناء تشغيلها، ويمكن إنهاؤها فورًا بمفتاح إيقاف، وتُسجَّل في سجل تدقيق محلي.

§06 · تصميم المعرفة الصفرية

المعرفة الصفرية في Remio ليست مصطلحًا تسويقيًا — بل قيد معماري. صُممت أنظمتنا بحيث يكون محتوى الجلسة بعيد المنال بنيويًا عن Remio وموظفيه وأي طرف ثالث.

ما تستطيع خوادمنا رؤيته

• عناوين IP للأجهزة المتصلة (مطلوبة للشبكات).
• الطوابع الزمنية للاتصال.
• معرّفات الأجهزة (معرّفات مبهمة غير مرتبطة بمعلومات شخصية).
• البيانات الوصفية للإشارة: تبادل عرض/رد SDP ومرشحو ICE.

ما لا تستطيع خوادمنا رؤيته

• محتوى الشاشة — إطارات الفيديو مشفّرة بـ SRTP من طرف إلى طرف.
• الصوت — تشفير SRTP نفسه كالفيديو.
• أحداث الإدخال — الماوس ولوحة المفاتيح واللمس مشفّرة بـ DTLS.
• موضع المؤشر — يُرسَل عبر قناة بيانات مشفّرة.
• محتوى الملفات — أي نقل ملفات يجري عبر قنوات مشفّرة.
• بيانات الحافظة — قناة بيانات مشفّرة.
• حالة التطبيقات — ما التطبيقات التي تشغّلها وما الذي تعمل عليه.

سياسة الاحتفاظ بالبيانات

بسبب بنية P2P لدينا، لا يوجد فعليًا ما يُحتفظ به:

• محتوى الجلسة. لا يُخزَّن أبدًا. بث فوري فقط.
• سجلات الإشارة. تُحفظ البيانات الوصفية للاتصال حتى 30 يومًا لأغراض التصحيح ثم تُحذف. لا تحتوي على أي محتوى جلسة.
• حسابات المستخدمين. لا حسابات مطلوبة. بيانات Firebase Auth الاختيارية تديرها بنية Google التحتية ويمكن للمستخدم حذفها.
• معلومات الأجهزة. تُخزَّن محليًا على كل جهاز. وإذا اخترت تسجيل الدخول تُزامَن قائمة أجهزتك مع حسابك (انظر سياسة الخصوصية).

تدفق بيانات ند لند أولًا

في غالبية الاتصالات (حيث ينجح اجتياز NAT) تتدفق البيانات مباشرةً بين الأجهزة دون المرور بأي خادم:

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

وحتى في سيناريو الاحتياط عبر مرحّل TURN، لا يتعامل خادم المرحّل إلا مع حزم مشفّرة. يعمل كأنبوب أصم — لا يستطيع فك التشفير أو الفحص أو التعديل.

§07 · أمان الشبكة

إنشاء اتصال P2P

يستخدم Remio بروتوكول ICE (Interactive Connectivity Establishment) لإيجاد أفضل مسار اتصال ممكن بين الأجهزة:

1. مرشحو المضيف — اتصال مباشر عبر الشبكة المحلية على الشبكة نفسها.
2. المرشحون المنعكسون من الخادم (STUN) — اجتياز NAT عبر خوادم STUN لاكتشاف عنوان IP العام.
3. مرشحو المرحّل (TURN) — مرحّل مشفّر حين يتعذر إنشاء اتصال مباشر.

يختبر وكيل ICE كل أزواج المرشحين في آنٍ واحد ويختار المسار الأقل زمن استجابة والأكثر موثوقية. ويُفضَّل P2P المباشر دائمًا.

سياسات نقل قابلة للضبط

تفضّل الاتصالات افتراضيًا P2P المباشر مع احتياط تلقائي إلى المرحّل المشفّر. وتتوفر سياسات أكثر صرامة — إجبار كل الحركة عبر المرحّل أو تخطي اكتشاف الشبكة المحلية كليًا — لبيئات الشبكات المقفلة.

تحديد المعدل

ينفّذ خادم الإشارة تحديدًا صارمًا للمعدل لمنع إساءة الاستخدام:

تُنظَّف محددات المعدل المنتهية تلقائيًا كل 5 دقائق مع TTL مدته 10 دقائق، مما يمنع استنزاف الذاكرة بسبب الهجمات الموزعة.

الحماية من DDoS

تُحمى بنيتنا التحتية للإشارة بواسطة Cloudflare، التي توفر:

• DNS بتقنية Anycast مع شبكة حافة عالمية.
• تخفيف DDoS في الطبقات 3 و4 و7.
• جدار حماية تطبيقات الويب (WAF).
• تحديد المعدل عند الحافة قبل وصول الحركة إلى الأصل.
• كشف الروبوتات وصفحات التحدي.

§08 · أمان العميل

يستفيد Remio من مكدّس الأمان الكامل لكل نظام تشغيل لحماية البيانات المحلية وضمان سلامة التطبيق.

macOS

• تكامل Keychain. تُخزَّن كل البيانات الحساسة (رموز ثقة الأجهزة وJWT) في Keychain في macOS، محمية ببيانات تسجيل دخول المستخدم والتشفير العتادي.
• App Sandbox. يعمل Remio في بيئة معزولة بأقل الأذونات. يتطلب التقاط الشاشة وإمكانية الوصول موافقة صريحة من المستخدم.
• توقيع الشيفرة. كل الإصدارات موقّعة بشهادات Apple Developer.
• التوثيق (Notarization). تُوثَّق إصدارات macOS من Apple، مما يؤكد خلوها من البرمجيات الخبيثة المعروفة.
• وقت التشغيل المحصَّن. يمنع حقن الشيفرة واختطاف المكتبات وتصحيح الأخطاء في إصدارات الإنتاج.

iOS

• App Transport Security (ATS). يجب أن تستخدم كل اتصالات الشبكة HTTPS/TLS. دون أي استثناءات.
• حماية البيانات. تُشفَّر عناصر Keychain بمفاتيح يشتقها الجهاز من عتاده الخاص، والعناصر المعلَّمة بـ «هذا الجهاز فقط» لا تغادره أبدًا، ولا حتى في نسخة احتياطية.
• Keychain Services. تُخزَّن بيانات اعتماد الجهاز في Keychain في iOS بفئة الحماية kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• مراجعة App Store. تجتاز كل إصدارات iOS عملية المراجعة الأمنية من Apple.
• لا بيانات في الخلفية. لا يجمع التطبيق بيانات ولا يرسلها وهو في الخلفية.

توقيع الشيفرة & التحقق

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · الاستجابة للحوادث

سجل الأمان

حتى فبراير 2026، ليس لدى Remio أي سجل اختراقات أو حوادث أمنية. تقلل بنية المعرفة الصفرية لدينا سطح الهجوم كثيرًا — فلا توجد قاعدة بيانات مركزية لبيانات الاعتماد أو بيانات الجلسات لاستهدافها.

الإبلاغ عن الثغرات

نشجّع الإفصاح المسؤول من باحثي الأمان. إذا اكتشفت ثغرة محتملة:

1. راسل security@remio.net بوصف مفصّل.
2. أرفق خطوات إعادة الإنتاج، إن أمكن.
3. نؤكد الاستلام خلال 48 ساعة.
4. نسعى إلى حل الثغرات المؤكدة خلال 30 يومًا.
5. يُنسب الفضل إلى المبلّغين في سجل التغييرات الأمنية لدينا، ما لم يفضلوا عدم الكشف عن هويتهم.

سياسة الإفصاح المسؤول

• نطلب نافذة إفصاح مدتها 90 يومًا قبل الإفصاح العلني.
• لا نلاحق قانونيًا الباحثين الذين يتصرفون بحسن نية.
• نرتّب أولويات الإصلاح حسب الخطورة: حرجة وعالية ومتوسطة ومنخفضة.
• برنامج مكافآت رسمي للثغرات ضمن خارطة طريقنا.

عملية الاستجابة للحوادث

في حال وقوع مشكلة أمنية مؤكدة:

1. الاحتواء. عزل الأنظمة المتأثرة خلال ساعة واحدة.
2. التقييم. تحديد النطاق والتأثير خلال 24 ساعة.
3. الإبلاغ. إشعار المستخدمين المتأثرين خلال 72 ساعة (بما يتوافق مع GDPR).
4. المعالجة. نشر التصحيحات عبر بنية التحديث التلقائي.
5. التحليل اللاحق. نشر تقرير شفافية.

§10 · الامتثال

الجاهزية لـ GDPR

بنية المعرفة الصفرية في Remio ملائمة لـ GDPR بطبيعتها لأننا نقلّص جمع البيانات إلى الحد التقني الأدنى:

• تقليل البيانات. لا نجمع إلا ما يلزم لإنشاء الاتصال.
• الحق في المحو. بما أننا لا نخزّن محتوى المستخدم فلا شيء لحذفه. يمكن حذف بيانات الحساب الاختيارية عند الطلب.
• قابلية نقل البيانات. تُخزَّن بيانات ثقة الأجهزة محليًا ويتحكم بها المستخدم.
• الموافقة. اقتران PIN آلية موافقة صريحة لكل جهاز.
• لا نقل عابر للحدود لمحتوى البيانات. تُبقي اتصالات P2P البيانات بين الأجهزة؛ ولا تدخل بنيتنا التحتية أبدًا.

SOC 2

غير متوفر بعد

• تدقيق أمني مستقل — لم يُجرَ بعد اختبار اختراق أو مراجعة شيفرة من طرف ثالث.
• SOC 2 Type I — لا تقرير بعد.
• SOC 2 Type II — لا تقرير بعد.
• برنامج مكافآت الثغرات — مكافآت رسمية للإفصاح المسؤول.

مكان إقامة البيانات

لأن Remio يعتمد P2P أولًا، فإن بيانات الجلسة تقيم حيث توجد أجهزتك. لا تغادر بياناتك الاتصال المباشر بين أجهزتك. ولا يعالج خادم الإشارة (المستضاف لدى Cloudflare وDigitalOcean) سوى البيانات الوصفية للاتصال — وهذه البيانات الوصفية غير مرتبطة بأي معلومات شخصية.

§11 · المقارنة بالبدائل

ابتُلي قطاع سطح المكتب البعيد باختراقات أمنية بارزة. وهكذا تختلف بنية Remio جذريًا عن البدائل المركزية.

لماذا تفشل البنى المركزية

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

وحين اخترقت APT29 (مجموعة روسية مدعومة من دولة) شبكة TeamViewer المؤسسية في يونيو 2024 أثار ذلك تساؤلات حول سلامة المنتج نفسه — لأن البنية المركزية تعني أن الشركة تملك القدرة التقنية على الوصول إلى الجلسات.

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

§12 · الخاتمة

أمان Remio ليس مجموعة ميزات أُلصقت بمنتج — بل نتيجة قرارات معمارية اتُّخذت منذ اليوم الأول. باختيار P2P بدل المركزية، واقتران PIN بدل كلمات المرور، والمعرفة الصفرية بدل جمع البيانات، بنينا سطح مكتب بعيد يكون فيه الأمان هو الحالة الافتراضية لا ترقية اختيارية.

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

للأسئلة أو المراجعات الأمنية للمؤسسات أو للإبلاغ عن ثغرة:

• استفسارات الأمان: security@remio.net
• مبيعات المؤسسات: enterprise@remio.net
• عام: hello@remio.net