GB2445231A - Authenticating suspect code at a Trusted Platform Module - Google Patents
Authenticating suspect code at a Trusted Platform Module Download PDFInfo
- Publication number
- GB2445231A GB2445231A GB0723883A GB0723883A GB2445231A GB 2445231 A GB2445231 A GB 2445231A GB 0723883 A GB0723883 A GB 0723883A GB 0723883 A GB0723883 A GB 0723883A GB 2445231 A GB2445231 A GB 2445231A
- Authority
- GB
- United Kingdom
- Prior art keywords
- trusted platform
- code
- platform module
- endorsement
- suspect code
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
- H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
Authentication of suspect code using tables in a Trusted Platform Module (TPM): A code validation system is disclosed comprising: a processor having an execution space; a secure storage area with a table for validation software; a trusted platform module device having registers: and, for each trusted platform module: an endorsement public / private key pair; and validation public keys and encrypted hash values, together associated with hash algorithms. Also disclosed is a system and method for authenticating suspect code including the steps of: receiving the suspect code for a first instance of a trusted platform module; loading the suspect code into a trusted platform module device operatively associated with a processor, wherein the suspect code is loaded outside of a shielded location within the trusted platform module device; retrieving a validation public key from a table and storing it in a register in the trusted platform module device, the validation public key indexed by the suspect code; retrieving a hash algorithm from the table, the hash algorithm indexed by the suspect code (or by the first instance of the trusted platform module); running the hash algorithm to derive a first hash value; decrypting a second hash value, using the validation public key; comparing the two hash values; and, upon determining a match, the suspect code is loaded into the shielded location of the processor for execution by the processor.
Description
AUTHENTICATING SUSPECT DATA USING KEY TABLES
The invention disclosed broadly relates to the field of data security, and more particularly relates to the field of enhancing the security features of trusted platform modules E-commerce, e-government and e-business are all growing in tandem with an increase in cyber crime. Many high tech security technologies have been implemented to address the increasing threat of cyber crime, but there is a tradeoff emerging in the use of security technologies for protecting data and authenticating identities and transactions, IT owners of processes involving these identities and transactions desire to use specific authentication and encryption algorithms tailored to their risk profiles. Associated with these algorithms, they want to use specific, feature set implementations of Trusted Platform Modules (TPMs) to support the required assurance level of their end to end systems and operational models TPMs are microchips designed to provide certain basic security-related functions to the software that utilizes the TPM. As a hardware-based security system, a TPM is much safer than a software-based security feature, but this increased safety comes at a high price and usually more administrative work. FIG. 1 shows a simplified block diagram of a basic TPM 100. The hardware components of the TPM 100 include: a hardware engine 120, a hash engine 140, a random number generator 160, and internal hardware-protected storage 180. Currently, TPMs require specific cryptographic algorithms, such as RSA SHA-1 and HMAC (hash function based message authentication code). RSA was developed by R.L. Rivest, A. Shamir, and L.M. Adleman. SHA-1 is a secure hash algorithm standard.
Referring to FIG. 2 there is shown a 1PM software stack At the lowest level is the TPM hardware device 210, which is a chip usually located on a motherboard. The TPM is accessed via a TPM device driver library 220 Applications use the 1PM through standard interfaces, or by directly implementing communication with the TSS 230. The TSS 230 is the TCPA (Trusted Computing Platform Alliance) Software Stack which provides the supporting functionality to the TPM. The next higher level is the cryptographic service provider 240, such as Microsoft's CAPI.
At the highest level are the applications 250 that use the 1PM 210.
The typical approach of implementing various algorithms and TPMs as delivered in unique or integrated hardware devices will keep security costs rising. What is needed is a flexible, yet secure, approach that uses a secure programmable microcontroller to support various selectable authentication and encryption algorithms and to also use these with the emulation of different instances of TPM hardware When execution code in a programmable microcontroller is loaded and unloaded from a cache for various operations the integrity of a particular security operation cannot be validated each time it is used. Bulk encryption (or block encryption) is on answer to this problem, but it is considered too slow.
Therefore, there is a need for a security system to overcome the shortcomings of
the prior art.
Briefly, according to an embodiment of the invention a method for authenticating suspect code includes steps or acts of. receiving the suspect code for a first instance of a trusted platform module; loading the suspect code into a trusted platform module device operatively associated with a processor, wherein the suspect code is loaded outside of a shielded location within the trusted platform module device; retrieving a validation public key from a first table and storing it in a register in the trusted platform module device, the validation public key indexed by the suspect code; and retrieving a hash algorithm from a table, the hash algorithm indexed by the suspect code. The method further proceeds by: running the hash algorithm associated with the suspect code to derive a first hash value; decrypting, using the validation public key, an encrypted second hash value stored in the table to derive a second decrypted hash value, the second hash value indexed by the suspect code; comparing the second decrypted hash value to the first hash value to determine if they are equal; and upon determining that the first and second hash values are equal, loading the suspect code into the shielded location of the processor for execution by the processor.
The method further includes steps or acts of.; retrieving an endorsement private key; storing the endorsement private key in a register within the trusted platform module device; and executing the suspect code from the execution space A system for validation of code, according to an embodiment of the present invention, includes the following components for carrying out the above method steps: a processor including an execution space, a trusted platform module device that includes trusted platform module registers; an endorsement key pair for each instance of trusted platform modules, the endorsement key including an endorsement private key and an endorsement public key; validation public keys and encrypted hash values for the each instance of trusted platform modules; a secure storage area including at least one table for storing validation software The system further includes: an input/output interface, a system memory, and a mass storage device.
According to another embodiment of the present invention a computer readable medium includes software for executing the above method steps.
To describe the foregoing and other exemplary purposes, aspects, and advantages, we use the following detailed description of an exemplary embodiment of the invention with reference to the drawings, in which: FIG. 1 is a simplified block diagram of a typical trusted platform module, according to the known art.
FIG. 2 is a simplified block diagram of a trusted platform module software stack, according to the known art.
FIG. 3 is a high level block diagram of an information processing system configured to operate according to an embodiment of the invention.
FIG. 4 is a flowchart of a method according to an embodiment of the invention.
FIG. 5 is a simplified diagram of a table of keys according to an embodiment of the present invention.
FIG. 6 is simplified diagram of another table of keys, according to an embodiment of the present invention.
FIG 7 is a simplified block diagram of an alternate configuration of the information processing system of FIG. 3, according to another embodiment of the present invention.
FIG. 8 is a simplified block diagram of a table of keys showing both the endorsement keys and the validation public key in one table, according to another embodiment of the present invention.
FIG. 9 is a simplified block diagram of another alternate configuration of the information processing system of FIG. 3, according to another embodiment of the present invention.
FIG. 10 is a simplified diagram of a table of keys with the emulator code, the validation public key and the endorsement keys together in one table, according to another embodiment of the present invention.
While the invention as claimed can be modified into alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the scope of the present invention.
We describe a flexible but secure method for using a programmable microcontroller to support various selectable authentication and encryption algorithms and to also use these with the emulation of different instances of TPM hardware. This is accomplished by the novel use of tables of keys, indexed by the emulation code.
What follows is a Glossary of Terms (from TCG Glossary of Technical Terms," incorporated by reference as if fully set forth herein) which are applicable to any discussion regarding TPMs: Glossary of Terms: Endorsement Key -EK; an RSA Key pair composed of a public key (EKpu) and private (EKpr) The EK is used to recognize a genuine TPM. The EK is used to decrypt information sent to a TPM in the Privacy CA and DAA protocols, and during the installation of an Owner in the 1PM.
Endorsement Key Credential -A credential containing the EKpu that asserts that the holder of the EKpr is a 1PM conforming to TCG specifications. Most TPMs are implemented in hardware, but this is not mandatory.
Non-volatile (shielded location) -A shielded storage location whose contents are guaranteed to persist between uses by Protected Capabilities Platform -A platform is a collection of resources that provides a service.
Protected Capabilities -The set of commands with exclusive permission to access shielded locations.
Root of Trust (component) -A component that must always behave in the expected manner, because its misbehavior cannot be detected. The complete set of Roots of Trust is at least the minimum set of functions to enable a description of the platform characteristics that affect the trustworthiness of the platform.
RSA -a cryptographic algorithm bearing the surname initials of its developers, R.L.
Rivest, A. Shamir, and L.M Adleman.
RTS -"Root of Trust for Storage" -a computing engine capable of maintaining an accurate summary of values of integrity digests and the sequence of digests.
RTR -"Root of Trust for Reporting" -a computing engine capable of reliably reporting information held by the RTS SHA-1 -a secure hash algorithm standard.
Shielded Location -A place (memory, register, etc.) where it is safe to operate on sensitive data; data locations that can be accessed only by "protected capabilities" Trust is the expectation that a device will behave in a particular manner for a specific purpose.
A Trusted Computing Platform is a computing platform that can be trusted to report its properties 1PM -Trusted Platform Module -an implementation of the functions defined in the TCG Trusted Platform Module Specification; the set of Roots of Trust with shielded locations and protected capabilities, normally includes just the RTS and the RTR.
TSS -Trusted Software Stack -software services that facilitate the use of the TPM but do not require the protections afforded to the TPM The System.
Referring now in specific detail to the drawings, and particularly FIG. 3, there is illustrated a simplified block diagram of an information processing system 300 configured to operated according to an embodiment of the invention.
Referring to FIG 3, information handling system 300 includes a processor 302, a TPM chip 309, a system memory 304, and an input/output (I/O) subsystem 306. A storage medium such as a CDROM 305 is operatively connected to the I/O subsystem 306 Processor 302 and system memory 304 components can be physically connected or operatively interconnected The TPM chip 309 may be located separately from the processor 302, or it may part of the processor 302, comprising a core chipset. The processor 302 can be a microprocessor. The processor 302 includes a microprocessor CPU 350 and an execution space 322 The execution space 322 is a secure area where data is protected against interference and prying, independent of its form. It is considered a shielded location. Only verified code is loaded into the execution space 322.
Secure memory 312 generally resides within the 1PM chip 309. The secure memory 312 also contains embedded instructions in the form of microcode. System storage 308 is also available, outside of the shielded location. 1PM emulator code 314 can be stored within the microprocessor 302 or in system storage 308 as depicted in FIG. 3 The TPM chip 309 according to an embodiment of the present invention is a generic 1PM chip that can emulate different TPMs using the 1PM emulator code 314 The emulator code 314 enables the microprocessor 302 to simulate any trusted platform module, thus allowing a relatively inexpensive generic TPM chip to work with a broad range of platforms This is important because TPMs can differ from organization to organization and there are many different formats available.
For example, the United States government uses one type of TPM, and the Chinese government uses another type TPM emulator code is known in the industry. The challenge becomes safeguarding the emulator code 314 so that no untrusted code is ever executed. This process will be explained in the discussion regarding FIG. 4 below.
Referring again to FIG. 3, a table 332 of hash values is stored within the secure storage area 312 and acts as a Iookup table. This secure storage area 312 is generally located in the TPM chip 309 as shown in FIG. 3, however, it could be stored elsewhere, perhaps in the processor 302. The values in table 332 are indexed by the 1PM code 314, as shown in FIG. 5. Additionally, another table 342 holds all of the endorsement keys generated for each TPM A second table, table 342, is also shown stored within the TPM chip 309, but to conserve space it can be stored outside of the secure area 312, as shown in FIG. 3. Note that the two tables, 332 and 342, are illustrated in FIG. 3. This is merely to illustrate one embodiment; however, the actual configuration and number of tables could vary, depending on the information stored, the hardware configuration, and the individual system space constraints, according to the present invention.
At either manufacturing or install time, a hash value for each instance of execution code for a TPM is created Usually this is done by the information technology (IT) owner For each platform, there is a known list of supported TPMs. Each of the supported TPMs will have its own associated hash value. Each hash value (Hash) is bound with the endorsement key (EK) for that particular 1PM. An endorsement key is a cryptographic key pair using the RSA algorithm. In addition to this key pair, a public key is also generated that holds the signature with which the TPM emulation code was signed. This public key, the validation public key (PK) is stored in table 332. Only the hash table 332 needs to be stored in secure storage, to conserve space. Concurrently, a hash value is also created for each of the encryption algorithms for the TPMs. The actual TPM emulator code 314 and encryption algorithm code and the encryption code's corresponding public key can be stored unencrypted in system storage 308 to conserve space within the microprocessor 302. The private key of the EK (EKpr), however, cannot be stored in system storage 308.
Referring now to FIG. 5, table 332 also stores the signed hash values (Hash) bound with the EK, and the validation public keys (PK) Table 332 additionally stores the hash algorithm (Aig) for each TPM code All of these values are indexed by the TPM code. More specifically, in this embodiment, the first column of table 332 holds a unique identifier that is associated with that TPM code. Other embodiments may index the keys somewhat differently, yet remain with the scope of the present invention.
Referring now to FIG. 7 there is shown an alternate configuration for the information processing system 300 of FIG 3. System 700 shows only one table 352 residing in secure storage 312 within the TPM chip 309 This table 352 is shown in FIG. 8.
Note that unlike the table of FIG. 5, table 352 holds the validation public keys (PK), the hash algorithms, the hash values, and the endorsement keys.
Another configuration within the scope of the present invention is shown in the block diagram of FIG. 9. Information processing system 900 again shows only one table 362 residing in secure storage 312. However, this table 362, unlike table 352 of FIG. 7, holds the TPM Codes, as well as the endorsement keys, the validation public keys, and the hash information. This table 362 is shown in FIG. 10 Note the emulator code 314 is system firmware. Other configurations of tables and keys are possible within the spirit and scope of the present invention.
The Process.
The code validation method, according to an embodiment of the present invention, validates TPM emulator code without exposing its own internal code. This is because the authentication is done prior to loading the emulator code into the microcontroller execution space 322 through the use of tables and their indexed values. Hardware-resident security measures are considered to be the most reliable, therefore it is preferable to hard-wire as much information as possible into the microprocessor and/or the chipset. Space becomes an issue: therefore a determination must be made as to what information gets hard-wired and what can be stored elsewhere. The flexibility of this code validation method allows the TPM emulator code 314 to be stored either within the microprocessor 302 or outside of the microprocessor 302. In this example of FIG. 3 the code 314 is stored in system storage 308 outside of the microprocessor 302. The authentication method described here below will assure the validity of the code before it is executed, even though it has been stored outside of a shielded location. The authentication method is able to easily identify code that has been tampered with.
Referring to FIG. 4 there is shown a flowchart 400 of the code validation method according to an embodiment of the present invention. The process begins at step 410 when a user selects a TPM code to execute from the pre-loaded set of emulator code 314 in system storage 308. The user interacts with the system 300 through the input/output subsystem 306. The user selects a TPM code from the various TPM codes available. These codes are generally stored in system storage, not fl the TPM chip 309. The 1PM code that the user selects is code that the user wants to run as a TPM emulator (referred to hereafter as "suspect code"). The user wishes to load this suspect code so that it can be executed For it to be executed, it has to be loaded into the execution space 322 When executed from the execution space 322, this emulator code will simulate whatever TPM the user has selected.
Assuming that the user has selected TPM code for 1PM4, the processor 302 must confirm the system identity of this suspect code, 1PM Code4. This means that 1PM4 must be a "trusted" TPM and TPM Code4 must have remained unchanged since it was loaded into the system 300. In order to do this, the microprocessor 302 loads the suspect code into the TPM chip 309 in step 420 and in step 430 loads the validation public key used to sign TPM Code4 into the chip's main registers 319.
This validation public key is PK4 from table 332, shown in FIG. 5. 1PM Code4 is loaded into memory 350 inside the 1PM 309. Note that although the suspect code is loaded into the 1PM 309, it has not been brought into the execution space 322 because it has not been verified.
Next, in step 440, the 1PM chip 309 uses the suspect code, TPM Code4, as an index to retrieve its corresponding hash algorithm, Alg4, from table 332. The chip 309 runs A1g4 in order to compute a first hash value. Keep in mind that each instance of 1PM code is associated with its own hash algorithm and keys needed to decrypt the algorithms are freely accessible in system storage 308. Next, in step 450, using the validation public key, PK4, associated with 1PM Code4, the TPM chip 309 decrypts the hash value, Hash4, that pertains to Alg4 (from table 332).
This provides a second hash value These two hash values, the first hash value computed in step 440 and the second hash value decrypted in step 450, should be identical. If they are identical, this confirms that 1PM Code4 is unchanged and it has not been tampered with or modified in any way since it was loaded onto the system 300. This verification step is what enables the different emulator codes 314 to be kept outside of the relative security of the chip 309.
In step 460, the first and second hash values are compared by the chip 309 If the values match (the comparison code returns a TRUE result) this indicates that 1PM Code4 has been verified and it is assumed unchanged and trusted.
Next, in step 470 an optional step of verifying that the user is authorized to run TPM code4 is carried out. After verification, in step 480 the suspect code is loaded into the microcontroller execution space 322 so that it can be executed.
In step 485 a check is made to determine if this is the first time that 1PM Code4 has been run. If so, then in step 490 the 1PM chip 309 will generate an EK pair for this code, EK4. Each TPM generates its own EK comprising one private key portion (EKpr) and one public key portion (EKpu) at its initiation. This key pair is stored in table 342, according to an embodiment of the invention Referring now to FIG. 6, table 342 holds the EK, indexed by the 1PM code, for each instance of 1PM code loaded into the system 300. The EKpu from EK4 can be given to other individuals so that they may verify that a document was signed by the private key EKpr The EKpr will not be given out.
In step 495, at the time that TPM Code4 is loaded into the execution space 322, the private key associated with it, EKpr4, is loaded from table 342 into the TPM's main registers 319. The registers 319 store only the currently needed keys. Once a new 1PM emulator is loaded into the registers, the keys are replaced. This is done so that a user has the ability to generate a proprietary private/public key pair for security reasons It is important to note that a user may not know the hash algorithm used to generate the key pair; therefore the user will need this key pair to be able to sign and validate the user's loaded code. There is a process to migrate/back up the private keys. This process involves encrypting the private key during the export process and is known to those with knowledge in the art. Lastly, in step 497, the 1PM executes the code, TPM Code4, from the execution space 322 after the EK4 keys are loaded and stored.
If the values from the hash value comparison of step 460 do not match, the emulator code 314 is not moved into the execution space 322, therefore it cannot be run, and the process ends Any code currently residing in the execution space 322 has not been exposed to any security breach throughout this entire operation.
By securing the validation public keys (PKs) and hash values only in secure storage 322, this method reduces the amount of space required, while still providing security. The PKs and hash algorithms can be offloaded to a less secure storage location in order to conserve space. This is particularly important because of the physical space constraints imposed by the increasing number of keys which need to be considered.
Therefore, while there have been described what are presently considered to be the preferred embodiments, it will be understood by those skilled in the art that other modifications can be made within the spirit of the invention.
Claims (22)
- CLAIMS: 1 A system for validation of code, the system comprising: aprocessor comprising an execution space; a trusted platform module device comprising trusted platform module registers; an endorsement key pair for each instance of trusted platform modules, said endorsement key pair each comprising an endorsement private key and an endorsement public key, validation public keys and encrypted hash values for each instance of trusted platform modules; hash algorithms associated with the validation public keys and the encrypted hash values; and a secure storage area comprising at least one table for storing validation software.
- 2. The system of claim 1 wherein the code is trusted platform module emulator code and the validation public keys and encrypted hash values are indexed by said trusted platform module emulator code.
- 3. The system of claim 2 wherein the at least one table comprises first and second tables, the first table comprising the validation public keys and the encrypted hash values; the second table comprising endorsement key pairs
- 4. The system of claim 3 wherein the first able further comprises: hash algorithms associated with the validation public keys and the encrypted hash values
- 5. The system of claim 4 wherein the first table further comprises: trusted platform module emulator code and an endorsement key associated with an emulator code encryption algorithm.
- 6 The system of claim 3 wherein the second table further comprises: the trusted platform module emulator code.
- 7. The system of claim 4 wherein the first table further comprises: the endorsement key pair.
- 8. The system of claim 1 wherein the hash algorithms are stored in unencrypted system storage.
- 9. The system of claim 2 wherein the endorsement private keys are stored in the trusted platform module registers.
- 10. The system of claim 1 wherein the secure storage area is located in the trusted platform module device
- 11. The system of claim 10 wherein the at least one table in the secure storage area comprises validation firmware.
- 12 The system of claim 1 further comprising: system storage located outside of the processor and the trusted platform module device, said system storage comprising at least one table for storing validation software.
- 13 A method for authenticating suspect code, comprising steps of: a) receiving the suspect code for a first instance of a trusted platform module; b) loading the suspect code into a trusted platform module device operatively associated with a processor, wherein said suspect code is loaded outside of a shielded location within said trusted platform module device; C) retrieving a validation public key from a table and storing said validation public key in a register in the trusted platform module device, said validation public key indexed by the suspect code; d) retrieving a hash algorithm, said hash algorithm indexed by the suspect code; e) running the hash algorithm associated with the suspect code to derive a first hash value; f) decrypting, using the validation public key, an encrypted second hash value stored in the table to derive a second decrypted hash value, said second hash value indexed by the suspect code; g) comparing the second decrypted hash value to the first hash value to determine whether the first and second hash values are equal; and upon determining that the first and second hash values are equal.h) loading the suspect code into an execution space of the processor for execution by the processor
- 14. The method of claim 13, further comprising a step of.verifying that a user is authorized to run the suspect code before loading the suspect code into the execution space of the processor.
- 15. The method of claim 13 wherein the table is located in a secure storage location.
- 16. The method of claim 15 wherein the secure storage location is located within the trusted platform module device.
- 17. The method of claim 13 further comprising steps of: i) determining if the suspect code has not been initialized; and if the suspect code has not been initialized: generating an endorsement key pair for the suspect code, the endorsement key pair comprising an endorsement private key and an endorsement public key; and storing the endorsement private key and the endorsement public key in the table, said table located within the trusted platform module device; j) retrieving the endorsement private key from the table; k) storing the endorsement private key in a register within the trusted platform module device; I) retrieving the endorsement public key from the table and storing said endorsement public key in the register, and m) executing the suspect code from the execution space.
- 18. The method of claim 13 further comprising a step of storing the hash algorithm in unencrypted system storage.
- 19. A computer readable medium comprising: computer code which enables a processor to execute the following steps.a) receive suspect code for a first instance of a trusted platform module; b) load the suspect code into a trusted platform module device operatively associated with the processor, wherein said suspect code is loaded outside of a shielded location within said trusted platform module device, c) retrieve a validation public key from a table and store said validation public key in a register in the trusted platform module device, said first validation public key indexed by the suspect code; d) retrieve a hash algorithm from the table, said hash algorithm indexed by the first instance of the trusted platform module; e) run the hash algorithm associated with the first instance of the trusted platform module to derive a first hash value; f) decrypt, using the validation public key, an encrypted second hash value stored in the table to derive a second decrypted hash value, said second hash value indexed by the suspect code, g) compare the second decrypted hash value to the first hash value; and upon determining that the first and second hash values are equal: h) load the suspect code into an execution space of the processor for execution by the processor.
- 20. The computer readable medium of claim 18 wherein the computer code further enables the processor to execute the following steps i) determine if the suspect code has not been initialized; and if the suspect code has not been initialized; generate an endorsement key pair for the suspect code, the endorsement key pair comprising an endorsement private key and an endorsement public key; and store said endorsement private key and said endorsement public key in the table; j) retrieve the endorsement private key from the table; k) store the endorsement private key in a register within the trusted platform module device; I) retrieve the endorsement public key from the table and store said endorsement public key in the register; and m) execute the suspect code from the execution space.
- 21. A system for validation of code, substantially as described herein with reference to, and as illustrated in, Figures 3 to 10 of the accompanying drawings.
- 22. A method for authenticating suspect code, substantially as described herein with reference to, and as illustrated in, Figures 3 to 10 of the accompanying drawings.23 A computer readable medium, substantially as described herein with reference to, and as illustrated in, Figures 3 to 10 of the accompanying drawings
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0903328A GB2455004B (en) | 2006-12-29 | 2007-12-06 | Authenticating suspect data using key tables |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/647,932 US8024579B2 (en) | 2006-12-29 | 2006-12-29 | Authenticating suspect data using key tables |
Publications (3)
Publication Number | Publication Date |
---|---|
GB0723883D0 GB0723883D0 (en) | 2008-01-16 |
GB2445231A true GB2445231A (en) | 2008-07-02 |
GB2445231B GB2445231B (en) | 2009-04-22 |
Family
ID=38983095
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB0903328A Active GB2455004B (en) | 2006-12-29 | 2007-12-06 | Authenticating suspect data using key tables |
GB0723883A Active GB2445231B (en) | 2006-12-29 | 2007-12-06 | Authenticating suspect data using key tables |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB0903328A Active GB2455004B (en) | 2006-12-29 | 2007-12-06 | Authenticating suspect data using key tables |
Country Status (3)
Country | Link |
---|---|
US (1) | US8024579B2 (en) |
DE (1) | DE102007057900B4 (en) |
GB (2) | GB2455004B (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2500880A4 (en) * | 2009-11-09 | 2016-08-10 | Nec Platforms Ltd | Handy terminal and payment method used for the handy terminal |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102006006633A1 (en) * | 2006-02-10 | 2007-08-16 | Sia Syncrosoft | Disseminating contents, data blocks for encoding contents involves receiving encoded contents in at least two receivers and decoding them using different data blocks,; encoding of contents is not receiver-specific or receiver group-specific |
GB0704963D0 (en) * | 2007-03-14 | 2007-04-25 | British Telecomm | Verification of movement of items |
US8141045B2 (en) * | 2007-12-14 | 2012-03-20 | International Business Machines Corporation | Automatically identifying the source of copied software |
US8285985B2 (en) | 2008-12-15 | 2012-10-09 | Sap Ag | Systems and methods for detecting exposure of private keys |
US10452817B1 (en) * | 2009-04-08 | 2019-10-22 | Trend Micro Inc | File input/output redirection in an API-proxy-based application emulator |
MY154286A (en) * | 2010-10-29 | 2015-05-29 | Mimos Berhad | Method and system to establish a trusted interface in a network environment |
US8769302B2 (en) | 2011-10-14 | 2014-07-01 | International Business Machines Corporation | Encrypting data and characterization data that describes valid contents of a column |
US9152793B2 (en) * | 2012-09-28 | 2015-10-06 | Intel Corporation | Methods, systems and apparatus to self authorize platform code |
US9754133B2 (en) * | 2013-03-14 | 2017-09-05 | Microchip Technology Incorporated | Programmable device personalization |
TWI531490B (en) * | 2013-08-20 | 2016-05-01 | Mobiletron Electronics Co Ltd | Code and its code method |
CN103927488A (en) * | 2014-04-04 | 2014-07-16 | 西安电子科技大学 | Trusted platform module aiming at trusted embedded system |
US20160373260A1 (en) * | 2015-02-26 | 2016-12-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Public Key Based Network |
CN105847011A (en) * | 2016-03-21 | 2016-08-10 | 华为技术有限公司 | Key loading method and device |
US11436883B2 (en) * | 2018-07-09 | 2022-09-06 | Hampton Products International Corporation | Secured tethering process between devices |
CN111835779B (en) * | 2020-07-20 | 2023-04-18 | 安徽华速达电子科技有限公司 | Authentication method for equipment access platform |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050138393A1 (en) * | 2003-12-22 | 2005-06-23 | Challener David C. | Determining user security level using trusted hardware device |
WO2006011943A1 (en) * | 2004-06-24 | 2006-02-02 | Intel Corporation | Method and apparatus for providing secure virtualization of a trusted platform module |
WO2006124751A2 (en) * | 2005-05-13 | 2006-11-23 | Intel Corporation | Method and apparatus for providing software-based security coprocessors |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3747520B2 (en) * | 1996-01-30 | 2006-02-22 | 富士ゼロックス株式会社 | Information processing apparatus and information processing method |
EP1026898A1 (en) * | 1999-02-04 | 2000-08-09 | CANAL+ Société Anonyme | Method and apparatus for encrypted transmission |
US7558965B2 (en) * | 2000-08-04 | 2009-07-07 | First Data Corporation | Entity authentication in electronic communications by providing verification status of device |
US20020129261A1 (en) * | 2001-03-08 | 2002-09-12 | Cromer Daryl Carvis | Apparatus and method for encrypting and decrypting data recorded on portable cryptographic tokens |
US7624272B2 (en) * | 2003-03-31 | 2009-11-24 | Intel Corporation | Platform information for digital signatures |
US7751568B2 (en) | 2003-12-31 | 2010-07-06 | International Business Machines Corporation | Method for securely creating an endorsement certificate utilizing signing key pairs |
US20060005015A1 (en) | 2004-06-30 | 2006-01-05 | David Durham | System and method for secure inter-platform and intra-platform communications |
US8806224B2 (en) * | 2005-06-28 | 2014-08-12 | Intel Corporation | Low cost trusted platform |
JP4769608B2 (en) * | 2006-03-22 | 2011-09-07 | 富士通株式会社 | Information processing apparatus having start verification function |
-
2006
- 2006-12-29 US US11/647,932 patent/US8024579B2/en active Active
-
2007
- 2007-11-29 DE DE102007057900.6A patent/DE102007057900B4/en active Active
- 2007-12-06 GB GB0903328A patent/GB2455004B/en active Active
- 2007-12-06 GB GB0723883A patent/GB2445231B/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050138393A1 (en) * | 2003-12-22 | 2005-06-23 | Challener David C. | Determining user security level using trusted hardware device |
WO2006011943A1 (en) * | 2004-06-24 | 2006-02-02 | Intel Corporation | Method and apparatus for providing secure virtualization of a trusted platform module |
WO2006124751A2 (en) * | 2005-05-13 | 2006-11-23 | Intel Corporation | Method and apparatus for providing software-based security coprocessors |
Non-Patent Citations (1)
Title |
---|
Trusted Computing Group, Trusted Platform Modules Strengthen User and Platform Authenticity, January 2005, downloaded 18th March 2008 from: https://www.trustedcomputinggroup.org/specs/TPM/Whitepaper_TPMs_Strengthen_User_and_Platform_Authenticity_Final_1_0.pdf * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2500880A4 (en) * | 2009-11-09 | 2016-08-10 | Nec Platforms Ltd | Handy terminal and payment method used for the handy terminal |
US10491395B2 (en) | 2009-11-09 | 2019-11-26 | Nec Platforms, Ltd. | Handy terminal and payment method to be used in same |
Also Published As
Publication number | Publication date |
---|---|
GB0903328D0 (en) | 2009-04-08 |
DE102007057900A1 (en) | 2008-07-03 |
US8024579B2 (en) | 2011-09-20 |
GB0723883D0 (en) | 2008-01-16 |
DE102007057900B4 (en) | 2017-02-16 |
GB2455004A (en) | 2009-05-27 |
US20080162932A1 (en) | 2008-07-03 |
GB2445231B (en) | 2009-04-22 |
GB2455004B (en) | 2011-02-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8024579B2 (en) | Authenticating suspect data using key tables | |
US7055029B2 (en) | Cryptographic system enabling ownership of a secure process | |
Tomlinson | Introduction to the TPM | |
CN101894224B (en) | Protecting content on client platforms | |
EP1850265B1 (en) | Computer architecture for an electronic device providing SLS access to MLS file system with trusted loading and protection of program execution memory | |
US7694139B2 (en) | Securing executable content using a trusted computing platform | |
KR101231561B1 (en) | Secure policy differentiation by secure kernel design | |
CA2507793C (en) | System and method for protected operating system boot using state validation | |
EP1840786B1 (en) | Computer architecture for an electronic device providing single-level secure access to multi-level secure file system | |
US8127145B2 (en) | Computer architecture for an electronic device providing a secure file system | |
US9026803B2 (en) | Computing entities, platforms and methods operable to perform operations selectively using different cryptographic algorithms | |
US9122864B2 (en) | Method and apparatus for transitive program verification | |
Jacob et al. | faulTPM: Exposing AMD fTPMs’ Deepest Secrets | |
CN117063174A (en) | Security module and method for inter-app trust through app-based identity | |
Safford et al. | Trusted computing and open source | |
CN117932691A (en) | BMC data writing method, system, device and medium | |
Talmi | Security Target | |
Menda-Shabat | Security Target | |
Noller | Security Target |