차량 보안을 고려한 게이트웨이의 라우팅 방법에 대한 연구

2.1 MAC(Message Authentication Code) Use Case

수신자가 메시지를 수신할 때, 올바른 발신자가 보낸 메시지인지 혹은 허가받지 않은 해커가 보낸 메시지인지 판별하기는 매우 어렵다. Fig. 4는 Attacker에 의해 인증되지 않는 Fake Message가 전송되는 것을 보여준다.

Fig. 4

Fake message sent by attacker

따라서 메시지를 안전하게 전송하기 위해 무결성과 인증이라는 두 가지 속성과 절차가 요구된다. 메시지의 무결성은 메시지가 위변조되지 않았음을 입증하고, 메시지 인증은 메시지가 올바른 발신자로부터 송신된 것임을 의미한다.

메시지 인증 코드 (MAC)는 데이터가 변조되었는지 확인하기 위한 방법이다.¹²⁾ 수신자와 발신자만 알고 있는 개인보안 키를 사용하여 MAC 값을 생성하고, 이 값을 이용하여 아래 Fig. 5와 같이 전송 된 메시지의 무결성을 확인 및 인증할 수 있다.³⁾

Fig. 5

Message authentication and verification for secure communication2)

Fig. 5의 발신자는 송신할 메시지와 개인보안 키를 사용하여 MAC값을 생성하고, 송신할 메시지와 MAC값을 함께 송신한다. 수신자는 메시지와 MAC을 함께 수신한 후, 수신된 메시지와 개인보안 키를 사용하여 MAC값을 직접 생성한다. 수신자가 수신한 MAC값과 직접 생성한 MAC값을 비교하여 일치하면 메시지의 무결성과 인증절차를 마치게 된다.

MAC값을 계산하기 위해 다양한 알고리즘이 존재한다. 본 논문에서는 현재 자동차 보안에서 가장 대중적으로 적용되는 Blockchipher기반의 CMAC방식을 사용하여 실제 차량 시스템과 동일한 환경으로 구현 및 시험한다.

2.2 CMAC (Cipher-based Message Authentication Codes)

AUTOSAR의 'Specification of Secure Onboard Communication'은 NIST SP800-38B에 따라 AES-128 기반 CMAC 알고리즘을 사용하여 MAC을 계산한다.⁹⁾ CMAC(Password Based Message Authentication Code)는 비밀키와 결합 된 블록암호를 사용하여 메시지 인증 코드를 계산한다. 그러므로, CMAC를 사용하여 메시지의 무결성과 인증을 확인할 수 있다. CMAC는 오류에 의한 데이터 변경뿐 아니라 의도적인 위변조도 감지할 수 있다. 최근 자동차 제조사는 CMAC을 안전하고 효율적으로 계산하기위해 Microcontroller에 내장된 HSM(Hardware Security Module)을 사용한다.

Fig. 6은 HSM 내장형 Microconroller의 아키텍쳐를 보여준다. HSM 은 Firewall에 의해 고립되어 있는 구조로써, 기존 Core들은 극히 제한된 통로 이외에는 HSM의 내부를 접근할 수 없다. 이와 반대로 HSM은 Firewall외부의 영역을 자유롭게 접근할 수 있다. HSM 내부에는 AES-128과 같은 암호화모듈을 내장하고 있다.

Fig. 6

Hardware Security Module (HSM)11)

2.3 게이트웨이의 라우팅

라우팅은 게이트웨이 제어기의 가장 기본적인 기능 중 하나이다. 하나의 통신 버스에서 다른 통신 버스로 메시지 및 데이터를 전송하는 작업을 의미한다. 동일한 유형의 버스간에(예. CAN-to-CAN) 또는 서로 다른 유형의 버스간에(예. CAN-to-Ethernet) 데이터를 라우팅 할 수 있다. 모든방식의 라우팅은 제한된 시간안에 정확하게 메시지가 전달되는 것이 매우 중요하다. 최근에는 제어기 수의 증가, 데이터양의 증가, 보안을 위한 격리 등의 이유로 통신 버스수를 늘리고 있고, 이더넷과 같은 고속 통신 프로토콜이 적용되고 있다. 이와 같은 변화에도 네트워크간의 정보교환은 항상 정확하고 빠른 통신이 요구된다.

게이트웨이가 서로 다른 유형의 버스에 대한 라우팅을 수행할 때, 한 유형의 프레임이 다른 유형의 프레임으로 캡슐화 되어야 하며, 일반적으로 작은 대역폭의 버스에서 더 큰 대역폭을 가진 다른 버스로 전달되는 경우가 해당된다(예. CAN-to Ethernet). 이어서 IP 또는 MAC주소를 사용하여 캡슐화 된 데이터가 최종수신제어기에 전달된다. 이와 같은 작업을 터널링이라 한다. 수신제어기는 캡슐화된 데이터패키지를 해제시키고 이 데이터를 시스템 RAM에 저장한다.

실시간 터널링을 하는 이유는 ECU를 직접 연결하지 않고도 한 도메인에서 다른 도메인(예: 인포테인먼트 시스템에 표시되는 자동차 속도)으로 데이터를 공유하는 것이다. 이와 같은 방식은 시스템의 유연성을 높이고 케이블사용을 줄일 수 있다. 도메인 아키텍처 및 Gbit Ethernet 백본 외에 ADAS, 센서 퓨전, 인포테인먼트 도메인의 도입으로 이와 같은 사용예는 더욱 증가하고 중요해지고 있다. 실시간 터널링의 중요한 요소는 라우팅 대기 시간이다(즉, 패킷이 송신측에서 수신측으로 라우팅되는 데 걸리는 시간).

Fig. 7은 게이트웨이가 CAN-to-Ethernet 라우팅을 수행하기 위한 시스템 아키텍쳐를 보여준다. 게이트웨이는 CAN통신을 통해 메시지를 수신한 후, HSM을 통해 메시지의 인증과 무결성을 확인한다. 이어서 이더넷에 맞게 터널링작업을 수행하여 이더넷용 버스로 송신을 한다.

Fig. 7

Routing structure of CAN-to-Ethernet5)

2.4 게이트웨이 라우팅 분석의 필요성

서로 다른 유형의 버스에 대한 라우팅 수행과 높은 보안레벨의 적용 등으로 지연시간과 코어 부하가 크게 증가하고 있다. 컨셉설계 단계에서 코어부하와 지연시간의 원인에 대한 정확한 분석과 예측이 없다면, 자동차 제조사의 시스템 요구사양에 최적화된 게이트웨이 라우팅 사양설계가 이루어 질 수 없다. 또한, 요구성능을 만족하기 위한 부하 예측 및 적합한 코어 제품을 선택하는 것도 어렵다. 그러므로, 체계적이고 정량화된 분석/설계 프로세스를 확립하고 적용하는 것이 필요하다.

3.1 게이트웨이의 보안 전송 방안

본 논문은 게이트웨이가 메시지를 라우팅하기 위해 적용 가능한 세가지 방식을 제안한다. 첫째, 직접 라우팅시 수신 메시지의 MAC무결성을 확인하지 않는 방식(Fig. 8 참조), 둘째, 직접 라우팅시 수신 메시지의 MAC검증을 포함하는 방식(Fig. 9참조), 셋째, 간접 라우팅시 수신 메시지의 MAC검증과 메시지의 데이터를 선별 및 가공 후 메시지로 계산한 새로운 MAC을 생성하여 송신하는 방식(Fig. 10 참조) 등이다.

Fig. 8

Direct routing (without CMAC verification)

Fig. 9

Direct routing (with CMAC verification )

Fig. 10

In-direct routing (with CMAC verification and generation)

본 논문은 게이트웨이의 메시지 무결성 확인과 인증절차를 위해 CMAC을 사용한다. 본 논문이 제안한 세가지 라우팅 방안은 Table 2에 상세히 설명된다.

Table 2

Three message routing methods considering security

3.2 게이트웨이 지연시간 분석

게이트웨이 지연시간을 분석하기 위해, 지연시간을 전송단계에 따라 분리하고 각 단계별 시간을 실험과 계산을 통해 파악해야한다. Fig. 11은 안전한 메시지 전송을 위한 게이트웨이 시스템의 전송단계를 간략하게 보여준다. Fig. 11의 T1, T2, T3, T4 및T5는 단계별 지연 시간을 나타낸다. 게이트웨이의 단계별 지연 시간은 Table 3에 상세히 설명되어 있다. T1과 T5는 통신속도와 메시지 프레임 크기를 계산하여 파악할 수 있고, T2와 T4는 HSM과 코어의 성능과 소프트웨어구조에 따라 다른 결과를 얻으므로 실험을 통해 파악할 수 있다. T3는 코어의 성능, 소프트웨어구조, 라우팅을 위한 IP종류 등에 따라 다른 결과를 얻으므로 실험을 통해 파악할 수 있다. 게이트웨이의 총전송 지연 시간은 앞서 제시된 세가지 전송모드에 따라 각각 다르게 나타난다.

Fig. 11

Routing process of CANFD to Ethernet6)

Table 3

Latency by routing steps

CMAC 검증없이 직접 라우팅하는 경우 CAN 및 다른 크기의 CAN-FD 메시지는 IEEE 1722 이더넷 프레임으로 즉시 캡슐화된다. 이어서 CMAC 검증없이 1722 이더넷 프레임으로 전송된다. 이 경우 T2와 T4 시간을 요구하지 않고, Microcontroller내부의 HSM 모듈은 사용되지 않는다.

CMAC 검증을 포함한 직접 라우팅 전송의 경우, CAN-FD 메시지는 이더넷 프레임에 캡슐화되고 CMAC값에 대한 검증 후 전송된다. 이 경우, CMAC검증을 위해 T2시간이 요구되고 HSM모듈이 사용된다. CMAC 검증을 위한 추가 지연 시간, T2는 64 바이트 페이로드 CAN-FD 프레임의 경우 42 us이다.

CMAC을 검증 및 생성해야 하는 간접 라우팅 전송의 경우, CAN-FD 메시지는 이더넷 프레임에 캡슐화되고, 수신된 CMAC값을 검증하고 변경된 송신 데이터에 맞는 신규 CMAC값을 재생성 후 전송된다. 그러므로, 간접 라우팅은 CMAC값 검증을 위한 T2와 신규 CMAC값 계산을 위한 T4시간이 요구된다.

Table 4는 각 라우팅 방법에 따른 지연시간을 보여준다.

Table 4

Total latency according to routing method (Description)

4.1 하드웨어 실험 환경

본 논문은 실험환경 구현을 위해 Realtek의 RTL 9047AA 이더넷 스위치와 함께 AURIX™ TC397를 사용한 두개의 Infineon 자동차 게이트웨이 평가 보드를 사용하였다. Aurix마이크로 컨트롤러 TC397는 데이터 전송을 위해 1Gbps RGMII포트와 스위치에 연결하여 사용했다.¹⁾

CAN 프레임은 2개의 Peak PCAN-USBPro FD 장치에 의해 생성된다. CAN-FD 프레임은 2Mbps Data 프레임(CAN의 경우 1Mbps) 및 1Mbps Arbitration Phase로 구성된다. 2개의 PCAN 장치는 게이트웨이 보드 #1의 8개의 CAN 포트에 연결된다. 마지막으로, 로직 분석기는 지연 시간을 측정한다(Fig. 12 T1참조). 게이트웨이 보드 #1이 수신 한 CAN 프레임은 로컬라우팅 테이블을 사용하여 라우팅되고 CAN 포트에서 이더넷 인터페이스로 포맷된다. 사용된 이더넷 프레임 형식은 IEEE 1722-2016 표준에 의해 정의된 ACF(AVTP Control Format)이다(Fig. 12 T3참조).²⁾ ACF는 Time Sensitive Networking Ethernet을 사용하여 다양한 제어 메시지를 시간 동기화 또는 비동기화 방식으로 전송하기 위한 유연한 프레임 워크를 제공한다. 본 논문은 실험을 위해 CAN / CAN FD ACF 메시지를 사용한다. Fig. 13은 IEEE 1722 프레임에 CAN프레임이 캡슐화 되어있는 것을 보여준다. CAN 프레임이 CAN/CAN-FD ACF 이더넷 프레임에 캡슐화되어 있고 프레임이 1Gbps 이더넷 인터페이스를 통해 게이트웨이 보드 #2로 전송된다(Fig. 12 T5참조). 게이트웨이 보드 #2는 이더넷 프레임을 수신하고, 이 프레임에 포함된 CAN 프레임을 추출하여 라우팅 테이블을 확인한 후 CAN 프레임을 오른쪽 CAN 인터페이스로 라우팅한다. 실험 환경 설정의 개요는 Fig. 12에서 볼 수 있다. Aurix TC397은 6개의 TriCore CPU 가 내장되어 있지만, 이 실험 환경은 1 CPU 만사용한다. 이 실험환경을 구현하기 위해 이더넷 스택에 Infineon Low-Level Drivers(ILLD)와 오픈소스 라이브러리 LwIP(Lightweigh IP)를 사용한다. 하드웨어 가속은 CRC 계산을 위해 사용된다. Table 5는 사용된 자원을 요약하여 보여준다.

Fig. 12

Gateway routing experiment environment

Fig. 13

CAN/CANFD AVTP format (IEEE 1722-2016)4)

Table 5

Routing experiment environment

4.2 실험 결과

Fig. 14와 Fig. 15는 전송 지연(T2)에 대한 고려 없이 페이로드 크기에 대한 평균라우팅 지연 시간을 보여준다. CAN과 CAN-FD비교시 라우팅 지연은 큰차이가 없고, 페이로드의 크기에 따른 라우팅 지연차이도 매우 제한적인 것을 볼 수 있다. CAN은 최대 8bytes의 Payload를 지원하므로(Table 5참조) Fig. 14와 Fig. 15는 64bytes Payload에 대해 CAN-FD의 결과값만을 표시한다.

Fig. 14

Comparison routing latency of Ethernet to CAN/CANFD

Fig. 15

Comparison routing latency of CAN/CANFD to Ethernet

이어지는 실험에서 게이트웨이 성능은 64 바이트 CAN-FD 메시지가 이더넷 프레임으로 캡슐화되어 전송되는 시간을 측정했다. Table 6은 라우팅 방법에 따라 측정된 시간을 포함한다.

Table 6

Total latency according to routing method (Test result [us])

결과적으로 게이트웨이에서 고정된 지연 시간은 T1, T3 및 T5이고, 라우팅 방법에 따라 고려되야 하는 지연 시간은 CMAC 검증 시간 및 CMAC 생성 시간 인 T2, T4이다. 위 실험은 각각의 T2 및 T4가 42μs 시간이 소요됨을 보여준다. 그러므로, 라우팅 방법에 따른 변동 시간은 CMAC 사용여부에 따라 다르게 나타난다.

Table 7

Pros and Cons according to routing methods