Comprendre les niveaux de confidentialité
Modèles disponibles
Modèles TEE
Les modèles TEE s’exécutent à l’intérieur d’enclaves sécurisées matériellement (Intel TDX, NVIDIA Confidential Computing). Les poids du modèle et vos données sont protégés du système hôte — y compris l’infrastructure de Venice.Usage de base
Les modèles TEE fonctionnent exactement comme des modèles réguliers :Vérifier l’attestation TEE
Vous pouvez vérifier cryptographiquement qu’un modèle s’exécute dans un véritable TEE en récupérant son rapport d’attestation :signing_address et les champs de vérification côté serveur suffisent pour des contrôles d’attestation de base. Une signing_key est requise lorsque vous avez besoin d’un accord de clé E2EE côté client et de contrôles stricts de liaison de clé.Signatures de réponse
Les modèles TEE peuvent signer leurs réponses, prouvant que la sortie provient de l’enclave attestée :Modèles E2EE
Les modèles E2EE ajoutent un chiffrement côté client par-dessus la protection TEE. Vos prompts sont chiffrés avant de quitter votre appareil, et seul le TEE peut les déchiffrer. L’E2EE Venice utilise :- ECDH (Elliptic Curve Diffie-Hellman) sur secp256k1 pour l’échange de clés
- HKDF-SHA256 pour la dérivation de clés
- AES-256-GCM pour le chiffrement symétrique
- Attestation TEE pour vérifier que le modèle s’exécute dans une enclave sécurisée
Comment fonctionne l’E2EE
Générer une paire de clés éphémères
Récupérer l'attestation TEE
/api/v1/tee/attestation et reçoit la clé publique du modèle, les preuves d’attestation et le nonce.Vérifier l'attestation
Chiffrer les messages
Envoyer la requête
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).Traitement par le TEE
Déchiffrer la réponse
Prérequis
JavaScript (Node.js ESM) :Étape 1 : Vérifier la prise en charge E2EE par le modèle
Vérifiez d’abord que le modèle prend en charge l’E2EE en interrogeant l’endpoint/models.
Étape 2 : Générer une paire de clés éphémères
Générez une nouvelle paire de clés pour chaque session. La clé privée doit rester en mémoire uniquement et être effacée de manière sécurisée après usage.Helpers de validation
Utilisez ces fonctions helper pour valider les clés et le contenu chiffré avant d’envoyer les requêtes.Étape 3 : Récupérer et vérifier l’attestation TEE
L’attestation prouve que le modèle s’exécute dans un véritable TEE. Vérifiez toujours l’attestation avant de faire confiance à la clé publique du modèle.Étape 4 : Chiffrer les messages
Chiffrez les messages utilisateur et système avant l’envoi. Seuls les messages des rôlesuser et system doivent être chiffrés.
Étape 5 : Envoyer la requête avec les en-têtes E2EE
Incluez les en-têtes requis pour activer le traitement E2EE.Étape 6 : Déchiffrer les chunks de réponse
Les réponses des modèles E2EE sont des chunks chiffrés encodés en hex. Déchiffrez chaque chunk avec votre clé privée.Exemple complet fonctionnel
- JavaScript
- Python
Limitations de l’E2EE
Bonnes pratiques de sécurité
- Générez de nouvelles paires de clés à chaque session — Ne réutilisez pas les clés éphémères
- Effacez les clés privées par remplissage de zéros — Effacez les octets de clé privée de la mémoire une fois terminé
- Vérifiez l’attestation — Vérifiez toujours
verified: trueet la correspondance du nonce - Cherchez le mode debug — Rejetez les attestations provenant d’enclaves en debug
- Utilisez le streaming — L’E2EE requiert le streaming pour un chunking correct du chiffrement
- Gérez les erreurs avec élégance — N’exposez pas les erreurs de déchiffrement aux utilisateurs
- Utilisez des nonces de 32 octets — Les fournisseurs TEE exigent exactement 32 octets
Bonnes pratiques
Vérifiez toujours l'attestation en production
Vérifiez toujours l'attestation en production
verified: true. Parsez le quote Intel TDX côté client et vérifiez que les mesures correspondent aux valeurs attendues. Pour les GPU NVIDIA, vérifiez l’attestation via le service de vérification de NVIDIA.Utilisez des nonces frais
Utilisez des nonces frais
Vérifiez la liaison de clé
Vérifiez la liaison de clé
Cherchez le mode debug
Cherchez le mode debug
Utilisez nos SDKs pour l'E2EE
Utilisez nos SDKs pour l'E2EE
Vérifier les capacités d’un modèle
Vous pouvez vérifier si un modèle prend en charge TEE ou E2EE via l’endpoint models :Gestion des erreurs
Dépannage
502 Bad Gateway ou 'Nonce must be exactly 32 bytes'
502 Bad Gateway ou 'Nonce must be exactly 32 bytes'
- Utilisez
crypto.randomBytes(32).toString('hex')(JS) ousecrets.token_hex(32)(Python) - Erreur courante :
secrets.token_hex(16)produit 32 caractères hex (16 octets), pas 32 octets
Attestation verification failed
Attestation verification failed
- Vérifiez que le modèle prend en charge l’E2EE (
supportsE2EE: true) - Vérifiez que votre clé API est valide et a accès au modèle demandé
- Vérifiez la connectivité réseau vers l’API Venice
Decryption failed
Decryption failed
- Assurez-vous d’utiliser la même clé privée qui a généré la clé publique envoyée dans les en-têtes
- Vérifiez que le contenu de la réponse est bien encodé en hex (E2EE actif)
- Vérifiez que la clé publique du modèle correspond à celle utilisée pour le chiffrement
Encrypted field is not valid hex
Encrypted field is not valid hex
- Tous les messages de rôle
useretsystemdoivent être chiffrés lorsque les en-têtes E2EE sont présents - Vérifiez que votre contenu chiffré passe la validation
isValidEncrypted()(minimum 186 caractères hex) - Vérifiez que la sortie du chiffrement est en hex minuscule sans préfixe
Erreurs de clé publique invalide
Erreurs de clé publique invalide
- La clé publique client doit faire exactement 130 caractères hex et commencer par
04 - Utilisez le helper
validateClientPubkey()pour vérifier le format avant l’envoi - Assurez-vous d’utiliser le format de clé publique non compressée (65 octets = 130 caractères hex)
Modèle introuvable
Modèle introuvable
- Vérifiez que l’ID du modèle est correct et qu’il prend en charge l’E2EE
- Utilisez l’endpoint
/modelspour vérifier les modèles E2EE disponibles