Self-adaptive identity authentication and key agreement method in cloud side end environment

Abstract

The invention discloses a self-adaptive identity authentication and key agreement method in a cloud side end environment, which comprises the following steps that: identity registration is carried out on a user, equipment, an edge server and a cloud server by utilizing a trust mechanism, and after identity registration is completed, the user logs in the equipment and sends request information of the user to the edge server in the range through the logged-in equipment; the edge server after receiving the request information provides service for the user: judging whether the service capability of the edge server meets the request information, if so, performing authentication and key negotiation between the edge server and the equipment logged in by the user, and providing service for the user after the authentication and key negotiation are completed; and if not, the cloud server is selected to perform authentication and key negotiation with the equipment logged in by the user, and the service is provided for the user after the authentication and key negotiation are completed. According to the method, different authentication modes can be executed in a self-adaptive mode, the equipment only needs to send out the authentication request once to meet the requirement, redundant authentication of the equipment is reduced, the load of the TA is reduced, and meanwhile the privacy of the equipment is protected.

Description

Technical Field

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

[0002] Cloud computing has become an important means to meet people's diverse needs. Its wide application covers various fields, from online medical diagnosis to video transmission of dashcams to daily conversations. Cloud computing has significant advantages in providing a variety of services, but it still has certain limitations for some highly time-sensitive businesses. For example, in terms of real-time data processing and low-latency communication, cloud computing often fails to achieve the expected results. In order to meet these challenges, edge computing has emerged. Edge computing effectively reduces latency and improves real-time performance by moving computing and data storage to the edge of the network, thereby meeting users' needs for time-sensitive businesses. However, edge computing itself has limited computing and storage capabilities, and still needs to rely on the support of cloud computing when processing large-scale and complex tasks. Today, the optimization and promotion of cloud-edge-end architecture has become a research hotspot. 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, there are the following disadvantages 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 device-edge authentication schemes, device-cloud authentication schemes, etc. However, these schemes are usually only applicable to a single scenario, for example, only considering the authentication between the edge and the user device or the authentication between the cloud and the user device, and failing to consider the comprehensive cloud-edge-end collaborative scenario. Due to the complexity of the cloud-edge-end collaborative scenario, for example, some time-sensitive services of users may require edge computing to complete, while services with large computing volume and high storage requirements require the assistance of cloud computing. Therefore, a scalable, adaptive and highly available cloud-edge-end collaborative authentication scheme is needed. In addition, due to the different requirements for system initialization and encryption algorithms, the integration difficulty is increased, and it is difficult to integrate these single-scenario solutions into a unified cloud-edge-end framework.

[0005] (2) Overload of Trust Authorities: Frequent interactions with Trust Authorities (TAs) or registries during the authentication process cause overload of TAs and registries, which may cause security issues.

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

[0007] The purpose of the present invention is to provide an adaptive identity authentication and key negotiation method in a cloud-edge 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-device environment, comprising:

[0009] Step 1: Use a trust agency 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 server within the set range through the logged-in device;

[0010] Step 2: After receiving the request information, the edge server verifies the legitimacy of the device logged in by the user, and provides services to the user based on the request information after the verification passes;

[0011] Step 3: In the process of providing services to 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, 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.

[0012] Optionally, before using the trust agency to register identities for users, devices, edge servers and cloud servers, it also includes: using the trust agency to initialize the hash function of the system hash calculation, and making the calculated parameters public in the network to complete the 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 agency, wherein the cloud server registration request includes the cloud server identity and the types of services provided; after receiving the cloud server registration request, the trust agency verifies the legitimacy of the cloud server identity, and if it is legal, generates a long-term public and private key based on the cloud server identity, and calculates the secret value of the cloud server based on a hash operation; the trust agency stores the calculated secret value, public key, and service type, and sends 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 agency, wherein the edge server registration request includes an edge server identity. After receiving the edge server registration request, the trust agency verifies the legitimacy of the edge server identity. If it is legal, a long-term public and private key is generated based on the edge server identity, and the authentication credential of the edge server is calculated based on a hash operation. The trust agency generates an associated authentication credential corresponding to each cloud server for the edge server, and returns a response message to the edge server, wherein 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 authentication between the edge server and the cloud server. The edge server identity, the public key, and the pseudonym for authentication between the edge server and the cloud server are stored in the trust agency 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 user name and password, performs a hash operation on the user name and password to obtain an encrypted password, and submits the calculated encrypted password, user name, device identification, behavior preference, and geographic location as a user registration request to a trust institution;

[0019] After receiving the user registration request, the trust agency calculates a unique communication identifier based on the user name and device identifier, verifies the legitimacy of the unique communication identifier, and if it is legitimate, generates a long-term public and private key based on the unique communication identifier, and generates an associated authentication credential corresponding to each edge server for the unique communication identifier based on the behavioral preference and geographic location;

[0020] The user login data is calculated on the device based on the user name, device identification and password, so that the device saves the user login data, the private key and the unique communication identification and the pseudonym authenticated by the edge server, and the trust agency stores the unique communication identification, the user name, the device identification, the public key and the pseudonym authenticated by the unique communication identification and the edge server, thereby completing the identity registration of the user and the device.

[0021] Optionally, the user logs in to the device, specifically including:

[0022] The device calculates the current user login data based on the user name, device identification and password entered 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, the step three specifically includes:

[0024] The device initiates an authentication request to the edge server, the authentication request including 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 being 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 is expired. If expired, the authentication request is rejected; if not expired, the current hash calculation value is calculated, and whether the current hash calculation value is consistent with the hash calculation value in the authentication request. If they are inconsistent, the authentication fails; if they are consistent, the authentication succeeds, and the service capability is judged. If the service capability of the edge server does not meet the request information, the cloud server is selected to perform authentication and key negotiation with the device logged in by the user, and the service is provided to the user after the negotiation is completed; if the service capability of the edge server meets the request information, the edge server and the device logged in by the user are authenticated and negotiated with the key, and the service is provided to the user after the negotiation is completed.

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

[0027] randomly generating a second random number, calculating a second message authentication code based on the second random number, generating a session key and extracting a current timestamp, calculating a hash value based on the second random number, the current timestamp and the session key, and sending the calculated hash value, the current timestamp and the second message authentication code as an authentication message to the device;

[0028] After receiving the authentication message, the device determines whether the timestamp is expired. If expired, the authentication request is rejected; if 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 adaptively selecting a cloud server to perform authentication and key negotiation with a device logged in by a user specifically includes:

[0030] Calculate a third message authentication code, calculate a current hash value based on the third message authentication code, the pseudonym, and the timestamp, and send the calculated hash value, the third message authentication code, the pseudonym, the timestamp, and the service type to the selected cloud server;

[0031] After receiving the data, the cloud server determines whether the timestamp is expired. If it is expired, the authentication request is rejected; if it is not expired, the fourth message authentication code is calculated, and the current hash operation value is determined to be 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 to determine whether the timestamp is expired. If it is expired, the authentication request is rejected; if it is not expired, the fifth message authentication code is calculated, and the current hash operation value is determined to be 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 is expired. If it is expired, the authentication request is rejected; if it is not expired, the current hash operation value is calculated based on the fifth message authentication code, and the current hash operation value is determined to be 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:

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

[0034] The edge server-assisted authentication architecture proposed in the present invention no longer frequently relies on a third-party trust agency TA during authentication and key negotiation, thereby reducing the load of the trust agency TA.

[0035] The lightweight authentication method proposed in the present invention is suitable for various scenarios with limited network resources and improves deployability.

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

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

[0039] Figure 1 This is a flow chart of cloud server registration in an embodiment of the present invention;

[0040] Figure 2 This is a flow chart of edge server registration in an embodiment of the present invention;

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

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

[0043] Figure 5 The present invention is a flowchart of the implementation of adaptive identity authentication and key negotiation in an embodiment of the present invention. DETAILED DESCRIPTION

[0044] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as limiting the present invention, but should be understood as a more detailed description of certain aspects, features, and embodiments of the present invention.

[0045] It should be understood that the terms described in the present invention are only for describing special embodiments and are not intended to limit the present invention. In addition, for the numerical range in the present invention, it should be understood that each intermediate value between the upper and lower limits of the scope is also specifically disclosed. Each smaller range between the intermediate value in any stated value or stated range and any other stated value or intermediate value in the described range is also included in the present invention. The upper and lower limits of these smaller ranges can be independently included or excluded in the scope.

[0046] Unless otherwise indicated, all technical and scientific terms used herein have the same meanings as those of ordinary skill in the art generally understood by the present invention. Although the present invention describes only preferred methods, any method similar or equivalent to that described herein may 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 the event of a conflict with any incorporated document, the content of this specification shall prevail.

[0047] It will be apparent to those skilled in the art that various modifications and variations may be made to the specific embodiments of the present invention description without departing from the scope or spirit of the present invention. Other embodiments derived from the present invention description will be apparent to those skilled in the art. The present application description and examples are exemplary only.

[0048] The words “include,” “including,” “have,” “contain,” etc. used in this article are open-ended terms, meaning including but not limited to.

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

[0050] Embodiment 1

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

[0052] Step 1: Use a trust agency 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 server within the set range through the logged-in device;

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

[0054] Step 3: In the process of providing services to 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, and provide services to the user after the negotiation is completed; if not, 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.

[0055] The authentication scenarios under the existing cloud-edge-end architecture are relatively simple, only considering the authentication between the cloud and user devices, and the authentication between the edge and user devices, without considering the cloud-edge-end collaboration scenario. One consequence of this situation is: for example, if the user device first initiates 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 will need to resend the service request and the authentication request to the cloud.

[0056] This embodiment takes into account the authentication in the cloud-edge-end collaboration scenario. The user device only needs to send an authentication request message once. If the edge meets the requirements, the user device and the edge directly perform identity authentication and key negotiation. 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 realized, that is, the user device does not need to send authentication request information frequently or repeatedly.

[0057] In view of the above problems, this embodiment proposes the following solutions:

[0058] First, we design a highly available cloud-edge collaborative authentication architecture to adaptively start different authentication methods based on the different needs of the devices, thus reducing the complexity and repetitive operations on the device side.

[0059] Secondly, during the authentication process, there is no need to frequently rely on the trusted authority TA, which reduces the load on the trusted authority TA.

[0060] Again, a lightweight authentication method is proposed, and a lightweight algorithm is used in the authentication process to reduce the authentication overhead.

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

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

[0063] This embodiment designs an adaptive and highly scalable cloud-edge collaborative authentication architecture: the architecture can effectively meet the real-time needs of the device. During the authentication process, the device can first send a service request to the edge server. If the edge server cannot meet the service requirements, it automatically requests assistance from the cloud server. In the process of requesting services, the architecture can adaptively start different authentication methods, thereby reducing the complex operation 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 the best service in different scenarios.

[0064] This embodiment proposes an edge server-assisted authentication architecture: Under this architecture, the authentication process no longer frequently relies on a third-party trust agency (trust agency 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 reliance on the trust agency TA, not only the burden of the trust agency TA is reduced, but also the security risks caused by the frequent calculations of the trust agency 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 a hash-based algorithm in the authentication process, avoiding complex elliptic curve cryptography (ECC) operations, thereby significantly reducing the computational overhead in the authentication process. The lightweight authentication method makes the scheme particularly suitable for various IoT devices with limited resources, ensuring that even devices with limited performance can perform efficient authentication operations, thereby improving the scope of application 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 when registering, and in the subsequent authentication process, 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, and the efficiency of the authentication operation is further improved.

[0067] This scheme consists of five stages. The first stage is system initialization, where the (trust authority TA) allocates public parameters to the system. The second stage is the legal registration of users, devices, edge servers (ESs) and cloud servers (CSs) with the trust authority TA to obtain the necessary credentials for authentication. The third stage is that users can only proceed with subsequent processes after necessary login operations on the device. 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 two-way authentication and key negotiation between devices and ESs. The second case is that with the assistance of ESs, devices perform two-way authentication and key negotiation with multiple CSs. The fifth stage is the user's password update.

[0068] Phase 1: System initialization.

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

[0070] Phase 2: Registration phase.

[0071] At this stage, Users, Devices, ESs, and CSs register their identities by providing registration information to the trusted authority TA through a secure channel.

[0072] ①Cloud Server CS Registration:

[0073] At this stage, CS k First select your own identity CID k , and then submit its registration request {CID k ,Services}, where Services is CS k The types of services that can be provided. After receiving the registration request, the trust agency TA will first check the CID kWhether it is legal, for example, whether it is a duplicate registration. If it is not legal, the request is rejected. If it is legal, the CID is generated based on the ECC algorithm or other algorithms. k Generate a long-term public-private key (SK k ,PK k ), it is worth noting that (SK k ,PK k ) and CID k It is a strong binding relationship for CID k Later, other scenes will be used. Finally, for CS k Calculate the secret value SC k =h(s||X). It should be noted here that the value of X is optional. It can be any value, but it cannot be repeated when registering with other entities.

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

[0075] ②ES registration:

[0076] (1)ES j First, select your EID j , and then submit its registration request {EID j}.

[0077] (2) After receiving the registration request, the trust agency TA will first check the EID j Is it legal, for example, whether it is a duplicate registration. If it is not legal, ignore the request. If it is legal, then use the ECC algorithm or other algorithms to calculate the EID. j Generate a long-term public-private key (SK j ,PK j ), it is worth noting that (SK j ,PK j ) and EID j It is a strong binding relationship for EID j It will be used in other scenarios later. j Generate authentication credentials SE j =h(s||X), it should be noted here that the value of X is optional, it can be any value, but it cannot be repeated when registering with other entities. j Used to verify the identity of the Device.

[0078] Then, the trust authority TA traverses ListCS() and finds ES j Generate an associated authentication credential corresponding to each CS. j Compared with a single CS (CS k )The process of generating associated authentication credentials:

[0079] In order to achieve ES j With CS k The anonymity of the authentication, the trust institution TA is ES j Computing and CS k Authentication pseudonym pid (x) j,k = h(Y), where Y can be any value and cannot be the same as other entities registered, and the generated pseudonym can be one or more, as well as multiple authentication credentials C (x) j,k =h(pid (x) j,k ||SC k ), where SC k For cloud server CS K The secret value of the response message {SK j ,(W k , PID j,k ,C j,k )}Return 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},W k Anything that can identify CS k Public identification of identity.

[0080] (3)ES j After receiving the response message from the trusted institution TA, save {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 ) is ES j With CS k The anonymous identity and authentication credentials of the communication. In reality, ES j During registration, the trust agency TA will provide the preferences and geographic location information provided by the ES, and select a customized CS sequence from the CS registered list. j Generate multiple (W x , PID j,x ,C j,x ), so that ES j Devices under the scope provide more services.

[0082] ③User and Device registration:

[0083] (1) First, the device user selects his own user name UID i and password PW i , then calculate the hash value EPW i =h(UID i ||PW i ), and finally submit {UID i , ID i , EPW i ,INFO}, where ID i For device D i INFO is the user's behavior preferences, geographic location and other information.

[0084] (2) After receiving the registration request, the trust agency TA will first calculate the UID i and ID i Combined unique communication identifier DID i =h(UID i ||ID i ||s), then check the DID i Is it legal, for example, whether it is a duplicate registration. If it is not legal, the request is ignored. If it is legal, the ECC algorithm or other algorithm is used for the DID i Generate a long-term public-private key (SK i ,PK i ).

[0085] The trust agency TA then creates a DID based on the INFO content. iSelect the most suitable ES sequence. For the convenience of description, this embodiment briefly describes DID i With a single ES (ES j )The process of generating associated authentication credentials:

[0086] In order to ensure the anonymity and unlinkability of user authentication, the trust agency TA is DID i Computing and ES j Authentication pseudonym pid (x) i,j = h(Y), where Y can be any value and cannot be the same as other entities registered, and the generated pseudonym can be one or more, as well as multiple authentication credentials a (x) i,j =h(pid (x) i,j ||SE j ), where SE j ES for edge servers j The secret value of b is then calculated. (x) i,j =EPW i ⊕a (x) i,j .

[0087] Finally, the response message {SK i ,(W j , PID i,j ,B i,j )}Return 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},W j Anything that can identify ES j Public identification of identity.

[0088] (3)D i Calculate Q i =H(UID i ||ID i ||PW i ), Q i For user UID i登录 D i Used. Di Save {Q i , S.K. 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 )}toListDID().

[0089] The third stage: login stage.

[0090] Login is the prerequisite for authentication and key negotiation. i登录 Equipment D i First, the user enters the UID i 、ID j , PW i , D i Calculate Q i '=H(UID i ||ID j ||PW i ), judge Q i 'Is it related to Q i If they are the same, the login is successful; if they are not the same, the login fails.

[0091] Phase 4: Authentication and key negotiation phase.

[0092] If User i Successfully logged in D i After, D i Instead of broadcasting the message to the CS, the ES sends its request message to the ES within its geographical range. The ES then verifies the D i If Di is legal and has been registered, ES provides services to the user according to the user's request. In order to improve the response efficiency of user requests, this embodiment defines two modes.

[0093] The first is that if the ES itself is capable of meeting the user's service needs, D i Authentication and key negotiation between the ES and the ES.

[0094] The second is that ES itself cannot meet the user's service needs, so it recommends the best CS service to the user, which may be one or more CSs. i The CS completes 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 If the services provided can meet the needs of users, then ES j No need to request cloud services. Then only D i With ES j Mutual authentication between the two parties. The mutual authentication process is as follows:

[0096] Step 1: D i Actively submit to ES j Initiate an authentication request, then D i Already received ES j The public identifier W broadcast within its control area j Calculation: EPW i =H(DID i ||PW i ). i Random from PID ij Randomly select pid (x) i,j With ES j Authentication, calculation Then randomly generate x1 and calculate Calculate the hash value ɑ=h(SerReq,pid (x) i,j ,x1,T i ). Then {SerReq, pid (x) i,j , M1, ɑ, T i}Send to ES j .

[0097] Step 2: Edgeserver: ES j Receive D i Authentication request information {SerReq, pid (x) i,j , M1, ɑ, T i}, first perform timestamp T i Test, if T i If it is expired, the authentication request is rejected. Otherwise, calculate: A ij =H(pid (x) i,j ||SE j ), and get 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, then device D i Authentication failed. Otherwise, Di Authentication passed. Then, check the information SerReq, if it is found that the device service requirements cannot be met, jump to mode 2, if it can be met: randomly generate x2, calculate Generate session key sk ji =h(A ij ||x1'||x2); extract timestamp T j , calculate the hash value β = h(sk ji ,x2,T j ), and finally the message {M2,β,T j}Return to D i .

[0098] Step 3: D i Receive ES j The authentication response information {M2,β,T j}, first perform timestamp T j Check, 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 not, then ES j Authentication failed. Otherwise, ES j Authentication passed, and the session key sessionKey=sk is stored ij .

[0099] ②Mode 2: This stage occurs in ES j If the services provided cannot meet the needs of users, ES j Need to be D i Request cloud services. This authentication method is also applicable to multi-cloud environments. Since users’ service requirements are diverse, ES j Multiple cloud services can be selected for users at the same time, and these selections are transparent to users, which means that ES assists in the authentication between users and CS. The specific process is as follows:

[0100] Step 1: Same as Mode 1, no further details are given here.

[0101] Step 2: The steps before checking the SerReq message are the same as those in mode 1 and will not be repeated here.

[0102] Check the information SerReq, find that the device service requirements cannot be met, and then select appropriate CSs based on the user 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 timestamp T k Test, if T k If it has expired, the authentication request is rejected. 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 they are not the same, the authentication fails. If they are the same, a random number x is generated. 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 {M4,υ,T l}Send to ES j .

[0104] Step 4: First, perform timestamp T l Test, if T l If it has expired, the authentication request is rejected. 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 they are the same, calculate M5 = S' j,k ⊕A i,j, ε=h(sk' ki ||S' j,k ||T m ), where T m is the timestamp. Then {M5,υ,T m}Send to D i .

[0105] Step 5: D i Receive ES j The authentication response information {M5,υ,T m}, first perform timestamp T m Test, if T m If it has expired, the authentication request is rejected. 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 ), determine whether ε' is the same as ε, if not, then ES j and CS k Authentication failed. Otherwise, ES j and CS k Authentication passed, and the session key sessionKey=sk is stored ij .

[0106] The authentication and key negotiation phase in this embodiment takes into account the authentication in the cloud-edge-end collaboration scenario. The user device only needs to send an authentication request message once. If the edge meets the requirements, the user device and the edge directly perform identity authentication and key negotiation. 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 realized, that is, the user device does not need to send authentication request information frequently or repeatedly.

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

[0108] The above is only a preferred specific implementation 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 a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An adaptive identity authentication and key negotiation method in a cloud-edge-device environment, characterized in that: include: Step 1: Use a trust agency 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 server within the set range through the logged-in device; Step 2: After receiving the request information, the edge server verifies the legitimacy of the device logged in by the user, and provides services to the user based on the request information after the verification passes; Step 3: In the process of providing services to 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, 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.

2. According to claim 1, the adaptive identity authentication and key agreement method in a cloud-edge-device environment is characterized in that: Before using the trust agency to register the identities of users, devices, edge servers and cloud servers, it also includes: using the trust agency to initialize the hash function of the system hash calculation, and making the calculated parameters public in the network to complete the system initialization.

3. According to the method of adaptive identity authentication and key negotiation in a cloud-edge-device environment of claim 1, it is characterized in that: The identity registration process of the cloud server specifically includes: The cloud server submits a cloud server registration request to the trust agency, wherein the cloud server registration request includes the cloud server identity and the types of services provided; after receiving the cloud server registration request, the trust agency verifies the legitimacy of the cloud server identity, and if it is legal, generates a long-term public and private key based on the cloud server identity, and calculates the secret value of the cloud server based on a hash operation; the trust agency stores the calculated secret value, public key, and service type, and sends the calculated secret value and private key to the cloud server to complete the identity registration of the cloud server.

4. According to claim 1, the adaptive identity authentication and key negotiation method in a cloud-edge-device environment is characterized in that: The identity registration process of the edge server specifically includes: The edge server submits an edge server registration request to the trust agency, wherein the edge server registration request includes an edge server identity. After receiving the edge server registration request, the trust agency verifies the legitimacy of the edge server identity. If it is legal, a long-term public and private key is generated based on the edge server identity, and the authentication credential of the edge server is calculated based on a hash operation. The trust agency generates an associated authentication credential corresponding to each cloud server for the edge server, and returns a response message to the edge server, wherein 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 authentication between the edge server and the cloud server. The edge server identity, the public key, and the pseudonym for authentication between the edge server and the cloud server are stored in the trust agency to complete the identity registration of the edge server.

5. According to claim 1, the adaptive identity authentication and key agreement method in a cloud-edge-device environment is characterized in that: The identity registration process of the user and the device specifically includes: The user selects a user name and password, performs a hash operation on the user name and password to obtain an encrypted password, and submits the calculated encrypted password, user name, device identification, behavior preference, and geographic location as a user registration request to a trust institution; After receiving the user registration request, the trust agency calculates a unique communication identifier based on the user name and device identifier, verifies the legitimacy of the unique communication identifier, and if it is legitimate, generates a long-term public and private key based on the unique communication identifier, and generates an associated authentication credential corresponding to each edge server for the unique communication identifier based on the behavioral preference and geographic location; The user login data is calculated on the device based on the user name, device identification and password, so that the device saves the user login data, the private key and the unique communication identification and the pseudonym authenticated by the edge server, and the trust agency stores the unique communication identification, the user name, the device identification, the public key and the pseudonym authenticated by the unique communication identification and the edge server, thereby completing the identity registration of the user and the device.

6. According to claim 1, the adaptive identity authentication and key negotiation method in a cloud-edge-device environment is characterized in that: The user login device specifically includes: The device calculates the current user login data based on the user name, device identification and password entered 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.

7. According to claim 1, the adaptive identity authentication and key agreement method in a cloud-edge-device environment is characterized in that: The step three specifically includes: The device initiates an authentication request to the edge server, the authentication request including 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 being 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 is expired. If expired, the authentication request is rejected; if not expired, the current hash calculation value is calculated, and whether the current hash calculation value is consistent with the hash calculation value in the authentication request. If they are inconsistent, the authentication fails; if they are consistent, the authentication succeeds, and the service capability is judged. If the service capability of the edge server does not meet the request information, the cloud server is selected to perform authentication and key negotiation with the device logged in by the user, and the service is provided to the user after the negotiation is completed; if the service capability of the edge server meets the request information, the edge server and the device logged in by the user are authenticated and negotiated with the key, and the service is provided to the user after the negotiation is completed.

8. According to claim 7, the adaptive identity authentication and key negotiation method in a cloud-edge-device environment is characterized in that: The authentication and key negotiation between the edge server and the device logged in by the user specifically includes: randomly generating a second random number, calculating a second message authentication code based on the second random number, generating a session key and extracting a current timestamp, calculating a hash value based on the second random number, the current timestamp and the session key, and sending 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 is expired. If expired, the authentication request is rejected; if 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.

9. According to claim 7, the adaptive identity authentication and key agreement method in a cloud-edge-device environment is characterized in that: The adaptive selection of a cloud server to perform authentication and key negotiation with a device logged in by a user specifically includes: Calculate a third message authentication code, calculate a current hash value based on the third message authentication code, the pseudonym, and the timestamp, and 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 is expired. If it is expired, the authentication request is rejected; if it is not expired, the fourth message authentication code is calculated, and the current hash operation value is determined to be 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 to determine whether the timestamp is expired. If it is expired, the authentication request is rejected; if it is not expired, the fifth message authentication code is calculated, and the current hash operation value is determined to be 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 is expired. If it is expired, the authentication request is rejected; if it is not expired, the current hash operation value is calculated based on the fifth message authentication code, and the current hash operation value is determined to be 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.

Images