UDS는 강력하고, Security Access가 잠가두고,
Session이 권한을 나누고, Flashing은 위험합니다.
그런데 한 가지 질문이 남습니다.
"그 모든 보안이 있어도, 테스터가 OBD-II에 꽂으면 ECU에 직접 닿지 않나요?"
예전에는 그랬습니다.
하지만 지금은 다릅니다.
테스터의 진단 요청은 ECU에 도달하기 전에
게이트웨이 ECU를 먼저 통과해야 합니다.
그리고 게이트웨이는 적지 않은 요청을 거기서 차단합니다.
과거에는 OBD-II가 CAN 버스에 직접 연결됐다
자동차 진단 역사의 초기에는 OBD-II 포트가 차량 내부 CAN 버스에 거의 직접 연결되어 있었습니다. 테스터를 꽂으면 그 순간 모든 ECU와 직통으로 대화할 수 있는 구조였습니다.
편리했습니다. 어떤 진단 장비든 꽂으면 모든 ECU에 접근할 수 있었습니다. 하지만 이 구조는 동시에 치명적인 취약점이었습니다. OBD-II 포트에 물리 접근한 누구든 — 악의적인 목적을 가진 사람도 — 차량의 모든 ECU에 진단 명령을 보낼 수 있었습니다.
그래서 최근 차량에서 OBD-II 포트는 더 이상 내부 CAN 버스의 "직통 입구"가 아닙니다. 모든 진단 요청은 반드시 게이트웨이를 통과해야만 내부 ECU에 닿을 수 있습니다.
지금은 게이트웨이가 중간에 있다
최신 차량에서는 OBD-II 포트와 내부 CAN 버스 사이에 게이트웨이 ECU가 자리잡고 있습니다. 테스터의 모든 진단 요청은 게이트웨이를 통과해야만 대상 ECU에 도달할 수 있습니다.
진단 요청 라우팅·필터링
엔진·변속기 ECU
ABS·스티어링 ECU
에어백·조명 ECU
→ 진단 접근 제한
게이트웨이가 진단 요청에 대해 하는 일
게이트웨이는 진단 요청에 대해 크게 세 가지를 합니다.
| 동작 | 설명 | 예시 |
|---|---|---|
| 라우팅 (Routing) | 허용된 진단 요청을 올바른 대상 ECU로 전달 | 엔진 ECU 대상 DTC 읽기 요청 → 파워트레인 도메인으로 전달 |
| 필터링 (Filtering) | 허용되지 않은 요청을 차단하고 NRC 반환 | 인포테인먼트 도메인에서 파워트레인 ECU 플래싱 요청 → 차단 |
| 주소 변환 (Address Translation) | 물리 주소(Physical)와 기능 주소(Functional)를 변환 | 브로드캐스트 요청 → 대상 ECU 물리 주소로 변환해 전달 |
게이트웨이는 구체적으로 무엇을 차단하는가
게이트웨이의 필터링 정책은 OEM이 정의합니다. 일반적으로 다음과 같은 요청들이 차단 대상이 됩니다.
테스터가 허용 목록에 없는 ECU에 직접 요청을 보내려 하면 게이트웨이가 라우팅을 거부합니다. 모든 ECU가 외부에 노출되지 않습니다.
인포테인먼트 도메인에서 파워트레인·섀시 도메인 ECU로의 진단 요청을 차단합니다. 인포테인먼트가 해킹되어도 안전 관련 ECU에 접근하지 못합니다.
차량이 주행 중이거나 조건이 맞지 않을 때 Programming Session 진입이나 플래싱 관련 서비스 요청을 게이트웨이 수준에서 선제 차단합니다.
최신 차량에서는 게이트웨이가 연결된 테스터의 인증서를 검증합니다. OEM이 승인하지 않은 서드파티 진단기는 게이트웨이 단계에서 차단됩니다.
| 진단 요청 | 게이트웨이 처리 | 이유 |
|---|---|---|
| 엔진 ECU DTC 읽기 (0x19) | 허용 | 모든 테스터에 허용된 기본 서비스 |
| 에어백 ECU 데이터 읽기 (0x22) | 조건부 허용 | 정비 장비 인증 필요 |
| 엔진 ECU 플래싱 (0x34) | 조건부 허용 | OEM 공식 장비 + 차량 정지 + SA 인증 필요 |
| 파워트레인 ECU에 임의 CAN 메시지 | 차단 | UDS 외 비정상 요청 |
| 허용 목록에 없는 ECU 주소 접근 | 차단 | 라우팅 테이블에 없는 대상 |
진단 보안의 변화 — 과거와 지금
Secure Diagnostics — 게이트웨이를 넘어서
게이트웨이의 진단 필터링은 중요한 보안 레이어이지만, 더 발전된 개념도 있습니다. 최근 차량에서는 Secure Diagnostics 개념이 적용되기 시작했습니다.
Secure Diagnostics는 단순히 요청을 차단하는 것을 넘어, 누가 어떤 ECU에 어떤 서비스를 사용할 수 있는지를 중앙에서 정책으로 관리합니다. 핵심 요소는 세 가지입니다.
| 요소 | 설명 |
|---|---|
| 진단 장비 인증 | 테스터가 OEM 발급 인증서를 제시. 게이트웨이가 PKI로 검증. 미인증 장비는 연결 단계에서 차단. |
| 역할 기반 접근 제어 | 같은 OEM 장비라도 일반 정비사·딜러·OEM 엔지니어에 따라 허용 서비스가 다름. 인증서에 권한 정보 포함. |
| 원격 진단 채널 보호 | OTA나 원격 진단 시 TLS·DoIP 보안 채널로 통신. 물리 포트 없이도 진단이 가능하지만 인증 요건은 동일하게 적용. |
그런데 이 변화가 논란이 된 이유
Secure Gateway는 보안성을 높였지만, 동시에 전통적인 자동차 정비 생태계에 균열을 일으켰습니다.
대표적인 사례가 FCA(현 스텔란티스)의 SGW(Secure Gateway) 적용입니다. 2017년 이후 출시된 일부 피아트·크라이슬러 차량은 OEM 인증 없이는 Programming 관련 진단 기능을 사용할 수 없게 됐습니다. 독립 정비소가 기존에 쓰던 서드파티 진단기로는 일부 기능에 아예 접근이 되지 않는 상황이 생긴 겁니다.
보안과 접근권 사이의 균형이 쉽지 않습니다. 게이트웨이를 열면 공격 경로가 생기고, 게이트웨이를 닫으면 수리 생태계가 흔들립니다. 자동차 업계가 아직 정답을 찾는 중인 문제입니다.
시리즈 전체를 하나로 연결하면
이제 진단 통신 시리즈의 다섯 편이 하나의 흐름으로 연결됩니다.
1편에서 언급 · 5편에서 심화
3편
2편
4편 · 기술 시리즈
테스터가 OBD-II에 연결하는 순간부터 새 펌웨어가 ECU에서 실행되기까지, 이 네 개의 레이어가 순서대로 방어합니다. 하나라도 빠지면 공격자에게 기회가 생깁니다.
현업에서는 실제로 이렇게 경험한다
마무리 — 시리즈를 닫으며
진단 통신은 차량을 가장 깊은 레벨에서 제어할 수 있는 채널입니다.
그래서 그 채널을 지키는 보안 레이어도 가장 복잡합니다.
이 시리즈를 통해 UDS가 어떻게 동작하는지, Security Access가 왜 필요한지, Session이 어떻게 권한을 나누는지, Flashing이 얼마나 민감한 작업인지, 그리고 게이트웨이가 그 앞을 어떻게 지키는지를 살펴봤습니다.
이 모든 레이어가 맞물려야 "진단 통신이 안전하다"고 말할 수 있습니다. 그리고 자동차가 SDV·OTA 중심으로 발전할수록, 이 채널의 중요성과 공격자의 관심은 동시에 커질 것입니다.
핵심 요약
- 과거에는 OBD-II가 CAN 버스에 직접 연결되어 모든 ECU가 외부에 노출됐다
- 현재는 게이트웨이 ECU가 중간에서 진단 요청을 라우팅·필터링한다
- 게이트웨이는 비인가 ECU 접근, 도메인 간 비인가 접근, 고위험 서비스를 차단한다
- Physical Addressing(특정 ECU 지정)과 Functional Addressing(브로드캐스트)을 게이트웨이가 처리한다
- Secure Diagnostics는 인증서 기반으로 진단 장비를 인증하고 역할별 권한을 부여한다
- 게이트웨이 자체가 뚫리면 뒤의 모든 ECU가 노출 — 게이트웨이 보안이 가장 중요하다
- 진단 로그는 보안 감사와 침해 분석의 핵심 증거가 된다
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| SecOC는 왜 아직도 어려운 기술일까? (1) | 2026.05.16 |
|---|---|
| 자동차 ECU는 왜 HSM을 필요로 할까? (0) | 2026.05.13 |
| 차량 ECU 업데이트는 실제로 어떻게 진행될까? (Flashing 구조 이해하기) (0) | 2026.05.13 |
| UDS의 Diagnostic Session은 왜 필요할까?(ECU 진단 권한을 나누는 방법) (0) | 2026.05.13 |
| 자동차는 왜 진단 인증(Security Access)을 사용할까? (0) | 2026.05.12 |