Multi-part transaction integrity protection and encryption

Abstract

Multi-part transaction integrity protection and encryption are disclosed, including generating, by a first device, a first message authentication code (MAC) for authenticating a plurality of packets of a transaction, the plurality of packets including at least a first packet received over a data link from a second device and a second packet generated by the first device in response to receiving the first packet, the first MAC is generated using data included in the plurality of packets; and transmitting, by the first device, the second packet and the first MAC over the data link to the second device.

Description

TECHNICAL FIELD

[0001] The field of the present disclosure is integrity and data encryption, or more specifically, methods, apparatuses, and products for multi-part transaction integrity protection and encryption.

[0002] Description of the Related Art

[0003] The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since then, computer systems have evolved into extremely sophisticated devices. Today's computers are much more complex than early systems such as the EDVAC. Computer systems typically include a combination of hardware and software components, application programs, operating systems, processors, microcode, buses, memory, input / output devices, etc. As advances in semiconductor processing and computer architecture push the performance of the computer higher and higher, more sophisticated computer software has evolved to take advantage of the higher performance hardware, resulting in today's computers that are much more powerful than just a few years ago.

[0004] There are many methods for integrity and data encryption (IDE) of data transmitted from one party to another. These methods are typically deployed in buses, networks, and other types of links. A transaction is a series of requests and responses between two parties over a bus, network, or other type of link. Conventional encryption and authentication techniques require significant overhead when a transaction is split into multiple parts or phases, and are typically not suitable for out-of-order transactions.

[0005] Conventional IDE methods typically consist of a packet of data sent from a source to a destination. As an example, the following description will employ the AES-GCM encryption algorithm, AES-GCM being the Advanced Encryption Standard (AES) in Galois / Counter Mode. AES specifies a cipher algorithm that can be used to protect electronic data. The AES algorithm is a symmetric block cipher algorithm that can encrypt (encrypt or encipher) and decrypt (decrypt or decipher) information using a shared initialization vector (IV), i.e., a random number, and an encryption key. Encryption converts plaintext data into an unintelligible form called ciphertext; and decryption of the ciphertext converts the data back into its original form, which is called plaintext. AES-GCM provides authenticated encryption (confidentiality and authentication) and the ability to check integrity and authentication using a message authentication code (MAC) that is computed using plaintext data and authentication data.

[0006] For transmission, the data packet can first be separated into plaintext and authentication data. The data packet can then be encrypted using AES-GCM encryption. The resulting ciphertext and authentication data are then sent to the destination along with the MAC. The receiver (destination) decrypts using the same encryption method, where the received ciphertext is used as the plaintext input. The resulting ciphertext is the decrypted data. Finally, the receiver's calculated MAC is compared to the MAC received from the source to verify the integrity of the received data. A device monitoring the link can see the authentication data, but cannot alter the authentication data without the MAC check detecting the change. The plaintext block is both encrypted and integrity protected, so a device monitoring the link cannot either clearly see the information or alter the information without the change being detected.

[0007] For a request and response between two parties, the conventional approach requires the requesting party to encrypt the data, calculate a MAC, and transmit the ciphertext to the destination. The responding party receiving the request decrypts the data, calculates a MAC, and compares the MAC to the MAC received from the requesting party to verify the integrity of the received data. The responding party then generates a response, encrypts the data, calculates a MAC, and transmits the ciphertext to the requesting party. The requesting party receiving the response decrypts the data, calculates a MAC, and compares the MAC to the MAC received from the responding party to verify the integrity of the received data. In many cases, the conventional approach is sufficient to protect the confidentiality (encryption) and integrity (MAC check) of the transaction. However, it is apparent that the transmission of the MAC with each message contributes to significant communication volume on the data link.

[0008] When performing transactions across a bus such as a compute express link (CXL), the transaction is separated into multiple phases. For example, in CXL, the CXL.cache protocol allows devices to coherently access and cache host CPU memory using a low-latency request / response interface. CXL defines a host-to-device (H2D) lane for messages from the host to the target device and a device-to-host (D2H) lane for messages from the device to the host. A transaction in this protocol can include multiple phases of a D2H request message, an H2D response message, a D2H datagram header, and D2H data. Further, in CXL, the CXL.mem protocol allows a host CPU to coherently access device memory with load / store commands for both volatile and persistent non-volatile storage. CXL.mem defines a master-to-slave (M2S) lane for messages from the host to the target device and a slave-to-master (S2M) lane for messages from the device to the host. A transaction in this protocol can include multiple phases of an M2S request message, an M2S request with data message, an S2M response message, an S2M datagram header, and S2M data.

[0009] To help illustrate, consider an example of a CXL.mem read transaction where a host (master) transmits a read request in the form of an M2S request packet. The target (subordinate) receives the request and responds with an S2M response followed by the requested data. Typically, a MAC needs to be transmitted with the M2S request and a second MAC tag will be transmitted with the S2M response and data packet. Since the amount of data sent for the M2S request is very small (~100 bits), the transmission of the MAC tag (96 bits) is almost 100% overhead. In another example, a CXL.cache write transaction includes a D2H request followed by an H2D response followed by a D2H data header and D2H data followed by an H2D response. Typically, this requires a MAC sent for the D2H request, a second MAC sent for the first H2D response, a third MAC sent with the D2H data header and D2H data phase, and a fourth MAC with the final H2D response. It is clear that applying the traditional method of sending a MAC in only a single direction to ensure data integrity to a multi-part transaction protocol such as CXL incurs significant overhead.

[0010] Further, both parties encrypting and decrypting the data must know the IV. The IV can be sent with each message, but to reduce bandwidth consumption, the IV can be shared once between the parties and incremented by message. Thus, to be able to use the MAC for integrity checking, either a unique IV needs to be transmitted with each request or the requests and responses need to be put back in order by the receiving party. In the case of CXL and other bus protocols, the requests and responses can be reordered. Thus, to be able to use the MAC for integrity checking, a unique IV needs to be transmitted with each request. In the case of multi-part transaction protocols that support reordering, transmitting the IV with each phase significantly increases the overhead.

[0011] Further, in the case of a direct application of AES-GCM or other counter mode algorithm, prevention of replay attacks requires that the receiver of the MAC keep track of which IVs have already been used and fail the transaction if a received IV has been used previously. This requires significant tracking logic within the receiving party. SUMMARY

[0012] Methods, apparatuses, and products for multi-part transaction integrity protection and encryption according to various embodiments are disclosed. As used herein, a transaction refers to a series of messages beginning with a request message that includes some command (e.g., read, write). Each message sent from one party to another party is referred to as a phase of the transaction. Due to reordering by intermediate devices (e.g., switches) on the link, transactions (including the phases within a transaction) can be received out of order. According to embodiments, the creation of a message authentication code (MAC) tag is amortized over multiple phases of a transaction to conserve bandwidth of the link, regardless of which party transmits a particular phase. In other words, the MAC tag is generated based on data included in one or more previous transaction messages as well as data in the current transaction message to which the MAC tag is attached. The link endpoints (requesting party or responding party) maintain state that includes data from messages sent and received in a transaction, and the link endpoints use this data to generate MAC tags to send to the other party and to check MAC tags received from the other party.

[0013] Embodiments relate to a method for multi-part transaction integrity protection and encryption. The method includes generating, by a first device, a first message authentication code (MAC) for authenticating a plurality of packets of a transaction. The plurality of packets includes at least a first packet received from a second device over a data link and a second packet generated by the first device in response to receiving the first packet. The first MAC is generated using data included in the plurality of packets. The first device can be a requesting party or a responding party of the transaction. The first device can be a host processor and the second device is a coupled device, or the first device can be a device and the second device is a host processor. The data link can be a bus such as a Compute Express Link (CXL) protocol bus. The plurality of packets can include a request packet, a response packet, a data header, and data corresponding to the multi-part transaction. The method further includes sending, by the first device, the second packet and the first MAC to the second device over the data link. Thus, both parties contribute to the data used as input for the generation of the MAC, allowing all previous packets of the transaction to be authenticated using one MAC.

[0014] In some variations, the method further includes receiving, by the first device from the second device, one or more additional packets of the transaction and a second MAC for authenticating the plurality of packets of the transaction including the one or more additional packets. The method further includes decrypting, by the first device, the one or more additional packets. The method further includes generating, by the first device, a third MAC for authenticating the plurality of packets of the transaction including the one or more additional packets using data included in the plurality of packets. The method further includes authenticating, by the first device, the plurality of packets including the one or more additional packets based on a comparison of the second MAC and the third MAC.

[0015] In some variations, the method further includes generating, by the first device, an IV based on a combination of a pre-shared initialization vector (IV) basis (IVbasis) and a tag included in the first packet. The IV is used for encryption and decryption of the data. Thus, by generating an IV uniquely associated with a transaction based on tag information of a message in a packet that has already been used to identify the transaction, the potential reordering problem of packets across transactions can be addressed. This eliminates the need to send the entire IV with each packet in the face of potential reordering, saving data link bandwidth.

[0016] The above and other objects, features and advantages of the present disclosure will be more apparent from the following more particular description thereof, presented in conjunction with the following drawings, wherein like numerals and characters represent like parts throughout the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 is a flow diagram of an example AES-GCM encryption algorithm suitable for multipart transaction integrity protection and encryption according to embodiments of the present disclosure, AES-GCM being Advanced Encryption Standard (AES) in Galois / Counter Mode.

[0018] Figure 2 is a block diagram of an example computing system configured for multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0019] Figure 3 is a diagram of an example transaction for multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0020] Figure 4 is a diagram of an example of MAC generation in multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0021] Figure 5 is a diagram of an example initialization vector construction for multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0022] Figure 6 is a diagram of another example transaction for multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0023] Figure 7 is a detailed flow of an example transaction for multipart transaction integrity protection and encryption according to embodiments of the present disclosure.

[0024] Figure 8 is a flow diagram of an example method for multipart transaction integrity protection and encryption according to some embodiments of the present disclosure.

[0025] Figure 9is a flowchart of another example method for multipart transaction integrity protection and encryption according to some embodiments of the present disclosure.

[0026] Figure 10 is a flowchart of another example method for multipart transaction integrity protection and encryption according to some embodiments of the present disclosure.

[0027] Figure 11 is a flowchart of another example method for multipart transaction integrity protection and encryption according to some embodiments of the present disclosure.

[0028] Figure 12 is a flowchart of another example method for multipart transaction integrity protection and encryption according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0029] From Figure 1 Start, reference is made to the accompanying drawings that describe example apparatus and systems for multipart transaction integrity protection and encryption according to the present disclosure. Figure 1 A flowchart of an example AES-GCM algorithm 100 for generating a message authentication code (MAC) according to some embodiments of the present disclosure is set forth. AES-GCM provides authenticated encryption (confidentiality and authentication) and is able to check the integrity and authentication of additional authentication data that is transmitted in plaintext (i.e., unencrypted). AES-GCM encryption has four inputs: a key (e.g., an AES key), an initialization vector (IV) (also referred to as a "nonce"), plaintext (e.g., padded to 128 bits 128 bits), and authentication data (e.g., padded to 128 bits). The authentication data is passed in plaintext, i.e., it is output from the AES-GCM encryption in the same format and length as input to the AES-GCM encryption. Other outputs of the AES-GCM encryption include ciphertext of the same length as the plaintext, and a message authentication code (MAC) (e.g., 106 bits) that can be used to authenticate the message. Figure 1 An example AES-GCM algorithm 100 is shown in FIG. 1, where it is assumed that AES 256, where a 256-bit encryption key (E k ) is used and the IV is a 128-bit nonce (a number used only once). The plaintext block is the data to be encrypted, and the ciphertext block is the encrypted data. The Multiply by H block is a Galois multiplication, where H is the value obtained by encrypting "0" using E k The authentication data block is unencrypted data, but is part of the data that is sent. According to the present disclosure, as will be explained below, both parties can use a derived counter (i.e., IV). It will be appreciated that the Galois multiplication can be performed without requiring all of the authentication data at the beginning of the transaction.

[0030] Figure 2A block diagram of an automated computer comprising an exemplary computing system 200 configured for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 2 The computing system 200 includes at least one computer processor 210, or "CPU," and a random access memory ("RAM") 220 that is connected through a high speed memory bus 213 and bus adapter 212 to the processor 210 and to other components of the computing system 200.

[0031] Stored in RAM 220 is an operating system 222. Operating systems useful in computers configured for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure include z / OS TM , UNIX TM , Linux TM , Microsoft Windows TM , AIX TM and others as will occur to those of skill in the art. Examples of operating systems 222 are shown in RAM 220, but many components of such software typically are stored in non-volatile memory also, e.g., stored in data storage 232 such as a disk drive. Figure 2

[0032] Figure 2 The computing system 200 includes a disk drive adapter 230 that connects the nonvolatile data storage to the computing system 200 through a bus 217 and bus adapter 212. The disk drive adapter 230 connects to a data storage device 232 in the form of a disk drive to the computing system 200. Disk drive adapters useful in computers configured for inserting serial numbers into editable spreadsheets according to embodiments of the present disclosure include integrated drive electronics ("IDE") adapters, small computer system interface ("SCSI") adapters, and others as will occur to those of skill in the art. Nonvolatile computer memory also can be implemented as a floppy disk drive, a compact disk drive, an electrically-erasable programmable read-only memory (so-called "EEPROM" or "Flash" memory), a RAM drive, and others as will occur to those of skill in the art.

[0033] Figure 2 The example computing system 200 includes one or more input / output ("I / O") adapters 216. I / O adapters enable user- oriented input / output of computing system 200, such as monitor 214, keyboard 218 and mouse 220. Figure 2 ​The example computing system 200 includes a video adapter 234, which is an example of an I / O adapter specially designed for graphic output to a display device 236 such as a display screen or computer monitor. Video adapter 234 connects to processor 210 through high-speed video bus 215, bus adapter 212, and front-side bus 211, which is also a high-speed bus.

[0034] Figure 2 The example computing system 200 includes a communication adapter 214 for data communications with other computers and for data communications with a data communications network. This communications can be carried out serially through RS-232 connections, through external buses such as a General Purpose Figure 2 The communication adapter 214 of the example computing system 200 is communicatively coupled to a wide area network 240, which also includes other computing devices such as Figure 3 computing devices 241 and 242 as shown. According to embodiments of the present disclosure, multi-part transaction integrity protection and encryption can be applied on links such as memory bus 213, video bus 215, expansion bus 217, and wide area network 240, where any component connected to such a link can perform the techniques for multi-part transaction integrity protection and encryption described below.

[0035] To further explain, Figure 3 A diagram illustrating an example transaction 300 for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 4Examples include a CX1.mem master-to-slave (M2S) read transaction. Here, the host 302 (e.g., a host CPU) is the requestor and the device 304 is the responder. In the first part of the transaction (or "first phase" as used herein), the host 302 generates a plaintext request and encrypts the plaintext into ciphertext. The host 302 then transmits an M2S request packet 306 including the ciphertext and authentication data to the device. Unlike conventional approaches, the host 302 does not transmit a MAC for the M2S request packet 306. The host 302 saves state that includes information such as the authentication data transmitted in the M2S request packet 306, or other information useful for performing MAC generation and further decryption of phases of the transaction received from the device. In some cases, the saved state need not include all of the information sent and / or received if the information can be represented as a partial state of the MAC generation or a previous MAC itself.

[0036] The device 304 generates a plaintext response to the request and encrypts the plaintext for an S2M response packet 308. The S2M response packet 308 includes ciphertext and authentication data generated by the device 304. When the request is for data, the device 304 also prepares a plaintext for a data packet 310 containing the requested data and encrypts the plaintext. Thus, the S2M response packet 308 can be a data header or data response packet. For the authentication data, the device 304 uses the authentication data from the M2S request packet 306 and the authentication data from the S2M response packet 308 and data packet 310 as combined authentication data for MAC generation. The device 304 uses the combined authentication data and plaintext from the M2S request packet, the S2M response packet, and the data block packet to generate a MAC 312 for the M2S request packet 306, the S2M response packet 308, and the data packet 310 as described below Figure 1 shown. The MAC generation can use the AES-GCM algorithm shown in Figure 1 described below. The device 304 transmits the S2M response packet 308 (e.g., as phase 2 of the transaction), the data packet 310 (e.g., as phase 3 of the transaction), and the MAC 312 (e.g., as phase 4 of the transaction), where the MAC 312 provides integrity checking for the M2S request packet 306, the S2M response packet 308, and the data packet 310.

[0037] When the host 302 receives the S2M response packet 308 and the data packet 310, the host 302 uses the ciphertext as Figure 3The algorithm uses plaintext in the S2M response packet 308 and the ciphertext in packet 310 to decrypt the ciphertext. Host 302 also generates a MAC using the same input allegedly used to generate the received MAC. An integrity check is performed by comparing this MAC with the MAC 312 received from device 304. If the MACs match, the integrity of the entire transaction (e.g., phases 1, 2, 3, and 4) is valid. If the MACs do not match, a portion of the received transaction has been modified from the originally sent transaction. Although Figure 4 Only the requesting party receiving the MAC to verify the transaction is shown; however, those skilled in the art will understand that other mitigation measures, such as the MAC transmitted to the responding party, may be necessary to mitigate all security threats.

[0038] To further explain, Figure 4 An example MAC generation 400 for multipart transaction integrity protection and encryption according to some embodiments of this disclosure is shown. Figure 3 The respondent's response to Figure 1 Example MAC generation for transaction 300, where the MAC generation algorithm (e.g., Figure 4 The input to the algorithm includes ciphertext, which is included in packets transmitted by the host and packets transmitted by the device during the transaction. For example... Figure 5 As shown, ciphertext 402 from M2S request packet 306 and ciphertext 404 included in S2M response packet 308 are combined into ciphertext block 1 406 (padded to 128 bits). Encrypted data from four 128-bit data blocks transmitted from the device are used as ciphertext block 2 408, ciphertext block 3 410, ciphertext block 4 412, and ciphertext block 5 414. These five 128-bit ciphertext blocks, along with authentication data 420, are input into MAC generation algorithm 418 to generate a MAC 422 that can be used for all packets in the authentication transaction. Authentication data 420 is created from unencrypted information from M2S request packet 306 and S2M response packet 308, as well as any unencrypted information from the data packets, and is padded to 128 bits.

[0039] Each M2S request and S2M response, as well as any packet in CXL, includes a transaction tag. The transaction tag indicates the transaction associated with the packet. In some examples, the transaction tag forms part of the authentication data used for MAC generation. Other elements of the authentication data may include valid bits, flow control tags, and all or part of the address specified in the packet. These elements, and therefore the authentication data, are sent in plaintext.

[0040] As mentioned earlier, AES-GCM requires the transmission of IVs in which data is encrypted and protected for integrity, in order to address the problems caused by packet reordering by the transport fabric between the sender and receiver. To further explain,Figure 5 An example construction method for an IV 500 for multipart transaction integrity protection and encryption according to embodiments of the present disclosure is illustrated. According to the present disclosure, embodiments construct the IV based on the data being transmitted. By doing so, it is not necessary to transmit additional bits to support the out-of-order nature of the CXL protocol. That is, each side constructs the IV based on information already sent in the packet and information shared between the requester and responder. For example, the IV base, code counter, and participant identifier can be pre-shared by the requester and responder in separate messages, and this pre-shared information can be used and updated by each side along with information within the packet to generate a unique IV for each transaction. Additional information in the packet used to construct the IV may include a transaction tag and the transaction's phase number and information already included in the packet. Figure 5 Other information identified in the transaction. When a requester initiates a new transaction, the requester generates a transaction tag. Transaction tags are used to identify that a specific packet belongs to a specific transaction.

[0041] exist Figure 5 In the example, example IV 500 is constructed using information from a packet that includes a 2-bit generation ID 510, a 14-bit tag 512, and a 3-bit stage number 514. Tag 512 is generated by the sender (typically the requester) and can be, for example, a CQUID or UQID from CXL.cache (padded to 14 bits if needed) or a queue entry from CXL.mem. Each tag 512 is used sequentially and only once per generation. Generation ID 510 indicates the generation associated with tag 512. Generation ID 510 is incremented once all tags 512 have been used and their corresponding transactions have completed. Generation ID 510 and tag 512 are used as the transaction tag 520 described above. Transaction tag 520 is a field already included in the packet structure. Stage number 514 indicates which stage the packet is associated with and increments with each packet in the transaction. Generation counter 508 is also used to construct example IV 500. The generation counter increments to 508 when all tags in the current generation are retired, where a tag is retired when the transaction associated with it has been completed. Figure 5In the example of Example IV, there are four generation counters 530, 531, 532, 533— one for each generation of tags. Thus, each generation counter counts the number of completed generations associated with a particular generation ID 510, and the generation ID 510 is used to determine which generation counter to increment. For example, each time a command associated with generation ID “01” completes, generation counter 531 can be incremented. Example IV also constructs using a 90-bit IV base value 501 that can be selected between two 90-bit IV bases 502, 504. The IV bases 502, 504 are pre-shared in separate messages, and a special command message can be used to update the IV base used. Thus, the generation counter 530 and IV base value 501 are not sent with the packet. Example IV 500 also constructs using a 12-bit participant ID 506 that is either pre-shared and selected through a logical device ID (LID) field in the packet, or based on other information in the packet that identifies the transaction participant.

[0042] As described above, all tags 512 are used only once per generation. In Figure 5 the example of Example IV, there are 2 14 tags in a generation. A generation counter 508 counts the generations that have passed. While only one generation counter can be used, using two or more generation counters can prevent stalling, as the generation counter cannot be incremented until all commands within a generation have completed (and thus the tags in the generation have been advanced). In Figure 5 the example of Example IV, four generation counters 508 correspond to the four generations of tags 512, indicated by the generation ID 510 associated with the tags 512. Having four generations allows for the necessary handshaking between the requester and responder in order to keep these values synchronized before the tags 512 must be used again for corresponding generation to be generated. A special command message can be communicated to indicate that all commands in a generation have completed, and thus the generation counter can be incremented by all parties. Once the counter(s) reach a threshold, the IV base is updated. Having two IV bases allows for the necessary handshaking between the requester and responder in order to switch between which IV base is the primary IV base (PIV), and allows for the ongoing transaction to select which IV base to use for the IDE process.

[0043] By using the IV construction of Figure 3 in the context of CXL.mem, for example, a requester can use 2 14 unique tags 512 before updating the 2-bit generation ID 510. This means that a requester can generate 2 16 x 2 17a unique command. Special messages can be exchanged between the requester and other devices on the data link to increment the generation counter 508. Special messages can be exchanged between the requester and the target on the data link to select an IV basis. Once it is known that all commands against an IV basis have been completed, the IV basis is updated. Thus, when the generation counter reaches a certain threshold, the parties can switch from a first IV basis to a second IV basis, making the second IV basis the primary basis. Once all commands associated with a first IV basis have been completed, the first IV basis can be updated with special message exchanges. Employing multiple generation counters and multiple IV bases prevents stalling.

[0044] By constructing the IV in this way, the additional information that needs to be sent with each individual request is minimal, thus not adding overhead to the transaction. In the case of CXL.cache, a 2-bit generation ID is added to effectively extend the tag space. In the case of CXL.mem, the top 2 bits of the tag are used as the generation ID, essentially dividing the tag space into four generations (i.e., no additional bits are added for CXL.mem). Additional protocols are used to update the generation counter and switch between IV bases. These updates are performed less frequently than transactions, thus minimizing the overhead, while also allowing transactions to be received or processed out of order without stalling. Furthermore, a unique transaction tag is used in the MAC generation, so replaying a previous request or response in a replay attack will fail the MAC verification.

[0045] The process of encryption, decryption, and MAC generation across multiple phases between two parties and across transactions is explained using specific examples and with additional reference to Figure 6 In this particular example of a CXL.mem transaction, the host generates a M2S request to the device using AES-GCM and IV constructed as described above. That is, prior to the transaction, the host and device securely share a secret key and IV basis(es). Other pre-shared information is also exchanged, such as the party ID and generation counter. The host uses this pre-shared information and the tag included in the M2S request packet to construct the IV. The host encrypts the IV (encrypted counter 0), increments the IV, and encrypts the incremented IV (encrypted counter 1). The host then encrypts the plaintext in the M2S request (e.g., plaintext including the command opcode and parameters) using encrypted counter 1 by, for example, XORing the 37 bits of the M2S request with the 37 bits of encrypted counter 1. The host then transmits the M2S request packet to the device with the ciphertext and unencrypted authentication data. The authentication data can contain, for example, a 40-bit address, a 16-bit tag, a validity bit, and a 3-bit traffic control marker. The host also saves a state including the information being sent to the device.

[0046] Continuing the example, the device receives the M2S request packet. To decrypt the M2S request, the device creates counter 0 by constructing an IV using the pre-shared information and the unencrypted tag in the M2S request, and encrypts counter 0 (encrypt counter 0). The device increments the IV and encrypts the incremented counter (encrypt counter 1). The device then decrypts the ciphertext by XORing the 37 bits with the 37 bits of encrypt counter 1. The device then prepares, for example, a 19-bit plaintext response to the M2S request. The device encrypts the 19-bit plaintext response by XORing the plaintext with the next 19 bits of encrypt counter 1 (without using the remainder of encrypt counter 1).

[0047] To encrypt the data of the data response, the device increments counter 1 and generates encrypt counter 2, and XORs the first 128 bits of the data with encrypt counter 2 to create encrypt data block 1. The device increments counter 2 to generate encrypt counter 3, and XORs the next 128 bits of the data with encrypt counter 3 to create encrypt data block 2. The device increments counter 3 to generate encrypt counter 4, and XORs the next 128 bits of the data with encrypt counter 4 to create encrypt data block 3. The device increments counter 4 to generate encrypt counter 5, and XORs the next 128 bits of the data with encrypt counter 5 to create encrypt data block 4. The device then prepares the packet for the encrypted S2M data response header and the four encrypt data blocks including 17 bits of authentication data (e.g., 16-bit tag and validity bit). The device also generates a MAC for integrity checking of the M2S request packet, the S2M data response packet, and the data transfer packet by combining the 59 bits of authentication data from the M2S request packet and the 17 bits of authentication data from the S2M data response packet. The device generates the MAC using the combined authentication data and plaintext input, which includes the recovered plaintext of the M2S request, the plaintext of the S2M response, and the plaintext data blocks. The device then transmits the S2M data response packet, the data packet, and the MAC over the data link (e.g., CXL transfer structure) to the host.

[0048] The host receives S2M data response and data packets and decrypts the ciphertext in these packets using the same technique. To decrypt the S2M response, the host XORs the encrypted 19 bits of the S2M data response packet with the next 19 bits of the encryption counter 1. To decrypt the data from the data response, the host increments the counter 1 to generate encryption counter 2 and XORs the ciphertext of data block 1 with encryption counter 2 to retrieve the plaintext of data block 1. The host increments counter 2 to generate encryption counter 3 and XORs the ciphertext of data block 2 with encryption counter 3 to create the plaintext of data block 2. The host increments counter 3 to generate encryption counter 4 and XORs the ciphertext of data block 3 with encryption counter 4 to retrieve the plaintext of data block 3. The host increments counter 4 to generate encryption counter 5 and XORs the ciphertext of data block 4 with encryption counter 5 to retrieve the plaintext of data block 4. The host then performs the MAC generation as described above, with its plaintext input comprising the plaintext of the M2S request, the retrieved plaintext of the S2M response, the retrieved plaintext of the data blocks, and the authentication data included in the S2M response (and potentially the authentication data included in the data packets). The host compares this MAC with the MAC transmitted by the device to check the integrity of the transaction.

[0049] To further explain, Figure 6 A diagram illustrating another example transaction 600 for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 7 The example includes a CXL.cache device-to-host (D2H) write transaction. Here, the host 602 (e.g., a host CPU) is the responder and the device 604 is the requester. In this particular type of transaction, both the host and the device must ensure that the transaction is integrity protected, which means that both need to receive a MAC. In the first phase of the transaction, the device 604 generates the plaintext of the request and encrypts the plaintext into ciphertext using an IV, which is generated using the techniques described above and employing, for example, the CQID of the D2H request. The device 604 then transmits a D2H request packet 606 to the host 602 that includes the ciphertext and the authentication data. In contrast to conventional techniques, the device 604 does not transmit a MAC for the D2H request packet 606. The device 604 saves the state that includes the plaintext and the authentication data used to create the D2H request packet 606. Notably, the transaction tag (in this example, the CQID) included in the D2H request packet is part of the authentication data and is also used to generate the IV for encrypting and decrypting the request.

[0050] Host 602 receives D2H request packet 606 and uses the transaction tag in the packet (CQID of the D2H request) and the pre-shared IV basis to construct an IV. Host 602 decrypts the ciphertext and saves the recovered plaintext in the transaction state. Host 602 then generates plaintext for the H2D response and encrypts the plaintext into ciphertext using the IV generated based on the transaction tag (CQID in this example). Host 602 then transmits H2D response packet 608 including the response ciphertext and authentication data including the original transaction tag (CQID) and the encryption tag to be used for the write phase of the transaction (e.g., the host's UQID). Host 602 saves the plaintext used to create the H2D response and the authentication data in the transaction state.

[0051] Device 604 receives H2D response packet 608 and uses the transaction tag in the packet (CQID in this example) and the pre-shared IV basis to construct an IV. Device 604 decrypts the ciphertext to recover the plaintext of the host response including the tag received from the host (UQID in this example) and saves this information in the transaction state. In response to the H2D response, device 604 generates plaintext for the D2H data header and encrypts the plaintext using the IV constructed based on the tag received from the host (UQID in this example). Device 604 also prepares a plaintext data block and encrypts the plaintext into a ciphertext data block using the IV constructed based on the tag received from the host (UQID in this example). Device 604 then transmits D2H data header packet 610 including the data header ciphertext and authentication data including the second transaction tag (the host's UQID). Device 604 also transmits D2H data block packet 612 including the ciphertext data block. Device 604 saves the plaintext of the D2H data header and the plaintext data block in the transaction state. As described above, device 604 also generates MAC 614 using the IV constructed based on the tag received from the host (UQID in this example). The plaintext input used to generate MAC 614 includes the plaintext used by device 604 to create the D2H request packet, the plaintext recovered from H2D response packet 608, the plaintext used by device 604 to create D2H data header packet 610, and the plaintext of the data block. The authentication data used to generate MAC 614 includes the concatenation of the authentication data transmitted by device 604 and the authentication data received from host 602. At this point, the device can save the MAC and discard the data used to generate the MAC.

[0052] Host 602 receives D2H data header packet 608 and data packet 610 and uses the host's transaction tag (UQID) in the packets to construct an IV as described above. Host 602 decrypts the ciphertext in those packets and saves the recovered plaintext in the transaction state. Host 602 also generates a MAC using the IV constructed based on the host's tag (UQID in this example) to compare to the received MAC 614. The plaintext input for this MAC includes the plaintext recovered from D2H request packet 606, the plaintext used by host 602 in transmitting H2D response packet 608, the plaintext recovered from D2H data header packet 610, and the recovered plaintext of data block packet 612, all of which are available in the saved transaction state. The authentication data used to generate the MAC includes the concatenation of the authentication data transmitted by device 604 and the authentication data received from host 602. Host 602 then compares this MAC to the MAC 614 received from device 604 to verify the integrity of the transaction.

[0053] Host 602 then generates plaintext for an H2D response (e.g., an acknowledgement) and encrypts this plaintext into ciphertext using an IV constructed based on the original transaction tag (CQID of the device in this example). Host 602 then transmits a second H2D response packet 616 that includes the response ciphertext and authentication data including the transaction tag (CQID). Host 602 saves the plaintext used to create the second H2D response and the authentication data in the transaction state. Host 602 then generates a MAC 618 using an IV constructed based on the original transaction tag (CQID of the device in this example). The plaintext input for MAC 618 includes the plaintext recovered from D2H request packet 606, the plaintext used by host 602 in transmitting H2D response packet 608, the plaintext recovered from D2H data header packet 610, the recovered plaintext of data block packet 612, and the plaintext used to create the second H2D response packet 616, all of which are available in the saved transaction state. The authentication data used to generate the MAC includes the concatenation of the authentication data transmitted by device 604 and the authentication data received from host 602. Host 602 sends the final MAC 618 to device 604. In a particular variant, the host and device can agree that the state information prior to the first MAC is not used to generate the second MAC. Instead, the first MAC is used to represent the information exchanged prior to the first MAC. In such a variant, host 602 generates the second MAC 618 using the first MAC and the plaintext used to create the second H2D response packet 616 as input to the MAC generation. When device 604 performs the MAC check using the plaintext recovered from the second H2D response packet and the MAC 614 it sent to the host. Thus, if the parties can save the state (the MAC or a portion of the MAC) that covers the prior information, they do not have to save all of the information sent and received.

[0054] Device 604 performs the MAC check by retrieving the plaintext from the saved transaction state and generating a MAC for comparison using an IV constructed based on the original transaction tag (in this example, the CQID of the device) as described above. This MAC is then compared to the MAC 618 received from host 602 to confirm the integrity of the transaction.

[0055] Thus, both host 602 and device 604 can ensure that the transaction is integrity protected, as both receive a MAC. The MAC generation and encryption is split between host 602 and device 604, and thus the number of MACs sent can be reduced to two (one in each direction). The party verifying the MAC (either the requesting or responding party) controls the transaction tag included in the authentication data used in the MAC generation. This party can ensure that the tag is unique and used only once. Thus, replaying a previous request or response will fail the MAC verification.

[0056] To further explain, Figure 7 A flowchart of an example method for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 5 The example of FIG. 7 shows a simple request and response transaction between a requesting device 752 and a responding device 750, with the response provided with a MAC. The flow begins with the requesting device 752 selecting a tag 701 for the transaction, and generating an IV 706 using the tag 701, a pre-shared IV base, and other information such as described above with reference to Figure 5 At request generation 708, the requesting device 752 generates a request plaintext 710, and encrypts the request plaintext 710 at request encryption 712 using the IV 706 and a shared encryption key 714. A packet 754 is created at packet generation 718 using the request ciphertext 716 and authentication data 702 including the tag 701, and transmitted at packet transmission 720.

[0057] The responding device 750 receives the packet 754 including the request ciphertext 716 and authentication data 702 including the tag 701. The responding device uses the tag 701, a pre-shared IV base, and other information such as described above with reference to Figure 5The other information described for IV generation 722 to create IV 706. The responding device 750 applies the request ciphertext 716, the IV 706, and the encryption key 714 to request decryption 724 to recover the request plaintext 710. At response generation 726, the responding device 750 uses the request to generate a response plaintext 728. At response encryption 730, the responding device 750 increments the IV 706 (e.g., by incrementing the phase number) and uses the incremented IV and the encryption key 714 to generate a response ciphertext 732. At authentication data generation 733, the responding device 750 creates authentication data 735 that includes the tag 701. At response packet generation 734, the responding device creates a packet 756 that includes the response ciphertext 732 and the authentication data 735 that includes the tag 701. The responding device also generates a MAC 738 at MAC generation 736 using the IV 706, the encryption key 714, the authentication data 702 and 735, and an input block that includes the received request ciphertext 716 and the generated response ciphertext 732. At packet / MAC transmission 740, the responding device 750 transmits the packet 756 and the MAC 738 to the requesting device 752. The MAC 738 can be transmitted in the packet 756 or in a separate packet.

[0058] The requesting device 752 receives the packet 756 and the MAC 738. At response decryption 742, the requesting device 752 uses the tag 701 identified from the authentication data 735, the pre-shared IV basis, and other information described above with reference to FIG. 5 to recreate the IV 706. The requesting device 752 increments the IV 706 corresponding to the phase of the transaction and uses the incremented IV and the encryption key 714 to decrypt the response ciphertext 732 to recover the response plaintext 728. At MAC generation 743, the requesting device 752 generates a verification MAC 744 using the IV, the encryption key 714, the authentication data 735, and an input block that includes the original request ciphertext 716 and the received response ciphertext 732. If it is determined at MAC comparison 746 that the received MAC 738 and the verification MAC 744 match, the message flow in the transaction is authenticated. Although only one message from the requesting device 752 to the responding device 750 and one message from the responding device 750 to the requesting device 752 are depicted, it should be understood that multiple messages (e.g., requests, responses, data headers, data, acknowledgements) can be exchanged unidirectionally or bidirectionally before the MACs are generated and verified. Figure 8 The other information described for IV generation 722 to create IV 706. The requesting device 752 increments the IV 706 corresponding to the phase of the transaction and uses the incremented IV and the encryption key 714 to decrypt the response ciphertext 732 to recover the response plaintext 728. At MAC generation 743, the requesting device 752 generates a verification MAC 744 using the IV, the encryption key 714, the authentication data 735, and an input block that includes the original request ciphertext 716 and the received response ciphertext 732. If it is determined at MAC comparison 746 that the received MAC 738 and the verification MAC 744 match, the message flow in the transaction is authenticated. Although only one message from the requesting device 752 to the responding device 750 and one message from the responding device 750 to the requesting device 752 are depicted, it should be understood that multiple messages (e.g., requests, responses, data headers, data, acknowledgements) can be exchanged unidirectionally or bidirectionally before the MACs are generated and verified.

[0059] To further explain, Figure 8 A flow diagram of an example method for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 8The example of FIG. 8 shows at least a portion of a transaction between a first device 801 and a second device 803. In various arrangements, the first device 801 can be the host or master (e.g., a host processor), or the second device 803 can be the host or master. In various scenarios, the first device 801 can be the requestor of the transaction and the second device 803 can be the responder or target, or the first device 801 can be the responder or target and the second device 803 can be the requestor. The transaction is performed over a data link. In some examples, the data link is a bus, such as a Compute Express Link (CXL) protocol bus. In other examples, the data link can be a network link utilizing, for example, a web-based protocol. The transport structure or transport layer that delivers the transaction packets between the first device 801 and the second device 803 can reorder the transactions such that the packets can not be received in the order that they were sent. To ensure the safety and trustworthiness of the data in the transaction packets, the communication between the first device 801 and the second device 803 utilizes counter mode symmetric encryption, such as AES-GCM.

[0060] Figure 8 The method of FIG. 8 can include generating 802, by the second device 803, a first packet 805. To generate the first packet 805, the second device applies an encryption key 807 to plaintext 809 to generate ciphertext 811. The plaintext 809 can be a command, a response, an acknowledgement, a data header, a data block, etc. The first packet 805 includes the ciphertext 811 and authentication data 813, which includes a tag 815 that identifies the first packet 805 as part of the transaction. In the case where the first packet 805 is a request packet and the second device 803 is the requestor, the second device 803 can select the tag 815 to be used for the transaction. In the case where the second device 803 is the responder, the tag 815 can be obtained from a request packet originally transmitted by the first device 801. It should be understood that one or more packets of the transaction can precede the first packet 805. Figure 8 The method of FIG. 8 further includes transmitting 804, by the second device 803, the first packet 805 to the first device 803. The plaintext 809 is stored by the second device 803 as part of a saved state of the transaction.

[0061] Figure 8 The method of FIG. 8 can further include decrypting 806, by the first device 801, the first packet 805 transmitted by the second device 803 over the data link. The first device 801 decrypts the ciphertext 811 in the first packet 805 using the encryption key 807 to recover the plaintext 809. The plaintext 809 is stored by the first device 801 as part of a saved state of the transaction.

[0062] Figure 8The method of can further include the first device 801 generating 808 a second packet 817 in response to receiving the first packet 805. To generate the second packet 817, the first device 801 applies the encryption key 807 to plaintext 819 to generate ciphertext 821. The plaintext 819 can be a response, an acknowledgement, a data header, a data block, etc. The second packet 817 includes the ciphertext 821 and authentication data 823, which includes the tag 815, which identifies the second packet 817 as part of the transaction.

[0063] Figure 8 The method of can further include the first device 801 generating 808 a second packet 817 in response to receiving the first packet 805. To generate the second packet 817, the first device 801 applies the encryption key 807 to plaintext 819 to generate ciphertext 821. The plaintext 819 can be a response, an acknowledgement, a data header, a data block, etc. The second packet 817 includes the ciphertext 821 and authentication data 823, which includes the tag 815, which identifies the second packet 817 as part of the transaction.

[0064] Figure 9 The method of can further include the first device 801 generating 808 a second packet 817 in response to receiving the first packet 805. To generate the second packet 817, the first device 801 applies the encryption key 807 to plaintext 819 to generate ciphertext 821. The plaintext 819 can be a response, an acknowledgement, a data header, a data block, etc. The second packet 817 includes the ciphertext 821 and authentication data 823, which includes the tag 815, which identifies the second packet 817 as part of the transaction.

[0065] To further explain, Figure 9 A flowchart of an example method for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 8 The example of Figure 9 The method of Figure 9 The method of may also include the second device 803 generating one or more additional packets 905 of the transaction. For example, the additional packets 905 can be a response to the second packet 817, an acknowledgement of receipt of the second packet 817, or an acknowledgement that a command has been completed. The one or more additional packets 905 can be generated in the same manner as described above (e.g., the generation of the first packet 805). Figure 9 The method of may also include the second device 803 generating a second MAC 925. The second device 803 can generate the second MAC 925 in the same manner as described above, i.e., the data from all packets of the transaction (including the additional packets 905) prior to the generation of the second MAC 925 are used to generate the second MAC 925. Alternatively, the second MAC 925 can be generated based on the first MAC 825 and the additional packets 905 since the generation of the first MAC 825. Figure 9 The method of may also include the second device sending one or more additional packets 905 of the transaction to the first device 801.

[0066] Figure 8 The example of Figure 9 The method of Figure 9 The method of includes the first device 801 receiving 902 from the second device 803 one or more additional packets 905 of the transaction and a second MAC 925 of the plurality of packets 805, 817, 905 of the transaction including the one or more additional packets 905 for authenticating the transaction. For example, the additional packets 905 can be a response to the second packet 817, an acknowledgement of receipt of the second packet 817, or an acknowledgement that a command has been completed. The second MAC 925 can be used to verify the integrity of all packets of the transaction, including the one or more additional packets 905 just received. The one or more additional packets 905 and the second MAC 925 are received over the data link.

[0067] Figure 9 The method of also includes the first device decrypting 904 the one or more additional packets 905. As described above, the first device 801 decrypts 904 the one or more additional packets 905 by applying the encryption key 807 to the ciphertext 907 in the additional packets 905 to recover the plaintext 909.

[0068] Figure 9The method also includes a first device 801 using data included in multiple packets 805, 817, 905 to generate a third MAC 935 906 for authenticating transactions, comprising one or more additional packets 905. In some examples, the first device 801 uses plaintext 912 to generate the MAC 935 912 for authenticating transactions, which can be transmitted by the first device 801 or recovered from packets sent by the second device 803. For example, plaintext 809 recovered from a first packet 805 transmitted by the second device 803, plaintext 819 generated by the first device 801 and transmitted in a second packet 817, and plaintext 909 recovered from a third packet 905 transmitted by the second device 803 are used as plaintext inputs to an authentication tag algorithm such as AES-GCM.

[0069] Figure 10 The method also includes the first device 801 authenticating multiple packets 908 that include the one or more additional packets based on a comparison of the second MAC 925 and the third MAC 935. In some examples, the first device 801 verifies the integrity of all packets exchanged in a transaction by determining whether the second MAC 925 and the third MAC 935 are the same.

[0070] To further explain, Figure 10 A flowchart illustrating an example method for multipart transaction integrity protection and encryption according to embodiments of the present disclosure is provided. Figure 8 The example expands Figure 10 The method, because Figure 5 The method includes a first device 801 generating an initialization vector (IV) 1003 based on a combination of pre-shared information (such as an IV base 1005) and information included in the first packet (such as a tag 815), wherein the IV 1003 is used to decrypt data in the first packet 805. In some embodiments, the above reference is used. Figure 5 Other information described is used to construct the IV. As previously mentioned, to reduce link bandwidth overhead, the IV is not sent with each packet. However, pre-sharing the IV is not possible when packets can be reordered by the transport structure. Therefore, the first device 801 and the second device 803 share the IV base 1005 that will form a part of the IV (e.g., the first 90 bits of the IV), and can also pre-share as referenced above. Figure 5 The other information described will be included in IV 1003. The remainder of IV 1003 is constructed using the information included in the package, such as the references above. Figure 10The described tag 815 (e.g., transaction tag) and other information. Tag 815 is chosen by the requester of the transaction, and each tag is used only once per generation (i.e., all tags are exhausted before the generation ID is incremented). Therefore, a unique IV for the transaction is generated when sending or receiving packets based on the information in the packet. Because the IV is generated using information unique to the transaction, problems caused by reordering are avoided. Furthermore, because tag 815 is already included to identify the command, no additional overhead is introduced. Figure 11 In the example, the first device 801 uses the pre-shared IV base 1005 and the tag 815 included in the first packet 805 to generate IV 1003, and uses IV 1003 to decrypt the ciphertext in packet 805.

[0071] To further explain, Figure 11 A flowchart illustrating an example method for multipart transaction integrity protection and encryption according to embodiments of the present disclosure is provided. Figure 9 The method is similar to Figure 11 In addition to the methods, Figure 11 In this context, the device does not generate or transmit a MAC address before receiving it. Figure 11 The method includes exchanging multiple packets 1105 of a transaction 1102 between a first device 1101 and a second device 1103. These multiple packets include one or more packets transmitted by the first device to the second device and one or more packets received from the second device.

[0072] Figure 11 The method also includes a first device 1101 storing 1104 transaction state information 1107, which covers data included in each of the multiple packets 1105. In some examples, the transaction state information includes plaintext blocks encrypted and transmitted to the second device 1103, as well as plaintext blocks recovered from ciphertext transmitted by the second device 1103. The transaction state information also includes authentication data transmitted to and received from the second device 1103. In some examples, the transaction state information includes a cryptographic representation of the data exchanged in the multiple packets. For example, the transaction state information may include a MAC representing a previous message stream. Therefore, the transaction state information can cover data included in each of the multiple packets by storing data or a cryptographic representation of the data.

[0073] Figure 11The method of further includes the first device 1101 generating 1106 a second MAC 1111 in response to receiving the first MAC 1109 from the second device 1103, where the MAC is generated based on data included in each of the plurality of packets. In some examples, the first device 1101 generates the second MAC 1111 using a plaintext input that includes all plaintext from the saved transaction state, including plaintext that the first device 1101 encrypted and transmitted to the second device 1103, and plaintext recovered from encrypted data in the packets received from the second device 1103.

[0074] Figure 12 The method of further includes the first device 1101 authenticating 1108 the plurality of packets 1105 based on a comparison of the first MAC 1109 and the second MAC 1111. In some examples, the first device 1101 verifies the integrity of all packets exchanged in the transaction by determining whether the first MAC 1109 and the second MAC 1111 are the same.

[0075] To further explain, Figure 12 A flowchart of an example method for multi-part transaction integrity protection and encryption according to embodiments of the present disclosure is set forth. Figure 12 The method of includes sharing 1202 an initialization vector (IV) basis 1205 between the first device 1201 and the second device 1203. The IV basis 1205 can be transmitted or received by the first device 1201 using a special protocol message for sharing the IV basis.

[0076] Figure 5 The method of further includes the first device 1201 generating 1204 an IV 1207 for the transaction using the IV basis 1205 and a transaction label 1209. In some examples, the first device 1201 selects the transaction label 1209 when creating a request packet for the transaction. In some examples, the first device 1201 generates the IV 1207 by concatenating the IV basis 1205, the transaction label 1209, and other information that is pre-shared between the first device 1201 and the second device 1203 or that is related to control information from the request packet. For example, the IV 1207 is constructed as described above with reference to Figure 12

[0077] Figure 12 The method of further includes the first device 1201 transmitting 1206 a request packet 1221 that includes data encrypted using the IV 1207 and a shared encryption key. Transmitting data using an IV is described above. Figure 12 The method of further includes the first device 1201 receiving 1208 a second packet 1211 from the second device 1203. The second device 1203 returns the same transaction label 1209 in the second packet 1211. ​

[0078] Figure 12 The method of 1200 further includes the first device 1201 generating 1210 an IV 1207 for the transaction using the IV base 1205 and the transaction tag 1209 read from the second packet 1211. It should be appreciated that because the IV 1207 is generated using shared state information including the IV base 1205 and the same transaction tag 1209, the initial IV 1207 and the second IV 1207 will be the same.

[0079] ​ The method of 1200 further includes the first device 1201 decrypting 1212 the encrypted data in the second packet 1211 using the regenerated IV 1207. Decrypting data using an IV is described above.

[0080] While the techniques that create this example can be applied to any communication protocol, it is most useful for transaction-based protocols in which a significant percentage of messages are small or in which out-of-order delivery is possible, such as CXL and some web-based protocols. For transaction-based protocols, the end of a transaction is a natural boundary for the final MAC. In addition, the overhead associated with MAC generation for small messages that are sent is high. To adapt the above-described techniques to a particular protocol, the threat model for the protocol should be identified, and all transaction types in the protocol should be identified. For each transaction type, all messages exchanged to complete the transaction should be identified. Both sides of the transaction must maintain enough state so that if needed, they can generate a MAC that covers all previous message flows of the transaction. Once the final flow of the transaction has been transmitted or verified, all of the retained state of the transaction can be discarded, and in some implementations, the retained state can be discarded once the MAC of the previous flow has been transmitted or verified. For each transaction and each message in the transaction, if an attacker can inspect a message, modify a message, create a fake message, or tamper with a message, it should be determined whether the attacker can cause undetected harm as defined by the threat model. If harm is possible, a MAC that covers all previous messages in the transaction should be inserted into the message that can cause harm. Each party to the transaction must retain the MAC or the saved state until the message sequence is complete so that they can verify the final MAC or generate intermediate MACs if needed. The retained state can be discarded when the final MAC is transmitted.

[0081] In view of the explanations set forth above, the reader will recognize many advantages of the multi-part transaction integrity protection and encryption according to embodiments of the present disclosure, including:

[0082] • Based on the fact that data is transmitted in both directions, MAC generation and encryption and decryption are split between the requester and the responder, allowing one MAC to authenticate multiple packet exchanges, reducing the number of MAC transmissions and saving bandwidth on the data link.

[0083] • The IV is constructed from the data being transmitted or received, so no extra bits need to be transmitted to support the out-of-order nature of various protocols.

[0084] • The MAC always includes unique information as part of the IV, which prevents all replay attacks.

[0085] The exemplary embodiments of the present disclosure are primarily described in the context of a fully functional computer system for multi-part transaction integrity protection and encryption. However, those skilled in the art will appreciate that the present disclosure is equally applicable in a computer program product setting to a suitably programmed computer or a computer readable storage medium having stored thereon instructions for causing a computer to implement the steps of the present disclosure. Such a computer program product can be loaded into a computer or other programmable data processing device to cause a series of machine steps to be performed that implement the present disclosure. This computer program product can be also be sold, by itself or as part of a larger system, as a computer program product. One skilled in the art will appreciate that the system as described is merely an example representation of equivalent systems.

[0086] The present application can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0087] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, a magnetically encoded device such as magnetic strip(s), an optically encoded device such as optical fiber, and / or any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire cable, as these do not persist for a sufficient amount of time to be tangibly stored.

[0088] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0089] Computer readable program instructions for carrying out operations of the present application can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computing / processing device, partly on the user's computing / processing device, as a stand-alone software package, partly on the user's computing / processing device and partly on a remote computing / processing device or entirely on the remote computing / processing device or server. In the latter scenario, the remote computing / processing device can be connected to the user's computing / processing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing / processing device, for example, through the Internet using an Internet Service Provider. In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0090] The computer readable program instructions can also be loaded onto a computing / processing device, other programmable data processing apparatus, or other device to cause a series of operations to be performed on the computing / processing device, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computing / processing device, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0091] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include a non-transitory computer readable storage medium that can be a computer readable storage medium having no data signals on it. The computer readable storage medium, having stored thereon this computer readable program instructions, can also include a computer program product that comprises all the respective features enabling the implementation of the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0092] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0093] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0094] From the foregoing, it will be appreciated that modifications and changes can be made by those skilled in the art to various embodiments of the present disclosure without departing from the true spirit of the present disclosure. The description is intended to be illustrative, and not to limit the scope of the application. What is desired to be protected by letters patent is set forth in the following claims, the scope of which is to be interpreted in accordance with the principles and spirit of the disclosure and the scope of the appended claims.

Claims

1. A method for multi-part transaction integrity protection and encryption, the method comprising: A first message authentication code (MAC) is generated by a first device for authenticating transactions from a plurality of packets, the plurality of packets including at least a first packet received from a second device on a data link and a second packet generated by the first device in response to receiving the first packet, wherein the first MAC is generated using data included in the plurality of packets; as well as The first device transmits the second packet and the first MAC to the second device over the data link.

2. The method according to claim 1, wherein, The plurality of packets includes at least one of a request packet and a response packet.

3. The method according to claim 1, wherein, The multiple packets include a data header packet and one or more data transmission packets.

4. The method according to claim 1, further comprising: The first device receives one or more additional packets of the transaction from the second device and a second MAC for authenticating the transaction, including the one or more additional packets; The first device decrypts the one or more additional packets; The first device uses data included in the plurality of packets to generate a third MAC for authenticating the transaction, comprising the plurality of packets including the one or more additional packets; as well as The first device authenticates the plurality of packets, including the one or more additional packets, based on a comparison between the second MAC and the third MAC.

5. The method according to claim 1, further comprising: The first device generates an initialization vector IV based on a combination of pre-shared information and information included in the first packet, wherein the IV is used to decrypt the data in the first packet.

6. The method according to claim 5, wherein, The pre-shared information includes at least one of the IV base number and the generation number.

7. The method according to claim 6, wherein, One or more commands are used to update at least one of the IV base and the generation count.

8. The method according to claim 5, wherein, The information included in the first package includes at least a tag and a code identifier for the tag.

9. The method according to claim 1, wherein, The transaction is reordered by the data link.

10. The method according to claim 1, wherein, The data link is a bus.

11. The method according to claim 10, wherein, The bus in question is the Compute Fast Link (CXL) bus.

12. The method according to claim 1, wherein, The first device is a host processor.

13. The method according to claim 1, wherein, The second device is the host processor.

14. An apparatus for multipart transaction integrity protection and encryption, the apparatus comprising a first device coupled to a data link, the first device being configured to exchange packetized data in the multipart transaction with one or more other devices on the data link, wherein the first device is configured to: The first device generates a first message authentication code (MAC) for authenticating transactions from a plurality of packets, the plurality of packets including at least a first packet received from the second device on the data link and a second packet generated by the first device in response to receiving the first packet, wherein the first MAC is generated using data from the plurality of packets; and The first device transmits the second packet and the first MAC to the second device over the data link.

15. The apparatus according to claim 14, wherein, The plurality of packets includes at least one of a request packet and a response packet.

16. The apparatus according to claim 14, wherein, The multiple packets include a data header packet and one or more data transmission packets.

17. The apparatus according to claim 14, wherein, The first device is also configured to: The first device receives one or more additional packets of the transaction from the second device and a second MAC for authenticating the transaction, including the one or more additional packets; The first device decrypts the one or more additional packets; The first device uses data included in the plurality of packets to generate a third MAC for authenticating the transaction, comprising the plurality of packets including the one or more additional packets; as well as The first device authenticates the plurality of packets, including the one or more additional packets, based on a comparison between the second MAC and the third MAC.

18. The apparatus according to claim 14, wherein, The first device is also configured to: The first device generates an initialization vector IV based on a combination of pre-shared information and information included in the first packet, wherein the IV is used to decrypt the data in the first packet.

19. The apparatus according to claim 18, wherein, The pre-shared information includes at least one of the IV base and the algebra.

20. The apparatus according to claim 19, wherein, One or more commands are used to update at least one of the IV base and the generation count.

21. The apparatus according to claim 18, wherein, The information included in the first package includes at least a tag and a code identifier for the tag.

22. The apparatus according to claim 14, wherein, The transaction is reordered by the data link.

23. The apparatus according to claim 14, wherein, The data link is a bus.

24. The apparatus according to claim 23, wherein, The bus in question is the Compute Fast Link (CXL) bus.

25. A method for multi-part transaction integrity protection and encryption, the method comprising: Multiple packets of transactions are exchanged between the first device and the second device; The first device stores transaction status information, which covers data included in each of the plurality of packets; The first device generates a second MAC in response to receiving a first message authentication code (MAC) from the second device, wherein the second MAC is generated based on the transaction state information; as well as The first device authenticates the plurality of packets based on a comparison of the first MAC and the second MAC.

Images