KR20040054493A - Secure mode indicator for smart phone or pda - Google Patents

Abstract

PURPOSE: A secure mode indicator for a smart phone or a PDA(Personal Digital Assistant) executing security applications is provided to inform a user that a smart device is in a secure mode by installing the secure mode indicator to the smart device executing the security applications. CONSTITUTION: The indicator(155) such as an LED(Light Emitting Diode) is connected to the GPIO(General Purpose Input/Output) latch(154) and is lighten by responding to the GPIO. The GPIO latch is recorded by one logical value and is accessed by a core(103) through a peripheral device bus(156). Operations of the GPIO are controlled by a security signal(152) under control of an SSM(Security State Machine)(150). The GPIO latch is recorded when the security signal is in a security state that a processor(102) indicates the operation of a security software routine.

Description

SECURE MODE INDICATOR FOR SMART PHONE OR PDA}

The present invention relates generally to microprocessors and, more particularly, to an enhancement of a security mechanism for supporting secure software services.

Microprocessors are general purpose processors that provide high instruction throughput to execute software thereon and may have a wide range of processing requirements depending on the particular software applications involved. Many different types of microprocessors are known, such microprocessors being just one example. For example, digital signal processors (DSPs) are widely used in particular applications, especially mobile processing applications. DSPs are typically configured to optimize the performance of related applications and to employ more specialized execution units and instruction sets. In applications such as mobile telephony, it is particularly desirable, but not exclusively, to provide improved DSP performance while keeping power consumption as low as possible.

To further improve the performance of the digital system, two or more processors may be interconnected. For example, a DSP may be interconnected with a general purpose processor within a digital system. The DSP performs numerically intensive signal processing algorithms while the general purpose processor manages the entire control flow. The two processors communicate and transmit data through the shared memory for signal processing. Direct memory access (DMA) controllers are often associated with a processor to take the burden of transferring data blocks from one memory or peripheral resource to another, thereby improving the performance of the processor.

An operating system is generally provided to manage a digital system by controlling resources and scheduling the execution of various program modules or tasks. In a system with several processors, it may be convenient to have a separate OS for each processor. In general, it is assumed that the OS controls all system resources. Many operating systems are not designed to share memory and resources with other operating systems. Therefore, resource allocation problems may arise when two or more OSes are combined into a single system. Conflicts across memory or peripheral devices can have extreme consequences for system operation.

Most processors consist of two privilege levels, one for the OS and the other for user tasks. There were also proposals for a third privilege level, but this is rarely implemented on current CPUs.

Some operating systems are certified as security for special financial or security-critical applications. Some general-purpose operating systems claim to have built-in security, but their vulnerability is well known.

Hardware mechanisms can be adopted to improve security. For example, US Pat. No. 4,590,552, entitled Security Bit For Designating The Security Status Of Information Stored In A Nonvolatile Memory, can be set permanently to prohibit off-chip resources from accessing the on-chip memory. By providing the above security bits, a mechanism for securing data storage by protecting code or data stored in on-chip memory is disclosed. However, the biased operation of the operating system can overcome such security measures.

On smart devices that can provide security levels for applications such as mobile commerce (mobile commerce) or electronic banking, users can enter secret information such as passwords on the keyboard or on the screen. It is requested to sign the displayed messages. In doing so, the user has no choice but to fully believe in the integrity of his device. However, the user has no way of detecting that a hacker or a virus has defeated the security framework of his device.

Therefore, there is a need for improvement in system security. In general terms, in accordance with aspects of the present invention, a digital system is provided with a security mode (third privilege) embedded in a non-intrusive manner on the processor system. Thus, a secure execution mode is provided on a platform where only trusted software is code stored in on-chip ROM. An indicator means that is observable by a user of the digital system is provided, which can only be activated by program code that is trusted during the secure mode of operation.

In one embodiment, the secure mode is entered through a unique entry point. The secure execution mode can be dynamically entered or exited by entirely hardware evaluation of entry / exit conditions.

1 is a block diagram of a digital system including one embodiment of the present invention in a megacell having multiple processor cores.

FIG. 2 is a block diagram of an MPU block in the system of FIG. 1 illustrating a distributed security configuration using a combination of selected hardware blocks with an execution environment of protected software implemented by a Security State Machine (SSM). to be.

FIG. 3 is a block diagram illustrating the contents of the ROM of FIG. 2 and a circuit for separating the ROM into a common part and a security part.

4 is a flowchart illustrating access to a secure mode of operation on the system of FIG. 2.

5 is a state diagram illustrating the operation of a secure state machine in the system of FIG.

6 illustrates a wireless personal digital assistant comprising an embodiment of the present invention.

<Explanation of symbols for main parts of drawing>

100: megacell

102: microprocessor

103: hardware accelerators

104: digital signal processor

105: DSP core

106: direct memory access controller

136: frame buffer

138: display device

150: Security State Machine (SSM)

152: security signal

154: GPIO latch

155: security indicator LED

200: CPU

310: security ROM

312: secure SRAM

316a, b: secure peripherals

10: personal digital assistant (PDA)

14: display

12a, 12b: input sensors

Specific embodiments according to the present invention will now be described, by way of example, with reference to the accompanying drawings, in which like reference numerals are used to indicate like parts, and unless otherwise indicated, the drawings are shown in FIG. 1. Related to the digital system.

The exchange of information of interest to the user, such as passwords or messages displayed on the screen, should only be performed when the processing device is in a secure mode. An apparatus and method for providing a secure mode is described in European Patent Application No. 02100727.3, filed on June 30, 2002, pending the title "Secure Mode For Processors Supporting MMU and Interrupts." A full description of the security mode is described herein to enable those skilled in the art to understand the operation.

In secure mode, access to a physical user interface, such as a keyboard or display, is restricted to secure applications through trusted drivers. The fact that access to the keyboard and display are locked by the secure mode is not enough to secure all exchanges with the user. The inventors of the present invention have found that there is a need for means to instruct the user whether the OS has invoked a suitable trusted keyboard or display driver, i.e., a driver stored in secure mode memory and entering a secure mode for execution. Otherwise, if a virus / hacker tries to download a fake driver onto a smart device, there is no way for the user to know that he or she cannot trust his device.

According to a feature of the present invention, a smart device executing secure applications will have a security mode indicator in addition to the display and keyboard. This indicator will inform the user that the device is in secure mode. The indicator may, for example, be a small LED. If the security mode indicator is not activated, the user must not enter any secret information (password) or sign anything on the screen. If you are prompted to enter his pin code while the indicator is inactive, the user will understand that his device has been compromised and the device cannot provide security operations.

To implement this functionality, a general purpose input / output (GPIO) latch bit 154 is provided on the digital system of FIG. 1 that can only be accessed in secure mode. This secure GPIO latch is used to drive the security indicator LED 155. Trusted keyboard and display drivers running in secure mode from secure read only memory / static random access memory (ROM / SRAM) are responsible for managing secure GPIO latches.

The secure mode indicator should be independent of the keyboard and display because non-secure application software must be able to access these devices in non-secure mode. In particular, messages such as "Please enter your password" displayed on the screen are generally unreliable. In addition, a code or a message displayed on the screen, such as a lock code for indicating a security operation, is not reliable because the screen can be accessed by the hacked code. The secure mode indicator shall only reliably indicate when the device is operating in secure mode. If the security mode indicator is not activated, the user should not be prompted to enter confidential information such as a password or to sign anything on the screen.

1 is a block diagram of a digital system including an embodiment of the present invention in a megacell 100 having a plurality of processors 102, 104. For clarity of explanation, FIG. 1 illustrates only the megacell 100 portions that relate to understanding embodiments of the present invention. Details of the general configuration of digital signal processors (DSPs) are well known and will be readily available from other sources. For example, US Pat. No. 5,072,418 to Frederick Boutaud, et al. Details DSP. U. S. Patent No. 5,329, 471 to Gary Swoboda, et al describes in detail how to test and emulate a DSP. Details of portions of megacell 100 related to embodiments of the present invention are described in sufficient detail below to enable those skilled in the microprocessor art to practice and use the present invention.

Although the present invention has found special applications for digital systems implemented in, for example, Application Specific Integrated Circuits (ASICs), applications for other types of systems can of course also be found. The ASIC may include one or more megacells, each having customer design functional circuits combined with pre-designed functional circuits provided by the design library.

A distributed security system is provided within megacell 100 that utilizes a combination of selected hardware blocks and a protected software execution environment. A distributed security system is a solution for solving electronic commerce (e-commerce) and mobile commerce (m-commerce) security problems within a mobile phone environment. Security issues include the following:

Confidentiality: ensures that only communicating parties know the content of the transmitted information.

Integrity: ensures that the information has not changed during transmission.

Authentication: Ensures that the person with whom you communicate is the person he claims to be.

Non repudiation: This ensures that the sender cannot deny sending a message.

Consumer protection: pseudonym and anonymous

-Copy protection

Current operating systems (OSs) cannot be considered safe. Some OSs claim to be secure, but their complexity makes it difficult to achieve or guarantee this security. For electronic-commerce and other secure transactions, a secure software layer is needed. It should be transparent to existing OSs, support interrupts in real time, and support memory management unit (MMU) and cache usage while the OS supports it.

In many applications, software only solutions are not powerful enough, and these problems can only be solved through a well-coupled hardware and software architecture. The security mode used in this embodiment was developed to give robustness to the overall security scheme and is based on the following assumptions.

The operating system is not reliable.

The native software running on the platform is not reliable.

Only trusted software is code stored in the security program ROM / SRAM.

Caches may be activated for performance reasons.

Interrupts can be activated for real time reasons.

MMU can be activated for flexibility.

The above assumptions result in: First, OS memory management is not reliable. In other words, MMU operations and OS-defined translation tables are unreliable. The secure mode must be resistant to any misuse of the MMU and must be resistant to the fact that OS defined translation tables can be tampered with. Second, OS-defined interrupt vector tables and interrupt service routines are not reliable. There is a need to implement special management of interrupts in secure mode so that the secure mode is resistant to any misuse of interrupts and tolerates the fact that the interrupt vector table and ISR can be tampered with. Third, context storage, cache flush, TLB flush, write buffer draining, etc. are not secure and the security mode should not depend on them. Last but not least, all test, debug, and emulation capabilities must be disabled in secure mode.

In this embodiment, a partitioned "secure mode" is created for the processor 102 so that the processor 102 can act as the sole "virtual secure processor" while executing security operations. The secure mode can be thought of as the third privilege level for the processor 102. Its activation relies on the presence of special purpose hardware that creates an environment for protecting critical information from access by untrusted software. The security mode is established by the assertion of a dedicated security signal 152 that propagates across the system and creates a boundary between resources that can be accessed by trusted software and resources that are also available to any software.

Activation of the security mode also depends on proper control by the security software. The security software is stored in and executed from the security program ROM / SRAM. There are no possible flows where untrusted code can trick the hardware into secure mode, or cause trusted code to perform tasks that it should not do. Once the boundary is properly created, there should be no way to use the normal operations of the processor to move information from inside to outside, except through controlled operations. Note that the normal operation of a processor involves executing a potentially defective "user-code".

The security software layer is trusted and stored in secure memory. This is entered through a software sequence indicating to the hardware security state machine (SSM) 150 that it is indeed executing the secure code, by passing in a secure mode through a single, secure gate while preventing MMU tampering. While the security software is operating in secure mode, the interrupt vectors are readjusted, if necessary, to allow the security control software to begin proper exit from the secure mode. The remediation process is transparent to the OS and prevents any secure data from becoming visible after the transition.

GPIO latch 154 is a memory-mapped latch that operates in a conventional manner except that it can only be accessed and activated by security software. Indicator 155 is coupled to GPIO 154 and illuminated in response to GPIO. Indicator 155 is turned on by writing one logic value, for example logic 1, to latch 154, and turned off by writing a complementary logic value, logic 0, for example, to latch 154. The latch 154 is accessed by the core 103 via the peripheral bus signal 156. However, the operation of GPIO latch 154 is controlled by security signal 152 controlled by SSM 150. Therefore, the GPIO latch 154 can be written only when the security signal 152 is in a secure state, indicating that the processor 102 is executing a security software routine. In this embodiment, the indicator 155 is a light emitting diode (LED), but in other embodiments any type of indicator may be used indicating two different states, on and off. For example, various types of lamps may be used, such as neon, plasma, and the like. Various mechanical devices may be used, such as rotating disks to indicate different colors to indicate on / off states, or actuators to move indicators to indicate on / off states. In other embodiments, the two states may also be dictated by the surface change of the texture, the height, the temperature, and so on, so that even the visually impaired or otherwise physically impaired person can detect the two states. For example, a tactile indicator may be provided in connection with the braille display device. In another embodiment, the indicator may provide an audio indicator, for example, a tone may be played to indicate that the secure mode state is on, but the tone may be imitated by a non-secure audio source, which may be appropriate. Attention is required.

Referring back to FIG. 1, megacell 100 shares a microprocessor (MPU) 102 with a 32 bit core 103 and a memory block 113, referred to as a level 2 (L2) memory subsystem. A digital signal processor 104 having a DSP core 105. Traffic control block 110 receives a transfer request from a host processor coupled to host interface 120b, a request from control processor 102, and a transfer request from a memory access node within DSP 10. Traffic control block 110 interleaves these requests and sends them to shared memory and cache. Shared peripherals 116 are also accessed through a traffic control block. The direct memory access controller 106 can transfer data between the off-chip memory 132 or the on-chip memory 134 and the shared memory. Various application specific processors or hardware accelerators 108 may also be included in the megacell as needed for interaction with the DSP and the MPU through the various applications and traffic control block.

Outside the megacell, a level 3 (L3) control block 130 is connected to receive memory requests from the internal traffic control block 110 in response to an explicit request from the DSP or MPU. Off-chip external memory 132 and / or on-chip memory 134 are connected to system traffic controller 130, which are referred to as L3 memory subsystems. Frame buffer 136 and display device 138 are connected to a system traffic controller to receive data for displaying a graphical image. The host processor 120a interacts with external resources through the system traffic controller 130. The host interface 120 connected to the system traffic controller 130 enables access by the host 120a to external memories and other devices connected to the traffic controller 130. Thus, the host processor may be connected at level 3 or level 2 in various embodiments. The set of private peripherals 140 is connected to the DSP, while the other set of private peripherals 142 is connected to the MPU.

2 is a block diagram of an MPU 102 in the system of FIG. 1 illustrating distributed security using a combination of selected hardware implemented by the secure state machine 300 and a protected software execution environment. In other embodiments of the digital system, the processor 102 may exist as a single processor or may be connected with one or more other digital systems, for example, for collaboration.

The security mode is the "third level of privilege" for the processor 102. The secure mode provides hardware means for restricting access to secure resources of the processor subsystem (CPU) 200 if a suitable execution environment has been established. The secure mode is installed around the CPU 200, which includes a processor core, data and instruction code caches 204 and 206, and an MMU 210. Preferably, the security features of this embodiment are non-intrusive to CPU 200, and in other embodiments other processors may be used instead of this processor.

There are two types of security hardware, one of which is the logic that controls the security signal, and the other is the hardware resources specific to the security mode. The former mainly consists of a secure state machine (SSM) 300. SSM 300 functions to monitor conditions for entering a secure mode, assert / de-assert security signal 302, and detect security mode violations. The violation is indicated by asserting a violation signal 304 connected to the reset circuit 306 to cause a system reset when a security breach is detected. The secure state machine monitors the various signals 330 from the external interface of the processor 200 and in particular addresses fetched by the processor on the command bus. The secure state machine is tightly coupled to the low-level assembly code from the entry sequence. This responds to events generated by the entry sequence on the monitored signals.

The security mode is entered when the security signal 302 is asserted. When a security signal is asserted, it propagates through the system to remove restrictions on access of security resources. Only processor 200 can access secure resources in secure mode. DSP 104 and DMA 106 are not allowed access to secure resources by the design constraints in this embodiment. Secure resources of this embodiment include secure ROM 310 (part of the entire ROM), secure SRAM 312, and various secure peripheral devices 316a, 316b. Similarly, access to GPIO latch 318 is also controlled by security signal 302 such that GPIO 318 is active, indicating that security signal 302 indicates that CPU 200 is executing a security software routine. Only when in a state can it be recorded. Security signal 302 is asserted by secure state machine (SSM) 30 under certain conditions. In the secure mode, the CPU 200 may execute only code stored in the secure ROM 310 or secure SRAM 312. Any attempt to execute code stored outside of these trusted places will generate a "security breach" by asserting a signal 304 that will cause the reset circuit 306 to perform a global reset of the system. will be.

This ROM is partitioned into two parts, one of which is the secure part of the ROM protected by the security bits, and the other is the public part of the ROM that is always accessible and contains the boot area. The common ROM 311 also includes various security procedures and participates in the overall security scheme.

Secure storage RAM 112 is where secure work data (secure stack, secure global data, secure heap) is stored. Secure program RAM 312 (optional) is dedicated to the execution of non-resident secure code. The non-resident security code is first downloaded from the external memory device into the secure program RAM and then authenticated before being executed.

Several byte addresses in the secure storage SRAM are implemented by registers 306 that are reset by a global reset signal. These registers shadow some normal SRAM locations and can be used as generic SRAM addresses. The only difference is that these registers / SRAM locations will all be reset to the value 1. It is desirable to have a few variables that can be reset in the secure mode and therefore have a known initial value and can only be changed in the secure mode. For example, this feature can be used for first entry detection in secure mode, setting appropriate exit_mode values (normal, exception, violation), power on detection, and the like. In other embodiments, these resettable values may be implemented in other ways, for example, by placing registers in an address space that does not overlay the SRAM, or by connecting a reset signal to selected memory cells in the SRAM.

There is no software way to cause the security signal 302 to be asserted or to change the behavior of the state machine. The SSM is closely coupled to the activation sequence, which will be described in more detail with reference to FIG. The SSM monitors the physical instruction address bus 330 from the processor 200 and various entry condition signals 321-327 received from various resources. Command interface signals 331 and data interface signals 333 from the processor 200 are also monitored, and what types of transactions are to be performed on the command bus 330 and the data bus 332 respectively. .

The secure mode is entered by branching to a special address in the common ROM, which is referred to as a single entry point, that is, hard code in the SSM. The entry point is the start address of the "activation sequence". The activation sequence is code stored in a common ROM coupled to the secure state machine and ensures that entry conditions for the secure mode are met. Other entry conditions are evaluated directly by monitoring special entry condition signals.

The activation sequence generates a defined sequence of events for some of the signals monitored by the security state machine. These events ensure that the conditions needed to enter the secure mode are met. The security state machine recognizes this pattern and asserts a security signal. In secure mode, the security state machine detects security mode violations and ensures that security mode exit procedures are followed. When a violation occurs, the SSM releases the security signal and asserts the security violation signal 304. A typical violation is to fetch instructions outside the address range of ROM / SRAM.

The activation sequence is stored in the common ROM. This ensures that secure mode entry conditions are met. The configuration sequence is stored in the secure ROM. This establishes a suitable execution environment for caches, interruption, and a secure mode in which the MMU can be activated. Exit sequences are stored in secure ROM. It enforces compliance with the security mode exit procedure. It provides a secure way to exit secure mode by BRANCH or under an interrupt. It also protects the "secure" content of the secure ROM and RAM upon exit.

Further referring to FIG. 2, the security control register 319 is accessible as a memory mapped register only in secure mode and can be used to break security by a hecker, but it is necessary to test, debug, to control and debug system hardware and software. , And to enable / disable emulation facilities. For example, one bit indicated by signal 321 enables / disables operation of embedded trace macrocell (ETM) 350 used for program development. Signal 322 enables / disables operation of the JTAG interface on processor 200. Signal 323 enables / disables operation of debug interface (dbg I / F) on processor (200).

The secure condition register 320 is accessible as a memory mapped register in the non-secure mode and establishes a portion of the entry condition in the secure mode by controlling the operation mode of the various resources that can be used to break security by hackers. Used for. Signals issued from the secure condition register are also monitored by the state machine. For example, direct memory access (DMA) enable signal 324 is used to enable a DMA controller (not shown) that can access secure memory 312.

In this embodiment, the scan chain interface Scan I / F is provided for testing and may provide a security breach point. However, processor 200 does not provide a means for disabling scan chain output. In order to avoid altering the internal signals of the processor 200, a scan gate 342 is provided externally to mask the scan output of the processor 200 for a number of clock cycles, such as the longest scan chain in the processor 200. Used. This masking scheme is initiated at reset (counter reset) and every time the device is switched from the functional mode to the test mode with the scan enabled under the control of an external test apparatus (not shown).

An external interrupt handler 360 is provided to receive the set of interrupt signals and multiplex them into two interrupt signals 362 and 363, which are then received by the processor 200. Interrupt handler 360 has a global mask bit 364 that can be set by software and allows the software to globally disable all interrupts to the processor. The interrupt controller asserts the mask signal 325 whenever the global mask bit is set and the interrupt signals 362 and 363 are deactivated. After the mask signal 325 is asserted, the interrupt signals 362, 363 output by the interrupt controller can no longer be asserted until after the global mask bit is cleared by software. SSM 300 monitors mask signal 325 to determine whether interrupts are enabled or masked.

Booting from external memory is a common means for heckers to compromise security in the system. In this embodiment, external booting is prohibited. The SSM 300 also monitors the boot signal 327 asserted when an external boot is attempted. However, it may be beneficial to allow external boot to better debug the software during program development. A fuse circuit 328 is provided to identify the development device from the manufacturing device. The device-type signal 326 is monitored by the SSM 300 to allow a relaxed security mode to be provided on the development devices. For development devices, SSM 300 ignores boot signal 327.

3 is a block diagram illustrating the contents of the ROM of FIG. 2 and a circuit for separating the ROM into a shared portion and a secure portion. The common ROM 311 and the secure ROM 310 are implemented as a single ROM in this embodiment. In other embodiments, they may be separated without affecting the character of the invention. The address decoder circuit 370a is part of the decode circuit 370 that decodes the addresses for the ROM. Similar circuits are provided for devices connected with SRAM and other command or data buses.

The driver circuit 400 responds to the address decode signal 406 or 407 corresponding to each of the common ROM address or the secure ROM address, so that an address corresponding to the ROM 310, 311 is stored on the command address bus 330a. Each time it is written, it is enabled to provide the requested command data on the command bus 330b.

As mentioned above, dummy data is provided when a secure resource is accessed when it is not in secure mode. The gate circuit 404 monitors the security signal 302 and the security ROM decode signal 407, and if the security ROM is being accessed and the security signal has not been asserted, the driver circuit 400 returns null data. Cause delivery.

4 is a flowchart illustrating access to a secure mode of operation on the system of FIG. 2 and will be described in more detail below. Steps 500, 502, and 504 represent an application program running on processor 200 in execution of normal, non-privileged levels. Occasionally, as indicated in steps 510, 512, 514, 516, an operating system (OS) is invoked 502 for service at the privilege level of the operation. When invoked, the OS saves the state in step 510, switches to privileged mode, performs the privilege operation in step 514, restores the state in step 516, and returns to the non-privileged application of step 504. These two levels of operation are well known.

In step 512, it is determined whether the requested service is for a security operation, and if so, the system will enter a third security level called security mode. In step 520, the OS driver performs a cleanup task task to place the system in the proper state for entering the secure mode. This sets the security condition register 320 to mask interrupts, disable various resources that may pose a security risk, and if the memory management unit 210 is enabled, the page table entry corresponding to the active sequence is " Verifying that it is marked "not cacheable". This will be explained in more detail later.

In step 522, referring back to FIG. 3, a jump occurs to entry point 410 in entry sequence 412 located in common ROM 311. An entry sequence is codes that are executed each time a "security service" is called by the application before executing any type of security code on the platform. This sequence is also executed when returning from the exception that interrupted the execution of the security code. The entry sequence starts at a defined address that is hard-coded in the ROM and called an “entry point”. The entry sequence consists of two parts, one of which is a secure signal activation sequence 413 and the other is a secure mode configuration sequence 414.

The purpose of the active sequence is to take over the flow of execution of the processor 200 and to ensure that it is not preempted by any other untrusted code. During this portion of the entry sequence, at some point, a security signal 302 is asserted to enter a secure mode and to remove restrictions on access of secure resources (ROM, SRAM, peripherals, etc.).

The purpose of the environment sequence 414 is to set up an environment for secure code execution. Preferably, by setting up a secure environment, it is possible to securely enable program and data caching and to handle interrupt exceptions.

The secure signal activation sequence 413 is placed in the public ROM, while the secure mode configuration sequence 414 is placed in the secure ROM. The total code size of the entry sequence (first part + second part) is required to be 1 Kbyte or less, so that it can be mapped in a minimum memory section 1 KB page in the MMU transaction tables of this embodiment. In this manner, entry sequence virtual addresses cannot be mapped across two sections to preemptively attack the processor at any suitable point during the execution of the entry sequence. It is also important that the memory page of the entry sequence is cache-capable or the instruction cache is disabled during entry sequence execution.

Security translation table (STT) 420 and security interrupt vector table (SIVT) 430 will be described in more detail later.

If the 1 KByte code size seems too limited for a given embodiment, then the MMU may be disabled at the end of the active sequence 413 and re-enabled at the end of the environment sequence 414. In this case, the 1 KByte constraint would apply only to the active sequence.

Referring again to FIG. 4, as will be described in more detail with respect to FIG. 5, at step 524 the active sequence is checked for accuracy by the SSM 300. If the activation sequence is not performed correctly, the SSM 300 asserts a violation signal at step 540 and the system is reset. The secure environment, as will be described in more detail later, is set up in step 526 by executing the configuration sequence 414.

Once the secure environment is established, the security operation requested in step 528 is executed from the security code 416, as originally requested by the non-privileged application. According to one aspect of the present invention, security code 416 includes instructions to write to GPIO latch 318 in step 528.1 to turn on security mode indicator 319 only during the secure mode. Security code 416 may then request the user to provide the secret information at step 528.2, and then turn off the security mode indicator at step 528.3 by writing back to the GPIO latch. Additional security processing is performed in step 528.4. It should be understood that this particular sequence is for illustration only. For example, other security processing may be performed before turning on the security mode indicator. The security mode indicator may be turned on for a moment, then turned off for a while, and then turned on again. If requested by the application program, numerous other sequences can be performed.

After completion of the security operations, the normal way to exit the security mode in step 530 is to jump to the "normal exit sequence" in the secure ROM exit sequence 418. The purpose of a normal exit sequence is to conform to a secure mode exit procedure and to ensure protection of "secret" content at the exit. The normal exit procedure can be located anywhere in the secure ROM, and there is no hard-coded address check in the secure state machine.

While in secure mode, SSM 300 continues to monitor signals 321-327 and 331. Based on these signals, the SSM can detect a security breach. Whenever a violation of the security mode occurs, the SSM detects it, releases the security signal, and generates a security violation, as indicated at arc 542. The violation causes a global reset of the device. A security breach drives the SSM into a blocking state, which can only be excited by a reset. The following violations may be detected: violation 1-instruction is fetched at an address outside the full ROM and RAM address range, violation 2-processor 200 is reset, violation 3-test, emulation, or debug functions Activated.

When an exception occurs, the processor 200 jumps to the corresponding exception vector in the interrupt vector table ITV and sends it back to the specific interrupt routine. IVTs are generally managed by the OS and are not placed in secure SRAM. Thus, its content is not protected and cannot be trusted. Furthermore, from a security point of view, the processor cannot accept a jump directly to the exception vector for two reasons: (1) out of the secure memory address range, incompatible with the entire security scheme. "Jump" is considered a security breach, and (2) caches and processor registers are filled with "secret" content, which needs to be cleared before the security bit is cleared and the non-secure code is executed. In order to allow interrupts while in secure mode, a secure IVT is provided.

5 is a state diagram illustrating the operation of the secure state machine 300 in more detail. The secure state machine asserts a security signal at some point during the execution of an active sequence in the ROM to enter the secure mode. The purpose of this part of the entry sequence is to generate a defined sequence of events for the signals probed by the secure state machine. These events are responsible for satisfying the conditions required to establish a security signal, which are tracked by the SSM. The "condition" signals are continuously monitored during the active sequence. If any of the etry conditions have not been met or have ceased validity before the end of the active sequence, the security state machine will transition to violation state 630 and assert a security violation signal 304. There are two important objectives behind the entry conditions monitored by the SSM. That is, except that (1) the processor 200 fetches the active sequence code and executes it above all, and (2) allows the trusted code to fully take over the CPU execution flow, and through controlled control operations, Nothing is intended to prevent preemptive attack before or after the security signal is set, without being detected.

The active sequence is constructed in such a way as to generate a unique pattern on the command address bus. The pattern consists of the (physical) address values of the active sequence codes and the relative time these addresses should appear on the bus. Nevertheless, the pattern is made independent of the memory system access delay. The exact active sequence bus pattern is obtained from the simulation and hard-coded in the SSM. Thus, the SSM guarantees full compliance with the active sequence bus pattern. Typically, the last instruction in the active sequence is a branch instruction, and all other instructions in the active sequence other than the cache flush instruction or the cache disable instruction are NOP instructions.

After entering the secure mode and the security signals are asserted, the entry conditions do not need to be valid and the SSM does not continue to test them. However, the SSM continues to probe several signals to detect security mode violations, as described later. Secure mode exit conditions are not tested until secure memory is entered.

Referring again to FIG. 5, state 600 is an idle state while the SSM monitors the address bus 330 to find the entry point address (ESA [EP]) of the entry sequence. Once the entry point address is detected, the SSM transitions to state 601 if all entry conditions have been met, otherwise transitions to violation state 630 to assert the violation signal 304.

Each of states 601-615 must be traversed sequentially by detecting the correct entry sequence address and corresponding entry condition signals, otherwise the SSM transitions to violation state 630. If the sequence has been traversed correctly, security mode state 620 is entered and security signal 302 is asserted.

For example, to transition from state 600 to state 601, the address of the entry point command must appear with all correct condition signals. The next address that appears should be the address of the next sequence command to transition to state 602, or the SSM transitions to violation state 630. In a similar manner, each address in the active sequence must appear to transition to states 602-615 and finally to secure mode state 620. Changes in incorrect address, address timing, or inaccurate condition signals will result in a transition to violation state 630, as indicated by arc 601a. Similarly, the active sequence is disabled if the status signals indicate that any one of the active sequence accesses is cacheable.

If it is detected by the SSM while in secure mode state 620 and validly detected that the address (ESA [SR]) of the security routine is in secure memory, then it is indicated by arc 621, as indicated by SSM. Likewise, the SSM transitions back to idle mode 600. If a security violation is indicated by the SSM that an address is outside of the ROM or SRAM, or is indicated by an incorrect change in the monitored signal, the SSM transitions to a violation state 630 as indicated by arc 622.

The instruction cache does not need to be disabled during the active sequence, and is sufficient to ensure the robustness of the entry sequence due to cache-inability of the instruction. Nevertheless, having the cache disabled will eliminate hacking attempts based on exploitation of cache flush mechanisms.

Secure Mode Preference Sequence

Referring again to FIG. 4, at step 526, the secure environment is set up by executing a configuration sequence 414 from the secure ROM. The purpose of this sequence is to set up a suitable environment for secure code execution. The secure environment enables program and data caches, real-time interrupts, and potentially MMUs. Some of these steps are specific to secure mode operations, and some are operations that should have been performed normally by the OS before invoking the active sequence. As discussed above, the secure mode cannot trust basic OS operations. Therefore, the configuration sequence needs to perform some of the context switch operations, such as cache flush, TLB flush, etc., which are essential for secure mode integrity.

System embodiments

FIG. 6 illustrates a mobile telephony device, such as, for example, a display 14, and a personal digital assistant (PDA) 10 having integrated input sensors 12a, 12b disposed around the display 14. The preferred embodiment of the integrated circuit in which the present invention is implemented is shown. The digital system 10 includes a megacell 100 according to FIG. 1 connected to input sensors 12a via an adapter (not shown) which is an MPU private peripheral 142. A stylus or finger can be used to enter information into the PDA through input sensors 12a and 12b. Display 14 is connected to megacell 100 through a local frame buffer similar to frame buffer 136. Display 14 provides graphical and video output within overlapping windows, such as, for example, MPEG video window 14a, shared text document window 14b, and three-dimensional game window 14c.

A radio frequency (RF) circuit (not shown) is connected to the antenna 18 and driven by the megacell 100 as the DSP private peripheral 140 to provide a wireless network link. The connector 20 is connected to a cable adapter modem (not shown), which in turn is connected to the megacell 100 as a DSP private peripheral 140, for use during static use, for example in an office environment. Provide a wired network link. The short range wireless link 23 is also driven by a low power transmitter (not shown) connected to the handset 22 and connected to the megacell 100 as a DSP private peripheral 140. Microphone 24 is similarly connected to megacell 100 so that bi-directional audio information can be exchanged with other users over a wireless or wired network using microphone 24 and wireless handset 22.

Megacell 100 provides all encoding and decoding for audio and video / graphic information transmitted and received over a wireless network link and / or a wired network link. Preferably, megacell 100 also provides a secure mode operation. As described herein, the secure mode indicator lamp 30 can only be turned on by code executed while the megacell 100 is running in secure mode. As a result, the security mode indicator lamp 30 instructs the user of the PDA 10 when it is safe to provide the data of interest to an application running on the PDA. In this way, PDA 10 provides a solution for solving electronic commerce (e-commerce) and mobile commerce (m-commerce) security problems in a mobile phone environment.

Of course, many other types of communication systems and computer systems are also contemplated to benefit from the present invention. Examples of such other computer systems include portable computers, smart phones, web phones, and the like. Since security is also a concern in desktops, wired-powered computer systems, and micro-controller applications, in particular in view of reliability, it is contemplated that the present invention may also benefit such wired-powered systems.

Fabrication of the digital system 100 involves a number of steps of injecting various amounts of impurities into a semiconductor substrate and diffusing the impurities to a selected depth within the substrate to form transistor devices. Masks are formed to control the placement of the impurities. Multiple layers of conductive and insulating materials are deposited and etched to interconnect the various devices. These steps are performed in a clean room environment.

A significant portion of the cost of manufacturing data processing devices is related to testing. While in wafer form, the individual devices are biased into the operational state and the basic operation functions are probe tested. The wafer is then separated into individual dice that can be sold in bare die or packaged form. After packaging, the finished parts are biased into the operational state to test the operation function.

As used herein, the terms “applied”, “connected” and “connected” mean electrically connected, and additional elements may be in the electrical connection path. The term "associated" means a controlling relationship, such as in a memory resource controlled by an associated port. The terms assert, assert, deassert, deny, deny, deny are used to avoid confusion when dealing with the hybrid of active high and active low signals. Assertions and assertions are used to indicate that a signal is active, or given logically true. De-asserts, de-asserts, denies, and denies are used to indicate that a signal is given as inactive or logically false.

Thus, the digital system is equipped with a secure mode (third level of privilege) embedded in a non-intrusive manner on the processor system including the processor core, instruction and data caches, write buffer and memory management unit. Secure execution mode is provided on the platform where only trusted software is code stored in ROM. In particular, the OS is not trusted, and not all native applications are trusted. The secure mode indicator is provided to inform the user that the device is in secure mode.

Although the present invention has been described with reference to exemplary embodiments, this description should not be considered as limiting. It will be apparent to those skilled in the art that various other embodiments of the invention are possible with reference to the description herein. For example, all types of processor types, such as RISC, ISC, wide word, DSP, etc., can be enhanced by using the security mode functionality described herein.

In another embodiment, the security environment may be extended to allow sharing of some initiator resources, for example security resources between DSPs. In such embodiments, each initiator resource may be monitored by a secure state machine to implement the security principles described above.

In different embodiments, different security hardware supplements may be provided, including various peripherals such as watchdog timers, encryption / decryption hardware accelerators, random number generators (RNGs), and keypads, LCDs, touches, etc. Various I / O devices, such as screens, are included.

Referring again to FIG. 1, in another embodiment, a second SSM may be implemented in the DSP 104 to generate a security signal in a similar manner as on the processor 102 for the security software layer executing on the DSP 104. have. In this embodiment, a bused version of the security signal is included in the traffic control bus 110 such that individual transactions initiated by the processor 102 or the DSP 104 depend on the security signal generated by each SSMs. Access to secure resources, such as specific ones of the shared peripherals 116, may be granted.

Referring again to FIG. 1, in another embodiment, the security signal may be extended from the megacell 100 such that level 3 resources may be operated in a secure manner.

Active sequences, environment set-up sequences, and exit sequences may vary depending on the requirements of various embodiments. For example, different instruction pipeline lengths and different cache line lengths require changes in the active sequence. In another embodiment, the cleanup task tasks performed in step 520 may be included in the active sequence.

In another embodiment, the means for entering into the secure mode may be different than the SSM described herein. Once the security mode of the operation is obtained by any means, access to the available security mode indicators is only used to indicate to the user that the system is operating in the secure mode while in the secure mode.

In other embodiments, other means than the GPIO latch may be provided to activate the secure mode indicator. For example, bits from the secure mode register 319 may be used. Similarly, a bit from secure devices 316a or 316b may be used. The main requirement is that the means are only accessible while in secure mode.

In another embodiment, the security mode indicator may respond directly to the security signal such that the security mode indicator may be active for the entire time the processor is in the security mode. However, in this embodiment, the user may find that the indicator is on more and tends to overlook it, so this is not a preferred embodiment.

Referring again to FIG. 2, secure device 316a may be an input device used to receive critical information from a user. Thus, this input device is enabled to receive critical information only when the system is operating in secure mode. 2 tends to indicate that the security device is on-chip. This is not necessary for all embodiments. It may also be an off-chip device such as a separate fingerprint recognition device. Access to this external device can be limited to only the secure mode. Typically, data exchanged with a secure external device need not be secret data unless it is encrypted. The external security device can be made visible to the user when the device is in operation. If the device cannot operate outside of secure mode, it makes it more difficult for hackers to trick users.

Referring back to FIG. 2, a tamper detection device 380 may be provided as an option. The output 380.1 of the tamper detection device 380 indicates that the access cover on the enclosure including the CPU 200 has been tampered with. And, the signal 380.1 is monitored by the SSM 300, so that if tampering is detected, it will not enter the secure mode. Similarly, if the security mode is during operation, the SSM 300 detects this via signal 380.1, and as discussed above, the security mode is excited to indicate a violation. The tamper detection device may be an external off-chip device. The output of the tamper detection device can be monitored by the SSM or logged in by a secure GPIO. The fact that access to the GPIO is restricted to the secure mode makes it impossible for the Hacker to solve it. In this way, the security software will know to enter the next secure mode.

Therefore, it is to be understood that the appended claims cover any such modifications of embodiments falling within the scope and spirit of the invention.

According to the present invention, a smart device executing security applications is provided with a security mode indicator in addition to a display and a keyboard. This indicator informs the user that the device is in secure mode. If the security mode indicator is not activated, the user must not enter any secret information (password) or sign anything on the screen. If you are prompted to enter his pin code while the indicator is inactive, the user may know that his device has been compromised and that the device cannot provide security operations.

Claims (10)

In operating a digital system, Providing an operation in a secure mode in which only trusted program code can be executed; And Providing a security mode indicator means observable by a user of the digital system And wherein the indicator means can only be activated by the trusted program code while in the secure mode of operation. The method of claim 1, Executing an application program; Entering the secure mode operation to execute a secure portion of the application program; Activating the secure mode indicator means in response to executing the secure portion of the application program; And Requesting a user to provide critical information to the secure portion of the application program while the indicator means is active Digital system operating method further comprising. The method of claim 2, De-activating the secure mode indicator means after receiving the critical information while the secure portion of the application program continues to run in a secure mode. The method according to claim 2 or 3, The step of activating the secure mode indicator means includes executing an instruction to write to a memory mapped latch, wherein the memory mapped latch can be written only when the instruction is executed during the secure mode operation. How to operate a digital system. The method of claim 1, wherein the step of providing an operation in a secure mode comprises: Jumping to an entry address at a special address in the instruction memory; Executing an active sequence of instructions starting at the entry address; And Entering the secure mode operation only if the active sequence of instructions is all executed in the order selected by the CPU Digital system operating method comprising a. The method according to any one of claims 1 to 5, Providing tamper detection means for detecting whether the digital system has been tampered with, The step of providing an operation in a secure mode is prohibited if the tamper detection means indicates that the digital system has been tampered with. In a digital system, A central processing unit (CPU) for executing instructions; A shared memory connected to the command bus of the CPU for holding non-secure instructions, wherein the shared memory is always accessible by the CPU; A secure memory connected to the command bus of the CPU for holding secure instructions, the secure memory being accessible only when a secure signal is asserted; A security circuit having an output for asserting the security signal when a security mode of operation is set; And A security mode indicator responsive to the security signal Wherein the security mode indicator is viewable by a user of the digital system and the security mode indicator can be placed in an active mode only by executing a command while the security signal is asserted. The method of claim 7, wherein The security mode indicator, A memory mapped latch connected to receive a data bit signal from the CPU in response to a write command, the operation of the memory mapped latch being controlled by a security signal such that the latch can only be written when the security signal is asserted The memory mapped latch has an output signal for indicating a state of the latch; And A security mode indicator device connected to said output signal of said memory mapped latch, said security mode indicator device responding to a state of said latch, said security mode indicator device being capable of indicating an on state and an off state; Digital system that is a device or an audio device capable of indicating an on state and an off state. The method according to claim 7 or 8, Further comprising tamper detection means capable of indicating whether the digital system has been tampered with, And said security circuit monitors said tamper detection means and prevents setting of a security mode of an operation in response to said tamper detection means. The method according to any one of claims 7 to 9, The digital system is a wireless device, An integrated keyboard connected to the CPU via a keyboard adapter; A display connected to the CPU via a display adapter; A radio frequency (RF) circuit connected to the CPU; And An antenna connected to the RF circuit More, The security mode indicator comprises a light emitting diode (LED) arranged in the visible vicinity of the display.