IA à confidentialité renforcée avec Trusted Execution Environments et chiffrement de bout en bout
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.
Le modèle s’exécute dans une enclave sécurisée matériellement. Venice ne peut pas accéder au calcul. Vous pouvez le vérifier par attestation.
E2EE
e2ee-*
Chiffrement de bout en bout complet. Vos prompts sont chiffrés côté client avant l’envoi. Seul le TEE peut les déchiffrer.
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.
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.
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 :
# Générer un nonce aléatoire (empêche les attaques par rejeu)NONCE=$(openssl rand -hex 16)# Récupérer l'attestationcurl "https://api.venice.ai/api/v1/tee/attestation?model=tee-qwen3-5-122b-a10b&nonce=$NONCE" \ -H "Authorization: Bearer $API_KEY_VENICE"
La réponse d’attestation inclut :
Champ
Description
verified
Indique si l’attestation a passé la vérification côté serveur
nonce
Votre nonce, confirmant la fraîcheur
model
L’ID du modèle attesté
tee_provider
Identifiant du fournisseur TEE
intel_quote
Quote Intel TDX brut (base64) pour vérification côté client
nvidia_payload
Données d’attestation GPU NVIDIA (le cas échéant)
signing_key
Clé publique pour vérifier les signatures de réponse (généralement requise pour les flux E2EE ; peut être omise pour certains modèles TEE simples)
signing_address
Adresse Ethereum dérivée de la clé de signature
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é.
Les modèles TEE peuvent signer leurs réponses, prouvant que la sortie provient de l’enclave attestée :
# Après avoir obtenu une completion, vérifier la signaturecurl "https://api.venice.ai/api/v1/tee/signature?model=tee-qwen3-5-122b-a10b&request_id=chatcmpl-abc123" \ -H "Authorization: Bearer $API_KEY_VENICE"
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.
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.
import { ec as EC } from 'elliptic'function generateEphemeralKeyPair() { const ec = new EC('secp256k1') const keyPair = ec.genKeyPair() return { privateKey: new Uint8Array(keyPair.getPrivate().toArray('be', 32)), publicKeyHex: keyPair.getPublic('hex'), // Format non compressé (65 octets hex) }}// Sécurité : remplir la clé privée de zéros une fois terminéfunction zeroFill(arr) { arr.fill(0)}
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.
import crypto from 'crypto'async function fetchAndVerifyAttestation(modelId, apiKey) { // Générer un nonce client pour la protection anti-rejeu (32 octets = 64 caractères hex) const clientNonce = crypto.randomBytes(32).toString('hex') const response = await fetch( `https://api.venice.ai/api/v1/tee/attestation?model=${encodeURIComponent(modelId)}&nonce=${clientNonce}`, { headers: { Authorization: `Bearer ${apiKey}` } } ) const attestation = await response.json() // Vérifier l'attestation if (attestation.verified !== true) { throw new Error('TEE attestation verification failed on server') } if (attestation.nonce !== clientNonce) { throw new Error('Attestation nonce mismatch - possible replay attack') } // Obtenir la clé publique du modèle pour le chiffrement const modelPublicKey = attestation.signing_key || attestation.signing_public_key if (!modelPublicKey) { throw new Error('No signing key in attestation response') } return { modelPublicKey, signingAddress: attestation.signing_address, attestation, }}
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 ».
import { gcm } from '@noble/ciphers/aes.js'import { hkdf } from '@noble/hashes/hkdf.js'import { sha256 } from '@noble/hashes/sha2.js'import { ec as EC } from 'elliptic'import crypto from 'crypto'const HKDF_INFO = new TextEncoder().encode('ecdsa_encryption')function encryptMessage(plaintext, modelPublicKeyHex) { const ec = new EC('secp256k1') // Normaliser la clé publique (ajouter le préfixe 04 si nécessaire) let normalizedKey = modelPublicKeyHex if (!normalizedKey.startsWith('04') && normalizedKey.length === 128) { normalizedKey = '04' + normalizedKey } const modelPublicKey = ec.keyFromPublic(normalizedKey, 'hex') // Générer une paire de clés éphémères pour ce message const ephemeralKeyPair = ec.genKeyPair() // Secret partagé ECDH const sharedSecret = ephemeralKeyPair.derive(modelPublicKey.getPublic()) const sharedSecretBytes = new Uint8Array(sharedSecret.toArray('be', 32)) // Dériver la clé AES via HKDF const aesKey = hkdf(sha256, sharedSecretBytes, undefined, HKDF_INFO, 32) // Générer un nonce aléatoire const nonce = crypto.randomBytes(12) // Chiffrer avec AES-GCM const cipher = gcm(aesKey, nonce) const encrypted = cipher.encrypt(new TextEncoder().encode(plaintext)) // Obtenir la clé publique éphémère (non compressée) const ephemeralPublic = new Uint8Array(ephemeralKeyPair.getPublic(false, 'array')) // Combiner : ephemeral_public (65 octets) + nonce (12 octets) + ciphertext const result = new Uint8Array(65 + 12 + encrypted.length) result.set(ephemeralPublic, 0) result.set(nonce, 65) result.set(encrypted, 65 + 12) return Buffer.from(result).toString('hex')}function encryptMessagesForE2EE(messages, modelPublicKey) { return messages.map(msg => { if (msg.role === 'user' || msg.role === 'system') { return { ...msg, content: encryptMessage(msg.content, modelPublicKey), } } return msg })}
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.
Utilisez des nonces frais
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.
Vérifiez la liaison de clé
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.
Cherchez le mode debug
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.
Utilisez nos SDKs pour l'E2EE
L’E2EE nécessite une implémentation cryptographique minutieuse. Utilisez nos SDK officiels plutôt que d’implémenter le protocole vous-même.