المؤلف: براتيك، روشان، سيدهارتا ولينجويني (مارلين)، كرين (أسولا) المترجم: شو، الكائن السماوي GodRealmX
منذ أن أعلنت شركة Apple عن الإطلاق أصبحت بيئات التنفيذ الخاصة الموثوقة (TEEs) شائعة بشكل متزايد منذ أن قدمت السحابة وNVIDIA حوسبة سرية في وحدات معالجة الرسومات. تساعد ضمانات السرية الخاصة بهم على حماية بيانات المستخدم (والتي قد تتضمن مفاتيح خاصة)، بينما يضمن العزل عدم إمكانية التلاعب بتنفيذ البرامج المنشورة عليها — سواء من قبل البشر أو البرامج الأخرى أو نظام التشغيل. لذلك، ليس من المستغرب أن يستخدم مجال Crypto x AI TEE على نطاق واسع لبناء المنتجات.
مثل أي تقنية جديدة، تمر TEE بفترة من التجارب المتفائلة. تأمل هذه المقالة في توفير دليل مفاهيمي أساسي للمطورين والقراء العامين لفهم ماهية TEE، ونموذج أمان TEE، ونقاط الضعف الشائعة، وأفضل الممارسات لاستخدام TEE بأمان. (ملاحظة: لتسهيل فهم النص، قمنا عمدًا باستبدال مصطلحات TEE بمرادفات أبسط).
ما هو TEE
تتم معالجة TEE بيئة معزولة في خادم أو مركز بيانات حيث يمكن تشغيل البرنامج دون أي تدخلمن بقية النظام. من أجل منع تدخل أجزاء أخرى في TEE، نحتاج إلى سلسلة من التصميمات، والتي تتضمن بشكل أساسي التحكم الصارم في الوصول، أي التحكم في وصول الأجزاء الأخرى من النظام إلى البرامج والبيانات في TEE. أصبح TEE الآن موجودًا في كل مكان في الهواتف المحمولة والخوادم وأجهزة الكمبيوتر والبيئات السحابية، مما يجعله سهل الوصول إليه وبأسعار معقولة.
قد يبدو المحتوى أعلاه غامضًا ومجردًا. في الواقع، يقوم موفرو الخوادم والسحاب المختلفون بتنفيذ TEE بطرق مختلفة، ولكن الغرض الأساسي منه هو تجنب التدخل في TEE مع برامج أخرى.
من المحتمل أن يستخدم معظم القراء المعلومات البيومترية لتسجيل الدخول إلى الجهاز، مثل فتح الهاتف ببصمة الإصبع. ولكن كيف نضمن أن التطبيقات أو مواقع الويب الضارة أو أنظمة التشغيل التي تم كسر حمايتها لا يمكنها الوصول إلى هذه المعلومات البيومترية وسرقتها؟ في الواقع، بالإضافة إلى تشفير البيانات، فإن الدوائر الموجودة في جهاز TEE لا تسمح لأي برنامج بالوصول إلى مناطق الذاكرة والمعالج التي تشغلها البيانات الحساسة.
تعد محفظة الأجهزة مثالًا آخر لسيناريو تطبيق TEE. تتصل محفظة الأجهزة بالكمبيوتر وتتصل به في وضع الحماية، لكن لا يتمتع الكمبيوتر بإمكانية الوصول المباشر إلى العبارة التذكيرية المخزنة داخل محفظة الأجهزة. في كلتا الحالتين، يثق المستخدمون في الشركة المصنعة للجهاز لتصميم الشريحة بشكل صحيح وتوفير تحديثات البرامج الثابتة المناسبة لمنع تصدير البيانات السرية داخل TEE أو عرضها.
نموذج الأمان
للأسف، أنواع تنفيذ TEE كثيرة، تتطلب العديد من هذه التطبيقات المختلفة (IntelSGX، وIntelTDX، وAMDSEV، وAWSNitroEnclaves، وARMTrustZone) تحليلًا مستقلاً لنمذجة نموذج الأمان. في بقية هذه المقالة، سنناقش بشكل أساسي IntelSGX وTDX وAWSNitro، لأن أنظمة TEE هذه بها عدد أكبر من المستخدمين ولديها أدوات تطوير كاملة متاحة. النظام أعلاه هو أيضًا نظام TEE الأكثر استخدامًا في Web3.
بشكل عام، يكون سير عمل التطبيق المنشور في TEE كما يلي:
"المطورون" يكتبون بعض التعليمات البرمجية التي قد تكون أو لا تكون مفتوحة المصدر
< /li>< لى>يقوم المطور بعد ذلك بتجميع التعليمات البرمجية في ملف صورة Enclave (EIF)، والذي يمكن تشغيله في TEE
تتم استضافة EIF على خادم مزود بنظام TEE. في بعض الحالات، يمكن للمطورين استخدام أجهزة الكمبيوتر الشخصية مباشرة مع TEE لاستضافة EIF لتقديم خدمات خارجية
يمكن للمستخدمين تحديد الواجهة مسبقًا للتفاعل مع التطبيق.
من الواضح أن هناك ثلاثة مخاطر محتملة هنا:
المطور: ما الذي يفعله بالضبط الكود المستخدم لإعداد EIF؟ قد لا يتوافق رمز EIF مع منطق العمل الذي يروج له طرف المشروع، وقد يسرق البيانات الخاصة للمستخدمين
الخادم: هل يقوم خادم TEE بتشغيل ملف EIF كما هو متوقع؟ أم أن EIF يتم تنفيذه بالفعل داخل TEE؟ قد يقوم الخادم أيضًا بتشغيل برامج أخرى داخل TEE
المورد: هل تصميم TEE آمن؟ هل هناك باب خلفي يسرب جميع البيانات الموجودة داخل TEE إلى البائع؟
لحسن الحظ، لدى TEE الآن خطة للقضاء على المخاطر المذكورة أعلاه، وهي قابلة للتكرار يبني والشهادات عن بعد.
إذن ما هو البناء القابل للتكرار؟ غالبًا ما يتطلب تطوير البرامج الحديثة استيراد عدد كبير من التبعيات، مثل الأدوات الخارجية أو المكتبات أو أطر العمل، وما إلى ذلك. وقد تحتوي ملفات التبعيات هذه أيضًا على مخاطر مخفية. تستخدم حلول مثل npm الآن تجزئة التعليمات البرمجية المقابلة للملف التابع كمعرف فريد. عندما يجد npm أن الملف التابع غير متوافق مع قيمة التجزئة المسجلة، يمكن اعتبار أن الملف التابع قد تم تعديله.
يمكن اعتبار الإصدارات القابلة للتكرار بمثابة مجموعة من المعايير. والهدف هو أنه عند تشغيل أي تعليمات برمجية على أي جهاز، طالما تم إنشاؤها وفقًا لعملية محددة مسبقًا، يمكن الحصول على قيمة تجزئة متسقة في النهاية. بالطبع، من الناحية العملية، يمكننا أيضًا استخدام منتجات أخرى غير التجزئة كمعرفات، وهو ما نسميه قياس الكود هنا.
Nix هي أداة شائعة للإنشاءات القابلة للتكرار. عندما يتم نشر الكود المصدري للبرنامج، يمكن لأي شخص التحقق من الكود للتأكد من أن المطور لم يدرج محتوى غير طبيعي. يمكن لأي شخص استخدام Nix لإنشاء الكود والتحقق مما إذا كان المنتج المدمج هو نفس المنتج الذي تم نشره بواسطة المشروع في بيئة الإنتاج Code Metrics/Hash. ولكن كيف نعرف مقاييس الكود الخاصة بأحد البرامج في TEE؟ وهذا ينطوي على مفهوم يسمى "التصديق عن بعد".
التصديق عن بعد عبارة عن رسالة موقعة من منصة TEE (جهة موثوقة) تحتوي على مقاييس كود البرنامج وإصدار منصة TEE وما إلى ذلك. يتيح التصديق عن بعد للمراقبين الخارجيين معرفة أن البرنامج يتم تنفيذه في مكان آمن (إصدار xx من TEE الحقيقي) لا يمكن لأي شخص الوصول إليه.
تسمح الإصدارات القابلة للتكرار والتصديق عن بعد لأي مستخدم بمعرفة الكود الفعلي الذي يعمل في TEE ومعلومات إصدار النظام الأساسي TEE، وبالتالي منع المطورين أو الخوادم من فعل الشر.
ومع ذلك،في حالة TEE، هناك دائمًا حاجة إلى الثقة بموردها. إذا كان مورد TEE شريرًا، فيمكنه تزوير الشهادات عن بعد مباشرةً. لذلك، إذا كان الموفر يعتبر ناقل هجوم محتمل، فيجب تجنب الاعتماد فقط على TEEs ومن الأفضل دمجها مع ZK أو بروتوكولات الإجماع.
سحر TEE
في يبدو أن الميزات الشائعة بشكل خاص لـ TEE، وخاصة ملاءمتها لنشر AI Agent، تكمن بشكل أساسي في النقاط التالية:
دعم وحدة معالجة الرسومات: توفر NVIDIA دعمًا لحوسبة TEE في أحدث سلاسل وحدات معالجة الرسومات (Hopper وBlackwell وما إلى ذلك)
الصحة: ماجستير إدارة الأعمال غير حتمي؛ فإدخال نفس الكلمة المطالبة عدة مرات سيؤدي إلى نتائج مختلفة. لذلك، قد لا تتوصل العقد المتعددة (بما في ذلك المراقبون الذين يحاولون إنشاء أدلة احتيال) إلى توافق في الآراء بشأن نتائج عملية LLM. في هذا السيناريو، يمكننا أن نثق في أن LLM الذي يتم تشغيله في TEE لا يمكن التلاعب به من قبل الجهات الشريرة، وأن البرامج الموجودة في TEE تعمل دائمًا كما هو مكتوب. وهذا يجعل TEE أكثر ملاءمة من opML أو الإجماع لضمان موثوقية نتائج استدلال LLM
السرية:أزواج البيانات في برامج TEE الخارجية غير مرئية. ولذلك، فإن المفاتيح الخاصة التي يتم إنشاؤها أو تلقيها في TEE تكون آمنة دائمًا. يمكن استخدام هذه الميزة لتأكيد المستخدمين أن أي رسالة موقعة بواسطة هذا المفتاح نشأت من الإجراءات الداخلية لـ TEE. يمكن للمستخدمين أن يعهدوا بالمفتاح الخاص إلى TEE بأمان وتعيين بعض شروط التوقيع، ويمكنهم التأكد من أن التوقيع من TEE يلبي شروط التوقيع المحددة مسبقًا
الشبكات:باستخدام بعض الأدوات، يمكن للبرامج التي يتم تشغيلها في TEE الوصول بشكل آمن إلى الإنترنت (دون الكشف عن الاستعلامات لخادم TEE) قيد التشغيل) أو الاستجابة مع الاستمرار في تقديم ضمانات لأطراف ثالثة بشأن استرجاع البيانات بشكل صحيح). يعد هذا مفيدًا لاسترداد المعلومات من واجهات برمجة التطبيقات التابعة لجهات خارجية ويمكن استخدامه لالاستعانة بمصادر خارجية للعمليات الحسابية لموفر نموذج موثوق به ولكن خاص
إذن الكتابة: على عكس مخطط zk، يمكن للكود الذي يتم تشغيله في TEE إنشاء رسائل (سواء كانت تغريدات أو معاملات) وإرسالها عبر واجهة برمجة التطبيقات (API) والوصول إلى شبكة RPC الخروج
ملائمة للمطورين:تسمح أطر العمل ومجموعات SDK ذات الصلة بـ TEE للأشخاص بكتابة التعليمات البرمجية بأي لغة ونشر البرامج على TEE بنفس السهولة كما هو الحال في خادم سحابي
للأفضل أو للأسوأ، هناك عدد لا بأس به من حالات الاستخدام التي تستخدم TEE يصعب حاليًا العثور على بدائل. نعتقد أن تقديم TEE يوسع مساحة التطوير للتطبيقات الموجودة على السلسلة، مما قد يعزز ظهور سيناريوهات تطبيقات جديدة.
TEE ليس حلاً سحريًا
في TEE، لا تزال البرامج التي تعمل على Windows عرضة لمجموعة من الهجمات والأخطاء. تمامًا مثل العقود الذكية، فهي عرضة لمجموعة من المشكلات. للتبسيط، نقوم بتصنيف نقاط الضعف المحتملة على النحو التالي:
التطوير المشغل كان مهملاً
ثغرة أمنية في وقت التشغيل
عيوب التصميم المعماري
المشكلات التشغيلية
إهمال المطور
سواء كان ذلك عن قصد أم لا، يمكن للمطورين إضعاف الضمانات الأمنية للبرامج في TEEs من خلال تعليمات برمجية مقصودة أو غير مقصودة. يتضمن ذلك:
رمز العتامة: يعتمد نموذج الأمان الخاص بـ TEE على إمكانية التحقق الخارجي. تعد شفافية التعليمات البرمجية أمرًا بالغ الأهمية للتحقق من جهة خارجية.
مشاكل في مقاييس الكود: حتى لو كان يكون الكود علنيًا، إذا لم يقوم أي طرف ثالث بإعادة بناء الكود والتحقق من مقاييس الكود في المصادقة عن بعد، ثم يتحقق من مقاييس الكود المقدمة في المصادقة عن بعد. وهذا مشابه لتلقي دليل zk ولكن لا يتم التحقق منه.
رمز غير آمن: حتى لو كنت حريصًا على فهمه بشكل صحيح في TEE، قم بإنشاء المفاتيح وإدارتها،قد يؤدي أيضًا المنطق الموجود في التعليمات البرمجية إلى تسرب المفاتيح داخل TEE أثناء المكالمات الخارجية. بالإضافة إلى ذلك، قد يحتوي الرمز على أبواب خلفية أو ثغرات أمنية. بالمقارنة مع التطوير الخلفي التقليدي، فإنه يتطلب معايير عالية في تطوير البرمجيات وعمليات التدقيق، على غرار تطوير العقود الذكية.
هجمات سلسلة التوريد:يستخدم تطوير البرمجيات الحديثة كميات كبيرة من مصادر ثالثة - كود الحزب . تشكل هجمات سلسلة التوريد تهديدًا كبيرًا لسلامة TEEs.
ثغرة أمنية في وقت التشغيل
< p style="text-align: left;">بغض النظر عن مدى حذر المطور، فقد يقع ضحية لثغرات وقت التشغيل. يجب على المطورين التفكير بعناية فيما إذا كان أي مما يلي سيؤثر على ضمانات أمان مشروعهم:الرمز الديناميكي: قد لا يكون من الممكن دائمًا الحفاظ على شفافية جميع التعليمات البرمجية. في بعض الأحيان، تتطلب حالة الاستخدام نفسها تنفيذًا ديناميكيًا لتعليمات برمجية غير شفافة تم تحميلها في TEE في وقت التشغيل. يمكن لمثل هذه التعليمات البرمجية أن تكشف الأسرار بسهولة أو تكسر الثوابت، ويجب توخي الحذر الشديد لمنع ذلك.
البيانات الديناميكية:تستخدمها معظم التطبيقات أثناء التنفيذ واجهات برمجة التطبيقات الخارجية و مصادر البيانات الأخرى. يتوسع نموذج الأمان ليشمل مصادر البيانات هذه، والتي هي على قدم المساواة مع Oracles في DeFi، حيث يمكن أن تؤدي البيانات غير الصحيحة أو حتى القديمة إلى كارثة. على سبيل المثال، في حالة استخدام AI Agent، هناك اعتماد مفرط على خدمات LLM، مثل Claude.
اتصال غير آمن وغير مستقر:يجب تضمين TEE يعمل المكون داخل الخادم. من منظور أمني،الخادم الذي يقوم بتشغيل TEE هو في الواقع الوسيط المثالي (MitM) بين TEE والتفاعلات الخارجية. لا يقتصر الأمر على أن الخادم قادر على إلقاء نظرة خاطفة على اتصالات TEE الصادرة ورؤية ما يتم إرساله، بل يمكنه أيضًا فرض رقابة على عناوين IP محددة وتقييد الاتصالات وإدخال الحزم في الاتصال بهدف خداع أحد الأطراف ليعتقد أنها قادمة من xx.
على سبيل المثال، تشغيل محرك مطابق في TEE يمكنه التعامل مع معاملات العملات المشفرة لا يمكن أن يوفر ضمانات عادلة للطلب (مكافحة -MEV) لأن أجهزة التوجيه/البوابات/المضيفين لا يزال بإمكانهم إسقاط الحزم أو تأخيرها أو تحديد أولوياتها بناءً على عنوان IP المصدر الخاص بهم.
العيوب المعمارية
ينبغي أن تكون مجموعة التكنولوجيا التي تستخدمها تطبيقات TEE حذرة. عند إنشاء تطبيق TEE، قد تحدث المشكلات التالية:
< strong>التطبيقات ذات سطح الهجوم الكبير:سطح الهجوم الخاص بالتطبيق هو عدد وحدات التعليمات البرمجية التي يجب أن تكون آمنة تمامًا. من الصعب جدًا تدقيق التعليمات البرمجية ذات سطح الهجوم الكبير وقد تخفي الأخطاء أو نقاط الضعف القابلة للاستغلال. وغالبًا ما يتعارض هذا مع تجربة المطورين أيضًا. على سبيل المثال، يتمتع برنامج TEE الذي يعتمد على Docker بسطح هجوم أكبر بكثير من برنامج TEE الذي لا يعتمد على Docker. تتمتع الجيوب التي تعتمد على أنظمة تشغيل ناضجة بسطح هجوم أكبر من برامج TEE التي تستخدم أنظمة التشغيل خفيفة الوزن
قابلية النقل والحيوية: في Web3، يجب أن تكون التطبيقات مقاومة للرقابة. يمكن لأي شخص بدء TEE والاستيلاء على المشاركين غير النشطين في النظام وإنشاء تطبيقات داخل TEE المحمول. التحدي الأكبر هنا هو إمكانية نقل المفاتيح. تحتوي بعض أنظمة TEE على آلية اشتقاق مفتاح مدمجة فيها، ولكن بمجرد استخدام آلية اشتقاق المفتاح داخل TEE، لا يمكن للخوادم الأخرى إنشاء مفاتيح محليًا داخل برنامج TEE الخارجي، مما يجعل برنامج TEE يقتصر عادةً على نفس جهاز الخادم. وهو غير كافٍ للحفاظ على إمكانية النقل
جذر الثقة غير الآمن
strong> : على سبيل المثال، تشغيل الذكاء الاصطناعي في TEE عند استخدام الوكيل، كيف يمكن التحقق مما إذا كان العنوان المحدد ينتمي إلى الوكيل؟ إذا لم يتم تصميم ذلك بعناية، فقد يكون الجذر الحقيقي للثقة هو طرف ثالث خارجي أو منصة ضمان رئيسية، وليس TEE نفسها.المشكلات التشغيلية
أخيرًا وليس آخرًا، هناك بعض الاعتبارات العملية حول كيفية التشغيل الفعلي لخادم ينفذ برامج TEE:
إصدار النظام الأساسي غير الآمن: تتلقى منصة TEE أحيانًا تحديثات أمنية، والتي تنعكس كإصدارات النظام الأساسي في الشهادات عن بعد. إذا لم يكن TEE الخاص بك يعمل على إصدار نظام أساسي آمن، فيمكن للمتسللين استغلال نواقل الهجوم المعروفة لسرقة المفاتيح من TEE. والأسوأ من ذلك، أن TEE الخاص بك قد يعمل على إصدار نظام أساسي آمن اليوم وغير آمن غدًا.
لا يوجد أمان جسدي: على الرغم من بذل قصارى جهدك، إلا أن TEEs قد يتعرض لهجمات القنوات الجانبية، وعادةً ما يحتاج المهاجمون إلى الوصول الفعلي والتحكم إلى الخادم الذي يوجد به TEE. ولذلك، فإن الأمن الجسدي هو طبقة مهمة من الدفاع في العمق. المفهوم ذو الصلة هو إثبات السحابة، حيث يمكنك إثبات أن TEE يعمل في مركز بيانات سحابي وأن النظام الأساسي السحابي يتمتع بضمانات أمان مادية.
إنشاء برامج TEE آمنة
لقد قسمنا توصياتنا إلى النقاط التالية:
الحل الأكثر أمانًا
الاحتياطات اللازمة التي يجب اتخاذها
التوصيات التي تعتمد على حالات الاستخدام
< p>1. الحل الأكثر أمانًا: عدم وجود تبعيات خارجية
< p style ="محاذاة النص: left;">قد يتضمن إنشاء تطبيقات آمنة للغاية التخلص من التبعيات الخارجية مثل المدخلات الخارجية أو واجهات برمجة التطبيقات أو الخدمات، وبالتالي تقليل سطح الهجوم. ويضمن هذا النهج أن يعمل التطبيق بطريقة قائمة بذاتها، دون أي تفاعلات خارجية يمكن أن تؤثر على سلامته أو أمنه. وعلى الرغم من أن هذه الإستراتيجية قد تحد من التنوع الوظيفي للبرنامج، إلا أنها توفر مستوى عالٍ للغاية من الأمان.يمكن تحقيق هذا المستوى من الأمان لمعظم حالات استخدام CryptoxAI إذا تم تشغيل النموذج محليًا.
2. يجب اتخاذ الاحتياطات اللازمة
بغض النظر عن تطبيق ما إذا كان البرنامج لديه تبعيات خارجية، ما يلي مطلوب!
فكر في تطبيقات TEE كعقود ذكية بدلاً من التطبيقات الخلفية، واحتفظ بتكرار التحديث منخفضًا واختبرها بدقة.
يجب أن يكون إنشاء برامج TEE بنفس صرامة كتابة العقود الذكية واختبارها وتحديثها. مثل العقود الذكية، تعمل TEEs في بيئة حساسة للغاية وغير قابلة للتغيير حيث يمكن أن تؤدي الأخطاء أو السلوك غير المتوقع إلى عواقب وخيمة، بما في ذلك الخسارة الكاملة للأموال. يعد التدقيق الشامل والاختبار الشامل والحد الأدنى من التحديثات التي تم تدقيقها بعناية أمرًا بالغ الأهمية لضمان سلامة وموثوقية التطبيقات المستندة إلى 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 قادر على دعم إصدار TLS الآمن من خلال استخدام سجلات CAA وRFC8657. بالإضافة إلى ذلك، فهو يوفر بروتوكول TLS أصلي لـ TEE يسمى Scallop، والذي لا يعتمد على WebPKI.
اعلم أن ذاكرة TEE عابرة
تعتبر ذاكرة TEE عابرة، مما يعني أن محتوياتها (بما في ذلك مفاتيح التشفير) تُفقد عند إيقاف تشغيل TEE. بدون آلية آمنة للاحتفاظ بهذه المعلومات، قد يتعذر الوصول إلى البيانات المهمة بشكل دائم، مما قد يؤدي إلى شل الأموال أو العمليات.
يمكن استخدام شبكات الحوسبة متعددة الأطراف (MPC) مع أنظمة التخزين اللامركزية مثل IPFS كحل لهذه المشكلة. تقوم شبكات MPC بتقسيم المفاتيح عبر عقد متعددة، مما يضمن عدم وجود عقدة واحدة تحمل المفتاح الكامل مع السماح للشبكة بإعادة بناء المفتاح إذا لزم الأمر. يمكن تخزين البيانات المشفرة باستخدام هذا المفتاح بشكل آمن على IPFS.
إذا لزم الأمر، يمكن لشبكة MPC توفير مفاتيح لخوادم TEE جديدة تعمل على نفس الصورة، بشرط استيفاء شروط معينة. ويضمن هذا النهج المرونة والأمان القوي، مع الحفاظ على إمكانية الوصول إلى البيانات والحفاظ على سريتها حتى في البيئات غير الموثوقة.
هناك حل آخر،أي أن TEE ستقوم بتسليم المعاملات ذات الصلة إلى خوادم MPC مختلفة على التوالي. بعد توقيع خادم MPC، سيقوم بتجميع التوقيع ووضع المعاملة في النهاية على السلسلة. هذه الطريقة أقل مرونة بكثير ولا يمكن استخدامها لحفظ مفاتيح واجهة برمجة التطبيقات أو كلمات المرور أو البيانات العشوائية (بدون خدمة تخزين موثوقة تابعة لجهة خارجية).
تقليل سطح الهجوم
بالنسبة لحالات الاستخدام الحرجة للأمان، يجدر المحاولة على حساب المطور تجربة تقليل أكبر عدد ممكن من التبعيات الطرفية. على سبيل المثال، يأتي Dstack مع الحد الأدنى من نواة Yocto التي تحتوي فقط على الوحدات المطلوبة لكي يعمل Dstack. قد يكون من المفيد أيضًا استخدام تقنية قديمة مثل SGX (عبر TDX) نظرًا لأن هذه التقنية لا تتطلب أداة تحميل التشغيل أو نظام التشغيل ليكون جزءًا من TEE.
العزل الجسدي
من خلال الجمع بين TEE و العزلة الجسدية عن التدخل البشري المحتمل يمكن أن تزيد من تعزيز سلامة TEE. على الرغم من أنه يمكننا استضافة خوادم TEE في مراكز البيانات وموفري الخدمات السحابية، إلا أننا نعتقد أن مراكز البيانات يمكنها توفير الأمان المادي. لكن مشاريع مثل Spacecoin تستكشف بديلاً مثيرًا للاهتمام وهو الفضاء. وتعتمد ورقة SpaceTEE على تدابير السلامة، مثل قياس لحظة القصور الذاتي بعد الإطلاق، للتحقق مما إذا كان القمر الصناعي ينحرف عن التوقعات أثناء عملية دخوله المدار.
إثباتات متعددة
تمامًا كما يعتمد Ethereum على عدة فقط نظرًا لأن تطبيقات العميل تقلل من مخاطر الأخطاء التي تؤثر على الشبكة بالكامل، يستخدم المعالجون المتعددون تطبيقات TEE مختلفة لتحسين الأمان والمرونة. من خلال تشغيل نفس الخطوات الحسابية عبر منصات TEE متعددة، يضمن التحقق المتعددأن الثغرة الأمنية في تطبيق TEE واحد لا تؤثر على التطبيق بأكمله. على الرغم من أن هذا النهج يتطلب أن تكون العملية الحسابية حتمية، أو لتحديد الإجماع بين تطبيقات TEE المختلفة في المواقف غير الحتمية، فإنه يوفر أيضًا مزايا كبيرة مثل عزل الأخطاء والتكرار والتحقق المتبادل، مما يجعله حلاً موثوقًا عندما يكون الاختيار جيدًا. لتطبيق الطمأنينة الجنسية.
التطلع إلى المستقبل
من الواضح أن TEE أصبح مجالًا مثيرًا للغاية. كما ذكرنا سابقًا، فإن انتشار الذكاء الاصطناعي في كل مكان واستمرار وصوله إلى البيانات الحساسة للمستخدمين يعني أن شركات التكنولوجيا الكبيرة مثل Apple وNVIDIA تستخدم TEE في منتجاتها وتقدم TEE كجزء من منتجاتها.
من ناحية أخرى، كان مجتمع التشفير دائمًا يركز بشكل كبير على الأمان. بينما يحاول المطورون توسيع التطبيقات الموجودة على السلسلة وحالات الاستخدام، فقد شهدنا أن TEE أصبح شائعًا كحل يوفر المفاضلة الصحيحة بين الوظائف وافتراضات الثقة. على الرغم من أن TEE لا يتم تقليل الثقة فيه مثل حل ZK الكامل، إلا أننا نتوقع أن يكون TEE هو المسار الأول لدمج المنتجات ببطء من شركات Web3 وشركات التكنولوجيا الكبيرة.
غرد كوينتيليغراف بأن هيئة الأوراق المالية والبورصة وافقت على صندوق الاستثمار المتداول في بيتكوين (BTC) الخاص بشركة iShares، ولكن تم تأكيد عدم صحة ذلك من قبل بلاك روك.
Aaronتعد البورصة واحدة من اثنتين فقط من البورصات في هونغ كونغ المرخصة بموجب قواعد الأصول الرقمية التي أدخلتها المدينة في يونيو.
Alexستطبق Uniswap قريبًا رسوم مقايضة بنسبة 0.15% على تطبيقات الويب وواجهات المحفظة الخاصة بها، وهي المرة الأولى التي يتم فيها تقديم مثل هذه الرسوم، مما يثير جدلاً في مجتمع العملات المشفرة.
Kikyoعلى مدار الأشهر القليلة الماضية، نشر Huang ما مجموعه 1,761 دولارًا أمريكيًا ETH (ما يعادل 2.89 مليون دولار أمريكي) و52000 دولارًا أمريكيًا USDC للحصول على 2.24 مليون دولار أمريكي من رموز APE بقيمة 2.94 مليون دولار أمريكي.
Davinفي تطور مثير للقلق، ابتكر مجرمو الإنترنت طريقة مبتكرة لنشر برامج الفيروسات، مستفيدين من نقاط الضعف في العقود الذكية لسلسلة BNB الذكية (BSC).
Jasperالمخاوف المستمرة بشأن الوصول إلى Adderall أبرزها الفريق القانوني لـ Sam Bankman-Fried وسط معركة قانونية عالية المخاطر.
Hui Xinتؤكد Coinhouse انخفاضًا بنسبة 15٪ في قوتها العاملة، بسبب عوامل مثل "انخفاض الحماس لـ Web3 والبيئة الاقتصادية العالمية الهشة".
Catherineبعد الفوز الملحوظ في The International 12 (TI12) على Tundra Esports، وجدت Nouns Esports، وهي منظمة بارزة في Dota 2، نفسها تحت التدقيق بسبب استراتيجيتها الترويجية التي تتضمن الرموز غير القابلة للاستبدال (NFTs).
Jasperتجد مؤسسة Fantom نفسها تواجه خرقًا كبيرًا حيث تم استنزاف 657 ألف دولار أمريكي نتيجة استنفاد أكثر من 35 محفظة عملات مشفرة.
Catherineولكن ربما لأنه معرض دائمًا للهجمات، ومع وجود ثغرة بقيمة 50 مليون دولار في عام 2019 تلوح في الأفق، فإن نهج Upbit تجاه الأمن والمخاطر أكثر حكمة من معظم الناس.
Snake