第 10 章：安全考量
本章描述 CAP 协议的威胁模型、已知风险和缓解措施。本章为非规范性内容（不使用 MUST/SHOULD/MAY 等关键词），但本章描述的风险和缓解措施 SHOULD 被实现者认真对待。
10.1 威胁模型
CAP 协议的威胁模型基于以下假设和考量。
10.1.1 信任假设
CAP 协议假定以下实体可信：
- Registration_Authority：信任锚，其密钥分发能力是协议安全性的基础
- 预置的信任锚密钥：终端制造或部署时预置的 RA 公钥
- 终端的安全存储：用于存储 Verification_Key 和本地签名密钥的硬件/软件安全模块
CAP 协议不假定以下实体可信：
- Fay 实例：Fay 可能被恶意编程或被攻击者控制
- iFay_Runtime：可能存在 bug 或被替换
- 网络通道：可能被监听、篡改、阻断
- 未授权的应用进程：终端上的其他进程可能尝试绕过 CAP 控制
10.1.2 攻击者能力
考虑以下能力的攻击者：
| 攻击者类型 | 能力 |
|---|---|
| 网络攻击者 | 监听、篡改、阻断、重放网络消息 |
| 流氓 Fay | 持有合法凭证但行为异常 |
| 凭证窃取者 | 通过其他渠道获得他人凭证副本 |
| 内部威胁 | Descriptor_Issuer 自身被攻陷 |
| 物理攻击者 | 物理接触终端设备 |
CAP 协议针对前 4 种攻击者提供保护机制，对物理攻击者的防护依赖于终端的硬件安全机制（不在协议层面解决）。
10.2 已知风险与缓解
10.2.1 凭证泄露风险
风险：Authorization_Descriptor 文件被攻击者窃取后，可在持有凭证的 Fay 之外的实体上提交给终端。
缓解措施：
- Authorization_Descriptor 的
subject_fay_id绑定到具体 Fay，终端在 §3.3.2 第 4 步验证主体匹配 - 攻击者必须同时控制目标 Fay 的运行时（即攻击 Fay 自身），凭证泄露本身不足以构成攻击
- 凭证存储 MUST 加密（§3.2.3），防止离线提取
- Trusted_Ticket 通过短有效期（最长 7 天）和实时撤销查询限制损害窗口
残余风险：若攻击者完全控制 Fay 进程（包括其密钥），凭证仍可被滥用。本协议不能解决"已被完全攻陷的 Fay"的问题——这是更上层的 Fay 完整性保护问题。
10.2.2 撤销延迟风险
风险：凭证被撤销后到撤销声明送达终端之间存在延迟窗口，期间被撤销的凭证仍能通过校验。
缓解措施：
- 终端持续联网时，撤销声明默认在 1 小时内同步（§3.4.5）
- 使用 Trusted_Ticket 时，终端 MAY 通过实时撤销查询消除延迟（§4.3.2 第 5 步）
- 凭证有效期上限（90 天离线 / 7 天在线）限制最长延迟
- 签发方在高敏感场景 SHOULD 使用更短的有效期（如 1 天）
残余风险：长期离线的终端可能在数天甚至更长时间内接受已被撤销的凭证。这是离线授权机制的固有权衡——在可用性与撤销时效性之间选择了可用性优先。
10.2.3 重放攻击风险
风险：攻击者捕获合法的协议消息后重放给终端。
缓解措施：
- AuthRequest 包含
message_id（UUID v7，时间相关），终端 MAY 维护短期已见 ID 缓存以拒绝重放 - Heartbeat 的
sequence_number单调递增，重放被检测（§5.4.2） - TLS 通道提供基础的重放保护（每个 TLS 会话独立）
- 撤销声明的
revocation_id唯一，重放无效
残余风险：在 TLS 会话内部，攻击者若已突破 TLS 加密则可重放消息。这是 TLS 层面的威胁，不是 CAP 协议的范围。
10.2.4 时钟攻击风险
风险：攻击者通过修改终端时钟绕过有效期检查或暴露时钟相关漏洞。
缓解措施：
- 终端时钟来源应可信（系统时钟、NTP 同步）
- §3.6 定义时钟漂移检测：显著时钟跳变时拒绝校验
- 离线时长过久的终端 SHOULD 提示用户重新同步时钟
残余风险：物理控制终端的攻击者可能能够操纵时钟。物理安全是终端硬件的责任。
10.2.5 Descriptor_Issuer 攻陷风险
风险：Descriptor_Issuer 被攻击者完全控制，可签发任意凭证。
缓解措施：
- §8.6.2 定义紧急密钥撤销机制
- Registration_Authority 可通过撤销 Descriptor_Issuer 的 Verification_Key 使其所有签发凭证失效
- 终端在收到 Verification_Key 撤销后立即终止相关 Session（§5.5）
- 信任根（Registration_Authority）的安全性是关键——其攻陷将导致整个信任链崩溃
残余风险：在 Verification_Key 撤销前已经签发的凭证可能被滥用。撤销窗口期不可避免。
10.2.6 资源耗尽攻击风险
风险：恶意 Fay 通过大量请求耗尽终端资源（连接数、Session 数、存储）。
缓解措施：
- §5.8 定义 Session 数量限制
- §3.2.3 定义凭证存储上限
- 心跳超时回收失效 Session 释放资源
- 终端 SHOULD 实施基于 fay_id 的速率限制（在 §7.4.2 频率约束之外）
残余风险：合法签发的多个凭证可能合谋耗尽资源。终端策略应限制单一 Fay 的总配额。
10.2.7 交接竞态风险
风险：攻击者利用交接流程的中间状态（如 §6.5.1 [T2] 的"无活跃 Session"状态）抢占资源。
缓解措施：
- 交接过程中资源处于预占状态（
handover_pending），不接受其他 Session 请求（§6.5.3） - 即使 [T2] 与 [T3] 之间出现失败，资源也明确进入"空闲"状态，由后续请求公平竞争（§6.5.2）
- 交接超时使资源不会长期处于 pending 状态
残余风险：在 [T3]–[T4] 失败的极端情况下，原 Fay 的会话已不可恢复——需要重新发起 AuthRequest。这是必要的代价，避免引入"自动恢复"带来的更复杂的安全分析。
10.2.8 降级攻击风险
风险：攻击者通过阻断终端与 Ticket_Issuer 的连接，迫使终端进入降级模式（§4.5），从而绕过实时撤销检查。
缓解措施：
- 终端在降级模式下默认拒绝接受新的 Trusted_Ticket
- 已转换为本地 Authorization_Descriptor 的票据的有效期短（最长 7 天）
- 终端 SHOULD 提示 iFay_Runtime 当前处于降级模式，使敏感操作可主动拒绝
残余风险：降级期间已转换的本地凭证仍可被使用。这是离线优先设计的固有取舍。
10.2.9 侧信道攻击风险
风险：通过观察 CAP 协议响应时间或错误码细节推断敏感信息（如有效凭证存在性）。
缓解措施：
- 错误码不暴露内部细节（§9.9）
- 实现 SHOULD 在校验失败的不同分支保持相近的响应时间
- 不在错误响应中泄露密钥指纹、内部 ID 等
残余风险：完全消除侧信道攻击是极困难的。本协议层面提供基础措施，深度防御依赖实现质量。
10.3 部署安全建议
实现 CAP 协议的部署者应考虑以下安全实践：
10.3.1 密钥管理
- 私钥存储使用硬件安全模块（HSM、TPM、Secure Enclave）
- 密钥轮换周期不长于 90 天（终端本地密钥）/ 365 天（Issuer 密钥）
- 建立密钥泄露应急响应流程
- 关键签名操作要求多人审批或硬件 PIN
10.3.2 监控与审计
- 记录所有授权校验失败事件并报警
- 监控异常的撤销请求频率（可能指示 Descriptor_Issuer 被攻陷）
- 审计日志使用单独的持久化存储，防篡改
- 对高敏感资源（configure 模式、
require_human_confirmation约束）的所有操作完整审计
10.3.3 终端硬化
- 启用 OS 强制访问控制（SELinux、AppArmor）
- 使用沙箱隔离 iFay_Runtime 与其他进程
- 关闭不必要的系统服务，减少攻击面
- 定期更新系统补丁
10.3.4 网络分段
- Registration_Authority 的部署网络与公网隔离
- Descriptor_Issuer 部署在受控环境
- 终端到 Issuer 的通信限制在必要的端口/协议
- 实施 mTLS（双向认证）保护关键通信
10.4 协议局限性
本规范明确不解决以下安全问题：
- Fay 完整性：CAP 协议假定 Fay 实例自身的代码和行为完整性由其他机制保证（如代码签名、运行时完整性度量）
- 物理安全：终端被物理攻击者完全控制时，软件层面无法提供保护
- 审计日志格式：v1 不规范化审计日志格式（蓝图 §3.2 排除项）
- 跨终端身份联邦：v1 不支持跨终端的统一身份管理，每个终端独立信任 Registration_Authority
10.5 后续版本的安全演进
未来版本（v2+）计划引入的安全增强：
- 分布式撤销共识（蓝图 §3.2 排除项）
- 审计日志标准化格式（蓝图 §3.2 排除项）
- 抗量子密码学算法（追踪 NIST PQC 标准）
- 零信任原则的更深整合
- 形式化的协议安全性证明