Phala / Intel TDX · 高可信度部署

TgWitness / 文档 · 部署与恢复

高可信度部署在 归档验证基础上增加了对采集环境的独立检查。审核人员会查询云服务提供商和 Cloudflare 持有的部署及访问记录，而 Intel TDX 部署还会对采集器的环境进行 硬件认证。

常规的本地和 Docker 使用方式保持不变。除非您使用 python -m tgwitness.cloud进行部署，且收集器仅在部署设置为 TGWITNESS_ASSURANCE.

图表转为文本

1. 操作员 → 服务器，防火墙未配置入站规则 (提供商 API)
2. 操作员 → 隧道与 DNS (Cloudflare API)
3. 服务器，防火墙未配置入站规则 → 隧道与 DNS (仅限外发)
4. 服务器，防火墙未配置入站规则 → 在服务器上生成的签名密钥
5. Verifier，只读令牌 → 提供商日志和防火墙
6. Verifier，只读令牌 → 隧道连接器地址和入口
7. Verifier，只读令牌 → 已签名的 /api/assurance 声明
8. Verifier，只读令牌 → 证据 ZIP

本页内容

• 验证者可以检查的内容
• 提供商
• Phala Cloud 上的机密虚拟机（Intel TDX）
• 开始之前
• 来自面板
• 无需域名的快速隧道
• 部署
• 调试部署与锁定
• 移除部署
• 任意服务器（自我认证）
• 验证
• 证据移交报告
• Cloudflare 作为外部见证方
• 阅读部署结果

验证者可以检查的内容#

收集器将 SSH 状态、会话、登录历史记录和启动信息记录在经过签名的 process-start 和 host.state 记录中。在普通虚拟机上，这些是本地库存 记录，审核人员会将其与提供商的独立记录进行比对。下文所述的 英特尔 TDX 部署还会额外验证基于硬件的测量结果。

提供商#

请为每个案例使用专用的项目、团队、账户或子账户：这样，验证者的 只读访问权限将仅显示此部署。凭据从 --provider-token-file 或上述变量中读取，绝不从命令行获取。对于 AWS，该文件 包含 ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]；区域为 --location.

每份报告中都会注明各服务商记录中无法显示的内容。 简而言之：Hetzner 会记录控制台请求；而 DigitalOcean 的恢复控制台、Linode 的 Lish/Glish 以及 Vultr 的 Web 控制台则不会被直接记录，因此 root 账户在首次启动时会被锁定，若要登录控制台 则需要重置密码或更改启动方式，而这些操作会被记录下来。Vultr 会向任何能够读取该实例的密钥返回控制台 地址；但记录和报告中均不会存储该地址。

Phala Cloud 上的机密虚拟机（Intel TDX）#

该 --provider phala 收集器运行在 Phala Cloud 上的英特尔 TDX 机密虚拟机中， 由 dstack 管理。主机和 Phala 工作人员无法读取其 内存，且处理器会对机器的启动过程生成一份认证声明并进行签名。验证器不会 仅凭 Phala 的声明就予以采信： tgwitness.tdx 会自行核查每份证明——直至固定的英特尔 SGX 根证书颁发机构（Root CA）——并将其与英特尔的撤销列表及英特尔签名的平台数据进行比对，同时拒绝 任何可被调试或迁移的机器。

The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from Dstack-TEE/meta-dstack into dstack-images beside the record; --tdx-image FOLDER uses another folder or an unpacked image, --tdx-image none skips the comparison. The measurement follows dstack-mr and the qemu-acpi crate of Dstack-TEE/dstack. Private measurement regressions compare QEMU's own ACPI output and a retained Phala Cloud quote; live qualification also needs the published image. --tdx-measurements still compares MRTD and RTMR0-2 given as JSON instead.

日志中记录的每次收集器启动都附有此类证明，因此 verify --evidence 会检查每次启动及其引导的操作系统镜像。Phala 的应用程序修订版本 和 CVM 的操作充当提供商日志：部署后 Docker Compose 配置的任何更改 都会导致报告失败，且重启记录将被列出以供审查。

在面板中，选择“附加功能 → 7×24小时服务器 ”下的“机密虚拟机 · Phala Cloud ”，并粘贴 Phala Cloud API 密钥；快速隧道的工作原理与 Hetzner 上相同。在命令行中：

python -m tgwitness.cloud deploy --provider phala --name case-1 --server-type tdx.small \
    --ref v0.8.0 --repository https://github.com/phishdestroy/TgWitness --quick-tunnel \
    --provider-token-file phala-key.txt
python -m tgwitness.cloud verify --record deployments/case-1/deployment.json \
    --provider-token-file phala-key.txt --cloud-init deployments/case-1/docker-compose.yaml \
    --source CHECKOUT_OF_COMMIT --fingerprint COLLECTOR_FINGERPRINT --report certificate.md
python -m tgwitness.cloud check-report --report certificate.pdf --verifier-fingerprint VERIFIER_KEY

--tdx-collateral 从文件中读取英特尔的证书和撤销列表，而不是 从英特尔下载。此处无法使用网关 DNS：Phala 没有用于 出站流量的提供商防火墙。

认证证书#

对于 Phala 部署，verify --report certificate.md 还会写入证书：一个 自包含的 certificate.html 文件和一份 A4 规格的 certificate.pdf 文件，其中包含验证结果、从英特尔根证书到收集器密钥的信任链、 与普通服务器及高保障服务器的对比分析、 与基于已发布镜像计算出的数值并列的测量结果、各部分的担保方、 英特尔证书链、每项检查、提供商日志，以及如何重复进行 验证。 JSON 报告仍是权威记录；这些页面仅用于呈现其内容。

该报告已通过签名和时间戳进行数字封存，封存文件为 certificate.seal.json 及其旁边的 .tsq/.tsr 文件：

--timestamp URL（可重复）选择其他认证机构，--timestamp none 不选择任何机构，--sign-with none 不对印章进行签名。check-report 会验证报告的哈希值、验证者签名、 每个时间戳与受信任根证书的关联及其合格状态，以及 PDF 文件的签名。 在欧盟以外地区， 合格时间戳以及报告整体的法律效力，由接收它的法院 或主管部门决定；该印章表明报告的生成时间以及其内容未被篡改。

一份认证报告无法排除英特尔 TDX 模块或微代码中存在漏洞，也无法排除对 内存总线的物理访问。无论谁控制了 Phala 账户中的应用程序，都可以部署另一个“compose”； 它将显示为一个带有新“compose”哈希值的新版本。主机控制着机器的 时间源和网络。

部署、使用 --evidence 进行验证、重启、操作系统镜像比较、带有签名和时间戳的数字密封证书以及 销毁操作均已在 Phala Cloud 平台上运行；参见 （2026 年 11 月 4 日运行）和 。

开始之前#

1. 一个 Cloudflare 区域、其账户 ID 以及一个具有 Cloudflare Tunnel 编辑、 区域读取和 DNS 编辑权限的 API 令牌，由 --cloudflare-token-file 或 CLOUDFLARE_API_TOKEN。对于验证者：Cloudflare Tunnel 读取、DNS 读取，以及针对 审计日志的账户设置读取。若无域名， 快速隧道则无需上述任何信息。
2. 具有专用项目写入权限的提供商凭据； lock 同样使用：
   • Hetzner：具有读写权限的 API 令牌；
   • DigitalOcean：具有写入权限的个人访问令牌；
   • Linode：个人访问令牌，包含 linodes, firewall 和 events 读写权限；
   • Vultr：专用账户或子账户的 API 密钥；
   • AWS：允许使用 IAM 凭据 ec2:DescribeVpcs, ec2:DescribeImages, ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress, ec2:RunInstances, ec2:CreateTags, ec2:DescribeInstances, ec2:DescribeSecurityGroupRules 且 ec2:RevokeSecurityGroupIngress.
3. 待执行的提交。发布标签会通过以下方式解析为对应的提交： git ls-remote； 服务器仅接收该 40 个字符的提交信息。

来自面板#

在您的电脑上，通过“扩展功能”→“24/7 服务器”即可为 Hetzner 运行相同的 deploy Hetzner服务，仅需三个 步骤：选择欧洲或美国，粘贴Hetzner令牌（读写权限），然后核对 控制面板根据该令牌检索到的服务器类型、月费、地址及版本。在您确认之前， 不会创建任何内容。控制面板会将每个步骤显示为 deploy 报告显示，随后显示 地址、面板令牌和签名密钥指纹。若未绑定域名，服务器将获得 快速隧道 ；重启后，通过“您的服务器”→“查找当前地址 ”可再次查询。若要在自有域名下设置固定地址，请打开 “可选”→“自有域名 ”，并添加 Cloudflare 令牌（预设链接会自动选择“区域 读取”、“DNS 编辑”和“Cloudflare 隧道编辑”）。

这些令牌随每次请求从浏览器标签页传输至同一台计算机上的 TgWitness， 且不会被写入任何位置；部署记录、经过处理的 cloud-init、面板令牌以及 用于快速隧道的地址密钥均保存在 deployments/NAME 数据目录内。 面板仅通过直接回环连接向主管理员提供此功能 （127.0.0.1，不允许代理或隧道头部）；通过网络访问的面板则会显示相关命令 。版本默认采用运行中面板的发布标签，该标签通过 GitHub API解析获得。位置、服务器类型和价格来自Hetzner的API： cpx22 在提供该服务的地方 使用该服务，否则使用内存至少为 2 GB 的最便宜 x86 类型。

无需域名的快速隧道#

--quick-tunnel 替换 --zone, --cloudflare-account 并 --panel-host；无需使用 Cloudflare 账户或令牌：

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --quick-tunnel --provider-token-file hetzner.token

在服务器端，cloudflared 会打开一条 快速隧道 连接到控制面板：一个随机的 https://….trycloudflare.com 地址，该地址会在 cloudflared 或服务器重启时发生变化。服务器上一个小型服务会将每个地址发布到一个随机的 ntfy.sh 主题中，并使用仅部署目录中保存的密钥进行签名（HMAC-SHA256） （address-key.txt），并每三小时重复一次，因为 ntfy.sh 会保留帖子 12. deploy 和“查找当前地址”功能仅接受签名帖子，因此伪造的帖子无法 将您和您的面板令牌重定向到他人的地址。该主题记录在 已发布的 cloud-init 中：任何拥有这些信息的人都能读取当前地址，而该地址仍会要求提供 面板令牌。无论哪种方式，服务器均不保留任何入站端口。

验证器没有地址密钥，任何读取该主题的人都可以向其发布消息。因此，收集器 还会发布该地址本身，并使用其自身的 Ed25519 密钥进行签名；verify 会取部署记录中 由收集器密钥签名的最新发布消息；发布消息的排序依据是 ntfy.sh 接收它们的时间，而非它们声称的时间。 在此变更之前的收集器不会对任何内容进行签名，而 verify 随后会取最新的一条发布内容，并在 statement 检查中声明这一点；伪造的发布内容 只能导致该检查失败，因为该地址仍必须使用收集器的密钥进行响应。

代价：由于没有 Cloudflare 账户记录快速隧道，因此 verify 会报告 隧道、连接器和 DNS 检查不可用，结果最好也只能是 incomplete（在 Phala Cloud 上，检查反而通过：连接器在被测的 Docker Compose 配置中运行）； 提供商记录、防火墙、签名声明、主机测量和安装程序比较均 按常规进行检查。与参考安装程序的字节比较需要一个已部署的提交 版本，该版本已知 --quick-tunnel；从 0.7.0 版本检出后构建域名安装程序并报告 差异。 Cloudflare 对快速隧道不提供正常运行时间保证，允许 200 个请求 在传输中，且不传输服务器发送事件（Server-Sent Events），因此控制面板的实时更新（0.7.0 之后的版本） 可能无法通过快速隧道到达，需要重新加载页面；这一部分尚未经过测试。对于 必须保持稳定的场景，请使用您自己的域名。

部署#

请先查看所有即将发送的内容。 plan 不会向任何服务提供商或 Cloudflare 发起请求：

python -m tgwitness.cloud plan --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org

然后使用相同的选项和凭据进行部署：

python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org \
    --witness-host case-witness.example.org \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

初始服务器类型： cpx22 (Hetzner)， s-1vcpu-2gb (DigitalOcean)， g6-standard-1 (Linode)， vc2-1c-2gb (Vultr)， t3.small (AWS)。 --location 以及 --image 默认使用各 服务商位于欧洲区域的 Ubuntu 24.04 系统。

--repository 从另一个 https Git 仓库获取提交，且 URL 中不包含凭据 （默认 https://github.com/phishdestroy/TgWitness.git). deploy 也接受 --out 指定其他部署目录（默认 deployments/NAME；若目录中已存在 部署则会被拒绝）以及 --wait，即等待收集器签署声明所需的分钟数： 1 到 240，默认值为 20，或 60 用于 generic.

命令：

1. 创建一个 Cloudflare 隧道，其入站流量将面板主机名转发至面板， 若已指定，则将见证主机名转发至 /api/witness/head 并 /api/assurance 且仅限该主机名；
2. 为这些主机名创建代理 CNAME 记录，并拒绝已存在的名称；
3. 创建一个不包含入站规则的提供商防火墙，并在其后部署一台服务器，该服务器不使用 SSH 密钥、 不进行备份、不使用控制台代理，且 cloud-init 会屏蔽 SSH、锁定 root 权限，并安装 cloudflared、精确获取该提交、验证并以 强化版 systemd 服务的形式启动 TgWitness；
4. 等待收集器发送的签名声明，并验证该声明是否指明了此服务器以及 此 cloud-init 的哈希值。

deployments/case-2026-11/ 其中包含：

提供商的根密码、隧道令牌和面板令牌绝不会写入 deployment.json。请通过您无法单独控制的频道（例如见证频道或发送给收件人的消息）发布文末显示的收集器指纹。

请使用面板令牌登录 Telegram， https://case.example.org 使用面板令牌登录 Telegram，具体操作参见 账户指南。面板操作会被记录在已签名的日志中；这些操作并非 SSH 会话。见证人可以轮询 https://case-witness.example.org.

不支持 SSH：如果初始化失败，收集器将永远不会响应。请删除服务器并 重新部署，或使用调试部署来查找原因。

用户数据中的秘密#

cloud-init 包含两个密钥：控制面板令牌和 Cloudflare 隧道令牌。 签名密钥不在此列；它是在服务器上生成的。Hetzner、DigitalOcean 和 Linode 不会通过其 API 返回用户数据。Vultr 会将其返回给任何能够读取 实例的密钥，而 EC2 则通过 DescribeInstanceAttribute。对于 AWS，仅向验证者提供表格中的三项 操作，切勿 ec2:Describe*。对于 Vultr，假设验证者的密钥可以读取这两个 令牌。隧道令牌允许某人运行第二个连接器： verify 这会报告任何 不在服务器上的连接器，且收集器的声明无法通过这种方式伪造，因为每一条 都会对新的挑战进行签名。使用 --quick-tunnel 第二个密钥则是地址密钥： 任何读取它的人都可以发布一个虚假地址，而控制面板会接受该地址。

该收集器的公开声明中未提及服务器地址和登录来源； 这两项信息均保存在已签名的日志中。

调试部署与锁定#

--debug-ssh-key KEY --debug-ssh-from 198.51.100.4 仅支持来自单一地址 或小型网络（IPv4 最多 /24，IPv6 最多 /48）的单个密钥的 SSH 连接。 KEY 已向 服务商注册：Hetzner 项目中 SSH 密钥的名称或 ID、DigitalOcean 团队中 SSH 密钥的 ID 或指纹、其个人资料中的 SSH 密钥已添加到 root 用户的 Linode 用户名、 Vultr 账户中 SSH 密钥的 ID，或该区域内 EC2 密钥对的名称。这些 选项不适用于 generic。此类部署将被记录为 debug ，且绝不会被报告为 高可信度。操作完成后，请运行 sudo tgwitness-lock 作为最后一次 SSH 会话的最后一条命令，然后：

python -m tgwitness.cloud lock --record deployments/case-2026-11/deployment.json --provider-token-file hetzner.token

防火墙会丢失所有入站规则。随后生成的报告会显示何时允许了 SSH 连接以及何时 将其关闭；该窗口将保持可见状态。

删除部署#

destroy 删除服务器及其防火墙（通过部署标签定位），以便 中途失败的部署也会被移除，随后删除指向其 隧道的 DNS 记录以及隧道本身。服务器的日志和签名密钥将一并删除：请先导出 证据。记录将保留，并标记为 removed，并附有删除操作的API调用记录。

python -m tgwitness.cloud destroy --record deployments/case-2026-11/deployment.json --confirm case-2026-11 \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token

针对 Hetzner，已通过 API 实现了内容删除功能。对于其他服务商 destroy 在删除任何内容之前 需先停止服务，并在服务商控制台中指定要删除的标签。手动安装的 服务器（generic）仅会丢失其隧道和 DNS 记录。快速隧道部署无需 Cloudflare 令牌：其隧道仅连接至服务器，且相关帖子将在 ntfy.sh 上于 12 小时内过期。

任意服务器（自我认证）#

--provider generic 适用于购买或手动安装的服务器。 deploy 用于创建隧道 和 DNS，并写入 install.sh （私有）和 install.redacted.sh （用于发布），然后进入等待状态。 将 install.sh 到新安装的 Ubuntu 24.04 服务器上，并在该服务器上运行：

sudo bash install.sh

它会记录主机当时的原始状态（登录信息、账户、 authorized_keys、监听套接字、 服务、定时任务、软件包）的原始状态，安装该提交，启用主机防火墙，删除 自身，屏蔽 SSH 并结束会话。此类服务器的报告充其量只能 算是“自我证明”：无论谁运行了安装程序，在运行之前都已拥有 root 权限，且验证者无法获取 任何提供商记录。但这仍优于来源不明的服务器：资产清单、 安装程序哈希值以及此后每次登录都经过了签名。

验证#

验证者需要 deployment.json已发布的安装程序、只读凭据，以及 最好是该提交的代码检出和证据 ZIP：

git clone -c core.autocrlf=false https://github.com/phishdestroy/TgWitness.git checkout
git -C checkout checkout 0123456789abcdef0123456789abcdef01234567
python -m tgwitness.cloud verify --record deployment.json \
    --provider-token-file read-only.token --cloudflare-token-file cloudflare-read.token \
    --fingerprint COLLECTOR_FINGERPRINT --cloud-init cloud-init.redacted.yaml \
    --source checkout --evidence tgwitness-evidence.zip --report report.md

验证器会在该时刻请求每个提供商和 Cloudflare 的值；记录 仅提供需要查询的 ID。退出代码 0 表示通过（PASS），1 表示失败（FAIL），2 表示 待审核（REVIEW）、不完整（INCOMPLETE）或自我认证（SELF-ATTESTED）。 --fingerprint 应来自一个独立的 频道；若无此信息，则仅将密钥与运营商的记录进行比对。 python verify.py 仍会像“证据”部分所述那样，自行验证证据ZIP。

提供商操作分为以下几类：创建操作以及在创建后 30 分钟内启动的操作均通过审核； 控制台、救援、密码重置、重建、ISO、镜像、快照、备份、系统管理器、 EC2 实例连接和防火墙开放操作若失败；电源操作以及任何意外操作 均会被标记为待审查。未知操作绝不会悄无声息地通过审核。

证据移交报告#

--report report.md 生成 Markdown 报告，并 report.json 其旁边：

1. 结果、收集器密钥指纹、部署、提供商、提交、服务器、防火墙、隧道；
2. 每次检查及其状态和来源（提供商 API、Cloudflare API、收集器声明、 证据日志）；
3. 提供者日志，其中包含每项操作的评估结果，以及（若提供者进行了记录）操作执行者；
4. Cloudflare 端点，用于存储隧道的连接信息、配置和审计日志；
5. 经签名的收集者声明；
6. 该报告阐明了哪些内容，又未阐明哪些内容；
7. 用于重现该功能的命令，以及每个输入文件的SHA-256。

提交报告、 report.json, deployment.json、已发布的安装程序以及 证据 ZIP。请尽早生成报告：服务商的日志保存期限有限。

Cloudflare 作为外部见证方#

此处所有内容均为可选。即使没有 Cloudflare 账户，服务器仍可运行，且其中两项 功能目前已可正常使用：

Logpush（该功能会将 Cloudflare 的副本保存在 R2 中）是一项企业级功能：在免费 套餐中，Cloudflare 会 logpush is not enabled for this account。其网关日志在该处保留 24 小时，因此“证据模式”会将其复制到已签名的日志中（即 Cloudflare Gateway 记录的 该服务器的 DNS 查询日志，这是一个具有“账户分析读取”权限的只读令牌）。

如果没有“零信任”方案，一个账户只有一个 DNS 位置。当 Cloudflare 拒绝另一个位置时， 服务器会共享现有的位置，并通过其地址来区分查询；该过滤器 也需要“零信任”PII 读取权限，并且 destroy 这会留下一个共享位置。一次日志查询的跨度 最多为三小时，因此复制和 verify 读取操作需在三小时的时段内完成。

Gateway DNS 负责系统解析器。通过 443 端口以 DNS over HTTPS 方式连接至其他解析器，以及 连接至未被任何地方查询的地址（例如 Telegram 的数据中心）的连接，均不会 记录在日志中。

Cloudflare 无法查看 Telegram 的加密内容、该 Telegram 账户下的其他设备 （“证据模式”的设备列表是从 Telegram 端记录的）或服务提供商的虚拟机管理程序。

阅读部署结果#

对于普通虚拟机，提供商控制主机基础设施，并会同时核对本地库存 与提供商记录。对于 Intel TDX，验证者还会额外检查 硬件配置、收集器绑定、Compose 以及操作系统测量数据。请阅读各项 结果，以查看哪些检查通过或不可用。

历史防火墙详情取决于服务提供商；Linode 会保留规则版本。 验证记录列出了已测试的部署和剩余的在线 检查，而验证范围将这些环境 检查与存档获取及完整性联系起来。