"차량 보안의 핵심은 결국 '키 보호'다 — HSM 구조(심화)"

현업에서 보는 차량 보안 기술

차량 보안 기술을 공부하다 보면 이런 질문을 만나게 됩니다.

Secure Boot, OTA 무결성 검증, 전자서명, SecOC. 이 기술들이 어떻게 동작하는지는 이해했습니다. 그런데 계속 이런 의문이 남습니다.

"그래서 이 암호키는 ECU 안 어디에 저장하는 건데?"

차량 보안의 진짜 핵심은 암호 알고리즘이 아닙니다.

"암호키를 얼마나 안전하게 보호할 수 있는가"입니다.

그리고 그 답이 바로 HSM(Hardware Security Module)입니다.

---

왜 키 보호가 핵심인가

AES-256이든 RSA-4096이든 ECC P-384든 — 알고리즘 자체는 충분히 강합니다. 현실적으로 수학적 공격으로 뚫기는 거의 불가능합니다.

그런데 공격자는 알고리즘을 뚫으려 하지 않습니다. 키를 훔치려 합니다.

먼저 정확히 알고 넘어갈 것 — 어떤 키가 ECU에 있나:

OEM 서명용 Private Key는 ECU 안에 없습니다. OEM 서버(HSM)에 안전하게 보관됩니다.
ECU 안에는 검증용 Public Key와 대칭키(SecOC, AES 세션키 등)가 들어갑니다.
그래서 공격 대상도 이 두 가지입니다.

공격 시나리오 A — ECU의 Public Key를 바꿔치기

ECU
물리 접근

→

Debug Port
연결

→

Flash에서
Public Key 교체

→

공격자 키로
서명한 Firmware

→

Secure Boot
우회 성공

Public Key를 공격자 것으로 교체 → 공격자가 서명한 악성 Firmware도 "정상"으로 통과

공격 시나리오 B — ECU의 대칭키(SecOC·세션키) 탈취

ECU
물리 접근

→

Flash
Dump

→

AES 대칭키
추출

→

가짜 메시지
MAC 생성

→

SecOC
무력화

대칭키 탈취 → 공격자가 정상 MAC이 붙은 가짜 CAN 메시지 생성 가능

⚠️ 일반 Flash 영역의 문제:
CPU나 Debug Interface를 통해 읽히거나 변경될 수 있습니다. Public Key 교체, 대칭키 탈취 — 둘 다 HSM 없이는 막기 어렵습니다.

---

HSM — 핵심 철학은 단순하다

HSM이 해결하는 방법은 명확합니다.

✅ 암호키를 일반 CPU 영역과 물리적으로 분리해서 보호한다.

CPU가 키를 직접 만지지 못하게 합니다. CPU는 "암호 연산 요청"만 할 수 있고, 키 원문은 HSM 밖으로 나오지 않습니다.

HSM 구조 — CPU와 키의 분리

Main CPU / Application

"이 데이터 서명해줘" / "이 서명 검증해줘" — 요청만 가능

↕ 요청(Request) / 결과(Result)만 교환
Key 원문은 절대 이 경계를 넘지 않음

🔒 HSM — 격리된 보안 영역

🗝️

Secure Key
Storage

⚡

Crypto
Engine

🎲

TRNG
난수 생성

🛡️

Secure
Boot 지원

🧠

Secure
RAM

⚠️

Tamper
Protection

Public Key·대칭키는 HSM 내부에서만 사용 — 외부로 직접 노출 불가

---

HSM 내부에는 뭐가 있나

HSM은 단순한 보안 저장소가 아닙니다. ECU 안의 작은 보안 컴퓨터에 가깝습니다.

🗝️

Secure Key Storage

암호키를 외부에서 읽을 수 없는 영역에 보관. Firmware Dump로 추출 불가

⚡

Crypto Engine

AES·RSA·ECC·SHA 연산 가속. CPU 부담 없이 빠른 암호 처리

🎲

TRNG

True Random Number Generator. 예측 불가능한 난수 생성. 키 생성·Challenge에 필수

🧠

Secure RAM

민감 데이터 임시 저장. HSM 내부에서만 접근 가능

🛡️

Secure Boot 지원

부팅 시 Firmware 무결성 검증. Chain of Trust 시작점

⚠️

Tamper Protection

물리적 공격·전압 조작 감지 시 키 자동 삭제. 하드웨어 수준 방어

---

CPU와 HSM — 실제로 어떻게 동작하나

HSM이 있으면 CPU가 키를 직접 사용하는 방식과 어떻게 달라지는지 비교해봅니다.

키 사용 방식 비교 — HSM 없음 vs HSM 있음

❌ HSM 없음

CPU가 Flash에서 Private Key 읽기

Key가 CPU 메모리에 올라옴

CPU가 직접 서명 연산 수행

메모리 덤프로 Key 탈취 가능

VS

✅ HSM 있음

CPU가 HSM에 "서명해줘" 요청

Key는 HSM 내부에만 존재

HSM 내부에서 서명 연산

결과(Signature)만 CPU에 전달

핵심: CPU가 해킹되더라도 HSM 내부의 Private Key는 접근 불가입니다. 공격자가 CPU 메모리를 전부 읽어도 키를 찾을 수 없습니다.

---

차량에서 HSM이 쓰이는 곳

생각보다 훨씬 많은 곳에 들어갑니다.

차량 기술	HSM 역할	없으면 어떻게 되나
Secure Boot	Firmware 서명 검증, 공개키 보호	공개키 조작으로 Secure Boot 우회 가능
OTA	인증서·서명 검증, 세션키 관리	가짜 OTA 패키지 설치 가능
SecOC	MAC 생성·검증 (AES 기반)	메시지 위변조 탐지 불가
TLS 통신	세션 키 및 인증 처리	중간자 공격에 노출
Secure Debug	Debug 인증 Challenge-Response	무제한 Debug 접근 허용
Key Provisioning	생산 라인에서 안전한 키 주입	생산 단계 키 유출 위험

---

SHE vs HSM — 현업에서 자주 헷갈리는 것

특히 AUTOSAR Classic 환경을 다루는 분들이 자주 혼동합니다.

항목	SHE	HSM
풀네임	Secure Hardware Extension	Hardware Security Module
목적	경량 보안 기능	확장형 보안 플랫폼
주요 알고리즘	AES-128 중심	AES·RSA·ECC·Hash 모두 지원
PKI / 인증서	지원 제한적	강력 지원
주 적용 환경	Classic ECU (CAN 중심)	고성능 ECU, Domain Controller, SoC
SDV 적합성	제한적	높음

SDV 시대로 갈수록 PKI·인증서·전자서명 요구가 커집니다. SHE만으로는 커버가 어려워지고, HSM 기반 구조로 이동하는 흐름이 계속되고 있습니다.

---

TEE — HSM과 비슷해 보이지만 다르다

SDV 시대 차량에서 HSM과 함께 자주 등장하는 개념이 있습니다. TEE(Trusted Execution Environment)입니다. 둘 다 "보안 영역 분리"라는 말이 나오지만 역할과 위치가 다릅니다.

하드웨어 기반

HSM

Hardware Security Module

물리적으로 분리된 전용 보안 칩입니다. Main CPU와 완전히 독립된 하드웨어입니다.

• 별도 CPU·메모리·전원
• 키가 물리적으로 격리
• Tamper 감지·자동 삭제
• 암호 연산 전용 가속기
• AUTOSAR Classic·Adaptive 모두 활용

→ 키 보호 최강. 하드웨어 수준 격리

소프트웨어 기반 (ARM TrustZone 등)

TEE

Trusted Execution Environment

같은 CPU 안에서 Normal World와 Secure World를 논리적으로 분리합니다.

• 같은 칩, 논리적 분리
• Linux(Normal)와 TA(Trusted App) 분리
• 보안 앱을 격리 환경에서 실행
• ARM TrustZone이 대표적
• SDV SoC 환경에서 많이 활용

→ 유연한 보안 앱 실행. 소프트웨어 격리

HSM vs TEE — 한눈에 비교

격리 방식	하드웨어 — 물리적 별도 칩	소프트웨어 — 논리적 분리(TrustZone)
주 역할	키 보호·암호 연산	보안 앱 격리 실행
보안 강도	매우 높음 (물리 공격도 방어)	높음 (SW 공격 방어, 물리는 제한적)
유연성	고정된 기능 중심	Trusted App 추가 가능
차량 활용	Secure Boot·키 관리·SecOC	DRM·결제·보안 서비스 격리

✅ SDV 시대 차량에서는 둘을 함께 쓰는 경우가 많습니다.

HSM이 키 보호·Secure Boot 같은 하드웨어 신뢰 기반을 담당하고, TEE가 그 위에서 보안이 필요한 소프트웨어 서비스(결제, DRM, 인증 앱 등)를 격리 실행하는 구조입니다.

---

SDV 시대 — HSM이 Root of Trust가 된다

SDV 시대 차량은 중앙집중형 E/E 아키텍처, Linux 기반 SoC, Cloud 연결, OTA 지속 업데이트로 이동합니다. 사실상 "움직이는 서버"에 가깝습니다.

서버에 HSM(TPM)이 있듯, 차량에서도 HSM이 신뢰의 출발점 — Root of Trust — 역할을 맡기 시작했습니다.

SDV 시대 — HSM이 Root of Trust로서 지원하는 것들

🔒 HSM — Root of Trust

차량 보안 신뢰의 출발점

Secure Boot
Chain of Trust

OTA
무결성 검증

차량 ID·
인증서 관리

SecOC
메시지 인증

TLS·PKI
통신 보안

Secure Debug
접근 통제

✅ HSM이 Root of Trust인 이유:
차량 내 모든 보안 기능의 신뢰 체인이 HSM에 저장된 키에서 시작됩니다. HSM이 신뢰할 수 없으면 그 위에 쌓인 보안 기능 전체가 흔들립니다.

---

현업에서는 이렇게 느낀다

현업 경험 4가지

암호 알고리즘보다 Key Protection이 더 중요하다 — AES-256이냐 AES-128이냐 논쟁보다, "그 키가 HSM에 있는가 Flash에 있는가"가 실제 보안 수준을 가릅니다.

Secure Boot·OTA·SecOC 대부분이 HSM 없이는 완전하지 않다 — 기능 구현은 되어도, 키가 Flash에 있으면 공격자가 그 키를 탈취하거나 교체할 수 있습니다.

SHE·HSM·Secure Element·TPM 개념이 현업에서 자주 혼동된다 — 역할은 비슷해 보이지만 지원하는 알고리즘, 적용 환경, 성능 수준이 꽤 다릅니다. 프로젝트 초반에 정확히 확인해야 합니다.

SDV로 갈수록 HSM 요구사항이 복잡해진다 — 키 종류가 늘어나고, 인증서 관리·Lifecycle·갱신까지 고려해야 합니다. HSM 설계를 나중으로 미루면 아키텍처 변경이 어려워집니다.

---

마무리

차량 보안은 결국
"얼마나 강한 암호를 쓰느냐"보다,
"암호키를 얼마나 안전하게 보호할 수 있느냐"의 문제입니다.

HSM은 그 답입니다.

Secure Boot, OTA, 전자서명, SecOC. 현대 차량 보안 기술 대부분은 결국 "누가 키를 믿을 수 있는가" 위에서 동작합니다.

그리고 그 신뢰의 출발점이 HSM입니다.

핵심 요약

1

차량 보안의 핵심은 알고리즘이 아닌 키 보호 — Private Key가 유출되면 모든 보안이 무너집니다

2

HSM = CPU와 키를 물리적으로 분리 — 키는 HSM 내부에서만 사용, 외부로 절대 노출되지 않습니다

3

HSM은 단순 저장소가 아닌 작은 보안 컴퓨터 — Crypto Engine·TRNG·Tamper Protection까지 포함합니다

4

SHE는 경량 구조, HSM은 확장형 보안 플랫폼 — SDV 시대에는 PKI·인증서 지원이 필요해 HSM 중요도가 커집니다

5

SDV 시대 HSM = Root of Trust — Secure Boot·OTA·SecOC·TLS 모두 HSM이 신뢰의 출발점이 됩니다

HSM HardwareSecurityModule SecureBoot 차량사이버보안 KeyManagement SHE RootOfTrust OTA보안 SecOC SDV