Die Privacy-Stufen verstehen
E2EE-Modelle umfassen den TEE-Schutz plus clientseitige Verschlüsselung. TEE-Modelle bieten Enklaven-Sicherheit ohne clientseitige Verschlüsselung.
Verfügbare Modelle
Loading…
Die vollständige Liste mit Preisen und Kontext-Limits findest du auf der Modelle-Seite.
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:Für die Verifikation reiner TEE-Modelle reichen
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
1
Ephemeren Schlüsselpaar generieren
Der Client erzeugt ein secp256k1-Schlüsselpaar für diese Session.
2
TEE-Attestation abrufen
Der Client fragt
/api/v1/tee/attestation an und erhält den Public Key des Modells, Attestation-Evidence und eine Nonce.3
Attestation verifizieren
Der Client prüft Nonce-Übereinstimmung, deaktivierten Debug-Modus und Attestation-Gültigkeit.
4
Nachrichten verschlüsseln
Der Client verschlüsselt die Prompts mittels ECDH-Shared-Secret → HKDF → AES-GCM.
5
Request senden
Der Client sendet den Request mit E2EE-Headern (
X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo).6
TEE-Processing
Die TEE entschlüsselt den Request, verarbeitet ihn und verschlüsselt die Antwort.
7
Response entschlüsseln
Der Client erhält verschlüsselte Chunks und entschlüsselt sie mit dem Private Key.
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.Wichtig: Nonce-Länge — Die Client-Nonce muss 32 Bytes (64 Hex-Zeichen) lang sein. Manche TEE-Provider verlangen exakt 32 Bytes und lehnen kürzere Nonces ab.
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
Verlasse dich nicht nur auf das
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
Für jede Attestation-Anfrage eine neue zufällige Nonce erzeugen. Das verhindert Replay-Angriffe, bei denen ein Angreifer eine veraltete Attestation ausliefern könnte.
Key-Binding prüfen
Key-Binding prüfen
Der Signing-Key sollte an das TDX-
REPORTDATA-Feld gebunden sein. Das beweist, dass der Schlüssel innerhalb der Enklave erzeugt wurde.Debug-Modus prüfen
Debug-Modus prüfen
Sicherstellen, dass die TDX-Attestation keine Debug-Flags gesetzt hat. Eine Debug-Enklave kann inspiziert werden und sollte in der Produktion nicht vertraut werden.
Für E2EE unsere SDKs nutzen
Für E2EE unsere SDKs nutzen
E2EE erfordert sorgfältige kryptografische Implementierung. Nutze unsere offiziellen SDKs, statt das Protokoll selbst zu implementieren.
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'
Die Nonce-Länge ist falsch. TEE-Provider verlangen exakt 32 Bytes (64 Hex-Zeichen).
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