ثغرة في بروتوكول Attested TLS تهدد الأساس الأمني للحوسبة السرية

أبرز النقاط

• بروتوكول Attested TLS يتحقق من سلامة البرمجيات لكنه يفشل في إثبات موقع الخادم الفعلي
• سبع آليات ربط تشفيرية خضعت للاختبار ولم تمنع أي منها هجمات الترحيل
• الإصلاح الكامل قد يكون مستحيلاً ضمن بنية TLS 1.3 الحالية

تُروّج شركات التقنية الكبرى للحوسبة السرية (Confidential Computing) باعتبارها العمود الفقري لمشاريع السحابة السيادية في أوروبا والخليج العربي. لكن بحثاً أكاديمياً جديداً يكشف أن البروتوكول المُصمم لإثبات الثقة التشفيرية في هذه الأنظمة يعاني من خلل بنيوي جوهري قد لا يوجد له إصلاح.

ما هي الحوسبة السرية ولماذا تهمّ صناع القرار؟

تعتمد الحوسبة السرية على آلية تُسمى التصديق عن بُعد (Remote Attestation)، حيث يُثبت الخادم تشفيرياً للعميل أنه يعمل داخل بيئة تنفيذ موثوقة (TEE) غير معدّلة قبل تبادل أي بيانات حساسة. تُقدّم Intel تقنية TDX بوصفها ضامنة لسيادة البيانات، بينما تصف Google Cloud بنيتها التحتية بأنها توفر تحكماً كاملاً وقابلاً للتدقيق في الوصول إلى بيانات العملاء.

ماذا اكتشف الباحثون في بروتوكول Attested TLS؟

أمضى الباحث محمد أسامة سردار من جامعة TU Dresden عامين في التحقق الرياضي من بروتوكول Attested TLS باستخدام أداة ProVerif المتخصصة في التحليل الأمني الرمزي للبروتوكولات. النتيجة: البروتوكول لا يفعل ما يدّعيه.

في ورقتهم البحثية Identity Crisis in Confidential Computing المنشورة مع الباحثين مريم مصطفى وتوماس أورا والمقدمة في مؤتمر AsiaCCS 2026، اكتشف الفريق هجمات تحويل (Diversion Attacks) ضد بروتوكولين متقدمين من Attested TLS. يمكن إعادة توجيه اتصال مخصص لخادم معين إلى جهاز مخترق آخر يشغّل برمجيات مطابقة في أي مكان بالعالم، دون أن يعلم العميل بذلك إطلاقاً.

لماذا يتحقق البروتوكول من البرمجيات لا من الموقع؟

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

الورقة البحثية الثانية Intra-handshake.fail، المنشورة مع فياتشيسلاف دوبيكو وجان-ماري جاكيه والمقبولة في مؤتمر ESORICS 2026، تفحص ما تسميه الصناعة التصديق أثناء المصافحة (Intra-handshake Attestation) حيث يُولّد الدليل خلال مصافحة TLS ذاتها.

ثلاثة مستويات من الثقة التشفيرية

صاغ الباحثون المشكلة في ثلاثة مستويات متصاعدة من الربط التشفيري بين دليل التصديق واتصال TLS الفعلي:

• المستوى الأول: يربط الدليل بخطوة Diffie-Hellman الأولية فقط، قبل إثبات هوية أي طرف
• المستوى الثاني: يربط الدليل بمفتاح حركة المصافحة للعميل حتى تأكيد هوية الخادم
• المستوى الثالث: يربط الدليل بمفتاح حركة التطبيق المستخدم فعلياً لتشفير البيانات الحساسة

ثلاث آليات فقط من السبع المفحوصة حققت المستوى الأول. البقية فشلت حتى في هذا الحد الأدنى. الحل المقترح من فريق سردار، وهو رابط تشفيري مبني من سر مصافحة TLS مع المفتاح العام للخادم، يحقق رسمياً المستوى الثاني فحسب.

ماذا يعني هذا للأنظمة الإنتاجية؟

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

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

التداعيات على السحابة السيادية والاستثمارات الأوروبية

تسعى أوروبا عبر مبادرة Gaia-X واستثمارات تتجاوز 1.2 مليار يورو لبناء سحابة سيادية تعتمد جوهرياً على وعود الحوسبة السرية. لكن تقريراً سابقاً أشار إلى أن الشريحة تحت الشريحة، أي محركات الإدارة العاملة أسفل نظام التشغيل في معالجات Intel وAMD، تقع خارج نطاق ما تُقيّمه أُطر السيادة الأوروبية مثل SecNumCloud فعلياً.

السوق العالمية للحوسبة السرية متوقع أن تصل إلى 54.4 مليار دولار بحلول 2030، وأكثر من 90% من أعباء العمل السحابية تعمل على معالجات Intel أو AMD. هذا يعني أن ثغرة على مستوى البروتوكول تملك نطاق انفجار هائل يطال المنظومة بأكملها.

الأسئلة الشائعة

هل تؤثر ثغرة Attested TLS على خدمات السحابة في الإمارات والسعودية؟

نعم، أي خدمة سحابية تستخدم الحوسبة السرية المبنية على Intel TDX أو AMD SEV تتأثر بهذه الثغرة البنيوية بغض النظر عن موقعها الجغرافي، بما في ذلك مراكز البيانات في المنطقة.

ما الفرق بين Attested TLS وبروتوكول TLS العادي؟

TLS العادي يُشفّر الاتصال ويتحقق من هوية الخادم عبر الشهادات. Attested TLS يُضيف طبقة تصديق تُثبت أن الخادم يعمل داخل بيئة تنفيذ موثوقة (TEE)، لكن البحث يُظهر أن هذه الطبقة لا تربط الدليل بالاتصال الفعلي بشكل كافٍ.

هل يوجد إصلاح لثغرة الحوسبة السرية؟

الإصلاح الكامل قد يكون مستحيلاً ضمن بنية TLS 1.3 الحالية. الحل المقترح من الباحثين يحقق المستوى الثاني من الحماية فقط، بينما المستوى الثالث الضروري لحماية البيانات الفعلية يتطلب تغييرات جوهرية في البروتوكول.

ما هي بيئة التنفيذ الموثوقة TEE؟

هي منطقة معزولة في المعالج تحمي الكود والبيانات أثناء المعالجة حتى من نظام التشغيل ومدير السحابة. تشمل التطبيقات Intel SGX وTDX وAMD SEV وARM CCA.

كيف يمكن للمؤسسات حماية بياناتها حالياً؟

ينبغي إضافة طبقات تحقق على مستوى التطبيق، ومراجعة نماذج التهديد، وعدم الاعتماد كلياً على وعود الحوسبة السرية. المراقبة المستمرة للتحديثات الأمنية من Intel وAMD ضرورية.