Cortex-M33 TF-M·TrustZone — Secure Firmware·PSA·MCUboot

#한 줄 요약

“TF-M은 TrustZone-M 기반 Cortex-M에서 secure service를 구성하는 대표적인 open-source framework입니다.” PSA Certified와 각 지역 규제의 요구사항을 검토할 때 참고할 수 있지만, 인증·준수 여부는 제품 threat model과 구현·평가 범위로 판단합니다. Crypto·storage·attestation을 secure side에 두고 RTOS·앱은 non-secure side에서 돌리는 구성을 지원합니다.

#어떤 상황에서 쓰나

IoT sensor, smart lock, gateway, wearable, BLE node, industrial controller처럼 공격면이 있는 connected MCU device에서 후보가 됩니다. 다음 규제·인증 요구사항을 검토할 때 PSA Certified와 TF-M 구성을 참고할 수 있지만, 적용 의무와 시점은 제품·시장·관할에 따라 확인해야 합니다.

• EU Cyber Resilience Act (Regulation (EU) 2024/2847) — 2024년 12월 10일 발효했습니다. 취약점·사고 보고 의무는 2026년 9월 11일부터, essential requirements와 CE marking을 포함한 대부분의 조항은 2027년 12월 11일부터 적용됩니다.
• UK PSTI Act 2022 — consumer connectable product 보안 regime이 2024년 4월 29일 시행됐습니다. 기본 비밀번호 금지, 취약점 신고 창구 공개, 보안 업데이트 지원 기간 공개를 요구합니다.
• US Cyber Trust Mark — FCC가 운영하는 자발적 labeling 제도로 2025년 1월 7일 출범했습니다.

요구사항에는 secure boot, protected storage, device attestation, secure update 등이 포함될 수 있습니다. TF-M은 관련 secure service의 reference 구현을 제공하며, vendor SDK의 통합 범위와 설정은 MCU·SDK 버전별로 확인합니다.

#핵심 개념

Cortex-M33/M55/M85는 TrustZone-M이라는 hardware mechanism으로 Secure와 Non-Secure 두 world를 가집니다.

Memory와 peripheral은 SAU/IDAU + MPC/PPC로 region별 secure 여부를 표시합니다. NSPE가 secure 영역에 접근하면 SecureFault가 발생합니다(SecureFault가 없는 Armv8-M Baseline, 예를 들어 Cortex-M23에서는 HardFault).

SPE↔NSPE 호출은 NSC veneer라는 special function을 거칩니다. 순서는 다음과 같습니다.

1. Non-secure 코드가 BL nsc_function으로 NSC veneer를 호출합니다.
2. Veneer는 secure side의 Non-Secure Callable(NSC) 영역에 있고, 첫 instruction인 SG(secure gateway)가 secure state로 전환합니다.
3. Veneer가 SPE service로 branch해 요청을 처리합니다.
4. Service가 BXNS lr로 non-secure state로 돌아가고 호출한 코드로 복귀합니다.

SG instruction이 유일한 entry point입니다. NSPE는 NSC veneer 외에는 secure 영역에 진입할 수 없습니다.

PSA(Platform Security Architecture)는 ARM이 정의한 vendor-agnostic security API입니다.

API가 같으므로 STM32·nRF·NXP·Renesas 같은 서로 다른 vendor의 TF-M port 위에서 application 코드를 재사용하는 것이 설계 목표입니다.

#코드 / 실제 사용 예

#TF-M build

1
git clone https://github.com/TrustedFirmware-M/trusted-firmware-m
2
cd trusted-firmware-m
3

4
cmake -S . -B build \
5
    -DTFM_PLATFORM=stm/nucleo_l552ze_q \
6
    -DTFM_PROFILE=profile_medium
7
cmake --build build -- install

현재 TF-M build는 SPE만 만듭니다. install 결과는 build/api_ns에 모이고, 그 안의 bin에 bootloader(BL2, 선택)·SPE image·결합 image가, interface·cmake에 NSPE가 PSA API를 쓰고 빌드할 header와 toolchain 파일이 들어갑니다. NSPE(RTOS + application)는 이 artifact를 가져다 별도 CMake project로 빌드합니다. TF-M test suite나 예제 NS app은 tf-m-tests·tf-m-extras repository에 있습니다.

Boot chain은 ROM bootloader → BL2(MCUboot) → SPE → NSPE 순입니다.

#PSA Crypto — key 생성·sign

1
#include "psa/crypto.h"
2

3
psa_crypto_init();
4

5
/* Persistent ECDSA key */
6
psa_key_attributes_t attr = PSA_KEY_ATTRIBUTES_INIT;
7
psa_set_key_type(&attr, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));
8
psa_set_key_bits(&attr, 256);
9
psa_set_key_usage_flags(&attr, PSA_KEY_USAGE_SIGN_MESSAGE);
10
psa_set_key_algorithm(&attr, PSA_ALG_ECDSA(PSA_ALG_SHA_256));
11
psa_set_key_lifetime(&attr, PSA_KEY_LIFETIME_PERSISTENT);
12
psa_set_key_id(&attr, 0x1001);
13

14
psa_key_id_t key_id;
15
psa_generate_key(&attr, &key_id);
16

17
/* Sign */
18
uint8_t sig[64];
19
size_t  sig_len;
20
psa_sign_message(key_id, PSA_ALG_ECDSA(PSA_ALG_SHA_256),
21
                  msg, msg_len, sig, sizeof(sig), &sig_len);

일반적인 PSA Crypto 구성에서는 private key를 NSPE로 export하지 않고 key_id를 통해 sign/encrypt를 위임합니다. 실제 key 보호 수준은 hardware isolation·storage backend·policy 설정과 secure world 구현을 함께 검토해야 합니다.

#PSA Internal Trusted Storage

1
#include "psa/internal_trusted_storage.h"
2

3
/* Write — 한 번만 */
4
uint8_t device_secret[32] = { /* derived from HUK */ };
5
psa_its_set(0x100, sizeof(device_secret), device_secret,
6
             PSA_STORAGE_FLAG_NONE);
7

8
/* Read */
9
uint8_t buf[32];
10
size_t  out_len;
11
psa_its_get(0x100, 0, sizeof(buf), buf, &out_len);

ITS는 secure side의 internal flash에 저장되어 NSPE가 직접 read할 수 없습니다. 외부 flash를 쓰는 Protected Storage와 달리 저장 매체 자체가 isolation 경계 안에 있다는 것이 전제입니다. Rollback 보호는 아래 PS 쪽이 NV counter로 제공합니다.

#Protected Storage (encrypted at rest)

1
#include "psa/protected_storage.h"
2

3
psa_ps_set(0x200, sizeof(secret), secret, PSA_STORAGE_FLAG_NONE);
4
psa_ps_get(0x200, 0, sizeof(buf), buf, &out_len);

PS는 data를 암호화·인증해 저장하고, TF-M 구현은 NV counter로 object table의 rollback을 막습니다. external flash의 보호 범위와 dump에 대한 저항성은 key 관리·암호화 구현·debug lock·physical attack model을 별도로 검증합니다.

#Initial Attestation

1
#include "psa/initial_attestation.h"
2

3
uint8_t challenge[32];   /* from server */
4
get_random(challenge, sizeof(challenge));
5

6
uint8_t token[1024];
7
size_t  token_len;
8
psa_initial_attest_get_token(
9
    challenge, sizeof(challenge),
10
    token, sizeof(token), &token_len);
11

12
/* Send token to verifier */

Token에는 device identity, firmware measurement, lifecycle state, nonce(challenge)가 들어가고 Initial Attestation Key(IAK)로 sign됩니다. Verifier는 signature와 measurement를 확인해 이 device와 firmware를 신뢰할지 결정합니다.

#NSPE에서 SPE service 호출

1
#include "psa/client.h"
2

3
#define MY_SERVICE_SID 0x00000200
4

5
psa_handle_t h = psa_connect(MY_SERVICE_SID, 1);
6

7
psa_invec  in[1]  = { { in_buf,  in_len  } };
8
psa_outvec out[1] = { { out_buf, out_size } };
9

10
psa_status_t s = psa_call(h, PSA_IPC_CALL, in, 1, out, 1);
11

12
psa_close(h);

Connection-based service는 NSPE에서 psa_connect/psa_call/psa_close로 호출합니다. 어떤 vendor의 TF-M port든 client API는 같습니다.

#Custom secure partition

1
{
2
  "psa_framework_version": 1.1,
3
  "name": "TFM_SP_MY_SERVICE",
4
  "type": "APPLICATION-ROT",
5
  "priority": "NORMAL",
6
  "model": "IPC",
7
  "entry_point": "tfm_my_service_main",
8
  "stack_size": "0x0800",
9
  "services": [{
10
    "name": "MY_SERVICE",
11
    "sid": "0x00000200",
12
    "non_secure_clients": true,
13
    "connection_based": true,
14
    "version": 1,
15
    "version_policy": "STRICT"
16
  }]
17
}

IPC model partition의 entry point는 반환하지 않는 loop입니다. Service의 signal 이름은 manifest의 service 이름에서 생성되어(MY_SERVICE → MY_SERVICE_SIGNAL) psa_manifest/ header로 들어옵니다.

1
#include "psa/service.h"
2
#include "psa_manifest/my_service_manifest.h"
3

4
void tfm_my_service_main(void) {
5
    while (1) {
6
        psa_signal_t signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK);
7
        if (signals & MY_SERVICE_SIGNAL) {
8
            psa_msg_t msg;
9
            psa_get(MY_SERVICE_SIGNAL, &msg);
10
            /* msg.type: PSA_IPC_CONNECT / PSA_IPC_CALL / PSA_IPC_DISCONNECT */
11
            psa_status_t st = PSA_SUCCESS;
12
            if (msg.type == PSA_IPC_CALL) {
13
                st = handle_request(&msg);   /* psa_read / psa_write로 iovec 처리 */
14
            }
15
            psa_reply(msg.handle, st);
16
        }
17
    }
18
}

PSA IPC는 message-passing 모델입니다. SPM이 client 요청을 signal로 알리고, partition은 psa_wait에서 깨어나 message를 처리한 뒤 psa_reply로 돌려줍니다. 별도 thread 없이 함수 호출로 처리하는 SFN model도 있으며, 이때는 entry_point 대신 entry_init을 둡니다.

#MCUboot — secure boot + A/B

Flash 배치는 platform의 flash_layout.h가 정합니다. 아래 주소는 구조를 보여 주는 예시입니다.

1
Flash layout (예시):
2
  0x0800_0000  BL2 (MCUboot)
3
  0x0801_0000  Slot 0 (primary)    — tfm_s + tfm_ns + manifest
4
  0x0808_0000  Slot 1 (secondary)  — staging
5
  0x080F_0000  Scratch

1
# Sign image
2
imgtool sign \
3
    --key root-ec-p256.pem \
4
    --header-size 0x400 \
5
    --slot-size 0x70000 \
6
    --version 1.2.3 \
7
    --security-counter 3 \
8
    --align 8 \
9
    tfm_s_ns.bin tfm_s_ns_signed.bin

Boot 시 BL2가 image signature와 security counter를 verify합니다. Secondary slot의 새 image가 검증에 실패하면 설치하지 않고 기존 primary image로 boot하며, primary image마저 실패하면 boot를 멈춥니다. TF-M build는 api_ns/image_signing에 이 signing 도구와 key를 함께 내보냅니다.

#SAU 설정

1
void sau_setup(void) {
2
    /* Region 0: non-secure flash */
3
    SAU->RNR  = 0;
4
    SAU->RBAR = (NS_FLASH_START)        & SAU_RBAR_BADDR_Msk;
5
    SAU->RLAR = (NS_FLASH_END   - 1)    | SAU_RLAR_ENABLE_Msk;
6

7
    /* Region 1: NSC veneer */
8
    SAU->RNR  = 1;
9
    SAU->RBAR = (NSC_START)             & SAU_RBAR_BADDR_Msk;
10
    SAU->RLAR = (NSC_END   - 1)         | SAU_RLAR_ENABLE_Msk
11
                                          | SAU_RLAR_NSC_Msk;
12

13
    /* Region 2: non-secure SRAM */
14
    SAU->RNR  = 2;
15
    SAU->RBAR = (NS_SRAM_START)         & SAU_RBAR_BADDR_Msk;
16
    SAU->RLAR = (NS_SRAM_END   - 1)     | SAU_RLAR_ENABLE_Msk;
17

18
    SAU->CTRL = SAU_CTRL_ENABLE_Msk;
19
}

Boot 초기에 SAU + MPC(memory protection controller)를 설정한 뒤 NSPE로 진입합니다. 한 region이 잘못 설정되면 NSPE 진입 즉시 fault가 납니다.

#측정 / 성능 비교

Crypto 연산 latency는 core·clock·crypto backend(software 또는 hardware accelerator)·TF-M profile·isolation level에 따라 크게 달라지므로 target에서 측정합니다. 기록할 항목입니다.

Hardware crypto accelerator(STM32U5 PKA, nRF5340 CryptoCell 등)를 사용하면 ECDSA latency를 줄일 수 있지만, 개선 폭은 curve·key size·driver·clock에서 측정합니다. Production에서는 hardware crypto 필요성을 threat model과 성능 예산으로 판단합니다.

PSA Certified는 level별로 평가 범위가 다릅니다.

Level 2·3에 secure element를 결합한 ”+ Secure Element” 등급과 RoT component 평가도 따로 있습니다. 어떤 level이 필요한지는 규제 자체가 정하지 않으므로, 제품의 threat model과 고객·시장 요구로 판단합니다.

#자주 보는 함정

NSPE에서 secure address access

1
*(uint32_t*)0x0C000000 = 0xDEADBEEF;   /* secure flash address */
2
/* SecureFault (Baseline core는 HardFault) */

NSPE는 NSC veneer로만 secure에 진입할 수 있습니다.

Veneer annotation 누락

1
/* secure side */
2
int my_func(int x) { ... }
3
/* compiler가 NSC entry로 wrap하지 않음 */

__attribute__((cmse_nonsecure_entry)) 또는 vendor macro로 NSC entry를 명시합니다.

Heap을 cross-world에서

1
/* secure malloc → non-secure free → corruption */

Heap은 secure·non-secure 각자 별도로 둡니다.

Key를 export해 NSPE에 들고 옴

1
psa_export_key(key_id, plain, sizeof(plain), &plain_len);
2
/* NSPE가 plain key를 보유 → 침투 시 노출 */

Sign/encrypt는 capability(key_id)만 위임하고 raw key는 SPE 안에 둡니다.

Anti-rollback counter 무시

1
imgtool sign --version 1.0.0 --security-counter 1 ...   # 이전 image와 같은 counter

MCUboot의 downgrade 방지는 image의 security counter(--security-counter)와 device NV counter를 비교해 동작합니다. 취약점을 고친 firmware는 counter를 증가시켜야 이전 image로의 downgrade를 막을 수 있습니다.

MPC·PPC 설정 누락

1
/* SAU만 설정, MPC 미설정 */
2
/* peripheral이 여전히 secure로 lock → NSPE에서 사용 불가 */

SAU(CPU view) + MPC(memory controller view) + PPC(peripheral)를 모두 설정해야 region이 올바르게 동작합니다. MPC·PPC 이름과 register는 vendor마다 다르므로(예: STM32의 GTZC) reference manual을 따릅니다.

#정리

• TF-M은 Cortex-M33+ TrustZone-M에서 secure service를 구성하는 대표적인 framework입니다.
• SPE/NSPE 분리와 NSC veneer를 제공하며, PSA API로 vendor 간 이식성을 목표로 하지만 platform port와 backend 차이는 확인해야 합니다.
• PSA Crypto·ITS·PS·Attestation이 네 가지 핵심 service입니다.
• MCUboot이 2nd-stage bootloader로 secure boot·anti-rollback·A/B update를 담당합니다.
• EU CRA·UK PSTI·US Cyber Trust Mark의 적용 여부와 PSA Certified 필요성은 제품·시장·관할별 요구사항으로 확인합니다.
• TF-M upstream에는 STM32L5/U5·nRF5340·NXP LPC55 같은 vendor platform port와 Arm MPS 보드 port가 있습니다.
• Crypto latency는 algorithm·hardware·implementation에 따라 benchmark합니다.
• Key는 NSPE에 export하지 않고 key_id capability만 위임하는 패턴을 지킵니다.

다음 편은 Matter·Thread IoT 표준입니다.

#관련 항목

• 12-10: 온디바이스 LLM
• 12-12: Matter·Thread
• RTOS 4-11: TrustZone·TF-M