Cross-level security authentication method for industrial internet based on certificateless identity-based cryptography system

Abstract

The application discloses a cross-level security authentication method of industrial internet based on a certificateless identification cipher system. In a multi-level structure of groups, parks, factories and equipment terminals, a layered certificateless key system of a root key generation center and a domain key generation center is constructed. A device private key is composed of a self-selected secret value and a domain issued partial private key, and neither key center can obtain it, eliminating hosting. The root key generation center signs each domain parameter identifier to form a domain trust list and caches and distributes it. A verification party can verify cross-domain equipment offline by using a local cache without online contacting an opposite domain key center. An authentication factor is divided into offline precalculation and online response. Online only performs hash, modulus multiplication and modulus addition, and pairing verification is borne by a gateway. Hierarchical permissions are decoupled from time-effective credentials and keys, and keys are negotiated in the same interaction. The application is certificateless, hosting-free and free from online key center interaction across domains.

Description

Technical Field

[0001] This invention relates to the fields of information security and cryptographic application technology, specifically to a cross-level security authentication method for the industrial internet based on a certificate-free cryptographic system. Background Technology

[0002] The Industrial Internet typically presents a multi-level structure of "group-level - park or factory-level - equipment or terminal level." Massive heterogeneous terminals need to access the platform across levels and domains and complete trusted identity authentication and secure communication. To address this need, existing trusted identity authentication solutions have generally followed three technical routes, but all of them have limitations in the cross-level and cross-domain scenarios of the Industrial Internet.

[0003] The first category comprises identity-based cryptography and certificateless signature schemes. These schemes replace public key certificates with user identity identifiers, with the key generation center generating private keys based on these identifiers. This eliminates the need for certificate issuance and maintenance. Some schemes modify the method of generating user private keys without altering the overall architecture of the elliptic curve cryptography, and also avoid the time-consuming bilinear pairing operations in identity-based cryptography to reduce signature complexity. However, these schemes are primarily geared towards single-domain, single-layer applications: when using a single key generation center, the user's private key is entirely generated by the key center based on the identifier, presenting inherent key escrow risks. Even with the introduction of static and dynamic dual key management centers to alleviate escrow, update, and revocation issues, the user is still not the sole owner of their private key, and dynamic keys must be obtained online from the dynamic key center. Cross-entity, especially cross-domain, authentication lacks an offline trust mechanism that eliminates the need for online contact with the other party's key center. Furthermore, these schemes do not further reduce the online computation load for resource-constrained industrial terminals and do not decouple hierarchical permissions from keys in the form of independently updatable credentials.

[0004] The second category is cross-domain authentication schemes based on public key infrastructure and certificate chains. These schemes typically involve the authentication server in the first trusted domain authenticating the entity, followed by the authentication server in the second trusted domain verifying the legitimacy of the first domain's authentication server online based on a pre-established trust relationship to complete the cross-domain authentication. However, the cross-domain mutual trust of such schemes relies on the online interaction between certificates and inter-domain authentication servers, requiring the establishment of certificate authorities, the issuance and revocation of certificates, and the maintenance of certificate revocation lists or online certificate status protocols. When the hierarchical structure is hierarchical, peer-to-peer, or mesh-like, and the entities are not adjacent, trust chain lookup and establishment become complex, authentication paths are long, latency is high, and there is strong coupling and single-point dependency on the online services of the other domain.

[0005] The third category consists of dedicated authentication solutions for industrial control or hierarchical scenarios. These solutions are mostly based on national cryptographic certificate algorithms and establish a root of trust using dedicated security chips. The authorization management server and the authentication terminal work together to complete signing, verification, and encryption / decryption. However, these solutions still rely on certificates and dedicated security chips, do not use certificate-free cryptography to avoid certificate management, and are geared towards a single authorization management server. They do not build a cross-level, cross-domain offline trust system across the group, park, and factory, nor do they perform lightweight online and offline segmentation for low-computing-power terminals.

[0006] In summary, existing technologies have the following main shortcomings in cross-level and cross-domain authentication scenarios in the Industrial Internet: First, they rely on digital certificates, which are complex to deploy and costly to maintain in scenarios with massive, heterogeneous, and long-lifecycle terminals. Second, cross-domain identity trust relies on online trust paths, resulting in high latency, strong inter-domain coupling, and single points of dependency. Third, there is key escrow or incomplete escrow mitigation, making it difficult for users to be the sole owners of their private keys. Fourth, identity password verification involves heavy computations such as bilinear pairing, leading to high online computational overhead and high latency for resource-constrained terminals. Fifth, identity authentication is disconnected from authorization and session key negotiation, requiring key re-signing for permission updates, resulting in numerous rounds of interaction and difficulty in unifying cross-domain security strategies. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a cross-level security authentication method for the Industrial Internet based on a certificate-free cryptographic system. The Industrial Internet, from top to bottom, includes a group-level system with a root key generation center, a park or factory-level system with a domain key generation center and a verifier, and a device or terminal-level system with industrial terminals acting as certifiers. The method is characterized by the following steps: Step S1: The root key generation center generates system parameters, a root master key, and a root public key, and issues a domain partial key for the domain identifier. The domain key generation center selects a domain secret value and generates a domain public value. The domain master key is composed of the domain partial key and the domain secret value. In step S2, the proving party selects a device secret value and generates a device public value, submits the device identifier and the device public value to the domain key generation center, and the domain key generation center issues a partial private key for the device based on the domain secret value. The proving party then uses the device secret value and the partial private key to form the complete private key for the device. Step S3: The root key generation center uses the root identifier to identify and sign the entry containing the domain identifier and the domain public value to obtain the entry signature, and distributes the domain trust list composed of the entry and the entry signature to the local cache of the verifier. Step S4: The verifier receives the authentication message sent by the prover, and performs offline verification of the cross-domain prover based on the domain trust list and the root public key, without contacting the key generation center of the domain to which the prover belongs online.

[0008] Preferably, in step S4, before the proving party sends the authentication message, the proving party pre-calculates and caches the offline factor; after receiving the authentication challenge, the proving party generates an authentication response based solely on the cached offline factor, the device secret value, and the authentication challenge using only hash operations, modular multiplication operations, and modular addition operations; the authentication message includes the offline factor, the authentication response, the device partial private key, the device identifier, and the device public value.

[0009] Preferably, the offline factor is an elliptic curve point pre-calculated and cached by the prover using a scalar multiplication operation between a random number and the first generator in the system parameters; The challenge value of the authentication challenge is obtained by hashing the authentication challenge using SM3, and the authentication response is a scalar obtained by modular multiplication and modular addition of the random number, the challenge value, and the device secret value.

[0010] Preferably, the domain key generation center uses a domain signature private key to identify and sign the information containing the device identifier, permission level, update generation, and expiration time, and issues hierarchical permission credentials that are independent of the complete private key of the device. The authentication message also includes the hierarchical permission credentials; The offline verification in step S4 also includes verifying the signature validity of the hierarchical permission credential, the timeliness of the expiration time and the consistency with the hierarchy of the permission level, and ensuring that the update of the hierarchical permission credential does not affect the complete private key of the device.

[0011] Preferably, the method further includes step S5, in the same authentication interaction in which the verifier completes the offline verification for the proviser, the proviser calculates the same shared value based on the device secret value and the offline factor, and the verifier calculates the same shared value based on the verification secret value of the verifier, and derives a session key from the shared value using a key, and the proviser and the verifier use the session key and SM4 to perform symmetric encryption on subsequent communications.

[0012] Preferably, the identifier signature uses an SM9 identifier signature; in step S2, the domain key generation center issues the device partial private key based on the domain secret value and the binding hash obtained by SM3 from the device identifier and the device public value, wherein the device partial private key, the binding hash, and the domain public value satisfy a pairing binding relationship: ; in This is a partial private key for the device. For the binding hash, The public value of the domain, and These are the first generator and the second generator in the system parameters, respectively; the verifier verifies the pairing and binding relationship when performing the offline verification on the prover.

[0013] Preferably, when the verifier performs the offline verification on the prover in step S4, the verification equation is... Whether it is valid, among which For the authentication response, This is the first generator in the system parameters. For the offline factor, The challenge value is... The device is publicly disclosed to verify that the certifying party holds the device's secret value.

[0014] Preferably, the authentication message further includes a timestamp and a replay-prevention random number. In step S4, the verifier checks whether the difference between the timestamp and the local time is within a preset time window during the offline verification, and checks whether the replay-prevention random number has not been recorded, in order to defend against replay attacks.

[0015] Preferably, the domain trust list is reissued by the root key generation center and distributed to the verifier according to a preset update cycle.

[0016] Preferably, in step S4, when the verifier performs offline verification on the cross-domain prover, it retrieves the entry corresponding to the domain to which the prover belongs from the locally cached domain trust list, first verifies the entry signature of the retrieved entry with the root public key, and then obtains the corresponding domain public value from the retrieved entry for verification of the prover.

[0017] The beneficial effects of the present invention include at least the following: 1) This invention replaces the public key infrastructure certificate system with a certificateless cryptographic system, eliminating the need to build certificate authorities, issue or revoke certificates, maintain certificate revocation lists and online certificate status protocols, fundamentally simplifying the access deployment and full lifecycle operation and maintenance of massive heterogeneous industrial terminals.

[0018] 2) The verifier can verify cross-domain devices offline using the locally cached domain trust list signed by the root key generation center. Cross-domain authentication does not require online contact with the other party's domain key generation center, nor does it require online search or establishment of a trust chain. The number of cross-domain online interactions is significantly reduced, and the strong coupling and single point of dependence on the other party's online services are eliminated. This effect is particularly prominent in hierarchical or mesh-level systems and when entities are not adjacent.

[0019] 3) The complete private key of the device is composed of the device's self-selected secret value and the domain-issued private key. The root key generation center does not participate in the generation of device keys, and the domain key generation center does not have the device's self-selected secret value. No key center can obtain the complete private key of the device, thus achieving complete keyless escrow under the hierarchical structure.

[0020] 4) By splitting online and offline authentication factors, the terminal can complete the pre-computable part during idle time, and only performs hash, modular multiplication and modular addition during the online stage. The authentication response does not contain bilinear pairing operations, and the most time-consuming pairing verification is transferred to the gateway with stronger computing power, thereby significantly reducing the online computing load and authentication latency of resource-constrained terminals and improving terminal adaptability.

[0021] 5) Hierarchical permissions are carried independently with time-limited and hierarchical permission credentials and decoupled from the key. Permission changes only require re-signing of lightweight credentials without touching the device private key. In addition, the session key is exported in one go in the same authentication interaction, so that identity authentication, cross-level authorization and session key negotiation are completed in one round, and cross-domain security policies are unified.

[0022] This invention pre-embeds the trustworthiness of the counterparty domain parameters into a root signature entry and places it in the local cache of the verifier, thus reducing cross-domain verification to an offline process of local table lookup and root public key verification. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of the industrial internet cross-level security authentication system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the industrial internet cross-level security authentication method according to an embodiment of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0025] like Figure 1As shown, the industrial internet applied in this embodiment of the invention comprises three layers from top to bottom. At the group level, a root key generation center is deployed, serving as the trusted root of the entire cross-level trust system. It is responsible for generating the system master key and system public parameters, issuing domain partial keys and verifying domain public parameters for each domain, and identifying and signing the domain identifiers and domain public values ​​of each domain to generate, maintain, and distribute domain trust lists. The root key generation center does not directly issue keys to devices and therefore does not access the complete private keys of devices. At the park or factory level, each "domain" is used as a unit. Figure 1 Taking parallel domains A and B as examples, each domain deploys a domain key generation center and a gateway or platform acting as the verifier: The domain key generation center holds the domain master key, issues partial private keys for devices in this domain based on the device core identifier and the device public value, issues hierarchical permission credentials with time limits and levels, and forwards the domain trust list to the gateway cache in this domain; the gateway caches the domain trust list, receives authentication requests from proving parties and initiates challenges, undertakes heavy verification including bilinear pairing operations, performs offline verification of cross-domain proving parties using the locally cached domain trust list, and after successful verification, exports the session key and grants the corresponding level of permissions in an integrated manner. Devices or terminals are various industrial terminals acting as proving parties in the authentication process, a significant proportion of which are terminals with limited computing power, storage, and power consumption; during the registration phase, industrial terminals select their own secret value and calculate the public value, obtain partial private keys and permission credentials from the domain key generation center to synthesize a private key for uncertified devices, pre-calculate and cache offline authentication factors when idle, and generate authentication responses only using hash, modular multiplication, and modular addition after receiving challenges online. The aforementioned levels and domains are coupled into an organic whole through relationships such as key and credential distribution, list caching, authentication interaction, and cross-domain offline verification.

[0026] like Figure 2 As shown, the present invention provides a cross-level security authentication method for the industrial internet based on a certificateless cryptographic system, which includes the following steps.

[0027] Step S1: The root key generation center generates system parameters, root master key and root public key, and issues domain partial key for domain identifier. The domain key generation center selects domain secret value and generates domain public value. The domain master key is composed of domain partial key and domain secret value.

[0028] Specifically, in the system establishment phase of this embodiment, the root key generation center selects a bilinear pair, i.e., a pairing operation. ,in , , All three orders are equal to the same large prime number. cyclic groups, for example Use 256 bits, for example, the recommended curve of the national cryptographic standard SM9 or a 256-bit BN curve with equivalent security strength; , Groups , The generator, referred to in this specification as For the first generator, As the second generator, the two belong to different groups and are not interchangeable; the pairing operation requires its left parameter to be taken from... The right parameter is taken from The root key generation center selects the root master key. Calculate the root public key In this instruction manual Represents the points of an elliptic curve of Double-point operation. The root key generation center also selects derived hash families. , , Key Derivation Function and the symmetric encryption algorithm SM4: The SM9 standard, based on SM3, combines bit strings with integers. Mapped to Cryptographic functions used for key derivation; The message hash function used internally by the SM9 identifier signature is used for the generation and verification of domain partial keys, domain trust list entries, and hierarchical authorization credentials. Challenge hashing for online knowledge proofs; This is a key derivation function constructed using SM3 and outputting a 128-bit key. , All are hashed by SM3 after performing a modulo operation on the input message. The Covenant The finally disclosed system parameters include the aforementioned group, group order, pairing operation, first generator, second generator, root public key, and hash family. to And the SM3 and SM4 algorithms.

[0029] Each domain is identified as The domain, hierarchical key derivation, and domain registration are as follows. The root key generation center identifies the domains according to the key generation rules for identifier cryptography. Issuance of the domain partial key; in this embodiment, the identifier signature can adopt the national cryptographic standard SM9 identifier signature, and the corresponding regional partial key is calculated according to the SM9 key generation rules. ,in This is the key purpose identifier, with a signature purpose value of 0x01, consistent with GM / T0044; some keys in this field satisfy the pairing and binding relationship. ,because The right side of the equation is equivalent to This allows anyone holding the root public key to verify the authenticity of a portion of the domain's key offline. The domain key generation center selects the domain secret value. Computational domain public value The domain master key for this domain is a binary tuple. ,in This reflects the root's authorization of that domain. The key is private to the domain and is not controlled by the root key generation center. Therefore, the root key generation center does not participate in device key generation and does not possess the domain secret value, laying the foundation for subsequent keyless escrow.

[0030] In step S2, the proving party selects a device secret value and generates a device public value. The device identifier and the device public value are submitted to the domain key generation center. The domain key generation center issues a partial private key for the device based on the domain secret value. The proving party uses the device secret value and the partial private key to form the complete private key for the device.

[0031] In one embodiment of the present invention, this step is specifically as follows.

[0032] Core identification of equipment ,in For domain identification, For hierarchical identification, For equipment identification. Proof of the equipment's secret value (selected by the proving party). Public value of computing equipment The core identifier and the device's public value are sent to the domain key generation center of the domain. The domain key generation center calculates the binding hash. For example, the binding hash can be obtained by using the national cryptographic standard SM3 to calculate the device identifier and the device public value; and a partial private key of the device can be issued based on the domain secret value. The device's private key, binding hash, and domain public value satisfy a pairing and binding relationship. Therefore, any value disclosed to the device Any replacement will break this binding relationship and be detected by the authenticator, which is the source of certificateless security. The device's complete private key is... The publicly disclosed information is only the equipment's publicly available value. No certificate is required. This is because the domain key generation center controls... However, they do not possess the device's self-selected secret value. The root key generation center only holds the root master key and does not participate in device key generation. Therefore, no key generation center can obtain the complete private key of the device, thus completely eliminating key escrow in the hierarchical structure.

[0033] In another embodiment of the present invention, while issuing a partial private key for the device, the domain key generation center separately uses its domain signing private key to perform an identifier signature on the information consisting of the device identifier, permission level, update generation, and expiration time, and issues a hierarchical permission credential that is independent of the complete private key of the device; the hierarchical permission credential is decoupled from the device private key, and when the permission is updated, only the hierarchical permission credential needs to be reissued without affecting the complete private key of the device.

[0034] In step S3, the root key generation center uses the root identifier to identify and sign the entry containing the domain identifier and the domain public value to obtain the entry signature, and distributes the domain trust list consisting of the entry and the entry signature to the local cache of the verifier.

[0035] In one embodiment of the present invention, this step is specifically as follows.

[0036] The root key generation center uses the root identifier. and the root signature private key derived from the root master key. An identifier signature is performed on an entry consisting of a domain identifier, a domain public value, a list number, and a validity period to obtain the entry signature. For example, the identifier signature uses the national cryptographic standard SM9 identifier signature, and its signing process internally uses hashing. Hash the message to be signed with the matched intermediate value. The verifier uses the root identifier. With root public key The entry can be signed and verified. The entry signature, along with the entry itself, constitutes a record in the domain trust list. This record is distributed by the root key generation center and forwarded to the local cache of each domain gateway. Entry signing allows any verifier holding the root public key to verify the authenticity of any domain's public value offline, forming a trust root for cross-domain offline verification. Simultaneously, the root key generation center does not possess the domain secret value, and the domain key generation center does not possess the device's self-selected secret value, structurally ensuring that no key center can obtain the complete private key of the device.

[0037] In another embodiment of the present invention, the domain trust list can also be reissued and distributed to the verifier by the root key generation center according to a preset update cycle to reflect events such as domain parameter changes or domain revocation. In this embodiment, the domain trust list update cycle is recommended to be 1 to 7 days, which balances the freshness of cross-domain trust with distribution overhead. The shorter the cycle, the faster the propagation of domain parameter changes or domain revocation. It is supplemented by real-time updates triggered by events such as domain parameter changes and domain revocation to balance timeliness and bandwidth.

[0038] Step S4: The verifier receives the authentication message sent by the prover and, based on the domain trust list and the root public key, performs offline verification of the cross-domain prover without contacting the key generation center of the domain to which the prover belongs online.

[0039] This step includes offline pre-computation and online authentication response generation on the proof side, and knowledge proof verification, certificate-free binding verification, cross-domain offline trust retrieval, hierarchical permission credential verification, and anti-replay validity verification on the verification side.

[0040] Offline pre-computation: Before sending the authentication message, the proving party selects a temporary random number during idle or charging periods. The offline factor is pre-calculated by multiplying the random number with the first generator in the system parameters using a scalar multiplication operation. The random number and offline factors, along with their validity periods, are securely cached together. During this stage, several sets of offline factors can be pre-stored in batches. In this embodiment, the validity period of the offline factors is recommended to be 5 to 60 minutes: its lower limit should cover the typical interval from the terminal's idle period to the next access, to ensure the pre-calculated amortization benefit; its upper limit is used to limit the exposure window for the abuse of cached offline factors. The longer the validity period, the greater the risk of the factor being abused when the secure storage is compromised, so it should be significantly shorter than the key rotation cycle. The number of offline factor sets that can be pre-stored is recommended to be 8 to 64: its lower limit should cover the access peak between two idle windows, and its upper limit is limited by the terminal's secure storage capacity. Each set of factors needs to store one random number and one elliptic curve point, which should be determined by a trade-off between the terminal's storage capacity and access frequency.

[0041] Online authentication response generation: When the proving party receives an authentication challenge from the verifying party, consisting of a replay-protected random number and a timestamp. Then, a set of offline factors that have not expired are taken, and the authentication challenge is hashed using the national cryptographic standard SM3 to obtain the challenge value, i.e., the calculation is performed. And only by one modular multiplication and one modular addition, according to For group order The authentication response is obtained by taking the modulus as a scalar. The authentication response generation process does not involve pairing operations. The proving party then sends an authentication message, which includes an offline factor, the authentication response, a portion of the device's private key, the device identifier, the device's public value, hierarchical permission credentials, and a timestamp and a replay-protected random number.

[0042] Knowledge proof verification: The verifier calculates the challenge value. And verify the equation. Does this equation hold true? The fact that this equation holds true indicates that the proving party indeed possesses information related to the publicly available value of the equipment. Corresponding equipment secret value This prevents impersonation based solely on a portion of the device's private key.

[0043] Certificate-less binding verification and cross-domain offline trust retrieval: The verifier first determines the domain public value used for verification. If the prover and verifier are in the same domain, the domain public value of this domain is directly retrieved. If the prover and verifier are in different domains, the entry corresponding to the prover's domain is retrieved from the locally cached domain trust list. The entry signature is first verified using the root public key. After successful verification, the corresponding domain public value is retrieved from the entry. Subsequently, the pairing and binding relationship is verified. Whether it is valid. The entire process of cross-domain offline trust retrieval only queries the local cache list and verifies with the root public key, without needing to contact the key generation center of the domain to which the certifier belongs online.

[0044] Hierarchical permission credential verification and anti-replay validity verification: The verifier verifies the signature validity of the hierarchical permission credential, the validity period of its expiration time, and the consistency with the permission level. It also checks whether the difference between the timestamp in the authentication message and the local time is within a preset time window, whether the anti-replay random number has been recorded, and whether the offline factor has expired to defend against replay attacks. If all the above verifications pass, offline verification is successful and the corresponding level of permission is granted; if any one fails, access is rejected and an audit log is recorded.

[0045] In another embodiment of the present invention, a session key negotiation step is further included in the same authentication interaction that completes offline verification. Specifically, the gateway, acting as the authenticator, is itself a registered entity, which selects its own verification secret value according to the device registration process in step S2. And calculate its own public value When issuing authentication challenges, the verifying party should also include its own publicly available value. In the same authentication interaction where the verifier completes offline verification for the prover, the prover calculates a shared value based on the device secret value and the offline factor. It requires only one online dot product and still does not involve pairing operations; the verifier calculates the shared value based on the verification secret value. The two are equal; therefore, from The session key is derived, and subsequently, the proving and verifying parties use the session key and the national standard SM4 for symmetric encryption of subsequent communications. Thus, a single authentication interaction simultaneously completes identity authentication, cross-level authorization, and session key negotiation, unifying cross-domain security policies.

[0046] The following example of cross-domain access illustrates the complete execution process of steps S1 to S5 above. A certain group-type industrial internet platform adopts a three-layer structure. The group-level deployment of the root key generation center and the division of the park or factory level into domain A and domain B, with each domain key generation center and edge gateway deployed. A low-computing-power industrial sensor terminal in domain A needs to cross-domain access to the edge gateway of domain B as a proof party. In step S1, the root key generation center generates the root master key and system parameters and publishes the root public key. The domain key generation centers of domain A and domain B each select their own domain secret value and calculate their respective domain public value. In step S3, the root key generation center signs the domain identifiers and domain public value entries of the two domains, generates a domain trust list, and distributes it to the gateway caches of domain A and domain B. In step S2, the terminal of domain A selects its own secret value, calculates its device public value, and submits it. The domain key generation center of domain A calculates the binding hash and issues a partial private key and hierarchical permission certificate for the device, such as read / write permission level and 7-day validity period. The terminal uses this to synthesize the complete private key of the device. Subsequently, the terminal pre-stores several sets of offline factors when idle, such as 16 sets with a validity period of 30 minutes. In the cross-domain online authentication in step S4, the terminal of domain A initiates access to the gateway of domain B. The gateway issues a challenge consisting of a replay-protected random number and a timestamp, along with its own public value. The terminal takes a set of offline factors, calculates the challenge value and authentication response, and then sends the authentication message. The gateway of domain B first verifies the knowledge proof equation. After determining that the certifier belongs to domain A (i.e., cross-domain), the entry for domain A is retrieved from the cache list. The signature of the entry is verified using the root public key, and the domain public value of domain A is retrieved to verify the pairing and binding relationship. Then, the validity and level of the hierarchical permission credentials are verified, and the timestamp and anti-replay random number are checked. No online interaction occurs with the domain key generation center of domain A throughout the entire process. Finally, the session key is exported by both parties in step S5 and the communication is encrypted with SM4.

[0047] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; only preferred embodiments of the present invention are illustrated. The descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. As long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0048] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this invention should be determined by the appended claims.

Claims

1. A cross-level security authentication method for the Industrial Internet based on a certificate-free cryptographic system, wherein the Industrial Internet comprises, from top to bottom, a group-level system with a root key generation center, a park or factory-level system with a domain key generation center and a verifier, and a device or terminal-level system with industrial terminals acting as certifiers, characterized in that, Includes the following steps: Step S1: The root key generation center generates system parameters, a root master key, and a root public key, and issues a domain partial key for the domain identifier. The domain key generation center selects a domain secret value and generates a domain public value. The domain master key is composed of the domain partial key and the domain secret value. In step S2, the proving party selects a device secret value and generates a device public value, submits the device identifier and the device public value to the domain key generation center, and the domain key generation center issues a partial private key for the device based on the domain secret value. The proving party then uses the device secret value and the partial private key to form the complete private key for the device. Step S3: The root key generation center uses the root identifier to identify and sign the entry containing the domain identifier and the domain public value to obtain the entry signature, and distributes the domain trust list composed of the entry and the entry signature to the local cache of the verifier. Step S4: The verifier receives the authentication message sent by the prover, and performs offline verification of the cross-domain prover based on the domain trust list and the root public key, without contacting the key generation center of the domain to which the prover belongs online.

2. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 1, characterized in that, In step S4, before the provider sends the authentication message, the provider pre-calculates the offline factor and caches it; Upon receiving the authentication challenge, the proving party generates an authentication response based solely on the cached offline factor, the device secret value, and the authentication challenge using only hash operations, modular multiplication operations, and modular addition operations. The authentication message includes the offline factor, the authentication response, the device partial private key, the device identifier, and the device public value.

3. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 2, characterized in that, The offline factor is an elliptic curve point pre-calculated and cached by the prover using a scalar multiplication operation between a random number and the first generator in the system parameters. The challenge value of the authentication challenge is obtained by hashing the authentication challenge using SM3, and the authentication response is a scalar obtained by modular multiplication and modular addition of the random number, the challenge value, and the device secret value.

4. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 1, characterized in that, The domain key generation center uses a domain signature private key to identify and sign information containing the device identifier, permission level, update generation and expiration time, and issues hierarchical permission credentials that are independent of the complete private key of the device. The authentication message also includes the hierarchical permission credentials; The offline verification in step S4 also includes verifying the signature validity of the hierarchical permission credential, the timeliness of the expiration time and the consistency with the hierarchy of the permission level, and ensuring that the update of the hierarchical permission credential does not affect the complete private key of the device.

5. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 2, characterized in that, The method further includes step S5, in the same authentication interaction in which the verifier completes the offline verification for the certifier, the certifier calculates the same shared value based on the device secret value and the offline factor, and the verifier calculates the same shared value based on the verification secret value of the verifier, and derives a session key from the shared value using a key, and the certifier and the verifier use the session key and SM4 to perform symmetric encryption on subsequent communications.

6. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 1, characterized in that, The identifier signature uses an SM9 identifier signature; in step S2, the domain key generation center issues the device partial private key based on the domain secret value and the binding hash obtained by SM3 from the device identifier and the device public value. The device partial private key, the binding hash, and the domain public value satisfy a pairing binding relationship: ； in This is a partial private key for the device. For the binding hash, The public value of the domain, and These are the first generator and the second generator in the system parameters, respectively; the verifier verifies the pairing and binding relationship when performing the offline verification on the prover.

7. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 3, characterized in that, In step S4, when the verifier performs the offline verification on the prover, the verification equation is... Whether it is valid, among which For the authentication response, This is the first generator in the system parameters. For the offline factor, The challenge value is... The device is publicly disclosed to verify that the certifying party holds the device's secret value.

8. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 2, characterized in that, The authentication message also includes a timestamp and a replay-protected random number. In step S4, the verifier checks whether the difference between the timestamp and the local time is within a preset time window during the offline verification, and checks whether the replay-protected random number has not been recorded, in order to defend against replay attacks.

9. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 1, characterized in that, The domain trust list is reissued by the root key generation center and distributed to the verifiers according to a preset update cycle.

10. The industrial internet cross-level security authentication method based on a certificateless cryptographic system according to claim 1, characterized in that, In step S4, when the verifier performs offline verification on the cross-domain prover, it retrieves the entry corresponding to the domain to which the prover belongs from the locally cached domain trust list, first verifies the entry signature of the retrieved entry with the root public key, and then obtains the corresponding domain public value from the retrieved entry for verification of the prover.

Images