核心策略（现状）：
现状第三层采用“ 端侧校验为主、服务端受控下载为辅 ”的工业常见分工：
- 车机端（执行层） ：负责固件完整性校验、防降级、回滚与安装状态机闭环
- 服务端（传输与收敛层） ：负责下载对象绑定、传输一致性控制、Range 边界校验、请求级鉴权（第二层能力），确保端侧拿到“正确对象的正确字节流”
因此，现状第三层并非缺失，而是其核心能力主要落在设备端侧。服务端当前体现的是第三层中的“数据传输安全与一致性支撑能力”，而不是完整性校验本体。
现状定位
在现状架构中，数据安全层不应被理解为“服务端必须完成内容校验”。第三层在工业实践中通常以端侧为核心，原因在于：
- 安装发生在端上，最终风险（变砖/回滚/降级）由端侧状态机承担
- 端侧最接近落地介质（eMMC/UFS），可在安装前做最终复核
- 服务端即便校验过，也无法替代端侧“下载后、安装前”的防篡改检查
因此，现状第三层的准确自评为：
- 端侧已形成“完整性校验 + 防降级 + 回滚”的安全闭环（车机端）
- 服务端侧形成“受控下载 + 传输一致性 + Range 边界控制”的支撑闭环
- 两者组合构成现状的数据安全层
现状的可信边界（设备端侧 vs 服务端的边界）
现状第三层的可信边界需要按“服务端负责什么、端侧负责什么”来描述。
服务端侧
服务端当前严格校验和约束的输入包括：
- X-VIN
- X-Timestamp
- X-Signature
- challengeCode
- authUuid
- Range
这些输入主要对应以下控制维度：
- 身份输入
- 请求时效
- 动态签名上下文
- 下载对象映射
- 分片下载边界
服务端侧的核心职责在于：
- 判断请求是否合法，即完成时效、签名与挑战上下文校验
- 判断请求是否指向合法资源，即完成
authUuid -> 下载对象绑定 - 判断请求是否位于允许的分片范围内，即完成 Range 边界控制并对非法请求返回
416
这部分本质上属于“传输一致性与边界控制”，其目标是为端侧完整性校验提供稳定、正确的输入。
设备端侧边界
设备端侧是第三层的核心执行点，其可信边界主要包括：
- 下载完成后的固件完整性校验
- 安装前的再次复核
- 防降级策略执行
- 安装失败后的回滚状态机
这部分能力决定“拿到的字节流是否可信、是否允许安装、失败后如何恢复”，通常不直接体现在服务端实现中。
服务端侧（现状）已具备的第三层支撑能力
尽管完整性校验在设备端侧执行，服务端仍承担重要的第三层支撑职责，用于减少端侧遭遇错误对象、错误分片和异常字节流的概率，并提升下载链路在弱网场景下的可恢复性。
下载对象绑定
下载前，系统会根据 authUuid 查询认证记录、品牌、项目和下载文件路径，并要求最终下载对象唯一存在。该能力的作用是先确定“当前请求对应的到底是哪一个文件”，属于第三层的数据面前置收敛条件。
文件/对象存在性检查
无论采用本地文件模式还是 GCS 存储模式，系统在出流前都会检查目标对象是否存在，再进入实际出流流程。这属于基础但必要的数据面正确性校验。
- 本地文件模式：检查
File.exists()且目标不能为目录，见downloadSoftware与downloadSoftware(HttpServletResponse) - GCS 模式：检查
Blob是否存在，见downloadSoftwareStorage
该能力保证系统不会在目标对象不存在时继续输出伪响应。
Range 边界控制
服务端对 Range 起止位置与文件大小关系做严格校验，是现状第三层服务端支撑能力中最完整的一部分，也是弱网断点续传场景下的关键控制点。
- 校验规则包括：
- 起始位置不能小于
0 - 起始位置不能超过文件大小
- 结束位置超出文件大小时截断到文件末尾
- 起始位置不能大于结束位置
- 非法 Range 直接返回
416 REQUESTED_RANGE_NOT_SATISFIABLE
相关逻辑见：
- 本地异步下载：
downloadSoftware - GCS 下载：
downloadSoftwareStorage - 传统下载头部准备：
prepareHttpHeaders
该能力保证系统不会允许明显越界的 Range 读取，从而降低错误拼接、异常读取和部分资源滥用风险。
传输元数据一致性输出
当前服务端在出流前，会基于真实文件或真实对象大小生成以下响应头：
Content-LengthContent-RangeAccept-Ranges
相关逻辑见：
prepareHttpHeadersAsyncprepareHttpHeadersAsyncStorage
这说明当前服务端输出的下载元数据来源于实际存储对象计算结果，而不是静态硬编码。该能力保证响应头与实际对象一致，但不等价于经过签名保护的可信元数据。
现状下的可信锚点与可证明性问题
现状第三层的基本闭环已经成立，但其工业可审计性与可信锚点表达仍依赖端侧校验依据是否具备权威来源与可证明性。
端侧校验依据的权威来源
设备端侧在执行完整性校验时，需要能够明确并被审计证明以下问题：
- 校验依据来自普通接口返回的
hash/size，还是来自签名保护的manifest - 校验依据是否可能被中间链路篡改
- 校验失败时如何区分“对象被替换”等攻击行为与“弱网损坏”等传输故障
如果端侧校验依据尚未采用签名保护的 manifest，则现状第三层依然可用，但可信锚点表达偏弱。签名 manifest + 端侧校验 是最典型、最轻量的增强方向。
防降级与回滚策略的可追溯性
设备端侧虽然已经具备防降级与回滚能力，但仍建议在文档中明确以下内容：
- 防降级阈值如何发布与更新
- 是否支持版本撤回或黑名单机制
- 回滚触发条件与回滚边界
- 是否存在可关联单次升级任务全生命周期的审计链路
这里的重点不是“要不要做”，而是“如何在审计与合规要求下做到可证明”。
当前能力边界
现状第三层的本质能力边界可以概括为：
- 服务端保证“把正确对象的正确分片稳定传输出去”
- 端侧保证“拿到的字节流是否可信、是否允许安装、失败后如何回滚”
因此，现状第三层的关键闭环并非缺失，而是“端侧主导、服务端支撑”。
风险边界
即便端侧完整性校验已经实现，仍建议在文档中明确以下风险边界：
- 对象被替换风险：若端侧校验依据不具备签名保护，服务端即便实现受控下载，也无法证明“当前对象仍是发布时的那一份”
- 元数据可信度风险：若端侧依赖未签名的
size/hash字段，可能因篡改或配置错误导致误判 - 取证与审计风险：若端侧校验失败、降级阻断或回滚触发未回传并与升级任务关联，则难以证明“每次交互均合法且可追溯”
层内收敛结果
现状第三层可收敛为“端侧闭环 + 服务端支撑”两部分：
- 设备端侧闭环能力：完整性校验、防降级、回滚、安装状态机
- 服务端支撑能力：下载对象绑定、文件存在性检查、Range 边界控制、传输元数据一致性输出
两者组合，构成现状的数据安全层。
| 机制 | 实现位置 | 当前状态 | 评价 |
|---|---|---|---|
| 下载对象绑定 | 服务端 + DB | 已实现 | 第三层前置条件（资源收敛），非完整性校验本体 |
| 文件存在性检查 | 服务端（本地文件/GCS 对象） | 已实现 | 基础能力 |
| Range 合法性校验 | 服务端 | 已实现 | 现状里较完整的一块（弱网续传关键能力） |
| 输出元数据一致性 | 服务端 | 已实现 | 服务端一致性输出，不等于签名可信元数据 |
| 文件本体 hash/签名校验 | 设备端 | 已实现 | 第三层核心执行点（由设备端侧安装前校验） |
| manifest 可信锚点 | 服务端/端侧协作 | 服务端未形成；端侧校验基准需明确 | 典型增强点：签名 manifest + 端侧校验 + 审计回传 |
| 防降级 | 设备端 | 已实现 | 需文档化阈值来源、撤回机制与可证明性 |
| 安装前可信状态 | 设备端 | 已实现 | 需文档化状态机与关键审计点 |
增强方向
现状 OTA 数据安全层已具备“安装前端侧校验 + 服务端数据面一致性支撑”的基本闭环，但尚未形成以签名 manifest 为核心的跨链路统一可信锚点。
当前分工如下：
- 车机端：在安装前完成固件总包完整性校验，并执行防降级与回滚策略，保证安装安全与可恢复性
- 服务端：承担数据传输与一致性控制职责，通过下载对象绑定、文件存在性检查、Range 边界校验与传输元数据一致性输出，保障端侧在弱网与断点续传场景下稳定获取目标固件字节流
在此基础上，建议后续优先采用以下轻量增强方向：
- 引入签名保护的
manifest作为端侧校验依据 - 保留端侧作为完整性校验与安装决策的最终执行点
- 将端侧校验失败、降级阻断、回滚触发等关键事件回传服务端
- 建立可关联升级任务全生命周期的审计链路
通过上述增强，可进一步提升跨链路篡改防护能力、可信锚点表达能力与合规可证明性。
