点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
在现代汽车行业中，电气/电子（E/E）系统的功能安全愈发重要，为此提出了全球功能安全标准 ISO 26262。该标准为每个E/E系统提供功能安全要求，以规避不合理风险。汽车开放系统架构（AUTOSAR）虽积极引入安全机制来满足这些要求，但仍不尽人意。特别是，当前 AUTOSAR 的安全机制无法完全处理 ISO 26262 规定必须检测出的软件故障。本文提出两种针对 AUTOSAR 的强化安全机制，使其能够检测出 ISO 26262 中列出的所有类型软件故障。首先提出强化的期限监督机制，用于检测任务的无限期阻塞；还引入端到端保护机制，可检测数据传输延迟。我们在 TriCore™启动套件上实现了该方案，并证明其能成功检测出预期故障。
01
引言
在现代汽车行业，电气/电子（E/E）系统中功能安全的重要性日益凸显。为全面解决汽车功能安全问题，一项名为 ISO 26262 的全球功能安全标准应运而生。ISO 26262 是将适用于一般电气/可编程电子安全相关系统的功能安全标准 IEC 61508 应用于汽车领域的产物。它为开发E/E系统时实现安全目标提供了结构化方法。
ISO 26262 提供了危害分析和风险评估方案，有助于识别和分类 E/E 系统故障行为引发的危害。通过应用该方案，每个 E/E 系统可基于严重程度、暴露概率和可控性这三个因素被赋予一个汽车安全完整性等级（ASIL）。ASIL 分为四个等级：ASIL A、ASIL B、ASIL C 和 ASIL D。其中，ASIL A 风险最低，ASIL D 风险最高。根据所分配的 ASIL，每个 E/E 系统在硬件和软件开发方面都有各自的安全要求，在设计、实现、验证和确认系统时必须满足这些要求。
软件故障检测是 ISO 26262 对软件开发提出的关键安全要求之一。因此，每个 E/E 系统都必须具备安全机制，以检测运行过程中可能出现的软件故障。ISO 26262 定义了必须通过这些安全机制检测出的软件故障，共分为三类：（1）定时和执行故障；（2）内存故障；（3）信息交换故障。在 ISO 26262 中，达到 ASIL C 和 ASIL D 等级的 E/E 系统必须具备检测所有这三类故障的安全机制。
AUTOSAR（汽车开放系统架构）是 2002 年由欧洲汽车行业推出的汽车软件平台标准。它为汽车软件开发人员提供软件平台架构、设计方法、模板和应用程序编程接口（API）。鉴于众多汽车行业参与者都参与到开发过程中，对 AUTOSAR 来说，提供平台级安全机制至关重要。自 4.0.3 版本发布以来，AUTOSAR 一直在积极引入安全机制，但仍无法完全满足 ISO 26262 的所有要求。
特别是，当前 AUTOSAR 的安全机制无法检测出 ISO 26262 中列出的所有类型故障。其一，它无法在运行时检测任务的无限期阻塞，这使得基于 AUTOSAR 的系统难以发现部分定时和执行故障；其二，它无法检测两个电子控制单元（ECU）之间的数据传输延迟，这可能会掩盖部分信息交换故障。
本文为 AUTOSAR 引入两种先进的安全机制，以检测 ISO 26262 中列出的所有三类软件故障。首先，提出强化期限监督机制，使其能够监控程序执行流程，并检查程序中两个检查点（起始检查点和结束检查点）之间的期限错过情况。与 AUTOSAR 原有的期限监督机制相比，该机制能够检测出任务在到达结束检查点之前因阻塞而导致的期限错过情况。具体而言，它会定期检查自起始检查点起经过的时间，一旦超过期限，便立即返回错误。此外，还提出端到端保护机制，用于检测数据传输延迟。该机制在每次接收消息时计算发送时间和接收时间的差值，以此检查是否存在传输延迟。我们在 TriCore™启动套件上实现了所提出的机制，并展示了其能成功检测出预期故障。
本文的其余部分结构如下：下一部分介绍研究工作的背景；然后阐述待解决的问题，并概述所提出的方法；接着详细解释所提出的解决方案机制及其实现方式；最后报告实验评估结果并总结全文。
02
背景
为帮助理解本文内容，下面解释 ISO 26262 的故障检测要求以及 AUTOSAR 的安全机制。
（一）ISO 26262 的故障检测要求
软件故障检测是 ISO 26262 对软件开发规定的基本要求之一。ISO 26262 明确规定了运行时可能出现的软件故障，这些故障被分为三类：（1）定时和执行故障；（2）内存故障；（3）信息交换故障。具体分类见表 1。
表 1：ISO 26262 中软件故障的分类
为检测这些软件故障，ISO 26262 规定了 E/E 系统必要的软件安全机制，包括：（1）输入输出数据范围检查；（2）合理性检查；（3）数据错误检测；（4）外部监控工具；（5）控制流监控；（6）多样化软件设计。达到 ASIL C 或 ASIL D 等级的 E/E 系统必须具备所有这些安全机制，其中（1）至（5）项机制需在运行时使用。为减少开发安全机制的重复工作，提倡在平台层面提供这些安全机制。
（二）AUTOSAR 安全机制
AUTOSAR 一直在积极采用安全机制，以满足 ISO 26262 的功能安全要求。从 4.0.3 版本开始，AUTOSAR 纳入了诸如程序流监控、端到端保护和内存分区等安全机制，以满足 ISO 26262 的故障检测要求。软件开发人员在开发软件组件时应使用这些安全机制。
程序流监控用于检查软件组件的正确执行情况，由一个名为看门狗管理器的任务负责。看门狗管理器是监督程序执行的基本软件模块，其监督的逻辑单元称为被监督实体，它是软件组件代码的一部分。每个被监督实体都有一组检查点，有三种监控方法：（1）存活监督；（2）期限监督；（3）逻辑监督。在存活监督中，看门狗管理器统计被监督实体在给定时间段内到达检查点的次数。若计数低于最小阈值或高于最大阈值，看门狗管理器将返回错误。在期限监督中，看门狗管理器测量两个检查点之间的执行时间，若执行时间超过阈值，则返回错误。在逻辑监督中，看门狗管理器监控检查点的执行顺序，若检测到不安全顺序，则返回错误。
端到端（E2E）保护是一种保护数据免受通信链路故障影响的机制。在数据从发送方发送到接收方之前，发送方会在数据上添加一个 E2E 头部。E2E 头部包含与安全相关的信息，如循环冗余校验（CRC）位和序列计数器。接收方收到数据后，会利用 E2E 头部检查发送的数据是否正确传输。有三种安全检查方法：（1）CRC 校验；（2）数据 ID 检查；（3）序列计数器检查。在 CRC 校验中，E2E 保护封装器比较发送方和接收方的 CRC 校验和，以检查数据在传输过程中是否被更改。在数据 ID 检查中，E2E 保护封装器通过检查数据 ID（分配给发送方和接收方每个端口的 ID）来判断数据是否来自正确的发送方。在序列计数器检查中，发送方每次发送请求时都会递增序列计数器，接收方则会检查其值。
内存分区机制使软件组件能够在单独的内存分区中运行，避免干扰其他软件组件。多个软件组件可组合在一起并放置在一个单独的内存区域中，这样一来，一个组中的软件组件无法修改其他组中软件组件的内存内容。
03
问题陈述
当前 AUTOSAR 的安全机制无法检测出 ISO 26262 中列出的所有类型故障。具体来说，AUTOSAR 无法检测执行阻塞或死锁，这属于定时和执行故障的范畴。在 AUTOSAR 中，只有当被监督实体到达检查点时，看门狗管理器才会被触发。因此，当程序在两个检查点之间无限期阻塞时，看门狗定时器无法正常工作。此外，AUTOSAR 也无法检测信息延迟故障，这属于信息交换故障。AUTOSAR 没有提供用于检查传输数据时效性的 API。表 2 展示了 AUTOSAR 安全机制涵盖的软件故障类型。
本文要解决的问题如下：（1）对于给定被监督实体中的两个检查点，安全机制应在预定时间内检测出两个检查点之间发生的执行阻塞；（2）安全机制应检测出发送方和接收方之间大于给定阈值的传输延迟。
表 2：AUTOSAR 安全机制与软件故障之间的关系
04
满足ISO 26262功能安全需求的安全机制
为解决上述问题，本文为 AUTOSAR 提出两种安全机制：（1）期限监督机制，用于在预定时间内检测执行阻塞；（2）端到端保护机制，用于检测数据传输延迟。
期限监督机制监控程序执行流程，检测程序中两个检查点之间的期限错过情况。这两个检查点分别称为起始检查点和结束检查点。当被监督实体到达起始检查点时，看门狗管理器会调用一个名为 WdgM_ChckpointReached () 的函数，该函数记录起始检查点的到达时间。之后，看门狗管理器会定期计算自控制通过起始检查点起经过的时间。若计算出的时间超过给定期限，看门狗管理器将返回错误，并调用用户定义的回调函数来处理故障。
为检测数据传输延迟，端到端保护机制计算发送时间和接收时间的差值。为此，我们对当前 AUTOSAR 的 E2E 头部进行了修改，具体是添加了两个额外字段：发送时间和延迟阈值。发送方在发送数据时会附上 E2E 头部并将数据发送给接收方。接收方收到数据后，用当前时间减去头部中存储的发送时间，计算出经过的时间，然后将计算出的时间与阈值进行比较。若计算出的时间大于阈值，则返回错误。当出现错误时，会调用用户定义的回调函数来处理故障。
05
实验评估
我们在 TriCore™启动套件上的 AUTOSAR 3.1 版本中实现了所提出的解决方案，并在目标系统上进行了一系列实验。目标系统的详细硬件和软件规格见表 3。
表 3：目标系统描述
在一次实验中，我们创建了一个软件组件，其中一个被监督实体由看门狗管理器监控，该实体有两个检查点：起始检查点和结束检查点。我们运行被监督实体，并在起始检查点和结束检查点之间阻塞其执行，然后测量看门狗管理器检测到这种阻塞所需的时间。我们的期限监督机制在规定时间内检测到了执行阻塞。
在另一项实验中，我们使用了两块 TriCore™启动套件板，在一块板上放置发送方软件组件，在另一块板上放置接收方软件组件。当发送方软件组件向接收方软件组件传输数据时，我们延迟传输，检查我们的端到端保护机制是否能检测到传输延迟。结果显示，该机制成功检测到了所有传输延迟。
06
结论
本文为 AUTOSAR 提出了两种安全机制，以检测 ISO 26262 中列出的所有三类软件故障。首先，引入了强化的期限监督机制，能够检测任务的无限期阻塞。它会定期监控自起始检查点起经过的时间，一旦超过期限便立即返回错误。其次，提出了端到端保护机制，能够检测数据传输延迟。该机制在每次接收消息时计算发送时间和接收时间的差值，一旦出现传输延迟便返回错误。我们在 TriCore™启动套件上实现了该解决方案，并证明其成功检测出了预期故障。
来源：豆包软件翻译
end
精品活动推荐
AutoSec中国行系列沙龙
专业社群
部分入群专家来自：
新势力车企：
特斯拉、合众新能源-哪吒、理想、极氪、小米、宾理汽车、极越、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯......
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚......
内资传统主流车企：
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用......
全球领先一级供应商：
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、赢彻科技、潍柴集团、地平线、紫光同芯、字节跳动、......
二级供应商(500+以上)：
Upstream、ETAS、Synopsys、NXP、TUV、上海软件中心、Deloitte、中科数测固源科技、奇安信、为辰信安、云驰未来、信大捷安、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、软安科技、浙江大学......
人员占比
公司类型占比
更多文章
关于涉嫌仿冒AutoSec会议品牌的律师声明
一文带你了解智能汽车车载网络通信安全架构
网络安全：TARA方法、工具与案例
汽车数据安全合规重点分析
浅析汽车芯片信息安全之安全启动
域集中式架构的汽车车载通信安全方案探究
系统安全架构之车辆网络安全架构
车联网中的隐私保护问题
智能网联汽车网络安全技术研究
AUTOSAR 信息安全框架和关键技术分析
AUTOSAR 信息安全机制有哪些？
信息安全的底层机制
汽车网络安全
Autosar硬件安全模块HSM的使用
首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议
