Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for processing blockchain data under a trusted execution environment (TEE). One of the methods includes receiving, by a blockchain node, a request to execute one or more software instructions in a TEE executing on the blockchain node; determining, by a virtual machine in the TEE, data associated with one or more blockchain accounts to execute the one or more software instructions based on the request; traversing, by the virtual machine, an internal cache hash table stored in the TEE to determine whether the data are included in the internal cache hash table; and in response to determining that the data is included in the internal cache hash table, executing, by the virtual machine, the one or more software instructions by retrieving the data from the internal cache hash table.

Methods and systems for implementing DevID enrollment for hardware redundant Trust Platform Modules (TPMs), are described. A system can include hardware redundancy for management modules, and for TPMs that correspond to each management module. Accordingly, a product can have a dual-TPM configuration, where both modules are associated with the same product. Further, a process that particularly considers the presence of dual-TPMs for creating, issuing, and enrolling DevID certificates is described. The process issues and maintains DevID certificates for each TPM by synchronizing dual sessions that correspond to each TPM. Also, the process accounts for duplicate identification data, for example allowing the certificate authority (CA) to sign certificates for dual-TPMs linked to the same chassis number. The process can include performing validation checks, rendezvous points, and locks to ensure that DevID certificates are successfully issued for each of the dual-TPMs, respectively.

One embodiment provides a client device. The client device includes a Trusted Platform Module (TPM). The TPM includes a secure controller to extend a secure hash digest with at least a portion of a data stream or a hash of the at least a portion of the data stream. Another embodiment provides a server system. The server system includes verifier logic. The verifier logic is to verify that an attestation identity key (AIK) public key associated with a received Trusted Platform Module (TPM) quote corresponds to an authenticated client device.

One embodiment provides a client device. The client device includes a Trusted Platform Module (TPM). The TPM includes a secure controller to extend a secure hash digest with at least a portion of a data stream or a hash of the at least a portion of the data stream. Another embodiment provides a server system. The server system includes verifier logic. The verifier logic is to verify that an attestation identity key (AIK) public key associated with a received Trusted Platform Module (TPM) quote corresponds to an authenticated client device.

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for blockchain address mapping are provided. One of the methods includes: obtaining one or more requests for creating a plurality of blockchain addresses in association with one or more local accounts; and creating the plurality of blockchain addresses respectively in association with the one or more local accounts.

Techniques are disclosed relating to relating to a public key infrastructure (PKI). In one embodiment, an integrated circuit is disclosed that includes at least one processor and a secure circuit isolated from access by the processor except through a mailbox mechanism. The secure circuit is configured to generate a key pair having a public key and a private key, and to issue, to a certificate authority (CA), a certificate signing request (CSR) for a certificate corresponding to the key pair. In some embodiments, the secure circuit may be configured to receive, via the mailbox mechanism, a first request from an application executing on the processor to issue a certificate to the application. The secure circuit may also be configured to perform, in response to a second request, a cryptographic operation using a public key circuit included in the secure circuit.

A tamper responsive sensor comprising: a carrier printed circuit board (carrier PCB), holding a mesh of one or more electrically conductive tracks, a pressure or force sensitive switch contact arranged on top of the carrier PCB and having first and second electrical contact connections, tamper detecting circuitry arranged at the carrier PCB and being powered via two electrical power lines and connected to one or more electrically conductive signal lines, wherein one of said power lines or one of said signal lines is electrically connected to the tamper detecting circuitry via a first tamper line holding the switch contact, and wherein one of said power lines or one of said signal lines is electrically connected to the tamper detecting circuitry via a second tamper line holding a conductive track of the carrier PCB mesh.

The disclosed technology is generally directed to cryptographic functions for smart contracts. In one example of the technology, a request for cryptographic resources is received. The request for cryptographic resources includes a binding identity (ID). Cryptographic resources are fetched from at least one cryptographic resource pool of a plurality of cryptographic resource pools responsive to the request for cryptographic resources. Separate cryptographic resource pools of the plurality of cryptographic resource pools are pools of separate types of cryptographic resources. Which type of proof delegate code is suitable for each fetched cryptographic resource is determined. For each fetched cryptographic resource, the determined type of proof delegate code is injected into the fetched cryptographic resource.

A first server exchanges with a second server a master (symmetric) key(s). The first server sends to the first application the master key(s). The second server generates dynamically a first derived key by using a generation parameter(s) and a first master key. The second server sends to the second application the first derived key and the generation parameter(s). The second application generates and sends to the first application a first (key possession) proof and the generation parameter(s). The first application verifies successfully by using the generation parameter(s), the first master key and the first proof, that the first proof has been generated by using the first derived key, generates and sends to the second application a second (key possession) proof. The second application verifies successfully that the second proof has been generated by using the first derived key, as a dynamically generated and proven shared key.

A hub device of a network receives a data model that includes a secure portion that is encrypted and one or more unsecure portions. The hub device deploys the one or more unsecure portions of the data model to respective edge devices of the network. The hub device decrypts the secure portion of the data model. The edge devices collect data (e.g., from sensors) and process the data using the unsecure portions of the data model. The edge devices send the processed data to the hub device. The hub device performs operations on the received processed data using the decrypted secure portion of the data model in a secure execution environment (e.g., a TPM or other secure module). The secure portion of the data model generates a result, which is then transmitted to an endpoint.