Storage-based encryption

Abstract

Embodiments herein describe a memory controller having an encryption 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 an encryption path or a bypass path. For example, using the encryption path when executing 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 the memory without encryption. Similarly, using the encryption path when executing a read request means that the controller decrypts the data before it is transmitted to the requesting entity, while using the bypass path means that the data is transmitted without being decrypted.

Description

Technical Field

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

[0002] Encryption is a common method for data protection and software security, but software-based encryption is slow and requires the software to know the encryption key. Making the key accessible to software means that the key is more easily obtained by malicious actors. While hardware encryption can be performed alternatively (where the encryption key is not available to software), encryption based on hardware accelerators requires expensive system calls to perform.

[0003] Modern processors have built-in encryption engines for encrypting data stored in short-term memory, such as random access memory (RAM). These processors have a user-configurable setting: either all data stored in memory is encrypted, or no data stored in memory is encrypted. If the processor is set to encrypt all data, then whenever data is moved from short-term memory to long-term storage (e.g., a hard drive or solid-state drive), the processor first decrypts the data before storing it. Therefore, the data is only encrypted while residing in short-term memory. In order to encrypt the data in long-term memory, the software application will need to generate another request. As a result, the advantages of performing 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, the memory controller being configured to receive a first write request for writing data to a memory. The memory controller is configured to identify a physical address in the first write request, wherein the physical address indicates where the data should be stored in the memory, and to generate a first encryption key for encrypting the data based on the physical address.

[0005] Another aspect described herein is a method comprising: receiving a first write request to write data to a memory; identifying a physical address in the first write request, wherein the physical address indicates where the data should be stored in the memory; 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, wherein the physical address indicates where data corresponding to the first write request should be; and

[0007] A first encryption key for encrypting the data is stored in the memory and is generated based on the physical address. The memory controller also includes an encryption engine configured to encrypt the data using the first encryption key. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a block diagram of a computing system for performing selective hardware encryption according to one embodiment described herein.

[0009] Figure 2 is a flow chart for performing a write request using an encryption path or a bypass path according to one embodiment described herein.

[0010] Figure 3 is a flow chart for performing a read request using an encryption path or a bypass path according to one embodiment described herein.

[0011] Figure 4 is a flow chart for decrypting data previously encrypted by a processor according to one embodiment described herein.

[0012] Figure 5A Executing a write request to encrypt data when mirroring is enabled according to one embodiment described herein is shown.

[0013] Figure 5B Executing a read request to retrieve encrypted data using a bypass path when mirroring is enabled according to one embodiment described herein is shown.

[0014] Fig. 6A Executing a write request using a bypass path to store encrypted data when mirroring is enabled according to one embodiment described herein is shown.

[0015] Figure 6B Executing a read request using an encryption path to decrypt encrypted data when mirroring is enabled according to one embodiment described herein is shown. DETAILED DESCRIPTION

[0016] Embodiments herein describe performing hardware encryption in a processor using an encryption key that is based on the address at which the data is stored in a memory. For example, an encryption key may include two parts: one part is a unique ID that is inaccessible to any entity outside the processor provided by the manufacturer, and the second part is derived from the physical address at which the data is stored. The processor can use these two parts to generate an encryption key. Thus, data stored in different locations have different encryption keys. Compared to using a static key (for example, if the entire key is assigned by the manufacturer), having a dynamic part of an encryption key based on the data address makes it almost impossible to crack the encryption key using a brute force method.

[0017] Further, compared to setting the processor to always encrypt / decrypt data stored in the memory or never encrypt / decrypt data, in one embodiment, the memory controller in 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 an encryption path or a bypass path. For example, using the encryption 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 the memory without encryption. Similarly, using the encryption path when performing a read request means that the controller decrypts the data before it is transmitted to the requesting entity, while using the bypass path means that the data is transmitted without being decrypted. Therefore, the 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 later instruct the processor to use the bypass path when performing a read operation, so that the encrypted data is now retrieved without being decrypted (and can be stored in an encrypted state in long-term memory).

[0018] Later, the software application may want 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 the bypass path (so that the already encrypted data is not re-encrypted). Then, a read request can be used 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.

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

[0020] The memory controller 115 includes an encryption path 120 for encrypting and decrypting data stored in or retrieved from the memory 150 and a bypass path 130 in which data is stored in or retrieved from the memory 150 without being encrypted or decrypted. For example, as described in more detail below, the processor 105 may receive a write request from the hypervisor 135 that includes an encryption address 140 that serves as an indicator to the memory controller 115 that the encryption path 120 should be used (i.e., the data should be encrypted) when writing data to the memory 150. Conversely, if the write request instead includes a bypass address 145, this indicates to the memory controller 115 that the bypass path 130 should be used—i.e., the data should be stored in the memory 150 without being encrypted. The hypervisor 135 may also use the encryption address 140 and the bypass address 145 when sending a read request to instruct the memory controller 115 to use the encryption path 120 or, alternatively, the bypass path 130 to decrypt the data. Despite Figure 1 1 , memory controller 115 is shown as being in the same integrated circuit that forms processor 105, but memory controller 115 may be part of a separate integrated circuit.

[0021] The encryption path 120 includes an encryption engine 125 that performs encryption and decryption. That is, the encryption engine 125 may encrypt data when a write request is performed using the encryption path 120, and also decrypt data when a read request is performed using the encryption path 120. However, in another embodiment, the memory controller may have an encryption path dedicated to encrypting data stored in the memory 150 and a decryption path (as well as the bypass path 130) dedicated to decrypting data retrieved from the memory 150. For simplicity, Figure 1 A single encryption path 120 and encryption engine 125 are shown that can perform encryption and decryption.

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

[0023] When receiving a read or write request, the memory controller 115 generates an encryption key 132 using a dynamic portion 133 (e.g., the physical address of the data) and a static portion 134 (e.g., an ID or subkey). For example, the memory controller 115 may combine a portion (or all) of the physical address with the subkey to generate the encryption key 132. In this way, the first portion of the encryption key 132 is static (i.e., the ID or subkey burned into the processor 105), while the second portion is dynamic and changes based on the physical address in the read or write request. Thus, if the encrypted data is obtained by a malicious actor, the actor would have to know both the unique subkey of the processor 105 and the physical address where the data was stored in the memory 150 when it was encrypted. Further, each cache line of encrypted data in the memory 150 can be encrypted using a different encryption key 132. This makes it nearly impossible to crack the different encryption keys 132 using a brute force approach.

[0024] In one embodiment, encryption key 132 is based on an address range (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 in memory 150) can be encrypted using the same encryption key 132, while encrypted data in different memory blocks can be encrypted using different values ​​of encryption key 132.

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

[0026] The encryption address 140 and the bypass address 145 may be any indicator for indicating to the memory controller 115 whether data needs to be encrypted / decrypted. For example, the encryption address 140 and the bypass address 145 may be a flag or 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 in a read or write request, the memory controller 115 may determine whether to use the encryption path 120 or the bypass path 130.

[0027] Memory 150 may 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.

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

[0029] In one embodiment, storage device 180 is a long-term storage device containing a non-volatile memory element (e.g., a hard drive or solid-state drive). In one embodiment, application 160 may want to store encrypted data 170 in storage device 180. Application 160 can transmit a read request to memory controller 115 indicating that bypass path 130 should be used to retrieve encrypted data 170 and forward it to storage device 180. The encrypted data 170 then bypasses encryption engine 125 and is stored in its encrypted state. Thus, if a malicious actor accesses the data (by physically stealing storage device 180 or by electronic means), the data 170 is encrypted. This is also useful if storage device 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 has been encrypted using an encryption key 132 (e.g., a subkey assigned to processor 105 and a physical address in memory 150) based only on hardware in computing system 100. In this way, the possibility that a malicious actor can decrypt the data without gaining physical control of computing system 100 is extremely low.

[0030] Figure 22 is a flow chart of a method 200 for executing a write request using an encryption 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 a hypervisor). In one embodiment, the write request includes an indicator that tells the processor whether the data corresponding to the write request should be encrypted (e.g., using a bypass path) before being stored in memory. Figure 1 The write request may also include the physical address (or range of physical addresses) where the data should be written into the memory.

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

[0032] If the bypass path is selected, the method proceeds to block 215, where the memory controller writes the data to the 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 at block 220, the encryption engine encrypts the data using an encryption key based on a write address (e.g., a physical address of the memory where the encrypted data will be stored after being encrypted). The write address may be provided by a hypervisor or by logic within a processor.

[0033] In addition to being based on a 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 and the write address to form the encryption key. For example, the bits of the subkey may be concatenated with some or all bits in the write address (e.g., its most or least significant bit) to form the encryption key. However, the embodiments herein are not limited to any particular technique for combining a static portion with a dynamic portion to generate an encryption key.

[0034] At block 225, the hypervisor (or hardware logic in the memory controller) provides the write address to the user application. Because in this example, the data is encrypted using a key based on the write address, the same write address needs to be used so that the data can be decrypted. The user application can record the memory address when the encrypted data is stored in the memory in a table or other data structure. In this way, the data can then be removed from the memory (e.g., moved to a storage device in a computing system or remote computing node) or moved to a different location in the memory, and then subsequently decrypted using the same encryption key. Figure 4 The process for decrypting data previously encrypted using method 200 is described in more detail in .

[0035] In any case, method 200 shows that the memory controller can use the indicator in the write request to determine for each request whether the corresponding data should be encrypted before being stored in the memory. Further, the memory controller can encrypt the data using an encryption key based on the write address, although 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 parts). If the encryption key is completely static (e.g., the memory controller uses the same encryption key for all data it encrypts), box 225 can be omitted because there is no dynamic part that should be tracked by the user application.

[0036] Figure 3 is a flow chart of a method 300 for performing a read request using an encryption path or a bypass path according to one embodiment described herein. That is, while method 200 describes a computing system performing a write request using a memory controller, method 300 describes the same computing system performing a read request.

[0037] At 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 read from the memory (e.g., RAM) should or should not be decrypted when being retrieved. For example, the application may want to move encrypted data to a long-term storage device in the computing system or a remote data storage node. For enhanced security, the application may want to store the data in an encrypted state. In this example, the indicator in the read request will instruct the memory controller to use a bypass path when retrieving the data, so the data remains encrypted.

[0038] In another example, the application can retrieve the data so that the data can be sent to a different second computing system for processing. In this case, because only the processor in the current computing system can decrypt the encrypted data in the 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 can encrypt the data again before sending it to the second computing system, but instead of using the hardware encryption key in the memory controller, the application can perform software encryption using a key shared with the second computing system. In this way, the second computing system can use the shared encryption key to decrypt the received data. In any case, the application instructs the processor to use the encryption path so that any encrypted data is first decrypted before being transmitted.

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

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

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

[0042] At block 325, the processor transfers the data to the destination specified by the user application. For example, the processor may forward the data to a local disk drive for storage, or to a network adapter that transmits the data to a remote destination using, for example, a network.

[0043] Figure 4 is a flow chart of a method 400 for decrypting data previously encrypted by a processor according to one embodiment described herein. That is, the method 400 assumes that the data previously encrypted by the processor is removed from the memory and is stored elsewhere (e.g., a long-term storage device) in its encrypted state. The application now wants to decrypt the encrypted data, for example, for further processing, or to send the unencrypted data to a different computing device for processing. Because the data was encrypted in the processor using a secure encryption key, the data must be decrypted using the same processor before it can be further processed.

[0044] At block 405, the user application identifies encrypted data that was previously encrypted by the processor. The data may currently be stored somewhere in the computing device other than a memory (e.g., RAM). In one embodiment, data encrypted using a processor may be tagged or tracked by software or a hypervisor so that the user application can determine which processor in a multi-processor system encrypted the data. In this way, the application can identify which processor should be tasked with decrypting the data.

[0045] At block 410, the application (or hypervisor) identifies the physical address in the memory where the encrypted data was previously stored when encrypted. As mentioned above at block 225, when encrypting data, the processor may provide the physical address where the encrypted data is stored to the software application. This same physical address may be used as part of the encryption key. Therefore, in order to decrypt the data, the memory controller needs to know the physical address used when encrypting the data. However, in embodiments where the encryption key is not based on the physical address of the memory, the block may be skipped.

[0046] The application may use any data structure to track the physical addresses of data encrypted by the processor. For example, for each encrypted chunk of data, the application may add an entry in a table indicating which processor performed the encryption and the physical address at which the data was stored in memory when encrypted. However, any technique for tracking this information may be used.

[0047] At box 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 that notifies the memory controller to use the bypass path so that the already encrypted data is not re-encrypted when it is stored in the memory. Further, if the identified physical address is occupied by other data, the memory controller can evict the data, or wait until the other data is removed from the memory. Again, in one embodiment, the encrypted data can be stored in the same memory location used when the data was originally encrypted so that the same encryption key is generated when the data is decrypted.

[0048] At 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 uses the encryption key to decrypt the encrypted data. The now unencrypted data can be stored again in memory (where the data is further processed as required by the user application), or can be transmitted to a different computing element (e.g., a different processor or storage element, or a different computing system).

[0049] In this manner, method 400 illustrates a technique for encrypting data using hardware encryption, wherein the encrypted data may be stored in its encrypted state in a long-term storage element. The encrypted data may then be returned to the same processor and decrypted using an encryption key. Doing so may be faster and more secure than using software encryption, wherein the encryption key is made available to a software application.

[0050] Figure 5A Execution of a write request when mirroring is enabled in order to encrypt data according to one embodiment described herein is shown. Data mirroring is when the same physical address points to two separate physical memory elements. Mirroring can be used to provide data redundancy so that if one copy of the data is damaged, 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).

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

[0052] The data is then encrypted by the encryption engine in the encryption path. Copies of the encrypted data are stored in both memory elements P0 and P1.

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

[0054] Furthermore, because each of the memory elements P0 and P1 contains duplicate (i.e., identical) 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 transmits the data to any destination indicated by the application that generated the read request.

[0055] Fig. 6A 1 shows performing a write request using a bypass path to store encrypted data when mirroring is enabled according to one embodiment described herein. Figure 4 In the method 400, it is assumed that the data corresponding to the write request has been encrypted by the processor and then moved from the memory 150 to a different storage element. That is, Fig. 6A The data in a write request can be Figure 5A The same data as the encrypted data in the write request, and then through Figure 5B The read request in is removed from storage in its encrypted state.

[0056] To decrypt the encrypted data, the write request hits the non-mirrored BAR. Therefore, the memory controller uses the bypass path to store the encrypted data in the memory. In addition, assume that Figure 5A The encryption key used in the write request can specify that the memory controller store the encrypted data in P0 or P1 based on the physical addresses corresponding to P0 and P1. If data mirroring is still activated, the memory controller can store the encrypted data in both P0 and P1; however, it is sufficient to store the data in only one of these memory elements.

[0057] Figure 6B Executing a read request to decrypt encrypted data using an encryption path when mirroring is enabled according to one embodiment described herein is shown. Fig. 6A After the storage shown, the processor receives a read request for data stored in P0 or P1 (or both). The read request hits the mirror BAR, thereby indicating to the memory controller that the encrypted path should be used to retrieve the data. In response, the memory controller generates the same Figure 5A The same encryption key used to encrypt the data in the read request is used to decrypt the data. The unencrypted data is then transmitted to the destination indicated by the application that generated the read request. In this way, the encryption / bypass path and dynamic hardware encryption key discussed above can be used in a computer system that enables memory mirroring.

[0058] The description of different embodiments of the present invention has been presented for the purpose of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications or technical improvements to technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0059] In the above, reference is made to the embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the features and elements discussed above, whether or not related to different embodiments, is considered to implement and practice the embodiments considered. In addition, although the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Thus, the various aspects, features, embodiments and advantages herein are merely illustrative and are not considered to be elements or limitations of the appended claims unless expressly stated in the claims. Similarly, reference to the "present invention" should not be interpreted as a generalization of any inventive subject matter disclosed herein, and should not be considered to be elements or limitations of the appended claims unless expressly stated in the claims.

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

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

[0062] Computer readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, 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 stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses passing through fiber optic cables) or electrical signals emitted by wires.

[0063] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0064] The computer-readable program instructions for performing the operation of the present invention can be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer, partially on the remote computer, or completely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be personalized to perform computer-readable program instructions by utilizing the state information of the computer-readable program instructions to perform the electronic circuit so as to perform various aspects of the present invention.

[0065] This article describes various aspects of the present invention with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0066] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which causes the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0067] These computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so as to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable apparatus, or other device to implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.

[0068] The flow charts and block diagrams in the accompanying drawings show the architecture, functions and operations of the possible implementations of the system, method and computer program product according to different embodiments of the present invention. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, depending on the functions involved, the two blocks shown in succession can actually be executed substantially simultaneously, or these blocks can sometimes be executed in reverse order. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

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

Claims

1. A processor, comprising: nuclear; as well as a memory controller including an encryption path including an encryption engine for encrypting and decrypting data and a bypass path for bypassing the encryption engine when executing read and write requests; Wherein, the memory controller is configured as: receiving a first write request to write data to a memory; identifying a first physical address in the first write request, wherein the first physical address indicates where the data should be stored in the memory; generating a first encryption key for encrypting the data based on the first physical address; encrypting the data using the first encryption key, wherein encrypting the data is performed using the encryption path; storing the encrypted data in a memory; receiving a first read request to retrieve encrypted data; identifying the first physical address corresponding to the encrypted data; generating a second encryption key for decrypting the data based on the first physical address, wherein the first encryption key and the second encryption key are the same; receiving a second read request to read the encrypted second data; and The second read request is performed using the bypass path so that the encrypted second data is retrieved without being decrypted.

2. The processor according to claim 1, wherein: Generating the first encryption key includes: A dynamic portion of the first encryption key is combined with a static portion of the first encryption key, wherein the dynamic portion is derived from the first physical address.

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

4. The processor according to claim 1, wherein: The first encryption key is stored in the processor and is not readable by any entity external to the processor.

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

6. The processor of claim 1, wherein: The memory controller is configured to: receiving a third write request for writing second data into the memory; identifying a second physical address in the third write request, wherein the second physical address indicates where the second data should be stored in the memory; as well as A second encryption key for encrypting the data is generated based on the second physical address, wherein the second encryption key is different from the first encryption key.

7. A method for memory encryption, the method comprising: receiving a first write request to write data to a memory; identifying a first physical address in the first write request, wherein the first physical address indicates where the data should be stored in the memory; as well as generating a first encryption key for encrypting the data based on the first physical address; encrypting the data using the first encryption key, wherein encrypting the data is performed using an encryption path, the encryption path including an encryption engine for encrypting and decrypting data; storing the encrypted data in a memory; receiving a first read request to retrieve encrypted data; identifying the first physical address corresponding to the encrypted data; generating a second encryption key for decrypting the data based on the first physical address, wherein the first encryption key and the second encryption key are the same; receiving a second read request for reading encrypted second data; as well as The second read request is performed using a bypass path, wherein the bypass path bypasses the encryption engine when performing read and write requests so that the encrypted second data is retrieved without being decrypted.

8. The method according to claim 7, wherein: Generating the first encryption key includes: A dynamic portion of the first encryption key is combined with a static portion of the first encryption key, wherein the dynamic portion is derived from the first physical address.

9. The method according to claim 8, wherein: The static portion is based on an ID assigned during the manufacturing process.

10. The method according to claim 7, wherein: The first encryption key is stored in the integrated circuit and cannot be read by any entity external to the integrated circuit.

11. The method of claim 7, wherein the first physical address in the first write request and the physical address in the first read request must be the same in order for the first encryption key and the second encryption key to be the same.

12. A memory controller in an integrated circuit, comprising an encryption path and a bypass path, the encryption path comprising an encryption engine for encrypting and decrypting data, the bypass path bypassing the encryption engine when performing read and write requests, the memory controller being configured to: receiving a first write request to write data to a memory; identifying a first physical address in a first write request received at the memory controller, wherein the first physical address indicates where data corresponding to the first write request should be stored in a memory; as well as generating a first encryption key for encrypting the data based on the first physical address; encrypting the data using the first encryption key, wherein encrypting the data is performed using an encryption path, the encryption path including an encryption engine for encrypting and decrypting data; storing the encrypted data in a memory; receiving a first read request to retrieve encrypted data; identifying the first physical address corresponding to the encrypted data; generating a second encryption key for decrypting the data based on the first physical address, wherein the first encryption key and the second encryption key are the same; receiving a second read request for reading encrypted second data; as well as The second read request is performed using a bypass path, wherein the bypass path bypasses the encryption engine when performing read and write requests so that the encrypted second data is retrieved without being decrypted.

13. The memory controller according to claim 12, wherein: Generating the first encryption key includes: A dynamic portion of the first encryption key is combined with a static portion of the first encryption key, wherein the dynamic portion is derived from the first physical address.

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

15. The memory controller according to claim 12, wherein: The first encryption key is stored in the integrated circuit and cannot be read by any entity external to the integrated circuit.

16. The memory controller of claim 12, wherein the first physical address in the first write request and the physical address in the first read request must be the same in order for the first encryption key and the second encryption key to be the same.

Images