1. 보안과 비보안 이미지는 실행 환경부터 갈라진다
TF-M 연동에서 Zephyr는 일반적으로 비보안 실행 환경(NSPE)의 앱이다. TF-M의 보안 이미지가 보안 실행 환경(SPE)을 초기화한 뒤 Zephyr로 제어를 넘긴다. 선택적 BL2가 있으면 보안 부트 단계가 그 앞에 놓인다. Zephyr가 실행될 때 주변장치와 메모리 설정은 이미 보안 이미지가 결정한 값일 수 있으므로, 비보안 앱의 초기 상태를 하드웨어 리셋값으로 가정하면 안 된다.
BL2는 설정·플랫폼에 따른 선택 단계다. 아래 세 상자가 항상 모두 별도 업데이트 단위라는 뜻은 아니다. 좁은 화면에서는 가로로 이동하세요.
경계: PSA API 호출은 비보안 앱이 보안 서비스에 요청하는 통로다. 이 화살표가 비보안 코드에 보안 저장소나 키의 직접 접근권을 주지는 않는다.
| 구성요소 | 실행 위치·역할 | 성립 조건 |
|---|---|---|
| BL2 | 보안 부트와 이미지 검증 | CONFIG_TFM_BL2=y이며 플랫폼이 지원할 때 |
| TF-M 보안 이미지 | SPE 초기화와 활성화된 보안 서비스 | 지원 보드에서 CONFIG_BUILD_WITH_TFM=y |
| Zephyr 앱 | NSPE에서 일반 앱 실행 및 PSA 클라이언트 | 비보안 보드 변형·TrustZone·TF-M 통합 설정 |
2. /ns 이름만 보고 지원을 확정하지 않는다
v3.7.0의 CONFIG_BUILD_WITH_TFM은 TRUSTED_EXECUTION_NONSECURE, ARM_TRUSTZONE_M, 비어 있지 않은 TFM_BOARD에 의존한다. TF-M을 그 보드·SoC에 포팅한 구성도 있어야 한다. 보통 비보안 보드 변형이 플래시·SRAM·주변장치를 보안 측 초기화와 맞춰 기술한다. 단순히 앱의 prj.conf에 한 줄을 더한다고 임의 보드가 TF-M 보드로 바뀌지는 않는다.
태그된 보호 저장소 샘플의 통합 테스트 보드 표기는 mps2/an521/cpu0/ns다. 샘플은 CONFIG_BUILD_WITH_TFM=y를 명시하지만, 통합 문서는 일반 앱에서는 지원되는 비보안 보드 정의가 필요한 설정을 제공하는 편을 설명한다. 보드 이름과 설정은 사용 중인 Zephyr 태그의 보드 정의·샘플과 함께 확인한다.
| 질문 | 3.7.0에서 볼 증거 | 아직 증명하지 못하는 것 |
|---|---|---|
| 비보안 대상인가? | 지원 보드의 /ns 변형과 기본 설정 | 해당 보드에 필요한 TF-M 포트·서비스 완성도 |
| TF-M 빌드를 선택했나? | CONFIG_BUILD_WITH_TFM 및 세 의존 조건 | BL2가 반드시 들어갔는지 |
| 메모리 경계가 맞나? | 비보안 DTS 영역과 TF-M 플랫폼 배치 | 실제 제품의 보호 설정·공격 저항성 |
| 필요한 서비스가 있나? | TF-M 파티션 설정과 보드 지원 | 호출 성공·지속성·키 보호의 실제 동작 |
3. 하나의 빌드 명령 뒤에도 산출물은 분리해서 읽는다
지원 대상에서 TF-M 통합을 켜면 Zephyr 빌드가 TF-M 보안 이미지를 함께 빌드하고 비보안 앱과 연결한다. TF-M 자체의 테스트용 비보안 앱이 아니라 Zephyr 앱이 통상 NSPE 이미지로 쓰인다. CONFIG_TFM_BL2가 활성이고 플랫폼이 이를 지원하면 BL2·서명 단계가 더해진다. tfm_merged.hex는 플래시 편의를 위한 결합 산출물이지 보안·비보안 실행 경계가 사라졌다는 뜻이 아니다.
Sysbuild는 다른 이미지까지 묶을 때 쓸 수 있는 상위 빌드 도구이며 TF-M 활성화의 필수 스위치가 아닙니다.
/ns 보드·TF-M 포트BUILD_WITH_TFM 의존 조건tfm_s 보안 이미지Zephyr 비보안 앱TFM_BL2=y일 때 BL2·서명키와 이미지 버전 정책 별도 검토tfm_merged.hex각 구성요소·링크·서명 결과도 따로 확인v3.7.0 샘플을 읽을 때의 명령 뼈대는 아래와 같다. 실행 가능 여부는 TF-M 모듈, 도구 체인, 보드·QEMU 요구 조건에 달려 있다. 이 글의 검증은 소스 계약에 한정하며 이 명령을 실행한 결과를 주장하지 않는다.
west build -b mps2/an521/cpu0/ns \
samples/tfm_integration/psa_protected_storage| 산출물 | 확인하는 경계 | 그 자체로 확인할 수 없는 것 |
|---|---|---|
tfm_s | 보안 펌웨어가 별도로 빌드됨 | 제품 키·정책이 안전하게 프로비저닝됐는지 |
Zephyr zephyr.hex | 비보안 앱의 빌드 | PSA 서비스가 실제 보드에서 성공하는지 |
| BL2·서명 이미지 | BL2를 켠 구성의 검증 입력 | 개발용 키가 교체됐는지·현장 업데이트 정책 |
tfm_merged.hex | 플래시용 주소 결합 결과 | 두 실행 환경의 권한이 같다는 뜻 |
근거: v3.7.0 TF-M 빌드·서명·결합, 태그된 TF-M 통합 CMake, 3.7.0 Sysbuild 역할.
4. PSA API는 보안 자원의 소유권이 아니라 요청 인터페이스다
Zephyr NSPE 코드는 PSA 클라이언트 API를 호출하고, TF-M이 생성한 비보안 인터페이스·veneer를 거쳐 활성화된 보안 서비스에 요청한다. 보호 저장소 예시에서는 psa_ps_set()이 UID에 데이터를 기록하고 psa_ps_get()이 다시 읽는다. 호출 결과인 psa_status_t를 검사해야 하며, API 선언이나 링크 성공만으로 서비스 가용성을 단정할 수 없다.
이 경로는 활성화된 TF-M Protected Storage 파티션을 가정한 설명도입니다. 보드마다 서비스·저장 매체 구성은 다를 수 있습니다.
psa_ps_set(uid,…)UID·입력 길이·버퍼를 전달psa_status_t 반환성공·거부·오류를 앱이 분기아래는 원본 샘플의 호출 순서를 줄인 설명용 조각이다. 헤더·오류 처리·출력 버퍼 크기와 프로비저닝은 실제 앱에 맞춰 완성해야 한다.
psa_status_t rc;
psa_storage_uid_t uid = 1;
const char value[] = "example";
rc = psa_ps_set(uid, sizeof(value), value, PSA_STORAGE_FLAG_NONE);
if (rc != PSA_SUCCESS) {
/* 서비스 구성, 저장 상태, 권한을 조사한다 */
}키가 보안 측에 남는다는 말의 범위: PSA Crypto의 불투명 키 핸들 사용은 비보안 앱에 개인 키 원문을 넘기지 않도록 설계된 서비스 경계다. 그러나 보드의 키 프로비저닝, 하드웨어 보호, 활성 파티션과 오류 처리는 별도로 검증해야 한다.
5. 개발용 이미지가 생겼다고 제품이 안전한 것은 아니다
v3.7.0 Kconfig에서 지원 플랫폼의 CONFIG_TFM_BL2 기본값은 y다. BL2를 쓴다면 기본 서명 키는 제품 키로 교체하고 보안·비보안 키 파일을 관리해야 한다. 또한 CONFIG_TFM_DUMMY_PROVISIONING은 기본적으로 y이며 Kconfig가 제품 하드웨어에 사용하지 말라고 명시한다. 설정값 확인, 보드 프로비저닝, 부팅·업데이트·복구 시험은 별도 검증 단계다.
| 항목 | v3.7.0의 역할 | 검증할 사실 |
|---|---|---|
CONFIG_TFM_BL2 | 지원하면 BL2를 빌드에 추가, 기본 y | 실제 보드에서 부트·업데이트 정책과 이미지 배치 |
CONFIG_TFM_KEY_FILE_S/NS | BL2를 쓸 때 S·NS 서명 키 경로 | 기본 개발 키 교체와 비밀 키 보관 |
CONFIG_TFM_DUMMY_PROVISIONING | 더미 키·자료로 개발, 기본 y | 제품 설정에서 해제·실제 프로비저닝 |
| PSA 서비스 파티션 | 선택된 Crypto·PS·ITS 등 기능 | 보드·프로파일 지원과 실제 응답 |
6. Zephyr User Mode는 다른 축의 경계다
Zephyr User Mode는 한 Zephyr 이미지 안에서 사용자 스레드가 접근할 수 있는 메모리와 커널 객체·시스템 호출을 제한한다. TF-M 통합은 Arm TrustZone의 보안 실행 환경과 비보안 실행 환경 사이에 이미지와 서비스를 나눈다. NSPE 안에서 User Mode를 쓸 수는 있지만, 사용자 스레드에 커널 객체 권한을 주는 일이 곧 TF-M 보안 저장소 접근권을 준다는 뜻은 아니다. 두 경계의 위협 모델과 실패 증거를 각각 점검해야 한다.
| 질문 | Zephyr User Mode | TF-M 통합 |
|---|---|---|
| 경계 위치 | Zephyr 이미지 내부의 thread·kernel | 보안 이미지(SPE)와 비보안 이미지(NSPE) |
| 주요 통로 | Zephyr 시스템 호출·객체 권한 | PSA 서비스 API·보안 측 정책 |
| 먼저 볼 실패 | 객체 권한·메모리 영역·fatal 경로 | 보드 설정·TF-M 파티션·PSA 상태값 |
근거: 3.7.0 User Mode, TF-M SPE/NSPE 경계. 사이트의 Zephyr 사용자 모드 글은 단일 이미지의 객체·메모리 권한을 자세히 다룬다.
7. 빌드, 부팅, 서비스 오류를 한 문제로 합치지 않는다
비보안 보드 변형을 먼저 확인하고, Kconfig에서 TF-M 의존 조건을 본다. 그다음 보안·비보안 산출물과 선택적 BL2 서명 결과를 구분한다. 부팅 뒤 PSA API가 실패하면 해당 파티션·프로파일·저장 매체·반환 상태를 본다. 파일이 있다고 해서 호출이 성공하거나 제품이 안전하다고 결론 내릴 수는 없다.
| 관측 | 먼저 확인 | 다음 질문 |
|---|---|---|
BUILD_WITH_TFM 선택 불가 | 비보안·TrustZone·TFM_BOARD 의존 조건 | 보드에 TF-M 포트가 있나? |
| S/NS 링크·메모리 오류 | 비보안 DTS와 TF-M 플랫폼 배치 | 서로 예약한 플래시·RAM이 맞나? |
| BL2·서명 오류 | TFM_BL2, 키 경로·이미지 버전 | 이 플랫폼의 부트 정책과 일치하나? |
| PSA 저장 요청 실패 | psa_status_t, 활성 PS 파티션·저장소 | 보드가 이 서비스를 제공하나? |
| 이미지는 생기나 제품 보안 미확인 | 더미 프로비저닝·개발 키·실측 시험 | 현장 위협 모델에 맞춘 검증을 했나? |
8. 고정된 버전과 확인 범위
본문은 Zephyr v3.7.0의 TF-M 문서와 태그된 Kconfig·CMake·PSA 보호 저장소 샘플에 맞춰 썼다. 부트·서비스 그림은 원본 자료의 관계를 재구성한 자체 그림이다. 보드별 실제 빌드, 서명 키 운용, 하드웨어 격리, PSA 서비스 응답은 이 글의 검증 범위 밖이다.