4. Freshness Value - Secure Message Sender Side

Hello, I'm Blowing Nose.

 

In our last session, we delved into Sync Messages and the Latest Fv.

This time, let's explore Construct Fv and Previous Fv.

*Note: Construct Fv and Previous Fv have the same contents, but their purposes are slightly different.

 

Today, I'd like to explain using the Sender Side, which sends Secure Messages.

*Note: The Sender Side is relatively more accessible compared to the Receiver Side, which we'll delve into in detail later.

 

Firstly, Construct Fv and Previous Fv must be maintained individually for each Secure Message.

For instance, if an ECU wants to send three Secure Messages with IDs 0x100, 0x200, and 0x300, it needs to manage Fv like this:

.

 

 

Each Construct Fv and Previous Fv is responsible for managing specific contents.

According to Autosar's definitions:

Source : AUTOSAR_SWS_SecureOnboardCommunication

※ TripCntLength and ResetCntLength are identical to the values seen in the previously mentioned Sync Message

 

Let's now examine an example to understand each element of Fv.

 

First, we'll look at Construct Fv.

 

Autosar provides the following table for reference:

Source : AUTOSAR_SWS_SecureOnboardCommunication

 

 

In the table, it's important to note that 'Trip Counter | Reset Counter' does not represent the logical OR operation.

(Although it may seem trivial, I recall having some difficulties explaining this to another supplier who initially misunderstood this part as an OR operation.) 

 

This implies comparing both the Trip Counter and Reset Counter. In other words, the interpretation of this box would be as follows:

• Compare the Trip Counters between the Latest Fv and the Previous Fv.
• Compare the Reset Counters between the Latest Fv and the Previous Fv.

Why do you think such comparisons are necessary?

 

 

The "Latest Fv" received through the previously explained Sync Message follows the rule:

'Trip Counter increases by 1 with each new ignition cycle, and Reset Counter increases whenever a Sync Message is transmitted.'

Do you remember?

 

So!

If you haven't received a new sync message yet, the latest Trip Counter / Reset Counter remains the same as the Previous.

And, when you receive a new sync message, the Reset Counter increases, leading to a difference from the Previous and latest.

 

Now, we can interpret the box again as follows:

• If you haven't received a new Sync Message (Latest Fv) yet
• If you have received a new Sync Message (Latest Fv)

 

Okay, let's look in to below table again.

1) If you haven't received a new Sync Message yet, increase the Message Counter by 1 in the Previous Fv and store it in the Construct Fv. 

 

2) If you have received a new Sync Message, store the Latest Trip Counter and Reset Counter values received from the Sync, initialize the Message Counter, and store it after adding 1.
Store only the lower value from the new Reset Counter for the Reset Flag.

 

Here's how Construct Fv is created.

Once Construct Fv is created, it serves as the raw material for generating the C-MAC that will be included in the Secure Message when transmitted. After the C-MAC is generated and added to the Secure Message by the Sender, you can then store the Construct Fv value in the Previous Fv.

 

 

The Autosar Spec describes this process as follows:

 

Today, we explored the Freshness Value from the perspective of the Sender.

 

And now, I'm contemplating the best sequence to unravel the following for easier comprehension.

 

Firstly, here's the procedure I'm considering:

1. Sender Side: The process of transmitting Secure Messages using the diligently crafted Freshness Value
   (Introduction of Truncated Fv).
2. Receiver Side: Explanation of the received Secure Message's Recv Fv (Truncated Fv).
3. Receiver Side: Explanation of Construct Fv, Previous Fv, and an overview of the entire reception process.  

I'll be back with the next post to delve into these aspects.

 

Thank you.