차량용 Secure OTA 네트워크 프로토콜 연구

2.1 MQTT

MQTT(Message Queuing Telemetry Transport)는 발행/구독(Publish and subscribe) 기반의 메시지 큐잉 프로토콜이다. 이 프로토콜은 특정 ‘주제(Topic)’를 중심으로 메시지가 발행되며, 해당 주제를 구독하고 있는 수신자들이 이 메시지를 받는다. MQTT의 가장 큰 장점 중 하나는 그것의 가벼운 구조로, 이는 낮은 대역폭과 제한된 리소스 환경에서도 효율적인 통신을 가능하게 한다. 이러한 특성은 IoT 환경에서 특히 유용하다.

MQTT는 0, 1, 2의 세 가지 수준의 QoS(Quality of Service)를 제공하여 메시지 전송의 신뢰성을 보장한다. QoS 0(At most once)는 메시지가 한 번만 전송되며, 전달 여부를 보장하지 않는다. QoS 1(At least once)는 메시지가 적어도 한 번 전달되도록 보장하며, QoS 2(Exactly once)는 메시지가 정확히 한 번만 전달되도록 보장한다. 이러한 다양한 QoS 수준을 통해 MQTT는 다양한 통신 환경 및 요구 사항에 맞춰 메시지 전달의 신뢰성을 조절할 수 있다.

MQTT의 성능이 빠른 이유는 그것의 경량화된 프로토콜과 메시지 구조 때문이다. MQTT 메시지는 헤더가 매우 간단하고, 메시지 전송에 필요한 추가적인 오버헤드가 적다. 이는 HTTP와 같은 더 복잡한 프로토콜에 비해 상대적으로 낮은 네트워크 대역폭을 사용하며, 더 빠른 메시지 전송을 가능하게 한다.

보안이 중요한 환경에서는 TLS(Transport Layer Security)를 적용한 MQTT를 사용하여 안전성을 확보할 수 있다. TLS를 적용함으로써, 메시지가 암호화되어 전송되며, 이는 데이터 무결성과 기밀성을 보장한다. 비록 TLS 적용 시 일정 수준의 오버헤드가 발생하나, MQTT의 경량화된 구조 덕분에 HTTPS보다 여전히 빠른 성능을 제공한다.

2.2 Merkle Tree

머클 트리는 블록체인 기술에서 중요한 역할을 하는 데이터 구조이며, 이진 트리(Binary tree) 형태를 취한다. 이 트리의 각 노드는 자신의 자식 노드들의 값들을 해싱(Hashing)하여 얻은 결과값을 저장한다. 이러한 방식으로, 머클 트리는 각 노드의 무결성을 보장하며, 전체 데이터 구조의 일관성을 유지한다.

펌웨어 업데이트 과정에서 머클 트리를 활용할 경우, 먼저 모든 펌웨어 파일을 작은 청크(Chunk)로 읽어와, 해시값을 계산한다. 이 해시값들은 머클 트리의 리프 노드(Leaf node)를 형성하며, 상위 노드는 이들 리프 노드의 해시값들을 다시 해싱하여 그 결과를 저장한다. 이 과정은 트리의 최상위 노드인 루트(Root)에 도달할 때까지 반복된다.

머클 트리의 강력한 특징 중 하나는, 단 하나의 데이터 청크가 변경되어도 이는 전체 트리에 영향을 미친다는 점이다. 즉, 하나의 청크의 데이터나 해시값이 바뀌면, 이는 해당 청크를 포함하는 모든 상위 노드의 해시값 변경으로 이어진다. 결국 루트 노드에 저장된 루트해시(Root hash)도 변경되어, 데이터의 변경이나 조작을 쉽게 감지할 수 있다. 이러한 특성 덕분에, 머클 트리는 펌웨어 업데이트 과정에서 펌웨어의 무결성과 신뢰성을 효과적으로 보장하는 데에 큰 역할을 한다.

2.3 Scope

본 연구는 SecureOTA의 세 가지 핵심 영역인 엔드 디바이스의 보안, 펌웨어 업데이트 방식, 그리고 통신 프로토콜 중에서 특히 통신 프로토콜에 대한 접근 방식에 중점을 두고 있다. 이 연구는 네트워크 보안성 확보에 중점을 두고 진행되었으며 엔드 디바이스에서의 보안은 HSM을 통해 확보 된다고 가정한다.

따라서 MQTT와 HTTP 통신 프로토콜에 TLS(Transport Layer Security)를 적용하여 두 프로토콜의 장점을 활용하며 네트워크 보안을 강화하는 첫 단계로 삼는다 TLS의 사용은 데이터전송 과정에서의 암호화를 통해 데이터의 기밀성과 무결성을 보장한다. 추가적으로, 본 연구에서는 머클 트리(Merkle tree)를 활용하는 방법도 고려한다. 머클 트리는 네트워크를 통한 데이터 전송 과정에서 데이터가 손상되거나 변경되었을 때 이를 효과적으로 감지할 수 있는 구조이다. 각 데이터 블록의 해시가 트리의 노드로 구성되며, 이 해시들은 상위 노드로 집계되어 전체 트리의 무결성을 나타낸다.

따라서, 이 연구에서는 MQTT와 HTTPS 프로토콜을 결합하여 사용함으로써, 두 프로토콜의 장점을 활용한다. 이러한 결합은 네트워크 보안을 강화하는 첫 단계이다. 이어서, TLS를 적용하여 데이터 전송 과정에서의 암호화를 통해 보안을 더욱 강화한다. TLS는 데이터의 기밀성과 무결성을 보장하는 중요한 역할을 한다.

그러나 보안 시스템은 언제나 잠재적인 위협에 노출되어 있으며, TLS가 손상될 가능성도 배제할 수 없다. 이러한 상황에 대비하여, 본 연구에서는 머클 트리를 추가적인 보안 수단으로 활용한다. 머클 트리는 네트워크를 통한 데이터 전송 과정에서 데이터가 손상되거나 변경되었을 때 이를 효과적으로 감지할 수 있는 구조이다. 만약 TLS 보안이 어떤 이유로든 뚫리게 되면, 머클 트리를 통해 데이터의 무결성을 검증하고, 손상되거나 변경된 데이터를 신속하게 감지할 수 있다. 특히 통신 프로토콜의 보안 강화 방법에 대한 심도 있는 분석과 개선 방안을 모색하는 데 그 목적이 있으며 이와 같은 방식으로, 본 연구는 SecureOTA의 구현에 있어서 통신 프로토콜의 보안 강화에 초점을 맞추며, 네트워크를 통한 데이터 전송 과정에서 발생할 수 있는 다양한 보안 위협에 대응할 수 있는 강력하고 포괄적인 보안 체계를 제안한다.

3.1 통신의 신뢰도 및 데이터 전송 효율성 연구

기존의 연구들 중 일부는 P2PMesh 아키텍처를 이용한 업데이트 시스템을 제안하고 있다.⁷⁾ 이와 더불어 펌웨어 파일을 슬라이싱하여 MQTT를 통해 전송하는 OTA 업데이트를 하거나,⁸⁾ 비보안 MQTT 통신에 대하여 256비트 대칭 암호화 알고리즘을 사용하여 MQTT 프로토콜의 보안을 강화하는 연구가 진행되어 왔다.⁹⁾ 그러나 이러한 P2P 기반 연구들은 기존 프로토콜이 제공하는 인증 수준을 충분히 고려하지 않았기 때문에, 정보 유출과 같은 보안 문제를 야기할 수 있다.

이러한 문제점을 해결하기 위해 TLS를 적용한 MQTT를 사용한다.¹²⁾ 특히, 특정 Topic을 구독할 때는 최소한의 인증 절차를 구현하여 보안을 강화하였다. MQTT를 사용하여 펌웨어 파일을 슬라이싱 하는 방식은 데이터 손실 또는 펌웨어 파일의 무결성 손상의 위험이 있을 수 있다. 따라서, 본 연구에서는 이러한 위험을 방지하기 위해 업로드된 펌웨어 파일의 위치를 JSON 형태의 URL 주소로 제공함으로써, 펌웨어 파일의 무결성을 유지하고 데이터 손실을 방지한다.

3.2 보안성 강화 연구

블록체인을 이용한 OTA(Over the Air) 업데이트 관련 연구는 제조업체 중심의 중앙집중형 방식을 벗어나 탈 중앙화 접근 방식을 모색하고 있다.¹⁰⁾ 이러한 연구들 중 일부는 제조업체 대신 분산 데이터베이스 시스템을 통해 IoT 장치의 펌웨어를 직접 다운로드하는 방법을 탐구한다. 또한 해시 테이블과 공개 블록체인을 이용하여 OEM의 펌웨어 무결성과 신뢰성을 보장하는 연구도 진행되고 있다.¹¹⁾ 특히, 지속적인 업데이트가 필요한 펌웨어의 경우, 블록체인 기술을 활용함으로써 무결성과 신뢰성을 효과적으로 보장할 수 있다. 그러나 이러한 접근법은 벤더사의 분산 구조화를 필요로 하며, 이로 인해 분산된 노드의 안전성을 보장하기 위해 상당한 노력과 시간이 소요된다는 문제가 있다.

이러한 문제에 대응하기 위해 중앙집중형 방식을 유지하면서도 머클 트리(Merkle tree)를 활용한다. 머클 트리를 사용함으로써, 펌웨어의 신뢰성과 무결성을 보장할 수 있으며, 동시에 중앙집중형 구조의 효율성과 안정성을 유지할 수 있다. 이러한 접근 방식은 블록체인 기반의 탈 중앙화 방식이 요구하는 복잡성과 비용을 줄이면서도, 펌웨어 업데이트 과정에서 요구되는 높은 보안 수준을 달성할 수 있는 장점을 가진다.

4.1 펌웨어 업로드

무단 업로드나 변조를 방지하기 위해, 인증 및 인가 권한을 가진 특정 MCU를 담당하는 부서가 펌웨어 파일을 업로드하는 과정을 채택하고 있다. 이는 펌웨어의 안전한 관리와 보안을 확보하는 데 중요한 역할을 한다. 업로드된 펌웨어 파일은 서버에 저장되며, 서버는 저장된 모든 MCU의 펌웨어와 함께 머클 트리를 생성한다. 이 머클 트리는 서버에서 구현되며, 각 펌웨어 파일의 해시값과 루트 해시를 데이터베이스에 저장한다. 이러한 구조는 펌웨어의 무결성과 신뢰성을 확인하는 데 매우 중요하다.

4.2 펌웨어 발급

블록체인 기반 SOTA 접근 방식과는 달리, 본 연구에서는 머클 트리를 활용한 중앙집중식 네트워크 아키텍처를 도입한다. 이를 통해 발생할 수 있는 보안 위협을 최소화하기 위해, 본 시스템은 업로드 관리자와는 별개로 업데이트를 담당하는 관리자를 두어 접근 제어를 강화함으로써 보안성을 향상시킨다. 이 관리자는 MQTT 프로토콜을 이용하여, 차량이 구독하고 있는 Topic에 대한 신규 펌웨어의 해쉬값, 루트 해쉬값, 버전 정보, 파일 위치 등을 발행한다.

Topic에 대한 접근 인증을 위해 사용되는 키는 일반적으로 사용자 아이디와 비밀번호 형태를 취하며, 이러한 중요한 인증 정보는 보안성이 높은 HSM과 같은 안전한 저장 매체에 보관된다. HSM은 높은 수준의 보안을 제공하여, 키 정보가 외부로 유출되거나 타인에 의해 접근되는 것을 방지한다. 이러한 방식으로, 차량은 안전하게 MQTT 서버에 연결되며, 구독 중인 Topic에 대한 접근 권한을 확보하게 된다.

펌웨어 정보의 전송 및 업데이트 과정은 이와 같이 강화된 보안 메커니즘을 통해 높은 수준의 보안과 신뢰성을 유지한다. 이는 차량이 신뢰할 수 있는 출처로부터만 펌웨어 업데이트를 받도록 보장하며, 시스템을 무단 접근 및 악의적인 공격으로부터 보호한다.

4.3 차량 내 펌웨어 다운로드 및 검증 절차

차량 내의 Gateway 역할을 수행하는 Jetson Orin은 MQTT 프로토콜을 통해 펌웨어의 URL 주소를 수신한다. 이 주소를 사용하여, HTTP의 확장성과 신뢰성에 기반해 TLS를 통해 펌웨어를 안전하게 다운로드 받는다. 다운로드는 차량의 임시 디렉토리에 이루어지며, 이때 데이터 손실의 위험이 최소화된다.

다운로드된 펌웨어 파일은 4096바이트 크기의 청크로 나누어 읽혀지고, 각 청크에 대해 SHA-256 해시 알고리즘을 사용하여 해시 값을 계산한다. 이 과정은 펌웨어 파일의 무결성을 확인하는 데 중요하다. 계산된 해시 값은 이후 MQTT를 통해 전송받은 원본 펌웨어 파일의 해시 값과 비교되어, 펌웨어의 정확성을 검증한다.

GateWay는 평상시에 차량의 네트워크 환경을 모니터링하며, 새로운 펌웨어 업데이트가 가능할 때 해당 정보를 수신하고 처리한다. 이는 주기적으로 서버와의 통신을 통해 최신 펌웨어 업데이트의 존재를 확인하는 과정을 포함한다. 이러한 방식으로, 차량의 펌웨어가 항상 최신 상태를 유지하도록 보장하며, 차량의 보안과 성능을 지속적으로 강화한다.

4.4 차량의 펌웨어 동기화 및 저장 절차

4.3절에서의 검증 과정을 성공적으로 마친 후, 차량의 Secure storage에서는 각 펌웨어 파일을 머클 트리의 리프 노드로 취급하여 처리한다. 즉, 차량에 보관된 모든 펌웨어 파일은 각각 머클 트리의 하나의 리프 노드에 해당하며, 이들 각각의 해시값을 계산하여 트리에 저장한다. 이러한 방식으로 머클 트리를 구성하고, 모든 리프 노드의 해시값을 결합하여 상위 노드의 해시값을 순차적으로 계산해 나간다. 이 과정은 루트 노드에 도달할 때까지 계속되며, 최종적으로 생성된 루트 해시는 차량에 보관된 모든 펌웨어 파일의 무결성을 대표한다. 차량에서 계산된 루트 해시는 서버에서 받은 루트 해시와 비교되며, 일치함을 확인하면 신규 펌웨어는 Secure storage 내 적절한 위치에 저장된다. 이러한 절차는 차량의 펌웨어 시스템이 안전하고 무결한 상태를 유지하는 데 중요한 역할을 한다.

4.5 펌웨어 업데이트

최종적으로 차량의 펌웨어 업데이트는 차량이 안전하게 정차된 상태를 확인한 후에 진행된다. 이는 실제 운행 상황에서 펌웨어 업데이트가 차량의 운행에 영향을 주지 않도록 보장하기 위함이다. 본 논문의 시나리오에서는, 차량 내에 설치된 Jetson Orin이 중앙 제어 장치로서의 역할을 하며, 아두이노 CLI(Command Line Interface)를 사용하여 아두이노 기반의 MCU에 펌웨어를 업로드 한다.

단지 구현의 용이성과 접근성을 고려한 선택으로 Jetson Orin을 사용하여 아두이노 기반의 MCU에 펌웨어를 업로드하는 방식을 채택했다.이 과정에서 GateWay는 먼저 안전한 네트워크 연결을 확인하고, Secure storage에서 검증된 신규 펌웨어를 불러온다. 그 후, MCU로 펌웨어를 전송하며, 이 과정은 특별히 설계된 스크립트나 명령어 세트를 통해 자동화될 수 있다. 펌웨어 업로드가 완료되면, GateWay는 업데이트의 성공 여부를 확인하고, 필요한 경우 추가적인 후처리 작업을 수행한다.

이러한 접근 방식은 차량의 펌웨어 업데이트 과정을 안전하고 신뢰할 수 있게 하며, 차량의 성능과 신뢰성을 유지하는 데 기여할 수 있을 것이다.

5.1 보안성 검증

먼저, Table 1은 OTA 프로토콜을 통해 발생할 수 있는 대표적인 공격은 크게 4가지로 정의하였다. Dos/DDoS 공격은 시스템의 자원을 고갈시켜 서비스 접근을 차단하는 방식으로 작동한다. MITM 공격에서는 공격자가 통신 과정에서 메시지를 변조하거나 가로챈다. Spoofing은 공격자가 다른 사용자나 시스템으로 위장하여 불법적으로 통신을 수행한다. Duplicated update 공격은 공격자가 이미 전송된 업데이트 패킷을 캡처하여 다시 전송함으로써 시스템을 혼란시키려는 공격 유형이다. MQTT프로토콜의 특성상, 이러한 공격에 대한 취약성이 있을 수 있다. MQTT는 경량 메시징 프로토콜로, 효율적인 데이터 전송을 위해 설계되었지만, 기본적으로 메시지의중복 전송을 자동으로 감지하고 처리하는 메커니즘을 포함하지 않는다.

Table 1

Mqtt(wtih TLS) + Merkle trees

이러한 특성 때문에, MQTT를 사용하는 시스템에서는 중복된 업데이트 메시지가 원본 메시지로 오인되어 처리될 위험이 있다. 예를 들어, 공격자가 펌웨어 업데이트 메시지를 캡처하고 이를 다시 시스템에 전송한다면, 시스템은 이미 적용된 업데이트를 새로운 것으로 인식하고 재적용할 수 있다. 이는 불필요한 리소스 소모, 시스템의 불안정성 증가, 심지어는 오작동을 초래할 수 있다.

TLS를 사용하게 되면 Spoofing과 MITM 공격에 대해서는 암호화와 인증서를 통해 신원을 검증할 수 있어 이러한 공격에 대응할 수 있다. 만약 업데이트 패킷을 캡처하여 재전송하는 중복 업데이트 공격을 시도한다면, 머클 트리를 이용한 무결성 검증으로 이를 방어할 수 있다. 그러나 서비스 거부 공격(Denial of Service, DoS)의 경에는 본 연구에서 제안한 방법으로는 방어할 수 없으며, 추가로 방화벽이나 DDoS 대응 기술이 필요하다.

5.2 성능 검증

Fig. 2에서 보여주는 성능 측정 결과는 총 10번의 독립적인 트랜잭션을 수행한 후, 이들의 평균 레이턴시를 계산하여 얻어졌다. 실험 환경은 서버 측에서 스프링 부트를 활용하고 클라이언트 측에서는 파이썬을 사용하여 구성되었다. 이러한 시스템은 100 Mbps의 대역폭을 갖는 공유기를 통해 네트워크 환경을 설정하였다. 실험에 사용된 각 트랜잭션은 4.2절에서 설명한 바와 같이, OTA에 필요한 정보를 JSON 형식으로 변환한 데이터를 기반으로 진행되었다.

Fig. 2

Average Latency for HTTPS and MQTT

HTTPS를 사용했을 경우, 평균 레이턴시는 0.467초로 측정되었다. 반면, TLS가 적용된 MQTT를 사용했을 때는 평균 레이턴시가 0.116초로, HTTPS 대비 약 4배 빠른 성능을 보였다. 이는 보안 요구사항을 충족하면서도 성능을 향상시킬 수 있음을 시사한다. 그러나 TLS가 적용되지 않은 MQTT의 경우 평균 레이턴시가 0.0092초로 가장 빠르나, 보안이 중요한 환경에서는 적합하지 않을 수 있다는 점을 감안해야 한다.

이러한 결과들을 통해 OTA 프로토콜을 구현하는 경우, HTTPS만을 사용하는 것보다는 TLS를 적용한 MQTT를 함께 사용하는 것이 성능 측면에서 상대적으로 우수함을 알 수 있다. 보안과 성능이라는 두 가지 중요한 요소를 모두 고려할 때, MQTT with TLS의 사용이 HTTPS를 사용하는 것보다 효과적인 대안으로 제시될 수 있다.