Secure Boot·TEE·RPMB는 서로 다른 문제를 해결합니다

서명 확인만으로 실행 중인 모든 공격을 막지는 못합니다

구분	확인하거나 보호하는 것	이것만으로 해결되지 않는 것
Secure Boot / AVB	다음에 실행할 이미지가 신뢰하는 키·정책에 맞는지 검증합니다.	허용된 코드 자체의 취약점이나 모든 실행 중 메모리 오류
TrustZone과 TEE	보안 상태와 접근 제어를 이용해 민감한 실행·메모리 자원을 분리합니다.	TA가 받은 입력의 유효성 검사를 자동으로 대신하는 일
암호화	키가 없는 쪽에서 저장 내용의 의미를 읽기 어렵게 합니다.	오래된 정상 암호문을 다시 가져오는 rollback
인증된 저장과 rollback 방지	변조·재전송을 구분할 증거와 상태를 유지합니다.	모든 저장장치 고장이나 전원 손실이 일으킬 수 있는 가용성 문제

Android의 AVB는 부트로더에 통합되는 검증 구조와 rollback 관련 메타데이터를 제공합니다. 검증할 키, 허용 정책, rollback 값을 보관하는 방법은 플랫폼 통합의 일부입니다. “서명이 맞으면 항상 부팅해도 된다”는 설명에는 버전 후퇴를 어떻게 막는지가 빠져 있습니다. AOSP AVB

OP-TEE 데이터가 일반 파일 시스템에 저장될 수 있습니다

REE 파일 시스템을 사용하는 secure storage의 개념

Trusted Application
TEE의 저장 API로 객체를 읽거나 씁니다.
secure world의 저장 처리로 전달합니다.
OP-TEE
키와 암호화·무결성 관련 처리를 수행합니다.
RPC로 normal world의 저장 작업을 요청할 수 있습니다.
tee-supplicant와 REE 파일 시스템
저장에 필요한 파일 I/O를 수행합니다.
읽어 온 데이터와 결과를 돌려줍니다.
OP-TEE와 TA
신뢰할 수 없는 저장 결과를 검증한 뒤 사용합니다.

화살표는 API·RPC·응답의 흐름입니다. normal world에 TA의 비밀 키를 그대로 넘긴다는 뜻이 아닙니다. 실제 데이터 형식은 선택한 backend를 따릅니다.

일반 파일 시스템을 쓰더라도 저장 내용의 기밀성·무결성을 TEE 쪽에서 보호할 수 있습니다. 하지만 과거의 정상 파일 묶음을 통째로 복원하는 공격까지 막으려면 별도의 신뢰할 수 있는 최신 상태가 필요합니다. OP-TEE 4.10 문서는 REE FS의 rollback 보호가 RPMB 설정과 연결된다고 명시합니다. OP-TEE secure storage 구성

RPMB의 역할을 “암호화 파티션”으로 줄이면 안 됩니다

RPMB는 인증된 요청과 write counter 등을 이용해 재전송을 막는 저장 영역입니다. 저장장치와 호스트 사이에서 누가 올바른 키로 요청했는지, 쓰기 순서가 맞는지 확인하는 기능과 데이터 자체를 암호화하는 기능은 구분해야 합니다. 제품에서 키를 어떻게 만들고 어떤 코드가 사용할 수 있는지도 보안 설계의 일부입니다.

확인할 항목	왜 필요합니까?
CFG_REE_FS / CFG_RPMB_FS	같은 OP-TEE 버전이어도 선택한 backend에 따라 보장하는 성질이 달라집니다.
키의 생성·보관·장치 연결	개발용 키를 여러 제품에서 공유하거나 normal world에 노출하면 기대한 신뢰 관계가 깨집니다.
재부팅·전원 손실 이후의 상태	최신 객체·메타데이터의 일관성이 유지되는지 확인해야 합니다.
쓰기 실패 처리	인증 실패와 저장장치 I/O 실패를 구분해야 합니다. 성공하지 않은 값을 최신 상태로 확정하면 안 됩니다.

실제 장치의 RPMB 키 기록은 되돌릴 수 없는 제약이 있을 수 있으므로 이 글의 예제로 기록 명령을 실행하지 않습니다. 여기서는 공개 규약과 소프트웨어 경로의 의미를 다룹니다. RPMB secure storage

TF-A와 TF-M 자료는 대상부터 다릅니다

이름	주로 다루는 구성	혼동하지 말아야 할 점
TF-A	Arm A-profile 시스템의 부팅·runtime firmware	일반적인 AArch64 BL31/EL3 설명을 모든 Arm MCU에 적용하지 않습니다.
OP-TEE	TEE OS와 TA·클라이언트 통신·secure storage	BL31 자체나 Linux의 일반 프로세스 라이브러리와 같지 않습니다.
TF-M	Arm M-profile 계열의 보안 서비스와 격리 구성	Cortex-M TrustZone 설명에 A-profile의 EL0~EL3 그림을 그대로 넣지 않습니다.
MCUboot	검증·업데이트를 위한 부트로더	TF-M의 secure service 실행 전체를 MCUboot가 맡는 것은 아닙니다.

TF-M의 secure boot 설명은 MCUboot 통합과 이미지 검증을 다룹니다. 내려받기·검증·실행·runtime service는 각각 별도의 단계입니다. 문서에 나온 샘플 메모리 주소나 테스트 키를 제품의 공통 규칙으로 사용하면 안 됩니다. TF-M의 secure boot TF-A firmware 구성

Android 파일 암호화와 메타데이터 암호화는 나누어 봅니다

앞의 OP-TEE 객체 저장과 달리, 여기서는 Android normal world의 userdata 파일 시스템을 다룹니다. FBE는 파일 내용과 이름을 보호합니다. 디렉터리 배치·파일 크기·권한·시각처럼 남는 정보는 메타데이터 암호화의 대상입니다. 둘을 켰다고 모든 파일 데이터가 언제나 두 번 암호화된다고 그리면 안 됩니다. 사용한 블록 암호화 경로와 버전을 확인해야 합니다.

구분	역할	사용 가능 시점
FBE의 DE 저장소	Direct Boot 중 필요한 파일의 내용·이름을 보호합니다.	사용자 잠금 해제 전에도 쓸 수 있습니다. 앱의 Direct Boot 대응과 접근 권한은 별도입니다.
FBE의 CE 저장소	사용자 자격 증명으로 보호하는 파일의 내용·이름을 다룹니다.	해당 사용자의 잠금 해제와 CE 키 설치가 필요합니다.
메타데이터 암호화	FBE가 암호화하지 않는 파일 시스템 정보를 보호합니다.	부팅 시 사용할 별도 키로 장치 계층을 준비합니다. CE 키 전체의 잠금 해제를 뜻하지 않습니다.

/data가 마운트되었다는 사실과 CE 파일을 읽을 수 있다는 사실은 다릅니다. 메타데이터 키의 KeyMint 보호 정보는 아직 읽을 수 없는 userdata에만 의존하지 않도록 별도 metadata 파티션에 보관합니다. vold와 KeyMint 준비가 /data 마운트보다 앞서야 하며, KeyMint 보호는 Verified Boot 신뢰 사슬과 연결됩니다.

고정된 vold 소스에서는 서로 다른 경로입니다

Android android-16.0.0_r1의 vold 커밋 11760521a2e8을 기준으로, MetadataCrypt.cpp의 read_key()는 kEmptyAuthentication으로 메타데이터 키를 가져오거나 생성합니다. create_crypto_blk_dev()는 DmTargetDefaultKey를 구성하고, fscrypt_mount_metadata_encrypted()가 파일 시스템 마운트 경로로 이어집니다. 이때 사용자 CE 키를 전부 여는 것은 아닙니다.

FsCrypt.cpp는 DE 키를 읽어 설치하는 load_all_de_keys()와 사용자 secret으로 인증을 구성하는 fscrypt_unlock_ce_storage()를 나눕니다. 후자는 CE 키를 읽어 설치하고 사용자별 정책을 기록합니다. fscrypt_lock_ce_storage()의 키 제거도 별도 호출입니다. 이 함수 구분만으로 화면이 다시 잠길 때마다 CE 키가 즉시 제거된다고 추론하지 않습니다.

내부 저장소의 메타데이터 암호화는 AOSP 문서가 최초 포맷 시의 통합으로 규정하며, 일반 OTA에서 설정만 바꾸는 기능으로 안내하지 않습니다. 소스에 encrypt_inplace 분기가 있다는 사실도 임의의 출시 기기에 전환을 허용하는 근거는 아닙니다. 이 절은 키·보호 범위·초기화 순서의 설명입니다. 기기 포맷, fstab 수정, 키 추출 또는 실제 Android 부팅 검증은 수행하지 않았습니다.

English: file keys and the metadata boot key

FBE protects file contents and names, while metadata encryption covers remaining filesystem information. DE storage supports Direct Boot; CE storage depends on the user's unlock and key installation. The pinned vold paths prepare the metadata block device separately from CE unlocking. A mounted /data does not mean every CE key is available, and screen relocking alone does not establish key eviction. This is source analysis, not a device migration or runtime test.

TF-M: 서명 확인과 rollback 방지는 별도 조건입니다

TF-M의 신뢰 사슬은 변경할 수 없는 첫 부트 단계와 신뢰할 루트 공개키(ROTPK)에서 시작합니다. 변경 가능한 다음 단계는 실행 전에 인증되어야 합니다. 기본 TF-M 부트로더인 MCUboot를 쓴다는 사실만으로 모든 제품의 키 저장 방식·이미지 구성·보안 정책이 같아지는 것은 아닙니다.

Secure·Non-secure 이미지를 묶는 single-image 방식과 별도로 다루는 multi-image 방식은 검증·업데이트 단위가 다릅니다. 실제 구성의 MCUboot 버전과 옵션, 신뢰키의 위치, 이미지 의존성을 확인해야 합니다. 기본 제공 키는 시험용이며 생산용 신뢰키로 사용하면 안 됩니다. TF-M의 MCU 부팅 구성과 TF-A의 A-profile 부팅 단계를 혼동하지 않습니다.

정상 서명된 옛 이미지도 존재할 수 있으므로 서명 검증만으로 rollback 방지를 설명할 수 없습니다. TF-M 문서의 security counter는 무결성 보호 대상이며 이미지 version과 구분됩니다. 마지막 유효 값을 신뢰 가능한 비휘발성 구성요소에 보관하고 새 이미지의 값과 비교하는 정책이 필요합니다. 명시하지 않으면 version에서 counter를 유도하는 구성도 있으므로 두 값이 언제나 독립적으로 설정된다고 단정하지 않습니다.

TF-M Secure boot: 신뢰 사슬·이미지 구성·security counter. 이 절은 문서의 구성 원리를 설명하며 키 생성·기기 서명·flash 업데이트를 수행한 시험 결과가 아닙니다.

MCUboot에서 키를 선택하는 방법도 신뢰 정책입니다

공개키는 비밀이 아니지만 어떤 공개키를 신뢰할지 정하는 값은 보호되어야 합니다. 이미지가 제시한 임의의 공개키를 그대로 승인하면 공격자도 자신의 이미지에 서명할 수 있습니다. 첫 검사기와 키 저장소를 더 이른 신뢰 단계 또는 하드웨어로 보호해야 한다는 원칙은 위 TF-M 설명과 연결됩니다.

MCUboot 설계의 기본 구성은 부트로더에 공개키를 포함하고 이미지의 KEYHASH로 키를 찾습니다. MCUBOOT_HW_KEY 구성에서는 이미지의 PUBKEY를 사용하되, 그 해시를 장치에서 신뢰해 가져온 값과 먼저 비교합니다. MCUBOOT_BUILTIN_KEY는 별도 provision된 키를 crypto backend가 ID로 다루는 방식이며 지원 backend·알고리즘 조건이 있습니다. 모든 MCU가 ROM·OTP에 같은 형태로 키를 저장한다고 일반화하지 않습니다.

서명용 개인키와 검증용 공개키의 관리 주체도 나눕니다. 기기에서 서명을 검증하기 위해 생산 개인키를 넣을 필요는 없습니다. Zephyr MCUboot 개발 기본 키는 공개되어 있으므로 제품용으로 사용하면 안 됩니다. 서명 권한, 키 교체와 복구·디버그 경로의 권한을 제품 정책으로 정해야 합니다.

서명 성공은 암호화나 구버전 차단을 대신하지 않습니다. MCUboot의 하드웨어 rollback 보호는 선택 기능이며, protected TLV의 보안 카운터와 신뢰 가능한 비휘발 값을 비교하는 플랫폼 구현이 필요합니다. 같은 보안 카운터를 유지한 예전 버전은 허용될 수 있습니다. 출시 검증에서는 유효·누락·다른 키·변조 서명과 구버전, 실패 뒤 복구 경로를 분리해 시험합니다. 이는 시험 항목이지 여기서 장치에 키를 생성·기록하거나 firmware를 실행한 결과가 아닙니다.