4. 身份认证与访问控制：OTA 安全的守门人
身份认证和访问控制，说白了就是解决两个问题：“你是谁”和“你能干什么”。在 OTA 场景里，这两个问题直接关系到车能不能安全地收到更新、会不会被恶意刷写。
我参与过好几个 OTA 项目，早期有些方案对身份认证不够重视，结果测试阶段就发现模拟攻击能轻易伪造更新请求。嗯，从那以后，我对这块的要求就特别苛刻。
4.1 PKI 体系：信任的基石
PKI（公钥基础设施）是 OTA 安全的根基。没有 PKI，你没法证明“这个包是官方发的”，也没法证明“这辆车是合法的”。
在 OTA 里，PKI 主要干三件事：
- 证书签发：给车端、云端、甚至每个 ECU 发数字证书。
- 证书验证：通信前先验证书，确认对方身份。
- 密钥管理：公钥分发、私钥安全存储、证书吊销。
我个人习惯把 PKI 体系分成两层：
| 层级 | 角色 | 典型证书 |
|---|---|---|
| 根 CA | 信任锚点，离线存储 | 自签名根证书 |
| 二级 CA | 签发业务证书 | OTA 服务 CA、设备 CA |
| 终端实体 | 车端、云端、ECU | 设备证书、代码签名证书 |
关键点：根 CA 必须离线。我见过有项目把根 CA 私钥放在联网服务器上，结果被拖库。那真是灾难性的。
4.2 设备身份证书管理：从出生到报废
每辆车、每个 ECU 都应该有一个唯一的数字身份。这个身份通常以证书形式存在。
证书的生命周期管理，我总结为四个阶段：
- 证书签发：在产线或首次激活时，为设备生成密钥对并签发证书。
- 证书分发：将证书安全写入设备的安全存储区（如 HSM、TEE）。
- 证书更新：证书快过期时，通过 OTA 或线下方式更新。
- 证书吊销：设备报废或密钥泄露时，吊销证书并同步到 CRL（证书吊销列表）。
避坑指南：我曾经遇到一个项目，证书私钥直接写在文件系统里，没有用 HSM 保护。结果测试时用简单的文件读取攻击就拿到了私钥。记住：私钥必须硬件隔离。
证书格式方面，目前主流是 X.509 v3。我建议在证书扩展域里加入设备专属信息，比如 VIN 号、ECU 硬件版本，这样验证时可以做到更细粒度的控制。
4.3 基于角色的访问控制（RBAC）
RBAC 在 OTA 系统里非常实用。你想想看，一个 OTA 平台有运维人员、审核人员、开发人员、第三方服务商，总不能所有人都能签发更新包吧？
我一般这样设计角色：
| 角色 | 权限范围 | 典型操作 |
|---|---|---|
| 超级管理员 | 全平台 | 用户管理、审计日志查看 |
| OTA 管理员 | OTA 策略配置 | 创建升级任务、设置灰度规则 |
| 审核员 | 包审核 | 签名验证、安全扫描、审批 |
| 运维人员 | 车辆管理 | 查看车辆状态、触发升级 |
| 第三方开发者 | 应用上传 | 上传应用包、查看自己应用状态 |
RBAC 的核心是“最小权限原则”。每个角色只能干自己分内的事。审核员不能直接签发更新，运维人员不能修改安全策略。这些在 ISO 21434 里也有明确要求。
4.4 令牌机制：JWT 与 OAuth 2.0
车端和云端通信时，不能每次请求都传证书。太慢了，而且证书校验开销大。这时候就需要令牌机制。
JWT（JSON Web Token） 是我在 OTA 项目里最常用的方案。它本质上是一个自包含的令牌，里面携带了用户身份和权限信息。
一个典型的 JWT 长这样：
// Header
{
"alg": "RS256",
"typ": "JWT"
}
// Payload
{
"sub": "vehicle_vin_123456",
"role": "ecu_ota_client",
"exp": 1718000000,
"iat": 1717996400,
"jti": "unique-token-id-001"
}
// Signature
// 使用私钥对 header + payload 签名车端拿到 JWT 后，用云端公钥验签。验签通过就信任令牌里的身份和权限。这样就不需要每次请求都查数据库了。
OAuth 2.0 更多用在 OTA 管理平台的人机交互场景。比如运维人员登录 OTA 后台，通过 OAuth 2.0 获取访问令牌，然后调用 API。
我建议的 OTA 令牌架构：
- 车端：使用 JWT，短期有效（比如 1 小时），配合 refresh token 续期。
- 管理端：使用 OAuth 2.0 + JWT，支持多种授权模式（授权码、客户端凭证）。
- 服务间通信：使用 mTLS + JWT，双重认证。
个人经验：JWT 的 exp 时间别设太长。我见过有项目设了 7 天有效期，结果令牌泄露后攻击者能浪一周。建议车端 JWT 有效期不超过 2 小时，配合 refresh token 实现无感续期。
4.5 整体架构：一张图说清楚
下面这张图展示了身份认证与访问控制的核心流程。从设备注册到令牌发放，再到 API 访问，每一步都有安全控制。
这张图里，车端先通过设备证书向令牌服务申请 JWT，然后携带 JWT 访问 OTA API。API 网关验签后，再根据 RBAC 策略判断是否有权限。管理端则走 OAuth 2.0 流程，获取令牌后调用业务接口。
4.6 合规要点：ISO 21434 怎么说
ISO 21434 对身份认证和访问控制有明确要求。我挑几个重点：
- 唯一身份标识：每个 ECU 必须有唯一标识，且与证书绑定。
- 密钥安全存储：私钥必须存储在硬件安全模块（HSM）或可信执行环境（TEE）中。
- 最小权限：每个角色只能访问完成工作所需的最小资源。
- 审计日志：所有认证和授权操作必须记录日志，且日志不可篡改。
- 证书吊销：必须支持 CRL 或 OCSP，及时吊销泄露的证书。
总结一下：身份认证和访问控制不是单一技术，而是一套组合拳。PKI 提供信任基础，证书管理保证身份唯一，RBAC 控制权限粒度，JWT/OAuth 2.0 实现高效认证。四者缺一不可。
嗯，这块内容比较多，但都是实战中必须啃下来的硬骨头。下次你设计 OTA 系统时，不妨从这张架构图开始，一步步把每个环节的安全控制做扎实。