Legacy ECU는 사이버보안을 어떻게 적용할까?

현업에서 보는 차량 사이버보안

R155와 ISO/SAE 21434 대응을 시작하면 반드시 이 질문이 나옵니다.

"신규 ECU는 알겠어요. 근데 지금 양산 중인 ECU는요?"

HSM도 없고, OTA도 안 되고, Flash도 빠듯하고,
보안을 고려하지 않고 설계된 ECU들이 지금 이 순간에도 도로를 달리고 있습니다.

이것이 현장에서 가장 많이 받는 질문 중 하나이고,
가장 현실적으로 어려운 문제이기도 합니다.

Legacy ECU — 신규 ECU와 무엇이 다른가

최신 차량 플랫폼은 처음부터 사이버보안을 고려해서 설계됩니다. 하지만 Legacy ECU는 그렇지 않습니다. 대부분 기능 안전과 제어 성능 중심으로 개발됐고, 당시에는 지금 수준의 보안 요구사항이 존재하지 않았습니다.

항목	신규 ECU	Legacy ECU
HSM	기본 탑재	대부분 없음
Secure Boot	초기 설계 포함	적용 어려움
OTA	구조적으로 고려됨	미고려 또는 불가
Flash / RAM	상대적 여유	사용률 한계에 근접
Crypto Stack	AUTOSAR 기반 지원	부분 지원 또는 없음
CPU 성능	암호 연산 고려	실시간 제어 중심
소스코드	접근 가능	없거나 히스토리 단절

"신규 개발 ECU만 보안 적용하면 된다"고 생각하는 경우가 많습니다. 하지만 차량 한 대 안에 Legacy ECU가 하나라도 있으면 그 ECU가 공격 진입점이 될 수 있습니다. 보안은 가장 약한 ECU 수준에서 결정됩니다.

실제로 어떤 한계가 존재하는가

문제 01

메모리 부족

Secure Boot나 SecOC를 넣으려면 추가 코드와 키 저장 공간이 필요합니다. 하지만 Legacy ECU는 Flash·RAM 사용률이 이미 한계에 가까운 경우가 많습니다.

문제 02

HSM 부재

최신 보안 기능은 HSM을 전제로 설계됩니다. HSM 없이는 키 보호와 암호 연산을 안전하게 처리하기 어렵고, SW 기반 대안은 구조적 취약성이 남습니다.

문제 03

성능 부족

SecOC MAC 검증이나 암호화 연산은 CPU 부하를 증가시킵니다. 실시간 제어 중심으로 설계된 Legacy ECU는 보안 연산을 추가하면 제어 성능 문제가 발생할 수 있습니다.

문제 04

개발 환경 단절

오래된 ECU는 원 개발사가 사라졌거나 소스코드 접근이 불가능한 경우도 있습니다. 재빌드 환경 자체를 복원하기 어려운 사례가 실제로 존재합니다.

가장 큰 어려움은 기술적 한계가 아닙니다. "변경하자"는 결정을 내리는 것입니다. MCU 변경 하나만으로도 HW 재설계, EMC 재시험, 양산 승인까지 연쇄적으로 영향이 발생하기 때문에 보안 위험보다 변경 비용이 더 크게 느껴집니다.

ISO/SAE 21434는 Legacy ECU에 무엇을 요구하는가

21434는 Legacy ECU 예외를 인정하지 않습니다. 다만 현실을 인정하고 다른 접근을 허용합니다. 핵심은 Tailoring입니다.

핵심

Tailoring — 범위를 조정하되 반드시 근거를 문서화하라

모든 보안 활동을 동일하게 적용할 수 없을 때 Tailoring으로 범위를 조정할 수 있습니다. 단, "왜 이 활동이 이 ECU에 적용되지 않는가"를 논리적으로 설명해야 합니다. 근거 없이 생략하면 VTA 심사에서 지적됩니다.

1

TARA 수행 — HW 제약과 관계없이 위협 분석은 반드시

HSM이 없어도 TARA는 수행해야 합니다. "이 ECU에 어떤 공격이 가능하고, 피해는 무엇이고, Risk Level은 어떻게 되는가"를 분석해야 이후 대응 우선순위가 결정됩니다.

2

Gap Analysis — 현재 상태와 요구사항의 차이 파악

TARA 결과로 도출된 보안 요구사항을 현재 ECU가 얼마나 충족하는지 분석합니다. "무엇이 없는가"를 명확히 해야 무엇을 보완할지 결정할 수 있습니다.

3

대응 방향 결정 — 보완·완화·허용 중 선택

SW 보완으로 개선 가능한 것, HW 제약으로 완전 해결 불가능해 Compensating Control로 완화해야 하는 것, 위험도가 낮아 허용 가능한 것으로 분류합니다.

4

Residual Risk Accept — 남은 Risk를 문서화하고 OEM 승인

모든 Risk를 제거할 수 없습니다. 대응 불가능한 Risk는 허용 근거와 완화 조치를 문서화해 OEM의 승인을 받아야 합니다. 이것이 "그냥 방치"와 "21434 대응"의 차이입니다.

R155와 ISO 21434는 "모든 ECU가 최신 보안 기술을 반드시 가져야 한다"고 요구하지 않습니다. 위험을 어떻게 파악하고, 관리하고, 감소시켰는지를 중요하게 봅니다. 체계적인 관리의 증명이 핵심입니다.

HW 제약 있어도 할 수 있는 것 — 기술별 적용 가능성

HSM이 없고 Flash가 빠듯해도 할 수 있는 것과 없는 것이 있습니다. 현실적인 판단을 위해 주요 보안 기술별 적용 가능성을 정리했습니다.

보안 기술	HSM 있음	HSM 없음	Flash 여유 없음	OTA 불가
Secure Boot	●	SW 기반 제한적	✕	●
SecOC (CAN MAC)	●	SW AES 가능	일부 메시지만	●
Secure Flash	●	Write 보호만	설정 변경만	●
Debug 잠금	●	●	●	●
Secure Diagnostics	●	Seed-Key SW	경량 구현	●
키 관리·갱신	●	✕ 매우 어려움	✕	✕ OTA 필요
보안 로깅	●	경량 이벤트만	✕	●

Debug 잠금은 HW 제약, Flash 여유, OTA 가능 여부와 무관하게 거의 항상 적용 가능합니다. 비용도 낮고 효과도 큽니다. Legacy ECU 대응에서 가장 먼저 확인해야 하는 항목입니다.

HSM 없을 때 — 현실적인 대안들

이상 Secure Boot — 이상적 방법 vs 현실적 대안

HSM 있을 때

HSM 기반 서명 검증

공개키 HSM에 안전 보관

강력한 변조 방지 보장

HSM 없을 때 현실적 대안

SW 기반 서명 검증 (제한적)

Flash Write 보호로 Bootloader 보호

MCU 내장 보안 기능(e-Fuse 등) 활용

대안 SecOC — HSM 없이 SW AES로 구현

HSM 있을 때

HSM에서 MAC 연산

키 안전 보관

CPU 부하 없음

HSM 없을 때 현실적 대안

SW AES-128 CMAC 구현

Safety Critical 메시지만 우선 적용

키 관리 취약성 인지 후 Residual Risk 문서화

최소 Flash 여유 없을 때 — 최소한으로 할 수 있는 것

Flash 여유 있을 때

전체 보안 기능 탑재

보안 로깅 포함

여유 있는 암호화 구현

Flash 여유 없을 때

Debug 잠금 (코드 추가 최소)

Flash Write 보호 설정

Bootloader 진입 제한

PenTest에서 Legacy ECU는 어떻게 보이는가

실제 차량 모의해킹에서 Legacy ECU가 반복적으로 지적되는 이유가 있습니다. 구조적으로 보안이 빠진 상태가 그대로 노출되기 때문입니다.

취약점 01

열려 있는 Debug Port

JTAG/SWD 잠금이 없거나 우회 가능한 경우가 있습니다. 메모리 덤프와 펌웨어 추출로 이어지고, 이후 전체 시스템 분석의 출발점이 됩니다.

취약점 02

약한 Security Access

단순 Seed-Key 알고리즘, 고정 Key, Attempt Counter 미구현 등이 여전히 발견됩니다. 진단 권한 획득 후 Flashing으로 이어집니다.

취약점 03

Secure Boot 부재

펌웨어 무결성 검증이 없어 변조된 소프트웨어 실행 가능성이 존재합니다. 한 번 Flash를 쓸 수 있으면 공격자 코드가 ECU에서 실행됩니다.

취약점 04

평문 Firmware

OTA나 Flash 데이터가 암호화되지 않은 상태로 저장·전송되는 경우가 있습니다. Firmware 역공학으로 키, 알고리즘, 로직 분석이 가능해집니다.

중요한 점은 Legacy ECU 자체보다 "Legacy ECU가 차량 전체 공격 경로의 약한 고리가 된다"는 것입니다. 공격자는 가장 약한 ECU 하나만 침해하면 내부 네트워크 이동을 시도할 수 있습니다.

Compensating Control — ECU 자체를 못 바꾸면 주변을 보호하라

모든 Legacy ECU를 직접 수정하는 것은 현실적으로 불가능합니다. 그래서 업계에서 실제로 사용하는 전략이 Compensating Control입니다. ECU 자체 보안이 부족하더라도 다른 보호 수단으로 위험을 줄이는 방식입니다.

LEGACY ECU 대응 — 현실적인 보안 구조

외부 통신 차단

→

Secure Gateway

→

Legacy ECU 보호

비정상 CAN 탐지

→

Gateway IDS

→

내부 공격 완화

진단 접근 제한

→

SGW 인증

→

불필요한 접근 차단

직접 보호 어려움

→

Compensating Control

→

Residual Risk 감소

부족한 보안 기능	현실적인 Compensating Control
Secure Boot 없음	OTA 패키지 서명 검증 강화 + Flash 접근 제한
SecOC 적용 불가	Gateway Filtering + IDS 적용
약한 Seed-Key	SGW 인증 + 진단 접근 횟수·권한 제한
HSM 없음	외부 Secure Element 활용 검토 + 키 노출 최소화
OTA 미지원	서비스센터 기반 오프라인 업데이트 + 절차 보안 강화

최근 일부 OEM은 Gateway ECU에 IDS 적용을 사실상 필수 수준으로 요구하기 시작했습니다. Legacy ECU를 완벽하게 보호하기 어렵기 때문에, 네트워크 중심 방어가 더욱 중요해지고 있는 흐름입니다.

어디서부터 시작할 것인가 — 우선순위 결정

Legacy ECU가 수십 개라면 전부 동시에 대응하는 건 불가능합니다. TARA 결과를 바탕으로 우선순위를 결정하는 것이 핵심입니다.

Legacy ECU 보안 대응 우선순위 결정 기준

Q1

외부 인터페이스가 있는가? — OBD, OTA, Telematics, BLE, Wi-Fi 등 외부와 연결되는 ECU가 최우선입니다. 외부 인터페이스 없는 내부 ECU는 상대적으로 공격 표면이 작습니다.

Q2

Safety Critical 기능을 제어하는가? — 브레이크, 조향, 엔진 등 Safety와 직결된 ECU는 피해 규모가 크기 때문에 Risk Level이 높습니다. Gateway ECU도 여기 포함됩니다.

Q3

공격 경로상 중간 거점이 되는가? — 직접 외부에 노출되지 않아도, 다른 ECU를 통해 도달 가능한 경로의 중간에 있다면 우선 대응 대상입니다.

Q4

현실적으로 수정 가능한가? — 위험도가 높아도 변경이 불가능한 ECU가 있습니다. 이 경우 Compensating Control과 Residual Risk Accept를 결정합니다.

현장에서 자주 마주치는 오해들

흔한 오해

"HSM 없으니까 보안 적용 불가" — 아무것도 안 해도 된다는 결론으로 이어짐

실제로는

Debug 잠금, Flash Write 보호, SW 기반 서명 검증은 가능. 할 수 있는 것부터 하고 나머지는 Residual Risk로 문서화

흔한 오해

"Legacy ECU는 TARA 안 해도 된다" — 신규 ECU만 분석하면 된다는 생각

실제로는

21434는 차량 전체를 본다. Legacy ECU도 TARA 대상. HW 제약과 관계없이 위협 분석은 해야 함. Tailoring은 TARA 이후에 적용

흔한 오해

"Gateway만 보안 강화하면 내부 ECU는 안전하다" — 경계 보안으로 충분하다는 생각

실제로는

Gateway가 뚫리면 내부 ECU가 무방비. Compensating Control은 완화 수단이지 완전 해결이 아님. 내부 ECU 최소 보안도 필요

흔한 오해

"Residual Risk는 그냥 방치해도 된다" — 대응 못 하면 기록도 필요없다는 생각

실제로는

반드시 문서화하고 OEM 승인 필요. "왜 이 Risk를 허용하는가"에 대한 근거가 없으면 VTA 심사에서 지적됨

결국 업계의 방향은 바뀌고 있다

Legacy ECU 대응은 결국 "현재 구조를 얼마나 오래 유지할 수 있는가"의 문제이기도 합니다. 그래서 업계는 점점 다음 방향으로 이동하고 있습니다.

과거 차량 아키텍처	SDV·미래 차량 아키텍처
분산형 ECU 구조 — 기능별 소형 ECU	Zonal Architecture — 구역별 통합 제어
기능 중심 MCU 선정	기본 HSM 탑재 MCU 표준화
보안 = 기능 위에 추가	보안 = 처음부터 설계 기반
OTA 미고려	OTA 중심 플랫폼 구조
ECU 단위 개별 관리	고성능 SoC 기반 중앙 집중형 관리

즉 자동차 산업은 보안을 "추가"하는 시대에서 보안을 "기본 전제"로 설계하는 방향으로 이동하고 있습니다. Legacy ECU 문제는 이 전환이 완료될 때까지 계속 남아있을 현실적인 숙제입니다.

현업에서는 실제로 이렇게 경험한다

변경 결정이 가장 어렵다 — 무엇을 해야 하는지는 알아도 "지금 양산 중인 ECU를 바꾸자"는 결정을 내리는 것이 실제로 가장 어렵습니다. MCU 변경 하나만으로도 HW 재설계, EMC 재시험, 양산 승인까지 연쇄 영향이 발생합니다. TARA 기반 Risk 정량화가 이 결정을 도와줍니다.

Debug 열린 채로 양산된 ECU가 생각보다 많다 — "개발 중에 JTAG 열어놨는데 닫는 걸 잊었다"는 상황이 실제로 꽤 있습니다. Debug 잠금은 코드 변경 없이 설정만으로 가능한 경우가 많아 가장 먼저 확인해야 하는 항목입니다.

Gateway 의존도가 계속 올라간다 — ECU 자체 보안이 부족하면 결국 SGW와 Gateway IDS에 의존하게 됩니다. 최근 OEM들이 Gateway ECU 보안 요구사항을 강화하는 이유입니다. 단, Gateway도 뚫리면 뒤가 없다는 점은 항상 인식해야 합니다.

OEM 요구와 현실의 괴리를 협의로 풀어야 한다 — OEM이 Legacy ECU에도 동일한 보안 요구사항을 제시하는 경우가 있습니다. 현실적으로 불가능한 부분은 Tailoring과 Residual Risk Accept로 근거를 갖춰 협의해야 합니다. 근거 없이 "못 한다"고만 하면 OEM이 받아들이지 않습니다.

소스코드가 없는 ECU도 있다 — 오래된 ECU는 담당자 퇴사, 협력사 폐업 등으로 소스코드 접근이 불가능한 경우가 있습니다. 이 경우 Firmware 역공학 분석 또는 Black-box 기반 TARA가 필요해집니다.

마무리

Legacy ECU의 문제는 단순히 오래된 하드웨어가 아닙니다.
"보안을 고려하지 않고 설계된 구조" 자체가 문제입니다.
그리고 그 구조를 하루아침에 바꿀 수는 없습니다.

21434와 R155는 완벽한 보안을 요구하지 않습니다. 위협을 파악하고, 할 수 있는 것을 하고, 못 하는 것은 근거를 갖춰 문서화하는 것 — 이것이 Legacy ECU를 가진 조직이 지금 당장 시작할 수 있는 현실적인 첫걸음입니다.

핵심 요약

• Legacy ECU = HSM 없음·Flash 제약·OTA 불가·양산 중 변경 어려운 ECU
• 21434는 Legacy ECU 예외를 인정하지 않는다 — Tailoring으로 범위 조정은 가능하나 근거 필수
• 접근 순서: TARA → Gap Analysis → 대응 방향 결정 → Residual Risk 문서화 및 OEM 승인
• Debug 잠금은 HW 제약 없이 가장 먼저 적용 가능한 항목이다
• HSM 없어도 SW AES 기반 SecOC, Flash Write 보호, Bootloader 접근 제한은 가능하다
• Compensating Control — ECU 자체 보호가 어려우면 Gateway·IDS·Network Segmentation으로 완화
• PenTest에서 반복 지적되는 항목: Debug 열림, 약한 Security Access, Secure Boot 부재, 평문 Firmware
• 우선순위: 외부 인터페이스 → Safety Critical → 공격 경로 거점 순

업계는 Zonal Architecture·HSM 기본 탑재·OTA 중심 플랫폼으로 이동 중

목표는 완벽한 보안이 아니라 체계적인 보안 관리의 증명이다