Comprendiendo los niveles de privacidad
Modelos disponibles
Modelos TEE
Los modelos TEE se ejecutan dentro de enclaves protegidos por hardware (Intel TDX, NVIDIA Confidential Computing). Los pesos del modelo y tus datos están protegidos frente al sistema anfitrión, incluida la infraestructura de Venice.Uso básico
Los modelos TEE funcionan exactamente igual que los modelos normales:Verificación de la atestación TEE
Puedes verificar criptográficamente que un modelo se está ejecutando en un TEE genuino obteniendo su informe de atestación:signing_address y los campos de verificación del lado del servidor son suficientes para las comprobaciones básicas de atestación. Se requiere un signing_key cuando necesitas el acuerdo de claves E2EE del lado del cliente y comprobaciones estrictas de vinculación de claves.Firmas de respuesta
Los modelos TEE pueden firmar sus respuestas, demostrando que la salida provino del enclave atestado:Modelos E2EE
Los modelos E2EE añaden cifrado del lado del cliente sobre la protección TEE. Tus prompts se cifran antes de salir de tu dispositivo, y solo el TEE puede descifrarlos. E2EE de Venice utiliza:- ECDH (Elliptic Curve Diffie-Hellman) sobre secp256k1 para el intercambio de claves
- HKDF-SHA256 para la derivación de claves
- AES-256-GCM para el cifrado simétrico
- Atestación TEE para verificar que el modelo se ejecuta en un enclave seguro
Cómo funciona E2EE
Generar par de claves efímeras
Obtener atestación TEE
/api/v1/tee/attestation y recibe la clave pública del modelo, la evidencia de atestación y el nonce.Verificar la atestación
Cifrar mensajes
Enviar solicitud
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).Procesamiento en el TEE
Descifrar la respuesta
Requisitos previos
JavaScript (Node.js ESM):Paso 1: Verificar el soporte de E2EE del modelo
Primero, verifica que el modelo admite E2EE consultando el endpoint/models.
Paso 2: Generar par de claves efímeras
Genera un nuevo par de claves para cada sesión. La clave privada debe mantenerse solo en memoria y borrarse de forma segura tras su uso.Ayudantes de validación
Usa estas funciones auxiliares para validar las claves y el contenido cifrado antes de enviar las solicitudes.Paso 3: Obtener y verificar la atestación TEE
La atestación demuestra que el modelo se está ejecutando en un TEE genuino. Verifica siempre la atestación antes de confiar en la clave pública del modelo.Paso 4: Cifrar los mensajes
Cifra los mensajes de usuario y de sistema antes de enviarlos. Solo los mensajes con roluser y system necesitan cifrarse.
Paso 5: Enviar la solicitud con cabeceras E2EE
Incluye las cabeceras requeridas para habilitar el procesamiento E2EE.Paso 6: Descifrar los fragmentos de respuesta
Las respuestas de los modelos E2EE son fragmentos cifrados codificados en hexadecimal. Descifra cada fragmento con tu clave privada.Ejemplo completo en funcionamiento
- JavaScript
- Python
Limitaciones de E2EE
Buenas prácticas de seguridad
- Genera nuevos pares de claves por sesión — No reutilices claves efímeras.
- Rellena con ceros las claves privadas — Borra los bytes de la clave privada de la memoria cuando termines.
- Verifica la atestación — Comprueba siempre que
verified: truey que el nonce coincide. - Comprueba el modo de depuración — Rechaza las atestaciones de enclaves en depuración.
- Usa streaming — E2EE requiere streaming para una correcta fragmentación del cifrado.
- Gestiona los errores con cuidado — No expongas los errores de descifrado a los usuarios.
- Usa nonces de 32 bytes — Los proveedores de TEE requieren exactamente 32 bytes.
Buenas prácticas
Verifica siempre la atestación en producción
Verifica siempre la atestación en producción
verified: true. Parsea la cita Intel TDX en el cliente y verifica que las mediciones coinciden con los valores esperados. Para GPU de NVIDIA, verifica la atestación mediante el servicio de verificación de NVIDIA.Usa nonces nuevos
Usa nonces nuevos
Verifica la vinculación de la clave
Verifica la vinculación de la clave
Comprueba el modo de depuración
Comprueba el modo de depuración
Usa nuestros SDK para E2EE
Usa nuestros SDK para E2EE
Comprobación de las capacidades del modelo
Puedes comprobar si un modelo admite TEE o E2EE a través del endpoint de modelos:Manejo de errores
Solución de problemas
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). - Error común:
secrets.token_hex(16)produce 32 caracteres hex (16 bytes), no 32 bytes.
Verificación de la atestación fallida
Verificación de la atestación fallida
- Comprueba que el modelo admite E2EE (
supportsE2EE: true). - Verifica que tu clave API es válida y tiene acceso al modelo solicitado.
- Verifica la conectividad de red con la API de Venice.
Descifrado fallido
Descifrado fallido
- Asegúrate de utilizar la misma clave privada que generó la clave pública enviada en las cabeceras.
- Comprueba que el contenido de la respuesta está realmente codificado en hexadecimal (E2EE activo).
- Verifica que la clave pública del modelo coincide con la utilizada para cifrar.
Encrypted field is not valid hex
Encrypted field is not valid hex
- Todos los mensajes con rol
userysystemdeben estar cifrados cuando hay cabeceras E2EE presentes. - Verifica que tu contenido cifrado pasa la validación
isValidEncrypted()(mínimo 186 caracteres hex). - Comprueba que la salida del cifrado es hex en minúsculas sin ningún prefijo.
Errores de clave pública no válida
Errores de clave pública no válida
- La clave pública del cliente debe tener exactamente 130 caracteres hexadecimales comenzando con
04. - Usa el ayudante
validateClientPubkey()para verificar el formato antes de enviar. - Asegúrate de utilizar el formato de clave pública no comprimido (65 bytes = 130 caracteres hex).
Modelo no encontrado
Modelo no encontrado
- Verifica que el ID del modelo es correcto y que el modelo admite E2EE.
- Usa el endpoint
/modelspara comprobar los modelos E2EE disponibles.