차량 ECU는 암호키를 어디에 보관할까? — Secure Storage 쉽게 이해하기

보안 기술 — 키 보호

키 보관에 대해 자주 듣는 말

"HSM이 있으면 키는 다 HSM에 저장되는 거 아닌가요?"

"Flash에 키 저장하면 안 되는 이유가 뭔가요? 암호화하면 괜찮지 않나요?"

"SHE랑 HSM이랑 다른 건가요? 둘 다 키 저장하는 거 아닌가요?"

"Secure Storage가 따로 있는 건가요, 아니면 HSM 안에 있는 건가요?"

Secure Boot, SecOC, OTA 인증 — 차량 보안 기능들은 결국 하나에 의존한다. 암호키다.

그런데 정작 "그 키를 어디에, 어떻게 저장하는가"를 깊이 다룬 글은 많지 않다. 키를 잘못 보관하면 아무리 강력한 알고리즘도 무의미하다.

---

왜 키 저장이 중요한가 — 모든 보안은 키에서 무너진다

차량 ECU에서 사용하는 대표적인 보안 기능들을 보면 공통점이 있다.

보안 기능	사용하는 키	키가 유출되면
Secure Boot	BOOT_MAC_KEY (대칭) 또는 Root Public Key (비대칭)	악성 펌웨어를 정상으로 서명 가능
Secure Flashing	플래싱 인증 키	위조 소프트웨어를 정식 업데이트로 주입 가능
SecOC	메시지 MAC 생성 키	가짜 CAN 메시지를 정상으로 인증 가능
OTA	Trust Anchor, Private Key, Certificate	가짜 OTA 서버에서 악성 업데이트 배포 가능
Security Access (UDS)	Seed/Key 파생 비밀값	진단 세션 무단 접근 가능

⚠️ 키 유출 = 보안 기능 전체 무력화

AES-256이든 RSA-4096이든 알고리즘 자체가 아무리 강력해도, 키가 공격자 손에 들어가면 암호는 풀린다. 차량 보안에서 "어떤 알고리즘을 쓰는가"만큼 중요한 것이 "키를 어디에, 어떻게 저장하는가"다.

---

일반 Flash에 저장하면 왜 안 되는가

ECU에는 기본적으로 코드와 데이터를 저장하는 Flash 메모리가 있다. 여기에 키를 그냥 저장하면 어떤 일이 생길까.

일반 Flash 키 저장 시 공격 시나리오

1

물리적 접근 — 공격자가 ECU를 탈거해 JTAG, SWD, UART 같은 디버그 인터페이스로 접근한다. Secure Debug가 비활성화되어 있지 않다면 Flash 전체를 덤프할 수 있다.

2

Flash Dump — Flash 메모리를 그대로 읽어내면 평문으로 저장된 키가 노출된다. 암호화된 키라도 복호화 키가 같은 Flash에 있으면 의미가 없다.

3

키 활용 — 획득한 Secure Boot 키로 악성 펌웨어를 서명하거나, SecOC 키로 가짜 CAN 메시지를 생성하거나, OTA 키로 위조 업데이트를 배포할 수 있다.

❌ Flash에 암호화해서 저장하면 안전하다

✅ 암호화에 사용한 키(Key Encryption Key)도 안전하게 보관되어야 한다

Flash에 저장된 키를 암호화하는 방식은 유효하지만, 그 암호화에 사용한 Key Encryption Key(KEK)가 어디에 있는지가 핵심이다. KEK가 일반 Flash나 코드에 있다면 근본적인 문제가 해결되지 않는다. KEK는 반드시 하드웨어 보안 영역에 있어야 한다.

---

Secure Storage — ECU 안의 금고

Secure Storage는 암호키, 인증서, 보안에 민감한 설정값 등을 안전하게 저장하는 하드웨어 보안 영역이다. 일반 Flash와의 차이는 단순히 "더 안전한 메모리"가 아니라, 접근 제어 메커니즘이 하드웨어 수준에서 강제된다는 것이다.

💡 Secure Storage가 일반 Flash와 다른 핵심

일반 Flash — 접근 권한이 소프트웨어로 관리됨. 권한을 우회하는 공격이 가능.
Secure Storage — 접근 자체가 하드웨어 로직으로 제한됨. 정해진 인터페이스(API) 외에는 키를 직접 읽을 수 없음. 키가 Secure Storage 밖으로 나오지 않는 것이 핵심.

Secure Storage에 보관되는 대표적인 데이터는 암호키(대칭키·비대칭키), 인증서, Freshness Counter, 보안 설정값, 비밀 시드값 등이다.

---

차량 ECU의 Secure Storage 구현 방식 3가지

방식 1

HSM 내부 NVM

키가 HSM 전용 NVM에 저장되고 HSM 코어만 접근 가능. 외부 CPU는 키 값 자체를 볼 수 없고 HSM API를 통해 암호 연산 결과만 받는다.

✅ 보안 수준 최고 — 키가 HSM 밖으로 나오지 않음

⚠️ HSM 탑재 MCU 필요, 키 슬롯 수 제한

방식 2

암호화 후 Flash 저장

키를 KEK(Key Encryption Key)로 암호화해 일반 Flash에 저장. 사용 시 HSM이 복호화해 내부에서만 사용. KEK는 HSM 내부에 하드코딩되거나 OTP에 저장.

✅ 추가 NVM 필요 없음 — 비용 효율적

⚠️ KEK 보안이 전제 조건 / 구현 복잡도 증가

방식 3

외부 보안 칩 (SE)

별도의 Secure Element IC에 키를 저장. ECU와 보안 채널로 통신. 고가 차량·V2X·전기차 충전 인증 등 높은 보안이 필요한 영역에 활용.

✅ MCU와 물리적 분리 — 최고 수준의 격리

⚠️ 추가 부품 비용, 레이턴시 발생

---

SHE — 차량 MCU의 표준화된 Secure Storage 인터페이스

차량 MCU에서 Secure Storage를 이야기할 때 빠지지 않는 개념이 SHE(Secure Hardware Extension)다. AUTOSAR가 정의한 표준 사양으로, 차량용 MCU에 하드웨어 기반 키 저장과 AES-128 암호 연산을 통합하는 방법을 규정한다.

ℹ️ SHE의 세 가지 구성 요소 (AUTOSAR SHE 사양 기반)

1. Key Storage Area — 암호키와 관련 메타데이터를 저장하는 하드웨어 영역
2. AES-128 구현체 — 블록 암호 알고리즘 하드웨어 구현
3. Control Logic — CPU와 SHE를 연결하는 인터페이스 로직

SHE의 핵심은 Key Slot 구조다. 각 슬롯은 역할이 정해져 있고 접근 권한이 하드웨어 수준에서 제어된다.

SHE Key Slot 구조 (AUTOSAR SHE 사양 기반)

SECRET_KEY

MASTER_ECU_KEY — 다른 키 슬롯 업데이트 권한 보유. OEM이 생산 단계에 주입. 이후 잠금.

Root Key

BOOT_MAC_KEY

Secure Boot 무결성 검증용 키. 부트로더 MAC 생성·검증에 사용.

Boot

BOOT_MAC

기준 MAC 값 저장. Secure Boot 시 현재 부트로더 MAC과 비교.

Boot

KEY_1~10

일반 사용 키 슬롯 10개. SecOC MAC 키, 진단 인증 키, 통신 암호화 키 등에 활용.

General

RAM_KEY

휘발성 임시 키 슬롯. 전원 차단 시 소멸. 세션 키 등 일시적 용도.

Volatile

💡 SHE의 핵심 보호 원칙

SHE에 저장된 키는 외부로 반출(export)할 수 없다. CPU는 "이 키로 AES 연산을 수행해달라"고 SHE에 요청하고, 결과값만 받는다. 키 값 자체는 CPU 영역으로 나오지 않는다. 이것이 SHE 기반 Secure Storage의 가장 중요한 특성이다.

EVITA — SHE의 확장판

SHE가 AES-128 중심의 경량 구현이라면, EVITA(E-safety Vehicle Intrusion proTected Applications)는 더 높은 보안 수준을 위한 확장 사양이다. Light / Medium / Full 세 등급으로 나뉘며, Full은 비대칭 암호(RSA, ECC)까지 지원한다.

구분	SHE / EVITA Light	EVITA Medium	EVITA Full
대칭 암호	AES-128	AES-128/256	AES-128/256
비대칭 암호	미지원	RSA/ECC 일부	RSA, ECC 완전 지원
주요 용도	SecOC, Secure Boot	파워트레인 도메인	V2X, OTA, PKI 연동
대표 MCU	Renesas RH850 ICU-S NXP HSE (SHE 호환)	Renesas RH850 ICU-M Infineon AURIX TC3xx	Infineon AURIX TC4x NXP S32G

---

키 슬롯 업데이트 — Memory Update Protocol

SHE의 키 슬롯에 새 키를 주입하거나 업데이트할 때 단순히 값을 쓰는 것이 아니다. AUTOSAR SHE 사양은 Memory Update Protocol을 정의하고 있으며, M1~M5라는 5개의 메시지 블록을 통해 키 업데이트가 이루어진다.

SHE Memory Update Protocol (M1~M5) 흐름

M1

UID + Key ID + Auth Key ID — 어떤 ECU의 어떤 슬롯에 어떤 인증 키로 업데이트할지 식별 정보

M2

암호화된 새 키 + Counter — 새 키가 현재 MASTER_ECU_KEY로 암호화되어 전달됨. Counter로 리플레이 공격 방지

M3

MAC — M1+M2에 대한 인증 태그. 위변조 방지

M4/M5

검증 응답 — SHE가 업데이트 성공 후 생성하는 확인 메시지. 백엔드가 실제로 키가 주입됐는지 검증 가능

ℹ️ 이 프로토콜이 중요한 이유

MASTER_ECU_KEY를 모르면 다른 키 슬롯을 업데이트할 수 없다. 그리고 Counter 값 때문에 같은 메시지를 다시 보내는 Replay Attack도 차단된다. 즉 Secure Storage에 키를 주입하는 과정 자체도 보안이 적용된다.

---

Secure Storage와 주변 기술의 관계

차량 보안 기술에서 Secure Storage의 위치

Key
Provisioning
키 주입

→

Secure
Storage
키 보관

→

Secure Boot
SecOC
OTA 인증

→

Secure
Debug
접근 제어

Key Provisioning이 "언제, 어떻게 키를 주입하는가"라면, Secure Storage는 "주입된 키를 어떻게 안전하게 유지하는가"다. Secure Debug는 Secure Storage에 대한 비정상 접근 경로를 차단하는 역할을 한다.

---

🔧 현업에서 느끼는 것들

키 슬롯 설계를 초기에 잘못 잡으면 나중에 바꾸기 어렵다 — SHE의 키 슬롯 수는 제한적이다. SecOC용 키, Secure Boot용 키, Security Access용 키, OTA용 키를 어떤 슬롯에 어떻게 배치할지는 프로젝트 초기에 설계해야 한다. 나중에 추가하려면 슬롯이 부족해지는 경우가 생긴다. HSM 키 슬롯 설계는 요구사항 단계에서 시작해야 한다.

MASTER_ECU_KEY 관리가 실제로 가장 어렵다 — SHE에서 다른 모든 키 슬롯을 업데이트할 수 있는 루트 키가 MASTER_ECU_KEY다. 이 키가 유출되면 ECU의 모든 키를 교체할 수 있다. 생산 단계에서 이 키를 어떻게 주입하고, 어떻게 관리하며, 라인 직원이 접근하지 못하게 어떻게 막는가 — 이것이 Key Provisioning에서 가장 민감한 부분이다.

HSM이 있다고 Secure Storage 문제가 자동으로 해결되지는 않는다 — HSM을 탑재한 MCU를 쓰더라도 소프트웨어에서 키를 잘못 다루면 보안이 무너진다. 예를 들어 디버그 빌드에서 키를 로그로 찍거나, 테스트용 키를 양산 ECU에 그대로 사용하거나, 키를 RAM에 복사해서 사용하는 코드가 있는 경우들이다. 하드웨어 보안은 필요조건이지 충분조건이 아니다.

아무리 강력한 암호 알고리즘을 써도, 키를 잘못 보관하면 보안은 무너진다.

차량 보안의 신뢰 기반(Root of Trust)은 결국 Secure Storage에서 시작된다.

Secure Boot도, SecOC도, OTA 인증도 — 모두 Secure Storage 안에 안전하게 보관된 키에 의존한다.

핵심 요약

1

모든 차량 보안 기능은 키에 의존한다 — Secure Boot, SecOC, OTA, Security Access 모두 암호키 없이는 동작하지 않는다. 키가 유출되면 기능 전체가 무력화된다.

2

일반 Flash 저장은 키를 그대로 노출한다 — JTAG·디버그 포트·Flash Dump로 키를 그대로 획득 가능. Flash에 암호화해 저장해도 KEK 보안이 전제되어야 한다.

3

SHE는 차량 MCU의 표준 Secure Storage 인터페이스다 — AUTOSAR가 정의. 키 슬롯 구조, AES-128, Memory Update Protocol(M1~M5)로 구성. 키는 SHE 밖으로 나오지 않는다.

4

EVITA는 SHE의 확장으로 비대칭 암호를 지원한다 — Light/Medium/Full 3등급. Full은 RSA·ECC 지원으로 V2X·PKI 연동에 필요.

5

HSM 탑재 = Secure Storage 문제 해결이 아니다 — 하드웨어가 있어도 소프트웨어에서 키를 잘못 다루면 보안이 무너진다. 설계·구현·운영 모두에서 키 보호를 고려해야 한다.

SecureStorage SHE EVITA HSM 암호키보호 KeySlot AUTOSAR 차량사이버보안 RootOfTrust KeyProvisioning SecureBoot