Storage security component, system on chip, embedded system and code calling method
By setting up an encrypted user area and processing unit control mechanism in the embedded system, the problem of code theft in multi-user development programs is solved, and code confidentiality and security are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-17
- Publication Date
- 2026-03-24
AI Technical Summary
In existing technologies, embedded program code developed by multiple users cannot be kept confidential from each other, posing a significant risk of theft.
By employing storage security components, multiple user areas are set up in the storage unit and the encryption mechanism is controlled by the processing unit. This ensures that a user area only responds to the function call instructions of its own user and does not respond to data access requests. Furthermore, the code is protected from being stolen through key and verification mechanisms.
It ensures the confidentiality of code in each user area of a multi-user development program, preventing code theft and tampering, and ensuring information security.
Smart Images

Figure CN114580036B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information security, and in particular to a storage security component, a system-on-a-chip, an embedded system, and a code calling method. Background Technology
[0002] With the rapid development of embedded technology and the Internet of Things, more and more embedded products are being launched into the market. Among these numerous embedded products, many involve multi-user program development.
[0003] For programs developed by multiple users, it's crucial to ensure that the code developed by different users doesn't get stolen by other users while simultaneously allowing the code to call each other. Currently, most similar products on the market only support collaborative development by multiple users; however, it's impossible to guarantee the confidentiality of the code developed by different users, resulting in a significant risk of code theft. Summary of the Invention
[0004] In view of the above problems, the present invention provides a storage security component, a system-on-a-chip, an embedded system, and a code calling method, aiming to solve the problem of code theft in multi-user development programs.
[0005] According to a first aspect of the present invention, a storage security component is provided, comprising:
[0006] The storage unit includes a code area, which comprises multiple user areas, each user area being used to store code developed by a user.
[0007] The processing unit is configured to, when a user area is configured to be encrypted, control the user area to respond to function call instructions when executing code stored in other user areas, and control the user area not to respond to data accesses when executing code stored in other user areas.
[0008] Optionally, the storage unit further includes multiple configuration areas, each configuration area corresponding to a user area, and each configuration area is used to store protection enable information for the corresponding user area;
[0009] The processing unit is also used to determine whether the user area corresponding to the configuration area is configured to be encrypted based on the protection enable information stored in the configuration area.
[0010] Optionally, the processing unit is further configured to control a user area not to respond to data access from debugging tools or programming tools when the user area is configured to be encrypted.
[0011] Optionally, the user area is also used to store keys;
[0012] The processing unit is also configured to, when a user area is configured to be encrypted, obtain a password input by the user for data access to that user area, and control the user area to respond to data access if the password matches the key stored in the user area.
[0013] The processing unit is further configured to control the user area not to respond to data accesses during the execution of code stored in other user areas, and to control the user area not to respond to data accesses from debugging tools or programming tools, when the password and the key stored in the user area do not match. This is performed when the password and the key stored in the user area do not match.
[0014] Optionally, the user area is also used to store verification codes;
[0015] The configuration area is also used to store hardware verification enable information for the corresponding user area, which is used to indicate whether the code stored in the user area needs hardware verification.
[0016] If the verification result of the hardware on the code stored in a user area is inconsistent with the verification code stored in the user area, the code stored in the user area has been tampered with.
[0017] Optionally, the configuration area is also used to store the address information of the corresponding user area;
[0018] The processing unit is also used to determine the range of the user area corresponding to a configuration area based on the address information stored in a configuration area.
[0019] Optionally, the address information includes the start and end addresses of the user area.
[0020] Optionally, the code area also includes at least one public area, which is a storage area configured to be unencrypted.
[0021] Optionally, among the multiple user-developed codes stored in the multiple user areas, at least one user-developed code needs to call code developed by other users.
[0022] According to a second aspect of the present invention, a system-on-a-chip is provided, comprising any of the storage security components described in the first aspect.
[0023] According to a third aspect of the present invention, an embedded system is provided, comprising any of the storage security components described in the first aspect.
[0024] According to a fourth aspect of the present invention, a method for configuring a storage security component is provided, the security component including a storage unit and a processing unit, the configuration method comprising:
[0025] A code area is configured within the storage unit, the code area comprising multiple user areas, and each user area is configured to store code developed by a user.
[0026] The processing unit is configured to: when a user area is encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas.
[0027] Optionally, the configuration method further includes:
[0028] Multiple configuration areas are configured within the storage unit, and each configuration area corresponds one-to-one with the user area, with each configuration area configured to store the protection enable information of the corresponding user area.
[0029] The processing unit is further configured to: determine whether the user area corresponding to a configuration area is configured to be encrypted based on the protection enable information stored in a configuration area.
[0030] Optionally, the processing unit is further configured to: when a user area is configured to be encrypted, control that user area not to respond to data access from debugging tools or programming tools.
[0031] Optionally, the user area is also configured to store keys;
[0032] The processing unit is further configured to: when a user area is configured to be encrypted, obtain a password input by the user for a data access to that user area, and control the user area to respond to the data access if the password matches the key stored in the user area;
[0033] The processing unit is further configured to: control the user area not to respond to data accesses when the password and the key stored in the user area do not match, and control the user area not to respond to data accesses from debugging tools or programming tools.
[0034] Optionally, the user area is also configured to store a verification code;
[0035] The configuration area is also configured to store hardware verification enable information for the corresponding user area, which is used to indicate whether the code stored in the user area needs hardware verification.
[0036] If the verification result of the hardware on the code stored in a user area is inconsistent with the verification code stored in the user area, the code stored in the user area has been tampered with.
[0037] Optionally, the configuration area is further configured to store the address information of the corresponding user area;
[0038] The processing unit is further configured to: determine the range of the user area corresponding to a configuration area based on the address information stored in a configuration area.
[0039] Optionally, the code area may further include at least one public area, which is configured as an unencrypted storage area.
[0040] According to a fifth aspect of the present invention, a code invocation method is provided, applicable to invocation between code developed by multiple users, wherein the code developed by each user is stored in a user area of a storage unit, the method comprising:
[0041] When a user area is configured to be encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas.
[0042] Optionally, the code invocation method further includes: when a user area is configured to be encrypted, controlling that user area not to respond to data access from debugging tools or programming tools.
[0043] Optionally, the user area is also used to store keys, and the code invocation method further includes:
[0044] When a user area is configured to be encrypted, the password entered by the user is obtained for data access to that user area, and the user area is controlled to respond to data access if the password matches the key stored in the user area.
[0045] In cases where the password and the key stored in the user area do not match, the user area is controlled to not respond to data accesses during the execution of code stored in other user areas, and the user area is controlled to not respond to data accesses from debugging tools or programming tools.
[0046] The storage security component provided by this invention includes a storage unit and a processing unit. The storage unit has a code area, which includes multiple user areas. Each user area stores code developed by one user. Therefore, the multiple user areas configured separately for the code area support multi-user development of the program. The processing unit, when a user area is configured to be encrypted, controls that user area to respond to function call instructions when executing code stored in other user areas, and controls that user area not to respond to data accesses when executing code stored in other user areas. Thus, other user areas cannot read the code in the encrypted user area using data access. In this way, for multi-user developed programs, each user area can protect its program from being stolen by other users by encryption, thereby solving the problem of code theft in multi-user developed programs. Attached Figure Description
[0047] The above and other objects, features and advantages of the present invention will become more apparent from the following description of embodiments of the invention with reference to the accompanying drawings, in which:
[0048] Figure 1 The diagram shown is an architecture diagram of an embedded system provided according to an embodiment of the present invention;
[0049] Figure 2 An architecture diagram of an embedded processor provided according to an embodiment of the present invention is shown;
[0050] Figure 3 This diagram illustrates an architecture of a storage security component provided in an embodiment of the present invention.
[0051] Figure 4 This diagram illustrates an architecture of a storage unit provided according to an embodiment of the present invention.
[0052] Figure 5 The flowchart illustrates a code invocation method provided by an embodiment of the present invention. Detailed Implementation
[0053] The present disclosure is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present disclosure below, certain specific details are described in detail. Those skilled in the art will fully understand the present disclosure even without these details. To avoid obscuring the substance of the present disclosure, well-known methods, processes, and procedures are not described in detail. Furthermore, the accompanying drawings are not necessarily drawn to scale.
[0054] An embedded system is a dedicated computer system designed for a specific application and completely embedded within a controlled device. The controlled device into which an embedded system is embedded is called an embedded product; common embedded products include various consumer electronics and Internet of Things (IoT) devices. Unlike general-purpose computer systems like personal computers, embedded systems typically perform predefined tasks with specific requirements. Because embedded systems are designed for a single, specific task, designers can optimize them to minimize size and cost.
[0055] Figure 1 This is an architecture diagram of an embedded system 100 provided in one embodiment of the present invention. Although various specific embedded systems differ greatly in terms of function, interface, and operation, their basic hardware structures are largely the same. Figure 1 It can represent the architecture of embedded systems relatively well.
[0056] Embedded systems and general-purpose computer hardware systems are highly similar, but the characteristics of embedded system applications lead to significant differences in hardware composition and implementation compared to general-purpose computer systems.
[0057] First, to meet the speed, size, and power consumption requirements of the embedded system 100, data that needs to be stored for a long time, such as the operating system, application software, and special data, typically does not use storage media with large capacity but slow speed, such as hard disks. Figure 1 The memory 102 shown as the storage medium of the embedded system 100 is typically random access memory or flash memory.
[0058] Secondly, the embedded system 100 requires an A / D (analog-to-digital) interface 104 for measurement and control purposes, which is rarely used in general-purpose computers. The A / D interface 104 mainly performs the conversion between analog signals and digital signals required in measurement and control. Since the microcontroller generates digital signals, but analog signals are needed during testing, unlike general-purpose computers, the A / D interface 104 is required to perform the relevant conversions.
[0059] Furthermore, in industrial applications, multiple embedded systems often need to be connected in series to perform related functions. Therefore, the embedded system 100 also needs to... Figure 1 The illustrated setup uses a serial interface 105 to connect multiple embedded systems in series, a configuration rarely required in general-purpose computers. As a basic processing system, embedded system 100 often needs to be networked in industrial designs, thus requiring additional features such as... Figure 1 The setup shown connects the embedded system 100 to the network via network interface 106, which is generally not required in general-purpose computers. Depending on the specific application and scale, some embedded systems 100 may require different interfaces. Figure 1 The external bus 103 is shown. With the rapid expansion of the application areas of embedded systems 100, embedded systems 100 are becoming increasingly personalized, and the types of buses used are also increasing according to their own characteristics. In order to test the internal circuitry of the embedded processor 101, the processor chip generally adopts boundary scan testing technology. Correspondingly, the embedded system 100 also sets up... Figure 1 The debugging interface 107 is shown.
[0060] The core of the embedded system 100 is the embedded processor 101. The embedded processor 101 is used to execute the instruction sequence (i.e., the program). The process of the embedded processor 101 executing each instruction includes: fetching the instruction from the memory 102 where the instructions are stored, decoding the fetched instruction, executing the decoded instruction, and saving the instruction execution result. This process is repeated until all instructions in the instruction sequence have been executed or a halt instruction is encountered.
[0061] To achieve the above process, the embedded processor 101, as shown in the example... Figure 2 The diagram shows an arithmetic logic unit (ALU) 201, a register 202, and a control unit 203. The ALU 201 performs the actual arithmetic operations, the register 202 stores instructions and intermediate results during the arithmetic operations, and the control unit 203 controls access to the memory 102.
[0062] When executing an instruction, ALU 201 moves the instruction from memory 102 to register 202 and fetches the next fetch address, which can be calculated using a fetch algorithm. Fetch algorithms include, for example, incrementing or decrementing the address based on the instruction length. This is commonly used when the program is stored in a contiguous region of memory 102. In this case, ALU 201 needs to obtain the starting address of the program storage to initiate program execution. ALU 201 is assigned a program to execute based on a pre-defined task. The aforementioned method of obtaining the starting address of the program storage and obtaining the subsequent fetch address based on the fetch algorithm is only one way to specify the program to be executed by ALU 201. Specifying the program to be executed by ALU 201 here does not include specifying the function code called during program execution. The function code called during program execution is specified by the corresponding instructions within the program, and the same applies to the following description.
[0063] After fetching the instruction, ALU 201 enters the instruction decoding stage. It decodes the fetched instruction according to a predetermined instruction format to obtain the operand fetch information required for the instruction, thus preparing for instruction execution. Operand fetch information includes, for example, addresses pointing to memory 102. After decoding, the ALU retrieves the operands stored in memory 102 according to the operand fetch information and performs the processing.
[0064] When executing data access instructions, ALU 201 needs to access memory 102 to obtain information stored therein or to provide data that needs to be written to memory 102.
[0065] After the data access instruction is fetched by ALU 201, ALU 201 can decode the instruction to obtain its source operand. The source operand typically includes an address operand. ALU 201 performs calculations on this address operand to obtain the virtual address corresponding to the data access instruction. ALU 201 then sends an address translation request to control unit 203 based on this virtual address. This address translation request includes the virtual address corresponding to the address operand of the data access instruction. Control unit 203 responds to the address translation request and converts the virtual address in the address translation request into a physical address based on the entry matching the virtual address, enabling ALU 201 to access memory 102 using the translated physical address.
[0066] Depending on their function, data access instructions include load instructions and store instructions. Load instructions typically do not require modification of the information in memory 102; the ALU 201 only needs to read data stored in memory 102 or an external storage device based on the address operand of the load instruction. Unlike load instructions, store instructions include not only address operands but also data information in their source operands, and the execution of store instructions typically requires modification of memory 102. The data information in a store instruction can point to data to be written, and the source of this written data can be the execution result of an arithmetic instruction, a load instruction, or data in register 202.
[0067] Currently, many embedded products involve multi-user program development, meaning the program executed by the embedded processor 101 is developed by multiple users. For multi-user developed programs, the code developed by different users often needs to call each other. For example, when the original manufacturer (OEM) and a solution provider jointly develop a program, the solution provider needs to call all or part of the code developed by the OEM. The OEM only needs to provide the function name and corresponding function address, and the solution provider can call the required functions to complete the program development. Therefore, the ALU 201 also involves the execution of function call instructions.
[0068] When executing a function call instruction, ALU 201 needs to access memory 102 to obtain the execution result of the code stored therein.
[0069] After the function call instruction is fetched by the ALU 201, the ALU 201 can decode the instruction, allowing the source operands to be retrieved. Unlike data memory access instructions, the source operands of a function call instruction include not only address operands but also the argument information required for function execution. The execution process of a function call instruction involves sending the argument information to the function at the specified address and receiving the dependent variable information obtained from the function's execution.
[0070] For multi-user developed programs, for information security reasons, while the code developed by different users calls each other, it is necessary to ensure that the code developed by each user is not stolen by other users. Currently, similar products on the market at most support multi-user collaborative program development, but it is impossible to ensure the confidentiality of the code developed by different users, resulting in a significant risk of code theft. In view of this, embodiments of the present invention provide a storage security component. For the embedded system 100, the storage security component provided in this embodiment of the present invention is used as the memory 102 of the embedded system 100, thereby ensuring that the multi-user developed program executed by the embedded processor 101 avoids the risk of code theft.
[0071] Figure 3 The diagram shown is a structural schematic of a storage security component provided in an embodiment of the present invention. (Refer to...) Figure 3 The storage security component 300 includes a storage unit 310 and a processing unit 320.
[0072] Figure 4 The diagram shown is a structural schematic of a storage unit 310 provided in an embodiment of the present invention. (Refer to...) Figure 4 The storage unit 310 includes a code area 311, which comprises multiple user areas. Each user area stores code developed by one user. In some examples, among the multiple user-developed codes stored in the multiple user areas, at least one user-developed code needs to call code developed by other users.
[0073] Specifically, Figure 4 The middle code area 311 includes three user areas: the BOOT area, the USER1 area, and the USER2 area. The code stored in the BOOT area is developed by the original manufacturer, the code stored in the USER1 area is developed by the first solution provider, and the code stored in the USER2 area is developed by a second solution provider. The first solution provider develops its code based on the original manufacturer's code; therefore, when the code stored in the USER1 area is executed, it calls some function code stored in the BOOT area via function call instructions. Similarly, the second solution provider develops its code based on both the original manufacturer's and the first solution provider's code; therefore, when the code stored in the USER2 area is executed, it calls function code in both the BOOT and USER1 areas via function call instructions.
[0074] The code execution in the USER2 area mentioned above is due to the storage security component 300 being used in... Figure 1 After the embedded system 100 shown, Figure 2The ALU 201 shown is designated to be started to complete a preset task. In this case, the code stored in the USER2 area is the program designated for the ALU 201 to execute. Similarly, the execution of the code stored in the USER1 area could also be due to the storage security component 300 being used... Figure 1 After the embedded system 100 shown, Figure 2 The ALU 201 shown is designated to be started in order to complete a preset task. In this case, the code stored in the USER1 area is the program that the ALU 201 is designated to execute. In addition, the execution of the code stored in the USER1 area can also be started by calling the code stored in the USER2 area.
[0075] It should be understood that, Figure 4 The storage unit 310 and the calling relationships of the code within the multiple user areas included in the storage unit 310 are merely examples and do not constitute a limitation of the present invention. In practice, the storage unit 310 may be configured with a corresponding number of user areas as needed, and the code within the multiple user areas may also have calling relationships as needed.
[0076] The processing unit 320 is used to control the user area to respond to function call instructions when the code stored in other user areas is executed when a certain user area is configured to be encrypted, and to control the user area not to respond to data accesses when the code stored in other user areas is executed.
[0077] For example, Figure 4 If the USER1 area is configured to be encrypted, then data access to the USER1 area initiated by the execution of code stored in the USER2 area will not receive a response from the USER1 area. Thus, the USER2 area cannot read the code stored in the USER1 area via data access, preventing the code stored in the USER1 area from being stolen by the user of the USER2 area; furthermore, the USER2 area cannot modify the code stored in the USER1 area via data access, preventing the code stored in the USER1 area from being tampered with by the user of the USER2 area. However, function call instructions initiated by the execution of code stored in the USER2 area that point to the USER1 area will receive a response from the USER1 area, meaning that the dependent variable information generated by the execution of the corresponding function code in the USER1 area can be obtained.
[0078] Combination Figure 1When the storage security component 300 is used as memory 102, it is connected to the embedded processor 101 via bus 103. Data access and function call instructions initiated by the embedded processor 101 when executing a program, pointing to a user area within memory 102, are transmitted to the processing unit 320 included in memory 102 via bus 103. In the prior art, a specific signal on the interface of bus 103 is used to distinguish between data access and function call instructions transmitted to memory 102. For example, in the AHB (Advanced High-performance Bus) interface, a high level of this specific signal represents data access, and a low level represents a function call instruction. Therefore, the processing unit 320 can distinguish between data access and function call instructions.
[0079] The storage security component 300 provided in this embodiment of the invention ensures that the encrypted user area does not respond to data access requests from other user areas during code execution. Therefore, other user areas cannot read the code within the encrypted user area via data access, and each user area can protect its code from being stolen by other users through encryption. Furthermore, other user areas cannot modify the code within the encrypted user area via data access, and each user area can protect its code from being tampered with by other users through encryption. For programs developed by multiple users, the code developed by different users achieves mutual confidentiality while calling each other, thus ensuring information security.
[0080] Reference Figure 4 In one optional embodiment, the storage unit 310 further includes multiple configuration areas 312, each corresponding to a user area, and each configuration area 312 stores protection enable information PENi for its corresponding user area. The processing unit 320 is further configured to determine whether the user area corresponding to a configuration area 312 is configured to be encrypted based on the protection enable information PENi stored in that configuration area 312. The protection enable information PENi stored in the configuration area 312 is written by the user of the corresponding user area, thus allowing the user of the user area to configure whether the user area is encrypted by writing the protection enable information PENi into the configuration area 312. Figure 4 In the BOOT area, the protection enable information is PENi, which is PEN0; in the USER1 area, the protection enable information is PENi, which is PEN1; and in the USER2 area, the protection enable information is PENi, which is PEN2.
[0081] Furthermore, the processing unit 320 is also configured to control a user area to not respond to data access from debugging tools or programming tools when that user area is configured to be encrypted. (See reference...) Figure 1The debugging tool is connected to the embedded system 100 via the debugging interface 107. The debugging interface 107 is connected to the memory 102 via the bus 103. As described above, the storage security component 300 of the memory 102 can identify data accesses from the debugging tool via the bus 103, thereby effectively preventing the debugging tool from stealing or tampering with the code. For the programming tool, the embedded processor 101 is the execution device for its programmed program. As described above, the data access initiated by the embedded processor 101 when executing the program can be identified by the processing unit 320. Therefore, the processing unit 320 can control the encrypted user area not to respond to data accesses from the programming tool, so that the programming tool cannot steal or tamper with the code stored in the encrypted user area.
[0082] Figure 4 The example shown uses the USER2 area to illustrate the data stored in a user area. (Refer to...) Figure 4 In one optional embodiment, the user area stores a key in addition to the user's code. Accordingly, the processing unit 320 is also configured to, when a user area is configured to be encrypted, obtain a password input by the user for data access directed to that user area, and control the user area to respond to data access if the password matches the key stored in the user area; the aforementioned control by the processing unit 320 to prevent the user area from responding to data access when the code stored in other user areas is executed, and to prevent the user area from responding to data access from debugging tools or programming tools, is performed when the password and the key stored in the user area do not match.
[0083] Specifically, the key stored in the user area typically includes multiple bits, for example, 128 bits. Figure 4 The shown keys are Key[31:0], Key[63:32], Key[95:64], and Key[127:96]. After receiving the password input by the user, the processing unit 320 can sequentially match the password and key segment by segment. Figure 4 Taking the 128-bit key shown as an example, we can first compare the first 32 bits of the user's input password with the corresponding bits of Key[31:0]. Then, we can compare the 33rd to 64th bits of the user's input password with the corresponding bits of Key[63:32]. Next, we can compare the 65th to 96th bits of the user's input password with the corresponding bits of Key[95:64]. Finally, we can compare the 97th to 128th bits of the user's input password with the corresponding bits of Key[127:96].
[0084] In the process of matching passwords and keys segment by segment, if even one bit does not match, it means that the password entered by the user does not match the key stored in that user area; only when all bits match does it mean that the password entered by the user matches the key stored in that user area.
[0085] In practice, each user only knows the key stored in their own user area. Therefore, by entering a password that matches the key stored in their user area, they can retrieve the code stored in their user area and thus execute the code.
[0086] Of course, in this embodiment, if users in other user areas obtain the key stored in the encrypted user area, they can also read and modify the code stored in the encrypted user area through data memory access. Similarly, if a user can input a password that matches the key stored in the encrypted user area through debugging or programming tools, the debugging or programming tools can also read and modify the code stored in the encrypted user area through data memory access.
[0087] The aforementioned user area, if configured to be unencrypted, can respond to both function call instructions and data access. It should be understood that for an unencrypted user area, no password is required from the user.
[0088] Reference Figure 4 In one optional embodiment, the user area stores a checksum (CRC) in addition to the user's code. Correspondingly, the configuration area 312 is also used to store hardware verification enable information CENi for the corresponding user area. CENi indicates whether the code stored in the user area requires hardware verification; wherein, if the hardware verification result of the code stored in a user area is inconsistent with the checksum stored in that user area, the code stored in that user area has been tampered with.
[0089] Figure 4 In the BOOT area, the hardware verification enable information is CENi, which is CEN0; in the USER1 area, the hardware verification enable information is CENi, which is CEN1; and in the USER2 area, the hardware verification enable information is CENi, which is CEN2.
[0090] The aforementioned hardware can be understood as an electronic device using the storage security component 300, or as the processor included in the electronic device using the storage security component 300. Taking the storage security component 300 as the memory 102 of the embedded system 100 and the hardware as the embedded processor 101 as an example, the hardware verification enable information CEN1 is used to indicate whether the code stored in the user area needs to be verified by the embedded processor 101.
[0091] Reference Figure 1If embedded processor 101 needs to perform verification, it will automatically read the code in the user area and verify it via bus 103 when it obtains read access to the code in the user area. The verification result can be stored in [the relevant storage location]. Figure 2 The verification result read from register 202 is used to compare with the verification code read from the user area. For unencrypted user areas, the embedded processor 101 gains read access to the code in the user area after the storage security component 300 is started; for encrypted user areas, the embedded processor 101 gains read access to the code in the user area if the processing unit 320 determines that the password entered by the user matches the key stored in the user area.
[0092] Specifically, code verification is performed to determine whether the code has been tampered with. Verification methods include, for example, Cyclic Redundancy Check (CRC). When CRC is used, the hardware reads the code in the user area and calculates the CRC checksum according to a pre-obtained algorithm. The calculated CRC checksum is the verification result obtained by the hardware. In some examples, the CRC checksum calculated by the hardware according to the pre-obtained algorithm is 32-bit, and the checksum stored in the user area is also 32-bit, such as... Figure 4 As shown in CRC[31:0], the CRC checksum calculated by the hardware and the checksum stored in the user area are only considered to be consistent if all bits correspond.
[0093] In this embodiment, if the hardware's verification result of the code stored in a user area does not match the checksum stored in that user area, the code stored in that user area has been tampered with. The hardware can therefore determine not to execute the code in that user area, thus ensuring that it is not attacked due to code tampering. Conversely, if the hardware's verification result of the code stored in a user area matches the checksum stored in that user area, the code stored in that user area has not been tampered with, and the hardware can safely execute the code in that user area.
[0094] Reference Figure 4 In one optional embodiment, the configuration area 312 is further used to store the address information of the corresponding user area; the processing unit 320 is further used to determine the range of the user area corresponding to the configuration area based on the address information stored in the configuration area 312.
[0095] The above data access or function call instructions point to a certain user area because the physical address after instruction translation falls within the range of that user area indicated by the address information.
[0096] Specifically, the address information stored in configuration area 312 can be the start address SAi and end address EAi of the user area. The start address SAi and end address EAi define a contiguous storage space as the user area. Figure 4 In the BOOT area, the starting address SAi is SA0 and the ending address EAi is EA0; the starting address SAi is SA1 and the ending address EAi is EA1; the starting address SAi is SA2 and the ending address EAi is EA2.
[0097] The start address SAi and end address EAi stored in the configuration area 312 are written by the users of the corresponding user areas. Thus, users in the user areas define the scope of their user areas by writing the start address SAi and end address EAi into the configuration area 312. When the user area is configured to be encrypted, users define the protected scope of their area by writing the start address SAi and end address EAi into the configuration area 312.
[0098] Reference Figure 4 In one alternative embodiment, the code area 311 further includes at least one public area, which is a storage area configured to be unencrypted, and all data accesses can directly read data stored in the public area or write data to the public area without a password. Figure 4 In the code segment 311, there are three public areas: Public0, Public1, and Public2. These public areas can be used to store annotation information for the code stored in the user area, such as code version information and configuration information of the device running the code. This facilitates easier use of the program for multi-user development.
[0099] With the rapid development of Very Large Scale Integration (VLSI) and semiconductor technology, the aforementioned memory security components can be implemented on a single silicon chip, known as a System-on-Chip (SoC). When in use, this SoC is installed as a chip within an electronic device, thus functioning as a component of the device.
[0100] Corresponding to the aforementioned storage security component 300, this embodiment of the invention also provides a configuration method for the storage security component. The security component includes a storage unit and a processing unit, and the configuration method includes:
[0101] A code area is configured within the storage unit, which includes multiple user areas, and each user area is configured to store code developed by one user.
[0102] The processing unit is configured to: when a user area is encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas.
[0103] Furthermore, the configuration methods also include:
[0104] Multiple configuration areas are configured within the storage unit. Each configuration area corresponds to a user area, and each configuration area is configured to store the protection enable information of the corresponding user area.
[0105] The processing unit is also configured to determine whether the user area corresponding to a configuration area is configured to be encrypted based on the protection enable information stored in a configuration area.
[0106] Furthermore, the processing unit is also configured to control a user area to not respond to data access from debugging tools or programming tools when that user area is configured to be encrypted.
[0107] Furthermore, the user area is also configured to store keys;
[0108] The processing unit is also configured to: when a user area is configured to be encrypted, retrieve the password entered by the user for data access to that user area, and control the user area to respond to the data access if the password matches the key stored in the user area;
[0109] The processing unit is also configured to: control the user area not to respond to data accesses when the password and the key stored in the user area do not match, and control the user area not to respond to data accesses from debugging tools or programming tools.
[0110] Furthermore, the user area is also configured to store verification codes;
[0111] The configuration area is also configured to store hardware verification enable information for the corresponding user area. The hardware verification enable information is used to indicate whether the code stored in the user area requires hardware verification.
[0112] If the hardware's verification result of the code stored in a user area is inconsistent with the verification code stored in that user area, then the code stored in that user area has been tampered with.
[0113] Furthermore, the configuration area is also configured to store the address information of the corresponding user area;
[0114] The processing unit is also configured to determine the range of the user area corresponding to a configuration area based on the address information stored in a configuration area.
[0115] Furthermore, the code area also includes at least one public area, which is configured as an unencrypted storage area.
[0116] Corresponding to the aforementioned storage security component 300, this embodiment of the invention also provides a code invocation method. This code invocation method is applied to invocation between code developed by multiple users, wherein the code developed by each user is stored in a user area of the storage unit 310. The code invocation method includes: when a certain user area is configured to be encrypted, controlling that user area to respond to function call instructions when executing code stored in other user areas, and controlling that user area not to respond to data accesses when executing code stored in other user areas.
[0117] Specifically, the execution flow of the code calling the method can be as follows: Figure 5 As shown. (Refer to...) Figure 5 The code call methods include:
[0118] Step S10: Determine whether the received instruction is a function call instruction or a data access instruction. If it is a function call instruction, proceed to step S20; if it is a data access instruction, proceed to step S30.
[0119] Step S20: Respond to the function call instruction.
[0120] Step S30: Determine whether the user area pointed to by the data access memory is configured to be encrypted. If it is configured to be encrypted, proceed to step S40; otherwise, proceed to step S50.
[0121] Step S40: Do not respond to data access requests.
[0122] Step S50: Response data access memory.
[0123] Furthermore, the code invocation method also includes: when a user area is configured to be encrypted, controlling the user area not to respond to data access from debugging tools or programming tools.
[0124] Furthermore, the user area is also used to store keys, and the code invocation method further includes: when a user area is configured to be encrypted, obtaining a password input by the user for data access pointing to that user area, and controlling the user area to respond to data access if the password matches the key stored in the user area; wherein, controlling the user area not to respond to data access when code stored in other user areas is executed, and controlling the user area not to respond to data access from debugging tools or programming tools, are performed when the password does not match the key stored in the user area.
[0125] The implementation details of the above method embodiments have been described in detail in the preceding device embodiments section, and can be referred to in the preceding device embodiments section, and will not be repeated here.
[0126] Those skilled in the art will understand that the present invention can be implemented as a system, method, and computer program product. Therefore, this disclosure can be specifically implemented as entirely hardware, entirely software (including firmware, resident software, and microcode), or a combination of software and hardware. Furthermore, in some embodiments, the present invention can also be implemented as a computer program product contained in one or more computer-readable media, the computer-readable medium containing computer-readable program code.
[0127] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium is, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium include: an electrical connection of one or more wires, a portable computer disk drive, hard disk drive, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with a processing unit, apparatus, or device.
[0128] Computer-readable signal media may include data signals propagated in baseband or as part of a chopped signal, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any other suitable combination. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction system, apparatus, or device.
[0129] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, and any suitable combination thereof.
[0130] Computer program code for executing embodiments of this disclosure can be written in one or more programming languages or combinations thereof. Programming languages include object-oriented programming languages such as JAVA and C++, and may also include conventional procedural programming languages such as C. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0131] The above are merely preferred embodiments of this disclosure and are not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.
Claims
1. A storage security device, characterized in that, include: A storage unit, wherein the storage unit is provided with a code area, the code area includes multiple user areas, each user area being used to store code developed by a user; The processing unit is configured to, when a user area is configured to be encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas. In the multiple user areas storing multiple user-developed codes, at least one user-developed code needs to call code developed by other users. The original manufacturer and the solution provider jointly develop the program. The solution provider calls all or part of the code developed by the original manufacturer. The original manufacturer provides the function names and corresponding function addresses. The solution provider calls the required functions to implement program development.
2. The storage security device according to claim 1, characterized in that, The storage unit is further provided with multiple configuration areas, each configuration area corresponding to a user area, and each configuration area is used to store the protection enable information of the corresponding user area; The processing unit is also used to determine whether the user area corresponding to the configuration area is configured to be encrypted based on the protection enable information stored in the configuration area.
3. The storage security device according to claim 2, characterized in that, The processing unit is also configured to control a user area to not respond to data access from debugging tools or programming tools when the user area is configured to be encrypted.
4. The storage security device according to claim 3, characterized in that, The user area is also used to store keys; The processing unit is also configured to, when a user area is configured to be encrypted, obtain a password input by the user for data access to that user area, and control the user area to respond to data access if the password matches the key stored in the user area. The processing unit is further configured to, in the event that the password and the key stored in the user area do not match, control the user area not to respond to data accesses when code stored in other user areas is executed, and control the user area not to respond to data accesses from debugging tools or programming tools.
5. The storage security device according to claim 2, characterized in that, The user area is also used to store verification codes; The configuration area is also used to store hardware verification enable information for the corresponding user area, which is used to indicate whether the code stored in the user area needs hardware verification. If the verification result of the hardware on the code stored in a user area is inconsistent with the verification code stored in the user area, the code stored in the user area has been tampered with.
6. The storage security device according to claim 2, characterized in that, The configuration area is also used to store the address information of the corresponding user area; The processing unit is also used to determine the range of the user area corresponding to a configuration area based on the address information stored in a configuration area.
7. The storage security device according to claim 6, characterized in that, The address information includes the start and end addresses of the user area.
8. The storage security device according to claim 1, characterized in that, The code area also includes at least one public area, which is a storage area configured to be unencrypted.
9. A system-on-a-chip, characterized in that, include: The storage security device according to any one of claims 1 to 8.
10. An embedded system, characterized in that, include: The storage security device according to any one of claims 1 to 8.
11. A method for configuring a storage security device, characterized in that, The storage security device includes a storage unit and a processing unit, and the configuration method includes: A code area is configured within the storage unit, the code area comprising multiple user areas, and each user area is configured to store code developed by a user. The processing unit is configured to: when a certain user area is encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas. In the multiple user areas storing multiple user-developed codes, at least one user-developed code needs to call code developed by other users. The original manufacturer and the solution provider jointly develop the program. The solution provider calls all or part of the code developed by the original manufacturer. The original manufacturer provides the function names and corresponding function addresses. The solution provider calls the required functions to implement program development.
12. The configuration method according to claim 11, characterized in that, Also includes: Multiple configuration areas are configured within the storage unit, and each configuration area corresponds one-to-one with the user area, with each configuration area configured to store the protection enable information of the corresponding user area. The processing unit is further configured to: determine whether the user area corresponding to a configuration area is configured to be encrypted based on the protection enable information stored in a configuration area.
13. The configuration method according to claim 12, characterized in that, The processing unit is also configured to: when a user area is configured to be encrypted, control that user area not to respond to data access from debugging tools or programming tools.
14. The configuration method according to claim 13, characterized in that, The user area is also configured to store keys; The processing unit is further configured to: when a user area is configured to be encrypted, obtain a password input by the user for a data access to that user area, and control the user area to respond to the data access if the password matches the key stored in the user area; The processing unit is further configured to: control the user area not to respond to data accesses when the password and the key stored in the user area do not match, and control the user area not to respond to data accesses from debugging tools or programming tools.
15. The configuration method according to claim 12, characterized in that, The user area is also configured to store verification codes; The configuration area is also configured to store hardware verification enable information for the corresponding user area, which is used to indicate whether the code stored in the user area needs hardware verification. If the verification result of the hardware on the code stored in a user area is inconsistent with the verification code stored in the user area, the code stored in the user area has been tampered with.
16. The configuration method according to claim 12, characterized in that, The configuration area is also configured to store the address information of the corresponding user area; The processing unit is further configured to: determine the range of the user area corresponding to a configuration area based on the address information stored in a configuration area.
17. The configuration method according to claim 11, characterized in that, The code area also includes at least one public area, which is configured as an unencrypted storage area.
18. A code invocation method, characterized in that, The method, applicable to calls between code developed by multiple users, wherein the code developed by each user is stored in a user area of a storage unit, includes: When a user area is configured to be encrypted, control that user area to respond to function call instructions when executing code stored in other user areas, and control that user area not to respond to data accesses when executing code stored in other user areas. In the multiple user areas storing multiple user-developed codes, at least one user-developed code needs to call code developed by other users. The original manufacturer and the solution provider jointly develop the program. The solution provider calls all or part of the code developed by the original manufacturer. The original manufacturer provides the function names and corresponding function addresses. The solution provider calls the required functions to implement program development.
19. The code invocation method according to claim 18, characterized in that, Also includes: When a user area is configured to be encrypted, control that user area to not respond to data access from debugging tools or programming tools.
20. The code invocation method according to claim 19, characterized in that, The user area is also used to store keys, and the method further includes: When a user area is configured to be encrypted, the password entered by the user is obtained for data access to that user area, and the user area is controlled to respond to data access if the password matches the key stored in the user area. In cases where the password and the key stored in the user area do not match, the user area is controlled to not respond to data accesses during the execution of code stored in other user areas, and the user area is controlled to not respond to data accesses from debugging tools or programming tools.
Citation Information
Patent Citations
Method and device for protecting codes of embedded software by hardware encryption module
CN103377350A
Device of performing protection to software
CN201035579Y