符合功能安全与网络安全要求的E2E通讯范文

本站小编为你精心准备了符合功能安全与网络安全要求的E2E通讯参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

[摘要]  随着R155、R156、ISO 21434等汽车领域的网络安全要求的法规和标准的，要求产品既符合功能安全标准，又符合网络安全标准。本文从安全设计流程出发，以通讯通道的安全保护为例，介绍符合标准要求的研发过程及安全设计措施。

 [关键词]  智能网联汽车  网络安全  功能安全  ISO 26262   ISO 21434  

一、安全体系的融合 

在产品研发前，首先要建立符合《ISO 26262  道路车辆功能安全》和《ISO/SAE 21434 道路车辆网络安全》的文化和管理流程体系。  在安全文化方面，网络安全与功能安全的要求相似，企业应建立、培养和保持有力的安全文化，确保“支持和保证安全活动”保质保量实施。良好的文化，不仅体现在企业口号和员工安全意识上，更体现在公司级的安全手册和研发流程上。  这两类安全管理体系都包含公司级或全局级、项目级的安全管理。实施时，需在质量管理的基础上，将这两类安全管理体系进行有效地融合。建立起涵盖概念阶段、研发阶段、生产运行及报废等阶段，全生命周期的管理手册、流程、指南、模板、检查列表等一系列可指导实施，可持续改进的工作输出物，为具体项目实施打下坚实基础。

二、概念阶段 

在概念阶段，首先要进行相关项的定义，定义出相关项的功能及非功能的需求、边界、约束条件以及运行环境等信息。根据定义的相关项，先进行功能安全的危害分析和风险评估（Hazard Analysisand Risk Assessment）[1]，通过各种定义的功能与多种失效或故障关键字的组合产生的整车级危害表现，与各种场景进行组合，从而导出各种场景下各个功能失效的S(伤害度)、E(暴露度）、C(可控程度)，再进行整理合并，导出功能安全目标，并在初始架构的支持下，通过安全分析，将功能安全目标形成功能安全需求，分配给架构上的各个元素。由于网络安全在概念阶段非常复杂，在相关项定义的基础上，需要进行整车网络安全威胁分析与评估（TARA）[2]。在系统初始架构图的基础上，对数据流进行分析，识别出安全资产。在《SAE J 3 0 6 1 网联汽车网络架构安全指南》中，提供了多种TARA分析方法，如电子安全车辆入侵防护应用（EVITA）[3]、待分析系统的威胁、漏洞和风险（TVRA）、修复漏洞以增强软件安全性（HEAVENS）等。以EVITA模型为例，除了要考虑功能安全方面的影响外，还需要考虑对隐私、财产、驾驶员操作等方面的影响，并结合威胁场景考虑攻击或潜在攻击的可能性，最终形成对风险的评估和应对措施的初步设计。一般情况下，若项目同时需要符合功能安全和网络安全的要求，先进行功能安全的HARA分析，再进行TARA分析，然后在一起进行统一的综合分析和评审，最后形成分配给各要素的功能安全需求和网络安全需求。

三、设计阶段 

在设计阶段，功能安全分为系统阶段、硬件阶段和软件阶段，逐步将安全需求进行细化和分配。I S O  21434的网络安全标准对设计阶段统一考虑。  完成了融合的安全流程体系和概念阶段工作后，在设计方面，本文以端到端(e2e)的通讯保护的安全需求为例，分析如何设计才能满足两种安全的需求。首先，在功能安全方面，要对端到端的通讯/数据传输可能的失效模式进行分析(参考I S O  26262标准的第5部分附录D)，可能的失效模式有如下类型：通信节点丢失、消息损坏、消息不可接受的延时、消息丢失、非预期的消息重复、消息顺序错误、消息插入、消息伪装、消息寻址错误。针对这些失效模式，可采取的有效安全措施主要包括奇偶位的检验、通讯通道硬件的冗余、使用测试模式检验、发送冗余、信息冗余、帧计数器、超时监控、发送信息回读以及多种措施的组合。在这些安全措施中，完全硬件冗余，使用测试模式检验和信息冗余、帧计数器和超时监控组合达到了高诊断覆盖率，可以达到99%单点故障的诊断覆盖率，达到了汽车安全完整性等级（ASILD）的要求。对于常用的循环冗余校验（CRC）措施，覆盖率依赖于被覆盖数据的长度、CRC  的大小（位数）和多项式，常用的有16位CRC校验、32位CRC校验等方式。  在功能安全设计中，为了实现高诊断覆盖率，更多时候采用多种措施组合，如将信息冗余、帧计数器和超时监控等组合使用，同时用多种方式对传输的信息进行校验，使得在信息出现丢失或偏差的时候，能够及时通过诊断获知异常，并在故障容错时间间隔（Fault Tolerant  Time  Interval）[4]内完成安全状态的转换。  在网络安全方面 ， 可以根据E C E  R155的法规内容对端到端的通讯/数据传输面临的网络安全威胁进行分析，常见的可能威胁有发送欺骗信息，通讯通道允许代码注入到车辆数据和代码，车辆通讯通道允许操纵、重写、删除数据和代码，车辆通讯通道允许向车辆系统导入数据和代码，接受来源不可靠或不可信的信息，中间人攻击/会话支持，重放攻击，拦截信息、干扰、窃听通讯，越权存取文件或数据，发送大量的垃圾数据给车辆信息系统，导致不能提供正常的服务，黑洞攻击，未经许可获取特权(如R o o t权限)，携带病毒信息媒介感染系统，内部恶意信息(如控制器局域网络CAN)，恶意的诊断信息等。  针对以上威胁分析，可考虑采用缓解措施如下：车辆需确认接收信息的真实性和完整性，对存储密钥实施安全控制，系统需通过风险最小化设计实现安全，访问控制技术和设计应该应用到数据和代码的预防措施，机密数据传递需要被加密保护，应部署相关措施发现并恢复阻断攻击，需有手段发现并阻断越权进入，要考虑防止嵌入式病毒、恶意软件的系统保护措施等。从上述E2E保护的例子可以看到，功能安全主要面临的是内部的故障问题，所有分析都建立在如何应对内部故障造成的危害影响上。网络安全面对可能来自外部的攻击，对方往往是人为或恶意的程序代码，面临的风险更加复杂、多样和动态化。  在面对E2E的功能安全需求制定保护或诊断措施时，往往可以将C R C校验，超时校验甚至信息回读等方式进行有效组合，从而得到高诊断覆盖率。但是，上述措施对于防范网络安全威胁远远不够，需在实现功能安全需求的基础上，对传输的信息进行加密处理，对发送信息的源头加入证书颁发机构（CA）认证机制，对资源进行分类，并进行权限控制，对传输信息流进行威胁监控等。在同时面对功能安全和网络安全需求时，首先，需进行针对功能安全需求的分析与措施设计，并以此为基础再对网络安全的需求进行分析和应对，制定出全面可行的综合性措施与方案。此外，还需满足独立性要求的功能安全工程师与网络安全工程师一起评审综合方案，以确保综合性设计方案能够满足功能安全和网络安全的需求。

四、测试与验证 

在V流程的模型里，每一级设计应进行相应层级的测试或验证。在源代码级，需要进行静态测试与单元测试；在软硬件集成、系统集成以及在整车集成的级别，为满足功能安全与网络安全的需求，需要进行针对所设计安全措施的故障注入测试、渗透性测试与网络攻击测试，形成各级测试报告，以证明所采用的安全措施达到或符合其所分配的安全需求。

五、小结 

关于满足功能安全与网络安全的项目实施，需要建立起融合两方要求的流程体系与安全文化，建立功能安全与网络安全团队间的高效沟通渠道，在设计时需综合分析两方面需求，设计出合理的架构和设计方案完整的测试策略，并在质量管理体系的基础上有效实施。

作者：李徐鹏 禹营 单位：中认车联网技术服务 中国质量认证中心