CENTRALIZED HANDLING OF IC IDENTIFICATION CODES

Abstract

The invention relates to a method of generating and authenticating guaranteed unique identifier codes (CID) as may be used for identifying and authenticating assets comprising an integrated circuit, the method comprising; generating guaranteed unique identifiers (AID) in a centralized code registration system (3); storing the generated identifiers (AID) within a data storage (31a-31c); associating each identifier (AID) with an unique identification (CID) to be used for identifying an integrated circuit, by applying a bijective algorithm; authenticating an identification code (CID) by inversely calculating an identifier (AID) from an identification code (CID) based on said algorithm.

Claims

1. A method for handling identification codes (AIDs) of integrated circuits (4), the method comprising: storing (101) the identification codes (AIDs) in one or more first data storages (31a-31c); storing (102) one or more operator keys (OKs) associated with an operator code (OC) in one of a first and a second data storage (31, 32), calculating identifiers (CIDs) for identification of integrated circuits (4) using a mathematical operation on identification codes (AIDs), therein using said one or more operator code (OC) associated operator keys (OKs), wherein each calculated identifier (CID) and the operator code (OC) is associated with an integrated circuit (4), such that each integrated circuit (4) comprises a calculated identifier (CID) and the operator code (OC), wherein an identification code (AID) of an integrated circuit (4) is obtainable from a mathematical operation (103) on the identifier (CID) using the operator code (OC) associated operator key (OK).

2. The method according to claim 1, wherein the operator keys associated with one or more operator codes are stored in a second data storage (32), wherein the second data storage (32) is separate from the first data storage (31).

3. The method according to claim 1, wherein said calculating of an identifier (CID) and said obtaining of an identification code (AID) from an integrated circuit associated identifier (CID) are handled in a centralized code registration system (3a).

4. The method according to claim 2, wherein the code registration system (3) is configured to obtain (104) the operator key (OK) from the second data storage (32) based on the operator code (OC) and perform the mathematical operation (103) on the identifier (CID) using the operator key (OK) as a cryptographic key, in particular wherein the second data storage (32) is a secure data storage, and wherein the method further comprises using a security protocol for accessing the second data storage, preferably the security protocol comprising an encrypted data communication with the second data storage (32) and/or the operator key (OK) being stored in the second data storage (32) in an encrypted format requiring decryption before use in the mathematical operation (103).

6. The method according to claim 1, wherein the identifier (CID) and the operator code (OC) are preferably immutably hard coded in a read-only memory (41, 42) of the integrated circuit (4).

7. The method according to claim 1, wherein the centralized code registration system (3) is configured to verify (105) the identification code (AID) obtained from the mathematical operation (103) against the identification codes (AIDs) stored in the first data storage (31).

8. The method according to claim 1, further comprising: requesting, by a verifying device (5), the identifier (CID) from the integrated circuit (4) via an end node device (2); reading, by the end node device (2), the identifier (CID) and the operator code (OC) from the integrated circuit (4) and transmitting the identifier (CID) and the operator code (OC) to the centralized code registration system (3); obtaining, by the centralized code registration system (3), the identification code (AID) from the identifier (CID) by performing the mathematical operation (103) on the identifier (CID) based on the operator code (OC); and verifying (105), in the centralized code registration system (3), the obtained identification code (AID) against the stored identification codes (AIDs) to obtain and output a verification result (IV).

9. (canceled)

10. The method according to any one of the claims 8-9, wherein the verification result (IV) is at least partly based on contextual data, the contextual data preferably including one or more of a number of verifying requests made in a predefined time interval, a total number of verifying requests made, a time of a verifying request, a geographical location of the integrated circuit, a geographical location from where a verifying request is made.

11. The method according claim 8, further comprising transmitting the verification result (IV) from the centralized code registration system (3) to the verifying device (5) and/or the end node device (2) comprising transmitting the identifier (CID) to the centralized code registration system (3) via the verifying device (5).

13. (canceled)

14. (canceled)

15. (canceled)

16. The method according to claim 1, wherein the identification code (AID) has been activated in the first data storage (31) upon implementation, e.g. upon validation of a lithographic writing operation of the identifier (CID) in the integrated circuit (4).

17. The method according to claim 1, wherein the identification code (AID) is provided unique, e.g. by using an enumeration algorithm, and therefore used only once amongst a plurality of integrated circuits (4).

18. (canceled)

19. A method of manufacturing an integrated circuit (4), the integrated circuit (4) for use in a method according to any one of the claims 1-18, the method comprising: generating (100) an identification code (AID) for an operator code (OC) in wherein the identification code (AID) is a bit-code of predefined length; storing (101), in a first storage (31) of the code registration system (3), the identification code (AID); storing (102), in a data storage (32) of the code registration system (3), an operator key (OK) associated with the operator code (OC); generating a chip identifier (CID) using a mathematical operation (107) on the identification code (AID) using the operator key (OK); and providing the identifier (CID) and the operator code (OC) to an IC manufacturing facility, where the identifier (CID) and the operator code (OC) are hard-coded in the integrated circuit (4).

20. The method of manufacturing according to claim 19, in which the storage (32) of the code registration system (3) and the associated operator key (OK) is a second storage (32), separate from the first storage (31).

21. A method of manufacturing according to claim 19, in which the registration system is a centralized registration system (3).

22. A centralized code registration system (3), comprising: a first data storage (31) configured to store the identification codes (AIDs); and a second data storage (32) configured to store operator keys (OKs) associated with an operator code (OK), wherein the second data storage (32) is separate from the first data storage (31), wherein the identification codes (AIDs) are associated with integrated circuits (4), wherein each integrated circuit (4) comprises an identifier (CID) and the operator code (OC), and wherein an identification code (AID) of an integrated circuit (4) is obtainable from a mathematical operation (103) on the identifier (CID) using an operator key (OK) from the second data storage (32).

23. A centralized code registration system according to claim 22, arranged to perform the method according to any one of the claims 1-18.

24. A system according to claim 22, involving a set of integrated circuits, within which, an integrated circuit (4) comprising an identifier (CID) and an operator code (OC) hard-coded in the integrated circuit (4), wherein the identifier (CID) is a bit-code of predefined length, the integrated circuit (4) for use with the centralized code registration system (3) according to any one of the claims 19-20.

25. A system according to claim 24, wherein the integrated circuit (4) comprises a first read-only register (41) comprising the identifier (CID), a second read-only register (42) comprising the operator code (OC), and an interface (MISO, RFID) for reading the identifier (CID) and the operator code (OC) from the first (41) and second (42) read-only registers and outputting the identifier (CID) and the operator code (OC).

26. (canceled)

28. (canceled)

29. A method according to claim 1, with generating and authenticating guaranteed unique identifier codes (CID) as may be used for identifying and authenticating assets comprising an integrated circuit, the method comprising generating guaranteed unique identifiers (AID) in a centralized code registration system (3); storing the generated identification codes (AID) within a data storage (31a-31c); associating each identification code (AID) with a unique identifier (CID) to be used for identifying an integrated circuit, by applying a bijective algorithm; authenticating an identifier (CID) by inversely calculating an identification code (AID) from an identifier (CID) based on said algorithm.

30. A system according to claim 22, comprising a centralized system provided with a computer based algorithm for executing the method according to claim 29.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Embodiments will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbols indicate corresponding parts, and in which:

[0059] FIG. 1 shows an exemplary data storage configuration in a centralized code registration system according to an aspect of the invention;

[0060] FIG. 2 shows another exemplary data storage configuration in a centralized code registration system according to an aspect of the invention;

[0061] FIG. 3 shows another exemplary data storage configuration in a centralized code registration system according to an aspect of the invention;

[0062] FIG. 4 shows and abstract representation of an exemplary IC according to an aspect of the invention;

[0063] FIG. 5 shows and exemplary IC according to an aspect of the invention;

[0064] FIG. 6 shows an exemplary flow chart of a method of manufacturing an integrated circuit according to an aspect of the invention;

[0065] FIG. 7 shows an exemplary flow chart of a method of handling identification codes of integrated circuits according to an aspect of the invention; and

[0066] FIG. 8 shows an exemplary architecture of a system wherein the invention may be applied.

[0067] The figures are intended for illustrative purposes only, and do not serve as restriction of the scope or the protection as laid down by the claims.

DESCRIPTION OF EMBODIMENTS

[0068] FIG. 1 shows an exemplary centralized code registration system 3, such as may e.g. be implemented in a manner known per se using a server. The centralized code registration system 3 includes a first data storage 31 and a second data storage 32. The data storages are typically implemented as databases. The first data storage 31 may store the identification codes AIDs of ICs, also called asset identifier AID. The second data storage 32 may store one or more operator keys OKs.

[0069] A mathematical operation performed in the centralized code registration system 3 may generate an identifier of an IC from an identification code AID using an operator key OK, and vice versa. Identifiers are stored in the ICs and may thus be verified against identification codes AIDs stored in the first data storage 31. Herein, the mathematical operation may be a look-up table operation.

[0070] The operator key OK may be associated with an operator code OC. This allows identification codes AIDs to be reused for different operator codes, by applying different operator keys depending on the operator code.

[0071] The first data storage 31 need not be highly secured. In fact, the identification codes AIDs cannot be linked to an IC, i.e. to a chip identifier CID of the IC, as long as the mathematical operation and/or the operator keys OKs are secured. The second data storage 32 and the mathematical operation are preferably secured, e.g. using cryptographic data storage, secured communication protocols and/or secure execution environments.

[0072] The centralized code registration system 3 may include an authentication service, enabling an authentication request for an IC to be received and processed. The identifier of an IC may then be received by the authentication service and verified against the stored identification codes AIDs, using the mathematical operation to obtain the identification code of the identifier.

[0073] The centralized code registration system 3 may include a code generation service, enabling identification codes and identifiers to be generated and prepared for implementing in ICs. The latter may include the generation of GDSII files for use by an IC manufacturing foundry, where the identifier may be written into a read only memory of the IC.

[0074] Thus, metadata related to a chip identifier CID may be separated from the chip identifier CID. An operator may see a chip identifier CID, without knowing to which asset record, i.e. asset identifier AID this chip identifier CID belongs. The two can preferably only be connected via and by the second data storage 32, e.g. a second secure database, effectively constituting a vault as it were. Rather than revealing the relation between the two identifiers CID and AID, or the combination thereof, the secure database or vault may after having established a relation, output a verification result, e.g. in the form of a ‘yes’ or a ‘no’. In this manner neither the operator, nor the secure database or a verifying functionality provider will ever become aware which chip identifier CID belongs to which asset identifier AID as long as the two are maintained separate and the secure database is effectively maintained secure in a manner known per se. The effect of the use of two separate data storages 31, 32, e.g. two separate databases, with one of which possibly being secure for holding a secret look-up table or operator key, is not only that asset holders may effectively and relatively economically rely on a centralized authentication service. The latter in turn may hence be used as part of a set of security measures. With such a system and method of authenticating assets, security functionality may attractively be shifted from end nodes to a centralized service system, implying that neither security measures nor security costs need to be distributed over each of these end nodes. Rather, the end nodes in such a system, provided that these are provided unchangeable, e.g. through hard coding thereof in a chip, may be provided with a simple electronically readable code, to the extent that it may even simply be maintained publicly readable.

[0075] A centralized code registration system 3a may store identification codes AIDs for different operator codes OCs. An example hereof is shown in FIG. 2, where data storage 31a, data storage 31b and data storage 31c are each similar to first data storage 31 and each store identification codes AIDs for different operator codes OCs. In the example of FIG. 2 the operator codes OCs are stored associated with the operator keys OKs in the second data storage 32a.

[0076] The operator codes OCs may be stored in a separate database 33, such as shown in FIG. 3. The operator codes OCs in the separate database 33 and the operator keys OKs stored in second data storage 32b may be associated using known database structures, e.g. using database links or any other data structure. The separate database 33 may be part of or external to a centralized code registration system 3b.

[0077] FIG. 4 is an abstract representation of an IC, wherein an operator code OC and an identifier CID have been stored in a memory, typically a read-only memory. The identifier CID is preferably unique amongst all ICs for a same operator code OC, but it is possible to use the same identifier in different ICs for a different operator code. Identifiers CID may be reused for different operator codes OC.

[0078] FIG. 5 shows an exemplary IC 4. The IC 4 may include one or more ROM registers 41, 42, e.g. a 32-bit (4×8) ROM 41 embedding a 32-bit operator code and a 128-bit (16×8) ROM 42 embedding a 128-bit identifier. The IC 4 may include an interface, here embodied in the form of a Serial Peripheral Interface (SPI) and control logic for outputting the identifier on a request received via the Control logic. The IC 4 may include voltage inputs, such as VDDD, VSSD, VDDIO and VSSIO. The IC 4 may further include signal inputs, such as MOSI (Master Output Slave Input), SCLK (Serial CloCK) and CSN (Chip Select Not). The IC 4 may further include a signal output, such as MISO (Master Input Slave Output) or any other output such as an RFID output.

[0079] It will be understood that the IC 4 is not limited to having SPI-based interfaces. Other non-limiting examples of interfaces that may be used in the IC 4 are serial interface like I2C or I2S, 3-wire, 1-wire, USB or a classical 13.56 MHz RF-ID contactless interface. Moreover, it will be understood that the IC 4 is not limited to 4×8 and 16×8 ROM registers and that any other read-only register may be used for storing operator codes and identifiers of any bit length. It is possible to store the operator code OC and the identifier CID in a single memory, e.g. a single ROM of 160 bits.

[0080] In FIG. 6 a flow chart is shown of an exemplary method performed in a centralized code registration server 3, 3a, 3b for generating identification codes AIDs and implementing the corresponding identifiers CIDs in the ICs. The steps in the left column of FIG. 6 may be performed in a less secure part of the centralized code registration system 3. The steps in the right column of FIG. 6 are preferably performed in a secured part of the centralized code registration system 3.

[0081] In step 100 one or more identification codes AIDs are generated which, using the computing means associated with controlling a storage 31a-31c is performed in a deterministic manner, i.e. guaranteeing the uniqueness of an AID as generated. This step 100 typically is the first time that the identification codes AIDs are generated for a specific operator code OC. Hence the system of the invention guarantees that AID values are at least unique within a set to be associated with an operator code OC. In step 101 the identification codes AIDs are stored in the first data storage 31. The identification codes AIDs may be used later when verifying the authenticity of ICs based on the identifier of the IC, which is depicted by the roman I (see also FIG. 7).

[0082] For the generated identification code AID an identifier to be stored in the IC is to be generated. Hereto the identifier is requested and in step 104 the operator key OK for the operator code OC is obtained from a data storage, which as indicated here and according to preference is the indicated second data storage 32. One or more operator keys OKs for the operator code OC may have been generated and stored in step 102. The operator keys OKs may be used later when verifying the authenticity of ICs based on the identifier of the IC, which is depicted by the roman II (see also FIG. 7).

[0083] In step 107 a mathematical operation c may be performed on the identification code AID to obtain the identifier CID. This is depicted as ε(AID)=ID. The mathematical operation may use the operator key OK, for example as a cryptographic encryption key in an AES-based cryptographic mathematical operation.

[0084] The thus obtained identifier CID and the operator code OC may be provided to an IC manufacturing foundry. Hereto the CIDs for the AIDs may be received. This receipt may be at another place than the place of request, e.g. a secure box at a lithographic machine writing a chip. There may be an interruption in the linking process by request to and operation of a second database in the right-hand side column.

[0085] For example, a GDSII file may be generated based on the identifier CID and the operator code OC, which GDSII file may be provided to the foundry in step 108. In step 106 the GDSII file, or any other data file enabling the foundry to create the IC, may be used to write the identifier CID and the operator code OC to a memory portion of a wafer forming a part of an IC 4.

[0086] The identifier CID and operator code IC stored in the IC 4 may be used later when verifying the authenticity of ICs, which is depicted by the roman III (see also FIG. 7).

[0087] In an embodiment, to generate a per-chip unique—e.g. 128-bit—identifier CID an intermediate encoding may be used. First, every operator that intends to encode ICs may receive a unique and secret operator key OK, e.g. a 128-bits or any other bit length key. The operator key OK is preferably kept in a secure location such as the second data storage 32, for example in a central software vault processing center (e.g. HSM) of the centralized code registration system 3. All computations that require encoding or decoding with this operator key OK preferably only take place within this central vault. If now a series of n ICs require an identifier CID, a list of n numbers may be generated, in its most simple form just the list 1, 2, . . . , n−1, n. These numbers may be or represent the identification codes AIDs to be stored in the first data storage 31. This list may be passed to a vault processing unit, which encodes encrypts these n numbers using the mathematical operation based on the operator key OK. This preferably happens inside the vault, and preferably only the list of identifiers CIDs thus obtained is received as output from the vault. The CIDs—e.g. ID1, ID2, . . . , IDn of 128 bits, or any other length, each—that may be processed into a GDSII file, transmitted to a mid-end fab and written on the n ICs.

[0088] Although stealing (essentially copying) of such a series of CIDs doesn't give any advantage to a hacker, it would be annoying and therefore the transmission of the n identifiers CIDs from the vault to the factory may be secured using e.g. standard AES encryption techniques.

[0089] Instead of every IC being coded individually, an operator may e.g. decide to code groups of ICs with the same CID per batch, per production day, per production location, etcetera. Of course, this reduces the identification level to such a group, but for fast turnover products (fresh food, beer bottles) this might be more than enough.

[0090] Once produced the ICs carrying their—possibly unique—identifier CID may be physically attached to a device they are expected to identify. This can be a tag, a bank note, another IC in a multi-chip package, a PCB board, module or complete device or machine, all to be decided by the operator. At any moment the identifier CID of such a device can be read, using the interface provided by the IC.

[0091] In FIG. 7 a flow chart is shown of an exemplary method performed in a centralized code registration server 3, 3a, 3b for handling identification codes AIDs of ICs 4. The steps in the left column of FIG. 7 may be performed in a less secure part of the centralized code registration system 3. The steps in the right column of FIG. 7 are preferably performed in a secured part of the centralized code registration system 3.

[0092] An identifier CID and operator code OC may be received from an IC in the centralized code registration server 3, e.g. via the authentication service shown in FIG. 1. The identifier CID may be verified by checking the identifier CID against the stored identification codes AIDs in the first data storage 31. Hereto a request of the validity of the identifier CID for the received operator code OC may be transmitted to a secured part of the centralized code registration system 3.

[0093] In step 104 the operator key OK associated with the operator code OC may be retrieved from the second data storage 32. In step 103 a mathematical operation ε.sup.−1 may be performed on the identifier CID to obtain the identification code AID. This is depicted as AID=ε.sup.−1(CID). The mathematical operation may use the operator key OK, for example as a cryptographic decryption key in an AES-based cryptographic mathematical operation.

[0094] In step 105 the thus obtained identification code AID may be verified against the stored identification codes AIDs to determine its authenticity. Indirect, the authenticity of the identifier CID may thus be verified. The result of the verification may be output as a verification result IV.

[0095] FIG. 8 shows an exemplary authentication system 1 wherein the centralized code registration system 3 may be used. The authentication system 1 may include one or more end node devices 2 each containing an IC 4 embedded with an identifier CID and an operator code OC. The authentication system 1 may further include a verifying device 5 for requesting the identifier CID and the operator code OC from the end node device 2 and ultimately from the IC 4. The authentication system 1 includes the centralized code registration system 3, such as shown in FIG. 1.

[0096] The IC 4 is typically linked to an asset. The asset is e.g. an electronic device like a peripheral device, an industrial device or a medical device, or any taggable good like packing material or consumer goods. The assets have in common that they are identifiable by a combination of the identifier CID and the operator code OC. It is possible that the end node device itself is the asset.

[0097] Querying of an IC 4 for its identifier may result in sending the identifier CID and the operator code OC to the centralized code registration system 3, and the centralized code registration system 3 providing a verification result indicative of an authentication result. The identifier CID and the operator code OC are typically transmitted to the centralized code registration system 3 after a request from the verifying device 5. The identifier CID and the operator code OC may be transmitted from an end node device 2 to the centralized code registration system 3 via the verifying device 5 and/or via any other intermediate communication device (not shown). The centralized code registration system 3 may then verify the identifier CID against stored identification codes AIDs to obtain a verification result. The verification result may be communicated to the verifying device 5, the end node device 2 or any other computer system.

[0098] In case an identifier CID and an operator code OC are used in a non-authorized combination, the centralized registration system 3 may return a negative verification result indicative of a failed authentication. Alternatively or additionally, in case of a negative verification result the centralized registration system 3 may block the identification code from any future use, resulting in future verification results for this identification code to be negative by default.

[0099] An identifier CID may be generated before or during the production process of ICs 4. This is illustrated in FIG. 8 as the code generation service that generates and stores the identification codes AIDs in the first data storage 31 of the centralized registration system 3. Identifiers CIDs generated from the identification codes AIDs using the mathematical operation may be transmitted to the IC Manufacturing (Foundries), for example in the form of GDSII files for writing memory portions 41,42 of the IC 4.

[0100] The ICs 4 are preferably manufactured in a cost-efficient manner, typically involving a lithography back-end processes followed by a so-called mid-end lithographic process step. In the back-end process the dies on a wafer 5 may be prepared to a common design, e.g. in a CMOS based, front end lithographic operation typically applying masked lithographic equipment. The front-end operation may be used to write the operator code OC to the wafer, as the same operator code OC is typically used multiple times. In the subsequent mid-end process step, a wafer based maskless lithographic operation may manipulate a predefined CMOS based IC for encoding each die of a wafer with the identifier CID— possibly a unique identifier—generated by the code generation service. The operator code OC may be written in the mid-end processing step instead of the front-end processing.

[0101] The implementation of the identifier CID in the mid-end lithographic process step advantageously allows commonly known and cost-effective front-end processes to remain unmodified. The mid-end lithographic process step may be integrated as a maskless lithography operation, which is found to be very suitable for uniquely encoding IC based electronic devices. In such a set-up maximum advantage may be taken from cost reduction as has over the past decades been effected in so called front-end chap manufacturing fab's or so-called foundries.

[0102] Advantageously, in the authentication system 1 according to the present invention, most or all security may be transferred to the centralized code registration system 3, which is preferably implemented in the cloud. Every application system, e.g. retail, may have its own first data storage 31 with the registered identification codes AIDs of ICs 4 that have been produced and as many associated data labels as are required (dates, type of product, manufacturer, etcetera). These data labels may be stored, together with or associated with operator codes OCs in the first data storage 31 or any other data storage. When an IC 4 is queried for its identifier CID, the identifier CID may be sent to the centralized code registration system 3 for verification of its validity, possibly with a simple “Yes” (or other indication of a positive verification result) or “No” (or other indication of a negative verification result) as outcome.

[0103] The centralized code registration system 3 may take the context of verification requests into account in processing the current verification request. Examples hereof are a number of requests made in a predefined time interval, the total number of requests made, time of the request, location of the request, and etcetera. Contextual information may be transmitted as contextual data from the verifying device 5 to the centralized code registration system 3 and/or generated in the centralized code registration system 3. Part or all of the contextual data may be generated in the end node device 2, 2a-2d.

[0104] Hackers may want to try to replicate or falsify end node devices 2 or ICs 4. Duplication of an end node 2 with IC 4 in an authentication system 1 no longer makes any sense, because this may immediately be detected, and the identification code AID and thereby the IC 4 be blocked for use. Although identifiers CIDs can in principle be public—there is nothing to hide—they may be encrypted during communication with the centralized code registration system 3. In other words, hacking an end node 2 or IC 4 does not make any sense, all security processing takes place in the centralized code registration system 3. The IC 4 thus acts as a hardware anchor (e.g. to attach the code to a physical device) in an otherwise centralized secure system 3. So, although the end nodes 2 and ICs 4 could be hacked (e.g. copied), the system 1 remains secure.