Security protection method and device for STR scene, equipment and storage medium

Abstract

The invention discloses a safety protection method and device for an STR scene, equipment and a storage medium, and relates to the technical field of computer application, the method comprises the steps that after an AP and an SP receive a SUSPend command, keys and sensitive information in a memory are cleared, and meanwhile the Checksum value of program data in a DDR is randomly calculated and stored; and after the SP Resume and before the AP Resume, randomly calculating the Checksum value of the program data in the DDR again, and comparing the Checksum value with the stored Checksum value so as to determine the Resume or the Reboot. The program data comprises Code segment data, Data segment data and Bss segment data. The application can ensure that sensitive information is not leaked, ensure that the program is not tampered, and eliminate the possibility of being attacked by illegal persons.

Description

Technical Field

[0001] This application relates to the field of computer application technology, specifically to a security protection method, device, equipment, and storage medium for STR scenarios. Background Technology

[0002] STR (Suspend To RAM) is a power management technology that enables fast wake-up by saving the system's current state to RAM. It is commonly used in energy-saving scenarios in computers and embedded devices. STR saves the system's runtime memory data to RAM while shutting down hard drives, peripherals, and other devices, only maintaining power to the memory. Upon wake-up, the system directly restores its state from memory, avoiding a system reload and significantly reducing boot time (typically only a few seconds).

[0003] However, current technologies generally lack security protections for STR (Sensitive Information Module) and have vulnerabilities. Specifically, existing STR solutions pose risks of sensitive information leakage and tampering, making them susceptible to attacks. Summary of the Invention

[0004] This application provides a security protection method, device, equipment, and storage medium for STR scenarios, which can ensure that sensitive information is not leaked, ensure that the program is not tampered with, and eliminate the possibility of being attacked by malicious personnel.

[0005] In a first aspect, embodiments of this application provide a security protection method for STR scenarios, the security protection method for STR scenarios including: After receiving the Suspend command, AP and SP clear the key and sensitive information in memory, and at the same time randomly calculate and save the checksum value of the program data in DDR. After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again and compared with the saved checksum value to determine whether to Resume or Reboot.

[0006] In conjunction with the first aspect, in one implementation, after receiving the Suspend command, the AP and SP clear the key and sensitive information in memory, and simultaneously randomly calculate and save the checksum value of the program data in DDR, specifically including: After receiving the Suspend command, the AP clears the key and sensitive information in memory before entering the STR. After receiving the Suspend command, SP randomly calculates the checksum value of the program data in DDR before entering STR, and saves the calculated checksum value.

[0007] In conjunction with the first aspect, in one implementation, the program data includes Code segment data, Data segment data, and Bss segment data.

[0008] In conjunction with the first aspect, in one implementation, the random calculation of the checksum value of the program data in the DDR and the saving of the calculated checksum value specifically includes: SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value; SP reads HUK from the EFUSE module as the calculation key for HMAC; SP uses TRNG to generate a random number as the starting position for HMAC input DDR program data; The calculated checksum value and the generated random number are saved to a preset fixed location in DDR.

[0009] In conjunction with the first aspect, in one implementation method, Both the checksum value and the random number are 32 bits, and the input length of HMAC is a fixed 128K.

[0010] In conjunction with the first aspect, in one implementation, the step of randomly calculating the checksum value of the program data in DDR again after SP Resume and before AP Resume, and comparing it with the saved checksum value to determine Resume or Reboot, specifically includes: After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again based on the saved random number. The recalculated checksum value is compared with the saved checksum value. If they match, a Resume is performed; otherwise, a Reboot is performed.

[0011] In conjunction with the first aspect, in one implementation, the step of randomly calculating the checksum value of the program data in the DDR again based on the saved random number specifically includes: SP reads HUK from the EFUSE module as the calculation key for HMAC; SP obtains a saved random number from a preset fixed location in DDR and locates the starting position of the program data in DDR based on the obtained random number; SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value.

[0012] Secondly, this application provides a security protection device for STR scenarios, the security protection device for STR scenarios comprising: The calculation module is used to clear the key and sensitive information in memory after the AP and SP receive the Suspend command, and at the same time randomly calculate and save the checksum value of the program data in DDR. The comparison module is used to randomly calculate the checksum value of the program data in DDR again after SP Resume and before AP Resume, and compare it with the saved checksum value to determine whether to Resume or Reboot.

[0013] Thirdly, this application provides a security protection device for STR scenarios, the security protection device for STR scenarios including a processor, a memory, and a security protection program for STR scenarios stored in the memory and executable by the processor, wherein when the security protection program for STR scenarios is executed by the processor, it implements the steps of the security protection method for STR scenarios described above.

[0014] Fourthly, this application provides a computer-readable storage medium storing a security protection program for STR scenarios, wherein when the security protection program for STR scenarios is executed by a processor, it implements the steps of the security protection method for STR scenarios described above.

[0015] The beneficial effects of the technical solutions provided in this application include: After receiving the Suspend command, the AP and SP clear the keys and sensitive information in memory. At the same time, they randomly calculate and save the checksum value of the program data in DDR. After the SP Resume and before the AP Resume, they randomly calculate the checksum value of the program data in DDR again and compare it with the saved checksum value to determine whether to resume or reboot. This effectively solves the security problem of the vehicle system in the STR scenario, effectively protects the user's personal sensitive information from being leaked, ensures that the vehicle system will not be attacked, and thus avoids unnecessary property losses. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the security protection method for STR scenarios in this application; Figure 2 This is a flowchart of the relevant steps S1 in this application; Figure 3 This is a flowchart of the relevant steps S2 in this application; Figure 4 This is a schematic diagram of the functional modules of the safety protection device for STR scenarios in this application; Figure 5 This is a schematic diagram of the hardware structure of the security protection device for the STR scenario in this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] Firstly, this application provides a security protection method for STR scenarios, which is used to ensure that sensitive information is not leaked, the program is not tampered with, and the possibility of being attacked by malicious actors in STR scenarios.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the security protection method for STR scenarios outlined in this application. Figure 1 As shown, the security protection methods for STR scenarios include: S1: After receiving the Suspend command, the AP and SP clear the key and sensitive information in memory, and at the same time randomly calculate and save the checksum value of the program data in DDR (Double Data Rate Synchronous Dynamic Random Access Memory). The Suspend command is an instruction used in the computer system to suspend the execution of a process or task, and the checksum is a value used to verify the integrity and accuracy of data. AP stands for Application Processor, and SP stands for Secure Processor. S2: After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again and compared with the saved checksum value to determine whether to Resume or Reboot. Resume means to restore, referring to resuming system operation from sleep / hibernation state; Reboot means to restart, referring to a complete system reboot.

[0021] Furthermore, in one embodiment, after receiving the Suspend command, the AP and SP clear the key and sensitive information in memory, and simultaneously randomly calculate and save the checksum value of the program data in DDR, specifically including: S101: After receiving the Suspend command, the AP clears the keys and sensitive information in memory before entering the STR. The keys include encryption and decryption keys, authentication keys, etc., and the sensitive information includes the customer's Face ID, fingerprint ID, identity-related information, etc. S102: After receiving the Suspend command, SP randomly calculates the checksum value of the program data in DDR before entering STR, and saves the calculated checksum value. The program data includes Code segment data, Data segment data, Bss segment (uninitialized data segment) data, etc.

[0022] Specifically, after receiving the Suspend command, the AP first clears the key and sensitive information in memory before entering the STR to prevent attackers from obtaining the key and sensitive information through memory attacks; after receiving the Suspend command, the SP needs to randomly calculate the checksum value of the program data in the DDR before entering the STR, and save the calculated checksum value.

[0023] Furthermore, in one embodiment, randomly calculating the checksum value of the program data in the DDR and saving the calculated checksum value specifically includes: S1021: SP calculates the hash value of the program data in DDR based on the HMAC (Hash-based Message Authentication Code) algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value; S1022: SP reads the HUK (Hardware Unique Key) from the EFUSE (One-Time Programmable Memory) module as the calculation key for HMAC; S1023: SP uses TRNG (True Random Number Generator) to generate random numbers as the starting position for HMAC input DDR program data; S1024: Save the calculated checksum value and the generated random number to a preset fixed location in the DDR. Both the checksum value and the random number are 32 bits, and the input length of the HMAC is fixed at 128K.

[0024] Specifically, SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the hash value as the checksum value. SP reads HUK from the EFUSE module as the calculation key for HMAC. SP uses TRNG to generate a 32-bit random number as the starting position of the HMAC input to the DDR program data. The input length of HMAC is fixed at 128K. Then, the 32-bit random number and the 32-bit checksum value are both stored in the preset fixed position of DDR.

[0025] See Figure 2 The diagram shown is a flowchart of the relevant steps S1 above. Figure 2 In this context, Random represents random numbers, sensitive data represents sensitive information, Heap represents a heap, and Stack represents a stack.

[0026] Furthermore, in one embodiment, after SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again and compared with the saved checksum value to determine whether to Resume or Reboot. Specifically, this includes: S201: After SP Resume and before AP Resume, calculate the checksum value of the program data in DDR again based on the saved random number. S202: Compare the recalculated checksum value with the saved checksum value. If they match, perform a Resume; otherwise, perform a Reboot.

[0027] Specifically, after Resume starts but before APResume starts, SP recalculates the checksum value of the program data in DDR based on the saved random number and compares it with the saved checksum value. If they match, Resume is performed; otherwise, Reboot is performed.

[0028] Furthermore, in one embodiment, the checksum value of the program data in the DDR is randomly calculated again based on the saved random number, specifically including: S2011: SP reads HUK from the EFUSE module as the calculation key for HMAC; S2012: SP retrieves a saved random number from a preset fixed location in DDR and locates the starting position of the program data in DDR based on the retrieved random number; S2013: SP calculates the HASH value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated HASH value as the Checksum value.

[0029] Specifically, SP first reads HUK from the EFUSE module as the calculation key for HMAC. Then, SP obtains a saved random number from a preset fixed location in DDR. SP recalculates the HASH value of the program data in DDR based on the obtained random number, takes the first 2 bytes and the last 2 bytes as the checksum value, and compares it with the saved checksum value. If they match, Resume is performed; if they do not match, Reboot is performed.

[0030] See Figure 3 The diagram shows the relevant flowchart for step S2 above. SP locates the starting position of the program code data in DDR based on the saved random number, and then reads the program code data in a fixed length of 128K. Then, SP obtains HUK from EFUSE. Finally, SP uses the HMAC algorithm to calculate the checksum value and compares it with the previously saved checksum value. If they match, Resume is performed; if they do not match, Reboot is performed. Figure 3 In this context, "equal" indicates whether the data is the same, and "codeetc" represents program data.

[0031] In this application, the key and sensitive personal information are cleared from memory by a clearing instruction before entering the STR; before the AP enters the STR and before the STR is restored, the security small core SP performs dynamic checksum calculation on the program in DRAM. If the two checksums are not equal, the Reboot instruction is executed to restart the system; the checksum uses the HMAC algorithm, the key uses HUK in EFUSE, and only the first 2 bytes and the last 2 bytes of the HMAC result are taken as the checksum value and stored in a fixed location in DRAM. The storage format is: Location_Checksum.

[0032] The security protection method for STR scenarios in this application embodiment involves the AP and SP clearing the key and sensitive information in memory after receiving the Suspend command. At the same time, they randomly calculate and save the checksum value of the program data in DDR. After SP Resume and before AP Resume, they randomly calculate the checksum value of the program data in DDR again and compare it with the saved checksum value to determine whether to Resume or Reboot. This effectively solves the security problem of the vehicle system in STR scenarios, effectively protects the user's personal sensitive information from being leaked, ensures that the vehicle system will not be attacked, and thus avoids unnecessary property losses.

[0033] Secondly, embodiments of this application also provide a security protection device for STR scenarios.

[0034] In one embodiment, reference is made to Figure 4 , Figure 4 This is a schematic diagram of the functional modules of the safety protection device for STR scenarios in this application. Figure 4 As shown, the security protection device for the STR scenario includes: a calculation module and a comparison module.

[0035] The calculation module is used to clear the key and sensitive information in memory after the AP and SP receive the Suspend command, and at the same time randomly calculate and save the checksum value of the program data in DDR; the comparison module is used to randomly calculate the checksum value of the program data in DDR again after SP Resume and before AP Resume, and compare it with the saved checksum value to determine Resume or Reboot.

[0036] In this application, after receiving the Suspend command, the AP and SP clear the key and sensitive information in memory, and simultaneously randomly calculate and save the checksum value of the program data in DDR. Specifically, this includes: After receiving the Suspend command, the AP clears the key and sensitive information in memory before entering the STR. After receiving the Suspend command, SP randomly calculates the checksum value of the program data in DDR before entering STR, and saves the calculated checksum value.

[0037] In this application, the program data includes Code segment data, Data segment data, and Bss segment data.

[0038] In this application, the checksum value of the program data in the DDR is randomly calculated and the calculated checksum value is saved, specifically including: SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value; SP reads HUK from the EFUSE module as the calculation key for HMAC; SP uses TRNG to generate a random number as the starting position for HMAC input DDR program data; The calculated checksum value and the generated random number are saved to a preset fixed location in DDR.

[0039] In this application, both the checksum value and the random number are 32 bits, and the input length of HMAC is fixed at 128K.

[0040] In this application, after SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again and compared with the saved checksum value to determine whether to resume or reboot. Specifically, this includes: After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again based on the saved random number. The recalculated checksum value is compared with the saved checksum value. If they match, a Resume is performed; otherwise, a Reboot is performed.

[0041] In this application, the checksum value of the program data in DDR is randomly calculated again based on the saved random number, specifically including: SP reads HUK from the EFUSE module as the calculation key for HMAC; SP obtains a saved random number from a preset fixed location in DDR and locates the starting position of the program data in DDR based on the obtained random number; SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value.

[0042] Thirdly, this application provides a security protection device for STR scenarios. The security protection device for STR scenarios can be a personal computer (PC), a laptop, a server, or other device with data processing capabilities.

[0043] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of a security protection device for STR scenarios involved in the embodiments of this application. In this embodiment, the security protection device for STR scenarios may include a processor, a memory, a communication interface, and a communication bus.

[0044] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0045] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of security protection equipment for STR scenarios, as well as interfaces used for interconnecting security protection equipment for STR scenarios with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0046] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0047] The processor can be a general-purpose processor, which can call a security protection program for STR scenarios stored in memory and execute the security protection method for STR scenarios provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the security protection program for STR scenarios is called can be referred to in the various embodiments of the security protection method for STR scenarios in this application, and will not be repeated here.

[0048] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0049] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0050] The present application has a computer-readable storage medium storing a security protection program for STR scenarios, wherein when the security protection program for STR scenarios is executed by a processor, it implements the steps of the security protection method for STR scenarios as described above.

[0051] The method implemented when the security protection program for the STR scenario is executed can be referred to in the various embodiments of the security protection method for the STR scenario in this application, and will not be repeated here.

[0052] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0053] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0054] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0055] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0056] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0057] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A security protection method for STR scenarios, characterized in that, The security protection method for STR scenarios includes: After receiving the Suspend command, AP and SP clear the key and sensitive information in memory, and at the same time randomly calculate and save the checksum value of the program data in DDR. After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again and compared with the saved checksum value to determine whether to Resume or Reboot.

2. The security protection method for STR scenarios as described in claim 1, characterized in that, After receiving the Suspend command, the AP and SP clear the key and sensitive information in memory, and simultaneously randomly calculate and save the checksum value of the program data in DDR. Specifically, this includes: After receiving the Suspend command, the AP clears the key and sensitive information in memory before entering the STR. After receiving the Suspend command, SP randomly calculates the checksum value of the program data in DDR before entering STR, and saves the calculated checksum value.

3. A security protection method for STR scenarios as described in claim 2, characterized in that: The program data includes Code segment data, Data segment data, and Bss segment data.

4. A security protection method for STR scenarios as described in claim 2, characterized in that, The random calculation and storage of the checksum value of the program data in the DDR specifically includes: SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value; SP reads HUK from the EFUSE module as the calculation key for HMAC; SP uses TRNG to generate a random number as the starting position for HMAC input DDR program data; The calculated checksum value and the generated random number are saved to a preset fixed location in DDR.

5. A security protection method for STR scenarios as described in claim 4, characterized in that: Both the checksum value and the random number are 32 bits, and the input length of HMAC is a fixed 128K.

6. A security protection method for STR scenarios as described in claim 4, characterized in that, The step of randomly calculating the checksum value of the program data in DDR again after SPResume and before AP Resume, and comparing it with the saved checksum value to determine whether to Resume or Reboot, specifically includes: After SP Resume and before AP Resume, the checksum value of the program data in DDR is randomly calculated again based on the saved random number. The recalculated checksum value is compared with the saved checksum value. If they match, a Resume is performed; otherwise, a Reboot is performed.

7. A security protection method for STR scenarios as described in claim 6, characterized in that, The step of randomly calculating the checksum value of the program data in DDR again based on the saved random number specifically includes: SP reads HUK from the EFUSE module as the calculation key for HMAC; SP obtains a saved random number from a preset fixed location in DDR and locates the starting position of the program data in DDR based on the obtained random number; SP calculates the hash value of the program data in DDR based on the HMAC algorithm, and takes the first 2 bytes and the last 2 bytes of the calculated hash value as the checksum value.

8. A safety protection device for STR scenarios, characterized in that, The safety protection device for STR scenarios includes: The calculation module is used to clear the key and sensitive information in memory after the AP and SP receive the Suspend command, and at the same time randomly calculate and save the checksum value of the program data in DDR. The comparison module is used to randomly calculate the checksum value of the program data in DDR again after SP Resume and before AP Resume, and compare it with the saved checksum value to determine whether to Resume or Reboot.

9. A safety protection device for STR scenarios, characterized in that, The security protection device for STR scenarios includes a processor, a memory, and a security protection program for STR scenarios stored in the memory and executable by the processor, wherein when the security protection program for STR scenarios is executed by the processor, it implements the steps of the security protection method for STR scenarios as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a security protection program for STR scenarios, wherein when the security protection program for STR scenarios is executed by a processor, it implements the steps of the security protection method for STR scenarios as described in any one of claims 1 to 7.

Images