US20140215202A1 - Extension of a platform configuration register with a known value - Google Patents
Extension of a platform configuration register with a known value Download PDFInfo
- Publication number
- US20140215202A1 US20140215202A1 US13/756,194 US201313756194A US2014215202A1 US 20140215202 A1 US20140215202 A1 US 20140215202A1 US 201313756194 A US201313756194 A US 201313756194A US 2014215202 A1 US2014215202 A1 US 2014215202A1
- Authority
- US
- United States
- Prior art keywords
- value
- binary
- computing system
- signature
- valid
- 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
- 238000000034 method Methods 0.000 claims description 27
- 230000015654 memory Effects 0.000 claims description 21
- 238000012545 processing Methods 0.000 claims description 16
- 230000006870 function Effects 0.000 claims description 13
- 230000003068 static effect Effects 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 238000005259 measurement Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Images
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
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
Definitions
- the embodiments of the disclosure relate generally to platform configuration registers, and, in particular to extending a platform configuration register with a known value.
- TCG Trusted Computing Group
- TPM trusted platform module
- TPM techniques can be implemented in a variety of platforms including servers, desktops, notebooks, or handheld computing devices.
- the purpose of the TPM is to provide computer identity and secure services related to transactions, protecting user data, and other special functions.
- Current trusted computing mechanisms which root the integrity of a platform, do so by “extending” a platform configuration register with a cryptographic hash representing the binary of the software. If, however, the binary of the software changes, which is prone to happen, then the cryptographic hash also changes. When any update is made to a trusted binary, an update should also be made to the contents of the platform configuration register.
- FIG. 1 illustrates one embodiment of a computing system, in accordance with various implementations
- FIG. 3 illustrates a flow diagram of one embodiment of a method for extending a platform configuration register value with a known value
- FIG. 4 is a block diagram of an example computer system that may perform one or more of the operations described herein.
- a computing system can include a trusted platform module.
- the trusted platform module can be a microprocessor that includes a data store (e.g., platform configuration registers) to store data when the computing system validates the integrity of the computing system components (e.g., hardware components, software components).
- the trusted platform module when the computing system validates the signature of a component, the trusted platform module extends a platform configuration register with a known value (e.g., public key associated with the signature of the component) instead of extending the platform configuration register with a hash value that is based on the binary of the component.
- a known value represents a value that is known or available to the public.
- An example of a known value can include, and is not limited to, a public key in public-key cryptography systems.
- a binary hereinafter refers to a type of binary file that contains machine code for a component, which the computing system can execute.
- FIG. 1 illustrates one implementation of a computing system 100 having a trusted platform architecture.
- the computing system 100 may be configured with various hardware components (e.g., base hardware platform 106 ) to support the execution of software components 101 that may include a kernel 102 and applications 104 .
- the base hardware platform 106 may include a processor 108 , memory 110 , a storage disk 112 , a power supply 114 , various add-on cards 116 , and a trusted platform module 118 .
- the trusted platform module 118 can include platform configuration registers 124 to store data.
- One implementation of the trusted platform module is described in greater detail below in conjunction with FIG. 2 .
- multiple interfaces can be used to couple the devices of the base hardware platform 106 to each other and other components of the computing system 100 .
- the hardware components in the base hardware platform 106 and the software components 101 may each be associated with binary, and may have a signature that is attached or supplied with the binary.
- the signature may have been created, for example, by hashing the binary and encrypting the hash of the binary.
- the computing system 100 can take an integrity measurement of the binary for a component and can verify if the signature that is associated with the binary is valid.
- the computing system 100 can use an asymmetric key signature algorithm to determine if the signature that is associated with the binary is valid.
- An example of an integrity measurement can include, and is not limited to, hash sums of files or data that are associated with the binary of the component.
- a trusted platform module 118 collectively represents any kind of trusted platform module, including a trusted platform module 118 implemented using software, firmware, hardware, or a combination thereof.
- the computing system 100 can check, for the various components, whether a signature that is associated with the binary of a particular component is valid. Each time the computer system 100 makes a determination of whether a signature is valid, the trusted platform module 118 can extend the platform configuration register 124 with a known value 126 .
- One implementation of the trusted platform module extending the platform configuration register with a known value is described in greater detail below in conjunction with FIG. 3 .
- the base hardware platform 106 may be a motherboard having firmware (e.g., power-on self-test basic input/output systems, or “POST BIOS”), that executes before the software components 101 (e.g., kernel 102 , operating system, or applications 104 ) initialize.
- firmware e.g., power-on self-test basic input/output systems, or “POST BIOS”
- the firmware may execute before a boot loader executes.
- a boot loader is a computer program that loads the main operating system or runtime environment for the computer after completion of the self-tests.
- the boot loader may execute before the kernel of the operating system executes, and the kernel may execute before any binary for applications 104 in the userspace of the operating system are executed.
- the firmware may take an integrity measurement for the binary of the boot loader and may determine whether the signature that is associated with the binary of the boot loader is valid. If the firmware determines that the signature that is associated with the boot loader is valid, the trusted platform module 118 can extend a platform configuration register 124 with a known value 126 (e.g., public key that is associated with the boot loader).
- the computing system 100 may then execute the boot loader.
- the boot loader may take an integrity measurement for the binary of the kernel and may determine whether the signature that is associated with the binary of the kernel is valid. If the boot loader determines that the signature that is associated with the kernel is valid, the trusted platform module 118 can extend the current value in the platform configuration register 124 using a known value 126 (e.g., public key) that is associated with the kernel.
- the computing system 100 can iterate through checking the integrity of the components and the validating the signatures that are associated with the binaries of the components. The number of iterations can be based on the number of components.
- FIG. 2 is a block diagram illustrating one implementation of the trusted platform module 200 .
- the client distribution module 300 may correspond to a client distribution module 138 in a client machine 102 of FIG. 1 .
- the trusted platform module 200 can extend the value of a platform configuration register 224 with a known value 226 .
- the trusted platform module 200 includes components specified by the Trusted Computing Group (“TCG”) specification.
- TCG Trusted Computing Group
- the trusted platform module 200 can be implemented in software and/or hardware that is compatible with a trusted platform module specification set forth, for example, by the TCG standard body
- the components can include, for example, a cryptographic co-processor 202 , a key generator 204 , a random number generator 206 , a SHA-1 engine 208 , an opt-in component 210 , a volatile storage 214 , platform configuration registers 224 , and one or more data stores 212 , 215 . Note that in alternative implementations, the functionality of one or more of the components can be combined or divided.
- the cryptographic co-processor 202 can perform cryptographic operations within the trusted platform module 200 .
- the key generator 204 can create symmetric keys and RSA asymmetric cryptographic key pairs.
- the random number generator 206 can provide randomness for the computation of various values such as keys or other values.
- the opt-in component 210 can maintain the state of persistent and volatile flags and can enforce semantics associated with those flags such that the trusted platform module 200 can be enabled and disabled.
- the data store 215 can store persistent identity and state information that is associated with the trusted platform module 200 .
- the data store 215 can be non-volatile memory.
- the trusted platform module 200 can include a set of platform configuration registers 244 .
- the trusted platform module 200 includes at least sixteen platform configuration registers 224 .
- the platform configuration registers 224 are each twenty bytes.
- the platform configuration registers 224 can reside in volatile and/or non-volatile memory.
- a subset of the set of platform configuration registers 244 can be designated for hardware components and another subset of the set of platform configuration registers 244 can be designated for software components.
- PCR-1 may be used for the motherboard manufacturer
- PCR-2 may be used for the processor
- PCR-3 may be used for the firmware, etc.
- registers 0-7 are reserved for trusted platform module use and registers 8-15 are available for operating system and application use.
- the platform configuration registers 224 values can be temporal and can be reset at computing system reboot.
- the values that are stored in one of the platform configuration registers 224 are “extendable,” in that the value for a particular platform configuration register is based on an aggregate of data.
- the current value that is stored in one the platform configuration registers 224 may be changed by hashing the current value in the platform configuration register 224 (e.g., PCR-1) with a new value to result in the “extended value” for the platform configuration registers 224 (e.g., PCR-1).
- the current value in a platform configuration register 224 is changed, for example, by a component (e.g., firmware, boot loader, kernel, application, etc.) sending an “Extend( )” operation to the trusted platform module 200 .
- a component e.g., firmware, boot loader, kernel, application, etc.
- the trusted platform module 200 can update the current value in a platform configuration register 224 using a known value 226 .
- the known value 226 , 213 is a public key.
- the known value 226 , 213 can be a predefined static value.
- the known value 226 , 213 is a user-defined value.
- the known value 226 that should be stored in the platform configuration register 224 can be based on a determination of whether the signature that is associated with binary of a component is valid. For example, if signature is valid, the trusted platform module 200 can use a public key that is associated with the component as the known value 226 . In another example, if the signature is not valid, the trusted platform module 200 can use a null value as the known value 226 .
- One implementation of the trusted platform module extending a platform configuration register is described in greater detail below in conjunction with FIG. 3 .
- the known value 226 , 213 is provided by a component vendor and/or component manufacturer.
- an operating system can provide a public key that is associated with a private key that was used to create a signature for binary associated with the operating system.
- the trusted platform module 200 stores the known values 213 , for example, in a data store 212 (e.g., non-volatile memory) in the trusted platform module 200 .
- the known values 226 , 213 are stored in a data store that is coupled to the trusted platform module.
- the SHA-1 engine 208 can implement the SHA-1 hash algorithm to calculate the new value for the platform configuration register 224 by hashing the current value in the platform configuration register 224 with a given value. For example, the current value that is stored in PCR-1 may be changed by the SHA-1 engine 208 hashing the current value in PCR-1 with a new value (e.g., public key) to result in the “extended value” for PCR-1.
- a new value e.g., public key
- FIG. 3 illustrates a flow diagram of one embodiment of a method 300 for extending a platform configuration register value with a known value.
- the method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both.
- at least a portion of the method is performed by a trusted platform module (e.g., trusted platform module 200 of FIG. 1 ) in a computing system (e.g., computing system 100 in FIG. 1 ).
- at least a portion of the method is performed by hardware components (e.g., components in vase hardware platform 106 in FIG. 1 ) and/or software components (e.g., software components 101 in FIG. 1 ) in a computing system (e.g., computing system 100 in FIG. 1 ).
- the computing system calculates a hash value of binary of a component of the computing system.
- the computing system may identify a system start event.
- the computing system may be initializing after a power down or reset/restart event, and the firmware of the motherboard of the computing system may be the first component to launch after power-up.
- the firmware may calculate a hash (e.g., cryptographic hash) of the binary of the boot loader.
- a cryptographic hash is a hash function that returns a fixed-size bit string as a result.
- the cryptographic hash function is SHA-1 Alternatively, any suitable cryptographic hash function may be used to calculate the hash for the binary.
- the computing system determines whether the signature that is associated with the binary of the component is valid using the public key.
- the computing system can use an asymmetric key signature algorithm to determine whether the signature is valid. If the signature is valid (block 309 ), the trusted platform module in the computing system, extends a platform configuration register in the trusted platform module using a known value at block 311 .
- the known value used when the signature is valid is the public key that is associated with the component. and sends an extend operation request to the trusted platform module.
- the trusted platform module receives an extend operation request from a component.
- the extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, public key) that the trusted platform module should use to extend the current value of the platform configuration register.
- the trusted platform module in the computing system extends a platform configuration register in the trusted platform module using another known value at block 313 .
- the known value used when the signature is not valid is a null value.
- the known value used when the signature is not valid is the hash value that is generated by hashing the binary of the component.
- the known value used when the signature is not valid can be another known value that is different from the known value that is used when the signature is valid.
- the trusted platform module receives an extend operation request from a component.
- the extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, null value, hash value) that the trusted platform module should use to extend the current value of the platform configuration register.
- the firmware calculates a hash value of the binary of the boot loader component using a SHA-1 hash function.
- the firmware retrieves the public key that is associated with the boot loader component from a data store in the computing system.
- the firmware retrieves the digital signature for the boot loader from a data store in the computing system. The digital signature may have been crated by the component vendor using the SHA-1 hash algorithm.
- the firmware decrypts the digital signature for the boot loader using the public key for boot loader to generate a hash value from the decrypted signature.
- the firmware compares the hash value that was identified from decrypting the digital signature using the public key with the hash value that was created by the firmware using a SHA-1 hashing function on the binary of the boot loader, for example, from block 301 .
- the SHA-1 engine (e.g., SHA-1 engine 208 in FIG. 2 ) in the trusted platform module can implement the SHA-1 hash algorithm to calculate the new value for updating the platform configuration register by hashing the current value in the platform configuration register with the known value. For example, if the signature is valid, the current value that is stored in PCR-1 may be changed by the SHA-1 engine hashing the current value in PCR-1 with the known value (e.g., public key) to generate a new value for PCR-1. The trusted platform module can replace the current value for the platform configuration register with the new value.
- the known value e.g., public key
- the computing system iterates method 300 to check the integrity of the components and to validate the signatures that are associated with the binaries of the components.
- the number of iterations can be based on the number of components.
- the computing system may continue the boot up sequence by measuring the next component in the boot up sequence.
- the firmware may perform at least a portion of method 300 with respect to a boot loader, then the boot loader may perform at least a portion of the method 300 with respect to the kernel of the operating system, and the kernel may perform at least a portion of the method 300 with respect to a binary of an application.
- the stored values in the platform configuration registers can be used to provide state information to another system and/or sub-system.
- the computing system may be a mobile user device.
- the mobile user device has been requested to provide its trusted platform module state information to a cell phone tower before the tower before the cellular tower will allow the mobile user device to access to the cellular network.
- the computing system may reside in a data center.
- the computer system may be requested to provide its trusted platform module state information to a server before the computing system is given access to the rest of the network.
- the computing system is requested by a disk reader to provide its trusted platform module state information to the disk reader before an encrypted disk is unlocked.
- FIG. 4 illustrates an example machine of a computer system 400 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
- the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and/or the Internet.
- the machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
- the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- PC personal computer
- PDA Personal Digital Assistant
- STB set-top box
- STB set-top box
- a cellular telephone a web appliance
- server a server
- network router a network router
- switch or bridge any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
- machine shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- the computer system 400 may further include a network interface device 408 .
- the computer system 400 also may include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse), and a signal generation device 416 (e.g., a speaker).
- a video display unit 410 e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)
- an alphanumeric input device 412 e.g., a keyboard
- a cursor control device 414 e.g., a mouse
- a signal generation device 416 e.g., a speaker
- the data storage device 418 may include a machine-readable storage medium 428 (also known as a computer-readable medium) on which is stored one or more sets of instructions or software 422 embodying any one or more of the methodologies or functions described herein.
- the instructions 422 may also reside, completely or at least partially, within the main memory 404 and/or within the processing device 402 during execution thereof by the computer system 400 , the main memory 404 and the processing device 402 also constituting machine-readable storage media.
- machine-readable storage medium 428 is shown in an example implementation to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.
- the term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure.
- the term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media.
- the present disclosure may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure.
- a machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer).
- a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Abstract
Description
- The embodiments of the disclosure relate generally to platform configuration registers, and, in particular to extending a platform configuration register with a known value.
- Electronic device use continues to grow, and conservative estimates suggest that tens of billions of electronic devices are in active use. Many of these devices are mobile and web-enabled. Similarly, the growth of malicious code, viruses, cyber espionage, malware, etc., tracks the growth of electronic device use. Great time and effort is expended to certify that the integrity of the software (e.g., operating system) is intact in these electronic devices. In other words, determining that software running on the electronic device has not been illegitimately modified is an important step in creating a trusted computing environment.
- The ability to protect the software of the electronic device is limited by the manner in which trust is created or “rooted” in the electronic device. The Trusted Computing Group (“TCG”) develops open standards and specifications for trusted computing. According to the specifications, trust within a given data processing system may be based on a trusted platform module (“TPM”).
- TPM techniques can be implemented in a variety of platforms including servers, desktops, notebooks, or handheld computing devices. The purpose of the TPM is to provide computer identity and secure services related to transactions, protecting user data, and other special functions. Current trusted computing mechanisms, which root the integrity of a platform, do so by “extending” a platform configuration register with a cryptographic hash representing the binary of the software. If, however, the binary of the software changes, which is prone to happen, then the cryptographic hash also changes. When any update is made to a trusted binary, an update should also be made to the contents of the platform configuration register.
- Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, and can be more fully understood with reference to the following detailed description when considered in connection with the figures in which:
-
FIG. 1 illustrates one embodiment of a computing system, in accordance with various implementations; -
FIG. 2 is a block diagram illustrating one embodiment of a trusted platform module; -
FIG. 3 illustrates a flow diagram of one embodiment of a method for extending a platform configuration register value with a known value; and -
FIG. 4 is a block diagram of an example computer system that may perform one or more of the operations described herein. - Described herein are methods and systems for establishing a chain of trust by extending platform configuration registers with known values. A chain of trust can be established by validating hardware components and software components in a computing system to ensure that only trusted software and hardware can be used. A computing system, under implementations of this disclosure, can include a trusted platform module. The trusted platform module can be a microprocessor that includes a data store (e.g., platform configuration registers) to store data when the computing system validates the integrity of the computing system components (e.g., hardware components, software components). According to various implementations, when the computing system validates the signature of a component, the trusted platform module extends a platform configuration register with a known value (e.g., public key associated with the signature of the component) instead of extending the platform configuration register with a hash value that is based on the binary of the component. A known value represents a value that is known or available to the public. An example of a known value can include, and is not limited to, a public key in public-key cryptography systems. A binary hereinafter refers to a type of binary file that contains machine code for a component, which the computing system can execute. Extending the platform configuration registers with a known value (e.g., public key), instead of extending the platform configuration registers with hash values that are based on the binary of the components, beneficially, allows the contents of the binary for a component to change without having to update the contents of the platform configuration registers.
-
FIG. 1 illustrates one implementation of acomputing system 100 having a trusted platform architecture. Thecomputing system 100 may be configured with various hardware components (e.g., base hardware platform 106) to support the execution ofsoftware components 101 that may include akernel 102 andapplications 104. Thebase hardware platform 106 may include aprocessor 108,memory 110, astorage disk 112, apower supply 114, various add-oncards 116, and a trusted platform module 118. The trusted platform module 118 can include platform configuration registers 124 to store data. One implementation of the trusted platform module is described in greater detail below in conjunction withFIG. 2 . Although not shown, multiple interfaces can be used to couple the devices of thebase hardware platform 106 to each other and other components of thecomputing system 100. - The hardware components in the
base hardware platform 106 and thesoftware components 101 may each be associated with binary, and may have a signature that is attached or supplied with the binary. The signature may have been created, for example, by hashing the binary and encrypting the hash of the binary. Thecomputing system 100 can take an integrity measurement of the binary for a component and can verify if the signature that is associated with the binary is valid. Thecomputing system 100 can use an asymmetric key signature algorithm to determine if the signature that is associated with the binary is valid. An example of an integrity measurement can include, and is not limited to, hash sums of files or data that are associated with the binary of the component. - The trusted platform module 118 can extend a platform configuration register 124 with a
known value 126 based on the determination made by thecomputing system 100 of whether a signature that associated with the binary of a component is valid. An example of a knownvalue 126 can include, and is not limited to, a public key. The term “public key” refers to a public-key cryptography system that utilizes two separate keys, a private key and a public key. The private key and the public key are mathematically linked. One key may lock data or encrypt the data, and the other key may unlock data or decrypt the data. For example, a private key may have been used to encrypt a hash of a binary of a component to create a signature for the binary. The public key that is associated with the private key may be used to decrypt the signature. The public key, as the name implies, is published. Throughout this disclosure, a trusted platform module 118 collectively represents any kind of trusted platform module, including a trusted platform module 118 implemented using software, firmware, hardware, or a combination thereof. - The
computing system 100 can check, for the various components, whether a signature that is associated with the binary of a particular component is valid. Each time thecomputer system 100 makes a determination of whether a signature is valid, the trusted platform module 118 can extend the platform configuration register 124 with a knownvalue 126. One implementation of the trusted platform module extending the platform configuration register with a known value is described in greater detail below in conjunction withFIG. 3 . - For example, the
base hardware platform 106 may be a motherboard having firmware (e.g., power-on self-test basic input/output systems, or “POST BIOS”), that executes before the software components 101 (e.g.,kernel 102, operating system, or applications 104) initialize. For example, the firmware may execute before a boot loader executes. A boot loader is a computer program that loads the main operating system or runtime environment for the computer after completion of the self-tests. In another example, the boot loader may execute before the kernel of the operating system executes, and the kernel may execute before any binary forapplications 104 in the userspace of the operating system are executed. When thecomputing system 100 receives power from thepower supply 114, the firmware may take an integrity measurement for the binary of the boot loader and may determine whether the signature that is associated with the binary of the boot loader is valid. If the firmware determines that the signature that is associated with the boot loader is valid, the trusted platform module 118 can extend a platform configuration register 124 with a known value 126 (e.g., public key that is associated with the boot loader). - The
computing system 100 may then execute the boot loader. The boot loader may take an integrity measurement for the binary of the kernel and may determine whether the signature that is associated with the binary of the kernel is valid. If the boot loader determines that the signature that is associated with the kernel is valid, the trusted platform module 118 can extend the current value in the platform configuration register 124 using a known value 126 (e.g., public key) that is associated with the kernel. Thecomputing system 100 can iterate through checking the integrity of the components and the validating the signatures that are associated with the binaries of the components. The number of iterations can be based on the number of components. -
FIG. 2 is a block diagram illustrating one implementation of the trustedplatform module 200. Theclient distribution module 300 may correspond to a client distribution module 138 in aclient machine 102 ofFIG. 1 . The trustedplatform module 200 can extend the value of a platform configuration register 224 with a knownvalue 226. In one implementation, the trustedplatform module 200 includes components specified by the Trusted Computing Group (“TCG”) specification. The trustedplatform module 200 can be implemented in software and/or hardware that is compatible with a trusted platform module specification set forth, for example, by the TCG standard body The components can include, for example, acryptographic co-processor 202, akey generator 204, arandom number generator 206, a SHA-1engine 208, an opt-incomponent 210, avolatile storage 214, platform configuration registers 224, and one ormore data stores 212, 215. Note that in alternative implementations, the functionality of one or more of the components can be combined or divided. - The
cryptographic co-processor 202 can perform cryptographic operations within the trustedplatform module 200. Thekey generator 204 can create symmetric keys and RSA asymmetric cryptographic key pairs. Therandom number generator 206 can provide randomness for the computation of various values such as keys or other values. The opt-incomponent 210 can maintain the state of persistent and volatile flags and can enforce semantics associated with those flags such that the trustedplatform module 200 can be enabled and disabled. The data store 215 can store persistent identity and state information that is associated with the trustedplatform module 200. The data store 215 can be non-volatile memory. - The trusted
platform module 200 can include a set of platform configuration registers 244. In one implementation, the trustedplatform module 200 includes at least sixteen platform configuration registers 224. In one implementation, the platform configuration registers 224 are each twenty bytes. The platform configuration registers 224 can reside in volatile and/or non-volatile memory. A subset of the set of platform configuration registers 244 can be designated for hardware components and another subset of the set of platform configuration registers 244 can be designated for software components. For example, PCR-1 may be used for the motherboard manufacturer, PCR-2 may be used for the processor, PCR-3 may be used for the firmware, etc. In one implementation, registers 0-7 are reserved for trusted platform module use and registers 8-15 are available for operating system and application use. - The platform configuration registers 224 values can be temporal and can be reset at computing system reboot. In one embodiment, the values that are stored in one of the platform configuration registers 224 are “extendable,” in that the value for a particular platform configuration register is based on an aggregate of data. For example, the current value that is stored in one the platform configuration registers 224 (e.g., PCR-1) may be changed by hashing the current value in the platform configuration register 224 (e.g., PCR-1) with a new value to result in the “extended value” for the platform configuration registers 224 (e.g., PCR-1). In one implementation, the current value in a platform configuration register 224 is changed, for example, by a component (e.g., firmware, boot loader, kernel, application, etc.) sending an “Extend( )” operation to the trusted
platform module 200. - The trusted
platform module 200 can update the current value in a platform configuration register 224 using a knownvalue 226. In one implementation, the knownvalue value value value 226 that should be stored in the platform configuration register 224 can be based on a determination of whether the signature that is associated with binary of a component is valid. For example, if signature is valid, the trustedplatform module 200 can use a public key that is associated with the component as the knownvalue 226. In another example, if the signature is not valid, the trustedplatform module 200 can use a null value as the knownvalue 226. One implementation of the trusted platform module extending a platform configuration register is described in greater detail below in conjunction withFIG. 3 . - In one implementation, the known
value platform module 200 stores the knownvalues 213, for example, in a data store 212 (e.g., non-volatile memory) in the trustedplatform module 200. In another implementation, the knownvalues - When a platform configuration register 224 is to be updated, the SHA-1
engine 208 can implement the SHA-1 hash algorithm to calculate the new value for the platform configuration register 224 by hashing the current value in the platform configuration register 224 with a given value. For example, the current value that is stored in PCR-1 may be changed by the SHA-1engine 208 hashing the current value in PCR-1 with a new value (e.g., public key) to result in the “extended value” for PCR-1. -
FIG. 3 illustrates a flow diagram of one embodiment of amethod 300 for extending a platform configuration register value with a known value. The method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, at least a portion of the method is performed by a trusted platform module (e.g., trustedplatform module 200 ofFIG. 1 ) in a computing system (e.g.,computing system 100 inFIG. 1 ). In one embodiment, at least a portion of the method is performed by hardware components (e.g., components invase hardware platform 106 inFIG. 1 ) and/or software components (e.g.,software components 101 inFIG. 1 ) in a computing system (e.g.,computing system 100 inFIG. 1 ). - At
block 301, the computing system calculates a hash value of binary of a component of the computing system. For example, the computing system may identify a system start event. For example, the computing system may be initializing after a power down or reset/restart event, and the firmware of the motherboard of the computing system may be the first component to launch after power-up. The firmware may calculate a hash (e.g., cryptographic hash) of the binary of the boot loader. A cryptographic hash is a hash function that returns a fixed-size bit string as a result. In one embodiment, the cryptographic hash function is SHA-1 Alternatively, any suitable cryptographic hash function may be used to calculate the hash for the binary. - At
block 303, The computing system retrieves a public key that corresponds to the component from a storage area (e.g., non-volatile storage of the trustedplatform module 200 inFIG. 2 ). Atblock 305, the computing system retrieves the digital signature that is associated with the binary of the component. The digital signature of the binary of the component may be originally “signed” by a platform vendor using the private key of the platform vendor. The platform vendor may have hashed the binary, and may have then encrypted the hash of the binary using the private key to create the digital signature for the binary. In one implementation, the digital signature for the component is stored in a data store in the computing system, and the digital signature is retrieved from the data store atblock 305. - At
block 307, the computing system determines whether the signature that is associated with the binary of the component is valid using the public key. The computing system can use an asymmetric key signature algorithm to determine whether the signature is valid. If the signature is valid (block 309), the trusted platform module in the computing system, extends a platform configuration register in the trusted platform module using a known value atblock 311. In one implementation, the known value used when the signature is valid is the public key that is associated with the component. and sends an extend operation request to the trusted platform module. In one implementation, the trusted platform module receives an extend operation request from a component. The extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, public key) that the trusted platform module should use to extend the current value of the platform configuration register. - If the signature is not valid (block 309), the trusted platform module in the computing system, extends a platform configuration register in the trusted platform module using another known value at
block 313. In one implementation, the known value used when the signature is not valid is a null value. In another implementation, the known value used when the signature is not valid is the hash value that is generated by hashing the binary of the component. The known value used when the signature is not valid can be another known value that is different from the known value that is used when the signature is valid. In one implementation, the trusted platform module receives an extend operation request from a component. The extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, null value, hash value) that the trusted platform module should use to extend the current value of the platform configuration register. - For example, at
block 301, the firmware calculates a hash value of the binary of the boot loader component using a SHA-1 hash function. Atblock 303, the firmware retrieves the public key that is associated with the boot loader component from a data store in the computing system. Atblock 305, the firmware retrieves the digital signature for the boot loader from a data store in the computing system. The digital signature may have been crated by the component vendor using the SHA-1 hash algorithm. Atblock 307, the firmware decrypts the digital signature for the boot loader using the public key for boot loader to generate a hash value from the decrypted signature. Atblock 307, the firmware compares the hash value that was identified from decrypting the digital signature using the public key with the hash value that was created by the firmware using a SHA-1 hashing function on the binary of the boot loader, for example, fromblock 301. - If the hash values match, the firmware determines that the signature is valid at
block 309, and sends an extend operation request to the trusted platform module. The extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, public key) that the trusted platform module should use to extend the current value of the platform configuration register. If the hash values do not match, the firmware determines that the signature is not valid atblock 309, and sends an extend operation request to the trusted platform module. The extend operation request can include an identifier of the platform configuration register that is to be extended and can include the known value (e.g, null value, hash value) that the trusted platform module should use to extend the current value of the platform configuration register. - In one implementation, the SHA-1 engine (e.g., SHA-1
engine 208 inFIG. 2 ) in the trusted platform module can implement the SHA-1 hash algorithm to calculate the new value for updating the platform configuration register by hashing the current value in the platform configuration register with the known value. For example, if the signature is valid, the current value that is stored in PCR-1 may be changed by the SHA-1 engine hashing the current value in PCR-1 with the known value (e.g., public key) to generate a new value for PCR-1. The trusted platform module can replace the current value for the platform configuration register with the new value. - In one implementation, the computing system iterates
method 300 to check the integrity of the components and to validate the signatures that are associated with the binaries of the components. The number of iterations can be based on the number of components. For example, the computing system may continue the boot up sequence by measuring the next component in the boot up sequence. For instance, the firmware may perform at least a portion ofmethod 300 with respect to a boot loader, then the boot loader may perform at least a portion of themethod 300 with respect to the kernel of the operating system, and the kernel may perform at least a portion of themethod 300 with respect to a binary of an application. - The stored values in the platform configuration registers can be used to provide state information to another system and/or sub-system. For example, the computing system may be a mobile user device. The mobile user device has been requested to provide its trusted platform module state information to a cell phone tower before the tower before the cellular tower will allow the mobile user device to access to the cellular network. In another example, the computing system may reside in a data center. The computer system may be requested to provide its trusted platform module state information to a server before the computing system is given access to the rest of the network. In another example, the computing system is requested by a disk reader to provide its trusted platform module state information to the disk reader before an encrypted disk is unlocked.
-
FIG. 4 illustrates an example machine of acomputer system 400 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and/or the Internet. The machine may operate in the capacity of a server or a client machine in client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. - The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
- The
example computer system 400 includes aprocessing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.), and adata storage device 418, which communicate with each other via a bus 430. -
Processing device 402 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 1202 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Theprocessing device 402 is configured to executeinstructions 422 for performing the operations and steps discussed herein. - The
computer system 400 may further include anetwork interface device 408. Thecomputer system 400 also may include a video display unit 410 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 412 (e.g., a keyboard), a cursor control device 414 (e.g., a mouse), and a signal generation device 416 (e.g., a speaker). - The
data storage device 418 may include a machine-readable storage medium 428 (also known as a computer-readable medium) on which is stored one or more sets of instructions orsoftware 422 embodying any one or more of the methodologies or functions described herein. Theinstructions 422 may also reside, completely or at least partially, within themain memory 404 and/or within theprocessing device 402 during execution thereof by thecomputer system 400, themain memory 404 and theprocessing device 402 also constituting machine-readable storage media. - In one implementation, the
computer system 400 include a trustedplatform module 200 that is coupled to theprocess device 402,main memory 404,static memory 406,network interface device 408,video display 410, alpha-numeric input device 412,cursor control device 414,signature generation device 416, anddata store device 418 via the bus 430. In one implementation, theinstructions 422 include instructions for a trusted platform module (e.g., trustedplatform module 200 ofFIG. 1 ) and/or a software library containing methods that call modules in a trusted platform module. While the machine-readable storage medium 428 is shown in an example implementation to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media. - Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
- It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “calculating” or “determining” or “extending” or “retrieving” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage devices.
- The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
- The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.
- The present disclosure may be provided as a computer program product, or software, that may include a machine-readable medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.
- In the foregoing specification, implementations of the disclosure have been described with reference to specific example implementations thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of implementations of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/756,194 US9465943B2 (en) | 2013-01-31 | 2013-01-31 | Extension of a platform configuration register with a known value |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/756,194 US9465943B2 (en) | 2013-01-31 | 2013-01-31 | Extension of a platform configuration register with a known value |
Publications (2)
Publication Number | Publication Date |
---|---|
US20140215202A1 true US20140215202A1 (en) | 2014-07-31 |
US9465943B2 US9465943B2 (en) | 2016-10-11 |
Family
ID=51224355
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/756,194 Active 2033-10-23 US9465943B2 (en) | 2013-01-31 | 2013-01-31 | Extension of a platform configuration register with a known value |
Country Status (1)
Country | Link |
---|---|
US (1) | US9465943B2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130191643A1 (en) * | 2012-01-25 | 2013-07-25 | Fujitsu Limited | Establishing a chain of trust within a virtual machine |
US20170093800A1 (en) * | 2015-09-26 | 2017-03-30 | Intel Corporation | Data protection keys |
US20170308706A1 (en) * | 2016-04-20 | 2017-10-26 | Sophos Limited | Boot security |
WO2018027190A1 (en) | 2016-08-04 | 2018-02-08 | Data I/O Corporation | Counterfeit prevention |
US10305893B2 (en) * | 2013-12-27 | 2019-05-28 | Trapezoid, Inc. | System and method for hardware-based trust control management |
US10356116B2 (en) * | 2016-04-07 | 2019-07-16 | IDfusion, LLC | Identity based behavior measurement architecture |
US20190245686A1 (en) * | 2018-02-02 | 2019-08-08 | Microsoft Technology Licensing, Llc | Secure crypto system attributes |
US11595189B2 (en) | 2020-10-27 | 2023-02-28 | Microsoft Technology Licensing, Llc | Secure key exchange using key-associated attributes |
US20230066210A1 (en) * | 2012-03-30 | 2023-03-02 | Irdeto B.V. | Method and system for preventing and detecting security threats |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104951316B (en) * | 2014-03-25 | 2018-09-21 | 华为技术有限公司 | A kind of credible startup method and apparatus of kernel |
US11138315B2 (en) | 2018-01-17 | 2021-10-05 | Hewlett Packard Enterprise Development Lp | Data structure measurement comparison |
US11165766B2 (en) | 2018-08-21 | 2021-11-02 | International Business Machines Corporation | Implementing authentication protocol for merging multiple server nodes with trusted platform modules utilizing provisioned node certificates to support concurrent node add and remove |
US11206141B2 (en) | 2018-09-21 | 2021-12-21 | International Business Machines Corporation | Merging multiple compute nodes with trusted platform modules utilizing provisioned node certificates |
US10885197B2 (en) | 2018-09-21 | 2021-01-05 | International Business Machines Corporation | Merging multiple compute nodes with trusted platform modules utilizing authentication protocol with active trusted platform module provisioning |
JP2024502548A (en) * | 2020-12-31 | 2024-01-22 | アボット ダイアベティス ケア インコーポレイテッド | System embedded in medical monitoring system |
Citations (7)
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 |
US20060155988A1 (en) * | 2005-01-07 | 2006-07-13 | Microsoft Corporation | Systems and methods for securely booting a computer with a trusted processing module |
US20060236122A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Secure boot |
US7191464B2 (en) * | 2001-10-16 | 2007-03-13 | Lenovo Pte. Ltd. | Method and system for tracking a secure boot in a trusted computing environment |
US7908483B2 (en) * | 2005-06-30 | 2011-03-15 | Intel Corporation | Method and apparatus for binding TPM keys to execution entities |
US20120102313A1 (en) * | 2009-07-01 | 2012-04-26 | Nicolson Kenneth Alexander | Secure boot method and secure boot apparatus |
US8694762B2 (en) * | 2011-05-18 | 2014-04-08 | Nokia Corporation | Secure boot with trusted computing group platform registers |
-
2013
- 2013-01-31 US US13/756,194 patent/US9465943B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7191464B2 (en) * | 2001-10-16 | 2007-03-13 | Lenovo Pte. Ltd. | Method and system for tracking a secure boot in a trusted computing environment |
US20050138393A1 (en) * | 2003-12-22 | 2005-06-23 | Challener David C. | Determining user security level using trusted hardware device |
US20060155988A1 (en) * | 2005-01-07 | 2006-07-13 | Microsoft Corporation | Systems and methods for securely booting a computer with a trusted processing module |
US7725703B2 (en) * | 2005-01-07 | 2010-05-25 | Microsoft Corporation | Systems and methods for securely booting a computer with a trusted processing module |
US20060236122A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Secure boot |
US7908483B2 (en) * | 2005-06-30 | 2011-03-15 | Intel Corporation | Method and apparatus for binding TPM keys to execution entities |
US20120102313A1 (en) * | 2009-07-01 | 2012-04-26 | Nicolson Kenneth Alexander | Secure boot method and secure boot apparatus |
US8694762B2 (en) * | 2011-05-18 | 2014-04-08 | Nokia Corporation | Secure boot with trusted computing group platform registers |
Non-Patent Citations (1)
Title |
---|
Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael K. Reiter, and Arvind Seshadri, Minimal TCB Code Execution * |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130191643A1 (en) * | 2012-01-25 | 2013-07-25 | Fujitsu Limited | Establishing a chain of trust within a virtual machine |
US9992024B2 (en) * | 2012-01-25 | 2018-06-05 | Fujitsu Limited | Establishing a chain of trust within a virtual machine |
US20230066210A1 (en) * | 2012-03-30 | 2023-03-02 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US10305893B2 (en) * | 2013-12-27 | 2019-05-28 | Trapezoid, Inc. | System and method for hardware-based trust control management |
US20170093800A1 (en) * | 2015-09-26 | 2017-03-30 | Intel Corporation | Data protection keys |
US10693851B2 (en) | 2015-09-26 | 2020-06-23 | Intel Corporation | Data protection keys |
US10057223B2 (en) * | 2015-09-26 | 2018-08-21 | Intel Corporation | Data protection keys |
US10356116B2 (en) * | 2016-04-07 | 2019-07-16 | IDfusion, LLC | Identity based behavior measurement architecture |
US10958678B2 (en) | 2016-04-07 | 2021-03-23 | IDfusion, LLC | Identity based behavior measurement architecture |
US10528739B2 (en) * | 2016-04-20 | 2020-01-07 | Sophos Limited | Boot security |
US20170308704A1 (en) * | 2016-04-20 | 2017-10-26 | Sophos Limited | Boot security |
US10762209B2 (en) * | 2016-04-20 | 2020-09-01 | Sophos Limited | Boot security |
US20170308706A1 (en) * | 2016-04-20 | 2017-10-26 | Sophos Limited | Boot security |
WO2018027190A1 (en) | 2016-08-04 | 2018-02-08 | Data I/O Corporation | Counterfeit prevention |
EP3494508A4 (en) * | 2016-08-04 | 2020-03-11 | Data I/O Corporation | Counterfeit prevention |
US20190245686A1 (en) * | 2018-02-02 | 2019-08-08 | Microsoft Technology Licensing, Llc | Secure crypto system attributes |
US11184164B2 (en) * | 2018-02-02 | 2021-11-23 | Microsoft Technology Licensing, Llc | Secure crypto system attributes |
US11595189B2 (en) | 2020-10-27 | 2023-02-28 | Microsoft Technology Licensing, Llc | Secure key exchange using key-associated attributes |
Also Published As
Publication number | Publication date |
---|---|
US9465943B2 (en) | 2016-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9465943B2 (en) | Extension of a platform configuration register with a known value | |
US20200272739A1 (en) | Performing an action based on a pre-boot measurement of a firmware image | |
US11921860B2 (en) | Rollback resistant security | |
CN109313690B (en) | Self-contained encrypted boot policy verification | |
Zhao et al. | Providing root of trust for ARM TrustZone using on-chip SRAM | |
US8151262B2 (en) | System and method for reporting the trusted state of a virtual machine | |
US8914627B2 (en) | Method for generating a secured boot image including an update boot loader for a secured update of the version information | |
US8732445B2 (en) | Information processing device, information processing method, information processing program, and integrated circuit | |
US9405912B2 (en) | Hardware rooted attestation | |
US10943013B2 (en) | Maintaining keys for trusted boot code | |
CN100447736C (en) | Firmware interface runtime environment protection field | |
US8479017B2 (en) | System and method for N-ary locality in a security co-processor | |
BR112014031586B1 (en) | SYSTEM TO EMULATE A RELIABLE EXECUTION ENVIRONMENT AND COMPUTER STORAGE MEDIA | |
CN107480535A (en) | The reliable hardware layer design method and device of a kind of two-way server | |
KR20180007922A (en) | User apparatus based on trusted platform module and booting method using the same | |
JP6769999B2 (en) | Secure computing environment | |
US20230325509A1 (en) | Trust chain preservation for remote attestation | |
US20220284088A1 (en) | Authentication of write requests | |
Dongliang et al. | TrustVP: construction and evolution of trusted chain on virtualization computing platform | |
US20180322291A1 (en) | Operational verification | |
Kushwaha | A trusted bootstrapping scheme using USB key based on UEFI | |
KR20230121382A (en) | Semiconductor chip and software security execution method using thereof | |
CN116938465A (en) | Gateway equipment starting method and device, electronic equipment and storage medium | |
CN118211242A (en) | Security architecture system, method for realizing secure and trusted starting and computing device | |
CN118211225A (en) | Security architecture system, method for realizing secure and trusted starting and computing device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: RED HAT, INC., NORTH CAROLINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PARIS, ERIC L.;WALSH, DANIEL J.;REEL/FRAME:029735/0760 Effective date: 20130131 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |