Towards Continuous Authentication in Internet of Things Based
on Secret Sharing Scheme
Omaimah Omar Bamasag
Dept. of Mechanical Engineering
Massachusetts Institute of Technology
Cambridge, MA, USA, obamasag@mit.edu
Dept. of Computer Science, King Abdulaziz University
Jeddah, Saudi Arabia, obamasek@kau.edu.sa
ABSTRACT
In this paper, we propose a novel continuous authentication
protocol for the Internet of Things based on secret sharing
scheme. This protocol provides secure and efficient authentication
for frequent message transmissions in short session time intervals.
The protocol introduces a novel use of secret sharing scheme, that
is, the secret is used as an authenticator and the shares are used as
authenticator tokens. Each token is an outcome of a function of
time that binds the secret share to a specific point in time during
the session such that the share can only be revealed in that
specific time. The share can be linked back to the secret and,
hence, the message source can be authenticated. Security
evaluation of the protocol shows that it fulfills the stated security
requirements and addresses the listed attacks. Performance
evaluation of the protocol shows that it is lightweight in terms of
computation and communication costs, thus addressing the
resource-constrained IoT endpoints.
Categories and Subject Descriptors
C.2.0 [Computer-Communication Networks]: General
Security and protection.
General Terms
Security
Keywords
Internet of Things Security, Continuous Authentication, Time-
bound Authentication
1. INRODUCTION
In recent years, Internet of Things (IoT) has developed rapidly
and gained a lot of attentions both in academia and industry. By
connecting sensors, tiny smart devices and everyday physical
objects with the Internet, IoT provides a new form of
communications for people and devices, which makes the virtual
information world integrated seamlessly with the real world [1].
IoT applications can involve environment monitoring[2], e-
health[3], electric vehicle, and the smart house[4], in which
appliances and services that provide notifications, security,
energy-saving, automation, telecommunication, computers and
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee. Request permissions
from Permissions@acm.org.
WESS'15, October 04-09, 2015, Amsterdam, Netherlands
© 2015 ACM. ISBN 978-1-4503-3667-3/15/10…$15.00
DOI: http://dx.doi.org/10.1145/2818362.2818363
Kamal Youcef-Toumi
Dept.of Mechanical Engineering
Massachusetts institute of Technology
Cambridge, MA, USA
youcef@mit.edu
entertainment will be integrated into a single ecosystem with a
shared user interface.
As many of these applications are related to user’s daily life,
privacy and security aspects are very important[5, 6, 7, 8].
Unfortunately, the nature of the complex and heterogeneous
structure of IoT makes the security issues very challenging. In
addition, most nodes are resource-limited, which makes the
feature of lightweight necessary for IoT security mechanisms. An
illustrative example would be a remote user who wants to access a
particular node of the IoT. Such a user needs to be authenticated
and, if done positively, allowed to gather data from or send
commands to that node.
Authentication mechanism is considered to be a central
element in addressing the security issue in the above scenario.
Authentication can prevent unauthorized users from gaining
access to resources, prevent legitimate users from accessing
resources in an unauthorized manner, and enable legitimate users
to access resources in an authorized manner. Mutual
authentication is also needed and is highly important since all
– parties need to be sure of the legitimacies of all the entities
involved.
There is a major need for the continuity of the secure
communication channel in IoT.Continuity in this context refers to
establishing a secure transmission channel for a pre-defined
period of time, i.e. session, to transmit certain number of
messages. It complements the initial standard, i.e. public key-
based, authentication and is necessary to guarantee that the
sender, who was identified and authenticated in the beginning of a
session, is the same throughout the session. We will refer to this
concept as continuous authentication.
The continuous authentication of a secure channel also
incorporates additionalfeatures. That is,fast and simple
authentication for frequent message transmission in short time-
intervals. Maintaining a low-cost authenticated communication
channel is important in IoT applications that require frequent
message transmissions, e.g. broadcasting control messages in a
Smart Grid.
Existing authentication solutions, however,do not provide
continuous authenticationfor the IoT. The work in[9, 10, 11, 12,
13, 14, 15, 20, 21]address the initial, i.e. 'handshake', phase, in
which the involved parties submit their credentials, and upon
positive verification, the parties are authenticated and the
communication proceeds. However, this 'one-time' process is
performed every time the parties need to communicate, which
incur computation and communication overhead on both sides.
This issue is critical specially when a large number of messages
are needed to be transmitted/exchanged in a short time interval, as
explained in the previous paragraph. As far as the authors'
knowledge, no existing solution in IoT addresses the continuous
authentication issue. This research will focus on further
investigating the continuous authentication in IoT and proposes a
solution to address it.
The contribution of this paper is two-fold. First, secret shares are
utilized as authentication tokens. These shares are portions of a
secret agreed upon between the involved parties in the initial
authentication phase. Therefore, instead of sending the identity
proofing credentials, e.g. public key certificate and a signed
message, the Claimer will only need to send these shares
consecutively, i.e. a single share accompanies a message, to the
Verifier who will be able to link the share with the original secret,
hence authenticate the Claimer.
Second, the proposed solutionintroduces the notion of 'time' such
that the authentication tokenswill be employed as a function of
time, changing in relation to time slots that agreed upon in
advance between the Claimer and the Verifier. A single function
outcome reveals portion of data to the verifier so that it will be
assured of the Claimer's identity.This leads to 'continuity' concept
in a sense that the secure transmission channel will be set between
both entities by releasing time-bound variables generated by the
Claimer and can be verified by the Verifier in a pre-determined
time-frame. This enables Claimer authentication in any point in
time in a fast and efficient way, which is very appealing in
applications requires frequent message transmissions in IoT
environment.
The reminder of the paper is organized as follows. Section 2
identifies the attack model threatening the authentication process
in IoT and then lists the security requirements that address these
attacks. Section 3 critically reviews the related work against the
specified requirements. Section 4 presents the proposed protocol
by explaining the design principles, the assumptions, notations
used in protocol description, and then detailing the protocol steps.
Section 5 evaluates the proposed protocol in terms of fulfilling the
security and functional requirements presented in Section 2.
Section 6 gives the performance evaluation of the protocol in
terms of its computation, communication, and storage costs and
compares it with that of the most related work. Finally, Section 7
outlines the conclusion and future work.
2.UNDERSTANDINGIoTTHREATS AND
SECURITY REQUIREMENTS
2.1 Threats and attacks
This section defines threats that our authentication solution
addresses. It presents well-known attacks on IoT so as
tounderstand the activities in IoT networks, and thus, helps in
deciding the mitigation plans.
T1. Man-in-the-Middle Attack: an active attacker can insert
itself between the communicating parties, i.e. Claimer and
Verifier, to gain access to the authentication protocol messages.
Then the attacker can impersonate the Verifier to the Claimer
while concurrently impersonating the Claimer to the Verifier. This
may allow it to authenticate itself to both parties successfully.
T2.Eavesdropping attack:a passive attacker can listen to the
communication channel in order to extract useful data from the
information flow, i.e. secret key.
T3.Denial of Service Attack: All the devices in IoT have
limited computation and storage resources, thus they are
vulnerable to resource exhaustion attack. Attackers can send
messages or requests to specific device so as to consume their
resources. In our case, the attacker might overwhelms the Verifier
with authentication requests.
T4. Replay Attack: an active attacker can capture
authentication messages exchanged between a legitimate
Claimerand a Verifier, and then replay them at a later time to be
falsely authenticated as that Claimer.
2.2 Security and performance requirements
To establish a continuous (time-bound) authenticated secure
channel between two entities in IoT, the following security
requirements should be met.
S1. Message source authentication: The message receiver
(Verifier) should be able to authenticate the identity of the
message sender (Claimer), i.e. ensuring that the message was sent
from the expected source. Fulfilling this requirement addresses
the Man-in-the-Middle attack T1.
S2. Continuous authentication: A secure transmission
channel is to be set between both the communicating entities in a
pre-determined time-frame. This will allow the performance of
the authentication handshake process, conducted between entities,
only at the beginning of the communication session. Then,
Claimer authentication will be performed at any point in time
during the communication session in a fast and efficient way,
which is very appealing in frequent message transmissions.
S3. Integrity of data is to ensure that the data has not been
tampered with or changed while being transmitted over networks
and stored by the entities.
S4. Confidentiality of the authentication token, i.e. the
secret: Transmitting parts of the secret, i.e. secret shares, should
not reveal any information on the secret itself.
S5. Access control: For this requirement, authentication plays
a significant role in order to protect entities and resources against
unauthorized access of internal and external entities. Fulfilling
this requirement addresses the Denial-of-Service attack T3.
S6. Freshness: is to ensure that theClaimer has just sent the
message to the Verifier for the first time, i.e. it was not replayed.
Fulfilling this requirement protects the protocol against the
Replay attack T4.
In addition to the security requirements listed above, some
functional requirements are desirable to be fulfilled as well.
F1. Efficiency: the authentication solution should be
lightweight, taking into account the computation, storage, and
power limitations of many of IoT devices.
F2. Scalability: The increasing number of entities in IoT
application should be accommodated in the solution with
minimum effort.
3. RELATED WORK
The literatures on authentication schemes for IoT have been
recently growing, aiming to address the emerging security and
privacy issues surrounding the IoT applications. Many security
mechanisms have been proposed based on symmetric key
cryptography due to its efficiency in computation and energy
consumption [27, 28]. The scalability problem and memory
requirement to store keys makes it inefficient to heterogeneous
devices in IoT. Asymmetric key cryptography-based solution
overcomes these challenges with high scalability, low memory
requirements and no requirement of key pre-distribution
infrastructure. However, their downside is that they require high
computational cost.
The asymmetric encryption scheme that has been employed the
most in IoT authentication solutions is Elliptic Curve
Cryptography (ECC). This is due to it being a lightweight
encryption mechanism, hence suited to the resource-constrains
IoT devices. The authentication and access control method
presented in [11] aims at establishing the session key on the basis
of ECC. This scheme defines attribute-based access control
policies, managed by an attribute authority. It enhances mutual Table 1. Analysis of the most related work against
authentication among the user and the sensor nodes, as well as specified security requirements
solving the resource-constrained issue at application level in IoT.
The authors in [22, 24, 25] have also presented ECC-based IoT - Command RFID-
authentication protocols. Security Elliptic & control- Elliptic
RSA, the most widely used asymmetric encryption scheme, is also Requirements Curve RSA 2014 Curve 2013
used in authentication provision for IoT. Authors in [20] 2012 [13] [20] [22]
presented a broadcast authentication scheme that we call rapid Message source
√ √ √
authentication, which is suitable for time-critical authentication of authentication
command and control messages in large and distributed systems. Continuous
The work in [29] presents s two-way authentication security X X X
Authentication
scheme for IoT based on existing Internet standards, specifically
the Datagram Transport Layer Security (DTLS) protocol. Integrity of data X √ √
Table 1 shows an comparison of the most related work to ours in
terms of addressing the security requirements stated in Section 2. Confidentiality
of the
From Table 1, it is clear that the existing solutions do not fulfill √ NA √
each and every requirement for secure and continuous IoT authentication
authentication, specially the continuous authentication token
requirement which has not been addressed. Even if they address Access control √ Not clear √
most of the requirements, as the work in [22], it still has the issues
of requiring high level of computational and communicational Freshness of
powers. authentication √ √ √
request
4. PROPOSED SOLUTION Our proposed solution employs Shamir (t, n) secret sharing
Based on the current literature of Internet of Things, we may draw scheme for continuous authentication.Traditionally, the (t,n)
an abstract architecture for our proposed solution. 'Things' are end secret sharing scheme is used to secure the secret by distributing
nodes in the IoT environment. They have unique Identifiers, i.e. its shares to n entities. Our approach uses the secret sharing
IP address, and are able to communicate with each other over the scheme differently such that the shares are used as authenticating
Internet. In order to manage large number of resources, every token to authenticate the Claimer (secret and shares generator) to
'Thing' will be pre-registered on a nearby trustworthy gateway the recipient (Verifier) in a pre-defined time-frame. That is, the
(denoted as Registration Authority RA). RA is able to store Verifier will be able to link the received share to its original
entities' public key certificates, securely generate and distribute secret, thus authenticate the Claimer (share generator) without the
secret keys and maintain a history record of all access requests for need to perform costly public/private key cryptographyoperations.
auditing purpose. This is performed in a pre-defined time-frame during which the
In our framework, a Claimeris an entity needs to send consecutive Claimer sends the shares accompanying the requiredmessages to
messages to a Thing, i.e. Verifier. For example, in smart grid the Verifier, hence achieving fast and efficient continuous
environment, a Claimer would be a user who wants to send authentication.
appliance control messages to his home appliances. A home In addition, the proposed continuous authentication employs a
appliance, which would be a Verifier, needs to verify the source 'time-bound' feature.In the added ‘time-bound’ feature, each share
and the integrity of the received command messages before is tied with a time. That is, the share can only be revealed when
executing them. the time it ties to is reached. This approach enables the realization
In this section, the design principles of the protocol are described of the 'continuity' in authentication as each time-bound share
along with the assumptions and the notation used in the protocol reveals portion of the shared secret (authenticator). This, in turn,
description. Finally, the protocol steps are detailed. enables the Verifier to authenticate the Claimer at any point in
time during the session time-frame. The implementation of this
4.1 Design Principles feature requires time synchronization among all parties involved
The proposed continuous authentication protocol incorporates in the protocol execution.
secret sharing and time-bound concepts. The secret sharing
scheme is originally proposed byShamir in 1979 [17]. It was to 4.2 Assumptions
generate shares of the secret s and distribute them to n The following assumptions are used in the work presented in this
shareholders. When an authorized number t of paper.
shareholderscollaborate together, they can retrieve the secret. The  Both the Claimer and the Verifier have communicated with
scheme is (t, n) threshold where any t number of users can RA to register their IDs, public key certificate (if required), and
collaborate to recover the secret out of n users. Shamir’s scheme received the secret s through a secure communication channel.
is based on polynomial interpolation over a finite field. It uses the  Both the Claimer and the Verifier stores securely to be used
fact that we can construct a polynomial of degree t − 1 only if t as a base for the continuous authentication protocol.
data points are given. That is, given t points in the 2-dimensional  Both the Claimer and the Verifier agree on a time-frame Ƭ
plane (xi, yi), . . . , (xt, yt), with distinct xi’s, there is one and only during which a series of messages M={m1, …mk}, k is the
one polynomial P(x) of degree t – 1 such that P(xi) = yi for all i. maximum number of messages, are to be sent from the Claimer to
the Verifier. These messages need to be authenticated in a timely
manner.

4.3 Notation
Table 2 shows the notation used in the remaining part of
this paper.
Table 2. Notation
Notation Definition
H(m) One-way collision free hash function, e.g. SHA-2 [18].
One-way MAC function executed on a message m using
MAC(m)s
secret key s [19].
Time period agreed upon by both the Claimer and the
Ƭ Verifier for the session during which the continuous
authentication takes place
ti
Positive integer denoting point in time frame Ƭ, associated
with message mi.
Secret chosen randomly from a finite group Zp, P is prime,
s Step3.Authentication verification (Verifier Side):
that both the Claimer and the Verifier store securely.
time-bound secret shares that the Claimer generates from
ui
the secret s and sends to the Verifier.
Positive integer denoting time flag during Ƭ that is bound
g i: to secret share uisuch that the share uiis only revealed to
the Verifier at time point ti.
Timestamp of the current time read from the computer's
tmi
clock by the Claimer to be incorporated in the message.
Unique identity associated with entity x, e.g. IDC is the
IDx
identity of the Claimer and IDV is that of the Verifier.
Verification outcome holding a flag value indicating the
VO
outcome of each verification step.
4.4 Protocol Steps
The proposed protocol consists of three main steps: Initialization,
Message Authentication Initiation, and Authentication
Verification. Following is a detailed explanation of these steps.
An overview of the protocol is shown in Figure1.
Figure1. Proposed Protocol
Step1.Initialization (Claimer Side):
1) Claimer defines the time period Ƭ for the session, where
the continuous authentication takes place to authenticate a
maximum of k number of messages,Ƭ = {t1, .., tk), where ti,
1  i  k , is a time associated with sending a message mi. Claimer
also defines time flagsG= {g1,, …, gk} such that time flaggiis
associated with each time ti..
2) Claimer generates time-bound shares uifor ssuch that
share ui is only revealed to the recipient in time ti.. Coefficients ai
are chosen randomly from ZP.
k
u i  f ( x)   ai x  ( s  g i ), x  [1, k ]
i (1)
i 1
3) For each share ui, the Claimer calculates share
authenticatorsai
k
sa i  H ( ai xi ) (2)
i 1
Step2.Message authentication initiation (Claimer Side):
During the time frame Ƭ, the Claimer sends messagesM={m1,
…mk} to the Verifier as follows:
4) For message mi, the Claimer sends the message
combined with the share ui, its authenticator sai, the time flaggi, a
timestamp tmi,and its authenticator MAC(mi, gi, ui, tmi)s. The
Claimer employs the secret s in flag authenticator Macing process
to ensure that it has been generated by the Claimer itself. The
Claimer then sends the whole message, containing the above
mentioned parts, to the Verifier as follows:
MS1. C  V :
{IDC , IDV , sai , mi , ui , tmi , MAC ( IDC , IDV , mi , g i , ui , tmi ) s , gi }
Verification V-1: Check the freshness of message MS1 by
performing the following verification:
a) Compare the timestamp tmi in MS1 with the current time
from the Verifier's machine. The Verifier will accept the
message if the difference between the two times is within
a margin agreed upon in advance between the two parties,
i.e. few seconds. If the outcome of this check is negative,
the Verifier will set VO ='tm-neg', send it to the Claimer in
message MS2 and terminate the protocol, otherwise, the
Verifier will go to the next step.
b) Check the freshness of the share ui, i.e. it is has been
received from the Claimer for the first time. This is done
by checking if it exists in the table of stored shares, i.e.
previously sent by the Claimer for the current session. If
the check outcome is positive, the Verifier will set VO =
'ui-neg', send it to the Claimer in message MS2 and
terminate the protocol; otherwise, the Verifier will go to
the next step.
5) Checks the authenticity of time flaggiand timestamp
tmi(received from the Claimer in message MS1 by performing the
following verification:
Verification V-2:
Compute a fresh MAC' of the message mi, share ui, time
flag gi, and timestamp tmireceived from the Verifier:
MAC' = MAC(IDC, IDV, mi, gi, ui, tmi)s.
If it equals to the received MAC in MS1, then gi, is genuine, i.e. as
sent by the Claimer and has not been changed in transit. If the
check outcome is negative, then the Verifier will set VO='MAC-
neg', send it to the Claimer in message MS2,and terminate the
protocol, otherwise, the Verifier will go to the next step.
6) Reveals the shareui':
ui'=ui-gi (3)
7) Checks the authenticity of the share ui', i.e. if it belongs
to the secret s, by performing the following verification:
Verification V-3:
a) Calculates fresh share authenticator sai' from the revealed
share ui and the secret s:
sai'=ui-s (4)
b) Computes the hash of the freshly calculated share
authenticator sai' and checks that it is equal to the share
authenticatorsai received in MS1:
?
sa i  H ( sa i ' ) (5)
If the outcome of this check is negative, the Verifier will set
VO='sa-neg',sends it to the Claimer in message MS2, and
terminates the protocol. The outcome being positive proves that
the share ui is associated with the secret s.
 OnceStep 3 is completed successfully, the Verifier is assured
that the message mi was sent from the legitimate Claimer with
identity IDcto the Verifier with identity IDV. The Verifier will set
VO='positive', and send it to the Claimer in message MS2:
MS2. V  C : VO
This protocol is repeated for each message sent from the
Claimer to the Verifier during the session time Ƭ. It enables the
Claimer to establish an authenticated communication channel with
the Verifier where he can send several messages with minimum
authentication overhead in the pre-defined time-frame.
5. SECURITY EVALUATION OF THE
PROTOCOL
We show in the following that the protocol presented above
satisfies all the security and functional requirements and
provides protection against the threats stated in Section 2.
S1. Message source authentication: When the Verifier
performs Verification V-3 in Step3 to verify the
authenticity of the share ui', i.e. belonging to the secret s,
the secret s is used which is only known to the Claimer and
the Verifier. Thus, the Verifier will be convinced that the
message mi has been originated and sent by the Claimer,
hence S1 security requirement is fulfilled. Addressing this
requirement secures the protocol against Man-in-the-
Middle attackT1.
S2.Continuous Authentication: The aim of the
continuous authentication property is to establish an
authenticated channel between the Claimer and the Verifier
during a predefined time-frame Ƭ. To achieve this property,
the Claimer releases parts (ui) of a knowledge shared
between him and the Verifier (s), each part in a certain
point in time ti within Ƭ and each part is distinct from
others. The Verifier needs to do two checks to ensure
continuous authentication.
 First is to check the authenticity of the share ui, i.e.
that it belongs to the secret s known to both the Claimer
and the Verifier. This is achieved by using the share
authenticator sai. The Verifier uses the share uiand the
secret s to calculate a fresh share authenticator sai' in
equation (4). If the hash of sai' is equal to the one received
in MS1 from the Claimer, then the Verifier is ensured that
the share ui was generated by the Claimer.
 Second is to check the authenticity of the time flag
gi, i.e. it is generated and sent by the Claimer. This is done
by performing Verification V-2.
The above two checks being positive ensures that the
message mi is sent from the true Claimer in a time point ti.
S3. Integrity of data:There are three pieces of data in
transactionMS1, sent by the Claimer, which the Verifier
needs to be ensured that they have not been altered in
transit. They are the message mi, share ui, and time flag gi.
For this purpose, the Verifier performs Verification V-2, i.e.
comparing a freshly computed MAC of these items with
the MAC received from the Claimer. If both are equal, then
the Verifier is assured that they have not been altered in
transit. In addition, Verification V-3(b) detects if any
alteration is done to the share authenticator sai,while in
transit, by comparing the hash of the share authenticator
calculated by the Verifier sai'with the share authenticator
sai received from the Claimer. The outcome of the
comparison being positive ensures the integrity of the share
authenticator sai.
S4. Confidentiality of the authentication token, i.e. the
secret: Each run of the protocol (consecutive messages
during a session of time period Ƭ) produces different secret
shares ui. Knowledge of secret shares from past protocol
execution does not allow deduction of future secret shares.
In addition, each session has a newly generated secret s
known only to the Claimer and Verifier and stored securely
by both parties. Therefore, even knowing all the secret
shares by the end of a protocol run, i.e. being able to
reconstruct the secret, will not give the attacker an
advantage to use thatsecret for future sessions. This fulfills
S4 security requirement and addresses the Eavesdropping
Attack T2.
S5. Access control: Fulfilling requirements S1 and S2
ensures the authenticity of the message source, i.e. that the
Claimer is who he claims to be.
This gives the Verifier a confidence to execute the message
contents and also to grant the Claimer access to its
resources as the Claimer's privilege permits. This protects
against the Denial-of-Service attack T3.
S6.Freshness: When the Verifier performs the checks
inVerification V-2 with positive outcome, he will be
assured that the message MS1 has been sent for the first
time from the Claimer in a timely manner. Fulfilling this
requirement protects the protocol against the Replay Attack
T4.
F1. Efficiency: The main functions the protocol
employs are hash and MAC algorithms. These are
considered efficient in terms of computational power, in
comparison to the symmetric and asymmetric key
operations performed by similar protocols, i.e. Elliptic
Curve in [13], RSA digital signatures in [20], and
symmetric encryption in [21]. Also, the protocol encounters
only two transactions: MS1from the Claimer to the Verifier
and MS2 from the Verifier back to the Claimer (per
authenticated message). This addresses the resource-limited
feature of the IoT end point devices.
F2. Scalability. The protocol can be scaled easily to
multi-cast scenario where the Claimer communicates with
more than one Verifier. In this case, the Claimer only needs
to store a secret key per Verifier and generate its
corresponding shares.
6. PERFORMANCE EVALUATION OF
THE PROTOCOL
In this section, our protocol is evaluated against the most related
work in terms of computational cost, communication overhead,
and storage requirement.
 Table 3. Performance comparison between our protocol and the most related work

S- key P-key Rand. No.

Phase Hash MAC Multip. Exp. Add/subt
encrypt encrypt gen.

K times k-1
Init.
1 1 - - - K+2 (each share)
(once) (once)
Our
Protocol
Verif.

1 1 - - - - - 2

Comm.
-
Init.

1 4 ECC 2 - - -
IoT-Ellipic encrypted
Curve
Verif.

2012 [13] 1 - - 2 ECC 1 - - -

- -
gen.
Sig.

Command 1 1 2 (key gen) 1 1

& control-
RSA 2014
Verif

- - - - -
Sig.

[20] K 1 1
Reader

RFID- 3 - - 5 EEC 3 - 1 2
Elliptic
Curve
2013 [22] - - - - - -
Tag

1 3

 Hash-256: takes an input message of maximum size 2 64-1 and

6.1 Computational Cost produces a fixed length (256 bits) output.
The constrains of IoT resource-limited devices have been taken  MAC: 128 bits
into account while designing the protocol, hence, all the  Recommended key size:
operations employed in our protocol are simple and lightweight as o Symmetric : 128 bits
a complaint with this requirement. Hash and MAC functions were
o ECC: key size 283 bits
used, which are considered fast and efficient. Expensive public
key encryption was avoided in our protocol. Table 3 shows the o RSA: 3072 bits
comparison between our protocol and the most related work in  ID : we will consider IPv6 address as an entity's ID: 128 bits
terms of the number of times each operation is performed. It can  Timestamp: 64 bits
be seen that our protocol is more efficient than the related work as  Secret (and its shares): 128 bits.
it employs only MAC and Hash algorithms whereas the work in
[13] and [22] uses Elliptic curve cryptography and the work in
[20] uses RSA cryptography. However, our protocol executes
random number generation k time. This is done once at the Table 4. Comparison of Communication costs between
beginning of the protocol and performed on the stronger side of our protocol and the most related work
the communication link, i.e., Claimer. No of
Msg size Storage
To further highlight the efficiency of our protocol, we refer to a msgs
(Verifier)
study presented in [31] in which the authors presented a
comprehensive analysis of the energy requirements, in terms of 1 800 64+ k*128
Init. Verif. Init

µJ/ byte, of a wide range of cryptographic algorithms that are Our

protocol
used as building blocks in security protocols. It shows that the 1 8 bits
energy consumption of the hash and MAC algorithms, which are
the only cryptographic algorithms employed in our protocol, 1 667 bits
consumes the least energy of all listed algorithms. IoT-Ellipic
Curve 2012
8/ 128/ 8/ 8/ 8/
Verif.

6.2 Communication and Storage Cost [13] 7 539

144 (ID+
Communication costs refer to the number of the messages session key)
exchanged between the Claimer and the Verifier and also the size Command 1 2,304 bits
gen.
Sig.

of each message in bytes. Storage costs refer to the memory & control-
requirements, in bytes, of the Verifier side as it is the weakest RSA 2014
Verif.

point in the protocol in terms of resources. The message size has [20] 1,104
been calculated according to the size of the parameters and
algorithms' outputs as recommended by the literature [30]. They RFID-
are as follows: Elliptic
reader

2 40/ 512 384

Curve 2013
[22]
From Table 4, it can be seen that our protocol enjoys the least
number of exchanged messages, one in each direction. The most
notable saving is in the size of the message sent from the Verifier
to the Claimer, which is only 8 bits, in comparison to the large
size of multiple messages sent from the verifier in the related
work. This is very desirable given the constrained Verifier's
devices. The storage costs are considered reasonable in
comparison to those of the related work, given the computational
efficiency of which our protocol outweighed them.
7. CONCLUSION
In this paper, we have presented a novel continuous authentication
protocol for IoT. The novelty of the protocol is reflected in two
concepts. First, it employs the shares, generated by Shamir's
secret sharing scheme from a secret known to both the Claimer
and the Verifier, as authenticating tokens. Second, these tokens
are released from the Claimer to the Verifier in a function of 'time'
such that a single function outcome reveals portion of the secret to
the recipient so that it will be assured of the Claimer identity.
The evaluation of the protocol shows that it satisfies all the
identified security requirements. In comparison with the most
related work, our protocol is more efficient in terms of fulfilling
the functional requirements presented in Section 2.
Our future work will focus on prototyping the protocol using
suitable platform to measure and evaluate its the performance. We
will also work on integrating more context-related factors in the
authentication process and identify levels of criticality of the
transaction to make the authentication multi-factor and multi-
layer.
8. ACKNOWLEDGMENT
The authors thank the Center for Clean Water and Clean Energy
at MIT and KFUPM for the support and facilitation provided for
this research, ARAMCO for funding the research, and King
Abdulaziz University.
9. REFERENCES
[1] Yao, X., Han, X., X., Du, X.. 2013. A Lightweight Multicast
Authentication Mechanism for Small Scale IoT Applications.
IEEE Sensors Journal, vol. 13, no. 10, 3693-3701.
[2] Dlodlo, N. 2012. Adopting the internet of things technologies
in environmental management in South Africa. In
Proceedings of the 2nd International Conference on
Environment Science and Engineering, 45–55.
[3] Li, J., Wu, X., andChen, H. 2011. Research on mobile digital
health system based on internet of things,Electrical Power
Systems and Computers (Lecture Notes in Electrical
Engineering), vol. 99, Springer-Verlag, 495–502.
[4] Wang, Z. 2014. Smart Home System Design Based on Internet
of Things.Applied Mechanics and Materials, vols. 602-605,
3808-3812.
[5] Roman, R., Zhou, J., Lopez, J. 2013. On the features and
challenges of security and privacy in distributed internet of
things, Computer Networks, vol. 57, 2266-2279.
[6] Sicari, S., Rizzardi, A., Grieco, L.A., Coen-Porisini, A. 2015.
Security, Privacy and Trust in Internet of Things: The Road
Ahead. Computer Networks, vol. 76, 146-164.
[7] Wang, K., Bao, J., Wu, M., and Lu, W. 2010. Research on
Security Management for Internet of Things.In Proceedings
of 2010 International Conference on Computer Application
and System Modeling, 133-137.
[8] Sarma, A. and Girao, J. 2009. Identities in the future Internet
of Things.Wireless Personal Communications, vol. 49, no. 3,
353-363.
[9] Turkanovic, M., Brumen, B., Holbl, M. 2014. A novel user
authentication and key agreement scheme for heterogeneous
ad hoc wireless sensor networks, based on the Internet of
Things notion. Ad Hoc Networks, vol. 20, 96-112.
[10] Xu, D. and Chen, Y. 2013. A Safe RFID Authentication
Protocol for Internet of Things.Journal of Theoretical and
Applied Information Technology, vol. 48, no. 1, 359-364.
[11] Ye, N., Zhu, Y., Wang, R.,Malekian, R.,Qiao-min, L. 2014.
An Efficient Authentication and Access Control Scheme for
Perception Layer on Internet of Things, Applied Mathematics
& Information Sciences, vol. 8, no. 4, 1617-1624.
[12] Hernandez-Goya, M.C., and Caballero-Gill, P. 2013.
Analysis of Lightweight Cryptographic Solutions for
Authentication in IoT, InProceedings of EUROCAST 2013,
Part II, LNCS 8112, 373-380.
[13] Xiao, J. andChen, C. 2012. Authentication and Access
Control in the Internet of Things.In Proceedings of 32nd
International Conference on Distributed Computing Systems
Workshops, 588-592.
[14] Mahalle, N., Prasad, N., Prasad, R. 2013. Novel Threshold
Cryptography-based Group Authentication (TCGA) Scheme
for the Internet of Things (IoT).In Proceedings of the
Seventh IEEE International Conference on Advanced
Networks and Telecommunication Systems (ANTS).
[15] Ndibanje, B., Lee, H., Lee, S. 2014. Security Analysis and
Improvements of Authentication and Access Control in the
Internet of Things. Sensors, vol. 14, 14786-14805.
[16] Roman, R. Zhou, J., Lopez, J. 2013. On the features and
challenges of security and privacy in distributed internet of
things, Computer Networks, vol. 57, 2266-2279.
[17] Shamir, A. 1979. How to Share a Secret, Communications of
the ACM, vol. 22, no. 11,.612-613.
[18] NIST, 2008. (FIPS 180-3) Secure Hash Standard (shs).
[19] ISO/IEC 9797. "Information technology – security
techniques – Message Authentication Code (MACs). Part 1:
Mechanisms using a block cipher", 1999, "Part 2:
Mechanisms using a dedicated hash-function", 2002.
[20]Yavuz, A.A. 2014. An efficient real-time broadcast
authentication scheme for command and control messages',
IEEE Transactions on Information Forensic and Security,
vol. 9, no. 10, 1733-1742.
[21] Bonetto, R., Bui, N., Lakkaundi, V., Olivereau, ,A.,Serbanati,
A., Rossi, M. 2012. Secure Communication for Smart IoT
Objects: protocol STACKS, Use Cases and Practical
Examples, In Proceedings of IEEE International Symposium
on a world of wireless, mobile and multimedia networks
(WoWMoM), 1-7.
[22] Liu, Y., Qin, X., Wang, C., Li, B. 2013.A lightweight RFID
authentication protocol based one elliptic curve
cryptography, Journal of Computers, vol. 8, no. 11, 2880-
2887.
[23] Lee, J-Y., Lin, W-C., Huang, Y-H. 2014. A lightweight
authentication protocol for internet of things. In Proceedings
of 2014 International Symposium on Next- Generation
Electronics ISNE, 1–2.
[24] Braun, M., Hess, E., Meyer, B. 2008. Using Elliptic Curves
on RFID Tags, IJCSNS International Journal of Computer
Science and Network Security, vol. 8, no. 2, 1-9.
[25] Ahamed, S. Rahman, F.,Hoque, E. 2008. ERAP: ECC based
RFID Authentication Protocol, InProceedings of 12th IEEE
International Workshop on Future Trends of Distributed
Computing Systems, 219-225.
[26] Zhao, G., Si, X.., Wang, J., Long, X.M and Hu, T. 2011. A
Novel Mutual Authentication Scheme for Internet of Things,
In Proceedings of 2011 IEEE International Conference on
Modeling, Identification and Control (ICMIC), 563- 566.
[27] Park, N., Kim, M., Bang, H. 2015. Symmetric Key-Based
Authentication and the Session Key Agreement Scheme in
IoT Environment, Computer Science and its Applications,
Lecture Notes in Electrical Engineering, Vol. 330, 379-
384.
[28] Gao, D.,Guo, Y.G., Cui, J.Q.,Hao, H.G., Shi, H. 2012. A
Communication Protocol of RFID Systems in Internet of
Things, International Journal of Security and its
Applications, vol. 6, no. 2, 91–102.
[29] Kothmayr, T., Schmitt, C., Hu, W., Brunig, M., Carle, G.
2013. DTLS based Security and Two-Way Authentication
for the Internet of Things, Ad Hoc Networks, vol. 11, no. 8,
2710-2723.
[30] Datagram Transport Layer Seurity (DTLS) 1.2 profile for
Internet o Things', available at
https://tools.ietf.org/html/draft-ietf-dice-profile-06.
[31] Potlapally, N., Ravi, S., Raghunathan, A., Jha, N. 2003.
Analyzing the Energy Consumption of Security
Protocols.InProceedings of the 2003 International
Symposium on Low Power Electronics and Design ISLPED'
03.