Method, microcontroller and system-on-chip device for cryptographic operations

By introducing a key cache and an XOR logic module into the serial interface, the problem of key duplication in existing technologies is solved, improving the efficiency of cryptographic operations and the functionality of the system.

CN122197040APending Publication Date: 2026-06-12INFINEON TECHNOLOGIES AMERICAS CORP

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
INFINEON TECHNOLOGIES AMERICAS CORP
Filing Date
2025-11-26
Publication Date
2026-06-12

AI Technical Summary

Technical Problem

The existing serial interface (SMIF) cannot effectively support cryptographic operations, especially in XIP mode, resulting in repeated calculation of the computing key, wasted resources, and inefficient operations.

Method used

By introducing a key cache and an XOR logic module, the computation key is stored and a new key is generated when necessary, thus avoiding redundant calculations and improving the efficiency of cryptographic operations.

Benefits of technology

It enables the reuse of computation keys, improves the efficiency of cryptographic operations, and supports efficient decryption operations in XIP mode.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122197040A_ABST
    Figure CN122197040A_ABST
Patent Text Reader

Abstract

The present disclosure provides methods, microcontrollers, and system-on-a-chip devices for cryptographic operations. A memory address corresponding to encrypted data transmitted via a serial memory interface (SMIF) is determined by a processing device to be within a range of memory addresses corresponding to a computational key stored in a key cache. In response to determining that the memory address is within the range of memory addresses corresponding to the computational key, an exclusive-OR (XOR) operation is performed on the encrypted data and the computational key to generate plaintext corresponding to the encrypted data.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure generally relates to the field of cryptography, and more specifically to key caches for supporting cryptographic operations associated with a Serial Memory Interface (SMIF). Background Technology

[0002] Serial communication refers to communication that transmits information sequentially, one bit at a time. A Serial Memory Interface (SMIF) can refer to a versatile hardware block that implements serial communication. For example, an SMIF can implement Serial Peripheral Interface (SPI) communication to external serial memory devices such as NOR (NOT-OR) flash memory, static random access memory (SRAM), and non-volatile SRAM. SPI is a standard (with many variations) for synchronous serial communication, primarily used for short-distance wired communication between integrated circuits in embedded systems.

[0003] Some SMIFs can support Execute-in-In-Memory (XIP) access. XIP refers to the method of executing a program directly through long-term storage instead of copying it into RAM. This is an extension of using shared memory and is designed to reduce the total amount of memory required. The overall effect of XIP is that the program text does not occupy writable memory, saving it for dynamic data, and all instances of the program run from a single copy. Summary of the Invention

[0004] According to one aspect of this disclosure, a method for cryptographic operations is provided. The method includes: determining, by a processing device, that a memory address corresponding to encrypted data transmitted via a Serial Memory Interface (SMIF) falls within a memory address range corresponding to a computational key stored in a key cache; and, in response to determining that the memory address falls within the memory address range, performing an XOR operation on the encrypted data and the computational key to generate plaintext corresponding to the encrypted data.

[0005] According to another aspect of this disclosure, a microcontroller is provided. The microcontroller includes: a cache; and a processing device coupled to the cache, the processing device being configured to: determine that a memory address corresponding to encrypted data transmitted via the SMIF is within a memory address range corresponding to a computation key stored in the cache; and, in response to determining that the memory address is within the memory address range, perform an XOR operation on the encrypted data and the computation key to generate plaintext corresponding to the encrypted data.

[0006] According to another aspect of this disclosure, a system-on-a-chip (SOC) device is provided. The SOC device includes: a hardware cache; and a serial memory interface (SMIF) configured to: determine that a memory address corresponding to encrypted data transmitted via the SMIF is within a memory address range corresponding to a computation key stored in the hardware cache; and, in response to determining that the memory address is within the memory address range, perform an XOR operation on the encrypted data and the computation key to generate plaintext corresponding to the encrypted data. Attached Figure Description

[0007] To facilitate the identification of any particular element or action in the discussion, one or more of the most significant digits in the figure references refer to the figure number in which the element was first introduced.

[0008] Figure 1 Exemplary aspects of a computing device according to some embodiments of the present disclosure are shown.

[0009] Figure 2 Various aspects of generating computation keys according to some embodiments of this disclosure are shown.

[0010] Figure 3 Various aspects of the input data for generating computation keys according to some embodiments of this disclosure are shown.

[0011] Figure 4 Various aspects of supporting cryptographic operations associated with SMIF are illustrated in some implementations of this disclosure.

[0012] Figure 5 Exemplary logic flows for supporting cryptographic operations associated with SMIF, according to some embodiments of this disclosure, are shown. Detailed Implementation

[0013] The following description sets forth numerous specific details, such as examples of specific systems, components, methods, etc., to provide a good understanding of the various implementations of the techniques described herein for supporting cryptographic operations associated with SMIF. However, it will be apparent to those skilled in the art that at least some implementations can be practiced without these specific details. In other instances, well-known components, elements, or methods have not been described in detail or presented in a simple block diagram format to avoid unnecessarily obscuring the techniques described herein. Therefore, the specific details set forth below are merely exemplary. Specific implementations may differ from these exemplary details and are still considered to be within the scope of this disclosure.

[0014] Existing serial interfaces, such as SMIF, cannot efficiently support cryptographic operations, such as those used for XIP. Even if the same key can be used to decode multiple bytes of data, it may still be necessary to recalculate the key for each byte of data, resulting in excessive and unnecessary computation. For example, block ciphers can be used to generate computation keys for each memory address accessed byte-by-byte (e.g., based on byte-by-byte instructions); however, these computation keys may be valid for a range of memory addresses. This leads to inefficient operation because resources are consumed to compute the same key for each memory address in the range. These challenges and complexities often stem from the fact that existing systems cannot efficiently support cryptographic operations with sufficient or desired memory resources. For example, existing systems may not include available or practical (e.g., secure, low-latency, etc.) memory (e.g., hardware cache) to facilitate the reuse of computation keys across a range of memory addresses. These limitations significantly reduce the usability of existing systems with serial interfaces, resulting in system, device, and technical inefficiencies and functional limitations.

[0015] Implementations of this disclosure address the aforementioned and other problems by including a key cache and logic for preventing the computation key from being recalculated while it is still usable. In some implementations, these techniques can be used to reduce the number of times ciphertext (e.g., computation keys) is generated for performing dynamic decryption. In many implementations, the cache may include a hardware cache configured to store the computation key to enable more efficient plaintext generation. For example, the computation key may remain the same for a range of memory addresses. Therefore, the implementations disclosed herein may include a key cache for storing the computation key, and logic for reusing the computation key for each memory address in a range of memory addresses instead of recalculating it. In other words, the computation key can be generated only once for the entire set of memory addresses that can be decrypted using the computation key.

[0016] In these and other ways, the components / techniques described herein can provide numerous technical advantages. For example, implementations can improve the efficiency of cryptographic operations such as decryption by enabling the reuse of computation keys. In another example, implementations can enable cryptographic operations when accessing memory based on byte-by-byte instructions. In yet another example, implementations can provide support for cryptographic operations in XIP operation mode. Therefore, the computer-based techniques of this disclosure improve cryptographic operations associated with serial interfaces compared to conventional methods. Furthermore, the implementations disclosed herein can be practically used to improve computer functionality and / or improve various technical fields including cryptography, serial communication, XIP, and memory devices.

[0017] The illustrative examples and embodiments provided above are intended to introduce the general subject matter discussed herein and are not intended to limit the scope of the disclosed concepts. Various additional features and examples are described below with reference to the accompanying drawings, in which the same reference numerals indicate the same elements, but as with the illustrative examples, are not intended to limit the scope of this disclosure.

[0018] Figure 1 Exemplary aspects of a computing device 102 according to some embodiments are shown. In the illustrated embodiment, the computing device 102 includes an SMIF 104, a memory 106, a cache 108, an XOR logic module 120, an encryption manager 110 with a block cipher module 122, a memory 126, and a processing device 128. The illustrated components of the computing device 102 are interoperable to support efficient cryptographic operations associated with data stored in the memory 106 and accessed via the SMIF 104. Figure 1 One or more components may be identical or similar to one or more other components disclosed herein. Furthermore, without departing from the scope of this disclosure, regarding... Figure 1 The aspects discussed in the various components can be implemented by one or more other components in one or more other embodiments. For example, without departing from the scope of this disclosure, one or more components of computing device 102 (such as cache 108, encryption manager 110, XOR logic module 120 and / or block cipher module 122) may be included in SMIF 104 and / or processing device 128. In this context, the implementation is not limited.

[0019] According to the embodiments described herein, computing device 102 can utilize cache 108 to perform cryptographic operations in a more efficient manner, such as by generating plaintext 124 more efficiently. Cache 108 may include a hardware cache configured to store computation keys to enable more efficient plaintext generation. In various embodiments, computation key 118 may include ciphertext that can be XORed with corresponding encrypted data to generate plaintext. For example, a cryptographic operation can be initiated to convert encrypted data 114 in memory 106 into plaintext 124. In some embodiments, this operation may be performed as part of XIP access via SMIF 104, such as on-the-fly decryption. As part of this operation, encryption manager 110 may determine whether the memory address of encrypted data 114 is included in the memory address range corresponding to computation key 118. More generally, encryption manager 110 may include logic (e.g., in a processing device) to determine whether the computation key stored in cache 108 can be used to decrypt encrypted data 114 (e.g., via XOR logic module 120) and whether a new computation key needs to be generated.

[0020] In some implementations, the encryption manager 110 can determine, based on the input data 116, whether the memory address of the encrypted data 114 is included in the memory address range corresponding to the computation key 118. For example, as will be discussed in more detail below, such as regarding... Figure 3 Input data 116 may include data corresponding to the memory address of encrypted data 114. In many embodiments, encryption manager 110 may compare the memory address (e.g., SMIF address) or a portion thereof of encrypted data 114 with data indicating a range of memory addresses corresponding to computation key 118. In various embodiments, encryption manager 110 or another component may cause data indicating a range of memory addresses corresponding to computation key 118 to be stored. For example, in one embodiment, data indicating a range of memory addresses corresponding to computation key 118 may be stored in cache 108.

[0021] If the memory address of the encrypted data 114 is within the memory address range corresponding to the computation key 118, the encryption manager 110 can cause the XOR logic module 120 to perform an XOR operation on the computation key 118 and the encrypted data 114 to generate plaintext 124. However, if the memory address of the encrypted data 114 is not within the memory address range, the encryption manager 110 can cause the block cipher module 122 to generate a new computation key and store it as computation key 118 in the cache 108. Each new computation key can be generated by the block cipher module 122 based on the input data 116 and the private key 112. The new computation key can be stored as computation key 118 in the cache 108. Subsequently, the encryption manager 110 can cause the XOR logic module 120 to perform an XOR operation on the new computation key 118 and the encrypted data 114 to generate plaintext 124. This process can be repeated as needed to access the encrypted data stored in the memory 106.

[0022] In various implementations, block cipher module 122 may include a symmetric key algorithm. In various such implementations, the symmetric key algorithm may operate on a 128-bit data block (e.g., input data 116) using a 128-bit, 192-bit, or 256-bit cryptographic key (e.g., private key 112) to generate a 128-bit output data block (e.g., computation key 118). In some implementations, the symmetric key algorithm may include or utilize the Advanced Encryption Standard (AES). Therefore, block cipher module 122 may include an AES-128 forward block cipher module.

[0023] Memory 106 may be communicatively coupled to other components of computing device 102 via SMIF 104. More generally, SMIF 104 may implement at least some instances of serial communication within computing device 102. For example, memory 106 may include a serial memory device, such as dynamic random access memory (DRAM), and SMIF 104 may implement a serial peripheral interface (SPI) communication with memory 106. Thus, in many embodiments, memory 106 may include or refer to memory accessed by computing device 102 via SMIF 104. On the other hand, memory 126 may refer to memory of computing device 102 that is not accessed via SMIF 104. In some embodiments, memory 106 may refer to external memory, and memory 126 may refer to internal memory. In some embodiments, one or more of the components of computing device 102 shown (such as components for implementing the techniques disclosed herein) may be included in a memory or interface device such as an SMIF. In some such embodiments, the memory or interface device may be included in a larger computing device or system, such as a microcontroller unit or system-on-a-chip.

[0024] It should be noted that, for simplicity or clarity, various components may be described and shown individually; however, one or more of these components may be combined or shared without departing from the scope of this disclosure. For example, although a single processing device is depicted in computing device 102 for simplicity, other embodiments may include multiple processing devices, storage devices, or other components. For example, SMIF 104, XOR logic module 120, or block cipher module 122 may include separate processing devices that implement various aspects of the techniques described herein. Processing device 128 and / or other processing devices may include Complex Instruction Set Computing (CISC) microprocessors, Reduced Instruction Set Computing (RISC) microprocessors, Very Long Instruction Word (VLIW) microprocessors, processors implementing other instruction sets, or processors implementing combinations of instruction sets. In many embodiments, processing device 128 and / or other processing devices may also include one or more dedicated processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, system-on-a-chip (SoCs), microcontrollers, etc.

[0025] Figure 2 Various aspects of generating a computational key 216 according to some embodiments are illustrated. The illustrated embodiments include one or more input caches 202, one or more private key caches 204, one or more computational key caches 206, and a block cipher module 208. The block cipher module 208 can generate the computational key 216 based on the contents of one or more input caches 202 and one or more private key caches 204. The computational key 216 can be stored in one or more computational key caches 206 for subsequent efficient cryptographic operations on memory accessed via a serial interface such as SMIF. Figure 2 One or more components may be identical or similar to one or more other components disclosed herein. For example, the computation key cache 206 may be identical or similar to cache 108. In another example, block cipher module 208 may be identical or similar to block cipher module 122. In yet another example, input data 116 may be identical or similar to input data 210. Furthermore, without departing from the scope of this disclosure, regarding Figure 2 The various components discussed herein can be implemented by one or more other components in one or more other embodiments. For example, the input cache 202, private key cache 204, computation key cache 206, and / or block cipher module 208 can be implemented by computing device 102 without departing from the scope of this disclosure. In this context, the implementation is not limited.

[0026] As previously described, the technique thus described achieves more efficient cryptographic operations. This is achieved, at least in part, by including a computation key cache 206. More specifically, the computation key cache 206 can be used to prevent, for example, recalculating the key for each memory address when the CPU generates instructions byte by byte, thereby achieving more efficient cryptographic operations. For instance, multiple memory addresses may utilize the same computation key, and the computation key cache 206 can be used to store that same computation key and reuse it for each of the multiple memory addresses. In contrast, existing systems recalculate the same computation key for each access to a memory address among multiple memory addresses for which the computation key is valid.

[0027] In many implementations, the computation key cache 206 includes a hardware cache. In many such implementations, the hardware cache may be included in a dynamic random access memory device. It should be understood that, for simplicity, each of caches 202, 204, and 206 is generally referred to in the singular, although it may be implemented as multiple caches. For example, input cache 202 may store 16 bytes of data in four separate four-byte caches. In another example, computation key cache 206 may store 16 bytes of data in four separate four-byte hardware caches. In one implementation, computation key cache 206 may include an indication of the effective memory address range of computation key 216.

[0028] The block cipher module 208 can generate a computation key 216 using the contents of the input cache 202 and the private key cache 204. For example, the input data 210 may include Encrypted Data Memory Address Information (EDMAI) 212. EDMAI 212 may include the memory address of the data to be decrypted (e.g., encrypted data 114). In some implementations, EDMAI 212 can be used to determine whether a new computation key needs to be generated. As discussed in more detail below, for example regarding... Figure 4 The computation key 216 can be generated using only a portion of EDMAI 212. This portion of EDMAI 212 can correspond to the address range for the computation key 216. For example, the portion of EDMAI 212 used by the block cipher module 208 to generate the computation key 216 may include n most significant bits of a memory address, while i least significant bits are ignored (e.g., for a 32-bit address, i = 4 and n = 28). Therefore, the memory address range corresponding to the n most significant bits can indicate the memory address range for which the corresponding computation key is valid.

[0029] In some embodiments, block cipher module 208 may include a symmetric key algorithm that computes a computation key 216 based on input data 210 and a private key 214. In various such embodiments, the symmetric key algorithm may operate on a 128-bit input data block (e.g., input data 210) using a 128-bit, 192-bit, or 256-bit cryptographic key (e.g., private key 214) to generate a 128-bit computation key data block (e.g., computation key 216). In various embodiments, computation key 216 may include ciphertext that can be XORed with corresponding encrypted data to generate plaintext. In some embodiments, the symmetric key algorithm may include or utilize the Advanced Encryption Standard (AES). In some such embodiments, block cipher module 208 may include an AES-128 forward block cipher module.

[0030] Figure 3 Various aspects of input data 304 for generating a computation key, according to some embodiments, are illustrated. The illustrated embodiments include input caches 302a, 302b, 302c, and 302d (collectively referred to as input cache 302). A first input cache 302a includes fixed data 306a, a second input cache 302b includes fixed data 306b, a third input cache 302c includes fixed data 306c, and a fourth input cache 302d includes Encrypted Data Memory Address Information (EDMAI) 308. The data in the input caches 302 collectively form input data 304, including address bits 314 and extended address bits 312. As previously described, input data 304 can be used with a cryptographic key to generate a computation key, which can be XORed with corresponding encrypted data to generate plaintext. Figure 3 One or more components may be identical or similar to one or more other components disclosed herein. For example, input cache 302 may be identical or similar to input cache 202. In another example, input data 304 may be identical or similar to input data 116. Furthermore, without departing from the scope of this disclosure, regarding Figure 3 The aspects discussed in the various components can be implemented by one or more other components in one or more other embodiments. In this context, the embodiments are not limited.

[0031] Although other sizes are possible without departing from the scope of this disclosure, the description pertains to input data 304, which may include 128 bits or 16 bytes. Figure 3Furthermore, each of the input caches 302 stores 4 bytes. In some implementations, the contents of the input caches 302 can be concatenated to create input data 304. Therefore, the input data 304 comprises four blocks of 4 bytes (or 32 bits). The first block corresponds to the contents of input cache 302d and includes bits [31:0] of the input data 304; the second block corresponds to the contents of input cache 302c and includes bits [63:32] of the input data 304; the third block corresponds to the contents of input cache 302b and includes bits [95:64] of the input data 304; and the fourth block corresponds to the contents of the first input cache 302a and includes bits [127:96] of the input data 304. Therefore, the 12 most significant bytes can include fixed data, and the 4 least significant bytes can include memory address information for encrypting the data.

[0032] The second, third, and fourth blocks of input data 304 include fixed data. This fixed data can be used to configure cryptographic blocks, select modes, ensure appropriate block sizes, etc. For example, input data 304 may include padding to ensure that the input to the block cipher module is a 16-byte random value. The first block of input data 304 includes EDMAI 308 (e.g., address information). In various embodiments, the address information may include the memory address of the encrypted data to be decrypted. The address information in input data 304 includes address bits 314 and extended address bits 312. Address bits 314 may be used to generate a computation key, but extended address bits 312 may not be used to generate a computation key. Therefore, for each memory address including address bits 314, the computation key may be the same.

[0033] In many implementations, address bit 314 and extended address bit 312 may include or indicate the entire memory address for the encrypted data (e.g., the address of encrypted data 114 in memory 106). Furthermore, since the computation key is identical for all values ​​of extended address bit 312, address bit 314 may indicate a range of memory addresses for which the computation key is valid and can be used to decrypt data. For example, if the CPU attempts to read from addresses 0x80000000 to 0x800000FF, the block cipher module uses 0x800000 to generate the computation key, ensuring that the computation key is identical for 0x80000000 to 0x800000FF. In various implementations, the 28 most significant bits of the memory address information for the encrypted data may be used to generate the computation key and / or to determine whether the memory address corresponding to the encrypted data is within the memory address range corresponding to the computation key. In many implementations, determining whether the memory address corresponding to the encrypted data is within the range of memory addresses corresponding to the computation key and / or whether a new computation key needs to be generated can be achieved via logic circuitry, such as logic circuitry included in the processing device.

[0034] Figure 4 Various aspects of supporting cryptographic operations associated with SMIF are illustrated according to some embodiments. The illustrated embodiments include a forward block cipher module 402, a first XOR gate 404a, a second XOR gate 404b, and data input / output terminals including a computation key 406, a private key 408, input data 410, encrypted read data 412, encrypted write data 414, decrypted read data 416, and decrypted write data 418. In various embodiments, these components and data input / output terminals can be used to generate the computation key 406, the decrypted read data 416, and / or the encrypted write data 414. Figure 4 One or more components may be identical or similar to one or more other components disclosed herein. For example, forward block cipher module 402 may be identical or similar to block cipher module 208. In another example, input data 410 may be identical or similar to input data 210. Furthermore, without departing from the scope of this disclosure, regarding Figure 4 The aspects discussed in the various components can be implemented by one or more other components in one or more other embodiments. For example, encrypted read data 412 can be received from memory 106 via SMIF 104 without departing from the scope of this disclosure. In another embodiment, computation key 406 can be received from cache 108 without departing from the scope of this disclosure. In this context, the embodiments are not limited.

[0035] In various embodiments, the forward block cipher module 402 can generate the computation key 406 based on the private key 408 and the input data 410. For example, the forward block cipher module 402 may include an AES-128 forward block cipher module that takes the private key 408 as a 128-bit block and the input data 410 as a 128-bit block as input to the cryptographic algorithm that outputs the computation key 406. In various embodiments, the computation key 406 may be stored in a cache such as a hardware cache.

[0036] In many embodiments, decrypted read data 416 can be generated by passing the computation key 406 and encrypted read data 412 through an XOR gate 404a. For example, when it is determined that the computation key 406 corresponds to encrypted read data 412, the computation key 406 and encrypted read data 412 can be XORed via XOR gate 404a to generate decrypted read data 416. In some embodiments, the decrypted read data 416 can be further processed, for example, by a CPU. In some embodiments, encrypted write data 414 can be generated by passing the computation key 406 and decrypted write data 418 through an XOR gate 404b.

[0037] It should be understood that, Figure 4 The layout and configuration of the components are exemplary, and various alternative layouts and configurations may be utilized without departing from the scope of this disclosure. For example, some configurations may utilize a single XOR gate.

[0038] Figure 5 A logical flow 500 for supporting cryptographic operations associated with an SMIF, according to some embodiments, is illustrated. The logical flow 500 can be executed by processing logic, which may include hardware and / or control logic (e.g., circuitry, dedicated logic, programmable logic, processor, processing device, central processing unit (CPU), system-on-a-chip (SoC), etc.), software (e.g., instructions that run / execute on the processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, at least a portion of the logical flow 500 may be executed by one or more components of computing device 102, SMIF 104, block cipher module 122, XOR logic module 120, encryption manager 110, and / or processing device 128. In this context, the embodiments are not limited.

[0039] Reference Figure 5The logic flow 500 illustrates example functions used by various implementations. Although specific functional blocks (“blocks”) are disclosed in the logic flow 500, such blocks are illustrative. That is, the implementation is well-suited to executing the various other blocks or variations thereof set forth in the logic flow 500. It should be understood that blocks in the logic flow 500 may be executed in a different order than presented, and not all blocks in the logic flow 500 may be executed.

[0040] Logic flow 500 begins at start block 502. From start block 502, logic flow 500 proceeds to decision block 504, where it is determined whether the memory address of the encrypted data is within the memory address range of the computation key. For example, encryption manager 110 may determine whether the memory address of encrypted data 114 is within the memory address range corresponding to computation key 118. In some implementations, as previously described, this determination may be based on input data 116. For example, the memory address of encrypted data 114, or a portion thereof, included in input data 116, may be compared with data indicating the memory address range corresponding to computation key 118.

[0041] If the memory address of the encrypted data is not within the memory address range of the computation key, logic flow 500 proceeds to block 506. A new computation key is generated at block 506. For example, block cipher module 208 can generate computation key 216 based on private key 214 and input data 210 corresponding to the encrypted data. Proceeding to block 508, the new computation key can be stored in a key cache. For example, the new computation key can replace a previous computation key, such as computation key 118 in cache 108.

[0042] Next, logic flow 500 proceeds to block 510. Additionally, it returns to decision block 504; if the memory address of the encrypted data is within the memory address range of the computation key, logic flow 500 proceeds to block 510. At block 510, the encrypted data can be XORed with the computation key in the key cache to generate plaintext. For example, XOR gate 404a can be used to XOR the computation key 406 and the encrypted read data 412 to generate the decrypted read data 416.

[0043] In the above description, some parts are presented in detail based on the algorithms and symbolic representations of operations on analog and / or digital signals or data bits within non-transitory storage media. These algorithmic descriptions and representations are the most effective means by which those skilled in the art of data processing communicate the substance of their work to others skilled in the art. Here, an algorithm is generally considered to be a self-consistent sequence of steps that produces a desired result. These steps are those that require physical manipulation of physical quantities. Typically, although not always necessary, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient, primarily for common use, to sometimes refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0044] References to "implementation," "one implementation," "example implementation," "some implementations," "various implementations," etc., in the specification mean that a specific feature, structure, step, operation, or characteristic described in connection with the implementation is included in at least one implementation of this disclosure. Furthermore, the appearance of the phrases "implementation," "one implementation," "example implementation," "some implementations," "various implementations," etc., in different positions in the specification does not necessarily refer to the same implementation.

[0045] This specification includes references to the accompanying drawings, which form part of the detailed description. The drawings illustrate a description according to exemplary embodiments. These embodiments are described in sufficient detail, and may also be referred to herein as "examples" to enable those skilled in the art to practice embodiments of the claimed subject matter described herein. Embodiments may be combined, other embodiments may be utilized, or structural, logical, and electrical changes may be made without departing from the scope and spirit of the claimed subject matter. It should be understood that the embodiments described herein are not intended to limit the scope of the subject matter, but rather to enable those skilled in the art to practice, make, and / or use the subject matter.

[0046] However, it should be remembered that all these terms and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise specifically stated, it is evident from the above discussion that throughout the specification, discussions using terms such as “determine,” “execute,” “calculate,” and “store” refer to the actions and processing of a processing device, integrated circuit (IC) controller, or similar electronic device that manipulates data represented as physical (e.g., electronic) quantities in the controller’s registers and memory and converts it into other data similarly represented as physical quantities in the controller’s memory or registers or other non-transitory information storage media.

[0047] The terms “example” or “exemplary” are used herein to mean as an example, instance, or illustration. Any aspect or design described herein as an “example” or “exemplary” should not be construed as superior or better than other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present the concept in a specific manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise stated or clearly understood from the context, “X comprises at least one of A or B” or “X comprises A or B” is intended to mean any natural inclusion arrangement. That is, if X comprises A; X comprises B; or X comprises both A and B, then in any of the foregoing cases, “X comprises at least one of A or B” or “X comprises A or B” is satisfied. Similarly, “X comprises one or more of A and B” should be interpreted as the same as “X comprises at least one of A or B.” Furthermore, unless otherwise stated or clearly indicated by the context to be a singular form, the articles “a” and “an” used herein and in the appended claims should generally be interpreted as meaning “one or more.” Furthermore, the use of the terms "implementation method" or "one implementation method" throughout the text is not intended to refer to the same implementation method unless described as such.

[0048] The embodiments described herein may also relate to means for performing the operations described herein (e.g., wireless communication devices including at least one of a terminal device, client device, station (STA), access point, router, or coordinator). The means may be specifically configured for the desired purpose or may include firmware or hardware logic selectively activated or reconfigured by the means. Such firmware may be stored in a non-transitory computer-readable storage medium such as, but not limited to, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, flash memory, or any type of medium suitable for storing electronic instructions. The term "computer-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "computer-readable medium" should also be considered to include any medium capable of storing, encoding, or carrying a set of instructions executable by a machine and enabling the machine to perform any one or more methods of this embodiment. Therefore, the term "computer-readable storage medium" should be considered to include, but is not limited to, solid-state memory, optical media, magnetic media, and any medium capable of storing a set of instructions executable by a machine and enabling the machine to perform any one or more methods of this embodiment. Furthermore, "computer-readable medium" or "computer-readable storage medium" may be non-transitory.

[0049] The foregoing description sets forth numerous specific details, such as examples of specific systems, components, methods, etc., to provide a good understanding of several embodiments of this disclosure. It should be understood that the foregoing description is intended to be illustrative and not restrictive. Many other embodiments will become apparent to those skilled in the art upon reading and understanding the foregoing description. Therefore, the scope of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A method for cryptographic operations, comprising: The processing device determines that the memory address corresponding to the encrypted data transmitted via the serial memory interface SMIF is within the memory address range corresponding to the computation key stored in the key cache; as well as In response to determining that the memory address is within the memory address range, an XOR operation is performed on the encrypted data and the computation key to generate plaintext corresponding to the encrypted data.

2. The method according to claim 1, wherein, The key cache includes a hardware cache.

3. The method according to claim 2, wherein, The hardware cache is contained in a dynamic random access memory chip.

4. The method according to claim 1, wherein, The encrypted data is transmitted via the SMIF as part of the on-site execution of XIP operations.

5. The method according to claim 1, wherein, The computation key includes ciphertext.

6. The method according to claim 1, wherein, The memory address range includes 16 bytes of memory.

7. The method according to claim 1, wherein, The computation key is calculated based on a symmetric key algorithm.

8. The method according to claim 7, wherein, The symmetric key algorithm includes the Advanced Cryptography Standard algorithm.

9. The method according to claim 1, wherein, The memory address includes a first memory address, the encrypted data includes first encrypted data, the calculation key includes a first calculation key, and the method further includes: The second memory address corresponding to the second encrypted data transmitted via the SMIF is determined to be outside the memory address range corresponding to the first computation key stored in the key cache; A second key is calculated based on the second encrypted data to generate a second computation key; and The second computation key is stored in the key cache.

10. A microcontroller, comprising: Cache; as well as A processing device coupled to the cache, the processing device being configured to: The memory address corresponding to the encrypted data transmitted via the serial memory interface SMIF is determined to be within the memory address range corresponding to the computation key stored in the cache; as well as In response to determining that the memory address is within the memory address range, an XOR operation is performed on the encrypted data and the computation key to generate plaintext corresponding to the encrypted data.

11. The microcontroller of claim 10, wherein, The cache includes a hardware cache.

12. The microcontroller of claim 11, wherein, The hardware cache is contained in a dynamic random access memory chip.

13. The microcontroller of claim 10, wherein, The encrypted data is transmitted via the SMIF as part of the on-site execution of XIP operations.

14. The microcontroller of claim 10, wherein, The computation key includes ciphertext.

15. The microcontroller of claim 10, wherein, The memory address range includes 16 bytes of memory.

16. The microcontroller of claim 10, wherein, The computation key is calculated based on a symmetric key algorithm.

17. The microcontroller of claim 16, wherein, The symmetric key algorithm includes the Advanced Cryptography Standard algorithm.

18. A system-on-a-chip (SoC) device, comprising: Hardware cache; as well as The serial memory interface SMIF is configured as follows: The memory address corresponding to the encrypted data transmitted via the SMIF is determined to be within the memory address range corresponding to the computation key stored in the hardware cache; as well as In response to determining that the memory address is within the memory address range, an XOR operation is performed on the encrypted data and the computation key to generate plaintext corresponding to the encrypted data.

19. The SOC device according to claim 18, wherein, The computation key is calculated based on a symmetric key algorithm.

20. The SOC device according to claim 18, wherein, The hardware cache is contained in a dynamic random access memory chip.