AP TEE가 MCU 보안을 대신하는 구조— 이상적인 보안보다 현실적인 아키텍처

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

프로젝트 시작할 때 들었던 말들

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

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

"AP쪽에 TEE는 있는데 MCU 보안을 거기서 해줄 수 있나요?"

"SPI로 Plain FW 넘기는 게 보안상 괜찮은 건가요?"

이 질문들, 실제 프로젝트에서 나온 이야기입니다.

결론부터 말하면 — 완벽한 구조는 아닙니다. 하지만 현실적인 제약 안에서 선택할 수 있는 합리적인 대안이었습니다.

보안 아키텍처는 항상
"가장 강한 구조"만 선택할 수 있는 게 아닙니다.
현실의 제약 안에서 어디까지 Risk를 줄일 수 있는가가 핵심입니다.

---

문제 상황 — MCU에 HSM이 없었다

이 ECU는 AP(Application Processor)와 MCU가 함께 있는 구조였습니다. AP는 Linux를 올린 SoC로, TEE(Trusted Execution Environment)를 가지고 있었습니다. 반면 MCU는 기존 플랫폼을 그대로 사용하는 조건이었고, HSM(Hardware Security Module)이 없었습니다.

ℹ️ 이 ECU의 하드웨어 조건

AP : Linux SoC  ·  TEE 보유  ·  암호 연산 가능
MCU : 기존 플랫폼 재사용  ·  HSM 없음  ·  Secure Flash만 존재

그런데 요구사항은 명확했습니다.

• OTA로 MCU Firmware 업데이트 필요
• Firmware 서명 검증 필요
• 암호화된 Firmware 복호화 필요
• Key 보호 필요
• Secure Flash에 안전하게 저장 필요

HSM 없이 이걸 다 해야 했습니다.

---

왜 MCU 단독으로는 어려웠나

문제	원인	영향
HSM 없음	기존 MCU 플랫폼 제약	Key를 안전하게 보관할 HW 격리 공간 없음
연산 성능 제한	MCU 리소스 한계	ECC/RSA 서명검증을 MCU에서 직접 하기 어려움
Secure Storage 부족	MCU 내부 보안 스토리지 없음	Key가 일반 Flash에 저장되면 노출 위험
플랫폼 변경 불가	원가·일정·기존 BSP	HSM 탑재 MCU로 교체하면 프로젝트 일정 초과

요약하면 — MCU 혼자서는 Key를 지킬 수도, 무거운 암호 연산을 할 수도 없는 상황이었습니다. 그렇다고 MCU를 바꾸는 건 현실적으로 불가능했습니다.

---

그래서 AP TEE를 활용했다 — AP Security Offloading

이 구조의 핵심 아이디어는 단순합니다.

MCU가 못 하는 것을
AP TEE가 대신한다.

역할을 이렇게 나눴습니다.

보안 기능	담당	이유
Key 보호 및 보관	AP TEE	TEE 내부는 일반 OS에서 접근 불가. Key 격리 가능
FW 복호화	AP TEE	암호화된 OTA Package를 TEE 내에서 복호화
서명 검증	AP TEE	ECC/RSA 서명검증을 AP 연산 능력으로 처리
검증된 FW 전달	SPI	검증 완료된 Plain FW를 MCU로 전송
FW 저장 및 실행	MCU	Secure Flash에 저장 후 실행만 담당

MCU는 "검증은 AP가 이미 했으니 나는 받아서 저장하고 실행한다"는 역할입니다.

AP·MCU 혼합 ECU 보안 구조

AP (Linux SoC)

Linux OS — OTA Package 수신

TEE — 복호화 / 서명검증 / Key 보관

Root of Trust 역할 대행

Plain FW

→

SPI

MCU

Secure Flash — FW 저장

MCU Core — 실행만 담당

HSM 없음 · 검증은 AP에서 완료

⚠️ AP → MCU SPI 구간은 Plain FW가 이동하는 구간입니다. 이 구간에 대한 물리적 접근 보호와 Secure Channel 적용이 추가 고려사항입니다.

---

OTA 업데이트 흐름

MCU Firmware OTA 업데이트 전체 흐름

OTA Server

암호화 + 서명된 MCU Firmware Package 배포

↓

AP Linux

OTA Package 수신 · TEE로 전달

↓

AP TEE

① Key로 FW 복호화   ② 서명 검증   ③ 검증 완료 시 Plain FW 반환

↓

SPI 전송

Plain FW를 MCU로 전달 ⚠️ 이 구간이 보안적으로 민감한 지점

↓

MCU Secure Flash

검증 완료된 FW 저장 · 재부팅 후 실행

---

왜 그래도 현실적인 선택이었나

이상적인 구조

MCU 내부 HSM 탑재

· MCU 자체 Root of Trust
· HW 격리된 Key 보관
· MCU 내부에서 서명검증
· AP 의존 없음
· 완전한 HW isolation

현실적인 제약

기존 MCU 재사용 조건

· HSM 탑재 MCU → 원가 상승
· MCU 교체 → BSP 재개발
· 플랫폼 변경 → 양산 일정 초과
· 기존 개발 자산 폐기
· 검증 비용 추가 발생

✅ HSM 기반 구조가 가장 이상적입니다.

하지만 기존 MCU 재사용, 원가 제약, 양산 일정, 플랫폼 변경 비용이라는 현실 앞에서 — AP TEE를 활용한 Security Offloading 구조가 선택되었습니다. AP TEE는 충분한 격리 환경과 연산 능력을 제공했고, MCU 보안 요구사항을 현실적으로 충족할 수 있었습니다.

---

실제로 얻은 효과

항목	기존 (변경 전)	AP TEE 활용 후
Key 보호	일반 Flash 저장 — 노출 위험	TEE 내부 격리 보관
서명검증	MCU 단독 — 연산 부담	AP 연산 능력 활용
FW 복호화	MCU 불가	TEE 내에서 처리
MCU 부담	암호 연산 포함 — 과부하	실행에만 집중
플랫폼 변경	—	기존 MCU 그대로 유지

---

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

이 구조가 현실적인 대안이었다는 건 맞습니다. 하지만 완벽한 구조가 아니라는 것도 솔직하게 봐야 합니다.

⚠️ 이 구조의 보안 한계

① SPI Plain 전송 구간 존재 — AP에서 검증 완료된 Plain FW가 SPI를 통해 MCU로 이동합니다. 이 구간에 물리적으로 접근하거나 중간에서 가로채면 FW 내용이 노출될 수 있습니다.

② AP가 침해되면 영향 범위가 커진다 — MCU 보안의 Root of Trust가 AP TEE에 의존하는 구조이므로, AP가 공격당하면 MCU 보안도 영향을 받습니다.

③ MCU 자체 Root of Trust 없음 — MCU는 AP의 검증을 신뢰할 뿐, 스스로 Firmware 무결성을 독립적으로 검증하지 못합니다.

④ 완전한 HW Isolation 아님 — HSM이 제공하는 MCU 내부 격리 수준에는 미치지 못합니다.

TEE는 현실적인 대안이 될 수 있지만,
MCU 내부 HSM을 완전히 대체하는 구조는 아닙니다.

그래서 이 구조를 선택했다면 SPI 구간 보호, AP 보안 강화, 물리적 접근 통제가 함께 고려되어야 합니다.

---

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

이 프로젝트에서 배운 것들

보안 아키텍처는 이상과 현실 사이에서 결정된다 — 교과서에는 "HSM을 써라"고 나온다. 하지만 현장에서는 원가, 일정, 기존 플랫폼이라는 현실이 있다. 그 안에서 최선을 찾는 게 실무다.

Trade-off를 명확히 문서화해야 한다 — 이 구조의 한계를 숨기면 나중에 더 큰 문제가 된다. "왜 이 구조를 선택했고, 어떤 위험이 남아있는가"를 TARA에 명확히 남겨야 한다.

SPI 구간이 가장 취약한 지점이다 — Plain FW가 이동하는 구간은 설계 단계부터 물리적 접근 통제와 Secure Channel 적용을 검토해야 한다. 나중에 추가하면 더 복잡해진다.

AP Security Offloading은 SDV/Zone ECU에서 점점 많아지는 패턴이다 — MCU 단독 구조에서 AP+MCU 혼합 구조로 가면서 이런 설계 판단이 더 자주 등장한다. 미리 이해해두면 도움이 된다.

---

마무리

현실의 차량 개발은
항상 "가장 강한 보안"만 선택할 수 없습니다.

중요한 건 현재 플랫폼 안에서
어디까지 현실적으로 Risk를 줄일 수 있는가입니다.

AP TEE를 활용한 구조는 그 현실적인 타협 중 하나였습니다.

MCU에 HSM이 없어서 고민이라면 — AP TEE Security Offloading이 하나의 선택지가 될 수 있습니다. 단, SPI 구간 보호와 AP 보안 강화가 함께 따라와야 하고, 이 구조의 한계를 설계 문서에 명확히 남겨야 합니다.

핵심 요약

1

HSM 없는 MCU 보안은 AP TEE Security Offloading으로 보완 가능하다 — Key 보호·복호화·서명검증을 AP TEE가 담당하고 MCU는 실행에 집중한다

2

이 구조는 현실적인 대안이지 완벽한 구조가 아니다 — SPI Plain 전송 구간, AP 의존성, MCU 자체 RoT 부재라는 한계가 존재한다

3

SPI 구간이 가장 취약한 지점이다 — Plain FW 이동 구간에 대한 물리적 접근 보호와 Secure Channel을 반드시 검토해야 한다

4

Trade-off를 TARA에 명확히 남겨야 한다 — 이 구조를 선택한 이유와 잔존 위험을 문서화하지 않으면 나중에 더 큰 문제가 된다

5

AP+MCU 혼합 구조에서 점점 많아지는 패턴이다 — SDV·Zone ECU 시대에 이런 설계 판단은 더 자주 등장한다

SecureBoot HSM TEE SecureFlash OTA보안 MCU보안 APTee SecurityOffloading 차량사이버보안 SDV ZoneECU 보안아키텍처 CAN보안 RootOfTrust