A Study on the Security Algorithm for Contexts in Smart Cities

Abstract

Recently, a great number of smart devices associated with their users exist within Smart City. Users are constantly moving around within Smart City according to their plans and consequently receive various network services from hosting devices adjacent. Currently, there are numbers of different types of security algorithms related to those activities; moreover, under such complexity of digital environment including various network devices and users, selective and customised services need to be provided for suitable purposes. However, the provided services are to be secured and well protected. Each customised service usually keeps tailored security policy and algorithm. Conventionally, every service including different servers, network, and users employs the same security algorithm so that sensitive information could be traced and revealed by using counter tracing method. Therefore, this paper investigates tailored smart security algorithm, which is taking into account scenarios within smart cities. Consequently, users are able to be protected under tailored security modules based on circumstances of network, smart devices, and types of services.

1. Introduction

Within smart city environment, users are able to access various contexts through their smart devices—such as smartphones, iPads, and computers—on the move. Such contexts could be commercialised; however, the received context requires security process if the users use a home network and smart grid (energy and home control) [1] since the information produced from home—as in status and measured—is transmitted as contexts or a message structure [2], in which the third smart devices could snatch the information. Moreover, EU aims to combine conventional power grid with renewable energy by 2020. Accordingly, EU sets up a target of completing smart grid, which connects to every regional level. Then, users/residents are able to monitor, to measure, and to control usage of utilities by their smart devices such as smartphones and laptops. Therefore, those transmitted pieces of information can contain private data and be vulnerable to attackers, which need to be protected at all times.

In 2012, Ko et al. published a paper [1] that investigated controlling home devices within cyber-physical system (CPS) and control methods and transmit information [1], context, and message [3]. As a result, Choi et al. defined [2] context structure that could be applicable within urban environment and security modules that fit each category of security levels. Through security research of smart city, paper dealt with message security algorithms that are transmitted from the home network.

However, those algorithms are faced with issues of password, processing speed, and loads to protect the entire context with smart devices, which have physical limits. Obviously, elliptic curve cryptosystem (ECC) has advantages of speed compared to conventional open key password algorithm; therefore, ECC is often used for a number of security algorithms together with SEED.

Consequently, this research attempted to minimise encrypted key of conventional ECC algorithm and resolve emerged issues through altering ECC's inner algorithm. Moreover, various security methods are tested for existing context based on degree of services by users’ smart/network devices.

The research is divided into five sections. After introduction, Section 2 organised previous literatures related to the topic. In Section 3, the concept of smart security policy was investigated. Section 4 contains discussion about the issues raised, and finally Section 5 concludes the study and provides the outlook of future research.

2. Related Works

2.1. Context Structure

A previous research [6] analysed and indicated a context structure, which could be implemented within urban environment as well as characteristics and structure of users’ own environment. Since these analysed contexts could be used within a home network, this paper suggested optimal intelligent supervisory control system, which is controlling system based on home network [1]. The paper also defined the information as contexts since the information from home devices is passed to users’ smart devices in real time. With the combination with the context, users are able to manage home devices; however, as suggested, the security modules transmitted from the models [1] only use ID/password in order to connect home devices, which cause vulnerable status to attackers from outside the network. Therefore, extensive researches are required within this field [7]. For instance, a research synthesises the context structure which defines signals from numerous home devices; moreover, the research also designed and provided an algorithm carrying out encryption process fully/partially for important context structures. Algorithm 1 showed the context structure for user 1. Also all users are going to use this structure. It has user.ID ( $u_1$ ), device ID ( $d_1$ ), users location information (loc.[x, y, h, sp]), and all information of user's plan such as when, where and so on.

Algorithm 1: //Context structure for user1.

user.structure {

  $\mathit{u}\mathit{s}\mathit{e}\mathit{r}.\mathit{I}{\mathit{D}}_{\#}$ :: $=u_{\mathrm{1}}$ : pd;

  $\mathit{d}.\mathit{I}{\mathit{D}}_{\#}::=d_{\mathrm{1}}$ ;

 loc. $[\mathit{x}·\mathit{y}·\mathit{h},\mathit{s}\mathit{p}]$ ::= $[x_{\mathrm{1}},y_{\mathrm{2}},h_n,{\text{sp}}_n]$ ;

 plan. $[\{$ when},{where},{who},{what $\}]$ ::=

     $\mathrm{*}\{{\text{when}.}_{\text{dd.mm.yy}}\}$ :: ${\text{dd}}_{\mathrm{1}}.{\text{mm}}_{\mathrm{1}}.{\text{yy}}_{\mathrm{1}}$ ;

     $\mathrm{*}\{{\text{where.}}_{\text{place}}\}::{\text{place}}_{\mathrm{1}}=(p_x,p_y)$ ;

     $\mathrm{*}\{{\text{what}.}_{\text{shop.item}}\}::{\text{item}}_{\mathrm{1}}=(i_{\mathrm{1}},i_{\mathrm{2}},..,i_n\mathrm{\hspace{0.17em}\hspace{0.17em}})$ ;

    *{who._user}:: user. ${\text{ID}}_{\#}=(u_{\mathit{2}},u_{\mathit{3}},u_n)$ ;

 Home.Devices. ${\mathit{h}\mathit{d}}_{\#}$ :: = ${\text{hd}}_{\mathit{1}},{\text{hd}}_{\mathit{2}},\dots ,{\text{hd}}_n$ ;

     $\{{\text{hd}}_{\mathit{1}}=v_{\mathit{1}},{\text{hd}}_{\mathit{2}}=v_{\mathit{2}},\dots ,{\text{hd}}_n=v_n,\}$

}* Security.Level;

2.2. Encrypt Algorithms

Symmetric-key algorithms are a class of algorithms for cryptography that use trivially related, often identical, cryptographic keys for both a decryption and an encryption. The encryption key is trivially related to the decryption key, in that they may be identical or there is a simple transform to go between the two keys. The keys, in practice, represent a shared secret between two or more parties that can be used to maintain a private information link [6, 7]. Symmetric-key algorithms can be divided into stream ciphers and block ciphers. Stream ciphers encrypt the bytes of the message one at a time, and block ciphers take a number of bytes and encrypt them as a single unit [7]. Since encrypting a message does not guarantee that a message is not changed while encryption process is performed, symmetric ciphers are also used to achieve other cryptographic primitives than just encryption. A message authentication code is added to a cipher-text to ensure that changes to the cipher-text will be noted by the receiver. Message authentication codes can be constructed from symmetric ciphers. The symmetric ciphers can also be used for nonrepudiation purposes by ISO 13888-2 standard. Another application is to build hash functions from block ciphers [8, 9]. However, this research identified that the algorithm is not efficient for small smart devices. There is ( $u_1$ , $d_1$ ) security which uses a hash function (H) in Algorithm 3. According to the hash value, they decide if it accepts. Here are three categories such as (loc, plan, Hd₁, security) in Algorithm 4. It takes a hash function and makes the hash value; then they check Validate ( $H_{d.\text{date}}$ ) and ACL $(h_{d1},h_{d2},\dots ,h_{dn})$ . After that, they compare them, and process it. There are three categories such as loc, plan, Hd₁, security in Algorithm 4. It takes hash function and makes the hash value, then they check Validate ( $H_{d.\text{date}}$ ) and ACL $(h_{d1},h_{d2},\dots ,h_{dn})$ . After that, they compare them and process it.

3. Smart Security Policy

This section explains a scenario to this study, the contexts which will appear from this scenario, and policy in order to investigate the security algorithm.

Scenario. Many users usually put their plans in each smart device and share them with other devices [4].

(S1) Hwayeon has a plan to visit K-shopping Centre, to buy her interesting goods and to meet her friends today. Before she goes out, she puts her shopping list, a jacket, a skirt, a pair of boots, and a science novel, and plans to meet her friends, when, where, and cell phone numbers, into her mobile device. We call this information today's profiling. (S2) Last month, she bought a jacket from Shop 1, and the server system in the shop has been keeping this piece of information. (S3) While she is walking on shopping street (pn1.), pn.1 detects her device (u1/d1), gets information on goods that she has interests in, and sends this piece of information to other trusted shops. As soon as s.Svr.1 gets her information, it sends goods information with comparison to old goods which she bought before. (S4) The server also builds an ad hoc virtual (cyber) social network, and it allows people around her to help in shopping by noticing her similar goods other shops have. And this social network will be organized by their related contexts. (S5) After buying a jacket, she moves to a bookstore, which sends the interesting book list to her. (S6) In the middle of reading in the bookstore, she gets notice that her friends are around the bookstore. (Figure 1 and Table 1).

Table 1

Context classification from scenario.

S#	Category	Contexts
S1	User identifier, User profile, Today's profile	(i) Authentication, authorization.   (ii) $d.\text{id},x,y,h,t,\text{sp},s$   (iii) Jacket, skirt, boots, book  (iv) t: 7:00 pm—p: K-coffee shop  (v) f.l (friends List): $\mathit{13,16,18,22}$
S2	User's purchase history	(i) $d.\text{id},x,y,h,s$   (ii) ${\text{it}}_{\mathit{1}},{\text{it}}_{\mathit{2}},\dots ,{\text{it}}_n$   $[{\text{it}}_{\mathit{1}}$ : color, size, price…] $[{\text{it}}_{\mathit{2}}\text{:}\dots ]\dots$   (iii) $u_{\mathit{1}},u_{\mathit{2}},\dots u_n$   $[u_{\mathit{1}}$ : bought  date/item,] [ $u_{\mathit{2}}$ : bd/it, …]   (iv) $u_{\mathit{1}},u_{\mathit{3}},\dots ,u_{\mathit{234}}\dots$   $[u_{\mathit{1}}$ : SL] $[u_{\mathit{2}}$ : SL] $\dots [u_{\mathit{234}}$ : SL]…
S3	Location User identifier User profile Purchase history	(i) $d.\text{id},x,y,h,s$   (ii) $u_{\mathit{1}},u_{\mathit{2}},u_{\mathit{3}},u_{\mathit{4}}$   $[u_{\mathit{1}}$ : SL] $[u_{\mathit{2}}$ : SL] $[u_{\mathit{3}}$ : SL] $[u_{\mathit{4}}$ : SL]… (iii) $u_{\mathit{5}},u_{\mathit{6}}$
S4	Location User identifier Today's profile	$p{n}_{\mathit{2}}$   (i) $d.\text{id},x,y,h,s$   (ii) $u_{\mathit{4}},u_{\mathit{5}},u_{\mathit{6}}[u_{\mathit{4}}$ : SL $][u_{\mathit{5}}$ : SL]…  (iii) $u_{\mathit{8}},u_{\mathit{23}}$ , Share with   $p{n}_{\mathit{1}},p{n}_{\mathit{3}},\dots$   $p{n}_{\mathit{3}}$   (iv) $d.\text{id},x,y,h,s$   (v) $u_{\mathit{7}}[u_{\mathit{7}}$ : SL]  Passed users list  [PUL]— Share with $p{n}_{\mathit{1}},p{n}_{\mathit{2}},\dots$
S5	Location User identifier User profile	(i) $d.\text{id},x,y,h,s$   (ii) ${\text{bl}}_{\mathit{1}},{\text{bl}}_{\mathit{2}},\dots [{\text{bl}}_{\mathit{1}}$ : title, category, …, price]  $[u_{\mathit{2}}$ : …]  (iii) $u_{\mathit{1}},[u_{\mathit{1}}$ : bought date/bl]
S6	Location User identifier User profile Today's profile	Ref. S4

Figure 1

Scenario. Many users usually put their plans in each smart device and share them with other devices [4]. Hwayeon (S1) plans to meet her friend (f1) at the school for a shopping trip. She makes her shopping list into a smart device (S2). The shopping list includes S's tablet PC, B's bag, and G's trousers. And she is in charge of making proposal for cyber and context security at the cyber-physical computing (S3) and works at the weekend for it.

The users put their schedules and objectives into smart devices. Then the smart devices analyse as follows. The algorithm analyses S's Slate PC i440D including colour and price. Then, CBSMA also analyses Slate PC i# series and classifies information of 450D/430D/460D/420D. In terms of colour, the black will be chosen and sort out similar colours. The price is sorted variously depending on shopping malls.

With this scenario, we could make Table 1 [4]. According to Table 1, the classification can be made based on context and users’ objectives can be identified consequently. Then the most appropriate information can be served to users after collecting user information based on their objectives.

Table 1 also defines the context based on user location. First of all, S1 is defined as users’ current location and objectives for the trip. In short, a user identifier, a user profile, and today's profile are defined as well as a context of user location ( $d.\text{id},x,y,h,t,\text{sp},s$ ), a context of shopping goods (jacket, skirt, boots, and book), and a context of time with friends (t: 7:00 pm—p: K-coffee shop, f.1). In the meantime, S2 is the context for analysing users shopping history such as “what kinds of goods were purchased previously”. S3 is the context that indicates circumstantial context while users are on the move. S3 has similar category to S1 which contains the purchasing history category ( $[u_1:\text{SL}][u_2:\text{SL}][u_3:\text{SL}][u_4:\text{SL}]\dots$ ). S4 is the context, which is defined by equipment (server). It compares the context defined by a server against the context defined by users and provides the most suitable service to users. This means that S4 contains the context of server location and ${pn}_{\#}$ . S5 defines the context of users’ movement to the next location (bookstore) after purchasing goods. It also defines the context for book list ( ${\text{bl}}_1,{\text{bl}}_2,\dots$ , $[{\text{bl}}_1\text{:title,category,}\dots \text{,price}]$ , $[u_2:\dots ]$ ) and the context of previously purchased book list $([u_1:\text{bought date/bl}])$ . Lastly, S6 contains location information of the friends that user is going to meet today and basic context is similar to S1.

3.1. Urban Context Structure

The advantage of urban computing (UC) is to provide intelligent and dynamic services, which cannot be supplied within ubiquitous computing environment. This means that sensors and network equipment from users are constantly synchronised and mapped for the services requested. Therefore, UC needs to be able to access users’ smart devices and analyse the information in order to understand users’ intention and life pattern.

People generally organise with smart devices including the use of personal information management (PIM) and electronic dairy within urban life [6]. Moreover, those smart devices are connected with home devices such as domestic appliances and energy controller in real time [1]. The information is classified as “context” and on the basis of context classification [6]; this paper defines a users’ server and a context structure.

First of all, the paper defines context structures as user ID (user.ID), smart devices ID ( $d.\text{ID}$ ), user movement (Loc), schedule (plan), and registration of home devices. Moreover, points x, y, and h and movement speed (sp) were defined in order to attain users movement information. In particular, When, Where, Who, and What information were clearly defined consequently. Home devices include almost all networked devices used at home.

In order to implement different degree of security for users, context, and services, five-phase system was introduced as (1) authentication,(2) authorisation, (3) validation, (4) access to control list (ACL), and (5) location hiding method.

Users are moving around within urban environment and connected various servers-network devices—and some contain—register-users’ information. By looking at context structure of the servers, server ID, customers ID, and new information (new.items) can be found. Table 2 indicates five different levels of security. Algorithm 5 says the server, the customer, and new.Items security. Also it checks Validate ( $C_{d.\text{date}}$ ) and ACL $(C_1,C_2,\dots ,C_n)$ and they share $(n_1,n_2,\dots ,n_n)$ .

Table 2

Security level (SL).

#	Security	Attribute	Content
1	Authen.	enc.Alg[…], key.Size[…]	Authentication of users, devices, or context
2	Author.	enc.Alg[…], key.Size[…]	Authorisation of users, devices, or use of context
3	Validation	valid.date.(dd.mm.yy);	Validating users, devices, or context
4	ACL (access control list)	access list. $l_{\#}$ ;	Access control on users, devices, and use of context
5	Location hidden	Location hiding algorithm	Security on locations

3.2. Smart Security Policy Algorithm

As defined in the context structure previously, security modules are composed of four different types. In theory, applying the four different types of security modules is the safest process; however, a service time aspect, which serves users in real time, cannot be ignored. Therefore, the application of different security modules as per context and types of services provided is able to benefit processing time. The application of the security modules policy is defined as in conjunction with eight different contexts (Table 3).

Table 3

Security policy.

Category	Security policy
1st area
user.ID#	$\{u_{\mathit{1}}·s_{\mathit{1}*\text{pd}}\}$
d.ID#	$\{[u_{\mathit{1}}·d_{\mathit{1}}][s_{\mathit{1,2}}{]}_{*\text{pd}}\}$
2nd area
loc. $[x,y,h,\text{sp}]$	$\{[d_{\mathit{1}}][s_{\mathit{2,5}}]\}$
plan.[{when}, {where}, {who}, {what}];	$\{[d_{\mathit{1}}][s_{\mathit{1,2}}{]}_{*\text{pd}}\}$
$H_d$ (home devices)#	$\{[h_{d\mathit{1}}][s_{\mathit{3}}*s_{\mathit{4}}]\}$
Shop area
Server.ID#	$\{s.{\text{ID}}_{\mathit{1}}]*s_{\mathit{1}}\}$
Customers	$\{[c_{\mathit{1}},c_{\mathit{2}},\dots ,c_n]*[s_{\mathit{3}}*s_{\mathit{4}}]\}$
New.items	$[n_{\mathit{1}},n_{\mathit{2}},\dots ,n_n]$

3.2.1. First Part Security Policy

There is the first part for user-oriented security policy. User security can be decided based on individual user's authentication which means that user.ID becomes s.1 within the security process. In this case, $\{u_1·s_1\}$ can be used for user authentication if needed. Consequently, the users type in their password for verification, whereas the device authentication ( $d.{\text{ID}}_{\#}$ ) can be implemented in order to verify ownership. Therefore, the verification between users and devices can be processed with $\{[u_1·d_1{]}_{[}{s}_{1.}{s}_{2]*\text{pd}}\}$ . Algorithm 2 defined the server context structure. It has also server.ID, the customers’ information, new items that they have including security level definition.

Algorithm 2: //Server context structure.

server. structure {

  $\mathit{s}\mathit{e}\mathit{r}\mathit{v}\mathit{e}\mathit{r}.\mathit{I}{\mathit{D}}_{\#}$ ::= $s_{\mathit{1}}$ ;

 customers:: = $\{u$ .id, when, item}; {

    [ $u_{\mathit{1}}$ : ( ${\text{dd}}_{\mathit{1}}$ . ${\text{mm}}_{\mathit{1}}$ . ${\text{yy}}_{\mathit{1}}$ ): ( $i_{\mathit{1}},i_{\mathit{2}},\dots ,i_n$ )];

    [ $u_{\mathit{3}}$ : ( ${\text{dd}}_{\mathit{3}}$ . ${\text{mm}}_{\mathit{3}}$ . ${\text{yy}}_{\mathit{3}}$ ): ( $i_{\mathit{3}},i_{\mathit{3}},\dots ,i_n$ )];

      ⋮

    [ $u_{\mathit{8}}$ : ( ${\text{dd}}_{\mathit{8}}$ . ${\text{mm}}_{\mathit{8}}$ . ${\text{yy}}_{\mathit{8}}$ ): ( $i_{\mathit{8}}$ , $i_{\mathit{8}}$ ,…, $i_n$ )];

 new.items.#::=( $n{i}_{\mathit{1}}$ , $n{i}_{\mathit{2}}$ ,…, $n{i}_n$ );

}* Security.Level;

Algorithm 3: ( $u_{\mathit{1}}$ · $d_{\mathit{1}}$ security).

User/Device security policy has two types, $s_{\mathit{1}}$ and $s_{\mathit{2}}$ . $u_{\mathit{1}}$ is a user and $d_{\mathit{1}}$ is his/her device.

With only a password, it decides if two securities pass. ( $u_{\mathit{1}}$ . $d_{\mathit{1}}$ ) = (H, $P_d$ , BL)

 H is a hash function to compare the typed password. $P_d$ is password. BL is a block list, BL = [( $u_{\mathit{1}}$ · $d_{\mathit{1}}$ ), …, ( $u_n$ · $d_n$ )].

  H $(P_d)\leftarrow u_{\mathit{1}}$ ;

 If ( $H(P_d)$ == “match”)

   proceed ← (Authen( $u_{\mathit{1}}$ ) ∣ Author( $u_{\mathit{1}}$ · $d_{\mathit{1}}$ ));

 Or Reject ← (Authen( $u_{\mathit{1}}$ ) ∣ Author( $u_{\mathit{1}}$ · $d_{\mathit{1}}$ ));

   Set BL and Share (BL);

Algorithm 4: (loc, plan, Hd₁ security).

There are three categories such as loc $[x,y,h$ , sp] to explain user/device's location,

plan[{when}, {where}, {who}, {what}] to let us know what the user do today, and Hd is

registered home devices, ex. $h_{d\mathit{1}}$ , $h_{d\mathit{2}}$ , …, $h_{dn}$ .

Loc has four items, $x,y,h$ , sp.

  $x,y,h$ mean a x-axis, y-axis and h-axis (height) of user/devices. sp is their speed.

// $w_{\mathit{0}}$ is produced by OTP (One Time Password). After processing with H (Hash Function) it

is transmitted to AP, and then saved as new value. The saved value is registered in temp

and then becomes $w_i$ . Within this algorithm, d.id is actual location of device, $w_i$ is

temporary location information, and only temporary location information is opened to

outside the network [5].

 H( $P_d$ ) ← $u_{\mathit{1}}$ ;

    Loc ← ([ $d_{\mathit{1}}$ ]*[ $s_{\mathit{2,5}}$ ]);      //Loc. Security

    Plan ← ([ $d_{\mathit{1}}$ ]*[ $s_{\mathit{1},\mathit{2}}$ ])Pd;      //Plan Security

     $H_d$ ← ([ $d_{\mathit{1}}$ ]*[ $s_{\mathit{3},\mathit{4}}$ ]);      //H.D Security

    Author(Loc ∣ Plan)(( $d_{\mathit{1}}$ )*( $s_{\mathit{2}}$ ));

    Check Validate ( $H_{d.\text{date}}$ );

    Check ACL ( $h_{d\mathit{1}}$ , $h_{d\mathit{2}}$ , …, $h_{dn}$ );

 Compute   $w_{\mathit{0}}=H^t$ (w);

    Send   $w_{\mathit{0}}$   to  AP;

    Store   $w_{\mathit{0}}$   and  set   $i_A=\mathit{1}$ ;

    Output temp.d.id = $w_i$ (= $H^{t-\mathit{1}}(w)$ );

    //temporal location

 Process   $H(w_i)=w_{i-\mathit{1}}$ ;

    ⋮

 Define  d.id. $w_i$

Algorithm 5: (Server, customer, new.Items security).

Server, Customer and new.Items are in a Shop Side. There are three security policies, $s_{\mathit{1}}$ , $s_{\mathit{3}}$ , $s_{\mathit{4}}$ .

$s_{\mathit{3}}$ is to confirm the server security, $s_{\mathit{3}}$ is to know the customer's validate and $s_{\mathit{4}}$ is to check their

availability if they can approach the servers.

  $u_{\mathit{1}}$ ← (s.ID₁)*s;

 proceed ( $u_{\mathit{1}}\hspace{0.17em}|\hspace{0.17em}s$ .ID₁);

  $C_{\mathit{1}}$ ← ([ $d_{\mathit{1}}$ ]*[ $s_{\mathit{3},\mathit{4}}$ ]);   //Customer Device Security

 Check Validate ( $C_{d\text{.date}}$ );

 Check ACL ( $C_{\mathit{1}},C_{\mathit{2}},\dots ,C_n$ );

 Share ( $n_{\mathit{1}},n_{\mathit{2}},\dots ,n_n$ );

3.2.2. Second Part Security Policy

The second part is for users’ location, schedule, and controlling information of home devices. First of all, authorisation process—as a security level—contains users location ( $\text{loc.}[x,y,h,\text{sp}]$ ). Obviously, “location hiding algorithm” is applicable for location security [10]. Moreover, Plan Context contains the information about time ( ${dd}_1.{mm}_1.{yy}_1$ ), location ( ${\text{place}}_1=(p_x,p_y)$ ;), user ( $\text{user.}{\text{ID}}_{\#}=(u_2,u_3,u_n)$ ;), and purpose ( ${\text{item}}_1=i_1,i_2,\dots ,i_n$ ;). Those Plan Contexts are usually processed between users and devices. Since the devices are already authenticated and authorised by users, devices perform $\{[d_1{]}_{[}{s}_{\mathrm{1,2}]*\text{pd}}\}$ for Plan Context. Home devices ([ ${hd}_1$ ]) vary; therefore, validation policy and ACL require to be used for each type of usage.

3.2.3. Shop Area Security Policy

The servers containing users’ information can define authentication levels. Registered users’ security policy can be processed with ( $s_3*s_4$ ) as defined. In order to implement user's information, the validity and authorisation must be attained. Lastly, the paper did not define the security information of new items (new.items) since new items can be accessed by random users.

4. Experiment

4.1. Security Algorithms

As defined in Table 2, each level of security follows different policy based on the object to be secured and services provided. The most basic security models are defined as [ $u_1·d_1$ ]. Moreover, the common method of authentication for users is the way using password registered individual devices.

4.2. Analysis Results

4.2.1. Experiment Environment

The experiment is carried out based on already defined algorithms. The paper also assumed that 100 users are in the same environment and classified individual schedules. The users stayed in the same location during half an hour (1800 seconds) and around 30 people moved in/out randomly during the experiment. The individually defined context sets up 10–20 and is defined dynamically.

4.2.2. Experiment

The experiment is carried out based on predefined algorithms. Figure 2 indicates the average processing time for context of 100 users.

Figure 2

The average cost of context process with security.

The average processing time for context of 100 people ranges from 1.5 to 3.6 seconds and the average is 2.712 seconds. This indicates that average processing time of the context from reception—including acceptance and rejection—is 2.712 and this result includes context security elements.

Each user keeps his/her own plan, and at that same time, they will be on each area. They will be members of each group, which has a similar plan, but the experiment does not involve the users in the group who have different plans. Figure 3 shows two experiment results, the security involved model (a) and not involved model (b).

Figure 3

The result of an experiment.

Also, the result of Figure 3 made Table 3. The users define 10–20 contexts. In the model (a), all users carry out security process in order to process 10–20 contexts, whereas none of the security processes have been carried out in the model (b).

Therefore, the model (a) took more time because of the security process; consequently users in the processing time 0–0.9 sec are 52, which was less compared to 71 who did not carry out security process. In the same token, model (a) that carried out security process contains 5 users who consumed more than 8 seconds for processing time, whereas there was none within the model (b). This indicates the increase in overheads for security processing. However, the model (a) can be defined as “safe” since the security process was carried out.

The result value, which would be from Figure 2, forms Table 4. There are two categories in the table, one is “with security case” and another is “without security case” to 100 users. During experimenting time, we evaluated their context-processing time and waiting time (Table 5).

Table 4

The number of users to waiting time.

Category	Sec.
	0	1	2	3	4	5	6	7	8	+8
With security	52	16	10	4	4	2	2	5	0	5
Without security	71	10	9	4	1	3	2	0	0	0

Table 5

The result of an experiment.

Category	Waiting time	Service time
With security	1.89	2.67
Without security	0.71	1.89

As Table 5 indicates, context-processing time including security (2.67 seconds) was 0.78 seconds faster than the results without security modules (1.89 seconds). Therefore, the context had to be delayed for the security process (around 1.18 seconds). This could be explained with the time delay that prearriving context needed to be defined for security levels and decided.

In conclusion, without security case required 0.78 seconds more for the security processing and waiting time was 1.18 seconds prior to the process. However, this overhead time is essential for security process and the context after security process is expected to be much safer and more usable.

5. Conclusions

The research aims to find out the usage of daily users context within smart cities. The research also finds that the context along is not much meaningful since it is just given to users. However, the combination of various contexts interactively is considered as valuable information to understand users’ status and circumstances. This means that clean context is able to provide accurate information—status and circumstances—to users; however, contaminated context supplied cannot be distinguished or filtered by users.

In order to solve this problem, this research employed the method which is applying security modules into the context provided. Moreover, the research suggests 5 different security module applications. As a result, implementation of the context could be highly improved although small amount of overhead occurs.

However, there will be difficulties in applying authentication and authorisation for every context received and transmitted since the context is created constantly and dynamically. Therefore, further research with regard to context classification is essential for each kind and purpose. Moreover, research about contaminated context, which tends to attack users and needs to be identified and blocked simultaneously, is to be carried out. This research will also carry out investigation with regard to context screening modules within smart cities.