Die Privacy-Stufen verstehen
Verfügbare Modelle
TEE-Modelle
TEE-Modelle laufen in hardware-gesicherten Enklaven (Intel TDX, NVIDIA Confidential Computing). Die Modellgewichte und deine Daten sind vor dem Host-System geschützt — einschließlich Venices Infrastruktur.Grundlegende Nutzung
TEE-Modelle funktionieren genau wie reguläre Modelle:TEE-Attestation verifizieren
Du kannst kryptografisch verifizieren, dass ein Modell in einer echten TEE läuft, indem du seinen Attestation-Report abrufst:signing_address und die serverseitigen Verifikationsfelder für Baseline-Attestation-Checks. Ein signing_key wird benötigt, wenn du clientseitige E2EE-Schlüsselverhandlung und strikte Key-Binding-Checks brauchst.Response-Signaturen
TEE-Modelle können ihre Antworten signieren und so beweisen, dass die Ausgabe aus der attestierten Enklave stammt:E2EE-Modelle
E2EE-Modelle fügen dem TEE-Schutz clientseitige Verschlüsselung hinzu. Deine Prompts werden verschlüsselt, bevor sie dein Gerät verlassen, und nur die TEE kann sie entschlüsseln. Venice E2EE verwendet:- ECDH (Elliptic Curve Diffie-Hellman) auf secp256k1 für Schlüsselaustausch
- HKDF-SHA256 für Schlüsselableitung
- AES-256-GCM für symmetrische Verschlüsselung
- TEE-Attestation, um zu verifizieren, dass das Modell in einer sicheren Enklave läuft
Wie E2EE funktioniert
Ephemeren Schlüsselpaar generieren
TEE-Attestation abrufen
/api/v1/tee/attestation an und erhält den Public Key des Modells, Attestation-Evidence und eine Nonce.Attestation verifizieren
Nachrichten verschlüsseln
Request senden
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).TEE-Processing
Response entschlüsseln
Voraussetzungen
JavaScript (Node.js ESM):Schritt 1: E2EE-Support des Modells prüfen
Zuerst über den/models-Endpoint prüfen, ob das Modell E2EE unterstützt.
Schritt 2: Ephemeres Schlüsselpaar generieren
Pro Session ein neues Schlüsselpaar generieren. Der Private Key sollte nur im Memory gehalten und nach Gebrauch sicher genullt werden.Validierungs-Helpers
Verwende diese Helper-Funktionen, um Schlüssel und verschlüsselten Content vor dem Senden zu validieren.Schritt 3: TEE-Attestation abrufen und verifizieren
Die Attestation beweist, dass das Modell in einer echten TEE läuft. Immer die Attestation verifizieren, bevor du dem Public Key des Modells vertraust.Schritt 4: Nachrichten verschlüsseln
User- und System-Nachrichten vor dem Senden verschlüsseln. Nur Nachrichten mit Rolleuser und system müssen verschlüsselt werden.
Schritt 5: Request mit E2EE-Headern senden
Erforderliche Header setzen, um E2EE-Processing zu aktivieren.Schritt 6: Response-Chunks entschlüsseln
Antworten von E2EE-Modellen sind hex-kodierte verschlüsselte Chunks. Entschlüssele jeden Chunk mit deinem Private Key.Vollständiges funktionierendes Beispiel
- JavaScript
- Python
E2EE-Einschränkungen
Sicherheits-Best-Practices
- Pro Session neues Schlüsselpaar — keine ephemeren Keys wiederverwenden
- Private Keys nullen — Private-Key-Bytes nach Gebrauch aus dem Memory löschen
- Attestation verifizieren — immer
verified: trueund Nonce-Match prüfen - Debug-Modus prüfen — Attestations von Debug-Enklaven ablehnen
- Streaming nutzen — E2EE benötigt Streaming für korrektes Chunking
- Fehler sauber behandeln — Decryption-Fehler nicht an Nutzer durchreichen
- 32-Byte-Nonces nutzen — TEE-Provider verlangen genau 32 Bytes
Best Practices
In der Produktion immer Attestation verifizieren
In der Produktion immer Attestation verifizieren
verified: true. Parse den Intel-TDX-Quote clientseitig und prüfe, dass die Messungen den erwarteten Werten entsprechen. Für NVIDIA-GPUs die Attestation über NVIDIAs Verifikationsdienst prüfen.Frische Nonces verwenden
Frische Nonces verwenden
Key-Binding prüfen
Key-Binding prüfen
REPORTDATA-Feld gebunden sein. Das beweist, dass der Schlüssel innerhalb der Enklave erzeugt wurde.Debug-Modus prüfen
Debug-Modus prüfen
Für E2EE unsere SDKs nutzen
Für E2EE unsere SDKs nutzen
Modell-Fähigkeiten prüfen
Du kannst über den Models-Endpoint prüfen, ob ein Modell TEE oder E2EE unterstützt:Fehlerbehandlung
Fehlerbehebung
502 Bad Gateway oder 'Nonce must be exactly 32 bytes'
502 Bad Gateway oder 'Nonce must be exactly 32 bytes'
crypto.randomBytes(32).toString('hex')(JS) odersecrets.token_hex(32)(Python) verwenden- Häufiger Fehler:
secrets.token_hex(16)erzeugt 32 Hex-Zeichen (16 Bytes), nicht 32 Bytes
Attestation-Verifikation fehlgeschlagen
Attestation-Verifikation fehlgeschlagen
- Prüfen, ob das Modell E2EE unterstützt (
supportsE2EE: true) - API-Schlüssel-Gültigkeit und Zugriff auf das angeforderte Modell verifizieren
- Netzwerkverbindung zur Venice-API prüfen
Decryption fehlgeschlagen
Decryption fehlgeschlagen
- Sicherstellen, dass derselbe Private Key verwendet wird, der den in den Headern gesendeten Public Key erzeugt hat
- Prüfen, dass der Response-Content tatsächlich hex-kodiert ist (E2EE aktiv)
- Verifizieren, dass der Model-Public-Key dem für die Verschlüsselung verwendeten entspricht
Encrypted field is not valid hex
Encrypted field is not valid hex
- Alle
user- undsystem-Nachrichten müssen verschlüsselt sein, wenn E2EE-Header vorhanden sind - Sicherstellen, dass der verschlüsselte Content die
isValidEncrypted()-Validierung passiert (mindestens 186 Hex-Zeichen) - Prüfen, dass die Verschlüsselungs-Ausgabe lowercase-Hex ohne Präfixe ist
Invalid public key-Fehler
Invalid public key-Fehler
- Client-Public-Key muss exakt 130 Hex-Zeichen sein und mit
04beginnen - Das Helper-
validateClientPubkey()vor dem Senden zur Formatprüfung verwenden - Sicherstellen, dass unkomprimiertes Public-Key-Format verwendet wird (65 Bytes = 130 Hex-Zeichen)
Model not found
Model not found
- Modell-ID prüfen und sicherstellen, dass das Modell E2EE unterstützt
/models-Endpoint nutzen, um verfügbare E2EE-Modelle zu verifizieren