Zum Hauptinhalt springen
Venice bietet Privacy-erweiterte Modelle, die in Trusted Execution Environments (TEE) laufen und Ende-zu-Ende-Verschlüsselung (E2EE) unterstützen. Diese Modelle liefern kryptografische Garantien, dass deine Daten privat bleiben — selbst gegenüber Venice.

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:
Die Attestation-Antwort enthält:
In der Produktion die Attestation clientseitig verifizieren, indem du den Intel-TDX-Quote parst und die NVIDIA-Attestation prüfst.
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
E2EE erfordert eine clientseitige Implementierung. Die Beispiele unten zeigen das vollständige Protokoll.

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):
Python:

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 Rolle user und system müssen verschlüsselt werden.
Wenn E2EE-Header gesetzt sind, müssen alle Nachrichten mit Rolle user und system verschlüsselt sein. Sendet du in diesen Rollen Klartext, gibt es einen „Encrypted field is not valid hex”-Fehler.

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

E2EE-Einschränkungen

E2EE hat einige Einschränkungen aufgrund der Verschlüsselungsanforderungen:

Sicherheits-Best-Practices

  1. Pro Session neues Schlüsselpaar — keine ephemeren Keys wiederverwenden
  2. Private Keys nullen — Private-Key-Bytes nach Gebrauch aus dem Memory löschen
  3. Attestation verifizieren — immer verified: true und Nonce-Match prüfen
  4. Debug-Modus prüfen — Attestations von Debug-Enklaven ablehnen
  5. Streaming nutzen — E2EE benötigt Streaming für korrektes Chunking
  6. Fehler sauber behandeln — Decryption-Fehler nicht an Nutzer durchreichen
  7. 32-Byte-Nonces nutzen — TEE-Provider verlangen genau 32 Bytes

Best Practices

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.
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.
Der Signing-Key sollte an das TDX-REPORTDATA-Feld gebunden sein. Das beweist, dass der Schlüssel innerhalb der Enklave erzeugt wurde.
Sicherstellen, dass die TDX-Attestation keine Debug-Flags gesetzt hat. Eine Debug-Enklave kann inspiziert werden und sollte in der Produktion nicht vertraut werden.
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

Die Nonce-Länge ist falsch. TEE-Provider verlangen exakt 32 Bytes (64 Hex-Zeichen).
  • crypto.randomBytes(32).toString('hex') (JS) oder secrets.token_hex(32) (Python) verwenden
  • Häufiger Fehler: secrets.token_hex(16) erzeugt 32 Hex-Zeichen (16 Bytes), nicht 32 Bytes
  • 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
  • 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
  • Alle user- und system-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
  • Client-Public-Key muss exakt 130 Hex-Zeichen sein und mit 04 beginnen
  • Das Helper-validateClientPubkey() vor dem Senden zur Formatprüfung verwenden
  • Sicherstellen, dass unkomprimiertes Public-Key-Format verwendet wird (65 Bytes = 130 Hex-Zeichen)
  • Modell-ID prüfen und sicherstellen, dass das Modell E2EE unterstützt
  • /models-Endpoint nutzen, um verfügbare E2EE-Modelle zu verifizieren

Ressourcen