Privacy-erweiterte KI mit Trusted Execution Environments und Ende-zu-Ende-Verschlüsselung
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.
Modell läuft in einer hardware-gesicherten Enklave. Venice kann nicht auf die Berechnung zugreifen. Du kannst das per Attestation verifizieren.
E2EE
e2ee-*
Vollständige Ende-zu-Ende-Verschlüsselung. Deine Prompts werden clientseitig verschlüsselt, bevor sie gesendet werden. Nur die TEE kann sie entschlüsseln.
E2EE-Modelle umfassen den TEE-Schutz plus clientseitige Verschlüsselung. TEE-Modelle bieten Enklaven-Sicherheit ohne clientseitige Verschlüsselung.
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.
Ob die Attestation die serverseitige Verifikation bestanden hat
nonce
Deine Nonce, bestätigt Frische
model
Die attestierte Modell-ID
tee_provider
TEE-Provider-Kennung
intel_quote
Roher Intel-TDX-Quote (base64) für clientseitige Verifikation
nvidia_payload
NVIDIA-GPU-Attestation-Daten (falls zutreffend)
signing_key
Öffentlicher Schlüssel zur Verifikation der Response-Signaturen (typischerweise für E2EE-Flows nötig; bei manchen reinen TEE-Modellen kann er fehlen)
signing_address
Aus dem Signing-Key abgeleitete Ethereum-Adresse
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.
TEE-Modelle können ihre Antworten signieren und so beweisen, dass die Ausgabe aus der attestierten Enklave stammt:
# Nach einer Completion die Signatur verifizierencurl "https://api.venice.ai/api/v1/tee/signature?model=tee-qwen3-5-122b-a10b&request_id=chatcmpl-abc123" \ -H "Authorization: Bearer $API_KEY_VENICE"
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.
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.
import crypto from 'crypto'async function fetchAndVerifyAttestation(modelId, apiKey) { // Client-Nonce für Replay-Schutz generieren (32 Bytes = 64 Hex-Zeichen) const clientNonce = crypto.randomBytes(32).toString('hex') const response = await fetch( `https://api.venice.ai/api/v1/tee/attestation?model=${encodeURIComponent(modelId)}&nonce=${clientNonce}`, { headers: { Authorization: `Bearer ${apiKey}` } } ) const attestation = await response.json() // Attestation verifizieren if (attestation.verified !== true) { throw new Error('TEE attestation verification failed on server') } if (attestation.nonce !== clientNonce) { throw new Error('Attestation nonce mismatch - possible replay attack') } // Public Key des Modells für Verschlüsselung holen const modelPublicKey = attestation.signing_key || attestation.signing_public_key if (!modelPublicKey) { throw new Error('No signing key in attestation response') } return { modelPublicKey, signingAddress: attestation.signing_address, attestation, }}
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.
import { gcm } from '@noble/ciphers/aes.js'import { hkdf } from '@noble/hashes/hkdf.js'import { sha256 } from '@noble/hashes/sha2.js'import { ec as EC } from 'elliptic'import crypto from 'crypto'const HKDF_INFO = new TextEncoder().encode('ecdsa_encryption')function encryptMessage(plaintext, modelPublicKeyHex) { const ec = new EC('secp256k1') // Public Key normalisieren (04-Präfix ggf. ergänzen) let normalizedKey = modelPublicKeyHex if (!normalizedKey.startsWith('04') && normalizedKey.length === 128) { normalizedKey = '04' + normalizedKey } const modelPublicKey = ec.keyFromPublic(normalizedKey, 'hex') // Ephemeres Schlüsselpaar für diese Nachricht generieren const ephemeralKeyPair = ec.genKeyPair() // ECDH-Shared-Secret const sharedSecret = ephemeralKeyPair.derive(modelPublicKey.getPublic()) const sharedSecretBytes = new Uint8Array(sharedSecret.toArray('be', 32)) // AES-Key per HKDF ableiten const aesKey = hkdf(sha256, sharedSecretBytes, undefined, HKDF_INFO, 32) // Zufällige Nonce const nonce = crypto.randomBytes(12) // Mit AES-GCM verschlüsseln const cipher = gcm(aesKey, nonce) const encrypted = cipher.encrypt(new TextEncoder().encode(plaintext)) // Ephemeren Public Key holen (unkomprimiert) const ephemeralPublic = new Uint8Array(ephemeralKeyPair.getPublic(false, 'array')) // Kombinieren: ephemeral_public (65 Bytes) + nonce (12 Bytes) + ciphertext const result = new Uint8Array(65 + 12 + encrypted.length) result.set(ephemeralPublic, 0) result.set(nonce, 65) result.set(encrypted, 65 + 12) return Buffer.from(result).toString('hex')}function encryptMessagesForE2EE(messages, modelPublicKey) { return messages.map(msg => { if (msg.role === 'user' || msg.role === 'system') { return { ...msg, content: encryptMessage(msg.content, modelPublicKey), } } return msg })}
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
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
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
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
E2EE erfordert sorgfältige kryptografische Implementierung. Nutze unsere offiziellen SDKs, statt das Protokoll selbst zu implementieren.