أود اليوم أن أتحدث عن نتائج بحثي الذي استمر سبع سنوات في مجال الإرسال الصوتي عبر شبكة Tor. من المقبول عمومًا أن الاتصال الصوتي عبر Tor يكاد يكون مستحيلًا:
- بروتوكولات النقل الحالية للعمل الهاتفي عبر UDP ، ويوفر Tor اتصالات TCP فقط ؛
- يقوم Tor بتوجيه الحزم عبر عدة عقد ، مما يؤدي إلى تشفير البيانات ، مما يتسبب في زمن انتقال مهم ويجعل المهاتفة المزدوجة مستحيلة أو غير مريحة للغاية.
ولكن هل هو حقا كذلك؟
في عام 2012 ، فكرت أولاً في الإمكانية الأساسية لتنفيذ الاتصالات الهاتفية المجهولة باستخدام مجهولي الهوية Tor و i2p. كان رد فعل المجتمع سلبيًا بشكل واضح ، بما في ذلك Phil Zimmermann نفسه ، مؤلف PGPFone الشهير ، الذي عمل على أساسه Torfon الأول. لكنني كنت عنيدة ، واختبرت أفكارًا جديدة ، وتم اختبارها وتحسين الحيل التي تم العثور عليها ، والتي تهدف أساسًا إلى تقليل زمن الوصول إلى مستوى مقبول. عمل باحثون آخرون أيضًا في هذا الاتجاه ، وقد أعطتني منشوراتهم أفكارًا جديدة وأساسًا لمزيد من العمل. كانت الجوانب الإيجابية هي التسارع الكبير لشبكة الإنترنت العالمية وشبكة Tor على وجه الخصوص ، وكذلك الفطام التدريجي للمستخدمين من PSTN لصالح اتصالات GSM مع زمن انتقالها الكبير المتأصل. أخيرًا ، تم تطوير مفهوم مناسب ، وقد حان دور تنفيذ الخطة.
في عام 2013 ، انتقد روجر دينجلين في المراسلات الشخصية المشروع بشدة بسبب عدم وجود نظام أساسي (في ذلك الوقت كان يستخدم PGPFone كقاعدة على منصة ويندوز) ولهندسته المعمارية غير وحدات. على خلفية هذا النقد ، تم وضع الأساس للتطبيق الحديث لـ Torfon ، مع الأخذ في الاعتبار العديد من التجارب والخطأ ، وكذلك الاتجاهات الحديثة في التشفير.
اليوم ، يتكون Torfon من أربع وحدات برامج تتفاعل مع بعضها البعض باستخدام حزم 36 بايت مع حقول ثابتة تمامًا. هذه وحدة نقل توفر العمل مع المقابس ووحدة تشفير وصوت ووحدة تخزين (تنفذ عمليات باستخدام مفتاح خاص وتحتوي على دفتر عناوين مشفر) ووحدة واجهة مستخدم. يمكن تشغيلها على نفس النظام الأساسي للأجهزة (في واحد أو في تدفقات مختلفة) أو على العديد من الأنظمة الأساسية المعزولة باستخدام بروتوكول تسلسلي قياسي (الأجهزة UART أو USB CSD أو Bluetooth SPP) كواجهة. تتيح هذه البنية للمطور تحديد حل وسط بين الأمان وسهولة التنفيذ. تتوفر الخيارات من تطبيق Windows مستقل إلى تنفيذ الأجهزة في شكل لوحة واحدة مع Linux for Tor ووحدة نقل جنبًا إلى جنب مع متحكم Cortex M4 المعزول ، الذي يقوم بتشفير ومعالجة الصوت وتشغيله بالكامل وتخزين المفاتيح الخاصة وجهات الاتصال وتطبيق واجهة مستخدم رسومية.
تتم كتابة التعليمات البرمجية المصدر للوحدات النمطية في C وهي مشتركة بشكل كامل ، باستثناء العمل المنخفض المستوى مع الصوت ، والذي يتم نقله إلى ملفات منفصلة خاصة بـ Windows (Wave) ، Linux (Alsa) ، Android (OpenSL) و bare metal (ADC / DAC + DMA للمراقب الدقيق) ).
عند اختيار برنامج ترميز الصوت وقائمة الانتظار ، تم مراعاة ميزات شبكة Tor: التأخير التلقائي المتكرر الدوري ، وانخفاض طفيف في زمن الوصول للحزم في نطاق طول معين ، والقدرة على إنشاء سلاسل مكررة بمسارات توجيه مختلفة أثناء المكالمة ، إلخ. تضمن مشروع OnionPhone الوسيط 17 من أكثر برامج الترميز الصوتية شيوعًا. بعد الاختبار الدقيق ، تم تحديد الخيار الأنسب: معدل AMR مع معدل بتات أدنى يبلغ 4750 بت في الثانية و VAD عالي السرعة. وبالتالي ، مع الأخذ في الاعتبار التوقف الطبيعي بين الكلمات والطبيعة المزدوجة للاتصال ، يبلغ متوسط معدل البت في كل اتجاه حوالي 2000-3000 بت في الثانية ، مما يجعل من الممكن استخدام GPRS حتى في ظروف تغطية GSM الرديئة وفقدان هائل لحزم GSM.
تم تطوير خوارزمية NPP7 فعالة ككبت للضوضاء ، وتم تطويرها لمكافحة الضوضاء الصوتية الشديدة وهي جزء من برنامج الترميز MELPe ، وهو معيار الاتصالات العسكرية الحالي STANAG-4591. تم اختيار خوارزمية إلغاء الصدى من مشروع WebRTC باعتباره الحل المفتوح الأكثر فاعلية المتاح.
تم تطوير الوظيفة العامة لـ Torfon مع مراعاة حالات الاستخدام المحتملة ونماذج التهديد الحالية التي تم استخدامها بالفعل ضد برامج المراسلة الفورية الشائعة.
أوضاع التشغيل الأساسية:
- مكالمات صوتية مجهولة المصدر إلى خدمة Tor المخفية (على عنوان البصل). هذه المكالمات محمية قدر الإمكان ، ولكن هناك بعض التأخير ، مما قد يسبب بعض الانزعاج للمستخدمين غير المعتادين.
- التبديل إلى اتصال UDP مباشر (مع مرور NAT) بعد إعداد اتصال Tor. توفر مفاتيح تشفير الجلسة التي تم التفاوض بشأنها داخل Tor خصوصية قوية ، ولكن يتم إخفاء الهوية (يكشف المستخدمون عن عنوان IP الخاص بهم لبعضهم البعض).
- توجيه المكالمات إلى عنوان IP المحدد (أو اسم المجال) ورقم منفذ TCP. لتلقي هذه المكالمات ، تحتاج إلى عنوان IP "أبيض" (قابل للتوجيه) على الجهاز (يقدم العديد من مشغلي شبكات الجوال هذه كخدمة مدفوعة) أو إعادة توجيه منفذ TCP المستخدم على جهاز توجيه محلي (على سبيل المثال ، في شبكة WiFi منزلية). يمكن إجراء مكالمات مباشرة في شبكة محلية معزولة (على سبيل المثال ، شبكة WiFi محلية تم إنشاؤها باستخدام نقطة وصول قوية مثبتة في وسط منطقة الخدمة). في هذه الحالة ، لا يتطلب Torfon التفاعل مع الإنترنت: لا يحتوي المشروع على خادم خاص به ، وهو ما يمثل نقطة فشل محتملة وجمع البيانات الوصفية. وبالتالي ، يمكن أن يعمل Torfon بنجاح حتى مع العزلة الكاملة لجزء الشبكة أو Runet بالكامل على مستوى الولاية.
اليوم ، غالبًا ما يتم إثارة مسألة الثقة في Tor سواء من حيث الحفاظ على السرية أو من حيث سرية البيانات المرسلة. لم يستخدم برنامج TorChat messenger المعروف التشفير والمصادقة ، حيث اعتمد اعتمادًا تامًا على الخدمات التي يوفرها Tor. أنا شخصياً أثق في تور ، على الأقل من حيث الخصوصية والسرية المتخلفة المثالية. ولكن لسوء الحظ ، فإن هذا الموقف قد طغت عليه اكتشاف نقاط الضعف العالمية SPECTER / MELTDOWN ، بالإضافة إلى كتلة نقاط الضعف في اليوم صفر لجميع أنظمة التشغيل المعروفة التي تستخدم عمليًا كأدوات عمل في ترسانة أي خدمة خاصة. لذلك ، لم أتمكن من اتباع مسار TorChat وأضفت طبقة التشفير والمصادقة الخاصة بي إلى Torfon ، باستخدام البروتوكولات الحديثة وأولويات التشفير القوية.
يعتمد المفهوم على القدرة على إجراء مكالمات بين المشتركين غير المألوفين ، ثم تبادل مفاتيحهم العمومية تلقائيًا للمصادقة المتبادلة في جلسات التواصل اللاحقة. يوفر هذا النهج إنكارًا معينًا فيما يتعلق بوجود مفتاح تسوية في قائمة جهات الاتصال الخاصة بك: يمكن لأي مشترك ، ومعرفة عنوان البصل الخاص بك ، إجراء مكالمة مجهولة وإرسال أي اتصال لك على الفور من دفتر العناوين الخاص به. ستتم إضافة جهة الاتصال هذه تلقائيًا إلى دفتر العناوين الخاص بك. ومع ذلك ، يمكن تعطيل هذه الميزة في الإعدادات ، ولكن من يدري ما إذا كنت قد قمت بتشغيلها من قبل؟
ويولى اهتمام خاص لحماية معرفات المشترك. لذلك ، يعرف المتصل هوية المتصل ويتعين عليه إخبار هويته (مفتاح). ولكن فقط له ولا أحد آخر! علاوة على ذلك ، إذا تم اعتراض الاتصال ، بما في ذلك من قبل مهاجم نشط ، وبعد ذلك تم الكشف عن جميع المفاتيح الخاصة للمشاركين ، لا توجد طريقة لتحديد (أو الاختيار من قائمة معروفة) معرفات المشاركين في كل عينة أو جلسة اعتراض في الماضي. بمعنى آخر ، حماية معرّف المكالمة والمشتركين المدعوين بالسرية التامة العكسية (PFS). تم تحقيق ذلك من خلال تعديل بروتوكول Triple-DH (Diffie-Hellman triple ، والمستخدم أيضًا في Signal) عن طريق إضافة بروتوكول SPEKE الموازي ، والذي يوفر إفصاحًا صفريًا فيما يتعلق بالمصادقة الصريحة المتبادلة بين الطرفين أثناء تبادل المفاتيح الأولي.
يحتوي البروتوكول المستخدم في Torfon على خاصية Denability ، عندما لا يتمكن الطرف الضار من إقناع القاضي بأن جهة الاتصال قد تمت بالفعل بعد جلسة اتصال مكتملة. يتم توفير "إمكانية التقدم إلى الأمام" أيضًا عندما يوافق الطرف الضار مقدمًا مع القاضي على أنه سيدير الجلسة ، وبعد الانتهاء من الجلسة ، يحاول إثبات حدوثها. التناقض التام (التناقض التام ، عندما يتصل الطرف الخبير بالقاضي أثناء جلسة التواصل) ، يتنافس مع خاصية مهمة مثل KCI - الاستقرار (عدم القدرة على تقديم نفسه لمشترك آخر يعرف مفتاحه الخاص). بناءً على الحقائق العملية ، كان التفضيل لصالح KCI-stabil ، باعتباره خاصية أكثر عملية ، خاصةً في ظروف العلاقات غير القانونية.
من بين القدرات الإضافية لمصادقة بعضنا البعض عند جهة الاتصال الأولى (لضمان صحة تبادل المفاتيح) ، يتم تنفيذ بروتوكولين:
- مقارنة بصمة قصيرة لسر مشترك (SAS ، على غرار بروتوكول ZRTP). لمنع هجوم بصمة قصيرة أثناء عملية MitM ، يتم استخدام الالتزام في إجراء Diffie-Hellman. بالإضافة إلى ذلك ، يتم تضمين بصمة السر المشترك تلقائيًا في اسم جهة الاتصال المقبولة في هذه الجلسة. وبالتالي ، عند تبادل جهات الاتصال خلال جلسة واحدة ، يجب أن تكون بداية اسم جهة الاتصال الجديدة هي نفسها لكلا المشاركين ، والتي يمكن التحقق منها لاحقًا ، على سبيل المثال ، شخصيا. وبالمناسبة ، يجب إعادة تسمية جهة الاتصال المستلمة للسماح لـ Torfon بتمثيل نفسه (هويته) في جهة الاتصال هذه.
- مقارنة سر متفق عليه مسبقا (الكلمات والعبارات). في OTR ، يؤدي بروتوكول المليونير الاشتراكي وظيفة مماثلة. يستخدم الخث نفس بروتوكول SPEKE من حيث الخصائص (مع عدم الكشف عن الصفر).
في حالة أن يكون لكل من المشاركين في الجلسة جهات اتصال (مفاتيح عامة) لبعضهما البعض ، في حالة نجاح المصادقة واستخدام Tor (استدعاء عنوان البصل) ، يقوم الطرف المتلقي بإجراء مكالمة مضادة باستخدام عنوان البصل للطرف المتصل من دفتر العناوين الخاص به. بعد إنشاء الاتصال ، يتم إجراء المصادقة المتبادلة على القناة الثانية ، مما يؤكد عنوان البصل للمتصل. يستخدم TorChat إجراءً مماثلاً لمصادقة الدردشات ، باستخدام عنوان البصل لجهة الاتصال كمعرّف.
يتكون اتصال Parallel Tor من سلاسل أخرى ، تُستخدم بشكل مفيد للتعويض عن التأخير التلقائي: يتم إرسال الحزم الصوتية إلى كلتا القناتين في وقت واحد ، ويتم استخدام الحزمة المستلمة مسبقًا. بالإضافة إلى ذلك ، يتم الاحتفاظ بإحصائيات حول التأخير في كلتا القناتين ، وإذا كانت إحدى القنوات أبطأ بكثير ، فيتم إعادة توصيلها بشكل دوري أثناء المحادثة. هذا يقلل من الكمون الكلي للمكالمة المصادق عليها مقارنة بمكالمة من مشترك غير معروف.
كما تبين الممارسة الحزينة ، من المهم جدًا اليوم تدريس التطبيق للدفاع عن نفسه ضد الأقفال المحتملة. لحسن الحظ ، لا يحتوي Torfon على خادم أو سحابة خاصة به ، ويستخدم Tor بدلاً من ذلك. لذلك ، يمكن حظر Torfon فقط عن طريق قفل Tor. ولكن اليوم أصبح أيضًا حقيقة واقعة ، وفي هذه الحالة لن يكون هناك سوى إمكانية إجراء مكالمات مباشرة إلى عنوان IP ومنفذ TCP. في السيناريو الأكثر تشاؤماً ، سيحاول الأخ الأكبر تعليم أنظمة DPI (تحليل الحزمة العميقة) لاكتشاف حركة المرور بين اثنين من Torfons في شبكة p2p محكومة. لذلك ، اتخذت تدابير إضافية لزيادة إخفاء هذه الحركة. أولاً ، يمكن اختيار منفذ الاستماع TCP يدويًا وهو في الواقع جزء من عنوان المشترك. ثانياً ، لا تحتوي جميع الحزم (بما في ذلك الصوت) أثناء جلسة الاتصال (جلسة TCP) على أي ميزات مميزة (حقول ثابتة أو تدريجية ، أطوال ، وما إلى ذلك) وتبدو وكأنها بيانات عشوائية ذات طول عشوائي إلى مراقب خارجي . ثالثًا ، لإجراء عينة نشطة من البروتوكول ، يلزم تقديم "إثبات الوظيفة" كحماية من المسح الشامل للعناوين والمنافذ للكشف عن الخث.
في الواقع ، يتم الاتصال من خلال اتصالين TCP متتاليين. أثناء الاتصال الأول ، تتبادل الأطراف مفاتيح الجلسة الأساسية في شكل نقاط على المنحنى الإهليلجي X25519 ، مما يؤدي إلى بروتوكول Diffie-Hellman المعتاد. نظرًا لأن تنسيق Montgomery لتمثيل النقطة ليس رقمًا عشوائيًا ، يتم استخدام تمثيل Elligator2 ، المضاف إلى وحدات البايت العشوائية. بعد إزالة السر المشترك ، يتم كسر الجلسة الأولى ، وبعد فترة زمنية عشوائية (عدة ثوان) ، يتم إنشاء الجلسة الثانية ، وجميع البيانات التي يتم تشفيرها باستخدام مفتاح مشتق من السر المشترك. يتم إنشاء مفاتيح جلسة جديدة ، ويتم تنفيذ بروتوكول Diffie-Hellman مرة أخرى ، والآن مع تعليق. وتستمد المفاتيح المتماثلة للتشفير وفك التشفير من السر الذي تم الحصول عليه. ثم يتم تشغيل بروتوكول Diffie-Hellman الثلاثي بالتوازي مع بروتوكول SPEKE لحماية معرف المتصل والمصادقة. في حالة عدم وجود مفاتيح في دفتر العناوين (جهة اتصال غير معروفة) أو أي تباين ، يتم استبدال جميع الرسائل بوحدات بايت عشوائية. لا يتم مقاطعة البروتوكول لمنع تسرب معلومات هوية المشاركين.
لتنفيذ هذه البروتوكولات ، يتم استخدام رموز المصدر C التي تم التحقق منها بعناية للأولويات المشفرة ، مأخوذة من مكتبات تشفير معروفة. للتحقق في مرحلة التطوير ، تم استخدام متجهات اختبار معروفة ، وبعد كل تشغيل للتطبيق ، يتم إجراء تحقق إضافي لتطبيق معين من التعليمات البرمجية القابلة للتنفيذ (نتيجة التحويل البرمجي).
بالنسبة لطبقة التشويش ، تم اختيار خوارزمية Serpent-128 المتماثلة ، والتي تعمل في وضع تشفير OCB المصادق. بالنسبة للطبقة الأساسية من التشفير المتماثل ، يتم تحويل Keccak-800 كدالة Shake-128 وعداد حزمة CTR أحادي الاتجاه. يتم استخدام نفس البدائية مثل Hash و MAC و PKDF. يتم استخدام خوارزمية ChaCha20 لتشفير دفتر العناوين ومولد الأرقام العشوائية الزائفة. يقع المولد في بداية كل جلسة ، لتراكم الإنتروبيا في أنظمة التشغيل متعددة المهام ، يتم استخدام خوارزمية Havege ، وفي المتحكم الدقيق ، أقل جزء من نتائج ADC ، والذي يقيس ضوضاء الفاصل المقاوم. يتراكم الانتروبيا إلى الكمية المطلوبة ، ويقدر باستخدام اختبار تردد المجموعة.
تستخدم أوليات التشفير الرئيسية (رياضيات أولية لـ X25519 و Keccak800 و ChaCha20) تطبيقات مجمّع محسنة للمترجمين لمنصات متحكم دقيق (Cortex M1 و M4) ، تم اختبارها بعناية لوقت التنفيذ الثابت وتقليل التسرب من خلال القنوات الجانبية للإشعاع الكهرومغناطيسي وتقلبات الاستهلاك الحالية. يجب أن أقول على الفور - لقد تم استلام هذه الرموز المجمعة من محترفين مشهورين على مستوى العالم ، لقد نقلتها للتو من GNU ASM إلى بيئة Keil ، والتي تعد مألوفة أكثر لبناء المشاريع المدمجة.
حسنا ، ماذا في النهاية؟
إذا قرأت هذا المكان ولم تموت من الملل ، فهذا يعني أن هذا المشروع يمكن أن يكون مفيدًا لك حقًا. إذا كان الأمر كذلك ، فعند طلب ذلك عن طريق البريد ، يسعدني تقديم مجموعات اختبار (الملفات القابلة للتنفيذ المرتبطة بشكل ثابت ، لا يلزم التثبيت) ، وكذلك شفرة المصدر للواجهة الرسومية لنظامي التشغيل Windows و Linux و Android في بيئات التطوير المعنية. يعتمد جوهر المشروع على مكتبة torfone عبر النظام الأساسي ، والمتاحة في بحث جيثب. هناك يمكنك أيضًا العثور على روابط مباشرة إلى إصدار alpha من تطبيق Android ودليل موجز لتثبيته واستخدامه ، مما سيساعد الجميع على تقييم زمن الانتقال الهاتفي في شبكة Tor.
يتم تطبيق الواجهة الرسومية بشكل منفصل لكل نظام أساسي وليست خيارًا (حتى الآن هذا اختبار ألفا فقط). تم تشغيل تطبيق الاختبار لجميع إصدارات Windows (بدءًا من نظام التشغيل Windows 98 القديم) في تطبيق Borland C ++ Builder 6. ولكنه قوي. بالنسبة لنظام Linux ، تم تطوير تطبيق واجهة المستخدم الرسومية باستخدام تطبيق Wide Studio for X11 المنسي بشكل منفصل لبنيي i386 و ARM. الأول يجب أن يعمل على كل من أجهزة سطح المكتب 32 بت و 64 بت ، والثاني - على أجهزة كمبيوتر أحادية اللوحة غير مكلفة: RPi ، و Orange ، و Nano ، وما إلى ذلك. يتوفر ملف APK تم تجميعه في Embarcadero RAD Studio 10.2 لنظام Android. هذا أبعد ما يكون عن الخيار الأفضل ولا يزال لا يعرف كيفية إنشاء خدمة مقدمة ، ومع ذلك ، يعمل بثبات في الخلفية مع تعطيل استخدام البطارية. أيضًا ، تدعم بيئة Android النسخ الاحتياطي التلقائي لملفات التكوين والمفاتيح ودفتر العناوين (بشكل مشفر) إلى وحدة تخزين واسترداد خارجية عند إعادة تثبيت Torfon أو نقله إلى جهاز آخر. في وقت كتابة هذا التقرير ، كان العمل جارياً في مشروع في بيئة Keil uVision ، والذي يتضمن وحدات نقل وتشفير وواجهة صوتية ورسومية تستند إلى Arduino - شاشة متوافقة مع 320 * 240 TFT + Touch. سيتم استخدام NanoPi Neo المزود بخادم دبيان المثبت ولوحة Nucleo STM32F446RE المتصلة عبر UART فعلي كمنصة مفتوحة للأجهزة.
في الخطط طويلة الأجل - الانتقال إلى نظام التشغيل iOS ، على الرغم من أنني بالكاد أفهم كيف يمكن دمج هذا مع الضمانات الأمنية الأساسية.وفي الختام.غالبًا ما يتم طرح نفس الأسئلة: كيف يمكنني إدارة المستخدمين دون خادم مركزي؟ كيفية رمي التحديثات ، والإعلانات؟ والأهم من ذلك ، لماذا أحتاج كل هذا إذا لم تكن هناك قيمة تجارية في هذا؟في الواقع ، العالم ليس رماديًا ومدمّرًا. وهناك العديد من القيم التي لا يمكن قياسها بالمال. لكن الجواب على السؤالين الأولين - بأي حال من الأحوال. حسنًا ، لا يمكنك إيقاف Turfon. لا يمكنك الحصول على "مفاتيح" منه ، لا يمكنك دمج تصرفات المستخدمين ، حتى أولئك الذين لوحظوا في الإرهاب أو الاعتداء الجنسي على الأطفال ، لا يمكنك حظر الأشخاص غير المرغوب فيهم. لا يمكنك فرض التحديثات. لا يمكنك التحكم من الخارج. لا توجد تسريبات أو مركبات جانبية في Torfon ، باستثناء ما هو منصوص عليه في البروتوكول. يمكن التحقق من ذلك بسهولة في الكود (يتم تعليق كل سطر تقريبًا ولا يوجد الكثير من الملفات في المشروع) ، وكذلك محللي الشبكات. لذلك ، لن يتمكن أي شخص من إدارة مستخدمي Torfon. ولكن تذكر: Torfon هو مجرد أداة ، وجميع أفعالك على ضميرك ، وأنت مسؤول عنهم ، وليس مؤلف المشروع.