K2-04 · 控制、软件与标定 / 控制器硬件与安全
待认领listed
→
众筹中recruiting
→
已开课open · Course 售卖
一课题可并存多讲师版本
课程大纲
学完能做什么
- 能识别热管理域控在通信、诊断接口、OTA 上的典型攻击面
- 能说出车用网络安全 TARA 分析的基本方法与热管理相关的资产/威胁
- 能判断一套安全通信/安全启动方案是否覆盖了关键风险点
- 能理解 OTA 升级流程中与功能安全交叉的关键环节
内容大纲
- 车载网络安全体系与 TARA 方法
- ISO/SAE 21434 与整车网络安全管理体系（CSMS）概览
- 资产、威胁、攻击路径：TARA 方法的基本框架
- 热管理域控的资产识别：标定参数、诊断接口、通信报文、固件
- CAN 总线的先天弱点：无认证、无加密、广播式通信
- 热管理域的攻击面全集与入口侧第一道缓解
- 诊断口（OBD/UDS）越权访问篡改标定参数
- 总线报文欺骗：伪造压缩机/PTC 控制指令
- OTA 升级链路被劫持或固件被篡改
- 供应链环节（第三方模块固件）引入的风险
- OBD 座与内部总线之间的安全网关/诊断防火墙：只放行诊断报文、拦截任意应用帧，是「诊断口越权」与「总线注入」两条路径共用的第一道缓解；网关缺位或网关解锁不鉴权，等于把 OBD 座直接接到内部总线上
- 车云下行的远控指令链路：APP → 云端 → T-Box → 热管理域控（远程预降温、预约预热），与「总线报文欺骗」「诊断口越权」并列的第三类入口；链路长且跨主体，任一段的鉴权、时效窗口或指令幂等性缺失都会被利用
- 安全板载通信 SecOC：报文认证与抗重放
- 消息认证码（MAC/CMAC）与安全板载通信 SecOC
- 新鲜度值（Freshness Value）与抗重放：计数器型 vs 时间型的取舍、收发两端的同步与失同步恢复（SecOC 落地最麻烦的工程问题）、截断位数与总线负载的权衡；车云下行的远控指令（远程预降温、预约预热）还须设时效窗口，过期指令一律丢弃——否则重放一条「预热 60 分钟」就是可复现的能量耗尽攻击
- 硬件信任根、安全启动与密钥管理
- 硬件安全模块 HSM/安全元件 SE 的作用
- 安全启动（Secure Boot）与安全存储
- 密钥管理与证书体系概览
- OTA 升级安全链路与功能安全联动
- OTA 整体流程：云端签发 → 传输 → 校验 → 刷写 → 回滚
- 固件签名验证与版本防回滚机制
- 差分升级对执行器标定数据完整性的影响
- 升级过程中的安全状态与功能安全联动
- 两种「回滚」不是一回事：失败回滚（断电、传输中断时靠 A/B 双分区切换或本地备份镜像恢复，设备本地自动完成，不过下载包的版本比对闸门）vs 授权降级回退（云端重新下发旧软件版本，需签名授权且受安全版本 SVN 约束）；混谈二者就会写出「版本号必须更大才准刷」这类堵死灰度回退的判据
- 安全运营、事件响应与型式认证准入
- 总线层面的安全监控（IDS）应用概览
- 漏洞管理与安全事件响应流程
- 网络安全与功能安全两套流程如何协同不打架
- 国内外网络安全型式认证要求概览：UN R155 要求的 CSMS 证书与 UN R156 要求的 SUMS 证书是型式批准的前提条件（无证书不受理申请），中国对应的强制性国标是 GB 44495（整车信息安全）与 GB 44496（软件升级），具体实施安排按现行版本确认；本课只到概览与准入链定位，证书申请流程、备案口径与召回联动见 M4-08
关键公式
风险 = 攻击可行性 × 影响严重度（定性组合，非精确数值相乘）
TARA 风险确定的基本逻辑：可行性看时间/专业知识/设备/窗口机会，影响看安全/财务/运营/隐私
MAC = f_K(msg)
用共享密钥对报文做认证码计算（如 CMAC），接收端比对判断报文是否被篡改或伪造
仅当 v_new > v_current 才允许刷写
OTA 固件版本防回滚判据，避免被恶意降级到含已知漏洞的旧版本
加装 SecOC 认证 → 报文数据场占用增加，需重新核算 ρ_bus
安全认证不是无代价的，报文变长会挤占总线负载余量，要和实时性一起核算
MAC_trunc = f_K(DataID ‖ msg ‖ FV)，总线上传输 = 原报文 + 新鲜度低位 + 截断 MAC
SecOC 的完整构成：DataID 绑定报文身份，新鲜度值 FV（计数器型或时间型）把「本次、这一刻发出」纳入认证，才具备抗重放能力；截断 MAC 长度与 FV 低位位数要与总线负载余量一起权衡
关键概念
ISO/SAE 21434CSMSTARASecOCHSM/安全元件安全启动 Secure BootCMAC密钥管理差分升级防回滚攻击面安全事件响应新鲜度值 Freshness Value（抗重放）安全版本号 SVN 与防回滚计数器
推荐工具与标准
Vector CANoe（安全通信/SecOC 模块） 总线渗透测试工具（如 CAN 接口适配器配合脚本） OTA 云端管理平台 固件静态安全扫描工具
ISO/SAE 21434（道路车辆网络安全工程） GB 44495（汽车整车信息安全技术要求）/ GB 44496（汽车软件升级通用技术要求）——强制性国标，实施安排按现行版本确认 UN R155 / UN R156（网络安全管理体系与软件升级型式认证）
工程案例
某车型热管理域控的安全审计暴露出两条互不相干的攻击路径，正好用来练 TARA 的「路径与缓解一一对应」：路径 A——诊断口的安全访问（Security Access）种子-密钥算法全车系通用且可从刷写工具逆向，攻击者进入扩展会话后用 WriteDataByIdentifier 改写温度阈值标定、或用 InputOutputControlByIdentifier 覆写电池温度输入，缓解=一车一密、提高算法强度、限制尝试次数并加失败延时；路径 B——攻击者物理接入内部 CAN 直接注入伪造的电池温度报文诱导冷却系统误判，缓解=关键报文加装 SecOC 认证 + 接收端合理性校验（与另一路传感器或模型估计值交叉比对）。注意安全访问不是总线门禁：换掉诊断凭据对路径 B 基本无缓解作用；只有当 OBD 座与内部总线之间设有安全网关、且网关解锁本身要鉴权时，诊断侧凭据才间接影响注入路径，而此时的缓解主体也是网关的报文过滤策略，不是凭据本身。
动手做
交付物 · 针对热管理域控：①列出至少 5 类资产（标定数据/固件/通信报文/诊断接口/车云下行车控指令）及对应威胁；②为其中一条报文（如压缩机转速请求）设计简化 SecOC 认证方案要点，必须写明新鲜度值的形态、同步方式与失同步恢复策略，并说明为什么只算 MAC 挡不住重放；③说明升级该域控固件时至少两个必须校验的安全环节。
常见误区
- 把功能安全的故障应对（随机硬件失效）和网络安全的攻击应对（人为恶意行为）用同一套机制覆盖，忽略后者需要认证/加密等专门手段
- OTA 只做了传输层加密，没做固件签名验证，中间环节固件被篡改而无法被检测
- 差分升级把标定参数当普通数据处理，升级失败时残留半套参数，执行器行为异常但难以定位
- 诊断接口安全访问（Security Access）用固定种子-密钥算法长期不更新，形同虚设
- 网络安全测试只做黑盒渗透，不覆盖供应链固件和总线物理层，遗漏真实攻击面
- 只算 MAC、不带新鲜度值就当作 SecOC：攻击者不需要密钥，把一条 MAC 正确的合法旧报文原样录下来重放即可通过校验；功能安全里的滚动计数器（RollingCounter）若不进 MAC 计算同样可被伪造，「有 RollingCounter」不等于「有抗重放」
相关课题