둘 다 맞는 말입니다. 그리고 실제 차량 보안에서는 이 두 요구사항을 동시에 만족시켜야 합니다.
그런데 공격자에게는 ECU 내부로 들어가는
가장 강력한 침입 경로이기도 합니다.
그래서 차량 보안에서는 "Debug를 없애는 것"이 아니라 "누가, 언제, 어떻게 Debug를 사용할 수 있는가"를 관리하기 시작합니다. 이게 바로 Secure Debug입니다.
왜 Debug Port가 위험할까
MCU 기반 ECU에는 보통 JTAG, SWD, DAP 같은 Debug Interface가 존재합니다. 원래 목적은 Firmware Download, Breakpoint, Memory Read, Register 분석 같은 개발 기능입니다. 그런데 공격자 입장에서는 완전히 다른 도구가 됩니다.
Flash Dump · Firmware 추출 · Secure Boot 우회
Key 탈취 · Memory 조작 · Boot Flow 변경
Debug Port는 사실상 "하드웨어 Root 권한"에 가까운 인터페이스입니다. 그리고 실제 공격은 생각보다 단순합니다.
양산 ECU는 Debug를 막기 시작했다 — 하지만 완전히는 못 막는다
R155, ISO/SAE 21434, OTA, Secure Boot가 도입되면서 상황이 바뀌었습니다.
그런데 Debug를 완전히 차단하면 다른 문제가 생깁니다. 현실에서는 양산 이후에도 Debug가 필요한 순간이 반드시 옵니다.
- 양산 이후 필드 장애 분석
- 서비스센터 Diagnostic 대응
- RMA(반품) ECU 분석
- 공장 재작업
- 품질 이슈 재현
현업에서 진짜 무서운 것 — 운영 실수
사실 가장 위험한 건 "Debug를 지원한다"는 사실 자체가 아닙니다.
· 양산 이미지인데 Debug 활성화 상태로 출하
· 개발용 Password 하드코딩이 양산까지 그대로 남음
· 전 ECU 동일한 Debug Key 사용
· 개발 단계 Unlock 설정이 제거되지 않음
· 양산 직전 일정 압박으로 Debug 정책 검토 생략
특히 개발 일정 부족, 양산 직전 변경, 생산라인 이슈가 겹치면 Debug 정책이 제대로 정리되지 못하는 경우가 생깁니다. 그리고 이게 실제 현업에서 꽤 자주 발생합니다.
ECU Lifecycle별 Debug 권한 관리
"Debug 가능 / 불가능"처럼 단순하게 관리하지 않습니다. ECU가 어느 단계에 있느냐에 따라 허용 범위가 달라집니다.
즉 ECU Lifecycle 전체에서 Debug 정책을 관리합니다. 단계별로 허용 범위가 다르고, 단계 전환 시 반드시 정책이 변경되어야 합니다.
Secure Debug — 인증된 사람만 접근 가능하게
최근 차량 보안에서는 Debug도 인증 기반으로 바뀌고 있습니다. "Debugger를 꽂았다"가 아니라, "인증된 사용자만 Debug 가능"으로 개념이 바뀌는 것입니다.
한 번의 Response를 캡처해도 재사용이 불가능합니다. Replay Attack을 막는 구조입니다.
Secure Debug도 결국 Key 관리 문제다
Secure Debug 구조도 결국 "누가 신뢰 가능한가" 문제입니다. Challenge-Response, 전자서명, Key Verification 위에서 동작하기 때문입니다.
| 구성 요소 | 역할 | 보관 위치 |
|---|---|---|
| OEM Private Key | Response 서명 생성 | OEM 서버 (외부 반출 금지) |
| Device Public Key | 서명 검증 | ECU 내부 HSM / 보안칩 |
| Device Unique Key | ECU별 고유 인증 | ECU 내부 HSM / 보안칩 |
| Debug Certificate | 접근 권한 범위 정의 | 서비스 툴 / OEM 발급 |
Flash Dump → Key 추출 → 인증 우회 → Fake Unlock 생성이 가능해집니다.
그래서 Secure Debug에서도 HSM 또는 외장 보안칩 기반 Key 보호가 핵심입니다.
SDV 시대에는 더 복잡해진다
AP, Linux, Hypervisor, TEE, MCU가 함께 있는 SDV 구조에서는 Debug 관리 자체가 훨씬 복잡해집니다.
| Debug 대상 | 특성 | 관리 포인트 |
|---|---|---|
| AP Linux Debug | SSH, gdb, 원격 접근 | 인증 기반 접근 제어, 로그 감사 |
| MCU Debug | JTAG/SWD 물리 접근 | Secure Debug + 물리 핀 보호 |
| TEE Secure World Debug | 일반 디버거로 접근 불가 | 별도 인증 채널, 접근 자체 최소화 |
| Hypervisor Debug | Guest VM 전체 영향 | 권한 분리, VM별 독립 정책 |
SDV 시대에는 "Debug 정책 자체가 하나의 보안 시스템"이 됩니다. 레이어별로 독립적인 접근 제어가 필요하고, 어느 하나라도 열려있으면 전체가 영향을 받을 수 있습니다.
현업에서는 이렇게 느껴진다
Secure Debug 적용 현장에서 배운 것들
마무리
차량 보안에서 Debug는
"막아야 하는 기능"이 아닙니다.
누가, 언제, 어떤 권한으로 접근 가능한가를
ECU Lifecycle 전체에서 관리해야 하는 기능입니다.
그 순간부터 Debug는 단순 개발 도구가 아니라
보안 아키텍처의 일부가 됩니다.
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| J1939-91C란 무엇일까? — 상용차 CAN 통신 보안은 SecOC와 무엇이 다를까? (0) | 2026.06.04 |
|---|---|
| 자동차 메시지는 어떻게 신뢰할 수 있을까? — SecOC 쉽게 이해하기 (0) | 2026.06.04 |
| "차량 보안의 핵심은 결국 '키 보호'다 — HSM 구조(심화)" (0) | 2026.05.26 |
| “우리가 만든 코드 아닌데…” — 차량 OSS·BSP 취약점 관리의 현실— SDV 시대에는 직접 개발하지 않은 소프트웨어까지 관리해야 한다 (0) | 2026.05.22 |
| 차량 IDS 구현의 진짜 어려움 — 표준은 있는데, 판단 기준은 다 다르다 (0) | 2026.05.22 |