System and method for authenticating a product

Abstract

System and method for authenticating a product The present description relates to a method for recording a link between a radiofrequency tag (110) and a token comprising data associated with a product, the method comprising: - sending, by near field communication or radio-identification, data of a transaction by an electronic device (130) to the tag; - generating a signature by the tag on the basis of a private key (C_PR) of an asymmetric key pair further comprising a public key (C_PU), the signature being configured to allow recording on a blockchain; - transmitting by the tag the signed transaction to the electronic device in NFC or RFID; and - recording, in an immutable manner, the link between the tag and the token by transmitting, by the electronic device, the signed transaction to a server (150) implementing the blockchain.Figure for abstract: Fig. 2.

Description

Title of the invention: System and method for authenticating a product Technical field

[0001] The present description relates generally to a system and a method for authenticating a product and in particular to solutions based on blockchains. Prior art

[0002] For certain products, it may be desirable to provide an authentication system to control the origin and traceability of these products. To meet this need, it has been proposed to stick a QR code on a product, allowing the product to be authenticated using a reader. However, a disadvantage with this solution is that a QR code is likely to be damaged and therefore become illegible during the life of the product. Another proposed solution is to integrate an electronic circuit into the product. The electronic circuit is capable of communicating with an external electronic device by wireless communication means, for example wifi or Bluetooth, in order to read information stored by the electronic circuit and to authenticate the product on the basis of this information.

[0003] However, existing solutions are generally complex, expensive, not sufficiently secure and / or require a battery, and there is therefore a need for an improved authentication solution. Summary of the invention

[0004] One embodiment provides a method of recording a link between a radio frequency tag and a token comprising data associated with a product, the method comprising: - sending, by near field communication (NFC) or radio frequency identification (RFID), transaction data from an electronic device to the label; - generating a signature of the transaction data by the tag based on a private key of an asymmetric key pair further comprising a public key, the signature being configured to allow recording on a blockchain; - transmission by the label of the signed transaction to the electronic device in NFC or RFID; and - the immutable recording of the link between the label and the token by the transmission, by the electronic device, of the signed transaction to a server implementing the blockchain.

[0005] According to one embodiment, the signature comprises three components generated by a cryptographic signature algorithm, the third component of which allows the identification of the public key.

[0006] According to one embodiment, the signature comprises two components generated by a cryptographic signature algorithm, one of the components identifying the asymmetric key pair.

[0007] According to one embodiment, the recording of the link between the label and the token comprises the execution by the server of scripts.

[0008] According to one embodiment, the sending of transaction data by the electronic device is carried out via an application, the application being implemented by the electronic device and the recording of the link being initialized by the application.

[0009] According to one embodiment, the generation of the signature is carried out by an elliptic cryptography algorithm.

[0010] According to one embodiment, the blockchain is of the Ethereum virtual machine type.

[0011] Another embodiment provides a system for recording a link between a radiofrequency tag and a token comprising data associated with a product, the device comprising: - an electronic device configured to send, in NFC or RFID, data of a transaction to the label, and configured to transmit the signed transaction to a server carrying out a blockchain; - the label configured to generate a signature of the transaction data based on a private key, forming an asymmetric key pair further comprising a public key, the signature being configured to allow recording on a blockchain, the label being further configured to transmit, in NFC or RFID, the signature to the electronic device, the electronic device being configured to transmit the signed transaction to the server carrying out the blockchain and configured to record, in an immutable manner, the link between the label and the token.

[0012] According to one embodiment, the signature comprises three components generated by a cryptographic signature algorithm, the third component of which allows the identification of the public key.

[0013] According to one embodiment, the signature comprises two components generated by a cryptographic signature algorithm, one of the components identifying the asymmetric key pair.

[0014] According to one embodiment, the method further comprises the server.

[0015] According to one embodiment, the label is attached or integrated into the product.

[0016] According to one embodiment, the data associated with the product are images and / or metadata. Brief description of the drawings

[0017] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:

[0018] [Fig.l] represents, in the form of blocks, an authentication system according to an embodiment of the present description;

[0019] [Fig.2] represents, in block form and in more detail, the label 110 and the electronic device 130 of [Fig.l] in communication with a server 150, according to an embodiment of the present description;

[0020] [Fig. 3] represents steps of an example method for recording a link between a near field communication (NFC) tag and a token according to an embodiment of the present description;

[0021] [Fig.4] shows steps of another example method of recording a link between a tag and a token according to an embodiment of the present description;

[0022] [Fig.5] represents steps of an exemplary method of registering an owner of a product according to an embodiment of the present description;

[0023] [Fig. 6] represents steps of an example of a method for verifying the authenticity of a product according to an embodiment of the present description; and

[0024] [Fig.7] represents steps of an example of a method for verifying the belonging of a product according to an embodiment of the present description. Description of the embodiments

[0025] The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same references and may have identical structural, dimensional and material properties.

[0026] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed. In particular, a blockchain and its operation as well as near-field communication protocols are known to those skilled in the art and will not be detailed.

[0027] Unless otherwise specified, when referring to two elements connected to each other, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") between them, this means that these two elements can be connected or linked through one or more other elements.

[0028] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "upper", "lower", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made unless otherwise specified to the orientation of the figures.

[0029] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.

[0030] [Fig.l] represents, in the form of blocks, an authentication system 100 according to an embodiment of the present description.

[0031] The authentication system 100 comprises a radiofrequency tag 110 present on a product 102. For example, the product 102 is a material object, for example an object not comprising an electronic circuit. The product 102 is for example an item of clothing, an accessory, a consumer product, for example a bottle of alcohol, a certificate of ownership, etc.

[0032] The label 110 is for example glued or physically integrated into the product 102 during its manufacture and cannot for example be removed or modified. For example, the physical connection is achieved by means of an adhesive so that the label 110 would be destroyed or damaged if it were removed from the product 102.

[0033] The authentication system 100 also comprises an electronic device 130. The tag 110 is configured to communicate via a radio frequency communication link, for example according to a near field communication (NFC) or radio frequency identification (RFID) protocol 125, with the electronic device 130. The electronic device 130 is for example a high-frequency NFC or RFID reader, a computer, a mobile phone, an electronic tablet, etc., equipped with a high-frequency NFC or RFID reader. The electronic device 130 is for example configured to implement an interface with a user, for example decentralized, for example a mobile application. The electronic device 130 is also configured to communicate with a remote server (not shown in [Fig.l]) in order to implement a method of authenticating the product 102 on the basis of the label 110.

[0034] [Fig. 2] represents, in block form and in more detail, the label 110 and the electronic device 130 of [Fig. 1] in communication with a server 150, according to an embodiment of the present description.

[0035] The product 102 of [Fig.l] is not shown in [Fig.2] and only the label 110 is illustrated. The label 110 comprises for example a memory 112 (“MEM1”). One or more key pairs each comprising a private key C_PR and a public key C_PU are for example generated by the manufacturer of the tag 110 and are for example assigned to the tag 110 and stored in the memory 112.

[0036] The tag 110 also comprises an NFC decoder 114 (“NFC DECODER”) and an NFC interface 116 (“NFC1”) comprising for example an antenna configured to send and receive waves having a radio frequency compatible with NFC communication and comprising for example also a conversion circuit (not shown). The block 114 and the NFC interface 116 are configured so that the tag 110 can communicate via an NFC link 125 with the electronic device 130.

[0037] The tag 110 also comprises a cryptographic circuit 118 (“CRYPT”) configured to perform cryptographic operations, for example to calculate a hash value from information on a transaction to be carried out and / or generate signatures from the private key C_PR recorded in the memory 112.

[0038] The electronic device 130 comprises, for example, a central processing unit 132 (CPU1, from the English “Central Processing Unit”) configured to implement the mobile application, a memory 134 (“MEM2”) and a battery 136 (“BAT”). The electronic device 130 also comprises an NFC interface 138 (“NFC2”) comprising, for example, an antenna configured to receive and send waves having a radio frequency compatible with NFC communication and comprising, for example, a conversion circuit (not shown). The electronic device 130 also comprises a communication interface 140 (“COMM1”) comprising, for example, an antenna configured to receive and send waves having a frequency compatible with wireless communication, for example a Wi-Fi connection or communication on a cellular network.The electronic device 130 is configured to communicate via an NFC or RFID link 125 with the tag 110 and to communicate via a wireless link 145 with the server 150 via the communication interface 140 and for example one or more intermediate wireless or wired networks, such as the Internet.

[0039] The server 150 comprises for example a central processing unit 152 (“CPU2”), a memory 154 (“MEM”) and a communication interface 156 (“C0MM2”) configured to receive and transmit data to the electronic device 130. The server 150 represents, for example, a node of a blockchain. In some cases, the blockchain comprises several nodes (not illustrated), each implemented by a server similar to the server 150. The electronic device 130 communicates, for example, with an interface of the server 150 which consists of a node making remote procedure calls (RPC) to the server 150.

[0040] The label 110, the electronic device 130 and the server 150 comprise, for example, other elements not illustrated in [Fig.2].

[0041] Embodiments provide for immutably and irreversibly linking the label 110 present on the product 102 to a digital token TOKEN (not illustrated in [Fig.2]), for example a non-fungible token (NFT) and / or a linked token (in English “SoulBound Token”).

[0042] In order to link the token TOKEN with the tag 110, a method is implemented comprising, during a first phase, the generation of a signature SIG1, generated by the tag 110, and, during a second phase, the recording of the link on a blockchain on the basis of the signature SIG1.

[0043] This link makes it possible to improve the traceability of the product 102 from its manufacture to marketing or successive marketings and to better inform users about the supply chain of the product 102.

[0044] According to one embodiment, the digital token TOKEN is generated by a computer system belonging to the entity marketing the product 102. The digital token TOKEN comprises, for example, images and / or metadata of the product 102, for example a photo of the product 102, a name, a logo of the brand of the product 102, the name of the creator, a description, a creation date, etc.

[0045] The server 150 corresponds for example to a node of the blockchain. The server 150 is for example configured to execute command scripts on the blockchain and to record transactions on the blockchain, in the memory 154.

[0046] [Fig. 3] represents steps of an example method 300 for recording a link between the label 110 of [Fig. 1] and the token TOKEN according to an embodiment of the present description.

[0047] The method is for example initialized by a user in possession of the product 102 of [Fig.l] and the electronic device 130. The user uses for example the mobile application implemented by the electronic device 130 to initiate the method of recording the link between the label 110 and the token TOKEN. This procedure is for example carried out only once, for example during the manufacture of the product 102 or before its marketing.

[0048] In a step 310 (“SEND TRANSACTION DATA”), the electronic device 130 of FIGS. 1 and 2 sends, in NFC, a signature request to the tag 110 which receives it. The sending of the signature request is for example carried out via the mobile application. The signature request is for example sent compressed (in English, “hashed”) or serialized by an encoding of the recursive length prefix (RLP, from the English “Recursive Length Prefix”).

[0049] According to one embodiment, the user, via the electronic device 130, creates a transaction data structure comprising for example nine fields including some or all of the following: a nonce, a gas price, a gas limit, a recipient, an amount, data, a blockchain identifier, and two fields each initialized to zero.

[0050] The nonce is, for example, a sequence number, generated by an account held outside the blockchain (EOA, from English, “externally owned account”) and used to avoid a replay attack.

[0051] The price of gas corresponds, for example, to the quantity of ether, in wei, that the user is prepared to pay for a unit of gas.

[0052] The gas limit corresponds for example to the maximum quantity of gas that the user is ready to pay for the transaction.

[0053] The recipient corresponds for example to a destination address, for example an address of an EOA or an address of a digital contract, such as a smart contract, on the blockchain.

[0054] The amount corresponds for example to the quantity of ether, in wei, to be sent to the recipient.

[0055] The data is for example binary data of variable length, for example a function selector, for example the first 4 hash bits of a secure hashing algorithm, for example Keccak-256, and the variables of the function, for example in connection with the called smart contract.

[0056] The blockchain identifier is, for example, a unique identifier associated with a blockchain network comprising the blockchain.

[0057] The two fields initially comprising a zero, in addition to the blockchain identifier, are for example used to secure the transaction and prevent replay attacks.

[0058] During step 310, the signature request sent by the electronic device 130 comprises, for example, the data structure.

[0059] In a step 320 (“SIG1 GENERATION”) following step 310, the tag 110 generates the signature SIG1. For example, the tag 110 generates the signature SIG1 only if the transaction corresponds to an expected cryptographic algorithm, for example an elliptic curve cryptography (ECC) algorithm, for example secp256kl, secp256rl, Keccak 256, SHA3-256, etc.

[0060] The block 118 CRYPT of the tag 110 performs for example a hash function, for example via the Keccak-256 algorithm, to generate a hash value corresponding to the signature request received from the electronic device 130.

[0061] The signature SIG1 is for example generated by the block 118, from the private key C_PR of the label 110, for example by means of a signature algorithm Elliptic Curve Digital Signature Algorithm (ECDSA).

[0062] The SIG1 signature is configured to allow recording on a blockchain. In particular, the SIG1 signature comprises: - either two components r and s generated by a cryptographic signature algorithm, one of the components identifying the asymmetric key pair C_PU, C_PR. An example of such an algorithm is the Edwards-Curve Digital Signature Algorithm (EdDSA), for example Ed25519, the algorithm taking as input the private key and the components r and s corresponding for example to coordinates on an elliptic curve. The EdDSA algorithm is described in more detail in the article entitled “Edwards-Curve Digital Signature Algorithm (EdDSA)” by S. Josefsson et al., the content of which article is fully incorporated into this description; - or three components r, s and v generated by a cryptographic signature algorithm, for example an ECDSA algorithm, where the third component allows the identification of the public key C_PU, the third component corresponding for example to a signature prefix and / or a recovery identifier (in English, “recovery identifier”). The third component v is such that the public key can be calculated from the components r, s and v. The third component v is for example also characteristic of the blockchain.

[0063] The generated SIG1 signature is for example compliant with the security protocols of elliptical type blockchains and can be directly used to sign transactions on the blockchain, without requiring an intermediate procedure for converting the SIG1 signature.

[0064] In a step 330 (“SEND SIG1”) following step 320, the tag 110 transmits, in NFC, the signature SIG1 to the electronic device 130. The electronic device 130 adds for example the signature SIG1 to the data structure to sign the transaction TL The third component v replaces for example the identifier of the block chain and the components r and s replace the two zeros.

[0065] In a step 340 (“TRANSMIT TRANSACTION”) following step 330, the electronic device 130, for example via the mobile application, transmits the signed transaction T1 to the server 150 to carry out the recording of the link on the blockchain.

[0066] In a step 350 (“SAVE SIG1”) following step 340, scripts written in the blockchain are for example executed. For example, these scripts are part of a digital contract, such as a smart contract, created and signed electronically by the entity marketing the product 102. A verification is for example carried out by the blockchain using one or more components of the SIG1 signature. For example For example, the v component is used for ECDSA algorithms or the r and s components are used for EdDSA algorithms, thanks to the exclusive ownership property. For example, the signature is used to compare an address of the label 110 which is for example extracted from the public key C_PU, to an expected address, associated with the token TOKEN, characterized by an identifier. The address of the label 110 is for example obtained from its public key C_PU. The address corresponds for example to a hexadecimal number, generated from the last 20 bytes of the public key C_PU having undergone a cryptographic hash, for example by the Keccak-256 algorithm. The identifier of the token TOKEN is for example generated at its creation, for example by the computer system of the entity marketing the product 102.

[0067] If the address of the label 110 corresponds to the expected address and the signature SIG1 is compliant, the signature SIG1 is recorded on the blockchain. Thus, any person having access to the data recorded on the blockchain and possessing the public key C_PU associated with the label 110 will be able to verify that the product 102, provided with the label 110, actually corresponds to the token TOKEN. The data recorded on the blockchain cannot be modified or deleted, which ensures that the link between the label 110 and the token TOKEN is irreversible. A product other than the product 102, for example a counterfeit, cannot possess the label 110 comprising the address and the private key C_PR. Thus, only the product 102 can generate the signature SIG1. Furthermore, the token TOKEN is for example a linked token, irreversibly associated with the address of the recipient. For example, the transfer of the TOKEN token is no longer usable after this association.

[0068] In a step 360 (“CONFIRMATION”), following step 350, a confirmation that the registration has been successfully completed is for example transmitted from the server 150 to the electronic device 130. The confirmation is for example accessible from the mobile application. The token TOKEN and its content are for example then also available from the mobile application, which provides a privileged means of communication between the entity marketing the product 102 and its owner. In other embodiments, step 360 is omitted.

[0069] [Fig. 4] represents steps of a method of recording the link between the label 110 of [Fig. 1] and the token TOKEN according to another embodiment of the present description.

[0070] In a step 410 (“KEY GENERATION”), the key pair C_PR, C_PU is generated, for example during the manufacture of the label 110.

[0071] In a step 420 (“KEY INJECTED IN NFC TAG”) following step 410, the generated key pair C_PR, C_PU is recorded in the memory 112 of the tag 110, for example by the manufacturer of the tag 110.

[0072] In a step 430 (“NFT GENERATION”), the token TOKEN is generated, for example by the computer system of the entity marketing the product 102. The identifier of the token TOKEN is for example generated at the time of creation of the token TOKEN.

[0073] The generation of the TOKEN token includes, for example, the addition of the content, for example images and / or metadata. For example, this content is stored in association with the token identifier TOKEN on a decentralized server accessible by the electronic device 130 and / or the server 150, so that these devices can access the content.

[0074] In a step 440 (“NFT-NFC MAPPING”) following steps 420 and 430, the identifier of the token TOKEN is assigned to the address of the label 110, for example by the computer system of the entity marketing the product 102. A digital token such as the token TOKEN is for example associated with a label such as the label 110. According to one embodiment, several NFC labels similar to the label 110 can each be associated with the same collection of digital tokens. For example, the product 102 is marketed in several copies. Each copy is then provided with a label such as the label 110 with an address and a pair of keys unique among the copies. Each copy is for example associated with the same collection of digital tokens comprising information relating to the product 102.

[0075] The correspondence between the identifier of the token TOKEN and the address of the label 110 is for example recorded in a database of the computer system of the entity marketing the product 102.

[0076] In a step 450 (“SMART CONTRACT”) following step 440, a smart contract CI is deployed on the blockchain, for example via a transaction signed by the computer system of the entity marketing the product 102. The blockchain is for example an ECC or Ed25519 type blockchain, for example an Ethereum Virtual Machine (EVM) or Ethereum type blockchain. The Ethereum blockchain is for example described in the article “Ethereum: a secure decentralized generalized transaction ledger, paris version 705168a” by Dr. Gavin Wood or by the publication “Ethereum White Paper” by Vitalik Buterin, published in 2014 and updated on December 8, 2023 (https: / / ethereum.org / fr / whitepaper / ), the content of these publications being fully incorporated into this present description.The CI smart contract includes, for example, scripts executable by the server 150 to cause the activation of tokens corresponding to physical objects (in English, “Physical Backed Tokens-enabled”) by a constructor-type function (in English, “constructor”) when the smart contract is deployed on the blockchain. The . smart contract CI includes for example correspondences between token identifiers and NFC tag addresses including the correspondence between the token identifier TOKEN and the tag address 110. The smart contract CI also includes for example scripts executable by the server 150 to link a tag to a token, scripts executable by the server 150 to record the ownership of the product 102 to a user, scripts executable by the server 150 to certify the authenticity of the product 102 and / or scripts executable by the server 150 to certify the ownership of the product 102 to a user, etc.

[0077] In a step 460 (“SOULBOUND TOKEN ACTIVATION”) following step 450, the TOKEN token is activated on the blockchain. A function of the CI smart contract is executed so that the digital tokens, including the TOKEN token, are linked to an account on a blockchain. Following the execution of this function, the TOKEN token can no longer be transferred to another account and / or another recipient address, such as an Ethereum address.

[0078] In a step 470 (“NFT-NFC LINK”) following step 460, the steps of method 300 of [Fig.3] are carried out.

[0079] [Fig.5] represents steps of an exemplary method of registering an owner of the product 102 of [Fig.l] according to an embodiment of the present description.

[0080] In a step 510 (“SEND TRANSACTION DATA”), a person, natural or legal, in possession of the product 102 and the electronic device 130 of [Fig. 1] initializes a claim of ownership. For example, the person, via the mobile application, executes a request for a transaction T2 on the blockchain. The electronic device 130 sends to the tag 110, in NFC, a signature request, corresponding to the transaction T2 on the blockchain. During step 510, the electronic device 130 sends for example data by NFC to the tag 110, the data being for example part of the signature request and comprising for example data characterizing the transaction T2.

[0081] Steps 520 (“SIG2 GENERATION”) and 530 (“SEND SIG2”) similar to steps 320 and 330 of [Fig.3] are performed following step 510 to generate a SIG2 signature and send it to the electronic device 130.

[0082] In a step 535 (“SIG_APP2 GENERATION”) following step 530, the electronic device 130 generates a SIG_APP2 signature for the transaction T2. ​​The transaction T2 is for example signed by the signatures SIG2 and SIG_APP2 in order to be valid. A pair of keys comprising a private key PRIV and a public key PUB is for example generated upon installation of the mobile application. According to one embodiment, the signature SIG_APP2 is generated by the electronic device 130 from the private key PRIV and the public key PUB allows verification of the signature. SIG_APP2.

[0083] In a step 540 (“TRANSMIT SIGNATURES”) following step 530, the electronic device 130, for example via the mobile application, transmits the signature SIG2 to the server 150 to carry out the transaction T2 on the blockchain. According to embodiments, the transaction T2 comprises two signatures and the electronic device 130, for example via the mobile application, also transmits the signature SIG_APP2 to the server 150. The use of the multiple signatures SIG2 and SIG_APP2 increases the reliability of the transaction.

[0084] In a step 550 (“SAVE SIG2”) following step 540, scripts of the smart contract CI are for example executed by the server 150 and the signature SIG2 is written on the blockchain. Thus, any person having access to the data recorded on the blockchain and possessing the public key C_PU associated with the label 110 will be able to verify the transaction T2. ​​The product 102 comprising the label 110 is then recorded as belonging to the user in possession of the private key PRIV.

[0085] According to one embodiment, in a step 555 (“SAVE PUBLIC KEY”) following step 550, the public keys C_PU and PUB are recorded on a database of the computer system of the entity marketing the product 102, for example via an oracle of the blockchain.

[0086] In a step 560 (“CONFIRM”), following step 555, a confirmation that the transaction T2 has been successfully carried out is for example transmitted from the server 150 to the electronic device 130. The confirmation is for example accessible from the mobile application.

[0087] [Fig.6] represents steps of an example of a method for verifying the authenticity of the product 102 of [Fig.1] according to an embodiment of the present description.

[0088] In a step 610 (“SEND TRANSACTION DATA”), a person, natural or legal, in possession of the product 102 and the electronic device 130 of [Fig.l] initializes a verification of authenticity of the product 102. For example, the person, via the mobile application, executes a request for a transaction T3 on the blockchain. The electronic device 130 sends to the tag 110, in NFC, a signature request, corresponding to the transaction T3 on the blockchain.

[0089] During step 610, the electronic device 130 sends, for example, data via NFC to the tag 110, the data being, for example, part of the signature request and comprising, for example, data characterizing the transaction T3.

[0090] Steps 620 (“SIG3 GENERATION”) and 630 (“SEND SIG3”) similar to steps 320 and 330 of [Fig. 3] are performed following step 610 to generate a SIG3 signature and send it to the electronic device 130.

[0091] In a step 640 (“TRANSMIT SIG3”) following step 630, the electronic device electronics 130, for example via the mobile application, transmits the SIG3 signature to the server 150 to carry out the T3 transaction on the blockchain.

[0092] In a step 650 (“SAVE SIG3”) following step 640, scripts of the smart contract CI are for example executed by the server 150 to check whether the address of the label 110 having initiated the transaction corresponds to an address associated with a digital token, for example an NFT token and / or a linked token, of the entity marketing the product 102 and registered on the smart contract, for example during the deployment of the smart contract CI by the entity marketing the product 102, during step 450 of [Fig.4].

[0093] In a step 660 (“CONFIRM”), following step 650, if the address of the label 110 of the product 102 actually corresponds to an address associated with a digital token, for example an NFT token and / or a linked token, of the entity marketing the product 102, then the tested product is considered to be authentic, and a confirmation of the authenticity of the product 102 is for example transmitted from the server 150 to the electronic device 130. The confirmation is for example accessible from the mobile application.

[0094] In the event that the product 102 is not authentic, it does not include the label 110. No SIG3 signature could be generated or a signature corresponding to a private key different from the C_PR key would be generated and the transaction would not be validated.

[0095] [Fig.7] represents steps of an example of a method for verifying the belonging of the product 102 of [Fig.1] according to an embodiment of the present description.

[0096] In a step 710 (“SEND TRANSACTION DATA”), a person, natural or legal, in possession of the product 102 and the electronic device 130 of [Fig.l] initiates a verification of ownership of the product 102. For example, the person, via the mobile application, executes a request for a transaction T4 on the blockchain. The electronic device 130 sends to the tag 110, in NFC, a signature request, corresponding to the transaction T4 on the blockchain.

[0097] During step 710, the electronic device 130 sends, for example, data via NFC to the tag 110, the data being, for example, part of the signature request and comprising, for example, data characterizing the transaction T4.

[0098] Steps 720 (“SIG4 GENERATION”) and 730 (“SEND SIG4”) similar to steps 320 and 330 of [Fig.3] are performed following step 710 to generate a SIG4 signature and send it to the electronic device 130.

[0099] In a step 735 (“SIG_APP4 GENERATION”) following step 730, the electronic device 130 generates a SIG_APP4 signature for the transaction T4. The transaction T4 is for example signed by the signatures SIG4 and SIG_APP4 to be valid. According to one embodiment, the signature SIG_APP4 is generated by the electronic device 130 from the private key PRIV.

[0100] In a step 740 (“TRANSMIT SIGNATURES”) following step 730, the electronic device 130, for example via the mobile application, transmits the signature SIG4 to the server 150 to carry out the transaction T4 on the blockchain. According to embodiments, the transaction T4 comprises two signatures and the electronic device 130, for example via the mobile application, also transmits the signature SIG_APP4 to the server 150.

[0101] In a step 750 (“SAVE SIG4”) following step 740, scripts of the smart contract CI are for example executed by the server 150 to compare the public keys PUB and C_PU with the public keys used during the registration of the owner of the product 102 and recorded during step 555 of [Fig. 5]. The recorded public keys are for example read from the database of the computer system of the entity marketing the product 102, for example via a blockchain oracle. The comparison of the public key C_PU and the public key PUB ensures that it is indeed the same product 102 and a user having the same electronic device 130 who carries out the transaction T4 as during the transaction T2 of [Fig. 5].

[0102] In a step 760 (“CONFIRM”), following step 750, a confirmation of the ownership of the product 102 is for example transmitted from the server 150 to the electronic device 130 if the public key pair C_PU, PUB is identical to that recorded in the database of the computer system of the entity marketing the product 102 during step 555 of [Fig. 5]. The confirmation is for example accessible from the mobile application.

[0103] The metadata of the TOKEN token also includes, for example, communications from the entity marketing the product 102 to the owner of the product 102 and accessible from the mobile application. The embodiments described allow consumers to be better informed about the supply chain of their products.

[0104] Advantageously, the described embodiments use NFC communication between the product 102 and the electronic device 130. This mode of communication over short distances is secure and passive on the side of the product 102 which does not require electronic circuits or a battery. The solution presented is inexpensive and compatible with a wide variety of products. Finally, the described embodiments allow the generation, by the product 102, of a three-component signature directly compatible with the blockchain.

[0105] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variants could be combined, and other variants will occur to those skilled in the art.

Claims

Claims

1. Method for recording a link between a radiofrequency tag (110) and a token (TOKEN) comprising data associated with a product (102), the method comprising: - sending, by near field communication (NFC) or radio frequency identification (RFID), data of a transaction by an electronic device (130) to the tag; - generating a signature of the transaction data by the tag on the basis of a private key (C_PR) of an asymmetric key pair further comprising a public key (C_PU), the signature being configured to allow recording on a blockchain; - transmitting by the tag the signed transaction to the electronic device in NFC or RFID;and - recording, in an immutable manner, the link between the label and the token by the transmission, by the electronic device, of the signed transaction to a server (150) carrying out the blockchain.;

2. Method according to claim 1, in which the signature comprises three components (v, r, s) generated by a cryptographic signature algorithm, the third component (v) of which allows the identification of the public key.

3. The method of claim 1, wherein the signature comprises two components (r, s) generated by a cryptographic signature algorithm, one of the components identifying the asymmetric key pair.

4. The method of any one of claims 1 to 3, wherein recording the binding between the tag and the token comprises the server executing scripts.

5. A method according to any one of claims 1 to 4, wherein the sending of the transaction data by the electronic device (130) is carried out via an application, the application being implemented by the electronic device and the recording of the link being initiated by the application.

6. A method according to any one of claims 1 to 5, wherein the generation of the signature is performed by an elliptic cryptography algorithm.

7. Method according to any one of claims 1 to 6, in which the blockchain is of the Ethereum virtual machine type.

8. System for recording a link between a radiofrequency tag (110) and a token (TOKEN) comprising data associated with a product (102), the device comprising: - an electronic device (130) configured to send, in NFC or RFID, data of a transaction to the tag (110), and configured to transmit the signed transaction to a server (150) producing a blockchain;- the label (110) configured to generate a signature of the transaction data based on a private key (C_PR), forming an asymmetric key pair further comprising a public key (C_PU), the signature being configured to allow recording on a blockchain, the label (110) being further configured to transmit, in NFC or RFID, the signature to the electronic device (130), the electronic device being configured to transmit the signed transaction to the server carrying out the blockchain and configured to record, in an immutable manner, the link between the label (110) and the token (TOKEN).;

9. System according to claim 8, in which the signature comprises three components (v, r, s) generated by a cryptographic signature algorithm, the third component (v) of which allows the identification of the public key.

10. The system of claim 8, wherein the signature comprises two components (r, s) generated by a cryptographic signature algorithm, one of the components identifying the asymmetric key pair.

11. The system of any one of claims 8 to 10, further comprising the server (150).

12. A system according to any one of claims 8 to 11, wherein the label (110) is attached or integrated into the product (102).

13. A system according to any one of claims 8 to 12, wherein the data associated with the product are images and / or metadata.

Images