SOTA - 보안 소프트웨어 무선 업데이트

ECU에 제공되는 별도의 메모리로 효율적 구현

글│마틴 클림케(Martin Klimke), 아이네스 페데르센(Ines Pedersen), 비요른 스테우리치(Bjorn Steurich), 인피니언 테크놀로지스
2017년 07월호 지면기사

리콜에 따른 비용의 대부분은 소프트웨어 결함을 보정하는 데 들어간다. 소프트웨어 무선 업데이트(SOTA)는 이러한 비용을 크게 줄일 수 있다. 테슬라는 자동차 업계에서는 SOTA의 선구자라고 할 수 있다. 자동차는 반드시 변조 위협으로부터 안전하게 보호되어야 하므로, 업데이트 과정은 빠르고 신뢰할 수 있어야 하며 기능 안전에 손상을 주어서는 안 된다.


자동차 제조업체들이 리콜 조치로 인해 증가하는 비용문제에 직면하고 있다. 비용의 대부분은 소프트웨어 결함과 발견된 결함을 보정하는 데 들어간다. 따라서 이에 대처하는 확실한 방법은 무선 연결을 이용한 소프트웨어 무선 업데이트(Software updates Over The Air, SOTA)이다.
 

현재 무선 소프트웨어 업데이트는 모바일 기기에서 흔히 시행되고 있지만, 자동차에서 소프트웨어 무선 업데이트를 시행하려면 먼저 보안과 안전, 편의성 요소들을 고려해야 한다. 자동차는 반드시 변조 위협으로부터 안전하게 보호(보안)되어야 하므로, 업데이트 과정은 빠르고 신뢰할 수 있어야 하며 기능 안전에 손상을 주어서는 안 된다.
 

SOTA를 구현하는 기본적인 동기는 명백하다. 시장조사업체 HIS에서 최근 발표한 오토모티브 리포트(Automotive Report)에 따르면, SOTA 시행을 통해 절감할 수 있는 비용이 2015년에 약 27억 달러에서 2022년에 350억 달러 이상으로 증가할 것으로 전망된다(그림 1 참조). 자동차 제조업체(OEM)가 SOTA를 도입하는 이유로는 리콜 비용 감소, 신속한 기능 업데이트, 고객 만족 증대 등을 꼽을 수 있다.
 

 

현재 내비게이션 데이터와 인포테인먼트 애플리케이션을 위한 무선 업데이트는 표준으로 자리잡고 있지만, 인포테인먼트 영역을 벗어나 전자제어장치(ECU)를 위한 SOTA를 구현하는 데에는 특정한 기술적 과제가 따른다. 일반적으로 자동차에서 실시간 애플리케이션 제어에는 플래시 메모리가 내장된 마이크로컨트롤러가 사용된다. 이 경우 품질, 안전 및 보안 표준을 유지해야 하며, 취약한 데이터 보안으로 자동차 안전이 훼손되지 않도록 해야 한다. 따라서 자동차에 요구되는 사항은 소비제품에 적용되는 인포테인먼트 애플리케이션의 경우보다 훨씬 까다롭다.
 

사이버 공격 보호


SOTA 구현은 적절하게 보호하지 못할 경우 외부 공격자가 차량의 안전에 중요한 애플리케이션을 조작할 수 있으며, 그에 따라 차량 전체의 보안이 위협받게 되고 최악의 경우 탑승자의 생명이 위험해질 수 있다. 이를 방지하려면 암호 방식과 함께 인증과 개인키의 사용을 지원하는 복합적인 보안 아키텍처가 필요하다. 적합한 암호기법은 RSA, ECC, AES, SHA와 같은 표준 알고리즘을 기반으로 한다. AURIX™ 및 OPTIGA™ TPM 제품군과 같은 인피니언의 보안 마이크로컨트롤러는 이러한 종류의 보안 기능과 특징을 제공한다(그림 2 참조).
 


SOTA 프로세스 및 요구되는 보안 아키텍처


일반적으로 SOTA 프로세스는 연속적인 여러 단계로 진행된다. 새로운 소프트웨어 패키지가 제작되고 보안 “래퍼(wrapper)”(암호화 및 서명)가 제공되면, 목표 차량과의 통신이 발생한다. 다음으로 차량(클라이언트)과 OEM 업데이트 서버 사이에 보안 연결이 확립된다. 차량과 서버 플랫폼은 상호 인증을 수행하고, 안전한 암호화된 전송 채널(전송 계층 보안, TLS)을 구성한다. 이 채널을 통해 차량은 새로운 소프트웨어 패키지를 수신한다.
 

초기 검증이 완료되면 차량은 중앙 메모리에 소프트웨어 패키지를 저장한다. 새로운 소프트웨어는 운전자에게 알리거나 차량의 동작에 영향을 주지 않으면서 백그라운드로 수신되고 저장된다. 실제 업데이트 과정은 차량이 안전하게 주차되어 운전자에 의해 개시될 때까지 시작되지 않는다. 소요시간은 버스 아키텍처와 중간의 저장 위치에 따라 몇 초에서 몇 분까지 다양하다.
 

SOTA를 위한 아키텍처

SOTA를 위한 자동차 아키텍처는 기본적으로 각기 다른 보안 마이크로컨트롤러가 독자적인 보안 기능을 수행하는 3개의 ECU 블록인 텔레매틱스 컨트롤러, 중앙 게이트웨이, 타깃 제어장치로 구성된다(그림 3 참조).

 


텔레매틱스 장치는 모바일 무선 인터페이스를 통해 OEM 서버에 연결되고 서비스 인증을 수행한다. 보안을 위해 이와 같은 중요한 인증 기능에는 전용 보안 컨트롤러 OPTIGA TPM(Trusted Platform Module)의 사용이 권장된다. 보통 자동차 네트워크와의 안전한 연결을 위해 실제 애플리케이션 컨트롤러 외에도 AURIX 제품군 마이크로컨트롤러가 사용된다.
 

중앙 게이트웨이의 AURIX 마이크로컨트롤러는 수신된 소프트웨어의 검증과 중간 저장을 지원한다. 보안에 핵심적인 인증 기능을 텔레매틱스 장치로부터 게이트웨이로 이동하는 것도 가능하다. 이 경우 TPM을 게이트웨이에 놓는 것을 권장한다. 이렇게 하면 중앙 키 관리와 같은 다른 중요한 보안 기능을 수행할 수 있다.


실제 업데이트는 운전자에 의해 개시된 후 목표 ECU에서 실행된다. 데이터 패키지는 메모리로부터 목표 ECU로 전송되고, 여기에서 데이터 패키지가 해독되고, 다시 한 번 검증된 다음 마침내 “실행된다”. 이러한 모든 보안 관련 기능은 AURIX 마이크로컨트롤러에 의해 지원된다.
 

“trust anchors”를 이용한 보안 인증 및 검증


위에서 설명한 바와 같이, “trust anchor”로 알려진 보안 컨트롤러는 전용 보안 기능을 수행해, 특히 안전과 관련된 중요한 애플리케이션의 업데이트가 진행되는 동안 조작과 오작동을 방지한다. OPTIGA TPM은 인증을 획득한 보안 컨트롤러로서 특히 중요한 인증 기능을 위해 사용할 수 있다. 이 컨트롤러의 역할은 인증 받은 디바이스만 차량에 데이터를 전송할 수 있도록 보장하는 데 있다.
 

TPM은 인증을 위한 모든 암호화 알고리즘을 실행한다. TPM은 이러한 목적을 위해 보호된 영역에 장기적인 인증과 개인키를 저장한다. TPM 2.0은 ECC, RSA, AES 및 SHA 256 같은 최신 알고리즘을 지원한다. TPM은 암호화해 애플리케이션 프로세서에 링크할 수 있다. TPM의 키 메모리는 확장 가능하며 애플리케이션 프로세서의 외부 메모리에 안전하게 로드할 수 있다. 따라서 OEM은 추가적인 인증서를 저장할 수 있다.
 

TPM은 최초 키를 TPM에 안전하게 저장하는 보안 인증을 획득한 제조공정으로 생산된다. 하드웨어 또는 사이드 채널 공격을 방지하는 등의 보호 레벨은 TPM이 SHE(Secure Hardware Extension) 모듈 또는 HSM(Hardware Security Module)보다 훨씬 높다. 하지만 관련된 모든 MCU는 두 가지를 모두 탑재해 연속적인(전체) 보호를 보장해야 한다.
 

전형적인 사이버 공격은 지정되지 않은 동작을 실행하는 방식으로 시스템을 조작한다. 이를 방지하기 위해 시스템은 종종 서로 다른 분리된 보안 영역으로 나누어 구성된다. 예를 들어 TPM은 별도의 보호되는 환경에 비대칭 키를 저장했다가, 암호화 절차에 이를 사용한다. 마이크로컨트롤러 역시 분리된 보안 영역을 갖는다. 일례로 AURIX 마이크로컨트롤러의 HSM은 애플리케이션 영역으로부터 보안 기능을 분리할 수 있다.
 

첫 번째 중요한 단계는 구동 사이클의 처음부터 보안 부트를 거쳐 관련된 마이크로컨트롤러의 프로그램 메모리에서 실시하는 무결성 검사이다(SHE 또는 HSM은 암호화 체크섬을 사용해 메모리 콘텐츠를 검사한다).

또한 HSM을 내장한 AURIX 마이크로컨트롤러 제품군은 수신된 소프트웨어에 대한 핵심적인 검증을 수행한다. 검증 과정은 HSM의 강력한 암호화 액셀러레이터와 빠른 통신 버스를 활용해 신속하게 실행된다. 이 검증은 게이트웨이 MCU에서 HSM을 사용해 수행한다. 펌웨어 검증은 공인인증서만 사용하므로 보안 요구사항은 인증 과정보다 낮다.
 

SOTA와 관련하여 온디맨드 무결성 검사에도 HSM을 사용할 수 있다. 이 예에서 텔레매틱스 장치와 게이트웨이는 둘 다 무결성 상태를 안전하게 교환한 다음에만 소프트웨어 업데이트를 시작한다. 유사한 절차를 목표 ECU에 구현할 수 있다. 목표 ECU도 HSM을 사용하지만, 보안 플래시 부트로더(secure flash bootloader, SFBL)가 업데이트 수신과 검증을 담당한다. 플래시 부트로더(flash bootloader, FBL)와 SFBL의 차이는 추가적인 암호화 알고리즘에 있다. 부트로더 자체는 모든 SOTA 업데이트 과정에서 제외된다. 자동차는 주행 중에 공격받을 수 있으므로 애플리케이션 소프트웨어에 대한 신속한 검사는 HSM이 SHE 모듈에 대해 갖는 주요한 장점이다.

 

고객 수용성 높이는 가용성 극대화


SOTA 통합의 보안과 안전 측면과는 별도로, 자동차의 기존 시스템 아키텍처에 미치는 영향을 최소화하고 차량의 최대 가용성을 보장해 차량 운행을 정지시켜야 하는 업데이트 시간을 최소화하는 것은 자동차 제조업체에게 매우 중요한 사항이다. 이러한 점에서 기존 온보드 네트워크 아키텍처와 ECU 레벨에서 갖는 특수한 요구사항은 특별히 주목할 필요가 있으므로 살펴보기로 한다.
기존에 ECU(또는 전체 차량)를 재프로그래밍하는 것은 차고에 자동차가 들어가는 것을 의미했다.
 

이러한 종류의 업데이트는 온보드 진단(OBD) 소켓에 꽂는 진단 툴을 사용한다. 진단 툴은 완전한 업데이트 과정을 관리하는데, 특히 새로운 소프트웨어 또는 서비스 팩의 다운로드와 목표 ECU로 이동 및 최종적인 검증을 수행한다. OEM은 가능한 SOTA에도 이와 유사한 메커니즘을 원한다. 따라서 SOTA의 경우, 진단 툴의 기능을 온보드 아키텍처의 중앙 지점으로 옮기고, 추가적인 SOTA 과정에 필요한 기능을 제공할 필요가 있다. 이러한 기능은 보통 게이트웨이 ECU 내부에서 실행된다. 새로운 소프트웨어 패키지가 OEM 서버로부터 다운로드되면 여기에서 일시적으로 중앙 메모리에 저장된다.
 

새로운 소프트웨어는 게이트웨이의 중앙 메모리로부터 목표 ECU로 이동해야 하므로, OEM이 채택하는 각기 다른 네트워크 토폴로지를 고려해야 한다. 기본적으로 3가지 접근방법이 있다(그림 4 참조).
 

 

개별적인 ECU를 업데이트하는 “기존” 방법에서는 관련된 새로운 소프트웨어 패키지를 중앙 메모리로부터 온보드 네트워크를 통해 목표 ECU의 마이크로컨트롤러에 내장된 플래시 메모리로 로드한다. 이 과정은 단일 단계로 수행된다. ECU와 관련해 하드웨어 변경은 필요 없다. 주요 제한은 버스 속도로서 업데이트에 소요되는 시간을 결정한다.

표 1은 일반적인 버스 시스템의 데이터 속도를 보여준다. 표에서 보듯이 4 MB의 서비스 팩을 가정하면 하나의 ECU를 CAN 버스를 통해 업데이트하는 데 거의 5분이 소요된다. 20개 ECU를 업데이트할 경우 차량은 1시간 반 이상 그대로 있어야 한다. 처리 속도를 증가시키는 여러 가지 방법이 있지만(CAN 버스 서브 도메인 클러스터링 또는 데이터 압축 등), 모두 복잡성과 비용을 증가시킨다.
 

 


A/B 스왑 


또 다른 방법은 A/B 스왑이다. 마이크로컨트롤러 내부에는 코드를 실행하기 위해 플래시 메모리에 2개의 블록(A와 B)이 있다. 백그라운드에서 중앙 메모리로부터 목표 ECU로 소프트웨어를 다운로드하고 메모리 프리 청크(free chunk, 블록 B)를 재프로그래밍하는 동안 차량을 이용할 수 있으므로 소요 시간에 구애받지 않는다. 블록 A는 영향을 받지 않기 때문에 현재의 코드를 실행하는 데 계속 사용할 수 있다.
 

이러한 방식으로 모든 ECU가 “사전 프로그래밍" 되면, 컨트롤러가 코드 실행을 블록 A에서 블록 B로 스위칭한다. 스왑 과정은 재시작 후 최종적으로 완료된다. 이 방법은 실질적으로 다운 시간이 없다는 점에서 큰 이점을 갖는다. 단점으로는 더 많은 플래시 메모리가 필요하고 기능 안전에 미치는 영향을 제거하기 위한 추가적인 검증 메커니즘으로 인한 비용 상승을 들 수 있다. 또한 아직 많은 마이크로컨트롤러가 “스와핑”을 지원하지 않는다.

세 번째 방법은 앞의 두 방법의 장점을 결합하는 방법으로, “ECU 레벨에 외부 메모리”를 추가한다. 새로운 서비스는 자동차를 사용하는 동안 백그라운드에서 이 “ECU 레벨의 외부 메모리”에 로드되며, 실제 업데이트 과정이 완료될 때까지 여기에서 기다린다. 이 방법은 AURIX 제품군과 같은 최신 마이크로컨트롤러가 매우 신속하게 플래시 메모리를 지우고 재프로그래밍하는 높은 성능을 이용한다. 예를 들어 4 MB를 외부 로컬 메모리로부터 SPI 인터페이스를 통해 지우고 재프로그래밍하는 데 8초가 채 걸리지 않는다. 이 방법의 주요 이점으로 기존 시스템 설계에 대한 간섭 최소화, 합리적인 수준의 추가 비용, 소형 크기의 추가되는 메모리 등을 들 수 있다. 표 2는 세 가지 방법을 비교해 보여준다.
 

 


결론
 


자동차 소프트웨어의 무선 업데이트 기능은 자동차 업계에 대폭적인 비용 절감을 약속한다. 하지만 자동차 및 안전에 중요한 애플리케이션에 불법적인 접근을 방지하려면 적절한 보안 조치를 갖춰야 한다. AURIX 마이크로컨트롤러와 함께 핵심적으로 중요한 지점에 OPTIGA TPM 같은 추가적인 전용 보안 컨트롤러를 사용한다면, SOTA를 안전하게 보호하는 데 최적화된 기능을 제공할 수 있다. 특정 보안 조치와 별도로, OEM은 이러한 최적화된 네트워크 아키텍처와 메모리 전략을 통해 업데이트 과정 동안 자동차의 다운타임과 운전자에 미치는 영향을 최소화하는 방안을 고려할 필요가 있다.
 



 

<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인


TOP