ECU 재시작, 메모리 접근, 소프트웨어 교체까지 가능한 진단 통신.
그렇다면 이 채널에 아무나 접근할 수 있을까요?
당연히 안 됩니다.
ECU는 진단 요청자가 신뢰할 수 있는 대상인지 먼저 확인합니다.
이 인증 메커니즘이 바로 Security Access(서비스 ID 0x27)입니다.
왜 진단 통신에 인증이 필요할까
1편에서 UDS 서비스 중 펌웨어 다운로드(0x34), ECU 재시작(0x11), 액추에이터 제어(0x2F) 같은 기능을 살펴봤습니다. 이 기능들은 정비사나 OEM 개발자에게는 필수지만, 아무나 사용할 수 있으면 심각한 문제가 됩니다.
OBD-II 포트는 차량 운전석 하단에 있습니다. 물리 접근만 가능하면 누구든 연결할 수 있습니다. 렌터카, 주차된 차량, 정비소에 맡긴 차량 모두 해당됩니다. 여기에 인증 없이 강력한 진단 기능이 열려 있다면 어떤 일이 벌어질까요.
Security Access — 시드-키(Seed-Key) 메커니즘
Security Access(0x27)는 시드-키(Seed-Key) 방식으로 동작합니다. 개념은 단순합니다. ECU가 먼저 문제(시드)를 내고, 테스터가 정답(키)을 맞혀야 잠금이 해제됩니다.
ECU도 동일한 알고리즘으로 예상 Key를 계산해 대기합니다.
알고리즘은 어떻게 공유되는가
시드-키 메커니즘의 핵심은 테스터와 ECU가 동일한 알고리즘과 비밀 파라미터를 갖고 있다는 전제입니다. 그렇다면 이 알고리즘은 어떻게 공유될까요?
| 방식 | 구조 | 특징 |
|---|---|---|
| OEM 전용 알고리즘 | OEM이 자체 설계한 알고리즘을 ECU와 공식 진단 장비에만 탑재 | 가장 일반적. OEM 승인 장비만 인증 가능. 알고리즘 유출 시 보안 붕괴 |
| DLL 배포 방식 | OEM이 알고리즘을 DLL 형태로 공식 Tier-1·정비 장비 업체에 배포 | 서드파티 진단 장비 지원 가능. DLL 유출·리버싱 위험 있음 |
| HSM 기반 키 관리 | 비밀 파라미터를 ECU 내 HSM에 저장. 알고리즘은 공개해도 키는 보호 | 보안성 높음. 소프트웨어 분석으로 키 추출 불가 |
Security Access 레벨과 세션의 조합
Security Access는 단일 레벨이 아닙니다. 접근하려는 기능의 민감도에 따라 여러 레벨로 나뉩니다. 그리고 각 레벨은 특정 진단 세션과 조합해서만 동작합니다.
| 진단 세션 | Security Access 레벨 | 허용되는 대표 기능 |
|---|---|---|
| Default Session (0x01) | 없음 (인증 불필요) | DTC 읽기, 기본 데이터 조회 |
| Extended Session (0x03) | Level 0x01 (낮은 권한) | 파라미터 쓰기, 액추에이터 제어 |
| Programming Session (0x02) | Level 0x01 (중간 권한) | 플래싱 준비, 메모리 소거 |
| Level 0x03 (높은 권한) | 펌웨어 다운로드, 보안 설정 변경 |
Security Access의 한계 — 어떻게 뚫릴 수 있나
Security Access가 있다고 완벽하지는 않습니다. 실제로 악용된 방법들이 있습니다.
ECU 펌웨어를 덤프해서 시드-키 알고리즘을 분석합니다. 알고리즘이 단순하거나 하드코딩된 시크릿 파라미터가 있다면 모든 ECU에 대한 Key 계산이 가능해집니다. 튜닝 업체나 OBD 해킹 커뮤니티에서 실제로 사용되는 방법입니다.
Key 공간이 작으면 모든 경우의 수를 시도해 맞출 수 있습니다. UDS 표준에는 연속 실패 시 잠금(Delay 또는 Lock) 메커니즘이 정의되어 있지만, 구현하지 않은 ECU가 있습니다.
OEM이 배포한 진단 장비 소프트웨어나 DLL 파일에서 알고리즘을 추출합니다. 공식 정비 소프트웨어가 리버싱의 대상이 됩니다.
JTAG/SWD 디버그 포트가 잠기지 않은 ECU는 직접 메모리를 읽어 시크릿 파라미터를 추출할 수 있습니다. Secure Boot 편에서 다뤘던 디버그 포트 잠금이 여기서도 중요한 이유입니다.
Security Access의 한계를 넘은 — Authentication (0x29)
시드-키 방식의 Security Access는 수십 년간 사용됐지만 구조적 한계가 있습니다. UDS 2020(ISO 14229-1:2020)에서 새로운 서비스인 Authentication(0x29)이 추가된 이유입니다.
Authentication은 진단 장비가 OEM 발급 인증서를 제시하고, ECU가 이를 검증하는 방식입니다. IT 보안의 TLS 인증과 유사한 개념을 차량 진단에 적용한 것입니다. 알고리즘을 숨기는 대신 수학적으로 안전한 공개키 암호를 사용하기 때문에 알고리즘 리버싱 공격이 원천적으로 불가능합니다.
현업에서는 실제로 이렇게 경험한다
Security Access와 Secure Boot — 두 보안이 맞닿는 지점
이 시리즈의 다른 글인 Secure Boot와 Security Access는 서로 다른 위협을 막습니다. 하지만 목적은 하나입니다.
| 보안 기능 | 막는 것 | 언제 동작하는가 |
|---|---|---|
| Security Access | 외부에서 허가되지 않은 진단 접근 | 테스터가 ECU에 연결했을 때 |
| Secure Boot | 내부에서 변조된 소프트웨어 실행 | ECU가 부팅될 때 |
Security Access를 우회해 악성 펌웨어를 플래싱하는 데 성공했더라도, 다음 부팅 시 Secure Boot가 서명 검증에 실패해 실행을 차단합니다. 반대로 Secure Boot가 없으면 Security Access를 통과하는 순간 ECU는 무방비 상태가 됩니다. 두 기능은 서로의 빈틈을 보완하는 관계입니다.
마무리
Security Access는 "아는 자만 들어올 수 있다"는 원칙을 구현합니다.
하지만 "아는 자"의 범위를 어떻게 정의하고,
그 비밀을 어떻게 지키느냐가 실제 보안 수준을 결정합니다.
시드-키 방식은 구현이 단순하고 기존 인프라 없이도 동작한다는 장점이 있습니다. 하지만 비밀 알고리즘에 의존하는 구조적 한계가 있습니다. PKI 기반의 Authentication(0x29)이 그 한계를 넘는 방향이지만, 아직 대부분의 양산차는 Security Access 기반으로 동작합니다.
다음 편에서는 Security Access와 깊게 연결된 Diagnostic Session이 왜 필요하고 어떻게 설계되는지를 다룹니다.
핵심 요약
- Security Access(0x27)는 시드-키 메커니즘으로 진단 채널 접근을 제어한다
- ECU가 랜덤 Seed를 발급 → 테스터가 알고리즘으로 Key 계산 → ECU가 검증
- Seed는 매번 달라져 리플레이 공격을 차단한다
- 알고리즘 자체보다 비밀 파라미터를 어디에 저장하느냐가 실제 보안의 핵심
- HSM에 파라미터를 저장하면 소프트웨어 공격으로 추출 불가
- 주요 공격: 알고리즘 리버싱, 브루트 포스, DLL 추출, 물리 메모리 접근
- Authentication(0x29)은 PKI 기반으로 구조적 한계를 극복한 신규 방식
- 연속 실패 잠금(Attempt Counter) 미구현은 Pentest에서 반드시 지적되는 결함
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| 차량 ECU 업데이트는 실제로 어떻게 진행될까? (Flashing 구조 이해하기) (0) | 2026.05.13 |
|---|---|
| UDS의 Diagnostic Session은 왜 필요할까?(ECU 진단 권한을 나누는 방법) (0) | 2026.05.13 |
| 차량 ECU의 첫 번째 방어선 (Secure Boot는 어떻게 동작하는가) (0) | 2026.05.12 |
| 차량 OTA 업데이트, 어떻게 안전하게 할 수 있을까? (1) | 2026.05.12 |
| 자동차에도 방화벽이 존재할까? (0) | 2026.05.12 |