TEE (Trusted Execution Environment, 신뢰 실행 환경) — SoC 내부에 하드웨어 기반 격리(isolation)로 만든 보안 엔클레이브(secure enclave). Arm TrustZone 같은 격리 실행 환경을 활용해 커스텀 코드와 데이터(Trusted Applications, TA)를 일반 OS의 취약점으로부터 분리해 실행한다. SDV 시대 차량 보안의 ‘신뢰의 바닥’(trust floor)으로 자리잡고 있다.

위치 — ‘ECU/도메인이 아닌 SoC 안’

Trustonic의 정의에 따르면:

박우종 (Trustonic) 비즈니스 개발 이사

ECU나 도메인 안이 아닙니다. SoC 안입니다. SoC 내부에는 물리적인 TrustZone 영역이 있고, TEE는 그 안에 자리합니다.

  • MCU에는 TrustZone 영역이 없어 TEE를 사용하지 않음
  • TEE = SoC 위 격리된 보안 영역
  • 그 위에서 키 관리·암호화·서명·보안 저장소·OTA 신뢰 루틴이 동작

자동차에서 TEE가 필요한 4가지 범주 (Trustonic)

범주내용
보안민감 데이터 보호, 안전한 통신
기능안전성중요 기능의 격리, 안전한 SW 업데이트
규제 준수·신뢰규제 적합성의 기반
IP 보호알고리즘 및 자산 보호

차량 내 TEE의 첫 적용 영역 — IVI

박우종

가장 흔한 경우는 IVI 쪽입니다. SoC가 있는 곳이라면 어디든 사용할 수 있습니다.

IVI/디지털 콕핏은 ‘PC화(PC-ification)‘가 가장 빠른 영역:

  • 풍부한 OS 스택, 앱 생태계, 외부 연결성, 사용자 데이터, 컨텐츠/DRM, 결제·인증, 키와 자격증명이 한꺼번에 유입
  • 공격 표면 넓고, 보호 자산 방대, 업데이트 빈번
  • 차량에서 계정·컨텐츠·결제·개인 데이터가 처음으로 집중된 영역

이후 게이트웨이·텔레매틱스·V2X·도메인 컨트롤러로 확장.

TEE 구현의 3개 진영

출발점특징
칩 벤더 번들 TEESoC 벤더 인하우스 솔루션. 하드웨어 최적화·락인 효과
OP-TEE (오픈소스)도입 시작점. 자체 유지보수 자원 부담
상용 TEE (Trustonic Kinibi 등)추상화 계층, 칩셋 무관 일관성, 10년 운영 책임

OEM 디커플링 문제

박우종

특정 칩셋에 묶인 보안은 처음에는 도입하기 편리할 수 있습니다. 그러나 OEM이 공급망을 다변화하려 할 때, 그것은 막대한 기술 부채로 돌아옵니다.

  • 칩셋이 바뀔 때마다 보안 구조 재설계·재검증 부담
  • 멀티-SoC 전략에서 보안 일관성 = 비용·일정 문제
  • 서드파티 TEE는 추상화 계층으로 기능

OTA 시대의 TEE 역할

OTA 시대 보안은 ‘공격을 막는다’에서 ‘무엇을 보호 범위로 정의하고 그 경계를 어떻게 유지할 것인가’로 변환:

박우종

개인 데이터나 차량의 주요 자원을 변경하는 것은 보안 타깃입니다. 그것이 SoC 안에서 구현되었거나, 제조사가 정의한 보안 영역 내에서 보완 조치가 마련돼 있다면, 그 범위는 보호되고 있다고 볼 수 있습니다.

업데이트가 많아질수록 도전받는 질문:

  • 업데이트된 코드가 적절히 검증되었는가?
  • 키·자격증명이 노출될 수 있는가?
  • 중요 루틴이 일반 OS 취약점 영역으로 끌려 들어갈 수 있는가?
  • 업데이트 이후에도 보호 경계는 온전한가?

TEE의 진단 — 추적성

박우종

오픈 구현의 경우에는 누가 무엇을 변경했는지 줄 단위로 확인해야 해서 속도가 느려집니다. 저희는 추적과 디버깅을 통해 빠르게 확인할 수 있습니다.

  • 모듈화·구조화된 상용 TEE = 빠른 추적
  • 사고 시 원인-영향-책임 경로를 좁히는 시간이 OEM 운영비·대응 타임라인 결정

차세대 — 양자 내성·Physical AI

  • 포스트 양자 컴퓨팅(PQC) 위협 — 핀란드 IQM 같은 양자 컴퓨팅 현실화로 10년 후 양자 공격 대비 ‘future trust’ 필요. Trustonic Kinibi 700에 양자 내성 보안 선제 통합
  • Physical AI 시대 — 자산이 ‘정보’에서 ‘물리적 제어’로 확장. AI 모델 가중치·학습 데이터를 보호 패키지에 포함

같이 보기