Method for verifying an electronic label, and system therefor

Abstract

The present invention relates to a method (200, 201, 202) for verifying an electronic label (1) for application to a product (50), in which label readable data and a secret key are stored, wherein the electronic label (1) comprises an integrated circuit (2) which is configured to calculate a hash value from the data by means of the private key. The present invention also relates to a system (100) comprising an electronic label (1) having an integrated circuit (2) for application to a product (50), a reader (5) for reading out data from the electronic label (1), and a server (7) connected to the reader (5) via a network (8) for exchanging data.

Description

Method for verifying an electronic label and system therefor

[0001] The present invention relates to a method for verifying an electronic label for attachment to a product having an integrated circuit, as well as to a system comprising an electronic label, a reader and a server. State of the art

[0002] Methods and systems for anti-counterfeiting and product authenticity verification are known in various forms from the state of the art. Determining the authenticity of a product is particularly important for both manufacturers and consumers in order to distinguish originals from counterfeits.

[0003] For example, clothing items can have tags sewn into them that contain special security features to verify the garment's authenticity. Such tags can also be designed to be electronically readable using a reader.

[0004] Methods for verifying electronic labels that can be attached to products are known from the prior art (US 2021 / 0103938 A1). Such methods verify a label using a private database, which is provided, for example, by the manufacturer of the label or product. However, these methods have the disadvantage that authenticity testing using a private database is not secure against tampering, as it can be manipulated both intentionally by the owner and unintentionally by third parties - for example, by changing or deleting entries for "genuine" products, or by generating new entries that do not correspond to a "genuine" product. Counterfeit products can thus be provided with such labels and appear "genuine" by manipulating the corresponding database. Disclosure of the invention

[0005] The present invention therefore has the object of making a method of the type mentioned at the outset more secure against counterfeiting or of providing a verification method which can increase the security against counterfeiting of products.

[0006] The invention solves the stated problem through the subject matter of the independent patent claims. Preferred embodiments emerge from the dependent patent claims and the embodiments presented below.

[0007] According to one aspect of the invention, a method for verifying an electronic label is shown, which can be attached, for example, to a physical product to increase the product's security against counterfeiting. The electronic label has an integrated circuit in which readable data and a secret key are stored. The integrated circuit is also designed to calculate a hash value from the data using the secret key.

[0008] The method comprises the following steps: a) reading data from the electronic label by a reading device, wherein the read data contains at least the hash value, b) transmitting the read data from the reading device to a server, c) verifying the hash value on the server by means of a blockchain, d) transmitting the result of the verification from the server to the reading device, and e) outputting and / or processing the result of the verification on the reading device.

[0009] According to a further aspect of the present invention, a system is shown comprising an electronic label with an electronic circuit for attachment to a product, a reader for reading data from the electronic label, and a server connected to the reader via a network for exchanging data.

[0010] According to the invention, the electronic circuit in the label has a memory in which readable data and a secret key are stored, and the electronic circuit is designed to calculate a hash value from the stored data and the secret key using a cryptographic function when read by a reading device and to send it to the reading device.

[0011] According to the invention, the reading device is designed to receive the hash value from the electronic label and to send it to a server for verification, as well as to receive a result of the verification from the server and to process and / or output it.

[0012] According to the invention, the server is designed to receive the hash value from the reading device and to verify it using a blockchain and to send the result of the verification to the reading device.

[0013] For the purposes of the present invention, an electronic label refers to any form of "tag" that contains data and is suitable for attachment to or in a product. Such products can include, for example, items of clothing, accessories such as bags, backpacks, etc., as well as electrical or electronic devices into which the label can be attached or integrated. Furthermore, such products can include trading cards, postage stamps, games, smart cards, or other paper products with integrated electronic circuits into which the electronic label is directly integrated.

[0014] It is generally stated that a blockchain within the meaning of the present invention can be understood as both private and public blockchains. Private blockchains can be stored on one or more servers of the owner and / or on users' computing devices. In particular, in the case of a private blockchain, the owner can freely define the protocols ("smart contracts") and thus determine the functionality and rules of the blockchain, while the individual blocks of the blockchain are public and freely visible to all users.

[0015] Hash values ​​are generally defined as strings generated by a hash function (a mathematical algorithm) that accepts data (or a "message") as input and returns a fixed string of characters (the "hash value"). The hash value generated by the hash function is unique for each input, and identical inputs always produce the same result. However, small changes in the input result in significantly different hash values.

[0016] Hash functions are regularly used in cryptographic protocols such as digital signatures and message authentication codes (MACs). A MAC is a specific type of hash function that takes a message and a secret key as input and returns a fixed string of characters. The secret key is used to ensure that only authorized parties can verify the authenticity of the message. The sender can append the MAC to the message, and the receiver can verify the MAC by back-calculating from the received message using the same private key, ensuring that the received message has not been tampered with or originates from a secure source.

[0017] If data is read or requested from the electronic label using a reader, the authenticity check or verification can be carried out particularly easily and conveniently.

[0018] The data read by the reader can include all or part of the data stored in the electronic tag. The calculated hash value is transferred to the reader as part of the read data. This reading can be done contactless or by establishing an electronic contact. Alternatively, the reading process on the electronic tag can also be initiated by a user (e.g., by bringing the reader close to the tag or by establishing electronic contact between the tag and the reader).

[0019] If the read data is transferred from the reader to a server, the authentication can be performed independently of the reader. Furthermore, the data required for verification or authentication does not need to be stored redundantly on each reader. This also ensures that each reader always accesses the most up-to-date data and does not retrieve outdated or inaccurate data.

[0020] If the hash value is verified on the server using a blockchain, the verification of the hash value can be made highly tamper-proof, as the data required for verification, stored in the blockchain, is resistant to manipulation. In conventional authentication methods, the data required for verification is usually stored in (private) databases. This allows both the database owner and hackers or external intruders to change, add, or delete database entries and thus manipulate the authentication process. However, if the data required for verification is stored in a blockchain, security against manipulation can be significantly increased.

[0021] Data stored in blockchains is considered more secure against tampering than data stored in traditional databases for several reasons. In particular, the following factors are relevant: Immutability: Once data is added to a blockchain, it can no longer be changed or deleted. This makes it much more difficult for attackers to manipulate the data. Decentralization: In a traditional database, data is stored in a single location, making it easier to attack. In contrast, Blockchains store data on a network of computers, making it much harder for attackers to gain control of all copies; Cryptography: Blockchains use cryptographic techniques to secure data, such as digital signatures and hashing algorithms. This provides an additional layer of security to prevent unauthorized access and tampering. Transparency: It is usually possible to track every transaction history in a blockchain, making it easier to detect suspicious activity; and finally Consensus: In a blockchain network, multiple parties must reach consensus before new data can be added to the chain. This makes it significantly more difficult for attackers to falsify the data.

[0022] By combining at least some of the factors mentioned above, the counterfeit security of electronic labels can be significantly increased.

[0023] According to the invention, the verification result is then transmitted back from the server to the reader, and finally, the verification result is output or further processed on the reader. Thus, the authenticity of the label can be verified independently of the reader using a blockchain, which significantly limits the possibilities for counterfeiting.

[0024] In summary, the invention provides a method for checking the authenticity or verification of an electronic label, which can be attached to or integrated into a product.

[0025] Further embodiments of the invention are presented below. Unless otherwise stated, the illustrated embodiments, or individual aspects of the embodiments, can be combined with one another in any way.

[0026] According to one embodiment of the invention, the reading of the data from the label by the reader can be carried out using one or more of the following methods: Wireless: Data can be transferred electronically and wirelessly between the label and the reader, for example, using RFID or NFC technology. Physical contact between the label and the reader is not necessary. Barcode scanning: Barcode scanning uses a laser- or camera-based system in the reader to capture data from the label. The barcode can be printed on the label or product, or displayed digitally by the label. Magnetic stripe reading: When reading magnetic stripes, a magnetic head in the reader is used to read the data encoded on a magnetic stripe. The label may have a magnetic stripe or be included in a magnetic stripe card, for example. Smart card reading: When reading smart cards, a contactless or contact-based interface is used to read data stored on the label. The label may have a contact zone with contact surfaces that can be brought into contact with the contacts of a reader to retrieve the data. Optical Character Recognition (OCR): OCR is a technology that can read printed text from an image, photo, or scanned document and convert it into machine-encoded text. The reader may have a camera that can capture text printed on the label or product. QR code scanning: QR codes are two-dimensional barcodes that can be scanned with a camera to extract the encoded information. The reader can, in turn, have a camera that captures and decodes the QR code. The QR code can, in turn, be printed or attached to the label or product.

[0027] As mentioned before, the above methods can also be combined with each other, so that, for example, part of the data is sent from the label to the reader via RFID and part of the data is printed as a QR code or writing or text on the label and captured by a camera of the reader.

[0028] According to a preferred embodiment, the data can be read from the electronic tag using an RFID reader. RFID (Radio Frequency Identification) uses radio waves for communication between the reader and the tag. The reader sends out a radio signal, which is received by the tag's antenna, thereby starting a reading process. This start of the reading process can be initiated, for example, by bringing the reader close to the tag. The tag then sends back data, which can be received and read by the reader. In this way, data can be electronically an electronic label without requiring physical contact or line of sight between the label and the reader.

[0029] According to one embodiment, the RFID reader can be an NFC reader and the electronic label can be an NFC tag. Both the reader and the label operate according to the NFC standard, thus enabling communication between the label and the reader only in the near field. This makes it particularly difficult for attackers to eavesdrop on the communication between the label and the reader.

[0030] According to one embodiment, the data transmission from the reader to the server can preferably take place over a network in which the reader and server are located. This creates a physical separation between the server and the reader, with the server being able to centrally receive and process requests from various readers. Such a network can be a private LAN or WLAN network, as well as a public network, such as the Internet. Especially when transmitting over a public network, communication between the reader and the server can be encrypted to improve security.

[0031] According to another design variant, the server can be implemented on the reader itself, with the data being transferred internally from the reader directly to the server. The server can then handle the verification requests decentrally, like many similar servers, thereby reducing request times and server load and minimizing server downtime.

[0032] For the transmission from the server back to the reader, the previously described variants can be applied analogously.

[0033] According to one embodiment, the reader can output the verification result visually, audibly, or haptically. The output can be a visual indication of the verification result, such as a colored LED or the display of text or symbols on a screen. Alternatively, a tone or a sequence of tones can be output that reflects the verification result. According to another option, the verification result can also be encoded as a haptic stimulus (such as a vibration).

[0034] According to one embodiment, the reader can be a smartphone or a portable computer. Preferably, the smartphone has an RFID or NFC reader, which is used to read the electronic tag. The received data is then transferred to the server, and the result obtained from the server can be displayed on the smartphone's screen.

[0035] According to one embodiment of the invention, to verify the hash value, a verification parameter can be requested from the blockchain based on the data received by the reader. The verification parameter can, for example, be a comparison value, based on which the hash value is verified. Alternatively, the verification parameter can also be used to calculate a comparison value on the server, which can be used to verify the hash value.

[0036] According to one embodiment of the invention, the readable data can comprise an identifier for uniquely identifying the label and an incremental counter. The identifier for uniquely identifying the label can be, for example, a UID or a consecutive numbering of the label or the like. The incremental counter can have a current counter value, which can be incremented, i.e., increased, by the integrated circuit. Preferably, the counter cannot be changed from outside the label, but only during corresponding program sequences in the integrated circuit, whereby the counter value cannot be decremented.

[0037] According to a further embodiment of the invention, the reader can receive the identifier for uniquely identifying the label and the counter value when reading the data from the electronic label. According to further embodiments of the invention, additional data or information stored on the electronic label (e.g., identification codes, character strings, etc.) can also be received.

[0038] According to one embodiment, this readable data can be received by the reader in the form of a message from the electronic tag. The message can contain all read data. The hash value is calculated as a checksum from the message and appended to the message when the message is sent from the electronic tag to the reader, so that the entire packet contains the read data as a message and the hash value as a checksum.

[0039] According to one embodiment, the readable data can be obtained from the electronic label in the form of a character string. The character string preferably represents a URL or a URI (Uniform Resource Identifier). Opening or querying the URL / URI on the reader transfers the data to the server, and the verification result is output. This makes it particularly easy to use a variety of readers to read the electronic labels, without requiring special software or programs to be installed on the readers.

[0040] For this purpose, the data or message transmitted from the label to the reader can be included in the URL / URI (e.g., in the form of query strings). The server can be operated as an HTTP server, which resolves the URL / URI and extracts the data from it. The result transmitted back to the reader can be received in the form of an HTTP response.

[0041] According to one embodiment of the invention, the integrated circuit of the electronic tag can be programmed to increment the incremental counter when data is read. The counter value can thus reflect the number of read operations of the electronic tag.

[0042] According to one embodiment of the invention, the integrated circuit of the electronic label can be programmed to automatically calculate a hash value from the read data each time the data is read and send it along with the data to the reader. The hash value can serve as a checksum or digital signature and, by incorporating the secret key, thus constitutes a forgery-proof certificate of the label's authenticity.

[0043] If the hash value is also calculated from the data containing the incremental counter, a unique hash value can be generated each time the data is read, which further increases the security against counterfeiting of the electronic label.

[0044] According to one embodiment, the reading device can read a message containing the data from the electronic label, wherein the message preferably includes an identifier for unique identification and the current counter value. The entire message is then used to calculate the hash value, wherein the hash value is a message authentication code (MAC), which is calculated from the message and the secret key using a cryptographic hash function or a block encryption method. The hash value is preferably a "one-key MAC" (OMAC), wherein the message is encrypted with the secret key stored on the electronic label.

[0045] According to a further embodiment, the hash value can also be generated using an encryption method with more than one key. Thus, more than one secret key can be stored on the electronic label; according to one embodiment, for example, a primary secret key and a secondary secret key. The encryption of the data to be read to generate the hash value can then be carried out first with the primary key and then again with the secondary key. This allows either two hash values ​​or one doubly encrypted hash value to be generated.

[0046] According to another embodiment, the hash value can be verified by comparing it with comparison hash values ​​stored in the blockchain. The blockchain can thus directly contain comparison hash values ​​as verification parameters, with which the hash values ​​received from the reader can be compared to verify the electronic tag. The hash values ​​stored in the blockchain are therefore immutable and cannot be manipulated. The possible hash values ​​for a specific electronic tag can be precalculated and stored in the blockchain in advance. This creates a particularly simple and secure verification process, since verification can be carried out exclusively based on or by means of the blockchain.

[0047] According to one embodiment, the comparison hash values ​​stored in the blockchain can also be pre-calculated for several possible counter values. For example, the hash values ​​stored in the blockchain can be calculated for a certain number of different counter values ​​for each data record of the electronic label (e.g., the unique identifier) ​​using the private key. Since the manufacturer of the electronic label knows the private key and the data stored on it, these can be used for the first time during production to calculate the different hash values. Since the private key, in particular, can no longer be read from the electronic label at a later point in time, the hash values ​​can no longer be calculated after the initial pre-filling of the blockchain without knowledge of the private key.By storing only the pre-calculated hash values ​​in the blockchain, active knowledge of the private key on the server is not necessary in order to perform an authenticity check of the electronic label.

[0048] According to another embodiment, the stored comparison hash values ​​can be stored in the blockchain as truncated comparison hash values. Such truncated comparison hash values ​​can be obtained, for example, by truncating or trimming the calculated hash values. In this case, not the entire hash value can be stored in the blockchain, but rather only the first / last 10 / 20 / 30, etc. characters of the calculated hash value. This makes it significantly more difficult to calculate back to the private key or to randomly guess the message or secret through numerous attempts. For verification, only the first characters of the hash value received from the reader are compared with the comparison hash values ​​stored in the blockchain.

[0049] According to another embodiment, the comparison hash values ​​can be stored in a program running on the blockchain, and the comparison between the hash value and the stored comparison hash values ​​can be performed when the program is executed. Such a program or protocol can preferably be a so-called "smart contract," which can be executed on the blockchain by a user. Storing the verification parameters directly in the program or smart contract has the advantage that control over the stored values ​​remains within the sphere of influence of the blockchain operator.

[0050] According to another embodiment, to verify the hash value, the server can retrieve a comparison key from the blockchain, calculate a comparison hash value from the received data and the comparison key using a cryptographic function, and compare the hash value with the comparison hash value. A number of comparison keys are stored on the blockchain, each of which is assigned to an electronic tag and is used to verify the hash value sent by the electronic tag. The comparison key can be retrieved by the server from the blockchain depending on the received data. For example, the received data can contain an identifier for uniquely identifying the electronic tag, and the comparison key can be retrieved from the blockchain for the respective identifier.The server then uses the comparison key to calculate a comparison hash value from the data received from the reader. The server preferably uses the same cryptographic hash function or encryption algorithm as the integrated circuit in the electronic tag. The calculated comparison hash value can then be compared with the received hash value to verify authenticity.

[0051] According to a further embodiment, all or part of the data received from the electronic label can be used to calculate the comparison hash value on the server. Preferably, the data includes the identifier for unique identification and the current counter value, which are encrypted with the comparison key. Alternatively, other or additional data can be used to calculate the hash value.

[0052] According to a further embodiment, a secret character string or a secondary key can be included in the electronic label's integrated circuit to calculate the hash value, which is not sent to the reader when reading the data from the electronic label. This secret character string can also be stored on the server, for example, in a private database, and when calculating the comparison hash value on the server using the comparison key. By including an additional secret or a secondary key, verification based on the blockchain alone without knowledge of the secret is not possible. Bypassing the server during verification is therefore impossible, further increasing security against forgery.

[0053] According to one embodiment of the invention, a comparison key can be stored in the blockchain for each identifier to uniquely identify the tag. The server can thus retrieve the appropriate comparison key from the blockchain after receiving the data from the reader, which in particular contains the identifier.

[0054] According to further variants, the comparison keys can also be stored in the blockchain linked to other data of the electronic label.

[0055] According to a further embodiment, the comparison keys can be stored in a program running on the blockchain, and the program can return a comparison key depending on data assigned to an electronic tag. Such a program or protocol can preferably be a so-called "smart contract," which can be executed on the blockchain by a user. Storing the verification parameters directly in the program or smart contract has the advantage that control over the stored values ​​remains within the sphere of influence of the blockchain operator. As previously described, the comparison keys in the program can be linked to tag data, such as the identifier for unique identification or other properties. For example, the program can receive the tag's identifier as a transfer parameter and return the appropriate comparison key for this.

[0056] According to another implementation variant, the comparison keys stored in the blockchain can be encrypted. Since the data stored in the blockchain is generally freely accessible and publicly visible to all users, an additional layer of security can be introduced by encrypting the stored comparison keys. The encrypted comparison keys can thus be stored directly in a public blockchain without any loss of security, and without any risk of bypassing the server's verification.

[0057] According to another variant, the comparison key retrieved from the blockchain can be decrypted on the server, and thus the decrypted comparison keys are used to calculate the comparison hash value.

[0058] The encryption of the comparison keys can be carried out using one or more security keys, whereby the security keys are in particular only available on the server or only to the user himself, so that unauthorized verification by third parties can be effectively prevented.

[0059] Encryption can be performed using common encryption algorithms, with both symmetric and asymmetric encryption possible. In the case of symmetric encryption, the comparison key is encrypted when entered into the blockchain using the same security key that is used to decrypt the encrypted comparison key on the server. In the case of asymmetric encryption, a different security key can be used to encrypt the comparison key than to decrypt the encrypted comparison key on the server.

[0060] According to one embodiment of the invention, a first part of the comparison keys stored in the blockchain can be encrypted with a first security key.

[0061] In addition, according to a further embodiment, a second part of the comparison keys stored in the blockchain can be encrypted with a second security key.

[0062] In this way, the security of the process can be further increased by using different security keys to encrypt the comparison keys. For example, parts of the comparison keys in the blockchain can be made available only to a specific group of participants who know the respective security key by using separate security keys. Other groups of participants do not have access to the encrypted part of the comparison keys and thus cannot verify the tags. Participants can be servers that perform the verification, devices, readers, manufacturers (of tags or products), or users.

[0063] According to one embodiment, multiple servers can retrieve comparison keys from a blockchain for the verification of labels, with each server being assigned a set of comparison keys and each server having a security key for decrypting the assigned comparison keys. This allows the creation of a central blockchain, which can be used for verification. different labels or products from different manufacturers simultaneously, without the manufacturers being able to influence or falsify each other's label verification process. The central blockchain creates a "true" data set independent of the individual manufacturers and confirmed by all participants ("Single Source of Truth" SSOT).

[0064] In other words, partitions of comparison keys are created in the blockchain, each of which can be assigned to a participant (owner, publisher or manufacturer of labels or products).

[0065] If multiple servers are configured to verify labels against the blockchain, the servers can also be used for decentralized storage of the blockchain. The servers can also act as validators of new blocks, thus fulfilling the blockchain's consensus mechanism by creating new blocks using a consensus process (proof of work, proof of stake, etc.) and then appending them to the blockchain.

[0066] According to one embodiment of the invention, every request from a server to the blockchain for the verification of a tag is stored as a transaction in a block of the blockchain. This allows every verification or verification attempt of a tag to be seamlessly recorded in the blockchain, allowing monitoring for attempted forgery or attacks and detecting malicious attacks.

[0067] According to one embodiment, the security key can be manually entered by a user on the reader; for example, by prompting the user to read the security key from the label or product and enter it into the reader. This allows an additional layer of security to be introduced, whereby authenticity checks or verification can only be performed when the user is in physical possession of the product or label.

[0068] According to one embodiment, the security key can be stored on a secondary electronic circuit. Such a secondary circuit can, for example, be a chip integrated into a smart card (key card) or attached to or in a product. The secondary circuit can preferably be read by the reader. Alternatively, a secondary reader can also be used to read the secondary electronic circuit.

[0069] According to the previously mentioned embodiments, the security key can be transmitted from the reader to the server for verification. According to an alternative embodiment, a partial result of the verification can be calculated on the server and This partial result is transferred back to the reader for complete verification, with the verification ultimately taking place at the reader.

[0070] According to another variant, a device property or parameter of the reader can also be used as the security key. For example, the MAC address or a serial number of the reader can be used as the security key.

[0071] According to a further embodiment, the ownership of the label or a product to which a label is attached can be stored in a block of the blockchain. Thus, the method according to the invention can perform not only an authenticity check but also an ownership check and verify the ownership of the label or product depending on the user and / or the reader. For example, by scanning the label, the authenticity of the product can be determined and it can be verified whether the user scanning the label is the owner of the label or the product with the label.

[0072] According to one embodiment, a user ID can be transmitted from the reader to the server for the purpose of checking the status of the card, whereby the user ID is linked to the user's reader.

[0073] According to one embodiment, the user identifier can be a username or an identification number of a digital wallet, and the tag can be linked to an NFT (non-fungible token) in the blockchain. Ownership of the tag or product can thus be linked to ownership of the associated NFT, with the server comparing the owner of the NFT with the user of the reader for ownership verification.

[0074] According to one embodiment, the electronic tag can be integrated into a key card, and the reader can be a door lock. In this case, an authorization attribute, which allows access to or locking of the door lock, for example, can also be stored in the blockchain or in a database.

[0075] For example, every read operation by the door lock can be stored in a blockchain block, especially along with a timestamp. This allows a complete history of opening requests to the door lock to be documented.

[0076] In particular, in the case of electronic devices, the label may, according to one embodiment, be integrated into an electronic circuit of the device.

[0077] In the system according to the invention, as described above, in particular the electronic label and / or reader and / or server can be programmed accordingly to carry out the method according to one of claims 1 to 16. Short description of the characters

[0078] Preferred embodiments of the invention are described in more detail below with reference to the drawings. They show: Fig. 1 is a schematic representation of a system according to a first embodiment of the invention, Fig. 2 schematic representation of a method according to a first embodiment of the invention, Fig. 3 is a schematic flow diagram of a method according to a second embodiment of the invention, and Fig. 4 is a schematic flow diagram of a method according to a third embodiment of the invention. Ways to implement the invention

[0079] The system 100 according to the invention is described below by way of example with reference to the embodiments shown in the figures.

[0080] According to Fig. 1, a schematic representation of a system 100 according to a first embodiment of the invention is shown.

[0081] The system 100 comprises an electronic label 1 integrated into a product 50. The label 1 can be permanently installed in the product 50 or attached to the product 50. The product 50 is illustrated in Fig. 1 as an example of a handbag 51, with the label 1 integrated or sewn into an inner lining of the handbag 51. However, the system 100, as described below, can be implemented regardless of the type of product 50, and the electronic label 1 can be integrated into or attached to any physical product.

[0082] The electronic tag 1, in turn, has an integrated circuit 2 in which data 3 is stored. As shown in the example, the data 3 includes an identifier for uniquely identifying the tag UID, an incremental counter CNT, and a private key PKEY; however, further data not shown may also be stored. The private key PKEY cannot be extracted from the electronic label, but is stored as secret information which is only accessible to the integrated circuit 2 itself.

[0083] The integrated circuit 2 is programmed in particular to increase the counter value CNT by one during a readout process and thus to transfer the current number of previous readout processes as the counter value CNT.

[0084] In addition, the integrated circuit 2 in the electronic label 1 is programmed to calculate a hash value from the data 3 during a readout process. In particular, the readable data, i.e., the identifier UID, the counter value CNT, and possibly other data, are "encrypted" with the private key PKEY to form the hash value HASH. The cryptographic hash function used is preferably an OMAC algorithm. For a more detailed description, reference is made to the above description of the invention.

[0085] To read the data 3, the electronic label 1 has a transmitting device 4 for transmitting data to a reading device 5. According to the embodiment shown in Fig. 1, the transmitting device 4 is designed as an RFID transponder, wherein the reading device 5 transmits a read request to the electronic label 1 via radio waves, and the electronic label 1 responds by sending the readable data 3 in the form of a message to the reading device 5.

[0086] According to the illustrated embodiment, the message is a character string representing a URI (Uniform Resource Identifier), which can be received by the reader and opened as a web address. The URI directly contains the data read from the electronic label 1. The read data preferably includes the unique identifier UID, the counter value CNT, and the hash value HASH calculated by the integrated circuit.

[0087] On the reader 5, which is depicted in Fig. 1 as a smartphone 6, the URI can be resolved, for example, via a browser or a corresponding program (app). By calling the URI, the data transmitted in the message to the reader 5 is forwarded to a server 7.

[0088] The transmission or communication between reader 5 and server 7 takes place via a network 8. Network 8 is preferably connected to the Internet and can be accessed by smartphone 6, for example, via WLAN (wireless LAN) or via a radio network (e.g., GPRS, UMTS, LTE, or 2G, 3G, 4G, 5G, etc.). Server 7 can thus be located at a different location than reader 5 or can receive and process requests from different readers 5.

[0089] Server 7 serves to verify the transmitted data; in particular, server 7 performs an authenticity check, which compares the transmitted data read from electronic label 1 with the aid of a blockchain 9. Blockchain 9 can be stored in its entirety on server 7. At the same time, blockchain 9 can also be stored on other servers, as schematically indicated in Fig. 1.

[0090] According to the first implementation variant, encrypted private keys (CPKEY) for each UID are stored in blockchain 9. To calculate the CPKEY, the PKEY of an electronic tag is encrypted with a security key (SKEY). This encryption is fully reversible and serves to secure the public data in the blockchain.

[0091] Server 7 is also connected to a database 10, in which the SKEYs for each UID are stored. This allows server 7 to decrypt the CPKEYs stored in blockchain 9 with the respective SKEY to obtain the PKEY for a UID.

[0092] Using the calculated PKEY on server 7, a comparison hash value can be calculated from the transmitted data, in particular from the UID and COUNT, using the same cryptographic hash function as in the electronic label 1. The comparison hash value can then be compared with the transmitted hash value, whereby, if there is a match, the authenticity of the electronic label 1 or the product 50 can be verified.

[0093] The server 7 can then transmit the result of the authenticity check or verification back to the reader 5, where this result can be processed or output by the reader 5. In particular, if the reader 5 opens the URI in a browser or program, the result can be displayed by the server directly in the browser or program, preferably as an HTML document.

[0094] According to the first embodiment, the reader 5 and the server 7 are programmed to carry out the above-mentioned steps.

[0095] Alternatively, according to a further embodiment variant, which is not shown in detail in the figures, comparison hash values ​​for different counter values ​​can be stored in the blockchain 9 for each UID. The server 7 can perform a verification or authenticity check by directly retrieving the comparison hash values ​​from the blockchain and comparing them with the transmitted hash value.

[0096] In the following, the method 200, 201, 202 according to the invention is illustrated by way of example using various embodiments.

[0097] The methods 200, 201, 202 described below can be carried out by means of the system 100 according to the invention, wherein the electronic label 1 or integrated circuit 2, the reader 5 and the server 7 are programmed to carry out the steps of the method 200, 201, 202.

[0098] Figure 2 shows a schematic representation of method 200 according to a first embodiment. Method 200 comprises the steps described below in chronological order.

[0099] In step 210, data 3 and a hash value are read from an electronic tag 1 using a reader 5. As previously described, the electronic tag 1 comprises an integrated circuit 2, which generates a hash value from the (readable) data 3 stored in the electronic tag 1 during a readout process.

[0100] Reading 210 can be initiated, for example, by holding reader 5 near tag 1, especially if electronic tag 1 and reader 5 communicate with each other via RFID / NFC. Reader 5 continuously emits radio waves, which are received by the RFID transponder of tag 1 and initiate a reading process. Tag 1 then sends the requested data directly back to reader 5.

[0101] RFID or NFC communication between reader 5 and tag 1 has the advantage that communication only works in the near field, which makes eavesdropping on the communication between reader 5 and tag 1 difficult or impossible.

[0102] In the subsequent step 220, the data read from the electronic label 1 is transmitted to a server 7 to verify the authenticity of the electronic label. This transmission can be carried out particularly easily, as described above with reference to Fig. 1, if the data read from the electronic label 1 is in the form of a URI, which can be resolved and accessed on the reading device. The URI then refers to a network address of the server 7 and contains all data to be transmitted to the server 7, in particular the hash value and the read data, such as UID and COUNT.

[0103] In step 230, a verification of the data, in particular of the hash value, is now carried out on the server 7 in order to determine whether the electronic label 1 or the associated labeled product 50 is genuine and not a counterfeit. To do this, server 7 attempts to verify or confirm the hash value calculated from label 1.

[0104] According to the invention, this verification of the electronic label 1 is carried out using a blockchain 9. For this purpose, the server 7 retrieves a verification parameter from the blockchain 9, which can be used to verify the hash value. Such a verification parameter can, for example, be a comparison hash value according to one embodiment; according to another embodiment, this can also be a comparison key, which is used to calculate the comparison hash value on the server 7.

[0105] In step 240, the verification result is transmitted from server 7 back to reader 5. If the data was transmitted in the form of a URI, this can occur as a result of retrieving the URI. Reader 5 retrieves the URI and waits until server 7 provides a response.

[0106] In step 250, the retrieved verification result can now be processed accordingly on reader 5. The result can be output directly, for example, as an indicator of whether the electronic label is authentic or not.

[0107] Figure 3 shows a schematic flow diagram of method 201 according to a second embodiment. Method 201 comprises steps 210 to 250 previously described with reference to Figure 2, with the special features listed below.

[0108] As shown in Fig. 3, in step 210, the reader 5 reads a UID and the calculated hash value HASH from the electronic label 1 and transmits it further from the reader 5 to the server 7 in step 220.

[0109] The verification 230 of the hash value HASH on the server 7 is then carried out according to the embodiment shown using steps 231 to 233 as described below.

[0110] In step 231, the UID is transferred to the blockchain 9 and, using a program in the blockchain 9, an associated comparison hash value CHASH is retrieved for the UID.

[0111] In step 232, the CHASH is transferred back to the server 7, where it is compared in the following step 233 with the HASH transferred by the reader and If there is a match, the verification or authenticity of the electronic label 1 is established.

[0112] The verification result is then transmitted back to the reader in step 240.

[0113] According to a further embodiment, which is not illustrated in detail in the figures, the comparison hash value CHASH stored in blockchain 9 is a truncated hash value, i.e., it contains only a certain number of characters of the hash value, but not the entire hash value. In step 233 on server 7, the (truncated) CHASH is then compared with the corresponding part of the transmitted HASH to determine the verification of electronic tag 1.

[0114] Figure 4 shows a schematic flow diagram of method 202 according to a third embodiment. Method 202 comprises steps 210 to 250 previously described with reference to Figure 2, with the special features listed below.

[0115] As shown in Fig. 4, in step 210 the reader 5 reads the UID, the CNT and the calculated hash value HASH from the electronic label 1 as data and transmits them further from the reader 5 to the server 7 in step 220.

[0116] The verification 230 of the hash value on the server 7 is then carried out according to the embodiment shown using steps 231.1, 232.1, 234, 235, 236, 237 and 233.1 as described below.

[0117] In step 231.1, as previously described for Fig. 3, the UID is transmitted to blockchain 9. However, a program in blockchain 9 now retrieves an encrypted comparison key CPKEY associated with the UID. The CPKEY is then transmitted back to server 7 in step 232.1.

[0118] In the subsequent step 234, the UID is transferred to a database 10 connected to server 7, where a security key SKEY is retrieved based on the UID. This SKEY is transferred back to server 7 in step 235.

[0119] Subsequently, in step 236, the CPKEY is decrypted with the SKEY to obtain a comparison key CKEY. The decryption of the CPKEY can be performed using a defined encryption function, which is also used for the initial creation of the CPKEYs in the blockchain 9. The decrypted CKEY should correspond to the private key PKEY on the electronic label 1, which is used to generate the HASH from the data in the integrated circuit 2.

[0120] Finally, in step 237, a comparison hash value CHASH is calculated from the transmitted data, in particular the UID and CNT, using a cryptographic hash function including the CKEY. Since the CKEY and PKEY from the electronic tag 1 should be identical, the CHASH generated in this way should match the HASH transmitted from the tag 1 if the tag is genuine.

[0121] Finally, in step 233.1, it is checked whether the CHASH matches the HASH and, if there is a match, the verification or authenticity of the electronic label 1 is determined.

[0122] The embodiments described above can be combined with one another, unless otherwise stated. Furthermore, the embodiments described above can be combined with those described in the description of the invention.

Claims

Patent claims 1. A method for verifying an electronic label (1) for attachment to a product (50), in which readable data and a secret key are stored, wherein the electronic label (1) has an integrated circuit (2) which is designed to calculate a hash value from the data by means of the private key, the method comprising the steps: - reading (210) the data and the hash value from the electronic label (1) by a reader (5), Transferring (220) the data and the hash value from the reader (5) to a server (7), - verifying (230) the hash value on the server (7) by means of a blockchain (9), transmitting (240) the result of the verification (230) from the server (7) to the reading device (5), and - Output and / or processing (250) of the result of the verification (230) on the reading device (5).

2. Method according to claim 1, characterized in that for the verification (230) of the hash value, a verification parameter is requested based on the data from the blockchain (9).

3. Method according to claim 1 or 2, characterized in that the readable data comprise an identifier for uniquely identifying the label (1) and an incremental counter.

4. Method according to claim 3, characterized in that the reading device (5) receives the identifier for uniquely identifying the label and the counter value of the incremental counter when reading the data from the electronic label (1).

5. Method according to one of claims 1 to 4, characterized in that for the verification of the hash value, it is compared with comparison hash values ​​stored in the blockchain (9).

6. Method according to claim 5, characterized in that the comparison hash values ​​stored in the blockchain (9) are precalculated for several counter values.

7. The method according to claim 5 or 6, characterized in that the stored comparison hash values ​​are stored as truncated comparison hash values ​​in the blockchain (9).

8. Method according to one of claims 5 to 7, characterized in that the comparison hash values ​​are stored in a program executed on the blockchain (9), in particular a smart contract, and that the comparison between the hash value and the stored comparison hash values ​​takes place when the program is executed.

9. The method according to one of claims 1 to 8, characterized in that for the verification (230) of the hash value, the server retrieves a comparison key from the blockchain, calculates a comparison hash value from the received data and the comparison key by means of a cryptographic function and compares the hash value with the comparison hash value.

10. The method according to claim 9, characterized in that a comparison key is stored in the blockchain (9) for each identifier for the unique identification of the label.

11. Method according to claim 10, characterized in that the comparison keys are stored in a program executed on the blockchain (9) and that the program outputs a comparison key depending on data assigned to a label.

12. Method according to one of claims 9 to 11, characterized in that the comparison keys stored in the blockchain (9) are encrypted.

13. The method according to claim 12, characterized in that the comparison key retrieved from the blockchain (9) is decrypted on the server (7), and the decrypted comparison key is used to calculate the comparison hash value.

14. The method according to claim 12 or 13, characterized in that a first part of the comparison keys stored in the blockchain (9) is encrypted with a first security key.

15. The method according to claim 14, characterized in that a second part of the comparison keys stored in the blockchain (9) is encrypted with a second security key.

16. Method according to one of claims 12 to 15, characterized in that a security key is used for the encryption and decryption of the comparison keys, which security key is stored in particular in a database (10) on the server (7).

17. A system comprising an electronic label (1) with an integrated circuit (2) for attachment to a product (50), a reader (5) for reading data from the electronic label (1), and a server (7) connected to the reader (5) via a network (8) for exchanging data, wherein the integrated circuit (2) has a memory in which readable data and a secret key are stored, and is designed to calculate a hash value from the stored data and the secret key using a cryptographic function when read by a reader (5) and to send it to the reader (5), and wherein the reader (5) is designed to receive the hash value from the electronic label (1) and send it to a server (7) for verification, and is designed to receive a result of the verification from the server (7) and to process and / or output it, and wherein the server (7) is designed toto receive the hash value from the reading device (5) and to verify it by means of a blockchain (9) and is designed to send the result of the verification to the reading device (5).

18. System according to claim 17, characterized in that the electronic label (1) is designed such that the secret key cannot be read by a reading device (1).

19. System according to claim 17 or 18, characterized in that the integrated circuit (2) has an incremental counter in the memory and is designed to increase the incremental counter during a read operation and to calculate the hash value from the counter value, optionally further data and the secret key by means of a cryptographic function.

20. System according to one of claims 17 to 19, characterized in that the reading device (5) is a smartphone (6), an RFID reader, a door lock or a smart lock.

Images