Delay-controlled integrity and data encryption (IDE)

Abstract

Techniques for providing integrity and data encryption (IDE) with zero latency are described. A receiving device having a cryptographic circuit with an Advanced Encryption Standard (AES) engine having a fixed time element size and a fixed delay for an IDE may transmit a latency parameter to a transmitting device. The delay parameter represents a number of clock cycles corresponding to the fixed delay. The cryptographic circuitry may use the AES engine to pre-determine AES data for a first time element before first input data for the first time element is received from the transmission device. After the number of clock cycles, the cryptographic circuitry may receive first input data from the transmitting device. The cryptographic circuit may determine first output data for the first time element using the AES data and the first input data without storing the AES data in the buffer.

Description

Background Art

[0001] Modern computer systems typically include one or more memory devices, such as memory devices on memory modules. A memory module may include, for example, one or more random access memory (RAM) devices or dynamic random access memory (DRAM) devices. A memory device may include a memory bank composed of memory cells, wherein a memory controller or a memory client accesses the memory cells through a command interface and a data interface within the memory device. A memory module may include one or more volatile memory devices. A memory module may be a permanent memory module having one or more non-volatile memory (NVM) devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings.

[0003] Figure 1 is a block diagram of a transmitting device and a receiving device having a delay controlled cryptographic circuit for integrity and data encryption (IDE) according to at least one embodiment.

[0004] Figure 2 is a block diagram of an in-line memory encryption (IME) block for latency controlled IDE according to at least one embodiment.

[0005] Figure 3 is a timing diagram of a transmitting device and a receiving device for delay controlled IDE according to at least one embodiment.

[0006] Figure 4 is a block diagram of a delay controlled cryptographic circuit with an Advanced Encryption Standard (AES) engine having multiple levels of pipelines and an XOR operation according to at least one embodiment.

[0007] Figure 5 It shows how to achieve zero latency within 7 clock cycles of the pipeline of an AES engine according to at least one embodiment.

[0008] Figure 6 shows how to use the Figure 5 The pipeline is stalled.

[0009] Figure 7 is a block diagram of a memory system having a memory module including an IME block with latency control according to at least one embodiment.

[0010] Figure 8is a block diagram of an integrated circuit including a memory controller, an encryption circuit with latency control, and a management processor according to at least one embodiment.

[0011] Fig. 9 A method 900 is shown according to one embodiment. DETAILED DESCRIPTION

[0012] The following description sets forth many specific details, such as examples of specific systems, components, methods, etc., in order to provide a good understanding of several embodiments of the present disclosure. However, it will be apparent to those skilled in the art that at least some embodiments of the present disclosure may be practiced without these specific details. In other cases, known components or methods are not described in detail or are presented in a simple block diagram format to avoid unnecessarily obscuring the present disclosure. Therefore, the specific details set forth are merely exemplary. Specific implementations may differ from these exemplary details and are still contemplated to be within the scope of the present disclosure.

[0013] Data center architectures are evolving to support workloads for emerging applications in artificial intelligence and machine learning that require high-speed, low-latency, cache-coherent interconnects. (Compute Express ) is an industry-supported cache-coherent interconnect for processors, memory expansion, and accelerators. The technology defines a mechanism called Integrity and Data Encryption (IDE) for The link provides confidentiality, integrity, and replay protection for data transmitted. The IDE mechanism can protect the business within the trusted execution environment (TEE) of multiple components. One IDE algorithm is the Advanced Encryption Standard (AES) Galois / Counter Mode (GCM) (hereinafter referred to as the AES-GCM algorithm). The AES-GCM algorithm uses AES-256 for encryption and uses a hash function called GHASH to generate a message authentication code (MAC) for the authentication tag. AES-GCM also supports additional authentication data (AAD) that is authenticated using GHASH but transmitted as plaintext. The GHASH algorithm belongs to a class of Wegman-Carter polynomial universal hashes. Other encryption and authentication algorithms can be used.

[0014] The protocol is highly sensitive to delay, and the IDE algorithm AES-GCM has a delay penalty at the beginning of EPOCH (also referred to herein as epoch). The AES engine may spend 7 or 14 cycles to calculate the AES data for output starting from the input of EPOCH. For example, a basic AES operation may include expanding the key, performing initial processing on the input data, and then repeating multiple rounds of calculations 7 or 14 times to provide output, thereby generating 7 or 14 cycles for the basic AES operation. For example, an integrated circuit operating at 1GHz may require one cycle for each round of calculation, thereby generating 14 cycles for a 128-bit output. Another integrated circuit may perform two rounds of calculations in one clock cycle, thereby generating 7 cycles for a 128-bit output. In this way, there is a delay penalty of 7 or 14 clock cycles.

[0015] Aspects and embodiments of the present disclosure address these and other problems by providing a delay-controlled cryptographic circuit that can have zero or low latency for IDE by calculating AES data in advance before the AES data is needed and performing an XOR operation on the main data path with the input data when the input data arrives. The delay-controlled cryptographic circuit can control when the input data (e.g., plaintext or ciphertext) arrives to correspond to when the AES data is ready for the XOR operation in the main data path. The delay-controlled cryptographic circuit can prepare the AES engine to receive the corresponding flits without delay. A flit (also called a flow control unit or digit) is a link-level atomic data piece that forms a network packet or stream. The AES engine can have a predetermined input and calculate an AES output. The AES output can be predetermined by the AES engine and can be used for the XOR operation when the input data (e.g., plaintext or ciphertext) arrives at the main data path.

[0016] Aspects and embodiments of the present disclosure may be used in all applications that have a fixed epoch size (also referred to as a fixed epoch length) when using the AES-GCM algorithm. In the IDE specification, the input to an AES engine (e.g., an AES encoder or an AES decoder) is predefined with a fixed epoch size of 5 or 128 microchips, and the AES engine has a fixed delay, such as 7 or 14 clock cycles. The programmable pre-operation delay of the AES engine can be used to pre-calculate the required AES data before normal operation of transmitting or receiving data. The AES output can be prepared before or when needed. Various aspects and embodiments of the present disclosure can be used for all applications with a variable epoch size range but fixed to a known epoch size. With the pre-known epoch size, the input to the AES engine can be predetermined and prepared at the appropriate time. Even if the epoch size is truncated, such as As allowed by the IDE specification, delay-controlled cryptographic circuits can also correctly handle this epoch by flushing the AES pipeline with a defined delay.

[0017] It should be noted that some solutions have considered pre-calculating the AES output to reduce latency, but these solutions require additional buffers or static random access memory (SRAM) to store the AES data until the AES data is needed. The main problem is that the buffer usually has an access delay (such as 2 or 3), and the area and power consumption of the buffer are large. Aspects and embodiments of the present disclosure can pre-calculate all required AES outputs at the right time, so no additional buffers or SRAM are needed to store the AES outputs in advance. Removing the additional buffers or SRAM used to store the AES output can significantly reduce latency, implementation area, and power.

[0018] Aspects and embodiments of the present disclosure may use an AES stall mechanism to control the AES pipeline to stall both input and output without data transfer stalling or stalling. Aspects and embodiments of the present disclosure may calculate MAC in parallel as data arrives. As described herein, MAC may be used to verify the correctness of encrypted data. A MAC (authentication tag) may be calculated as part of a MAC calculation path.

[0019] In at least one embodiment, the delay controlled cryptographic circuit may be supported Technical equipment (such as part of a memory module). The memory module may include a DRAM (eg, one or more volatile memory devices) and / or a permanent storage memory (eg, one or more NVM devices). Controller or Memory expansion devices (e.g. Memory expander system on chip (SoC). The memory expansion device may include a management processor. The memory expansion device may include error correction code (ECC) circuitry to detect and correct errors in data read from the memory or transferred between entities. Memory expansion devices can be used A memory module (such as an IME circuit) to encrypt the host's unencrypted data before storing it in DRAM. The IME circuit can generate a MAC as described herein that can be used to authenticate the encrypted data.

[0020] Figure 11 is a block diagram of a transmission device 102 and a receiving device 104 having a delay controlled cryptographic circuit 110 and a delay controlled cryptographic circuit 106 for integrity and data encryption (IDE), respectively, according to at least one embodiment. The receiving device 104 includes the delay controlled cryptographic circuit 106 having an AES engine 108. The AES engine 108 has a fixed epoch size and a fixed delay for receiving (RX) IDE. The delay controlled cryptographic circuit 106 can send a delay parameter to the transmission device 102. The receiving device 104 and the transmission device 102 can be connected via a link 114. The link 114 can be any type of connection between the two devices. The delay parameter can represent a certain number of clock cycles corresponding to the fixed delay of the AES engine 108. Before receiving the first input data of the first epoch from the transmission device 102, the delay controlled cryptographic circuit 106 can use the AES engine 108 to predetermine the AES data for the first epoch. After the number of clock cycles, the delay controlled cryptographic circuit 106 can receive the first input data from the transmission device 102. The delay controlled cryptographic circuit 106 can use the AES data and the first input data to determine the first output data for the first epoch without storing the AES data in a buffer. That is, the receiving device 104 does not have an additional buffer or SRAM dedicated to storing the AES data. When the first input data arrives from the transmission device 102, the AES data is ready. When the first input data arrives at the delay controlled cryptographic circuit 106, the delay controlled cryptographic circuit 106 can perform an XOR operation using the first input data and the AES data to obtain the first output data. In at least one embodiment, the first input data is a ciphertext, and the first output data is a plaintext. For example, the transmission device 102 can send encrypted data including ciphertext to the receiving device 104 via the link 114, and the receiving device 104 can decrypt the encrypted data including the plaintext. In at least one embodiment, the first input data is a ciphertext, and the first output data is a plaintext. The delay controlled cryptographic circuit 106 can perform these operations in the receiving device 104 to achieve zero delay or low delay for RX IDE.

[0021] Similar operations can be performed on the transmission device 102 to achieve zero or low latency for sending (TX) IDE. In at least one embodiment, the transmission device 102 includes a delay-controlled cryptographic circuit 110 with an AES engine 112. The AES engine 112 has a fixed epoch size and a fixed delay for TX IDE. Before the first input data of the first epoch is input to the AES engine 112, the delay-controlled cryptographic circuit 110 can use the AES engine 112 to predetermine the AES data for the first epoch. After a first number of clock cycles corresponding to the delay of the AES engine 112, the delay-controlled cryptographic circuit 110 can use the AES data and the first input data to determine the first output data for the first epoch without storing the AES data in a buffer. In other words, the transmission device 102 does not have an additional buffer or SRAM dedicated to storing AES data. When the first input data is input into the AES engine 112, the AES data is ready. When the first input data arrives at the AES engine 112, the delay controlled cryptographic circuit 110 can perform an XOR operation using the first input data and the AES data to obtain the first output data. The transmission device 102 can send the first output data to the receiving device 104. In at least one embodiment, the first input data is plain text, and the first output data is cipher text. For example, the transmission device 102 can send encrypted data including cipher text to the receiving device 104 through the link 114, and the receiving device 104 can decrypt the encrypted data including the plain text. In at least one embodiment, the first input data is cipher text, and the first output data is plain text. In some cases, the delay controlled cryptographic circuit 110 can send a delay parameter to the receiving device 104 to indicate a first number of clock cycles. The delay controlled cryptographic circuit 106 can perform these operations in the receiving device 104 to achieve zero delay or low delay for RX IDE.

[0022] In at least one embodiment, before predetermining the AES data for the first epoch, the delay controlled cryptographic circuit 106 may predetermine the AES input data for the first epoch. For example, the delay controlled cryptographic circuit 106 may predetermine the AES input data from a counter output. The counter may receive an initialization vector (IV) to generate a counter output. The counter may be incremented for each round of calculation. The output of the counter may be used to predetermine the AES data before the data for the first epoch arrives at the delay controlled cryptographic circuit 106. In at least one embodiment, before predetermining the AES data for the first epoch, the delay controlled cryptographic circuit 110 may predetermine the AES input data for the first epoch. For example, the delay controlled cryptographic circuit 110 may predetermine the AES input data from a counter output.

[0023] In at least one embodiment, the delay controlled cryptographic circuit 106 can use the AES engine 108 to determine the authentication tag associated with the first epoch in parallel with determining the first output data. The authentication tag is used to verify the correctness of the first output data. In at least one embodiment, the delay controlled cryptographic circuit 110 can use the AES engine 112 to determine the authentication tag associated with the first epoch in parallel with determining the first output data. Additional details of the delay controlled cryptographic circuit 106 and the delay controlled cryptographic circuit 110 are described below with respect to Figures 2 to 6 Give a description.

[0024] Figure 2 is a block diagram of an in-line memory encryption (IME) block 200 for latency controlled IDE according to at least one embodiment. The IME block 200 provides encryption, decryption, and authentication for memory read and write requests between a host processor (via a host-side interface) and its attached memory (via a memory-side interface). The IME block 200 can be instantiated on a host system (e.g., a system on a chip (SoC) or a field programmable gate array (FPGA)) between processor logic and a memory controller. The IME block 200 can be a high throughput, low latency security solution. The IME block 200 can be implemented in hardware, software, firmware, or any combination thereof. The IME block 200 can receive plaintext data 202 via a host-side interface, encrypt the plaintext data 202 into ciphertext data, generate an authentication tag 216, and provide an output 204 to the memory via a memory-side interface. The output 204 includes final ciphertext data 218 and an authentication tag 216. The IME block 200 can receive the ciphertext data and the authentication tag from the memory controller via the memory-side interface, decrypt the data, and provide the decrypted data via the host-side interface. The IME block 200 may implement an encryption and authentication algorithm, such as the AES-GCM algorithm. The AES-GCM algorithm uses AES-256 for encryption and GMAC for authentication. GMAC internally uses a GHASH function to generate an authentication tag 216. In at least one embodiment, the IME block 200 may generate a message authentication code (MAC) tag for each segment (or portion or segments or portions) received from a source node via a host-side interface. Figure 2 As shown, the generation of the MAC tag is performed in conjunction with an authentication algorithm that uses a hash function to calculate the MAC tag. In other embodiments, the generation of the MAC tag is performed in conjunction with another operation such as an encryption operation. In at least one embodiment, the authentication algorithm is the GMAC algorithm and the hash function is the GHASH function. Alternatively, other authentication algorithms and / or hash functions may also be used.

[0025] In at least one embodiment, the IME block 200 includes an encryption engine 206, an authentication engine 208, and additional logic and SRAM 210, the additional logic and SRAM 210 including a delay controller 220. The additional logic and SRAM 210 can be used to perform other operations and store information in conjunction with encryption and authentication operations. For simplicity, the IME block 200 shows a process flow for encryption using the encryption engine 206. The encryption engine 206 (also referred to herein as encryption logic) can receive plaintext data 202 as fragments (or portions) and encrypt these fragments into fragments 214 (or portions) of ciphertext data. The fragments or portions can be epochs or micro-slices of epochs. The authentication engine 208 can perform authentication using GMAC (including GHASH functions) to generate an authentication tag 216. Before outputting the final authentication tag 216, the authentication engine 208 can output intermediate states stored by the additional logic and SRAM 210 in the event of an error. The intermediate states can include intermediate initialization vectors (IVs) and intermediate hash states of hash calculations. The intermediate states can also store counter outputs.

[0026] In at least one embodiment, the encryption engine 206 (encryption logic) receives the segments 212 of the plaintext data 202 of the data burst and outputs the segments 214 of the ciphertext data of the data burst. The authentication engine 208 (authentication logic) receives the segments 214 of the ciphertext data, outputs a final authentication tag 216 associated with the data burst, and outputs the final ciphertext data 218.

[0027] In at least one embodiment, the delay controller 220 can control the encryption engine 206 to predetermine the AES data before the fragment 212 arrives, so that the AES data is ready when the fragment 212 arrives, and no additional buffer or SRAM is used to store the AES data, as described herein. The delay controller 220 can determine or store a fixed delay of the encryption engine 206 to predetermine the AES data. The delay controller 220 can send a delay parameter to the source node that sends the plaintext data 202. The delay parameter can represent a certain number of clock cycles corresponding to the fixed delay of the encryption engine 206. The delay controller 220 can cause the encryption engine 206 to predetermine the AES data within the number of clock cycles, so that when the corresponding plaintext data 202 arrives at the encryption engine 206, the AES data is ready. The delay controller 220 can also control the encryption engine 206 when data is not transmitted or stagnant, as described in more detail below.

[0028] In at least one embodiment, the IME block 200 includes data-integrity (DI) detection logic to detect errors. The error may be caused by a DI error in one or more of the following: cryptographic calculations of the cryptographic engine 206, authentication calculations of the authentication engine 208, SRAM operations of the additional logic and SRAM 210, or I / O operations. The DI detection logic may be part of the cryptographic engine 206 or coupled to the cryptographic engine 206. The DI detection logic may be part of the authentication engine 208 or coupled to the authentication engine 208. The DI detection logic may be part of the additional logic and SRAM 210 or coupled to the additional logic and SRAM 210. In other embodiments, each stage of the IME block 200 may include DI detection logic to detect errors in authentication operations, cryptographic operations, SRAM operations, I / O operations, etc.

[0029] Figure 3300 is a timing diagram of a transmission device 102 and a receiving device 104 for delay controlled IDE according to at least one embodiment. The receiving device 104 may send a delay parameter to the transmission device 102 in a first command 302. The delay parameter represents a certain number of clock cycles corresponding to a fixed delay of an AES engine (e.g., AES engine 108) of the receiving device 104. In at least one embodiment, the receiving device 104 may send the first command 302 including the delay parameter through a management interface. The management interface may use the CXL.io protocol. The delay parameter may let the transmission device 102 know how many delay cycles are needed for IDE mode. The transmission device 102 may then activate 306 the IDE mode. In response, the transmission device 102 may program the IDE delay time 312 using the number of clock cycles in the delay parameter received from the receiving device 104 and send a second command 304 to the receiving device 104, which may initialize 308 the receiving device 104 for AES mode. In at least one embodiment, the transmission device 102 may send the second command 304 to the receiving device 104 through the management interface. The transmission device 102 may start the IDE delay time 312 and send the third command 310 to the receiving device 104, the third command 310 causing the receiving device to start the IDE initialization time 314. The receiving device 104 may use the IDE initialization time 314 to prepare the AES data in advance. The transmission device 102 may send the third command 310 periodically or at the end of the IDE delay time 312. In at least one embodiment, the transmission device 102 may send the second command 304 to the receiving device 104 through the management interface. After the IDE delay time 312, the transmission device 102 may start the normal service 316 and send the protocol sliver 318 to the receiving device 104. Because the IDE initialization time 314 is equal to the IDE delay time 312, the receiving device 104 is ready to receive the sliver data without delay. For example, during the IDE initialization time 314, the receiving device 104 may use the AES engine 108 to predetermine the AES data for the first epoch. After the number of clock cycles of the IDE initialization time 314, the receiving device 104 receives the first flitter of the first epoch from the transmitting device 102 via the data interface. The receiving device 104 is ready to receive the first flitter without delay after the number of clock cycles.

[0030] In at least one embodiment, the receiving device 104 may determine an authentication tag associated with the first epoch using the AES engine 108 in parallel with determining the first output data. The authentication tag may be a partial authentication tag or a final authentication tag. In at least one embodiment, the authentication tag is a MAC.

[0031] In another embodiment, the transmission device 102 may send the second command 304 and the third command(s) 310 before sending the protocol flits 318. In some cases, the transmission device 102 may send the first command with a delay parameter for the AES engine 112.

[0032] In another embodiment, the transmission device 102 may receive a delay parameter in the first command from the receiving device through the management interface. The delay parameter represents a second number of clock cycles corresponding to the fixed delay of the AES engine of the receiving device 104. The transmission device 102 may send a second command to the receiving device 104 through the management interface, the second command being used to cause the receiving device 104 to initialize the AES engine 108 of the receiving device 104. The transmission device 102 may send a third command to the receiving device 104 through the management interface, the third command being used to cause the receiving device 104 to predetermine the AES data for the first epoch using the AES engine 108 of the receiving device 104. After the second number of clock cycles, the transmission device 102 may send the first microchip of the first epoch to the receiving device 104 through the data interface. The AES engine 108 of the receiving device 104 is ready to receive the first microchip without delay after the second number of clock cycles. In yet another embodiment, the second number of clock cycles and the first number of clock cycles overlap at least partially in time.

[0033] Figure 4 is a block diagram of a delay controlled cryptographic circuit 400 having an AES engine 402 and an XOR operation 404, wherein the AES engine 402 has multiple levels of pipelines, according to at least one embodiment. The delay controlled cryptographic circuit 400 may be Figure 1 The delay controlled cryptographic circuit 106, Figure 1 The delay controlled cryptographic circuit 110, Figure 1 The encryption engine 206, Figure 1 or Figure 3 Transmission equipment 102, Figure 1 or Figure 3The receiving device 104 of the present invention and the like. The AES engine 402 receives a predefined AES input 406. The predefined AES input 406 may be a counter output. The AES engine 402 includes a plurality of (such as 7 or 14) levels of pipelines. In at least one embodiment, the number of pipeline levels is equal to the number of clock cycles. In some cases, the number of microchips in a fixed epoch size is less than or greater than the number of clock cycles. The AES engine 402 may output a predefined AES output 408. The predefined AES input 406 should be input into the AES engine 402 a certain number of (such as 7 or 14) clock cycles before the arrival of the input data 410. The predefined AES output 408 determined by the AES engine 402 is used in the XOR operation 404 to determine the output data 412 after the number of clock cycles. The XOR operation 404 may be a bitwise XOR operation. The input data 410 may be plaintext (P) or ciphertext (C), and the output data 412 may be ciphertext (C) or plaintext (P). The delay controlled cryptographic circuit 400 can be used in a receiving device or a transmitting device. For a receiving device, the input data 410 is ciphertext (C), and the output data 412 is plaintext (P). For a transmitting device, the input data 410 is plaintext (P), and the output data 412 is ciphertext (C).

[0034] Figure 5 How to achieve zero latency within 7 clock cycles of a pipeline 500 of an AES engine according to at least one embodiment is shown. In this embodiment, the pipeline 500 has a fixed latency of 7 clock cycles. The AES engine is configured for an epoch size of 5 microchips. Because the epoch size is fixed to 5 and the latency of the AES engine is fixed, the input to the AES engine can be predetermined. This allows the pipeline 500 to predetermine the AES output with 7 latency cycles.

[0035] As shown, the pipeline 500 predetermines first AES input data 504 for the first epoch 502 at a first level of the pipeline 500. For example, the pipeline 500 may receive the AES input data 504 from a counter output. The pipeline 500 processes the first AES input data 504 through subsequent levels of the pipeline 500. After 7 clock cycles, the pipeline 500 produces first AES data 514 for the first epoch 502. At this point (i.e., after a delay of 7 cycles), the pipeline 500 receives a first flitter 516 for the first epoch 502, and the pipeline 500 determines first AES output data 518 for the first epoch 502. In this embodiment, the number of flits is 5, and the number of levels is 7. Therefore, the pipeline 500 may receive 5 flits for the first epoch and 2 flits for the second epoch before determining a first output flitter for the first epoch.

[0036] In the next clock cycle after receiving 504, the pipeline 500 receives the second AES input data 506 at the first stage of the pipeline 500. The pipeline 500 processes the second AES input data 506 through the subsequent stages of the pipeline 500. After 7 clock cycles, the pipeline 500 generates the second AES data 520 for the first epoch 502. At this time (i.e., after a delay of 7 cycles), the pipeline 500 receives the second microchip 524 for the first epoch 502, and the pipeline 500 determines the second AES output data 522 for the first epoch 502. As shown, the AES data (e.g., 514, 520) for the first epoch 502 is predetermined at the same time as the corresponding microchip (e.g., 516, 524) arrives to generate the AES output data (e.g., 518, 522). This is repeated for the third AES input data 508, the fourth AES input data 510, and the fifth AES input data 512.

[0037] After predetermining the AES input data (e.g., 504 to 512), the pipeline 500 predetermines the AES input data for the second epoch 526. After a delay of 7 cycles, the pipeline 500 receives the flits for the second epoch 526 to generate the AES output data based on the flits and the AES input data. Similarly, after predetermining the AES input data for the second epoch 526, the pipeline 500 begins to predetermine the AES input data for the third epoch 528.

[0038] In at least one embodiment, all of the flits in a media access control (MAC) epoch (also referred to as FLITs) may be processed together. This means that one key and one initialization vector (IV) are used for all of the flits in that epoch. Key switching may occur at the boundaries of MAC epochs. Thus, all of the flits of a first epoch will use one key and one IV. The flits of a second epoch will use a different key and IV. The MAC for the flits of a first epoch may be processed using the IV and key from a previous epoch.

[0039] like Figure 5 As shown, pipeline 500 can achieve zero latency because the AES data is predetermined within a fixed latency of 7 cycles. In other embodiments, the pipeline can have a different number of stages, fixed delays, and epoch sizes. In some cases, no data is transmitted and the input and output of the AES engine should be stalled, such as Figure 6 shown.

[0040] Figure 6 shows how to use the Figure 5 The pipeline 500 is stagnant. Figure 6As shown, the pipeline 500 predetermines the first AES input data 504 for the first epoch 502 at the first level of the pipeline 500. For example, the pipeline 500 can receive the AES input data 504 from the counter output. The pipeline 500 processes the first AES input data 504 through the subsequent levels of the pipeline 500. After 7 clock cycles, the pipeline 500 generates the first AES data 514 for the first epoch 502. At this time (i.e., after a delay of 7 cycles), it is determined that no data is transmitted. When no data is transmitted, the input and output of the pipeline 500 are simultaneously stalled. That is, the current input micro-slice is stalled from this point, and the current output micro-slice is stalled from this point. The pre-calculated data (not yet finalized) can stay in the pipeline 500 of the AES engine until it can be used. For example, the pipeline 500 has the AES input data for the first epoch 502, the first AES input data 602, the second AES input data 604, and the third AES input data 606. Because no data is transmitted after the delay, the third AES input data 606 is stalled at the input and the first AES data 514 is stalled at the output. The epoch after the stall does not need to be fully calculated during the stall period, so the partially calculated data can stay in the AES pipeline because it is not needed at the current time. When the data is restored, the pipeline can be restored accordingly. No additional computing power is used, and no additional SRAM is required to store the AES output. This can save power consumption and area. Fixed epoch size allows the AES input to change in advance. In the case where the epoch is terminated before its end, the estimation of the AES input may be interrupted. However, a delay can be inserted after the early MAC termination, so this period can be used to predetermine the AES data required for the next epoch.

[0041] Figure 7is a block diagram of a memory system 700 having a memory module 708, wherein the memory module 708 includes an IME block 706 with latency control, according to at least one embodiment. In one embodiment, the memory module 708 includes a memory buffer device 702 and one or more DRAM devices 716. In one embodiment, the memory buffer device 702 is coupled to the one or more DRAM devices 716 and a host 710. In another embodiment, the memory buffer device 702 is coupled to a switch fabric manager, which is operably coupled to one or more hosts. In another embodiment, the memory buffer device 702 is coupled to the host 710 and the switch fabric manager. The switch fabric manager is software executed by a device (such as a network device or switch) that manages connections between multiple entities in a network switch fabric. A network switch fabric is a network topology in which components pass data to each other through interconnected switches. The network switch fabric includes hubs, switches, adapter endpoints, etc. between devices.

[0042] In one embodiment, the memory buffer device 702 includes an IME block 706 with delay control. The IME block 706 with delay control is similar to Figure 2 IME block 200. In at least one embodiment, IME block 706 with latency control can send or receive decrypted data 726 (or encrypted data with MAC) from host 710. In another embodiment, IME block 706 with latency control can receive encrypted data 720 from DRAM device(s) 716. In some cases, decrypted data or encrypted data is stored in DRAM device(s) 716 and retrieved by memory buffer device 702 to be encrypted into encrypted (or re-encrypted) data by IME block 706 with latency control before being stored back in DRAM device(s) 716 or transmitted to host 710.

[0043] In at least one embodiment, the IME with latency control block 706 may generate a MAC 722 for each cache line to provide cryptographic integrity when accessing a corresponding cache line or set of cache lines of encrypted data 720 .

[0044] In at least one embodiment, the IME block with delay control 706 can verify one or more MACs associated with the encrypted data stored in the (multiple) DRAM devices 716. The one or more MACs are previously generated. The IME block with delay control 706 can decrypt the encrypted data to obtain decrypted data.

[0045] In one embodiment, the memory buffer device 702 includes an ECC block 704 (e.g., an ECC circuit) to detect and correct errors in cache lines or cache line sets read from the DRAM device(s) 716. In at least one embodiment, the ECC block 704 can generate and verify ECC information stored with each cache line or cache line set. The ECC block 704 can use the ECC information to detect and correct errors in cache lines of data.

[0046] The memory buffer device may include a A controller, one or more hosts, and a memory controller coupled to the ECC block and the DRAM devices.

[0047] In yet another embodiment, the memory buffer device 702 includes controller 712 and memory controller 714 . The controller 712 is coupled to the host 710 and the IME block 706 with latency control. The memory controller 714 is coupled to one or more DRAM devices 716. In yet another embodiment, the memory buffer device 702 includes a management processor and a trusted root ( Figure 7 In at least one embodiment, the management processor may receive one or more management commands via a command interface between the host 710 (or the switch fabric manager) and the management processor. In at least one embodiment, the memory buffer device 702 may be configured to use a memory expansion device (such as NVM module or Module The memory buffer device 702 may be implemented by a memory expander SoC). The memory buffer device 702 may encrypt unencrypted data (e.g., plaintext or plaintext user data) received from the host 710 using an IME block 706 with latency control to obtain encrypted data 720 before storing the encrypted data 720 in the DRAM device(s) 716.

[0048] In some cases, the IME block with delay control 706 can receive encrypted data for transmission across the link. The IME block with delay control 706 can generate a MAC 722 associated with the encrypted data 720. In at least one embodiment, the IME block with delay control 706 is an IME engine. In another embodiment, the IME block with delay control 706 is an encryption circuit or logic. The ECC block 704 can receive the encrypted data 720 from the IME block with delay control 706. The ECC block 704 can generate ECC information associated with the encrypted data 720. The encrypted data 720, the MAC 722, and the ECC information can be organized as cache line data 724. The memory controller 714 can receive the cache line data 724 from the ECC block 704 and store the cache line data 724 in (multiple) DRAM devices 716.

[0049] It should be noted that when unencrypted data and encrypted data traverse a link (e.g. Link), the memory buffer device 702 can receive it. This encryption is usually link encryption (in In this case, the link encryption will not continue to the DRAM because the MAC 722 in the memory module 708 is generated before the IME block 706 with latency control described herein encrypts the link data and generates the MAC 722. Controller 712 can decrypt the link data and verify its integrity. Although "unencrypted data" is used herein, in other embodiments, the data can be encrypted data encrypted by memory buffer device 702 using a key used only for the link, so the plain text data exists in The IME block 706 with latency control does not encrypt the data, but still generates the MAC 722.

[0050] In at least one embodiment, The controller 712 includes a host memory interface (eg, CXL.mem) and a management interface (eg, CLX.io). The host memory interface can receive remote memory protocols (such as CXL.mem) from the host 710. The management interface may receive one or more management commands of the remote memory protocol from the host 710 or the switch fabric manager by way of a management processor.

[0051] In at least one embodiment, the IME block 706 with delay control receives a data stream from the host 710 and encrypts the data stream into encrypted data 720, and provides the encrypted data 720 to the ECC block 704 and the memory controller 714. The memory controller 714 stores the encrypted data along with the MAC 722 and the ECC information as cache line data 724 in the (multiple) DRAM devices 716. The cache line data 724 can be accessed as a separate cache line. In some cases, the memory buffer device 702 can determine that the encrypted data stored in the (multiple) DRAM devices 716 should be compressed. For example, this can be done to save space in the (multiple) DRAM devices 716. The memory buffer device 702 can retrieve the encrypted data. The IME block 706 with delay control can verify one or more MACs associated with the retrieved encrypted data. The IME block 706 with delay control can decrypt the encrypted data to obtain uncompressed data. The IME block 706 with delay control can encrypt the decrypted data 726 to obtain the encrypted data 720. The IME block 706 with latency control may generate a MAC 722 for the compressed data. The ECC block 704 may generate ECC information. The encrypted data 720, the MAC 722, and the ECC information may be organized as cache line data 724. The memory controller 714 may receive the cache line data 724 from the ECC block 704 and store the cache line data 724 in the DRAM device(s) 716. The cache line data 724 may be accessed as a collection of multiple cache lines.

[0052] In some embodiments, the memory module 708 has a persistent memory backup capability, wherein in the event of a power outage or brownout event, the management processor can access the encrypted data 720 and transfer the encrypted data from the DRAM device(s) 716 to the persistent memory ( Figure 7 720 in the persistent memory is considered static data. In at least one embodiment, the management processor uses an NVM controller (eg, a NAND controller) to transfer the encrypted data to the persistent memory.

[0053] The IME block 706 with delay control may include multiple encryption functions, such as a first encryption function using 128-bit AES encryption and a second encryption function using 256-bit AES encryption. In other embodiments, the encryption function may also provide cryptographic integrity (such as using a MAC). In other embodiments, cryptographic integrity may be provided separately from encryption. In some cases, the strength of the MAC and encryption algorithms may be different. The first encryption function may have a first encryption strength, such as AES-256 encryption. In at least one embodiment, the IME block 706 with delay control is an IME engine with two encryption functions. In another embodiment, the IME block 706 with delay control includes 2 separate IME engines, each IME engine having one of the two encryption functions. In another embodiment, the IME block 706 with delay control includes a first encryption circuit for the first encryption function and a second encryption circuit for the second encryption function. Alternatively, additional encryption functions may also be implemented with the IME block 706 with delay control. The memory controller 714 may receive the encrypted data 720 from the IME block with latency control 706 and store the encrypted data 720 from the IME block with latency control 706 in the DRAM device(s) 716 .

[0054] In at least one embodiment, a MAC may be calculated on the first encrypted data stored with the second encrypted data as part of an algorithm (e.g., AES) or separately from a different algorithm. The memory controller 714 may receive the encrypted data 720 and the MAC 722 from the IME block 706 with latency control and store the encrypted data 720 and the MAC 722 in the DRAM device(s) 716. For all host transactions, the host to unencrypted memory path may bypass the IME block 706 with latency control. The host to unencrypted memory path may still pass through the IME block 706 with latency control for generating the MAC 722.

[0055] Figure 8 802 includes a memory controller 812, an encryption circuit 806 with latency control, and a management processor 808. In at least one embodiment, the integrated circuit 802 is a block diagram of an integrated circuit 802 that can use a cache coherent interconnect protocol (e.g., a computing high-speed link). protocol) with one or more host systems ( Figure 8 Integrated circuit 802 may be implemented Standard equipment. The protocol can be built on high speed Standard physical and electronic interfaces, including high-speed The standard protocol establishes consistency, simplifies the software stack, and maintains compatibility with existing standards. The integrated circuit 802 includes a first interface 804 coupled to one or more host systems or switch fabric managers, coupled to one or more volatile memory devices ( Figure 8 ) and may include a second interface 810 coupled to one or more non-volatile memory devices ( Figure 8 The integrated circuit 802 may include a third interface 814 (not shown). The one or more volatile memory devices may be DRAM devices. The integrated circuit 802 may be part of a single-host memory expansion integrated circuit, a multi-host memory pooling integrated circuit coupled to multiple host systems via multiple cache coherent interconnects, and the like.

[0056] In one embodiment, the memory controller 812 receives data from the host through the first interface 804, or receives data from the volatile memory device through the second interface 810. The memory controller 812 can send data or a copy of the data to the encryption circuit with delay control 806. The encryption circuit with delay control 806 can be similar to Figure 1 The delay controlled cryptographic circuit 106 or the delay controlled cryptographic circuit 110 of FIG. The encryption circuit 806 with delay control may be similar to Figure 2 IME block 200, Figure 4 The delay controlled cryptographic circuit 400, Figure 5 Pipeline 500, Figure 7 The IME block 706 with delay control and the like can be operated. The fixed delay of the encryption circuit 806 with delay control can be stored in the register data. The encryption circuit 806 with delay control can include an encryption circuit, an encryption logic, a decryption circuit, a decryption logic, an IME block, an IME engine, an IME logic, or an encryption block for encrypting data. The encryption circuit 806 with delay control can include a MAC circuit for generating, verifying, and storing a MAC, as described herein. In at least one embodiment, the encryption circuit 806 with delay control includes an ECC block or circuit that can generate ECC information, as described herein.

[0057] In another embodiment, one or more non-volatile memory devices are coupled to a second memory controller of the integrated circuit 802. In another embodiment, the integrated circuit 802 is implemented The integrated circuit 802 is a standard processor and includes an encryption circuit 806 with delay control and a memory controller 812. In another embodiment, the integrated circuit 802 may include more or less than three interfaces.

[0058] Fig. 9is a flow chart of a method 900 for delaying controlled IDE according to at least one embodiment. The method 900 may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions running on a processing device to perform hardware simulation), or a combination thereof. In one embodiment, the method 900 is performed by Figure 1 In at least one embodiment, Figure 2 The IME block 200 performs the method 900. In another embodiment, Figure 4 The delay controlled cryptographic circuit 400 performs the method 900. In another embodiment, Figure 5 The pipeline 500 performs the method 900. In another embodiment, Figure 7 The IME block 706 with delay control performs the method. In another embodiment, Figure 7 In another embodiment, the method 900 is performed by a memory buffer device 702. In another embodiment, the method 900 is performed by a memory expansion device. Figure 7 In another embodiment, the method 900 is performed by the memory module 708 of Figure 8 The method 900 may be performed by an integrated circuit 802 including an encryption circuit 806 with delay control. Alternatively, other devices may also perform the method 900.

[0059] refer to Fig. 9 , method 900 begins with processing logic sending a delay parameter to a transmission device (block 902). The delay parameter may represent a certain number of clock cycles corresponding to a fixed delay of an AES engine, the AES engine having a fixed epoch size for IDE. At block 904, before first input data of the first epoch is received from the transmission device, processing logic uses the AES engine to predetermine AES data for the first epoch. At block 906, after the number of clock cycles, processing logic receives the first input data from the transmission device. At block 908, processing logic uses the AES data and the first input data to determine first output data for the first epoch without storing the AES data in a buffer.

[0060] In yet another embodiment, processing logic determines the authentication tag associated with the first epoch using the AES engine in parallel with determining the first output data.Processing logic may predetermine the AES input data from the counter output prior to predetermining the AES data.

[0061] In yet another embodiment, the processing logic sends a delay parameter in a first command to the transmission device via the management interface. The processing logic may receive a second command from the transmission device via the management interface. The processing logic initializes the AES engine in response to the second command. The processing logic may receive a third command from the transmission device via the management interface. The AES data may be predetermined in response to the third command. After the number of clock cycles, the processing logic receives a first microchip of a first epoch from the transmission device via the data interface. The processing logic is ready to receive the first microchip without delay after the number of clock cycles.

[0062] It should be understood that the above description is intended to be illustrative, not restrictive. Upon reading and understanding the above description, many other embodiments will be apparent to those skilled in the art. Therefore, the scope of the present disclosure should be determined with reference to the full scope of the appended claims and the equivalents of these claims.

[0063] In the above description, many details are set forth. However, it will be apparent to those skilled in the art that various aspects of the present disclosure may be practiced without these specific details. In some cases, known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the present disclosure.

[0064] Some portions of the above detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the art of data processing to most effectively convey the substance of their work to others skilled in the art. An algorithm is generally conceived here as a self-consistent sequence of steps leading to a desired result. These steps require physical manipulation of physical quantities. Typically, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Mainly for common reasons, it has proven convenient at times to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc.

[0065] It should be remembered, however, that all of these terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise specifically stated, it will be apparent from the following discussion that throughout the description, discussions utilizing terms such as "receiving," "determining," "selecting," "storing," "setting," etc., will be understood to refer to actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage devices, transmission devices, or display devices.

[0066] The present disclosure also relates to a device for performing the operations herein. The device may be specially constructed for the desired purpose, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as but not limited to any type of disk (including floppy disk, optical disk, CD-ROM, magneto-optical disk), read-only memory (ROM), random access memory (RAM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), magnetic card or optical card, or any type of medium suitable for storing electronic instructions, each medium coupled to a computer system bus.

[0067] The algorithms and displays presented herein do not inherently relate to any particular computer or other device. Various general purpose systems can be used together with programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the required method steps. The structures required for various these systems will be listed as set forth in the description. In addition, no reference is made to any particular programming language to describe the various aspects of the present disclosure. It will be appreciated that the teachings of the present disclosure described herein may be implemented using various programming languages.

[0068] Aspects of the present disclosure may be provided as a computer program product or software that may include a machine-readable medium having instructions stored thereon, wherein the instructions may be used to program a computer system (or other electronic device) to perform processing according to the present disclosure. A machine-readable medium includes any process for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium (e.g., a read-only memory ("ROM"), a random access memory ("RAM"), a disk storage medium, an optical storage medium, a flash memory device, etc.).

Claims

1. A receiving device, comprising: A cryptographic circuit comprising an Advanced Encryption Standard (AES) engine having a fixed epoch size and a fixed delay for integrity and data encryption (IDE), wherein the cryptographic circuit is to: Sending a delay parameter to a transmission device, the delay parameter representing a certain number of clock cycles corresponding to the fixed delay; using the AES engine to predetermine AES data for a first epoch before first input data of the first epoch is received from the transmission device; receiving the first input data from the transmission device after the number of clock cycles; as well as First output data for the first epoch is determined using the AES data and the first input data without storing the AES data in a buffer.

2. The receiving device according to claim 1, wherein the cryptographic circuit is further configured to: predetermine the AES input data for the first epoch before the AES data for the first epoch is predetermined.

3. The receiving device according to claim 2, wherein the cryptographic circuit is configured to predetermine the AES input data from a counter output. The receiving device according to claim 1 , wherein the first input data is plain text, and the first output data is cipher text. 5 . The receiving device according to claim 1 , wherein the first input data is ciphertext, and the first output data is plaintext. 6 . The receiving device of claim 1 , wherein the AES engine comprises a pipeline of a certain number of stages, wherein the number of stages corresponds to the number of clock cycles.

7. A receiving device according to claim 6, wherein the number of micro-chips of the first epoch is 5 and the number of levels is 7, wherein the AES engine is used to: receive 5 micro-chips of the first epoch and 2 micro-chips of the second epoch before determining the first output micro-chip for the first epoch.

8. The receiving device according to claim 6, wherein: In response to no data being transmitted between the transmitting device and the receiving device, the input and output of the pipeline are simultaneously stalled.

9. The receiving device of claim 1, wherein the cryptographic circuit is to: use the AES engine to determine an authentication tag associated with the first epoch in parallel with determining the first output data.

10. The receiving device according to claim 1, wherein the cryptographic circuit is used to: sending the delay parameter to the transmission device in a first command via a management interface; receiving a second command from the transmission device through the management interface, wherein the second command is used to enable the cryptographic circuit to initialize the AES engine; receiving a third command from the transmission device through the management interface, the third command being used to: cause the cryptographic circuit to use the AES engine to predetermine the AES data for the first epoch; as well as After the number of clock cycles, a first flitter of the first epoch is received from the transmission device via a data interface, wherein the cryptographic circuit is ready to receive the first flitter without delay after the number of clock cycles.

11. The receiving device according to claim 1, further comprising: a CXL controller coupled to the cryptographic circuit and one or more hosts; as well as A memory controller is coupled to a dynamic random access memory (DRAM) device, wherein the cryptographic circuit includes an error correction code (ECC) block and an in-line memory encryption (IME) block having the AES engine.

12. A transmission device, comprising: A cryptographic circuit comprising an Advanced Encryption Standard (AES) engine having a fixed epoch size and a fixed delay for integrity and data encryption (IDE), the fixed delay corresponding to a first number of clock cycles, wherein the cryptographic circuit is to: using the AES engine to predetermine AES data for a first epoch before first input data of the first epoch is input into the AES engine; after the first number of clock cycles, determining first output data for the first epoch using the AES data and the first input data without storing the AES data in a buffer; as well as The first output data is sent to a receiving device. 13 . The transmission device according to claim 12 , wherein the first input data is plain text, and the first output data is cipher text.

14. The transmission device of claim 12, wherein the AES engine comprises a pipeline of a certain number of stages, wherein the number of stages corresponds to the first number of clock cycles.

15. The transmission device of claim 12, wherein the cryptographic circuit is configured to: use the AES engine to determine an authentication tag associated with the first epoch in parallel with determining the first output data.

16. The transmission device according to claim 12, wherein the cryptographic circuit is used to: receiving, from the receiving device via a management interface, a delay parameter in a first command, the delay parameter representing a second number of clock cycles corresponding to a fixed delay of an AES engine of the receiving device; Sending a second command to the receiving device through the management interface, wherein the second command is used to enable the receiving device to initialize the AES engine of the receiving device; Sending a third command to the receiving device through the management interface, the third command being used to: cause the receiving device to use the AES engine of the receiving device to predetermine the AES data for the first epoch; as well as After the second number of clock cycles, the first flitter of the first epoch is sent to the receiving device via a data interface, wherein the AES engine of the receiving device is ready to receive the first flitter without delay after the second number of clock cycles. 17 . The transmission device of claim 16 , wherein the second number of clock cycles and the first number of clock cycles at least partially overlap in time.

18. A method of operating a receiving device, the method comprising: sending a delay parameter to a transmitting device, the delay parameter representing a certain number of clock cycles corresponding to a fixed delay of an Advanced Encryption Standard (AES) engine having a fixed epoch size for integrity and data encryption (IDE); Before receiving first input data of a first epoch from the transmission device, using the AES engine to predetermine AES data for the first epoch; receiving the first input data from the transmission device after the number of clock cycles; as well as First output data for the first epoch is determined using the AES data and the first input data without storing the AES data in a buffer.

19. The method according to claim 18, further comprising: An authentication tag associated with the first epoch is determined using the AES engine in parallel with determining the first output data.

20. The method of claim 18, further comprising: sending the delay parameter to the transmission device in a first command via a management interface; receiving a second command from the transmission device through the management interface; initializing the AES engine in response to the second command; receiving a third command from the transmission device via the management interface, wherein the predetermination of the AES data is performed in response to the third command; as well as After the number of clock cycles, a first flit of the first epoch is received from the transmitting device via a data interface, wherein the receiving device is ready to receive the first flit without delay after the number of clock cycles.

Images