코딩 푸는 남자

Hello, this is the Blowing Nose.

We're approaching the final stretch of our journey into SecOC.

Today, I'll be delving into what I consider the most complex aspect of the receiving end: Fv Construction.

In our previous session, we learned that to construct Fv, we need Recv Fv, Latest Fv, and Previous Fv. Before diving into the main topic, let's have a quick review:

• Recv Fv : Received from the Secure Message, it's a Truncated Value, not the Full Fv.
• Latest Fv : Received from the Sync Message, it contains Trip Counter and Reset Counter information.
• Previous Fv : It's the value from the previous MAC generation and verification, containing the Full Fv.

Now, let's analyze the table step by step.

1. Reset Flag Identical Case 

First, we compare the Reset Flags of Latest Fv and Recv Fv.

In other words, we check whether the information sent by the sender (Received) matches the information I received through the Sync Message (Latest).

Why do we perform this comparison?

You will understand why we do this when we explain how to handle cases where these two values are different, which we will cover later.

1.1. Trip/Reset Counter Identical Case 

Secondly, we check if the Trip Counter and Reset Counter in Latest Fv match the values of the Previous Trip Counter and Reset Counter.

What does it mean if they match?

It means that we haven't received a new Sync Message yet.

*Note: When we receive a new Sync Message, at least the Reset Counter should be different.

Since we haven't received a new Sync Message, we reuse the Previous values for the Trip Counter and Reset Counter in Construct Fv.

1.1.1. Message Counter No Carry Case

Now we compare the Message Counter in Recv Fv with the lower bits of the Message Counter in Previous Fv.

For example, if the Truncated Message Counter is 4 bits,

we compare "Recv Fv's Message Counter" vs. "Previous Fv's Message Counter & 0x0F."

If the Recv value is greater, then the Construct Message Counter is updated based on the Recv value.

Here's a simple example:

Input:

• Recv Fv = 0x3
• Previous Fv = 0x2

Result:

• Construct Fv Message Counter Upper = 0x00 (remains the same as previous)
• Construct Fv Message Counter Lower = 0x3 (updated to the Recv value)

1.1.2. Message Counter With Carry Case

If the values are as follows, how would you determine the outcome?

Input: 

• Recv Fv = 0x0
• Previous Fv = 0xF

In this case, it appears that Recv Fv has wrapped around after reaching the maximum value of a 4-bit counter and has started from 0 again.

Therefore, it should be handled as follows.

Result:

• Construct Fv Message Counter Upper = 0x01(updated to the previous + 1)
• Construct Fv Message Counter Lower = 0x0(updated to the Recv value )

1.2. Trip/Reset Counter Not same Case

What does it mean when the Latest Value differs from the Previous Value?

The fact that the Latest Value is different from the Previous Value means that a new Sync Message has been received. However, if the newly received Latest Value is smaller, it indicates that incorrect information has been received. Therefore, processing only occurs when the Latest Value is larger.

In this case, both the Trip Counter and Reset Counter are updated with the Latest Value, and the Message Counter is reset and updated with the Recv Value.

2. the Latest Reset Flag is 1 greater than the Received Reset Flag

Returning to the first condition, what does it mean when the Latest Reset Flag is 1 greater than the Received Reset Flag?

It means that the information in the Sync Message sent by the Secure Message sender is one step behind the Sync Message information I have.

In other words, the sender of the Secure Message calculated and sent the MAC based on the previous Sync Message, so when the receiving end constructs the Fv, it uses the previous information as a reference.

Therefore, all subsequent Latest Values will operate based on a value that is reduced by 1.

All other concepts remain the same as explained in the "1.Reset Flag Identical Case"

3. the Latest Reset Flag is 1 less than the Receive Reset Flag 

In this case, it means that the Sync Message information sent by the Secure Message sender is one step ahead of the Sync Message information I have, indicating that I haven't received the latest Sync Message yet.

The rest of the procedures remain the same.

Returning to the Autosar table for Reset Flag Comparison, we can see that Autosar SecOC allows a synchronization tolerance of up to ±2. Differences greater than this are likely considered to be indicative of an issue other than synchronization problems.

Today, we have completed the process of constructing the Freshness Value from the perspective of the receiving end.

Most of the content related to SecOC is now finished, and in the next session, we will briefly explore some additional topics before concluding.

Thank you.

안녕하세요, 코딩 푸는 남자 입니다.

SecOC에 대한 내용이 이제 거의 막바지로 가고 있습니다.

오늘은 제가 생각하기에, 가장 복잡한 수신측의 Fv Construction 작업에 대해 알아 보도록 하겠습니다.

우리는 지난시간에 Construct Fv를 하기 위해서는 Recv Fv, Latest Fv, Previous Fv가 필요 하다는 것을 배웠습니다.

본론으로 들어가기에 앞서 한번 복습해 보겠습니다.

• Recv Fv : Secure Message로 부터 전송되며, Full Fv가 아닌 Truncated Value임
• Latest Fv : Sync Message로 부터 전송되며, Trip Counter, Reset Counter 정보가 들어 있음
• Previous Fv : 이전에 MAC 생성 및 검증이 완료된 값으로, Full Fv를 가지고 있음

Autosar Spec에는 Construct Fv를 하기 위해 다음과 같은 표를 제공 하고 있습니다.

이제 차근차근 Table을 분석해 보도록 하겠습니다.

1. Reset Flag 동일 Case

우선 Latest Fv의 Reset Flag와 Recv Fv의 Reset Flag가 같은지 비교 합니다.

즉 Secure Message를 송신한 측에서 보낸 정보(Received)와 Sync Message를 통해 내가 받은 정보(Latest)가 같은지 판단합니다.

왜 이런 비교를 할까요?

이건 두 값이 다른 경우, 어떻게 처리하는지를 보시면 이해가 쉬울거라 생각 되며, 아래에서 설명 하도록 하겠습니다.

1.1. Trip/Reset Counter 동일 Case

두번째로, Latest의 Trip Counter / Reset Counter와 Previous Trip Counter / Reset Counter가 같은지 판단 합니다.

같다면 무슨 뜻일까요?

아직 새로운 Sync Message를 받지 않은 상태라는 의미 입니다.

*Note. 새로운 Sync Message를 받은 경우 최소한 Reset Counter는 달라야 합니다.

새로운 Sync Message를 받은 상태가 아니니, Construct Fv의 Trip Counter / Reset Counter는 Previous값을 재사용 합니다.

1.1.1. Message Counter No Carry Case

이제 Recv Fv의 Message Counter와 Previous Fv의 Message Counter를 비교 합니다.

다만 Recv Fv는 Truncated 값이기 때문에, Previous Fv의 Message Counter도 하위 부분만 비교 합니다.

예를 들어, Truncated Message Counter가 4bit라고 가정하면, 

"Recv Fv 의 Message Counter" vs "Previous Fv의 Message Counter & 0x0F"를 비교 하면 됩니다.

이때 Recv값이 더 큰 경우라면, Construct Message Counter는 Recv값을 기준으로 업데이트 됩니다.

이를 간단히 예제로 표현하면 다음과 같습니다.

입력

• Recv Fv = 0x3
• Previous Fv = 0x2

결과

• Construct Fv Message Counter Upper = 0x00(이전값 유지)
• Construct Fv Message Counter Lower = 0x3(Recv값으로 변경)

1.1.2. Message Counter With Carry Case

만약 다음과 같은 경우 어떻게 판단 할까요?

입력

• Recv Fv = 0x0
• Previous Fv = 0xF

새로 수신한 값이 이전에 처리되었던 값보다 작아진 경우네요.

이 경우는 Recv Fv가 4bit max값을 지나서 다시 0부터 시작 했다고 판단 합니다.

따라서 다음과 같이 처리 합니다.

결과

• Construct Fv Message Counter Upper = 0x01(이전값 + 1)
• Construct Fv Message Counter Lower = 0x0(Recv값으로 변경)

1.2. Trip/Reset Counter Not same Case

Latest Value가 Previous Value와 다르다는건 무엇을 의미 할까요? 

새로운 Sync Message를 받았다는걸 의미 합니다.

하지만 새롭게 받은 Latest가 작다면, 이는 잘못된 정보를 받은것이니, Latest가 큰 경우에만 처리 되며,

Trip Couter/Reset Counter 모두 Latest값으로 업데이트 하고, Message Counter는 초기화 후, Recv값으로 업데이트 합니다.

2. Latest Reset Flag가 Receive보다 1 큰 경우

다시 첫번째 Condition으로 돌아와서, Latest Reset Flag가 Recv Reset Flag보다 1 큰 경우는 무엇을 의미 할까요?

Secure Message를 송신하는측의 Sync Message 정보는 내가 가진 Sync Message정보보다 1단계 전 값임을 의미 합니다.

즉 Secure Message를 송신하는 측에서 아직 이전의 Sync Message로 MAC을 계산해서 송출 했으니,

수신 측에서도 Construct Fv를 만들때, 이전 정보를 토대로 만들기 위함 입니다.

따라서 그 이후의 모든 Latest Value는 1을 뺀 값 기준으로 동작 하게 됩니다.

그 외 나머지 컨셉은 모두 "1. Reset Flag 동일 Case" 에서 설명한 내용과 동일 합니다.

3. Latest Reset Flag가 Receive보다 1 작은 경우

이 경우는 반대로, 

Secure Message를 송신하는측의 Sync Message 정보가 내가 가진 Sync Message정보보다 1단계 빠른 값임을 의미 하고, 내가 아직 최신의 Sync Message를 받지 못한 상황을 나타 냅니다.

그 이외 나머지 절차는 모두 동일 합니다.

다시 Autosar의 Table로 돌아와서, Reset Flag Comparison을 살펴보면,

Autosar SecOC에서 이러한 Sync Message의 동기화 부분을 ± 2만큼만 허용하는 것을 알수 있습니다.

이보다 더 큰 폭의 차이는 동기화 문제가 아니라 실제 어떤 문제가 있다고 판단하는걸로 보입니다.

자, 이렇게 해서 Freshness Value의 Construction이 완료 되었습니다.

오늘은 수신측 입장에서 Construct Fv를 만드는 과정을 살펴 보았습니다.

이제 사실 SecOC에 대한 대부분의 내용은 끝이 났고, 다음 시간에는 추가적으로 알아야 할 부분들을 일부 살펴 보며 마무리 하도록 하겠습니다.

그럼 감사합니다.

Hello, this is Blowing Nose.

In this session, we would like to explain the process of receiving a Secure Message.

The receiving process may be somewhat complex and challenging, but it is considered the most crucial flow in SecOC.

Firstly, today will be an introductory session to understand the overall procedure conceptually, for receiving the Secure Message.

1. Latest Fv

We store the Trip Counter and Reset Counter received through the Sync Message in the Latest Fv.

Detailed information about this can be found in section 3: Sync Message, so please refer to it if necessary.

2023.12.09 - [CyberSecurity/SecureOnCAN[Eng]] - 3. Sync Message

2. Recv Fv

In the previous session, we learned that Truncated Fv is transmitted by the Secure Message Sender.

The receiving side then receives this value and stores it in the Recv Fv.

3. Construct Fv

In the previous session, we learned that Construct Fv and Previous Fv are managed for each Secure Message.

Let's assume that 0x100 is a Secure Message, and the Construct Fv for 0x100 is created through the following three components.

• Recv Fv
• Latest Fv
• Previous Fv for 0x100

4. 16 Byte MAC Value Generation

Using Secure Msg 2Byte ID(0x01, 0x00 in this example), Construct Fv for 0x100 and the Key value, a 16-byte MAC value is generated through the AES128 function.

5. MAC Verification

Comparing the generated MAC value with the Truncated MAC value included in the Secure Message to check if they match. Since the Truncated MAC contains only a portion of the MSB (Most Significant Bits) from the entire 16-byte MAC, the comparison is done with only the corresponding MSB portion. When the MAC values match, the data is considered received successfully and can be used.

6. Update Previous Fv

When the MAC values match and the data is used for reception (Rx), the Construct Fv value is updated as the Previous Fv.

Today, we conceptually explained the receiving process. In the next session, we will delve into the implementation details of each step.

Thank you.

안녕하세요, 코딩 푸는 남자 입니다.

이번 시간에는 Secure Message를 수신하는 과정을 설명해 보고자 합니다.

수신하는 과정은 다소 복잡하고, 어려울수 있지만, SecOC의 가장 중요한 흐름이라 생각 됩니다.

우선 오늘은 전체적인 절차를 이해하는 시간으로, 개념적으로 수신하는 과정을 다뤄 보도록 하겠습니다.

1. Latest Fv

Sync Message를 통해 전달 받은 Trip Counter, Reset Counter를 Latest Fv에 저장 합니다.

이 내용은 3. Sync Message 에 자세히 설명해 놓았으니, 필요하신 경우 참고 부탁 드리겠습니다.

2023.12.07 - [CyberSecurity/SecureOnCAN] - 3. Sync Message

2. Recv Fv

지난 시간에 Secure Message Sender에 의해 Truncated Fv가 송출 된다는 것을 배웠습니다.

2023.12.15 - [CyberSecurity/SecureOnCAN] - 5. Send Secure Message

수신측에서는 이 값을 받아, Recv Fv에 저장 합니다.

3. Construct Fv

지난 시간, 우리는 Secure Message별로 Construct Fv, Previous Fv가 관리 된다는 것을 배웠습니다.

0x100 Message가 Secure Message라고 가정하고, 0x100의 Construct Fv는 다음 3가지를 통해 만들어 지게 됩니다.

• Recv Fv
• Latest Fv
• Previous Fv for 0x100

4. 16 Byte MAC Value Generation

SecureMsg ID 2Byte(0x01, 0x00), Construct Fv for 0x100과 Key값을 이용하여, AES128 함수를 통해 16 Byte MAC값을 생성 합니다.

5. MAC Verification

생성한 MAC값과 Secure Message에 포함된 Truncated MAC값을 비교하여 일치하는지를 비교 합니다.

Truncated MAC은 전체 16 Byte MAC중 MSB 일부만 포함 되어 있기 때문에, 비교 역시 MSB 일부만을 비교 합니다.

이때 MAC값이 일치하면, 해당 Data는 정상적으로 수신하여 사용할수 있게 됩니다.

6. Previous Fv 업데이트

MAC값이 일치하여 Rx로 사용되는 경우, Construct Fv값을 Previous Fv로 업데이트 하게 됩니다.

오늘은 수신하는 과정을 개념적으로 설명해 보았습니다.

다음시간에는 각 과정에서 구현적인 부분을 더 디테일하게 다루어 보도록 하겠습니다.

감사합니다.

Hello every, this is blowing nose.

It's already the fifth time of SecOC.

Before we start, let's take a moment to look back at the last time.

We've learned about the following characteristics of Construct Fv:

• It's managed individually for each Secure Message,
• It's used as a raw material to create C-MAC,
• When a Secure Message (0x100 in this example) is sent, it's stored in the Previous Fv.

In this session, let's learn about the process of sending a 0x100 Secure Message.

1. Enter the Message ID 2byte(0x01, 0x00 in this exam) and Construct Fv as input data into the AES128-CMAC() function 2. Use the Key value received from the customer as input key into the AES128-CMAC() function. 3. This process returns a 16 Byte result, which becomes the MAC value. 4. Base on 16 Byte MAC, some of that MAC will send onto Secure Message according to SecOCAuthInfoTruncLength.

* Note: SecOCFreshnessValueTxLength, SecOCAuthInfoTruncLength are values received based on customer requirements.

Now, let's find out how a Message is sent using the following requirements as an example:

• Secure Message ID: 0x100
• Secure Message DLC: 8
• CRC: 1 Byte
• Normal Data: 2 Byte
• SecOCFreshnessValueTxLength: 2 Byte
• SecOCAuthInfoTruncLength: 3 Byte

The Fv and MAC included in the Secure Message can be summarized as follows:

• Add the LSB corresponding to SecOCFreshnessValueTxLength in Fv to the Secure Message
• Add the MSB corresponding to SecOCAuthInfoTruncLength in CMAC to the Secure Message

Because there is a limit to the length of the Message, not all of Fv and CMAC are included in the data. Instead, only a portion is truncated and transmitted.

Therefore, the Fv and CMAC included in the Secure Message are called Truncated Fv and Truncated CMAC.

The Autosar SecOC document expresses this as follows.

Source: AUTOSAR SECOC SWS

Now, the task of the Secure Message's Sender is completed.

Next time, we will visit the Receiver side, which receives such a Secure Message and verifies the MAC.

Thank you.

안녕하세요, 코딩 푸는 남자 입니다.

벌써 다섯번째 시간이네요.

들어가기 앞서, 잠시 지난 시간으로 돌아가 보겠습니다.

Consturct Fv의 다음과 같은 특성에 대해 배워 봤습니다.

• Secure Message별로 각각 관리 되고
• C-MAC을 생성하는 원료로 사용 되며
• Secure Message(본 예제에서는 0x100)가 전송되면, Previous Fv에 저장 된다.

이번시간에는 0x100 Secure Message가 전송되는 과정에 대해 알아 보도록 하겠습니다.

1. AES128-CMAC() 함수에, Message ID 2Byte(본 예제에서는 0x01, 0x00), Construct Fv를 data로 입력 2. AES128-CMAC() 함수에, 고객으로 부터 받은 Key값을 입력 3. 이 함수를 통해, 16 Byte MAC값을 리턴 받음. 4. 16 Byte MAC값중 SecOCAuthInfoTruncLength만큼만 Secure Message로 전송 됨.

* Note : SecOCFreshnessValueTxLength, SecOCAuthInfoTruncLength는 고객 요구사항으로 받는 값

자 이제 다음과 같은 요구사항을 예제로, 어떻게 Mesage가 전송 되는지 알아 보겠습니다.

• Secure Message ID : 0x100
• Secure Message DLC : 8
• CRC : 1 Byte
• Normal Data  : 2 Byte
• SecOCFreshnessValueTxLength : 2 Byte
• SecOCAuthInfoTruncLength : 3 Byte

Secure Message에 들어가는 Fv와 MAC을 살펴 보면 다음과 같습니다.

• Fv중 SecOCFreshnessValueTxLength 에 해당하는 LSB를 Secure Message에 추가
• CMAC중 SecOCAuthInfoTruncLength 에 해당하는 MSB를 Secure Message에 추가

Message는 길이에 한계가 있기 때문에, Fv, CMAC을 모두 데이터에 실어 보내지 않고, 그중 일부만을 Truncated하여 송출 하게 됩니다.

따라서 Secure Message에 포함하여 보내는 Fv와 CMAC을 Truncated Fv, Truncated CMAC이라고 합니다.

Autosar SecOC 문서에서는 이를 다음과 같이 표현 하고 있습니다.

출처 : AUTOSAR SECOC SWS

자, 이제 Secure Message의 Sender쪽의 업무가 끝이 났습니다.

다음 시간에는 이러한 Secure Message를 받아서 MAC을 검증하는 Receiver쪽으로 찾아 오도록 하겠습니다.

감사합니다.

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.

Hello, this is Blowing Nose.

Today, in the third session of Secure On CAN, let's delve into the details of the Sync Message.

In our previous session, we learned that the Fv Manager Master ECU sends the Sync Message, and ECUs involved in sending and receiving Secure Messages synchronize information based on the Sync Message.

Today, let's take some time to understand the composition, operating principles, and the relationship with Secure Message ECUs of the Sync Message based on the Autosar Spec.

Firstly, the Sync Message defined in Autosar is structured as follows:

* The Authenticator represents C-MAC

Here, TripCntLength, ResetCntLength, and SecOCAuthInfoTxLength are not fixed values.

They are configured based on customer requirements.

Now, let's assume you received the following customer requirements for the Sync Message:

• Total = 64 bits
• TripCntLength = 16 bits
• ResetCntLength = 24 bits
• SecOCAuthInfoTxLength = 24 bits
• Message ID = 0x20

Representing this in a Message Diagram would look like the following:

To understand each component, let's first refer to the AUTOSAR Specification, which provides the following explanations.

1. Trip Counter: Increments by 1 each time a new power on(ignition on) event occurs.

2. Reset Counter: Increments by 1 at each transmission cycle of the Sync Message.

3. C-MAC

C-MAC is generated when transmitting the Sync Message, and the receiving end verifies the C-MAC value to confirm the authenticity of the data.

To generate C-MAC, the 2byte ID(0x00, 0x20), Secure Data (Data0 ~ Dat4) and the Key received from the customer in advance are used. The AES128-CMAC algorithm is applied for this process.

The result is a 16-byte MAC value, and the upper 3 bytes of this value are added to Data 5 ~ Data 7 before transmission.

Now, let's briefly return to the characters involved.

The Sync Message transmitted from the Master ECU is validated by the Secure Message sender and receiver using C-MAC.

If the validation is successful, it is stored as the Latest Fv.

What would be the contents of the Latest Fv, then?

The TripCnt and ResetCnt received from the Sync Message, excluding the C-MAC part, are stored in the Latest Fv.

This is an important concept to remember for later.

Today's content will conclude here.

Thank you.