AUTOSAR 信息安全机制有哪些？

AUTOSAR 信息安全机制有哪些？

虽然AUTOSAR不是一个完整的安全解决方案，但它提供了一些安全机制用于支持安全关键系统的开发。本文用于介绍AUTOSAR支持的四种功能安全机制：

1. 内存分区（Memory Partitioning）

2. 时间监控（Timing Monitoring）

3. 逻辑监督（Logical Supervision）

4. 端到端保护（End-2-End Protection）

这些安全机制中，内存分区用于实现不同ASIL等级，安全相关组件和非安全相关组件的彼此独立，时间监控和逻辑监控是软件运行时序错误的常用检测方法，端到端保护实现了安全相关应用在非受信网络或存储之间数据交互的安全。

1. 内存分区

内存分区用于解决不同软件组件之间的互相干扰，造成对内存存储的数据段或代码段的篡改，需要限制对内存和内存映射的硬件外设的访问。

在AUTOSAR架构下，分区是以OS-Application为对象划分的，属于一个OS-Application内的任务可以互相访问，一个OS-Application包括多个任务Task，软件组件SW-C的实现由一组可运行实体Runnable组成，Runnables在其调用者OS-Task的上下文中被循环执行和/或以事件作为触发。下图是OS-Application、Task、Runnable、SW-C之间的关系。

AUTOSAR 操作系统将OS-Application放入独立的内存区域，由操作系统实现不同应用免受内存故障干扰，这种机制称为内存分区。

由于在一个OS-Application的内存分区中执行的代码不能修改其他内存区域，因此OS-Application之间相互保护。

具有不同 ASIL等级的软件组件不应分配给同一个 OS-Application。操作系统只是防止其他 OS-Application进行不适当的访问。一个有问题的软件组件不会被阻止修改同一 OS-Application中其他软件组件的内存区域。同一软件组件不能分配到不同的OS-Application中。

内存分区的实现方案是通过CPU的supervisor/ user mode进行分区

基础应用任务运行于supervisor mode

普通应用任务运行于user mode

所有的基本软件模块都在一个trusted/supervisor 模式的内存分区中执行(红色)。

一些软件组件在逻辑上被分组，放在单独的non-trusted/user模式的内存分区中（绿色）。

选定的软件组件属于与基本软件模块相同的受信任/监督者模式内存分区（见图8中第四个SW-C以红色突出显示）。可能有几个非信任/用户模式分区，每个分区包含一个或多个软件组件。

内存分区功能需要专用硬件支持MPU（memory protection unit），MPU允许非受信的应用访问微控制器地址空间的多个部分，访问控制定义为Read/ Write/Execute访问的组合。MPU的配置只允许在supervisor模式下进行。硬件由操作系统进行适当的配置，以检测和防止错误的内存访问，然后监控在非受信/user模式内存分区中软件组件的执行。

错误处理策略：

如在非受信/user模式分区中出现内存访问违规或CPU指令违规，错误的访问将被阻止，并由微控制器硬件提出一个异常。操作系统和RTE通过执行分区关闭或重新启动该分区的所有SW-C来处理错误的软件分区。

2.时间监控

为避免软件组件之间出现的执行阻塞、死锁、活锁、执行时间的不正确分配、软件元素之间的不同步，需要对软件的运行时间进行监控，以确定软件运行的正确时序。

受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。受监督实体中的重要位置被定义为checkpoint。受监督实体的代码与看门狗管理器的函数调用交错在一起。这些调用用于向看门狗管理器报告达到了一个checkpoint。

看门狗管理器实现两种监督方式：Alive supervision和Deadline supervision。

• Alive Supervision: 周期检查被监督实体的checkpoint是否在给定的范围内到达。这意味着看门狗管理器检查被监督实体的运行频率是否过高或过低。

• Deadline Supervision：非周期性或偶发性的被监督实体对两个checkpoint之间的时间有单独的约束。

通过Deadline Supervision，看门狗管理器检查被监督实体的两个checkpoint之间的转换时间。

这意味着看门狗管理器检查被监督实体的某些步骤所需时间是否在配置的最小和最大范围内。

错误处理策略：

当检测到错误时，看门狗管理器将启动以下错误处理策略的一种：

1. 被监督实体内的错误处理：如果被监督实体是SW-C或CDD，看门狗管理器可以通过RTE模式机制通知被监督实体监督失败的情况，然后，被监督实体可以采取其行动从该故障中恢复。

2. 分区关闭：如果看门狗管理模块检测到位于非信任分区的被监督实体的监督失败，看门狗管理模块可以通过调用BswM请求分区关闭。

3. 由硬件看门狗复位：看门狗管理器向看门狗接口指示看门狗接口何时应不再触发硬件看门狗。在硬件看门狗超时后，硬件看门狗对ECU或MCU进行复位。这将导致ECU和/或MCU硬件的重新初始化和软件的完全重新初始化

4. 立即MCU复位：如果有必要对监控故障做出立即的、全局的反应，看门狗管理器可以直接导致MCU复位。这将导致MCU硬件和整个软件的重新初始化。通常情况下，MCU复位不会重新初始化ECU的其他硬件。

3.逻辑监督

逻辑监督用于检查软件是否按照正确的逻辑顺序执行。如果一条或多条程序指令以不正确的顺序被处理，或者甚至根本没有被处理，就会发生不正确的控制流。

例如，控制流错误会导致数据不一致、数据损坏或其他软件故障。程序序列的逻辑监测是ISO26262、IEC61508、MISRA所要求或建议提出。

与时间监控一样，受监督的软件实体可以是软件组件、基础软件模块或CDD中的一个SW-C或Runnable。

逻辑监督同样基于checkpoint进行检查，每个被监督实体都有一个或多个checkpoint。一个被监督实体的checkpoint之间的转换形成一个图。

一个图可以有一个或多个初始checkpoint和一个或多个最终checkpoint。假设checkpoint属于同一个图，那么从任何初始checkpoint开始到任何最终checkpoint结束的任何顺序都是正确的。

错误处理策略：逻辑监督的故障处理策略与时间监控的处理策略一致。

4.端到端保护

在一个分布式系统中，发送方和接收方之间的数据交互可能会影响功能安全，如果其安全行为的安全性取决于这些数据的完整性。因此，此类数据的传输应使用保护机制，以防止通信链路内的故障影响。

数据传输存在以下故障类型：

• 信息的重复：一种通信故障，即信息被接收一次以上
• 信息的丢失：一种通信故障，即信息或部分信息从传输的信息流中被删除
• 信息的延迟：一种通信故障，即信息的接收比预期的晚
• 信息的插入：一种通信故障，即在传输的信息流中插入额外的信息
• 信息的伪装：一种通信故障，即非真实的信息被传输者当作真实的信息接受。
• 信息的不正确的寻址：一种通信故障，即信息被不正确的发送者或不正确的接收者所接受。
• 信息的不正确顺序：一种通信故障，它修改了传输信息流中的信息顺序
• 信息的破坏：一种通信故障，它改变了信息。
• 从一个发送方发送至多个接收方的不对称信息：一种通信故障，即接收者确实从同一个发送者那里收到不同的信息
• 从一个发送方发出的信息只被一个子集的接收方收到：一种通信故障，一些接收者没有收到信息
• 阻断对一个通信通道的访问：一种通信故障，即对通信通道的访问被阻断。

这些故障类型存在于一个ECU内部的不同软件组件、OS-Application，也存在于不同ECU硬件之间。

实现端到端保护的方法是在通信协议中，数据发送方增加端到端控制信息，控制信息通常包含

一个校验和

一个计数器

其他选项。

扩展后的数据元素被提供给RTE进行传输。

数据元素在接收方通过处理端到端控制信息的内容与应用数据进行验证。在收到的数据元素被处理并接受为正确后，控制信息被删除，应用数据被提供给目标软件组件，错误处理是在接收方进行的。

端到端的数据保护机制包括：

• CRC校验和，用于检验数据是否被破坏；

• 顺序计数器，在每次传输请求时递增，该值在接收方检查是否正确递增，用于检查数据是否丢失、插入、顺序混乱；

• 在每个传输请求中增加的alive counter，如果它有任何变化，在接收方检查其值，但不检查正确的增量；

• ID:通过端口发送的每一个端口数据元素都有一个特定的ID（对系统来说是全局的，因为系统可能包含几个ECU）；

• 超时检测，接收器通信超时和发送器确认超时。

AUTOSAR 4.2.1 版还引入了一个状态机，帮助确定所收到的应用数据是否可以接受，并且更加详细。通信状态机用于接收方接收到正确数据、错误数据以及可恢复、不可恢复的状态转换。

端到端保护以软件库的方式提供，可以有不同的解决方案。它们可能取决于RTE、COM或其他基本软件模块的完整性，以及其他SW/HW机制的使用（例如，内存分区）。

错误处理策略：端到端通信保护功能在 AUTOSAR 4.0 中作为标准库实现。

这个库提供了End-2-End通信保护机制，使发送方能够在传输前保护数据，接收方能够在运行时检测和处理通信链路中的错误。当接收方检测到通信错误后，将向应用提供错误类型，数据处理方式（丢弃/使用上周期/重启）。

从软件应用层来看，端到端通信保护是一个点对点的连接，但为了达到多点通信的灵活适用性和互通性，300多页的端到端设计规范可以看出，在通信协议的设计上需要考虑很多

总结:

以上是AUTOSAR架构提供的四种功能安全机制，用于在

• 内存保护
• 软件执行的时间
• 逻辑顺序
• 数据交互需要考虑的安全机制

这些内容更多是规范性方面的要求，不涉及具体的实现方法，例如时间和顺序监控中，看门狗的checkpoint应该设置多少个，监督检测到错误应该采用何种处理，由各厂商在遵循AUTOSAR框架下去具体实现，为保证互通性，AUTOSAR仅提供统一的外部调用接口；

这些安全措施作为ISO26262中的通用性安全要求，应予以遵循，但AUTOSAR没有从系统层进行结构化的安全分析，这些安全要求并不完备，也没有ASIL等级，还应结合具体的相关项定义进行补充和规定。

从应用方角度来看，安全功能的设计实现不是应用方所关注的，已在AUTOSAR架构中予以实现，应用只要实现对这些功能进行参数配置，按照给定手册中的要求进行调用即可，简化了安全功能的实现过程，另一方面来说，由于对接口做了封装，也了解不到具体的实现细节。

本文主要内容来自于AUTOSAR官方文档《Overview of Functional Safety Measures in AUTOSAR》，如有疏漏，以原文为准。

另外一篇

AUTOSAR 信息安全机制有哪些？汽车不再孤立，越来越多地融入到互联网中https://mp.weixin.qq.com/s/IYmBVYgm6yYzsmZsh1iKZw

随着汽车网联化和智能化，汽车不再孤立，越来越多地融入到互联网中。在这同时，汽车也慢慢成为潜在的网络攻击目标，汽车的网络安全已成为汽车安全的基础，受到越来越多的关注和重视。AUTOSAR作为目前全球范围普遍认可的汽车嵌入式软件架构，已经集成的相关信息安全模块对实现信息安全需求有着充分的支持，例如保护车内通信或保护机密数据。

由于CP AUTOSAR 和AP AUTOSAR 的体系结构不同，目前信息安全模块的相关技术实现也存在差异。

1. SecOC

在车载网络中，CAN 总线作为常用的通讯总线之一，其大部分数据是以明文方式广播发送且无认证接收，这种方案具有低成本、高性能的优势。

但是随着汽车网联化、智能化的业务需要，数据安全性越来越被重视。

传统的针对报文添加RollingCounter 和 Checksum 信息的方法，实现的安全性十分有限，也容易被逆向破解，进而可以伪造报文控制车辆。

SecOC 是在AUTOSAR 软件包中添加的信息安全组件，主要增加了加解密运算、密钥管理、新鲜值管理和分发等一系列的功能和新要求。该模块的主要作用是为总线上传输的数据提供身份验证，它可以有效地检测出数据回放、欺骗以及篡改等攻击。

图4.1-1消息认证和新鲜度验证流程

在SecOC 标准中，AUTOSAR 主要基于MAC 的身份验证和Freshness 的防重放攻击，来实现数据的真实性和完整性校验。

首先MAC（Message Authentication Code）是保障信息完整性和认证的密码学方法之一，其中CMAC（Cipher based MAC）一般用于对称加密，整车厂可在车辆下线刷写程序时静态分配密钥，也可选择使用云端服务器动态地给车辆分配密钥）是车载总线加密认证常用方案。

MAC 的作用不是防止有效数据被泄露，而是为了保护数据不会被攻击方篡改，即完成数据来源的认证。如需保护通信数据不被攻击方监听，则报文的有效数据还需要进行额外的加密。

为了降低重复攻击的风险，则需要在Secured I-PDU 中加入新鲜度值，Freshness Value 是一个根据一定逻辑不断更新的数值，Freshness Value 的更新方法多种多样，AUTOSAR 标准将基于计数器或基于时间的新鲜度值作为典型选项。

在CP AUTOSAR 平台，SecOC 模块依赖于PduR 的API 和功能，提供了PDU Router 所需的上下两层API（upper and lower layer API）功能。

依赖于由CSM 模块在AUTOSAR 中提供的加密算法。SecOC 模块需要API 函数来生成和验证加密签名（Cryptographic Signatures）或消息验证码（Message Authentication Codes）。为RTE 提供具有管理功能的API 作为服务接口进行调用。

SecOC 通信协议特性同样适用于AP AUTOSAR 平台标准中，其主要目标是实现与CP AUTOSAR平台SecOC 功能互操作性，尤其适用于使用 UDP 多播的消息场景（SecOC 是目前唯一支持的协议）和与CP AUTOSAR 之间基于信号的网络绑定的安全通信场景。

图4.1-2 AP AUTOSAR通信管理中的SecOC

为了实现与CP AUTOSAR 平台的互操作性，SecOC 同样应用于Adaptive CM 中。

认证信息包括认证器（例如，消息认证码）和可选的新鲜度值。为了保持与CP AUTOSAR 平台的互操作性并提供可选的新鲜度值管理功能，AP AUTOSAR CM 将依赖于可插入的新鲜度值管理库。该库将提供新鲜度值管理相关的API，包含CP AUTOSAR 平台关于Freshness Management 客户端、服务端接口的副本以及调用定义的相关功能。

SecOC 的核心思想在于通信认证，但是不涉及报文加密。虽然伪造报文的难度已经大大提升了，但是在通信过程中采用明文传输，依旧有一定的风险；认证信息的强度和信息长度相关，通信认证方案会加大报文负载（传统CAN 报文的负载只用8-64 个字节），从而导致负载率提升，通信实时性下降，可能使得正常功能受到影响，应考虑信息安全强度与通信实时性的相互平衡；

MAC 技术应考虑对称密钥的管理和共享的问题，目前大部分MCU 是没有安全功能的，对称密钥也是明文保存在系统或者内存中。共享该密钥时采用明文通信，这是非常不安全的。但MCU 的计算能力和存储空间是有限的，采用了安全机制以后，必然占用很大的资源消耗，应充分考虑系统的稳定性，以保障业务与安全机制能够正常运行；

SecOC 用于保证安全通信，必然涉及密钥（key）的管理，应考虑灌装、更新和维护该key, 同时还需考虑换件后key 的一致性。

2. TLS

TLS（Transport Layer Security）作为传输层的中坚力量，可以支撑上层的SOME/IP、MQTT 和HTTP 等协议。不但可以用于V2X 的安全通讯，也可以用于车内通讯节点之间的安全通讯。当然像T-BOX等可以与车外节点通讯的节点来说，其安全性要求更高，可以应用更加完整的广义TLS，既安全，又灵活。

而车内之间一般IP 地址、端口、服务接口等都固定，安全性要求也不如T-BOX 高，则可以应用广义TLS中的预共享密钥（TLS_PSK）等套件，既高效，又稳定。

TLS 属于工作在传输层的协议，它介于传输层底层协议和上层应用协议之间。

而以太网的传输层主要有两大底层协议：

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。

二者各有特点，互为补充。

不管在传统互联网上，还是车载以太网上，两者都是常见的传输层底层协议。不同的传输层底层协议实际上对应着不同的传输层安全保护协议，采用TCP 传输的，就用TLS 保护。采用UDP 传输的，就用DTLS 保护。

DTLS 的全称是Datagram Transport Layer Security，比TLS 多出来的“D” ，指的就是UDP 中的“D” 。

TLS 和DTLS 各有不同的版本，目前主流支持的还是1.2 和1.3版本。

AUTOSAR 标准基于Ethernet 架构同时提供了ISO DoIP 的解决方案。

DoIP 全称是Diagnostic Over IP，顾名思义就是基于IP 的诊断。

DoIP 具有处理大量数据、节省重编程时间、方便接入IT 设施、标准通信灵活使用等优势。普通的DoIP 是基于TCP 进行诊断通信，在ISO 13400-2 2019 版本中定义了安全的DoIP 会话，即基于TLS 进行诊断通信。

DoIP server 协议栈会根据DoIP client 实体的请求，确定使用TCP 还是TLS 进行诊断信息的传输。TLS 允许在Client DoIP 实体和Server DoIP 实体之间建立经过身份认证和加密的通信通道，Client DoIP实体身份的验证可以在诊断应用层中实现，例如ISO 14229 中定义的0x29 服务。

TLS 技术仍有自身的技术局限性。大部分控制器都是采用了MCU，计算能力和存储空间都是有限的，采用了安全机制，例如加解密算法、消息摘要算法、签名验签算法等，必然占用很大的资源消耗，应考虑在不影响正常功能的情况下安全策略能够正常实施。

SSL/TLS 采用安全认证的方式来识别对方身份，需要提前灌装安全证书，如果控制器进行换件，应保证证书的一致性，让新的控制器能够进行身份的合法验证，从而正常通信。

在实际应用场景中，大部分控制器可能没有安全存储环境（SE 或者HSM 等），应考虑保证证书和私钥的安全存储。

在采用TLS 进行安全认证通信中，必然会降低通信的效率，应考虑通信的实时性。安全技术应用的同时会带来一些资源消耗，产生一定的局限性。

应当在满足汽车信息安全相关法规标准的原则下，技术手段在不影响控制器正常运行的前提下，进行方案选型完成集成部署，如果内部安全通信技术手段消耗过多的控制器资源并影响了正常业务运行，应适当降低安全等级，必须同时兼顾控制器运行和内部安全通信。

随着汽车网联化的发展，以太网通讯已经在车内通讯及车联网普及，TLS 和DTLS 也更多地出现在汽车行业的视野里。

AUTOSAR 在CP 和AP 中也加入了TLS 和DTLS 的规范。从AUTOSAR CP 4.4 标准开始就明确了支持1.2 和1.3 版本，优先选择1.3 版本。

AP R21-11 中只描述了1.2 版本，但相信将来版本也会加上1.3 版本。

3. IPsec

IPsec（Internet Protocol Security）是网络安全协议，运行在OSI 模型的第三层（Internet Protocol，IP 层），在VPN（Virtual Private Network）应用很广泛。

IPsec 在IP 层对报文提供数据机密性、数据完整性、数据来源认证、防重放等安全服务，定义了如何在IP 数据包中增加字段来保证IP 包的完整性、私有性和真实性，以及如何加密数据包。

图4.1-3 IPsec协议及组件功能

IPsec 提供了两种安全机制：认证和加密。

认证机制使IP 通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。

加密机制通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。

IPsec 的安全体系由下面三部分组成：

1. 验证头协议（Authentication Header，AH）
2. 安全封装协议（Encapsulating Security Payload ，ESP）
3. 安全联盟（Security Association，SA）

AH 是认证头协议（IP 协议号为51），主要提供的功能有数据源验证、数据完整性校验和防报文重放功能，可选择的散列算法有MD5（Message Digest ），SHA1（Secure Hash Algorithm）等。

ESP 是报文安全封装协议（IP 协议号为50），ESP 将需要保护的用户数据进行加密后再封装到IP 包中，验证数据的完整性、真实性和私有性。可选择的加密算法有DES，3DES，AES 等。

SA（Security Association）是IPsec 的基础，也是IPsec的本质，IPsec 对数据流提供的安全服务通过SA 来实现，它包括协议、算法、密钥等内容。IPsec 有隧道（tunnel）和传输（transport）两种运行模式，运行模式和安全体系中的AH 及ESP 组合形成4 种情况：隧道模式+AH、隧道模式+ESP、传输模式+AH 以及传输模式+ESP。

AUTOSAR CP R19-11 标准在TCP/IP 模块加入IPsec 相关功能介绍，并对功能实现进行了条件约束，目前只支持IPsec 运输运行模式，隧道运行模式、IPv6 和多点传播都暂不支持。

并规定了其他模块可执行的操作内容，KeyM 模块可为IPsec 子模块提供证书处理，CSM 允许执行IPsec 子模块所使用的加密作业和密钥操作。

AUTOSAR AP 中IPsec 协议实施的目标是在车载IP 网络中提供安全的通信通道。

在 AUTOSAR 自适应平台中实施IPsec 将为网络节点之间的通信提供保密性、完整性或两者兼备的选项。IPsec 作为标准网络安全协议提供了安全通信的手段，同时支持多供应商堆栈互操作性。自适应平台没有为电子控制单元指定任何操作系统，因此是IPsec 功能最好的实践方式。

4. Crypto Stack

为了汽车软件提供统一的安全加密/ 解密接口，AUTOSAR 在4.3 版本推出Crypto Stack 模块。Crypto Stack 是AUTOSAR 架构体系中负责数据加密保护和密钥管理的模块，

由Crypto Service Manager,Crypto Interface, Crypto Driver 三个部分组成，为应用程序和系统服务提供了标准化的密码服务接口。密码服务可以是哈希计算，非对称签名验证，对称加密等。其主要应用于ECU 通信加密、SecurityAccess 流程保护和KEY 的管理等使用场景。

CSM(Crypto Service Manager）是加密服务管理器，位于AUTOSAR 的SYS 模块最高层的服务层。服务层是基础软件的最高层，它的任务是为应用软件和基本软件模块提供基本服务，即为应用软件和基本软件模块提供最相关的功能。

CSM 基于一个依赖于软件库或硬件模块的加密驱动程序来提供加密功能的服务，也可以使用多个加密驱动程序的混合设置。CSM 通过CryIf(Crypto Interface）访问不同的加密驱动程序。

图4.1-4 CSM和邻近模块的关系

CSM 作为服务层，为SWC 或BSW 提供加密操作的接口。

CSM 的主要任务是对服务进行调度和排序，并调用加密接口（CryIf）进行进一步操作。

CryIf 将请求调度到加密驱动程序及其静态分配给该服务的加密驱动程序对象。

CSM 使用基元（CsmPrimitives，已配置加密算法的实例）的静态配置来定义加密操作。然后将这样的基元分配给Job(Job 是配置过的CsmJob，指的是密钥、密码原语和参考信道），该配置决定进一步的属性，如优先级、异步或同步执行以及程序执行中应使用的密钥。需要注意的是，密钥总是位于加密驱动程序本身中，CSM 只使用对它的引用。

密钥和基元的分离允许加密操作和密钥管理API 分离。这使得应用程序可以专注于所需的加密操作，如MAC 计算和验证，而密钥管理器则在配置设置期间提供密钥。

CSM的API大致可以分为两类：

直接AP（I 主要用于密钥管理）和基于Job的AP（I 主要用于加密操作）（见下图）

直接API 与CryIf 和Crypto Driver 中的函数有直接对应关系，这些函数只能同步调用，CSM将把参数从应用程序直接传递给函数调用。

基于Job 的API 使用一个Job 结构，即Crypto_JobType，它包含静态和动态参数以及对结构的引用，为执行该Job 的加密驱动程序提供所有必要的信息，使用Job 的每个服务都将使用此结构。服务的所有必要参数将由CSM 打包到结构的元素中，然后调用CryIf，然后调用配置好的Crypto Driver。

图4.1-5 CSM、CryIf和Crypto的Job API和直接API调用树

Job 可以同步运行，也可以异步运行，这取决于静态配置。加密服务信息、加密算法族和模式的参数决定了加密驱动程序中要执行的确切的加密算法。

CryIf（Crypto Interface）是加密接口模块，位于BSW（Basic SoftWare）的抽象层。

CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案，如 HSM、SHE 或基于软件的 CDD。

图4.1-6 AUTOSAR Layered View with Crypto-Interface

CryDrv 有如下两种实现方式：

1. Crypto（HW based）：硬件加密模块的驱动程序，用于控制HSM（Hardware Security Module）或SHE（Security Hardware Extensions），和具体芯片有关。

2. Crypto（SW based）：基于软件的CDDs（Complex Device Drivers） 实现的加密算法， 如AES-128 等算法。

基于以上两种不同的实现方式，CryIf 模块提供了唯一的接口来管理不同的加密硬件和软件解决方案。因此，基于 CryIf 维护的映射方案，CSM 模块可以使用多个底层的Crypto HW 以及 Crypto SW 解决方案。此外，CryIf 还确保了对加密服务的并发访问，从而能够同时处理多个加密任务。

与CP AUTOSAR 不同，AUTOSAR 自适应平台支持用于通用加密操作和安全密钥管理的API。该API 支持在运行时动态生成密钥和加密作业，以及对数据流进行操作。API 实现可以引用一个中央单元（加密服务管理器）来实现平台级任务，例如跨应用程序一致地进行访问控制和证书存储。该实现还可以使用加密服务管理器来协调功能到加密驱动程序的卸载，例如硬件安全模块（HSM）。为了在潜在的应用程序受损的情况下支持密钥的安全远程管理，Crypto Stack 集成了密钥管理体系结构，其中密钥和相关数据以端到端的保护形式进行管理。密钥可以基于现有的供应密钥以受信任的方式引入系统，也可以通过本地密钥生成以不受信任的方式引入系统。

5. IAM

车内信息娱乐应用程序由于与外界互联网相连，因此被入侵的风险很高，像这类应用程序在设计时一定是不被允许使用车身控制相关服务的。例如信息娱乐系统被外界攻击，然后被远程控制去使用制动服务，为了保障安全，必须要阻止这种信息娱乐应用程序对制动服务访问的任何尝试。

日益增长的信息安全需求驱动了身份和访问管理（IAM）的概念，因为AUTOSAR Adaptive 平台需要和应用程序建立健壮和良好定义的信任关系。

IAM 为Adaptive 应用程序引入了特权分离，并针对攻击时的特权升级提供了保护。另外，在部署期间，IAM 能够使集成者提前验证Adaptive 应用程序要求的资源访问权限。IAM 为来自适应应用程序对服务接口，Adaptive 平台基础功能簇和相关模型资源的的请求提供了访问控制框架。

IAM 框架为AUTOSAR Adaptive 平台堆栈和Adaptive 应用程序的开发人员提供了一种机制，这种机制用于对每个应用程序的意图进行建模，根据访问请求提供访问控制决策，并执行控制访问。IAM 侧重于提供方法来限制Adaptive 应用程序对Adaptive 平台基础接口、服务接口与功能集群相关的明确资源接口( 例如KeySlots) 的访问。特别对系统资源( 如CPU 或RAM) 的强制配额不包括在IAM 中。

在运行期间，IAM 的进程对Adptive 应用程序是透明的，除非请求被拒绝并发出通知。远程Adaptive平台提供的服务实例请求由IAM 覆盖的，传入请求的PDPs 必须由Adaptive 应用程序实现。

该框架旨在运行期间执行对AUTOSAR 资源的访问控制。假设Adaptive 应用程序将在启动时进行身份验证，并且现有受保护的运行时环境确保Adaptive 应用程序被正确隔离，并且防止它们的特权升级( 例如绕过访问控制)。

考虑一个简单的应用场景，对于访问权限的描述，通常可以用一个访问权限矩阵来表示：

图4.1-7 访问权限矩阵

访问权限矩阵显示的是访问主体和访问客体之间的访问权限。

所谓访问主体，是指一个想要获得其他服务访问权限的对象，通常是指系统中的一个进程；

所谓访问客体，是指应当授权被访问的对象，通常它可以是指系统中的一个进程也可以是系统中的其他资源。

访问权限相关的信息需要以清单文件的形式部署在系统中。

对于这份清单文件，有两种组成形式：

第一种，针对每一个服务和应用，从访问权限主体的角度，列举每个访问主体的访问意图，也就是每个访问主体拥有的其他服务或应用程序（访问客体）的访问权限；

第二种，针对每一个服务和应用，从被访问的客体角度，列举出它支持被哪些其他服务和应用（访问主体）访问。对于访问主体，通常情况下它可访问的客体清单文件是不会随着时间推移而改变；但是对于一个访问客体，它的被访问清单会随着部署了新的应用而更新。

6. KeyM

在一个加密功能中，密钥和证书的功能比重很大。首先，密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。

许多加密算法需要使用到密钥，因此，就需要KeyM 模块来管理密钥，而KeyM 对于密钥的管理主要体现在更新和生成密钥方面。

而证书以加密或解密的形式保障了用户网络交流中的信息和数据的完整性和安全性。

KeyM 模块可以实现证书链的配置保存与验证，这使得网络中的信息和数据的安全性更高。

AUTOSAR KeyM 模块由两个子模块组成：

密钥子模块和证书子模块。

密钥子模块用于初始化、更新和维护的密钥材料；

证书子模块允许定义和配置证书，以便在生产时存储它们，并进一步用于多种用途。

图4.1-8 AUTOSAR layered view with KEYM

密钥子模块提供了一个API 和配置项，用于引入或更新预定义的加密密钥材料。它充当一个关键客户端，解释从一个关键服务器提供的数据，并创建相应的关键材料，这些密钥被提供给加密服务管理器。成功安装密钥材料后，应用程序就能够进行加密操作。

证书子模块提供了对证书进行操作的API 和配置。允许配置证书链，在配置中将证书的属性和关系设置好，上层应用通过 API 将证书数据传给KeyM 后，证书子模块将根据配置内容及HSM 按照标准结构解析的证书存储配置的位置（NVM、CSM 或 RAM）。

此外，证书子模块允许BSW 模块和SWC 在AUTOSAR 软件架构的中心点上更有效地使用证书进行操作。此类操作的示例包括验证完整的证书链或从运行时提供并验证的证书中检索元素。所需的加密操作（如验证证书签名）仍然由加密服务管理器中定义的相关加密作业执行。

与CP AUTOSAR 不同，AP AUTOSAR 平台的更新和配置、通信、持久性或诊断等服务，也需要加密服务作为其功能的一部分。因为架构差异的原因，AP AUTOSAR 平台会将需要用户自定义、差异性的功能在应用层去实现，所以应用程序可以定义所需的密钥插槽、加密提供程序和证书。当需要关键材料时，必须由自适应应用程序（例如OEM key manager）配置，平台应指定槽型机器的关键槽。为了管理关键材料，一个专用的自适应应用程序（密钥管理器）可以指定相同的密钥插槽（即相同的参数和插槽型机器）。

7. IdsM

车辆中的许多新功能建立在车载和后台服务之上，需要面对保护车辆免受网络攻击的挑战。为车辆的E/E 架构配置了安全机制，更新签名软件、安全启动和安全车载通信系统正在逐步建立。目前，IDS 作为一种额外的安全机制正在引起OEM 和供应商的关注。

入侵检测系统管理器（IdsM）是一个基础软件模块（适用于Classic AUTOSAR）或平台服务（适用于Adaptive AUTOSAR），用于收集和集中聚合可能由车辆软件、通信或电子系统受到恶意攻击而导致的安全事件。

软件组件IdsM 提供了接收板载安全事件SEv 通知的标准化接口。SEv 可以通过BSW (Basic Software Modules）和SW-C (application Software Components）实现的安全传感器上报。此外，可以用可选的上下文数据（如事件类型和可疑数据）报告SEv，这些数据对于在后端执行的安全取证来说是有用的信息。

除了收集，IdsM 还可以根据可配置的规则对SEv 进行筛选。

IdsM 将上报的SEv 过滤并转换为合格的机载安全事件（QSEv)，IdsM 进一步处理QSEv，用于存储或转发。根据总体安全概念的不同，QSEv可以通过安全事件内存（Sem）在本地持久化，也可以传播到已配置的接收器，或者两者兼有。可用的接收器是诊断事件管理器（Dem）模块和IDS 报告器模块（IdsR)，它们可以将QSEv 数据传递给后端中的安全操作中心（SOC)。

在车辆内的每个安全相关或机器中，IdsM 模块或服务的实例会收集和过滤安全事件（可选地包括附加数据），以便将它们存储在本地安全事件内存（Sem）和/ 或通过车辆网络将它们转发到中央入侵检测系统报告器（IdsR)。例如，该IdsR 可能位于远程信息处理单元内，使其能够通过蜂窝网络向OEM 的安全操作中心（SOC）发送安全报告和相关数据。然后，安全事件管理（SIEM）分析这些信息，并在必要时用于制定和决定适当的防御或缓解措施以应对攻击。

AUTOSAR 标准指出BSW 模块、CDD 和SWC 都可以充当安全传感器，安全传感器将安全事件（SEv）报告给IdsM，AUTOSAR 标准化可以由AUTOSAR BSW 报告的安全事件类型的子集。每个BSW 的规格里列出了自己产生的安全事件类型，这些事件由相应模块报告，业务组件也可以报告在AUTOSAR 中未标准化的自定义安全事件类型，可以使用安全性摘要（SecXT）指定由特定ECU 报告的安全性事件类型的属性。

AUTOSAR 入侵检测系统管理器是通用的、提供灵活的配置。它独立于底层通信系统，在上述限制和假设条件下可以应用于任何汽车领域。