PLC instruction level dual-factor authentication system and method based on hardware root of trust

Abstract

This application provides a PLC instruction-level two-factor authentication system and method based on a hardware root of trust. It includes: a session authentication module for performing session-level two-factor authentication based on device authentication information corresponding to the user password factor and the client device's device identity key; a key derivation module for deriving a token key and an instruction key based on the session master key; an instruction encryption module for performing authentication encryption processing on control instructions using the instruction key, and generating instruction ciphertext and an authentication tag; and an instruction execution module for decrypting the token ciphertext using the token key and verifying the device identifier, validity period information, and instruction permission information of the decrypted security token. If the verification passes, the instruction ciphertext is decrypted to obtain the control instruction and executed. This application can improve the strength of instruction-level authentication and authorization verification, enhance cross-layer identity consistency assurance capabilities, and reduce the processing overhead of instruction security verification.

Description

Technical Field

[0001] This application relates to the field of industrial automation control technology, and in particular to a PLC instruction-level two-factor authentication system and method based on hardware root of trust. Background Technology

[0002] In high-security industrial control scenarios such as finance, military, and nuclear power, PLC controllers issue control commands through operator stations or engineer stations to complete equipment linkage and critical control operations. Attacks in these scenarios are highly adversarial and chain-like, potentially involving copying operator station password hash databases and brute-forcing offline, copying firmware and certificates for third-party spoofing, analyzing and replaying transmitted commands, sniffing access via mobile or wireless devices, or internal personnel implanting malicious programs to steal sensitive information and perform unauthorized operations, making subsequent tracing and liability determination difficult.

[0003] Existing PLC security solutions primarily focus on communication link encryption, device access authentication, or multi-factor login for operator stations. For example, they employ transport layer encryption protocols to establish encrypted channels and verify the identity of peer devices through certificate mechanisms, or implement password and secondary authentication login control on the host computer side. However, these solutions typically remain at the session-level or access-level authentication level, lacking a mechanism to fine-grainedly bind each control command to the identity of the command source device and the operator. This makes them vulnerable to advanced attacks such as session hijacking, command replay, and offline database breach analysis. Furthermore, single-layer device authentication is insufficient to form a defense-in-depth defense, and command-level authorization and strong auditing capabilities are inadequate, failing to meet the requirements of high-security scenarios for command-level authentication, encryption, and strong traceability. Summary of the Invention

[0004] In view of this, embodiments of this application provide a PLC instruction-level two-factor authentication system and method based on hardware root of trust to solve the problems of lack of instruction-level human-machine two-factor strong authentication, inconsistent identities of cross-layer devices, and insufficient instruction-level permissions and timeliness verification in the prior art.

[0005] The first aspect of this application provides a PLC instruction-level two-factor authentication system based on a hardware root of trust, comprising: a hardware root of trust module, used to generate and protect device identity keys and authentication keys within the hardware security units of the controller device and the client device, and output device authentication information associated with the device identity keys; a device certificate management module, used to acquire and manage device certificates of the controller device and the client device based on the device authentication information; a secure communication module, used to establish an encrypted communication channel between the controller device and the client device based on the device certificates, and complete bidirectional device authentication during the establishment process; and a session authentication module, used to perform session-level two-factor authentication within the encrypted communication channel based on the device authentication information corresponding to the user password factor and the device identity key of the client device, and to perform authentication upon successful authentication. The process involves: a session master key obtained through negotiation; a key derivation module for deriving token and command keys based on the session master key; a security token generation module for constructing a security token based on user identifier, device identifier, command permission information, and validity period information, and encrypting the security token using the token key to obtain token ciphertext; a command encryption module for performing authentication encryption processing on control commands using the command key, and binding the token ciphertext as associated data with the authentication encryption result of the control commands to generate command ciphertext and authentication tag; and a command execution module for verifying the authentication tag based on the command key, decrypting the token ciphertext using the token key, and verifying the device identifier, validity period information, and command permission information of the decrypted security token. If the verification passes, the command ciphertext is decrypted to obtain the control command and executed.

[0006] A second aspect of this application provides a PLC instruction-level two-factor authentication method based on a hardware root of trust, comprising: generating and protecting a device identity key and a verification key within the hardware security unit of a controller device and a client device; outputting device verification information associated with the device identity key; and acquiring and managing device certificates for the controller device and the client device based on the device verification information; establishing an encrypted communication channel between the controller device and the client device based on the device certificates, and completing bidirectional device authentication during the establishment process; and performing session-level two-factor authentication within the encrypted communication channel based on the user password factor and the device verification information corresponding to the device identity key of the client device. The process involves: negotiating an expired session master key; deriving a token key and a command key from the session master key; constructing a security token based on the user identifier, device identifier, command permission information, and validity period information, and encrypting the security token using the token key to obtain token ciphertext; performing authentication encryption processing on the control command using the command key, and binding the token ciphertext as associated data with the authentication encryption result of the control command to generate command ciphertext and authentication tag; verifying the authentication tag based on the command key, and decrypting the token ciphertext using the token key; verifying the device identifier, validity period information, and command permission information of the decrypted security token; and decrypting the command ciphertext to obtain and execute the control command if the verification passes.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The hardware trust root module generates and protects device identity keys and authentication keys within the hardware security units of the controller and client devices, and outputs device authentication information associated with the device identity keys. The device certificate management module acquires and manages device certificates for the controller and client devices based on the device authentication information. The secure communication module establishes an encrypted communication channel between the controller and client devices based on the device certificates and completes bidirectional device authentication during the establishment process. The session authentication module performs session-level two-factor authentication within the encrypted communication channel based on the user password factor and the device authentication information corresponding to the client device's device identity key, negotiating a session master key after successful authentication. The key derivation module... This application utilizes a method to derive token and command keys based on a session master key. A security token generation module constructs a security token based on user identifier, device identifier, command permission information, and validity period information, and encrypts the security token using the token key to obtain token ciphertext. A command encryption module performs authentication encryption processing on control commands using the command key, and binds the token ciphertext as associated data with the authentication encryption result of the control command to generate command ciphertext and an authentication tag. A command execution module verifies the authentication tag based on the command key, decrypts the token ciphertext using the token key, and verifies the device identifier, validity period information, and command permission information of the decrypted security token. If the verification passes, the command ciphertext is decrypted to obtain the control command and executed. This application enhances the strength of command-level authentication and authorization verification, strengthens cross-layer identity consistency assurance capabilities, and reduces the processing overhead of command security verification. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram of the architecture of a PLC instruction-level two-factor authentication system based on a hardware root of trust provided in this application embodiment; Figure 2 This is a schematic diagram of the structural composition of the PLC instruction-level two-factor authentication system based on hardware root of trust provided in this application embodiment; Figure 3 This is a schematic diagram illustrating the implementation process of the controller instruction-level authentication process provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the PLC instruction-level two-factor authentication method based on hardware root of trust provided in this application embodiment. Detailed Implementation

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

[0011] In PLC control applications with high security requirements, such as those in finance, military, and nuclear power, certain malicious attacks exceed the scope of general attacks. These attacks include copying the operator station's password hash database, using large computers for brute-force attacks, performing instruction feature analysis on transmitted commands without decryption, copying key files such as operator station firmware and certificates for third-party spoofing, using printers or mobile devices such as wireless devices for sniffing access, and internal personnel implanting viruses to detect confidential information or unauthorized operations. Traditional PLC controllers lack fine-grained device and personnel identity control at the instruction level, making it difficult to prevent high-level replay attacks, offline attacks, and extremely difficult to trace the source after an attack.

[0012] Critical control operations in high-security scenarios require controllers to possess instruction-level authentication, encryption, and strong traceability. PLC control devices with certain security capabilities, such as TLS encrypted transmission and multi-factor login control for operator stations, provide good protection against malicious attacks. However, single-layer device authentication cannot prevent session hijacking, lacks a defense-in-depth system, and has weak or absent instruction authentication and access control, making it difficult to achieve instruction-level security. It cannot perform fine-grained strong authentication of the source device and personnel, cannot prevent offline analysis of operator stations, and cannot address the problem of collusion attacks involving internal personnel maliciously stealing sensitive information such as passwords and device tags. This application proposes a high-security instruction-level two-factor authentication method based on a hardware root of trust, strengthening the above-mentioned security risk prevention capabilities and resolving the contradiction between high security and real-time performance at the control instruction level.

[0013] Existing technologies have not yet discovered multi-factor direct authentication at the instruction level for PLC controllers. Most authentication methods focus on the access identity of controller devices, indirectly performing single authentication on PLC sessions and application instructions. The authentication strength is insufficient to resist high-level attacks of military or financial grade.

[0014] In view of the problems existing in the prior art, this application proposes a PLC controller instruction-level two-factor authentication system and method based on a hardware root of trust. This application adopts a four-level defense architecture. The underlying hardware uses a hardware trusted encryption module (TPM) on the controller and engineering station. The communication security layer uses the Transport Layer Security (TLS) 1.3 protocol. The application layer uses an improved OPAQUE protocol (an advanced authentication key exchange protocol that combines Oblivious Pseudorandom Function (OPRF) and Password-Authenticated Key Exchange (PAKE) for authentication) for shared key authentication and authorization. The instruction security layer uses the AEAD (Authenticated Encryption with Associated Data) method with associated data encryption, based on two-factor synchronous authentication of device and user information. This application uses a high-entropy symmetric key negotiated three times via the OPAQUE protocol to encrypt a command token containing device, user, permission, and retention time information for TPM signature authentication. The encrypted token information is then used as additional information for AEAD authentication. A lightweight authentication encryption method is adopted to encrypt commands, reducing the decryption overhead of control commands while supporting high-strength two-factor authentication for each control command for both the device and the user. This strictly protects the legitimacy of the person and device from which the command originates, ensuring the integrity, privacy, and non-repudiation of the commands.

[0015] The following description, with reference to the accompanying drawings, illustrates the system architecture of the hardware root-of-trust-based PLC instruction-level two-factor authentication system in a real-world scenario. Figure 1 This is a schematic diagram of the architecture of a PLC instruction-level two-factor authentication system based on a hardware root of trust, provided in an embodiment of this application. For example... Figure 1 As shown, the hardware security layer utilizes the TPM (Telematics Management Unit) of the operator station / engineer station as an immutable cryptographic foundation to generate and store the root key, providing true random numbers and accelerating cryptographic operations. The communication security layer adopts the latest TLS 1.3 protocol to establish an encrypted communication channel between devices and verifies device identity based on a certificate mechanism. The application security layer includes an OPAQUE protocol authentication module, a device consistency check module, and a session key negotiation module to achieve strong binding between user identity and device, and negotiates the communication key between the host computer and the controller based on a zero-trust approach. The command security layer includes a security token generator, an AEAD command encryptor, and a key derivation module to generate command tokens containing security context, encrypt commands, verify command validity, and execute secure commands.

[0016] Through this layered security design, the encryption token strongly binds each controller instruction to an authenticated context (user, client device, permission, validity period). The function of each layer is as follows: 1. Hardware Security Root Implemented based on a hardware TPM, it provides hardware-level key protection, ensuring that all private keys never leave the TPM. Its key includes an endorsement key (EK): factory-programmed, a unique identifier for the TPM, used to create the AIK; Authentication Identity Key (AIK): A privacy-protected identity verification key, derived from EK, used to remotely verify the identity of a device; Storage Root Key (SRK): The key that protects all user keys.

[0017] Device Identity Key (SK): The device signing key used by the application layer.

[0018] 2. Communication Security Layer (TLS 1.3): Establish an end-to-end encrypted channel and complete device authentication on the server side (PLC). The device certificate used for communication signature is issued by a unified enterprise CA and adopts a dual-signature mechanism.

[0019] In Phase 1 of the communication security layer, the server (PLC) AIK certificate is generated by the PLC's built-in TPM requesting it from the unified enterprise CA. In Phase 2, the server (PLC) device certificate is generated by adding AIK signature information and the AIK public key certificate to the appendix section of the PLC device certificate CSR request file. This converts the dual certificate chain into a single certificate format, which is then used to request a certificate from the unified enterprise CA and obtain a third-party CA certificate. Phases 3 and 4 follow the same process, requesting the client (operator station)'s built-in TPM's AIK certificate and device certificate from the unified enterprise CA. Phase 5 performs a TLS 1.3 handshake and mutual authentication. During mutual authentication of the device certificates, in addition to verifying the CA-issued chain, the AIK certificate chains of each device certificate also need to be further verified.

[0020] 3. Application security layer Within the encrypted TLS channel, the application layer employs two-factor authentication for both personnel and devices, verifying the consistency between the client device's identity and the identity information carried in the communication certificate. Upon successful authentication, an application layer session master key is generated based on the QPAQUE key negotiation protocol. In this security layer, the server (PLC device) only stores encrypted packets, placing them within an internal TPM protection layer; the client (operator station) does not store sensitive information. Even if the TPM's envU is leaked, the server (PLC) cannot reverse-engineer the password, and even if the client (operator) station is copied, no sensitive information will be leaked. The interaction between the server and client possesses zero-knowledge proof properties, effectively resisting man-in-the-middle attacks.

[0021] 4. Command Security Layer It includes a security token generator. The client and server derive a key based on the negotiated application-layer session key. The client encrypts the security token and binds it to the command. The command is encrypted using the AEAD encryption algorithm. The server decrypts the command and token and verifies the time, device ID, and authorization information based on the token. If successful, the command is executed normally; otherwise, it is not executed and an alarm is generated.

[0022] The specific structure and function of the PLC instruction-level two-factor authentication system based on hardware root of trust provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 2 This is a schematic diagram of the structural composition of the PLC instruction-level two-factor authentication system based on a hardware root of trust provided in this application embodiment, as shown below. Figure 2 As shown, the system may specifically include the following modules: The hardware trust root module 201 is used to generate and protect the device identity key and the authentication key within the hardware security unit of the controller device and the client device, and output device authentication information associated with the device identity key; Device certificate management module 202 is used to obtain and manage device certificates for controller devices and client devices based on device certification information; The secure communication module 203 is used to establish an encrypted communication channel between the controller device and the client device based on the device certificate, and to complete two-way device authentication during the establishment process; Session authentication module 204 is used to perform session-level two-factor authentication based on the device authentication information corresponding to the user password factor and the device identity key of the client device within the encrypted communication channel. After successful authentication, the session master key is negotiated and obtained. Key derivation module 205 is used to derive token key and instruction key based on session master key; The security token generation module 206 is used to construct a security token based on the user identifier, device identifier, instruction permission information and validity period information, and to encrypt the security token using the token key to obtain the token ciphertext. The instruction encryption module 207 is used to perform authentication encryption processing on the control instruction using the instruction key, and bind the token ciphertext as associated data with the authentication encryption result of the control instruction to generate instruction ciphertext and authentication tag; The instruction execution module 208 is used to verify the authentication tag based on the instruction key, and to decrypt the token ciphertext using the token key and verify the device identifier, validity period information and instruction permission information of the decrypted security token. When the verification is successful, the instruction ciphertext is decrypted to obtain the control instruction and executed.

[0023] In some embodiments, the hardware trust root module is used for: A storage root key for protecting key objects is generated and stored within the hardware security unit, and the private key of the device identity key is encapsulated and protected based on the storage root key, so that the private key of the device identity key remains within the hardware security unit and is not exported. A proof key for device authentication is generated within the hardware security unit, and the proof data associated with the public key of the device identity key is signed based on the proof key to obtain device authentication information; The device certificate management module outputs the public key of the device identity key and the device certification information, enabling the device certificate management module to prove the association between the device identity key and the hardware security unit based on the device certification information and obtain the corresponding device certificate.

[0024] Specifically, the storage root key is used to encapsulate and protect the key object, the proof key is used to sign the proof data to generate device proof information, and the device identity key is used to characterize the device identity and provide device-side signing capabilities in subsequent authentication processes. To ensure that the device identity key cannot be copied or misused offline, its private key is encapsulated as a key object protected by the storage root key after generation, and an access control policy is set so that the private key can only be called to perform signature operations within the hardware security unit and cannot be exported; the proof key is also protected by the storage root key as a key object and is used to sign the device proof data to form a verifiable proof chain.

[0025] On the controller device side, during the initialization phase, the hardware security unit generates and saves a root key, and generates a device identity key pair for the controller device within the protection domain of the root key. After generation, the hardware security unit encapsulates the private key of the device identity key into a key object and writes it to a protected key storage area, while configuring the access policy of the key object to "non-exportable, allowing only internal signature calls within the hardware security unit." Subsequently, the hardware security unit generates a proof key for device authentication and constructs proof data associated with the public key of the device identity key. The proof data may include at least one or a combination of: the public key of the device identity key, a device hardware identifier digest, the identity identifier of the hardware security unit, a random challenge value associated with the current authentication session, and a session identifier used to identify the authentication context. The hardware security unit performs a signature operation on the proof data to obtain a signature result, and outputs the signature result and the proof data together as device authentication information, whereby the device authentication information proves that "the device identity public key was generated and protected by a specific hardware security unit in a protected environment."

[0026] On the client device side, the hardware security unit generates and stores the root key in the same manner, and generates a device identity key pair for the client device within the protection domain of the root key. The private key of the device identity key is encapsulated and protected as a key object with a non-exportable policy configured. Subsequently, the client-side hardware security unit generates a proof key and signs the proof data associated with the client device identity public key based on the proof key pair, obtaining the client-side device proof information. Consistent with the controller device side, the proof data at least includes the public key of the client device identity key, and may further include a device hardware identifier digest and a random challenge value, so that subsequent verifiers can confirm the freshness and non-replayability of the device proof information.

[0027] Furthermore, the device certificate management module receives the device identity key public key and corresponding device certification information output by the controller device and client device, respectively, and constructs certificate application data based on the device certification information. Specifically, the device certificate management module writes the device identity key public key into the public key field of the certificate application request and submits the device certification information as supplementary supporting material to the enterprise certificate authority. The enterprise certificate authority verifies the association between the device identity key public key and the hardware security unit based on the device certification information, and issues the corresponding device certificate upon successful verification. After obtaining the device certificate, the device certificate management module establishes a binding relationship between the device certificate and the device identity key public key and stores it. This enables the secure communication module to perform two-way device authentication based on the device certificate when establishing an encrypted communication channel, and also enables the session authentication module to perform device factor authentication operations such as challenge signature based on the device identity key within the hardware security unit.

[0028] Through the above implementation method, a chain association can be formed on the device side, consisting of "device identity private key protected by storage root key encapsulation + device proof information signed by proof key + device certificate issued based on proof information". This keeps the private key of the device identity key inside the hardware security unit and cannot be exported, and provides a verifiable device identity foundation for subsequent cross-layer device identity verification and instruction-level two-factor authentication.

[0029] In some embodiments, the secure communication module is used for: The device certificate management module submits certificate application data containing device certification information to the enterprise certificate authority to obtain the controller device certificate corresponding to the controller device and the client device certificate corresponding to the client device; During the handshake process of establishing an encrypted communication channel, the controller device and the client device send their respective device certificates to each other and perform certificate chain verification on each other's device certificates based on the trust chain of the enterprise certificate authority. When the certificate chain verification is successful, the consistency between the device certificate and the hardware security unit is verified based on the proof key chain corresponding to the device proof information carried in the device certificate to complete the two-way device authentication, and an encrypted communication channel is established after the two-way device authentication is successful.

[0030] Specifically, the controller device is a PLC controller, and the client device is an operator station or engineer station. Both have built-in hardware security units that output device authentication information. The device certificate management module establishes a controlled certificate application and issuance process with the enterprise certificate authority, ensuring that the issued device certificate is associated not only with the device identity key public key but also with the device authentication information generated by the hardware security unit. This provides a dual verification basis of "certificate trust chain + hardware authentication chain" for subsequent handshake authentication.

[0031] During the certificate acquisition phase, the device certificate management modules on both the controller and client sides receive the device identity key public key and device authentication information output from their respective hardware security units, and construct certificate application data. The certificate application data includes at least the device identity key public key, device identification information, and device authentication information. The device authentication information includes the signature result obtained by signing the authentication data associated with the device identity key public key using an authentication key, and the corresponding authentication data. The device certificate management module submits the certificate application data to the enterprise certificate authority, which verifies the device authentication information based on a pre-defined trust policy. After confirming that the device identity key public key was indeed generated and protected by a trusted hardware security unit, the enterprise certificate authority issues a controller device certificate corresponding to the controller device and a client device certificate corresponding to the client device. After acquiring the device certificate, the device certificate management module binds the device certificate to its local device identity key public key and stores it for use by the secure communication module.

[0032] During the encrypted communication channel establishment phase, the secure communication module initiates a handshake process for the encrypted communication channel. At the start of the handshake, the controller device and the client device exchange their respective device certificates and their certificate chain information. Subsequently, both parties perform certificate chain verification on each other's device certificates based on their respective enterprise certificate authority trust chains. Certificate chain verification includes at least verification of the trustworthiness of the certificate issuing authority, verification of the integrity of the certificate chain, and verification of the certificate's validity period and revocation status. If the certificate chain verification fails, the peer device's identity is deemed untrustworthy, and the handshake process is terminated.

[0033] Upon successful certificate chain verification, to prevent attackers from merely copying the certificate file without possessing the corresponding hardware security unit's proof capabilities, this embodiment further performs consistency verification based on the hardware proof chain. Specifically, the secure communication module parses the proof materials associated with the device's proof information from the peer device's certificate and obtains the proof key chain information corresponding to the proof materials. Both the controller device and the client device initiate hardware proof challenges to the peer device. These challenges include a random challenge value and a session identifier associated with the current handshake session. Upon receiving the hardware proof challenge, the peer device invokes its local hardware security unit to sign the data corresponding to the random challenge value and the session identifier using the proof key, generating a proof response and returning it. The verifier verifies the proof response based on the proof key chain carried in or parsable from the device certificate, and further compares the device identity key public key associated with the proof response with the device identity information in the device certificate to confirm that the device certificate is indeed held by a device with the corresponding hardware security unit and that no cross-device copying has occurred.

[0034] When both the certificate chain verification and the hardware proof chain consistency verification pass, the controller device and the client device determine that the two-way device authentication is successful, and continue to complete the key negotiation and session parameter confirmation for the encrypted communication channel, ultimately establishing an end-to-end encrypted communication channel. This established encrypted communication channel is used to carry subsequent session-level two-factor authentication interactions and key derivation parameter negotiation interactions for the session authentication module. This ensures that personnel password factor and device factor authentication are completed in a protected communication environment, preventing authentication materials from being stolen or tampered with during the process.

[0035] Through the above implementation methods, this embodiment realizes bidirectional device authentication between the controller device and the client device during the establishment of the encrypted communication channel, and introduces hardware proof chain consistency verification on the basis of certificate chain verification, so that the device certificate and hardware security unit capabilities are strongly bound together, providing a reliable communication and device identity foundation for subsequent instruction-level two-factor authentication.

[0036] In some embodiments, the session authentication module is used for: Based on the user identifier, the password authentication data and device binding data associated with the user identifier are determined from the pre-stored binding records, and a challenge random number for anti-replay is sent to the client device; The client device performs password authentication key exchange calculation based on the user password factor and password authentication data, generates session authentication data to prove password knowledge, and calls the hardware security unit to sign the challenge random number using the private key of the device identity key to generate device authentication data. Session authentication data and device authentication data are sent to the controller device. The controller device verifies the device authentication data based on the device binding data in the binding record and verifies the session authentication data based on the password authentication data in the binding record to complete session-level two-factor authentication. When session-level two-factor authentication is successful, the session master key is obtained by negotiating the shared result calculated by the controller device and the client device based on the password authentication key exchange and in combination with the session context parameters.

[0037] Specifically, after completing the registration phase, the controller device maintains a binding record in its local secure storage area. The binding record includes at least the password authentication data corresponding to the user identifier and the device binding data of the client device bound to the user identifier. The password authentication data is used for server-side verification to support password authentication key exchange, and the device binding data is used to restrict the user identifier to be authenticated only with the bound client device. The device binding data includes at least the public key of the client device's identity key or its digest identifier, and may further include a device authentication information identifier and an instruction permission set identifier.

[0038] During the login initialization phase, the user on the client device enters their user identifier and password on the client interface. The client device sends the user identifier to the controller device, requesting session-level authentication. Upon receiving the user identifier, the controller device determines the password authentication data and device binding data associated with the user identifier from pre-stored binding records and generates a challenge random number as a replay protection element. The challenge random number can be associated with the session identifier of the current authentication session to ensure that the challenge random number is not reused across different sessions. The controller device then sends the challenge random number, along with the necessary parameters for password authentication key exchange calculations, to the client device.

[0039] During the client-side computation phase, the client device performs a password authentication key exchange calculation based on the user password factor and the password authentication data obtained from the controller device, generating session authentication data to prove password knowledge. The session authentication data includes at least an authentication message for server-side verification of password knowledge and temporary negotiation elements for generating a shared result, enabling the controller device to verify password knowledge without storing the plaintext password. Simultaneously, the client device calls its local hardware security unit to sign the challenge random number using the private key of the device identity key, generating device authentication data. Since the private key of the device identity key is kept within the hardware security unit and cannot be exported, the device authentication data can serve as device factor proof for the client device, demonstrating that "the authentication request was initiated by a device holding the bound device identity key." To enhance replay resistance, in this embodiment, the device authentication data may further include a signed input of the session identifier or session context digest, binding the signature result to the current authentication session.

[0040] During the authentication data submission phase, the client device encapsulates the session authentication data and device authentication data into a login data packet and sends it to the controller device. Upon receiving the login data packet, the controller device first verifies the device authentication data based on the device binding data in the binding record. Specifically, the controller device reads the client device's identity key public key or its digest identifier stored in the binding record and uses this public key to verify the signature in the device authentication data. Simultaneously, it verifies that the challenge random number covered by the signature matches the challenge random number issued this time, confirming that the device authentication data was generated by the bound device and has not been replayed. Subsequently, the controller device verifies the session authentication data based on the password authentication data in the binding record. If the verification passes, the user's password factor is confirmed to be valid. Through the separate verification of device authentication data and session authentication data, the controller device completes session-level two-factor authentication. Authentication is considered successful only when both the user's password factor and device factor verification pass.

[0041] During the session master key negotiation phase, when session-level two-factor authentication is successful, the controller device and client device negotiate the session master key based on the shared result calculated from the password authentication key exchange. Specifically, both parties use the shared result calculated from the password authentication key exchange as the core input to the session master key, and incorporate the session identifier, challenge random number, and random number materials or handshake context digests exchanged during authentication as session context parameters in the combined calculation, thus strongly binding the session master key to the current authentication session. After establishing the session master key in this session, the controller device and client device associate the session master key with the session identifier and save it as session state data for subsequent key derivation modules to derive token and command keys. Simultaneously, after the session is established, the client device cleans up temporary sensitive data and intermediate authentication values ​​from the password input process to reduce the dwell time of sensitive information on the client side.

[0042] Through the above implementation method, this embodiment combines user password factors and device factors generated by hardware security units for session-level authentication within the encrypted communication channel, and forms a session master key bound to the session context after successful authentication, providing a unified and session-isolated key basis for the authentication and encryption of subsequent instruction-level security tokens and control instructions.

[0043] In some embodiments, the system further includes a device conformance check module, used for: Extract the first device identity information corresponding to the client device certificate from the handshake context of the secure communication module; Extract the second device identity information from the session authentication data of the session authentication module; A consistency comparison is performed between the identity information of the first device and the identity information of the second device. If the consistency comparison passes, it is determined that the client device corresponding to the encrypted communication channel and the client device participating in the authentication of the session authentication module are the same device, and a session validity flag is output.

[0044] Specifically, the secure communication module maintains a handshake context during the handshake process of establishing an encrypted communication channel. This handshake context records at least the peer's certificate chain verification result, the peer device certificate, the current channel session identifier, and handshake digest information used for channel key negotiation. The session authentication module generates session authentication data when performing session-level two-factor authentication within the encrypted communication channel. This session authentication data includes at least an authentication message proving password knowledge and a challenge signature or authentication element associated with the device identity key to prove device factors, and carries or allows deduction of the client device's identity information.

[0045] During the first device identity information acquisition phase, the device consistency check module extracts the first device identity information corresponding to the client device certificate from the handshake context of the secure communication module. The first device identity information may be the device identity public key information in the client device certificate, the certificate subject field associated with the device identity public key, or the device identifier digest used to identify the client device in the device certificate's extended fields. In one embodiment, upon successful handshake, the secure communication module parses the public key field in the client device certificate into the first device identity information and establishes an association with the channel session identifier for storage, so that subsequent consistency checks can directly reference it.

[0046] During the second device identity information acquisition phase, the device consistency check module extracts the second device identity information from the session authentication data of the session authentication module. The second device identity information may be the client device identity key public key carried in the session authentication data, the public key identifier corresponding to the signature of the challenge random number by the hardware security unit, or a device identity public key digest verifiable by the device authentication data. In one embodiment, when generating the login data packet, the session authentication module writes the device identity public key or its digest used to verify the device authentication data as the second device identity information into the session authentication data, enabling the controller device to perform unified extraction and comparison on the server side.

[0047] During the consistency comparison phase, the device consistency check module performs a consistency comparison between the first device identity information and the second device identity information. The consistency comparison can include exact string matching, byte-level comparison, or digest-based consistency comparison, specifically determined by the representation format of the first and second device identity information. In one embodiment, when the first device identity information is a byte sequence of the device certificate public key and the second device identity information is a byte sequence of the device identity public key used for device authentication data verification, the device consistency check module performs an exact comparison of the public key byte sequences. In another embodiment, when both the first and second device identity information are digest identifiers of the device identity public key, the device consistency check module performs a consistency comparison of the digest identifiers.

[0048] When the consistency comparison passes, the device consistency check module determines that the client device corresponding to the encrypted communication channel and the client device participating in the session authentication module are the same device, outputs a session valid flag, and writes the session valid flag into the session state data, allowing the key derivation module to continue to derive the token key and instruction key based on the session master key; when the consistency comparison fails, the device consistency check module outputs a session invalid flag and triggers session termination processing or refuses to enter the key derivation and instruction issuance process, so as to prevent attackers from impersonating the user in the established encrypted communication channel by replacing session authentication data or transferring authentication materials.

[0049] Through the above implementation method, this embodiment establishes a mandatory consistency check between communication layer device certificate authentication and session layer device factor authentication, so that the channel identity and the authentication identity are consistent, thereby providing a reliable cross-layer security context for subsequent instruction-level token encryption and authentication encryption.

[0050] In some embodiments, the key derivation module is used for: The controller device and the client device negotiate and determine the key derivation algorithm and the set of key derivation parameters within an encrypted communication channel; The controller device and the client device generate and exchange their respective random number materials, and obtain a shared random number based on the combination of random number materials. The parameter digest values ​​are calculated for the key derivation algorithm and the key derivation parameter set, and consistency verification is performed. When the consistency verification passes, the controller device and the client device independently perform key derivation operations based on the session master key and the key derivation parameter set, and derive the token key and instruction key based on different derivation context identifiers.

[0051] Specifically, after the controller device and the client device complete session-level two-factor authentication and negotiate to obtain the session master key, they bind and save the session master key and session identifier as session state data. After the device consistency check module determines that the communication layer identity and the session layer identity are consistent and outputs the session validity flag, the key derivation module starts the key derivation process in the encrypted communication channel to generate the token key and instruction key for the subsequent instruction issuance stage.

[0052] During the derivation parameter negotiation phase, the controller device and the client device negotiate and determine the key derivation algorithm and the key derivation parameter set through an encrypted communication channel. The key derivation parameter set includes at least a session identifier, a derivation purpose identifier, identification information of random number materials from both parties, and derivation context information associated with the current session context. The derivation purpose identifier is used to distinguish the derivation fields of the token key and the command key. The derivation context information may include a handshake digest, an authentication digest, or a challenge random number digest from the session authentication process, used to bind the derivation result to the authentication context of the current session. In one embodiment, the controller device, as the parameter selector, selects the target key derivation algorithm from the candidate algorithm set submitted by the client device and generates a derivation parameter set associated with the session identifier, returning it to the client device. In another embodiment, both parties directly determine the target key derivation algorithm according to a preset strategy, using the session identifier as the core index of the derivation parameter set.

[0053] During the random number exchange phase, the controller device and the client device generate and exchange their respective random number materials. The controller device generates server-side random number materials and sends them to the client device, while the client device generates client-side random number materials and sends them to the controller device. After receiving the random number materials from the other end, both parties combine them according to a predetermined combination rule to obtain a shared random number. The shared random number is used to introduce randomness contributed by both parties to ensure the freshness of the derived key and reduce the risk of replay. The combination rule can be XOR combination, concatenation combination, or digest-based combination, and the specific rule can be determined according to the system's preset combination strategy.

[0054] During the parameter digest consistency verification phase, the controller device and the client device calculate parameter digest values ​​for the determined key derivation algorithm and key derivation parameter set, respectively, and exchange parameter digest values ​​through an encrypted communication channel for consistency verification. This consistency verification confirms that both parties used completely consistent algorithms and parameter inputs before key derivation, preventing man-in-the-middle interference, transmission errors, or parameter inconsistencies from causing deviations in the derivation result. In one embodiment, the client device first calculates the parameter digest value and sends it to the controller device. The controller device calculates its own parameter digest value and compares it with the parameter digest value of the client device. If the comparison matches, the controller device returns consistency confirmation information to the client device; if the comparison does not match, the controller device determines that the consistency verification has failed and terminates the derivation process.

[0055] During the key derivation phase, when the consistency check passes, the controller device and the client device independently perform key derivation operations based on the session master key and the key derivation parameter set, respectively. Specifically, the key derivation module uses the session master key as the primary input, and a shared random number, session identifier, and derivation context information as auxiliary inputs. A derivation purpose identifier is introduced to distinguish the derivation domains of keys for different purposes. The controller device and the client device obtain the same derivation result without transmitting the final derivation key. Further, the key derivation module derives a token key and a command key based on different derivation context identifiers. The derivation context identifier corresponding to the token key is used to limit the key to encryption of security tokens, and the derivation context identifier corresponding to the command key is used to limit the key to authentication encryption of control commands. After derivation, the controller device and the client device associate the token key and the command key with the session identifier and save them as session-state keys. At the end of the session, the session-state keys are deleted according to a preset session cleanup policy to reduce the risk of key residing in the session.

[0056] Through the above implementation, this embodiment introduces derived parameter negotiation, random number material combination between both parties and parameter digest consistency verification based on the session master key under the premise that the session is valid. Under the constraint of the derived context identifier with purpose isolation, the token key and the instruction key are derived, thereby forming a session-isolated and purpose-isolated instruction-side key system without adding additional asymmetric computation burden, providing a consistent and verifiable key foundation for subsequent security token encryption and instruction authentication encryption.

[0057] In some embodiments, the security token generation module is used for: Based on the user identifier, device identifier, and instruction permission information associated with the user identifier, construct a plaintext token containing the controller device identity identifier, client device identity identifier, user identifier, instruction permission information, and token validity period information; The plaintext of the token is structured and encapsulated to generate a token data unit, and the timestamp or retention duration parameter corresponding to the token validity information is written into the token data unit. The token data unit is symmetrically encrypted using the token key to obtain the token ciphertext.

[0058] Specifically, the user identifier comes from the user identity confirmed by the session authentication module after the session-level two-factor authentication is passed; the device identifier comes from the client device identity information and the controller device's own identity information determined by the device consistency check module after the cross-layer consistency check is passed; the instruction permission information comes from the set of instruction permissions pre-configured by the controller device and associated with the user identifier; and the validity period information is used to limit the time window or duration for which the token can be accepted on the instruction side, so as to support anti-replay and lightweight verification strategies.

[0059] During the token plaintext construction phase, the security token generation module, assuming the session validity flag indicates the session is valid and the token key has been derived by the key derivation module, reads the user identifier and session identifier from the session state data, and then reads the device identifier and command permission information associated with the user identifier. Specifically, the controller device identity identifier can be taken from the identity field in the controller device certificate or the public key digest of the controller device identity key; the client device identity identifier can be taken from the identity field in the client device certificate or the public key digest of the client device identity key. These identity identifiers must be consistent with the comparison criteria of the device consistency check module to ensure that subsequent verification on the controller device side achieves source matching. Based on this, the security token generation module constructs the token plaintext, which includes at least the controller device identity identifier, client device identity identifier, user identifier, command permission information, and token validity period information. The token validity period information can be in absolute timestamp form or relative retention duration form; when using retention duration form, the token plaintext further includes the time base of the token generation time or the time base identifier associated with the session identifier to support the controller device side in calculating the validity period window.

[0060] During the structured encapsulation phase, the security token generation module performs structured encapsulation on the plaintext token to generate token data units. The purpose of structured encapsulation is to ensure that each field of the token has defined field boundaries and consistent parsing rules, avoiding inconsistencies in verification methods caused by field ambiguity. In one embodiment, the token data unit includes a fixed field area and an expandable field area. The fixed field area carries the controller device identity identifier, client device identity identifier, user identifier, and token validity period information. The expandable field area carries instruction permission information and permission version identifiers related to the permission information. In another embodiment, the token data unit further includes a token serial number or token digest identifier associated with the session identifier, enabling the controller device to quickly determine duplicate tokens based on the validity period. The security token generation module writes a timestamp or retention duration parameter corresponding to the token validity period information into the token data unit, and may also include the token generation time or time base identifier for subsequent verification by time window.

[0061] During the token encryption phase, the security token generation module performs symmetric encryption on the token data unit based on the token key to obtain the token ciphertext. The token key is a session-state key derived by the key derivation module based on the session master key under a purpose-isolated derivation context identifier. The token key and the command key are independent of each other, thus isolating the token ciphertext and command ciphertext at the key level. Symmetric encryption can be implemented using block cipher mode or stream cipher mode, combined with random initialization vectors or counter parameters, to ensure that the same plaintext token corresponds to different ciphertexts in different sessions or at different generation times. After encryption, the security token generation module associates the token ciphertext with the session identifier and writes it into the buffer of the command data packet to be sent, so that the command encryption module can use the token ciphertext as associated data in the authentication encryption of control commands.

[0062] In one optional implementation, to reduce the overhead of token decryption and verification for duplicate commands on the controller device side, the security token generation module generates a token digest identifier while generating the token ciphertext, and associates the token digest identifier with the token validity period information. During subsequent command verification, the controller device can use the token digest identifier to perform fast duplicate detection within the validity period window, thereby reducing repeated decryption operations. This optional implementation does not change the basic link of token ciphertext participating in command authentication encryption binding; it only optimizes the token verification processing path within the validity period window.

[0063] Through the above implementation method, this embodiment, based on the trusted session context formed by session-level two-factor authentication and cross-layer device consistency verification, uniformly encapsulates the controller device identity identifier, client device identity identifier, user identifier, instruction permission information, and validity period information into a token data unit, and uses the token key to perform symmetric encryption to obtain the token ciphertext. This allows the token ciphertext to participate in subsequent authentication encryption binding as an instruction-level security context carrier, while providing a clear field basis for the controller device to perform device identifier consistency verification, time window verification, and permission verification.

[0064] In some embodiments, the instruction encryption module is used for: The control commands and command parameters to be issued are encapsulated in a structured manner to obtain plaintext data units of commands, and random numbers or sequence identifiers associated with session identifiers are configured for the plaintext data units of commands. Using the instruction key as the authentication encryption key and the token ciphertext as the associated data, the authentication encryption operation is performed on the instruction plaintext data unit to obtain the instruction ciphertext and the authentication tag associated with both the token ciphertext and the instruction ciphertext.

[0065] Specifically, the instruction encryption module operates on the client device side, which is either an operator station or an engineer station, and the controller device is a PLC controller. After the session authentication module completes session-level two-factor authentication and the device consistency check module outputs a session validity flag, the client device obtains the session state key material and enters the instruction issuance stage. Each time the instruction encryption module is ready to issue a control instruction, it reads the session identifier, instruction key, and token ciphertext from the session state data, and performs instruction encapsulation and authentication encryption processing using the session identifier as an index.

[0066] During the plaintext encapsulation stage, the instruction encryption module structurally encapsulates the control instructions to be issued and their parameters to obtain plaintext data units. Control instructions can be write instructions to PLC control logic, start / stop instructions, mode switching instructions, or parameter setting instructions, etc. Instruction parameters include a target object identifier matching the instruction type, a target register area or function block identifier, parameter values, and necessary execution condition descriptions. The purpose of structured encapsulation is to enable the controller device to parse the instruction type and parameter boundaries in a consistent format after decryption, avoiding ambiguity. To enhance anti-replay capability and distinguish multiple instructions within the same session, this embodiment configures a random number or sequence identifier associated with the session identifier for the plaintext data unit. This random number or sequence identifier can be composed of a random number generated by the client device, an incrementing sequence number, or a combination of both, and can further include an instruction generation timestamp or a time base identifier associated with the token validity window, enabling the controller device to perform duplicate determination of the instruction based on the random number or sequence identifier after the token verification is successful.

[0067] During the authentication encryption phase, the instruction encryption module uses the instruction key as the authentication encryption key and the token ciphertext as the associated data to perform authentication encryption operations on the plaintext instruction data unit, obtaining the instruction ciphertext and an authentication tag associated with both the token ciphertext and the instruction ciphertext. The authentication encryption operation employs an authentication encryption mechanism that jointly outputs "encryption" and "integrity authentication." Specifically, the plaintext instruction data unit is encrypted into instruction ciphertext under the control of the instruction key, while the authentication tag is output as the authentication result. The calculation of the authentication tag not only covers the instruction ciphertext itself but also the token ciphertext as the associated data input, making the token ciphertext and instruction ciphertext cryptographically strongly bound. Therefore, if an attacker attempts to replace the token ciphertext or the instruction ciphertext, the controller device will fail to verify the authentication tag, thus blocking the attack path of "instruction content mismatch with security context."

[0068] In one implementation, to ensure that the same plaintext instruction within the same session corresponds to different ciphertext instructions at different times, the instruction encryption module generates a one-time random parameter for the current authentication encryption operation and associates this one-time random parameter with the session identifier or sequence identifier, so that the controller device side uses consistent input when verifying the authentication tag and decrypting. The one-time random parameter can be reused with the random number or sequence identifier in the plaintext instruction data unit, or it can be generated independently and sent along with the instruction data packet.

[0069] During the data assembly phase, the command encryption module assembles the token ciphertext, command ciphertext, and authentication tag into a command data packet, along with necessary index information associated with the session identifier. This allows the controller device to retrieve the corresponding token key and command key based on the session identifier upon receipt. The command data packet is sent to the controller device through the established encrypted communication channel. On the controller device side, the command verification and execution module verifies the authentication tag, decrypts and verifies the token ciphertext, and, upon successful verification, decrypts the command ciphertext to obtain the control command and executes it.

[0070] Through the above implementation method, this embodiment uses the instruction key to authenticate and encrypt the control instruction based on the trusted session formed by session-level two-factor authentication and cross-layer device consistency verification, and uses the token ciphertext as associated data to participate in the authentication tag calculation, thereby realizing the encryption protection and integrity verification of the control instruction content, and ensuring that the control instruction is consistent with the security context constituted by the user identity, device identity, permission information and validity period information, providing a verifiable data binding basis for the first-to-true and then-decryption processing on the controller device side.

[0071] In some embodiments, the instruction execution module is used for: Receive instruction data packets containing token ciphertext, instruction ciphertext, and authentication tag sent by the client device, and obtain the instruction key and token key corresponding to the instruction data packet based on the session identifier; The instruction key is used to perform authentication tag verification on the instruction data packet to ensure that the token ciphertext and instruction ciphertext have not been tampered with during transmission when the authentication tag verification is successful. When the authentication tag is verified, the token ciphertext is decrypted using the token key to obtain the token plaintext, and token verification is performed based on the controller device identity, client device identity, user identity, instruction permission information and validity period information in the token plaintext. When the token verification is successful, the command key is used to decrypt the command ciphertext to obtain the control command. Based on the association between the control command and the corresponding command permission information, the control command is output to the command execution unit of the controller device for execution.

[0072] Specifically, the controller device is a PLC controller, and the client device is an operator station or engineer station. During the session establishment phase, the controller device completes session-level two-factor authentication and obtains the session master key. After the device consistency check module outputs a session validity flag, the key derivation module derives the token key and instruction key associated with the session identifier and stores them as session state keys. The instruction verification and execution module uses the session identifier as an index to sequentially process the inbound instruction data packets: key location, integrity verification, token decryption and verification, and instruction decryption and execution.

[0073] During the command data packet reception and key acquisition phase, the controller device receives a command data packet sent by the client device. This command data packet contains a token ciphertext, a command ciphertext, and an authentication tag, and carries or can be deduced a session identifier corresponding to the current session. Based on the session identifier, the controller device retrieves the command key and token key corresponding to the command data packet from the session state key cache. To avoid cross-session key misuse, this embodiment establishes a one-to-one correspondence between the session identifier and the session state key. When the session identifier does not exist or is invalid, the controller device directly determines that the command data packet is unacceptable and initiates an alarm or audit logging process.

[0074] During the authentication tag verification phase, the command verification and execution module uses the command key to perform authentication tag verification on the command data packet. Authentication tag verification uses the token ciphertext as associated data in the verification input, ensuring that the authentication tag verification simultaneously covers the binding relationship between the token ciphertext and the command ciphertext. If authentication tag verification fails, it is determined that the token ciphertext or command ciphertext has been tampered with or mismatched during transmission. The controller device does not enter the decryption path but directly rejects the command data packet, recording the reason for failure, session identifier, command data packet digest, and arrival time for subsequent auditing.

[0075] During the token decryption and verification phase, when the authentication tag verification is successful, the instruction verification and execution module uses the token key to decrypt the token ciphertext to obtain the token plaintext. The token plaintext is the result of decrypting the token data unit constructed and structurally encapsulated by the aforementioned security token generation module, and includes at least the controller device identity identifier, client device identity identifier, user identifier, instruction permission information, and validity period information. The controller device performs token verification based on the token plaintext, and the token verification includes at least one or a combination of the following: Controller device identity verification: The controller device identity in the token plaintext is compared with the identity information in the controller device's own device certificate or the public key digest of the controller device's identity key to confirm that the server device to which the token is addressed is the current controller device; Client device identity verification: The client device identity in the token plaintext is compared with the client device identity information determined during the session authentication phase to confirm that the client device corresponding to the token is consistent with the client device bound to this session; User ID verification: The user ID in the token plaintext is compared with the user ID that was authenticated in this session or the user ID in the binding record to confirm that the user identity corresponding to the token is consistent with the current session. Validity verification: The validity information in the token plaintext is compared with the current system time of the controller device within a time window to confirm that the token is within an acceptable valid time range; when the token validity information adopts the retention duration form, the controller device calculates the valid time window based on the token generation time or time base identifier; Permission verification: Based on the instruction permission information in the token plaintext, a conformity judgment is made with the permission rules pre-configured on the controller device. This includes at least a judgment on the matching of instruction type, instruction parameter range, or target object identifier with the permission mask, to confirm that the current user has the permission to execute this type of control instruction in the current device context.

[0076] In one optional implementation, to reduce the decryption and verification overhead of duplicate instructions within the validity window, the controller device establishes a short-term buffer based on the token validity information after the token verification is successful. This buffer caches the authentication tag or instruction ciphertext digest associated with the token ciphertext. When a duplicate instruction data packet matching the authentication tag or instruction ciphertext digest is received within the validity window, the controller device can directly determine that the data packet is consistent with the already verified data packet and reuse the previous verification conclusion according to a preset strategy to enter the instruction execution path or the fast rejection path. This caching mechanism uses the validity information as a boundary to avoid long-term caching introducing security risks.

[0077] During the instruction decryption and execution phase, when the token verification passes, the instruction verification and execution module uses the instruction key to decrypt the encrypted instruction to obtain the control instruction. The control instruction is the result of decrypting the structured, encapsulated plaintext data unit from the client side, containing the instruction type and parameters. The controller device establishes an association between the control instruction and the instruction permission information in the token plaintext, and outputs the control instruction to the controller device's instruction execution unit for execution. The instruction execution unit can be the instruction scheduler or control logic execution engine during PLC runtime. Before execution, it can further perform format verification and security boundary checks on the instruction parameters to ensure that the instruction parameters meet the device's operational constraints.

[0078] After execution, the controller device returns the instruction execution result to the client device and records audit entries in the local audit log, including at least the session identifier, user identifier, client device identity identifier, controller device identity identifier, instruction type, execution time, and execution result, for subsequent traceability and compliance auditing.

[0079] Through the above implementation method, this embodiment forms a processing sequence of "first authentication tag verification, then token decryption verification, and finally instruction decryption and execution" on the controller device side, and uses the user and device context carried by the token to impose fine-grained constraints on instruction execution, thereby realizing instruction-level two-factor security verification and auditable instruction execution process.

[0080] The implementation process of the controller instruction-level authentication process involved in this application will be described in detail below based on the system architecture and functions of the foregoing embodiments, in conjunction with the accompanying drawings and embodiments. Figure 3 This is a schematic diagram illustrating the implementation process of the controller instruction-level authentication flow provided in an embodiment of this application. For example... Figure 3 As shown, the controller instruction-level authentication process of this application is divided into the following three stages: registration stage, login stage, and instruction execution stage.

[0081] During the registration phase, after the operator enters their password, the OPAQUE registration calculation is executed, generating a user key pair and an encrypted envelope. Simultaneously, the TPM generates a device identity key pair, configures the instruction permission table set, and constructs a registration data packet. The operator station's TPM signs the packet using the device identity private key and sends it to the server (PLC device). The server verifies the AIK certificate and device certificate and stores the binding record. The binding record contains information including the encrypted envelope user identifier, OPRF configuration parameters and salt value, envU, client public key, device public key, and instruction permission set.

[0082] The operation phase consists of two steps: user login and command issuance. During normal operation, user login is initiated first. The server (PLC) verifies the user using the OPAQUE password and simultaneously verifies the client (operator station) TPM device based on the device's public key. Upon successful verification, a session key is established. From this session key, a token encryption key A and a command encryption key B are derived. The command token is then encrypted using derived key A before the command is issued. The command is encrypted using AEAD encryption, with the key source being derived key B. After encryption, the attached token information is decrypted. The server identity identifier, client identity identifier, token validity period, and permission information contained in the token are compared and determined. If the determination is successful, the command is executed; otherwise, an alarm is triggered.

[0083] The registration process consists of the following 5 steps: Step 1: User input The user enters their username and password on the client interface. After receiving the user's credentials, the client sends a request to the TPM client on the same machine, requesting the generation of a key pair specifically for this device.

[0084] Step 2: Generate device key The client-side TPM generates a device key pair. It then returns the AK (Authorization Key) certificate along with the generated device public key to the client. The AK certificate serves as the TPM module's own authentication proof, representing a higher level of security.

[0085] Step 3: OPAQUE Calculation The client performs calculations related to the OPAQUE protocol. First, it calculates a blind password rwdU by combining the user password and the salt value provided by the server. Then, it generates an encryption key pair. Finally, it uses the calculated rwdU to encrypt the device public key obtained from the TPM in step 2, resulting in enc_dev_pk. This securely binds the user secret to the device hardware identity.

[0086] Step 4: Construct and sign the registration data packet The client constructs a registration data packet containing the username, encrypted device public key, etc., and requests the client TPM to sign the registration data packet using the device private key to prove that the request does indeed come from a legitimate TPM hardware.

[0087] Step 5: Send registration request The client sends a complete registration data packet containing the TPM's digital signature to the server. The server verifies whether the TPM's AIK certificate was issued by a trusted authority, confirming that the device TPM is trustworthy. It then uses the TPM's device public key to verify the data packet's signature, ensuring the integrity and authenticity of the registration request. Upon successful verification, the server associates the user account, the encrypted device public key, and the TPM's identity information to form a binding record, which is then stored. At this point, device registration is successful.

[0088] Furthermore, the operational phase includes the following five steps: Step 1: Login Authentication The user enters a username and password. The client TPM challenges the server's signature to prove the device's identity, verifies the password knowledge using the OPAQUE protocol, and outputs the same session master key negotiated by both parties.

[0089] Step 2: Key Derivation Both parties negotiate the KDF algorithm, random numbers, session ID, and other derived parameters. They exchange random number materials through a secure channel to generate shared random numbers and exchange parameter hash values ​​to ensure that the parameters of both parties are completely consistent. They also derive token encryption keys and command encryption keys from the session master key and verify the consistency of the keys derived by both parties through encryption challenges to ensure that the command key is isolated from the session and that leakage will not affect other sessions.

[0090] Step 3: Encrypted execution of instructions Construct a security token containing permissions and device information. Encrypt the instructions in plaintext, and use the token as Associated Data (AAD). The server first verifies the AAD tag, then decrypts the token and instructions, and executes the industrial control instructions after verifying the token's validity.

[0091] Step 4: Session Cleanup Securely erase temporary keys and sensitive data, record complete operation logs for security auditing, update session state, and prepare for the next operation.

[0092] The improved OPAQUE login authentication process employs multi-factor authentication for both users and devices, along with secondary verification of the device to prevent session hijacking and third-party interference. Standard OPAQUE credentials are globally valid; as long as the server stores the authenticated party's (envU, pkU), a login attempt can be initiated from a compatible OPAQUE client. In the improved OPAQUE login process, credentials are locally valid. The authenticated party's (envU, pkU) can only be verified on the server (controller) side when combined with a specific dev_pk (i.e., a specific operator station). While attackers can crack a leaked server database using standard OPAQUE methods (such as rainbow tables), the improved OPAQUE login process ensures that even if a leaked server database is cracked, it cannot be used because there is no bound device private key dev_sk to generate a valid login signature.

[0093] The steps of the TPM-based OPAQUE login authentication process are described below: Step 1: Login Initialization The user enters their username and password on the client; the client sends the username to the server to request registration; the server returns a random challenge number (nonce). This initiates the login process, with the server issuing a challenge to prevent replay attacks.

[0094] Step 2: Device Response The client sends its device passkey to the server; the TPM receives the nonce from the server. It then registers or verifies the client device's identity and prepares for subsequent authentication.

[0095] Step 3: OPAQUE Authentication Calculation TPM derives a key from the user's password, decrypts the ciphertext stored on the server to obtain the salt value, generates a temporary session key, and calculates the OPAQUE authentication data (auth_message). Core cryptographic operations are performed in a secure hardware environment, ensuring that sensitive information such as user passwords is not exposed.

[0096] Step 4: Construct and send data The client constructs a complete login data packet containing authentication data (auth_message), a random number (pkrd), and a challenge number (nonce), and sends it to the server. The authentication evidence calculated by the TPM is then submitted to the server for verification.

[0097] Step 5: The server verifies whether the device signature is within a valid range, executes the server-side verification process of the OPAQUE protocol, calculates the session key (K_session), and records the audit log. This comprehensively verifies the client device identity and the correctness of the user password.

[0098] Step 6: Client completes The client calculates the session key (K_session), and after receiving the server's successful authentication message, securely discards the temporary password and sensitive data. The client completes session establishment and cleans up sensitive information to ensure forward security.

[0099] In the device consistency check during server verification, after verifying the OPAQUE device signature, the server compares the device public key in the TLS certificate with the device public key in the OPAQUE / challenge response to ensure consistency across the security context.

[0100] After successful two-factor authentication and device consistency check, the application layer generates a master key K_master. This key is generated jointly by the user password and the device identities of both the client and server, ensuring extremely high security.

[0101] Step 2 of the operation phase, key derivation, involves key negotiation and derivation based on the encrypted master key generated by the client (operator station) and the server (controller), generating encrypted token encryption keys and instruction encryption keys, conforming to industry security standards and best practices. The key derivation process steps are as follows: Step 2.1: Initialization parameter negotiation The algorithm for key derivation, session context, and random number basis are determined, ensuring both parties use the same computational standard. The client initiates a parameter negotiation request to the server, including a list of supported KDF algorithms (such as HKDF-SHA256). The server selects an algorithm based on the security policy, generates a session ID and a server random number R_s, and returns a negotiation response.

[0102] Step 2.2: Exchange random number materials By introducing randomness contributed by both parties, the freshness of the generated key is ensured, replay attacks are prevented, and the unpredictability of the key is guaranteed. The client generates a high-entropy client-side random number R_c and sends it to the server. The server receives R_c and combines it with its own R_s (e.g., through an XOR operation R = R_c ⊕ R_s) to generate the final negotiated random number.

[0103] Step 2.3: Confirm derived parameters A critical consistency check is performed to prevent man-in-the-middle attacks or transmission errors, ensuring that both parties use identical input parameters in subsequent steps. The client independently calculates the hash value of the parameters and compares it with the value sent by the server. After verification, an acknowledgment response is sent. The server calculates the hash values ​​of all determined parameters (algorithm, session ID, random number R, etc.) and sends them to the client for confirmation.

[0104] Step 2.4: Independent Key Derivation The core security step of key negotiation is enabling both parties to independently derive the same session key without transmitting the final key. The client uses the shared K_master and confirmed parameters to execute the KDF locally, deriving the instruction key K_instruction. The server independently uses the same K_master and parameters to execute the same KDF, deriving its own K_instruction.

[0105] Step 2.5: Key Confirmation and Verification Verify that the derived keys from both parties are completely identical. This ensures the confidentiality and integrity of subsequent communications before proceeding to the secure instruction transmission phase. The client encrypts a known test data (challenge) using the newly derived K_instruction and sends the ciphertext to the server. The server decrypts the challenge data using its locally derived K_instruction. If decryption is successful and the data is correct, a verification success is returned.

[0106] After key derivation is completed, the application instruction security layer is entered. The instruction encryption execution process in step 3 of the runtime phase is as follows: Step 3.1: Constructing Security Instructions The operation instructions are converted into a machine-readable standard format and strongly bound to the executor's identity, permissions, and timeliness. Encrypted tokens are used to prevent the leakage of sensitive information (such as permissions) and to prepare for subsequent integrity verification.

[0107] 1) Constructing plaintext commands: The operator station serializes control commands and their parameters into structured data (such as JSON format).

[0108] 2) Generate security token: Create a security token that includes the client and server device identity identifiers, user identity (user_id), permissions (permissions), and expiration date.

[0109] 3) Encrypted token: The token is encrypted using a special key (K_token) and a symmetric encryption algorithm such as AES to obtain the ciphertext token (enc_token).

[0110] Step 3.2: Encrypt AEAD commands The AEAD authentication encryption algorithm ensures that the instruction content cannot be eavesdropped on during transmission. An authentication tag (auth_tag) verifies that the instruction and token have not been tampered with during transmission. The ciphertext of the instruction is cryptographically bound to its security context (enc_token).

[0111] 1) Perform AEAD encryption: Encrypt using the instruction encryption key (K_instruction) in AEAD mode (such as AES-GCM). Obtain the instruction ciphertext and authentication tag (auth_tag).

[0112] 2) Send data packet: Combine the encryption token, instruction ciphertext, and authentication tag into a data packet and send it to the PLC device.

[0113] Step 3.3: Decryption and Verification of AEAD Commands First verify data integrity before decryption to prevent the processing of invalid or malicious data. Ensure the current operator has the necessary permissions to execute the command, adhering to the principle of least privilege. Only execute the command after all security checks have passed to prevent unauthorized operations.

[0114] 1) Verify integrity: The PLC device uses the same K_instruction and algorithm to verify the validity of the authentication tag (auth_tag). This is the first step to ensure that the data has not been tampered with.

[0115] 2) Decrypt and verify the token: Use K_token to decrypt enc_token to obtain the plaintext token, and verify its validity period, user permissions, etc. The verification data specifications are shown in Table 1: Table 1 Validation Data Specification Table When verifying a command, check the validity period of the decrypted token. The server starts a timer to cache 10 consecutive AEAD authentication tags and corresponding encrypted commands within the validity period. Duplicate commands within the validity period will no longer require decryption of the command and command token information, reducing command verification overhead.

[0116] 3) Decryption command: After all the above verifications are passed, use K_instruction to decrypt the ciphertext command to obtain the plaintext command.

[0117] Update the ciphertext instructions cached in step 2) to plaintext instructions.

[0118] 4) Execute instructions: The server (PLC device) executes the decrypted or cached control instructions.

[0119] Step 3.4: Client Processing Results Provides operational feedback to operators, forming an operational closed loop. Records complete logs for system monitoring and security incident analysis, meeting the audit requirements of industry safety standards (such as IEC 62443), facilitating post-event traceability and analysis.

[0120] 1) Processing response: The operator station receives and decrypts the instruction execution results returned by the PLC.

[0121] 2) Update the interface: Display the final execution status (such as "success" or "failure") to the operator.

[0122] 3) Log recording: Record key information about this operation (who, when, what was performed, and what the result was) in the audit log.

[0123] The technical solution provided in this application has at least the following advantages: 1. By adopting a strict layered design, security functions are decoupled into independent but interconnected layers (hardware, communication, application, and command), which greatly enhances the security strength compared to independent layered defense. At the same time, each layer has a single responsibility, improving the maintainability and security of the system.

[0124] 2. Based on hardware-level security, the combination of TLS 1.3 and OPAQUE protocols provides forward security and zero-trust security features, fundamentally eliminating the possibility of operator stations or controllers being analyzed offline to brute-force sensitive information, and is immune to phishing attacks.

[0125] 3. Compared with schemes that require asymmetric signatures for instructions, the use of the lightweight AEAD symmetric cryptographic algorithm greatly reduces the execution latency during execution.

[0126] 4. The encrypted token information bound to the instruction enables two-factor authentication of both the instruction device source and the instruction user, thereby enhancing the strength of instruction authentication.

[0127] 5. The operator station does not need to store key-sensitive information, and requires no HSM or complex key management. A temporary key pair is generated only upon login for key exchange during a single session, and the key is discarded immediately after the session ends.

[0128] 6. The AIK key and device key inside the server (PLC controller) are generated by TPM and signed by the TPM root key, and will never be disclosed to the outside world, which can prevent insiders from leaking information and protect against physical attacks.

[0129] 7. Complete operation logs and audit process tracking are in place. Even if a coordinated attack by internal and external personnel succeeds, precise post-attack auditing cannot be avoided.

[0130] The above embodiments have described in detail the specific composition and function of the PLC instruction-level two-factor authentication system based on hardware root of trust of this application. The implementation process of the PLC instruction-level two-factor authentication method based on hardware root of trust of this application will be described in detail below with reference to specific embodiments. Figure 4 This is a flowchart illustrating the PLC instruction-level two-factor authentication method based on a hardware root of trust provided in this application embodiment, as follows: Figure 4 As shown, the method may specifically include the following steps: S401 generates and protects the device identity key and the authentication key within the hardware security unit of the controller device and the client device, outputs the device authentication information associated with the device identity key, and obtains and manages the device certificates of the controller device and the client device based on the device authentication information; S402 establishes an encrypted communication channel between the controller device and the client device based on the device certificate, and completes two-way device authentication during the establishment process; S403, within the encrypted communication channel, performs session-level two-factor authentication based on the device authentication information corresponding to the user password factor and the device identity key of the client device, and negotiates to obtain the session master key when the authentication is successful; S404, derive token key and instruction key based on session master key; S405: Construct a security token based on user identifier, device identifier, instruction permission information and validity period information, and encrypt the security token using the token key to obtain the token ciphertext; S406 uses the instruction key to perform authentication encryption processing on the control instruction, and binds the token ciphertext as associated data with the authentication encryption result of the control instruction to generate instruction ciphertext and authentication tag; S407 verifies the authentication tag based on the command key, and uses the token key to decrypt the token ciphertext and verify the device identifier, validity period information and command permission information of the decrypted security token. When the verification is successful, the command ciphertext is decrypted to obtain the control command and executed.

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

Claims

1. A PLC instruction-level two-factor authentication system based on a hardware root of trust, characterized in that, include: The hardware trust root module is used to generate and protect device identity keys and authentication keys within the hardware security units of controller devices and client devices, and output device authentication information associated with the device identity keys; The device certificate management module is used to acquire and manage device certificates for controller devices and client devices based on the device certification information. The secure communication module is used to establish an encrypted communication channel between the controller device and the client device based on the device certificate, and to complete two-way device authentication during the establishment process; The session authentication module is used to perform session-level two-factor authentication within the encrypted communication channel based on the device authentication information corresponding to the user password factor and the device identity key of the client device, and negotiate a session master key after successful authentication. The key derivation module is used to derive the token key and the instruction key based on the session master key; The security token generation module is used to construct a security token based on user identifier, device identifier, instruction permission information and validity period information, and encrypt the security token using the token key to obtain token ciphertext; The instruction encryption module is used to perform authentication encryption processing on the control instruction using the instruction key, and bind the token ciphertext as associated data with the authentication encryption result of the control instruction to generate instruction ciphertext and authentication tag; The instruction execution module is used to verify the authentication tag based on the instruction key, and to decrypt the token ciphertext using the token key and verify the device identifier, validity period information and instruction permission information of the decrypted security token. When the verification is successful, the instruction ciphertext is decrypted to obtain control instructions and executed.

2. The system according to claim 1, characterized in that, The hardware root trust module is used for: A storage root key for protecting key objects is generated and stored within the hardware security unit, and the private key of the device identity key is encapsulated and protected based on the storage root key, so that the private key of the device identity key remains within the hardware security unit and is not exported. A proof key for device authentication is generated within the hardware security unit, and proof data associated with the public key of the device identity key is signed based on the proof key to obtain the device authentication information; The device certificate management module outputs the public key of the device identity key and the device certification information to the device certificate management module, so that the device certificate management module can prove the association between the device identity key and the hardware security unit based on the device certification information and obtain the corresponding device certificate.

3. The system according to claim 1, characterized in that, The secure communication module is used for: The device certificate management module submits certificate application data containing the device certification information to the enterprise certificate authority to obtain the controller device certificate corresponding to the controller device and the client device certificate corresponding to the client device; During the handshake process of establishing an encrypted communication channel, the controller device and the client device send their respective device certificates to each other and perform certificate chain verification on each other's device certificates based on the trust chain of the enterprise certificate authority. When the certificate chain verification is successful, the consistency between the device certificate and the hardware security unit is verified based on the proof key chain corresponding to the device proof information carried in the device certificate, so as to complete the two-way device authentication, and the encrypted communication channel is established after the two-way device authentication is successful.

4. The system according to claim 1, characterized in that, The session authentication module is used for: Based on the user identifier, the password authentication data and device binding data associated with the user identifier are determined from the pre-stored binding records, and a challenge random number for anti-replay is sent to the client device; The client device performs password authentication key exchange calculation based on the user password factor and the password authentication data to generate session authentication data for proving password knowledge, and calls the hardware security unit to sign the challenge random number using the private key of the device identity key to generate device authentication data. The session authentication data and the device authentication data are sent to the controller device, which verifies the device authentication data based on the device binding data in the binding record, and verifies the session authentication data based on the password authentication data in the binding record, so as to complete the session-level two-factor authentication; When the session-level two-factor authentication is successful, the session master key is negotiated by the controller device and the client device based on the shared result calculated by the password authentication key exchange and in combination with the session context parameters.

5. The system according to claim 1, characterized in that, The system also includes a device consistency check module, used for: Extract the first device identity information corresponding to the client device certificate from the handshake context of the secure communication module; Extract the second device identity information from the session authentication data of the session authentication module; A consistency comparison is performed between the first device identity information and the second device identity information. If the consistency comparison passes, it is determined that the client device corresponding to the encrypted communication channel and the client device participating in the authentication by the session authentication module are the same device, and the session validity flag is output.

6. The system according to claim 1, characterized in that, The key derivation module is used for: The controller device and the client device negotiate and determine the key derivation algorithm and the key derivation parameter set within the encrypted communication channel; The controller device and the client device generate and exchange their respective random number materials, and obtain a shared random number based on the combination of the random number materials. The parameter digest values ​​of the key derivation algorithm and the key derivation parameter set are calculated and consistency checks are performed respectively. When the consistency verification passes, the controller device and the client device independently perform key derivation operations based on the session master key and the key derivation parameter set, and derive the token key and the instruction key based on different derivation context identifiers.

7. The system according to claim 1, characterized in that, The security token generation module is used for: Based on the user identifier, the device identifier, and the instruction permission information associated with the user identifier, a token plaintext containing the controller device identity identifier, the client device identity identifier, the user identifier, the instruction permission information, and the token validity period information is constructed; The plaintext of the token is structured and encapsulated to generate a token data unit, and a timestamp or retention duration parameter corresponding to the token validity information is written into the token data unit; The token data unit is subjected to symmetric encryption based on the token key to obtain the token ciphertext.

8. The system according to claim 1, characterized in that, The instruction encryption module is used for: The control commands and command parameters to be issued are encapsulated in a structured manner to obtain command plaintext data units, and a random number or sequence identifier associated with the session identifier is configured for the command plaintext data units. Using the instruction key as the authentication encryption key and the token ciphertext as associated data, an authentication encryption operation is performed on the instruction plaintext data unit to obtain the instruction ciphertext and the authentication tag associated with the token ciphertext and the instruction ciphertext.

9. The system according to claim 1, characterized in that, The instruction execution module is used for: Receive an instruction data packet containing a token ciphertext, an instruction ciphertext, and an authentication tag sent by the client device, and obtain the instruction key and the token key corresponding to the instruction data packet based on the session identifier; The instruction key is used to perform authentication tag verification on the instruction data packet, so as to determine that the token ciphertext and the instruction ciphertext have not been tampered with during transmission when the authentication tag verification is successful; When the authentication tag is verified, the token key is used to decrypt the token ciphertext to obtain the token plaintext, and token verification is performed based on the controller device identity identifier, client device identity identifier, user identifier, instruction permission information and validity period information in the token plaintext. When the token verification is successful, the instruction ciphertext is decrypted using the instruction key to obtain the control instruction, and the control instruction is output to the instruction execution unit of the controller device for execution based on the association between the control instruction and the corresponding instruction permission information.

10. A PLC instruction-level two-factor authentication method based on a hardware root of trust according to any one of claims 1 to 9, characterized in that, include: The device identity key and authentication key are generated and protected within the hardware security unit of the controller device and the client device, the device authentication information associated with the device identity key is output, and the device certificates of the controller device and the client device are obtained and managed based on the device authentication information. An encrypted communication channel is established between the controller device and the client device based on the device certificate, and two-way device authentication is completed during the establishment process; Within the encrypted communication channel, session-level two-factor authentication is performed based on the device authentication information corresponding to the user password factor and the device identity key of the client device, and a session master key is negotiated when authentication is successful; derive the token key and instruction key based on the session master key; A security token is constructed based on the user identifier, device identifier, instruction permission information, and validity period information, and the security token is encrypted using the token key to obtain the token ciphertext; The control command is authenticated and encrypted using the command key, and the token ciphertext is bound to the authentication and encryption result of the control command as associated data to generate command ciphertext and authentication tag; The authentication tag is verified based on the instruction key, and the token key is used to decrypt the token ciphertext. The device identifier, validity period information and instruction permission information of the decrypted security token are verified. If the verification is successful, the instruction ciphertext is decrypted to obtain the control instruction and executed.

Images