NL2025695B1

NL2025695B1 - Centralized handling of ic identification codes

Info

Publication number: NL2025695B1
Application number: NL2025695A
Authority: NL
Inventors: Anthonius Henricus Juffermans Casparus; Mathias Doumen Jeroen; Werner Hooijmans Pieter
Original assignee: Sandgrain B V
Priority date: 2020-05-28
Filing date: 2020-05-28
Publication date: 2022-01-13

Abstract

A method for handling identiﬁcation codes (AIDS) of integrated circuits in a centralized code registration system (3), the method comprising: storing the identiﬁcation codes (AIDS) in a 5 ﬁrst data storage (31), storing operator keys (OKs) associated with an operator code (OC) in a second data storage (32), wherein the second data storage (32) is separate from the ﬁrst data storage (31), wherein the identiﬁcation codes (AIDs) are associated with integrated circuits, wherein each integrated circuit comprises an identiﬁer and the operator code (OC), Wherein an identiﬁcation code of an integrated circuit is obtainable from a mathematical operation on 10 the identiﬁer using an operator key (OK) from the second data storage (32). [+FIG. 1]

Description

-1-

CENTRALIZED HANDLING OF IC IDENTIFICATION CODES TECHNICAL FIELD

[0001] The present invention relates to a method for handling identification codes of integrated circuits in a centralized code registration system, a method of manufacturing an integrated circuit for use with a centralized code registration system, a centralized code registration system, an integrated circuit for use with a centralized code registration system, and use of an integrated circuit with a centralized code registration system.

BACKGROUND ART

[0002] Over the last three decades, integrated circuit (IC)-based identification and security- based technologies and associated devices have reached a broad set of applications. Well- known examples are public transport ticketing, smart card conditional access systems for TV subscriptions, SIM cards in mobile phones, electronic passports, banking or credit cards, and labeling for tracking and managing logistic flows and transport. Volumes associated with these applications run in the billions of ICs per year. However, there are potentially many more applications that could use these technologies, that could further multiply these volumes by several orders of magnitude, so indeed hundreds of billions or trillions of IC’s. So far this is not happening for two fundamental reasons: security and cost.

[0003] A main problem in the world of identification and security is hacking. Existing identification and security applications are typically built around so-called secure microcontrollers. Microcontroller units (MCU) are required for functions like authentication or security key generation, and storing of the relevant data in such a way that it is not accessible for intruders. Because MCUs typically operate under an operating system and a specific program, e.g. firmware program, to execute the required functions, they are typically a combined hardware (HW) and software (SW) solution.

[0004] Known systems have as a major drawback that they can be hacked. This in practice means reverse engineering the function of the device by analyzing its HW and/or SW behavior, resulting in the discovery of e.g. a secret (cryptographic) key as typically required in these known systems and stored in a memory. In a worst-case scenario, the memory content of the device is altered, e.g. by increasing the amount of credits on a transit card or changing the balance on a bank card. Although suppliers of these ICs and systems implement measures to make their ICs robust to hacking, in the end most systems are vulnerable and can be hacked, albeit at often high technological effort.

[0005] The other problem with existing security solutions is related to cost. With high- volume applications of IC related security solutions, an obvious requirement is to have the IC cost as low as possible. Today’s ICs typically cost a few dollar cents, which multiplies by a factor four for the final assembled module or package sales price. Elements that increase the IC cost are the MCU infrastructure and the programmable on-chip memories. Typical 40 elements that increase the IC cost are: - Secure MCUs are expensive, either as in-house development or as purchased IP, e.g. as ARMT™ Secure Cores;

2- - MCUs are complex functions, and although the core is relatively small in advanced technology, it requires all kind of peripheral functionality to make it work properly: communication busses, memories (usually a combination of multiple specific memories, like RAM, ROM, Flash), start-on and advanced power management circuitry. So, the total function is much bigger, and requires serious design effort; - The simplest identification products don’t require re-programmable memories or keys. But even so, during manufacturing of the IC the code needs somehow be written in its memory. In most cases thus is done using One Time Programmable Read Only Memories (OTP-ROM), but these IP blocks are big, and require high voltage supply, making them large and thus expensive; - More complex identification and security ICs have programmable key or data storage, which requires re-programmable Non-Volatile Memory (NVM), often also referred to as flash memory. But flash memories are expensive technology features, requiring — depending upon the size of the baseline CMOS node — 10 to 12 additional mask layers in production. This can be a cost adder of typically 35 to 30% compared to non-flash baseline technology wafer cost; - Identification and security ICs have a complex Back End (BE) process in the assembly and packaging fab, since every ICs requires pre-programming with its secure SW and — in case of non-programmable ICs — the embedded keys or identifiers.

[0006] With high volumes of IC’s there is a need for a cost effective yet secure solution for applying identification codes to the IC’s. Moreover, the identification codes should be verifiable.

SUMMARY OF THE INVENTION

[0007] The present invention aims to provide a centralized solution for managing and verifying identification codes of integrated circuits (IC’s). The present invention is particularly useful with, but not limited to, large number of IC’s each having a unique identification.

[0008] The present invention enables identification and security solutions that are much cheaper at the high-volume customer or user end of the chain, and shift complex security functionality away from those end nodes.

[0009] According to an aspect of the invention a method is proposed for handling identification codes (also called asset identifiers) of integrated circuits in a centralized code registration system. The method can comprise storing the identification codes in a first data storage. The method can further comprise storing one or more operator keys associated with an operator code in a second data storage. Herein, storing means the action of putting data in a data storage or having data stored in a data storage available for use. The second data storage can be separate from the first data storage. The identification codes can be associated with integrated circuits. Each integrated circuit can comprise an identifier (also called a chip 40 identifier) and the operator code. An identification code of an integrated circuit can be obtainable from a mathematical operation on the identifier using an operator key from the second data storage, wherein the operator key can be associated with the operator code.

-3-

[0010] According to an aspect of the invention a centralized code registration system is proposed. The centralized code registration system can comprise a first data storage configured to store the identification codes. The centralized code registration system can further comprise a second data storage configured to store operator keys associated with an operator code. The second data storage can be separate from the first data storage. The identification codes can be associated with integrated circuits. Each integrated circuit can comprise an identifier and the operator code. An identification code of an integrated circuit can be obtainable from a mathematical operation on the identifier using an operator key from the second data storage.

[0011] Inthe first data storage the identification codes of each of the integrated circuits are stored. In each of the integrated circuits an identifier is stored. In the centralized code registration system, the identifiers of the integrated circuits can be linked to the identification codes stored in the first data storage using the mathematical operation, which is depending on the operator key stored in the second data storage. The identifier may be readable to anyone, i.e. not requiring any security means to prevent the identifier from being read from the integrated circuit. Although security measures are possible, the identification codes may be stored in the first data storage without a need for securing the identification codes from being hacked, 1.e. read unauthorized. The second data storage is typically a highly secured data storage to prevent the operator keys from being accessible unauthorized. Without the operator key an identifier of an integrated circuit cannot be linked to an identification code stored in the first data storage, thereby creating a secured centralized solution for managing and verifying identification codes of integrated circuits.

[0012] A chip identifier may represent an anonymized version of an asset identifier,

[0013] The mathematical operation is preferably performed in a secured part of the centralized code registration system to prevent the link between an identifier and an identification code being exposable to hackers. The mathematical operation may be performed in a same secured computer environment where the second data storage is a part of.

[0014] In an embodiment the mathematical operation may be implemented as or make use of a look-up table. The chip identifier may e.g. be stored in a look-up table and/or obtained from a look-up table using the mathematical operation. The mathematical operation may e.g. comprise storing and/or obtaining the chip identifier from a look-up table. The second data storage may be implemented as a look-up table.

[0015] The operator keys are associated with an operator code. Hereto the operator code may be stored together with the operator keys in the second data storage. Alternatively, the operator code may be stored in a separate data storage and associated with the operator keys using known technologies, such as using database keys or database links. The operator code may be stored in a data storage of the centralized code registration system or in a database external to the centralized code registration system.

40 [0016] The first data storage, the second data storage and/or the separate data storage are typically based on computer databases.

4-

[0017] The following are embodiments of the method for handling identification codes and the centralized code registration system.

[0018] In an embodiment the centralized code registration system can be configured to obtain the operator key from the second data storage based on the operator code and perform the mathematical operation on the identifier using the operator key as a cryptographic key.

The mathematical operation is e.g. an AES based decryption operation.

[0019] This advantageously enables identification codes to be reused for different operator codes, resulting in different identifiers in the integrated circuits if the operator key is different for different operator codes. This enables e.g. different batches of integrated circuits to be assigned to different clients, different product groups or any other differentiation, while having assigned the same identification codes to the integrated circuits.

[0020] In an embodiment the second data storage 1s a secure data storage. A security protocol can be used for accessing the second data storage. Preferably the security protocol comprising an encrypted data communication with the second data storage and/or the operator key being stored in the second data storage in an encrypted format requiring decryption before use in the mathematical operation.

[0021] In an embodiment the identifier and the operator code can be hard coded in a read- only memory of the integrated circuit. The identifier and the operator code can be stored in two separate read-only memories. Alternatively, the identifier and the operator code can be stored in the same read-only memory, possibly as a single binary value.

[0022] In an embodiment the centralized code registration system can be configured to verify the identification code obtained from the mathematical operation against the identification codes stored in the first data storage. Thus, it may be established if the identifier of the integrated circuit is valid.

[0023] In an embodiment a verifying device can request the identifier from the integrated circuit via an end node device. The end node device can read the identifier and the operator code from the integrated circuit and transmit the identifier and the operator code to the centralized code registration system. The centralized code registration system can obtain the identification code from the identifier by performing the mathematical operation on the identifier based on the operator code. The centralized code registration system can verify the obtained identification code against the stored identification codes to obtain and output a verification result.

[0024] In an embodiment the verification result can be indicative for a match of the obtained identification code in the stored identification codes.

[0025] In an embodiment the verification result can be 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.

40 [0026] In an embodiment he verification result can be transmitted from the centralized code registration system to the verifying device and/or the end node device.

-5-

[0027] In an embodiment the identifier can be transmitted to the centralized code registration system via the verifying device.

[0028] In an embodiment the centralized code registration system can register the identification code as being invalid in case of a negative verification result, resulting in future verification results for this identification code to be negative by default.

[0029] In an embodiment the integrated circuit can comprise a first read-only register comprising the identifier, a second read-only register comprising the operator code, and an interface for reading the identifier and the operator code from the first and second read-only registers and outputting the identifier and operator code. It is possible that the first read-only register and the second read-only register are the same.

[0030] In an embodiment the functionality of the integrated circuit can be limited to providing the identifier and the operator code upon request. This allows the integrated circuit to be relatively simple, not requiring an MCU. The integrated circuit may be a part of another integrated circuit, possibly an MCU.

[0031] In an embodiment the identification code can be activated in the first data storage upon implementation, e.g. upon validation of a lithographic writing operation of the identifier in the integrated circuit.

[0032] In an embodiment the identification code can be unique and therefore used only once amongst a plurality of integrated circuits. In this embodiment an identification code may be reused for different operator codes, while being unique for one operator code.

[0033] In an embodiment the centralized code registration system can be implemented as a cloud service.

[0034] In an embodiment the first data storage and the second data storage can be implemented as separated cloud services.

[0035] According to an aspect of the invention a method of manufacturing an integrated circuit 1s proposed. The integrated circuit is for use in a method for handling identification codes as described above. The method can comprise generating an identification code in a centralized registration system. The identification code is preferably a bit-code of predefined length and associated to an operator code. The method can further comprise storing, in a first storage of the centralized code registration system, the identification code. The method can further comprise optionally storing, in a second data storage of the centralized code registration system, an operator key associated with the operator code. The second data storage can be separate from the first data storage. The method can further comprise generating an identifier using a mathematical operation on the identification code using the operator key. The method can further comprise providing the identifier and the operator code to an IC manufacturing facility. The identifier and the operator code can be hard-coded in the integrated circuit.

[0036] The identifier and the operator code may be hard-coded in a single read-only memory. The identifier and the operator code may be hard-coded in two separate read-only 40 memories.

[0037] According to an aspect of the invention an integrated circuit is proposed comprising an identifier and an operator code hard-coded in the integrated circuit. The identifier is

-6- preferably a bit-code of predefined length. The integrated circuit is for use with a centralized code registration system as described above.

[0038] In an embodiment the integrated circuit can comprise a first read-only register storing the identifier. A second read-only register can comprise the operator code. The 5S integrated circuit can comprise an interface for reading the identifier and the operator code from the first and second read-only registers and outputting the identifier and the operator code.

[0039] In an embodiment the integrated circuit can comprise an SPI (Serial Peripheral Interface) and control logic for obtaining the identifier from the first read-only register on a request received via the control logic. The integrated circuit can further comprise one or more voltage inputs. The integrated circuit can further comprise one or more signal inputs. The integrated circuit can further comprise a signal output for outputting the identifier.

[0040] In an embodiment the integrated circuit can be one of: miniature SO8-packaged, SSOP8-packaged, TSSOP8-packaged or SWLCSP-packaged for board-level applications; RF-ID compatible; integrated in a multi-chip package; integrated as IP block in a larger IC.

[0041] According to an aspect of the invention a use of an integrated circuit as described above is proposed, for use with a centralized code registration system as described above.

[0042] There is no security vulnerability at end node devices through the simple use of the identifier stored in the IC. Cost can be reduced since authentication means are performed centralized. No authentication measures are needed at the end node device.

[0043] The invention is scalable over orders of magnitude, from tens to billions of nodes. The availability of coding space is no problem at all (e.g. 10°® in case of 128-bit identifiers) and the end nodes can be so small and cheap that they allow deployment in very large numbers. The invention allows putting individual electronic identifiers at a level not attainable today. Think of tagging all individual products in a supermarket or store, all elements in complex logistics chains (e.g. aircraft or car assembly) or all ICs (by embedding an IC inside a larger IC package).

[0044] Clients of the centralized code registration system can choose at which level they want to uniquely code their products. E.g. high turn-over goods (beer bottles or cans, food) could be coded by production batches with codes that have a time-limited validity. This is yet another scalability factor of the present invention.

[0045] The identifiers linkable to the identification codes may be used as a connected electronic bar code. But whereas todays printed bar codes are identical for all instantiations of the same product, the identifiers in the ICs are electronic and can, if chosen so, be different at individual product level. The usage of the identifiers in the ICs may be tracked through a cloud connection, allowing for “big data” analysis and possible interaction with the end node device to take security measures.

[0046] The centralized code registration system may be distributed among multiple servers or multiple networked computers while functioning as a centralized system.

40 [0047] The system enables owners/users to set up a secure data information system on the use of their products.

<7-

[0048] Aspects and embodiments of the invention are further described in the following description and in the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0049] 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:

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

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

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

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

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

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

[0056] 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

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

[0058] 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

[0059] FIG. 1 shows an exemplary centralized code registration system 3. 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.

[0060] 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.

[0061] 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. 40 [0062] 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

-8- and the mathematical operation are preferably secured, e.g. using cryptographic data storage, secured communication protocols and/or secure execution environments.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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 314, data storage 3 1b and data storage 3 Ic 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.

[0067] The operator codes OCs may be stored in a separate database 33, such as shown in 40 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

0.

database links or any other data structure. The separate database 33 may be part of or external to a centralized code registration system 3b.

[0068] 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 same operator code. Identifiers CID may be reused for different operator codes OC.

[0069] FIG. 5 shows an exemplary IC 4. The IC 4 may include one or more ROM registers 41, 42, e.g. a 32-bit (4x8) ROM 41 embedding a 32-bit operator code and a 128-bit (16x8) 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.

[0070] 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 128, 3-wire, 1-wire, USB or a classical 13,56MHz RF-ID contactless interface.

Moreover, it will be understood that the IC 4 is not limited to 4x8 and 16x8 ROM registers and that any other read-only register may be used for storing operator codes and identifiers of any bit length. It 1s possible to store the operator code OC and the identifier CID in a single memory, e.g. a single ROM of 160 bits.

[0071] 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.

[0072] In step 100 one or more identification codes AIDs are generated. This is typically the first time that the identification codes AIDs are generated for a specific 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).

[0073] For the generated identification code AID an identifier to be stored in the IC is to be generated. Hereto the identifier 1s requested and in step 104 the operator key OK for the operator code OC is obtained from the 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 40 the IC, which is depicted by the roman II (see also FIG. 7).

[0074] In step 107 a mathematical operation e may be performed on the identification code AID to obtain the identifier CID. This is depicted as e(AID)=ID. The mathematical operation

-10- may use the operator key OK, for example as a cryptographic encryption key in an AES- based cryptographic mathematical operation.

[0075] 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.

[0076] 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.

[0077] 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).

[0078] 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 77 ICs require an identifier CID, a list of # 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 # 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, ...., ID 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 7 ICs.

[0079] 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 # identifiers CIDs from the vault to the factory may be secured using e.g. standard AES encryption techniques.

[0080] 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.

[0081] 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, 40 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.

-11-

[0082] 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.

[0083] An identifier CID and operator code OC may be received from an IC 1n 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.

[0084] 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 et may be performed on the identifier CID to obtain the identification code AID. This is depicted as AID=¢'(CID). The mathematical operation may use the operator key OK, for example as a cryptographic decryption key in an AES-based cryptographic mathematical operation.

[0085] 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.

[0085] 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.

[0087] 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.

[0088] 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 40 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

-12- result. The verification result may be communicated to the verifying device 5, the end node device 2 or any other computer system.

[0089] 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.

[0090] 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.

[0091] 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 predetined 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.

[0092] 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.

[0093] 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 40 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.

-13-

[0094] 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.

[0095] 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.

Claims

CONCLUSIONS

A method of handling identification codes (AIDs} of integrated circuits {4} in a centralized code recording system (3), the method comprising: storing {101} the identification codes (AIDs} in a first data store (31); storing {102} of one or more operator keys (OKs) associated with an operator code (OC) associated with a second data store (32), the second data store (32) being separate from the first data store (31), the identifiers (AIDs) associated with integrated circuits (4), each integrated circuit (4) comprising an identifier (CID) and the operator code (OC), wherein an identification code (AID) of an integrated circuit (4) is obtainable from a mathematician processing (103) on the identifier (CID) using an operator key (OK) associated with an operator code (OC} from the second data store (32).

The method of claim 1, wherein the centralized code recording system (3) is configured to obtain the operator key (OK) from the second data store (32) based on the operator code (OC) (104) and to perform the mathematical operation (103) on the identifier (CID) using the operator key (OK) as a cryptographic key.

The method of claim 1 or claim 2, wherein the second data store (32) is a secure data store, and wherein the method further comprises using a security protocol to access the second data store, the security protocol preferably being an encrypted data communication with the second data store (32) and/or the operator key (OK) in the second data store (32) is stored in an encrypted format that requires decryption before use in the math operation (103).

A method according to any one of the preceding claims, wherein the identifier (CID) and the operator code (OC) are hard-coded in a read-only memory (41, 42) of the integrated circuit (4).

A method according to any one of the preceding claims, 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 ( 1 ) stored in the first data store (31). AIDS}).

A method according to any preceding claim, further comprising: requesting, by a verification device (5), the identifier (CID) from the integrated circuit (4) via an end node device (2); the end node device {2} reading 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 recording system (3 ); obtaining, by the centralized code registration system (3), the identification code (AID) of 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).

The method of claim 6, wherein the verification result (IV) is indicative of a match of the obtained identification code {AID} in the stored identification codes (AIDs).

A method according to any one of claims 6-7, wherein the verification result (IV) is based at least in part on contextual data, the contextual data preferably comprising one or more of a number of verification requests made in a predefined time interval, a total number of verification requests made, a time of a verification request, a geographic location of the integrated circuit, a geographic location from which a verification request was made.

A method according to any one of claims 6-8, further comprising sending the verification result {IV} from the centralized code recording system (3) to the verification device (5) and/or the end node device {2}.

A method according to any one of claims 6-9, comprising sending the identifier (CID) to the centralized code recording system (3) via the verification device (5).

A method according to any one of claims 6 to 10, further comprising registering, in the centralized code registration system {3}, the identification code as invalid in case of a negative verification result, resulting in future verification results for this identification code being negative by default. are.

A method according to any one of the preceding claims, 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 operator code (OC), includes.

A method according to any one of the preceding claims, wherein the functionality of the integrated circuit (4) is limited to providing the identifier (CID) and the operator code (OC) on request.

A method according to any one of the preceding claims, wherein the identification code (AID) is activated in the first data store (31) during implementation, e.g. upon validation of a lithographic write operation of the identifier (CID} in the integrated circuit (4).

A method according to any one of the preceding claims, wherein the identification code (AID) is unique and therefore used only once within a plurality of integrated circuits (4).

A method according to any one of the preceding claims, wherein the centralized code registration system (3) is implemented as a cloud service.

A method according to any one of the preceding claims, wherein the first data store (31) and the second data store (32) are implemented as separate cloud services.

A method of manufacturing an integrated circuit (4), wherein the integrated circuit (4) is used in a method according to any one of claims 1-16, the method comprising: generating (100) an identification code (AID) in a centralized registration system (3), wherein the identification code (AID) is a bit code of predefined length and is associated with an operator code; storing, in a first storage {31} of the centralized code recording system (3), {101} the identification code (AID); optionally, in a second data store (32} of the centralized code recording system (3), storing {102} an operator key (OK) associated with the operator code (OC), the second data store (32) being separate from the first data storage (31); generating a chip identifier {CID} using a mathematical operation {107} on the identification code (AID) using the operator key (OK); and making available the identifier {CID} and the operator code (OC) to an IC manufacturing facility, where the identifier (CID) and operator code (OC) are hard-coded into the integrated circuit (4).

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

A centralized code registration system according to claim 19, which is adapted to perform the method according to any one of claims 1-17.

21. Integrated circuit {4} comprising an identifier (CID) and operator code (OC) hard coded in the integrated circuit {4}, the identifier (CID) being a bit code of predefined length, the integrated circuit using (4) with the centralized code registration system (3} according to one of the claims 19-

20.

An integrated circuit (4) according to claim 21, 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 operator code (OC) from the first (41) and second (42) read-only registers and for outputting the identifier {CID} and includes the operator code (OC).

An integrated circuit (4) according to any one of claims 21 to 22, comprising: an SPI (Serial Peripheral Interface) and control logic for obtaining the identifier (CID) from the first read-only register (41) on a via the control logic request received; one or more voltage inputs (VDDD, VSSD, VDDIO, VSSIO); one or more signal inputs {MOS}, SCLK, CSN); and a signal output (MISO, RFID} for outputting the identifier (CID).

An integrated circuit {4} according to any one of claims 21 to 23, wherein the integrated circuit (4) is one of: miniature SO8 packaged, SSOP8 packaged, TSSOP8 packaged or 8WLCSP packaged for board-level applications; RF-ID compatible; integrated in a multichip package; integrated as an IP block in a larger IC.

Use of an integrated circuit {4} according to any one of claims 21-24, with the centralized code recording system (3} according to any one of claims 19-20.