차량에는 암호키가 몇 개나 들어있을까? — Secure Boot부터 OTA까지 자동차 키 관리의 모든 것

보안 기술 — 키 관리 · PKI 시리즈 完

PKI · 키 관리 시리즈

1

이전 글

차량 ECU는 어떻게 서로를 신뢰할까?

Vehicle PKI와 인증서 기초

DONE

2

지금 읽는 글 — 시리즈 完

차량에는 암호키가 몇 개나 들어있을까?

Secure Boot부터 OTA까지, 자동차 키 관리의 모든 것

NOW

키 관리 이야기할 때 자주 나오는 말

"차량에 암호키가 몇 개나 들어가요? 그냥 하나 아닌가요?"

"Secure Boot 키랑 OTA 키가 다른 건가요? 같은 키 쓰면 안 되나요?"

"RA가 뭔가요? CA랑 뭐가 달라요?"

"Private Key는 ECU 안에 있는 거 아닌가요?"

"차량에 암호키 하나쯤 들어가는 거 아닌가요?"

실제로는 다르다. 현대 차량 한 대에는 목적별로 분리된 수십 개의 암호키와 인증서가 존재한다. 그리고 그 중 가장 중요한 키들은 ECU 안에 없다.

---

먼저 — 왜 키를 목적별로 분리하는가

하나의 마스터 키로 모든 보안 기능을 처리하면 안 되는가. 기술적으로는 가능하지만 보안 원칙상 하지 않는다. 이유는 단순하다.

❌ 하나의 강력한 키로 모든 보안 기능을 처리하면 관리가 편하고 더 안전하다

✅ 키는 용도별로 반드시 분리해야 한다 — 하나가 유출되면 나머지는 안전해야 한다

Secure Boot 키가 OTA 키와 같다면, OTA 서버가 침해됐을 때 Secure Boot 보호도 함께 무너진다. 키를 용도별로 분리하면 한 키가 유출되더라도 피해 범위가 제한된다. 이것을 Key Separation 또는 Principle of Least Privilege라고 한다. 암호학에서 가장 기본적인 설계 원칙 중 하나다.

---

Vehicle PKI 구조 — CA와 RA의 역할

개별 키를 설명하기 전에 전체 PKI 구조를 먼저 이해해야 한다. 특히 RA(Registration Authority)는 실무에서 매우 중요하지만 설명이 빠진 경우가 많다.

Vehicle PKI 계층 구조 — 실무 기반

Root CA

전체 PKI 신뢰의 최상위 / 오프라인 HSM 보관 / 극도로 제한된 사용 빈도

Trust Anchor

↓ 서명 (Intermediate CA 인증서 발급)

Intermediate CA (기능별 분리)

Production CA / OTA CA / V2X CA / Diagnostic CA — 목적별로 분리 운영

위임된 신뢰

↓ 서명 (Issuing CA 또는 End Entity 인증서 발급)

Issuing CA + RA (Registration Authority)

RA — 신청자 신원 검증 (VIN·제조번호·생산이력 확인) | Issuing CA — 인증서 발급

신원 검증 + 발급

↓ 인증서 배포

End Entity — Vehicle Certificate / ECU Certificate / OTA Certificate

차량·ECU·업데이트 패키지 등 실제 사용 단계 인증서

End Entity

여기서 RA의 역할을 제대로 이해하는 것이 중요하다. CA는 인증서를 발급하지만, 신청자가 정말 그 신원을 가진 대상인지 확인하는 것은 RA가 담당한다.

RA (Registration Authority)

신원 검증 담당

생산 라인에서 ECU가 생성될 때 VIN·부품 번호·제조 이력·생산 공정 데이터를 확인한다. "이 ECU가 정말 우리가 만든 정품인가"를 검증하고 CA에 인증서 발급을 요청한다.

CA (Certificate Authority)

인증서 발급 담당

RA로부터 검증된 요청을 받아 인증서를 발급한다. RA가 없으면 CA는 신청자의 신원을 직접 확인해야 하는데, 대규모 생산 환경에서 이는 현실적으로 불가능하다.

💡 생산 라인에서 RA가 하는 일

ECU가 생산 라인을 통과할 때 RA는 제조 번호(부품 번호), VIN 연동 정보, 생산 이력 데이터를 검증한다. 검증이 완료되면 CA에 Vehicle Certificate 또는 ECU Certificate 발급을 요청하고, 발급된 인증서가 Key Injection 과정에서 ECU에 주입된다. Key Injection Key는 이 생산 공정 중 Secure Flash Tool에서 사용되며, OEM이 발급·관리한다.

---

ECU에 들어가는 키 — 기능별 완전 정리

1. Secure Boot

ECU 부팅 시 소프트웨어 무결성 검증

Secure Boot Public Key

비대칭 공개키

저장: ROM / OTP / Flash | 사용: 부팅 시 Bootloader 서명 검증

ECU 출고 시 탑재. OTP에 저장되면 이후 변경 불가. 이 키가 신뢰의 출발점이다.

Secure Boot Private Key

비대칭 개인키

저장: OEM·Tier1 KMS (서버) | 사용: 서명 생성 시 (개발 툴 환경)

ECU에 절대 저장되지 않는다. 서버 측 KMS에서만 존재. 유출 시 전체 Secure Boot 체계 붕괴.

2. Secure Flash (펌웨어 업데이트)

ECU Flash 이미지 암호화 및 서명 검증

Firmware Signing Private Key

비대칭 개인키

저장: FST (Secure Flash Tool, 서버 측) | 사용: Flash 이미지 서명 생성

ECU에 없음. 서버 측 보안 환경에서만 사용. Secure Boot Private Key와 별도로 관리.

Firmware Verify Public Key

비대칭 공개키

저장: Flash / ROM | 사용: Flash 이미지 서명 검증

ECU 내 저장. 서명 검증(Verify)에만 사용되므로 외부 노출 자체는 보안 위협이 아님. Firmware Signing Public Key로도 불리나 역할 기준으로는 Verify Key가 더 정확하다.

Secure Flash Encryption Key

대칭키 (AES)

저장: FST (서버 측) | 사용: 펌웨어 이미지 암호화

복호화 키와 쌍. 이 키로 암호화된 이미지를 ECU가 복호화하는 구조.

Secure Flash Decryption Key

대칭키 (AES)

저장: HSM / TEE 내부 | 사용: 펌웨어 수신 후 복호화

ECU 내 HSM에 저장. KDF Salt(Password) 방식으로 파생하기도 함. HSM 외부로 반출 불가.

3. OTA 업데이트

무선 소프트웨어 업데이트 무결성 및 발신자 인증

OTA Signing Private Key

비대칭 개인키

저장: OTA 서버 (KMS) | 사용: OTA 이미지 패키지 서명 생성

ECU에 절대 저장되지 않는다. 서버가 침해돼도 차량 내 키는 안전한 구조 설계.

OTA Verify Public Key

비대칭 공개키

저장: 서명 검증 ECU (TCU / Gateway 등) | 사용: OTA 패키지 서명 검증

OTA 이미지를 받을 때 이 키로 서명을 검증. 검증 실패 시 설치 거부. OTA Signing Public Key로도 불리나 역할 기준으로는 Verify Key가 더 정확하다.

4. Secure Storage

ECU 내 민감 데이터 암호화 보호

Secure Storage Key

대칭키 (AES)

저장: HSM / TEE / 암호화된 Flash | 사용: 민감 데이터 암호화·복호화

사용자 계정, 인증 토큰, 개인 설정 등 민감 정보 보호. OEM 또는 ECU 내부에서 생성.

5. 진단 인증

UDS Security Access — 인가된 접근만 허용

Secure Access Key (0x27)

Seed-Key 기반

저장: Flash / Config | 사용: 진단 인증 시 (UDS SID 0x27)

ECU가 Seed를 생성하면 진단기가 Key를 계산해 응답. 키 자체보다 알고리즘 보안이 핵심.

Secure Unlock Key (0x29)

비대칭 공개키 / 인증서 기반

저장: Flash / Config | 사용: Flash Unlock 시

0x27(Seed-Key 기반)과 달리 0x29는 인증서 기반 비대칭키 인증 방식을 사용하는 경우가 일반적. 더 높은 보안 레벨이 요구되는 개발자 모드 접근에 적합.

Secure Debug Unlock Key

Seed-Key 기반

저장: OTP / Config | 사용: Debug 포트 Unlock

공격자가 가장 노리는 키 중 하나. Debug 포트가 열리면 Secure Boot·암호화도 우회 가능.

6. IDS (침입탐지)

IDS 이벤트 보고의 무결성 및 채널 보안

IDS Comm Key

대칭 / TLS

저장: Secure Storage | 사용: IDS 이벤트 vSOC 전송 시

IDS → vSOC 통신 채널 암호화. TLS 기반. IDS 데이터가 중간에 위변조되지 않도록 보호.

IDS Signing Key

비대칭 개인키

저장: TEE / Secure Zone | 사용: IDS 로그 서명 (옵션)

IDS 로그 무결성 보장용. 서명이 없으면 공격자가 IDS 로그를 위조할 수 있다.

IDS Signing Certificate

X.509 인증서

저장: Flash / Secure Zone | 사용: vSOC에서 IDS 서명 검증

OEM CA가 발급. vSOC 측에서 이 인증서로 IDS 로그 서명을 검증한다.

---

차량 레벨에서 관리되는 키 — ECU가 아닌 차량 전체의 키

7. Vehicle Identity (차량 식별)

차량 자체를 클라우드·서버에서 인증

Vehicle Private Key

비대칭 개인키

저장: TCU / Gateway Secure Zone | 사용: TLS 핸드셰이크 시

차량 식별 및 서버 인증. mTLS에서 차량이 자신을 증명하는 데 사용. 유출 시 차량 가장 가능.

Vehicle Certificate

X.509 인증서

저장: Flash / Secure Area | 사용: TLS 세션 수립 시

OEM CA 발급. OEM 서버가 이 인증서로 "이 차량이 우리 고객 차량"임을 확인.

Root CA Certificate

X.509 인증서

저장: Gateway / ECU (신뢰 저장소) | 사용: 인증서 체인 검증 시

전체 PKI 신뢰 체인의 출발점. 출고 시 탑재. 교체 불가에 가깝게 관리해야 함.

Intermediate CA Certificate

X.509 인증서

저장: Gateway / TCU | 사용: 인증서 체인 검증

Root CA 하위 CA 인증서. 기능별(OTA, V2X, Production)로 분리된 Intermediate CA가 각각 존재할 수 있다.

8. V2X (차량 간 통신)

메시지 신뢰 + 프라이버시 동시 달성

Pseudonym Certificate

X.509 기반 단기 인증서

저장: V2X 모듈 Secure Storage | 사용: V2X 메시지 서명

IEEE 1609.2 기반. 일정 주기마다 교체 — 동일 인증서가 계속 사용되면 위치 추적이 가능하기 때문. SCMS(Security Credential Management System)가 발급·폐기 관리.

Long-Term Certificate (LTC)

X.509 인증서

저장: V2X 모듈 Secure Zone | 사용: Pseudonym Certificate 요청 시 신원 증명

SCMS에 Pseudonym Certificate를 요청할 때 차량 신원 증명에 사용. 차량 추적을 막기 위해 외부 통신에는 직접 사용하지 않음.

9. 생산 공정 (Manufacturing)

생산 라인에서만 사용되는 키

Key Injection Key

대칭 또는 공개키

저장: Secure Flash Tool | 사용: 생산 공정 중 키 배포

생산 라인에서 ECU에 키를 주입할 때 사용. OEM이 발급·관리. 생산 환경 외부로 유출되어서는 안 됨.

Secure Lock Seed

Seed 값

저장: OTP / Flash | 사용: Secure Lock 시

Flash Lock 관련. 생산 완료 후 ECU를 잠그는 데 사용. OEM 또는 제조사 관리.

---

전체 키 목록 한눈에 보기

키 이름	타입	저장 위치	사용 시점
Secure Boot Public Key	공개키	ECU (ROM/OTP)	부팅 시 서명 검증
Secure Boot Private Key	개인키	KMS (서버)	서명 생성 (개발 툴)
Firmware Signing Private Key	개인키	FST (서버)	Flash 이미지 서명
Firmware Verify Public Key	공개키	ECU (Flash/ROM)	Flash 이미지 서명 검증
Secure Flash Encryption Key	대칭 (AES)	FST (서버)	펌웨어 암호화
Secure Flash Decryption Key	대칭 (AES)	ECU (HSM/TEE)	펌웨어 복호화
OTA Signing Private Key	개인키	OTA 서버 (KMS)	OTA 패키지 서명
OTA Verify Public Key	공개키	ECU (TCU/GW)	OTA 패키지 검증
Secure Storage Key	대칭 (AES)	ECU (HSM/TEE)	민감 데이터 암·복호화
Secure Access Key (0x27)	Seed-Key	ECU (Flash/Config)	진단 인증
Secure Unlock Key (0x29)	비대칭/인증서	ECU (Flash/Config)	Flash Unlock
Secure Debug Unlock Key	Seed-Key	ECU (OTP/Config)	Debug 포트 Unlock
IDS Comm Key	대칭/TLS	Secure Storage	IDS → vSOC 채널 암호화
IDS Signing Key / Certificate	개인키 / 인증서	TEE / Secure Zone	IDS 로그 서명·검증
Vehicle Private Key	개인키	TCU/GW Secure Zone	TLS 핸드셰이크
Vehicle Certificate	인증서	Flash / Secure Area	TLS 세션 수립
Root CA Certificate	인증서	Gateway / ECU	인증서 체인 검증
Intermediate CA Certificate	인증서	Gateway / TCU	인증서 체인 검증
V2X Pseudonym Certificate	단기 인증서	V2X 모듈	V2X 메시지 서명
V2X Long-Term Certificate	인증서	V2X Secure Zone	SCMS 신원 증명
Key Injection Key	대칭/공개키	Secure Flash Tool	생산 공정 키 주입
Secure Lock Seed	Seed	OTP / Flash	생산 완료 후 ECU 잠금

---

가장 중요한 키는 차량 안에 없다

이 목록을 보고 나면 흥미로운 패턴이 보인다. 차량 보안을 실질적으로 결정하는 키들 — Root CA Private Key, Secure Boot Private Key, Firmware Signing Private Key, OTA Signing Private Key — 이것들은 모두 ECU 안에 없다. OEM의 KMS(Key Management System), HSM 서버, Secure Flash Tool에서 관리된다.

⚠️ Root CA Private Key 유출 시나리오

Root CA의 개인키가 유출되면 그 PKI 하에서 발급된 모든 인증서의 신뢰가 붕괴된다. 공격자가 원하는 대상에게 임의의 인증서를 발급할 수 있게 된다. 차량 수십만 대에 배포된 OTA 인증서, ECU 인증서, Vehicle Certificate 전체가 영향을 받는다. 이 때문에 Root CA는 오프라인 환경과 HSM에서 엄격하게 보관하고, Intermediate CA를 통해 일상 업무를 위임하는 구조를 사용한다.

---

🔧 현업에서 느끼는 것들

키 설계는 개발 초기에 끝내야 한다 — 나중에 바꾸기 극도로 어렵다 — 어떤 키를 어떤 슬롯에, 어떤 알고리즘으로, 어떤 길이로 넣을 것인가. HSM 슬롯 수는 제한적이고, OTP에 구운 키는 변경이 불가능하며, Key Injection 프로세스는 생산 라인과 연동되어 있다. 프로젝트 후반에 "키 구조를 바꾸자"는 말이 나오면 이미 늦은 경우가 많다.

Secure Debug Unlock Key를 양산 ECU에서 어떻게 처리하는가가 핵심이다 — 개발 단계에서는 Debug가 필요하다. 하지만 양산 차량에 Debug 포트가 열려 있으면 공격 표면이 된다. Secure Debug Unlock Key를 OTP에 굽고 양산 후 Debug 기능을 봉인하는 것이 일반적이지만, "AS 때 디버깅이 필요하면 어떻게 하나"는 항상 논쟁이 된다.

Key Injection 프로세스 보안이 생각보다 취약한 경우가 있다 — 생산 라인에서 ECU에 키를 주입하는 Secure Flash Tool과 환경이 충분히 보안되지 않은 경우가 있다. Key Injection Key가 생산 환경 밖으로 유출되거나, 생산 라인 PC가 인터넷에 연결되어 있거나, 로그가 남지 않는 경우. TARA에서 생산 단계 위협을 다루지 않으면 이 부분이 빠지게 된다.

Secure Boot, OTA, V2X, IDS — 모두 다른 기술처럼 보이지만 결국 하나로 연결된다.

"이 데이터를 만든 것이 정말 우리 OEM인가 — 그것을 누가, 어떻게 보증하는가."

그 보증 체계가 PKI이고, 그 보증의 근거가 키다. 차량 보안의 본질은 알고리즘이 아니라 키 관리다.

핵심 요약 — PKI · 키 관리 시리즈 完

1

현대 차량 한 대에는 20개 이상의 암호키·인증서가 존재한다 — Secure Boot, Secure Flash, OTA, 진단, IDS, Vehicle Identity, V2X, 제조 공정까지 목적별로 분리된다.

2

가장 중요한 키들은 ECU 안에 없다 — Root CA Private Key, Secure Boot/Firmware Signing Private Key, OTA Signing Private Key는 서버 측 KMS에서 관리된다.

3

RA는 신원 검증, CA는 인증서 발급으로 역할이 분리된다 — 생산 라인에서 RA가 ECU의 제조 정보를 검증하고 CA에 인증서 발급을 요청하는 구조다.

4

V2X는 Pseudonym Certificate로 신뢰와 프라이버시를 동시에 달성한다 — 동일 인증서를 계속 쓰면 위치 추적이 가능하므로 SCMS가 주기적으로 교체한다.

5

키 설계는 프로젝트 초기에 완료해야 한다 — HSM 슬롯, OTP 구성, Key Injection 프로세스는 나중에 바꾸기 극도로 어렵다. TARA에서 생산 단계 위협도 반드시 다뤄야 한다.

VehiclePKI 키관리 KeyManagement RootCA RA Certificate SecureBoot SecureFlash OTA보안 HSM V2X SCMS KeyInjection 자동차사이버보안