Computing device with entry authentication into trusted execution environment and method therefor

A computing device (10) includes a trusted execution environment (TEE) manager (40) that manages a switchover from non-trusted software (116) to trusted software (118). The TEE manager (40) includes memory (90) configured to store password-bearing, immediate-operand instructions (54). At the point of switching between the non-trusted software (116) and the trusted software (118) the memory (90) may be accessed as instruction fetches, and its contents fetched into a CPU core (24) as instructions. Immediate-operand portions (60) of the immediate-operand instructions (54) provide passwords, which are written back into guess registers (80) within the TEE manager (40). When a predetermined relationship between the instructions (54) and guesses in guess registers (80) is identified, actual execution of the immediate-operand instructions (54) is verified, the TEE mode of operation is signaled, and security-sensitive hardware (44) is enabled for use by a privileged routine (42) portion of the trusted software (118).

TECHNICAL FIELD OF THE INVENTION

The present invention generally relates to data security in electronic devices. More specifically, the present invention relates to the implementation of a trusted execution environment (TEE) having an improved mechanism for switching into the TEE.

BACKGROUND OF THE INVENTION

A computing device is an electronic apparatus, whether a portion of a single integrated circuit or an entire system, whose functions and operations are defined by both hardware and software. Hardware represents the physical components that carry out the functions of the device, and software represents the collection of all programming instructions, procedures, rules, routines, modules, programs, data, and the like that define how to carry out the device's functions and operations.

Manufacturers of computing devices intended for specific system applications are often concerned about the security of at least some of the computing device's data and functions. Thus, some system applications may employ security-sensitive cryptographic circuits so that security policies may be implemented with respect to data handled by the device. Some system applications may employ other security-sensitive circuits, such as RF transmitters whose use is tightly controlled for regulatory and network efficiency purposes, and security policies may be implemented so that the security-sensitive circuits are not misused.

Two classes of software are often identified for the purposes of implementing a security policy. One class is non-trusted software. Non-trusted software may or may not be malicious, but no assurance is provided that the non-trusted software will cause no harm. In many situations, non-trusted software may nevertheless be beneficial to a user of the computing device. Thus, a computing device often permits the execution of non-trusted software. But in accordance with a security policy, non-trusted software executes in a non-privileged mode of operation, or restricted execution environment (REE), in which access is denied to security-sensitive resources so that the non-trusted software cannot cause harm.

Trusted software is software whose bone fides are assured. If trusted software controls security-sensitive resources, it does so in a way that causes no harm. When security-sensitive resources are controlled by trusted software, the computing device may operate in a privileged mode, or trusted execution environment (TEE), that allows the trusted software to access the resources needed to carry out its function. A TEE is where trusted software has control of the CPU and the device. In this environment access is allowed to security sensitive resources.

System designers of computing devices face many challenges in configuring a computing device to provide both an REE and a TEE. While in the REE, the non-trusted software's access to security-sensitive resources should be constrained. Then, before switching to the TEE, an entry mechanism should authenticate the trusted software to establish that the software about to be executed is authentic trusted software and not malicious, mischievous, or possibly error-infested software. And, the entry mechanism itself, which provides an interface between the REE and TEE, should be protected against threats.

Conventional techniques for implementing both an REE and TEE are inadequate. A variety of different manufacturers provide different versions of CPU cores and operating systems. CPU cores represent central processing units (CPUs) and related circuits dedicated to controlling the flow of instructions and data into and out of the CPU, and operating systems represent the software that interfaces most directly with hardware and that controls the execution of application software. These manufacturers provide some products with some features directed toward distinguishing between privileged and non-privileged modes of operation. But from a system perspective, a solution that is unique to a specific CPU core or a specific operating system is highly undesirable because it enslaves other system components and the entire system design to a specific CPU core and/or operating system.

Moreover, many of the conventional techniques are simply ineffective from a system perspective. For example, features built into a CPU core often do not extend outside the CPU core where they might have been useful for controlling other system components. And, whether or not such features are extended outside a CPU core, other active entities in the system, such as direct memory access (DMA) devices or other CPU's, often cannot be controlled with respect to implementing an effective TEE. Operating systems may have been written so that too much potentially flawed software runs in privileged modes, thereby blurring the distinction between the TEE and the REE. Too many techniques are vulnerable to being tricked by stack and cache manipulations, by conditional branching, speculative execution, and out-of-order instruction completion schemes, and by failing to verify that trusted software actually executes. As a consequence, the conventional techniques provide inadequate security assurances, particularly from a system-wide perspective.

DETAILED DESCRIPTION

FIG. 1shows a simplified block diagram of a computing device10configured in accordance with one embodiment of the present invention. Computing device10may be configured for any of a wide variety of data-processing applications, including point-of-sale terminal, wireline or wireless telephone, radio, personal computer, laptop, handheld computer, workstation, digital media player, router, modem, industrial controller, and the like. Regardless of a specific configuration, the security of at least some of the data and/or functions of computing device10is a concern.

In a preferred embodiment, computing device10is an electronic device formed using one or more semiconductor devices12which have pins14through which signals are routed into and out of device12. Semiconductor device12couples to other units and components through an external bus16. The other units and components may include memory18, peripherals20, and original equipment manufacturer (OEM) functions22. Memory18may be configured as magnetic, optical, or semiconductor memory and may be configured as volatile and/or non-volatile memory. Peripherals20represent devices which support the primary operations of computing device10. In one example, peripherals20may include any of a wide variety of data input and data output devices known to those skilled in the art. OEM functions22represent devices added by a manufacturer other than the manufacturer of semiconductor device12or the provider of any operating system that may run on semiconductor device12and that tailor computing device10to a particular application.

Within semiconductor device12, a central processing unit (CPU) core24and a variety of system components26couple together through an internal bus28. CPU core24includes a processor30and a variety of circuits which support processor30and are dedicated to controlling the flow of instructions and data into and out of processor30. Processor30may also be called an arithmetic unit, a central processing unit, microprocessor, controller, digital signal processor, and the like. Supporting circuits may include a data cache32, an instruction cache34, and other circuits (not shown) known to those skilled in the art. Nothing requires CPU core24to include caching circuits32and34, or that separate caching circuits32and34be included for data and instructions.

System components26may also couple to internal bus28and be configured in accordance with a wide variety of circuits known to those skilled in the art of computing devices. Volatile or non-volatile memory, direct memory access controllers, other processors, and serial or parallel data link controllers are but a few of the many possible circuits that may serve as system components26.

Processor30may occasionally execute software stored in some of system components26. From the prospective of computing device10, such software will most likely be considered non-trusted software. But if adequate authentication is provided trusted software may reside in any system component, including system components26. Processor30may be configured to respond to interrupts36, and some of system components26may couple to processor30through the use of interrupts36. Those skilled in the art will appreciate that interrupts are one technique for forcing a processor to stop executing one routine and then execute another routine that services the interrupt, but that interrupts may be disabled or otherwise secured to tightly control the precise instructions that processor30executes.

Computing device10includes a trusted portion38having circuits that couple to internal bus28. In trusted portion38, data integrity is assured by any of a variety of hardware, software, firmware, and/or physical access techniques known to those skilled in the art of providing security for computing devices. To a desired degree of confidence, the designed condition of the data within trusted portion38remains sound, unimpaired, and unmolested. Some data within trusted portion38may be discoverable by non-trusted software, but unalterable by the non-trusted software. Alternatively, some data within trusted section38may be completely undiscoverable by non-trusted software.

Those portions of computing device10outside of trusted portion38are generally viewed by the software within trusted portion38as being a non-trusted portion of computing device10. In contrast to trusted portion38, the software within trusted portion38does not assume that data in the non-trusted portion have any particular bone fides, authenticity, or legitimacy. The non-trusted portion has data that can be both altered and discovered by non-trusted software. But those skilled in the art will appreciate that a physical location in a processor's address space may be non-trusted in one situation (not operating in a privileged mode) and trusted in another (operating in a privileged mode). Likewise, CPU core24may be viewed as being non-trusted when under or potentially under the control of non-trusted software, but trusted when under the control of trusted software.

Trusted section38includes a trusted execution environment (TEE) manager40. TEE manager40allows computing device10to switch from operating in a restricted execution environment (REE) to operating in the TEE. When operating in the REE, computing device10, including non-trusted software executing on processor30, operates in a non-privileged mode and cannot access or manipulate portions of computing device10considered to have a security sensitivity, but can otherwise function normally. When operating in the TEE, computing device10, including trusted software executing on processor30, operates in a privileged mode and can access portions of computing device10that have a security sensitivity as well as those portions of computing device10that have no particular security sensitivity.

In switching from the REE to the TEE, TEE manager40authenticates a privileged routine42portion of the trusted software, which is desirably stored in a trusted data section43of trusted portion38, enables security-sensitive hardware44, which is also considered to be located in trusted portion38, and passes control to privileged routine42for it to perform its access on security-sensitive hardware44. Trusted data section43is one of the sections of trusted portion38in which data, and particularly the data which constitute privileged routine42, are stored. Data integrity is assured for data stored in trusted data section43by any of a variety of hardware, software, firmware, and/or physical access techniques known to those skilled in the art of providing security for computing devices. In one embodiment, encrypted and authenticated data may have been loaded into trusted data section43from the non-trusted portion of computing device10and then decrypted and authenticated to cause privileged routine42to be located in trusted data section43. In another embodiment, trusted data section43may be configured as a read-only memory (ROM) that was programmed with privileged routine42at the time of manufacture and whose contents cannot be altered.

Security-sensitive hardware44is disabled when computing device10operates in the REE. Security-sensitive hardware44is enabled by the activation of a hardware-implemented, privileged-mode signal46. Security-sensitive hardware44is also referred to herein as selectively enabled hardware44. When privileged-mode signal46is activated, computing device10is operating in the TEE. As suggested by a connector48, which may represent either a physical or logical connection, privileged routine42is then executed by processor30. When executed, privileged routine42accesses the now enabled selectively-enabled hardware44to perform a security-sensitive function for computing device10.

Security-sensitive hardware44may perform any security-sensitive functions known to those skilled in the art. For example, cryptographic circuits that store cryptographic keys may be treated as security-sensitive hardware. Thus, cryptographic functions using these keys, such as encryption and decryption, cannot be carried out in computing device10when privileged-mode signal46is inactive and computing device10operates in the REE, but can be carried out in computing device10when privileged-mode signal46is active and computing device10operates in the TEE. Or, areas of memory located in trusted data section43may be disabled from write access, both read and write access, and/or instruction-fetch access when computing device10operates in the REE so that sensitive data may be protected, but accessible when computing device10operates in the TEE. Or, in an RF transmitter application, a transmitter's operation may be blocked and/or otherwise have operational parameters protected when computing device10operates in the REE so that improper transmissions cannot emanate from computing device10. One or more of these and/or other security-sensitive functions are intended to be included within and performed by security-sensitive hardware44.

TEE manager40couples to internal bus28. Internal bus28includes address, data, and control signals for CPU core24, and TEE manager40appears as memory available through internal bus28from which instructions can be fetched and executed and into which data can be written. Those skilled in the art will appreciate that some CPU cores may distinguish between a memory address space and an input-output (IO) address space. For the purposes of this description, such distinctions are unimportant and all such address spaces are simply referred to as memory.

In a preferred embodiment discussed in more detail below, instructions stored in TEE manager40cannot be written, at least while computing device10operates in the REE, and cannot be read as data. The signals required of internal bus28by TEE manager40are basic in nature and provided for CPU cores available from a wide variety of different manufacturers. No signal unique to any specific CPU core is required.

An interface50couples to internal bus28and to pins14of semiconductor device12. Interface50is configured so that at least signals which carry instructions from TEE manager40into CPU core24are disabled from appearing at pins14.

In an alternative embodiment (not shown), TEE manager40may be located on a different semiconductor device12from CPU core24. In this embodiment, instructions fetched from TEE manager40by CPU core24are desirably encrypted prior to being transferred through pins on that different semiconductor device and onto the semiconductor device12where CPU core24resides. After being transferred to the semiconductor device12where CPU core24resides, such instructions are decrypted prior to execution by processor30. In neither embodiment do instructions fetched from TEE manager40appear at the pins of semiconductor devices12.

FIG. 2shows a timing diagram depicting tasks and signals commonly available from any of the variety of CPU cores24which may be used in computing device10. In particular,FIG. 2depicts the execution of two representative instructions by processor30.FIG. 2depicts an immediate-operand instruction54being fetched and executed first during memory cycles1-4, followed by a memory-to-register instruction56which is fetched and executed in memory cycles5-7. In particular,FIG. 2depicts immediate-operand instruction54as being an instruction for moving an immediate operand to a memory address and memory-to-register instruction56as being an instruction for moving the contents of a memory address to a register. Those skilled in the art will appreciate that an immediate-operand instruction is one in which data to be operated upon are included in the instruction itself and fetched into the CPU core24as a part of the instruction. Immediate-operand instructions are commonly accommodated by a wide variety of different CPU's.

Instructions54and56include operational code (op code) portions58and operand portions60. Op codes58are fetched into CPU core24during cycles1and5, while operand portions60are fetched into CPU core24during cycles2-3and6. The particular immediate-operand instruction54depicted inFIG. 2includes two operand portions60for instruction54. One operand portion60specifies the “target” memory address where the immediate operand is to be written and the other operand portion60specifies the immediate operand itself. Those skilled in the art will appreciate that other immediate-operand instructions may omit the target operand but will still have the immediate operand.FIG. 2depicts one operand portion60for instruction56which specifies the address of the memory location from which data are to be moved into a register specified in the instruction's op code.

When an instruction is being fetched into CPU core24, an instruction fetch (I. Fetch) signal62is active. Instruction fetch signal62does not remain active throughout all memory cycles.FIG. 2shows instruction fetches during memory cycles1-3and5-6. An instruction fetch is a type of read operation where the data read are used as instructions to processor30. From the perspective of CPU core24, instruction fetches are a different type of memory cycle than data fetches or write operations. After an instruction has been fetched, and when the instruction is actually being executed, as occurs in cycles4and7inFIG. 2, instruction fetch signal62is inactive because no instruction is being fetched in those cycles. Thus, cycle4depicts a write cycle where the immediate operand from instruction54is written to memory. And, cycle7depicts a data fetch or read cycle where data is read from memory and placed in a register. A read signal64is active during all instruction fetch cycles, because an instruction fetch is a form—albeit a specialized form—of a read operation, and data fetch cycles (cycle7). A write signal66is active during write cycles. Signals62,64, and66are part of internal bus28(FIG. 1) and generated within CPU core24.

As discussed in more detail below, TEE manager40(FIG. 1) is desirably configured so that data stored therein cannot be accessed, at least while computing device10operates in the REE, during any cycle other than an instruction fetch cycle. This enhances security by prohibiting non-trusted software from being able to read the locations in the memory space of CPU core24where instructions are stored in TEE manager40. Such instructions may be transferred into CPU core24as instructions but not as data.

Those skilled in the art will appreciate thatFIG. 2is intended to impose no limitation on the manner in which CPU core24may operate. For example, processor30desirably executes a wide variety of other instructions than are depicted inFIG. 2, and nothing requires processor30to be able to execute precisely the instructions depicted inFIG. 2because other instructions may be used to accomplish the same tasks. Likewise, when CPU core24includes caches32and34(FIG. 1), nothing requires an instruction that has been fetched to actually be executed. This situation may occur, for example, in connection with speculative branching techniques or the activation of interrupts. And, when instructions fetched into CPU core24are actually executed, the execution may occur far later than the memory cycles where the instructions were fetched. If CPU core24is configured to support separate data and instruction busses, then all memory accesses over the instruction bus are instruction fetches, and an instruction fetch signal may be omitted. Nevertheless, the ability to determine from outside CPU core24whether a memory cycle is an instruction cycle or a data fetch cycle is a basic feature of a wide variety of CPU cores which may be used as CPU core24.

FIG. 3shows a high-level block diagram of TEE manager40from computing device10.FIG. 3depicts how TEE manager40is configured to verify that instructions fetched from TEE manager40, and not duplicates, copies or otherwise similar instructions located elsewhere in the memory space of processor30, are actually executed by CPU core24. The actual execution of the fetched instructions authenticates the trusted software of privileged routine42because only the trusted software of privileged routine42contains the correct authentication password, and the only way to present the password for validation by the TEE Manager40is to actually execute the sequence of instructions that contains the password.

TEE manager40includes a trusted data section68where instructions in the form of an authentication routine70are stored and a non-trusted data section72where data are written. Data integrity is assured for trusted data section68by any of a variety of hardware, software, and firmware techniques known to those skilled in the art of computer security. To a desired degree of confidence, the instructions stored in trusted data section68remain sound, unimpaired, and unmolested. Those skilled in the art will appreciate that no specific physical location is required of trusted data section68so long as data integrity is assured. The instructions may be fetched as instructions when computing device10operates in the REE, but may not be altered by any software executing on processor30while computing device10operates in the REE. As discussed above, the instructions may not be read as data but, desirably, only fetched as instructions.

Data may be written into non-trusted data section72at any time, including when computing device10operates in the REE. Thus, non-trusted software is free to write data into non-trusted data section72and to overwrite data previously written therein. Data written into non-trusted data section72may or may not be readable by processor30. If such data are readable by processor30, nothing need restrict such data from being readable during operation in the non-privileged mode of operation.

Trusted data section68appears to processor30as a section of memory in which authentication routine70is stored.FIG. 3depicts the authentication routine70as being four instruction pairs, with each pair including an instruction to inhibit interrupts74(CLI—“clear interrupts”), followed by an immediate-to-memory, immediate-operand (MOV) instruction54. A jump (JMP) instruction76follows the four sets of instruction pairs.

Non-trusted software, including malicious software, is free to transfer program control to any instruction in authentication routine70. But in order for computing device10to switch from the REE to the TEE, such execution should be directed to the first instruction of authentication routine70. Program execution will then sequence through the remaining instructions of authentication routine70before the TEE manager switches from the REE to the TEE.

The inhibit interrupts instructions74are configured to secure interrupts so that either no interrupts will be recognized until enabled or to control all recognizable interrupt jump vectors to point into trusted software. Instructions74are interspersed among the immediate-operand instructions54so that if program flow somehow misses execution of the first inhibit interrupt instruction74, it will nevertheless execute one of the instructions74before executing all of the immediate-operand instructions54.

FIG. 3shows that trusted data section68is associated with a password generation section78. In the preferred embodiment, immediate-operand instructions54are each configured as password-bearing, immediate-operand instructions. In particular, the immediate-operand portions60of immediate-operand instructions54convey passwords supplied by password generation section78. Thus, when processor30executes immediate-operand instructions54, the passwords are treated by processor30as the immediate-operand portions60of the instructions. In the case of the immediate-to-memory instruction depicted inFIG. 3, the target-operand portions of the instructions cause the password to be written into memory addresses associated with guess registers80in non-trusted data section72. Thus, by actually executing the password-bearing, immediate-operand instructions54, the passwords are written into guess registers80.

A variety of different techniques may be used by password generation section78, and password generation section78need not be implemented through the use of hardware. In different embodiments, password generation section78may be implemented through software, through the use of a random number generator, or through data supplied from outside computing device10during the manufacture of semiconductor device12(FIG. 1).

A control section82is configured to identify when a predetermined relationship exists between the password guesses in guess registers80and the password-bearing, immediate-operand instructions54, and to signal the privileged mode (TEE) in response to identifying the predetermined relationship. In the version of control section82depicted inFIG. 3, the predetermined relationship being identified is equivalence between the immediate-operand portions60of instructions54and the guesses in guess registers80. Thus, all passwords and guesses are fed to a comparator84. Comparator84signals when the guesses match the passwords, and an output of comparator84is fed to a logic circuit that includes a latch86for indicating whether computing device10is operating in the non-privileged mode (REE) or privileged mode (TEE). The output of latch86supplies privileged-mode signal46, discussed above in connection withFIG. 1. The logic circuit is configured so that once latch86indicates operation in the TEE by virtue of comparator84signaling a match between all passwords and guesses, it continues to indicate operation in the TEE, until an exit-privileged-mode signal88is activated to clear all guess registers80and reset latch86, thereby indicating operation in the REE.

After executing all password-bearing, immediate-operand instructions54and any corresponding instructions which write data to non-trusted data section72, program control causes the execution of jump instruction76. Jump instruction76is configured to cause program control to exit authentication routine70and execute an entry instruction for privileged routine42(FIG. 1). Of course, nothing requires jump instruction76to be included in authentication routine70. As an alternative, privileged routine42may be placed immediately after authentication routine70in the memory space for processor30, and program control will exit authentication routine70and then execute the first instruction of privileged routine42without requiring a jump instruction.

A plurality of password-bearing, immediate-operand instructions54are provided and verified by TEE manager40in the preferred embodiment for two reasons. The combined password made from all passwords taken together is much more immune to attack or accidental guessing than a single password would be. And, a potential exotic attack that attempted to coordinate interrupts with the caching of instructions might possibly lead to fetching and caching, but not executing, a single password, which could then be read from the cache. But only a portion of the combined password would be discovered in this manner, and discovery of the entire combined password would still be exceedingly unlikely.

In a preferred embodiment, password generation section78is configured so that the passwords change from time to time. Accordingly, the likelihood of a systematic attack that repeatedly writes guesses into guess registers80and tests for entry into the TEE is exceedingly unlikely to be successful.

Those skilled in the art will appreciate that many variations may be made in the theme generally presented byFIG. 3. For example, a single password might be used in lieu of the plurality of passwords discussed above. If a plurality of passwords is used, the precise number may be determined to achieve a desired tradeoff between implementation complexity and a desired amount of security. But the use of precisely four passwords as depicted inFIG. 3is no requirement.

In an alternate embodiment, passwords are not required to change from time to time. In this embodiment, a combined password having a greater number of bits might be desirable, and/or other techniques for reducing the likelihood of success in a systematic attack may be employed. Such other techniques may include limiting the frequency of permitted guesses, restricting the number of incorrect guesses that will be tolerated, and the like. Moreover, in this embodiment, it would be desirable for the manufacturer of computing device10to insure that no two computing devices10have the same password.

Authentication routine70desirably includes an instruction which writes data to non-trusted data section72, as discussed above in connection with an immediate-to-memory, immediate-operand instruction54. But this particular type of instruction is not a requirement. In an alternate embodiment, the immediate-operand portion60of each immediate-operand instruction54may be placed in a register then written to a guess register80in a separate register-to-memory instruction. And, nothing requires the exact same password fetched with an immediate-operand instruction54to be written into a guess register80. In another alternate embodiment, other instructions may cause the password to be altered, with the altered password being written into a guess register80. In this embodiment, hardware within TEE manager40would desirably perform a similar alteration or otherwise cause control section82to identify a relationship between passwords and guesses that is not equivalence.

FIG. 4shows a more detailed block diagram of a first embodiment of TEE manager40. The block diagram ofFIG. 4depicts one way to implement the theme generally presented inFIG. 3.

Trusted data section68includes a memory90that couples to internal bus28.

Memory90stores authentication routine70(FIG. 3). A portion, typically but not necessarily a few of the least significant bits, of address signals from bus28couples to an address input of memory90, and data signals from bus28couple to a data I/O port of memory90. Read signal64from bus28couples to a read input of memory90, and write signal66is gated with privileged-mode signal46in a gate92. An output of gate92couples to a write input of memory90. Gate92provides an AND function so that write access to trusted data section68and its memory90is denied while computing device10operates in its non-privileged mode (the REE). Gate92also prevents processor30from overwriting immediate-operand instructions54when selectively enabled hardware44(FIG. 1) is disabled, as signaled by privileged-mode signal46.

Another portion of address signals from bus28, typically but not necessarily more significant bits than are routed to address inputs of memory90, couples to an address decode section94. Address decode section94is desirably configured to identify when a memory cycle is being addressed to TEE manager40. An output of address decode section94couples to an enable input of memory90and also serves as disable-pins signal52, discussed above in connection withFIG. 1. When a memory cycle is addressed to TEE manager40, memory90is enabled and may be accessed, provided other conditions are met. But when a memory cycle is addressed to TEE manager40, interface50of semiconductor device12is disabled so that signals appearing on internal bus28do not pass through pins14where they might possibly be detectable from outside semiconductor12.

The output from address decode section94and instruction fetch (I. FETCH) signal62from internal bus28couple to inputs of a gate96configured to provide an AND function. An output of gate96couples to an enable input of a buffer98.

The data I/O port of memory90also couples to a first data input of a multiplexer (MUX)100, and a data output of multiplexer100couples to an input of buffer98. An output section of buffer98, when enabled, drives the data signals of internal bus28.

Together, address decode section94and gate96form a control section102. Control section102is configured to grant read access to password-bearing, immediate-operand instructions54(FIG. 3) in response to an instruction fetch memory cycle addressed to trusted data section68of TEE manager40, but to deny read access to password-bearing, immediate-operand instructions54in response to data fetch memory cycles. During such instruction fetch memory cycles, instructions, including password-bearing, immediate-operand instructions54, are read from memory90and passed through multiplexer100and buffer98to drive the data signals of internal bus28. These data signals are routed to the instruction path for processor30. Those skilled in the art will appreciate that in some architectures data and instructions have separate bus paths within internal bus28. In such architectures, the output of buffer98couples to the path for instructions, not data.

TEE manager40includes a random number generator104. Desirably, random number generator104is configured so that software, and particularly non-trusted software, executed by processor30has no influence over the random numbers produced by random number generator. An output of random number generator104couples to a second data input of multiplexer100as well as to inputs of password registers106and108. Unlike the embodiment depicted inFIG. 3which utilized four passwords, the embodiment ofFIG. 4utilizes only two passwords. Those skilled in the art will appreciate that theFIG. 4embodiment could alternatively utilize only a single password or a greater number of passwords, and that the number of password registers would be adjusted accordingly.

A password address decode section110has an input which couples to address signals from internal bus28. Password address decode section110is configured to identify when memory cycles are addressed to the specific memory locations where immediate operands60(FIG. 3) of password-bearing, immediate-operand instructions54reside. One output is provided from address decode section110for each such instruction54. The outputs couple to respective inputs of a gate112. Gate112is configured to provide an OR function, and an output of gate112couples to a selection input of multiplexer100. Accordingly, when any memory access cycle is addressed to an immediate operand60of any password-bearing, immediate-operand instruction54included in authentication routine70, multiplexer100routes a random number from random number generator104to buffer98. This random number, rather than the actual data stored in memory90, drives the appropriate data signals of internal bus28during an instruction fetch memory cycle so that the random number is fetched as the immediate operand. In addition, the random number that drives the data signals is latched into the corresponding password register106or108.

An output from gate112also couples to a control input of random number generator104to control the generation of random numbers. In this embodiment, each access to a password-bearing, immediate-operand instruction54causes a new random number to be generated. As a consequence, the password portions of immediate-operand instructions54are altered from time to time. More particularly, a password portion is altered at each access attempt. As discussed above, the altering of passwords from time to time is desirable because it makes a systematic attack having discovery of the passwords as an objective exceedingly unlikely to prove successful.

Non-trusted data section72includes a guess register address decode section114configured to identify when memory cycles are addressed to the specific memory locations where guesses registers80reside. One output is provided from address decode section114for each guess register80, and couples to a control or clock input of the respective guess register80. Inputs to guess register80are driven by data signals from internal bus28, and outputs of guess registers80couple to inputs of control section82. Thus, guesses are written to respective guess registers80when processor30executes instructions having memory write cycles addressed to the guess registers80.

Outputs of password registers106and108likewise couple to control section82. Control section82may be configured as discussed above in connection withFIG. 3. Thus, control section82verifies the existence of a predetermined relationship between passwords from trusted data section68and guesses from non-trusted data section72and activates privileged-mode signal46when the predetermined relationship is identified.

Desirably, privileged routine42is configured so that it includes a command which causes computing device10to switch back to the REE. Desirably, such a command is issued immediately prior to exiting privileged routine42. That command may be implemented as an instruction that includes a memory access addressed to a dummy guess register whose address is decoded by guess register address decoder114. The dummy guess register need not exist in hardware. But decoder114may include an output for that dummy guess register that activates exit-privileged-mode signal88, clears all other guess registers80, and toggles control section82into signaling the non-privileged mode of operation through the deactivation of privileged-mode signal46.

FIG. 5shows interaction between non-trusted and trusted software in computing device10. In particular, during the normal operation of computing device10processor30occasionally executes non-trusted software116and occasionally executes trusted software118. As mentioned above, trusted software118includes authentication routine70and privileged routine42.

Non-trusted software116may perform any manner of function or functions, including malicious functions. Non-trusted software116executes in the REE, or non-privileged mode in which selectively enabled, security-sensitive hardware44(FIG. 1) is disabled. Consequently, no harm results from the execution of non-trusted software116.

In accordance with the normal functioning of computing device10, non-trusted software116includes an instruction which essentially initiates the execution of trusted software118. Before executing privileged routine42, authentication routine70is executed to authenticate privileged routine42. In other words, the execution of authentication routine70insures that privileged routine42truly is trusted software. As discussed above, authentication routine70executes immediate-operand instructions54to cause passwords to be fetched into CPU core24as instructions and not as data, and executes instructions which write the immediate operands to guess registers80to prove that the immediate-operand instructions54were actually executed and not just fetched. The embodiments disclosed above discuss the use of a particular immediate-operand instruction54that writes its immediate operand to a guess register80, but the use of this specific instruction is not required. The immediate-operand instruction54might simply fetch the immediate operand60into a register and another instruction can then write the contents of the register to the guess register80. When the guess register80contents exhibit the predetermined relationship with the immediate-operand instructions54, privileged-mode signal46is activated, signaling operation of computing device10in the TEE, or privileged mode. While in the privileged mode, selectively enabled, security-sensitive hardware44(FIG. 1) is enabled.

Program control exits from authentication routine70to privileged routine42. Privileged routine42may perform any of a number of functions that have a security-sensitive component to them. To the extent that dedicated hardware, such as cryptographic circuits, memory, transmitter controls, or the like, is required to carry out these functions, such hardware is now enabled, and instructions within privileged routine42successfully access the selectively enabled hardware44. Eventually, the function or functions provided by privileged routine42have been performed, and program control exits privileged routine42. But before leaving, the privileged mode of operation is disabled by executing an appropriate instruction, such as the above-discussed instruction that includes a memory access addressed to a dummy guess register whose address is decoded by guess register address decoder114(FIG. 4). Following this instruction, privileged-mode signal46is inactive, security-sensitive hardware44disabled, and program control exits privileged routine42back to non-trusted software116.

Referring back toFIG. 4, the use of random number generator104to generate passwords is a preferred embodiment because the human element is removed from password generation and passwords are conveniently altered from time to time in response to data from random number generator104. No person or machine, not even associated with the manufacturer of semiconductor device12, is able to predict the value of any password with more likelihood of success than a random guess. Moreover, random number generators are often available in integrated circuits which perform cryptographic functions, as may be the case for semiconductor device12, and may be included in TEE manager40at little additional cost. Nevertheless, the use of a random number generator in TEE manager40is not a requirement.

FIG. 6shows a more detailed block diagram of a second embodiment of TEE manager40. The second embodiment ofFIG. 6differs from the first embodiment ofFIG. 4in that random number generator104and associated circuits are omitted. Rather than use a hardware-implemented random number generator, the embodiment ofFIG. 6uses passwords stored in memory90as the operand portions60(FIG. 2) of password-bearing, immediate-operand instructions54of authentication routine70. Desirably, instructions in privileged routine42are configured to alter these operand portions60from time to time. Thus, when password addresses are decoded by password address decode section110, the data fetched from memory90for that address is latched in password register106or108as it is fetched into processor30as an instruction. The contents of password registers106and108are compared in control section82with the contents of guess registers80, and when a predetermined relationship, such as equivalence, is detected, privileged-mode signal46is activated.

FIG. 7shows an alternate embodiment of privileged routine42from that depicted inFIG. 5. As with theFIG. 5embodiment of privileged routine42, privileged routine42may perform any of a number of functions that have a security-sensitive component to them. To the extent that dedicated hardware, such as cryptographic circuits, memory, transmitter controls, or the like, is required to carry out these functions, such hardware is enabled by the time privileged routine42is entered, and instructions within privileged routine42access the selectively enabled hardware44. Eventually, the function or functions provided by privileged routine42have been performed, and program control exits privileged routine42.

But before leaving, the passwords provided by immediate operands60in password-bearing, immediate-operand instructions54are desirably altered. The logic provided by gate92(FIG. 6) permits data to be written into memory90while computing device10operates in the privileged mode. Thus, prior to exiting privileged routine42, privileged routine42desirably executes instructions to get a random number (RN) and write the random number into a corresponding address for the immediate operand60of the password-bearing, immediate operand instructions stored in memory90. Desirably, such password-altering instructions are repeated for each separate password-bearing, immediate-operand instruction54included in authentication routine70. The random numbers may be obtained in a manner known to those skilled in the art, including through the use of software-implemented random number generators, which are preferably implemented using trusted software. Since trusted software is used to perform the password alteration function, security assurances are maintained.

After executing the password-altering instructions, the privileged mode of operation is disabled by executing an appropriate instruction, such as the above-discussed instruction that includes a memory access addressed to a dummy guess register whose address is decoded by guess register address decoder114(FIG. 4). Following this instruction, privileged-mode signal46is inactive, security-sensitive hardware44disabled, and program control exits privileged routine42back to non-trusted software116.

In summary, at least one embodiment of the present invention provides an improved computing device and method with entry authentication into a trusted execution environment (TEE). In at least one embodiment of the present invention a TEE manager manages a TEE for an entire system without relying on specific signals or features unique to any CPU core or operating system. In at least one embodiment of the present invention a TEE manager relies on basic features endemic to most all CPU cores and avoids operating system specific features to implement a system wide security policy that accommodates a TEE. In at least one embodiment of the present invention, a TEE manager is configured in a low overhead manner wherein relatively few gates and little processing time are required to enforce effective system-wide security policies. In at least one embodiment of the present invention, a TEE manager manages system-wide security policies for a computing device that includes any number of independent active entities, such as multiple CPU's, operating systems, DMA controllers, and the like. And, in at least one embodiment of the present invention, a TEE is provided in a manner that allows it to work in addition to and be compatible with existing supervisory or privileged modes that may be implemented in a CPU core or operating system.

Although the preferred embodiments of the invention have been illustrated and described in detail, it will be readily apparent to those skilled in the art that various modifications and extensions may be made therein without departing from the spirit of the invention or from the scope of the appended claims. For example, it may be desirable for computing device10to boot-up into its privileged mode so that trusted bootstrap programs may then be permitted to load trusted data and/or instructions into trusted data sections. And, while the above-presented discussion mentions only a single privileged routine, computing device10may be configured to have any number of independent privileged routines. In this scenario, each privileged routine may be associated with its own authentication routine, or a common authentication routine may switch program control to an appropriate privileged routine after authentication of trusted software has been assured. These and other modifications and extensions are intended to be included within the scope of the present invention.