明文始終留在 TEE 記憶體
TLS 在閘道 TEE 內終止。每個請求都會以供應商安全隔離區的金鑰密封，因此路由只承載密文，絕不持有金鑰。
簡短答案
營運者無法讀取安全隔離區記憶體
金鑰在安全隔離區記憶體中建立並保存。無論是雲端服務商還是 0G 營運者，都無法檢視金鑰、提示詞或解密後的回應。
兩個 TEE 皆可檢驗
閘道與供應商 TEE 會發布經硬體簽署的度量值與發行版建置，讓任何人都能確切驗證正在執行的程式碼。
你的提示詞會送到哪裡
路由會轉發每個請求並計費，但絕不會取得開啟密封內容所需的金鑰。
密文 · TLS
你的瀏覽器
標準 HTTPS 工作階段在閘道 TEE 內終止。
明文 · 記憶體
閘道 TEE
請求會以已驗證供應商安全隔離區的金鑰密封。
密文 · HPKE
0G 路由
以不透明方式轉發密封內容，且絕不持有解密金鑰。
明文 · 記憶體
供應商 TEE
模型在解密請求的同一個已認證安全隔離區內執行。
密文 · 已簽章
回應
回傳內容以安全隔離區簽章密封，路由無法偽造該簽章。
回應之後，閘道會取得供應商的簽章，且不包含提示詞內容。提示詞絕不會儲存在日誌、備份或磁碟中。
為何「在 TEE 內」是可檢查的
TLS 金鑰在內部產生
入口會在機密虛擬機器內建立其私密金鑰，並將所提供的憑證提交至 Intel TDX 證明引用中。比對兩者即可證明 TLS 是在安全區內終止的。
Intel 簽署執行中建置的雜湊
該證明引用綁定部署清單，而清單以摘要鎖定每個容器。任何程式碼變更都會產生不同的硬體簽署度量值，任何人都可以與已發布的版本進行比對。
供應商會先經過驗證
閘道會以 DCAP 驗證供應商的證明引用，並從該已驗證的證據中讀取供應商的加密金鑰，而非從路由取得。未經驗證的供應商與未簽署的回應都會被拒絕。
自行檢查
建置驗證器，並針對一個閘道網域執行單一指令。它會驗證 Intel 的證明引用、提供給您連線的憑證、程式碼雜湊，以及其發布的版本。
$cd 0g-pc-e2ee/client && go build -o pcverify ./cmd/pcverify
$./pcverify -gateway <gateway-domain>
仍可看見的資訊
加密內文無法隱藏所有周邊後設資料。路由可以讀取這些欄位並據以計費，但安全區的簽章可防止它竄改這些欄位。
- 您請求的模型，因為路由必須將其轉送。
- 您精確的詞元使用量，因為路由會依此計費。
- 訊息大小；密文會保留明文長度再加上一個常數。
- 請求與回應的時間，包括串流區塊的時間。
這無法證明的事
- 這是偵測，而非預防。不誠實的部署只有在有人執行驗證時，才會被公開偵測到。
- 一次通過只涵蓋被檢查的連線，並非自動涵蓋同一網域下的所有安全區。
- 這是可驗證的中繼，而非可驗證的計算。它證明哪個安全區產生了回應，而不是模型的品質或行為。
- 可用性未經證明；部署仍可被下線。
- 託管閘道增加了第二個能看到明文的安全區。用戶端密封目前還不是受支援的進入點。