Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Various embodiments are generally directed to an apparatus, system, and other techniques for shared, trusted token generation for a token-bucket flow control policy implemented in a distributed ledger. Tokens may be generated by blocks in the distributed ledger, which may be a blockchain system. Trusted execution hardware may be used as a proof algorithm to ensure that a token exists, and that client has legitimately acquired or accumulated the token prior to using it to submit a transaction.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Various embodiments are generally directed to an apparatus, system, and other techniques for shared, trusted token generation for a token-bucket flow control policy implemented in a distributed ledger. Tokens may be generated by blocks in the distributed ledger, which may be a blockchain system. Trusted execution hardware may be used as a proof algorithm to ensure that a token exists, and that client has legitimately acquired or accumulated the token prior to using it to submit a transaction.

Abstract: Techniques for securely provisioning a set of enclaves are described. A contract owner may register with a shared registry. A subset of enclaves may be selected to be provisioned from among a plurality of enclaves. A keyshare may be requested from one or more provisioning services for each of the subset of enclaves to be provisioned. The requested keyshares may be received from each provisioning service for each of the subset of enclaves to be provisioned. For each of the selected enclaves, the received keyshares may be sent for verification by the enclave. Each of the selected enclaves may send an authenticated and encrypted key derived from the received keyshares.

Abstract: The present invention discloses a secure ML pipeline to improve the robustness of ML models against poisoning attacks and utilizing data provenance as a tool. Two components are added to the ML pipeline, a data quality pre-processor, which filters out untrusted training data based on provenance derived features and an audit post-processor, which localizes the malicious source based on training dataset analysis using data provenance.

Abstract: Various embodiments are generally directed to an apparatus, system, and other techniques for shared, trusted token generation for a token-bucket flow control policy implemented in a distributed ledger. Tokens may be generated by blocks in the distributed ledger, which may be a blockchain system. Trusted execution hardware may be used as a proof algorithm to ensure that a token exists, and that client has legitimately acquired or accumulated the token prior to using it to submit a transaction.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for securely provisioning a set of enclaves are described. A contract owner may register with a shared registry. A subset of enclaves may be selected to be provisioned from among a plurality of enclaves. A keyshare may be requested from one or more provisioning services for each of the subset of enclaves to be provisioned. The requested keyshares may be received from each provisioning service for each of the subset of enclaves to be provisioned. For each of the selected enclaves, the received keyshares may be sent for verification by the enclave. Each of the selected enclaves may send an authenticated and encrypted key derived from the received keyshares.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: An automated method to verify a block record for a digital ledger involves a first validation node (FVN) which receives a block record from a second validation node (SVN). The block record comprises a digital signature for the block record. In response to receiving the block record, the FVN automatically obtains a node identifier for the SVN, based on the digital signature for the block record. The first validator node uses the node identifier for the SVN to determine whether the SVN belongs to a validation group that comprises the FVN. The FVN uses an attestation service to determine whether the node identifier for the SVN belongs to a node with a trusted processor. The FVN determines whether the digital signature for the block record was created with a private key that corresponds to the node identifier for the SVN.

Abstract: Techniques for securely provisioning a set of enclaves are described. A contract owner may register with a shared registry. A subset of enclaves may be selected to be provisioned from among a plurality of enclaves. A keyshare may be requested from one or more provisioning services for each of the subset of enclaves to be provisioned. The requested keyshares may be received from each provisioning service for each of the subset of enclaves to be provisioned. For each of the selected enclaves, the received keyshares may be sent for verification by the enclave. Each of the selected enclaves may send an authenticated and encrypted key derived from the received keyshares.

Abstract: Various techniques for collection and processing of motor vehicle telematics data and establishing control over access to the telematics data are disclosed herein. In an example, a communication device (e.g., a computing device) operated by an owner or operator of a motor vehicle operates to receive telematics data from a telematics system, generate and transmit a derived indication of the telematics data (e.g., using a hash of the data), receive and process a request for information from the telematics data, and generate and transmit an answer and proof of the answer validity in response to the request for information. In an example, the proof of the answer validity may be provided as a zero knowledge proof. The proof may be verified using the derived indication of the telematics data, such as from an indication that is stored in a public distributed blockchain that is auditable and unalterable.

Abstract: Techniques for sharing private data objects in a trusted execution environment using a distributed ledger are described. The techniques described herein may enable sharing of data objects, referred to herein as private data objects (PDOs), between individuals and organizations with access and update policies mediated by execution of code (referred to herein as a “smart contract”) carried with the PDO in a secure enclave. A distributed ledger may serve as a “public commit log” to ensure that there is a single, authoritative instance of the object and provide a means of guaranteeing atomicity of updates across interacting objects.

Abstract: Techniques for securely provisioning a set of enclaves are described. A contract owner may register with a shared registry. A subset of enclaves may be selected to be provisioned from among a plurality of enclaves. A keyshare may be requested from one or more provisioning services for each of the subset of enclaves to be provisioned. The requested keyshares may be received from each provisioning service for each of the subset of enclaves to be provisioned. For each of the selected enclaves, the received keyshares may be sent for verification by the enclave. Each of the selected enclaves may send an authenticated and encrypted key derived from the received keyshares.

Abstract: Techniques for remote SGX enclave authentication are described. An attestation service may be used to attest that an enclave was successfully established on a Software Guard Extensions (SGX) enabled platform. Further, an attestation service may, in embodiments, be used as a notary system to attest that a public-key certificate was generated by a particular SGX enclave and, therefore, may be trusted by other remote enclaves for authentication. In an embodiment, a client-side SGX enclave may generate a public-private key pair (SK, PK), compute a cryptographic hash H of PK, create a report R containing H, obtain a quote Q on the report R from a quoting enclave component, obtain remote attestation response RA from an attestation service, and broadcast RA and PK to one or more server side SGX enclaves. Other embodiments are described and claimed.

Abstract: An automated method to verify a block record for a digital ledger involves a first validation node (FVN) which receives a block record from a second validation node (SVN). The block record comprises a digital signature for the block record. In response to receiving the block record, the FVN automatically obtains a node identifier for the SVN, based on the digital signature for the block record. The first validator node uses the node identifier for the SVN to determine whether the SVN belongs to a validation group that comprises the FVN. The FVN uses an attestation service to determine whether the node identifier for the SVN belongs to a node with a trusted processor. The FVN determines whether the digital signature for the block record was created with a private key that corresponds to the node identifier for the SVN. Other embodiments are described and claimed.

Abstract: Various techniques for collection and processing of motor vehicle telematics data and establishing control over access to the telematics data are disclosed herein. In an example, a communication device (e.g., a computing device) operated by an owner or operator of a motor vehicle operates to receive telematics data from a telematics system, generate and transmit a derived indication of the telematics data (e.g., using a hash of the data), receive and process a request for information from the telematics data, and generate and transmit an answer and proof of the answer validity in response to the request for information. In an example, the proof of the answer validity may be provided as a zero knowledge proof. The proof may be verified using the derived indication of the telematics data, such as from an indication that is stored in a public distributed blockchain that is auditable and unalterable.