アテステーションが証明するもの、しないもの

「エンクレーブまで暗号化」は、一連の確認を短く言い表した言葉です。その一つひとつの環は知っておく価値があります。それぞれが別のものに依拠しているからです。プロセッサのベンダーの鍵、公開されたリリース、ヘッダー、あるいは私たちが配信するコードです。このノートでは、その連鎖を順にたどり、どこで終わるかを示します。

確認の順序

ワークスペースがメッセージを送る前に、ブラウザは私たちのリレーを通じてエンクレーブのアテステーションバンドルを取得し、タブの中で 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 日時点の結果です。

確認では扱えない 2 つのこと

• 検証するコードは私たちが配信しています。私たちが偽りの結果を返す検証ツールを配信すれば、確認は通ってしまいます。だからこそ /verify は、ブラウザが読み込んだコードをビルドの公開マニフェストと比較し、ビルドはバイト単位で再現できるようになっています。
• アテステーションは、ベンダーの署名鍵と、エンクレーブのハードウェアが設計どおりに動くことに依拠しています。そのどちらかにある欠陥については何もわかりません。

自分で確認する

検証の仕組みでは、連鎖の全体を図で示しています。自分で封印するでは、何も送らずにブラウザで封印の手順を実行します。このページを検証は読み込んだコードのハッシュを計算し、解読に挑戦では、リレーから見えたとおりの暗号化されたリクエストを 1 件公開しています。