دليل المطورين الموجه لـ TEE

المؤلفون: براتيك ، روشان ، سيدهارثا ولينجويني (Marlin) ، كرين (Asula) المترجم: Shew ، GodRealmX

منذ إعلان Apple عن السحابة الخاصة وتوفير NVIDIA للحوسبة السرية في وحدة تحكم المعالجة الرسومية (GPU) ، أصبحت بيئات التنفيذ الموثوقة (TEE) أكثر شيوعًا. يساعد ضمان السرية على حماية بيانات المستخدم (التي قد تتضمن المفتاح الخاص) ، بينما يضمن العزلة أن تنفيذ البرامج التي يتم نشرها عليه لا يتم تلاعبه - سواء من قبل البشر أو برامج أو أنظمة التشغيل. لذلك ، فإن استخدام TEE بشكل كبير في بناء المنتجات في مجال Crypto x AI ليس أمرًا غريبًا.

كما هو الحال مع أي تكنولوجيا جديدة ، يمر TEE بفترة تجريبية متفائلة. يهدف هذا المقال إلى توفير دليل مفاهيمي أساسي للمطورين والقراء العامين لمساعدتهم على فهم ما هو TEE ، نموذج أمان TEE ، الثغرات الشائعة وأفضل الممارسات الأمنية لاستخدام TEE. (* ملاحظة: من أجل جعل النص سهل الفهم ، قمنا بعمد استبدال مصطلحات TEE بكلمات مكافئة أبسط).

ما هو TEE

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

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

!

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

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

نموذج الأمان

للأسف، هناك العديد من أنواع تنفيذ TEE، وهذه التنفيذات المختلفة (Intel SGX، Intel TDX، AMD SEV، AWS Nitro Enclaves، ARM TrustZone) تتطلب جميعها نمذجة تحليل أمنية مستقلة. في بقية هذه المقالة، سنناقش بشكل رئيسي Intel SGX و TDX و AWS Nitro، لأن هذه الأنظمة TEE لديها عدد أكبر من المستخدمين وتتوفر لديها أدوات تطوير كاملة. وهذه الأنظمة المذكورة أعلاه هي أيضًا الأنظمة TEE الأكثر استخداما في Web3.

بشكل عام، يتبع تدفق عمل التطبيق المستحدث في TEE التالي:

1. “المطورون” كتبوا بعض الشفرات، وقد تم نشرها مفتوحة المصدر أو قد لا تكون
2. ثم يقوم المطور بتعبئة الشفرة في ملف صورة Enclave (EIF) الذي يمكن تشغيله داخل TEE.
3. EIF يتم استضافتها على خادم مع نظام TEE. في بعض الحالات ، يمكن للمطورين استخدام جهاز كمبيوتر شخصي مزود بـ TEE لاستضافة EIF مباشرة لتقديم الخدمة الخارجية.
4. يمكن للمستخدم التفاعل مع التطبيق من خلال واجهة محددة مسبقًا.

!

واضح أن هناك 3 مخاطر محتملة:

• المطورين: ما هو دور تحضير كود EIF؟ قد لا يتوافق كود EIF مع منطق العمل الذي يتم ترويجه من قبل الشركة المشروعة، وقد يتم سرقة بيانات خاصة للمستخدم
• الخادم: هل يعمل خادم TEE وفقًا لملف EIF المتوقع؟ أم أن EIF يتم تنفيذه بالفعل داخل TEE؟ قد يتم تشغيل برامج أخرى أيضًا على الخادم داخل TEE
• **المورد: **هل تصميم TEE آمن؟ هل يوجد باب خلفي يؤدي إلى تسريب جميع البيانات في TEE إلى المورد؟

من السعيد أن TEE لديها الآن حلاً للتخلص من المخاطر المذكورة أعلاه، وهو إعادة بناء مستدام وإثبات عن بعد.

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

!

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

Nix هي أداة شائعة للإنشاءات القابلة للتكرار. عندما يتم الكشف عن الكود المصدري للبرنامج ، يمكن لأي شخص فحص الكود للتأكد من أن المطور لم يقم بإدراج أي شيء غير عادي ، ويمكن لأي شخص إنشاء الكود باستخدام Nix للتحقق مما إذا كان المنتج المدمج يحتوي على نفس مقاييس / تجزئة الكود مثل المنتج الذي نشره فريق المشروع في الإنتاج. ولكن كيف نعرف مقاييس الكود لبرنامج في TEE؟ هذا يقودنا إلى مفهوم يسمى “إثبات عن بعد”. **

!

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

!

يجعل البناء المتكرر والبرهان عن بعد من الممكن لأي مستخدم معرفة الشفرة الفعلية التي تعمل داخل TEE ومعلومات إصدار TEE ، وبالتالي يمنع المطورين أو الخوادم الشريرة.

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

سحر TEE

في رأينا، تُعتبر TEE محبوبة بشكل خاص بسبب السمات التالية، وخصوصًا بالنسبة إلى ودية نشر وكيل الذكاء الاصطناعي:

• الأداء: يمكن لـ TEE تشغيل نموذج LLM ، ويكلفة الأداء والتكلفة المتعلقة به مماثلة لتلك الموجودة في الخوادم العادية. بينما يتطلب zkML استهلاك قوة حاسوبية كبيرة لإنشاء إثبات zk لـ LLM.
• دعم وحدة معالجة الرسوميات (GPU): تقدم NVIDIA دعم الحوسبة المؤمنة (TEE) في سلسلة وحدات معالجة الرسوميات الأحدث لديها (Hopper، Blackwell وغيرها)
• الدقة : LLMs غير قطعية ؛ يمكن الحصول على نتائج مختلفة عند إدخال كلمة محفزة متكررة. لذلك ، قد لا يتوصل عدة عقداء (بما في ذلك المراقبون الذين يحاولون إنشاء إثباتات احتيال) أبدًا إلى توافق حول نتيجة تشغيل LLM. في هذا السياق ، يمكننا الاعتماد على أن LLM الذي يعمل في TEE لا يمكن أن يتم التلاعب به من قبل الأشخاص الخبيثين ، حيث يعمل البرنامج داخل TEE دائمًا بالطريقة التي تم كتابتها ، مما يجعل TEE أكثر ملاءمة لضمان موثوقية نتائج استدلال LLM بدلاً من opML أو الاتفاق
• **السرية: ** البيانات في TEE غير مرئية للبرامج الخارجية. وبالتالي، فإن المفاتيح الخاصة التي تم إنشاؤها أو استلامها في TEE دائمًا آمنة. يمكن استخدام هذه الميزة لضمان للمستخدمين أن أي رسالة موقعة بواسطة هذه المفتاح تأتي من البرامج الداخلية لـ TEE. ** يمكن للمستخدمين أن يشعروا بالراحة عند تكليف مفتاحهم الخاص إلى TEE وتعيين بعض الشروط للتوقيع، ويمكنهم التحقق من توقيع من TEE وفقًا للشروط المحددة مسبقًا **
• الشبكة: يمكن للبرامج التي تعمل في TEE الوصول بأمان إلى الإنترنت باستخدام بعض الأدوات (دون الحاجة إلى الكشف عن الاستعلامات أو الاستجابات للخادم الذي يعمل في TEE، مع ضمان توفير البيانات الصحيحة لأطراف ثالثة). هذا مفيد جدًا لاسترجاع المعلومات من واجهة برمجة التطبيقات الخارجية ويمكن استخدامه لتفويض الحسابات إلى مزود نموذج موثوق ومملوك.
• **أذونات الكتابة: ** على عكس حلول zk ، يمكن للشفرة التي تعمل في TEE بناء الرسائل (سواء كانت تغريدات أو معاملات) وإرسالها عبر شبكة API و RPC.
• موجه للمطورين: يسمح إطار العمل ودليل تطوير البرمجيات الخاصة بـ TEE للأشخاص بكتابة الشفرة بأي لغة ونشر البرنامج بسهولة في TEE كما لو كانوا في خادم سحابي

بغض النظر عن جودتها ، فإن العديد من حالات استخدام TEE في الوقت الحالي من الصعب العثور على بدائل. نحن نعتقد أن إدخال TEE يوسع مزيداً من مساحة تطوير تطبيقات السلسلة الجانبية، وهذا قد يعزز ظهور سيناريوهات تطبيق جديدة.

TEE ليس رصاصة فضية

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

• الفاحشة
• الثغرات في وقت التشغيل
• عيوب تصميم الهيكل
• مشكلة التشغيل

خطأ من المطورين

سواء كان ذلك عمدًا أم غير عمد، يمكن لمطوري البرامج تضعيف ضمانات أمان TEE من خلال التعمد أو عدم التعمد. يتضمن ذلك:

• **الشفافية: ** يعتمد نموذج أمان TEE على القابلية للتحقق الخارجي. ** شفافية الشفرة مهمة جدًا للتحقق من جهات خارجية. **
• **مشكلة قياس الشيفرة المصدرية: **حتى إذا كانت الشيفرة المصدرية متاحة للجميع، فإنه إذا لم يتم إعادة بناء الشيفرة المصدرية من قبل جهة خارجية وفحص قيمة قياس الشيفرة المصدرية في البرهان البعيد ثم التحقق من قياس الشيفرة المصدرية المقدم في البرهان البعيد ، فإن ذلك يشبه استلام برهان زيكرت وعدم التحقق منه.
• الشفرة غير الآمنة: حتى لو كنت تولي اهتمامًا كبيرًا بإنشاء وإدارة المفاتيح بشكل صحيح في TEE ، فقد تتسرب المفاتيح الداخلية لـ TEE خلال عمليات الاستدعاء الخارجية التي تتضمن المنطق الموجود في الشفرة المضمنة. بالإضافة إلى ذلك ، قد تحتوي الشفرة على باب خلفي أو ثغرات. بالمقارنة مع تطوير الخوادم التقليدية ، يتطلب تطوير البرمجيات والعملية التدقيق معايير عالية ، مماثلة لتطوير العقود الذكية.
• هجوم سلسلة التوريد: يستخدم تطوير البرمجيات الحديث العديد من رموز الطرف الثالث. هجمات سلسلة التوريد تشكل تهديدًا كبيرًا لسلامة TEE.

ثغرة زمن التشغيل

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

• الرمز الديناميكي: قد لا يمكن الحفاظ دائمًا على شفافية جميع الرموز. في بعض الأحيان، قد يحتاج الحالة نفسها إلى تنفيذ الرموز الغير شفافة التي تم تحميلها ديناميكيًا في وقت التشغيل إلى TEE. يمكن أن يؤدي هذا النوع من الرموز بسهولة إلى تسرب المعلومات السرية أو تدمير الثوابت، ويجب توخي الحذر الشديد في منع هذا النوع من الحالات.
• البيانات الديناميكية: يستخدم معظم التطبيقات مصادر بيانات خارجية مثل واجهات برمجة التطبيقات (API) وغيرها من مصادر البيانات أثناء التشغيل. يتم توسيع نموذج الأمان ليشمل هذه المصادر، حيث تكون هذه المصادر على قدم المساواة مع البيانات الواردة من البيانات المنبئة في DeFi، ويمكن أن تؤدي البيانات غير الصحيحة أو المتأخرة إلى كوارث. على سبيل المثال، في حالة استخدام AI Agent، قد يؤدي الاعتماد المفرط على خدمة LLM مثل Claude إلى نتائج غير صحيحة.
• غير آمن وغير مستقر في الاتصال: يتطلب TEE تشغيله داخل خادم يحتوي على مكونات TEE. من الناحية الأمانية ، يعد تشغيل الخادم الذي يتضمن TEE في الواقع وسيطًا مثاليًا بين TEE والتفاعل الخارجي (MitM). ليس فقط يمكن للخادم أن يستطلع اتصال TEE الخارجي ويعرض المحتوى الذي يتم إرساله ، ولكنه أيضًا قادر على مراجعة عناوين IP المحددة وتقييد الاتصال وحقن حزم البيانات في الاتصال ، مما يهدف إلى تضليل طرف واحد ليعتقد أنه يأتي من xx.**

على سبيل المثال، يمكن تشغيل محرك المطابقة الذي يمكنه التعامل مع المعاملات المشفرة في TEE، وهذا المحرك غير قادر على توفير ضمان ترتيب عادل (مكافحة MEV)، لأنه لا يزال بإمكان الموجه/البوابة/المضيف التخلص من الحزم البيانات التي تأتي من عنوان IP المصدر أو تأخيرها أو منحها الأولوية وفقا لذلك.

عيوب في التصميم

يجب أن يكون استخدام تقنية الكتف بحذر من قبل تطبيق TEE. قد تواجه مشاكل التالية عند بناء تطبيق TEE:

• **التطبيقات ذات السطح الهجومي الكبير: **يشير سطح الهجوم للتطبيق إلى عدد وحدات التعليمات البرمجية التي يجب ضمان سلامتها بالكامل. يعتبر التدقيق الأمني للشفرة ذات السطح الهجومي الكبير صعبًا للغاية ويمكن أن يخفي الأخطاء أو الثغرات التي يمكن استغلالها. وعادة ما يتعارض ذلك مع تجربة المطورين. على سبيل المثال ، يكون سطح الهجوم لبرنامج TEE الذي يعتمد على Docker أكبر بكثير مقارنةً ببرنامج TEE الذي لا يعتمد على Docker. وعند مقارنته ببرنامج TEE الذي يستخدم أنظمة تشغيل خفيفة الوزن ، فإن Enclaves التي تعتمد على أنظمة التشغيل الناضجة تتمتع بسطح هجوم أكبر.
• قابلية النقل والنشاط: في Web3 ، يجب أن تكون التطبيقات مقاومة للرقابة. يمكن لأي شخص تشغيل TEE والسيطرة على المشاركين في النظام الغير نشطة وجعل التطبيقات داخل TEE قابلة للنقل. **أكبر تحدي هنا هو قابلية نقل المفاتيح. يوجد آليات لتوليد المفاتيح داخل نظام TEE ، ولكن بمجرد استخدام آلية توليد المفاتيح داخل TEE ، لا يمكن للخوادم الأخرى توليد المفاتيح التي في تطبيق TEE الخارجية محليًا ، **مما يعني أن برامج TEE عادةً ما تكون محدودة إلى نفس الجهاز ، وهذا غير كافٍ للحفاظ على قابلية النقل
• جذر الثقة غير الآمنة: على سبيل المثال، كيف يتم التحقق من أن العنوان المحدد ينتمي إلى الوكيل الذكي في TEE عند تشغيله؟ إذا لم يتم تصميم هذا الجانب بعناية، فقد يؤدي ذلك إلى جذر الثقة الحقيقي يكون جهة خارجية ثالثة أو منصة تخزين المفاتيح بدلاً من TEE نفسه.

مشكلة التشغيل

وأما آخر نقطة ولكنها ليست الأقل أهمية هي أنه هناك بعض الاعتبارات العملية بشأن كيفية تشغيل خادم ينفذ برنامج TEE بشكل فعلي:

• الإصدارات غير الآمنة للمنصة: يتلقى منصة TEE في بعض الأحيان تحديثات أمان، وسيتم عكس هذه التحديثات في إصدارات المنصة في البرهان عن بُعد. إذا كان TEE الخاص بك لا يعمل على إصدار آمن للمنصة، فيمكن للقراصنة الاستفادة من وسائط الهجوم المعروفة لسرقة المفاتيح من TEE. والأسوأ من ذلك، قد يعمل TEE الخاص بك اليوم على إصدار آمن للمنصة، وربما لا يكون آمنًا غدًا.
• **لا يوجد أمان فيزيائي: ** على الرغم من بذلك قصارى جهدها، إلا أن TEE قد يتعرض لهجوم جانبي القناة، الذي عادة ما يتطلب الوصول الفعلي والسيطرة على الخادم الذي يحتوي على TEE. لذلك، الأمان الفيزيائي هو طبقة دفاع عميقة مهمة. مفهوم ذا صلة هو إثبات السحابة، حيث يمكنك إثبات أن TEE يعمل في مركز البيانات السحابية، وأن هذه المنصة السحابية توفر ضمانات أمان فيزيائي.

بناء برنامج TEE آمن

سنقسم اقتراحاتنا إلى النقاط التالية:

• أكثر برنامج أمان
• اتخاذ الإجراءات الوقائية اللازمة
• اعتمادًا على توصية الحالة النموذجية

1. أكثر حل آمن: بدون تبعيات خارجية

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

إذا تم تشغيل النموذج محليًا ، يمكن تحقيق هذا المستوى من الأمان لمعظم حالات استخدام CryptoxAI.

2. إجراءات الوقاية اللازمة

بغض النظر عما إذا كان التطبيق لديه تبعيات خارجية، فإن الأمور التالية ضرورية!

اعتبار تطبيقات TEE على أنها عقود ذكية بدلاً من تطبيقات الخلفية؛ والحفاظ على تردد تحديث منخفض واختبار صارم.

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

فحص رمز التدقيق وفحص أنابيب البناء

أمان التطبيق لا يعتمد فقط على الرمز نفسه، ولكن أيضًا على الأدوات المستخدمة في عملية البناء. يعد خط أنابيب البناء الآمن حاسمًا لمنع الثغرات. لا يمكن لـ TEE إصلاح العيوب التي تم إدخالها خلال عملية البناء، ولكنه يضمن فقط تشغيل الرمز المزود وفقًا للعملية المتوقعة.

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

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

استخدم مكتبات تم التدقيق فيها أو التحقق منها

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

التحقق الدائم من دليل TEE

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

يمكن أن يتم التحقق بشكل محدد على السلسلة (IntelSGX، AWSNitro) ، واستخدام إثبات ZK (IntelSGX، AWSNitro) للتحقق دون سلسلة ، كما يمكن للمستخدمين أو الخدمات المستضافة (مثل t16z أو MarlinHub) تنفيذ التحقق.

3. توصيات تعتمد على الحالة

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

التأكد دائمًا من تنفيذ تفاعل المستخدم مع TEE في القناة الآمنة

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

على سبيل المثال ، يمكن لـ Oyster دعم توزيع توقيع الطبقة الأمنية (CAA) و RFC8657 للحصول على توزيع TLS الآمن. بالإضافة إلى ذلك ، يوفر بروتوكول Scallop الأصلي لـ TEE TLS ، والذي لا يعتمد على WebPKI.

تعلم أن ذاكرة TEE هي عابرة

ذاكرة TEE هي عابرة للزمن، وهذا يعني أنه عند إغلاق TEE، سيتم فقدان محتواها (بما في ذلك المفاتيح التشفيرية). إذا لم يكن هناك آلية آمنة للحفاظ على هذه المعلومات، فقد يتعذر الوصول إلى البيانات الحساسة بشكل دائم، مما قد يؤدي إلى تعرض الأموال أو العمليات التشغيلية لمشكلات خطيرة.

يمكن استخدام شبكة الحساب العددي المتعدد (MPC) التي تحتوي على نظام تخزين مركزي مثل IPFS كحلا لهذه المشكلة. تقوم شبكة MPC بتقسيم المفتاح إلى عدة عقد، مما يضمن عدم امتلاك أي عقد فردي للمفتاح الكامل، مع السماح في الوقت نفسه للشبكة بإعادة بناء المفتاح عند الحاجة. يمكن تخزين البيانات المشفرة بهذا المفتاح بشكل آمن على IPFS.

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

!

هناك حلاً آخر، ** وهو أن يقوم TEE بتقسيم المعاملات ذات الصلة وتسليمها إلى خوادم MPC مختلفة، ثم يقوم خوادم MPC بالتوقيع وتجميع التوقيعات وتقديم المعاملات النهائية للسلسلة. هذا الطريقة أقل مرونة بكثير، ولا يمكن استخدامها لحفظ مفتاح API أو كلمة مرور أو بيانات عشوائية (بدون خدمة تخزين ثالثة موثوقة).**

!

تقليل سطح الهجوم

بالنسبة لحالات الاستخدام الحرجة من حيث الأمان ، يستحق المحاولة للحد من الاعتمادات الخارجية بأقصى قدر ممكن على حساب تجربة المطور. على سبيل المثال ، يأتي Dstack مع نواة دقيقة على أساس Yocto والتي تحتوي فقط على الوحدات اللازمة لعمل Dstack. ربما يستحق حتى استخدام التقنيات القديمة مثل SGX (تفوق TDX) ، لأن هذه التقنية لا تحتاج إلى برنامج تحميل أو نظام تشغيل ليتم تحميلهما كجزء من TEE.

العزل الفيزيائي

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

متعدد الإثبات

تمامًا مثلما يعتمد Ethereum على عدة عملاء لتخفيض مخاطر أخطاء البرامج الضارة التي تؤثر على الشبكة بأكملها ، يستخدم multiprovers خططًا مختلفة لـ TEE لزيادة الأمان والمرونة. يمكن للتحقق المتعدد ضمان أن أي عيوب في تنفيذ TEE معين لن تؤثر على التطبيق بأكمله عن طريق تشغيل نفس الخطوات الحسابية عبر عدة منصات TEE مختلفة. على الرغم من أن هذا النهج يتطلب أن يكون عملية الحساب محددة بشكل دقيق ، أو تعريف الاتفاق بين خطط TEE المختلفة في حالة عدم التحديد ، فإنه يوفر أيضًا مزايا ملحوظة مثل العزلة من الأخطاء والتكرار والتحقق المتقاطع ، مما يجعله خيارًا جيدًا للتطبيقات التي تتطلب ضمانات الموثوقية.

!

توقعات المستقبل

يبدو أن TEE أصبح مجالًا مثيرًا للغاية. كما ذكرنا سابقًا ، فإن وجود AI في كل مكان والوصول المستمر إلى بيانات المستخدم الحساسة يعني أن شركات التكنولوجيا الكبرى مثل Apple و NVIDIA تستخدم TEE في منتجاتها وتقدمها كجزء من منتجاتها.

من ناحية أخرى، كانت المجتمع المشفر مهتمة دائمًا بالأمان. مع محاولة المطورين لتوسيع تطبيقات السلسلة الضوئية وحالات الاستخدام، لاحظنا أن تقنية TEE أصبحت شائعة كحلا يوفر توازنًا صحيحًا بين الوظائف وافتراضات الثقة. ** على الرغم من أن TEE لا توفر الحد الأدنى للثقة مثل حل ZK الكامل، إلا أننا نتوقع أن تصبح TEE المنهج الذي سيتم دمج شركات Web3 ومنتجات الشركات التكنولوجية الكبيرة به لأول مرة تدريجيًا. **