CN113765658A - Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture - Google Patents

Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture Download PDF

Info

Publication number
CN113765658A
CN113765658A CN202110970858.0A CN202110970858A CN113765658A CN 113765658 A CN113765658 A CN 113765658A CN 202110970858 A CN202110970858 A CN 202110970858A CN 113765658 A CN113765658 A CN 113765658A
Authority
CN
China
Prior art keywords
user
cloud server
internet
control server
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110970858.0A
Other languages
Chinese (zh)
Inventor
黄辉辉
武泽慧
王红敏
李泽村
刘厚志
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Information Engineering University of PLA Strategic Support Force
Original Assignee
Information Engineering University of PLA Strategic Support Force
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Information Engineering University of PLA Strategic Support Force filed Critical Information Engineering University of PLA Strategic Support Force
Priority to CN202110970858.0A priority Critical patent/CN113765658A/en
Publication of CN113765658A publication Critical patent/CN113765658A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The invention discloses an authentication and key agreement protocol method for equipment of the Internet of things in a distributed cloud computing architecture. The method comprises a registration stage, a login stage and an authentication and key agreement stage; the authentication and key agreement phase includes: first handshake process: user UiTo cloud server S through its internet of things devicemSending a login message, SmAfter receiving the login message, calculating the authentication condition of the user, and sending the authentication condition and the login message to the control server CS; second handshake process: CS receives from SmAfter the message, verify UiAnd SmIf the two are legal, they are respectively UiAnd SmGenerating its own identity verification condition and sending to Sm(ii) a Third hand of shakeThe process is as follows: smSelects an authentication condition associated with itself to authenticate the CS and sends another authentication condition to the UiThe internet of things device of (1); the fourth handshake process: u shapeiThe Internet of things equipment verifies the validity of the CS according to the authentication condition, and if the CS passes the verification, the U passesi、SmFinally negotiating with CS to obtain a shared secret key SK h (N)m||NCS||Ni)。

Description

Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture
Technical Field
The invention relates to the technical field of information security, in particular to a high-efficiency authentication and key agreement protocol design method used among a plurality of internet of things devices in a distributed cloud computing architecture.
Background
In recent years, internet of things (IoT) devices, such as sensor devices, RFID tags, actuators, and smart terminals, are increasingly used in daily life to provide people with convenient lives. In the construction process of the smart city, the main functions of the Internet of things equipment are interconnected and intercommunicated in a heterogeneous wireless environment, and the equipment can continuously monitor and analyze various application data from the city so as to realize the real-time automation of the smart decision process of the smart city. However, as is well known, the internet of things device resources are limited, and the amount of data in a smart city is huge, which generally grows exponentially with the data and devices, so that a standard platform is required to centrally process a large amount of heterogeneous data and devices. To handle such a large database repository generated by various internet of things devices, cloud computing is an effective solution. Currently, cloud providers offer various types of cloud services, such as software as a service cloud (SaaS) (e.g., IBM lotus live), platform as a service (PaaS) (e.g., Google appeengine), and infrastructure as a service (IaaS) (e.g., amazon web services).
However, with the widespread use of internet of things and cloud computing in smart cities, various security and privacy challenges may be encountered, the most basic of which is mutual authentication between various application devices, such as participating users, internet of things devices, distributed servers, data control centers, and the like. In fig. 1, we simply present a scenario: assuming that a cloud computing service provider has already built a distributed private cloud environment covering the whole smart city, in the operation process of the smart city, a plurality of internet of things devices need to upload application data generated in real time to the private cloud service closest to the internet of things devices, and each distributed private cloud service is subjected to primary computing and then converges data to a cloud service center, namely a data control center, so that real-time communication perception among the devices is realized through high-speed computing and intelligent scheduling of the cloud service center, and high-quality service is provided. Three main entities are mainly involved in this scenario: the system comprises a cloud computing provider, namely a data control center, a single distributed private cloud server and equipment terminals which are connected with each support in a network. In the process, the distributed private cloud server generally stores the privacy information from the internet of things equipment, and only a legal user can access the sensitive information, so that mutual authentication between two entities needs to be realized. Similarly, mutual authentication between the distributed private server and the data control center is required. In addition, after mutual authentication is implemented between the devices, since mutual communication data is mostly transmitted through the open internet, in order to ensure the confidentiality of the data, it is also necessary to generate a shared key for sealing the next communication traffic after the mutual authentication is implemented by the three entities.
Recently, many authentication protocols integrated with the internet of things and distributed cloud computing have been proposed for secure access control of large-scale internet of things networks. In 2018, Amin et al (document 1 "r.amin, n.kumar, g.p.biswas, r.iqbal, and v.chang, a light weight authentication protocol for IoT-enabled devices in distributed Cloud Computing environment, Future Generation Computer Systems, vol.78, pp.01") proposed an authentication protocol for internet of things devices in a distributed Cloud Computing environment, indicating a number of security vulnerabilities in two authentication protocols proposed by Xue et al and Chuang et al, respectively. However, Kang et al (document 2: Kang B, Han Y, Qian K, et al, analysis and Improvement on an Authentication Protocol for IoT-Enabled Devices in Distributed Cloud Computing Environment [ J ]. physical schemes in Engineering,2020, (2):1-6) found that the Amin et al Protocol was susceptible to forgery attacks and improved the Protocol. However, through a large amount of research on authentication protocols, the inventors further found that an offline password guessing attack on the protocol of Kang et al is performed, that is, a malicious user can easily obtain a master key of a master control server, and the master key is a key parameter of the entire system, which may cause all information of the entire system to be leaked.
In addition, as the protocols are designed for communication among internet of things devices, as is well known, the devices are developed based on an embedded mode, generally, computing resources and storage resources are limited, and in the actual use process, the real-time requirement of communication is high, the data operation efficiency is high, and if a mainstream encryption algorithm is adopted, the requirements are difficult to meet. Therefore, designing these protocols also requires considering the computational complexity of the protocol implementation while ensuring the confidentiality of the communication.
Disclosure of Invention
In order to meet mutual authentication and encryption communication among application equipment under a distributed cloud architecture based on the Internet of things in a smart city, the invention provides a high-efficiency authentication and key agreement protocol design method for the Internet of things equipment in the distributed cloud computing architecture.
The invention provides an authentication and key agreement protocol method of Internet of things equipment in a distributed cloud computing architecture, which comprises a registration stage, a login stage and an authentication and key agreement stage, wherein the authentication and key agreement stage comprises the following steps:
first handshake process: user UiTo cloud server S through its internet of things devicemSending a login message, cloud Server SmReceiving user UiAfter the login message, calculating the authentication condition of the user, and comparing the authentication condition of the user with the authentication condition of the user UiThe login message is sent to the control server CS;
second handshake process: the control server CS receives the data from the cloud server SmAfter the message, the user U is authenticatediAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating its own authentication conditions, and sending the generated two authentication conditions to the cloud serviceDevice Sm；
Third handshake process: cloud server SmSelects an authentication condition related to itself from the two received authentication conditions to authenticate the control server CS, and sends the other authentication condition to the user UiThe internet of things device of (1);
the fourth handshake process: user UiThe Internet of things equipment verifies the validity of the control server CS according to the received identity verification condition, and if the control server CS passes the verification, the user UiCloud server SmFinally negotiating with the control server CS to obtain a shared secret key SK h (N)m||NCS||Ni) (ii) a Wherein N ismIndicating that the first handshake process is performed by the cloud server SmA 128-bit random number, N, is generatedCSRepresenting a 128-bit random number, N, generated by the control server CS during the second handshakeiRepresenting a user UiOn-login cloud server SmA random number of at least 128 bits generated;
in the four-way handshake process, only the user U needs to be usediCloud server SmAnd the control server CS fails to authenticate, the session ends.
Further, in the first handshake process, the cloud server SmReceiving user UiAfter the login message, the method further comprises:
cloud server SmExamination conditions TSm-TSi<Whether delta T is established or not, if yes, the cloud server SmCalculating the identity verification condition of the user, specifically comprising: cloud server SmGenerating a 128-bit random number NmAnd calculate
Figure BDA0003225600800000031
Ki＝h(Nm||BSm||PIDi||Gi||TSm)；
Correspondingly, the cloud server SmThe authentication condition of the user U and the user UiThe sending of the login message to the control server CS specifically includes: cloud server SmWill be provided with<Ji,Ki,PSIDm,Gi,Fi,Zi,PIDi,TSi,TSm>Sending to the control server CS;
wherein the content of the first and second substances,<Gi,Fi,Zi,PIDi,TSi>representing a user UiThe log-in message of (a) is,<Ji,Ki,PSIDm,TSm>representing cloud Server SmAuthentication condition of (TS)mRepresenting cloud Server SmCurrent time stamp of, TSiRepresenting a user UiThe current time stamp of the Internet of things equipment, delta T represents a set time threshold value, BSmRepresenting cloud Server SmSymmetric key with control server CS, PIDiRepresenting a user UiPseudo-identity of, PSIDmRepresenting cloud Server SmPseudo-identity of, Bm、Ji、Ki、Gi、FiAnd ZiAll represent intermediate operation results, h (-) represents a hash function, and | | represents splicing operation.
Further, in the second handshake process, the control server CS receives the information from the cloud server SmAfter the message, further comprising: control Server CS checks Condition TSCS-TSm<Whether the delta T is established or not, if yes, verifying the user UiAnd cloud server SmThe validity of (2);
correspondingly, the authentication user UiAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating the authentication conditions of the cloud server S and sending the generated two authentication conditions to the cloud server SmThe method specifically comprises the following steps:
step A1: control server CS computation
Di＝h(PIDi||x)
Figure BDA0003225600800000041
Figure BDA0003225600800000042
Figure BDA0003225600800000043
Step A2: control server CS checking condition
Figure BDA0003225600800000044
If yes, the control server CS verifies the user UiLegality;
step A3: control server CS computation
BSm＝h(PSIDm||SIDm||y)
Figure BDA0003225600800000045
Step A4: control server CS checking condition
Figure BDA0003225600800000051
If yes, the control server CS verifies the cloud server SmLegality;
step A5: the control server CS generates a 128-bit random number NCSAnd calculate
Figure BDA0003225600800000052
Figure BDA0003225600800000053
SKCS＝h(Ni||Nm||NCS)
Figure BDA0003225600800000054
Figure BDA0003225600800000055
Step A6: through the common channel<PCS,QCS,RCS,VCS>Sending to cloud server Sm；
Wherein, TSCSRepresenting the current timestamp of the control server CS, x representing a timestamp known only to the control server CS for authenticating the user UiSecret key, ID ofiRepresenting a user UiTrue identity of, SIDmRepresenting cloud Server SmTrue identity of SKCSRepresenting a shared secret generated by the CS side of the control server, RCSAnd VCSIndicating that the control server CS is a cloud server SmGenerated authentication condition, PCSAnd QCSIndicating that control server CS is user UiGenerated authentication conditions, DiRepresenting a symmetric key between the internet of things device and the control server CS,
Figure BDA0003225600800000056
and
Figure BDA0003225600800000057
respectively representing means for authenticating a user UiAnd cloud server SmThe legitimacy of and the parameters of the integrity of the data transmission,
Figure BDA0003225600800000058
representing an exclusive or operation.
Further, the third handshake process specifically includes:
first, the cloud server SmComputing
Wm＝h(BSm||Nm)
Figure BDA0003225600800000059
Figure BDA00032256008000000510
Then, the cloud server SmExamination conditions
Figure BDA00032256008000000511
Whether it is, if it is, the cloud server SmThe authentication control server CS passes and will pass<PCS,QCS>Sent to user UiThe internet of things device of (1);
wherein SKmRepresenting cloud Server SmEnd-generated shared secret, WmThe result of the intermediate operation is represented,
Figure BDA0003225600800000061
a parameter representing the authenticity of the identity used to verify the control server CS;
further, the fourth handshake process specifically includes:
first, user UiInternet of things equipment computing
Li＝h(Ni||Di||Fi)
Figure BDA0003225600800000062
SKi＝h(Nm||NCS||Ni)
Figure BDA0003225600800000063
Then, the user UiInternet of things equipment inspection condition
Figure BDA0003225600800000064
If true, user UiConfirm that the control server CS is authentic;
wherein L isiRepresenting the result of an intermediate operation, SKiRepresenting a user UiThe shared secret key generated by the device side of the internet of things,
Figure BDA0003225600800000065
respectively, representing parameters for verifying the authenticity of the identity of the control server CS.
Further, the registration stage is divided into a cloud server registration stage and a user registration stage; wherein: the cloud server registration stage specifically includes:
cloud server SmWill register the message<SIDm,d>Sending to the control server CS; wherein SIDmRepresenting cloud Server SmD is a random number;
the control server CS receives the information from the cloud server SmAfter the registration message, calculate the PSIDm＝h(SIDm||d)，BSm＝h(PSIDm||SIDmY) and will be transmitted via a secure channel<BSm>Send back cloud server Sm(ii) a Wherein, PSIDmRepresenting cloud Server SmY denotes a pseudo identity known only to the control server CS for authenticating the cloud server SmOf the secret key, BSmRepresenting cloud Server SmA symmetric key with the control server CS, h (-) represents a hash function;
cloud server SmSecret parameters<BSm,d>And storing the data in the memory.
Further, the user registration stage specifically includes:
user UiSelecting the desired real identity IDiAnd a password PiEntering the Internet of things equipment;
internet of things equipment collection user UiBiological characteristics of (B)iAnd generates a random number b to calculate the PIDi＝h(IDi||b)，
Figure BDA0003225600800000071
And
Figure BDA0003225600800000072
wherein, PIDiRepresenting a user UiPseudo-identity of, AiAnd ΩiAll of which represent the results of the intermediate operations,
Figure BDA0003225600800000073
representing an exclusive or operation;
internet of things equipment registers message<IDi,PIDi,Ai>Sending the data to a control server CS through a secure channel;
the control server CS verifies the ID after receiving the registration message from the Internet of things equipmentiIs true of, if IDiIs illegal, the control server CS will reject the user UiRegistering; otherwise, the control server CS calculates Ci＝h(PIDi||Ai)，Di＝h(PIDi| x) and
Figure BDA0003225600800000074
wherein x denotes a user U known only to the control server CS for authenticationiSecret key of DiRepresenting a symmetric key between the Internet of things device and the control server CS, CiAnd EiAll represent intermediate operation results;
control server CS sends data<Ci,Ei,h(·)>Write in the smart card and deliver it to the user U by dedicated communicationi；
User UiAfter the smart card is obtained, the smart card is inserted into the Internet of things equipment, and the ID is input into the Internet of things equipment againiAnd PiSo as to write omega into the smart card through the equipment of the Internet of thingsiRecording information by smart card<Ci,Ωi,Ei,h(·)>。
Further, the login stage specifically includes:
when the user UiWant to slave cloud server SmObtaining information, user UiSmart cardInsert an internet of things device and provide
Figure BDA0003225600800000075
Pi *And
Figure BDA0003225600800000076
wherein the content of the first and second substances,
Figure BDA0003225600800000077
Pi *and
Figure BDA0003225600800000078
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure BDA0003225600800000079
And
Figure BDA00032256008000000710
examination conditions
Figure BDA00032256008000000711
If yes, the user UiIs true, otherwise, the user U is rejectediLogging in;
if the user UiIs true, the Internet of things equipment generates a random number N with at least 128 bitsiAnd calculate
Figure BDA00032256008000000712
PIDi＝h(IDi||b)
Figure BDA0003225600800000081
Gi＝h(PIDi||SIDm||Ni||TSi||Di)
Figure BDA0003225600800000082
Figure BDA0003225600800000083
Wherein, TSiIs the current timestamp, SID, of the Internet of things devicemIs a cloud server SmTrue identity of Gi、FiAnd ZiAll represent intermediate operation results;
the Internet of things equipment is connected with the Internet of things equipment through a public channel<Gi,Fi,Zi,PIDi,TSi>Transmitting to a cloud Server Sm。
Further, still include: the password changing stage specifically includes:
user UiInserting the smart card into the Internet of things device and then providing
Figure BDA0003225600800000084
Pi *And
Figure BDA0003225600800000085
wherein the content of the first and second substances,
Figure BDA0003225600800000086
Pi *and
Figure BDA0003225600800000087
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure BDA0003225600800000088
And
Figure BDA0003225600800000089
examination conditions
Figure BDA00032256008000000810
Whether the current time is established or not, if so, prompting the user UiInputting new password Pi newAnd generates a random number
Figure BDA00032256008000000811
Otherwise, rejecting user UiPassword change of (2);
then, the Internet of things equipment calculates
Figure BDA00032256008000000812
Figure BDA00032256008000000813
Figure BDA00032256008000000814
Figure BDA00032256008000000815
Figure BDA00032256008000000816
Figure BDA00032256008000000817
Internet of things equipment records original values in smart card<Ci,Ωi,Ei>Is replaced by
Figure BDA00032256008000000818
Further, still include: the identity change stage specifically includes: user UiRe-registering to the control server CS over a secure channel.
The invention has the beneficial effects that:
1. the scheme of the invention is lightweight protocol authentication, and is more suitable for terminal equipment of the Internet of things with limited calculation and storage. In consideration of the characteristics that the computing resources and the storage capacity of the Internet of things terminal accessed to the cloud server are limited and the real-time requirement is high in the construction process of the smart city, the implementation efficiency is fully improved and the requirement of the environment is met only by using exclusive-or operation and Hash operation in the design process of the scheme of the invention;
2. the scheme fully considers the confidentiality of communication. On one hand, the method adopts a login mode of anonymous identity to fully protect the identity information of the user; on the other hand, in the user login authentication process, a shared key is also negotiated for encrypting subsequent communication data and resisting a man-in-the-middle to acquire communication information;
3. resisting off-line password guessing attack. The scheme of the invention fully considers the identity authentication among the three participating bodies during the design so as to resist the attack of off-line password guessing after a malicious attacker impersonates the identity attack. For example, during the cloud server registration phase, by calculating the PSIDm＝h(SIDmD) and BSm＝h(PSIDm||SIDmY), ensure cloud server's identity SIDmIs bound to the private key y of the control server, so that a malicious attacker, if taking an impersonation identity attack, has to obtain the private key y of the control server, which is not possible. Moreover, since d is randomly generated by the cloud server, the cost of an attacker for performing offline password guessing attack can be greatly increased.
Drawings
Fig. 1 is a schematic diagram of a distributed cloud architecture based on the internet of things in a smart city according to an embodiment of the present invention;
fig. 2 is a flowchart of an authentication and key agreement protocol method for an internet of things device in a distributed cloud computing architecture according to an embodiment of the present invention;
fig. 3 is a flowchart of the first three stages of an authentication and key agreement protocol method for an internet of things device in a distributed cloud computing architecture according to an embodiment of the present invention;
fig. 4 is a part of HLPSL emulation codes of an authentication and key agreement protocol method for an internet of things device in a distributed cloud computing architecture according to an embodiment of the present invention;
fig. 5 is a code description of a CS role of a control server in SPDL according to an embodiment of the present invention;
fig. 6 is a simulation result of the AVISPA tool under four back-end analyses provided by the embodiment of the present invention;
fig. 7 shows simulation results of the Scyther tool provided in the embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly described below with reference to the accompanying drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In order to meet mutual authentication and encryption communication among application equipment under a distributed cloud architecture based on the Internet of things in a smart city, the invention designs a security authentication and key agreement scheme using a smart card based on lightweight dynamic anonymous identity, and the scheme is proved to be efficient and safe. The current scenario involves 3 main entities: control server CS and cloud server SmAnd each internet of things device supporting internet of things; wherein the Internet of things equipment belongs to a user Ui。
The authentication and key agreement protocol method for the internet of things equipment in the distributed cloud computing architecture provided by the embodiment of the invention is divided into 5 stages: (1) the method comprises the following steps of (1) registering, (2) logging in, (3) authenticating and carrying out key agreement, (4) password changing and (5) identity updating. Wherein, the stage (3) is the core of the method of the invention. It should be noted that, in the last two stages, whether to add or delete can be selected according to the needs of the application scenario.
As an implementable manner, as shown in fig. 2, the authentication and key agreement phase in the embodiment of the present invention includes the following steps:
first handshake process: user UiTo cloud server S through its internet of things devicemSending a login message, cloud Server SmReceiving user UiAfter the login message, calculating the authentication condition of the user, and comparing the authentication condition of the user with the authentication condition of the user UiThe login message is sent to the control server CS;
in particular, cloud server SmReceiving user UiAfter the login message, the method further comprises: cloud server SmExamination conditions TSm-TSi<Whether delta T is established or not, if yes, the cloud server SmCalculating the identity verification condition of the user, specifically comprising: cloud server SmGenerating a 128-bit random number NmAnd calculate
Figure BDA0003225600800000101
Ki＝h(Nm||BSm||PIDi||Gi||TSm)；
Correspondingly, the cloud server SmThe authentication condition of the user U and the user UiThe sending of the login message to the control server CS specifically includes: cloud server SmWill be provided with<Ji,Ki,PSIDm,Gi,Fi,Zi,PIDi,TSi,TSm>Sending to the control server CS;
wherein the content of the first and second substances,<Gi,Fi,Zi,PIDi,TSi>representing a user UiThe log-in message of (a) is,<Ji,Ki,PSIDm,TSm>representing cloud Server SmAuthentication condition of (TS)mRepresenting cloud Server SmCurrent time stamp of, TSiRepresenting a user UiThe current time stamp of the Internet of things equipment, delta T represents a set time threshold value, BSmRepresenting cloud Server SmSymmetric key with control server CS, PIDiRepresenting a user UiThe identity of the pseudo-identity of (c),PSIDmrepresenting cloud Server SmPseudo-identity of, Bm、Ji、Ki、Gi、FiAnd ZiAll represent intermediate operation results, h (-) represents a hash function, and | | represents splicing operation.
Second handshake process: the control server CS receives the data from the cloud server SmAfter the message, the user U is authenticatediAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating the authentication conditions of the cloud server S and sending the generated two authentication conditions to the cloud server Sm；
Specifically, in the second handshake process, the control server CS receives a request from the cloud server SmAfter the message, further comprising: control Server CS checks Condition TSCS-TSm<Whether the delta T is established or not, if yes, verifying the user UiAnd cloud server SmThe validity of (2);
correspondingly, the authentication user UiAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating the authentication conditions of the cloud server S and sending the generated two authentication conditions to the cloud server SmThe method specifically comprises the following steps:
step A1: control server CS gets the message<Ji,Ki,PSIDm,Gi,Fi,Zi,Oi,PIDi,TSi,TSm>Thereafter, the control server CS calculates
Di＝h(PIDi||x)
Figure BDA0003225600800000111
Figure BDA0003225600800000112
Figure BDA0003225600800000113
Step A2: control server CS checking condition
Figure BDA0003225600800000114
If yes, the control server CS verifies the user UiLegality; otherwise, the control server CS terminates the session;
step A3: user UiAfter the validity is verified, the control server CS calculates
BSm＝h(PSIDm||SIDm||y)
Figure BDA0003225600800000121
Step A4: control server CS checking condition
Figure BDA0003225600800000122
If yes, the control server CS verifies the cloud server SmLegality; if the cloud server S is not established, the control server CS considers the cloud server SmIllegally, terminating the session;
step A5: cloud server SmAfter the validity is verified, the control server CS generates a 128-bit random number NCSAnd calculate
Figure BDA0003225600800000123
Figure BDA0003225600800000124
SKCS＝h(Ni||Nm||NCS)
Figure BDA0003225600800000125
Figure BDA0003225600800000126
Step A6: through the common channel<PCS,QCS,RCS,VCS> send to cloud Server Sm；
Wherein, TSCSRepresenting the current timestamp of the control server CS, x representing a timestamp known only to the control server CS for authenticating the user UiSecret key, ID ofiRepresenting a user UiTrue identity of, SIDmRepresenting cloud Server SmTrue identity of SKCSRepresenting a shared secret generated by the CS side of the control server, RCSAnd VCSIndicating that the control server CS is a cloud server SmGenerated authentication condition, PCSAnd QCSIndicating that control server CS is user UiGenerated authentication conditions, DiRepresenting a symmetric key between the internet of things device and the control server CS,
Figure BDA0003225600800000127
and
Figure BDA0003225600800000128
respectively representing means for authenticating a user UiAnd cloud server SmThe legitimacy of and the parameters of the integrity of the data transmission,
Figure BDA0003225600800000129
representing an exclusive or operation.
Third handshake process: cloud server SmSelects an authentication condition related to itself from the two received authentication conditions to authenticate the control server CS, and sends the other authentication condition to the user UiThe internet of things device of (1);
specifically, first, the cloud server SmReceiving messages from a control server CS<PCS,QCS,RCS,VCSAfter that, cloud server SmComputing
Wm＝h(BSm||Nm)
Figure BDA0003225600800000131
Figure BDA0003225600800000132
Then, the cloud server SmExamination conditions
Figure BDA0003225600800000133
Whether it is, if it is, the cloud server SmThe authentication control server CS passes and will pass<PCS,QCSTo user UiThe internet of things device of (1);
wherein SKmRepresenting cloud Server SmEnd-generated shared secret, WmThe result of the intermediate operation is represented,
Figure BDA0003225600800000134
a parameter representing the authenticity of the identity used to verify the control server CS;
the fourth handshake process: user UiThe Internet of things equipment verifies the validity of the control server CS according to the received identity verification condition, and if the control server CS passes the verification, the user UiCloud server SmFinally negotiating with the control server CS to obtain a shared secret key SK h (N)m||NCS||Ni) (ii) a Wherein N ismIndicating that the first handshake process is performed by the cloud server SmA 128-bit random number, N, is generatedCSRepresenting a 128-bit random number, N, generated by the control server CS during the second handshakeiRepresenting a user UiOn-login cloud server SmAnd then generating a random number of at least 128 bits.
Specifically, firstUser UiIOT (Internet of things) equipment slave cloud server SmReceiving a message<PCS,QCS>Thereafter, the user UiInternet of things equipment computing
Li＝h(Ni||Di||Fi)
Figure BDA0003225600800000135
SKi＝h(Nm||NCS||Ni)
Figure BDA0003225600800000141
Then, the user UiInternet of things equipment inspection condition
Figure BDA0003225600800000142
If true, user UiConfirm that the control server CS is authentic;
finally, the user UiCloud server SmNegotiating with the 3 participants of the control server CS to obtain a shared key SK-h (N)m||NCS||Ni)。
Wherein L isiRepresenting the result of an intermediate operation, SKiRepresenting a user UiShared secret key, Q generated by equipment end of Internet of things* CSRespectively, representing parameters for verifying the authenticity of the identity of the control server CS.
It should be noted that, in the four-way handshake process, only the user U needs to be presentiCloud server SmAnd the control server CS fails to authenticate, the session ends.
As can be seen from the above embodiments, ultimately, the entire authentication path (U)i→Sm→CS→Sm→Ui) Is established. At the same time, the negotiation results in a shared key SK, which is used to encrypt the user UiAnd cloud servicesDevice SmTo the subsequent communication traffic therebetween.
Before entering the authentication and key agreement stage, registration and login are required to be performed, and as an implementable mode, the registration stage in the embodiment of the invention is divided into a cloud server registration stage and a user registration stage;
in the registration phase, the control server CS randomly generates two high-entropy numbers x and y in advance, where x is used as a key known only to CS for authenticating all users UiY is used as a key known only to CS for authenticating all cloud servers SmThe key of (2). Then, any cloud server SmAnd user UiMay be registered with the CS.
The cloud server registration stage specifically comprises the following steps:
cloud server SmWill register the message<SIDm,d>Sending to the control server CS; wherein SIDmRepresenting cloud Server SmD is a random number;
the control server CS receives the information from the cloud server SmOf a registration message<SIDm,d>Then, calculate PSIDm＝h(SIDm||d)，BSm＝h(PSIDm||SIDmY) and will be transmitted via a secure channel<BSm>Send back cloud server Sm(ii) a Wherein, PSIDmRepresenting cloud Server SmY denotes a pseudo identity known only to the control server CS for authenticating the cloud server SmOf the secret key, BSmRepresenting cloud Server SmA symmetric key with the control server CS, h (-) represents a hash function;
cloud server SmSecret parameters<BSm,d>And storing the data in the memory.
The user registration stage specifically includes:
when the user UiWhen wishing to register with the control server CS, the user UiSelecting the desired real identity IDiAnd a password PiEntering its internet of things device (e.g., card reader);
internet of things equipmentCollect user UiBiological characteristics of (B)iAnd generates a random number b to calculate the PIDi＝h(IDi||b)，
Figure BDA0003225600800000151
And
Figure BDA0003225600800000152
wherein, PIDiRepresenting a user UiPseudo-identity of, AiAnd ΩiAll of which represent the results of the intermediate operations,
Figure BDA0003225600800000153
representing an exclusive or operation;
internet of things equipment registers message<IDi,PIDi,Ai>Sending the data to a control server CS through a secure channel;
the control server CS verifies the ID after receiving the registration message from the Internet of things equipmentiIs true of, if IDiIs illegal, the control server CS will reject the user UiRegistering; otherwise, the control server CS calculates Ci＝h(PIDi||Ai)，Di＝h(PIDi| x) and
Figure BDA0003225600800000154
wherein x denotes a user U known only to the control server CS for authenticationiSecret key of DiRepresenting a symmetric key between the Internet of things device and the control server CS, CiAnd EiAll represent intermediate operation results;
control server CS sends data<Ci,Ei,h(·)>Write in the smart card and deliver it to the user U by dedicated communicationi；
User UiAfter the smart card is obtained, the smart card is inserted into the Internet of things equipment, and the ID is input into the Internet of things equipment againiAnd PiSo as to write omega into the smart card through the equipment of the Internet of thingsiRecording information by smart card<Ci,Ωi,Ei,h(·)>
It should be noted that the "secure channel" in the registration phase may be internet key exchange protocol version 2 or secure socket layer protocol (SSL).
As an implementable manner, the login stage in the embodiment of the present invention specifically includes:
when the user UiWant to slave cloud server SmObtaining information, user UiInserting a smart card into an internet of things device, and providing
Figure BDA0003225600800000161
Pi *And
Figure BDA0003225600800000162
wherein the content of the first and second substances,
Figure BDA0003225600800000163
Pi *and
Figure BDA0003225600800000164
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure BDA0003225600800000165
And
Figure BDA0003225600800000166
examination conditions
Figure BDA0003225600800000167
If yes, the user UiIs true, otherwise, the user U is rejectediLogging in;
if the user UiIs true, the Internet of things equipment generates a random number N with at least 128 bitsiAnd calculate
Figure BDA0003225600800000168
PIDi＝h(IDi||b)
Figure BDA0003225600800000169
Gi＝h(PIDi||SIDm||Ni||TSi||Di)
Figure BDA00032256008000001610
Figure BDA00032256008000001611
Wherein, TSiIs the current timestamp, SID, of the Internet of things devicemIs a cloud server SmTrue identity of Gi、FiAnd ZiAll represent intermediate operation results;
then, the Internet of things equipment passes through the public channel<Gi,Fi,Zi,PIDi,TSi>Transmitting to a cloud Server Sm。
The detailed implementation of the first three stages so far is shown in fig. 3.
As a practical implementation, the password change phase in the embodiment of the present invention (every time the user U is used for changing the password)iThis phase is invoked when it is desired to update his/her password without communicating with the control server CS), including in particular:
user UiInserting the smart card into the Internet of things device and then providing
Figure BDA00032256008000001612
Pi *And
Figure BDA00032256008000001613
wherein the content of the first and second substances,
Figure BDA00032256008000001614
Pi *and
Figure BDA00032256008000001615
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure BDA00032256008000001616
And
Figure BDA00032256008000001617
examination conditions
Figure BDA00032256008000001618
Whether the current time is established or not, if so, prompting the user UiInputting new password Pi newAnd generates a random number
Figure BDA00032256008000001619
Otherwise, rejecting user UiPassword change of (2);
then, the Internet of things equipment calculates
Figure BDA0003225600800000171
Figure BDA0003225600800000172
Figure BDA0003225600800000173
Figure BDA0003225600800000174
Figure BDA0003225600800000175
Figure BDA0003225600800000176
Finally, the Internet of things equipment records the original record value in the smart card<Ci,Ωi,Ei>Is replaced by
Figure BDA0003225600800000177
As can be seen from this embodiment, user UiIt is very convenient and fast to update the password locally using the smart card.
A legal user UiUpdate his identity IDiIt is very practical, such as the identity has expired. But since the control server CS needs to verify the user's IDiAs an implementable manner, the identity change stage in the embodiment of the present invention specifically includes: user UiRe-registering to the control server CS over a secure channel.
To verify the security and other performance of the protocol method of the present invention, the following was analyzed mainly from the following three aspects: (1) using password related knowledge and utilizing a heuristic method to analyze how the scheme resists the impersonation identity attack; (2) the implementation process of the scheme is simulated by utilizing two security protocol analysis tools, namely Scyther and AVISPA, and the scheme can resist the mainstream attack process; (3) a brief description of the performance comparison of the protocol of the present invention with other protocols is presented.
1. Security analysis
In this subsection, knowledge of cryptography is mainly utilized to analyze U in detail in the scheme of the present inventioni、SmAnd the CS to protect against the most common spoofed identity attacks.
(1) In the cloud server registration phase, SmMutual authentication with CS, SmNegotiating with the CS to generate a value BSm＝h(PSIDm||SIDmY), the value can be regarded as SmAnd CSIs called a key because of the value BSmCan only be formed by SmAnd CS calculation. Thus, SmAnd the CS can pass the symmetric key BS in the authentication phasemMutual authentication, such as Kerberos protocol authentication, is implemented. In addition, SID due to identitymAnd pseudo identity PSIDmAre bound to the secret number y of the control server CS, so CS will be paired with SmThe two identities of (1) are authenticated. Thus, our protocol can implement S during the authentication phasemAnd mutual authentication between the CS.
For convenience of description, the present invention is labeled with the following symbols:
in the authentication phase:
Figure BDA0003225600800000181
(2)Uiand mutual authentication between the CS
To avoid recording U on the control server CSiCS distributes the smart card to U during the registration phasei. The smart card records the value in the protocol of the invention<Ci,Ei,h(·)＞。
First, the ID is known as uniquei，BiAnd PiU of (1)iCan calculate PIDi＝h(IDiB) and
Figure BDA0003225600800000182
c for logging in Internet of things equipment and recording in smart cardiThe value is mainly used for verifying Ui. Therefore, it is labeled with the following notation:
in the user login stage:
Figure BDA0003225600800000183
the above symbols represent: by means of key parameter values C recorded in the smart cardiAnd the Internet of things equipment can verify the Ui. On the other hand, the user obviously trusts own Internet of things equipment.
Secondly, when U is turnediLogin toWhile the equipment is in operation, the equipment is accounting
Figure BDA0003225600800000184
And PIDi＝h(IDi| b). Value E recorded in a smart cardiCan be regarded as intermediate data in the authentication process between the internet of things device and the CS. On the one hand, only UiUsing BiAnd PiWhen the equipment logs in the Internet of things equipment, the equipment can use the Ei data to calculate
Figure BDA0003225600800000185
On the other hand, only x and PID are knowniCan CS calculate Di＝h(PIDi| x), then using data EiComputing
Figure BDA0003225600800000186
Therefore, the internet of things device and the CS can realize mutual authentication by means of the smart card in the user login stage. Therefore, it is labeled with the following notation:
in the user login stage:
Figure BDA0003225600800000187
thirdly, when U is turnediWhen logging in the Internet of things equipment, the value E of the Internet of things equipment can be usediCalculating Di. Then, the value DiCan be used as a symmetric key of the Internet of things equipment and the CS, because only the Internet of things equipment and the CS can calculate the value Di. Therefore, the internet of things device and the CS can pass the symmetric key D in the authentication stageiMutual authentication is achieved. Therefore, it is labeled with the following notation:
in the authentication phase:
Figure BDA0003225600800000191
from the symbol (2), the symbol (3) and the symbol (4), we can derive the following symbol (5):
in the authentication phase:
Figure BDA0003225600800000192
the above notation means: with the help of a smart card, the identity is IDiU of (1)iMutual authentication with the CS may be achieved during an authentication phase.
In addition, upon receiving UiAfter registering the message, the CS should verify the UiIdentity ID ofiThe authenticity of. When the identity IDiWhen the CS is confirmed to be legal, the CS executes the subsequent operation and sends the subsequent operation to the UiThe smart card is transferred. Then, when U isiWhen logging in to a device supporting a network, the device calculates PID by a hash functioni＝h(IDiB), which indicates a pseudo-identity PIDiWith true identity IDiBinding, value b is received by omega in the smart cardiAnd (4) protecting the record. Thus, UiIs identified byiBy UiPseudo-identification PID ofiIndirect control, the pseudo-identity and operation Di＝h(PIDi| x) the secret number x of the control server CS. Therefore, the following notation is used:
in the authentication phase:
Figure BDA0003225600800000193
(3)Uiand SmMutual authentication between:
as with the analysis of section (2) above, this section may be marked with the following symbols
In the authentication phase:
Figure BDA0003225600800000194
due to the value of NiAnd SIDmIs formed by a symmetric key DiEncrypted and transmitted, wherein
Figure BDA0003225600800000195
And
Figure BDA0003225600800000196
at the authentication stageSection (2):
Figure BDA0003225600800000197
because of the value NmIs formed by a symmetric key BSmEncrypted and transmitted, wherein
Figure BDA0003225600800000198
In the authentication phase:
Figure BDA0003225600800000199
due to value of
Figure BDA00032256008000001910
From a secret value NiAnd DiEncryption and transmission, wherein
Figure BDA0003225600800000201
In the authentication phase:
Figure BDA0003225600800000202
due to value of
Figure BDA0003225600800000203
By secret values BSmAnd NmEncryption and transmission, wherein
Figure BDA0003225600800000204
Therefore, the following notation can be used to infer:
in the authentication phase:
Figure BDA0003225600800000205
as shown by symbol (11), the protocol of the present invention implements U through the intermediary of CSiAnd SmMutual authentication between them. In addition, the three parties share the same session key SK ═ h (N)m||NCS||Ni). Due to the fact thatTherefore, the protocol of the invention can be asserted to be capable of effectively resisting the impersonation identity attack.
2. Simulation analysis using Scyther and AVISPA
In this subsection, capabilities of attackers are defined and security analysis of the protocol of the present invention is discussed. Based on the countermeasure model, the security protocol analysis tools of AVISPA (automatic verification of the infinite state system) and Scyther are used to prove that the protocol can defend against the existing various attacks.
2.1 confrontation model
And (4) giving a threat attack model by referring to a Dolev-Yao adversary threat model.
The detailed description of the Dolev-Yao adversary threat model is as follows:
(1) an attacker can eavesdrop and intercept all messages passing through the network;
(2) an attacker can store and send intercepted or self-built messages;
(3) an attacker can participate in the operation of the protocol as a legal subject;
(4) power analysis or side channel attacks may help an attacker extract secret information stored in a user's smart card.
2.2 simulation of the protocol of the invention Using a Security protocol analysis tool
2.2.1 Emulation code Specification
The first step in using the simulation tool is to describe the target protocol in a formal language. This section introduces AVISPA tool form language HLPSL (high level protocol specification language) and Scyther tool form language SPDL (Security protocol description language) to emulate the protocol of the present invention.
(1) HLPSL simulation code of the protocol of the invention: the HLPSL emulation code of the protocol of the present invention involves 5 roles: 'role user' simulating real user Ui(ii) a 'role server' simulation cloud server Sm(ii) a The role control server simulates a control server CS; "character session" represents the role of the four-way interactive handshake; "role environment" represents the high-level corner with intruders; "character object" represents the purpose of the simulation. The following description of the HLPSL is a brief introduction of only the user roles, environment roles, and security objectives, as illustrated in the figure4, respectively.
In fig. 4(a), the user role process describes the parameters, initial states and transitions to be used initially. "convert" means to accept the information and send the response information. "channel (dy)" indicates that the attack mode is a Dolev-Yao attack model, and an attacker can control the network of the protocol. For example, an attacker can intercept, steal, modify, replay information transmitted on a channel in a protocol, and even impersonate a legitimate role in the protocol to perform an operation and launch an attack.
FIG. 4(b) illustrates the persona environment and security goals. The high-level role process includes a hybrid role process of global constants and one or more sessions. Wherein an intruder may impersonate a legitimate user to run certain role processes. Still other sentences describe the knowledge known to the intruder in the initial state, typically including the name of the agent, all keys shared by other agents, and all known functions. For HLPSL modeling of security objectives, we only give confidentiality objectives for HLPSL that support both confidentiality and authentication, one of the two objectives. For privacy, the target instance indicates which values are in the declared role are private. If the secret value cannot be realized, the secret value is obtained by the intruder, and the protocol can be attacked successfully. For identity verification, the main purpose is to verify identity masquerading attacks, and in the security analysis in the previous section, how the protocol resists the common attacks is specifically demonstrated.
(2) SPDL emulation code of the protocol of the present invention: similar to HLPSL, the SPDL emulation code of the inventive protocol includes 3 roles: role U simulates real user Ui(ii) a Role S simulation cloud server Sm(ii) a The "role CS" emulates the server control CS. The SPDL code is introduced here by way of example in the role of control server CS, as shown in fig. 5. Having defined the variables required by the session protocol, the complete implementation of the protocol of the invention is represented by the set of events occurring in the CS. The "send" and "recv" events indicate that the CS sends and receives messages, respectively. One of the advantages of the Scyther tool is that it can flexibly describe target properties, whether for the confidentiality of variables or for the authentication of one subject to another. The Scyther tool can analyze and verify security attributes of interest to the user. TargetThe description of the attributes is done through a "close" event, which can be used to describe the role's authentication and the confidentiality of variables.
2.2.2 simulation results
This section shows the simulation results of the protocol of the present invention using two formal analysis tools. AVISPA (version 2006/02/13) and Scyther (v1.1.3) are built in the virtual machines of the ubuntu operating system. Figure 6 shows the results of all four back-end analysis tools provided by AVISPA to simulate the proposed protocols of all entities. The test results of the OFMC, CL-AtSe and SATMC modules indicate that the protocol of the invention is SAFE (SUMMARY SAFE), which means that it can reach the intended safety target; TA4SP verifies that the model represents INCONCLUSIVE because the current TA4SP module does not support one-way hash functions, and the current version can provide a result of No ATTACK TRACE. When the protocol was simulated using the Scyther tool, the Dolev-Yao attack model was also used, and the minimum number of execution rounds in the analysis parameters was set to 3. The results of the simulation of the Scyther tool are shown in FIG. 7. Fig. 7 (a) shows the attack path of the Scyther tool under the Dolev-Yao model for formal analysis of our protocol. The reachability analysis report of our protocol message is shown in fig. 7 (b). The test result shows that the protocol of the invention has no attack threat under the model. Thus, it can be asserted that the inventive protocol can resist various common attacks, such as internal attacks, replay attacks, session key disclosure attacks, and the like.
3. Performance comparison
In the following, the protocol of the invention is specifically compared with the other two protocols (document 1 and document 2, respectively) in terms of resistance to security functions and computational performance. Table 2 lists 9 general security requirements of the strong authentication protocol of the internet of things device and the cloud server. The results in table 2 show that the inventive protocol has the advantages of user auditability, simple and secure password modification, resistance to offline password guessing attacks, resistance to impersonation attacks, and biometric protection.
In addition, table 3 shows the number of hash functions and XOR operations that take in each phase of the protocol of the present invention and other related protocols. As can be seen from the total count of the last row, the number of times the hash function and XOR are used by the protocol of the present invention is minimal. Therefore, it is more suitable for environments where application resources are limited and data intensive, such as internet of things devices in smart cities.
TABLE 2 comparison of Security function of New protocol with related protocol
Figure BDA0003225600800000221
TABLE 3 comparison of operation of the New scheme with other related schemes
Figure BDA0003225600800000231
H, hash function; x is exclusive OR operation
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims (10)

1. An authentication and key agreement protocol method for internet of things equipment in a distributed cloud computing architecture comprises a registration stage, a login stage and an authentication and key agreement stage, and is characterized in that the authentication and key agreement stage comprises the following steps:
first handshake process: user UiTo cloud server S through its internet of things devicemSending a login message, cloud Server SmReceiving user UiAfter the login message, calculating the authentication condition of the user, and comparing the authentication condition of the user with the authentication condition of the user UiThe login message is sent to the control server CS;
second handshake process: control server CS receives a message from a cloud server SmAfter the message, the user U is authenticatediAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating the authentication conditions of the cloud server S and sending the generated two authentication conditions to the cloud server Sm；
Third handshake process: cloud server SmSelects an authentication condition related to itself from the two received authentication conditions to authenticate the control server CS, and sends the other authentication condition to the user UiThe internet of things device of (1);
the fourth handshake process: user UiThe Internet of things equipment verifies the validity of the control server CS according to the received identity verification condition, and if the control server CS passes the verification, the user UiCloud server SmFinally negotiating with the control server CS to obtain a shared secret key SK h (N)m||NCS||Ni) (ii) a Wherein N ismIndicating that the first handshake process is performed by the cloud server SmA 128-bit random number, N, is generatedCSRepresenting a 128-bit random number, N, generated by the control server CS during the second handshakeiRepresenting a user UiOn-login cloud server SmA random number of at least 128 bits generated;
in the four-way handshake process, only the user U needs to be usediCloud server SmAnd the control server CS fails to authenticate, the session ends.
2. The method according to claim 1, wherein in the first handshake process, the cloud server S is used for authentication and key agreement protocol of the internet of things device in the distributed cloud computing architecturemReceiving user UiAfter the login message, the method further comprises:
cloud server SmExamination conditions TSm-TSi<Whether delta T is established or not, if yes, the cloud server SmComputing its own identity verificationThe conditions specifically include: cloud server SmGenerating a 128-bit random number NmAnd calculate
Figure FDA0003225600790000021
Ki＝h(Nm||BSm||PIDi||Gi||TSm)；
Correspondingly, the cloud server SmThe authentication condition of the user U and the user UiThe sending of the login message to the control server CS specifically includes: cloud server SmWill be provided with<Ji,Ki,PSIDm,Gi,Fi,Zi,PIDi,TSi,TSmSending to the control server CS;
wherein the content of the first and second substances,<Gi,Fi,Zi,PIDi,TSi>representing a user UiThe log-in message of (a) is,<Ji,Ki,PSIDm,TSm>representing cloud Server SmAuthentication condition of (TS)mRepresenting cloud Server SmCurrent time stamp of, TSiRepresenting a user UiThe current time stamp of the Internet of things equipment, delta T represents a set time threshold value, BSmRepresenting cloud Server SmSymmetric key with control server CS, PIDiRepresenting a user UiPseudo-identity of, PSIDmRepresenting cloud Server SmPseudo-identity of, Bm、Ji、Ki、Gi、FiAnd ZiAll represent intermediate operation results, h (-) represents a hash function, and | | represents splicing operation.
3. The method according to claim 2, wherein in the second handshake process, the control server CS receives a request from the cloud server SmAfter the message, further comprising: control Server CS checks Condition TSCS-TSm<Whether the delta T is established or not, if yes, verifying the user UiHarmonious cloud clothesServer SmThe validity of (2);
correspondingly, the authentication user UiAnd cloud server SmIf the two are legal, the two are respectively the user UiAnd cloud server SmGenerating the authentication conditions of the cloud server S and sending the generated two authentication conditions to the cloud server SmThe method specifically comprises the following steps:
step A1: control server CS computation
Di＝h(PIDi||x)
Figure FDA0003225600790000022
Figure FDA0003225600790000023
Figure FDA0003225600790000031
Step A2: control server CS checking condition
Figure FDA0003225600790000032
If yes, the control server CS verifies the user UiLegality;
step A3: control server CS computation
BSm＝h(PSIDm||SIDm||y)
Figure FDA0003225600790000033
Step A4: control server CS checking condition
Figure FDA0003225600790000034
If yes, the control server CSVerifying cloud server SmLegality;
step A5: the control server CS generates a 128-bit random number NCSAnd calculate
Figure FDA0003225600790000035
Figure FDA0003225600790000036
SKCS＝h(Ni||Nm||NCS)
Figure FDA0003225600790000037
Figure FDA0003225600790000038
Step A6: through the common channel<PCS,QCS,RCS,VCS>Sending to cloud server Sm；
Wherein, TSCSRepresenting the current timestamp of the control server CS, x representing a timestamp known only to the control server CS for authenticating the user UiSecret key, ID ofiRepresenting a user UiTrue identity of, SIDmRepresenting cloud Server SmTrue identity of SKCSRepresenting a shared secret generated by the CS side of the control server, RCSAnd VCSIndicating that the control server CS is a cloud server SmGenerated authentication condition, PCSAnd QCSIndicating that control server CS is user UiGenerated authentication conditions, DiRepresenting a symmetric key between the internet of things device and the control server CS,
Figure FDA0003225600790000039
and
Figure FDA00032256007900000310
respectively representing means for authenticating a user UiAnd cloud server SmThe legitimacy of and the parameters of the integrity of the data transmission,
Figure FDA00032256007900000311
representing an exclusive or operation.
4. The method according to claim 3, wherein the third handshake process specifically includes:
first, the cloud server SmComputing
Wm＝h(BSm||Nm)
Figure FDA0003225600790000041
Figure FDA0003225600790000042
Then, the cloud server SmExamination conditions
Figure FDA0003225600790000043
Whether it is, if it is, the cloud server SmVerifies the control server CS passes and passes [ < P >CS,QCS>Sent to user UiThe internet of things device of (1);
wherein SKmRepresenting cloud Server SmEnd-generated shared secret, WmThe result of the intermediate operation is represented,
Figure FDA0003225600790000044
representing a parameter for verifying the authenticity of the identity of the control server CS.
5. The method according to claim 4, wherein the fourth handshake process specifically includes:
first, user UiInternet of things equipment computing
Li＝h(Ni||Di||Fi)
Figure FDA0003225600790000045
SKi＝h(Nm||NCS||Ni)
Figure FDA0003225600790000046
Then, the user UiInternet of things equipment inspection condition
Figure FDA0003225600790000047
If true, user UiConfirm that the control server CS is authentic;
wherein L isiRepresenting the result of an intermediate operation, SKiRepresenting a user UiThe shared secret key generated by the device side of the internet of things,
Figure FDA0003225600790000048
respectively, representing parameters for verifying the authenticity of the identity of the control server CS.
6. The method according to claim 1, wherein the registration phase is divided into a cloud server registration phase and a user registration phase; wherein: the cloud server registration stage specifically includes:
cloud clothesServer SmWill register message < SIDm,d>Sending to the control server CS; wherein SIDmRepresenting cloud Server SmD is a random number;
the control server CS receives the information from the cloud server SmAfter the registration message, calculate the PSIDm＝h(SIDm||d)，BSm＝h(PSIDm||SIDmY) and passes through the secure channel to the BSm>Send back cloud server Sm(ii) a Wherein, PSIDmRepresenting cloud Server SmY denotes a pseudo identity known only to the control server CS for authenticating the cloud server SmOf the secret key, BSmRepresenting cloud Server SmA symmetric key with the control server CS, h (-) represents a hash function;
cloud server SmSecret parameters<BSm,d>And storing the data in the memory.
7. The method according to claim 6, wherein the user registration stage specifically includes:
user UiSelecting the desired real identity IDiAnd a password PiEntering the Internet of things equipment;
internet of things equipment collection user UiBiological characteristics of (B)iAnd generates a random number b to calculate the PIDi＝h(IDi||b)，
Figure FDA0003225600790000051
And
Figure FDA0003225600790000052
wherein, PIDiRepresenting a user UiPseudo-identity of, AiAnd ΩiAll of which represent the results of the intermediate operations,
Figure FDA0003225600790000053
means for indicating differentOr operation;
internet of things equipment registers message (ID)i,PIDi,Ai>Sending the data to a control server CS through a secure channel;
the control server CS verifies the ID after receiving the registration message from the Internet of things equipmentiIs true of, if IDiIs illegal, the control server CS will reject the user UiRegistering; otherwise, the control server CS calculates Ci＝h(PIDi||Ai)，Di＝h(PIDi| x) and
Figure FDA0003225600790000054
wherein x denotes a user U known only to the control server CS for authenticationiSecret key of DiRepresenting a symmetric key between the Internet of things device and the control server CS, CiAnd EiAll represent intermediate operation results;
control server CS sends data<Ci,Ei,h(·)>Write in the smart card and deliver it to the user U by dedicated communicationi；
User UiAfter the smart card is obtained, the smart card is inserted into the Internet of things equipment, and the ID is input into the Internet of things equipment againiAnd PiSo as to write omega into the smart card through the equipment of the Internet of thingsiRecording information by smart card<Ci,Ωi,Ei,h(·)>。
8. The method according to claim 7, wherein the login phase specifically includes:
when the user UiWant to slave cloud server SmObtaining information, user UiInserting a smart card into an internet of things device, and providing
Figure FDA0003225600790000061
Pi *And
Figure FDA0003225600790000062
wherein the content of the first and second substances,
Figure FDA0003225600790000063
Pi *and
Figure FDA0003225600790000064
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure FDA0003225600790000065
And
Figure FDA0003225600790000066
examination conditions
Figure FDA0003225600790000067
If yes, the user UiIs true, otherwise, the user U is rejectediLogging in;
if the user UiIs true, the Internet of things equipment generates a random number N with at least 128 bitsiAnd calculate
Figure FDA0003225600790000068
PIDi＝h(IDi||b)
Figure FDA0003225600790000069
Gi＝h(PIDi||SIDm||Ni||TSi||Di)
Figure FDA00032256007900000610
Figure FDA00032256007900000611
Wherein, TSiIs the current timestamp, SID, of the Internet of things devicemIs a cloud server SmTrue identity of Gi、FiAnd ZiAll represent intermediate operation results;
the Internet of things equipment is connected with the Internet of things equipment through a public channel<Gi,Fi,Zi,PIDi,TSi>Transmitting to a cloud Server Sm。
9. The method for authentication and key agreement protocol of internet of things equipment in distributed cloud computing architecture according to claim 1, further comprising: the password changing stage specifically includes:
user UiInserting the smart card into the Internet of things device and then providing
Figure FDA00032256007900000612
Pi *And
Figure FDA00032256007900000613
wherein the content of the first and second substances,
Figure FDA00032256007900000614
Pi *and
Figure FDA00032256007900000615
respectively represent users UiThe identity, password and biometric features of the actual input;
internet of things equipment computing
Figure FDA00032256007900000616
And
Figure FDA00032256007900000617
examination conditions
Figure FDA00032256007900000618
Whether the current time is established or not, if so, prompting the user UiInputting new password Pi newAnd generates a random number
Figure FDA00032256007900000619
Otherwise, rejecting user UiPassword change of (2);
then, the Internet of things equipment calculates
Figure FDA0003225600790000071
Figure FDA0003225600790000072
Figure FDA0003225600790000073
Figure FDA0003225600790000074
Figure FDA0003225600790000075
Figure FDA0003225600790000076
Internet of things equipment records original values in smart card<Ci,Ωi,Ei>Is replaced by
Figure FDA0003225600790000077
10. The method of claim 8, wherein the method further comprises: the identity change stage specifically includes:
user UiRe-registering to the control server CS over a secure channel.
CN202110970858.0A 2021-08-23 2021-08-23 Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture Pending CN113765658A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110970858.0A CN113765658A (en) 2021-08-23 2021-08-23 Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110970858.0A CN113765658A (en) 2021-08-23 2021-08-23 Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture

Publications (1)

Publication Number Publication Date
CN113765658A true CN113765658A (en) 2021-12-07

Family

ID=78790861

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110970858.0A Pending CN113765658A (en) 2021-08-23 2021-08-23 Authentication and key agreement protocol method for Internet of things equipment in distributed cloud computing architecture

Country Status (1)

Country Link
CN (1) CN113765658A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114401153A (en) * 2022-03-24 2022-04-26 科大天工智能装备技术（天津）有限公司 Authentication method and system of intelligent well lid equipment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109327313A (en) * 2018-11-07 2019-02-12 西安电子科技大学 A kind of Bidirectional identity authentication method with secret protection characteristic, server
CN113259091A (en) * 2021-04-01 2021-08-13 中国人民解放军战略支援部队信息工程大学 Space information network clock asynchronous security authentication method based on elliptic curve cryptography

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109327313A (en) * 2018-11-07 2019-02-12 西安电子科技大学 A kind of Bidirectional identity authentication method with secret protection characteristic, server
CN113259091A (en) * 2021-04-01 2021-08-13 中国人民解放军战略支援部队信息工程大学 Space information network clock asynchronous security authentication method based on elliptic curve cryptography

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
黄辉辉等: ""An efficient authentication and key agreement protocol for IoT-enabled devices in distributed cloud computing architecture"" *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114401153A (en) * 2022-03-24 2022-04-26 科大天工智能装备技术（天津）有限公司 Authentication method and system of intelligent well lid equipment

Similar Documents

Publication Publication Date Title
Amin et al. A light weight authentication protocol for IoT-enabled devices in distributed Cloud Computing environment
Qiu et al. Practical and provably secure three-factor authentication protocol based on extended chaotic-maps for mobile lightweight devices
Banerjee et al. Physically secure lightweight anonymous user authentication protocol for internet of things using physically unclonable functions
Dhillon et al. Secure multi‐factor remote user authentication scheme for Internet of Things environments
Odelu et al. Provably secure authenticated key agreement scheme for distributed mobile cloud computing services
Liu et al. A physically secure, lightweight three-factor and anonymous user authentication protocol for IoT
Ghaffar et al. An improved authentication scheme for remote data access and sharing over cloud storage in cyber-physical-social-systems
Srinivas et al. Provably secure biometric based authentication and key agreement protocol for wireless sensor networks
Jiang et al. An anonymous and efficient remote biometrics user authentication scheme in a multi server environment
Kalra et al. Advanced password based authentication scheme for wireless sensor networks
Huang et al. An efficient authentication and key agreement protocol for IoT-enabled devices in distributed cloud computing architecture
CN113849815B (en) Unified identity authentication platform based on zero trust and confidential calculation
CN113572765B (en) Lightweight identity authentication key negotiation method for resource-limited terminal
Alhaidary et al. Vulnerability analysis for the authentication protocols in trusted computing platforms and a proposed enhancement of the offpad protocol
CN114143343A (en) Remote access control system, control method, terminal and medium in fog computing environment
Alizai et al. Key-based cookie-less session management framework for application layer security
Bairwa et al. Mutual authentication of nodes using session token with fingerprint and MAC address validation
Chen et al. Improved Secure and Lightweight Authentication Scheme for Next‐Generation IoT Infrastructure
Indushree et al. Mobile-Chain: Secure blockchain based decentralized authentication system for global roaming in mobility networks
Liu et al. TR‐AKA: A two‐phased, registered authentication and key agreement protocol for 5G mobile networks
Huang et al. An Efficient ECC‐Based Authentication Scheme against Clock Asynchronous for Spatial Information Network
Hussain et al. An improved authentication scheme for digital rights management system
Sani et al. SPrivAD: A secure and privacy-preserving mutually dependent authentication and data access scheme for smart communities
Zhang et al. Formal analysis of QUIC handshake protocol using ProVerif
Resende et al. PUF-based mutual multifactor entity and transaction authentication for secure banking

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20211207

WD01 Invention patent application deemed withdrawn after publication