AUTOSAR_SWS_SecureOnboardCommunication（7）-功能规格 -1

最新推荐文章于 2024-02-23 15:17:46 发布

翼曦

最新推荐文章于 2024-02-23 15:17:46 发布

阅读量590

点赞数

文章标签：汽车

本文链接：https://blog.csdn.net/zhanglei_admin/article/details/126107561

版权

7 Functional specification

Authentication and integrity protection of sensitive data is necessary to protect

correct and safe functionality of the vehicle systems – this ensures that received data

comes from the right ECU and has the correct value.

7 功能规格

敏感数据的身份验证和完整性保护 对于保护车辆系统的正确和安全功能是必要的 —— 这可以确保接收

到的数据来自正确的 ECU 并具有正确的值。

The SecOC module aims for resource-efficient and practicable authentication

mechanisms of sensitive data on the level of PDUs. The approach proposed in this

specification generally supports the use of symmetric and asymmetric methods for

authenticity and integrity protection. Both methods roughly aim at the same goal and

show major similarities in the concept, but there are also some differences due to

differing technical properties of the underlying primitives. In addition, the commonly

used terms for Authenticator are different. In general, the term Message

Authentication Code (MAC) is used for symmetric approaches while the term

signature or digital signature refers to asymmetric approaches having different

properties and constraints.

SecOC 模块旨在为 PDU 级别的敏感数据提供资源高效且实用的认证机制。本规范中提出的方法通常支

持使用对称和非对称方法来保护真实性和完整性。两种方法大致针对相同的目标，并在概念上显示出

主要的相似之处，但由于底层原语的不同技术特性，也存在一些差异。此外， Authenticator 的常用术

语也不同。通常，消息认证码 (MAC) 一词用于对称方法，而术语签名或数字签名是指具有不同属性和

约束的非对称方法。

In order to ease presentation and improve legibility, the following approach is taken:

The subsequent section describes the technical approach using symmetric

mechanisms in some detail. Here also the common terms for symmetric primitives

are used. The adaptations that need to be done in case of an asymmetric approach

are separately given in section 7.1.4.

为了便于演示和提高易读性，采用以下方法：下一节将详细描述使用对称机制的技术方法。这里也使

用了对称原语的常用术语。在非对称方法的情况下需要进行的调整在第 7.1.4 节中单独给出。

7.1 Specification of the security solution

The SecOC module as described in this document provides functionality necessary to verify the authenticity and freshness of PDU based communication between ECUs

within the vehicle architecture. The approach requires both the sending ECU and the

receiving ECU to implement a SecOC module. Both SecOC modules are integrated

providing the upper and lower layer PduR APIs on the sender and receiver side. The

SecOC modules on both sides generally interact with the PduR module.

7.1 安全解决方案规范

本文档中描述的 SecOC 模块提供了验证车辆架构内 ECU 之间基于 PDU 的通信的真实性和新鲜度所

必需的功能。该方法需要发送 ECU 和接收 ECU 来实现 SecOC 模块。两个 SecOC 模块都集成在一

起，在发送方和接收方提供上层和下层 PduR API 。两侧的 SecOC 模块通常与 PduR 模块交互。

To provide message freshness, the SecOC module on the sending and receiving

side get freshness from an external Freshness Manager for each uniquely identifiable

Secured I-PDU, i.e. for each secured communication link.

为了提供消息新鲜度，发送方和接收方的 SecOC 模块从外部新鲜度管理器获取每个唯一可识别的安全

I-PDU 的新鲜度，即每个安全通信链路。

On the sender side, the SecOC module creates a Secured I-PDU by adding

authentication information to the outgoing Authentic I-PDU. The authentication

information comprises of an Authenticator (e.g. Message Authentication Code) and

optionally a Freshness Value. Regardless if the Freshness Value is or is not included

in the Secure I-PDU payload, the Freshness Value is considered during generation of

the Authenticator. When using a Freshness Counter instead of a Timestamp, the

Freshness Counter should be incremented by the Freshness Manager prior to

providing the authentication information to the receiver side.

在发送方， SecOC 模块通过向传出的 Authentic I-PDU 添加认证信息来创建 Secured I-PDU 。认证信

息包括认证器（例如消息认证码）和可选的新鲜值。无论新鲜度值是否包含在安全 I-PDU 有效载荷

中，在生成验证器期间都会考虑新鲜度值。当使用新鲜度计数器而不是时间戳时，新鲜度计数器应由

新鲜度管理器在向接收方提供身份验证信息之前递增。

On the receiver side, the SecOC module checks the freshness and authenticity of the

Authentic I-PDU by verifying the authentication information that has been appended

by the sending side SecOC module. To verify the authenticity and freshness of an

Authentic I-PDU, the Secured I-PDU provided to the receiving side SecOC should be

the same Secured I-PDU provided by the sending side SecOC and the receiving side

SecOC should have knowledge of the Freshness Value used by the sending side

SecOC during creation of the Authenticator. 在接收方， SecOC 模块通过验证发送方 SecOC 模块附加的认证信息来检查 Authentic I-PDU 的新鲜度和

真实性。为了验证 Authentic I-PDU 的真实性和新鲜度，提供给接收方 SecOC 的 Secured I-PDU 应该

与发送方 SecOC 提供的 Secured I-PDU 相同，并且接收方 SecOC 应该知道发送方 SecOC 在创建

Authenticator 期间使用的Freshness Value。

The main purpose of the SecOC module is the realization of the security functionality

described throughout this specification.

SecOC 模块的主要目的是实现本规范中描述的安全功能。

7.1.1 Basic entities of the security solution

7.1.1 安全解决方案的基本实体

7.1.1.1 Authentic I-PDU and Secured I-PDU

7.1.1.1 真实 I-PDU 和安全 I-PDU

The term Authentic I-PDU refers to an AUTOSAR I-PDU that requires protection

against unauthorized manipulation and replay attacks.

Authentic I-PDU 一词是指需要防止未经授权的操纵和重放攻击的 AUTOSAR I-PDU 。

The payload of a Secured I-PDU consists of the Authentic I-PDU and an

Authenticator (e.g. Message Authentication Code). The payload of a Secured I-PDU

may optionally include the Freshness Value used to create the Authenticator (e.g.

MAC). The order in which the contents are structured in the Secured I-PDU is

compliant with Figure 3 .

Secured I-PDU 的有效载荷由 Authentic I-PDU 和 Authenticator （例如消息验证码）组成。安全 I-PDU

的有效载荷可以可选地包括用于创建认证器的新鲜度值（例如 MAC ）。 Secured I-PDU 中的内容结构

顺序符合图 3 。

The length of the Authentic I-PDU, the Freshness Value and the Authenticator within

a Secured I-PDU may vary from one uniquely indefinable Secured I-PDU to another.

Authentic I-PDU、Freshness Value 和 Authenticator 在 Secured I-PDU 中的长度可能因一个唯一

无法定义的 Secured I-PDU 而异。

The Authenticator (e.g. MAC) refers to a unique authentication data string generated

using a Key, Data Identifier of the Secured I-PDU, Authentic Payload, and Freshness

Value. The Authenticator provides a high level of confidence that the data in an

Authentic I-PDU is generated by a legitimate source and is provided to the receiving

ECU at the time in which it is intended for.

Authenticator （例如 MAC ）是指使用密钥、安全 I-PDU 的数据标识符、真实有效负载和新鲜度值生成

的唯一认证数据串。 Authenticator 提供了高度的信心，即 Authentic I-PDU 中的数据是由合法来源生

成的，并在预期的时间提供给接收 ECU 。

Depending on the authentication algorithm(parameter

SecOCTxAuthServiceConfigRef or SecOCRxAuthServiceConfigRef ) used to

generate the Authenticator, it may be possible to truncate the resulting Authenticator

(e.g. in case of a MAC) generated by the authentication algorithm. Truncation may be

desired when the message payload is limited in length and does not have sufficient

space to include the full Authenticator.

根据用于生成 Authenticator 的身份验证算法（参数 SecOCTxAuthServiceConfigRef 或

SecOCRxAuthServiceConfigRef），可能会截断由身份验证算法生成的生成的 Authenticator（例

如，在 MAC 的情况下）。当消息有效负载的长度有限并且没有足够的空间来包含完整的

Authenticator 时，可能需要截断。

The Authenticator length contained in a Secured I-PDU(parameter

SecOCAuthInfoTruncLength) is specific to a uniquely identifiable Secured I-PDU.

This allows provision of flexibility across the system (i.e. two independent unique

Secured I-PDUs may have different Authenticator lengths included in the payload of

the Secure I-PDU) by providing fine grain configuration of the MAC truncation length

for each Secured I-PDU. 包含在 Secured I-PDU 中的 Authenticator 长度（参数 SecOCAuthInfoTruncLength ）特定于唯一可识别

的安全 I-PDU 。通过为每个安全 I-PDU 提供 MAC 截断长度的细粒度配置，这允许在整个系统中提供

灵活性（即，两个独立的唯一安全 I-PDU 可能具有不同的认证器长度，包括在安全 I-PDU 的有效负载

中）。

If truncation is possible, the Authenticator should only be truncated down to the most

significant bits of the resulting Authenticator generated by the authentication

algorithm.Figure 5 shows an example of the truncation of the Authenticator and the

Freshness Values respecting the parameter SecOCFreshnessValueTruncLength and

SecOCAuthInfoTruncLength.

如果截断是可能的，则应该只将 Authenticator 截断到由身份验证算法生成的结果 Authenticator 的最

高有效位。图 5 显示了 Authenticator 的截断示例和有关参数 SecOCFreshnessValueTruncLength 和

SecOCAuthInfoTruncLength 的新鲜度值。

Note: For the resource constraint embedded use case with static participants, we propose using

Message Authentication Codes (MACs) as a basis for authentication (e.g. a CMAC [16] based on AES

[19] with an adequate key length).

注意：对于具有静态参与者的资源约束嵌入式用例，我们建议使用消息身份验证代码（ MAC ）作为身份验证的基础（例如，

基于 AES [19] 的 CMAC [16] 具有足够的密钥长度）。

Note: In case a MAC is used, it is possible to transmit and compare only parts of the MAC. This is

known as MAC truncation. However, this results in a lower security level at least for forgery of single

MACs. While we propose to always use a key length of at least 128 bit, a MAC truncation can be

beneficial. Of course, the actual length of the MAC for each use case has to be chosen carefully. For

some guidance, we refer to appendix A of [16]. In general, MAC sizes of 64 bit and above are

considered to provide sufficient protection against guessing attacks by NIST. Depending on the use case, different MAC sizes can be appropriate, but this requires careful judgment by a security expert.

注意：如果使用 MAC ，则可以仅传输和比较 MAC 的一部分。这称为 MAC 截断。然而，这至少对于伪造单个 MAC 会导致较

低的安全级别。虽然我们建议始终使用至少 128 位的密钥长度，但 MAC 截断可能是有益的。当然，必须仔细选择每个用例的

MAC 的实际长度。对于一些指导，我们参考 [16] 的附录 A 。一般来说， 64 位及以上的 MAC 大小被认为可以提供足够的保护来

防止 NIST 的猜测攻击。根据用例，不同的 MAC 大小可能是合适的，但这需要安全专家仔细判断。

[SWS_SecOC_00011] ⌈

All SecOC data(i.e. Freshness Value, Authenticator, Data Identifier) that is directly or

indirectly transmitted to the other side of a communication link shall be encoded in

Big Endian byte order so that each SecOC module interprets the data in the same

way.

⌋ (SRS_SecOC_00006)

[SWS_SecOC_00011] ⌈

所有直接或间接传输到通信链路另一端的 SecOC 数据（即 Freshness Value 、 Authenticator 、 Data