attestos

Linux ブートアテステーションの実験用イメージおよびエビデンスハーネス。アンチチートベンダーが、ディストリビューション名の許可リストに頼る代わりに検証可能な内容をテストするためのものです。

メカニズム、脅威モデル、ベンダー仕様は、plunder707/attested-gaming にあります。このリポジトリは、そのエビデンスを生成するイメージです。

ステータス: ソースメカニクスプレビュー。インストール不可または本番信頼不可。

GitHub Actions の実行 31157890393 と 31159951490 は、Bazzite 派生の QCOW2 をビルドし、swtpm を備えゲストネットワークなしの QEMU/OVMF で起動して、 永続的な EK/AK ハンドルをプロビジョニングし、ゲスト内部から SHA-256 の PCR 7、11、12、15 に対する raw クォートを検証しました。その境界付きレシートの SHA-256 は ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf です。 別の検証ワークフロー 31160003873 は、このリポジトリの最終エージェントコミット b918392 を独立したソフトウェア TPM に対して実行し、 AK 登録、raw クォート検証、リプレイ拒否、署名改ざん拒否、QEMU/OVMF の TPM 配線をパスしました。

起動結果はまた、Bazzite のポリシーブロッカーを確認しました。UKI ファイルも systemd-stub のシグナルも 存在せず、意図した lockdown 引数もなく、PCR 11 と 15 はゼロのままでした。PCR 12 もゼロでしたが、 これは独立した失敗ではありません。埋め込まれた UKI コマンドラインは PCR 11 に属し、PCR 12 は外部の コマンドライン入力を記録するため、入力がなければ正しくゼロのままであり得ます。Secure Boot キー登録、 UKI によるコマンドライン測定、ハードウェアの来歴、イベントログのリプレイ、トランスポート結合、 ブートポリシーの受入は未解決のままです。どちらの成功実行も、機能する本番アテステーションシステムを 確立していません。

別の Fedora 封印イメージのポジティブコントロールは、実行 31218059725 で2回、 統合ソースの先頭で 実行 31219745053 でもう一度パスしました。 これは、ハーネスが不変のアップストリーム署名付き UKI を起動し、ファームウェアが選択したパスと 読み込まれたファイルのハッシュを preboot 検査に結合し、非ゼロの PCR 11 を観測し、署名なしの .cmdline 改変を拒否できることを証明します。これはハーネスのコントロールにすぎません。 製造元、ポリシー、本番トラストのフラグはすべて false のままであり、Bazzite プレビューを インストール可能にするものではありません。

その後、別の署名付き PCR 12 ポリシーアドオンレーンは 実行 31234464516 で2回パスしました。 アップストリーム UKI と PCR 11 はバイト単位で同一のままでした。両方の署名付きブートは lockdown=confidentiality module.sig_enforce=1 を正確に1回適用し、PCR 12 ca62dd5f...a8f5 を再現しました。 署名後の改ざんは拒否され、ゼロ PCR 12 のベースラインに戻りました。 これは、展開可能なキー階層や OS トラストポリシーではなく、限定されたメカニズムを証明します。

このソースは、レビューと再現可能なエミュレーションのために利用可能です。GHCR イメージは公開されておらず、 インストール可能な信頼済みディストリビューションではありません。

完了した Bazzite 実験は、BOOTED_IMAGE_CANARY.md で指定されています。再現とソースビルドの手順は BUILDING.md にあります。UKI ベースのエビデンスとその独立した受入基準は、UKI_BASE_DECISION.md に記録されています。署名付き PCR 12 ポリシーアドオン実験は、別途 FEDORA_PCR12_ADDON_CANARY.md で指定されています。マイルストーンの順序と停止ルールは ROADMAP.md で追跡されています。別の読み込み済み UKI ハーネスコントロールは、FEDORA_SEALED_POSITIVE_CONTROL.md で指定されています。

Bazzite に追加されるもの

何も削除されず、何もパッチされません。その上に4つのものが追加されます:

1. tpm2-tools と tpm2-tss — エージェントが実行時に必要とするものです。
2. カーネルコマンドライン — /usr/lib/attestos/cmdline に lockdown=confidentiality と module.sig_enforce=1 を保持します。
3. attestos-provision — TPM 内に個別の永続 RSA EK および AK アイデンティティを作成し、NV ストレージに存在する場合はエンドースメント証明書を読み出すワンショットユニットです。
4. attestos-agent — ループバック上でソケットアクティベーションされ、厳密な attestos.tpm/v1 のアイデンティティ、アクティベーション、またはクォートチャレンジに raw TPM エビデンスで応答します。エージェントは信頼判定を返しません。

ベースが Bazzite である理由

Bazzite は Fedora 派生であり、現在アンチチートの許可リストがブロックしているのは Fedora ファミリーです。ここでアテステーションが機能することを証明することは、証明する価値のあるケースです。SteamOS 上に構築しても何も実証できません。SteamOS はすでに許可されているため、そこでデモが成功しても、すでに持っているアクセスを得るだけです。

Bazzite はまた、レイヤリングされるように設計されています。OCI イメージであるため、このリポジトリはミラーやインストーラーを伴うディストリビューションではなく、Containerfile と GitHub Action です。

ポリシーはカーネルの前に認証・測定されなければならない

これが、すべてに意味があるかどうかを左右する部分です。lockdown=confidentiality は、/dev/mem、実行中のカーネルに対する kprobe、署名なしモジュールの読み込みをブロックします。その保証は、ポリシーがユーザーが編集できるブートローダー設定にのみ存在する場合、何の価値もありません。そうでなければ、ユーザーは引数を削除し、同じカーネル測定で起動し、欠落したポリシーについて何も語らないクォートを提示できます。

Unified Kernel Image は、カーネル、initrd、および埋め込まれたコマンドラインを、PCR 11 に測定される単一の署名付き PE バイナリに束縛します。別途署名された systemd コマンドラインアドオンは、そのアップストリーム UKI を変更せずに、追加ポリシーを PCR 12 に拡張できます。どちらの経路も、実際に読み込まれたアーティファクトに結合され、検証者によってリプレイされなければなりません。ファイルの存在や非ゼロの PCR だけでは不十分です。

Bazzite は UKI を採用しておらず、これは疑いではなく今や確認されています。 その Containerfile は UKI カーネルパッケージを積極的に除外しています:

dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"

systemd-ukify はリポジトリのどこにも登場しません。したがって、このイメージが同梱する cmdline ファイルは、現時点では意図の表明にすぎません。UKI がなければそれを封印するものがなく、ユーザーはブートローダーで編集でき、PCR 11 は設計が想定するものを測定しません。

Bazzite を修正することは build.sh の1行では済みません。イメージの起動方法を変更するか、すでに systemd-stub 経由で起動するベースを採用するかによって、信頼されたカーネル前の測定経路が必要です。

実験により、現実的な選択肢は次のように絞り込まれます:

1. それでも Bazzite 上で UKI 作業を行い、ベースからの乖離を受け入れる。
2. アップストリームの封印された Fedora UKI を使用し、PCR 12 に測定される別途署名された systemd アドオンを通じて attestos ポリシーを追加する。
3. 別の認証済みカーネル前測定経路を見つける。カーネル起動後にのみ行われる測定はより弱いエビデンスクラスであり、同等として提示してはなりません。

未解決のキー受入問題

アップストリームの Fedora UKI はディストリビューション署名を維持できますが、別の attestos ポリシーアドオンには、ファームウェア、Shim、または MOK によって受け入れられる署名キーが依然として必要です。サードパーティのカーネルは、同じ問題のより大きなバージョンを抱えています。展開オプションは次のとおりです:

• MOK 登録 — ユーザーが初回起動時に青いファームウェア画面から Machine Owner Key を登録する方法。Universal Blue はアウトオブツリーカーネルモジュールでこれを既に行っているため、仕組みは存在しますが、主張は「Microsoft がこのカーネルを保証する」から「ユーザーがこのキーを明示的に信頼する」に変わり、ベンダーがそれを受け入れられるかどうかを判断する必要があります。
• Microsoft 署名付き shim — 実際のディストリビューションが取る経路であり、フォームではなくレビュープロセスです。
• ユーザー所有の PK と KEK — 完全な制御を提供しますが、採用はほとんどありません。

使い捨ての Fedora ハーネスは、実行ローカル証明書をコピーした UEFI DB に登録し、展開モデルを主張することなくメカニズムを証明します。受け入れられたエンドユーザーのキー登録、失効、または復旧契約はまだありません。これは、工学的な問題であると同時に、証明書利用者側の問題でもあります。

インストール

サポートされたインストールコマンドはまだありません。特に、ghcr.io/plunder707/attestos:latest は公開されていません。現在のプレビューは、ソースレビューと分離された QEMU/swtpm 再現のみを目的としています。BUILDING.md を参照してください。

レイアウト

Containerfile            base image and the single RUN that calls build.sh
build_files/build.sh     the attestation layer
system_files/            agent, provisioning script, systemd units
image-template.env       image name and registry organisation
.github/workflows/       build-only and isolated evidence canaries
Justfile                 local build and test targets

build_files/ と system_files/ 以外のすべては、ublue-os/image-template からのものであり、彼らの成果物です。

まだ答えなければならないこと

• イメージがそもそもビルドできるか。GitHub Actions ラン 31143048491 でコミット 14e3a21 について確認済み。ビルドは致命的でない DNF 状態の lint 警告を2件出力しました。
• 検証者が、エージェントの実行時 bootc status のデプロイメント主張を、検証済みのイメージアイデンティティに変換する方法。その主張はメタデータであり、署名された権威ではありません。bootc がないシステムでは、明示的に unavailable です。
• Bazzite 派生の QCOW2 は分離されたメカニクスカナリアをパスしますが、UKI と lockdown に関するネガティブな観測結果のため、ポリシー受入には至りません。
• 別途署名された PCR 12 ポリシーアドオンが、更新、ロールバック、代替の順序付け、および本番キーライフサイクルの下で再現可能かどうか。凍結された単一ポリシーハーネスは現在パスしますが、これらのライフサイクルケースはパスしません。
• エージェントとポリシーを封印された候補に組み込み、ゲスト外部で署名付きクォートを検証し、関連するイベントログをリプレイする方法。
• bootc ルート上で PCR 15 が設計が想定する方法で入力されるか。
• MOK 登録によって、ポリシーを書くのに十分安定した PCR 7 値が生成されるか。
• ベンダーが MOK 登録されたキー階層をそもそも受け入れるか。

実行時測定の問いには、追加のハードウェアを必要としない QEMU + OVMF + swtpm が必要です。配線と raw TPM プロトコルの仕組みはそこでパスしましたが、ビルドされたイメージを起動し、そのイベントログとポリシーを検証することは、依然として別の実験です。ベンダーの受け入れにはベンダーとの対話が必要です。

ライセンス

Apache-2.0。これはビルド元のテンプレートに合わせたものです。