그런데 공통적으로 한 단어가 반복해서 등장했습니다.
Secure Boot.
"서명 검증 후 Secure Boot가 재확인한다", "Secure Boot가 없으면 무용지물이다"…
도대체 Secure Boot가 무엇이기에 이렇게 자꾸 등장하는 걸까요?
ECU가 켜지는 그 첫 순간, 무슨 일이 일어나는지 처음부터 들여다봅니다.
Secure Boot란 무엇인가
Secure Boot는 ECU가 부팅될 때 실행되는 소프트웨어가 신뢰할 수 있는 것인지 검증하는 기술입니다. 한마디로 "이 코드, 우리가 만든 게 맞나?"를 부팅 순간마다 확인하는 것입니다.
왜 부팅 시점이 중요할까요? 공격자가 ECU에 악성 펌웨어를 심는 데 성공했다고 가정해봅니다. 아무리 훌륭한 게이트웨이와 OTA 보안이 있더라도, 이미 ECU 안에 악성 코드가 있다면 모든 보안이 그 위에서 돌아가게 됩니다. 기초가 무너진 건물처럼요.
핵심 원리 — 디지털 서명이란 무엇인가
Secure Boot를 이해하려면 먼저 디지털 서명(Digital Signature)이 무엇인지 알아야 합니다. 어렵게 느껴지지만 개념은 단순합니다.
OEM은 펌웨어를 만들 때 자신만이 가진 개인키(Private Key)로 서명을 붙입니다. "이 소프트웨어는 우리가 만든 정상 코드입니다"라는 전자 도장입니다. ECU는 공장 출하 시 이미 심어진 공개키(Public Key)로 그 서명이 진짜인지 확인합니다.
| 구분 | 누가 갖는가 | 역할 |
|---|---|---|
| 개인키 (Private Key) | OEM 서버만 보유. 절대 외부 노출 금지 | 펌웨어에 서명을 생성 |
| 공개키 (Public Key) | ECU 내 HSM에 저장. 읽기만 가능 | 서명이 진짜인지 검증 |
한 가지 오해를 짚고 가겠습니다. 스마트폰에도 Secure Boot가 있습니다. 하지만 차량 ECU의 Secure Boot는 다음과 같은 이유로 훨씬 까다롭습니다.
| 구분 | 스마트폰 Secure Boot | 차량 ECU Secure Boot |
|---|---|---|
| 부팅 실패 결과 | 화면 오류, 재시도 가능 | 주행 기능 마비, 안전 문제 직결 |
| 부팅 시간 제약 | 수 초 허용 | 수백 밀리초 이내 요구 |
| 업데이트 주체 | 사용자 선택 | OEM 승인 필수 |
| 하드웨어 다양성 | 소수 플랫폼 | MCU 벤더별 HSM 구조가 모두 다름 |
| 법적 요구사항 | 없음 | UN R155, ISO 21434 의무 대응 |
신뢰 체인 — 부팅은 어떻게 단계적으로 검증되나
Secure Boot의 핵심은 "절대적으로 신뢰할 수 있는 출발점"에서 시작해 위로 올라가며 검증하는 구조입니다. 이 출발점을 Root of Trust(RoT)라고 합니다.
검증이 실패하면 어떻게 되는가
Secure Boot 검증 실패는 단순한 에러 메시지가 아닙니다. ECU 설계에 따라 다르지만 일반적으로 세 가지 방향으로 동작합니다.
Secure Boot를 구성하는 핵심 요소들
OEM 공개키와 암호화 연산을 하드웨어로 격리합니다. 소프트웨어가 아무리 침해당해도 HSM 내부의 키는 추출할 수 없습니다. Secure Boot의 신뢰 앵커(Trust Anchor) 역할을 합니다.
각 소프트웨어 이미지는 OEM 개인키로 서명됩니다. 부팅 시 HSM에 저장된 공개키로 서명을 검증합니다. RSA-2048, ECDSA P-256 등이 주로 사용됩니다.
Memory Protection Unit을 설정해 각 소프트웨어 레이어가 허용된 메모리 영역에만 접근하도록 제한합니다. Bootloader가 Application 영역을 임의로 수정하지 못하게 막습니다.
JTAG, SWD 같은 디버그 인터페이스는 개발 단계에서는 열려 있지만, 양산 시 반드시 잠가야 합니다. 열린 디버그 포트는 Secure Boot 전체를 우회하는 지름길이 됩니다.
ECU는 개발→테스트→양산→폐기 단계를 거칩니다. 각 단계별로 허용되는 동작이 다르며, 양산 단계에서는 디버그 접근·키 교체 등이 차단됩니다. 수명주기 상태는 HSM이 관리합니다.
AUTOSAR 기반 ECU에서는 Crypto Stack과 SecOC 모듈이 Secure Boot와 연동됩니다. HSM 드라이버를 통해 하드웨어 암호화 자원을 추상화해 사용합니다.
Secure Boot가 없으면 어떤 일이 가능한가
Secure Boot의 필요성을 가장 잘 이해하는 방법은 없을 때 무슨 일이 가능한지 보는 것입니다.
| 공격 시나리오 | Secure Boot 없을 때 | Secure Boot 있을 때 |
|---|---|---|
| OTA로 악성 펌웨어 배포 | 서명 없이 그대로 설치됨 | 서명 검증 실패 → 설치 거부 |
| OBD-II로 펌웨어 직접 주입 | 플래싱 즉시 실행됨 | 부팅 시 무결성 검증 실패 → 실행 차단 |
| 디버그 포트로 코드 수정 | 수정된 코드 그대로 실행 | 양산 단계 Lock으로 포트 자체 차단 |
| 메모리 덤프 후 코드 변조 | 변조된 이미지 재플래싱 가능 | 서명 불일치로 부팅 중단 |
| 공급망 침해 (악성 펌웨어 납품) | 탐지 수단 없음 | OEM 서명 없으면 실행 불가 |
구현이 생각보다 쉽지 않은 이유
개념은 단순합니다. "서명 검증하고, 실패하면 멈추면 된다." 하지만 실제 차량 ECU에 적용하는 것은 여러 제약이 맞물립니다.
- 1 부팅 시간 제약 — 차량 ECU는 이그니션 온 후 수백 밀리초 안에 기능을 시작해야 합니다. 암호화 연산이 추가되면 부팅 시간이 늘어나는데, 이를 HSM 하드웨어 가속으로 보완해야 합니다.
- 2 키 관리 복잡성 — OEM 개인키가 유출되면 전체 차량 보안이 붕괴됩니다. 서명용 키를 안전하게 관리하는 인프라(PKI)가 ECU만큼이나 중요합니다.
- 3 개발·양산 단계 전환 — 개발 중에는 디버그 포트가 열려 있어야 하지만, 양산 전에 반드시 잠가야 합니다. 이 전환 절차를 실수하면 양산 차량에 디버그 포트가 열린 채로 출하될 수 있습니다.
- 4 레거시 ECU 적용의 어려움 — 이미 설계가 완료된 구형 ECU에 Secure Boot를 추가하려면 하드웨어 수정이 필요한 경우가 많습니다. 소프트웨어만으로는 신뢰 체인의 출발점을 만들 수 없습니다.
- 5 "검증은 하지만 계속 진행"하는 잘못된 구현 — Secure Boot 코드를 넣었지만 검증 실패 시 에러 로그만 남기고 부팅을 계속하는 경우가 있습니다. 이는 보안이 아니라 보안의 외양만 갖춘 것입니다.
Secure Boot와 OTA — 이 둘은 어떻게 연결되는가
지난 편에서 OTA 보안의 핵심이 코드 서명과 검증이라고 했습니다. 그런데 OTA 수신 시점에 서명을 검증했더라도, 그것만으로 충분하지 않습니다.
예를 들어 공격자가 OTA 검증을 통과한 이후 ECU 메모리를 직접 변조했다면 어떻게 될까요? OTA 단계에서는 정상이었더라도, 이미 ECU 안에는 변조된 코드가 있습니다.
| 검증 시점 | 담당 | 목적 |
|---|---|---|
| OTA 수신 즉시 | Secure Flash / OTA 보안 | 다운로드된 패키지가 정상 서명인지 확인 |
| 매 부팅 시 | Secure Boot | 현재 ECU에 저장된 펌웨어가 변조되지 않았는지 확인 |
현업에서는 실제로 이렇게 접근한다
마무리
Secure Boot는 차량 보안의 시작점입니다. 이것이 없으면 그 위에 쌓이는 모든 보안은 모래 위의 성입니다.
게이트웨이가 도메인 경계를 지키고, OTA가 안전하게 업데이트를 전달하고, SecOC가 CAN 메시지를 인증하더라도 — ECU 안에서 실행되는 코드 자체가 신뢰할 수 없다면 모든 것이 의미를 잃습니다.
Secure Boot는 그 신뢰의 출발점을 하드웨어에 못 박아두는 기술입니다. 완벽하지 않고 구현이 어렵지만, 없어서는 안 될 첫 번째 방어선입니다.
핵심 요약
- Secure Boot는 부팅 시 소프트웨어 무결성을 단계적으로 검증하는 기술이다
- 신뢰 체인(Chain of Trust)은 하드웨어 기반 Root of Trust에서 시작한다
- Boot ROM → BL1 → BL2 → Application 순으로 각 단계가 다음 단계를 검증한다
- 검증 실패 시 Hard Failure, Fallback, Degraded Mode 중 하나로 대응한다
- HSM이 신뢰 앵커 역할을 하며, 디버그 포트 잠금은 필수다
- "검증은 하지만 계속 진행"하는 구현은 Secure Boot가 아니다
- 양산 단계 전환 절차와 V&V 실패 케이스 검증이 현업의 핵심 과제다
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| UDS의 Diagnostic Session은 왜 필요할까?(ECU 진단 권한을 나누는 방법) (0) | 2026.05.13 |
|---|---|
| 자동차는 왜 진단 인증(Security Access)을 사용할까? (0) | 2026.05.12 |
| 차량 OTA 업데이트, 어떻게 안전하게 할 수 있을까? (1) | 2026.05.12 |
| 자동차에도 방화벽이 존재할까? (0) | 2026.05.12 |
| 차량은 어떻게 해킹되는가?(ECU 공격의 실제 구조) (1) | 2026.05.12 |