
Reading time
7 minutes
软件定义汽车新时代下的通信安全
随着软件定义汽车(SDV)理念的普及,车辆内部各电子控制单元(ECU)之间的通信已经突破传统的控制边界,成为支撑自动驾驶、高度互联和OTA更新的关键基础设施。在这样的背景下,通信安全的重要性尤为凸显。未经保护的通信链路可能面临数据篡改、重放攻击及冒充攻击等风险,危及车辆功能的正确性和用户安全。因此,在AUTOSAR架构中建立完备的通信安全机制,已成为行业共识与技术刚需。
AUTOSAR通信栈(ComStack):分层、模块化的基础
AUTOSAR通信栈(ComStack)作为基础软件(BSW)核心组件之一,承担起ECU之间数据交换的核心功能,包含多个分层模块,支持CAN、LIN、FlexRay 和以太网等多种通信协议。其层级结构可概括如下:
- CanIf/EthIf/FrIf/LinIf接口层
针对不同总线协议,在低层提供硬件抽象,屏蔽底层细节,连接上层的PduR。 - PduR(Protocol Data Unit Router)路由层
管理不同协议的数据单元(PDU)路由,确保来自Com模块的消息发送至应用层或者对应物理总线,也可以接收和转发消息。 - Com(Communication)层
位于应用和底层接口之间,负责信号级处理,包括信号打包、解包及路由到相应应用组件或下层。 - SecOC(Secure Onboard Communication)模块
这是通信栈中专门针对安全功能设计的组件,用于消息认证与防篡改,属于BSW的一部分,但需结合上层Com、PduR共同协作实现端到端的安全传输。 这种分层架构使得通信部分高度模块化,功能清晰,易于扩展与维护,同时为集成安全功能功能安全提供了良好的基础。
SecOC模块:安全通信的核心支撑
Secure Onboard Communication(SecOC)是AUTOSAR专门用于通信安全的模块,旨在保护ECU间的PDU级消息,确保其真实性、完整性和新鲜度。根据官方规范,SecOC的功能包括:消息认证、完整性保护及防重放措施。
- 消息认证与完整性保护
每条受保护消息都会附加认证标签(如MAC),接受方在接收消息时进行验证,确保消息确实来自可信源且在传输中未被篡改。 SecOC支持对一条消息内容和其认证标签共同校验,从而对攻击产生抵御能力。 - 重放攻击防护机制(Freshness)
为阻止重放攻击,SecOC插入”freshness”值(如递增计数器或时间戳),用于区分消息的时序新旧。接收方比较该值并拒绝过期或重复消息,从而确保系统只能处理按预期顺序或时间提交的消息。 - 资源高效设计
SecOC模块强调在资源受限的AUTOSAR环境中实现轻量安全机制。其规范涵盖处理认证算法、打包认证标签、与Com/PduR协作流程等细节,并支持根据实际资源选用对称算法、MAC长度及计数器类型等多个配置选项。
安全通信的系统级实现流程
- 初期设计与配置
- 定义通信需求及安全等级:分析哪些通信路径需要认证、完整性验证以及新鲜度保护。如:安全/关键命令、遥测数据或OTA触发消息等;
- 配置SecOC模块:设置安全算法(如AES-CMAC)、MAC总长度、计数器大小、如何计算新鲜度值等。
- 与ComStack集成
- Tx路径:应用调用Com,将信号封装为PDU;随后PduR将PDU导向SecOC,SecOC 生成认证标签并附加生成MAC校验值;经过PduR-CanIf将其发送至总线。
- Rx路径:接收方通过CanIf接收数据后转发至SecOC;SecOC校验MAC与新鲜度,认证通过后移除标签,将净内容转交给PduR处理,再由PduR分发给应用组件。
- 该流程由AUTOSAR通信规范明确规定,不允许跳过SecOC模块以保证端到端的安全性。
- 系统级测试与验证
- 功能验证:测量正常通信路径及认证通过时的数据完整性。
- 攻击模拟:尝试对消息内容篡改、重放旧消息或伪造MAC,检验系统并确保拒绝不符合安全策略的消息。
- 性能评估:评估认证与验证机制对总线延迟和资源(如CPU、内存)的影响,确保系统仍满足实时、安全等关键性能指标。
AUTOSAR通信安全的未来方向
- 趋向更高的安全目标与扩展
随着整车功能和联网能力的不断增强,未来安全机制亦需升级。当前研究如CINNAMON模块,即在SecOC的基础上增加加密功能,增强机密性保护。这种机制可以与SecOC并行部署,使信息在传输中不仅防篡改,也无法被未授权读取。 - 与Adaptive Platform的整合
除了Classic Platform当前支持的SecOC,AUTOSAR Adaptive Platform(AP)中的ara::com同样集成认证与防重放功能,新版本规格已加入SecOC行为和API,支持Freshness管理,从而保障高级、动态更新场景下的通信安全。
总结与Elektrobit的专业视角
通过上述分析,可见AUTOSAR通信栈中安全机制的设计原则:模块化、安全性与资源效率兼备。 SecOC模块作为枢纽,结合Com、PduR、CanIf等基础组件,实现端到端安全通信,为SDV提供可信基础。
未来发展方向主要包括:
- 增强机密性保护;
- 更完善的浓缩式Freshness 管理;
- 在Adaptive Platform场景中实现统一安全策略。
以下提供EB tresos软件解决方案的实践案例
多核ECU可信配置与ASIL‑D安全实装
面向对象:ECU软件架构师、嵌入式系统工程师、功能安全负责人
通过EB tresos AutoCore OS实现单/多核部署、实现基于Crypto/HSM的CAN/LIN/ETH通信协议栈,利用Elektrobit对MCAL接入与安全隔离优化来实现安全通信的实现。
以我们在英飞凌AURIXTM TC 397上的Demo为例:
首先通过EB tresos Studio新建一个多核的OS系统,按照初始化的流程在EcuM中实现从主核到从核的顺序初始化MCAL和BSW的寄存器/函数。
因为部署有多个CAN控制器(CAN0, CAN1, …),不同核(Core0, Core1)会独立管理它监控的进程。
初始化成功之后,OS启动调度,通过RTE管理不同的Task,来触发CAN通信的读写,通信流程例子如下:
MCAL CAN Driver多核
- 每个核上的CAN Driver接收自己核上CAN控制器的数据
- 例如:CAN0的Rx消息在Core0的中断中触发CanIf_RxIndication()或者把消息放到对应的CANtx Buffer里面去
CanIf多核部署
- 每核各自运行CanIf实例,但共享统一配置(通常静态分区)
- CanIf查找匹配的RxPdu后,调用上层PduR_CanIfRxIndication() PduR多核处理
- 若RxPdu的目标模块(如COM)位于同核:直接调用上层模块
- 若目标模块在另一核(Core1接收,Core0的SWC接收):
- 调用核间通信机制:
- Shared Memory Ring Buffer
- AUTOSAR OS Event
- 数据通过共享内存或IOC传递至另一核
- 调用核间通信机制:
COM & RTE
-
- 数据最终被写入目标核上的COM模块
- SWC通过Rte_Read()接口读取数据
LIN/ETH的通信也是类似的,通过各自的LinIf和SOAD抽象层协议栈去实现通信。
在此之上,Elektrobit通过对此过程中PduR的数据根据对应的Crypto算法,使用密钥,新鲜值等参数作为入参,实现通信数据的加解密,实现数据的安全通信满足ASIL-D的要求。