Secure communication using blockchain technology

Techniques for secure communication is provided. The techniques include requesting first smart contract execution by one or more nodes of the communication system to determine permissions for communication; performing communication based on the requested permissions; and requesting second smart contract execution by one or more nodes of the communication system to verify information associated with the communication.

BACKGROUND

Communication security between electronic devices is a constant design consideration. Improvements to security are constantly being made.

DETAILED DESCRIPTION

Techniques for secure communication are provided. The techniques include requesting first smart contract execution by one or more nodes of the communication system to determine permissions for communication; performing communication based on the requested permissions; and requesting second smart contract execution by one or more nodes of the communication system to verify information associated with the communication.

FIG.1is a block diagram of an example device100in which one or more features of the disclosure can be implemented. The device100can include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. The device100includes a processor102, a memory104, a storage106, one or more input devices108, and one or more output devices110. The device100can also optionally include an input driver112and an output driver114. It is understood that the device100can include additional components not shown inFIG.1.

In various alternatives, the processor102includes a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core can be a CPU or a GPU. In various alternatives, the memory104is located on the same die as the processor102, or is located separately from the processor102. The memory104includes a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache.

The input driver112communicates with the processor102and the input devices108, and permits the processor102to receive input from the input devices108. The output driver114communicates with the processor102and the output devices110, and permits the processor102to send output to the output devices110. It is noted that the input driver112and the output driver114are optional components, and that the device100will operate in the same manner if the input driver112and the output driver114are not present.

FIG.2is a block diagram of a blockchain based communication system200, according to an example. The communication system200includes one or more verifier nodes202, one or more non-verifier nodes204, and one or more non-node users206, all connected by a network208. Each of the nodes, which include the verifier nodes202and the non-verifier nodes204, are capable of executing smart contracts212of a blockchain210.

The blockchain210is blockchain data and code (“smart contracts”) stored in a distributed manner. More specifically, the blockchain210is data stored in any technically feasible manner, such as in a distributed manner across different nodes. In some examples, multiple copies of one or more different portions of the blockchain210are stored by one or more of the nodes.

The blockchain210includes one or more blockchain blocks. Each block includes one or both of blockchain data and smart contracts. Blockchain data is data of a type that is specified by the entity that initializes the blockchain or an entity that writes to the blockchain. An entity that initializes the blockchain is, in some implementations, a user performing such initialization through specific software. A smart contract212is executable code whose instructions are included within the blockchain210itself. In an example, the nodes execute a blockchain virtual machine. The smart contracts are encoded with instructions of the instruction set architecture of the blockchain virtual machine. Any node of the communication system200is capable of executing some or all of any smart contract. A node is a “user” that has one or more processors, such as the processor102ofFIG.1, capable of executing smart contracts212. A user is a node (i.e., a verifier node202or a non-verifier node204) or a non-node user206. A user has a unique identifier, which, in some implementations, is a blockchain wallet. The unique identifier is, includes, or is associated with a unique communication security identifier. In some implementations, the unique communication security identifier is a public key/private key cryptographic pair. This pair allows for secure communications between users of the communication system200as well as unique identification of the user. In an example, a first user encrypts communications to be sent to one or more other users with the private key of the first user. Other users attempt decryption of such communications using the public key for the first user. If the decryption is successful (e.g., successfully results in recovery of a known value), then the other users are able to verify that the message originated with the user associated with the public key, i.e., the first user. The public/private key is used for both communications security and identity verification, since only communications encrypted with a particular private key can be decrypted with the corresponding public key.

As stated above, the blockchain210includes one or more blocks. Each block stores at least a portion of the blockchain data and/or at least a portion of a smart contract212. Further, the blockchain210is a sequence (or “chain”) of these blocks, with each block including metadata that is mathematically linked to at least one preceding block. In an example, each block includes a cryptographic hash of the preceding block. This metadata provides additional security for the contents of the blockchain, since modification of one portion of the blockchain would require modification of all other blocks of the blockchain, which is computationally expensive and also means that block content integrity is verifiable.

As stated above, any node, such as a verifier node202or a non-verifier node204, is able to execute one or more smart contracts212. In addition to being able to execute one or more smart contracts212, the verifier node202is able to add additional verifier nodes202, non-verifier nodes204, or non-node users206to the communication system200, through a proof of authority scheme, as illustrated inFIG.3. The proof of authority scheme is a scheme to add an identification holder (i.e., a user) to the system200based on one or more items of data describing one or more aspects of identity of the identification holder. In some examples, an “identification holder” is an entity that has a unique identifier, such as a blockchain wallet. In the example in which blockchain wallets are or are identified by public and private keys, an identification holder has a unique public and private key. The identification holder or an entity acting on behalf of the identification holder (e.g., a human operator) provides information identifying the identification holder to one or more verifier nodes202and the one or more verifier nodes202determines whether the identification holder should be added to the system.

In some examples, the information identifying the identification holder includes the unique identifier (e.g., blockchain wallet). In some examples, the information identifying the identification holder additionally or alternatively includes other information uniquely identifying the identification holder. In some examples, this other information includes network address (e.g., internet protocol address), physical network address (e.g., media access control (“MAC”) address), geographic information, an identifier of a device that is uniquely associated with the unique identifier (e.g., a bar code number appearing on the physical device itself, such as a device serial number, a device model number, or other type of device-identifying number), or some other identifying feature. In response to receiving the information identifying the identification holder, the one or more verifier nodes202verifies whether that identification holder is permitted to be added to the system200. In the event that the one or more verifier nodes202verifies that a particular identification holder is permitted, the one or more verifier nodes202permits the identification holder to join the system. In the event that the one or more verifier nodes202does not verify that a particular identification holder is permitted, the one or more verifier nodes202does not permit the identification holder to join the system. The decision of whether to allow the identification holder to join the system is made by consensus, meaning that at least a certain proportion of the verifier nodes202(e.g., a half or two thirds) must agree that a particular identification holder is permitted to join the system200. Joining the system means that the user is permitted to communicate with other users of the system.

In some examples, any particular verifier node202makes a decision regarding whether a particular identification holder is permitted to join the system200in any technically feasible manner. In one example, each verifier node202interfaces with a trusted network administrator software application which allows an administrator to add identification holders (specified by their identification information) to the system200. The verifier nodes202check that a particular identification holder is included in a list of authorized identification holder and, if so, adds that identification holder to the network. In some implementations, the trusted network administrator software application allows for a selection of which category (e.g., verifier node202or non-verifier node204) a particular identification holder is to be placed into. In another example of how to add users to the system200, the verifier nodes202make an algorithmic determination of whether to add a specific identification holder to the system200. In various examples, the algorithmic determination considers any one or more aspects of the identity of the identification holder, processing those one or more aspects as specified by software (such as a smart contract), and determines whether to add the identification holder to the system based on the results of that processing. In an example implementation, a human authenticator interfaces with a user interface of a trusted software application and adds one or more blockchain wallets (which, in this example, are the identification information for associated users) to the system as users but not as verifiers. As a result of this action, the verifier nodes202determine that those blockchain wallets are associated with authorized users and permit those wallets to be added as users.

In some implementations, the determination of whether a particular identification holder has permission to join the system200includes a determination of whether a particular identification holder should be added as a verifier node202or a user that is not a verifier (e.g., a non-verifier node204or non-node user206). As described elsewhere herein, verifier nodes202have the capability to add additional users to the system, while non-verifier users (e.g., non-verifier nodes204or non-node users206) do not have that capability. Similar to the above, in some implementations, a user specifies through a trusted software application whether any particular user is to be added to the system200as a verifier.

FIG.4is a block diagram illustrating operations for interfacing with the blockchain210, according to an example. Regarding interfacing with the blockchain, any user404(that is, any non-node user206, any non-verifier node204, or any verifier node202that has been be authorized onto the system200) is able to request a particular smart contract be executed by a node402(that is, a non-verifier node204or a verifier node202). In response, any of the nodes402in the system200executes that smart contract and provides results back to the requestor. Execution of a smart contract sometimes results in additions to the blockchain210. Additions to the blockchain210are performed once a consensus is reached. In other words, once a threshold number of nodes402agree that a particular edit is to be made to the blockchain210, then all nodes402of the system200agree that that edit is to be made to the blockchain210. Execution of a smart contract to provide results to a user404requesting such execution does not need to be done by a sufficient number of nodes402to reach consensus, except if such execution results in modification to the blockchain210.

The system200allows for communications between users in a secure manner. Specifically, the smart contracts212executed by the nodes implement a secure communication mechanism.FIGS.5A and5Billustrate operations of this secure communication mechanism.

FIG.5Aillustrates a distributed publication/subscription network502. In some implementations, the distributed publication/subscription network502is a decentralized network. The distributed publication subscription network502includes one or more topics504, each having one or more items of published data506. A topic is a category that a publisher can publish to. An item data is a piece of data indicated as being published to a topic. Subscribers to a topic are able to read all data published to that topic. Published data can be any data defined by a system. In an example, a set of smart lightbulbs is permitted to publish lightbulb status (e.g., on, off, or intensity) to a “lightbulb” topic. The distributed publication subscription network502is “distributed” in that the published data506is permitted to be stored on any storage or memory (e.g., storage106or memory104ofFIG.1) associated with any user404of the system200, as shown. The users404request data and provide such data in response.

The communication of the topics504and published data506of the distributed publication/subscription network502does not occur directly via the blockchain-communication. However, the smart contracts212of the blockchain210are configured to manage permissions related to the distributed publication/subscription network502. More specifically, users404request execution of the smart contracts212to obtain information indicating which topics504are viewable by a particular user404, as well as to determine which users404have permission to publish to which topics504. It should be understood that a user404requesting execution of a smart contract212means that the user404either executes the smart contract212if able (i.e., if the user404is a node) or transmits a request to one or more other users404in the system200to execute the smart contract. Those one or more users, themselves, either execute the smart contract, or transmit the request to different users404. This process proceeds until the smart contract212is executed. The result of the smart contract execution includes indications of which topics504the user is able to view as well as which topics the user is able to publish to. In some examples, the user404is able to make finer granularity requests, such as asking only which topics504the user404can view or which topics the user can publish to.

FIG.5Billustrates an example set of operations for communicating data between users404. In the example, a first user404arequests, from one or more nodes402, an indication of which topics504the first user404ais permitted to view (552). In other words, the first user404asubmits a subscription permissions request (552) to one or more nodes402. In response, one or more nodes402executes an appropriate smart contract212(554) and provides the results (the subscription permissions) to the first user404a(556). As described elsewhere herein, the instructions of the smart contract212are specified in the blockchain210itself. At step558, the first user404athen requests from a second user404bthe information belonging to a particular topic504returned from the one or more nodes402at step556. At step560, the second user404brequests the one or more nodes402to inform the second user404bregarding whether the first user404ais permitted to view the topic requested by that user404. In other words, the second user404bsubmits a subscription permissions request (560) to one or more nodes402regarding the permissions of the first user404a. In response, at step562, the one or more nodes402executes a smart contract562and responds to the second user404b, at step564, with the requested permissions. In the example, these permissions indicate that the first user404is permitted to view the requested topic. Thus, at step566, the second user404bprovides the information from the requested topic to the first user404a.

It should be understood that the specific transactions illustrated inFIG.5Brepresent an example set of transactions. In various implementations or modes of operation, a user404does not need to request permissions to view messages for a topic for each time that user404wants to view such messages. In some implementations, users404request discovery of topics, rather than permissions to view topics. The result of execution of a smart contract212to discover topics for a user404is a list of topics that the user404is permitted to view. In some implementations, the user404that is to respond to a request for topic information (558) does not check whether the requesting user404is permitted to access the requested topic (steps560-564), and assumes that if a user404knows about a topic, the user is permitted to access the requested topic.

It should be understood that, in some implementations, the request for topic information558and providing of the topic information566between users404are not, themselves, performed using the blockchain210(i.e., by executing smart contracts212encoded into the blockchain210) but instead occur directly. The protection that the blockchain210provides is that a user404that is not authorized to view a particular topic is not permitted to learn that that topic exists. Another protection offered by the blockchain210is that users404who would provide an unauthorized user with information for a particular topic learns that the requesting user is not authorized to receive such information, when the second user404brequests execution of the appropriate smart contract212(steps560-564). Although the communication between users404of topic information does not, itself, occur via the blockchain210smart contracts212, such communication is, in some implementations protected through other means such as encryption using the wallet information of the users404. An example means for ensuring data verification is described with respect toFIG.5C.

AlthoughFIG.5Billustrates verifying permission to request access to a particular topic504via a smart contract212, it should be understood that in other modes of operation, a similar technique is used to verify permission to publish to a particular topic. In an example, a first user404arequests and receives topic information from a second user404b. The topic information includes an indication of which user404originally published that information to that topic. The first, or requesting, user404arequests a node402to execute a smart contract212to determine whether the second, or publishing, user404bactually has permission to publish to that topic.

It should also be understood that the actors inFIG.5Brepresent entities from a distributed system. For example, it is possible that the first user404arequesting information for a particular topic540is not able to directly communicate with the second user404bthat actually has the information for that topic504. The communication between a user404requesting information and a user404who actually stores this information is able to go through other users404as intermediaries.

Similarly, it is possible for either the user404requesting topic information or a user404providing such information in response, or both, to not be in direct contact with any nodes402. In such a situation, requests to execute smart contracts212and responses would be communicated through intermediaries.

It should be understood that any smart contract execution212that results in a modification to the blockchain210is executed by a sufficient number of nodes402to make a consensus. Any result from smart contract execution may result in a modification to the blockchain210.

AlthoughFIG.5Bshows users404as requestors and providers of information and nodes402as the entity that executes smart contracts212, it should be understood that any of the users404that request or provide topic information could, themselves, be nodes402. Thus, a user404that is a node402that requests topic information could execute its own smart contract212to determine whether that user404has permissions to view the topic. For security, smart contracts212that mediate access to the distributed publication/subscription service add at least some information to the blockchain210, so that a consensus of nodes402needs to execute that smart contract212and achieve the same result. In an example, an indication of which user404asked for topic discovery, as well as which topics were provided, is written to the blockchain210so that the results of such smart contract212execution can be verified.

FIG.5Cillustrates a technique for verifying data received by a user404, according to an example. According to the technique, a user404has received data for a topic already and attempts to verify the integrity of the data received. The user404has also received a verification signature. In an example, the verification signature is a hash of the data received as the contents published to a requested topic (or is the result of some other function applied to the data received). At step580, the user404requests execution of a smart contract212to verify data integrity, providing both the data and the verification signature. The node402executes a smart contract582to verify the data. In an example, this execution involves performing a verification function (e.g., a hash) to obtain a verification signature for the data provided and comparing the generated verification signature with the one received at step580. In response to executing the smart contract212, the node402provides the data verification response584to the user404. If the generated verification signature matches the received verification signature, then the data is determined to be verified and if there is no match, then it is determined that the data is not verified.

As with the flow ofFIG.5B, in some examples, the user404is itself a node402. In addition, it is not necessary for a user404to be directly connected to a node402.

FIG.6is a flow diagram of a method600for communicating securely, according to an example. Although described with respect to the system ofFIGS.1-5C, any system configured to perform the steps of the method600in any technically feasible order falls within the scope of the present disclosure.

The method600begins at step602, where a user404requests execution of a smart contract212to determine permissions for communication. In general, these permissions include which users404are permitted to write or read which communications. In the example where communication occurs via a publication-subscription system, permissions include whether a user404is permitted to publish to a particular topic and/or whether a user404is permitted to read from a particular topic. As described elsewhere herein, the topics include individual communications to be read by users404. The execution occurs and the node that executes the smart contract212provides the results back to the user402.

At step604, the user404performs communication based on the requested permissions. In the situation where the user404is requesting permissions to read data (e.g., requesting discovery of topics—which topics the user404has permissions to read, or requesting whether data is readable in another manner), the user receives the read permission information in step602and performs the read in accordance with those permissions. In an example, the user404reads from a topic that the user is permitted to read from. In the situation where the user404is requesting permissions to write data, the user404writes data in the manner permitted as specified in the communication received in step602. In an example, the user404learns in step602that the user404is permitted to publish to a particular topic and therefore does so.

In some situations, multiple users404involved in a transaction as counter-parties (e.g., where a first user404aprovides requested data to a second user404bthat requested that data) each request permissions involved in that transaction. For example, a first user404awishes to read data from a particular topic. The first user404arequests permissions to read from that topic and, once permission is obtained, attempts to access data stored by another user404b. That second user404balso requests permissions regarding whether the first user404ais permitted to read from that topic. Similarly, in an example where data is written, a first user404arequests permissions to write to a particular topic and, a second user404bthat wishes to read that topic requests permission information indicating that the first user404ais permitted to write to that topic.

At step606, a user404requests performance of a verification operation to verify data involved in a communication. In an example, the user404receives data and a signature, and requests verification of the data and signature. A node402executes a smart contract212with the data and signature. The node402performs a signature operation on the data and compares a resulting signature with the received signature. If the signatures match, the node402informs the user404that the data is verified. If the signatures do not match, the node402informs the user04that the data is not verified.

In some implementations or situations, step606is optional. In such situations, a user404just requests permissions to access certain data, a node402executes one or more smart contracts212to determine whether the user402is permitted to perform the requested actions, the node402returns that permissions information to the user402, and the user402acts in accordance with those permissions.

An example of a blockchain system is now described. This example system is embodied as a fleet of autonomous vehicles. At least some of these autonomous vehicles are non-verifier nodes204. In some implementations, each autonomous vehicle is a non-verifier node204, while in other implementations, some but not all vehicles are non-verifier nodes204, with the other vehicles being non-node users206.

To set up the system, the vehicles are each provided with unique identifiers, such as blockchain wallets. An administrator such as the manufacturer or fleet controller (e.g., a company that owns or operates the fleet) uses a software interface to add each of the vehicles to the blockchain system. The administrator also uses the software interface to indicate publication/subscription permissions for each of the vehicles. In an example, the administrator indicates that the distributed publication/subscription network502includes one topic for each vehicle, that each vehicle is permitted to publish to the topic assigned to that vehicle but not to any other topic, and that any vehicle is permitted to subscribe to the topic for any other vehicle. The information regarding the topics that exist, the permissions for the topics, and which users are in the system is stored in any technically feasible manner, such as within the blockchain itself, external to the blockchain, or partially within the blockchain and partially external to the blockchain.

During operation, each vehicle publishes information regarding that vehicle to the corresponding topic. Some such information includes vehicle location information, speed, and other status information. In the event that a vehicle wishes to obtain information about other vehicles, the vehicle requests that a node402perform a smart contract to return subscription permission for that vehicle. Any node402, such as the vehicle itself and/or other vehicles, executes that smart contract and provides the subscription permission to the vehicle. In an example, this information indicates that the vehicle is permitted to subscribe to any other vehicle. The vehicle then requests, from a second vehicle (which can be a vehicle that is a node402or a vehicle that is not a node402), published data506for a third vehicle. The second vehicle requests a node402(which can be any other vehicle) to execute a smart contract to verify that the requesting vehicle has permission to view the published data506for the third vehicle. The node402executes the smart contract and provides the result, indicating that the first vehicle is permitted to view the published data506for the third vehicle to the second vehicle. The second vehicle then retrieves the published data. If the second vehicle stores all requested data, the second vehicle provides that data to the first vehicle. If the second vehicle does not store all requested data, then the second vehicle requests a different vehicle to provide the information requested. The network of vehicles routes such request traffic through different vehicles until the request is finally satisfied. The one or more vehicles that have the request data return that data to the original requestor through the network of vehicles. In some implementations, each vehicle checks (via a smart contract) whether the original requestor is permitted to view the requested data, while in other implementations, only one or a limited number of vehicles makes this check. At some point after receiving requested data, the first vehicle requests data verification for the obtained data (FIG.5C).

The term “user device” is sometimes used herein and refers to a device acting as or on behalf of a particular user identification. In an example, a particular user device is a device acting within the system200as an entity identified by a particular blockchain wallet.

It should be understood that although a distributed publication/subscription model has been described as a means for sharing data, the teachings of the present disclosure could be adapted for any data sharing system. In general, such a system would be a system in which users404are added to the system via verifier nodes. In addition, the users404request permissions to read from or write to other users404or to or from data entities (e.g., topics) that could be read from or written to by other users. In addition, the users404are able to perform verification of data received. Each of the above features are performed by smart contracts212executed by nodes402of the system as described elsewhere herein.

Any of the entities described, including users404and nodes402, are embodied as software executing on a processor, hardware circuitry for configured to perform the functionality described herein, or a combination thereof. In an example, the nodes402are computing devices such as the device100ofFIG.1, having sufficient executing power to execute smart contracts212. In some examples, some users404are assigned to devices that have relatively simpler processing abilities. Some examples include smart home devices such as smart lightbulbs.

The various functional units illustrated in the figures and/or described herein (including, but not limited to, the processor102, the input driver112, the input devices108, the output driver114, the output devices110, and the nodes402, as well as the devices associated with non-node users206) may be implemented as a general purpose computer, a processor, or a processor core, or as a program, software, or firmware, stored in a non-transitory computer readable medium or in another medium, executable by a general purpose computer, a processor, or a processor core. The methods provided can be implemented in a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. Such processors can be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediary data including netlists (such instructions capable of being stored on a computer readable media). The results of such processing can be maskworks that are then used in a semiconductor manufacturing process to manufacture a processor which implements features of the disclosure.