Physical unclonable function authentication

Abstract

Proposed concepts thus aim to provide schemes, solutions, concept, designs, methods and systems pertaining to offline physical unclonable function, PUF, authentication of an NFC tag by a master device. In particular, embodiments aim to provide a method for offline PUF authentication of an NFC tag by a master device by storing a plurality of challenge response pairs, CRPs, on the NFC tag itself so that connection to a server storing CRPs is not required. In order to increase the security of this method, the master device also encrypts the challenge of a CRP selected from the stored plurality before communicating the encrypted challenge to the NFC tag. The NFC tag then needs to decrypt the encrypted challenge using the same secret key to be able to provide the correct response such that the master device can authenticate it.

Description

[0001] Physical unclonable function authentication

[0002] FIELD OF THE INVENTION

[0003] This invention relates to the field of physical unclonable functions, PUFs, and more specifically, to the field of offline PUF authentication.

[0004] BACKGROUND OF THE INVENTION

[0005] Some accessories in many electronic consumer products are replaced frequently. For example, smart toothbrushes need their brush heads regularly replaced, and this involves device pairing. The emergence of replica accessories, however, has led to a demand for anticounterfeiting. Unlike general anti-counterfeiting scenarios, consumers often take the initiative to trigger the detection or authentication, e.g., entering an anti-counterfeiting code on an official website to check whether the product is genuine or not.

[0006] For some consumer products, consumers prefer to use non-original accessories considering the often-lower price, however, from the perspective of device manufacturers, there is a need for a mechanism that can detect or authenticate whether the accessories are genuine.

[0007] Over the years, with the popularity of radio-frequency identification (RFID) / near-field communication (NFC) technologies, the cost of tags making use of such technology has fallen and they are now widely used in anti-counterfeiting. However, these kinds of tags have the security problem of being cloned and therefore bypassed. Of course, there are also enhanced solutions, such as adding specific crypto-chips to improve security, but in addition to the increased cost, the deployment and verification process also becomes more complicated.

[0008] A physical unclonable function (PUF) is a physical object that for a given input and conditions (a challenge), provides a physically defined “digital fingerprint” output (a response). The pair is called a challenge response pair (CRP). A PUF is unique because of its physical microstructure which depends on random physical factors introduced during manufacturing. These factors are unpredictable and uncontrollable, which makes it virtually impossible to duplicate or clone the structure. Due to the physical characteristics and low cost of PUF, as well as a mature manufacturing process, it has therefore been introduced as a new type of anti-counterfeiting application with a higher security level. At present, however, most PUF-based authentication solutions are online, i.e., require network access. A server saves a CRP library of the PUF in advance, and then the verifying component can obtain a challenge response from the PUF on an accessory device and compare it with the server-side CRP to achieve authentication. This method can be easily implemented for networked components or with a consumer’s mobile phone, however, many consumer devices are not configured for network access. In addition to this problem, there is no one-to-one correspondence between the master device and accessory, e.g., one toothbrush handle for multiple compatible toothbrush heads, so it is impossible to preset the CRP library in the master device at the production stage.

[0009] SUMMARY OF THE INVENTION

[0010] The invention is defined by the claims.

[0011] According to examples in accordance with an aspect of the invention, there is provided a method for offline physical uncl enable function, PUF, authentication of an NFC tag by a master device.

[0012] The method comprises: receiving NFC data from the NFC tag at the master device, the NFC data comprising a plurality of challenge response pairs, CRPs; selecting, at the master device, a CRP from the plurality of CRPs; encrypting the challenge of the selected CRP, at the master device, with a secret key; communicating the encrypted challenge of the selected CRP from the master device to the NFC tag; decrypting, at the NFC tag, the encrypted challenge with the secret key; generating, at the NFC tag, a response to the challenge; communicating the generated response from the NFC tag to the master device; verifying, at the master device, the generated response based on the response of the selected CRP; and responsive to the generated response being verified, authenticating the NFC tag.

[0013] Proposed concepts thus aim to provide schemes, solutions, concept, designs, methods and systems pertaining to offline physical unclonable function, PUF, authentication of an NFC tag by a master device. In particular, embodiments aim to provide a method for offline PUF authentication of an NFC tag by a master device by storing a plurality of challenge response pairs, CRPs, on the NFC tag itself so that connection to a server storing CRPs is not required.

[0014] In other words, it is proposed that by storing a plurality of CRPs on the NFC tag itself, the master device may have access to CRPs to challenge the NFC tag with while being entirely offline, e.g., not having online access to a server-side CRP library. In order to increase the security of this method, the master device also encrypts the challenge of a CRP selected from the stored plurality before communicating the encrypted challenge to the NFC tag. The NFC tag then needs to decrypt the encrypted challenge using the same secret key to be able to provide the correct response so that the master device can authenticate it.

[0015] By storing a plurality of CRPs on the NFC tag and by using a secret key to encrypt and decrypt the selected challenge, a secure method of PUF authentication is provided that requires neither device to have access to a server storing a plurality of CRPs nor requiring complex processing. A small NFC tag can thus be integrated into an accessory device, such as a toothbrush head, with the toothbrush handle acting as the master device. These devices typically do not have network access and therefore would benefit from a secure offline authentication process so that, for example, consumers are not provided with counterfeit toothbrush heads.

[0016] The inventors have realised that as a single master device may be used to pair with many NFC tags, the plurality of CRPs cannot be pre-saved in the master device at the production stage (as the plurality of CRPs are dependent on the PUF component in each NFC tag, i.e., identifying unique physical characteristics of the NFC tag). A plurality of CRPs can thus be stored in each NFC tag instead and securely communicated to the master device for the master device to then select a CRP and challenge the NFC tag with it. In order to improve security, the challenge can be encrypted with a secret key before communication. The secret key can be preset in the master device (e.g., during the production stage) or the master device can read the secret key (which can also be encrypted) from the NFC tag.

[0017] This invention may be of particular use for authenticating relatively simple devices / objects which do not have networking capabilities. The use of PUF in NFC tags is low cost and easily manufacturable, however, is typically only used in conjunction with online authentication. The present invention thus adjusts the method of authentication to allow NFC tags with PUF components to be authenticated entirely offline and with relatively low computational power.

[0018] Further steps may also be integrated into the proposed method in order to enhance security. In this way, a flexible method for offline PUF authentication of an NFC tag by a master device is provided.

[0019] In some embodiments, the secret key may comprise one of the responses from the plurality of the CRPs. For example, the secret key may be known to both the NFC tag and the master device as the first response of the plurality of CRPs. In this way, a key that is secret to any third parties yet is contained within the plurality of CRPs is provided. The NFC tag then does not need any further storage to store the secret key as well as the plurality of CRPs, and further, the secret key is essentially hidden in plain sight amongst the plurality of CRPs. If the master device knows, for example, that the third response of the plurality of CRPs is the secret key, after receiving the CRPs from the NFC tag, it can then use the secret key to encrypt a chosen challenge without the secret key having to be exactly preset during production. The master device is then capable of authenticating multiple different NFC tags, which will all have different secret keys, without having to pre-save the secret key of each possible NFC tag. Essentially, this feature allows the master device to use a simple secret rule to work out the secret key for each different NFC tag.

[0020] In some embodiments, the NFC data may further comprise the secret key, wherein the secret key has been encrypted with a private key, and wherein a corresponding public key is stored in the master device, and wherein the method may further comprise decrypting the encrypted secret key, at the master device, with the public key. In order to further enhance security of the method, the secret key may be encrypted in the NFC tag. Encrypting the secret key with a private key, wherein the corresponding public key is stored in the master device, allows the secret key to be more highly secure while still allowing the master device to decrypt the secret key, e.g., one of the stored responses.

[0021] In some embodiments, the method may further comprise generating, at the master device, a random string; encrypting, at the master device, the random string with the secret key; communicating the encrypted random string with the encrypted challenge from the master device to the NFC tag; decrypting, at the NFC tag, the encrypted random string with the secret key; prior to communicating the generated response, encrypting the generated response, at the NFC tag, with the random string; and decrypting the generated response, at the master device, with the random string. This adds another layer of protection to the authentication by encrypting communications between the NFC tag and the master device so that they cannot be eavesdropped on and easily understood.

[0022] In some embodiments, any encryption and / or decryption may be performed with a logic-based algorithm. This allows encryption / decry ption to be performed in a relatively computationally simple way so that an NFC tag with only a simple processor can still perform the encryption / decryption steps.

[0023] In some embodiments, the logic-based algorithm may comprise an XOR operation. This is a computationally simple operation for less-powerful processors to perform while still facilitating encryption / decryption.

[0024] In some embodiments, the responses of the plurality of CRPs of the NFC data may be hashed and / or truncated. This may further enhance security while also allowing more CRPs to be stored on the NFC tag. Hashing the responses allows the responses to be protected against plaintext-analysis attacks, e.g., deep learning.

[0025] In some embodiments, the NFC data may further comprise a signature, and wherein the method may further comprise verifying the signature, at the master device, based on a public key stored in the master device, wherein the signature is based on a corresponding private key. This facilitates the secure verification of the NFC data before use of the NFC data, thus providing a more efficient method of potentially ending authentication of a counterfeit device early into the method.

[0026] In some embodiments, selecting a CRP from the plurality of CRPs may comprise selecting a CRP from the plurality of CRPs randomly or pseudo-randomly. This can enhance the security of the method.

[0027] In some embodiments, selecting a CRP from the plurality of CRPs may comprise selecting a CRP from the plurality of CRPs using an algorithm. This can provide an efficient and yet still secure way of selecting a CRP.

[0028] According to another aspect of the invention, there is provided a method for preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device. The method comprises: generating a plurality of CRPs by a PUF component in the NFC tag; generating a secret key; and storing the plurality of CRPs and the secret key in the NFC tag. This allows the master device and NFC tag to be prepared to carry out any embodiment of the proposed method of offline PUF authentication described above.

[0029] In some embodiments, generating a secret key may comprise encrypting one of the responses of the plurality of CRPs with a private key; storing a public key corresponding to the private key in the master device; and storing the encrypted response in the NFC tag, wherein the secret key comprises the response. This allows the NFC tag to store an encrypted response as an encrypted secret key such that the encrypted secret key may be used in an embodiment of the method of authentication described above.

[0030] In some embodiments, encrypting one of the responses may comprise encrypting the response with a private key using an asymmetric algorithm. This is a relatively secure method of encryption.

[0031] In some embodiments, the asymmetric algorithm may comprise an elliptic- curve cryptography series algorithm. This is a form of an asymmetric algorithm capable of being performed with limited computing capabilities and memory capacities. In some embodiments, the method may further comprise storing a secret rule in the master device, wherein the secret rule describes how the secret key can be obtained from the NFC data.

[0032] In some embodiments, the method may further comprise generating a private key and a corresponding public key. This allows the private and public keys respectively to be generated within the method rather than obtaining them externally to the method.

[0033] In some embodiments, the method may further comprise storing the secret key in the NFC tag. In other words, in some embodiments, the NFC data may further comprise the secret key (e.g., in an unencrypted form).

[0034] According to another aspect of the invention, there is provided a computer program comprising code means for implementing the method of any herein disclosed method when said program is run on a processing system.

[0035] According to another aspect of the invention, there is provided a system for offline physical uncl enable function, PUF, authentication of an NFC tag by a master device. The system comprising an NFC tag storing NFC data, the NFC data comprising a plurality of CRPs; and a master device configured to: receive the NFC data from the NFC tag; select a CRP from the plurality of CRPs; encrypt the challenge of the selected CRP with a secret key; and communicate the encrypted challenge of the selected CRP to the NFC tag; wherein the NFC tag is configured to: decrypt the encrypted challenge with the secret key; generate a response to the challenge; and communicate the generated response to the master device; and wherein the master device is further configured to: verify the generated response based on the response of the chosen CRP; and responsive to the generated response being verified, authenticate the NFC tag.

[0036] Thus, there may be proposed concepts for offline physical unclonable function, PUF, authentication of an NFC tag by a master device, and this may be done based on a plurality of CRPs stored in the NFC tag and an encryption / decry ption of a chosen challenge using a secret key.

[0037] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiment s) described hereinafter.

[0038] BRIEF DESCRIPTION OF THE DRAWINGS

[0039] For a better understanding of the invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: Fig. l is a simplified flow diagram of a method for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment;

[0040] Fig. 2 is a flow diagram of a method for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment;

[0041] Fig. 3 is a more in-depth flow diagram of a method for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment;

[0042] Fig. 4 is a simplified flow diagram of a method of preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device according to a proposed embodiment;

[0043] Fig. 5 is a flow diagram of a method of preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device according to a proposed embodiment;

[0044] Fig. 6 is a simplified block diagram of a system for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment;

[0045] Fig. 7 is a simplified block diagram of an example NFC tag comprising a PUF component; and

[0046] Fig. 8 illustrates an example of a computer within which one or more parts of an embodiment may be employed.

[0047] DETAILED DESCRIPTION OF THE EMBODIMENTS

[0048] The invention will be described with reference to the Figures.

[0049] It should be understood that the detailed description and specific examples, while indicating exemplary embodiments of the apparatus, systems and methods, are intended for purposes of illustration only and are not intended to limit the scope of the invention. These and other features, aspects, and advantages of the apparatus, systems and methods of the present invention will become better understood from the following description, appended claims, and accompanying drawings. It should be understood that the Figures are merely schematic and are not drawn to scale. It should also be understood that the same reference numerals are used throughout the Figures to indicate the same or similar parts.

[0050] Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to offline physical unclonable function, PUF, authentication of an NFC tag by a master device. According to proposed concepts, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[0051] Embodiments of the invention aim to provide a method for offline PUF authentication of an NFC tag by a master device. This can be achieved by storing a plurality of challenge response pairs, CRPs, on the NFC tag itself so that connection to a server storing a library of CRPs is not required.

[0052] Proposed concepts thus aim to provide schemes, solutions, concept, designs, methods and systems pertaining to offline physical unclonable function, PUF, authentication of an NFC tag by a master device. In particular, embodiments aim to provide a method for offline PUF authentication of an NFC tag by a master device by storing a plurality of challenge response pairs, CRPs, on the NFC tag itself so that connection to a server storing CRPs is not required.

[0053] In other words, it is proposed that by storing a plurality of CRPs on the NFC tag itself, the master device may have access to CRPs to challenge the NFC tag with while remaining entirely offline. In order to increase the security of this method, the master device also encrypts the challenge of a CRP selected from the stored plurality before communicating the encrypted challenge to the NFC tag. The NFC tag then needs to decrypt the encrypted challenge using the same secret key to be able to provide the correct response such that the master device can authenticate it.

[0054] Referring now to Fig. 1, there is depicted a simplified flow diagram of a method 100 for offline physical unclonable function, PUF, authentication of an NFC tag by a master device according to a proposed embodiment.

[0055] It is noted that offline can be understood as the method not requiring access to any third party, such as a server or another device. In other words, offline refers to the fact that the method is capable of being carried out via entirely local data transfer between only the NFC tag and the master device.

[0056] The method 100 begins with the step 110 of receiving NFC data from the NFC tag at the master device, the NFC data comprising a plurality of challenge response pairs, CRPs. In this embodiment, the responses of the CRPs are hashed and truncated, however, this need not be the case. In other words, the responses of the CRPs may be hashed and / or truncated or neither. Hashing and truncating further enhances security of the method, however, while also allowing more CRPs to the stored on the limited memory of the NFC tag. Hashing the responses allows the responses to be protected against plaintext-analysis attacks, e.g., deep learning. In step 120, the master device selects a CRP from the received plurality of CRPs. This selection may be done randomly, pseudo-randomly, and / or using an algorithm. These can all enhance the security of the method while remaining efficient. The NFC data can also include a tag ID, such that at the end of the method 100, the ID can be saved as authenticated or not.

[0057] In other words, for verification based on PUF, without use of an online server, the CRP library needs to be securely exchanged to the master device without leaking through, for example, a factory preset method. Therefore, in the production stage, for the PUF component of the NFC tag, a certain amount of CRPs are recorded (depending on the storage capacity of the NFC tag). A challenge and a corresponding hash-calculated response are used as a pair. In some embodiments, a general private key (with the corresponding public key being stored in the master device) of the NFC tag can then be used to sign these multiple records. All records and the signature can then be saved in the data area of the NFC tag. This is described in more detail later, in reference to Fig. 3.

[0058] In step 130, the master device encrypts the challenge of the selected CRP with a secret key. For example, the secret key may be pre-known to the master device, e.g., stored in the master device prior to the method 100. Alternatively, the NFC data may further comprise the secret key. Alternatively, a secret rule that allows the master device to determine the secret key based on the NFC data may be pre-known to the master device. In this embodiment, the secret key comprises one of the responses from the plurality of the CRPs, however, this is not an essential feature for the method 100 to function, i.e., the secret key may take any suitable form. For example, the secret key may be known to both the NFC tag and the master device as the first response of the plurality of CRPs (i.e., this is the secret rule). In this way, a key that is secret to any third parties yet is contained within the plurality of CRPs is provided. The NFC tag then does not need any further storage to store the secret key as well as the plurality of CRPs, and further, the secret key is essentially hidden in plain sight amongst the plurality of CRPs. If the master device knows, for example, that the third response of the plurality of CRPs is the secret key, after receiving the CRPs from the NFC tag, it can then use the secret key to encrypt a chosen challenge without the secret key having to be exactly preset during production. The master device is then capable of authenticating multiple different NFC tags, which will all have different secret keys, without having to pre-save the secret key of each possible NFC tag. Essentially, this feature allows the master device to use a simple secret rule to work out the secret key for each different NFC tag.

[0059] In step 140, the encrypted challenge of the selected CRP is communicated from the master device to the NFC tag. For instance, the master device may send the encrypted challenge to the NFC tag or the NFC tag may request and / or pull the encrypted challenge from the master device.

[0060] In step 150, the NFC tag decrypts the encrypted challenge with the secret key. For example, the secret key may be pre-known to the NFC tag, e.g., stored in the NFC tag prior to the method 100. In step 160, the NFC tag generates a response to the challenge. For instance, the NFC tag may generate the response to the challenge using a PUF component, by which the CRPs were first generated.

[0061] In step 170, the generated response is communicated from the NFC tag to the master device. For instance, the NFC tag may send the generated response to the master device or the master device may request and / or pull the generated response from the NFC tag. In step 180, the master device verifies the generated response based on the response of the selected CRP, i.e., based on the response of the selected CRP of the initially received plurality of CRPs. For example, the master device may compare the response of the selected CRP to the generated response, and if they are the same then the generated response is verified, and if the responses are different then the generated response is not verified. In other words, if the hash value of the generated response and the initially-read response is the same, then the response is verified.

[0062] Thus, in step 190, responsive to the generated response being verified, the NFC tag is authenticated. For example, the master device authenticates the NFC tag and may register the NFC tag in a database or log of authenticated NFC tags. For example, the NFC tag can have an ID associated with it (which may be an NFC ID) and this ID can be marked as authenticated.

[0063] It should be noted that in method 100, the NFC tag may form part of an accessory device, and the method 100 would therefore essentially be for authenticating the entire accessory device, not merely the NFC tag, per se.

[0064] In a first example, a master device reads a plurality of CRPs from an NFC tag of an accessory device and then randomly chooses one of the CRPs (Ci-Ri) for verification. The master device then encrypts the chosen challenge (Ci) with a secret key (in this case, the first response of the plurality of CRPs, Rl) and sends the encrypted challenge (Ci) back to the accessory device. The accessory device then decrypts the encrypted challenge (Ci) with the secret key (Rl), generates a response (Ri) by means of its PUF module / component, and sends the generated response (Ri) to the master device. The master device then compares the response (Ri) received from the accessory device with the response (Ri) that it previously read from the received plurality of CRPs and authenticates the accessory device if the comparison matches.

[0065] Referring now to Fig. 2, there is depicted a flow diagram of a method 200 for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment.

[0066] Steps 120, 130, 140, 150, 160, 170, 180, and 190 are substantially the same as have been described in relation to method 100 of Fig. 1. Step 210 is substantially the same as has been described in relation to method 100 of Fig. 1, however, in this embodiment, the NFC data further comprises the secret key, wherein the secret key has been encrypted with a private key, and wherein a corresponding public key is stored in the master device.

[0067] In step 230, the master device decrypts the encrypted secret key with the public key. It can then use the decrypted secret key to encrypt the challenge of the selected CRP in step 130. In other words, in order to further enhance security of the method 200, the secret key can be encrypted in the NFC tag. Encrypting the secret key with a private key, wherein the corresponding public key is stored in the master device, allows the secret key to be more highly secure while still allowing the master device to decrypt the secret key, e.g., one of the stored responses.

[0068] The NFC tag may also store the secret key (e.g. one of the responses) in an unencrypted form such that it may use the secret key to decrypt the encrypted challenge, i.e., as part of the plurality of CRPs with the NFC tag having knowledge of which response is the secret key. Alternatively, the NFC tag may not have knowledge of which response is the secret key and the challenge corresponding to the response chosen as the secret key may be communicated from the master device along with the encrypted selected challenge so that the NFC tag may generate the secret key to decrypt the encrypted selected challenge.

[0069] It should be noted that in method 200, the NFC tag may form part of an accessory device, and the method 200 would therefore essentially be for authenticating the entire accessory device, not merely the NFC tag, per se.

[0070] Referring now to Fig. 3, there is depicted a more in-depth flow diagram of a method 300 for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment.

[0071] Steps 110, 130, 180, and 190 are substantially the same as have been described in relation to the method 100 in Fig. 1. Step 310 is substantially the same as step 110, however, in this embodiment, the NFC data further comprises a signature, wherein the signature is based on a private key.

[0072] In step 315, the master device verifies the signature based on a public key stored in the master device, wherein the public key corresponds to the private key that was used to generate the signature. This facilitates the secure verification of the NFC data before use of the NFC data, thus providing a more efficient method of potentially ending authentication of a counterfeit device early into the method.

[0073] In step 320, the master device generates a random string. In step 330, the master device encrypts the random string with a secret key (the same used to encrypt the challenge of the selected CRP in step 130). In step 340, the encrypted random key is communicated along with the encrypted challenge from the master device to the NFC tag. In step 345, the NFC tag decrypts the encrypted random string and the encrypted challenge with the secret key.

[0074] In step 355, after the NFC tag has generated a response to the challenge in step 160, the NFC tag encrypts the generated response with the random string. In step 360, the encrypted generated response is communicated from the NFC tag to the master device. In step 365, the master device decrypts the encrypted response with the random string. The master device can thus verify the decrypted response in step 180. The use of a random string in the method 300 adds another layer of protection to the authentication by encrypting communications between the NFC tag and the master device so that they cannot be eavesdropped on and easily understood. A random string can, for example, be understood as a string of random characters and / or numbers.

[0075] It should be noted that in methods 100, 200 and 300, any mentioned encryption and / or decryption is performed with an XOR (exclusive disjunction) operation. This is a computationally simple operation less-powerful processors are capable of performing while still facilitating encryption / decry ption. This need not be the case, however. In other embodiments, any encryption and / or decryption may be performed with any logic-based algorithm. In other embodiments, any encryption and / or decryption may be performed in any suitable way. Further, in some embodiments, all hash operations can be performed with secure hash algorithms (SHA).

[0076] In a second example, in addition to the steps described in the first example above, the transmission of the response (Ri) from the accessory device to the master device is further protected by using a random number (T). That is, the master device first generates a random number (T), encrypts the random number (T) with the secret key (Rl) and then transmits the encrypted random number to the accessory device. The accessory device then obtains the random number (T) by decrypting it with the secret key (Rl) and then encrypts its generated response (Ri) with the random number (T) before sending it to the master device. The master device then finally obtains the response (Ri) by decrypting it with the random number. In this way, the security of communications between the devices has been enhanced.

[0077] In a third example, when pairing begins, the master device starts NFC and reads all NFC data (including a tag ID) from the accessory device. After verifying a signature of the NFC data with its embedded public key (MK-pub), the master device also checks the integrity of the NFC tag ID. The master device then reads a Cl-Enc(Rl) pair from the NFC data and decrypts it with the MK-pub to obtain Rl (i.e., the secret key). A pseudo-random string (T) with 4-bytes’ size is then generated. The master device then randomly chooses one CRP (Ci- Trunc(Hash(Ri))) before encrypting it with Rl and sending it to the accessory device comprising an NFC tag along with Cl and the random string (T), also encrypted with Rl. This communication is thus 12 bytes in total.

[0078] The accessory device, after receiving the communication, reads Cl from the received message and then challenges the PUF component in order to obtain Rl. With Rl, it can thus decrypt both Ci and T. The accessory device then challenges its PUF with Ci in order to obtain Ri. It then encrypts the generated response (Ri) with the random string (T) before communicating it to the master device. This communication is 4 bytes in total.

[0079] The master device then obtains Ri by XOR with T, proceeds Ri with SHA-1 hash and truncates the 4 last bytes to verify with the pre-read value. If they are the same, the accessory is thus authenticated, e.g., its tag ID can be stored in a memory indicating that the ID has been previously authenticated.

[0080] Referring now to Fig. 4, there is depicted a simplified flow diagram of a method 400 for preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device according to a proposed embodiment. This allows the master device and NFC tag to be prepared to carry out any embodiment of the proposed method of offline PUF authentication described above.

[0081] In step 410, a plurality of CRPs are generated by a PUF component in the NFC tag. In step 415, a secret key is generated. For instance, the secret key can be generated by the NFC tag or an external third party. In step 420, the plurality of CRPs and the secret key are stored in the NFC tag. What is stored in the NFC tag can be understood as the NFC data.

[0082] A secret rule can be stored in the master device for determining the secret key based on the received NFC data. For instance, the rule may be that the first response of the plurality of CRPs is the secret key. Referring now to Fig. 5, there is depicted a flow diagram of a method 500 of preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device according to a proposed embodiment. Step 410 is substantially the same as has been described in relation to method 400 of Fig. 4.

[0083] In step 515, a private key and a corresponding public key are generated. For instance, these keys can be generated by an external third party, e.g. a crypto-component of a specific supporting program in production stage. Step 515 is not essential, however. The private and corresponding public key may be generated externally to the method 500 and simply provided to the master device and NFC tag. In step 525, the public key is stored in the master device. In step 520, one of the responses of the plurality of CRPs is encrypted with the private key. For instance, step 520 can be performed by the NFC tag, the master device, or an external third party. In this embodiment, the response is encrypted in step 520 using an elliptic- curve cryptography series algorithm. This is a form of an asymmetric algorithm capable of being performed with limited computing capabilities and memory capacities. In other embodiments, however, the response encryption may be performed using any asymmetric algorithm as this is a relatively secure method of encryption. In yet other embodiments, however, the response encryption may be performed using any suitable method.

[0084] In step 530, the encrypted response is stored in the NFC tag along with the plurality of CRPs, wherein the secret key comprises the response that has been encrypted with the private key. In this way, the master device will be able to decrypt the encrypted secret key with the public key during authentication. In other words, method 500 allows the NFC tag to store an encrypted response as an encrypted secret key such that the encrypted secret key may be used in an embodiment of the method of authentication.

[0085] It should be noted that in methods 400 and 500, the NFC tag may form part of an accessory device, and the methods would therefore essentially be for preparing the entire accessory device, not merely the NFC tag, per se.

[0086] For example, during production of the master device and NFC tag(s) (which may each take place in locations separate in space and / or time), a master asymmetric encryption 128bit key is generated (MK-pub, MK-pri) for a certain category of products (that is, one specific type of master device, e.g., a toothbrush handle). The MK-pub is then stored in the master devices. For each NFC tag (which may be stored in an accessory device) a series of CRPs is then randomly generated with its PUF component, with the exact number of CRPs dependent on the memory capacity of the NFC tag. It can then be decided that one of the CRPs, e.g. the first one, can be used as a secret key. For instance, the first response (Rl) can be chosen as the secret key. In this case, the response (Rl) is then be encrypted with MK-pri, and Cl- Enc(Rl) can be taken as a pair (136 bytes). All other responses (Ri) in the NFC tag are then processed with SHA-1 hash and the hash value truncated with the last 4 bytes to reduce their size. Ci and its corresponding truncated value are thus taken as a pair (8 bytes). A sharing table is then built which contains: NFC tag ID (usually 7 bytes); the processed CRPs; and Cl- Enc(Rl). The table is then signed with MK-pri. The table and its signature are finally written to the memory of the NFC tag for public access.

[0087] Referring now to Fig. 6, there is depicted a simplified block diagram of a system 600 for offline PUF authentication of an NFC tag by a master device according to a proposed embodiment. The system 600 comprises an NFC tag 610 and a master device 620. The NFC tag 610 and master device 620 are communicable with one another, i.e., able to communicate data to and from one another, i.e., using near-field communication.

[0088] The NFC tag 610 stores NFC data, the NFC data comprising a plurality of CRPs. The master device 620 is configured to receive the NFC data from the NFC tag 610; select a CRP from the plurality of CRPs; encrypt the challenge of the selected CRP with a secret key; and communicate the encrypted challenge of the selected CRP to the NFC tag. The NFC tag 610 is configured to decrypt the encrypted challenge with the secret key; generate a response to the challenge; and communicate the generated response to the master device 620. The master device 620 is further configured to then verify the generated response based on the response of the chosen CRP; and, responsive to the generated response being verified, authenticate the NFC tag 610.

[0089] It is expected that the master device 620 will generally be powered / charged, and therefore can have more computing capability, including security processing such as performing asymmetric encryption and hash operations, as well as being used as an NFC reader. NFC readers typically read data from an NFC tag 610 in NDEF (NFC data exchange format).

[0090] Referring now to Fig. 7, there is depicted a simplified block diagram of an example NFC tag 610 comprising a PUF component 614. The NFC tag 610 comprises a controller 612, a PUF component 614 which can typically only perform simple operations, and a memory 616 for storing data, such as the aforementioned NFC data. The NFC tag 610 further comprises an antenna 618 so that it may, for example, communicate with a master device.

[0091] A PUF component 614, which could be a PUF integrated circuit with fuzzy extractor, provides a stable challenge-response mechanism. A strong PUF is preferred which has unlimited CRPs, but considering the memory limit of the NFC tag, 4 bytes can be taken as the size of the challenge-response. A common type 4 NFC tag 610 can provide 32k memory, which can store more than 3500 CRPs. The size of the memory capacity, however, also depends on the cost of the NFC tag.

[0092] Fig. 8 illustrates an example of a computer 800 within which one or more parts of an embodiment may be employed. Various operations discussed above may utilize the capabilities of the computer 800. In this regard, it is to be understood that system functional blocks can run on a single computer or may be distributed over several computers and locations (e.g. connected via internet).

[0093] The computer 800 includes, but is not limited to, PCs, workstations, laptops, PDAs, palm devices, servers, storages, and the like. Generally, in terms of hardware architecture, the computer 800 may include one or more processors 810, memory 820 and one or more VO devices 830 that are communicatively coupled via a local interface (not shown). The local interface can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and / or data connections to enable appropriate communications among the aforementioned components.

[0094] The processor 810 is a hardware device for executing software that can be stored in the memory 820. The processor 810 can be virtually any custom made or commercially available processor, a central processing unit (CPU), a digital signal processor (DSP), or an auxiliary processor among several processors associated with the computer 800, and the processor 810 may be a semiconductor based microprocessor (in the form of a microchip) or a microprocessor.

[0095] The memory 820 can include any one or combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., ROM, erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), programmable read only memory (PROM), tape, compact disc read only memory (CD-ROM), disk, diskette, cartridge, cassette or the like, etc.). Moreover, the memory 820 may incorporate electronic, magnetic, optical, and / or other types of storage media. Note that the memory 820 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 810.

[0096] The software in the memory 820 may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory 820 includes a suitable operating system (O / S) 850, compiler 860, source code 870, and one or more applications 880 in accordance with exemplary embodiments. As illustrated, the application 880 comprises numerous functional components for implementing the features and operations of the exemplary embodiments. The application 880 of the computer 800 may represent various applications, computational units, logic, functional units, processes, operations, virtual entities, and / or modules in accordance with exemplary embodiments, but the application 880 is not meant to be a limitation.

[0097] The operating system 850 controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. It is contemplated by the inventors that the application 880 for implementing exemplary embodiments may be applicable on all commercially available operating systems.

[0098] Application 880 may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler (such as the compiler 860), assembler, interpreter, or the like, which may or may not be included within the memory 820, so as to operate properly in connection with the O / S 850. Furthermore, the application 880 can be written as an object oriented programming language, which has classes of data and methods, or a procedure programming language, which has routines, subroutines, and / or functions, for example but not limited to, C, C++, C#, Pascal, Python, BASIC, API calls, HTML, XHTML, XML, ASP scripts, JavaScript, FORTRAN, COBOL, Perl, Java, ADA, NET, and the like.

[0099] The I / O devices 830 may include input devices such as, for example but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, the I / O devices 830 may also include output devices, for example but not limited to a printer, display, etc. Finally, the I / O devices 830 may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator / demodulator (for accessing remote devices, other files, devices, systems, or a network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The I / O devices 830 also include components for communicating over various networks, such as the Internet or intranet.

[0100] If the computer 800 is a PC, workstation, intelligent device or the like, the software in the memory 820 may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of essential software routines that initialize and test hardware at start-up, start the O / S 850, and support the transfer of data among the hardware devices. The BIOS is stored in some type of read-only-memory, such as ROM, PROM, EPROM, EEPROM or the like, so that the BIOS can be executed when the computer 800 is activated.

[0101] When the computer 800 is in operation, the processor 810 is configured to execute software stored within the memory 820, to communicate data to and from the memory 820, and to generally control operations of the computer 800 pursuant to the software. The application 880 and the O / S 850 are read, in whole or in part, by the processor 810, perhaps buffered within the processor 810, and then executed.

[0102] When the application 880 is implemented in software it should be noted that the application 880 can be stored on virtually any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium may be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method.

[0103] The application 880 can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.

[0104] The methods of Figs. 1-5, and the system of Fig. 6, may be implemented in hardware or software, or a mixture of both (for example, as firmware running on a hardware device). To the extent that an embodiment is implemented partly or wholly in software, the functional steps illustrated in the process flowcharts may be performed by suitably programmed physical computing devices, such as one or more central processing units (CPUs) or graphics processing units (GPUs). Each process - and its individual component steps as illustrated in the flowcharts - may be performed by the same or different computing devices. According to embodiments, a computer-readable storage medium stores a computer program comprising computer program code configured to cause one or more physical computing devices to carry out an encoding or decoding method as described above when the program is run on the one or more physical computing devices. Storage media may include volatile and non-volatile computer memory such as RAM, PROM, EPROM, and EEPROM, optical discs (like CD, DVD, BD), magnetic storage media (like hard discs and tapes). Various storage media may be fixed within a computing device or may be transportable, such that the one or more programs stored thereon can be loaded into a processor.

[0105] To the extent that an embodiment is implemented partly or wholly in hardware, the blocks shown in the block diagrams of Fig. 8 may be separate physical components, or logical subdivisions of single physical components, or may be all implemented in an integrated manner in one physical component. The functions of one block shown in the drawings may be divided between multiple components in an implementation, or the functions of multiple blocks shown in the drawings may be combined in single components in an implementation. Hardware components suitable for use in embodiments of the present invention include, but are not limited to, conventional microprocessors, application specific integrated circuits (ASICs), and field-programmable gate arrays (FPGAs). One or more blocks may be implemented as a combination of dedicated hardware to perform some functions and one or more programmed microprocessors and associated circuitry to perform other functions.

[0106] A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. If a computer program is discussed above, it may be stored / distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. If the term "adapted to" is used in the claims or description, it is noted the term "adapted to" is intended to be equivalent to the term "configured to". Any reference signs in the claims should not be construed as limiting the scope.

[0107] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions, the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention.

Claims

CLAIMS:

1. A method (100) for offline physical unclonable function, PUF, authentication of an NFC tag by a master device, the method comprising: receiving NFC data (110) from the NFC tag at the master device, the NFC data comprising a plurality of challenge response pairs, CRPs; selecting, at the master device, a CRP (120) from the plurality of CRPs; encrypting the challenge of the selected CRP (130), at the master device, with a secret key; communicating the encrypted challenge (140) of the selected CRP from the master device to the NFC tag; decrypting, at the NFC tag, the encrypted challenge (150) with the secret key; generating, at the NFC tag, a response (160) to the challenge; communicating the generated response (170) from the NFC tag to the master device; verifying, at the master device, the generated response (180) based on the response of the selected CRP; and responsive to the generated response being verified, authenticating the NFC tag (190).

2. The method of claim 1, wherein the secret key comprises one of the responses from the plurality of CRPs.

3. The method of claim 1 or 2, wherein the NFC data further comprises the secret key, wherein the secret key has been encrypted with a private key, and wherein a corresponding public key is stored in the master device, and wherein the method further comprises: decrypting the encrypted secret key (230), at the master device, with the public key.

4. The method of any prior claim, wherein the method further comprises: generating, at the master device, a random string (320); encrypting, at the master device, the random string (330) with the secret key;communicating the encrypted random string with the encrypted challenge (340) from the master device to the NFC tag; decrypting, at the NFC tag, the encrypted random string (345) with the secret key; prior to communicating the generated response, encrypting the generated response (355), at the NFC tag, with the random string; and decrypting the generated response (365), at the master device, with the random string.

5. The method of any prior claim, wherein any encryption and / or decryption is performed with a logic-based algorithm.

6. The method of claim 5, wherein the logic-based algorithm comprises an XOR operation.

7. The method of any prior claim, wherein the responses of the plurality of CRPs of the NFC data are hashed and / or truncated.

8. The method of any prior claim, wherein NFC data further comprises a signature, and wherein the method further comprises: verifying the signature (315), at the master device, based on a public key stored in the master device, wherein the signature is based on a corresponding private key.

9. A method (400) for preparing an NFC tag and a master device for offline PUF authentication of the NFC tag by the master device, comprising: generating a plurality of CRPs (410) by a PUF component in the NFC tag; generating a secret key (415); and storing the plurality of CRPs and the secret key in the NFC tag (420).

10. The method of claim 9, wherein generating a secret key comprises: encrypting one of the responses (520) of the plurality of CRPs with a private key; storing a public key corresponding to the private key in the master device (525); andstoring the encrypted response in the NFC tag (530), wherein the secret key comprises the response.

11. The method of claim 10, wherein encrypting one of the responses comprises encrypting the response with a private key using an asymmetric algorithm.

12. The method of claim 11, wherein the asymmetric algorithm comprises an elliptic-curve cryptography series algorithm.

13. The method of any of claims 9 to 12, further comprising: storing a secret rule in the master device, wherein the secret rule describes how the secret key can be obtained from the NFC data..

14. A computer program comprising code means for implementing the method of any preceding claim when said program is run on a processing system.

15. A system (600) for offline NFC tag PUF -authentication of an NFC tag by a master device, the system comprising: an NFC tag (610) storing NFC data, the NFC data comprising a plurality of CRPs; and a master device (620) configured to: receive the NFC data (110) from the NFC tag; select a CRP (120) from the plurality of CRPs; encrypt the challenge of the selected CRP (130) with a secret key; and communicate the encrypted challenge (140) of the selected CRP to the NFC tag; wherein the NFC tag (610) is configured to: decrypt the encrypted challenge (150) with the secret key; generate a response to the challenge (160); and communicate the generated response (170) to the master device; and wherein the master device (620) is further configured to: verify the generated response (180) based on the response of the chosen CRP; and responsive to the generated response being verified, authenticate the NFC tag (190).

Images