증명이 입증하는 것과 입증하지 못하는 것

“엔클레이브까지 암호화”는 일련의 확인 과정을 짧게 줄인 말입니다. 그 사슬의 고리 하나하나는 알아 둘 가치가 있습니다. 고리마다 기대는 대상이 다르기 때문입니다. 프로세서 제조사의 키, 공개된 릴리스, 헤더, 또는 저희가 제공하는 코드가 그것입니다. 이 노트에서는 그 사슬을 순서대로 따라가며 어디에서 끝나는지 짚어 봅니다.

확인 순서

워크스페이스가 메시지를 보내기 전에, 브라우저는 저희 릴레이를 통해 엔클레이브의 증명 번들을 가져와 탭 안에서 Tinfoil의 검증 도구로 검증합니다. 번들에는 프로세서 제조사에 뿌리를 둔 키로 서명된 하드웨어 보고서(라우터의 경우 AMD SEV-SNP), 엔클레이브가 부팅한 코드의 측정값, 그리고 엔클레이브가 복호화에 사용할 공개 키가 들어 있습니다.

• 보고서의 서명은 그 보고서가 진짜 엔클레이브 하드웨어에서 나왔음을 보여 줍니다.
• 측정값을 서명되어 공개된 라우터 코드의 릴리스와 대조하므로, 브라우저는 어떤 코드가 실행 중인지 알 수 있습니다.
• 보고서에 담긴 키가 바로 메시지가 탭을 떠나기 전에 HPKE로 암호화되는 대상 키입니다.

릴레이는 이 공개 번들을 1분 동안 캐시합니다. 검증은 브라우저가 하므로, 저희 서버를 거친다고 해서 확인이 약해지지는 않습니다. 변경된 번들은 확인을 통과하지 못하며, 그러면 아무것도 전송되지 않습니다.

확인을 통과하면 알 수 있는 것

그 주소의 엔클레이브가 공개된 그 릴리스를 실행하는 실제 하드웨어이며, 메시지를 봉인한 키를 그 엔클레이브가 가지고 있다는 사실입니다. 하드웨어의 보호가 유지되는 한, 메시지는 그 코드 안에서만 열 수 있습니다. 저희 릴레이와 호스팅 업체, 그리고 그 사이의 네트워크가 보는 것은 암호문입니다.

확인이 멈추는 곳

브라우저가 검증하는 엔클레이브는 Tinfoil의 모델 라우터입니다. 라우터의 공개된 코드는 요청을 복호화한 뒤, 모델 자체 엔클레이브의 증명된 키에 묶인 TLS 연결을 통해 그 엔클레이브로 전달합니다. 브라우저는 이 구간을 직접 확인할 수 없으며, 이 구간은 라우터의 공개된 코드에 기대고 있습니다.

워크스페이스는 모델의 엔클레이브도 확인하려고 시도하며, 그 결과를 각 답변의 영수증에 기록합니다. 다만 현재로서는 이 확인을 브라우저에서 끝내지 못하는 경우가 많습니다. Tinfoil의 브라우저 검증 도구는 AMD SEV-SNP 보고서만 읽을 수 있는데, Kimi K3, GPT-OSS 120B, DeepSeek V4.1 Flash와 대부분의 Gemma 4 31B 엔클레이브는 Intel TDX에서 실행되므로, 이들의 영수증에는 아직 브라우저에서 확인할 수 없다고 표시됩니다. GLM-5.3의 엔클레이브를 비롯한 일부 SEV-SNP 엔클레이브는 검증 도구가 아직 받아들이지 않는 프로세서 버전을 보고하므로 확인되지 않음으로 표시됩니다. 어느 쪽도 엔클레이브에 문제가 있다는 뜻은 아닙니다. 브라우저가 그것이 올바르다는 것을 보여 주지 못했다는 뜻입니다. 이 내용은 2026년 10월 28일 기준입니다.

확인으로 다룰 수 없는 두 가지

• 검증하는 코드는 저희가 제공합니다. 저희가 거짓 결과를 내는 검증 도구를 제공한다면 확인은 통과할 것입니다. 그래서 /verify는 브라우저가 불러온 코드를 빌드의 공개 매니페스트와 비교하며, 빌드는 바이트 단위까지 똑같이 재현할 수 있습니다.
• 증명은 제조사의 서명 키, 그리고 엔클레이브 하드웨어가 설계대로 작동한다는 전제에 기대고 있습니다. 둘 중 어느 쪽에 결함이 있더라도 증명으로는 알 수 없습니다.

직접 확인하기

검증 방식은 사슬 전체를 그림으로 보여 줍니다. 직접 봉인해 보기는 아무것도 보내지 않고 브라우저에서 봉인 단계를 실행합니다. 이 페이지 검증하기는 불러온 코드의 해시를 계산하며, 해독에 도전하세요 페이지에는 저희 릴레이가 본 그대로의 암호화된 요청 하나가 공개되어 있습니다.