모든 것들이 스스로 움직이고 끊김 없이 연결된 세상을 만든다

42dot에서는 모든 것들이 스스로 움직이게 하기 위해서 자율 주행 제어 장치를 개발하고 있습니다. 이 장치는 다양한 센서(카메라, 레이더 등)를 활용해서 주변 상황을 인지/판단하고 지도/측위 기술 등을 조합해서 주행 경로에 따라 장치 스스로 조향 각과 가감속과 같은 다양한 이동 과정의 제어를 수행합니다.

자율주행 장치의 이동을 비용 효율적, 안정적으로 보장하기 위해서는 장치를 구동 시키는 운영 체제 및 애플리케이션들을 빠르고 지속적으로, 원격에서 신규 기능 적용뿐만 아니라 성능 개선, 버그 수정, 보안 패치 등의 소프트웨어 업데이트가 끊김 없이 이루어져야 가능합니다. 이것은 OTA 업데이트 기술을 통해 지속 가능하게 할 수 있습니다.

OTA(Over-the-air)?

Software 및 firmware를 update 하는 방식 중에 하나로, update를 하기 위해 유선으로 host machine에 연결하지 않고 무선으로 원격지의 device를 update 하는 방식입니다. OTA 방식에 따라 SOTA(Software-over-the-air)와 FOTA(Firmware-over-the-air)로 나누기도 하는데, 보통 SOTA는 다양한 software component들을 대상으로 하고 있고, FOTA는 특정 device에 국한된 update 방식으로 볼 수 있습니다.

1. OTA 업데이트 기술은 안정성과 보안이 핵심

잘못 설치되거나 네트워크 전송 오류로 인해 일부 파일 내용이 손상된 OTA 업데이트는 장치를 동작하지 않는 “벽돌"로 만들어서 이용자에게 상당한 불편을 초래할 뿐만 아니라 장치 공급자에 대한 평판 및 금전적인 손상까지 이어질 수 있습니다.

해커가 OTA 서버에 중간자 공격(man-in-the-middle attack) 통해 자율주행 제어 장치의 주요 운영체제 모듈 및 애플리케이션들의 바이너리를 확보하고 리버스 엔지니어링을 통해 악의적인 목적으로 위변조 된 소프트웨어를 해당 장치에 다시 배포할 수 있습니다. 또한 알려진 소프트웨어 보안 취약점을 악용해서 해당 장치에 원격으로 침입하여 민감한 데이터를 훔치거나 물리적인 자율 주행 이동의 제어권을 장악할 수 있습니다.

중간자 공격(Man-in-the-middle attack)?

네트워크 통신을 조작하여 통신 내용을 도청하거나 조작하는 공격 기법이다. 중간자 공격은 통신을 연결하는 두 사람 사이에 중간자가 침입하여, 두 사람은 상대방에게 연결했다고 생각하지만 실제로는 두 사람은 중간자에게 연결되어 있으며 중간자가 한쪽에서 전달된 정보를 도청 및 조작한 후 다른 쪽으로 전달합니다. 예를 들어, 위 그림처럼 해커가 클라우드에 연결된 차량의 모뎀에 가짜 기지국 연결과 같은 중간자 공격을 통해 셀룰러 통신 데이터를 가로채기 및 위변조가 가능합니다.

OTA 업데이트 기능의 3가지 필수 사항

1. 전원 및 네트워크로 인한 오류 발생 시 이전 안정화 버전 롤백

자율 주행 장치는 이동을 제어하기 위한 목적의 장치이므로 네트워크 연결 및 전원 공급의 불량으로 인해 업데이트가 실패 되면 이전 안정화 버전으로 돌아가는 롤백 기능이 기본적으로 제공되어야 합니다.

Dual A/B 파티션 전략을 이용하면 비활성 루트 파일 시스템 파티션에 변경된 소프트웨어 업데이트 파일들을 설치하고 재부팅 이후에 부트로더가 해당 파티션에서 부팅 되도록 구성하는 방식으로 가장 안정적이고 빠른 롤백 기능 구현이 가능합니다.

2. 변경된 부분만 다운로드하고 패치(Delta 업데이트 지원)

네트워크 대역폭이 제한된 환경에서 기가 단위인 대용량 자율주행 운영체제를 포함한 소프트웨어를 배포해야 하는 경우 해당 장치의 배터리 전력이 빠르게 소모되거나 네트워크 사용 비용 증가 등 여러 가지 문제점이 발생할 수 있습니다. 따라서 OTA 업데이트를 진행할 파일의 크기와 시간, 네트워크 대역폭을 크게 절약할 수 있는 변경된 부분만 업데이트하는 Delta 업데이트 기술 메커니즘 도입이 필요합니다.

3. 가짜 OTA 업데이트 요청 거부 및 위변조된 소프트웨어 배포 방지

신규로 설치될 소프트웨어는 설치 대상 기기의 고유한 하드웨어 식별자와 인증서 기반의 공개키로 상호 인증된 장치에서만 다운로드 및 설치되어야 합니다. 추가적으로 암호화 및 코드 사이닝 적용을 통해서 설치 대상 소프트웨어(bootloader, kernel, root filesystem 등) 무결성을 보장하고 주요 애플리케이션 파일 및 데이터 위변조 공격으로부터 보호해야 합니다.

자율주행 장치와 클라우드 간에 종단 간(E2E) 암호화 통신을 위한 secure channel을 통해 클라우드 서버와 상호 인증된 자율 주행 장치만의 네트워크 통신만 허용해서 외부 공격을 원천적으로 차단하고 장치 내에서 외부로 나가는 통신을 지속적으로 모니터링하여 비정상적인 네트워크 연결 트래픽이 있는지 모니터링해야 합니다.

Safe and Secure Over-the-air(SOTA) Software Update

1. 소개

42dot은 모든 장치에 쉽고, 빠르게, 안정적이고 안전한 소프트웨어 업데이트 적용 및 운영이 가능하게 해 주는 SaaS 형태의 솔루션을 자체 개발하고 있습니다. 등록된 모든 장치의 소프트웨어 배포 작업은 원격에서 중앙 통합 관리되며, 다음과 같은 주요 기능을 제공해서 안정적이고 안전한 OTA 소프트웨어 구현의 핵심 기술을 대상 장치에 빠르고 손쉽게 적용이 가능합니다.

2 주요 기능

2.1 공개키(PKCS#11) 기반의 장치 등록 및 인증

솔루션에 연결을 위한 장치를 프로비저닝 하려면 장치 / 서버 간 상호 인증서(x.509)와 private key를 생성하고 전자 서명 유효성 체크해야 합니다. 이때 생성된 장치 인증서와 private key는 하드웨어 방식인 HSM (Hardware Security Module) 또는 소프트웨어 방식인 ARM TrustZone 기술을 사용해서 TEE(Trusted Execution Environment)와 같은 안전한 영역에 대상 장치에 주입하고 장치 등록 및 인증을 하기 위한 CLI 프로비저닝 도구를 제공합니다.

TrustZone?

TrustZone은 ARM에서 개발한 ARMv6 이상의 CPU에서 추가된 보안 확장 집합인데 CPU, 주소 공간, 메모리를 하드웨어 단위로 분리하여 기밀성과 무결성을 제공할 수 있는 보안 및 비 보안으로 격리된 환경을 제공하는 기술입니다.

42dot은 PKCS#11과 OP-TEE OS를 조합한 소프트웨어 방식으로 private key나 인증서를 TEE 영역에서 저장하고 다양한 암복호화 및 서명 알고리즘을 사용하는 방식을 제공함으로써, 일반적으로 I2C 또는 SPI 인터페이스를 통해 메인 프로세스에 연결된 전통적인 하드웨어 방식의 전용 보안 칩셋이 필요하지 않습니다.

또한 다양한 3rd-party 벤더가 제공하는 PKCS#11 인터페이스를 지원하는 HSM/Secure elements 등의 하드웨어 보안 엔진들을 OpenSSL로 추상화해서 SDK나 agent에서 사용 가능합니다.

PKCS#11?

PKCS#11(공개 키 암호 표준 #11)은 키(RSA, 대칭 키, 타원 곡선 암호화), 인증서(X.509) 와 같은 암호화 객체 관리를 위한 API를 지정하는 표준으로써 PKCS#11은 물리적인 장치의 특성에 관계없이 애플리케이션과 암호화 장치 간의 표준 인터페이스를 제공합니다.

2.2 Dual Copy(A/B) 및 Delta 업데이트 지원

소프트웨어 업데이트 실패 시에 이전 상태로 복원이 빠르게 가능하도록 Dual copy(A/B)를 유지하는 방식을 지원합니다. 이 방식은 A라는 루트파일시스템이 booting 상태에서는 B라는 루트 파일시스템 또는 B라는 루트 파일시스템으로 booting 상태에서는 A라는 루트 파일 시스템 전체를 업데이트하는 방식으로, 업데이트 프로세스 중에 배포가 불완전하거나 손상된 경우에 장치를 수 초 안에 빠르게 복구할 수 있는 장점이 있습니다.

추가로 시스템 수준의 부트로더, 커널 및 각종 드라이버 루트 파일시스템 포함해서 신규로 업데이트되는 버전과 이전의 stable 버전 간의 바이너리 차이만 교체하는 Delta 업데이트를 지원합니다.

2.3 중앙에서 원격 업데이트 진행 상황 및 장치 상태 모니터링

웹 UI 또는 REST API를 사용하여 운영자가 장치 이름, 유형 및 제조 연도, 인증서 및 액세스 정책과 같은 장치 속성 관리가 가능하며, 단일 장치 또는 장치 그룹으로 구성해서 해당 그룹에 대한 계층 구조로 액세스 및 업데이트 배포 정책 설정해서 운영할 수 있습니다.

2.4 안전한 네트워크 통신을 위한 Secure Channel 지원

솔루션에 접속하는 모든 장치는 자체 구축된 PKI를 통해 발급된 자격 증명(X.509 인증서) 기반해서 디바이스 간에 주고받는 네트워크 프로토콜(MQTT, HTTPS) 트래픽을 장치와 서버와의 Mutual TLS 을 이용한 종단 간 암호화를 통해 안전하게 전송합니다.

mTLS (mutual TLS)?

mTLS는 서버와 클라이언트 간 상호 인증의 방법 중에 하나이며, 서버 클라이언트 모두 인증서가 있고 양쪽 모두 private key 쌍을 사용하여 인증합니다. 일반적인 TLS 와 비교하여 mTLS는 양 당사자를 확인하는 단계가 추가된 형태입니다.

2.5 Artifact 파일 서명 및 암복호화 지원

대상 장치에 전달된 업데이트가 신뢰할 수 있는 소스에서 온 것인지, 아니면 해커 혹은 악성코드에 의해 위변조 되지 않았는지 무결성을 확인할 수 있는 기능을 제공합니다.

빌드 서버에서 생성된 artifact 파일은 CLI 도구로 배포시 마다 private key와 public key가 신규로 만들어지고, 생성된 private key로 서명된 artifact 파일과 public key가 함께 서버에 업로드됩니다.

이후 OTA 업데이트 시 클라이언트는 서버에서 public key와 서명 값을 전달받고 다운로드 되는 이미지의 서명 체크를 통해 설치 대상 파일들의 위변조 여부를 확인할 수 있습니다.

이러한 서명 확인 절차를 통과하면 클라이언트는 해당 OTA 업데이트가 신뢰할 수 있는 소스에서 온 것으로 간주하고 다운로드 된 소프트웨어 설치를 진행합니다.

그리고 CBC 모드에서 AES 블록 암호를 사용하여 artifact 파일을 대칭적으로 암호화된 이미지로 배포해서 Artifact 위변조 공격을 방어하는 기능을 지원합니다.

2.6 Chain of Trust 기반의 Secure Booting

Secure boot는 De-face 공격(펌웨어 및 구동 페이지 변조로, 해킹 당한 표시 및 오작동을 일으키는 방식), 소프트웨어 업데이트 및 펌웨어 변조 공격 등에 대한 효과적인 대비 방법으로 CPU -> Bootloader -> Kernel -> Root FileSystem(RootFS)의 순서로 각각의 시그니처 & 무결성 정보를 확인하고, 설치된 이미지에 변조가 없다면 정상적으로 부팅이 완료 되게 하는 기술입니다.

위 단계별로 동일하게 신뢰점(개별 시스템 이미지를 읽어, 해시 함수를 통해 메시지 다이제스트 생성, 개별 검증 프로그램으로 시그니처를 검증하는 방식) 과정을 통해 순차적으로 수행합니다.

・ ・ ・

이 글이 자율주행 제어 장치뿐만 아니라 다양한 임베디드 장치의 OTA 업데이트 구현을 시작하는 기업과 제품 개발자들에게 작은 도움이 되면 좋겠습니다. 우리는 임베디드 장치 관련 소프트웨어 개발 업체들의 제품 프로젝트에 매우 적은 노력과 낮은 비용으로 안정적이고 안전한 OTA 업데이트 기능과 위에서 소개한 보안 기능들을 통합 적용해서 빠른 제품 출시에 실질적인 도움을 줄 수 있는 SaaS(Software as a Service) 클라우드 기반으로 서비스 제공을 준비하고 있습니다. 관련해서 보다 자세한 기술 및 기능 설명이나 demo 버전 사용을 원하시면 언제든지 42dot으로 문의 부탁드립니다.

김성준 | SDV Security (Tech Lead)



스스로 움직이는 모든 장치들에 적용될 보안 기술을 개발 하고 있습니다.