26、Camera安全攻击面：物理攻击、协议攻击、软件漏洞、防御策略
各位同学，今天我们聊点“硬核”的——Camera的安全攻击面。
说实话，做车载Camera系统这么多年，我见过太多只关注功能实现、忽视安全防护的项目。结果呢？要么被物理破解，要么被协议劫持，要么被软件漏洞钻了空子。今天我就把这几个攻击面掰开揉碎了讲清楚，顺便聊聊我踩过的坑和总结的防御策略。
26.1 物理攻击：最直接，也最容易被忽视
物理攻击，说白了就是“动手”。攻击者直接接触硬件，试图绕过或破坏安全机制。
26.1.1 常见的物理攻击手段
- 串口/JTAG调试接口暴露：很多开发板甚至量产板，调试接口没做物理防护。一根杜邦线，一个USB转串口模块，就能直接dump固件、修改内存。
- SPI Flash/EEPROM读取：用编程器直接读取存储芯片里的固件或校准数据。我见过一个项目，摄像头模组的校准参数明文存在外部Flash里，被读出来后直接克隆了整套模组。
- 电源/时钟毛刺攻击：通过瞬间拉低电压或注入时钟毛刺，让CPU跳过安全检查指令。嗯，这招在破解汽车ECU时很常见。
- 激光/电磁故障注入：用激光照射芯片特定区域，或者用电磁脉冲干扰，导致寄存器状态翻转。这属于高阶攻击，但确实存在。
⚠️ 避坑指南
我曾经在一个项目中，为了调试方便，把UART调试口留在了PCB边缘，而且没加电阻隔离。结果量产车被第三方拆解后，直接通过这个口刷入了恶意固件，导致摄像头输出被篡改。从那以后，我要求所有量产板必须物理移除调试接口，或者至少用树脂封死。
我曾经在一个项目中，为了调试方便，把UART调试口留在了PCB边缘，而且没加电阻隔离。结果量产车被第三方拆解后，直接通过这个口刷入了恶意固件，导致摄像头输出被篡改。从那以后，我要求所有量产板必须物理移除调试接口，或者至少用树脂封死。
26.1.2 物理防御策略
- 硬件安全模块（HSM/SHE）：把密钥和敏感运算放到独立的安全芯片里，即使主芯片被攻破，密钥也拿不到。
- 防篡改检测：在机壳或PCB上安装防拆开关，一旦检测到物理入侵，立即擦除密钥或触发安全擦除。
- 加密存储：所有固件、校准数据、密钥必须加密存储。我习惯用AES-256-GCM，带认证加密，防止被篡改。
- 调试接口熔丝：量产前烧断芯片的调试接口熔丝，彻底禁用JTAG/SWD。
26.2 协议攻击：通信链路是薄弱环节
Camera系统内部通信协议很多：MIPI CSI-2、I2C、SPI、UART、Ethernet（AVB/TSN）。每个协议都可能成为攻击目标。
26.2.1 常见协议攻击手段
- MIPI CSI-2 数据注入：攻击者可以在物理链路上注入虚假的MIPI数据包，替换真实摄像头画面。你想想看，如果ADAS系统看到的是伪造的障碍物或车道线，后果是什么？
- I2C/SPI 总线监听与篡改：摄像头配置通常通过I2C完成。攻击者可以监听配置命令，或者直接篡改寄存器值，比如关闭自动曝光、锁定增益，让摄像头输出过曝或欠曝的图像。
- Ethernet 中间人攻击：对于基于IP的摄像头（如GMSL2转Ethernet），攻击者可以ARP欺骗、DNS劫持，甚至直接替换视频流。
- CAN/CAN-FD 消息伪造：如果摄像头通过CAN上报状态或诊断信息，攻击者可以伪造CAN消息，让ECU误以为摄像头故障或正常。
💡 个人经验
我参与过一个项目，摄像头通过I2C配置，但I2C总线上还挂了其他传感器。结果发现，某个传感器驱动有bug，会随机往总线上发错误数据，导致摄像头配置被意外改写，图像出现间歇性花屏。排查了整整两周才发现是I2C总线冲突。所以，我建议所有摄像头相关的I2C总线必须独立，或者至少加总线隔离器。
我参与过一个项目，摄像头通过I2C配置，但I2C总线上还挂了其他传感器。结果发现，某个传感器驱动有bug，会随机往总线上发错误数据，导致摄像头配置被意外改写，图像出现间歇性花屏。排查了整整两周才发现是I2C总线冲突。所以，我建议所有摄像头相关的I2C总线必须独立，或者至少加总线隔离器。
26.2.2 协议防御策略
- MIPI CSI-2 数据完整性校验：在SoC端对MIPI数据包进行CRC校验，发现异常立即丢弃并报警。
- I2C/SPI 写保护：关键寄存器设置写保护位，只有通过特定序列才能修改。或者使用安全GPIO控制写使能。
- Ethernet 802.1X/MACsec：对IP摄像头进行端口认证和链路层加密，防止中间人攻击。
- CAN 消息认证：使用SecOC（安全车载通信）对CAN消息进行认证和新鲜度检查。
26.3 软件漏洞：最复杂，也最致命
软件层面的攻击面最广，从驱动到HAL，再到Framework，每一层都可能存在漏洞。
26.3.1 常见软件漏洞类型
- 缓冲区溢出：在V4L2驱动或ISP驱动中，如果对用户空间传入的buffer大小校验不严，攻击者可以构造恶意数据触发溢出，执行任意代码。
- 整数溢出/下溢：在图像尺寸计算、内存分配时，如果整数运算没做边界检查，可能导致分配过小或过大的内存，引发崩溃或信息泄露。
- 权限提升：Camera HAL通常运行在高权限下（如system或root）。如果HAL对外暴露的接口（如binder服务）存在漏洞，攻击者可以从普通app提权到system权限。
- 竞争条件：多线程访问共享资源（如帧buffer、配置参数）时，如果没有加锁或加锁不当，可能导致数据不一致或use-after-free。
- 逻辑漏洞：比如，某些摄像头在安全模式下（如倒车影像）应该禁止用户修改参数，但代码里没做检查，导致攻击者可以通过adb或root shell篡改。
🔍 真实案例
我记得有一个开源Camera HAL，在处理metadata时，没有校验传入的buffer长度是否与预期一致。攻击者可以传入一个超长的metadata buffer，触发堆溢出，最终控制了整个Camera服务。这个漏洞在CVE上挂了很久，很多车厂都中招了。
我记得有一个开源Camera HAL，在处理metadata时，没有校验传入的buffer长度是否与预期一致。攻击者可以传入一个超长的metadata buffer，触发堆溢出，最终控制了整个Camera服务。这个漏洞在CVE上挂了很久，很多车厂都中招了。
26.3.2 软件防御策略
- 安全编码规范：强制使用安全函数（如snprintf代替sprintf），开启编译器的栈保护（-fstack-protector-strong）、ASLR、PIE。
- 输入校验：所有来自用户空间或网络的数据，必须在内核或HAL层进行严格的长度、范围、格式校验。
- 最小权限原则：Camera HAL只授予必要的权限，不要直接跑在root下。使用SELinux/AppArmor进行强制访问控制。
- 模糊测试（Fuzzing）：在开发阶段，对V4L2驱动、ISP驱动、HAL接口进行持续模糊测试。我习惯用syzkaller来测内核驱动，用libFuzzer测用户空间代码。
- 运行时防护：启用CFI（控制流完整性）、Shadow Stack等硬件辅助安全特性，防止ROP/JOP攻击。
26.4 防御策略总结：纵深防御
单一防御手段是不够的。你必须构建一个多层防御体系，让攻击者即使突破一层，也无法轻易攻破整个系统。
下面这张图是我个人总结的Camera安全防御架构，你可以把它当作一个checklist来用。
你看，这个架构的核心思想就是：不要把所有鸡蛋放在一个篮子里。物理层防住了，还有协议层；协议层防住了，还有软件层。每一层都独立且互相补充。
📌 核心要点
- 物理攻击：防硬件接触，用HSM和加密存储
- 协议攻击：防链路篡改，用认证和加密
- 软件漏洞：防代码缺陷，用安全编码和运行时防护
- 纵深防御：多层防护，层层递进，让攻击成本最大化
好了，关于Camera安全攻击面，我就讲这么多。记住，安全不是一次性的工作，而是贯穿整个开发周期的持续过程。从需求分析到设计，从编码到测试，从部署到运维，每一步都要把安全考虑进去。
我个人习惯在项目启动时就拉一个安全checklist，每个阶段都对照检查。虽然前期会多花一些时间，但比起后期被攻破再补救，这点投入绝对是值得的。