فهم مستويات الخصوصية
تشمل نماذج E2EE حماية TEE بالإضافة إلى تشفير من جانب العميل. أما نماذج TEE فتوفر أمان الجيب دون اشتراط تشفير من جانب العميل.
النماذج المتاحة
جارٍ التحميل…
راجع صفحة النماذج للاطلاع على القائمة الكاملة مع التسعير وحدود السياق.
نماذج TEE
تعمل نماذج TEE داخل جيوب مؤمَّنة عتاديًا (Intel TDX، NVIDIA Confidential Computing). تكون أوزان النموذج وبياناتك محمية من النظام المضيف — بما في ذلك البنية التحتية لـ Venice.الاستخدام الأساسي
تعمل نماذج TEE تمامًا مثل النماذج العادية:التحقق من تصديق TEE
يمكنك التحقق تشفيريًا من أن النموذج يعمل داخل TEE حقيقي عبر جلب تقرير التصديق الخاص به:بالنسبة للتحقق من نموذج TEE العادي، يكفي
signing_address وحقول التحقق من جانب الخادم لإجراء فحوصات التصديق الأساسية. ويُطلب signing_key عندما تحتاج إلى اتفاق مفاتيح E2EE من جانب العميل وفحوصات ربط مفاتيح صارمة.توقيعات الاستجابة
يمكن لنماذج TEE توقيع استجاباتها، ما يُثبت أن المخرجات صدرت من الجيب المُصدَّق عليه:نماذج E2EE
تضيف نماذج E2EE تشفيرًا من جانب العميل فوق حماية TEE. تُشفَّر مطالباتك قبل مغادرة جهازك، ولا يستطيع فك تشفيرها سوى TEE. يستخدم Venice E2EE:- ECDH (Elliptic Curve Diffie-Hellman) على secp256k1 لتبادل المفاتيح
- HKDF-SHA256 لاشتقاق المفاتيح
- AES-256-GCM للتشفير المتماثل
- تصديق TEE للتحقق من أن النموذج يعمل في جيب آمن
كيف يعمل E2EE
1
توليد زوج مفاتيح مؤقت
يولّد العميل زوج مفاتيح secp256k1 لهذه الجلسة.
2
جلب تصديق TEE
يطلب العميل
/api/v1/tee/attestation ويتلقّى المفتاح العام للنموذج، ودليل التصديق، والـ nonce.3
التحقق من التصديق
يتحقق العميل من تطابق الـ nonce، وتعطيل وضع التصحيح، وصلاحية التصديق.
4
تشفير الرسائل
يُشفّر العميل المطالبات باستخدام السر المشترك ECDH → HKDF → AES-GCM.
5
إرسال الطلب
يرسل العميل الطلب مع رؤوس E2EE (
X-Venice-TEE-Client-Pub-Key، X-Venice-TEE-Model-Pub-Key، X-Venice-TEE-Signing-Algo).6
معالجة TEE
يفك TEE تشفير الطلب، ويعالجه، ويُشفّر الاستجابة.
7
فك تشفير الاستجابة
يتلقى العميل أجزاءً مشفّرة ويفك تشفيرها باستخدام المفتاح الخاص.
المتطلبات المسبقة
JavaScript (Node.js ESM):الخطوة 1: التحقق من دعم النموذج لـ E2EE
أولًا، تحقق من أن النموذج يدعم E2EE عبر فحص نقطة النهاية/models.
الخطوة 2: توليد زوج مفاتيح مؤقت
ولّد زوج مفاتيح جديدًا لكل جلسة. يجب الإبقاء على المفتاح الخاص في الذاكرة فقط وتصفيره بأمان بعد الاستخدام.مساعدات التحقق
استخدم دوال المساعدة هذه للتحقق من المفاتيح والمحتوى المشفّر قبل إرسال الطلبات.الخطوة 3: جلب تصديق TEE والتحقق منه
يُثبت التصديق أن النموذج يعمل داخل TEE حقيقي. تحقق دائمًا من التصديق قبل الوثوق بمفتاح النموذج العام.مهم: طول الـ nonce — يجب أن يكون nonce العميل بطول 32 بايت (64 محرف hex). تشترط بعض مزوّدي TEE 32 بايت بالضبط وترفض أي nonce أقصر.
الخطوة 4: تشفير الرسائل
قم بتشفير رسائل المستخدم والنظام قبل الإرسال. تحتاج رسائل دورuser وsystem فقط إلى التشفير.
الخطوة 5: إرسال الطلب مع رؤوس E2EE
ضمِّن الرؤوس المطلوبة لتمكين معالجة E2EE.الخطوة 6: فك تشفير أجزاء الاستجابة
تكون الاستجابات من نماذج E2EE أجزاءً مشفّرة بترميز hex. فك تشفير كل جزء باستخدام مفتاحك الخاص.مثال عملي كامل
- JavaScript
- Python
قيود E2EE
أفضل ممارسات الأمان
- ولّد أزواج مفاتيح جديدة لكل جلسة — لا تُعد استخدام المفاتيح المؤقتة
- املأ المفاتيح الخاصة بالأصفار — امسح بايتات المفتاح الخاص من الذاكرة عند الانتهاء
- تحقق من التصديق — تأكد دائمًا من
verified: trueومطابقة nonce - افحص وضع التصحيح — ارفض التصديقات من جيوب التصحيح
- استخدم البث المتدفق — يتطلب E2EE البث للتجزئة الصحيحة للتشفير
- عالج الأخطاء بأناقة — لا تُظهر أخطاء فك التشفير للمستخدمين
- استخدم nonce بحجم 32 بايت — تتطلب مزوّدات TEE 32 بايت بالضبط
أفضل الممارسات
تحقق دائمًا من التصديق في الإنتاج
تحقق دائمًا من التصديق في الإنتاج
لا تكتفِ بالثقة في استجابة
verified: true. قم بتحليل اقتباس Intel TDX من جانب العميل وتحقق من أن القياسات تطابق القيم المتوقعة. بالنسبة إلى وحدات معالجة الرسومات من NVIDIA، تحقق من التصديق عبر خدمة التحقق من NVIDIA.استخدم nonces جديدة
استخدم nonces جديدة
ولّد دائمًا nonce عشوائيًا جديدًا لكل طلب تصديق. يمنع ذلك هجمات إعادة التشغيل التي يمكن للمهاجم فيها تقديم تصديق قديم.
تحقق من ربط المفتاح
تحقق من ربط المفتاح
يجب أن يكون مفتاح التوقيع مرتبطًا بحقل TDX REPORTDATA. وهذا يُثبت أن المفتاح وُلّد داخل الجيب.
افحص وضع التصحيح
افحص وضع التصحيح
تحقق من أن تصديق TDX لا يحتوي على أعلام تصحيح مضبوطة. يمكن فحص جيب التصحيح ولا ينبغي الوثوق به في الإنتاج.
استخدم SDK الخاصة بنا لـ E2EE
استخدم SDK الخاصة بنا لـ E2EE
يتطلب E2EE تنفيذًا تشفيريًا دقيقًا. استخدم SDK الرسمية الخاصة بنا بدلًا من تنفيذ البروتوكول بنفسك.
التحقق من قدرات النموذج
يمكنك التحقق مما إذا كان النموذج يدعم TEE أو E2EE عبر نقطة نهاية النماذج:معالجة الأخطاء
استكشاف الأخطاء وإصلاحها
502 Bad Gateway أو 'Nonce must be exactly 32 bytes'
502 Bad Gateway أو 'Nonce must be exactly 32 bytes'
طول الـ nonce غير صحيح. تتطلب مزوّدات TEE 32 بايت (64 محرف hex) بالضبط.
- استخدم
crypto.randomBytes(32).toString('hex')(JS) أوsecrets.token_hex(32)(Python) - خطأ شائع:
secrets.token_hex(16)يُنتج 32 محرف hex (16 بايت)، وليس 32 بايت
فشل التحقق من التصديق
فشل التحقق من التصديق
- تأكد من أن النموذج يدعم E2EE (
supportsE2EE: true) - تحقق من أن مفتاح API صالح ولديه وصول إلى النموذج المطلوب
- تحقق من اتصال الشبكة بـ Venice API
فشل فك التشفير
فشل فك التشفير
- تأكد من أنك تستخدم نفس المفتاح الخاص الذي ولّد المفتاح العام المرسل في الرؤوس
- تحقق من أن محتوى الاستجابة مشفّر فعلًا بترميز hex (E2EE نشط)
- تأكد من أن المفتاح العام للنموذج يطابق ما استُخدم للتشفير
Encrypted field is not valid hex
Encrypted field is not valid hex
- يجب تشفير جميع رسائل دور
userوsystemعند وجود رؤوس E2EE - تحقق من أن المحتوى المشفّر يجتاز التحقق
isValidEncrypted()(الحد الأدنى 186 محرف hex) - تأكد من أن إخراج التشفير hex بأحرف صغيرة دون أي بادئات
أخطاء المفتاح العام غير الصالح
أخطاء المفتاح العام غير الصالح
- يجب أن يكون المفتاح العام للعميل بطول 130 محرف hex بالضبط ويبدأ بـ
04 - استخدم المساعد
validateClientPubkey()للتحقق من التنسيق قبل الإرسال - تأكد من استخدام تنسيق المفتاح العام غير المضغوط (65 بايت = 130 محرف hex)
النموذج غير موجود
النموذج غير موجود
- تحقق من صحة معرّف النموذج وأنه يدعم E2EE
- استخدم نقطة النهاية
/modelsللتحقق من نماذج E2EE المتاحة