1. Introduction to safe storage
Secure storage is one of the important features of TEEOS. Secure storage is mainly used to save sensitive data such as keys and other information for users. When the user uses the secure storage function to save data, the data will be encrypted in the TEE, and then saved to the relevant storage area on the REE side. According to the security requirements for data storage and usage scenarios, the common secure storage of TEE is generally divided into RPMB secure storage and SFS secure storage. RPMB secure storage is a partition with security features in eMMC. It is characterized by being invisible to the non-secure world and can prevent replay and rollback attacks. However, its capacity is small, so RPMB storage is generally used for data with high security requirements. SFS secure storage uses the file system on the REE side for storage services. The data encrypted by the TEE will be stored in the storage medium on the REE side by using the file system on the non-secure side. Therefore, it has a large capacity and can store many files. However, due to It uses the file system on the non-secure side, so the stored files are visible on the REE side, and its security is lower than that of RPMB.
This article will analyze the basic implementation of SFS secure storage in OPTEE3.18 version. The secure storage in the following article refers to SFS secure storage. The overall framework of secure storage is shown in Figure 1.1:
Figure 1.1 Secure Storage Framework
OPTEE provides GP secure storage API in user mode, and TA calls GP API to operate on the data to be saved. The specific functions are implemented in the file system module of OPTEE kernel mode, which mainly implements data storage. Decryption-related functions and corresponding ciphertext data RPC message sending functions. The daemon process tee_supplicant on the REE side mainly completes the RPC message reception and the operation function of securely storing files on the REE side.
The main files involved in OPTEE secure storage are shown in Figure 1.2:
Figure 1.2 Safe storage file directory
2. Safe storage file operation
Figure 2.1 lists the GP interface for secure storage file operations and the relationship diagram of related system calls. The function at the beginning of syscall is the specific implementation of the secure storage GP API function in the OPTEE kernel. Next, we analyze the file format, basic data structure, and file creation process in secure storage.
Figure 2.1 Secure Storage API
2.1 Safe storage file format and main data structure
The secure storage file format is shown in Figure 2.2. It is mainly divided into three parts: file header information, file node description information, and data body information. The data block of the data body is stored at a granularity of 4K. OPTEE uses a hash binary tree to manage securely stored file data, and each node tee_fs_htree_node_image in the tree protects its two child nodes and a data block. Metadata is stored in the head node tee_fs_htree_image, which also protects the top-level nodes. File format for secure storage All fields are replicated using two versions ver0 ver1 to ensure atomic updates.
Figure 2.2 File format
The head node tee_fs_htree_image structure is specifically defined as follows, where iv is used when encrypting the head, tag is generated after encrypting the head, enc_fek is the ciphertext data of the key fek of the encrypted data file, imeta is generated after encrypting the head, and counter It is ver information, indicating whether it is stored in ver0 or ver1.
The specific definition of the node tee_fs_htree_node_image structure is as follows, hash is the hash value of the saved node, the main function of this value is to find the head of the file during file operation, iv is used for encrypting data bloc, different data blocks correspond to different iv values, tag is Generated after encrypting a data block, flags identifies the version number information of the data block.
Another main structure tee_fs_fd is specifically defined as follows, which mainly stores fd, dir, uuid and other information used in file operations.
2.2 Secure File Operations
This section mainly analyzes the basic operation process of OPTEE secure storage files, including the creation, opening, reading and writing process of secure storage files.
(1) Safe storage file creation: The safe storage file creation process is the most complicated process of the entire file operation, and the safe storage file creation process is shown in Figure 2.3. When using the secure storage function to save user files for the first time, two types of files will be generated in the /data/tee directory, namely the dirf.db file and files named after numbers. The files named by numbers will be named according to the different files created. to add up. The dirf.db file saves the directory information and node information of all files managed by the entire secure storage function. This file will only be created once. Subsequent operations on the file will update the content of dirf.db. The file named after the number is saved. is the user file information. To perform basic operations on user files, OPTEE needs to index the dirf.db file to find the required specific user files. syscall_storage_obj_create is the main entry of the secure storage file creation function in the kernel space. The main flow of the creation process is analyzed below.
Permission check: Before creating a security file, the vm_check_access_rights function will be used to verify the object permission of TA to call the secure storage operation, and only after the permission verification is passed, the subsequent operations will be performed.
Dirt.db file creation: get_dirh is the main implementation of creating dirt.db. When the tee_fs_rpc_create_dfh function creates the dirt.db file for the first time, it notifies the ree side tee_supplicant to create the file, and tee_fs_htree_open creates the file node information. tee_fs_htree_sync_to_storage mainly stores tee_fs_htree_node_image and tee_fs_htree_image information in dirt.db.
Secure file creation: Secure file creation is realized through ree_fs_open_primitive. This process will notify the ree side tee_supplicant to create a file named after a number. At this time, no specific data information has been written in the file.
Safe file writing: safe file head and data block writing is realized through ree_fs_write_primitive, and the file creation process is finally completed, and the initialized data is written to the ree side.
Figure 2.3 Security file creation process
(2) Open the safe storage file: When you need to open a certain safe storage file, you need to find the corresponding number-named file number from the global directory file dirt.db first. Opening dirf.db is realized by calling the get_dirt function. Finally call tee_supplicant on the REE side to open the /data/tee/dirf.db file and return the fd value of the file, read the latest file header data in dirt.db, decrypt and obtain the FEK used for file encryption and decryption, and create a file Node tree, after opening the dirf.db file and establishing the file node tree, find the storage number of the security file by reading the dirf_entry corresponding to the security file in the data area of the dirf.db file. Before obtaining the safe storage file number, a series of verification checks are required, and the correct file number is obtained after the check is passed. After obtaining the security file number, the file can be opened, the header part of the security file is read, the root node information is obtained, and the node tree of the security file is established, and then the read and write operation of the security file can be started.
(3) Secure storage file read and write operations: Secure storage read and write operations depend on the open operation, and can only be performed after the open operation is performed. The secure file read operation first obtains the TA's session ID and running context and checks the permissions. Then call the ree_fs_read function to realize the operation of reading data, and call the ree_fs_write function to realize the operation of writing data.
3. Safe storage file encryption process
3.1 Keys in secure storage
In the secure storage of OPTEE, three types of keys are mainly involved: SSK secure storage key, TSK TA storage key, and FEK file encryption key. The relationship among them is shown in Figure 3.1. Among them, huk is the unique key of the chip, which derives the basic key SSK for safe storage through chipid and other related parameters. For different TAs, each TA's own storage key TSK is derived according to the uuid value and SSK. This can ensure that files encrypted and stored by different TAs cannot be decrypted by other files, which ensures security to a certain extent. TSK is not the key to finally encrypt the file, but the key to encrypt and decrypt the randomly derived file encryption key FEK. Among the three types of keys, SSK TSK does not output TEE regardless of plaintext and ciphertext, and FEK ciphertext and data ciphertext are encapsulated together and stored in the REE side file system.
Figure 3.1 key relationship diagram
3.2 Safe storage file encryption process
The core operation in secure storage is to encrypt and decrypt secure files. The data that needs to be encrypted is encrypted for metadata and encrypted for specific data blocks. The metadata and block data encryption process is shown in Figure 3.2. The metadata is the data in tee_fs_hreee_node_image. During the encryption process, a random AES key FEK will be generated first. This value is generally saved in the form of enc_fek and decrypted by TSK when in use. used later. The data block area is the user data information that needs to be saved and the data in tee_fs_htree_node_image. The encryption algorithm of metadata and block data adopts AES GCM algorithm in OPTEE, and the KEY used is FEK. The difference is that there are different IV values in the encryption process.
Figure 3.2 Metadata block data encryption process
4. Summary
The secure storage function is an important function in TEEOS, and different TEE products have different implementations. This paper makes a simple analysis of the SFS part of OPTEE secure storage. We found that the process involved in the secure storage operation is relatively complicated, which involves the encryption and decryption key derivation method, the selection of data encryption and decryption algorithms, and the way of data file management. TEE actively interacts with REE and other functions. These parts all affect the security stability and performance of secure storage. Although OPTEE secure storage stores each data file separately, the index information for file operations is stored in dirt.db centrally, so when the dirt.db file is damaged, there will be a risk that all files cannot be read. Therefore, in the actual use of OPTEE, customized modifications can be considered, and the file can be backed up in different partitions on the REE side.
5. Reference materials
1. "Mobile Phone Security and Trusted Application Development Guide"
2.https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
3.https://blog.csdn.net/xcxhzjl/article/details/127257463
4. https://github.com/OP-TEE/optee_os
5. https://schspa.tk/2020/01/10/persistent-object.html
6.https://blog.csdn.net/xy010902100449/article/details/124551205
Long press to follow Kernel Craftsman WeChat
Linux Kernel Black Technology | Technical Articles | Featured Tutorials