Power transmission terminal multi-module key cooperative updating method

Abstract

The application discloses a power transmission terminal multi-module key cooperative updating method and belongs to the field of power system terminal communication security. In order to solve the problems of multi-module key version out of step, old key rollback, failed module diffusion and key and random number multiplexing under intermittent connection conditions, the application determines a target epoch and an access set through a module version state vector and a signature update list, derives an isolated working key from a terminal root secret hierarchical distribution, and atomically registers a persistent random number lease before encapsulation. In combination with an activation certificate, a state to be chased and an isolated recovery gate, old version fault ciphertext is isolated first, and then the current version is retransmitted and verified to be released. After the destruction of the return receipt is linked to the subsequent access, the technical effects of version monotonic synchronization, cross-module failure isolation, replay suppression and destructible state auditability are realized.

Description

Technical Field

[0001] This invention relates to the field of communication security for power system terminals, and in particular to a method for collaborative updating of keys for multiple modules in a power transmission terminal. Background Technology

[0002] Transmission terminals are typically configured with multiple communication modules targeting different communication networks or service channels. Each module may be in an online, dormant, weakly connected, or offline state. Existing unified key distribution methods usually rely on the arrival of the entire terminal as a condition for progress, or only record the terminal-level version, making it difficult to simultaneously express the current version, version to be activated, trust status, and destruction result of each module. When some modules fail to receive updates in a timely manner, problems such as missed updates, version inconsistencies, and non-critical offline modules blocking the overall terminal version progression can easily occur.

[0003] The existing key update process may also reallocate used random number ranges during restarts, update interruptions, or module recovery, causing the same working key and random number combination to be reused. For modules that have been revoked or identified as compromised, if the key derivation, preparation package distribution, and access recovery do not use a consistent exclusion scope, the current version key may be obtained again through the recovery path, expanding the impact of a single compromised module.

[0004] When an offline communication module reconnects, it often carries fault data encrypted with an older version key. If the coordinator directly uses the old working key to verify or decrypt, it may create rollback and replay entry points; if it directly rejects the connection, the fault record will be lost. Therefore, it is necessary to complete forward-only recovery, retransmission of the current version of the original fault record, replay and timeliness verification without enabling the old working key, and to implement access interlocking for the destruction results of historical keys and old leases. Summary of the Invention

[0005] One objective of this invention is to propose a collaborative key update method for multiple modules in a power transmission terminal. Addressing the problems of out-of-sync module key versions, old key rollback, compromised modules potentially bypassing the update scope, duplicate random number leases, and difficulty in securely recovering faulty data from older versions under intermittent connection conditions, this invention proposes a method that uses the module version state vector and digest chain signature update list to determine the target epoch, allowed set, revocation set, and current access set. Working keys are derived hierarchically from the terminal root secret within the security unit according to version, module, protocol domain, direction, and purpose. Random number leases are atomically persisted before encapsulating the key material, and a monotonic version is submitted through temporary proof and activation certificate. Old ciphertexts of catching-up modules are isolated first, and access and freshness verification are performed using independent equipment to restore credentials. Only the current version key and new lease are provided, allowing the module to retransmit the original local fault record and complete replay and timeliness verification. Finally, historical key and old lease destruction receipts are used to link subsequent access. This invention has the technical effects of version monotonically converging, cross-module key domain isolation, non-reuse of random numbers, controlled recovery of old fault data, and auditable destruction status.

[0006] This invention provides a method for collaborative updating of multi-module keys in a power transmission terminal, comprising:

[0007] S1. Obtain the connection status, version, and trust status of the communication module to form a module version status vector; verify the signature update list, determine the target epoch, and exclude or revoke the access set of the communication module.

[0008] S2. Align the modules within the set and derive mutually isolated module working keys from the terminal root secret of the security unit according to the target epoch and module identifier; after atomically registering and binding the module identifier and target epoch, and a random number lease with a starting point greater than the random number persistence level, encapsulate the working key and lease into a preparation packet;

[0009] S3. Generate an activation certificate based on the preparation package temporary proof of the connected modules and submit the target era as the current version accordingly, and monotonically increase the minimum acceptable version; non-critical offline modules enter the catch-up state;

[0010] S4. Before calling the working key, write the old version fault ciphertext and isolation metadata uploaded by the module to be caught up into the isolation queue; after confirming that the module is still in the admission set and has passed the freshness verification with independent device recovery credentials, register the new lease in the manner described in step S2, and send a recovery package that only points to the current version and contains the module working key and the new lease of that version; receive the local original fault record that is re-encrypted with the working key and the random number in the new lease, and generate a service release decision after matching with the isolation metadata, replay verification and timeliness verification.

[0011] S5. Based on the business release judgment and the historical key expiration and old lease burn authentication receipt returned by the module, update the destruction status and subsequent access status.

[0012] Optionally, S1 includes: recording for each communication module the module identifier, connection status, current version, version to be activated, minimum acceptable version, trust flag, update list summary, persistent random number watermark value, and destruction status;

[0013] Verify the continuity between the signature, the preceding digest, and the locally submitted digest of the signature update list;

[0014] When the continuity relationship verification is successful, the target version carried by the signature update list is used as the target epoch. The communication modules located in the allowed set and marked as trusted are determined as the admission set, and the communication modules located in the revocation set or marked as compromised are excluded from the admission set.

[0015] Furthermore, the connection status is determined by the security coordinator based on the link establishment event of the communication module, sleep notification, continuous transmission failure count, and the time of the most recent authentication communication;

[0016] The trust token includes at least three values: trusted, observed, and compromised. Communication modules with the observed value are restricted to receiving only status notifications and recovery challenges that do not contain the module working key and random number lease. Communication modules with the compromised value are added to the revocation set and do not obtain the module master key corresponding to the target epoch.

[0017] The key modules are determined by the set of key modules in the signature update list. An activation certificate is not generated if a key module does not return a verified temporary proof.

[0018] Optionally, S2 includes: deriving a terminal version key corresponding to the target epoch from the terminal root secret within the security unit, deriving a module master key using the terminal version key and the module identifier, and deriving the module working key from the module master key using the protocol domain, communication direction, and key purpose as domain separation tags;

[0019] In persistent storage, the lease identifier, module identifier, target epoch, protocol domain, communication direction, update list digest, lease start, lease end and lease status are written through the same atomic transaction, and the persistent watermark value of the random number is advanced to a value not less than the lease end. The module working key and random number lease are encapsulated only after the atomic transaction is committed.

[0020] The preparation packet is protected by the device recovery credentials of the corresponding communication module, so that the preparation packet can only be decapsulated by the corresponding communication module.

[0021] Furthermore, the key usage is characterized by a key usage identifier, the domain separation tag also includes the update list digest, and the key usage identifier at least distinguishes between data encryption, message authentication, and receipt authentication;

[0022] Different module identifiers, target epochs, protocol domains, communication directions, key usage identifiers, or update list digests correspond to different derived inputs;

[0023] When any communication module is determined to be a revoked communication module, the generation of new leases and new module working keys for that communication module is stopped. Within the same target epoch and the same update list digest, the module master keys and module working keys of other communication modules are not affected by the secret materials of the revoked communication module. When the target epoch changes, the module master keys of other communication modules are updated according to the changed derived inputs, and when the target epoch or update list digest changes, the module working keys of other communication modules are updated according to the changed derived inputs.

[0024] Optionally, S3 includes: designating communication modules located in the admission set and whose connection status is online or weak as preparation packet delivery targets, and marking non-critical communication modules whose connection status is dormant or offline as to be caught up;

[0025] The temporary proof includes the module identifier, target era, update list summary, lease identifier, and preparation result;

[0026] The activation certificate is generated when all temporary proofs corresponding to the key modules are verified and the activation time or activation event specified in the signature update list is reached.

[0027] The current version, minimum acceptable version, and update manifest summary are submitted using the activation certificate atomically. The pending versions of the switched communication modules are cleared, and the submission of the target epoch is not prevented because the non-critical communication modules are in a catch-up state.

[0028] Optionally, S4 includes: the isolation metadata includes at least a service identifier, content digest, source module identifier, reception time, old version number and isolation status, and after receiving the old version fault ciphertext, the module working key corresponding to the old version number is not called to authenticate the recovery request;

[0029] Send a recovery challenge containing a one-time challenge value and a summary of the current version status to the communication module in the catch-up state, verify that the communication module is still in the admission set, and use the device recovery credentials to verify the response returned by the communication module to the one-time challenge value;

[0030] After successful verification and submission of the atomic registration transaction for the new lease, a recovery package containing the current version, current update manifest digest, new lease, and current module working key is generated. A session protection key is derived using the device recovery credentials and the one-time challenge value. The recovery package is then authenticated and encrypted using the session protection key, and the module identifier, current version, current update manifest digest, and one-time challenge value are bound to it, ensuring that the version in the recovery package is not less than the minimum acceptable version.

[0031] Furthermore, a unique and unchanging service identifier is generated for each local original fault record within the source communication module. The re-encrypted local original fault record carries the service identifier, content summary, source module identifier, current version, lease identifier, lease-based random number, and local record time.

[0032] Based on the service identifier, content summary and source module identifier, locate the corresponding isolation metadata, merge duplicate isolation items with the same service identifier, content summary and source module identifier and retain the earliest reception time, compare the current version with the minimum acceptable version, and calculate the time interval obtained by subtracting the local record time corrected by the power transmission terminal clock from the earliest reception time.

[0033] When the current version is not less than the minimum acceptable version and the time interval is not less than zero and not greater than the fault data validity period specified in the signature update list, conditional insertion is performed using the lease identifier and the random number within the lease as the unique index. The unused judgment and the used occupied record are completed through the same atomic transaction. A business release judgment that allows release is generated only when the conditional insertion is successful. A business release judgment that refuses release is generated when a unique index conflict occurs.

[0034] Optionally, S5 includes: writing the module identifier, current version, set of destroyed historical key versions, set of burned old lease identifiers, destruction operation result and authentication value into the authentication receipt;

[0035] Verify the receipt authentication value and write the verified destruction operation result into the destruction status;

[0036] If the receipt is missing, the receipt authentication value fails to be verified, or the destruction operation result is incomplete, it is identified as an abnormal recovery branch. In the abnormal recovery branch, the subsequent service access status of the corresponding communication module is set to closed, and only the channel for re-execution of recovery based on the device recovery credentials is retained.

[0037] Furthermore, when the communication module restarts, resumes from an interruption, advances the target epoch, or is revoked, the remaining random number leases allocated to the corresponding communication module but not recorded as used are marked as permanently unallocable. The maximum value of the lease endpoint of all submitted or marked as permanently unallocable random number leases is compared with the current random number persistence level. The random number persistence level is monotonically advanced to a value not less than the maximum value of the lease endpoint. Then, the starting point of the next random number lease is persisted to a value greater than the advanced random number persistence level.

[0038] After the current version and minimum acceptable version are submitted, the module master key and module working key corresponding to the historical version in the security unit are deleted or made unusable, and the authentication receipt is used as an audit association record for the invalidation of historical keys, the burning of old random number leases and subsequent access status updates.

[0039] The beneficial effects of this invention are:

[0040] 1. By explicitly allowing and revoking sets in the signature update list, and combining them with the module version state vector to form an admission set before key derivation, non-critical offline modules are allowed to enter the catch-up phase without blocking the target epoch commit. At the same time, revoked or compromised modules are continuously excluded from the scope of new version key derivation and recovery package distribution, thereby reducing version out-of-sync caused by intermittent connections and limiting the propagation of single module compromise.

[0041] 2. By registering random number leases bound to the derived context with atomic transactions before the working key is encapsulated, and advancing the persistent water level to the lease end, unused margins are burned and the water level is repaired during restarts, recovery interruptions, epoch advances, or reversals, so that the starting point of subsequent leases keeps moving forward, thereby suppressing the reuse of random numbers in the same key context.

[0042] 3. By first entering the isolation queue with the old version of the fault ciphertext, independently authenticating the device recovery credentials, ensuring that the recovery package only points to the submitted version, re-encrypting the original fault record using the current key and the new lease, and verifying the unique conditions of random number occupancy, replay, and timeliness, the fault data is allowed to pass under controlled conditions without enabling the old working key, and the subsequent business access is closed by destroying the failure receipt to form an auditable security loophole. Attached Figure Description

[0043] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0044] Figure 1 This is a flowchart of the multi-module key collaborative update method for power transmission terminals according to the present invention.

[0045] Figure 2This is a flowchart of the S4 isolation recovery and verification release process of the present invention. Detailed Implementation

[0046] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0047] refer to Figures 1-2 A method for collaborative updating of keys for multiple modules in a power transmission terminal, comprising:

[0048] S1. Obtain the connection status, version, and trust status of the communication module to form a module version status vector; verify the signature update list, determine the target epoch, and exclude or revoke the access set of the communication module.

[0049] S2. Align the modules within the set and derive mutually isolated module working keys from the terminal root secret of the security unit according to the target epoch and module identifier; after atomically registering and binding the module identifier and target epoch, and a random number lease with a starting point greater than the random number persistence level, encapsulate the working key and lease into a preparation packet;

[0050] S3. Generate an activation certificate based on the preparation package temporary proof of the connected modules and submit the target era as the current version accordingly, and monotonically increase the minimum acceptable version; non-critical offline modules enter the catch-up state;

[0051] S4. Before calling the working key, write the old version fault ciphertext and isolation metadata uploaded by the module to be caught up into the isolation queue; after confirming that the module is still in the admission set and has passed the freshness verification with independent device recovery credentials, register the new lease in the manner described in step S2, and send a recovery package that only points to the current version and contains the module working key and the new lease of that version; receive the local original fault record that is re-encrypted with the working key and the random number in the new lease, and generate a service release decision after matching with the isolation metadata, replay verification and timeliness verification.

[0052] S5. Based on the business release judgment and the historical key expiration and old lease burn authentication receipt returned by the module, update the destruction status and subsequent access status.

[0053] In this specific embodiment, S1 includes:

[0054] This specific implementation sets up a safety coordinator, a safety unit, and three communication modules—cellular, public network leased line, and low-power wide area network—within a power transmission line monitoring terminal. The safety coordinator uses the module identifier, which is written at the factory and cannot be repeated, as an index. It maintains the connection status, current version, version to be activated, minimum acceptable version, trust flag, summary of submitted update list, persistent random number level, destruction status, last authentication communication time, and consecutive transmission failure count in a version status table protected against power loss. Each record in the status table carries a record version number and a cyclic redundancy check value. The terminal reads the complete record after restarting by submitting a double copy of the pre-write log and the master record.

[0055] The security coordinator receives link establishment events, link disconnection events, sleep notifications, and authentication communication completion events every 5 seconds. Link establishment and link disconnection events are only used to update the persistent link establishment flag. When the link is established, the continuous transmission failure count is 0, and the most recent authentication communication is no more than 30 seconds from the current time, it is recorded as online. When the link is established and the continuous transmission failure count is 1 to 3, or the most recent authentication communication is more than 30 seconds but no more than 120 seconds from the current time, it is recorded as weak connection. When a sleep notification is received and the expected end time of sleep has been registered, it is recorded as sleep. When the link is not established, the continuous transmission failure count is greater than 3, or the most recent authentication communication is more than 120 seconds from the current time, it is recorded as offline. When there are conflicting conditions, the offline, sleep, weak connection, and online states are written in a more conservative order. If the link flag, failure count, or authentication time is missing, out of bounds, or cannot be compared, causing all the above conditions to be missed, it will fall back to offline, and the determination time and trigger event sequence number will be persisted.

[0056] The security coordinator will be the first The module version status records of each communication module are organized as follows: ,symbol The serial number of the communication module is a positive integer, and the sign is... Indicates the first Each communication module's version state vector is a structured record, with symbols... The symbol represents the module identifier and originates from the read-only identity area of ​​the corresponding module. Indicates the connection status, taking the form of online, weak connection, dormant, or offline. (symbol) Represents a dimensionless integer of the current version, with a value ranging from 0 to 4294967295. (Symbol: ) This represents the version to be activated and is either empty or a dimensionless integer ranging from 0 to 4294967295. (Symbol: ) Represents the minimum acceptable version, a dimensionless integer ranging from 0 to 4294967295, with the sign... The symbol represents a trust marker and indicates whether the action is trustworthy, observable, or compromised. This indicates that a local update manifest digest has been submitted and is a 256-bit digest value; the symbol is... Represents a dimensionless integer representing a persistent water level value, ranging from 0 to 18446744073709551615, with the sign... The vectors, representing the destruction status and including options such as not requested, pending confirmation, completed, or abnormal, are sorted by module identifiers and written into the current update snapshot.

[0057] Trust marks are updated by the security coordinator according to the state machine after reading the device certificate status, certificate signature and certificate chain verification results, remote measurement results, authentication failure count, and revocation notification. A device remains trusted if its certificate is valid, its signature and certificate chain verification are successful, its most recent remote measurement matches the local baseline digest, and it has not experienced more than two consecutive authentication failures. A device is switched to observation and its working key and random number lease issuance are disabled when its certificate is not yet valid, has expired without a clear revocation notification, its measurement times out, or it has experienced 3 to 5 consecutive authentication failures. A device is switched to compromised if its certificate is revoked, its certificate signature or certificate chain verification fails, its remote measurement is clearly inconsistent, or it has experienced more than 5 consecutive authentication failures. When multiple judgment results conflict, the most conservative state is adopted based on the priority order of compromised, observation, and trusted. The observation module's sending queue is only allowed to write status notifications and recovery challenges that do not contain the module's working key and random number lease. A compromised module simultaneously writes to the local revocation table and closes the preparation and recovery packet sending channels.

[0058] Before connection events and authentication events enter the state machine, they are deduplicated by module identifier and event sequence number. For events with the same sequence number, the one with the earliest authentication tag verification and reception time is retained. For late events with an event time more than 120 seconds earlier than the time when the module has submitted its state, only the audit log is written and the connection state is not written back. Input records that lack module identifier, event sequence number or authentication tag are discarded, so that the connection state calculation only uses the authenticated and time-comparable inputs.

[0059] The signature update list received by the security coordinator includes the list sequence number, target version, previous digest, allowed set, revocation set, key module set, activation condition, fault data validity period, signature algorithm identifier, and management end signature. First, the signature byte string to be verified is obtained by encoding it according to a fixed field order and length prefix. Then, the signature verification is performed using the update management public key pre-placed in the security unit, and the SHA-256 digest of the byte string is calculated as the digest of the update list for this round. If a field is missing, the module identifier in the set is duplicated, the target version is not greater than the current version, or the signature verification fails, the list is written to the rejection log without changing any module status.

[0060] After the signature is approved, the security coordinator compares the previous digest of the manifest with the digest of the previous committed manifest in the version status table byte by byte, and verifies that the manifest number is equal to the previous committed manifest number plus 1. Only when both are true will the digest continuity relationship be recorded as passed. When the terminal is first trusted and deployed, the genesis digest and the starting manifest number sealed in the manufacturing stage are used as the comparison benchmark. If the continuity relationship fails, the current version and the minimum acceptable version are retained, the manifest chain is broken and the management end is waited to fill in the missing manifest.

[0061] After the continuity verification is successful, the security coordinator uses the target version carried in the manifest as the target epoch. and in accordance with Generate admission set, symbol This represents the target epoch of the current round, and is a dimensionless integer greater than the current version. (Symbol: ...) Represents the admission set corresponding to the target era, symbol Indicates the allowed set in the signature update list, symbol The set of module identifiers that indicate a trusted module is represented by the symbol. Represents the revocation set in the signature update list, symbol This represents the set of module identifiers whose local trust is compromised. All elements of the set are module identifiers. The intersection, difference, and union operations are performed on the sorted module identifiers. Modules located in the observation set are not considered symbols. Instead of entering the admission set;

[0062] The security coordinator queries the update transaction table using a unique key composed of the list sequence number, target epoch, and list summary. When the same unique key is matched, the existing verification results are reused. If the list sequence number is the same but the target epoch or summary is inconsistent, it is marked as a forked list and the current round of updates is frozen. Only lists that are continuously connected from the submitted summaries and whose target epochs are strictly increasing can enter the admission set for computation.

[0063] The security coordinator registers the set of critical modules carried in the signature update list as the current round's critical module set and calculates the set summary. It does not replace the version submission threshold with the intersection of this set and the admission set. When the same module in the list is simultaneously in the critical module set and the revocation set, the list is marked as a range conflict and the current round of activation is frozen. If any critical module specified in the list is not in the admission set or is in the observation, compromise, or revocation state, the current round of activation is also frozen and a specific reason is written. The threshold is only re-established after a new signature update list with consecutive and clear changes to the critical module set in the previous summary is received.

[0064] For each module in the admission set, the security coordinator writes the version to be activated as the target epoch and keeps the current version unchanged. For non-admission and non-critical modules, the version to be activated is cleared and no security element derivation key is requested. For non-admission critical modules, the threshold blocking state is retained and no key is derived. Finally, the target epoch, admission set, original critical module set and its summary, current update list summary and module version state vector snapshot are written to the update transaction record.

[0065] The number of state vectors for updating transaction records must be equal to the number of terminal registered modules. Both the admission set and the key module set are encoded in ascending order by module identifier and the number of set elements is saved. The security coordinator publishes a read-only snapshot only after recalculating the record digest and finding that it matches the write digest. If the verification fails, the uncommitted page is discarded and the system recovers from the previous committed page. The snapshot that passes the verification serves as the sole input to S2.

[0066] In this specific embodiment, S2 includes:

[0067] The security coordinator reads the update transaction record generated by S1 and establishes a derived context for each communication module in the input set. The derived context includes a terminal identity digest, module identifier, target epoch, protocol field, communication direction, key usage identifier, update list digest, and derived algorithm version. In this specific embodiment, the protocol field distinguishes between telemetry reporting, remote maintenance, and fault recording. The communication direction distinguishes between terminal to master station and master station to terminal. The key usage identifier distinguishes between data encryption, message authentication, and receipt authentication. Each field uses a length prefix encoding to avoid the same derived input being generated after concatenating different fields.

[0068] The security unit stores the 256-bit terminal root secret, which is only available within its internal memory, as... ,according to Derived terminal version key, symbol Represents the terminal root secret and is generated during the security element manufacturing phase; symbol The 256-bit terminal version key representing the target epoch, symbol S1 represents the target epoch determined by S1 and is a dimensionless integer, with the symbol... This represents a summary of the updated manifest and is a 256-bit value; the symbol... This indicates the use of the SHA-256 message authentication code function, symbol Represents a deterministic encoding function with type and length, symbol This indicates a byte string concatenation operation; the terminal version key is stored only in the volatile key slot of the security unit.

[0069] The safety unit continues to press Derived module master key, symbol Indicates the first The 256-bit module master key for each access module, symbol Represents the aforementioned terminal version key, symbol Indicates the first The module identifier for each communication module is defined in the S1 module version state vector and originates from the corresponding module's read-only identity area. (Symbol) Represents the admission module number and takes a positive integer, with the sign... This indicates that the target epoch determined by S1 is used, and is a dimensionless integer greater than the current version with a value ranging from 1 to 4294967295. The symbol is... ,symbol and symbols Following the aforementioned meaning, the key slot access control entry of the module master key is bound to the module identifier and the target epoch, and the security coordinator can only submit a derivation request but cannot read the key;

[0070] For each protocol domain, communication direction, and key usage, the security element is configured as follows: Derivative module working key, symbol Indicates by the first Each module, protocol domain , communication direction and Key Usage A 256-bit working key with a common and unique identifier, symbol Indicates the corresponding module master key, symbol Represents the admission module number and takes a positive integer, with the sign... This indicates an enumeration identifier derived from a derived context protocol field, specifically from the telemetry reporting field, remote maintenance field, or fault record field. Units are not applicable. (Symbol) This indicates an enumerated identifier derived from the derived context communication direction field, taking either terminal-to-master or master-to-terminal communication direction. Units are not applicable. (Symbol) This indicates an enumerated identifier derived from the derived context key usage field, used for data encryption, message authentication, or receipt authentication. Units are not applicable. (Symbol) This represents a 256-bit summary of the updated inventory calculated using S1, with the symbol... ,symbol and symbols Using the aforementioned meaning, any change in the protocol field, communication direction, purpose, or digest field will result in different derived contexts, working key variable identities, and key handles;

[0071] Before requesting a derivation, the security coordinator queries again whether the module identifier is still in the admission set and verifies that the trust mark is trustworthy. Only after the query result is passed will the derivation context digest be submitted to the security unit. Modules that are revoked or turned into compromised modules immediately terminate their derivation queue and delete the volatile handles that have not yet been encapsulated. The module master key of other modules is determined only by the terminal version key and their respective module identifiers. No secrets, proofs or states of the revoked modules are taken as input, thereby maintaining cross-module isolation within the same target epoch and the same inventory digest.

[0072] The security coordinator reads a persistent watermark value for each working key context. In this specific embodiment, a lease is defined as 4096 consecutive counts, according to... , and Determine lease boundaries and new water levels, symbols Represents the persistent water level value before registration, and is a dimensionless non-negative integer, with the sign... Indicates the first The dimensionless starting point of the new lease for each module, symbol The symbol represents the dimensionless end point of the lease. Represents the communication module serial number and takes a positive integer value; a constant. This indicates advancing a dimensionless count value from the pre-registration persistent water level to ensure the new lease start point is strictly greater than the pre-registration water level. The constant 4095 indicates that a total of 4096 count values ​​are allocated, including the start point. Represents the dimensionless persistent water level value after a transaction is committed, with the symbol... This indicates the maximum value of the two values, with the lease start point strictly exceeding the pre-registration water level;

[0073] The lease record consists of lease identifier, module identifier, target epoch, protocol field, communication direction, key usage identifier, update list digest, lease start point, lease end point, current consumption position, lease status, and creation transaction number. The lease identifier is generated by digesting the terminal identity digest, module identifier, target epoch, and monotonic transaction number. The current consumption position is initially the lease start point minus 1. The lease status is initially registered. The lease end point must not exceed the upper limit of the counter bit width. If the remaining space is less than 4096 count values, the lease is not shortened but the context is marked as having exhausted the count space and encapsulation is stopped.

[0074] The security coordinator performs atomic registration binding module identifier and target epoch, random number leases with a starting point greater than the random number persistence watermark value, writes the lease record through the same persistent atomic transaction, updates the random number persistence watermark value in the version status table to the aforementioned new watermark, and appends a pre-write log commit flag. Only when the checksums of the lease record, the master record, and the log commit flag are all verified, does it return a successful transaction commit to the security unit. During power failure recovery, records without commit flags are rolled back as a whole, and transactions with commit flags but whose master records have not been paginated are replayed in the log, so that any lease that can be encapsulated has a persistence watermark not less than the lease end point.

[0075] After the atomic transaction is submitted, the security coordinator generates a preparation packet for each admission module. The list of context entries in the packet is arranged in byte order by protocol domain, communication direction, and key purpose identifier. Each entry includes protocol domain, communication direction, key purpose identifier, working key, lease identifier, lease start, lease end, and entry status. The list covers all required derived contexts defined in the S2 header and each context has an independent lease. Packet-level fields include module identifier, target epoch, update list digest, number of context entries, context list digest, packet sequence number, and valid expiration time. Associated data includes terminal identity digest and derived algorithm version. All working keys are sequentially written to the encapsulation buffer through the controlled export interface of the security unit. Once encapsulation is complete, the intermediate buffer is cleared and the lease status is updated from registered to encapsulated.

[0076] The device recovery credential for the corresponding communication module is an independent long-term credential established in the module security area and the terminal security unit during the manufacturing stage. The security unit uses this credential and the preparation packet sequence number to derive a one-time packet protection key, and uses AES-256-GCM to perform authentication encryption on the plaintext of the preparation packet. The module identifier, target epoch, update list digest and packet sequence number are used as associated data to participate in authentication but are not included in the ciphertext. The receiving module only writes the working key and lease to the temporary storage area when the associated data is consistent with its own identifier and the version to be activated and the authentication tag is verified.

[0077] The security coordinator performs consistency cleaning on duplicate module identifiers in the S1 snapshot. It retains the record with the largest version number only when the current version, minimum acceptable version, trust flag, and digest of the duplicate record are completely consistent. When the fields are inconsistent, the derived task of the corresponding module is frozen and the reason for the state conflict is written. Records outside the align set and records that are missing the target epoch are not included in the derived queue.

[0078] The preparation packet generation result is written into the preparation packet sending table with the module identifier and packet sequence number as keys, and associated with the context list summary and the list of all lease identifiers. Online modules immediately enter the sending queue. Weak connection modules retransmit the same packet sequence number and do not register leases repeatedly. Observed, trapped or revoked modules are filtered by the sending gate even if there are old sending records. Finally, S2 outputs to S3 the module-level preparation packet record corresponding to the admission set, the lease record corresponding to each context, and the sending status snapshot.

[0079] In this specific embodiment, S3 includes:

[0080] The security coordinator reads the preparation packet sending table output by S2 and the connection state snapshot saved by S1, lists the modules in the admission set with online or weak connection status as preparation packet sending objects, writes the dormant or offline modules that do not belong to the critical module set into the catch-up table, and writes the dormant or offline modules that belong to the critical module set into the critical wait table. When the critical wait table is not empty, the update transaction is kept in the preparation stage without generating an activation certificate.

[0081] After the communication module decapsulates the preparation packet, it checks the number of context entries and the context list digest item by item. It writes all working key handles, lease identifier list, lease boundaries, target epoch, and update list digest into the module's secure temporary storage area. Then, it uses the device recovery credentials to authenticate the temporary proof text. The temporary proof text includes the module identifier, target epoch, update list digest, context list digest, all lease identifier list, temporary storage status of each required working key handle, preparation result, monotonic write count of the temporary storage area, and preparation packet sequence number. The preparation result is only retrieved when all working keys and leases in the list are successfully written. Other results are retrieved as insufficient storage, version conflict, incomplete list, or authentication failure. The security coordinator updates the corresponding proof status only after verifying the authentication value, list digest, all lease list, and packet sequence number.

[0082] For weakly connected modules, the security coordinator retransmits at 10-second intervals and a maximum of 3 times. Each retransmission uses the original prepared packet, the original context list digest, and the original lease identifier list. When a duplicate temporary proof with the same module identifier, context list digest, and packet sequence number is received, only the first one that has been authenticated is retained. When a proof with an inconsistent context list digest, lease identifier list, or target epoch is received, the proof is recorded as conflict and the module is kept in an unprepared state to avoid repeated preparation triggering of new working keys or leases.

[0083] The security coordinator checks one by one whether the modules in the critical module set are still in the admission set, whether the temporary proof has been certified, whether the preparation result is successful, and whether the target epoch and update list digest in the proof are consistent with the current transaction. If any critical module fails to meet the conditions, no activation certificate is generated. When a critical module is removed from the admission set due to a trap or revocation event, the critical module set is recalculated only after a new signature update list containing the revocation change and with a continuous digest is received. The critical module must not be ignored in the current round.

[0084] When all critical modules have passed the complete temporary proof and the activation time given by the signature update list has arrived or the specified circuit breaker status collection completion event has occurred, the security coordinator enumerates the admission set. For non-critical modules that have not yet returned a complete temporary proof or whose preparation result is insufficient storage, version conflict, incomplete list, authentication failure, proof conflict or retransmission timeout, regardless of their connection status as online, weak connection, dormant or offline, they are written into the catch-up table and the failure reason is recorded. The qualification to send ordinary services is closed. Online or weak connection modules are immediately initiated by S4 to initiate a recovery challenge.

[0085] After completing the aforementioned enumeration, the security coordinator generates an activation certificate. The certificate body contains the terminal identity digest, target epoch, update list digest, admission set digest, original key module set digest, list of verified temporary proof digests, list of all context lists, list of modules to be caught up and their reasons, activation condition type, actual value of activation condition, and generation time. The terminal proof key of the security unit then generates the authentication value. If the activation condition has not been met, the proof record is maintained and the version is not submitted in advance.

[0086] The security coordinator executes version atomic transactions using the activation certificate as the sole commit credential, for the first... Each switched module is as follows Update to the minimum acceptable version, symbol Indicates the sequence number of the communication module that has been switched, and takes a positive integer, with the sign... This represents the minimum acceptable dimensionless version before submission, indicated by the symbol. This represents the dimensionless target era of this round, symbolized by... This represents the minimum acceptable dimensionless version after submission, indicated by the symbol. This indicates the maximum value operation between the two, while writing the current version as the target epoch, writing the committed list summary as the current round summary, and clearing the version to be activated. Any write request with an input version smaller than the original minimum acceptable version is rejected by the transaction check.

[0087] The same version atomic transaction commits the current terminal version, the summary of the update list for this round, the summary of the activation certificate, and the new version record of each switched module. For non-critical modules in the catch-up table, the old current version is retained and the version to be activated is written as the target epoch that has been committed. The offline state is not added to the preconditions for commit. It is explicitly stated that the target epoch will not be prevented from being committed because the non-critical communication module is in the catch-up state. When the transaction fails, all version fields retain the values ​​before the commit and the activation certificate is marked as pending retry.

[0088] After successful submission, the security coordinator sends an activation notification carrying the activation certificate digest and the current version to the switched module. The module switches the temporary key slot to the current key slot and prohibits service calls with versions lower than the minimum acceptable version. The security coordinator removes the switched module from the preparation packet sending table, keeps the modules to be caught up in the recovery scheduling queue, and finally outputs the current version status digest, minimum acceptable version, catch-up table, admission set, and activation certificate audit record to S4.

[0089] In this specific embodiment, S4 includes:

[0090] The security coordinator reads the catch-up list and current version status digest output by S3. Before calling the working key, it writes the old version fault ciphertext and isolation metadata uploaded by the catch-up module into the isolation queue. After the catch-up module re-establishes the link, it only opens the isolation receiving port. The receiving port saves the old version fault ciphertext it uploaded in the original bytes to the write-only isolation object storage. At the same time, it writes the service identifier, content digest, ciphertext transmission digest, source module identifier, receiving time, old version number, isolation status, object storage address and receiving sequence number into the isolation queue. The content digest is calculated by the module based on the plaintext bytes of the original fault record and remains stable in subsequent retransmissions. The ciphertext transmission digest is only calculated based on the old version ciphertext bytes of this time. The initial isolation status is pending recovery. The receiving path does not request the security unit to load or call the old version module working key.

[0091] The isolated receiving port first cleans the input, verifying the message length, field encoding, content digest, and ciphertext transmission digest format. Then, it removes duplicates according to the source module identifier and the received sequence number. If the message length exceeds 1 MiB, field parsing fails, or any digest bit length is not 256 bits, it is rejected as an abnormal input and does not enter the isolated object storage. The SHA-256 value of the complete old version ciphertext is recalculated to obtain the ciphertext transmission digest and is only compared with the ciphertext transmission digest carried in the message. If the two are inconsistent, the received copy is discarded. The content digest does not participate in the ciphertext byte verification. Only records that match the ciphertext transmission integrity verification are entered into the subsequent isolated metadata matching.

[0092] The service identifier is generated by the source communication module when the fault record is first written to local storage and remains unchanged in subsequent retransmissions. The module uses its own identifier, monotonic local record sequence number and the encoded digest of the record time as a 128-bit service identifier, and the SHA-256 value of the plaintext byte of the fault record as a stable content digest. The security coordinator establishes an isolation item composite key based on the service identifier, content digest and source module identifier. Repeated uploads with the same composite key are merged into the same isolation item and the earliest reception time is retained. The encrypted transmission digest of each upload is stored in the received copy record without changing the composite key. The same service identifier corresponding to different content digests is marked as an identifier conflict and recovery is stopped.

[0093] The security coordinator generates a 256-bit one-time challenge value and a 60-second expiration time for the module to catch up with the composite key that does not conflict. The one-time challenge value, the current version, the minimum acceptable version, the current update list digest, the activation certificate digest, and the challenge expiration time are combined to form a recovery challenge. The challenge record is written to the freshness table with the module identifier and the challenge digest as the key. The initial state is unused. The observation module can only receive this recovery challenge and cannot enter the working key distribution stage. The compromised or revoked module directly changes the challenge state to rejection.

[0094] The communication module uses independent device recovery credentials to generate an authentication response to a one-time challenge value, the current version status summary, the module startup count, and the local recovery sequence number. The security coordinator first confirms that the response arrives within a 60-second validity period, the challenge status is still unused, and the module identifier is still in the admission set. Then, the security unit verifies the device recovery credential authentication value. If successful, the challenge status atom is changed to used with a conditional update. Duplicate responses are rejected because the status is no longer unused. No module working key is invoked when device recovery credential authentication fails or admission set check fails.

[0095] After the freshness verification is passed, the security coordinator, according to the derived context of S2 and the lease atomic registration rules, derives the current working key of the module and registers a new lease only with the current version and current update list digest already committed in S3 as input. The lease start point is strictly greater than the corresponding persistence watermark value. No recovery package is generated when the transaction is not committed. If the target epoch advances again during the recovery period, the remaining leases that have been registered but not used are burned and the challenge and registration start again from the new current version.

[0096] Safety unit according to Derived session protection key, symbol This represents the 256-bit protection key for this session recovery, symbol Indicates the first Individual device recovery credentials for each module and are only available within the security cell, symbol Indicates the recovered module number as a positive integer, with the sign... Represents a 256-bit one-time challenge value, symbol Represents the current version and is a dimensionless integer not less than the minimum acceptable version, with the symbol [symbol missing]. This represents a 256-bit summary of the currently updated manifest, with the symbol... This indicates the use of the SHA-256 message authentication code function, symbol Represents an encoding function with type and length, symbol This indicates a byte string concatenation operation;

[0097] The recovery packet is written in plaintext to the module identifier, current version, current update list digest, list of working key entries for all required contexts of the current version, list of new lease identifiers and the start and end points of each lease, context list digest, one-time challenge value digest, and recovery packet sequence number. The security element performs AES-256-GCM authentication encryption using the session protection key and associates the module identifier, current version, current update list digest, and one-time challenge value with the data. Before encapsulation, the security coordinator compares the current version with the minimum acceptable version again and sends the packet only if the current version is not less than the minimum acceptable version. The session protection key is cleared immediately after sending.

[0098] After the communication module unpacks the recovery package, it writes all necessary working keys and new leases to the temporary storage area and returns a switch confirmation. The switch confirmation binds the module identifier, current version, current update list summary, context list summary, all lease identifier list and recovery session summary. After the security coordinator verifies the integrity of the confirmation, it executes the same version atomic transaction, writes the current version of the module as the recovery package version, updates the minimum acceptable version to the maximum value of the value before the commit and the recovery package version, clears the version to be activated, removes it from the catch-up list and records the recovery session summary. The module activates the current working key and enables subsequent retransmissions only after receiving the transaction commit receipt. When the transaction fails, it remains in the catch-up state and ordinary business access is closed, and the uncommitted working key is not used.

[0099] After the communication module is unsealed and restored, the historical version key slot is kept unusable for transmission. The lease identifier and the unused random number in the new lease are encoded into AES-256-GCM random numbers. The working key corresponding to the current version fault record field, terminal to master station direction, and data encryption purpose is used to perform authentication encryption on the plaintext bytes of the original fault record. The service identifier, stable content digest, source module identifier, current version, lease identifier, random number in the lease, local record time, and module start count are encoded into associated data in a fixed-length order. The fault record ciphertext and GCM authentication tag are output. The outer message authentication tag is calculated on the associated data, fault record ciphertext, and GCM authentication tag using the working key corresponding to the message authentication purpose in the same context. The retransmission record carries the aforementioned associated data field, fault record ciphertext, GCM authentication tag, and outer message authentication tag. Each time the random number in the lease is used, the consumption position is first advanced in the module's secure storage before the ciphertext is output. The consumption position is not rolled back during restart.

[0100] After receiving a retransmission record, the security coordinator first verifies the outer message authentication tag using the working key corresponding to the current version fault record field, the terminal-to-master direction, and the message authentication purpose. Then, it performs AES-256-GCM authentication and decryption using the working key for data encryption purpose of the same version and context, a random number formed by the lease identifier and the random number within the lease, and the authenticated associated data. Any authentication or decryption failure generates an authentication rejection result without generating plaintext. After successful decryption, the SHA-256 content digest is recalculated on the recovered plaintext bytes. Only when the recalculated value matches the stable content digest in the authenticated associated data is the isolation metadata located according to the service identifier, the content digest, and the source module identifier. If the location cannot be determined, a rejection result without isolation basis is generated. If the digest is inconsistent or an identifier conflict is located, a content conflict rejection result is generated. If multiple identical composite keys are located, duplicates are merged and the earliest reception time is read. The current version plaintext, after authentication, decryption, and digest verification, is only written to the pending release buffer and does not directly enter the service processing queue.

[0101] The terminal clock correction module obtains the master station's transmission time and round-trip time from the authenticated master station's clock message every 60 seconds, and then performs the corresponding correction. The second valid sample is based on Calculate the offset, sign Indicates the valid clock sample number as a positive integer, with the sign... Indicates the first The clock correction sample of the secondary terminal relative to the master station, in seconds. A positive value indicates that the terminal clock lags behind the master station. The sign... Indicates the first The next authenticated message carries the master station's sending time in seconds, and the symbol... This indicates the round-trip time of the message as measured by the terminal, in seconds (s). The symbol is... This represents the local time when the terminal receives the message, expressed in seconds. The constant 2 indicates that the round-trip delay is converted to a one-way delay under the symmetric link assumption. The module takes the 8 most recent valid... The median was obtained by limiting the amplitude to -2 seconds to +2 seconds. Security coordinator Calculate the lead time interval, sign Indicates the time interval and the unit is seconds (s), symbol Represents the earliest reception time in the duplicate isolation term, in seconds, with the symbol... Indicates the local record time carried by the retransmission record, in seconds, symbol. This represents the clock correction amount used to convert the terminal's local time to the master station's UTC reference, and the unit is seconds (s). For the corrected recording time, all three use the same UTC epoch time base; samples with negative round-trip delay, exceeding 2 seconds, or with failed authentication are not included in the median calculation; if there are fewer than 8 clock correction samples, the record is marked as clock pending calibration and not released.

[0102] The security coordinator reads the validity period of fault data from the signature update list. In this specific implementation, this field is 86400 s. First, it verifies that the current version of the retransmission record is not less than the minimum acceptable version. Then, it verifies that the validity period interval is not less than 0 s and not greater than 86400 s. If the version is too low, the validity period interval is negative, or the validity period is exceeded, a version rejection, a future time rejection, or a timeout rejection status is written respectively. The unit of the validity period is consistent with the validity period interval.

[0103] After the version and timeliness checks pass, the security coordinator uses the lease identifier and random numbers within the lease to form a unique index for the replay occupancy table. It pre-constructs used records, allow-to-release business judgments, faulty business queue records, and isolation status update records. Used records include module identifier, current version, business identifier, content summary, occupancy time, isolation item composite key, and recovery session summary. In the same persistent database atomic transaction, it performs the insertion of the unique index under the condition of not being used, the use of occupancy, the write of the allow-to-release judgment, the enqueue of the record in the buffer to be released, and the update of the isolation status to released. If any write fails, the entire process is rolled back.

[0104] The security coordinator uses the isolation status equal to the pending recovery, the source module still being in the admission set, and the current version not less than the minimum acceptable version as candidate filtering conditions. It selects the records to be verified from the isolation items of the same source module in ascending order of the earliest reception time. If the reception times are the same, the order is determined by the ascending order of the service identifier byte order. A maximum of 64 records are processed in each recovery cycle. Records that do not meet the filtering conditions are kept in the isolation queue and do not enter the working key call queue.

[0105] The security coordinator merges the results of five steps—authentication tag verification, isolation metadata matching, current version comparison, timeliness check, and unique index condition insertion—into a business release decision. If any of the first four steps fails, a rejection release decision containing a rejection reason code is generated, and the original isolation object remains uncallable. If any conflict occurs during unique index condition insertion, this call generates a replay rejection decision, prevents this record from entering the business queue, and prevents it from being enqueued again. If the recovery session summary, business identifier, content summary, and isolation item composite key of the existing occupied record are all the same as this time, only the existing transaction status and duplicate commit status are returned by the idempotent query interface. This conflict is not interpreted as allowing release. If any binding field is different, a binding conflict reason code is written simultaneously. Only when all five steps pass and the unique index condition insertion is successful can the faulty business queue, the allow decision, and the released isolation status after the atomic transaction commit be simultaneously visible.

[0106] The security coordinator sets three intermediate states for retry rejection: pending clock calibration, pending retry, and pending recovery. If there are fewer than 8 clock samples, the record is updated from pending recovery to pending clock calibration using the isolation item composite key, recovery session summary, and current state as idempotent condition keys. After the terminal clock calibration module obtains 8 valid samples, it re-verifies that the source module is still in the admission set, the current version is not less than the minimum acceptable version, the isolation metadata binding has not changed, and the record is still pending clock calibration. If all conditions are met, the record is updated to pending recovery and re-added to the candidate queue. Temporary resource shortages or transaction lock congestion also apply. If a request suddenly enters the "pending retry" state, the recovery scheduler will update it to "pending recovery" using the same condition key after resource recovery or transaction lock release. During re-verification, the old allowed result is not directly reused. Instead, the outer message authentication label is verified again, AES-256-GCM authentication and decryption are performed, the plaintext digest is recalculated, and version, timeliness, and unique index checks are re-performed. Authentication failure, decryption failure, content conflict, version too low, future time, timeout, or replay conflict are permanent rejection reasons. The status is updated to "rejected" and the request cannot be re-entered into the candidate queue. If the condition update fails, the original status is maintained and written to the scheduling audit.

[0107] S4 finally writes the service release decision, current version, module identifier, new lease identifier, used random number occupancy record, isolation item composite key and recovery session summary into the recovery audit record, and sends a destruction request to the communication module. The destruction request explicitly lists all historical key version sets that are lower than the current version and the set of old lease identifiers registered before recovery but not yet confirmed as used. The recovery audit record and the destruction request together serve as the input of S5.

[0108] In this specific embodiment, S5 includes:

[0109] This specific implementation performs the destruction closing stage of a multi-module key collaborative update method for power transmission terminals. The security coordinator reads the service release judgment and destruction request output by S4. For both the allowed release and denied release recovery results, the communication module is required to clear the historical module master key handle, historical working key handle, and old lease balance before recovery that are lower than the current version. The destruction request includes the request sequence number, module identifier, current version, historical key version set, old lease identifier set, and recovery session digest. The communication module only accepts requests whose current version is equal to its activated version and whose request sequence number is greater than the last processed sequence number.

[0110] The communication module sequentially puts historical key slots into an unretrievable state in secure storage and marks the remaining amount of each old lease from the current consumption position plus 1 to the lease end as permanently unallocable. Then, it generates an authentication receipt. The receipt text includes the module identifier, the current version, the set of destroyed historical key versions, the set of burned old lease identifiers, the results of each destruction operation, the request sequence number, the completion time, and the recovery session summary. The receipt authentication value is calculated using the current version module working key corresponding to the receipt authentication purpose in S2.

[0111] The security coordinator requests receipt verification from the security unit based on the module identifier, current version, receipt authentication purpose, and current update list summary. Before verification, it verifies that the receipt request sequence number is consistent with the destruction request, that there are no missing items in the historical key version set and old lease identifier set, and that the recovery session summary is consistent with the S4 audit record. When the authentication value and field integrity are both passed, the result of each destruction item is written to the destruction status of the version status table and associated with the corresponding recovery audit record with the receipt summary.

[0112] When a communication module restarts, recovers from an interruption, advances a target epoch, or is revoked, the security coordinator enumerates all leases in the lease table that are registered, encapsulated, issued, recovering, or committed but not yet closed, based on the module identifier. It reads the endpoint registered on the coordinator side for each lease and the last confirmed persistent consumption position in the module's secure storage. It updates the closed interval from the next count value after the consumption position to the lease endpoint as permanently unallocatable, using the lease identifier and trigger event sequence number as idempotent conditions. Simultaneously, it marks the old lease handle on the corresponding module side as unusable. If the consumption position is missing or cannot be authenticated, the entire segment from the lease start point to the endpoint is burned. Permanently unallocatable intervals are processed repeatedly, only returning the original transaction result. After burning the remaining portion, the security coordinator scans all committed leases and permanently unallocatable intervals of the module, and then... Repair persistent water level, symbol This represents the dimensionless random persistent water level value after repair, with the symbol... This represents the dimensionless persistent water level value before restoration, symbol [symbol missing]. Indicates the first The set of all submitted leases and permanently unassignable lease ranges for each module, symbolized by [symbol]. The symbol represents the communication module serial number, which is a positive integer. The symbol represents the lease index in the lease set. Indicates the first The dimensionless endpoint of a leased or burned-out zone, symbolized by... This operation represents the maximum value of a set or the maximum value of two sets.

[0113] The aforementioned triggering event, lease identifier, burn interval, old lease handle failure status, repaired water level, and transaction number are committed in the same persistent transaction, and the next lease start point is... Persistence, Symbols The symbol represents the dimensionless starting point of the next random number lease. This represents the dimensionless persistent water level value after the aforementioned repair. The constant 1 indicates that it crosses the last count value that is occupied or permanently unallocable. When the lease table is empty, the maximum value of the set is treated as 0. When the transaction commit fails, all burn-out and water level candidate writing, stop preparation package and recovery package generation are rolled back and the normal business access of the corresponding module is closed. The candidate starting point or old lease balance in memory is not used.

[0114] The security coordinator limits the destruction of the state machine to three committable states: pending confirmation, completed, and abnormal. It can only transition from pending confirmation to completed or abnormal. The completed state cannot be rolled back. The abnormal state can only be converted to completed after a new recovery session is generated and the new authentication receipt is verified. Each state transition uses the recovery session summary as the conditional update key. The old session receipt cannot overwrite the new session result.

[0115] After the current version and minimum acceptable version are submitted, the security coordinator submits a historical key expiration command to the security unit. The command action fields include deleting volatile slots, blocking persistent handles, and checking the version lower bound. The security unit deletes the module master key and working key volatile slots that are lower than the minimum acceptable version one by one. For objects that must retain audit digests, only the key identifier, version, and destruction time are saved, but the key material is not saved. A version lower bound check is performed every time a key is invoked. If any requested version is lower than the minimum acceptable version, a version rejection is returned and no decryption, authentication, or derivation is performed.

[0116] When the authentication receipt arrives within 120 seconds after the destruction request is issued, the authentication value is verified, the set is complete, and all destruction operations are completed, the security coordinator updates the destruction status to complete. For modules that are allowed by S4, the subsequent service access status is updated to enabled. For modules that are denied by S4, service access is kept disabled, but isolation verification is allowed to be re-executed after a new fault record or clock correction condition is met. All status changes and receipt summaries are committed within the same transaction.

[0117] The security coordinator scans records awaiting confirmation with a 5-second acknowledgment check cycle, using the destruction request sequence number, recovery session summary, and the deadline formed by adding 120 seconds to the destruction request issuance time as the condition update key. If the current time has not exceeded the deadline and no acknowledgment has been received, the record remains pending confirmation and does not enter the abnormal recovery branch. Only if the current time has exceeded the deadline and no acknowledgment is received is the destruction status updated to abnormal. Before and after the deadline, as long as an acknowledgment is received and verification is completed, if the authentication value verification fails, the acknowledgment set is missing, or any destruction operation result is incomplete, the abnormal recovery branch is immediately entered. The state transition transaction re-checks the request sequence number, recovery session summary, deadline, and current status. If the conditions do not match, the old scan results are discarded to prevent old scan results from overwriting valid acknowledgments arriving within the window. After entering the abnormal recovery branch, the subsequent service access status is set to closed, the ordinary service sending token for this module is deleted, and only the recovery challenge port based on the independent device recovery credential is retained in the recovery routing table. The next recovery must regenerate the one-time challenge value, re-verify the access set, and register a new lease according to the current persistence level, without reusing recovery packets from failed sessions.

[0118] Before each business session is established, the subsequent business access gate reads the business release judgment, destruction status, current version and trust mark. It issues a normal business sending token only when the business release judgment is allowed, the destruction status is completed, the requested version is not less than the minimum acceptable version and the trust mark is trusted. If any of the four conditions are not met, the token is rejected and the corresponding status code is returned. The judgment of restoring the challenge port is independent of the normal business sending token.

[0119] The audit write module first checks whether the recovery session summary already exists. If it does not exist, it inserts a new record based on conditions. If it already exists and the receipt summary is the same, it returns idempotency success. If it already exists but the receipt summary is different, the two records are marked as audit conflict and business access is kept closed. The audit records are sorted by both generation time and transaction number and are pulled and verified by the main station every day.

[0120] The security coordinator combines the business release decision, destruction request, authentication receipt, historical key expiration result, old lease burning result, water level repair transaction number, and subsequent access status into an audit association record that cannot be added or modified. The record is indexed by the module identifier, current version, and recovery session digest and is authenticated by the terminal audit key. Thus, the access scope formed by S1, the key and lease registered by S2, the monotonic version submitted by S3, the release decision generated by S4, and the destruction status completed by S5 are linked together into the final output of the same update transaction.

[0121] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

[0122] The module version state vector, signature update list, hierarchical key derivation, and activation certificate of this invention jointly establish a continuous control chain from update authorization and module scope to version submission. Non-critical offline modules escape the current round of submission blocking through the catch-up state, while revoked or compromised modules are excluded in the derivation, preparation, and recovery phases, thus maintaining key material isolation between different modules, protocol domains, communication directions, and key uses.

[0123] The persistent random number lease and isolation recovery gate change the processing order of key materials and offline fault data: the lease and water level are persisted first, then the key materials are encapsulated; the old ciphertext is isolated first, then the independent recovery credential is verified; business data is released only after retransmission and completion of random number occupancy, replay and timeliness verification in the current version; in conjunction with the historical key expiration, old lease burning and authentication receipt access interlock, the version is not rolled back after submission and the risk of key and random number pair reuse and old ciphertext replay is reduced.

Claims

1. A method for collaborative key update of multiple modules in a power transmission terminal, characterized in that, include: S1. Obtain the connection status, version, and trust status of the communication module to form a module version status vector; Verify the signature update list, determine the target epoch, and exclude or revoke the access set of communication modules; S2. Align with the modules within the set and derive mutually isolated module working keys from the terminal root secret of the security unit according to the target epoch and module identifier; After binding the module identifier and target epoch, and the random number lease with a starting point greater than the random number persistence level, the working key and the lease are encapsulated into a preparation package; S3. Generate an activation certificate based on the preparation package temporary proof of the connected modules and submit the target era as the current version accordingly, and monotonically increase the minimum acceptable version. Non-critical offline modules are now in a catch-up phase. S4. Before calling the working key, write the old version fault ciphertext and isolation metadata uploaded by the module to be caught up into the isolation queue; after confirming that the module is still in the admission set and has passed the freshness verification with independent device recovery credentials, register the new lease in accordance with step S2, and send a recovery package that only points to the current version and contains the module working key and the new lease of this version; receive the local original fault record that is re-encrypted with the working key and the random number in the new lease, and generate a business release decision after matching with the isolation metadata, replay verification and timeliness verification. S5. Based on the business release judgment and the historical key expiration and old lease burn authentication receipt returned by the module, update the destruction status and subsequent access status.

2. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 1, characterized in that, S1 includes: For each communication module, record the module identifier, connection status, current version, version to be activated, minimum acceptable version, trust flag, update list summary, persistent random number level, and destruction status; Verify the continuity between the signature, the preceding digest, and the locally submitted digest of the signature update list; When the continuity relationship verification is successful, the target version carried by the signature update list is used as the target epoch. The communication modules located in the allowed set and marked as trusted are determined as the admission set, and the communication modules located in the revocation set or marked as compromised are excluded from the admission set.

3. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 1, characterized in that, S2 includes: Within the security unit, a terminal version key corresponding to the target epoch is derived from the terminal root secret. Then, a module master key is derived using the terminal version key and the module identifier. Finally, the module working key is derived from the module master key using the protocol domain, communication direction, and key purpose as domain separation tags. In persistent storage, the lease identifier, module identifier, target epoch, protocol domain, communication direction, update list digest, lease start, lease end and lease status are written through the same atomic transaction, and the persistent watermark value of the random number is advanced to a value not less than the lease end. The module working key and random number lease are encapsulated only after the atomic transaction is committed. The preparation packet is protected by the device recovery credentials of the corresponding communication module, so that the preparation packet can only be decapsulated by the corresponding communication module.

4. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 1, characterized in that, S3 includes: designating communication modules located in the admission set and whose connection status is online or weak as preparation package delivery targets, and marking non-critical communication modules whose connection status is dormant or offline as pending catch-up; the temporary proof includes a module identifier, target epoch, update list digest, lease identifier, and preparation result; generating the activation certificate when all temporary proofs corresponding to the critical modules are verified and the activation time or activation event specified in the signature update list arrives; atomically submitting the current version, minimum acceptable version, and update list digest with the activation certificate, clearing the pending activation versions of switched communication modules, and not preventing the target epoch from being submitted because the non-critical communication modules are in a pending catch-up state.

5. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 1, characterized in that, S4 includes: The isolation metadata includes at least the service identifier, content summary, source module identifier, reception time, old version number, and isolation status. After receiving the old version fault ciphertext, the module working key corresponding to the old version number is not invoked to authenticate the recovery request. A recovery challenge containing a one-time challenge value and a current version status summary is sent to the communication module in the catch-up state to verify that the communication module is still in the admission set, and the response returned by the communication module to the one-time challenge value is verified using the device recovery credentials; after the verification is successful and the atomic registration transaction of the new lease is submitted, the recovery package containing the current version, the current update list summary, the new lease, and the current module working key is generated, and a session protection key is derived using the device recovery credentials and the one-time challenge value, and the recovery package is authenticated, encrypted, and bound with the module identifier, the current version, the current update list summary, and the one-time challenge value, so that the version in the recovery package is not less than the minimum acceptable version.

6. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 1, characterized in that, S5 includes: writing the module identifier, current version, set of destroyed historical key versions, set of burned old lease identifiers, destruction operation result, and receipt authentication value into the authentication receipt; verifying the receipt authentication value and writing the verified destruction operation result into the destruction status; identifying missing receipts, unverified receipt authentication values, or incomplete destruction operation results as abnormal recovery branches, setting the subsequent service access status of the corresponding communication module to closed in the abnormal recovery branch, and only retaining the channel for re-performing recovery based on the device recovery credentials.

7. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 2, characterized in that, The connection state is determined by the security coordinator based on the link establishment event, sleep notification, continuous transmission failure count, and the time of the most recent authentication communication of the communication module; the trust mark includes at least three values: trusted, observation, and compromised. Communication modules with the observation value are restricted to receiving only state notifications and recovery challenges that do not contain the module working key and random number lease; communication modules with the compromised value are added to the revocation set and do not obtain the module master key corresponding to the target epoch. The key modules are determined by the set of key modules in the signature update list. An activation certificate is not generated if a key module does not return a verified temporary proof.

8. The method for collaborative updating of multi-module keys in a power transmission terminal according to claim 3, characterized in that, The key purpose is characterized by a key purpose identifier, the domain separation label also includes the update list summary, and the key purpose identifier at least distinguishes between data encryption, message authentication and receipt authentication; Different module identifiers, target epochs, protocol domains, communication directions, key usage identifiers, or update list digests correspond to different derived inputs. When any communication module is determined to be a revoked communication module, the generation of new leases and new module working keys for that communication module is stopped. Within the same target epoch and the same update list digest, the module master keys and module working keys of other communication modules are not affected by the secret materials of the revoked communication module. When the target epoch changes, the module master keys of other communication modules are updated according to the changed derived inputs, and when the target epoch or update list digest changes, the module working keys of other communication modules are updated according to the changed derived inputs.

9. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 5, characterized in that, For each local original fault record, a unique and unchanging service identifier is generated within the source communication module. The re-encrypted local original fault record carries the service identifier, content digest, source module identifier, current version, lease identifier, lease-internal random number, and local record time. Based on the service identifier, content digest, and source module identifier, the corresponding isolation metadata is located. Duplicate isolation items with the same service identifier, content digest, and source module identifier are merged, and the earliest reception time is retained. The current version is compared with the minimum acceptable version, and the time interval obtained by subtracting the local record time corrected by the power transmission terminal clock from the earliest reception time is calculated. When the current version is not less than the minimum acceptable version and the time interval is not less than zero and not greater than the fault data validity period specified in the signature update list, conditional insertion is performed using the lease identifier and lease-internal random number as unique indexes. Unused judgment and used occupied record are completed through the same atomic transaction. A service release decision is generated only when the conditional insertion is successful, and a service release decision is generated when a unique index conflict occurs.

10. The method for collaborative key update of multiple modules in a power transmission terminal according to claim 6, characterized in that, When a communication module restarts, recovers from an interruption, advances a target epoch, or is revoked, the remaining random number leases allocated to the corresponding communication module but not recorded as used are marked as permanently unallocable. The maximum value of the lease endpoint of all submitted or marked as permanently unallocable random number leases is compared with the current random number persistence level. The random number persistence level is monotonically advanced to a value not less than the maximum value of the lease endpoint. The starting point of the next random number lease is then persisted to a value greater than the advanced random number persistence level. After the current version and minimum acceptable version are submitted, the module master key and module working key of the corresponding historical version in the security unit are deleted or rendered unusable. The authentication receipt is used as an audit association record for the invalidation of historical keys, the burning of old random number leases, and subsequent access status updates.

Images