OP-TEE 4.10.0 · AOSP AVB · TF-A와 TF-M 구성 구분

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

부팅 이미지의 검증, 실행 중의 격리, 저장 데이터의 기밀성·무결성·재전송 방지를 구분합니다.

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

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

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

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

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

    TEE의 저장 API로 객체를 읽거나 씁니다.

    secure world의 저장 처리로 전달합니다.

  2. OP-TEE

    키와 암호화·무결성 관련 처리를 수행합니다.

    RPC로 normal world의 저장 작업을 요청할 수 있습니다.

  3. tee-supplicant와 REE 파일 시스템

    저장에 필요한 파일 I/O를 수행합니다.

    읽어 온 데이터와 결과를 돌려줍니다.

  4. 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-AArm A-profile 시스템의 부팅·runtime firmware일반적인 AArch64 BL31/EL3 설명을 모든 Arm MCU에 적용하지 않습니다.
OP-TEETEE OS와 TA·클라이언트 통신·secure storageBL31 자체나 Linux의 일반 프로세스 라이브러리와 같지 않습니다.
TF-MArm 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 구성