Patent Description:
While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

As described above, Physically Unclonable Functions (PUPs) are emerging as attractive solutions for low-cost device authentication. PUPs harness manufacturing process variations to provide a unique device-specific response for a given input (known as challenge) to enable authentication over an insecure communication channel. The use of Red Keys and Black Keys are common techniques for utilizing PUFs to generate a Key-Encryption-Key (KEK), which may be used to protect sensitive information.

In order for a PUF to be used in the creation of a cryptographic key, the output must be validated for sufficient entropy. This entropy validation occurs on-chip, as the PUF output should never be exposed externally. Entropy validation consumes valuable real estate on the chip and consumes processing time. The resulting PUF key may be used in a cryptographic operation to convert the Black Key into the Red Key, which results in an unnecessary electromagnetic emission that could leak information about the PUF key.

To address these and other issues, described herein are techniques which use a PUF to generate a pool of random bits that may be used to re-create a known good key with high entropy. The described techniques also incorporate time-based variations in the re-creation of the key in order to provide full obfuscation of data needed to re-create the key(s).

Various techniques described herein reduce concern about the entropy of a PUF generated key, while also eliminating, or at least reducing, unnecessary circuitry that would normally be used to validate the entropy of the PUF output. In addition, these techniques reduce security risks associated with a metal group key encryption key (GKEK) by only utilizing it for supply chain threat mitigation during manufacturing. Further, these techniques reduce security risk from electromagnetic emissions that could be used to extract the PUF output. Finally, these techniques reduce the need to store any key material, encrypted or otherwise, thereby reducing the value of physical attacks against the target.

<FIG> is a simplified schematic diagram of an example system including an authentication system in accordance with an embodiment. Referring to <FIG>, in some examples, system <NUM> comprises an electronic device <NUM>. A detailed description of components of an electronic device <NUM> is provided with reference to <FIG>, below.

In some examples, electronic device <NUM> may be implemented a one or more components of a computing system. In other examples, edge device <NUM> may comprise an electronically activatable device such as an integrated circuit that is to be mounted on a credit card, identification card, or the like. Electronic device <NUM> comprises one or more physically unclonable functions (PUPs) such as a PUF circuit <NUM>, a provisioning circuit <NUM>, and a validation circuit <NUM>. In some examples, PUF device/circuit <NUM> may be constructed using delay chains, SRAM bitcells, or cross-coupled inverters as an entropy source. Various embodiments of a provisioning circuit <NUM> and a validation circuit <NUM> are described with reference to <FIG>, below.

<FIG> is a simplified block diagrams illustrating components of an apparatus capable to implement a time-based multi-dimensional key recreation mechanism using PUF technologies, in accordance with an embodiment. <FIG> is a schematic illustration of an embodiment of a provisioning circuit <NUM>. Referring to <FIG>, in some examples, provisioning circuit <NUM> receives a PUF output from a PUF circuit <NUM> and packs the PUF output into a circular shift register <NUM>. Provisioning circuit <NUM> further receives an encryption key (e.g., a red key) that is packed into a shift register <NUM>. Provisioning circuit <NUM> comprises at least one of an exclusive NOR (XNOR) or an exclusive OR gate <NUM> that operates on the contents of the circular shift register <NUM> and the shift register <NUM> to generate a series of match bits <NUM>. In the embodiment depicted in <FIG> all components reside within the same system clock domain and physical chip boundary.

<FIG> is a schematic illustration of an embodiment of a validation circuit <NUM>. Referring to <FIG>, in some examples, validation circuit <NUM> receives a PUF output from a PUF circuit <NUM> and packs the PUF output into a circular shift register <NUM>. Validation circuit <NUM> further receives the match bits <NUM> that are packed into a shift register <NUM>. Provisioning circuit <NUM> comprises a latch <NUM> that operates on the contents of the circular shift register <NUM> and the shift register <NUM> to generate an encryption key <NUM> (e.g., a red key). In the embodiment depicted in <FIG> all components reside within the same system clock domain and physical chip boundary.

Rather than using the output of the PUF device as a seed to a key derivation function (KDF), the output of the PUF device is instead used as a pool of random bits from which a pre-generated key with known good entropy can simply be recreated. It is also possible to use the PUF output to seed a RNG. In one example, the provisioning circuit <NUM> a provisioning stage performs a not-exclusive-or of the PUF output with the encryption key, one bit at a time (i.e., a bitwise comparison). This operation identifies matches between the two bitstreams resulting in a sequence of match bits <NUM>. Both the PUF output <NUM> and the encryption key <NUM> have their own effective index for iteration, with the index for the PUF output <NUM> incrementing on every comparison and the index for the encryption key <NUM> incrementing on every match.

<FIG> is a simplified data flow diagram of at least one embodiment of a method <NUM> to implement a time-based multi-dimensional key recreation mechanism using PUF technologies, in accordance with an embodiment. Operation of the provisioning circuit <NUM> and the validation circuit <NUM> will be described with reference to <FIG>. Referring to <FIG>, at operation <NUM> the provisioning circuit receives a first PUF bitstring from a physically unclonable function (PUF) device, e.g., PUF device/circuit <NUM>.

At operation <NUM> the provisioning circuit <NUM> generates, during the provisioning process, a series of match bits, wherein each bit in the series of match bits indicates whether a first PUF bit in the first PUF bitstring matches a corresponding encryption key bit in an encryption key. In some examples operation <NUM> may include operation <NUM> in which the provisioning circuit <NUM> packs the first PUF bitstring into a circular shift register <NUM>. In some examples operation <NUM> may include operation <NUM> in which the provisioning circuit <NUM> packs the encryption key <NUM> into a second shift register <NUM>. In some examples operation <NUM> may include operation <NUM> in which the provisioning circuit <NUM> applies at least one of a non-exclusive or logical operation or an exclusive or logical operation between a first bit in the first shift register and a second bit in the second shift register to generate a match bit. Operation <NUM> may be repeated until a bitwise comparison of the contents of the first shift register <NUM> and the second shift register <NUM> is complete, thereby forming a series of match bits <NUM>.

The process for recreating the authentication key solution only requires latching in the right bits of the PUF output <NUM> as those bits are cycled through a shift register. For example, a bit value of '<NUM>' in the match bits <NUM> indicates that the corresponding bit in the PUF output should be used as part of the encryption key, whereas a bit value of '<NUM>' says the bit should be ignored. The match bits <NUM> created previously the control the enable signal of a latch and serves to identify the correct bits for recreating the encryption key <NUM>.

Thus, referring to <FIG>, at operation <NUM> the validation circuit <NUM> uses at least a portion of the series of match bits to recreate, during an authentication process, the encryption key. In some examples operation <NUM> may include operation <NUM> in which the validation circuit <NUM> applies a latch logical operation between a first bit in the first shift register and a second bit in the second shift register to generate a copy of the encryption key. Operation <NUM> may be repeated until a bitwise comparison of the contents of the first shift register <NUM> and the second shift register <NUM> is complete, thereby recreating the encryption key <NUM>.

To illustrate how the operations occur and the match bits <NUM> are created, an example is provided in Table <NUM> and Table <NUM>. Table <NUM> shows a provisioning stage for an example case where the match bits <NUM> are identified based on a trivial encryption key <NUM> and PUF Output <NUM>.

Reproduction of the example Red Key is shown in Table <NUM>.

To prevent unintentional leakage of bit transitions in the PUF output <NUM> in some examples, a time-based multi-dimensional solution is implemented as illustrated in <FIG> and <FIG>. <FIG> is a schematic illustration of an embodiment of a provisioning circuit <NUM> similar to the circuit described with reference to <FIG>. Referring to <FIG>, in some examples, provisioning circuit <NUM> receives a PUF output from a PUF circuit <NUM> and packs the PUF output into a circular shift register <NUM>. Provisioning circuit <NUM> further receives an encryption key (e.g., a red key) that is packed into a shift register <NUM>. Provisioning circuit <NUM> comprises at least one of an exclusive NOR (XNOR) or an exclusive OR gate <NUM> that operates on the contents of the circular shift register <NUM> and the shift register <NUM> to generate a series of match bits <NUM>.

In the embodiment depicted in <FIG>, the circular shift register <NUM> and the at least one of an exclusive NOR (XNOR) or an exclusive OR gate <NUM> operate according to a system clock domain generated on-chip and the encryption key <NUM> and shift register <NUM> operate according to an external debug clock domain input by an external user via a pin on the processor (although this second domain could be created on chip as well). The circular shift register <NUM> for the PUF output <NUM> operates as described previously. The shift register <NUM> for the encryption key <NUM> still increments when a match is found, but the frequency at which it performs the comparison is under the control of a separate clock domain. This results in the ability to perform non-sequential and non-linear comparisons between the two shift registers, resulting in effective delays.

For example, if the encryption key shift register <NUM> is being clocked at <NUM> while the circular shift register <NUM> for the PUF Output is being clocked at <NUM>, the result would be that the not-exclusive-or would compare the encryption key bits with every other PUF output bit, as opposed to comparing them sequentially. The respective clock rates can be static or completely dynamic to adjust the delay rates between the domains. As long as the initial provisioner or internal hardware is able to recreate the proper sequence, virtually any sequence of delays will work.

The validation circuit can be similarly divided into separate clock domains. <FIG> is a schematic illustration of an embodiment of a validation circuit <NUM>. Referring to <FIG>, in some examples, validation circuit <NUM> receives a PUF output from a PUF circuit <NUM> and packs the PUF output into a circular shift register <NUM>. Validation circuit <NUM> further receives the match bits <NUM> generated by provisioning circuit <NUM> that are packed into a shift register <NUM>. Provisioning circuit <NUM> comprises a latch <NUM> that operates on the contents of the circular shift register <NUM> and the shift register <NUM> to generate an encryption key <NUM> (e.g., a red key).

In the embodiment depicted in <FIG>, the circular shift register <NUM> and the latch <NUM> operate according to a system clock domain generated on-chip and the encryption key <NUM> and shift register <NUM> operate according to an external debug clock domain input by an external user via a pin on the processor (although this second domain could be created on chip as well).

In another example a variable delay may be introduced by skipping bit in a programmatic manner when reading the PUF output <NUM>. For example, the PUF output <NUM> could be read four bits at a time, but only the first bit is used for comparison with a bit in the encryption key <NUM>. The remaining three bits provide a random value to a counter resulting in the PUF output shift register <NUM> that causes the register to advance anywhere from <NUM>-<NUM> places while the encryption key register <NUM> only progresses <NUM> bit. This is illustrated in the bit sequence depicted in <FIG>. The first bit in this sequence, '<NUM>', represents the bit for comparison with a bit from the encryption key <NUM>. The next three bits, '<NUM>', represent the number of random cycles of delay to introduce.

Rather than moving forward one space in a linear fashion for the next comparison bit, the proposed solution progresses <NUM> + n steps, where n is the random <NUM>-bit value represented by the binary value of the delay bits. In this case, the solution will move forward <NUM>+<NUM> (i.e., binary <NUM>) steps to find the next comparison bit, as shown in <FIG>. In <FIG> the value of the comparison bit is '<NUM>' and added delay of '<NUM>'. The next comparison bit will then be <NUM>+<NUM> positions forward, as shown in <FIG>. In <FIG> the value of the comparison bit is '<NUM>' a delay value of '<NUM>' (i.e., <NUM>). The subsequent progression is shown in <FIG>.

In the example depicted in <FIG>, the comparison bit is the final bit in the string, '<NUM>', and the delay bits wrap around to the beginning of the bitstring, i.e., the binary string '<NUM>'. This cycle can continue until all needed comparisons are completed. The example above used a <NUM>-bit delay window, although there are no physical or logical constraints on the window size, other than what might be imposed by adopting requirements.

<FIG> is a block diagram illustrating a computing architecture which may be adapted to implement a secure address translation service using a permission table (e.g., HPT <NUM> or HPT <NUM>) and based on a context of a requesting device in accordance with some examples. The embodiments may include a computing architecture supporting one or more of (i) verification of access permissions for a translated request prior to allowing a memory operation to proceed; (ii) prefetching of page permission entries of an HPT responsive to a translation request; and (iii) facilitating dynamic building of the HPT page permissions by system software as described above.

In various embodiments, the computing architecture <NUM> may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture <NUM> may be representative, for example, of a computer system that implements one or more components of the operating environments described above. In some embodiments, computing architecture <NUM> may be representative of one or more portions or components in support of a secure address translation service that implements one or more techniques described herein.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive or solid state drive (SSD), multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the unidirectional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> includes one or more processors <NUM> and one or more graphics processors <NUM>, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors <NUM> or processor cores <NUM>. In on embodiment, the system <NUM> is a processing platform incorporated within a system-on-a-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

An embodiment of system <NUM> can include, or be incorporated within, a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system <NUM> is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system <NUM> can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system <NUM> is a television or set top box device having one or more processors <NUM> and a graphical interface generated by one or more graphics processors <NUM>.

In some embodiments, one or more processor(s) <NUM> are coupled with one or more interface bus(es) <NUM> to transmit communication signals such as address, data, or control signals between processor <NUM> and other components in the system. The interface bus <NUM>, in one embodiment, can be a processor bus, such as a version of the Direct Media Interface (DMI) bus. However, processor buses are not limited to the DMI bus, and may include one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express), memory buses, or other types of interface buses. In one embodiment the processor(s) <NUM> include an integrated memory controller <NUM> and a platform controller hub <NUM>. The memory controller <NUM> facilitates communication between a memory device and other components of the system <NUM>, while the platform controller hub (PCH) <NUM> provides connections to I/O devices via a local I/O bus.

Memory device <NUM> can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory. In one embodiment the memory device <NUM> can operate as system memory for the system <NUM>, to store data <NUM> and instructions <NUM> for use when the one or more processors <NUM> execute an application or process. Memory controller hub <NUM> also couples with an optional external graphics processor <NUM>, which may communicate with the one or more graphics processors <NUM> in processors <NUM> to perform graphics and media operations. In some embodiments a display device <NUM> can connect to the processor(s) <NUM>. The display device <NUM> can be one or more of an internal display device, as in a mobile electronic device or a laptop device or an external display device attached via a display interface (e.g., DisplayPort, etc.). In one embodiment the display device <NUM> can be a head mounted display (HMD) such as a stereoscopic display device for use in virtual reality (VR) applications or augmented reality (AR) applications.

In some embodiments the platform controller hub <NUM> enables peripherals to connect to memory device <NUM> and processor <NUM> via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller <NUM>, a network controller <NUM>, a firmware interface <NUM>, a wireless transceiver <NUM>, touch sensors <NUM>, a data storage device <NUM> (e.g., hard disk drive, flash memory, etc.). The data storage device <NUM> can connect via a storage interface (e.g., SATA) or via a peripheral bus, such as a Peripheral Component Interconnect bus (e.g., PCI, PCI Express). The touch sensors <NUM> can include touch screen sensors, pressure sensors, or fingerprint sensors. The wireless transceiver <NUM> can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a <NUM>, <NUM>, Long Term Evolution (LTE), or <NUM> transceiver. The firmware interface <NUM> enables communication with system firmware, and can be, for example, a unified extensible firmware interface (UEFI). The network controller <NUM> can enable a network connection to a wired network. In some embodiments, a high-performance network controller (not shown) couples with the interface bus <NUM>. The audio controller <NUM>, in one embodiment, is a multi-channel high definition audio controller. In one embodiment the system <NUM> includes an optional legacy I/O controller <NUM> for coupling legacy (e.g., Personal System <NUM> (PS/<NUM>)) devices to the system. The platform controller hub <NUM> can also connect to one or more Universal Serial Bus (USB) controllers <NUM> connect input devices, such as keyboard and mouse <NUM> combinations, a camera <NUM>, or other USB input devices.

In the description above, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments. It will be apparent, however, to one skilled in the art that embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form. There may be intermediate structure between illustrated components. The components described or illustrated herein may have additional inputs or outputs that are not illustrated or described.

Various embodiments may include various processes. These processes may be performed by hardware components or may be embodied in computer program or machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the processes. Alternatively, the processes may be performed by a combination of hardware and software.

Portions of various embodiments may be provided as a computer program product, which may include a computer-readable medium having stored thereon computer program instructions, which may be used to program a computer (or other electronic devices) for execution by one or more processors to perform a process according to certain embodiments. The computer-readable medium may include, but is not limited to, magnetic disks, optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically-erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or other type of computer-readable medium suitable for storing electronic instructions. Moreover, embodiments may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer.

Many of the methods are described in their most basic form, but processes can be added to or deleted from any of the methods and information can be added or subtracted from any of the described messages without departing from the basic scope of the present embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations can be made. The particular embodiments are not provided to limit the concept but to illustrate it. The scope of the embodiments is not to be determined by the specific examples provided above but only by the claims below.

If it is said that an element "A" is coupled to or with element "B," element A may be directly coupled to element B or be indirectly coupled through, for example, element C. When the specification or claims state that a component, feature, structure, process, or characteristic A "causes" a component, feature, structure, process, or characteristic B, it means that "A" is at least a partial cause of "B" but that there may also be at least one other component, feature, structure, process, or characteristic that assists in causing "B. " If the specification indicates that a component, feature, structure, process, or characteristic "may", "might", or "could" be included, that particular component, feature, structure, process, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, this does not mean there is only one of the described elements.

Claim 1:
A method (<NUM>) comprising:
receiving (<NUM>) a first PUF bitstring (<NUM>) from a physically unclonable function (PUF) device (<NUM>);
generating (<NUM>), during a provisioning process, a series of match bits (<NUM>), wherein each bit in the series of match bits indicates whether a PUF bit in the first PUF bitstring matches a corresponding encryption key bit in a pre-generated encryption key (<NUM>); and
using (<NUM>) said first PUF bitstring and at least a portion of the series of match bits to recreate, during an authentication process, said pre-generated encryption key.