An Adaptive Identity Authentication and Key Agreement Method in Cloud-Edge-Terminal Environment

Abstract

The present invention discloses an adaptive identity authentication and key negotiation method in a cloud-edge-end environment, including: using a trust institution to perform identity registration for users, devices, edge servers, and cloud servers. After the identity registration is completed, the user logs in to the device and sends the user's request information to the edge servers within the range through the logged-in device; the edge server that receives the request information provides services for the user: determines whether the service capability of the edge server meets the request information. If so, performs authentication and key negotiation between the edge server and the device logged in by the user, and provides services for the user after completion; if not, selects a cloud server to perform authentication and key negotiation with the device logged in by the user, and provides services for the user after completion. The present invention can adaptively execute different authentication methods, and the device only needs to send one authentication request to meet the requirements, reducing the redundant authentication of the device, reducing the load on the trust institution TA while protecting the device privacy.

Description

Technical Field

[0001] The present invention belongs to the technical field of network security, and particularly relates to an adaptive identity authentication and key negotiation method in a cloud-edge-end environment. Background Art

[0002] Cloud computing has become an important means to meet people's diverse needs, and its wide applications cover various fields from online medical diagnosis to video transmission of dashcams and then to daily conversations. Cloud computing has significant advantages in providing various services, but for some time-sensitive services, there are still certain limitations. For example, in aspects such as real-time data processing and low-latency communication, cloud computing often fails to achieve the expected results. To address these challenges, edge computing has emerged. Edge computing effectively reduces latency and improves real-time performance by moving computing and data storage to the network edge, thus meeting users' needs for time-sensitive services. However, the computing and storage capabilities of edge computing itself are limited, and it still relies on the support of cloud computing when dealing with large-scale and complex tasks. Nowadays, the optimization and promotion of the cloud-edge-end architecture have become a research hotspot. The cloud-edge-end collaborative computing technology combines the advantages of cloud computing and edge computing, and can simultaneously meet users' diverse needs for real-time performance and computing power, becoming an inevitable trend in the development of the Internet of Things.

[0003] However, the following disadvantages exist in the prior art:

[0004] (1) Authentication in a single scenario: Currently, there are some existing authentication schemes in the cloud-edge-end environment, such as the authentication scheme between devices and the edge, the authentication scheme between devices and the cloud, etc. However, these schemes are usually only applicable to a single scenario. For example, only the authentication between the edge and user devices or the authentication between the cloud and user devices is considered, and the comprehensive cloud-edge-end collaborative scenario is not taken into account. Due to the complexity of the cloud-edge-end collaborative scenario, for example, users may need edge computing to complete some time-sensitive services, while for services with high computing volume and storage requirements, they need the assistance of cloud computing. Therefore, a cloud-edge-end collaborative authentication scheme with scalability, adaptability, and high availability is required. In addition, due to different requirements for system initialization and encryption algorithms, the integration difficulty increases, and it is difficult to integrate these single-scenario schemes into a unified cloud-edge-end framework.

[0005] (2) Overloaded trust institutions: Frequent interaction with trust authorities (TAs, Trust Authorities) or registration centers during the authentication process leads to overloaded TAs and registration centers, which may cause security problems.

[0006] (3) Complex ECC operations are not suitable for resource-constrained devices: Complex elliptic curve cryptography (ECC) operations and bilinear pairings are used in the authentication process, which are not friendly to resource-constrained devices and increase the deployment difficulty. Summary of the Invention

[0007] The object of the present invention is to provide an adaptive identity authentication and key negotiation method in a cloud-edge-end environment to solve the problems existing in the above-mentioned prior art.

[0008] To achieve the above object, the present invention provides an adaptive identity authentication and key negotiation method in a cloud-edge-end environment, including:

[0009] Step 1: Use a trust institution to register the identities of users, devices, edge servers, and cloud servers. After the identity registration is completed, the user logs in to the device, and the logged-in device sends the user's request information to an edge server within a set range.

[0010] Step 2: After receiving the request information, the edge server verifies the legality of the device logged in by the user. After passing the verification, the edge server provides services for the user based on the request information.

[0011] Step 3: During the process of providing services for the user, determine whether the service capability of the edge server meets the request information. If so, perform authentication and key negotiation between the edge server and the device logged in by the user. After the negotiation is completed, provide services for the user; if not, adaptively select a cloud server to perform authentication and key negotiation with the device logged in by the user. After the negotiation is completed, provide services for the user.

[0012] Optionally, before using the trust institution to register the identities of users, devices, edge servers, and cloud servers, it further includes: using the trust institution to initialize the Hash function for system hash calculation and publicly disclose the calculated parameters within the network to complete system initialization.

[0013] Optionally, the identity registration process of the cloud server specifically includes:

[0014] The cloud server submits a cloud server registration request to the trust institution. The cloud server registration request includes the cloud server identity identifier and the types of services provided. After receiving the cloud server registration request, the trust institution verifies the legality of the cloud server identity identifier. If it is legal, generate a long-term public-private key based on the cloud server identity identifier, calculate the secret value of the cloud server based on hash operation, store the calculated secret value, public key, and service types by the trust institution, and send the calculated secret value and private key to the cloud server to complete the identity registration of the cloud server.

[0015] Optionally, the identity registration process of the edge server specifically includes:

[0016] The edge server submits an edge server registration request to the trust institution, and the edge server registration request includes an edge server identity identifier; after receiving the edge server registration request, the trust institution verifies the legality of the edge server identity identifier. If it is legal, the trust institution generates a long-term public-private key based on the edge server identity identifier, calculates an authentication credential for the edge server based on a hash operation, generates an associated authentication credential for each cloud server corresponding to the edge server, and returns a response message to the edge server. The response message includes the private key of the edge server, the public identifier of the cloud server identity, the authentication credential, and the pseudonym for the authentication between the edge server and the cloud server; stores the edge server identity identifier, public key, and the pseudonym for the authentication between the edge server and the cloud server in the trust institution to complete the identity registration of the edge server.

[0017] Optionally, the identity registration process of the user and the device specifically includes:

[0018] The user selects a username and password, performs a hash operation on the username and password to obtain an encrypted password, and submits the calculated encrypted password, username, device identifier, behavior preferences, and geographical location as a user registration request to the trust institution;

[0019] After receiving the user registration request, the trust institution calculates a unique communication identifier based on the username and device identifier, verifies the legality of the unique communication identifier. If it is legal, the trust institution generates a long-term public-private key based on the unique communication identifier, and generates an associated authentication credential for each edge server corresponding to the unique communication identifier based on the behavior preferences and geographical location;

[0020] Calculate user login data on the device based on the username, device identifier, and password, enable the device to save the user login data, private key, and the pseudonym for the authentication between the unique communication identifier and the edge server, and enable the trust institution to store the unique communication identifier, username, device identifier, public key, and the pseudonym for the authentication between the unique communication identifier and the edge server to complete the identity registration of the user and the device.

[0021] Optionally, the user logging in to the device specifically includes:

[0022] The device calculates the current user login data based on the username, device identifier, and password input by the user. If the current user login data is consistent with the preset user login data, the login is successful; if the current user login data is inconsistent with the preset user login data, the login fails.

[0023] Optionally, step three specifically includes:

[0024] The device sends an authentication request to the edge server. The authentication request includes a service request, a pseudonym, a first random number, a timestamp, a first message authentication code, and a hash calculation value, where the hash calculation value is obtained by performing a hash operation on the service request, the pseudonym, the random number, and the timestamp;

[0025] After receiving the authentication request, the edge server determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the current hash calculation value is calculated, and it is determined whether the current hash calculation value is consistent with the hash calculation value in the authentication request. If they are not consistent, the authentication fails; if they are consistent, the authentication is successful, and the service capability is judged. If the service capability of the edge server does not meet the request information, a cloud server is selected to perform authentication and key negotiation with the device logged in by the user. After the negotiation is completed, the service is provided to the user; if the service capability of the edge server meets the request information, authentication and key negotiation are performed between the edge server and the device logged in by the user. After the negotiation is completed, the service is provided to the user.

[0026] Optionally, the authentication and key negotiation between the edge server and the device logged in by the user specifically includes:

[0027] A second random number is randomly generated, a second message authentication code is calculated based on the second random number, a session key is generated and the current timestamp is extracted, a hash value is calculated based on the second random number, the current timestamp, and the session key, and the calculated hash value, the current timestamp, and the second message authentication code are sent to the device as an authentication message;

[0028] After receiving the authentication message, the device determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the current hash value is calculated based on the second message authentication code, and the current hash value is compared with the hash value in the authentication message. If they are different, the authentication fails; if they are the same, the authentication passes, and the session key is saved.

[0029] Optionally, the adaptive selection of a cloud server to perform authentication and key negotiation with the device logged in by the user specifically includes:

[0030] A third message authentication code is calculated, and the current hash value is calculated based on the third message authentication code, the pseudonym, and the timestamp. The calculated hash value, the third message authentication code, the pseudonym, the timestamp, and the service type are sent to the selected cloud server;

[0031] After receiving the data, the cloud server determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the fourth message authentication code is calculated, and it is determined whether the current hash operation value is consistent with the hash value in the data received by the cloud server. If they are inconsistent, the authentication fails; if they are consistent, the authentication passes, and the calculated hash value, the fourth message authentication code, and the current timestamp are sent to the edge server for verification. It is determined whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the fifth message authentication code is calculated, and it is determined whether the current hash operation value is consistent with the hash value in the data received by the edge server. If they are inconsistent, the authentication fails; if they are consistent, the authentication passes, and the calculated hash value, the fifth message authentication code, and the current timestamp are sent to the device. After receiving the data, the device determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the current hash operation value is calculated based on the fifth message authentication code, and it is determined whether the current hash operation value is consistent with the hash value in the data received by the device. If they are inconsistent, the authentication fails; if they are consistent, the authentication passes, and the session key is saved.

[0032] The technical effects of the present invention are as follows:

[0033] The self - adaptive and highly scalable cloud - edge - device collaborative authentication architecture provided by the present invention can effectively meet various requirements of devices, adaptively execute different authentication methods, and reduce redundant authentication and complex operations on the device side.

[0034] In the authentication architecture assisted by the edge server proposed by the present invention, the authentication and key negotiation processes no longer rely on the third - party trust authority TA frequently, reducing the load on the trust authority TA.

[0035] The lightweight authentication method proposed by the present invention is suitable for various scenarios with limited network resources, increasing the deployability.

[0036] The use of associated authentication credentials in the present invention reduces the complexity of real - time calculation and time consumption while protecting device privacy. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required in the embodiments. Obviously, the 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 be obtained based on these drawings.

[0038] The drawings constituting a part of this application are used to provide a further understanding of this application. The schematic embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation of this application. In the drawings:

[0039] Figure 1 It is the flowchart of cloud server registration in the embodiment of the present invention;

[0040] Figure 2 It is the flowchart of edge server registration in the embodiment of the present invention;

[0041] Figure 3 It is the flowchart of user and device registration in the embodiment of the present invention;

[0042] Figure 4 It is the flowchart of authentication and key negotiation in the embodiment of the present invention;

[0043] Figure 5 It is the implementation flowchart of adaptive identity authentication and key negotiation in the embodiment of the present invention. Detailed implementation manners

[0044] Now, various exemplary implementation manners of the present invention will be described in detail. This detailed description should not be considered as a limitation of the present invention, but should be understood as a more detailed description of certain aspects, characteristics and implementation schemes of the present invention.

[0045] It should be understood that the terms described in the present invention are only for describing specific implementation manners and are not used to limit the present invention. Additionally, for the numerical ranges in the present invention, it should be understood that each intermediate value between the upper and lower limits of the range is also specifically disclosed. Each intermediate value within any stated value or stated range, as well as each smaller range between any other stated value or intermediate value within the stated range, is also included in the present invention. The upper and lower limits of these smaller ranges can be independently included or excluded from the range.

[0046] Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the present invention pertains. Although the present invention only describes preferred methods, any method similar or equivalent to those described herein can also be used in the implementation or testing of the present invention. All documents mentioned in this specification are incorporated by reference to disclose and describe the methods related to the documents. In case of conflict with any incorporated document, the content of this specification shall prevail.

[0047] Without departing from the scope or spirit of the present invention, various improvements and changes can be made to the specific implementation manners of the present invention specification, which are obvious to those skilled in the art. Other implementation manners obtained from the specification of the present invention are obvious to those skilled in the art. The specification and embodiments of this application are only exemplary.

[0048] Regarding the terms "comprising", "including", "having", "containing", etc. used herein, they are all open-ended terms, that is, they are meant to include but not limited to.

[0049] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other. The following will describe the present application in detail with reference to the accompanying drawings and in combination with the embodiments.

[0050] Embodiment 1

[0051] As Figure 1 - Figure 5 shown, in this embodiment, an adaptive identity authentication and key negotiation method in a cloud-edge-end environment is provided, including:

[0052] Step 1: Use a trust institution to register the identities of users, devices, edge servers, and cloud servers. After the identity registration is completed, the user logs in to the device, and the logged-in device sends the user's request information to an edge server within a set range.

[0053] Step 2: After receiving the request information, the edge server verifies the legitimacy of the device logged in by the user. After the verification passes, the edge server provides services for the user based on the request information.

[0054] Step 3: During the process of providing services for the user, determine whether the service capability of the edge server meets the request information. If so, perform authentication and key negotiation between the edge server and the device logged in by the user. After the negotiation is completed, provide services for the user. If not, select a cloud server to perform authentication and key negotiation with the device logged in by the user. After the negotiation is completed, provide services for the user.

[0055] In the existing authentication scenarios under the cloud-edge-end architecture, the scenarios are relatively single, only considering the authentication between the cloud and the user device, and the authentication between the edge and the user device, without considering the scenario of cloud-edge-end collaboration. One consequence of this situation is that, for example, if the user device first sends a service request and an authentication request to the edge, and the edge cannot meet the service request of the user device, the user device still needs to send a service request and an authentication request to the cloud again.

[0056] This embodiment considers the authentication in the scenario of cloud-edge-end collaboration. The user device only needs to send an authentication request message once. If the edge meets the requirements, the user device directly performs identity authentication and key negotiation with the edge. If the edge does not meet the requirements, the authentication message is adaptively processed and forwarded to a suitable cloud, and finally identity authentication and key negotiation between the cloud and the user device are achieved, that is, the user device does not need to send authentication request information frequently or repeatedly.

[0057] In response to the above problems, this embodiment proposes the following solutions:

[0058] First, design a highly available cloud-edge-end collaborative authentication architecture, and adaptively start different authentication methods according to different requirements of the devices, reducing the complexity and repetitive operations at the device end.

[0059] Secondly, during the authentication process, there is no need to frequently rely on the Trust Authority (TA), which reduces the load on the Trust Authority (TA).

[0060] Thirdly, a lightweight authentication method is proposed. In the authentication process, lightweight algorithms are used, reducing the authentication overhead.

[0061] Finally, each entity in the authentication protocol generates associated authentication credentials during registration. During authentication, only these credentials need to be used, without disclosing device privacy.

[0062] In summary, this embodiment designs a highly scalable and adaptive cloud-edge-end collaborative authentication architecture. Through the collaborative work of devices, edge servers, and cloud servers, it meets the user's needs for diversification and real-time performance. This solution does not rely on the Trust Authority (TA) during the authentication process, reducing the burden and security risks of the Trust Authority (TA). At the same time, it adopts a lightweight authentication method and an associated authentication credential method, which is suitable for resource-constrained Internet of Things devices and has high practicality and security.

[0063] This embodiment designs an adaptive and highly scalable cloud-edge-end collaborative authentication architecture: This architecture can effectively meet the real-time needs of devices. During the authentication process, a device can first send a service request to the edge server. If the edge server cannot meet the service requirements, it will automatically request the assistance of the cloud server. During the process of requesting services, this architecture can adaptively initiate different authentication methods, thereby reducing the complex operations of the device and improving the efficiency of the authentication process. This design not only enhances the flexibility and response speed of the system but also ensures that various devices can obtain optimal services in different scenarios.

[0064] This embodiment proposes an authentication architecture assisted by an edge server: In this architecture, the authentication process no longer frequently relies on a third-party trust authority (Trust Authority TA). With only the assistance of the edge server, two-way anonymous authentication between the device and the edge server, and between the device and the cloud server can be achieved. By reducing the dependence on the Trust Authority TA, not only the burden on the Trust Authority TA is reduced, but also the security risks caused by frequent calculations of the Trust Authority TA are reduced. This two-way anonymous authentication mechanism improves the security and reliability of the system.

[0065] This embodiment proposes a lightweight authentication method: This method only uses hash-based algorithms during the authentication process, avoiding complex Elliptic Curve Cryptography (ECC) operations, thus significantly reducing the computational overhead during the authentication process. The lightweight authentication method makes this solution particularly suitable for various resource-constrained Internet of Things devices, ensuring that even devices with limited performance can perform efficient authentication operations, enhancing the applicable scope and practicality of the overall system.

[0066] This embodiment introduces the use of associated authentication credentials in the authentication protocol: each entity generates associated authentication credentials during registration, and in subsequent authentication processes, only these credentials need to be used to complete the authentication. This design ensures the efficiency and security of the authentication process. By pre-generating and using associated credentials, the complexity and time consumption of real-time calculations are reduced, further enhancing the efficiency of authentication operations.

[0067] This solution has a total of five stages. The first stage is system initialization, where the Trusted Authority (TA) assigns public parameters to the system. The second stage is when users (User), devices (devices), edge servers (Edge servers, ESs), and cloud servers (cloud servers, CSs) legally register with the Trusted Authority (TA) to obtain the necessary credentials for authentication. The third stage is that the user can proceed with subsequent processes only after performing the necessary login device operations. The fourth stage is the authentication and key negotiation stage before the device requests various services. This stage can be divided into two cases. The first case is the mutual authentication and key negotiation between devices and ESs, and the second case is that with the assistance of ESs, devices perform mutual authentication and key negotiation with multiple CSs. The fifth stage is the password update of the user.

[0068] The first stage: System initialization.

[0069] In this stage, the Trusted Authority (TA) initializes the Hash function for system hash calculation and makes these parameters public within the network. Each entity in the network can calculate the required authentication credentials based on these public parameters. The Trusted Authority (TA) selects a series of secure hash functions h: {0, 1}* → {0, 1} l

[0070] The second stage: Registration stage.

[0071] In this stage, Users, Devices, ESs, and CSs respectively provide registration information to the Trusted Authority (TA) through a secure channel for identity registration.

[0072] ① Registration of cloud server CS:

[0073] In this stage, CS k First selects its own identity identifier CID k , and then submits its registration request {CID k , Services} to the Trusted Authority (TA) through a secure channel, where Services is the type of services that CS k can provide. After receiving the registration request, the Trusted Authority (TA) will first check CID kWhether it is legal, for example, whether there is duplicate registration. If it is not legal, the request is rejected. If it is legal, based on the ECC algorithm or other algorithms, for this CID k Generate long-term public and private keys (SK k , PK k ), it should be noted that, (SK k , PK k ) and CID k are in a strong binding relationship for other scenarios to use in the future for CID k . Finally, calculate the secret value SC k = h(s||X) for CS k . Here, it should be noted that the value of X is optional. It can be any value, but it cannot be repeated when other entities register.

[0074] Return the message {SC k , SK k} to the cloud server CS k . Finally, the trust authority TA stores {identity identifier CID k , PK k , Services}toListCS(), and CS stores {SC k , SK k}.

[0075] ② ES registration:

[0076] (1) ES j First, select its own identity identifier EID j , and then submit its registration request {EID j} to the trust authority TA through a secure channel.

[0077] (2) After receiving the registration request, the trust authority TA will first check whether EID j is legal, for example, whether there is duplicate registration. If it is not legal, the request is ignored. If it is legal, based on the ECC algorithm or other algorithms, generate long-term public and private keys (SK j , PK j ) for this EID j . It should be noted that, (SK j , PK j ) and EID j are in a strong binding relationship for other scenarios to use in the future for EID j . Then generate an authentication credential SE j = h(s||X) for ES j . Here, it should be noted that the value of X is optional. It can be any value, but it cannot be repeated when other entities register. SE j is used to verify the identity of the Device.

[0078] Then, the trusted authority TA traverses ListCS() to generate an associated authentication credential for each CS j For the sake of simplicity in description, this embodiment briefly illustrates the process of generating an associated authentication credential between ES j and a single CS (CS k ):

[0079] To achieve the anonymity of the authentication between ES j and CS k , the trusted authority TA calculates a pseudonym pid j for the authentication between ES k and CS (x) j,k = h(Y), where the value of Y can be any value, which cannot be the same as that during the registration of other entities, and the generated pseudonym can be one or more, and multiple authentication credentials C (x) j,k = h(pid (x) j,k ||SC k ), where SC k is the secret value of the cloud server CS K . Finally, the response message {SK j , (W k , PID j,k , C j,k )} is returned to ES j , where PID j,k = {pid (1) j,k , pid (2) j,k ,..., pid (n) j,k}, C j,k = {C (1) j,k , C (2) j,k ,..., C (n) j,k}, and W k is a public identifier that can identify the identity of CS k .

[0080] (3) After receiving the response message from the trusted authority TA, ES j saves {SK j , (W k , PID j,k , C j,k )} to ListE2C(), and at the same time, the trusted authority TA saves {EID j , PK j,(PID j,k )} to ListES().

[0081] It should be noted here that the (W k , PID j,k , C j,k ) generated by the above registration process is the anonymous identity and authentication credential for communication between ES j and CS k . In fact, when ES j is registering, the trust authority TA will customize and select a CS sequence from the list of CSs already registered according to the information such as the preferences and geographical location provided by ES j , and generate multiple (W x , PID j,x , C j,x ) for ES j , so that more services can be provided for the devices within the range of ES

[0082] ③ User and Device Registration:

[0083] (1) First, the device user selects their username UID i and password PW i , then calculates the hash value EPW i = h(UID i || PW i ), and finally submits {UID i , ID i , EPW i , INFO} to the trust authority TA, where ID i is the identifier of device D i , and INFO is other information such as the user's behavior preferences and geographical location.

[0084] (2) After receiving the registration request, the trust authority TA will first calculate the unique communication identifier DID i combined with UID i and ID i = h(UID i || ID i || s), then check whether DID i is legal, such as whether there is a duplicate registration. If it is not legal, the request will be ignored. If it is legal, the ECC algorithm or other algorithms will generate long-term public and private keys (SK i , PK i , PK i ) for this DID

[0085] The trust authority TA will then, according to the content of INFO, for DID iSelect the most suitable ES sequence. For the convenience of description, this embodiment briefly describes DID i The process of generating an associated authentication credential with a single ES (ES j ):

[0086] To ensure the anonymity and unlinkability of user authentication, the trust authority TA calculates the pseudonym pid i authenticated with ES j = h(Y), where the value of Y can be any value, cannot be the same as when other entities are registered, and the generated pseudonym can be one or more, and multiple authenticated credentials a (x) i,j = h(pid (x) i,j ||SE (x) i,j ), where SE j is the secret value of the edge server ES j . Then calculate b j (x) i,j = EPW i ⊕a (x) i,j i,j .

[0087] Finally, return the response message {SK i ,(W j , PID i,j , B i,j )} to D j , where PID i,j = {pid (1) i,j , pid (2) i,j ,..., pid (n) i,j}, B i,j = {b (1) i,j , b (2) i,j ,..., b (n) i,j}, and W j is any public identifier that can identify the identity of ES j .

[0088] (3) D i Calculate Q i = H(UID i ||ID i ||PW i ), and Q i is used by the user UID i登录 D i .i Save {Q i , SK i , (W j , PID i,j , B i,j )} to ListD2E(). The trusted authority TA saves {DID i , (UID i , ID i ), PK i , (PID i,j )} to ListDID().

[0089] The third stage: Login stage.

[0090] Login is a prerequisite for authentication and key negotiation. This process mainly describes the process of User i登录 device D i . First, the user inputs UID i , ID j , PW i , and D i calculates Q i ’ = H(UID i || ID j || PW i ), and determines whether Q i ’ is the same as Q i . If they are the same, the login is successful; if not, the login fails.

[0091] The fourth stage: Authentication and key negotiation stage.

[0092] If User i successfully logs in to D i , D i sends its request message to the ES within its geographical range instead of broadcasting the message to the CS. Then, the ES verifies the legitimacy of D i through authentication. If D is legal and has been registered, the ES provides services for it according to the user's request. To improve the response efficiency of user requests, two modes are defined in this embodiment.

[0093] The first is that if the ES itself has the ability to complete the user's service requirements, the authentication and key negotiation between D i and the ES are directly carried out.

[0094] The second is that if the ES itself cannot meet the user's service requirements, the best CS service is recommended to the user, which may be one or more CSs. Subsequently, D i and the CS complete the authentication and session key negotiation with the assistance of the ES. It should be noted here that how to select a suitable cloud service provider is beyond the scope of this solution.

[0095] ① Mode 1: This mode is ES j The services provided can already meet the needs of users, then ES j does not need to request cloud services. Then only D i and ES j need to authenticate each other. The mutual authentication process is as follows:

[0096] Step1: D i initiates an authentication request to ES j . At this time, D i has received the public identifier W j broadcast by ES j within its control range. Calculate: EPW i = H(DID i || PW i ). D i randomly selects pid ij from PID (x) i,j to authenticate with ES j , and calculate Then randomly generate x1 and calculate Calculate the hash value ɑ = h(SerReq, pid (x) i,j , x1, T i ). Then send {SerReq, pid (x) i,j , M1, ɑ, T i} to ES j .

[0097] Step2: Edgeserver: ES j receives the authentication request information {SerReq, pid i (x) i,j , M1, ɑ, T i i} from D. First, perform a timestamp T i check. If Thas expired, reject the authentication request. Otherwise, calculate: A ij = H(pid (x) i,j || SE j ), and at the same time obtain the value of x1' Then calculate the hash value ɑ' = h(SerReq, pid (x) i,j , x1', T i ). Determine whether ɑ is the same as ɑ'. If not, the device D i authentication fails. Otherwise, Di The authentication is passed. Then, check the information SerReq. If it is found that the device service requirements cannot be met, jump to Mode 2. If they can be met, randomly generate x2 and calculate Generate the session key sk ji = h(A ij ||x1’||x2); Extract the timestamp T j , calculate the hash value β = h(sk ji , x2, T j ), and finally return the message {M2, β, T j} to D i .

[0098] Step3: D i Receives the authentication response information {M2, β, T j} from ES j . First, perform the timestamp T j verification. If T has expired, reject the authentication request. Otherwise, calculate and calculate the session key sk ij = h(a (x) i,j ’||x1||x2). Calculate the hash value β’ = h(sk ij , x2’, T j ). Determine whether β is the same as β’. If they are not the same, the ES j authentication fails. Otherwise, the ES j authentication is passed, and store the session key sessionKey = sk ij .

[0099] ② Mode 2: This stage occurs when the services provided by ES j cannot meet the user's requirements. ES j needs to request cloud services for D i . This authentication method is also applicable to multi-cloud environments. Since the user's service requirements are diverse, ES j can select multiple cloud services for the user at the same time, and these selections are transparent to the user. That is to say, ES assists in the authentication between the user and CS. The specific process is as follows:

[0100] Step1: The same as Mode 1, which will not be elaborated here.

[0101] Step2: The steps before checking the information SerReq are also the same as those in Mode 1 and will not be elaborated.

[0102] Check the information SerReq. If it is found that the device service requirements cannot be met, then select appropriate CSs based on the user's request. Calculate S i,j = h(Ai,j || x1’), M3 = S i,j ⊕ C j,k , θ = h(SerReq || pid j,k || S i,j || T k ). Send {SerReq, pid j,k , M3, θ, T k} to CS k。

[0103] Step 3: First, perform the timestamp T k check. If T k has expired, reject the authentication request. Otherwise, calculate A j,k = h(pid j,k || SC j ), S’ i,j = M3 ⊕ A j,k , θ = h(SerReq || pid j,k || S’ i,j || T k ). Determine whether θ is the same as θ’. If not, the authentication fails. If so, generate a random number x 3， Calculate S j,k = h(A j,k || x3), M4 = S j,k ⊕ A j,k , sk ki = h(S’ i,j || S j,k ), υ = h(sk ki || S j,k || T l ), where T l is the timestamp. Then send {M4, υ, T l} to ES j .

[0104] Step 4: First, perform the timestamp T l check. If T l has expired, reject the authentication request. Otherwise, calculate S’ j,k = M4 ⊕ C j,k , sk’ ik = h(S’ i,j || S’ j,k ), υ’ = h(sk ki || S’ j,k || T l ). Determine whether υ’ is the same as υ. If not, the authentication fails. If so, calculate M5 = S’ j,k ⊕ A i,j, ε = h(sk’ ki ||S’ j,k ||T m ), where T m is a timestamp. Then send {M5, υ, T m} to D i .

[0105] Step5: After D i receives the authentication response information {M5, υ, T j} from ES m , first perform the timestamp T m verification. If T m has expired, reject the authentication request. Otherwise, calculate S” i,j = h(a (r)’ i,j ||x1), S” j,k = M5 ⊕ a (r)’ i,j , ε’ = h(sk’ ki ||S” j,k ||T m ), and determine whether ε’ is the same as ε. If not, the authentication of ES j and CS k fails. Otherwise, the authentication of ES j and CS k passes, and store the session key sessionKey = sk ij .

[0106] In this embodiment, the authentication and key negotiation phase considers the authentication in the cloud-edge-end collaborative scenario. The user device only needs to send an authentication request message once. If the edge meets the requirements, the user device directly performs identity authentication and key negotiation with the edge. If the edge does not meet the requirements, the authentication message is adaptively processed and forwarded to the appropriate cloud, and finally, the identity authentication and key negotiation between the cloud and the user device are achieved, that is, the user device does not need to send authentication request information frequently or repeatedly.

[0107] The self-adaptive and highly scalable cloud-edge-end collaborative authentication architecture designed in this embodiment can effectively meet the various needs of devices, adaptively execute different authentication methods, and reduce the complex operations on the device side. The authentication architecture assisted by the edge server proposed in this embodiment no longer relies on the third-party trust authority TA frequently during the authentication and key negotiation process, reducing the load of the trust authority TA. The lightweight authentication method proposed in this embodiment is suitable for various scenarios with limited network resources, increasing the deployability. The use of associated authentication credentials in this embodiment reduces the complexity of real-time calculation and time consumption while protecting device privacy.

[0108] As described above, it is only the preferred specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An adaptive identity authentication and key negotiation method in a cloud-edge-terminal environment, characterized in that, Including: Step 1: Use a trusted institution to register the identities of users, devices, edge servers, and cloud servers. After the identity registration is completed, the user logs in to the device and sends the user's request information to the edge servers within a set range through the logged-in device; The identity registration process of the cloud server specifically includes: The cloud server submits a cloud server registration request to the trusted institution. The cloud server registration request includes the cloud server identity identifier and the types of services provided; After receiving the cloud server registration request, the trusted institution verifies the legality of the cloud server identity identifier. If it is legal, a long-term public-private key is generated based on the cloud server identity identifier, and the secret value of the cloud server is calculated based on the hash operation. The trusted institution stores the calculated secret value, public key, and service types, and sends the calculated secret value and private key to the cloud server to complete the identity registration of the cloud server; The identity registration process of the edge server specifically includes: The edge server submits an edge server registration request to the trusted institution. The edge server registration request includes the edge server identity identifier; After receiving the edge server registration request, the trusted institution verifies the legality of the edge server identity identifier. If it is legal, a long-term public-private key is generated based on the edge server identity identifier, and the authentication credential of the edge server is calculated based on the hash operation. The trusted institution generates an associated authentication credential for each cloud server corresponding to the edge server and returns a response message to the edge server. The response message includes the private key of the edge server, the public identifier of the cloud server identity, the authentication credential, and the pseudonym for the authentication between the edge server and the cloud server; Store the edge server identity identifier, public key, and the pseudonym for the authentication between the edge server and the cloud server in the trusted institution to complete the identity registration of the edge server; The identity registration process of the user and the device specifically includes: The user selects a username and password, performs a hash operation on the username and password to obtain an encrypted password, and submits the calculated encrypted password, username, device identifier, behavior preferences, and geographical location as a user registration request to the trusted institution; After receiving the user registration request, the trusted institution calculates a unique communication identifier based on the username and device identifier, verifies the legality of the unique communication identifier. If it is legal, a long-term public-private key is generated based on the unique communication identifier, and an associated authentication credential for each edge server corresponding to the unique communication identifier is generated based on the behavior preferences and geographical location; Calculate user login data on the device based on the username, device identifier, and password, so that the device saves the user login data, private key, and the pseudonym for the authentication between the unique communication identifier and the edge server, and the trusted institution stores the unique communication identifier, username, device identifier, public key, and the pseudonym for the authentication between the unique communication identifier and the edge server to complete the identity registration of the user and the device; Step 2: After receiving the request information, the edge server verifies the legality of the device logged in by the user. After the verification passes, the edge server provides services to the user based on the request information; Step 3: During the process of providing services to the user, determine whether the service capabilities of the edge server meet the request information. If so, perform authentication and key negotiation between the edge server and the device logged in by the user, and provide services to the user after the negotiation is completed; if not, adaptively select a cloud server to perform authentication and key negotiation with the device logged in by the user, and provide services to the user after the negotiation is completed; The specific steps of Step 3 include: The device sends an authentication request to the edge server. The authentication request includes a service request, a pseudonym, a first random number, a timestamp, a first message authentication code, and a hash calculation value. The hash calculation value is obtained by performing a hash operation on the service request, the pseudonym, the random number, and the timestamp; After receiving the authentication request, the edge server determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the current hash calculation value is calculated, and it is determined whether the current hash calculation value is the same as the hash calculation value in the authentication request. If they are not the same, the authentication fails; if they are the same, the authentication is successful, and the service capabilities are judged. If the service capabilities of the edge server do not meet the request information, a cloud server is selected to perform authentication and key negotiation with the device logged in by the user, and services are provided to the user after the negotiation is completed; if the service capabilities of the edge server meet the request information, authentication and key negotiation are performed between the edge server and the device logged in by the user, and services are provided to the user after the negotiation is completed; The specific steps of performing authentication and key negotiation between the edge server and the device logged in by the user include: Randomly generate a second random number, calculate a second message authentication code based on the second random number, generate a session key, and extract the current timestamp. Calculate a hash value based on the second random number, the current timestamp, and the session key, and send the calculated hash value, the current timestamp, and the second message authentication code as an authentication message to the device; After receiving the authentication message, the device determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, calculate the current hash value based on the second message authentication code, and compare the current hash value with the hash value in the authentication message. If they are different, the authentication fails; if they are the same, the authentication passes, and the session key is saved; The specific steps of adaptively selecting a cloud server to perform authentication and key negotiation with the device logged in by the user include: Calculate a third message authentication code, and calculate the current hash value based on the third message authentication code, the pseudonym, and the timestamp. Send the calculated hash value, the third message authentication code, the pseudonym, the timestamp, and the service type to the selected cloud server; After receiving the data, the cloud server determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the fourth message authentication code is calculated, and it is determined whether the current hash operation value is the same as the hash value in the data received by the cloud server. If they are not the same, the authentication fails; if they are the same, the authentication passes, and the calculated hash value, the fourth message authentication code, and the current timestamp are sent to the edge server for verification. It is determined whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the fifth message authentication code is calculated, and it is determined whether the current hash operation value is the same as the hash value in the data received by the edge server. If they are not the same, the authentication fails; if they are the same, the authentication passes, and the calculated hash value, the fifth message authentication code, and the current timestamp are sent to the device. After receiving the data, the device determines whether the timestamp has expired. If it has expired, the authentication request is rejected; if it has not expired, the current hash operation value is calculated based on the fifth message authentication code, and it is determined whether the current hash operation value is the same as the hash value in the data received by the device. If they are not the same, the authentication fails; if they are the same, the authentication passes, and the session key is saved.

2. The adaptive identity authentication and key negotiation method in the cloud-edge-end environment according to claim 1, wherein, Before using the trust authority to register the identities of the user, the device, the edge server, and the cloud server, it further includes: using the trust authority to initialize the Hash function for system hash calculation, and publicly disclosing the calculated parameters within the network to complete system initialization.

3. An adaptive identity authentication and key negotiation method in a cloud-edge-terminal environment according to claim 1, characterized in that, The user logs in to the device, which specifically includes: The device calculates the current user login data based on the username, device identifier, and password input by the user. If the current user login data is the same as the preset user login data, the login is successful; if the current user login data is different from the preset user login data, the login fails.

Images