Technologies for secure I/O data transfer includes a compute device, which includes a processor to execute a trusted application, an input/output (I/O) device, and an I/O subsystem. The I/O subsystem is configured to establish a secured channel between the I/O subsystem and a trusted application running on the compute device, and receive, in response to an establishment of the secured channel, I/O data from the I/O device via an unsecured channel. The I/O subsystem is further configured to encrypt, in response to a receipt of the I/O data, the I/O data using a security key associated with the trusted application that is to process the I/O data and transmit the encrypted I/O data to the trusted application via the secured channel, wherein the secured channel has a data transfer rate that is higher than a data transfer rate of the unsecured channel between the I/O device and the I/O subsystem.

A method and system for performing computational jobs securely on a shared computing resource. Data files for the computational job are encrypted on a secure system and the encrypted data files are stored in a data store on the shared computing resource. A key distribution server is established using a secure enclave on a front end of the shared computing resource. Cryptographic keys and application binaries are transferred to the enclave of the shared computing resource using a session key. The computational job is run using an application launcher on compute nodes of an untrusted execution environment of the shared computing resource, the application launcher obtaining the application binaries and the cryptographic keys from the key distribution server.

This specification discloses devices and methods for a security concept that includes an immobile hardware token (e.g., a “wall token” that is fixed within a wall) which ensures that the more sensitive actions of electronic banking (e.g., money transfers of large sums to foreign bank accounts) can only be done from the account owner's home, but not from a remote place. However, other less sensitive (and lower security risk) actions can still be done from anywhere else. In some embodiments, the hardware token includes sensors to ensure that the token is not moved or tampered with, interfaces to provide distance bounding, and a crypto-processor to provide secure authentication. The distance bounding can be used to determine if the authentication device is in close proximity to the hardware token, which can in turn ensure that the authentication device is within the account owner's home.

A method for authenticating an origin of a network device. The method includes reading one or more encrypted parameters from a memory of the network device, decoding the one or more encrypted parameters, and determining whether one or more of the decoded parameters match parameters obtained from a trusted platform module (TPM) installed in the network device and/or a read only memory (ROM) of the network device. In response to a mismatch between the decoded parameters and the parameters obtained from the TPM or the ROM, at least one of suspending operation of the device or transmitting a report of an authentication failure across a network on which the device is operating.

Aspects of the disclosure provide various methods relating to enclaves. For instance, a method of authentication for an enclave entity with a second entity may include receiving, by one or more processors of a host computing device of the enclave entity, a request and an assertion of identity for the second entity, the assertion including identity information for the second identity; using an assertion verifier of the enclave entity to determine whether the assertion is valid; when the assertion is valid, extracting the identity information; authenticating the second entity using an access control list for the enclave entity to determine whether the identity information meets expectations of the access control list; when the identity information meets the expectations of the access control list, completing the request.

An active attestation apparatus verifies at runtime the integrity of untrusted machine code of an embedded system residing in a memory device while it is being run/used with while slowing the processing time less than other methods. The apparatus uses an integrated circuit chip containing a microcontroller and a reprogrammable logic device, such as a field programmable gate array (FPGA), to implement software attestation at runtime and in less time than is typically possible with comparable attestation approaches, while not requiring any halt of the processor in the microcontroller. The reprogrammable logic device includes functionality to load an encrypted version of its configuration and operating code, perform a checksum computation, and communicate with a verifier. The checksum algorithm is preferably time optimized to execute computations in the reprogrammable logic device in the minimum possible time.

The invention relates to distributed ledger technologies such as consensus-based blockchains. Computer-implemented N methods for reducing arithmetic circuits derived from smart contracts are described. The invention is implemented using a blockchain network, which may be, for example, a Bitcoin blockchain. A set of conditions encoded in a first programming language is obtained. The set of conditions is converted into a programmatic set of conditions encoded in a second programming language. The programmatic set of conditions is precompiled into precompiled program code. The precompiled program code is transformed into an arithmetic circuit. The arithmetic circuit is reduced to form a reduced arithmetic circuit, and the reduced arithmetic circuit is stored.

Methods and integrated circuit architectures for assuring the protection of intellectual property between third party IP providers, system designers (e.g., SoC designers), fabrication entities, and assembly entities are provided. Novel design flows for the prevention of IP overuse, IP piracy, and IC overproduction are also provided. A comprehensive framework for forward trust between 3PIP vendors, SoC design houses, fabrication entities, and assembly entities can be achieved, and the unwanted modification of IP can be prevented.

According to certain general aspects, the present embodiments relate generally to securing communication between ECUs. Example implementations can include a method of securely transmitting Controller Area Network (CAN) protocol frames via a CAN controller.

A client computing device may obtain access to protected resources with a proof-of-possession (Pop) token. The client computing device may request an access token from an authorization server via an application server. The request may include key material (e.g., token binding type, key, and key parameters) that the client computing device possesses or has access to, such as a public key of an asymmetric public/private key pair. In some embodiments, the public key may be a confirmation (CNF) key, which may be added to the access token and JWT signed by the authorization server. The private key may be retained by the client, who may then use the PoP token to prove possession of the private key.