WO2019190394A1 - Procédés de distribution de logiciel à travers un réseau et systèmes de distribution - Google Patents

Procédés de distribution de logiciel à travers un réseau et systèmes de distribution Download PDF

Info

Publication number
WO2019190394A1
WO2019190394A1 PCT/SG2019/050159 SG2019050159W WO2019190394A1 WO 2019190394 A1 WO2019190394 A1 WO 2019190394A1 SG 2019050159 W SG2019050159 W SG 2019050159W WO 2019190394 A1 WO2019190394 A1 WO 2019190394A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
software
reputation score
smart contract
block
Prior art date
Application number
PCT/SG2019/050159
Other languages
English (en)
Inventor
Dinil Mon DIVAKARAN
Le Su
Sze Ling YEO
Jiqiang LI
Vrizlynn Ling Ling Thing
Original Assignee
Agency For Science, Technology And Research
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agency For Science, Technology And Research filed Critical Agency For Science, Technology And Research
Priority to SG11202009660SA priority Critical patent/SG11202009660SA/en
Publication of WO2019190394A1 publication Critical patent/WO2019190394A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Definitions

  • Various embodiments relate to methods of distributing software across a network and distribution systems.
  • IoT Internet of Things
  • a method of distributing software across a network may include: recording a transaction associated with the software, in a new block of a blockchain; wherein the new block is linked to a preceding block that records a latest earlier transaction associated with the software; computing a reputation score of the software based on the transaction and a previous reputation score stored in the linked preceding block; and storing the computed reputation score in the new block.
  • the distribution system may include a processor and a non-volatile computer memory storing computer readable instructions configured to generate a blockchain.
  • the blockchain may include: a plurality of blocks, wherein each block of the plurality of blocks stores a record of a transaction associated with software; and a plurality of smart contracts.
  • Each smart contract may correspond to a type of transaction.
  • At least one smart contract of the plurality of smart contracts may be configured to compute a reputation score of any software.
  • Each block may be linked to a preceding block that stores a record of a latest earlier transaction associated with the same software as the transaction of its stored record; and each block may store the reputation score of the software.
  • the distribution system may include: a plurality of nodes, wherein each node may be configured to selectively initiate transactions. At least a subset of the plurality of nodes may be configured to implement a plurality of smart contracts, each smart contract associated with a type of transactions. For each transaction initiated by one of the plurality of nodes, the transaction associated with software: another node of the plurality of nodes may be configured to record the transaction, in a new block of a blockchain. The new block may be linked to a preceding block that records a latest earlier transaction associated with the software. At least one smart contract of the plurality of smart contracts may be configured to compute a reputation score of the software based on the transaction and a previous reputation score stored in the linked preceding block.
  • FIG. 1 shows a system architecture diagram of a distribution system according to various embodiments.
  • FIG. 2 shows an example of a transaction data format according to various embodiments.
  • FIG. 3 A shows an example of a gateway information field according to various embodiments.
  • FIG. 3B shows an example of a SSP information field according to various embodiments.
  • FIG. 4 shows an example of a gateway register transaction according to various embodiments.
  • FIG. 5 shows an example of a gateway device register transaction according to various embodiments.
  • FIG. 6 shows an example of a SSP register transaction according to various embodiments.
  • FIG. 7 shows an example of a SSP device register transaction according to various embodiments.
  • FIG. 8 shows an example of a release transaction according to various embodiments.
  • FIG. 9 shows an example of an interest transaction according to various embodiments.
  • FIG. 10 shows an example of a review transaction according to various embodiments.
  • FIG. 11 shows an example of a purchase transaction according to various embodiments.
  • FIG. 12 shows a conceptual diagram of a blockchain network according to various embodiments.
  • FIG. 13 shows an example of a distribution system according to various embodiments.
  • FIG. 14 shows a flow diagram for a method of distributing software across a network.
  • FIG. 15 is a diagram illustrating an example of a hardware implementation for an apparatus employing a distribution system.
  • the distribution systems as described in this description may include a memory which is for example used in the processing carried out in the distribution systems.
  • a memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • DRAM Dynamic Random Access Memory
  • PROM Programmable Read Only Memory
  • EPROM Erasable PROM
  • EEPROM Electrical Erasable PROM
  • flash memory e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • a buyer node may be, but not limited to being, a gateway.
  • the properties described herein for a gateway may be applicable to any buyer node.
  • a seller node may be, but not limited to being, a Security Solution Provider (SSP), although a seller node may also be a provider of other software.
  • SSP Security Solution Provider
  • the properties described herein for a SSP may be applicable to any seller node.
  • “transaction” may refer to an exchange or interaction between nodes in a blockchain network, or an exchange or interaction between a node and the blockchain network.
  • “transaction” may not be limited to instances of buying or selling, for example, it may include registration of a node to the blockchain network, or exchange of information that does not have monetary value.
  • a method of distributing software across a network may be provided.
  • the method may employ a decentralized distribution system based on blockchain and smart contract technology.
  • the distribution system may include a blockchain network which may serve as a distribution platform for software.
  • the blockchain network may include a plurality of nodes that may include buyer nodes and supplier nodes.
  • the supplier nodes may be computers that provide software.
  • the buyer nodes may be computers that receive the software.
  • the supplier nodes and the buyer nodes may exchange information, for example, to perform a transaction, using a blockchain.
  • Information about the transactions may be stored in blocks of the blockchain.
  • the blockchain may be a ledger that stores all transactions.
  • the method may include maintaining and updating a reputation score of each software.
  • the buyer nodes may initiate further transactions associated with the software, based on the latest reputation score of the software.
  • the blockchain may include a new set of transaction formats for linking of blocks pertaining to records of the same solutions, and for aggregating reputation scores.
  • the transaction formats may be designed in a way to record necessary information and to trigger corresponding smart contracts.
  • the blockchain may store smart contracts that verify each transaction carried out in the network.
  • a smart contract may be a computer protocol that digitally facilitates, verifies, or enforces a transaction according to a set of predefined rules.
  • the buyer nodes may provide the computing power to execute the smart contracts.
  • all of the buyer nodes may verify the transaction and may compete to solve a mathematical puzzle.
  • the supplier nodes may be barred from performing the verification process to prevent them from manipulating the verification process.
  • the first buyer node to solve the puzzle also referred herein as the“winner” buyer node, may add a new block to the blockchain and may record the transaction in the new block.
  • the winner buyer node may link the new block to an immediately preceding block in the blockchain, as well as to the most recent related block that records the most recent earlier transaction associated with the same software as the transaction recorded in the new block.
  • the blockchain may store a reputation score for each software that is uploaded to the network.
  • the smart contracts may compute and/or update the reputation score of software based on a current transaction and the last updated reputation score of the software which may be stored in the most recent related block that the new block is linked to. Transactions that influence the reputation score of the software may include a review, or a purchase of the software.
  • the buyer nodes may determine whether to download the software based on the reputation score of the software.
  • the smart contract associated with purchasing the software may check that the reputation score meets a first threshold, before proceeding with the purchase transaction.
  • the buyer nodes may install the software or apply the software to an electronic device connected to the buyer node, once the purchase transaction is verified.
  • the buyer nodes may install the software onto the electronic devices automatically after the purchase transaction is verified, if the reputation score of the software is above a second threshold.
  • the second threshold may be the same as or higher than, the first threshold. If the reputation score is below a minimum threshold, any one of the buyer nodes may initiate a de-registration transaction for removing the software from the network.
  • the minimum threshold may be lower than both the first threshold and the second threshold.
  • the method described above may efficiently and securely distribute, as well as deploy, verifiable software such as IoT security solutions through a decentralized system.
  • the method may ensure the integrity, authenticity and non-repudiation of the transactions using cryptographic primitives, smart contracts and“miners”.
  • the smart contracts may be computer protocols that automatically execute the transactions while ensuring that predefined rules are met.
  • the miners may be computer nodes in the network that verify the transactions, similar to “miners” in a bitcoin platform.
  • the distribution platform does not have a centralized authority and each participant may act according to predefined rules, the distribution platform may be resistant to manipulation by any single party.
  • the smart contracts may achieve full automation of the entire transaction process. By performing a sequence of logical condition checking, the smart contracts may guarantee the secure execution of the entire solution distribution process, in order to prevent foul play such as purposely providing negative feedback while still purchasing the actually well-working solution.
  • the buyer nodes may be gateway devices.
  • Each gateway device may be connected to a respective group of user devices.
  • a gateway device may be a machine, or a computer, that connects each user device to a network, such as a Wide Area Network (WAN), a Local Area Network (LAN), or the Internet.
  • the gateway device may controls data traffic received and transmitted by the user devices.
  • the gateway device may act as a controller that analyzes, processes and manipulates data traffic with the aim of protecting the user devices.
  • the gateway device may also serve as a firewall with high computational and storage capabilities.
  • the gateway device may also be referred herein as “gateway server” or“gateway”.
  • the user devices may be IoT devices.
  • the software may be security solutions.
  • a security solution may be any software solution that protects a device, for example an IoT device, against a non-empty set of vulnerabilities.
  • Examples of the software include software patch, a firmware update, an independent software solution module that can be installed in the device or a gateway connected to the device.
  • the software may also be a set of rules specific to an IoT or one of its services.
  • a gateway may be“intelligent” in the sense that it may deploy security solutions to its group of user devices dynamically and as early as possible with respect to the time when a vulnerability is known.
  • the gateway may carry out functions such as patching the user devices, inspecting the traffic of the user devices, checking the traffic for patterns related to new exploits for which patches are not available, and manipulating data packets of the traffic, etc.
  • the gateways may serve as the last line of defense for IoTs in a network, such as a home network.
  • the gateways may have large storage and may be capable of performing heavy computations.
  • the gateways may be connected to the Internet. Each gateway may have its own public-private key pair, which may be used for generating digital signatures.
  • Each device in a home IoT network may have an embedded digital signature public-private key pair, issued by the vendor of the device. This key pair may not be extractable. For example, the key pair may be stored in a tamper-resistant module. Each device in an IoT network may trust its gateway, such that the gateway may act on behalf of the devices it controls.
  • FIG. 1 shows a system architecture diagram 100 of a distribution system according to various embodiments.
  • the distribution system may include a blockchain network.
  • the blockchain network may include a plurality of nodes. Each node of the plurality of nodes may be connected to the Internet 102. Alternatively, all of the nodes may be connected to a closed network.
  • the plurality of nodes may consist of only two types of nodes - supplier nodes and buyer nodes.
  • the supplier nodes may be security solution providers (SSP) 106.
  • the buyer nodes may be IoT gateways 104. Each buyer node may be connected to a plurality of user devices 108, which may be electronic devices, for example, IoT appliances.
  • the user devices 108 may include household appliances such as televisions, digital door locks, personal computers, mobile phones, lights, coffeemakers, refrigerators, microwaves and air- conditioners.
  • Each IoT gateway 104 may be connected to appliances belonging to one household such that each household only requires one gateway.
  • the quantity of buyer nodes may outnumber the quantity of supplier nodes in orders of magnitude.
  • all of the nodes may be connected to form a peer-to-peer (P2P) network.
  • the P2P network of nodes may collectively store a decentralized database of information.
  • Each node may be assigned with a cryptographic key pair (public and private key) that may be used to digitally sign and verify messages.
  • An SSP 106 may develop and may release security solutions for any type of user device. When releasing a security solution, the SSP 106 may include a trial version of the security solution. If a gateway 104 decides to verify and apply a particular solution (for example, to fix a security flaw of one of its devices), the gateway 104 may download the trial version of the solution from the SSP 106. The gateway 104 may apply and evaluates the security solution, and may subsequently report the outcome to the network. The reported outcomes, also referred herein as feedback, by the gateways 104 may provide an indication of the effectiveness of the security solutions that are being released into the market, i.e. the blockchain network in this context.
  • the reported outcomes by the gateways 104 may influence, or contribute to the reputation of the security solutions.
  • the reputation of the security solutions also contribute to the reputation for the corresponding SSP 106 that developed the security solution(s).
  • the gateway 104 after testing the trial version, may have the right to decide whether to purchase the solution or not.
  • the above described process may be realized through a series of transactions.
  • the series of transactions may be executed by a plurality of smart contracts which may be triggered when the transactions are initiated.
  • the process may include recording these transactions in the blockchain, and miners may verify the authenticity and integrity of these transactions.
  • the miners may be the gateways 104.
  • the distribution system may be understood as an interaction between two types of entities, namely the SSP 106 and the gateways 104, through a set of transactions which invoke pre-defined smart contracts.
  • the participants of the distribution system and the blockchain network are described in further details as follows:
  • the buyer nodes may be computers that represent the recipients of software, i.e. customer or buyer in the distribution system.
  • the buyer nodes may be gateways 104 in a non-limiting embodiment.
  • the gateway 104 may be a machine that connects user devices 108 to the Internet or to a closed network.
  • the user devices 108 that are connected to a single gateway 104 may be closely located or may be located in the same neighborhood, for example, in the same house.
  • the gateway 104 may filter the IoT data traffic sent to the user devices 108, to prevent unauthorized or even malicious data from reaching the user devices 108.
  • the gateway 104 may include a processor and may also include a storage device such as a memory.
  • the gateways 104 may make up the majority of the computing nodes in the blockchain network.
  • the seller nodes may represent the provider of software, i.e. the seller in the distribution system.
  • the seller nodes may be SSPs 106.
  • the SSP 106 may be a machine, such as a computer, that provides the security solutions for the user devices 108.
  • the seller may be entities that develop and/or sell security solution(s) related to a particular (set of) user devices 108, which may be the manufacturer of the user device 108, or any third party service provider.
  • a transaction participant may initiate transactions by invoking a smart contract that corresponds to the desired type of transaction. Both the buyer nodes and the seller nodes may take on the role of the transaction participant.
  • the miners may verify each transaction and corresponding smart contract executions that take place in the blockchain network, and may subsequently write the verified transaction into the blockchain. Only the buyer nodes may take on the role of the miners, to enhance the trustiness of the distribution system.
  • the seller nodes which may be the SSPs 106, may be banned from being miners. This prevents undesirable software from being released into the blockchain and those transactions as being fraudulently verified or recorded by the seller nodes.
  • the buyer nodes and the seller nodes in the distribution system may initiate several types of transactions.
  • the types of transactions may include (1) register, (2) release, (3) interest, (4) review and (5) purchase. These transaction types will be described in further details in subsequent paragraphs.
  • An associated smart contract may be triggered in order to complete a set of tasks associated with the transaction.
  • a smart contract may be a computer program comprising a set of protocols that execute a pre-defmed set of actions.
  • the smart contract may receive inputs, executes the rules written in the contract based on the received inputs, and produces an output.
  • the smart contract may include three components, namely an address (for example, a public key), a set of pre-defmed rules, and storage.
  • a smart contract may be triggered by any of the network participants, or another smart contract. Triggering a smart contract may include initiating a transaction to the smart contract address, and providing input within the transaction.
  • FIG. 2 shows an example of a transaction data format 200 according to various embodiments.
  • the transaction data format 200 may include a plurality of fields.
  • the transaction (abbreviated as“Txn”) type field 202 may indicate a type or nature of the transaction, for example one of the following five possible values: register, release, interest, report, and purchase.
  • the time stamp field 204 may be used to store the time when the transaction is created. The granularity of the time stamp field 204 may be set according to the application and network requirement.
  • the time stamp field 204 may be a standard field for all transactions, and thus the subsequent paragraphs describing the data format of different types of transactions will omit further description of the time stamp field, unless otherwise required.
  • the transaction data format 200 may include a gateway information field 206 and a SSP information field 208.
  • the gateway information field 206 may be further divided into three sub-fields, as shown in FIG. 3A.
  • the SSP information field 208 may similarly be divided into three sub-fields, as shown in FIG. 3B.
  • the smart contract information field 210 may include an address of the smart contract (for example, a public key of the smart contract) that corresponds to the transaction type.
  • the blockchain network may store a plurality of smart contracts, and the address of the smart contract may point to a storage location in the blockchain network. As mentioned above, each transaction may interact with the associated smart contract to trigger a set of actions to be carried out.
  • each transaction may need to include the smart contract address, in order to identify the corresponding smart contract from the pool of stored contracts.
  • the amount field 212 may be used for storing monetary value associated with a particular transaction.
  • the amount field 212 may be left empty for transactions that do not involve any monetary value transfer.
  • the previous transaction hash (abbreviation:“PreTxnHash”) field 214 may store the hash output of the previous transaction that is related to this current transaction.
  • the definition of“related”, or to be exact the“previous transaction”, will be defined in detail in subsequent paragraphs, together with the specific transaction description.
  • the hash output may be generated using a standard, secure hash function such as the secure hash algorithm 256 bits (SHA256).
  • the previous transaction hash may be:
  • PreTxnHash SHA256 (previous transaction)
  • FIG. 3A shows an example of a gateway information field 206, according to various embodiments.
  • the gateway information field 206 may include a gateway identifier (abbreviation:“ID”) sub-field 302, a device ID sub-field 304 and a data sub-field 306.
  • the gateway ID sub-field 302 may store a unique identifier for each gateway 104.
  • the identifier for the gateway 104 may be a unique public key associated with the gateway 104.
  • the device ID sub-field 304 may store the unique identifier of a user device 108 that the gateway 104 controls.
  • the identifier of the user device 108 may be the user device public key, or the user device serial number, or a combination of both.
  • the data sub-field 306 may be used to store transaction-specific data, such as the digital signature of the user device 108 during registration, or a solution evaluation report for the review transaction. Details of the data sub field 306 in the context of different transactions, are discussed in the subsequent paragraphs.
  • One or more sub-fields of the gateway information field 206 may be left empty for some types of transactions.
  • FIG. 3B shows an example of a SSP information field 208, according to various embodiments.
  • the SSP information field 208 may include a SSP ID sub-field 308, a device ID sub-field 310 and a data sub-field 312.
  • the SSP ID sub-field 308 may store a unique identifier for each SSP 106, which may be a unique public key associated with the SSP 106.
  • the device ID sub-field 310 may store a unique identifier of a user device connected to the SSP 106, that may be of the same product model as the user device 108 controlled by the gateway.
  • the SSP 106 may provide security solutions for the user device 108.
  • the unique identifier stored in the device ID sub-field 310 may serve to verify that the SSP 106 indeed has the user device that it is providing the security solution for.
  • the data sub-field 312 may be used to store transaction-specifie data, such as the digital signature of the user device 108 during registration, or a solution evaluation report for the review transaction.
  • One or more sub-fields of the SSP information field 208 may be left empty for some types of transactions.
  • Any first-time entity may need to register in the blockchain network in order to access the services of the blockchain network.
  • the registration process may be similar for both the gateways 104 and the SSPs 106.
  • Each of the gateway 104 and the SSP 106 may require two types of registration - first, registration for themselves; and second, registration for each device that they control for the security solution.
  • SSPs 106 may control similar user devices
  • a SSP 106 that provides security solutions only for smart televisions may control many types of smart televisions, but may not control any other type of user devices 108 such as smart phones.
  • FIG. 4 shows an example of a gateway register transaction 400 according to various embodiments.
  • a gateway 104 may be required to perform self-registration with the blockchain network before it may be permitted to register the user devices 108 that it controls.
  • the gateway register transaction 400 may be filled out in the transaction data format 200.
  • the transaction type field 202 may be filled out to indicate that this transaction is a registration.
  • the gateway information field 206 may be filled only with the gateway address (GW add) in the gateway identifier field 302.
  • the gateway address may be, for example, the public key of this particular gateway.
  • the device ID sub-field 304 and the data sub-field 306 may be filled with zero(s) or left empty.
  • the SSP information field 208 may be filled with zero or left empty.
  • the smart contract information field 210 may be filled with an address of a smart contract“registration smart contract”. This smart contract may be pre-written and stored on the blockchain.
  • the smart contract may be distributed across the blockchain network, i.e., each node may store a copy of all available types of smart contract.
  • the smart contracts may be stored in a centralized location, for example a server that is external to the blockchain network.
  • the gateway 104 may trigger the registration smart contract to be executed. When the registration smart contract is executed, it may invoke codes to carry out the registration procedures.
  • the self-registration of the gateway 104 does not require payment of fees, so the amount field 212 may be left empty.
  • the amount field 212 may be customizable to suit the application, for example, in another embodiment, the distribution system could charge a fee even for registration and in that embodiment, the amount field 212 may be filled with the system-defined monetary value.
  • the PreTxnHash field 214 may store a hash of a string of zeros by default, since there is no transaction earlier than the self-registration for this gateway 104.
  • the gateway 104 may generate a digital signature Sig GW based on the information in the abovementioned fields, to complete the digital signature field 216.
  • the registration smart contract stored at the address SCjreg may be triggered, and the registration smart contract may self-execute a set of pre-defined rules.
  • the registration smart contract may perform the following tasks: 1. Check that GW add, the gateway address in the gateway ID sub-field 302 has not been previously registered; and
  • the registration smart contract may output 1, so that the gateway 104 may be successfully registered. If any one of the above two conditions are not met, the registration smart contract may output 0 so that the registration request is declined.
  • the digital signature field may be generated in a similar way as described above, using all the previous fields in the transaction data format 200 as the underlying message to be signed.
  • the Time Stamp may be used to prevent replay attack.
  • the gateway 104 may then register the user devices 108 that it controls, in order to access services provided by SSPs, for example, to be able to initiate a successful transaction with the SSPs. If a gateway 104 has not registered any user devices 108, the distribution system may prohibit the gateway 104 from performing any other transactions. This is to prevent a malicious entity from registering many“empty shell” gateways, each one without any user device 108, for the purpose of launching attacks on nodes in the blockchain network. To register a specific user device 108, the gateway 104 may initiate a gateway device register transaction, like shown in FIG. 5.
  • FIG. 5 shows an example of a gateway device register transaction 500 according to various embodiments.
  • the gateway device register transaction 500 may be filled in a similar manner as the gateway register transaction 400, except for a few fields such as the gateway information field 206 and the PreTxnHash field 214.
  • the device ID sub-field 304 of the gateway information field 206 may be filled with the serial number, or public key, or a combination of both, of a particular user device 108.
  • the device ID, denoted as D_ID may uniquely identify the user device 108.
  • the data sub-field 306 of the gateway information field 206 may be a signature generated by the user device 108, denoted as D_sig.
  • Each user device 108 may have an embedded public-private key pair.
  • the public-private key pair may be tamper-resistant.
  • the public key may be provided by the user device manufacturer, and therefore publicly available.
  • the gateway may trigger the user device 108 to generate such a signature.
  • the underlying message used for this signature generation may include the timestamp for this transaction, the gateway ID and the device ID.
  • the user device signature is required to verify that the gateway 104 indeed has control over the user device 108, so as to prevent the gateway 104 from falsely registering user devices that are not controlled by itself.
  • the PreTxnHash field 214 may be filled with the hash result of the previous transaction by the same gateway 104, which is the gateway register transaction 400. This is to make sure that a gateway 104 has registered itself before registering a user device 108.
  • the gateway 104 may generate a digital signature of this transaction like described above, using the data in the fields 202, 204, 206, 208, 210, 212 and 214.
  • the gateway device register transaction 500 may designate to the same smart contract SC reg, as the gateway register transaction 400.
  • the smart contract SC_reg may execute the following tasks:
  • Each gateway 104 may maintain locally, a database of all transactions that it has executed. This allows each gateway 104 to quickly identify the previous transaction, for efficiently computing the PreTxnHash field 214 and other required data.
  • the smart contract SC reg may output a Boolean value 1. If any of the above tasks yield a negative result, SC reg may output a Boolean value 0. This may complete the user device registration.
  • FIG. 6 shows an example of a SSP register transaction 600 according to various embodiments.
  • the format of the SSP register transaction 600 may be similar to the gateway register transaction 400.
  • the SSP may similarly register itself using the SSP register transaction 600, and also register its device as shown in FIG. 7.
  • the gateway information field 206 may be zero since there is no interaction with a gateway.
  • the SSP information field 208 may store the SSP address, such as the SSP public key, in the SSP ID sub-field 308.
  • the SSP register transaction 600 may indicate the address of the corresponding smart contract in the smart contract information field 210.
  • the corresponding smart contract may be SCjreg, the same smart contract as for the gateway register transaction 400.
  • the digital signature field 216 may include an SSP digital signature.
  • the smart contract SCjreg may verify the legitimacy of this transaction by performing the same checking tasks as for the gateway register transaction 400.
  • FIG. 7 shows an example of a SSP device register transaction 700 according to various embodiments.
  • the format of the SSP device register transaction 700 may be similar to the gateway device register transaction 500.
  • the SSP information field 208 may be filled with the SSP address in the SSP ID sub-field 308, the device ID in the device ID sub-field
  • the previous transaction hash field 214 may be filled with the SSP register transaction 600.
  • the registration smart contract may carry out a sequence of tasks or actions, similar to those for the gateway device register transaction 500, to check the legitimacy of the transaction.
  • FIG. 8 shows an example of a release transaction 800 according to various embodiments.
  • An SSP 106 may create a release transaction 800 to make a new security solution available on the blockchain network.
  • a release transaction may be created only by SSPs 106.
  • the smart contract associated with this transaction may be a release smart contract, denoted as SC_rel.
  • the data sub-field 312 under the SSP information 208 may store a link or a pointer, for example, a URL, or an address that directs to a location where the security solution being released by the SSP 106 is stored.
  • the security solution may be stored in a memory of the SSP 106.
  • the SSP 106 may limit access to the link, by using for example, a password, or an authentication request.
  • the release transaction 800 may specify a deposit amount in the amount field 212.
  • the deposit amount may be a monetary value deducted from the SSP’s account.
  • the purpose for this deposit is to motivate SSPs 106 to provide reliable and useful solutions to the gateways 104, and prevent them from offering low-quality solutions.
  • a portion of the deposit may be deducted when a gateway gives a negative feedback for the security solution using a review transaction, which will be described in subsequent paragraphs.
  • the release smart contract may remove the security solution from the blockchain or block off access to the security solution, for example using a de-register transaction which will be described subsequently.
  • the amount field 212 may indicate a feedback score of the SSP 106 or the security solution.
  • the feedback score may also be referred herein as a reputation score.
  • the feedback score may be deducted when a negative feedback is issued, similar to the deposit amount.
  • the release smart contract upon receiving the release transaction 800, may check the following:
  • the SSP 106 has registered the device (i.e., the previous transaction);
  • the release smart contract may store the rel_deposit value into its own storage, for future usage.
  • FIG. 9 shows an example of an interest transaction 900 according to various embodiments.
  • An interest transaction 900 may be created by a gateway 104, to make a request to a SSP 106 for trying out a security solution offered by the SSP 106. With this transaction, the gateway 104 and the SSP 106 may enter into a contract, wherein the SSP 106 may transfer a trial version of the security solution to the gateway 104. The trial version of the security solution may have an expiry time, beyond which the security solution may cease to function.
  • the transaction type field 202 may be indicated as“interest”.
  • the gateway information field 206 may be filled with information relating to the gateway 104 that is making the request and its user device 108 that may be receiving the security solution.
  • the data sub-field 306 may be filled with zero, as the user device signature may not be required in this transaction.
  • the SSP information field 208 may be filled with information relating to the SSP 106 that provides the security solution that the gateway 104 is requesting to try.
  • the data sub-field 312 of SSP info may be filled with the link of the security solution.
  • the transaction may be targeted at the specific interest smart contract, with SC_int as its address.
  • the amount field 212 may record an interest deposit, denoted herein as“int deposit”.
  • the gateway 104 may leave an interest deposit with the interest smart contract.
  • the interest deposit may be transferred back to the gateway 104 after it submits a feedback, i.e. review of the security solution via a review transaction.
  • the review may contain information on the merits and demerits of the security solution.
  • the review may explicitly inform all the nodes in the blockchain network whether the solution worked for the user device 108.
  • the distribution system may incentivize the gateway 104 to review the security solution that it tested.
  • the interest smart contract may distribute the interest deposit equally between the SSP 106 and the gateway 104 if the gateway 104 does not review the security solution after a predefined time duration, i.e. before a review deadline.
  • the interest deposit may be split according to other ratios and in accordance with other predefined rules.
  • the review deadline may be later than the expiry time of the trial solution, so that the gateway 104 has sufficient time to review the trial solution.
  • the gateway 104 has registered the device (i.e., the previous transaction);
  • the smart contract may also check whether there exists a Review transaction initiated by the gateway 104 for this particular security solution. If the review transaction does not exist, the interest deposit may be forfeited and divided according to the pre-defined rules. If the gateway 104 has already submitted a review transaction, the interest deposit may be returned to the gateway 104.
  • the interest smart contract may verify that the gateway 104 had not submitted an earlier interest transaction 900 for the same security solution, so as to prevent the gateway 104 from behaving maliciously. It is not necessary for a gateway 104 to test a security solution multiple times. If the gateway 104 has already tested the security solution, the distribution system prevents a malicious gateway 104 in attempting to influence the reputation of a solution or SSP 106. By checking if there is sufficient release deposit, the smart contract may ensure that the security solution is still valid for gateways 104 to try out. If the release deposit falls below a threshold, the security solution may have received many negative reviews and therefore, should not be released to another gateway 104.
  • FIG. 10 shows an example of a review transaction 1000 according to various embodiments.
  • a gateway 104 may review the security solution, via a review transaction 1000.
  • the gateway 104 may have an incentive to do so, in the form of receiving a refund of the interest deposit.
  • the gateway 104 may indicate the outcome of the evaluation.
  • the gateway 104 may indicate in the review transaction, either success or failure, corresponding to the outcome of the evaluation.
  • the review transaction 1000 may be similar to the interest transaction 900, except that the data sub-field 306 of the gateway information 206 field may stored the outcome of the testing for the security solution, denoted as“out”.
  • the possible values of“out” may be either success, or failure.
  • the amount field 212 may be zero, as there may be no money transfer in this transaction.
  • a gateway 104 wants to report that the security solution has failed, it may indicate‘ failure” in the data sub-field 306. However, there is a possibility that a gateway 104 may report a false review for a security solution, for example, to give advantage to another SSP 106.
  • the distribution system may bar a gateway 104 from purchasing a security solution after it reports a security solution as failure in a review transaction 1000. This scheme may discourage the gateway 104 from lying about a failure as the gateway may not be allowed to purchase a successful solution. If the solution works successfully, the gateway may specify success in the data sub-field 306.
  • the previous transaction hash field 214 may store the hash value of the interest transaction 900 for this particular security solution. While it may be possible for an SSP 106 to incentivize a set of gateways 104 to report positive reviews of its security solution which does not work well, such a method of cheating may be impractical in a large network with many gateways 104.
  • the SSP 106 may have to provide incentives to a large percentage of the gateways 104 to cheat the system successfully. This may be too expensive for an SSP to make eventual gain from the market, besides even being financially improbable.
  • SC_rev the associated review smart contract
  • the review smart contract may check that the gateway 104 has not submitted earlier review reports for the same security solution, to prevent the gateway 104 from flood the system with repetitive reviews.
  • the review smart contract may re-compute the reputation score of the security solution whenever there is a review transaction 1000.
  • the review smart contract may return the interest deposit to the gateway 104.
  • Actions 4 and 5 may trigger transactions that involve monetary values. As these may be basic money transfers which may be completed with a basic transaction that indicates (1) the address of an associated smart contract for remitting money, (2) the address of the recipient (such as the gateway 104 for int deposit refund, or a central pool of funds for failure report deduction), and (3) the monetary value. These transactions may be performed using the transaction format 200. These transactions may be available for verification by the miners which may be the gateways 104, may be added into the blockchain.
  • FIG. 11 shows an example of a purchase transaction 1100 according to various embodiments.
  • Any gateway 104 may create a purchase transaction 1100, to purchase a security solution from a SSP 106.
  • the amount field 212 of the purchase transaction 1100 may be filled with the purchase price, i.e. the payment amount to be transferred to the SSP 106 in exchange for the security solution.
  • the distribution system may allow the gateway 104 to purchase a security solution even it has not tested it before. This may be reasonable, as the gateway 104 may have purchased other solutions from the same SSP 106 before and therefore trusts it, or may simply decide on the purchase based on the reputation score.
  • the gateway 104 may initiate the purchase transaction of the security solution when the reputation score of the security solution is above a threshold.
  • the gateway 104 may also compare the reputation scores of a plurality of security solutions available for its user device 108, and then initiate a purchase transaction 1100 for the security solution that has the highest reputation score.
  • the gateway 104 may determine whether to initiate the purchase transaction 1100 or determine which security solution to purchase, using an associated smart contract.
  • the gateway 104 need not have carried out an interest transaction 900 and a review transaction 1000 in order to initiate a purchase transaction 1100.
  • the previous transaction indicated in the PreTxnHash field 214 may not be limited to one type of transaction, for example, it may indicate a device registration transaction, or a review transaction.
  • the smart contract associated with the purchase transaction 1100 may be, for example, a purchase smart contract having the address SC_pur.
  • the associated purchase smart contract may perform the following actions:
  • the purchase smart contract may improve the reputation score based on the purchase transaction 1100.
  • the rationale may be that every successful purchase may be an affirmation of the security solution.
  • the last action of payment transfer may include triggering an associated transaction for money transfer, for example, by activating another smart contract associated with money transfer.
  • the major contribution to the reputation score may come from purchase transactions 1100.
  • the distribution system may also include an optional de-register transaction.
  • the de-register transaction may serve to nullify any register transactions. Once a gateway 104 is no longer in control of a particular user device 108, or a user device 108 is no longer present in the network, or similarly if an SSP 106 has quit the market, the gateway 104 or the SSP 106 may initiate a de-register transaction to leave a record in the blockchain.
  • the de-register transaction need not be implemented in the distribution system, as these inactive entities may still exist in the blockchain network without causing any storage or computational overhead to the blockchain network.
  • FIG. 12 shows a conceptual diagram 1200 of a blockchain network according to various embodiments.
  • the blockchain 1210 may be a linked (chained) plurality of blocks 1204.
  • Each block 1204 may be created by a miner.
  • the blocks 1204 may be linked using their hash addresses.
  • Each time a miner verifies a set of transactions, it may create a new block 1204 and add the new block 1204 to the blockchain 1210.
  • the blockchain 1210 may function as a ledger of all transactions that take place on the blockchain network.
  • each block may consist of transactions related to only one particular security solution, for example a solution denoted as S. This may be useful in computing the reputation score of the security solution efficiently.
  • Each block 1204 may store the latest computed reputation score for one and only one security solution.
  • a newly mined block may also contain the hash address that links it to the previous block that has transactions for the same security solution (referred herein as a second link 1208).
  • a miner may compute the reputation score of a solution, by simply accessing the last block related to the solution S, and adding the reputation scores due to transactions in the current block to the reputation score stored in the last block related to the solution S.
  • the SSP or the devices as these transactions are not related to any particular security solution, they mat be mined and added to the latest block together with other grouped, security solution-related transactions, according to the transaction timestamp.
  • the blockchain network may include a plurality of unconfirmed and unordered transactions 1202.
  • the unconfirmed and unordered transactions 1202 may include new transactions that have not yet been verified by the miners which may be the buyer nodes. After the unconfirmed and unordered transactions 1202 have been verified by the miners, they may be added into the blockchain 1210. For each successfully mined block 1204, a new block ID may be created. The block ID may be the hash value of the block 1204. Further, the miner may chain the newly mined block 1204 to the previous block by listing the“Prev Blk ID”, i.e. indicated by the first link 1206.
  • each block 1204 may also be chained to the latest previous block (Prev Soln X Blk) that contains the transactions for the same security solution, indicated by the second link 1208.
  • Each block 1204 may contain the transactions related to the same solution.
  • the miners may responsible for creating blocks of transactions to be added to the ledger. Only the buyer nodes such as the gateways 104 may be the miners in the distribution system, so as to prevent the seller nodes such as the SSPs 106 from gaining any advantage in the mining process. Besides the task of gathering the transactions and creating a block 1204, the miners may also be required to verify each transaction. For such transaction verification, a miner may repeat the same actions as the smart contracts do for each transaction. The miner may verify the conditions listed as being satisfied, as well as ascertain that the smart contracts have faithfully executed the stipulated actions. Once the verifications of the transactions gathered have been completed, the miner may create the new block 1204.
  • Each block 1204 may store records of at least one transaction associated with the same software, for example two or more transactions.
  • a miner which has verified a transaction and subsequently successfully created a block 1204 may be rewarded. This reward may come from the transaction processing fees obtained from executing the smart contracts, and may be provided by the SSPs 106.
  • the reputation score of security solutions may be computed by the miners, during the process of verification of transactions.
  • the reputation score for a new untested solution may be initialized to zero.
  • the reputation score of a solution S may be denoted as r(S).
  • the reputation score may be stored in each block 1204. Since each block 1204 has only transactions related to one particular security solution, there may be only one reputation score stored in each block 1204. For every positive ( succession ) review report submitted by a gateway 104, the associated smart contract may execute an increment _rep() function to increase the reputation score. For every negative (failure ) review report submitted, the associated smart contract may execute a decrement repQ function to decrease the reputation score.
  • FIG. 13 shows an example of a distribution system 1300 according to various embodiments.
  • a plurality of SSPs 106 and gateways 104 may be communicatively coupled via a network such as the Internet 102.
  • a network such as the Internet 102.
  • the gateways 104 and the SSPs 106 may communicate via a blockchain platform 1310.
  • the blockchain platform 1310 may store smart contracts 1302, un-consolidated transactions 1202, and mined blocks (blockchain 1210).
  • a gateway 104 and an SSP 106 may register themselves and their devices by invoking the“register” smart contract 1312, and may create corresponding transactions, for example denoted as txn 1, txn2, txn 10. The transactions may be not recorded in sequence because there may be other transactions resulting from other gateway/SSP interactions.
  • the SSP 106 may release its security solution by triggering the“release” smart contract 1314.
  • a corresponding transaction, txn 11, may be created as a result.
  • Actions A3.1, A3.2 and A3.3 may be a sequence of actions.
  • the gateway 104 may invoke the“interest” smart contract 1316. By doing so, the gateway 104 may express its intention to try a particular solution“XX”.
  • the“interest” smart contract 1316 may trigger Action A3.2.
  • the“interest” smart contract 1316 may inform the SSP 106 that the gateway 104 wishes to try the solution.
  • the SSP 106 may provide the solution to the gateway 104.
  • it may review the solution in Action A4.1.
  • the“review” smart contract 1318 may be activated.
  • the “review” smart contract 1318 may update the reputation score of the SSP 106 and this particular solution, through Action A4.2.
  • Actions A5.1, A5.2 and A5.3 may be a sequence of actions.
  • the gateway 104 may trigger Action A5.1 with a purchase transaction.
  • The“purchase” smart contract 1320 may be activated to check, and then trigger Action A5.2 to inform the SSP 106 to release the solution.
  • Action 5.3 the SSP 106 may release the solution to the gateway 104.
  • Action 5.1 may include updating the reputation score of the SSP 106.
  • Each action may create associated transactions which the gateways 104 may mine to form blocks to be added to the blockchain 1210. Each block may record more than one transaction associated with the same software.
  • the distribution system 1300 may differ from traditional peer-to-peer (P2P) content distribution networks in that all the actions in the distribution system 1300 as represented through the format of transactions, may be recorded in the ledger.
  • the blockchain 1210 may be the ledger. These actions may be integrity-checked, authenticity-verified and non- repudiation-achieved through cryptographic primitives, and carried out by smart contracts and miners in the distribution system 1300.
  • the distribution system 1300 may assume minimum trust among the participants, and any modification on the transactions may be easily detected.
  • the distribution system 1300 may utilize smart contract technology to achieve rich functionalities, for example, enforcing time-dependent transactions like providing a deadline to submit reviews, storing of deposits etc.
  • the distribution system 1300 may leverage on the usage of smart contract, to incentivize the participants to behave faithfully, and may penalize them otherwise.
  • the distribution system 1300 may prevent malicious attacks, such as falsely providing negative reviews of successful solutions or falsely removing negative reviews.
  • the distribution system 1300 may use the transactions and the enforcement of the smart contracts to compute the reputation score of the security solutions.
  • the reputation score may help gateways 104 to quickly identify a trustworthy solution, as well as motivate the SSPs 106 to provide high-quality solutions.
  • FIG. 14 shows a flow diagram 1400 for a method of distributing software across a network.
  • the method may be performed by an autonomous system.
  • the method may be performed by an apparatus.
  • the method may include elements 1402, 1404 and 1406.
  • Element 1402 may include recording a transaction associated with software.
  • a buyer node of the network may record the transaction.
  • the transaction may be recorded in a new block of a blockchain.
  • the new block may be linked to a preceding block that records a latest earlier transaction associated with the software.
  • Element 1404 may include computing a reputation score of the software based on the transaction and a previous reputation score stored in the linked preceding block.
  • a smart contract associated with the transaction may compute the reputation score.
  • Element 1406 may include storing the computed reputation score in the new block.
  • a further transaction associated with the software may be initiated based on the reputation score.
  • a buyer node may initiate the further transaction.
  • the buyer node that initiates the further transaction may be a different buyer node from the buyer node that recorded the earlier transaction.
  • the further transaction may be a purchase transaction for installing the software onto an electronic device.
  • a smart contract may trigger an installation of the software, by the buyer node, onto the electronic device upon checking that the reputation score is above the threshold.
  • the software may be applied to protect the electronic device from security vulnerabilities.
  • the further transaction may be a de-registration transaction for removing the software from the network.
  • FIG. 15 is a diagram 1500 illustrating an example of a hardware implementation for an apparatus 1502' employing a distribution system 1514.
  • the apparatus 1502’ may be the apparatus described above with reference to FIG. 14.
  • the apparatus 1502’ may include one or more computing devices.
  • the distribution system 1514 may be implemented with a bus architecture, represented generally by the bus 1524.
  • the bus 1524 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 1514 and the overall design constraints.
  • the bus 1524 links together various circuits including one or more processors and/or hardware components, represented by the processor 1504 and the computer-readable medium / memory 1506.
  • the bus 1524 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.
  • the processing system 1514 includes a processor 1504 coupled to a computer- readable medium / memory 1506.
  • the processor 1504 is responsible for general processing, including the execution of software stored on the computer-readable medium / memory 1506.
  • the software when executed by the processor 1504, causes the processing system 1514 to perform the various functions described supra for any particular apparatus.
  • the computer- readable medium / memory 1506 may also be used for storing data that is manipulated by the processor 1504 when executing software.
  • the computer readable medium/memory 1506 may store computer readable instructions configured to generate a blockchain.
  • the blockchain may be the blockchain 1210 described with reference to FIG. 12.
  • the processor 1504 may be configured to generate the blockchain, for example, based on the computer readable instructions stored in the computer readable medium/memory 1506.
  • Example 1 is a method of distributing software across a network.
  • the method may include: recording a transaction associated with the software, in a new block of a blockchain; wherein the new block is linked to a preceding block that records a latest earlier transaction associated with the software; computing a reputation score of the software based on the transaction and a previous reputation score stored in the linked preceding block; and storing the computed reputation score in the new block.
  • Example 2 the subject matter of Example 1 may optionally include: initiating a further transaction associated with the software based on the reputation score.
  • Example 3 the subject matter of Example 2 may optionally include that the further transaction is one of a purchase transaction for installing the software onto an electronic device when the reputation score is above a threshold and a de-register transaction for removing the software from the network when the reputation score is below a threshold.
  • the further transaction is one of a purchase transaction for installing the software onto an electronic device when the reputation score is above a threshold and a de-register transaction for removing the software from the network when the reputation score is below a threshold.
  • Example 4 the subject matter of any one of Examples 1 to 3 may optionally include recording transactions associated with only one software in any one block of the blockchain.
  • Example 5 the subject matter of any one of Examples 1 to 4 may optionally include: broadcasting data about the transaction to a network; wherein the data comprises an address of a smart contract of a plurality of smart contracts stored in the blockchain, the smart contract corresponding to a type of the transaction.
  • Example 6 the subject matter of Example 5 may optionally include: retrieving the corresponding smart contract based on the address; and executing the corresponding smart contract; wherein the smart contract comprises a set of instructions which when executed, performs the transaction and computes the reputation score when a set of predefined rules are satisfied.
  • Example 7 the subject matter of any one of Examples 5 to 6 may optionally include that the data further comprises an address of the software.
  • Example 8 the subject matter of any one of Examples 1 to 7 may optionally include that a further block of the blockchain stores records of transactions associated with another software.
  • Example 9 the subject matter of any one of Examples 1 to 8 may optionally include that the software is a security software for protecting an electronic device.
  • Example 10 the subject matter of any one of Examples 1 to 9 may optionally include that the transaction is a review of the software, wherein the transaction increases or decreases the reputation score of the software depending on an outcome of the review.
  • Example 11 the subject matter of any one of Examples 1 to 10 may optionally include that the transaction is a purchase of the software, wherein the transaction increases the reputation score of the software.
  • Example 12 is a distribution system including: a memory; and at least one processor communicatively coupled to the memory.
  • the at least one processor may be configured to: generate a blockchain that includes: a plurality of blocks, wherein each block of the plurality of blocks stores a record of a transaction associated with software; and a plurality of smart contracts, each smart contract corresponding to a type of transaction, wherein at least one smart contract of the plurality of smart contracts is configured to compute a reputation score of any software; wherein each block is linked to a preceding block that stores a record of a latest earlier transaction associated with the same software as the transaction of its stored record; and wherein each block stores the reputation score of the software.
  • Example 13 the subject matter of Example 12 may optionally include that each record of a transaction comprises an address of the corresponding smart contract.
  • Example 14 the subject matter of any one of Examples 12 to 13 may optionally include that the at least one smart contract computes the reputation score stored in each block based on the transaction recorded in the block and further based on a previous reputation score stored in the linked preceding block.
  • each block of the blockchain stores a plurality of records of transactions associated with only one software.
  • each smart contract comprises a set of instructions which when executed, performs the corresponding transaction and computes the reputation score when a set of predefined rules are satisfied.
  • Example 17 the subject matter of any one of Examples 12 to 16 may optionally include that the record of the transaction comprises an address of the software.
  • Example 18 is a distribution system including: a plurality of nodes, wherein each node is configured to selectively initiate transactions; wherein at least a subset of the plurality of nodes is configured to implement a plurality of smart contracts, each smart contract associated with a type of transactions; wherein for each transaction initiated by one of the plurality of nodes, the transaction associated with software: another node of the plurality of nodes is configured to record the transaction, in a new block of a blockchain, wherein the new block is linked to a preceding block that records a latest earlier transaction associated with the software; and wherein at least one smart contract of the plurality of smart contracts is configured to compute a reputation score of the software based on the transaction and a previous reputation score stored in the linked preceding block.
  • Example 19 the subject matter of Example 18 may optionally include that the plurality of nodes comprises: a plurality of supplier nodes that provides software; and a plurality of buyer nodes, each buyer node configured to dispatch software to a respective set of electronic devices.
  • Example 20 the subject matter of Example 19 may optionally include that the plurality of buyer nodes is configured to verify the transaction before one buyer node of the plurality of buyer nodes records the transaction in the new block.
  • the plurality of buyer nodes is configured to verify the transaction before one buyer node of the plurality of buyer nodes records the transaction in the new block.
  • Combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C.
  • combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Divers modes de réalisation de l'invention concernent un procédé de distribution de logiciel à travers un réseau. Le procédé consiste à : enregistrer une transaction associée au logiciel, dans un nouveau bloc d'une chaîne de blocs ; le nouveau bloc étant lié à un bloc précédent qui enregistre une dernière transaction antérieure associée au logiciel ; calculer un score de réputation du logiciel sur la base de la transaction et d'un score de réputation précédent stocké dans le bloc précédent lié ; et stocker le score de réputation calculé dans le nouveau bloc.
PCT/SG2019/050159 2018-03-29 2019-03-22 Procédés de distribution de logiciel à travers un réseau et systèmes de distribution WO2019190394A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
SG11202009660SA SG11202009660SA (en) 2018-03-29 2019-03-22 Methods of distributing software across a network and distribution systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10201802656T 2018-03-29
SG10201802656T 2018-03-29

Publications (1)

Publication Number Publication Date
WO2019190394A1 true WO2019190394A1 (fr) 2019-10-03

Family

ID=68062642

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2019/050159 WO2019190394A1 (fr) 2018-03-29 2019-03-22 Procédés de distribution de logiciel à travers un réseau et systèmes de distribution

Country Status (2)

Country Link
SG (1) SG11202009660SA (fr)
WO (1) WO2019190394A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111310239A (zh) * 2020-03-23 2020-06-19 杭州溪塔科技有限公司 一种数字信息批量分发方法、装置及电子设备
CN111583039A (zh) * 2020-05-09 2020-08-25 江苏大学 无管理者区块链交易的安全交互方法、激励方法及交易系统
CN111639308A (zh) * 2020-04-24 2020-09-08 杭州溪塔科技有限公司 一种基于区块链的软件序列号分发验证方法和装置
CN112702390A (zh) * 2020-12-07 2021-04-23 北京大学 基于区块链的智能合约资源的组网方法和装置
CN113691632A (zh) * 2021-08-27 2021-11-23 广东卓启云链科技有限公司 一种区块链计算资源的动态调度方法及系统
US20220052909A1 (en) * 2020-08-17 2022-02-17 Nokia Solutions And Networks Oy Blockchain-based network device management methods and devices
CN116017438A (zh) * 2023-02-14 2023-04-25 广州爱浦路网络技术有限公司 确保pin安全的方法、装置、电子设备和存储介质
US12052133B2 (en) * 2020-08-17 2024-07-30 Nokia Solutions And Networks Oy Blockchain-based network device management methods and devices

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017145009A1 (fr) * 2016-02-23 2017-08-31 nChain Holdings Limited Procédé et système de sécurisation de logiciel informatique au moyen d'une table de hachage distribuée et d'une chaîne de blocs
US20180176229A1 (en) * 2016-12-19 2018-06-21 International Business Machines Corporation Decentralized automated software updates via blockchain
CN108304696A (zh) * 2018-03-12 2018-07-20 黄君 基于区块链的软件保护方法及软件保护系统
US20180293363A1 (en) * 2017-04-07 2018-10-11 Cisco Technology, Inc. Blockchain based software licensing enforcement
US20190004789A1 (en) * 2017-06-30 2019-01-03 Oracle International Corporation System and method for managing a public software component ecosystem using a distributed ledger

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017145009A1 (fr) * 2016-02-23 2017-08-31 nChain Holdings Limited Procédé et système de sécurisation de logiciel informatique au moyen d'une table de hachage distribuée et d'une chaîne de blocs
US20180176229A1 (en) * 2016-12-19 2018-06-21 International Business Machines Corporation Decentralized automated software updates via blockchain
US20180293363A1 (en) * 2017-04-07 2018-10-11 Cisco Technology, Inc. Blockchain based software licensing enforcement
US20190004789A1 (en) * 2017-06-30 2019-01-03 Oracle International Corporation System and method for managing a public software component ecosystem using a distributed ledger
CN108304696A (zh) * 2018-03-12 2018-07-20 黄君 基于区块链的软件保护方法及软件保护系统

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111310239A (zh) * 2020-03-23 2020-06-19 杭州溪塔科技有限公司 一种数字信息批量分发方法、装置及电子设备
CN111639308A (zh) * 2020-04-24 2020-09-08 杭州溪塔科技有限公司 一种基于区块链的软件序列号分发验证方法和装置
CN111583039A (zh) * 2020-05-09 2020-08-25 江苏大学 无管理者区块链交易的安全交互方法、激励方法及交易系统
US20220052909A1 (en) * 2020-08-17 2022-02-17 Nokia Solutions And Networks Oy Blockchain-based network device management methods and devices
CN114157429A (zh) * 2020-08-17 2022-03-08 诺基亚通信公司 基于区块链的网络设备管理方法和设备
US12052133B2 (en) * 2020-08-17 2024-07-30 Nokia Solutions And Networks Oy Blockchain-based network device management methods and devices
CN112702390A (zh) * 2020-12-07 2021-04-23 北京大学 基于区块链的智能合约资源的组网方法和装置
CN113691632A (zh) * 2021-08-27 2021-11-23 广东卓启云链科技有限公司 一种区块链计算资源的动态调度方法及系统
CN113691632B (zh) * 2021-08-27 2023-06-13 广东卓启云链科技有限公司 一种区块链计算资源的动态调度方法及系统
CN116017438A (zh) * 2023-02-14 2023-04-25 广州爱浦路网络技术有限公司 确保pin安全的方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
SG11202009660SA (en) 2020-10-29

Similar Documents

Publication Publication Date Title
WO2019190394A1 (fr) Procédés de distribution de logiciel à travers un réseau et systèmes de distribution
JP7461417B2 (ja) セキュアなオフチェーンのブロックチェーントランザクション
CN109981679B (zh) 在区块链网络中执行事务的方法和装置
JP7411011B2 (ja) セキュアな投票及び配布に利用されるブロックチェーンが実装された計数システム及び方法
CN109064334B (zh) 一种智能合约记账方法、计算机装置及可读存储介质
CN108462724B (zh) 数据共享方法、装置、系统、成员节点和可读存储介质
CN108492180B (zh) 资产管理方法及装置、电子设备
US20200145373A1 (en) System for blockchain based domain name and ip number register
CN111476667B (zh) 基于区块链的原创作品交易方法及装置和电子设备
TWI614713B (zh) 基於區塊鏈的智能合約版本控管系統及其方法
WO2015116998A2 (fr) Système de transfert électronique et d'application d'obligations
JP2006190254A (ja) 従量制コンピュータおよび動的な差別的価格決定に関する方法
CN109978477B (zh) 基于区块链的智能合约版本控管系统及其方法
CN111383114A (zh) 基于区块链的资产信息管理方法和装置
CN110597916B (zh) 基于区块链的数据处理方法、装置、存储介质及终端
US20200402026A1 (en) Blockchain management system, blockchain management apparatus, information providing apparatus, and blockchain management method
CN111402033A (zh) 基于区块链的资产信息管理方法和装置
CN111340628A (zh) 基于区块链的资产信息管理方法和装置
JP2005243036A (ja) サービス利用者による不払いに曝されることを管理する、サービスプロバイダの方法およびシステム
JP2022525551A (ja) データレコードのコピーの分散型台帳システムへの誤伝送の防止
US20230042916A1 (en) System and method for secure peer-to-peer transmission of content in distributed ledger neworks
Leiba et al. IoTPatchPool: Incentivized delivery network of IoT software updates based on proofs-of-distribution
CN113034137A (zh) 基于区块链的数据处理方法、装置及相关设备
Kirkman et al. Using smart contracts and blockchains to support consumer trust across distributed clouds
CN112400298B (zh) 验证交易系统和方法用于加至电子区块链

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19776405

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19776405

Country of ref document: EP

Kind code of ref document: A1