Controller and its safe operation method and system

Abstract

The application relates to the technical field of embedded systems, and provides a controller and a safe operation method and system thereof. The method is applied to a controller without a hardware security module, and comprises the following steps: obtaining device unique characteristic information of the controller; generating a device root key through a key derivation function based on the device unique characteristic information; wherein the device root key exists in a volatile memory; deriving a function key based on the device root key; and performing a safe operation on target data by using the function key. The safe operation of the controller is realized by combining the device unique characteristic information in a software mode, and security threats such as firmware tampering and data leakage are effectively resisted.

Description

Technical Field

[0001] This application relates to the field of embedded systems technology, specifically to a controller and its safe operation method and system. Background Technology

[0002] With the rapid development of connected vehicles and smart terminals, embedded devices face increasingly severe security threats during operation, including risks such as malware tampering, unauthorized firmware flashing, and theft of critical data. To address these threats, the industry typically integrates dedicated security chips or hardware security modules into controllers to handle core security functions such as key management, authentication, and data encryption / decryption, ensuring the trustworthiness and data security of the device during startup and operation.

[0003] However, in actual product development and deployment, due to objective factors such as cost budgets, material supply, and PCB space constraints, a significant number of embedded controllers are not equipped with dedicated security chips or security coprocessors. For these controllers lacking dedicated security hardware, current practices often rely solely on calculating hash digests of the program image to detect firmware tampering. While this method can detect unintended program changes to some extent, the hash value itself is stored in non-volatile memory. Attackers can replace the corresponding hash value while modifying the program image, thus bypassing the verification process. Furthermore, this method fails to provide encryption protection for sensitive operational data; critical configuration parameters and calibration data are still stored in plaintext on non-volatile media such as flash memory, posing a risk of direct reading or tampering.

[0004] In summary, existing technologies lack a technical means to achieve secure operation for embedded controllers that do not have dedicated security hardware, making it difficult to effectively defend against security threats such as firmware tampering and data leakage without increasing hardware costs. Summary of the Invention

[0005] In view of this, embodiments of this application provide a controller and its secure operation method and system, which can achieve secure operation of the controller by combining the unique characteristic information of the device in a software manner without relying on hardware security modules, and effectively resist security threats such as firmware tampering and data leakage.

[0006] A first aspect of this application provides a secure operation method for a controller, applied to a controller that does not include a hardware security module, the method comprising: Obtain the device-unique characteristic information of the controller; Based on the unique characteristic information of the device, a device root key is generated through a key derivation function; wherein, the device root key is stored in volatile memory and automatically becomes invalid after power failure; Derive functional keys based on the device root key; Use the function key to perform secure operations on the target data.

[0007] A second aspect of this application provides a secure operating system for a controller, applied to a controller that does not include a hardware security module, comprising: Information acquisition unit, used to acquire the device unique characteristic information of the controller; A key generation unit is used to generate a device root key based on the device's unique characteristic information through a key derivation function; wherein the device root key is stored in volatile memory; A key derivation unit is used to derive a function key based on the device root key; A security operation unit is used to perform security operations on target data using the function key.

[0008] A third aspect of this application provides a controller, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it causes the electronic device to implement the secure operation method of the controller provided in the first aspect of this application.

[0009] A fourth aspect of this application provides a computer program product including a computer program that, when run, causes the method described in the first aspect of this application to be performed.

[0010] The first aspect of this application provides a secure controller operation method that obtains unique device characteristic information, generates a device root key that exists only in volatile memory using a key derivation function, and derives a startup key from this root key to verify the legitimacy of the application image. Upon successful verification, the program is allowed to execute, thus achieving secure and reliable application startup without relying on hardware security modules. Alternatively, it encrypts and verifies the integrity of critical data by deriving a storage key based on the device root key, achieving secure storage and protection of runtime data. This solution requires no additional security hardware, reducing hardware costs while ensuring device security during startup and operation.

[0011] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating a safe operation method for a controller provided in one embodiment of this application; Figure 2 This is a flowchart illustrating a safe operation method for a controller according to another embodiment of this application; Figure 3 This is a flowchart illustrating a safe operation method for a controller according to another embodiment of this application; Figure 4 This is a schematic diagram of the structure of the secure operating system of the controller provided in the embodiments of this application. Detailed Implementation

[0014] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0015] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0016] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0018] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0020] The secure operation method for controllers provided in this invention can be applied to various embedded controllers that do not include hardware security modules, including but not limited to vehicle controllers (such as body control modules, domain controllers, gateway controllers, etc.), industrial controllers, and IoT terminal devices. In the above application scenarios, the controller typically uses a microcontroller chip (MCU) or microprocessor (MPU) as the core processing unit, combined with storage units such as flash memory and random access memory (RAM) to form a basic hardware platform. This invention implements secure boot and secure storage functions on the above hardware platform through software, specifically by the controller's processor running a bootloader or security management program with corresponding functions. This invention does not impose any restrictions on the specific type of controller or application scenario.

[0021] like Figure 1 As shown, in one embodiment, the present invention provides a secure operation method for a controller, applied to a controller that does not contain a hardware security module. The method includes the following steps S1 to S4 executed by the controller's processor: Step S1: Obtain the device unique characteristic information of the controller.

[0022] In applications, during the secure boot phase after the controller powers on, it is first necessary to obtain the controller's unique device characteristic information. This unique device characteristic information refers to inherent attribute data tightly bound to the controller hardware, uniquely identifying or representing the device. This information is non-replicable and device-specific; that is, different controllers correspond to different unique device characteristic information. The purpose of obtaining this unique device characteristic information is to provide input parameters bound to the device hardware for subsequent key derivation, ensuring that the generated key corresponds one-to-one with a specific physical device. This prevents attackers from reproducing the same key on other devices even if they obtain the implementation code of the key derivation algorithm.

[0023] In practice, the controller's processor can obtain the device's unique characteristic information by reading internal registers of the chip, accessing specific memory areas, or calling hardware interfaces. For example, the processor can obtain the chip's unique identifier (UID) by reading the unique identifier register written at the chip's manufacturing stage. This identifier is written by the manufacturer during the chip production phase and is unique to each chip.

[0024] Step S2: Based on the unique characteristic information of the device, generate the device root key through a key derivation function; wherein the device root key is stored in volatile memory.

[0025] In applications, after obtaining the device's unique characteristic information, this information is passed as input to the key derivation function, which then calculates and generates the device's root key. The key derivation function (KDF) is a class of cryptographic algorithms that derives a key with a specific length and cryptographic strength from one or more input values. The core characteristics of a key derivation function are: under the same input conditions, its output is deterministic; that is, each time the same device's unique characteristic information is used as input, the exact same device root key will be generated; furthermore, the input value cannot be reversibly derived from the output. Commonly used key derivation functions include HKDF and PBKDF2.

[0026] The device root key serves as the trust anchor for the entire security system. All subsequent working keys used for secure boot and secure storage are derived from this root key. The device root key exists only in volatile memory (such as RAM) and is never written to non-volatile storage media such as flash memory in plaintext or ciphertext. Volatile memory refers to storage devices whose stored data is automatically lost after a power outage, typically SRAM or DRAM. This means that the device root key automatically becomes invalid after each power outage and needs to be recalculated using the key derivation function upon the next power-on, thus avoiding the risk of the root key being directly read or extracted from non-volatile memory. Due to the deterministic output characteristic of the key derivation function, with the same unique device information input, the device root key recalculated each time power is applied is completely consistent with the previous one, ensuring the consistency of system functionality.

[0027] Step S3: Derive a function key based on the device root key.

[0028] In the application, this function key can be either a startup key or a storage key. The startup key is used to verify the legitimacy of the application image, while the storage key is used to encrypt critical data to obtain encrypted data.

[0029] Step S4: Perform a security operation on the target data using the function key.

[0030] In applications, security operations can include verifying the legitimacy of application images or encrypting critical data.

[0031] In one embodiment, the security operation is a secure boot operation, the target data is an application image to be booted, and the function key is a boot key; the step of performing a security operation on the target data using the function key includes: The application image is validated using the startup key; When the validity verification passes, the application image is allowed to execute.

[0032] In one embodiment, the security operation is a secure storage operation, the target data is critical data, and the function key is a storage key; performing the security operation on the target data using the function key includes: The key data is encrypted using the storage key to obtain encrypted data; The encrypted data is stored in a non-volatile memory.

[0033] like Figure 2As shown, this application embodiment also provides a secure boot method for a controller, applied to a controller that does not contain a hardware security module, the method including the following steps S101 to S105 executed by the controller's processor: Step S101: Obtain the device unique characteristic information of the controller.

[0034] Step S102: Based on the unique characteristic information of the device, generate a device root key through a key derivation function; wherein the device root key is stored in volatile memory.

[0035] Step S103: Derive the startup key based on the device root key.

[0036] In the application, after generating the device root key, a key derivation function is used to derive a dedicated working key for the secure boot phase, namely the boot key. The boot key is specifically used for verifying the legitimacy of the application image, and its cryptographic strength and purpose are determined by the context parameters used during the derivation process (such as the purpose identifier string and key length parameters). By deriving working keys for different purposes from the root key, key purpose isolation is achieved. This means that different security functions, such as boot verification and data storage, use their own independent keys, and the leakage of one working key will not directly affect the key security of other security functions.

[0037] Step S104: Read the application image to be launched and use the launch key to verify the legitimacy of the application image.

[0038] In the application, after the boot key is generated, the controller's bootloader reads the application image to be launched from non-volatile memory (such as Flash). The application image refers to the binary data of the application stored in non-volatile memory and to be loaded into the processor for execution. Legitimacy verification refers to using cryptographic methods to examine the application image to confirm that it has not been illegally tampered with and that its source is trustworthy. The bootloader uses the boot key derived in step S103 to perform legitimacy verification on the read application image. The specific verification method can be different, such as integrity verification or digital signature verification, depending on security requirements. Compared to simple hash verification, key-based legitimacy verification prevents attackers from forging matching verification data after modifying the application image, thus effectively preventing the loading and execution of unauthorized firmware.

[0039] Step S105: When the legality verification passes, the application image is allowed to execute.

[0040] In the application, when the legality verification in step S104 passes, it indicates that the content of the application image is complete, tamper-proof, and of a trustworthy origin. The bootloader then transfers program execution rights to the application, allowing it to load and run normally. Specifically, allowing the application image to execute means that after completing the verification, the bootloader jumps the processor's program counter to the application's entry address, causing the processor to begin executing the application code.

[0041] The secure boot method provided in the above embodiments achieves secure and reliable booting even without a hardware security module by obtaining unique device characteristic information and generating a device root key that exists only in volatile memory using a key derivation function. This root key is then used to derive a boot key to verify the legitimacy of the application image. The device root key is bound to the individual device hardware; different devices generate different root keys, preventing attackers from using information obtained from one device to attack another. The root key is stored only in volatile memory and becomes invalid upon power failure, significantly reducing the risk of it being stolen by attacks that read it from non-volatile memory. The use of key-based legitimacy verification instead of simple hash verification prevents attackers from forging corresponding verification data after tampering with the application image. The entire solution requires no additional security hardware support, reducing product hardware costs and supply chain complexity.

[0042] like Figure 3 As shown, this application embodiment also provides a secure storage method for a controller, applied to a controller that does not include a hardware security module, the method including the following steps S201 to S205 executed by the controller's processor: Step S201: Obtain the device unique characteristic information of the controller.

[0043] Step S202: Based on the unique characteristic information of the device, generate a device root key through a key derivation function; wherein the device root key is stored in volatile memory.

[0044] Step S203: Derive the storage key based on the device root key.

[0045] In applications, when critical data needs to be securely stored during controller operation, a storage key for data encryption must first be derived from the device root key. This storage key is a working key specifically used for encrypting and decrypting critical data. Similar to the derivation process of the startup key, the storage key is also derived using a key derivation function, with the device root key as the primary input and different context parameters (such as the usage identifier string "storage"), thus generating a storage key different from the startup key. This context parameter-based key usage isolation mechanism ensures that even if one working key is compromised, it will not directly affect the security of other working keys. Due to the deterministic output of the key derivation function, the storage key derived using the same device root key and context parameters is consistent each time, guaranteeing consistency in data encryption and decryption.

[0046] Step S204: Use the storage key to encrypt the key data to obtain encrypted data.

[0047] In the application, after obtaining the storage key, this key and a predetermined symmetric encryption algorithm are used to encrypt critical data, resulting in encrypted data. Critical data refers to sensitive information requiring security protection during controller operation, including but not limited to security access credentials, calibration parameters, encryption key materials, and device configuration information. The choice of symmetric encryption algorithm is determined based on security and performance requirements; commonly used algorithms include AES-128 and AES-256. The encryption process converts the original plaintext data into ciphertext that cannot be directly interpreted; only an entity possessing the correct storage key can decipher the ciphertext back to plaintext.

[0048] Step S205: Store the encrypted data in a non-volatile memory.

[0049] In applications, encrypted data is persistently stored in non-volatile memory such as flash memory. Non-volatile memory refers to storage devices that retain stored data even after power is lost; typical examples include NOR Flash, NAND Flash, and EEPROM. Because encrypted ciphertext data is stored, even if an attacker can directly read the contents of the non-volatile memory through physical means (such as chip disassembly or bus eavesdropping), they cannot recover the original plaintext data without knowing the storage key, thus achieving confidentiality protection for critical data.

[0050] The above embodiments achieve a unified key management system for secure boot and secure storage through a key derivation mechanism based on the device root key. The storage key and boot key originate from the same root key but are independent of each other, ensuring simplicity in key management while achieving usage isolation. Critical data is stored in encrypted form in non-volatile memory, effectively preventing unauthorized reading or theft of data in a static storage state, filling the gap in secure storage capabilities for critical data in the absence of hardware security modules.

[0051] In one embodiment, the device unique characteristic information includes at least one of the following: The unique identifier of the chip in the controller; The physical characteristics of the storage unit in the controller; The random number generated when the controller is powered on.

[0052] In applications, the unique characteristic information of a device can come from various inherent attributes at the hardware level. This embodiment will describe three typical information types respectively.

[0053] The Unique Identifier (UID) of a chip is a unique code written by the chip manufacturer into the read-only memory area inside the chip during the manufacturing stage. Each chip's UID is globally unique. The UID is typically embedded in a one-time programmable (OTP) area or a dedicated information area of ​​the chip, and user programs can obtain this identifier by reading a specific register address. Because the UID cannot be changed after the chip leaves the factory and is globally unique, it is a reliable source of device identification.

[0054] The physical characteristics of memory cells refer to the individual differences in memory devices such as flash memory or SRAM caused by process variations during manufacturing. For example, when SRAM is powered on in an uninitialized state, each memory cell exhibits a statistically stable initial value pattern (i.e., SRAM PUF, Physically Unclonable Function) due to minute differences in transistor threshold voltages. This pattern is unique to each individual chip and can be used as a device fingerprint. Similarly, the programming voltage characteristics and erase / write endurance parameters of flash memory cells also exhibit individual differences, serving as a source of unique device characteristic information.

[0055] The random number generated upon power-up refers to the random data generated by a hardware random number generator (TRNG) during the controller's initial power-up or initial configuration phase. This random number is written to a protected area of ​​non-volatile memory after its initial generation and is read from this area during each subsequent power-up, used in combination with other characteristic information to enhance the randomness and security of the device's unique characteristics. It should be noted that once generated and stored, this random number remains unchanged throughout the device's entire lifespan, thus ensuring the consistency of key derivation.

[0056] The above embodiments utilize various inherent hardware attributes as input sources for key derivation, fully leveraging the physical differences and non-replicability of individual chips. This deeply binds the device root key to a specific hardware entity, further enhancing key security and anti-cloning capabilities. Simultaneously, multiple information sources can be combined, improving the entropy value and collision resistance of the device identifier.

[0057] In one embodiment, the lifecycle of the device root key exists only during the key derivation phase. After the derivation of the function key is completed, the device root key is cleared from the volatile memory.

[0058] In this application, to further reduce the exposure of the device root key, this embodiment imposes strict constraints on the lifecycle of the device root key. The lifecycle of the device root key refers to the entire time span from its generation to its erasure from memory. The key derivation phase refers to the process from the generation of the device root key by the key derivation function to the derivation of all working keys (such as startup keys, storage keys, etc.) based on that root key. After the key derivation phase is completed, the device root key is actively cleared from volatile memory as a temporary variable, i.e., its occupied memory area is zeroed out or overwritten.

[0059] It's worth noting that, due to the high computation speed of the key derivation function, on modern embedded processors, the complete root key generation and working key derivation process can typically be completed within one millisecond. This means that the actual existence time of the device root key in volatile memory is extremely short, limiting the time window that could be exploited by attackers to a very short range. Furthermore, in scenarios with high hardware security requirements, disabling debug interfaces (such as JTAG, SWD, etc.) can further prevent attackers from reading the root key data in volatile memory through debug interfaces during the key derivation phase.

[0060] The above embodiments achieve an extreme reduction in the key exposure surface by minimizing the lifespan of the device root key. The root key exists in memory for only a very short time during key derivation and is completely deleted after derivation is completed. This significantly reduces the possibility of the root key being stolen by side-channel attacks, memory read attacks, and other methods, and significantly improves the security level of key management.

[0061] In one embodiment, verifying the legitimacy of the application image using the startup key includes: Use the boot key to perform integrity verification on the application image; Alternatively, the application image can be digitally signed using the startup key.

[0062] In applications, legitimacy verification can employ two different cryptographic implementations, which can be selected based on the controller's computing resources and security level requirements.

[0063] Integrity verification refers to calculating a Message Authentication Code (MAC) on all data in the application image using the boot key as a key parameter. Specifically, the bootloader uses the boot key and a pre-defined MAC algorithm (such as HMAC-SHA256, CMAC, etc.) to calculate a MAC value on the read application image. This MAC value is then compared with a reference MAC value pre-stored in a specific area of ​​non-volatile memory. The reference MAC value is calculated and stored on the original image using the same boot key and MAC algorithm when the application image is written to the controller. If the two MAC values ​​match, it indicates that the application image has not been modified since it was written, and the integrity verification passes. Because the MAC calculation depends on the boot key, an attacker cannot forge a valid MAC value for a tampered image without knowing the key, thus achieving key-based integrity protection.

[0064] Digital signature verification refers to the use of asymmetric cryptography to verify the signature of an application image. In this method, the application image is signed with a private key during the distribution phase, and the signature data is stored along with the image in non-volatile memory. During the secure boot phase, the controller verifies the signature using a public key paired with the private key (which can be derived from or protected by the boot key). If the verification passes, it indicates that the application image was indeed signed by the legitimate publisher holding the corresponding private key and has not been tampered with after signing. Digital signature verification can not only verify the integrity of the image but also the authenticity of its origin.

[0065] The above embodiments provide two verification methods with different security levels and computational complexity. Integrity verification is based on symmetric cryptography, which is computationally efficient and suitable for resource-constrained microcontrollers; digital signature verification is based on asymmetric cryptography, which offers a higher security level and is suitable for applications with more stringent security requirements. Both methods achieve strong authentication of the application image through key participation, providing higher security strength compared to simple hash verification.

[0066] In one embodiment, after allowing the application image to execute, the method further includes: When the validity verification fails, the controller enters a security failure state and restricts function execution.

[0067] In the application, when the legality verification result in step S104 fails, it indicates that the application image may have been tampered with or corrupted, posing a security risk. At this time, the controller will not transfer program execution control to the application, but will instead enter a predefined security failure state. This security failure state refers to a restricted operating mode that the controller actively enters after detecting a security threat. In this mode, the controller only maintains the most basic system functions (such as diagnostic communication and fault reporting), restricting or prohibiting the execution of normal application functions to prevent potential security hazards caused by untrusted program code running on the controller.

[0068] In practical implementation, the specific manifestation of a security failure state can be defined according to the application scenario. For example, in an automotive controller scenario, the controller can disable control outputs related to vehicle driving safety, retaining only the diagnostic communication interface for maintenance personnel to troubleshoot and restore the program. In an industrial controller scenario, the controller can switch actuator outputs to safe default values ​​and report security anomalies via status indicator lights or communication interfaces. The purpose of restricting function execution is to minimize the potential impact of tampered programs and ensure that the system maintains a basic security state even when attacked.

[0069] The above embodiments construct a complete secure startup closed loop by explicitly defining a secure failure mechanism after verification failure. This not only ensures the trusted execution of the program when verification passes, but also takes proactive protective measures when verification fails, preventing the operation of untrusted programs and improving the overall security robustness of the system.

[0070] In one embodiment, after storing the encrypted data in non-volatile memory, the method further includes: In response to a data read request, the encrypted data is read from the non-volatile memory; Perform integrity verification on the encrypted data; When the integrity verification passes, the encrypted data is decrypted using the storage key.

[0071] In applications, when a controller needs to use encrypted critical data during operation, it first needs to respond to a data read request and read the corresponding encrypted data from non-volatile memory. A data read request refers to a data access instruction issued by the controller's application or security management module when it needs to use certain critical data.

[0072] After reading the encrypted data, an integrity check is first performed to confirm that the data has not been illegally tampered with during storage. Integrity check refers to verifying, through cryptographic means, whether the data has remained unchanged since its last legitimate write. Specifically, during encrypted data storage, a Message Authentication Code (MAC) can be calculated simultaneously, or an encryption mode with authentication capabilities (such as AES-GCM) can be used, and the authentication tag is stored along with the encrypted data. Upon reading, the authentication tag of the encrypted data is recalculated and compared with the stored tag; if they match, it indicates that the data is intact and has not been tampered with.

[0073] Once the integrity verification passes, the stored key is used to decrypt the encrypted data, restoring the ciphertext to the original plaintext data for normal use by the controller's application. The decryption process uses the same symmetric encryption algorithm and stored key as the encryption. Due to the deterministic output characteristic of the key derivation function, even if the controller experiences a power outage and restart, the newly derived stored key remains consistent with the stored key used during encryption, thus enabling correct decryption.

[0074] The above embodiments achieve dual protection of the integrity and confidentiality of stored data by adding an integrity verification step before data decryption. The processing order of verification before decryption not only promptly detects data tampering but also avoids invalid decryption operations on tampered data, thus improving the security and efficiency of data processing.

[0075] In one embodiment, after performing integrity verification on the encrypted data, the method further includes: If the integrity check fails, perform security exception handling.

[0076] In applications, when the integrity verification of encrypted data fails, it indicates that the stored encrypted data may have been illegally tampered with or corrupted due to storage media failure, and the data's trustworthiness can no longer be guaranteed. At this point, the controller needs to execute security anomaly handling. Security anomaly handling refers to a series of predefined protection and recovery measures taken by the controller when it detects that the integrity of the stored data has been compromised.

[0077] In practical implementation, security anomaly handling may include, but is not limited to, the following operations: reporting data integrity anomalies to upper-layer applications or diagnostic systems so that maintenance personnel can be promptly informed and handle them; refusing to use tampered data and instead using preset security default values ​​to ensure that the controller can maintain a basic secure operating state even when the data is untrusted; recording security logs, writing the occurrence time and data identifier of the anomaly into the security log area for post-event auditing and source tracing analysis; and triggering system-level security response strategies, such as degraded operation or requesting remote recovery. Specific security anomaly handling strategies can be customized according to application scenarios and security level requirements.

[0078] The above embodiments improve the closed loop of security storage exception handling by defining a security exception handling mechanism after integrity verification failure. This ensures that the system can detect and take effective protective measures in a timely manner when stored data is tampered with, preventing functional abnormalities or security incidents that may be caused by untrusted data being used by applications.

[0079] This invention also provides a secure operating system on the controller for executing the steps described in the secure boot method embodiments. The secure boot system can be a virtual device within the controller, run by the controller's processor, or it can be the controller itself.

[0080] like Figure 4 As shown, in one embodiment, the secure operating system 100 provided by this invention is applied to a controller that does not include a hardware security module, the system comprising: Information acquisition unit 101 is used to acquire the device unique characteristic information of the controller; The key generation unit 102 is used to generate a device root key based on the device's unique characteristic information through a key derivation function; wherein the device root key is stored in volatile memory; Key derivation unit 103 is used to derive a function key based on the device root key; The security operation unit 104 is used to perform security operations on the target data using the function key.

[0081] In the application, the information acquisition unit 101 is responsible for reading the device's unique characteristic information from the chip after the controller is powered on and passing this information to the key generation unit 102. After receiving the device's unique characteristic information, the key generation unit 102 calls the key derivation function to calculate and generate the device root key, which is then temporarily stored in volatile memory. The device root key is then passed to the key derivation unit 103. The key derivation unit 103 derives a function key based on the device root key, which can be a startup key or a storage key. The function key is then passed to the security operation unit 104. The security operation unit 104 uses the function key to perform security operations on the target data.

[0082] This application also provides a controller, including: at least one processor, a memory, and a computer program stored in the memory and executable on at least one processor, wherein the processor executes the computer program to implement the steps in the above-described method embodiments.

[0083] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0085] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0086] This application provides a computer program product, including a computer program, which, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0088] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0089] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0090] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0091] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A safe operation method for a controller, characterized in that, The method, applied to a controller that does not include a hardware security module, comprises: Obtain the device-unique characteristic information of the controller; Based on the unique characteristics of the device, a device root key is generated through a key derivation function; wherein, the device root key is stored in volatile memory; Derive functional keys based on the device root key; Use the function key to perform secure operations on the target data.

2. The safe operation method as described in claim 1, characterized in that, The security operation is a secure boot operation, the target data is the application image to be booted, and the function key is the boot key; The step of performing a security operation on the target data using the function key includes: The application image is validated using the startup key; When the validity verification passes, the application image is allowed to execute.

3. The safe operation method as described in claim 1, characterized in that, The security operation is a secure storage operation, the target data is critical data, and the function key is a storage key; The step of performing a security operation on the target data using the function key includes: The key data is encrypted using the storage key to obtain encrypted data; The encrypted data is stored in a non-volatile memory.

4. The safe operation method as described in claim 1, characterized in that, The unique characteristic information of the device includes at least one of the following: The unique identifier of the chip in the controller; The physical characteristics of the storage unit in the controller; The random number generated when the controller is powered on.

5. The safe operation method as described in claim 1, characterized in that, The lifecycle of the device root key exists during the key derivation phase. After the derivation of the function key is completed, the device root key is cleared from the volatile memory.

6. The safe operation method as described in claim 2, characterized in that, The step of using the startup key to verify the legitimacy of the application image includes: Use the boot key to perform integrity verification on the application image; Alternatively, the application image can be digitally signed using the startup key.

7. The safe operation method as described in claim 2, characterized in that, Also includes: When the validity verification fails, the controller enters a security failure state and restricts function execution.

8. The safe operation method as described in claim 3, characterized in that, After storing the encrypted data in non-volatile memory, the method further includes: In response to a data read request, the encrypted data is read from the non-volatile memory; Perform integrity verification on the encrypted data; When the integrity verification passes, the encrypted data is decrypted using the storage key.

9. A secure operating system for a controller, characterized in that, A system for use with a controller that does not include a hardware security module, the system comprising: Information acquisition unit, used to acquire the device unique characteristic information of the controller; A key generation unit is used to generate a device root key based on the device's unique characteristic information through a key derivation function; wherein the device root key is stored in volatile memory; A key derivation unit is used to derive a function key based on the device root key; A security operation unit is used to perform security operations on target data using the function key.

10. A controller comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The controller does not include a hardware security module, and the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1 to 8.

Images