一、座舱系统安全概述：安全概念、安全威胁模型、安全目标与原则

1.1 安全概念：到底什么是“安全”？

说到座舱系统安全，很多人第一反应就是“防黑客”。其实，这个理解有点窄了。

我个人习惯把安全分成三层来看：

• 功能安全：系统在正常或故障状态下，不会对人造成伤害。比如刹车失灵、屏幕死机导致看不到仪表——这些是功能安全的事。
• 信息安全：防止外部攻击者非法访问、篡改或窃取数据。比如有人通过蓝牙漏洞远程控制你的车窗——这是信息安全。
• 隐私保护：用户的个人数据不被滥用或泄露。比如你的驾驶习惯、常去的地点、通话记录——这些是隐私范畴。

我在项目中遇到过不少团队，只盯着信息安全，忽略了功能安全。结果呢？系统确实没被黑，但某个极端工况下屏幕直接黑屏了。嗯，这其实更危险。

1.2 安全威胁模型：谁在攻击我们？

你想想看，座舱系统暴露在多少种攻击面下？

我列一个常见的威胁模型，大家对照一下自己的项目：

攻击面	典型攻击方式	风险等级
无线通信（蓝牙/WiFi/4G/5G）	中间人攻击、重放攻击、协议漏洞利用	高
USB/OTG接口	恶意设备注入、BadUSB攻击	高
车载以太网/CAN总线	报文伪造、DoS攻击、总线监听	中高
应用层（APP/第三方服务）	权限滥用、数据泄露、代码注入	中
OTA升级通道	固件篡改、降级攻击、签名绕过	高
传感器（摄像头/麦克风/GPS）	数据窃听、物理篡改	中

我曾经参与过一个项目，客户说“我们的蓝牙只用来播放音乐，不会有安全问题”。结果呢？我们做渗透测试时，通过蓝牙协议栈的一个缓冲区溢出漏洞，直接拿到了系统root权限。说白了，攻击者不会管你“只用来做什么”，他们只看“能不能攻进去”。

1.3 安全目标：我们要保护什么？

搞清楚了威胁，接下来就是目标。座舱系统的安全目标，我总结为四个字：CIA + A。

• C - 机密性（Confidentiality）：敏感数据不能被未授权的人看到。比如你的通话记录、导航历史、支付信息。
• I - 完整性（Integrity）：数据和系统不能被非法篡改。比如仪表盘显示的速度、导航的路线规划——如果被改了，后果很严重。
• A - 可用性（Availability）：系统在需要的时候必须能用。比如紧急刹车时，屏幕不能死机；倒车时，摄像头不能延迟。
• A - 可追溯性（Accountability）：谁在什么时候做了什么，必须能查清楚。比如谁修改了系统配置、谁访问了用户数据。

我建议大家在设计阶段就把这四个目标写进需求文档里。别等到测试了才发现“哦，我们忘了考虑可用性”。

1.4 安全原则：设计时该遵循什么？

说到原则，我脑子里第一个蹦出来的就是 “最小权限原则”。说白了，就是每个模块、每个进程、每个用户，只给它们完成工作所需的最小权限。多一点都不给。

举个例子：一个显示天气的APP，它需要访问网络，但不需要访问你的通讯录，更不需要访问你的麦克风。如果它申请了这些权限，你就得警惕了。

其他几个核心原则：

• 纵深防御：不要依赖单层防护。比如防火墙 + 入侵检测 + 应用沙箱，多层叠加。
• 默认安全：系统出厂时，所有安全机制默认开启。用户可以选择关闭，但不能默认关闭。
• 失效安全：系统出故障时，应该进入安全状态，而不是暴露在风险中。比如安全认证失败时，应该拒绝访问，而不是放行。
• 最小暴露面：能不暴露的接口就不暴露，能不开的服务就不开。比如调试接口在生产环境中必须关闭。

我记得有一次评审一个座舱系统的架构设计，对方把所有的服务端口都暴露在车载以太网上。我问他们为什么，回答是“方便调试”。嗯，方便是方便了，但安全呢？后来我们强制要求：所有调试接口只能在工程模式下启用，且必须通过物理开关控制。

1.5 我的个人经验：安全设计要趁早

最后说点实在的。我参与过好几个座舱项目，有一个深刻的体会：安全设计越早介入，成本越低，效果越好。

举个例子：如果架构阶段就确定了权限模型，开发时按这个模型编码，测试时按这个模型验证——整个过程很顺畅。但如果等到开发完了才发现权限设计有问题，那就要改代码、改测试、改文档，甚至要改硬件设计。这个代价，谁改谁知道。

所以我的建议是：

• 项目启动时，安全工程师就要参与进来
• 每个迭代，都要做安全评审
• 每个功能上线前，都要过安全测试

别觉得麻烦。你想想看，一个安全漏洞被曝光，损失的不仅是钱，还有用户的信任。这个账，值得算清楚。