Patent Grant
11210373
In general, embodiments of the present invention relate to system hardware. Specifically, embodiments of the present invention relate to a self-authenticating chip having an intrinsic chip identifier (ID).
In today's global marketplace, the growing use of counterfeit information technology (IT) computer and hardware equipment is a difficult challenge facing businesses across the world. Counterfeit hardware is becoming harder to identify, as it may display high technical specifications and reputed brand names. Counterfeit IT hardware cuts into the revenue of hundreds of legitimate players in the supply chain including dealers, suppliers, and manufacturers. For these legitimate companies, the losses and damages may be significant because counterfeit IT hardware competes with authentic hardware. Ultimately, it may affect a brand's reputation and marketplace equity.
Embodiments of the present invention provide an authenticating service of a chip using an intrinsic component. In a typical embodiment, an authenticating device is provided that includes an identification (ID) engine, a self-test engine, and an intrinsic component. The intrinsic component is associated with a chip and includes an intrinsic feature. For ID generation, the self-test engine retrieves the intrinsic feature and communicates it to the identification engine. The identification engine receives the intrinsic feature, generates a first authentication value using the intrinsic feature, and stores the authentication value in memory. For ID authentication, the self-test engine generates a second authentication value using an authentication challenge. The identification engine includes a compare circuitry that compares the first authentication value and the second authentication value and generates an authentication output value based on the results of the compare of the two values.
A first aspect of the present invention provides a system for providing an authenticating service of a chip, the system comprising: an authenticating device comprising an identification engine, a self-test engine, and an intrinsic component, wherein the intrinsic component is associated with a chip and comprises an intrinsic feature; the self-test engine configured to retrieve the intrinsic feature and communicate the intrinsic feature to the identification engine; the identification engine further configured to receive the intrinsic feature, generate a first authentication value using the intrinsic feature, and store the authentication value in memory; the self-test engine further configured to generate a second authentication value using an authentication challenge; the identification engine further comprising a compare circuitry configured to compare the first authentication value and the second authentication value; and the compare circuitry further configured to generate an authentication output value based on the results of the compare of the first authentication value and the second authentication value.
A second aspect of the present invention provides a method for providing an authenticating service of a chip, the method comprising: retrieving an intrinsic feature at a self-test engine, wherein the intrinsic feature is derived from an intrinsic component and the intrinsic feature is associated with a chip; receiving the intrinsic feature at an identification engine; generating a first authentication value using the intrinsic feature at the identification engine; storing the first authentication value in memory; generating a second authentication value at the self-test engine using an authentication challenge; comparing the first authentication value and the second authentication value at a compare circuitry; and generating an authentication output value at the compare circuitry based on the results of the compare of the first authentication value and the second authentication value.
A third aspect of the present invention provides a method for deploying a system for providing an authenticating service of a chip, the system comprising a database and an authenticating device comprising an identification engine, a self-test engine, and an intrinsic component, wherein the intrinsic component is associated with a chip and comprises an intrinsic feature; the self-test engine configured to retrieve the intrinsic feature and communicate the intrinsic feature to the identification engine; the identification engine further configured to receive the intrinsic feature, generate a first authentication value using the intrinsic feature, and store the authentication value in memory; the self-test engine further configured to generate a second authentication value using an authentication challenge generated by the database; the identification engine further comprising a compare circuitry configured to compare the first authentication value and the second authentication value; and the compare circuitry further configured to generate an authentication output value to the database based on the results of the compare of the first authentication value and the second authentication value, and the database confirming the authentication output value.
These and other features of this invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings in which:
The drawings are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. The drawings are intended to depict only typical embodiments of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numbering represents like elements.
Illustrative embodiments will now be described more fully herein with reference to the accompanying drawings, in which exemplary embodiments are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of this disclosure to those skilled in the art. In the description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, the use of the terms “a”, “an”, etc., do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items. The term “set” is intended to mean a quantity of at least one. It will be further understood that the terms “comprises” and/or “comprising”, or “includes” and/or “including”, when used in this specification, specify the presence of stated features, regions, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, regions, integers, steps, operations, elements, components, and/or groups thereof. The terms “first” and “1st” are used interchangeably, as well as the terms “second” and “2nd”.
It will be understood that, although the terms first, second, third, etc., may be used herein to describe various buffers, cores, grades, and/or memories, these buffers, cores, grades, and/or memories should not be limited by these terms. These terms are only used to distinguish one buffer, core, grade, or memory from another buffer, core, grade, or memory. Thus, a first buffer, core, grade, or memory discussed below could be termed a second buffer, core, grade, or memory without departing from the teachings of the present inventive concept.
Embodiments are described herein with reference to cross-sectional or perspective illustrations that are schematic illustrations of idealized embodiments (and intermediate structures). As such, variations from the shapes of the illustrations as a result, for example, of manufacturing techniques and/or tolerances are to be expected. Thus, embodiments should not be construed as limited to the particular shapes of regions illustrated herein but are to include deviations in shapes that result, for example, from manufacturing. For example, an edge or corner region illustrated as having sharp edges may have somewhat rounded or curved features. Likewise, elements illustrated as circular or spherical may be oval in shape or may have certain straight or flattened portions. Thus, the regions illustrated in the figures are schematic in nature, and their shapes are not intended to illustrate the actual shape of a region or element of a device and are not intended to limit the scope of the disclosed embodiments.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this inventive concept belongs. It will be further understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.
Embodiments of the present invention provide an authenticating service of a chip using an intrinsic component. In a typical embodiment, an authenticating device is provided that includes an identification (ID) engine, a self-test engine, and an intrinsic component. The intrinsic component is associated with a chip and includes an intrinsic feature. The self-test engine retrieves the intrinsic feature and communicates it to the identification engine. The identification engine receives the intrinsic feature, generates a first authentication value using the intrinsic feature, and stores the authentication value in memory. The self-test engine generates a second authentication value using an authentication challenge. The identification engine includes a compare circuitry that compares the first authentication value and the second authentication value and generates an authentication output value based on the results of the compare of the two values.
In order to curb the spread of counterfeit hardware, it is necessary to develop methods to establish a hardware root of trust. Chip identifiers must be unique and hard to clone. The large amounts of memory embedded in chips provides a pathway to creating such keys by exploiting intrinsic properties from each bit cell which are a consequence of inherent variability in the chip manufacturing process.
Such hardware keys belong to the family of physically unclonable functions (PUFs), which suffer from a lack of strict reproducibility. Some PUFs based on DRAM are guaranteed to change very little between assessments, and can therefore be made practical by means of a fuzzy authentication algorithm. Because this approach always requires a pattern recognition approximate match, secure hashing is not possible, and authentication requires an off-chip fuzzy comparison of the chip response to the chip unique identification string originally kept in the manufacturers secure database. This requires large databases that can store all the pattern identifiers for every chip, and it requires communicating the identifier over a network. The systems and methods described herein present a solution that can be used with any intrinsic identifier which meets a minimum reproducibility threshold.
The self-authenticating intrinsic ID methodology employs an unclonable random bit pattern, preferably using embedded memory. A challenge is provided to create a bit pattern. The chip possesses intrinsic information that is unique to each chip and results from manufacturing variability. This information can be divided into two parts: a challenge/question and a response/answer. The question is preferably a combination of a subset of bit addresses belonging to the memory chip to be challenged under certain test conditions, such as chip voltage, chip temperature, or a specific pattern such as retention time (for DRAM). The response is the test result such as pass/fail for each tested bit, creating a bit pattern.
The bit pattern is converted into a binary string, which is encrypted and stored in memory, preferably eFUSE, within the same chip after generation. The original equipment manufacturers (OEM) database records the corresponding challenge, which is unique to each chip and to the intrinsic ID from each chip. The challenge may be used for encrypting and decrypting the bit pattern for creating the binary string stored in the memory, further improving security.
The key idea of the present invention is to enable 100% secure authentication. The OEM database searches the ID to find the corresponding challenge and sends it to the corresponding chip. When the chip is challenged with its corresponding challenge, it enables decryption of the binary string stored locally in memory to generate the original bit map. A valid challenge applied to a different chip will generate a different response because the probability of collision between responses is statistically negligible, while the challenges are tailored to ensure the uniqueness of the response set. Similarly, a valid bit pattern response stored in the chip's local memory bank can only be reproduced by the chip with a valid challenge. Since there are too many bit subsets in a memory chip and too many different challenges to choose from, a counterfeiter cannot determine the bit subset or the challenge with feasible resources in a cheap manner.
A comparator then performs a fuzzy or exact comparison between the resulting new pattern and the original bit map (in nonvolatile memory). A correct match results in the chip self-authenticating. The process is described in more detail below with reference to
The ID engine 104 uses an authentication challenge to authenticate the intrinsic component 108. The intrinsic component 108 may be one of the components used for a product chip. The intrinsic component is associated with the chip and includes an intrinsic feature 120. In one example, the intrinsic feature 120 is made up of a matrix of values.
The authentication challenge 130 supplied by the OEM database (i.e. server) provides the domain information used to generate the intrinsic ID (or authentication value). In this instance, the authentication challenge is location challenge 132. The domain information provided by the location challenge 132 is input to the self-test engine 106 to produce the domain address to access a specific address domain in the intrinsic component, preferably DRAM 108.
The BIST 106 performs the function of generating the domain address and the data pattern for testing the intrinsic component associated with the intrinsic feature, preferably DRAM 108. The location challenge 132 is provided to the address generator 204. The address generator uses the location challenge 132 to produce the domain (or physical) address 222 of the DRAM 108, or more specifically, the address to access the corresponding 1T1C cells 150.
The fail counter 212 counts the number of fails to check if it is equal to the number specified. If not, the VWL generator 208 varies the VWL to generate more fails until the required number of fails has been reached. In one example, the limit on the required number of fails may be set on the domains requested. In another example, the limit may be set for the entire memory. Upon generating the required number of fails, a vector pattern corresponding to the requested domain fails is generated at the fail register 214 and sent to the ID function generator 112 (
Referring back to
During authentication, the authentication challenge 130 supplied by the OEM database (i.e. server) specifies the domain addresses as previously mentioned. In this instance, the authentication challenge includes an ID function challenge 134 or memory challenge 136. A second authentication value 124 is generated from the domains as illustrated above using the ID function specified and the bit fails produced by the DRAM 108.
Referring back to
The fuzzy comparator 402 compares the 1st authentication value 122 (i.e., the recorded eFUSE ID) with the 2nd authentication value 124 (i.e., the generated chip ID). The comparison may be implemented as a simple XOR or AND of the individual bits. A counter 404 counts the number of matches. The fuzzy comparator 402 may accommodate a specific number of matches to account for the variation in the generated authentication values. If the number of matches is smaller than a predefined fuzzy threshold 406, the fuzzy comparator 402 returns a mismatch indicating that the 1st authentication value 122 failed to match with the 2nd authentication value 124.
A one challenge-response pair approach provides a means of self-authentication, but it is an approach vulnerable to man-in-the-middle attacks. If a third party intercepts the result of the local match that the chip sends back to the OEM database (i.e., server), the third party can easily distinguish between a Yes or No, since there are only two outcomes.
Secure identification may be accomplished by generating multiple challenge-response pairs. Additionally, multiple challenges must be provided at each authentication step, generating a string of results from local response matches. Also, to avoid trivial result strings of Y or N, the questions must include a combination of true challenges and false challenges, which can be randomized at every authentication request from the challenges in the database, since there are guard bands ensuring a negligible number of collisions for challenges and responses belonging to different pairs. The string of 1s (Y) and 0s (N) may result in a bit string created after the intrinsic ID comparisons are made. The bit string has a definite expectation value on the OEM's side and must be reproducible. Such a string can be hashed for increased security by using a one-way function (irreversible), and if the results of the hash on the OEM's side and customer's side match, then the chip is securely authenticated. The expected output value generated by the OEM database for each challenge must match the authentication output value from the authentication device in order to result in confirmation of the chip's authenticity.
It will be appreciated that the exemplary method process flow 500 of
Secure self-authentication follows from scaling this approach to a series of randomized challenges, of which a few are expected to result in a correct local match (at least one in order to avoid a trivial response). The new bit string comprised of all the false (0) and positive (1) matches is unique and exactly reproducible. This is analogous to a lie detector test with a secretly known set of absolute truths. The questions/challenges and answers/responses possess a truth table known only to the OEM, and every answer has only two outcomes (false-0 or positive-1). The chip itself does not possess key information that validates the local intrinsic information stored locally in memory. This key information that the OEM stores in a database is preferably the physical addresses of the group of bits possessing the intrinsic signature, which can be combined with a set of test conditions such as chip voltages, which may or may not include VWL, and/or chip temperatures, which may or may not be controllable. A counterfeiter that copies the non-volatile component has a negligible chance of creating a chip that can be successfully validated due to the missing key information and the unclonability of the intrinsic memory signature.
In summary, this method and related circuits create secure reproducible random strings which are unique to each chip and derived from an intrinsic ID which does not need to be strictly reproducible. The resulting strings, which can be randomized at each authentication, are compatible with hashing algorithms, leading to increased security.
The foregoing description of various aspects of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed and, obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of the invention as defined by the accompanying claims.
The present patent document is a continuation of U.S. patent application Ser. No. 16/238,738, filed Jan. 3, 2019, the entire contents of which is incorporated herein by reference. U.S. patent application Ser. No. 16/238,738 is a continuation of U.S. patent application Ser. No. 15/489,036, filed Apr. 17, 2017, U.S. Pat. No. 10,262,119, issued Apr. 16, 2019, the entire contents of which is incorporated herein by reference. U.S. patent application Ser. No. 15/489,036 is a continuation of U.S. patent application Ser. No. 14/658,611, filed Mar. 16, 2015, U.S. Pat. No. 9,690,927, issued Jun. 27, 2017, the entire contents of which is incorporated herein by reference. U.S. patent application Ser. No. 14/658,611 is a continuation of U.S. patent application Ser. No. 13/707,964, filed Dec. 7, 2012, U.S. Pat. No. 9,038,133, issued May 19, 2015, the entire contents of which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5157664 | Waite | Oct 1992 | A |
| 5982899 | Probst | Nov 1999 | A |
| 7840803 | Clarke et al. | Nov 2010 | B2 |
| 7898283 | Koushanfar et al. | Mar 2011 | B1 |
| 8065718 | Grove et al. | Nov 2011 | B2 |
| 8590010 | Fainstein et al. | Nov 2013 | B2 |
| 8595498 | Junod | Nov 2013 | B2 |
| 8667265 | Hamlet et al. | Mar 2014 | B1 |
| 9038133 | Chellappa et al. | May 2015 | B2 |
| 9330788 | Anzou | May 2016 | B2 |
| 9690927 | Chellappa et al. | Jun 2017 | B2 |
| 10262119 | Chellappa et al. | Apr 2019 | B2 |
| 20030204743 | Devadas et al. | Oct 2003 | A1 |
| 20040049468 | Walmsley | Mar 2004 | A1 |
| 20040060017 | Abdennadher | Mar 2004 | A1 |
| 20050265735 | Kim | Dec 2005 | A1 |
| 20060059395 | Su et al. | Mar 2006 | A1 |
| 20060221686 | Devadas et al. | Oct 2006 | A1 |
| 20080229119 | Skoric et al. | Sep 2008 | A1 |
| 20080263362 | Chen | Oct 2008 | A1 |
| 20080279373 | Erhart et al. | Nov 2008 | A1 |
| 20090011596 | Okuno | Jan 2009 | A1 |
| 20090083833 | Ziola et al. | Mar 2009 | A1 |
| 20090158445 | Dewar | Jun 2009 | A1 |
| 20090217045 | Skoric et al. | Aug 2009 | A1 |
| 20090282259 | Skoric et al. | Nov 2009 | A1 |
| 20100122093 | Tuyls et al. | May 2010 | A1 |
| 20100122353 | Koushanfar et al. | May 2010 | A1 |
| 20100127822 | Devadas | May 2010 | A1 |
| 20100146261 | Talstra et al. | Jun 2010 | A1 |
| 20100177898 | Tuyls et al. | Jul 2010 | A1 |
| 20100287374 | Roy et al. | Nov 2010 | A1 |
| 20100289590 | von Staudt et al. | Nov 2010 | A1 |
| 20110215829 | Merchan et al. | Sep 2011 | A1 |
| 20120033810 | Devadas et al. | Feb 2012 | A1 |
| 20120131340 | Teuwen et al. | May 2012 | A1 |
| 20120168506 | Ruehrmair et al. | Jul 2012 | A1 |
| 20120182041 | Laackmann et al. | Jul 2012 | A1 |
| 20120183135 | Paral et al. | Jul 2012 | A1 |
| 20120278893 | Jyothi et al. | Nov 2012 | A1 |
| 20120293354 | Suzuki | Nov 2012 | A1 |
| 20130133031 | Fainstein et al. | May 2013 | A1 |
| 20130147511 | Koeberl et al. | Jun 2013 | A1 |
| 20130163764 | van den Berg et al. | Jun 2013 | A1 |
| 20130187764 | Smith | Jul 2013 | A1 |
| 20140033330 | Fainstein et al. | Jan 2014 | A1 |
| 20140100807 | Rosenblatt et al. | Apr 2014 | A1 |
| 20140108786 | Kreft | Apr 2014 | A1 |
| 20140111234 | Laackmann et al. | Apr 2014 | A1 |
| 20140165141 | Chellappa et al. | Jun 2014 | A1 |
| 20150186639 | Chellappa et al. | Jul 2015 | A1 |
| 20170220784 | Chellappa et al. | Aug 2017 | A1 |
| 20190155999 | Chellappa et al. | May 2019 | A1 |
| Number | Date | Country |
|---|---|---|
| 101291224 | Oct 2008 | CN |
| 101409620 | Apr 2009 | CN |
| 2302555 | Mar 2011 | EP |
| 2012014623 | Feb 2012 | WO |
| Entry |
|---|
| Rosenblatt, S. et al., “A Self-Authenticating Chip using an Intrinisic Chip ID”, IBM Systems and Technology Group, Hopewell Junction, New York, 3 pages. No publication date cited. |
| Ben Widdows, Application No. GB1320411.0, Uk Examination Report, Dated May 7, 2014, 7 pages. |
| Ben Widdows, Application No. GB 1320411.0, UK Examination Report, Dated Jan. 30, 2015, 3 pages. |
| Bryan F. Wright, USPTO Office Action, U.S. Appl. No. 13/707,964, Notification dated Apr. 25, 2014, 30 pages. |
| Bryan F. Wright, USPTO Final Office Action, U.S. Appl. No. 13/707,964, dated Sep. 25, 2014,19 pages. |
| Bryan F. Wright, USPTO Notice of Allowance and Fee(s) Due, U.S. Appl. No. 13/707,964, dated Dec. 15, 2014, 19 pages. |
| Bryan F. Wright, USPTO Office Action, U.S. Appl. No. 14/658,611, Notification dated May 27, 2016, 21 pages. |
| Bryan F. Wright, USPTO Final Office Action, U.S. Appl. No. 14/658,611, Notification dated Oct. 27, 2016, 15 pages. |
| Bryan F. Wright, USPTO Notice of Allowance and Fee(s) Due, U.S. Appl. No. 14/658,611, dated Feb. 14, 2017, 9 pages. |
| Bryan F. Wright, USPTO Office Action, U.S. Appl. No. 15/489,036, Notification dated Mar. 27, 2018, 32 pages. |
| Bryan F. Wright, USPTO Notice of Allowance and Fees Due, U.S. Appl. No. 15/489,036, dated Oct. 4, 2018, 9 pages. |
| Bryan F. Wright, USPTO Office Action, U.S. Appl. No. 16/238,738, Notification dated May 14, 2019, 22 pages. |
| Bryan F. Wright, USPTO Notice of Allowance and Fees Due, U.S. Appl. No. 16/238,738, dated Sep. 6, 2019, 40 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20200074051 A1 | Mar 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16238738 | Jan 2019 | US |
| Child | 16675516 | US | |
| Parent | 15489036 | Apr 2017 | US |
| Child | 16238738 | US | |
| Parent | 14658611 | Mar 2015 | US |
| Child | 15489036 | US | |
| Parent | 13707964 | Dec 2012 | US |
| Child | 14658611 | US |
