2015年安全研究员通过远程接口黑进一辆切诺基的CAN总线向刹车系统发送伪造指令——车在高速上被远程劫持。这件事震惊了整个汽车行业CAN总线从设计之初就没考虑过认证任何接到总线上的设备都能发任意ID的报文其他ECU无条件接收。SecOCSecure Onboard Communication就是AUTOSAR给出的解药。这篇把SecOC的原理、报文结构、收发流程、与TBOX的关系完整拆解。先讲清楚CAN的原罪CAN总线诞生于1980年代设计目标是低成本、高可靠、实时性——压根没考虑安全明文广播所有报文在总线上明文传输谁都能看无认证接收任何节点都能发任意ID其他节点无条件接收以前车是封闭的问题不大。但现在——TBOX、车机、OTA网关都接在总线上任何一个被攻破攻击者就能通过CAN总线向动力、底盘、刹车系统发指令。这就是一条报文引发的惨案。1、SecOC 是什么AUTOSAR 的车内消息认证标准SecOCSecure Onboard Communication是 AUTOSARAUTOSAR Classic 4.2 引入的车内通信安全模块。核心思想一句话给关键的CAN报文加一层身份验证 防重放——接收方先验证验证通过才处理失败就丢弃。SecOC 不加密数据车内实时总线做加密代价太高它做的是认证MAC消息认证码→ 证明消息是合法发送方发的防伪造、防篡改Freshness Value新鲜度值→ 证明消息不是重放的防重放对比第7篇车云通信TLS证书是点对点安全SecOC是总线广播安全——一个防通道、一个防报文正好一外一内。2、 SecOC 报文结构8字节里挤出安全Classic CAN 一帧只有 8 字节怎么塞进认证信息AUTOSAR 的默认配置字段长度作用原始载荷剩余空间业务数据新鲜度值FV截断4 bit防重放MAC 截断28 bit防伪造/篡改MAC 计算范围CMAC(K, 消息ID 载荷 完整新鲜度值)为什么要截断完整MAC是128bit16字节完整FV更长——8字节的CAN帧根本塞不下。所以FV只发低4bit接收方用自己的计数器收到的低4bit重构完整FVMAC只发高28bit截断后的MAC仍能提供足够安全强度8字节 vs 64字节 vs 以太网SecOC 在三种总线上的配置总线帧长决定了安全信息的挤出空间——这是SecOC落地最实际的差异总线帧长典型配置载荷特点Classic CAN8字节Profile 3FV截断4bit MAC截断28bit约3字节镣铐最重只能保护关键报文Classic CAN8字节Profile 1FV截断8bit MAC截断24bit约4字节中间配置FV步进更大CAN-FD64字节FV 1字节 MAC 7字节56字节空间宽裕安全信息可放宽车载以太网100/1000BASE-T1三种Profile可配甚至叠加TLS/IPsec充足游刃有余可多层安全Classic CAN8字节——戴着镣铐跳舞AUTOSAR Profile 3JASPARFV截断4bit MAC截断28bit载荷只剩约3字节Profile 18bit FV 24bit MACFV步进更大但MAC弱一点只能保护最高优先级的报文安全功能信号且要精打细算每1bitCAN-FD64字节——空间宽裕典型配置FV取1字节 MAC取7字节共8字节安全信息载荷56字节发送时SecOC收到56字节报文加8字节安全信息 → 64字节SIPDU发出接收时64字节报文 → 验签 → 转出56字节给上层载荷是Classic CAN的近19倍FV/MAC都能放宽保护范围可以更大车载以太网——游刃有余SOME/IP SecOCFV/MAC可配到更长甚至完整128bit MAC还能叠加TLS/IPsec第7篇的双向认证在以太网上也能用适合域控/网关的大流量场景工程结论Classic CAN上SecOC是精打细算每个bit都金贵CAN-FD上SecOC是正常发挥以太网上SecOC可以豪华配置甚至叠加多层。选总线时就要想清楚SecOC的配置空间。3、 收发流程认证 vs 验证发送方认证取新鲜度值FV单调递增计数器/时间戳调 CMAC 计算 MACCMAC(K, 消息ID载荷FV)组装安全报文载荷 FV低4bit MAC高28bit发到总线接收方验证从报文中取FV低4bit MAC用本地计数器收到的低4bit重构完整FV重算MAC与收到的比对验证失败 → 静默丢弃不送上层软件组件静默丢弃是关键设计——验证失败的消息直接不上层接收软件组件根本看不到伪造报文从源头阻断。4、新鲜度值FV防重放的核心重放攻击攻击者录下一条合法报文比如解锁车门过会儿再发一次——没有防重放机制ECU会照单全收。新鲜度值就是计数器每条报文带一个单调递增的FV接收方记住上次收到的最新值——重放的旧报文FV小于当前值验证失败。AUTOSAR 的FV构造常见配置多计数器组合Trip Counter行程计数器每次车辆启动1由网关广播同步Reset Counter复位计数器固定间隔1也在同步报文中Message Counter消息计数器每条消息1复位时清零Reset Flag复位计数器的低几位同步报文由指定的同步节点通常是网关周期性广播 Trip Counter 和 Reset Counter让全网节点FV保持同步。同步报文本身也被MAC保护——防止攻击者伪造同步报文搞乱FV。工程难点提示FV同步是最容易出问题的地方——ECU复位、休眠唤醒、总线恢复后如果FV没重新同步就会出现合法报文被误杀或重放窗口打开。这是SecOC落地最常见的坑。5、密钥管理SecOC 的命门MAC是对称密码发送方接收方用同一个密钥K所以密钥安全 SecOC 安全密钥管理要点密钥必须存HSM硬件安全模块——呼应第5篇软件存密钥钥匙贴在门上密钥通过AUTOSAR Crypto Stack执行CSM/CryIf/加密驱动密钥按车辆/ECU组独立分发整车下线刷写时静态分配或云端动态下发更换ECU时全网重配密钥新密钥用已有密钥加密传输防止旁观重配窃取密钥对TBOX的含义TBOX 的 MCU如 S32K144内置 HSMSecOC 的 CMAC 计算和密钥存储都在 HSM 里做——这正是第5篇说MCU侧HSM做安全启动和密钥管理的具体应用场景之一。6、SecOC 防的三类攻击攻击原理SecOC如何防重放重发旧报文新鲜度值单调递增旧值验证失败伪造冒充发送方发指令MAC验证失败没有密钥伪造不了篡改改报文载荷载荷一变MAC就不匹配但注意SecOC不防窃听CAN明文广播MAC不加密数据——要防窃听需要报文数据加密CanTransceiver/报文加密是另一套方案。SecOC解决的是数据来源可信不是数据内容保密。7、哪些报文需要SecOC——TARA来决定不是所有CAN报文都要SecOC保护8字节挤得太紧全保护不现实。哪些报文受保护是风险评估TARA的结果优先保护的报文涉及安全功能的信号刹车、转向、动力——伪造它们直接威胁人身安全远程可触发的指令TBOX下发的车门解锁、远程启动关键配置参数标定、密钥可以不保护的非安全相关信号车窗位置、座椅调节低风险数据法规视角UN R155 Annex 5 和 GB 44495 都要求对车内网络安全威胁采取缓解措施——SecOC就是R155评估里车内网络报文伪造威胁的标准缓解方案之一。8、TBOX在SecOC体系里的角色TBOX 在车内网络中是**“敏感节点”**——它同时连接车外蜂窝/WiFi和车内CAN总线是攻击者进入总线的跳板TBOX的SecOC职责下行的安全报文TBOX→ECU车门解锁、远程启动等指令必须SecOC保护——防止攻击者借TBOX的通信通道向ECU发伪造指令上行报文验证ECU→TBOXTBOX接收的ECU报文也要验证MAC——防止伪造ECU数据欺骗TBOX配合密钥管理TBOX的HSM存储SecOC密钥执行CMAC计算一句话TBOX是车内总线的城门SecOC是城门的验兵牌——进城总线的每条关键消息都要验明正身。9、SecOC车内通信安全总结需求法规/客户规范对应解决方案GB 44495 7.2.9 内部网络区域划分边界防护车内信息安全域划分客户需求6.1.1客户需求 6.1.2 车内通信身份标签与验证报文加载身份标识验证发送方身份客户需求 6.2.1 认证密钥和加密密钥分离密钥管理认证密钥≠加密密钥客户需求 6.2.2 车内关键数据通信防护SecOC加密/认证/抗重放客户需求 6.2.4 消息校验和认证SecOC MAC验证CMAC-AES128客户需求 6.3.1 车内网络数据状态监测总线监测异常告警10、给TBOX工程师的5条实战建议SecOC不是选配是该配涉及安全的报文车控指令、关键配置必须保护UN R155/GB 44495评估会查密钥必须进HSMSecOC密钥放软件白搭MCU内置HSM如S32K144就是干这个的新鲜度同步是最大坑ECU复位/休眠唤醒后FV要重新同步落地时重点测这个场景按TARA决定保护范围不是所有报文都保护先保护伪造了会出人命的按总线选配置Classic CAN8字节用Profile 34bit FV28bit MAC精打细算CAN-FD64字节用1字节FV7字节MAC载荷56字节以太网可配更宽裕甚至叠加TLS——选总线时就要想清楚SecOC配置空间11、系列进度这是《TBOX信息安全实战系列》第8篇。系列全景篇主题状态第1篇国内法规GB 44495 全景解读✅第2篇国内外法规对比✅第3篇网络安全需求怎么定双客户对标✅第4篇客户需求细节全拆解 与国标对比✅第5篇硬件安全SE/HSM/TEE对比需求映射✅第6篇系统/数据安全SELinux数据分级✅第7篇车云通信安全双向认证✅第8篇车内通信安全SecOC✅ 本篇第9篇安全启动安全升级待写第10篇渗透测试IDPS运营闭环待写下一篇TBOX安全启动安全升级实操——从信任根到OTA逐级验签防降级失败恢复。❤️文末福利❤️1、关注【擎天柱工坊】获取更多免费学习视频和资料2、私信回复【汽车硬件设计】领取原理图、PCB、学习视频
2015年安全研究员通过远程接口黑进一辆切诺基的CAN总线向刹车系统发送伪造指令——车在高速上被远程劫持。这件事震惊了整个汽车行业CAN总线从设计之初就没考虑过认证任何接到总线上的设备都能发任意ID的报文其他ECU无条件接收。SecOCSecure Onboard Communication就是AUTOSAR给出的解药。这篇把SecOC的原理、报文结构、收发流程、与TBOX的关系完整拆解。先讲清楚CAN的原罪CAN总线诞生于1980年代设计目标是低成本、高可靠、实时性——压根没考虑安全明文广播所有报文在总线上明文传输谁都能看无认证接收任何节点都能发任意ID其他节点无条件接收以前车是封闭的问题不大。但现在——TBOX、车机、OTA网关都接在总线上任何一个被攻破攻击者就能通过CAN总线向动力、底盘、刹车系统发指令。这就是一条报文引发的惨案。1、SecOC 是什么AUTOSAR 的车内消息认证标准SecOCSecure Onboard Communication是 AUTOSARAUTOSAR Classic 4.2 引入的车内通信安全模块。核心思想一句话给关键的CAN报文加一层身份验证 防重放——接收方先验证验证通过才处理失败就丢弃。SecOC 不加密数据车内实时总线做加密代价太高它做的是认证MAC消息认证码→ 证明消息是合法发送方发的防伪造、防篡改Freshness Value新鲜度值→ 证明消息不是重放的防重放对比第7篇车云通信TLS证书是点对点安全SecOC是总线广播安全——一个防通道、一个防报文正好一外一内。2、 SecOC 报文结构8字节里挤出安全Classic CAN 一帧只有 8 字节怎么塞进认证信息AUTOSAR 的默认配置字段长度作用原始载荷剩余空间业务数据新鲜度值FV截断4 bit防重放MAC 截断28 bit防伪造/篡改MAC 计算范围CMAC(K, 消息ID 载荷 完整新鲜度值)为什么要截断完整MAC是128bit16字节完整FV更长——8字节的CAN帧根本塞不下。所以FV只发低4bit接收方用自己的计数器收到的低4bit重构完整FVMAC只发高28bit截断后的MAC仍能提供足够安全强度8字节 vs 64字节 vs 以太网SecOC 在三种总线上的配置总线帧长决定了安全信息的挤出空间——这是SecOC落地最实际的差异总线帧长典型配置载荷特点Classic CAN8字节Profile 3FV截断4bit MAC截断28bit约3字节镣铐最重只能保护关键报文Classic CAN8字节Profile 1FV截断8bit MAC截断24bit约4字节中间配置FV步进更大CAN-FD64字节FV 1字节 MAC 7字节56字节空间宽裕安全信息可放宽车载以太网100/1000BASE-T1三种Profile可配甚至叠加TLS/IPsec充足游刃有余可多层安全Classic CAN8字节——戴着镣铐跳舞AUTOSAR Profile 3JASPARFV截断4bit MAC截断28bit载荷只剩约3字节Profile 18bit FV 24bit MACFV步进更大但MAC弱一点只能保护最高优先级的报文安全功能信号且要精打细算每1bitCAN-FD64字节——空间宽裕典型配置FV取1字节 MAC取7字节共8字节安全信息载荷56字节发送时SecOC收到56字节报文加8字节安全信息 → 64字节SIPDU发出接收时64字节报文 → 验签 → 转出56字节给上层载荷是Classic CAN的近19倍FV/MAC都能放宽保护范围可以更大车载以太网——游刃有余SOME/IP SecOCFV/MAC可配到更长甚至完整128bit MAC还能叠加TLS/IPsec第7篇的双向认证在以太网上也能用适合域控/网关的大流量场景工程结论Classic CAN上SecOC是精打细算每个bit都金贵CAN-FD上SecOC是正常发挥以太网上SecOC可以豪华配置甚至叠加多层。选总线时就要想清楚SecOC的配置空间。3、 收发流程认证 vs 验证发送方认证取新鲜度值FV单调递增计数器/时间戳调 CMAC 计算 MACCMAC(K, 消息ID载荷FV)组装安全报文载荷 FV低4bit MAC高28bit发到总线接收方验证从报文中取FV低4bit MAC用本地计数器收到的低4bit重构完整FV重算MAC与收到的比对验证失败 → 静默丢弃不送上层软件组件静默丢弃是关键设计——验证失败的消息直接不上层接收软件组件根本看不到伪造报文从源头阻断。4、新鲜度值FV防重放的核心重放攻击攻击者录下一条合法报文比如解锁车门过会儿再发一次——没有防重放机制ECU会照单全收。新鲜度值就是计数器每条报文带一个单调递增的FV接收方记住上次收到的最新值——重放的旧报文FV小于当前值验证失败。AUTOSAR 的FV构造常见配置多计数器组合Trip Counter行程计数器每次车辆启动1由网关广播同步Reset Counter复位计数器固定间隔1也在同步报文中Message Counter消息计数器每条消息1复位时清零Reset Flag复位计数器的低几位同步报文由指定的同步节点通常是网关周期性广播 Trip Counter 和 Reset Counter让全网节点FV保持同步。同步报文本身也被MAC保护——防止攻击者伪造同步报文搞乱FV。工程难点提示FV同步是最容易出问题的地方——ECU复位、休眠唤醒、总线恢复后如果FV没重新同步就会出现合法报文被误杀或重放窗口打开。这是SecOC落地最常见的坑。5、密钥管理SecOC 的命门MAC是对称密码发送方接收方用同一个密钥K所以密钥安全 SecOC 安全密钥管理要点密钥必须存HSM硬件安全模块——呼应第5篇软件存密钥钥匙贴在门上密钥通过AUTOSAR Crypto Stack执行CSM/CryIf/加密驱动密钥按车辆/ECU组独立分发整车下线刷写时静态分配或云端动态下发更换ECU时全网重配密钥新密钥用已有密钥加密传输防止旁观重配窃取密钥对TBOX的含义TBOX 的 MCU如 S32K144内置 HSMSecOC 的 CMAC 计算和密钥存储都在 HSM 里做——这正是第5篇说MCU侧HSM做安全启动和密钥管理的具体应用场景之一。6、SecOC 防的三类攻击攻击原理SecOC如何防重放重发旧报文新鲜度值单调递增旧值验证失败伪造冒充发送方发指令MAC验证失败没有密钥伪造不了篡改改报文载荷载荷一变MAC就不匹配但注意SecOC不防窃听CAN明文广播MAC不加密数据——要防窃听需要报文数据加密CanTransceiver/报文加密是另一套方案。SecOC解决的是数据来源可信不是数据内容保密。7、哪些报文需要SecOC——TARA来决定不是所有CAN报文都要SecOC保护8字节挤得太紧全保护不现实。哪些报文受保护是风险评估TARA的结果优先保护的报文涉及安全功能的信号刹车、转向、动力——伪造它们直接威胁人身安全远程可触发的指令TBOX下发的车门解锁、远程启动关键配置参数标定、密钥可以不保护的非安全相关信号车窗位置、座椅调节低风险数据法规视角UN R155 Annex 5 和 GB 44495 都要求对车内网络安全威胁采取缓解措施——SecOC就是R155评估里车内网络报文伪造威胁的标准缓解方案之一。8、TBOX在SecOC体系里的角色TBOX 在车内网络中是**“敏感节点”**——它同时连接车外蜂窝/WiFi和车内CAN总线是攻击者进入总线的跳板TBOX的SecOC职责下行的安全报文TBOX→ECU车门解锁、远程启动等指令必须SecOC保护——防止攻击者借TBOX的通信通道向ECU发伪造指令上行报文验证ECU→TBOXTBOX接收的ECU报文也要验证MAC——防止伪造ECU数据欺骗TBOX配合密钥管理TBOX的HSM存储SecOC密钥执行CMAC计算一句话TBOX是车内总线的城门SecOC是城门的验兵牌——进城总线的每条关键消息都要验明正身。9、SecOC车内通信安全总结需求法规/客户规范对应解决方案GB 44495 7.2.9 内部网络区域划分边界防护车内信息安全域划分客户需求6.1.1客户需求 6.1.2 车内通信身份标签与验证报文加载身份标识验证发送方身份客户需求 6.2.1 认证密钥和加密密钥分离密钥管理认证密钥≠加密密钥客户需求 6.2.2 车内关键数据通信防护SecOC加密/认证/抗重放客户需求 6.2.4 消息校验和认证SecOC MAC验证CMAC-AES128客户需求 6.3.1 车内网络数据状态监测总线监测异常告警10、给TBOX工程师的5条实战建议SecOC不是选配是该配涉及安全的报文车控指令、关键配置必须保护UN R155/GB 44495评估会查密钥必须进HSMSecOC密钥放软件白搭MCU内置HSM如S32K144就是干这个的新鲜度同步是最大坑ECU复位/休眠唤醒后FV要重新同步落地时重点测这个场景按TARA决定保护范围不是所有报文都保护先保护伪造了会出人命的按总线选配置Classic CAN8字节用Profile 34bit FV28bit MAC精打细算CAN-FD64字节用1字节FV7字节MAC载荷56字节以太网可配更宽裕甚至叠加TLS——选总线时就要想清楚SecOC配置空间11、系列进度这是《TBOX信息安全实战系列》第8篇。系列全景篇主题状态第1篇国内法规GB 44495 全景解读✅第2篇国内外法规对比✅第3篇网络安全需求怎么定双客户对标✅第4篇客户需求细节全拆解 与国标对比✅第5篇硬件安全SE/HSM/TEE对比需求映射✅第6篇系统/数据安全SELinux数据分级✅第7篇车云通信安全双向认证✅第8篇车内通信安全SecOC✅ 本篇第9篇安全启动安全升级待写第10篇渗透测试IDPS运营闭环待写下一篇TBOX安全启动安全升级实操——从信任根到OTA逐级验签防降级失败恢复。❤️文末福利❤️1、关注【擎天柱工坊】获取更多免费学习视频和资料2、私信回复【汽车硬件设计】领取原理图、PCB、学习视频
