Peripheral device

Abstract

A peripheral device for use with a host includes one or more computing elements, a security module, and at least one encryption unit. The security module is configured to form a trusted execution environment on the peripheral device to process the sensitive data using the sensitive code. Sensitive data and sensitive code are provided by a trusted computing entity in communication with a host computing device. The at least one encryption unit is configured to encrypt and decrypt data passed between the trusted execution environment and the trusted computing entity via the host computing device. The security module is configured to compute and send an attestation to the trusted computing entity to attestation that the sensitive code is in the trusted execution environment.

Description

[0001] Related Applications

[0002] This application is a divisional application of an invention patent application with an international application date of September 5, 2019, which entered the Chinese national stage on April 16, 2021, with Chinese national application number 201980068700.5 and invention name “Peripheral Device”. Background Art

[0003] Peripherals such as graphics processing units, field programmable gate arrays (FPGAs), application specific integrated circuits, cryptographic accelerators, video processing units, regular expression accelerators, data compression accelerators, artificial intelligence accelerators, etc. are increasingly being used to supplement the central processing unit (CPU) of the host. Peripherals that are separate from the CPU and act as hardware accelerators are often very useful units that include computer hardware that performs functions more efficiently than is possible in software running on a general-purpose CPU. Typically, these types of peripherals improve the execution of specific types of algorithms by allowing greater concurrency. Peripherals are also used to provide higher reliability and different security options.

[0004] There is an increasing need to use sensitive code and / or sensitive data and maintain security and privacy. Typically, large amounts of sensitive code and / or data will be processed using resource-intensive algorithms, and in this case, peripherals are an option to improve efficiency. However, in the case of using peripherals, because there are both hosts and peripherals, and the host itself is usually untrusted, additional challenges are introduced regarding the security and privacy of sensitive code and / or data. Sensitive code and sensitive data reach peripherals via the host, and therefore an attacker may be able to obtain sensitive information from an untrusted host.

[0005] The embodiments described below are not limited to implementations that solve any or all disadvantages of known peripheral devices. Summary of the invention

[0006] A simplified summary of the present disclosure is presented below in order to provide the reader with a basic understanding. This summary is neither intended to identify key features or essential features of the claimed subject matter nor to be used to limit the scope of the claimed subject matter. Its sole purpose is to present a selection of the concepts disclosed herein in a simplified form as a prelude to a more detailed description that is presented later.

[0007] In various examples, there is a peripheral device for use with a host computing device, the peripheral device comprising one or more computing elements, a security module, and at least one cryptographic unit. The security module is configured to form a trusted execution environment on the peripheral device to process sensitive data using sensitive code. The sensitive data and sensitive code are provided by a trusted computing entity that communicates with the host computing device. The at least one cryptographic unit is configured to encrypt and decrypt data passed between the trusted execution environment and the trusted computing entity via the host computing device. The security module is configured to compute a proof and send it to the trusted computing entity to prove that the sensitive code is in the trusted execution environment.

[0008] Many of the attendant features will become better appreciated as they are better understood by reference to the following detailed description considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] This description will be better understood from the following detailed description read in conjunction with the accompanying drawings, in which:

[0010] Figure 1 is a schematic diagram of a first trusted computing entity, an untrusted intermediary, and a second trusted computing entity;

[0011] Figure 2 is a schematic diagram of a computing node;

[0012] Figure 3 is a schematic diagram of a data center including an untrusted host computing device having a trusted peripheral device;

[0013] Figure 4 is a schematic diagram of a peripheral device that is Figure 1 An example of a second trusted computing entity;

[0014] Figure 5A is a schematic diagram of a peripheral device package having a security module on a die;

[0015] Figure 5B is a schematic diagram of a peripheral device package having a security module on a die and on a substrate;

[0016] Figure 5C is a schematic diagram of a peripheral device including two packages;

[0017] Figure 6 is a flow chart of a method of operation at a security module;

[0018] Figure 7 It is a message sequence diagram of the remote attestation process;

[0019] Figure 8 is the message sequence diagram of the key exchange method;

[0020] Fig. 9 Is Figure 1 A message sequence diagram of an encryption protocol used by a first trusted entity and a second trusted entity; and

[0021] Fig.10 is a schematic diagram of a computing-based device in which an embodiment of a first trusted computing entity or host is implemented.

[0022] In the drawings, the same reference numerals are used to denote the same parts. DETAILED DESCRIPTION

[0023] The specific embodiments provided below in conjunction with the accompanying drawings are intended to be a description of this example, and are not intended to represent the only form in which this example is constructed or utilized. This description sets forth the functions of the example and the sequence of operations for constructing and operating the example. However, the same or equivalent functions and sequences may be implemented by different examples.

[0024] In various examples described herein, a peripheral device is used with a host computing device. The host computing device is untrustworthy and may be malicious. A tenant is any computing device that communicates with the host computing device and has access to the code that the tenant wants to execute on the peripheral. In some examples, the tenant has sensitive code to be executed on the peripheral device in order to process sensitive data. In some examples, one or more other tenants are also using the peripheral device, but this is not necessary. In the example, the sensitive code implements training or reasoning for a neural network or other machine learning algorithm, and the sensitive data is training data. The machine learning model is trained on the peripheral device, and after training, the resulting trained model parameters are returned from the peripheral to the tenant. The model can also be left in the peripheral device for reasoning after training. However, the technology is not limited to machine learning applications, and any sensitive code and sensitive data are used. In some examples, one or both of the code and data are not sensitive.

[0025] In order for sensitive code to be executed on a peripheral device, the sensitive code will be passed to the peripheral via the host, since input to the peripheral device is made via the host. Once at the peripheral device, the sensitive code can be passed to other peripheral devices of the same host. However, since the host computing device may be malicious, it is not simple to pass sensitive code to the peripheral via the host. Sensitive data will also be passed to the peripheral, and again, this is problematic in the case where the host computing device may be malicious. The tenant does not trust the host computing device, and therefore, even if the sensitive code has been passed to the peripheral, the tenant cannot be sure that the sensitive code is still confidential, nor can it be determined whether the host has tampered with the sensitive code or replaced it with other code. Sensitive data passes through the host and may be corrupted by an untrusted host.

[0026] In some cases, the attacker has privileged access to the host computing device, for example, where the attacker is an administrator of the host operating system or has administrator rights to an application or service in the host operating system. In some cases, the attacker is a hacker who exploits a vulnerability in the operating system of the host computing device, a hypervisor on the host computing device, or another privileged execution mode of the host computing device. In some cases, the attacker has physical access to the host computing device and the peripheral device, and optionally is able to probe and tamper with the connections between components in the peripheral. The attacker may be a board-level adversary, taking the peripheral out of thermal, power, or clock limits to cause a bit flip.

[0027] In various examples, a tenant is a computing device, referred to as a client, that communicates with a host computing device over any appropriate communication network. A peripheral device is in or connected to a host computing device. Through careful design of peripheral devices as described herein, a trusted execution environment (TEE) can be created on the peripheral device to execute sensitive code and process sensitive data. In some examples, the TEE is designed to be secure against untrusted hosts and attackers who may have physical access to the peripheral as described above.

[0028] At least refer to Figure 4 and FIG. 5A to FIG. 5C Describe the design of the peripheral device and at least refer to Figure 6 Describes the creation of a TEE. In some examples, the peripheral is configured to prove to the tenant that sensitive code was installed on the peripheral as the tenant intended. At least reference Figure 7 Describes an example attestation process for a peripheral device.

[0029] There are references such as Figure 8 The key exchange process described. The key exchange process is useful for secure communication between tenants and the periphery. In some cases, the key exchange process is used to enable sensitive data from more than one party to be processed at the periphery and maintain confidentiality between the parties. In some examples, the parties are tenants. However, in some cases, the parties do not have access to the code to be executed on the periphery. In the case where the periphery is a peripheral device that supports resource isolation, the key exchange process is useful to enable more than one tenant to use the same periphery to execute different sensitive code and sensitive data while maintaining confidentiality between tenants. In some examples, multiple tenants and / or parties agree on the same code, and then they send different data sets to the periphery.

[0030] In some examples, there is a cryptographic protocol that enables sensitive data to be efficiently and securely transferred between two trusted entities via an untrusted intermediary. Fig. 9is described, and it is applicable to the following situations: one of the trusted entities is a tenant, the other trusted entity is a periphery, and the untrusted intermediary is a host. However, it is noted that the encryption protocol is broadly applicable to situations other than tenant and hosted periphery situations. The encryption protocol can be used to securely transfer sensitive data between any first trusted entity and any second trusted entity via any untrusted intermediary. In some cases, the first and second trusted entities are nodes in a telecommunications network, and the untrusted intermediary is a router, switch, or proxy in the telecommunications network. In some examples, the first and second trusted entities are a home personal computer and an Internet service provider server, and the untrusted intermediary is a home wireless access point. In some examples, the untrusted intermediary is a wireless hotspot device, and the trusted first entity is a smart phone, and the trusted second entity is a web server.

[0031] The security module at the second trusted entity operates in an unconventional manner to enable dynamic creation of a trusted execution environment at the second trusted entity. The security module operates in an unconventional manner to enable secure and efficient communication between its trusted execution environment and the trusted first entity via an untrusted intermediary.

[0032] The security module at the second trusted entity improves the functionality of the base peripheral device by creating a trusted execution environment at the peripheral device.

[0033] Figure 1 Three high-level entities are shown: a first trusted computing entity 100, an untrusted intermediary 108, and a second trusted computing entity 112. In most of the examples described herein, the first trusted computing entity 100 is a tenant, and the second trusted computing entity 112 is a peripheral to the untrusted intermediary 108. However, as described above, reference Fig. 9 The encryption protocol described is more generally applicable to Figure 1 . The first trusted computing entity is any computing device or trusted execution environment that is capable of storing sensitive code 102, storing sensitive data 104, encrypting 106 sensitive code and / or sensitive data, and communicating with an untrusted intermediary 108. In some examples, the first trusted computing entity is a trusted execution environment on an untrusted intermediary 108. The encryptor 106 of the first trusted entity both encrypts and decrypts the sensitive information.

[0034] Untrusted intermediary 108 is any computing device having memory 110 that is capable of receiving encrypted data from first trusted computing entity 100 and that is capable of communicating with a second trusted computing entity via a communication network or link. Memory 110 (which is any type of memory 110) stores at least encrypted code blocks and / or data blocks from the first trusted computing entity.

[0035] The second trusted computing entity 112 is any computing device that can isolate itself in a way to create a trusted execution environment for processing sensitive data using sensitive code. The second trusted computing entity 112 has one or more computing elements 114 for processing sensitive data using sensitive code. The computing element 114 is a processor, a parallel computing unit, or other computing element. The second trusted computing entity 112 has a memory 116 shared by the computing elements 114, and it has one or more encryption units 118. Each encryption unit 118 is capable of encrypting and decrypting information. The security module 120 of the second trusted computing entity 112 controls the process to create a trusted execution environment and provides proof to the first computing entity to prove one or more states at the second trusted computing entity 112. A non-exhaustive list of states to be proven at the second trusted computing entity 112 is: the hardware of the second trusted computing entity 112 is in a known state (such as having a cleared memory), a specific firmware is installed in the second trusted computing entity 112, and a specific sensitive code is installed in the second trusted computing entity 112.

[0036] Both the encryption unit(s) 118 at the second trusted computing entity and the encryptor 106 at the first trusted computing entity are configured to use an encryption protocol to encrypt blocks of sensitive code and / or data for transfer via an untrusted host. Any encryption protocol may be used that protects sensitive information from the host by encrypting blocks of sensitive information using a key and an initialization vector. Individual blocks are encrypted using a pair comprising an initialization vector and a key.

[0037] In some examples, the cryptographic protocol is a protocol that is particularly efficient in securely managing initialization vectors for the cryptographic protocol. The cryptographic protocol involves the first and second trusted computing entities reaching a prior agreement 122 on a parameterized function for obtaining the initialization vector in an efficient manner. The parameterized function calculates pairs of distinct initialization vectors for encryption and decryption of each sensitive information block. In contrast, using the same initialization vector for different sensitive information blocks may compromise their integrity and confidentiality. Using different initialization vectors for the same sensitive information block results in decryption errors, as described in more detail later in this document.

[0038] Despite Figure 1The example in shows a single untrusted intermediary 108 and a single second trusted computing entity 112, but there may be multiple such entities. In some examples, each untrusted intermediary 108 has multiple second trusted computing entities 112 connected to it, and the second trusted computing entities 112 are able to communicate with each other. In some examples, there are multiple untrusted intermediaries 108, which are optionally able to communicate with each other. Therefore, the technology can be extended to rack-scale scenarios, where there are multiple racks of untrusted intermediaries 108, each of which is responsible for multiple second trusted computing entities 112, which are able to communicate with each other.

[0039] Figure 2 2 is a schematic diagram of a computing node 200, which includes an untrusted host 204 and a trusted peripheral device 206 connected to the untrusted host 204. A plurality of such computing nodes 200 are deployed in a Figure 3 In the data center 300 shown in FIG. Figure 3 In the example, computing nodes 200 are interconnected using a communication network within data center 300, which is not shown in FIG. Figure 3 . A first tenant 302 including a computing device has a secure repository 306 of sensitive data and / or code. The first tenant 302 communicates with a data center 300. The first tenant 302 is able to securely copy sensitive code to a trusted execution environment on one or more trusted peripherals of a computing node 200 in the data center 300, and is able to receive the following proof from the peripheral: the sensitive code has been installed and the device is in a known state. The first tenant 302 is able to copy sensitive data to a trusted peripheral so that the sensitive data is processed in a trusted execution environment. In some examples, one or more other sources of secure sensitive data are also input to the code executed in the trusted execution environment. In this way, data from more than one party will be used for machine learning or other processing in a trusted execution environment.

[0040] In some examples, there is a second tenant 304 that includes a computing device in communication with the data center 300. The second tenant 304 has a secure repository 308 for sensitive code and / or data. As with the first tenant 302, the second tenant is able to copy sensitive code and data to one or more peripherals in the same peripherals in the data center. Using resource isolation mechanisms in the peripherals and using separate encryption keys for individual tenant code and data, the confidentiality of individual tenants can be maintained.

[0041] In some examples, the second tenant 304 has a secure repository 308 of sensitive data that is different from the sensitive data of the first tenant 302. Both the first tenant 302 and the second tenant 304 use the same sensitive code at the same peripheral device, and they send their respective different data sets to be processed by the same sensitive code.

[0042] Figure 3 The diagram is shown for a data center scenario. However, it can also be used in a standalone scenario or in other types of deployments. Figure 1 trusted and untrusted entities. In the example, Figure 1 Trusted entities and untrusted entities are used in edge deployments. Here, a first trusted computing entity 100, an untrusted intermediary 108, and a second trusted computing entity 112 are deployed at the edge of a communication network rather than in the cloud. The first trusted computing entity 100 is physically close to a data source such as a capture device or sensor, or has an integrated capture device or sensor that generates sensitive data 104. The first trusted computing entity 100 uses the untrusted intermediary 108 and the second trusted computing entity 112 to perform machine learning and / or reasoning near the source of the data stream, such as a capture device or sensor.

[0043] Figure 4 Such as Figure 1 Schematic diagram of a second trusted computing entity 112 of FIG. In some examples, the second trusted computing entity is a peripheral device of the host computing device, but this is not required.

[0044] The second trusted computing entity 112 includes one or more computing elements 114 and an optional memory 116. The memory 116 is shared by the computing elements or private to a specific computing element. The second trusted computing entity 112 has at least one cryptographic unit 118, which includes an encryption / decryption component 402, an optional key storage repository 404, and an optional buffer 406.

[0045] The encryption / decryption component 402 is configured to authenticate and decrypt data, which is received from the host and from other peripheral devices via any form of communication. In the example, direct memory access (DMA) requests are used for communication, but it is not necessary to use this form of communication. The encryption / decryption component 402 is configured to use authenticated encryption to encrypt data sent to the host or to other peripheral devices via DMA transfer (or other forms of communication). In some examples, the encryption / decryption component 402 is a logic block placed on a packaged die, where the periphery is a device package. In other examples, the encryption / decryption component is implemented on the package or as a software component on a programmable periphery. The encryption / decryption component 402 is connected to an optional buffer 406, and the buffer 406 is arranged to intercept and buffer communications to and from the host, such as DMA requests and responses. The buffer 406 is connected to a key repository 404 holding an extended encryption key, and is also connected to a peripheral component interconnect express (PCIe) complex. In some but not all examples, the second trusted computing entity supports a non-secure operating mode. In a non-secure operating mode of the peripheral device, the encryption / decryption component is bypassed.

[0046] The benefit provided by using buffer 406 is that more than one DMA request or response can be in flight at any time. In some cases, buffer 406 is omitted and one DMA request or response is issued at a time.

[0047] In a specific example (which is not intended to limit the scope of the technology), the encryption / decryption component 402 has support for AES or another encryption scheme, supports multiple key contexts, has an interface for specifying an authentication tag to be checked at the end of an encrypted data stream, and for retrieving the authentication tag at the end of a plaintext data stream.

[0048] The security module 120 in the second trusted computing entity 112 has an optional mode switch 408 (used when the second trusted computing entity 112 supports a non-secure mode), a certification component 412, an optional key exchanger 410, a secure data transfer component 414, and an optional parameter monitor 416. The security module is a logic block that is integrated with the peripheral device package. In one example, the security module is a system on chip (SoC) with a microcontroller, a static random access memory (SRAM) for code and data, and a read-only memory (ROM) for holding an initial boot block for the microcontroller. However, other implementations of the security module are also possible. The security module 120 includes logic blocks or software for operations such as: encryption and decryption of symmetric key authentication, secure hash calculation, public key generation, signing and authentication, and entropy sources. The security module 120 is connected to other components of the periphery using any suitable connector.

[0049] The security module 120 is configured to initialize the peripheral to a clean state and coordinate the encryption and decryption of data passed between the host and the peripheral and between the peripherals. The security module 120 contains a root endorsement key that is burned into the fuse of the security module 120 or generated using the hardware of the security module 120. The root endorsement key serves as a trust root suitable for generating attestation keys for attestation using a trusted certificate authority.

[0050] Mode switch 408 is arranged to switch the peripheral device between an unsecure mode, in which sensitive memory and sensitive registers of the peripheral device are accessible by entities external to the peripheral device, and a secure mode, in which sensitive memory and sensitive registers of the peripheral device are not accessible by entities external to the peripheral device. During secure mode, the security module configures the peripheral to enforce device-specific access control lists to prevent untrusted intermediaries from accessing unsecure functions. During secure mode, DMA and peripheral-to-peripheral communications are routed through the cryptographic unit(s) 118.

[0051] In some examples, there are one or more registers to which access rights are to be authenticated, such as registers containing addresses of sensitive code to be launched on the peripheral. Access to these registers is routed to the security module, which authorizes access and calls peripheral functions through different interfaces. The registers to which access rights are to be authenticated are exposed by the peripheral and serviced by the security module.

[0052] The optional key exchanger 410 is arranged to configure the cryptographic unit 118 with a key.

[0053] The security module 120 has an attestation component 412 for measuring application code running on the computing unit(s), generating a reference for remote attestation, and key exchange. A reference is data that acts as a certificate issued by a peripheral device for remote attestation, whereby a tenant can verify one or more security-critical properties of the peripheral device. The reference captures the security-critical properties of the peripheral. In a non-limiting example, the reference is calculated as a hash.

[0054] The security module 120 has a secure data transfer component 414 that generates DMA requests to transfer data from the host directly or indirectly into a security module memory such as SRAM or other memory.

[0055] The optional parameter monitor 416 is arranged to monitor thermal, power, and clock parameters of the security module 120. The parameter monitor 416 is arranged to issue a reset if one or more of the parameters are outside of a safe range, and to hold the reset line until the security module 120 receives notification that the peripheral has been fully reset. The reset state is maintained in memory on the security module 120, and the logic for sending a reset is implemented using software or using a hardware state machine. The security module 120 uses a dynamic random access memory (DRAM) word with a parity bit and an on-die temperature sensor to check whether the peripheral is operating outside of the specified power and temperature ratings.

[0056] The identity of the second trusted computing entity 112 is based on an endorsement key, which is created or provided on the chip during manufacturing, in the case where the second trusted computing entity 112 is a device package including a chip. The private endorsement key never leaves the chip, and the public key is used for certification and is called a certification key. There are different ways to provide endorsement keys of varying complexity and security, two of which will now be described.

[0057] In the first approach, the manufacturer of the trusted second entity has facilities for securely generating an endorsement key pair, burning the private endorsement key into a fuse in each device, and providing a certificate for the public key to a trusted certificate authority. A disadvantage of this approach is that the manufacturer has access to the private endorsement key. Another disadvantage is that it introduces complexity and cost to the manufacturer.

[0058] In the second method, an endorsement key is generated on a second trusted computing device using a combination of a physical unclonable function (PUF) and a fuzzy extractor. PUF is based on physical changes that occur naturally during semiconductor manufacturing and make it possible to distinguish between otherwise identical semiconductors. Using a fuzzy extractor, the PUF will generate the same key each time it is evaluated using a given input. Typically, the PUF will be used by trusted firmware during a secure boot process to first generate a secret key, and then generate and output the corresponding public key. The manufacturer of the trusted second computing device can trigger this process for each device and issue a certificate for the public key without having to access or maintain a private key. Another advantage is that the mechanism enables physical proof, that is, anyone with physical access to the device (such as an auditor) can obtain the public key and issue a certificate.

[0059] Once the certificate authority has received the endorsement key certificate, it issues the certificate. The relying party uses the certificate to ascertain the integrity of messages from the trusted second computing device. The certificate authority also maintains a revocation list containing devices that have been misplaced, deactivated, or may have been compromised. The certificate authority stops issuing certificates for such devices.

[0060] Enclave attestation services can be used by Figure 1 The enclave attestation service accepts a reference from an enclave, such as a trusted execution environment on a second trusted computing device. The enclave attestation service generates a signed token that can be forwarded to other services to release secrets. The release of secrets is governed by a policy. The policy uses criteria such as attributes in the reference (such as a measure of the state of the second trusted computing device). The attestation service checks the policy against the reference. The attestation service supports multiple trust models, such as trusting all references from a specified manufacturer, or trusting a reference if the service has a valid public endorsement key. In some cases, the token generated by the attestation service can carry information about the geographic location of the device. In some cases, the PCK certificate is packaged with the reference and forwarded to the attestation service.

[0061] There are various options for where to place the security module 120 in the peripheral device package. Figure 5A In the first depicted option, the security module 504 is located on the same die 506 as the computing element 502 and the cryptographic unit(s) 118. For clarity, the cryptographic unit is not shown in FIG. Figure 5A 5 and is positioned with computing element 502. The first option has strong security because if an attacker accesses or tampers with the secrets within the security module, he or she will compromise the functionality of the entire package. Since the security module is on the die, the first option provides good performance.

[0062] The second option is Figure 5B 508 and includes integrating the security module 514 into the same multi-chip module as the peripheral package 508. Here, the computing element 510 and the encryption unit 118 ( Figure 5B The second option is a schematic diagram of an embodiment of the present invention. ...

[0063] The third option is Figure 5C , and includes placing the security module 524 on a separate chip outside the package. In a third option, there is a first package 518 that includes a computing element 520 and an encryption unit 118 (for clarity, in Figure 5C). There is also a second package 522 including a security module 524. The first package and the second package are connected to each other. The third option decouples the security module from the rest of the peripheral device package and thus facilitates manufacturing.

[0064] Initialization of the second trusted computing device is now described.When the second trusted computing device boots or resets, the security module will go through a boot sequence.

[0065] During the boot sequence, the security module loads the firmware from the ROM, checks whether the firmware is correctly signed and measures the firmware. The measurement results are securely stored in the security module.

[0066] The security module firmware is split into two components, (a) a component responsible for critical tasks such as checking signatures, measurements, and attestation key generation, and (b) a component responsible for other tasks such as reference generation, and encryption / decryption of direct memory access traffic. The first component is security-critical, as small as possible, and rarely changes. The second component has no write access to secrets such as firmware measurements and private endorsement and attestation keys.

[0067] After booting, the security module is requested to generate a new attestation key (AK). The corresponding private key AKpriv is securely stored in the non-volatile memory of the security module. Alternatively, the attestation key is derived from the PUF using the firmware trusted computing base as an initialization vector. This avoids the need to store the attestation key. However, this limits the frequency of refreshing the attestation key to refresh the firmware update.

[0068] Reference now Figure 6 Given a security module (such as Figure 1 and Figure 4 600 . The peripheral device is in an unsecure mode, where the host device is able to access or tamper with sensitive code and / or sensitive data on the peripheral device. The security module 120 checks 602 whether to switch to secure mode. If not, it remains in unsecure mode. If the security module 120 receives a command from the tenant to create a TEE, it switches to secure mode.

[0069] In order to switch to the secure mode, the security module 120 disables 604 external access to sensitive memories and registers in the peripherals, and places the hardware elements of the peripherals in a known state. In the example, the security module 120 disables read and write access to the SRAM in the security module 120 through memory mapped input / output (MMIO). The security module 120 instructs the peripheral to disable access to any security-sensitive memories and control registers through MMIO. In secure mode, access to registers or memories in the security module 120 is maintained for the correct function of the peripherals, where those registers or memories do not hold security-sensitive information. Access to those registers or memories is routed to the security module, which checks whether the access is authorized by the tenant. After disabling access through MMIO, the security module 120 places the memory of the peripherals in a known state, such as by resetting the peripherals and resetting the memory of the peripherals by writing zeros.

[0070] As reference Figure 7 In more detail, once in secure mode, the security module 120 receives 606 sensitive code from the tenant. The host can request a reference from the security module and provide the reference to the tenant. The reference acts as a certificate issued by the peripheral device for remote attestation so that the tenant verifies whether the sensitive code is properly installed at the peripheral device.

[0071] The security module computes 608 evidence and sends the evidence to the tenant. The reference captures the security-critical properties of the peripheral. In a non-limiting example, the reference is computed as a hash of the following: security module, debug mode, and an attribute called a host access flag signed with a proof key. The host access flag indicates whether the host has read / write access rights to the block memory through MMIO. In some examples, the reference contains external data, such as a hash of a new data encryption key, which is generated by the security module and encrypted using the tenant's public key. In another example, the reference contains a hash of a public key that the tenant can use to encrypt / wrap a tenant-defined symmetric key and provision it to the peripheral.

[0072] The quote is signed using the peripheral's attestation key generated from the peripheral's root of trust. The quote forms the following PKI-like certificate chain:

[0073] A reference signed using the certification key;

[0074] An attestation key certificate signed using the peripheral device's root endorsement key;

[0075] An endorsement key certificate signed using the peripheral device's root endorsement key;

[0076] The self-signed root endorsement key that issued the certificate.

[0077] The reference can be verified by any entity (such as an attestation service) that has the following artifacts:

[0078] An endorsement key certificate issued by the manufacturer of the peripheral device;

[0079] Such as revocation lists applicable to certificates;

[0080] Current Trusted Computing Base Metrics for Peripheral Device Firmware.

[0081] Current trusted computing base metrics enable checking that the peripheral device issuing the reference is running the latest version of firmware, and revocation lists are used to check if the reference from the device is invalid (due to device failure, being deactivated, destroyed or for other reasons).

[0082] For embodiments where sensitive data from more than one party will be processed by the same sensitive code on the peripheral device, or for embodiments where there are multiple tenants using the same peripheral device (the code and data of those tenants are isolated using resource isolation on the peripheral device), the security module optionally implements a key exchange process 610. This will be discussed later in detail. Figure 8 Explain the key exchange process in more detail.

[0083] The security module implements secure data download 612, execution, and output by downloading sensitive data from the tenant, processing the sensitive data on the peripheral device using sensitive code, and outputting the results to the tenant via the host. In some examples, the secure data download involves the tenant encrypting a block of data and sending the encrypted block to the peripheral device via the host. In some examples, the secure data download involves the tenant encrypting a block of data, copying the encrypted block to the host, and then the peripheral retrieving the encrypted block from the host. Any suitable encryption protocol is used. In the example, a particularly effective encryption protocol is used, which is referred to below Fig. 9 To output the result to the tenant via the host, the encryption unit 118 encrypts the block of output data and sends it to the tenant via the host. In some examples, Fig. 9 An encryption protocol (which is symmetric) is used both for downloading data to the peripheral device and for sending the output results back to the tenant.

[0084] The security module checks 614 whether the trusted execution environment is to be terminated. If so, the security module erases 616 the peripheral and returns to non-secure mode 600. When the TEE is explicitly terminated, or the peripheral receives a reset signal from the host, the security module deletes all sensitive data and returns the peripheral to a clean state. This includes resetting memory on the peripheral, deleting any keys, unblocking MMIO access, and switching to non-secure mode. If the peripheral undergoes a power cycle, it restarts in a clean state regardless of which mode it was in.

[0085] Reference now Figure 7 Give about Figure 6 608. The remote attestation process has the advantage of using simple hardware compared to embodiments in which an untrusted host copies sensitive code into a peripheral device memory and, when creating a TEE, adds support in the peripheral device memory to measure the memory contents.

[0086] Figure 7 is a message sequence diagram showing messages (represented by horizontal arrows) being passed between a first trusted entity 100 represented by a vertical line on the left side of the diagram, an untrusted intermediary 108 represented by a vertical line in the center of the diagram, and a second trusted entity 112 represented by a vertical line on the right side of the diagram. The relative vertical positions of the arrows in the diagram represent the temporal order of the messages.

[0087] A first trusted entity 100, such as a tenant, generates 700 a program encryption key (PEK) for encrypting application code. The tenant has sensitive code to be copied to a peripheral device. The tenant calculates an authentication tag 702 on the binary of the sensitive code, and it uses the PEK to encrypt 704 the sensitive code. In some cases, the authentication tag is a message authentication code (MAC).

[0088] The first trusted entity 100 (such as a tenant) sends a request 706 to the untrusted intermediary 108 to request the creation of a TEE at the second trusted entity 112 (such as a peripheral device). The request 706 includes the authentication tag calculated for the sensitive code at operation 702. The host forwards the request to create the TEE to the second trusted entity 112, and the second trusted entity (such as a peripheral device) is as described above with reference to Figure 6 The TEE 708 is created as described in operation 604 of the second trusted entity 112. After the TEE is created, the security module of the second trusted entity 112 resets the cryptographic unit(s) of the peripheral device and switches the security module to a mode in which the security module computes an authentication tag running on all memory blocks at the peripheral device.

[0089] The second trusted entity 112 generates a reference to indicate that a TEE has been formed, and it includes the authentication tag in the reference. The reference including the authentication tag is sent 710 from the second trusted entity 112 to the first trusted entity 100 (e.g., tenant). The first trusted entity 100 verifies 712 the reference and checks whether the authentication tag included in the reference matches the authentication tag calculated at operation 702. If the verification is successful, the first trusted entity 100 provides 714 the PEK to the second trusted entity 112. In the example, the PEK is provided 714 to the security module of the second trusted entity by encrypting the symmetric key using the public key included in the reference.

[0090] The first trusted entity 100 copies 716 the encrypted code to an untrusted intermediary 108 (such as a host), and the untrusted intermediary 108 loads 718 the encrypted binary at a specified virtual address of its physical memory.

[0091] The second trusted entity 112 issues a DMA request 720 to the untrusted intermediary 108 to copy the code from the memory of the untrusted intermediary 108 to the memory at the second trusted entity 112. A response including the encrypted blocks 722 is received from the untrusted intermediary 108. The response 722 passes through the cryptographic unit(s) at the second trusted entity 112, which decrypts 724 each code block and computes 726 an authentication tag over the entire code sequence.

[0092] Once the DMA request 720 is completed (to transfer the complete sensitive code), the security module of the second trusted entity 112 checks 726 whether the authentication tag of the transferred sensitive code matches the authentication tag specified when the TEE was created. If there is a match, the security module of the second trusted entity switches the cryptographic unit(s) of the second trusted entity 112 to a default mode 730, in which the cryptographic unit(s) of the second trusted entity 112 are in compliance with the TEE. Fig. 9 The first trusted entity 100 and the second trusted entity 112 use an encryption protocol to transfer data between the first trusted entity 100 and the second trusted entity 112. If there is no match, the second trusted entity terminates 732 the TEE.

[0093] In some examples, there are references to Figure 8 Explain the key exchange process. Multiple keys are used when different data streams are encrypted with different keys. For example, the input data stream, the output data stream, and the checkpoints can be encrypted with different keys. Checkpoints are intermediate results computed by sensitive code while processing sensitive data, and which are encrypted and stored on an untrusted intermediary. Checkpoints are useful for restoring state and reusing computations. Figure 8 The key exchange process has the advantage of not requiring programmability of the security module. Programmability of the security module is a facility that an attacker can exploit to run arbitrary code on the security module and potentially leak secrets such as attestation keys.

[0094] In the example, Figure 8 The key exchange process is a protocol built into the firmware of the security module of the trusted second device 112. One or more key hierarchies are also built into the firmware of the security module. This provides a balance between cryptographic agility and security, because the protocol and key hierarchy can be upgraded by upgrading the firmware.

[0095] Figure 8 The key exchange process securely supplies a set of K symmetric keys DEK_1 . . . DEK_K to each trusted second device 112 , wherein the keys are used for different data streams.

[0096] The trusted second entity 112 creates 802 a TEE. The untrusted intermediary 108 (e.g., a host) obtains 800 the number of users K and specifies 804K user public signature keys, represented as UKpub_1, ... UKPub_K, where each public key belongs to a participating user (such as a data stream or a tenant). In response, the security module of the trusted second entity 112 generates 806 a new key pair called a wrapping key (WK) when the TEE is created, securely stores 808 WKpriv in a secure volatile storage in the security module, and writes 810 the public key WKpub to a memory at the untrusted intermediary 108. When the untrusted intermediary 108 requests 812 a reference, the reference is calculated 814 on WKpub and contains a measurement of a set of public keys UKpub. The reference is calculated by the trusted second entity 112 and sent to the untrusted intermediary using a message 816. The untrusted intermediary 108 uses 818 the reference to retrieve K different symmetric encryption keys from different users of the key management service account. The user / key management service receives the reference and verifies 820 the reference. If the reference is invalid, the process ends 822. If the reference is valid, the trusted first entity 100 encrypts 824 the private key using WKpub and signs the result using its UKpriv. This ensures that the private key is only decrypted by the security module. The untrusted intermediary 108 then provides 826 the wrapped symmetric key to the security module with index j in (1, K). The security module checks 828 the signature of the encrypted key using UKpub_j. If the signature verification is successful, it decrypts 830 the key and stores the key in a map. Once all K symmetric keys have been deployed, the security module supplies 832 these keys to (multiple) encryption units.

[0097] Fig. 9 is a message sequence diagram for a cryptographic protocol, which in some examples consists of Figure 1The trusted first entity 100 and the trusted second entity 112 use the trusted first entity 100 and the trusted second entity 112. The trusted first entity 100 and the trusted second entity 112 agree in advance 900 that the initialization vector of the encryption protocol will only be used once for the encryption key and the data set; that is, they agree to a single use of the initialization vector. The trusted first entity 100 and the trusted second entity 112 also agree in advance on a parameterized function for obtaining the initialization vector. In some embodiments, the parameterized function takes a single parameter that is a virtual address, and the function is an identity function so that the virtual address is used as the initialization vector. In other embodiments, the parameterized function takes a parameter such as a program state. The parameterized function calculates one or more of the following: a virtual address, a key, a counter. Therefore, it is not necessary that the parameterized function is an identity function. Because the trusted first entity 100 and the trusted second entity 112 have agreed in advance on the function for obtaining the initialization vector, the protocol is very efficient because no complex scheme is required to manage the initialization vectors, ensure that they are unique, and pass them between the trusted first entity 100 and the trusted second entity 112. The initialization vector and key are calculated from parameterized functions prior to the encryption 904 and decryption 914 operations, as now referred to Fig. 9 Explained.

[0098] The trusted first entity 100 divides the sensitive information to be passed to the trusted second entity 112 into a plurality of blocks. It encrypts the blocks using an initialization vector and a key 904. The individual blocks are encrypted using a pair comprising an initialization vector and a key. Due to the prior agreement on the single use of the initialization vector, the individual blocks are encrypted using a unique pair. In this way, the encryption is secure. In contrast, if the initialization vector is used more than once, there is a risk that a malicious party could obtain sensitive data or compromise the integrity of the computation, for example, by replacing a data sample with another data sample encrypted using the same initialization vector.

[0099] The trusted first entity copies 906 the encrypted block to memory at the untrusted intermediary 108. The untrusted intermediary 108 stores the encrypted block in its physical memory, and the physical memory location of the block has a virtual address according to the mapping between physical and virtual memory locations. The potentially available virtual addresses are very large because their domain is large enough to enable sensitive code to run large calculations while still using each virtual address only once.

[0100] The trusted second entity 112 includes at least one cryptographic unit 118 and at least one computing unit 114. The computing unit 114, when it begins executing code to process data in an encrypted block, requests the block from the untrusted intermediary 108 using a DMA request 910 and the parameters of a pre-agreed function. The untrusted intermediary 108 receives the request 910, and it calculates an initialization vector for the requested block. The untrusted intermediary looks in its memory to find the appropriate encrypted block from the trusted first entity 100, and retrieves the appropriate encrypted block.

[0101] The encryption unit 118 at the trusted second entity decrypts 914 the retrieved block and sends the result to the computing unit 114. The computing unit knows the original initialization vector associated with the request it made at operation 910. Based on the initialization vector from operation 910, the computing unit is expected to be able to check the result it received from the decryption. If the check passes, the computing unit 114 continues to use the decrypted data; otherwise, it rejects the decrypted data.

[0102] As described above, in some cases, the pre-agreed function is such that the virtual address of the encrypted block at the untrusted intermediary 108 is the initialization vector. In this case, the trusted first entity 100 uses the virtual address of the block as the initialization vector when encrypting the block, and never reuses the same virtual address to encrypt another block using the same key. This ensures that there is only one block encrypted using the same initialization vector and key. The trusted second entity 112 uses the virtual address of the block as the initialization vector when encrypting the block before writing it to the untrusted intermediary 108. The application running on the trusted second entity 112 is configured not to reuse the same virtual address to write two different blocks of data.

[0103] The benefit of using a virtual address as the initialization vector is that the application running on the compute unit 114 is an oracle of the data blocks to be read and written. The sequence of addresses generated by the application for the virtual address space uniquely defines the sequence of blocks to be read from the host. The combination of checking the authenticity of the input block and then checking to ensure that the initialization vector included in the header of the block matches the virtual address is sufficient to ensure the integrity of the input data stream. The authentication and initialization vector checks are sufficient to ensure the integrity of the output stream.

[0104] In some examples, Fig. 9 The protocol also derives an encryption key identifier from the virtual address. The virtual address space at the untrusted intermediary 108 is divided into K regions. In an example, some but not all of the bits of the virtual address are used as a key identifier. The key identifier is used to look up a list of keys that are used during a key exchange process (such as, Figure 8The encryption unit 118 at the trusted second entity 112 expects to use the same encryption key to encrypt blocks with the same bits. The encryptor at the trusted first entity 100 encrypts blocks with the same bits using the same key.

[0105] In some examples, for each encrypted block, the trusted first entity 100 places a header containing an authentication tag and an initialization vector in the data stream following the block. The data stream is formed by a sequence of blocks of data to be copied from the trusted first entity 100 to the untrusted intermediary 108. The use of a header holding an authentication tag and an initialization vector ensures that the tag, initialization vector, and data are read and written together as part of the same DMA request. In an embodiment using a buffer 406, in the case of using a header, the trusted second entity 112 is able to authenticate any data block it receives, and is able to authenticate and decrypt multiple blocks in parallel. In the case where the buffer 406 is omitted, the authentication and decryption of the blocks occur one after another. Any suitable component of the peripheral device is arranged to take into account the additional space used by the header (such as when the peripheral generates a DMA request). Any suitable component of the peripheral device is arranged to take into account that the data returned from the untrusted intermediary 108 in response to the DMA request will be less than the requested size. The trusted second entity 112 checks the initialization vector included in the header before using the data.

[0106] The buffer 406 (in the security module) is arranged to intercept and buffer DMA requests and responses as described above, and pass them to the encryption / decryption component 402.

[0107] In some examples, buffer 406 stores DMA responses until the entire DMA response is ready to be decrypted. This reduces complexity at encryption / decryption unit 402 because complex state for multiple inbound responses does not need to be maintained. Buffer 406 is not needed in cases where it is possible to guarantee that there will be no externally observable side effects from a peripheral device processing incorrect data while a DMA response is in transit. This can be achieved by providing a barrier so that no outbound DMA is issued until all inbound DMA responses have arrived.

[0108] In some examples, in addition to (or instead of) storing the DMA response until the entire DMA response is ready to be decrypted, the buffer maps from the request to the initialization vector, as now described. For a DMA write request, the buffer extracts the initialization vector from the outbound write request and uses it to retrieve the encryption key from the key repository. The buffer then routes the payload along with the initialization vector and key to the encryption / decryption component 402. The buffer 406 uses the encrypted payload, the authentication tag, and the initialization vector to construct a new payload request, which is sent to the untrusted intermediary 108.

[0109] Decrypting DMA responses from host memory to peripheral memory is challenging for three reasons: first, DMA responses from the host are sometimes split into multiple chunks; second, there may be multiple DMA requests in transit at any point in time; and third, DMA responses do not contain a key identifier.

[0110] For each DMA request, the buffer 406 maintains a small amount of state in the peripheral device. The buffer 406 extracts the key identifier and destination address from each outgoing read request, and stores the key identifier and destination address pair in a map that tracks the source address and destination address pair and the DMA size. When the first DMA response to a request is received, the buffer 406 uses the destination address to find the source initialization vector address (IVA). It uses the source initialization vector address to retrieve the encryption key. It creates a new context in the encryption unit 118 and forwards the encryption key, initialization vector (obtained by extending the IVA), and the encrypted payload. It forwards the subsequence DMA response to the encryption unit 118. If authentication and decryption are successful, the buffer 406 forwards the response to the computing element 114. Once the entire response to the request has been received, the buffer 406 stops tracking the request.

[0111] The encryption unit 118 has a key storage repository, such as a block of SRAM or a register file, to hold encryption keys. The keys are stored in a map that is indexed using the high-order bits from the initialization vector address. After key exchange, the map is supplied by the security module.

[0112] Fig.10 Various components of an exemplary computing-based device 1000 are illustrated, which is implemented as any form of computing and / or electronic device and, in some examples, implements embodiments of an untrusted intermediary or a first trusted computing entity therein.

[0113] The computing-based device 1000 includes one or more processors 1004, which are microprocessors, controllers, or any other suitable type of processor for processing computer-executable instructions to control the operation of the device, such as to implement cryptographic protocols or to host peripheral devices. In some examples, such as where a system-on-chip architecture is used, the processor 1004 includes one or more fixed function blocks (also referred to as accelerators) that are implemented in hardware (rather than software or firmware). Fig. 9 A computing-based device is provided with platform software including an operating system 1006 or any other suitable platform software to enable application software 1008 to be executed on the device. A data repository 1010 holds initialization vectors, keys, encrypted data blocks, or other information. The computing-based device 1000 is Figure 1 In the case of the first trusted computing entity, the encryption protocol 1012 is stored in the memory 1002.

[0114] Computer executable instructions are provided using any computer readable medium accessible by the computing-based device 1000. For example, computer readable media include computer storage media such as memory 1002 and communication media. Computer storage media such as memory 1002 include volatile and non-volatile, removable and non-removable media, which are implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules, etc. Computer storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electronic erasable programmable read-only memory (EEPROM), flash memory or other storage technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other non-transmission medium for storing information for access by a computing device. In contrast, communication media embodies computer readable instructions, data structures, program modules, etc. in a modulated data signal such as a carrier wave or other transmission mechanism. As defined herein, computer storage media do not include communication media. Therefore, computer storage media itself should not be interpreted as a propagation signal. Although computer storage media (memory 1002) is illustrated as being within computing-based device 1000, it will be appreciated that in some examples the storage is remotely distributed or located and accessed via a network or other communications link (eg, using communications interface 1014).

[0115] In the case where the computing-based device is a first trusted computing entity, the communication interface 1014 enables the computing-based device 1000 to communicate with an untrusted intermediary (such as Figure 1In the case where the computing-based device 1000 is an untrusted intermediary, a peripheral device (such as Figure 4 Peripheral devices) are hosted by computing-based device 1000.

[0116] The computing-based device 1000 also includes an input / output interface 1016, which is arranged to output display information to a display device, which may be separate from or integrated into the computing-based device. The display information may provide a graphical user interface. The input / output interface 1016 is also arranged to receive and process input from one or more devices, such as a user input device (e.g., a mouse, keyboard, camera, microphone, or other sensor).

[0117] Techniques include any combination of the following examples:

[0118] A peripheral device for use with a host computing device, the peripheral device comprising:

[0119] one or more computing elements;

[0120] a security module configured to form a trusted execution environment on the peripheral device for processing sensitive data using sensitive code, wherein the sensitive data and the sensitive code are provided by a trusted computing entity in communication with the host computing device;

[0121] at least one cryptographic unit configured to encrypt and decrypt data passed between the trusted execution environment and the trusted computing entity via the host computing device;

[0122] The security module is configured to compute and send a proof to a trusted computing entity to prove that the sensitive code is in a trusted execution environment.

[0123] By having a cryptographic unit on a peripheral device rather than on a host, sensitive data can be securely and efficiently decrypted when it is received from a trusted entity for processing by sensitive code. The cryptographic unit can also securely and efficiently encrypt the output of the sensitive code before it is sent to the host and / or trusted computing entity. How to deploy the cryptographic unit on a peripheral device rather than on a host is not straightforward because of the ability to have a trusted execution environment on the peripheral device and the ability to switch between trusted and untrusted operating modes of the peripheral device.

[0124] The peripheral device described above uses direct memory access requests and responses to transfer data between the trusted execution environment and the trusted computing entity, which provides an effective and efficient way to transfer data.

[0125] The peripheral device described above, wherein the security module is configured to form a trusted execution environment by switching the peripheral device from a non-secure mode to a secure mode, in which it is possible to access peripheral memory and registers via a linear address space, and in secure mode, access to peripheral designated memory and designated registers via a linear address space is disabled. In some cases, the linear address space is shared or partially shared. In some cases, the linear address space is implemented using memory-mapped input-output. By having a secure operating mode and a non-secure operating mode, the peripheral device is universal. The secure operating mode limits some functions of the peripheral device and is generally more resource-intensive than the non-secure mode. Therefore, the ability to switch between modes enables the secure mode to be used only when needed. However, it is noted that the non-secure operating mode is omitted in some examples, and in this case, there is no mode switching between the secure operating mode and the non-secure operating mode.

[0126] A peripheral device as described above, wherein the security module is configured to switch the peripheral device to a secure mode in response to a request from a host device. In this way, the host device can create a trusted execution environment on the peripheral when needed using a simple request. A peripheral device as described above, wherein the security module is configured to exchange keys with a first trusted computing entity and supply keys provided by the first trusted computing entity to at least one cryptographic unit. Exchanging and supplying keys in this manner supports the ability to securely communicate between the peripheral device and the first trusted computing entity.

[0127] A peripheral device as described above, wherein the security module is configured so that when the peripheral device is in secure mode, if a request for a reference is received from a host, the security module computes a reference that captures the security-critical properties of the peripheral device and returns it to the host. In this way, the peripheral device can demonstrate security-critical properties in a simple and efficient manner.

[0128] A peripheral device as described above, wherein the security module is configured to compute the attestation by computing a reference, the reference being a hash of the security module and additionally being a hash of zero or more of: a debug mode, a host access flag, a hash of a new data encryption key, the new data encryption key being generated by the security module and encrypted using a public key of a trusted computing entity. In this way, a reference can be computed which gives an accurate indication of the nature of the peripheral. The reference enables a potential remote entity to verify the state of the peripheral before deciding whether to trust it.

[0129] The peripheral device described above, wherein the security module is configured to calculate the attestation by calculating a reference including a certificate, the certificate following a certificate chain, the certificate chain including: a reference signed using an attestation key, an attestation key certificate signed by an endorsement key, an endorsement key certificate signed using a root key, a self-signed root endorsement key that issued the certificate. By using a certificate following a certificate chain, security is enhanced.

[0130] The peripheral device described above, wherein the cryptographic unit comprises a key storage repository, a buffer and an encryption / decryption component, is a simple and effective design for a compact cryptographic unit.

[0131] The peripheral device described above, wherein the buffer is configured to intercept and buffer direct memory access requests and responses sent between the trusted execution environment and the host. By buffering the requests and responses, the rate of operation of the encryption / decryption unit can be controlled.

[0132] The peripheral device described above, wherein the buffer is configured to: when it intercepts a direct memory access write request, extract an initialization vector from the direct memory access write request, and use the initialization vector to retrieve the encryption key from the key repository. This supports efficient key exchange.

[0133] The peripheral device described above, wherein the buffer is configured to: route the payload of the direct memory access write request together with the initialization vector and the retrieved encryption key to the encryption / decryption component. In this way, the encryption / decryption component has items for encryption or decryption.

[0134] The peripherals described above are formed as a package where the security module is on-die with one or more computing elements, or off-die of one or more computing elements. The on-die option provides enhanced security but is complex to manufacture. The off-die option provides greater flexibility in the design, testing, and manufacture of the peripherals. In some cases, the peripheral is on-package, and in some cases, it is off-package. The on-package option provides more security.

[0135] The peripheral device described above is formed as a plurality of connected packages. In this case, the manufacturing cost increases due to the formation of two packages, but the design, testing and manufacturing are simplified due to the use of two packages. Forming the peripheral device as a plurality of packages provides enhanced safety compared to using an out-of-package arrangement.

[0136] A peripheral device as described above, wherein the encryption unit has multiple keys so that different data streams are encrypted using different keys, and wherein a key exchange process is used to supply the encryption unit with multiple keys. Using different keys in this way enables sensitive data from more than one source to be processed by sensitive code at the peripheral device.

[0137] The peripheral device described above, wherein the security module is configured to isolate resources of the peripheral device to create a secure channel on the peripheral device, and wherein different encryption keys are used for different secure channels. Where resource isolation is available on the peripheral, it is possible to have multiple tenants using resources of the same peripheral, and the work of the respective tenants can be kept separate.

[0138] The peripheral device described above, wherein the security module is configured to compute a reference containing measurements of a plurality of public keys, which have been specified by the host computing device as part of a key exchange process. References are an efficient way to support key exchange.

[0139] The peripheral device described above, wherein the security module is configured to receive an encrypted private key from an entity that has authenticated the reference.

[0140] A peripheral device as described above, wherein at least one cryptographic unit and a trusted computing entity are configured to: use a cryptographic protocol for encrypting blocks of data, each block being encrypted using a pair comprising a key and an initialization vector, and wherein the cryptographic unit and the trusted computing entity agree that each initialization vector is used only once with a given key; and wherein the initialization vector is calculated according to a parameterized function known to the cryptographic unit and the trusted computing entity.

[0141] A peripheral device for use with a host computing device, the peripheral device comprising:

[0142] one or more computing elements;

[0143] a security module configured to form a trusted execution environment on the peripheral device for processing sensitive data using sensitive code, wherein the sensitive data and the sensitive code are provided by a trusted computing entity in communication with the host computing device;

[0144] at least one cryptographic unit configured to encrypt and decrypt data passed between the trusted execution environment and the trusted computing entity via the host computing device;

[0145] The cryptographic unit is configured to use a cryptographic protocol in which an initialization vector is calculated according to a parameterized function known to the cryptographic unit and the trusted computing entity. Using the parameterized function gives a particularly efficient way to manage the initialization vectors to ensure that each initialization vector is used only once with a given key.

[0146] A data center, comprising:

[0147] A plurality of computing nodes, each computing node comprising a host computing device having at least one peripheral device, the peripheral device comprising:

[0148] one or more computing elements;

[0149] a security module configured to form a trusted execution environment on the peripheral device for processing sensitive data using sensitive code, wherein the sensitive data and the sensitive code are provided by a trusted computing entity in communication with the host computing device;

[0150] At least one cryptographic unit configured to encrypt and decrypt data passed between the trusted execution environment and the trusted computing entity via the host computing device. As a result of the peripheral device, the resulting data center gives significant computing power, and it enables sensitive code and data to be processed on the peripheral device on behalf of the tenant even if the sensitive code and data are passed to the peripheral device via an untrusted host. In some examples, a single trusted execution environment can be formed across multiple peripheral devices of the host computing device. The multiple peripheral devices can be any subset of the peripheral devices of the host computing device.

[0151] A method for securely transferring data between a first trusted computing entity and a second trusted computing entity via an untrusted intermediary, the method comprising:

[0152] encrypting the block of data at the first trusted computing entity using, for each block, a pair comprising a key and an initialization vector;

[0153] Make the first trusted computing entity and the second trusted computing entity agree in advance that the initialization vector is used only once;

[0154] storing, at the first trusted computing entity, a parameterized function for obtaining an initialization vector, the parameterized function being known by the second trusted computing entity;

[0155] The encrypted block of data is copied from the first trusted computing entity to the virtual address space of the untrusted intermediary to enable the second trusted computing entity to retrieve the block by making a direct memory access request.

[0156] A method as described above, wherein the virtual address space is targeted by code installed in a trusted execution environment at the second trusted computing entity.

[0157] A method as described above, wherein the parameterized function is an identity function such that the virtual address is an initialization vector.

[0158] The method as described above, wherein at least one parameter of the parameterized function includes a program state of code installed in a trusted execution environment at the second trusted computing entity.

[0159] In the method as described above, the second trusted computing entity includes an encryption unit and a computing unit.

[0160] A method as described above, wherein the virtual address of the block is used as an initialization vector.

[0161] The method as described above, wherein for each encrypted block, the first trusted computing entity places a header including an authentication tag and an initialization vector in a data stream following the block.

[0162] The method as described above includes: at the second trusted computing entity, receiving a header for each encrypted block, and authenticating the block using the header.

[0163] The method as described above includes authenticating and decrypting a plurality of blocks in parallel at the second trusted computing entity.

[0164] The method as described above includes taking into account, at the second trusted computing entity, the additional space used by the header when generating the direct memory access request.

[0165] The term 'computer' or 'computing-based device' is used herein to refer to any device having processing capabilities to enable it to execute instructions. Those skilled in the art will appreciate that such processing capabilities are incorporated into many different devices, and thus the terms "computer" and "computing-based device" each include personal computers (PCs), servers, mobile phones (including smartphones), tablet computers, set-top boxes, media players, game consoles, personal digital assistants, wearable computers, and many other devices.

[0166] In some examples, the methods described herein are performed by software in a machine-readable form on a tangible storage medium, for example in the form of a computer program including computer program code means adapted to perform all operations of one or more methods described herein when the program is run on a computer, and wherein the computer program may be embodied on a computer-readable medium. The software is suitable for execution on a parallel processor or a serial processor, such that the method operations may be performed in any suitable order or simultaneously.

[0167] This recognizes that software is a valuable, separately tradable commodity. It is intended to include software that runs on "dumb" or standard hardware, or controls "dumb" or standard hardware to perform a desired function. It is also intended to cover software that "describes" or defines the configuration of hardware, such as HDL (Hardware Description Language) software, which is used to design silicon chips, or to configure general-purpose programmable chips to perform a desired function.

[0168] Those skilled in the art will recognize that the storage device for storing program instructions is optionally distributed across a network. For example, a remote computer can store an example of a process described as software. A local or terminal computer can access the remote computer and download part or all of the software to run the program. Alternatively, the local computer can download software as needed, or execute some software instructions at a local terminal, and execute some software instructions at a remote computer (or computer network). Those skilled in the art will also recognize that, by utilizing conventional techniques known to those skilled in the art, all or part of the software instructions can be executed by a dedicated circuit (such as a digital signal processor (DSP), a programmable logic array, etc.).

[0169] As will be apparent to one skilled in the art, any range or device value given herein may be extended or altered without losing the effect sought.

[0170] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0171] It should be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to embodiments that solve any or all of the problems described, or embodiments that have any or all of the benefits and advantages described. It should also be understood that reference to an item 'a' refers to one or more of these items.

[0172] The operations of the methods described herein may be performed in any suitable order, or simultaneously where appropriate. In addition, individual blocks may be removed from any method without departing from the scope of the subject matter described herein. Aspects of any of the above examples may be combined with aspects of any other example described to form other examples without losing the effect sought.

[0173] The term 'comprising' is used herein to mean including the identified method blocks or elements, but such blocks or elements do not comprise an exclusive list and the method or apparatus may contain additional blocks or elements.

[0174] It should be understood that the above description is given by way of example only, and that various modifications may be made by those skilled in the art. The above description, examples, and data provide a complete description of the structure and use of the exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity or with reference to one or more individual embodiments, those skilled in the art may make various changes to the disclosed embodiments without departing from the scope of this specification.

Claims

1. A device comprising: processor; Encryptor; as well as a memory storing at least a portion of a first initialization vector associated with data in storage external to the processor, the first initialization vector being for a single use and comprising a virtual address of a block of the data; The processor is configured to execute computer-readable instructions to cause a read request to be issued for the data in the storage external to the processor; and The encryptor is configured as: receiving a read completion corresponding to the read request, the read completion comprising encrypted text and a second initialization vector; decrypting the encrypted text using the second initialization vector to generate plain text; as well as providing the plaintext and at least a portion of the second initialization vector to the processor; The processor is configured to: comparing at least a portion of the first initialization vector with the at least a portion of the second initialization vector; as well as In response to determining that the at least a portion of the first initialization vector matches the at least a portion of the second initialization vector, the plaintext is accepted.

2. The device according to claim 1, wherein The processor is part of a subsystem that acts as an accelerator for a host system coupled to the device, and The storage external to the processor is a memory of the host system.

3. The device of claim 2, the processor further configured to receive at least a portion of the computer-readable instructions from the host system. 4 . The apparatus of claim 1 , wherein the storage external to the processor is external to a processing unit including the processor.

5. The apparatus of claim 1, wherein the storage external to the processor is a dynamic random access memory.

6. The device according to claim 1, further comprising another processor, the other processor being configured to, before issuing the read request, execute computer-readable instructions so as to issue a write request for the data to the storage outside the processor, the write request comprising the plaintext and at least a portion of the first initialization vector; The encryptor is further configured to: receiving the write request; encrypting the plaintext of the write request using the first initialization vector to produce the encrypted text; as well as The encrypted text and the first initialization vector are caused to be written to the storage external to the processor.

7. The apparatus of claim 1, wherein decryption of the encrypted text using the second initialization vector is performed in accordance with the Advanced Encryption Standard.

8. The apparatus of claim 1, wherein the read completion corresponding to the read request is received via a buffer, the buffer having one read completion in-progress while another read completion is received via the buffer.

9. A method implemented in a device including a processor, the method comprising: Send a write request to the encryptor; receiving, at the encryptor, a write request for data to storage external to the processor based on the issued write request, the write request comprising plaintext and at least a portion of a first initialization vector, wherein the first initialization vector is a single use; encrypting the plaintext of the write request using the first initialization vector to produce encrypted text; causing the encrypted text and the first initialization vector to be written to the storage external to the processor; causing a read request to be issued for the data in the storage external to the processor; receiving, by the encryptor, a read completion corresponding to the read request, the read completion including the encrypted text and a second initialization vector; decrypting the encrypted text using the second initialization vector to generate the plain text; providing the plaintext and at least a portion of the second initialization vector to the processor; comparing, at the processor, the at least a portion of the first initialization vector with the at least a portion of the second initialization vector; as well as In response to determining that the at least a portion of the first initialization vector matches the at least a portion of the second initialization vector, the plaintext is accepted.

10. The method of claim 9, the processor being part of a subsystem for acting as a work accelerator for a host system coupled to the device, and the storage external to the processor being a memory of the host system. The method of claim 9 , wherein the storage external to the processor is external to a processing unit including the processor.

12. The method of claim 9, wherein the storage external to the processor is a dynamic random access memory.

13. The method of claim 9, further comprising calculating, at the processor, the first initialization vector from a parameterized function.

14. The method of claim 13, wherein the parameterized function generates different pairs of distinct initialization vectors for different portions of the plaintext.

15. A computer program for being executed by a processor of a device to perform a method comprising: storing in the processor at least a portion of a first initialization vector associated with data in storage external to the processor, the first initialization vector being for a single use and comprising a virtual address of a block of the data; causing a read request to be issued for the data in the storage external to the processor; receiving, by the encryptor, a read completion corresponding to the read request, the read completion comprising plaintext and at least a portion of a second initialization vector; comparing at least a portion of the first initialization vector with the at least a portion of the second initialization vector; as well as In response to determining that the at least a portion of the first initialization vector matches the at least a portion of the second initialization vector, accepting the received plaintext.

16. The computer program of claim 15, further comprising the processor being part of a subsystem for acting as a work accelerator for a host system coupled to the device, and the storage external to the processor being a memory of the host system.

17. The computer program of claim 16, the processor being further configured to receive at least a portion of the computer program from the host system.

18. The computer program of claim 15, further comprising the storage external to the processor being a memory external to the processor.

19. The computer program of claim 15, wherein the storage external to the processor is dynamic random access memory.

20. A method for securely transferring data between a first trusted computing entity and a second trusted computing entity by an untrusted intermediary, the method comprising: sending a request to the second trusted computing entity to create a trusted execution environment (TEE) at the second trusted computing entity, the request including a first authentication tag; receiving, from the second trusted computing entity, an indication that the TEE has been created; After verifying the indication, at the first trusted computing entity, for each of the plurality of encrypted data blocks, encrypting the plurality of data blocks using a pair including a key and an initialization vector; storing, at the first trusted computing entity, a parameterized function for obtaining an initialization vector, the parameterized function being known to the second trusted computing entity; copying the plurality of encrypted data blocks from the first trusted computing entity to a virtual address space of the untrusted intermediary so that the second trusted computing entity can retrieve the plurality of encrypted data blocks by making a direct memory access request using the parameterized function; as well as A second authentication tag computed based at least on data received by the second trusted computing entity from the direct memory access request matches the first authentication tag, enabling data to be transferred between the first trusted computing entity and the second trusted computing entity.

21. The method of claim 20, wherein the initialization vector is used only once.

22. The method of claim 21, wherein the first trusted computing entity and the second trusted computing entity agree that an initialization vector is used only once.

23. The method of claim 20, wherein the indication includes the first authentication tag and a reference showing that the TEE has been created.

24. The method of claim 20, further comprising: After verifying the indication, a program encryption key generated by the first trusted computing entity is sent to the second trusted computing entity.

25. The method of claim 24, wherein the data received from the direct memory access request comprises the plurality of encrypted data blocks.

26. The method of claim 25, wherein the second trusted computing entity decrypts each code block from the plurality of encrypted data blocks and computes the second authentication tag over the entire code sequence.

27. A system comprising: a first trusted computing entity; a second trusted computing entity; as well as Untrusted intermediaries; The first trusted computing entity is configured as: sending a request to the second trusted computing entity to create a trusted execution environment (TEE) at the second trusted computing entity, the request including a first authentication tag; receiving, from the second trusted computing entity, an indication that the TEE has been created; After verifying the indication, at the first trusted computing entity, for each of the plurality of data blocks, encrypting the plurality of data blocks using a pair including a key and an initialization vector; storing a parameterized function for obtaining an initialization vector, the parameterized function being known to the second trusted computing entity; copying the plurality of encrypted data blocks to a virtual address space of the untrusted intermediary so that the second trusted computing entity can retrieve the plurality of encrypted data blocks by making a direct memory access request using the parameterized function; as well as Data is transferred to and from the second trusted computing entity based at least on a second authentication tag calculated by the second trusted computing entity from the data received from the direct memory access request matching the first authentication tag.

28. The system of claim 27, wherein the initialization vector is used only once.

29. The system of claim 28, wherein the first trusted computing entity and the second trusted computing entity agree that an initialization vector is used only once.

30. The system of claim 29, wherein the indication includes the first authentication tag and a reference showing that the TEE has been created.

31. The system of claim 27, wherein the first trusted computing entity is further configured to send a program encryption key generated by the first trusted computing entity to the second trusted computing entity after verifying the indication.

32. The system of claim 31, wherein the data received from the direct memory access request comprises the plurality of encrypted data blocks.

33. The system of claim 32, wherein the second trusted computing entity is configured to decrypt each code block from the plurality of encrypted data blocks and compute the second authentication tag over the entire code sequence.

34. A computer readable medium comprising computer executable instructions which, when executed by a processor, cause the processor to: sending a request to a second trusted computing entity to create a trusted execution environment (TEE) at the second trusted computing entity, the request including a first authentication tag; receiving, from the second trusted computing entity, an indication that the TEE has been created; After verifying the indication, at the first trusted computing entity, for each of the plurality of data blocks, encrypting the plurality of data blocks using a pair including a key and an initialization vector; storing, at the first trusted computing entity, a parameterized function for obtaining an initialization vector, the parameterized function being known to the second trusted computing entity; copying the plurality of encrypted data blocks from the first trusted computing entity to a virtual address space of an untrusted intermediary so that the second trusted computing entity can retrieve the plurality of encrypted data blocks by making a direct memory access request using the parameterized function; as well as A second authentication tag computed based at least on data received by the second trusted computing entity from the direct memory access request matches the first authentication tag, enabling data to be transferred between the first trusted computing entity and the second trusted computing entity.

35. The computer readable medium of claim 34, wherein the initialization vector is used only once.

36. The computer-readable medium of claim 35, wherein the first trusted computing entity and the second trusted computing entity agree that an initialization vector is used only once.

37. The computer-readable medium of claim 36, wherein the indication comprises the first authentication tag and a reference showing that the TEE has been created.

38. The computer-readable medium of claim 34, wherein the first trusted computing entity is further configured to send a program encryption key generated by the first trusted computing entity to the second trusted computing entity after verifying the indication.

39. The computer-readable medium of claim 38, wherein the data received from the direct memory access request comprises the plurality of encrypted data blocks.

Images