Technologies for low-latency cryptography for processor-accelerator communication

Technologies for secure data transfer include a computing device having a processor, an accelerator, and a security engine, such as a direct memory access (DMA) engine or a memory-mapped I/O (MMIO) engine. The computing device initializes the security engine with an initialization vector and a secret key. During initialization, the security engine pre-fills block cipher pipelines and pre-computes hash subkeys. After initialization, the processor initiates a data transfer, such as a DMA transaction or an MMIO request, between the processor and the accelerator. The security engine performs an authenticated cryptographic operation for the data transfer operation. The authenticated cryptographic operation may be AES-GCM authenticated encryption or authenticated decryption. The security engine may perform encryption or decryption using multiple block cipher pipelines. The security engine may calculate an authentication tag using multiple Galois field multipliers. Other embodiments are described and claimed.

BACKGROUND

Current processors may provide support for a trusted execution environment such as a secure enclave. Secure enclaves include segments of memory (including code and/or data) protected by the processor from unauthorized access including unauthorized reads and writes. In particular, certain processors may include Intel® Software Guard Extensions (SGX) to provide secure enclave support. In particular, SGX provides confidentiality, integrity, and replay-protection to the secure enclave data while the data is resident in the platform memory and thus provides protection against both software and hardware attacks. The on-chip boundary forms a natural security boundary, where data and code may be stored in plaintext and assumed to be secure. Intel® SGX does not protect I/O data that moves across the on-chip boundary.

Modern computing devices may include general-purpose processor cores as well as a variety of hardware accelerators for offloading compute-intensive workloads or performing specialized tasks. Hardware accelerators may include, for example, one or more field-programmable gate arrays (FPGAs), which may include programmable digital logic resources that may be configured by the end user or system integrator. Hardware accelerators may also include one or more application-specific integrated circuits (ASICs). Hardware accelerators may be embodied as I/O devices that communicate with the processor core over an I/O interconnect.

DETAILED DESCRIPTION OF THE DRAWINGS

Referring now toFIG. 1, an illustrative computing device100for low-latency cryptography for processor-accelerator communication includes a processor120and an accelerator device136. The accelerator device136includes one or more hardware security engines, illustratively a direct memory access (DMA) engine138and a memory-mapped I/O (MMIO) engine140. In use, as described further below, the computing device100initializes the security engine138,140, which pre-fills cryptographic pipelines and pre-computes counter values, hash subkeys, and other values. After initialization is complete, the computing device100generates DMA or MMIO transactions between the processor120and the accelerator device136, and the respective security engine138,140performs authenticated cryptographic operations (e.g., AES-GCM authenticated encryption or authenticated decryption) on the transferred data in-line. A block of multiple DMA and/or MMIO transactions may be protected without re-initialization of the security engine138,140. As described further below, the security engines138,140perform the cryptographic operations with low latency (e.g., 1-2 clock cycles) and high bandwidth, without the need to buffer data prior to processing or to stall the data transfers. Accordingly, the computing device100may provide security without significant additional overhead for data streamed between processor120and accelerator device136as compared to existing, unsecured communications. Additionally, as described further below, the computing device100provides protection against certain denial of service (DoS) attacks.

The computing device100may be embodied as any type of device capable of performing the functions described herein. For example, the computing device100may be embodied as, without limitation, a computer, a laptop computer, a tablet computer, a notebook computer, a mobile computing device, a smartphone, a wearable computing device, a multiprocessor system, a server, a workstation, and/or a consumer electronic device. As shown inFIG. 1, the illustrative computing device100includes a processor120, an I/O subsystem124, a memory130, and a data storage device132. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory130, or portions thereof, may be incorporated in the processor120in some embodiments.

The processor120may be embodied as any type of processor capable of performing the functions described herein. For example, the processor120may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. As shown, the processor120illustratively includes secure enclave support122, which allows the processor120to establish a trusted execution environment known as a secure enclave, in which executing code may be measured, verified, and/or otherwise determined to be authentic. Additionally, code and data included in the secure enclave may be encrypted or otherwise protected from being accessed by code executing outside of the secure enclave. For example, code and data included in the secure enclave may be protected by hardware protection mechanisms of the processor120while being executed or while being stored in certain protected cache memory of the processor120. The code and data included in the secure enclave may be encrypted when stored in a shared cache or the main memory130. The secure enclave support122may be embodied as a set of processor instruction extensions that allows the processor120to establish one or more secure enclaves in the memory130. For example, the secure enclave support122may be embodied as Intel® Software Guard Extensions (SGX) technology.

The memory130may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory130may store various data and software used during operation of the computing device100such as operating systems, applications, programs, libraries, and drivers. As shown, the memory130may be communicatively coupled to the processor120via the I/O subsystem124, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor120, the memory130, and other components of the computing device100. For example, the I/O subsystem124may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, sensor hubs, host controllers, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations.

As shown, the I/O subsystem124includes a direct memory access (DMA) engine126and a memory-mapped I/O (MMIO) engine128. The processor120, including secure enclaves established with the secure enclave support122, may communicate with the accelerator device136with one or more DMA transactions using the DMA engine126and/or with one or more MMIO transactions using the MMIO engine128. As described further below, the transactions are cryptographically protected using corresponding security engines138,140of the accelerator device136. The computing device102may include multiple DMA engines126and/or MMIO engines128for handling DMA and MMIO transactions based on bandwidth between the processor120and the accelerator136. Although illustrated as being included in the I/O subsystem124, it should be understood that in some embodiments the DMA engine126and/or the MMIO engine128may be included in other components of the computing device102(e.g., the processor120, memory controller, or system agent), or in some embodiments may be embodied as separate components. Thus, in some embodiments, the memory130may be directly coupled to the processor120, for example via an integrated memory controller hub. Additionally, in some embodiments, the I/O subsystem124may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor120, the memory130, the accelerator device136, and/or other components of the computing device100, on a single integrated circuit chip. Additionally or alternatively, in some embodiments the processor120may include an integrated memory controller and a system agent, which may be embodied as a logic block in which data traffic from processor cores and I/O devices converges before being sent to the memory130.

The data storage device132may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, non-volatile flash memory, or other data storage devices. The computing device100may also include a communications subsystem134, which may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the computing device100and other remote devices over a computer network (not shown). The communications subsystem134may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, 3G, 4G LTE, etc.) to effect such communication.

The accelerator device136may be embodied as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a coprocessor, or other digital logic device capable of performing accelerated functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions). Illustratively, the accelerator device136is an FPGA, which may be embodied as an integrated circuit including programmable digital logic resources that may be configured after manufacture. The FPGA may include, for example, a configurable array of logic blocks in communication over a configurable data interchange. The accelerator device136may be coupled to the processor120via a high-speed connection interface such as a peripheral bus (e.g., a PCI Express bus) or an inter-processor interconnect (e.g., an in-die interconnect (IDI) or QuickPath Interconect (QPI)), or via any other appropriate interconnect. The accelerator device136may receive data and/or commands for processing from the processor120and return results data to the processor120via DMA, MMIO, or other data transfers.

As shown, the accelerator device136includes the secure DMA engine138and the secure MMIO engine140. As described further below, the security engines138,140perform in-line authenticated cryptographic operations on data transferred between the processor120and the accelerator device136. The accelerator device136may include multiple secure DMA engines138and/or secure MMIO engines140for handling DMA and MMIO transactions based on bandwidth between the processor120and the accelerator136. Although illustrated as being included in the accelerator136, it should be understood that in some embodiments the security engines138,140may be included in other components of the computing device100(e.g., the processor120and/or the I/O subsystem124), or in some embodiments may be embodied as separate components. Additionally or alternatively, although illustrated as being included in the accelerator136, it should be understood that in some embodiments the processor120and/or SoC may also include hardware security engines (e.g., secure DMA engines and/or secure MMIO engine).

As shown, the computing device100may further include one or more peripheral devices142. The peripheral devices142may include any number of additional input/output devices, interface devices, hardware accelerators, and/or other peripheral devices. For example, in some embodiments, the peripheral devices142may include a touch screen, graphics circuitry, a graphical processing unit (GPU) and/or processor graphics, an audio device, a microphone, a camera, a keyboard, a mouse, a network interface, and/or other input/output devices, interface devices, and/or peripheral devices.

Referring now toFIG. 2, an illustrative embodiment of a security engine200(e.g., the secure DMA engine138or the secure MMIO engine140) is shown. As shown, the security engine200includes multiple AES pipelines202and multiple Galois field (GF) multipliers204. Each AES pipeline202may be embodied as digital logic resources that perform AES block cipher encryption. Illustratively, each AES pipeline202processes 128-bit blocks and thus includes ten pipeline stages, which correspond to ten AES rounds that are performed during AES encryption for 128-bit blocks. In other embodiments, each AES pipeline202may include a different number of pipeline stages, for example to process blocks of different sizes. Each GF multiplier204may be embodied as digital logic resources that performs multiplication in a Galois (finite) field of 2128elements. Thus, the security engine200may perform cryptographic operations according to a Galois/Counter mode of operation (AES-GCM). As shown, the security engine200also includes registers206and counters/control logic208. The security engine200receives input data and generates output data. The input data and output data may be embodied as blocks of binary data. The security engine200may also receive and/or assert other data signals, including additional authentication data, authentication tags, encryption keys, control signals, and/or other signals.

The particular number and/or arrangement of components of the security engine200may scale depending on the type of data transfer and/or the amount of data processed per transaction. For example, the number of parallel AES pipelines202and Galois Field multipliers204may be scaled to match the maximum bandwidth of the transfers and enable processing without buffers or throttling down transfer speed. For both DMA and MMIO, after the setup phase, the engines138,140are ready for data transfer and the respective engine produces encrypted/decrypted output in the next clock cycle of a valid input; e.g., plaintext to ciphertext latency is 1 clock cycle and ciphertext to plaintext latency is 1 clock. The pipelines202are stalled if there is no valid input available. Otherwise, the security engine200continually streams out the encrypted/decrypted data in each clock cycle. For DMA, the secure DMA engine138may process 512 bits of data per transaction (e.g., per clock cycle), which may be embodied as four 128-bit blocks of data. In that example, the secure DMA engine138may include four AES pipelines202and five GF multipliers204. When run at 256 MHz, this results in 128 Gbit/sec throughput. As another example, the secure MMIO engine140may process 32 or 64 bits of data per transaction (e.g., per clock cycle). In that example, the secure MMIO engine140may include two AES pipelines202and two GF multipliers204.

Referring now toFIG. 3, in an illustrative embodiment, the computing device100establishes an environment300during operation. The illustrative environment300includes a trusted execution environment302, an initialization manager304, a transfer manager306, and a security engine200. The various components of the environment300may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the environment300may be embodied as circuitry or collection of electrical devices (e.g., trusted execution environment circuitry302, initialization manager circuitry304, transfer manager circuitry306, and/or security engine circuitry200). It should be appreciated that, in such embodiments, one or more of the trusted execution environment circuitry302, the initialization manager circuitry304, the transfer manager circuitry306, and/or the security engine circuitry200may form a portion of the processor120, the I/O subsystem124, the accelerator device136, and/or other components of the computing device100. Additionally, in some embodiments, one or more of the illustrative components may form a portion of another component and/or one or more of the illustrative components may be independent of one another.

The trusted execution environment302may be embodied as any trusted execution environment of the computing device100that is authenticated and protected from unauthorized access using hardware support of the computing device100, such as the secure enclave support122of the processor120. Illustratively, the trusted execution environment302is a secure enclave established using Intel SGX technology. As shown, the trusted execution environment302includes the initialization manager302and the transfer manager306. In some embodiments, the initialization manager302and the transfer manager306may be included in separate trusted environments (e.g., separate enclaves).

The initialization manager304is configured to initialize the security engine200with an initialization vector and a secret key. The initialization vector and the secret key may be provided by the trusted execution environment302. Initializing the security engine200may include asserting a start signal to the security engine200and inserting a zero block into a block cipher pipeline202in response to receiving the start signal. The zero block may be embodied as a 128-bit block with each bit equal to zero. Initializing the security engine200may further include deriving, by the security engine200, one or more hash subkeys as a function of an output of the block cipher pipeline202in response to inserting the zero block. Initializing the security engine200may further include initializing an initial counter block as a function of the initialization vector in response to receiving the start signal, inserting a counter block based on the initial counter block into each of the block cipher pipelines202, executing a predetermined number of block cipher rounds (e.g., ten rounds) with the block cipher pipelines202in response to inserting the counter blocks, and asserting a ready signal by the security engine200in response to executing the predetermined number of block cipher rounds.

The transfer manager306is configured to initiate a data transfer operation between the trusted execution environment302and an accelerator device136in response to initializing the security engine200. In some embodiments, the data transfer operation may be a direct memory access (DMA) transfer with multiple input data blocks (DMA transactions). For DMA operations, the transfer manager306may be further configured to read, by the trusted execution environment302, a final authentication tag value from the security engine200, calculate, by the trusted execution environment302, an expected authentication tag value for the data transfer operation, and compare, by the trusted execution environment302, the final authentication tag value to the expected authentication tag value. In some embodiments, the data transfer operation may be a memory-mapped I/O (MMIO) transaction with a single input data block. For MMIO transactions, the transfer manager306may be further configured to calculate, by the trusted execution environment302, an expected authentication tag value for the data transfer operation and to write, by the trusted execution environment302, the expected authentication tag value to the security engine200.

The security engine200is configured to perform an authenticated cryptographic operation for the data transfer operation in response to initiating the data transfer operation. The authenticated cryptographic operation may be embodied as an AES Galois/Counter mode (AES-GCM) cryptographic operation including authenticated encryption or authenticated decryption. For DMA operations, performing the authenticated cryptographic operation may include performing a cryptographic operation with the block cipher pipelines202on the input data blocks to generate a corresponding number of output data blocks. Performing the cryptographic operation may include reading the input data blocks, bitwise exclusive ORing each of the input data blocks with an output of a block cipher pipeline202to generate a corresponding output data block, and then inserting an incremented counter block into each of the block cipher pipelines202. Performing the authenticated cryptographic operation may also include updating an intermediate authentication tag value register based on multiple ciphertext blocks (e.g, the input data blocks for decryption or the output data blocks for encryption). Updating the intermediate authentication tag value may include performing, for each ciphertext block, a Galois field multiplication with a GF multiplier204as a function of a hash subkey and the ciphertext block. The security engine200may be further configured to receive a last signal and to generate a final authentication tag value as a function of the intermediate authentication tag value register in response to receiving the last signal.

For MMIO operations, performing the authenticated cryptographic operation may include performing a cryptographic operation with a block cipher pipeline202on the input data block to generate an output data block and generating a final authentication tag value based on a ciphertext block (e.g., the input data block for decryption or the output data block for encryption). The security engine200may compare the final authentication tag value to an expected authentication tag value written by the trusted execution environment302. Generating the final authentication tag value may include performing a Galois field multiplication with a GF multiplier204as a function of a hash subkey and the ciphertext block. Performing the cryptographic operation may include reading the input data block, bitwise exclusive ORing the input data block with an output of the block cipher pipeline202to generate the output data block, and inserting an incremented counter block into the block cipher pipeline202if the expected authentication tag value and the final authentication tag value match.

Referring now toFIG. 4, in use, the computing device100may execute a method400for low-latency cryptography for processor-accelerator communication of DMA transfers. It should be appreciated that, in some embodiments, the operations of the method400may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3. The method400begins in block402, in which the computing device100initializes the security engine200(e.g., the secure DMA engine138) using an initialization vector IV and a secret key K. The IV is a nonce value associated with a particular DMA transfer, which may include multiple DMA transactions. The security engine200may be initialized, for example, in response to a signal from the processor120caused by the trusted execution environment302. One potential embodiment of a method for initializing and managing DMA transfers that may be performed by the trusted execution environment302is described below in connection withFIG. 5.

The value for IV may be determined according to one or more AES-GCM specifications. The secret key K may be embodied as any symmetric encryption key used to protect data transferred between the processor120and the accelerator136. During initialization, the security engine200pre-computes values, primes encryption pipelines, and otherwise prepares to process data transfers. As described further, initializing the security engine200may hide pipeline latency or other latency associated with the security engine200. For example, initialization may require 16 clock cycles for DMA. In block404, the security engine200derives a hash subkey H based on IV. The hash subkey H is determined according to one or more AES-GCM specifications, illustratively by encrypting a block with all bits set to zero using the secret key K. In block406, the security engine200primes one or more AES pipelines202with counter blocks based on IV. The initial counter block value CTR may be determined according to one or more AES-GCM specifications. For multiple AES pipelines202, an incremented counter block (e.g., CTR+1, CTR+2, etc.) may be inserted into each of AES pipeline. In block408, the security engine200pre-computes additional hash subkey values using one or more GF multipliers204. For example, the security engine200may compute H2=H·H, H3=H·H·H, and so on, where the symbol · denotes Galois field multiplication.

In block410, the security engine200checks for an input DMA transaction. For example, the DMA transaction may be embodied as 512 bits of data (e.g., four 128-bit blocks of data). As described further below, a DMA transfer of data (e.g., a contiguous block of data or other data) may include multiple DMA transactions. In block412, the security engine200determines whether an input DMA transaction has been received. If so, the method400branches to block416, described below. If an input DMA transaction was not received, the method400branches to block414, in which the security engine200stalls the AES pipelines202. When the AES pipelines202are stalled, they retain their state and are prepared to output encrypted values on the next clock cycle. After stalling the AES pipelines202, the method400loops back to block410to continue waiting for input DMA transactions.

Referring back to block412, if a DMA transaction was received, the method400branches to block416, in which the security engine200performs a cryptographic operation on the input data block associated with the DMA transaction. In some embodiments, in block418the security engine200may encrypt the input data using the AES pipelines202. For example, the security engine200may encrypt plaintext data received from the accelerator136before it is transferred with a DMA transaction to the processor120. In some embodiments, in block420the security engine200may decrypt the input data using the AES pipelines202. For example, the security engine200may decrypt ciphertext data received from the processor120before it is transferred with a DMA transaction to the accelerator136.

In block422, the security engine200updates an authentication tag (AT) with the ciphertext block(s) using multiple GF multipliers204. The ciphertext blocks may be the input data to the security engine200(e.g., for decryption operations) or the output data from the security engine200(e.g., for encryption operations). The AT may be updated based on the ciphertext and one or more other values (e.g., hash subkeys H, H2, H3, additional authenticated information A, etc.).

In block424, the security engine200determines whether a last DMA transaction associated with the DMA transfer has been processed. As described above, a particular DMA transfer of data may include multiple DMA transactions (e.g., multiple DMA transactions of 512-bit data blocks). The trusted execution environment302or other entity may assert a last signal to the security engine200or otherwise indicate to the security engine200that the DMA transfer is complete. If the last DMA transaction has not been processed, the method400loops back to block410, in which the security engine200waits for additional DMA transactions. Note that the security engine200is not re-initialized between DMA transactions. Referring back to block424, if the last DMA transaction has been processed, the method400advances to block426. In block426the security engine200generates a final authentication tag T based on the intermediate value of T updated after each DMA transaction. As described further below, the final authentication tag T may be used by the processor120and/or the accelerator136to verify that a data transfer was authentic and unaltered. After generating the final authentication tag, the method400loops back to block402to re-initialize the security engine200to process additional DMA transfers.

Referring now toFIG. 5, in use, the computing device100may execute a method500for DMA transfer management. It should be appreciated that, in some embodiments, the operations of the method500may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3, such as the trusted execution environment302. The method500begins in block502, in which the processor120asserts a start signal to the secure DMA engine138. The computing device100provides the initialization vector IV, secret key K, and additional authenticated data A to the secure DMA engine138. The computing device100may use any technique to security communicate that data to the secure DMA engine138. As described above, IV is a nonce value associated with a DMA transfer, and may be determined according to one or more AES-GCM specifications. The secret key K may be embodied as any symmetric encryption key used to protect data transferred between the processor120and the accelerator136. The key K may be protected from unauthorized disclosure by the trusted execution environment302, for example by being maintained in a secure enclave established using the secure enclave support122of the processor120. The additional authenticated data A may be embodied as any addressing data, metadata, or other data related to the DMA transfer that will be authenticated but not encrypted by the security engine200. In response to the start signal, the secure DMA engine138performs an initialization process as described above in connection with block402ofFIG. 4. One potential embodiment of a method for initialization is described below in connection withFIG. 6.

In block504, the processor120waits for a ready for data signal to be asserted by the secure DMA engine138. As described further below, the ready for data signal is asserted when the secure DMA engine138completes its initialization process. The computing device100may poll, wait for an interrupt, or otherwise monitor for the ready for data signal. After the ready for data signal is asserted, the method500proceeds to block506.

In block506, the processor120configures a DMA controller to perform a DMA transfer. The processor120may configure the DMA controller, for example, by writing one or more descriptors or other commands that describe the DMA transfer. The descriptors may identify a memory address, memory range, scatter-gather list of addresses or ranges, or other locations in memory and a direction of transfer (e.g., from the memory130to the accelerator136or vice versa). The DMA controller may perform the DMA transfer, for example, by performing one or more DMA transactions defined by the descriptors. Each DMA transaction may transfer a fixed block of data, such as a 512-bit block of data. The DMA controller may interrupt or otherwise signal the processor120when the DMA transfer is completed and/or when each DMA transaction is completed. Illustratively, the DMA controller may included or otherwise be coupled with the DMA engine126. In some embodiments, the DMA controller may be included in the accelerator136or other component of the computing device. In block508, the processor120may send a request that data be transferred from the accelerator136into a location in the memory130. In block510, the processor120may send a request that encrypted data be transferred from the memory130to the accelerator136. As described further below in connection withFIGS. 7-8, the secure DMA engine138performs authenticated cryptographic operations on the data as the DMA transactions are performed (e.g., as the data is transferred between the memory130and the accelerator136). Although illustrated as being configured by the processor120, it should be understood that in other embodiments the DMA controller may be configured by a different entity, such as the accelerator136.

In block512, the processor120determines whether additional data remains to be transferred by DMA. For example, the processor120may determine whether the DMA controller has completed all of the DMA transactions associated with the DMA transfer. If additional data remains, the method500loops back to block506to continue transferring data. If no additional data remains, the method500advances to block514.

In block514, the processor120sends a last signal to the secure DMA engine138. As described further below in connection withFIGS. 7-8, the secure DMA engine138calculates the final authentication tag value T in response to the last signal. Although illustrated as asserting the last signal after completing the DMA transfer, in some embodiments the last signal may be asserted with the last DMA transaction or otherwise at the end of processing the DMA transaction. In block516, the processor120waits for a done signal asserted by the secure DMA engine138. As described further below, the done signal is asserted when the secure DMA engine138completes calculating the final authentication tag T. The processor120may poll, wait for an interrupt, or otherwise monitor for the done signal. After the done signal is asserted, the method500proceeds to block518.

In block518, the processor120reads the final (AT) value T from a register of the secure DMA engine138. In block520, the processor120compares the AT value T to an expected AT value calculated by the processor120, for example by the trusted execution environment302. In some embodiments, in block522, the processor120may calculate the expected AT based on encrypted data (ciphertext) that was sent to the accelerator136. For example, the expected AT may be calculated based on ciphertext sent to the accelerator136with one or more DMA transactions. In some embodiments, in block524, the processor120may calculate the expected AT based on encrypted data received from the accelerator136, for example with one or more DMA transactions.

In block526, the processor120determines whether the AT value T read from the secure DMA engine138matches the expected AT value calculated by the processor120. A mismatch indicates that an authentication failure has occurred. For example, the ciphertext may have been altered, a malicious actor may have configured false descriptor or other DMA transaction request, or another error may have occurred. If the values do not match, the method500branches to block528, in which the processor120indicates an authentication error. Referring back to block526, if the AT values match, then the method500loops back to block502, in which the secure DMA engine138may be re-initialized for additional DMA transfers.

Referring now toFIG. 6, in use, the computing device100may execute a method600for security engine200initialization. It should be appreciated that, in some embodiments, the operations of the method600may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3, such as the security engine200. The method600begins in block602, in which the security engine200receives a start signal, for example from the trusted execution environment302. After receiving the start signal, the method600advances to block604.

In block604, the security engine200reads the initialization vector IV and the secret key K from the processor120. As described above, IV is a nonce value associated with multiple transactions, such as a DMA transfer session or a block of MMIO transactions, and may be determined according to one or more AES-GCM specifications. The secret key K may be embodied as any symmetric encryption key used to protect data transferred between the processor120and the accelerator136.

In block606, the security engine200inserts a block which each bit set to zero (e.g., a 128-bit block of all zeros) to an AES pipeline202, identified as pipeline1. Although illustrated as inserting a zero block, it should be understood that in other embodiments, any predetermined constant or otherwise known value may be inserted. In block608, the security engine200executes a pipeline stage of the AES pipeline202(pipeline1). Executing the pipeline stage calculates an AES round and prepares the AES pipeline202for insertion of another value to be encrypted. Executing the pipeline stage may require one clock cycle.

In block610, the security engine200initializes a counter block CTR based on IV. The counter block may be determined according to one or more AES-GCM specifications. Illustratively, the security engine200initializes a 32-bit counter with the decimal value “2” and forms CTR as a 128-bit value equal to IV concatenated with the 32-bit counter, as shown in Equation 1, below.
CTR=IV∥(2d′32)   (1)

In block612, for each AES pipeline202, the security engine200inserts an appropriately incremented CTR block into the corresponding AES pipeline202. For example, in an embodiment with four AES pipelines202a,202b,202c,202d, the security engine200may insert counter blocks CTR, CTR+1, CTR+2, and CTR+3, respectively. The CTR blocks may be incremented according to one or more AES-GCM standards, for example by incrementing the 32-bit counter value and concatenating IV with that incremented counter value. As another example, and as described further below in connection withFIGS. 9-11, in an embodiment with two AES pipelines202a,202b, the security engine200may insert counter block CTR into pipeline202aand may insert a pre-counter block based on IV and used for authentication tag generation into pipeline202b. In block614, the security engine200executes a pipeline stage of each AES pipeline202. As described above, executing the pipeline stage calculates an AES round and prepares the AES pipeline202for insertion of another value to be encrypted. Executing the pipeline stage may require one clock cycle. In block616, the security engine200increments the counter block CLK by the number of AES pipelines n. For example, in an embodiment with four AES pipelines202, the security engine200may increment the counter block to equal CTR+4. As discussed above, the security engine200may increment the 32-bit counter by n and then concatenate IV with that incremented counter value. As another example, in embodiment with two pipelines202a,202b, wherein pipeline202bis used for authentication tag generation, the security engine200may increment the counter by one and determine a corresponding pre-counter block.

In block618, the security engine200determines whether nine pipeline stages (clock cycles) have been executed since inserting the counter blocks based on CTR. For example, the security engine200may determine whether the 32-bit counter equals 34. If not, the method600branches ahead to block622. If nine pipeline stages have been executed, the method600advances to block620. In block620, the security engine200stores the hash subkey H from the output of the corresponding AES pipeline202(pipeline1). The hash subkey H is determined by encrypting a 128-bit block with each bit set to zero using the secret key K, as shown in Equation 2 below. Because the zero block was inserted before inserting counter blocks based on CTR, the corresponding AES pipeline202has executed ten stages (AES rounds), and thus the output of the corresponding AES pipeline202is H, the encrypted zero block. H may be stored in a register206of the security engine200.
H=CIPHK(0′128)   (2)

In block622, the security engine200determines whether ten pipeline stages (clock cycles) have been executed since inserting the counter blocks based on CTR. For example, the security engine200may determine whether the 32-bit counter equals 38. If not, the method600loops back to block612to continue inserting counter blocks into the pipelines202. If ten pipeline stages have been executed, the method600advances to block624.

In block624, the security engine200stalls all of the AES pipeline stages. As discussed above, when the AES pipelines202are stalled, they retain their state and are prepared to output encrypted values on the next clock cycle. Thus, after initialization, the AES pipelines202may be primed with appropriate counter blocks to perform cryptographic operations.

In block626, the security engine200computes additional hash subkeys H2to Hn, where n is the number of AES pipelines and Hnis the nth power of H under the product “·” (Galois field multiplication). The subkeys H2to Hnmay be calculated with multiple GF multipliers204of the security engine in parallel. For example, in an embodiment with four AES pipelines202, the security engine200may calculate H2in one clock cycle and then calculate H3and H4in the next clock cycle. The pre-computed values of H2to Hnmay be stored in registers206of the security engine200.

In some embodiments, in block628the security engine200may pre-compute a value Len·H using a GF multiplier204. The value Len is determined based on the length of the additional authenticated data A and the ciphertext C, for example equal to len(A)∥len(C). For MMIO transactions, the lengths of A and C may be constant and known ahead of time, and thus the value Len·H. Illustratively, for MMIO transactions, A may have a length of 128 bits and C may have a length of 64 bits.

In block630, the security engine200asserts a ready for data signal to the processor120. As described above, after asserting the ready for data signal, the processor120may initiate one or more data transactions between the processor120and the accelerator136, such as DMA transactions and/or MMIO transactions. After asserting the ready for data signal, the security engine200waits for input data or other signals from the processor120. One potential embodiment of a method for processing DMA transactions that may be executed by the security engine200(e.g., by a secure DMA engine138) is described further below in connection withFIGS. 7 and 8. One potential embodiment of a method for processing MMIO transactions that may be executed by the security engine200(e.g., by a secure MMIO engine140) is described further below in connection withFIG. 11.

Referring now toFIGS. 7 and 8, in use, the secure DMA engine138of the computing device100may execute a method700for performing secure DMA transfers. It should be appreciated that, in some embodiments, the operations of the method700may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3, such as the security engine200(e.g., the secure DMA engine138). The method700begins in block702, in which the secure DMA engine138initializes an intermediate authentication tag (AT) register T as equal to A·H, where the symbol “·” denotes Galois field multiplication. The register T may be initialized during or after initialization of the secure DMA engine138as described above in connection withFIG. 6. As described further below, the AT value is be determined according to one or more AES-GCM specifications. The register T may be stored in the registers206of the secure DMA engine138. After initializing T, the method700advances to block704.

In block704, the secure DMA engine138stalls the AES pipelines202and waits for one or more signals to be asserted from the processor120. As described above, stalling the AES pipelines202allows the pipelines to retain their state and be prepared to output encrypted values on the next clock cycle. In block706, the secure DMA engine138determines whether a last signal has been asserted. As described above, the processor120asserts the last signal to indicate that the DMA transfer is complete and no additional DMA transactions remain. If the last signal is asserted, the method700branches to block730, shown inFIG. 8and described further below. If the last signal is not asserted, the method700advances to block708. In block708, the secure DMA engine138determines whether there is a valid input to process (e.g., whether an input valid signal has been asserted by the processor120). If not, the method700loops back to block704to continue to stall the AES pipelines202and wait for signals. If valid input exists, the method700advances to block710.

In block710, the secure DMA engine138reads n 128-bit input data blocks. In the illustrative embodiment, the secure DMA engine138reads four (4) 128-bit input data blocks, which results in 512 bits of DMA data per transaction. The input data blocks may be read from the memory130(e.g., for transfers from the memory130to the accelerator136) or from the accelerator136(e.g., for transfers from the accelerator136to the memory130). In some embodiments, in block712the secure DMA engine138may read plaintext data (i.e., for an encryption operation). In some embodiments, in block714the secure DMA engine138may read ciphertext data (i.e., for a decryption operation).

In block716, the secure DMA engine138bitwise exclusive ORs (XOR, or the symbol ⊕) each input data block with the current output of a corresponding AES pipeline202. For example, in the illustrative embodiment with four AES pipelines202a,202b,202c,202dand four input data blocks X1, X2, X3, X4, the secure DMA engine138determines X1⊕202a, X2⊕202b, X3⊕202c, and X4⊕202d. XORing the output of the pipelines202with the input data blocks performs a cryptographic operation on the input data blocks. Thus, the secure DMA engine138may read the input data in one clock cycle and generate the output data in the following clock cycle. In some embodiments, in block718the secure DMA engine138encrypts plaintext input data blocks P to generate corresponding ciphertext blocks C. For example, in the illustrative embodiment the secure DMA engine138calculates C1=P1⊕202a, C2=P2δ202b, C3=P3⊕202c, C4=P4⊕202d. In some embodiments, in block720the secure DMA engine138decrypts ciphertext input data blocks C to generate corresponding plaintext blocks P. For example, in the illustrative embodiment the DMA engine calculates P1=C1⊕202a, P2=C2⊕202b, P3=C3⊕202c, P4=C4⊕202d. As shown, the outputs of the AES pipelines202may be used for both encryption and decryption operations.

In block722, the secure DMA engine138increments CTR by n and inserts appropriately incremented counter blocks into each AES pipeline202. For example, in the illustrative embodiment with four AES pipelines202, the security engine200may increment the counter block to equal CTR+4 by incrementing a 32-bit counter by n and then concatenating IV with that incremented counter value. After incrementing CTR, the secure DMA engine138may insert counter blocks CTR, CTR+1, CTR+2, and CTR+3 into the AES pipelines202a,202b,202c,202d, respectively. In block724, the secure DMA engine138executes a pipeline stage of each AES pipeline202. As described above, executing the pipeline stage calculates an AES round and prepares the AES pipeline202for insertion of another value to be encrypted. Executing the pipeline stage may require one clock cycle.

In block726, the secure DMA engine138updates the intermediate AT register T based on the ciphertext blocks C1to Cnand the subkeys H to Hn. As described above, the subkeys H to Hnare pre-computed during initialization, and the ciphertext blocks C may be the input to the secure DMA engine138(for decryption) or the output of the secure DMA engine138(for encryption). The register T may be updated according to one or more AES-GCM specifications. In particular, the updated value for T may be determined according to Equation 3, below. The Galois field multiplication operations of Equation 3 may be performed in parallel by multiple GF multipliers204of the secure DMA engine138. Thus, in the illustrative embodiment, the secure DMA engine138may include five GF multipliers204that perform the five GF multiplications in one clock cycle. Thus, for 128-bit ciphertext blocks, the secure DMA engine138may update the authentication tag with a bandwidth of 512 bits per clock cycle. In some embodiments, authentication-tag related operations may be performed in parallel with ciphertext/plaintext generation.
T′=T·H4⊕C1·H4⊕C2·H3⊕C3·H2⊕C4·H(3)

After updating the register T, in block728the secure DMA engine138asserts an output valid signal. In response to asserting the output valid signal, the DMA transaction may be performed with the output data of the secure DMA engine138. For example, for a decryption operation, decrypted output data may be transferred to the accelerator136. As another example, for an encryption operation, encrypted output data may be stored in the memory130, where it may be accessed by the processor120. Performance overhead experienced on the data transfer may be limited to two clock cycle latency because the AES pipelines202are pre-filled before starting the data stream, which is thus not experienced as latency, and the throughput of the secure DMA engine138is capable of processing the full bandwidth of communication (512 bits per DMA transfer). After performing the DMA transaction, the method700loops back to block704to stall the AES pipelines202and wait for additional signals.

Referring back to block706, if the secure DMA engine138determines that the last signal is asserted, the method700branches to block730, shown inFIG. 8. In block730, the secure DMA engine138captures length data in the intermediate AT register T. The register T may be updated according to one or more AES-GCM specifications. In particular, the updated value for T may be determined according to Equation 4, below. Len may be determined as len(A)∥len(C), that is, the length of the additional authenticated data concatenated with the length of the ciphertext. The operations of Equation 4 may be performed with two GF multipliers204in parallel, and may require 2 clock cycles.
T′=T·H4⊕Len·H(4)

In block732, the secure DMA engine138inserts a pre-counter block based on IV into an AES pipeline202. The pre-counter block may be determined according to one or more AES-GCM specifications. For example, the pre-counter block may be determined as IV∥(1d′32), that is, IV concatenated with a 32-bit counter value equal to decimal 1. To reduce latency, the pre-counter block may be inserted into the AES pipeline202in parallel with the GF multiplication operations of block730. In block734, the secure DMA engine138executes ten pipeline stages of the AES pipeline202to produce an encrypted pre-counter block. Executing the ten pipeline stages may require 10 clock cycles.

After waiting for execution of the pipeline stages, in block736the secure DMA engine138computes the final AT T based on the intermediate AT value in the register T and the encrypted pre-counter block. The final AT T may be determined according to one or more AES-GCM specifications. In particular, the final AT T may be determined according to Equation 5, below. Thus, calculation of the final AT T, including the operations of Equations 4 and 5 may involve two GF multiplications, one AES encryption, and two XOR operations. By starting the AES encryption in parallel with the GF multiplication, calculation of the final AT T may require eleven (11) clock cycles.
T′=T⊕CIPHK(IV∥1d′32)   (5)

In block738, the secure DMA engine138asserts a done signal or other signal indicating the final AT T has been computed. For example, in some embodiments, the secure DMA engine138may assert a predone pulse, release the final tag T, and then generate a done pulse. After asserting the done signal, the trusted execution environment302may verify the final authentication tag T to verify that the DMA transaction was authentic and not tampered with or otherwise altered. The processor120and/or the accelerator136may perform one or more processing operations on the transferred data. After asserting the done signal, the method700advances to block740, in which the secure DMA engine138waits for a start signal from the processor120. Upon the receiving the start signal, the DMA engine138may be reinitialized as described above in connection withFIG. 6and then may perform another DMA transfer.

As described above, the register T may be updated after each DMA transaction within a larger DMA transfer. In some embodiments, the processor120may read the register T at any time and compare that value to a corresponding value calculated by the processor120(e.g., by the trusted execution environment302) on the data transferred up to that time. Thus, the processor120may validate that the data was transferred with integrity as an intermediate validity check to provide an early warning of an integrity failure. In the case of an intermediate validity failure, the processor120may avoid transferring the remaining data and let the monitor (e.g., the trusted execution environment302) perform remedial actions earlier. For example, the intermediate checks may be performed after completion of data transfer of a DMA descriptor. Or, the intermediate checks may be performed as the processor120switches from one buffer to another when using a ping-pong buffer scheme to transfer data.

In the ping-pong buffer scheme, instead of allocating a buffer of the full size of the DMA transfer, the computing device100may allocate two buffers (A and B) to transfer in “installments” and coordinate when the sender can overwrite a buffer with the receiver. For example, the sender may fill buffer A and tell the receiver that data in A is ready for reading. The sender may continue to fill B, tell the receiver that buffer B is available, and then check or wait for the receiver to free A. The receiver reads A and when finished tells the sender that A is now available for overwrite. The receiver waits for the sender to tell that there is a new buffer ready (e.g., buffer B). The Sender writes the remaining data to A and so on, which the sender and receiver continuing to ping-pong between buffers A and B until all data has been sent and received.

Referring now toFIG. 9, in use, the computing device100may execute a method900for low-latency cryptography for processor-accelerator communication for a block of MMIO transactions. It should be appreciated that, in some embodiments, the operations of the method900may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3. The method900begins in block902, in which the computing device100initializes the security engine200(e.g., a secure MMIO engine140) using an initialization vector IV and a secret key K. The IV is a nonce value associated with a particular block of MMIO transactions. The security engine200may be initialized, for example, in response to a signal from the processor120caused by the trusted execution environment302. One potential embodiment of a method for initializing and managing a block of MMIO transactions that may be performed by the trusted execution environment302is described below in connection withFIG. 10.

The value for IV may be determined according to one or more AES-GCM specifications. The secret key K may be embodied as any symmetric encryption key used to protect data transferred between the processor120and the accelerator136. During initialization, the security engine200pre-computes values, primes encryption pipelines, and otherwise prepares to process data transfers. As described further, initializing the security engine200may hide pipeline latency or other latency associated with the security engine200. Initialization may require 14 clock cycles for MMIO. In block904, the security engine200derives a hash subkey H based on IV. The hash subkey H is determined according to one or more AES-GCM specifications, illustratively by encrypting a block with all bits set to zero using the secret key K. In block906, the security engine200primes one or more AES pipelines202with counter blocks based on IV. The initial counter block value CTR may be determined according to one or more AES-GCM specifications. In particular, the security engine200may prime one AES pipeline202with the initial counter block value CTR and prime another AES pipeline202with a pre-counter block (e.g., CTR−1) used for authentication tag generation. In block408, the security engine200pre-computes additional hash subkey values using one or more GF multipliers204. For example, the security engine200may compute H2=H·H, H3=H·H·H, and so on, where the symbol · denotes Galois field multiplication.

In block910, the security engine200checks for input MMIO data. The MMIO data may be embodied as 32 bits or 64 bits of data. In block912, the security engine200determines whether input data has been received. If so, the method900branches to block916, described below. If no input data was received, the method900branches to block914, in which the security engine200stalls the AES pipelines202. When the AES pipelines202are stalled, they retain their state and are prepared to output encrypted values on the next clock cycle. After stalling the AES pipelines202, the method900loops back to block910to continue checking for input MMIO data.

Referring back to block912, if input data was received, the method900branches to block916, in which the security engine200performs a cryptographic operation on the input data block. In some embodiments, in block918the security engine200may encrypt the input data using an AES pipeline202. For example, the security engine200may encrypt plaintext data received from the accelerator136before it is transferred to the processor120, as in an MMIO read response. In some embodiments, in block920the security engine200may decrypt the input data using an AES pipeline202. For example, the security engine200may decrypt ciphertext data received from the processor120before it is transferred to the accelerator136, as in an MMIO write.

In block922, the security engine200generates an authentication tag based on the ciphertext block(s). The ciphertext blocks may be the input data to the security engine200(e.g., for decryption operations) or the output data from the security engine200(e.g., for encryption operations). The AT may be generated using multiple GF multipliers204based on the ciphertext and one or more other values (e.g., hash subkeys H, H2, H3, additional authenticated information A, etc.). As described further below, the AT may be used by the processor120and/or the accelerator136to verify that an MMIO transaction was authentic and unaltered. After performing the cryptography operation and the authentication operation, the method900loops back to block910to continue monitoring for input MMIO data.

Referring now toFIG. 10, in use, the computing device100may execute a method1000for MMIO transaction block management. It should be appreciated that, in some embodiments, the operations of the method1000may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3, such as the trusted execution environment302. The method1000begins in block1002, in which the processor120asserts a start signal to the secure MMIO engine140. The processor120provides the initialization vector IV, secret key K, and additional authenticated data A to the secure MMIO engine140. The processor120may use any technique to security communicate that data to the secure MMIO engine140. As described above, IV is a nonce value associated with a block of MMIO transactions, and may be determined according to one or more AES-GCM specifications. The secret key K may be embodied as any symmetric encryption key used to protect data transferred between the processor120and the accelerator136. The key K may be protected from unauthorized disclosure by the trusted execution environment302, for example by being maintained in a secure enclave established using the secure enclave support122of the processor120. The additional authenticated data A may be embodied as any addressing data, metadata, or other data related to the MMIO transaction that will be authenticated but not encrypted by the secure MMIO engine140. In response to the start signal, the secure MMIO engine140performs an initialization process as described above. One potential embodiment of a method for initialization is described above in connection withFIG. 6.

In block1004, the processor120waits for a ready for data signal to be asserted by the secure MMIO engine140. As described above, the ready for data signal is asserted when the secure MMIO engine140completes its initialization process. The processor120may poll, wait for an interrupt, or otherwise monitor for the ready for data signal. After the ready for data signal is asserted, the method1000proceeds to block1006.

In block1006, the processor120loads an expected value of the authentication tag T for an MMIO request into a register of the secure MMIO engine140. The MMIO request may be embodied as an MMIO write request or an MMIO read request. The tag T may be determined by the processor120, for example by the trusted execution environment302, based on one or more AES-GCM specifications. In particular, the expected tag T may depend upon the ciphertext C and additional authenticated data A of the MMIO request. If the ciphertext C is not known ahead of time, for example for MMIO read requests, the tag T may be based on A with no C (e.g., C of length zero) or with a predetermined constant C or other known value of C (e.g., a zero block). As described further below, MMIO read responses may be generated by the accelerator136, and thus the processor120does not predetermine a tag T for MMIO read responses.

In block1008, the method1000switches based on whether the MMIO request is an MMIO write request or an MMIO read request. If the MMIO request is a read request, the method1000branches to block1014, described below. If the MMIO request is a write request, the method100branches to block1010.

In block1010, the processor120sends an MMIO write request to the secure MMIO engine140, including encrypted data (ciphertext) to be written to the accelerator136. As described further below, the encrypted data may be decrypted by the secure MMIO engine140and transferred to the accelerator136. The MMIO write request may be issued by the processor120using the MMIO engine128or other typical components of the processor120or SoC. MMIO requests are typically performed with small (e.g., 64-bit) payloads, and there may be an MMIO request every clock cycle that requires confidentiality and integrity protection. The execution of an MMIO transaction is conditional on the integrity of the MMIO transaction request. The MMIO request may include an address in MMIO space, encrypted data, or other data associated with the MMIO request. One potential embodiment of a method for processing MMIO write requests that may be performed by the secure MMIO engine140is described below in connection withFIG. 11.

In block1012, the processor120securely reads a fail flag from the secure MMIO engine140. As described further below, for MMIO write requests the secure MMIO engine140calculates a final AT value and compares it to the expected AT value provided by the processor120in connection with block1006. If the final AT value and the expected AT value do not match, then the secure MMIO engine140sets the fail flag. After reading the fail flag, the method1000advances to block1022.

In block1022, the processor120checks whether the MMIO write request was successfully performed (e.g., whether or not the fail flag was set). If the write was not successful, the method1000branches to block1024, in which the processor120indicates an authentication error. Referring back to block1022, if the MMIO write request was successfully performed, the method1000loops back to block1006, in which the processor120may perform additional MMIO requests.

Referring back to block1008, if the MMIO request is a read request, the method1000branches to block1014, in which the processor120sends an MMIO read request. The MMIO read request may be issued by the processor120using the MMIO engine128or other typical components of the processor120or SoC. As described above, MMIO requests are typically performed with small (e.g., 64-bit) payloads, and there may be an MMIO request every clock cycle that requires confidentiality and integrity protection. The execution of the MMIO transaction is conditional on the integrity of the MMIO transaction request. The MMIO read request may include an address in MMIO space or other data associated with the MMIO read request. One potential embodiment of a method for processing MMIO read requests that may be performed by a secure MMIO engine140is described below in connection withFIG. 11.

In some embodiments, in block1016, the processor120securely reads a fail flag from the secure MMIO engine140. As described further below, for MMIO read requests the secure MMIO engine140calculates a final AT value and compares it to the expected AT value provided by the processor120in connection with block1006. If the final AT value and the expected AT value do not match, then the secure MMIO engine140sets the fail flag.

In block1018the processor120may receive an MMIO read response with encrypted data (ciphertext) from the secure MMIO engine140. As described further below, the encrypted data may be generated by the secure MMIO engine140, which may read plaintext data from the accelerator device136. In some embodiments, the MMIO read response may be received only if the MMIO read request was successful. Additionally or alternatively, in some embodiments an arbitrary MMIO read response may be returned if the MMIO read request was not successful. Additionally or alternatively, in some embodiments a poisoned MMIO read response may be returned if the MMIO read request was not successful. The poisoned response and AT will be calculated to guarantee the AT generated by the secure MMIO engine140mismatches the AT calculated by the processor120on the poisoned response. One potential embodiment of a method for processing MMIO read responses that may be performed by a secure MMIO engine140is described below in connection withFIG. 11. Additionally or alternatively, although illustrated as being performed by the same secure MMIO engine140, in some embodiments, a different secure MMIO engine140may process MMIO transactions in each direction. For example, two different secure MMIO engines140may process MMIO requests (read requests and write requests) and MMIO read responses, respectively.

In block1020the processor120reads a final AT value from the secure MMIO engine140and compares that value to an AT value for the MMIO read response calculated by the processor120. The calculated AT value may be determined by the processor120based on the ciphertext received in the MMIO read response. If the final AT value matches the calculated AT value, then the MMIO read response was performed successfully. If the final AT value does not match, then either the MMIO read response was not performed successfully or the MMIO read request was not performed successfully. For example, as described further below, if the MMIO read request is not successful, the secure MMIO engine140may return an arbitrary MMIO read response and a poisoned AT value that does not match the MMIO read response.

In block1022the processor120checks whether the MMIO read request was successfully performed. For example, the processor120may determine whether or not the fail flag was set after sending the MMIO read request and/or the processor120may determine whether the AT received from the secure MMIO engine140matches the calculated AT for the MMIO read response. If the MMIO read request was not successful, the method1000branches to block1024, in which the processor120indicates an authentication error. Referring back to block1022, if the MMIO read request was successfully performed, the method1000loops back to block1006, in which the processor120may perform additional MMIO requests.

Referring now toFIG. 11, in use, the secure MMIO engine140of the computing device100may execute a method1100for performing secure MMIO transactions, including MMIO read requests, MMIO write requests, and/or MMIO read responses. It should be appreciated that, in some embodiments, the operations of the method1100may be performed by one or more components of the environment300of the computing device100as shown inFIG. 3, such as the security engine200(e.g., the secure MMIO engine140). The method1100begins in block1102, in which the secure MMIO engine140inserts a pre-counter block based on IV into an AES pipeline202(pipeline2). The pre-counter block may be determined according to one or more AES-GCM specifications. For example, the pre-counter block may be determined as IV∥(1d′32), that is, IV concatenated with a 32-bit counter value equal to decimal 1. To reduce latency, the pre-counter block may be inserted during initialization of the secure MMIO engine140or otherwise before processing MMIO transaction. For example, the pre-counter block may be inserted during initialization as described above in connection with block902ofFIG. 9and in connection withFIG. 6.

In block1104, the secure MMIO engine140determines whether an MMIO transaction has been received. The MMIO transaction may be an MMIO read request, an MMIO write request, or an MMIO read response. MMIO read requests and MMIO write requests may be received from the processor120, and MMIO read responses may be received from the accelerator136. Additionally or alternatively, as described above, in some embodiments separate MMIO engines140may receive MMIO requests (MMIO read requests and MMIO write requests) and MMIO read responses, respectively. If no MMIO transaction was received, the method1100loops back to block1104to continue waiting for MMIO transactions. While waiting for transactions, the AES pipelines202of the secure MMIO engine140may be stalled to preserve pipeline state. If an MMIO transaction is received, then the method1100advances to block1106.

In block1106, the secure MMIO engine140bitwise exclusive ORs (XOR, or the symbol ⊕) the input data block with the current output of an AES pipeline202(pipeline1). The input data block may be 32 bits or 64 bits in length. The AES pipeline1was primed with counter blocks during initialization of the secure MMIO engine140as described above in connection with block902ofFIG. 9and withFIG. 6. Thus, XORing the output of the pipeline1with the input data performs a cryptographic operation on the input data. In some embodiments, in block1108the secure MMIO engine140decrypts ciphertext C to generate plaintext P, for example when processing an MMIO write request from the processor120. In that example, the secure MMIO engine140calculates P=C⊕202. In some embodiments, in block1110the secure MMIO engine140performs an encryption operation with a predetermined constant ciphertext C or an empty ciphertext C, for example when processing an MMIO read request from the processor120. The predetermined ciphertext C may be, for example, a block of data with each bit set to zero. In that example, the MMIO read request does not include a data payload, and thus the cryptographic operation may be performed to facilitate generation of the authentication tag T. In some embodiments, in block1112the secure MMIO engine140encrypts plaintext P to generate ciphertext C, for example when processing an MMIO read response from the accelerator136. In that example, the secure MMIO engine140calculates C=P⊕202.

In block1114, the secure MMIO engine140generates a final authentication tag T for the MMIO transaction. The tag T may be generated according to one or more AES-GCM specifications. The generation of the final authentication tag T may be performed according to Equation 6, below. In block1116, the secure MMIO engine140performs GF multiplications of A·H3and C·H2using two GF multipliers204. As described above, in some embodiments the ciphertext C may be a predetermined constant value (e.g., a zero block) for MMIO read requests or other transactions that do not include a data payload. In block1118, the secure MMIO engine140performs a bitwise XOR of the results of the GF multiplication as well as the pre-computed value of Len·H and the output of the AES pipeline202that encrypted the pre-counter block (pipeline2). As described above, the length of MMIO transactions is known, and thus the value Len·H may be precomputed during initialization. Because the value Len·H is precomputed, using two GF multipliers204in parallel may allow the operations of Equation 6 to be completed in one clock cycle. Thus, when input data is received during a clock cycle, the ciphertext/plaintext and the AT may be generated in the following clock cycle. As described above, the AES pipelines202(pipeline1and pipeline2) are pre-filled during initialization, which hides the pipeline latency.
T=A·H3⊕C·H2⊕Len·H⊕CIPHK(IV∥1d′32)   (6)

In block1120, the secure MMIO engine140may determine whether the final AT value T matches an AT value stored in a register by the processor120before the MMIO transaction. As described above in connection withFIG. 10, the processor120may write the expected AT value before issuing an MMIO write request or an MMIO read request. If the final AT value does not match the expected AT value, then an error or attempted attack (e.g., attempted splicing attack or DoS attack) may have occurred. For example, writes to the AT register and MMIO transaction requests may be non-atomic, which may allow an attacker to write an incorrect value to the AT register and/or send a false MMIO request. In those circumstances, the AT values would not match, indicating a potential attack. As another example, a malicious actor may submit an improper MMIO transaction request (e.g., an MMIO transaction request with an incorrect AT). In block1122, the secure MMIO engine140checks whether the AT values match. If not, the method1100branches to block1130, described below. If the AT values match, the method1100branches to block1124. It should be understood that for MMIO read responses generated by the accelerator136, the processor120does not write an expected AT value and thus the secure MMIO engine140may not check AT values. If no AT check is performed, the method1100advances to block1124.

In block1124, the secure MMIO engine140increments IV and updates the associated counter CTR. For a blocked session of multiple MMIO transactions, the value for IV may be incremented for each MMIO transaction. The counter block may be determined according to one or more AES-GCM specifications. As described above, CTR may be determined as CTR=IV∥(2d′32), that is, a 128-bit value equal to IV concatenated with a 32-bit counter initialized to the decimal value “2.” In block1126, the secure MMIO engine140inserts the CTR block to pipeline1and a pre-counter block to pipeline2. As described above, the pre-counter block may be determined as IV∥1d′32, that is, IV concatenated with a 32-bit counter initialized to decimal “1.” In block1128, the AES pipeline stages are executed. Accordingly, because CTR and the pre-counter block may be pre-determined and pre-executed, the AES pipelines202for performing the cryptographic operation and generating the tag T (i.e., pipeline1and pipeline2) are pre-filled to reduce latency for subsequent MMIO transactions in the same block of transactions. After executing the pipeline stages, the method1100loops back to block1104to process additional MMIO transactions.

Referring back to block1122, if the AT value written by the processor120and the final AT value generated by the secure MMIO engine140do not match, the method1100branches to block1130, in which the secure MMIO engine140sets the fail flag. In response to a mismatch, the secure MMIO engine140may drop packets or otherwise prevent the MMIO transaction from reaching the accelerator136. Thus, the secure MMIO engine140may prevent splicing or spoofing attacks and other improperly formed MMIO requests. For a mismatched MMIO read request, the secure MMIO engine140may send an arbitrary MMIO read response and store a poisoned AT (e.g., a mismatched AT or other AT that indicates failure) that may allow the processor120to detect the authentication failure. Additionally or alternatively, storing a poisoned AT may not be necessary if the processor120checks the fail flag for success of the MMIO read request. Note that in the case of an AT mismatch, the secure MMIO engine140does not increment IV or the CTR block and does not execute any pipeline stages. Thus, the state of the secure MMIO engine140is unchanged, and the processor120(e.g., the trusted execution environment302) and the secure MMIO engine140may remain synchronized for future MMIO transactions. Accordingly, by avoiding the need to re-synchronize after an incorrect AT and/or MMIO transaction, the MMIO engine may prevent certain denial-of-service (DoS) attacks without additional performance overhead. After setting the fail flag, the method1100loops back to block1104in which the secure MMIO engine140processes additional MMIO transactions.

It should be appreciated that, in some embodiments, the methods400,500,600,700,900,1000, and/or1100may be embodied as various instructions stored on a computer-readable media, which may be executed by the processor120, the I/O subsystem124, the secure DMA engine138, the secure MMIO engine140, the accelerator136, and/or other components of the computing device100to cause the computing device100to perform the respective method400,500,600,700,900,1000, and/or1100. The computer-readable media may be embodied as any type of media capable of being read by the computing device100including, but not limited to, the memory130, the data storage device132, firmware devices, other memory or data storage devices of the computing device100, portable media readable by a peripheral device142of the computing device100, and/or other media.

EXAMPLES

Example 1 includes a computing device for secure data transfer, the computing device comprising: a hardware security engine that comprises a plurality of block cipher pipelines and a plurality of Galois field multipliers; an initialization manager to initialize the hardware security engine with an initialization vector and a secret key; and a transfer manager to initiate a data transfer operation between a trusted execution environment of the computing device and an accelerator device of the computing device in response to initialization of the hardware security engine; wherein the hardware security engine is to perform an authenticated cryptographic operation for the data transfer operation in response to initiation of the data transfer operation.

Example 2 includes the subject matter of Example 1, and wherein each block cipher pipeline of the plurality of block cipher pipelines comprises a 128-bit AES block cipher pipeline.

Example 3 includes the subject matter of any of Examples 1 and 2, and wherein to perform the authenticated cryptographic operation comprises to perform an authenticated encryption operation or an authenticated decryption operation.

Example 4 includes the subject matter of any of Examples 1-3, and wherein the authenticated cryptographic operation comprises an AES Galois/Counter mode (AES-GCM) cryptographic operation.

Example 5 includes the subject matter of any of Examples 1-4, and wherein to initialize the hardware security engine comprises to: insert a zero block into a first block cipher pipeline, wherein the each bit of the zero block equals zero; derive, by the hardware security engine, a hash subkey as a function of an output of the first block cipher pipeline in response to inserting the zero block; initialize an initial counter block as a function of the initialization vector; and insert, for each block cipher pipeline of the plurality of block cipher pipelines, a counter block based on the initial counter block into the block cipher pipeline.

Example 6 includes the subject matter of any of Examples 1-5, and wherein to initialize the hardware security engine further comprises to: receive a start signal by the hardware security engine; and assert a ready signal by the hardware security engine in response to insertion of the counter block; wherein to insert the zero block comprises to insert the zero block in response to receipt of the start signal, and wherein to initialize the initial counter block comprises to initialize the initial counter block in response to the receipt of the start signal.

Example 7 includes the subject matter of any of Examples 1-6, and wherein to initialize the hardware security engine further comprises to: execute, by the hardware security engine, a predetermined number of block cipher rounds with the plurality of block cipher pipelines in response to the insertion of the counter block; wherein to assert the ready signal further comprises to assert the ready signal in response to execution of the predetermined number of block cipher rounds.

Example 8 includes the subject matter of any of Examples 1-7, and wherein to initialize the hardware security engine further comprises to stall the plurality of block cipher pipelines in response to the execution of the predetermined number of block cipher rounds.

Example 9 includes the subject matter of any of Examples 1-8, and wherein: to initiate the data transfer operation comprises to initiate a direct memory access operation with a plurality of input data blocks; and to perform the authenticated cryptographic operation comprises to: perform, by the hardware security engine, a cryptographic operation with the plurality of block cipher pipelines on the plurality of input data blocks to generate a plurality of output data blocks; and update, by the hardware security engine, an intermediate authentication tag value register based on a plurality of ciphertext blocks, wherein the plurality of ciphertext blocks comprises the plurality of input data blocks or the plurality of output data blocks.

Example 10 includes the subject matter of any of Examples 1-9, and wherein the authenticated cryptographic operation comprises an authenticated encryption operation and the plurality of ciphertext blocks comprises the plurality of output data blocks.

Example 11 includes the subject matter of any of Examples 1-10, and wherein the authenticated cryptographic operation comprises an authenticated decryption operation and the plurality of ciphertext blocks comprises the plurality of input data blocks.

Example 12 includes the subject matter of any of Examples 1-11, and wherein to perform the cryptographic operation comprises to: read, by the hardware security engine, the plurality of input data blocks; bitwise exclusive OR, by the hardware security engine, each of the plurality of input data blocks with an output of a block cipher pipeline to generate the plurality of output data blocks; and insert, for each block cipher pipeline of the plurality of block cipher pipelines, an incremented counter block into the block cipher pipeline in response to a bitwise exclusive OR.

Example 13 includes the subject matter of any of Examples 1-12, and wherein to update the intermediate authentication tag value comprises to perform, for each ciphertext block of the plurality of ciphertext blocks, a Galois field multiplication with a Galois field multiplier as a function of a hash subkey and the ciphertext block.

Example 14 includes the subject matter of any of Examples 1-13, and wherein the plurality of block cipher pipelines comprises four AES pipelines and the plurality of Galois field multipliers comprises five Galois field multipliers.

Example 15 includes the subject matter of any of Examples 1-14, and wherein the hardware security engine is further to: receive a last signal; and generate a final authentication tag value as a function of the intermediate authentication tag value register in response to receipt of the last signal.

Example 16 includes the subject matter of any of Examples 1-15, and wherein the transfer manager is further to: read, by the trusted execution environment, the final authentication tag value from the hardware security engine; calculate, by the trusted execution environment, an expected authentication tag value for the data transfer operation; and compare, by the trusted execution environment, the final authentication tag value to the expected authentication tag value.

Example 17 includes the subject matter of any of Examples 1-16, and wherein: to initiate the data transfer operation comprises to initiate a memory-mapped I/O operation with an input data block; and to perform the authenticated cryptographic operation comprises to: perform, by the hardware security engine, a cryptographic operation with a block cipher pipeline on the input data block to generate an output data block; and generate, by the hardware security engine, a final authentication tag value based on a ciphertext block, wherein the ciphertext block comprises the input data block or the output data block.

Example 18 includes the subject matter of any of Examples 1-17, and wherein the authenticated cryptographic operation comprises an authenticated encryption operation and the ciphertext block comprises the output data block.

Example 19 includes the subject matter of any of Examples 1-18, and wherein the authenticated cryptographic operation comprises an authenticated decryption operation and the ciphertext block comprises the input data block.

Example 20 includes the subject matter of any of Examples 1-19, and wherein: the transfer manager is further to (i) calculate, by the trusted execution environment, an expected authentication tag value for the data transfer operation, and (ii) write, by the trusted execution environment, the expected authentication tag value to the hardware security engine; and the hardware security engine is to compare the expected authentication tag value to the final authentication tag value.

Example 21 includes the subject matter of any of Examples 1-20, and wherein to perform the cryptographic operation comprises to: read, by the hardware security engine, the input data block; bitwise exclusive OR, by the hardware security engine, the input data block with an output of the block cipher pipeline to generate the output data block; and insert an incremented counter block into the block cipher pipeline in response to a bitwise exclusive ORing and in response to comparison of the expected authentication tag value to the final authentication tag value.

Example 22 includes the subject matter of any of Examples 1-21, and wherein to generate the final authentication tag value comprises to perform a Galois field multiplication with a Galois field multiplier as a function of a hash subkey and the ciphertext block.

Example 23 includes the subject matter of any of Examples 1-22, and wherein the plurality of block cipher pipelines comprises two AES pipelines and the plurality of Galois field multipliers comprises two Galois field multipliers.

Example 24 includes a method for secure data transfer, the method comprising: initializing, by a computing device, a hardware security engine of the computing device with an initialization vector and a secret key, wherein the hardware security engine comprises a plurality of block cipher pipelines and a plurality of Galois field multipliers; initiating, by the computing device, a data transfer operation between a trusted execution environment of the computing device and an accelerator device of the computing device in response to initializing the hardware security engine; and performing, by the hardware security engine, an authenticated cryptographic operation for the data transfer operation in response to initiating the data transfer operation.

Example 25 includes the subject matter of any of Example 24, and wherein each block cipher pipeline of the plurality of block cipher pipelines comprises a 128-bit AES block cipher pipeline.

Example 26 includes the subject matter of any of Examples 24 and 25, and wherein performing the authenticated cryptographic operation comprises performing an authenticated encryption operation or an authenticated decryption operation.

Example 27 includes the subject matter of any of Examples 24-26, and wherein the authenticated cryptographic operation comprises an AES Galois/Counter mode (AES-GCM) cryptographic operation.

Example 28 includes the subject matter of any of Examples 24-27, and wherein initializing the hardware security engine comprises: inserting a zero block into a first block cipher pipeline, wherein the each bit of the zero block equals zero; deriving, by the hardware security engine, a hash subkey as a function of an output of the first block cipher pipeline in response to inserting the zero block; initializing an initial counter block as a function of the initialization vector; and inserting, for each block cipher pipeline of the plurality of block cipher pipelines, a counter block based on the initial counter block into the block cipher pipeline.

Example 29 includes the subject matter of any of Examples 24-28, and wherein initializing the hardware security engine further comprises: receiving a start signal by the hardware security engine; and asserting a ready signal by the hardware security engine in response to inserting the counter block; wherein inserting the zero block comprises inserting the zero block in response to receiving the start signal, and wherein initializing the initial counter block comprises initializing the initial counter block in response to receiving the start signal.

Example 30 includes the subject matter of any of Examples 24-29, and wherein initializing the hardware security engine further comprises: executing, by the hardware security engine, a predetermined number of block cipher rounds with the plurality of block cipher pipelines in response to inserting the counter block; wherein asserting the ready signal further comprises asserting the ready signal in response to executing the predetermined number of block cipher rounds.

Example 31 includes the subject matter of any of Examples 24-30, and wherein initializing the hardware security engine further comprises stalling the plurality of block cipher pipelines in response to executing the predetermined number of block cipher rounds.

Example 32 includes the subject matter of any of Examples 24-31, and wherein: initiating the data transfer operation comprises initiating a direct memory access operation with a plurality of input data blocks; and performing the authenticated cryptographic operation comprises: performing, by the hardware security engine, a cryptographic operation with the plurality of block cipher pipelines on the plurality of input data blocks to generate a plurality of output data blocks; and updating, by the hardware security engine, an intermediate authentication tag value register based on a plurality of ciphertext blocks, wherein the plurality of ciphertext blocks comprises the plurality of input data blocks or the plurality of output data blocks.

Example 33 includes the subject matter of any of Examples 24-32, and wherein the authenticated cryptographic operation comprises an authenticated encryption operation and the plurality of ciphertext blocks comprises the plurality of output data blocks.

Example 34 includes the subject matter of any of Examples 24-33, and wherein the authenticated cryptographic operation comprises an authenticated decryption operation and the plurality of ciphertext blocks comprises the plurality of input data blocks.

Example 35 includes the subject matter of any of Examples 24-34, and wherein performing the cryptographic operation comprises: reading, by the hardware security engine, the plurality of input data blocks; bitwise exclusive ORing, by the hardware security engine, each of the plurality of input data blocks with an output of a block cipher pipeline to generate the plurality of output data blocks; and inserting, for each block cipher pipeline of the plurality of block cipher pipelines, an incremented counter block into the block cipher pipeline in response to bitwise exclusive ORing.

Example 36 includes the subject matter of any of Examples 24-35, and wherein updating the intermediate authentication tag value comprises performing, for each ciphertext block of the plurality of ciphertext blocks, a Galois field multiplication with a Galois field multiplier as a function of a hash subkey and the ciphertext block.

Example 37 includes the subject matter of any of Examples 24-36, and wherein the plurality of block cipher pipelines comprises four AES pipelines and the plurality of Galois field multipliers comprises five Galois field multipliers.

Example 38 includes the subject matter of any of Examples 24-37, and further comprising: receiving, by the hardware security engine, a last signal; and generating, by the hardware security engine, a final authentication tag value as a function of the intermediate authentication tag value register in response to receiving the last signal.

Example 39 includes the subject matter of any of Examples 24-38, and further comprising: reading, by the trusted execution environment, the final authentication tag value from the hardware security engine; calculating, by the trusted execution environment, an expected authentication tag value for the data transfer operation; and comparing, by the trusted execution environment, the final authentication tag value to the expected authentication tag value.

Example 40 includes the subject matter of any of Examples 24-39, and wherein: initiating the data transfer operation comprises initiating a memory-mapped I/O operation with an input data block; and performing the authenticated cryptographic operation comprises: performing, by the hardware security engine, a cryptographic operation with a block cipher pipeline on the input data block to generate an output data block; and generating, by the hardware security engine, a final authentication tag value based on a ciphertext block, wherein the ciphertext block comprises the input data block or the output data block.

Example 41 includes the subject matter of any of Examples 24-40, and wherein the authenticated cryptographic operation comprises an authenticated encryption operation and the ciphertext block comprises the output data block.

Example 42 includes the subject matter of any of Examples 24-41, and wherein the authenticated cryptographic operation comprises an authenticated decryption operation and the ciphertext block comprises the input data block.

Example 43 includes the subject matter of any of Examples 24-42, and further comprising: calculating, by the trusted execution environment, an expected authentication tag value for the data transfer operation; writing, by the trusted execution environment, the expected authentication tag value to the hardware security engine; and comparing, by the hardware security engine, the expected authentication tag value to the final authentication tag value.

Example 44 includes the subject matter of any of Examples 42-43, and wherein performing the cryptographic operation comprises: reading, by the hardware security engine, the input data block; bitwise exclusive ORing, by the hardware security engine, the input data block with an output of the block cipher pipeline to generate the output data block; and inserting an incremented counter block into the block cipher pipeline in response to bitwise exclusive ORing and in response to comparing the expected authentication tag value to the final authentication tag value.

Example 45 includes the subject matter of any of Examples 24-44, and wherein generating the final authentication tag value comprises performing a Galois field multiplication with a Galois field multiplier as a function of a hash subkey and the ciphertext block.

Example 46 includes the subject matter of any of Examples 24-45, and wherein the plurality of block cipher pipelines comprises two AES pipelines and the plurality of Galois field multipliers comprises two Galois field multipliers.

Example 48 includes one or more non-transitory, computer readable storage media comprising a plurality of instructions stored thereon that in response to being executed result in a computing device performing the method of any of Examples 24-46.

Example 49 includes a computing device comprising means for performing the method of any of Examples 24-46.