“汽车人”眼中的网络安全-聊聊网络安全的5W1H

网络安全（Cyber Security）是近几年汽车电子圈与以太网、自动驾驶、车联网等并驾齐驱的热门话题，为何（Why）？目前的标准和现状是什么（What）？网络安全防的是谁（Who）？是从哪里发起攻击（Where）？面对这些攻击，何时（When）要做网络安全工作？如何做（How）？

• 自动驾驶的下沉和技术升级➔网络安全的缺陷如潜伏的灰犀牛，影响和危害更大

• 车联网广泛的需求➔更多攻击源，更大的个人信息外泄风险（如在车端交易付款的账户信息）

• 以太网通信技术的普及➔已存的基于以太网的攻击技术将无缝迁移

• 下一代基于高性能计算平台的电子电器架构➔使Linux、QNX等操作系统在域（Domain）控制器/区（Zone）控制器中得以广泛应用，同步引入了成熟的攻击“套路”（如下图1）

图1 针对QNX操作系统的攻击过程

上述的 “叠加效应”以及过去几年发生的安全事件和攻防演练案例（以15年大切诺基的网络安全“网红事件”开始），让大家对网络安全更为敏感和重视。但网络安全该如何行之有效地落地，这也是当前行业同仁们的焦虑点之一。

网络安全常涉及的四个名词：Vulnerability vs. Threat vs. Attack vs. Risk，借用下图予以解释。

图2 网络安全名词解释

以铁路运输为例，网络安全包括铁路干线运行安全和运行之上的列车及货物安全，信息安全侧重于列车中货物安全（防火防盗），是网络安全的子集。

先说区别：

Safety的目标是在受到外部攻击或内部故障的情况下，保护车内人员、路人的生命安全，其危害（Hazard）分析具有相对的可预测及静态的特点。

以通信作为对比示例：

Security Communication：防止恶意攻击（如ECU软件被非法替换）对通信链路的影响，如消息的插入、删除、修改、延迟等。采用机制包括SecOC等，保证信息的真实性及完整性。

再说联系：

SAE J3061从两个维度阐述了两者之间的关系：

• 从实体或载体的角度，功能安全关键系统是网络安全关键系统的子集

举例来说，ADAS控制器是毋容置疑的“关键的”功能安全系统。同样的安全漏洞在此类载体中所产生的危害更大，所以对它不仅要求满足对应功能安全等级的技术条件，同时也必须应用网络安全相关技术，这也是为何很多网络安全技术在此类功能安全关键系统中应用更广的推动力。反之，T-Box是公认的网络安全的关键系统，但却不是功能安全的关键系统。

• 从工程开发的角度，两者既有区别，又有联系

图4 Security与Safety之间的关系

关于上述标准文档的解读不在此展开，只说明几点：

• AUTOSAR所定义的网络安全技术，对车内ECU是快速落地的最佳选择

• ISO 21434将于2020年正式发布，可能会取代SAE J3061

• 在传统IT及工业领域的ISO 15408、ISO 27001、IEC 62443可充分借鉴参考

• 某些情况下“车内”和“车外”的界线并不明显，具体问题具体分析

• 国家非常重视交通运输领域网络安全标准的制定和推广，相关的标准、行业白皮书需大家关注

图6 应用IDS和IPS后转发性能的对比（图片来源：Bosch）

网络安全需要认清一个现实：“道高一尺，魔高一丈”，如果有足够资源（时间、金钱、设备等），一切安全措施都可能被突破。而尝试攻击的人，可大致分两类：

• 技术段位极高的，想扬名立万的黑客级玩家，主观上无损害他人人身和财产安全的意愿

• 具备攻击手段的，利益熏心的不法之徒

显然，要防范的重点是后者。从社会经济学的角度，既然逐利，后者同样会分析投入与收益的关系。所以对于网络安全的设计者而言，需建立相应的安全措施去重点保护可让攻击者获益的漏洞，从而让攻击者觉得投入回报不具吸引力。

弄清和了解“谁是我们的敌人”，做到知己知彼，方可有的放矢！他自狠来他自恶，我自一口真气足。

补充一点，尝试攻击的除上述以外，当然还存在有组织、有纪律的团体，其目标非单一维度的“获名”或“获利”来描述，不在本文讨论的范畴。

图7 攻击端口的示意图

• 现在是否要做网络安全技术的实践

建议：技术储备只争朝夕，方案落地结合实际。

• 车内ECU何时设防

图8 简单有效的网络安全开发方法

• Concept Phase

推荐通过TARA（Threat Analysis and Risk Assessment）的方法（此处画重点，和功能安全中的HARA分析方法异曲同工），评估和定义网络安全特性及需求。

• Product Development

 定义产品在系统层面、硬件层面、软件层面网络安全开发流程。

• Production, Operation and Service

定义车辆生产、使用和售后维护过程的网络安全需求，比如售后诊断刷写工具等。

• Supporting Processes

图10 网络安全所涉及的技术

• L1

针对多核多操作系统域控制器，为了保证网络安全就需要控制器从逻辑或物理上实现隔离分区，这样可保证一旦某个操作系统下的漏洞被攻破，不会影响其它操作系统的通信和功能。

• L2

以太网本身自带一些安全机制（VLAN/ACL等），同时TSN定义了802.1Qci，实现入口过滤和监控，以满足作为主干网通信的网络安全需求。另外，诊断通信也将定义新的诊断指令以更好地支持网络安全。

• L3

采用以功能域为导向或以网络安全关键性为导向的架构设计方案。

• L4

包括数据加密和身份认证等技术，以实现防探测和防篡改，网络安全技术的芯片化是趋势；同时，3GPP主导的C-V2X中网络安全相关标准在起草中，值得关注。

图11 以功能域和安全关键性为导向的架构设计示意图

包括ISO 21434和SAE J3061等在内的标准和文档，介绍了如下几种常用的测试方法：

• 功能性测试

• 接口测试

• 模糊测试

• 漏洞扫描

• 渗透测试

ISO 21434中定义了1级-4级的CAL（Cybersecurity Assurance Level）。与ASIL相似，不同CAL等级的部件需采用不同Level的测试方法和手段。

技术落地要从实际出发，要结合汽车行业自身的特点。以大家耳熟能详的SecOC中的MAC（Message Authentication Code）应用为例：

• CAN报文中增加了MAC数据，对数据场分配带来了影响，进而可能对网络负载产生影响

• 是否需要采用CAN FD以容纳新增的数据场？如果是，就需要进行CAN FD通信需求设计；如果否，需要对原有的网络设计进行重定义和优化

• 如使用CAN FD通信了，需考虑是否基于CAN FD实现诊断刷写，是否增加网关的路由类型等问题，这些将会影响系统架构的设计

• MAC对于接收端和发送端都将产生额外的资源消耗，需通过专用的硬件HSM模块来处理，才能降低CPU/MCU开销，并减少收发延迟
  
• HSM硬件模块采用何种方案，对开发和成本影响有多大，都需要予以考虑
  

由此可见，哪怕只是增加一个MAC的特性，就已涉及了内部和外部的上下游，涵盖从顶层设计至具体实现的方方面面，每走一步的包袱和惯性自然会大一些，更何况是网络安全这样的大话题。所以，更需要策略性的应对，坚持“合适的才是最好”的原则。

关于网络安全，总的来说，对传统的“汽车人”而言，当前更为缺失的是对网络安全系统性的、全面的认识，以及有条不紊的、有的放矢的行动。他强由他强，清风拂山岗；他横由他横，明月照大江。

此次成文抛砖，对网络安全的知识框架和技术脉络的梳理，既是对自我认知学习的小结，也希望借此分享可以给大家带来一些启发和思想碰撞。疏漏及谬误之处，请予指正！关于当前行业内网络安全技术的具体应用情况和进展，欢迎当面沟通交流！

最后做个预告，我们后续将针对网络安全具体的技术实现方案和测试实践经验推出相关主题的文章，敬请大家持续关注！

如需了解如上内容更多信息，

可以随时联系北汇信息！

电话：021-34716271

邮箱：info@polelink.com

看都看完了，不如点这里试试