ブラウザで確認。
エンクレーブへ封印。

要点

Undergrove は、Tinfoil が運用するハードウェアエンクレーブの中でオープンウェイトモデルを動かしています。その意味するところのうち、一部はブラウザ自身が確認し、一部は Tinfoil の表明であり、一部は私たちに依存します。それぞれを以下に分けて示します。

これらはいずれも、まだ第三者による評価を受けていません。

01 · アテステーション

チップがコードを保証します。

ハードウェアエンクレーブとは、サーバーの中で、そのホスト自身も中をのぞけない部分です。プロセッサがエンクレーブのメモリを暗号化し、ホストのソフトウェアを締め出します。それだけでは約束にすぎません。確認できるものにするのがアテステーションです。エンクレーブの起動時に、プロセッサは読み込んだコードを測定し、その測定値のレポートに、チップメーカーが保証する鍵で署名します。レポートには、エンクレーブが復号に使う公開鍵も記されています。

最初のメッセージの前に、ワークスペースは Tinfoil のルーターエンクレーブのレポートを私たちのサーバー経由で取得し、Tinfoil のオープンソースの検証ツールをブラウザ上で実行します。私たちを経由しても何も変わりません。私たちはチップの署名を偽造できず、検証に通らないレポートはすべてを止めます。

検証ツールのチェック(実行順)

1. このコードについて Tinfoil が公開したリリースを見つける。
2. エンクレーブのハードウェアアテステーションレポートを、チップメーカーの署名鍵で確認する。
3. リリースの署名付きビルド記録を確認する(GitHub からの Sigstore)。
4. 比較する:エンクレーブで測定されたコードが、そのリリースと完全に同じであること。
5. 暗号化の鍵が、エンクレーブのアテステーションが示す鍵であることを確認する。

私たちはチップの署名を偽造できず、検証に通らないレポートはすべてを止めます。

検証済みのレポートは、このタブまたはこのサイトの別のタブで最大 10 分間再利用されます。ただし SHA-256 で同一と確認できた場合に限ります。ワークスペースは各チェックを「検証済み」に表示し、アーキテクチャのページではそれを実行するコードを確認できます。

02 · 封印

開けられるのはエンクレーブだけです。

エンクレーブの検証が済むと、ライブのリクエストはすべて、タブを出る前に封印されます。本文は、Tinfoil の HTTP 本文暗号化プロトコルである EHBP で、アテステーションが示した鍵に向けて暗号化されます。EHBP が使う HPKE は、相手の公開鍵に向けて暗号化するための標準です。タブはリクエストごとに新しい鍵ペアを作り、エンクレーブの鍵と組み合わせて共有秘密を導き、AES-256-GCM で暗号化します。

新しい鍵ペアの公開側は、カプセル化された鍵として暗号文と一緒に送られます。それを秘密に戻せるのは、エンクレーブから決して出ないエンクレーブの秘密鍵だけです。回答も同じように、封印されたフレームで戻り、届くそばからタブで開かれます。

03 · リレー

読めないバイト列。

封印されたリクエストは、Tinfoil に直接ではなく、Vercel 上の関数である私たちのリレーに届きます。リレーは誰からのリクエストか、利用枠の範囲内かを確認し、Undergrove の Tinfoil 鍵をリクエストに付けます。そのため Tinfoil のアカウントは不要です。Tinfoil 自身のホスト宛てでないもの、カプセル化された鍵のないものは拒否します。

リレーは単語を数えられないため、各リクエストの費用を暗号文のサイズから多めに見積もります。コピーは残さず、ログにはルート名、ステータスコード、所要時間だけが記録されます。

04 · レシート

2 つのエンクレーブと、回答ごとのレシート。

ブラウザが検証したルーターエンクレーブは、モデルを実行しません。リクエストを開き、モデルが GPU とともに動くエンクレーブへ渡します。ルーターはそのエンクレーブを公開コードに従って自ら検証し、レスポンスヘッダーで名前を示します。

続いてブラウザは、その名前のエンクレーブも同じ検証ツールで、Tinfoil のルーターがそのモデルに固定しているリポジトリと照らして確認します。結果はレシートとして回答と一緒に保存されます。エンクレーブ、その中で測定されたコード、一致したリリース、リクエストを封印した鍵です。レシートはブラウザ自身の記録で、私たちも Tinfoil も署名していません。その根拠となるアテステーションには AMD と GitHub が署名しているため、誰でも確認し直せます。

05 · 開発者向け API

別の経路を、率直に。

開発者向け API を呼び出すコードは、リクエストを HTTPS で私たちのゲートウェイに送り、ゲートウェイはそれを読みます。確認し、制限を適用し、ツールを実行するためです。読むのはメモリ上だけで、保存もログ記録もしません。その後ゲートウェイは、ワークスペースでブラウザが行うのと同じことをします。Tinfoil の SDK でエンクレーブを検証し、リクエストを封印します。

つまりこの経路では、ゲートウェイがリクエストを持っている間、私たちを信頼していただくことになります。それでも確認できるのはエンクレーブです。Tinfoil のルートからの回答には、ゲートウェイが検証したアテステーションバンドルを示すヘッダーが付いており、ご自身で検証し直せます。方法は開発者向けドキュメントにあります。

06 · このページ

確認するコードを確認する。

ここまでのすべては、このサイトがブラウザに送るコードの中で動いています。だからそのコードも重要です。ビルドごとにマニフェストが作られます。サイトが配信するすべてのファイルの SHA-256 と、ビルド元のコミットです。

ページは自分自身を完全には保証できません。ページの中で動くチェックは、そのページと同じだけしか信頼できません。より強い確認には私たちは一切関わりません。指定の環境でご自身でコミットをビルドし、マニフェストを比べてください。

07 · 限界

これで証明できないこと。

• Tinfoil の表明は Tinfoil のものです。 Tinfoil がエンクレーブにアクセスできないこと、中身が再起動をまたいで残らないこと、GPU がコンフィデンシャルコンピューティングモードで動作することは、Tinfoil の表明です。ブラウザが確認するのは、ハードウェアが本物で、公開されたコードを実行していることです。
• ハードウェアも信頼の一部です。 保護の強さは、プロセッサとそのファームウェア、チップメーカーの鍵に左右されます。ハードウェアエンクレーブには、これまでにも脆弱性が公表されています。
• 一区間は公開コードに依拠しています。 リクエストがルーターからモデルのエンクレーブへ渡ったことは、ルーターの公開コードに依拠しています。ブラウザがモデルのエンクレーブを確認できるのは AMD SEV-SNP の場合だけで、Intel TDX では未確認として記録されます。
• リレーには外側が見えます。 アカウント、IP アドレス、サイズ、時刻、どのモデルが回答したか。
• 公開されていることは、レビュー済みであることとは違います。 検証ツールが示すのはどのコードが動いているかであって、そのコードに欠陥がないことではありません。
• 第三者評価はまだありません。 この設計とそのコードは、これまでどの監査人のレビューも受けていません。

誰に何が見えうるかを観察者ごとに知るには、脅威モデルをお読みください。

08 · さらに詳しく

各部分が動く様子を見る。

• アーキテクチャメッセージが通る 4 つの地点、それぞれに見えるもの、そしてそれを実現するコード。
• 自分で封印するメッセージを入力し、エンクレーブ向けに封印される様子を一歩ずつ確かめられます。
• 解読に挑戦暗号化されたリクエストひとつを、リレーが見たとおりバイト単位で。
• 脅威モデル誰に何が見えうるか。ホスティング事業者、私たち、Tinfoil、ネットワーク、裁判所の命令。
• このページを検証このページが読み込んだコードのハッシュを計算し、ビルドと照合します。
• 透明性暗号化リクエストとエンクレーブ検証の件数、そして本番環境のコミット。