الانتقال إلى المحتوى الرئيسي
يقدّم Venice نماذج معزّزة للخصوصية تعمل داخل بيئات تنفيذ موثوقة (TEE) وتدعم التشفير الكامل من طرف إلى طرف (E2EE). توفّر هذه النماذج ضمانات تشفيرية تكفل أن تبقى بياناتك خاصة — حتى عن Venice نفسها.

فهم مستويات الخصوصية

تشمل نماذج E2EE حماية TEE بالإضافة إلى تشفير من جانب العميل. أما نماذج TEE فتوفر أمان الجيب دون اشتراط تشفير من جانب العميل.

النماذج المتاحة

جارٍ التحميل…
راجع صفحة النماذج للاطلاع على القائمة الكاملة مع التسعير وحدود السياق.

نماذج TEE

تعمل نماذج TEE داخل جيوب مؤمَّنة عتاديًا (Intel TDX، NVIDIA Confidential Computing). تكون أوزان النموذج وبياناتك محمية من النظام المضيف — بما في ذلك البنية التحتية لـ Venice.

الاستخدام الأساسي

تعمل نماذج TEE تمامًا مثل النماذج العادية:

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

يمكنك التحقق تشفيريًا من أن النموذج يعمل داخل TEE حقيقي عبر جلب تقرير التصديق الخاص به:
تتضمن استجابة التصديق:
للاستخدام في الإنتاج، تحقق من التصديق من جانب العميل عبر تحليل اقتباس Intel TDX والتحقق من تصديق NVIDIA.
بالنسبة للتحقق من نموذج 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 تنفيذًا من جانب العميل. توضّح الأمثلة أدناه البروتوكول الكامل.

كيف يعمل 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):
Python:

الخطوة 1: التحقق من دعم النموذج لـ E2EE

أولًا، تحقق من أن النموذج يدعم E2EE عبر فحص نقطة النهاية /models.

الخطوة 2: توليد زوج مفاتيح مؤقت

ولّد زوج مفاتيح جديدًا لكل جلسة. يجب الإبقاء على المفتاح الخاص في الذاكرة فقط وتصفيره بأمان بعد الاستخدام.

مساعدات التحقق

استخدم دوال المساعدة هذه للتحقق من المفاتيح والمحتوى المشفّر قبل إرسال الطلبات.

الخطوة 3: جلب تصديق TEE والتحقق منه

يُثبت التصديق أن النموذج يعمل داخل TEE حقيقي. تحقق دائمًا من التصديق قبل الوثوق بمفتاح النموذج العام.
مهم: طول الـ nonce — يجب أن يكون nonce العميل بطول 32 بايت (64 محرف hex). تشترط بعض مزوّدي TEE 32 بايت بالضبط وترفض أي nonce أقصر.

الخطوة 4: تشفير الرسائل

قم بتشفير رسائل المستخدم والنظام قبل الإرسال. تحتاج رسائل دور user وsystem فقط إلى التشفير.
عند وجود رؤوس E2EE، يجب تشفير جميع رسائل دور user وsystem. إرسال أي محتوى نصي عادي في هذه الأدوار سيؤدي إلى خطأ “Encrypted field is not valid hex”.

الخطوة 5: إرسال الطلب مع رؤوس E2EE

ضمِّن الرؤوس المطلوبة لتمكين معالجة E2EE.

الخطوة 6: فك تشفير أجزاء الاستجابة

تكون الاستجابات من نماذج E2EE أجزاءً مشفّرة بترميز hex. فك تشفير كل جزء باستخدام مفتاحك الخاص.

مثال عملي كامل

قيود E2EE

يفرض E2EE بعض القيود نتيجة متطلبات التشفير:

أفضل ممارسات الأمان

  1. ولّد أزواج مفاتيح جديدة لكل جلسة — لا تُعد استخدام المفاتيح المؤقتة
  2. املأ المفاتيح الخاصة بالأصفار — امسح بايتات المفتاح الخاص من الذاكرة عند الانتهاء
  3. تحقق من التصديق — تأكد دائمًا من verified: true ومطابقة nonce
  4. افحص وضع التصحيح — ارفض التصديقات من جيوب التصحيح
  5. استخدم البث المتدفق — يتطلب E2EE البث للتجزئة الصحيحة للتشفير
  6. عالج الأخطاء بأناقة — لا تُظهر أخطاء فك التشفير للمستخدمين
  7. استخدم nonce بحجم 32 بايت — تتطلب مزوّدات TEE 32 بايت بالضبط

أفضل الممارسات

لا تكتفِ بالثقة في استجابة verified: true. قم بتحليل اقتباس Intel TDX من جانب العميل وتحقق من أن القياسات تطابق القيم المتوقعة. بالنسبة إلى وحدات معالجة الرسومات من NVIDIA، تحقق من التصديق عبر خدمة التحقق من NVIDIA.
ولّد دائمًا nonce عشوائيًا جديدًا لكل طلب تصديق. يمنع ذلك هجمات إعادة التشغيل التي يمكن للمهاجم فيها تقديم تصديق قديم.
يجب أن يكون مفتاح التوقيع مرتبطًا بحقل TDX REPORTDATA. وهذا يُثبت أن المفتاح وُلّد داخل الجيب.
تحقق من أن تصديق TDX لا يحتوي على أعلام تصحيح مضبوطة. يمكن فحص جيب التصحيح ولا ينبغي الوثوق به في الإنتاج.
يتطلب E2EE تنفيذًا تشفيريًا دقيقًا. استخدم SDK الرسمية الخاصة بنا بدلًا من تنفيذ البروتوكول بنفسك.

التحقق من قدرات النموذج

يمكنك التحقق مما إذا كان النموذج يدعم TEE أو E2EE عبر نقطة نهاية النماذج:

معالجة الأخطاء

استكشاف الأخطاء وإصلاحها

طول الـ 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 نشط)
  • تأكد من أن المفتاح العام للنموذج يطابق ما استُخدم للتشفير
  • يجب تشفير جميع رسائل دور user وsystem عند وجود رؤوس E2EE
  • تحقق من أن المحتوى المشفّر يجتاز التحقق isValidEncrypted() (الحد الأدنى 186 محرف hex)
  • تأكد من أن إخراج التشفير hex بأحرف صغيرة دون أي بادئات
  • يجب أن يكون المفتاح العام للعميل بطول 130 محرف hex بالضبط ويبدأ بـ 04
  • استخدم المساعد validateClientPubkey() للتحقق من التنسيق قبل الإرسال
  • تأكد من استخدام تنسيق المفتاح العام غير المضغوط (65 بايت = 130 محرف hex)
  • تحقق من صحة معرّف النموذج وأنه يدعم E2EE
  • استخدم نقطة النهاية /models للتحقق من نماذج E2EE المتاحة

الموارد