TBOX信息安全系列3需求篇-车企信息安全需求对比

做TBOX项目，你第一个拿到的不是原理图，而是一份客户的网络安全需求规范。很多工程师看到几十页的"应/应该/可能"就头大，不知道从哪下手。这篇用两份真实的OEM需求规范做对标——某自主品牌（33页）和某合资品牌（25页），把章节结构、条款颗粒度、写法差异全部拆开讲。文中所有客户名称、文档编号、作者信息均已脱敏，只保留技术内容。这是系列第3篇。

先回答一个灵魂问题：为什么TBOX要有独立的网络安全需求规范？

因为TBOX是整车对外通信的"大门"——4G/5G、WiFi、蓝牙、V2X全从它进出。GB 44495 要求整车做信息安全，但整车厂不可能逐颗芯片去管，它把要求拆解、细化、下发给零部件供应商——这就是TBOX网络安全需求规范的由来。

拿到这份规范，你的工作不是"照着做"，而是逐条解读 → 映射到设计 → 证明合规。下面用两份真实规范演示这个过程。

1、两份规范：同一件事，两种写法

第一个洞察：自主品牌规范是**“TBOX专用”（12章按安全域展开），合资品牌规范是"零部件通用"**（用编号体系方便跨项目复用）。前者重"域覆盖"，后者重"可追溯"——这决定了你解读时的思路：前者按安全域扫一遍，后者按条款逐个打钩。

2、章节结构对标：安全域其实是对齐的

把两份规范的章节摊开对比，你会发现表面写法不同，底层安全域高度一致：

第二个洞察：合资品牌规范大量引用外部子规范（安全启动、安全刷新、安全日志、密码技术、TLS通信、调试接口、态势感知、身份识别……一整套文档体系）——它的IAM规范只是"总纲"，真正细颗粒度的要求在下级规范里。做合资品牌项目，你拿到的可能是一整套文档包，不是一份。

3、条款颗粒度对标：自主品牌"讲原则"，合资品牌"给配置"

这是两份规范最本质的差异。看两个具体例子：

例1：硬件安全要求

某自主品牌（3.1 硬件安全）——讲"原则"：

TBOX应具备防拆保护措施，防护硬件电路和软件安全，包括但不限于开盖检测、拆机告警等方式。
关键加密算法实现应具备抵抗侧信道分析和故障注入分析等物理攻击的能力，防止根密钥被破解。
芯片在设计验证阶段使用的调试接口（如I/O接口、JTAG）应在上市产品中禁用。

某合资品牌（4.1 硬件强化）——讲"动作"：

在开发阶段留有的后门或接口（例如标定接口）应在量产时完全移除。

对比结论：自主品牌明确要求"侧信道防护"“防拆告警”（原则级，设计自由度大）；合资品牌一句话点到"后门移除"（动作级，但要求清晰）。

例2：软件强化要求

某自主品牌（4.3 系统安全）——讲"目标"：

清除非必要系统账户；限制特权账户使用；最小化端口、进程和服务。

某合资品牌（4.2 软件强化 SC-CS-SW-Req系列）——直接给"配置清单"：

• kptr_restrict置2（内核符号地址打印为全0，root和普通用户都无权限）
• 内核地址空间布局随机化（KASLR）启动
• 删除sudo/su等提权命令
• 系统配置dm-verity
• 内核符号表（Kallsyms）命令禁用
• 诊断信息（Dmesg）命令禁用或限制
• 安卓调试桥（ADB）root权限禁止，ro.secure=1；调试权限禁止ro.debuggable=0
• 量产后移除或关闭core dump（内核/应用/SETGID/SETUID）
• 移除或关闭不需要的文件系统、接口、驱动、网络服务、daemon、shell解释器、语言解释器
• 非必要端口关闭；业务必需端口用防火墙黑白名单限制，禁止对外部任意IP开放
• 量产后禁用调试功能（ADB、gdb、pdebug）
• 量产软件无法切换至非正常模式（测试模式/调试模式）
• 移除敏感命令（ssh/telnet/ftp/wget/curl等）

第三个洞察（最重要）：合资品牌把"安全配置"直接写到了内核参数、编译选项、命令级——你不需要猜"什么叫安全状态"，照着配置清单做就行。自主品牌给你留了设计空间，但也要求你自己想清楚"怎么才算达到目标"。前者的坑是"漏项"（没列出来的你容易忽略），后者的坑是"过度"（为了合规堆配置，影响性能）。

4、通信安全章节：TBOX 的"重头戏"

通信安全是TBOX需求的核心，两家都花了大篇幅。以某自主品牌为例：

4.1 云端通信

TBOX应具备识别通信通道遭受拒绝服务攻击的能力，并对攻击数据包进行相应的处理（拦截、丢弃等）。
应对关键的通信通道信息安全事件进行日志记录。

4.2 直连通信（V2X）

应使用注册证书和通信证书相结合的方式，为直连通信消息提供数字签名服务。注册证书是车辆或行人参与直连通信的身份凭证；通信证书用来对直连通信发送的消息进行数字签名。
证书由统一的云端管理系统分发，参与直连通信的车辆应通过身份鉴别后获得注册证书，并进一步获得通信证书。

4.3 网络传输（重点）

应采取安全通信协议，例如TLS 1.2等（法规）。
应关闭不必要的网络端口（法规）。
应具有网络访问控制功能（按源/目的地址、端口、协议检查，允许或拒绝数据包）。
应支持网络分域，对不符合分域的数据包丢弃或记录日志。
应配置访问控制列表（ACLs），遵循默认拒绝原则（丢弃所有不符合条件的数据包）和最小化授权原则（只授予必要权限）。

第四个洞察：注意"（法规）“这个标注——自主品牌规范里凡是标了”（法规）"的条款，都对应GB 44495等强制国标要求。这些是"红线条款"，设计评审一票否决，必须无条件满足。

5、从需求到落地：一条完整的链路

拿到需求规范，怎么变成产品？这是完整链路：

1. 客户需求：OEM发来需求规范（GWM/IAM或类似的）
2. 需求分析：逐条解读，按"应/应该/可能"分级——"应"必须做、"应该"强烈建议做、"可能"可协商
3. 方案设计：映射到六大设计域（硬件/系统/通信/数据/升级/诊断）
4. 开发实现：安全启动、加密、ACL、SELinux等落地
5. 测试验证：渗透测试、合规检查（对照需求逐条打钩）
6. 量产交付：送审OEM、漏洞持续响应（法规要求）

6、需求评审 Checklist（可直接抄）

这是我从两份规范里提炼的通用评审清单，做TBOX项目的可以直接用：

硬件安全

• 是否有防拆/开盖检测？
• 调试接口（JTAG/串口）是否量产禁用？
• 密钥是否由安全模块（HSM/SE）管理，全生命周期安全？
• 加密算法能否抗侧信道/故障注入？
• 敏感通信线路是否内层布线隐藏？

系统安全

• 非必要账户是否清除？特权账户是否受限？
• 内核是否启用KASLR？kptr_restrict是否置2？
• 是否删除提权命令（sudo/su）？
• 是否配置dm-verity/文件系统完整性？
• 调试功能（ADB/gdb）是否禁用？
• core dump、不需要的服务/驱动/shell是否关闭？
• 端口是否最小化？防火墙是否默认拒绝？

通信安全

• 是否使用TLS 1.2+（或国密TLS）？
• 云端是否双向认证？
• 是否有ACL访问控制，遵循默认拒绝？
• 是否有网络分域？
• 是否能检测DoS攻击？
• V2X是否双证书（注册+通信）体系？

数据安全

• 是否最小化采集？
• 敏感数据是否加密存储？
• 是否有个人信息删除功能？

升级安全

• 升级包是否签名验证？
• 是否能防回滚/防降级？
• 离线升级是否有校验？

日志与监测

• 安全日志是否记录（时间/主体/对象/结果）？
• 日志留存是否≥6个月？
• 是否有漏洞响应流程？

7、给TBOX工程师的3条实战建议

1. 先分级，再动手：拿到需求先按"应/应该/可能"分级，把"应"和"（法规）"条款单独拎出来——这些是评审一票否决项，优先级最高
2. 通用能力优先建：安全启动、加密（国密+国际双算法）、ACL、日志——这些是所有OEM都要的通用能力，先建成平台化模块，接新项目就是"配置差异"而不是"重新开发"
3. 合规要留证据：合资品牌那种"配置清单式"需求，每条都要留实现证据（配置截图、测试报告）——评审时是逐条打钩的，没有证据=没做

8、系列进度

这篇是《TBOX信息安全实战系列》第3篇。系列全景（8篇）：

下一篇：TBOX硬件安全怎么做？密码模块+车规安全芯片，从攻击面到信任根。

❤️文末福利❤️

1、关注【擎天柱工坊】获取更多免费学习视频和资料
2、私信回复【汽车硬件设计】领取原理图、PCB、学习视频