코딩 푸는 남자

Hello, this is the Blowing Nose.

Today, in our second session on SecOC, let's introduce the key characters needed to understand the principles of SecOC.

It might seem a bit complex, but these concepts are crucial for grasping SecOC, so make sure to understand them thoroughly.

(Let's do this!)

* SecOC Key Characters

1. Freshness Value Manager Master ECU
In SecOC, which authenticates based on C-MAC, the concept of Freshness Value is introduced.There is a Master ECU that controls the Freshness Value for the entire node
(Detailed information will be provided in the future.)
There is a Master ECU that controls the Freshness Value for the entire node.

1.1. Sync Message
This is a message sent to synchronize the Freshness Value of the Master ECU. The Sync Message contains the most recent Freshness Value. Every node that receives this Sync Message updates its information accordingly for synchronization. 

2. Secure Message Sender ECU
This is the ECU responsible for sending secure messages.
Therefore, it holds the secure message to be transmitted.

3. Secure Message Receiver ECU
This is the ECU that intends to receive secure messages.
When a secure message is transmitted by the sender, this ECU plays the role of receiving it.

4. Freshness Value (Fv)
The Freshness Value is a crucial and somewhat complex concept in SecOC.
Based on my understanding from Autosar SecOC SWS, there seem to be around four necessary concepts of Fv.
Due to the complexity of the concepts, let's start by explaining the Fv concept from the perspective of the Receiver ECU.

4.1. Latest Fv

The Sync Message sent periodically by Fv Master contains information known as the Trip Counter and Reset Counter.

• Trip Counter : Increase by 1 every new ignition cycle
• Reset Counter : Increase by 1 every a sync message is sent base on it's own period

Upon receiving the Sync Message, the remaining ECUs store this information in the Latest Fv.

4.2. Recv Fv

The Secure Message includes information called Truncated Fv, which is a subset of the Freshness Value sent by the Sender.
The receiving side stores this value in the Recv Fv upon reception.

4.3. Construct Fv

Since Recv Fv is a truncated value, the process of generating the Full Fv based on this value is required. This is referred to as Construction, and during Construction, information from Recv Fv, Previous Fv, and Latest Fv is all necessary. The resulting value from this process is temporarily stored in Construct Fv.

4.4. Previous Fv

Using ConstructFv, the received Secure Message is verified (C-MAC Verification). If the verification is successful, ConstructFv is then stored in Previous Fv.

Today, we briefly introduced the characters in SecOC. How was it?

If there are still confusing parts, following the upcoming posts should eventually make things clearer, and you'll likely find it wasn't as complicated as it seemed.

 

 

All right, I'll step back for today and be back soon~.

 

 

 

Hello, this is the Blowing Nose.

In the field, it's not uncommon to receive unexpected requirements and have to implement them.

Recently, we had a customer requesting Secure On CAN, but our current Autosar Solution didn't support this stack.

In a rush, I had to read through the Autosar Spec and implement it through what's commonly known as manual coding.

While coding for a new spec can be a daunting task, it's also a double-edged sword where you can learn a lot once it's done.

From now on, I plan to share my experiences and insights into Secure On CAN that I learned through hands-on coding.

Today, before diving into Secure On CAN, I want to provide some background knowledge.

1. CRC

Before delving into Secure CAN, let's briefly understand CRC.

Have you ever heard of the CRC field in a CAN Message?

To illustrate, let's assume Bob sends the following to CAN Message ID 0x100.

The total length of the data is 7 bytes, and among them, Data0 serves as the CRC field. It's filled with the result of CRC calculation based on Data1 to Data6.

To aid understanding, let's assume the calculated result is 0xAF.

Now, let's imagine that from a distant place, Alice receives the following data.

Alice, using the received Data0 (Recv CRC) and received Data1 to Data6, compares it with the calculated CRC (Calculate CRC).

If these two values match, she can conclude that all the data has been received without any corruption.

However, let's assume, unfortunately, that there has been tampering with Data3.

In that case, Bob's calculated Data0 (0xAF) and Alice's calculated CRC through Data1 to Data6 will not match, right?

In summary, it can be stated as follows:

• If Recv CRC == Calculate CRC, it is considered that the data has been received without tampering.
• If Recv CRC != Calculate CRC, it is considered that tampering has occurred somewhere, although the exact location of the tampered data is unknown.

Therefore, using CRC for data integrity verification is referred to as an Integrity Check.

Up to this point, it was sufficient. Usually, the CRC algorithm evolved by adding more complexity.

However, with the increasing importance of cybersecurity, one important question has arisen.

Let's go back to the situation where Alice received the data without tampering.

Alice is happily receiving data from Bob without tampering, but someone nearby asks a question.

Up until now, we've only focused on whether the data has been tampered with, neglecting to consider if the untampered data is really from Bob or if it's fake data from a sophisticated attacker.

One day, I received a message from my son's phone number.

"Dad, I can't make a call, and it's urgent. Please send me $100k quickly!"

The number is clearly from our son's account, but since I'm not a fool, I respond like this:

"Son... life has its own order. If you are my son, I must have experienced dating at least once, but..."

2. C-MAC's Introduction

SecOC emerged against this backdrop.

With the introduction of SecOC technology, an additional field called the C-MAC Field is included in the Data Field, excluding the CRC.

Here, MAC stands for Message Authentication Code, which signifies the property of guaranteeing authenticity.

Now, with SecOC, Bob adds a kind of signature to the Data using another piece of data to indicate that the sender of the data is the genuine Bob himself.

Upon receiving the data, Alice examines this signature closely to determine whether it was sent by the real Bob or if it's a ploy by a skilled scammer.

Ah, of course, we must continue with the CRC for Integrity Check.

Continuing...

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

우리는 지난 시간에 Sync Message와 Latest Fv에 대해 알아 보았습니다.

이번 시간에는 Construct Fv, Previous Fv 에 대해 알아 보는 시간을 갖도록 하겠습니다.

*Note : Contruct Fv와 Previous Fv는 contents는 동일하고, 그 목적이 조금 다르다고 이해 하시면 됩니다.

오늘은 Secure Message를 송신하는 Sender Side를 가지고 설명을 해 보고자 합니다.

* Note : Sender Side가 Receiver Side에 비해 비교적 쉽게 접근 가능 하고, Receiver Side는 향후에 자세히 알아볼 예정 입니다.

우선 Construct Fv, Previous Fv는 Secure Message 마다 개별적으로 가지고 있어야 합니다.

만약 0x100, 0x200, 0x300 3개의 Secure Message를 전송하고자 하는 ECU라면, 아래와 같은 Fv를 관리 해야 하겠네요.

각각의 Contruct Fv와 Previous Fv는 무슨 내용을 관리 하고 있을까요?

Autosar에서는 다음과 같이 정의 하고 있습니다.

출처 : AUTOSAR_SWS_SecureOnboardCommunication

※ TripCntLength, ResetCntLength는 앞서 본 Sync Message의 값과 동일함

그럼 이제 하나의 예제를 살펴 보면서 Fv의 각 요소 요소를 이해해 보도록 하겠습니다.

우선 첫번째로 Construct Fv 입니다.

Autosar에서는 다음과 같은 Table을 제공하고 있습니다.

출처 : AUTOSAR_SWS_SecureOnboardCommunication

자 우선 "Trip Counter | Reset Counter"는 OR의 의미가 아닙니다.

(별거 아닌거 같지만, 처음에 이부분을 OR로 이해하는 타 Suppiler와 이야기 하는데 상당히 애를 먹었던 기억이 납니다.)

이 의미는 Trip Counter와 Reset Counter를 모두 비교하라는 의미 입니다.

즉 해당 Box는 다음과 같이 해석이 됩니다.

• Latest Fv의 Trip Counter와 Previous Fv의 Trip Counter를 비교
• Latest Fv의 Reset Counter와 Previous Fv의 Reset Counter를 비교

왜 이렇게 비교를 하게 했을까요?

앞서 설명드린 Sync Message를 통해서 받는 Latest Fv는

"Trip Counter는 새로운 IGN Cycle마다 1씩 증가하고, Reset Counter는 Sync Message가 송출될때마다 증가 한다"

기억하고 계신가요?

그.렇.다.면!

아직 새로운 Latest를 받지 않은 경우, Trip Counter / Reset Counter가 Previous와 동일 하고,

그럼 새로운 Latest를 받은 경우, Reset Counter가 증가된 값을 받게 되니, Previous값과 다르게 됩니다.

그럼 이 Box는 다시 다음과 같이 해석이 가능 합니다.

• 아직 새로운 Sync Message(Latest Fv)를 받지 못한 경우
• 새로운 Sync Message(Latest Fv)를 받은 경우

자 그럼 아래 내용을 다시 다음과 같이 해석 할수 있습니다.

1) 아직 새로운 Sync Message를 받지 못한 경우, Previous Fv에서 Message Counter를 1증가 시키고, Contrcut Fv에 저장해라.

2) 새로운 Sync Message를 받은 경우, Sync에서 받은 Latest Trip Counter와 Reset Counter값을 가지고 저장하고,

Message Counter는 초기화 한 이후 1 더해서 저장해라.

Reset Flg는 새로운 Reset Counter값에서 하위값만 저장해라.

자 이렇게 Construct Fv가 만들어 졌습니다.

그리고, 이렇게 만들어진 Construct Fv는 Secure Message가 전송될때 포함될 C-MAC을 생성하는 원료로 쓰입니다.

C-MAC이 생성되고, Secure Message에 해당 C-MAC을 추가하여 Sender가 송출 되고 나면,

이제 Construct Fv값을 Previous Fv에 저장 하면 됩니다.

Autosar Spec에서는 이부분을 다음과 같이 설명하고 있습니다.

오늘은 Sender 입장에서의 Freshness Value에 대해 알아 보았습니다.

이제 다음을 어떤 순서로 풀어 나가야 쉽게 접근될지 나름 고심 중 입니다.

우선 제가 생각하고 있는 절차는 다음과 같습니다.

1) 송신측 : 열심히 만든 Freshness Value를 통해 Secure Message를 송신하는 과정(Truncated Fv의 등장)

2) 수신측 : 수신 받은 Secure Message의 Recv Fv(Truncated Fv) 설명

3) 수신측 : Construct Fv, Previous Fv 설명 및 전체 수신 과정 설명 

그럼 다음 posting에서 다시 뵙겠습니다.

감사합니다.

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

오늘은 Secure On CAN 세번째 시간으로 Sync Message에 대해서 자세히 알아 보도록 하겠습니다.

지난 시간에 우리는 Fv Manager Master ECU를 통해 Sync Message가 전송 되고, Secure Message를 송/수신 하는 ECU들은 Sync Message를 기반하여 어떠한 정보를 동기화 한다고 배웠습니다.

오늘은 Autosar Spec을 기반하여, Sync Message의 구성, 동작 원리, Secure Message ECU들과의 관계에 대해서 알아 보는 시간을 가져 보도록 하겠습니다.

우선 Autosar에서 정의하는 Sync Message는 다음과 같이 구성 되어 있습니다.

※ Authenticator는 C-MAC을 나타냄.

여기서 TripCntLength, ResetCntLength, SecOCAuthInfoTxLength는 고정된 값이 아니고,

고객의 요구사항에 맞게 설정 되는 값 입니다.

자 그럼 만약, 고객으로 부터 Sync Message에 대해 다음과 같은 요구사항을 받았다고 가정 하겠습니다.

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

이걸 Message Diagram으로 표시하면 다음과 같이 표현 할수 있습니다.

각 항목에 대해 알아 보는 절차로 우선 AUTOSAR Spec을 보면 다음과 같이 설명 되어 있습니다.

1. Trip Counter : 신규 IGN On될때마다 1씩 증가 합니다.

2. Reset Counter : Sync Message가 전송되는 주기마다 1씩 증가 합니다.

3. C-MAC

C-MAC은 Sync Message를 송신할때 C-MAC 생성하고, 수신측에서 C-MAC값을 검증하여 데이터의 진본성을 확인 합니다.

C-MAC을 생성하기 위해, ID 2byte, Secure Data인 Data0 ~ Dat4을 미리 고객으로 부터 받은 Key를 이용하여, AES128-CMAC 알고리즘을 수행 합니다.

이 결과 16 byte MAC값이 리턴 되며, 이중 상위 3Byte를 Data 5 ~ Data 7에 추가한뒤 송출하게 됩니다.

여기서 잠시 등장인물편으로 돌아가 보겠습니다.

Master ECU로 부터 송출된 Sync Message는 Secure Message 송/수신측에서 C-MAC을 검증한뒤 검증에 문제 없으면 Latest Fv로 저장 됩니다.

그럼 Latest Fv의 contents는 무엇이 될까요?

Sync Message로 부터 받은 Data중, C-MAC 부분을 제외한 TripCnt, ResetCnt가 저장 됩니다.

이건 나중에 중요한 개념이니 꼭 기억 하시기 바라고, 그럼 오늘은 이만 마치도록 하겠습니다.

감사합니다.

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

​

오늘은 SecOC 두번째 시간으로 SecOC의 원리를 이해 하기 위해 필요한 등장 인물들을 소개해 볼까 합니다.

조금 복잡해 보일수도 있지만, SecOC를 이해하기 위해서는 꼭 필요한 개념이니, 꼭 이해하고 가셨으면 합니다.

(아자 아자!)

1. Freshness Value Manager Master ECU

C-MAC을 기반하여 인증하는 SecOC에서는 Freshness Value라는 개념이 등장 하게 됩니다.

(자세한 내용은 추후에 기술할 예정)

전체 Node의 Freshness Value를 Control하는 Master ECU가 존재 합니다.

​

1.1. Sync Message

Master ECU의 Freshness Value를 동기화하기 위해 전송하는 Message이며, Sync Message 안에는 가장 최신의 Freshness Value가 들어 있습니다.

이 Sync Message를 전달받은 모든 Node는 해당 Sync Message의 정보로 업데이트 하여, 동기화를 하도록 합니다.

2. Secure Message Sender ECU

Secure한 Message를 전송하고자 하는 ECU 입니다.

따라서 송출할 Secure Message를 가지고 있습니다.

​

3. Secure Message Receiver ECU

Secure한 Message를 수신하고자 하는 ECU 입니다.

따라서 Sender측에서 Secure Message가 송출 되면, 이를 수신하는 역할을 하게 됩니다.

​

4. Freshness Value(Fv)

Freshness Value는 SecOC에서 중요하고, 다소 복잡한 개념 입니다.

Autosar SecOC SWS를 기반으로 제가 이해한 바로는, 4가지 정도의 Fv 개념이 필요 합니다.

개념이 다소 복잡하기 때문에 우선 Receiver ECU의 입장에서 Fv 개념을 풀어 보겠습니다.

​

4.1. Latest Fv

Fv Master가 송출하는 Sync Message 안에는 Trip Counter, Reset Counter라는 정보가 들어 있습니다.

Trip Counter는 현재 몇번째 IGN Cycle인지 정보가 나타나며,

Reset Counter는 현재 IGN Cycle안에서 몇번째 Sync Message가 송출되고 있는지를 나타내게 됩니다.

Sync Message를 수신한 나머지 ECU들은 이 정보를 Latest Fv에 저장하게 됩니다.

​

4.2. Recv Fv

Secure Message안에는 Sender가 보내는 Freshness Value의 일부만 포함한 Trunked Fv라는 정보가 포함 되어 있습니다.

수신측에서는 이 값을 받아 Recv Fv에 저장해 놓습니다.

​

4.3. Construct Fv

Recv Fv는 Trunked된 값이기 때문에, 이 값을 토대로 Full Fv를 만들어내는 과정이 필요 합니다.

이를 Construction이라고 표현하며, Construction할때는 Recv Fv, Previous Fv, Latest Fv 정보가 모두 필요 합니다.

이를 통해 Construction된 값을 Construct Fv에 일단 저장해 놓습니다.

​

4.4. Previous Fv

ConstructFv를 이용하여 수신 받은 Secure Message를 검증(C-MAC Verification)하고, 검증이 통과 되었으면, ConstructFv를 Previous Fv에 저장 하게 됩니다.

​

오늘은 SecOC에 등장하는 등장인물들에 대해 간단히 소개해 봤는데, 어떠셨나요?

혹시나 아직은 난해하게 생각 되는 부분이 있으시다면,

추후 포스팅되는 나머지 이야기들을 따라오시다 보면, 조만간 "아 별거 아니었구나" 하시게 될거라 생각 됩니다.

그럼 오늘은 이만 물러 나고 조만간 다시 돌아오도록 하겠습니다~

안녕하세요, 코딩 푸는 남자 입니다.
 
현업에서 일하다 보면, 미처 준비되지 못한 요구사항을 받아서 구현을 해야 하는 일이 종종 발생 합니다.
 
이번에 Secure On CAN 을 요구하는 고객이 있었는데, 현재 가지고 있는 Autosar Solution에서는 해당 Stack을 지원 하지 않았습니다.
 
부랴부랴 Autosar Spec을 읽어가면서 이른바 날코딩으로 구현해야 했었습니다.

 
새로운 스펙에 대한 날코딩이란, 두려운 존재이기도 하지만, 끝나고 나면 많은 것을 배울수 있는 양날의 검인것 같습니다.
 
이제부터 틈틈히, 날코딩하면서 배운 Secure On CAN에 대한 이야기를 풀어 보려고 합니다.
 
오늘은 Secure On CAN에 대해 들어가기에 앞어, 전반적인 사전 지식을 설명해 보고자 합니다.
 
1. CRC
우선 Secure CAN을 알기 전에, CRC를 먼저 간단히 알아 보겠습니다.
혹시 CAN Message의 CRC Field를 들어 보셨나요?
 
이해를 돕기 위해 Bob이 CAN Message ID 0x100에 다음과 같이 전송 했다고 가정해 보겠습니다.

총 Data의 길이는 7 Byte이며, 이중 Data0는 CRC 필드로, Data1 ~ Data6를 기반으로 CRC 계산한 결과를 채워 놨습니다.
이해를 돕기 위해 계산 결과가 0xAF라고 가정해 봅니다.
 
자, 이제 머나먼 먼곳에서 Alice가 다음과 같이 데이터를 받았다고 가정해 봅시다.

Alice는 전송받은 Data0(Recv CRC)와 전송받은 Data1 ~ Data6을 이용하여, 계산한 CRC(Calculate CRC)를 비교하여,
이 둘값이 일치하는지 확인 합니다.
일치하는 경우, 모든 Data가 깨지지 않고 수신 되었다고 판단 할수 있겠죠?
 
만약에 안타깝게도, Data3에 변조가 발생 했다고 가정해 봅시다.

그럼 Bob이 계산해서 보내준 Data0(0xAF) 와 Alice가 Data1 ~ Data6을 통해 계산한 CRC가 일치하지 않겠죠?
 
정리해 보면, 다음과 같습니다.
Recv CRC == Calculate CRC인 경우, Data가 변조 없이 수신 되었다고 판단 가능
Recv CRC != Calculate CRC인 경우, 어느 Data인지는 모르지만, 어디선가 변조가 발생 했다고 판단 가능
 
따라서 CRC를 데이터의 무결성 검증 방법이라 하여, Integrity Check라고 합니다.
 
이전까지는 이정도로 충분 했습니다. 보통 CRC 알고리즘을 좀더 복잡하게 추가하는 방식으로 발전해 나갔습니다.
 
하지만, Cyber 보안이 중요해 지면서, 한가지 중요한 질문이 생겨났습니다.
 
 
다시 Alice가 변조 없이 받은 상황으로 돌아가 보겠습니다.

Alice가 변조 없이 Bob에게 데이터를 받았다고 기뻐하고 있는데, 누가 옆에서 질문을 합니다.
 
 

"근데, 이 데이터가 Bob이 보낸건지 어떻게 보증해?"

 
지금까지 우리는 데이터가 변조가 있었는지에만 초점을 맞추느라, 변조 없이 온 저 데이터가 진짜 Bob에게서 온건지,
전문 낚시꾼에게서 온 가짜 데이터인지 고민하지 않았습니다.
 
어느날 아들에게 카톡이 왔습니다.
"아빠. 나 전화가 안되는데, 급한거야. 빨리 돈 5천억 좀 보내줘!!"

 
전 이렇게 답장을 보냅니다.
"아들아... 세상사는 다 순서가 있단다. 내게 아들이 생기려면 최소한 연얘라는건 해봐야지 않겠니?"
 
 
2. C-MAC의 등장
SecOC는 이런 배경에서 등장 했습니다. 
SecOC 기술이 도입 되면서, 이제 Data Field에 CRC를 제외하고, C-MAC Field가 하나 더 추가 합니다.
 
여기서 MAC은 Message Authentification Code의 약자로, 한국말로, 진짜임을 보증하기 위한 성질(진본성) 이라 합니다.
 
자, 이제 Bob은 Data를 한개 더 사용해서 데이터를 보낸사람이 진짜 Bob 본인임을 나타내기 위한 일종의 싸인을 추가해서 같이 보내게 됩니다.

데이터를 수신 받은 Alice는 이 싸인을 뜯어 보면서 진짜 Bob이 보낸건지, 전문 낚시꾼의 소행인지 면밀히 살펴 봅니다.
 
아... 물론 Integrity Check를 위한 CRC는 계속 해 줘야 합니다.
 
계속...