ننتقل إلى اليوم الثالث من التعرف أكثر على TEE

يجب أن نسأل باستمرار، "هل بروتوكولي آمن؟" لكن، سؤال أفضل هو: "هل بروتوكولي قوي؟"

دعوني أدخل في التفاصيل هنا. إليك صورة واقعية لما قصدته حقا عندما قلت إن عبء التحقق قد تم تغييره. السياق: في بروتوكولات SGX/TDX TEE الحديثة، يرسل PROVER: + أدلة التصديق (اقتباس/تقرير) + ضمان التحقق ضروري للتحقق من صحة ذلك أو تعتمد البروتوكولات على طرف ثالث وليس على الاستخبارات كمصدر للحقيقة كمصدر للمعلومات الجانبية. الآن، إرسال المحقق نفسه المواد المطلوبة للتحقق (ضمان) إلى المتحقق أو إلى طرف ثالث يزود القطع الأثرية لاتخاذ القرار الحيوي ليس مشكلة كما يبدو على السطح. لكن علينا أن نمر ببعض الوحل لننجح في ذلك. دعني أخبرك لماذا. هذا الاختيار في التصميم يعتمد إلى حد كبير على الواقعية ومقايضة التوفر. العديد من المصادقين لا يريدون الاعتماد على مكالمات شبكة إنتل الحية في كل مصافحة. عادل. فما هي خيارات التصميم التي يركز عليها الناس عادة: 1. المتحقق يجلب مباشرة من Intel PCS لسحب سلسلة شهادات PCK، وCRLs من PCK، وTCBInfo، وQEIdentity، وغيرها. جيد: الانتعاش القوي، خطر التراجع ضئيل سيء: المتحقق يحتاج إلى شبكة خارجية + مشاكل توفر/تأخير إنتل 2. جلب التحقق من ذاكرة تخزين مؤقت موثوقة (PCCS) هنا لدينا خدمة تخزين مؤقت لشهادات التوفير التي تتزامن مع Intel PCS وتعتبر مصدر الحقيقة للمراجعين (بدلا من Intel) جيد: بعض الحيوية، وحدود ثقة محكمة، وتأخير منخفض سيء: الأمن داخل وحول PCCS 3. Prover يوفر ضمانات (سير عمل غير متصل تقريبا) يجمع Prover الضمانات مع العرض، ويقوم المتحقق بالتحقق منها محليا. جيد: يمكن للمحقق أن يعمل حتى مع القيود الشديدة سيء: تراجع وملل كثير. ------ الآن، ما نوع البنية التي يجب أن يختارها البروتوكول؟ يعتمد ذلك كليا على ضمانات الأمان الموعودة بها، ومدى أهمية كل فحص توثيق صحيح لعملائهم، وسرعة النقل التي يناسبونها. ---- دعونا نتحدث عن الحالة الثانية الأكثر شيوعا التي تعتمد فيها البروتوكولات على PCCS بدلا من التحدث إلى إنتل. 1. عادة ما يدار PCCS من قبل من يدير البنية التحتية على جانب المحقق. 2. لذا، البروتوكولات التي تريد ثقة محدودة في أطراف ثالثة تدير PCCS خاصة بها. 3. ومع ذلك، يعتمد عدد كبير من الفرق على نقطة نهاية PCCS توفرها السحابة أو منصات SGX المدارة. الآن، الاعتماد على طرف ثالث للحصول على القطع الأثرية الحرجة التي تحدد ما إذا كان التصديق سيعتبر صحيحا أم لا، يبدو غريبا. لكن هناك بعض الضمانات التشفيرية التي تلعب دورا هنا. 1. يجب أن يغلق المتحقق العاقل في حالة فشل في الكشف عن المفقود أو المشوه أو أي شيء مشبوه. إذا لم يكن بالإمكان بناء سلسلة التوقيع. ارفض. 2. كل ضمان مهم يتم (أو من الناحية المثالية) التحقق من صحتها تشفيريا. 3. ببساطة، إذا كان PCCS "يغير الإدخالات"، فلا يمكنه تزوير توقيعات المعلومات. 4. الضرر الذي يمكن أن يسببه PCCS (وهو ذاكرة مؤقتة ولا ينبغي التعامل معها كمرساة للأمانة للنزاهة) هو: + اقتطاع الإدخال + تقدم إدخالات قديمة لكنها صالحة سابقا + إدخالات سيئة/مشوهة ---- لكن لنفترض أن هذه الضمانات ليست كافية لك، وتريد أن تدفع نحو أكبر قدر ممكن من عدم الثقة أثناء بناء بروتوكول TEE في صناعة الويب 3 القديمة لدينا. إذا، تقول إننا لن نعتمد على طرف ثالث لنظام PCCS الخاص بنا وسنبني نظامنا الخاص. الآن دعونا نرى مدى صعوبة أن يكون ذلك "صحيحا تماما". > إذا كان المتحقق سيجلب ضمانا من PCCS، فيجب أن يتصرف PCCS كبوابة للتجديد وليس كمرآة غبية. يجب عليك بالتأكيد التأكد: + PCCS تزامن بشكل دوري من Intel PCS + يرفض تقديم ضمان منتهية الصلاحية + يحتفظ فقط بالإصدار الأحدث لأجهزة FMSPC/TCBInfo/QEIdentity ولن يخدم الإصدارات الأقدم + يمكنه تثبيت الحد الأدنى المقبول ل 'tcbEvaluationDataNumber' / "تاريخ الإصدار" ل TCBInfo/QEIdentity. + سجلات PCCS + إنذارات عندما لا يمكن تحديثها في الوقت المناسب. + وأشياء أخرى تعتمد على تفاصيل بروتوكلك وإذا لم ترغب في تنفيذها في PCCS الخاص بك، فسيتعين عليك تنفيذ هذه الفحوصات في المتحقق محليا. لكن مرة أخرى، الدفاع العميق هو جوهر اللعبة. --- أقوى عقلية أمنية يمكنني تركها لكم في هذا الموضوع هي: > تعامل الضمان الذي يقدمه الدليل كتلميح، وليس كحقيقة. ثق دائما بتأكيدك الشامل على أي وعود تأتي من أي شخص. يجب أن تتضمن قائمة التحقق الخاصة بك لمشاكل مورد الضمان الخاص بك: + فشل في الإغلاق بسبب ضمان مفقود/غير صالح + التحقق من التواقيع/السلاسل لجميع كائنات الثقة + فرض التجديد (الوقت، انتهاء الصلاحية، والرتابة) + تخزين الأحدث ورفض الانحدارات ------ مع ذلك، أشكركم وأتمنى لك كل التوفيق على مغامراتك مع TEE. وإذا كنت بحاجة لأي مساعدة حول نقاط التثبيت على الثقة، وسياسات البروتوكول الخاصة بك، وكيفية التعامل مع TEEs لبناء بروتوكول قوي، @bluethroat_labs يسعدني مساعدتك.