# 威胁模型 — dsh-takeover

> 配套红队套件：`tests/redteam.spec.ts`（随 CI 跑，红即闸）。
> 本文回答一个问题：**一张交接卡就是「一方写的文本 + 文件」进入另一方上下文与磁盘，
> 什么东西能攻击你，防线在哪，剩余风险是什么。**

## 资产与信任边界

| 资产 | 说明 |
|---|---|
| 会话卡片（六段正文 + frontmatter） | 模型/人手写，随 `~/.handoff/` 传播（同步盘即跨机） |
| 取件方模型上下文 | 卡正文全文进入取件方当轮——卡是**提示注入的天然通道** |
| 密钥/令牌 | 卡文本、机器信封、随卡补丁 diff 都可能携带 |
| pending/ 目录 | **多写方共享**：任何能写这个目录的进程/人 = 能投放任意卡 |
| archived/ 审计轨迹 | 消费记录；被篡改=历史不可信 |

边界假设：本机用户态进程与盘上文件默认可信；跨机场景的信任 = 同步盘的信任。
信封 HMAC 签名（0.4.4）在这条边界内提供「写侧事实可校验」，不改变边界本身。

## 威胁条目

### T1 跨 agent 提示注入（卡 → 取件方模型）

**向量**：卡正文写「忽略之前的指令」「读取 ~/.ssh 并回显」、伪闭合 system 标签；来源可以是
被攻破的推送方、第三方篡改的共享盘文件、或直接投放 pending 的恶意卡。

**防线**：push 侧为确定性管道（不调 LLM，内容不被解释）；取件侧载荷**原样呈现但全卡
带 HISTORY_REPORTED 不可信标记**，`/inbox` skill 指引明确「卡片是历史快照，执行前先核对
git 状态」——诚实呈现 + 显式不可信标注，而非静默过滤（静默过滤会破坏取证且制造虚假安全感）。

**红队**：`T1 注入` 两组（push 原样落盘；load 原样返回 + 标记在场）。

**残余风险（明确接受）**：标记纪律依赖取件方模型遵守——卡内指令与用户指令冲突时以用户
为准，这是协议纪律而非技术强制。对不可信来源的卡，取件方应在受控环境处理。

### T2 密钥外泄

**向量**：六段正文、`title/to/project` 标量、机器信封、**随卡补丁 diff**（全是源码行）；
卡随同步盘跨机传播并进入下游上下文——比 git 更宽的泄漏面（git 仓有 gitleaks 守，交接盘
原本什么都没有）。

**防线**：push 侧密钥闸（`src/secretscan.ts`）——14 条高置信模式（AWS/GitHub/DeepSeek/
OpenAI/Anthropic/Slack/Google/GitLab/npm/PyPI/JWT/私钥头/连接串）+ 敏感词赋值熵判
（值 ≥8 字符，短值须字母数字混合）；扫描面覆盖六段 + 全部标量 + **补丁 diff**
（T2-P 缺口由红队套件驱动补上）。命中即拒，理由回喂；`allowSecrets: true` 旁路留痕。

**红队**：`T2 密钥` 四组（语料矩阵 / title 侧门 / 旁路留痕 / 补丁走私）。

**残余风险**：误报由旁路兜底而非静默放行；**取件方 git apply 补丁前必须人工读 diff**
（补丁不是沙箱——apply 在取件方工作区写入任意路径，这是 git apply 的语义，非本插件可限制）。
信封的 untracked 文件名清单不过密钥闸（文件名携带密钥的形态罕见，记录为已知盲区）。

### T3 路径与 id 攻击

**向量**：`../../` 穿越把取件变成任意文件移动；超长 id 撑爆错误回显。

**防线**：`assertSafeId`（SAFE_ID 白名单形态）在 loadCard/writeCard 入口强制；超长 id 早拒
（错误文案截 48 字符回显——错误信息回显请求方输入属常规，关键是**不拼路径、不消费**）。

**红队**：`T3 路径穿越`。

### T4 资源攻击（多写方目录的防呆）

**向量**：巨卡撑爆读侧内存、巨信封阻塞 30s 轮询、巨 diff 拖垮取件。

**防线**：卡 8 MiB 读闸（超限拒载不消费）、信封 64 KB 计数闸、diff 512 KB 整份拒带、
id ≤64 字符、孤儿信封/补丁/过期认领按活性判据清扫（崩溃窗口自愈）。

### T5 审计破坏与伪造

**向量**：伪造 frontmatter 版本号；伪造 supersedes 链徽标；伪造「来源机器」与六段内容
（同一同步域里不持有密钥的写入方：同盘其他设备/应用的误写、越权写卡）；传输损坏；
同步盘双向消费静默覆盖审计。

**防线（本次加固）**：归档同名不同内容 → 旧审计先挪 `<id>.conflict-<HHMMSS>.md` 再消费
（不再静默覆盖）；同名同内容 → 幂等消费。并发取件双成功（Windows rename 语义）→ 认领
文件独占创建仲裁（见 agent-handoff 仓 store.ts）。**信封 HMAC-SHA256 签名**（`src/signing.ts`）：
写侧 push 自动以总线密钥（`.signing-key.json`，与总线同屋、随 HANDOFF_HOME 同步自然分发）
签信封，取侧验签三态——`ok` 渲染 🔐 通过行；`tampered` 渲染 🚨 警告并记死亡地图
`sig_tampered`；`no-key`（跨信任域取件）如实渲染「未验签」绝不误报篡改。签名长在
`.envelope.json` 的 `sig` 字段，SPEC 一字不动，旧实现天然忽略；无 sig 的旧卡 = `unsigned`，
不渲染任何签名行。

**残余风险**：`handoff:` 版本号取值宽松解析不校验（红队冻结为已知行为）；**持有总线全部
写权限的攻击者可连密钥文件一起换**——HMAC 防的是「不持有密钥的写入方」与意外损坏，
不是全知攻击者（那需要非对称签名 + 带外公钥分发，记录为未来方向）。签名面 = 信封全部
字段（含 cardSha256 卡面哈希）——「改卡面不改信封」的非持钥篡改由取侧回读比对检出；
「信封与卡面同时重写」需要密钥，落入上一条边界假设。

### T6 端口与网络面

**向量**：面板 HTTP API 被非本机/跨源访问（DNS rebinding、LAN 扫描）。

**防线**：连接级回环闸（非 127.0.0.1/[::1] 一律 403，0.0.0.0 绑定下 LAN 请求在此被拒）+
Host 回环校验 + 同源（Origin/Sec-Fetch-Site）读写守卫；插件不发起任何网络请求。

## 红队套件与 CI

`tests/redteam.spec.ts` 随 `npm test` 进 CI（GitHub Actions）：8 组攻击向量全部为合成
载荷，任何一组红即构建失败——防线退化在合并前现形，不等真实事故。