Patent Description:
A secure element (SE) is a tamper-resistant platform (typically a discrete integrated circuit secure microcontroller) capable of securely hosting and executing applications and confidential and cryptographic data for the hosted applications in accordance with the rules and security requirements set by well-identified trusted authorities. As one example, one of the hosted applications could be implemented as Java Card.

In some examples, an SE can be removable from another computing device. For example, an SE can be implemented as a removable subscriber identity module (SIM) card installed on a smart phone. Alternatively, the SE can be an embedded secure element (eSE) that is wired to another computing device. In still other examples, the SE can be an integrated secure element (iSE) that is directly integrated with a System on a Chip (SoC) hardware design. In this last case, the SE does not operate as a stand-alone device. Rather, the SE includes (secure) microprocessor and/or a (secure) microcontroller that is part of the design of a single integrated circuit to combine secure and non-secure processing environments.

A trusted execution environment (TEE) is a secure area of a main processor. A TEE ensures code and data loaded within the TEE is protected with respect to confidentiality and integrity. Thus, a TEE provides an isolated execution environment that provides security features, such as isolated execution and integrity of applications executing with the TEE, along with confidentiality of assets of the applications executed by the TEE. In general terms, the TEE offers an execution space that provides a higher level of security than a rich execution environment (REE), which REE may execute applications through a general purpose operating system (OS), such as a user-facing OS.

A botnet is a logical collection of internet-connected devices such as computers, smartphones or Internet of Thing (loT) devices whose security has been breached and control ceded to a third party. Each such compromised device, known as a "bot", is created when a device is penetrated by software from a malware (malicious software) distribution. The controller of a botnet is able to direct the activities of these compromised computers through communication channels formed by standards-based network protocols such as Internet Relay Chat (IRC) and Hypertext Transfer Protocol (HTTP). As the ubiquity of loT devices continues to grow, the dangers of botnets grow as well. In fact, the problems with botnets are so pervasive, that a botnet operating on loT refrigerators was lampooned on the television series, Silicon Valley.

<CIT> teaches to maintain security of a device, such as a mobile device, via a heartbeat signal. As long as the heartbeat signal is detected, the device is allowed to perform operations. If the heartbeat signal is not detected, appropriate action is taken. Appropriate action can include powering down the device, restricting access to files, erasing files, erasing the contents of a disk on the device, preventing access to designated files, reporting the location of the device, and/or preventing the device from being turned on after it is turned off. In an example configuration, the heartbeat signal is a low-power consuming, low data rate, signal allowing for processing of the heartbeat signal to be accomplished, at least in part, via the SIM of the device.

<CIT> discloses techniques for providing security to a wireless transmit receive unit (WTRU). A software vulnerability ticket (SVT) may be received by a WTRU. The SVT may include a location to fetch software update information, content of the software update information, and/or an indication that an update is not available. The SVT may be stored in a memory associated with the WTRU. It may be determined (e.g., by a security agent associated with the WTRU) whether the WTRU has a fresh SVT. A security agent may run in a secure execution environment on the WTRU. The secure execution environment may not be dependent on a main operating system associated with the WTRU. If it is determined that the WTRU has a fresh SVT, a security update may be performed. If it is determined that the WTRU does not have a fresh SVT, a recovery procedure may be executed.

<CIT> discloses a method of automatically locking a client. The method includes a step of a client automatically establishing a heartbeat interval. A determination can be automatically made regarding whether a proper server response is received within the heartbeat interval. When no proper response is received, the client can be automatically placed in a locked state. All client functions accessible by a user other than those functions relating to unlocking the client can be disabled while the client is in the locked state. A remotely located server can unlock the client by conveying an unlock message to the client.

The invention is defined by the independent claims, taking due account of any element which is equivalent to an element specified in the claims.

One example relates to a method for establishing and maintaining a security policy for a device and can include establishing a secure channel between a secure execution environment (SEE) operating on the device and a security entity external to the device. The method can also include configuring, by a security manager executing on the SEE, access to sensitive operations of an environment interactor coupled to the device based on a security policy provided from the security entity. The method can further include resetting, by the security manager, a secure watchdog timer in response to a reset authorization token provided from the secure entity. If the secure watchdog timer expires a given predetermined number of times since a last reset authorization token is received, the security manager can execute a given prescriptive operation dictated by the security policy.

Another example relates to a non-transitory computer-readable storage medium storing program instructions that, when executed by a computing platform operating on a device, can cause the computing platform to perform a method. The method can include establishing a secure channel between a SEE operating on the device and a security entity external to the device. The method can also configuring, by a security manager executing on the SEE, access to sensitive operations of an environment interactor coupled to the device based on a security policy provided from the security entity. The method can further include resetting, by the security manager, a secure watchdog timer in response to a reset authorization token provided from the secure entity. If the secure watchdog timer expires a given predetermined number of times since a last reset authorization token is received, the security manager can execute a given prescriptive operation dictated by the security policy.

Yet another example relates to a device providing a computing platform, and the computing platform can include a rich execution environment (REE) for controlling operations of an environment interactor coupled to the device and a secure execution environment (SEE) operating on the device that communicates with a security entity external to the device via a secure channel. A security manager operating on the SEE can configure access to sensitive operations of the environment interactor coupled to the device based on a security policy provided from the security entity. The SEE can also include a secure watchdog timer that is reset in response to a reset authorization token provided from the secure entity. If the secure watchdog timer expires a given predetermined number of times since a last reset authorization token is received, the security manager can execute a given prescriptive operation dictated by the security policy.

The present disclosure directed to establishing and maintaining control of sensitive operations of a device (such as an Internet of Things (loT) device) by the employment of a secure execution environment (SEE) even if the device has been hacked and/or the device is offline. Conventional device management products and mechanisms operate under the erroneous assumption that the software of the device is genuine and the integrity of the software (indicating that the software has not been modified) is guaranteed. Such devices can be hacked, preventing the device management system from functioning as expected.

In the examples described herein, a computing platform executing on the device is separated into multiple isolated execution environments, namely a Rich Execution Environment (REE) which is the host of the main Operating System of the device and a Secure Execution Environment (SEE) which is the host of sensitive assets and operations for the device. The isolation of those two environments ensures protection against software attacks. Depending on the configuration of the SEE, the level of hardware attacks countermeasures can vary. If the SEE is generated by a trusted execution environment (TEE), the SEE ensures software isolation but may have limited countermeasures against hardware attacks. However, if a secure element is included in addition to or in alternative of the TEE, the device can achieve a high level of security against both software and hardware attacks.

In some examples, the SEE can be directly embedded and integrated with the device platform and on the same security domain as device peripherals and/or sensors (environment interactors). Then, by acting as a secure master of the peripherals and/or sensors, the SEE selectively disables access to some (or all) of those peripherals and/or sensors. In this manner, applications executing on the REE have usage of the peripherals and/or the sensor, and while operating in parallel, the SEE configures such access to the peripherals and/or the sensors.

A remotely operated security entity administrates the SEE. Such administration permits updates and/or upgrades of assets and applications running within the SEE in a secure manner (e.g. via a secure channel). Operations of the SEE may be executed either online or offline through the use of a local agent, such as a security manager executing on the SEE. Moreover, the REE includes an administration agent that operates as a pass through of the secure channel between the security entity and the SEE to ensure bi-directional secure communication. The security entity manages a "security policy" that is stored in the SEE to facilitate management of the peripherals and/or sensors (e.g., environment interactors) coupled to the device. The remote entity can update the security policy on a periodic and/or asynchronous basis.

Furthermore, the SEE includes a secure watchdog timer. The secure watchdog timer is a programmable timer that allows the SEE to perform prescriptive (e.g., corrective and/or preventative) operations at regular intervals. Accordingly, the secure watchdog timer permits execution of sensitive code on a timely manner to process a security policy. More particularly, in some examples, the security entity can provide the reset authorization tokens for the secure watchdog timer in response to a confirmation that the REE is operating properly.

The SEE stores and applies the security policy. The SEE can store a value counting the number of times the secure watchdog timer has expired since the last reset authorization token was received from the security entity. The security policy associates prescriptive operations (e.g., corrective and/or preventative operations) to a number of timer expirations since the last reset authorization token is received. At the time the secure watchdog timer expires, the SEE checks if a new reset token has been received and, if not, the SEE applies the prescriptive operation identified in the secure policy which may include, but is not limited to any one of disabling an input/output (I/O) port, such as a Wi-Fi port (or other type of communication port), disabling access to a peripheral and/or a sensor controlled by the SEE and/or any combination thereof. This list and any other list is intended to disclose both disjunctive and conjunctive embodiments.

<FIG> illustrates a block diagram of a device <NUM> (e.g., a hardware device) that can be employed to implement a security policy. The device <NUM> can deploy a computing platform with multiple execution environments executing in parallel. Moreover, the device <NUM> can include a bus <NUM> and/or other communication mechanisms that can communicate information between components of device <NUM>. The device <NUM> can also include a memory <NUM> for storing machine readable instructions and data. The memory <NUM> can include any one or combination of random access memory ("RAM"), read only memory ("ROM"), static storage such as flash memory, a magnetic or optical disk, or any other type of non-transitory machine or computer-readable medium. The device <NUM> also includes an application processor <NUM>, operatively coupled to the bus <NUM>, that can process information and execute machine readable instructions or operations. The application processor <NUM> may be any type of general or specific purpose processor, such as an application specific integrated circuit (ASIC) chip. The device <NUM> further includes an input/output (I/O) port <NUM>, such as a wireless or wired network interface card or other communications interface, to provide access to a network. As some examples, the I/O port <NUM> can represent any one or more of Wi-Fi port, a Bluetooth port, a Near Field Communication (NFC) port, a Universal Serial Bus (USB) port, an Ethernet port, a modem, a proprietary communication port and/or any combination thereof. Inclusion of the I/O port <NUM> allows an external system to interface the device <NUM> directly or remotely through a network or any other method.

A computer-readable medium may be any available medium that can be accessed by the application processor <NUM>. The computer-readable medium may include both a volatile and nonvolatile medium, a removable and non-removable medium, a communication medium, and a storage medium. A communication medium may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any other form of information delivery medium known in the art. A storage medium may include RAM, flash memory, ROM, erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

The application processor <NUM> can also be operatively coupled via the bus <NUM> to a peripheral <NUM> and/or a sensor <NUM>. As used herein, the term "environment interactor" refers to a peripheral <NUM> and/or sensor <NUM> that is configured to execute a particular task. In some examples, the peripheral <NUM> can be representative of peripherals of a standard computing device, such as a Liquid Crystal Display ("LCD"), a keyboard and/or a cursor control device (e.g., a mouse or trackpad) can also be operatively coupled to the bus <NUM> to enable the user to interface with the device <NUM>. Additionally, the combination of the peripheral <NUM> and the sensor <NUM> can be representative of an environment interactor such as a biometric data collector, such as a fingerprint sensor, a (human) thermometer and/or a glucose monitor, etc. In still other examples, the peripheral <NUM> and/or the sensor <NUM> can be representative of a thermostat, a global positioning satellite (GPS) navigation system, a refrigerator, etc. In yet other examples, the peripheral <NUM> and/or the sensor <NUM> can be representative of smart card, including such as a passport, a subscriber identity module (SIM) card, an automatic teller machine (ATM) card, etc..

In some examples, the memory <NUM> can store software modules that may provide functionality when executed by the application processor <NUM>. The modules can include an operating system <NUM>, such as a rich OS. The memory <NUM> can also include an administrative agent <NUM> that can communicate with a secure execution environment (SEE) <NUM> of the device <NUM>. The OS <NUM> can provide an operating system functionality for the device <NUM> to provide a rich execution environment (REE) <NUM> for applications, including the administrative agent <NUM>.

The SEE <NUM> can be an execution environment of the computing platform that executes trusted operations. As used herein, the term "trusted operations" defines the execution of computer executable instructions that are deployed in a secure manner and that include countermeasures to prevent unauthorized access and/or modification. As one example, the SEE <NUM> can execute Java Card. The SEE <NUM> can be implemented as a trusted execution environment (TEE) and/or a secure element <NUM> communicatively coupled to the bus <NUM>. The TEE <NUM> is a tamper resistant set of resources in the application processor <NUM> dedicated to the execution of trusted operations. In some examples, a portion of the memory <NUM> can be assigned to the TEE <NUM> for storing trusted applications <NUM>. Additionally, in some examples as explained herein, a portion of the memory <NUM> can be assigned to the secure element <NUM>. Each trusted application <NUM> includes computer executable instructions for executing trusted operations.

The application processor <NUM> includes at least a portion of resources that can execute non-trusted computer executable instructions. That is, at least a portion of the resources of the application processor <NUM> is permitted to execute computer executable instructions that are susceptible to unauthorized modification. However, as discussed herein, harm induced by such unauthorized modification is thwarted by operations of the SEE <NUM>.

The secure element <NUM> is implemented as a discrete hardware device that is physically isolated from other components on the device <NUM>. More particularly, the secure element <NUM> can be implemented as a tamper-resistant hardware platform that provides security from software attacks that originate outside the hardware platform through hardware mechanisms that applications outside the hardware platform cannot control, where software components are executable on the secure element <NUM>. In some examples, the secure element <NUM> can be an embedded secure element (eSE) that is embedded within the device <NUM> and wired to other components of the device <NUM>. In other examples, the secure element <NUM> can be an integrated secure element (iSE) that is directly integrated into the hardware design of the device <NUM>, such as a situation where the device <NUM> includes a System on a Chip (SoC). In other examples, the secure element <NUM> can be removable from the device <NUM>. In some examples, the secure element <NUM> can be at least one of the following: a (single) discrete IC chip, a chipset, a secured microcontroller, a universal integrated circuit card, a memory card or a smart card such as a subscriber identity module (SIM) card. In examples where the secure element <NUM> is implemented as an removable device or an eSE, the secure element <NUM> includes an internal memory for storing trusted applications separate from the memory <NUM>. In examples where the secure element <NUM> is implemented as an iSE the secure element <NUM> can include internal memory and/or may share a portion of the memory <NUM> with the REE <NUM>, even though confidentiality of the contents of the share portion of the memory <NUM> is maintained.

The SEE <NUM> can provide functionality for implementing a security policy and a secure watchdog timer for the peripheral <NUM> and the sensor <NUM> to prevent botnet and other malicious attacks on the device <NUM>. The device <NUM> can also be part of a larger system. Thus, the device <NUM> can include other functional modules (not shown) to include the additional functionality.

<FIG> illustrates a block diagram of an example of a system <NUM> for establishing and maintaining a security policy with an SEE <NUM> operating on a device <NUM>. In some examples, the device <NUM> can be, for example an Internet of Things (IoT) device. In other examples, the device <NUM> can be implemented as a device that facilitates authentication and/or integrity, such as a mobile phone (e.g., a smart phone), etc..

The device <NUM> can be implemented as a hardware device such as the device <NUM> of <FIG> that can implement a computing platform with multiple executing environments, including the SEE <NUM> and an REE <NUM> operating in parallel. The SEE <NUM> can be implemented with a TEE and/or an secure element. The REE <NUM> can be representative of a rich OS executing on an application processor. In examples where a TEE is included, the TEE executes in concert with the REE <NUM> on the same application processor. More particularly, execution of the TEE and REE <NUM> are serialized, such that the operations of the TEE and the REE <NUM> appear to executing in parallel. In a situation where the TEE is omitted, and the SEE <NUM> is implemented on a secure element, the SEE <NUM> and the REE <NUM> operate in parallel on separate processing devices.

The device <NUM> can include an I/O port <NUM> for communicating with an security entity <NUM>, such as through a network or in a direct communication. The I/O port <NUM> can be a Wi-Fi port, a Bluetooth port a Near Field Communication (NFC) port, Universal Serial Bus (USB) port, an Ethernet port, a modem or a proprietary communication port. Additionally, the I/O port <NUM> can be representative of multiple different types of communication ports. The security entity <NUM> can be a computing platform that executes a secure server <NUM> for communicating with the SEE <NUM> in a manner described herein. The security entity <NUM> is remote from the device <NUM>.

The REE <NUM> can include an administrative agent <NUM> executing thereon. The administrative agent <NUM> can provide an interface between the REE <NUM> (an untrusted computing environment) and the SEE <NUM> (a trusted computing environment). More particularly, the administrative agent <NUM> can operate as a conduit (pass through) for a secure channel <NUM> (with encrypted data) between the SEE <NUM> and the secure server <NUM>.

In some examples, the secure channel <NUM> can be established by exchanging an asymmetric encryption key (e.g., a public key of a public/private key pair). More particularly, the secure channel <NUM> can be established with a standard encryption scheme, such as the Diffie-Hellman (DH) key exchange or the Elliptic Curve Diffe-Hellman (ECHD) key exchange. As one example, to establish the secure channel <NUM>, the secure server <NUM> can provide a public key of a public/private key pair to the SEE <NUM>. In response, the SEE <NUM> can be programmed to generate and encrypt a symmetric key with the public key of the secure server and transmit the encrypted symmetric key to the secure server <NUM> via the administrative agent <NUM>. The secure server <NUM> can decrypt the symmetric key using the private key of the public/private key pair. In this manner, both the security entity <NUM> and the SEE <NUM> possess the symmetric key, and the symmetric key is securely passed from the SEE <NUM> to the security entity <NUM>. In other examples, the secure channel <NUM> can be established using a predetermined symmetric key. In still other examples, other authentication techniques can be employed. In some examples, keys can be exchanged with authentication certificates that can leveraged to verify the authenticity of a sender of the key.

As one particular example, to establish the secure channel <NUM> between the SEE <NUM> and the secure server <NUM>, the SEE <NUM> can receive a signed public key certificate of the secure server <NUM>. The signed public key certificate can be issued by a trusted authority that securely stores a private key of an asymmetric encryption key pair (sometime referred to simply as a "key pair"). The signed public key certificate includes a public key of the asymmetric encryption key pair.

In response to the public key certificate, one or more of the trusted applications of the SEE <NUM> can be programmed to authenticate the public key certificate and to generate and encrypt a symmetric key with the public key included in the public key certificate and transmit the encrypted symmetric key to the secure server <NUM>. The secure server <NUM> can decrypt the symmetric key using the private key of the public/private key pair. In this manner, both the SEE <NUM> and the secure server <NUM> possess the symmetric key, and the symmetric key is securely passed from the SEE <NUM> to the secure server <NUM> to establish the secure channel <NUM>. In other examples, the secure channel <NUM> can be established using other authentication techniques, such as a predetermined symmetric key. In still other examples, other authentication techniques can be employed.

The device <NUM> can include an environment interactor <NUM>. The environment interactor <NUM> can be implemented as a peripheral and/or a sensor to interact with an environment of the device <NUM>. More particularly, in some examples, the environment interactor <NUM> can provide data characterizing observations of the environment to the SEE <NUM> and (in some examples) the REE <NUM>. Additionally, in some examples, the environment interactor <NUM> can receive user input and/or provide user output (e.g., in a display). In still other examples, the environment interactor <NUM> can output digital and/or analog actuation signals that control external systems, such as amplifiers, relays, motors and heating and/or cooling systems, etc..

As some examples, the environment interactor <NUM> can be can be representative of peripherals of a standard computing device, such as any one or more of an LCD, a keyboard, a cursor control device and/or any combination thereof. Additionally, the environment interactor <NUM> can be representative of a biometric data collector, such as a fingerprint sensor, a (human) thermometer and/or a glucose monitor. In still other examples, the environment interactor <NUM> can be representative of a thermostat, a global positioning satellite (GPS) navigation system, a refrigerator, a video playback device, etc. In yet other examples, the environment interactor can be representative of smart card, including a smart card implemented as a passport, a SIM card, an automatic teller machine (ATM) card, a credit card, etc..

As used herein, a "sensitive operation" is an operation that, if executed in an unauthorized manner, can cause harm the device <NUM> and/or another entity. Sensitive operations include, but are not limited to one or more of communications via the I/O port <NUM>, actuation signals, access to memory local to the environment interactor <NUM> that stores confidential information (e.g., credit card numbers, biometric data, etc.) and/or any combination thereof.

The device <NUM> can execute Java Card to implement the SEE <NUM>. Java Card refers to a specific software technology that allows Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices, including the TEE. Java Card gives the ability to program the devices and make the SEE <NUM> application specific. Java Card is employable for example, in situations where the SEE <NUM> includes a secure element implemented as a smart card, such as a situation where the secure element is implemented as a SIM cards (used in mobile phones), ATM cards and/or credit cards. In some examples, the Java-based applications can conform to standards, such as standard set forth in the GlobalPlatform.

The GlobalPlatform sets standards for operations of the secure element <NUM> and the TEE <NUM> of <FIG> to support the SEE <NUM>. The standards provided by the GlobalPlatform can include, for example, procedures for completing establishing a secure channel, such as the secure channel <NUM> and/or executing a transaction, such as a financial transaction. Additionally, the GlobalPlaftorm includes standards for contactless secure elements that are powered remotely as well as standards for secure elements that are powered through physical contact with a reader.

As used herein, the term "smart card", refers to a secure hardware device that can operate as a communication endpoint. A smart card is a device that includes an embedded integrated circuit that can be either a secure microprocessor (e.g., microcontroller) and memory or equivalent intelligence with internal memory or a memory chip alone. The smart card connects to a reader with direct physical contact or with a remote contactless radio frequency interface. With an embedded microprocessor and memory smart cards have the unique ability to store data, execute on-card functions (e.g., encryption and mutual authentication) and interact intelligently with a smart card reader. Many smart cards include an embedded private key and a corresponding public key that can be employed for establishing a secure communication channel, such as the secure channel <NUM>.

The SEE <NUM> can include a security manager <NUM> executing thereon. The security manager <NUM> can be a trusted application. The environment interactor <NUM> can interact with an application <NUM> (e.g., a software application) executing on the REE <NUM>. The application <NUM> executing on the REE <NUM> control operations of the environment interactor <NUM>. Concurrently, the environment interactor <NUM> also interacts with the security manager <NUM> executing in the SEE <NUM>. The security manager <NUM> can store and apply a security policy <NUM> to the environment interactor <NUM>. More particularly, the security manager <NUM> can control access to sensitive operations of the environment interactor <NUM> and/or the device <NUM>. That is, the SEE <NUM>, by executing the security manager <NUM>, can operate as a secure master of the environment interactor <NUM>.

The security policy <NUM> can be managed by the secure server <NUM> of the security entity <NUM>. In some examples, the security policy <NUM> is provided from the secure server <NUM> via the secure channel <NUM> that traverses the administrative agent <NUM>. Additionally or alternatively, updates to the security policy <NUM> are provided from the secure server <NUM> via the secure channel <NUM>.

Additionally, the security manager <NUM> includes a secure watchdog timer <NUM> executing thereon. The secure watchdog timer <NUM> can be implemented as a trusted application. The secure watchdog timer <NUM> executes a timer and the security manager <NUM> counts the number of timer expirations since a most recent (last) reset authorization token is received from the secure server <NUM>. In some examples, the secure watchdog timer <NUM> is based on an hardware mechanism managing a hardware timer in the SEE <NUM>. Alternatively, the secure watchdog timer <NUM> can be implemented in a security domain of the REE <NUM>, such as the portion of the memory <NUM> assigned to the TEE <NUM> for storing trusted applications <NUM> for the SEE <NUM>. In either such situation, the security manager <NUM> executes a handler of the security watchdog timer <NUM>.

The application <NUM> can communicate with the secure server <NUM> via the I/O port <NUM>. Moreover, at regular intervals, the secure server <NUM> can query the application <NUM> with a keep-alive message or other status check to ensure that the application <NUM> is executing properly and has not been corrupted and/or modified in an unauthorized manner. Each time (or some subset thereof) that the application <NUM> responds to the keep-alive message, the secure server <NUM> can send a reset authorization token to the secure watchdog timer <NUM> via the secure channel <NUM>. The reset message can be sent (or not sent) by the secure server <NUM> independently of messages (e.g., keep-alive message or other status check messages) sent to the application <NUM>. Stated differently, the reset message sent via the secure channel <NUM> allows messages (including the reset message) to be passed from the secure server <NUM> to the SEE <NUM> independently from the status of the application <NUM> (which may be corrupted).

Each time the secure watchdog timer <NUM> expires, the security manager <NUM> checks for receipt of a reset authorization token. If the reset authorization token corresponding to the expiration of the secure watchdog timer <NUM> has been received since the last expiration of the secure watchdog timer, the security manager <NUM> updates a period interval for the timer expiration stored by the secure watchdog timer <NUM>. In some examples, the period interval for the timer expiration can be reset to zero ('<NUM>'). Additionally, in some examples, the security manager <NUM> resets the count of the number of expirations of the secure watchdog timer <NUM> since the last reset authorization token was received. Conversely, if the secure watchdog timer <NUM> expires and the reset authorization token has not been received, the security manager <NUM> increments the value of the number of times the secure watchdog timer <NUM> has expired since the last reset authorization token has been received. Additionally, the security manager <NUM> consults the security policy <NUM> to determine whether a prescriptive operation is to be executed. The prescriptive operation dictated by the security policy <NUM> is commensurate with the number of expirations of the secure watchdog timer <NUM> since the last reset authorization token has been received by the security manager <NUM>.

In some examples, it is presumed that, if the secure watchdog timer <NUM> expires and no reset authorization token has been received at the SEE <NUM>, the REE <NUM> has become corrupted and/or compromised. Accordingly, the prescriptive operation can include corrective operations and/or preventative operations that prevent the device <NUM> from executing unauthorized and/or harmful operations. More particularly, the security manager <NUM> can disable the sensitive operations of the environment interactor <NUM> and/or other components of the device <NUM>. As an example, the security manager <NUM> can prevent the environment interactor <NUM> from outputting actuation signals. Additionally, the security manager <NUM> can disable or limit communications on the I/O port <NUM>. Disabling the I/O port <NUM> or limiting communication on the I/O port to communications on the secure channel <NUM> can prevent the device <NUM> from operating as a bot (a node) in a botnet attack.

In some examples, the prescriptive operation dictated by the security policy <NUM> does not disable all operations of the environment interactor <NUM>. For instance, in some examples, the environment interactor <NUM> can include a local memory that stores data characterizing observed conditions (e.g., temperature). In such a situation, the prescriptive operation dictated by the security policy <NUM> may allow reads to that memory (e.g., by the application <NUM>) since such reads may considered non-sensitive operations.

Further, in some examples, the prescriptive operation dictated by the security policy <NUM> can periodically and/or asynchronously configure the I/O port <NUM> to allow the secure server <NUM> to overwrite a portion (or all) of the machine readable instructions and the data for the REE <NUM>. As noted, in some examples, it is presumed that if the secure watchdog timer <NUM> expires a predetermined number of times and no reset authorization token has been received, that the REE <NUM> is corrupted and/or compromised. In such a situation, it may be prudent to erase the memory of the device <NUM> associated with the REE <NUM> and write over the memory to restore permitted operations of the REE <NUM>. By implementing the SEE <NUM> in this manner, the security policy <NUM> can be deployed on the environment interactor <NUM> independent of whether the device <NUM> is in communication with the security entity <NUM>. That is, the SEE <NUM> can implement the prescriptive operations dictated by the security policy <NUM> if the device <NUM> is online (connected to the security entity <NUM>) or offline (e.g., disconnected from other nodes, including the security entity <NUM>).

As a first example of implementation (hereinafter, "the first example"), it is presumed that the device <NUM> represents a smart thermostat. In such a situation, the security entity <NUM> can represent an end-user device (e.g., a smart phone or desktop/laptop computer) and the secure server <NUM> can represent an application (e.g., a software application or a web browser) with controls for adjusting parameters of the smart thermostat. Continuing with the first example, the I/O port <NUM> can be representative of a Wi-Fi port. Additionally, the environment interactor <NUM> can be representative of a thermometer (e.g., a sensor) and a signal actuator (e.g., a peripheral) for controlling the switching on and off of a heating, ventilation and air conditioning (HVAC). Additionally, the application <NUM> can be a client application for the secure server <NUM>.

Continuing with the first example, the security manager <NUM> can configure the device <NUM> to allow the application <NUM> to control operations of the environment interactor <NUM>. However, in the first example, if the secure watchdog timer <NUM> expires and the security manager <NUM> has not received a reset authorization token from the secure server <NUM> via the secure channel <NUM>, the security manager <NUM> applies the prescriptive operation dictated by the security policy <NUM>.

As noted, the prescriptive operation dictated by the security policy <NUM> is commensurate with the number of expirations of the secure watchdog timer <NUM> since the last reset authorization token has been received by the security manager <NUM>. Thus, in some examples, a less severe prescriptive operation can be executed with a first number of expirations of the secure watchdog timer <NUM> (e.g., corresponding to a relatively short amount of time), and a more severe prescriptive operation can be executed with a second number of expirations of the secure watchdog timer <NUM> (e.g., corresponding to a relatively long amount of time). As a simplified situation in the first example, if the secure watchdog timer <NUM> expires a number of times corresponding to about <NUM>-<NUM> hours (e.g., relatively short amount of time in the first example), the security policy <NUM> may dictate that the I/O port <NUM> is to be disabled for communications other than the communications on the secure channel <NUM>, but that other operations including the actuation signals controlled by the application <NUM> are allowed to continue. Such a prescriptive operation may be selected since disabling communication on the I/O port <NUM> (other than communication on the secure channel <NUM>) would prevent the device <NUM> from operating as a bot in a botnet attack. However, since connections to the security entity <NUM> may be intermittent, the REE <NUM> may not be presumed to be corrupted and/or compromised after about <NUM>-<NUM> hours of expiration of the secure watchdog timer <NUM> recorded by the security manager <NUM>. Thus, in the first example, it is presumed that the REE <NUM> is operating properly, but as a caution, communication on the I/O port <NUM> are disabled until the reset authorization token is received from the secure server <NUM>.

Continuing with the first example, if the secure watchdog timer <NUM> expires a number of times corresponding to about <NUM> hours or more (e.g., a relatively long amount of time in the first example), the security policy <NUM> may dictate disabling the I/O port <NUM> for communications other than the communications on the secure channel <NUM> and disabling execution of the actuation signals. Such a prescriptive operation may be selected since disabling communication on the I/O port <NUM> (other than communication on the secure channel <NUM>) would prevent the device <NUM> from operating as a bot in a botnet attack and would prevent unauthorized operation of the HVAC system. However, in this situation, the prescriptive operation dictated by the security policy <NUM> may continue to allow readings of a memory local to the environment interactor <NUM> that stores data characterizing measured ambient temperature, since such operation has a low chance of inducing harm and may considered a non-sensitive operation.

As noted, in some examples, the security policy <NUM> may contain contextual constraints that dictates certain operations in particular contexts. Thus, continuing with the first example, in some situations, the security policy <NUM> can include operations for a low temperature trigger and/or a high temperature trigger. The low temperature trigger could dictate that if the thermometer (corresponding to the environment interactor <NUM>) reports an ambient temperature of about <NUM> degrees Celsius or less that the security manager <NUM> is to provide an activation signal to activate (e.g., turn on) the heat. Similarly, the high temperature trigger could dictate that if the thermometer (corresponding to the environment interactor <NUM>) reports an ambient temperature of <NUM> degree Celsius or more, the security manager <NUM> is to provide an activation signal to activate (e.g., turn on) the air conditioning. These operations can override the control of heat and/or air conditioning by the application <NUM>.

Still further, in some instances of the first example, as part of the prescriptive operation, the security manager <NUM> can enable communication to the I/O port <NUM> to allow rewriting of the memory for the REE <NUM>. In this manner, the device <NUM> can be restored to a functional state.

As a second example of implementation (hereinafter, "the second example"), it is presumed that the environment interactor <NUM> represents a fingerprint capturing device. In such a situation, the security entity <NUM> can represent an end-user device (e.g., a smart phone or desktop/laptop computer) and the secure server <NUM> can represent an application (e.g., a software application or a web browser) with control operations for capturing a fingerprint of a person. Continuing with the second example, the I/O port <NUM> can be representative of an Ethernet port or a USB port. Additionally, the environment interactor <NUM> can be representative of a fingerprint scanner (e.g., a sensor). Additionally, the application <NUM> can be a client application for the secure server <NUM>.

Continuing with the second example, the security manager <NUM> can configure the device <NUM> to allow the application <NUM> to control operations of the environment interactor <NUM>. However, in the second example, if the secure watchdog timer <NUM> expires and the security manager <NUM> has not received a reset authorization token from the secure server <NUM> via the secure channel <NUM>, the security manager <NUM> applies the prescriptive operation dictated by the security policy <NUM>.

Due to the high sensitivity of the nature of fingerprint scanning, the prescriptive operation dictated by the security policy <NUM> may be sweeping even with a relatively short time corresponding to expirations of the watchdog timer <NUM> without receipt of a reset authorization token. Stated differently, due to the security risk of a fingerprint scanner, in some examples, a severe, and sweeping prescriptive operation can be executed after a relatively short time after a failure to receive reset authorization tokens. As a simplified situation in the second example, if the secure watchdog timer <NUM> expires a number of times corresponding to about <NUM>-<NUM> minutes (or less, in some examples), the security policy <NUM> may dictate that the I/O port <NUM> is to be disabled for communications other than the communications on the secure channel <NUM>, and that other operations including the scanning of fingerprints are disabled. Such a prescriptive operation may be selected since disabling communication on the I/O port <NUM> (other than communications on the secure channel <NUM>) would prevent the device <NUM> from operating as a bot in a botnet attack. Additionally, since connections to the security entity <NUM> may be continuous, the REE <NUM> may be presumed to be corrupted and/or compromised after about <NUM> to about <NUM> minutes of expirations of the secure watchdog timer <NUM>. Thus, in the second example, independent of whether the REE <NUM> is actually operating properly, as a caution, communication on the I/O port <NUM> are disabled (or limited) until the reset authorization token is received from the secure server <NUM>.

Furthermore, in contrast to the first example, the prescriptive operation dictated by the security policy <NUM> in the second example may prevent reading of a local memory of the environment interactor <NUM> since such local memory can have (in some examples) sensitive data characterizing a scanned fingerprint. Thus, in addition to preventing botnet attacks, the SEE <NUM> prevents unauthorized distribution of sensitive information.

As a third example of implementation (hereinafter, "the third example"), it is presumed that the device <NUM> represents a time-based lock control device. In such a situation, the security entity <NUM> can represent an end-user device (e.g., a smart phone or desktop/laptop computer) and the secure server <NUM> can represent an application (e.g., a software application or a web browser) with control operations for opening and closing a lock. Continuing with the third example, the I/O port <NUM> can be representative of a WiFi and/or a Bluetooth port. Additionally, the environment interactor <NUM> can be representative of a lock on a safe. Additionally, the application <NUM> can be a client application for the secure server <NUM>.

Furthermore, in the third example, the SEE <NUM> can include a secure clock. Moreover, as noted, in some examples, the security policy <NUM> may contain contextual constraints that dictates certain operations in particular contexts. Thus, continuing with the third example, in some situations, the security policy <NUM> may have time constraints for operating the lock. For instance, if the lock is door lock in a secure facility, the security policy <NUM> may dictate that the lock can only be opened at certain times of day and/or on certain dates.

Continuing with the third example, the security manager <NUM> can configure the device <NUM> to allow the application <NUM> to control operations of the environment interactor <NUM>. However, in the third example, if the secure watchdog timer <NUM> expires and the security manager <NUM> has not received a reset authorization token from the secure server <NUM> via the secure channel <NUM>, the security manager <NUM> applies the prescriptive operation dictated by the security policy <NUM>.

Similar to the second example, due to the high sensitivity of the nature of secure doors, the prescriptive operation dictated by the security policy <NUM> may be sweeping even with a relatively short time corresponding to expirations of the watchdog timer <NUM> without receipt of a reset authorization token. Stated differently, due to the security risk of a unauthorized access to subject matter protected by the lock, in some examples, a severe, and sweeping prescriptive operation can be executed after a relatively short time after a failure to receive reset authorization tokens. As a simplified situation in the third example, if the secure watchdog timer <NUM> expires a number of times corresponding to about <NUM>-<NUM> minutes (or less, in some examples), the security policy <NUM> may dictate that the I/O port <NUM> is to be disabled for communications other than the communications on the secure channel <NUM>, and that other operations including unlocking of the lock are disabled. Such a prescriptive operation may be selected since disabling communication on the I/O port <NUM> (other than communications on the secure channel <NUM>) would prevent the device <NUM> from operating as a bot in a botnet attack. Additionally, since connections to the security entity <NUM> may be continuous, the REE <NUM> may be presumed to be corrupted and/or compromised after about <NUM> to about <NUM> minutes of expirations of the secure watchdog timer <NUM>. Thus, in the third example, independent of whether the REE <NUM> is actually operating properly, as a caution, communication on the I/O port <NUM> are disabled (or limited) until the reset authorization token is received from the secure server <NUM>.

Furthermore, in the third example, the security manager <NUM> may override control of the lock due to the noted contextual constraints included in the security policy <NUM>. More particularly, the security manager <NUM> can be configured to override control of the lock if a contextual condition is not met. For example, if application <NUM> attempts to open the lock, the security manager <NUM> can query the internal clock and determine whether the present time and date is within a time outside a permitted window of time. If the present time is outside the time and date of the permitted window of time, the security manager <NUM> can command the lock (the environment interactor <NUM>) to remain locked, such that an actuation signal for unlocking the lock is disabled by the security manager <NUM>.

As a fourth example of implementation (hereinafter, "the fourth example"), it is presumed that the environment interactor <NUM> represents a location-based vehicle control device. In such a situation, the security entity <NUM> can represent an end-user device (e.g., a smart phone or desktop/laptop computer) and the secure server <NUM> can represent an application (e.g., a software application or a web browser) with controls operation for turning on and off a vehicle. Continuing with the fourth example, the I/O port <NUM> can be representative of a WiFi and/or a Bluetooth port. Additionally, the environment interactor <NUM> can be representative of an ignition of a vehicle. Additionally, the application <NUM> can be a client application for the secure server <NUM>.

Furthermore, in the fourth example, the SEE <NUM> can include a secure global navigation satellite system (GNSS), such as a global positioning system (GPS). Moreover, as noted, in some examples, the security policy <NUM> may contain contextual constraints that dictates certain operations in particular contexts. Thus, continuing with the fourth example, in some situations, the security policy <NUM> may have location constraints for operating the ignition of the vehicle. For instance, if the vehicle is a vehicle available for rent, the security policy <NUM> may dictate that the ignition of the vehicle can only be turned on in certain jurisdictions to prevent the vehicle from being illegally exported.

Continuing with the fourth example, the security manager <NUM> can configure the device <NUM> to allow the application <NUM> to control operations of the environment interactor <NUM>. However, in the fourth example, if the secure watchdog timer <NUM> expires and the security manager <NUM> has not received a reset authorization token from the secure server <NUM> via the secure channel <NUM>, the security manager <NUM> applies the prescriptive operation dictated by the security policy <NUM>.

Similar to the first example, in the fourth example the prescriptive operation dictated by the security policy <NUM> can be commensurate with the number of expirations of the secure watchdog timer <NUM> since the last reset authorization token has been received by the security manager <NUM>. Thus, in some examples, a less severe prescriptive operation can be executed with a first number of expirations of the secure watchdog timer <NUM> (e.g., corresponding to a relatively short amount of time), and a more severe prescriptive operation can be executed with a second number of expirations of the secure watchdog timer <NUM> (e.g., corresponding to a relatively long amount of time). As a simplified situation in the first example, if the secure watchdog timer <NUM> expires a number of times corresponding to about <NUM>-<NUM> hours (e.g., a relatively short amount of time in the fourth example), the security policy <NUM> may dictate that the I/O port <NUM> is to be disabled for communications other than the communications on the secure channel <NUM>, but that other operations including the actuation signals controlled by the application <NUM> are allowed to continue. Such a prescriptive operation may be selected since disabling communication on the I/O port <NUM> (other than communication on the secure channel <NUM>) would prevent the device <NUM> from operating as a bot in a botnet attack. However, since connections to the security entity <NUM> may be intermittent, the REE <NUM> may not be presumed to be corrupted and/or compromised after about <NUM>-<NUM> hours of expiration of the secure watchdog timer <NUM> recorded by the security manager <NUM>. Thus, in the fourth example, it is presumed that the REE <NUM> is operating properly, but as a caution, communication on the I/O port <NUM> are disabled until the reset authorization token is received from the secure server <NUM>.

By employing the system <NUM>, the SEE <NUM> is leveraged to configure access to sensitive operations of the environment interactor <NUM> (peripherals and/or sensors). For example, if the SEE <NUM> includes a secure element (e.g., with Java Card executing thereon) embedded in the device <NUM> and a TEE that is present on the device <NUM>, the SEE <NUM> can control access to sensitive operations of the environment interactor <NUM> with privileges elevated relative to an application executing on the REE <NUM>. Furthermore, inclusion of the secure watchdog timer <NUM> in the SEE <NUM> ensures that if the REE <NUM> is accessed in an unauthorized manner (e.g., hacked) or otherwise becomes corrupted, the prescriptive operation dictated by the security policy <NUM> is executed before significant harm is done, even in situations where the device <NUM> is offline.

In view of the foregoing structural and functional features described above, an example method will be better appreciated with reference to <FIG>. While, for purposes of simplicity of explanation, the example method of <FIG> is shown and described as executing serially, it is to be understood and appreciated that the present examples are not limited by the illustrated order, as some actions could in other examples occur in different orders, multiple times and/or concurrently from that shown and described herein. Moreover, it is not necessary that all described actions be performed to implement a method.

<FIG> illustrates an example of a method <NUM> for establishing and maintaining a security policy on a device, such as an loT device and/or an authentication device. The method <NUM> can be implemented, for example, by an SEE (e.g., the SEE <NUM> of <FIG> and/or the SEE <NUM> of <FIG>) operating on a computing platform hosted by a device (e.g., the device <NUM> of <FIG> and/or the device <NUM> of <FIG>). At <NUM>, the SEE establishes a secure channel (e.g., the secure channel <NUM> of <FIG>) between a security entity (e.g., the security entity <NUM> of <FIG>) and the SEE of the device. The security entity can be remote from the device. Thus, the secure channel can traverse an I/O port (e.g., a wired or wireless communication port) of the device. Moreover, the computing platform of the device includes an REE (e.g., the REE <NUM> of <FIG> and/or the REE <NUM> of <FIG>). In some examples, the REE includes an administrative agent that operates as a pass-through for the secure channel between the security entity and the SEE.

At <NUM>, the SEE receives a security policy (e.g., the security policy <NUM> of <FIG>) from the secure entity via the secure channel. The security policy can be implemented as a table with a list of prescriptive operations for a corresponding number of secure watchdog timer expirations since a last reset authorization token has been received at the SEE. At <NUM>, a security manager (e.g., the security manager <NUM> executing on the SEE) configures access to sensitive operations of the environment interactor (e.g., a peripheral and/or a sensor such as the environment interactor <NUM> of <FIG>). Such configuration can allow an application (e.g., the application <NUM> of <FIG>) to control operations of the environment interactor.

At <NUM>, the security manager can reset a secure watchdog timer (e.g., the secure watchdog timer <NUM> of <FIG>) executing on the SEE. At <NUM>, the secure watchdog timer expires. At <NUM>, the security manager can make a determination as to whether the SEE received a reset authorization token from the security entity since the last reset of the secure watchdog timer. If the determination at <NUM> is positive (e.g., YES), the method <NUM> returns to <NUM>. If the determination at <NUM> is negative (e.g., NO), the method proceeds to <NUM>.

At <NUM>, the security manager increments a recorded value corresponding to the number of times the secure watchdog timer has expired since a last reset authorization token has been received. At <NUM>, the security manager determines a prescriptive operation (e.g., corrective and/or preventative operations) based on the security policy. That is, the security policy includes a list of prescriptive operations commensurate with the number of secure watchdog timer expirations. At <NUM>, the security manager executes the prescriptive operation. As noted, in some examples, the prescriptive operations can include disabling an I/O port for communication other than communication via the secure channel. Additionally or alternatively, the prescriptive operations can include disabling actuation signals of the environment interactor and/or disabling access to memory of the environment interactor. Still further, in some examples, the prescriptive operation can include enable writing over the portion of memory of the device employed for the REE to restore the REE to a functional state. In some examples, upon executing the prescriptive operation, the method <NUM> can return to <NUM>.

The examples herein may be implemented on virtually any type of computing system regardless of the platform being used. For example, the computing system may be one or more mobile devices (e.g., laptop computer, smart phone, personal digital assistant, tablet computer, or other mobile device), desktop computers, servers, blades in a server chassis, or any other type of computing device or devices that includes at least the minimum processing power, memory, and input and output device(s) to perform one or more embodiments. As shown in <FIG>, the computing system <NUM> can include a computer processor <NUM>, associated memory <NUM> (e.g., random access memory (RAM), cache memory, flash memory, etc.), one or more storage device <NUM> (e.g., a solid state drive, a hard disk drive, an optical drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a flash memory stick, etc.), and numerous other elements and functionalities. The computer processor <NUM> may be an integrated circuit for processing instructions. For example, the computer processor may be one or more cores, or micro-cores of a processor. Components of the computing system <NUM> can communicate over a data bus <NUM>.

The computing system <NUM> may also include an input device <NUM>, such as any combination of one or more of a touchscreen, keyboard, mouse, microphone, touchpad, electronic pen. Further, the computing system <NUM> can include an output device <NUM>, such as one or more of a screen (e.g., light emitting diode (LED) display, an organic light emitting diode (OLED) display, a liquid crystal display (LCD), a plasma display, touchscreen, cathode ray tube (CRT) monitor, projector, or other display device), a printer, external storage, or any other output device. In some examples, such as a touch screen, the output device <NUM> can be the same physical device as the input device <NUM>. In other examples, the output device <NUM> and the input device <NUM> can be implemented as separate physical devices. The computing system <NUM> can be connected to a network <NUM> (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, mobile network, or any other type of network) via a network interface connection (not shown). The input device and output device(s) can be connected locally and/or remotely (e.g., via the network <NUM>) connected to the computer processor <NUM>, the memory <NUM>, and/or the storage device <NUM>. Many different types of computing systems exist, and the aforementioned input device <NUM> and the output device <NUM> can take other forms. The computing system <NUM> can further include a peripheral <NUM> and a sensor <NUM> for interacting with the environment of the computing system <NUM> in a manner described herein.

Software instructions in the form of computer readable program code to perform embodiments disclosed herein can be stored, in whole or in part, temporarily or permanently, on a non-transitory computer readable medium such as a CD, DVD, storage device, a diskette, a tape, flash memory, physical memory, or any other computer readable storage medium. Specifically, the software instructions can correspond to computer readable program code that when executed by a processor, is configured to perform operations disclosed herein.

The computing system <NUM> can include a secure element <NUM> installed thereon. In some examples, the secure element <NUM> can be a removable device, such as a SIM card, in situations where the computing system <NUM> is implemented as a smart phone. In other examples, the secure element <NUM> can be an embedded secure element (eSE) that is hardwired to the data bus <NUM>. In still other examples, including examples where the computing system <NUM> is implemented as a system on a chip (SoC), the secure element <NUM> can be implemented as an integrated secure element (iSE).

The secure element <NUM> can include an embedded secure processor <NUM> that can execute machine readable instructions separately from the processor <NUM>. The machine readable instructions executed by secure processor <NUM> can be stored in a secure memory <NUM>. The secure memory <NUM> is inaccessible to other components of the computing system <NUM>. The secure memory <NUM> can include trusted applications <NUM> that are executable by the secure processor <NUM> of the secure element <NUM>.

Additionally, in examples where the secure element <NUM> is an iSE (integrated secure element), the memory <NUM> can be partitioned to include SE (secure element) memory <NUM>. The SE memory <NUM> of the memory can also store trusted applications <NUM> that can be the same or different applications than the trusted applications <NUM> of secure memory <NUM>. Still further, the memory <NUM> can include a partition for TEE (trusted execution environment) memory <NUM> that also includes trusted applications <NUM> that can be the same or different from the trusted applications <NUM> and <NUM>.

The memory <NUM> can also include a partition of unsecured memory <NUM>. The unsecured memory <NUM> can include, for example, rich applications <NUM> that could be executed in a REE (rich execution environment), as described herein.

The trusted applications <NUM>, <NUM> and <NUM> can include, but are not limited to applications configured for Java Card. Java Card provides a Java Card Virtual Machine and a runtime library to allow the same applet to execute on multiple different types of secure elements <NUM> or TEE. The Java Card Virtual machine encapsulates data and provides an applet firewall to protect against the unauthorized access of the data. Java Card bytecode that is run by the Java Card Virtual Machine is a functional subset of Java <NUM> bytecode run by a standard Java Virtual Machine but with a different encoding to adjust for size. A Java Card applet thus typically uses less bytecode than the hypothetical Java applet obtained by compiling the same Java source code to conserves memory. Java Card is employable for example, in situations where the secure element <NUM> is implemented as an application specific smart card, such as a SIM card (used in mobile phones), ATM cards and/or credit cards (e.g., EMV cards).

As described herein, the secure element <NUM> and a TEE can operate alone or in concert to provide an SEE (secure execution environment) to execute that monitors and controls the rich applications <NUM> executing on the REE. That is, the SEE can be hosted by the secure memory <NUM>, the SE memory <NUM> and/or the TEE memory <NUM>. Furthermore, the secure memory <NUM>, the SE memory <NUM> and/or the TEE memory <NUM> can host data for the corresponding trusted applications <NUM>, <NUM> and <NUM>.

The computing system <NUM> can communicate with a server <NUM> via the network <NUM>. In some examples, the connection between the server <NUM> and the computing system <NUM> can be a secure channel. More particularly the SEE (the secure element <NUM> and/or the TEE) can provide a communication endpoint for a secure channel. For purposes of simplification of explanation with respect to <FIG>, it is presumed that the secure element <NUM> operates as a communication endpoint for the secure channel.

As one example, the secure element <NUM> can be implemented as a SIM card. A SIM card is a type of smart card that is employed on mobile devices to communicate with carrier networks. In fact, the SIM card can be employed to establish the secure channel between the server <NUM> and the secure element <NUM>. The SIM card stores a unique identifier, namely an international mobile subscriber identity (IMSI) that can be provided to the server <NUM> on the carrier network. The server <NUM> can employ the IMSI provided from the SIM card to determine an authentication key (Ki), wherein the authentication key, Ki is also securely embedded on the SIM card. The server <NUM> can generate a random number and sign the random number, RAND with the authentication key, Ki of the SIM card to generate a first signed response, RSP1 and a (symmetric) encryption key, Kc. The server <NUM> returns the random number, RAND to the SIM card, wherein the SIM card signs the random number, RAND using the embedded authentication key, Ki to produce a second signed response, RSP2 and a copy of the encryption key, Kc. The SIM card passes the signed response, RSP2 to the secure server <NUM> and the SIM card securely stores the encryption key, Kc.

The secure server <NUM> compares the first response, RSP1 to the second response, RSP2. If the first response, RSP1 and the second response, RSP2 match, then both copies of the encryption key, Kc, namely the copy at the secure server <NUM> and the copy embedded on the SIM card, also match. In this manner, both the secure server <NUM> and the SIM card have an encryption key, Kc that can be employed as a symmetric encryption key. In this manner, the secure server <NUM> can be granted (or denied) communication privileges on a carrier network. In situations where the SIM card is removable, the privileges on the carrier network can follow the SIM card.

As noted, in some examples, the secure element <NUM> can be implemented as a credit card, and more particularly, an EMV card. In such a situation, the EMV card can be an IC card that is powered through contacts on the EMV card. Alternatively, the EMV can be a contactless card that receives power through inductive coupling when a reader is in relatively close physical proximity to the EMV card. That is, in both examples of a EMV card, an IC card or a contactless card, the EMV card is powered by a remote device. During a transaction with an EMV card, the secure processor <NUM> is configured to process information and determine rules that impact an outcome of the transaction. Such rules include enforcing services such as offline data authentication, user identification, online authorization, etc..

During a transaction with an EMV (implementing the secure element <NUM>) the EMV sends an Authorization Request Cryptogram (ARCQ) in an authorization request for the transaction to the server <NUM>. In response, the server <NUM>, generates and returns an Authorization Response Cryptogram (ARPC) to the EMV. In response to the ARPC, the EMV can either generate a Transaction Certificate (TC) authorizing the transaction or an Application Authentication Cryptogram (AAC) that declines the transaction.

Further still, as noted, in some examples, the secure element <NUM> is implemented as a non-removable secure element, such as an eSE (embedded secure element) of an iSE (integrated secure element). In such a situation, the server <NUM> can implement a remote provisioning protocol set forth by the Global System for Mobile Communications (GSMA) association. Such standards define a computing platform that supports Java Card to enable the secure execution of the trusted applications <NUM> and <NUM>.

Further, one or more elements of the aforementioned computing system <NUM> can be located at a remote location and connected to the other elements over the network <NUM>. Further, some examples can be implemented on a distributed system having a plurality of nodes, where each portion of an embodiment can be located on a different node within the distributed system. In one example, the node corresponds to a distinct computing device. Alternatively, the node can correspond to a computer processor with associated physical memory. The node can alternatively correspond to a computer processor or micro-core of a computer processor with shared memory and/or resources.

Claim 1:
A method for establishing and maintaining a security policy (<NUM>) for a device (<NUM>, <NUM>, <NUM>), the method comprising:
establishing a secure channel (<NUM>) between a secure execution environment, SEE (<NUM>, <NUM>), operating on the device (<NUM>, <NUM>, <NUM>) and a security entity (<NUM>) external to the device (<NUM>, <NUM>, <NUM>);
configuring, by a security manager (<NUM>) executing on the SEE (<NUM>, <NUM>), access to sensitive operations of an environment interactor (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) coupled to the device (<NUM>, <NUM>, <NUM>) based on a security policy (<NUM>) provided from the security entity (<NUM>);
resetting, by the security manager (<NUM>), a secure watchdog timer (<NUM>) in response to a reset authorization token provided from the secure entity (<NUM>);
wherein the SSE (<NUM>, <NUM>) stores and applies the security policy (<NUM>) whereby, if the secure watchdog timer (<NUM>) expires a given predetermined number of times since a last reset authorization token is received, the security manager (<NUM>) executes a given prescriptive operation dictated by the security policy (<NUM>), and, if the secure watchdog timer (<NUM>) expires another predetermined number of times since the last reset authorization token is received, the security manager (<NUM>) executes another prescriptive operation dictated by the security policy (<NUM>).