Apparatus and method for controlling access to data stored in untrusted memory

Abstract

The invention provides an apparatus and method for controlling access to data stored in non-trusted memory. The apparatus has memory access circuitry for controlling access to data stored in the non-trusted memory, and memory security circuitry for verifying the integrity of data stored in the non-trusted memory. The memory security circuitry has authentication code generation circuitry for generating authentication codes to be associated with the data stored in the non-trusted memory for use in verifying the integrity of the data. The apparatus also has trusted storage, and the authentication code generation circuitry is arranged to generate different authentication codes depending on whether the authentication codes are to be stored in the non-trusted memory or the trusted storage. In particular, for a given block of data for which an associated authentication code is to be generated, the authentication code generation circuitry is arranged to generate, as the associated authentication code, a first authentication code having a first size when the associated authentication code is to be stored in the non-trusted memory, and to generate, as the associated authentication code, a second authentication code having a second size smaller than the first size when the associated authentication code is to be stored in the trusted storage. This enables the resources of the trusted storage to be used more efficiently.

Description

Background Technology

[0001] This technology relates to memory security, and more specifically to an apparatus and method for controlling access to data stored in untrusted memory.

[0002] Some data processing systems may need to run software that handles confidential or sensitive information that should not be exposed to potential attackers. However, providing sufficient capacity to store all such information in memory that is tamper-proof may not be feasible, so sometimes it may be necessary to export some sensitive information to vulnerable memory. For example, while data stored on-chip may be protected from attack, on-chip memory storage may be limited, thus necessitating writing data to external memory. An attacker might be able to read data from external memory or intercept data as it is being transferred to external memory, and / or tamper with data values ​​stored in external memory in an attempt to cause incorrect behavior when such externally stored data is subsequently brought back to the processing system.

[0003] To provide security for data stored in potentially insecure memory, authentication codes can be generated and associated with that data. These codes are then referenced during verification to check that the data has not been modified since it was stored when reading from insecure memory. While authentication codes are smaller than the data they are used to authenticate (e.g., 64 to 128 bits for a 64-byte data block), they need to be large enough to suppress the possibility of collisions that could be exploited by attackers—that is, collisions that occur when two different data values ​​produce the same authentication code. Otherwise, in the event of a collision, an attacker monitoring untrusted memory could replace the current value with a different one and thus corrupt the memory, because verification performed using the authentication code would result in a false positive (i.e., verification would pass even though the data is different).

[0004] Therefore, the size of the set of authentication keys used in association with data stored in untrusted memory is typically larger than the set of authentication keys that can be stored on-chip, and thus can also be stored in untrusted memory. To improve performance, a limited number of authentication keys that may be used in the future can be stored in trusted storage devices (such as on-chip caches), where the access time is less than that of authentication keys accessed in untrusted memory. However, such trusted storage devices are typically relatively small in size, and it is desirable to utilize them more efficiently. Summary of the Invention

[0005] In a first exemplary arrangement, an apparatus is provided, comprising: a memory access circuit for controlling access to data stored in an untrusted memory; a memory security circuit for verifying the integrity of the data stored in the untrusted memory; and a trusted storage device; the memory security circuit having an authentication code generation circuit for generating an authentication code to be associated with the data stored in the untrusted memory for use in verifying the integrity of the data; wherein, for a given data block for which an associated authentication code is to be generated, the authentication code generation circuit is arranged to: generate a first authentication code having a first size as the associated authentication code when the associated authentication code is to be stored in the untrusted memory, and generate a second authentication code having a second size smaller than the first size as the associated authentication code when the associated authentication code is to be stored in the trusted storage device.

[0006] In a second exemplary arrangement, a method for controlling access to data stored in an untrusted memory is provided, the method comprising: employing an authentication code generation circuit to generate an authentication code to be associated with the data stored in the untrusted memory; referencing the authentication code to verify the integrity of the data; providing a trusted storage device; and, for a given data block for which an associated authentication code is to be generated, arranging the authentication code generation circuit to: generate a first authentication code having a first size as the associated authentication code when the associated authentication code is to be stored in the untrusted memory, and generate a second authentication code having a second size smaller than the first size as the associated authentication code when the associated authentication code is to be stored in the trusted storage device.

[0007] In another exemplary arrangement, an apparatus is provided, comprising: a memory access means for controlling access to data stored in an untrusted memory; a memory security means for verifying the integrity of the data stored in the untrusted memory; and a trusted storage means; the memory security means having an authentication code generation means for generating an authentication code to be associated with the data stored in the untrusted memory for use in verifying the integrity of the data; wherein the authentication code generation means, in response to a given data block for which an associated authentication code is to be generated, generates a first authentication code of a first size as the associated authentication code when the associated authentication code is to be stored in the untrusted memory, and generates a second authentication code of a second size smaller than the first size as the associated authentication code when the associated authentication code is to be stored in the trusted storage means. Attached Figure Description

[0008] The present technology will be further described by way of illustration only, with reference to examples of the present technology shown in the accompanying drawings, wherein:

[0009] Figure 1 This is a block diagram schematically illustrating an example of a device with a memory security circuit for verifying the integrity of data stored in an untrusted memory.

[0010] Figures 2A to 2C The illustration schematically shows a technique that can be used to generate a first authentication code and a second authentication code according to an exemplary arrangement;

[0011] Figure 3 This is a flowchart illustrating the authentication code generation process used in an exemplary arrangement;

[0012] Figure 4 This is a flowchart illustrating the eviction process employed in an exemplary arrangement;

[0013] Figure 5 This is a flowchart illustrating the data reading process employed in an exemplary arrangement;

[0014] Figure 6 This is shown as an example arrangement that can be used as Figure 5 A flowchart of the sequence of steps performed as an alternative to step 265;

[0015] Figure 7 The flowchart, based on an exemplary arrangement, illustrates how a reduced-size authentication code can be generated from a full-size authentication code sequence read from an untrusted memory.

[0016] Figure 8A and Figure 8B An authentication code generation circuit of one form that can be employed in a particular exemplary arrangement is shown; and

[0017] Figure 9 It is shown in an exemplary arrangement when using Figure 8A and Figure 8B When the authentication code circuit shown is used, how can a smaller authentication code be generated from the input full-size authentication code? Detailed Implementation

[0018] According to one exemplary embodiment, an apparatus is provided having a memory access circuit for controlling access to data stored in an untrusted memory, and a memory security circuit for verifying the integrity of the data stored in the untrusted memory. The memory security circuit includes an authentication code generation circuit for generating an authentication code to be associated with the data stored in the untrusted memory for use in verifying the integrity of the data.

[0019] A trusted storage device is also provided, which typically has a significantly smaller capacity than the untrusted memory. This trusted storage device can take various forms, but can be, for example, a cache storage device. Typically, this cache storage device can be used to cache a subset of the information stored in the untrusted memory. Therefore, while the authentication codes generated by the authentication code generation circuit can generally be stored in the untrusted memory, a subset of those authentication codes can be stored in the trusted storage device. However, the inventors of this technology realized that a more efficient use of the trusted storage device can be achieved compared to simply using it to cache a subset of the authentication codes stored in the untrusted memory. Specifically, as previously mentioned, these authentication codes are typically made large enough to suppress the possibility of collisions exploited by attackers. Otherwise, an attacker could implement a substitution attack, whereby the data stored in memory is replaced with different data that generates the same authentication code, and thus passes the verification check.

[0020] However, the inventors point out that since attackers cannot read the contents of the trusted storage device, they are unaware of potential collisions and therefore do not know the exact time to execute a substitution attack. Thus, when verification checks use authentication code information stored in the trusted storage device, the only chance for an attacker to carry out a substitution attack is to blindly replace data values ​​in memory and hope for an authentication code collision. This attack has a 1 / 2 chance of success. i The success probability is given by , where i is the bit size of the authentication code. Furthermore, attackers will typically only have a single attempt, as detected memory corruption will trigger an emergency procedure that usually halts the affected process.

[0021] Therefore, while the fact that the entire set of authentication codes is typically too large to be stored in trusted storage necessitates storing them in untrusted memory, and this generally indicates that the size of the authentication codes effectively minimizes the chance of collisions to a degree sufficient to deter attackers from performing substitution attacks, the inventors realized that when authentication codes are stored in trusted storage, they no longer need to be as large as when stored in untrusted memory. Therefore, according to the technique described herein, the authentication code generation circuitry is arranged to generate different forms of authentication codes depending on where they will be stored, rather than simply using trusted storage to cache copies of the subset of authentication codes generated for storage in untrusted memory.

[0022] Specifically, for a given data block for which an associated authentication code is to be generated, the authentication code generation circuit is arranged such that: when the associated authentication code is to be stored in the untrusted memory, a first authentication code of a first size is generated as the associated authentication code; and when the associated authentication code is to be stored in the trusted storage device, a second authentication code of a second size smaller than the first size is generated as the associated authentication code. Therefore, compared to the case where the trusted storage device is only used to cache a subset of authentication codes stored in the untrusted memory, a larger number of authentication codes can be stored in the trusted storage device. This can significantly reduce silicon area and power consumption within the device without compromising the effectiveness of the integrity checks performed by the device. Specifically, while reducing the size of the authentication code does increase the chance of collisions, since the reduced-size authentication code is only used within the trusted storage device, potential attackers cannot access the contents of the trusted storage device. Therefore, attackers cannot exploit this increased probability of collisions and, as previously mentioned, can only attempt to perform blind attacks without any information about the likelihood of collisions caused by the attack.

[0023] The first and second sizes of the authentication codes used for storage in untrusted and trusted memory devices, respectively, are a matter of design choice. However, by simply providing a concrete example, it is possible that when the first authentication code is stored in untrusted memory, these codes are used in association with 64-byte blocks of data, but the resulting second authentication code for storage in trusted memory might only be 16 or 32 bits, implying a 75% or 50% reduction in cache size, respectively. Alternatively, it will be understood that, compared to caching only a subset of authentication codes stored in untrusted memory, a significantly larger number of authentication codes can be stored in trusted memory when employing the techniques described above, rather than reducing the cache size.

[0024] In one exemplary embodiment, the device can be considered to reside with a trusted domain, and the untrusted memory may be located outside the trusted domain. In this arrangement, the authentication code generation circuitry can be configured to generate the second authentication code in a manner that ensures it cannot be inferred from information residing outside the trusted domain. Specifically, to ensure the robustness of the integrity check process is not compromised by using a smaller authentication code within the trusted storage device, it is desirable that the reduced-size authentication code be unpredictable to potential attackers. It is evident from the above discussion that not only the data but also the first authentication code is stored in the untrusted memory, therefore it is desirable that the second authentication code cannot be predicted from knowledge of the first authentication code. Thus, for example, it is desirable that the second authentication code is not generated solely by truncating the first authentication code.

[0025] Therefore, in one exemplary arrangement, the authentication code generation circuit is configured to employ an authentication code generation process that depends on which of the first and second authentication codes is being generated, to ensure that the second authentication code generated for a given data block cannot be inferred from the visibility of the first authentication code for that given data block.

[0026] There are multiple ways to ensure that a second authentication code cannot be derived from the visibility of an equivalent first authentication code. For example, in one implementation, the authentication code generation process depends on the input items of the confidential data, and the authentication code generation circuit is arranged such that a first item of the confidential data is used when the first authentication code is generated, and a second item of the confidential data is used when the second authentication code is generated, wherein the second item of the confidential data is different from the first item of the confidential data.

[0027] There are several ways to generate a second authentication code. For example, the authentication code generation circuit can be arranged to generate the second authentication code by applying an algorithm that takes a given data block as an input. Therefore, the second authentication code can be generated based on the data block to which the authentication code is associated and a second item of the confidential data (i.e., an item of confidential data that is different from the equivalent item of the confidential data used to generate the first authentication code). However, in an alternative implementation, the second authentication code can be generated without reference to a given data block. Specifically, the authentication code generation circuit can be arranged to generate the second authentication code by applying an algorithm that takes the first authentication code as an input. Therefore, in such an implementation, the first authentication code will always be generated, but if it is decided to store the authentication code in a trusted storage device, an additional process will be employed to generate the second authentication code based on the first authentication code. It should be noted that in this case, there is still a possibility that an attacker cannot infer the second authentication code from knowledge of the first authentication code, because other inputs, such as the previously mentioned second item of the confidential data, will also be used when generating the second authentication code.

[0028] There are multiple ways in which an authentication code generation circuit can generate a second authentication code with the desired second size. For example, the algorithm used to generate the second authentication code can directly generate a second authentication code with the desired second size. However, in an alternative implementation, the authentication code generation circuit can be arranged to generate the second authentication code by employing an algorithm that generates an intermediate authentication code with a first size, and then applying another process to generate a second authentication code with a second size from the intermediate authentication code. Therefore, the algorithm used to generate the second authentication code may not itself directly generate an authentication code with the desired size, but a separate process can then be used to convert the intermediate authentication code into a second authentication code with a second size. For example, this other process could be a truncation process, such that the second authentication code is simply a truncated version of the intermediate authentication code.

[0029] As previously mentioned, trusted storage devices can take many forms, but in one exemplary implementation, the trusted storage device is organized as a cache to store a second authentication key for a subset of data blocks stored in untrusted memory.

[0030] When a trusted storage device is organized as a cache, it will be apparent that there will sometimes be a need to evict a second authentication code from the cache, for example, to make room for a newly generated second authentication code. In this case, to avoid losing any authentication code information, the equivalent first authentication code must reside in the untrusted memory. There are several ways to achieve this. For example, in one implementation, when generating a second authentication code to be stored in the trusted storage device, the authentication code generation circuit can be arranged to also generate a first authentication code and store the generated first authentication code in the untrusted memory, so that when any second authentication code is evicted from the trusted storage device, the corresponding first authentication code resides in the untrusted memory. Therefore, since an equivalent first authentication code is also generated and stored in the untrusted memory when the second authentication code is initially generated and stored in the trusted storage device, when evicting the second authentication code, it can simply be discarded without any further action.

[0031] However, in an alternative implementation, when generating a second authentication code to be stored in a trusted storage device, the authentication code generation circuit can be arranged not to store the first authentication code in the untrusted storage, and when any second authentication code is evicted from the trusted storage device, the authentication code generation circuit can be arranged to generate a corresponding first authentication code to be stored in the untrusted storage. It should be noted that, depending on the process used to generate the second authentication code, the first authentication code may or may not be generated as part of the process of generating the second authentication code. However, according to this exemplary implementation, even if the first authentication code is generated as part of the process of generating the second authentication code, once the second authentication code has been generated and stored in the trusted storage device, the first authentication code is not retained, and therefore needs to be regenerated upon evicting. Since the first authentication code cannot be regenerated from the second authentication code, the relevant data block must be read from the untrusted storage to generate the first authentication code to be stored in the untrusted storage. It should be noted that the success of this generation process depends on the integrity verification of the read data block. To perform this verification, the second authentication code is recreated from the read data block, and then the second authentication code is compared with the second authentication code to be evicted. If the verification is successful, the expulsion process can be completed by discarding the second authentication key and storing the verified first authentication key in an untrusted memory.

[0032] In one exemplary implementation, when reading a data block from untrusted memory, the memory security circuit is configured to determine whether an associated authentication code is stored as a second authentication code in a trusted storage device, and if so, to use the second authentication code in the trusted storage device to verify the integrity of the read data block. Conversely, if it is determined that the associated authentication code is not stored as a second authentication code in the trusted storage device, the memory security circuit may be configured to retrieve a first authentication code from the untrusted memory, and then use the retrieved first authentication code when verifying the integrity of the read data block.

[0033] While in one exemplary embodiment the memory security circuit may include verification checking components that can perform verification checks based on either a first authentication code or a second authentication code, in alternative embodiments the memory security circuit may be arranged such that checks are always performed with reference to the second authentication code. For example, this approach may be used when the authentication code generation circuit is arranged to generate the second authentication code using the first authentication code as input. Specifically, in one exemplary arrangement, the memory security circuit may be arranged to employ the authentication code generation circuit to apply a second code generation algorithm to generate a reference second authentication code based on the first authentication code retrieved from untrusted memory. Furthermore, the authentication code generation circuit may be arranged to generate a comparison second authentication code by first generating a comparison first authentication code from a read data block, and then applying the comparison first authentication code to the second code generation algorithm to generate a comparison second authentication code. The memory security circuit may then be arranged to verify the integrity of the read data block by comparing the reference second authentication code with the comparison second authentication code. In this way, regardless of whether the authentication code for a specific data block is stored as a second authentication code in a trusted storage device or as a first authentication code in an untrusted memory, the memory security circuit can be arranged to verify the integrity of the read data block based on the second authentication code and by comparing the second authentication code.

[0034] In this implementation where the authentication code generation circuit generates a second authentication code by applying an algorithm that uses a first authentication code as input, the above-described situation can offer some benefits when the authentication code is migrated from untrusted memory to trusted storage. Specifically, at this point in time, a second authentication code needs to be generated for storage in the trusted storage, and when the above-described technique is employed, a corresponding second authentication code can be generated for storage in the trusted storage without referencing the associated data block. Therefore, it is not necessary to access the untrusted memory to retrieve the data block in question; instead, the second authentication code can be generated using an equivalent first authentication code as input (note that the reverse process is not possible). This can be useful when reading a sequence of first authentication codes from untrusted memory, enabling the generation of a corresponding equivalent sequence of second authentication codes and their storage in the trusted storage without retrieving the associated data block from the untrusted memory. An example of this is prefetching the first authentication code from the untrusted memory into the trusted memory cache by explicitly or implicitly reading a full cache line containing multiple first authentication codes.

[0035] The authentication code generation circuit can be arranged in various ways and can include, for example, completely separate circuit elements for generating a first authentication code and for generating a second authentication code. However, in one exemplary arrangement, the authentication code generation circuit is arranged to apply a first process to generate the first authentication code and apply a second process to generate the second authentication code, the first process and the second process sharing a common initial portion.

[0036] In one particular exemplary arrangement, the common initial portion includes performing a hash function on a data block using an input key to produce an intermediate value. The authentication code generation circuitry is then arranged to complete a first process by encrypting the intermediate value using first confidential data to generate a first authentication code, and to complete a second process by encrypting the intermediate value using second confidential data to generate a second authentication code. This provides some efficiency benefits by avoiding the need to replicate the hash function within both the circuitry for generating the first authentication code and the circuitry for generating the second authentication code.

[0037] Furthermore, the above-mentioned approach can offer additional benefits when it is desired to generate a second authentication code after the first authentication code has already been generated, such as when the authentication code needs to be migrated from an untrusted memory to a trusted memory device. Specifically, in this case, the authentication code generation circuit can be arranged to generate the second authentication code by decrypting the first authentication code using first confidential data to generate an intermediate value, and then encrypting the intermediate value using second confidential data to generate the second authentication code. Therefore, it is not necessary to retrieve the data block associated with the authentication code to generate the second authentication code; instead, the second authentication code can be generated directly from the intermediate value obtained by decrypting the first authentication code.

[0038] A specific example will now be described with reference to the accompanying drawings.

[0039] Figure 1 An example of a data processing system is schematically shown, which includes an integrated circuit (IC) or system-on-a-chip (SoC) 10, comprising at least one processor core 15 for executing program instructions to perform data processing operations. Although Figure 1 Only one processor core is shown, but in some cases, SoC 10 may include multiple processors. Each processor core or cluster of processor cores may have a cache 20 (or multi-level caches 20, 25). Memory controller 35 acts as memory access circuitry for controlling access to off-chip memory 40, which resides on a separate integrated circuit from SoC 10. While access to on-chip data may be difficult for an attacker to tamper with, the edges of the SoC may act as trust boundaries, and any data outside these boundaries may be vulnerable to attack by intercepting data on the physical channel 37 between memory controller 35 and off-chip memory 40, or by reading or modifying data while it is stored in off-chip memory 40.

[0040] It should be noted that, although Figure 1 An example of a trust boundary corresponding to the edge of a SoC is shown, but in other cases, trust boundaries may exist within the SoC (or between stacked layers of a 3D integrated circuit), which could expose data beyond the trust boundary to potential attacks.

[0041] SoC 10 may include a memory security unit 30, which is provided to protect data stored in off-chip memory 40 from malicious adversaries who can physically access the system and are able to observe and / or replay data or code exchanged between the microprocessor and off-chip memory 40. Memory 40 stores not only the data 45 to be protected, but also a Message Authentication Code (MAC) 50 used to verify the integrity of the data.

[0042] The memory security unit 30 may include encryption / decryption circuitry 55 for encrypting data written to off-chip memory 40 and decrypting data read back from off-chip memory. This provides privacy by preventing a malicious observer from clearly seeing data being read from or stored on off-chip memory 40. The encryption keys used by the encryption and decryption circuitry may be stored in on-chip memory on the system-on-chip. Figure 1(Not shown) within the secure memory unit 30 itself. Encryption and decryption can be performed using any known techniques, and any known methods for protecting the encryption key can be used. It should be noted that data encryption is not required when using the authentication code mechanism described herein, and the authentication code mechanism can be used for plaintext (i.e., unencrypted data) if needed.

[0043] The memory security unit 30 also includes an authentication unit 60 for generating a message authentication code and for using the associated message authentication code to perform an authentication process to verify the integrity of the data 45. Specifically, when writing a data block to the untrusted memory 40, the authentication unit 60 can be used to generate an associated MAC, wherein the data block is then written to the untrusted memory, and wherein the generated MAC is also stored for future reference. As will be discussed in more detail later, the generated MAC can be stored in a MAC set 50 within the untrusted memory 40, or alternatively, a reduced-size MAC can be generated and stored in a trusted storage device 65 provided in association with the memory security unit 30. The trusted storage device can take various forms, but in one embodiment it can be formed as a cache.

[0044] Then, when data is subsequently read from the untrusted memory 40, the authentication unit 60 can generate a comparison MAC from the retrieved data, and then compare this comparison MAC with the MAC for that data storage to check the integrity of the data. Specifically, the data is determined to have passed the data integrity check only if the MAC generated by the authentication unit 60 from the read data matches the MAC for that data storage.

[0045] MACs can be generated in various ways, but in one exemplary implementation, one-way encryption functions such as AES-GCM or SHA-256 can be used to generate MACs. When the secret key used to generate the authentication code is unknown, the functions used by these one-way encryption functions make it computationally impossible for an attacker to guess the authentication code associated with a specific data value by brute force.

[0046] As previously discussed, the MAC generated by authentication unit 60 is typically chosen to be large enough that the risk of MAC collisions is very low, thus suppressing the ability of an attacker to exploit MAC collisions as a mechanism to modify data 45 stored in untrusted memory 40. Given that a MAC needs to be generated for each data block stored in the protected untrusted memory 40, the resulting set of MACs will be relatively large, and there is typically not enough memory within the SoC 10 to store all the generated MACs. Therefore, MAC 50 must be stored in untrusted memory 40, and thus the size of the generated MAC will be chosen to be large enough to ensure that the risk of MAC collisions is very low, preventing an attacker from tampering with the memory contents using MAC collisions, even if the attacker has access to data 45 and MAC 50.

[0047] Typically, an on-chip cache can be used to store a subset of MACs 50 to allow for faster access to those MACs, and thus, for example, a trusted storage device 65 can be used to store a subset of MACs. However, instead of using only an on-chip cache to store a subset of MACs externally stored in untrusted memory 40, a different approach is employed according to the techniques described herein, whereby the authentication unit 60 generates different authentication codes depending on whether the authentication code is externally stored in untrusted memory 40 or stored within the SoC 10 (e.g., within trusted storage device 65). Specifically, when the MAC is stored within trusted storage device 65, this means that an attacker cannot access that information. Therefore, it has been recognized that when performing verification using MACs stored within trusted storage device 65, an attacker is unaware of potential conflicts and, consequently, the exact time when a substitution attack should be performed. This means that the size of the MAC used when it is stored within trusted storage device 65 provided within the SoC 10 can be reduced compared to the size of the MAC used when it is stored in untrusted memory 40, without compromising the data integrity verification process. Specifically, while a smaller MAC does increase the MAC collision rate, an attacker cannot exploit this increased collision opportunity if the smaller MAC is stored only in trusted storage device 65, rather than externally in untrusted storage device 40.

[0048] Therefore, according to the technology described herein, when authentication unit 60 is generating a MAC for a data block, if the MAC is to be stored in trusted storage device 65, authentication unit 60 is arranged to employ an authentication code generation process that generates a reduced-size MAC. However, when authentication unit 60 is generating a MAC to be stored as one of MACs 50 in untrusted storage device 40, the authentication unit instead employs a different authentication code generation process that generates a full-size MAC for storage in untrusted storage device 40. Furthermore, the different authentication code generation processes are arranged such that the reduced-size MAC generated for storage in trusted storage device 65 cannot be inferred from the corresponding full-size MAC, which can be generated and stored in untrusted storage device 40.

[0049] Figure 2A The diagram illustrates how authentication unit 60 can generate a full-size MAC for storage in untrusted memory 40; this full-size MAC is also referred to herein as a first authentication code. MAC function 100 can be used as an algorithm to generate the first authentication code from multiple inputs. Specifically, the data to be used to generate the MAC is the input and can be the original unencrypted data or an encrypted version of the data (also referred to as ciphertext). A secret key is also provided for generating the authentication code from the data. Furthermore, in some implementations, other input information may be provided, such as a physical address corresponding to the data, and optionally, some input information forming a unique value that does not repeat over time (e.g., a counter value). A separate counter can be maintained for each data block and can be incremented or updated each time a corresponding data block is written. Therefore, the counter can be considered a random number, i.e., an arbitrary number used only once, whose value changes each time a corresponding data block is written, thus changing the generated authentication code each time data is written. The physical address can be concatenated with a counter to form the input to the MAC function 100 along with the secret key and data (e.g., the concatenated physical address and counter used with the secret key serve as input to a function that generates a one-time keybook (OTP)).

[0050] Depending on the implementation method, except Figure 2A In addition to the three inputs shown, the MAC function 100 can take many other forms and can actually take additional inputs. As an example, the MAC function can be implemented by a combination of a hash function and an encryption function, and in such a case, the MAC function can also receive the input key used by the hash function to generate a hash value from the input data, and then encrypt that hash value using a secret key and other inputs formed from the physical address and counter.

[0051] Figure 2BA function that can be used to generate a reduced-size MAC (also referred to herein as a second authentication code) for storage in a trusted storage device is shown. In this example, the MAC function 105 also receives data as input (plaintext or ciphertext), as... Figure 2A The MAC function 105 does the same as MAC function 100 to generate a full-size MAC. MAC function 105 also receives a secret key, but in this exemplary embodiment, this secret key is different from the secret key used for the first authentication code; therefore, the reduced-size MAC cannot be inferred from knowledge of the equivalent full-size MAC generated using MAC function 100. Figure 2A Similar to the example, MAC function 105 can accept other inputs, such as a concatenation of a physical address and a counter.

[0052] MAC function 105 can be a different MAC function from MAC function 100, or it can be essentially the same MAC function, such that the only difference is that the secret key used by MAC function 105 is different from the secret key used by MAC function 100. The application of MAC function 105 results in the generation of an intermediate authentication code. In some cases, this intermediate authentication code may directly have the desired reduced size, but in other exemplary implementations, such as when MAC function 105 is essentially the same MAC function as MAC function 100, another process may be needed to generate a reduced-size MAC from the intermediate authentication code. For example, as... Figure 2B As shown, the truncation process 110 can be used to discard certain bits of the intermediate authentication code in order to generate a second authentication code of the desired size.

[0053] While the sizes of the full-size MAC and the reduced-size MAC can vary depending on the implementation, in one exemplary embodiment, the full-size MAC may be 64 bits long, while the equivalent reduced-size MAC may be only 16 or 32 bits. Therefore, it should be understood that the number of authentication codes that can be stored in the trusted storage device 65 is significantly increased compared to a method that caches only a subset of the full-size MAC in the trusted storage device 65. Alternatively, for the desired number of authentication codes to be stored in the trusted storage device 65, the size of the trusted storage device itself can be significantly reduced compared to a method where the trusted storage device is only used to cache a subset of the full-size MAC 50 stored in the untrusted memory 40.

[0054] Although Figure 2B In the example, the data block associated with the second authentication code is provided as input to the MAC function 105, but in an alternative implementation, it can be derived from... Figure 2A The output of MAC function 100, as shown, generates a first authentication code, which in turn generates a second authentication code. This is in... Figure 2CThe diagram shows that encryption function 115 uses a first authentication code and a secret key different from the secret key used to generate the first authentication code as input. In this implementation, it may be considered unnecessary to also provide the physical address and counter as input, as this information has already been considered when generating the first authentication code. Encryption function 115 then generates an intermediate authentication code and, together with... Figure 2B The method is the same; if necessary, truncation procedure 120 can be used to discard certain bits of the intermediate authentication code in order to produce a second authentication code with the desired reduced size.

[0055] Figure 3 This is shown in an exemplary embodiment by Figure 1 The flowchart illustrates the authentication code generation process used by authentication unit 60. At step 150, it is determined whether an authentication code is required for the data block to be written to untrusted memory 40, and if it is determined that there are data blocks to be written that require an authentication code, the process proceeds to step 155. It should be noted that some data blocks written to untrusted memory 40 may not require the authentication process, so it is not always the case that every data block written to untrusted memory needs to have an associated MAC generated.

[0056] When it is determined at step 150 that an authentication code is needed, then at step 155 it is determined whether the authentication code should be stored in the on-chip cache, for example... Figure 1 The trusted storage device 65 shown is illustrated. In one exemplary embodiment, it is often the case that authentication codes are initially generated as smaller authentication codes for storage in an on-chip cache, while older authentication codes stored in the on-chip cache are evicted when necessary to make room for newly generated authentication codes. In this case, the process will always follow... Figure 3 The "yes" path is shown. However, in a more general implementation, it can be determined that for some regions of memory, or at least for certain data blocks, a full-size MAC will be generated for storage in untrusted memory, rather than a reduced-size MAC for storage in on-chip cache.

[0057] If it is determined that the authentication code should be stored in the on-chip cache, the process proceeds to step 165, in which authentication unit 60 is used to generate the required reduced-size MAC for storage in the on-chip cache, using, for example... Figure 2B MAC function 105 or Figure 2C The encryption function 115. It should be noted that, at least when using encryption function 115, the process performed by the authentication unit at step 165 will also involve generating a first authentication code (i.e., a full-size MAC), as it is the input required by the encryption function.

[0058] As shown in optional step 170, the authentication unit can also be arranged to generate a full-size MAC and store the full-size MAC in untrusted memory 40. Therefore, regardless of the method used in step 165... Figure 2B The MAC function 105 still uses Figure 2C The encryption function 115 allows the authentication unit to be configured in any case to generate a full-size MAC using the MAC function 100 and store that full-size MAC in untrusted memory. This can be simplified if, as will be discussed in more detail later, the reduced-size MAC generated at step 165 needs to be evicted from the on-chip cache when appropriate, since the corresponding full-size MAC already exists in the untrusted memory and therefore does not need to be recreated.

[0059] If it is decided at step 155 not to store the authentication code in the on-chip cache, the process proceeds to step 160, in which the authentication unit 60 is used to generate a full-size MAC for storage in the untrusted memory 40, for example using... Figure 2A The MAC function 100 is shown in the figure.

[0060] Figure 4 This is a flowchart illustrating the eviction process that can be employed when a reduced-size MAC needs to be evicted from the on-chip cache. As previously discussed, this eviction process may arise due to the need to free up space to receive the newly generated reduced-size MAC, or it may actually occur as part of general cache maintenance operations. When it is determined at step 200 that a reduced-size MAC does indeed need to be evicted from the on-chip cache, then at step 205 it is determined whether the corresponding latest full-size MAC has already been stored in untrusted memory. From the previously discussed... Figure 3 It will be obvious that if step 170 is performed when generating each reduced-size MAC, this will occur because in this case, it can be seen that the on-chip cache is effectively operating as a write-through cache, since for each reduced-size MAC stored in the on-chip cache, a corresponding full-size MAC is simultaneously generated and stored in the untrusted memory 40.

[0061] If the corresponding latest full-size MAC is already stored in the untrusted memory 40, the process proceeds to step 220, in which only the evicted, reduced-size MAC needs to be discarded.

[0062] However, if the corresponding latest full-size MAC is not yet stored in the untrusted memory 205, the process proceeds to step 210, in which a corresponding full-size MAC is generated for the data block associated with the reduced-size MAC. It should be noted that, as part of this process, it is typically considered necessary to first perform a verification check on the data block to check whether the data block has been modified since the reduced-size MAC was generated. Therefore, to perform the verification check, the data block can be read from the untrusted memory, and then the read data (using, for example...) can be... Figure 2B The MAC function 105) recreates a smaller-sized comparison MAC so that it can be compared with a smaller-sized MAC stored in the on-chip cache. Assuming this results in a match, the data block is considered correct, and therefore the process can continue to create a full-size MAC from the data read, for example using... Figure 2A The MAC function is 100.

[0063] After step 210, and then at step 215, the full-size MAC can be stored in untrusted memory 40, and then at step 220, the reduced-size MAC can be discarded.

[0064] Figure 5 This is a flowchart illustrating a data reading process employed in one exemplary embodiment. When it is determined at step 250 that a data block is to be read from untrusted memory, then at step 255 it is determined whether a corresponding reduced-size MAC exists in the on-chip cache. For example, for each stored MAC, whether in the on-chip cache or in untrusted memory 40, an address indicator can be stored to identify the address of the data block associated with that MAC, and thus it can be determined whether the on-chip cache stores a reduced-size MAC associated with the memory address of the data block. However, in alternative embodiments, such an address indicator may not be necessary. For example, the MAC may be stored in a fixed memory region, and the address of the MAC can be inferred from the address of the data block associated with the MAC. For example, considering a very specific exemplary embodiment where it is assumed that the MAC region is contiguous and starts at address 0x100000000, if a data block is at address 0x8000 and the MAC is 8 times smaller than the data block, then the MAC address of the data block is 0x100000000+0x1000.

[0065] If the corresponding reduced-size MAC exists in the on-chip cache, then at step 270, the reduced-size MAC is read from the on-chip cache, and then at step 275, a reduced-size comparison MAC is created from the read data block. At step 275, the reduced-size comparison MAC can be used... Figure 2B Method or Figure 2CThe method is used to generate a smaller comparison MAC, but it should be understood that if the method is used... Figure 2C In this method, authentication unit 60 will also need to generate a full-size MAC, for example, using Figure 2A The MAC function 100 allows the full-size MAC to be input into the encryption function 115.

[0066] Subsequently, at step 280, the read MAC and the MAC can be compared, and if a match is detected at step 285, authentication is considered to have passed at step 290; otherwise, authentication is considered to have failed at step 295.

[0067] If the corresponding reduced-size MAC does not exist in the on-chip cache, the full-size MAC needs to be read from untrusted memory at step 260. Subsequently, at step 265, a full-size comparison MAC is created from the read data block, for example using... Figure 2A The MAC function 100 is then used. The process then proceeds to step 280, where the previously described comparison procedure is performed to determine whether authentication has passed or failed.

[0068] In one exemplary embodiment, the authentication unit 60 may be provided with a comparison element to enable the comparison process of step 280 to be performed relative to both the reduced-size MAC and the full-size MAC. However, if desired, in an alternative embodiment, the comparison circuit may be configured to always perform the comparison relative to the reduced-size MAC. In this case, modifications can be made. Figure 5 Step 265, such as Figure 6 shown. Specifically, Figure 6 It shows that it can be executed to implement Figure 5 The sequence of steps 265 is such that once step 280 is reached, a smaller MAC is used during the comparison process.

[0069] At step 300, use Figure 2C The mechanism generates a reduced-size reference MAC based on the MAC of the full-size read obtained at step 260. Then, at step 305, a full-size comparison MAC is created from the read data block, for example using... Figure 2A The MAC function is 100.

[0070] Then, at step 310, use again Figure 2C The mechanism generates a reduced-size comparison MAC from the full-size comparison MAC generated at step 305.

[0071] Subsequently, as indicated in step 315, a reduced-size reference MAC and a reduced-size comparison MAC can be used to perform subsequent comparison operations, and therefore the same circuitry will be used to implement steps 280 to 295, whether by performing steps 270, 275 or by performing steps 260, 265 to reach step 280.

[0072] As previously mentioned, a reduced-size MAC can be generated from the data block associated with the reduced-size MAC or from the full-size MAC generated for that data block, for example, using... Figure 2B Method or Figure 2C The method. However, when using Figure 2C This method, and thus the generation of a reduced-size MAC from a full-size MAC, can have certain benefits when the full-size MAC is migrated from untrusted memory 40 to trusted storage device 65. Specifically, it is possible that a full-size MAC sequence is retrieved from untrusted memory at a certain point in time. For example, when reading a data block and therefore needing to obtain the corresponding MAC, it is possible that the corresponding MAC is stored in untrusted memory 40, and the granularity of the read allows for the retrieval of multiple MACs stored in untrusted memory 40 at that point in time, such as the MAC values ​​of cache lines. Therefore, in Figure 7 At step 350, it is possible that the full-size MAC sequence is read from an untrusted memory.

[0073] Although only one of these MACs will be associated with the current data block already read, it is appropriate at this point to seek a cache-equivalent, reduced-size MAC for each of these full-size MACs within the sequence read in step 350. If used Figure 2B This method, however, is only possible when reading each data block associated with the reduced-size MAC from memory. However, if... Figure 2C The method can directly generate a reduced-size MAC from the full-size MAC sequence read in step 350. Specifically, as indicated in step 355, a reduced-size MAC can be generated relative to each full-size MAC in the sequence. Figure 2C This mechanism generates corresponding reduced-size MACs without requiring the reading of the corresponding data block associated with each MAC. At step 360, the generated reduced-size MAC sequence can then be stored in an on-chip cache.

[0074] The authentication code generation circuitry provided as part of the authentication unit 60 can be implemented in various ways. For example, the circuitry for generating the full-size MAC can be completely separate from the circuitry for generating the reduced-size MAC. However, in alternative implementations, at least a portion of the circuitry can be shared. Figure 8A A specific example of this method is shown. In this implementation, it is carried out through a combination of hash functions and encryption functions. Figure 2A and Figure 2B Each of the MAC functions 100 and 105. While the encryption functions can remain separate, the hash functions can be shared. Therefore, hash function 400 can operate on the input data block using a provided input key to generate an intermediate value, also known as a hash value. This hash value can then be provided to encryption block 405, which is used as part of MAC function 100, and encryption block 410, which is used as part of MAC function 105. Encryption block 405 will receive a first secret key and any other appropriate input information, such as a physical address and a counter, and similarly, encryption block 410 will receive a second secret key and any other appropriate input information, such as a physical address and a counter.

[0075] Applying the encryption algorithm to cipher block 405 will result in the generation of a full-size MAC, while applying the encryption algorithm to cipher block 410 will result in the generation of a smaller MAC. From the previous discussion... Figure 2B It is evident that the truncation process can also be used to discard certain bits of the resulting MAC generated by encryption block 410 in order to produce a MAC with the desired reduced size.

[0076] Encryption blocks 405 and 410 can be organized in various ways, but... Figure 8B An exemplary arrangement is shown. Advanced Encryption Standard (AES) encryption block 420 can be used to generate an OTP using a secret key and a concatenation of a counter and a physical address. An XOR block 425 can then be used to perform an XOR function, which serves as input to the OTP generated by AES block 420 and the hash value output by hash function 400, resulting in the generation of a MAC. In the case of generating a smaller MAC using encryption block 410, it may be necessary to combine a truncation function relative to the output from XOR block 425 to generate a smaller MAC.

[0077] When using, such as Figure 8A and Figure 8B The arrangement shown allows for the generation of a reduced-size MAC from a full-size MAC without having to reread the MAC-related data block by alternatively referencing an intermediate hash value. Specifically, from Figure 8A It should be understood that the combination of hash function 400 and encryption block 410 can implement... Figure 2B The MAC function 105 generates a reduced-size MAC from the data block input to the hash function. However, if a full-size MAC has already been generated and a corresponding reduced-size MAC is expected at the appropriate time (e.g., because the MAC is being migrated from untrusted memory 40 to on-chip cache), a reduced-size MAC can be generated without rereading data from the untrusted memory. Figure 9 The process is illustrated below. At step 450, the full-size MAC is input, and then at step 455, the full-size MAC is decrypted to generate a hash value. This can be achieved by performing an XOR function using an OTP and the full-size MAC, where the output is then the hash value. Subsequently, at step 460, the hash value can be provided to encryption block 410 to generate a reduced-size MAC.

[0078] By using the techniques described herein, on-chip caches used to store MACs for verifying the integrity of data stored in untrusted memory 40 can be utilized more efficiently. Although a certain size of MACs is generated for storage in untrusted memory 40, different authentication code generation processes can be used to generate equivalent MACs if these MACs are to be stored within the on-chip cache, and these equivalent MACs can have a reduced size relative to the size of the MACs stored in untrusted memory 40. Therefore, for a given size of on-chip storage, more MACs can be stored compared to the case where the on-chip cache is only used to cache a subset of MACs stored in untrusted memory 40. Alternatively, if it is desired to be able to store a specific number of MACs on-chip, the size of the on-chip cache can be reduced because the MACs generated for on-chip storage have a reduced size relative to the MACs generated for storage in untrusted memory.

[0079] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operation.

[0080] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes, additions, and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, features of the dependent claims may be combined with features of the independent claims in various ways without departing from the scope of the invention.

Claims

1. An apparatus for controlling access to data stored in a non-trusted memory, the apparatus comprising: A memory access circuit, the memory access circuit being used to control access to data stored in the untrusted memory; A memory security circuit, wherein the memory security circuit is used to verify the integrity of data stored in the untrusted memory; as well as Trusted storage devices; The memory security circuit has an authentication code generation circuit to generate an authentication code to be associated with the data stored in the untrusted memory for use in verifying the integrity of the data; For a given data block for which an associated authentication code is to be generated, the authentication code generation circuit is arranged such that: when the associated authentication code is to be stored in the untrusted memory, a first authentication code of a first size is generated as the associated authentication code; and when the associated authentication code is to be stored in the trusted storage device, a second authentication code of a second size smaller than the first size is generated as the associated authentication code.

2. The apparatus according to claim 1, wherein: The device resides within a trust domain, while the untrusted memory is outside the trust domain; and The authentication code generation circuit is arranged to generate the second authentication code in a manner that ensures the second authentication code cannot be inferred from information residing outside the trust domain.

3. The apparatus according to claim 1 or claim 2, wherein: The authentication code generation circuit is arranged to employ an authentication code generation process that depends on which of the first and second authentication codes is being generated, to ensure that the second authentication code generated for the given data block cannot be inferred from the visibility of the first authentication code for the given data block.

4. The apparatus of claim 3, wherein the authentication code generation process depends on the input items of the confidential data, and the authentication code generation circuit is arranged such that when the first authentication code is generated, a first item of the confidential data is used, and when the second authentication code is generated, a second item of the confidential data is used, wherein the second item of the confidential data is different from the first item of the confidential data.

5. The apparatus of claim 1 or claim 2, wherein the authentication code generation circuit is arranged to generate the second authentication code by applying an algorithm that takes the given data block as an input.

6. The apparatus of claim 1 or claim 2, wherein the authentication code generation circuit is arranged to generate the second authentication code by applying an algorithm that takes the first authentication code as an input.

7. The apparatus of claim 1 or claim 2, wherein the authentication code generation circuit is arranged to generate the second authentication code by employing an algorithm for generating an intermediate authentication code having the first size, and then applying another process to generate the second authentication code having the second size from the intermediate authentication code.

8. The apparatus of claim 7, wherein the other process is a truncation process, such that the second authentication code is a truncated version of the intermediate authentication code.

9. The apparatus of claim 1 or claim 2, wherein the trusted storage device is organized as a cache to store a second authentication code for a subset of the data blocks stored in the untrusted memory.

10. The apparatus of claim 9, wherein when the second authentication code to be stored in the trusted storage device is generated, the authentication code generation circuit is arranged to also generate the first authentication code and store the generated first authentication code in the untrusted memory, such that when any second authentication code is evicted from the trusted storage device, the corresponding first authentication code exists in the untrusted memory.

11. The apparatus of claim 9, wherein when generating the second authentication code to be stored in the trusted storage device, the authentication code generation circuit is arranged not to store the first authentication code in the untrusted memory, and when any second authentication code is evicted from the trusted storage device, the authentication code generation circuit is arranged to generate a corresponding first authentication code to be stored in the untrusted memory.

12. The apparatus according to claim 1 or claim 2, wherein: When a data block is read from the untrusted memory, the memory security circuit is configured to determine whether the associated authentication code is stored as a second authentication code in the trusted storage device, and if so, to use the second authentication code in the trusted storage device to verify the integrity of the read data block.

13. The apparatus according to claim 1 or claim 2, wherein: When a data block is read from the untrusted memory and it is determined that the associated authentication code is not stored as a second authentication code in the trusted storage device, the memory security circuit is arranged to: retrieve the first authentication code from the untrusted memory and use the retrieved first authentication code when verifying the integrity of the read data block.

14. The apparatus according to claim 13, wherein: The memory security circuit is arranged to employ the authentication code generation circuit to: A second code generation algorithm is applied to generate a reference second authentication code from the retrieved first authentication code; as well as The comparison first authentication code is generated first from the read data block, and then the comparison first authentication code is used to apply the second code generation algorithm to generate the comparison second authentication code; The memory security circuitry is configured to verify the integrity of the read data block by comparing the reference second authentication code with the comparison second authentication code.

15. The apparatus according to claim 1 or claim 2, wherein: The authentication code generation circuit is arranged to generate the second authentication code by applying an algorithm that uses the first authentication code as an input; and The authentication code generation circuit responds to the first authentication code retrieved from the untrusted memory to generate a corresponding second authentication code for storage in the trusted storage device, without referencing the associated data block.

16. The apparatus according to claim 1 or claim 2, wherein: The authentication code generation circuit is arranged to apply a first process to generate the first authentication code and apply a second process to generate the second authentication code, wherein the first process and the second process share a common initial portion.

17. The apparatus according to claim 16, wherein: The common initialization portion includes performing a hash function on the data block using the input key to produce an intermediate value; The authentication code generation circuit is arranged to encrypt the intermediate value using first confidential data to generate the first authentication code to complete the first process. and The authentication code generation circuit is configured to complete the second process by encrypting the intermediate value using second confidential data to generate the second authentication code.

18. The apparatus according to claim 17, wherein: The authentication code generation circuit is arranged to generate the second authentication code by applying an algorithm that uses the first authentication code as an input; and The authentication code generation circuit, in response to the first authentication code retrieved from the untrusted memory, generates a corresponding second authentication code for storage in the trusted storage device, without referencing the associated data block. The authentication code generation circuit is configured to generate the second authentication code by: decrypting the first authentication code using the first confidential data to generate the intermediate value, and then encrypting the intermediate value using the second confidential data to generate the second authentication code.

19. A method for controlling access to data stored in an untrusted memory, the method comprising: An authentication code generation circuit is used to generate an authentication code to be associated with the data stored in the untrusted memory; Refer to the authentication code to verify the integrity of the data; Provide trusted storage devices; as well as For a given data block for which an associated authentication code is to be generated, the authentication code generation circuit is arranged such that: when the associated authentication code is to be stored in the untrusted memory, a first authentication code of a first size is generated as the associated authentication code; and when the associated authentication code is to be stored in the trusted storage device, a second authentication code of a second size smaller than the first size is generated as the associated authentication code.

20. An apparatus for controlling access to data stored in a non-trusted memory, the apparatus comprising: A memory access device for controlling access to data stored in the untrusted memory; A memory security device for verifying the integrity of data stored in the untrusted memory; as well as Trusted storage devices; The memory security device includes an authentication code generation device for generating an authentication code to be associated with the data stored in the untrusted memory for use in verifying the integrity of the data; The authentication code generation device, in response to a given data block for which an associated authentication code is to be generated, is configured to generate a first authentication code of a first size as the associated authentication code when the associated authentication code is to be stored in the untrusted memory, and to generate a second authentication code of a second size smaller than the first size as the associated authentication code when the associated authentication code is to be stored in the trusted memory.

Images