Cluster-Based Authentication Process in a Smart City

,e widespread deployment of the Internet of,ings in any smart city provides a regular flow of huge amount of data in server(s) that poses challenges for effective and efficient management to improve the quality of citizens’ life. To maintain the privacy and security of these data, a proper and secured identification and authentication process is very essential. In this paper, we propose a cluster-based identification and authentication process for the users, edge servers, and service servers, which are engaged in storing, processing, and accessing data. ,e proposed identification and authentication process is secured due to some codes (values), which are not possible to compute except by the concerned entities. For the proposed trust evaluation method (which actually strengthens the proposed authentication process), we consider major components and their integration in the model very carefully so that the simulation results become credible. Hence, we hope that the simulation results will be useful for the readership. As a whole, the proposed approach has potentials of being implemented in real-time applications.


Introduction
World population has increased significantly in the last few decades, and most of the people are attracted to city "life" for job opportunities, improved health care, and education, to note a few. As a result, the number of city dwellers has increased at an unprecedented rate. According to statistics, the percentages of people living in cities were 29% and 50% in the years 1950 and 2008, respectively, which is predicted to reach 65% in 2040 [1]. With the rapid advancement and innovation of Information Technology (IT), the world is experiencing a paradigm shift in city infrastructures and services. e evolution of this new form of IT-based city is popularly known as "Smart City." In a smart city, digital technologies translate into better public services for inhabitants and better use of resources while impacting the environment less. e smartness of a city depends on proper integration of numerous IoT devices with different service-oriented information systems. To make a city smart, sharing of information among the citizens and those service-oriented information systems is very important. For example, if a citizen suddenly becomes sick, s/he can ask for medical assistance through her/his smart phone. en, an ambulance from the Emergency Medical Service will rush to her/his location to transfer her/him to a nearby hospital according to her/his need. Hence, interconnection among the citizens and service providers' information systems to realize different services is a central issue of a smart city.
We know that cloud computing involves the use of globally interconnected data centers. ese data centers process a huge volume of IoT data from smart cities and respond as per user requirement. However, as the physical distance between the cloud and the end user is high, transmission latency and response time also increase accordingly [2]. Besides, IoT devices connected to distant data centers try to access sophisticated applications, which impose additional load on networks and contribute to higher latency [3]. Many IoT applications such as a Medical Assistance Management System need to send the location of a citizen, her/his current medical condition (e.g., a severe heart attack) with detailed medical records to the Medical Emergency Service of a smart city for assessment, so that an ambulance dedicated to her/his medical condition can reach to her/his location, provide paramedic service inside the ambulance, evaluate traffic conditions, and direct the ambulance in the best possible way to the nearest hospital of required specialty. However, the inherent limitations of cloud computing such as high latency, non-context-aware behavior, and no support for such mobility requirements pose serious limitations on the use of a real-time emergency service [4].
A large-scale network of IoT with device and networklevel heterogeneity along with the ultralarge volume of data and events generated by "things" of IoT will require prohibitively high network bandwidth in the case of "IoT + -Cloud" scenario [3,5]. Apart from these downsides, cloud computing will simply suffer from processing time inefficiency due to the large overhead of IoT data. Recent research efforts are investigating how to effectively exploit capabilities at the edge of networks to support the IoT in the context of the smart city [6]. In edge computing, massive data generated by different types of IoT devices of a smart city can be processed at the network edge instead of transmitting them to the distant cloud data centers owing to bandwidth and energy consumption concerns. Edge computing can provide services with faster response and greater quality, in comparison with cloud computing. Edge computing is more suitable to be integrated into the paradigm of a smart city to provide real-time services for a large number of end users. Figure 1 depicts a smart city with dedicated servers for different city-oriented services. By using different IoT devices, users connect to those service servers through edge servers to obtain real-time services (cloud computing can also be used for providing non-real-time services). ere can be millions of registered users for a particular server, and one user may be client(s) of multiple servers. Service to service and user to service communication are common scenarios in the context of a smart city. Most of the services can generally be accessed through IoT devices. In such a situation, user identification and authentication is a paramount security issue. It is important to note that edge computing can incorporate a hierarchy of servers with increasing computation capabilities for better service [7]. e hierarchy of servers can be organized into a cluster-based formation. e proposed cluster-based authentication process utilizes this capability of edge computing to manage the security challenges of a smart city more effectively. In a smart city, there will be thousands of users, who will access data, and it will be very difficult to observe every activity of a user. So, we consider cluster-based authentication to minimize the insider attacks, where a cluster member cannot access data of another cluster without going through her/his cluster master, who is a more trusted subject (user) than a cluster member. e clustering will decrease the processing overheads of authentication and authorization systems. e proposed authentication process is integrated with a trust evaluation method that helps to identify malicious activities of the user(s).
An increasing number of studies emphasize on the security, privacy, and risks within smart cities, highlighting the threats relating to information security and challenges for smart city infrastructure in view of management and processing of personal data [8][9][10]. Hence, privacy, data integrity, authenticity, and availability of information are major concerns for a smart city [11]. In this paper, we focus on to provide high availability of information and at the  same time maintain privacy and data integrity. e contributions of the paper are as follows: (i) We have shown a concept of data processing through edge servers and service servers controlled by the central server(s) in a smart city. (ii) A robust trust evaluation process has been designed to evaluate the user trust before and after the registration to control the activities of the members as a first line of defense. is process is demonstrated using simulation results. (iii) A secured cluster-based authentication process has been designed in the paradigm of edge computing. e secrecy of user information and authentication process is verified using AVISPA and Scyther. (iv) A secured key management process has been verified using simulation results that ensure data confidentiality and integrity.
In this way, the paper contributes to realize an efficient ecosystem of IoT devices, data, and applications along with stringent security requirements. e remainder of this paper is organized as follows. In Section 2, we describe the proposed Trust Evaluation and Cluster-based Authentication Process. Section 3 presents comparison and discussion in detail. Finally, we render our concluding observations in Section 4.

Trust Evaluation and Cluster-Based Authentication Process
In the proposed cluster-based approach, we consider three types of servers such as edge server, which can ease the processing and storing overload of the other server; service server for each service (e.g., emergency healthcare service); and the central server for a smart city. Each user communicates with an edge server, which is located in the user's locality. A user can get service from any service server through cluster-based communication. All users of a service server will be registered with the help of the edge servers. Users will perform registration through the respective edge server.

Trust Evaluation.
For user registration, at first, the "trust" of a user is evaluated. Trust has been treated as a soft security mechanism for protection or a means for security in many fields, ranging from economics, psychology, sociology, medicine, and technology [12]. Hence, it is nearly impossible to generalize the concept of trust. Even for a specific field, trust is very complicated as it can be influenced by many measurable and nonmeasurable attributes [13]. Trust can be classified into two types: one is direct trust and another is indirect trust [14,15]. For registration in a service server, a direct trust can be gained if a user can present her/his National Identification Number (NID) or passport number or an equivalent authentic document issued by the government. On the other hand, if a user cannot present her/his NID/passport, for registration s/he must be endorsed by one or more existing user(s) having direct trust or a representative (such as a commissioner) from the user's locality. In this way, a user can gain indirect trust and be eligible for registration. Once a user is registered into one or more service server(s), her/his trust will be evaluated continuously according to her/his activities over time. Hence, in the process of trust evaluation, it is required to automatically collect information concerning trust decision attributes, evaluate the level of trust based on the values of trust decision attributes, and at times evaluate the entire trust evaluation process to make the proposed trust evaluation process more effective and updated [13]. e proposed trust evaluation process works as follows. At first, we define the levels of trust (LT) and their associated value ranges according to Table 1. When a user performs registration through direct trust, s/he is assigned "mid (M)" as the LT. Hence, s/he obtains a random value in the interval of [0.41, 0.50] as the initial trust value. Similarly, when a user performs registration through indirect trust, s/he is assigned "low (L)" as the LT. As a result, s/he obtains a random value in the interval of [0.31, 0.40] as the initial trust value. After a user obtains the initial trust value, her/his trust value is continuously updated based on a reward-penalty method. We use the following recurrence to assign ITV (Initial Trust Value) to a user U i who is registered to the system.
For each unwanted or malicious activity by the user, her/ his trust value will be decreased (as a penalty). Malicious activities for which the trust value is penalized or rewarded is called trust decision attributes (TDAs). Malicious activities such as unauthorized read, write, update, or delete of data are examples of some TDAs for which trust value can be decreased. According to the proposed trust evaluation process, TDAs for which the trust value is decreased are grouped into the following two broad categories: (i) Data-level TDAs (ii) Application-level TDAs TDAs of the abovementioned groups and their penalty points are defined in Tables 2 and 3.
On the other hand, for a day-long authorized activity, the user's trust value will be increased (as a reward). For LTs ranging from low (L) to high (H), the user's trust value will be increased by 0.01 for each day-long authorized activity. However, for both warning (W) and very high (VH) LTs, the trust value will be increased by 0.001 for each day-long authorized activity. Trust value will not be gone beyond 1.00.
We now explain how the trust value of a user can be changed over time according to her/his activities and, as a result, how it impacts the LT. We suppose that a user is registered in a service server (the Emergency Medical Service Server) through direct trust; hence, the user's LT will be "mid" and a random number in the interval of [0.41, 0.50] will be assigned as the trust value. Let us assume that the Security and Communication Networks 3 initial trust value (ITV) is 0.45. Now if s/he asks for medical assistance through an application deployed in the emergency medical service server, the emergency medical service will act accordingly. However, if it is identified that the service was called without any purpose, according to Table 3, the user's trust value will be reduced by 0.20 for "inappropriate use" of the application. e user's current trust value (CTV) will be 0.25, and as a result, the user's LT will change from "mid" to "warning" and an appropriate text warning will be sent to the user. After receiving the warning, if the user starts committing authorized activities, then for each day-long authorized activity the trust value will be increased by 0.001. In this way, the user can increase her/his LT. However, if the user does the same malicious activity with CTV 0.25, her/his CTV will again be reduced by 0.20 (changes of values for CTV can be formulated using equation (1)). As the user's CTV will be 0.05, the user's LT will be "revocation list" and her/his information will be put into the "revocation list" database so that s/he will be barred from not only using the Emergency Medical Service Server but also other sensitive service servers. Even if the user tries to obtain a new registration through indirect trust, s/he will be detected from the "revocation list" database and will be barred from obtaining a new registration. However, the user can again be assigned to the "warning" LT only if it is advised by an appropriate regulatory body. e proposed trust evaluation process can be further explained in Figure 2. In Figure 2, DTF (Database for Trust Evaluation) consists of tables of trust decision attributes, LTs and associated value ranges, and the revocation list, and DRU stands for Database for Registered Users.
Here, in (2) |TDA| is the number of trust decision attributes. pen(TDA i ) indicates the penalty associated with the i-th TDA. |D| is the number of day-long authorized activity; inc is the increment (as a reward) of CTV for each day-long authorized activity based on CTV. We define inc as follows: It is worth to mention that the whole process of trust evaluation is flexible. For example, penalties of TDAs can be reviewed regularly and can be updated as per relevancy to the trust decision process. Accordingly, if any TDA such as "unauthorized download" from the category of applicationlevel attributes (Table 3) becomes irrelevant in the future, then its penalty will be set to a very small value or zero. If a new TDA appears to be relevant, it can be incorporated with an appropriate penalty. Even if a new category of TDAs evolves, they can be incorporated into the process of trust evaluation. Different data mining algorithms [16,17] can be applied in the evolution of the trust evaluation process.
We now identify how effective is the proposed trust evaluation process in terms of protection against Denial of Service (DoS) attack and resistance to insider attack. In doing so, we simulate some scenarios as described in the following. e simulation program is developed using Python 3.8. For simulation, we consider three types of scenarios.
(i) Scenario 1: user first commits malicious activity and then plans to do day-long authorized activity    (ii) Scenario 2: user first does day-long authorized activity and then plan to commit malicious activity (iii) Scenario 3: user starts at random whether to commit a malicious activity or do the day-long authorized activity In Scenario 1, a user with direct trust obtains a random value in the interval of [0.41, 0.50] as ITV (initial trust value) according to equation (1). en, s/he starts activities by first committing a malicious activity. e malicious activity is selected randomly from the set of data-level TDAs and application-level TDAs. As a result, the user's CTV (current trust value) will be reduced. To compensate the reduction, the user starts doing day-long authorized activity so that again user's CTV can be increased and again s/he can get an opportunity do some malicious activities. However, if the user goes into the "revocation list" in the database, her/his CTV will never be increased unless s/he is again assigned to the "warning" LT (level of trust) by an appropriate regulatory body.
From the simulation, we see that if a user with direct trust first commits a malicious activity and then plans to do day-long authorized activity (any number of days from 1 to 30), s/he will be able to commit only another malicious activity before going into the "revocation list" in the database. Here, in total two (02) malicious activities are committed, however, at the cost of nine (09) day-long authorized activities (see columns 2 and 3 of the first data row of Table 4). In this paper, we define maximum possible malicious activities (MPMA) as the number of malicious activities before going into the "revocation list." We also define the number of day-long authorized activities before going into the "revocation list" as the cost in days (CD). Here, MPMA � 2 and CD � 9. If the same user first does a day-long authorized activity (any number of days from 1 to 30) to increase CTV and then plan to commit malicious activity, s/ he will be able to commit 4 malicious activities (MPMA), however, at the cost of 68 day-long activities (CD) (see columns 6 and 7 of the first data row of Table 4). If the same user starts by random (whether to commit a malicious activity or do day-long authorized activity), then MPMA � 4 and CD � 65 (see columns 10 and 11 of the first data row of Table 4).
An example of how MPMA and CD are calculated for simulation is described in the following. At first, a user with direct trust obtains a random value of 0.49 in the interval of [0.41, 0.50] as ITV.
en, for the case of "Scenario 1," malicious activity is selected randomly from the set of data-level TDAs and application-level TDAs. If "unauthorized download" gets selected from data-level TDAs, the associated penalty of 0.2 is deducted from the CTV of the user. As a result, CTV of the user reduces to 0.49-0.2 � 0.29 according to equation (2). At this point, MPMA � 1 (as one malicious activity has just been committed). e reduction of CTV also affects the user's LT (level of trust). With a CTV of 0.29, the user's LT will change from "mid" to "warning" and an appropriate text warning will be sent to the user. Now, if the user starts committing authorized activity, then for each day-long authorized activity the trust value will be increased by 0.001 (this increment value is assigned with the "warning" LT). For simulation, the number of day-long authorized activity is randomly selected either from 1 to 30 or from 1 to 60. Even if 60 is selected (meaning two month-long uninterrupted authorized activities), CTV is only increased to 0.29 + (0.001 × 60) � 0.29 + 0.06 ≡ 0.30. At this point, CD � 60. However, when the user commits the next random malicious activity (suppose with 0.2 penalties), CTV is reduced to 0.30-0.20 � 0.10. At this point, MPMA will be 2 (as two malicious activities have been committed in total). However, with CTV � 0.10, the user is placed into the "revocation list" database and will be barred from not only using the Emergency Service Servers but also other sensitive service servers. e user's CTV will never be increased unless s/he is again assigned to the "warning" LT, however, only if recommended by an appropriate regulatory body. In the same way, the simulation result also shows that in Scenario 1, the most likely value of MPMA is 2 (see Table 4). In Table 4, we interpret "any number of day-long authorized activities from 1 to 30" as "1 to 30" and "any number of day-long authorized activities from 1 to 60" as "1 to 60" for convenience.
From Table 4, we see that even for users with direct trust, and planning intelligently and patiently (user first do daylong authorized activity for any number from 1 to 60 and then plan to commit malicious activities), CD/MPMA is 31.28. is implies that even when the user(s) plan meticulously for committing malicious activities, they will not be able to repeat that within a month. Such a low frequency of malicious activities can occur even by mistake. Hence, it is easily understandable that the proposed trust evaluation process provides formidable protection against Denial of Service (DoS) attack and insider attack. e calculation of CTV, which in turn determines the LT of a user, is performed in such a way that it is independent of the nature of applications or sensors (or any IoT devices). As detailed above, the calculation of CTV is directly dependent on data-level TDAs, application-level TDAs, and the current LT of a user. erefore, the CTV of a user is directly dependent on the usage pattern of that particular user. is is why, in the scenario of a concurrent attack on an application, the CTVs of all participating users are reduced in the same manner.

Cluster-Based
Authentication. Now, the proposed cluster-based authentication process comes into action. According to the proposed cluster-based authentication process, each service server gets a number generated by the central server and it is unique for each service server. Similarly, each edge server gets a number generated by the respective service server and each user of an edge server is assigned a number generated by the edge server. ese numbers are called authentication numbers, which are used for generating keys and authentication token for each entity (user, edge server, and service server). Here, we have considered two types of cryptosystems such as symmetric (secret key) and asymmetric (public key) cryptosystems. In a secret Security and Communication Networks key cryptosystem, a secret key is used for both encryption and decryption. In an asymmetric cryptosystem, private and public keys are used. Figure 3 shows an edge server with its registered users. e respective server generates the authentication number using a cryptographic hash function such as SHA-512 or any other strong hash function. e authentication number generation process is given below.
(1) For the central server, ANcs � H (IDcs ‖ RN ‖ TScsan) generated by itself (2) For a service server, ANss � H (IDss ‖ ANcs ‖ TSssan) generated by the central server (3) For an edge server, ANes � H (IDes ‖ ANss ‖ TSesan) generated by the respective service server (4). For a user, ANu � H (IDu ‖ Pwd ‖ ANes ‖ TSu-an) generated by the respective edge server e authentication numbers of all registered users are stored in the respective edge servers. All the symbolic notations used in this article are defined in Table 5. All the authentication numbers are stored in the server, which generates them and the respective entity obtains her/his/its authentication number from her/his/its controlling server. Here, an authentication number is much secured since it is generated using a one-way hash function such as SHA-512. Hence, it is not possible to compute an authentication number of a user without knowing the authentication number of the respective edge server and the authentication number of an edge server cannot be computed without knowing the authentication number of the respective service server. A user can get access to the respective edge server using her/his IDu, Pwd, and ANu. For secured communication, each entity will have a secret key. e secret key generation process is as follows: (1) For a user, Ksec-u � H (IDu ‖ ANu ‖ ESsec ‖ TSu-k) generated by the respective edge server (2) For an edge server, Ksec-es � H (IDes ‖ ANes ‖ SSsec ‖ TSes-k) generated and stored by the respective service server (3) For a service server, Ksec-ss � H (IDss ‖ ANss ‖ CSsec ‖ TSss-k) generated and stored by the central server (4) For the central server, Ksec-cs � H (IDcs ‖ ANcs ‖ CSsec ‖ TScs-k) For the security of the secret key of each entity (user, edge server, service server, and central server), secrecy of the respective generating entity plays an important role. For example, in case of the secret key of a user (Ksec-u), even if ANu (authentication number of the user) is compromised no one can compute Ksec-u without knowing the ESsec (secret key of the edge server). Similarly, other secret or private keys cannot be computed without knowing the secret key of the respective generating entity. Dialogues of the different entities in process of secret key generation are shown in Table 6.
In the proposed approach, each service server and its related edge server constitute a cluster. Each edge server is a cluster member, and the respective service server is a cluster master in the cluster. e secret key of a cluster member is used for secured communication between a member of a cluster and its master (service server). Member to member communication is performed using public key cryptography [18]. However, the user to user communication can be done through the help of the respective edge server. For clusterbased communication, each entity will use token for authentication purposes. e generation process of authentication token is as follows: (1) For a user, ATu � H (IDu ‖ Ksec-u ‖ ESsec ‖ TSu-at) generated by the respective edge server (2) For an edge server, ATes � H (Ides ‖ Ksec-es ‖ SSsec ‖ TSes-at) generated by the respective service server (3) For a service server, ATss � H (IDss ‖ Ksec-ss ‖ CSsec ‖ TSss-at) generated by the central server Figure 4 shows a cluster where all edge servers are members of the cluster and the respective service server is the cluster master. A cluster member can be authenticated by the cluster master whenever it is necessary. If there are r (more than one) service servers in a smart city, there will be r clusters for secured communication.
Here, a user gets services directly from the edge server where s/he has done her/his registration. At first, a user logs in to the edge server using her/his ID, Pwd, and   Type of users  MPMA  CD  MPMA  CD  MPMA  CD  MPMA  CD  MPMA  CD  MPMA  CD  User with direct trust  2  9  2  42  4  68  287  8977  4  65  37  954  User with indirect trust  1  0  1  0  3  53  44  1368  4  44  12  326   6 Security and Communication Networks authentication token (AT). For a strong authentication process, AT is used here. A user can get service from another edge server where s/he has not registered. is process will be performed in the following way. Suppose a user U i has performed registration in an edge server ES i where her/his credential is stored. If s/he wants to get service from an edge server ES j (where the user U i has not performed her/his registration), in such case, in the log-in process the edge server asks the user to enter her/his ID, Pwd, and the ID of the edge server ES i . e server ES j sends an encrypted message (where plain text is ID, Pwd of the user, and the ID of ES j with a nonce which is used to authenticate the message) to ES i to authenticate the user U i . Next, ES i authenticates the user and sends an encrypted response to ES j . Here, all the edge servers in a cluster use public key cryptosystem such as RSA or elliptical curve cryptography for secret messaging. e above scenario is depicted in Figure 5. In Figure 5, CTes denotes ciphertext, which is generated using the private key of ES j where plain text is ID and Pwd of the user, ID of ES j , and a nonce (n1). ES i decrypts the message using the public key of ES j and finds the authentication request to authenticate the user U i . ES i sends an authentication message (AMes) with n1 to ES j . In this way, ES j authenticates the user U i . Now, when an edge server itself wants to get service from the service server of the same cluster (cluster master), the edge server is authenticated by the service server. e edge server sends an encrypted message using the secret key of the edge server where plain text is ID and AT of the edge server. After receiving the message, the service server will authenticate the edge server and accept the request for the service if the requesting edge server is an authentic one.
When an edge server wants to get service from a service server (cluster master) of a different cluster, the edge server sends the request to the cluster master of its cluster with its ID and ATand the ID of the server from which it wants to get  Figure 4: A cluster of edge servers and the respective service server. Password of a user ATu, ATes, ATss Authentication Token for a user, edge server, and service server, respectively RNcs Random number of the central server ANu, ANes, ANss, ANcs Authentication number of user, edge server, service server, and the central server, respectively ESsec, SSsec, CSsec Secret key of edge server, service server, and central server, respectively TSu, TSes, TSss, TScs Time stamp for the user, edge server, service, and central server, respectively. Times tamp means date and time. In a time stamp an, k and AT represent authentication number, key, and authentication token, respectively. For example, TSu-an is the time stamp for generating the authentication number of a user Ksec-u, Ksec-es, Ksec-ss Private key of the user, edge server, and service server, respectively service. Suppose an edge server ES e (cluster member of cluster e) wants to get service from SS g (cluster master of cluster g). Let the cluster master of cluster e is SS e . In this case, ES e encrypts its ID and AT and sends a request message to SS e to get the service from SS g . en, SS e opens the message and finds ID and AT, and authenticates ES e . If ES e is an authentic member, then SS e sends an encrypted message using its private key and a nonce. SS g receives the message and opens it using the public key of SS e . In this way, ES e can reach out SS g for the desired service. is scenario is depicted in Figure 6.
In the cluster-based authentication process, there exists another cluster where members are all the service servers and cluster master is the central server or an authentication server connected with the central server (see Figure 7). is cluster is mainly used to authenticate the service server when interservice server communication is needed. Suppose a service server SS b wants to get service from the service server SS c . In this situation, the SS c uses its private key and sends an encrypted message to the central server to authenticate SS b . e central server will then send a message to SS b to send his ID and AT. en, SS b sends its ID and AT as a ciphertext using its secret key. e central server opens it and authenticates SS b if its AT is in the central server.
Secured communication between two service servers can be performed using public cryptography such as RSA [19] or elliptical curve cryptography. According to Chatzigiannakis et al. [20], elliptical curve cryptography is a better alternative to RSA as elliptical curve cryptography requires less computational resources. In the paradigm of the proposed approach, the majority of devices will have enough resources required. Suppose an edge server ES p is a member where the cluster master is SS c and ES p wants to get service from another service server SS g . In this case, ES p sends a request message to SS g with the ID of SS c . en, SS g sends the encrypted request message of ES p using the public key of SS c . SS c opens it and finds the ID and AT of the edge server ES p and proceeds accordingly.
Verification of phases 3, 3.1, 3.2, and 3.3 from Table 7 is simulated using AVISPA and Scyther separately. For the phases mentioned, the secrecy of messages is verified using both AVISPA and Scyther. In addition, AVISPA also checks the authentication of messages. We achieve the following goals when the protocol from mentioned table is simulated using AVISPA and Scyther.
(1) Secrecy of ID, Pwd, and AMes using AVISPA and Scyther when ES j and ES i pass messages between them (2) Authentication of the sender using AVISPA when ID and Pwd of user sent from ES j from ES i (3) No attack by an intruder when checking authentication using AVISPA when (ID + Pwd) of user are sent by ES j When ES j sends PEes to ES i , it is encrypted using the public key of ES i and the private key of ES j . e target is to ensure the authenticity of the sender and maintain the secrecy of the messages within the cipher. Figures 8 and 9 show that AVISPA and Scyther verify the secrecy of plain texts (ID and Pwd), respectively, inside PEes cipher. At this phase, the receiver receives the cipher and decrypts using the public key of the sender and the private key of the receiver. Authentication of the sender at the same phase is maintained, which is verified by AVISPA, and Figure 8 shows the result. In the same figure, AVISPA also verifies that due to this authentication process no intruder can attack. On the other hand, when ES i sends AMes to ES j , the secrecy of AMes is maintained in both sender and receiver ends. At this phase, the sender encrypts the message using a symmetric key   shared by the sender and receiver. AVISPA and Scyther both verify this result in Figures 8 and 9. Verification of phases 1, 1.1, 2, and 2.1 in Table 8 is simulated using AVISPA and Scyther separately. For all the phases mentioned, the secrecy of messages is verified using both AVISPA and Scyther. In addition, AVISPA also checks the authentication of messages. We achieve the following goals when the protocol from the mentioned table is simulated using AVISPA and Scyther.
(1) Secrecy of ATes and PEss using AVISPA and Scyther when ES e , SS e , and SS g pass messages among them (2) Authentication of the sender using AVISPA when PEss is sent from ES e to SS g (3) No attack by intruder occurs when checking authentication using AVISPA when PEss is sent by ES e When ES e sends a service request to SS e , the secrecy of the message checked from sender and receiver sides, both AVISPA and Scyther in Figures 10 and 11, respectively, show that secrecy of ATes is maintained. At this phase, the message is encrypted using a symmetric key shared between sender and receiver. On the other hand, the secrecy of PEss is maintained when ES e sends an encrypted message to SS g . At this phase, the sender encrypts the message using the private key of ES e and SS g decrypts the cipher using the public key of SS e . is result of secrecy is verified by AVISPA and Scyther, which are shown in above mentioned figures. In addition, authentication of the sender of PEss also verified by AVI-SPA, which is depicted in Figure 11.

Comparison and Discussion
In this paper, based on some predefined comparison criteria, we present a qualitative comparison between the proposed cluster-based authentication process and some other similar processes that involves authentication. We consider the following contenders in the comparison spectrum.   Table 7 using AVISPA verifies secrecy and authentication.
(i) Contender 1: secure remote user authenticated key establishment protocol for smart home environment [21] (ii) Contender 2: effective authentication for restricting unauthorized user [22] (iii) Contender 3: a secure remote user authentication scheme for smart cities e-governance applications [23] (iv) Contender 4: a secure IoT architecture for smart cities [24] Table 8 using AVISPA verifies secrecy and authentication.  Table 7 using Scyther verifies secrecy.
From Table 9, we see that the proposed cluster-based authentication process uses more secured public key encryption system with a framework of key hierarchy. Besides, together with trust evaluation, the proposed cluster-based authentication process can provide a shield against DoS and Insider Attack.
We now evaluate the proposed cluster-based authentication process in terms of execution time(s). Table 10 shows the mean execution times of generating authentication numbers (ANcs, ANss, ANes, and ANu), secret keys (Ksecu, Ksec-es, Ksec-ss, and Ksec-cs) and authentication tokens (ATu, ATes, and ATss) using PHP as a scripting language. We conduct five rounds of executions for each of the authentication numbers, secret keys, and authentication tokens, and then calculate the mean of execution times, where values of IDs (e.g., IDcs, IDss, IDes and IDu) and password are assumed to be six characters long for the abovementioned generation processes. For the same generation processes, Apache server time is used for time stamp (e.g., TSu, TSes, TSss, and TScs) values as we use PHP for above experiment. PHP script generates the abovementioned time stamp values within in Apache server using an Intel Core i5 CPU with 2.30 GHz processor and 8 GB RAM. We use PHP benchmark tool to record the execution times in microseconds. Among the first set that shows authentication number generation times; generation of ANss takes the highest time, where the fastest one is ANcs. In the second set, which shows secret key generation times, close competitors are Ksec-u and Ksec-cs with almost equal time. In the same set, the slowest time is taken by Ksec-es to be generated. In the third set, ATss takes the slowest time among three where ATes is the fastest to be generated. All these keys mentioned in Table 10 are used in variety of dialogues, next paragraphs show detailed comparisons.
Next, we compare the secret key generation times using variety of hashing algorithms required for "dialogues of different entities," which is shown in Figure 10. We use MD5, SHA256, SHA384, SHA512, and Snefru as hashing algorithms to generate secret keys (Ksec-u, Kseces, and Ksec-ss) as shown in Table 6. We calculate the total time required to generate secret keys (shown in Table 6) using each of the hashing algorithms (see Figure 12). Our experiment shows that SHA384 and SHA512 perform the best (takes less time) among all the algorithms used, whereas SHA256 and Snefru take more time in execution, and MD5 takes moderate time compared to all others. Figure 13 shows the comparison of total time taken for both encryption and decryption using variety of key length of RSA and elliptic curve cryptography (ECC). We use these two asymmetric algorithms for "dialogue for user authentication." We execute all encryption and decryption shown in Table 7 with 1024-, 2048-, and 3072-bit keys separately for RSA, and for the same operations using ECC, we use 160-, 224-, and 256-bit keys. ese are the comparable key sizes of these two asymmetric algorithms considering security strengths [25]. For example, 256-bit ECC key will provide same level of security as 3072-bit key of RSA. e figure shows total time required for encryption and decryption with RSA always faster than ECC in all the test cases above. It is shown in [25] that key generation time of ECC is faster than RSA as ECC uses shorter keys to provide same level of security strength. Hence, if encryption and decryption take place more frequently than the key generation process, then use of RSA is a good choice. However, when the situation is opposite, the use of ECC is a better choice. Figure 14 shows the comparative result of total execution times for encryption and decryption required for the steps shown in Table 8. ese encryption and decryption processes require combination of asymmetric and symmetric keys both. We calculate the total time for two combinations asymmetric and symmetric keys: one set contains RSA and AES with variety of key length and another set contains ECC and AES, where RSA and ECC are asymmetric algorithms and AES is a symmetric one. We use variety of key lengths for each of the sets. RSA with 512-bit key and AES with 128-bit key combination is the fastest in terms of execution time than all other pairs of RSA and AES combination, whereas the combination of RSA (2048) and AES (256) is the slowest in terms of execution time among all the combinations. On the other hand, combination of ECC and AES with variety of key lengths encrypts and decrypts even faster than all the  Table 8 using Scyther verifies secrecy.
combinations of RSA and AES. e combination of ECC and AES has a decreasing trend in total encryption and decryption time as the key length increases for each execution. For example, ECC with 256-bit key and AES with 256-bit key show the fastest total of encryption and decryption time.

Conclusion
In this paper, we have proposed a cluster-based authentication process for the users, edge servers, and service servers, which are engaged in storing, processing, and accessing data. All the necessary processes have been presented using necessary figures and tables. A trust evaluation process is used to evaluate the user trusts before and after the registration to control the activities of the members in the system. e proposed trust evaluation process can be further augmented through fusion of soft information with already existing hard information. Soft information for the proposed trust evaluation process can be collected from three different kinds of platforms such as authority's complaint platform, users' review platform, and social media platform. Moreover, simulation of the proposed trust evaluation process has not been conducted for time-advance mechanism using a large number of alternative system configurations. In the future, we intend to extend our work by exploiting the aforementioned scopes. Also, we shall extend our work by comparing with some similar ones such as [26,27]. e proposed authentication process is secured enough in the context of a smart city. As such, the authentication token of a user is simulated using the secret key and secret of the generating entity (edge server). Even if the secret key is compromised, authentication token cannot be generated without the secret of the edge server. Similarly, authentication tokens of other entities are secured according to the proposed method. We have done simulations of the protocol using AVISPA and Scyther. e simulation results have shown that the sessions in the process are safe.

Data Availability
Operations of proposed solution (algorithms) are implemented and verified using some existing verification tools, where no data are required for the experiments. So, only computer scripts (source code) for the experiments are available. e source codes of this study are available from the corresponding author upon reasonable request.

Conflicts of Interest
All authors declare that they have no conflicts of interest.