코딩 푸는 남자

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

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

그럼 감사합니다.

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

이번 시간에는 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로 업데이트 하게 됩니다.

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

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

감사합니다.

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

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

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

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쪽으로 찾아 오도록 하겠습니다.

감사합니다.

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

우리는 지난 시간에 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는 계속 해 줘야 합니다.
 
계속...