mirror of
https://github.com/clash-verge-rev/clash-verge-rev.git
synced 2026-11-12 13:42:08 +08:00
99 lines
6.7 KiB
Markdown
99 lines
6.7 KiB
Markdown
# CVD 订阅设备绑定：让订阅链接从“拿到就能用”升级为“登记设备后才能持续更新”
|
||
|
||
CVD（Clash Verge Device-binding Protocol）是一套面向订阅服务的设备绑定与加密下发方案。
|
||
|
||
过去，一条订阅链接一旦泄露，第三方可能直接把链接粘贴到浏览器或脚本中，持续拉取最新节点。CVD 在原有订阅流程上增加了设备公钥、加密响应和设备槽位管理：服务提供方可以识别设备、限制数量、解绑旧设备，并为每台设备单独加密订阅内容。
|
||
|
||
对于普通用户，它几乎不改变使用习惯；对于服务提供方，它提供了一条可以逐步上线的安全加固路径。
|
||
|
||
这不是给订阅链接换一个外壳，也不是再增加一组所有设备共享的验证密码。简单的链接变形、固定密码或单层加密，可以增加一点复制步骤，却很难回答更关键的问题：**到底是哪台设备在持续拉取订阅？已经登记了多少台设备？某一台设备是否应该被限制或解绑？**
|
||
|
||
CVD 直接把这些问题纳入协议流程。每个订阅 profile 使用独立设备密钥，服务端可以按公钥识别设备，并结合槽位上限、新设备注册频率限制、解绑和过期回收进行治理。它不是让订阅“看起来更难复制”，而是从技术实现上把持续获取订阅的门槛，从“拿到链接即可请求”提高到“登记设备后才能持续更新”。
|
||
|
||
## 一句话理解
|
||
|
||
传统订阅链接像一把可以反复复制的门禁卡。CVD 为它增加了“设备登记”：
|
||
|
||
1. Clash Verge 为订阅生成一对设备密钥。
|
||
2. 公钥随订阅请求发送给服务端，私钥只保存在本机系统钥匙串。
|
||
3. 服务端用公钥加密订阅内容，并按设备公钥记录槽位。
|
||
4. 只有持有本机私钥的设备才能解密本次订阅响应。
|
||
|
||
服务端还可以限制每个账号允许登记的设备数，并允许用户在控制台解绑旧设备。
|
||
|
||
## CVD 带来的价值
|
||
|
||
### 1. 提高订阅链接泄露后的滥用成本
|
||
|
||
仅拿到订阅 URL，不再等于可以用浏览器或通用 `curl` 持续复制明文节点。第三方必须实现 CVD 协议、登记设备并占用可见槽位，服务端也可以据此限制新设备注册频率、限制数量和吊销设备。
|
||
|
||
相比之下，共享密码只能证明“请求者知道密码”，无法区分不同设备；单纯加密订阅内容，如果缺少设备身份和服务端策略，也难以阻止泄露者反复请求。CVD 的重点不是堆叠一道验证，而是让每次持续访问都进入可识别、可计量、可治理的设备流程。
|
||
|
||
### 2. 每台设备独立加密下发
|
||
|
||
CVD 使用标准 HPKE（RFC 9180）方案。服务端针对设备公钥加密订阅内容，不同设备拿到的密文不同。协议采用 X25519、HKDF-SHA256，以及 ChaCha20-Poly1305 或 AES-256-GCM 等成熟算法组合。
|
||
|
||
### 3. 私钥留在系统钥匙串
|
||
|
||
设备私钥不会写入普通配置文件，也不会随应用备份导出。它由 macOS Keychain、Windows Credential Manager 或 Linux Secret Service 等系统能力保存。服务端只接收公钥，不接触用户私钥。
|
||
|
||
### 4. 平滑兼容现有订阅生态
|
||
|
||
CVD 采用渐进启用方式：
|
||
|
||
- 服务端尚未支持 CVD 时，仍可按原有明文订阅流程工作。
|
||
- 服务端支持 CVD 后，可以先灰度测试，再按套餐或用户组启用设备限制。
|
||
- 新建、导入订阅和手动更新会自动尝试登记；已登记订阅会在后续更新中复用同一设备公钥。
|
||
- 尚未登记的旧订阅不会在静默自动更新时主动创建密钥，避免系统启动时出现不必要的钥匙串授权弹窗。
|
||
|
||
### 5. 面向真实使用场景的自恢复设计
|
||
|
||
用户换机、重装系统或清理钥匙串后，本机私钥可能丢失。客户端会识别这种情况，并准备新的设备密钥用于后续更新。服务提供方配合提供设备解绑和过期回收后，用户可以恢复正常使用。
|
||
|
||
## 为什么说它更先进
|
||
|
||
CVD 没有重新发明一套私有加密算法，而是组合成熟标准与实际运营能力：
|
||
|
||
| 能力 | CVD 的做法 |
|
||
|------|------------|
|
||
| 设备身份 | 直接使用 X25519 公钥，无需额外 `device_id` |
|
||
| 订阅加密 | 使用 RFC 9180 HPKE 标准方案 |
|
||
| 私钥保护 | 仅保存在操作系统钥匙串 |
|
||
| 风险控制 | 服务端设备槽位、新设备注册频率限制、解绑和过期回收 |
|
||
| 上线方式 | 兼容未改造服务端，支持灰度启用 |
|
||
| 用户体验 | 自动协商、复用公钥、按需访问钥匙串 |
|
||
|
||
它与常见轻量方案的差异，不只体现在“有没有加密”，而在于是否形成完整闭环：
|
||
|
||
| 方案 | 能解决什么 | 仍然缺少什么 |
|
||
|------|------------|--------------|
|
||
| 更换或隐藏订阅链接 | 降低链接被随手发现的概率 | 链接一旦泄露，仍可持续复制和请求 |
|
||
| 增加共享验证密码 | 增加一道访问门槛 | 所有设备共享凭据，难以单独识别、限制或吊销 |
|
||
| 仅对订阅内容加密 | 避免直接看到明文 | 如果没有设备身份和槽位策略，仍难治理持续滥用 |
|
||
| **CVD 设备绑定** | **设备独立密钥、标准加密下发、槽位计量、新设备注册频率限制、解绑和回收** | **需要服务端按建议策略接入，才能发挥完整价值** |
|
||
|
||
这使 CVD 不只是“加一层加密”，而是把订阅分发升级为可识别、可计量、可限制、可吊销的设备级流程。它把安全能力落实到协议、客户端密钥管理和服务端运营策略三个层面，而不是停留在表面上的访问障碍。
|
||
|
||
## 服务提供方如何获得完整防护价值
|
||
|
||
仅返回加密响应还不够。服务端应同时实施以下策略：
|
||
|
||
1. 对受保护订阅拒绝不带 CVD 公钥的明文请求。
|
||
2. 按账号或套餐设置设备槽位上限。
|
||
3. 按账号和来源 IP 限制新公钥注册频率，防止攻击者刷满设备槽位。
|
||
4. 提供设备查看、解绑和长期未使用设备回收能力。
|
||
5. 保留 HTTPS，并确保 CDN、WAF 和反向代理透传 `X-CVD-*` 请求头。
|
||
|
||
完整的服务端字段、响应格式、测试向量和接入示例，请阅读 [CVD 服务端集成技术文档](./cvd-server-integration.md)。
|
||
|
||
## 需要诚实说明的边界
|
||
|
||
CVD 是安全加固方案，不是 DRM，也不承诺“订阅永远无法泄露”：
|
||
|
||
- 合法设备解密后仍能看到节点信息。
|
||
- 愿意专门开发工具的第三方仍可尝试登记设备。
|
||
- CVD 不能替代 HTTPS，也不负责解决中间人攻击、服务端投毒等问题。
|
||
- 真正的治理效果来自加密下发与服务端设备槽位、新设备注册频率限制、解绑策略的组合。
|
||
|
||
CVD 的目标很明确：让低成本、批量化、长期持续的订阅滥用变得更难，让服务提供方获得可执行的治理手段。
|