독립 검증

왜 프라이빗한가

0G가 프라이빗 컴퓨팅 프롬프트를 읽을 수 없는 이유와, 직접 검증하는 방법.

간략한 버전입니다. 절차는 verifying-the-gateway.md이며, 설계는 design/ 아래에 있습니다.

간단한 답변

TLS는 게이트웨이 TEE 내부에서 종료됩니다. 각 요청은 제공자 엔클레이브의 키로 봉인되므로, 라우터는 암호문만 운반하며 키를 보관하지 않습니다.

키는 엔클레이브 메모리 내부에서 생성되고 보관됩니다. 클라우드 호스트도 0G 운영자도 키, 프롬프트, 복호화된 응답을 열람할 수 없습니다.

게이트웨이와 제공자의 TEE는 하드웨어 서명 측정값과 릴리스 빌드를 공개하므로, 누구나 실제로 실행 중인 코드를 정확히 검증할 수 있습니다.

라우터는 모든 요청을 전달하고 청구하지만, 봉인된 본문을 여는 데 필요한 키는 절대 받지 않습니다.

암호문 · TLS

사용자 브라우저

게이트웨이 TEE 내부에서 종료되는 표준 HTTPS 세션.

평문 · 메모리

게이트웨이 TEE

요청은 검증된 제공자 엔클레이브의 키로 봉인됩니다.

암호문 · HPKE

0G 라우터

봉인된 본문을 내용을 알 수 없는 채로 전달하며, 복호화 키는 절대 보관하지 않습니다.

평문 · 메모리

제공자 TEE

모델은 요청을 복호화하는 동일한 증명된 엔클레이브 내에서 실행됩니다.

암호문 · 서명

응답

라우터가 위조할 수 없는 엔클레이브 서명으로 봉인되어 반환됩니다.

응답 후 게이트웨이는 프롬프트 내용 없이 제공자의 서명을 가져옵니다. 프롬프트는 로그, 백업 또는 디스크에 저장되지 않습니다.

인그레스는 기밀 VM 내부에서 개인 키를 생성하고 제공된 인증서를 Intel TDX 증명 명세에 커밋합니다. 이 둘을 대조하면 TLS가 엔클레이브 내부에서 종료되었음이 입증됩니다.

쿼트는 배포 매니페스트에 바인딩됩니다. 매니페스트는 모든 컨테이너를 다이제스트로 고정하므로, 코드가 변경되면 하드웨어 서명된 측정값이 달라집니다. 누구나 이 측정값을 공개 릴리스와 비교할 수 있습니다.

게이트웨이는 제공자 쿼트를 DCAP으로 검증하고, 암호화 키를 라우터가 아닌 해당 검증된 증거에서 읽습니다. 검증되지 않은 제공자와 서명되지 않은 응답은 거부됩니다.

검증기를 빌드하고 게이트웨이 도메인을 대상으로 한 가지 명령을 실행하세요. 이 명령은 Intel의 쿼트, 사용자 연결에 제공된 인증서, 코드 해시 및 게시된 릴리스를 검증합니다.

$cd 0g-pc-e2ee/client && go build -o pcverify ./cmd/pcverify

$./pcverify -gateway <gateway-domain>

본문을 암호화해도 주변 메타데이터가 모두 숨겨지지는 않습니다. 라우터는 이 필드들을 읽고 과금할 수 있지만, 엔클레이브 서명 때문에 이를 변경할 수는 없습니다.

탐지일 뿐 예방이 아닙니다. 부정한 배포는 누군가 검증을 실행해야만 공개적으로 탐지될 수 있습니다.
통과는 검사된 연결에만 적용되며, 같은 도메인 뒤의 모든 엔클레이브에 자동으로 적용되지는 않습니다.
이것은 검증 가능한 릴레이이지 검증 가능한 연산이 아닙니다. 어떤 엔클레이브가 응답을 생성했는지는 증명하지만, 모델의 품질이나 동작을 증명하지는 않습니다.
가용성은 증명되지 않습니다. 배포는 여전히 오프라인으로 전환될 수 있습니다.
호스팅 게이트웨이는 평문을 볼 수 있는 두 번째 엔클레이브를 추가합니다. 클라이언트 측 봉인은 아직 지원되는 진입점이 아닙니다.