WO2019137614A1

WO2019137614A1 - Apparatus and method for runtime integrity protection for execution environments

Info

Publication number: WO2019137614A1
Application number: PCT/EP2018/050746
Authority: WO
Inventors: Vijayanand NAYANI; Sampo Sovio; Gang LIAN; Meilun XIE; Mu Yang; Liming Wu; Hui Li
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-01-12
Filing date: 2018-01-12
Publication date: 2019-07-18

Abstract

A processor to provide a secure execution environment including a secure mutable memory and a secure immutable memory. The processor loads a target application into a rich execution environment, and determine a baseline value of the loaded application. The baseline value is stored in the secure immutable memory. The processor determines a runtime value of the target application, and stores the runtime value in the secure mutable memory. A request for secure services is received from the target application within the secure execution environment. The processor determines whether a current state of the target application is consistent with a baseline state of the target application, where consistency is based on the stored baseline value and the stored runtime value. The request is processed when the current state is consistent with the baseline state, and/or an alarm procedure is executed when the current state and the baseline state are not consistent.

Description

APPARATUS AND METHOD FOR RUNTIME INTEGRITY PROTECTION FOR

EXECUTION ENVIRONMENTS

TECHNICAL FIELD

[0001] The aspects of the present disclosure relate generally to mobile computing devices and more particularly to data security in mobile computing devices.

BACKGROUND

[0002] Mobile computing devices, or mobile devices, which can include smart phones and tablets, etc., are experiencing an increase in the number and types of secure transactions being performed, such as for example payment processing, banking, retail purchases, etc. As the number and type of secure transactions increases so does the need for strong security to protect confidential information stored on these mobile computing devices.

[0003] A conventional approach to protecting confidential information and processes in mobile devices is to configure the devices to include multiple execution environments. One such execution environment, referred to as a rich execution environment (REE) or a normal world environment, is included to run feature rich user applications requiring friendly graphical interfaces and a wide range of functionality. The REE usually runs a fully featured operating system (OS) or application framework. These fully featured OS are often large and complex making it difficult to secure them. A separate secure execution environment (SEE) having a small secure OS is included for highly secure tasks such as cryptographic operation that rely on private or secret keys. Each execution environment is kept separate through both hardware and software techniques. This prevents applications executing in the REE from accessing or modifying confidential material protected within the SEE.

[0004] User applications running in the REE typically send requests for secure operations to a secure client application executing in the SEE through well-defined and protected communication channels. In this way access to secure material and functionality residing in the SEE is provided only to known applications executing in the REE. However, a known application that has been infected by a malicious software virus or that has become otherwise corrupted may inadvertently be allowed access to secure functionality or material based only on its identity. There is currently no way for secure or trusted applications executing in the SEE to assess the integrity or state of an application running the REE. This exposes a significant security risk where trusted applications may be performing protected operations for an infected or otherwise compromised user application. Thus there is a need for improved apparatus and methods to allow trusted applications executing within a secure execution environment to assess the integrity of user applications before performing secure services.

[0005] Accordingly, it would be desirable to provide methods and apparatus that address at least some of the problems identified above.

SUMMARY

[0006] It is an object of the disclosed embodiments to provide improved methods and apparatus that can efficiently, securely, and reliably provide information about the integrity of user applications to trusted applications executing within a secure execution environment. [0007] According to a first aspect the above and further objects and advantages are obtained by a processor configured to provide a rich execution environment and a secure execution environment. The secure execution environment includes a secure mutable memory and a secure immutable memory and the rich execution environment includes a user memory. The mutable and immutable memory are protected from access or modification by applications executing within the rich execution environment. The processor is configured to load a target application into the memory within the rich execution environment, and determine a baseline measured value corresponding to the loaded target application. The baseline measured value is sent to an appraisal process that is executing within the secure execution environment and the processor stores the baseline measured value in the secure immutable memory within the secure execution environment. The processor is configured to determine, within the rich execution environment, a runtime measured value corresponding to the target application, send the runtime measured value to the appraisal process, and store the runtime measured value in a secure mutable memory within the secure execution environment. The processor receives, in a client application, a request for secure services from the target application, wherein the client application is executing within the secure execution environment. The processor notifies the appraisal process about the request for secure services, determines within the appraisal process, whether a current state of the target application is consistent with a baseline state of the target application, wherein the consistency determination is based on the stored baseline measured value and the stored runtime measured value. The processor processes the request for secure services when the current state is consistent with the baseline state, and/or executes an alarm procedure when the current state and the baseline state are not consistent. In this manner information about the integrity of user applications is provided to trusted applications executing within a secure execution environment.

[0008] In a first possible implementation form of the processor according to the first aspect the processor is configured to prevent modification of the stored baseline measured value until the processor is restarted. Preventing modification of the baseline measured value ensures a malicious application cannot make alterations to the baseline measured value, and that the runtime measured values are always compared to a known good baseline.

[0009] In a second possible implementation form the processor is configured to update the stored runtime measured value. Updating the stored runtime measured value includes determining, within the rich execution environment, a current runtime measured value corresponding to a current state of the target application, sending the current runtime measured value to the appraisal process within the secure execution environment, and updating the stored runtime measured value based on the current runtime measured value. Updating the runtime measured value stored in the secure execution environment ensures the appraisal process always has access to an up to date measurement of the target application thereby ensuring the integrity check represents the current state of the target application and not an older outdated state.

[0010] In a third possible implementation form the processor is configured to update the stored runtime measured value based on execution of a critical process by the target application. A critical process is one that uses secure services. Trigging an update of the runtime measured value when a critical process executes ensures the runtime measured value stored within the secure execution environment will accurately reflect the integrity of the target application when the critical process attempts to access secure services. [0011] In a fourth possible implementation form the processor is configured to update the stored runtime measured value periodically or aperiodically during execution of the target application. Updating the runtime measured value at various time intervals ensures the runtime measured value stored within the secure execution environment accurately reflects the integrity of a target application whenever a secure service is accessed.

[0012] In a fifth possible implementation form the processor is configured to, while executing the alarm procedure, perform one or more of modifying a set of rights of the target application, log audit information, broadcast an alarm message, shut down vital system services, and bring the apparatus to a dormant state. A flexible alarm procedure ensure confidential material can be appropriately protected in the event a problem with the integrity of the target application is detected.

[0013] In a sixth possible implementation form, the processor is configured to evaluate the baseline measured value based on a signed baseline file prior to storing the baseline measured value in the secure immutable memory. Evaluation of a cryptographically secure signature ensures the initial form of the loaded target application is consistent with the form that was intended by the distributor of the target application.

[0014] In a seventh possible implementation form the processor is configured to determine when to measure the target application based on a policy information file, wherein the policy information file comprises information about one or more of which target applications should be measured, when the target application should be measured, and how the target application should be measured. The use of a policy information file provides flexibility of when, how, and what applications should be measured. This is advantageous as a way to conserve processing resources for example by measuring only those applications that pose an unacceptable security risk, reducing the frequency of measurement of low risk applications, and/or using more reliable but computationally more intensive measurement techniques only on high risk applications.

[0015] In a second aspect of the present disclosure the above and further objects and advantages are obtained by a method that loads a target application into a user memory within a rich execution environment, determines a baseline measured value corresponding to the loaded target application and stores the baseline measured value in a secure immutable memory within a secure execution environment. The method then determines, within the rich execution environment, a runtime measured value corresponding to the target application, and stores the runtime measured value in a secure mutable memory within the secure execution environment.

The method receives within the secure execution environment a request for secure services from the target application, determines within the secure execution environment whether a current state of the target application is consistent with a baseline state of the target application. This consistency determination is based on the stored baseline measured value and the stored runtime measured value. The method processes the request for secure services when the current state is consistent with the baseline state, and/or executes an alarm procedure when the current state and the baseline state are not consistent. In this manner information about the integrity of user applications is provided to trusted applications executing within a secure execution environment.

[0016] In a first possible implementation form of the method according to the second aspect the method includes storing the baseline measured value when the target application is loaded into user memory, and the stored baseline measured value is not modified. By keeping the baseline measured value constant while the target application is loaded in memory ensures that any changes to the form of the target application can be reliably detected.

[0017] In a second possible implementation form the method includes updating the stored runtime measured value. Updating the stored runtime measured value includes determining, within the rich execution environment, a current runtime measured value corresponding to a current state of the target application, and updating the stored runtime measured value based on the current runtime measured value. Updating the runtime measured value stored in the secure execution environment ensures the appraisal process always has access to an up to date measurement of the target application thereby ensuring the integrity check represents the current state of the target application and not an older outdated state.

[0018] In a third possible implementation form executing the alarm procedure includes one or more of modifying a set of rights of the target application, logging audit information, broadcasting an alarm message, shutting down vital system services, and bringing the apparatus to a dormant state. A flexible alarm procedure ensures confidential material can be appropriately protected in the event a problem with the integrity of the target application is detected.

[0019] In a fourth possible implementation form the method includes determining when to measure the target application based on a policy information file, wherein the policy information file comprises information about one or more of which target applications should be measured, when a target application should be measured, and how a target application should be measured. This is advantageous as a way to conserve processing resources for example by measuring only those applications that pose an unacceptable security risk, reducing the frequency of measurement of low risk applications, and/or using more reliable but computationally more intensive measurement techniques only on high risk applications.

[0020] These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which:

[0022] Figure 1 illustrates a block diagram of an exemplary computing apparatus configured to provide run-time integrity protection for execution environments in accordance with aspects of the disclosed embodiments.

[0023] Figure 2 illustrates a block diagram of an exemplary computing apparatus appropriate for implementing aspects of the disclosed embodiments. [0024] Figure 3 illustrates a flow chart of a method for providing run-time integrity checking incorporating aspects of the disclosed embodiments.

[0025] Figure 4 illustrates a flow chart of an exemplary alarming procedure in accordance with the aspects of the disclosed embodiments. DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

[0026] Figure 1 illustrates a block diagram of an exemplary apparatus 100 configured to provide run-time integrity protection for execution environments (RIPE). A processor 150 is adapted to access a memory 152 that is configured to store program instructions. When the program instructions are executed by the processor 150, the processor 150 is caused to perform useful methods and processes for RIPE as described herein.

[0027] As will be discussed further below the processor 150 and memory 152 are configured to support a rich execution environment (REE) 102 and a secure execution environment (SEE) 104. The SEE 104 is logically and/or physically isolated from the REE 102 such that data and programs executing within the SEE 104 are isolated from and protected from access or modification by programs executing within the REE 102. The SEE 104 is configured to protect the integrity and confidentiality of data and programs stored and/or executing within the SEE 104. The SEE 104 may be implemented by any appropriate technology such as a trusted execution environment or trust zone.

[0028] In the example shown in Figure 1, the secure execution environment 104 comprises a secure mutable memory 126 and a secure immutable memory 124. The rich execution environment 102 comprises a user memory 152. The secure mutable memory 126 and the secure immutable memory 124 are protected from access or modification by applications executing within the rich execution environment 102.

[0029] In one embodiment the processor 150 is configured to load a target application

106 into the user memory 152 within the rich execution environment 102 and determine a baseline measured value corresponding to the loaded target application 106. The processor 150 sends the baseline measured value to an appraisal process 118 that is executing within the secure execution environment 104 and store the baseline measured value in the secure immutable memory 124 within the secure execution environment 104.

[0030] The processor 150 is also configured to determine, within the rich execution environment 102, a runtime measured value corresponding to the target application 106 and send the runtime measured value to the appraisal process 118. The runtime measured value is stored in the secure mutable memory 126 within the secure execution environment 104.

[0031] In one embodiment, a client application 120 executing within the secure execution environment 102 receives a request for secure services from the target application 106. The client application 120 notifies the appraisal process 118 about the request for secure services and determines within the appraisal process 118 whether a current state of the target application 106 is consistent with a baseline state of the target application 106. The consistency determination is based on the stored baseline measured value and the stored runtime measured value and the request for secure services is processed when the current state is consistent with the baseline state. In one embodiment, an alarm procedure 128 is executed when the current state and the baseline state are not consistent. [0032] To ensure integrity and isolation of the SEE 104, communication 130 between the

REE 102 and the SEE 104 is carefully controlled. In certain embodiments a software driver or trust zone (TZ) driver 112 may be used to manage communication between the REE 102 and the SEE 104. To prevent corruption of the communications 130 or TZ driver 112 it may be desirable to execute the TZ driver 112 within an operating system kernel 110 process or at a privilege level that is the same as or more secure than the operating system (OS) or kernel 110. This prevents target applications 106 executing at a privilege level that is more restrictive than the OS privilege level from accessing or corrupting the OS or other components such as the TZ driver 112.

[0033] Target applications 106 executing in the REE 102 often need to perform secure operations such as encryption, decryption, or signing. For example a target application 106 such as a media player application, may need to decrypt data necessary to play music or movie files, or a banking application may need to encrypt information before sending it over the internet. When a target application 106 requires a secure operation it is often the case that a request for secure services 136 is sent to a trusted client applications 120 executing within the SEE 104. It should be noted that the trusted client 120 is a client application is a client from the perspective of the RIPE appraisal component 118 but is a server from the perspective of the target application 106. The term trusted client 10 is used to emphasize the novel features provided by the RIPE appraisal process 118 as will be discussed further below. The request may be sent via a TZ driver 112 as illustrated in the apparatus 100. Alternatively the request 136 may be sent directly without participation of a TZ driver 112. The trusted client 120 can then service the request 134 and return a result thereby preventing any confidential material, such as private keys and the sensitive cryptographic algorithms necessary for the secure operations, from being exposed outside the SEE 104.

[0034] A target application 106 may communicate with a client 120 by establishing a secure communication link 130 and sending 136 requests and receiving responses 134 to/from the trusted client 120. In certain embodiments a smaller, more easily controlled, critical process 108 running within or on behalf of the target application 106 may be used to send secure requests 138 from the target application 106 to the client 120.

[0035] Controlling access to the SEE 104 with a communication link 130 provides trusted applications, such as the trusted clients 120, a certain degree of assurance about the source of the communication, however there is no way for applications executing within the SEE 104 to obtain current information about the integrity or sanity of the target application 106 or critical process 108 at the time the requests 136, 138 are being received. The target applications 106 that are requesting secure services may have been infected by a virus or otherwise modified by malicious attacks. The trusted client 120 will not be able to detect these attack. Thus, a request for secure services, that may appear to be a valid by virtue of the sending application, may actually be an attack coming from an infected or otherwise corrupted target application 106.

[0036] To overcome this problem, the apparatus 100 includes a RIPE system that in one embodiment includes a RIPE appraisal component 118 executing within the SEE 104 and a RIPE measurement component executing within the REE. The RIPE measurement process 114 generates measurements of the target application 106 and/or critical process 108. These measurements are securely sent to the RIPE appraisal component 118 where, as will be discussed in more detail below, they are stored in protected areas of the SEE memory 124, 126. These two sets of measurements are consumed by the RIPE appraisal component 118 and used to determine information 142 about the integrity of a target application 106. This integrity information is made available to a trusted client application 120 that will use the integrity information to make decisions on how to handle requests for secure operations 136, 138 received from the target application 106.

[0037] The RIPE appraisal component 118 receives measurements from a RIPE measurement component 114 running at an elevated privilege level within the REE 102, such as part of the kernel 110 or other protected software component executing in the REE. The RIPE measurement component 114 generates a baseline measured value or measurement of the target application 106 when the target application 106 is first loaded into memory. In certain embodiments it is advantageous to validate the baseline measurement using a cryptographically signed installation file or other signed information file 160 associated with the target application 106. As used herein the terms signed and signature refer to a cryptographic signature obtained by any appropriate cryptographic process and configured to allow cryptographic validation of data in the signed file 160.

[0038] This baseline measurement is sent to the RIPE appraisal component 118 executing within the SEE 104 where the baseline measurement is stored in the secure immutable area 124 of the SEE 104. This immutable memory 124 is protected from modification in order to keep the baseline measured value from being modified. The baseline measured values stored in the immutable memory 124 are kept constant as long as the device is powered on. In certain embodiments it is advantageous to re-initialize the immutable memory 124 when the device is re-booted, alternatively the baseline measured value may be kept constant during the time the target application 106 is loaded in user memory 152. These immutable measurements become the baseline or golden values that can be later used as a basis of integrity determinations.

[0039] The RIPE measurement component 114 makes run-time measurements of the target application 106 at critical points during execution of the target application 106, such as when a session 130 is established with the SEE 104, or when a critical process 108 is started.

These run-time measurements are sent to the RIPE appraisal component 118 where they are stored in the mutable and continuously updated memory area 126 within the SEE 104 used to hold the run-time values.

[0040] The term "critical process" as used herein refers to a software component executing in the REE 102 that is associated with a target application 106 and has been assessed as having security implications. The critical process may be one or more software components running in the same process space as the target application 106 or in a different process space than the target application 106.

[0041] When the client application 120 receives a request for secure services 136, 138 it can contact a service or other software procedure or function exposed by the RIPE appraisal component 118 to check the integrity of the target application 106. The RIPE appraisal component 118 compares the most recent run-time measurement stored in the mutable run-time values memory area 126 with the golden value or baseline measurements stored in the immutable memory area 124 to determine whether the state or integrity of target application 106 has been compromised or corrupted. A change in the measured value may indicate the integrity of the target application is suspect or that the integrity check has failed. This integrity information is returned 142 to the client application 120 where the client application can decide how to proceed. [0042] When the integrity check fails the client application 120 may decide for example to log an audit record and proceed, refuse to process the request, pass control to an alarm procedure 128, or completely shut down the apparatus 100. Selection of the resulting action may be based on many factors such as the severity of the integrity problem or the type of the request 136, 138.

[0043] The RIPE system, which in the illustrated embodiment includes the RIPE components 114, 118, provides a mechanism for clients 120, such as secure trusted applications, running in an isolate environment, such as the SEE 104, to assess or verify the integrity of normal world applications, such as the target application 106 executing in the REE 102, before executing any secure operations on behalf of the real word applications. A SEE 104 is an example of, and may be referred to as, an isolated environment, and a REE 102 is an example of and may be referred to as a normal word environment. The RIPE system is illustrated using two components, RIPE measurement 114 and RIPE Appraisal 118, as an aide to understanding only. Those skilled in the art will readily recognize that a RIPE system may contain any desired number of components and have the described functionality distributed in any appropriate fashion among those one or more RIPE components without straying from the spirit or scope of the disclosed embodiments.

[0044] The tasks performed by RIPE can be more easily understood by viewing them in three distinct pieces or phases: baselining, measurement, and appraisal. Baselining is the generation of information corresponding to a valid program state and may be obtained when a target application 106 is first loaded from a file system into memory 152. Measurement is the collection of evidence from a current running instance of the target application 106. Appraisal is evaluation of the collected evidence or measurements against the baseline information.

[0045] Baselining can begin offline such as when an application is packaged for distribution. When the target application 106 is initially loaded it is important to determine what a valid running instance of the target application 106 should look like, i.e. what a valid measurement of the target application 106 should be when it is loaded into memory. Baseline values may be obtained in various ways, for example a cryptographic hash of the target application 106 may be obtained in an offline environment where integrity checks can be implemented. The offline generated content is then cryptographically signed with a private key and subsequently included as part of the RIPE system 160. When the target application 106 is loaded for the first time it can be verified using the cryptographically signed data 160. Measurements involving cryptography can be computationally expensive and in certain embodiments it is desirable to have a more easily computed measurement. To support this a less computationally intensive measure may be made of the loaded target application 106.

[0046] The initial measured value of the loaded target application 106 generated by the

RIPE measurement component 114 is sent 132 to the RIPE appraisal component 118 where it may be stored 146 in the immutable memory area 124 allocated within the SEE 104. This initial measured value, referred to as a golden value or baseline measured value, is used as the reference golden value for the target application 106. The reference golden value remains constant and never changes while the target application 106 remains loaded in memory 152. The baseline measurement may be reset such as during a reboot or power cycle of the apparatus 100. [0047] In certain embodiments the RIPE system is configured to store a reference baseline value of the target application 106 within the SEE 104 when the target application 106 is installed on the apparatus 100. The initial measure value may then be compared to the reference baseline value as an initial integrity check prior to storing the initial measured value in immutable memory area 124.

[0048] During the measurement phase the state of the running instance of the target application 106 is inspected and a run-time measurement is generated. The run-time measurement, generated by the RIPE measurement component 114 is sent 132 to the RIPE appraisal component 118 where it is stored in the SEE 104 in a mutable memory area 126 allocated for storage of the run-time values. The run-time values are updated throughout execution of the target application 106 thereby maintaining a current and up to date measure of the running target application 106. Updating of the run-time measurement may be performed based on time intervals or at critical points in execution of the target application 106 such as when the target application creates a session with the SEE 104, launches a critical process 108, or requests certain secure services.

[0049] It can be advantageous in certain embodiments for the RIPE system to maintain policy information 122 that may be used to guide the RIPE appraisal component 118 and the RIPE measurement component 114. In one embodiment the policy information 122 may include information indicating which target applications should be monitored by the RIPE measurement 114 and RIPE appraisal 118 components. Alternatively, or in addition, the policy information

122 may provide information about when and how to measure a target application. For example it may be desirable to measure some target applications 106 or types of target applications 106 continually at intervals, while other target applications 106 may only be measured when they access secure services. Certain target applications 106 may require an in depth and expensive measurement be used while a simpler less computationally expensive measurement may be adequate for other target applications 106.

[0050] The appraisal phase consumes the run-time generated measurement data 132 and compares them with the baseline measured value 124 of the target application 106 to determine whether the observed state is consistent with the original or baseline state of the target application 106. The run-time measurements 126 generated by the RIPE measurement component 114 throughout execution of the target application 106 will be compared against the baseline or golden values 124 that were stored when the target application 106 was initially loaded into memory 152 to determine integrity of the target application 106.

[0051] Appraisal is done when a client 120, such as a trusted application executing within the SEE 104, receives a request for secure services from a target application 106. The client 120 may notify, or send a request for appraisal information to the RIPE appraisal component 118. The RIPE appraisal process or component 118 can then compare the current run-time measurement 126 corresponding to the target application 106 with the baseline or golden value. This comparison can be used as the basis of an integrity determination. For example in certain embodiments the integrity determination may be determined to be good when the current state of the target application 106, as indicated by the run-time measurement, is consistent with the baseline state of the target application 106 as indicated by the baseline or golden value. Otherwise when the current and baseline states are not consistent the integrity is determined to be not good. [0052] In one embodiment decisions about how to handle good and not good integrity determinations are made in the client application 120. Alternatively, decisions about processing of the integrity determinations may be handled in the RIPE appraisal component 118 or distributed between both the client 120 and the RIPE appraisal component 118. When the state or integrity of the target application 106 is determined to be good, the request for secure services may be processed and the result returned to the target application 106. Optionally it may be advantageous to log audit information for every integrity check to record information such as results of the integrity check, secure services accessed, as well at other information about the request and returned result.

[0053] When the integrity of the target application is determined to be not good, meaning the state of the target application 106 is different than the baseline or golden state, processing of the request for secure services may be aborted and control may be passed 140 to an alarming procedure 128. The alarming procedure 128 may be configured to take any desired corrective action, such as modifying policies 122 or a set of rights associated with the target application 106, broadcasting an alarm message to other processes executing on the apparatus 100, logging of audit information, shutting down sensitive or vital system services, or bringing the apparatus 100 to a dormant state.

[0054] Figure 2 illustrates a block diagram of an exemplary computing apparatus 200 configured to provide a REE 102 and a SEE 104 appropriate for use as the REE 102 and SEE 104 described above and with reference to Figure 1. The computing apparatus 200 may be incorporated into various types of computing apparatus such as mobile phones, phablets, tablet computers, laptop computers, set top cable boxes, televisions, automobiles, etc., and can be advantageously employed to provide run-time integrity protection for execution environments within the computing apparatus 200.

[0055] The REE 102 is configured to provide a broad range of functionality and features to support a wide variety of applications with an enhanced user experience. However, due to this enhanced feature set and rich functionality the REE 102 is inherently less secure than the SEE 104 and cannot safely perform cryptographic operations without risking loss of confidentiality or integrity of the cryptographic keys and data. Examples of rich execution environments are those offered by operating systems (OS) such as the Android OS developed by GOOGLE™, and iOS developed by APPLE™, or the widely distributed LINUX OS.

[0056] In the example of Figure 2, the computing apparatus 200 includes a processor 210 coupled to a memory 212 where a first portion of the processor 202 and a first portion of the memory 204 are configured to support a SEE 104. A second portion of the processor 206 and a second portion of the memory 208 are configured to support a REE 102.

[0057] The processor 210 may be a single processing device or may comprise a plurality of processing devices including special purpose devices, such as for example, digital signal processing (DSP) devices, microprocessors, specialized processing devices, parallel processing cores, or general purpose computer processors. The processor 210 is configured to read non transient program instructions from a memory 212 and perform any of the methods and processes described herein. The processor (210) may also include a CPU working in tandem with a graphics processing unit (GPU) which may include a DSP or other specialized graphics processing hardware. [0058] The memory 212 may be a combination of various types of volatile and non volatile computer memory such as for example read only memory (ROM), random access memory (RAM), magnetic or optical disk, or other types of computer memory. The secure portion of memory 204 may include a one-time programmable memory configured to protect confidential data.

[0059] The SEE 104 is configured to ensure the confidentiality and integrity of data and computer program instructions stored within SEE memory 204, and to protect the confidentiality and integrity computer programs and associated data executing within the secure portion of the processor 202. The SEE 104 may be implemented for example using various technologies such as a trusted execution environment (TEE) or other suitable technology adapted to provide both a REE 102 and a SEE 104 within a computing device 200.

[0060] To maintain a security boundary between the SEE 102 and REE 104 the REE portion of the processor 206 is allowed access 218 only to the REE portion of the memory 208. Because the SEE 104 is a secure environment, the SEE portion of the processor 202 is allowed to access 214 the secure portion of the memory 204 and is also allowed to access 216 to the REE portion of memory 208.

[0061] Figure 3 illustrates a flow chart describing a method 300 for providing run-time integrity checking, referred to herein as RIPE, appropriate for use in mobile computing apparatus such as for example the computing apparatus 100 described above and with reference to Figure 1. The RIPE method or system 300 may be viewed as having three phases: baselining 350, measurement 352, and appraisal 354. [0062] Baselining 350 is used to determine what a running instance of a target application should look like when loaded in a computer memory. Baselining 350 may begin offline in a secure environment where a cryptographic hash of the target application may be generated. Integrity checking of the application may be performed during generation of the hash to ensure correctness. The generated content is then cryptographically signed and installed as part of the RIPE system.

[0063] The measurement phase 352 includes the collection of evidence or measured values from a current running instance of a target application. During the measurement phase 352 a running instance of the target application is inspected and a run-time measured value is generated. The run-time measured value is a representation of the state of the target application at the time the measurement was generated.

[0064] The appraisal phase 354 compares the run-time measured value to data computed from the baseline information to determine the integrity of the running application. This integrity information may then be used to determine whether a request for secure information or processing should be honored or declined.

[0065] The RIPE method 300 begins when a target application is loaded 302 within a computing apparatus. Loading refers to the process of preparing a target application for execution and may for example entail copying the program code and data from a file into computer memory and initializing any associated memory that will be used by the target application.

[0066] A baseline measured value is then generated or determined 304 for the loaded instance of the target application. This baseline measured value may be determined from the in- memory image of the target application, information cryptographically embedded in a corresponding file, or other information stored in the RIPE system when an application is installed on the computing apparatus or device.

[0067] An immutable area of secure memory, such as memory protected within a SEE, is then used to store 306 the baseline measured value. The baseline measured value is treated as a golden value corresponding to a known good state of the target application and remains unchanged as long as the computing apparatus is running. The immutable memory area is protected within a secure execution environment where it cannot be accessed or tampered with and will remain constant until the computing apparatus is rebooted. In certain embodiments it may be desirable to remove the baseline value from the immutable memory area when a target application is unloaded or removed from memory. When this is the case a new baseline value may be generated 304 and stored 306 the next time the target application loaded 302.

[0068] Once the baseline value is stored 306 the RIPE system enters the measurement phase 352 where a run-time measured value is determined 308. Determination 308 of a run-time measured value may be triggered by critical events in the execution of the target application, such as creation of a secure session between a REE and a SEE, starting of a critical process by the target application, etc. Alternatively, determination 308 of a run-time measured value may be scheduled based on time or other pre-determined criteria.

[0069] The run-time measured value is then stored 310 in a mutable secure memory area, such as an area of memory protected within a SEE. The measurement phase 352 may be repeated 322 many times during execution of a target application. Thus a new run-time measured value may repeatedly be determined 308 and stored 310 throughout execution of a target application. This ensures the stored run-time measured value accurately represents a current state of the target application.

[0070] In one embodiment it is desirable to employ a policy information file that includes information to guide the RIPE processing. The policy information file may influence all phases of the RIPE method. For example the policy information file may specify which target applications should be measured by the RIPE system. Alternatively, the policy information file may be used to influence the measurement phase by specifying when, such as at what critical points or time intervals etc., run-time measurements should be determined 308 and stored 310. It may also be advantageous to use a policy information file to influence the integrity determination 316, such as specifying how the integrity determination should be made, and/or to influence the alarm procedure 320 to be followed when an integrity check 316 fails.

[0071] During operation of a computing apparatus, a request for secure services may be received 312 by a trusted application or client executing within a SEE. The client may then contact the RIPE appraisal subsystem, which is also executing with the SEE, to determine 314 the integrity of the target application that generated the request for secure services. The RIPE appraisal subsystem determines 314 the integrity of the target application by comparing a run time measurement corresponding to the target application to the baseline or golden value stored when the target application was loaded.

[0072] A decision 316 is made based on the outcome of the integrity determination 314. When the state of the target application is determined to be good, the request for secure services may be processed 318. When the integrity of the target application is determined 316 to be not good, i.e. the integrity check 316 fails, control may be passed to an alarm procedure 320. As will be discussed further below, the alarm procedure 320 may take one or more actions determined to mitigate risks caused by a target application that has been compromised.

[0073] Figure 4 illustrated a flow chart of an exemplary alarm procedure appropriate for use in the method 300 described above. When an integrity check fails, indicating the state of a target application that is requesting secure services is not consistent with the baseline state maintained by the RIPE system, a secure client application may decide to take actions to mitigate any harm or risks that may result from an infected or otherwise compromised target application by initiating 450 an alarm procedure 400. The alarm procedure includes one or more actions 402, 404, 406, 408, 410 that may be taken when an integrity check fails. It may be desirable to modify any rights 402 or other security policies associated with a target application when an integrity check fails. For example a target application that is prone to frequent corruption may pose an undesirable security risk and as such it may be desirable to limit the applications access to secure operations. It may also be desirable to update the RIPE policy file, such as the policy file 122 described above, to increase the frequency of run-time measurements as a way to reduce the opportunity for an infected application to cause harm.

[0074] In many embodiments it is desirable to log audit information 404 when an integrity check fails. This audit information may include for example an identification of the target application, the secure services being requested, the time at which the failure was detected, etc. Any information that may be useful for later analysis and root cause identification may be logged.

[0075] An alarm message may be broadcast 406 to applications that are using or providing secure services making them aware of an integrity issue and perhaps causing them to run their own integrity checks. It may also be advantageous to shut down 408 some vital services or highly secure processes in order to protect them from attacks. In extreme cases it may be desirable to cause the entire computing apparatus to go dormant 410 in order to prevent loss or corruption of any confidential material or algorithms stored in the SEE. The actions 402, 404, 406, 408, 410 illustrated in the exemplary alarm procedure 400 are provided only as an aide to understanding, and those skilled in the art will readily recognize that other actions may be implemented in an alarm procedure without straying from the spirit and scope of the disclosed embodiments.

[0076] Thus, while there have been shown, described and pointed out, fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that various omissions, substitutions and changes in the form and details of apparatus and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Further, it is expressly intended that all combinations of those elements, which perform substantially the same function in substantially the same way to achieve the same results, are within the scope of the invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims

What is claimed is:

1. An apparatus (100) comprising a processor (150) coupled to a memory (152) wherein the processor (150) and the memory (152) are configured to provide a rich execution environment (102) and a secure execution environment (104) and wherein the secure execution environment (104) comprises a secure mutable memory (126) and a secure immutable memory (124), the rich execution environment (102) comprises a user memory (152), wherein the secure mutable memory (124) and the secure immutable memory (124) are protected from access or modification by applications executing within the rich execution environment (102), and wherein the processor (150) is configured to: load a target application (106) into the user memory (152) within the rich execution environment (102);

determine a baseline measured value corresponding to the loaded target application

(106);

send the baseline measured value to an appraisal process (118), wherein the appraisal process (118) is executing within the secure execution environment (104);

store the baseline measured value in the secure immutable memory (124) within the secure execution environment (104);

determine, within the rich execution environment (102), a runtime measured value corresponding to the target application (106);

send the runtime measured value to the appraisal process (118); store the runtime measured value in the secure mutable memory (126) within the secure execution environment (104);

receive, in a client application (120), a request for secure services from the target application (106), wherein the client application (120) is executing within the secure execution environment (102);

notify the appraisal process (118) about the request for secure services; determine within the appraisal process (118), whether a current state of the target application (106) is consistent with a baseline state of the target application (106), wherein the consistency determination is based on the stored baseline measured value and the stored runtime measured value; and

process the request for secure services when the current state is consistent with the baseline state; and/or

execute an alarm procedure (128) when the current state and the baseline state are not consistent. 2. The apparatus (100) according to claim 1 wherein the processor (150) is configured to prevent modification of the stored baseline measured value until the processor (150) is restarted.

3. The apparatus (100) according to claims 1 or 2 wherein the processor (150) is configured to update the stored runtime measured value, wherein updating the stored runtime measured value comprises:

determining, within the rich execution environment (104), a current runtime measured value corresponding to a current state of the target application (106); sending the current runtime measured value to the appraisal process (118) within the secure execution environment (104); and

updating the stored runtime measured value based on the current runtime measured value. 4. The apparatus (100) according to any one of the preceding claims wherein the processor (150) is configured to update the stored runtime measured value based on execution of a critical process (108) by the target application.

5. The apparatus (100) according to any one of the preceding claims wherein the processor (150) is configured to update the stored runtime measured value periodically or aperiodically during execution of the target application.

6. The apparatus (100) according to any one of the preceding claims wherein the processor (150) is configured to, while executing the alarm procedure, perform one or more of: modify a set of rights of the target application, log audit information, broadcast an alarm message, shut down vital system services, and bring the apparatus (100) to a dormant state. 7. The apparatus (100) according to any one of the preceding claims wherein the processor (150) is configured to evaluate the baseline measured value based on a signed baseline file prior to storing the baseline measured value in the secure immutable memory (124).

8. The apparatus (100) according to any one of the preceding claims wherein the processor (150) is configured to determine when to measure the target application (106) based on a policy information file (122), wherein the policy information file (122) comprises information about one or more of: which target applications should be measured, when the target application (106) should be measured, and how the target application (106) should be measured.

9. A method (400) comprising:

loading (402) a target application into a user memory within a rich execution environment;

determining (404) a baseline measured value corresponding to the loaded target application;

storing (406) the baseline measured value in a secure immutable memory within a secure execution environment;

determining (408), within the rich execution environment, a runtime measured value corresponding to the target application;

storing (410) the runtime measured value in a secure mutable memory within the secure execution environment;

receiving (412) within the secure execution environment a request for secure services from the target application;

determining (414) within the secure execution environment, whether a current state of the target application is consistent with a baseline state of the target application, wherein the consistency determination is based on the stored baseline measured value and the stored runtime measured value; and processing (418) the request for secure services when the current state is consistent with the baseline state; and/or

executing (420) an alarm procedure when the current state and the baseline state are not consistent. 10. The method of claim 9 wherein the baseline measured value is stored (406) when the target application is loaded (402) into user memory, and the stored baseline measured value is not modified.

11. The method of claims 9 or 10 comprising updating the stored runtime measured value, wherein updating the stored runtime measured value comprises:

determining, within the rich execution environment, a current runtime measured value corresponding to a current state of the target application; and

updating the stored runtime measured value based on the current runtime measured value.

12. The method of any of the preceding claims 9 through 11 comprising updating the stored runtime measured value based on execution of a critical process by the target application.

13. The method of any of the preceding claims 9 through 12 wherein executing (420) the alarm procedure comprises one or more of: modifying a set of rights of the target application, logging audit information, broadcasting an alarm message, shutting down vital system services, and bringing the apparatus to a dormant state.

14. The method of any of the preceding claims 9 through 13 comprising determining when to measure the target application based on a policy information file, wherein the policy information file comprises information about one or more of: which target applications should be measured, when a target application should be measured, and how a target application should be measured.

15. A computer program product comprising non-transitory computer program instructions that when executed by a processor (150) are configured to cause the processor (150) to perform the method according to any of claims 9 through 14.

16. A processor (150) configured to provide a rich execution environment (102) and a secure execution environment (104), the secure execution environment (104) comprising a secure mutable memory (126) and a secure immutable memory (124), the rich execution environment (102) comprising a user memory (152), wherein the secure mutable memory (126) and secure immutable memory (124) are protected from access or modification by applications executing within the rich execution environment (102), and wherein the processor (150) is configured to:

load a target application (106) into the user memory (152) within the rich execution environment (102);

(106);

send the baseline measured value to an appraisal process (118), wherein the appraisal process (118) is executing within the secure execution environment (104); store the baseline measured value in the secure immutable memory (124) within the secure execution environment (104);

send the runtime measured value to the appraisal process (118);

store the runtime measured value in the secure mutable memory (126) within the secure execution environment (104);

notify the appraisal process (118) about the request for secure services;

determine within the appraisal process (118), whether a current state of the target application (106) is consistent with a baseline state of the target application (106), wherein the consistency determination is based on the stored baseline measured value and the stored runtime measured value; and

execute an alarm procedure (128) when the current state and the baseline state are not consistent.