Comprendere i livelli di privacy
Modelli disponibili
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: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
Genera coppia di chiavi effimere
Recupera attestation TEE
/api/v1/tee/attestation e riceve la chiave pubblica del modello, le evidenze di attestation e il nonce.Verifica attestation
Cifra messaggi
Invia richiesta
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).Elaborazione TEE
Decifra risposta
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.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
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
Verifica il key binding
Verifica il key binding
Controlla la modalità debug
Controlla la modalità debug
Usa i nostri SDK per E2EE
Usa i nostri SDK per E2EE
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'
- 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