文章总结： 本文深度解析智能汽车车载网络通信安全架构，指出智能汽车因外部连接增多而攻击面扩大，CAN总线存在无身份认证等先天短板。文章提出分层纵深防御体系，涵盖安全启动、SecOC通信认证、入侵检测及云端运营，并强调ISO21434等法规对架构设计的强制影响。建议工程师在架构设计阶段即融入安全机制，重视密钥管理与信任边界划分。
综合评分： 88
文章分类： 车联网安全,网络安全,安全架构,解决方案
智能汽车车载网络通信安全架构深度解析
谈思实验室
2026年9月28日 18:17
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
智能汽车这几年最大的变化，不是屏幕变大、算力变强，而是它从一台”机械产品”悄悄变成了一台”会联网的计算机”。前几年出去和同行聊架构，十有八九聊的是传感器、芯片、自动驾驶算法；但是从2021年之后，”车载网络通信安全”几乎成了躲不开的话题。不是跟风，而是现实逼着大家必须做——远程攻击的事故通报、法规的强制落地、供应链审核的要求，都在把网络安全往架构建模阶段推。
这篇文章想聊的，就是智能汽车车载网络通信安全架构这件事。我会把车载网络里最容易出问题的通信链路、主流的安全机制、分层的防护设计思路、以及法规落地后对架构的实际影响，尽量用做项目 的视角讲清楚。适合正在做智能网联汽车域控制器、车联网网关、自动驾驶平台的工程师，也适合刚想转行进入车载安全方向、想建立整体认知的读者。
01
为什么智能汽车成了”网络安全”的头号战场
1.1 攻击面从无到有：一辆现代智能车到底有多少可被攻击的入口
传统燃油车时代，车辆和外部世界联系很少，顶多是收音机接收信号，OBD诊断接口偶尔被维修店接一下。攻击者想远程控制一台车，几乎想象不出路径。但现在不一样了，智能汽车的对外连接通道多到离谱：
- 4G/5G蜂窝网络，通过T-Box接入，这是最经典的远程攻击入口；
- 蓝牙、Wi-Fi，手机钥匙、无线CarPlay、OTA下载都走这些通道；
- V2X短距离通信，车与车、车与路侧设备直接交换消息；
- USB接口、OBD诊断口，既是维修诊断的通道，也是物理接触的攻击点；
- 云端后台，通过APP远程控制、数据采集，间接进入车端。
光是”入口多”还不算致命，致命的是这些入口背后都链接着车内的高速网络。早期车内的ECU（电子控制单元）之间用CAN总线互相通信，而CAN 总线在设计之初假设”车内是一个可信环境”，没有做任何身份认证。结果是什么呢？只要有一个入口被攻破，攻击者就像拿到了内网的”合法身份”，可以沿着CAN总线往所有ECU里发指令。
2015年那次著名的远程攻击实验里，研究人员通过车载娱乐系统进入CAN网络，最终控制了转向和制动，整车在高速公路上被迫熄火。这个案例对行业的影响是巨大的，它把”车载网络通信安全”从论文里拉进了真实的产品需求清单。
1.2 车载环境不能直接套用IT安全方案的深层原因
很多人第一次接触车载网络安全时会想：这东西在IT领域不是有一堆成熟方案吗？防火墙、入侵检测、TLS加密、公钥基础设施，直接把云计算那套搬过来不就行了？
理论上可以，但实际上搬不动，原因在于车载环境的约束很特殊。
第一，ECU的资源极其有限。一块典型的MCU可能只有几十MHz的主频、几百KB的Flash、几十KB的RAM。在这种资源下跑TLS握手是不现实的，一个完整的握手需要大量非对称运算和缓冲，启动时间也会拉长到不可接受。
第二，实时性要求是硬杠子。动力系统CAN报文的周期往往是10ms级别，制动、转向相关的控制消息延迟抖动不能超过几毫秒。安全机制如果引入明显时延，哪怕只是多1ms，都可能影响控制品质，甚至引发系统性问题。
第三，车辆生命周期极长。一台车要安全运行15年甚至更久，这意味着密钥管理、证书轮换、固件升级的机制都要设计成”长期可运维”的形态，而不是像互联网服务那样可以随时发版修复。
第四，车内网络的信任模型已经彻底变化。以前CAN报文谁都能发、谁都能收，默认大家都可信；现在任何一个ECU都可能被攻破，所以车内通信必须假设”网络不可信、节点可能被攻破”，所有的安全设计都要基于这个前提。
换句话说，车载安全架构的本质，是在”极低算力、极低延迟、超长生命周期、不可信网络”这四堵墙之间找到平衡。理解了这些约束，才能理解后面为什么要分层、为什么要用SecOC而不是直接跑TLS、为什么硬件安全模块那么重要。
02
从CAN到车载以太网：先认清网络基石，再谈安全设计
想设计一个安全架构，第一步不是选加密算法，而是先摸清底下是什么网络、什么协议、有什么先天短板。车载网络经过几十年演进，目前不是”单一总线打天下”的状态，而是一个多种总线混合的分层网络。
2.1 CAN/CAN FD：三十年的老伙计，安全短板与生俱来
CAN（Controller Area Network）总线是1980年代为汽车开发的现场总线，至今仍是动力、车身、底盘域的主流通信协议。它的设计核心是”可靠”，不是”安全”。
CAN协议的报文格式很简洁——帧ID + 数据段 + 校验段，没有发送者身份标识，没有消息认证码，数据也是明文传输。任何一个节点只要连在总线上，就可以收发所有消息。这个”广播式、无身份、无加密”的特性，在安全视角下几乎等于裸奔。
具体来说，CAN网络有哪几个致命弱点：
- 伪造消息：攻击者只需要知道报文的ID和信号布局（很多还是公开标准），就能伪装成任意ECU发消息，比如伪造制动请求、伪造车速信号；
- 窃听数据：虽然车内数据的敏感度不如用户手机，但GPS轨迹、电池状态、驾驶模式这些信息也能反映用户隐私；
- 重放攻击：即便攻击者当时不理解报文含义，只要录下一段合法报文，过一会儿再原样发出去，就可能触发动作，比如解锁车门；
- 拒绝服务：CAN的仲裁机制决定了高优先级报文先发，攻击者如果不停发高优先级帧，就能把网络带宽耗尽，让其他ECU无法通信。
CAN FD（CAN with Flexible Data-Rate）改进了带宽和单帧长度，从经典CAN的8字节提升到最大64字节，也因此给SecOC消息认证码提供了空间。但注意——CAN FD只是提高了”承载能力”，并没有引入任何安全机制，安全短板和经典CAN是相同的。
在实际项目中，我的一个体会是：评估一个车载网络的攻击面，先画一张”谁在总线上”的图。只要还有传统CAN总线存在，就不能假设攻击者需要很高的技术水平，网上公开的CAN工具和协议逆向教程太多了，一位熟练的嵌入式开发者用一块几十块钱的板子就能接上车内网络做分析。这跟IT领域的攻击门槛完全不是一个量级。
2.2 车载以太网与新协议：带宽上来了，安全能力也上来了
随着自动驾驶、智能座舱、OTA大升级包的出现，CAN总线的带宽明显不够用了。摄像头每秒产生数百兆比特的数据，诊断和刷写也要几十兆的传输率，于是车载以太网进入了主流架构。
车载以太网用的物理层标准跟传统IT以太网不一样——100BASE-T1和1000BASE-T1使用单对非屏蔽双绞线，针对车载电磁环境做了优化，但上层的TCP/IP协议栈和IT以太网几乎完全对齐。这意味着什么？意味着IT领域几十年来积累的安全协议栈，比如TLS、IPsec、MACsec，理论上都可以复用到车载以太网上。
而且车载以太网天然支持VLAN（虚拟局域网）和流量隔离。在一台采用以太网骨干的域控制器架构里，可以把动力域、底盘域、智驾域的流量划分到不同VLAN，再配合访问控制列表（ACL）做二层隔离，攻击者就算拿下一个多媒体系统的入口，也很难直接摸到制动系统的报文。
不过车载以太网也有自己的”安全幼稚”：很多设计团队的思维还停留在”把功能跑通就行”，交换机上没配ACL、没有对ARP和DHCP做防护、调试网口在生产车上没关掉——这些都是我在项目评审里反复看到的问题。协议是安全的，部署姿势不对，照样白搭。
这里补充一句：TSN（Time-Sensitive Networking）的应用越来越广，它让车载以太网有了确定性的时延保障，这算好事。但TSN本身也不含安全机制，它只是解决QoS问题，安全要么走MACsec（链路层加密认证），要么走上层协议。
2.3 网络信任边界怎么画：域架构与分区隔离的思考
清楚了底层协议之后，就要认真想架构问题了：车内这么多ECU，哪些归为”可信区域”，哪些归为”不可信区域”，区域之间怎么隔离？
目前主流的整车电子电气架构是”域集中式”——按功能分成动力域、底盘域、座舱域、智驾域、车身域等，域内的ECU通过CAN/CAN FD通信，域间的数据走以太网骨干。再往前演进，会走向”中央计算+区域控制器”的架构。无论哪种，安全架构设计都会把网络划分成几个信任级别：
- 最高信任级：动力、制动、转向等安全关键ECU。这些节点不允许接收来自外部或娱乐系统的未认证指令；
- 中等信任级：远程信息系统（T-Box）、座舱域。它们需要对外通信、需要升级、需要连接用户手机，因此必须被视为”可能被攻破”的区域；
- 低信任级/不可信：所有外部接口，包括USB、蓝牙、Wi-Fi、蜂窝网络、V2X，统统默认不可信。
信任边界一旦确定，架构上就要落地三个动作：
- 流量隔离：用VLAN、网关路由规则、防火墙规则，让跨域流量必须经过明确的策略检查；
- 协议转换点的安全强化：域控制器或中央网关往往是”内外交流”的咽喉，所有从低信任区进入高信任区的报文，都要在这里做格式校验、身份认证、深度检查；
- 最小权限原则：哪怕在同一信任级内，ECU间也不应该能随意读写对方的服务，尽量按需授权。
我见过不少团队在画架构图时画得很漂亮，圈圈套圈圈、箭头有红有绿，但问到底层怎么隔离的，就支支吾吾。其实信任边界不是一张图，它是实实在在的VLAN配置、路由表、防火墙策略和网关白名单。每一条流量是从哪进、从哪出、经没经过策略检查，都应该能追查清楚，这才是”画了边界”。
03
分层纵深防御的车载通信安全架构：从芯片信任根到入侵检测
车载安全架构的核心思想，业内已经形成了共识：不能只靠单点防护，要建立纵深防御。层次从底到顶大致是这样的：芯片硬件安全模块 → 安全启动 → 系统隔离 → 通信安全（SecOC/TLS） → 入侵检测 → 云端安全运营。下面我把每一层的价值和落地细节展开讲。
3.1 安全启动：可信根基如何从芯片一路传导到应用
智能汽车的ECU现在普遍使用HSM（Hardware Security Module）或类似的硬件安全单元。这颗安全芯片能干嘛？它可以安全存储密钥，可以执行硬件加速的加解密、签名验签，更重要的是它提供了一项基础能力：可信启动。
可信启动的逻辑链条是这样的：
- 芯片上电后，从ROM里的不可变引导代码开始运行；
- Bootloader使用存储在HSM或eFuse里的根密钥，验证下一阶段镜像（比如OS内核）的签名；
- 签名验证通过后才加载执行，系统继续验证应用层的签名；
- 任何一层验证失败，系统拒绝启动或进入恢复模式。
为什么这一步是整个安全架构的”地基”？因为如果启动链不可信，后面所有软件层面的安全机制都是建立在沙滩上的。攻击者如果能在启动阶段植入恶意代码，那么它就能篡改任何后续的安全策略——比如把SecOC的认证密钥dump出来、关掉入侵检测的报告功能。
实际操作中，安全启动有一个很常见的”坑”：密钥管理流程不闭环。有的团队在开发阶段把签名私钥放在所有工程师都能访问的构建服务器上，结果就是任何人都能签出”合法”的固件镜像。安全启动设计得再好，私钥泄露等于整个信任链崩塌。所以架构师在设计阶段就要把密钥的分级管理和权限隔离考虑进去——根密钥离线保管，开发密钥和量产密钥严格分离，构建和发布流程加权限审计。
3.2 SecOC与通信加密：CAN时代最需要补齐的短板
说完了节点层面的可信根基，再看通信链路本身。针对CAN/CAN FD总线上没有认证、没有防重放的短板，AUTOSAR提出了一套标准化的解决方案：SecOC（Secure On-Board Communication）。
SecOC的核心逻辑不复杂——发送方在原始报文中追加一段消息认证码（MAC），接收方用共享的密钥验证这段MAC，确认报文确实来自合法发送方且没有被篡改。为了防止重放攻击，SecOC还引入了新鲜度值（Freshness Value），每次报文中带一个新鲜度参数，接收方记录最近收到的最大值，旧值重放直接拒绝。
我在项目里落地SecOC时，有几个实际问题必须想清楚：
- 新鲜度值的管理：最常见的是基于时间和计数器混合的机制。计数器方案简单可靠，但ECU重启后计数器重置可能造成同步丢失；纯时间方案需要各个ECU都有可靠的时间源。现实方案往往是”时间为主、计数器为辅”或者反过来；
- MAC截断：CAN FD数据场最多64字节，不可能放一个完整的128位MAC。通常取MAC的低32位或64位，但截断的位数直接决定了防伪强度，需要根据报文周期和安全等级来权衡；
- 密钥分发：SecOC使用的对称密钥怎么部署到各ECU？常见做法是在产线下线时通过安全的刷写通道注入，或者由网关/密钥中心在车辆第一次上电时分发。这个过程设计不好，产线效率会大受影响。
一个更宏观的提醒是：SecOC不是万能的。它保护了”消息认证”和”防重放”，但通信内容依然是明文。如果报文本身涉及隐私数据（比如位置轨迹），还得叠加链路加密。而对于走以太网的场景，可以使用IPsec或MACsec来做更全面的机密性和完整性保护。
对于以太网通信，尤其是面向外部（T-Box到云端、V2X通信、OTA下载），当前的主流选择是TLS 1.3。TLS的好处是生态成熟，证书体系完整；坏处是握手开销大、计算成本高。车载场景里，TLS通常用在会话层面，比如和云端建立一次HTTPS连接，然后做批量数据传输，而不是对每一个实时报文加密——实时性强的控制信号还是要走SecOC这种轻量方案。
3.3 入侵检测与安全运营：攻击发生后的最后防线
安全架构的最后一个关键层次是”假设会被攻破”（Assume Breach）之后的应对。这就要引入车载入侵检测系统（IDPS，Intrusion Detection and Prevention System）。
IDPS在车端可以是独立的安全组件，也可以集成在网关或域控制器中。它的工作方式有两种：
一种是基于规则的检测。比如监控CAN总线上报文频率是否符合预期、是否出现未知ID、是否出现异常的 新鲜度值跳变；对以太网流量，则可以检测异常的连接端口扫描、异常的ARP响应等。规则检测的优点是开销低、匹配准确度高；缺点是只能发现已知攻击模式。
另一种是基于行为/异常的检测。通过机器学习 模型学习ECU的正常通信模式，一旦流量偏离基线就告警。这种方法对未知攻击的识别率更好，但车载嵌入式平台的算力通常不足以跑复杂的模型，误报率也是现实问题。在实际项目里，我倾向于采用”规则为主、少量轻量异常检测为辅”的策略，既控制误报，又能捕捉一些规则覆盖不到的情况。
车端检测到异常之后，消息通过安全通道上报给云端的安全运营中心，由专业团队分析并给出处置建议（比如远程切断某ECU通信、冻结某个会话、推送应急安全更新）。这才叫”闭环”——只检测不处置，告警永远躺在日志里，基本等于白做。
这里分享一条比较实在的经验：IDPS的规则和告警阈值一定要跟着真实车型数据调，不能照搬参考设计。工程车和量产车、市区路况和高速路况，报文特征差异很大。一套阈值调到”能抓到攻击又不误报”级别，没有一个月以上的真实数据回放训练，很难做到。
04
合规与标准不是走形式：ISO 21434、R155如何重塑架构设计
前几年做车载安全还可以说是”自选动作”，但到了2022年之后，做安全已经成为”强制动作”。全球主要市场的监管和标准框架基本都落地了，架构师再不考虑合规，整车拿不到准入资格，项目连量产都上不了。
4.1 从TARA到安全概念：标准要求如何一步步落进架构图
ISO 21434（Road vehicles — Cybersecurity engineering）是车载网络安全的事实标准。它覆盖了从概念、开发、生产、运维到退役的全生命周期网络安全要求。对架构师来说，最直接的影响是把TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）变成了开发流程中不可跳过的一环。
TARA的流程是这样的：
- 定义目标资产（比如ESP的制动控制功能、门锁控制报文、OTA升级包）；
- 分析可能影响这些资产的威胁场景（比如消息伪造、重放、拒绝服务、密钥提取）；
- 评估攻击可行性（攻击者需要什么样的物理访问？技术门槛有多高？）；
- 评估受损影响（能不能导致车辆失控？数据泄露是多少人的隐私？）；
- 计算出风险值，确定哪些风险需要”减缓”，哪些可以”接受”。
TARA输出的是”安全概念”——针对高风险的威胁场景，架构上该上什么安全机制。比如TARA发现”远程攻击者可以通过T-Box的蜂窝连接伪造CAN上行报文”，安全概念就是”在网关处对来自T-Box的报文做身份认证+白名单过滤”。
实际项目中，我发现TARA环节最容易出问题的不是”不会分析”，而是”分析和设计脱节”。安全概念写了一堆，最后架构图里根本没体现，或者体现了但没有落实到具体方案和测试用例。所以我现在做项目，会要求安全工程师、系统架构师、软件开发工程师坐在一起过TARA结论，确认每条风险都有对应的架构措施、有落地的技术方案、有对应的验证计划。
4.2 认证与取证：架构评审中反复被问到的几个问题
UNECE R155（联合国欧洲经济委员会第155号法规）要求车辆制造商建立网络安全管理体系（CSMS），并通过认证后才能申请车型准入。这意味着第三方审核员会审你的网络安全活动，而且审得很细。
我在配合认证和架构评审的过程中，被反复问到的问题基本是这几类：
- 你们的安全概念是怎么从TARA推导出来的？有没有可追溯的矩阵，从威胁到风险、从风险到安全需求、从安全需求到测试用例，每一步都有记录？
- 安全启动的密钥体系是怎样的？开发、生产、售后分别怎么管理？有没有密钥轮换和废弃的流程？
- SecOC的新鲜度值机制在ECU复位后如何同步？有没有考虑到整车掉电、时钟不同步等极端场景？
- OTA升级流程里，升级包怎么验签？回滚攻击（把固件回退到有漏洞的旧版本）怎么防？
- 供应商提供的第三方组件，安全责任边界在哪里？有没有SBOM（软件物料清单）和漏洞跟踪机制？
这些问题看起来是合规流程问题，实际上每一问都直击架构设计的深度。审核员不需要你背标准条款，他需要看到你真正把安全”做进了”设计和开发流程里，而不是事后补一份文档。
05
实战中的取舍与踩坑：一个车载安全架构师的日常
理论框架说了不少，分享一些我在实际项目中碰到的真实问题和处理思路。安全架构不是”选型正确就万事大吉”，更多的时候是在各种约束之间做取舍，而且坑往往藏在细节里。
5.1 性能和安全的天平：加解密开销的真实测量
先说性能。在MCU上做HMAC运算，听起来不是什么大活儿，但放在高速CAN FD报文的场景里就要认真算账了。假设一个动力控制ECU每10ms发一条CAN FD消息，每条消息要做一次HMAC计算（取64位MAC），那么一秒钟就是100次。单片机上如果HSM硬件加速，每次算HMAC-SHA256（截断64位）大约需要0.1~0.3ms；如果没有硬件加速，纯软件实现可能要1~2ms。对于10ms周期的报文来说，这就占了10%~20%的CPU资源，完全不可接受，必须启用硬件加速。
所以选型时的建议很明确：只要做通信安全，ECU就必须有一颗带HSM的MCU或SoC。这不是可选项，是必需品。我见过某些团队为了省几毛钱成本，在关键ECU上选了不带HSM的芯片，后面只能把SecOC做成”部分报文认证”，留下了一堆安全漏洞，得不偿失。
另外还要注意，非对称运算（RSA/ECC签名验签）在MCU上更慢。一个ECC P-256签名验证即使有硬件加速，也需要几毫秒，所以非对称运算只适合用在低频场景，比如固件验签、证书验证、TLS握手，绝不能用在周期性的高速报文里。对称运算（AES、HMAC）才是报文级的首选。
5.2 密钥管理：安全架构里最容易被低估的难题
如果说算法和协议是安全架构的”招式”，那密钥管理就是”内功”。再强的加密算法，密钥泄露等于白搭；再完善的分层架构，密钥分布混乱照样会被一锅端。
我看到的常见问题有这几种：
- 所有ECU共享一把密钥。好处是部署简单，坏处是一旦一个节点被攻破，整车的通信保护全部失效。正确做法是”一车一密”或者至少”域一密”，每个车下线时生成独立的密钥集；
- 私钥常驻在可读存储介质中。哪怕有HSM，有些工程师为了方便调试，把私钥导出存在Flash的明文区域。这在产线和售后返修阶段尤其容易发生，必须通过权限控制、日志审计和HSM的”密钥不可导出”属性来封堵；
- 缺少密钥轮换机制。法规和标准都要求密钥不能一用到底。尤其在运维周期长达15年以上的车辆上，长期不轮换几乎等于等着被攻击。轮换过程要设计成不影响用户正常用车，通常利用OTA后台悄悄完成。
产线环节的密钥注入也是一个容易忽略的细节。每个ECU在产线下线前要完成密钥注入，这个过程会占用节拍时间。如果安全策略要求所有ECU都注入独立密钥，产线的设备投入和操作时间都会显著上升。架构上可以考虑”主密钥+派生密钥”的方案，由网关或密钥中心根据主密钥和ECU ID派生各节点独立密钥，减少产线负担。
5.3 供应链与开发流程：安全在组织层面的落地阻力
最后聊一个很多人不爱提但必须面对的问题：车载安全架构的真正落地，最大的阻力往往不是技术，而是流程和供应链。
一家整车厂或Tier 1供应商的架构里，有大量ECU来自不同供应商，每家供应商的安全能力参差不齐。有的供应商连安全启动都没做过，有的供应商的HSM驱动漏洞百出。这时候整车厂作为系统集成方，必须在技术协议里明确安全需求、在验收测试里加入安全用例、在供应商开发过程中进行安全评审。这些工作非常耗时耗力，但不做的话，整车的安全架构就是”木桶理论”里的短板——一个不安全的ECU就能拖垮整个安全体系。
开发流程的影响也很明显。引入安全活动之后，开发周期变长了。TARA要做，安全需求要写，安全测试要执行，安全文档要维护。这种”额外工作量”容易在项目压力下被压缩。但安全这东西真的很现实——产品一旦进入量产遭遇大规模远程攻击，损失不是多几个月开发成本能衡量的。
踩过几次坑之后，我的体会是：一开始就要把安全当成”功能需求”来做，而不是当成”附加活动”来做。在项目kickoff阶段就明确安全负责人、安全计划和资源预算，每周有固定的安全例会，每一次架构变更都要过一遍安全评估。只有这样，安全才能从PPT里走出来，真正长到架构的血肉里去。
车载网络通信安全架构这条路，没有终南捷径，标准还在演进，攻击手法也在升级。但底层逻辑不会变——把信任边界画清楚，把每一层防护做实，把密钥和证书管好，在性能和有效性之间找到平衡。踩过坑、填过坑、把这些写下来，希望能给正在走同一条路的工程师省一些时间。
来源：CSDN@「孙晓岸」
https://blog.csdn.net/weixin_29323273/article/details/166572090
end
谈思汽车媒体门户
精品活动推荐
AutoSec系列沙龙
专业社群
部分入群专家来自：
新势力车企：
特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……
内资传统主流车企：
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……
全球领先一级供应商：
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……
二级供应商(500+以上)：
中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……
人员占比
公司类型占比
文章
不要错过哦，这可能是汽车网络安全产业最大的专属社区！
首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：谈思实验室 《智能汽车车载网络通信安全架构深度解析》