Abstract: Techniques are shown for key management using a traceable key blockchain. A first block corresponding to a cryptographic key is generated on the blockchain, and the first block is securely modified to include metadata describing a key source for the cryptographic key. A second block corresponding to a first key transaction with the cryptographic key is generated on the blockchain, the second block is linked to the first block, and the second block is securely modified to include metadata describing the first key transaction with the cryptographic key.

Abstract: A distributed key management system (KMS) includes a central KMS server and multiple intermediate KMS servers. The central KMS server replicates managed keys to the intermediate KMS servers. An intermediate KMS server receives a KMS service request from a KMS client, where any of the intermediate KMS servers are capable of servicing the request. The intermediate KMS server performs the action requested if it has access to the necessary managed key and returns the response to the KMS client. If it does not have access to the necessary managed key, the intermediate KMS server transmits a request for the managed key to the central KMS server. The intermediate KMS server receives the managed key, performs the action requested, and returns the response to the KMS client.

Abstract: Technologies are shown for high granularity metric (HGM)-based control for smart contract execution. In accordance with some aspects, a function call associated with one or more methods of a smart contract on a blockchain is detected by identifying an entrance or exit of the function call in a kernel for smart contract execution on the blockchain. The function call is added to a function call stack, and one or more detected HGMs are identified in the function call stack. A comparison of the detected HGMs in the function call stack against one or more control rules is performed. Execution or completion of the function call is blocked based on the comparison.

Abstract: Technologies are shown for system level function based access control for smart contract execution on a blockchain. Access control rules control function calls at a system level by utilizing function boundary detection instrumentation in a kernel that executes smart contracts. The detection instrumentation generates a call stack that represents a chain of function calls in the kernel for execution of a smart contract. The access control rules are applied to the function call stack to allow or prohibit specific functions or function call chains. Access control rules can also define allowed or prohibited parameter data in the function call chain. If the function call chain or parameters do not meet the requirements defined in the access control rules, then the function call can be blocked from executing or completing execution. The access control rules can produce sophisticated access control policies based on complex function call chains.

Abstract: A first intermediate key management system (KMS) server of a distributed KMS receives a key lookup service (KLS) query from a KMS client for determining an identity of KMS server(s) that are capable of performing a first operation with a first managed key. The first intermediate KMS server is one of the intermediate KMS servers of the distributed KMS. The first KMS server determines the identity of one or more of the KMS servers that are capable of performing the first operation with the first managed key. The first KMS server transmits a KLS response to the KMS client that includes the identity of the KMS server(s) that are capable of performing the first operation with the first managed key.

Abstract: Technologies are shown for HGM based control for smart contract execution. HGM control rules control function calls at a system level utilizing function boundary detection instrumentation in a kernel that executes smart contracts. The detection instrumentation generates a call stack that represents a chain of function calls in the kernel for a smart contract. The HGM control rules are applied to HGMs collected from the call stack to allow or prohibit specific HGMs observed in functions or function call chains. HGM control rules can use dynamic state data in the function call chain. If the dynamic state data observed in function call chains does not meet the requirements defined in the HGM control rules, then the function call can be blocked from executing or completing execution. The HGM control rules can be generated by executing known sets of acceptable or vulnerable smart contracts and collecting the resulting HGMs.

Abstract: Technologies are shown for function level permissions control for smart contract execution to implement permissions policy on a blockchain. Permissions control rules control function calls at a system level utilizing function boundary detection instrumentation in a kernel that executes smart contracts. The detection instrumentation generates a call stack that represents a chain of function calls in the kernel for a smart contract. The permissions control rules are applied to the call stack to implement permissions control policy. Permissions control rules can use dynamic state data in the function call chain. If the dynamic state data observed in function call chains does not meet the requirements defined in the permissions control rules, then the function call can be blocked from executing or completing execution. The permissions control rules can be generated for a variety of different entities, such as a domain, user or resource.

Abstract: Disclosed is technology for storing original work data on a derivative work data blockchain along with code for verifying that derivative work data is derivative of the original work data. The technology involves receiving derivative work data from a submitting entity along with proof data showing that the derivative work is derivative of the original work. If the derivative work data is verified as derivative, then the derivative work data is appended to the derivative work data blockchain.

Abstract: A server of a distributed cloud computing network receives, over a tunnel established between a customer-premises equipment and the compute server, traffic from an Internet-of-Things (IoT) device that is connected to the CPE. The server enforces an egress traffic policy to determine whether the traffic is permitted to be transmitted to the destination. If the traffic is not permitted to be transmitted to the destination, the server drops the traffic. If the traffic is permitted to be transmitted to the destination, the server transmits the traffic to the destination.

Abstract: Technologies are shown for function level permissions control for smart contract execution to implement permissions policy on a blockchain. Permissions control rules control function calls at a system level utilizing function boundary detection instrumentation in a kernel that executes smart contracts. The detection instrumentation generates a call stack that represents a chain of function calls in the kernel for a smart contract. The permissions control rules are applied to the call stack to implement permissions control policy. Permissions control rules can use dynamic state data in the function call chain. If the dynamic state data observed in function call chains does not meet the requirements defined in the permissions control rules, then the function call can be blocked from executing or completing execution. The permissions control rules can be generated for a variety of different entities, such as a domain, user or resource.

Abstract: Techniques are shown for key management using a traceable key blockchain. A first block corresponding to a cryptographic key is generated on the blockchain, and the first block is securely modified to include metadata describing a key source for the cryptographic key. A second block corresponding to a first key transaction with the cryptographic key is generated on the blockchain, the second block is linked to the first block, and the second block is securely modified to include metadata describing the first key transaction with the cryptographic key.

Abstract: Systems and methods employ a blockchain for managing component state data for each component of a resource, where the resource has a plurality of different components. In accordance with some aspects, a resource data block is generated for a resource that has a plurality of components. The resource data block includes a first link to a first component data block that corresponds to a first component of the plurality of components for the resource. The resource data block is committed to a blockchain.

Abstract: Technologies are shown for selecting a provider to service a client service request using a consensus protocol and creating a block on a blockchain to service the client service request. In accordance with some aspects, a first miner receives parameters of each proposal transaction from a plurality of proposal transactions for servicing a client service request. The parameters of at least one proposal transaction from the plurality of proposal transactions is received from a second miner. The first miner uses a selection algorithm to select a first proposal transaction from the plurality of proposal transactions based on the parameters of each proposal transaction. The first miner appends a block to a blockchain based on the first proposal transaction.

Abstract: A server of a distributed cloud computing network receives, over a tunnel established between a customer-premises equipment and the compute server, traffic from an Internet-of-Things (IoT) device that is connected to the CPE. The server enforces an egress traffic policy to determine whether the traffic is permitted to be transmitted to the destination. If the traffic is not permitted to be transmitted to the destination, the server drops the traffic. If the traffic is permitted to be transmitted to the destination, the server transmits the traffic to the destination.

Abstract: Techniques are shown for key management using a traceable key block-chain ledger involving creating a cryptographic key at a key source, generating a key block on a block-chain ledger corresponding to the cryptographic key, and securely modifying the key block to include metadata describing the key source. The techniques also involve performing a first key transaction with the cryptographic key, generating a first transaction block on the block-chain ledger corresponding to the first key transaction with the cryptographic key, linking the first transaction block to the key block and securely modifying the first transaction block to include metadata describing the first key transaction with the cryptographic key.

Abstract: Systems and methods for managing keys in a computer memory are described. In some embodiments, location addresses are determined for two key elements. A periodic time interval that is based on a time duration for performing a transaction involving a distance between the key elements is determined. One key element may be stored at a location address and then relocated to another location address after the periodic time interval has passed. In some embodiments, areas the computer memory may remain static during relocation of the key element.

Abstract: Technologies are shown for storing sub-component state data for a resource on a blockchain involving generating a resource data block that corresponds to a resource that includes links that correspond to sub-components of the resource, generating a first sub-component state data block for a sub-component of the resource on a blockchain that includes first state data for the first sub-component, and setting the link for the sub-component to reference the first sub-component state data block. Subsequently, a second sub-component state data block can be generated for the sub-component with second state data and the second sub-component state data block linked to the first sub-component state data block.

Abstract: Technologies are shown for selecting a provider to service a client service request using a predictive metrics based consensus protocol to select a provider and create a service request transaction block to service the client service request. A client service request is received and forwarded to a set of providers. Proposed transactions are received from the providers and scored based on a predictive metric. A proposal transaction is selected based on the scoring and the selected transaction is written as a block on a service transaction blockchain. The provider for the selected transaction detects the block on the blockchain and performs the requested service. The client detects the block on the blockchain and transfers payment to the provider. Selection can be based on predictive metrics in the providers or macro metrics determined in miner nodes in combination with provider reputation, currency, load sharing, fairness, provisioning, and static and dynamic criteria.

Abstract: A distributed key management system (KMS) includes a central KMS server and multiple intermediate KMS servers. The central KMS server replicates managed keys to the intermediate KMS servers. An intermediate KMS server receives a KMS service request from a KMS client, where any of the intermediate KMS servers are capable of servicing the request. The intermediate KMS server performs the action requested if it has access to the necessary managed key and returns the response to the KMS client. If it does not have access to the necessary managed key, the intermediate KMS server transmits a request for the managed key to the central KMS server. The intermediate KMS server receives the managed key, performs the action requested, and returns the response to the KMS client.

Abstract: Technologies are shown for HGM based control for smart contract execution. HGM control rules control function calls at a system level utilizing function boundary detection instrumentation in a kernel that executes smart contracts. The detection instrumentation generates a call stack that represents a chain of function calls in the kernel for a smart contract. The HGM control rules are applied to HGMs collected from the call stack to allow or prohibit specific HGMs observed in functions or function call chains. HGM control rules can use dynamic state data in the function call chain. If the dynamic state data observed in function call chains does not meet the requirements defined in the HGM control rules, then the function call can be blocked from executing or completing execution. The HGM control rules can be generated by executing known sets of acceptable or vulnerable smart contracts and collecting the resulting HGMs.