某车企系统遭黑客入侵车辆失控 汽车联网时代信息安全成焦点 ISO21434标准解读 整车设计生产运维全流程合规指南 企业如何应对认证要求与常见漏洞
最近看到一条新闻，心里挺不是滋味的。美国有辆Jeep Cherokee被黑客远程入侵，车速从零直接飙到一百一十公里，方向也失灵了。这不是电影情节，是真真正正发生在现实中的事。开车的人当时完全懵了，只能在高速公路上拼命踩刹车，差点就出了大事。
这件事直接把汽车信息安全推到了风口浪尖。
从一辆车失控说起
2015年，安全研究员Chris Valasek和Charlie Miller做了个让人后背发凉的东西——他们通过电话网络，远程入侵了一辆正在行驶的Jeep Cherokee。
他们是怎么做到的？简单来说，那辆车的多媒体娱乐系统有个漏洞，黑客利用这个入口，进入了车辆的内部网络，然后一步步拿到了对刹车、转向、油门的控制权。
这件事之后，FEMA（美国联邦紧急事务管理局）直接介入了，要求克莱斯勒召回140万辆车。
这不是孤例。后来陆续有研究团队对特斯拉、宝马、丰田等品牌做过渗透测试，发现了很多类似问题：通过蓝牙进入车内网络、通过OTA升级包植入恶意代码、通过车载诊断接口（OBD）直接操控……
汽车，这个曾经最封闭的机械产品，现在已经变成了一个跑在四个轮子上的”超级智能手机”。
一辆现代汽车里有多少个ECU（电子控制单元）？
- 普通家用车：至少60~100个
- 高端电动车：超过150个
- 里面跑的代码行数：超过1亿行（比windows还多）
这么多代码，这么多网络连接，安全防护就跟守一座城一样，任何一个城门破了，整座城都危险。
为什么汽车行业对信息安全这么”迟钝”？
说实话，在很长一段时间里，汽车工程师根本不看网络安全。
他们的培训里讲的是：结构强度、发动机热效率、NVH（噪声振动）、碰撞安全。从来没教过”怎么防止黑客通过CAN总线篡改刹车信号”这种事儿。
行业里有句玩笑话：”汽车的安全性是从外往内看的，信息安全是从内往外看的。”
过去的汽车，每个ECU之间用CAN总线通信，信号不加密、不验证。你接一个OBD接口读码，或者往CAN总线上发个广播帧，理论上就能操控很多东西。
举个例子，CAN总线上有个经典的”刹车攻击”：
// 黑客只需发送一个CAN帧
CAN ID: 0x1AB
数据: [0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
// 这个帧会让刹车系统以为驾驶员踩了刹车
// 或者更糟糕的：
CAN ID: 0x080
数据: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]
// 直接清空刹车压力信号
这些代码看起来简单，但背后是一个完整的安全体系缺失。
ISO 21434是什么？一句话说清楚
ISO 21434是国际标准化组织（ISO）发布的”道路车辆——网络安全工程”标准，全称是ISO/SAE 21434:2021。
它不是技术手册，而是一套”怎么建立网络安全管理体系”的框架标准。
你可以把它理解成：汽车行业的”ISO 9001”——但不是告诉你怎么造好车，而是告诉你怎么确保这辆车从出生到报废，整个生命周期都不会被黑客操控。
标准的核心逻辑很简单：风险管理。
不是”把所有漏洞都堵死”（不可能），而是”识别风险，评估严重性，制定应对措施”。
ISO 21434全流程拆解
这个标准最核心的东西，是它把网络安全贯穿到了整车的整个生命周期：
整车生命周期网络安全流程
│
├── 1. 概念阶段（Concept Phase）
│ ├── 车辆网络架构定义
│ ├── 通信路径识别
│ ├── 初步威胁分析（TARA）
│ └── 网络安全目标制定
│
├── 2. 产品开发阶段（Product Development）
│ ├── 详细威胁与影响分析
│ ├── 网络安全需求分解
│ ├── 架构设计（防火墙、IDPS等）
│ ├── 组件级安全设计
│ └── 网络安全验证与确认
│
├── 3. 生产阶段（Production）
│ ├── 软件签名与校验
│ ├── 生产工具安全管控
│ ├── 供应链安全管理
│ └── 生产数据完整性保障
│
├── 4. 运行与维护阶段（Operation & Maintenance）
│ ├── 漏洞监测与响应
│ ├── OTA安全更新
│ ├── 网络安全事件响应（CSIRT）
│ └── 威胁情报共享
│
└── 5. 报废阶段（End of Life）
├── 数据清除
└── 安全终止机制
概念阶段：TARA分析是关键
TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）是ISO 21434最核心的活动。
简单说，就是”先搞清楚谁会打我，从哪打，打了会造成什么后果，然后再决定怎么防”。
TARA要做的事情：
Step 1: 定义车辆层级
- 整车级
- 系统级（如制动系统、转向系统）
- 组件级（如ESP控制器、信息娱乐系统）
Step 2: 识别攻击面
- 外部接口：蓝牙、WiFi、4G/5G、OBD接口、充电口
- 内部接口：CAN总线、Ethernet、LIN、FlexRay
- 物理接口：USB、SD卡槽
Step 3: 识别威胁场景
例如：
"攻击者通过蓝牙配对漏洞，进入信息娱乐系统，
进而通过内部网络访问制动系统，
导致车辆意外制动"
Step 4: 评估影响等级（影响值Impact）
- 人身安全（Safety）：高/中/低
- 财产安全（Property）：高/中/低
- 隐私（Privacy）：高/中/低
- 车辆可用性（Availability）：高/中/低
Step 5: 评估实现可能性（Achievability）
- 需要多高的技术能力？
- 需要多近的物理距离？
- 是否需要特殊设备？
- 是否需要用户交互？
Step 6: 确定风险等级
风险 = 影响值 × 实现可能性
高/中/低
Step 7: 制定缓解措施
- 消除风险（如关闭不必要接口）
- 降低风险（如加密通信、身份认证）
- 接受风险（风险极低，无需额外措施）
用Jeep Cherokee那个案例来说：
| 威胁场景 | 影响等级 | 实现可能性 | 风险等级 | 缓解措施 |
|---|---|---|---|---|
| 通过互联网入侵娱乐系统 | 高（人身） | 中 | 高 | 网络隔离、入侵检测 |
| 通过蓝牙重放攻击 | 中 | 高 | 中 | 加密配对、消息新鲜性检查 |
| 通过OBD接口直接操控 | 高 | 低 | 中 | 接口物理保护、诊断认证 |
产品开发阶段：架构设计是关键
TARA做完之后，就要进入产品设计阶段了。这一步的核心是安全架构设计。
一个典型的汽车网络安全架构包含这些层次：
1. 网络分区与隔离
把不同的功能域隔离开，是汽车网络安全最基本的思路。
┌─────────────────────────────────────────┐
│ 整车网络架构（Zone架构） │
├─────────────┬─────────────┬─────────────┤
│ 动力域 │ 车身域 │ 信息娱乐域 │
│ (Power) │ (Body) │ (Infotain.) │
├─────────────┼─────────────┼─────────────┤
│ 引擎ECU │ 车门ECU │ 屏幕MCU │
│ 变速箱ECU │ 座椅ECU │ 蓝牙模块 │
│ 电池管理 │ 空调ECU │ 4G模组 │
│ 电机控制 │ 灯光ECU │ 导航模块 │
└─────────────┴─────────────┴─────────────┘
│ │ │
└─────────────┼─────────────┘
┌──────────┐
│ 中央网关 │
│ (Gateway)│
│ 防火墙 │
│ IDPS │
└──────────┘
关键点：信息娱乐域（外网入口多、风险高）和动力域（直接控制车辆）之间必须通过网关隔离，不能直接互通。
2. 安全通信
CAN总线通信要加密和认证，防止中间人攻击和消息篡改。
# 简化的CAN消息安全认证示例
# 实际车企会使用SecOC（Secure Onboard Communication，ISO 15119相关）
import hashlib
import hmac
import struct
class SecureCANFrame:
"""简化的安全CAN帧实现"""
def __init__(self, can_id, data, secret_key):
self.can_id = can_id
self.data = data[:7] # 最多7字节有效数据
self.secret_key = secret_key
self.nonce = self._generate_nonce()
self.mac = self._compute_mac()
def _generate_nonce(self):
"""生成唯一随机数，防止重放攻击"""
import os
return os.urandom(4)
def _compute_mac(self):
"""计算消息认证码（ISO 13209 SecOC标准简化版）"""
# 拼接：CAN ID + 序列号 + 数据 + nonce
payload = struct.pack('>I', self.can_id) + self.data + self.nonce
return hmac.new(self.secret_key, payload, hashlib.sha256).digest()[:4]
def to_bytes(self):
"""序列化为CAN帧"""
return struct.pack('>I', self.can_id) + self.data + self.nonce + self.mac
@classmethod
def verify(cls, frame_bytes, secret_key):
"""接收端验证消息完整性"""
can_id = struct.unpack('>I', frame_bytes[:4])[0]
data = frame_bytes[4:11]
nonce = frame_bytes[11:15]
received_mac = frame_bytes[15:19]
# 重新计算MAC
expected_mac = hmac.new(
secret_key,
frame_bytes[:15],
hashlib.sha256
).digest()[:4]
# 时序安全的比较，防止侧信道攻击
if not hmac.compare_digest(expected_mac, received_mac):
raise ValueError("消息认证失败！可能遭受篡改或重放攻击")
return True
注意：实际车规级实现比这个复杂得多，涉及密钥管理、序列号计数、Freshness Counter等机制，但核心思路是一致的。
3. 入侵检测与防御系统（IDPS）
ISO 21434要求车辆具备IDPS能力，实时监测异常行为。
IDPS工作原理：
│
├── 流量基线学习
│ └── 记录正常情况下的CAN总线流量特征
│ （消息频率、ID分布、负载模式等）
│
├── 异常检测
│ ├── 统计异常：消息频率超出正常范围
│ ├── 语义异常：CAN ID出现了不该出现的消息
│ ├── 协议异常：消息格式不符合预期
│ └── 行为异常：某个ECU的通信模式突然改变
│
└── 响应机制
├── 告警：记录事件，通知后台
├── 隔离：阻断异常通信路径
└── 降级：切换到安全状态（如限速、点亮警告灯）
# 简化的CAN总线异常检测示例
class CANBusIDS:
"""CAN总线入侵检测系统（简化版）"""
def __init__(self):
# 正常CAN ID白名单
self.allowed_ids = {
0x100: {"freq_range": (10, 100), "min_len": 8, "max_len": 8}, # 引擎状态
0x200: {"freq_range": (5, 50), "min_len": 8, "max_len": 8}, # 刹车状态
0x300: {"freq_range": (1, 10), "min_len": 8, "max_len": 8}, # 转向状态
0x7E0: {"freq_range": (0, 5), "min_len": 8, "max_len": 8}, # OBD诊断（低频）
}
# 历史流量统计
self.msg_counts = {}
self.last_seen = {}
def analyze_frame(self, can_id, data, timestamp):
"""分析单个CAN帧"""
alerts = []
# 1. 检查是否在白名单内
if can_id not in self.allowed_ids:
alerts.append({
"type": "UNKNOWN_ID",
"severity": "HIGH",
"message": f"未知CAN ID: 0x{can_id:03X}"
})
return alerts
# 2. 检查数据长度
config = self.allowed_ids[can_id]
if len(data) < config["min_len"] or len(data) > config["max_len"]:
alerts.append({
"type": "INVALID_LENGTH",
"severity": "MEDIUM",
"message": f"CAN ID 0x{can_id:03X} 数据长度异常: {len(data)}"
})
# 3. 检查消息频率（滑动窗口）
if can_id not in self.msg_counts:
self.msg_counts[can_id] = []
self.msg_counts[can_id].append(timestamp)
# 保留最近1秒的消息
self.msg_counts[can_id] = [
t for t in self.msg_counts[can_id]
if timestamp - t < 1.0
]
current_freq = len(self.msg_counts[can_id])
min_freq, max_freq = config["freq_range"]
if current_freq > max_freq:
alerts.append({
"type": "FLOOD_ATTACK",
"severity": "HIGH",
"message": f"CAN ID 0x{can_id:03X} 消息频率异常: {current_freq}/s"
})
elif current_freq < min_freq and self.last_seen.get(can_id):
# 长时间没有消息，可能ECU被禁用
if timestamp - self.last_seen[can_id] > 10.0:
alerts.append({
"type": "SILENCED_ECU",
"severity": "CRITICAL",
"message": f"CAN ID 0x{can_id:03X} 长时间无消息，可能遭受DoS攻击"
})
self.last_seen[can_id] = timestamp
return alerts
生产阶段：供应链与数据安全
这一阶段经常被忽视，但恰恰是出问题最多的地方。
供应链安全：一辆车的零部件来自几十甚至几百家供应商。每个供应商的ECU都要符合网络安全要求。
供应链网络安全要求检查清单：
□ 供应商是否通过ISO 21434或等同标准认证？
□ ECU是否支持安全启动（Secure Boot）？
□ 通信是否加密和认证？
□ 是否有密钥管理机制？
□ 是否有漏洞响应流程？
□ 源代码是否经过安全审计？
□ 第三方组件是否有已知漏洞？
□ 固件是否可以安全更新？
生产数据安全：生产线上用于编程ECU的工具和设备，如果管理不善，本身就是攻击入口。
生产阶段安全管理要点：
1. 编程工具安全
- 编程密钥保管在硬件安全模块（HSM）中
- 编程过程使用安全加密通道
- 编程完成后密钥立即清除
2. 车辆识别码（VIN）绑定
- 每个ECU的软件与VIN绑定
- 防止拆换恶意ECU
3. 生产数据完整性
- 所有编程日志加密存储
- 定期审计编程记录
- 异常编程行为自动告警
运维阶段：漏洞响应与OTA
车子卖出去之后，网络安全工作才刚刚开始。
漏洞响应流程是ISO 21434明确要求建立的：
漏洞发现 → 评估 → 修复 → 部署 → 验证
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
外部报告 影响 补丁 OTA推送 遥测确认
或内部审计 分析 开发 下发 回滚检查
# 简化的漏洞响应流程示例
class VulnerabilityResponse:
"""漏洞响应管理系统"""
def __init__(self):
self.vulnerabilities = {}
self.patch_queue = []
def report_vulnerability(self, vuln_id, severity, description, affected_ecus):
"""接收漏洞报告"""
vuln = {
"id": vuln_id,
"severity": severity, # CRITICAL/HIGH/MEDIUM/LOW
"description": description,
"affected_ecus": affected_ecus,
"status": "REPORTED",
"created_at": self._get_timestamp(),
}
self.vulnerabilities[vuln_id] = vuln
self._assess_priority(vuln)
def _assess_priority(self, vuln):
"""评估修复优先级"""
severity_score = {
"CRITICAL": 4,
"HIGH": 3,
"MEDIUM": 2,
"LOW": 1
}
# 影响车辆数量越多，优先级越高
score = severity_score.get(vuln["severity"], 0) * len(vuln["affected_ecus"])
vuln["priority_score"] = score
self.patch_queue.append(vuln)
self.patch_queue.sort(key=lambda x: x["priority_score"], reverse=True)
def generate_patch(self, vuln_id, fix_description):
"""生成安全补丁"""
vuln = self.vulnerabilities.get(vuln_id)
if not vuln:
raise ValueError(f"漏洞 {vuln_id} 不存在")
patch = {
"vulnerability_id": vuln_id,
"fix": fix_description,
"target_ecus": vuln["affected_ecus"],
"signature": self._sign_patch(fix_description),
"status": "READY",
}
return patch
def _sign_patch(self, content):
"""对补丁进行数字签名（简化版）"""
import hashlib
return hashlib.sha256(content.encode()).hexdigest()
def deploy_patch(self, patch, vehicle_vin):
"""部署补丁到车辆（简化版）"""
# 实际流程要复杂得多：
# 1. 验证补丁签名
# 2. 检查车辆版本兼容性
# 3. 下载到车辆本地存储
# 4. 在合适时机（车辆熄火后）安装
# 5. 验证安装结果
# 6. 回滚机制（安装失败时恢复）
return {
"vin": vehicle_vin,
"patch_id": patch["vulnerability_id"],
"status": "DEPLOYED",
"install_time": self._get_timestamp()
}
def _get_timestamp(self):
import datetime
return datetime.datetime.now().isoformat()
认证要求：车企到底要过哪些关？
ISO 21434本身是一个标准，不是认证。但很多国家和客户会把”符合ISO 21434”作为准入条件。
主要认证/合规要求一览：
┌──────────────────┬──────────────────────┬──────────────────┐
│ 认证/法规 │ 适用范围 │ 关键要求 │
├──────────────────┼──────────────────────┼──────────────────┤
│ ISO 21434 │ 全球（事实标准） │ 全流程网络安全工程 │
│ UN R155 │ 欧盟、日本、韩国等 │ 网络安全管理体系 │
│ UN R156 │ 欧盟、日本、韩国等 │ 软件更新管理体系 │
│ US NHTSA │ 美国 │ 漏洞报告要求 │
│ China GB │ 中国 │ 数据安全和功能安全│
│ TISAX │ 欧洲汽车行业 │ 信息安全评估 │
└──────────────────┴──────────────────────┴──────────────────┘
UN R155 是最有约束力的法规之一，要求车企建立CSMS（Cyber Security Management System，网络安全管理体系），否则车辆不能在欧洲等市场销售。
CSMS的核心要求：
CSMS架构要求：
┌─────────────────────────────────────┐
│ CSMS体系架构 │
├─────────────────────────────────────┤
│ 管理层（Management） │
│ ├── 网络安全政策与方针 │
│ ├── 组织架构与职责分工 │
│ ├── 资源保障 │
│ └── 管理评审与持续改进 │
├─────────────────────────────────────┤
│ 支持层（Support） │
│ ├── 人员培训与意识 │
│ ├── 供应商安全管理 │
│ ├── 文档与记录管理 │
│ └── 工具与基础设施安全 │
├─────────────────────────────────────┤
│ 运营层（Operation） │
│ ├── 威胁分析与风险评估（TARA） │
│ ├── 安全需求定义与设计 │
│ ├── 安全验证与确认 │
│ ├── 事件响应与漏洞管理 │
│ └── 配置管理与变更控制 │
└─────────────────────────────────────┘
常见漏洞类型与典型案例
1. 通信协议漏洞
CAN总线本身没有认证机制，这是老式汽车的”原罪”。
典型攻击：CAN总线消息注入
攻击者通过OBD接口或无线接入点，
向CAN总线发送伪造的刹车控制消息。
防御：
- 使用SecOC（ISO 15119）进行消息认证
- 在网关层实施ID过滤
- 部署IDPS实时监测异常消息
2. 密钥管理漏洞
很多早期车型，密钥硬编码在ECU里，或者使用弱密钥。
# 反面教材：硬编码密钥（绝对禁止！）
BAD_KEY = "1234567890abcdef" # 硬编码密钥
# 攻击者只需反编译固件就能拿到密钥
# 正确做法：使用HSM（硬件安全模块）
"""
- 密钥生成在HSM内部，永不导出
- 密钥分片存储，需要多因素才能恢复
- 密钥定期轮换
- 使用安全启动链确保固件完整性
"""
3. OTA更新漏洞
OTA是双刃剑，既能修复漏洞，也能成为攻击入口。
OTA安全更新流程：
车辆端 服务端
│ │
│ 1. 请求更新 ←────────────────────┤
│ (携带车辆ID、当前版本) │
│ │
│ 2. 下载补丁包 ───────────────────►│
│ (加密+签名) │
│ │
│ 3. 验证签名 ◄────────────────────┤
│ (确认来自官方) │
│ │
│ 4. 安装补丁 ◄────────────────────┤
│ (在安全环境下执行) │
│ │
│ 5. 回滚检查 ◄────────────────────┤
│ (验证安装成功) │
│ │
│ 6. 确认完成 ─────────────────────►│
│ (上传遥测数据) │
4. 第三方组件漏洞
一辆车可能用到上千个第三方开源组件（Linux、Qt、Boost等），任何一个有漏洞都可能成为入口。
第三方组件管理要点：
1. SBOM（软件物料清单）
- 记录所有使用的组件及版本
- 定期扫描已知漏洞（CVE）
- 建立自动化更新机制
2. 供应链审计
- 评估第三方组件的安全质量
- 要求供应商提供安全声明
- 对高风险组件进行源码审计
3. 监控与响应
- 订阅CVE通知
- 建立内部漏洞响应流程
- 与行业共享威胁情报
车企如何应对：实操建议
1. 建立网络安全文化
这是最难也最重要的一步。网络安全不是IT部门的事，而是从董事长到产线工人 everyone 的事。
网络安全文化建设路径：
第1步：高层承诺
- CEO签署网络安全政策
- 设立首席信息安全官（CISO）
- 网络安全纳入公司战略
第2步：组织架构
- 建立跨部门网络安全团队
- 明确职责分工（开发、测试、运维、售后）
- 与供应商建立安全协作机制
第3步：培训与意识
- 全员网络安全培训（每年至少一次）
- 开发人员专项安全编码培训
- 建立安全奖励机制（如漏洞报告奖励）
第4步：持续改进
- 定期安全审计
- 参与红蓝对抗演练
- 跟踪行业最佳实践
2. 建立技术防护体系
汽车网络安全防护层次：
┌─────────────────────────────────────────┐
│ 第1层：物理安全 │
│ - OBD接口保护（加密锁/禁用） │
│ - 车载天线信号屏蔽（非工作时） │
│ - 关键ECU物理防拆 │
├─────────────────────────────────────────┤
│ 第2层：网络安全 │
│ - 网关防火墙（跨域访问控制） │
│ - IDPS入侵检测与防御 │
│ - VPN加密通信（远程诊断） │
├─────────────────────────────────────────┤
│ 第3层：主机安全 │
│ - 安全启动（Secure Boot） │
│ - 安全存储（HSM/TEE） │
│ - 进程隔离与权限最小化 │
├─────────────────────────────────────────┤
│ 第4层：应用安全 │
│ - 输入验证与 sanitized │
│ - 安全编码规范（MISRA C等） │
│ - 第三方组件漏洞管理 │
├─────────────────────────────────────────┤
│ 第5层：数据与密钥安全 │
│ - 敏感数据加密存储 │
│ - 密钥安全生命周期管理 │
│ - 隐私数据最小化收集 │
└─────────────────────────────────────────┘
3. 应对认证的 checklist
ISO 21434 / UN R155 认证准备清单：
□ 网络安全政策文件
□ 组织架构图（含网络安全职责）
□ 风险管理流程文档
□ TARA分析报告（每款车型）
□ 安全需求规格书
□ 安全架构设计文档
□ 安全测试报告（渗透测试、模糊测试等）
□ 漏洞响应流程文档
□ 事件响应计划（IRP）
□ 供应商安全评估记录
□ 员工安全培训记录
□ 软件更新管理流程（UN R156）
□ 配置管理记录
□ 变更管理流程
□ 持续监控与改进记录
给小朋友也能听懂的解释
想象一下，你的自行车本来很安全，有刹车、有车铃。但后来有人给自行车加了个手机APP，可以远程开锁、查看位置。
这个APP虽然方便，但如果有人偷看了你的密码，或者假装成APP向你发送错误指令，你就可能找不到自行车，或者车被偷偷骑走。
汽车也是一样的道理。以前汽车很”封闭”，黑客进不去。现在汽车连接了网络，就像给自行车装了APP——好处很多（远程诊断、OTA升级、智能导航），但风险也来了。
ISO 21434就像是一本”如何保护智能汽车”的说明书，告诉车企：
- 先想想谁会想办法偷你的车（威胁分析）
- 看看哪些地方最容易被盗（识别攻击面）
- 给每个可能被盗的地方装上锁（安全措施）
- 定期检查锁有没有坏（持续监控）
- 如果有人真的撬锁了，要能快速反应（事件响应）
总结：这不是选择题，是必答题
汽车网络安全不是一时热点，而是整个行业必须面对的基础能力。
从Jeep Cherokee那次入侵开始，到后来特斯拉、宝马接连被”白帽子”证明漏洞，再到各国法规的密集出台——汽车行业正在经历一场深刻的安全变革。
ISO 21434提供了一套完整的方法论，但更重要的是：车企需要从”安全是额外负担”转变为”安全是产品的一部分”。
这条路不好走，需要投入资源、改变流程、培养人才。但想想那些坐在车里的人——他们把生命托付给了这辆车。网络安全，不是可选项，是责任。
延伸思考：
随着自动驾驶的发展，车辆的控制权将进一步交给系统。这意味着网络安全的重要性只会更高——当一辆车可以完全无人驾驶时，黑客的入侵就不再是”偷车”，而是”劫持一辆移动的铁棺材”。
这个话题，值得我们每个人关注。