차량 OBD 시스템 보안 취약점 분석: 실전 침투 테스트로 본 현실과 대책
본 포스트는 다음 학술 문서를 기반으로 공부 목적으로 요약 및 분석하여 작성한 포스트입니다.
현대 차량은 점점 더 정교한 전자 제어 시스템(ECU)에 의존하게 되었고, 그 중심에는 온보드 진단 시스템(OBD: On-Board Diagnostic)이 있습니다. 그러나 이러한 진단 인터페이스는 동시에 사이버보안의 새로운 공격 표면이 되고 있습니다. 본 학술 자료를 기반으로 실차 테스트에서 발견된 치명적인 보안 취약점들과 그 개선 방안을 요약합니다.
1️⃣ OBD Vs. UDS: 누가 보안에 더 취약한가?
- OBD(On-Board Diagnostic)는 주로 정비소가 연구 기관에서 사용하는 공개 표준 진단 프로토콜이며, 기본 CAN ID(0x07DF)를 통해 모든 ECU에 브로드캐스트됩니다.
- UDS(Unified Diagnostic Services)는 ECU 소프트웨어 업데이트, 캘리브레이션, 내부 테스트 등을 포함하는 제조사 전용 확장 진단 프로토콜입니다.
문제는 OBD와 UDS 모두 동일한 물리적 채널(DLC & CAN 버스)을 사용하면서도, 보안 정책은 완전히 다르다는 점입니다. 이로 인해 하나의 메시지가 두 영역에 모두 영향을 줄 수 있는 위험이 발생합니다.
2️⃣ 실차(차량) 실험으로 드러난 5가지 주요 취약점
#취약점1 : OBD 메시지로 UDS 명령 실행
- 0x07DF OBD CAN ID를 통해 UDS Diagnostic Session Control 명령(0x10 03)을 전송
- 일부 ECU는 이를 수신하고 진단 모드로 전환 → 차량 운행 불가 상태 유발
- 표준 ID로 제조사 고유 기능에 접근 가능 = 심각한 설계 오류
#취약점2 : Seed 값 고정 or 짧은 길이(2바이트)
- Seed 값이 고정되거나 반복되는 경우, 브루트포스 공격이 가능
- 계산 예: 2바이트일 경우 약 4시간 이내 공격 성공 가능
- TRNG 또는 강화된 PRNG 사용 필요
#취약점3 : 로그인 실패 카운트 저장 타이밍 오류
- 잘못된 Key 입력 후 응답 전 NVM 저장 수행
- 저장 직전 시점에 전원 차단 시도로 로그인 시도 무제한 공격 가능
- 응답 전에 모든 상태 저장 완료 필요
#취약점4 : 알고리즘 재사용
- 동일 제조사의 다른 ECU에 같은 key 계산 함수(f(seed)) 사용
- 한 ECU가 뚫리면, 같은 제조사 차량의 다른 ECU도 공격 가능
- ECU/차량 고유 정보 기반 key 도출 설계 필요
#취약점5 : 진단 메시지의 인증 부재
- 인증된 진단기가 SA 인증을 수행한 이후, MITM 공격자가 메시지 삽입 가능
- 현재 UDS는 TLS와 같은 완전한 인증 구조 미제공
3️⃣ 보안 강화를 위한 소프트웨어 요구사항
본 학술 자료에서는 현실적으로 구현 가능한 사이버보안 요구사항을 다음과 같이 제안합니다
1. UDS 명령은 OBD CAN ID에서 무효화
2. Seed는 64비트 이상의 고유 난수로 생성 (TRNG 또는 고급 PRNG)
3. 실패 횟수는 Seed 요청 시점에 증가 + 응답 이전에 영속화
4. 응답은 비동기식으로, 모든 로그 기록 후 전송
5. Key 계산식에 ECU 고유 식별자 포함 (SW 버전, VIN 등)
6. 진단 기능 별로 Security Level을 분리하여 인증 요구
7. Security Access 인증 세션 종료 명령 구현 → 타이머 없이 종료 가능
4️⃣ 결론 : OBD 보안, 지금 시작해야 할때
OBD 및 UDS 시스템의 보안 취약점은 CAN 통신의 평문 구조, 세션 기반 인증 한계, 그리고 진단 메시지에 대한 인증 부재에서 기인합니다. UNR.155와 ISO/SAE 21434는 이러한 문제들을 식별했지만, 구체적 기술 구현은 OEM과 Tier-1의 몫입니다.
이번 연구는 하나의 사실을 분명히 보여줍니다: 적절한 소프트웨어 설계와 테스트만으로도 대부분의 문제는 해결할 수 있습니다. 인증 대응뿐 아니라 실제 차량의 안전성을 보장하기 위해, 개발 초기 단계부터 진단 보안 설계가 필요합니다