A resource protection method for multi-TA scenarios under OP-TEE

Abstract

The present invention discloses a resource protection method for a multi-TA scenario under OP‑TEE. The method of the present invention first identifies the ownership of resources, each resource is owned by one or more TAs, each TA can access one or more resources owned, and the identifier is the variable name of the TA to which it is owned; in a trusted execution environment, it is determined whether the resource can be accessed by the resource ID, and the variable name of the TA to which the resource belongs is found by the resource ID, and it is determined whether it is the same as the UUID of the TA currently accessing the resource. If the same, access is allowed, otherwise access is denied; after each resource access is completed, the resource is released through the resource ID. The method of the present invention ensures that each TA can obtain the necessary hardware resources during operation while maintaining strict isolation from each other. The method of the present invention can achieve an efficient and secure operating environment in a multi-TA scenario, providing a more comprehensive and flexible security guarantee for embedded devices.

Description

Technical Field

[0001] The present invention belongs to the field of embedded security technology, and in particular relates to a resource protection method for a multi-TA scenario under OP-TEE. Background Art

[0002] OP-TEE (Open Portable Trusted Execution Environment) is an open source trusted execution environment solution designed to provide a secure execution environment for embedded devices. It is built on ARM TrustZone technology, which provides a solid foundation for the secure isolation between TEE (Trusted Execution Environment) and REE (Rich Execution Environment). On the same processor, TEE is responsible for running applications that require extremely high security, while REE hosts the main operating system and regular applications on it. This isolation mechanism ensures that operations on TEE can proceed smoothly in an independent and secure environment, effectively resisting potential threats from REE.

[0003] Applications running on TEE are specifically called TAs (Trusted Applications). These TAs play a vital role, and they are specifically responsible for handling tasks involving sensitive data and performing key security operations. For example, in the fields of mobile payment, identity authentication, digital rights management (DRM), etc., TAs play an irreplaceable role. By running on TEE, TAs ensure that these sensitive operations are performed in a highly isolated and secure environment, thus providing strong protection for user data security and the safe operation of devices.

[0004] TA (Trusted Application) is generally issued by a certification authority (CA) and plays a core security role. However, due to the needs of business scenarios, third-party TAs may appear, such as DRM scenarios. In the scenario of multiple TAs (Multi-TA), we are faced with a crucial issue: how to ensure the secure isolation of hardware resources between multiple TAs. This is a complex and urgent challenge, because each TA may process sensitive data and perform critical operations, and any conflict or leakage in hardware resources may lead to serious security risks. Summary of the invention

[0005] The purpose of the present invention is to provide a resource protection method for a multi-TA scenario under OP-TEE, which can realize a secure operating environment in the Multi-TA scenario.

[0006] The method of the present invention is specifically as follows: Step 1. Identify the ownership of resources, including memory, keys, and device driver access rights; the specific method is: Step (1-1) declares the universally unique identifier (UUID) of each TA as a variable corresponding to the TA, and the variable name is UUID; Step (1-2) divides the memory into multiple memory blocks, identifies each memory block as belonging to one or more TAs, and each TA can access the one or more memory blocks to which it belongs; Identify the ownership of each of the one or more keys as one or more TAs, each TA being able to access the one or more keys; Identify the attribution of each device driver access right in the one or more device driver access rights as one or more TAs, and each TA can access the device driver corresponding to the attribution of the one or more device driver access rights; The identifier is the variable name of the TA to which it belongs; Steps (1-3) identify the ID of each memory block, key, and device driver access rights.

[0007] Step 2. In the trusted execution environment TEE, determine whether the resource can be accessed by the resource ID; specifically: Step (2-1) initializes the status of all resources to idle; Step (2-2) uses the resource ID to find the variable name of the TA to which the resource belongs, recorded as UUID1; Step (2-3) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID2; Step (2-4) If the resource currently accessed by the TA is in the occupied state, the access is denied, otherwise, step (2-5) is executed; Step (2-5) compares UUID1 and UUID2 to see if they are the same. If they are the same, the current TA is allowed to access and the status of the currently accessed resource is changed to occupied; if they are not the same, the current TA is denied access; Steps (2-6) operate resource access.

[0008] Step 3. After each resource access, release the resource using the resource ID; specifically: Step (3-1) uses the resource ID to find the variable name of the TA to which the resource belongs, recorded as UUID3; Step (3-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID4; Step (3-3) compares UUID3 and UUID4 to see if they are the same. If they are the same, the state of the currently accessed resource is changed to idle, that is, the resource is released; if they are not the same, the resource is refused to be released and remains occupied.

[0009] The method of the present invention ensures that each TA can obtain necessary hardware resources during operation while maintaining strict isolation between each other. The method of the present invention can achieve an efficient and secure operating environment in a multi-TA scenario, providing more comprehensive and flexible security protection for embedded devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A schematic diagram of resource access according to an embodiment of the method of the present invention. DETAILED DESCRIPTION

[0011] A resource protection method for multiple TA scenarios under OP-TEE is as follows: Step 1. Identify the ownership of resources, including memory, keys, and device driver access permissions; the specific method is: Step (1-1) declares the universal unique identifier UUID of each TA as a variable corresponding to the TA, and the variable name is UUID. Execute as follows:

[0012] / / CA1 company publishes TA's UUID CFG_CA1_UUID={ 0x8aaaf200, 0x2451, 0x11e3, { 0x1b, 0xe2, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x30}} / / CA2 company publishes TA's UUID CFG_CA2_UUID={ 0x8aaaf200, 0x2451, 0x11e3, { 0x1b, 0xe2, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x31}} By defining CFG_XXX_UUID, a specific UUID value is used to indicate each TA entity.

[0013] Step (1-2) divides the memory into multiple memory blocks, identifies each memory block as belonging to one or more TAs, and each TA can access the one or more memory blocks to which it belongs; such as executing as follows: # Memory ownership definition: # eg "ca1" is defined as belonging to CFG_CA1_UUID # eg "ca2" is defined as belonging to CFG_CA2_UUID CFG_OWNER_MEM_A="ca1,ca2" CFG_OWNER_MEM_B="ca2" The ownership of each of the one or more keys is identified as one or more TAs, and each TA can access the one or more keys to which it is owned; such as by performing the following: #Key ownership definition: CFG_OWNER_KEY_A="ca1" CFG_OWNER_KEY_B="ca2" The attribution of each device driver access right in the one or more device driver access rights is identified as one or more TAs, and each TA can access the device driver corresponding to the attribution of the one or more device driver access rights; for example, the following is performed: # Definition of device driver access rights: CFG_OWNER_MODULE_A="ca1" CFG_OWNER_MODULE_B="ca2" The ownership of the device driver is indicated by defining CFG_OWNER_MODULE_xxx, the ownership of the key ID is indicated by defining CFG_OWNER_KEY_xxx, and the ownership of the memory is indicated by defining CFG_OWNER_MEM_xxx. The identifier is the variable name of the TA to which it belongs.

[0014] Steps (1-3) identify the ID of each memory block, key, and device driver access permission. For example, perform the following:

[0015] struct Resource { uint32_t id; const char *vendor; enum ResourceStatus status; }; struct Resource resTable[] = { {RES_ID_MOD_A, CFG_OWNER_MODULE_A}, {RES_ID_MOD_B, CFG_OWNER_MODULE_B}, {RES_ID_KEY_A, CFG_OWNER_MODULE_A}, {RES_ID_KEY_B, CFG_OWNER_KEY_B}, {RES_ID_MEM_A, CFG_OWNER_MEM_A}, {RES_ID_MEM_B, CFG_OWNER_MEM_B}, }. Step 2. In the trusted execution environment TEE, determine whether the resource can be accessed by the resource ID; specifically: Step (2-1) initializes the status of all resources to idle; for example, perform the following: enum ResourceStatus { IDLE, OCCUPIED }; for (i = 0; i < MAX_RES_ID; i++) { resTable[i].status = IDLE; }. Step (2-2) searches for the variable name of the TA to which the resource belongs through the resource ID, which is recorded as UUID1_list; such as executing as follows: uint32_t id = CURRENT_RES_ID; If (memcmp(resTable[id].vendor,"ca1",3) == 0) UUID1_list[0] = CFG_CA1_UUID; If (memcmp(resTable[id].vendor+3,"ca2",3) == 0) UUID1_list[1] = CFG_CA2_UUID. Step (2-3) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID2. Execute as follows:

[0016] struct ts_session *user = NULL; user=ts_get_calling_session(); / / UUID2 is the user->ctx->uuid obtained later if(!user) user=ts_get_current_session(); Step (2-4) If the resource currently accessed by the TA is in the occupied state, the access is denied, otherwise, step (2-5) is executed. For example, the following is executed:

[0017] if (resTable[id].status==OCCUPIED) return ERROR_ACCESS_FAILED. Step (2-5) determines whether UUID1_list contains UUID2. If so, the current TA is allowed to access and the status of the currently accessed resource is changed to occupied. If not, the current TA is denied access. Execute as follows:

[0018] If (memcmp(&UUID1_list[0],UUID2,sizeof(UUID2)) == 0 || memcmp(&UUID1_list[1],UUID2,sizeof(UUID2)) == 0) { resTable[id].status=OCCUPIED; return OK; } return ERROR_ACCESS_FAILED. Steps (2-6) operate resource access.

[0019] Step 3. After each resource access, release the resource using the resource ID; specifically: Step (3-1) searches for the variable name of the TA to which the resource belongs through the resource ID, recorded as UUID3_list; such as executing as follows: uint32_t id = CURRENT_RES_ID; If (memcmp(resTable[id].vendor,"ca1",3) == 0) UUID3_list[0] = CFG_CA1_UUID; If (memcmp(resTable[id].vendor+3,"ca2",3) == 0) UUID3_list[1] = CFG_CA2_UUID. Step (3-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID4; if performed as follows: struct ts_session *user = NULL; user=ts_get_calling_session(); / / UUID4 is the user->ctx->uuid obtained later if(!user) user=ts_get_current_session(). Step (3-3) determines whether UUID3 contains UUID4. If so, the state of the currently accessed resource is changed to idle, that is, the resource is released; if not, the resource is refused to be released and remains in the occupied state. Execute as follows.

[0020] If (memcmp(&UUID3_list[0],UUID4,sizeof(UUID4)) == 0 || memcmp(&UUID3_list[1],UUID4,sizeof(UUID4)) == 0) { resTable[id].status=IDLE; return OK; } return ERROR_ACCESS_FAILED. Example scenario: The following example illustrates the resource protection method using a scenario where multiple TAs simultaneously access a secure resource. Figure 1 .

[0021] Prerequisite: The access rights of device driver A belong to both TA1 and TA2.

[0022] Step (1) TA1 (provided by CA1) accesses device driver A; Step (1-1) find the variable name of the TA to which the device driver A belongs, recorded as UUID1; Step (1-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID2; Step (1-3) determines the current resource status. Since the resource status is idle, the execution continues; Step (1-4) determines that UUID1 contains UUID2, so the device driver A state is changed to occupied and execution continues; Step (2) Device driver A operates TA1 to access this resource; Step (3) TA2 (provided by CA2) accesses device driver A; Step (3-1) find the variable name of the TA to which the device driver A belongs, recorded as UUID3; Step (3-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID4; Step (3-3) determines the current resource status. Since the resource status is occupied, it returns access denied. Step (4) Device driver A releases resources; Step (4-1) find the variable name of the TA to which the device driver A belongs, recorded as UUID5; Step (4-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID6; Step (4-3) determines that UUID5 contains UUID6, so the device driver A state is changed to idle and the execution is returned successful.

Claims

1. A resource protection method for a multi-TA scenario under OP-TEE, characterized by: Step (1) identifies the ownership of resources, where the resources include memory, keys, and device driver access rights; the specific method is: Step (1-1) declares the universal unique identifier UUID of each TA as a variable corresponding to the TA, and the variable name is UUID; Step (1-2) divides the memory into a plurality of memory blocks, identifies the ownership of each memory block as one or more TAs; identifies the ownership of each key in the one or more keys as one or more TAs; identifies the ownership of each device driver access right in the one or more device driver access rights as one or more TAs; The identifier is the variable name of the TA to which it belongs; Steps (1-3) identify the ID of each memory block, key, and device driver access rights; Step (2) In the trusted execution environment TEE, determine whether the resource can be accessed by using the resource ID; specifically: Step (2-1) initializes the status of all resources to idle; Step (2-2) uses the resource ID to find the variable name of the TA to which the resource belongs, recorded as UUID1; Step (2-3) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID2; Step (2-4) If the resource currently accessed by the TA is in the occupied state, the access is denied, otherwise, step (2-5) is executed; Step (2-5) compares UUID1 and UUID2 to see if they are the same. If they are the same, the current TA is allowed to access and the status of the currently accessed resource is changed to occupied; if they are not the same, the current TA is denied access; Steps (2-6) operate resource access; Step (3) After each resource access is completed, the resource is released through the resource ID; specifically: Step (3-1) uses the resource ID to find the variable name of the TA to which the resource belongs, recorded as UUID3; Step (3-2) obtains the UUID of the TA currently accessing the resource through the system interface provided by TEE, recorded as UUID4; Step (3-3) compares UUID3 and UUID4 to see if they are the same. If they are the same, the state of the currently accessed resource is changed to idle, that is, the resource is released; if they are not the same, the resource is refused to be released and remains occupied.

2. A resource protection method for a multi-TA scenario under OP-TEE as claimed in claim 1, characterized in that: In step (1-2), each TA can access one or more memory blocks to which it is assigned, each TA can access one or more keys to which it is assigned, and each TA can access device drivers corresponding to one or more device driver access permissions to which it is assigned.

Images