US20170132620A1

US20170132620A1 - Systems and methods for autonomous device transacting

Info

Publication number: US20170132620A1
Application number: US15/345,424
Authority: US
Inventors: Jeremie Miller; Thomas Muldowney; Allison Cliff-Jennings
Original assignee: Swfl Inc D/b/a "filament"
Current assignee: Swfl Inc D/b/a "filament"
Priority date: 2015-11-06
Filing date: 2016-11-07
Publication date: 2017-05-11
Also published as: US10269012B2; US20170132619A1; US20170134937A1; US20170132621A1

Abstract

A system and method for facilitating microtransaction involving an autonomous transacting device includes generating a plurality of key pairs and sharing a key of each of the plurality of key pairs with the transacting entity; establishing an escrow at the blockchain and providing the plurality of key pairs to the blockchain; exchanging one or more of the key pairs using a sidechain; requesting a release or a refund of funds from the escrow; and presenting one or more exchange key pairs to the blockchain thereby establishing a percent completion of the sidechain.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 62/252,306, filed 6 Nov. 2015, which is incorporated in its entirety by this reference.

TECHNICAL FIELD

The inventions of the present application relate generally to the electronic connectivity and communications fields, and more specifically to improved systems and methods for implementing secure and private communications between devices.

BACKGROUND

In many centralized systems, many devices across great and small distances can achieve heightened levels of connectivity and interaction without being physically connected to each other and thus, are able to connect and communicate with one another wirelessly. These centralized systems for connecting these devices, however, are accompanied with several disadvantages that limit connectivity in remote locations, limit the autonomy of the devices operating in the centralized systems, and therefore, do not allow for optimal connectivity, autonomous transacting, and communications between and through the devices.
Additionally, due to the inherent lure of abuse and exploitation by centralized systems, all of these economic elements, digital and physical, with existing systems or new products, must be fundamentally autonomous and distributed in nature in order to maximize their potential. It is only in autonomous and distributed environment that markets can naturally emerge, balanced and maximizing benefit for all those involved.
The commonly referred to proposal to evolve the Internet to optimize for the “Internet of Things” has become synonymous with connected thermostats, pet collars, and toothbrushes. While the ability to build connectivity between devices like these is novel, there is a possibility that it may not realize the full potential of digitally connecting the physical world of things together. When a device can only connect with similarly-manufactured devices, and each of them can only connect with their manufacturer-approved cloud service, and thus, the vast majority of value that the device could have provided over its lifetime is severely hindered since it is strictly tied to a cloud-based interaction platform.
These new economic actors—e.g., the devices themselves—must be principally independent actors from centralized authority (e.g., manufacturers and connectivity servers) to unlock the vast majority of value associated therewith. Including—and especially—from the manufacturers of the devices themselves. It can be a very risky proposition to continue to give central authority, whether a nation state or a corporation, the reach and control capable of this new type of connected device. These autonomous and fully interconnected devices should retain full control and complete privacy at the device providing the coupling and creating the economic value.
But in order to realize such prospective technical environments where devices are independent actors; the technical functions involved in connectivity including discovery, interacting, and even transacting value between devices and with people, the entire protocol stack, systems, and methods governing these technical functions must be re-evaluated from the ground up. Thus, there is a need in the device connectivity and communication field to create new and useful systems and methods for implementing an environment for interactivity of autonomous devices without or independent of a central authority for governing interaction there between and consequently, enhancing the levels and quality of connectivity achievable with such networks and devices.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic representation of a system of a preferred embodiment of the present application;

FIG. 2 is a schematic representation of a component of system of a preferred embodiment of the present application;

FIG. 3 is an example process flow of a method of a preferred embodiment of the present application;

FIG. 4 is an example process flow of a method of a preferred embodiment of the present application;

FIG. 5 is an example process flow of a method of a preferred embodiment of the present application; and

FIG. 6 is an example process flow of a method of a preferred embodiment of the present application.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventions are not intended to limit the inventions to these preferred embodiments, but rather to enable any person skilled in the art to make and use these inventions.
DIST Protocols
In the present application, a set of protocols called Distributed Sentient Transactions (DIST), are implemented in the systems and methods described herein to provide a minimum set of requirements necessary to realize autonomous, decentralized devices.
In addition to the capabilities described of DIST and other novel protocols described herein, there are two fundamental requirements that are cornerstone for implementing a truly decentralized connected device environment. The baseline of these requirements revolve around security and privacy.
Security and privacy as two concepts that are sometimes used interchangeably, and while these concepts are related, they are not the same thing. For instance, in the realm of connectivity devices, security entails guaranteeing that the identity given to a device and the information transmitted by and between devices are what the device(s) states it is, without tampering, interference, and modification within transit, at the time of transmission, and/or at the time of receipt. Security sometimes also includes enciphering information so that the information is not readable by any other entity but the sender and receiver. Privacy, on the other hand, entails preventing others outside of the intended recipient to gain information related to or about the transaction or transmission between two devices or parties. Exploiting privacy could be as simple as eavesdropping, or as sophisticated as deep-packet inspection or timing attacks to determine additional information about the transaction or transmission. Thus, in order for devices to be truly autonomous, they must also have enough basic capabilities, at the device level, in both privacy and security to mitigate their vulnerabilities to security and privacy attacks that would otherwise render the devices disabled or ineffective for their intended purposes with the simplest effort (e.g., hacking).
Accordingly, DIST weaves security and privacy throughout the entire collection of protocols that make up the composition for DIST. While DIST protocols, in some embodiments, reduce efficiencies in some processes, the benefit obtained by enhanced security and privacy far outweigh the drawbacks in efficiencies. A fundamental assumption, in many embodiments described herein, is that any hardware the DIST stack of protocols runs on will have access to a hardware cryptographic co-processor to securely generate, manage, and store cryptographic keys—and when necessary, to accelerate computation-intensive encipher and decipher processing and to ensure tamper-resistant cryptographic code. Security must be trusted at the lowest level of the hardware of the device, or it is possible that all higher-level promises of security and privacy become indefensible.
Privacy must also be adhered to at the very lowest levels. Telehash protocol is a primary communication protocol in the DIST protocol stack, and along with a sub-protocol of Telehash called TMesh, Telehash protocols provide maximized communication privacy between any two endpoints. Therefore, under such protocols, encrypted communication is enforced, no metadata is ever leaked in communications and the operations of devices, and perfect forward secrecy is required.
The DIST protocol has been designed to run on a myriad of hardware platforms, from laptops and embedded computers all the way down to microcontroller-based systems such as wearables and wireless sensors. Thus, it shall be understood that DIST protocol can be run and/or applied to any type of device or element with sufficient computational and/or processing abilities to execute DIST protocols.
Blockname: Discovery Operation
Before any decentralized interaction between parties (e.g., devices) can happen, there must first be a means or method to ensure both the identity and the discoverability of a party. Identity of a party (e.g., an endpoint or node) focuses specifically on the verifiability that a party is who they say they are. Discovery focuses on the ability to find the network location of the party, given a known identifier of that party. Blockname primarily works to solve the discovery problem. But it also solves the identity verifiability problem in concert with Telehash—the secure communication protocol.
Blockname works on a novel premise, which is: leverage almost all of the existing Domain Name System (DNS) infrastructure that is currently used for Internet name resolution for domain names to Internet protocol (IP) addresses. Except, instead of relying on ICANN and its 13 root name server delegates to be the final source-of-truth, replace the 13 root name server delegates with the Bitcoin blockchain or other digital ledger technologies operating without a central administrator. Blockname uses the blockchain as a replacement start of authority (SOA) for normal DNS resolution, as well as to resolve alternative domains and custom top-level domains (TLDs). Blockname provides identity and discovery in a completely distributed manner—no registrars, root servers, or central authorities required further enabling the autonomy of the devices operating thereunder.
Blockname solves an underlying issue with existing name resolution and decentralization. DNS is not fundamentally decentralized in that at its root, there is a federation of 13 servers run by a loose conglomerate of organizations, under the singular ICANN DNS Root Server System Advisory Committee. However, this root zone is actually controlled by governmental entities. The government entities approve all changes to the root zone file as requested by 1.
In order to replace the role of ICANN in Blockname, there exists a notion of notaries. Notaries are a collection of individuals or organizations who vouch for the authenticity of names posted within a Blockname-based system. Notaries can use several means or methods to guarantee authenticity, from traditional ways such as confirming business licenses or personal identities to using already-established means to confirm identity, such as SSL certificate authorities (CAs). To prevent land-grabs and squatting, it is expected that the earliest notaries will leverage existing efforts from SSL certificate authorities in order to bootstrap Blockname. As the Blockname protocol matures and sees greater use, notaries will likely expand to use additional means to validate identities.
On the software side, a Blockname Resolver is provided which acts like a traditional DNS cache and recursive resolver. Blockname Resolver will resolve all queries via regular DNS first, and only when those queries fail will Blockname Resolver use any names that come from the blockchain-based hints. In this mode, Blockname always acts as a backup for any existing valid DNS names and only provides additional resolution for unregistered domains or unsupported Top-Level Domains (TLDs).
In the background, Blockname Resolver continuously indexes all newly broadcast blockchain transactions that have a valid hint—any OP_RETURN starting with a *—storing only the unique hints that have the largest values associated with them. The value of the hint's own output—what could be considered the “burned” value in Satoshis—must be larger for the new hint to replace a previous one of the same name. In this way, an old host name or IP address can be updated by simply creating a new blockchain transaction with a higher value assigned to it. Since a Satoshi is 1/100,000,000 of a Bitcoin, it is extremely low cost to update Blockname records.
The other software component, the Blockname Notary, verifies that the newly broadcast Blockname transactions are from an authorized agent of that name. It shall be noted that the Blockname Resolver will have a list of valid notaries in it—much like web browsers have a list of valid certificate authorities that are used to confirm authenticity for web site SSL certificates. Each Blockname Resolver instance can modify the list of valid notaries, but a default list is also provided.
While individual device names and subdomains can both use Blockname, they may not scale well depending on how the combination is utilized. Inefficiencies arise if it is attempted to store every device identity inside the blockchain directly. Larger namespaces, such as a custom TLDs, are formed by designated public Blockname resolvers advertising their existence to each other and building a distributed hash table (DHT) index for a TLD from those advertisements. The DHT index is then used to dynamically resolve any names with that TLD, allowing for ephemeral and alternative uses on a custom TLD that do not require a transaction per name or traditional DNS registration.
Telehash: Secure Communication Protocol
Once verifiable identity and lookup capabilities are available through Blockname, Telehash allows devices to establish secure communication directly with each other. Telehash, simply put, is a lightweight network protocol with strong encryption to enable communication across multiple transports and platforms. A lightweight interoperable protocol with strong encryption to enable mesh networking across multiple transports and platforms. Each endpoint generates its own unique public-key based address (e.g., a hashname) to send and receive small encrypted packets of JSON (with optional binary payloads) to other trusted endpoints. An endpoint may also provide routing assistance to others for bridging across different transports and to help negotiate direct peer-to-peer links.
Encryption is end-to-end, and is required one hundred percent (100%) of the time. It is impossible to disable encryption in Telehash. There is strict privacy, where no content, metadata or identity is ever revealed to third-parties. Telehash runs well on embedded, mobile, and desktop computing classes of hardware. Several underlying transport protocols are supported, so Telehash can run cleanly on top of very common networking protocols currently in use today. Lastly, there are many native implementations of Telehash supporting a large number of programming languages.
Telehash could be considered a next generation iteration of the best parts of the XMPP protocol. XMPP is a protocol created by Jabber to facilitate instant messaging between entities in a federated manner. Federation is similar to decentralization, except that in XMPP's case, federation means that anyone could run their own instant messaging server, and servers could communicate with each other. Instant messaging clients would connect to servers to send messages to each other on their clients' behalf. This was a much better model than the silos of the day—most notably AOL Instant Messenger (AIM). At the height of XMPP's popularity, over 1 billion people used it daily to communicate. Both Google Chat and Facebook Messenger used it as their messaging protocol. However, federation led to consolidation over time. Early on, there were thousands of XMPP servers, and as time went on, the number of servers decreased to just a dozen or so.
Telehash takes the best parts of XMPP, and addresses the deficiencies found by having XMPP deployed at such a large scale. The most important changes Telehash brings are in the areas of protocol verbosity, privacy, and addressing the drawbacks of a federated model.
As computing has become increasingly powerful and efficient, protocol verbosity is not so much a problem as it used to be. The size of the protocol packets, the amount of processing required to encode and decode the packets, and the overall compute overhead required to run that protocol are all less of a problem for today's devices than they used to be. However, in this new era of connected devices (e.g., nodes)—many of which are extremely low power and compute (e.g., low computer processing capabilities) capability, a lightweight protocol is actually more important now than it used to be. Telehash can run on devices as small as ARM Cortex Mo+ class: a 32-bit microcontroller running at 48 MHz with 32 kB of SRAM. No floating point processor and no memory controller is necessary. Because of the proliferation of low-power connected devices, Telehash must be able to run across all devices natively in order to allow true end-to-end communication. It is important to note that, in device classes as small as these, it is often beneficial to leverage a hardware-based crypto-accelerator chip, not only to increase cryptography performance, but for secure key storage as well. A crypto-accelerator chip can be integrated or otherwise, included in a number of different manners of a circuit board. A significant purpose of the crypto-accelerator chip, as alluded to above, is to load off very computing intensive tasks of encryption/decryption and compression/decompression. In such cases, the acceleration is often achieved by doing particular arithmetic calculations in the hardware. Accordingly, by including a crypto-accelerator chip in addition to a microcontroller and/or cryptographic coprocessor on a device, significant computing efficiencies can be achieved without necessarily having to increase the size of a small device having the processors and chips thereon.
In terms of privacy, XMPP originally did not handle privacy considerations at all. Only at a later time was work done with integrating Off-The-Record2 (OTR) functionality into XMPP. OTR brought strong encryption, authentication, deniability, and perfect forward secrecy to XMPP. Telehash handles these capabilities natively within its protocol, without the need to have OTR functionality built on top of it. By performing these OTR-type functionalities natively in Telehash provides a significant benefit of computing efficiencies by a computer processor since there is only one protocol to be process for a secure and private communication rather than using two disparate protocols in combination.
Lastly, a federated model may be insufficient, as it has been seen with XMPP. True end-to-end networking is necessary to avoid the consolidation of federated systems as seen in the XMPP environment. The consolidation of the federated systems in the XMPP environment raises the same and/or similar issues apparent in systems having a central authority. Specifically, systems having central authorities governing, managing, or otherwise interacting with multiple devices may be compromised and therefore, affecting multiple and if not all devices in a network. This configuration should be avoided to mitigate the possibility of compromise.
Before getting into the underlying process of Telehash, a relevant terms glossary is provided in the following paragraphs which may be helpful when discussing the operation of Telehash, to avoid confusion with other network protocols.
Packet refers or relates to an encapsulated format for JavaScript Object Notation (JSON) and binary data using an encoding format that allows combined JSON and binary data
Hashname refers or relates to an endpoint identifier, calculated from its public key Endpoint, which refers or relates to a participant in the Telehash network identified by a single hashname.
Message refers or relates to an asynchronous encrypted packet between two endpoints; Channel, which refers or relates to a virtual stream that allows two endpoints to exchange data reliably or unreliably.
Chunking refers or relates to a packet is chunked into smaller pieces for low-MTU or streaming transports.
Cloaking (or Masking) refers or relates to method used to hide Telehash traffic on the wire by randomizing all data sent in a network of endpoints.
Exchange refers or relates to the currently encrypted session state between two endpoints; Handshake, which refers or relates to a message type used to establish an encrypted session for channels; Link, which refers or relates to a connection between two endpoints either directly or via a router; Mesh, which refers or relates to a number of links with active encrypted sessions over any transport; participants in the mesh are called endpoints.
Router refers or relates to an endpoint that will facilitate link setup between two other endpoints; Transport—underlying network responsible for packet transfer.
The core entity in a Telehash network is the endpoint. Endpoints can be embedded devices, web browsers, mobile phone apps, or server daemons. They are simply the original sender, or the final recipient of any communication. Each endpoint has a globally unique 32-byte or similar-sized address, called a hashname. This hashname is how endpoints identify themselves and other endpoints.
Endpoints establish secure communication with other endpoints by first establishing a link—either directly or through a router. These links can use any available underlying network transports such as User Datagram Protocol (UDP), (Transmission Control Protocol) TCP, or even Bluetooth, short-range communications (e.g., radio), long-range sub-gigahertz radio, or a combination thereof. Once the link is established between the endpoints, a handshake message occurs to create a secure exchange on the link between the endpoints.
Once this secure link is established, one or more channels can be established on this link. A channel is analogous to a traditional network socket.
Once one or more channels are established securely, packets are passed between them directly. A collection of links to many endpoints is considered a mesh.
When an endpoint does not already know how to find another endpoint, it will request help from a router. The router will facilitate a link setup between the two endpoints. Once the link is set up, the router is no longer a part of the link, and the two endpoints can continue to establish links directly until one or the other is no longer at the same network address.
TMesh is a sub-protocol of the Telehash system, that extends Telehash functionality onto low power, low bandwidth radio links. TMesh is uniquely designed to be a secure physical (PHY) and Media Access Control (MAC) protocol for long-range, sub-Gigahertz mesh networking. It brings the same secure, private end-to-end networking to the smallest of embedded devices that Telehash offers in more powerful hardware, but works within the typically high latency and low bandwidth that these very long-range radio transceivers exhibit.
Accordingly, TMesh is the composite of three distinct layers, the physical radio medium encoding (PHY), the shared management of the spectrum (MAC), and the networking relationships between two or more endpoints (Mesh).
A community is any set of endpoints that are using a common medium definition and have enough trust to establish a Telehash link for sharing peers and acting as a router to facilitate larger scale meshing. Within any community, the endpoints that can directly communicate over a medium are called neighbors, and any neighbor that has a higher z-index is always considered the current leader that may have additional responsibilities.
To provide proper context additional definitions of terms used with TMesh are provided: medium refers and/or relates to a definition of the specific channels/settings the physical transceivers of endpoints use; community refers and/or relates to a network of endpoints using a common medium to create a large area mesh; neighbors refers and/or relates to nearby reachable endpoints in a same community; z-index refers and/or relates to a self-asserted resource level (e.g., available power capacity, available memory, and other capacities of the limited capabilities associated with an endpoint) from any endpoint; leader refers and/or relates to a highest z-index endpoint in any set of neighbors; knock refers and/or relates to a single transmission; window refers and/or relates to a variable period in which a knock is transmitted, 2̂16 to 2̂32 microseconds (<100 ms to >1 hr); and window sequence refers and/or relates to each window will change frequency/channels in a sequence.
Regarding context about PHY, a medium is a compact 5 byte definition of the exact PHY encoding details required for a radio to operate. The 5 bytes are always string encoded as 8 base32 characters for ease of use in JSON and configuration storage, an example medium is azdhpa5r which is 0x06, 0x46, 0x77, 0x83, 0xb1.
Byte 0 is the primary type that determines if the medium is for a public or private community and the overall category of PHY encoding technique to use. The first/high bit of byte 0 determines if the medium is for public communities (bit 0, values from 0-127) or private communities (bit 1, values from 128-255). The other bits in the type map directly to different PHY modes on transceivers or different hardware drivers entirely and are detailed in the PITY section.
Byte 1 is the maximum energy boost requirements for that medium both for transmission and reception. While an endpoint may determine that it can use less energy and optimize its usage, this byte value sets an upper bar so that a worst case can always be independently estimated. The energy byte is in two 4-bit parts, the first half for the additional TX energy, and the second half for the additional RX energy. While different hardware devices will vary on exact mappings of mA to the 1-16 range of values, effort will be made to define general buckets and greater definitions to encourage compatibility for efficiency estimation purposes.
Each PHY driver uses the remaining medium bytes 2, 3, and 4 to determine the frequency range, number of channels, spreading, bitrate, error correction usage, regulatory requirements, channel dwell time, and similar details on the transmission/reception. The channel frequency hopping and transmission window timing are derived dynamically and not included in the medium.
Transmitted payloads do not generally need whitening as encrypted packets are by nature DC-free. They also do not explicitly require CRC as all Telehash packets have authentication bytes included for integrity verification.
A single fixed 64 byte payload can be transmitted during each window in a sequence, this is called a knock. If the payload does not fill the full 64 byte frame the remaining bytes must contain additional data so as to not reveal the actual payload size.
WIP—determine a standard filler data format that will add additional dynamically sized error correction, explore taking advantage of the fact that the inner and outer bitstreams are encrypted and bias-free (Gaussian distribution divergence?).
Each transmission window can go either direction between endpoints, the actual direction is based on the parity of the current nonce and the binary ascending sort order of the hashnames of the endpoints. A parity of 0 (even) means the low endpoint transmits and high endpoint receives, whereas a parity of 1 (odd) means the low endpoint receives and high endpoint transmits.
Regarding MAC, there is no endpoint addressing or other metadata included in the transmitted bytes, including there being no framing outside of the encrypted ciphertext in a knock. The uniqueness of each knock's timing and PHY encoding is the only endpoint addressing mechanism.
Every window sequence is a unique individual encrypted session between the two endpoints in one community using a randomly rotating nonce and a shared secret key derived directly from the medium, community name, and hashnames. All payloads are additionally encrypted with the ChaCha20 cipher before transmission regardless of if they are already encrypted via Telehash.
Each endpoint should actively make use of multiple communities to another endpoint and regularly test more efficient mediums to optimize the overall energy usage. Every endpoint advertises their current local energy availability level as a z-index (single byte value) to facilitate community-wide optimization strategies.
There are two mechanisms used for enabling a larger scale mesh network with TMesh, communities (MAC layer) and routers (Telehash/app layer).
A community is defined by endpoints using a shared medium and the automatic sharing of other neighboring endpoints that it has active windows with in that medium. Each neighbor endpoint hashname is listed along with next nonce, last seen, z-index, and the signal strength. An endpoint may be part of more than one community but does not share neighbor endpoint information outside of each one.
The leader is always the neighbor with the highest z-index reachable directly, this is the endpoint advertising that it has the most resources available. The leader inherits the responsibility to monitor each neighbor's neighbors for other leaders and establish direct or bridged links with them.
Any endpoint attempting to connect to a non-local hashname will use their leader as the Telehash router and send it a peer request, whom will forward it to the next highest leader it is connected to until it reaches the highest in the community. That highest resourced leader is responsible for maintaining an index of the available endpoints in the community. Additional routing strategies should be employed by a mesh to optimize the most efficient routes and only rely on the leaders as a fallback or bootstrapping mechanism.
Any endpoint that can provide reliable bridged connectivity to another network (wifi, ethernet, etc) should advertise a higher z-index and may also forward any Telehash peer request to additional Telehash router(s) in the mesh via those networks.
While Telehash and TMesh are not expressly discussed with respect novel embodiments discussed below, it shall be understood that Telehash protocols and TMesh protocols may be, especially if using radio communication, the underlying communication security and privacy protocols, which are implemented to ensure that the embodiments and implementations thereof are not compromised.
OVERVIEW of IoT
Ushering in a new era revolving around IoT or generally, digital connectivity of things (DGoT) requires a robust system for connectivity and in the view of the present application, robust methods and systems for implementing secure and private connectivity with or involving those devices and other elements that enable an IoT or DGoT environment are disclosed. In this context, arises the several inventive concepts disclosed herein which provide novel and nonobvious techniques and systems which shore up the gaps in security and privacy that exist when IoT devices and the like connect and communicate with one another. By shoring up the security and privacy gaps in these devices, enhances the autonomy of the devices to operate without a central authority (e.g., a central server or the like) that may be used to manage the device's privacy and security considerations.
In a typical IoT environment, there may be data capturing devices and/or operational devices, such as sensors and/or actuators which gather information associated with a machine (e.g., a thing) and connect to other sensors and/or actuators to communicate the gathered information. In this basic example of an IoT environment, the transmissions of the sensors and/or actuators may be susceptible to attacks which aim to absorb observable information about the transmission and absorb the gathered information being transmitted and often, information about the devices, themselves. Thus, with the prevalence of meta data attacks and meta data surveillance to wrongfully obtain information from IoT connectivity devices, such as the sensor and/or actuator, raises an immediate concern particularly with communications between IoT devices that are performed over radio frequency. This is because with radio frequency communications there is not a network access point that you have to worry about gathering meta data from; rather, a real immediate concern is that anybody and/or any receiver in proximity to the radio range of the radio frequency communication can surveil the communication and record all of the radio frequency communication in the air. There is virtually no way to detect whether a receiver is surveilling and/or recording the radio communication; however, if an entity chooses to invest heavily in physical security it may be possible to mitigate the opportunities others have to monitor and capture radio frequency communication information between devices. This approach, however, may be extremely expensive and cost prohibitive.
Thus, in a system that includes thousands of devices communicating with each other over radio frequency, the issues involving wrongful surveillance and information capture is magnified even greater. This is problematic because any kind of information including data management patterns, device management patterns, sensor recording, sensor data patterns, type of sensors, when schedules run, actuation timing and schedules, and the like can become exposed from the meta data associated with radio frequency traffic. Simply put, the wrongful surveillance and/or capture of meta data from radio frequency communications allows the surveilling entity to identify communication packets which have the information of interest since the meta data in a radio frequency transmission usually or possibly describes the general contents of the communication packets. Once the general contents of the communication packets are known, an entity who is surveilling the radio transmissions can then allocate resources to hacking or wrongfully obtaining the specific contents of the communication packets. This situation can be substantially mitigated or otherwise, completely avoided by diminishing, disguising, obfuscating, or mitigating to a zero meta data state any useful meta data that can be obtained by mere surveillance in a radio transmission between two communicating parties. A zero meta data of a preferred embodiment is a state in which at least two endpoints in a mesh network or otherwise, which are establishing a link, linked, or communicating with each do not reveal any kind of meta data to a surveilling entity, such that zero meta data is exposed. A zero meta data state ensures that the patterns, schedules, and communication packets of the network of endpoints are securely and privately protected.
Accordingly, there are three main recordable and/or surveillable meta data attributes of a radio frequency communication between at least two communicating parties that the embodiments of the present application seek to protect using the systems, methods, and protocols described herein. A first attribute that the embodiments seek to protect include the channel (e.g., frequency) of communication of a transmission, a second attribute includes a signal strength (e.g., the loudness of the transmission or power) of a communication and/or a signal strength emanating from the parties or devices involved in the radio transmission, and the time of the radio transmission including a start time, duration of transmission (e.g., total time of transmission, end time of transmission, and even time between transmissions. Obviously, if any of these attributes of a radio communication become accessible to a wrongful observer, the content of the transmission including the data of the transmission can be recorded.
Thus, each of these four parameters including the three meta data attributes and data content of a radio transmission are protected using the embodiments of the present application. It shall be understood that, while the present application expressly protects these forms of meta data from surveillable or noticeable exposure, any and other forms of meta data associated with a radio transmission or other susceptible forms of communication can be protected, such as any other indirect transmission signals from components of the communicating devices when processing signals, such as an RF amplifier and also, meta data information from a tuner or detector.
While cryptography can be used to strongly secure contents or data contents of a communication packet, it is difficult to apply cryptography to protect meta data attributes of a radio transmission, such as timing, power, and frequency (e.g., channel) being used in the transmission. Thus, the systems and protocols associated with the system and methods of the present application can be used to protect each of the above-noted parameters.
As mentioned previously, in the system(s) described herein below, there is a fundamental requirement that each of the nodes (e.g., autonomous devices) is able to perform full cryptography protocols without any intervention or assistance of a central authority or central connectivity server. This fundamental functionality of the nodes lends to the autonomous nature of the devices required in an IoT or DCoT of the future.
The systems and methods required for achieving such device autonomy is described below, in part, as well as in the following application, which is incorporated by reference in its entirety:
Systems and Methods for Secure and Private Communications application Ser. No. ______
Blocklet Overview
Blocklet protocol is fundamentally based on cryptography and is organized or structured in such a manner in which any implementation of blocklet protocol can be self-verified using the protocols therein. The root of blocklet protocols include the data structures available under the JavaScript Object Signing Encryption (JOSE) stack of protocols. Specifically, the composition of blocklet protocols includes, mainly, a number of JWTs and JWKs, as defined by the JOSE specification.
Regarding a JWT, a JWT is a JavaScript Objection Notation (JSON) Web Token (JWT), which is a compact data structure of JOSE and a URL-safe means of representing claims or statements of information to be transferred between two parties. Essentially, JWT is a compact claims representation format intended for space constrained environments. A claim in a JWT is encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Accordingly, a claim is a piece of information asserted about a subject.
Additionally, the contents of a JOSE Header for a JWT describe the cryptographic operations applied to the JWT claims. If the JOSE Header is for a JWS, the JWT is represented as a JWS and the claims are digitally signed or MACed with the JWT claims being the JWS payload. IF the JOSE header is for a JWE, the JWT claims being the plaintext encrypted by the JWE. A JWT may be enclosed in another JWE or JWS structure to create a nested JWT, enabling nested signing and encryption to be performed.
A JSON Web Key (JWK) is a JSON data structure that represents a cryptographic key.
A JWS represents content or claims of a JWT that is secured with one or more digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Thus, JWS provides the capability for a receiving party of an encrypted message or the like to verify a creator of the message.
A JWE represents encrypted content of a JWT also using JSON-based data structures. Applying JWE to encrypt JSON content provides the capability to allow or the intended recipient to decrypt and read the content.
Accordingly, the blocklet protocol stack provides a standard access control mechanism for devices using data structures in the JOSE stack including JWTs and JWKs, which may be encrypted using at least one of JWS and JWE or the like. In addition to providing access control of a device between any two parties, there is another higher level activity is enabled by blocklet protocol, which is contractual enforcement between a device using blocklet protocols and another entity without intervention of an outside controlling server and/or central authority.
Generally, access control in accordance with blocklet protocols define parties, for example, other devices allowed to communicate with this device, and contractual enforcement defines under what conditions can those allowed to communicate with this device do so and providing a cryptographically secure method for doing so. The differences between these concepts are subtle but important distinctions, and blocklet protocols handle both of these concepts.
Traditionally, access control was typically handled by the concept of an Access Control List (ACL), as discussed above, which simply was a centrally-controlled list of other entities that were allowed, or blocked, from accessing the particular resource (e.g., device). However, since DIST aims to offer both access control and contractual enforcement in a single protocol (e.g., Blocklet), DIST does so in a more sophisticated and autonomous way than just using an ACL.
Significantly, Blocklet protocols add to the traditional access control approach using ACL in the way of defining price and receipts. Because DIST includes a first-class term for value transfer, access control can now include a price at which particular access to a device implementing blocklet protocol is available, and can control access of the device if the appropriate price is not paid. Price is then a validation term that must be validated in an interaction between the device and another party in order to grant access to one or more resources associated with the device.
There are several ways to define the conditions under which a device may be accessed. In some embodiments, a first type of condition under which a device can be accessed includes on a time-basis, where a third-party would gain access to a device over a certain time duration. A time-basis access, in some embodiments, could be granted at no cost or value exchange to select groups of external parties based on one or more predetermined factors. In a preferred embodiment, price is added to the access control terms, or otherwise, recognized under DIST protocols as one of the contractual terms. If price is added to the access control terms, then additional access control is possible, such as access by monthly payment for use of a device, a per-day contract, or an annual contract. In the time-basis mode, the set of functionality sold by the device is on a time-limited basis. The durations and price for the contract are flexible for a set of functionality. The time-basis mode is possible using only the blocklet protocol.
Additionally, and/or alternatively, a second type of condition under which a device implementing blocklet protocol could be accessed includes on a use-basis, where a customer would pay per use for a device resource. This could be a payment for a given sensor reading, or to actuate a machine that the device is operably connected to or operably in communication with. In the use-basis mode, there is a set of functionality that is sold per unit of functionality provided by the device. In such embodiments, the units of functionality and price for the contracts are flexible, for an unlimited time. The use-basis mode is possible using both the Blocklet and Penny Bank protocols, as described herein below.
Accordingly, in the context of DIST protocols involving the Blocklet protocol, a price-enabled access control list is referred to herein as a smart contract. Though this term is used in many different contexts within the cryptocurrency universe, the definition provided above is strongly tied to the terms' original definition, which is that of a self-executing, self-enforcing contract implemented in software. Accordingly, in some or many embodiments, the smart contract may also be a digital mirror of a physical or orally negotiated contract and thus, is basically a computer-readable and executable form of a real world contract.
In conventional service-based applications, permission to interact with a device is typically granted through reference to an access control list (ACL) such as a whitelist of privileged entities. Although more sophisticated policy frameworks exist, in general ACLs are relatively simplistic, allowing or disallowing interaction in an all-or-nothing way. In any case, both ACLs and policy frameworks are instantiated at the service or account level, and thus require communication with a cloud-based API or other remote centralized authority in order for the device to enforce access decisions.
By contrast, the blocklet protocol stack leverages several innovative solutions to enable smart contracts and autonomous device transacting without the need for a central authority or centrally controlled ACL. As mentioned above, this enabled smart contract functionality includes: self-executing, self-enforcing contracts that are implemented in software. These smart contracts make it possible to specify the particular conditions under which a device will interact with other entities, without reference to a cloud service or other central authority. Such conditions can include price or value to be exchanged, time period(s) during which access is allowed, a per-use charge for defined functionality, attribution for data provided, and other transaction or interaction (e.g., contractual) terms that are required in some manner to govern the overall interaction of the parties involved. These smart contracts or defined set of conditional parameters governing an interaction between entities are specified in a standardized JWT format.
System for Implementing Blocklet
With Blocklet, there are four primary components necessary: the digital smart contract, the physical hardware of the device, the contract issuance/renewal capability, and the blockchain that records the proof-of-payment receipt of the smart contract.
The smart contract itself represents a contractual agreement between the buyer, the seller, the product capabilities offered for sale, the contract term length, and any fees associated with the contract. What makes this contract different from a traditional legal contract is that it is implemented in software and generated by the same using data structures in the JOSE stack, the smart contract is self-executing and self-enforcing, and can be bought, sold, renewed, revoked, and transferred in a completely digital fashion. The actual terms within this smart contract can be nearly anything, and is usually specific to the product and/or service.
The smart contract's terms are specified in a standardized format called JSON Web Token (JWT), a subset of the JavaScript Object Signing and Encryption (JOSE) specification described at the following links, the subject matters of which are incorporated by reference in their entireties:
JSON Web Signature: https://datatracker.ietf.org/doc/rfc7515/
JSON Web Encryption: https://datatracker.ietf.org/doc/rfc7516/
JSON Web Key: https://datatracker.ietf.org/doc/rfc7517/
JSON Web Algorithm: https://datatracker.ietf.org/doc/rfc7518/
JSON Web Token: https://datatracker.ietf.org/doc/rfc7519/
This smart contract typically resides directly on the DIST-capable hardware device in a secure storage area.
The DIST-capable physical hardware is the actual electronic circuit board module that contains the DIST stack, and physically controls the capabilities and features of the product as well as handles the secure storage of the contract. It often includes wireless communication for a completely standalone decentralized connectivity solution for a product, and to receive smart contracts over the air wirelessly.
As shown in FIG. 1, a schematic representation 100 is illustrated of a system environment for implementing a transaction involving one or more devices implementing Blocklet protocols. Specifically, the system environment of FIG. 1 includes an autonomous transaction device 110, a transacting party 120, a network 130, a block chain ledger 140, and a provisioning device 150.
The autonomous transacting device 110, as shown in more detail in FIG. 2, of system 100 may be any type of device and/or software implemented on hardware of a device with capabilities of self-enforcing one or more conditions and/or terms of a digital smart contract 150 residing on a memory 112 of the autonomous transacting device 110. Accordingly, the autonomous transacting device 110 is a principally independent actor from a central authority including any central server authority and including manufacturers of the autonomous transacting device 110. That is, the autonomous transacting device 110 is able to manage all of its operations, transactions, access controls, transactions with other devices and entities, an operational control of the device without intervention of a central authority outside of the physical device. Thus, the autonomous transacting device retains full control and complete privacy at the autonomous transacting device, itself, when in use and in operation.
As shown in FIG. 2, the autonomous transacting device comprises one or more computer processors 111 (or a main processor 111), a memory 112, a communication interface 113. In one variation, each autonomous device includes a microcontroller 114 having a small computer on a single integrated circuit containing a processor core, memory, and programmable input/output peripherals. The microcontroller 114, in some embodiments, is used in lieu of the one or more computer processors 111 and in other embodiments, the microcontroller is used in conjunction with the one or more computer processors 111. Additionally, and/or alternatively, each autonomous device of the plurality of nodes 110 includes a cryptographic coprocessor 115 which is a hardware security module or component which provides high security and high-throughput cryptographic subsystems and a crypto-accelerator chip 116, which may be integrated with the cryptographic coprocessor 115. The autonomous transacting device may also include a modulator 117, an oscillator 118, a timer/clock 119, and a power supply 120.
The autonomous transacting device 110 of FIG. 2 may also include traditional elements of a device configured for radio communication at the communication interface 113. Thus, the communication interface 113 of node 110 of a preferred embodiment includes a radio frequency (RF) scanner 121, RF transmitter 122, RF receiver 123, RF tuner 124, an antenna 125, and a RF amplifier 126.
The memory 112 of the autonomous transacting device 110 in a preferred embodiment includes one or more computer-executable instructions and/or software applications with computer code for executing the functionality and protocols of DIST including blocklet and penny bank protocols and any other functionality or protocols associated therewith, which are described herein required for secure and private communications by and between each of the autonomous transacting device and another party.
The cryptographic coprocessor 115 of the autonomous device 110 is configured to implement various cryptographic processes including generating, managing, and storing cryptography keys and encrypting and decrypting cryptographically secured communications. Specifically, each autonomous device using the cryptographic coprocessor 115 is able to generate private/public cryptography key pairs that can be used to cryptographically secure communication links and sessions between the device 110 and another party.
The autonomous transacting device 110 may be any type of device, which may be coupled with one or more machines, instruments, components, and/or real world operational devices or elements to sense inputs and/or outputs thereof, to perform actuation operations of one or more components thereof, to perform transactions on behalf of the element or device to which the autonomous device is coupled, and the like. For example, in some embodiments, the autonomous device is a sensor integrated onto a circuit board having cryptographic chips thereon that is able to obtain readings and other information relating to or about one or more devices to which the sensor is operably coupled and/or obtain readings about the environment of the one or more devices. Additionally, and/or alternatively, the autonomous device 110 may be an actuator that performs and/or controls one or more actuation operations of a device to which the actuator is a component and/or is operably coupled to. In yet another example, the autonomous device may be a transaction device which brokers transactions on behalf of the device to which it is operably coupled and/or forms a component thereof. The transaction may include an exchange of value for a good, service, or other product offered to the autonomous device or the device to which the autonomous device is coupled. In such example, the autonomous device acting as a transaction device is able to negotiate with other devices and/or other autonomous devices to obtain resources for itself and the device to which it is coupled or provide resources from the device to which it is coupled for a negotiated value or the like from another device or party.
The communication network 130 of system 100 may be any type of communication network that is useable by the parties of a transaction involving the autonomous device no. The communication network 130 of the system 100 is preferably used only when the autonomous device no and an another entity involved in a transaction are not able to establish communication using a decentralized communication means or method that does not rely on a centrally controlled and/or managed communication scheme, such as the Internet. For instance, if the autonomous device 110 and a transacting party 120 cannot established a short-ranged radio frequency communication or similar means for completing a transaction, the parties can rely on the communication network 130, as a backup communication network from establishing a proper communication channel or the like for completing the transaction or implementing an interaction.
As mentioned above, the communication network 130 may be any type or kind of network that uses the Internet (e.g., GAN), WAN, LAN, or other centralized communication network architectures to facilitate communications between two or more parties including transmitting and receiving information there between.
The blockchain ledger 140 is a distributed database that maintains a continuously growing list of records called blocks secured from tampering and revision. Each block contains a timestamp and a link to a previous block. The block chain ledger 140 may be a private or a public ledger.
The configuration device 150 of a preferred embodiment is configured to be used as a trusted third party for provisioning the autonomous device no with a prime contract, one or more smart digital contracts, shared secrets used in cryptography and as an initialization and/or generally, a provisioning server for an autonomous device; however, it shall be noted that once in operation, an autonomous device operates independently of the configuration device 150 and do not rely on the configuration device 150 for access and/or operational control support or management. The stateless configuration server is preferably a management server which may be used in a device/node deployment process. For example, the configuration device 150 in a provisioning process is able to generate private/public cryptograph key pairs and provision the autonomous device no with a public key pair defining who and/or which devices/nodes the provisioned device can trust. The prime contract that is provisioned onto the autonomous device governs the contractual relation between the acquirer (e.g., buyer) of the autonomous device 110 and the provider (e.g., manufacturer). While the prime contract may be a smart digital contract, the prime contract governs all subsequent smart digital contracts provided by the autonomous device either between the acquirer and the provider and also, between the acquirer and a subsequent purchaser of one or more services and/or goods provided by the autonomous device.
The autonomous devices/nodes can be provisioned online or offline. In offline provisioning, it is possible to provision the devices at initialization or at a time of manufacturing. Thus, online configuration through a communication network is not necessarily required; however, in some embodiments, when renewing a digital smart contract or when it is required to provision the autonomous device remotely, the configuration device 150 may be a mobile terminal or remote terminal that can wirelessly communicate with the autonomous device over the Internet or the like to provide any provisioning downloads and the like.
It should be understood that in a transaction involving the autonomous transacting device 110, the establishment of a cryptographic communication and facilitating a transaction with another party can be purely performed offline and without an outside accessible network (e.g., LAN, WAN, GAN, etc.) or central authority (e.g., a central/management server). The rationale for configuring the autonomous transacting device 110 to perform cryptographic functions without an area network or central authority is to reduce, if not, eliminate any requirements that the autonomous transacting device 110 will require intervention or assistance from an outside central authority, which may be used to compromise the autonomous transacting device 110, thereby eliminating the need for a central authority or area network enhances the autonomous nature of the autonomous transacting device no.
As shown in FIG. 3, a process flow of a method 300 is provided for initializing an autonomous transacting device using blocklet protocols. At step 310, one or more conditions and/or contractual terms are identified and defined for a digital smart contract using one or more compact data structures. At step 320, a provisioning device (e.g., provisioning server) provisions the autonomous device with the digital smart contract. At step 330, the conditions and/or terms of the smart contract are provided to cryptographic-based ledger (e.g., blockchain).
At step 310, one or more digital smart contracts are identified and defined. Specifically, a manufacturer and/or a provider of a device having blocklet protocol modules or service using one or more blocklet protocols determines and/or generates the one or more terms for providing a performance of a service and/or provisioning of one or more goods in accordance with the digital smart contract to be imprinted on the device and/or incorporated into a service. In some embodiments, the terms of the digital smart contract are negotiated between the manufacturer and an entity that will offer the services and/or goods of autonomous transacting device.
Once the terms of the digital smart contract are identified, the one or more terms of the digital smart contract are used to define one or more JWTs (e.g., one or more contracts) and JWKs (e.g., one or more cryptographic keys).
Defining the one or more JWTs include one or more of the following steps, which can be done in any order where there are no dependencies between the inputs and outputs of the steps. However, if there are dependencies in the claims, then the order of defining or creating the one or more JWTs must be followed. First step in defining a JWT includes creating a JWT claims set containing the desired claims, as shown FIG. 3A. FIG. 3A illustrates a schematic representation of a JWT including a claim set. In this case, the performance steps and value identified and/or negotiated terms for the digital smart contract would be converted into one or more claim statements in the JWT(s).
The JWT illustrated in FIG. 3A includes one or more claim names including “iss”, “sub”, “aud”, “exp”, “nbf”, “iat”, and “jti” where “iss” identifies the issuer of the contract, “sub” identifies the subject of the contract, “aud” identifies the audience of the contract, “exp” identifies the expiration of the contract, “nbf” indicates a not before time, “iat” indicates issued at, and “jti” indicates the JWT identifier.
As a second step, let the message be the octets of the UTF-8 representation of the JWT claims set. Thirdly, define a JOSE Header containing the desired set of header parameters including the cryptographic operations to be performed against the message and any other information for processing the claims. Accordingly, the JOSE Header must conform to either the JWS or JWE specification. FIG. 3B illustrates a schematic representation of a JOSE Header. As a final step, the message (e.g., the payload including the claims) is digitally signed and then encrypted, in that order.
FIG. 3B includes contains a “cty” (i.e., content type) value, which must be defined as a JWT.
Defining one or more JWKs to be included in the one or more JWTs includes the following steps. FIG. 3C provides an example JWK in which the members of the JWK represent properties of the key. In such case, the JWK declares that the key is an Elliptic Curve key (kty), that is used with P-256 Elliptic Curve (cry), and its x and y coordinates are the base64url-encoded values shown. A key identifier (kid) is also provided for the key. Accordingly, the “kty” parameter identifies the cryptographic algorithm family used with the key, such as “EC” but could also be “RSA”, and is used to match a specific key. The “use” (e.g., public key use) parameter identifies the intended use of the public key. The “use” parameter is employed to indicate whether a public key is used for encrypting data or verifying the signature on data.
At step 320, the autonomous transacting device is provisioned with the digital smart contract. In some embodiments, the autonomous transacting device is provisioned with the digital smart contract at the manufacturer of the autonomous transaction device. Provisioning is typically performed in this manner when it would be difficult to otherwise provision the autonomous transacting device remotely due to connectivity concerns when the device is implemented in remote areas.
The contract issuance software for provisioning the autonomous transacting device usually resides on a provisioning device or server separate from the autonomous transacting device. This contract issuance software securely generates and renews contracts, and cryptographically signs them before making them available to the buyer of the autonomous transacting device. This system is typically integrated into the manufacturer's web site or mobile application, and may be made available to buyers by the manufacturer in a number of ways including via the manufacturer's web site. However, the contract generation of this software is part of the Blocklet protocol specification, and as such, any Blocklet contract issuance protocols will work to generate a new contract to be presented.
Additionally, and/or alternatively, the autonomous transacting device may be provisioned with the digital smart contract remotely using a mobile computing device or terminal or other computing device that is able to interact with the cryptographic circuit board of the autonomous transaction device to download the digital smart contract thereon and cryptographically store the digital smart contract. This method of provisioning the autonomous transacting device with the digital smart contract is preferred when the terms of the digital smart contract are negotiated between and a vendor or the like. Additionally, this method of provisioning the autonomous transaction device is preferred for autonomous devices which are currently in the field (e.g., external to the manufacturer) and a contractual renewal is required or a new digital smart contract is provided with new terms.
At step 330, the digital smart contract and associated terms are provided to a blockchain ledger. In particular, the digital smart contract is provided to the blockchain together with details for identifying the autonomous transacting device. By storing this information at the blockchain ledger, enables the transaction involving the autonomous transacting device to be verified without the use of online central authority, such as a payment system server or the like. Accordingly, in this manner, cryptocurrency may be used as a form of payment to a cryptocurrency address associated with the autonomous transaction device where the validity and verification of the cryptocurrency payment may be performed solely between the transacting parties.
Thus, the inclusion of a digital smart contract's cryptographic fingerprint and metadata to a blockchain gives a completely decentralized but verifiable assignment of contract ownership, assignment, and payment. The manufacturer or provider of the autonomous device can verify by whom a particular smart digital contract has been paid for by checking the transaction output of the particular contract receipt record within the blockchain. The buyer can verify that its smart digital contract is valid and current by checking the same record in the blockchain.
It shall be clarified that in order to truly realize a decentralized ecosystem, once an autonomous transacting device is provisioned once, it must always be possible to ensure that device's contract can be paid for and renewed through at least one decentralized method. The opcode logic of the transaction of a blockchain must make available the ability to continue to pay for a device's contract renewal through that blockchain itself. The manufacturer can also provide for centralized contract issuance and renewal using their own contract issuance software, but to ensure true decentralization, once a contract is issued once, the device must have the ability to be renewed by the cryptocurrency of the blockchain to which it is assigned. In the case of Bitcoin, this logic is added to the P2SH script of the transaction assigning the contract.
Primarily, this is so that if a device outlives the company who manufactured the device, the buyer of that device can continue to use—and pay for—that device for as long as the device is operational, and prevents planned obsolescence. Secondarily, ensuring that device contracts can be renewed digitally gives devices the ability to pay the contracts of other devices themselves. This feature maximizes the idea of device autonomy, which is a primary objective of the entire DIST protocol stack.
It should also be noted that more than one contract can be assigned to a particular autonomous transacting device. This allows the decoupling of the device from the number and type of buyers and sellers of the services that the particular device provides. For instance, there could exist one contract on a device that sells its temperature data for a given price. There could exist another contract on that same device that sells humidity data for another price. Each of those contracts can be open—meaning anyone can transact with them if the proper amount is paid. Or they can be closed, where transactions are only allowed to a given whitelist of buyers. And any number of customers can agree to any contract terms that they have access to. So the particular device may have 10 different temperature customers, and 25 different humidity customers, utilizing the same two contracts, and all sold by the same physical device.
Digital smart contracts can also be combined, where two sellers may decide to chain their contracts together. In this situation, all chained contractual terms must be satisfied in order for the transaction to complete. These are called chained contracts. This allows situations where an OEM provides a given module to a sensor device, and the device's manufacturer decides to sell access to their device using Blocklet protocols. In this situation, the OEM and manufacturer would each create a contract, and chain them together with some percentage split agreed upon between the both of them. When the payment for the device is received from the buyer, both contracts must verify a payment receipt in order for the device to sell the features. This could also be considered a form of software or hardware licensing that's built right into the purchase of the device's functionality itself, without having to set up licensing agreements between the OEM and manufacturer in the traditional way with paper contracts.
As shown in FIG. 4, a process flow of method 400 illustrates one or more steps for facilitating a transaction between an autonomous transacting device and another party in accordance with blocklet protocols. At step 410, a transaction request is received at the autonomous transacting device. At step 420, the autonomous transacting device evaluates the transaction request against the one or more conditions and/or terms in the digital smart contract. At step 430, the autonomous transacting device confirms that price and/or value is provided by the party initiating the transaction request. At step 440, the autonomous transacting device provides one or more resources and/or initiates the performance of one or more services in accordance with the transaction request.
At step 410, an initiating party makes a request for a transaction with the autonomous transacting device. The initiating party may be any type of entity including a business organization, another device that is autonomous or otherwise, a person having a device with transacting capabilities, and the like. The transaction request of a preferred embodiment may include a request for access, a grant, an extension (e.g., renewal), a request for information (e.g., sensor readings), request for routing assistance, subcontracts (e.g., JWTs with equal or lesser scope that parent smart contract) a request for performance of some work or service by the autonomous device, and/or a request to perform a task or provide a service in accordance with the capabilities of the autonomous transacting device. It shall be understood that the transaction request shall not be limited to the above examples; rather, the transaction request may include any type of request that is consistent with the one or more capabilities and/or resources available to the autonomous transacting device.
At step 420, the autonomous transacting device generates an addendum based on the transaction request. In particular, based on the blocklet protocols, the autonomous transacting device converts the transaction request into a format that is executable in accordance with the JOSE protocols. Therefore, the addendum is dynamically generated by the autonomous transacting device and in a JWT format and is used to bind the parent smart digital contract. The generated addendum must be signed by a JWK or JWT of the prime smart digital contract hosted on the autonomous transacting device and also must be signed with economic value (e.g., cryptocurrency). Cryptographically signing the addendum with both a JWT or JWK of the prime contract and cryptocurrency provided by the initiating party authorizes the addendum.
The signature of the JWT or JWK of digital smart contract (e.g., prime contract) of the autonomous transacting device confirms that the addendum makes a valid transaction request that the autonomous device can perform. In particular, the autonomous transacting device compares the transaction request (e.g., terms) of the addendum to the one or more claims in the exhibits of the parent smart contract of the autonomous device. In such a case, the exhibit is used as a reference validation for the performance to be made under the parent smart digital contract. The exhibits in the parent smart contract lists as claims actions performable with an addendum. Accordingly, following the steps in the claims of the exhibits of the parent smart digital contract allows for the validation of digital contract formed by the addendum together with the smart digital contract of the autonomous device. Accordingly, one or more of the claims in the smart digital contract may require that the addendum is signed by the autonomous transacting device, itself, as well as a second signature of economic value. By attributing a signature having economic value (e.g., cryptocurrency) by the initiating party allows the transaction to be completed without intervention of any outside party and/or device, such as a payment system, and additionally confirms that consideration has been paid to bind the performance to be made under the parent smart digital contract.
In some embodiments, the one or more claims of the exhibit of the parent digital smart contract may not necessarily require a second signature having economic value; rather, it is possible that the second cryptographic signature merely identifies the initiating party, which in some cases is sufficient to bind the digital smart contract and render a performance by the autonomous device in accordance with the transaction request in a validated addendum.
At step 430, the autonomous transacting device confirms the economic value and/or price is provided and further, confirms the value of the signature having economic value. In embodiments where the signature having economic value is a cryptocurrency signature, the autonomous transacting device confirms that the value of the cryptocurrency using the blockchain. In such embodiments, the autonomous transacting device implements a simplified payment verification, which is discussed in more detail below, using only required portions of the blockchain needed to confirm that the value of the cryptocurrency exists and that there has not been any double spend of said cryptocurrency value. However, it shall be understood that, if capable, the autonomous transacting device may use the full blockchain to confirm the value of the cryptocurrency signature. This may be helpful in some case when the initiating party of the transaction is unknown, not trusted, or the value of the cryptocurrency exchange is high.
Accordingly, at step 440, once the autonomous transacting device has validated the addendum and has also verified the value of the cryptocurrency signature, the autonomous transacting device performs in accordance with the terms of the contract bound by the addendum. In such embodiments, the autonomous provides one or more resources and/or initiates performance of one or more services in accordance with the transaction request.
As an example, often when discussing the ability to buy and sell with connected devices, it's assumed that what's for sale is the data from the sensors on the connected device itself, or perhaps access to the machine that the connected device is attached to. However, connected devices that create large-scale mesh networks can also sell raw connectivity as well. Especially when these devices bring network communication to areas where it's difficult or expensive to otherwise communicate wirelessly. Long-range communication becomes another sellable aspect of the device.
Consider a company that makes a connected device that monitors utility power poles. Perhaps the autonomous device is monitoring the status of the pole itself, or the power transfer efficiency of the electricity moving through the cables attached. For the sake of this example, it is assumed that these power pole monitoring devices are running an implementation of the DIST stack.
Since DIST allows for multiple types of functionality to be sold to multiple buyers, it's a simple extension of the same principles to sell general network connectivity in addition to the sensor data monitoring the power poles. So while power utility company may be purchasing the monitoring of power pole health through the devices deployed across all the power poles in a given area, it's possible that others who need general network connectivity could purchase it as well—not knowing or caring that the devices that will transport their messages also happen to be monitoring power poles.
Perhaps a trucking company is moving to automated telemetry for their fleet, and the semi-trucks are outfitted with their own telemetry system running a DIST implementation. And it so happens that this trucking company has routes that traverse very rural areas—areas where cellular access is non-existent or spotty at best. The semi truck's telemetry system would discover a DIST network provider within range of it on one of these remote roads—the network provider being the power pole monitoring system.
Once discovered, a price can be negotiated and agreed upon between the truck's telemetry system and the power pole device, to send a telemetry system message on behalf of the trucking company, routed back hundreds of miles to an Internet backhaul connection, and directly delivered to the trucking company's back-office system. Since Telehash provides for multiple separate sockets of encrypted communication on a given node, the power pole device acts as a tiny network router that can have multiple clients connected to it, routing data to multiple other destinations on behalf of each client—and paid for with different prices.
It shall also be noted that the power utility company cannot see any data sent on behalf of the trucking company, nor can the trucking company see any data sent on behalf of the power utility company. Just as multiple parties use cellular towers to gain connectivity and privacy, one party of a cellular tower cannot see or intercept data sent on behalf of another party.
Blocklet Receipts
As shown in FIG. 5, a process flow of a method 500 illustrates providing a cryptocurrency receipt for a transaction involving an autonomous transacting device. Specifically, method 500 uses raw transaction information and blockchain information to verify an exchange of cryptocurrency value and provide the autonomous transacting device a cryptocurrency receipt as verification that the cryptocurrency was actually paid as consideration for resources and/or services provided by the device.
A cryptocurrency-receipt is defined as a cryptocurrency-based signature that must be presented to the autonomous transacting device that indicates that the cryptocurrency-based signature has a verified value exchange required by the digital smart contract. The verification of value exchange is provided to the autonomous transacting device which hosts the digital smart contract as a cryptocurrency receipt. The cryptocurrency receipt, in some embodiments, includes: 1) the raw transaction and information, 2) block headers for the transaction, 3) block header after the transaction that confirms the transaction, and 4) the portion of the Merkle tree necessary for performing the verification of value.
Presenting the autonomous transacting device with the crypto-receipt authorizes the addendum that is involved in the transaction request. Effectively, the cryptocurrency receipt acts as a cryptographic signature that the device recognizes as an authorization to then perform the addendum. The cryptocurrency receipt of a preferred embodiment verifies the value, itself, in the value exchange. That is, the device performs a cryptocurrency value verification that includes identifying an amount of cryptocurrency required for the requested transaction, identifying one or more cryptocurrency keys exchanged in the transaction, verifying with blockchain ledger associated with the transaction.
While it is preferable to verify a cryptocurrency value exchange using the full blockchain, such verification would be difficult to perform because the autonomous transacting device is most likely a low-memory and low-compute power device (e.g., constrained autonomous device), which typically lacks sufficient computing resources to perform such complex computations according to its existing resources. Especially, in light of the fact that the autonomous transacting device operates without the assistance of an external central authority, such as a central server or the like, which typically could perform a full verification of cryptocurrency value exchange if provided with the full blockchain.
Thus, in lieu of performing cryptocurrency value exchange verification using the full blockchain, the autonomous transacting device of a preferred embodiment performs a simple payment verification (SPV) using only limited portions of the blockchain associated with the transaction.
At step 510, upon receipt of a digitally signed addendum, the autonomous transaction device identifies the cryptocurrency value required to be exchanged for performing the addendum. Specifically, in some embodiments, the autonomous transacting device identifies the transaction request of an addendum generated to the device and compares the transaction request of the addendum to an exhibit (e.g., JWK) of the digital smart contract (e.g., JWT). In such embodiments, the autonomous device can determine a required cryptocurrency value to be exchanged for performing the transaction request of the addendum. That is, in most circumstances, the requested action, performance, and/or resource in the transaction request of the addendum should be associated with a cryptocurrency value in the digital smart contract, that if provided by the party initiating the transaction request, should be sufficient to verify the addendum and therefore, allow the autonomous transacting device to perform in accordance with the terms of the addendum.
At step 520, once the cryptocurrency value for performing the addendum by the autonomous transacting device is identified or digitally signed to the addendum, the autonomous transacting device implements a simple payment verification process in order to verify that the actual cryptocurrency value required for the autonomous device to execute the addendum has been transferred.
The simple payment verification process, in such embodiments, is used to allow a device to operate without storing the full blockchain. Accordingly, the autonomous transacting device downloads only the block headers and do not download the transactions included in each block. Thus, the resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. With this limited blockchain information, the autonomous transacting device, in some embodiments, cannot construct a full picture of all the cryptocurrency available for spending by the party making the transaction request because the device does not know about all the transactions on the network. Accordingly, since the autonomous device only has a limited amount of blockchain information for verifying the exchange of the cryptocurrency value, a slightly different method for verification is required that sometimes relies on peers to provide to provide partial views of relevant parts of the blockchain on demand.
Regarding SPV, SPV verifies transaction by reference to their depth in the blockchain instead of their height. Whereas a full blockchain node will construct a fully verified chain of thousands of blocks and transaction reaching down the blockchain (e.g., back in time) all the way to the genesis block, an SPV node will verify the chain of all blocks (but not all transaction) and link that chain to the transaction of interest.
Specifically, using SPV the autonomous transacting device will establish a link between the transaction and the block that contains it, using a merkle path. Then, the device waits for blocks following the transaction block piled on top of the block containing the transaction and verifies is by establishing its depth under the subsequent blocks. The fact that other nodes on the blockchain network accepted the transaction block and did the necessary work to produce subsequent blocks on top of the transaction block is proof, by proxy, that the transaction was not a double-spend.
Thus, using SPV, the device establishes the existence of a transaction in a block by requesting a merkle path (e.g., part of a Merkle tree) proof and by validating the proof of work in the chain of blocks.
At step 530, once the simplified payment is completed, the autonomous transaction device bundles together as a cryptocurrency receipt two or more of the raw transaction, the transaction block header, subsequent block headers (e.g., 6 or so blocks), and the merkle tree path use to verify proof of work. The cryptocurrency receipt is store at the autonomous transacting device and is also used as an additional signature or at least, an additional verification added to an addendum.
Pennybank Overview
Once an autonomous transacting device has the capability to discover other participants, establish a secure communication channel with them (e.g., using Telehash and TMesh protocols), and decide to trust access from that device through Blocklet protocols, there needs to be a way for a device to buy and sell very small amounts of value between each other directly. Penny Bank protocols sets out to solve this last problem—that of frictionless micro-transaction capability directly between devices in a very lightweight way, and not requiring immediate Internet connectivity to do so or a traditional payment system, which includes some type of central authority to process the payment.
Rather, Penny Bank is a mechanism for placing some amount of value such as Bitcoin or other cryptocurrency on hold between two parties without involving another third party, such that those two parties can then exchange smaller amounts of value over time independently. This requires that one or both parties be willing to source that amount of value and have it locked in an escrow between them, so that only through cooperation can it be unlocked again.
Penny Bank protocols implement a zero-knowledge proof in order to allow parties to pay each other without revealing any information other than proving to each other that their payment is valid. This mechanism also allows two parties to exchange payment directly with each other without having Internet connectivity at the time of transfer or a central transacting authority, such as a central server, to reconcile the transaction. At any time during the ongoing transactions between the two parties, either party that has Internet access and wishes to do so or otherwise, has access to the blockchain, can request to reconcile their balances and value will be balanced between the two parties.
Accordingly, in cryptography, zero-knowledge proof is a method by which one party (e.g., the prover) can prove to another party, such as a verifier (e.g., blockchain) that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.
If proving the statement requires knowledge of some secret information on the part of the prover, the definition implies that the verifier will not be able to prove the statement in turn to anyone else, since the verifier does not possess the secret information. Notice that the statement being proved must include the assertion that the prover has such knowledge (otherwise, the statement would not be proved in zero-knowledge, since at the end of the protocol the verifier would gain the additional information that the prover has knowledge of the required secret information). If the statement consists only of the fact that the prover possesses the secret information, it is a special case known as zero-knowledge proof of knowledge, and it nicely illustrates the essence of the notion of zero-knowledge proofs: proving that one has knowledge of certain information is trivial if one is allowed to simply reveal that information; the challenge is proving that one has such knowledge without revealing the secret information or anything else.
For zero-knowledge proofs of knowledge, the protocol must necessarily require interactive input from the verifier, usually in the form of a challenge or challenges such that the responses from the prover will convince the verifier if and only if the statement is true (i.e., if the prover does have the claimed knowledge). This is clearly the case, since otherwise the verifier could record the execution of the protocol and replay it to someone else: if this were accepted by the new party as proof that the replaying party knows the secret information, then the new party's acceptance is either justified—the replayer does know the secret information—which means that the protocol leaks knowledge and is not zero-knowledge, or it is spurious—i.e. leads to a party accepting someone's proof of knowledge who does not actually possess it.
The Penny Bank protocols, which implements zero-knowledge proof, are particularly helpful with microtransactions and/or micropayments in which the transaction costs are high relative to the overall value of the transaction amounts. In a traditional blockchain transaction involving cryptocurrency, the cryptographic costs for creating a transaction for each of the microtransactions is high. For instance, if two parties contemplated ten microtransactions, then each of the ten microtransactions would require a separate cryptographic transaction to be created in the blockchain therefore multiplying the cost of transacting between the two parties by ten. However, using Penny Bank, the cryptographic costs are significantly reduced because only a limited number of cryptographic transactions are necessary. For instance, the number of transaction incurring significant cryptographic expense due to the use of block chain may be limited to as little as two transactions.
In many common micro-transaction scenarios, there is some prior trust or reputation with one of the parties (such as service providers) where having some funds locked in an escrow with them is not very risky. When there is limited or no trust, then the locked value should be small to reduce the risk, the only side-effect being a larger percentage of fees on the transaction to fund it.
In particular, as shown in FIG. 6, the process flow of method 600 implementing the Penny Bank protocols for facilitating microtransactions and/or micropayments.
At step 610, a sidechain for the microtransactions is created. A sidechain is separate from the main blockchain but would be interoperable to allow for a transfer of cryptocurrency assets between the sidechain and the main blockchain. Accordingly, the sidechain is a blockchain that runs in parallel to the main blockchain which extend functionality through interoperable blockchain networks allowing decentralized way of transferring/synchronizing cryptocurrency token between the two chains.
Sidechains are decentralized like the blockchain. The sidechain comprises a set of secrets for incremental performance of an overall transaction or for each microtransaction in a set of microtransactions between two parties.
At step 620, a set of shared secrets or key pairs are generated prior to performing the microtransactions and prior to establishing an escrow at the main blockchain. Each key in the pair is split between the transacting parties and can be exchanged in order to complete one microtransaction of a set of microtransactions. The set of key pairs provided to the transacting parties may be based on simple hashing (e.g., using 256 hashing) or similar method thereby reducing the transaction costs significantly.
At step 630, the parties to the transactions negotiate a simple escrow where the party making the transactions request sets aside funds for the transactions (e.g., a series of microtransactions), which is guaranteed to be available to the two parties. The cryptographic escrow is created at the main blockchain and only when both parties cryptographically sign the escrow can the funds of the escrow be released. Accordingly, all of the key pairs or shared secrets between the parties are provided to the escrow at the blockchain. In this way, the blockchain acting as a third party verifier can implement zero-knowledge proofing if one or both of the parties want only a portion of the funds set aside in the escrow released.
Thus, if either party stops cooperating for any reason including malfunction and/or intentional non-cooperation, then the funds at that point remain frozen until cooperation begins again or the party seeking to have the funds released from escrow is able to prove that at least some of the microtransactions have been completed thereby causing the blockchain to release spent or unspent funds.
As mentioned above, in addition to locking the funds in the escrow, the parties provide all of the shared secrets generated at step 710 for each of the microtransactions into the cryptographic escrow. Accordingly, with all of the generated shared secrets stored in the cryptographic escrow at the block chain, the block chain can be used as a third party to verify completion of all or a portion of the microtransactions based on the number of shared secret pairs that have been exchanged to form the sidechain.
At step 640, the parties (e.g., the autonomous device and the transacting party) to the transaction may exchange shared secret pairs for each increment of a transaction that is completed or for each microtransaction that is completed. Each exchanged shared secret key pair creates a block in the sidechain.
At step 650, a party to the transaction requests a release of a portion of the escrowed funds. If either of the parties ceases their performance of the microtransactions, by either a second transacting party (e.g., payee) failing to continue using a resource provided by a first transacting party (e.g., payor) or by failing to provide a resource or service requested in the microtransactions by the second transacting, at step 740, either party may present the sidechain to the blockchain, even if not fully completed with all shared secrets, to release funds in accordance with the percentage completion of the sidechain.
The blockchain in such a case would act as a third party verifier by implementing zero-knowledge proof. The blockchain, in such embodiment, would present a challenge to the requester of the release of funds. In some embodiments, the challenge is based on the one or more shared secrets or key pairs escrowed at the blockchain. In this way, if the requester intends to prove that 50% of the microtransactions have been completed and that 50% of the key pairs have been exchanged, the requester could most likely respond to a challenge from the blockchain showing that a key from the key pair of the other party is 50% percent up the chain.
Then, the blockchain can compare the key to the key pairs stored in escrow to the key pair exchanged in the sidechain to determine a percentage completion of the microtransactions. In this instance, the blockchain may confirm that the key from the other party is 50% up the chain and would release 50% of the funds to the payee and refund the other 50% of the funds to the payor.
The current implementation of Penny Bank currently only focuses on the core locking mechanism and exchanges. It is possible to add timelocks and create more complex transactions that further reduce the risk of funds remaining locked at an escrow account
The system and methods of the preferred embodiment and variations thereof can be embodied and/or implemented at least in part as a machine configured to receive a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components. The computer-readable medium can be stored on any suitable computer-readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a general or application specific processor, but any suitable dedicated hardware or hardware/firmware combination device can alternatively or additionally execute the instructions.
Although omitted for conciseness, the preferred embodiments include every combination and permutation of the various system components and the various method processes.
As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.

Claims

We claim:

1. A system for facilitating microtransactions involving an autonomous transacting device, the system comprising:

a blockchain;

a transacting entity;

an autonomous transacting device comprising:

(i) a cryptographic processor;

(ii) a cryptographic storage medium having cryptographic code stored thereon, that when executed by the cryptographic processor performs:

generating a plurality of key pairs and sharing a key of each of the plurality of key pairs with the transacting entity;

establishing an escrow at the blockchain and providing the plurality of key pairs to the blockchain;

exchanging one or more of the key pairs using a sidechain;

requesting a release or a refund of funds from the escrow; and

presenting one or more exchange key pairs to the blockchain thereby establishing a percent completion of the sidechain.

2. A method for facilitating microtransaction involving an autonomous transacting device, the method comprising:

at a cryptographic processor operably in communication a cryptographic storage medium having stored thereon computer-executable code stored thereon, that when executed by the cryptographic processor performs:

generating a plurality of key pairs and sharing a key of each of the plurality of key pairs with a transacting entity;

establishing an escrow at the blockchain and providing the plurality of key pairs to a blockchain;

exchanging one or more of the key pairs using a sidechain;

requesting a release or a refund of funds from the escrow; and

3. A non-transitory computer-readable medium having stored thereon computer-executable code that when executed by one or more of a processor and a cryptographic processor performs:

establishing an escrow at a blockchain and providing the plurality of key pairs to the blockchain;

exchanging one or more of the key pairs using a sidechain;

requesting a release or a refund of funds from the escrow; and