System and method for non-intrusive automated trusted operator migration

Abstract

The present disclosure provides systems and methods for non-intrusive automated trusted operator migration. According to an aspect, a method for executing code in a secure environment is provided. The method includes receiving code including an annotated portion and an unannotated portion. The annotation portion indicates a portion of the code for secure execution. The method may also include constructing a trusted application (TA) corresponding to the annotated portion in a trusted execution environment (TEE). The method may also include constructing a client application (CA) corresponding to the unannotated portion in a rich execution environment (REE).

Description

[0001] Cross - reference to related applications

[0002] This is the first application related to the present disclosure. Technical field

[0003] The present disclosure relates to the field of computer security, and more particularly to systems and methods for non - invasive automated trusted operator migration. Background art

[0004] Computer security is an evolving field that faces several challenges in ensuring the confidentiality and integrity of computing systems and their data. Cyber - attacks and threats are some of these challenges that may require continuous monitoring and updating of security measures. Additionally, modern computing systems are complex, having a wide variety of hardware and software components that must be secured. This complexity can create vulnerabilities that are difficult to detect and resolve. Existing solutions face many limitations and challenges while providing some advantages. One of the limitations of existing solutions is software compatibility. For example, existing solutions require modifying the original program to adapt to new environments and security features. Moreover, current use of these technologies may introduce performance overhead, which can affect the overall performance of the system.

[0005] Therefore, there is a need for systems and methods for non - invasive automated trusted operator migration that eliminate or mitigate one or more limitations of the prior art.

[0006] This background information is provided to disclose information that the applicant believes may be relevant to the present invention. This is not necessarily intended to admit, nor should it be construed as, any of the foregoing information constituting prior art with respect to the present invention. Summary of the invention

[0007] The present disclosure provides systems and methods for non - invasive automated trusted operator migration. According to one aspect, a method for executing code in a secure environment is provided. The method includes: receiving code including an annotated portion and an unannotated portion, the annotated portion indicating the portion of the code for secure execution. The method may further include: constructing a trusted application (TA) corresponding to the annotated portion in a trusted execution environment (TEE). The TEE may be the TEE of TrustZone. The method may further include: constructing a client application (CA) corresponding to the unannotated portion in a rich execution environment (REE).

[0008] The method may further include: receiving, at the CA, a request to execute a function in the TA based on data included in the request. The method may further include: sending the request from the CA to the TA. The method may further include: executing, at the TA, the function based on the request to obtain a result. The method may further include: sending the result from the TA to the CA. The method may further include: sending the result from the CA to the caller.

[0009] The step of sending the request from the CA to the TA may further include: serializing the data at the CA to obtain serialized data. Sending the request from the CA to the TA may further include: sending a request including the serialized data from the CA to the TA.

[0010] The step of executing the function at the TA based on the request to obtain a result may include: deserializing the serialized data at the TA to obtain the data. Executing the function at the TA based on the request to obtain a result may further include: executing the function based on the data at the TA to obtain the result.

[0011] Sending the result from the TA to the CA may include: serializing the result at the TA to obtain serialized result. Sending the result from the TA to the CA may further include: sending the serialized result from the TA to the CA.

[0012] Sending the result from the CA may include: deserializing the serialized result at the CA to obtain the data.

[0013] The method may further include: establishing a communication channel between the CA and the TA. The method may further include: generating a serialization function and a deserialization function for use in the communication channel.

[0014] According to an embodiment, the annotation part is annotated using in-file annotations or out-of-file annotations. The out-of-file annotation may be a meta-file of a defined domain specific language (DSL). The meta-file of the DSL may be a YAML file. The in-file annotation may be in the form of: MACRO, C++ custom attribute, or Doxygen parameter. The annotation part may include one or more of classes and functions.

[0015] According to another aspect, an apparatus is provided. The apparatus includes modules configured to execute one or more of the methods described herein.

[0016] According to one aspect, a device is provided, wherein the device comprises: a memory configured to store a program; a processor configured to execute the program stored in the memory, and when the program stored in the memory is executed by the processor, the device is configured to execute one or more of the methods described herein.

[0017] According to another aspect, a computer-readable medium is provided, wherein the computer-readable medium stores program code executable by a processor associated with a device, and the program code is for executing one or more of the methods described herein.

[0018] According to one aspect, a chip is provided, wherein the chip comprises a processor and a data interface, and the processor reads and executes instructions stored in a memory by using the data interface, and the instructions configure the chip to execute one or more of the methods described herein.

[0019] Other aspects of the present disclosure provide devices and systems configured to implement the methods according to the first aspect disclosed herein. For example, the device can be a wireless station and an access point. The device can be configured with a machine-readable memory including instructions that, when executed by a processor of the device, configure the device to execute one or more of the methods and systems described herein.

[0020] Embodiments have been described above in connection with aspects of the present invention, and these embodiments can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in combination with the aspects describing these embodiments, but can also be implemented by other embodiments of these aspects. This will be apparent to those skilled in the art when the embodiments are mutually exclusive or inconsistent with each other. Some embodiments can be described with respect to one aspect, but can also be applicable to other aspects, which will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Other features and advantages of the present invention will become apparent from the following detailed description in conjunction with the accompanying drawings, in which:

[0022] Figure 1 The main SGX implementations are shown.

[0023] Figure 2 The trusted region environment is shown.

[0024] Figure 3A File-level annotations at the class level according to one aspect are shown.

[0025] Figure 3B File-level annotations at the function level according to one aspect are shown.

[0026] Figure 3C Shows in - file comments based on Doxygen comment blocks according to one aspect.

[0027] Figure 4A Shows out - of - file comments at the class level according to one aspect.

[0028] Figure 4B Shows out - of - file comments at the function level according to one aspect.

[0029] Figure 5 Shows a workflow diagram according to one aspect.

[0030] Figure 6 Shows a running compiler extension such as Omnishield according to one aspect.

[0031] Figure 7 Shows a method for performing a security operation according to one aspect.

[0032] Figure 8 Shows an apparatus that can perform any or all of the above - described methods and features explicitly or implicitly described herein according to different aspects of the present disclosure.

[0033] It should be noted that throughout the drawings, like features are identified by like reference numerals. Detailed Description

[0034] The present disclosure provides systems and methods for non - intrusive automated trusted operator migration. According to one aspect, a method for executing code in a secure environment is provided. The method includes: receiving code that includes an annotated portion and an unannotated portion. The annotated portion can indicate the portions of the code that need to be moved to the secure environment for secure execution. The method can further include: constructing a trusted application (TA) corresponding to the annotated portion in a trusted execution environment (TEE). The method can further include: constructing a client application (CA) corresponding to the unannotated portion in a rich execution environment (REE). In some embodiments, the annotated portion indicates one or more classes and functions in the code that are to be moved to the TEE. In some embodiments, the annotated portion is annotated using in - file comments or out - of - file comments.

[0035] As the cloud computing paradigm brings high efficiency to many big data applications, concerns about its security and reliability are also increasing. On public clouds, users may face attacks from other tenants and are particularly vulnerable to privileged attacks, in which the entire OS may be under the control of the attacker.

[0036] To address this concern, Provided Software GuardeXtensions (SGX), which uses enclaves—isolated memory areas—for secure computing. Provides TrustZone with system-wide hardware-enforced isolation between normal and trusted environments.

[0037] However, developers still have the burden of modifying their original programs to adapt to new environments and security features. The code rewriting required for these modifications can be cumbersome, especially in the case of striving to minimize the trusted computing base (TCB) to achieve high performance.

[0038] Existing solutions can be classified into two categories: library operating system (LibOS) solutions and partitioning solutions. LibOS solutions require minimal or even no code rewrite. However, these solutions transfer the entire application to the secure environment together with the lightweight operating system (OS). Graphene-SGX is such a lightweight LibOS: it can be SGX runs a single application in an isolated environment with minimal host requirements. Memory-safe, multi-process LibOS for SGX. SCONE provides secure Linux containers on Intel SGX.

[0039] Alternatively, partitioning solutions move a portion of an application into a trusted execution environment (TEE), but this typically requires considerable and costly modification of legacy code. Sensitive code needs to be rewritten to take advantage of the C or C++ application program interface (API) of SGX or TrustZone.

[0040] In addition, Uranus is a tool that can migrate Java Virtual Machine (JVM) programs to SGX after the sensitive parts of the code have been marked with Java comments. Uranus also addresses some of the major vulnerabilities in code reuse methods. RT-Trust is a tool that can migrate C programs with real-time characteristics to a trusted environment after the code has been marked with comments in a specific format.

[0041] Another solution is Huawei's secGear, which does not fall into the two categories mentioned. This solution aims to provide a unified development framework for different hardware devices, thus shielding the differences between the underlying confidential computing architectures and APIs. The hardware devices include SGX hardware and TrustZone. secGear provides extensibility capabilities at both the middleware layer and the service layer, enabling developers to call security components and directly use confidential computing services.

[0042] However, existing solutions have their limitations. Figure 1 Shows the main SGX implementation methods. The library OS simulates the functions of the OS through context-based optimized function calls while interacting with the host OS via the enclave interface. The shim layer acts as an intermediate layer that simply passes calls from inside the enclave to the underlying host OS. However, these solutions may require the application to be packaged as a whole, even for non-sensitive functions. This inevitably leads to an increase in the TCB and thus a performance degradation, especially for data-intensive applications. Combining with the limited space in the TEE, the LibOS solution is not suitable for solving big data problems.

[0043] Figure 2 Shows the trusted environment. The trusted environment requires partitioning and rewriting the code for its APIs. For the partitioning method, some solutions also provide in-file comments to assist with code migration. However, their limitations cannot be ignored. For example, Uranus only supports code migration for Java Virtual Machine (JVM) language. Additionally, the comments associated with RT-Trust are intrusive. For example, after the code has been commented by the design of RT-Trust, it cannot be compiled by a general C compiler.

[0044] In addition, the existing technologies are intrusive because their applications require changing the code according to the partitioning best practices from To use TrustZone, the user has to partition their application into two parts (client application and trusted application) by changing their code. This modification can be considered intrusive. Additionally, existing solutions migrate the entire code (including parts that do not need protection) into the TEE, which further increases the attack surface, i.e., the TCB.

[0045] Common drawbacks of existing solutions are that they only handle data sizes in the megabyte (MB) range. This drawback will become increasingly prominent as real-world applications demand higher and higher capabilities for processing large amounts of data. Additionally, almost all tools are targeted at SGX. TrustZone runs an independent secure OS that already provides the OS functionality that LibOS attempts to provide.

[0046] One aspect of the present disclosure can avoid the need for developers to perform cumbersome and error-prone code rewriting to use TrustZone for confidential computing. Some aspects can also improve the low-performance issues caused by data being unnecessarily passed into TrustZone and out of TrustZone.

[0047] According to one aspect, a non-intrusive compiler extension can be provided that uses existing syntax to support the automatic conversion of untrusted functions into trusted functions. The compiler extension can also be referred to as Omnishield in some embodiments. The compiler extension can be easy to use through various forms of non-intrusive annotations.

[0048] In some aspects, both untrusted functions and trusted functions can coexist as part of the binary output, and it can be decided at runtime whether to use the trusted version of the function or the untrusted version of the function, which can be based on the sensitivity of the data. According to one aspect, an adaptive execution pipeline can be provided, where non-sensitive data used in the application will be processed using untrusted functions to improve performance. Thus, the data exchange strategy can be adjusted based on the data sizes involved.

[0049] According to one aspect, the framework described herein can provide automated memory management, secure data serialization and deserialization. It can be understood that during processing, sensitive data can be serialized into and out of the secure environment. Serialization can be performed by adopting secure data serialization techniques to ensure that the data is correctly and securely fed into the secure environment and the results are obtained from the secure environment.

[0050] According to some aspects, batch processing with improved performance and security can be enabled for data-intensive applications. In an implementation, a number of operators can be enabled to work together to provide batch processing (e.g., performing multiple operations using a single function call). For example, assuming that three operations need to be performed, the typical way is to call the operations one by one, which results in three function calls. According to one aspect, the calls for multiple operations can be simplified into a single function call. From the customer's perspective, a single function call can be used to perform multiple operations. Simplifying multiple operations into a single function call (e.g., batch processing) can enable reducing the round trips in and out of the secure environment, and thus reducing the security risks and overheads involved in the transmission processing of round trips to the secure environment (since each round trip involves encryption and decryption operations, etc.).

[0051] According to one aspect, security classes and functions can be chained together to reduce the overhead caused by the transmission of information to and from the secure environment. As a compiler extension, preprocessing can be automatically applied during the compilation phase and controlled or initiated through compiler flags.

[0052] According to one aspect, the user's code (e.g., a C or C++ program) can be preprocessed, where a part (e.g., one or more classes and functions of the program) can operate on sensitive data. After preprocessing, the code can be migrated into a form suitable for the TrustZone API or other similar trusted execution environments for secure computing.

[0053] According to one aspect, the user can non-intrusively annotate the code (e.g., source code) either inside or outside the source code file. It can be understood that non-intrusive annotation can indicate that the user does not need to make code changes as they should in the case of following the partitioning best practices from . According to To use TrustZone, the user has to partition their application into two parts (client application and trusted application). In stark contrast, according to one aspect, the user does not need to modify the original source code (as required for partitioning), while still being able to secure the operations associated with the selected parts of the code. The user can non-intrusively annotate their code via in-file annotations or out-of-file annotations. In some implementations, the user can annotate the code in-file via simple C++ attributes. In some implementations, the user can annotate the code via out-of-file annotations in a file independent of the code, and the source code remains unchanged. Since the code is not modified as required in other cases, non-intrusive annotation enables increased flexibility.

[0054] Users can annotate the source code to indicate one or more parts (such as one or more in classes and functions) in the source code file that need to be securely computed in the TEE (e.g., for migration to a secure environment). Thus, according to one aspect, a non-invasive approach can be provided that avoids the need to partition the source code. In some embodiments, in-file annotations can apply to new code, while out-of-file annotations can apply to legacy code.

[0055] According to one aspect, thus, file annotations (whether in-file or out-of-file) can indicate one or more parts of the source code for migration to a secure environment. In some aspects, file annotations can indicate additional information related to the code, such as the marked data type, data size, etc.

[0056] Those skilled in the art can understand that code annotations can take several forms. This flexibility can reduce the annotation effort by adapting to different characteristics of legacy code.

[0057] In one embodiment, for in-file annotations, an annotation such as a SECURE tag can be placed next to a part of the code (e.g., a function or a class) to indicate that secure execution is required. In some embodiments, the annotation can be in the form of a MACRO, a custom attribute, a Doxygen parameter, or other suitable annotation syntax that is easy to understand. In some embodiments, when other descriptions of some function parameters, such as size, serialization / deserialization (serde), cannot be determined from the function declaration, the annotation can include these characteristics.

[0058] In some embodiments, out-of-file annotations can involve generating a new file, such as a YAML file or other suitable file configuration, that indicates information similar to that of in-file annotations. Thus, for out-of-file annotations, the annotations can be saved in a meta-file of a defined domain specific language (DSL), such as YAML. The DSL can describe the qualified names of functions and / or classes.

[0059] The indicated (e.g., labeled or marked) one or more parts of the annotated code can be moved to a secure environment. In some embodiments, as described herein, an extension of the compilation process - a compiler extension (referred to as Omnishield in some embodiments) can be used to perform the operations involved in moving the indicated one or more parts of the annotated code. In some embodiments, the extension of the compilation process can operate in a switch-like manner, by which the user can activate the extension by turning on the switch to process the marked parts of the source code. Then the compiler can operate accordingly.

[0060] Figure 3AIllustrates in - file comments at the class level according to one aspect. In some embodiments, one or more classes can be marked as secure to indicate one or more classes for migration to a secure environment. According to an embodiment, the security marking can be done at the class level. For example, in Figure 3A the class "Automobile" is marked as secure. The comments can also indicate useful information, such as "size = parts_size; manual[inout]; record[in]: serde = custom, size = record_size".

[0061] In some aspects, the security marking can be done at the function level. Figure 3B Illustrates in - file comments at the function level according to one aspect. For example, in Figure 3B the function "MaintenanceRecord* GetRecord" is marked as secure. It should be understood that although the comments in Figure 3A and Figure 3B are based on C++ custom attributes, other suitable comment styles such as Doxygen comment blocks can also be used, as shown in Figure 3C . Figure 3C Illustrates in - file comments based on Doxygen comment blocks according to one aspect.

[0062] As described herein, for out - of - file comments, the user can provide a YAML - formatted file including the names and basic information of secure classes and functions. Figure 4A Illustrates out - of - file comments at the class level according to one aspect. Figure 4B Illustrates out - of - file comments at the function level according to one aspect.

[0063] As Figure 4A and Figure 4B shown, the original source code remains unchanged. New files such as YAML files can include the required comments to indicate one or more parts of the source code for migration. Similar to in - file comments, out - of - file comments can be used to mark one or more classes or one or more functions as secure, thus identifying the marked classes or functions for transfer to a secure environment for execution.

[0064] In some embodiments, to reduce the amount of annotations required, additional information may be needed in addition to the "secure" label. For example, if there are pointers in the function variable parameter list, their sizes may need to be provided. In some embodiments, additional information may be needed if references or pointers in the associated variable parameter list are used to save outputs. In such cases, the [out] or [inout] symbols may be needed. In some embodiments, additional information may be needed in the following cases: the variable parameter list includes user-defined types, where embodiments of such types can be annotated as "serde=custom".

[0065] In some embodiments, if a class or function is indicated as sensitive by the aforementioned attributes, the class or function can be automatically migrated to a trusted environment or a secure environment. In some embodiments, functions to be executed can be divided into stateless functions and stateful functions. In some embodiments, stateless functions can be executed by traditional functions such as int Multiply(int x, int y). Stateful functions can be executed by instances of classes (i.e., objects) such as void Operator.AddInput(VectorBatch*).

[0066] According to one aspect, migrating a class or function to a trusted environment or a secure environment may involve generating serde (serialization, deserialization) for data transmission. In some embodiments, for annotated stateless functions, function parameters can be collected to generate serde. In some embodiments, for stateful functions, parameters of all class member functions including constructors can be collected to generate serde. In some embodiments, a custom serde can be specified to override the automatically generated serde.

[0067] According to one aspect, migrating a class or function to a trusted environment or a secure environment may involve code generation. In some embodiments, "untrusted" functions can be encapsulated in a proxy to intercept the parameters required by the functions. In some embodiments, "untrusted" functions can be encapsulated in a proxy to create a corresponding trusted application (TA) using the original untrusted code. In some embodiments, "untrusted" functions can be encapsulated in a proxy to serialize the parameters into shared secure memory. In some embodiments, "untrusted" functions can be encapsulated in a proxy so that the CA can call the TA and the parameters. In some embodiments, "untrusted" functions can be encapsulated in a proxy to retrieve the output from the secure memory.

[0068] According to one aspect, a compiler extension, which may be referred to as Omnishield in some embodiments for example, can mark the parts (one or more functions and classes) in the code that require confidential computing, while the rest remains unchanged. Thus, Omnishield can cause the target functions to be automatically migrated into the TEE via annotations. Omnishield can also reduce or minimize the TCB of the system to improve security. Since only the necessary functions can run in the resource-constrained TEE, Omnishield can also achieve performance improvement. Omnishield can also automate the preprocessing associated with compilation. Since the security enhancement is non-intrusive, Omnishield can also achieve transparency. Omnishield can also flexibly serialize and deserialize buffers and send and receive large data, which can make this type of compiler extension an ideal tool for big data applications.

[0069] Figure 5 A workflow diagram according to one aspect is shown. A client can annotate the code 502 via, for example, C++ custom attribute annotations or appropriate techniques to indicate the parts in the code for migration into the TEE. A compiler extension, which may be referred to as Omnishield in some embodiments, can receive the annotated client code and preprocess the client code 504. Omnishield can generate code for migrating the indicated parts (e.g., indicating sensitive parts of the program) in the code into the TEE. Generating the code can involve generating 506 secure copies (e.g., TAs) for the indicated parts (which can be sensitive classes and functions). Generating the code can also involve generating 508 TA and CA support files. Generating the code can also involve generating 510 serde (serialization / deserialization) data, data input functions, and data output functions.

[0070] According to an embodiment, to generate the serde for an annotated function or class, on the client application (CA) side, security functions (member functions of a security class or annotated functions) can be intercepted, and the associated parameters can be collected to generate the serde. In some embodiments, generating the serde can be automated. In some embodiments, the user can also provide specific serde parameters or instructions to override the automatically generated serde. Then, the serialized parameters can be transmitted into the secure memory in the TEE. Then, the CA can initiate a TA call and retrieve the output from the secure memory.

[0071] As mentioned, a secure copy of the function can be generated on the TA side. A compiler extension, which may be referred to as Omnishield in some embodiments, can deserialize the function arguments and perform the function operations, and then send the results back. In the case of a large amount of output, the results can be sent back in batches.

[0072] In one embodiment, the preprocessed code can be combined or integrated in a trusted environment. For example, the Huawei iTrustee SDK, such as the support files for its integrity features and all standard types of pre-written serde, are integrated in the trusted environment.

[0073] It can be understood that when several functions or operators are chained together, they can be combined into a single process from CA to TA and then back to CA. In some embodiments, a compiler extension (which may be referred to as Omnishield in some embodiments) can avoid the need for unnecessary intermediate stage result transmissions, and thus, these intermediate stage result transmissions may not occur. Since SQL requests typically include a series of operations and only require the final result, this feature (i.e., avoiding intermediate stage result transmissions) can be beneficial for big data applications.

[0074] In some embodiments, one or more features of a compiler extension such as Omnishield can be designed as a plugin, such as a Clang-plugin. It should be understood that the plugin can be controlled using compiler flags. Thus, a mechanism can be provided for the user to select or not select to activate the compiler extension, i.e., to securely execute certain classes or functions.

[0075] Figure 6 A compiler extension, which may be referred to as Omnishield in some embodiments, in the operations according to one aspect is shown. The Omnishield operations can refer to block 600. In one embodiment, a user or caller 620 can annotate the code to indicate one or more parts of the code that are identified for secure operations. One or more parts of the code can include one or more classes and functions. Based on the code and the annotation, Omnishield can request additional information associated with the classes or functions as needed.

[0076] The caller 620 may request one or more services from Omnishield 600 and provide Omnishield with code with associated annotations. As part of the request, the caller may request, for example, a constructor in an instance of class A, where class A is included in a section indicated for secure operation. Omnishield may intercept the call (e.g., request) and associated parameters and forward them to the TEE 628. At the TEE 628, Omnishield may construct class A 624 within the trusted application. Omnishield may return a handle 603 from class A 624 to the caller 620. The caller may use the handle as, for example, a ticket to redeem a service. The interception (e.g., forwarding of the service) and the constructor of class A 624 may refer to Figure 5 the TA / CA support file 508.

[0077] In one embodiment, the caller 620 may use the handle to call function A of class A by sending a second request 604 (e.g., calling ClassA.functionA(Args…)). Omnishield may intercept the second request on the client application side in the REE (e.g., at class A 626). Omnishield may serialize the second request at class A 622 in the REE 605 and send the serialized second request to class A 624 in the TEE 628. At class A 624, the serialized second request may be deserialized to determine the second request. Thereafter, function A may be called on class A in the TEE 606 to obtain a result. Then, the result may be serialized at class A 624 and sent to the client application side class A 622. On the client application side, the serialized result may be deserialized and sent back to the caller. In some embodiments, the TA class A 624 may be deleted by initiating a delete request 606, as Figure 6 shown.

[0078] According to some aspects, multi-form and non-intrusive annotations may be used to indicate the portions of the code to be executed in a secure environment. Thus, the original code may remain intact, and the work required to perform secure operations may be reduced. Some aspects may also allow for the migration of C code and C++ code. It can be understood that much high-performance code is written in C++. One or more aspects may allow for the migration of code (e.g., C++ code) to a trusted environment such as TrustZone or a similar trusted execution environment that supports code migration, thereby incorporating the advantages of the C++ language into confidential computing. According to some aspects, secure functions may be chained together to improve performance, which further reduces unnecessary large data transfers.

[0079] Figure 7 A method for performing a security operation according to one aspect is shown. Method 700 includes: receiving 701 code including an annotated portion and an unannotated portion. The annotated portion indicates the portions of the code for secure execution. The annotation can be in a non-intrusive manner, which enables the annotated code to be compatible with compilation by a general-purpose C compiler. The non-intrusive aspect can also enable accommodation of increased data sizes, which is applicable to big data applications. As described herein, the annotation can be performed within or outside the file.

[0080] Method 700 may further include: constructing 702 a trusted application (TA) corresponding to the annotated portion in a trusted execution environment (TEE). It can be understood that only the portions of the code indicated by the annotated portion can be moved into the TEE for secure operation. This feature (i.e., migrating only the required portions of the code to the TEE) can allow for handling larger code sizes (compared to code sizes based on the prior art) and significantly reduce the attack surface, i.e., the TCB.

[0081] The TEE can refer to any suitable TEE, such as a TrustZone TEE or other similar TEE. Method 700 may further include: constructing 703 a client application (CA) corresponding to the unannotated portion in a rich execution environment (REE). The REE can refer to any suitable REE, such as a TrustZone REE or other similar REE.

[0082] It can be understood that the migration of the code to the TEE and the REE can be automatic. In one aspect, the code can be scanned, and the required portions indicated via the annotation (whether within or outside the file) can be identified and moved accordingly.

[0083] In some embodiments, method 700 may further include: receiving, at the CA, a request from a caller to execute a function in the TA based on data included in the request. In some embodiments, method 700 may further include: sending a request from the CA to the TA. In some embodiments, method 700 may further include: executing, at the TA, the function based on the request to obtain a result. In some embodiments, method 700 may further include. In some embodiments, method 700 may further include: sending the result from the TA to the CA. In some embodiments, method 700 may further include: sending the result from the CA to the caller.

[0084] In some embodiments, sending a request from the CA to the TA may include: serializing data at the CA to obtain serialized data. In some embodiments, sending a request from the CA to the TA may further include: sending a request including the serialized data from the CA to the TA.

[0085] In some embodiments, executing a function at the TA based on the request to obtain a result may include: deserializing the serialized data at the TA to obtain the data. In some embodiments, executing a function at the TA based on the request to obtain a result may further include: executing a function based on the data at the TA to obtain the result.

[0086] In some embodiments, sending the result from the TA to the CA may include: serializing the result at the TA to obtain a serialized result. In some embodiments, sending the result from the TA to the CA may further include: sending the serialized result from the TA to the CA.

[0087] In some embodiments, sending the result from the CA to the caller may include: deserializing the serialized result at the CA to obtain the data. In some embodiments, sending the result from the CA to the caller may further include: sending the result from the CA to the caller.

[0088] In some embodiments, the method may further include: establishing a communication channel between the CA and the TA. In some embodiments, the method may further include: generating a serialization function and a deserialization function for use in the communication channel.

[0089] In some embodiments, the annotation part is annotated using in-file comments or out-of-file comments. The in-file comments can be in any suitable format understandable by those skilled in the art. For example, they can be in the form of MACRO, custom attributes (C++ custom attributes), Doxygen parameters, or other suitable comment syntax.

[0090] The out-of-file comments may involve generating a new file such as a YAML file or another suitable file configuration. For out-of-file comments, the comments can be saved in a meta-file of a defined domain specific language (DSL). In some embodiments, the out-of-file comments are YAML files. In some embodiments, the annotation part includes one or more of classes and functions.

[0091] Figure 8FIG. 800 illustrates an apparatus 800 in accordance with various aspects of the present disclosure. The apparatus 800 may perform any or all of the above-described methods and features, either explicitly or implicitly described herein. For example, a computer equipped with network capabilities may be configured as the apparatus 800. In some aspects, the apparatus 800 may be a device connected to a network infrastructure via a wireless interface, such as a mobile phone, a smart phone, or a device that may be classified as a user equipment (UE). In some aspects, the apparatus 800 may be a machine type communications (MTC) device (also known as a machine-to-machine (M2M) device) or another such device that may be classified as a UE although it does not provide direct services to a user. In some aspects, the apparatus 800 may be used to implement one or more aspects described herein. For example, the apparatus 800 may be configured to implement a compiler extension that may be referred to as Omnishield in some embodiments. The apparatus 800 may also be configured to perform one or more operations described with reference to Figure 5 , Figure 6 and Figure 7 .

[0092] As shown, the apparatus 800 may include a processor 810 (e.g., a central processing unit (CPU) or a dedicated processor such as a graphics processing unit (GPU) or other such processor unit), a memory 820, a non-transitory mass storage device 830, an input-output interface 840, a network interface 850, and a transceiver 860, all of which are communicatively coupled via a bidirectional bus 870. According to certain aspects, any or all of the described elements may be utilized, or only a subset of the elements may be utilized. Additionally, the apparatus 800 may include multiple instances of certain elements, e.g., multiple processors, multiple memories, or multiple transceivers. Further, the elements of the hardware device may be directly coupled to other elements without the need for a bidirectional bus. In addition to or in lieu of the processor and the memory, other electronic devices such as integrated circuits may be employed to perform the required logical operations.

[0093] The memory 820 may include any type of non-transitory memory, such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof, etc. The mass storage device component 830 may include any type of non-transitory storage device, such as, for example, a solid state drive, a hard disk drive, a disk drive, an optical disk drive, a USB drive, or any computer program product configured to store data and machine-executable program code. In accordance with certain aspects, the memory 820 or the mass storage device 830 may record thereon statements and instructions executable by the processor 810 for performing any of the method operations recited above.

[0094] Aspects of the present disclosure may be implemented using electronic hardware, software, or a combination thereof. In some aspects, this may be achieved by one or more computer processors executing program instructions stored in a memory. In some aspects, for example, the present invention uses one or more field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs) to perform processing operations quickly to implement partially or fully in hardware.

[0095] It should be understood that, although specific aspects of the present technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the present technology. Accordingly, the specification and drawings are to be regarded only as illustrative of the invention as defined by the appended claims, and are expected to cover any and all modifications, variations, combinations, or equivalents falling within the scope of the invention. Specifically, within the scope of the present technology, a computer program product or program element, or a program storage device or memory device such as magnetic wiring or optical wiring, magnetic tape or disk, etc., is provided for storing machine-readable signals, for controlling the operation of a computer in accordance with the method of the present technology, and / or for constructing in part or in whole components of its system in accordance with the present technology.

[0096] The actions associated with the methods described herein may be implemented as encoded instructions in a computer program product. In other words, the computer program product is a computer-readable medium on which software code is recorded to perform the methods when the computer program product is loaded into a memory and executed on a microprocessor of a wireless communication device.

[0097] In addition, each operation of the method can be performed on any computing device such as a personal computer, a server, a PDA, etc. and in accordance with one or more program elements, modules or objects generated from any programming language such as C++, Java, etc. or a part of one or more program elements, modules or objects. Additionally, each operation or a file or object implementing each said operation, etc. can be performed by dedicated hardware or a circuit module designed for this purpose.

[0098] Through the description of the foregoing aspects, the present invention can be implemented only by using hardware, or by using software and a necessary general hardware platform. Based on this understanding, the technical solution of the present invention can be implemented in the form of a software product. The software product can be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash drive or a removable hard disk. The software product includes many instructions that enable a computer device (a personal computer, a server or a network device) to execute the methods provided in various aspects of the present invention. For example, such execution can correspond to the simulation of the logical operations described herein. According to various aspects of the present invention, the software product can additionally or alternatively include a plurality of instructions that enable a computer device to execute operations for configuring or programming a digital logic device.

[0099] Although the present invention has been described with reference to specific features and aspects of the present invention, it is obvious that various modifications and combinations can be made to the present invention without departing from the present invention. Therefore, the specification and the drawings are only regarded as an illustration of the present invention as defined by the appended claims, and it is expected to cover any and all modifications, variations, combinations or equivalents falling within the scope of the present invention.

Claims

1. A method, comprising: Receiving code including an annotated part and an unannotated part, the annotated part indicating the part for secure execution in the code; Constructing a trusted application (TA) corresponding to the annotated part in a trusted execution environment (TEE); And Constructing a client application (CA) corresponding to the unannotated part in a rich execution environment (REE).

2. The method according to claim 1, further comprising: Receiving, at the CA, a request to execute a function in the TA based on data included in the request; Sending the request from the CA to the TA; Executing the function at the TA based on the request to obtain a result; Sending the result from the TA to the CA; And Sending the result from the CA.

3. The method according to claim 1 or 2, wherein Sending the request from the CA to the TA includes: Serializing the data at the CA to obtain serialized data; and Sending the request including the serialized data from the CA to the TA.

4. The method according to any one of claims 1 to 3, wherein, Executing the function at the TA based on the request to obtain a result includes: Deserializing the serialized data at the TA to obtain the data; and Executing the function at the TA based on the data to obtain the result.

5. The method according to any one of claims 1 to 4, wherein, Sending the result from the TA to the CA includes: Serializing the result at the TA to obtain serialized result; and Sending the serialized result from the TA to the CA.

6. The method according to any one of claims 1 to 5, wherein Sending the result from the CA includes: Deserializing the serialized result at the CA to obtain data; and Sending the result from the CA.

7. The method according to any one of claims 1 to 6, further comprising: Establishing a communication channel between the CA and the TA; And Generating serialization functions and deserialization functions for use in the communication channel.

8. The method according to any one of claims 1 to 7, wherein Annotating the annotated part using in-file annotations or out-of-file annotations.

9. The method according to claim 8, wherein The out-of-file annotation is a meta-file of a defined domain-specific language (DSL).

10. The method according to claim 9, wherein, The meta-file of the DSL is a YAML file.

11. The method according to claim 8, wherein, The in-file annotation is in the form of MACRO, C++ custom attribute, or Doxygen parameter.

12. The method according to any one of claims 1 to 11, wherein, The annotated part includes one or more of classes and functions.

13. The method according to any one of claims 1 to 12, wherein, The TEE is the TEE of TrustZone.

14. An apparatus, comprising: At least one processor; And At least one machine-readable medium storing executable instructions that, when executed by the at least one processor, configure the apparatus to perform any one of method claims 1 to 13.

15. A computer device including a non-transitory computer-readable medium, on which instructions are stored, and the instructions, when executed by a computer processor, cause the computer to perform the method according to any one of claims 1 to 13.

Images