Abstract
Embodiments of the present invention are directed to an improved system and method of producing, recording and reporting boot integrity measurements of an Internet of Things (“IoT”) computing device to resource (such as an on-chip software module, an external software module, a printer, a network router, or a server), so the resource can confirm that the IoT computing device can be trusted before access to the resource is granted. Embodiments provide a new and less expensive architecture for reliably collecting and relaying device state information to support trust-sensitive applications. Embodiments leverage crypto-acceleration modules found on many existing microprocessors and microcontroller-based IoT devices, while introducing little additional overhead or additional circuitry. Embodiments provide a Root of Trust module comprising integrated internal control logic that functions as a secure on-chip wrapper for cryptographic primitive modules, which provide secure storage and reporting of the host's platform integrity measurements.
Claims
1. A computing hardware Root of Trust module, comprising: integrated internal control logic; a Provisioned Seed (PS), accessible only by the internal control logic; a one-way hash module operable only by the internal control logic, said one-way hash module producing a hash digest from a hash input message; a signing module accessible only by the internal control logic, said signing module producing a signature of a signing input message using a provided signing key; a Platform Configuration Register (PCR) updatable only by the internal control logic, said PCR initialized to a provisioned default value; an Extend module comprising extend circuitry to perform an extend operation under control of the internal control logic in response to an extend request received from an on-chip computing resource, said extend circuitry invoking the one-way hash module to cryptographically blend a current contents of the PCR concatenated with a message digest provided in the extend request, and said extend circuitry then storing a result of the cryptographic blend operation back into the PCR; and a Quote module comprising quote circuitry to perform a quote operation under control of the internal control logic in response to a quote request received from the on-chip computing resource to create a digital signature using the signing module with the PS as the basis for the provided signing key, and a hash of the concatenation of a nonce received in the quote request and the current contents of the PCR as the signing input message.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) So that the above recited features of the present invention can be understood in detail, a more particular description of the invention may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
(2) FIG. 1 is a block diagram illustrating a traditional trusted platform in accordance with the prior art.
(3) FIG. 2 is a block diagram illustrating an exemplary embodiment of a conventional hash function, in accordance with the present invention.
(4) FIG. 3 is a block diagram illustrating an alternative encrypt-based hash function that repurposes an existing block cipher as a replacement to a compression function, according to embodiments of the present invention.
(5) FIG. 4 is a block diagram illustrating a traditional TCG implementation of an Extend operation, in accordance with the prior art.
(6) FIG. 5 is a block diagram illustrating an optimized Extend operation, according to embodiments of the present invention.
(7) FIG. 6 is a block diagram illustrating a conventional quote mechanism, in accordance with the prior art.
(8) FIG. 7 is a block diagram illustrating an optimized Quote, according to embodiments of the present invention.
(9) FIG. 8 is a block diagram illustrating the components of a Root of Trust implementation according to embodiments of the present invention.
(10) FIG. 9 is a high-level block diagram illustrating a traditional TPM implementation for purposes of comparing the prior art to embodiments of the present invention.
(11) FIG. 10 is a high-level block diagram illustrating an implementation of a host chip with an on-chip root of trust, for purposes of comparing the prior art to embodiments of the present invention.
DESCRIPTION OF THE EMBODIMENTS
(12) Embodiments of the present invention will be described with reference to the accompanying drawings, wherein like parts are designated by like reference numerals throughout, and wherein the leftmost digit of each reference number refers to the drawing number of the figure in which the referenced part first appears.
(13) Architecture
(14) The cryptographic primitives found in the TPM 122 to support the RTS's 150 Extend and the RTR's 170 Quote operations (see FIG. 1) are hash (e.g., SHA or Secure Hash Algorithm) and public key (asymmetric) ciphers that produce a digital signature (e.g., RSA or Rivest-Shamir-Adleman). Embodiments of the present invention provision the RTS 150 and RTR 170 components of TPM 122 as integral, not supplemental, components to a host, such as host 121. Embodiments may use symmetric or asymmetric cryptography and may make on-chip crypto accelerators function in both general purpose and root of trust modes. Embodiments may further use block ciphers as the basis for hashing and signing. The purpose for doing so is to take advantage of integrated ciphers (e.g., AES) already prevalent in the market (e.g., ST STM32L081xx, TI MSP430 and the Atmel XMEGA) and to be less burdensome for manufacturers.
(15) The logic that drives the cryptographic primitives (e.g., hash and encrypt, a.k.a. “engines”) to function in either general purpose or root of trust modes can be thought of as a “wrapper.” Such a wrapper would function as a trusted, special-purpose interface to the engines, and would have virtually no disruption to their core logic. Thus, as manufacturers dedicate silicon to these accelerators, they could find that a fractional increase in logic could provide an important level of trust for very little cost. This approach strikes a balance between overhead and robustness and would suit resource constrained IoT devices well.
(16) Supporting the Extend Operation
(17) While a TPM 122 may support multiple PCRs 151 and multiple hashing algorithms, embodiments of the present invention will use a single PCR (for example, PCR 830 in FIG. 8) and a single hashing algorithm. Note that the PCR 830 is to be protected from arbitrary writes and may only be updated with Extend (see Extend 813 in FIG. 8). The initial value of PCR 830 is 0 (or some other provisioned value) and may be reset only upon receiving a full platform reset signal.
(18) As is known in the art, a hash function is any function that can be used to map data of arbitrary size to data of (typically smaller) fixed size. The values returned by a hash function are called hashes, hash values, hash codes, or (more commonly) digests. A required property of secure hashes is that they be “one-way.” If a hash function H consumes input A to produce B, H is considered one-way if it is infeasible to create an inverse function that consumes B to produce A.
(19) FIG. 2 is a block diagram illustrating an exemplary embodiment of a conventional hash function 200, in accordance with the present invention. The input to hash function 200 is a message 203 and an initializing value 201. The output of hash function 200 is a digest 206. To produce digest 206, a compression function H 204 repeatedly or iteratively processes fragments of message 203 into a smaller compressed portion 205, until the entire message 203 has been compressed into digest 206. In each iteration, compression function H 204 accepts two inputs: the next fragment of message 203 and an intermediate digest V 202, which is the result of the immediately preceding iteration of H 204 (i.e., the previously compressed portion 205). An example of a conventional hash function 200 is SHA-256. In the case of SHA-256, the size of each fragment of message 203 is 512 bits and the size of V 202 is 256 bits. The result of compressing those 768 bits is 256 bits, matching the size of V 202. When all fragments of message 203 have been processed along with any additional padding and termination, V 202 is returned as message digest 206, which is a digest or a hash of message 203. The initialization value 201 and termination added to 203 for SHA-256 is specified by NIST's FIPS 180-4, Secure Hash Standard.
(20) FIG. 3 is a block diagram illustrating an alternative encrypt-based hash function 300 that repurposes a block cipher E 304 as a replacement to compression function H 204 (shown in FIG. 2), according to embodiments of the present invention. The purpose of doing so would allow consolidation of logic for hashing and encrypting, thereby reducing on-chip manufacturing demands. From the perspective of inputs and outputs, encrypt-based hash function 300 is identical to conventional hash function 200. The difference between the two hash functions is: conventional hash function 200 uses a conventional compression function such as found in SHA-256, where encrypt-based hash function 300 uses a Davies-Meyer compression algorithm, V.sub.i=E.sub.Mi(V.sub.i-1)⊕V.sub.i-1, where M.sub.i corresponds to the ith block of message M (M is message 303), V.sub.i-1 is the result of the previous iteration, E.sub.Mi(V.sub.i-1) is the output of an encrypt function E 304 encrypting V.sub.i-1 with key Mi, and ⊕ is the exclusive-or operator XOR. V.sub.0 is set to the initialization value 301.
(21) Continuing to refer to FIG. 3, the input to hash function 300 is a message 303 (corresponding to M in the equation above) and an initializing value 301. The output of hash function 300 is digest 306. To produce digest 306, encrypt function E 304 repeatedly or iteratively encrypts V 302 using a portion of message 303 as key to produce ciphertext 305, and XORing that with V 302 until the entire message 303 has been processed into digest 306. In each iteration, encrypt function E 304 accepts two inputs: the next fragment of message 303 and V 302, which is the result of the immediately preceding iteration of E 304 (i.e., the previously compressed cyphertext 305). The compressed cyphertext 305 is fed to XOR gate 307 along with the original V 302 whose result is then used to overwrite V 302. When all fragments of message 303 have been processed, V 302 is returned as message digest 306, which is a hash of message 303.
(22) Any hash approach—including conventional hash function 200 or encrypt-based hash function 300 utilizing a Davies-Meyer compression algorithm—can be represented at a higher level simply as a HASH “engine” that can be initialized (with some algorithm-dependent value), consume multiple message fragments, and produce a digest as output.
(23) FIG. 4 is a block diagram illustrating a traditional TCG implementation of an Extend operation, in accordance with the prior art. The TCG's implementation of Extend 400 implements the following iterative algorithm: DoD.sub.i=H(DoD.sub.i-1∥D.sub.i), where each DoD.sub.i corresponds to the i.sup.th value of one of the PCRs 151 shown in FIG. 1, H is a HASH engine such as described in FIG. 2 (H 204) or 3 (H 304), and where each digest D.sub.i 403 corresponds to one of the digests 101, 102, shown in FIG. 1. DoD.sub.0 is specified by the TCG for specific PCRs and is typically either all zeros 408 or all ones. In operation, the hash engine 401 is initialized with Init value 402 and will process as its message fragment inputs DoD.sub.i-1 404, D.sub.i 403, and any padding and termination shown as PAD 406, as required by the specific hash algorithm operating within HASH 401. The result 405 of Extend 400 is written back to the PCR 407 (PCR 151).
(24) FIG. 5 is a block diagram illustrating an optimized Extend 500, according to embodiments of the present invention. The purpose of this optimization is to provide a slight improvement over TCG Extend 400 to streamline the concatenation of digests 503, resulting in more efficient control logic. Extend 500 does not initialize and pad for every D.sub.i. Instead, it initializes the PCR 504 with the Hash 501 algorithm's initialization value 508 and defers message termination padding (if needed, not shown) to when PCR 504 is read for other uses. Note that some padding of D.sub.i 503 may be required if D.sub.i 503 is smaller than the message fragment input size. The hash engine 501 compresses its initialization value DoD.sub.i 502 from PCR 504 with D.sub.i. The result 505 is written back to the PCR 504.
(25) FIG. 6 is a block diagram illustrating a conventional quote mechanism 600, in accordance with the prior art. As described in the Background section above, the conventional Quote mechanism for TPM is shown in FIG. 6. The nonce 603, provided by an external challenger, is hashed with the PCR 604, along with any necessary padding, by the hash engine 601. Instead of updating the PCR 604, the resulting digest 605 is fed as plaintext to an encryption engine E 606. The digest 605 is encrypted with UDS 607. The term “UDS” or Unique Device Secret, in the context of FIG. 6 and embodiments of the present invention, refers to a value either obtained directly or derived from a provisioned secret on the host. The resulting ciphertext is digital signature SIG 608.
(26) FIG. 7 is a block diagram illustrating an optimized Quote 700, according to embodiments of the present invention. To optimize the quoting process, hash engine 601 (in FIG. 6) could use the same encryption logic provided by encrypt-based hash function 300 (FIG. 3). This optimization also benefits from Optimized Extend 500. First, V 702 is initialized with PCR 701 and compressed by E 704 with the nonce 703. The result 705 and the initial V 702 are XORed at 707. That result updates V 702 (but not the PCR 701). Then, V 702 is encrypted by E 704 with the UDS 708 as key. The result is digital signature SIG 709.
(27) FIG. 8 is a block diagram of an On-Chip Root of Trust 805, according to embodiments of the present invention. It depicts the components and their interaction as needed to implement an RTS and RTR to support measurement and attestation on the same chip (or die) containing the host processor and its RTM. It is unique in that the same logic a manufacturer might incorporate for general-purpose crypto acceleration, such as Cipher 850, can also be used to implement a root of trust. Control Logic 810 is a state machine that maintains exclusive access and control over all resources within the On-Chip Root of Trust 805. It is also responsible for all interactions (for example, Reply 860 and Request 870) through internal bus 880 with other chip components, shown as On-Chip Resource 890, such as a primary microcontroller. The Root of Trust 805 resources managed by Control Logic 810 are UDS 820 (from UDS 607 or UDS 708), PCR 830 (from PCR 407, PCR 504, PCR 604 or PCR 701), Hash 840 (from Hash 401, Hash 501, or Hash 601) and Cipher 850 (from E 606 or E 704). If Hash 840 is excluded, then Cipher 850 would be controlled by Control Logic 810 to affect a hash function as described in FIG. 3 and used in Hash 401, Hash 501, Hash 601, and E 704.
(28) UDS 820 is read and used exclusively within the On-Chip Root of Trust 805 as required by Control Logic 810. While provisioning of UDS 820 is outside the scope of this disclosure, it may use technologies such as PUFs (Physically Unclonable Functions) or fuses. The bits used to represent UDS 820 may be obfuscated and shielded to thwart extraction. Outside of provisioning, UDS 820 is read-only by Control Logic 810. Whenever UDS 820 is used, such as in FIG. 6 (UDS 607) or 7 (UDS 708), it must be erased from where it was used (such as by E 606 or E 704) to prevent reuse for unauthorized purposes.
(29) While PCR 830's contents are readable and sharable to any On-Chip Resource 890, PCR 830 can only be written by Control Logic 810 during platform reset for initialization or by Extend 813 as shown in FIGS. 4 (via 408 and 405) and 5 (via 508 and 505).
(30) While the On-Chip Root of Trust 805 contains crypto accelerators Hash 840 and Cipher 850, Control Logic 810 will control them for its internal use via Extend 813 and Quote 811, or for indirect, general purpose use by On-Chip Resource 890 via Other 815. When switching between internal and external modes, Control Logic 810 will ensure that no interference or leakage occurs.
(31) Extend 813 control logic is responsible for updating PCR 830 as shown in FIG. 4 (PCR 407) or 5 (PCR 504) to affect the Extend primitive. It will ensure that only the specified inputs are hashed, that only this output is written to PCR 830, and that it is not interruptible. The process will fully complete before responding to any other requests for root of trust or general-purpose services.
(32) Quote 811 control logic is responsible for reading both PCR 830 and UDS 820 as shown in FIGS. 6 (reading PCR 604 and UDS 607) and 7 (reading PCR 701 and UDS 708) to affect the Quote primitive. Quote 811 control logic will ensure that only (PCR 830∥Nonce) is hashed and that only that result is signed by UDS 820. The “Nonce” in (PCR 830∥Nonce) is included in a Quote request transmitted as Request 870 via Internal Bus 880 by On-Chip Resource 890. A resulting signature generated by Quote 811 (for example SIG 709 as shown in FIG. 7) will be returned to On-Chip Resource 890 as Reply 860, also via Internal Bus 880. Any transient copies of UDS 820 (e.g. in Cipher 850 key input) will be erased to help prevent disclosure or reuse. The process will fully complete before responding to any other requests for root of trust or general-purpose services.
(33) Other control logic 815 may be used for other root of trust operations (such as to support sealed storage) or to enable general purpose use of the accelerators.
(34) FIG. 9 is a high-level block diagram illustrating a traditional trusted platform implementation for purposes of comparing the prior art to embodiments of the present invention. In a traditional trusted platform implementation, an On-Chip Resource 990 executing on a Host 921 may issue Requests 970 (such as Extend and Quote) to TPM 905. Requests 970 are typically transmitted to TPM 905 from an On-Chip Resource 990 via an Internal Bus 980, then to an External Bus Controller 925, then through an External Bus 985, and finally to the TPM 905. A Reply 960 corresponding to Request 970 will typically be transmitted from TPM 905 to an On-Chip Resource 990 in similar fashion, but in reverse, from TPM 905 to an External Bus 985, then through an External Bus Controller 925 executing on Host 921, and finally through Internal Bus 980 to On-Chip Resource 990. TPM 905 may correspond to TPM 122. External bus 985 may implement a number of bus architectures, including LPC (Low Pin Count), I.sup.2C (Inter-Integrated Circuit), or SPI (Serial-Peripheral Interface). These are the same bus architectures that can enable modules executing on Host 121 (such as RTM 110, SW Module 111, and the like) to communicate with TPM 122, as illustrated in FIG. 1. Host 921 may correspond to Host 121. Reply 960 may correspond to Reply 860. Request 970 may correspond to Request 870. Internal Bus 980 may correspond to Internal Bus 880. On-Chip Resource 990 may correspond to On-Chip Resource 890.
(35) FIG. 10 is a high-level block diagram illustrating an implementation of a Host Chip 1000 with an On-Chip Root of Trust 1005, for purposes of comparing the prior art (shown in FIG. 9, for example) to embodiments of the present invention. Just as in a traditional trusted platform implementation (see FIGS. 1 and 9), On-Chip Resource 1090 executing on a Host 1000 may issue Requests 1070 (such as Extend and Quote). Rather than being transmitted to an off-chip TPM, such as TPM 905, Requests 1070 may be transmitted to an On-Chip Root of Trust 1005 from an On-Chip Resource 1090 directly through Internal Bus 1080. A Reply 1060 corresponding to Request 1070 may be transmitted from On-Chip Root of Trust 1005 to On-Chip Resource 1090 in similar fashion, but in reverse, directly through Internal Bus 1080. On-Chip Root of Trust 1005 may correspond to On-Chip Root of Trust 805. Reply 1060 may correspond to Reply 860 or Reply 960. Request 1070 may correspond to Request 870 or Request 970. Internal Bus 1080 may correspond to Internal Bus 880 or Internal Bus 980. On-Chip Resource 1090 may correspond to On-Chip Resource 890 or On-Chip Resource 990.
(36) Variations
(37) The present invention can be realized in hardware, software, or a combination of hardware and software. The invention can be realized in a centralized fashion in one computing system, or in a distributed fashion where different elements are spread across several computing systems. Any kind of computer system or other apparatus adapted for implementing the limitations described herein is suitable.
(38) Although the present disclosure provides certain embodiments, other embodiments apparent to those of ordinary skill in the art, including embodiments that do not provide all the features and advantages set forth herein, are also within the scope of this disclosure.
(39) The foregoing disclosure has been set forth merely to illustrate the invention and is not intended to be limiting. It will be appreciated that modifications, variations and additional embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention. Other logic may also be provided as part of the exemplary embodiments but are not included here so as not to obfuscate the present invention. Since modifications of the disclosed embodiments incorporating the spirit and substance of the invention may occur to persons skilled in the art, the invention should be construed to include everything within the scope of the appended claims and equivalents thereof.
