さて、2ヶ月間の堅実な努力の末、私はタップアウトしています。 「Groth16 は TEE で信頼してセットアップを行い、有毒廃棄物が破壊されたというリモート認証を取得する」プロジェクトは失敗に終わりました。以下のTLDRになります。 ここで言及するのは、実際にはそうではないのに、私がまだ取り組んでいると思っているからといって、誰もそれに取り組むのを思いとどまらせたくないからです。

TLDRの: - 現在、これを実現できる唯一の TEE (AFAICT) は TDX で、必要な暗号化 RAM が保証されているためです。(このプロジェクトでは、TEEで正しいコードが実行されていることを知るだけでは不十分であり、マシンの物理的な攻撃者が式典中にRAMをダンプして有毒廃棄物を学ぶことができないことも知っておく必要があります)。 - TDX リモート構成証明は、VM イメージの任意のバイトが変更された場合に変更されるハッシュである "MRTD" を経由して署名します。 - したがって、将来の監査人/ユーザーが、信頼できるセットアップ中に(特にあらゆる種類の自動化された方法で)正しいコードを実行していたことを確認するためには、そのMRTDハッシュを再現できる必要があり、そのためには、人間が読めるソースコードからVMイメージをビットごとに再現可能な方法で再構築する必要があります。 - GCPイメージをビット単位で再現可能な方法で作成できませんでした。(超最小限のものでも、SSHポートを起動して開くだけで、文字通り他には何も開きません)。

これが既存の既製のツールで可能かどうかはわかりません。既存のツールを微調整する必要がある場合があります。 StageXは非常に役に立ちましたので、なるべくそちらを使うことをオススメします。問題は、現在StageXレイヤーでは利用できないものが必要なときに発生します。そのためには、必要なものをソースからビルドする必要があります (tarball を自分でビルドせずにダウンロードすることは、サプライ チェーンのリスクであるため)。 そして、ソースからの_ほとんどの_ソフトウェアをビットごとに再現可能な方法でビルド/コンパイルすることは、非常に時間がかかり、困難で、もろいことがわかりました。そして、多くの場合、私はそれを*まったく*行うことができませんでした。

必要なソフトウェアのビルドは、ハッシュピンされたStageXレイヤーのみで構成されるDockerコンテナ内で行うことをお勧めします。そのテクニックは私に最も多くの走行距離を与えました。