Saltar al contenido principal
Venice ofrece modelos con privacidad mejorada que se ejecutan en entornos de ejecución confiables (TEE) y admiten cifrado de extremo a extremo (E2EE). Estos modelos proporcionan garantías criptográficas de que tus datos permanecen privados, incluso frente a Venice.

Comprendiendo los niveles de privacidad

Los modelos E2EE incluyen protección TEE más cifrado del lado del cliente. Los modelos TEE proporcionan seguridad de enclave sin requerir cifrado del lado del cliente.

Modelos disponibles

Cargando…
Consulta la página de Modelos para ver la lista completa con precios y límites de contexto.

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:
La respuesta de atestación incluye:
En entornos de producción, verifica la atestación del lado del cliente parseando la cita Intel TDX y comprobando la atestación de NVIDIA.
Para la verificación de un modelo TEE simple, 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
E2EE requiere implementación del lado del cliente. Los ejemplos a continuación muestran el protocolo completo.

Cómo funciona E2EE

1

Generar par de claves efímeras

El cliente genera un par de claves secp256k1 para esta sesión.
2

Obtener atestación TEE

El cliente solicita /api/v1/tee/attestation y recibe la clave pública del modelo, la evidencia de atestación y el nonce.
3

Verificar la atestación

El cliente comprueba la coincidencia del nonce, que el modo de depuración esté deshabilitado y la validez de la atestación.
4

Cifrar mensajes

El cliente cifra los prompts utilizando un secreto compartido ECDH → HKDF → AES-GCM.
5

Enviar solicitud

El cliente envía la solicitud con cabeceras E2EE (X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).
6

Procesamiento en el TEE

El TEE descifra la solicitud, la procesa y cifra la respuesta.
7

Descifrar la respuesta

El cliente recibe fragmentos cifrados y los descifra con la clave privada.

Requisitos previos

JavaScript (Node.js ESM):
Python:

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.
Importante: longitud del nonce — El nonce del cliente debe ser de 32 bytes (64 caracteres hexadecimales). Algunos proveedores de TEE requieren exactamente 32 bytes y rechazarán nonces más cortos.

Paso 4: Cifrar los mensajes

Cifra los mensajes de usuario y de sistema antes de enviarlos. Solo los mensajes con rol user y system necesitan cifrarse.
Cuando hay cabeceras E2EE presentes, todos los mensajes con rol user y system deben estar cifrados. Enviar contenido en texto plano en estos roles dará lugar a un error “Encrypted field is not valid hex”.

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

Limitaciones de E2EE

E2EE tiene algunas restricciones debido a los requisitos de cifrado:

Buenas prácticas de seguridad

  1. Genera nuevos pares de claves por sesión — No reutilices claves efímeras.
  2. Rellena con ceros las claves privadas — Borra los bytes de la clave privada de la memoria cuando termines.
  3. Verifica la atestación — Comprueba siempre que verified: true y que el nonce coincide.
  4. Comprueba el modo de depuración — Rechaza las atestaciones de enclaves en depuración.
  5. Usa streaming — E2EE requiere streaming para una correcta fragmentación del cifrado.
  6. Gestiona los errores con cuidado — No expongas los errores de descifrado a los usuarios.
  7. Usa nonces de 32 bytes — Los proveedores de TEE requieren exactamente 32 bytes.

Buenas prácticas

No te limites a confiar en la respuesta 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.
Genera siempre un nuevo nonce aleatorio para cada solicitud de atestación. Esto evita ataques de repetición en los que un atacante podría servir una atestación obsoleta.
La clave de firma debe estar vinculada al campo TDX REPORTDATA. Esto demuestra que la clave se generó dentro del enclave.
Verifica que la atestación TDX no tenga marcas de depuración activadas. Un enclave de depuración puede inspeccionarse y no debe considerarse confiable para producción.
E2EE requiere una implementación criptográfica cuidadosa. Usa nuestros SDK oficiales en lugar de implementar el protocolo por tu cuenta.

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

La longitud del nonce es incorrecta. Los proveedores de TEE requieren exactamente 32 bytes (64 caracteres hexadecimales).
  • Usa crypto.randomBytes(32).toString('hex') (JS) o secrets.token_hex(32) (Python).
  • Error común: secrets.token_hex(16) produce 32 caracteres hex (16 bytes), no 32 bytes.
  • 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.
  • 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.
  • Todos los mensajes con rol user y system deben 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.
  • 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).
  • Verifica que el ID del modelo es correcto y que el modelo admite E2EE.
  • Usa el endpoint /models para comprobar los modelos E2EE disponibles.

Recursos