EP4681098A1 - Verfahren zur verifizierung eines elektronischen etiketts und system hierzu - Google Patents

Verfahren zur verifizierung eines elektronischen etiketts und system hierzu

Info

Publication number
EP4681098A1
EP4681098A1 EP23731533.8A EP23731533A EP4681098A1 EP 4681098 A1 EP4681098 A1 EP 4681098A1 EP 23731533 A EP23731533 A EP 23731533A EP 4681098 A1 EP4681098 A1 EP 4681098A1
Authority
EP
European Patent Office
Prior art keywords
comparison
blockchain
data
hash value
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23731533.8A
Other languages
English (en)
French (fr)
Inventor
Michael Dorner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Variussystems Digital Solutions GmbH
Original Assignee
Variussystems Digital Solutions GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Variussystems Digital Solutions GmbH filed Critical Variussystems Digital Solutions GmbH
Publication of EP4681098A1 publication Critical patent/EP4681098A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10257—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for protecting the interrogation against piracy attacks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0723—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips the record carrier comprising an arrangement for non-contact communication, e.g. wireless communication circuits on transponder cards, non-contact smart cards or RFIDs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G06Q30/0185—Product, service or business identity fraud
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C5/00—Ciphering apparatus or methods not provided for in the preceding groups, e.g. involving the concealment or deformation of graphic data such as designs, written or printed messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/77—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for interrogation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/47—Security arrangements using identity modules using near field communication [NFC] or radio frequency identification [RFID] modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • the present invention relates to a method for verifying an electronic label for attachment to a product having an integrated circuit, as well as a system comprising an electronic label, a reader and a server.
  • labels can be sewn into items of clothing that have special security features to verify the authenticity of the item of clothing.
  • Such labels can also be designed to be electronically readable using a reader.
  • 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 method for verification which can increase the security against counterfeiting of products.
  • 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.
  • a method for verifying an electronic label 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 calculate a hash value from the data using the secret key.
  • 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.
  • 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.
  • 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.
  • 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.
  • the server is designed to receive the hash value from the reading device and to verify it by means of a blockchain and to send the result of the verification to the reading device.
  • an electronic label refers to any form of "tag" which contains data and is suitable for attachment to or in a product.
  • tags 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.
  • 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.
  • 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' computers.
  • 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.
  • Hash values are generally strings of characters 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.
  • 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.
  • the authenticity check or verification can be carried out particularly easily and conveniently.
  • 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.
  • 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 by establishing electronic contact between the label and the reader).
  • the read data is transferred from the reader to a server, the authenticity check can be carried out independently of the reader.
  • 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 accesses the current data set and does not retrieve outdated or incorrect data.
  • 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.
  • 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.
  • security against manipulation can be significantly increased.
  • Immutability Once data is added to a blockchain, it cannot be changed or deleted. This makes it much more difficult for attackers to manipulate the data;
  • 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;
  • Consensus In a blockchain network, multiple parties must reach consensus before new data can be added to the chain. This makes it much more difficult for attackers to falsify the data.
  • 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.
  • the invention thus provides a method for checking the authenticity or verification of an electronic label, which can be attached to or integrated into a product.
  • the reading of the data from the label by the reader can be carried out using one or more of the following methods:
  • 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;
  • 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 can 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 can have a contact zone with contact surfaces that can be brought into contact with the contacts of a reader to read the data;
  • OCR Optical Character Recognition
  • 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 an image of the QR code and decrypts it.
  • the QR code can in turn be printed or attached to the label or product.
  • 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 is captured by a camera of the reader.
  • the data can be read from the electronic label using an RFID reader.
  • RFID radio frequency identification
  • 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 can be received and read by the reader. In this way, data can be electronically read from an electronic label without requiring physical contact or line of sight between the label and the reader.
  • the RFID reader can be an NFC reader and the electronic label can be an NFC tag, with the reader and label operating according to the NFC standard and 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.
  • the data can preferably be transmitted from the reader to the server via a network in which the reader and server are located.
  • a network in which the reader and server are located.
  • Such a network can be a private LAN or WLAN network, as well as a public network, such as the Internet.
  • the communication between the reader and the server can be encrypted to improve security.
  • 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, whereby the request times and server loads can be reduced and server downtimes can be minimized.
  • 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.
  • a sound or a sequence of sounds can be output which reflects the verification result.
  • the verification result can also be encoded as a haptic stimulus (such as a vibration).
  • the reading device can be a smartphone or a portable computer.
  • the smartphone preferably 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 received from the server can be shown on a display of the smartphone.
  • 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 the hash value is verified.
  • the verification parameter can also be used to calculate a comparison value on the server, which can be used to verify the hash value.
  • the readable data can include 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 that can be incremented, i.e. increased, by the integrated circuit.
  • the counter cannot be changed from outside the label, but only in the course of corresponding program sequences in the integrated circuit, whereby the counter value cannot be decreased.
  • the reading device can receive the identifier for uniquely identifying the label and the counter value when reading the data from the electronic label.
  • other data or information stored on the electronic label for example identification codes, character strings, etc. can also be received.
  • 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 of 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 contains the read data as a message and the hash value as a checksum.
  • 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 reading device transfers the data to the server and the result of the verification is output.
  • a large number of reading devices can be used to read the electronic labels in a particularly simple technical manner without special software or programs having to be provided on the reading devices.
  • 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 result transmitted back to the reader can be received in the form of an http response.
  • the integrated circuit of the electronic label can be programmed to increase the incremental counter when data is read.
  • the counter value can thus reflect the number of times the electronic label has been read.
  • 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 to the reading device together with the data.
  • the hash value can serve as a checksum or digital signature and thus represent a forgery-proof certificate for the authenticity of the label by incorporating the secret key.
  • the hash value is calculated from the data comprising the incremental counter, a unique hash value can be generated each time it is read, which further increases the security against forgery of the electronic label.
  • 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 encrypted using the secret key stored on the electronic label.
  • the hash value can also be generated by an encryption method with more than one key.
  • 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 hash value can then first be carried out with the primary key and then again with the secondary key. In this way, either two hash values or one doubly encrypted hash value can be generated.
  • 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 directly 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, for example, and stored in the blockchain in advance. A particularly simple and secure verification process can be created in this way, since the verification can only be carried out using or by means of the blockchain.
  • the comparison hash values stored in the blockchain can also be pre-calculated for several possible counter values.
  • 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 blockchain has been pre-filled for the first time. 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 be able to carry out an authenticity check of the electronic label.
  • the stored comparison hash values can be stored as truncated comparison hash values in the blockchain.
  • Such truncated comparison hash values can be obtained by cutting or trimming the calculated hash values.
  • 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 by the reader are compared with the comparison hash values stored in the blockchain.
  • 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.
  • 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.
  • the server in order to verify the hash value, 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.
  • 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 compared with the received hash value to verify authenticity.
  • all or part of the data received from the electronic label can be used to calculate the comparison hash value on the server.
  • the data preferably includes the identifier for unique identification and the current counter value, which are encrypted with the comparison key.
  • other or additional data can be used to calculate the hash value.
  • a secret character string or a secondary key can be included in the calculation of the hash value in the integrated circuit of the electronic label, 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 when calculating the comparison hash value on the server with the comparison key.
  • a comparison key can be stored in the blockchain for each identifier for the unique identification of the label.
  • 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.
  • the comparison keys can also be stored in the blockchain linked to other data of the electronic label.
  • 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.
  • 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.
  • 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 record the identifier of the label as a transfer parameter and return the appropriate comparison key for this.
  • 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 and without there being any risk of bypassing the verification on the server.
  • 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.
  • the encryption of the comparison keys can be carried out with 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.
  • the encryption can be carried out using common encryption algorithms, whereby both symmetric and asymmetric encryption are possible.
  • the comparison key is encrypted when entered into the blockchain with the same security key that is used to decrypt the encrypted comparison key on the server.
  • a different security key can be used to encrypt the comparison key than to decrypt the encrypted comparison key on the server.
  • a first part of the comparison keys stored in the blockchain can be encrypted with a first security key.
  • a second part of the comparison keys stored in the blockchain can be encrypted with a second security key.
  • the security of the process can be further increased by using different security keys to encrypt the comparison keys.
  • 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 verify the labels.
  • Participants can be understood as servers that carry out the verification, devices, readers, manufacturers (of labels or products) or users.
  • several servers can retrieve comparison keys from a blockchain for verifying labels, with each server being assigned a set of comparison keys and the servers each having a security key for decrypting the assigned comparison keys.
  • a central blockchain can be created which can be used for verification 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).
  • 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).
  • 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 attaching them to the blockchain.
  • every request from a server to the blockchain to verify a label is stored as a transaction in a block of the blockchain.
  • every verification or every attempt to verify a label can be recorded seamlessly in the blockchain, which makes it possible to monitor for attempted forgery or attacks and to detect malicious attacks.
  • the security key can be manually entered into the reader by a user; for example, by asking the user to read the security key from the label or the product and enter it into the reader.
  • an additional security level can be introduced, whereby an authenticity check or verification can only be carried out if the user is in physical possession of the product or label.
  • the security key can be stored on a secondary electronic circuit.
  • a secondary circuit can, for example, be a chip integrated in a smart card (key card) or attached in or to a product.
  • the secondary circuit can preferably be read by the reader.
  • a secondary reader can also be used to read the secondary electronic circuit.
  • the security key can be transmitted from the reader to the server for verification.
  • 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.
  • a device property or a device parameter of the reader can also be used as the security key.
  • the security key For example, the MAC address or a serial number of the reader can be used as the security key.
  • the ownership of the label or of a product on which a label is attached can be stored in a block of the blockchain.
  • 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 with the label.
  • a user identifier can be transmitted from the reader to the server for the purpose of checking ownership, the user identifier being linked to the user's reader.
  • the user identifier 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 NFT with the user of the reader for ownership verification.
  • NFT non-fungible token
  • the electronic label can be integrated in a key card and the reader can be a door lock.
  • an authorization attribute can also be stored in the blockchain or in a database, which allows access to or locking of the door lock.
  • every reading process by the door lock can be stored in a block of the blockchain, in particular together with a timestamp. In this way, a seamless history of opening requests to the door lock can be documented.
  • the label can, according to one embodiment, be integrated into an electronic circuit of the device.
  • 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.
  • 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.
  • Fig. 4 is a schematic flow diagram of a method according to a third embodiment of the invention.
  • FIG. 1 a schematic representation of a system 100 according to a first embodiment of the invention is shown.
  • 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, with the label 1 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 be integrated into any physical product or attached to it.
  • the electronic label 1 in turn has an integrated circuit 2 in which data 3 are stored.
  • the data 3 comprise an identifier for uniquely identifying the label UID, an incremental counter CNT and a private key PKEY; however, further data not shown can also be stored.
  • the private key PKEY cannot be taken from the electronic label, but is stored as secret information which is only accessible to the integrated circuit 2 itself.
  • the integrated circuit 2 is programmed in particular to increase the counter value CNT by one during a read-out process and thus to transfer the current number of previous read-out processes as the counter value CNT.
  • the integrated circuit 2 in the electronic label 1 is programmed to calculate a hash value from the data 3 during a readout process.
  • 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.
  • the electronic label 1 has a transmitting device 4 for transmitting data to a reading device 5.
  • 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 sends the readable data 3 in the form of a message to the reading device 5 in response.
  • 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.
  • the URI can be resolved, for example, via a browser or via a corresponding program (app).
  • the data transmitted in the message to the reading device 5 is transmitted to a server 7.
  • 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, 5G, 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 reading devices 5.
  • 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 was indicated schematically in Fig. 1.
  • 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 secure the public data in the blockchain.
  • the server 7 is further connected to a database 10 in which the SKEYs are stored for each UID. This allows the server 7 to decrypt the CPKEYs stored in the blockchain 9 with the respective SKEY in order to obtain the PKEY for a UID.
  • 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.
  • 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.
  • this result can be processed or output by the reader 5.
  • 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.
  • the reader 5 and the server 7 are programmed to carry out the above-mentioned steps.
  • comparison hash values for different counter values can be stored for each UID in the blockchain 9.
  • the server 7 can carry out a verification or authenticity check by directly retrieving the comparison hash values from the blockchain and comparing them with the transmitted hash value.
  • 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.
  • FIG. 2 a schematic representation of the method 200 according to a first embodiment is shown.
  • the method 200 has the steps described below in chronological order.
  • step 210 data 3 and a hash value are read from an electronic label 1 using a reading device 5.
  • the electronic label 1 has, as previously described, an integrated circuit 2 which generates a hash value from the (readable) data 3 stored in the electronic label 1 during a reading process.
  • 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.
  • An RFID or NFC communication between reader 5 and label 1 has the advantage that the communication only works in the near field, which makes it difficult or impossible to intercept the communication between reader 5 and label 1.
  • 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 is 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.
  • step 230 a verification of the data, in particular 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 fake. To do this, server 7 attempts to understand or confirm the hash value calculated from label 1.
  • this verification of the electronic label 1 is carried out using a blockchain 9.
  • the server 7 retrieves a verification parameter from the blockchain 9, based on which the hash value can be verified.
  • 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 to calculate the comparison hash value on the server 7.
  • 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 retrieves the URI and waits until the server 7 provides a response.
  • 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.
  • FIG. 3 a schematic flow diagram of the method 201 according to a second embodiment is shown.
  • the method 201 has the steps 210 to 250 previously described with reference to Fig. 2, with the special features listed below.
  • a UID and the calculated hash value HASH are read from the electronic label 1 by the reader 5 and further transmitted by the reader 5 to the server 7 in step 220.
  • step 231 the UID is transmitted to the blockchain 9 and a comparison hash value CHASH associated with the UID is retrieved using a program in the blockchain 9.
  • step 232 the CHASH is transmitted back to the server 7, where it is compared in the following step 233 with the HASH transmitted by the reader and If there is a match, the verification or authenticity of the electronic label 1 is established.
  • 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.
  • the (truncated) CHASH is then compared with the corresponding part of the transmitted HASH in order to determine the verification of the electronic label 1.
  • FIG. 4 a schematic flow diagram of the method 202 according to a third embodiment is shown.
  • the method 202 has the steps 210 to 250 previously described with reference to Fig. 2, with the special features listed below.
  • step 210 the UID, the CNT and the calculated hash value HASH are read out as data from the electronic label 1 by the reader 5 and further transmitted by the reader 5 to the server 7 in step 220.
  • 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.
  • 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.
  • step 234 the UID is now transferred to a database 10 connected to the server 7, and a security key SKEY is retrieved there using the UID. This SKEY is transferred back to the server 7 in step 235.
  • step 236 the CPKEY is decrypted with the SKEY in order 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 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.
  • 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 CHASH generated in this way should match the HASH transmitted by the label 1 in the case of a genuine label.
  • step 233.1 it is checked whether the CHASH matches the HASH and, if they match, the verification or authenticity of the electronic label 1 is determined.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Toxicology (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Strategic Management (AREA)
  • Bioethics (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Electromagnetism (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Storage Device Security (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren (200, 201, 202) zur Verifizierung eines elektronischen Etiketts (1) zum Anbringen an ein Produkt (50), in welchem auslesbare Daten und ein geheimer Schlüssel gespeichert sind, wobei das elektronische Etikett (1) einen integrierten Schaltkreis (2) aufweist, welcher dazu ausgebildet ist aus den Daten mittels des privaten Schlüssels einen Hashwert zu errechnen. Zudem betrifft die vorliegende Erfindung ein System (100) umfassend ein elektronisches Etikett (1) mit einem integrierten Schaltkreis (2) zum Anbringen an ein Produkt (50), ein Lesegerät (5) zum Auslesen von Daten aus dem elektronischen Etikett (1) und einen über ein Netzwerk (8) mit dem Lesegerät (5) verbundenen Server (7) zum Austausch von Daten.

Description

Verfahren zur Verifizierung eines elektronischen Etiketts und System hierzu
[0001] Die vorliegende Erfindung betrifft ein Verfahren zur Verifizierung eines elektronischen Etiketts zum Anbringen an ein Produkt, welches einen integrierten Schaltkreis aufweist, sowie ein System aufweisend ein elektronisches Etikett, ein Lesegerät und einen Server.
Stand der Technik
[0002] Verfahren und Systeme zur Fälschungssicherung und Echtheitsverifizierung von Produkten sind in verschiedenen Ausprägungen aus dem Stand der Technik bekannt. Insbesondere die Feststellung der Echtheit eines Produkts ist dabei von großer Bedeutung für sowohl Hersteller als auch Konsumenten, um Originale von Fälschungen unterscheiden zu können.
[0003] So können beispielsweise in Kleidungsstücken Etikette eingenäht sein, welche besondere Sicherheitsmerkmale aufweisen, um die Echtheit des Kleidungsstücks zu verifizieren. Solche Etikette können zudem auch mittels eines Lesegeräts elektronisch auslesbar ausgestaltet sein.
[0004] Aus dem Stand der Technik (US 2021/0103938 A1 ) sind Verfahren zur Verifizierung von elektronischen Etiketten bekannt, welche an Produkten angebracht sein können. Solche Verfahren führen die Verifizierung eines Etiketts über eine private Datenbank durch, welche beispielsweise vom Hersteller des Etiketts bzw. des Produkts bereitgestellt werden. Diese Verfahren haben jedoch den Nachteil, dass eine Echtheitsprüfung anhand einer privaten Datenbank nicht sicher gegenüber Manipulationen ist, da diese sowohl gewollt vom Eigentümer, als auch ungewollt durch Dritte manipuliert werden kann - beispielsweise in dem Einträge „echter“ Produkte geändert oder gelöscht werden, oder neue Einträge generiert werden, welche nicht einem „echten“ Produkt entsprechen. Gefälschte Produkte können somit mit solchen Etiketten versehen werden und durch Manipulation der entsprechenden Datenbank als „echt“ erscheinen.
Offenbarung der Erfindung
[0005] Die vorliegende Erfindung hat sich daher die Aufgabe gestellt, ein Verfahren der eingangs erwähnten Art fälschungssicherer zu gestalten bzw. ein Verfahren zur Verifizierung zur Verfügung zu stellen, welches die Fälschungssicherheit von Produkten erhöhen kann. [0006] Die Erfindung löst die gestellte Aufgabe durch die Gegenstände der unabhängigen Patentansprüche. Bevorzugte Ausgestaltungen ergeben sich aus den abhängigen Patentansprüchen und den in weiterer Folge dargestellten Ausführungsvarianten.
[0007] Gemäß einem Aspekt der Erfindung ist ein Verfahren zur Verifizierung eines elektronischen Etiketts gezeigt, welches beispielsweise an einem physischen Produkt angebracht werden kann, um die Fälschungssicherheit des Produkts zu erhöhen. Das elektronische Etikett weist dabei einen integrierten Schaltkreis auf, in welchem auslesbare Daten und ein geheimer Schlüssel gespeichert sind. Der integrierte Schaltkreis ist zudem dazu ausgebildet, aus den Daten mittels des geheimen Schlüssels einen Hashwert zu errechnen.
[0008] Das Verfahren weist dabei folgende Schritte auf: a) Auslesen von Daten aus dem elektronischen Etikett durch ein Lesegerät, wobei die ausgelesenen Daten zumindest den Hashwert enthalten, b) Übertragen der ausgelesenen Daten von dem Lesegerät an einen Server, c) Verifizierung des Hashwerts am Server mittels einer Blockchain, d) Übertragen des Ergebnisses der Verifizierung von dem Server an das Lesegerät, und e) Ausgabe und/oder Verarbeitung des Ergebnisses der Verifizierung am Lesegerät.
[0009] Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein System, umfassend ein elektronisches Etikett mit einem elektronischen Schaltkreis zum Anbringen an ein Produkt, ein Lesegerät zum Auslesen von Daten aus dem elektronischen Etikett und einen über ein Netzwerk mit dem Lesegerät verbundenen Server zum Austausch von Daten gezeigt.
[0010] Erfindungsgemäß weist der elektronische Schaltkreis in dem Etikett einen Speicher auf, in welchem auslesbare Daten und ein geheimer Schlüssel gespeichert sind, und ist der elektronische Schaltkreis dazu ausgebildet, beim Auslesen durch ein Lesegerät einen Hashwert anhand einer kryptografischen Funktion aus den gespeicherten Daten und dem geheimen Schlüssel zu errechnen und an das Lesegerät zu senden.
[0011] Erfindungsgemäß ist das Lesegerät dazu ausgebildet, den Hashwert von dem elektronischen Etikett zu empfangen und an einen Server zur Verifikation zu senden, sowie ein Ergebnis der Verifizierung vom Server zu empfangen und zu verarbeiten und/oder auszugeben. [0012] Erfindungsgemäß ist der Server dazu ausgebildet, den Hash-Wert vom Lesegerät zu empfangen und mittels einer Blockchain zu verifizieren und das Ergebnis der Verifizierung an das Lesegerät zu senden.
[0013] Im Rahmen der vorliegenden Erfindung wird unter elektronischem Etikett jede Form eines „Tags“ bezeichnet, welcher Daten beinhalten und zur Anbringung an oder in einem Produkt geeignet ist. Solche Produkte können beispielsweise Kleidungsstücke, Accessoires wie Taschen, Rucksäcke, etc., sowie elektrische bzw. elektronische Geräte sein, in welchen das Etikett angebracht oder integriert sein kann. Des Weiteren können derartige Produkte Sammelkarten, Briefmarken, Spiele, Smartcards oder andere Papierprodukte mit integriertem elektronischem Schaltkreis sein, in welchen das elektronische Etikett direkt integriert ist.
[0014] Es wird im Allgemeinen festgehalten, dass unter einer Blockchain im Sinne der vorliegenden Erfindung sowohl private als auch öffentliche Blockchains verstanden werden können. Private Blockchains können dabei auf einem oder mehreren Servern des Inhabers und/oder auf Recheneinrichtung von Benutzern gespeichert sein. Insbesondere im Falle einer privaten Blockchain kann der Inhaber die Protokolle („smart contracts“) frei definieren und so die Funktionsweise und Regeln der Blockchain bestimmen, während die einzelnen Blocks der Blockchain für alle Benutzer öffentlich und frei einsehbar sind.
[0015] Als Hashwert werden im Allgemeinen Zeichenfolgen bezeichnet, welche durch eine Hashfunktion (ein mathematischer Algorithmus), welche Daten (bzw. eine „Nachricht“) als Eingabe aufnimmt und eine feste Zeichenfolge von Zeichen zurückgibt (der „Hashwert“), generiert werden. Der durch die Hashfunktion erzeugte Hashwert ist dabei jeweils einzigartig für die Eingabe und identische Eingaben liefern immer das gleiche Ergebnis. Kleine Änderungen in der Eingabe führen jedoch zu deutlich unterschiedlichen Hashwerten.
[0016] Hashfunktionen werden regelmäßig in kryptographischen Protokollen wie digitalen Signaturen und Nachrichtenauthentifizierungscodes (MAC) verwendet. Ein MAC ist ein spezifischer Typ von Hash-Funktion, der eine Nachricht und einen geheimen Schlüssel als Eingabe erhält und eine feste Zeichenfolge von Zeichen zurückgibt. Der geheime Schlüssel wird verwendet, um sicherzustellen, dass nur autorisierte Parteien die Echtheit der Nachricht überprüfen können, da der Sender den MAC an die Nachricht anhängen und der Empfänger den MAC durch Rückrechnung aus der empfangenen Nachricht unter Verwendung des gleichen privaten Schlüssels überprüfen kann, um sicherzustellen, dass die empfangene Nachricht nicht verändert wurde, bzw. aus einer sicheren Quelle stammt. [0017] Werden Daten aus dem elektronischen Etikett mittels eines Lesegeräts ausgelesen bzw. angefordert, so kann die Echtheitsüberprüfung bzw. Verifizierung besonders einfach und komfortabel erfolgen.
[0018] Die vom Lesegerät ausgelesenen Daten können dabei die im elektronischen Etikett gespeicherten Daten ganz oder teilweise umfassen. Der errechnete Hashwert wird dabei als Teil der ausgelesenen Daten auf das Lesegerät übertragen. Ein solches Auslesen kann dabei kontaktlos oder mittels Herstellung eines elektronischen Kontakts erfolgen. Alternativ kann der Auslesevorgang am elektronischen Etikett auch durch einen Benutzer initiiert werden (bspw. indem das Lesegerät nahe an das Etikett herangebracht wird, oder ein elektronischer Kontakt zwischen Etikett und Lesegerät hergestellt wird).
[0019] Werden weiter die ausgelesenen Daten von dem Lesegerät an einen Server übertragen, so kann die Echtheitsprüfung unabhängig vom Lesegerät erfolgen. Zudem muss der Datenbestand, welcher zur Verifizierung bzw. zur Echtheitsprüfung notwendig ist, nicht auf jedem Lesegerät redundant vorrätig gehalten werden. Hierdurch wird zudem gewährleistet, dass jedes Lesegerät stets auf den aktuellen Datenbestand zugreift und nicht veraltete oder unrichtige Daten abruft.
[0020] Wird der Hashwert am Server mittels einer Blockchain verifiziert, so kann die Verifizierung des Hashwerts in einem hohen Maß fälschungssicher gestaltet werden, da die zur Verifizierung benötigten, in der Blockchain gespeicherten Daten resistent gegenüber Manipulationen sind. In herkömmlichen Verfahren zur Echtheitsverifizierung sind die zur Verifizierung notwendigen Daten in der Regel in (privaten) Datenbanken gespeichert. Hierbei besteht sowohl für den Eigentümer der Datenbank als auch für Hacker bzw. Eindringlinge von außen die Möglichkeit, Datenbankeinträge zu ändern, hinzuzufügen oder zu löschen und somit die Echtheitsprüfung zu manipulieren. Werden die zur Verifizierung notwendigen Daten allerdings in einer Blockchain gespeichert, so kann die Sicherheit gegenüber Manipulationen deutlich erhöht werden.
[0021] Daten, die in Blockchains gespeichert sind, gelten aus mehreren Gründen als sicherer gegenüber Manipulation als Daten, die in traditionellen Datenbanken gespeichert sind. Insbesondere sind folgende Faktoren von Relevanz:
Unveränderlichkeit: Sobald Daten in eine Blockchain aufgenommen werden, können sie nicht mehr verändert oder gelöscht werden. Das macht es Angreifern sehr viel schwerer, die Daten zu manipulieren;
Dezentralisierung: In einer traditionellen Datenbank werden die Daten an einem einzigen Ort gespeichert, was Angriffe erleichtert. Im Gegensatz dazu verteilen Blockchains die Daten auf ein Netzwerk von Computern, was es Angreifern viel schwerer macht, die Kontrolle über alle Kopien zu erlangen;
Kryptografie: Blockchains nutzen kryptografische Techniken, um die Daten zu sichern, wie etwa digitale Signaturen und Hashing-Algorithmen. Dies bietet eine zusätzliche Sicherheitsschicht, um unbefugtem Zugriff und Manipulation entgegenzuwirken;
Transparenz: Es ist in der Regel möglich, jeden Transaktionsverlauf in einer Blockchain zu verfolgen, so dass es einfacher ist, verdächtige Aktivitäten zu erkennen; und schließlich
Konsensualität: In einem Blockchain-Netzwerk müssen mehrere Parteien einen Konsens erreichen, bevor neue Daten der Kette hinzugefügt werden können. Das macht es Angreifern deutlich schwerer, die Daten zu verfälschen.
[0022] Durch Kombination von zumindest einigen der oben genannten Faktoren kann somit die Fälschungssicherheit der elektronischen Etiketten deutlich erhöht werden.
[0023] Erfindungsgemäß wird dann weiter das Ergebnis der Verifizierung von dem Server an das Lesegerät zurückübertragen und schließlich das Ergebnis der Verifizierung am Lesegerät ausgegeben oder weiterverarbeitet. Somit kann eine vom Lesegerät losgelöste Verifizierung der Echtheit des Etiketts anhand einer Blockchain erfolgen, welche die Möglichkeiten zur Fälschung deutlich einschränkt.
[0024] Zusammenfassend kann somit erfindungsgemäß ein Verfahren zur Echtheitsüberprüfung bzw. Verifizierung eines elektronischen Etiketts, welches an einem Produkt angebracht oder integriert sein kann, geschaffen werden.
[0025] Im Folgenden werden weitere Ausführungsvarianten der Erfindung dargestellt. Die dargestellten Ausführungsvarianten, bzw. einzelne Teilaspekte der Ausführungsvarianten, sind, falls nicht anders angegeben, beliebig miteinander kombinierbar.
[0026] Gemäß einer Ausführungsvariante der Erfindung kann das Auslesen der Daten aus dem Etikett durch das Lesegerät anhand einer oder mehrerer der folgenden Methoden erfolgen:
Drahtlos: Die Übertragung von Daten zwischen Etikett und Lesegerät kann ohne Kontakt elektronisch, also drahtlos, beispielsweise mittels RFID- oder NFC- Technologie, erfolgen. Ein physischer Kontakt zwischen Etikett und Lesegerät ist dabei nicht vonnöten; Barcode-Scannen: Beim Scannen von Barcodes wird ein laser- oder kamerabasiertes System im Lesegerät verwendet, um Daten von dem Etikett zu erfassen. Der Barcode kann dabei auf dem Etikett oder dem Produkt aufgedruckt sein, oder durch das Etikett digital angezeigt werden;
Magnetstreifenlesung: Beim Lesen von Magnetstreifen wird ein Magnetkopf im Lesegerät verwendet, um die auf einem Magnetstreifen kodierten Daten zu lesen. Dabei kann das Etikett etwa einen Magnetstreifen aufweisen oder bspw. in einer Magnetstreifenkarte inkludiert sein;
Smartcard-Lesen: Beim Lesen von Smartcards bzw. Chipkarten wird eine kontaktlose oder kontaktbasierte Schnittstelle verwendet, um Daten zu lesen, die auf dem Etikett gespeichert sind. Das Etikett kann dabei eine Kontaktzone mit Kontaktflächen aufweisen, die mit den Kontakten eines Lesegeräts in Verbindung gebracht werden können, um die Daten auszulesen;
Optische Zeichenerkennung (OCR): OCR ist eine Technologie, mit der gedruckter Text aus einem Bild, einem Foto oder einem gescannten Dokument gelesen und in maschinencodierten Text umgewandelt werden kann. Das Lesegerät kann dazu eine Kamera aufweisen, welche auf dem Etikett oder dem Produkt aufgedruckten Text erfassen kann.
QR-Code-Scannen: QR-Codes sind zweidimensionale Strichcodes, die mit einer Kamera gescannt werden können, um die kodierten Informationen zu extrahieren. Dabei kann das Lesegerät wiederum eine Kamera aufweisen, welche ein Bild von dem QR-Code aufnimmt und diesen entschlüsselt. Der QR-Code kann dabei wiederum auf dem Etikett oder dem Produkt aufgedruckt bzw. angebracht sein.
[0027] Wie zuvor erwähnt, können die oben genannten Methoden auch miteinander kombiniert werden, so dass beispielsweise ein Teil der Daten über RFID vom Etikett ans Lesegerät gesendet wird und ein Teil der Daten als QR-Code oder Schrift bzw. Text auf dem Etikett aufgedruckt ist und durch eine Kamera des Lesegeräts erfasst wird.
[0028] Gemäß einer bevorzugten Ausführungsvariante können die Daten mit einem RFID- Lesegerät, von dem elektronischen Etikett gelesen werden. RFID (Radiofrequenz- Identifikation) nutzt Funkwellen zur Kommunikation zwischen dem Lesegerät und dem Etikett. Das Lesegerät sendet dabei ein Funksignal aus, welches von der Antenne des Tags empfangen wird, wodurch eine Auslesevorgang gestartet wird. Dieser Start des Auslesevorgangs kann etwa dadurch initiiert werden, indem das Lesegerät nahe an das Etikett herangeführt wird. Das Etikett sendet dann Daten zurück, welche vom Lesegerät empfangen und gelesen werden können. Auf diese Weise können Daten elektronisch von einem elektronischen Etikett gelesen werden, ohne dass ein physischer Kontakt oder eine Sichtverbindung zwischen dem Etikett und dem Lesegerät erforderlich ist.
[0029] Gemäß einer Ausführungsvariante kann das RFID-Lesegerät ein NFC-Lesegerät sein und das elektronische Etikett ein NFC-Tag sein, wobei Lesegerät und Etikett nach dem NFC-Standard arbeiten und so eine Kommunikation zwischen Etikett und Lesegerät lediglich im Nahfeld ermöglichen. Hierdurch wird es insbesondere Angreifern erschwert, die Kommunikation zwischen Etikett und Lesegerät abzuhören.
[0030] Gemäß einer Ausführungsvariante kann die Übertragung der Daten vom Lesegerät an den Server bevorzugt über ein Netzwerk erfolgen, in dem sich Lesegerät und Server befinden. So kann eine physische Trennung zwischen Server und Lesegerät hergestellt werden, wobei der Server zentral Anfragen von verschiedenen Lesegeräten empfangen und verarbeiten kann. Ein solches Netzwerk kann sowohl ein privates LAN- oder WLAN- Netzwerk sein, sowie ein öffentliches Netzwerk, etwa das Internet, sein. Insbesondere bei Übertragungen über ein öffentliches Netzwerk kann zur Verbesserung der Sicherheit die Kommunikation zwischen Lesegerät und Server verschlüsselt erfolgen.
[0031] Gemäß einer weiteren Ausführungsvariante kann der Server am Lesegerät selbst ausgeführt sein, womit die Daten vom Lesegerät intern direkt an den Server übertragen werden. Der Server kann dann dezentral, wie viele gleichartige Server, die Anfragen zur Verifizierung erledigen, wodurch die Anfragezeiten und Serverlasten reduziert werden können und Ausfallszeiten der Server minimiert werden können.
[0032] Für die Übertragung vom Server zurück an das Lesegerät sind die zuvor beschriebenen Ausführungsvarianten analog anwendbar.
[0033] Gemäß einer Ausführungsvariante kann das Lesegerät das Ergebnis der Verifizierung am Lesegerät visuell, auditiv oder haptisch ausgeben. So kann die Ausgabe etwa eine visuelle Indikation für das Verifizierungsergebnis sein, beispielsweise eine farbige LED oder die Ausgabe von Text oder Symbolen auf einem Bildschirm. Alternativ kann auch ein Ton oder eine Tonfolge ausgegeben werden, welche das Verifizierungsergebnis widerspiegelt. Gemäß einer weiteren Möglichkeit kann das Verifizierungsergebnis auch als haptischer Reiz kodiert sein (wie etwa ein Vibrieren).
[0034] Das Lesegerät kann gemäß einer Ausführungsvariante ein Smartphone bzw. ein tragbarer Computer sein. Bevorzugt weist das Smartphone einen RFID- bzw. NFC-Leser auf, mit welchem das elektronische Etikett ausgelesen wird. Die empfangenen Daten werden dann auf den Server übertragen und das vom Server erhaltene Ergebnis kann auf einem Display des Smartphones angezeigt werden. [0035] Gemäß einer Ausführungsvariante der Erfindung kann zur Verifizierung des Hashwerts ein Verifizierungsparameter anhand der vom Lesegerät empfangenen Daten von der Blockchain angefordert werden. Der Verifizierungsparameter kann dabei bspw. ein Vergleichswert sein, anhand dessen eine Verifizierung des Hashwerts durchgeführt wird. Alternativ kann der Verifizierungsparameter auch dazu dienen einen Vergleichswert am Server zu errechnen, welcher zur Verifizierung des Hashwerts herangezogen werden kann.
[0036] Gemäß einer Ausführungsvariante der Erfindung können die auslesbaren Daten eine Kennung zur eindeutigen Identifizierung des Etiketts und einen inkrementellen Zähler umfassen. Die Kennung zur eindeutigen Identifizierung des Etiketts kann dabei beispielsweise eine UID oder eine fortlaufende Nummerierung des Etiketts oder dergleichen sein. Der inkrementelle Zähler kann dabei einen aktuellen Zählerwert aufweisen, welcher durch den integrierten Schaltkreis inkrementiert, also erhöht werden kann. Bevorzugt ist der Zähler von außerhalb des Etiketts nicht änderbar, sondern ausschließlich im Zuge entsprechender Programmabläufe im integrierten Schaltkreis, wobei der Zählerwert nicht erniedrigt werden kann.
[0037] Gemäß einerweiteren Ausführungsvariante der Erfindung kann das Lesegerät beim Auslesen der Daten aus dem elektronischen Etikett die Kennung zur eindeutigen Identifizierung des Etiketts und den Zählerwert empfangen. Gemäß weiteren Ausführungsvarianten der Erfindung können ebenso weitere, auf dem elektronischen Etikett gespeicherte Daten oder Informationen (beispielsweise Identifizierungscodes, Zeichenfolgen, etc.), empfangen werden.
[0038] Gemäß einer Ausführungsvariante können diese auslesbaren Daten durch das Lesegerät in Form einer Nachricht von dem elektronischen Etikett erhalten werden. Die Nachricht kann dabei sämtliche ausgelesenen Daten enthalten. Der Hashwert wird dabei als Prüfsumme aus der Nachricht errechnet und beim Senden der Nachricht vom elektronischen Etikett ans Lesegerät der Nachricht angehängt, so dass das gesamte Paket die ausgelesenen Daten als Nachricht und den Hashwert als Prüfsumme enthält.
[0039] Gemäß einer Ausführungsvariante können die auslesbaren Daten in Form einer Zeichenkette von dem elektronischen Etikett erhalten werden. Bevorzugt stellt die Zeichenkette dabei eine URL oder eine URI (Uniform Ressource Identifier) dar, wobei ein Öffnen bzw. Abfragen der URL/URI am Lesegerät die Daten auf den Server überträgt und das Ergebnis der Verifizierung ausgegeben wird. Auf diese Weise können technisch besonders einfach eine Vielzahl von Lesegeräten zum Auslesen der elektronischen Etiketten eingesetzt werden, ohne dass spezielle Software bzw. Programme auf den Lesegeräten bereitgestellt werden müssen. [0040] Hierzu können die vom Etikett ans Lesegerät übertragenen Daten bzw. die übertragene Nachricht in der URL/URI enthalten sein (etwa in Form von Abfrage- Zeichenketten, bzw. „Query-Strings“). Der Server kann dabei etwa als http-Server betrieben werden, welcher die URL/URI auflöst und die Daten daraus extrahiert. Das ans Lesegerät zurückübertragene Ergebnis kann dabei in Form eines http-Response erhalten werden.
[0041] Gemäß einer Ausführungsvariante der Erfindung kann der integrierte Schaltkreis des elektronischen Etiketts dazu programmiert sein, beim Auslesen von Daten den inkrementellen Zähler zu erhöhen. Der Zählerwert kann somit die Anzahl der Auslesevorgänge des elektronischen Etiketts widerspiegeln.
[0042] Gemäß einer Ausführungsvariante der Erfindung kann der integrierte Schaltkreis des elektronischen Etiketts dazu programmiert sein, automatisch bei jedem Auslesen der Daten einen Hashwert aus den ausgelesenen Daten zu berechnen und zusammen mit den Daten an das Lesegerät zu senden. Der Hashwert kann dabei als Prüfsumme (Checksum) oder digitale Signatur dienen und so durch Einbindung des geheimen Schlüssels ein fälschungssicheres Zertifikat für die Echtheit des Etiketts darstellen.
[0043] Wird zudem der Hashwert aus den Daten errechnet, welche den inkrementellen Zähler umfassen, so kann bei jedem Auslesen ein eindeutiger Hashwert generiert werden, was die Fälschungssicherheit des elektronischen Etiketts weiter erhöht.
[0044] Gemäß einer Ausführungsvariante kann das Lesegerät aus dem elektronischen Etikett dabei eine Nachricht enthaltend die Daten auslesen, wobei die Nachricht bevorzugt eine Kennung zur eindeutigen Identifizierung und den aktuellen Zählerwert aufweist. Die gesamte Nachricht wird dann zur Berechnung des Hashwerts herangezogen, wobei der Hashwert ein Nachrichtenauthentifizierungscodes (MAC) ist, welcher anhand einer kryptografischen Hashfunktion oder anhand eines Blockverschlüsselungsverfahrens aus der Nachricht und dem geheimen Schlüssel berechnet wird. Bevorzugt ist der Hashwert ein „One-Key MAC“ (OMAC), wobei die Nachricht mit dem, auf dem elektronischen Etikett gespeicherten, geheimen Schlüssel verschlüsselt wird.
[0045] Gemäß einer weiteren Ausführungsvariante kann der Hashwert auch durch ein Verschlüsselungsverfahren mit mehr als einem Schlüssel generiert werden. So können auf dem elektronischen Etikett auch mehr als ein geheimer Schlüssel gespeichert sein; gemäß einer Ausführungsvariante etwa ein primärer geheimer Schlüssel und ein sekundärer geheimer Schlüssel. Die Verschlüsselung der auszulesenden Daten zur Erzeugung des Hashwerts kann dann zunächst mit dem primären Schlüssel und danach nochmals mit dem sekundären Schlüssel erfolgen. Auf diese Weise können entweder zwei Hashwerte oder ein doppelt verschlüsselter Hashwert erzeugt werden.
[0046] Gemäß einer weiteren Ausführungsvariante kann zur Verifizierung des Hashwerts, dieser mit in der Blockchain gespeicherten Vergleichs-Hashwerten verglichen werden. Die Blockchain kann somit als Verifizierungsparameter direkt Vergleichs-Hashwerte enthalten, mit welchen die vom Lesegerät empfangenen Hashwerte verglichen werden können, um die Verifizierung des elektronischen Etiketts durchzuführen. Die in der Blockchain gespeicherten Hashwerte sind somit unveränderlich und können nicht manipuliert werden. Dabei können die möglichen Hashwerte etwa für ein bestimmtes elektronisches Etikett vorberechnet werden und vorab in der Blockchain gespeichert werden. Ein besonders einfaches und auch sicheres Verifizierungsverfahren kann so geschaffen werden, da die Verifizierung ausschließlich anhand bzw. mittels der Blockchain erfolgen kann.
[0047] Gemäß einer Ausführungsvariante können weiter die in der Blockchain gespeicherten Vergleichs-Hashwerte für mehre mögliche Zählerwerte vorberechnet sein. So können die in der Blockchain gespeicherten Hashwerte etwa für eine gewisse Anzahl von unterschiedlichen Zählerwerten für jeweils einen Datensatz des elektronischen Etiketts (etwa der eindeutigen Kennung) unter Verwendung des privaten Schlüssels errechnet sein. Da für den Hersteller der elektronischen Etiketten der private Schlüssel und die darauf gespeicherten Daten bekannt sind, können diese bei der Fertigung erstmalig zur Berechnung der unterschiedlichen Hashwerte herangezogen werden. Da zu einem späteren Zeitpunkt insbesondere der private Schlüssel nicht mehr aus dem elektronischen Etikett auslesbar ist, kann nach der erstmaligen Vorbefüllung der Blockchain keine Errechnung der Hashwerte ohne Kenntnis des privaten Schlüssels mehr erfolgen. Indem lediglich die vorberechneten Hashwerte in der Blockchain gespeichert werden, ist eine aktive Kenntnis des privaten Schlüssels am Server nicht notwendig, um eine Echtheitsprüfung des elektronischen Etiketts durchführen zu können.
[0048] Gemäß einer weiteren Ausführungsvariante können die gespeicherten Vergleichs- Hashwerte als trunkierte Vergleichs-Hashwerte in der Blockchain gespeichert sein. Solche trunkierte Vergleichs-Hashwerte können etwa durch ein Abschneiden bzw. Beschneiden der errechneten Hashwerte erhalten werden. Dabei können in der Blockchain nicht die gesamten Hashwerte, sondern beispielsweise lediglich die ersten/letzten 10/20/30, etc. Zeichen des errechneten Hashwerts gespeichert werden. Ein Rückrechnen auf den privaten Schlüssel bzw. ein durch viele Versuche zufälliges Erraten der Nachricht bzw. des Geheimnisses, wird somit deutlich erschwert. Es werden zur Verifizierung dann lediglich die ersten Zeichen des vom Lesegerät empfangenen Hashwerts mit den in der Blockchain gespeicherten Vergleichs-Hashwerten verglichen. [0049] Gemäß einer weiteren Ausführungsvariante können die Vergleichs-Hashwerte in einem auf der Blockchain ausgeführten Programm, gespeichert sein und der Vergleich zwischen Hashwert und gespeicherten Vergleichs-Hashwerten beim Ausführen des Programms erfolgen. Ein solches Programm bzw. Protokoll kann vorzugsweise ein sogenannter „Smart Contract“ sein, welcher auf der Blockchain durch einen Benutzer ausgeführt werden kann. Die Speicherung der Verifizierungsparameter direkt in dem Programm bzw. dem Smart Contract, hat den Vorteil, dass die Kontrolle über die gespeicherten Werte im Einflussbereich des Betreibers der Blockchain bleibt.
[0050] Gemäß einer weiteren Ausführungsvariante kann zur Verifizierung des Hashwerts, der Server aus der Blockchain einen Vergleichs-Schlüssel abrufen, aus den empfangenen Daten und dem Vergleichs-Schlüssel einen Vergleichs-Hashwert mittels einer kryptografischen Funktion errechnen und den Hashwert mit dem Vergleichs-Hashwert vergleichen. Auf der Blockchain sind dabei eine Anzahl von Vergleichs-Schlüssel gespeichert, welche jeweils einem elektronischen Etikett zugeordnet sind und so zur Überprüfung des vom elektronischen Etikett gesendeten Hashwerts herangezogen werden. Der Vergleichs-Schlüssel kann vom Server aus der Blockchain in Abhängigkeit der empfangenen Daten abgerufen werden. So können die empfangenen Daten beispielsweise eine Kennung zur eindeutigen Identifizierung des elektronischen Etiketts enthalten und der Vergleichs-Schlüssel aus der Blockchain für die jeweilige Kennung abgerufen werden. Am Server wird der Vergleichs-Schlüssel nun verwendet um aus den vom Lesegerät erhaltenen Daten einen Vergleichs-Hashwert zu errechnen, wobei der Server dabei vorzugsweise dieselbe kryptografische Hashfunktion bzw. den selben Verschlüsselungsalgorithmus wie der im elektronischen Etikett integrierte Schaltkreis verwendet. Der errechnete Vergleichs- Hashwert kann somit zur Verifizierung der Echtheit den errechneten Vergleichs-Hashwert mit dem empfangenen Hashwert vergleichen.
[0051] Gemäß einer weiteren Ausführungsvariante können zur Berechnung des Vergleichs-Hashwerts am Server alle oder ein Teil der vom elektronischen Etikett empfangenen Daten verwendet werden. Bevorzugt umfassen die Daten die Kennung zur eindeutigen Identifizierung und den aktuellen Zählerwert, welche mit dem Vergleichs- Schlüssel verschlüsselt werden. Alternativ können andere oder weitere Daten zur Berechnung des Hashwerts herangezogen werden.
[0052] Gemäß einer weiteren Ausführungsvariante kann zur Berechnung des Hashwerts im integrierten Schaltkreis des elektronischen Etiketts eine geheime Zeichenfolge bzw. ein sekundärer Schlüssel miteinbezogen werden, welche/r beim Auslesen der Daten vom elektronischen Etikett nicht an das Lesegerät gesendet wird. Diese geheime Zeichenfolge kann zudem am Server, beispielsweise in einer privaten Datenbank, gespeichert sein, und bei der Berechnung des Vergleichs-Hashwerts am Server mit dem Vergleichs-Schlüssel einbezogen werden. Durch die Einbeziehung eines weiteren Geheimnisses bzw. eines sekundären Schlüssels, kann eine Verifizierung alleine anhand der Blockchain ohne Kenntnis des Geheimnisses nicht erfolgen. Ein Umgehen des Servers bei der Verifizierung ist somit nicht möglich, wodurch die Fälschungssicherheit weiter erhöht wird.
[0053] Gemäß einer Ausführungsvariante der Erfindung kann in der Blockchain pro Kennung zur eindeutigen Identifizierung des Etiketts jeweils ein Vergleichs-Schlüssel gespeichert sein. Der Server kann somit nach Erhalt der Daten vom Lesegerät, welche insbesondere die Kennung enthalten, den passenden Vergleichs-Schlüssel aus der Blockchain abrufen.
[0054] Gemäß weiterer Ausführungsvarianten können die Vergleichs-Schlüssel auch zu anderen Daten des elektronischen Etiketts verknüpft in der Blockchain gespeichert sein.
[0055] Gemäß einer weiteren Ausführungsvariante können die Vergleichs-Schlüssel in einem auf der Blockchain ausgeführten Programm gespeichert sein und das Programm in Abhängigkeit von einem elektronischen Etikett zugeordneten Daten einen Vergleichs- Schlüssel zurückgeben. Ein solches Programm bzw. Protokoll kann vorzugsweise ein sogenannter „Smart Contract“ sein, welcher auf der Blockchain durch einen Benutzer ausgeführt werden kann. Die Speicherung der Verifizierungsparameter direkt in dem Programm bzw. dem Smart Contract, hat den Vorteil, dass die Kontrolle über die gespeicherten Werte im Einflussbereich des Betreibers der Blockchain bleibt. Wie zuvor beschrieben, können die Vergleichs-Schlüssel in dem Programm mit Daten des Etiketts, wie etwa der Kennung zur eindeutigen Identifizierung oder anderen Eigenschaften, verknüpft sein. So kann das Programm etwa als Übergabeparameter die Kennung des Etiketts aufnehmen und hierfür den passenden Vergleichs-Schlüssel zurückgeben.
[0056] Gemäß einer weiteren Ausführungsvariante können die in der Blockchain gespeicherten Vergleichs-Schlüssel verschlüsselt sein. Da die in der Blockchain gespeicherten Daten in der Regel für alle Benutzer frei zugänglich und öffentlich einsehbar sind, kann durch Verschlüsselung der gespeicherten Vergleichs-Schlüssel eine weitere Sicherheitsebene eingezogen werden. Die verschlüsselten Vergleichs-Schlüssel können somit ohne Sicherheitsverlust direkt in einer öffentlichen Blockchain gespeichert werden, ohne dass eine Gefahr für ein Umgehen der Verifizierung am Server besteht.
[0057] Gemäß einer weiteren Ausführungsvariante kann der aus der Blockchain abgerufene Vergleichs-Schlüssel am Server entschlüsselt werden, und so der entschlüsselte Vergleichs-Schlüssel zur Berechnung des Vergleichs-Hashwerts herangezogen werden.
[0058] Die Verschlüsselung der Vergleichs-Schlüssel kann dabei mit einem oder mehreren Sicherheitsschlüsseln erfolgen, wobei die Sicherheitsschlüssel insbesondere nur am Server oder nur beim Benutzer selbst zur Verfügung stehen, so dass eine unbefugte Verifizierung durch Dritte effektiv unterbunden werden kann.
[0059] Die Verschlüsselung kann dabei anhand gängiger Verschlüsselungs-Algorithmen erfolgen, wobei sowohl symmetrische als auch asymmetrische Verschlüsselungen möglich sind. Im Falle einer symmetrischen Verschlüsselung wird der Vergleichs-Schlüssel beim Einträgen in die Blockchain mit dem gleichen Sicherheitsschlüssel verschlüsselt, welcher zur Entschlüsselung der verschlüsselten Vergleichs-Schlüssel am Server verwendet wird. Im Falle einer asymmetrischen Verschlüsselung kann zur Verschlüsselung der Vergleichs- Schlüssel eine anderer Sicherheitsschlüssel als zur Entschlüsselung der verschlüsselten Vergleichs-Schlüssel am Server verwendet werden.
[0060] Gemäß einer Ausführungsvariante der Erfindung kann ein erster Teil der in der Blockchain gespeicherten Vergleichs-Schlüssel mit einem ersten Sicherheitsschlüssel verschlüsselt sein.
[0061] Zudem kann gemäß einer weiteren Ausführungsvariante ein zweiter Teil der in der Blockchain gespeicherten Vergleichs-Schlüssel mit einem zweiten Sicherheitsschlüssel verschlüsselt sein.
[0062] Auf diese Weise kann durch die Verwendung unterschiedlicher Sicherheitsschlüssel zur Verschlüsselung der Vergleichs-Schlüssel, die Sicherheit des Verfahrens weiter erhöht werden. So können beispielsweise Teile der Vergleichs-Schlüssel in der Blockchain durch Verwendung eigener Sicherheitsschlüssel nur für eine bestimmte Gruppe an Teilnehmern, welche den jeweiligen Sicherheitsschlüssel kennen, verfügbar sein, wobei andere Gruppen an Teilnehmern keinen Zugriff auf den so verschlüsselten Teil der Vergleichs-Schlüssel haben und somit die Verifizierung der Etiketten nicht durchführen können. UnterTeilnehmer können dabei etwa Server, welche die Verifizierung durchführen, Geräte, Lesegeräte, Hersteller (von Etiketten oder Produkten) oder Benutzer verstanden werden.
[0063] Gemäß einer Ausführungsvariante können mehrere Server aus einer Blockchain zur Verifizierung von Etiketten Vergleichs-Schlüssel abrufen, wobei jedem Server ein Satz an Vergleichs-Schlüssel zugeordnet ist und wobei die Server jeweils über einen Sicherheitsschlüssel, zur Entschlüsselung der zugeordneten Vergleichs-Schlüssel, verfügen. So kann eine zentrale Blockchain geschaffen werden, welche zur Verifizierung unterschiedlicher Etiketten bzw. Produkte verschiedener Hersteller zugleich dient, ohne dass die Hersteller in der Lage sind, gegenseitig den Verifizierungs-Vorgang der Etiketten zu beeinflussen bzw. zu fälschen. Durch die zentrale Blockchain wird ein von den einzelnen Herstellern unabhängiger und durch alle Teilnehmer bestätigter „wahrer“ Datenbestand geschaffen („Single Source of Truth“ SSOT).
[0064] In anderen Worten werden so Partitionen von Vergleichs-Schlüsseln in der Blockchain geschaffen, welche jeweils einem Teilnehmer (Besitzer, Herausgeber oder Hersteller von Etiketten oder Produkten) zugeordnet sein können.
[0065] Sind mehrere Server dazu eingerichtet, eine Verifizierung der Etiketten anhand der Blockchain durchzuführen, so können die Server zudem zur dezentralen Speicherung der Blockchain verwendet werden. Die Server können dabei zudem als Validatoren neuer Blöcke fungieren und so den Konsensmechanismus der Blockchain erfüllen, indem die Server neue Blöcke über ein Konsensverfahren (Proof of Work, Proof of Stake, etc.) erschaffen und anschließend an die Blockchain anhängen.
[0066] Gemäß einer Ausführungsvariante der Erfindung wird jede Anfrage eines Servers an die Blockchain zur Verifizierung eines Etiketts als Transaktion in einem Block der Blockchain gespeichert. So kann jede Verifizierung bzw. jeder Verifizierungsversuch eines Etiketts lückenlos in der Blockchain aufgezeichnet werden, wodurch eine Überwachung auf Fälschungsversuche oder Angriffe erreicht werden kann und etwa schadhafte Angriffe entdeckt werden können.
[0067] Gemäß einer Ausführungsvariante kann der Sicherheitsschlüssel am Lesegerät von einem Benutzer manuell eingegeben werden; etwa indem der Benutzer aufgefordert wird, den Sicherheitsschlüssel von dem Etikett oder dem Produkt abzulesen und am Lesegerät einzugeben. So kann eine zusätzliche Sicherheitsebene eingeführt werden, wobei eine Echtheitsprüfung bzw. Verifizierung nur dann durchgeführt werden kann, wenn der Benutzer in physischem Besitz des Produkts bzw. Etiketts ist.
[0068] Gemäß einer Ausführungsvariante kann der Sicherheitsschlüssel auf einem sekundären elektronischen Schaltkreis gespeichert sein. Ein solcher sekundärer Schaltkreis kann beispielsweise ein in einer Smartcard integrierter Chip sein (Schlüsselkarte) oder in bzw. an einem Produkt angebracht sein. Der sekundäre Schaltkreis kann dabei bevorzugt von dem Lesegerät ausgelesen werden. Alternativ kann auch ein sekundäres Lesegerät verwendet werden, um den sekundären elektronischen Schaltkreis auszulesen.
[0069] Gemäß der zuvor genannten Ausführungsvarianten kann der Sicherheitsschlüssel zur Verifizierung vom Lesegerät an den Server übertragen werden. Gemäß einer alternativen Ausführungsvariante kann ein Teilergebnis der Verifizierung am Server berechnet werden und dieses Teilergebnis zur vollständigen Verifizierung zurück auf das Lesegerät übertragen werden, wobei die Verifizierung schlussendlich am Lesegerät stattfindet.
[0070] Gemäß einer weiteren Ausführungsvariante kann als Sicherheitsschlüssel auch eine Geräteeigenschaft bzw. ein Geräteparameter des Lesegeräts herangezogen werden. So kann als Sicherheitsschlüssel beispielsweise die MAC-Adresse oder eine Seriennummer des Lesegeräts verwendet werden.
[0071] Gemäß einer weiteren Ausführungsvariante können in einem Block der Blockchain die Eigentumsverhältnisse des Etiketts bzw. eines Produkts, auf dem ein Etikett angebracht ist, gespeichert sein. So kann das erfindungsgemäße Verfahren neben einer Echtheitsprüfung auch eine Besitzstandsprüfung durchführen und in Abhängigkeit des Benutzers und/oder des Lesegeräts das Eigentum am Etikett bzw. Produkt überprüfen. So kann beispielsweise durch das Scannen des Etiketts zugleich die Echtheit des Produkts festgestellt werden und überprüft werden, ob der Benutzer, welcher das Etikett scannt, der Eigentümer des Etiketts bzw. des Produkts mit dem Etikett ist.
[0072] Gemäß einer Ausführungsvariante kann zur Besitzstandsprüfung eine Benutzerkennung vom Lesegerät an den Server übertragen werden, wobei die Benutzerkennung mit dem Lesegerät des Benutzers verknüpft ist.
[0073] Gemäß einer Ausführungsvariante kann die Benutzerkennung ein Benutzername oder eine Identifikationsnummer einer digitalen Brieftasche (Wallet) sein und das Etikett in der Blockchain mit einem NFT (Non fungible Token) verknüpft sein. Das Eigentum am Etikett bzw. Produkt kann somit mit einem Eigentum an dem zugeordneten NFT verbunden sein, wobei der Server zur Besitzstandsprüfung den Eigentümer des NFT mit dem Benutzer des Lesegeräts vergleicht.
[0074] Gemäß einer Ausführungsvariante kann das elektronische Etikett in einer Schlüsselkarte integriert sein und das Lesegerät ein Türschloss sein. Hierbei kann insbesondere auch ein Berechtigungsattribut in der Blockchain oder in einer Datenbank gespeichert sein, welches etwa den Zugriff bzw. das Sperren des Türschlosses erlaubt.
[0075] So kann etwa jeder Lesevorgang durch das Türschloss in einem Block der Blockchain, insbesondere zusammen mit einem Zeitstempel (Timestamp), gespeichert werden. So kann ein lückenloser Verlauf der Öffnungsanfragen an das Türschloss dokumentiert werden.
[0076] Insbesondere bei elektronischen Geräten kann das Etikett gemäß einer Ausführungsvariante in einem elektronischen Schaltkreis des Geräts integriert sein. [0077] In dem erfindungsgemäßen System, wie zuvor beschrieben, können insbesondere elektronisches Etikett und/oder Lesegerät und/oder Server entsprechend programmiert sein, um das Verfahren gemäß einem der Ansprüche 1 bis 16 auszuführen.
Kurzbeschreibung der Figuren
[0078] Im Folgenden werden bevorzugte Ausführungsvarianten der Erfindung anhand der Zeichnungen näher dargestellt. Es zeigen:
Fig. 1 eine schematische Darstellung eines Systems gemäß einer ersten Ausführungsvariante der Erfindung,
Fig. 2 schematische Darstellung eines Verfahrens gemäß einer ersten Ausführungsvariante der Erfindung,
Fig. 3 ein schematisches Ablaufdiagramm eines Verfahrens gemäß einer zweiten Ausführungsvariante der Erfindung, und
Fig. 4 ein schematisches Ablaufdiagramm eines Verfahrens gemäß einer dritten Ausführungsvariante der Erfindung.
Wege zur Ausführung der Erfindung
[0079] Das erfindungsgemäße System 100 wird im Folgenden anhand der in den Figuren gezeigten Ausführungsvarianten exemplarisch beschrieben.
[0080] Gemäß Fig. 1 ist eine schematische Darstellung eines Systems 100 gemäß einer ersten Ausführungsvariante der Erfindung gezeigt.
[0081] Das System 100 weist dabei ein elektronisches Etikett 1 auf, welches in einem Produkt 50 integriert ist. Das Etikett 1 kann dabei in dem Produkt 50 fest eingebaut sein, oder an dem Produkt 50 angebracht ist. Das Produkt 50 ist in Fig. 1 exemplarisch als Handtasche 51 dargestellt, wobei das Etikett 1 in einem Innenfutter der Handtasche 51 integriert, bzw. eingenäht ist. Das System 100, wie in weiterer Folge beschrieben, ist jedoch unabhängig von der Art des Produkts 50 realisierbar und das elektronische Etikett 1 kann dabei in beliebige physische Produkte integriert oder an diesen angebracht werden.
[0082] Das elektronische Etikett 1 weist wiederum einen integrierten Schaltkreis 2 auf, in welchem Daten 3 gespeichert sind. Wie exemplarisch dargestellt umfassen die Daten 3 eine Kennung zur eindeutigen Identifizierung des Etiketts UID, einen inkrementellen Zähler CNT und einen privaten Schlüssel PKEY; es können allerdings auch noch weitere, nicht dargestellte Daten gespeichert sein. Der private Schlüssel PKEY kann nicht aus dem elektronischen Etikett ausgelesen werden, sondern ist als geheime Information gespeichert, welche nur dem integrierten Schaltkreis 2 selbst zugänglich ist.
[0083] Der integrierte Schaltkreis 2 ist insbesondere dazu programmiert, bei einem Auslesevorgang den Zählerwert CNT um eins zu erhöhen und so jeweils die aktuelle Anzahl an bisherigen Auslesevorgängen als Zählerwert CNT zu übergeben.
[0084] Zudem ist der integrierte Schaltkreis 2 im elektronischen Etikett 1 dazu programmiert, bei einem Auslesevorgang aus den Daten 3 einen Hashwert zu errechnen. Dabei werden insbesondere die auslesbaren Daten, also die Kennung UID, der Zählerwert CNT und ggf. weitere, mit dem privaten Schlüssel PKEY zu dem Hashwert HASH „verschlüsselt“. Die dabei verwendete kryptografische Hashfunktion ist vorzugsweise ein OMAC-Algorithmus. Zur näheren Beschreibung wird auf die obige Darstellung der Erfindung verwiesen.
[0085] Zum Auslesen der Daten 3, weist das elektronische Etikett 1 eine Sendeeinrichtung 4 zur Datenübertragung an ein Lesegerät 5 auf. Gemäß der in Fig. 1 dargestellten Ausführungsvariante ist die Sendeeinrichtung 4 als RFID-Transponder ausgeführt, wobei das Lesegerät 5 eine Ausleseanfrage mittels Radiowellen an das elektronische Etikett 1 aussendet und dieses als Antwort die auslesbaren Daten 3 in Form einer Nachricht an das Lesegerät 5 sendet.
[0086] Die Nachricht ist dabei gemäß der dargestellten Ausführungsvariante eine Zeichenkette, welche einen URI (Uniform Ressource Identifier) darstellt, welcher vom Lesegerät empfangen und als Webadresse geöffnet werden kann. In dem URI sind die ausgelesenen Daten aus dem elektronischen Etikett 1 direkt enthalten. Die ausgelesenen Daten umfassen dabei bevorzugt die eindeutige Kennung UID, den Zählerwert CNT und den vom integrierten Schaltkreis errechneten Hashwert HASH.
[0087] Am Lesegerät 5, welches in Fig. 1 als Smartphone 6 dargestellt ist, kann die URI beispielsweise über einen Browser oder über ein entsprechendes Programm (App) aufgelöst werden. Durch das Aufrufen der URI werden die in der Nachricht an das Lesegerät 5 übertragenen Daten weiter an einen Server 7 übertragen.
[0088] Die Übertragung bzw. Kommunikation zwischen Lesegerät 5 und Server 7 erfolgt dabei über ein Netzwerk 8. Das Netzwerk 8 ist dabei bevorzugt mit dem Internet verbunden und kann vom Smartphone 6 beispielsweise über WLAN (Wireless LAN) oder über ein Funknetz (bspw. GPRS, UMTS, LTE, bzw. 2G, 3G, 4G, 5G, etc.) erreicht werden. Der Server 7 kann somit an einem anderen Standort als das Lesegerät 5 situiert sein, bzw. kann Anfragen von unterschiedlichen Lesegeräten 5 empfangen und verarbeiten. [0089] Der Server 7 dient zur Verifizierung der gesendeten Daten; insbesondere führt der Server 7 hierzu eine Echtheitsprüfung durch, welche die übertragenen Daten, die aus dem elektronischen Etikett 1 ausgelesen wurden, mithilfe einer Blockchain 9 abgleicht. Die Blockchain 9 kann dabei in ihrer Gesamtheit auf dem Server 7 gespeichert sein. Zugleich kann die Blockchain 9 auch auf weiteren Servern gespeichert sein, was in Fig. 1 schematisch angedeutet wurde.
[0090] In der Blockchain 9 sind gemäß der ersten Ausführungsvariante zu jeder UID verschlüsselte private Schlüssel CPKEY gespeichert, wobei zur Errechnung des CPKEY der PKEY eines elektronischen Etiketts mit einem Sicherheitsschlüssel SKEY verschlüsselt wird. Diese Verschlüsselung ist voll reversibel und dient dazu, die öffentlichen Daten in der Blockchain abzusichern.
[0091] Der Server 7 ist weiters mit einer Datenbank 10 verbunden, in welcher zu jeder UID die SKEYs gespeichert sind. Damit kann der Server 7 die in der Blockchain 9 gespeicherten CPKEYs mit dem jeweiligen SKEY entschlüsseln, um den PKEY zu einer UID zu erhalten.
[0092] Mit dem errechneten PKEY am Server 7 kann somit aus den übertragenen Daten, insbesondere aus der UID und COUNT, unter Verwendung derselben kryptografischen Hashfunktion wie im elektronischen Etikett 1 , ein Vergleichs-Hashwert errechnet werden. Der Vergleichs-Hashwert kann dann mit dem übertragenen Hashwert verglichen werden, wodurch bei Übereinstimmung die Echtheit des elektronischen Etiketts 1 bzw. des Produkts 50 verifiziert werden kann.
[0093] Der Server 7 kann dann wiederum das Ergebnis der Echtheitsprüfung bzw. der Verifikation an das Lesegerät 5 zurückübertragen, wo dieses Ergebnis vom Lesegerät 5 verarbeitet bzw. ausgegeben werden kann. Insbesondere wenn das Lesegerät 5 die URI in einem Browser oder Programm öffnet, so kann das Ergebnis vom Server direkt im Browser bzw. dem Programm, bevorzugt als HTML-Dokument, angezeigt werden.
[0094] Das Lesegerät 5 und der Server 7 sind gemäß der ersten Ausführungsvariante dazu programmiert, die oben genannten Schritte auszuführen.
[0095] Alternativ können gemäß einer weiteren Ausführungsvariante, welche in den Figuren nicht näher dargestellt wurde, in der Blockchain 9 zu jeder UID Vergleichs- Hashwerte für unterschiedliche Zählerwerte gespeichert sein. Der Server 7 kann dabei durch direkten Abruf der Vergleichs-Hashwerte aus der Blockchain und Vergleich mit dem übertragenen Hashwert eine Verifikation bzw. Echtheitsprüfung durchführen. [0096] In weiterer Folge wird das erfindungsgemäße Verfahren 200, 201 , 202 anhand verschiedener Ausführungsvarianten exemplarisch dargestellt.
[0097] Die im Nachfolgenden beschriebene Verfahren 200, 201 , 202 können mittels des erfindungsgemäßen Systems 100 ausgeführt werden, wobei elektronisches Etikett 1 bzw. integrierter Schaltkreis 2, Lesegerät 5 und Server 7 derart programmiert sind, um die Schritte des Verfahrens 200. 201 , 202 auszuführen.
[0098] Gemäß Fig. 2 ist eine schematische Darstellung des Verfahrens 200 gemäß einer ersten Ausführungsvariante gezeigt. Das Verfahren 200 weist dabei die nachfolgend beschriebenen Schritte in chronologischer Reihenfolge auf.
[0099] In Schritt 210 werden mittels einem Lesegerät 5 aus einem elektronischen Etikett 1 Daten 3 und ein Hashwert ausgelesen. Das elektronische Etikett 1 weist dabei, wie zuvor beschrieben, einen integrierten Schaltkreis 2 auf, welcher aus den im elektronischen Etikett 1 gespeicherten (auslesbaren) Daten 3 bei einem Auslesevorgang einen Hashwert erzeugt.
[0100] Das Auslesen 210 kann beispielsweise durch Halten des Lesegeräts 5 in der Nähe des Etiketts 1 initiiert werden, insbesondere wenn elektronisches Etikett 1 und Lesegerät 5 über RFID/NFC miteinander kommunizieren. Das Lesegerät 5 sendet dabei kontinuierlich Radiowellen aus, welche von dem RFID-Transponder des Etiketts 1 empfangen werden und einen Lesevorgang starten. Das Etikett 1 sendet dabei die angeforderten Daten direkt zurück an das Lesegerät 5.
[0101] Eine RFID- bzw. NFC-Kommunikation zwischen Lesegerät 5 und Etikett 1 hat den Vorteil, dass die Kommunikation nur im Nahfeld funktioniert, was das Abhören der Kommunikation zwischen Lesegerät 5 und Etikett 1 erschwert bzw. verunmöglicht.
[0102] Im nachfolgenden Schritt 220 werden die aus dem elektronischen Etikett 1 ausgelesenen Daten an einen Server 7 übertragen, um eine Verifizierung der Echtheit des elektronischen Etiketts durchzuführen. Diese Übertragung kann, wie anhand der Fig. 1 weiter oben beschrieben, besonders einfach erfolgen, wenn die aus dem elektronischen Etikett 1 ausgelesenen Daten in Form einer URI vorliegen, welche am Lesegerät aufgelöst und aufgerufen werden kann. Die URI verweist dann auf eine Netzwerkadresse des Servers 7 und beinhält alle an den Server 7 zu übertragenden Daten, insbesondere den Hashwert und die ausgelesenen Daten, wie UID und COUNT.
[0103] In Schritt 230 wird nun am Server 7 eine Verifizierung der Daten, insbesondere des Hashwerts durchgeführt, um festzustellen, ob das elektronische Etikett 1 , bzw. das damit etikettierte Produkt 50, echt ist und keine Fälschung vorliegt. Hierzu versucht der Server 7 den vom Etikett 1 errechneten Hashwert nachzuvollziehen bzw. zu bestätigen.
[0104] Erfindungsgemäß erfolgt diese Verifizierung des elektronischen Etiketts 1 anhand einer Blockchain 9. Hierzu wird vom Server 7 aus der Blockchain 9 ein Verifizierungsparameter abgerufen, anhand dem eine Verifizierung des Hashwerts erfolgen kann. Ein solcher Verifizierungsparameter kann beispielsweise gemäß einer Ausführungsvariante ein Vergleichs-Hashwert sein; gemäß einer weiteren Ausführungsvariante kann dies auch ein Vergleichs-Schlüssel sein, welcher zur Berechnung des Vergleichs-Hashwerts am Server 7 herangezogen wird.
[0105] In Schritt 240 wird das Ergebnis der Verifizierung vom Server 7 zurück an das Lesegerät 5 übertragen. Dies kann, wenn die Übertragung der Daten in Form einer URI erfolgte, als Ergebnis des Abrufs der URI geschehen. Das Lesegerät 5 ruft dabei die URI ab und wartet bis der Server 7 eine Antwort liefert.
[0106] In Schritt 250 kann das abgerufene Ergebnis der Verifizierung am Lesegerät 5 nun entsprechend verarbeitet werden. So kann das Ergebnis direkt ausgegeben werden, beispielsweise als Indikator, ob das elektronische Etikett echt ist oder nicht.
[0107] Gemäß Fig. 3 ist ein schematisches Ablaufdiagramm des Verfahrens 201 gemäß einer zweiten Ausführungsvariante gezeigt. Das Verfahren 201 weist dabei die zuvor anhand der Fig. 2 beschriebenen Schritte 210 bis 250 auf, mit den nachfolgend angeführten Besonderheiten.
[0108] Wie in Fig. 3 gezeigt, wird in Schritt 210 von dem Lesegerät 5 aus dem elektronischen Etikett 1 eine UID und der errechnete Hashwert HASH ausgelesen und vom Lesegerät 5 weiter in Schritt 220 an den Server 7 übertragen.
[0109] Die Verifizierung 230 des Hashwerts HASH am Server 7 erfolgt dann gemäß der gezeigten Ausführungsvariante anhand der Schritte 231 bis 233 wie nachfolgend beschrieben.
[0110] In Schritt 231 wird die UID an die Blockchain 9 übertragen und anhand eines Programms in der Blockchain 9 zu der UID ein zugeordneter Vergleichs-Hashwert CHASH abgerufen.
[0111] In Schritt 232 wird der CHASH zurück zum Server 7 übertragen, wo dieser in dem nachfolgenden Schritt 233 mit dem vom Lesegerät übertragenen HASH verglichen wird und bei Übereinstimmung die Verifizierung bzw. Echtheit des elektronischen Etiketts 1 festgestellt wird.
[0112] Das Ergebnis der Verifizierung wird dann wieder in Schritt 240 zurück zum Lesegerät übertragen.
[0113] Gemäß einer weiteren Ausführungsvariante, welche in den Figuren nicht näher dargestellt ist, ist der in der Blockchain 9 gespeicherte Vergleichs-Hashwert CHASH ein trunkierter Hashwert, enthält also nur eine bestimmte Anzahl von Zeichen des Hashwerts, nicht aber den gesamten Hashwert. In Schritt 233 am Server 7 wird der (trunkierte) CHASH dann mit dem entsprechenden Teil des übertragenen HASH verglichen um die Verifizierung des elektronischen Etiketts 1 festzustellen.
[0114] Gemäß Fig. 4 ist ein schematisches Ablaufdiagramm des Verfahrens 202 gemäß einer dritten Ausführungsvariante gezeigt. Das Verfahren 202 weist dabei die zuvor anhand der Fig. 2 beschriebenen Schritte 210 bis 250 auf, mit den nachfolgend angeführten Besonderheiten.
[0115] Wie in Fig. 4 gezeigt, werden in Schritt 210 von dem Lesegerät 5 aus dem elektronischen Etikett 1 die UID, der CNT und der errechnete Hashwert HASH als Daten ausgelesen und vom Lesegerät 5 weiter in Schritt 220 an den Server 7 übertragen.
[0116] Die Verifizierung 230 des Hashwerts am Server 7 erfolgt dann gemäß der gezeigten Ausführungsvariante anhand der Schritte 231.1 , 232.1 , 234, 235, 236, 237 und 233.1 wie nachfolgend beschrieben.
[0117] In Schritt 231.1 wird, wie schon zuvor für Fig. 3 beschrieben, die UID an die Blockchain 9 übertragen. Allerdings wird nun anhand eines Programms in der Blockchain 9 zu der UID ein zugeordneter verschlüsselter Vergleichs-Schlüssel CPKEY abgerufen. Der CPKEY wird dann in Schritt 232.1 zurück an den Server 7 übertragen.
[0118] Im nachfolgenden Schritt 234 wird die UID nun an eine mit dem Server 7 verbundene Datenbank 10 übertragen und dort anhand der UID ein Sicherheitsschlüssel SKEY abgerufen. Dieser SKEY wird in Schritt 235 wieder zurück an den Server 7 übertragen.
[0119] Nachfolgend wird in Schritt 236 der CPKEY mit dem SKEY entschlüsselt, um einen Vergleichs-Schlüssel CKEY zu erhalten. Die Entschlüsselung des CPKEY kann dabei anhand einer definierten Verschlüsselungsfunktion erfolgen, welche ebenso zur initialen Erstellung der CPKEYs in der Blockchain 9 verwendet wird. Der entschlüsselte CKEY sollte dabei dem privaten Schlüssel PKEY auf dem elektronischen Etikett 1 entsprechen, welcher zur Generierung des HASH aus den Daten im integrierten Schaltkreis 2 verwendet wird.
[0120] In Schritt 237 wird schließlich aus den übertragenen Daten, insbesondere UID und CNT, mittels einer kryptografischen Hashfunktion unter Einbeziehung des CKEY ein Vergleichs-Hashwert CHASH errechnet. Nachdem CKEY und PKEY aus dem elektronischen Etikett 1 identisch sein sollten, sollte bei echtem Etikett der so erzeugte CHASH mit dem vom Etikett 1 übertragenen HASH übereinstimmen.
[0121] In Schritt 233.1 wird schließlich überprüft, ob der CHASH mit dem HASH übereinstimmt und bei Übereinstimmung wird die Verifizierung bzw. Echtheit des elektronischen Etiketts 1 festgestellt.
[0122] Die oben beschriebenen Ausführungsvarianten können miteinander kombiniert werden, soweit nichts anderes angegeben ist. Zudem können die oben beschriebenen Ausführungsvarianten mit jenen in der Darstellung der Erfindung beschriebenen Ausführungsvarianten kombiniert werden.

Claims

Patentansprüche
1. Verfahren zur Verifizierung eines elektronischen Etiketts (1 ) zum Anbringen an ein Produkt (50), in welchem auslesbare Daten und ein geheimer Schlüssel gespeichert sind, wobei das elektronische Etikett (1 ) einen integrierten Schaltkreis (2) aufweist, welcher dazu ausgebildet ist aus den Daten mittels des privaten Schlüssels einen Hashwert zu errechnen, das Verfahren aufweisend die Schritte:
- Auslesen (210) der Daten und des Hashwerts aus dem elektronischen Etikett (1 ) durch ein Lesegerät (5),
Übertragen (220) der Daten und des Hashwerts von dem Lesegerät (5) an einen Server (7),
- Verifizieren (230) des Hashwerts am Server (7) mittels einer Blockchain (9), Übertragen (240) des Ergebnisses der Verifizierung (230) von dem Server (7) an das Lesegerät (5), und
- Ausgabe und/oder Verarbeitung (250) des Ergebnisses der Verifizierung (230) am Lesegerät (5).
2. Verfahren gemäß Anspruch 1 , dadurch gekennzeichnet, dass zur Verifizierung (230) des Hashwerts ein Verifizierungsparameter anhand der Daten von der Blockchain (9) angefordert wird.
3. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass die auslesbaren Daten eine Kennung zur eindeutigen Identifizierung des Etiketts (1 ) und einen inkrementellen Zähler umfassen.
4. Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass das Lesegerät (5) beim Auslesen der Daten aus dem elektronischen Etikett (1 ) die Kennung zur eindeutigen Identifizierung des Etiketts und den Zählerwert des inkrementellen Zählers empfängt.
5. Verfahren gemäß einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zur Verifizierung des Hashwerts, dieser mit in der Blockchain (9) gespeicherten Vergleichs- Hashwerten verglichen wird.
6. Verfahren gemäß Anspruch 5, dadurch gekennzeichnet, dass die in der Blockchain (9) gespeicherten Vergleichs-Hashwerte für mehre Zählerwerte vorberechnet sind.
7. Verfahren gemäß Anspruch 5 oder 6, dadurch gekennzeichnet, dass die gespeicherten Vergleichs-Hashwerte als trunkierte Vergleichs-Hashwerte in der Blockchain (9) gespeichert sind.
8. Verfahren gemäß einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass die Vergleichs-Hashwerte in einem auf der Blockchain (9) ausgeführten Programm, insbesondere einem Smart Contract, gespeichert sind und dass der Vergleich zwischen Hashwert und gespeicherten Vergleichs-Hashwerten beim Ausführen des Programms erfolgt.
9. Verfahren gemäß einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass zur Verifizierung (230) des Hashwerts, der Server aus der Blockchain einen Vergleichs- Schlüssel abruft, aus den empfangenen Daten und dem Vergleichs-Schlüssel einen Vergleichs-Hashwert mittels einer kryptografischen Funktion errechnet und den Hashwert mit dem Vergleichs-Hashwert vergleicht.
10. Verfahren gemäß Anspruch 9, dadurch gekennzeichnet, dass in der Blockchain (9) pro Kennung zur eindeutigen Identifizierung des Etiketts ein Vergleichs-Schlüssel gespeichert ist.
11. Verfahren gemäß Anspruch 10, dadurch gekennzeichnet, dass die Vergleichs- Schlüssel in einem auf der Blockchain (9) ausgeführten Programm gespeichert sind und dass das Programm in Abhängigkeit von einem Etikett zugeordneten Daten einen Vergleichs-Schlüssel ausgibt.
12. Verfahren gemäß einem der Ansprüche 9 bis 11 , dadurch gekennzeichnet, dass die in der Blockchain (9) gespeicherten Vergleichs-Schlüssel verschlüsselt sind.
13. Verfahren gemäß Anspruch 12, dadurch gekennzeichnet, dass am Server (7) der aus der Blockchain (9) abgerufene Vergleichs-Schlüssel entschlüsselt wird, und der entschlüsselte Vergleichs-Schlüssel zur Berechnung des Vergleichs-Hashwerts herangezogen wird.
14. Verfahren gemäß Anspruch 12 oder 13, dadurch gekennzeichnet, dass ein erster Teil der in der Blockchain (9) gespeicherten Vergleichs-Schlüssel mit einem ersten Sicherheitsschlüssel verschlüsselt ist.
15. Verfahren gemäß Anspruch 14, dadurch gekennzeichnet, dass ein zweiter Teil der in der Blockchain (9) gespeicherten Vergleichs-Schlüssel mit einem zweiten Sicherheitsschlüssel verschlüsselt ist.
16. Verfahren gemäß einem der Ansprüch 12 bis 15, dadurch gekennzeichnet, dass zur Verschlüsselung und Entschlüsselung der Vergleichs-Schlüssel ein Sicherheitsschlüssel verwendet wird, welcher insbesondere in einer Datenbank (10) am Server (7) gespeichert ist.
17. System umfassend ein elektronisches Etikett (1 ) mit einem integrierten Schaltkreis (2) zum Anbringen an ein Produkt (50), ein Lesegerät (5) zum Auslesen von Daten aus dem elektronischen Etikett (1 ) und einen über ein Netzwerk (8) mit dem Lesegerät (5) verbundenen Server (7) zum Austausch von Daten, wobei der integrierte Schaltkreis (2) einen Speicher aufweist, in welchem auslesbare Daten und ein geheimer Schlüssel gespeichert sind, und dazu ausgebildet ist, beim Auslesen durch ein Lesegerät (5) einen Hashwert anhand einer kryptografischen Funktion aus den gespeicherten Daten und dem geheimen Schlüssel zu errechnen und an das Lesegerät (5) zu senden, und wobei das Lesegerät (5) dazu ausgebildet ist, den Hashwert von dem elektronischen Etikett (1 ) zu empfangen und an einen Server (7) zur Verifikation zu senden, und dazu ausgebildet ist, ein Ergebnis der Verifizierung vom Server (7) zu empfangen und zu verarbeiten und/oder auszugeben, und wobei der Server (7) dazu ausgebildet ist, den Hashwert vom Lesegerät (5) zu empfangen und mittels einer Blockchain (9) zu Verifizieren und dazu ausgebildet ist, das Ergebnis der Verifizierung an das Lesegerät (5) zu senden.
18. System gemäß Anspruch 17, dadurch gekennzeichnet, dass das elektronische Etikett (1 ) derart ausgebildet ist, dass der geheime Schlüssel durch ein Lesegerät (1 ) nicht ausgelesen werden kann.
19. System gemäß Anspruch 17 oder 18, dadurch gekennzeichnet, dass der integrierte Schaltkreis (2) im Speicher einen inkrementellen Zähler aufweist und dazu ausgebildet ist, bei einem Lesevorgang den inkrementellen Zähler zu erhöhen und aus dem Zählerwert, optional weiteren Daten und dem geheimen Schlüssel mittels einer kryptografischen Funktion den Hashwert zu errechnen.
20. System gemäß eines der Ansprüche 17 bis 19, dadurch gekennzeichnet, dass das Lesegerät (5) ein Smartphone (6), ein RFID-Lesegerät, ein Türschloss oder ein smartes Schloss ist.
EP23731533.8A 2023-02-27 2023-05-30 Verfahren zur verifizierung eines elektronischen etiketts und system hierzu Pending EP4681098A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA60030/2023A AT526983B1 (de) 2023-02-27 2023-02-27 Verfahren zur Verifizierung eines elektronischen Etiketts und System hierzu
PCT/EP2023/064413 WO2024179692A1 (de) 2023-02-27 2023-05-30 Verfahren zur verifizierung eines elektronischen etiketts und system hierzu

Publications (1)

Publication Number Publication Date
EP4681098A1 true EP4681098A1 (de) 2026-01-21

Family

ID=86851783

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23731533.8A Pending EP4681098A1 (de) 2023-02-27 2023-05-30 Verfahren zur verifizierung eines elektronischen etiketts und system hierzu

Country Status (3)

Country Link
EP (1) EP4681098A1 (de)
AT (1) AT526983B1 (de)
WO (1) WO2024179692A1 (de)

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016512675A (ja) * 2013-03-12 2016-04-28 インタートラスト テクノロジーズ コーポレイション 安全な取引システム及び方法
US20180108024A1 (en) * 2016-06-03 2018-04-19 Chronicled, Inc Open registry for provenance and tracking of goods in the supply chain
US10523443B1 (en) * 2016-08-24 2019-12-31 Bruce Kleinman Devices, methods, and systems for cryptographic authentication and provenance of physical assets
WO2020231328A1 (en) * 2019-05-16 2020-11-19 Mighty Jaxx International Pte. Ltd. An ownership data management system and method
US20200364817A1 (en) * 2019-05-17 2020-11-19 UCOT Holdings Pty Ltd Machine type communication system or device for recording supply chain information on a distributed ledger in a peer to peer network
US11360963B2 (en) * 2019-09-24 2022-06-14 International Business Machines Corporation Tracking and verification of physical assets
US20210091960A1 (en) * 2019-09-24 2021-03-25 International Business Machines Corporation Tracking and verification of physical assets
US12470254B2 (en) * 2019-10-03 2025-11-11 collectID AG Methods and systems for authenticating physical products via near field communication tags and recording authentication transactions on a blockchain
US20220284447A1 (en) * 2019-10-03 2022-09-08 collectID AG Methods and systems for authenticating physical products via near field communication tags and recording authentication transactions on a blockchain
US12307494B2 (en) * 2020-02-07 2025-05-20 Citizens Reserve, Inc. Authentication of products
US11645632B2 (en) * 2020-05-26 2023-05-09 Derek Norman La Salle System and method for a decentralized portable information container supporting privacy protected digital information credentialing, remote administration, local validation, access control and remote instruction signaling utilizing blockchain distributed ledger and container wallet technologies
US20220405770A1 (en) * 2021-06-19 2022-12-22 Deep Signature Ltd. System and methods for verifying merchandise authenticity

Also Published As

Publication number Publication date
AT526983A1 (de) 2024-09-15
WO2024179692A1 (de) 2024-09-06
AT526983B1 (de) 2025-01-15

Similar Documents

Publication Publication Date Title
DE60021183T2 (de) Hochsicherheits-biometrische authentifizierung mittels privatem und öffentlichem schlüsselpaares
EP3319006B1 (de) Verfahren zur offline-echtheitsprüfung eines virtuellen dokuments
DE69630713T2 (de) Identifikationssystem ohne identitätsmarker
DE60211841T2 (de) Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln
EP3318999B1 (de) Verfahren zum ausstellen einer virtuellen version eines dokuments
DE60023705T2 (de) Sichere verteilung und schutz einer schlüsselinformation
EP1946481B1 (de) Verfahren zur erzeugung einer fortgeschrittenen elektronischen signatur eines elektronischen dokuments
EP2041729B1 (de) Lesegerät für ein dokument, verfahren zum lesen eines datenobjekts und computerprogrammprodukt
WO2018073071A1 (de) Bereitstellung und prüfung der gültigkeit eines virtuellen dokuments
EP4179487A1 (de) Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen
DE112005003281T5 (de) Elektronisches Signatursicherheitssystem
DE102013019870B4 (de) Authentifizierungs- und/oder Identifikationsverfahren in einem Kommunikationsnetzwerk
DE102008001880B4 (de) Verfahren und Vorrichtung zum Kennzeichnen von Objekten
WO2022008320A1 (de) Bezahlsystem, münzregister, teilnehmereinheit, transaktionsregister, überwachungsregister und verfahren zum bezahlen mit elektronischen münzdatensätzen
EP4179488A1 (de) Herausgabeinstanz und verfahren zum herausgeben von elektronischen münzdatensätzen sowie bezahlsystem
EP1706957B1 (de) Biometrische authentisierung
AT526983B1 (de) Verfahren zur Verifizierung eines elektronischen Etiketts und System hierzu
EP3815291B1 (de) Fälschungssicherung und abgabekontrolle von verbrauchsgütern
EP3005317B1 (de) Verfahren zum deaktivieren einer sicherheitsanlage
EP2920754B1 (de) Verfahren zur durchführung von transaktionen
DE102008000348B4 (de) Verfahren zur Signierung eines medizinischen Datenobjekts
DE102023108677A1 (de) Verfahren zum Authentifizieren eines Objekts sowie Vorrichtung und System zum Ausführen des Verfahrens
EP4651110A1 (de) Banknote
WO2014019776A1 (de) Authentifizierung eines dokuments gegenüber einem lesegerät
DE102012022037A1 (de) Sicherheitsvorrichtung zur Herstellung von Sicherheitsetiketten und Sicherheitsetikett

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250929

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR