Safe starting method and device of programmable logic controller

Abstract

The invention provides a safe starting method and device of a programmable logic controller, a PUF circuit, a starting control unit and a password authentication unit are integrated on a main controller chip of a PLC system, and the method comprises the following steps: responding to power-on of the PLC system, activating the PUF circuit and generating a device root key; the starting control unit activates and operates the starting state machine; under the control of the starting state machine, the starting control unit executes the following step-by-step verification and loading processes: reading a code of a first-stage boot loader from a boot read-only memory of the PLC system, and checking; in the first stage, the boot loader reads encrypted firmware data and checks the encrypted firmware data; loading an operating system component or an application program of the PLC system, and checking; and if the inspection is passed, entering an operation state, and executing a corresponding industrial control task by the PLC system. Firmware tampering and unauthorized code execution are effectively resisted, and the starting safety and the operation reliability of the PLC system are comprehensively enhanced.

Description

Technical Field

[0001] This application relates to the field of equipment safety technology, and in particular to a safe startup method and a safe startup device for a programmable logic controller. Background Technology

[0002] A Programmable Logic Controller (PLC) is a digital computing electronic system designed specifically for industrial environments. It uses programmable memory to store instructions for performing logical operations, sequential control, timing, counting, and arithmetic operations, and controls various types of machinery or production processes through digital or analog input / output interfaces.

[0003] Currently, secure booting of PLC systems commonly employs a combination of external hardware security modules (such as Trusted Platform Module (TPM) and Trusted Cryptography Module (TCM)) and general encryption algorithms (such as Rivest–Shamir–Adleman (RSA) and Advanced Encryption Standard (AES)). Specifically, after the PLC powers on, the boot firmware calls a pre-stored key in the external hardware security module to perform digital signature verification or hash integrity checks on the bootloader and operating system image using a general encryption algorithm. Upon successful verification, the bootloader is loaded level by level, thus constructing a trusted boot chain.

[0004] However, in the aforementioned secure boot methods, the external hardware security module needs to communicate with the main processor via a bus (such as an internal integrated circuit (I2C) or a serial peripheral interface (SPI)) to provide key and computation services. This not only increases hardware cost and power consumption but also introduces potential attack surfaces (such as bus eavesdropping and man-in-the-middle attacks) into the communication link. Furthermore, the software-driven encryption and decryption verification process is prone to causing significant boot delays in resource-constrained PLC environments, affecting industrial real-time requirements. Therefore, current PLC secure boot methods are deficient in terms of boot security, hardware power consumption, and real-time performance. Summary of the Invention

[0005] The purpose of this application is to provide a safe startup method and a safe startup device for a programmable logic controller (PLC) to achieve a safer startup of the PLC system.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a secure startup method for a programmable logic controller (PLC) system. The method is applied to a PLC system, where the main controller chip integrates a Physically Unclonable Function (PUF) circuit, a startup control unit, and a cryptographic authentication unit. The method includes: in response to power-on of the PLC system, the PUF circuit is activated and generates a device root key; the startup control unit activates and runs a startup state machine, implemented in hardware logic or secure firmware, which predefines a sequence of security states containing multiple security states; under the control of the startup state machine, the startup control unit executes the following step-by-step verification and loading process: entering a first security state, reading the code of the first-stage bootloader from the PLC system's boot read-only memory, and calling the cryptographic authentication unit to perform integrity and authenticity verification on the code and its digital signature using a national cryptographic algorithm and a pre-set public key; if the verification fails... If the verification passes, the PLC system is reset; if the verification passes, proceed to the next step; enter the second security state, transfer control to the verified first-stage bootloader, which reads the encrypted firmware data and calls the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature; if the verification fails, the PLC system is reset; if the verification passes, proceed to the next step; enter the third security state, load the PLC system's operating system components or application programs, and call the cryptographic authentication unit to perform integrity verification based on hash value; if the verification fails, the PLC system is reset; if the verification passes, proceed to the next step; enter the running state, and the PLC system executes the corresponding industrial control tasks.

[0007] Compared to existing technologies, the secure startup method for programmable logic controllers provided in the first aspect of this application constructs a hardware-based intrinsic security root of trust and a fully verifiable PLC trusted startup mechanism by integrating a PUF circuit, a startup state machine, and a cryptographic authentication unit within the main controller chip. Replacing traditional external security modules with a unique device root key generated by the PUF eliminates the communication bus attack surface and reduces hardware cost and power consumption. Hardware-accelerated national cryptographic algorithms enable rapid verification at each startup stage, significantly improving startup efficiency and real-time performance. The step-by-step verification process controlled by the state machine forms a complete trust chain from the bootloader to the application layer, effectively resisting firmware tampering and unauthorized code execution, comprehensively enhancing the startup security and operational reliability of the PLC system.

[0008] In other embodiments provided in this application, the main controller chip also integrates a Key Management Unit (KMU) circuit, which is connected to the PUF circuit. The PUF circuit is a lightweight PUF circuit based on a linear feedback shift register. The PUF circuit is activated and generates a device root key, including: the PUF circuit generates an original unique device response, and the KMU circuit stabilizes the original unique device response to obtain the device root key.

[0009] By integrating a key management unit connected to a lightweight (Lightweight Linear Feedback ShiftRegister based, LR)-PUF circuit on the main controller chip, and using the KMU to perform error correction and other stabilization processing on the raw response generated by the PUF, the noise of the PUF output caused by environmental factors can be effectively overcome. This allows for the extraction of a high-entropy and stable device root key, ensuring that the hardware root of trust relied upon in the subsequent secure boot process has a high degree of determinism and consistency.

[0010] In other embodiments provided in this application, before the start control unit activates and runs the start state machine, the method further includes: starting the start control unit to obtain the device root key; calculating the hash value of the device root key; comparing the calculated hash value with a preset reference value burned into the one-time programmable memory or electronic fuse of the PLC system at the time of manufacture, wherein the preset reference value is the hash value corresponding to the device root key generated when the PUF circuit runs; if they match, then the step of activating and running the start state machine is performed; if they do not match, then the PLC system is reset.

[0011] By adding a verification step to check the authenticity of the device root key generated by PUF before starting the state machine after power-on, the hash value of the current key is compared with the reference hash value preset in the factory immutable memory (such as OTP / eFuse). This ensures the integrity and legitimacy of the hardware trust root at the initial stage of establishing the trust chain, effectively preventing the failure of the entire secure boot foundation due to PUF circuit failure, physical attack, or tampering during the key extraction process, and further strengthening the first line of defense for secure system boot.

[0012] In other embodiments provided in this application, the cryptographic authentication unit is implemented by a hardware cryptographic accelerator or security coprocessor integrated on the main controller chip; calling the cryptographic authentication unit to perform integrity and authenticity verification on the code and its digital signature using the national cryptographic algorithm and a preset public key includes: calling the cryptographic authentication unit to perform the following operations: calculating the hash value of the code using the SM3 algorithm; obtaining the preset SM2 public key in the device security zone of the PLC system; decrypting the digital signature attached to the code using the SM2 public key; if the decrypted hash value is the same as the calculated hash value, then the integrity and authenticity verification is determined to have passed; if the decrypted hash value is different from the calculated hash value, then the integrity and authenticity verification is determined to have failed.

[0013] By using a cryptographic authentication unit composed of a hardware cryptographic accelerator or a security coprocessor to perform SM3 hash calculations and SM2 signature verification, the complex cryptographic operations originally implemented in software are offloaded to dedicated hardware. This not only significantly improves the verification speed of bootloader and other startup code and significantly shortens system startup latency, but more importantly, it ensures the security of keys (such as SM2 public keys) and the cryptographic operation process itself through hardware isolation execution. This effectively resists side-channel attacks and runtime tampering at the software level, providing a high-performance and highly secure cryptographic operation foundation for the construction of a trusted boot chain.

[0014] In other embodiments provided in this application, the invocation of the cryptographic authentication unit to decrypt encrypted firmware data using the device root key and to perform integrity and authenticity verification based on hash value and electronic signature includes: invoking the cryptographic authentication unit to perform the following operations: decrypting the encrypted firmware data using the SM4 algorithm based on the device root key or its derived key to obtain plaintext firmware data; calculating the hash value of the plaintext firmware data using the SM3 algorithm; if the hash value of the plaintext firmware data is the same as the hash value of the same firmware data in the pre-secure storage area, the integrity verification is determined to be passed; if the hash value of the plaintext firmware data is different from the hash value of the same firmware data in the pre-secure storage area, the integrity verification is determined to be failed; decrypting the digital signature of the encrypted firmware data using the SM2 algorithm and its corresponding public key; if the decrypted hash value is the same as the hash value of the plaintext firmware data, the authenticity verification is determined to be passed; if the decrypted hash value is different from the hash value of the plaintext firmware data, the authenticity verification is determined to be failed.

[0015] The firmware data undergoes triple security protection through a cryptographic authentication unit, sequentially performing SM4 decryption, SM3 hash verification, and SM2 signature verification: decryption verification → integrity verification → source authenticity authentication. The SM4 algorithm ensures the confidentiality of firmware storage, the SM3 hash comparison verifies the integrity of the decrypted firmware content, and the SM2 signature verification confirms the trusted identity of the firmware publisher. These three elements combine to form an end-to-end trusted verification chain for the firmware from its storage form to its operational content, effectively resisting attacks such as theft, tampering, and forgery of firmware data during storage or transmission.

[0016] In other embodiments provided in this application, invoking the cryptographic authentication unit to perform integrity checks on operating system components or applications based on hash values ​​includes: invoking the cryptographic authentication unit to perform the following operations: calculating the hash value of the operating system component or application using the SM3 algorithm; if the hash value of the operating system component or application is the same as the hash value of the same operating system component or application in the pre-secure storage area, then the integrity check is determined to be passed; if the hash value of the operating system component or application is different from the hash value of the same operating system component or application in the pre-secure storage area, then the integrity check is determined to be failed.

[0017] By introducing hash integrity verification based on the SM3 algorithm during the operating system and application loading phase, the hash value of the currently loaded component is compared with the baseline hash value pre-stored in the secure area. This can efficiently and sensitively detect any subtle tampering that may occur during the storage or loading of the code, thereby ensuring that only certified clean software components can be loaded and executed. This effectively prevents malicious code injection or accidental program corruption, laying a reliable integrity foundation for the upper-level application operating environment of the PLC system.

[0018] In other embodiments provided in this application, the operating system component or application contains sensitive information and is stored in the general storage area of ​​the PLC system in ciphertext form. The ciphertext is obtained by encrypting the key derived from the device root key using the SM4 algorithm. Before calculating the hash value of the operating system component or application using the SM3 algorithm, the method further includes: reading the ciphertext from the general storage area; calling the cryptographic authentication unit to decrypt the ciphertext based on the derived key using the SM4 algorithm to obtain the plaintext data of the operating system component or application.

[0019] By using the SM4 algorithm to encrypt operating system components or applications containing sensitive information, and deriving the encryption key from the device's unique PUF root key, even if an attacker can physically access and read ordinary storage areas, they cannot obtain meaningful plaintext code or data. This ensures storage security while allowing encrypted software to be stored on lower-cost, higher-capacity ordinary storage media, achieving a good balance between security, storage cost, and flexibility.

[0020] In other embodiments provided in this application, the method further includes a trusted execution phase: after entering the running state, the following steps are periodically or triggered to execute: collect runtime data of the PLC system; call the cryptographic authentication unit, use the SM3 algorithm to generate a hash value of the runtime data, and use the SM2 algorithm to generate a digital signature of the hash value based on the derived session key of the device root key; send the digital signature as an integrity report to the remote monitoring platform for verification, or perform local verification; and decide whether to take security protection measures for the PLC system based on the verification results.

[0021] By extending the trusted startup mechanism to the operation phase, and using hardware-accelerated SM3 and SM2 algorithms to perform periodic hash calculations and digital signatures on PLC runtime data, continuous and proactive trusted verification and auditing of the system's operating status are achieved. This not only enables timely detection of potential malicious tampering or abnormal behavior during operation, but also provides verifiable integrity reports for remote monitoring platforms, thereby constructing an end-to-end dynamic trusted assurance system from startup and loading to the entire lifecycle operation.

[0022] In other embodiments provided in this application, the runtime data consists of multiple continuously generated data; generating the hash value of the runtime data using the SM3 algorithm includes: calculating the hash value of each runtime data separately using the SM3 algorithm, concatenating all hash values, and then calculating the hash value again using the SM3 algorithm to obtain the final hash value; or, aggregating all runtime data and then calculating the hash value of the aggregated data using the SM3 algorithm to obtain the final hash value.

[0023] For continuously generated runtime data, two efficient batch data integrity digest generation strategies are provided (recursive hashing after separate hashing, or one-time hashing after aggregation). Both strategies can utilize the characteristics of the SM3 algorithm to compress any amount of runtime status data within any time period into a fixed-length, irreversible, unique hash value for signing. This significantly reduces the amount of data that needs to be transmitted and signed, and while ensuring that any data tampering can be detected, it significantly improves the efficiency of trusted verification during the runtime phase and the utilization rate of communication bandwidth.

[0024] The second aspect of this application provides a secure startup device for a programmable logic controller (PLC). The device is integrated onto the main controller chip of a PLC system and includes: a PUF module configured to be activated and generate a device root key in response to power-on of the PLC system; a startup state machine implemented in hardware logic or secure firmware, wherein a predefined sequence of security states containing multiple security states is defined; a startup control unit connected to both the PUF module and the startup state machine, configured to activate and run the startup state machine; the startup control unit is further configured to, under the control of the startup state machine, perform corresponding operations based on the current security state to advance the step-by-step verification and loading process; and a password authentication unit connected to the startup control unit, configured to perform encryption, decryption, hash calculation, and digital signature verification operations in response to a call from the startup control unit; specifically, the startup control unit is configured to: when the startup state machine enters the first security state, read the code of the first-stage bootloader from the PLC system's boot read-only memory and call the password authentication unit to verify the code and its digital signature. The system performs integrity and authenticity checks. If the checks fail, the PLC system is reset. If the checks pass, the startup state machine is controlled to enter the second security state. When the startup state machine enters the second security state, control is transferred to the verified first-stage bootloader, which reads the encrypted firmware data and calls the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity checks based on hash value and electronic signature. If the checks fail, the PLC system is reset. If the checks pass, the startup state machine is controlled to enter the third security state. When the startup state machine enters the third security state, the PLC system's operating system components or application programs are loaded, and the cryptographic authentication unit is called to perform integrity checks based on hash value. If the checks fail, the PLC system is reset. If the checks pass, the startup state machine is controlled to enter the running state, allowing the PLC system to execute corresponding industrial control tasks.

[0025] The safe startup device for a programmable logic controller provided in the second aspect of this application has the same or similar beneficial effects as the safe startup method for a programmable logic controller provided in the first aspect. Attached Figure Description

[0026] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a schematic diagram illustrating an application scenario of the secure startup method for a programmable logic controller in this application. Figure 2This is a flowchart illustrating the secure startup method for a programmable logic controller in an embodiment of this application. Figure 1 ; Figure 3 This is a flowchart illustrating the secure startup method for a programmable logic controller in an embodiment of this application. Figure 2 ; Figure 4 This is a schematic diagram of the structure of the safe start device of the programmable logic controller in the embodiments of this application. Detailed Implementation

[0027] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0028] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0029] Traditional PLC safe startup solutions mainly suffer from three technical problems: First, they rely on external hardware security modules (such as TPM / TCM), which not only increases additional hardware costs and power consumption, but also introduces security risks such as eavesdropping and man-in-the-middle attacks on the communication bus (such as I2C, SPI) between the module and the main processor; second, key security operations such as encryption / decryption and signature verification are usually implemented in software, which can cause significant startup delays in resource-constrained PLC environments, making it difficult to meet the real-time requirements of industrial control; and third, the commonly used general encryption algorithms (such as RSA, AES) may not meet the compliance requirements of specific regions or industries for cryptographic algorithms.

[0030] In view of this, embodiments of this application provide a secure boot method and a secure boot device for a programmable logic controller (PLC). By integrating a PUF circuit, a boot control unit, and a hardware-accelerated cryptographic authentication unit within the PLC main controller chip, an intrinsic, hardware-based root of trust is constructed. A unique device root key generated by the PUF replaces external security modules, eliminating the communication bus attack surface. A hardware-implemented boot state machine strictly controls and executes a step-by-step verification process based on national cryptographic algorithms (i.e., national commercial cryptographic algorithms), performing integrity and authenticity checks and decryption on each layer of code from the bootloader, firmware, operating system, and applications, forming a complete hardware-level trusted boot chain. This improves security while ensuring boot efficiency and real-time performance.

[0031] First, the application scenarios of the secure startup method for a programmable logic controller provided in the embodiments of this application will be described.

[0032] Figure 1 This is a schematic diagram illustrating an application scenario of the secure startup method for a programmable logic controller in this application. See also... Figure 1 As shown, the scenario may include: PLC system 11.

[0033] The main controller chip of the PLC system 11 integrates a PUF circuit 111, a start control unit 112, and a password authentication unit 113. The PLC system 11 also includes a start state machine 114.

[0034] Integrating security modules such as PUF circuits, startup control units, and cryptographic authentication units onto the main controller chip of a PLC system aims to build an intrinsic, tightly coupled hardware security architecture. This on-chip integration fundamentally eliminates the additional hardware costs, communication bus overhead, and side-channel attack surfaces introduced by relying on external independent security modules (such as TPM) in traditional solutions. Simultaneously, embedding key security functions (such as key generation, cryptographic operations, and flow control) within the chip not only significantly improves verification efficiency and shortens startup latency to meet industrial real-time requirements through hardware acceleration, but also effectively protects against software-level tampering and attacks through physical isolation. This establishes a self-generating, inseparable, highly efficient, and controllable root of trust and secure execution environment for the PLC system.

[0035] Under the strict coordination of the startup state machine, each module forms a tightly linked, trusted startup chain: the PUF circuit is activated upon power-up, generating a unique and unclonable device root key, serving as the hardware foundation of the entire trust system. The startup control unit then activates and drives the startup state machine, strictly following its predefined sequence of "first security state → second security state → third security state → running state." In the first security state, the startup control unit calls the cryptographic authentication unit to verify the Bootloader's code and signature using national cryptographic algorithms (such as SM2 / SM3). Upon successful verification, the state machine transitions to the second security state, transferring control to the verified Bootloader, which continues to call the cryptographic authentication unit to perform SM4 decryption and SM2 / SM3 verification on the encrypted firmware using the device root key. Subsequently, it enters the third security state to perform SM3 hash integrity verification on the operating system or application. The cryptographic authentication unit acts as the security computing engine throughout, responding to calls at each stage and performing encryption / decryption, hash calculations, and signature verification. If any verification fails, the startup state machine triggers a system reset through the startup control unit, ensuring that untrusted code cannot be executed. The entire interaction process is implemented in the form of hardware logic or security firmware, ensuring that the process cannot be skipped and that the execution is deterministic.

[0036] Next, the secure startup method for a programmable logic controller provided in the embodiments of this application will be described in detail.

[0037] Figure 2 This is a flowchart illustrating the secure startup method for a programmable logic controller in an embodiment of this application. Figure 1 See Figure 2 As shown, the method may include: S21: In response to the power-on of the PLC system, the PUF circuit is activated and a device root key is generated.

[0038] This is the hardware root of trust establishment phase for trusted system startup. When the PLC system is powered on, the built-in PUF circuit generates a unique, unpredictable, and unclonable original response based on microscopic physical differences generated during chip manufacturing (such as random deviations in transistor threshold voltage).

[0039] The response can be stabilized, key derived and securely stored directly at the hardware level by using a dedicated hardware security module (HSM) or cryptographic coprocessor integrated in the chip, combined with a hardware acceleration engine for PUF and Chinese cryptographic algorithms. Alternatively, it can be stabilized by error correction and other processes using a KMU, and finally a stable, high-entropy device root key can be extracted.

[0040] This key serves as the cryptographic foundation for the entire secure boot process. It requires no external storage or injection, fundamentally avoiding the risk of key leakage or cloning. It realizes the "chip as trust" security paradigm and provides a unique and uncopyable hardware-level trust source for all subsequent encryption and verification operations.

[0041] S22: The startup control unit activates and runs the startup state machine, which is implemented in the form of hardware logic or security firmware, wherein a predefined sequence of security states containing multiple security states is defined.

[0042] The startup control unit, or BUC for short, is a control unit for starting the engine.

[0043] The boot state machine, also known as the boot sequencer or boot state machine, can be abbreviated as BSM.

[0044] This marks the formal control and execution phase of the trusted boot process. After power-on, the boot control unit first obtains the verified device root key from the PUF-KMU, and then activates and runs the boot state machine implemented in the form of hardware logic or secure firmware.

[0045] The startup state machine predefines a strictly ordered sequence of secure states (such as key verification, bootloader verification, firmware verification, application loading, etc.), acting as a hardwired commander of the process to ensure that the system must proceed step by step according to the predetermined state sequence, and no step can be skipped or bypassed. Once the state machine starts, it takes over the scheduling of all subsequent verification and loading steps, providing a mandatory execution framework for building an immutable and trusted startup chain.

[0046] S23: Under the control of the startup state machine, the startup control unit executes the following step-by-step verification and loading process.

[0047] The next step is the core execution phase of the trusted boot chain. Under the strict timing and logic control of the boot state machine, the boot control unit sequentially enters each predefined security state and triggers the corresponding level of code verification and loading operations. This ensures that the system can only proceed in the order of "bootloader → firmware → operating system / application," and can only proceed after cryptographic verification at each level, thus building an interlocking and uninterrupted hardware-level trust transfer chain.

[0048] S231: Enter the first security state, read the code of the first-stage bootloader from the boot read-only memory of the PLC system, and call the password authentication unit to perform integrity and authenticity verification on the code and its digital signature using the national cryptographic algorithm and the preset public key; if the verification fails, reset the PLC system; if the verification passes, proceed to the next step.

[0049] This is the first critical verification step in establishing a trusted bootstrap chain. Its core objective is to rigorously verify the source trustworthiness and integrity of the first piece of code executed by the system (i.e., the bootloader).

[0050] Driven by the startup state machine, the startup control unit enters the "first security state", reads the Bootloader code from the immutable boot read-only memory, and immediately calls the password authentication unit to perform dual verification using hardware-accelerated national cryptographic algorithms.

[0051] The national cryptographic algorithms mentioned here can include SM2 elliptic curve public key cryptography, SM3 cryptographic hash algorithm, SM4 block cipher algorithm, etc.

[0052] First, the digest value of the code is calculated using the SM3 hash algorithm to verify whether it has been tampered with (integrity). Then, the digital signature attached to the code is decrypted and verified using the SM2 public key pre-installed in the device's security zone. The hash value in the signature is compared with the calculated hash value to confirm whether the code comes from a trusted issuer (authenticity).

[0053] Alternatively, verification can be based on a symmetric key authentication code. The boot control unit reads the code of the first-stage bootloader and its accompanying authentication code (such as a Cipher-based Message Authentication Code (CMAC) generated based on the SM4 algorithm) from the boot read-only memory. It then invokes the cryptographic authentication unit to calculate the authentication code of the code using the device root key (or a specific key derived from it), and compares the calculated result with the accompanying authentication code. If they match, the integrity and authenticity of the code (i.e., generated by a trusted party holding the same key) are verified. This method eliminates the need for asymmetric encryption / decryption operations, resulting in faster verification. However, it relies on the verifier securely holding the same key as the signer, and is typically suitable for closed, controlled supply chain environments.

[0054] Any verification failure will trigger a system reset, preventing any unauthorized or tampered code from gaining execution rights and laying a solid foundation for trust transfer in all subsequent stages.

[0055] S232: Enter the second security state, transfer control to the verified first-stage bootloader, which reads the encrypted firmware data and calls the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature; if the verification fails, the PLC system is reset; if the verification passes, proceed to the next step.

[0056] This is the second-level verification and loading stage of the trusted boot chain, marking the first time that system control has been transferred from the underlying hardware state machine to the verified software entity (i.e., the first-stage bootloader).

[0057] The firmware data is stored in encrypted form at this time to protect the intellectual property rights and core logic of the firmware. This prevents attackers from directly obtaining, analyzing, and tampering with the executable plaintext code when the storage medium (such as Flash) is physically read or leaked, thereby ensuring the confidentiality of the firmware in its static storage state.

[0058] In this state, the Bootloader, as the currently trusted execution agent, actively reads encrypted firmware data (usually referring to the second-stage bootloader or operating system kernel) from the storage medium and calls the cryptographic authentication unit to execute a composite verification process.

[0059] First, the encrypted firmware is decrypted using the SM4 algorithm based on the device root key generated by the PUF (or its derived firmware decryption key), yielding the plaintext firmware. Then, the hash value of this plaintext is calculated using the SM3 algorithm and compared with a baseline hash value stored securely beforehand (such as One-Time Programmable (OTP) memory or a protected flash memory area) to verify that the firmware content has not been tampered with (integrity check). Finally, the digital signature attached to the firmware is decrypted using a pre-configured SM2 public key, and the resulting hash value is compared with the previously calculated hash value to confirm that the firmware originated from a trusted issuer (authenticity check).

[0060] Alternatively, an integrated verification process can be performed using an authentication encryption mode (such as SM4-GCM or SM4-CCM). In this method, firmware data is stored in an authentication encryption mode (such as GCM), and the output includes ciphertext and an authentication tag. The bootloader invokes the cryptographic authentication unit, using a key derived from the device root key, to perform authentication and decryption operations on the ciphertext data. This operation completes decryption and authentication simultaneously in a single process: the algorithm internally verifies the authentication tag, and only outputs the correct plaintext firmware if it confirms that the ciphertext has not been tampered with during transmission and storage (integrity) and was encrypted by an entity holding the correct key (authenticity); otherwise, it directly returns a verification failure. This approach integrates decryption, integrity verification, and source authentication into a single, efficient atomic operation, further simplifying the verification logic and improving processing speed.

[0061] If any step fails, the system will immediately reset, ensuring that any tampered or unknown firmware cannot be loaded and executed, thus reliably extending the trust chain from the Bootloader to the upper-level system firmware.

[0062] S233: Enter the third security state, load the operating system components or application of the PLC system, and call the password authentication unit to perform an integrity check on it based on the hash value; if the check fails, reset the PLC system; if the check passes, proceed to the next step.

[0063] This is the final software layer verification stage of the trusted bootstrap chain. Its core objective is to ensure the purity and integrity of the code before the operating system and application are loaded and executed.

[0064] Under the control of the startup state machine, the system enters the third security state, at which point the verified firmware (such as the operating system kernel) begins to load operating system components or user applications.

[0065] During the loading process, the startup control unit or firmware will call the cryptographic authentication unit to perform a hash integrity check based on the SM3 algorithm on each software module to be loaded. That is, calculate the hash value of the module and compare it with a baseline hash value generated by a trusted party and pre-stored in a secure area (such as a signature-protected configuration area or secure boot partition).

[0066] Alternatively, an attribute-based dynamic measurement and remote verification mechanism can be employed. In this approach, the system no longer simply compares hash values ​​statically, but dynamically calculates multiple security attributes of the software module (such as code hashes, configuration settings, memory layout, etc.) during loading, generating a structured measurement report. Subsequently, the cryptographic authentication unit uses the device's unique identity key (derived from the PUF) to digitally sign the measurement report, forming a piece of evidence. This evidence can be sent to a remote verification service for verification. The verifier not only checks the code hash but also evaluates all attributes according to predefined security policies (whitelists, version requirements, etc.), thereby achieving stronger verification of whether the software state conforms to the expected security policy (authenticity) while verifying integrity. This approach is more suitable for complex industrial IoT scenarios that require dynamic trust integration with the cloud or management platform.

[0067] If both are consistent, it proves that the software has not been tampered with since its release, the integrity check has passed, and it is allowed to be loaded and ultimately granted execution rights. If they are inconsistent, it indicates that the software may have been corrupted or replaced, and the system will immediately trigger a reset to prevent potential malicious code from contaminating the operating environment, thereby providing a reliable software execution foundation for the industrial control tasks above the PLC.

[0068] S234: Entering the running state, the PLC system executes the corresponding industrial control tasks.

[0069] This marks the final closed loop of the trusted boot chain. After ensuring that each level, from the hardware root of trust, bootloader, firmware to the operating system and application software, has passed strict cryptographic verification, the system officially enters a secure and reliable operating environment and begins to execute the predetermined industrial control tasks, thus achieving full-process security and controllability from the boot source to the function execution.

[0070] As described above, the secure startup method for programmable logic controllers provided in this application integrates a PUF circuit, a startup state machine, and a cryptographic authentication unit within the main controller chip, constructing a hardware-based intrinsic security root of trust and a fully verifiable PLC trusted startup mechanism. Replacing traditional external security modules with a unique device root key generated by the PUF eliminates the communication bus attack surface and reduces hardware cost and power consumption. Hardware-accelerated national cryptographic algorithms enable rapid verification at each startup stage, significantly improving startup efficiency and real-time performance. The step-by-step verification process controlled by the state machine forms a complete trust chain from the bootloader to the application layer, effectively resisting firmware tampering and unauthorized code execution, comprehensively enhancing the startup security and operational reliability of the PLC system.

[0071] Furthermore, as a response to Figure 2 In a refinement and extension of the method shown, this application embodiment also provides a secure startup method for a programmable logic controller.

[0072] Figure 3 This is a flowchart illustrating the secure startup method for a programmable logic controller in an embodiment of this application. Figure 2 See Figure 3 As shown, the method may include: S31: In response to the power-on of the PLC system, the PUF circuit generates the original unique device response, and the KMU circuit stabilizes the original unique device response to obtain the device root key.

[0073] The main controller chip also integrates a key management unit (KMU) circuit. The KMU circuit is connected to the PUF circuit. The PUF circuit is a lightweight PUF circuit based on a linear feedback shift register.

[0074] The PUF-KMU is a core hardware security submodule integrated on the main controller chip. It consists of a lightweight, physically unclonable function circuit based on a linear feedback shift register (LFSR) tightly coupled with a key management unit circuit. The LR-PUF circuit utilizes the unclonable physical differences introduced during chip manufacturing to generate a unique but noisy original device response upon power-up. The directly connected KMU circuit then uses a built-in fuzzy extractor (typically including error-correcting codes and an entropy extractor) to stabilize this original response in real time, filtering out environmental noise and improving entropy uniformity. The final output is a stable, reliable, and cryptographically strong device root key.

[0075] This integrated design achieves a fully on-chip closed loop of "response generation-key extraction," eliminating the need for external key storage. It provides an unclonable hardware root of trust while ensuring key consistency and availability, making it the cornerstone for building an intrinsically secure boot system.

[0076] In cases where the PUF circuit experiences characteristic drift or failure due to aging, physical attacks, or manufacturing defects, the generated device root key may deviate from the legitimate key recorded at the factory. Directly using this abnormal key for subsequent verification would result in the entire trusted boot chain being built on an unreliable root of trust. Therefore, a key self-verification step is added before the boot state machine runs. By comparing the current key hash value with the reference hash value burned into the immutable storage (OTP / eFuse) at the factory, it ensures that the hardware root of trust used for this boot is strictly consistent with the original device identity, thereby eliminating systemic security risks caused by PUF failure or key tampering from the source.

[0077] S32: Start the control unit to obtain the device root key; calculate the hash value of the device root key; compare the calculated hash value with the preset reference value burned into the one-time programmable memory or electronic fuse of the PLC system at the factory. The preset reference value is the hash value corresponding to the device root key generated when the PUF circuit is running; if they match, execute S33; if they do not match, execute S35.

[0078] It's important to note that the preset reference value used for comparison is not the directly stored plaintext of the device root key. Instead, it's the cryptographic hash value (such as an SM3 digest) corresponding to the legitimate root key generated by the PUF circuit during its first stable operation in a calibrated environment during the device's factory testing phase. This hash value is burned into an immutable OTP or eFuse at the factory. Each subsequent power-on startup, the system calculates the hash value of the newly generated device root key in real time and compares it with this pre-stored reference hash value. This design ensures that the comparison process itself does not leak the plaintext key, while effectively verifying whether the key output by the current PUF is consistent with the legitimate key registered at the factory, thereby detecting whether the PUF has drifted or been physically tampered with.

[0079] S33: Startup control unit activates and runs startup state machine, which is implemented in the form of hardware logic or security firmware, wherein a predefined sequence of security states containing multiple security states is defined.

[0080] S34: Under the control of the startup state machine, the startup control unit executes the following step-by-step verification and loading process.

[0081] S341: Enter the first security state, read the code of the first-stage bootloader from the boot read-only memory of the PLC system, and call the password authentication unit to perform integrity and authenticity verification on the code and its digital signature using the national cryptographic algorithm and the preset public key; if the verification fails, reset the PLC system; if the verification passes, execute S342.

[0082] Specifically, the password authentication unit is invoked to perform the following operations: Step A1: Calculate the hash value of the code using the SM3 algorithm.

[0083] A hash value, also known as a message digest, is a fixed-length digital fingerprint obtained by calculating a piece of data (such as code) using a hash algorithm (such as SM3).

[0084] Step A2: Obtain the SM2 public key preset in the device security zone of the PLC system.

[0085] The device security area is a hardware-protected storage area inside the main controller chip. This area is typically isolated through the chip's security mechanisms (such as memory protection units, encrypted storage, and access control logic) to ensure that sensitive information stored therein (such as the SM2 public key in this example) cannot be illegally read, modified, or erased by unauthorized software or external debugging interfaces.

[0086] An SM2 key pair contains a private key and a public key. The private key must be kept strictly confidential and is used to generate digital signatures. The public key can be publicly distributed and used to verify signatures. Here, the SM2 public key used for verification is provided by the legitimate issuer of the code (such as the device manufacturer) and is pre-installed in the device's secure area before the device leaves the factory.

[0087] Step A3: Decrypt the digital signature attached to the code using the SM2 public key.

[0088] A digital signature is a specific piece of data generated by the code issuer using their SM2 private key to encrypt the hash value of the code. It is equivalent to the issuer's electronic seal on the code, proving that the code was issued by them and that its content has not been changed.

[0089] Specifically, the SM2 public key is used to perform verification operations on the digital signature.

[0090] The legitimate issuer first generates the SM3 hash value H1 of the code, and then encrypts H1 using their own SM2 private key (i.e., performs a signature operation) to obtain the digital signature Sig. Sig will be distributed along with the code.

[0091] The device independently calculates the SM3 hash value H2 of the code to be verified through step A1. The operation performed on the device is not to directly decrypt the hash value using the public key, but rather to input the received digital signature Sig and the locally calculated hash value H2 into the SM2 verification algorithm. The SM2 verification algorithm uses the preset SM2 public key to perform a series of operations on the signature Sig (this is not simple decryption, but includes elliptic curve point operations, etc.), ultimately yielding a result. This result needs to be compared with H2.

[0092] If the output of the SM2 verification algorithm matches the locally calculated H2, it means that the signature Sig was indeed generated by the private key paired with the current public key (authenticity verification passed). If the original object of the signature (i.e., the hash value H1 calculated at the time of issuance) is the same as the hash value H2 of the code being verified, it means that the code has not been tampered with since signing (integrity verification passed). Otherwise, verification fails.

[0093] Step A4: If the decrypted hash value is the same as the calculated hash value, then the integrity and authenticity verification is passed.

[0094] Step A5: If the decrypted hash value is different from the calculated hash value, then the integrity and authenticity verification has failed.

[0095] S342: Enter the second security state, transfer control to the verified first-stage bootloader, which reads the encrypted firmware data and calls the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature; if the verification fails, the PLC system is reset; if the verification passes, S343 is executed.

[0096] Specifically, the password authentication unit is invoked to perform the following operations: Step B1: Based on the device root key or its derived key, use the SM4 algorithm to decrypt the encrypted firmware data to obtain the plaintext firmware data.

[0097] A derived key is a subkey generated from the device root key using a specific key derivation function (such as SM3 KDF). It is used for different security purposes (such as firmware decryption and session encryption) to achieve secure isolation with one key serving multiple purposes.

[0098] Firmware plaintext data, which is the original firmware code obtained after being decrypted by SM4 and can be directly read and executed by the processor.

[0099] Encrypted firmware data may include plain encrypted data or authenticated encrypted data. If it is the former (SM4 encryption only), this step performs standard decryption. If it is the latter (such as SM4-GCM mode), the decryption process will simultaneously verify the data integrity tag. If the tag is invalid, decryption will fail. This essentially moves the integrity check to the forefront.

[0100] Step B2: Calculate the hash value of the firmware plaintext data using the SM3 algorithm.

[0101] Step B3: If the hash value of the firmware plaintext data is the same as the hash value of the same firmware data in the pre-secure storage area, then the integrity check is considered to have passed.

[0102] The pre-secure storage area is a hardware-protected storage area within the chip (such as OTP or secure flash partition) used to store critical security parameters such as firmware decryption keys and hash base values ​​to prevent unauthorized tampering.

[0103] Step B4: If the hash value of the firmware plaintext data is different from the hash value of the same firmware data in the pre-secure storage area, then the integrity check has failed.

[0104] Step B5: Decrypt the digital signature of the encrypted firmware data using the SM2 algorithm and its corresponding public key.

[0105] Digital signature decryption refers to using the SM2 public key to perform verification operations on a digital signature in order to recover the hash value bound to the signature, which is used to verify the authenticity of the signature's origin.

[0106] In other words, a verification algorithm is executed on the digital signature attached to the firmware using a pre-configured SM2 public key to obtain a hash value. This result is then compared with the plaintext hash value of the firmware calculated in step B2. The consistency verification proves that the signature was generated by a trusted party (such as the firmware developer) holding the corresponding private key for this firmware hash value, thus verifying the authenticity of the source.

[0107] Step B6: If the decrypted hash value is the same as the hash value of the firmware plaintext data, then the authenticity verification is confirmed to be successful.

[0108] Step B7: If the decrypted hash value is different from the hash value of the firmware plaintext data, then the authenticity verification has failed.

[0109] Steps B3 and B4 (integrity check) and B5 and B6 (authenticity check) are logically independent. In practice, they can be executed in parallel or sequentially, but both must pass to be considered a successful verification.

[0110] This constructs a defense-in-depth system. First, SM4 decryption ensures the confidentiality of firmware storage. Then, SM3 hash comparison provides an independent integrity check. Finally, SM2 signature verification provides strong authentication. This triple mechanism of "decryption + hash + signature" is more effective than a single verification method (such as verifying only the signature) in dealing with various attack scenarios (such as data flipping on the storage medium, leakage of the signature key but not the firmware hash library), significantly improving the security robustness of the firmware loading phase.

[0111] S343: Enter the third security state, load the operating system components or application of the PLC system, and call the password authentication unit to perform an integrity check on it based on the hash value; if the check fails, reset the PLC system; if the check passes, execute S37.

[0112] Specifically, the password authentication unit is invoked to perform the following operations: Step C1: Calculate the hash value of the operating system component or application using the SM3 algorithm.

[0113] Operating system components are modules or drivers that make up the core functions of an operating system, such as the kernel, file system, and network protocol stack.

[0114] An application program is a user program that runs on top of an operating system to implement specific industrial control functions (such as logic control and motion planning).

[0115] Step C2: If the hash value of the operating system component or application is the same as the hash value of the same operating system component or application in the pre-secure storage area, then the integrity check is considered to have passed.

[0116] Step C3: If the hash value of the operating system component or application is different from the hash value of the same operating system component or application in the pre-secure storage area, then the integrity check has failed.

[0117] Pre-secure storage is a hardware-protected storage area within a chip used to store the base hash values ​​of operating system components and applications, preventing unauthorized modification or replacement.

[0118] The hashes of the same operating system components or applications stored in this area must have been generated by a trusted source at the time of software release. This value is typically calculated and written to secure storage by a trusted installer or security update process during software installation or system upgrades, rather than being dynamically generated at each startup. Therefore, this baseline hash value itself represents a digital fingerprint of the software in a "known good state."

[0119] Integrity checks can be performed at the granularity of the entire image, or at the level of a single module or file. A more secure approach is to use fine-grained checks, which involves storing a base hash value for each critical component or application separately and checking it individually. This way, even if only a small module is tampered with, it can be accurately identified and prevented, rather than performing a one-size-fits-all check on the entire large image.

[0120] This advantage lies in its efficiency and necessity. At the operating system and application layers, where the code is large and updates are relatively frequent, the use of lightweight SM3 hash verification can quickly detect any unauthorized modifications to the software content with almost no impact on startup performance. This constitutes the last static line of defense against runtime malicious code injection or data corruption on the storage medium, ensuring that the upper-layer software environment to be executed is completely consistent with expectations, and is an indispensable final link in building a complete chain of trust.

[0121] In scenarios where ordinary storage areas of PLC systems (such as inexpensive, large-capacity standard Flash) may face physical extraction or unauthorized copying, sensitive components are stored in encrypted form to protect the sensitive intellectual property and control logic in the operating system and applications. Specifically, a dedicated key derived from the device root key of the PUF is used to encrypt the data using the SM4 algorithm. The encrypted data is only decrypted into plaintext and hashed for verification by the integrated cryptographic authentication unit in real time before loading and execution, thereby achieving a balance between storage security and cost-effectiveness.

[0122] That is, the operating system components or application contain sensitive information, which is stored in encrypted form in the general storage area of ​​the PLC system. The encrypted information is obtained by encrypting a key derived from the device root key using the SM4 algorithm. Before step C1, the method may further include: Step C01: Read the ciphertext from the normal storage area.

[0123] The general storage area refers to the general-purpose storage medium (such as standard NOR / NANDFlash, eMMC) in the PLC system that is not strongly isolated by special hardware mechanisms (such as memory encryption, access control). It is characterized by low cost and large capacity, but is vulnerable to physical extraction attacks.

[0124] Although this area is referred to as "normal," its access should be managed by the boot control unit or security firmware in the system design. Prior to this stage of the boot process, read and write permissions for this area may be hardware-restricted. Encrypted data at a specified location should only be read when invoked by currently verified code (such as the bootloader or kernel) to prevent arbitrary access by runtime malware.

[0125] Step C02: Invoke the cryptographic authentication unit and use the SM4 algorithm based on the derived key to decrypt the ciphertext and obtain the plaintext data of the operating system component or application.

[0126] Derived keys refer to subkeys generated from the device's unique PUF root key through standard key derivation functions (such as KDF based on SM3). They are specifically used to encrypt and decrypt sensitive data stored in ordinary areas, thus achieving functional separation of key usage.

[0127] Plaintext data refers to the original binary code of operating system components or applications that can be directly recognized and executed by the CPU after being decrypted using the SM4 algorithm.

[0128] This achieves decoupling between security and storage cost. It allows software components containing core intellectual property and sensitive logic to be stored in large quantities of inexpensive general-purpose storage chips, without relying on expensive secure storage media, ensuring confidentiality solely through key isolation. This significantly reduces hardware costs, while leveraging the device-unique key derived from PUF ensures that even if the storage chip is physically disassembled, attackers cannot obtain meaningful code content, effectively preventing reverse engineering and code theft.

[0129] S344: Entering the running state, the PLC system executes the corresponding industrial control tasks.

[0130] This signifies that the PLC system has successfully completed the entire cryptographic verification and loading process from hardware power-on and key generation to all levels of software (bootloader, firmware, operating system, and applications), and has officially entered a secure execution environment with an established chain of trust, beginning to run the user-preset industrial control logic.

[0131] S35: Reset the PLC system.

[0132] This is a security fault tolerance mechanism triggered when any of the above verification steps fail. Its core is to immediately interrupt the current startup process and force the system to reset. It aims to prevent any unverified, unknown, or potentially tampered code from gaining execution privileges, thereby nipping potential security threats in the bud during the startup phase and ensuring that the system always starts from a known secure initial state.

[0133] In practice, the startup control unit can trigger the hardware watchdog timer to overflow or directly send a reset signal to the system reset pin, forcing the main controller chip and all related circuits to perform a complete hardware power-on reset process, clearing all volatile states, and enabling the system to return to the initial power-on point and restart the reliable startup.

[0134] In order to dynamically extend the static startup trust chain to the entire operational lifecycle of the system, continuous hash calculation and signing of key runtime states are performed to achieve real-time monitoring and proactive proof of whether malicious tampering, abnormal behavior or unauthorized code injection occurs during PLC operation.

[0135] S36: After entering the running state, the following steps are executed periodically or triggered: Periodic execution refers to the automatic repetition of an operation at preset, fixed time intervals (such as every 10 seconds, every minute, or every hour). Its core characteristic is that it has a temporal regularity and is often used for continuous monitoring and routine inspections.

[0136] Triggered execution refers to execution that occurs only when specific conditions or events are met, and its core characteristic is event-driven. Triggering conditions may include: the system detecting an abnormal event (such as the exit of a critical process or a memory access violation), receiving a specific instruction from an external source (such as a verification request initiated by a remote management platform), or reaching a non-periodic system state (such as completing a production batch or performing a specific critical operation).

[0137] S361: Collects runtime data from the PLC system.

[0138] Runtime data refers to critical status information generated by a PLC during operation. Runtime data must be meaningful and difficult-to-forge system health indicators, such as dynamic hashes of critical code segments (to prevent runtime code substitution), values ​​of security configuration registers, or summaries of critical task execution paths, rather than simple application variables. Its collection should be performed in a protected execution environment to prevent tampering by malicious software.

[0139] S362: Call the cryptographic authentication unit, use the SM3 algorithm to generate a hash value of the runtime data, and use the SM2 algorithm to generate a digital signature of the hash value based on the derived session key of the device root key.

[0140] A derived session key is the private key portion of an SM2 signature key pair that is dynamically generated by the device root key through a key derivation function (such as SM3 KDF) each time a remote authentication session is established. It is used to implement forward security and key isolation.

[0141] The SM2 private key used for signing should not be the device root key itself, nor should it be a long-term, fixed key. Instead, it should be a temporary private key derived from the root key and used only for this specific time or period. Its corresponding public key must be securely provided to the verifier (remote platform). This ensures that even if the signing key is compromised in a particular instance, it will not affect the security of the device root key or the trust of other sessions.

[0142] In scenarios where massive amounts of runtime data are continuously generated, i.e., the runtime data consists of multiple data generated consecutively, signing each data separately would result in huge signing overhead and wasted communication bandwidth. Therefore, one of the following two efficient batch data integrity digest generation strategies can be adopted.

[0143] Specifically, step S362 above may include: S362a: The SM3 algorithm is used to calculate the hash value of each runtime data separately. After concatenating all hash values, the SM3 algorithm is used again to calculate the final hash value.

[0144] For example, suppose the system periodically collects three runtime data points, D1, D2, and D3. First, calculate Hash1 = SM3(D1), Hash2 = SM3(D2), and Hash3 = SM3(D3) respectively. Then, concatenate these three hash values ​​in order into a long string: Concat = Hash1||Hash2||Hash3. Finally, calculate the final hash value: FinalHash = SM3(Concat).

[0145] This approach supports streaming or incremental processing, eliminating the need to store all the original data in memory simultaneously. The hash of each data point can be calculated independently and in parallel, making it suitable for scenarios with large amounts of data or data that do not arrive at the same time. It also allows for easy expansion of the verification of individual data points (for example, to verify D2, you only need to provide Hash1, Hash2, Hash3, and FinalHash, and you can verify it by reconstructing Concat and recalculating SM3(Concat)).

[0146] S362b: After aggregating all runtime data, the SM3 algorithm is used to calculate the hash value of the aggregated data to obtain the final hash value.

[0147] For example, suppose the system collects three runtime data points, D1, D2, and D3. First, the raw bytes of these three data points are directly concatenated into an aggregate data block, Aggregate = Length(D1)||D1||Length(D2)||D2||Length(D3)||D3, according to a predetermined format (such as adding a length prefix). Then, the final hash value, FinalHash = SM3(Aggregate), is calculated in one go.

[0148] This method is generally more computationally efficient because it only requires calling the SM3 hash function once, avoiding the overhead of multiple hash calculations and connecting intermediate results. It is particularly suitable for scenarios with small amounts of data that can be aggregated at once, and it is simple and direct to implement with the lowest computational overhead.

[0149] S363: Send the digital signature as an integrity report to a remote monitoring platform for verification, or perform local verification.

[0150] An integrity report is a structured data packet containing runtime data hashes and their corresponding SM2 digital signatures, used to prove to the verifier the authenticity and integrity of the system state at a specific moment.

[0151] Local verification is not simply self-verification, but rather refers to the verification of the signature of the current execution environment by another security monitoring module (such as a security coprocessor) within the main control chip with higher privileges. This forms a decentralized and balanced checking mechanism within the system.

[0152] S364: Determine whether to take safety protection measures for the PLC system based on the verification results.

[0153] Security measures are emergency response actions that the system can take after verification failure, such as triggering local alarms, switching the system to a secure state, blocking suspicious outputs, logging audit logs, or performing a controlled system reset.

[0154] This represents a leap from trusted startup to continuous trust. By extending the cryptographic proof mechanism from the static startup phase to the dynamic operational phase, the PLC system can proactively and periodically prove the integrity of its operational status to itself or a remote administrator. This not only enables timely detection and response to malicious tampering during runtime (such as memory attacks and firmware backdoor activation), but also provides the technical foundation for building an auditable and traceable security posture for industrial control systems, which is crucial for meeting high-level security compliance and proactive defense requirements.

[0155] This concludes the description of the secure startup method for a programmable logic controller provided in the embodiments of this application.

[0156] Based on the same inventive concept, this application also provides a safe startup device for a programmable logic controller.

[0157] The safety start device of the programmable logic controller is integrated into the main controller chip of the PLC system.

[0158] Figure 4 This is a schematic diagram of the structure of the safe start device of the programmable logic controller in an embodiment of this application. See also... Figure 4 As shown, the device may include: PUF module 41 is configured to be activated and generate a device root key in response to power-on of the PLC system.

[0159] Start state machine 42, implemented in the form of hardware logic or security firmware, which has a predefined sequence of security states containing multiple security states.

[0160] The startup control unit 43 is connected to the PUF module 41 and the startup state machine 42 respectively, and is configured to activate and run the startup state machine 42. The startup control unit 43 is also configured to perform corresponding operations under the control of the startup state machine 42 according to the current security state to advance the step-by-step verification and loading process.

[0161] The password authentication unit 44 is connected to the start control unit 43 and is configured to perform encryption, decryption, hash calculation and digital signature verification operations in response to the call of the start control unit 43.

[0162] Specifically, the start control unit 43 is configured as follows: When the startup state machine 42 enters the first safe state, it reads the code of the first-stage bootloader from the boot read-only memory of the PLC system and calls the password authentication unit 44 to verify the integrity and authenticity of the code and its digital signature; if the verification fails, the PLC system is reset; if the verification passes, the startup state machine 42 is controlled to enter the second safe state. When the startup state machine 42 enters the second security state, control is transferred to the verified first-stage bootloader, which reads the encrypted firmware data and calls the password authentication unit 44 to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature; if the verification fails, the PLC system is reset; if the verification passes, the startup state machine 42 is controlled to enter the third security state. When the startup state machine 42 enters the third security state, it loads the operating system components or application of the PLC system and calls the password authentication unit 44 to perform an integrity check based on the hash value. If the check fails, the PLC system is reset. If the check passes, the startup state machine 42 is controlled to enter the running state, allowing the PLC system to execute the corresponding industrial control tasks.

[0163] Furthermore, the device also includes: The KMU module connects to the PUF module. Specifically, the PUF module is configured to generate a raw, unique device response; The KMU module is configured to stabilize the original unique device response to generate the device root key; The PUF module is a lightweight PUF circuit based on a linear feedback shift register.

[0164] Furthermore, the start control unit is also configured to: Before activating and running the startup state machine, obtain the device root key; calculate the hash value of the device root key; compare the calculated hash value with the preset reference value burned into the PLC system's one-time programmable memory or electronic fuse at the factory. The preset reference value is the hash value corresponding to the device root key generated by the PUF module during operation; if they match, activate and run the startup state machine; if they do not match, trigger the PLC system reset.

[0165] Furthermore, the cryptographic authentication unit is implemented by a hardware cryptographic accelerator or security coprocessor integrated on the main controller chip; Specifically, when the control unit invokes the cryptographic authentication unit to verify the integrity and authenticity of the code and its digital signature, the process includes: The control cryptographic authentication unit uses the SM3 algorithm to calculate the hash value of the code; obtains the SM2 public key preset in the device security zone of the PLC system; the control cryptographic authentication unit uses the SM2 public key to decrypt the digital signature attached to the code; if the decrypted hash value is the same as the calculated hash value, the integrity and authenticity verification is confirmed to have passed; if the decrypted hash value is different from the calculated hash value, the integrity and authenticity verification is confirmed to have failed.

[0166] Furthermore, when the control unit invokes the password authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash values ​​and electronic signatures, the specific steps include: The control cryptographic authentication unit decrypts the encrypted firmware data using the SM4 algorithm based on the device root key or its derived key to obtain the plaintext firmware data; it then calculates the hash value of the plaintext firmware data using the SM3 algorithm; if the hash value of the plaintext firmware data is the same as the hash value of the same firmware data in the pre-secure storage area, the integrity check is considered passed; otherwise, the integrity check is considered failed; and finally, it decrypts the digital signature of the encrypted firmware data using the SM2 algorithm and its corresponding public key; if the decrypted hash value is the same as the hash value of the plaintext firmware data, the authenticity check is considered passed; otherwise, the authenticity check is considered failed.

[0167] Furthermore, when the control unit invokes the password authentication unit to perform integrity checks on operating system components or applications based on hash values, the specific steps include: The control cryptographic authentication unit uses the SM3 algorithm to calculate the hash value of the operating system component or application; if the hash value of the operating system component or application is the same as the hash value of the same operating system component or application in the pre-secure storage area, the integrity check is determined to be passed; if they are different, the integrity check is determined to be failed.

[0168] Furthermore, the operating system components or applications contain sensitive information and store it in the general storage area of ​​the PLC system in ciphertext form. The ciphertext is obtained by encrypting the key derived from the device root key using the SM4 algorithm. The start control unit is also configured as follows: Before invoking the cryptographic authentication unit to perform integrity verification on the operating system components or applications based on the hash value, the ciphertext is read from the ordinary storage area; and the cryptographic authentication unit is invoked to decrypt the ciphertext using the SM4 algorithm based on the derived key to obtain the plaintext data of the operating system components or applications.

[0169] Furthermore, the startup control unit is also configured to perform trusted execution operations after the startup state machine enters the running state: The following steps are executed periodically or triggered: collect runtime data of the PLC system; call the cryptographic authentication unit, use the SM3 algorithm to generate a hash value of the runtime data, and use the SM2 algorithm to generate a digital signature of the hash value based on the derived session key of the device root key; send the digital signature as an integrity report to the remote monitoring platform for verification, or perform local verification; and decide whether to take security protection measures for the PLC system based on the verification results.

[0170] Furthermore, the runtime data consists of multiple data sets generated consecutively; When the startup control unit calls the password authentication unit to generate the hash value of runtime data using the SM3 algorithm, it is specifically configured as follows: The control cryptographic authentication unit uses the SM3 algorithm to calculate the hash value of each piece of runtime data, concatenates all hash values, and then uses the SM3 algorithm again to calculate the final hash value; or... After the control cryptographic authentication unit aggregates all runtime data, it uses the SM3 algorithm to calculate the hash value of the aggregated data to obtain the final hash value.

[0171] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0172] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of safe start-up of a programmable logic controller, characterized in that, The method is applied to a programmable logic controller (PLC) system, a physical unclonable function (PUF) circuit, a startup control unit and a password authentication unit are integrated on a main controller chip of the PLC system, and the method comprises the following steps: In response to power-on of the PLC system, the PUF circuit is activated and generates a device root key; The startup control unit activates and runs a startup state machine, the startup state machine is implemented in the form of hardware logic or secure firmware, wherein a security state sequence comprising a plurality of security states is predefined; The startup control unit performs the following step-by-step verification and loading process under the control of the startup state machine: Enter the first security state, read the code of the first-stage boot loader from the boot read-only memory of the PLC system, and call the password authentication unit to perform integrity and authenticity verification on the code and its digital signature by using a national secret algorithm and a preset public key; if the verification fails, the PLC system is reset; if the verification passes, the next step is performed; Enter the second security state, transfer control to the verified first-stage boot loader, read encrypted firmware data therefrom, and call the password authentication unit to perform decryption and integrity and authenticity verification based on a hash value and an electronic signature on the encrypted firmware data by using the device root key; if the verification fails, the PLC system is reset; if the verification passes, the next step is performed; Enter the third security state, load the operating system components or application programs of the PLC system, and call the password authentication unit to perform integrity verification on the operating system components or application programs based on a hash value; if the verification fails, the PLC system is reset; if the verification passes, the next step is performed; Enter the running state, and the PLC system performs corresponding industrial control tasks.

2. The method of claim 1, wherein, The main controller chip further integrates a key management unit (KMU) circuit, the KMU circuit is connected with the PUF circuit, and the PUF circuit is a lightweight PUF circuit based on a linear feedback shift register; the PUF circuit is activated and generates a device root key, which comprises the following steps: The PUF circuit generates an original unique device response, and the KMU circuit performs stabilization processing on the original unique device response to obtain the device root key.

3. The method of claim 1, wherein, Before the startup control unit activates and runs the startup state machine, the method further comprises the following steps: The startup control unit obtains the device root key; Calculate the hash value of the device root key; Compare the calculated hash value with a preset reference value burned in the one-time programmable memory or electronic fuse of the PLC system at the time of factory shipment, the preset reference value is the hash value corresponding to the device root key generated when the PUF circuit is running; If they are consistent, the step of activating and running the startup state machine is performed; If they are inconsistent, the PLC system is reset.

4. The method of claim 1, wherein, The password authentication unit is implemented by a hardware password accelerator or a secure coprocessor integrated on the main controller chip; the password authentication unit is called to perform integrity and authenticity verification on the code and its digital signature by using a national secret algorithm and a preset public key, which comprises the following steps: The password authentication unit is invoked to perform the following operations: The hash value of the code is calculated using the SM3 algorithm; Obtain the SM2 public key preset in the device security zone of the PLC system; The digital signature attached to the code is decrypted using the SM2 public key; If the decrypted hash value is the same as the calculated hash value, then the integrity and authenticity verification is passed. If the decrypted hash value is different from the calculated hash value, then the integrity and authenticity checks have failed.

5. The method of claim 1, wherein, The process of calling the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature includes: The password authentication unit is invoked to perform the following operations: Based on the device root key or its derived key, the encrypted firmware data is decrypted using the SM4 algorithm to obtain the firmware plaintext data. The hash value of the firmware plaintext data is calculated using the SM3 algorithm; If the hash value of the firmware plaintext data is the same as the hash value of the same firmware data in the pre-secure storage area, then the integrity check is deemed to have passed. If the hash value of the firmware plaintext data is different from the hash value of the same firmware data in the pre-secure storage area, then the integrity check is determined to have failed. The digital signature of the encrypted firmware data is decrypted using the SM2 algorithm and its corresponding public key. If the decrypted hash value is the same as the hash value of the firmware plaintext data, then the authenticity verification is confirmed to be successful. If the decrypted hash value is different from the hash value of the firmware plaintext data, then the authenticity verification is determined to have failed.

6. The method of claim 1, wherein, The step of invoking the password authentication unit to perform integrity verification on the operating system components or applications based on hash values ​​includes: The password authentication unit is invoked to perform the following operations: The hash value of the operating system component or application is calculated using the SM3 algorithm; If the hash value of the operating system component or application is the same as the hash value of the same operating system component or application in the pre-secure storage area, then the integrity check is deemed to have passed. If the hash value of the operating system component or application is different from the hash value of the same operating system component or application in the pre-secure storage area, the integrity check is determined to have failed.

7. The method of claim 6, wherein, The operating system components or applications contain sensitive information and are stored in the general storage area of ​​the PLC system in ciphertext form. The ciphertext is obtained by encrypting a key derived from the device root key using the SM4 algorithm. Before calculating the hash value of the operating system component or application using the SM3 algorithm, the method further includes: Read the ciphertext from the ordinary storage area; The cryptographic authentication unit is invoked to decrypt the ciphertext using the SM4 algorithm based on the derived key, thereby obtaining the plaintext data of the operating system component or application.

8. The method according to any one of claims 1 to 7, characterized in that, The method also includes a trusted execution phase: After entering the operating state, the following steps are executed periodically or triggered: Collect runtime data from the PLC system; The cryptographic authentication unit is invoked to generate a hash value of the runtime data using the SM3 algorithm, and a digital signature of the hash value is generated using the SM2 algorithm based on the derived session key of the device root key. The digital signature is sent as an integrity report to a remote monitoring platform for verification, or it is verified locally. The decision on whether to take safety protection measures for the PLC system will be based on the verification results.

9. The method of claim 8, wherein, The runtime data consists of multiple data sets generated consecutively. The process of generating the hash value of the runtime data using the SM3 algorithm includes: The SM3 algorithm is used to calculate the hash value of each runtime data separately. After concatenating all hash values, the SM3 algorithm is used again to calculate the final hash value. or, After aggregating all runtime data, the SM3 algorithm is used to calculate the hash value of the aggregated data to obtain the final hash value.

10. A safety start-up apparatus of a programmable logic controller, characterized by comprising: The device is integrated on the main controller chip of the programmable logic controller (PLC) system, and the device includes: The Physically Unclonable Function (PUF) module is configured to be activated and generate a device root key in response to power-on of the PLC system. Start the state machine, implemented in hardware logic or secure firmware, which has a predefined sequence of secure states containing multiple secure states; The startup control unit is connected to both the PUF module and the startup state machine, and is configured to activate and run the startup state machine. The startup control unit is also configured to perform corresponding operations under the control of the startup state machine, based on the current security status, to advance the step-by-step verification and loading process. The password authentication unit, connected to the startup control unit, is configured to perform encryption, decryption, hash calculation, and digital signature verification operations in response to a call from the startup control unit. Specifically, the start-up control unit is configured as follows: When the startup state machine enters the first security state, it reads the code of the first-stage bootloader from the boot read-only memory of the PLC system and calls the password authentication unit to verify the integrity and authenticity of the code and its digital signature; if the verification fails, the PLC system is triggered to reset; if the verification passes, the startup state machine is controlled to enter the second security state. When the startup state machine enters the second security state, control is transferred to the verified first-stage bootloader, which reads the encrypted firmware data and calls the cryptographic authentication unit to decrypt the encrypted firmware data using the device root key and perform integrity and authenticity verification based on hash value and electronic signature; if the verification fails, the PLC system is reset; if the verification passes, the startup state machine is controlled to enter the third security state. When the startup state machine enters the third security state, it loads the operating system components or application of the PLC system and calls the password authentication unit to perform an integrity check on it based on the hash value. If the check fails, the PLC system is reset. If the check passes, the startup state machine is controlled to enter the running state, allowing the PLC system to execute the corresponding industrial control tasks.

Images