[SecOC] SecOC Freshness and MAC Truncation

SecOC Freshness and MAC Truncation

1. Functional

Authentication and integrity protection of sensitive data is necessary to protect the correct and safe functionality of vehicle systems. The SecOC module aims for resource-efficient and practicable authentication mechanisms of sensitive data on the level of PDUs (Protocol Data Units).

AUTOSAR SecOC defines secure communication on OSI layers above DataLink:

1.1 Specification of the security solution

The SecOC module as described in this document provides the 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.

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.

1.1.1 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 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.

1.1.2 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 the creation of the Authenticator.

1.1.3 Basic entities of the security solution

1.1.3.1 Authentic I-PDU and Secured I-PDU

The term Authentic I-PDU refers to an AUTOSAR I-PDU that requires protection against unauthorized manipulation and replay attacks.

The payload of a Secured I-PDU consists of the Authentic I-PDU and an Authenticator (e.g. Message Authentication Code). In other words, Secured I-PDU = Authentic I-PDU + CMAC value.

Truncating Authenticator

Depending on the authentication algorithm (parameter SecOCTxAuthServiceConfigRef or SecOCRxAuthServiceConfigRef ) 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.

A truncated Secured I-PDU is shown in the following example of the truncation of the Authenticator and the Freshness Values respecting the parameter SecOCFreshnessValueTxLength and SecOCAuthInfoTxLength.

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.

Note: For the resource constraint embedded use case with static participants, The SecOC specification proposes using Message Authentication Codes (MACs) as a basis for authentication (e.g. a CMAC [16] based on AES with an adequate key length).

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 SecOC specification 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 carefully further judge.

1.1.3.2 Data Covered by Authenticator

The data that the Authenticator is calculated on consists of the Data Identifier of the:

Secured I-PDU (parameter SecOCDataId)
Authentic I-PDU data
the Complete Freshness Value.

1.1.3.4 Freshness Values

Each Secured I-PDU is configured with at least one Freshness Value. The Freshness Value refers to a monotonic counter that is used to ensure the freshness of the Secured I-PDU.

The monotonic counter could be realized by:

or Freshness Counter
or Freshness Timestamp
or JasPar counter

Freshness Values are to be derived from a Freshness Manager.

SecOCFreshnessValueTxLength is configured to a smaller length than the actual freshness value, SecOC shall include only the least significant bits of the freshness value up to SecOCFreshnessValueTxLength within the secured I-PDU.
If the parameter SecOCFreshnessValueTxLength is configured to 0, the freshness value shall not be included in the secured I-PDU.
If SecOCUseAuthDataFreshness is set to TRUE, SecOC shall use a part of the Authentic I-PDU as freshness. In this case, SecOCAuthDataFreshnessStartPosition determines the start position in bits of the freshness inside the Authentic I-PDU and SecOCAuthDataFreshnessLen determines its length in bits.
In our use case, please set the SecOCUseAuthDataFreshness is FALSE.

The AES-CMAC Algorithm:

1.3.4 Authentication of I-PDUs

The creation of a Secured I-PDU and thus the authentication of an Authentic I-PDU consists of the following six steps:

Prepare Secured I-PDU
Construct Data for Authenticator
Generate Authenticator
Construct Secured I-PDU
Increment Freshness Counter
Broadcast Secured I-PDU

The SecOC module shall generate the Authenticator by passing DataToAuthenticator, the length of DataToAuthenticator into the Authentication Algorithm corresponding to SecOCTxAuthServiceConfigRef.

The SecOC module shall truncate the resulting Authenticator down to the number of bits specified by SecOCAuthInfoTxLength.

1.3.5 Verification of I-PDUs

The verification of a Secured I-PDU consists of the following six steps:

Parse Authentic I-PDU, Freshness Value and Authenticator
Get Freshness Value from Freshness Manager
Construct Data to Authentication
Verify Authentication Information
Send Confirmation to Freshness Manager
Pass Authentic I-PDU to upper layer

If SecOCTxSecuredPduCollection is used then SecOC shall not perform any verification until it has received both the Authentic I-PDU and Cryptographic I-PDU which make up the Secured I-PDU. Only after both have been received SecOC shall attempt to verify the resulting Secure I-PDU.

Although this document consequently uses the terms and concepts from symmetric cryptography. the SecOC module can be configured to use both, symmetric as well as asymmetric cryptographic algorithms.

The sender and receiver flow is shown in the following figure:

1.4 Rules of Freshness and MAC Truncation

The rule of MAC and freshness truncation refers to a technique used in security protocols to balance security and performance by limiting the amount of data that needs to be authenticated or encrypted.

The basic idea is to use a shorter MAC (message authentication code) and/or a truncated freshness value when transmitting a message, rather than authenticating and encrypting the entire message. By doing this, the amount of data that needs to be processed and transmitted is reduced, which can improve performance. Refer to spec 7.1.1.1 Authentic I-PDU and Secured I-PDU. However, this also reduces the level of security, as an attacker may have more opportunities to guess or manipulate the truncated or shortened data.

The exact rule of MAC and freshness truncation will vary depending on the specific security protocol being used and the security requirements of the system. In general, the rule will aim to find a balance between security and performance by limiting the amount of data that needs to be authenticated or encrypted, while still providing sufficient protection against attacks.

In AUTOX’s system, adopting a redundant system design approach, if a full-length MAC is used, it will exert certain pressure and impact on the overall system load. As a result, a MAC and freshness truncation approach are employed while maintaining security.

We refer to the Specification of Secure Onboard Communication Protocol:

The following are rules to consider for MAC and freshness truncating.

The calibration process is shown in the following diagram:

The length, Tlen, of the MAC is an important security parameter. The role of this parameter in resisting guessing attacks is outlined in the spec of the SecOC recommends referring to the NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication.

The verification process determines whether the purported MAC on a message is the valid output of the MAC generation process applied to the message. The output of the MAC verification determines the assurance that the receiver of the message obtains:

If the output is INVALID, then the message is definitely not authentic, i.e., it did not originate from a source that executed the generation process on the message to produce the purported MAC.
If the output is VALID, then the design of the mode provides assurance that the message is authentic and, hence, was not corrupted in transit; however, this assurance, as for any MAC algorithm, is not absolute.

In the second case, an attacker, i.e., a party without access to the key or to the MAC generation process, may have simply guessed the correct MAC for the message. In particular, if the attacker selects a MAC at random from the set of strings of length Tlen bits, then the probability is 1 in 2Tlen that the MAC will be valid. Consequently, larger values of Tlen provide greater protection against such an event. Of course, an attacker may attempt to systematically guess many different MACs for a message, or for different messages, thereby increasing the probability that one (or more) of them will be accepted as valid. For this reason, a system should limit the number of unsuccessful verification attempts for each key.

1.4.1 Message Span of the Key

The message span of a key is the total number of messages for which MACs are generated across all implementations of CMAC with that key. The message span of the key affects the security of the system against attacks that are based on the detection of a pair of distinct messages with the same MAC before its truncation[1]. Such a pair is called a collision[2] in this appendix. As with other block cipher-based MAC algorithms, an attacker may be able to exploit a collision to produce the valid MAC for a new message, the content of which may be large of the attacker's choosing. Such an event would be a fundamental breach of the expected authentication assurance.

In principle, collisions must exist because there are many more possible messages than MACs; in practice, however, collisions may not occur among the messages for which MACs are actually generated during the lifetime of the key. The probability that at least one collision will occur depends mostly on the message span of the key relative to the block size, b, of the underlying block cipher. For example, a collision is expected to exist among a set of 2b/2 arbitrary messages; in other words, 264 messages for the AES algorithm, and 232 messages for TDEA. This property was one of the motivations to develop the AES with a block size of 128 bits.

Perspective A:

For any system in which CMAC is implemented, the risk that an attacker can detect and exploit a collision shall be limited to a level that is appropriate to the value of the data. A simple and prudent method to achieve this goal is to establish and enforce an appropriate limit on the message span of any CMAC key, which in turn limits the probability that a collision will even occur. For general-purpose applications, the default recommendation is to limit the key to no more than 248 messages when the block size of the underlying block cipher is 128 bits, as with the AES algorithm, and 221 messages when the block size is 64 bits, as with TDEA. Within these limits, the probability that a collision will occur is expected to be less than one in a billion for the AES algorithm, and less than one in a million for TDEA.

Perspective B:

For applications where higher confidence in security is required, the message span of a key may be measured in terms of the total number of message blocks. The recommendation, in this case, is to limit the key to no more than 248 message blocks (222 Gbytes) when the block size is 128 bits, and 221 message blocks (16 Mbytes) when the block size is 64 bits. Within these limits, the probability that a collision will occur is proved to be less than one in a billion for the AES algorithm, and less than one in a million for TDEA, assuming that the underlying block cipher has no weakness, as modeled in Ref. [3]. In some cases, a limit on the message span of a key may be established and enforced within a key management infrastructure by an appropriate constraint on the time span during which the key remains in effect, i.e., its crypto period.

Ref:

[1] FIPS Publication 197, The Advanced Encryption Standard (AES), U.S. DoC/NIST, November 26, 2001.
[2] FIPS Publication 198, The Keyed-Hash Message Authentication Code, U.S. DoC/NIST, March 6, 2002.
[3] T. Iwata, K. Kurosawa, OMAC: One-Key CBC MAC, in Fast Software Encryption, 10th International Workshop, FSE 2003, Lecture Notes in Computer Science, Vol. 2887, Thomas Johansson, ed., Springer-Verlag (2003), p.p. 129–153.

1.4.2 Selection of the MAC Length

Larger values of Tlen bits provide greater assurance against guessing attacks. The performance tradeoff is that larger values of Tlen require more bandwidth/storage for the MAC.

The NIST guidance can be quantified in terms of the following two bounds:

The highest acceptable probability for an inauthentic message to pass the verification process
A limit on the number of times that the output is the error message INVALID before the key is retired, across all implementations of the verification process for the key.

Given estimates of these quantities, denoted Risk and MaxInvalids, respectively, Tlen should satisfy the following inequality:

In our use case, the MAC verification process(es) within a system will not output INVALID for more than 1024 messages before the key is retired(i.e., MaxInvalids = 2^10), and the users can tolerate about a one in a million chance that the system will accept an inauthentic message (i.e., Risk = 2^-20).

As the result, the Tlen = lg(25÷ 2-20) = 30

1.4.3 Freshness Truncation

The successful verification of a MAC for a message gives assurance that the source of the message executed the MAC generation algorithm to create the MAC; however, the party that presented the message and MAC for verification may not be the original source of the message. Therefore, the CMAC algorithm does not inherently prevent an attacker from intercepting a legitimate message and its MAC and “replaying” them for verification at a later time, for example, in an attempt to impersonate a party that has access to the key. In some protocols, an attacker may even be able to present to a verifier a message-MAC pair that the verifier itself generated earlier in the protocol.

The controlling protocol or application may protect against such an event by incorporating certain identifying information into the initial bits of every message. Examples of such information include a sequential message number, a timestamp, or a nonce. Upon successful verification of the message, this information may provide a means for the detection of replayed messages, out-of-sequence messages, or missing messages.

The freshness value can be truncated to include the length of one session. The rule is following Refer to https://www.autosar.org/fileadmin/standards/R21-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf 5.4 Security Profiles.

For the short freshness, please enable the JasPar counter in the system.

For the monotonic counter, please use the eight least significant bits of the freshness value as a truncated freshness value.

1.4.4 Security Profiles

The specification of the module Secure Onboard Communication allows different configurations for which cryptographic algorithms and modes to use for the MAC calculation and how the truncation of the MAC and freshness value (if applicable) shall be done. The security profiles provide a consistent set of values for a subset of configuration parameters that are relevant to the configuration of Secure Onboard Communication. Refer to https://www.autosar.org/fileadmin/standards/R21-11/FO/AUTOSAR_PRS_SecOcProtocol.pdf 5.4 Security Profiles.

SecOC Profile 1 (or 24Bit-CMAC-8Bit-FV) Recommended

[PRS_SecOc_00610] Using the CMAC algorithm based on AES-128 according to NIST SP 800-38B to calculate the MAC, use the eight least significant bit of the freshness value as truncated freshness value and use the 24 most significant bits of the MAC as truncated MAC.

SecOC Profile 3 (or JASPAR) Recommended

[PRS_SecOc_00630] This profile depicts one configuration and usage of the JasPar counter base FV with the Master-Slave Synchronization method. It uses the CMAC algorithm based on AES-128 according to NIST SP 800-38B Appendix-A to calculate the MAC. Use the 4 least significant bits of the freshness value as truncated freshness value and use the 28 most significant bits of the MAC as truncated MAC. Freshness Value provided to SecOC shall be constructed as described in the [UC_SecOC_00202]. The profile shall be used for CAN.

User defining

Further reduction in MAC length requires renegotiation of the key according to the NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication.

WIP

2. Key Management

There are a large number of keys that need to be managed here. In the following example,

1 Gateway
3 Domains
11 ECUs
Multiple local domain applications
3 cross-domain / E2E applications
Secured by keys: ECU 2 needs many keys

2.1 Key Generation

Random keys generated with approved Random Bit Generators (RBG)
Using approved cryptographic modules (ECU hardware)
Country-specific compliance standards
FIPS 1402 compliancy National Institute of Standards and Technology (NIST) standards.
AUTOSAR CryIF module must be implemented to international standards

2.2 Key Distribution

Primary ECU as Key Management Server (KMS)
responsible for generation and distribution of Secret Keys
Distribution via PDUs, network agnostic.
Distribution in the production phase (secure premises).
Default key installed in ECUs on initialization
After first distribution, key updates require previous key...
Key data encrypted with older key
Keys installed and activated on reception from KMS

2.3 Key Storage and Access

Keys are stored in and accessed from Secure On-Chip Hardware
Different Implementation for different hardware:
- Arm TrustZone
- or on-chip HSM
No access to secured flash (where keys are stored) via debug port
Accessed via AUTOSAR SecOC Module -> CSM Module -> CryIF Module (software layer)
CryIF Module -> MCAL (hardware layer)
No use of Software Crypto, unsecured

WIP

FAQ

Question 1: Can be the Big Endian changed to Little Endian?

Question 2: Comparing the auth bandwidth overhead (Classical CAN)

Question 3: 在使用SecOC的时候，如果是广播的CAN信息，对于不想接收广播信息的ECU如何处理这个CAN信息？

具体来说，SecOC协议使用了消息认证码（MAC）算法对CAN数据进行认证，以确保数据的完整性、认证性和抗重放攻击性，而没有进行加密。在发送方ECU发送CAN数据时，需要在CAN帧中添加Secured I-PDU字段，该字段包含了MAC值和相关的安全参数，用于在接收方ECU进行认证。在接收方ECU收到CAN数据时，会先验证Secured I-PDU字段中的MAC值，如果验证通过，则表示CAN数据是可信的，否则则会拒绝该CAN数据。

需要注意的是，SecOC协议并没有对CAN数据进行加密，而是仅对CAN数据进行了认证。因此，在使用SecOC协议时，CAN数据仍然是以明文的形式在CAN总线上传输的。因此，SecOC并不会影响CAN总线的广播特性。广播消息仍然会被发送到所有连接到总线上的ECU。同时，在使用SecOC时，需要确保所有连接到总线上的ECU都支持SecOC协议，否则可能会导致通信错误或安全漏洞。