分散システムにおけるデータの有意義な制御。
Oakは、システムの動作に関する外部から検証可能（または反証可能）な主張を透明な方法で提供する分散システムを構築するためのソフトウェアプラットフォームです。
Oakは、Enclaveアプリケーションを構築するために使用されるビルディングブロックを提供します。すなわち、実行されるホストから分離され、リモートで証明可能なアプリケーションです。
このドキュメントでは、異種の「ノード」で構成される分散システムに焦点を当てます。ノードとは、サーバー（例：プライベートデータセンター、パブリッククラウドプロバイダーなど）上で実行されるEnclaveアプリケーション、クライアントデバイス（例：電話、ラップトップ）上で実行される通常のアプリケーション、通常のHTTPまたはgRPCサービス、ストレージシステムなどです。2つのノードが通信する場合、そのいずれかまたは両方がEnclaveアプリケーションである可能性があります。2つのノード間の各インタラクションについて、それらを「イニシエーター」と「レスポンダー」と呼びます。これらの役割に対して「クライアント」と「サーバー」という用語は避けています。なぜなら、場合によっては「イニシエーター」ノードが実際に「サーバー」上で実行されている可能性があるからです。すべての組み合わせが可能です。
Oak分散システム内のEnclaveアプリケーションは、他のノードに対して自身をリモートで証明できます。これは、ローカルの暗号鍵（改ざん防止ハードウェアに保存され、鍵の持ち出しやコピーができないことを保証する）にバインドされた、自身のソフトウェアおよびハードウェアのアイデンティティの証拠を提供することで構成され、最終的にはそのノードのホストで利用可能な1つ以上のソフトウェアまたはハードウェアのルートオブトラストによって署名されます。Enclaveアプリケーションのソフトウェアアイデンティティは、それに寄与する実行可能バイナリの測定値（すなわちダイジェスト／ハッシュ）と、追加データ（例：設定）で構成されます。
Oakは、Enclaveアプリケーションのハードウェアルートオブトラストとして、VMベースの Trusted Execution Environments (TEEs) （例：AMD SEV-SNP、Intel TDX）に焦点を当てています。これにより、Enclaveアプリケーションは、サービスプロバイダーからアクセスできないTEE内のハードウェアバインド鍵で署名されたリモートアテステーションレポートを提供できます。これらの鍵は最終的にTEEメーカー（例：AMD、Intel）にルートを持ちます。これにより、信頼を複数の共謀しないアクターに分散させることで、そのノードの証拠を検証するためにサービスプロバイダーを信頼する必要性が軽減されます（理想的には排除されます）。
起動時に、各Enclaveアプリケーションはローカル鍵ペアを生成し、公開鍵を自身の証拠にバインドします。ノードがEnclaveアプリケーションと通信しようとする場合（イニシエーターまたはレスポンダーのいずれかとして）、2つのノード間にエンドツーエンドの暗号化チャネルが確立されます。チャネル確立の一環として、各ノードは自身の証拠（存在する場合）を他のノードに提供し、他のノードから提供された証拠を使用してその信頼性を確立した上で、データを交換するかどうかを決定できます。
この暗号化および証明されたチャネルは以下を提供します：
Enclaveアプリケーションの攻撃対象領域と信頼されたコンピューティングベース（TCB）を最小化するために、Oakは分割アーキテクチャを推奨します：
Enclave Application: オープンソースコードから（再現可能に）ビルドされ、TEE 内で実行されるバイナリ。Enclave Application は、アテステーション証拠に紐付けられた復号鍵にアクセスでき、他のノードからの受信リクエストを復号して処理し、レスポンスを暗号化して通信チャネル経由で送り返します。これは、外部から検証可能なクレームに関連付けられたバイナリです。他のバイナリが受信リクエストを平文で扱うことはありません。
Host Application: ホスト（信頼されていない）サーバー環境で実行され、Enclave Application のフロントエンドとして機能するバイナリ。他のノードから外部から到達可能な gRPC エンドポイントを公開します。このバイナリは暗号化されたデータのみを扱い、その主な役割は TEE 内で Enclave Application のインスタンスを作成・維持し、暗号化されたデータを Enclave Application との間で転送することです。また、サービスプロバイダーのインフラストラクチャ上で実行するために必要な、コントロールプレーンやその他の内部システムとやり取りするための独自ロジックを含む場合もあります。
このアーキテクチャにより、サービスプロバイダーは検出されることなく Enclave Application のバイナリを別の（潜在的に悪意のある）ものに差し替えることはできません。サービスプロバイダーが Enclave Application にバックドアを仕込もうとした場合、そのバイナリに署名し、Transparent Release プロセスを通じて検証可能なログに公開する必要があり、これによりバックドアは外部の観察者に対して不可逆的に可視化されることになります。
Oak の代表的な用途は、プライバシーを保護する sealed computing アプリケーションを構築することです。
sealed computing アプリケーションでは、ノード（通常はクライアントデバイス）がデータを enclave アプリケーション（通常はサーバー）に送信し、enclave アプリケーションをホストするサービスプロバイダーが計算の入力、出力、副作用を見ることができないままデータを処理します。
以下は簡略化したアーキテクチャ図です。
Oak は、Enclave Application をデプロイできる TEE 内のオペレーティングシステムとして、2 つの種類をサポートしています。
Oak Restricted Kernel: 単一の CPU と単一のアプリケーションのみをサポートする、非常に最小限の独自開発マイクロカーネル。アプリケーションに対して非常に限られたシステムコールのみを公開することで、アプリケーションが実行できることに非常に厳しい制限を課します。Oak Restricted Kernel アプリケーションは、TEE 内の信頼されたコードベース全体のレビューが重要であり、限られた機能と低下したパフォーマンスが許容できるトレードオフである場合に適しています。理想的には、単一の専門家による人間のレビュー担当者が、Oak Restricted Kernel のコード全体を数週間でレビューできるべきです。
Oak Containers: Enclave Application は OCI ランタイムバンドルの一部として提供されます。これには、TEE 内の完全な Linux カーネル、Linux ディストリビューション、およびコンテナランタイムエンジンが含まれます。OCI ランタイムバンドルを互換性レイヤーとして使用することで、より馴染みのある開発体験と柔軟性が得られます。Oak Containers は TEE 内の複数 CPU もサポートするため、高いパフォーマンス要件がある場合に適しています。このアプローチの欠点は、TEE 内で実行される信頼されたコードベース全体のサイズが大幅に大きくなることです。なぜなら、単一の人間のレビュー担当者が Linux カーネルと Linux ディストリビューション全体のコードをレビューすることは現実的ではないからです。このアプローチの信頼モデルは、より広範な Linux エコシステムのセキュリティに依存しています。また、Linux カーネルがアプリケーションに提供する追加機能と柔軟性により、アプリケーションの動作について推論することがより難しくなり、その結果、レビュープロセスがより複雑になります。
Remote Attestation は、TEE が自身の状態と TEE 内で実行されているワークロード（Enclave Application）の識別情報に関する証拠を、リモートの当事者に提供するプロセスです。
Oakは、ブートプロセスにおける各レイヤーの同一性を測定し（ブートローダーだけでなく）、それをTEEの証拠と暗号学的に結び付けるために、多段階プロトコルを使用します。Oak Stage 0仮想ファームウェアはVMメモリに事前ロードされ、TEEのアテステーションレポートによってカバーされます。以降のブートステージをカバーするために、OakはDevice Identifier Composition Engine (DICE)アプローチに依拠しており、各ブートステージが次のステージの測定を担当します。Oakはこの追加の証拠でアテステーションレポートを拡張し、ワークロードのすべてのコンポーネント（例：カーネルやアプリケーション）の同一性が証拠によってカバーされるようにします。
ノードがEnclave Applicationに接続すると、まずアテステーション証拠と関連するエンドースメントを要求します。エンドースメントには、アテステーションレポートが正規のAMD CPUによって署名されたことを証明するAMDからの証明書チェーンと、オプションでエンクレーブ内で実行される各種コンポーネントの開発者による署名済みステートメントが含まれます。その後、もう一方のノードはこれらのエンドースメントを使用して証拠を検証し、自身の期待と一致することを確認します。クライアントノードは、エンクレーブアプリケーションが最新かつ正しく構成されたTEEで実行されていること（例：CPUが最新バージョンのマイクロコードとSNPファームウェアを実行しており、デバッグが無効になっていること）、およびエンクレーブ内で実行される各種コンポーネントの同一性が期待と一致することを確認すべきです。
ノードがエンクレーブアプリケーションがすべての期待を満たしていると確信すると、証拠にバインドされた公開鍵を使用して、エンクレーブアプリケーションとの暗号化チャネルを確立します。
エンクレーブアプリケーションが期待に沿ってデータを処理することを確実にするために、外部のレビュアーがTEE内で実行されるコードをレビューする必要があります。Oakは、ほとんどのOakコンポーネントの来歴情報を公開することでこれを可能にします。これは逆引きインデックスとして機能し、レビュアーがアテステーション証拠から得たバイナリの測定ダイジェストに基づいて、各コンポーネントのビルドに使用された正確なソースコードコミットを検索できるようにします。すべてのOakコンポーネントは再現可能にビルド可能であり（以下のTransparent Releaseを参照）、これはレビュアーが特定のソースコードコミットを取得してコンポーネントを再ビルドし、同じ正確な測定ダイジェストが生成されることを確認できることを意味します。これにより、レビュアーは、レビューしているコードバージョンが起動時にエンクレーブにロードされたものとまったく同じコードバージョンであると確信できます。
Transparent Releaseは、開発者がバイナリアーティファクトに関する主張を透明かつ否認不能な方法で公開および消費できるようにする、一連のフォーマットとツールです。
リモートアテステーションプロセスの一環として、ノードは1つ以上のバイナリダイジェスト（例：通常はブートチェーンの各レイヤーごとに少なくとも1つ）の形式でEnclave Applicationの同一性を取得します。その後、これらの測定値が信頼できるかどうかを確立する必要があります。
最初の近似として、クライアントが期待するダイジェストをハードコーディングすることで正確に把握し、実際の値をローカルで期待値と照合できると仮定できます。これは機能しますが、サーバーアプリケーションの進化に関して非常に制限的です。新しいリリースの一環としてEnclave Applicationのバイナリのいずれかが変更されるとすぐに、ノードはEnclave Applicationを信頼しなくなり、両者はもはや相互にやり取りできなくなります。
これは、ダイジェスト自体ではなく、バイナリダイジェストの署名に使用される公開鍵をノードにハードコーディングすることで解決できます。この方法では、Enclave Applicationのバイナリが変更されたとき、開発者は所有する対応する秘密鍵でそれらに署名し、これらの署名をリモートアテステーションレポートとともにノードに配布でき、ノードはこれらの署名の有効性を検証できます。これは機能しますが、Enclave Applicationが異なるノードに異なる署名を提示できるという問題があり、ユーザーが検出するのは非常に困難です。
実装された解決策は、新しいリリースが作成されたときにダイジェストに署名するだけでなく、その署名を外部の追記専用で検証可能なログに記録することです。Oak はこの目的のために、外部の検証可能なログとして Rekor（Sigstore による）に依存しています。Transparent Release プロセスの一環として、署名は Rekor に記録され、そこから包含証明（または包含の約束）が取得され、Rekor のルートキーによって署名されます。これは対象のバイナリ成果物とともに保存され、Enclave Application の身元を検証したいノードに提供されます。これにより、開発者が Enclave Application にバックドアを挿入する際に、それを検証可能なログに記録せずに行うことは不可能になります。
完全なセキュリティが不可能であることは認識しています。一般に、Trusted Computing Base（TCB）は小さいほど良く、Oak は TCB を信頼する必要のある最小限のコンポーネントまで削減するよう努めています。
Oak は、以下を信頼する必要なく、検証可能な信頼性を持つように設計されています。
