Lightweight certificateless identity authentication method and system based on IBC

Abstract

The invention discloses a lightweight certificateless identity authentication method and system based on IBC, and belongs to the technical field of unmanned aerial vehicle security. Comprising the following steps: step 1, establishing a lightweight certificateless identity authentication system based on IBC, and performing user registration, key generation and storage; 2, sending the key pair data and the identity identifier to the client; 3, encrypting, decrypting, signing and verifying the secret key pair data; and step 4, sending encryption, decryption, signature and verification requests to the server side, and receiving a result returned by the server side to complete certificateless identity authentication. According to the method, a unique identity identifier can be allocated to each user, and a public and private key pair stored in a local database is generated based on the identity identifier, so that the problem that the unmanned aerial vehicle cannot form a wireless communication security closed loop in the traditional public key management technology is solved; therefore, the problems of difficulty in identity verification, low calculation speed and difficulty in adapting to key generation, distribution and application of large-scale equipment application are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of UAV security, and in particular to a lightweight certificateless identity authentication method and system based on IBC. Background Art

[0002] Nowadays, various UAV swarms are playing an increasingly important role in modern society. They are often used in application scenarios such as disaster prevention and relief and modern agriculture. In such application scenarios, UAV swarms often need to respond quickly and work collaboratively, which requires the public key management scheme to have the following characteristics: 1. Privacy protection: Since the scale of the UAV swarm may be large, it is inevitable to collect sensitive information of the public after being distributed to the mission area. Therefore, it is particularly important to protect user privacy and avoid the leakage of sensitive data without disclosing user identity information. 2. Security: In applications such as disaster prevention and relief, UAV swarms may carry sensitive data, such as disaster monitoring information, etc. Therefore, it is necessary to ensure the security and integrity of the data; the public key management scheme needs to provide a strong encryption mechanism to prevent the data from being tampered with or leaked during transmission. 3. Scalability: In modern agriculture, UAV swarms may need to cover a wide range of farmland, which requires the public key management scheme to support the joining and leaving of a large number of nodes, while maintaining efficient communication and key management. 4. Decentralization: In order to avoid single-point failures, the public key management scheme needs to adopt a decentralized architecture to ensure that the system can still operate continuously when a single node fails. 5. Lightweight: Due to the limited hardware resources of UAVs, the public key management scheme needs to be lightweight to reduce the consumption of computing resources and energy.

[0003] As the core support for UAV security collaboration, public key management technology can effectively ensure the security of UAV swarm collaborative operations. However, currently in UAVs, although some UAVs have enabled data encryption functions, access authentication and key management with identity authentication are generally not carried out, so a wireless communication security closed-loop has not been formed, resulting in problems such as difficult identity verification, slow calculation speed, and difficulty in adapting to key generation, distribution, and application for large-scale equipment applications, seriously affecting the flight control security of UAVs and the security of the transmitted information.

[0004] Based on this, the present invention proposes a lightweight certificateless identity authentication method and system based on IBC to solve the problems existing in the above-mentioned prior art. Summary of the Invention

[0005] In view of this, the main purpose of the present invention is to provide a lightweight certificateless identity authentication method and system based on IBC to solve the problems that UAVs using traditional public key management technology fail to form a wireless communication security closed-loop, resulting in difficult identity verification, slow calculation speed, and difficulty in adapting to key generation, distribution, and application for large-scale equipment applications.

[0006] The technical solution of the present invention is realized as follows:

[0007] The present invention provides a first solution: a lightweight certificateless identity authentication method based on IBC, including:

[0008] Step 1: Build a lightweight certificateless identity authentication system based on IBC, and use the server side of the system for user registration, key generation and storage;

[0009] Step 2: Send the key pair data and identity identifier generated during the server-side registration process to the client through the interaction end;

[0010] Step 3: The client encrypts, decrypts, signs and verifies the key pair data;

[0011] Step 4: After the client encrypts, decrypts, signs and verifies the key pair data, send requests for encryption, decryption, signature and verification to the server side through the interaction end, and receive the results returned by the server side to complete the certificateless identity authentication.

[0012] In a preferred embodiment, the process of user registration and key generation in Step 1 includes:

[0013] Step 1011: During registration, the user selects a random number t ∈ i , q , i , R Z q , calculates T and Q according to the system parameters to obtain the identity identifier ID i ;

[0014] Where: T = t·P, Q = H(ID), H represents the hash operation, P represents the bilinear pair operation, ID represents the user identity, and i represents each user;

[0015] Step 1012: The user registers the identity identifier ID offline with the digital certificate registration system LRA i =<Q, T>;

[0016] Step 1013: The digital certificate registration system LRA submits the user registration information to the private key generator PKG;

[0017] Step 1014: The private key generator PKG saves the user registration information as a voucher for the user to apply for the identity private key, and completes the user registration;

[0018] Step 1015: After the user registration is completed, the server generates a key using the key derivation algorithm based on IBC.

[0019] In a preferred embodiment, the process of encrypting, decrypting, signing and verifying the key pair data in Step 3 includes:

[0020] Step 301: Encrypt and decrypt the key pair data;

[0021] Step 302: After encrypting and decrypting the key pair data in Step 301, sign and verify the key pair data;

[0022] Step 303: After encrypting and decrypting the key pair data in Step 301, verify the self-signed public key of the key pair data.

[0023] In a preferred embodiment, the process of encrypting and decrypting the key pair data in Step 301 includes:

[0024] Step 3011: System initialization

[0025] Step 30111: The client server selects groups of prime order q, namely the additive groups G1, G2 and the multiplicative group G T , and a non-degenerate bilinear mapping e: G1×G2→G T , and selects a generator P1∈G1, P2∈G2, a hash algorithm H and an identifier hid represented by one byte;

[0026] Step 30112: Use the random number s generated by the system as the system encryption master private key, and calculate P pub and g;

[0027] Step 3012: Generate user key pairs

[0028] Step 30121: The user selects a random number x as the user's partial private key, and calculates the user's public key PK;

[0029] Step 30122: The user uses the user identity ID and the user's public key PK to apply to the server for the partial SM9 private key. The server calculates h ID ;

[0030] If (h ID +s) mod q = 0, then output an error, and the system regenerates the encryption master key; otherwise output d ID = s(h ID +s) -1 P2;

[0031] Step 30123: After the user gets the d ID returned by the server, calculate the user's private key SK using x, and save it;

[0032] Step 3013: Encryption process

[0033] Step 30131: After the sender receives the user's public key PK, calculate the encryption public key E PK ;

[0034] Step 30132: Randomly select an integer r, and calculate C1 and w;

[0035] Step 30133: Calculate K = K1||K2. If K1 is all 0s, then return to Step 30132;

[0036] where K1 is the leftmost Mlen bits of K, Mlen is the length of the message M, and K2 is the remaining bits of K;

[0037] Step 30134: Calculate C2 and C3, and output the ciphertext C1, C2, and C3 and send them to the decryptor;

[0038] Step 3014: Decryption process

[0039] When the decryptor receives the ciphertext C1‘, C2‘, C3‘:

[0040] Step 30141: Verify whether C1‘ is an element in the group G1. If not, then report an error and exit;

[0041] Step 30142: Calculate w' and K' = K1'||K2'. If K1' is all 0s, then report an error and exit;

[0042] Step 30143: Calculate M' and C3". If C3" is inconsistent with C3‘, then report an error and exit.

[0043] In a preferred embodiment, during the decryption process, it further includes verifying the correctness of decryption, including:

[0044]

[0045] In a preferred embodiment, the process of signing and verifying the key pair data described in Step 302 includes:

[0046] Step 3021: System initialization

[0047] Step 30211: The client server selects groups of prime order q, namely the additive group G1, G2, and the multiplicative group G T , and a non-degenerate bilinear mapping e: G1×G2→G T , and selects a generator P1∈G1, P2∈G2, hash algorithms H1, H2, and an identifier hid represented by one byte;

[0048] Step 30212: The system generates a random number ks as the main private key for system signature, and calculates P pub ;

[0049] Step 3022: Generate user keys

[0050] The user identity of user A is IDA The server calculates t1;

[0051] If t1 = 0, a new system signature master private key is generated; if not, calculate t2 = ks·t1 -1 The private signature key ds of user A A = [t2]P1;

[0052] Step 3023: User signature process;

[0053] Step 30214: Verify the signature.

[0054] In a preferred embodiment, the user signature process includes:

[0055] Let the message to be signed be the bit string M, and the signer A should implement the following operation steps:

[0056] (1) Calculate G T The element g = e(P1, P pub ) in it;

[0057] (2) Select a random number r and calculate the element w = g T in G r ;

[0058] (3) Calculate h = H2(M||w, q);

[0059] (4) Calculate l = r - h mod q;

[0060] (5) Calculate S = [l]ds A , and take (h, S) as the signature.

[0061] In a preferred embodiment, the signature verification process includes:

[0062] The verifier receives the message M' and its signature (h‘, S’):

[0063] (1) Calculate G T The element g = e(P1, P pub ) in it

[0064] (2) Calculate the element t = g T in G h

[0065] (3) Calculate h1 = H1(M||w, q), and the element P = [h1]P2 + P in G2 pub

[0066] (4) Calculate the elements u, w‘ in G T , u = e(S’, P), w‘ = u·t

[0067] (5) Calculate h2 = H2(M'||w', q), and verify h2 and h'. If the two are consistent, the verification passes.

[0068] In a preferred embodiment, the process of self-signature public key verification for the key pair data in step 303 includes:

[0069] Step 3031: System initialization

[0070] Step 30311: The server selects groups of prime order q, namely additive groups G1, G2, and multiplicative group G T , and a non-degenerate bilinear mapping e: G1×G2→G T , and selects generators P1∈G1, P2∈G2, and hash algorithms H1, H2;

[0071] Step 30312: The system generates a random number s as the system master private key, and calculates P pub = [s]P1 and publishes these system parameters;

[0072] Step 3032: Generate user keys

[0073] Step 30321: Identify the user identity of user A as ID A , and the server calculates the user A identity public key Calculate the user A identity private key using the system master key s The PKG sends the identity private key to user A through a secure channel;

[0074] Step 30322: User A selects a random parameter x ID , and constructs the user key

[0075] where

[0076] Step 3033: Generate a self-signature public key

[0077] User A selects a random number r, signs the user public key using the identity private key, and constructs the self-signature public key

[0078] where,

[0079] Step 3034: Verify the self-signature public key

[0080] Step 30341: Calculate h, Q;

[0081] Step 30342: Verify e(P1, V ID ) = e(P pub , Q), to achieve self-signature public key verification.

[0082] The present invention provides a second solution: a lightweight certificateless identity authentication system based on IBC, including:

[0083] A server side, which is used to generate and manage the public-private key pair of a user after the user registers, and provide corresponding interfaces for the user to obtain and update the key;

[0084] A client side, as the user's terminal device, is responsible for the encryption, decryption, signature and verification operations of the key pair data;

[0085] An interaction side, which is used to perform the interaction between the server side and the client side to realize user registration, key generation and security operations;

[0086] Wherein, the server side, the client side and the interaction side are all implemented based on the method described in any one of claims 1-9.

[0087] Compared with the prior art, the present invention provides a lightweight certificateless identity authentication method and system based on IBC, having the following beneficial effects:

[0088] 1. Privacy protection. The present invention uses encryption technology to protect the privacy of user identities and communication content; the user's identity information is only generated and stored by the KGC during registration, while in daily communication, the user can use his own identity identifier for anonymous communication, avoiding the exposure problem of certificates in traditional PKI.

[0089] 2. Security. The present invention uses bilinear pairing cryptographic tools to ensure the uniqueness of user identities and the security of key exchange; at the same time, by regularly updating keys and monitoring system activities, potential security threats are reduced.

[0090] 3. Scalability. The present invention designs a flexible system architecture that can support the large-scale deployment and dynamic expansion of drone swarms. Newly added drones can be quickly integrated into the system without reconfiguring the entire network.

[0091] 4. Decentralization. The present invention uses blockchain technology to achieve decentralized management of public keys; the distributed characteristics of the blockchain ensure that there is no central authority in the system, but a ledger is jointly maintained by multiple nodes in the network, improving the reliability and anti-attack ability of the system.

[0092] 5. Lightweight. The present invention reduces the computational and communication overhead through optimized algorithms and protocols. For example, efficient encryption and hash algorithms, as well as a simplified authentication mechanism are used, thereby reducing the demand for the computing resources of drones. It solves the problems in traditional public key management technology that drones fail to form a wireless communication security closed loop, resulting in difficult identity authentication, slow computing speed, and difficulty in adapting to key generation, distribution and application in large-scale equipment applications. Description of the Drawings

[0093] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained according to these drawings.

[0094] Figure 1 It is a flowchart of the lightweight certificateless identity authentication method based on IBC of the present invention;

[0095] Figure 2 It is a screenshot of the system initialization experiment in Embodiment 2 of the present invention;

[0096] Figure 3 It is a screenshot of the self-signed public key generation experiment in Embodiment 2 of the present invention. Detailed implementation manners

[0097] The following further elaborates in detail on the structure and process of the lightweight certificateless identity authentication method and system based on IBC in combination with the accompanying drawings and the embodiments of the present invention.

[0098] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0099] Embodiment 1:

[0100] As Figure 1 shown, the present invention provides a lightweight certificateless identity authentication method based on IBC, including the following steps:

[0101] Step 1: Build a lightweight certificateless identity authentication system based on IBC, and use the server side of the system for user registration, key generation, and storage; specifically including:

[0102] Step 101: Conduct user registration, and during the user registration process, generate a pair of public and private key pairs, store them in the local database, and store and manage the public and private key pairs;

[0103] Step 102: After obtaining the public and private key pairs, the server generates corresponding key pairs according to the identity identifiers of the corresponding public and private key pairs, and returns the key pairs to the client of the user;

[0104] Among them, the key pairs generated in this step are used for subsequent encryption, decryption, and signature operations;

[0105] Step 2: Send the key pair data and identity identifiers generated during the server-side registration process to the client through the interaction end;

[0106] Step 3: The client performs encryption, decryption, signature, and verification operations on the key pair data transmitted back by the server; specifically including:

[0107] Step 301: Use the client to perform encryption and decryption operations on the key pair data returned by the server;

[0108] Step 302: After performing encryption and decryption on the key pair data in Step 301, perform signature and verification operations on the key pair data;

[0109] Step 303: After performing encryption and decryption on the key pair data in Step 301, perform self-signature public key verification operation on the key pair data;

[0110] Step 4: After the client performs encryption, decryption, signature, and verification operations on the key pair data, send requests for encryption, decryption, signature, and verification to the server through the interaction end, and receive the results returned by the server to complete the certificate-free identity authentication.

[0111] It should be noted that in the above description, the IBC-based lightweight certificate-free identity authentication system is a lightweight centerless certificate-free system. The lightweight centerless certificate-free system can reduce complexity, improve efficiency, and reduce the dependence on the central server, thereby providing a more secure and reliable communication method. At the same time, the IBC-based lightweight certificate-free identity authentication system described in this embodiment enables users to perform secure encryption, decryption, signature, and verification operations without relying on a third-party certificate authority.

[0112] In a preferred embodiment, in Step 101 when the user registers, user registration is the first step of the system. When registering, the server can generate a pair of public and private key pairs and store them in the local database; this process uses IBC-based identity recognition technology to ensure the uniqueness and security of the user identity; at the same time, the server also generates a unique identity identifier for each user, and this identifier will be used in the subsequent key generation and identity verification processes.

[0113] Specifically, the specific process of user registration and public and private key pair generation in Step 101 includes:

[0114] Step 1011: When registering, the user selects a random number t ∈ R Z q (which means randomly selecting an integer t in the finite field of the integer ring modulo q), calculates T (user identity private key) and Q (user identity public key) according to the system parameters, and obtains a unique identity identifier ID i , so as to confirm the user's identity in the subsequent communication process;

[0115] Where: T = t·P, Q = H(ID), H represents the hashing operation, P represents the bilinear pairing operation, ID represents the user identity identifier, and i represents each user;

[0116] Step 1012: The user registers the identity identifier ID with the digital certificate registration system LRA in an offline manner i = <Q, T>;

[0117] Step 1013: The digital certificate registration system LRA securely delivers the user registration information to the private key generator PKG;

[0118] Step 1014: The private key generator PKG saves the user registration information as a voucher for the user to apply for the identity private key, and completes the user registration;

[0119] Step 1015: After the user registration is completed, the server uses the IBC-based key derivation algorithm to generate keys for subsequent key pair generation and user authentication.

[0120] It should be noted that in the above description, when the user needs to perform encryption or signature operations, the server will generate corresponding key pairs according to its identity identifier; these key pairs will be used for subsequent encryption, decryption, and signature operations. Among them, in the public-private key pair (key pair), the server master private key is generated by the random number generator in the server, and the master public key is generated by combining the master private key with the system parameters. In the process of key pair generation, using the IBC-based key derivation algorithm to generate keys can effectively ensure the security and uniqueness of the keys. The generation and management of key pairs are one of the core functions of the system, which guarantees the confidentiality and integrity of user data.

[0121] In a preferred embodiment, the principle of the client in step 301 performing encryption and decryption operations on the key pair data returned by the server is as follows: The user uses the generated key pair data for encryption and decryption operations; the encryption operation converts the user data into ciphertext, which guarantees the security of the data during transmission and storage; the decryption operation restores the ciphertext to plaintext, ensuring the readability and integrity of the user data; the entire process uses the encryption and decryption algorithms in the BF-IBE scheme, and these operations are all performed on the client side without relying on any third-party certificates, improving the flexibility and security of the system.

[0122] Specifically, the process of the client in step 301 performing encryption and decryption operations on the key pair data returned by the server includes:

[0123] Step 3011: System initialization

[0124] Step 30111: The client server selects groups of prime order q, namely the additive group G1, G2, and the multiplicative group G T, and a non - degenerate bilinear mapping e: G1×G2→G T , and select a generator P1∈G1, P2∈G2, a hash algorithm H, and an identifier hid represented by one byte;

[0125] Step 30112: Use the random number s generated by the system as the system's encryption master private key, calculate the system's public key P pub =[s]P1 and the bilinear mapping result (for subsequent encryption operations) g = e(P pub ,P2), and disclose these system parameters;

[0126] Step 3012: Generate a user key pair

[0127] Step 30121: The user selects a random number x as the user's partial private key, and calculates the user's public key PK, PK=(PK1,PK2)=(xP1,xP pub );

[0128] Step 30122: The user uses the user identity ID and the user's public key PK to apply to the server for the partial SM9 private key. The server calculates h ID =H(ID||PK||hid); If (h ID +s) mod q = 0, then output an error, and the system regenerates the encryption master key; otherwise, output the user's partial private key d ID =s(h ID +s) -1 P2;

[0129] Step 30123: After the user obtains the d ID returned by the server, use x to calculate the user's private key SK, SK = x -1 s(h ID +s) -1 P2 and keep it secret;

[0130] Step 3013: Encryption process

[0131] Step 30131: After the sender receives the user's public key PK, calculate the encryption public key E PK =[h ID PK1+PK2;

[0132] Step 30132: Randomly select an integer r, calculate the first - part ciphertext C1 = rE PK , the power operation of the bilinear mapping, used to generate the encryption key w = g r ;

[0133] Step 30133: Calculate K = KDF(C1||w||ID)=K1||K2. If K1 is all 0, then return to Step 30132;

[0134] Among them, K is the derived key, which is divided into two parts; K1 is the leftmost Mlen bits of K, Mlen is the length of the message M, and K2 is the remaining bits of K;

[0135] Step 30134: Calculate C3 = MAC(K2, C2), output the ciphertext C1, C2, C3 and send them to the decryptor;

[0136] Step 3014: Decryption process

[0137] When the decryptor receives the ciphertext C1‘, C2‘, C3‘, perform the following calculations to obtain the plaintext:

[0138] Step 30141: Verify whether C1‘ is an element in the group G1. If not, report an error and exit;

[0139] Step 30142: Calculate w' = e(C1‘, SK), K' = KDF(C1‘||w'||ID) = K1'||K2'. If K1' is all 0, report an error and exit; w' and K' respectively represent the calculated values of w and K by the decryptor;

[0140] Step 30143: Calculate C3" = MAC(K2', C2’). If C3" is inconsistent with C3‘, report an error and exit;

[0141] Verifying the correctness of decryption (i.e., whether M' is consistent with M, meaning whether the calculated value is equal to the true value) depends on whether w is consistent with w'. The proof is as follows:

[0142]

[0143] In a preferred embodiment, the principle of signing and verifying the key pair data after encrypting and decrypting the key pair data in step 302 includes: during the user registration process, the server generates a public-private key pair for each user and stores it in the local database; when the user needs to perform a signing operation, the server generates a corresponding key pair according to the user's identity identifier and transmits the private key to the user side; the user can use the private key to sign the data, generate a digital signature, and send it to the recipient; after the recipient receives the data and the digital signature, verify the validity of the digital signature through the public key; this process realizes the function of centerless and certificate-free digital signature; the principle of the verification process includes: after the user receives the data and the digital signature, the user can verify the validity of the digital signature through the public key, thereby confirming the integrity and authenticity of the data. The server side does not participate in the verification process, which is completely completed by the user side, realizing the function of centerless and certificate-free digital signature verification.

[0144] Specifically, after encrypting and decrypting the key pair data in step 301 as described in step 302, the process of signing and verifying the key pair data includes:

[0145] Step 3021: System initialization

[0146] Step 30211: The client server selects groups of prime order q, namely the additive groups G1, G2 and the multiplicative group G T , and a non-degenerate bilinear map e: G1 × G2 → G T , and selects generators P1 ∈ G1, P2 ∈ G2, hash algorithms H1, H2 and an identifier hid represented by one byte;

[0147] Step 30212: The system generates a random number ks as the main private key for system signature, and calculates P pub = [ks]P1 and publishes these system parameters;

[0148] Step 3022: Generate user keys

[0149] Identify the user identity of user A as ID A , the server calculates t1 = H1(ID A ||hid, q) + ks, if t1 = 0, then regenerate the main private key for system signature; if not 0, then calculate t2 = ks · t1 -1 , the signature private key ds of user A A = [t2]P1;

[0150] Step 3023: User signature process

[0151] Let the message to be signed be the bit string M, and the signer A should implement the following operation steps:

[0152] (1) Calculate the element g in G T = e(P1, P pub );

[0153] (2) Select a random number r and calculate the element w in G T = g r ;

[0154] (3) Calculate the hash result h = H2(M||w, q); for signature generation

[0155] (4) Calculate the signature parameter l = r - h mod q;

[0156] (5) Calculate S = [l]ds A , and take (h, S) as the signature;

[0157] Step 30214: Verify the signature

[0158] The verifying party receives the message M' and its signature (h ‘ , S ’ )

[0159] (1) Calculate g in G T where g = e(P1, P pub )

[0160] (2) Calculate t in G T where t = g h‘

[0161] (3) Calculate h1 = H1(M || w, q), and the element P in G2 is P = [h1]P2 + P pub

[0162] (4) Calculate the elements u, w' in G T where u = e(S', P), w' = u · t

[0163] (5) Calculate h2 = H2(M' || w', q), and check h2 and h'. If they are the same, the verification passes;

[0164] In the above process, after receiving the data and digital signature, the user can verify the validity of the digital signature through the public key, thereby confirming the integrity and authenticity of the data. The server side does not participate in the verification process, which is completely completed by the user side, realizing the digital signature verification function without a center and without certificates. The experiment has conducted various tests on the verification function, including verification speed, verification efficiency, and system scalability.

[0165] In a preferred embodiment, the principle of the self-signed public key verification operation on the key pair data after encrypting and decrypting the key pair data in step 303 includes: Due to reasons such as the key revocation problem existing in traditional IBC, since the user identity public key is "bound" to the user identity identifier, and most user identity identifiers are fixed or not allowed to be changed, it is impossible to update or revoke the user key; after the user identity identifier changes, since the identity private key corresponding to the original identity identifier cannot be changed, the user can still master the original identity private key, resulting in the problem of forward security of communication; to solve the key revocation problem, the idea of hierarchical key management is adopted. While the user masters the identity key generated by the PKG, the user freely selects the key in the public key cryptosystem as the user key for encryption, decryption, or signature verification; the user uses the signature algorithm in IBC to sign the user public key with the identity private key, constructing and publishing the self-signed public key.

[0166] Specifically, the self-signed public key verification operation described in step 303 consists of two parts: the user public key and the signature result of the public key. The specific algorithm is as follows:

[0167] Step 3031: System initialization

[0168] Step 30311: The server selects groups of prime order q, namely additive groups G1, G2 and multiplicative group G T , and a non-degenerate bilinear map e: G1×G2→G T , and selects generators P1∈G1, P2∈G2, and hash algorithms H1, H2;

[0169] Step 30312: The system generates a random number s as the system master private key, and calculates P pub =[s]P1 and publishes these system parameters;

[0170] Step 3032: Generate user keys

[0171] Step 30321: Identify the user identity of user A as ID A , and the server calculates the public key of user A's identity calculates the private key of user A's identity using the system master key s PKG sends the identity private key to user A through a secure channel;

[0172] Step 30322: User A selects a random parameter x ID , and constructs the user key where the user public key user private key

[0173] Step 3033: Generate a self-signed public key

[0174] User A selects a random number r, signs the user public key using the identity private key, and constructs the self-signed public key where,

[0175] Step 3034: Verify the self-signed public key

[0176] Step 30341: Calculate

[0177] Step 30342: Verify e(P1, V ID )=e(P pub , Q), to achieve the verification of the self-signed public key;

[0178] The self-signed public key is constructed by signing the user's public key with the identity private key. Therefore, the authenticity of the self-signed public key can be verified by the user's identity public key; the authenticity of the user's identity public key is guaranteed by the user's identity identifier. Therefore, the authenticity of the user's self-signed public key can be guaranteed by the user's identity identifier; the self-signed public key contains the information of the user's public key. Therefore, the authenticity of the user's public key can also be guaranteed by the user's identity identifier; the user's key is freely selected by the user, and there is no "binding" relationship between the user's public key and the user's identity identifier. Therefore, the user's key can be updated or revoked. After the user's identity identifier changes, since the user's private key corresponding to the original identity identifier can be changed, there is no forward security problem for communication; in summary, the self-signed public key generation algorithm based on IBC inherits the simple feature of identity public key authentication in IBC, realizes the independent update of the user's key, and solves the key revocation problem existing in the application of IBC.

[0179] The lightweight certificate-free public key management method based on IBC described in this embodiment realizes the decentralized management of public keys by utilizing the distributed characteristics of the blockchain, without relying on traditional certificate issuing authorities; through lightweight design, it greatly reduces the system resource consumption, improves the efficiency, and is especially suitable for applications on resource-constrained devices; at the same time, it also enhances the security and scalability of the system, providing an effective way to build a secure certificate-free communication environment.

[0180] A lightweight certificate-free identity authentication system based on IBC for implementing the lightweight certificate-free identity authentication method based on IBC as described above in this embodiment includes a server side, a client side, and an interaction side; wherein:

[0181] The server side is used to generate and manage the public and private key pairs of the user after the user registers, and provide corresponding interfaces for the user to obtain and update the keys;

[0182] The client side, as the user's terminal device, is responsible for operations such as encryption, decryption, signature, and verification of key pair data;

[0183] The interaction side is used to conduct the interaction between the server side and the client side to realize user registration, key generation, and security operations.

[0184] It should be noted that in the above description, when this system is in use, user registration, key generation, and storage are carried out through the server side. After user registration and key generation are completed, the public-private key pair and identity identifier generated during the server-side registration process are sent to the client; then the client performs encryption, decryption, signature, and verification operations on the key pair data transmitted back by the server side; after the client's encryption, decryption, signature, and verification operations on the key pair data, requests for encryption, decryption, signature, and verification are sent to the server side through the interaction side, and the results returned by the server side are received to complete the certificate-free identity authentication.

[0185] In a preferred embodiment, in the interaction side, an encrypted communication and identity authentication mechanism is adopted to ensure the security of data transmission and the legitimacy of user identities during the communication process.

[0186] In a preferred embodiment, on the server side, when a user joins the system or the identity changes, the server can regenerate the corresponding key pair and notify the user to update it; while when a user exits the system or the identity is revoked, the server can promptly revoke the corresponding key pair to ensure the security of the system and data privacy.

[0187] Example 2:

[0188] Different from the above Example 1, as Figure 2 and Figure 3 shown, to verify the feasibility of the lightweight certificate-free identity authentication method based on IBC established in the above Example 1, a test system for lightweight certificate-free identity authentication based on IBC is built through this example for verification.

[0189] 1. Performance Test Environment Setup

[0190] The setup of the experimental environment will include server-side and client-side configurations, as well as relevant hardware and software support. In addition, the support environment of hardware and software needs to be considered. In terms of hardware, servers and client devices with stable performance are selected and ensured to meet the requirements of performance testing. In terms of software, open-source encryption algorithm libraries and network communication libraries are used to support functions such as encryption, decryption, signature, and verification of the system.

[0191] (1) Server-Side Configuration

[0192] On the server side, the Linux operating system is selected as the basic environment, and a lightweight server application program is used to simulate the functions of public key management and user identity authentication. The configuration is shown in Table 1;

[0193] Table 1: Server-Side Configuration

[0194]

[0195] The server program will be responsible for generating and managing the public-private key pairs of users and generating a unique identity identifier for each user. Meanwhile, the server will provide services such as key generation, encryption, decryption, signature, and verification.

[0196] (2) Client Configuration

[0197] On the client side, the Linux operating system is also selected as the basic environment. The client will serve as the user's terminal device for operations such as encryption, decryption, signature, and verification. The software installation and configuration process of the client can ensure effective communication with the server side and complete various operations required for performance testing. Its specific configuration is shown in Table 2:

[0198] Table 2: Client Configuration

[0199]

[0200] 2. Encryption, Decryption Speed and Efficiency Testing

[0201] The server side is responsible for generating and managing the public-private key pairs of users, while the client is used for operations such as encryption, decryption, and signature. In this embodiment, the experiment selects the bilinear mapping parameter initialization system in the PBC library and checks the symmetry of the mapping. There are many types of bilinear mappings provided by the library, and different types of bilinear mapping parameters have different characteristics. When selecting bilinear mapping parameters in this embodiment, only the types where the order of the group and the order of the field in the bilinear mapping are close are considered. For example, type A bilinear mapping is the fastest. Type C bilinear mapping is vulnerable to the Coppersmith attack in low characteristic fields, so its practicality is reduced. The elements type variables in type D are very short, while the running time is extended by 2 to 5 times. The elements type variables in type are even shorter, and the running time is extended by 10 times compared to type. The difference in running speed is related to the hardware environment and whether precomputation is performed.

[0202] Taking into account the characteristics of the existing bilinear mapping parameters, this embodiment selects the fastest type A bilinear mapping parameters; the bilinear mapping of type A is constructed by the elliptic curve y q on the prime field F 2 =x 3 +x; in order to obtain the non-degenerate characteristic of the bilinear mapping, the mapping is adopted as: G1×G2→G T ; where G1 and G2 are both elliptic curves on the prime field;

[0203] E(F q ) the group composed of points on, G T is a subgroup of the finite field ;

[0204] q is a prime number such that q = -1 mod 12; Through experimental verification, the A-type bilinear mapping is a symmetric bilinear mapping, and the elliptic curve adopted is 512 bits;

[0205] Use elliptic curve cryptography to implement the key generation and signature verification functions required by the IBC technology to improve the efficiency and security of the system;

[0206] After the bilinear mapping parameters are determined, this embodiment conducts experiments on the BF-IBE scheme, the self-signed IBC public key generation algorithm scheme, and the self-signed ECC public key generation algorithm scheme respectively. The parameters selected for the experiment are as follows:

[0207] (1) The A-type bilinear mapping is selected for the experiment;

[0208] (2) The identity public key is directly generated by hashing the string "shenfen";

[0209] (3) The encrypted data is represented in the form of the string "mingwen";

[0210] (4) In the actual application environment, other parameters can be selected according to needs for replacement.

[0211] 3. Encryption and decryption speed test

[0212] This embodiment uses the PBC library for programming to verify the BF-IBE scheme, the self-signed IBC public key generation algorithm, and the self-signed ECC public key generation algorithm; The experimental process consists of four stages: "system initialization", "identity key generation", "self-signed public key generation", and "encryption and decryption":

[0213] (1) System initialization

[0214] In the "system initialization" stage, the experimental processes of the three algorithms are exactly the same, mainly completing the selection of bilinear mapping parameters, the judgment of bilinear mapping symmetry, declaring and initializing the variables in the PBC library, and generating the system master key pair; The running results of the system initialization program are given below, as Figure 2 shown.

[0215] (2) Identity key generation

[0216] In the "identity key generation" stage, the experimental processes of the three algorithms are exactly the same; Among them, the identity public key is directly generated by hashing the string "shenfen", and the identity private key is signed by the PKG using the master key pair for the identity public key; After the identity key is generated, the experiment uses the bilinear mapping to verify the validity of the identity key; After the verification passes, the next stage can be entered: Otherwise, the experiment ends.

[0217] (3) Self-Signed Public Key Generation

[0218] In the "Self-Signed Public Key Generation" phase, the experimental processes of the three algorithms are completely different.

[0219] A. The BF-IBE scheme does not require the generation of a self-signed public key.

[0220] B. For the self-signed IBC public key generation algorithm, elements in the finite field are randomly selected and multiplied by the identity key respectively, and the operation results are used as the user keys. Using the self-signed IBC public key generation algorithm, a self-signed IBC public key is generated, and the validity of the self-signed IBC public key is verified using bilinear mapping.

[0221] C. For the self-signed ECC public key generation algorithm, elements on the elliptic curve are randomly selected as the user keys. Using the self-signed ECC public key generation algorithm, a self-signed ECC public key is generated, and the validity of the self-signed public key is verified using bilinear mapping.

[0222] Taking the self-signed IBC public key generation algorithm as an example, the self-signed public key generation results are given as Figure 3 shown.

[0223] 4. Efficiency Test

[0224] In the "Encryption and Decryption" phase, the experimental processes of the three algorithms are not completely the same.

[0225] (1) For the BF-IBE scheme and the self-signed IBC public key generation algorithm, the encryption and decryption algorithms in the BF-IBE scheme are both used to perform encryption and decryption calculations on the string "mingwen", and the correctness of the encryption and decryption results is judged.

[0226] (2) For the self-signed ECC public key generation algorithm, the ElGamal elliptic curve encryption and decryption algorithm is used to perform encryption and decryption calculations on the string "mingwen", and the correctness of the encryption and decryption results is judged.

[0227] The experiment is repeated 300 times. In this paper, the time overheads of "System Initialization", "Identity Key Generation", and "Encryption and Decryption" for each experiment are respectively recorded, and the average time is calculated. The experimental results are shown in Table 3, and the time unit is "millisecond";

[0228] Table 3: Algorithm Operation Time

[0229] [[ID=.....]] [[ID=.....]] [[ID=.....]]

[0230] [[ID=.....]] [[ID=.....]] [[ID=.....]]

[0231] 5. Analysis of Test Results

[0232] (1) System Initialization

[0233] In the system initialization phase, the three algorithms complete the generation of system parameters and the system master key pair. Since the three algorithms use the same bilinear mapping parameters, the time overhead is approximately the same.

[0234] (2) Identity key generation

[0235] In the identity key generation phase, the identity public keys of the self-signed ECC and IBC algorithms are both generated by hashing the string "shenfen", and the identity private keys are generated by the PKG trusteeship, so the time overhead is also approximately the same. However, for the BF-IBE algorithm, due to the need for central distribution, the time overhead is relatively large.

[0236] (3) Public key generation

[0237] In the public key generation phase, the BF-IBE scheme requires central distribution and certificate authentication, so the time overhead is relatively large. Since the self-signed public keys used by the self-signed IBC public key generation algorithm and the self-signed ECC public key generation algorithm, the time overhead is relatively smaller than that of the BF-IBE. And the factors affecting the time overhead between the two only lie in the generation of user keys. The user keys of the self-signed ECC public key generation algorithm are randomly selected through elliptic curves in the finite field, and its time overhead is the same as that of the system master key generation. Compared with the self-signed IBC public key generation algorithm, the self-signed ECC public key generation algorithm adds one selection of elements in the finite field and two point doubling operations, so the operation time overhead is relatively large.

[0238] 6. Encryption and decryption

[0239] In the encryption and decryption phase, the BF-IBE scheme and the self-signed ECC public key generation algorithm adopt the encryption and decryption algorithms in the BF-IBE scheme to perform encryption and decryption calculations on the string "mingwen", so the required time overhead is approximately the same. The self-signed IBC public key generation algorithm uses the ElGamal elliptic curve encryption and decryption algorithm to perform encryption and decryption calculations on the string "mingwen". Since it does not require the computational overhead of bilinear mapping, the time overhead is the smallest. Based on the above four-part analysis, the conclusion can be drawn that:

[0240] When implementing data encryption and decryption, the self-signed IBC public key generation algorithm has better overall performance than the BF-IBE and self-signed ECC public key generation algorithms because it uses the identity identifier for self-signed authentication and does not require bilinear mapping calculations during encryption and decryption.

[0241] 7. System scalability and fault tolerance testing

[0242] 7.1 Scalability testing

[0243] Regarding the scalability of the system, a series of test cases were designed for the system to verify its performance when the number of users and data is continuously increasing. First, gradually increase the number of user registrations and observe the performance of the server side in generating and managing public-private key pairs, as shown in Table 4:

[0244] Table 4: Algorithm operation time for multiple users (unit: milliseconds)

[0245] Number of users 1 10 50 100 BF-IBE scheme 650.873 5340.322 24768.674 Failure Self-signed ECC public key generation algorithm 534.657 4332.233 20435.342 51432.335 Self-signed IBC public key generation algorithm 466.370 3962.545 19452.543 41434.323

[0246] Through testing, comprehensively evaluate the performance of the system under different loads and verify the scalability of the system when the number of users and data is continuously increasing. According to the result analysis, it can be known that when the number of users increases, the BF-IBE scheme has poor scalability; the self-signed IBC public key generation algorithm performs more stably in terms of scalability.

[0247] 7.2 Fault tolerance test

[0248] In the fault tolerance test, simulate scenarios where partial failures or abnormal conditions occur in the system, including partial failures on the server side, network anomalies, and signal interference. Through these simulation tests, evaluate the performance of the system when facing different types of failures, including the system's self-healing ability, data integrity guarantee, and system stability, as shown in Table 5. According to the results, it can be concluded that the authentication method using identity identifiers has strong anti-fault ability in key exchange, reflecting the superiority of the centerless and certificate-free system. However, when there are problems with the hardware, the system inevitably stops working.

[0249] Table 5: Fault tolerance test

[0250]

[0251] 7.3 Analysis of test results

[0252] Through the scalability and fault tolerance tests on the system, the results show that the system and method described in Embodiment 1 of the present invention can still maintain a high response speed and processing efficiency when the number of users and data volume increase, demonstrating good scalability.

[0253] The above-described embodiments only represent several implementation manners of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the appended claims.

Claims

1. A lightweight certificateless identity authentication method based on IBC, characterized in that: Including: Step 1: Build a lightweight certificate-free identity authentication system based on IBC, and use the server side of the system to perform user registration, key generation and storage; Step 2: Send the key pair data and identity identifier generated during the server-side registration process to the client through the interactive terminal; Step 3: The client encrypts, decrypts, signs and verifies the key pair data; Step 4: After the client encrypts, decrypts, signs and verifies the key pair data, send requests for encryption, decryption, signature and verification to the server side through the interactive terminal, and receive the results returned by the server side to complete the certificate-free identity authentication.

2. The lightweight certificateless identity authentication method based on IBC according to claim 1, wherein: The process of user registration and key generation described in Step 1 includes: Step 1011: During registration, the user selects a random number t ∈ R Z q , calculates T and Q according to the system parameters, and obtains the identity identifier ID i ; Where: T = t·P, Q = H(ID), H represents the hash operation, P represents the bilinear pairing operation, ID represents the user identity identifier, and i represents each user; Step 1012: The user registers the identity identifier ID with the digital certificate registration system LRA in an offline manner i = <Q, T>; Step 1013: The digital certificate registration system LRA submits the user registration information to the private key generator PKG; Step 1014: The private key generator PKG saves the user registration information as a certificate for the user to apply for the identity private key, and completes the user registration; Step 1015: After the user registration is completed, the server generates a key using the IBC-based key derivation algorithm.

3. The lightweight certificateless identity authentication method based on IBC according to claim 1, wherein: The process of encrypting, decrypting, signing and verifying the key pair data described in Step 3 includes: Step 301: Encrypt and decrypt the key pair data; Step 302: After encrypting and decrypting the key pair data in Step 301, sign and verify the key pair data; Step 303: After encrypting and decrypting the key pair data in Step 301, verify the self-signed public key of the key pair data.

4. The lightweight certificateless identity authentication method based on IBC according to claim 3, wherein: The process of encrypting and decrypting the key pair data described in Step 301 includes: Step 3011: System initialization Step 30111: The client server selects groups of prime order q, namely additive groups G1, G2 and multiplicative group G T , and a non-degenerate bilinear map e: G1 × G2 → G T , and selects a generator P1 ∈ G1, P2 ∈ G2, a hash algorithm H, and an identifier hid represented by one byte; Step 30112: Use the random number s generated by the system as the main private key for system encryption, and calculate P pub and g; Step 3012: Generate a user key pair Step 30121: The user selects a random number x as the user's partial private key and calculates the user's public key PK; Step 30122: The user applies to the server for a partial SM9 private key using the user identity ID and the user public key PK, and the server calculates h ID ; If (h ID + s) mod q = 0, then an error is output and the system regenerates the encryption master key; otherwise, d ID = s(h ID + s) -1 P2; Step 30123: After the user obtains d returned by the server ID calculate the user's private key SK using the random number x and save it; Step 3013: Encryption process Step 30131: After the sender receives the user public key PK, calculate the encryption public key E PK ; Step 30132: Randomly select an integer r and calculate C1 and w; Step 30133: Calculate K = K1||K2. If K1 is all 0, then return to Step 30132; Where K1 is the leftmost Mlen bits of K, Mlen is the length of the message M, and K2 is the remaining bits of K; Step 30134: Calculate C2, C3, and output the ciphertext C1, C2, C3 and send them to the decryptor; Step 3014: Decryption process After the decryptor receives the ciphertext C1‘, C2‘, C3‘: Step 30141: Verify whether C1‘ is an element in the G1 group. If not, report an error and exit; Step 30142: Calculate w' and K' = K1'||K2'. If K1' is all 0, then report an error and exit; Step 30143: Calculate M' and C3". If C3" is inconsistent with C3‘, then report an error and exit.

5. The lightweight certificateless identity authentication method based on IBC according to claim 4, characterized in that: During the decryption process, it also includes verifying the correctness of decryption, including:

6. The lightweight certificateless identity authentication method based on IBC according to claim 3, wherein: The process of signing and verifying the key pair data described in Step 302 includes: Step 3021: System initialization Step 30211: The client server selects groups of prime order q, namely additive groups G1, G2 and multiplicative group G T , and a non-degenerate bilinear mapping e: G1×G2→G T , and selects a generator P1∈G1, P2∈G2, hash algorithms H1, H2 and an identifier hid represented by one byte; Step 30212: The system generates a random number ks as the main private key for system signature and calculates P pub ; Step 3022: Generate a user key Identify the user identity of user A as ID A , the server calculates t1; If t1 = 0, then regenerate the system signature master private key; if not 0, then calculate t2 = ks·t1 -1 , the signature private key ds of user A A = [t2]P1; Step 3023: User signature process; Step 30214: Verify the signature.

7. The lightweight certificateless identity authentication method based on IBC according to claim 6, characterized in that: The user signature process includes: Assume the message to be signed is bit string M, and signer A should perform the following operation steps: (1) Calculate G T The element g = e(P1, P pub ); (2) Select a random number r and calculate w = g T in the element of r ; (3) Calculate h = H2(M||w, q); (4) Calculate l = r - h mod q; (5) Calculate \(S=\int_{l}ds\) A and take \((h, S)\) as the signature.

8. The lightweight certificateless identity authentication method based on IBC according to claim 6, characterized in that: The signature verification process includes: The verifier receives message M' and its signature (h‘, S’): (1) Calculate G T The element g = e(P1, P pub ) (2) Calculate G T The element t = g in h‘ (3) Calculate h1 = H1(M||w, q), and the element P in G2 is P = [h1]P2 + P pub (4) Calculate G T for elements u, w' in it, where u = e(S', P) and w' = u · t (5) Calculate h2 = H2(M'||w', q), and check h2 and h‘. If the two are consistent, the verification passes.

9. The lightweight certificateless identity authentication method based on IBC according to claim 3, characterized in that: The process of self-signature public key verification for the key pair data described in step 303 includes: Step 3031: System initialization Step 30311: The server selects groups of prime order q, namely additive groups G1, G2, and multiplicative group G T , and a non-degenerate bilinear mapping e: G1×G2→G T , and selects generators P1∈G1, P2∈G2, and hash algorithms H1, H2; Step 30312: The system generates a random number s as the system master private key, and calculates P pub = [s]P1 and publishes these system parameters; Step 3032: Generate user keys Step 30321: Identify the user identity of User A as IDA, and the server calculates the identity public key of User A Calculate the identity private key of User A using the system master key s PKG sends the identity private key to User A through a secure channel; Step 30322: User A selects a random parameter x ID , and constructs a user key Among them Step 3033: Generate self-signature public key User A selects a random number r, signs the user's public key using the identity private key, and constructs a self-signed public key Among them, Step 3034: Verify self-signature public key Step 30341: Calculate h, Q; Step 30342: Verify e(P1, V ID ) = e(P pub , Q), to achieve self-signed public key verification.

10. A lightweight certificateless identity authentication system based on IBC, characterized in that: Includes: The server side is used to generate and manage the public and private key pairs of users after user registration, and provide corresponding interfaces for users to obtain and update keys; The client side, as the user's terminal device, is responsible for the encryption, decryption, signature and verification operations of key pair data; The interaction side is used to conduct the interaction between the server side and the client side to realize user registration, key generation and security operations; Among them, the server side, the client side and the interaction side are all implemented based on the method described in any one of claims 1-9.

Images