Storage and communication environment for cryptographic tags

Abstract

Example operations may include one or more of the following: receiving tag data read from a tag associated with a physical object and signed using a key assigned to the tag via a network; determining, via a blockchain peer, that the signed tag data is validly signed based on the corresponding key pair of the tag accessible to the blockchain peer; determining, via a blockchain peer, whether the tag data satisfies one or more predefined conditions of the physical object; and storing the determination via a blockchain database.

Description

Technical Field

[0001] This invention relates to storing data via blockchain, and more particularly to a mechanism for securely transmitting readable tag data associated with physical objects to a remote blockchain. Background Technology

[0002] A centralized database stores and maintains data in a single location (e.g., a database server). This location is typically a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored on a centralized database is usually accessible from multiple different points. Multiple users or client workstations can work on the centralized database simultaneously, for example, based on a client / server configuration. Centralized databases are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized database, data redundancy is minimized because the single storage location of all data also implies that a given dataset has only one master record.

[0003] Meanwhile, blockchain systems store data about an immutable ledger, providing distributed and decentralized access to the immutable ledger through untrusted participants. They establish consensus requirements for agreements among these untrusted participants, ensuring that no single entity can alter the immutable ledger or invoke smart contracts without agreements from other entities. A blockchain is formed by a network of participants who agree to add blocks (containing data) to the immutable ledger. Before being added, the block is linked to the previous block on the immutable ledger, forming a chain. This immutable and unbreakable nature of blockchain makes it immune to forged information and hacking. Its decentralized nature also gives it a unique trustless quality, as parties do not need to establish trust before they can securely transact. Summary of the Invention

[0004] From a first aspect, the present invention provides an apparatus comprising: a network interface configured to receive tag data read from a tag associated with a physical object and signed using a key assigned to the tag; a processor configured to determine, based on a corresponding key pair of the tag accessible to a blockchain peer, that the signed tag data has been effectively signed, and via the blockchain peer, determine whether the decrypted tag data satisfies one or more predefined conditions of the physical object; and a memory configured to store the determination via a blockchain database.

[0005] Preferably, the present invention provides an apparatus in which the tag data includes sensor data sensed by one or more sensor devices coupled to the tag.

[0006] Preferably, the present invention provides an apparatus wherein the sensor data includes one or more of the following values: temperature, position, fluid flow rate, pH, velocity, acceleration, viscosity, illumination, spectral measurement, image, pressure, vibration, gravity, and rotational speed.

[0007] Preferably, the present invention provides an apparatus in which the processor is further configured to verify the authenticity of the tag based on a sensor identifier included in the tag data.

[0008] Preferably, the present invention provides an apparatus in which a processor is configured to determine whether the tag data violates one or more predefined conditions embedded in logic of chaincode running on the blockchain peer.

[0009] Preferably, the present invention provides an apparatus in which the network interface is further configured to send alerts to computer devices associated with the physical object via chaincode running on the blockchain peer.

[0010] Preferably, the present invention provides an apparatus in which the tag data is further signed by a key assigned to a reader, and the processor is further configured to determine whether the signed tag data has been effectively signed based on the corresponding key pair of the reader accessible to the blockchain peer.

[0011] Preferably, the present invention provides an apparatus in which the processor is configured to store the identifier of the tag and the tag data as key-value pairs in the state database of the blockchain.

[0012] In another aspect, the present invention provides a method comprising: retrieving sensor data from one or more hardware sensors coupled to a tag and storing the sensor data in the tag's memory; receiving a read request from a reader associated with a blockchain platform; verifying the authenticity of the blockchain platform via the reader based on a handshake protocol between the tag and the blockchain; and, in response to successful verification by the blockchain platform, signing the sensor data based on the tag's private key and sending the signed sensor data to the reader.

[0013] Preferably, the present invention provides a method further comprising: checking the integrity of software running on the tag via a bootloader on the tag during tag power-on.

[0014] Preferably, the present invention provides a method in which verifying the authenticity of a blockchain platform includes receiving data signed by the blockchain platform and verifying the signed data based on the corresponding key of the blockchain platform stored in the tag.

[0015] Preferably, the present invention provides a method that further includes: verifying the authenticity of the reader by the tag based on a handshake protocol with the reader.

[0016] Preferably, the present invention provides a method further comprising: performing a key exchange with the blockchain platform to establish a shared key between the tag and the blockchain platform.

[0017] Preferably, the present invention provides a method wherein signing the sensor data further includes encrypting the sensor data based on the shared key with the blockchain platform before sending the signed sensor data to the reader.

[0018] Preferably, the present invention provides a method further comprising: detecting a data violation based on values ​​of sensor data retrieved from the one or more hardware sensors via the tag, and storing the data violation in a memory.

[0019] Preferably, the present invention provides a method in which the memory of the tag is protected against read and write operations, thereby preventing the private key from being read or modified by an external entity.

[0020] In another aspect, the present invention provides a method comprising: receiving, via a network, tag data read from a tag associated with a physical object and signed using a key assigned to the tag; determining, via a blockchain peer, that the signed tag data is validly signed based on a corresponding key pair of the tag accessible to the blockchain peer; determining, via the blockchain peer, whether the tag data satisfies one or more predefined conditions of the physical object; and storing the determination via a blockchain database.

[0021] Preferably, the present invention provides a method, which further includes: verifying the authenticity of the tag based on a sensor identifier included in the tag data.

[0022] Preferably, the present invention provides a method wherein the determination includes determining whether the tag data violates one or more predefined conditions embedded in the logic of the chaincode running on the blockchain peer.

[0023] Preferably, the present invention provides a method that further includes: sending an alert to a computing device associated with a physical object via chaincode running on a blockchain peer. Attached Figure Description

[0024] Figure 1 This is a diagram illustrating the storage and communication environment between tags and a blockchain according to an example embodiment.

[0025] Figure 2A This is a diagram illustrating an example blockchain architecture configuration according to an example embodiment.

[0026] Figure 2B This is a diagram illustrating the blockchain transaction flow between nodes according to an example embodiment.

[0027] Figure 3A This is a diagram illustrating a licensed network according to an example embodiment.

[0028] Figure 3B This is a diagram illustrating another licensed network according to an example embodiment.

[0029] Figure 3C This is a diagram illustrating an unlicensed network according to an example embodiment.

[0030] Figure 4A This is a diagram illustrating the process of reading tag data at different locations in the supply chain according to an example embodiment.

[0031] Figure 4B This is a diagram illustrating the process of storing tag data into a blockchain ledger according to an exemplary embodiment.

[0032] Figure 4C This is a diagram illustrating a user interface that displays tag data associated with a physical object, according to an example embodiment.

[0033] Figure 5A This is a diagram illustrating a method for receiving tag data according to an example embodiment.

[0034] Figure 5B This is a diagram illustrating a method for sending tag data according to an example embodiment.

[0035] Figure 6A This is a diagram illustrating an example system configured to perform one or more operations described herein, according to an example embodiment.

[0036] Figure 6B This is a diagram illustrating another example system configured to perform one or more operations described herein, according to an example embodiment.

[0037] Figure 6C This is a diagram illustrating another example system configured to utilize smart contracts according to an example embodiment.

[0038] Figure 6D This is a diagram illustrating yet another example system configured to utilize blockchain according to an example embodiment.

[0039] Figure 7A This is a diagram illustrating the process of adding a new block to a distributed ledger according to an example embodiment.

[0040] Figure 7B This is a diagram illustrating the data content of a new data block according to an example embodiment.

[0041] Figure 7C This is a diagram illustrating a blockchain for digital content according to an example embodiment.

[0042] Figure 7D This is a diagram illustrating a block that can represent the structure of a block in a blockchain according to an exemplary embodiment.

[0043] Figure 8A This is a diagram illustrating an example blockchain for storing machine learning (artificial intelligence) data according to an example embodiment.

[0044] Figure 8B This is a diagram illustrating an example quantum-safe blockchain according to an example embodiment.

[0045] Figure 9 This is a diagram illustrating an example system that supports one or more example embodiments. Detailed Implementation

[0046] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transitory computer-readable medium, and system illustrated in the drawings is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

[0047] In one or more embodiments, the features, structures, or characteristics described herein may be combined or removed in any suitable manner. For example, throughout the specification, the use of the phrases “example embodiment,” “some embodiments,” or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the phrases “example embodiment,” “in some embodiments,” “in other embodiments,” or other similar language appearing throughout the specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the figures may be a different device. For example, if a mobile device is shown as transmitting information, a wired device may also be used to transmit information.

[0048] Furthermore, although the term "message" may have been used in the description of the embodiments, this application can be applied to many types of networks and data. Additionally, while certain types of connections, messages, and signaling may be described in the exemplary embodiments, this application is not limited to certain types of connections, messages, and signaling.

[0049] Example embodiments provide methods, systems, components, non-transient computer-readable media, devices, and / or networks for extending the trust, security, and immutability of blockchain to the physical world.

[0050] In one embodiment, this application utilizes a decentralized database (such as a blockchain), which is a distributed storage system comprising multiple nodes communicating with each other. A decentralized database comprises an append-only, immutable data structure, similar to a distributed ledger capable of maintaining records among mutually distrustful parties. These untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering storage transactions as needed to maintain consistency. In various implementations, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can involve native cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). On the other hand, permissioned blockchain databases provide secure transactions between a group of entities sharing common goals but not fully trusting each other, such as businesses exchanging funds, goods, information, etc.

[0051] This application can utilize blockchains that operate arbitrary, programmable logic, customized as decentralized storage schemes and referred to as "smart contracts" or "chaincode." In some cases, there may be dedicated chaincode used to manage functions and parameters, referred to as system chaincode. This application can also utilize smart contracts as trusted distributed applications, leveraging the tamper-proof nature of the blockchain database and the underlying agreements between nodes, referred to as signing or signing policies. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. Signing policies allow chaincode to specify the endorsers of a transaction in the form of a set of peer nodes necessary for endorsement. When a client sends a transaction to a peer specified in the endorsement policy, the transaction is executed to verify it. After verification, the transaction enters a sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions that are divided into blocks.

[0052] This application can utilize nodes as communication entities in a blockchain system. A "node" can perform logical functions, meaning that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or committing client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to a sorting service (e.g., sorting nodes). Another type of node is a peer node that receives transactions submitted by clients, submits transactions, and maintains the state and copies of the ledger of blockchain transactions. Peers can also have the role of endorsers, although this is not required. A sorting service node or sorter is a node that runs communication services for all nodes and implements delivery guarantees, such as broadcasting to every peer in the system when a transaction is submitted and the state of the blockchain world is modified. This is another name for the initial blockchain transaction, which typically includes control and setup information.

[0053] This application can utilize a ledger, which is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be generated by chaincode calls (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorsing nodes, peer nodes, etc.). Each participant (such as a peer node) can maintain a copy of the ledger. A transaction can result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0054] This application can utilize a chain as a transaction log, constructed as hashed linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than one. The block header includes the hash of the block's transactions and the hash of the previous block header. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction on the chain that arrived before it, ensuring that all peer nodes are in a consistent and trusted state. This chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), thus efficiently supporting the attached-only nature of blockchain workloads.

[0055] The current state of an immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the most recent key value known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions targeting the ledger's current state data. To make these chaincode transactions valid, the latest value of the key can be stored in a state database. According to various embodiments, the state database of a blockchain ledger is a key-value store (KVS). The state database can simply be an indexed view of the chain's transaction log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peer nodes start up and before transactions are accepted.

[0056] Blockchain technology enables the sharing of data among multiple parties through a secure, immutable, distributed ledger with verifiable origins and attributes. Blockchain systems can be integrated with existing industries, including food safety, maritime transport, supply chains, the Internet of Things (IoT), and diamond tracking. In relevant blockchain systems, access to the blockchain typically requires input methods that operate through external sources, which can include enterprise software, scanned physical documents, integrations within insecure existing devices, and human input. However, these input methods cannot provide the same level of trust and security achieved by a blockchain network. The most vulnerable input sources are those that rely on human input or insecure devices.

[0057] Therefore, for blockchain to be securely extended to the physical world, security and communication must be as secure as the blockchain itself. Radio Frequency Identification (RFID) systems provide such a channel to the physical world. RFID tags can be attached to physical assets or their surrounding environment (e.g., pallets, cars, trucks, storage areas, etc.). However, RFID tags can be cloned quite easily. Furthermore, the RF channel through which RFID tags communicate can be easily intercepted because these tags tend to rely on schemes based on simple cryptography for authentication.

[0058] The example embodiment relates to a tag-based communication environment that overcomes the shortcomings of previous tag-based systems by extending blockchain to tags attached to or surrounding physical assets. Therefore, a chain of trust can be established between tags, readers, and the blockchain. Tags may include a private key embedded (written) in the tag's secure storage and inaccessible to external entities. Simultaneously, the corresponding public key of the private key may be stored on the blockchain network, for example, on a blockchain ledger, blockchain storage, etc. Each tag may be provided with a private key and then registered to the blockchain. When a tag sends data to the blockchain, the tag can sign the data using its private key. The blockchain can then use the corresponding public key to verify the tag's signature and, similarly, the authenticity of the tag's data.

[0059] A secure executable program can be loaded into the tag, including instructions for responding to requests from a reader on the tag. The reader relaying information from the tag to the blockchain can be trusted or untrusted. If the reader is trusted, it can include a private key stored therein, which has a corresponding public key stored by the blockchain. Trusted readers can also sign the tag data, creating an additional layer of security. Furthermore, the blockchain can store the reader's corresponding public key, thus verifying the validity of the reader's signature.

[0060] The tag can be a programmable computer system with a secure hardware root of trust. The tag may include a network interface (e.g., RFID in one embodiment, etc.), a wireless antenna, a battery, etc. The tag may also include one or more communication interfaces (e.g., Bluetooth, etc.) that enable the tag to be electrically coupled to one or more sensor devices. Therefore, the tag can be periodically woken up and capture sensor data from the coupled sensor.

[0061] In some embodiments, the tag may be provided with a key from a blockchain certificate authority (CA); however, the embodiments are not limited thereto. In some embodiments, the CA can be used to reduce the storage load on the tag and / or the blockchain. The private key can be stored in the tag's protective non-volatile memory via an external system using a communication interface such as RFID, Bluetooth (wireless), or a port (wired). Furthermore, once the tag is provided, the external system can protect the memory location storing the private key to prevent the private key from being accessed or overwritten. Additionally, the tag's hardware can be controlled so that only a program running on the hardware with specific privileges can access the private key. An example of such a program is a bootloader, which loads when the tag is powered on. The bootloader can also enable hardware protection schemes so that no subsequent code is ever run on the hardware. The bootloader can also protect the access port and prevent debuggers from reading and writing to the memory and the tag's CPU.

[0062] The bootloader can start every time the tag is powered on. Here, the bootloader can check the integrity of the software applications running on the tag. This check can be performed every time the tag powers on. For example, the bootloader can check the CRC of the application image every time the tag boots to verify the application's integrity. The bootloader can also be updated via a device firmware update signed with a secret key. This update makes the application code permanent for the tag.

[0063] Tags can be provided with a private key, which has a corresponding public key stored on the blockchain. Here, the tag can use the private key to sign tag data, and the corresponding public key stored on the blockchain can be used to verify the signed tag data. Therefore, the tag can send tag data and a digital signature based on the tag data to the blockchain. Tags can perform key exchange using methods such as Elliptic Curve Diffie-Hellman (ECDH). After the key exchange, the tag can use the generated shared key to encrypt the tag data using an algorithm such as AES, and store the encrypted data on the blockchain, where the encrypted data can be decrypted by the blockchain, for example, automatically or upon meeting one or more conditions.

[0064] To create a digital signature, a tag can create a one-way hash of the electronic tag data to be signed. The private key can be used to generate the hash using an algorithm such as Elliptic Curve Digital Signature Algorithm (ECDSA). The hash is the digital signature. The hash can be encrypted instead of the entire tag data because a hash can transform an input of arbitrary size into a fixed-length value that is typically much shorter than the original tag data. The value of the hash is unique for hash data. The blockchain can use the public key (corresponding to the tag's private key) to verify that the signature indeed corresponds to the tag data and that it was indeed generated using the correct private key. For example, the blockchain can use the ECDSA signature verification algorithm. This ensures that the tag data is authenticated and not tampered with.

[0065] Tags can respond to queries from RFID readers. For example, a tag could be a "smart" tag. When an RFID reader queries a tag, the tag can respond with a request for a verifiable signature and identifier from the RFID reader. Here, the tag can store the corresponding public key of the associated RFID reader. When the RFID reader responds with its identifier (which can be hashed using the RFID reader's private key), the tag can verify the private key based on the corresponding public key to verify the RFID reader's integrity. Furthermore, the tag can provide sensor data, tag serial numbers, etc., which are encrypted by the tag using an encryption key (e.g., after an ECDH key exchange). The RFID reader can relay this data to the blockchain via wireless protocols such as Wi-Fi or Bluetooth (if short-range), by first decrypting and then re-encrypting the tag data using a shared key between the RFID reader and the blockchain. The RFID reader can also add supplementary data from any sensors attached to the reader, such as location sensors that provide their location. Authorized RFID readers will be able to decrypt the tag data. Otherwise, the RFID reader simply acts as a relay between the tag and the blockchain. When the RFID reader operates as a relay, ECDH key exchange occurs between the tag and the blockchain server, and encrypted tag data is sent from the tag to the server without the RFID reader decrypting it. In this scenario, the tag also verifies the integrity of the blockchain server using the public key stored on the server, similar to the verification process described above for the RFID reader.

[0066] One example use case for this system is a supply chain. Each entity (e.g., manufacturer, distributor, transporter, retailer, etc.) can be connected to the blockchain and required to capture tag data at various points in the supply chain. Simultaneously, the tag can be electrically coupled to a sensor, causing the sensor to periodically (e.g., every 10 minutes) sense information. For example, the tag can be coupled to a thermometer that captures temperature readings every 10 minutes, which are then stored by the tag. When the tag is read by a reader, it can sign the sensor data with its private key and provide it to the reader. The tag can also encrypt the data using a shared key generated using ECDH or similar methods between the tag and the reader, or between the tag and the blockchain server. The sensor data can be fed into the blockchain for further analysis. In some embodiments, the sensor data can also be used to further authenticate the tag. For example, sensor identifiers, geographic locations, etc., can also be provided by the tag to verify that the tag communicates with predefined sensors.

[0067] Some benefits of the example implementation include extending the security of the blockchain to the physical environment where the tag resides. A private key embedded in the tag allows the tag to uniquely sign all data sent from the tag to the blockchain. Furthermore, additional data can be provided by the tag (e.g., sensor ID, sensor data, geolocation, etc.), which can be used to further verify the authenticity of the tag, and thus the authenticity of the object to which the tag is attached. The blockchain can have a public key for the tag. As another example, a secure reader can also have a public key that enables the reader to also verify the tag's signature.

[0068] In the example embodiment, blockchain can be used as a tool to provide backend storage for tagged data. However, the embodiments are not limited to this. It should be understood that the storage device can include any trusted system, such as a secure server, a secure database, etc.

[0069] Figure 1 A storage and communication environment 100 between tag 110 and blockchain 130 is illustrated according to an example embodiment. (Refer to...) Figure 1 Blockchain 130 is distributed among multiple blockchain peers, each storing a copy of the blockchain ledger. Blockchain peers can also participate in endorsing transactions. New blocks can be added to blockchain 130 via ordering nodes (not shown) that communicate with blockchain peers within a secure network (blockchain network).

[0070] Tag 110 may include antenna 111 for wireless radio frequency communication with reader 120 having a corresponding antenna 121. Tag 110 also includes communication interface 112, which enables tag 110 to be coupled to sensor 115. Here, communication interface 112 may include wired / port, Bluetooth interface, RFID interface, NFC interface, etc. Therefore, tag 110 and sensor 115 may be electrically coupled, optically coupled, via radio frequency coupling, etc. Sensor 115 may include thermometers, speedometers, GPS devices, accelerometers, flow meters, hygrometers, pressure sensors, etc. Sensor 115 may include various types of sensors (e.g., two or more types of sensors). Moreover, it should be understood that the type of sensor may be different from those specifically listed.

[0071] For example, tag 110 can be periodically (e.g., every 5 minutes) awakened and request readings from sensor 115 via communication interface 112. Sensor readings can be stored in tag 110's memory, which includes a list of sensor readings. Furthermore, when tag 110 is read by reader 120, tag 110 can send a list of readings collected from sensor 115 since its most recent reading by reader 120. The tag can also send processed information about the sensor data, such as minimum and maximum temperature readings and corresponding timestamps, or the number of people in the room after image processing of camera images. Tag 110 can sign the sensor data with its private key. The tag can also encrypt the sensor data. Moreover, the tag can send its serial number (ID), geographic location, timestamp, etc.

[0072] Before sending data to reader 120, tag 110 can first verify that reader 120 is a valid reader using a handshake protocol. For example, tag 110 can store a list of public keys corresponding to one or more readers. Tag 110 can query reader 120 for its private key (or data signed by reader 120 using its private key). Reader 120 can then provide the signed data to tag 110. If the signature verification is successful, tag 110 can determine that reader 120 is a valid reader.

[0073] In some embodiments, ECDH can be used to compute a secret key (session key) for encryption and hashing. The shared secret can be a key used for hashing, or it can be used to derive that key. For example, tag 110 can establish an AES encryption key with the blockchain network hosting blockchain 130. The encrypted tag data can be stored on blockchain 130 and decrypted by smart contracts or blockchain applications, making it available for other applications such as analytics.

[0074] Tag 110 can support various security algorithms, such as AES, SHA256, and ECDSA. External systems can program a private key in a portion of the memory within tag 110; this private key can be permanently determined, ensuring that it cannot be altered once stored on tag 110. Furthermore, the initial code running in the processor of tag 110 can be configured such that the private key written into tag 110 cannot be read by any non-privileged code running on the processor. These features ensure that tag 110 cannot be cloned. Tag 110 can also support different communication protocols, such as NFC, RFID, and Bluetooth Low Energy (BLE), wired interfaces (e.g., I2C, SPI), or other standard or proprietary interfaces, providing flexibility for coupling sensors and readers to tag 110.

[0075] In the example embodiment, blockchain 130 stores the public key corresponding to the tag's private key, and tag 110 is protected against cloning and / or rewriting. Therefore, a chain of trust is created between tag 110 and blockchain 130. Reader 120 does not necessarily have to be a trusted reader. However, the example embodiment can include both scenarios. In one example, reader 120 may include its own private key for signing tag data read from tag 110. Therefore, reader 120 can sign tag data separately, thereby verifying the authenticity of reader 120. If reader 120 is not trusted, it can simply act as a relay device, relaying tag data to blockchain 130 or other intermediary nodes.

[0076] Blockchain 130 stores tag data received from tag 110. This data can be made available to blockchain peer 132, including smart contracts (deployed as chaincode on blockchain peer 132), blockchain applications, and more. For example, tag data can be provided to analytics applications, smart contracts, payment processes, and other business process software.

[0077] In some embodiments, Certificate Authority 140 can be used to reduce the storage load on tag 110 and also generate keys assigned to tag 110, reader 120, and blockchain 130. In this example, Certificate Authority 140 can store the blockchain public key, which tag 110 can retrieve when needed and then delete after use. Similarly, blockchain 130 can retrieve the public key of the tag (including tag 110) from Certificate Authority 140 when needed. In this alternative arrangement, one or more intermediate Certificate Authority (not shown) may also exist between tag 110 and Certificate Authority 140, and between blockchain 130 and Certificate Authority 140. In this example, the intermediate Certificate Authority can respond to requests from tag 110 and Certificate Authority 140, so the request will not bottleneck at Certificate Authority 140. Furthermore, the intermediate Certificate Authority can sign the response to the request with its own signature.

[0078] In this alternative example, reader 120 can query tag 110. Tag 110 can identify itself (ID) and generate a random message that requests a signed message from a source it can trust. In this example, reader 120 can be an untrusted reader, so it then forwards the request to blockchain 130. If the blockchain node / server has the master private key (the corresponding public key for tag 110), the blockchain server can sign the message and also create a challenge to tag 110 to authenticate itself. However, if the blockchain server does not have the private key, it can request certificate authority 140 to sign the message. In this example, it is assumed that certificate authority 140 is trusted by blockchain 130.

[0079] In this example, the blockchain server can access the tag's public key via a consensus mechanism with the rest of blockchain 130. Signed messages can be sent to tag 110, which can verify the server's authenticity because it has access to the public key of certificate authority 140. Tag 110 can also sign queries sent by the blockchain server and send them to the server, which can verify the signature because it has tag 110's public key. The blockchain server can also send its own public key (signed by certificate authority 140) to tag 110. In this example, the blockchain server (authenticated by certificate authority 140 and verified by tag 110) and tag 110 (verified by the blockchain server) can communicate using messages signed by their respective private keys. The blockchain server and tag 110 can also perform ECDH and generate a symmetric session key for data encryption. At the end of the session (or timeout, or a specified number of uses), tag 110 can delete the server's symmetric session key and / or public key.

[0080] Alternative mechanisms could include tag 110 storing the public keys of some blockchain servers (e.g., a small subset determined via consensus among the servers). In this case, when tag 110 requests authentication from a blockchain server, the server can request a signature from one of its peers. In this example, since the "Certificate Authority" is now distributed throughout the network, a "Certificate Authority" is not needed. This distinction might be between permissioned blockchains and public blockchains. Additionally, the protocol could include a mechanism for updating the set of trusted public keys. Protocols for updating trusted keys can be implemented in the CA and consensus methods described above. For example, tag 110 could request authentication from two or more trusted sources to initiate a key update, making it more difficult to crack and preventing a single malicious actor from compromising it.

[0081] Figure 2A A blockchain structure configuration 200 according to an example embodiment is shown. (Reference) Figure 2AThe blockchain architecture 200 may include certain blockchain elements, such as a set of blockchain nodes 202. Blockchain nodes 202 may include one or more nodes 204 and 210 (these four nodes are described by way of example only). These nodes participate in multiple activities, such as the blockchain transaction increment and verification process (consensus). One or more of blockchain nodes 204-210 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 200. A blockchain node may initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in blockchain layer 216, a copy of which may also be stored on the supporting physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to the customized configuration sought by the participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as transactions and installed on all blockchain nodes 204-210 by attaching to the distributed ledger.

[0082] The blockchain infrastructure or platform 212 may include blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and layers supporting the physical computer infrastructure. This physical computer infrastructure can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may expose interfaces providing access to the processor code and the virtual execution environment required to participate in the physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions such as asset exchange transactions and maintain information privacy.

[0083] Figure 2A The blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and the services provided. Code 220 can control blockchain assets. For example, code 220 can store and transmit data, and can be executed by nodes 204-210 in the form of smart contracts and other code elements with conditionally associated chaincode or subject to their execution. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications of changes, updates, etc. Smart contracts themselves can be used to identify authorization and access requirements related to the ledger and the use of associated rules. For example, a smart contract (or chaincode executing the logic of a smart contract) can read blockchain data 226, which can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216 to generate results 228, including alerts, liability determination, etc., in complex service scenarios. Physical infrastructure 214 can be used to retrieve any data or information described herein.

[0084] Smart contracts can be created using high-level applications and programming languages ​​and then written into blocks in a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated to a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be performed in response to the satisfaction of conditions associated with the smart contract. The execution of a smart contract can trigger one or more trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0085] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to one or more blocks within the blockchain. This code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by smart contracts is maintained in memory by the supplied execution environment and then deleted once the data required by the blockchain is identified.

[0086] Chaincode can include a code interpretation (e.g., logic) of a smart contract. For example, chaincode can include a wrapper and deployable version of the logic in a smart contract. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified together by chain validators during the consensus process. Chaincode can receive hashes and retrieve hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode can write data associated with cryptographic details to the blockchain.

[0087] Figure 2B An example of a blockchain transaction flow 250 between nodes in a blockchain, according to an example embodiment, is shown. References Figure 2BThe transaction flow may include client node 260 sending a transaction proposal 291 to endorsing peer node 281. Endorsing peer 281 may verify the client signature in transaction proposal 291 and execute chaincode functionality to initiate the transaction. Output may include chaincode results, a set of key / value versions read in the chaincode (read set), and a set of key / value versions written in the chaincode (write set). Here, endorsing peer 281 may determine whether to endorse the transaction proposal. If approved, a proposal response 292, along with the endorsement signature, is sent back to client 260. Client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to ordering service node 284. Ordering service node 284 then delivers the ordered transactions as blocks on the channel to all peers 281-283. Each peer 281-283 may verify the transaction before it is committed to the blockchain. For example, a peer can check the endorsement policy to ensure that the correct allocation of the specified peer has been signed and verify the signature against transaction payload 293.

[0088] Refer again Figure 2B The client node initiates transaction 291 by constructing a request and sending it to peer node 281, which acts as the endorser. Client 260 may include an application utilizing a supporting software development kit (SDK) that leverages available APIs to generate a transaction proposal. This proposal requests chaincode functionality that enables data to be read from and / or written to the ledger (i.e., written as new key-value pairs for assets). The SDK can act as a shim to encapsulate the transaction proposal into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and uses the client's cryptographic certificate to generate a unique signature for the transaction proposal.

[0089] In response, endorsing peer 281 can verify that (a) the transaction proposal is well-formed, (b) the transaction has not been committed in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is correctly authorized to perform the proposed operation on the channel. Endorsing peer 281 can take the transaction proposal input as an argument to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a read set, and a write set. However, the ledger is not updated at this time. At 292, the set of values, along with the signature of endorsing peer 281, is passed back to client 260's SDK as a proposal response, which parses the payload to be consumed by the application.

[0090] In response, the application of client 260 checks / verifies the endorser peer's signature and compares the proposal response to determine if they are identical. If the chaincode only queries the ledger, the application will check the query response and typically does not commit the transaction to the ordering node service 284. If the client application wants to commit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before the commit (i.e., whether all peers necessary for the transaction have endorsed it). Here, the client may include only one of the many parties to the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the commit confirmation phase.

[0091] After a successful check, in step 293, client 260 assembles the endorsement into the transaction proposal and broadcasts the transaction proposal and response to ordering node 284 within the transaction message. A transaction may contain a read / write set, the signature of the endorsing peer, and the channel ID. Ordering node 284 does not need to examine the entire contents of a transaction to execute its operation; instead, it can simply receive transactions from all channels in the network, order them by channel in chronological order, and create a block of transactions per channel.

[0092] These blocks are delivered on the channel from sorting node 284 to all peer nodes 281-283. The data portion within a block can be verified to ensure the endorsement policy is satisfied and to ensure that there have been no changes to the ledger state of the read set variables since the read set was generated by the transaction execution. Furthermore, in step 295, each peer node 281-283 appends a block to the chain of the channel, and for each valid transaction, the write set is committed to the current state database. Events can be emitted to notify clients that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction is valid or invalid.

[0093] Figure 3AAn example of a permissioned blockchain network 300 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 302 can initiate transactions to a permissioned blockchain 304. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to a regulator 306, such as an auditor. The blockchain network operator 308 manages member permissions, for example, registering regulator 306 as an "auditor" and blockchain user 302 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0094] Blockchain developer 310 can write chaincode and client-side applications. Blockchain developer 310 can deploy chaincode directly to the network via an interface. To include credentials from traditional data source 312 in the chaincode, developer 310 can use out-of-band connections to access the data. In this example, blockchain user 302 connects to the permissioned blockchain 304 via peer node 314. Before any transaction, peer node 314 retrieves the user's registration and transaction certificates from a certificate authority 316 that manages user roles and permissions. In some cases, blockchain users must possess these digital certificates to process transactions on the permissioned blockchain 304. Simultaneously, users attempting to utilize the chaincode may need to verify their credentials on traditional data source 312. To confirm user authorization, the chaincode can use an out-of-band connection to this data via a traditional processing platform 318.

[0095] Figure 3B Another example of a permissioned blockchain network 320 is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to a regulator 326, such as an auditor. The blockchain network operator 328 manages member permissions, for example, registering regulator 326 as an "auditor" and blockchain user 322 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0096] Blockchain developer 330 writes chaincode and client-side applications. Blockchain developer 330 can deploy the chaincode directly to the network via an interface. To include credentials from the traditional data source 332 in the chaincode, developer 330 can use an out-of-band connection to access the data. In this example, blockchain user 322 connects to the network through peer node 334. Before any transaction, peer node 334 retrieves the user's registration and transaction certificates from the certificate authority 336. In some cases, blockchain users must possess these digital certificates to conduct transactions on the permissioned blockchain 324. Simultaneously, users attempting to use the chaincode may need to verify their credentials on the traditional data source 332. To confirm user authorization, the chaincode can use an out-of-band connection to this data through the traditional processing platform 338.

[0097] In some implementations, the blockchain described herein can be a permissionless blockchain. In contrast to a permissioned blockchain that requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network by submitting a transaction and thus adding an entry to the ledger. Additionally, all parties can choose to run nodes on the system and employ a mining protocol to help verify transactions.

[0098] Figure 3C The process 350 of a transaction processed by a permissionless blockchain 352 comprising multiple nodes 354 is illustrated. A sender 356 expects to send payment or some other form of value (e.g., contract, medical record, agreement, goods, services, or any other asset that can be encapsulated in a digital record) to a receiver 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the receiver device 358 may have a digital wallet (associated with the blockchain 352) that provides user interface controls and displays transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify the transaction 360 based on rules established by the creator of the permissionless blockchain 352 (which may be predefined or dynamically assigned). For example, this may include verifying the identities of the parties involved. The transaction may be verified immediately, or it may be queued along with other transactions, and the nodes 354 may determine its validity based on a set of network rules.

[0099] In construct 362, valid transactions are formed into blocks and sealed with locks (hashes). This process can be performed by mining nodes in node 354. Mining nodes can utilize additional software specifically designed for mining and creating blocks for the permissionless blockchain 352. Each block can be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent chain for the blocks.

[0100] Before blocks can be added to the blockchain, they must be verified. Verification of permissionless blockchains (352) can include proof-of-work (PoW) as a solution to a puzzle derived from the block header. Although in Figure 3C Not shown in the example, but another process used to verify blocks is Proof-of-Stake (PoS). In PoS, where the algorithm rewards miners for proving their work by solving mathematical problems, the creator of a new block is deterministically selected based on their wealth (also defined as "stake"). A similar proof is then performed by the selected / picked node.

[0101] By mining 364 blocks, nodes attempt to solve the block by incrementally changing a variable until the solution satisfies the network's overall objective. This creates Proof-of-Work (PoW), ensuring a correct answer. In other words, a potential solution must prove that computational resources are exhausted while solving the problem. In some types of permissionless blockchains, miners can be rewarded with value (e.g., tokens, etc.) for correctly mining blocks.

[0102] Here, in addition to the blockchain itself, the Proof-of-Work (PoW) process makes modifying the blockchain extremely difficult because for a modification to a block to be accepted, an attacker must modify all subsequent blocks. Furthermore, as new blocks are mined, the difficulty of modifying blocks increases, and the number of subsequent blocks also increases. Through distribution 366, successfully verified blocks are distributed through the permissionless blockchain 352, and all nodes 354 add the blocks to the majority chain, which is the auditable ledger of the permissionless blockchain 352. Furthermore, the values ​​in transactions submitted by sender 356 are stored or otherwise transferred to the digital wallet of recipient device 358.

[0103] Figure 4A A process 400A for reading tag data at different locations in the supply chain, according to an example embodiment, is shown. (Refer to...) Figure 4AThe diagram illustrates a security protocol between tags (not shown) at different locations in the supply chain and blockchain network 410. In this example, the tags are electrically coupled to a temperature sensor. Here, the tags can wake up every 2 minutes, 5 minutes, 20 minutes, etc., and acquire temperature readings stored on the tags. These temperature readings can be encrypted and added to a list of readings maintained by the tags in their local memory. The readers are located at different locations in the supply chain, including manufacturer 402, transporter 404, and retailer 406. Blockchain network 410 can include a network of blockchain peers distributed across different geographical locations. Therefore, each of manufacturer 402, transporter 404, and retailer 406 can interact with different blockchain peers of blockchain network 410.

[0104] When a tag is read, it can verify the reader via a handshake protocol. For example, the tag could be a smart tag storing the public key of each corresponding reader. The tag can request the reader to provide a signature using the reader's private key. The tag then uses the reader's corresponding public key (e.g., by hashing / encrypting the same data) and determines that the two hashes match to verify the reader's private key is valid, and therefore the signature is valid. If the reader is verified, a session can begin. Alternatively, verification can occur between a blockchain server and the tag, with the RFID reader acting as the pathway. For example, ECDH can be used by the tag to establish a session key for encryption and hashing with the blockchain. The tag then sends tag data (including any temperature measurements captured and stored in a list, or post-processed tag data) to the reader. The tag signs the tag data using its private key. Furthermore, the tag can encrypt the data using the session key established using ECDH. Therefore, the reader will not be able to decrypt the tag data.

[0105] In this example, readers at manufacturer 402, carrier 404, and retailer 406 can connect to blockchain network 410 via Hypertext Transfer Protocol (HTTP) connections. Blockchain network 410 can receive tag data and unpack the encrypted tag data to decrypt it, then use the tag's corresponding public key to verify the tag's signature. If the reader is a trusted reader, blockchain network 410 can further unpack the reader's signature to determine if the reader is a valid reader based on the reader's corresponding public key stored by blockchain network 410. If the tag and reader verification is successful, blockchain 410 will then transfer the tag data (e.g., as shown in the image) to the blockchain network. Figure 4B (As shown) stored in the blockchain ledger. If a tag or reader fails to be successfully verified, the blockchain can record attempts made by an unregistered tag or reader on the blockchain. Furthermore, in either scenario, any additional information about the tag, such as date, time, geographic location, etc., can also be recorded on the blockchain ledger by the blockchain network 410.

[0106] If the reader is untrusted, the tag can refuse to communicate with it. As another example, the tag can check if the reader is semi-trusted, meaning the reader can reach the correct blockchain network 410 and verify a secret shared by the blockchain network 410 and the tag, such as a shared secret. Here, the tag can send a challenge to the blockchain network 410 via an untrusted reader. If the response returned from the blockchain network 410 is correct, the tag knows the reader is communicating with the correct blockchain network 410 and will send tag data. Even if the reader is intercepting data from the tag, the data will not be of much use because it is also encrypted using the session key shared between the tag and the blockchain network 410.

[0107] In some embodiments, blockchain network 410 may include peer nodes controlled by corresponding parties in the supply chain, including manufacturers 402, transporters 404, and retailers 406; however, the embodiments are not limited thereto. In this example, each party may write data to the blockchain via a conventional endorsement / consensus protocol, and each party maintains its own copy of the blockchain ledger.

[0108] Blockchain network 410 may also include one or more smart contracts 412 that can analyze tag data provided from the supply chain. For example, smart contract 412 can query all tags scanned by a given reader, query all tracking history for a given tag, query all endorsed tags, verify that sensor readings from a given tag (e.g., temperature readings, etc.) are within predefined security limits in the logic of smart contract 412, cross-validate timestamps from the tags with other data (GPS logs, reader logs) in the blockchain to further verify the authenticity of the tag data, and so on. In some embodiments, smart contract 412 can also make the data available for other applications, such as notification application 414, which can alert one or more interested parties (e.g., their computing devices) to a problem indicated by sensor data, for example, that a predefined condition has not been met. Figure 4A In the example, notification service 414 sends alerts or other notifications to the user interface displayed on user device 420.

[0109] Smart contract 412 can store various monitoring conditions for physical objects tracked by tags. For example, goods, materials, components, etc., can be transported through a supply chain and have various requirements, such as temperature requirements (e.g., cold chain), humidity requirements, pressure requirements, timing requirements, etc. Tag data relayed back from readers at each location in the supply chain can be monitored by smart contract 412 to determine if any conditions have been violated. These conditions can be embedded within the logic of smart contract 412. Furthermore, although referred to herein as a smart contract, when packaged into executable code and deployed on a blockchain peer, a smart contract can be referred to as chaincode containing the logic of the smart contract.

[0110] Figure 4B A process 400B for storing tag data into a blockchain ledger according to an example embodiment is shown. (Refer to...) Figure 4B Including Figure 4A Each blockchain peer within the blockchain network 410 shown may include a blockchain 432 and a state database 434 included in the blockchain ledger. The blockchain peer may also include a peer-to-peer application 431 for blockchain communication and can interact with... Figure 4A The smart contract shown is the same as or different from the smart contract 430.

[0111] Each time a tag sends back tag data, blockchain 432 can be updated with a new block 433. Furthermore, the state database 434 can be updated to reflect the tag's most recent value. Here, the state database 434 can store key-value pairs, where the key corresponds to the tag's device ID, and the value is actually multiple values ​​436, including various data read from the tag by the reader, such as the log ID of the reader that called the tag, the caller's log signature, opcode, the tag's device ID, the tag's device signature, the tag's device metadata, terminal ID, terminal signature, terminal metadata, etc. The date can also be stored as a unique transaction on blockchain 432 (e.g., within a new block 433). In this example, smart contract 430 can analyze the tag data stored on blockchain 432 and state database 434, and perform various operations and communicate with other applications / services.

[0112] Figure 4C A user interface 450 displaying tag data associated with physical objects is shown according to an example embodiment. For example, the user interface 450 may be output by a service or application running a blockchain or communicating with a blockchain or blockchain peers. References Figure 4CThe user interface includes data from tags at different reading times and locations along the supply chain. In this example, user interface 450 includes attributes such as a status value 451, a data value 452, a tag ID value 453, a reader ID value 454, and a sensor value 455. The user interface may also display other or additional data attributes, such as geographic location, whether tag signature verification was successful, etc. In this example, the user interface outputs a warning 456, indicating that one of the tag readings indicates a failure of a condition included within the logic of the smart contract.

[0113] Figure 5A A method 510 for receiving tag data according to an example embodiment is shown. As a non-limiting example, method 500 may be performed by a blockchain peer node, server, database node, etc. Referring to FIG5, at 512, the method may include: receiving tag data read from a tag associated with a physical object via a network and signed using a private key assigned to the tag, and the data may be encrypted by the tag. For example, receiving may include receiving messages or other communications from a reader of the tag. In some embodiments, the tag may be an RFID tag. However, the embodiments are not limited thereto.

[0114] Tag data may include the tag's identifier and additional data that is fed back and can verify the tag. For example, additional data may include sensor data from one or more sensors electrically coupled to the tag. Here, the tag may periodically or randomly trigger or otherwise request the sensors to capture readings. Sensor data may include sensor values ​​of any kind of sensor, including fluid flow rate, temperature, velocity, acceleration, humidity, pressure, etc. Sensor data can be used to verify that the physical object associated with the tag is being properly monitored. In other words, sensor data can be used to verify that the physical object is being held under specified conditions, etc. As another example, sensor data can be used to further verify the authenticity of the tag. For example, geographic location values, sensor IDs, etc., may be included in the tag data and used to further verify that the tag is coupled to the correct sensor. In some embodiments, in addition to signing the tag data, the tag may also encrypt the tag data using methods such as AES encryption established with a blockchain.

[0115] In 514, the method may include: determining, via a blockchain peer, that the signed tag data has been effectively signed based on the corresponding key pair of the tag accessible to the blockchain peer. For example, the tag can be signed using a private key uniquely assigned and embedded in the tag's secure storage. Simultaneously, the blockchain peer can access and use the tag's public key stored in the blockchain peer's storage to verify that the tag's private key is valid. In some embodiments, the method may further include verifying the tag's authenticity based on a sensor identifier included within the tag data.

[0116] At 516, the method may include determining, via a blockchain peer, whether tag data satisfies one or more predefined conditions of a physical object. At 518, the method may include storing the determination via a blockchain database. In some embodiments, the determination may include determining whether the tag data violates one or more predefined conditions embedded in logic running on the blockchain peer. Here, conditions may include environmental conditions for the physical object, such as storage conditions, temperature conditions, timing conditions, etc.

[0117] In some embodiments, the method may further include sending an alert to a computing device associated with a physical object via chaincode running on the blockchain peer. In some embodiments, the tag data is also signed with a key assigned to a reader, and the method further includes determining whether the signed tag data is validly signed based on a corresponding key pair of the reader accessible to the blockchain peer. In some embodiments, storage may include storing the tag's identifier and tag data as key-value pairs in the blockchain's state database. In a non-limiting example use case, determination may include determining whether temperature data within the tag data violates one or more temperature requirements for the physical object embedded in logic of the chaincode running on the blockchain peer.

[0118] Figure 5B A method 520 for sending tag data according to an example embodiment is shown. (Reference) Figure 5B In 522, the method may include: retrieving sensor data from one or more hardware sensors coupled to the tag, and storing the sensor data in the tag's memory. In 524, the method may include: receiving a read request from a reader associated with the blockchain platform. In 526, the method may include: verifying the authenticity of the blockchain platform via the reader based on a handshake protocol between the tag and the blockchain. In 528, the method may include: in response to successful verification by the blockchain platform, signing the sensor data based on the tag's private key, and sending the signed sensor data to the reader.

[0119] In some embodiments, the method may further include checking the integrity of software running on the tag via a bootloader on the tag during tag power-up. In some embodiments, the method may further include verifying the authenticity of the blockchain platform, including receiving data signed by the blockchain platform and verifying the signed data based on a corresponding key of the blockchain platform stored by the tag. In some embodiments, the method may further include the tag verifying the authenticity of the reader based on a handshake protocol with the reader. In some embodiments, the method may include performing a key exchange with the blockchain platform to establish a shared key between the tag and the blockchain platform.

[0120] In some embodiments, signing the sensor data may further include encrypting the sensor data based on a shared key with the blockchain platform before sending the signed sensor data to the reader. In some embodiments, the method may further include detecting a data breach via a tag based on values ​​of sensor data retrieved from one or more hardware sensors, and storing the data breach in memory. In some embodiments, the tag's memory is read- and write-protected to prevent the private key from being read or modified by an external entity.

[0121] Figure 6A An example system 600, according to an example embodiment, includes physical infrastructure 610 configured to perform various operations. References Figure 6A Physical infrastructure 610 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which can perform any operational step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, module 612 and module 614 may be the same module.

[0122] Figure 6B Another example system 640, configured to perform various operations according to an example embodiment, is shown. References Figure 6B System 640 includes modules 612 and 614. Module 614 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620), which can perform any operational step 608 (in module 612) included in any example embodiment. Step / operation 608 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, modules 612, and 614 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 612 and 614 may be the same module.

[0123] Figure 6C The illustration depicts an example system configured to utilize a smart contract configuration between a mediator server and contracting parties, according to an example embodiment, and configured to enforce smart contract terms on a blockchain. References Figure 6CConfiguration 650 can represent a communication session, asset transfer session, or process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution can be managed by server 654. The content of smart contract 630 may require digital signature by one or more entities 652 and 656 who are parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, which can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0124] Figure 6D A system 660 including a blockchain, according to an example embodiment, is shown. Reference Figure 6D As an example, Application Programming Interface (API) Gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 662 is a public interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, server 654 is a blockchain network peer component that holds a copy of the world state and allows clients 652 and 656 to query data about the world state and submit transactions to the distributed ledger in the blockchain network, where, depending on smart contract 630 and the endorsement policy, the endorsing peer will run smart contract 630.

[0125] The above embodiments can be implemented in hardware, as a computer program executed by a processor, firmware, or a combination thereof. The computer program can be contained on a computer-readable medium, such as a storage medium. For example, the computer program can reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disks, removable disks, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0126] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as discrete components.

[0127] Figure 7AThe illustration shows a process 700 in which a new block is added to a distributed ledger 720 according to an example embodiment, and Figure 7B The illustration shows the contents of a new data block structure 730 for blockchain according to an example embodiment. (Refer to...) Figure 7A A client (not shown) can submit transactions to blockchain nodes 711, 712, and / or 713. The client can be an instruction received from any source to formulate an activity on blockchain 720. As an example, the client can be an application acting on behalf of a requester (e.g., a device, person, or entity) to propose a transaction against the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) can maintain the state of the blockchain network and copies of the distributed ledger 720. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients, and submission peers that confirm endorsements, verify transactions, and submit transactions to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can perform the roles of endorser node, submitter node, or both.

[0128] The distributed ledger 720 comprises a blockchain storing immutable, ordered records in blocks, and a state database 724 (current world state) maintaining the current state of the blockchain 722. Each channel can have its own distributed ledger 720, and each peer maintains its own copy of the distributed ledger 720 for each channel in which it is a member. The blockchain 722 is a transaction log constructed as hashed, linked blocks, where each block contains a sequence of N transactions. Blocks may include, for example... Figure 7B The various components are shown. Block links can be generated by adding the hash of the previous block header to the current block header. Figure 7A (As indicated by the arrow in the diagram). In this way, all transactions on blockchain 722 are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the last block in blockchain 722 represents every transaction that arrived before it. Blockchain 722 can be stored on a peer-to-peer file system (local or attached storage), which supports workloads that only attach to the blockchain.

[0129] The current state of blockchain 722 and distributed ledger 722 can be stored in state database 724. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of blockchain 722. Chaincode calls execute transactions against the current state in state database 724. To make these chaincode transactions highly efficient, the latest values ​​of all keys are stored in state database 724. State database 724 can include an indexed view of the transaction log of blockchain 722, and therefore, the indexed view can be regenerated from the chain at any time. State database 724 can be automatically restored (or generated if needed) before accepting transactions.

[0130] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing node holds the smart contract that simulates the transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy, which can be specified within the chaincode. An example of an endorsement policy is "most endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

[0131] The ordering service 710 accepts endorsed transactions, orders them into blocks, and delivers these blocks to commit peers. For example, the ordering service 710 can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 7A In the example, blockchain node 712 is a peer that has received a commit for a new data block 730 to be stored on blockchain 720. The first block in a blockchain can be called the origin block, which includes information about the blockchain, its members, the data stored in it, etc.

[0132] The ordering service 710 can consist of a group of orderers. The ordering service 710 does not handle transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 can accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 720. The architecture of the blockchain network can be designed to make specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) pluggable components.

[0133] Transactions are written to the distributed ledger 720 in a consistent order. This order is established to ensure that updates to the state database 724 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin) that sort transactions through solving or mining cryptographic puzzles, in this example, the parties to the distributed ledger 720 can choose the sorting mechanism best suited to the network.

[0134] When the sorting service 710 initializes a new data block 730, the new data block 730 can be broadcast to commit peers (e.g., blockchain nodes 711, 712, and 713). In response, each commit peer verifies the transactions within the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. Specifically, the commit peers can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 724. When a commit peer confirms a transaction, the transaction is written to blockchain 722 on the distributed ledger 720, and the state database 724 is updated using the write data from the read and write sets. If the transaction fails, i.e., if the commit peers find that the read-write set does not match the current world state in the state database 724, the transaction sorted into a block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0135] refer to Figure 7B A new data block 730 (also called a data block) stored on blockchain 722 of the distributed ledger 720 may include multiple data segments, such as a block header 740, block data 750 (the block data portion), and block metadata 760. It should be understood that... Figure 7B The various blocks and their contents shown, such as new data block 730 and its contents, are merely examples and are not intended to limit the scope of the example embodiments. In a regular block, the data portion may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 750.

[0136] The new data block 730 can be included within the block header 740 (for example, ...). Figure 7A The block header 740 is a link to previous blocks on blockchain 722. Specifically, the block header 740 may include a hash of previous block headers. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 can be unique and assigned in various orders, such as incremental / sequential starting from zero.

[0137] According to various embodiments, block data 750 may store tag data 752 received from electronic tags, such as RFID tags. Tag data 752 may include sensor data, tag identifiers, reader data, reader identifiers, etc. Tag data 752 includes one or more of the steps, features, processes, and / or actions described or depicted herein. Therefore, tag data 752 may be stored in the immutable log of blocks on the distributed ledger 720. Some benefits of storing tag data 752 on the blockchain are reflected in the various embodiments disclosed and described herein. Although in Figure 7B In this embodiment, tag data 752 is depicted as being in block data 750, but in other embodiments, it may be located in block header 740 or block metadata 760. Furthermore, tag data 752 may be stored as key-value pairs within state database 724.

[0138] Block metadata 760 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include a signature for block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, the last persistent offset of the sorting service that sorts the blocks, and so on. The signature, last configured block, and sorter metadata can be added by the sorting service 710. Simultaneously, the block submitter (e.g., blockchain node 712) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. Transaction filters may include byte arrays of size equal to the number of transactions included in block data 750 and verification codes indicating whether a transaction is valid or invalid.

[0139] Figure 7C An embodiment of a blockchain 770 for digital content according to embodiments described herein is illustrated. Digital content may include one or more files and associated information. Files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as a security measure to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where permissive rules are applied, or in other settings where consideration of evidence or the presentation and use of digital information is of additional interest. In this context, the digital content may be referred to as digital evidence.

[0140] Blockchains can be formed in various ways. In one embodiment, digital content can be included within and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value (e.g., header, value, etc.) of referencing information along with its associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis for referencing previous blocks. This can be illustrated as follows:

[0141]

[0142] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain could store a cryptographic hash of the content of each block without any digital content. The digital content could be stored in a separate storage area or memory address associated with the hash value of the original file. This other storage area could be the same storage device used to store the blockchain, or it could be a different storage area, or even a separate relational database. The digital content of each block can be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the value stored in the storage area that corresponds to the actual digital content. This operation could be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0143]

[0144] exist Figure 7C In an example embodiment, blockchain 770 includes a plurality of blocks 7781, 7782, ... 778 cryptographically linked in an ordered sequence. N Where N≥1. Used to link blocks 7781, 7782, ..., 778. N The encryption can be any of multiple keyed or unkeyed hash functions. In one embodiment, blocks 7781, 7782, ... 778 N The input is subjected to a hash function that produces an n-bit alphanumeric output (where n is 256 or another number) based on information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle-tree algorithms, random number-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778... N Cryptographic linking can be achieved using functions other than hash functions. For illustrative purposes, the following description is based on hash functions such as SHA-2.

[0145] Blocks 7781, 7782, ..., 778 in the blockchain N Each of these includes a header, a file version, and a value. As a result of hashing in the blockchain, the header and value are different for each block. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0146] The first block of the blockchain, 7781, is called the origin block and includes a header 7721, the original file 7741, and an initial value 7761. The hashing scheme used for the origin block, and indeed in all subsequent blocks, can vary. For example, all the information in the first block 7781 can be hashed together and at once, or each or part of the information in the first block 7781 can be hashed separately, and then the hashing of the separately hashed parts can be performed.

[0147] The header 7721 may include one or more initial parameters, which may include, for example, a version number, timestamp, random number, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., via blockchain network management software) or manually by blockchain participants. It is consistent with blocks 7782 to 778. N Unlike the previous block, the header 7721 of the origin block does not reference the previous block, simply because the previous block does not exist.

[0148] The original file 7741 in the origin block can be, for example, data captured by a device, which may or may not have been processed before being included in the blockchain. The original file 7741 is received from a device, media source, or node through a system interface. The original file 7741 is associated with metadata, which may be generated manually or automatically by a user, device, and / or system processor. This metadata may be included in the first block 7741 associated with the original file 7781.

[0149] The value 7761 of the origin block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value for the original file 7741, metadata for the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes:

[0150] 1) Hash value used for SHA-2 calculation of the original file

[0151] 2) Starting device ID

[0152] 3) Start timestamp for the original file

[0153] 4) Initial storage location for the original file

[0154] 5) A blockchain network member ID used to currently control the original file and associated metadata for the software.

[0155] Other blocks 7782 to 778 in the blockchain N It also has a header, filename, and value. However, unlike the first block 7721, the headers 7722 to 772 in the other blocks... N Each of these blocks includes the hash value of the preceding block. The hash value of the preceding block can be simply the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the preceding block in each remaining block, a block-by-block tracing back to the originating block (and associated original file) can be performed, as shown by arrow 780, to establish an auditable and immutable chain of custody.

[0156] The first 7722 to 772 of other blocks N Each of these may also include other information such as version number, timestamp, random number, root information, difficulty level, consensus protocol, and / or other parameters or information typically associated with the corresponding file and / or blockchain.

[0157] Documents 7742 to 774 N Other blocks can be equal to the original file, or they can be modified versions of the original file in the origin block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. Processing can involve, for example, any modification to the file in the preceding block, such as editing information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0158] Additionally or alternatively, processing may involve only copying a file from an existing block, changing the storage location of a file, analyzing a file from one or more existing blocks, moving a file from one storage or memory location to another, or performing actions relative to the file and / or its associated metadata on the blockchain. Processes involving analyzing files may include, for example, appending, including, or associating various analyses, statistics, or other information associated with the file.

[0159] Other blocks 7762 to 776 NThe value in each block is unique and completely distinct due to the processing performed. For example, the value in any given block corresponds to an updated version of the value in a previous block. The update is reflected in the hash of the block to which the value was assigned. Therefore, the value of a block provides an indication of what processing was performed within that block and also allows for tracing back through the blockchain to the original file. This tracing confirms the chain of custody of the file throughout the blockchain.

[0160] For example, consider a scenario where a portion of a file in a previous block is edited, fragmented, or pixelated to protect the identity of the person depicted in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the editing was performed, who performed the editing, the timestamp when the editing occurred, etc. The metadata can be hashed to form values. Because the metadata of this block differs from the information hashed to form the values ​​in the previous block, these values ​​are distinct from each other and can be recovered during decryption.

[0161] In one embodiment, the value of a previous block can be updated (e.g., a newly calculated hash value) to form the value of the current block when any one or more of the following occur. In this example embodiment, a new hash value can be calculated by hashing all or part of the information mentioned below.

[0162] a) If the file has been processed in any way (e.g., if the file has been edited, copied, altered, accessed, or subjected to some other action), the new SHA-2 calculated hash value

[0163] b) The new storage location for the file

[0164] c) New metadata identified that is associated with the file

[0165] d) Transferring access to or control of files from one blockchain participant to another.

[0166] Figure 7D An embodiment of a block, according to one example, can represent the structure of a block in blockchain 790. (Block) i Including head 772 i Document 774 i Sum of 776 i .

[0167] Head 772 i Including previous blocks i-1The hash value and additional referencing information, which can be any type of information discussed herein (e.g., header information including references, attributes, parameters, etc.). All blocks reference the hash of previous blocks, except for the originating block. The hash value of a previous block can be simply the hash of the header in the previous block, or the hash of all or part of the information in the previous block (including file and metadata).

[0168] Document 774 i This includes multiple data sets, such as sequential data 1, data 2, ..., data N. Each data set is tagged with metadata 1, metadata 2, ..., metadata N, describing the content and / or characteristics associated with it. For example, the metadata for each data set may include information such as: a timestamp indicating the data, the processing of the data, keywords indicating the people or other content depicted in the data, and / or other characteristics that may help establish the validity and content of the document as a whole, and particularly its use of digital evidence, for example, as described in conjunction with the embodiments discussed below. In addition to the metadata, each data set may be accompanied by references to previous data, REF1, REF2, ..., REF... N To mark it, so as to prevent tampering, gaps, and sequential references through the file.

[0169] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered without changing the hash, as this could easily be identified as invalid. Therefore, metadata creates a data log of information that can be accessed and used by participants in the blockchain.

[0170] Value 776 i A hash value or other value calculated based on any type of information discussed earlier. For example, for any given block. i The value of the block can be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for associating with the file, a transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value may be based partly or entirely on that metadata.

[0171] Once the blockchain 770 is established, at any point in time, an immutable chain of custody for a file can be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracing process can begin by decrypting the value of the most currently included block (e.g., the last (Nth) block), and then continue decrypting the values ​​of other blocks until the origin block is reached and the original file is recovered. Decryption can also involve decrypting the header and file structure within each block, as well as the associated metadata.

[0172] Decryption is performed based on the type of encryption that occurs in each block. This can involve the use of private keys, public keys, or public-private key pairs. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a predefined algorithm. The public and private keys are associated with each other through some mathematical relationship. The public key can be publicly distributed to be used as an address to receive messages from other users, such as an IP address or home address. The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message, allowing the recipient to verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent the message.

[0173] Generating key pairs is similar to creating an account on the blockchain, but it doesn't require actual registration anywhere. Furthermore, every transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process documents on the blockchain (if within the permissions defined by smart contracts).

[0174] Figure 8A and 8B Further examples of blockchain use cases that can be combined and used in this article are shown. Specifically, Figure 8A Example 800 of a blockchain 810 storing machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build predictive models for making accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can typically sift through millions of records to find non-intuitive patterns.

[0175] exist Figure 8A In the example, host platform 820 builds and deploys machine learning models for predictive monitoring of asset 830. Here, host platform 820 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 830 can be any type of asset (e.g., machinery or equipment), such as aircraft, locomotives, turbines, medical equipment and devices, oil and gas equipment, ships, vessels, vehicles, etc. As another example, asset 830 can be intangible assets, such as stocks, currencies, digital tokens, insurance, etc.

[0176] Blockchain 810 can be used to significantly improve both the training process 802 of a machine learning model and the prediction process 804 based on the trained machine learning model. For example, in 802, historical data can be stored on blockchain 810 by the asset 830 itself (or through an intermediary, not shown), instead of requiring data scientists / engineers or other users to collect the data. This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be transferred directly and reliably from its place of origin to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can directly send data from the asset to the individual using the data to build the machine learning model. This allows data to be shared between assets 830.

[0177] The collected data can be stored on Blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (i.e., supply chains, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of data recording.

[0178] Furthermore, the machine learning model trained on the collected data can be refined and tested in several rounds by the host platform 820. Each round can be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In 802, the different training and testing steps (and the data associated with them) can be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on the blockchain 810. This provides verifiable proof of how the model was trained and what data was used to train the model. Additionally, when the host platform 820 has achieved the final trained model, the resulting model can be stored on the blockchain 810.

[0179] After the model has been trained, it can be deployed to a field environment where predictions / decision-making can be made based on the execution of the finally trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and healthcare machines. In this example, data feedback from asset 830 can be fed into the machine learning model and used to make event predictions, such as failure events, error codes, etc. The determinations made by the machine learning model by executing it at host platform 820 can be stored on blockchain 810 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict the future failure / failure of a portion of asset 830 and create an alert or notification to replace that portion. The data behind this decision can be stored on blockchain 810 by host platform 820. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 810.

[0180] New transactions for the blockchain can be aggregated into a new block and added to an existing hash value. It is then encrypted to create a new hash for the new block. As transactions are encrypted, they are added to the next list of transactions, and so on. The result is a chain of blocks, each containing the hash values ​​of all previous blocks. The computers storing these blocks periodically compare their hash values ​​to ensure they all agree. Any computer that disagrees discards the record that caused the problem. This method is beneficial for ensuring the blockchain's tamper-resistance, but it is not perfect.

[0181] One way to exploit this system is for dishonest users to alter the list of transactions to their advantage while keeping the hash unchanged. This can be done through brute force—in other words, by altering the record, encrypting the result, and checking if the hash values ​​match. If not, this is repeated until a matching hash is found. The security of blockchain is based on the belief that ordinary computers can only perform such brute-force attacks on completely impractical timescales (such as the age of the universe). In contrast, quantum computers are much faster (1000 times faster), and therefore pose a much greater threat.

[0182] Figure 8B An example 850 of a quantum-secure blockchain 852 implementing quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can verify each other's identities using QKD. This uses quantum particles, such as photons, to send information, which cannot be copied by an eavesdropper without destroying them. In this way, senders and receivers can be certain of each other's identities through the blockchain.

[0183] exist Figure 8BIn this example, there are four users: 854, 856, 858, and 860. Each pair of users can share a key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, thus six different keys 862 are used, including QKD. AB QKD AC QKD AD QKD BC QKD BD and QKD CD Each pair can create a QKD by sending information using quantum particles such as photons, and an eavesdropper cannot copy a QKD without destroying it. In this way, a pair of users can be certain of each other's identity.

[0184] Blockchain 852 operates based on two processes: (i) the creation of transactions and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similarly to traditional blockchain networks. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of reference transactions proving the sender has funds for the operation, etc. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, the two parties (i.e., a pair of users in 854-860) authenticate the transaction by providing their shared key 862 (QKD). This quantum signature can be appended to each transaction, making it extremely difficult to tamper with. Each node checks its local copy of the entries for blockchain 852 to verify that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0185] Instead of performing a traditional mining process on blocks, blocks can be created in a decentralized manner using a broadcast protocol. Within a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine agreement (consensus) regarding the correct version of the transaction. For example, each node can possess a private value (the transaction data for that particular node). In the first round, nodes send their private values ​​to each other. In subsequent rounds, nodes transmit the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within a new block. This new block can be added to blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein can occur on or relative to blockchain 852.

[0186] Figure 9Example system 900 supporting one or more of the exemplary embodiments described and / or depicted herein is illustrated. System 900 includes computer system / server 902, which can operate with a number of other general-purpose or special-purpose computing system environments or configurations. Examples of known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 902 include, but are not limited to: personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0187] Computer system / server 902 can be described in the general context of executable instructions of a computer system, such as program modules executed by the computer system. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 902 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0188] like Figure 9 As shown, the computer system / server 902 in the cloud computing node 900 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, system memory 906, and buses that couple various system components, including system memory 906, to the processor 904.

[0189] A bus refers to one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. By way of example and not limitation, these architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0190] Computer system / server 902 typically includes a variety of computer system readable media. Such media can be any available media accessible to computer system / server 902, and it includes volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 906 implements the flowcharts of other figures. System memory 906 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache 912. Computer system / server 902 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media. In this case, each may be connected to a bus via one or more data media interfaces. As will be further described and illustrated below, memory 906 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of this application.

[0191] By way of example and not limitation, a program / utility 916 having a set (at least one) of program modules 918, along with an operating system, one or more applications, other program modules, and program data, may be stored in memory 906. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules 918 typically perform the functions and / or methods of various embodiments of the applications described herein.

[0192] As those skilled in the art will understand, aspects of this application can be implemented as a system, method, or computer program product. Therefore, aspects of this application can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which can be collectively referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application can take the form of a computer program product contained in one or more computer-readable media that include computer-readable program code thereon.

[0193] The computer system / server 902 can also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). This communication can occur via I / O interface 924. Furthermore, the computer system / server 902 can communicate with one or more networks, such as a local area network (LAN), a general area network (WAN), and / or a public network (e.g., the Internet), via network adapter 926. As depicted, network adapter 926 communicates with other components of the computer system / server 902 via a bus. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0194] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it will be understood that this application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined in the appended claims. For example, the capabilities of the systems in the various figures may be performed by one or more of the modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by the various modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various times and may be related to various events, either internal or external to the modules or components. Moreover, information transmitted between the various modules may be transmitted between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Moreover, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0195] Those skilled in the art will understand that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smartphone, or any other suitable computing device, or a combination of devices. Presenting the foregoing functionality as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in a localized and distributed manner consistent with computing technologies.

[0196] It should be noted that some system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits comprising off-the-shelf semiconductors, such as custom VLSI circuits or gate arrays, logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0197] Modules can also be implemented, at least in part, as software executed by various types of processors. Identifying units of executable code can, for example, include one or more physical or logical blocks of computer instructions, which can be organized, for example, into objects, procedures, or functions. However, the executable code identifying a module does not need to be physically located together, but can include different instructions stored in different locations that, when logically combined, comprise the module and achieve its intended purpose. Furthermore, modules can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0198] In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data can be identified and represented within a module, and can be embodied in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single data set, or it can be distributed across different locations including different storage devices, and can exist at least in part as electronic signals on a system or network.

[0199] It is readily understood that, as generally described and illustrated in the accompanying drawings, the components of this application can be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the application.

[0200] Those skilled in the art will readily understand that the above content can be practiced with steps in a different order and / or with hardware components configured differently from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0201] Although preferred embodiments of this application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of this application is limited only by the appended claims when considering its full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A computer-implemented apparatus, comprising: A network interface is configured to receive encrypted tag data read by a reader from a tag associated with a physical object and signed using a key assigned to the tag by a blockchain network, wherein when the reader is trusted, the trusted reader signs the tag data using the trusted reader's private key and forwards it; when the reader is untrusted, the tag sends a challenge to the blockchain network via the untrusted reader; and when a correct response is received from the blockchain network, the tag passes the tag data to the untrusted reader. A processor configured to determine that signed tag data is effectively signed based on a corresponding key pair of the tag accessible to blockchain peers, and to generate a session key via a secret shared between the blockchain network and the tag, based on a secret between the blockchain network and the tag, to decrypt the encrypted tag data based on the session key, and to determine whether the decrypted tag data satisfies one or more predefined conditions of the physical object; and The memory is configured to store the determination via a blockchain ledger.

2. The apparatus according to claim 1, wherein, The encrypted tag data includes sensor data sensed by one or more sensor devices coupled to the tag.

3. The apparatus according to claim 2, wherein, The sensor data includes one or more of the following values: temperature, location, fluid flow rate, pH, velocity, acceleration, viscosity, illumination, spectral measurement, image, pressure, vibration, gravity, and rotational speed.

4. The apparatus according to claim 2, wherein, The processor is also configured to verify the authenticity of the tag based on a sensor identifier included in the encrypted tag data.

5. The apparatus according to claim 1, wherein, The processor is configured to determine whether the encrypted tag data violates one or more predefined conditions embedded in the logic of the chaincode running on the blockchain peer.

6. The apparatus according to claim 1, wherein, The network interface is also configured to send alerts to computer devices associated with the physical object via chaincode running on the blockchain peer.

7. The apparatus according to claim 1, wherein, The tag data is also signed by a key assigned to the reader, and the processor is further configured to determine whether the signed tag data has been effectively signed based on the corresponding key pair of the reader that is accessible to the blockchain peer.

8. The apparatus according to claim 1, wherein, The processor is configured to store the identifier of the tag and the tag data as key-value pairs in the state database of the blockchain.

9. A computer-implemented method, comprising: Sensor data is retrieved from one or more hardware sensors coupled to the tag, and the sensor data is stored in the tag's memory; The tag receives a read request from a reader associated with the blockchain network. When the reader is trusted, the trusted reader signs and forwards the sensor data in the tag using the private key of the trusted reader. When the reader is untrusted, the tag sends a challenge to the blockchain network via the untrusted reader. When a correct response is received from the blockchain network, the tag transmits the sensor data in the tag to the untrusted reader. The authenticity of the blockchain network is verified by the reader based on the handshake protocol between the tag and the blockchain; In response to successful verification by the blockchain network, a session key is generated based on a secret shared with the blockchain network, and the sensor data is encrypted based on the session key; and The encrypted sensor data is signed based on the private key of the tag, and the signed encrypted sensor data is sent to the reader.

10. The method of claim 9, further comprising: The integrity of the software running on the tag is checked via a bootloader on the tag during power-up.

11. The method according to claim 9, wherein, Verifying the authenticity of the blockchain network includes receiving data signed by the blockchain network and verifying the signed data based on the corresponding key of the blockchain network stored in the tag.

12. The method of claim 9, further comprising: The authenticity of the reader is verified by the tag based on a handshake protocol with the reader.

13. The method of claim 9, further comprising: Perform a key exchange with the blockchain network to establish the shared secret value between the tag and the blockchain network.

14. The method of claim 9, further comprising: The tag detects a data violation based on values ​​of sensor data retrieved from the one or more hardware sensors and stores the data violation in the memory.

15. The method according to claim 9, wherein, The tag's memory is protected from read and write operations, thereby preventing the private key from being read or modified by external entities.

16. A computer-implemented method, comprising: A blockchain peer receives encrypted tag data read from a tag associated with a physical object and signed using a key assigned to the tag by the blockchain network. When the reader is trusted, the trusted reader signs the tag data using its private key and forwards it. When the reader is untrusted, the tag sends a challenge to the blockchain network via the untrusted reader. When a correct response is received from the blockchain network, the tag passes the tag data to the untrusted reader. The signed tag data is determined to be validly signed by the blockchain peer based on the corresponding key pair of the tag that is accessible to the blockchain peer. A session key is generated based on a secret shared between the blockchain network and the tag via the blockchain peer, and the encrypted tag data is decrypted based on the session key; The blockchain peers determine whether the tag data satisfies one or more predefined conditions of the physical object; and The determination is made via a blockchain ledger.

17. The method of claim 16, further comprising: The authenticity of the tag is verified based on the sensor identifiers included in the tag data.

18. The method according to claim 16, wherein, The determination includes determining whether the tag data violates one or more predefined conditions embedded in the logic of the chaincode running on the blockchain peer.

19. The method of claim 16, further comprising: Warnings are sent to computing devices associated with the physical object via chaincode running on the blockchain peer.

Images