WO2006137947A1 - Programmable processor supporting secure mode - Google Patents

Programmable processor supporting secure mode Download PDF

Info

Publication number
WO2006137947A1
WO2006137947A1 PCT/US2005/042864 US2005042864W WO2006137947A1 WO 2006137947 A1 WO2006137947 A1 WO 2006137947A1 US 2005042864 W US2005042864 W US 2005042864W WO 2006137947 A1 WO2006137947 A1 WO 2006137947A1
Authority
WO
WIPO (PCT)
Prior art keywords
interrupt
processing system
secure mode
read
key
Prior art date
Application number
PCT/US2005/042864
Other languages
French (fr)
Inventor
Joshua Kablotsky
Original Assignee
Analog Devices, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Analog Devices, Inc. filed Critical Analog Devices, Inc.
Priority to EP05858338A priority Critical patent/EP1836637A1/en
Publication of WO2006137947A1 publication Critical patent/WO2006137947A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode

Definitions

  • the present invention generally relates to processing systems, and relates in particular to computer processing systems that support a secure mode of operation for executing a secure code and/or for processing secure data.
  • Certain processing systems provide a safe mode or a secure mode of operation in which a processor may be operated such that it may manipulate sensitive files and/or run secure algorithms that are highly sensitive.
  • the access to such a secure mode is sometimes difficult to safeguard. If a threat is able to obtain secure mode access, then substantial damage may result in certain applications.
  • Software safeguards that protect access to a secure mode may be avoided if certain software data is obtained by a hacker.
  • Hardware safeguards that protect access to a secure mode may involve the use of a secure boot sequence that employs a secure kernel that is separate from the primary operating system. Such a system, however, adds significant cost to the processor.
  • Security in processing is essential not only to avoid malignant code such as viruses from damaging the operation of the processor, but also to provide confidentiality of data within the processor and confidentiality in encrypting data that is to be transmitted to other processors.
  • the invention provides a processing system supporting a secure mode of operation and comprising a read-only hardware key that is only accessible in secure mode.
  • the invention provides a method of operating a processing unit in a secure mode. The method includes the steps of comparing an application signature in an application to be authenticated with a hardware key in the processing system, enabling an interrupt diversion routine to prevent interrupts from being received by the processor, disabling an emulation unit of the processor, and enabling a secure function to be executed.
  • Figure 1 shows a diagrammatic illustrative view of a plurality of processing systems in accordance with an embodiment of the invention
  • FIG. 2 shows a diagrammatic flowchart of the operational steps performed by a system in accordance with an embodiment of the invention
  • FIG. 3 shows a diagrammatic flowchart of the operational steps involved in the operation of a pre-interrupt handler in accordance with an embodiment of the invention.
  • Figure 4 shows a diagrammatic flowchart of the operational steps performed by a system in accordance with another embodiment of the invention.
  • a processor 10 may include a central processing unit 12 that includes interrupt ports 14, a read only memory (ROM) 16, a random access memory (RAM) 18, and input/output ports 20 and 22 for communicating with input and/or output devices 26 and 28.
  • the ROM 16 includes a hardware embedded key 26 that is provided by the manufacturer of the processing unit 10. This key is a private key that is embedded in the hardware of the device and is not available to be read except in secure mode.
  • the private key may be, for example, about 256 bytes or 1024 bits long.
  • various input/output devices 26 and 28 may communicate with the processor via the ports 20, 22. If any applications 30, 32 that are coupled to the devices 26 and 28 request operations in secure mode, then the system authenticates the requesting code by using public key authorization.
  • the public key may, for example, be about 512 bytes or 2048 bits long.
  • the key or keys on the device for this purpose are public. Code that has been authenticated has access to the key that may be used to decrypt subsequent code and data.
  • the device key may depend on the protocol in use.
  • the key may be either embedded in the ROM or may be otherwise fixed in the hardware during manufacturing, or may involve the use of fuses or links to set the key.
  • all interrupts are vectored to a pre-interrupt handler to appropriately clear the state of the machine.
  • an alternate interrupt vector table may be used as discussed below.
  • the move to secure mode is possible under software control, but only after the requesting software has been authenticated. Authentication is achieved by passing a pointer and a byte count to the authentication-request subroutine placed in the RUM device.
  • the Jcey may be embedded in the ROM 16 or may be provided in a set of fuse- type links within the processor.
  • the authentication request subroutine begins with a request for secure mode (step 40) and uses a public key signature algorithm (step 42) to verify the source and integrity of the code requesting secure mode (step 44).
  • the signature is generated using a private key, and it is validated using the public key. Once validated, secure mode is enabled and the hidden key becomes visible.
  • An authentication request may be made either by a direct function call to a known and fixed address, or by a system call that loads registers with parameters that are passed, which causes a software exception to occur.
  • the authentication request may, for example, vector to an authentication code in registers or a data structure in fixed hardware memory, or may call a coded location. If the signature does not match, the routine ends (step 46).
  • the authenticated function would then install a pre- interrupt handler (step 48), and then disable emulation capability (step 50).
  • the authenticated function would put the hardware into secure mode (step 52) and then make an indirect call to the requested, authenticated function (step 54). Once in secure mode, this key becomes visible.
  • This key could then be used by the authenticated function to decrypt and call subsequent code, to decrypt other data, or as a seed for generating private keys.
  • the algorithm used may, for example, take advantage of the secret nature of this hardware key to use public/private key encryption for the code.
  • the authenticated function Prior to leaving secure mode, the authenticated function should clear the machine of any sensitive state and code before ending. In particular, the function should turn off the secure function (step 56), re-enable emulation (step 58), and un-install the pre-interrupt handler (step 60) prior to ending (step 62).
  • the authenticated function may wish to use a subset of the hardware key to create a device key or ID that is useful in establishing secure communications with other devices. Alternatively, the device key used for communication may be stored in an encrypted fashion in the software.
  • an interrupt routine may be handled (step 70) by first storing information regarding where the secure mode was called from (step 72). The routine then erases all sensitive or secure external and internal programming code and data (step 74). The routine then disables secure mode (step 76), and vectors to the requested interrupt (step 78). The routine then restores any arguments to secure mode and vectors to that location (step 80) before ending (step 82). In other embodiments, the system may not return to exactly the same place from where the requested code was called. For example, if the interrupt service routine is aware of what the secure code is doing, and is able to determine that some useful work was done, it may then continue the secure work approximately where it left off before the interrupt was received.
  • an authentication request subroutine begins with a request for secure mode (step 90) and uses a public key signature algorithm (step 92) to verify the source and integrity of the code requesting secure mode (step 94).
  • the authentication request may, for example, vector to an authentication code in registers or a data structure in fixed hardware memory, or may call a coded location. If the signature does not match, the routine ends (step 96). If the signature matches, the authenticated function would then switch to an alternate interrupt table (step 98), and then disable emulation capability (step 100). The authenticated function would put the hardware into secure mode (step 102) and then make an indirect call to the requested, authenticated function (step 104).
  • this key becomes visible. This key could then also be used by the authenticated function to decrypt and call subsequent code to decrypt other data, or as a seed for generating private keys. Again, the algorithm used may take advantage of the secret nature of this hardware key to use public/private key encryption for the code.
  • the authenticated function Prior to leaving secure mode, the authenticated function should clear the machine of any sensitive state and code before ending. In particular, the function should turn off the secure function (step 106), re-enable emulation (step 108), and return to using the primary interrupt table (step 110) prior to ending (step 112).
  • the authenticated function may wish to use a subset of the hardware key to create a device key or ID that is useful in establishing secure communications with other devices. Alternatively, the device key used for communication may be stored in an encrypted fashion in the software.
  • the alternate interrupt vector table may include a list of addresses to interrupt service routines in accordance with an embodiment, or may include several bytes that may contain either an interrupt service routine itself (for example if the routine is short), or may include a jump instruction to a relative or absolute address. Any of the bits of an address (e.g., 14 bits) as well as any of the bytes that include a jump instruction may also include instructions for the routine that was called by the interrupt.
  • a signature may be generated with a private key that can be verified with a public key.
  • the signature itself is not verified, but rather it is the combination of the message and the signature that is verified.
  • the signature is similar to a one-way hash of the content of the message, in that the message cannot be generated from the hash, and only the hashing function can produce the signature.
  • There is a comparable function that together can hash the message with its signature so if the public key is present, then the signature may be verified. If the public key pair of that private key is present, then that signature may be verified as being is correct for that message. The system verifies that that private key was used to sign that message.
  • the system therefore, performs two basic functions; one is authentication, and the other is providing access to the private hardware key.
  • the authentication code includes a public key.
  • the public code uses that public key to verify the authenticity of code requesting secure mode. Once authenticated, access to secure mode is provided which gives the device access to additional hardware features, including the hardware key itself.
  • the system may then permit the requesting device to perform a wide variety of functions. For example, if the requesting device included additional code that was encrypted, the system could not decrypt the code without knowing the private hardware key.
  • the encryption may for example, employ a public key encryption technology such as sold by PGP Corporation of Palo Alto, California, or symmetric key, cryptography, where the exact same key was used in encryption, and unless the receiver has the exact same key the receiver cannot decrypt the code.
  • access to the secure mode may be used to generate a unique device identifier, for example, wherein the hardware key itself could be the unique device identifier. Access to secure mode also permits one to create subsequent keys. Further, to the extent that the resource of secure mode is unique for each chip, further uses are provided that are unique to each user of each such system.

Abstract

A processing system supporting a secure mode of operation is disclosed. The processing system includes a read-only hardware key that is only accessible in secure mode.

Description

PROGRAMMABLE PROCESSOR SUPPORTING SECURE MODE
PRIORITY INFORMATION This application claims priority from U.S. utility application Serial No. 10/999,656 filed
November 30, 2004, incorporated herein by reference in its entirety.
BACKGROUND OF THE INVENTION
The present invention generally relates to processing systems, and relates in particular to computer processing systems that support a secure mode of operation for executing a secure code and/or for processing secure data.
Certain processing systems provide a safe mode or a secure mode of operation in which a processor may be operated such that it may manipulate sensitive files and/or run secure algorithms that are highly sensitive. The access to such a secure mode, however, is sometimes difficult to safeguard. If a threat is able to obtain secure mode access, then substantial damage may result in certain applications. Software safeguards that protect access to a secure mode may be avoided if certain software data is obtained by a hacker. Hardware safeguards that protect access to a secure mode may involve the use of a secure boot sequence that employs a secure kernel that is separate from the primary operating system. Such a system, however, adds significant cost to the processor.
Security in processing is essential not only to avoid malignant code such as viruses from damaging the operation of the processor, but also to provide confidentiality of data within the processor and confidentiality in encrypting data that is to be transmitted to other processors.
There is a need, therefore, for a processor that provides a secure mode of operation in a reliable and economical processing system.
SUMMARY OF THE INVENTION
In accordance with an embodiment, the invention provides a processing system supporting a secure mode of operation and comprising a read-only hardware key that is only accessible in secure mode. In accordance with another embodiment, the invention provides a method of operating a processing unit in a secure mode. The method includes the steps of comparing an application signature in an application to be authenticated with a hardware key in the processing system, enabling an interrupt diversion routine to prevent interrupts from being received by the processor, disabling an emulation unit of the processor, and enabling a secure function to be executed. BRIEF DESCRIPTION OF THE DRAWINGS
The following description may be further understood with reference to the accompanying drawing in which: Figure 1 shows a diagrammatic illustrative view of a plurality of processing systems in accordance with an embodiment of the invention;
Figure 2 shows a diagrammatic flowchart of the operational steps performed by a system in accordance with an embodiment of the invention;
Figure 3 shows a diagrammatic flowchart of the operational steps involved in the operation of a pre-interrupt handler in accordance with an embodiment of the invention; and
Figure 4 shows a diagrammatic flowchart of the operational steps performed by a system in accordance with another embodiment of the invention.
The drawings are shown for illustrative purposes.
DETAILED DESCRIPTION OF THE INVENTION
As shown in Figure 1, a processor 10 may include a central processing unit 12 that includes interrupt ports 14, a read only memory (ROM) 16, a random access memory (RAM) 18, and input/output ports 20 and 22 for communicating with input and/or output devices 26 and 28. The ROM 16 includes a hardware embedded key 26 that is provided by the manufacturer of the processing unit 10. This key is a private key that is embedded in the hardware of the device and is not available to be read except in secure mode. The private key may be, for example, about 256 bytes or 1024 bits long.
During use, various input/output devices 26 and 28 may communicate with the processor via the ports 20, 22. If any applications 30, 32 that are coupled to the devices 26 and 28 request operations in secure mode, then the system authenticates the requesting code by using public key authorization. The public key may, for example, be about 512 bytes or 2048 bits long. The key or keys on the device for this purpose are public. Code that has been authenticated has access to the key that may be used to decrypt subsequent code and data. The device key may depend on the protocol in use. The key may be either embedded in the ROM or may be otherwise fixed in the hardware during manufacturing, or may involve the use of fuses or links to set the key. When operating in secure, mode, all interrupts are vectored to a pre-interrupt handler to appropriately clear the state of the machine. In other embodiments, an alternate interrupt vector table may be used as discussed below. The move to secure mode is possible under software control, but only after the requesting software has been authenticated. Authentication is achieved by passing a pointer and a byte count to the authentication-request subroutine placed in the RUM device. The Jcey may be embedded in the ROM 16 or may be provided in a set of fuse- type links within the processor.
With reference to Figure 2, the authentication request subroutine begins with a request for secure mode (step 40) and uses a public key signature algorithm (step 42) to verify the source and integrity of the code requesting secure mode (step 44). The signature is generated using a private key, and it is validated using the public key. Once validated, secure mode is enabled and the hidden key becomes visible. An authentication request may be made either by a direct function call to a known and fixed address, or by a system call that loads registers with parameters that are passed, which causes a software exception to occur. The authentication request may, for example, vector to an authentication code in registers or a data structure in fixed hardware memory, or may call a coded location. If the signature does not match, the routine ends (step 46). If the signature matches, the authenticated function would then install a pre- interrupt handler (step 48), and then disable emulation capability (step 50). The authenticated function would put the hardware into secure mode (step 52) and then make an indirect call to the requested, authenticated function (step 54). Once in secure mode, this key becomes visible.
This key could then be used by the authenticated function to decrypt and call subsequent code, to decrypt other data, or as a seed for generating private keys. The algorithm used may, for example, take advantage of the secret nature of this hardware key to use public/private key encryption for the code. Prior to leaving secure mode, the authenticated function should clear the machine of any sensitive state and code before ending. In particular, the function should turn off the secure function (step 56), re-enable emulation (step 58), and un-install the pre-interrupt handler (step 60) prior to ending (step 62). The authenticated function may wish to use a subset of the hardware key to create a device key or ID that is useful in establishing secure communications with other devices. Alternatively, the device key used for communication may be stored in an encrypted fashion in the software.
As shown in Figure 3, an interrupt routine may be handled (step 70) by first storing information regarding where the secure mode was called from (step 72). The routine then erases all sensitive or secure external and internal programming code and data (step 74). The routine then disables secure mode (step 76), and vectors to the requested interrupt (step 78). The routine then restores any arguments to secure mode and vectors to that location (step 80) before ending (step 82). In other embodiments, the system may not return to exactly the same place from where the requested code was called. For example, if the interrupt service routine is aware of what the secure code is doing, and is able to determine that some useful work was done, it may then continue the secure work approximately where it left off before the interrupt was received. in accordance witn yet anotner embodiment, and with reference to Figure 4, an authentication request subroutine begins with a request for secure mode (step 90) and uses a public key signature algorithm (step 92) to verify the source and integrity of the code requesting secure mode (step 94). The authentication request may, for example, vector to an authentication code in registers or a data structure in fixed hardware memory, or may call a coded location. If the signature does not match, the routine ends (step 96). If the signature matches, the authenticated function would then switch to an alternate interrupt table (step 98), and then disable emulation capability (step 100). The authenticated function would put the hardware into secure mode (step 102) and then make an indirect call to the requested, authenticated function (step 104). Once in secure mode, this key becomes visible. This key could then also be used by the authenticated function to decrypt and call subsequent code to decrypt other data, or as a seed for generating private keys. Again, the algorithm used may take advantage of the secret nature of this hardware key to use public/private key encryption for the code.
Prior to leaving secure mode, the authenticated function should clear the machine of any sensitive state and code before ending. In particular, the function should turn off the secure function (step 106), re-enable emulation (step 108), and return to using the primary interrupt table (step 110) prior to ending (step 112). Again, the authenticated function may wish to use a subset of the hardware key to create a device key or ID that is useful in establishing secure communications with other devices. Alternatively, the device key used for communication may be stored in an encrypted fashion in the software.
The alternate interrupt vector table may include a list of addresses to interrupt service routines in accordance with an embodiment, or may include several bytes that may contain either an interrupt service routine itself (for example if the routine is short), or may include a jump instruction to a relative or absolute address. Any of the bits of an address (e.g., 14 bits) as well as any of the bytes that include a jump instruction may also include instructions for the routine that was called by the interrupt.
Systems of the invention provide, therefore, that a signature may be generated with a private key that can be verified with a public key. The signature itself is not verified, but rather it is the combination of the message and the signature that is verified. The signature is similar to a one-way hash of the content of the message, in that the message cannot be generated from the hash, and only the hashing function can produce the signature. There is a comparable function that together can hash the message with its signature so if the public key is present, then the signature may be verified. If the public key pair of that private key is present, then that signature may be verified as being is correct for that message. The system verifies that that private key was used to sign that message. The system, therefore, performs two basic functions; one is authentication, and the other is providing access to the private hardware key. The authentication code includes a public key. The public code uses that public key to verify the authenticity of code requesting secure mode. Once authenticated, access to secure mode is provided which gives the device access to additional hardware features, including the hardware key itself. The system may then permit the requesting device to perform a wide variety of functions. For example, if the requesting device included additional code that was encrypted, the system could not decrypt the code without knowing the private hardware key. The encryption, may for example, employ a public key encryption technology such as sold by PGP Corporation of Palo Alto, California, or symmetric key, cryptography, where the exact same key was used in encryption, and unless the receiver has the exact same key the receiver cannot decrypt the code. In further embodiments, access to the secure mode may be used to generate a unique device identifier, for example, wherein the hardware key itself could be the unique device identifier. Access to secure mode also permits one to create subsequent keys. Further, to the extent that the resource of secure mode is unique for each chip, further uses are provided that are unique to each user of each such system.
Those skilled in the art will appreciate that numerous modifications and variations may be made to the above disclosed embodiments without departing from the spirit and scope of the invention.
What is claimed is:

Claims

1. A processing system supporting a secure mode of operation and comprising a read- only hardware key that is only accessible in secure mode.
2. The processing system as claimed in claim 1, wherein said read-only hardware key is provided in a read-only-memory.
3. The processing system as claimed in claim 1, wherein said read-only hardware key is provided using fuse- type links.
4. The processing system as claimed in claim 1, wherein a software key authenticates a signature against a read only public hardware key.
5. A processing system supporting a secure mode of operation, said processing system comprising: a read only memory that includes a read only hardware key; authentication means for comparing a public key with a signature of a requesting device; and secure access means for permitting the read only hardware key to be accessible by the requesting device responsive to an output of said authentication means.
6. The processing system as claimed in claim 5, wherein said processing system further includes interrupt diversion enabling means for enabling an interrupt diversion routine to prevent interrupts from being received by the processor.
7. The processing system as claimed in claim 6, wherein said interrupt diversion enabling means includes pre-interrupt handler means for installing a pre-interrupt handler.
8. The processing system as claimed in claim 6, wherein said processing system includes a primary interrupt vector table for use during operation of the processing system outside of secure mode, and said interrupt diversion handling means includes alternate interrupt vector table means for installing an alternate interrupt vector table for use during the secure mode of operation.
9. The processing system as claimed in claim 8, wherein said alternate interrupt vector table includes a list of addresses of interrupt service routines.
10. The processing system as claimed in claim 8, wherein said alternate interrupt vector table includes interrupt service routines.
11. The processing system as claimed in claim 8, wherein said alternate interrupt vector table includes jump instructions to interrupt service routines.
12. A method of operating a processing unit in a secure mode, said method comprising the steps of: comparing an application signature in an application to be authenticated with a hardware key in the processing system; enabling an interrupt diversion routine to prevent interrupts from being received by the processor; . disabling an emulation unit of the processor; and enabling a secure function to be executed.
13. The method as claimed in claim 12, wherein said step of enabling an interrupt diversion routine to prevent interrupts from being received by the processor involves installing a pre-interrupt handler.
14. The method as claimed in claim 12, wherein said step of enabling an interrupt diversion routine to prevent interrupts from being received by the processor involves installing an alternate interrupt vector table.
15. The method as claimed in claim 12, wherein said method further involves the step of clearing any sensitive code prior to exiting the secure mode.
PCT/US2005/042864 2004-11-30 2005-11-29 Programmable processor supporting secure mode WO2006137947A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05858338A EP1836637A1 (en) 2004-11-30 2005-11-29 Programmable processor supporting secure mode

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/999,656 US7457960B2 (en) 2004-11-30 2004-11-30 Programmable processor supporting secure mode
US10/999,656 2004-11-30

Publications (1)

Publication Number Publication Date
WO2006137947A1 true WO2006137947A1 (en) 2006-12-28

Family

ID=36585639

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/042864 WO2006137947A1 (en) 2004-11-30 2005-11-29 Programmable processor supporting secure mode

Country Status (4)

Country Link
US (1) US7457960B2 (en)
EP (1) EP1836637A1 (en)
CN (1) CN100527145C (en)
WO (1) WO2006137947A1 (en)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7225333B2 (en) * 1999-03-27 2007-05-29 Microsoft Corporation Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
US20060242406A1 (en) 2005-04-22 2006-10-26 Microsoft Corporation Protected computing environment
US8347078B2 (en) 2004-10-18 2013-01-01 Microsoft Corporation Device certificate individualization
US7694153B2 (en) * 2004-11-15 2010-04-06 Microsoft Corporation Changing product behavior in accordance with license
US8176564B2 (en) 2004-11-15 2012-05-08 Microsoft Corporation Special PC mode entered upon detection of undesired state
US8336085B2 (en) 2004-11-15 2012-12-18 Microsoft Corporation Tuning product policy using observed evidence of customer behavior
US7480755B2 (en) * 2004-12-08 2009-01-20 Hewlett-Packard Development Company, L.P. Trap mode register
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US8353046B2 (en) 2005-06-08 2013-01-08 Microsoft Corporation System and method for delivery of a modular operating system
US20090204823A1 (en) * 2008-02-07 2009-08-13 Analog Devices, Inc. Method and apparatus for controlling system access during protected modes of operation
US8607034B2 (en) 2008-05-24 2013-12-10 Via Technologies, Inc. Apparatus and method for disabling a microprocessor that provides for a secure execution mode
US8819839B2 (en) 2008-05-24 2014-08-26 Via Technologies, Inc. Microprocessor having a secure execution mode with provisions for monitoring, indicating, and managing security levels
EP2146213B1 (en) * 2008-07-14 2011-08-17 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Integrated circuit, method and electronic apparatus
US7761714B2 (en) * 2008-10-02 2010-07-20 Infineon Technologies Ag Integrated circuit and method for preventing an unauthorized access to a digital value
US8516260B2 (en) * 2008-10-27 2013-08-20 Advanced Micro Devices, Inc. Method, apparatus, and device for providing security among a calling function and a target function
US8681976B2 (en) * 2011-05-12 2014-03-25 Apple Inc. System and method for device dependent and rate limited key generation
WO2013012436A1 (en) 2011-07-18 2013-01-24 Hewlett-Packard Development Company, L.P. Reset vectors for boot instructions
KR20130031435A (en) * 2011-09-21 2013-03-29 주식회사 팬택 Method and apparatus for generating and managing of encryption key portable terminal
EP2817755B1 (en) * 2012-02-20 2021-03-24 Intel Corporation Directed wakeup into a secured system environment
CN103313240B (en) * 2012-03-15 2016-12-14 中国移动通信集团公司 A kind of safety access method, Apparatus and system
JP6117068B2 (en) * 2013-09-20 2017-04-19 株式会社東芝 Information processing apparatus and program
GB2581161A (en) 2019-02-05 2020-08-12 Trustonic Ltd Software encryption

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5563950A (en) * 1995-03-31 1996-10-08 International Business Machines Corporation System and methods for data encryption using public key cryptography
US20020007456A1 (en) 1999-03-27 2002-01-17 Marcus Peinado Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US20030140245A1 (en) * 2002-01-16 2003-07-24 Franck Dahan Secure mode for processors supporting MMU and interrupts
US20030191719A1 (en) * 1995-02-13 2003-10-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4411017A (en) * 1980-03-14 1983-10-18 Harris Corporation Secure mobile telephone system
US4555805A (en) * 1980-03-14 1985-11-26 Harris Corporation Secure mobile telephone system
US5081675A (en) * 1989-11-13 1992-01-14 Kitti Kittirutsunetorn System for protection of software in memory against unauthorized use
UA41387C2 (en) * 1994-01-13 2001-09-17 Сертко, Інк Method for setting of true communication being checked, method for protected communication, method for renewal of micro-software, method for execution of enciphered communication and method for giving to device checked on identity of right on electron transaction
JPH08249280A (en) * 1994-10-28 1996-09-27 Internatl Business Mach Corp <Ibm> Electronic key of data processor
FR2729700B1 (en) * 1995-01-25 1997-07-04 Nofal Dawalibi PROGRAMMABLE ELECTRONIC CLOSING DEVICE
DE69527773T2 (en) * 1995-05-18 2002-11-28 Hewlett Packard Co Circuit arrangement for monitoring the use of functions in an integrated circuit
US5970143A (en) * 1995-11-22 1999-10-19 Walker Asset Management Lp Remote-auditing of computer generated outcomes, authenticated billing and access control, and software metering system using cryptographic and other protocols
EP0763791A1 (en) * 1995-09-14 1997-03-19 Hewlett-Packard Company Computer keyboard unit with smartcard interface
US6523119B2 (en) * 1996-12-04 2003-02-18 Rainbow Technologies, Inc. Software protection device and method
US20010050990A1 (en) * 1997-02-19 2001-12-13 Frank Wells Sudia Method for initiating a stream-oriented encrypted communication
US6775778B1 (en) * 1998-05-29 2004-08-10 Texas Instruments Incorporated Secure computing device having boot read only memory verification of program code
FR2780177B1 (en) * 1998-06-17 2001-10-05 Schlumberger Ind Sa SOFTWARE PROTECTION SYSTEM
US6385727B1 (en) * 1998-09-25 2002-05-07 Hughes Electronics Corporation Apparatus for providing a secure processing environment
US6279114B1 (en) * 1998-11-04 2001-08-21 Sandisk Corporation Voltage negotiation in a single host multiple cards system
WO2000049511A1 (en) * 1999-02-17 2000-08-24 Sony Corporation Semiconductor ic, information processing method, information processing device, and program storage medium
EP1056014A1 (en) * 1999-05-28 2000-11-29 Hewlett-Packard Company System for providing a trustworthy user interface
US7124170B1 (en) * 1999-08-20 2006-10-17 Intertrust Technologies Corp. Secure processing unit systems and methods
AU2001243365A1 (en) * 2000-03-02 2001-09-12 Alarity Corporation System and method for process protection
US20030037237A1 (en) * 2001-04-09 2003-02-20 Jean-Paul Abgrall Systems and methods for computer device authentication
US6445606B1 (en) * 2001-05-10 2002-09-03 Koninklijke Philips Electronics N.V. Secure poly fuse ROM with a power-on or on-reset hardware security features and method therefor
FI115356B (en) * 2001-06-29 2005-04-15 Nokia Corp A method for processing audio-visual information in an electronic device, a system and an electronic device
FI115257B (en) * 2001-08-07 2005-03-31 Nokia Corp Method for Processing Information in an Electronic Device, System, Electronic Device, and Processor Block
US7313828B2 (en) * 2001-09-04 2007-12-25 Nokia Corporation Method and apparatus for protecting software against unauthorized use
US7194633B2 (en) * 2001-11-14 2007-03-20 International Business Machines Corporation Device and method with reduced information leakage
IL161652A0 (en) * 2001-11-14 2004-09-27 Ibm Device and method with reduced information leakage
CN100339780C (en) * 2002-04-18 2007-09-26 先进微装置公司 A computer system including a secure execution mode - capable cpu and a security services processor connected via a secure communication path
US20030228911A1 (en) * 2002-06-05 2003-12-11 Dernis Mitchell S. DVD-enabling code server and loader for a console-based gaming system
US7203844B1 (en) * 2002-06-20 2007-04-10 Oxford William V Method and system for a recursive security protocol for digital copyright control
US20040025033A1 (en) * 2002-08-02 2004-02-05 Todd Luke B. System and method for preventing unauthorized installation, use and reproduction of software
US20040092310A1 (en) * 2002-11-07 2004-05-13 Igt Identifying message senders
EP1563388A2 (en) * 2002-11-18 2005-08-17 ARM Limited Secure memory for protecting against malicious programs
JP4347582B2 (en) * 2003-02-04 2009-10-21 パナソニック株式会社 Information processing device
US7373657B2 (en) * 2003-03-10 2008-05-13 Avaya Technology Corp. Method and apparatus for controlling data and software access
US20040243783A1 (en) * 2003-05-30 2004-12-02 Zhimin Ding Method and apparatus for multi-mode operation in a semiconductor circuit
US20050021968A1 (en) * 2003-06-25 2005-01-27 Zimmer Vincent J. Method for performing a trusted firmware/bios update
JP4253543B2 (en) * 2003-07-29 2009-04-15 矢崎総業株式会社 Hardware protection key and reissuing method
JP2005227995A (en) * 2004-02-12 2005-08-25 Sony Corp Information processor, information processing method and computer program
US7940932B2 (en) * 2004-04-08 2011-05-10 Texas Instruments Incorporated Methods, apparatus, and systems for securing SIM (subscriber identity module) personalization and other data on a first processor and secure communication of the SIM data to a second processor
US7542567B2 (en) * 2004-06-10 2009-06-02 Freescale Semiconductor, Inc. Method and apparatus for providing security in a data processing system
US20060059369A1 (en) * 2004-09-10 2006-03-16 International Business Machines Corporation Circuit chip for cryptographic processing having a secure interface to an external memory
US8332653B2 (en) * 2004-10-22 2012-12-11 Broadcom Corporation Secure processing environment
US7496347B2 (en) * 2004-11-12 2009-02-24 Velocita Wireless Llc Method and apparatus for providing secure wireless communication
US8037310B2 (en) * 2004-11-30 2011-10-11 Ricoh Co., Ltd. Document authentication combining digital signature verification and visual comparison
WO2006082988A2 (en) * 2005-02-07 2006-08-10 Sony Computer Entertainment Inc. Methods and apparatus for facilitating a secure processor functional transition
US7739517B2 (en) * 2005-03-31 2010-06-15 Intel Corporation Hardware-based authentication of a software program

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030191719A1 (en) * 1995-02-13 2003-10-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5563950A (en) * 1995-03-31 1996-10-08 International Business Machines Corporation System and methods for data encryption using public key cryptography
US20020007456A1 (en) 1999-03-27 2002-01-17 Marcus Peinado Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US20030140245A1 (en) * 2002-01-16 2003-07-24 Franck Dahan Secure mode for processors supporting MMU and interrupts

Also Published As

Publication number Publication date
CN101065758A (en) 2007-10-31
US20060130130A1 (en) 2006-06-15
CN100527145C (en) 2009-08-12
US7457960B2 (en) 2008-11-25
EP1836637A1 (en) 2007-09-26

Similar Documents

Publication Publication Date Title
US7457960B2 (en) Programmable processor supporting secure mode
EP3387813B1 (en) Mobile device having trusted execution environment
US9043615B2 (en) Method and apparatus for a trust processor
US7734932B2 (en) System and method for securing executable code
US7986786B2 (en) Methods and systems for utilizing cryptographic functions of a cryptographic co-processor
EP1725924B1 (en) Device with a cryptographic coprocessor
US9054865B2 (en) Cryptographic system and methodology for securing software cryptography
US20090282254A1 (en) Trusted mobile platform architecture
US7930537B2 (en) Architecture for encrypted application installation
EP1725923A1 (en) Secure mode controlled memory
JP4226556B2 (en) Program execution control device, OS, client terminal, server, program execution control system, program execution control method, program execution control program
EP1593015B1 (en) Architecture for encrypted application installation
CN110750791A (en) Method and system for guaranteeing physical attack resistance of trusted execution environment based on memory encryption
CN112182669A (en) System and method for storing data records to be protected
US7464406B2 (en) System and method for user determination of secure software
KR100730708B1 (en) Architecture for encrypted applicationn installation
CN117707586A (en) BIOS firmware updating method, device, computer equipment and medium
Murase et al. Dependable TCB Based on the Cell Broadband Engine Isolation Facility

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200580040818.5

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2005858338

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005858338

Country of ref document: EP