4、GB/T 40856-2021解读：《车载信息交互系统信息安全技术要求》的硬件安全、软件安全、通信安全要求
好，咱们进入第四个章节。说实话，GB/T 40856-2021 这个标准，在我眼里是车载信息安全领域里最「接地气」的一个。为什么这么说？因为 ISO 21434 讲的是流程和体系，告诉你「怎么做才安全」；而 40856 直接告诉你「什么东西必须安全」，它把车载信息交互系统——也就是我们常说的车机、T-Box、网关这些——的硬件、软件、通信三个维度，掰开揉碎了讲。
我个人习惯，每次接手一个新项目，第一件事就是把 40856 翻出来，对着硬件设计清单一条条过。你想想看，如果硬件层面就漏了安全防护，后面软件写得再好，也是白搭。
4.1 硬件安全要求：物理防线怎么搭？
硬件安全，说白了就是防止别人物理上动你的板子。我在项目中遇到过，有些团队觉得「车机装在车里，谁还能拆开看？」——嗯，这种想法很危险。攻击者可能通过 OBD 接口、调试串口，甚至直接拆机，拿到你的 Flash 镜像。
40856 对硬件安全的要求，我总结为三个核心点：
- 安全启动（Secure Boot）：芯片上电后，第一段代码必须是只读的、签过名的。我记得有一次，某供应商的 Bootloader 没做签名校验，结果被刷了个恶意固件，整台车的 CAN 总线都被控制了。从那以后，我对 Secure Boot 的要求就是：必须硬件级实现，不能依赖软件。
- 调试接口保护：JTAG、SWD 这些调试口，量产时必须物理熔断或加密码锁。我见过一个案例，攻击者通过 JTAG 直接 dump 了整个 Flash，密钥、算法一览无余。所以我的建议是：调试口要么用 eFuse 熔断，要么用芯片原厂的调试认证机制。
- 安全存储：密钥、证书这类敏感数据，不能明文存在 Flash 里。必须用硬件安全模块（HSM）或可信执行环境（TEE）来保护。我习惯把密钥分成多段，分别存在不同的安全区域，就算攻破一个，也拿不到完整密钥。
重要提醒：硬件安全是基础。如果芯片本身不支持安全启动或 HSM，那这个方案从一开始就不合规。选型阶段就要把 40856 的硬件要求写进招标书里。
4.2 软件安全要求：代码层面的「铜墙铁壁」
软件安全，是 40856 里篇幅最大的一块。为什么？因为现在的车机系统越来越复杂，Android、Linux、QNX 都在用，漏洞面自然就大了。
标准里明确要求了以下几点，我挑几个重点说说：
- 操作系统安全：必须启用强制访问控制（如 SELinux、AppArmor）。我见过一个项目，车机跑的是 Android，但 SELinux 是 permissive 模式——说白了就是形同虚设。攻击者通过一个 App 漏洞，直接拿到了 root 权限。所以我的原则是：SELinux 必须 enforcing，而且策略要逐条审核。
- 应用安全：所有第三方应用必须经过签名验证。我记得有一次，一个 OTA 升级包没做签名校验，结果被中间人篡改，推送了一个带后门的版本。嗯，从那以后，我对签名校验的要求就是：必须硬件级校验，不能只靠软件。
- 数据安全：用户隐私数据（如位置、通讯录）必须加密存储。我建议用 AES-256-GCM，密钥由 HSM 管理。另外，数据删除时要做到「安全擦除」，不能只是标记删除——你想想看，如果只是删个文件头，数据恢复工具分分钟就能找回来。
实战技巧：在做软件安全设计时，我习惯先画一个「数据流图」，标出所有数据的输入、输出、存储点。然后针对每个点，问自己三个问题：数据可信吗？传输加密了吗？存储安全吗？这样基本不会漏掉关键环节。
4.3 通信安全要求：管好每一根「网线」
通信安全，是 40856 里最容易被忽视的部分。很多人觉得「车内通信是封闭的，怕什么？」——但现在的车，有 4G/5G、Wi-Fi、蓝牙、V2X，甚至还有 UWB，攻击面早就从车内延伸到车外了。
标准对通信安全的要求，我归纳为三个层面：
| 通信类型 | 安全要求 | 我的经验 |
|---|---|---|
| 车内通信（CAN、以太网） | 必须做消息认证和完整性校验 | 我建议用 MAC（消息认证码），不要只用 CRC。CRC 只能检错，不能防篡改。 |
| 车外通信（T-Box、V2X） | 必须用 TLS 1.2+ 或 DTLS，证书双向认证 | 有一次我发现某供应商的 TLS 实现只验证了服务器证书，没验证客户端证书——这相当于门只锁了一半。 |
| 无线通信（蓝牙、Wi-Fi） | 必须使用安全配对和加密连接 | 蓝牙的 Just Works 模式千万别用，一定要用 Passkey Entry 或 Numeric Comparison。 |
这里我要特别强调一下 CAN 通信。很多老工程师觉得「CAN 总线是广播式的，加个 ID 过滤就够了」——但 40856 明确要求了消息认证。我曾经在一个项目中，发现攻击者通过 OBD 接口伪造了 CAN 报文，直接让车辆加速。解决方案就是：每条 CAN 报文都带一个基于密钥的 MAC，接收方校验通过才执行。
避坑指南：我曾经踩过一个坑——通信加密的密钥是硬编码在代码里的。结果代码被反编译，密钥直接暴露。后来我改用密钥协商协议（如 ECDH），每次会话生成临时密钥，用完即销毁。这个教训，希望大家不要再重复。
4.4 我的总结与建议
GB/T 40856-2021 这个标准，其实是在告诉所有车载系统开发者：安全不是某个模块的事，而是硬件、软件、通信三个维度协同的结果。你想想看，硬件再强，软件有漏洞也没用；软件再安全，通信不加密也是白费。
我个人建议，在做合规设计时，可以按照这个顺序来：
- 先搞定硬件安全——选支持 HSM 和安全启动的芯片
- 再搭建软件安全——操作系统加固、应用签名、数据加密
- 最后完善通信安全——车内车外通信都要加密认证
嗯，这样一层层往上搭，基本就能满足 40856 的要求了。下一章，我们会聊聊 GB/T 40857-2021，也就是网关的安全要求。那个标准，说实话，比 40856 还要「狠」一点——到时候再细说。