Passer au contenu principal
Venice propose des modèles à confidentialité renforcée qui s’exécutent dans des Trusted Execution Environments (TEE) et prennent en charge le chiffrement de bout en bout (E2EE). Ces modèles offrent des garanties cryptographiques que vos données restent privées — même vis-à-vis de Venice.

Comprendre les niveaux de confidentialité

Les modèles E2EE incluent la protection TEE plus le chiffrement côté client. Les modèles TEE fournissent la sécurité de l’enclave sans nécessiter de chiffrement côté client.

Modèles disponibles

Loading…
Consultez la page Modèles pour la liste complète avec les prix et les limites de contexte.

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 :
La réponse d’attestation inclut :
Pour un usage en production, vérifiez l’attestation côté client en parsant le quote Intel TDX et en vérifiant l’attestation NVIDIA.
Pour la vérification d’un modèle TEE simple, 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
L’E2EE nécessite une implémentation côté client. Les exemples ci-dessous montrent le protocole complet.

Comment fonctionne l’E2EE

1

Générer une paire de clés éphémères

Le client génère une paire de clés secp256k1 pour cette session.
2

Récupérer l'attestation TEE

Le client interroge /api/v1/tee/attestation et reçoit la clé publique du modèle, les preuves d’attestation et le nonce.
3

Vérifier l'attestation

Le client vérifie la correspondance du nonce, l’absence de mode debug et la validité de l’attestation.
4

Chiffrer les messages

Le client chiffre les prompts en utilisant le secret partagé ECDH → HKDF → AES-GCM.
5

Envoyer la requête

Le client envoie la requête avec les en-têtes E2EE (X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).
6

Traitement par le TEE

Le TEE déchiffre la requête, la traite et chiffre la réponse.
7

Déchiffrer la réponse

Le client reçoit les chunks chiffrés et les déchiffre avec sa clé privée.

Prérequis

JavaScript (Node.js ESM) :
Python :

É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.
Important : longueur du nonce — Le nonce client doit faire 32 octets (64 caractères hex). Certains fournisseurs TEE exigent exactement 32 octets et rejettent les nonces plus courts.

Étape 4 : Chiffrer les messages

Chiffrez les messages utilisateur et système avant l’envoi. Seuls les messages des rôles user et system doivent être chiffrés.
Lorsque les en-têtes E2EE sont présents, tous les messages des rôles user et system doivent être chiffrés. Envoyer du contenu en clair dans ces rôles entraînera une erreur « Encrypted field is not valid hex ».

É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

Limitations de l’E2EE

L’E2EE comporte certaines contraintes liées aux exigences de chiffrement :

Bonnes pratiques de sécurité

  1. Générez de nouvelles paires de clés à chaque session — Ne réutilisez pas les clés éphémères
  2. 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é
  3. Vérifiez l’attestation — Vérifiez toujours verified: true et la correspondance du nonce
  4. Cherchez le mode debug — Rejetez les attestations provenant d’enclaves en debug
  5. Utilisez le streaming — L’E2EE requiert le streaming pour un chunking correct du chiffrement
  6. Gérez les erreurs avec élégance — N’exposez pas les erreurs de déchiffrement aux utilisateurs
  7. Utilisez des nonces de 32 octets — Les fournisseurs TEE exigent exactement 32 octets

Bonnes pratiques

Ne vous contentez pas de faire confiance à la réponse 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.
Générez toujours un nouveau nonce aléatoire pour chaque requête d’attestation. Cela empêche les attaques par rejeu, où un attaquant pourrait servir une attestation périmée.
La clé de signature doit être liée au champ REPORTDATA de TDX. Cela prouve que la clé a été générée à l’intérieur de l’enclave.
Vérifiez que l’attestation TDX n’a pas de flags debug activés. Une enclave en debug peut être inspectée et ne doit pas être considérée comme fiable pour la production.
L’E2EE nécessite une implémentation cryptographique minutieuse. Utilisez nos SDK officiels plutôt que d’implémenter le protocole vous-même.

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

La longueur du nonce est incorrecte. Les fournisseurs TEE requièrent exactement 32 octets (64 caractères hex).
  • Utilisez crypto.randomBytes(32).toString('hex') (JS) ou secrets.token_hex(32) (Python)
  • Erreur courante : secrets.token_hex(16) produit 32 caractères hex (16 octets), pas 32 octets
  • 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
  • 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
  • Tous les messages de rôle user et system doivent ê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
  • 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)
  • Vérifiez que l’ID du modèle est correct et qu’il prend en charge l’E2EE
  • Utilisez l’endpoint /models pour vérifier les modèles E2EE disponibles

Ressources