Memory-Based Encryption

Abstract

Embodiments herein describe a memory controller having an encrypted path and a bypass path. Using an indicator (e.g., a dedicated address range), an external entity can inform the memory controller whether to use the encrypted path or the bypass path. For example, using the encrypted path when performing a write request means that the memory controller encrypts the data before it is stored, while using the bypass path means that the data is written to memory unencrypted. Similarly, using the encrypted path when performing a read request means that the controller decrypts the data before delivering it to the requesting entity, while using the bypass path means that the data is delivered undecrypted.

Description

[Technical Field]

[0001] The present invention relates to memory-based encryption. [Background technology]

[0002] Encryption is a common method for data protection and software security, but software-based encryption is slow and requires an encryption key known to the software. Making the key accessible to software means that the key is easily obtainable by malicious actors. While hardware encryption can be performed instead (when the encryption key is not available to the software), hardware-accelerated encryption requires expensive system calls to execute.

[0003] Modern processors have built-in encryption engines for encrypting data stored in short-term memory (e.g., random access memory (RAM)). These processors have one user-configurable setting: either all data stored in memory is encrypted or none of the data stored in memory is encrypted. If the processor is configured to encrypt all data, each time data moves from short-term memory to long-term storage (e.g., a hard disk drive or solid-state drive), the processor first decrypts the data before storing it. Thus, data is only encrypted while residing in short-term memory. To encrypt data for long-term storage, a software application must generate a separate request. Therefore, the benefits of hardware encryption are limited. Summary of the Invention

[0004] According to one aspect of the present invention, a processor includes a core and a memory controller configured to receive a first write request to write data to a memory, the memory controller being configured to identify a physical address in the first write request, the physical address indicating a location in the memory where the data should be stored, and to generate a first encryption key for encrypting the data based on the physical address.

[0005] Another aspect described herein is a method that includes receiving a first write request to write data to a memory; identifying a physical address in the first write request, the physical address indicating a location in the memory where the data is to be stored; and generating a first encryption key for encrypting the data based on the physical address.

[0006] Another aspect described herein is a memory controller in an integrated circuit. The memory controller includes hardware logic configured to identify a physical address in a first write request received at the memory controller and to generate a first encryption key for encrypting the data based on the physical address, the physical address indicating a location in memory where the data corresponding to the first write request should be stored. The memory controller also includes an encryption engine configured to encrypt the data using the first encryption key. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram of a computing system for performing selective hardware encryption, according to one embodiment described herein. [Figure 2] 1 is a flowchart for performing a write request using an encrypted path or a bypass path according to one embodiment described herein. [Figure 3] 1 is a flowchart for performing a read request using an encrypted path or a bypass path according to one embodiment described herein. [Figure 4] 1 is a flowchart for decrypting previously encrypted data by a processor according to one embodiment described herein. [Figure 5A] FIG. 10 illustrates performing a write request to encrypt data when mirroring is enabled, according to one embodiment described herein. [Figure 5B] FIG. 10 illustrates performing a read request to retrieve encrypted data using a bypass path when mirroring is enabled, according to one embodiment described herein. [Figure 6A] FIG. 10 illustrates performing a write request to store encrypted data using a bypass path when mirroring is enabled, according to one embodiment described herein. [Figure 6B] FIG. 10 illustrates performing a read request to decrypt encrypted data using an encryption path when mirroring is enabled, according to one embodiment described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] Embodiments herein describe performing hardware encryption in a processor using an encryption key that is based on the address at which data is stored in memory. For example, the encryption key can include two parts: one part that is a unique ID provided by manufacture that is not accessible to any entity outside the processor, and a second part that is derived from the physical address at which the data is stored. The processor can generate the encryption key using these two parts. Thus, data stored in different locations has a different encryption key. By having a dynamic part of the encryption key that is based on the address of the data, rather than using a static key (e.g., where the entire key is assigned by manufacture), the encryption key becomes nearly impossible to crack using a brute force attack.

[0009] Furthermore, rather than a processor being configured to always encrypt / decrypt data stored in memory or never encrypt / decrypt data, in one embodiment, the memory controller within the processor has an encryption path and a bypass path. Using an indicator (e.g., a dedicated address range), an external entity (e.g., a hypervisor or software application) can inform the memory controller whether to use the encryption path or the bypass path. For example, using the encryption path when performing a write request means that the memory controller will encrypt the data before it is stored, while using the bypass path means that the data will be written to memory unencrypted. Similarly, using the encryption path when performing a read request means that the controller will decrypt the data before delivering it to the requesting entity, while using the bypass path means that the data will be delivered undecrypted. In this way, a software application can instruct the processor to use the encryption path when performing a write operation so that the data is first encrypted before being stored, and can instruct the processor to use the encryption path when performing a read operation so that currently encrypted data can be retrieved without decryption (and stored in long-term storage encrypted).

[0010] Later, the software application may need to decrypt the encrypted data. The software application can use another write request to instruct the processor to store the encrypted data in RAM using a bypass path (so that already encrypted data is not re-encrypted). It can then use a read request to instruct the process to retrieve the encrypted data from RAM using the encryption path so that the data is decrypted before being returned to the software application. In this way, only hardware encryption is used, and the software application can encrypt and decrypt data without knowing the encryption key.

[0011] 1 is a block diagram of a computing system 100 for performing selective hardware encryption according to one embodiment described herein. Computing system 100 includes a processor 105, a hypervisor 135, a memory 150, and storage 180 communicatively coupled using a bus 190. Processor 105 includes one or more cores 110 and a memory controller 115 that serves as an interface between cores 110 and memory 150 (e.g., short-term or volatile memory such as RAM). Although not shown, cores 110 may include one or more caches.

[0012] Memory controller 115 includes an encryption path 120 for encrypting and decrypting data to be stored in or retrieved from memory 150, and a bypass path 130 for storing or retrieving data from memory 150 without encryption or decryption. For example, as described in further detail below, processor 105 may receive a write request from hypervisor 135 that includes an encryption address 140 that serves as an indicator to memory controller 115 that encryption path 120 should be used when writing data to memory 150 (i.e., the data should be encrypted). Conversely, if the write request instead includes bypass address 145, it instructs memory controller 115 that bypass path 130 should be used, i.e., the data should be stored in memory 150 without encryption. Hypervisor 135 may also use encryption address 140 and bypass address 145 when sending a read request to instruct memory controller 115 to decrypt data using encryption path 120 or to use bypass path 130 instead. Although in FIG. 1 memory controller 115 is shown within the same integrated circuit that forms processor 105, memory controller 115 may also be part of a separate integrated circuit.

[0013] The encryption path 120 includes an encryption engine 125 that performs encryption and decryption. That is, the encryption engine 125 encrypts data when a write request is made using the encryption path 120 and can also decrypt data when a read request is made using the encryption path 120. However, alternative embodiments may have a dedicated encryption path for encrypting data being stored in the memory 150 and a dedicated decryption path (as well as the bypass path 130) for decrypting data being retrieved from the memory 150. For simplicity, FIG. 1 depicts a single encryption path 120 and encryption engine 125 that can perform both encryption and decryption.

[0014] Encryption engine 125 encrypts and decrypts data using encryption key 132. In one embodiment, encryption key 132 has at least two parts: a static portion 134 formed using a unique subkey or ID set by the manufacturer of processor 105, and a dynamic portion 133 formed using a physical address at which data is stored in memory 150. The subkey provided by the manufacturer may be inaccessible to outside entities; that is, hypervisor 135, operating system (OS) 155, and applications 160 may not be able to retrieve the subkey from processor 105.

[0015] Upon receiving a read or write request, memory controller 115 generates encryption key 132 using dynamic portion 133 (e.g., the physical address of the data) and static portion 134 (e.g., an ID or subkey). For example, memory controller 115 combines part (or all) of the physical address with the subkey to generate encryption key 132. Thus, while the first portion of encryption key 132 is static (i.e., the ID or subkey is burned into processor 105), the second portion is dynamic and changes according to the physical address in the read or write request. Therefore, if the encrypted data is obtained by an unauthorized actor, the actor would need to know both processor 105's unique subkey and the physical address stored in memory 150 when the data was encrypted. Furthermore, each cache line of encrypted data in memory 150 may be encrypted with a different encryption key 132. This makes it nearly impossible to crack the various encryption keys 132 using brute force attack methods.

[0016] In one embodiment, encryption key 132 is based on a range of addresses (e.g., a memory block) rather than a single address. In this example, encrypted data stored in the same memory block (or any other logical data partition within memory 150) is encrypted using the same encryption key 132, and encrypted data in different memory blocks is encrypted using different values of encryption key 132.

[0017] Hypervisor 135 may be firmware, hardware, software, or a combination thereof. In one embodiment, hypervisor 135 provides an interface between the virtual address space allocated to OS 155 and applications 160 and the physical addresses used by processor 105. For example, applications 160 may send read and write requests based on the virtual address space, which hypervisor 135 translates into physical addresses in memory 150. These physical addresses may be different from encrypted addresses 140, and bypass addresses 145 are used to indicate to memory controller 115 whether to use encrypted path 120 and bypass path 130 when servicing a read or write request. As described above, memory controller 115 may use the physical addresses (or portions thereof) to generate encryption key 132.

[0018] The encryption address 140 and the bypass address 145 may be any indicators to instruct the memory controller 115 whether data needs to be encrypted / decrypted. For example, the encryption address 140 and the bypass address 145 may be flags, a single memory address, or a range of memory addresses. In one embodiment, the encryption address 140 may be part of a base address register (BAR), while the bypass address 145 is a different BAR. Depending on which BAR value is used for a read or write request, the memory controller 115 may determine whether to use the encryption path 120 or the bypass path 130.

[0019] Memory 150 can be any short-term memory element (e.g., volatile memory), such as DRAM, SRAM, etc. However, memory 150 need not be a short-term memory element, although this is a typical arrangement in modern computing systems. For example, memory 150 may include non-volatile memory.

[0020] Memory 150 includes OS 155 (which may be any OS suitable for performing the tasks described herein) and user data 165. Applications 160 are hosted by OS 155 and may be any software application. Applications 160 generate tasks executed by processor 105. These tasks may include read and write requests that cause memory controller 115 to store user data 165 in memory 150. As described above, based on instructions from applications 160 and hypervisor 135, memory controller 115 can store encrypted data 170 in memory 150 using encryption path 120 and unencrypted data 175 using bypass path 130. The decision to encrypt / decrypt (or not encrypt / decrypt) user data 165 can be made by application 160 on a task-by-task basis (e.g., for each read and write request) rather than by a setting within processor 105 that causes processor 105 to always encrypt user data 165 or never encrypt data.

[0021] In one embodiment, storage 180 is a long-term storage device that includes non-volatile memory elements (e.g., a hard disk drive or solid state drive). In one embodiment, application 160 may need to store encrypted data 170 in storage 180. Application 160 can send a read request to memory controller 115 indicating that encrypted data 170 should be retrieved and transferred to storage 180 using bypass path 130. Encrypted data 170 then bypasses encryption engine 125 and is stored in an encrypted state. Thus, if an unauthorized actor gains access to the data (by physically stealing storage 180 or through electronic means), data 170 will be encrypted. This is also useful when storage 180 is part of a remote data storage node, such as a data center or cloud storage service. If security on the remote node fails, the data is encrypted using an encryption key 132 that is based solely on hardware within computing system 100 (e.g., a subkey assigned to processor 105 and a physical address within memory 150), making it highly unlikely that a malicious actor would be able to decrypt the data without gaining physical control of computing system 100.

[0022] 2 is a flowchart of a method 200 for executing a write request using an encrypted path or a bypass path, according to one embodiment described herein. At block 205, a processor receives a write request from a user application (or hypervisor). In one embodiment, the write request includes an indicator that informs the processor whether data corresponding to the write request should be encrypted before being stored in memory (e.g., using encrypted address 140 or bypass address 145 of FIG. 1). The write request may also include a physical address (or range of physical addresses) where the data should be written to memory.

[0023] In block 210, hardware logic within the memory controller uses the indicator included in the write request to determine whether to use the encrypted path to store the data. In other words, the memory controller uses the indicator to determine whether to use the encrypted path or the bypass path.

[0024] If the bypass path is selected, the method proceeds to block 215, where the memory controller writes the data to memory without first encrypting the data. That is, the memory controller uses the bypass path to bypass the encryption engine in the encryption path. However, if the memory controller selects the encryption path, then in block 220, the encryption engine encrypts the data using an encryption key based on a write address—e.g., a physical address in memory where the encrypted data will be stored after encryption. The write address may be provided by the hypervisor or by logic within the processor.

[0025] In addition to being based on the write address, the encryption key may also be based on a unique ID or subkey assigned to the processor by the manufacturer. The memory controller may use a predefined technique to combine the subkey with the write address to form the encryption key. For example, bits of the subkey may be concatenated with some or all bits (e.g., the most significant bits or the least significant bits) in the write address to form the encryption key. However, embodiments herein are not limited to any particular technique for combining the static and dynamic portions to generate the encryption key.

[0026] In block 225, the hypervisor (or hardware logic in the memory controller) provides the write address to the user application. In this example, because the data was encrypted using a key based on the write address, the same write address must be used so that the data can be decrypted. The user application can record the memory address of the encrypted data in a table or other data structure when it is stored in memory. In this way, the data can be removed from memory (e.g., moved to storage within the computing system or a remote compute node) or moved to a different location in memory and then later decrypted using the same encryption key. A process for decrypting data previously encrypted using method 200 is described in further detail in FIG. 4.

[0027] In either case, method 200 illustrates that the memory controller can use an indicator in the write request to determine whether the corresponding data should be encrypted before being stored in memory. Additionally, while the memory controller can encrypt the data using an encryption key based on the write address, this is not required. That is, method 200 can be used with any encryption key (whether completely static, completely dynamic, or a combination of static and dynamic portions). If the encryption key is completely static (e.g., the memory controller uses the same encryption key for all data it encrypts), block 225 can be omitted because there is no dynamic portion to be tracked by the user application.

[0028] 3 is a flowchart of a method 300 for executing a read request using an encrypted or bypass path, according to one embodiment described herein. That is, while method 200 describes a computing system using a memory controller to execute a write request, method 300 describes the same computing system executing a read request.

[0029] In block 305, the processor receives a read request from a user application or a hypervisor. Similar to method 200, the read request may include an indicator indicating whether the data being read from memory (e.g., RAM) should be decrypted as it is retrieved. For example, the application may need to move encrypted data to a long-term storage device within the computing system or a remote data storage node. For added security, the application may need to store the data in an encrypted state. In this example, the indicator in the read request would instruct the memory controller to use a bypass path when retrieving the data so that the data remains encrypted.

[0030] In another example, an application may retrieve data so that it can be sent to a second, different computing system for processing. In that case, because only the processor in the current computing system can decrypt the encrypted data in memory, the application instructs the processor to decrypt the encrypted data so that the second computing system can process the data. Of course, the application could re-encrypt the data before sending it to the second computing system, but instead of using a hardware encryption key in the memory controller, the application could perform software encryption using a key shared with the second computing system. In this way, the second computing system can decrypt the received data using the shared encryption key. In either case, the application instructs the processor to use an encryption path so that any encrypted data is first decrypted before being delivered.

[0031] At block 310, the memory controller uses an indicator in the read request to determine whether to use the encrypted path or the bypass path. If the bypass path is selected, method 300 proceeds to block 315, where the memory controller retrieves the data from memory in its current state (which may be encrypted or unencrypted). No decryption is performed.

[0032] If an encryption path is selected, method 300 instead proceeds to block 320, where an encryption engine in the encryption path decrypts the data using an encryption key based on the read address. That is, in this embodiment, hardware logic in the memory controller uses the read address (i.e., the physical address or address range where the data is stored in memory) to generate an encryption key and decrypt the data. As long as the data is stored at the same memory address where it was stored when it was written to memory, the memory controller generates the same encryption key that the memory controller uses when encrypting the data while writing it to memory. In other words, as long as the data is retrieved from the same location in memory where it was written when it was encrypted, the memory controller generates the same encryption key and can successfully decrypt the data.

[0033] Of course, method 300 can be used with static encryption keys, in which case it does not matter whether the data being retrieved is stored in a different memory location than where it was originally stored when it was written to memory (and encrypted). In this scenario, the physical address of the data when it is decrypted does not matter, since any data that was encrypted when it was written to memory was encrypted using the same key.

[0034] In block 325, the processor delivers the data to a destination specified by the user application. For example, the processor may transfer the data to a local disk drive for storage, or may transfer the data to a network adapter that transports the data to a distant destination, for example, using a network.

[0035] 4 is a flowchart of a method 400 for decrypting data previously encrypted by a processor, according to one embodiment described herein. That is, method 400 considers that data previously encrypted by a processor has been removed from memory and is still stored in its encrypted state (e.g., in a long-term storage device). An application now needs to, for example, perform further processing on the encrypted data or send the unencrypted data to another computing device for processing. Because the data was encrypted using a secure encryption key within the processor, the same processor must be used to decrypt the data before it can be further processed.

[0036] In block 405, a user application identifies encrypted data that was previously encrypted by a processor. This data may currently be stored somewhere other than memory (e.g., RAM) within the computing device. In one embodiment, data encrypted using a processor may be flagged or tracked by software or a hypervisor, allowing the user application to determine which processor in a multiprocessor system encrypted the data. In this manner, the application can identify which processor should be assigned the task of decrypting the data.

[0037] In block 410, the application (or hypervisor) identifies the physical address in memory where the encrypted data was previously stored when it was encrypted. As described above in block 225, when encrypting the data, the processor can provide the physical address where the encrypted data was stored to the software application. This same physical address may be used as part of the encryption key. Therefore, to decrypt the data, the memory controller needs to know the physical address used when encrypting the data. Note that in embodiments where the encryption key is not based on the physical address of memory, this block may be skipped.

[0038] An application can use any data structure to track the physical addresses of data encrypted by a processor. For example, for each chunk of encrypted data, the application can add an entry to a table indicating which processor performed the encryption and the physical address at which the data was stored in memory as it was encrypted. Note that any technique for tracking this information can be used.

[0039] In block 415, the hypervisor sends a write request to the processor to store the encrypted data at the identified physical address using the bypass path. That is, because the data is already encrypted, the hypervisor can use an indicator to notify the memory controller to use the bypass path, so that the already encrypted data will not be re-encrypted when stored in memory. Furthermore, if the identified physical address is occupied by other data, the memory controller may reject this data or wait until the other data is removed from memory. Also, in one embodiment, the encrypted data may be stored in the same memory location used to originally encrypt the data so that the same encryption key is generated when decrypting the data.

[0040] In block 420, the hypervisor sends a read request to the processor to decrypt the encrypted data using the encryption path. In response, the memory controller uses the physical address in the read request (in this example, the same address used when the data was previously encrypted by the processor) to generate the same encryption key used to encrypt the data. The encryption engine in the encryption path decrypts the encrypted data using the encryption key. The unencrypted data can now be stored back in memory (where further processing is performed on the data at the request of a user application) or sent to another computing element (e.g., another processor or storage element, or another computing system).

[0041] Thus, method 400 describes a technique for encrypting data using hardware encryption, which allows the encrypted data to be stored in its encrypted state in a long-term storage element. The encrypted data can then be returned to the same processor and decrypted using an encryption key, which is faster and more secure than using software encryption, where the encryption key is made available to a software application.

[0042] 5A illustrates executing a write request to encrypt data when mirroring is enabled, according to one embodiment described herein. Data mirroring occurs when the same physical address points to two separate physical memory elements. Mirroring may be used to provide data redundancy, so that if one copy of the data becomes corrupted, the data can be retrieved from the other physical memory element. In this example, memory 150 includes at least two separate memory elements or blocks (P0 and P1).

[0043] 5A, a processor receives a write request that hits a mirrored BAR. In this example, the mirrored BAR is an indicator that the data being written to memory 150 should be encrypted using an encryption path. In one embodiment, the mirrored BAR is different from the physical address where the encrypted data is written to memory 150.

[0044] The data is then encrypted by the encryption engine in the encryption path, and a copy of the encrypted data is stored in both memory elements P0 and P1.

[0045] 5B illustrates performing a read request to retrieve encrypted data using a bypass path when mirroring is enabled, according to one embodiment described herein. In this example, the read request hits a non-mirrored BAR, which is an indicator that data should be retrieved from memory 150 as part of the read request. Thus, the memory controller retrieves the data from memory 150 using the bypass path.

[0046] Furthermore, because memory elements P0 and P1 each contain duplicate (i.e., the same) encrypted data, the memory controller can retrieve the data from either element. In this example, the data is retrieved from memory element P0. Once retrieved, the processor delivers the data to whatever destination is indicated by the application generating the read request.

[0047] Figure 6A illustrates executing a write request to store encrypted data using a bypass path when mirroring is enabled, according to one embodiment described herein. Similar to method 400 of Figure 4, consider that the data corresponding to the write request has already been encrypted by the processor and moved from memory 150 into another storage element. That is, the data of the write request in Figure 6A may be the same data that was encrypted by the write request in Figure 5A and then removed from memory in its encrypted state by the read request in Figure 5B.

[0048] To decrypt the encrypted data, the write request hits a non-mirrored BAR. As a result, the memory controller stores the encrypted data in memory using a bypass path. Also, considering that the encryption key used in FIG. 5A is based on the physical addresses corresponding to P0 and P1, the write request may specify that the memory controller store the encrypted data in either P0 or P1. If data mirroring is still active, the memory controller may store the encrypted data in both P0 and P1, but it may be sufficient to store the data in only one of these memory elements.

[0049] FIG. 6B illustrates executing a read request to decrypt encrypted data using an encryption path when mirroring is enabled, according to one embodiment described herein. After storing the encrypted data as shown in FIG. 6A, the processor receives a read request for data stored in P0 or P1 (or both). This read request hits a mirrored BAR, thereby indicating to the memory controller that the data should be retrieved using the encryption path. In response, the memory controller generates the same encryption key used to encrypt the data in FIG. 5A and decrypts the data. The unencrypted data is then delivered to the destination indicated by the application generating the read request. In this manner, the encryption / bypass paths and dynamic hardware encryption keys described above can be used in a computer system with memory mirroring enabled.

[0050] The description of various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles, practical applications, or technical improvements over commercially available technology of the embodiments, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0051] As explained above, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the particular described embodiments. Instead, any combination of the above-described features and elements, whether associated with different embodiments, is contemplated for implementing and practicing the contemplated embodiments. Moreover, while the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Therefore, the aspects, features, embodiments, and advantages disclosed herein are exemplary only and are not intended to be elements or limitations of the appended claims unless expressly recited in the claims. Similarly, references to "the present invention" should not be construed as a generality of the inventive subject matter disclosed herein, nor should they be considered elements or limitations of the appended claims unless expressly recited in the claims.

[0052] Aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system."

[0053] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0054] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but 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 computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as being itself a transitory signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses through fiber optic cable), or an electrical signal transmitted over a wire.

[0055] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0056] Computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or partially on the remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions according to state information of the computer-readable program instructions to implement aspects of the present invention.

[0057] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0058] These computer-readable program instructions may 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, executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can cause a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner; thus, a computer-readable storage medium having instructions stored therein may include an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0059] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, causing 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, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0060] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or that implements a combination of dedicated hardware and computer instructions.

[0061] While the foregoing description is directed to embodiments of the present invention, other or further embodiments of the invention may be devised without departing from the basic scope thereof, which scope is determined by the claims that follow.

Claims

1. The core and a memory controller configured to receive a first write request to write data to the memory; 1. A processor comprising: The memory controller identifying a physical address in the first write request, the physical address indicating a location in the memory where the data should be stored; generating a first encryption key for encrypting the data based on the physical address; encrypting the data using the first encryption key; storing the encrypted data in said memory; removing the encrypted data from the memory; receiving a second write request to write the encrypted data back into the memory after removing the encrypted data; receiving a read request to retrieve the encrypted data that was written back; identifying a physical address corresponding to the encrypted data; and generating a second encryption key for decrypting the data based on the physical address, the first and second encryption keys being the same; a processor configured to:

2. Generating the first encryption key includes: combining a dynamic portion of the first encryption key with a static portion of the first encryption key, the dynamic portion being derived from the physical address. The processor of claim 1 .

3. The processor of claim 2 , wherein the static portion is based on an ID assigned to the processor during manufacturing.

4. 2. The processor of claim 1, wherein the first encryption key is stored on the processor and is not readable by any entity outside the processor.

5. 2. The processor of claim 1, wherein the physical address in the first write request and the physical address in the read request must be the same for the first and second encryption keys to be the same.

6. The memory controller an encryption path including an encryption engine for encrypting and decrypting data; a bypass path that bypasses the encryption engine for executing read and write requests; Including, the first write request and the read request are performed using the encrypted path, but the second write request is performed using the bypass path. The processor of claim 1 .

7. The memory controller receiving a second write request to write second data to the memory; identifying a second physical address in the second write request, the second physical address indicating a location within the memory where the second data should be stored; and generating a second encryption key based on the second physical address to encrypt the data, the second encryption key being different from the first encryption key; The processor of claim 1 configured to:

8. receiving a first write request to write data to a memory; identifying a physical address in the first write request, the physical address indicating a location in the memory where the data should be stored; generating a first encryption key for encrypting the data based on the physical address; encrypting the data using the first encryption key; storing the encrypted data in said memory; removing the encrypted data from the memory; receiving a second write request to write the encrypted data back into the memory after removing the encrypted data; receiving a read request to retrieve the encrypted data that was written back; identifying a physical address corresponding to the encrypted data; and generating a second encryption key for decrypting the data based on the physical address, the first and second encryption keys being the same; A method comprising:

9. Generating the first encryption key includes: combining a dynamic portion of the first encryption key with a static portion of the first encryption key, the dynamic portion being derived from the physical address. The method of claim 8.

10. The method of claim 9 , wherein the static portion is based on an ID assigned during manufacturing.

11. 9. The method of claim 8, wherein the first encryption key is stored on an integrated circuit but is not readable by any entity outside the integrated circuit.

12. 9. The method of claim 8, wherein the physical address in the first write request and the physical address in the read request must be the same for the first and second encryption keys to be the same.

13. A memory controller in an integrated circuit, comprising: identifying a physical address in a first write request received at the memory controller, the physical address indicating a location in memory where data corresponding to the first write request should be stored; and generating a first encryption key for encrypting the data based on the physical address; and hardware logic configured to: an encryption engine configured to encrypt the data using the first encryption key; Including, storing the encrypted data in said memory; removing the encrypted data from the memory; receiving a second write request to write the encrypted data back into the memory after removing the encrypted data; receiving a read request to retrieve the encrypted data that was written back; identifying a physical address corresponding to the encrypted data; and generating a second encryption key for decrypting the data based on the physical address, the first and second encryption keys being the same; a memory controller configured to:

14. Generating the first encryption key includes: combining a dynamic portion of the first encryption key with a static portion of the first encryption key, the dynamic portion being derived from the physical address.

14. The memory controller of claim 13.

15. 15. The memory controller of claim 14, wherein the static portion is based on an ID assigned to the integrated circuit during manufacturing.

16. 14. The memory controller of claim 13, wherein the first encryption key is stored on the integrated circuit but is not readable by any entity outside the integrated circuit.

17. 14. The memory controller of claim 13, wherein the physical address in the first write request and the physical address in the read request must be the same for the first and second encryption keys to be the same.

Images