AT526983A1 - Method for verifying an electronic label and system therefor - Google Patents

Abstract

The present invention relates to a method (200, 201, 202) 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 using the private key. In addition, the present invention relates to a system (100) 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.

Description

15

20

25

30

22033P-AT1/26

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, and to a system comprising an electronic label, a reader

and a server.

State of the art

[0002] Methods and systems for anti-counterfeiting and authenticity verification of products are known in various forms from the state of the art. In particular, determining the authenticity of a product is of great importance for both manufacturers and consumers in order to distinguish originals from counterfeits.

to be able to.

[0003] For example, labels can be sewn into clothing items that have special security features to verify the authenticity of the garment. Such labels can also be electronically read by means of a reader.

be designed to be readable.

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

appear as “real” in the corresponding database.

Disclosure of the invention

[0005] The present invention therefore has the task of making a method of the type mentioned at the outset more forgery-proof or of providing a method for verification which increases the forgery-proofness of products

can increase.

15

20

25

30

22033P-AT2/26

[0006] The invention solves the problem by 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 to a physical product, for example, in order 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 generate a hash value from the data using the secret key.

calculate.

[0008] The method comprises the following steps:

a) Reading data from the electronic label by a reader, whereby the

read data contain at least the hash value, b) transfer of the read data from the reader to a server, c) verification of the hash value on the server using a blockchain,

d) Transferring the verification result from the server to the reader,

and

e) Output and/or processing of the verification result on the reader.

[0009] According to a further aspect of the present invention, a system 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

shown.

[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 generate a hash value from the stored data and the

to calculate the secret key and send it to the reader.

[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 and process a result of the verification from the server and/or

to spend.

15

20

25

30

22033P-AT3/26

[0012] According to the invention, the server is designed to receive the hash value from the reader and to verify it by means of a blockchain and to

verification to the reader.

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

electronic label is directly integrated.

[0014] It is generally stated that a blockchain in the sense 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 character strings that are generated by a hash function (a mathematical algorithm) that takes 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 lead to significantly different hash values.

[0016] Hash functions are regularly used in cryptographic protocols such as digital signatures and message authentication codes (MAC). 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, as the sender can attach the MAC to the message and the receiver can verify the MAC by back-calculating from the received message using the same private key to ensure that

the received message has not been altered or comes from a secure source.

15

20

25

30

22033P-AT4/26

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

and comfortably.

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

electronic contact is established between the label and the reader).

[0019] If the read data is transferred from the reader to a server, the authenticity check can be carried out independently of the reader. In addition, the data set required for verification or authenticity check does not have to be kept redundant on each reader. This also ensures that each reader always has access to the current data set and does not

retrieves 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, since the data required for verification and stored in the blockchain are resistant to manipulation. In conventional authenticity verification procedures, the data required for verification is usually stored in (private) databases. This gives both the owner of the database and hackers or intruders from outside the database the opportunity to change, add or delete database entries and thus manipulate the authenticity check. However, if the data required for verification is stored in a blockchain, the security

protection against manipulation can be significantly increased.

[0021] Data stored in blockchains is considered more secure against manipulation than data stored in traditional databases for several reasons.

The following factors are particularly relevant:

- Immutability: Once data is entered into a blockchain, it can no longer be changed or deleted. This makes it difficult for attackers

much more difficult to manipulate the data;

- Decentralization: In a traditional database, the data is stored at a

stored in a single location, which makes attacks easier. In contrast,

15

20

25

30

22033P-AT5/26

Blockchains store the data on a network of computers, making it much easier for attackers

makes it harder to gain control over all copies;

- Cryptography: Blockchains use cryptographic techniques to secure the data, such as digital signatures and hashing algorithms. This provides an additional layer of security to prevent unauthorized access and manipulation

to counteract;

- Transparency: It is usually possible to track every transaction history in a blockchain, making it easier to detect suspicious activity.

recognize; and finally

- Consensus: In a blockchain network, several parties must reach a consensus before new data can be added to the chain.

makes it much more difficult for attackers to falsify the data.

[0022] By combining at least some of the above factors,

the security against counterfeiting of electronic labels can be significantly increased.

[0023] According to the invention, the result of the verification is then transmitted back from the server to the reading device and finally the result of the verification is output or further processed on the reading device. Thus, a verification of the authenticity of the label can be carried out independently of the reading device using a blockchain, which

This significantly limits the possibilities for counterfeiting.

[0024] In summary, the invention provides a method for authenticating or verifying an electronic label which is attached to a

Product may be attached or integrated.

[0025] Further embodiments of the invention are presented below. The embodiments shown, or individual aspects of the embodiments,

can be combined with each other as desired, unless otherwise stated.

[0026] According to an 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

take place:

- Wireless: The transfer of data between the label and the reader can be carried out electronically without contact, i.e. wirelessly, for example using RFID or NFC technology. Physical contact between the label and the reader is

not necessary;

15

20

25

30

35

22033P-AT6/26

- 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 the product.

or be digitally displayed 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 can have a magnetic stripe or be encoded in a

Magnetic stripe card must be included;

- Smartcard reading: When reading smartcards or chip cards, a contactless or contact-based interface is used to read data stored on the label. The label can have a contact zone with contact surfaces that can be connected to the contacts of a reader.

can be brought to read 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 can have a camera that can read the text printed on the label or product.

can capture text.

- OQR 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 takes a picture of the QR code and decrypts it. The QR code can

be printed or affixed to the label or product.

[0027] As previously mentioned, 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 sent as a QR code or writing or text on

printed on the label and captured by a camera on the reader.

[0028] According to a preferred embodiment, the data can be read from the electronic label using an RFID reader. RFID (radio frequency identification) uses radio waves for communication between the reader and the label. The reader sends out a radio signal, which is received by the antenna of the tag, thereby starting a reading process. This start of the reading process can be initiated, for example, by bringing the reader close to the label. The label then sends back data, which is received by the reader.

can be received and read. In this way, data can be transmitted electronically from

7732

15

20

25

30

22033P-AT7/26

an electronic label without physical contact or

Line of sight between the label and the reader is required.

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

To eavesdrop on communication between the label and the reader.

[0030] According to one embodiment, the transmission of data from the reader to the server can preferably take place via a network in which the reader and server are located. This allows a physical separation between the server and the reader to be established, whereby the server can centrally receive and process requests from different readers. Such a network can be a private LAN or WLAN network, as well as a public network, such as the Internet. In particular, when transmitting via a public network, the

Communication between the reader and the server is encrypted.

[0031] According to a further embodiment, the server can be implemented on the reader itself, whereby the data from the reader is transmitted internally directly to the server. The server can then handle the verification requests in a decentralized manner, like many similar servers, thereby reducing the request times and server loads.

and server downtime can be minimized.

[0032] For the transmission from the server back to the reader, the previously

The design variants described are applicable analogously.

[0033] According to one embodiment, the reader can output the result of the verification on the reader visually, audibly or haptically. The output can be a visual indication of the verification result, for example a colored LED or the output of text or symbols on a screen. Alternatively, a sound or a sequence of sounds can be output which reflects the verification result. According to another possibility, the verification result can also be displayed as

haptic stimulus (such as a vibration).

[0034] According to one embodiment, the reading device can be a smartphone or a portable computer. Preferably, the smartphone has an RFID or NFC reader with which the electronic label is read. The received data is then transferred to the server and the result obtained from the server can be

displayed on a smartphone display.

15

20

25

30

35

22033P-AT8/26

[0035] According to an embodiment of the invention, a verification parameter can be requested from the blockchain based on the data received from the reading device in order to verify the hash value. The verification parameter can be, for example, a comparison value based on which a verification of the hash value is carried out. Alternatively, the verification parameter can also be used to provide a comparison value on the

Server which can be used to verify the hash value.

[0036] According to an 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 in the course of corresponding program sequences in the integrated circuit.

where the counter value cannot be decreased.

[0037] According to a further embodiment of the invention, the reading device 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, other data or information stored on the electronic label (for example identification codes,

strings, etc.) can be received.

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

which 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), whereby opening or querying the URL/URI on the reader transfers the data to the server and the result of the verification is output. In this way, a large number of readers can be used to read the electronic labels in a particularly simple manner, without special software or programs being required on the

readers must be provided.

15

20

25

30

22033P-AT 9/26

[0040] For this purpose, the data transmitted from the label to the reader or the transmitted message can be contained in the URL/URI (for example 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 data transmitted to the reader

The returned result can be received in the form of an http response.

[0041] According to a variant embodiment of the invention, the integrated circuit of the electronic label can be programmed to increase the incremental counter when reading data. The counter value can thus represent the number of

Reflect reading operations of the electronic label.

[0042] According to an 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 to send it together with the data to the reader. The hash value can serve as a checksum or digital signature and thus, by incorporating the secret key, can create a

represent a forgery-proof certificate for the authenticity of the label.

[0043] If the hash value is also calculated from the data that includes the incremental counter, a unique hash value can be generated each time it is read out,

which further increases the counterfeit security of the electronic label.

[0044] According to one embodiment, the reading device can read a message containing the data from the electronic label, the message preferably having an identifier for unique identification and the current counter value. The entire message is then used to calculate the hash value, the hash value being 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), the message being authenticated with the one on the electronic label.

stored secret key.

[0045] According to a further embodiment, the hash value can also be generated by 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 out to generate the

The hash value can then be verified first with the primary key and then again with the

15

20

25

30

35

22033P-AT 10/26

secondary key. In this way, either two hash values or

a doubly encrypted hash value is generated.

[0046] According to a further embodiment, the hash value can be verified by comparing it with comparison hash values stored in the blockchain. The blockchain can thus contain comparison hash values as verification parameters, with which the hash values received from the reader can be compared in order to carry out the verification of the electronic label. The hash values stored in the blockchain are thus unchangeable and cannot be manipulated. The possible hash values can be pre-calculated for a specific electronic label and stored in advance in the blockchain. A particularly simple and secure verification process can be created in this way, since the

Verification can only be done using or through the blockchain.

[0047] According to one embodiment variant, 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 set of the electronic label (such as the unique identifier) using the private key. Since the manufacturer of the electronic labels 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 without knowledge of the private key after the initial pre-filling of the blockchain. By only storing the pre-calculated hash values in the blockchain, active knowledge of the private key on the server is not necessary in order to

To be able to check the authenticity of the electronic label.

[0048] According to a further embodiment, the stored comparison hash values can be stored as truncated comparison hash values in the blockchain. Such truncated comparison hash values can be obtained, for example, by cutting off or trimming the calculated hash values. In this case, not all of the hash values can be stored in the blockchain, but only the first/last 10/20/30, etc. characters of the calculated hash value. Calculating back to the private key or randomly guessing the message or secret through many attempts is thus made much more difficult. For verification, only the first characters of the hash value received from the reader are compared with the characters in the blockchain.

stored comparison hash values.

15

20

25

30

35

22033P-AT 11/26

[0049] According to a further embodiment, the comparison hash values can be stored in a program executed on the blockchain, and the comparison between the hash value and the stored comparison hash values can be carried out 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 the smart contract has the advantage that control over the

stored values remain within the sphere of influence of the blockchain operator.

[0050] According to a further embodiment, in order 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 label and is thus used to check the hash value sent by the electronic label. The comparison key can be retrieved by the server from the blockchain depending on the data received. For example, the received data can contain an identifier for uniquely identifying the electronic label and the comparison key can be retrieved from the blockchain for the respective identifier. The comparison key is then used on the server to calculate a comparison hash value from the data received from the reader, whereby the server preferably uses the same cryptographic hash function or the same encryption algorithm as the circuit integrated in the electronic label. The calculated comparison hash value can thus be used to verify the authenticity of the calculated comparison hash value

compare with the received hash value.

[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 further data can be used for

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 integrated circuit of the electronic label to calculate the hash value, which is not sent to the reader when the data is read from the electronic label. This secret character string

can also be stored on the server, for example in a private database, and

15

20

25

30

22033P-AT 12/26

when calculating the comparison hash value on the server with the comparison key. By including an additional secret or a secondary key, verification cannot be carried out using the blockchain alone without knowledge of the secret. Bypassing the server during verification

is therefore not possible, which further increases the security against counterfeiting.

[0053] According to an embodiment of the invention, a comparison key can be stored in the blockchain for each identifier for the unique identification of the label. The server can thus, after receiving the data from the reader, which in particular contains the identifier, the appropriate comparison key from the

Retrieve blockchain.

[0054] According to further embodiments, the comparison keys can also be

other data of the electronic label and stored in the blockchain.

[0055] According to a further embodiment, the comparison keys can be stored in a program executed on the blockchain and the program can return a comparison key depending on data associated with an electronic label. 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 the smart contract has the advantage that control over the stored values remains within the sphere of influence of the operator of the blockchain. As previously described, the comparison keys in the program can be linked to data from the label, such as the identifier for unique identification or other properties. For example, the program can use the identifier of the

Record the label and return the corresponding comparison key.

[0056] According to a further embodiment, 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 level 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.

without any risk of bypassing the verification on the server.

[0057] According to a further embodiment, the blockchain

retrieved comparison keys are decrypted on the server, and so the

15

20

25

30

22033P-AT 13/26

decrypted comparison keys to calculate the comparison hash value

be used.

[0058] The encryption of the comparison keys can be carried out with one or more security keys, whereby the security keys are only available on the server or only to the user himself, so that unauthorized

Verification by third parties can be effectively prevented.

[0059] The encryption can be carried out using common encryption algorithms, whereby both symmetric and asymmetric encryption are possible. In the case of symmetric encryption, the comparison key is encrypted when it is entered into the blockchain with 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 keys can be used on the server.

[0060] According to an embodiment of the invention, a first part of the comparison keys stored in the blockchain can be linked to a first security key

be encrypted.

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

be encrypted.

[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 their own security keys, whereby other groups of participants have no access to the encrypted part of the comparison keys and thus cannot carry out the verification of the labels. Participants can include servers that carry out the verification, devices, readers,

Manufacturers (of labels or products) or users.

[0063] According to one embodiment, several servers can retrieve comparison keys from a blockchain for verifying labels, each server being assigned a set of comparison keys and the servers each having a security key for decrypting the assigned comparison keys.

This way, a central blockchain can be created, which can be used to verify

15

20

25

30

35

22033P-AT 14/26

different labels or products from different manufacturers at the same time, without the manufacturers being able to influence or falsify each other's verification process of the labels. The central blockchain creates a "true" data set that is 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 is assigned to a participant (owner, publisher or

manufacturers of labels or products).

[0065] If several servers are set up to verify the labels using the blockchain, the servers can also be used for decentralized storage of the blockchain. The servers can also act as validators of new blocks and thus fulfill the consensus mechanism of the blockchain by creating new blocks using a consensus process (proof of work, proof of stake, etc.).

and then attach it to the blockchain.

[0066] According to one embodiment of the invention, every request from a server to the blockchain to verify a label is stored as a transaction in a block of the blockchain. In this way, every verification or every attempt to verify a label can be recorded seamlessly in the blockchain, which can be used to monitor for attempted forgery or attacks and to detect malicious attacks.

can be.

[0067] According to one embodiment, the security key can be entered manually by a user on the reader, for example by asking the user to read the security key from the label or the product and enter it on the reader. This allows an additional security level to be introduced, whereby an authenticity check or verification can only be carried out if the user

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 in 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 above-mentioned embodiments, the security key can be transmitted from the reader to the server for verification. According to an alternative

In this variant, a partial result of the verification can be calculated on the server and

15

20

25

30

22033P-AT 15/26

Transfer this partial result back to the reader for complete verification Transfer this partial result back to the reader for complete verification

The decoration is finally done on the reader,

[0070] According to a further embodiment, a device property or a device 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.

[0071] According to a further embodiment, the ownership of the label or of a product on which a label is attached can be stored in a block of the blockchain. In addition to an authenticity check, the method according to the invention can also carry out an ownership check and check the ownership of the label or product depending on the user and/or the reading device. For example, by scanning the label, the authenticity of the product can be determined at the same time and it can be checked whether the user who scans the label is the owner of the label or the product.

product with the label,

[0072] According to a variant, a user ID can be transmitted from the reader to the server for the purpose of checking the status of ownership, whereby the

User ID is linked to the user’s reader,

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

compares,

[0074] According to one embodiment, the electronic label can be integrated in a key card and the reader can be a door lock. In this case, an authorization attribute can also be stored in the blockchain or in a database

which allows access to or locking of the door lock.

[0075] For example, every reading process through the door lock can be stored in a block of the blockchain, in particular together with a timestamp.

A seamless history of opening requests to the door lock is documented.

[0076] In particular, for electronic devices, the label may be printed in accordance with a

Design variant integrated in an electronic circuit of the device.

15

20

25

30

22033P-AT16/26

[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] In the following, preferred embodiments of the invention are described with reference to

Drawings are shown in more detail. 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

Variant of the invention.

Ways to implement the invention

[0079] The system 100 according to the invention is described below with reference to the figures

The design variants shown are described as examples.

[0080] According to Fig. 1 is a schematic representation of a system 100 according to a

first embodiment of the invention.

[0081] The system 100 has an electronic label 1 which is integrated in a product 50. The label 1 can be permanently installed in the product 50 or attached to the product 50. The product 50 is shown in Fig. 1 as an example as a handbag 51, wherein the label 1 is integrated or sewn into an inner lining of the handbag 51. The system 100, as described below, can be implemented independently of the type of product 50 and the electronic label 1 can

can be integrated into or attached to any physical product.

[0082] The electronic label 1 in turn has an integrated circuit 2 in which data 3 are stored. As shown by way of example, the data 3 comprise an identifier for the unique identification of the label UID, an incremental counter CNT and a private key PKEY; however, there may also be further, non-

The private key PKEY cannot be removed from the

15

20

25

30

22033P-AT 17/26

electronic label, but is classified 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 determine the current number

to previous reading processes as 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 others, 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 illustration of the

invention.

[0085] To read the data 3, the electronic label 1 has a transmitting device 4 for data transmission 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 sends a read request to the electronic label 1 by means of radio waves and the latter, in response, sends the readable data 3 in the form of a message to the

Reader 5 sends.

[0086] According to the embodiment shown, the message is a character string which represents a URI (Uniform Resource Identifier) which can be received by the reader and opened as a web address. The data read from the electronic label 1 are directly contained in the URI. The read data preferably include 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 shown in Fig. 1 as a smartphone 6, the URI can be resolved, for example, via a browser or via a corresponding program (app). By calling up the URI, the data in the message to the

The data transmitted by the reader 5 is further transmitted to a server 7.

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

Receive and process requests from different readers 5.

15

20

25

30

22033P-AT18/26

[0089] The server 7 serves to verify the data sent; in particular, the server 7 carries out an authenticity check, which compares the transmitted data read from the electronic label 1 with the help of a blockchain 9. The blockchain 9 can be stored in its entirety on the server 7. At the same time, the blockchain 9 can also be stored on other servers, which is shown in Fig. 1

was indicated schematically.

[0090] According to the first embodiment, encrypted private keys CPKEY are stored for each UID in the blockchain 9, whereby the PKEY of an electronic label is encrypted with a security key SKEY to calculate the CPKEY. This encryption is fully reversible and serves to protect the public data in the

to secure the blockchain.

[0091] The server 7 is further connected to a database 10 in which the SKEYs are stored for each UID. This enables the server 7 to use the data stored in the blockchain 9.

Decrypt CPKEYSs with the respective SKEY to obtain the PKEY to a UID.

[0092] Using the calculated PKEY on the server 7, a comparison hash value can thus 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 the program, preferably as an HTML document.

[0094] According to the first embodiment, the reader 5 and the server 7 are designed

programmed to perform the above steps.

[0095] Alternatively, according to a further embodiment, which is not shown in detail in the figures, comparison hash values for different counter values can be stored for each UID in the blockchain 9. The server 7 can thereby directly retrieve the comparison hash values from the blockchain and compare them with the

Perform a verification or authenticity check on the transmitted hash value.

15

20

25

30

22033P-AT19/26

[0096] In the following, the method 200, 201, 202 according to the invention is described with reference to

different design variants are shown as examples.

[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 in such a way as to carry out the steps of the method 200, 201, 202.

[0098] According to Fig. 2, a schematic representation of the method 200 according to a first embodiment is shown. The method 200 has the following

described steps in chronological order.

[0099] In step 210, data 3 and a hash value are read from an electronic label 1 by means of a reader 5. The electronic label 1 has, as previously described, an integrated circuit 2 which consists of the data stored in the electronic label

1 stored (readable) data 3 generates a hash value during a reading process.

[0100] The reading 210 can be initiated, for example, by holding the reader 5 near the label 1, in particular when the electronic label 1 and the reader 5 communicate with each other via RFID/NFC. The reader 5 continuously emits radio waves, which are received by the RFID transponder of the label 1 and start a reading process. The label 1 sends the requested data directly

back to the reader 5.

[0101] An RFID or NFC communication between reader 5 and label 1 has the advantage that the communication only works in the near field, which prevents the

Communication between reader 5 and label 1 is made difficult or impossible.

[0102] In the following step 220, the data read from the electronic label 1 are transmitted to a server 7 in order 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 are in the form of a URI, which can be resolved and called up on the reading device. The URI then refers to a network address of the server 7 and contains all the 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 the

Hash value is checked to determine whether the electronic label 1 or the associated

15

20

25

30

22033P-AT 20/26

labeled product 50 is genuine and not a fake. To do this, the server 7 tries

to understand 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, based on which a verification of the hash value can be carried out. Such a verification parameter can, for example, be a comparison hash value according to one embodiment variant; according to another embodiment variant, this can also be a comparison key which is used for

Calculation of the comparison hash value on server 7.

[0105] In step 240, the result of the verification is transmitted from the server 7 back to the reader 5. If the data was transmitted in the form of a URI, this can happen as a result of retrieving the URI. The reader 5 calls the URI

and waits until server 7 provides a response.

[0106] In step 250, the retrieved result of the verification can now be processed accordingly on the reader 5. The result can thus be output directly,

for example as an indicator of whether the electronic label is genuine or not.

[0107] According to Fig. 3, a schematic flow diagram of the method 201 according to a second embodiment is shown. The method 201 comprises the steps 210 to 250 previously described with reference to Fig. 2, with the following

Special features.

[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

Reader 5 further transmits to 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 follows

described.

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

retrieved.

[0111] In step 232, the CHASH is transferred back to server 7, where it is stored in the

subsequent step 233 is compared with the HASH transmitted by the reader and

15

20

25

30

22033P-AT 21/26

if there is a match, the verification or authenticity of the electronic label 1

is detected.

[0112] The result of the verification is then returned to the

reader.

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

of the electronic label 1.

[0114] According to Fig. 4, a schematic flow diagram of the method 202 according to a third embodiment is shown. The method 202 comprises the steps 210 to 250 previously described with reference to Fig. 2, with the following

Special features.

[0115] As shown in Fig. 4, in step 210 the reader 5 extracts the UID, the CNT and the calculated hash value HASH from the electronic label 1 as data

read out and transmitted 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 the blockchain 9. However, an encrypted comparison key CPKEY associated with the UID is now retrieved using a program in the blockchain 9. The CPKEY is then transmitted back to the server 7 in step 232.1.

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

transmitted.

[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 carried out using a defined encryption function, which is also used for the initial

used to create the CPKEYSs in the blockchain 9. The decrypted CKEY should

15

22033P-AT 22/26

correspond to the private key PKEY on the electronic label 1, which

used to generate the HASH from the data in integrated circuit 2.

[0120] Finally, in step 237, a comparison hash value CHASH is calculated from the transmitted data, in particular UID and CNT, using a cryptographic hash function including the CKEY. Since CKEY and PKEY from the electronic label 1 should be identical, the resulting hash value should be

CHASH must match the HASH transmitted by label 1.

[0121] In step 233.1, it is finally checked whether the CHASH matches the HASH and if they match, the verification or authenticity of the

electronic label 1 was detected.

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

Versions can be combined.

Claims (20)

15 20 25 22033P-AT 23/26 Patent claims 1. 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 using the private key, the method comprising the steps of: - reading (210) the data and the hash value from the electronic label (1) by a reading device (5), - transmitting (220) the data and the hash value from the reading device (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 - outputting and/or processing (250) the result of the verification (230) on the reading device (5). 2. Method according to claim 1, characterized in that for verification (230) of the hash value, a verification parameter is determined based on the data from the blockchain (9) is requested. 3. Method according to claim 1 or 2, characterized in that the readable data comprise an identifier for the unique identification of the label (1) and a incremental counter. 4. Method according to claim 3, characterized in that the reading device (5) when reading the data from the electronic label (1) uses the identifier for unique Identification of the label and the counter value of the incremental counter. 5. Method according to one of claims 1 to 4, characterized in that for verification of the hash value, this is compared with comparison values stored in the blockchain (9). hash values are compared. 6. Method according to claim 5, characterized in that the data stored in the blockchain (9) stored comparison hash values are precalculated for several counter values. 15 20 25 30 22033P-AT24/26 7. 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) are stored. 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 stored comparison hash values when executing the program takes place. 9. Method according to one of claims 1 to 8, characterized in that for 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 the hash value with the comparison hash value. 10. Method according to claim 9, characterized in that in the blockchain (9) for each identifier for the unique identification of the label a comparison key is stored. 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, depending on data associated with a label, generates a Outputs comparison key. 12. Method according to one of claims 9 to 11, characterized in that the are encrypted using the comparison key stored in the blockchain (9). 13. 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 is used. 14. Method according to claim 12 or 13, characterized in that a first part of the comparison keys stored in the blockchain (9) is compared with a first Security key is encrypted. 15. Method according to claim 14, characterized in that a second part of the comparison keys stored in the blockchain (9) is compared with a second Security key is encrypted. 15 20 25 30 22033P-AT25/26 16. Method according to one of claims 12 to 15, characterized in that a security key is used for encryption and decryption of the comparison keys, which is stored in particular in a database (10) on the server (7). is. 17. 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 and process and/or output a result of the verification from the server (7), and wherein the server (7) - is designed to receive the hash value from the reader (5) to receive and verify 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 reader (1). can be read out. 19. System according to claim 17 or 18, characterized in that the integrated circuit (2) in the memory has an incremental counter and is designed to increase the incremental counter during a read operation and to calculate the value of the counter, optionally further data and the secret key by means of a cryptographic Function to calculate the hash value. 20. System according to one of claims 17 to 19, characterized in that the reader (5) is a smartphone (6), an RFID reader, a door lock or a smart Castle is.