Authentication processing method and device of power terminal, terminal and authentication platform

Abstract

The application relates to an authentication processing method and device of a power terminal, a terminal and an authentication platform, and belongs to the technical field of power system safety. According to the technical scheme provided in the application, the trusted state of the power terminal is verified to obtain a verification result; in the case that the verification result is verified, a short-period trusted token is issued to the power terminal; a state continuity proof sent by the power terminal is received, the state continuity proof is sent by the power terminal within the validity period of the short-period trusted token in the case that a terminal state change is monitored, and the generation of the state continuity proof at least includes the following data: first state data and second state data, the first state data represents historical state data of the last round when the trusted state is verified and is locally retained by the power terminal, and the second state data represents current state data collected in real time by the power terminal after the terminal state changes; and a disposal means for the short-period trusted token is determined based on the state continuity proof.

Description

Technical Field

[0001] This application relates to the field of power system security technology, and in particular to an authentication processing method, device, terminal and authentication platform for power terminals. Background Technology

[0002] As edge access devices in the power Internet of Things system, power terminals undertake key tasks such as data acquisition, remote control, and parameter configuration. Their access reliability and operational security are directly related to the stable operation of the power system.

[0003] To ensure the security of power terminal access, related technologies generally adopt a single-time trusted authentication mechanism: the terminal only completes a one-time trusted state authentication with the service platform when triggered during authentication events such as the initial access to the power service platform, network registration, or initial session establishment. After successful authentication, it obtains long-term or fixed-term service access permissions. As can be seen from the above, the above authentication mechanism is a static trust model, which uses the static authentication result as the basis for long-term trust.

[0004] Under the static trust model described above, relying solely on the initial authentication result to maintain the session trust relationship presents a significant security shortcoming: the trust relationship established by the initial authentication is continuously used, lacking the ability to perceive changes in the terminal state in real time, thus creating security risks. Summary of the Invention

[0005] This invention provides an authentication processing method, apparatus, terminal, and authentication platform for power terminals, aiming to at least address the high security risks associated with static trust models in related technologies. The technical solution of this invention is as follows: According to a first aspect of the present invention, an authentication processing method for a power terminal is provided, the method being applied to an authentication platform, the method comprising: The trusted status of the power terminal is verified, and the verification result is obtained; If the verification result is successful, a short-period trusted token is issued to the power terminal. The short-period trusted token is an access credential for power services with a validity period shorter than the preset duration. The system receives a state continuity certificate sent by the power terminal. The state continuity certificate is sent by the power terminal within the validity period of the short-cycle trusted token when a change in the terminal state is detected. The state continuity certificate is a cryptographic proof message that shows the evolution relationship between the trusted states of the power terminal in two consecutive rounds. The generation of the state continuity certificate includes at least the following data: first state data and second state data. The first state data represents the historical state data stored locally by the power terminal in the previous round when performing trusted state verification. The second state data represents the current state data collected by the power terminal in real time after the terminal state changes. Based on the state continuity proof, the means of handling the short-period trusted token are determined.

[0006] In one possible implementation, the generation of the state continuity proof further includes the following data: the event type corresponding to the terminal state change and the random challenge value issued by the authentication platform; The determination of the handling method for the short-period trusted token based on the state continuity proof includes: The state continuity proof is analyzed to obtain the first state data, the second state data, the event type, and the random challenge value; The validity of the first state data, the second state data, and the random challenge value are verified respectively. If the validity verification of the first state data, the second state data, and the random challenge value is passed, based on the first state data and the second state data, the change event of the terminal state change is identified, and the identified change event of the terminal state change is compared with the event type for consistency. If the consistency comparison between the change event and the event type passes, the handling method for the short-cycle trusted token is determined based on the change event of the terminal state change.

[0007] In one possible implementation, the data types in the first state data and the second state data include: joint binding digest, anti-rollback count, and module change count. The joint binding digest is a comprehensive fingerprint calculated by combining the device identity of the power terminal, the operating system trust measure of the power terminal, the cellular communication module identity of the power terminal, and the user identification module identity of the power terminal. The step of identifying the change event of the terminal state change based on the first state data and the second state data includes: The joint binding digest in the first state data is compared with the joint binding digest in the second state data to obtain the device identity change status, operating system trust measurement change status, cellular communication module identity change status and user identification module identity change status. The rollback count and module change count of the first state data are compared with the rollback count and module change count of the second state data to obtain the rollback count change value and module change count change value. Based on the change identification information, the change events of the terminal status change are identified. The change identification information includes: the device identity change, the operating system trust measurement change, the cellular communication module identity change, the user identification module identity change, the anti-rollback count change value, and the module change count change value. The events that change the terminal state include: resetting the cellular communication module, upgrading the operating system, replacing the cellular communication module, and replacing the user identification module.

[0008] In one possible implementation, the short-cycle trusted token has a trust level, which includes: a third trust level, a second trust level, a first trust level, and a zero trust level, and the permissions of the power services corresponding to the third trust level to the zero trust level are sorted from high to low. The method for handling the short-cycle trusted token based on the change event of the terminal state includes: If the change event is a reset of the cellular communication module, continue to issue the short-cycle trusted token to the power terminal with the current trusted level renewed, or reissue another short-cycle trusted token of the second trusted level to the power terminal. If the change event is an operating system upgrade, reissue another short-cycle trusted token of the second trusted level to the power terminal; If the change event is the replacement of a cellular communication module or a user identification module, a new short-cycle trusted token of the first trusted level is reissued to the power terminal.

[0009] In one possible implementation, the method further includes: If the consistency comparison between the change event and the event type fails, another short-cycle trust token of the zero trust level is reissued to the power terminal. or, If the operating system trust metric in the second state data does not belong to the trust baseline, another short-cycle trust token of the zero trust level is reissued to the power terminal.

[0010] In one possible implementation, verifying the validity of the first state data, the second state data, and the random challenge value respectively includes: The validity of the parsed random challenge value is verified based on the locally retained random challenge value; The validity of the first state data is verified based on the locally retained historical data, wherein the historical data represents the historical data of the previous round of trusted state verification on the authentication platform. The validity of the second state data is verified based on the currently collected state snapshot.

[0011] In one possible implementation, verifying the trusted state of the power terminal to obtain a verification result includes: Send authentication session challenge information to the power terminal and the communication access device respectively; The system receives a terminal-side joint authentication certificate from the power terminal and a network access-side certificate from the communication access device. The terminal-side joint authentication certificate is a cryptographic proof message related to the current authentication session generated by the power terminal from its perspective under the triggering of the authentication session challenge information. The network access-side certificate is a cryptographic proof message related to the current authentication session generated by the communication access device from its perspective under the triggering of the authentication session challenge information. The terminal-side joint authentication certificate is verified in conjunction with the network access-side certificate to obtain the verification result.

[0012] In one possible implementation, the step of verifying the terminal-side joint authentication proof in conjunction with the network access-side proof to obtain the verification result includes: Obtain the first cellular identity information indicated by the network access side certificate and the second cellular identity information indicated by the terminal side joint authentication certificate; The consistency between the first cellular identity information and the second cellular identity information is verified to obtain the verification result.

[0013] In one possible implementation, the method further includes: The system receives a control instruction digest sent by the business platform. The control instruction digest is a digest value obtained by the business platform performing a cryptographic digest operation on a risk control instruction to be executed within the validity period of the short-cycle trusted token. Generate a one-time control micro-token carrying a digest of the control instruction, the one-time control micro-token being a one-time authorization credential for power services for the risk control instruction; The one-time control micro-token is sent to the power terminal. The one-time control micro-token is used for verification by the power terminal, and if the verification is successful, the risk control instruction is executed.

[0014] According to a second aspect of the present invention, an authentication processing method for a power terminal is provided, the method being applied to a power terminal, the method comprising: Receive a short-term trusted token issued by the authentication platform. The short-term trusted token is issued by the authentication platform after verifying the trusted status of the power terminal. The short-term trusted token is an access credential for power services with a validity period shorter than a preset time. Within the validity period of the short-cycle trusted token, when a change in the terminal state is detected, a state continuity proof is generated by combining the first state data and the current second state data. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The state continuity proof is sent to the authentication platform, and the state continuity proof is used by the authentication platform to determine the disposal method for the short-cycle trusted token.

[0015] In one possible implementation, generating a proof of state continuity by combining the first state data and the current second state data includes: Obtain the event type corresponding to the terminal state change, and receive the random challenge value issued by the authentication platform; Using the local hardware private key, the first state data, the second state data, the event type, and the random challenge value are concatenated and signed to generate the state continuity proof.

[0016] According to a third aspect of the present invention, an authentication processing apparatus for a power terminal is provided, the apparatus comprising: The trusted verification module is used to verify the trusted status of the power terminal and obtain the verification result; The token issuance module is used to issue a short-period trusted token to the power terminal when the verification result is successful. The short-period trusted token is an access credential for power services with a validity period shorter than a preset duration. The proof receiving module is used to receive the state continuity proof sent by the power terminal. The state continuity proof is sent by the power terminal within the validity period of the short-cycle trusted token when a change in the terminal state is detected. The state continuity proof is a cryptographic proof message with the evolution relationship between the trusted states of the power terminal in two consecutive rounds. The generation of the state continuity proof includes at least the following data: first state data and second state data. The first state data represents the historical state data of the previous round when performing trusted state verification locally retained by the power terminal. The second state data represents the current state data collected by the power terminal in real time after the terminal state changes. The token handling module is used to determine the handling method for the short-cycle trusted token based on the state continuity proof.

[0017] According to a fourth aspect of the present invention, an authentication processing apparatus for a power terminal is provided, the apparatus comprising: The token receiving module is used to receive short-period trusted tokens issued by the authentication platform. The short-period trusted tokens are issued by the authentication platform after the trusted status of the power terminal is verified. The short-period trusted tokens are access credentials for power services with a validity period shorter than a preset time. The proof generation module is used to generate a state continuity proof by combining the first state data and the current second state data when a change in the terminal state is detected during the validity period of the short-cycle trusted token. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The proof sending module is used to send the state continuity proof to the authentication platform, and the state continuity proof is used by the authentication platform to determine the disposal method for the short-period trusted token.

[0018] According to a fifth aspect of the present invention, an authentication system for a power terminal is provided, the authentication system comprising: an authentication platform and a power terminal; The authentication platform is used to verify the trusted status of the power terminal and obtain the verification result. The authentication platform is used to issue a short-period trusted token to the power terminal when the verification result is successful. The short-period trusted token is an access credential for power services with a validity period shorter than a preset duration. The power terminal is used to receive short-term trusted tokens issued by the authentication platform; The power terminal is used to generate a state continuity proof by combining first state data and current second state data when a change in terminal state is detected during the validity period of the short-cycle trusted token. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The power terminal is used to send the state continuity certificate to the authentication platform; The authentication platform is used to receive the state continuity certificate sent by the power terminal; The authentication platform is used to determine the disposal method for the short-cycle trusted token based on the state continuity proof.

[0019] According to a sixth aspect of the present invention, an authentication platform is provided, the authentication platform including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the method as described in any one of the first aspects above.

[0020] According to a seventh aspect of the present invention, a power terminal is provided, the power terminal including a processor and a memory, the memory storing at least one instruction, at least one program, a code set or an instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the method as described in any one of the second aspects above.

[0021] According to an eighth aspect of the present invention, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or at least one program being loaded and executed by a processor to implement the method as described in any one of the first or second aspects above.

[0022] According to a ninth aspect of the present invention, a computer program product is provided, comprising computer instructions that, when executed by a processor, cause a computer to perform the method as described in any one of the first or second aspects above.

[0023] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: The system performs initial verification of the trusted state of power terminals and issues short-term trusted tokens. Within the validity period of the short-term trusted token, it no longer relies on static initial authentication results. Instead, when a change in terminal state occurs, the power terminal uploads a state continuity proof carrying the evolution relationship between the two trusted states. This allows the authentication platform to dynamically perceive the real changes in the terminal's operating state. The state continuity proof integrates first state data representing the historical trusted state and second state data representing the latest real-time state. This ensures, from a cryptographic perspective, that the terminal state changes are traceable and verifiable. The authentication platform dynamically determines the terminal's trusted state based on the state continuity proof and adaptively adjusts the handling strategy of the short-term trusted token. This effectively avoids the security vulnerability where a power terminal continues to access power services with valid permissions even after authentication has passed, when a change in terminal state leads to security risks. This significantly improves the dynamism, continuity, and security of power terminal authentication. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram illustrating an application environment according to an exemplary embodiment; Figure 2 This is a flowchart illustrating an authentication processing method for a power terminal according to an exemplary embodiment; Figure 3 This is a flowchart illustrating an authentication processing method for another power terminal according to an exemplary embodiment; Figure 4 This is a flowchart illustrating an authentication processing method for another power terminal according to an exemplary embodiment; Figure 5 This is a flowchart illustrating an authentication processing method for another power terminal according to an exemplary embodiment; Figure 6 This is a structural block diagram of an authentication processing apparatus for a power terminal according to an exemplary embodiment; Figure 7 This is a structural block diagram of an authentication processing apparatus for another power terminal, according to an exemplary embodiment. Figure 8 This is a structural block diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0027] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] It should be noted that the following diagram shows one possible sequence of steps, and it is not strictly necessary to follow this order. Some steps can be executed in parallel without interdependence.

[0029] This application provides an authentication processing method for a power terminal, which can be applied to a power system.

[0030] Figure 1 This is a schematic diagram of a power system provided in an embodiment of this application. The power system includes: a power terminal 10 and an authentication platform 20.

[0031] The power terminal 10 can be a distribution area integration terminal, a distribution automation terminal, an electricity consumption information collection terminal, a charging facility controller, a distributed energy controller, an energy storage control terminal, a smart meter gateway, or other types of terminal equipment connected to the power system.

[0032] The authentication platform 20 is a server that performs authentication processing on the power terminal 10. For example, the authentication platform 20 may include the following functions: generating random challenge values, verifying the proof uploaded by the power terminal 10, and issuing or revoking short-term trusted tokens.

[0033] Optionally, the power system further includes a service platform 30. The service platform 30 is a server that provides power services to the power terminal 10. For example, the service platform 30 may include the following functions: controlling telemetry, alarms, parameter writing, upgrades, and remote control based on the trust level and permitted service set in the short-cycle trusted token.

[0034] Optionally, the power system also includes a communication access device 40. The communication access device 40 is a server providing a cellular access network, and the power terminal 10 communicates with the authentication platform 20 and the service platform 30 through the cellular access network provided by the communication access device 40.

[0035] The authentication processing method for power terminals applied to the above-mentioned power system will be described below.

[0036] Figure 2 This is a flowchart illustrating an authentication processing method for a power terminal according to an exemplary embodiment. Figure 2 As shown, the authentication process for power terminals may include the following steps: Step 201: The authentication platform verifies the trusted status of the power terminal and obtains the verification result.

[0037] When the authentication trigger condition is met, the authentication platform initiates the verification of the trusted status of the power terminal and obtains the verification result.

[0038] For example, the verification content of the trusted state includes at least one of the following: verification of the legality of the power terminal's device identity, the integrity of the system software, the identity of the communication module, the identity of the user identification module, and the authenticity of the access session. Based on the above verification content, a comprehensive judgment is made on whether the current software and hardware operating environment, access status, and identity information of the power terminal are compliant and trustworthy, and finally the verification result of the trusted state of the power terminal is obtained.

[0039] For example, the authentication triggering conditions mentioned above can be as follows: (1) The first access or reconnection of the power terminal.

[0040] For example: the power terminal connects to the platform after its first registration; the power terminal restarts; the power terminal comes back online after being offline for a long time; the cellular data connection is re-established after being disconnected; the original authentication session has ended.

[0041] (2) The short-cycle trusted tokens issued in the previous round have expired or are about to expire.

[0042] (3) The authentication platform detected an abnormal risk.

[0043] For example, the authentication platform may detect the following abnormal risks: abnormal login location or access network; repeated re-registration within a short period of time; inconsistency between the cellular identity reported by the power terminal and the information on the network side; the same device identity appearing in multiple access connections simultaneously; suspected replay of authentication messages; and the trusted status of the power terminal not being updated for an extended period of time.

[0044] (4) The authentication platform updates the authentication information of power terminals, such as trusted baselines or security policies.

[0045] For example, the authentication platform has updated the following authentication-related information: trusted baseline of the operating system; trusted baseline of the cellular communication driver; allowed version of the module firmware; registration relationship of power terminal-cellular module-SubscriberIdentityModule (SIM); power service permission policy; authentication algorithm or certificate status.

[0046] Step 202: If the verification result is successful, the authentication platform issues a short-term trusted token to the power terminal.

[0047] Among them, the short-period trusted token is an access credential for power services with a validity period shorter than the preset duration. That is, the short-period trusted token is a short-term valid credential issued by the authentication platform after the authentication platform has verified the power terminal.

[0048] Furthermore, the short-cycle trusted token carries a trust level, with each trust level granting different permissions for power services.

[0049] Step 203: The power terminal receives the short-cycle trusted token issued by the authentication platform.

[0050] Step 204: Within the validity period of the short-cycle trusted token, if a change in the terminal state is detected, the power terminal combines the first state data and the current second state data to generate a state continuity proof.

[0051] The first state data represents the historical state data stored locally by the power terminal during the previous round of trusted state verification. The second state data represents the current state data collected in real time by the power terminal after a change in terminal state.

[0052] During the validity period of the short-cycle trusted token, the power terminal continuously monitors the terminal status. If it detects that the current terminal status has changed compared to the terminal status at the time of issuance of the short-cycle trusted token, it acquires the first status data and the second status data, and combines the first status data and the current second status data to generate a status continuity proof.

[0053] For example, changes in terminal status include changes in device identity status, cellular identity status, or operating system trust measurement status. Cellular identity status can include cellular communication module identity status and user identification module identity status.

[0054] Understandably, since the generation of the state continuity proof combines the aforementioned first state data and second state data, the state continuity proof is a cryptographic proof message that demonstrates the evolutionary relationship between the two trusted states of the power terminal. The state continuity proof is used to trigger continuity re-authentication for the power terminal, which refers to authentication performed based on the evolutionary relationship between the two trusted states.

[0055] Step 205: The power terminal sends a status continuity certificate to the authentication platform.

[0056] Step 206: The authentication platform receives the status continuity certificate sent by the power terminal.

[0057] Step 207: The authentication platform determines the handling method for short-cycle trusted tokens based on the proof of state continuity.

[0058] After receiving the proof of state continuity, the authentication platform parses and verifies the proof of state continuity to obtain the verification result. Based on the verification result, the authentication platform determines the handling method for short-cycle trusted tokens.

[0059] For example, the authentication platform can feed back the processed short-term trusted token to the power terminal. Based on the processed short-term trusted token, the power terminal interacts with the business platform, which is responsible for executing the corresponding release or rejection of the business.

[0060] For example, the means of handling short-term trusted tokens include at least one of the following: maintaining the current short-term trusted token, renewing the current short-term trusted token, revoking the current short-term trusted token, and issuing another short-term trusted token.

[0061] In summary, the method provided in this embodiment performs initial verification of the trusted state of a power terminal and issues a short-cycle trusted token. Within the validity period of the short-cycle trusted token, it no longer relies on the static initial authentication result. Instead, when a change in terminal state occurs, the power terminal uploads a state continuity proof carrying the evolution relationship between the two rounds of trusted states. This allows the authentication platform to dynamically perceive the real changes in the terminal's operating state. The state continuity proof integrates first state data representing the historical trusted state and second state data representing the latest real-time state, ensuring the traceability and verifiability of terminal state changes from a cryptographic perspective. The authentication platform dynamically determines the trusted state of the terminal based on the state continuity proof and adaptively adjusts the handling strategy of the short-cycle trusted token. This effectively avoids the security vulnerability where the power terminal continues to access power services with valid permissions even when a change in terminal state after successful authentication poses a security risk. This significantly improves the dynamism, continuity, and security of power terminal authentication.

[0062] In one possible implementation, the generation of the state continuity proof also includes the following data: the event type corresponding to the terminal state change, and the random challenge value issued by the authentication platform. Then, based on the first state data, the second state data, the event type, and the random challenge value in the state continuity proof, the authentication platform determines the handling method for the short-cycle trusted token.

[0063] That is, in conjunction with references Figure 3 Steps 204 to 207 above can be replaced with the following steps: Step 301: Within the validity period of the short-cycle trusted token, the power terminal, upon detecting a change in terminal status, obtains the event type corresponding to the change in terminal status and receives a random challenge value issued by the authentication platform.

[0064] During the effective lifespan of the short-cycle trusted token, the power terminal continuously monitors its own operating status. Once a change in the terminal status is detected, it immediately identifies the event type corresponding to the change and receives a random challenge value issued by the authentication platform for this continuous re-authentication, which is used to construct a fresh, replay-proof proof of state continuity.

[0065] For example, after detecting a change in the terminal status, the power terminal sends an authentication application message carrying a prompt message about the change in terminal status to the authentication platform. In response to the authentication application message, the authentication platform issues a random challenge value to the power terminal.

[0066] Step 302: The power terminal uses its local hardware private key to concatenate and sign the first state data, the second state data, the event type, and the random challenge value to generate a state continuity proof.

[0067] The power terminal relies on the local hardware private key stored in the local hardware root of trust to complete data concatenation and signature operations only within a hardware-trusted environment, preventing tampering and forgery by upper-layer software. By concatenating and signing the first state data representing the historical trusted state, the second state data representing the latest current state, the event type of the actual state change, and the random challenge value issued by the authentication platform, a state continuity proof with a fresh and credible source is formed, ensuring that the proof message cannot be tampered with, concatenated, or forged.

[0068] Step 303: The power terminal sends a status continuity certificate to the authentication platform.

[0069] After generating a state continuity certificate, the power terminal uploads the certificate to the authentication platform as the core credential for this continuity re-authentication, requesting the platform to verify the legality of the terminal's state change and update the power terminal's trusted state in the current session.

[0070] Step 304: The authentication platform receives the status continuity certificate sent by the power terminal.

[0071] The authentication platform monitors the authentication messages reported by the power terminals in real time, thereby receiving the status continuity proof uploaded by the power terminals.

[0072] Step 305: The authentication platform parses the state continuity proof to obtain the first state data, the second state data, the event type, and the random challenge value.

[0073] The authentication platform parses the received state continuity proof and uses the local signature verification public key to strip the signature information and message fields from the state continuity proof, accurately extracting the following message fields: the historical first state data retained by the power terminal, the second state data currently collected by the power terminal, the event type identified by the power terminal, and the random challenge value corresponding to this re-authentication, providing the original data basis for the subsequent verification process.

[0074] Step 306: The authentication platform verifies the validity of the first state data, the second state data, and the random challenge value, respectively.

[0075] To ensure that the data used in this continuous re-authentication is authentic, valid, unaltered, and does not reuse historical messages, the authentication platform performs source-specific and dimension-specific validity checks on all types of message fields obtained from parsing (first-state data, second-state data, and random challenge values) to prevent forged data, expired data, and illegal parameters.

[0076] In one possible implementation, step 306 includes: (1) Verify the validity of the parsed random challenge value based on the locally retained random challenge value.

[0077] The authentication platform stores the random challenge value issued for this continuous re-authentication locally. It verifies the random challenge value reported by the power terminal as follows: whether it matches the random challenge value stored locally on the authentication platform, whether it is exclusive to this session, and whether it has not expired and has not been used, in order to resist replay attacks.

[0078] (2) The validity of the first state data is verified based on the locally retained historical data. The historical data represents the historical data of the previous round of verification of the trusted state on the authentication platform.

[0079] The authentication platform retrieves historical data of the terminal's trusted status after the previous round of authentication, compares it with the first status data reported by the power terminal, and confirms that the historical first status data is a legitimate and trusted status recognized by the authentication platform, thus eliminating the risk of the terminal forging historical trusted status.

[0080] (3) Verify the validity of the second state data based on the current state snapshot.

[0081] Among them, the status snapshot represents the identity information and operational status information related to authentication collected within a time window.

[0082] The authentication platform combines the latest status snapshot corresponding to this continuous re-authentication to verify that the second status data is consistent with the current actual operating status of the power terminal, ensuring that the received second status data is authentic, reliable, and tamper-free.

[0083] In this embodiment, three independent data sources are used to verify the historical first state data, the current second state data, and the random challenge value of the session separately, thereby realizing the end-to-end trusted verification of state continuity proof and improving the accuracy and reliability of the power terminal's dynamic continuity re-authentication.

[0084] Step 307: If the validity verification of the first state data, the second state data, and the random challenge value is passed, the authentication platform identifies the change event of the terminal state based on the first state data and the second state data.

[0085] After all parameters have passed the validity verification, the authentication platform relies on the status data from the two rounds to identify the differences between the first and second status data, and accurately identifies the actual change events that have occurred in the power terminal based on the differences.

[0086] In one possible implementation, the data types in the first state data and the second state data include: joint binding digest, anti-rollback count, and module change count. The joint binding digest is a comprehensive fingerprint calculated by combining the device identity of the power terminal, the operating system trust measure of the power terminal, the cellular communication module identity of the power terminal, and the user identification module identity of the power terminal.

[0087] Among them, the anti-rollback count represents the count of the operating system version, and the module change count represents the count of the cumulative number of times the cellular communication module has been started.

[0088] For example, if we denote the proof of state continuity as CONT_PROOF, then the formula for CONT_PROOF is as follows: CONT_PROOF = Sign(SK_ROOT, B_PREV ∥ B_CUR ∥ E_EVT ∥ C_MOD_PREV ∥C_MOD_CUR ∥ CTR_PREV ∥ CTR_CUR ∥ N_CONT) Wherein, Sign is the digital signature function; SK_ROOT is the authentication private key stored inside the security chip or trusted execution environment of the power terminal; B_PREV is the combined binding digest in the first state data; B_CUR is the combined binding digest in the second state data; E_EVT is the event type; C_MOD_PREV is the module change count in the first state data; C_MOD_CUR is the module change count in the second state data; CTR_PREV is the anti-rollback count in the first state data; CTR_CUR is the anti-rollback count in the second state data; and N_CONT is the random challenge value.

[0089] For example, if we denote the federated binding digest as B, then the formula for B is as follows: B = H(ID_DEV ∥ ID_OS ∥ M_TRUST ∥ ID_MOD ∥ ID_SIM ∥ SNAP ∥ SID∥ N ∥ T ∥ CTR ∥ POLICY_ID) Wherein, H is the cryptographic hash function; ID_DEV is the device identity of the power terminal; ID_OS is the identity of the operating system instance or trusted operating environment; M_TRUST is the operating system trust metric of the power terminal; ID_MOD is the identity of the cellular communication module of the power terminal; ID_SIM is the identity of the user identification module of the power terminal; SNAP is the state snapshot number; SID is the authentication session identifier; N is the one-time random challenge value for this authentication; T is the challenge time information; CTR is the anti-rollback count; and POLICY_ID is the authentication policy identifier for this authentication.

[0090] For example, the operating system trust metric represents the comprehensive digital fingerprint of the key software of the power terminal's operating system. Let M_TRUST be the denoted trust metric of the power terminal's operating system, and the formula for M_TRUST is as follows: M_TRUST = H(M_BOOT ∥ M_KERNEL ∥ M_DRIVER ∥ M_AUTH ∥ V_OS ∥ CTR) Where H is the cryptographic hash function; M_BOOT is the boot program fingerprint; M_KERNEL is the system kernel fingerprint; M_DRIVER is the communication driver fingerprint of the cellular communication module; M_AUTH represents the authentication service fingerprint; V_OS is the system version; and CTR is the anti-rollback counter.

[0091] Accordingly, step 307 includes: (1) Compare the joint binding digest in the first state data with the joint binding digest in the second state data to obtain the device identity change status, operating system trust measurement change status, cellular communication module identity change status and user identification module identity change status.

[0092] By comparing the joint binding summaries in the two rounds, the system can accurately identify whether there are any changes to the terminal's identity and integrity, such as changes to the entire device, operating system, cellular communication module, or user identification module.

[0093] (2) Perform a difference operation between the rollback count and module change count of the first state data and the rollback count and module change count of the second state data to obtain the rollback count change value and module change count change value.

[0094] By comparing the differences in hardware monotonic counts, it is determined whether an operating system upgrade has occurred, whether there has been a malicious rollback, or whether a module has been restarted or reset. The immutability and unidirectional increment of hardware counts ensure the reliability of state evolution.

[0095] (3) Based on the change identification information, identify the change events of the terminal status. The change identification information includes: device identity change, operating system trust measurement change, cellular communication module identity change, user identification module identity change, anti-rollback count change value and module change count change value.

[0096] The events that change the terminal status include: resetting the cellular communication module, upgrading the operating system, replacing the cellular communication module, and replacing the user identification module.

[0097] For example, if the change identification information is: the module change count change value is positive (i.e. the module change count increases), and other identification information remains unchanged, then the change event of the identification terminal status is the reset of the cellular communication module.

[0098] For example, if the change identification information is: the operating system trust metric changes to a new trust baseline, the rollback prevention count changes to a positive value (i.e., the rollback prevention count increases), and other identification information remains unchanged, then the change event in the terminal state is identified as an operating system upgrade.

[0099] For example, if the change in identification information is: the identity of the cellular communication module has changed, and other identification information has not changed, then the change event in the identification terminal status is the replacement of the cellular communication module.

[0100] For example, if the change in identification information is: the user identification module's identity changes while other identification information remains unchanged, then the change event in the identification terminal's state is the replacement of the user identification module.

[0101] In this embodiment, the first state data and the second state data are defined to include a joint binding digest, an anti-rollback count, and a module change count. The joint binding digest is a comprehensive fingerprint generated by fusing device identity, operating system trust measurement, cellular communication module identity, and user identification module identity. It can aggregate the multi-dimensional identity of the terminal and the software trust baseline into a single cryptographic fingerprint. By comparing the joint binding digests of the two rounds, the changes in each dimension of device identity, operating system trust measurement, module identity, and user identification module identity can be identified, avoiding the problem that relying on a single field cannot locate the specific object that has changed. Simultaneously, anti-rollback counts and module change counts are introduced for differential calculation to quantify the change values ​​of the count dimension. The summary comparison results and the count change results are combined to form change identification information, thereby distinguishing different types of terminal status change events such as cellular communication module reset, operating system upgrade, cellular communication module replacement, and user identification module replacement. The aforementioned terminal status change events can specifically distinguish between normal business events and malicious tampering and replacement events, improving the ability to distinguish various status events during continuous re-authentication. This provides a reliable identification basis for the subsequent authentication platform to perform differentiated handling such as renewal, downgrade, and token revocation for different event types.

[0102] Step 308: The authentication platform will perform a consistency comparison between the identified terminal status change events and the event types.

[0103] The authentication platform will verify the consistency between the change events identified through data difference analysis and the event types reported by the power terminals, and determine whether the event types reported by the power terminals are true and accurate, thereby eliminating the risk of power terminals falsely reporting event types or deliberately concealing malicious abnormal behavior.

[0104] Step 309: If the consistency comparison between the change event and the event type passes, the authentication platform determines the handling method for the short-cycle trusted token based on the change event of the terminal state change.

[0105] If the consistency comparison between the change event and the event type passes, it indicates that the event type reported by the power terminal is accurate. Therefore, the authentication platform determines the handling method for short-cycle trusted tokens based on the specific type of the change event of the terminal status change.

[0106] In one possible implementation, the short-cycle trusted token has a trust level, which includes: third trust level, second trust level, first trust level and zero trust level. The permissions of the power services corresponding to the third trust level to the zero trust level are sorted from high to low.

[0107] The three trust levels are as follows: Level 3 is the highest permission level; short-cycle trusted tokens at Level 3 grant the power terminal all preset power service permissions, such as telemetry, remote signaling, alarms, authorized parameter settings, upgrades, and authorized remote control. Level 2 is the observation permission level; short-cycle trusted tokens at Level 2 grant the power terminal regular power service permissions, such as telemetry, remote signaling, and alarms. Level 1 is the restricted permission level; short-cycle trusted tokens at Level 1 restrict the power terminal to only have alarm, registration, and maintenance permissions. Level 0 is the isolation permission level; short-cycle trusted tokens at Level 0 prohibit the power terminal from accessing and executing services, and only support basic status reporting.

[0108] Accordingly, step 309 includes: (1) If the change event is a reset of the cellular communication module, continue to issue short-term trusted tokens with the current trusted level to the power terminal, or reissue another short-term trusted token with the second trusted level to the power terminal.

[0109] Resetting a cellular communication module is a routine communication restart action that does not change the terminal hardware or trusted status, and therefore carries low risk. Thus, the authentication platform can directly renew the original high-trust level or issue a short-term trusted token of the second-trust level at the observation level, ensuring business continuity while mitigating potential temporary risks.

[0110] (2) If the change event is an operating system upgrade, reissue another short-cycle trusted token of the second trusted level to the power terminal.

[0111] Operating system upgrades carry the risk of temporary instability. Therefore, short-cycle tokens are downgraded to the second level of trust, and higher-level privileges can be restored after subsequent stability verification.

[0112] (3) If the change event is the replacement of the cellular communication module or the replacement of the user identification module, reissue another short-cycle trusted token of the first trusted level to the power terminal.

[0113] Cellular communication modules or user identification modules are core hardware components of the terminal. Unauthorized replacement poses access security risks. Therefore, short-cycle tokens are downgraded to the first level of trust, significantly reducing business privileges.

[0114] In this implementation, a four-level trusted permission system is set up for short-cycle trusted tokens, from high to low: the third trusted level, the second trusted level, the first trusted level, and the zero trusted level. This breaks away from the coarse control mode of traditional power authentication schemes that "only use a binary judgment of legality / illegality and grant or block access in one go," and realizes fine-grained access control of power terminal business permissions. Furthermore, differentiated token handling strategies are matched for different types of terminal state change events, and dynamic adjustments are made under the four-level trusted permissions. Legal and normal changes are allowed to proceed, while hardware changes with security risks are strictly controlled with reduced permissions. This balances the continuity of power grid business and the access security of power terminals, effectively solving the technical defects of traditional static authorization mechanisms that cannot dynamically fine-tune permissions according to terminal status and have coarse security control granularity, and improving the adaptability and security protection accuracy of power terminal dynamic authentication.

[0115] In one possible implementation, the following steps are also included: if the consistency comparison between the change event and the event type fails, reissue another short-cycle trust token of the zero trust level to the power terminal; or, if the operating system trust metric in the second state data does not belong to the trust baseline, reissue another short-cycle trust token of the zero trust level to the power terminal.

[0116] If the event type reported by the power terminal does not match the identified change event, it indicates that the power terminal is suspected of making false reports or deliberately circumventing security verification. Therefore, the authentication platform directly implements the highest level of isolation, downgrading the short-cycle token to the zero trust level, clearing the business permissions, and avoiding the security risk of malicious power terminals accessing the power grid.

[0117] If the operating system trust metric in the second state data does not belong to the trust baseline, it indicates that there is an operating system metric anomaly. The metric anomaly is a high-risk security risk. Therefore, the short-cycle token is downgraded to the zero trust level, the terminal business permissions are directly isolated, all power business access is prohibited, and the power grid security is guaranteed.

[0118] In this implementation, in addition to the conventional scheme of hierarchical authorization based on the type of change event, for scenarios where the event type reported by the power terminal is inconsistent with the change event identified by the authentication platform, and for scenarios where the trust measurement of the terminal operating system deviates from the preset trust baseline, a permission isolation mechanism of short-cycle trust tokens at the zero trust level is used to completely block the attack path of abnormal power terminals continuing to access power services and execute high-risk control commands, and to prevent malicious power terminals from bypassing the security vulnerabilities of the hierarchical authentication system by means of status false reporting, system tampering, etc., thereby further improving the overall security and anti-malicious attack capability of power terminal access.

[0119] In summary, the method provided in this embodiment further introduces the event type corresponding to the terminal state and the random challenge value issued by the authentication platform during the generation of the state continuity proof. Combined with the hardware signature mechanism, a complete state continuity proof is constructed. After verifying the validity of the first state data, the second state data, and the random challenge value, the consistency comparison between the real change event identified by the platform and the event type reported by the power terminal is performed. If the consistency comparison passes, the handling method for the short-cycle trusted token is determined based on the change event of the terminal state change. On the one hand, by introducing a single valid random challenge value, the continuity proof of each state change has session freshness, effectively preventing attackers from using historical proof messages to carry out replay attacks. On the other hand, by incorporating the event type of the real state change into the proof field, the power terminal cannot arbitrarily report change behavior without considering the actual state, avoiding the power terminal from circumventing security control by forging event types, thereby ensuring the reliability of the subsequently determined handling method for the short-cycle trusted token.

[0120] In one possible implementation, the authentication platform combines the network access side certificate fed back by the communication access device with the terminal-side joint authentication certificate uploaded by the power terminal to perform cross-verification.

[0121] That is, in conjunction with references Figure 4 Step 201 above can be replaced by the following steps: Step 401: The authentication platform sends authentication session challenge information to the power terminal and the communication access device respectively.

[0122] The authentication session challenge information represents the session freshness parameter generated by the authentication platform and used to bind the current authentication session. For example, this authentication session challenge information includes a random challenge value, a session identifier, and an authentication policy identifier.

[0123] When the authentication triggering conditions are met, the authentication platform generates authentication session challenge information specific to this session and sends it to the power terminal and communication access device respectively, thereby triggering the power terminal side and the network access side to generate corresponding authentication certificates in parallel.

[0124] Step 402: Upon being triggered by the authentication session challenge information, the power terminal uploads the terminal-side joint authentication certificate to the authentication platform.

[0125] Among them, the terminal-side joint authentication proof is a cryptographic proof message related to the current authentication session generated by the power terminal from the perspective of the power terminal under the triggering of authentication session challenge information.

[0126] After receiving the authentication session challenge information, the power terminal collects a snapshot of its current local state, which includes cellular identity information. It calculates a joint binding digest, performs a signature operation within the hardware trusted root environment, and generates a terminal-side joint authentication certificate. This certificate is used to report trusted evidence at the terminal's own level to the authentication platform. After generating the terminal-side joint authentication certificate, the power terminal reports it to the authentication platform.

[0127] For example, the process of a power terminal collecting a snapshot of its current local state includes: (1) At least the following information is obtained through the hardware root of trust: the device identity (ID_DEV) of the power terminal, the reference information of the device certificate (CERT_REF), the anti-rollback count (CTR), and the trusted boot record.

[0128] (2) Calculate or read the operating system trust metric (M_TRUST), and at least check the bootloader, system kernel, authentication service and communication driver of cellular communication module.

[0129] (3) Read at least the following through the trusted cellular driver: the cellular communication module identity (ID_MOD), module firmware version, module change count (C_MOD), current cellular registration status, cellular access session marker, and whether the user identification module exists.

[0130] (4) Read the user identification module identity (ID_SIM) of the power terminal.

[0131] The power terminal collects the aforementioned identity information and operating status within a preset short time window, noting the type, length, source, collection time, snapshot number, and version for each data item to prevent the platform from mistakenly combining different fields. During the collection process, if a system update, driver change, cellular communication module reset, module identity change, or user identification module hot-plugging is detected, the status change latch flag F_EVT is set to 1. Only if F_EVT remains 0 at the end of the collection is the status snapshot marked as valid. If F_EVT is set to 1 during the collection process, the entire status snapshot is invalidated, and no partial fields are allowed to be retained. After the status stabilizes, F_EVT is reinitialized and the data is collected again to avoid generating mixed states that have never actually existed simultaneously.

[0132] For example, after calculating the federated binding digest based on the state snapshot, a terminal-side federated authentication certificate is generated, denoted as PROOF. The formula for PROOF is as follows:

[0133]

[0134] Wherein, ID_DEV is the device identity of the power terminal; ID_OS is the operating system instance or trusted runtime environment identity; M_TRUST is the operating system trust metric of the power terminal; ID_MOD is the cellular communication module identity of the power terminal; ID_SIM is the user identification module identity of the power terminal; SNAP is the state snapshot number; SID is the authentication session identifier; N is the one-time random challenge value for this authentication; T is the challenge time information; CTR is the anti-rollback count; POLICY_ID is the authentication policy identifier for this authentication; B is the combined binding digest; ALG_ID is the signature algorithm identifier; KEY_ID is the authentication private key identifier used for this authentication; CERT_REF is the reference information of the corresponding device certificate; and SIG is the digital signature generated by the hardware root of trust.

[0135] For example, if the digital signature generated by the hardware root of trust is denoted as SIG, then the formula for SIG is as follows: SIG = Sign(SK_ROOT, B ∥ ALG_ID ∥ KEY_ID ∥ CERT_REF) Wherein, Sign is the digital signature function; SK_ROOT is the authentication private key stored inside the security chip or trusted execution environment; B is the combined binding digest; ALG_ID is the signature algorithm identifier; KEY_ID is the authentication private key identifier used this time; and CERT_REF is the reference information of the corresponding device certificate.

[0136] Step 403: Upon being triggered by the authentication session challenge information, the communication access device uploads the network access side certificate to the authentication platform.

[0137] Among them, network access side proof is a cryptographic proof message related to the current authentication session generated by the communication access device from the perspective of the communication access device when triggered by authentication session challenge information.

[0138] After receiving the authentication session challenge information, the communication access device collects the actual cellular identity information of the power terminal from the network access side corresponding to the communication access device, and encapsulates it to generate a network access side certificate. The network access side certificate is protected by the communication access device's own cryptographic key, represents the real access identity observed by the network access layer, and provides third-party corroboration evidence independent of the power terminal. The communication access device then reports the network access side certificate to the authentication platform.

[0139] For example, if we denote the network access side proof as ACCESS_PROOF, then the formula for ACCESS_PROOF is as follows: ACCESS_PROOF = Sign(SK_NET, SID ∥ N ∥ ID_SIM_NET ∥ ID_MOD_NET ∥SESSION_NET ∥ T_NET) Wherein, Sign is the digital signature function; SK_NET is the digital signature private key used by the communication access device to generate the network access side certificate; SID is the authentication session identifier, used to identify the authentication session to which it belongs; N is the random challenge value, a random number generated by the authentication platform for this authentication session and sent to the communication access device, used to identify that the network access side certificate is newly generated for this authentication; ID_SIM_NET is the user identification module identity on the network access side, which is the user identification module identity actually identified by the cellular network; ID_MOD_NET is the cellular communication module identity on the network access side, which is the access attribute identity related to the communication module that the cellular network can obtain; SESSION_NET is the cellular access session marker on the network access side, identifying the current real cellular access connection of the power terminal, used to prove that the user identification module identity, cellular communication module identity and this cellular connection correspond; T_NET is the proof time on the network access side, identifying the time when the above network side information was collected or the network access side certificate was generated, used to determine whether the network access side certificate is fresh or expired.

[0140] Step 404: The authentication platform receives the joint authentication certificate from the power terminal and the network access certificate from the communication access device.

[0141] The authentication platform receives a terminal-side joint authentication certificate from a power terminal and a network access-side certificate from a communication access device. Since the two certificates belong to the same authentication session, the terminal-side joint authentication certificate and the network access-side certificate can be associated and matched.

[0142] Step 405: The authentication platform verifies the joint authentication certificate on the terminal side in conjunction with the network access side certificate, and obtains the verification result.

[0143] When verifying the joint authentication certificate on the terminal side, the authentication platform combines the network access side certificate to verify the relevant information about cellular access in the joint authentication certificate on the terminal side, and obtains the overall verification result.

[0144] In one possible implementation, step 405 includes: (1) Obtain the first cellular identity information indicated by the network access side certificate and the second cellular identity information indicated by the terminal side joint authentication certificate.

[0145] The authentication platform parses the network access side certificate and extracts the first cellular identity information actually observed by the network access side; at the same time, it parses the terminal side joint authentication certificate and extracts the second cellular identity information reported by the power terminal itself, thus obtaining two sets of cellular identity information to be compared.

[0146] For example, cellular identity information includes: the cellular communication module identity of the power terminal and the user identification module identity of the power terminal.

[0147] (2) Verify the consistency between the first cellular identity information and the second cellular identity information to obtain the verification result.

[0148] If the first cellular identity information matches the second cellular identity information, it means that the cellular identity reported by the power terminal matches the real access identity observed by the network access side, and the cellular identity dimension verification passes; if the two do not match, it means that the power terminal has a risk of identity fraud, which directly affects the verification result of the overall trust status.

[0149] In this implementation, by extracting the first cellular identity information objectively carried by the network access side certificate and the second cellular identity information reported by the terminal side joint authentication certificate, the authenticity of the terminal access identity is verified by relying on the objective third-party perspective of the communication access device, ensuring the uniqueness and authenticity of the power terminal access identity, eliminating the security risks of illegal terminal impersonation and network access from the source of network access, and further improving the reliability of power terminal authentication.

[0150] It is understandable that, in addition to cellular identity consistency verification, when verifying the joint authentication certificate on the terminal side, the authentication platform can also combine information such as the joint binding summary in the joint authentication certificate on the terminal side to complete the verification of other dimensions and comprehensively output the trusted status verification result of the power terminal corresponding to this authentication session.

[0151] For example, if the terminal-side joint authentication proof is PROOF as mentioned above, then the verification of the remaining dimensions is as follows: (1) Parse the PROOF, check its field integrity, data format, protocol version and authentication policy identifier, and confirm that the device certificate is valid and has not been revoked, and obtain the verification public key corresponding to the registered power terminal.

[0152] (2) The authentication platform recalculates the combined binding digest B according to the same field encoding order and calculation rules as the power terminal, based on the device identity ID_DEV, operating system trust metric M_TRUST, cellular communication module identity ID_MOD, user identification module identity ID_SIM, status snapshot number SNAP, authentication session identifier SID, anti-rollback count CTR, and authentication policy identifier POLICY_ID in the PROOF; confirms that the recalculated combined binding digest is consistent with the combined binding digest carried in the PROOF, and uses the signature verification public key to verify the digital signature SIG to determine whether the PROOF is generated by the hardware trust root of the power terminal and whether the relevant fields are covered by the same digital signature.

[0153] (3) Query the corresponding authentication challenge record according to the authentication session identifier SID, confirm that the proof generation time corresponding to the random challenge value N and the challenge time information T and the authentication policy corresponding to the authentication policy identifier POLICY_ID both belong to this authentication, and confirm that the random challenge value N has not been used and has not exceeded the allowed time window, so as to prevent the old authentication proof from being reused.

[0154] (4) Compare the rollback count CTR in PROOF with the historical rollback count saved by the authentication platform to confirm that the current rollback count has not decreased, and determine whether its change is in line with the terminal startup, system upgrade or recovery process, so as to prevent the terminal from falling back to an old system, old firmware or old running state with security risks.

[0155] (5) Determine the trusted baseline, compare the current operating system trusted measurement M_TRUST with the trusted baseline, and confirm that the software, communication driver and authentication service currently running on the power terminal are in a legal state recognized by the authentication platform.

[0156] (6) Verify whether the device identity ID_DEV, cellular communication module identity ID_MOD and user identification module identity ID_SIM conform to the combination relationship pre-registered by the authentication platform; at the same time verify whether the cellular identity information (ID_MOD, ID_SIM) on the power terminal side is obtained and generated by the cellular communication driver, trusted execution environment or hardware trusted root in the trusted baseline state.

[0157] In summary, the method provided in this embodiment synchronously sends authentication session challenge information to the power terminal and the communication access device through the authentication platform. This triggers the power terminal to generate a joint authentication certificate and the communication access device to generate a network access certificate. Two independent authentication certificates are formed from the perspectives of the terminal itself and the network access. The authentication platform cross-verifies the terminal-side certificate by combining the network access certificate with the terminal-side certificate. It no longer solely trusts the identity and status data reported by the power terminal, effectively avoiding the authentication risks caused by the power terminal unilaterally forging its identity, tampering with access information, or falsely reporting its status.

[0158] In one possible implementation, in conjunction with the reference Figure 5 The following steps are also performed: Step 501: Within the validity period of the short-cycle trusted token, the business platform generates a control instruction summary for the risk control instructions to be executed.

[0159] Among them, the control instruction digest is the digest value obtained by performing a cryptographic digest operation on the risk control instruction to be executed.

[0160] Risk control instructions are operational instructions that pose a risk to the operational safety of the power system. Examples of risk control instructions include those instructing remote parameter modification, remote closing / opening of circuit breakers, and firmware updates. If such instructions are tampered with or forged, they will directly threaten the operational safety of the power system.

[0161] When a business platform initiates a risk control instruction, it first performs a cryptographic digest operation on the risk control instruction to obtain a unique corresponding control instruction digest. The control instruction digest represents the risk control instruction to be executed, thus preventing the complete plaintext instruction from being tampered with during transmission across multiple platforms.

[0162] For example, if the control instruction digest is denoted as CMD_HASH, then the formula for CMD_HASH is as follows: CMD_HASH = H(CMD_TYPE ∥TARGET_ID ∥CMD_PARAM ∥CMD_SEQ ∥ T_EXEC) Wherein, H is a cryptographic hash function used to calculate a fixed-length digest for each field; CMD_TYPE is the risk control instruction type, used to indicate the category of this operation, such as switch opening, switch closing, parameter writing, control mode switching, program upgrade, or equipment reset; TARGET_ID is the target object identifier, used to uniquely identify the control object on which the instruction actually acts, which may include at least one of the following: equipment identifier, bay identifier, switch identifier, circuit identifier, or controlled resource identifier of the power terminal, to prevent incorrect application of the control object; CMD_PARAM is the instruction parameter set, used to indicate the specific parameters required to complete the risk control instruction; CMD_SEQ The instruction sequence number is generated by the instruction issuer for each risk control instruction. It is used to distinguish instructions with the same content but different issuance times, and to detect duplicate execution, out-of-order execution, and replay attacks. This instruction sequence number should be unique within the corresponding terminal or business session, preferably using a monotonically increasing value or a globally unique value; T_EXEC is the instruction execution time constraint, which specifies the allowed execution time of the instruction. It can represent the planned execution time, the earliest allowed execution time, the latest execution time, or an effective time window consisting of start and end times.

[0163] Step 502: The business platform sends a control instruction digest to the authentication platform.

[0164] The business platform sends the generated control instruction summary to the authentication platform, requesting the authentication platform to generate an authorization certificate for the risk control instruction, thereby entrusting the authorization authority for high-risk operations to the authentication platform for unified management.

[0165] Step 503: The authentication platform receives the control instruction digest sent by the business platform.

[0166] Step 504: The authentication platform generates a one-time control micro-token carrying a digest of the control instructions.

[0167] Among them, the one-time control micro token is a one-time authorization credential for power business that is used for risk control instructions.

[0168] For example, if a one-time control micro-token is denoted as CTL_TOKEN, then the formula for CTL_TOKEN can be as follows: CTL_TOKEN = Sign(SK_PLATFORM, ID_DEV ∥ B_CUR ∥ CMD_HASH ∥ N_CTL ∥T_EXP ∥ POLICY_ID) Wherein, Sign is the digital signature function; SK_PLATFORM is the digital signature private key used by the authentication platform to issue one-time control micro-tokens; ID_DEV is the device identity of the power terminal; B_CUR is the real-time calculated combined binding digest; CMD_HASH is the control command digest; N_CTL is the one-time random challenge value; T_EXP is the expiration time of the one-time control micro-token; and POLICY_ID is the authentication policy identifier for this authentication.

[0169] It is understandable that one-time control micro-tokens differ from the short-term trusted tokens mentioned above in at least the following ways: Short-term trusted tokens serve as access credentials for a business session over a limited period and do not directly authorize specific control commands; one-time control micro-tokens are bound to specific risk control commands, allowing only single use and cannot be reused for other control commands. Furthermore, the validity period of a one-time control micro-token is shorter than that of a short-term trusted token, and it can only be used once.

[0170] Step 505: The authentication platform sends a one-time control micro-token to the power terminal.

[0171] The authentication platform will issue the generated one-time control micro-token to the power terminal as the authorization credential for executing this risk control instruction.

[0172] Step 506: The power terminal receives a one-time control micro-token.

[0173] Step 507: The power terminal verifies the one-time control micro-token and executes the risk control instruction if the verification is successful.

[0174] Within a trusted hardware environment, the power terminal completes verification of multiple checks on the one-time control micro-token. If all checks pass, the power terminal is allowed to execute the corresponding risk control command; if any check fails, the command is refused. Furthermore, in the event of a verification failure, the power terminal can report the anomaly to the authentication platform to prevent forged, reused, or tampered risk control commands from being executed.

[0175] For example, the verification work for multiple verification items of a one-time control micro token may include at least one of the following: (1) The signature of the authentication platform is valid.

[0176] (2) The device identity ID_DEV and combined binding digest B_CUR of the power terminal bound to the micro token are consistent with the current state of the power terminal.

[0177] (3) The same control instruction digest CMD_HASH is obtained after the power terminal is recalculated.

[0178] (4) Random challenge value N_CTL is not used.

[0179] (5) Verify that the one-time control micro token has not expired based on the expiration time T_EXP.

[0180] (6) The current trust level of the power terminal still allows the execution of this risk control instruction.

[0181] For example, after successful verification, the power terminal atomically marks N_CTL as occupied, then executes the risk control command and records the result. Even if the risk control command fails to execute, the record of N_CTL usage should be retained to prevent the same command from being repeatedly triggered by an attacker.

[0182] In summary, the method provided in this embodiment, based on short-cycle trusted tokens, further introduces a one-time control micro-token authorization mechanism for risk control instructions. The business platform performs cryptographic digest operations on the risk control instructions to be executed to obtain a control instruction digest. The authentication platform generates a one-time control micro-token bound to the specific risk control instruction based on the digest, and then issues it to the power terminal as an authorization credential for instruction execution. The power terminal needs to verify the one-time control micro-token before it can execute the risk control instruction. Through the one-time control micro-token, a fine-grained secondary authorization protection is added to the risk control instructions with high risk in power business. Even if the short-cycle trusted token is leaked, attackers cannot use the leaked short-cycle trusted token to launch high-risk operations such as illegal remote control or parameter modification, thus ensuring the security management requirements of high-risk business.

[0183] The above technical solution will be illustrated below with an example: S101: The power terminal sends authentication application information to the authentication platform.

[0184] For example, the authentication application information carries the device identity (ID_DEV) of the power terminal.

[0185] S102: The authentication platform sends authentication session challenge information to the power terminal and the communication access equipment respectively.

[0186] S103: The power terminal creates a status snapshot (SNAP), clears the status change latch flag (F_EVT) to zero, and performs multi-dimensional information collection within the same time window.

[0187] For example, the information collected includes: device identity, operating system trust metrics, cellular communication module identity, user identification module identity, module change count, anti-rollback count, and cellular access session markers.

[0188] S104: If the terminal state changes during information collection, set F_EVT and invalidate the entire SNAP; collect again after the state stabilizes.

[0189] S105: Based on the collected information, the power terminal calculates the joint binding digest B according to a fixed format, forms the joint authentication certificate PROOF on the terminal side by signing with the security chip, and uploads the PROOF to the authentication platform.

[0190] S106: The communication access device generates a network access side certificate ACCESS_PROOF and uploads the ACCESS_PROOF to the authentication platform.

[0191] S107: The authentication platform uses ACCESS_PROOF to verify PROOF.

[0192] For example, the verification of PROOF includes: verifying the signature, freshness, trusted baseline, registration relationship of device identity - cellular communication module identity - user identification module identity, anti-rollback count, and further combining ACCESS_PROOF to complete the same session consistency verification between the terminal side and the network access side.

[0193] S108: After the authentication platform verifies the information, it issues a short-term trusted token (TOKEN) associated with B, specifying the trust level and the permitted permissions for power services.

[0194] S109: The power terminal operates within the limits permitted by the TOKEN and its status is continuously monitored.

[0195] S110: After the power terminal detects a change in the terminal status, it freezes the TOKEN, re-collects B, generates a status continuity certificate, CONT_PROOF, and uploads CONT_PROOF to the authentication platform.

[0196] For example, CONT_PROOF is generated by signing the state data (joint binding digest, anti-rollback count, and module change count) of the two rounds, the event type, and the new random challenge value.

[0197] S111: The authentication platform determines the handling method for the TOKEN based on CONT_PROOF.

[0198] S112: When the business platform is preparing to execute the risk control instruction, it calculates the control instruction digest CMD_HASH. The authentication platform issues a one-time control micro token CTL_TOKEN to the power terminal based on CMD_HASH.

[0199] S113: After the power terminal verifies that the CTL_TOKEN has been used, it executes a risk control instruction once after atomically marking that the CTL_TOKEN has been used; risk control instructions that are duplicated, modified, expired, or inconsistent in status are all rejected.

[0200] Based on the above technical solutions, the authentication system will execute the following process in different scenarios: Scenario 1: Normal power-on authentication.

[0201] After the power terminal is powered on, it first checks the boot program, system kernel, authentication service, and cellular communication module driver to form an operating system trust measure. After the authentication platform issues a one-time random challenge value, the terminal reads information such as device identity, cellular communication module identity, and user identification module identity within the same snapshot. Combining this with the aforementioned operating system trust measure, a joint binding digest is generated, which is then signed by the security chip to generate a joint authentication certificate on the terminal side. After the authentication platform verifies that the verification is successful, it issues a short-term trusted token of the third trust level, allowing telemetry, alarms, parameter settings, and authorized remote control.

[0202] Scenario 2: The user identification module is replaced.

[0203] When the power terminal detects that the user identification module has been removed or replaced, and finds that the current user identification module identity is inconsistent with the historical token binding status, it immediately freezes the original token and uploads proof of status continuity. After verifying the proof of status continuity, the authentication platform downgrades the power terminal to a restricted state (first level of trust). After maintenance personnel confirm the replacement is legitimate, a new user identification module binding can be established, followed by a complete re-authentication. This prevents unauthorized remote control after user identification module replacement while ensuring the power terminal does not completely lose its alarm capabilities.

[0204] Scenario 3: Normal reset of cellular communication module.

[0205] When a cellular communication module experiences a normal reset due to a network anomaly, the power terminal freezes the original token and uploads a certificate of state continuity. Once the authentication platform verifies the certificate of state continuity, it performs rapid re-authentication and reissues the token, thus preventing a normal reset from being mistakenly identified as module replacement.

[0206] Scenario 4: The cellular communication module driver is abnormally modified.

[0207] Periodic checks revealed that the digital fingerprint of the cellular communication module driver was inconsistent with the standard fingerprint. Since the driver responsible for reading the user identification module's identity was no longer trustworthy, even if the read identity appeared normal, the authentication platform could not continue to trust it. The authentication platform determined that the operating system's trust metric did not belong to the trust baseline, and therefore revoked the token and entered the zero trust level isolation, while retaining logs for auditing.

[0208] Scenario 5: Legitimate operating system upgrade.

[0209] After confirming the legitimate source of the upgrade package, the power terminal installs the new version, freezes the original token, and uploads proof of status continuity. Once the authentication platform confirms that the status has continuously evolved from the old legitimate baseline to the new legitimate baseline, it first issues a short-cycle trusted token of the second trust level. After stable operation meets the conditions, it reverts to the third trust level.

[0210] Scenario 6: Replay and identity splicing attacks.

[0211] When the attacker resends the previously intercepted authentication proof, the authentication platform rejects it because the random challenge value has been used or the authentication has timed out. Similarly, when the attacker combines the device identity of one power terminal with the identity of another cellular communication module or user identification module, the calculated combined binding digest does not match the original signature, and verification also fails.

[0212] Scenario 7: Cross-verification of the same session from the source of cellular identity.

[0213] After the authentication platform issues the authentication session challenge information, the power terminal generates a joint authentication certificate on the terminal side, and the communication access device generates a network access side certificate. The platform only recognizes the cellular identity source after verifying that both certificates originate from the same session and that the identity mapping is consistent. If an attacker only forges the cellular identity on the terminal side, they cannot simultaneously generate a matching network access side certificate.

[0214] Scenario 8: The distinction between module replacement and normal reset.

[0215] An attacker replaces the original cellular communication module with another module and attempts to report a "module reset" event in the state continuity certificate. The authentication platform verifies that the identity of the cellular communication module in the state continuity certificate has changed, and the change does not match the increasing relationship of the module change count. Although the attacker can declare the event type as reset, the state continuity certificate generated by the power terminal will simultaneously overwrite the actual federated binding digest and count. Based on this, the authentication platform judges it as identity replacement, revokes the original token, and enters restricted rebinding, instead of performing fast reauthentication.

[0216] Scenario 9: One-time control micro-token for remote closing command.

[0217] The business platform prepares to issue a closing command to a designated switch, first calculating the control instruction digest corresponding to the closing command. After the authentication platform confirms the validity of the power terminal's current joint binding digest and short-cycle trusted token, it issues a one-time control micro-token with a validity period of 10 seconds. The power terminal verifies that its current state matches the control instruction digest in the one-time control micro-token, atomically marks the random challenge value N_CTL in the one-time control micro-token as used, and then performs a closing operation. If an attacker modifies the target switch, changes parameters, or resends the same message, the control instruction digest or N_CTL verification fails, and the power terminal refuses to execute.

[0218] Figure 6 This is a structural block diagram illustrating an authentication processing apparatus for a power terminal according to an exemplary embodiment. (Refer to...) Figure 6 The device may include: The trusted verification module 610 is used to verify the trusted status of the power terminal and obtain the verification result; The token issuance module 620 is used to issue a short-period trusted token to the power terminal when the verification result is successful. The short-period trusted token is an access credential for power services with a validity period shorter than a preset duration. The proof receiving module 630 is used to receive the state continuity proof sent by the power terminal. The state continuity proof is sent by the power terminal within the validity period of the short-cycle trusted token when a change in the terminal state is detected. The state continuity proof is a cryptographic proof message with the evolution relationship between the trusted states of the power terminal in two consecutive rounds. The generation of the state continuity proof includes at least the following data: first state data and second state data. The first state data represents the historical state data of the previous round when the trusted state was verified, which is locally retained by the power terminal. The second state data represents the current state data collected by the power terminal in real time after the terminal state changes. The token handling module 640 is used to determine the handling method for the short-period trusted token based on the state continuity proof.

[0219] In one possible implementation, the generation of the state continuity proof further includes the following data: the event type corresponding to the terminal state change and the random challenge value issued by the authentication platform; The token processing module 640 includes: The proof parsing unit is used to parse the state continuity proof to obtain the first state data, the second state data, the event type, and the random challenge value; The validity verification unit is used to verify the validity of the first state data, the second state data, and the random challenge value, respectively. The change event identification unit is used to identify change events of the terminal state change based on the first state data and the second state data when the validity verification of the first state data, the second state data and the random challenge value is passed, and to compare the identified change events of the terminal state change with the event type for consistency. The token processing unit is used to determine the processing method for the short-cycle trusted token based on the change event of the terminal state change, provided that the consistency comparison between the change event and the event type passes.

[0220] In one possible implementation, the data types in the first state data and the second state data include: joint binding digest, anti-rollback count, and module change count. The joint binding digest is a comprehensive fingerprint calculated by combining the device identity of the power terminal, the operating system trust measure of the power terminal, the cellular communication module identity of the power terminal, and the user identification module identity of the power terminal. The change event identification unit is further configured to compare the joint binding digest in the first state data with the joint binding digest in the second state data to obtain the device identity change, operating system trust metric change, cellular communication module identity change, and user identification module identity change; perform difference calculations on the anti-rollback count and module change count of the first state data with the anti-rollback count and module change count of the second state data to obtain the anti-rollback count change value and module change count change value; and identify the change events of the terminal state change based on the change identification information, wherein the change identification information includes: the device identity change, the operating system trust metric change, the cellular communication module identity change, the user identification module identity change, the anti-rollback count change value, and the module change count change value; wherein the change events of the terminal state change include: cellular communication module reset, operating system upgrade, cellular communication module replacement, and user identification module replacement.

[0221] In one possible implementation, the short-cycle trusted token has a trust level, which includes: a third trust level, a second trust level, a first trust level, and a zero trust level, and the permissions of the power services corresponding to the third trust level to the zero trust level are sorted from high to low. The token processing unit is further configured to: if the change event is a reset of the cellular communication module, continue to issue the short-term trusted token with the current trusted level to the power terminal, or reissue another short-term trusted token of the second trusted level to the power terminal; if the change event is an upgrade of the operating system, reissue another short-term trusted token of the second trusted level to the power terminal; if the change event is a replacement of the cellular communication module or a replacement of the user identification module, reissue another short-term trusted token of the first trusted level to the power terminal.

[0222] In one possible implementation, the token processing unit is further configured to reissue another short-cycle trusted token of the zero trust level to the power terminal if the consistency comparison between the change event and the event type fails; or, if the operating system trust metric in the second state data does not belong to the trusted baseline, reissue another short-cycle trusted token of the zero trust level to the power terminal.

[0223] In one possible implementation, the validity verification unit is further configured to verify the validity of the parsed random challenge value based on the locally retained random challenge value; verify the validity of the first state data based on the locally retained historical data, wherein the historical data represents the historical data of the previous round of trusted state verification on the authentication platform; and verify the validity of the second state data based on the currently collected state snapshot.

[0224] In one possible implementation, the trusted verification module 610 includes: The challenge information sending unit is used to send authentication session challenge information to the power terminal and the communication access device respectively; The proof receiving unit is used to receive the terminal-side joint authentication proof fed back by the power terminal and the network access-side proof fed back by the communication access device. The terminal-side joint authentication proof is a cryptographic proof message related to the current authentication session generated by the power terminal from the perspective of the power terminal under the triggering of the authentication session challenge information. The network access-side proof is a cryptographic proof message related to the current authentication session generated by the communication access device from the perspective of the communication access device under the triggering of the authentication session challenge information. The joint verification unit is used to verify the joint authentication certificate on the terminal side in conjunction with the network access side certificate, and obtain the verification result.

[0225] In one possible implementation, the joint verification unit is further configured to obtain the first cellular identity information indicated by the network access side certificate and the second cellular identity information indicated by the terminal side joint authentication certificate; verify the consistency between the first cellular identity information and the second cellular identity information to obtain the verification result.

[0226] In one possible implementation, the device further includes: The control instruction digest receiving module is used to receive control instruction digests sent by the business platform. The control instruction digest is a digest value obtained by the business platform performing cryptographic digest operations on a risk control instruction to be executed within the validity period of the short-cycle trusted token. The micro-token generation module is used to generate a one-time control micro-token carrying the digest of the control instruction. The one-time control micro-token is a one-time authorization credential for power services for the risk control instruction. The micro-token sending module is used to send the one-time control micro-token to the power terminal. The one-time control micro-token is used for verification by the power terminal, and if the verification is successful, the risk control command is executed.

[0227] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0228] Figure 7 This is a structural block diagram illustrating an authentication processing apparatus for a power terminal according to an exemplary embodiment. (Refer to...) Figure 7 The device may include: The token receiving module 710 is used to receive a short-period trusted token issued by the authentication platform. The short-period trusted token is issued by the authentication platform after verifying the trusted status of the power terminal. The short-period trusted token is an access credential for power services with a validity period shorter than a preset time. The proof generation module 720 is used to generate a state continuity proof by combining the first state data and the current second state data when a change in the terminal state is detected during the validity period of the short-cycle trusted token. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The proof sending module 730 is used to send the state continuity proof to the authentication platform, the state continuity proof being used by the authentication platform to determine the disposal method for the short-period trusted token.

[0229] In one possible implementation, the proof generation module 720 includes: The information acquisition unit is used to acquire the event type corresponding to the change in the terminal state and to receive the random challenge value issued by the authentication platform. The proof generation unit is used to use a local hardware private key to concatenate and sign the first state data, the second state data, the event type, and the random challenge value to generate the state continuity proof.

[0230] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0231] In an exemplary embodiment, an electronic device is also provided, comprising a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the method described in the embodiments of this application. This electronic device may specifically be any one of the aforementioned power terminal, service platform, authentication platform, and communication access device.

[0232] Furthermore, Figure 8 A schematic diagram of a hardware structure for implementing the electronic device provided in the embodiments of this application is shown. The electronic device can participate in or include the authentication processing device of the power terminal provided in the embodiments of this application. Figure 8 As shown, the electronic device 100 may include one or more processors 802 (shown as 802a, 802b, ..., 802n in the figure) 802 (processor 802 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 804 for storing data, and a transmission device 806 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 8 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device 100 described above. For example, the electronic device 100 may also include components that are more... Figure 8 The more or fewer components shown, or having the same Figure 8 The different configurations shown.

[0233] It should be noted that the authentication processing circuitry of one or more processors 802 and / or other power terminals described above may generally be referred to herein as "power terminal authentication processing circuitry". This power terminal authentication processing circuitry may be implemented wholly or partially as software, hardware, firmware, or any other combination thereof. Furthermore, the power terminal authentication processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element in the electronic device 100. As involved in the embodiments of this application, the power terminal authentication processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor terminal path connected to an interface).

[0234] The memory 804 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the power terminal authentication processing method described in this embodiment. The processor 802 executes various functional applications and data processing by running the software programs and modules stored in the memory 804, thereby realizing the aforementioned power terminal authentication processing method. The memory 804 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 804 may further include memory remotely located relative to the processor 802, and these remote memories can be connected to the electronic device 100 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0235] The transmission device 806 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 100. In one example, the transmission device 806 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one embodiment, the transmission device 806 may be a radio frequency (RF) module for wireless communication with the Internet.

[0236] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the electronic device 100.

[0237] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or at least one program being loaded and executed by a processor to implement the method described in the embodiments of this application.

[0238] In an exemplary embodiment, a computer program product is also provided, including computer instructions that, when executed by a processor, cause a computer to perform the methods described in the embodiments of this application.

[0239] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0240] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0241] It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for authentication processing of a power terminal, characterized in that, The method is applied to an authentication platform, and the method includes: The trusted status of the power terminal is verified, and the verification result is obtained; If the verification result is successful, a short-period trusted token is issued to the power terminal. The short-period trusted token is an access credential for power services with a validity period shorter than the preset duration. The system receives a state continuity certificate sent by the power terminal. The state continuity certificate is sent by the power terminal within the validity period of the short-cycle trusted token when a change in the terminal state is detected. The state continuity certificate is a cryptographic proof message that shows the evolution relationship between the trusted states of the power terminal in two consecutive rounds. The generation of the state continuity certificate includes at least the following data: first state data and second state data. The first state data represents the historical state data stored locally by the power terminal in the previous round when performing trusted state verification. The second state data represents the current state data collected by the power terminal in real time after the terminal state changes. Based on the state continuity proof, the means of handling the short-period trusted token are determined.

2. The method according to claim 1, characterized in that, The generation of the state continuity proof also includes the following data: the event type corresponding to the terminal state change, and the random challenge value issued by the authentication platform; The determination of the handling method for the short-period trusted token based on the state continuity proof includes: The state continuity proof is analyzed to obtain the first state data, the second state data, the event type, and the random challenge value; The validity of the first state data, the second state data, and the random challenge value are verified respectively. If the validity verification of the first state data, the second state data, and the random challenge value is passed, based on the first state data and the second state data, the change event of the terminal state change is identified, and the identified change event of the terminal state change is compared with the event type for consistency. If the consistency comparison between the change event and the event type passes, the handling method for the short-cycle trusted token is determined based on the change event of the terminal state change.

3. The method according to claim 2, characterized in that, The data types in the first state data and the second state data include: joint binding digest, anti-rollback count and module change count. The joint binding digest is a comprehensive fingerprint calculated by combining the device identity of the power terminal, the operating system trust measure of the power terminal, the cellular communication module identity of the power terminal and the user identification module identity of the power terminal. The step of identifying the change event of the terminal state change based on the first state data and the second state data includes: The joint binding digest in the first state data is compared with the joint binding digest in the second state data to obtain the device identity change status, operating system trust measurement change status, cellular communication module identity change status and user identification module identity change status. The rollback count and module change count of the first state data are compared with the rollback count and module change count of the second state data to obtain the rollback count change value and module change count change value. Based on the change identification information, the change events of the terminal status change are identified. The change identification information includes: the device identity change, the operating system trust measurement change, the cellular communication module identity change, the user identification module identity change, the anti-rollback count change value, and the module change count change value. The events that change the terminal state include: resetting the cellular communication module, upgrading the operating system, replacing the cellular communication module, and replacing the user identification module.

4. The method according to claim 2, characterized in that, The short-cycle trusted token has a trusted level, which includes: a third trusted level, a second trusted level, a first trusted level, and a zero trusted level. The permissions of the power services corresponding to the third trusted level to the zero trusted level are sorted from high to low. The method for handling the short-cycle trusted token based on the change event of the terminal state includes: If the change event is a reset of the cellular communication module, continue to issue the short-cycle trusted token to the power terminal with the current trusted level renewed, or reissue another short-cycle trusted token of the second trusted level to the power terminal. If the change event is an operating system upgrade, reissue another short-cycle trusted token of the second trusted level to the power terminal; If the change event is the replacement of a cellular communication module or a user identification module, a new short-cycle trusted token of the first trusted level is reissued to the power terminal.

5. The method according to claim 4, characterized in that, The method further includes: If the consistency comparison between the change event and the event type fails, another short-cycle trust token of the zero trust level is reissued to the power terminal. or, If the operating system trust metric in the second state data does not belong to the trust baseline, another short-cycle trust token of the zero trust level is reissued to the power terminal.

6. The method according to claim 2, characterized in that, The verification of the validity of the first state data, the second state data, and the random challenge value includes: The validity of the parsed random challenge value is verified based on the locally retained random challenge value; The validity of the first state data is verified based on the locally retained historical data, wherein the historical data represents the historical data of the previous round of trusted state verification on the authentication platform. The validity of the second state data is verified based on the currently collected state snapshot.

7. The method according to claim 1, characterized in that, The verification of the trusted state of the power terminal, and the resulting verification, includes: Send authentication session challenge information to the power terminal and the communication access device respectively; The system receives a terminal-side joint authentication certificate from the power terminal and a network access-side certificate from the communication access device. The terminal-side joint authentication certificate is a cryptographic proof message related to the current authentication session generated by the power terminal from its perspective under the triggering of the authentication session challenge information. The network access-side certificate is a cryptographic proof message related to the current authentication session generated by the communication access device from its perspective under the triggering of the authentication session challenge information. The terminal-side joint authentication certificate is verified in conjunction with the network access-side certificate to obtain the verification result.

8. The method according to claim 7, characterized in that, The verification of the terminal-side joint authentication certificate, combined with the network access-side certificate, to obtain the verification result includes: Obtain the first cellular identity information indicated by the network access side certificate and the second cellular identity information indicated by the terminal side joint authentication certificate; The consistency between the first cellular identity information and the second cellular identity information is verified to obtain the verification result.

9. The method according to claim 1, characterized in that, The method further includes: The system receives a control instruction digest sent by the business platform. The control instruction digest is a digest value obtained by the business platform performing a cryptographic digest operation on a risk control instruction to be executed within the validity period of the short-cycle trusted token. Generate a one-time control micro-token carrying a digest of the control instruction, the one-time control micro-token being a one-time authorization credential for power services for the risk control instruction; The one-time control micro-token is sent to the power terminal. The one-time control micro-token is used for verification by the power terminal, and if the verification is successful, the risk control instruction is executed.

10. A method for authentication processing of a power terminal, characterized in that, The method is applied to a power terminal, and the method includes: Receive a short-term trusted token issued by the authentication platform. The short-term trusted token is issued by the authentication platform after verifying the trusted status of the power terminal. The short-term trusted token is an access credential for power services with a validity period shorter than a preset time. Within the validity period of the short-cycle trusted token, when a change in the terminal state is detected, a state continuity proof is generated by combining the first state data and the current second state data. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The state continuity proof is sent to the authentication platform, and the state continuity proof is used by the authentication platform to determine the disposal method for the short-cycle trusted token.

11. The method according to claim 10, characterized in that, The step of combining the first state data and the current second state data to generate a proof of state continuity includes: Obtain the event type corresponding to the terminal state change, and receive the random challenge value issued by the authentication platform; Using the local hardware private key, the first state data, the second state data, the event type, and the random challenge value are concatenated and signed to generate the state continuity proof.

12. An authentication processing device for a power terminal, characterized in that, The device includes: The trusted verification module is used to verify the trusted status of the power terminal and obtain the verification result; The token issuance module is used to issue a short-period trusted token to the power terminal when the verification result is successful. The short-period trusted token is an access credential for power services with a validity period shorter than a preset duration. The proof receiving module is used to receive the state continuity proof sent by the power terminal. The state continuity proof is sent by the power terminal within the validity period of the short-cycle trusted token when a change in the terminal state is detected. The state continuity proof is a cryptographic proof message with the evolution relationship between the trusted states of the power terminal in two consecutive rounds. The generation of the state continuity proof includes at least the following data: first state data and second state data. The first state data represents the historical state data of the previous round when performing trusted state verification locally retained by the power terminal. The second state data represents the current state data collected by the power terminal in real time after the terminal state changes. The token handling module is used to determine the handling method for the short-cycle trusted token based on the state continuity proof.

13. An authentication processing device for a power terminal, characterized in that, The device includes: The token receiving module is used to receive short-period trusted tokens issued by the authentication platform. The short-period trusted tokens are issued by the authentication platform after the trusted status of the power terminal is verified. The short-period trusted tokens are access credentials for power services with a validity period shorter than a preset time. The proof generation module is used to generate a state continuity proof by combining the first state data and the current second state data when a change in the terminal state is detected during the validity period of the short-cycle trusted token. The first state data represents the historical state data of the previous round of trusted state verification stored locally by the power terminal, and the second state data represents the current state data collected in real time by the power terminal after the terminal state changes. The state continuity proof is a cryptographic proof message that has the evolution relationship between the trusted states of the power terminal in the previous and subsequent rounds. The proof sending module is used to send the state continuity proof to the authentication platform, and the state continuity proof is used by the authentication platform to determine the disposal method for the short-period trusted token.

14. An authentication platform, characterized in that, The authentication platform includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the authentication processing method for the power terminal as described in any one of claims 1-9.

15. A power terminal, characterized in that, The power terminal includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the authentication processing method of the power terminal as described in claim 10 or 11.

Images