الأصدار الاول من بروتوكول OxideTalis

جدول المحتويات

المؤلف: عويتب
التاريخ: 2024/6/1
الاصدار: 1.0.0
الحالة: مسودة

نظرة عامة

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

الاهداف

الاهداف الغير مرغوبة

العناوين العامة

العنوان العام هو المفتاح العام الخاص بخوارزمية Elliptic Curve Diffie-Hellman مضغوط وهو يتكون من 33 بايت (264 بت) يتم ترميزه بترميز base58 على سبيل المثال العنوان التالي becZJsZZqGR7qBG8t1Pm4uy62jDTzJsabxnkARhr2syo.

يتم وضع العنوان العام في رأس (Header) الطلب (Request) بأسم X-OTMP-PUBLIC ويجب ان يكون نص base58 صحيح مكون من 33 بايت (264 بت) بعد فك ترميزه.

عنوان دليل الخوادم

عنوان دليل الخوادم هو نطاق طبيعي على سبيل المثال example.com يحتوي على المسار التالي /.well-known/oxidetalis/directory ومحتوى هذا المسار ملف json يوجد به خادم و مُرحلات مستخدمين هذا الدليل.

الخادم الذي في هذا الدليل يكون اسمه خادماً إذا كان يقبل التواصل الداخلي، إذا كان يقبل التواصل الخارجي فقط حتى بين مستخدمينه، يصبح اسمه مُرحل.

يمكن أن يكون هذا الدليل تابع لمستضيف معين ويضع به خوادمه أو عناوين لنفس الخادم (مثل عنوانه في شبكة Tor) أو يكون تابع لفرد ويضع به الخوادم التي يستخدمها. يجب لكل خادم في الدليل أن يصدر شهادة SSL/TLS من جهة موثوقة لأن الإتصال سيكون HTTPS (يستثنى من هذا خدمات Tor).

مهمة هذا الدليل

في الإتصال الخارجي يحتاج المُرسل معرفة خادم المُستقبل لإرسال الرسالة إليه، عبر هذا الدليل سيعرف المُرسل خادم المُستقبل و المُرحلات التي يستقبل الرسائل منها.

الخادم و المُرحلات

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

المُرحل لديه وظيفة واحدة فقط، وهي تحويل الرسائل الخارجية إلى مستخدميه، ليس لدى المرحل أي وظيفة أخرى، لا يقوم بتخزين ملفات مستخدمينه التعريفية ولا أي معلومات ما عدى عناوينهم العامة لتحويل الرسائل إليهم.

سوف يتم الإشارة إلى الخوادم و المُرحلات بخوادم في هذا التوثيق.

الإشارة إلى مستخدمين الدليل

للإشارة إلى المستخدمين في أي وسيلة نقل يكون بالطريقة التالية @becZJsZZqGR7qBG8t1Pm4uy62jDTzJsabxnkARhr2syo/example.com علامة @ متبوعة بعنوان المستخدم العام متبوعاً بخط مائل وبعد ذلك عنوان الدليل. يمكن لمطوري عملاء OxideTalis إختصار إسم عنوان المستخدم بالشكل التالي عند الإشارة إليه @bec..syo/example.com بأخذ ثلاث محرفات من البداية ومن النهاية و الفصل بينهم بنقطتين ...

خوادم الدليل

يوجد نوعين من خوادم الدليل، النوع الأول الخوادم التي على شبكة الإنترنت العامة ولتي يتم جلب عنوانها من النطاق الخاص بها مثل example.com، سوف يتم التواصل مع هذه الخوادم بإتصال https و wss لذلك يجب أن يكون لديها شهادة SSL/TLS ويجب ان تكون الشهادة موقعة من جهة موثوقة وليست موقعة ذاتياً1، يتم الإشارة إلى هذا الخوادم بالنطاق الذي تستخدمه و المنفذ، على سبيل المثال otmp.example.com:443 يتم الفصل بين النطاق الذي سوف يتم جلب العنوان منه و المنفذ بنقطتان رأسيتان.

النوع الثاني وهو خدمات شبكة Tor المخفية، سوف يتم الإتصال بها بـhttp و ws، يتم الإشارة إليها بوضع عنوانها في شبكة Tor فقط بدون المنفذ، على سبيل المثال duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion

محتوى المسار /.well-known/oxidetalis/directory في الدليل

يجب أن يرجع هذا المسار نص بتنسيق JSON يحتوي هذا النص على المفتاحين "server" و "relays"، محتوى المفتاح "server" نص (تم توضيح تنسيقه هنا) ويمكن أن يكون null و المفتاح "relays" مصفوفة نصية يوجد بها المُرحلات (تم توضيح تنسيقها هنا) ويمكن أن تكون null. يمكن للمستخدم أن لا يكون لديه خادم بالتالي لن يكون لديه ملف تعريفي، و يمكن أن لا يكون لديه مُرحلات وسوف يتم التواصل الخارجي عبر خادمه. يعد الدليل تالف إذا لم يكن به خادم ولا مُرحلات.

أمثلة

في المثال التالي مُخرج الدليل example.com في المسار /.well-known/oxidetalis/directory ويتضح به انه لايوجد إلا الخادم

{ "server": "otmp.example.com:443", "relays": null }

في المثال التالي مُخرج الدليل example.net في المسار /.well-known/oxidetalis/directory ويتضح به انه يوجد مُرحلين فقط

{
    "server": null,
    "relays": [
     "random-relay.tld:7294",
     "duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion"
     ] 
}

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

مفتاح التشفير المشترك

يتم انشاء مفتاح التشفير المشترك عبر خوارزمية Elliptic Curve Diffie-Hellman secp256k1 حيث يقوم مرسل الرسالة بوضع العنوان العام الخاص بالمستقبِل لإنتاج المفتاح المشترك، بعد إنتاج المفتاح المشترك يتم ادخاله إلى دالة HKDF بدون ملح بخوارزمية Sha256 وبعد ذلك يتم عمل له توسعة (expand) بدون معلومات (info) بطول 32 بايت (256 بت).

التشفير

سوف يتم استخدام مفتاح التشفير المشترك مفتاحاً للتشفير في خوارزمية AES-256 CBC، بعد تشفير الرسالة يتم وضع قيمة التهيئة (iv) في أخر الرسالة، ليكون اخر 16 بايت (128 بت) هي قيمة التهيئة (iv) التي سوف يستخدمها المستقبِل لفك تشفير الرسالة.

مثال لمفتاح تشفير مشترك بترميز base58 LKGKeuV3SRu1n3fez4SdboM3FT48vbBxHai9MbuWxb3

مفتاح الخادم العام

مفتاح الخادم العام هو مثل العنواين العامة الخاصة بالمستخدمين، ولكنه خاص بالخادم، حيث ان الخادم سوف يقوم بأنشاء مفتاح مشترك بينه وبين مرسل الطلب (Request) ليتأكد من أن المرسل (صاحب العنوان العام) هو مالك هذا العنوان. يتم التأكد عبر مطابقة التوقيع الموجود في الطلب (Request).

يتم جلب مفتاح الخادم العام من المسار /api/info سوف يتم إرسال طلب GET إلى هذا المسار و يجب أن يُرجع هذا المسار نص بتنسيق application/json يحتوي على المفتاح public_key ولذي قيمته نص المفتاح العام الخاص بالخادم بترميز base58.

تم توضيح المفتاح العام هنا (العناوين العامة)

حاول ان لا تقوم بتغيير المفتاح العام الخاص بالخادم بشكل مستمر، لآن العملاء سوف يقومون بتخزينه بالعادة.

توقيع الطلب

هو التوقيع الخاص بالطلب يتم وضعه في رأس الطلب (Header) بأسم X-OTMP-SIGNATURE او في بيانات ال Websocket في المفتاح signature بترميز Hex ويتم أستخدامه للتأكد من ان مرسل الطلب هو مالك المفتاح العام.

إنشاء التوقيع

التوقيع يحتاج إلى ثلاث اشياء ليتم إنشائه

يتم إدخال جسم الطلب (body) او بيانات الحدث في الـWebsocket إلى دالة HMAC-SHA256 و إستخدام مفتاح التشفير المشترك مضافاً إليه الوقت الحالي (8 بايت) و الـ16 بايت العشوائي، أي المفتاح المستخدم في دالة HMAC-SHA256 سوف يكون

مفتاح التشفير المشترك+الوقت الحالي+16 بايت عشوائي

بعد ذلك يتم أخذ نتيجة دالة HMAC-SHA256 و إضافة الوقت المستخدم في الأعلى و الـ16 بايت المستخدمة في الأعلى و جميعهم بترميز Hex، مثال

bad035084e11bfd266c7b7dfa473d6603be551b3aa215f869776b75bf42ef31900000000665e1a696e6d776f65726e6664757265686a66

بعد تحويله إلى بايتات سوف يكون المجموع 56 بايت، وسوف يكون التقسيم كالتالي

سوف يتحقق الخادم من أن الوقت الذي في التوقيع لم يتجاوز الـ20 ثانية، وسوف يقوم الخادم بتخزين ال 16 بايت العشوائي في الكاش بمدة حياة 30 ثانية، ليتأكد الخادم من ان ال 16 بايت العشوائي لن يتم إستخدامهم في توقيع أخر، بالتالي ضمان عدم إرسال الطلب مرة أخرى من المهاجمين (ضمان أن التوقيع صالح لمرة واحدة فقط).

شكل البيانات داخل إتصال الـWebsocket

بعد الإتصال بـWebsocket مع الخادم، يكون تنسيق البيانات التي يتم تبادلها بين المرسل والخادم json ويجب عليها توفر المفاتيح التالية

مثال لشكل البيانات في ال websocket

{
  "event": "EventName",
  "data": {
    "key": "value"
  },
  "signature": "bad035084e11bfd266c7b7dfa473d6603be551b3aa215f869776b75bf42ef31900000000665e1a696e6d776f65726e6664757265686a66"
}

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

طريقة التواصل

هنا سوف يتم توضيح طريقة التواصل بين طرفين في خادم واحد (تواصل داخلي)، وبين طرفين في خوادم مختلفة (تواصل خارجي)

مفاهيم مهمة

سوف يتم استبدال العنوان العام بأسم سارة و أحمد لآن العناوين العامة طويلة نسبياً

التواصل الداخلي

اولاً يجب2 عند فتحك لعميل التواصل أن تقوم بإنشاء إتصال Websocket بينك وبين الخادم الخاص بك، عبر هذا الإتصال سوف تستقبل الرسائل الجديدة من الخادم الخاص بك، وسوف تقوم بالتواصل من خلاله لإرسال الرسائل إلى افراد الخادم.

لدينا الآن المرسلة سارة والمستقبِل أحمد و كلاهم في الخادم نفسه، سوف تقوم سارة بإرسال حدث Websocket تطلب من الخادم إرسال طلب دردشة إلى أحمد سوف يرد الخادم بأحد الأخطأ التالية، او لا يقوم بالرد إذا لم يكن هناك خطأ.

إذا لم يكن هناك مستخدم بأسم أحمد في الخادم

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

إذا لم تكن سارة في قائمة أحمد البيضاء ولا السوداء

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

عندما يرد أحمد بالموافقة أو الرفض (عبر إتصال الـWebsocket)، سوف يُعلم الخادم سارة بأن أحمد وافق أو رفض التواصل معها (عبر إتصال الـWebsocket أو إضافتها إلى جدول ليُعلمها عند تواصلها مع الخادم). إذا لم يوافق أحمد سوف يقوم الخادم بإضافة سارة إلى قائمة أحمد السوداء، و إذا وافق سوف يتم إضافتها إلى القائمة البيضاء.

إذا كانت سارة في قائمة أحمد البيضاء

سوف يرجع الخادم خطأ، يُعلم سارة أنها في قائمة أحمد البيضاء (يمكنها التواصل معه)

إذا كانت سارة في قائمة أحمد السوداء

سوف يرجع الخادم خطأ و يُعلم سارة انها في قائمة أحمد السوداء ولا يمكنه الدردشة معه.

يتم تخزين رسائل الطرفين مُشفرة في قاعدة البيانات الخاصة بالخادم

التواصل الخارجي

لدينا الآن المرسلة سارة من example1.com والمستقبِل أحمد من example2.com سوف تقوم سارة بإرسال طلب Get إلى example2.com تطلب فيه الدردشة مع أحمد، يجب على سارة وضع الرأس X-OTMP-SERVER يحتوي على أسم الخادم الخاص بها، سوف يستخدم أحمد هذا الخادم لإرسال طلب القبول أو الرفض إليه إذا لم تكن سارة في قائمته السوداء ولا البيضاء، سوف يرد الخادم بأحد الردود التالية

إذا لم يكن هناك مستخدم بأسم أحمد في الخادم

سوف يرجع الخادم 404 و يُعلم سارة بأنه ليس لديه مستخدم بهذا الأسم.

إذا لم تكن سارة في قائمة أحمد البيضاء ولا السوداء

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

قبول أو رفض طلب الدردشة

بعدما يستقبل أحمد طلب دردشة سارة و خادمها و عندما يريد قبول أو رفض الطلب سيقوم بالإرسال إلى النقطة /api/chat_response في خادم سارة، يجب على أحمد وضع عنوانه العام في الرأس X-OTMP-PUBLIC وتوقيع الطلب في X-OTMP-SIGNATURE، يجب أن يرسل طلب POST إلى النقطة مع جسم يوضح من مرسل الطلب (سارة في حالتنا) و إذا اراد قبوله أم لا.

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

إذا كانت سارة في قائمة أحمد البيضاء

سوف يقوم الخادم بترقية الإتصال إلى Websocket او إذا كانت سارة متصلة معه من قبل، سوف يقوم بإرجاع 400 ويخبر سارة بالتواصل معه عبر ال Websocket.

إذا كانت سارة في قائمة أحمد السوداء او كانت هي او خادمها في قائمة الخادم السوداء

سوف يرجع الخادم 403 مع توضيح السبب.

أساسيات التواصل الخارجي

شكر و تقدير

شكراً للأشخاص التاليين على مراجعة و تحسين البروتوكول.

1

لضمان عدم وجود شخص في المنتصف، يقوم بالتلاعب بالبيانات و الإطلاع عليها.

2

طالما انك عضو في الخادم، سوف يعتقد الخادم دائماً انك في إتصال Websocket معه، ولن يقوم بترقية أي إتصال إلى Websocket

3

يتم إضافة العنوان الخاص بـأحمد في جدول طلبات الدردشة المُرسلة للتاكد من عدم إستقبال إشعارات قبول/رفض مزيفة هدفها الإزعاج.