개요
https://optee.readthedocs.io 문서를 구글 번역기 + 네이버번역기를 이용하여 번역하였습니다.
즉, 기계가 번역한 내용이므로 대략적인 내용은 확인가능합니다. 제대로 보시려면 원문을 보시길 권유드립니다.
글순서
- [OPTEE 문서번역] OPTEE GettingStarted
- [OPTEE 문서번역] OPTEE Architecture - 1 Core
- [OPTEE 문서번역] OPTEE Architecture - 2 Crypt
- [OPTEE 문서번역] OPTEE Architecture - 3 Device Tree
- [OPTEE 문서번역] OPTEE Architecture - 4 File structure
- [OPTEE 문서번역] OPTEE Architecture - 5 GlobalPlatform API
- [OPTEE 문서번역] OPTEE Architecture - 6 Libraries API
- [OPTEE 문서번역] OPTEE Architecture - 7 Porting Guide
- [OPTEE 문서번역] OPTEE Architecture - 8 Secure Boot
- [OPTEE 문서번역] OPTEE Architecture - 9 Secure storage
- [OPTEE 문서번역] OPTEE Architecture - 10 Trusted Applications
- [OPTEE 문서번역] OPTEE Architecture - 11 Virtualization
9. Secure storage
9.1. Background
OP-TE의 시큐어 스토리지는 GloblaPlatform 의 TEE Internal Core API (여기서 신뢰할 수 있는 스토리지라고 함)에서 정의한 바에 따라 구현된다. 이 규격은 저장한 데이터의 기밀성과 무결성을 보증하는 범용 데이터 및 핵심 자료와 저장소를 수정하는 작업의 원자성을 저장할 수 있어야 한다고 규정한다(여기서 원자성은 전체 작업이 성공적으로 완료되거나 쓰기가 수행되지 않는다는 것을 의미한다).
현재 OP-TEE에는 두 가지 보안 스토리지 구현이 있다.
- 첫 번째 것은 정상 세계 (REE) 파일 시스템에 의존합니다. 이 문서에 설명되어 있으며 기본 구현입니다. 컴파일시
CFG_REE_FS = y에 의해 활성화됩니다.- 두 번째는 eMMC 장치의 RPMB (Replay Protected Memory Block) 파티션을 사용하고,
CFG_RPMB_FS = y를 설정하여 활성화됩니다. 포스팅작성중 에 설명되어 있습니다.
정상적인 세계 파일 시스템과 RPMB 구현을 동시에 사용할 수 있습니다. 이를 위해 두 개의 OP-TEE 고유 저장 장치 식별자, 즉 TEE_STORAGE_PRIVATE_REE와 TEE_STORAGE_PRIVATE_RPMB이 정의되었습니다. 컴파일시 구성에 따라 하나 또는 여러 개의 값을 사용할 수 있습니다. TEE_STORAGE_PRIVATE 값은 가능한 경우 REE FS를 선택하고 그렇지 않으면 RPMB FS를이 순서로 선택합니다.
9.2. REE FS Secure Storage
Secure Storage System Architecture
Source Files in OP-TEE OS
| Source file | Purpose |
|---|---|
| core/tee/tee_svc_storage.c | TEE trusted storage service calls |
| core/tee/tee_ree_fs.c | TEE file system & REE file operation interface |
| core/tee/fs_htree.c | Hash tree |
| core/tee/tee_fs_key_manager.c | Key manager |
| lib/libutee/ | GlobalPlatform Internal API library |
9.2.1. Basic File Operation Flow
TA가 영구 저장소에 데이터를 쓰도록 GP Trusted Storage API 에서 제공하는 쓰기 기능을 호출하면 TEE 신뢰할 수있는 저장소 서비스에 구현 된 해당 syscall이 호출되고 일련의 TEE 파일 작업이 호출되어 데이터를 저장합니다 . TEE 파일 시스템은 데이터를 암호화하고 REE 파일 작업 명령 및 암호화 된 데이터를 일련의 RPC 메시지로 TEE 요청자에게 보냅니다. TEE 요청자가 메시지를 수신하고 암호화 된 데이터를 Linux 파일 시스템에 따라 저장합니다. 파일 읽기도 비슷한 방식으로 처리됩니다.
9.2.2. GlobalPlatform Trusted Storage Requirement
다음은 가장 중요한 요구 사항을 나열한 사양에서 발췌 한 것입니다.
(see GP TEE Internal Core API section 2.5 and 5.2) 1. 신뢰할 수있는 저장소는 적합한 암호화 보호가 적용되는 한 비보안 자원에 의해 뒷받침 될 수 있으며 TEE 코드 및 데이터 자체를 보호하는 수단만큼 강해야합니다. 2. 신뢰할 수있는 저장소는 특정 장치에 바인딩 되어야합니다. 즉, 동일한 TEE에서 실행되는 인증 된 TA와 데이터 생성시와 동일한 장치에서만 액세스하거나 수정할 수 있어야합니다. 3. 민감한 핵심 자료를 TA 자체에서 숨길 수있는 기능. 4. 각 TA는 해당 TA의 모든 인스턴스간에 공유되지만 다른 TA와는 분리 된 자체 저장 공간에 대한 액세스 권한을가집니다. 5. 신뢰할 수있는 저장소는 롤백 공격에 대한 최소 수준의 보호를 제공해야합니다. 실제로 물리적 인 저장소는 안전하지 않은 영역에있을 수 있으므로 TEE 외부의 작업에 취약합니다. 일반적으로 구현은 그 목적을 위해 REE (보호 레벨 100) 또는 TEE (보호 레벨 1000)에 의해 제어되는 하드웨어 자산에 의존 할 수 있습니다.
CFG_RPMB_FS = y로 구성된 경우, 롤백에 대한 보호는 TEE에 의해 제어되고 1000으로 설정됩니다.`CFG_RPMB_FS = n '이면 롤백에 대한 보호가 없으며 보호 레벨은 0으로 설정됩니다.
9.2.3. TEE File Structure in Linux File System
기본적으로 OP-TEE는 Linux 파일 시스템의 안전한 저장 공간으로/data/tee/를 사용합니다. 각 영구 객체에는 내부 식별자가 할당됩니다. 이는 리눅스 파일 시스템에서/data/tee/<file number>로 볼 수있는 정수입니다.
디렉토리 파일/data/tee/dirf.db는 보안 스토리지에있는 모든 오브젝트를 나열합니다. 아래에 설명 된대로 모든 정상적인 세계 파일은 무결성 보호되고 암호화됩니다.
9.3. Key Manager
키 관리자는 TEE 파일 시스템의 구성 요소이며 데이터 암호화 및 해독 처리와 중요한 키 자료 관리를 담당합니다. 키 관리자는 SSK (Secure Storage Key), TSK (Tab Storage Key) 및 FEK (File Encryption Key)의 세 가지 유형의 키를 사용합니다.
9.3.1. Secure Storage Key (SSK)
SSK는 장치 별 키이며 OP-TEE가 부팅 될 때 보안 메모리에 생성되어 저장됩니다. SSK는 TA 저장소 키 (TSK)를 파생시키는 데 사용됩니다.
SSK is derived by
SSK = HMACSHA256 (HUK, Chip ID || “static string”)
Hardware Unique Key(HUK) 및 칩 ID를 얻는 함수는 플랫폼 구현에 따라 다릅니다. 현재 OP-TEE OS에서는 보안 저장소 하위 시스템에 사용되는 장치 별 키 인 SSK 만 있지만 미래에는 동일한 알고리즘을 사용하여 여러 하위 시스템에 대해 서로 다른 장치 별 키를 만들어야 할 수도 있습니다 SSK를 생성한다. 여러 하위 시스템에 대해 서로 다른 장치 별 키를 생성하는 쉬운 방법은 다른 정적 문자열을 사용하여 키를 생성하는 것입니다.
9.3.2. Trusted Application Storage Key (TSK)
TSK는 SSK 및 TA 식별자 (UUID)에서 생성되는 신뢰할 수있는 응용 프로그램 별 키입니다. 이는 FEK를 보호하기 위해, 즉 FEK를 암호화 / 해독하기 위해 사용됩니다.
TSK is derived by:
TSK = HMACSHA256 (SSK, TA_UUID)
9.3.3. File Encryption Key (FEK)
새 TEE 파일이 생성되면 키 관리자는 TEE 파일에 대해 PRNG (페소 임의 번호 생성기)로 새 FEK를 생성하고 암호화 된 FEK를 메타 파일에 저장합니다. FEK는 메타 파일에 저장된 TEE 파일 정보 또는 블록 파일에 저장된 데이터를 암호화 / 해독하는 데 사용됩니다.
9.4. Hash Tree
해시 트리는 보안 저장소 파일의 데이터 암호화 및 암호 해독을 처리합니다. 해시 트리는 트리의 각 노드 (struct tee_fs_htree_node_image below)가 두 개의 자식 노드와 데이터 블록을 보호하는 바이너리 트리로 구현됩니다. 메타 데이터는 상위 노드를 보호하는 헤더 (struct tee_fs_htree_image below)에 저장됩니다.
원자 적 업데이트를 보장하기 위해 모든 필드 (header, nodes, and blocks)는 0과 1의 두 가지 버전으로 복제됩니다. 자세한 내용은 [core/tee/fs_htree.c](https://github.com/OP-TEE/optee_os/blob/master/core/tee/fs_htree.c를 참조하십시오.
9.4.1. Meta Data Encryption Flow
Meta data encryption
메타 데이터를 업데이트해야하는 경우 PRNG가 새 메타 IV를 생성합니다. 메타 IV의 크기는 core/include/tee/fs_htree.h에 정의되어 있습니다. 다음과 같이 메타 데이터 및 노드 데이터의 데이터 구조가 fs_htree.h에 정의되어 있습니다.
struct tee_fs_htree_node_image {
uint8_t hash[TEE_FS_HTREE_HASH_SIZE];
uint8_t iv[TEE_FS_HTREE_IV_SIZE];
uint8_t tag[TEE_FS_HTREE_TAG_SIZE];
uint16_t flags;
};
struct tee_fs_htree_meta {
uint64_t length;
};
struct tee_fs_htree_imeta {
struct tee_fs_htree_meta meta;
uint32_t max_node_id;
};
struct tee_fs_htree_image {
uint8_t iv[TEE_FS_HTREE_IV_SIZE];
uint8_t tag[TEE_FS_HTREE_TAG_SIZE];
uint8_t enc_fek[TEE_FS_HTREE_FEK_SIZE];
uint8_t imeta[sizeof(struct tee_fs_htree_imeta)];
uint32_t counter;
};
9.4.2. Block Data Encryption Flow
Block data encryption
블록 데이터를 업데이트해야하는 경우 PRNG가 새 블록 IV를 생성합니다. 블록 IV의 크기는 core/include/tee/fs_htree.h에 정의되어 있습니다.
9.5. Atomic Operation
atomicity 의 "GlobalPlatform Trusted Storage" 요구 사항에 따르면 다음 작업은 atomic update를 지원해야합니다.
Write, Truncate, Rename, Create and Delete
원 자성을 보장하기 위해 OP-TEE 보안 스토리지에 사용되는 전략은 비공개 업데이트입니다.
9.6. RPMB Secure Storage
이 문서는CFG_RPMB_FS = y를 설정함으로써 가능 해지는 OP-TEE의 RPMB 보안 스토리지 구현을 설명합니다. 신뢰할 수있는 응용 프로그램은TEE_STORAGE_PRIVATE_RPMB와 같은 저장소 ID를 전달하거나, CFG_REE_FS가 비활성화 된 경우 TEE_STORAGE_PRIVATE를 전달하여이 구현을 사용할 수 있습니다. RPMB에 대한 자세한 내용은 JEDEC eMMC 사양 (JESD84-B51)을 참조하십시오.
The architecture is depicted below.
| NORMAL WORLD : SECURE WORLD |
:
U tee-supplicant : Trusted application
S (rpmb.c) : (secure storage API)
E ^ ^ : ^
R | | : |
~~~~~~~ ioctl ~~~~~~~|~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~
K | | : OP-TEE
E v v : (tee_svc_storage.c)
R MMC/SD subsys. OP-TEE driver : (tee_rpmb_fs.c, tee_fs_key_manager.c)
N ^ ^ : ^
E | | : |
L v | : |
Controller driver | : |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~
v v
Secure monitor / EL3 firmware
Linux 커널의 MMC / SD 서브 시스템에 대한ioctl ()인터페이스에 대한 정보는 리눅스 핵심 MMC 헤더 파일 인 linux/mmc/core.h와 mmc-utils 저장소를 참조하십시오.
9.6.1. The Secure Storage API
이 부분은 REE 기반 파일 시스템과 공통입니다. core/tee/tee_svc_storage.c 와 RPMB 파일 시스템 사이의 인터페이스는 tee_file_operations, 즉struct tee_file_ops입니다.
9.6.2. The RPMB filesystem
FS 구현은 전적으로 core/tee/tee_rpmb_fs.c이고 RPMB 분할은 세 부분으로 나뉩니다.
- 처음 128 바이트는 파티션 데이터 용으로 예약되어 있습니다 (
struct rpmb_fs_partition).- 오프셋 512에는 파일 할당 테이블 (FAT)이 있습니다. 이것은
struct rpmb_fat_entry요소의 배열로, 파일 당 하나씩 있습니다. FAT는 파일이 파일 시스템에 추가 될 때 동적으로 커집니다. 무엇보다도 각 항목에는 파일 데이터의 시작 주소, 크기 및 파일 이름이 있습니다.- RPMB 파티션의 끝에서 시작하여 파일 데이터 영역이 아래로 확장됩니다.
파티션의 공간은 범용 할당 자 함수tee_mm_alloc (...) 및 tee_mm_alloc2 (...)에 의해 할당됩니다.
모든 파일 조작은 원자 적입니다. 이것은 다음 속성 덕분에 가능합니다.
- 단일 블록의 데이터를 RPMB 파티션에 쓰는 것은 eMMC 사양에 의해 원자적일 수 있습니다.
- 수정 된 파일에 대한 FAT 블록은 데이터가 성공적으로 기록 된 후 항상 마지막으로 업데이트됩니다.
- 파일 내용에 대한 업데이트는 데이터가 "신뢰할 수있는 쓰기 블록 수"블록을 넘지 않는 경우에만 수행됩니다. 그렇지 않은 경우 또는 파일을 확장해야하는 경우 새 파일이 작성됩니다.
9.6.3. Device access
OP-TEE에는 eMMC 컨트롤러 드라이버가 없습니다. 장치 작업은 모두 정상적인 세계를 통과해야합니다. 그것들은tee-supplicant 프로세스에 의해 처리됩니다. 프로세스는 커널에있는ioctl ()인터페이스를 사용하여 디바이스에 접근합니다. tee-supplicant는 또한 가상 RPMB 장치를 테스트 목적으로 구현하는 에뮬레이션 모드를 가지고 있습니다.
-
RPMB 작업은 다음과 같습니다.
장치 정보 읽기 (파티션 크기, 신뢰할 수있는 쓰기 블록 수). 보안 키 프로그래밍. 이 키는 인증 목적으로 사용됩니다. 암호화에 사용되는 아래에 정의 된 SSK (Secure Storage Key)와는 다릅니다. 그러나 SSK와 마찬가지로 보안 키는 하드웨어 고유 키 또는 식별자에서 파생됩니다. 현재, 함수
tee_otp_get_hw_unique_key ()는 RPMB 보안 키를 생성하는 데 사용됩니다. 쓰기 카운터 값을 읽습니다. 쓰기 카운터는 읽기 및 쓰기 요청 중에 HMAC 계산에 사용됩니다. 이 값은 초기화시에 읽혀지고,struct tee_rpmb_ctx에 저장됩니다. 즉,rpmb_ctx-> wr_cnt입니다. 데이터 블록을 읽거나 씁니다.
RPMB 작업은 FS 계층의 요청에 따라 시작됩니다. 요청과 응답을위한 메모리 버퍼는thread_rpc_alloc_payload (...)를 사용하여 공유 메모리에 할당됩니다. 버퍼는thread_rpc_cmd ()함수 덕분에 정상적인 세계로TEE_RPC_RPMB_CMD 메시지로 전달됩니다. 대부분의 RPMB 요청 및 응답은 JEDEC eMMC 사양에 정의 된 데이터 프레임 형식을 사용합니다. HMAC 인증도 여기에 구현됩니다.
9.6.4. Encryption
FS 암호화 루틴은 core/tee/tee_fs_key_manager.c에 있습니다. 블록 암호화는 파일 데이터를 보호합니다. 알고리즘은 암호화 된 소금 섹터 초기화 벡터 (ESSIV)가있는 CBC (Cipher Block Chaining) 모드의 128 비트 AES입니다 (자세한 내용은 CBC-ESSIV 참조).
- OP-TEE를 초기화하는 동안 128 비트 AES SSK (Secure Storage Key)는 Hardware Unique Key (HUK)에서 파생됩니다. 보안 메모리에 보관되어 디스크에 기록되지 않습니다. 신뢰할 수있는 응용 프로그램 저장소 키는 SSK와 TA UUID에서 파생됩니다.
- 각 파일에 대해 128 비트 암호화 된 파일 암호화 키 (FEK)는 파일을 만들 때 무작위로 생성되고 TSK로 암호화되며 파일의 FAT 항목에 저장됩니다.
- 각 256 바이트 데이터 블록은 CBC 모드로 암호화됩니다. 초기화 벡터는 ESSIV 알고리즘에 의해, 즉 FEK의 해시로 블록 번호를 암호화하여 얻습니다. 이렇게하면 다음과 같이 파일의 모든 블록에 직접 액세스 할 수 있습니다.
c FEK = AES-Decrypt(TSK, encrypted FEK); k = SHA256(FEK); IV = AES-Encrypt(128 bits of k, block index padded to 16 bytes) Encrypted block = AES-CBC-Encrypt(FEK, IV, block data); Decrypted block = AES-CBC-Decrypt(FEK, IV, encrypted block data);
SSK, TSK 및 FEK 처리는 REE 기반 보안 저장 장치와 공통적 인 반면 AES CBC 블록 암호화는 RPMB에만 사용됩니다 (REE 구현은 GCM을 사용함). FAT는 암호화되지 않습니다.
9.6.5. REE FS hash state
CFG_REE_FS = y와CFG_RPMB_FS = y 둘 다 설정되어 있다면, REE FS는 REE FS의 상태를 나타내는 해쉬를 담고있는 RPMB에 특별한 파일dirfile.db.hash을 생성 할 것입니다.
9.7. Important caveats
Warning
현재 OP-TEE 플랫폼은 보안 작동에 필요한 하드웨어 고유 키 또는 칩 ID의 검색을 지원할 수 없습니다. 모든 플랫폼에서 암호 해독에 대한 보호가 없거나 다른 장치에 대한 Secure Storage 복제가 발생하는 상수 키가 사용됩니다. 이는 SoC에서 주요 데이터를 검색하는 방법에 대한 정보가 공급 업체에 민감한 것으로 간주되고 공개적으로 사용할 수 없기 때문입니다.
OP-TEE에는 OTP (One-Time-Programmable) 메모리에서 키를 읽는 API가 있습니다. 그러나 기존 플랫폼 구현은 없습니다.
보안 저장소가 플랫폼에서 안전하게 작동하도록하려면 플랫폼 코드에서 구현을 다음과 같이 정의해야합니다.
void tee_otp_get_hw_unique_key(struct tee_hw_unique_key *hwkey);
int tee_otp_get_die_id(uint8_t *buffer, size_t len);
이러한 구현은 SoC 공급 업체가 정의한 방법에 따라 SoC 특정 e-fuse 또는 암호화 장치에서 핵심 데이터를 가져와야합니다.
9.8. References
보안 저장 장치에 대한 자세한 내용은 Presentations 및 TEE Internal Core API 사양의 SFO15-503, LAS16-504, SFO17-309를 참조하십시오.