한 단어가 계속 등장합니다.
HSM.
"키는 HSM에 저장해야 한다",
"HSM 없이는 Secure Boot의 신뢰 기반이 없다",
"Security Access 파라미터를 HSM으로 보호해야 한다"…
도대체 HSM이 무엇이기에 모든 보안 기술의 기반으로 등장하는 걸까요?
오늘은 HSM을 처음부터 끝까지 풀어봅니다.
먼저 — 왜 암호 키가 그렇게 중요한가
차량 보안 기능의 대부분은 결국 암호 기술에 의존합니다. Secure Boot는 서명 검증을 위한 키가 필요하고, Security Access는 시드-키 연산의 비밀 파라미터가 필요하고, SecOC는 MAC 생성을 위한 공유 키가 필요합니다.
| 보안 기능 | 사용하는 키 | 키가 유출되면 |
|---|---|---|
| Secure Boot | OEM 공개키 (서명 검증) | 악성 펌웨어를 정상 코드처럼 서명 가능 |
| Security Access | 시드-키 알고리즘 비밀 파라미터 | 아무 Seed에 대해 유효한 Key 계산 가능 |
| SecOC | CAN 메시지 MAC용 공유 비밀키 | 공격자가 유효한 MAC 생성 → 위조 메시지 주입 |
| OTA / Secure Flash | 코드 서명 검증용 공개키 | 변조된 펌웨어를 정상으로 위장 가능 |
| TLS / 인증서 | 개인키 | 통신 내용 복호화 · 차량 위장 가능 |
HSM — Hardware Security Module
HSM(Hardware Security Module)은 암호화 연산과 보안 키를 하드웨어로 격리해서 보호하는 전용 보안 칩입니다. 자동차 ECU에서는 메인 MCU 안에 별도의 보안 서브시스템으로 내장됩니다.
핵심 개념은 격리(Isolation)입니다. HSM 안에 저장된 키와 HSM 안에서 수행되는 암호화 연산은 메인 CPU가 직접 접근할 수 없습니다. 소프트웨어가 아무리 침해당해도 HSM 내부는 영향을 받지 않습니다.
왜 소프트웨어로 키를 저장하면 안 되는가
키를 그냥 플래시 메모리에 저장하면 안 될까요? 읽기 보호를 걸면 되지 않을까요?
HSM이 차량 보안에서 실제로 하는 일들
부팅 시 소프트웨어 서명 검증에 쓰이는 OEM 공개키를 HSM이 보관합니다. Chain of Trust의 출발점이 됩니다. HSM이 없으면 Secure Boot의 신뢰 기반 자체가 없습니다.
CAN 메시지에 붙이는 MAC을 HSM이 생성하고 검증합니다. 공유 비밀키는 HSM 안에만 있고, 외부에서 키 없이 유효한 MAC을 만들 수 없습니다.
UDS Security Access의 시드-키 연산을 HSM이 수행합니다. 알고리즘의 비밀 파라미터가 HSM에 저장되어 있어 펌웨어를 덤프해도 파라미터를 추출할 수 없습니다.
OTA로 수신된 펌웨어 패키지의 디지털 서명을 HSM이 검증합니다. OEM 공개키가 HSM에 안전하게 보관되어 있어 서명 검증의 신뢰성이 보장됩니다.
펌웨어 다운그레이드를 막는 단조 카운터를 HSM이 관리합니다. 오직 증가만 가능하고 소프트웨어로 감소 불가. 하드웨어 보증이 없으면 카운터가 의미 없습니다.
Security Access Seed, 암호화 초기값 등 예측 불가능한 난수가 필요한 곳에 TRNG(True Random Number Generator)를 씁니다. 소프트웨어 난수보다 훨씬 예측하기 어렵습니다.
차량용 HSM은 일반 HSM과 무엇이 다른가
| 구분 | 서버용 HSM | 차량용 내장 HSM |
|---|---|---|
| 형태 | PCI 카드, USB 토큰, 네트워크 장비 | MCU 내부에 통합된 보안 서브시스템 |
| 표준 | FIPS 140-2/3 | EVITA, SHE (Secure Hardware Extension), AUTOSAR HSM |
| 동작 환경 | 안정적인 데이터센터 | -40°C ~ 125°C, 진동·EMI·전압 변동 |
| 응답 시간 | 수 ms 허용 | 수십 μs 이내 (실시간 ECU 제어 영향 최소화) |
| 비용 | 수백만 원대 | MCU 원가에 포함, 수 달러 수준 |
MCU 벤더별 차량용 HSM
차량 ECU에 가장 많이 쓰이는 MCU 벤더들은 각자의 HSM 구현을 제공합니다. 이름은 다르지만 역할은 같습니다.
| 벤더 | HSM 명칭 | 특징 | 주요 MCU |
|---|---|---|---|
| Infineon | HSM | AURIX 시리즈 내장. EVITA Full 수준 지원. 차량 보안 MCU 시장 점유율 1위 | TC3xx, TC4xx |
| NXP | CSE / HSE | S32K: CSE(SHE 기반), S32G/S32E: HSE(고급 기능·PKI 지원) | S32K, S32G, MPC57xx |
| Renesas | SCE / HSM | RH850: SCE, R-Car: 전용 HSM 코어 | RH850, R-Car |
| STMicroelectronics | HSM / SFI | SPC5x, Stellar 계열 내장 보안 모듈 | SPC58, Stellar |
HSM은 모든 차량 보안 기술의 기반이다
이 블로그에서 다뤄온 보안 기술들이 HSM과 어떻게 연결되는지 보면 왜 HSM이 계속 등장하는지 이해가 됩니다.
이 연결을 보면 명확해집니다. HSM은 특정 보안 기능 하나를 위한 것이 아닙니다. 차량의 모든 암호화 기반 보안 기능이 결국 HSM에 의존합니다. HSM이 없으면 이 모든 기술의 신뢰 기반이 흔들립니다.
현업에서는 실제로 이렇게 경험한다
SDV 시대에는 HSM이 왜 더 중요해지는가
SDV(Software Defined Vehicle) 시대로 갈수록 차량 내부 ECU뿐 아니라 클라우드·OTA·V2X·원격 진단까지 모두 암호 기반 신뢰 구조 위에서 동작하게 됩니다. 신뢰해야 할 대상이 늘어나고, 통신 경로가 복잡해질수록 각 지점의 키 보호가 더 중요해집니다.
그리고 이 변화가 자동차 보안의 중심축을 바꾸고 있습니다. 앞으로 차량 보안은 "코드를 얼마나 잘 짰는가"보다 "신뢰 체인(Chain of Trust)을 어떻게 보호하는가"가 더 중요해질 것입니다. HSM은 그 신뢰 체인의 출발점을 하드웨어로 못 박아두는 기술입니다.
마무리
HSM은 차량 사이버보안의 신뢰 기반입니다.
키가 안전하지 않으면, 그 키로 보호하는 모든 것이 안전하지 않습니다.
Secure Boot가 아무리 잘 구현돼도 검증에 쓰이는 키가 소프트웨어 덤프로 노출된다면 의미가 없습니다. SecOC가 메시지를 인증해도 공유 비밀키가 추출된다면 공격자가 유효한 MAC을 만들 수 있습니다. HSM은 그 모든 보안의 토대를 하드웨어로 못 박아두는 기술입니다.
핵심 요약
- 차량 보안 기능 대부분은 암호 키에 의존한다 — 키가 유출되면 보안 전체가 무너진다
- HSM은 암호화 키와 연산을 하드웨어로 격리하는 전용 보안 서브시스템이다
- 핵심 원칙 — 키는 HSM 밖으로 나오지 않는다. 연산 결과만 나온다
- 소프트웨어 키 저장의 한계 — 펌웨어 덤프, 소프트웨어 취약점, 부채널 공격에 취약
- HSM이 담당하는 기능: Secure Boot 신뢰 앵커, SecOC MAC, Security Access, OTA 서명 검증, 안티 롤백 카운터, TRNG
- 차량용 HSM 요구사항 — 낮은 레이턴시, 극한 환경 내구성, 저비용
- EVITA Light/Medium/Full이 차량용 HSM 기능 수준을 정의한다
- Secure Boot, SecOC, Secure Flash 모두 HSM이 없으면 신뢰 기반이 없다
- 키 프로비저닝은 공장 생산 단계에서 이루어지며 설계 초기부터 정의해야 한다
- SDV 시대 — 코드를 잘 짜는 것보다 신뢰 체인을 어떻게 보호하는가가 더 중요해진다
'차량 사이버보안 > 보안기술' 카테고리의 다른 글
| 자동차 ECU는 왜 Secure Debug가 필요할까?— 개발용 디버그 포트는 왜 양산 이후 위험이 되는가 (0) | 2026.05.20 |
|---|---|
| SecOC는 왜 아직도 어려운 기술일까? (1) | 2026.05.16 |
| Gateway ECU는 왜 진단 요청을 차단할까? (0) | 2026.05.13 |
| 차량 ECU 업데이트는 실제로 어떻게 진행될까? (Flashing 구조 이해하기) (0) | 2026.05.13 |
| UDS의 Diagnostic Session은 왜 필요할까?(ECU 진단 권한을 나누는 방법) (0) | 2026.05.13 |