Comprendere i livelli di privacy
I modelli E2EE includono la protezione TEE piĂš la cifratura lato client. I modelli TEE forniscono la sicurezza dellâenclave senza richiedere la cifratura lato client.
Modelli disponibili
CaricamentoâŚ
Consulta la pagina Models per lâelenco completo con prezzi e limiti di contesto.
Modelli TEE
I modelli TEE vengono eseguiti allâinterno di enclavi protette hardware (Intel TDX, NVIDIA Confidential Computing). I pesi del modello e i tuoi dati sono protetti dal sistema host, inclusa lâinfrastruttura di Venice.Utilizzo di base
I modelli TEE funzionano esattamente come i modelli regolari:Verifica dellâattestation TEE
Puoi verificare crittograficamente che un modello sia in esecuzione in un TEE genuino recuperando il suo report di attestation:Per la verifica di un modello TEE semplice,
signing_address e i campi di verifica lato server sono sufficienti per i controlli di attestation di base. Una signing_key è richiesta quando hai bisogno del key agreement E2EE lato client e di controlli rigorosi di key-binding.Firme delle risposte
I modelli TEE possono firmare le loro risposte, dimostrando che lâoutput proviene dallâenclave attestata:Modelli E2EE
I modelli E2EE aggiungono la cifratura lato client sopra la protezione TEE. I tuoi prompt vengono cifrati prima di lasciare il tuo dispositivo, e solo il TEE può decifrarli. Venice E2EE usa:- ECDH (Elliptic Curve Diffie-Hellman) su secp256k1 per lo scambio di chiavi
- HKDF-SHA256 per la derivazione delle chiavi
- AES-256-GCM per la cifratura simmetrica
- TEE attestation per verificare che il modello sia in esecuzione in unâenclave sicura
Come funziona E2EE
1
Genera coppia di chiavi effimere
Il client genera una coppia di chiavi secp256k1 per questa sessione.
2
Recupera attestation TEE
Il client richiede
/api/v1/tee/attestation e riceve la chiave pubblica del modello, le evidenze di attestation e il nonce.3
Verifica attestation
Il client controlla la corrispondenza del nonce, che la modalitĂ debug sia disabilitata e la validitĂ dellâattestation.
4
Cifra messaggi
Il client cifra i prompt usando lo shared secret ECDH â HKDF â AES-GCM.
5
Invia richiesta
Il client invia la richiesta con gli header E2EE (
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).6
Elaborazione TEE
Il TEE decifra la richiesta, la elabora e cifra la risposta.
7
Decifra risposta
Il client riceve chunk cifrati e li decifra con la chiave privata.
Prerequisiti
JavaScript (Node.js ESM):Passo 1: Verifica il supporto E2EE del modello
Prima di tutto, verifica che il modello supporti E2EE controllando lâendpoint/models.
Passo 2: Genera una coppia di chiavi effimere
Genera una nuova coppia di chiavi per ogni sessione. La chiave privata deve essere mantenuta solo in memoria e azzerata in modo sicuro dopo lâuso.Helper di validazione
Usa queste funzioni helper per validare le chiavi e i contenuti cifrati prima di inviare le richieste.Passo 3: Recupera e verifica lâattestation TEE
Lâattestation dimostra che il modello è in esecuzione in un TEE genuino. Verifica sempre lâattestation prima di fidarti della chiave pubblica del modello.Importante: lunghezza del nonce - Il nonce del client deve essere di 32 byte (64 caratteri hex). Alcuni provider TEE richiedono esattamente 32 byte e rifiuteranno nonce piĂš corti.
Passo 4: Cifra i messaggi
Cifra i messaggi user e system prima di inviarli. Solo i messaggi con ruolouser e system devono essere cifrati.
Passo 5: Invia la richiesta con gli header E2EE
Includi gli header richiesti per abilitare lâelaborazione E2EE.Passo 6: Decifra i chunk della risposta
Le risposte dei modelli E2EE sono chunk cifrati codificati in hex. Decifra ogni chunk usando la tua chiave privata.Esempio completo funzionante
- JavaScript
- Python
Limitazioni di E2EE
Best practice di sicurezza
- Genera nuove coppie di chiavi per ogni sessione - Non riutilizzare chiavi effimere
- Azzera le chiavi private - Cancella i byte della chiave privata dalla memoria quando hai finito
- Verifica lâattestation - Controlla sempre
verified: truee la corrispondenza del nonce - Controlla la modalitĂ debug - Rifiuta le attestation da enclavi in debug
- Usa lo streaming - E2EE richiede lo streaming per la corretta segmentazione della cifratura
- Gestisci gli errori con eleganza - Non esporre errori di decifratura agli utenti
- Usa nonce da 32 byte - I provider TEE richiedono esattamente 32 byte
Best practice
Verifica sempre l'attestation in produzione
Verifica sempre l'attestation in produzione
Non fidarti solo della risposta
verified: true. Effettua il parsing del quote Intel TDX lato client e verifica che le misurazioni corrispondano ai valori attesi. Per le GPU NVIDIA, controlla lâattestation tramite il servizio di verifica NVIDIA.Usa nonce freschi
Usa nonce freschi
Genera sempre un nuovo nonce casuale per ogni richiesta di attestation. Questo previene attacchi replay in cui un attaccante potrebbe servire unâattestation obsoleta.
Verifica il key binding
Verifica il key binding
La chiave di firma dovrebbe essere legata al campo TDX REPORTDATA. Questo dimostra che la chiave è stata generata allâinterno dellâenclave.
Controlla la modalitĂ debug
Controlla la modalitĂ debug
Verifica che lâattestation TDX non abbia flag di debug impostati. Unâenclave in debug può essere ispezionata e non dovrebbe essere ritenuta affidabile per la produzione.
Usa i nostri SDK per E2EE
Usa i nostri SDK per E2EE
E2EE richiede unâimplementazione crittografica attenta. Usa i nostri SDK ufficiali invece di implementare il protocollo da solo.
Verifica delle capacitĂ del modello
Puoi controllare se un modello supporta TEE o E2EE tramite lâendpoint models:Gestione degli errori
Troubleshooting
502 Bad Gateway o 'Nonce must be exactly 32 bytes'
502 Bad Gateway o 'Nonce must be exactly 32 bytes'
La lunghezza del nonce non è corretta. I provider TEE richiedono esattamente 32 byte (64 caratteri hex).
- Usa
crypto.randomBytes(32).toString('hex')(JS) osecrets.token_hex(32)(Python) - Errore comune:
secrets.token_hex(16)produce 32 caratteri hex (16 byte), non 32 byte
Verifica dell'attestation fallita
Verifica dell'attestation fallita
- Controlla che il modello supporti E2EE (
supportsE2EE: true) - Verifica che la tua API key sia valida e abbia accesso al modello richiesto
- Verifica la connettivitĂ di rete con lâAPI Venice
Decifratura fallita
Decifratura fallita
- Assicurati di usare la stessa chiave privata che ha generato la chiave pubblica inviata negli header
- Controlla che il contenuto della risposta sia effettivamente codificato in hex (E2EE attivo)
- Verifica che la chiave pubblica del modello corrisponda a quella usata per la cifratura
Encrypted field is not valid hex
Encrypted field is not valid hex
- Tutti i messaggi con ruolo
useresystemdevono essere cifrati quando gli header E2EE sono presenti - Verifica che il tuo contenuto cifrato superi la validazione
isValidEncrypted()(minimo 186 caratteri hex) - Controlla che lâoutput della cifratura sia hex minuscolo senza prefissi
Errori di Invalid public key
Errori di Invalid public key
- La chiave pubblica del client deve essere esattamente 130 caratteri hex che iniziano con
04 - Usa lâhelper
validateClientPubkey()per verificare il formato prima dellâinvio - Assicurati di usare il formato di chiave pubblica non compressa (65 byte = 130 caratteri hex)
Modello non trovato
Modello non trovato
- Verifica che lâID del modello sia corretto e che il modello supporti E2EE
- Usa lâendpoint
/modelsper verificare i modelli E2EE disponibili