Inline encryption/decryption for a memory controller

Various embodiments relate to a memory controller, including: a memory interface connected to a memory; an address and control logic connected to the memory interface and a command interface, wherein the address and control logic is configured to receive a memory read request; a read inline encryption engine (IEE) connected to the memory interface, wherein the read IEE is configured to decrypt encrypted data read from the memory; a key selector configured to determine a read memory region associated with the memory read request based upon a read address where the data to be read is stored, wherein the read address is received from the address and control logic; and a key logic configured to select a first key associated with the determined read memory region and provide the selected key to the read IEE.

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally to inline encryption and decryption for a memory controller, such as for example a double data rate (DDR) memory controller, and refreshing the keys used by inline encryption.

Inline encryption is the method of encrypting or decrypting data as external memory such as DDR is accessed. This allows for data to be securely stored in memory in order to prevent unauthorized access to the data. Such encryption and decryption may be accomplished in a manner that is transparent to the user or system accessing the memory.

SUMMARY

Various embodiments relate to a memory controller, including: a memory interface connected to a memory; an address and control logic connected to the memory interface and a command interface, wherein the address and control logic is configured to receive a memory read request; a read inline encryption engine (IEE) connected to the memory interface, wherein the read IEE is configured to decrypt encrypted data read from the memory; a key selector configured to determine a read memory region associated with the memory read request based upon a read address where the data to be read is stored, wherein the read address is received from the address and control logic; and a key logic configured to select a first key associated with the determined read memory region and provide the selected key to the read IEE.

Various embodiments are described, wherein the read IEE further includes: an encryption engine configured to encrypt a counter based on the read address and a nonce; a first in first out buffer (FIFO) configured to receive ciphertext data read from the memory; an XOR gate configured to XOR the ciphertext from the FIFO with the encrypted counter to produce plaintext.

Various embodiments are described, further including a valid FIFO configured to receive and output valid flags indicating when the associated plaintext is valid.

Various embodiments are described, further including a bypass gate configured to receive the encrypted counter and a bypass signal, and output 0s when decryption is to be bypassed.

Various embodiments are described, wherein the memory has a plurality of different memory regions, and the read IEE includes a plurality of different encryption engines implementing different encryption modes of operation, wherein one or more of the plurality of memory regions is associated with one of the plurality of different encryption engines.

Various embodiments are described, further including a write IEE connected to the memory interface, wherein the write IEE is configured to encrypt data to be stored in the memory.

Various embodiments are described, wherein the key selector is configured to determine a write memory region associated with a memory write request based upon a write address where the data to be stored, wherein the write address is received from the address and control logic; and

the key logic is configured to select the first key associated with the determined write memory region and provide the selected first key to the write IEE.

Various embodiments are described, wherein the key logic is configured to select a second key associated with the determined write memory region and provide the selected second key to the write IEE, the write IEE further includes: a first encryption engine configured to encrypt a first data sequence number, based on the write address data and nonce, using the second key; a first tweak circuit configured to produce a first tweak based upon the encrypted first data sequence number; a first first-in-first-out buffer (FIFO) configured to receive the encrypted data sequence number; a second FIFO configured to receive plaintext data to be written into the memory; a first XOR gate configured to XOR the plaintext from the second FIFO with the first tweak; a second encryption engine configured to encrypt the output of the first XOR using a first key; a second tweak circuit configured to produce the first tweak based upon the output of the first FIFO; and a second XOR gate configured to XOR the output of the second encryption engine with the first tweak to produce a ciphertext to be written in the memory.

Various embodiments are described, further including a first valid FIFO configured to receive and output valid flags indicating when the ciphertext is valid.

Various embodiments are described, wherein the key logic is configured to select a second key associated with the determined read memory region and provide the selected second key to the read IEE, the read IEE further includes: a third encryption engine configured to encrypt a second data sequence number, based on the read address data and nonce, using the second key; a third tweak circuit configured to produce a second tweak based upon the encrypted second data sequence number; a third FIFO configured to receive the encrypted second data sequence number; a fourth FIFO configured to receive ciphertext data to be read from the memory; a third XOR gate configured to XOR the ciphertext from the fourth FIFO with the second tweak; a decryption engine configured to decrypt the output of the third XOR using a first derived key based upon the first key wherein the first derived key may be the same as the first key; a fourth tweak circuit configured to produce the second tweak based upon the output of the third FIFO; and a fourth XOR gate configured to XOR the output of the decryption engine with the second tweak to produce a plaintext.

Various embodiments are described, further including a second valid FIFO configured to receive and output valid flags indicating when the plaintext is valid.

Various embodiments are described, further including a memory scrubber configured to cycle through memory locations and at each memory location utilizing the read IEE and the write IEE to: decrypt the stored data using the first key; encrypt the decrypted stored data using a new first key; store the data encrypted with the new first key; and update a key update location, wherein the key update location indicates a boundary between data stored in the memory encrypted using the first key and the new first key.

Various embodiments are described, further including a memory scrubber configured to:

cycle through memory locations of the memory at a first rate and at each memory location utilizing the read IEE and write IEE to: decrypt the stored data using the first key; encrypt the decrypted stored data using a new first key; store the data encrypted with the new first key; update a key update location, wherein the key update location indicates a boundary between data stored in the memory encrypted using the first key and the new first key; and scan through the memory at a second rate to correct data errors using an error correction code, wherein the first and second rates are different.

Further various embodiments relate to a memory controller, including: a memory interface connected to a memory; an address and control logic connected to the memory interface and a command interface, wherein the address and control logic is configured to receive a memory access request and a write memory request; a read inline encryption engine (IEE) connected to the memory interface, wherein the read IEE is configured to decrypt encrypted data read from the memory; a write IEE connected to the memory interface, wherein the write IEE is configured to encrypt data to be stored in the memory; a key selector configured to: determine a read memory region associated with the memory read request based upon a read address where the data to be read is stored, wherein the read address is received from the address and control logic; and determine a write memory region associated with the memory write request based upon a write address where the data is to be stored, wherein the write address is received from the address and control logic; a key logic configured to select a first old key or a first new key associated with the determined read or write memory region based upon a key update location, wherein the key update location indicates a boundary between data stored in the memory encrypted using the first key and the new first key; and provide the selected key to the read or write IEE.

Various embodiments are described, further including a memory scrubber configured to cycle through memory locations and at each memory location utilizing the read IEE and the write IEE to: decrypt the stored data using the first key; encrypt the decrypted stored data using a new first key; store the data encrypted with the new first key; and update the key update location.

Various embodiments are described, further including a memory scrubber configured to: cycle through memory locations of the memory at a first rate; and at each memory location utilizing the read IEE and the write IEE to: decrypt the stored data using the first key; encrypt the decrypted stored data using a new first key; store the data encrypted with the new first key; update the key update location; and scan through the memory at a second rate to correct data errors using an error correction code, wherein the first and second rates are different.

DETAILED DESCRIPTION

In a computing system with external memory, the path between processor and memory may be snooped by an attacker. It is desirable to encrypt the data stored in the external memory. Encrypting data can be a time-consuming process. What is needed is a way of encrypting/decrypting the data stored in external memory that can be performed at the same rate as reading/writing the external memory. Such encryption should be independent of the data being encrypted, or of the user of that data (i e, the encryption should be done transparently) so that it can be easily enabled. Further, as the system may be active for a long period of time it is desirable to periodically replace current encryption keys with new keys without the necessity of bringing the system to a halt during this process. Periodically updating the encryption keys can make it more difficult for an attacker to extract a key as well as reduce the amount of data that can be decrypted by that key.

Embodiments of an inline encryption engine (IEE) and methods are disclosed that allow for fast inline encryption and decryption of data stored in memory. The system memory may be divided into multiple regions, each protected with its own key. This allows for different processes to be in different regions with their own keys. As security becomes more critical to more products, it becomes desirable to encrypt all external memory. However, DDR is a high-speed memory system and requires low latency. Accordingly, the IEE disclosed herein is fully pipelined and integrated into the memory controller data path in order to provide transparent encryption and decryption of data stored in the memory. The IEE also includes the capability of having its keys periodically updated while the memory system remains active providing continuous service without stalling. While a memory controller is described in the context of DDR, the memory controller embodiments described herein may be applied other types of memory.

In a basic IEE, the same region-specific keys may be used from power on/initialization until the next reset. In long running systems, the same keys could be used for months or even years, providing an attacker ample opportunity to perform cryptoanalysis or side channel attacks. Accordingly, it is beneficial to perform periodic key updates. Current IEEs perform key updates as part of a bulk update process that blocks access to pages while the data is decrypted with the old key and re-encrypted with the new key. One aspect of the embodiments described herein is the ability to enable two keys, an old region key and a new region key, and allow data to be decrypted and re-encrypted without blocking access to the data. This process of re-encrypting the data from the old key to the new key takes place in the background while other data processing may occur.

The embodiments of an IEE are described herein that use a hardware memory scrubber that can also be used for error correction code (ECC) memory integrity protection to refresh the old region key to a new region key without memory pages being made temporarily unavailable. A DDR controller typically includes memory scrubber hardware that scans the address space of the memory so that an ECC refresh may be performed in the background. ECC will be applied to the plaintext data if encryption is not used, or to the ciphertext data if memory encryption is enabled. In either case, the ECC is applied to the data actually stored in the memory. The IEE may reuse this scanning hardware in the DDR controller to set and track a “water level” or key update location where memory content at addresses “below” the water level has already been encrypted with the new key while memory content at addresses “above” the water level is still encrypted with the old key. ECC memory scrubbing moves the water level indicator after reading data from the memory. When key refresh is required for the address accessed by the ECC scrubber, the data will be decrypted using the old key, re-encrypted with the new key, and the newly encrypted data stored back in the memory. Memory scrubbing is a low bandwidth background process, so that the key refresh occurs, but imperceptibly to the users of system memory and without affecting the performance of the memory. Also, the memory may continue to be used during the scrubbing process.

FIG.1illustrates a block diagram of a computing system with an IEE in a memory controller. The computing system100includes a core105, network on a chip (NOC) bus interconnect110, cache115, a memory controller120with an IEE125, and a memory130. The core is any processor core that may be part of a computing system. The core is connected to the NOC110. The NOC provides an interconnect that allows various cores to access various memories and peripheral devices not shown. The NOC110is connected to a cache115that is used as short-term memory for use by the core105. The cache115is connected to the memory controller120. While memory accesses from the core may be any size, the cache will always make memory accesses of a size that is a multiple of the encryption data block size. The cache acts as a buffer to prevent data size accesses which are mismatched to the encryption algorithm. Without this buffer, writing mismatched data to memory may require reading a block of data, decrypting it, splicing the new data into the decrypted data, re-encrypting it and finally writing the data to memory. Having the cache allows the memory controller not to need this extra logic. The memory controller120controls access to the memory130. The memory controller120includes the IEE125. Various other cores, memory and peripherals may also be connected to the NOC110but are not shown. In another embodiment, there is no cache and the memory controller120is connected directly to the NOC110. It will be appreciated by those skilled in the art that there are many different ways for the memory controller and IEE to be connected in a system.

FIG.2illustrates a block diagram of a memory controller including inline encryption. The memory controller200includes a write IEE210, read IEE212, key logic214, key selector215including a read region key selector216and a write region selector218, buffer220, DDR PHY222, DRAM interface224, address/command logic232, write data transmit logic234, and memory scrubber230. The block diagram of the memory controller200is a simplification of the memory controller so that the key features of the embodiment may be described. The memory controller200may include various other elements and features that are typically found in memory controllers.

The memory controller200may be connected to the cache, processor cores (or other system elements) via a write data channel242, a read data channel244, and an address channel240. The address channel240may support simultaneous use of both the write data channel242and the read data channel244. The write data channel242, read data channel244, and address channel240may be implemented by one or more suitable communication buses, such as an Advanced eXtensible Interface (AXI), an Advanced High-performance bus (AHB), or other suitable bus (es), or a combination thereof. As used herein, the term “bus” is used to refer to a plurality of signals or conductors which may be used to transfer one or more various types of information, such as data, addresses, control, or status. The conductors as discussed herein may be illustrated or described in reference to being a single conductor, a plurality of conductors, unidirectional conductors, or bidirectional conductors. However, different embodiments may vary the implementation of the conductors. For example, separate unidirectional conductors may be used rather than bidirectional conductors and vice versa. Also, a plurality of conductors may be replaced with a single conductor that transfers multiple signals serially or in a time multiplexed manner. Likewise, single conductors carrying multiple signals may be separated out into various different conductors carrying subsets of these signals. Therefore, many options exist for transferring signals.

The memory controller200may receive address and other command information on an address channel240. The data to be written to the DRAM is received on the write data channel242. The data to be read from the DRAM is output on the read data channel244.

The memory controller200may be connected to the DDR memory using one or more suitable communications buses, such as the DDR PHY222which implements the DRAM Interface224. The DRAM interface224may use any available memory interface protocol. Accordingly, the memory controller200has a DFI DRAM command interface that is part of the DRAM interface224where commands are sent to the DRAM and status and other information is received back from the DRAM. DRAM interface224also has a DFI write data channel interface where data to be written to the DRAM is output. The DRAM interface224has a DFI read data channel interface where data read from the DRAM is received.

The address/command logic232acts as a controller for the memory controller200. The address/command logic232receives address and command information from the address channel240. For example, when data is to be written, a write command and the address to write to is received by the address/command logic232from the core via the address channel240. The data to be written is received on the write data channel242and the write data transmit logic coordinates with the address/command logic232to provide the data to be written to the write IEE210. The write IEE210encrypts (when requested) the data to be written to the DRAM. The write IEE210then provides the encrypted data to be written to the DDR PHY222which then writes the data in the DRAM.

When data is to be read, a read command and the address of the data in the DRAM is received by the address/command logic232from the core via the address channel240. The address/command logic232sends a read command and the address to the DDR PHY222which then reads the data from the DRAM. The DDR PHY222transmits the data read from the DRAM to the read IEE212. The read IEE212decrypts (when the data is encrypted) the data read from the DRAM and then outputs the decrypted data on the read data channel244. Because they are pipelined, the write IEE210and read IEE212may accept a block of data and key every clock cycle. This allows the IEEs to operate at the full memory speed. The latency of the write IEE210and read IEE212will depend on the encryption algorithm used and may vary from one to a few tens of clock cycles.

Different encryption keys may be used for different address regions of the memory. This helps to make data stored in the DRAM more secure. Further, using different keys for different regions of the memory allow for different applications or users to have different keys to further secure the data in the DRAM from unauthorized access or manipulation. Accordingly, the write IEE210and read IEE212need to know which key to use when encrypting and decrypting data written to or read from the DRAM. The key logic214provides the correct keys to the write IEE210and read IEE212. The key logic214includes registers for storing the different keys for the various regions of the DRAM, i.e., the memory is divided into regions where each region has a key associated with it. The key logic214may be configured and receives key values via a register interface226. Such keys will be installed when the system restarts. Also keys may be updated as will be further described below. In order to determine the key to be used by the write IEE210and read IEE212at any given time, a buffer220receives address information from the address/command logic. A key selector215reads address information from the buffer220. If the address is for a read command, then the read region/key selection logic216determines the memory region associated with the read address, and provides this region information to the key logic214that then provides the key for indicated region to the read IEE212. Likewise, if the address is for a write command, then the write region/key selection logic218determines the memory region associated with the write address, and provides this region information to the key logic214that then provides the key for indicated region to the write IEE210. During normal operation there may be both memory write requests and memory read requests. Both the read region/key selection logic216and write region/key selection logic218may select different regions/keys simultaneously. While the key selector215is shown as separate from the key logic214, the key selector215, key logic214, and/or the buffer220may be integrated together. In another embodiment, the key logic214may be integrated into the write IEE210and read IEE212.

The memory controller200includes a memory scrubber230that scrubs the DRAM. Memory scrubbing includes reading from each memory location, correcting bit errors (if any) with an error-correcting code (ECC), and writing the corrected data back to the same location. Memory scrubbing of memory is done to correct for errors that may occur in memory due to, for example, radiation. Memory scrubbing is performed as a background task that is it carried out when there is idle time or as a low priority task. The memory scrubber230may simply cycle through the memory in a sequential order. When a memory location is to be refreshed, the memory scrubber230sends a refresh request to the address/command logic232. The address/command logic sends a read request to the DRAM for the location to be scrubbed. Then the data read from the DRAM is checked, and if an error is found the data corrected. The corrected data and ECC is then written back to the DRAM. The memory scrubber230cycles through the memory refreshing the whole memory periodically. The rate at which the memory is refreshed is based upon the size of the memory and the availability of time to perform the refresh operation. The time to completely scrub the memory may be on the order of hours, but other rates are possible as well. In another embodiment, this same scheme may be used to search for ECC errors without correcting them. In that embodiment, errors would only be detected and reported. In addition, for the key refresh, this memory scrubber may be used in cases where ECC is not enabled. ECC enablement is not a prerequisite to run the memory scrubber for this key refresh process.

The scanning function of the memory scrubber230may be used in order to drive the update the keys for each region of the memory.FIG.3illustrates memory regions and their associated keys. The memory300includes region1310, region2320, and region3330. The memory may include any number of regions based upon the specific application. Each region may have an old key and a new key. The old keys are key1a312, key2a,322, and key3a332. The new keys are key1b314, key2b324, and key3b334. When a key update is to occur, a new key is generated for each memory region. Keys for all regions may be updated together or individually. A water level or key update location340indicates a boundary between data that is encrypted with the new key and the old key. The memory scrubber230moves the location of the key update location340as data in the memory is encrypted with the new key. If a key refresh has been indicated, then the data in the location is decrypted using the old key and then re-encrypted using the new key. Then the key update location340is moved. This process repeats itself as the memory scrubber230scans through the memory checking for and correcting errors. Once, the whole memory has been scanned, the old key values are replaced by the new key values, and the key update location340is reset to the beginning of the memory. At this time, the old key and the new key may have the same value until a next key update occurs. In this situation the check for a key update may be skipped, because the old and the new key are the same, so the data if re-encrypted does not change. This may be done to simplify the logic for key selection.

During read and write operations of the memory300, the key selector215determines whether the old key or the new key should be used for decryption/encryption of the data. First the key selector215determines the region associated with the address of the data. This may be accomplished, for example, using a lookup table that has the upper and lower addresses for each region. Next, the key selector215decides whether the address to be accessed is “above” or “below” the key update location340. This may be as simple as determining that the value of the address to be accessed is greater than or less than the key update location340. InFIG.3, if the key update location340moves downward, then memory locations above the key update location340have been re-encrypted with a new region key and hence the new key should be sent to the write IEE210or the read IEE212. Otherwise the old key is sent to the write IEE210or the read IEE212. The key logic214may receive the region indication and whether the old or new key is to be used, and then send the correct key to the write IEE210or the read IEE212.

While a region is being scrubbed, and data is being re-encrypted using the new key, other normal memory requests may also occur. A memory access that is to a memory location below the key update location340will be encrypted using the old key312, while a memory access to a location at or above the key update location340will be encrypted using the new key314. Thus, key refresh may occur while the memory continues to be actively used.

For the above description, it is assumed that a key refresh starts at the beginning of a memory scrubbing scan. As a result, when a key refresh is received, the new keys should be updated when the memory scrub begins at the beginning of the memory. This could delay the update of the key refresh. If a quicker key refresh is needed, a key refresh start location is noted at the location where the key refresh begins. Then when the address comparison is made to the key update location, the following comparison is made (ADD−KEYSTART) mod N>(UPLOC−KFYSTART) mod N, where ADD is the memory address being accessed, KFYSTART is the key refresh start location, N is the address space size, UPLOC is the key update location340. Then the key selection logic215signals the key logic214to update the old keys when the key update location340returns to the key refresh start location.

Another approach for managing access to the memory while the keys are being updated may include a refresh flag for each region that indicates whether the region is undergoing a key refresh. If the region is not currently undergoing a key refresh, then the old key is used to read or write the data. If the region is undergoing a key refresh, then the key to use in accessing the data in the memory will be decided based upon the memory location relative to the water line. That is, if the memory location has been refreshed, then the new key is used. If the memory location has not been refreshed, then the old key is used. When the memory scrubber starts on a region, the refresh flag for that region is set to indicate that the region is being refreshed. Once the whole region has been refreshed, the refresh flag is reset to indicate that the region is not being refreshed and the new key replaces the old key.

The key refresh process is described above as occurring in conjunction with the memory scrubbing function. If there is a need for the key refresh to occur at a different rate, the key refresh process may use logic in the memory scrubber to scan the memory independent of the memory scrubbing to perform the ECC bit error corrections.

Because the key refresh is done in the background, the key refresh is accomplished with minimal performance impact on the memory and the memory remains available for use during the key refresh.

The read IEE212and write IEE210may be implemented in various ways using different encryptions schemes.FIG.4illustrates an embodiment of a read IEE for use with a read only memory. The read IEE412uses a lightweight PRINCE encryption engine in Counter mode to decrypt encrypted data read from the memory. Other encryption algorithms may also be used such as AES. A lightweight encryption algorithm is useful in an application such an inline encryption as it can be performed with a lower latency than AES and using less logic. Counter mode should only be used with Read-only applications, such as encrypted Flash or other pre-encrypted code image, as a key and single counter value should not be used to encrypt more than one block of data. Counter mode is described in NIST document SP800-38a, and although it is described using the AES encryption algorithm it can be used with other algorithms such as PRINCE. The decryption is done using an XOR432that XORs a ciphertext452with an encryption of a counter value. In this example, the data address454is a 32-bit address and the ciphertext is 128 bits. The PRINCE encryption algorithm has a 64-bit block size, and so two PRINCE encryption engines are used in parallel. A nonce438is concatenated with the address454by a concatenator428to form a counter value which is input into a first instance of the PRINCE encryption engine424. The nonce438is also concatenated with the address454plus 1 by the concatenator428and input into a second instance of the PRINCE encryption engine426. The output of the PRINCE encryption engines424,426are concatenated and input into an AND gate430. The AND gate430receives a bypass signal434that is inverted at the input to the AND gate430. If the bypass signal is 1 (or a string of 1s) it indicates the ciphertext452read from the memory is not to be decrypted. This may mean that the ciphertext452is actually not encrypted data, or the encrypted data is to be output from the read IEE412. The bypass signal434is inverted to 0 (or a string of 0s) and when ANDed with the concatenated output of the PRINCE encryption engines424,426, results in a string of 128 0s. When this string of 128 0s is XORed with the ciphertext452the output of the XOR432is the ciphertext. This allows for a region to be identified as containing plaintext that does not need to be decrypted.

When the bypass signal is 0, then a 1 is ANDed with the output of the PRINCE encryption engines424,426so that the output is not changed. The output of the AND430is then XORed with the ciphertext to decrypt the ciphertext resulting in plaintext462.

Because the PRINCE encryption algorithm has multiple steps or stages to encrypt input data, a data first-in-first-out buffer (FIFO)422may be used to pipeline the ciphertext452while the associated counter is moving through the stages of the PRINCE encryption engines424,426. This pipelined architecture allows data and key to be input into the read IEE412every clock cycle, and the read IEE412is able to keep up with the data flow through the memory controller200in real-time.

Further, an address and region valid FIFO420receives a valid flag450associated with each read access of the memory. As the pipelined structure is in continuous operation even when new data is not input, read IEE412outputs an address and region valid flag460that tells the core reading the plaintext output 462 that the output is valid.

Key logic414provides an encryption key436, bypass flag434, and the nonce438to the read IEE412. The key logic also receives a region input440that indicates the region in which the data to be read is stored. The key logic414also receives keys, nonces, etc. from interface442and stored in the key logic414. Further, in this example, the memory may have 8 regions and thus there will be 8 keys. Further, 8 nonces are stored one for each of the regions. In the read-only mode (i e, encrypted flash), there is no key-refresh. A new key will be used only when the encrypted flash image is updated. The key will be selected by the person encrypting the image (external to IEE).

In the example above, a PRINCE encryption engine is used. In other embodiments, other encryption algorithms such as AES may be used as well depending upon the specific requirements of the application. Further, a ciphertext width of 128-bits is shown. Other ciphertext widths may be used, and as a result, the number of instances of the PRINCE encryption engine will be varied accordingly. Further, the number of permutations of the counter may be varied. For example, for a 256-bit ciphertext width, 4 PRINCE encryption engines may be used, and 4 variations of the counter +0, +1, +2, and +3 may be used. Further, if the address width is different, the size of the nonce may change accordingly.

FIG.5illustrates an embodiment of a write IEE and read IEE using AES in XTS mode. XTS is specified in NIST document SP800-38e and is intended for use in data storage applications. Although it is specified as using AES, it may also be used with other encryption algorithms. XTS mode encrypts a data sequence number to generate a tweak value. In an embodiment, a nonce may be concatenated with the memory address and used as the data sequence number. The write IEE510and the read IEE512have a mirrored structure. For ease of description the same number is used to label the same item in both the write IEE510and the read IEE512. The read IEE512will first be described. In an embodiment, the ciphertext552may be 256-bits wide while an AES data block size is 128 bits. Thus, two AES engines546,548may be used in parallel to match the ciphertext size. The read IEE512uses an AES decryption engine546to decrypt encrypted data read from the memory. Further, an AES encryption engine542is used to encrypt the data sequence number, and this encrypted data sequence number is used to generate tweaks that are XORed with the input ciphertext552and the output of the AES engine546.

The read IEE512receives a ciphertext input552that is input into a first FIFO522. This first FIFO522helps to keep the input ciphertext data in order and synchronized with the output of the data sequence number AES encryption engine542. The first FIFO522also receives a first derived key Key1dec that is derived from a first key Key1being the final generated AES round key. Keyldec moves through the first FIFO522along with its associated ciphertext. In other embodiments, Key1and Keyldec may be the same value.

A nonce is concatenated with an input address associated with the ciphertext being read and input into the AES encrypt engine542. The AES encrypt engine542also receives a second key Key2. The AES engine542encrypts data sequence number comprised of the received nonce and address using Key2. The output of the AES encrypt engine542is input into a second FIFO544that pipelines the encrypted data sequence number so that it may be used at both the input and the output of the AES decryption engine546. The encrypted data sequence number is also input into a MULx function554(a data rotation and conditional XOR as defined by the XTS standard) to generate two tweaks T1and T2. These tweak values are each XORed with half of the ciphertext from the first FIFO522using XORs540. Each of the outputs of the XORs540is input into a separate instance of the AES decryption algorithm in the AES decryption engine546. The output of the second FIFO544is also input into the MULx function556two produce the same tweaks T1and T2generated by the MULx function554, and tweaks T1and T2are also XORed with the outputs of the AES decryption engine546by XORs558. The outputs of the XORs558are concatenated together to produce the plaintext562.

A second FIFO520receives a valid flag as part of the address and valid flag input550. The second FIFO520pipelines the address valid flags so that they are synchronized with the plaintext output 562. The address valid flag indicates when data received at the plaintext output is valid.

The write IEE510has almost the same structure and operation as the write IEE512, but with a few differences. The write IEE510receives plaintext512and address and address valid flags570as input. The plaintext512after moving through first FIFO522is encrypted by AES encryption engine548using Key1. Otherwise, the operation of the write IEE510proceeds in the same manner as for the read IEE512.

Key logic514provides encryption keys Key1, Key2and the nonce to the write IEE510. Key logic514provides decryption keys Keyldec, Key2and the nonce to the read IEE512. The key logic also receives inputs indicating the write region and new/old write key580and read region and new/old read key582. The region input indicates the region in which the data is to be read or stored. The old/new key input is an indication of whether the old key or the new key is to be provided to the AES encryption/decryption engine548,546by the key logic514. Further, in this example, the memory may have 8 regions. This means that there will be 48 256-bit keys stored including 6 keys for each region. The 6 keys for each region include old and new first keys Key1and Key1dec and old and new second keys Key2. Further, 8 nonces are stored, one for each of the regions.

In the example above, an AES encryption/decryption engine is used. In other embodiments, other encryption engines may be used depending upon the specific requirements of the application. Further, a ciphertext width of 256-bits is shown. Other ciphertext widths may be used, and as a result the number of instances of the AES encryption/decryption instances will be varied accordingly. Further, the number of tweaks generated by the MULx functions may be increased or decreased. For example, if the data bus is 128-bits, then only one AES engine is needed along with a single tweak value. In another example, for a 512-bit ciphertext width, 4 AES encryption/decryption instances may be used, and 4 tweaks T1, T2, T3, T4generated by the MULx function may be used.

A read or write IEE may use more than one type of encryption/decryption algorithm to read and write to a memory.FIG.6illustrates a read IEE that includes an AES pipeline, a PRINCE pipeline and a bypass pipeline (for stored plaintext data). These pipelines may have different latencies. The read IEE600receives ciphertext632, an associated address634, and a valid flag630. This data is combined622,624,626with key data from the key logic614and input into selection gates616,618,620. The selection gates616,618,620also receive inputs650from the key logic614indicating which of the processing pipelines are to be used on the ciphertext632. Only one of inputs650is asserted at a time so that only one of the pipelines is used. If the data is not encrypted, then the bypass FIFO610may be used to simply pass the data from the memory to the output along with the associated address and valid flag640. If the data is encrypted, then the key logic indicates which of the decryption pipelines to use: in this example AES and PRINCE are the options. The selected pipeline610,612,616is activated by asserting the valid input only to that decryption pipeline612,616or bypass FIFO610and the plaintext data will be output along with the associated address and valid flag640/642/644. The key logic will determine which pipeline to use on the ciphertext based upon the region input660, as each region will be encrypted using a specific known encryption algorithm and mode of operation (such as Counter mode or XTS).

The key logic614operates as described above with the addition of outputting a data value indicating which of the processing pipelines is to be used on the data read from the memory. As in the prior examples, the memory may be divided into 8 regions, but more or fewer regions may be used as well. Old and new keys are stored for each region. Further, a key size is set to accommodate any size key that is required. Also, the key logic614stores 8 counter/nonce values to be used as needed by the different decryption pipelines. The size of these counter/nonce values can by any size needed by the decryption pipelines. The architecture of the read IEE612using multiple decryption pipelines may also be applied to the write IEE so that it may accommodate different encryption pipelines. This architecture allows the memory controller to allow a memory to use multiple different types of encryption/decryption in the different regions. Further, while the different pipelines are shown as using different encryption/decryption algorithms, multiple pipelines using the same encryption/decryption algorithm may be used with each accommodating a different mode of operation or a different key size. For example, AES may use 128-bit, 192-bit, or 256-bit keys, so different AES encryption/decryption pipelines may be implemented using different key sizes. Alternatively, a single AES pipeline may also be able to accommodate different key sizes.

The read IEE and write IEE may include a clear keys input that sets all keys to zero, or other initialization value, when it has been determined that tampering has occurred. This results in outputs that appear random to an attacker and protects the encrypted data from being exposed to the attacker.