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

 

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를 하기 위해 다음과 같은 표를 제공 하고 있습니다.

출처 : Autosar SecOC SWS

 

이제 차근차근 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에 대한 대부분의 내용은 끝이 났고, 다음 시간에는 추가적으로 알아야 할 부분들을 일부 살펴 보며 마무리 하도록 하겠습니다.

 

그럼 감사합니다.

'CyberSecurity > SecureOnCAN' 카테고리의 다른 글

6. Recv Secure Message  (1) 2023.12.17
5. Send Secure Message  (0) 2023.12.15
4. Freshness Value - Secure Message Sender Side  (1) 2023.12.08
3. Sync Message  (1) 2023.12.07
2. SecOC의 등장 인물  (1) 2023.12.03

+ Recent posts