Vai al contenuto principale
Venice offre modelli con privacy migliorata che vengono eseguiti in Trusted Execution Environments (TEE) e supportano l’End-to-End Encryption (E2EE). Questi modelli forniscono garanzie crittografiche che i tuoi dati rimangano privati, anche da Venice.

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:
La risposta di attestation include:
Per l’uso in produzione, verifica l’attestation lato client effettuando il parsing del quote Intel TDX e controllando l’attestation NVIDIA.
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
E2EE richiede un’implementazione lato client. Gli esempi seguenti mostrano il protocollo completo.

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):
Python:

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 ruolo user e system devono essere cifrati.
Quando gli header E2EE sono presenti, tutti i messaggi con ruolo user e system devono essere cifrati. L’invio di qualsiasi contenuto in chiaro in questi ruoli produrrà un errore “Encrypted field is not valid hex”.

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

Limitazioni di E2EE

E2EE ha alcuni vincoli dovuti ai requisiti di cifratura:

Best practice di sicurezza

  1. Genera nuove coppie di chiavi per ogni sessione - Non riutilizzare chiavi effimere
  2. Azzera le chiavi private - Cancella i byte della chiave privata dalla memoria quando hai finito
  3. Verifica l’attestation - Controlla sempre verified: true e la corrispondenza del nonce
  4. Controlla la modalità debug - Rifiuta le attestation da enclavi in debug
  5. Usa lo streaming - E2EE richiede lo streaming per la corretta segmentazione della cifratura
  6. Gestisci gli errori con eleganza - Non esporre errori di decifratura agli utenti
  7. Usa nonce da 32 byte - I provider TEE richiedono esattamente 32 byte

Best practice

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.
Genera sempre un nuovo nonce casuale per ogni richiesta di attestation. Questo previene attacchi replay in cui un attaccante potrebbe servire un’attestation obsoleta.
La chiave di firma dovrebbe essere legata al campo TDX REPORTDATA. Questo dimostra che la chiave è stata generata all’interno dell’enclave.
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.
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

La lunghezza del nonce non è corretta. I provider TEE richiedono esattamente 32 byte (64 caratteri hex).
  • Usa crypto.randomBytes(32).toString('hex') (JS) o secrets.token_hex(32) (Python)
  • Errore comune: secrets.token_hex(16) produce 32 caratteri hex (16 byte), non 32 byte
  • 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
  • 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
  • Tutti i messaggi con ruolo user e system devono 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
  • 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)
  • Verifica che l’ID del modello sia corretto e che il modello supporti E2EE
  • Usa l’endpoint /models per verificare i modelli E2EE disponibili

Risorse