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

벌써 다섯번째 시간이네요.
들어가기 앞서, 잠시 지난 시간으로 돌아가 보겠습니다.
![]() |
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쪽으로 찾아 오도록 하겠습니다.
감사합니다.

'CyberSecurity > SecureOnCAN' 카테고리의 다른 글
7. Construct Fv in Recv Side (0) | 2023.12.19 |
---|---|
6. Recv Secure Message (1) | 2023.12.17 |
4. Freshness Value - Secure Message Sender Side (1) | 2023.12.08 |
3. Sync Message (1) | 2023.12.07 |
2. SecOC의 등장 인물 (1) | 2023.12.03 |