Ebay, Incorporated

Cloudflare, Inc.

Derek A Chamorro

Venkata Siva Vijayendra Bhamidipati

Michael L Chan

Arpit Jain

Ashok Srinivasa Murthy

Michael J T Chan

Nikhil Firke

Anuj Kaul

Sahil Chadha

Michael Pak

Sean R Embry

Nicholas Alexander Wondra

Tom Paseka

Molly Rose Cinnamon

Ralph Scott Forsythe

Glenn G Lebumfacil

Chase Robinson

Ignat Korchagin

Anirudh Kamalapuram Muralidhar

Michael JT Chan

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.

Distributed key management system

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.

Distributed key management system with a key lookup service

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.

Isolating internet-of-things (IoT) devices using a secure overlay network

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.

Traceable key block-chain ledger

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.

System level function based access control for smart contract execution on a blockchain

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.

Adaptive security for smart contracts using high granularity metrics

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.

Storing and verification of derivative work data on blockchain with original work data

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.

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.

Masked key hopping

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.

Resource trust model for securing component state data for a resource using blockchains

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.

Growing community of inventors

Austin, TX, United States of America

Derek A Chamorro