HSM 없는 MCU ECU, 어떻게 보안할까?— 외장 보안칩을 활용한 현실적인 구조

현업에서 보는 차량 보안 아키텍처

프로젝트에서 자주 듣는 말

"Secure Boot 해야 하는데 MCU에 HSM이 없어요."

"HSM 탑재 MCU로 바꾸면 원가랑 일정이 안 나옵니다."

"Key를 그냥 Flash에 넣으면 안 되는 건 알겠는데, 방법이 없어요."

"보드 설계 바꿔서 보안칩 하나 붙이는 방법은 안 될까요?"

이 질문들, 실제 프로젝트에서 나온 이야기입니다. 그리고 마지막 질문이 바로 이 글의 주제입니다.

MCU는 바꾸기 어렵다.
하지만 보드 설계를 수정해서 외장 보안칩을 추가하는 방법이 있다.
이게 현실적인 선택이 되는 경우가 생각보다 많다.

---

왜 HSM 없는 MCU가 아직도 많을까

차량 보안만 보면 최신 MCU + 내장 HSM + Secure Boot + HW Root of Trust 구조가 가장 이상적입니다. 하지만 실제 양산 개발은 다릅니다.

ℹ️ MCU 하나를 바꾸는 건 단순 부품 교체가 아닙니다.

PCB 변경 → Driver 수정 → AUTOSAR 재검증 → 양산 검증 → 공급망 변경까지 연결됩니다.

이미 양산 중이거나 기존 플랫폼을 유지해야 하는 프로젝트에서는 원가, 일정, 공급 안정성, 재인증 비용 때문에 MCU 교체 자체가 불가능한 경우가 많습니다. 특히 Classic AUTOSAR ECU, CAN 중심 제어기, 저사양 MCU, 특장·상용차 ECU에서 자주 맞닥뜨리는 현실입니다.

❌ 보안 강화하려면 MCU부터 바꿔야 한다

✅ 보드 설계를 수정해 외장 보안칩을 추가하는 방법이 있다

MCU 교체 없이 기존 보드에 보안칩을 SPI/I2C로 연결하는 구조입니다. HW 변경 범위가 MCU 교체보다 훨씬 작고, 기존 SW 자산을 대부분 재사용할 수 있습니다.

---

HSM 없는 MCU의 핵심 문제 — Key Protection

Secure Boot, SecOC, OTA 인증, Secure Debug. 이 기능들이 공통으로 요구하는 게 하나 있습니다.

⚠️ Key를 안전하게 보호하는 공간이 필요합니다.

Secure Boot용 Public Key, SecOC AES Key, Debug Authentication Key — 이 값들이 일반 Flash에 있으면, Debug Interface 접근이나 Flash Dump만으로 Key를 읽거나 변조할 수 있습니다.

Key가 노출되면 알고리즘이 아무리 강해도 의미가 없습니다. Secure Boot는 우회되고, 가짜 MAC 생성이 가능해지고, Debug Unlock이 됩니다. 결국 보안의 실질적인 강도는 Key를 얼마나 잘 보호하느냐에서 결정됩니다.

---

외장 보안칩을 추가하는 구조

이 문제를 해결하기 위해 기존 보드에 별도 보안칩(Security Controller)을 추가하는 방식입니다. MCU는 그대로 두고, 보드 설계를 수정해서 SPI 또는 I2C로 보안칩을 연결합니다.

외장 보안칩 추가 구조

기존 MCU (변경 없음)

Application Code

Crypto API 호출

결과값 수신 및 처리

SPI / I2C

⟷

명령·결과

외장 보안칩 (신규 추가)

Crypto Engine (AES·ECC·RSA)

Key Storage (격리된 보안 영역)

인증·서명·MAC 처리

핵심: Key는 보안칩 내부에서만 사용됩니다. MCU는 "MAC 생성해줘", "서명 검증해줘" 명령만 보내고, Key 값 자체는 MCU로 나오지 않습니다.

✅ 암호키를 MCU 내부 Flash가 아니라 별도 보안칩 내부에 격리해서 저장합니다.
MCU가 공격당하더라도 Key 자체는 직접 노출되지 않습니다.

---

외장 보안칩으로 뭘 할 수 있나

01

Secure Boot — Firmware 무결성 검증

MCU 부팅

→

FW Hash 계산

→

보안칩 서명검증

→

정상 시 실행

검증용 Key가 MCU Flash에 직접 노출되지 않습니다. 보안칩이 내부 Key로 서명을 검증하고 결과만 반환합니다. 변조된 Firmware는 실행되지 않습니다.

02

SecOC — CAN 메시지 MAC 생성·검증

CAN 메시지 준비

→

보안칩 MAC 생성

→

MAC 첨부 전송

AES Key는 보안칩 내부에서만 사용됩니다. MCU는 "이 데이터로 MAC 만들어줘"라고 요청하고 결과값만 받습니다. Key가 MCU 메모리에 올라오지 않습니다.

03

Secure Debug — 무단 디버그 접근 차단

Debugger 연결 시도

→

Challenge 생성

→

보안칩 인증 검증

→

성공 시만 허용

인증 없이 Debug Port에 접근하면 차단됩니다. 이 구조가 없으면 Debug Interface가 주요 공격 경로가 됩니다.

04

OTA 인증 — 검증된 Firmware만 업데이트

OTA Package 수신

→

보안칩 서명 검증

→

검증 통과 시 Flash

서명되지 않은 Firmware는 설치되지 않습니다. OTA 공격을 통한 악성 Firmware 주입을 막는 핵심 구조입니다.

---

MCU 내장 HSM vs 외장 보안칩 — 뭐가 다른가

MCU 내장 HSM

이상적인 구조

· MCU 내부 HW 격리 영역
· 저지연 — 내부 버스 통신
· 별도 부품 없음
· 가장 강한 격리 수준
· 단점: MCU 교체 필요

외장 보안칩

현실적인 대안

· 독립된 별도 IC
· 기존 MCU 재사용 가능
· 보드 설계 수정으로 추가
· 물리적 분리로 독립 보안
· 단점: BOM 증가, SPI 지연

내장 HSM이 이상적이지만 MCU 교체가 필요합니다. 외장 보안칩은 보드 설계 수정으로 기존 MCU를 그대로 두면서 Hardware Root of Trust를 추가할 수 있는 구조입니다.

---

보드 설계 수정 시 실제 고려사항

항목	내용	주의점
인터페이스	SPI 또는 I2C 연결	SPI가 속도 유리, I2C는 핀 수 절약. 보안칩 스펙 확인 필요
PCB 공간	보안칩 실장 공간 확보	소형 패키지 제품 선택 시 영향 최소화 가능
전원	별도 전원 라인 설계	노이즈 영향 고려한 디커플링 설계 필요
SPI 통신 보호	MCU ↔ 보안칩 구간	물리적 접근 보호 필요. 해당 구간은 여전히 공격 포인트
Driver 개발	보안칩 연동 SW	Crypto API 추상화 레이어 설계 권장
Key Provisioning	제조 단계 Key 주입	생산 라인에서 Key 주입 프로세스 별도 설계 필요

---

한계도 있다 — 이걸 숨기면 안 된다

⚠️ 외장 보안칩 구조의 한계

① SPI/I2C 통신 구간 노출 — MCU와 보안칩 사이 통신 라인은 물리적으로 접근 가능합니다. 내장 HSM의 내부 버스와 달리 외부 핀으로 신호가 지나갑니다.

② MCU 자체 격리가 아니다 — 내장 HSM처럼 MCU 내부에서 완전히 격리된 구조가 아닙니다. MCU와 보안칩 간 신뢰 관계 설계가 중요합니다.

③ Latency 증가 — 외부 IC 통신이므로 내장 HSM 대비 응답 시간이 늘어납니다. SecOC처럼 빈번한 암호 연산이 필요한 기능은 성능 분석이 필요합니다.

④ BOM 및 설계 복잡도 증가 — 부품 추가, PCB 변경, Driver 개발, Key Provisioning 프로세스 구축이 함께 필요합니다.

외장 보안칩은 현실적인 대안이 될 수 있습니다.
하지만 MCU 내장 HSM과 동일한 보안 수준을 제공하지는 않습니다.
Trade-off를 명확히 인식하고 설계해야 합니다.

---

현업에서는 이렇게 느껴진다

이 구조를 실제로 적용하면서 배운 것들

MCU 교체보다 보드 수정이 현실적으로 빠른 경우가 있다 — MCU를 바꾸면 BSP, AUTOSAR, 양산 검증을 다시 해야 한다. 보안칩 추가는 그 범위가 훨씬 작다. 일정이 빠듯한 프로젝트에서 의미 있는 선택이 됐다.

Key Provisioning 설계를 초반에 해야 한다 — 보안칩 추가 결정보다 "제조 라인에서 Key를 어떻게 주입할 것인가"가 더 복잡한 문제였다. 이걸 나중에 생각하면 생산 라인 설계 전체가 흔들린다.

SPI 구간 보호를 설계 단계에서 고려해야 한다 — PCB 레이아웃에서 해당 신호 라인의 물리적 접근을 고려하는 것이 나중에 추가하는 것보다 훨씬 쉽다. 보안 요구사항이 HW 설계에 영향을 준다는 걸 처음 제대로 느꼈다.

이 구조는 SDV 시대에도 계속 필요하다 — 고성능 AP가 있어도 차량에는 수십 개의 MCU 기반 ECU가 여전히 존재한다. 그 ECU들도 Secure Boot, SecOC, R155 대응을 해야 한다. "기존 MCU를 어떻게 안전하게 보호할 것인가"는 앞으로도 중요한 문제다.

---

마무리

차량 보안은 항상 최신 플랫폼에서만 시작되는 게 아닙니다.

현실에서는 기존 MCU를 유지한 채
어떻게 Root of Trust를 추가할 것인가가 더 중요한 문제인 경우가 많습니다.

외장 보안칩은 그 현실 속에서 나온 구조 중 하나입니다.

보드 설계 수정으로 외장 보안칩을 추가하는 방식은 MCU 교체 없이 Hardware Root of Trust를 확보할 수 있는 현실적인 선택입니다. 단, SPI 통신 구간 보호, Key Provisioning 프로세스, Latency 영향 분석이 반드시 함께 설계되어야 합니다.

핵심 요약

1

HSM 없는 MCU의 핵심 문제는 Key Protection — Key가 일반 Flash에 있으면 공격에 취약하다

2

보드 설계 수정으로 외장 보안칩 추가 가능 — MCU 교체 없이 SPI/I2C로 Hardware Root of Trust를 추가한다

3

Secure Boot·SecOC·Secure Debug·OTA 인증에 활용 가능 — Key는 보안칩 내부에서만 사용되고 MCU로 나오지 않는다

4

내장 HSM과 동일하지 않다 — Trade-off를 알고 설계해야 한다 — SPI 구간 노출, Latency, BOM 증가를 함께 고려해야 한다

5

Key Provisioning 설계는 초반에 확정해야 한다 — 제조 단계 Key 주입 프로세스를 나중에 추가하면 생산 라인 설계 전체가 흔들린다

HSM SecureBoot SecOC MCU보안 RootOfTrust 외장보안칩 차량사이버보안 KeyProtection SDV 보안아키텍처 OTA보안 SecureDebug