Apparatus and method for protecting shared objects

Abstract

An apparatus is provided for protecting the privacy of shared objects and helping to prevent the loss of these software assets by loading the shared objects into the user memory of a trusted execution environment. The shared objects have encrypted segments and metadata. A decryption request is sent to the trusted execution environment, and the encrypted segments are decrypted based on the metadata and a predetermined platform key to produce a decrypted segment. The decrypted segment is written to the shared object. A request to lock the shared object is sent, locking or setting the memory occupied by the shared object to execution-only. The locking of the memory region occupied by the decrypted shared object maps the memory region to be unreadable and unwritable by all applications executing at a first privilege level and by the operating system kernel executing at a second privilege level.

Description

Technical Field

[0001] The various aspects of the disclosed embodiments generally relate to apparatus for computer security, and more specifically, to protecting the privacy of shared software objects. Background Technology

[0002] When developing computer applications, it is common practice to combine third-party libraries, software development kits (SDKs), or other third-party shared objects to facilitate efficient application development. SDKs or shared objects can incorporate new technologies that provide a competitive advantage to both shared object developers and third-party application developers. For example, a shared object can provide a new graphics processing technology that can deliver a superior user experience.

[0003] When shared objects are distributed, it is relatively easy to inspect and reverse engineer the computer code contained within them, making any new technology susceptible to abuse. Traditional shared objects typically include encryption measures to protect their integrity and detect unauthorized modifications. However, there are no reliable means to protect the confidentiality of a shared object's contents throughout its entire lifecycle.

[0004] Therefore, there is a need for improved methods and apparatuses to protect the privacy of software assets distributed as shared objects, while also supporting the execution of these shared objects within rich execution environments. Thus, it is desirable to provide methods and apparatuses that address at least some of the aforementioned problems. Summary of the Invention

[0005] The purpose of the disclosed embodiments is to protect the privacy of software assets distributed as shared objects, while still supporting the execution of these shared objects within a rich execution environment. This and other objectives are achieved through the subject matter claimed in the independent claims. Further advantageous modifications are provided in the dependent claims.

[0006] According to the first aspect, the above and other objects and advantages are achieved by an apparatus. In one embodiment, the apparatus includes a processor coupled to a memory. The processor and the memory are used to provide a rich execution environment and a trusted execution environment. Memory and processes in the trusted execution environment are protected from access or modification by applications executing within the rich execution environment. The processor and memory are also used to provide a first computing environment for execution at a first privilege level and a second computing environment for execution at a second privilege level within the rich execution environment. In one embodiment, the first privilege level is more restrictive than the second privilege level. The processor is also used to load shared objects into user memory within the rich execution environment. In one embodiment, the shared objects include encrypted segments and metadata. The processor is also used to send a decryption request from the rich execution environment to the trusted execution environment, wherein the decryption request includes the metadata and the encrypted segment. The processor is also used to decrypt the encrypted segment within the trusted execution environment to produce a decrypted segment. In one embodiment, the decryption is based on the metadata and a predetermined platform key. The processor is used to receive a decryption response within the rich execution environment. The decryption response includes the decrypted segment. The processor is further configured to write the decrypted segment to the shared object and send a request to lock the shared object from the first computing environment to the second computing environment. The processor is configured to, when executing at the second privilege level, set the memory occupied by the shared object to execute-only. Locking the memory region occupied by the decrypted shared object or setting the memory region occupied by the decrypted shared object to execute-only maps the memory region to be unreadable by all applications executing at the first privilege level, and also marks the memory region as unreadable, even by the operating system kernel that may be executing at the second privilege level.

[0007] In a first possible implementation of the device, the metadata includes an encrypted asset key. The encrypted asset key is an asset key encrypted according to the predetermined platform key. The processor is further configured to, within the trusted execution environment, decrypt the encrypted asset key according to the predetermined platform key, and decrypt the encrypted segment according to the decrypted asset key. This supports the use of more efficient symmetric cryptography to decrypt the encrypted segment while still obtaining the security advantages of computationally intensive asymmetric-key cryptography.

[0008] In one possible implementation of the device, the metadata includes a plurality of encrypted key data, wherein the plurality of encrypted key data includes the asset key encrypted according to a different platform key from a plurality of platform keys. The processor is further configured to select the encrypted key data from the plurality of encrypted key data according to the predetermined platform key. This can support the decryption and execution of a single encrypted shared object on multiple computing devices with different platform keys.

[0009] In one possible implementation of the device, the decryption request is sent by an agent executing within the trusted execution environment. The processor is also configured to verify the integrity of the agent within the trusted execution environment before decrypting the encrypted segment. Verifying the agent ensures that the decryption request is sent by an approved agent and that the agent is not infected or otherwise corrupted, thus providing additional security.

[0010] In one possible implementation of the device, the predetermined platform key is the public portion of an asymmetric key pair. Asymmetric key cryptography supports public key infrastructure (PKI) and improves resistance to attacks.

[0011] In one possible implementation of the device, the asset key is a symmetric key. Since the encrypted segments can be very large, using symmetric key cryptography reduces processing compared to asymmetric cryptography.

[0012] In one possible implementation of the device, the rich execution environment includes a third computing environment for execution at a third privilege level. The second privilege level is more restrictive than the third privilege level. The processor, when executing at the third privilege level, sets the memory occupied by the shared object to execute-only. Using the third privilege level provides stricter control over software executing at that level and reduces the software size, thereby improving security.

[0013] In one possible implementation of the device, the first computing environment includes a user application, the second computing environment includes an operating system, and the third computing environment includes a hypervisor. The hypervisor is typically a smaller, more comprehensively tested application. Applying locks within the hypervisor can improve security and reduce available attack vectors.

[0014] In one possible implementation of the device, the shared object includes a constructor routine that, when executed by the processor, causes the processor to send the decryption request. Including the constructor routine provides additional flexibility and the opportunity to complement the functionality of the SOP agent.

[0015] In one possible implementation of the device, the trusted execution environment includes a trusted application, and the rich execution environment includes a proxy. The trusted application is configured to: receive the decryption request from the proxy; verify the integrity of the proxy; and, when the integrity is valid, decrypt the encrypted segment to generate the decrypted segment, and return the decrypted segment to the proxy. Verifying the proxy before decryption provides an opportunity to detect if the proxy has been corrupted before sending the decryption proxy to an application that may be malicious.

[0016] In one possible implementation of the device, the encrypted segment occupies a first memory region, and writing the decrypted segment to the shared object includes one or more of the following operations: writing the decrypted segment to the first memory region; writing the decrypted segment to a second memory region; and merging the second memory region into the shared object. For example, writing the decrypted segment to the second memory region may be advantageous when locking the second memory region is easier or more efficient than locking the first memory region. The decrypted segment may be larger than the encrypted segment, thus requiring additional memory, or in some devices, allocating new space may be more efficient than overwriting already used space.

[0017] In one possible implementation of the device, the device includes a mobile communication device. Seamless user experiences across many applications rely on integrating numerous shared objects within a single device. In modern mobile computing devices, protecting these shared objects has become increasingly important.

[0018] According to the second aspect, the above and other objectives and advantages are achieved through a method. In one embodiment, the method includes: loading a shared object into user memory within a rich execution environment, wherein the shared object includes an encrypted segment, metadata, and a constructor routine; sending a decryption request from the rich execution environment to a trusted execution environment, wherein the decryption request includes the metadata and the encrypted segment; decrypting the encrypted segment within the trusted execution environment to produce an unencrypted segment, wherein the decryption is based on the metadata and a predetermined platform key; receiving a decryption response from the trusted execution environment within the rich execution environment, wherein the decryption response includes a decrypted segment; writing the decrypted segment into the shared object; setting the memory occupied by the shared object to execute-only when executing at a second privilege level; accessing the shared object from a user application at a first privilege level, wherein the first privilege level is more restrictive than the second privilege level. Locking the memory occupied by the decrypted shared object or setting the memory occupied by the decrypted shared object to execute-only maps the memory region to be unreadable by all applications executing at the first privilege level, and also marks the memory region as unreadable, even by the operating system kernel that may be executing at the second privilege level.

[0019] In one possible implementation of the method, the encrypted segment is encrypted based on an asset key, and the metadata includes an encrypted asset key, which is the asset key encrypted according to the predetermined platform key. The method includes: decrypting the encrypted asset key according to the predetermined platform key within the trusted execution environment; and decrypting the encrypted segment according to the asset key within the trusted execution environment. This supports the use of more efficient symmetric cryptography to decrypt the encrypted segment while still obtaining the security advantages of computationally intensive asymmetric-key cryptography.

[0020] According to the third aspect, the above and other objects and advantages are obtained through a non-transitory computer-readable medium. In one embodiment, the non-transitory computer-readable medium stores program instructions that, when executed by a processor, cause the processor to perform the method according to any possible implementation.

[0021] These and other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein in conjunction with the accompanying drawings. However, it should be understood that such description and drawings are for illustrative purposes only and should not be construed as limiting the disclosed invention; any limitation on the invention should be referenced to the appended claims. Additional aspects and advantages of the invention will be set forth in the following description, and some aspects and advantages will be apparent from the description or may be learned by practicing the invention. Furthermore, aspects and advantages of the invention may be realized and obtained by means or combinations particularly pointed out in the appended claims. Attached Figure Description

[0022] In the following detailed description of the invention, the invention will be explained in detail with reference to exemplary embodiments shown in the accompanying drawings, wherein:

[0023] Figure 1 Block diagrams of exemplary computing devices provided in various aspects of the disclosed embodiments are shown;

[0024] Figure 2 A block diagram of an exemplary computing device provided by various aspects of the disclosed embodiments is shown, the exemplary computing device being used to provide a rich execution environment and a trusted execution environment;

[0025] Figure 3 A visual diagram illustrating the shared object lifecycle provided by various aspects of the disclosed embodiments is shown;

[0026] Figure 4 Sequence diagrams are shown illustrating aspects of the disclosed embodiments, which describe an exemplary construction process for generating protected shared objects;

[0027] Figure 5 A software flowchart is shown, illustrating an exemplary method for protecting shared objects provided by various aspects of the disclosed embodiments. Detailed Implementation

[0028] Figure 1 A schematic block diagram of an exemplary apparatus 100 provided by aspects of the disclosed embodiments is shown. Aspects of the disclosed embodiments are designed to prevent the theft of software assets distributed as shared objects to third-party developers. Computing apparatus 100 is suitable for protecting the privacy of shared objects such as software libraries, software development kits (SDKs), or other types of redistributable software assets. Assets bundled within an SDK are vulnerable to theft when proprietary technology is incorporated into the SDK and distributed to third-party application developers. The embodiments disclosed herein provide methods and apparatus for protecting the privacy of shared objects and helping to prevent the loss of these software assets.

[0029] like Figure 1 As shown, device 100 includes processor 102 coupled to memory 184. Although Figure 1 Only one memory 184 is shown, but it should be understood that memory 184 may include one or more memory blocks or modules. Processor 102 and memory 184 are used to provide a rich execution environment 104 and a trusted execution environment 106. As further discussed below, the trusted execution environment 106 includes secure memory 182 and a secure portion of processor 102, while the rich execution environment 104 includes separate memory 180 and an insecure portion of processor 102. Figure 1 In the example, the memory 184 and process 126 executing within the trusted execution environment 106 are protected from being accessed or modified by applications executing within the rich execution environment 104.

[0030] The processor 102 and memory 184 are also configured to provide, within the rich execution environment 104, a first computing environment 108 for execution at a first privilege level and a second computing environment 158 ​​for execution at a second privilege level. In one embodiment, the first privilege level is more restrictive than the second privilege level.

[0031] Privilege levels are used to prevent a process (e.g., application 110 executing in user memory 108) from unintentionally or maliciously accessing or modifying computing resources belonging to different processes (e.g., a second application 176 or system processes 128, 130). Processor 102 is used to prevent a process executing at one privilege level from viewing or accessing computing resources associated with different processes executing at the same privilege level or at lower or higher privilege levels. A higher privilege level is one that allows access to a smaller set of computing resources compared to a lower privilege level. Conversely, a lower or higher privilege level is one that allows access to a larger set of computing resources compared to a lower privilege level.

[0032] For example, processors based on the Acorn RISK machine ARMv8-A architecture (referred to herein as ARM architecture) provide four privilege levels, which can also be called exception levels. Exception level 0 (EL0), also known as unprivileged execution, is the lowest privilege level, with the fewest privileges and the highest restrictions, while exception level 3 (EL3) is the highest privilege level, with the highest privileges and the lowest restrictions. In ARM-based computing devices, exception level 1 (EL1) is often used for the execution of operating system processes, and exception level 2 (EL2) can be used to provide hypervisor support. Processes executing at the lowest privilege level are allowed to access and modify computing resources associated with their own process, but are not allowed to access or modify computing resources associated with any other processes executing on computing device 100.

[0033] User-space applications (such as application 110 executing in user memory 108) typically execute at the lowest privilege level EL0, which is also the most restrictive privilege level. In contrast, processes executing at the next higher privilege level (such as EL1 in the ARM example presented above) are allowed to access and modify the computational resources of processes executing at the lowest privilege level EL0, but cannot access, view, or modify the computational resources of any processes executing at the same (EL1) or higher privilege levels (such as EL2 or EL3). Therefore, the lowest privilege level EL0 is considered more restrictive than the privilege level EL1.

[0034] Importantly, within computing device 100, only code executing at one of the higher privilege levels is permitted to access memory management components used to lock or mark the memory region 190 occupied by shared object 116 as execute-only. Code executing in user space 108 cannot access these memory management components. Therefore, a program executing in user space at a higher privilege level cannot remove locks or modify any read-only or execute-only designations imposed on the memory region by the higher-privileged program.

[0035] As used herein, the terms “set to execute-only,” “apply execute-only designation,” or “mark as execute-only” generally refer to configuring a portion of memory using the memory management capabilities of a computing device in such a way that the processor is allowed to execute instructions stored in a specified memory region, but the processor is prevented from reading or writing to the memory region that has been set to execute-only. The terms “lock,” “lock shared object,” or “lock memory region” as used herein refer to setting a subject memory region to execute-only, such that any data stored in the locked memory region cannot be read or modified.

[0036] exist Figure 1 In the illustrated embodiment, when application 110, executing within user space 108, identifies a need for shared object 116, it makes a call 150 to employ the service of loader 112, which loads (154) the required shared object 116 into user memory 108. The loading (154) of shared object 116 may occur during the loading of application 110, or may be otherwise triggered and subsequently loaded during the execution of application 110.

[0037] exist Figure 1 In the example, processor 102 is used to load (154) shared object 116 into user memory 108 within rich execution environment 104. Shared object 116 can be loaded (154) from a non-volatile portion 114 of memory into user memory 108 within rich execution environment memory 180. When data is stored in non-volatile memory 114, the data can be referred to as "hibernating". Shared object 116 can be protected while hibernating by encrypting portions of the shared object, for example by encrypting the portion of shared object 116 containing proprietary information or software assets.

[0038] In one embodiment, the shared object 116 includes an encrypted segment 122 and metadata 120. The protected software assets are encrypted before the shared object 116 is distributed. These protected software assets may include information such as executable code and supporting data, as well as any other necessary information, and may be referred to herein as a “segment” or more specifically as a “text segment.” The metadata 120 includes information used to enable the decryption of the encrypted segment 122 or otherwise reconstruct the shared object 116 in preparation for execution. For example, the metadata 120 may include a symmetric cryptography, a symmetric key encrypted using a platform key, and an initialization vector for an algorithm identifier.

[0039] The loaded shared object 116 employs (156) a shared object protection (SOP) agent 124 to handle the decryption and preparation of the shared object 116 for execution within the rich execution environment 104. The SOP agent 124 coordinates the decryption, locking, and preparation of the shared object 116 for execution.

[0040] Processor 102 is also configured to send a decryption request 158 ​​from rich execution environment 104 to trusted execution environment 106, wherein the decryption request includes metadata 120 and encrypted segments 122. In the illustrated embodiment, decryption request 158 ​​can be sent from SOP agent 124 across the security boundary between rich execution environment 104 and trusted execution environment 106 via an appropriate secure communication method to SOP decryption application 126. Decryption request 158 ​​is received by a trusted application (referred to as SOP decryption application 126) executing within trusted execution environment 106.

[0041] Processor 102 is also configured to decrypt encrypted segment 122 within Trusted Execution Environment 106 to produce decrypted segment 175. In one embodiment, decryption is based on metadata 120 and a predetermined platform key 174. Platform key 174 may be an asymmetric key, a symmetric key, or other type of encryption key material used to decrypt encrypted information embedded in metadata 120. In some embodiments, platform key 174 may be securely provided into Trusted Execution Environment 106 during manufacturing, post-manufacturing, or other appropriately secure provisioning processes, which securely provide platform key 174 for securely installing within Trusted Execution Environment 106.

[0042] In an exemplary embodiment, metadata 120 includes an encrypted copy of a decryption key that can be used to decrypt encrypted segment 122. The encrypted copy is decrypted according to platform key 174 to obtain a decryption key, and then encrypted segment 122 is decrypted according to the decryption key obtained from metadata 120.

[0043] Processor 102 is configured to receive decryption response 162 within rich execution environment 104, wherein decryption response 162 includes decryption segment 175. Processor 102 is also configured to write decryption segment 175 to shared object 116. Decryption segment 175 may be written back to the same region of memory 108 initially occupied by encrypted segment 122. Alternatively, in some embodiments, it may be desirable to write decryption segment 175 to different portions of memory 108 and associate different portions of memory with shared object 116.

[0044] exist Figure 1 In the exemplary embodiment shown, processor 102 is configured to send a request 168 from first computing environment 108 to second computing environment 178 to lock shared object 116, and, when executing at a second privilege level, to set memory 190 occupied by shared object 116 to execute-only. Memory region 190 includes the memory region occupied by shared object 116. Therefore, by locking memory region 190 or marking memory region 190 as execute-only, applications executing at the more restrictive first privilege level can be prevented from reading or modifying shared object 116.

[0045] For example, the first computing environment could be a user space executing at a relatively high privilege level (e.g., the EL0 privilege level described above), which prevents applications 110 and 176 executing within the first computing environment 108 from accessing computing resources not allocated to them, and importantly, from accessing the memory management or memory configuration capabilities of the computing device 100. Preventing user applications 110 and 176 executing at the first privilege level from accessing memory management or configuration capabilities can prevent these user applications 110 and 176 from removing locks applied to the memory 190 occupied by the shared object 116 or from performing only specified actions.

[0046] In some embodiments, it may not be desirable to mark the entire shared object 116 as execution-only by locking the entire memory region 190. Critical assets can be concentrated in the decryption segment 175. Therefore, locking only the memory region occupied by the decryption segment 175 can provide suitable protection for the proprietary technology.

[0047] exist Figure 1 In the exemplary embodiment shown, a request 158 ​​to lock memory region 190 may be received by an SOP lock routine 128, which executes at a privilege level less restrictive than the privilege level of application 110 or shared object 116. For example, SOP lock routine 128 may execute at the same privilege level as the operating system (e.g., the EL1 privilege level provided by an ARM processor as described above), while user space program 108 executes at a higher privilege level (e.g., the EL0 privilege level provided by an ARM processor). Importantly, applications or processes executing at the second privilege level are allowed to execute, while applications and processes executing at the first privilege level are not allowed to perform memory management operations (e.g., setting or resetting memory regions to execution-only). The functionality of SOP lock routine 128 may be incorporated into the operating system or other executing applications executing at the second privilege level, or it may be provided by a separate routine or process executing at the second privilege level.

[0048] Setting the memory region 180 occupied by the shared object 116 to execute-only or locking it can prevent other potentially malicious applications 176 running in user space 108 or at the first privilege level from reading, copying, or modifying the shared object 116, thereby effectively protecting the privacy of the shared object.

[0049] In one exemplary embodiment, metadata 120 includes an encrypted asset key. The encrypted asset key may include an asset key encrypted according to or with a predetermined platform key 174. The processor is configured to decrypt the asset key according to the predetermined platform key 174 and decrypt the encrypted segment 122 according to the decrypted asset key within a trusted execution environment 106.

[0050] In one embodiment, metadata 120 includes a plurality of encrypted key data, wherein the plurality of encrypted key data includes an asset key encrypted according to a different platform key among a plurality of platform keys. Processor 102 is configured to select encrypted key data from the plurality of encrypted key data corresponding to or according to a predetermined platform key 174.

[0051] This allows different manufacturers and different device models to use different platform keys 174. Including multiple encryption keys supports the single construction of a shared object 116 on multiple different devices with different platform keys. During loading, encrypted key data corresponding to the available platform key is selected, allowing individual encrypted segments to be decrypted on various different devices.

[0052] In one embodiment, decryption request 158 ​​is sent by SOP agent 124, which executes within rich execution environment 104, to SOP decryption routine 126, which executes within trusted execution environment 106. Processor 102 is used within trusted execution environment 106 to verify (160) the integrity of SOP agent 124 before decrypting encrypted segment 122. In the event of SOP agent 124 verification failure, for example, if SOP agent 124 has been corrupted by a virus, SOP decryption routine 126 will refuse to decrypt encrypted segment 122.

[0053] To enhance security and facilitate the provision of computing device 100, in some embodiments, it is desirable to use asymmetric cryptography for the platform key. However, the computational cost of asymmetric cryptography is higher than that of symmetric cryptography. By using a symmetric or secret key as the asset key, performance can be improved while maintaining the security benefits of the asymmetric platform key 174. The platform key 174 is used to decrypt a relatively small asset key, and the asset key is used to decrypt potentially larger encrypted segments 122.

[0054] In some embodiments, it is desirable that the predetermined platform key 174 is the common portion of an asymmetric key pair. When the platform key 174 in computing device 100 is populated from an external source, it may be desirable to keep the private key portion of the asymmetric platform key pair within a well-defined security boundary, such as within hardware devices at a physically secure manufacturing facility, and to populate numerous devices with the corresponding common portion of the platform key pair 174. For example, all telephones of a particular model or distributed by a particular operator may be populated using the same predetermined platform key.

[0055] In one embodiment, the rich execution environment includes a third computing environment 192 for execution at a third privilege level. The second privilege level is more restrictive than the third privilege level. The computing device 100 is configured to allow applications executing at the third privilege level to modify memory settings, such as execute-only, read-only, or read-write memory access permissions, while preventing applications executing at the first or second privilege level from modifying memory settings. The processor 102 is configured to set the memory 190 occupied by the shared object 116 to execute-only when executing at the third privilege level. For example, the third privilege level may be a privilege level such as the EL2 privilege level provided in an ARM architecture computing device.

[0056] In embodiments including a third privilege level, security can be enhanced by configuring processor 102 to send a request 170 for locking memory region 190 from SOP lock routine 128 to SOP visor routine 130, wherein SOP lock routine 128 executes at a second privilege level within a second computing environment 178, and SOP visor routine 130 executes at a third privilege level within a third computing environment 192. SOP visor routine 130 can then set memory region 190 to execute-only, thereby preventing the operating system executing at a second privilege level, or user applications executing at a first privilege level, from reading or writing to the locked memory region 190.

[0057] In some embodiments, the first computing environment 108 includes user applications, the second computing environment 178 includes an operating system, and the third computing environment 192 includes a hypervisor. Modern operating systems are increasing in size and functionality, thus requiring regular maintenance and updates. Regular updates provide attackers with opportunities to access the system. Furthermore, large and feature-rich software programs (such as modern operating systems) are more difficult to secure than smaller, more feature-limited software packages (such as hypervisors). Hypervisors offer far fewer features than operating systems, are therefore much smaller, require fewer updates, and are inherently more secure. The security of the entire computing device 100 can be improved by restricting memory management operations (such as locking or unlocking memory regions 190 occupied by shared object 116) to applications or processes executing at the third privilege level.

[0058] In some embodiments, the shared object 116 includes a constructor routine 118. When executed by the processor 102, the constructor routine 118 causes the processor 102 to send a decryption request 158. The decryption request 158 ​​may be triggered directly by the constructor routine 118, or the constructor routine 118 may initiate the initialization process of the shared object 116 and send the decryption request 158 ​​as part of that initialization process. The constructor routine 118 provides a convenient way to incorporate flexibility into the decryption process.

[0059] For example, constructor routine 118 may perform certain preparatory steps before sending request 156 to SOP agent 124, and may also perform additional steps after SOP agent 124 has completed its work, thereby adapting the new shared object to be compatible with existing or currently deployed SOP agent 124. Constructor routine 118 may include information such as metadata 120 in the decryption request 156 used to initiate SOP agent 124.

[0060] In one embodiment, application 110 invokes a dynamic linker to load shared object 116 into memory. The dynamic linker may invoke constructor routine 118, and constructor routine 118 may issue a request 156 to SOP agent 124 to decrypt encrypted segment 122. Alternatively, constructor routine 118 may be invoked or triggered by application 110 as an initialization step performed before application 110 uses any methods or features in decrypted segment 174. SOP agent 124 issues a request 158 ​​to trusted execution environment 106, providing the starting address and length of encrypted segment 122 (which may be a text segment) and metadata 120 to SOP decryption routine 126, which executes within trusted execution environment 106.

[0061] The SOP decryption routine 126, executed within the trusted execution environment 106, verifies the device's security level. Verifying the security level of the SOP decryption routine 126 ensures that decrypted assets are only exposed to the SOP agent 124 when the device's security is at an appropriate level. For example, in Android... TM Within the device, the trusted execution environment should be able to read trusted root fields, such as the operating system version, the verification startup status, and the versions of security patches. Verifying the device's security level may include determining whether the trusted root fields are in a satisfactory state.

[0062] In one embodiment, once the device security level is verified, the trusted execution environment 106 decrypts the asset key from the metadata 120 and uses the asset key, along with the starting address and length, to decrypt the encrypted segment 122. Alternatively, advantageously, any suitable method for decrypting the encrypted segment 122 can be employed.

[0063] In one exemplary embodiment, the trusted execution environment 106 includes a trusted application 126, while the rich execution environment 104 includes an SOP agent 124. The trusted application 126 receives a decryption request 158 ​​from the SOP agent 124 and verifies (160) the integrity of the agent 124. When the integrity is valid, the encrypted segment 122 is decrypted to produce a decrypted segment 175. The decrypted segment 175 is returned (162) to the SOP agent 124. The verification of the SOP agent 124 by the trusted application 126 ensures that the decryption request originates from a known source and that the SOP agent 124 has not been modified or otherwise corrupted by an attacker.

[0064] In one exemplary embodiment, the encrypted segment 122 occupies a first memory region. Writing the decrypted segment 175 to the shared object 116 includes one or more of the following operations: writing the decrypted segment 175 back to the first memory region initially occupied by the encrypted segment 122; writing the decrypted segment 175 to a second memory region; and merging the second memory information into the shared object 116.

[0065] Decrypting encrypted segment 122 can produce decrypted segment 175 with a different size than encrypted segment 122. It is advantageous to allocate a second memory region of the required size and write the decrypted segment into that second memory region, rather than reusing the first memory region for decrypted segment 175. Alternatively, it may be desirable to write a portion of decrypted segment 175 into the first memory region and another portion into the second memory region.

[0066] As will be further discussed below, advantageously, the exemplary computing device 100 can be used in various computing devices, such as mobile communication devices, mobile phones, tablet computers, phablets, automobiles, set-top boxes, etc.

[0067] Figure 2A block diagram of an exemplary computing device 200 provided by various aspects of the present invention is shown, which is used to provide a rich execution environment (REE) 250 and a trusted execution environment (TEE) 252. The computing device 200 is adapted to [the above references]. Figure 1 The computing device 200 described herein is used in computing device 100. Computing device 200 can be incorporated into various types of computing devices, such as mobile phones, phablets, tablets, laptops, set-top boxes, televisions, automobiles, etc., and advantageously, can be used to implement the apparatus and methods disclosed herein to protect shared objects deployed within computing device 200.

[0068] REE 250 is designed to support a wide range of functions and features to support a broad range of applications and provide an enhanced user experience. However, this enhanced feature set and rich functionality available within REE 250 is inherently less secure than the smaller and more targeted functionality offered by TEE 252, and cannot securely perform cryptographic operations without risking the loss of confidentiality, authenticity, or integrity of encryption keys and algorithms. An example of a rich execution environment is the environment provided by an operating system (OS), such as Google. TM Developed Android OS, Apple TM Developed iOS operating system, MICROSOFT TM The developed Windows operating system and the widely distributed Linux OS TM .

[0069] exist Figure 2 In the example, computing device 200 includes a processor 210 coupled to memory 212. A first portion 202 of the processor and a first portion 204 of the memory are used to support TEE 252. A second portion 206 of the processor and a second portion 208 of the memory are used to support REE 250.

[0070] Processor 210 may be a single processing device or may include multiple processing devices, including dedicated devices such as digital signal processing (DSP) devices, microprocessors, dedicated processing devices, parallel processing cores, or general-purpose computer processors. Processor 210 is used to read non-transitory program instructions from memory 212 and execute any methods and processes described herein. Processor 210 may also include a central processing unit (CPU) that works in conjunction with a graphics processing unit (GPU), which may include a DSP or other dedicated graphics processing hardware.

[0071] Memory 212 can be a combination of various types of volatile and non-volatile computer memory, such as read-only memory (ROM), random access memory (RAM), disk or optical disk, flash memory, or other suitable types of computer memory. The secure portion 204 of the memory may include non-volatile or one-time programmable memory for protecting confidential data such as platform key 174 or other private or confidential encrypted material.

[0072] TEE 252 is used to ensure the confidentiality and integrity of data and computer program instructions stored in TEE memory 204, and to protect the confidentiality and integrity of computer programs and associated data executed within the secure portion 202 of the processor. TEE 252, also known as a secure computing environment (SCE), can be implemented using any technology suitable for providing REE 250 and TEE 252 within computing device 200.

[0073] To maintain a secure boundary between TEE 252 and REE 250, only the REE portion 206 of the processor is allowed to access the REE portion 208 of the memory (218). Since TEE 252 is a secure environment, the TEE portion 202 of the processor is allowed to access the secure portion 204 of the memory (214), and access to the REE portion 208 of the memory (216) is also allowed.

[0074] Figure 3 A block diagram illustrating an exemplary lifecycle 300 of a shared object provided in various aspects of the disclosed embodiments is shown, the shared object being protected using shared object protection (SOP). When in accordance with Figure 3When adjustments are made as shown, SOPs can prevent the loss of software assets distributed as shared objects to third-party developers.

[0075] The protected shared object 316 is created via a build process 302 and deployed (330) in non-volatile memory 320 within the computing device. When an application needs to use the deployed shared object 316, a loading process 304 prepares the shared object 326 for execution. Then, after loading the shared object 326, memory protection 306 is applied to prevent unauthorized read access to the shared object 326.

[0076] When a software company develops a shared object 312 containing valuable software assets for sale and distribution to third-party software developers or companies, a build process 302 is used. To protect the software assets, the build process 302 prepares a Standard Operating Procedure (SOP) and incorporates it into the shared object 316 for sale and distribution. Computer program instructions or program code 308 are developed and compiled and linked (310) (code 308) to create a software library module lib.so 312. By convention, software libraries are often named with the file extension ".so," indicating that they contain shared objects. As discussed further below, portions of lib.so 312 are encrypted and packaged (314) to create a protected shared object 316. The packaged shared object 316 includes the encrypted form of the shared object 312 along with metadata and, where necessary, constructor routines. The packaged shared object 316 is suitable for use as a reference above. Figure 1 The described shared object is 116.

[0077] The packaged shared object 316 is then deployed to non-volatile memory 320 in a computing device (e.g., a mobile communication device or other desired type of computing device), where the packaged shared object can be called or used as a shared object 318 by an application 322 executing on the computing device.

[0078] When application 322 needs to access functionality provided by protected shared object 318, it invokes SOP agent 324 to coordinate the loading, decryption, and protection of shared object 326 in runtime memory. When loading 304 completes, a decrypted copy of shared object 326 is loaded into runtime memory, and this memory is locked to prevent the loss of contained software assets.

[0079] While the shared object 326 remains loaded (332), memory is protected (306) by applying the SOP lock feature described above. The SOP lock 328 applied to the shared object 326 (334) may be executed only if it is configured at an elevated privilege level, such as the EL2 privilege level supported by the ARM processor as described above.

[0080] Figure 4 Sequence diagrams are shown illustrating aspects of the disclosed embodiments, illustrating an exemplary build process 400 for generating protected shared objects. Inspired by this, the build process 400 can be viewed as having three phases: an initial configuration phase 408, a code generation phase 410, and an encryption phase 414. Advantageously, the exemplary build process 400 can be used to generate shared objects containing shared object protection to prevent theft or loss of software assets when distributed to third-party software developers.

[0081] When preparing to build a shared object protected by a Standard Operating Procedure (SOP), the build process 400 configures a platform key for all supported computing devices or equipment. A software developer or library developer 402 issues a request 416 to the SOP builder 404, requesting the configuration of a platform key for the connected device. The SOP builder 404 then sends a request to retrieve the common portion of the platform key pair from the target device 406. Advantageously, the required platform key is securely stored within a trusted execution environment (TEU) within the computing device, and the request 420 to retrieve the common platform key is received by a trusted application executing within the TEU of the target device or computing device 406. Advantageously, any TEU capable of securely protecting the confidentiality of key materials, such as those referenced above... Figure 1 The Trusted Execution Environment 106 described above, or the reference above. Figure 2 The Trusted Execution Environment 252 described can be used to provide the required security environment.

[0082] The requested public platform key is returned to the SOP builder 404, which in turn returns an acknowledgment 418 to notify the library developer 402 that the configuration of device 406 is complete and that the public portion of the platform key has been loaded into the SOP builder.

[0083] Configuration 408 can be repeated for as many different computing devices 406 or device types as needed. In some embodiments, each computing device 406 or device type (e.g., mobile phone model, manufacturer, or carrier) will be populated with its own unique platform key. In embodiments that will support many different computing devices 406 with many different platform keys, SOP builder 404 needs to configure the platform key for each supported computing device 406, thereby storing or configuring multiple platform keys in SOP builder 404.

[0084] In the code generation phase 410, library developer 402 uses tools provided by SOP builder 404 to generate (424) custom constructor code and library scripts. The constructor code can be a constructor such as constructor 118 described above. A custom linker script is used to identify and isolate code sections to be marked as executable only, and also to reserve space for metadata and virtual parts within the target shared object. The constructor and linker script are then packaged (426) into the shared object. After running the linker script, the shared object can be compiled and linked using standard, regular procedures.

[0085] Testing and debugging of shared objects can be accomplished by temporarily configuring the constructor to skip the encryption step, thus allowing the compilation / linking / debugging 412 cycle to be completed using unprotected shared object code.

[0086] Once the shared object is ready for release, it is protected using encryption phase 414. In encryption phase 414, software developer 402 sends the compiled and linked shared object file to SOP builder 404. SOP builder 404 encrypts and (optionally) signs any desired portions of the library and replaces unencrypted portions with corresponding encrypted segments. SOP builder 404 then prepares metadata and includes it in the shared object. In some embodiments, SOP builder 404 includes encrypted information in the metadata to support decryption of the encrypted segments on any of a plurality of target platforms, obtaining the platform key for the target platform in configuration phase 408.

[0087] Figure 5 A software flowchart of an exemplary method 500 provided by aspects of the disclosed embodiments is shown, which is used to protect shared objects when deployed to a computing device. Aspects of the disclosed embodiments are designed to prevent the theft of software assets intended for distribution to and used by third-party developers. Exemplary method 500 is suitable for protecting the privacy of shared objects such as software libraries, software development kits (SDKs), or other types of redistributable software assets.

[0088] In the illustrated embodiment, the application executing in user space (502) identifies the need for a shared object and hires or invokes a loader to load (504) the required shared object into user memory. The loading of the shared object 504 may occur when the application is loaded, or may be triggered otherwise during the execution of the application.

[0089] exist Figure 5In the example, the shared object is loaded (504) into the user memory of a suitable rich execution environment of the computing device (e.g., rich execution environment 104 or 250 described above). The shared object can be loaded from a non-volatile portion of memory or from any other desired computer memory or storage device (504).

[0090] In one embodiment, the shared object includes an encrypted segment, metadata, and constructor routines or constructor code. The protected software asset is encrypted and placed within the encrypted segment before the shared object is distributed. Encryption can protect the confidentiality of the encrypted segment while it is dormant or transmitted over a computer network. The metadata includes information that can be used to decrypt or otherwise reassemble the encrypted segment in preparation for execution, and as described above, the constructor can run during the loading (504) of the shared object and communicate with the SOP agent during the preparation for execution of the shared object.

[0091] During or after loading (504) the shared object, the constructor contacts (506) the SOP agent to coordinate the preparation and execution of the shared object. This is done by contacting a trusted execution environment (e.g., as described above, see references). Figure 1 and Figure 2 Any of the trusted execution environments (106, 252) described herein sends (508) a decryption request to decrypt the encrypted portion (e.g., an encrypted segment) of the shared object. The decryption request may include the encrypted segment along with metadata providing the information and key data required to perform the decryption. In some embodiments, the metadata passed to the trusted execution environment is the same metadata included in the loaded shared object. Alternatively, the constructor code and / or SOP agent may construct metadata based on the content of the shared object.

[0092] In exemplary method 500, a trusted application running within a trusted execution environment processes the decryption request. In one embodiment, the trusted application verifies (510) the integrity of the SOP agent before processing the decryption request to ensure that the SOP agent is not infected with a virus or otherwise corrupted. The verification result is checked (512), and if the integrity check fails, the decryption request is rejected (514).

[0093] When the integrity of the SOP agent is found to be valid, the encrypted segment is decrypted (516), and the decrypted segment is returned (518) to the SOP agent executing in the rich execution environment.

[0094] The decrypted segment is then written to (520) user memory and merged into the shared object. Alternatively, the decrypted segment can be written back to the same memory originally occupied by the encrypted segment, or it can be written back to a newly allocated portion of user memory, which is then configured as part of the shared object.

[0095] In the illustrated embodiment, the software application, SOP agent, and other user applications execute at a first privilege level. This first privilege level prevents programs executing at the first privilege level from performing any memory management operations, such as modifying access permissions to memory occupied by shared objects. Memory management operations are only permitted to be performed by programs executing at a second privilege level (e.g., an SOP lock program), where the second privilege level includes privilege levels that are either higher or less restrictive than the first privilege level.

[0096] The SOP lock procedure locks (522) the memory occupied by the shared object when executing at the second privilege level. The lock allows the user-space application executing at the first privilege level to execute the locked code, but prevents reading or modifying the locked memory, thereby preventing the theft of software assets contained in the shared object. Execution of the user-space application can now be resumed (524), and the application can begin to use the features provided by the shared object.

[0097] In an exemplary embodiment of method 500 described above, the encrypted segment is encrypted based on an asset key. The metadata included in the shared object includes the encrypted asset key, wherein the encrypted asset key includes a predetermined platform key (e.g., referenced above). Figure 1 The asset key described is encrypted using the predefined platform key 174. Employing symmetric-key cryptography for the asset key and asymmetric-key cryptography for the platform key reduces the processing costs associated with decrypting encrypted segments while enhancing the security advantages of asymmetric cryptography, including the associated private key infrastructure (PKI).

[0098] In one embodiment, metadata may include multiple encrypted asset keys, wherein each encrypted asset key includes the same asset key encrypted with a different predetermined platform key from a plurality of predetermined platform keys. During decryption, a trusted application can select from the plurality of encryption keys the encryption key encrypted with the predetermined asset key available to the trusted application. By including multiple encrypted asset keys, a single build of a shared object can be used on multiple different types of computing devices, wherein the different types of computing devices have different predetermined platform keys.

[0099] Therefore, although the essential novel features of the invention applicable to exemplary embodiments thereof have been shown, described, and pointed out herein, it should be understood that those skilled in the art can make various omissions, substitutions, and changes to the form and details of the illustrated devices and methods, as well as the operation of the setup, without departing from the spirit and scope of the invention. Furthermore, all combinations of those elements that are explicitly desired to perform substantially the same function in substantially the same manner to achieve the same result are within the scope of the invention. Moreover, it should be recognized that structures and / or elements shown and / or described in conjunction with any form or embodiment of the disclosed invention can be incorporated as general design choices into any other form or embodiment disclosed, described, or suggested. Therefore, its intent is limited only as indicated by the scope of the appended claims.

Claims

1. A device for protecting shared objects, characterized in that, The processor is coupled to memory, wherein the processor and memory are used to provide a rich execution environment and a trusted execution environment, wherein memory and processes in the trusted execution environment are protected from access or modification by applications executing within the rich execution environment, and the processor and memory are also used to provide within the rich execution environment: A first computing environment for execution at a first privilege level; and a second computing environment for execution at a second privilege level, wherein the first privilege level is more restrictive than the second privilege level, and the processor is used for: Within the rich execution environment, a shared object is loaded into user memory, wherein the shared object includes an encrypted segment and metadata; A decryption request is sent from the rich execution environment to the trusted execution environment, wherein the decryption request includes the metadata and the encrypted segment; The encrypted segment is decrypted within the trusted execution environment to generate a decrypted segment, wherein the decryption is based on the metadata and a predetermined platform key; Receive a decryption response including the decryption segment within the rich execution environment; Write the decrypted segment into the shared object; Send a request to lock the shared object from the first computing environment to the second computing environment; When executed at the second privilege level, the memory occupied by the shared object is set to execute-only.

2. The apparatus according to claim 1, characterized in that, The metadata includes an encrypted asset key, and the encrypted asset key includes an asset key encrypted according to the predetermined platform key, wherein the processor is configured to, within the trusted execution environment, decrypt the encrypted asset key according to the predetermined platform key, and decrypt the encrypted segment according to the decrypted asset key.

3. The apparatus according to claim 1, characterized in that, The metadata includes multiple encrypted key data, and each encrypted key data includes the asset key encrypted according to a different platform key from a plurality of platform keys, the processor being configured to select the encrypted key data from the plurality of encrypted key data according to the predetermined platform key.

4. The apparatus according to any one of claims 1 to 3, characterized in that, The decryption request is sent by an agent executing within the rich execution environment, and the processor is configured to verify the integrity of the agent within the trusted execution environment before decrypting the encrypted segment.

5. The apparatus according to any one of claims 1 to 3, characterized in that, The predetermined platform key is the common part of the asymmetric key pair.

6. The apparatus according to any one of claims 1 to 3, characterized in that, The asset key is a symmetric key.

7. The apparatus according to any one of claims 1 to 3, characterized in that, The rich execution environment includes a third computing environment for execution at a third privilege level, and the second privilege level is more restrictive than the third privilege level, wherein the processor is configured to, when executing at the third privilege level, set the memory occupied by the shared object to execution-only.

8. The apparatus according to claim 7, characterized in that, The first computing environment includes user applications, the second computing environment includes an operating system, and the third computing environment includes a hypervisor.

9. The apparatus according to any one of claims 1 to 3, characterized in that, The shared object includes a constructor routine that, when executed by the processor, causes the processor to send the decryption request.

10. The apparatus according to any one of claims 1 to 3, characterized in that, The trusted execution environment includes a trusted application, and the rich execution environment includes an agent, wherein the trusted application is used for: Receive the decryption request from the agent; Verify the integrity of the agent; When the integrity is valid, the encrypted segment is decrypted to generate the decrypted segment, and the decrypted segment is returned to the agent.

11. The apparatus according to any one of claims 1 to 3, characterized in that, The encrypted segment occupies a first memory area, and writing the decrypted segment into the shared object includes one or more of the following operations: writing the decrypted segment into the first memory area; Write the decrypted segment into the second memory area; The second memory region is merged into the shared object.

12. The apparatus according to any one of claims 1 to 3, characterized in that, The device includes a mobile communication device.

13. A method for protecting shared objects, characterized in that, include: Within a rich execution environment, a shared object is loaded into user memory, wherein the shared object includes an encrypted segment, metadata, and a constructor routine; A decryption request is sent from the rich execution environment to the trusted execution environment, wherein the decryption request includes the metadata and the encrypted segment; The encrypted segment is decrypted within the trusted execution environment to produce an unencrypted segment, wherein the decryption is based on the metadata and a predetermined platform key; Within the rich execution environment, a decryption response is received from the trusted execution environment, wherein the decryption response includes a decryption segment; Write the decrypted segment into the shared object; When executing at the second privilege level, the memory occupied by the shared object is set to execute-only; The shared object is accessed from the user application at a first privilege level, wherein the first privilege level is more restrictive than the second privilege level.

14. The method according to claim 13, characterized in that, The encrypted segment is encrypted based on an asset key, and the metadata includes an encrypted asset key, wherein the encrypted asset key includes an asset key encrypted according to a predetermined platform key, and the method includes: decrypting the encrypted asset key according to the predetermined platform key in the trusted execution environment; and decrypting the encrypted segment according to the asset key in the trusted execution environment.

15. A non-transitory computer-readable medium, characterized in that, The system stores program instructions that, when executed by the processor, cause the processor to perform the method according to claim 13 or 14.

Images