IT와 보안 그 어디 쯤/Security

ARM Trustzone - Secure state 변경

깊음위에 2021. 1. 27. 19:08
반응형

ARM Trustzone은 이제는 많이 알려진 것처럼, 한 SoC 안에서, Non-secure / Secure world의 가상 영역을 나누어 실행하도록 하는데에 있어서,  물리적으로 스위칭 할 수 있는 구조를 가지고 있는 것이다. Secure world 에서 operation 되는 메모리, status 등은 Normal world에서는 알 수 없으며, NWd (Normal World domain)에서는 SWd (Secure World domain)의 결과만 받을 뿐이다.

아래의 아키텍쳐가 기본적인 컨셉이고 처음에 Trustzone이 deploy되면서부터 있어왔던 구조이다. 

Trustzone architecture

 

TrustZone for Cortex-A

Trustzone 은 수십만의  AP에서 high-level code와 data를 보호하며 인증, 결제, content protection 과 기업보안을 포함하여 다양한 usecase 에서 사용되고 있다. Trustzone은 GlobalPlatform TEE (Trusted Execustion Environmet)의 Security boundary를 제공한느 것으로 자주 사용되고 언급되어 왔다.

TrustZone for Cortex-M

ARMv8-M 아키텍처는 Trustzone을 Cortex-M으로 확장시켜서 높은 수준의 Protection을 가능하게 했다. ARMv8-M의 Trustzone은 Secure / Non-Secure world 간의 이동이 빠른 이동과 전력효용을 위해 하드웨어에서 수행되는 등, AP에서의 Trustzone과  같은 수준의 High-level feature를 가지고 있다. 

 

Feature/Architecture TrustZone for Armv8-A TrustZone for Armv8-M 
Additional security states SEL0 - Trusted Apps SEL1 - Trusted OS EL3 - Trusted Boot and Firmware (Armv8-A) Secure thread - Trusted code/data Secure handler - Trusted device drivers, RTOS, Library managers...
Secure interrupts Yes Yes (Fast) 
State transition (Boundary crossing) Software transition Hardware transition (Fast) 
Memory management Virtual memory MMU with secure attributes Secure Attribution Unit (SAU) and MPU memory partitions
System interconnect security Yes Yes
Secure code, data and memory Yes Yes
Trusted boot  Yes Yes
Software Trusted Firmware-A (and third-party TEEs) Arm Keil MDK, CMSIS, Arm Mbed OS, Trusted Firmware-M and third-party software

어쨌는 Trustzone 관점에서는 Cortex-A이건 M 이건 어마어마하게 다르지는 않다. 빠른 이해를 위해, Cortex A, 64bit 시스템에서의 Trustzone에 대해서 알아보도록 하자. 

Security States

ARM 아키텍쳐에서, 두개의 Security state가 있다 즉, Secure 와 Non-Secure. 이건 마치 동전에는 앞면과 뒷면이 있다는 말처럼 당연하지만 비장하게 꺼내는 말이다. 

EL0, EL1 그리고 EL2에서는 process 가 SCR_EL3.NS 비트에 의해서 Seucre state 에서 동작할지 Non-Secure State 에서 동작할지 결정된다. 

  • NS.EL1: Non-secure state, Exception level 1
  • S.EL1: Secure state, Exception level 1

EL3는 항상 Secure state이다. 이건 SCR_EL3.NS 비트와는 관계없이 무조건 Secure state이다. 아래 그림공부. 뻔하고 뻔한 말이지만 그림으로 그리면 이렇다.

 

Security states의 변환

자 그럼 NS.EL1 에서 S.EL1으로 바꾸려면 뭘해야 할까? Security state를 바꾸기 위해서는, Secure에서 Non-secure건, Non-Secure에서 Secure건 간에. EL3를 통해서 변경되어야 한다. 또 아래 당연한 그림참조.

이건 그저 한 예이다. 한번에 일어난다The preceding diagram shows an example sequence of the steps involved in moving between Security states. Taking these one step at a time:

  1. 더 높은 Exception leve로 진입하기 위해서는, FIQ나 SMC excetion과 같은 exception이 필요함. 
  2. EL3에는 적절한 excetion vector 가 입력된다. EL3에서 돌고 있는 SW는 SCR_EL3.NS bit를 토글하게 된다.
  3. Exception에서 돌아오면서 processor는 EL3에서, S.EL1에서 동작하도록 변경된다.

Security state를 변경하는 것은 단지 Exception level에서 SCR_EL3.NS 비트를 변경하는 것 외에 다른 사항들도 있다. processor state 도 고려해야 한다. Security states 가 변경되어 regsister state가 저장되고 복원되는 것은 software가 담당한다. hardware가 아니다! 편의를 위해, 이런 Software를 Secure Monitor라 부른다. 역시 뻔한 그림한번 더보자. 

Seucre Monitor

이거, open TEE 에도 나와 있고, ARM site 에가서 document 하나 받으면 거기 example code 도 찾을 수 있다. 

적은 수의 레지스터가 Secure state에 의해 뱅크된다. 즉, 레지스터의 복사본이 두 개이고 코어는 현재 Secure state에 속하는 복사본을 자동으로 사용합니다. 이러한 레지스터는 프로세서가 항상 두 설정을 모두 알아야하는 레지스터로 제한된다.. Banking은  예외이 고  프로세서의 아키텍처 참조 매뉴얼에서 명시 적으로 언급된다.

쉽게 말하자면, Secure state를 복원하기 위한 저장본이 하나씩 있다고 보면된다. 

 

간단히 Coretex-A 64bit에서 Trustzone의 Architecture에 대해 알아봤는데, 사실 32비트는 좀 더 복잡하다. 게다가 EL1~EL3로 Exceptino Level을 나누어 놓지도 않을 뿐더러, 그러다보니 architecture가 좀 덜 구조화 되어 있다. Coretex-M은 32비트 기반으로 되어 있다. 

아무튼, 기본적인 컨셉은 같다. NS 비트를 따라서 Secure/ Non-secure state 로 천이되고, 이걸 담당하는 Secure Monitor 코드가 필요하다. 

 

메모리 관점에서도 한번 더 풀어봐야 겠다. 물론 다음 기회에.. 오늘은 졸립네.

반응형

'IT와 보안 그 어디 쯤 > Security' 카테고리의 다른 글

FIPS 140-3  (0) 2024.06.01
HSM 과 KMS  (0) 2023.06.15
Cloud HSM  (0) 2021.01.23