메인 콘텐츠로 건너뛰기
Venice는 Trusted Execution Environment(TEE)에서 실행되고 End-to-End Encryption(E2EE)을 지원하는 프라이버시 강화 모델을 제공합니다. 이 모델들은 사용자의 데이터가—Venice조차도 접근할 수 없도록—프라이빗하게 유지된다는 암호학적 보증을 제공합니다.

프라이버시 레벨 이해

E2EE 모델은 TEE 보호와 더불어 클라이언트 측 암호화를 포함합니다. TEE 모델은 클라이언트 측 암호화 없이도 enclave 수준의 보안을 제공합니다.

사용 가능한 모델

Loading…
가격 및 context 한도가 포함된 전체 목록은 Models 페이지를 확인하세요.

TEE 모델

TEE 모델은 하드웨어로 보호된 enclave(Intel TDX, NVIDIA Confidential Computing) 안에서 실행됩니다. 모델 가중치와 사용자 데이터는—Venice 인프라를 포함한—호스트 시스템으로부터 보호됩니다.

기본 사용법

TEE 모델은 일반 모델과 동일하게 동작합니다:

TEE Attestation 검증하기

attestation 보고서를 가져와 모델이 진짜 TEE에서 실행되는지 암호학적으로 검증할 수 있습니다:
attestation 응답에는 다음이 포함됩니다:
프로덕션에서는 Intel TDX quote를 파싱하고 NVIDIA attestation을 확인해 클라이언트 측에서 attestation을 검증하세요.
일반 TEE 모델 검증의 경우, 기본 attestation 점검에는 signing_address와 서버 측 검증 필드만으로도 충분합니다. 클라이언트 측 E2EE 키 합의 및 엄격한 키 바인딩 점검이 필요한 경우에는 signing_key가 필요합니다.

응답 서명

TEE 모델은 응답에 서명할 수 있으며, 이를 통해 결과가 검증된 enclave에서 왔음을 증명할 수 있습니다:

E2EE 모델

E2EE 모델은 TEE 보호 위에 클라이언트 측 암호화를 더합니다. prompt는 사용자의 기기를 떠나기 전에 암호화되며, TEE만 이를 복호화할 수 있습니다. Venice E2EE는 다음을 사용합니다:
  • 키 교환을 위한 secp256k1 위 ECDH(Elliptic Curve Diffie-Hellman)
  • 키 파생을 위한 HKDF-SHA256
  • 대칭 암호화를 위한 AES-256-GCM
  • 모델이 안전한 enclave에서 실행됨을 검증하는 TEE attestation
E2EE는 클라이언트 측 구현이 필요합니다. 아래 예시는 전체 프로토콜을 보여줍니다.

E2EE 동작 방식

1

임시 키 쌍 생성

클라이언트가 세션용 secp256k1 키 쌍을 생성합니다.
2

TEE Attestation 가져오기

클라이언트가 /api/v1/tee/attestation을 요청해 모델의 공개 키, attestation 증거, nonce를 받습니다.
3

Attestation 검증

클라이언트가 nonce 일치, 디버그 모드 비활성화, attestation 유효성을 확인합니다.
4

메시지 암호화

클라이언트가 ECDH 공유 비밀 → HKDF → AES-GCM 순으로 prompt를 암호화합니다.
5

요청 전송

클라이언트가 E2EE 헤더(X-Venice-TEE-Client-Pub-Key, X-Venice-TEE-Model-Pub-Key, X-Venice-TEE-Signing-Algo)와 함께 요청을 전송합니다.
6

TEE 처리

TEE가 요청을 복호화하고, 처리한 뒤 응답을 암호화합니다.
7

응답 복호화

클라이언트가 암호화된 청크를 받아 private key로 복호화합니다.

사전 요구사항

JavaScript (Node.js ESM):
Python:

1단계: 모델 E2EE 지원 확인

먼저 /models endpoint를 확인해 모델이 E2EE를 지원하는지 확인하세요.

2단계: 임시 키 쌍 생성

각 세션마다 새 키 쌍을 생성합니다. private key는 메모리에만 보관하고 사용 후 안전하게 0으로 채워야 합니다.

검증 헬퍼

요청을 보내기 전에 키와 암호화된 콘텐츠를 검증하려면 다음 헬퍼 함수를 사용하세요.

3단계: TEE Attestation 가져오기 및 검증

attestation은 모델이 진짜 TEE에서 실행되고 있음을 증명합니다. 모델의 공개 키를 신뢰하기 전에 항상 attestation을 검증하세요.
중요: Nonce 길이 — 클라이언트 nonce는 32바이트(64 hex 문자) 여야 합니다. 일부 TEE 공급자는 정확히 32바이트를 요구하며 더 짧은 nonce는 거부합니다.

4단계: 메시지 암호화

전송 전에 user 및 system 메시지를 암호화합니다. usersystem 역할 메시지만 암호화하면 됩니다.
E2EE 헤더가 있는 경우, 모든 usersystem 역할 메시지는 암호화되어야 합니다. 이 역할에 평문 콘텐츠를 보내면 “Encrypted field is not valid hex” 에러가 발생합니다.

5단계: E2EE 헤더와 함께 요청 전송

E2EE 처리를 활성화하려면 필수 헤더를 포함하세요.

6단계: 응답 청크 복호화

E2EE 모델의 응답은 hex 인코딩된 암호화 청크입니다. 각 청크를 private key로 복호화하세요.

완전한 동작 예시

E2EE 제한 사항

암호화 요건으로 인해 E2EE에는 몇 가지 제약이 있습니다:

보안 모범 사례

  1. 세션마다 새 키 쌍을 생성하세요 - 임시 키를 재사용하지 마세요
  2. Private key를 0으로 채우세요 - 사용 후 메모리에서 private key 바이트를 지우세요
  3. Attestation을 검증하세요 - 항상 verified: true와 nonce 일치를 확인하세요
  4. 디버그 모드 확인 - 디버그 enclave에서 온 attestation은 거부하세요
  5. 스트리밍 사용 - E2EE는 적절한 암호화 청킹을 위해 스트리밍이 필요합니다
  6. 에러를 우아하게 처리 - 사용자에게 복호화 에러를 노출하지 마세요
  7. 32바이트 nonce 사용 - TEE 공급자는 정확히 32바이트를 요구합니다

모범 사례

verified: true 응답만 믿지 마세요. Intel TDX quote를 클라이언트 측에서 파싱하고 측정값이 기대값과 일치하는지 검증하세요. NVIDIA GPU의 경우 NVIDIA 검증 서비스를 통해 attestation을 확인하세요.
매 attestation 요청마다 새 무작위 nonce를 생성하세요. 이로써 공격자가 오래된 attestation을 제공하는 재전송 공격을 방지할 수 있습니다.
signing key는 TDX REPORTDATA 필드에 바인딩되어야 합니다. 이는 키가 enclave 내부에서 생성되었음을 증명합니다.
TDX attestation에 디버그 플래그가 설정되어 있지 않은지 확인하세요. 디버그 enclave는 검사가 가능하므로 프로덕션에서는 신뢰해서는 안 됩니다.
E2EE는 신중한 암호 구현이 필요합니다. 직접 프로토콜을 구현하기보다 공식 SDK를 사용하세요.

모델 기능 확인

다음과 같이 models endpoint를 통해 모델이 TEE 또는 E2EE를 지원하는지 확인할 수 있습니다:

에러 처리

문제 해결

nonce 길이가 잘못되었습니다. TEE 공급자는 정확히 32바이트(64 hex 문자) 를 요구합니다.
  • crypto.randomBytes(32).toString('hex') (JS) 또는 secrets.token_hex(32) (Python) 사용
  • 흔한 실수: secrets.token_hex(16)은 32 hex 문자(16바이트)를 생성하며 32바이트가 아닙니다
  • 모델이 E2EE를 지원하는지 확인 (supportsE2EE: true)
  • API 키가 유효하고 요청한 모델에 접근 권한이 있는지 확인
  • Venice API와의 네트워크 연결 확인
  • 헤더로 전송한 공개 키를 생성한 동일한 private key를 사용하고 있는지 확인
  • 응답 콘텐츠가 실제로 hex 인코딩되어 있는지 확인(E2EE 활성)
  • 모델 공개 키가 암호화에 사용된 것과 일치하는지 확인
  • E2EE 헤더가 있을 때 모든 usersystem 역할 메시지는 암호화되어야 합니다
  • 암호화된 콘텐츠가 isValidEncrypted() 검증을 통과하는지 확인(최소 186 hex 문자)
  • 암호화 결과가 prefix 없는 소문자 hex인지 확인
  • 클라이언트 공개 키는 04로 시작하는 정확히 130 hex 문자 여야 합니다
  • 전송 전에 validateClientPubkey() 헬퍼로 포맷을 확인
  • 비압축 공개 키 포맷(65바이트 = 130 hex 문자) 사용 확인
  • 모델 ID가 정확하고 모델이 E2EE를 지원하는지 확인
  • /models endpoint로 사용 가능한 E2EE 모델을 확인

리소스