ملخص

  • أثار Muhammad Usama Sardar في RIPE 93 سؤال إدخال إثبات المنصة داخل مصافحة TLS. وتصف نشرة Cocos AI لمسار Intel TDX اختباراً قَبِل قيمة جلسة معاد استخدامها أو غير مطابقة، ثم سمح بمرور بيانات التطبيق بعد المصافحة.
  • تصف نشرة أخرى مسار AMD SEV-SNP عندما تغيب القيمة المتوقعة من المتصل؛ عندها يمكن قبول دليل لا يخص الاتصال. انتقلت Cocos AI في الإصدار 0.9.0 إلى الإثبات بعد المصافحة، ويشترط ميثاق IETF SEAT حداثة الدليل لكل اتصال.

فتّش الحارس البطاقة بعناية، ثم نسي النظر إلى المعطف المعلّقة عليه. في نشرة Cocos AI الأصلية عن Intel TDX، تلقّى المدقق قيمة يفترض أن تحدد جلسة TLS الحالية، لكن المسار المختبر لم يضعها في سياسة فحص تقرير العتاد. قبل الاختبار دليلاً خارجياً يحمل reportData مختلفاً أو مستخدماً سابقاً. وبعد اكتمال المصافحة خرجت بيانات التطبيق. قرار الثقة اتُّخذ عند مقارنة لم تحدث.

في برنامج RIPE 93 عُرضت مداخلة Sardar يوم 27 أكتوبر. ينتقد وضع الإثبات مبكراً داخل المصافحة وما يجلبه من تعقيد واحتمالات خطأ في الربط. تضعه نشرة الشركة أمام حالة محددة: إجراء أمني أنيق أتم خطواته، بينما بقيت هوية الجلسة التي يخصها التقرير بلا تحقق كافٍ.

أما نشرة Cocos AI الثانية فتخص AMD SEV-SNP. كان الإصدار 0.8.2 يضبط قيمة ReportData المتوقعة فقط عندما يرسل المستدعي قيمة غير فارغة. إذا غابت، أمكن قبول دليل لا يخص الاتصال؛ وإذا حُددت قيمة غير فارغة، رُفضت القيم المخالفة. وتقول الشركة إنها انتقلت في 0.9.0 إلى الإثبات بعد المصافحة. هنا لا تقع المشكلة في كل استعمال للمسار، بل في السماح بفراغ كان ينبغي أن يغلق الباب.

وتعرض نشرة Edgeless Systems عن Contrast خللاً مختلفاً: وفق شروط اعتراض الاتصال وتزوير التقرير أو استخراج الأسرار التي تحددها الشركة، كان تقرير صالح من جهاز آخر قادراً على إقناع المدقق القديم إذا طابقت القياسات. أضاف الإصدار 1.16.0 قوائم بمعرّفات العتاد المسموح. صحة التقرير وهوية الجهاز وحداثة الاتصال ثلاثة أسئلة مستقلة.

يلزم ميثاق مجموعة IETF SEAT ربط الدليل باتصال TLS، وإمكان التحقق من حداثته لكل اتصال، وإجراء تحليل رسمي بالتوازي مع صياغة المواصفة. يمكن اختبار ذلك عملياً بتقرير قديم، وقيمة متوقعة غائبة، وتقرير صادر من جهاز آخر. بطاقة الثقة تستحق اسمها عندما تمنع مرور البيانات في الحالات الثلاث.