From Specs to Apps: Verifying and Monitoring Models of Signal and WhatsApp
تجسر هذه الورقة البحثية الفجوة بين المواصفات البروتوكولية الرسمية والتنفيذات الواقعية باستخدام أداة المراقبة وقت التشغيل SpecMon للتحقق من أن التنفيذات المرصودة لـ WhatsApp Web وSignal Desktop تتوافق مع نماذج مطورة حديثاً ومتوافقة مع Tamarin، مما يؤكد الخصائص الأمنية ويكشف عن الاختلافات غير الموثقة بين التطبيقين.
المؤلفون الأصليون:Moustafa Said, Aurora Naska, Kevin Morio, Robert Künnemann
في العصر الرقمي، يعتمد مليارات البشر على تطبيقات المراسلة لمشاركة أكثر أفكارهم خصوصية، وتأمين بياناتهم المالية، وتنسيق حياتهم اليومية. وخلف كواليس هذه التطبيقات يكمن مجموعة معقدة من القواعد تُعرف باسم "البروتوكول"، والذي يعمل بمثابة المخطط لكيفية تشفير الرسائل وإرسالها وفك تشفيرها. وأشهر هذه المخططات هو "بروتوكول سيجنال" (Signal protocol)، وهو نظام صُمم لضمان أنه حتى لو اعترض مخترق رسالة ما، فإنه لن يتمكن من قراءتها. لسنوات طويلة، استخدم خبراء الأمن أدوات حاسوبية قوية لإثبات أن هذا المخطط سليم من الناحية الرياضية؛ حيث أظهروا أنه إذا تم اتباع القواعد بدقة، فإن النظام سيكون غير قابل للاختراق. ومع ذلك، فإن المخطط ليس هو البناء نفسه؛ فمجرد كون التصميم يبدو مثاليًا على الورق لا يعني أن طاقم البناء اتبع كل التعليمات، أو استخدم المواد الصحيحة، أو تجنب الأخطاء العرضية أثناء بناء الجدران. وفي عالم البرمجيات، تكمن الثغرات الأمنية غالبًا في الفجوة بين التصميم النظري والكود الفعلي الذي يعمل على هاتف المستخدم.
لقد سعى فريق من الباحثين في مركز "سيسبا هيلمهولتز للأمن المعلوماتي" (CISPA Helmholtz Center for Information Security) لسد هذه الفجوة. أرادوا معرفة ما إذا كانت النسخ الواقعية من بروتوكول "سيجنال"، كما تعمل داخل تطبيقي "واتساب" و"سيجنال"، تتبع بالفعل القواعد الصارمة التي صُممت للالتزام بها. وبدلاً من محاولة قراءة كامل الكود المصدري لهذه التطبيقات الضخمة — وهي مهمة جعلها عدم الوضوح أو انغلاق بعض أجزائها أمراً صعباً — قام الباحثون ببناء "رقيب" متخصص. هذا الرقيب، الذي يُسمى "سبيك مون" (SpecMon)، يراقب التطبيق أثناء تشغيله، ويستمع إلى كل محادثة يجريها مع الشبكة وكل عملية حسابية يجريها مع مفاتيح الأمان الخاصة به. وهو يقارن هذه الأفعال الحية بالنموذج النظري المثالي في الوقت الفعلي؛ فإذا حاول التطبيق اتخاذ طريق مختصر، أو تخطي خطوة، أو استخدام طريقة مختلفة عما يسمح به المخطط، يطلق الرقيب إنذاراً.
طبق الباحثون هذه الطريقة على تطبيقين رئيسيين: "سيجنال ديسكتوب" (Signal Desktop)، وهو مفتوح للمراجعة من قبل أي شخص، و"واتساب ويب" (WhatsApp Web)، وهو نظام مغلق ومملوك لشركة ضخمة. بالنسبة لتطبيق "سيجنال ديسكتوب"، بدأوا بنموذج رياضي موجود ومفصل للغاية للبروتوكول، وأضافوا إليه التفاصيل المعقدة الموجودة في البرمجيات الفعلية، مثل كيفية تعامله مع أنواع جديدة من التشفير المصممة لمقاومة الحواسيب الكمومية المستقبلية. أما بالنسبة لـ "واتساب"، فقد اضطروا للعمل بشكل عكسي؛ فبدءاً من عدم وجود نموذج مسبق، راقبوا سلوك التطبيق، وسجلوا أفعاله، وبنوا مخططاً جديداً مخصصاً يتطابق تماماً مع ما تفعله البرمجيات. كان هذا إنجازاً كبيراً، حيث كان أول مرة يتم فيها اشتقاق نموذج رسمي مباشرة من تنفيذ نسخة "واتساب" للبروتوكول.
بمجرد تجهيز هذه النماذج، وضع الباحثون الاختبار عليها. أجروا آلاف المحادثات المحاكية، بما في ذلك سيناريوهات تأخرت فيها الرسائل، أو أُرسلت بترتيب خاطئ، أو حيث انقطع الاتصال بالشبكة. وفي كل حالة، تصرفت التطبيقات تماماً كما توقعت النماذج، مما أكد أن آليات الأمان الأساسية تعمل بشكل صحيح. كما قام الباحثون بحقن أخطاء متعمدة في البرمجيات لمعرفة ما إذا كان "الرقيب" الخاص بهم سيكتشفها. لقد جعلوا التطبيقات تعيد استخدام مفاتيح تشفير قديمة، أو تتخطى عمليات التحقق من التوقيع، أو تسرب بيانات سرية بطرق غير متوقعة. وقد رصد النظام كل واحدة من هذه الأخطاء الأمنية، مما أثبت أن أداة المراقبة حساسة بما يكفي لرصد الانحرافات الخطيرة عن القواعد.
ومع ذلك، كشفت المراقبة أيضاً عن اختلافات دقيقة بين التطبيقين لم تكن واضحة للوهلة الأولى. وجد الباحثون أن "واتساب" يتعامل مع "إيصالات القراءة" — وهي الإشعارات التي تخبر المرسل بأن الرسالة قد تمت قراءتها — بشكل مختلف عن "سيجنال". في "سيجنال"، يتم تغليف هذه الإيصالات بنفس التشفير القوي المستخدم في الرسائل وتشارك في التحديث المستمر لمفاتيح الأمان. أما في "واتساب"، فتُرسل هذه الإيصالات خارج طبة التشفير تلك، مما يعني أنها لا تحفز تحديثات أمنية مماثلة. وبينما لم يجد الباحثون طريقة لكسر أمان "واتساب" بناءً على هذا الاختلاف، إلا أنهم أشاروا إلى أن هذا يعني أن التطبيق قد يستغرق وقتاً أطول لاستعادة أمانه إذا ما سُرق مفتاح سري ما. كما أكدوا أن "واتساب" لا يتضمن بعد ميزات الخصوصية المتقدمة، مثل إخفاء هوية المرسل عن الخادم، والتي تتوفر في تطبيق "سيجنال".
تُظهر هذه الدراسة أنه من الممكن مراقبة البرمجيات المعقدة في العالم الحقيقي والتحقق من التزامها بوعودها الأمنية دون الحاجة لرؤية كل سطر من كودها المصدري. كانت العملية فعالة، حيث استغرقت بضعة أسابيع فقط للإعداد والتشغيل، ولم تضف سوى قدر ضئيل جداً من التأخير إلى سرعة التطبيقات. ومن خلال إنشاء نظام يتشارك فيه النموذج النظري والمراقبة الحية نفس اللغة، قدم الباحثون طريقة للمطورين وخبراء الأمن للتحقق باستمرار من بقاء تطبيقاتهم آمنة مع تطورها. يوفر هذا النهج مساراً جديداً لبناء الثقة في الأدوات الرقمية التي نستخدمها كل يوم، مما يضمن أن المباني التي نسكن فيها آمنة بقدر المخططات التي بُنيت منها.
ملخص تقني: من المواصفات إلى التطبيقات: التحقق ومراقبة نماذج بروتوكول Signal وWhatsApp
بيان المشكلة
بينما يشكل بروتوكول Signal الركيزة الأساسية لمليارات الاتصالات الآمنة (بما في ذلك WhatsApp وSignal)، توجد "فجوة تحقق" كبيرة بين الضمانات الأمنية الرسمية والسلوك الفعلي أثناء التشغيل. لقد قدمت الأبحاث المكثفة براهين أمنية رسمية قوية لمواصفات البروتوكول باستخدام أدوات مثل Tamarin وProVerif. ومع ذلك، تعتمد هذه البراهين على نماذج مجردة غالبًا ما تغفل تفاصيل التنفيذ، مثل البدائيات التشفيرية المحددة، أو تنسيقات الرسائل، أو منطق إدارة الحالة. علاوة على ذلك، ورغم أن البروتوكول مفتوح المصدر، فإن التنفيذات الرئيسية مثل WhatsApp هي مغلقة المصدر، مما يجعل من الصعب التحقق مما إذا كان الكود المنشور يلتزم بالنموذج النظري. غالبًا ما تتطلب تقنيات التحقق الساكن (مثل التحقق من الكود أو إثبات النظريات) جهد إثبات كبير أو تكون محدودة بتنفيذات معينة. هناك حاجة إلى نهج ديناميكي يمكنه التحقق مما إذا كانت عمليات التنفيذ المرصودة للتطبيقات الواقعية تتوافق مع نماذج البروتوكول الرسمية الخاصة بها.
المنهجية
يسد المؤلفون هذه الفجوة من خلال تطبيق SpecMon، وهو محرك مراقبة وقت التشغيل، للتحقق مما إذا كانت التنفيذات المرصودة تتوافق مع نماذج البروتوكول الرسمية. تتضمن المنهجية ثلاث مراحل رئيسية:
التوسيم واستخراج الأحداث (Instrumentation and Event Extraction):
Signal Desktop (مفتوح المصدر): قام المؤلفون بتوسيم مكتبة libsignal (بلغتي Rust/JavaScript) لتسجيل المدخلات، والمخرجات، وقيم الإرجاع للوظائف التشفيرية والشبكية.
WhatsApp Web (مغلق المصدر): باستخدام Chrome DevTools، قام المؤلفون بتوسيم بيئة المتصفح ديناميكيًا. لقد اعترضوا استدعاءات WebSocket والوظائف التشفيرية من خلال مطابقة تتبعات مكدس التشغيل (stack traces) وأسماء الوظائف مع الورقة البيضاء لبروتوكول Signal، مما خلق رؤية "الصندوق الأسود" للتنفيذ مغلق المصدر.
مجمع الأحداث (Event Aggregator - EA): مكون مسؤول عن التقاط هذه الأحداث، والتعامل مع تهيئة ما قبل التتبع (استخراج مفاتيح الجلسة من قواعد البيانات المشفرة أو ذاكرة المتصفح)، وتوجيه تدفق أحداث موحد إلى المراقب.
بناء النموذج وتكييفه (Model Construction and Adaptation):
طور المؤلفون نماذج إعادة كتابة المجموعات (Multiset-Rewrite - MSR) المتوافقة مع Tamarin.
نموذج Signal: قاموا بتوسيع نماذج Tamarin الحالية (X3DH، Double Ratchet) لتشمل تبادل المفاتيح لما بعد الكم (PQXDH)، ومرسل مختوم (Sealed Sender)، واشتقاقات مفاتيح تشفير محددة تم رصدها في التنفيذ. نتج عن ذلك أكثر نموذج تفصيلي لبروتوكول Signal حتى الآن.
نموذج WhatsApp: بدءًا من الصفر باستخدام آثار التشغيل فقط، استخلصوا أول نموذج رسمي لنسخة بروتوكول Signal المستخدمة في WhatsApp Web.
لغة موحدة: استخدموا لغة مواصفات موحدة، حيث تقوم سلاسل التنسيق (format strings) بتحليل السلاسل البتية (bitstrings) الملموسة للمراقبة، بينما تُستخدم المصطلحات الرمزية للتحقق عبر Tamarin. قامت قواعد إعادة كتابة التتبع بتطبيع استدعاءات الوظائف الخاصة بالتنفيذ (مثل aes_encrypt) إلى رموز نموذجية (مثل senc).
المراقبة والتحقق في وقت التشغيل (Runtime Monitoring and Verification):
SpecMon (متصل/Online): يراقب تدفق الأحداث الحي مقابل نموذج MSR الموسع. ويتحقق من الامتثال لمنطق البروتوكول، ويكتشف الانحرافات مثل التسلسل غير الصحيح، أو عدم تطابق التنسيق، أو انتقالات الحالة غير الصالحة.
Tamarin (غير متصل/Offline): يُستخدم للتحقق رسميًا من الخصائص الأمنية (المصادقة والسرية) على النسخ الرمزية من النماذج.
التحقق (Validation): استخدم المؤلفون أداة فحص عشوائي (fuzzer) لتوليد أنماط اتصال متنوعة (رسائل خارج الترتيب، سقوط الجلسات، إعادة المحاولة) لاختبار النماذج والتوسيم تحت الضغط.
المساهمات الرئيسية
جدوى المراقبة في بيئة الإنتاج: تثبت الورقة أول تطبيق ناجح لـ SpecMon على تطبيقات مراسلة ذات نطاق إنتاجي (Signal Desktop وWhatsApp Web) مع حمل تشغيلي منخفض تم قياسه.
نموذج Signal التفصيلي: أنشأ المؤلفون النموذج الأكثر تفصيلًا لبروتوكول Signal حتى الآن، حيث وحدوا ووسعوا نماذج Tamarin السابقة لتشمل PQXDH، وSealed Sender، وخطوات اشتقاق المفاتيح المحددة التي لوحظت في التنفيذ.
أول نموذج رسمي لـ WhatsApp: استخلصوا أول نموذج رسمي لتنفيذ WhatsApp Web لبروتوكول Signal مباشرة من آثار التشغيل، دون وجود مواصفات مسبقة.
التحقق من الخصائص الأمنية: باستخدام Tamarin، تحققوا من المصادقة وسرية مفتاح الجذر الأولي لكلا النموذجين. كما استعرضوا نتيجة استحالة فيما يتعلق بأمن ما بعد الاختراق (PCS) في سياقهم.
الكشف عن الاختلافات في التنفيذ: كشفت المراقبة عن اختلافات غير موثقة بين libsignal الأصلية ونسخة WhatsApp المعدلة، وتحديدًا فيما يتعلق بـ:
إيصالات القراءة (Read Receipts): يقوم WhatsApp Web بإرسال إيصالات القراءة خارج طبة تشفير Double Ratlet (معالجة من جانب الخادم)، بينما يدمجها Signal Desktop ضمن بروتوكول DR.
تبني الميزات: يفتقر WhatsApp Web إلى آليات ما بعد الكم (PQXDH) وSealed Sender، الموجودة في Signal Desktop.
النتائج
مطابقة النموذج: أثبتت المراقبة أن التنفيذات المرصودة لكلا التطبيقين تتوافق مع نماذجها الخاصة بالنسبة لاستخراج الأحداث الموثوق والتجريد الرمزي.
كشف الأعطال: نجح النظام في اكتشاف أعطال أمنية تم حقنها عمدًا، بما في ذلك:
تسريب الأسرار الحرجة (عبر أحداث غير متوقعة أو سلاسل تنسيق غير متطابقة).
الاستخدام غير الصحيح للمكتبات التشفيرية (مثل إعادة استخدام مفاتيح DH الخاصة، أو تخطي فحص التوقيع).
الأداء: قدمت عملية التوسيم حملًا منخفضًا.
وقت المعالجة: 0.277–0.336 مللي ثانية لكل حدث لـ Signal؛ 0.082–0.257 مللي ثانية لـ WhatsApp.
استخدام الذاكرة: تراوح ذروة الـ RSS بين 22 ميجابايت و53 ميجابايت اعتمادًا على عبء العمل.
زمن الاستجابة (Latency): أضاف التوسيم متوسط قدره 0.30 مللي ثانية إلى زمن الاستجటు من طرف إلى طرف لتشفير الرسائل في Signal Desktop (الأساس ~2.76 مللي ثانية).
قابلية التكرار: استغرقت دورة العمل بأكملها (تطوير النموذج، التوسيم، الفحص، والتجارب) لـ WhatsApp Web حوالي ثلاثة أسابيع عمل لشخص واحد.
الأهمية والادعاءات
تدعي الورقة أن هذا العمل يوفر منهجية عملية لإرساء الثقة في تطبيقات المراسلة من خلال ربط المواصفات الرسمية بسلوك وقت التشغيل. تكمن الأهمية في:
سد الفجوة: تربط بشكل صريح بين الضمانات النظرية لبروتوكول Signal والسلوك الفعلي للنماذج المغلقة والمفتوحة المصدر.
نقطة تحقق مشتركة: من خلال الحفاظ على نسخ متقاربة جدًا للمراقبة والتحقق من نموذج MSR واحد، يخلق النهج نقطة تحقق مشتركة. النماذج المقبولة تتوافق مع النسخة القابلة للمراقبة، بينما تربط التحويلات الموثقة النموذج بالبرهان، مما يجعل فجوات التجريد صريحة.
التحقق المستمر: يقترح المؤلفون إمكانية دمج النماذج القابلة للمراقبة في دورة التطوير للتحقق المستمر، لتعمل كوثائق قابلة للتنفيذ وأدوات اختبار عميقة.
الثقة للمستخدمين والشركات: توفر المنهجية للمستخدمين المطلعين تقنيًا طريقة لبناء ثقة أكبر في تطبيقاتهم، وتوفر للشركات نهجًا منهجيًا لتوثيق وصيانة صحة البروتوكول بمرور الوقت.
يظل المؤلفون متواضعين، مشيرين إلى أن النهج يعتمد على استخراج أحداث موثوق ولا يمكنه اكتشاف السلوكيات خارج تدفق الأحداث (مثل القنوات الجانبية، أو تسريبات الذاكرة، أو الأخطاء في المسارات غير المختبرة). كما أشاروا إلى أنه رغم ملاحظة اختلافات في تردد DH ratchet بين WhatsApp وSignal، إلا أنهم لم يثبتوا هجومًا ملموسًا بناءً على هذا الاختلاف، تاركين تحليل خصائص التعافي الأكثر دقة كعمل مستقبلي.