No Cyber Security without Key Security
점점 더 많은 차량이 새로운 기능과 비즈니스 모델을 지원할 수 있도록 외부 IT 시스템에 연결되고 있다. 사이버 공격으로부터 연결된 차량을 보호하기 위해 해당 키 자료에 기초한 암호화 방식이 사용되고 있다. 하지만 키 관리를 통해 해결해야 할 문제는 무엇인가? 그리고 AUTOSAR 내 표준화를 통해 어떤 이점을 실현할 수 있는가?
글│에두아르드 메츠커(Eduard Metzker), 팔코 K. 바프(Falco K. Bapp), 안토니오 알메이다(Antonio Almeida), Vector Informatik
출처│Automobil Elektronik 2019년 9월호
최근 몇 년 동안 보안 관련 기능이 차량에 탑재돼 왔다. 예를 들어 자동차 도난방지 장치와 ECU의 보안 프로그래밍에 암호화 및 서명 확인 등과 같은 암호화 방식이 활용되고 있다. 커넥티비티에 관한 지속적인 트렌드는 차량이 지원하는 기능의 범위를 확장하는 것이다. 예를 들어 무선(OTA) 소프트웨어 업데이트, 원격 기능 활성화 및 차량과 인프라 간 통신(V2X) 등이 있다. 이러한 유스케이스를 통해 자동차 업계에는 흥미롭고, 매우 유망한 비즈니스 모델이 탄생한다. 하지만 연결 수가 증가할수록 차량에 대한 잠재적인 사이버 공격수 또한 증가한다.
키: 사이버 보안의 기초
사이버 공격 위험에 대응하기 위해 자동차 업계는 자동차 업계 고유의 보안조치를 구현하며 기존의 IT 보안 분야의 프로토콜을 배포하고 있다. 예를 들어 AUTOSAR의 표준화된 SecOC(보안 온보드 통신)[1]은 ECU와 차량 네트워크 내 ECU 간 통신을 보호한다. 버스 기술과 특정 애플리케이션, 예를 들어 IT 분야에서 자주 언급되는 TLS(전송 계층 보안)와 IPSec(인터넷 프로토콜 보안) 프로토콜이 사용될 수 있다. 모든 최신 보안 메커니즘에서 공유돼야 할 한 가지 특징은 사용된 암호화 알고리즘 세부사항의 기밀성이 아니라 사용된 키의 기밀성에 기초한다. 보안을 더 많이 개선하기 위해 주어진 키는 한 개의 보안 메커니즘에만 사용될 수 있다.
사이버 보안 애플리케이션 수가 점점 증가함에 따라 많은 ECU에서 비밀 키, 개인/공용 키 페어 및 인증서 같은 대량의 암호화 자료가 안전하게 저장돼야 할 필요성이 대두되고 있다. 이러한 맥락에서 키 저장과 차량 키 관리에 대한 개념이 종종 사용된다. 키 저장과 차량 키 관리 개념 간 차이점은 아래에서 설명한다.
암호화 키를 안전하게 저장하기
최근 몇 년 동안 사이버 보안에 대한 표준화가 발전했다. 마이크로컨트롤러의 특수 하드웨어 장치인 HSM(하드웨어 보안 모듈)을 사용하면 키를 안전하게 저장하고, 암호화 계산 속도를 높일 수 있다.
AUTOSAR 컨소시엄은 키를 모델링하고, 암호화 스택을 사용하기 위해 베이직 소프트웨어 내의 암호화 스택을 표준화했다[2](그림 1). 그리고 소프트웨어 기반 라이브러리 또는 HSM에서 제공하는 보안 기능 액세스용의 표준화된 인터페이스를 제공한다(그림 2). 이러한 소프트웨어와 하드웨어의 조합을 통해 ECU에 키 자료를 효율적이고, 안전하게 저장할 수 있다.
그림 1|AUTOSAR 암호화 스택의 목적은 키를 모델링해 암호화 서비스를 사용하는 것이다.
그림 2|하드웨어 보안 모듈(HSM)의 아키텍처
암호화 키의 라이프 사이클
차량에서 키의 사용은 일반적인 일상 작동 모드로 제한되지 않는다. 키 관리에 대한 주제 또한 다음의 차량 라이프 사이클 단계에서 고려돼야 한다(그림 3).
1. ECU 개발: ECU에 초기 키를 저장한다.
2. 차량 통합: 초기 키를 개발 키로 대체한다.
3. 차량 생산: 초기 또는 개발 키를 생산 키로 대체한다. 그리고 종종 외부 소스의 다른 키 자료를 설치하거나 해당 차량에 존재하는 키로부터 다른 키 자료를 얻어야 한다. ECU 간에 비밀 키가 공유될 경우 이러한 키의 기밀성과 무결성은 항상 보장돼야 한다. 예를 들어, 비밀키는 버스를 통해 일반 텍스트로 결코 전송되서는 안 된다.
4. A/S와 서비스 해제: 추가 키 자료 업데이트 또는 설치는 원격 기능 활성화에도 적합한 새 키가 필요할 때에 요구될 수 있다. 또한, 결함이 있는 ECU를 교체할 경우 결함이 있는 ECU에서 어떠한 방법으로도 중요한 키 자료를 읽거나 조작할 수 없도록 조치를 취해야 한다. 그리고 기능이 실행될 수 있도록 새 ECU에 적합한 키 자료가 제공돼야 한다.
그림 3|전체 차량 라이프 사이클 동안 키를 관리한다.
키 관리 전략
다양한 키 관리 전략을 잘 보여주는 적용사례는 SecOC이다. SecOC은 ECU 간 차량 내 통신을 검증하는 데 사용된다. SecOC는 메시지 수신자에게 기록된 메시지의 재생을 감지하고, 메시지 발송자의 신뢰성을 확인하고, 전송된 데이터의 무결성을 평가하는 기능을 제공한다. 이를 위해 수신자는 MAC(메세지 인증 코드)라고 알려진 암호화 체크섬을 확인한다. MAC은 기본적으로 발송자가 생성하고 수신자가 유효성을 확인하는 데 사용된다. MAC 확인이 실패하면 수신자는 메시지를 거부한다. 성능상의 이유로 대칭 암호화 알고리즘을 MAC를 계산하는 데 사용한다.
이러한 방법에서 메시지 발송자와 모든 수신자는 MAC를 생성 및 확인을 위해 같은 키를 사용한다. 이 키는 전체 라이프 사이클 동안 기밀이 유지돼야 한다. 따라서 내부 차량 네트워크 또는 차량 외부의 네트워크를 통해 보호되지 않는 상태로 메시지가 전송되서는 안 된다.
다음 예제의 핵심은 생산하는 동안 키 생성 및 설치이다. 이러한 다른 전략은 본 문서에는 평가되지 않지만 유스케이스가 같을 경우에도 실제로는 키 관리에 대한 다른 많은 솔루션이 있음을 알 수 있다. 이 예제에서는 키 자료는 SecOC를 위해 생성 및 배포된다.
오프보드에서 생성된 키
한 가지 전략은 SecOC에 필요한 키를 생성하는 오프보드 키 관리 서버를 보유하는 것이다. 오프보드 키 관리 서버에는 차량에 설치된 ECU에 대한 정보와 SecOC 키에 대한 요구사항이 포함돼 있어야 한다. ECU는 차량이 생산되는 동안 필요한 키를 가져온다. 이들 키는 기밀이므로 전송하는 동안 암호화를 통해 보호돼야 한다. 수신 ECU에서는 키를 저장하기 전에 키의 신뢰성과 무결성을 확인한다.
코디네이터가 있는 상태에서
온보드에서 생성된 키
이 전략의 경우 생산 과정 동안 테스터에서 SecOC 키가 생성될 수 있도록 인증된 요청을 만들어 생성하고, 조정을 담당하는 ECU에 전송한다. 첫 번째 단계에서 조정 담당 ECU는 일반적인 자동차별 키를 생성한다. 그리고 이 ECU는 각 대상 ECU에 임시 보안 연결을 설정하기 위해 키 계약 프로토콜을 사용하고, 미리 생성된 키를 전송한다. 이 키와 키 파생 규격에 기초하여 각 대상 ECU는 적합한 SecOC 키를 생성한다. 키 계약 프로토콜은 다소 긴 실행 시간이 필요하므로 키를 생성 및 배포하는 데에만 사용된다. 모든 대상 ECU는 방금 생성된 키를 사용하여 SecOC를 통해 서로 안전하고, 효율적으로 통신한다. 그리고 모든 대상 ECU는 새 키를 배포하지 않고 이러한 작업을 수행한다.
코디네이터 없이 온보드에서 생성된 키
또한 여기에서 SecOC의 주요 자료가 온보드에서 생성된다. 하지만 키 생성 요청은 조정 기능 담당 ECU에 전송되지 않고, ECU 그룹에 직접 전송된다. 개별 ECU는 그룹의 구성원을 인지하고, 여러 단계의 키 계약 프로토콜을 시작한다. 그룹 구성원은 버스를 통해 이 키를 실제로 전송하지 않고 공유된 키가 생성되도록 메시지를 교환한다. 그룹의 모든 ECU가 공유된 키를 계산하자마자 각 그룹 구성원은 키 파생 규격에 기초하여 필요한 SecOC 키를 생성한다.
표준화 상태
이전에는 키 관리에 대한 표준이 없었지만 솔루션이 필요했으므로 자동차 OEM은 개별 접근 방식을 따랐다. 같은 유형의 문제를 해결하기 위해 이러한 다른 접근 방식을 개발 및 유지관리하면 관련된 모든 이해 당사자에게 추가 비용이 발생한다. 또 다른 고려사항은 키 관리가 일반적으로 경쟁적이고, 차별화된 제품 특성이 아니라는 점이다. 이러한 최적화의 가능성은 AUTOSAR 4.4 Security Extensions에서 인식돼 활용됐다. 키 관리 전용 모듈 KeyM[3]이 지정되었다(그림 4). 이 모듈은 두 개의 하위 모듈인 암호화 키와 인증서로 구성돼 있다.
암호화 키 하위 모듈은 협상 키에 필요한 기능을 제공한다. 이러한 프로세스는 다른 단계로 세분화된다. 마지막 단계에서 키 자료는 ECU의 HSM에서 암호화 스택을 통해 파생 및/또는 저장될 수 있다. 위에서 설명한 문제로 인해 자동차 OEM에서 정의하는 논리가 KeyM 모듈에 구현되지 않는다. 대신 키 Key Handler(키 처리기)라는 소프트웨어 구성요소에 구현된다(그림 4).
인증서 하위 모듈은 인증서 구문 분석, 확인 및 설치 기능을 제공한다. 애플리케이션에서 추가 처리를 위해 인증서의 정의된 요소 값을 읽을 수 있다. 마지막 단계에서 인증서는 ECU의 NVM(비휘 발성 메모리) 또는 HSM에 저장된다.
그림 4|AUTOSTAR에서 키 관리는 두 개의 하위 모듈 암호화 키와 인증서가 포함돼 있는 KeyM 모듈에서 구현된다.
표준화의 문제
키 관리는 OEM과 공급업체의 개발, 생산 및 A/S 프로세스와 밀접하게 연관돼 있다. 몇몇 기능에 대한 키 자료가 최근 몇 년 동안 이미 사용돼 왔고, 공개 키 인프라(PKI) 및 키 서버 같은 일부 IT 인프라가 이미 존재한다. OEM은 기존 인프라를 재사용하는 경향이 있으므로 표준화 가능성은 제한된다. 기존의 또는 계획된 인프라 또한 암호화 키를 생성하기 위해 온보드 또는 오프보드 방법을 선택할지 여부에 영향을 미친다. 그리고 키 관리 또한 자동차 OEM이 정의하는 보안 목표의 영향을 받는다. 이러한 목표는 개발, 생산 및 서비스 환경의 보안에 대한 가정 같은 다양한 요소에 기초한다. 예를 들어 사내 생산 환경이 안전하다고 가정할 수 있는지에 대한 의견차가 발생한다. 이러한 가정은 생산하는 동안 그리고 A/S 시 보호 조치에 직접적인 영향을 미친다.
생산력 요구사항 또한 키 관리에 영향을 미친다. 예를 들어 모든 차량의 ECU의 키를 전송하는 데 몇 초만 사용할 수 있을 경우 키 관리 전략을 새로 설계해야 한다.
표준화 시 발생한 변형의 수 감소
암호화 알고리즘과 관련 키 자료는 차량의 최신 보안 메커니즘의 기초를 형성한다. 이러한 알고리즘은 사이버 공격에 대비하여 혁신적인 기능과 기존의 비즈니스 모델을 보호하는 데 사용된다.
표준화를 향한 초기 단계는 AUTOSAR 4.4에 도입된 KeyM 모듈이다. KeyM 모듈은 특정 키 관리 전략을 표준화하지 않고, 다양한 전략 구현에 필요한 일반적인 인터페이스를 제공한다. 자동차 커뮤니티는 키 관리 전략을 조화시키는 데 더욱 집중해야 한다. 이를 통해 관련 전략의 키 처리기를 표준화해 실질적으로 변형의 수를 감소시킬 수 있다. 그리고 높은 수준의 표준화로 비용과
참고문헌
[1] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Module Secure Onboard Communication
[2] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Crypto Stack
[3] AUTOSAR 4.4 WP-X-SEC (2018), Specification of Key Manager
<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>