Autosar架构下的IDS

1 分布式车载IDS架构

1.1 分布式车载IDS架构主要由四部分组成：

• 安全传感器(SE)

• 入侵检测系统管理器（IdsM）

• 安全事件存储（Sem）

• 入侵检测系统报告器（IdsR）

  

1.2 安全传感器和安全事件

AUTOSAR的BSW，CDD和SWC模块都可以被指作为安全传感器，安全传感器将安全事件报告给IdsM。AUTOSAR将可以由BSW报告的安全事件类型进行了标准化，可以在各BSW软件规范文档中检索到，SWC和CDD也能报告这样的事件，不过它们的安全事件类型并未标准化，特定ECU报告的安全事件可以通过Security Extract定义，相关文档需要参考AUTOSAR_TPS_SecurityExtractTemplate。

1.3 入侵检测系统管理器

IdsM会将报告的安全事件缓存下来，然后将它们应用于一组连续的过滤条件，也称作为过滤链，如果某一安全事件通过了过滤链，那么此安全事件被视作为合格安全事件（QSEv）。根据配置的不同，IdsM会将QSEv保存在安全事件存储这样的非易失性存储区域当中，或者同时将他们序列化之后发送给IdsR。

IDSR可以丰富QSEv，例如添加地理位置信息。但是AUTOSAR中并未提供IdsR的规范，可根据实际情况实现。

1.4 入侵检测系统报告器

IdsR从各个ECU的IdsM实例接收发送而来的QSEv，通信协议由IdsM协议规定。IdsR一般还会在接收到数据后添加地理位置等信息。基于OEM的需求，数据可以发送到SOC，进行更详细的安全事故事件分析。AUTOSAR不对IdsR进行规范制定。

2 需求规范

• 收集有关安全事件（SEv）
• 从安全事件数据中筛选合格的车载安全事件
• 本地存储QSEv记录
• 将ECU中的QSEv通过连接转发到SOC
• 访问本地存储的QSEv记录
• 在运行期重新配置鉴定参数
• 更新IdsM配置
• 保护IdsM配置
• 保护传输和持久化的IdsM数据

3 功能需求

3.1 初始化

IdsM过滤链规则应在启动时初始化，IdsM需要配置信息才能执行其操作。因此该信息应从NVM中恢复，并在其启动之前进行初始化处理操作。（NvM模块负责管理和从非易失性内存中读写数据。在系统启动和关闭阶段，同步应用程序RAM区的数据。此模块还提供其他服务，例如用于上层数据保护的冗余数据单元。同时，RTE提供了简单灵活和接口（NvData Interface）用于非易失内存的数据处理。MvM在CP中属于BSW）。

3.2 上传SEv

IdsM应提供报告SEv的接口。接口应允许以报告以下SEv属性：

• 安全事件类型：唯一标识安全事件类型
• 上下文数据：可用于SOC分析安全事件的可选数据
• 时间戳：Sensor提供的可选时间戳。
• 计数：传感器提供的可选计数。

基本软件、复杂的设备驱动程序和应用软件可以通过接口上传SEv。

3.3 缓存上报的SEv

IdsM应为Sensor缓存上报的SEv，IdsM应缓存SEv传感器的SEv和上下文数据，直到数据完全由IdsM处理完成。

3.4 过滤SEv

3.4.1 上报模式

IdsM应支持为IdsM实例处理的每种安全事件类型配置上报模式。上报模式应包括以下选项:(a)关闭SEv的处理，(b)丢弃上下文数据，以及©绕过后续过滤器。

上报模式允许控制是否对事件感兴趣，以及是否应该进一步处理它。

3.4.2 过滤器链

为合格的SEv提供可配置的过滤器链：IdsM应通过对上报的SEv应用可配置的过滤器链来验证SEv的有效性。一个已配置的过滤器序列称为过滤器链。并非总是将单个SEv作为合格的安全事件直接处理。根据项目特定的安全分析，可以使用一个或多个筛选器应用于报告的SEv。如果SEv通过所应用的滤波器链的所有滤波器，则该事件是合格的（即它是QSEv）。然后将传输事件和/或持久化。

提供多个过滤链：IdsM应支持创建多个过滤器链，并支持将给定安全事件类型的每个SEv单独分配给每个IdsM实例的特定过滤器链

3.4.3 机器状态过滤器

IdsM应支持依赖于ECU/机器状态的SEv处理。因为某些事件定义可能仅在某些状态下相关，而在其他状态下应该忽略。

3.4.4 抽样过滤器

IdsM应支持SEv的抽样，可以降低可能以非常高的频率发生的安全事件的数据速率。

3.4.5 聚合过滤器

IdsM应支持将多个SEv聚合为一个QSEv表示聚合SEv发生的频率。事件的聚合可以减少高频率发生的SEv的资源消耗，同时保持有关事件发生总数的信息。

3.4.6 阈值过滤器

如果SEv在可配置的时间间隔内发生的频率超过可配置的阈值，则IdsM应仅支持上报此情况下的SEv。SEv可能是由正常操作定期触发的所以不需要上报，但是，偏离正常频率可能表明应该上报这种事件。

3.5 事件时间戳

事件的时间戳：IdsM应提供向sev添加时间戳的机制，对某些事件的分析可能需要事件发生的时间。

时间戳的来源：IdsM应提供让应用程序或传感器软件提供时间戳的机制。项目特定的应用程序或传感器可以提供更准确的时间戳。

3.6 QSEv向IdsR上传

IdsM应允许使用独立于底层总线技术的IDS协议来传输QSEv和上下文数据。QSEv由ECU上报，ECU可以连接到系统的其余部分E/E体系结构与各种总线系统。IdsR可以将事件转发到SOC。

3.7 QSEv的持久化

IdsM应该能够通过用户定义的诊断内存在本地持久化qsev。用户定义的诊断内存应与主诊断存储器分开，以便对用于存储QSEv记录的NV块进行单独的访问控制和保护。(这种用户定义的诊断内存也称为安全事件内存)QSEv的以下属性将被持久化:

• 指示协议版本和使用协议选项的IDS协议头
• IdsM实例的标识符
• Sensor模块实例的标识符
• 有效的SEv的标识符
• 指示SEv被认定合格前的上传频率的计数器
• 指示SEv被认定合格的时间戳（可选）
• 供具有访问权限的诊断测试器、SOC或其它安全分析实例评估的上下文数据（可选）
• 用于保证IsdM上传到SOC事件完整性和安全的签名（可选）

可以在将来的时间点访问持久化QSEv进行分析，而无需依赖于例如网络连接等。

3.8 配置

SEv的配置：IdsM报告的SEv应该是可配置的。根据项目特定的安全性分析，一些SEv被认为是有价值，而其他SEv则被认为是无关紧要的。为了避免传感器模块对IdsM的不必要调用，该属性应根据每个IdsM实例的安全事件类型进行配置。

SEv的和格性过滤器配置：IdsM对SEv应用哪些和格过滤器应该是可配置的，根据特定于项目的安全性分析，需要应用不同的限定过滤器来限定不同的SEv类型。

QSEv的持久性处理配置：如果QSEv要在本地持久化，那么它应该是可配置的，将根据项目特定的安全性分析和可用资源(例如NVM)来决定是否持久化QSEv。各自的属性(例如缓冲区的大小)需要是可配置的。

QSEv的上传处理配置：根据项目特定的安全分析和可用的资源(例如:将对QSEv的上传作出决定。各自的属性(例如QSEv的I-PDU)需要是可配置的。

3.9 重新配置

在运行时重新配置，支持在运行时期间重新配置上报模式，应该可以在运行时更改SEv的上报模式。IdsM应提供可用于诊断程序等的接口。

3.10 更新IdsM配置

更换完整的过滤器链配置，IdsM应允许更换完整的过滤器链配置。在线路末端编程、ECU在车间初始化或通过OTA推出新更新等情况下，应可以更换完整的过滤器链配置。

支持方式：实际的替换/更新可以是由FBL或OTA执行的逻辑块的标准SW更新。

3.11 与安全相关的需求

3.11.1 基础软件的安全事件类型

被认为与安全有关的基本软件模块，应向IdsM报告安全事件。基本软件模块是否被视为与安全有关，由一个专门的AUTOSAR工作小组讨论和决定。安全事件类型的规范是根据相关AUTOSAR成员的需要完成的。

3.11.2 IdsM安全事件类型

在下列情况下，IdsM应报告IdsM的具体安全事件:

• 超过IdsM流量限制
• 如果IdsM上下文缓冲区耗尽
• 如果IdsM事件缓冲区耗尽

IdsM应提供支持其自身安全事件的手段。

3.11.3 端到端传输QSEV的真实性

IdsM应支持签名QSEv，包括所有可选数据（例如，上下文数据、时间戳）。以确保事件的真实性。

3.11.4 存储的QSEv记录的真实性

支持检测QSEv记录的操作，存储器堆栈应能够选择性地检测持久化QSEv记录的操作。如果检测到对QSEv记录异常的操作，内存堆栈将引发安全事件。根据OEM的安全分析，可能需要检测QSEv记录的操作。

3.11.5 可用性

限制事件速率和流量，IdsM应支持限制发送到IdsR的QSEv的速率和这些传输消耗的带宽。限制由IDS引起的网络总线负载。

4 依赖模块

AUTOSAR入侵检测系统管理器包括BswM、Dcm、DET、Dem、NvM、PduR和RTE模块的头文件。此外，它为基本软件模块和软件组件(传感器)提供通用接口，用于报告它们的SEv。下图显示了AUTOSAR BSW中为其他模块提供和需要的接口。

5 传输协议