Patent Application
20070192830
The invention relates generally to digital security and, more particularly, to techniques for limiting access to secrets and/or security related functionality within a security module.
Security is quickly becoming a major concern in a wide range of different digital products. As the mobility of digital devices increases, and the channels of communication between such devices and the outside world become more plentiful and more sophisticated, there is growing need to provide adequate protection for important data and other “secrets” that may be stored within a digital device. With the increasing popularity of e-commerce, high bandwidth data services, and other digital transactions, it has also become more important to be able to accurately and reliably authenticate digital devices and associated users, even from remote locations. To combat the various security risks associated with digital devices, hardware-based security modules (e.g., trusted platform modules (TPMs), etc.) have been developed to, for example, aid in the protection of secrets on digital platforms, facilitate the authentication of platforms, prevent unauthorized access to platforms, prevent unauthorized access to outside networks and services, and/or perform other security related functions. It is believed that such security modules will play an increasingly important role as both the number and the capabilities of digital devices increase in the coming years. Therefore, there is a general need for methods and structures for improving the effectiveness of digital security modules.
In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.
The processor 12 can be any of a variety of different digital processing device types. For example, the processor 12 may be a general purpose microprocessor, a digital signal processor, a reduced instruction set computer (RISC), a complex instruction set computer (CISC), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller, a multi-core processor, and/or others. Multiple processors that share a common security module 16 may also be used. The processor 12 is not necessarily the main processor or central processing unit (CPU) of the digital device 10, but can also be a secondary or supplementary processor of the device. The processor 12 that is coupled to the security module 16 will typically be the processor (or processors) that will need to access the security functionality within the module 16 during device operation. In at least one embodiment, the processor 12 is a chipset of the digital device 10, although many other arrangements also exist.
The digital device 10 will typically include some communication functionality to enable the device to communicate with one or more remote entities. This communication functionality may support wireless and/or wired communication. In the embodiment of
As described previously, the security module 16 is operative for performing one or more security related functions for the digital device 10. The security module 16 may, for example, provide secure storage for one or more “secrets” that a user of the device 10 wants to hide from, for example, hackers and data thieves. As used herein, a “secret” may be any information that a user wishes to keep confidential. Secrets may include, for example, encryption keys, authentication information, endorsement certificates, passwords, bank account information, credit card information, personal information, and/or other information. The security module 16 may also provide encryption/decryption functions, authentication functions, and/or other security related functions that can be used by, for example, one or more programs being executed by the processor 12. The programs may be able to send commands to the security module 16 when they require security related functions to be performed.
The security module 16 may include digital processing functionality that is capable of performing the supported security functions. For example, in one embodiment, the security module 16 may include a secure microcontroller or other processor. The digital processing functionality may be used to provide various cryptography functions for the device 10. The cryptography functions will typically be performed within the module hardware and entities outside the security module 16 will not have access to the execution of these functions. The security module 16 may also include, for example, encryption/decryption hardware, such as an RSA engine, etc. to perform public key encryption. An RSA engine may be used during, for example, digital signing operations and/or key wrapping operations. In some embodiments, the security module 16 may also include a hash engine or similar hardware to compute hash values for input data. One type of security module that may be used in accordance with the invention is a trusted platform module (TPM) as described in Trusted Computing Platform Alliance (TCPA) Main Specification, Version 1.1b, published by the Trusted Computing Group, 2003. Other similar devices may alternatively be used.
In one aspect of the present invention, the security module 16 will not treat commands from all programs executing within the processor 12 the same. That is, the security module 16 will control access to its protected secrets and/or security functionality based on a “security level” associated with code issuing a command to the module. Programs to be executed within the processor 12 may each have a security level associated with it that is related to the level of trust that the program is deemed to possess. Thus, programs that are very trustworthy may have a high security level while programs that are less trustworthy (e.g., programs that are easily hacked, etc.) may have a lower security level. Any number of different security levels (i.e., two or more) may be used to describe the programs resident on a particular platform.
When a program issues a command to the security module 16, the module will determine the security level of the issuing program and limit the access of the program based thereon. For example, in one embodiment, the security module 16 may limit the secrets that are available for use by a particular program based on the security level of the program. In another embodiment, the security module 16 may limit the security related processing functions that are available to a program based on the security level of the program. In yet another embodiment, the security module 16 may limit both the secrets and the security related processing functions that are available to a program based on security level. For example, the security module 16 may only allow programs having a highest security level to use certain types of encryption. Similarly, the security module 16 may only allow programs having a highest security level to have access to certain encryption keys (or other secrets) stored within the module.
In at least one embodiment, a security level condition may be established for each different security function that may be provided by the security module 16. For example, a particular type of encryption may require that a program issuing a command for that encryption have a security level at or above a specified level. Another possible condition may be that only programs having one or more specified security levels may use that type of encryption. Security level conditions may also be specified for different secrets stored within the module 16 (e.g., for different secrets stored within the module, etc.).
The security levels that are used to categorize the programs on a digital platform may be established in a number of different ways. For example, in one approach, a user associated with a platform may specify the number of security levels to be used for the platform and which level to assign to each program. Programs that are not assigned a security level may be given a default level by the device (e.g., the lowest security level). In another possible approach, levels that are already assigned by a processor manufacturer or other entity may be used as the security levels regulating access to the security module 16. For example, ARM® is a manufacturer of digital products that has developed a security technology known as Trustzone® technology. While using the Trustzone® technology, some of the programs on a platform may be operated in a “secure” mode while other programs may be operated in a “non-secure” mode. In at least one embodiment of the invention, this designation of secure mode and non-secure mode may be used by a security module as an indicator of the security level of executing programs.
In an ARM Trustzone enabled platform, bits are usually included on the ARM bus that indicate whether a command currently on the bus was issued by a secure mode or non-secure mode program. In at least one embodiment, the security module 16 may simply latch these bits to determine the security level of the issuing code. Other systems may identify programs as executing in either “supervisor mode” or “user mode.” These may also be used as security levels in a similar manner. In another possible approach, in a system where a module reads instructions off of a list residing in memory, certain bits in the commands, as well as restrictions on the order and memory of commands in the list, may be used to identify security levels associated with the issuing programs.
Other techniques for determining security levels associated with programs may alternatively be used. For example, in systems based on Intel Architecture processors, the ring level of the executing code may be used. As another example, the processor may indicate a security level based on which instructions are being executed, thus allowing security functions built-in to the processor exclusive access to some secrets or algorithms in the security module.
If the program that issued the command does not satisfy the security level condition associated with the requested function (block 26-N), an error signal may be delivered to a user of the corresponding platform (block 28) and the method 20 may then terminate (block 30). If the program does satisfy the security level condition associated with the requested function (block 26-Y), the security level of the program may then be compared to a security level condition associated with the secret identified within the command, if any (block 32). As with the security level condition associated with the requested function, if the program does not satisfy the security level condition associated with the secret (block 34-N), an error signal may be delivered to the user of the platform (block 28) and the method 20 may terminate (block 30). Otherwise, the requested function will be performed (block 36).
In the method 20 illustrated in
The techniques and structures of the present invention may be implemented in any of a variety of different forms. For example, features of the invention may be embodied within laptop, palmtop, desktop, and tablet computers; personal digital assistants (PDAs); cellular telephones and other handheld wireless communicators; pagers; satellite communicators; network interface cards (NICs) and other network interface structures; base stations; wireless access points; integrated circuits; security modules; trusted platform modules; as instructions and/or data structures stored on machine readable media; and/or in other formats. Examples of different types of machine readable media that may be used include floppy diskettes, hard disks, optical disks, compact disc read only memories (CD-ROMs), digital video disks (DVDs), Blu-ray disks, magneto-optical disks, read only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, flash memory, and/or other types of media suitable for storing electronic instructions or data.
In the foregoing detailed description, various features of the invention are grouped together in one or more individual embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects may lie in less than all features of each disclosed embodiment.
Although the present invention has been described in conjunction with certain embodiments, it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the invention as those skilled in the art readily understand. Such modifications and variations are considered to be within the purview and scope of the invention and the appended claims.
