[Mobility Security] CAN Protocol

티스토리 뷰

Mobility Security

[Mobility Security] CAN Protocol

chettz 2025. 4. 22. 02:49

CAN(Controller Area Network) Protocol

CAN?

CAN Protocol : 차량 내 각 ECU 장치들이 Host Computer 없이 서로 소통하기 위해 설계된 Message 기반 표준 프로토콜

ECU(Electronic Control Unit) : 자동차에서 사용되는 많은 전자 제어 장치를 지칭한다.

Airbag Control Unit, Engine Control Unit, Brake Control Unit, OBD 등의 전자 제어 장치들이 존재
ECU는 각 센서로부터 오는 정보들을 처리하고, 전자장치를 제어

CAN Protocol 두둥장

CAN Protocol 등장 이전 모듈(ECU)이 많지 않던 초기에는 서로 통신하기 위해 UART 방식을 사용했다. UART(Universal Asynchronous Receiver/Transmitter)는 모듈들이 서로 일대일(Point-To-Point) 방식으로 연결되어 있는 구조이다. 그러나 차량 내부에 모듈 수가 증가함에 더 많은 배선이 필요했고, 이는 차량 무게 증가 및 연비 하락의 문제로 이어졌다.

이러한 문제를 해결하기위해 BOSCH사에서 CAN Protocol을 개발하였다. 기존 UART 방식과 다르게 모듈(ECU)들이 병렬로 연결되어 통신하는 Multi Master 구조이다. BMW 850 쿠페에 CAN Protocol을 처음 적용하였으며, 배선의 길이와 차량의 무게가 줄어드는 효과를 볼 수 있었다.

각 ECU들은 CAN 버스 네트워크에 병렬로 연결되어 있고, 버스 라인을 통해 CAN 메시지를 주고받는다. 통신 라인을 공유하는 모든 ECU들이 마스터 역할을 하는 Multi Master 구조이다.

보안을 고려했을 때?

하지만 이러한 단순한 구조적 기능이 외부와 연결되었을 때 보안 문제가 발생할 수 있다. CAN의 어떤 특징이나 기능이 공격 지점으로 발생할 수 있는지 CAN에 대해 자세히 설명 후 알아보겠다. 그 전에 ECU가 뭐고 어떻게 구성되어 있는지 잠깐 아라보자

ECU (aka 'CAN node')

ECU는 차량의 특정 기능이나 시스템을 제어하는 전자 제어 장치이다. 각 ECU는 버스 라인에 연결된 다른 ECU들과 정보를 공유할 수 있다. 현대 차량에서는 70개 이상의 ECU가 차량에 존재한다. ECU는 센서 또는 다른 ECU로부터 정보를 전달받아 동작을 수행한다. 예를 들어 Airbag Control Module(ACM)은 에어백 시스템의 동작을 관리하는데, 다양한 센서들로부터 입력을 받는다. 충돌 센서 및 안전벨트 프리텐셔너 센서의 입력 받아 에어백의 전개 여부를 결정할 수 있다.

그럼 ECU는 어떻게 구성되어 있을까? MCU, CAN controller, CAN transceiver 3가지로 구성되어 있다.

Microcontroller(MCU)
- 들어오는 CAN 메시지를 해석하고 어떤 메시지를 전달할지 결정
CAN controller
- 컨트롤러는 일반적으로 MCU에 통합되어 있으며, 모든 통신이 CAN 프로토콜을 준수하도록 보장
- 내부 버퍼를 가지고 있고, 수신 메시지에 대한 유효성을 ID 기반으로 판별 후 MCU에 전송
CAN transceiver
- MCU와 CAN wire에 사이에 위치하여 송/수신 담당
- 송신시에는 MCU에서 생성한 디지털 신호를 아날로그 신호로, 수신 시에는 그 반대의 역할을 수행

CAN 특징

CAN 통신은 여러 개의 ECU가 병렬로 연결되어 있고, 모든 ECU가 마스터 역할을 수행한다. 통신 라인에 CAN 메시지를 띄어놓으면, 메시지가 필요한 ECU들은 데이터를 가져와 사용할 수 있다.

1. Twisted pair cable(2-wire)

CAN 신호 전달 매체로써 CAN_H와 CAN_L이라는 꼬인 두 개의 선에 차등 신호 방식으로 신호를 전달한다. 이 방식은 신호의 간섭을 줄일 수 있다.

2. Multi Master 통신

여러 개의 ECU들이 동일한 버스 라인에 연결되어 통신할 수 있다. 버스가 idle 상태라면 언제든지 메시지 전송이 가능하다.

3. 무게와 비용 감소

일대일 연결이 아니므로 적은 양의 전선을 사용하여 무게와 비용을 줄일 수 있다.

4. 메시지 지향성 프로토콜 / ID 값에 의한 우선순위

CAN 메시지에 주소를 포함해 전송하지 않고, 메시지 우선순위에 따라 ID를 할당한다. CAN node들은 ID를 기준으로 자신에게 필요한 메시지인지 판단한다.

5. 고속 통신

최대 1Mbps에 달하는 전송속도를 제공한다.

6. PLUG&PLAY

CAN node를 버스에 간편하게 연결하고 끊을 수 있어, 장치의 추가 및 제거가 용이하다. 결함 노드의 버스 연결을 자동으로 해제한다.

CAN Protocol 규격

CAN은 CAN 프레임에 존재하는 식별자(ID)길이에 따라 두 가지 모드로 구분할 수 있다. CAN 2.0A 컨트롤러는 표준 CAN 포맷 메시지만 전송 및 수신이 가능하지만, CAN 2.0B 모든 메시지 포맷에 대해 송수신이 가능하다.

표준 CAN(2.0A) : 11비트 길이의 ID
확장 CAN(2.0B) : 29비트 길이의 ID

ISO 규격에 따라 두가지로 구분될 수 있는데 통신 속도에서 차이가 있다.

ISO 11898 : 1Mbps 이상의 고속 통신 가능, 차량 중요 통신에 해당되는 RPM관리 또는 브레이크 등에 사용
ISO 11519 : 125Kbps 까지의 통신 가능, 상대적으로 중요하지 않은 통신들에 사용(에어컨 제어, 문 개폐 등등)

CAN은 2-wire 구조를 갖는다 했는데, 신호는 어떻게 전달되는 걸까. CAN transceiver가 CAN_H와 CAN_L에 각각 연결되어 있고, 각 전선 서로 다른 전압을 주어 두 선의 전위차를 통해 정보를 전송한다. 두 신호의 차이가 버스의 상태를 정의한다.

Dominant(우성) - 디지털 '0'으로 표시하며, 두 선의 전위차가 발생할 때이다.
Recessive(열성) - 디지털 '1'로 표시하며, 두 선의 전위차가 없는 경우이다.

CAN 프레임

CAN 버스 라인에 보낼 수 있는 패킷의 종류는 여러가지가 있다. CAN 통신 프레임이라고도 한다. CAN 통신 프레임은 [그림 5]와 같이 여러 종류로 나눌 수 있다. 그 중에서도 Data Frame에 대해서 아라보자.

Data Frame은 위 그림과 같이 구성되어 있다. 각 필드별로 무슨 역할을 하는지 살펴보자

SOF(Start of Frame)
- Frame의 시작, 1bit로 구성, 값은 항상 logical '0'
- SOF전에 구리선은 Recessive(1), SOF가 나가면 Dominant로 바뀌고 Falling Edge가 생김 → 모든 ECU가 박자를 맞춤
- 여러 개의 ECU가 물려 있을 때, ECU 하나가 정보 전송을 시작하면 falling edge가 생기고 해당 edge를 통해서 다른 ECU들이 인지
EOF(End of Frame)
- Frame의 끝, 7-bit의 1로 구성되어 있음
Arbitration Field - Identifier(11bit) | RTR(Remote Transmission Request, 1bit)
- 메시지의 충돌이 일어났을 때 ID를 가지고 우선순위를 식별해 해소할 수 있음
- ID 값이 낮을수록 우선순위가 높음
  - 상대적으로 우선순위가 높은 ID값을 가진 패킷의 인터벌을 의도적으로 조작하여 공격할 수 없을까?
  - 인터벌을 더 짧게하여 우선순위가 낮은 정상 패킷들이 각 ECU로 가지 못하는 상황이 발생할 수 있지 않을까?
- Identifier
  - data의 의미와 성격을 나타냄
  - data frame끼리 충돌이 일어났을 때 우선순위를 결정
- RTR - Data frame인지 remote frame인지 선택하는 비트, data frame일 경우 bit 값 '0'
- [그림 6] 우선 순위 처리 예시
  - 10~6 bit까지는 모든 노드의 상태가 동일하다. 그러나 5번째 bit에서 노드 2의 값이 1로 값이 높으므로 탈락하여 신시신호 전송을 정지하고 Receive Mode로 전환
  - 이후 노드 1과 3은 3번째 bit까지 동일하지만 2번째 bit에서 차이 발생
  - 노드 3이 0으로 dominant하므로 노드 1은 Receive Mode로 전환
  - 우선순위는 노드 3이 제일 높고, 전송을 중지한 노드 1, 2는 다음에 재전송 시도

Control Field(6bit)
- r1, r0 - identifier를 29bit로 확장하는데 사용
- DLC(Data Length Code) - can frame이 싣고가는 데이터의 길이 결정, 0~8bytes까지 표현 가능
Data Field(0~8bytes)
- 데이터가 저장되는 필드
- 리틀 엔디안, 빅 엔디안 두 가지 방식 모두 가능
CRC Field(16bit)
- CRC Sequence(15bit)
  - ECU의 CAN Controller에서 계산(sender)
  - SOF부터 Data field의 마지막 bit에서 desutffing된 비트열에 15개의 0을 붙여줌
  - 해당 비트열을 0xC599로 나누었을 때 나오는 나머지 15bit가 CRC Sequence
  - 노이즈등으로 인한 Error를 검출할 수 있는 기능
  - Receiver는 data frame에 error가 발생했는지 체크하기 위해 SOF부터 CRC Sequence까지 destuffing된 비트열을 0xC599로 나누었을 때 나머지를 체크, 나머지가 0이면 error 발생 X
- CRC Delimiter(1bit)
  - logical 값 항상 '1'
Acknowledgment Field(2bit)
- Acknowledgment Delimiter - 항상 logical '1'
- Acknowledgment Slot
  - 정상 통신의 경우 slot은 좌우에 항상 1값을 가져 쉽게 구분할 수 있다.
  - 받는 ECU가 logical '0'을 보내면 can frame이 규약에 맞게 왔음을 알려줌
  - error가 발생했다면 1
  - sender를 제외한 ECU는 can frame에 실려오는 정보를 추출하든지 안 하든지 통신 라인에 흘러가는 can frame의 규격을 상시 체크
  - ID filtering에 관계없이 버스 라인에 연결된 모든 ECU는 error가 없다면 ACK slot에 0을 보내야 함. 해당 시점에 구리선의 값은 0이됨.
  - Sender ECU는 ACK slot값을 구리선으로 부터 읽고, ACK Del 값을 보내기 시작
  - 만약 각 ECU가 error를 다르계 계산했다면??
    - dominant한 0의 값을 따르게 됨
    - error를 검출한 ECU는 ACK Delimiter가 지나간 후에 error frame을 전송
  - 모든 ECU가 error를 검출했다면??
    - Sender는 error frame전송, 나머지 ECU들도 error frame 전송
IFS(Inter Frame Space)
- 다음 프레임 전송이 시작되기 전까지 적어도 3-bit 이상의 1의 간격이 유지되어야 함
- 반드시 3-bit 쉬고 정보 전송을 시작해야 함