汽车人眼中的网络安全网络安全的5W1H.docx

汽车人眼中的网络安全网络安全的5W1H.docx

《汽车人眼中的网络安全网络安全的5W1H.docx》由会员分享，可在线阅读，更多相关《汽车人眼中的网络安全网络安全的5W1H.docx（13页珍藏版）》请在冰点文库上搜索。

汽车人眼中的网络安全网络安全的5W1H

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

网络安全（CyberSecurity）是近几年汽车电子圈与以太网、自动驾驶、车联网等并驾齐驱的热门话题，为何（Why）？

目前的标准和现状是什么（What）？

网络安全防的是谁（Who）？

是从哪里发起攻击（Where）？

面对这些攻击，何时（When）要做网络安全工作？

如何做（How）？

作为当代“汽车人”，让我们从这5W1H来聊聊汽车网络安全这个话题。

Why：

背景

从行业应用的角度

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

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

从技术通路的角度

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

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

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

上述的“叠加效应”以及过去几年发生的安全事件和攻防演练案例（以15年大切诺基的网络安全“网红事件”开始），让大家对网络安全更为敏感和重视。

但网络安全该如何行之有效地落地，这也是当前行业同仁们的焦虑点之一。

What：

概念及现状

名词解释

“CyberSecurity”，其中之一的英文说明：

“Aattributeofacyber-physicalsystemthatrelatestoavoidingunreasonableriskduetoanattack”，很挣扎地把它翻译为：

网络物理系统中“避免由于攻击而引起不合理风险”的一种属性。

后续章节通过对比的方式将给大家展示更形象的释义。

网络安全常涉及的四个名词：

Vulnerabilityvs.Threatvs.Attackvs.Risk，借用下图予以解释。

图2 网络安全名词解释

网络安全vs信息安全

前者更宏观，包括通信链路安全以及“链路”所运载的数据安全；后者更具体，强调的是数据的安全，例如对通过蓝牙共享在车机中电话薄信息的保护。

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

网络安全vs功能安全（SecurityvsSafety）

先说区别：

Security的目标是如何免受攻击（Attack），保护财产、隐私信息、生命安全，所需应对的威胁和攻击具有不可预测及动态的特性。

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

图3 网络安全与功能安全区别示意图

以通信作为对比示例：

SafetyCommunication：

防止非恶意故障（如ECU自身软件的运行错误）对通信链路的影响，如消息损坏、消息丢失。

采用的机制包括CRC/E2E等，保证信息的完整性。

SecurityCommunication：

防止恶意攻击（如ECU软件被非法替换）对通信链路的影响，如消息的插入、删除、修改、延迟等。

采用机制包括SecOC等，保证信息的真实性及完整性。

再说联系：

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

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

举例来说，ADAS控制器是毋容置疑的“关键的”功能安全系统。

同样的安全漏洞在此类载体中所产生的危害更大，所以对它不仅要求满足对应功能安全等级的技术条件，同时也必须应用网络安全相关技术，这也是为何很多网络安全技术在此类功能安全关键系统中应用更广的推动力。

反之，T-Box是公认的网络安全的关键系统，但却不是功能安全的关键系统。

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

功能安全和网络安全的设计开发流程相互影响，部分要素互为输入。

在ISO262622018版中专门阐述了两者之间在概念、开发、生产各阶段的潜在的交互关系。

图4 Security与Safety之间的关系

标准及现状

为了更好地理解及应用，可简单地将近些年汽车网络安全相关主要标准及组织按照如下二维坐标进行定位。

图5 部分标准和组织的网络安全的关注点定位

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

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

∙ISO21434将于2020年正式发布，可能会取代SAEJ3061

∙在传统IT及工业领域的ISO15408、ISO27001、IEC62443可充分借鉴参考

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

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

小结

网络安全和功能安全都是相对的，不存在绝对的“安全”。

许多已有网络安全技术本身既炫酷也有效，但为何却并未如预期普及呢（如车内报文加密、基于机器学习的IDS、IPS等）？

汽车行业的开发是分厘计较的，多一点代码/多一点存储空间占用/多一点CPU开销都需精打细算其对成本和性能带来的影响，所以平衡最重要也最难。

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

Bosch）

Who：

防的是谁

网络安全需要认清一个现实：

“道高一尺，魔高一丈”，如果有足够资源（时间、金钱、设备等），一切安全措施都可能被突破。

而尝试攻击的人，可大致分两类：

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

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

显然，要防范的重点是后者。

从社会经济学的角度，既然逐利，后者同样会分析投入与收益的关系。

所以对于网络安全的设计者而言，需建立相应的安全措施去重点保护可让攻击者获益的漏洞，从而让攻击者觉得投入回报不具吸引力。

弄清和了解“谁是我们的敌人”，做到知己知彼，方可有的放矢！

他自狠来他自恶，我自一口真气足。

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

Where：

从哪里发起攻击

根据车内和车外进行划分，可以把潜在攻击点汇总如下图，针对ADAS传感器端的攻击不属于本文的讨论范畴。

图7 攻击端口的示意图

When：

何时

关于When可分为两个层面：

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

建议：

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

∙车内ECU何时设防

通宵达旦处于防备状态为理想，但对车辆而言功耗和馈电的紧箍咒，决不允许ECU如此“任性”。

所以可行的方式是网络安全相关的功能/任务，要“早起晚睡”：

从ECU唤醒和启动的时刻开始布防，如下文将提到的SecureBoot，同时站好最后一班岗。

How：

如何实现网络安全

简单有效的开发方法

若是解决短期的网络安全设计困惑，可借鉴如下图8所示的相对简单有效的方式实现网络安全。

体系化的流程

若长远考虑建立网络安全开发机制，可以参照和解读SAEJ3061，定义与功能安全十分相似的开发过程：

∙ConceptPhase

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

∙ProductDevelopment

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

∙Production,OperationandService

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

∙SupportingProcesses

可与ISO26262所定义的支持过程共用的，比如配置管理，文档管理，变更管理等，同时需根据网络安全开发的特点进行一定的定制，如网络安全需求管理、分布式开发的处理。

图9 网络安全的Concept阶段和产品开发阶段的工作流（来自SAEJ3061）

总的来说，SAEJ3061定义了涵盖产品完整的生命周期网络安全开发流程，后续在ISO21434中进行继承和补充，但是与ISO26262相同的：

定义的都是What，不是How！

网络安全实现的技术方案

基于车辆电子电器系统和局部的特点，网络安全的技术框架普遍采用层层设防的分层理念。

同时，按照保护、监测、响应不同的目标阶段，对所涉及的技术可简要汇总如下图。

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

对各层新技术趋势，举例来说：

∙L1

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

∙L2

以太网本身自带一些安全机制（VLAN/ACL等），同时TSN定义了802.1Qci，实现入口过滤和监控，以满足作为主干网通信的网络安全需求。

另外，诊断通信也将定义新的诊断指令以更好地支持网络安全。

∙L3

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

∙L4

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

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

从技术应用的落地角度，对车内可区别对待，先从功能安全（ADAS/VCU等）和网络安全关键系统（GW/TBOX/HMI等）着手，先从可行的技术着手；而车外可借助IT行业成熟经验和技术，保证TSP及TSP与TBox之间通信，手机端APP及手机端与TSP之间通信的网络安全。

网络安全测试

测试依然负责坚守最后的防线，但与以前有些不同。

对于网络安全而言，测试的地位明显提高，因为网络安全测试的过程也是模拟攻击，发现漏洞的过程。

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

∙功能性测试

基于网络安全设计需求的正向和逆向测试和性能测试，可黑盒实现。

∙接口测试

通过功能测试，验证从输入和输出是否满足设计需求，可归类至功能性测试，可黑盒实现。

∙模糊测试

通过产生随机数，或“规律的”随机数，验证系统的行为，可黑盒或灰盒实现。

∙漏洞扫描

在白盒或灰盒的状态下进行扫描测试，例如基于CERT的Guideline进行代码扫描，或基于已知的安全漏洞Checklist进行审查，漏洞扫描的结果可作为渗透测试的输入。

∙渗透测试

利用系统漏洞，发起“攻击”，尝试获得系统控制、访问等各种权限。

基于测试结果识别网络安全需求，强化系统的安全设计。

可在黑盒、灰盒或白盒状态下开展，对测试人员的要求极高。

ISO21434中定义了1级-4级的CAL（CybersecurityAssuranceLevel）。

与ASIL相似，不同CAL等级的部件需采用不同Level的测试方法和手段。

总结

技术落地要从实际出发，要结合汽车行业自身的特点。

以大家耳熟能详的SecOC中的MAC（MessageAuthenticationCode）应用为例：

从系统设计角度

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

∙是否需要采用CANFD以容纳新增的数据场？

如果是，就需要进行CANFD通信需求设计；如果否，需要对原有的网络设计进行重定义和优化

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

以部件实现而言

∙MAC对于接收端和发送端都将产生额外的资源消耗，需通过专用的硬件HSM模块来处理，才能降低CPU/MCU开销，并减少收发延迟

∙HSM硬件模块采用何种方案，对开发和成本影响有多大，都需要予以考虑

由此可见，哪怕只是增加一个MAC的特性，就已涉及了内部和外部的上下游，涵盖从顶层设计至具体实现的方方面面，每走一步的包袱和惯性自然会大一些，更何况是网络安全这样的大话题。

所以，更需要策略性的应对，坚持“合适的才是最好”的原则。

关于网络安全，总的来说，对传统的“汽车人”而言，当前更为缺失的是对网络安全系统性的、全面的认识，以及有条不紊的、有的放矢的行动。

他强由他强，清风拂山岗；他横由他横，明月照大江。

此次成文抛砖，对网络安全的知识框架和技术脉络的梳理，既是对自我认知学习的小结，也希望借此分享可以给大家带来一些启发和思想碰撞。

疏漏及谬误之处，请予指正！

关于当前行业内网络安全技术的具体应用情况和进展，欢迎当面沟通交流！