초기 상항

자동차 업계에 CAN 버스가 개발 도입된 지 이제 거의 25년이 지났다. 차량 운행 중에 상호 연결을 통해 지속적으로 데이터를 교환하는 차내 전자제어장치(ECU)의 수가 점점 늘어나면서 자동차의 E/E 아키텍처도 진화해왔다. CAN 개발 초기부터 네트워크의 신뢰성 확보가 가장 중요한 핵심이었다. 여기에 고도의 유연성, 명확한 통신 표준 채택, 안정된 상호연동성도 필수 조건이었다. 특히 차량에 다양한 부가 기능이나 옵션을 제공하고 자동차 모델에 관계 없이 다양한 플랫폼에 걸쳐 모듈이나 ECU를 각각 적용하기 위해서는 이러한 조건들이 중요하다(재사용의 극대화).
최근 몇 십 년간 CAN 버스 외에 다른 버스 시스템들도 개발되었는데, 이러한 시스템들은 적용 분야에 따라 대역폭이나 실시간 처리 성능 등의 장점이 있다. 그러나 개발 단계에서는 잘 고려되지는 않지만 가장 중요시 해야 할 조건은 잠재적 해킹 방지 성능을 강화하여 신뢰성과 가용성을 최대한 확보하는 것이다.
여러 단계의 증설 과정(제어장치와 프로세서 모듈을 최대 70대까지 손쉽게 증설 가능)을 거치고 다양한 버스 시스템을 게이트웨이 역할을 하는 단일 중앙 ECU로 통합함으로써 여러 개의 서브-버스 시스템으로 구성된 시스템 아키텍처가 구현된다. 그림 1은 대표적인 네트워크 토폴로지의 한 예이다.

 그림 1. 대표적인 네트워크 토폴로지의 예

또 한 가지 주목해야 할 트렌드로, 휴대전화 무선 접속에 필요한 WLAN, 블루투스를 통한 웹서비스 등 외부 서비스와 고객 장비 간의 연결을 위해 차량에서 제공되는 다양한 인터페이스가 있다. 인터넷에서 다운받을 수 있는 차량 관련 애플리케이션도 현재 개발 중이거나 이미 상용화된 예도 있으며, 텔레매틱스(차량 무선 인터넷 서비스)나 비상전화 모듈은 차내 네트워크와의 무선 접속을 위해 별도의 외부 인터페이스를 제공한다.
지금까지는 무단 해킹을 방지하는 차내 네트워크의 보안에 대해서는 충분한 고려가 없었다. 더욱이 호환성과 신뢰성 확보를 위해 마련된 조치들도 적절한 보안 아키텍처를 수립하고 구현하는 과정에는 오히려 장애가 되었다. 따라서 개발 초기 단계에서부터 보안을 차내 네트워크 아키텍처의 정의에 포함시켜야 한다.

해킹 시나리오

해킹
지난 2년 동안, 네트워크 아키텍처의 취약성을 파고드는 수많은 해킹 사건이 보도되었다. 외부 인터페이스를 통해 원격으로 어떻게 차량 내의 특정 기능들을 작동시키거나 중지시킬 수 있는지도 공개되었다.

몇 가지 해킹 사례:
• 마일리지나 차량 서비스 항목의 변경
• TPMS 모듈을 사용하여 특정 차량의 무단 위치 추적
• 감염된 CD를 통해 인포테인먼트 시스템에 트로이 목마 바이러스 설치
• 블루투스를 통한 전화 감청
• 전자제어장치 소프트웨어를 통해 칩 튜닝 유발

이러한 해킹에 사용된 방법들은 다음과 같습니다:

1. 도청
차량 외부 통신을 도청 - 시스템의 잠재적 약점을 파악하기 위함

2. 재전송 공격
데이터 버스로부터 메시지 탈취 – 차후에 메시지를 재전송하여 ECU가 해당 기능을 실행하도록 하기 위함

3. 중간자 공격
원래의 메시지가 중간에 탈취되어 수정된 후 전달됨

4. 각 ECU의 수정 및 비휘발성 메모리의 변경
ECU 소프트웨어는 JTAG 진단을 통해 조작된 후 재설치된다.

OBD 인터페이스들은 대개 케이블을 통한 차량의 물리적 접속에 사용되었다.

시스템 보안 및 무결성 향상

필수 조건
데이터 무결성을 보장하기 위해 차내 네트워크의 해킹을 방지하는 보안 기능의 향상은 필수임이 분명해 보인다. 그러나 동시에 네트워크의 신뢰성과 성능도 고려해야 한다. 예를 들어 암호화 기술을 사용함으로 인해 브레이크나 에어백 등 안전 관련 시스템이 영향을 받아서는 안 된다. 차량에 장착된 다양한 장비들이 제공하는 유연성 또한 손상되어서는 안될 것이다.
기존의 아키텍처나 시스템들과의 호환성을 충분히 고려하고 현재의 하드웨어나 소프트웨어 구성에 대한 변경이 최소화되도록 솔루션을 구현해야 할 것이다.
 
방안: 트러스트 앵커의 통합
기존 시스템은 물론 미래의 시스템까지도 보안을 확보할 수 있는 유일한 방법은 읽기와 쓰기 권한이 제한된 보안 메모리 영역을 통합하는 것이다. 트러스트 앵커 등의 신뢰할만한 요소를 보안 관련 ECU에 통합함으로써 데이터 보안을 향상시킬 수 있다.
 

그림 2. 보안 설계 측면

트러스트 앵커는 보안 마이크로컨트롤러의 형태로 신용카드나 전화 유심카드 등 다양한 보안 관련 시스템에 설치된다. 이렇게 추가되는 마이크로컨트롤러는 그림 2에서 보는 바와 같이 보안 설계 측면 등 시스템 내의 다른 측면들과 관련하여 고려된다.

차량 전자장치 내의 트러스트 앵커

트러스트 앵커는 보안 요소를 통해 구현할 수 있다. 보안 요소는 보안 관련 기능들을 하나의 전용 장치로 통합시킨다. 따라서 각 EU별로 보안 프로세서가 제공되어 다음과 같은 기능들을 지원하게 된다.

• 시스템 권한 보유자들만 읽기와 쓰기가 허용된 보안 메모리 영역
• 동기/비동기 통신 암호화를 위한 암호화 보조프로세서
• 인증서와 비밀키 관리
• 공개키와 체크썸의 생성
 
기존의 마이크로컨트롤러와 통합된 A700x 제품 그룹을 바탕으로 한 NXP 보안 요소는 다음과 같은 보안 관련 기능들의 구현에 적합하다.

• 게이트웨이 보안을 위한 방화벽 애플리케이션. 이 목적을 위해 해당 서브 버스로 전달되기 전에 인증을 받도록 할 수 있다.
• 오류 로그나 마일리지 등 인증을 통해서만 읽기와 쓰기가 가능한 보안 저장 애플리케이션
• 보안 부팅. 이 기능으로 각 ECU의 소프트웨어의 보안이 보장된다.
• (전자) 예비 부품의 인증. 인증된 ECU만 차내 네트워크에 설치된다.
• 보안 접속을 통한 외부 서비스 등록. 보안 요소는 VPN, HTTPS 접속을 위한 접속 데이터를 제공한다.

A700x - 시스템 통합
자동차 분야에서는 데이터 보호나 NXP ATOP(자동차 텔레매틱스 온보드 유닛 플랫폼)에 장착된 텔레매틱스 모듈의 접근 보호 등을 위해 보안 요소들이 설치되었다. 자동차 영역에서 사용된 독립형 보안 요소의 또 다른 예로는 신용카드를 자동차 키로 사용하는 “결제키” 기능이 있다. 이 기능은 공통평가기준 레벨 5+(Common Criteria Level 5+)에 따라 인증된 보안 요소가 필요하다.
NXP의 A700x 보안 요소는 또한 현재 자동차 업계 이외의 분야에서도 여러 보안 관련 애플리케이션에 사용되고 있다.

ECU 보안을 위한 보안 요소
해커의 공격을 방지하는 기능이나 애플리케이션이 정의되면 아키텍처 내에서 보안 요소의 형태로 트러스트 앵커를 설치할 필요가 있는 해당 ECU들을 파악할 수 있다. 여기에는 ECU의 메인 마이크로컨트롤러가 사용하는 “저장”, “통화” 또는 “인증” 데이터처럼 내부적으로 보호해야 하는 기능들이나 추가된 ECU와의 접속을 위한 보안 기능들도 포함될 수 있다. 어떤 경우든 소프트웨어 해킹을 방지하는 보안 부팅 알고리즘은 반드시 구현해야 한다. 
 

그림 3. ECU 아키텍처의 보안 요소

SPI나 I²C인터페이스를 통해 보안 요소를 ECU의 마이크로컨트롤러와 연결할 수 있다. 최대 80 KB의 비휘발성 메모리 영역을 사용해 독립적인 애플리케이션을 생성하여 인증서나 비밀키들을 안전하게 저장할 수 있다. 애플리케이션 독립적인 보안 기능들을 구현하여 보안 요소 내의 임베디드 80C51 코어 기반 보안 CPU에서 실행할 수도 있다. 다음은 몇 가지 예이다:

• 마이크로컨트롤러의 보안 부팅
• 공개키, 세션키, 또는 온보드 네트워크에서 통신 인증을 위한 보안 인증서 생성
• 마이크로컨트롤러 파라미터 및 계산값들이나, 보안 운행기록장치 데이터나 특수 파라미터 등의 온보드 네트워크 정보의 보안 저장

A700x에는 프로그래머블 보안 CPU가 장착되어 있을 뿐만 아니라 사용자를 위한 암호화 보조프로세서도 설치되어 있다. 공개키 암호화 보조프로세서는 RSA (최대 2,048비트), 디피-헬먼(Diffie-Hellman) 키교환, 키 길이가 최대 320비트인 타원곡선 암호화 등의 기술들을 지원한다. AES 보조프로세서의 동기 암호화의 경우, 최대 128비트의 데이터 패킷을 위해서는 ECB(Electronic Cypher Codebook) 운영 모드가, 그 이상의 데이터를 위해서는 CBC(Cypher Block Chaining) 운영 모드가 지원된다. 해쉬합(hash sums)을 산출하고 메모리 영역에 대한 해킹 검사를 하기 위해 SHA1, SHA224, SHA256은 물론, SEED 알고리즘이나 MD5를 위한 보조프로세서가 제공된다.
AIS-31과 호환 가능한 인증된 원본 난수 발생기도 포함되었다.
하드웨어는 높은 보안 수준에서 물리적 공격을 방지할 수 있다. 부채널 공격이나 역엔지니어링 공격은 효과적인 대책을 통해 방지할 수 있다. 결제 기능 등 폐쇄 시스템의 경우, 공통평가기준(Common Criteria)이나 FIPS를 바탕으로 인증을 수행할 수 있다.

소프트웨어 – JCOP 운영체제
보안 요소에는 자바 카드와 호환되면서 사용자에게 암호화 루틴 및 보조프로세서를 사용하기 위한 루틴이나 함수들을 제공하는 독립적인 자바 기반 운영체제가 포함돼 있다. JCOP 운영체제는 각각의 애플리케이션을 관리하고 GPIO를 제어하기 위한 인터페이스를 제공한다. 사용자는 자바 기반 개발 환경을 사용해 직접 애플리케이션을 개발할 수 있는데(Eclipse 등), 이렇게 개발된 애플리케이션은 보안 메모리에 저장된다.
보안 요소를 사용하면 애플리케이션을 자신이 원하는 대로 커스터마이징할 수 있기 때문에 ECU 고유의 기능을 최대한 활용할 수 있다. 외부 마이크로컨트롤러의 보안 부팅, 보호된 ECU 파라미터의 활성화, 보안 데이터 로그 관리 등을 예로 들 수 있다.
필요에 따라 애플리케이션으로 임시 인증서나 공개키를 생성할 수도 있다. 이런 경우 필수적인 비밀키는 보안 요소 외부에서는 접근이 불가능하며 해커들에게는 보이지 않게 된다. 애플리케이션은 MCU에서 해당 호출번호를 통해 외부에서 실행이 가능하다.
또 다른 사용 예로 보안 요소에 의한 버스 통신 인증을 들 수 있다. 여기서 해쉬 또는 체크썸 산출을 위한 비밀키도 보호된 메모리 영역에 저장된다. 산출 과정은 보안 요소 내에서 실행되며 외부에서는 보이지 않는다.
보안 요소 내에서의 JCOP 운영체제 기능 및 애플리케이션 호출은 ECU의 메인 마이크로컨트롤러에서 실행되는 호스트 컨트롤러 API(Application Programmer Interface)에 의해 수행된다. API는 2개의 메인부, 호스트 드라이버 자체, 그리고 인증 라이브러리로 구성돼 있다. 호스트 드라이버가 마이크로컨트롤러의 메인 프로그램에 의해 호출되면 보안 요소의 애플리케이션과 인터페이스가 생성된다. 인증 라이브러리는 보안 요소가 호스트의 정체를 검증하는 데 사용된다.

보안 요소 – 생산과 납품을 위한 신뢰 제공
시스템을 정의할 때 또 한 가지 고려해야 할 측면은 모듈 생산 단계에서 키와 기밀 정보들을 관리하고 설치된 ECU로 전달하는 것이다. 자동차 제조사는 거래업체 중에서 어떤 업체가 보안 요소를 설치할지, 누가 ECU에 키 값을 설치할지, 그리고 유통망의 각 단계별로 할당값을 어떻게 관리할지를 지정해야 한다.
은행이나 신용카드 공급망을 통해 검증된 절차를 자동차 생산에 적용할 수도 있다. 다음 그림은 ECU가 자동차 제조사에 적용되는 절차를 나타낸다. 차량의 최종 조립 단계까지 모듈 생산업체(1계층)와 반도체 공급업체는 사전 합의된 전송 키(transport key)를 사용한다. 예비 부품의 조달 과정에서도 이 키를 설치한다.
전송 키는 반도체 생산 과정에서 보안 생산 환경의 메모리 영역에 저장된다. 이렇게 함으로써 설치된 컴포넌트는 전담 모듈 공급업체만 사용할 수 있게 된다.
일단 모듈이 티어 1 공급업체에 의해 납품되고 나면, 자동차 제조사는 각 차량별로 별도 설계된 애플리케이션 전용 키에 전송 키나 인증서를 대조시키고, 여기서 얻은 데이터를 백엔드 데이터베이스에 각 차량별로 업데이트한다.
티어 1 공급업체나 세미 공급업체(Semi supplier)에 의해 전용 애플리케이션이 보안 요소에 사전 설치되도록 함으로써 접속 데이터(VPN 터널 등)가 백엔드 시스템에 제공되어 “엔드투엔드” 암호화가 가능해진다. 현장에서 ECU를 교환하는 등의 경우에 이 절차를 사용할 수 있다.
 

그림 4. 신뢰 제공 구조도

요약 및 향후 전망

요약
차량 내 전자 시스템의 보안 문제가 갈수록 중요해지고 있는데, 그 이유는 주로 3가지로 들 수 있다.

1. 차량 내 전자제어장치들이 상호 복잡하게 연결되어 있기 때문에 무단 기능 변경이나 해킹에 취약하기 때문에 보안이 필요하다.
2. 차량 내 (모바일) 장치와의 인터페이스가 늘어나고 외부 서비스(앱스토어/인터넷) 접속도 증가함에 따라 보안 솔루션이 필요하다.
3. Car-to-X 통신이나 긴급전화 모듈(eCall)을 사용할 때는 개인 데이터를 보호하고 차량의 원격 해킹을 방지하기 위해 보안이 필요하다.

이에 따른 보안 문제를 보안 요소로 해결할 수 있다. 특수 시스템, 수명주기, 신뢰성에 관한 가이드라인을 고려해야 한다. 보안 요소는 시스템 내에 믿을만한 '신뢰의 뿌리'가 된다.
무단 해킹을 방지하는 시스템 보안은 정의 및 설계 과정의 초기 단계에서부터 고려해야 한다. 이 과정에서 기능적 보안도 무시해서는 안 된다. 그러나 이러한 조건들 상호간에 충돌이 발생할 수도 있다.
네트워크에서 주로 사용되는 보안 요소는 차량 오류 로그나 마일리지, 서비스 데이터의 해킹 방지 구현 등 개별 운영체제의 보안에도 사용할 수 있다.
eCall, 텔레매틱스, 일반 백엔드 서비스의 경우, VPN 터널이나 HTTPS를 통해 자동차 제조사의 서버에 대한 보안 접속을 설정하는 트러스트 앵커로서 보안 요소를 사용할 수도 있다. 텔레매틱스 애플리케이션에 사용자 관련 데이터를 보안 저장하는 것도 가능하다.


향후 전망
차량의 해킹 방지를 위한 보안은 더욱 강화할 필요가 있다. 자동차 제조사는 자체 시스템 전체의 보안을 평가하고 잠재적 해킹 시나리오와 보호가 필요한 데이터에 대한 점검을 고려할 필요가 있다.
미래에 대비하여 다음과 같은 사항이 중요하다:

• 개별적 기능과 전체 시스템을 보호하는 유연한 솔루션
• 시스템의 보안 표준
• 전체 시스템에 걸쳐 실시할 수 있는 테스트 시나리오

궁극적으로, 차내 네트워크의 보안은 미래 car-to-X 통신을 위해 필수 불가결한 요소라 할 수 있다.