专题：签名 Manifest（Signed Manifest）

定义与定位

Manifest 是“固件内容的可信说明书”，用于描述“要下载并安装的目标固件到底是什么”。

签名 Manifest 指：对 manifest 的关键字段进行密码学签名，使其具备不可篡改性与可验证来源。

定位关系（HMAC的接口签名和Manifest签名的区别）

• 请求签名（之前介绍的HMAC + challengeCode + timestamp 或 challengeToken自包含方案）：解决的是“这次请求是否合法、是谁发起的、有没有被篡改”（访问控制层：二层）
• 签名 manifest：解决“下载到的固件内容是不是官方发布的那一份、是否允许安装”（数据安全层：三层）

⚠️关键认知： 访问控制保证“能不能拿到文件”，manifest 保证“拿到的文件是不是对的”。

为什么必须引入签名 Manifest（威胁模型）

在 OTA 体系中，以下攻击/故障，在前两层(安全防护层and访问控制层)是无法覆盖的，第三层数据安全层必须补：

• 对象存储内容替换 ：GCS 对象被替换，signed URL 仍可用；访问控制仍通过，但内容已变。
• 端点本地篡改 ：车机下载完成后、安装前，文件被本地恶意 App 或异常逻辑替换。
• 降级/回滚滥用 ：旧版本仍然“合法可下载”，但包含已知漏洞。
• 元数据欺骗 ：Content-Length/文件大小与真实内容不一致，触发异常资源消耗或安装失败。
• 弱网局部损坏 ：下载中断/续传导致局部损坏，若没有内容校验可能带毒进入安装。

签名 manifest 的目标不是“证明固件无恶意逻辑”（供应链问题），而是证明：
固件的字节内容与官方发布的目标版本一致，且当前策略允许安装。

工业主线：签谁？签什么？谁验证？

签谁

• 发布侧 签：CI/CD 或签名服务（建议 HSM/离线保护）
• 车机侧 验：只持有公钥/证书链，不持有签名私钥

推荐： 非对称签名（Ed25519/ECDSA/RSA-PSS）。

原因：车机被攻破也拿不到签名能力；对称 HMAC 一旦密钥泄露等价于“攻击者可签固件”。

签什么（最小字段集）

第一阶段务实版 manifest 建议最小字段如下（够用且体积小）：

• packageId ：固件唯一标识（或 imageId）。
• version ：目标版本。
• target ：适配范围（车型/项目/ECU/硬件版本约束）。
• fileName ：固件文件名。
• fileSize ：文件大小（必须纳入签名）。
• sha256 ：整包哈希（必须纳入签名）。
• minAllowedVersion ：最低允许版本（防降级）。
• releaseTime ：发布时间或生效时间。
• signature ：对上述字段的签名值。
• sigKeyId ：签名 key 标识（支持轮换与多 key）。

可选增强字段（第二阶段再引入）：

• chunkSize/chunkCount/chunkHashes （提升弱网恢复能力）。

校验闭环（车机侧必须做的最小动作）

签名 manifest 的“闭环”必须落在车机安装前，否则等于白做。

推荐校验时序（第一阶段务实版）

安全默认

• manifest 签名失败：拒绝下载/安装。
• hash 不匹配：拒绝安装并清理缓存。
• size 不匹配：拒绝安装（区分攻击与故障，记录审计事件）。

防降级（必须写清楚的工业条款）

很多系统只校验 hash，但审计更关心： 旧版本能不能被合法安装 。

manifest 建议至少包含并签名：

• minAllowedVersion （或 minSecurityPatchLevel ）。
• rollbackAllowed （是否允许回滚）。
• rollbackWindow （允许回滚到哪些版本集合/时间窗）。

车机策略（示例）：

• 若 targetVersion < currentVersion 且 rollbackAllowed != true ：拒绝。
• 若 targetVersion < minAllowedVersion ：拒绝。
• 若该版本被撤回（denylist / revoked）：拒绝。

与 challengeCode/challengeToken体系如何衔接（推荐契约）

challengeCode + HMAC 是“访问控制层”较成熟的一套方案。签名 manifest 可以作为第三层能力，不破坏现有链路。

建议衔接方式：

• 检查更新/版本信息接口 ：返回“是否有更新 + manifest 的获取方式（URL 或 manifestId）”
• challenge/send ：仍用于短期授权上下文（谁能拿下载权限）
• 下载接口 ：可以继续保留（服务端出流）或演进为返回 signed URL
• manifest 获取 ：建议独立接口或静态对象（但必须签名）

⚠️注意：manifest 不建议塞进 challengeCode（会膨胀、耦合、泄露影响面扩大）。
更稳的是：challenge 控制“能否获取 manifest/URL”，manifest 控制“内容是否可信”。

审计与可观测性（必备）

建议定义并记录以下安全事件（便于审计与线上定位）：

• MANIFEST_SIGNATURE_INVALID
• MANIFEST_EXPIRED （若含有效期策略）
• SIZE_MISMATCH
• HASH_MISMATCH
• DOWNGRADE_BLOCKED
• REVOKED_VERSION_BLOCKED

并要求事件必须能关联到：

• vin/deviceId
• upgradeTaskId （或 authUuid / downloadUuid）
• packageId/version
• 时间戳

演进路线（从轻到强，适配低端车机）

阶段1（强烈推荐先做）

• manifest 签名
• 整包 sha256 + size 校验
• 防降级策略

阶段2（弱网/大包场景增强）

• manifest 仍签一次
• 加 chunk hashes（不做每片独立签名）
• 支持断点续传局部修复

阶段3（更高安全等级）

• A/B + 安装状态机强化
• secure/verified boot（高端设备）
• 更强的密钥轮换与委派模型（可对齐 Uptane/TUF）

结论

签名 manifest 是 OTA 数据安全层的核心可信锚点。它通过对固件关键元数据（版本、大小、哈希、适配范围、防降级约束）进行签名，使车机能够在不可信传输与不可信存储环境下，独立验证“下载到的固件是否为官方发布且当前允许安装的目标版本”。该机制与访问控制层的请求签名互补：请求签名保证“谁能下载”，manifest 签名保证“下载到的是什么、能不能装”。在资源受限的车机环境中，务实落地应优先采用“签名 manifest + 整包 sha256 校验 + 防降级”的轻量闭环，再按弱网与包体规模逐步演进至分片校验与更强安装链路保护。