The document presents a secure storage architecture utilizing OP-TEE, detailing key management and atomic operations required for reliable data handling. It outlines mechanisms for file encryption, enforced confidentiality, and integrity guarantees while allowing atomic updates to mitigate risks such as rollback attacks. Future work includes strengthening the separation of storage among different Trusted Applications (TAs) and improving protections against unauthorized access.

1. Presented by
Date
Event
SFO15-503: Secure storage
in OP-TEE
James Kung, SY ChiuJames Kung, Sheng-Yu Chiu
Friday 25 September 2015
SFO15

2. Agenda
● Overview
● Key Manager
● Atomic Operations
● Future Work

3. Secure Storage System Architecture
REE File Operation Interface
TEE Supplicant
TEE DriverREE
FileSystem TEE FileSystem Key
Manager
TEE File Operation Interface
TEE Trusted Storage Service
TATATA
GP Trusted Storage API
Support Atomic Operations
Normal World Secure World
UserSpaceKernelSpace

4. GP Trusted Storage Requirement
From GlobalPlatform TEE Internal Core API v1.1:
(section 2.5 and section 5.2)
● Must be bound to a particular device
● Guarantees on the confidentiality and integrity of the data
● Guarantees on the atomicity of the operations that modify the storage
● Ability to hide sensitive key material from the TA itself
● Separation of storage among different TAs
● Provide protection against rollback attacks (future work)

5. TEE File Operation Interface
int (*open)(const char *file, int flags, ...);
int (*close)(int fd);
int (*read)(int fd, void *buf, size_t len);
int (*write)(int fd, const void *buf, size_t len);
tee_fs_off_t (*lseek)(int fd, tee_fs_off_t offset, int whence);
int (*rename)(const char *old, const char *new);
int (*unlink)(const char *file);
int (*ftruncate)(int fd, tee_fs_off_t length);
int (*access)(const char *name, int mode);
int (*mkdir)(const char *path, tee_fs_mode_t mode);
tee_fs_dir *(*opendir)(const char *name);
int (*closedir)(tee_fs_dir *d);
struct tee_fs_dirent *(*readdir)(tee_fs_dir *d);
int (*rmdir)(const char *pathname);

6. TEE Storage And File Structure In REE
File System
block 0
block 1
block N
● Provide separate folder for each TA
● TEE filename == object id (provided by TA)
● TEE file == a folder contains a meta file and
several block files (folder name is object id)
● Meta file
○ Storing info. of a TEE file. e.g. file length.
○ Always encrypted
● block file
○ Storing TEE file data
○ Optionally encrypted depends on the
compile time flag - CFG_ENC_FS
/data/tee/
<obj-id>/
<ta-uuid>/
meta
* default max. data size in
block file is 4KB
* default max. number of
blocks is 1024
* default max TEE file size
= 4MB (4KB * 1024)

7. ● Overview
● Key Manager
● Atomic Operations
● Future Work

8. Key Manager
● Provide file encryption/decryption functions
● Key management
○ Secure Storage Key (SSK)
■ Per-device key
■ Used by secure storage subsystem for FEK
encryption/decryption
■ Generated and stored in secure memory at boot time
○ File Encryption Key (FEK)
■ Per-file key
■ Used for TEE file encryption/decryption
■ Generated, encrypted and stored in meta file when a
new TEE file is created

9. Key Derivation
● Secure Storage Key (SSK)
○ SSK = HMACSHA256
(HUK, Chip ID || “static string”)
○ HUK: Hardware Unique Key
● File Encryption Key (FEK)
○ By default, generated by Fortuna (PRNG*)
○ Default key length: 128 bits
* It is better to leverage platform H/W RNG(TRNG) if your platform supports that
* Can be implemented in platform porting layer
* To avoid other
subsystems to generate
the same per-device key

10. Meta Data Encryption
Meta IV Tag Encrypted Meta Data
AESECB
SSK
FEK
AESGCM
Meta DataMeta IVEncrypted FEK
Encrypted FEK
Generated by PRNG, and default length is 96 bits
Meta Data = {
TEE_file_data_length;
backup_version_table[number of blocks];
}
Meta File:
AAD

11. Block Data Encryption
Block IV Tag Encrypted Block Data
AESECB
SSK
FEK
AESGCM
Block DataBlock IV
Generated by PRNG, and default length is 96 bits
...Encrypted FEKMeta File:
Block File:
Decryption

12. ● Overview
● Key Manager
● Atomic Operations
● Future Work

13. What is Atomic Update
● Each update can only have two results
○ Update succeed
○ Update failed, rollback to old version
● We cannot modify the file contents directly
○ Out-of-place update
○ Modify a copy of file content instead

14. Changes to Support Out-of-place Update
data.0 data.1
write datawrite data
● Both Meta and Block file has an
additional attribute called backup
version, backup version is 0 or 1
● We toggle the backup version each
time when we want to update
something
● We should follow the step to update
meta or block file

15. How to Keep Track Backup Version
Meta.0 Block0.0
Block1.1
BlockN.0
0 1 1 0
version table
● Introduce a version table in meta
data, which stores the backup
version of each Block file. This is
used to keep track of the backup
version of each block file.
Block2.1

16. GP Internal Core API Says...
● The following operations should be atomic
○ Write
○ Truncate
○ Rename
○ Create/Delete

17. Ensure Atomic Operation
Commit stage
Write new meta file to storage (commit the change).
Remove old meta file
Out-of-place update stage
Any fault here would cause a failed update
(no changes has been made)
Clean-up stage
Any fault here was ignored
(changes has been made)
* should having a tool to do garbage collection to clean up invalid block
or meta. The idea is similar to fsck for Linux file system.

18. Atomic Write Operation
block0.0
block1.1
block0.1
(in memory)
meta.0
0 1
meta.1
0 11
Assume block size is 1KB, we want to write 20 Bytes at position 0
write data

19. Atomic Truncate Operation
meta.0
block0.0
block1.1
meta.1
(in memory)
Assume block size is 1KB, file length is 1.5 KB, we want to truncate it
to 500 Bytes
len:1.5KB len:1.5KBlen:500B

20. REE path: .../bar/REE path: .../foo/
Atomic Rename Operation
meta.0
block0.0
block1.1
meta.0
block0.0
block1.1
hard link
Assume we want to rename foo to bar
* ISO C requires rename to be atomic. We are considering to use it.
** Atomic override is not supported yet.

21. Atomic Create/Delete Operation
● Create
○ If the meta file is successfully encrypted and stored,
we are done.
○ If any failure occurs during meta file creation, no file
is created.
● Delete
○ Rename <filename> to <filename>.trash
○ Then remove <filename>.trash
* unlink is not need to be atomic. Thus we can’t simply unlink(‘meta’)

22. ● Overview
● Key Manager
● Atomic Operations
● Future Work

23. Binding TEE File to TA
● TEE file folder can be copied or moved into other TA’s
folder in normal world
● We do not have a mechanism to prevent TA’s from
opening other TA’s TEE file(s)
● A simple way to bind TEE file to TA is adding TA’s UUID
to meta file

24. Rollback Attack Detection
● TEE file content can be backed up and then restored
without any error. TEE should be able to detect this kind
of actions.
● The solution is to add a file version number in meta file
and store it in another safe place.
● The safe place can be
○ normal world file system (Protection Level = 100)
○ RPMB (Protection Level = 1000)

25. Thank you~