Security Tech

차량 사이버 보안 - 진단 프로토콜 및 보안 기능

작성자 - 이토란

차량에서는 여러가지 다양한 프로토콜을 사용하고, 또 그 중에서 진단 통신을 위해 사용되는 여러 프로토콜이 존재한다.
본 게시물에서는 진단 통신을 위한 프로토콜인 UDS, ISO-TP 에 대해서 설명하고, 실제 차량에서는 어떠한 보안적 기능들이 존재하는지 함께 살펴보도록하겠다.

1-1. Protocol - UDS

UDS 개요

UDS(Unified Diagnostic Services) 진단 통신 프로토콜

프로토콜 계층 위치

응용계층 (OSI 7계층 중 7계층 해당)
차량 ECU가 진단 요청을 주고받을 수 있게 만든 상위 계층의 응용 프로토콜

목적

진단 장비(Diagnostic Tool)와 ECU 간에 진단, 설정, 제어 작업을 수행
DTC (Diagnostic Trouble Code) 판독
소프트웨어(펌웨어) 업데이트
ECU 내부 데이터 및 정보 조회

메시지 구조

메시지 형식: Client(ex 진단기) – Server (ex ECU)
- Request – Response 통신

사용 예시

진단 코드 읽기, ECU 리셋, SW 업데이트, 보안 인증 등

SID (Service ID)

UDS는 아래와 같이 SID를 사용해 서비스를 구분함

긍정 응답 SID: 요청 성공, 요청 SID + 0x40
부정 응답 SID: 요청 실패, 0x7F

통신 예시

1-2 Protocol - ISO-TP

개요

CAN Data 프레임의 최대 전송 길이인 8Bytes를 넘는 데이터를 분할하고 재조합하는 프로토콜

CAN은 기본적으로 한 프레임 당 최대 8바이트 까지 전송 가능
그러나 UDS 응답은 보통 데이터의 크기가 그 이상인 경우가 다수
따라서 ISO-TP 프로토콜을 이용해 여러 CAN 프레임으로 나눠서 전송함

ISO-TP의 프레임은 다음과 같이 구성되어 있음.

용어

프레임 유형	내용
SF (Single Frame)	데이터가 7바이트 이하일 때, 하나의 CAN 프레임으로 전송
FF (First Frame)	데이터가 8바이트 초과일 때, 첫 번째 프레임 (전체 길이 포함)
CF (Consecutive Frame)	두 번째 이후의 연속된 데이터 프레임
FC (Flow Control)	수신 측이 보낸 메시지 제어

First Frame (FF)

CAN 데이터 (8바이트)

10 14 62 F1 90 4A 4B 43

10 → FF 표시 + 상위 nibble (0x1 = FF)
14 → 전체 메시지 길이 0x14 = 20 bytes (최종적으로 전송할 데이터 크기)
그 뒤 6바이트는 본문 시작

Flow Control (FC)

수신 측이 전송

진단 장비가 응답:

30 00 14 00 00 00 00 00

30 → FC 표시 (0x3 = Flow Control) / Continue To Send (CTS = 0, Wait = 1, Overflow = 2)
00 → Block Size ( 연속으로 몇 개의 CF를 보내도 되는지, 00이면 계속 보내도 된다는 뜻)
14 → ST min ( Separation Time Minimum) 각 CF 사이에 최소 몇 ms를 기다릴지 설정

Consecutive Frames (CF)

나머지 데이터 전송

CF #1

21 32 31 42 56 31 58 59

21 → CF 표시 (0x2 = CF) + 순서 번호 1

CF #2

22 5A 33 34 35 36 00 00

22 → 순서 번호 2
나머지는 남은 데이터 + 패딩

[ECU → 진단기]
FF: 10 14 62 F1 90 4A 4B 43

[진단기 → ECU]
FC: 30 00 14 00 00 00 00 00

[ECU → 진단기]
CF1: 21 32 31 42 56 31 58 59  
CF2: 22 5A 33 34 35 36 00 00

→ 진단 장비는 이걸 받아서 하나의 UDS 응답 메시지로 재조립

이렇게 진단에 사용되는 프로토콜인 UDS와 ISO-TP에 대해 알아보았다. 다음으로는 보안 기능들에 대해서 작성해보도록 할 것이다.

2-1. HSM

HSM (Hardware Security Module)

정의: 암호 키를 안전하게 만들고(생성), 보관하고(저장), 쓰는(연산) 일을 별도 하드웨어 경계 안에서 수행하는 보안 전용 모듈

주요 기능

암호 연산 가속
- 대칭키, 해시, 비대칭키를 하드웨어에서 처리하여 속도,안전성 확보
키 관리
- 키 생성, 저장, 사용, 폐기를 안전하게 관리
- 키는 HSM 내부에서만 사용 가능
난수 생성(TRNG): 보안 수준이 높은 키와 시드(seed) 생성에 필요한 랜덤 값 제공
SecureBoot 지원
- ECU 부팅 시 소프트웨어 무결성을 검증하여 변조된 코드 실행 방지
Secure Flash
- 펌웨어 업데이트 시 암호화·서명 검증을 수행해 변조·위조·롤백 공격 차단
디버그 및 접근 제어
- JTAG 등 디버그 인터페이스 보호, ECU 접근 인증 기능 제공

주요 특징

하드웨어 격리
- 메인 프로세서와 독립된 보안 영역으로 동작, 보안 연산과 키를 분리 관리
보안 속성 기반 키 관리
- 키마다 용도(ex 서명 전용, 검증 전용), 교체 주기, 내보내기 여부 등을 속성으로 정의해 관리
롤백 방지
- 모노토닉 카운터를 활용해 낮은 버전 소프트웨어나 키가 다시 주입되는 것을 차단

2-2. Seed&Key

ECU에는 인가 되지 않은 사용자의 접근을 제어하기 위한 기능이 필요하다.

그렇기 때문에 Security Access 서비스 (SID: 0x27)를 지원한다.

Security Access (SID: 0x27)

Security Acess 서비스는 외부 사용자의 ECU 내부 데이터 및 진단 서비스의 접근 권한을 제어한다. 보안 표준에 위배 되는 루트 접근 시도를 하거나 부적절한 데이터를 다운로드하게 되면 ECU나 차량 내부 구성 요소를 손상 시켜 운전자의 안전을 위협할 수 있다. 때문에 외부 사용자는 Security Access 서비스를 통해 보안 엑세스 권한을 받은 후 ECU의 내부 데이터를 수정, 삭제 또는 업데이트를 할 수 있어야 한다.

Seed & Key 알고리즘 작동 방식

클라이언트가 서버에게 Session 요청(Extension,Programming)
서버가 긍정 응답 전송 → Session 진입
클라이언트가 서버에 Seed 요청
Seed 전송 (긍정 응답)
클라이언트는 Seed를 기반으로 계산된 Key를 생성하고 해당 키를 서버에 전송
클라이언트가 올바른 알고리즘을 사용해 Key를 생성한 후, 서버는 Key가 유효하고, 잠금이 해제되었다고 긍정 응답

NSK (Normal Seed Key), ASK (Advanced Seed Key)

NSK: 2byte의 난수 사용

ASK: 8Byte의 난수 사용

긍정 응답(Positive Response), 부정 응답(Negative Response)

긍정 응답 시, 요청 SID + 0x40

부정 응답 시, 0x7F + NRC

NRC (Negative Response Codes)

UDS 프로토콜에서는 특정 오류 코드의 의미를 파악하는데 도움을 제공하며, 아래 NRC 코드를 통해 오류의 원인을 파악한다.

2-3. Secure Boot

개요

Secure Boot는 ECU나 임베디드 시스템이 부팅될 때, 실행하려는 소프트웨어가 위·변조되지 않았는지 검증한 후에만 실행을 허용하는 보안 메커니즘이다.

디지털 서명 기반 무결성 검증으로 인증된 소프트웨어만 실행 가능

작동 방식

Secure Boot는 부팅 시 실행되는 각 소프트웨어 컴포넌트의 디지털 서명을 검증함. 부트로더, 커널, 운영 체제 등을 포함한 부팅 단계에서 다음 단계로 넘어가기 전에, 현재 단계의 소프트웨어가 신뢰할 수 있는 서명으로 서명되었는지 확인

동작 원리

소프트웨어 로드 과정에서 무결성을 검증하는 방법으로는 공개키 암호 기반의 전자서명과 해시 함수 같은 암호학적 방법이 사용됨. 부팅 과정에서 메모리에 소프트웨어를 로드할 때, 해당 소프트웨어의 해시값과 인증서를 공개키로 복호화하여 나온 값이 같다면 로드를 하고 아니라면 로드를 하지 않음

2-4. Secure Flash

개요

Secure Flash는 펌웨어 업데이트 시 무단 접근 및 변조를 방지하기 위해 암호화, 무결성 검증, 인증 등의 보안 기능을 제공한다. 펌웨어는 안전하게 전송, 검증 저장되어 신뢰할 수 있는 업데이트를 보장한다. 이를 통해 차량 제어 시스템의 안전성과 안정성을 유지한다.

종류

Secure Flash 1.0
- 서명 검증 수행
Secure Flash 2.0
- 서명 검증 + 펌웨어 암복호화 지원

동작 절차

Secure Flash는 업데이트 예정인 소프트웨어를 확인하기 위해서는 공개키 암호 기반의 전자 서명과 해시 함수 같은 암호학적으로 안전한 방법이 사용됨
자동차 소프트웨어 생산업체에서 업데이트 예정인 소프트웨어에 개인키를 사용한 전자서명을 하고, 제어기에서는 사전에 주입된 공개키를 이용하여 전달받은 소프트웨어의 출처를 확인하며, 해시 함수를 사용하여 해당 소프트웨어가 변경되지 않았는지 확인함. 이를 통해 변경되지 않은 소프트웨어가 정상적인 발송처로부터 온 것을 확인한 후 해당 소프트웨어를 반영함

서버 측 작업

Salt 및 PSK를 인자로 키 유도 함수를 수행하여 펌웨어 암복호화 KEY 생성 (PBKDF2 활용)
도출된 Key의 MAC 값 생성 (CMAC/HMAC 활용)
도출된 Key를 가지고 펌웨어 암호화 (AES 활용)
암호화 하기 전 펌웨어(원본 펌웨어) 를 가지고 SHA256 알고리즘 (해시 알고리즘)을 수행하여 Hash A값 생성 (Hash 활용)
Private Key(개인키)와 Hash A를 인자로 서명 생성 (RSA 활용)
Salt, MAC, 암호화된 펌웨어, 전자 서명을 제어기로 송신 (Salt, Mac을 합쳐서 Meta Data 라고 부름)

PBKDF2 = HASH 함수를 사용하는 패스워드 변환기
- 펌웨어 암호화 시 사용되는 대칭키는 PBKDF2를 사용해 생성함.

제어기 측 작업

서버로부터 전달 받은 Salt, Mac, 암호화된 펌웨어, 전자 서명을 메모리에 저장
Salt 및 PSK를 인자로 키 유도 함수를 수행하여 펌웨어 암복호화 Key 생성 (PBKDF2 활용)
생성된 Key와 전달받은 MAC값을 가지고 Key가 제대로 생성되었는지 확인
1. Key의 무결성이 확인되었다면 Key를 가지고 펌웨어 복호화 수행 (AES 활용)
복호화 한 펌웨어 가지고 SHA256 알고리즘 수행하여 Hash값 B 생성
서버로 부터 전달받은 전자 서명 검증 수행
1. 전자 서명을 공개키를 이용해 복호화 하여 Hash A 획득
2. Hash A 와 Hash B가 같은 경우에만 전자서명 검증 성공

이렇게 해서 차량 진단에 사용되는 기본적인 프로토콜과 보안적 기능들에 대해 살펴보았다. 더욱 다양한 프로토콜과 기능들이 존재하지만 다음 게시글에서 추가적으로 작성해보도록 하겠다.

저작자표시 비영리 (새창열림)

'Security Tech' 카테고리의 다른 글

Frida 스크립트 작성 기초(안드로이드 예제) (0)	2025.08.31
웹 LLM 공격 (0)	2025.06.30
MITM RELAY 를 활용한 TCP 패킷 변조 (0)	2025.06.30
OWASP - MASTG UnCrackable-LEVEL 3 (2) (0)	2025.05.31
[Mobile] QuarkEngine 툴 소개 및 사용법 (0)	2025.05.31

Contents