Patent Description:
One or more embodiments may apply to a cipher engine that performs data decryption on an AXI (Advanced eXtensible Interface) bus.

In a microcontroller unit (MCU) or microprocessor unit (MPU), a master device (e.g., a processing core) may access a slave device (e.g., a memory or an interface to an external memory) to retrieve data therefrom via an interconnect, such as an AXI bus. The AMBA AXI protocol specification is given in document "AMBA® AXI™ and ACE™ Protocol Specification", ARM IHI 0022E (ID033013), published online by ARM®.

The data fetched from the memory device may be encrypted for security reasons. Therefore, a memory cipher engine (MCE) may be coupled to the AXI bus to decrypt the data retrieved from the memory (i.e., the ciphertext) before forwarding the data to the master device as plaintext.

For instance, document <CIT> discloses a hardware cipher engine that supports both encryption (i.e., the input data is plaintext data and the output data is ciphertext data, and the cipher circuit encrypts a block of plaintext data from a sequence of blocks of plaintext data to generate a block of ciphertext data using the cipher operation) and decryption (i.e., the input data is ciphertext data and the output data is plaintext data, and the cipher circuit decrypts a block of ciphertext data from a sequence of blocks of ciphertext data to generate a block of plaintext data using the cipher operation). The cipher operations may be the same for encryption and decryption (e.g., with the cipher operation being a stream cipher operation), or there may be an encryption operation and a different decryption operation. The cipher engine comprises an input for switching the cipher engine between an encryption mode of operation and a decryption mode of operation. Further, the hardware cipher engine may be switchable between a random-access mode of operation and a sequential mode of operation. It may comprise a mode-switching input for receiving an input (e.g., a signal, or a register bit or register value) that determines whether or not the engine operates in the random-access mode. In some embodiments the cipher operation may be a block-chain mode of operation of a block cipher, such as Cipher Block Chaining (CBC) mode encryption, Propagating Cipher Block Chaining (PCBC) mode encryption or decryption, or Cipher Feedback (CFB) mode encryption. In other embodiments the cipher operation may be a stream cipher. The cipher operation may comprise generating or accessing a sequence of keystream blocks. It may comprise performing a combining operation, such as an XOR operation, between a keystream block and the block of input data. The sequence of keystream blocks may have an initial keystream block, and the cipher circuit may be configured to perform the combining operation with a keystream block that has the same received position in the sequence of keystream blocks (relative to the initial keystream block) as the block of input data has in the sequence of blocks of input data.

In certain applications, the memory cipher engine may operate according to plural decryption modes, such as a block cipher mode and a stream cipher mode, resulting in different types of data traffic on the AXI bus. The selection of the operation mode may be dynamic, such that the type of data traffic on the AXI bus may change from time to time, with the risk of generating inconsistencies and/or protocol violations.

Therefore, there is a need in the art to provide improved memory cipher engines that are able to decrypt mixed data traffic fetched from a slave device.

An object of one or more embodiments is to contribute in providing such improved memory cipher engines.

According to one or more embodiments, such an object can be achieved by means of a processing system having the features set forth in the claims that follow.

One or more embodiments may relate to a corresponding method of operation.

The claims are an integral part of the technical teaching provided herein in respect of the embodiments.

In one or more embodiments, a processing system comprises a master device and a slave device coupled via an interconnection bus. The master device is configured to issue memory burst transaction requests via the interconnection bus to fetch data from the slave device. The processing system comprises a cipher engine coupled to the interconnection bus and configured to decrypt the data fetched from the slave device to produce plaintext data for the master device. The cipher engine selectively operates according to a stream cipher operation mode, wherein a stream of data is fetched from the slave device and processed in a combinatorial circuit to produce the plaintext data, or according to a block cipher operation mode, wherein a block of data is fetched from the slave device, stored in a buffer memory of the cipher engine, and processed in a cryptographic engine to produce the plaintext data. The cipher engine is configured to stall a read data channel of the interconnection bus between the slave device and the master device in response to the cipher engine switching from the block cipher operation mode to the stream cipher operation mode. The cipher engine is configured to reactivate the read data channel in response to a last beat of a read burst of the plaintext data produced by the cryptographic engine and corresponding to the block of data stored in the buffer memory being received by the master device.

In one or more embodiments, the cipher engine may comprise a first register configured to store, for each of the memory transaction requests, information as to whether the memory transaction request is to be processed in the block cipher operation mode. The cipher engine may switch between the stream cipher operation mode and the block cipher operation mode as a function of data fetched from the first register in response to the master device having received all data of a previous memory transaction request.

In one or more embodiments, the cipher engine may comprise a second register configured to store, for each of the memory transaction requests, information as to whether the memory transaction request is to be processed in the stream cipher operation mode. The cipher engine may stall the read data channel as a function of data fetched from the second register in response to the slave device having returned all data of a previous memory transaction request.

In one or more embodiments, the slave device may include a memory and/or an interface to a memory external to the processing system.

In one or more embodiments, the stream cipher operation mode may include a counter operation mode and/or the block cipher operation mode may include an electronic codebook operation mode.

In one or more embodiments, the cipher engine may switch between the stream cipher operation mode and the block cipher operation mode as a function of a data address included in the memory transaction requests.

In one or more embodiments, the interconnection bus may operate according to an Advanced eXtensible Interface (AXI) protocol.

In one or more embodiments, a method of operating a processing system according to one or more embodiments may comprise issuing, at the master device, memory burst transaction requests via the interconnection bus to fetch data from the slave device. The method may comprise decrypting the data fetched from the slave device to produce plaintext data for the master device. Decrypting data may include selectively operating the cipher engine according to a stream cipher operation mode, wherein a stream of data is fetched from the slave device and processed in a combinatorial circuit to produce the plaintext data, or according to a block cipher operation mode, wherein a block of data is fetched from the slave device, stored in a buffer memory of the cipher engine, and processed in a cryptographic engine to produce the plaintext data. The method may comprise stalling a read data channel of the interconnection bus between the slave device and the master device in response to the cipher engine switching from the block cipher operation mode to the stream cipher operation mode. The method may comprise reactivating the read data channel in response to a last beat of a read burst of the plaintext data produced by the cryptographic engine and corresponding to the block of data stored in the buffer memory being received by the master device.

One or more embodiments may thus facilitate a dynamic switching operation of a memory cipher engine in a processing system between a block cipher operation mode and a stream cipher operation mode while complying with the requirements of the communication protocol of the interconnection bus of the processing system.

Moreover, particular configurations, structures, or characteristics may be combined in any adequate way in one or more embodiments.

Throughout the figures annexed herein, unless the context indicates otherwise, like parts or elements are indicated with like references/numerals and a corresponding description will not be repeated for the sake of brevity.

As previously discussed, in a processing system such as a microcontroller unit (MCU) or a microprocessor unit (MPU), a cryptographic engine can be used to cipher (e.g., encrypt and/or decrypt) data provided by a slave device (e.g., an external memory controller) on a communication bus (e.g., an AXI bus) in a dual manner. A first operation mode, referred to as stream ciphering (e.g., a counter (CTR) encryption mode), may be used for high-speed communication and generic data transmission. A second operation mode, referred to as block ciphering (e.g., an electronic codebook (ECB) encryption mode), may be used for secure data transmission. Depending on the selection of the operation mode of the cryptographic engine, data traffic on the bus may therefore be of different kinds.

<FIG> is a block diagram exemplary of a processing system including an on-the-fly memory cipher engine (MCE) that operates in a first operation mode. As exemplified in <FIG>, a processing system <NUM> (e.g., a MCU or a MPU) may comprise a master device <NUM> (e.g., a processing core) and a slave device <NUM> (e.g., a memory or a memory interface) coupled via an interconnection bus <NUM> (e.g., an AXI bus). The interconnection bus <NUM> may comprise an address channel <NUM> and a data channel 32a, 32b. The processing system <NUM> may comprise a memory cipher engine <NUM> coupled to the interconnection bus <NUM> and configured to apply Advanced Encryption Standard (AES) ciphering (e.g., AES encryption and/or decryption) to the data on the bus <NUM> by means of an AES engine <NUM>.

As exemplified in <FIG>, the memory cipher engine <NUM> may operate in a first operation mode, e.g., a stream cipher mode such as a counter (CTR) mode. In this operation mode, the master device <NUM> issues an AXI request on the address channel <NUM> that includes the address of the data to be retrieved from the slave device <NUM>. The AXI request is propagated to the slave device <NUM> and to the AES engine <NUM> of the cipher engine <NUM>. The AES engine <NUM> computes a respective keystream as a function of the data address, and applies XOR processing <NUM> to the encrypted data retrieved from the slave device <NUM> via the data channel 32a and the keystream computed by the AES engine <NUM>. The corresponding plaintext data is returned to the master device <NUM> via the data channel 32b. Therefore, the encrypted data is XORed (e.g., in a combinatorial manner) with a precomputed keystream, which is generated as a function of the data address, while the burst request is propagated to the slave device <NUM> without modifications.

The stream ciphering operation mode exemplified in <FIG> relies on a simple and straightforward data transfer on the AXI bus <NUM>, insofar as the address channel <NUM> and the data channel <NUM> are parallel. However, such an operation mode may be vulnerable to brute force attacks on the data bus.

<FIG> is a block diagram exemplary of the processing system <NUM> of <FIG> where the on-the-fly memory cipher engine <NUM> operates in a second operation mode, e.g., a block cipher mode such as an electronic codebook (ECB) mode. In this operation mode, the master device <NUM> issues an AXI request on the address channel 31a that includes the address of the data to be retrieved from the slave device <NUM>. The AXI request is processed in a processing block <NUM> of the memory cipher engine <NUM> to format the request to the block size of the cryptographic engine (i.e., the AES engine <NUM>). The formatted AXI request (e.g., Address MOD(AES_size)) is propagated to the slave device <NUM> via the address channel 31b. The corresponding data retrieved from the slave device <NUM> via the data channel 32a is stored in a buffer (e.g., a register) <NUM> of the memory cipher engine <NUM>. The buffer <NUM> may have a size equal to the AES_size. The AES engine <NUM> decrypts the data stored in the buffer <NUM>, and the corresponding plaintext data is returned to the master device <NUM> via the data channel 32b.

The block ciphering operation mode exemplified in <FIG> is much less vulnerable to side-channel attacks (SCA) or brute force attacks on the data bus, but it is slower than the stream cipher mode since the operation of the AES engine on the buffered data introduces additional latency.

In one or more embodiments as exemplified in <FIG>, the memory cipher engine <NUM> may switch between a first operation mode (e.g., stream ciphering) and a second operation mode (e.g., block ciphering) dynamically, e.g., as a function of the data address of the AXI request. For instance, this approach may be advantageous when the slave device <NUM> (e.g., an interface towards an external memory) stores both generic data with a low security level (that can be retrieved with low latency from the cryptographic engine) and secure data with higher computation latency (that can be retrieved with higher latency from the cryptographic engine). Since the cryptographic engine involves a high gate count (e.g., around sixteen thousand logic gates), using the same engine for both operation modes is particularly advantageous in terms of silicon area.

Therefore, as exemplified in <FIG>, a memory cipher engine <NUM> may switch between the first operation mode and the second operation mode by properly setting one or more multiplexers to implement a stream cipher topology or a block cipher topology. By way of example, in <FIG> the grey arrows are indicative of a stream cipher topology, and the black arrows are indicative of a block cipher topology.

In particular, the memory cipher engine <NUM> may comprise a first multiplexer <NUM>, which propagates either the AXI request as issued by the master device <NUM> (stream cipher topology) or the AXI request as formatted by the processing block <NUM> (block cipher topology) to the slave device <NUM> via the address channel 31b. The memory cipher engine <NUM> may further comprise a second multiplexer <NUM>, which propagates either the AXI request as issued by the master device <NUM> (stream cipher topology) or the data retrieved from the slave device <NUM> and stored in the buffer <NUM> (block cipher topology) to the AES engine <NUM>. The data output by the AES engine <NUM> may be stored in a first register (that is filled with keystreams produced by the AES engine <NUM>, not visible in <FIG>) or a second register (that is filled with plaintext data produced by the AES engine <NUM>, not visible in <FIG>) depending on the currently selected operation mode of the memory cipher engine <NUM>. Therefore, the memory cipher engine <NUM> may further comprise a demultiplexer <NUM>, which propagates the output data from the AES engine <NUM> either towards the first register (stream cipher topology) or towards the second register (block cipher topology). The first register may feed the XOR processing block <NUM>. The memory cipher engine <NUM> may further comprise a third multiplexer <NUM>, which propagates either the data output from the XOR processing block <NUM> (stream cipher topology) or the data decrypted by the AES engine <NUM> and stored in the second register (block cipher topology) to the master device <NUM> via the data channel 32b.

It is noted that dynamically switching between the first operation mode and the second operation mode may generate inconsistencies and/or protocol violations on the bus <NUM>, in particular when switching from the block cipher mode to the stream cipher mode. Such inconsistencies may be due to two factors:.

Certain solutions to the above-discussed issues may be considered. A first solution may be limiting the application to use a static selection between the stream cipher mode and the block cipher mode, but this is not a solution for dynamic traffic management. Another solution may rely on using two separate buses, but this would require an additional interconnect and an AES dedicated manager to distribute the cryptographic engine. Another solution may rely on the duplication of the cryptographic engine, with duplication of the silicon area. Another solution may rely on using the internal buffer <NUM> also during operation in the stream cipher mode. Another solution may rely on stalling the master device <NUM>, when switching from the block cipher mode to the stream cipher mode, in order to "clean" the read channel of residual block cipher data traffic. This last solution would impact on the performance, insofar as the slave device gates the access to the external memory.

Therefore, in order to improve the management of mixed data traffic on the bus <NUM> when switching the data bus from reading the buffer <NUM> to reading directly from the slave data channel 32a (i.e., when switching operation of the memory cipher engine <NUM> from a block cipher mode to a stream cipher mode), one or more embodiments may rely on stalling the data channel 32a of the slave device <NUM> until the master device <NUM> has completed a reading from the buffer <NUM>.

One or more embodiments may thus relate to a processing system <NUM> as exemplified in <FIG>, which is a block diagram exemplary of certain components of the processing system, in particular certain components of a memory cipher engine configured to manage mixed data traffic on the bus <NUM> when the memory cipher engine switches between a block cipher operation mode and a stream cipher operation mode.

It is noted that in <FIG> certain signals of the bus <NUM> are designated according to the AXI protocol as defined in the reference document by ARM® cited at the beginning of the present description.

Signal ARADDR[<NUM>:<NUM>] of the read address channel has the master device <NUM> as source and stands for "read address"; the read address gives the address of the first transfer in a read burst transaction. Signal ARVALID of the read address channel has the master device <NUM> as source and stands for "read address valid"; this signal indicates that the channel is signaling valid read address and control information. Signal ARREADY of the read address channel has the slave device <NUM> as source and stands for "read address ready"; this signal indicates that the slave is ready to accept an address and associated control signals.

Signal RVALIDS of the read data channel has the slave device <NUM> as source and stands for "read valid"; this signal, as issued by the slave device, indicates that the channel is signaling the required read data. Signal RVALID is the same as signal RVALIDS, as received by the master device <NUM>. Signal RDATAS of the read data channel has the slave device <NUM> as source and stands for "read data"; this signal, as issued by the slave device, carries the data retrieved from the slave device <NUM>. Signal RDATA is the same as signal RVALIDS, as received by the master device <NUM> (e.g., as provided at the output of the multiplexer circuit <NUM>). Signal RREADY of the read data channel has the master device <NUM> as source and stands for "read ready"; this signal, as issued by the master device, indicates that the master can accept the read data and response. Signal RREADYS is the same as signal RREADY, as received by the slave device <NUM> and possibly stalled by the memory cipher engine <NUM> as further discussed in the following.

In one or more embodiments, in order to inform (e.g., make aware) the read channel of the bus <NUM> about the type of management expected (e.g., depending on whether the MCE <NUM> is expected to operate in a stream cipher mode or in a block cipher mode), information about the expected ciphering mode (e.g., streaming (CTR) or block (ECB) ciphering) may be stored in a register <NUM>, particularly a FIFO register <NUM>, also referred to as "FIFO of outstandings" (i.e., outstanding bursts). As exemplified in <FIG>, information may be pushed (e.g., enqueued) in the FIFO register <NUM> as a function of a signal PUSH which corresponds to the request being granted (e.g., PUSH = ARVALID AND ARREADY). Thus, information coming from signal DIN1 = ECB, which is indicative of the block ciphering mode expected for the next burst, may be pushed in the FIFO register <NUM> upon the request granting on the address channel. Information stored in the FIFO register <NUM> may be popped (e.g., dequeued) from the FIFO register <NUM> via signal DOUT1 = ECB as a function of a signal POP1 which indicates that the last data beat was transferred to master (e.g., POP1 = RLAST and RVALID and RREADY). Signal DOUT1 may be used to control the multiplexer circuit <NUM> so that, depending on the value of signal DOUT1, the data transferred to the master device <NUM> via the signal RDATA is either the data coming from the XOR gate <NUM> (if the memory cipher engine operates in stream cipher mode) or the data coming from the AES engine <NUM> (if the memory cipher engine operates in block cipher mode).

However, storing information about the expected ciphering mode in the FIFO register <NUM> may not be sufficient in the case a block cipher (e.g., ECB) burst is followed by a stream cipher (e.g., CTR) burst.

Therefore, one or more embodiments as exemplified in <FIG> may rely on stalling the streaming (e.g., CTR) data coming from the slave device <NUM> dynamically until the block burst has been completed (e.g., completely received) by the master device <NUM>. For this purpose, in one or more embodiments the memory cipher engine may comprise a second register <NUM>, also referred to as "ECB2STR" register, particularly a FIFO register <NUM>. Information containing the stream cipher tag (e.g., CTR tag) of the next burst may be stored in the register <NUM>. As exemplified in <FIG>, information may be pushed (e.g., enqueued) in the FIFO register <NUM> as a function of the same signal PUSH that controls the first FIFO register <NUM>. Thus, information coming from signal DIN2 = CTR, which is indicative of the stream ciphering mode expected for the next burst, may be pushed in the FIFO register <NUM> upon the request granting on the address channel. Information stored in the FIFO register <NUM> may be popped (e.g., dequeued) from the FIFO register <NUM> via signal DOUT2 = CTR as a function of a signal POP2 that is generated upon the slave end of burst, i.e., the end of burst from the slave side (e.g., POP2 = RLASTS and RVALIDS and RREADYS). The memory cipher engine <NUM> may comprise an AND gate <NUM> that receives signals DOUT1 and DOUT2 as input signals and produces a respective output signal. The memory cipher engine <NUM> may comprise an AND gate <NUM> that receives as a first input an inverted replica of the signal produced by the AND gate <NUM>, and as a second input the RREADY signal from the master device <NUM>, to produce the RREADYS signal for the slave device <NUM>.

<FIG> is a time diagram exemplary of possible behavior of signals ACLK (e.g., a global clock signal of the interconnect bus <NUM>), RVALID, RREADY, RLAST, POP1 (indicated as "OUTSTANDING_FIFO_POP" in <FIG>), DOUT2 (indicated as "ECB2STR_INFO" in <FIG>), RVALIDS, RREADYS, RLASTS, POP2 (indicated as "ECB2STR_INFO_POP" in <FIG>) and ECB in one or more embodiments.

In <FIG>, a new block cipher burst (e.g., ECB burst) starts at instant M1. At instant M2, the block cipher burst has run out for the slave device but not for the master device, and information DOUT2 is popped (e.g., dequeued) from the FIFO register <NUM> to check the kind of encryption of the next burst. Since the kind of encryption of the next burst is a streaming encryption (e.g., CTR), the slave device <NUM> is stalled (RREADYS = <NUM>) until the master device <NUM> finishes processing the current block cipher burst. At instant M3, the master device <NUM> has received the last data of the block cipher burst; from this instant, signal RREADYS is no longer stalled (RREADYS == RREADY) and a stream cipher burst can be processed, driven by the slave device <NUM>.

It is noted that one or more embodiments may be applied in any case where the read channel has to switch from reading buffered information to reading a stream of data, so they may also be applied when switching to plaintext traffic (e.g., in case the slave device <NUM> stores information that is not encrypted, i.e., it stored directly the plaintext).

It is also noted that one or more embodiments may operate provided that the slave device <NUM> disables the "out of order" feature, i.e., a feature of the AXI bus that allows a master device to issue transactions without waiting for earlier transactions to complete, relying on the use of AXI ID transaction identifiers.

Therefore, one or more embodiments may relate to an on-the-fly decryption engine comprising a "dual" outstanding FIFO register (<NUM>, <NUM>) that is also updated upon the burst generated by the slave device to know the kind of encryption of the next burst before the master completes the current burst. One or more embodiments may rely on gating the AXI read channel for a time sufficient to let the master device <NUM> complete the buffered data transfers. In one or more embodiments, the AES engine <NUM> can be used to alternatively generate keystream or block ciphering; the output from the memory cipher engine may be delivered to the master device <NUM>, dynamically driven from the internal buffer or the slave device <NUM>, depending on the ciphering mode.

One or more embodiments may thus provide one or more of the following advantages:.

Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what has been described by way of example only, without departing from the extent of protection.

Claim 1:
A processing system (<NUM>), comprising:
a master device (<NUM>) and a slave device (<NUM>) coupled via an interconnection bus (<NUM>), wherein the master device (<NUM>) is configured to issue memory burst transaction requests via said interconnection bus (<NUM>) to fetch data from said slave device (<NUM>);
a cipher engine (<NUM>) coupled to the interconnection bus (<NUM>) and configured to decrypt said data fetched from said slave device (<NUM>) to produce plaintext data for the master device (<NUM>), wherein the cipher engine (<NUM>) selectively operates according to:
a stream cipher operation mode, wherein a stream of data is fetched from said slave device (<NUM>) and processed in a combinatorial circuit (<NUM>) to produce said plaintext data, or
a block cipher operation mode, wherein a block of data is fetched from said slave device (<NUM>), stored in a buffer memory (<NUM>) of the cipher engine (<NUM>), and processed in a cryptographic engine (<NUM>) to produce said plaintext data;
wherein the cipher engine (<NUM>) is configured to stall a read data channel (32a) of said interconnection bus (<NUM>) between said slave device (<NUM>) and said master device (<NUM>) in response to the cipher engine (<NUM>) switching from said block cipher operation mode to said stream cipher operation mode, and to reactivate said read data channel (32a) in response to a last beat of a read burst of said plaintext data produced by said cryptographic engine (<NUM>) and corresponding to said block of data stored in said buffer memory (<NUM>) being received by said master device (<NUM>).