ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
Kenta Muranaka
1
, Naoto Yanai
1
, Shingo Okamura
2
and Toru Fujiwra
1
1
Graduate School of Information Science and Technology, Osaka University, Osaka, Japan
2
National Institute of Technology, Nara College, Nara, Japan
Keywords:
Secure Routing Protocol, Wireless Sensor Network, Dynamic Source Routing, Aggregate Signature, ID-based
Signature, ID-based Sequential Aggregate Signature.
Abstract:
Wireless sensor networks are often more vulnerable than wired ones. Especially, an adversary can attack the
networks by utilizing false route information. A countermeasure against the attack is a secure routing protocol
with digital signatures to guarantee the validity of route information. However, existing secure routing proto-
cols are inefficient because the memory size and the computational overhead are heavy. To overcome these
problems, we focus on ID-based sequential aggregate signatures (IBSAS) (Boldyreva et al., 2007). IBSAS
allow users to aggregate individual signatures into a single signature. Moreover, certificates of public keys are
unnecessary for IBSAS. Therefore, IBSAS can drastically decrease the memory size and the computational
overhead. Besides, one of the main concerns for practical use is to construct a protocol specification with
IBSAS. Moreover, since IBSAS are sometimes weak against compromising secret keys, another concern is to
construct its countermeasure. For these purposes, we propose a secure dynamic source routing with ID-based
sequential aggregate signatures, called ISDSR for short and discuss the key management to revoke/update
compromised keys. We also show that the performance of ISDSR is the best in comparison with the existing
protocols.
1 INTRODUCTION
1.1 Background
When devices send data in wireless sensor networks,
intermediate devices relay the received data to its des-
tination as routers. This mechanism is known as
a multi-hop routing protocol. There are also two
types of mechanisms; namely dynamic source rout-
ing (DSR) protocol (Johnson and Maltz, 1996) and
an ad hoc on-demand distance vector (AODV) pro-
tocol (Perkins and Royer, 1999). Both protocols are
well-known instantiations. From the standpoint of an
adversary, wireless sensor networks are more vulner-
able than wired ones since the adversary can attack by
a setup of its own devices within the networks. For ex-
ample, malicious devices can inject false route infor-
mation (Karlof and Wagner, 2003), and then packets
are looped or transferred unnecessarily to far nodes.
A sinkhole attack (Karlof and Wagner, 2003) also ex-
ists, where data is collected to malicious nodes man-
aged by an adversary.
One of the potential approaches to preventing
these attacks is to guarantee the validity of the route
information to secure routing protocols with authen-
tication tools such as digital signatures. This has
been proposed (Hu et al., 2002a; Zapata and Asokan,
2002). Several standardized organizations such as
the European Telecommunications Standards Insti-
tute (ETSI) have suggested the use of digital signa-
tures to prevent forgery of information or unautho-
rized accesses (Guillemin, 2007). We thus focus on
digital signatures. Nevertheless, utilizing digital sig-
natures brings problems for the memory size and the
computational overhead. From another standpoint of
sensor networks, the batteries of sensor devices are
small and low-capacity. Hence, the memory size and
the computational overhead should be small. Based
on these mechanisms and approaches, our goal is to
construct a secure routing protocol with both min-
imum memory size and lower computational over-
head.
1.2 Problems for Secure Routing
Protocols
The secure routing protocols discussed in this work
are routing protocols with digital signatures that guar-
376
Muranaka, K., Yanai, N., Okamura, S. and Fujiwara, T.
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature.
DOI: 10.5220/0006001003760387
In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 376-387
ISBN: 978-989-758-196-0
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

antee the validity of the route information. In particu-
lar, each node generates signatures on route informa-
tion when the node sends a packet including the route
information. Any node that received the packets and
the signatures verify its validity. However, a trivial
use of digital signatures increases the data size of the
packets linearly in proportion to the number of nodes.
This then requires each node to contain a large size
of memory storage and it also requires a large amount
of computational time to verify all of the signatures.
Moreover, since certificates for public keys are neces-
sary, obtaining and verifying the certificates often re-
quire large cost. Although Kim and Tsudik (Kim and
Tsudik, 2009), Ghosh and Datta (Ghosh and Datta,
2011) and Muranaka et al. (Muranaka et al., 2015)
have proposed secure routing protocols to decrease
the overhead of signatures by the use of multisigna-
tures, they are still insufficient due to the verification
of public keys via certificates. Verification including
certificates for public key often require heavy cost,
and thus the existing protocols are unpractical due to
the large overhead.
1.3 Contributions
In this work, we propose a new secure routing proto-
col to guarantee the validity of the route information,
which is the most efficient for the memory size and
the computational overhead in existing secure rout-
ing protocols. In particular, in addition to combin-
ing individual signatures into a single short signa-
ture,verification of public keys via certificates are un-
necessary for our protocol. Our main approach is to
utilize ID-based sequential aggregate signatures (IB-
SAS) (Boldyreva et al., 2007). We name the proposed
protocol a
secure DSR with ID-based sequential ag-
gregate signatures (ISDSR)
. The IBSAS use digital
signatures to obtain both multisignatures (Itakura and
Nakamura, 1983) where signatures are compressed
into a single short signature and ID-based signa-
tures (Shamir, 1984) so that any identity can be used
as a public key for each user. Although there are sev-
eral secure routing protocols (Kim and Tsudik, 2009;
Muranaka et al., 2015) with multisignatures that de-
crease the size of signatures, they are still unpractical
due to verifications of public keys via certificates. In
comparison, our proposed protocol removes such ver-
ifications of public keys by virtue of ID-based signa-
tures.
Our primary contribution is to propose a protocol
specification of ISDSR for practical use. A new pro-
tocol specification is required for DSR with IBSAS
because IBSAS are different from the conventional
digital signatures in terms of multisignatures and ID-
based signatures. Constructing an efficient and fea-
sible specification is still a challenge problem. Fur-
thermore, since identities are used as public keys and
they are unique information, it is also difficult for ID-
based signatures to revoke/update keys if the keys are
compromised. Therefore, we clarify the specification
and discuss the management of public keys. We show
that the performance of ISDSR is the best relativelyto
the existing protocols. In this work, we focus on DSR
as a routing protocol in ad hoc networks. We consider
that the main construction of ISDSR can be extended
to other routing protocols such as AODV.
2 RELATED WORKS
Zhou and Haas (Zhou and Haas, 1999) proposed the
first secure routing protocol for key management on
ad hoc networks. Hu et al. (Hu et al., 2002a; Hu
et al., 2005) have proposed Ariadne in DSR (John-
son and Maltz, 1996) with message authentication
codes (MAC) and protocols with digital signatures.
Next, Papadimitratos and Haas (Papadimitratos and
Haas, 2002) have proposed another protocol called
secured routing protocol (SRP) with symmetric cryp-
tography. In comparison with Ariadne, SRP makes no
assumptions regarding intermediate nodes between a
source and a destination.Hu et al. have also proposed
SEAD (Hu et al., 2002b) in destination-sequenced
distance vector protocol (DSDV) (Broch et al., 1998).
SEAD has utilized MAC. In AODV (Perkins and
Royer, 1999), Zapata and Asokan firstly proposed se-
cure AODV (SAODV) (Zapata and Asokan, 2002).
SAODV is based on both types of cryptography. Fol-
lowing these authors, Sangiri et al. (Sanzgiri et al.,
2005) showed the vulnerabilities of SAODV and the
proposed ARAN to improvethe vulnerabilities by uti-
lizing public key cryptography.
In recent years, there are three protocols with sig-
nature schemes for multiple signers. The first pro-
tocol is the secure route discovery protocol (SRDP)
by Kim and Tsudik (Kim and Tsudik, 2009), and they
haveutilized sequential aggregatesignatures (Lysyan-
skaya et al., 2004) and accountable-subgroup mul-
tisignatures (Boldyreva, 2003; Micali et al., 2001).
Ghosh and Datta (Ghosh and Datta, 2011) have pro-
posed identity based secure AODV (IDSAODV) with
the sequential aggregate signatures. IDSAODV is
the second protocol. However, we mention that their
meaning “identity-based” is different from the use of
ID-based signatures. That is, IDSAODV does not
utilize ID-based signatures, but the sequential aggre-
gate signature schemes. Moreover, public keys of all
nodes for IDSAODV are registered in each node in
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
377

advance. Thus, IDSAODV is impractical. The third
protocol is the secure routing protocols by Muranaka
et al. (Muranaka et al., 2015), and these protocols are
based on ordered multisignatures (Boldyreva et al.,
2007; Yanai et al., 2013) and general aggregate sig-
natures (Boneh et al., 2003). However, they are still
insufficient as described in the previous section.
In the ID-based setting, Ghosh and Datta (Ghosh
and Datta, 2013) also have proposed the secure dy-
namic routing protocol (SDRP) utilizing an ID-based
key exchange protocol. However, the cost of their
work seems to be inefficient compared to the works
of (Kim and Tsudik, 2009; Muranaka et al., 2015)
since SDRP requires each node to keep the linear size
of shared keys with respect to the number of signers.
Namely, each node has to keep both ID information
for other nodes and its shared keys to communicate
each other to verify the validity of route information.
We emphasize that it is quite different from our work
in the sense of the use of ID-based signature schemes
for multiple signers. More precisely, each node for
our protocol can keep only ID information to verify
validity.
3 DYNAMIC SOURCE ROUTING
DSR (Johnson and Maltz, 1996) is a routing protocol
designed for an ad hoc network. It can construct au-
tonomous sensor networks. DSR has two functions,
i.e.,
route discovery and route maintenance . The route
discovery searches for a route and constructs a route
when a transfer is required. The route maintenance
restores a route which has broken.
3.1 Route Discovery
The route discovery finds a route when a node has a
packet to send to a destination. The route discovery
consists of a search phase with
route request packets
(RREQs) and a reply phase with route reply packets
(RREPs).
In the search phase, a source node broadcasts
RREQs around the node. Intermediate nodes write
route information to the RREQ by adding their own
IDs to the RREQ and broadcasting this information
to neighbor nodes. This process is iterated until a
destination node receives the RREQ. Then the desti-
nation node knows the route information through the
RREQ. Since RREQ is transmitted as a local broad-
cast, a node often receives the RREQ transmitted by
the node-self in advance. In such a case, the node
checks whether its own ID is written in RREQ. If
so, the node detects a loop and discards the RREQ.
The RREQ consists of header and route information
as in Figure 1. According to RFC4728 (Johnson et al.,
2007), a source node ID and a destination node ID are
included in the IP field. However, we do not assume
the other layers, and consider that these IDs are in-
cluded in the route information.
Figure 1: Route request packet (RREQ).
In the reply phase, the destination node sends the
RREP to the source node when it receives the RREQ.
The RREP is given the route which has been found by
the RREQ. The destination node informs the source
node of the route by sending the RREP via the reverse
order of the route. When the source node receives the
RREP, the route between the source node and the des-
tination node is constructed. Then the source node
sends data to the destination node via the route. The
source node stores the route information in the cache
and reuses it when it sends data to the same destina-
tion node.
3.2 Route Maintenance
In Route Maintenance, when a node detects a bro-
ken route, it sends other nodes
route error packets
(RERRs) and informs them of the destruction of the
route. The node which has detected the broken route,
for a short detect node, checks its own cache to see
whether there are substitute routes. If so, the detect
node changes the route to the substitute route and
continues to send data via the substitute route. Oth-
erwise, the detect node sends a RERR to the source
node which has sent data via the broken route. If
the nodes which received the RERR have the bro-
ken route in their cache, they delete the route in their
cache. RERR consists of a header and error infor-
mation as described in Figure 2. In the route main-
tenance, 3 is set in error type and the broken node
is described in type specific information. Therefore,
RERR is constructed as in Figure 3 in the route main-
Figure 2: Route error packet (RERR).
SECRYPT 2016 - International Conference on Security and Cryptography
378

Figure 3: Route error packet (RERR) for route mainte-
nance.
tenance. That is, the detect node ID is described in the
Error Source Node ID and the source node ID which
has sent data via the broken route is described in the
Error Destination ID. The broken node ID is then de-
scribed in the Unreachable Node ID.
4 ISDSR Model
4.1 Security Requirements
Sanzgiri et al. (Sanzgiri et al., 2005) argued that se-
cure routing protocols should satisfy five security re-
quirements when a route is constructed. However,
these requirements can be integrated into two require-
ments. Therefore, we designed ISDSR to satisfy the
following two requirements:.
1. Attackers cannot spoof other nodes.
2. Attackers cannot forge route information.
We define “guaranteeing the validity of the route in-
formation” as satisfying the above two requirements.
ISDSR guarantees the validity of route information.
4.2 Assumptions
Node Assumptions. The network consists of two
kinds of nodes, i.e., sensor nodes and a manage-
ment server. We hereafter refer to sensor nodes
as nodes. The management server manages other
nodes. In other words, the management server is-
sues an identity for each node, and generates a se-
cret key for each node. We explain this in more
detail in Section 6.1.
Network Assumptions. In the network, data is
transmitted in both directions.
4.3 Attack Model
We define honest nodes as nodes which are man-
aged by the management server, and attacker nodes
as nodes which are non-managed. Honest nodes work
as a specification of the protocol. The purpose of at-
tackers is to attack networks which consist of only
honest nodes to set their own nodes. This network is
opened and the attacker can eavesdrop and manipu-
late data. Although sensor networks are vulnerable to
DoS attacks such as jamming on the physical layer,
we do not consider these attacks in this paper. We
also do not consider the attacks on a media access
control protocol. The attackers cannot hijack, rob, or
destroy honest nodes. Attackers forge and manipu-
late the route information so that packets go through
attack nodes. This attack model is equivalent to the
definition of that a “ managed-open attack” according
to Sanzgiri et al. (Sanzgiri et al., 2005).
5 DESIGN PRINCIPLE
5.1 Foundation of ID-based Signature
Schemes for Multiple Signers
As ID-based signature schemes for multiple signers
can aggregate signatures into a single signature, the
size of the signatures is constant with respect to the
number of signers. Because they are ID-based sig-
natures, certificates of public keys are unnecessary.
Currently, there are ID-based aggregate signatures
(IBAS) (Gentry and Ramzan, 2006) and ID-based
sequential aggregate signatures (IBSAS) (Boldyreva
et al., 2007) as ID-based signature schemes for mul-
tiple signers. The difference between these two
schemes is the timing of the aggregation of the signa-
tures. In IBAS, any signer can aggregate individually
generated signatures. On the other hand, each signer
for IBSAS generates signatures and their aggregation
on the same algorithm. The restriction of the timing
of aggregation in IBSAS is stronger than that in IBAS.
However, each signer can only send a single signature
in IBSAS. The functionality of IBSAS is sufficient for
exchanging one signature between nodes in a secure
routing protocol. The other difference is the necessity
of a time stamp. It is necessary for IBAS and it is un-
necessary in IBSAS. Since DSR does not require the
time stamp, the use of IBSAS is more suitable than
IBAS. Based on these observations, we utilize IBSAS
in DSR.
5.2 Identity-based Sequential Aggregate
Signatures
5.2.1 Algebraic Setting
Let G,G
T
be groups of the same prime order p. A
paring is an efficiently computable map e: G × G →
G
T
such that the following two conditions hold;
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
379

• Bilinearity: For all u,v ∈ G and a,b ∈ Z, we have
e(au,bv) =e(u,v)
ab
.
• Non-degeneracy: For any generator g ∈ G
∗
, we
have e(g,g) 6= 1
G
T
where 1
G
T
is an identity ele-
ment over G
T
. That is e(g,g) generates G
T
We call (p,G,G
T
,e) a bilinear-map parameter.
5.2.2 Algorithm
IBSAS have four algorithms, i.e., Setup, KeyDeriva-
tion, Signing and Verification. These algorithms are
described in Algorithm 1-4.
Algorithm 1: Setup.
Ensure: Master public key mpk and master secret
key msk
1: generate the bilinear-map parameter (p,G,G
T
,e)
2: g
1
,g
2
R
← G
3: α
1
,α
2
R
← Z
p
4: {H
1
},{H
2
} : {0, 1}
∗
→ G
5: {H
3
} : {0,1}
∗
→ Z
p
6: return (G,G
T
,e,g,α
1
g,α
2
g,{H
i
}
i=1,...,3
) as the
mpk and (α
1
,α
2
) as the msk
Algorithm 2: KeyDerivation.
Require: msk,ID ∈ {0,1}
∗
Ensure: ID’s secret key sk
ID
1: return (α
1
H
1
(ID), α
2
H
2
(ID))
Algorithm 3: Signing.
Require: sk
ID
i
,m ∈ {0, 1}
∗
,σ,L
i−1
=
((ID
1
,m
1
),... ,(ID
i−1
,m
i−1
)) ∈ {{0,1}
∗
×
{0,1}
∗
}
i−1
Ensure: signature σ
′
= (σ
′
1
,σ
′
2
,σ
′
3
)
1: if i = 1 then
2: σ is defined as (1
G
,1
G
,1
G
)
3: end if
4: parse σ as (σ
1
,σ
2
,σ
3
)
5: r, x
R
← Z
p
6: σ
′
3
← σ
3
+ xg
7: σ
′
2
← σ
2
+ rg
8: σ
′
1
← σ
1
+ rσ
3
+ xσ
′
2
+ α
2
H
2
(ID
i
) +
H
3
(ID
i
||m
i
)α
1
H
1
(ID
i
)
9: return (σ
′
1
,σ
′
2
,σ
′
3
) as the ID’s signature
6 CONSTRUCTION OF ISDSR
ISDSR consists of four functions, i.e.,
setup , secure
route discovery
, secure route maintenance and key
Algorithm 4: Verification.
Require: mpk,((ID
1
,m
1
),... , (ID
n
,m
n
)),σ
Ensure: 1 or 0
1: if all of ID
1
,... ,ID
n
are distinct then
2: parse σ as (σ
1
,σ
2
,σ
3
)
3: if e(σ
1
,g)
?
=
e(σ
2
,σ
3
) · e(
∏
n
i=1
H
3
(ID
i
||m)H
1
(ID
i
),α
1
g)
then
4: return 1
5: else
6: return 0
7: end if
8: else
9: return 0
10: end if
management . Notations in this section are as de-
scribed in Table 1. In this work, we assume that head-
ers are updated in a similar manner to that of the con-
ventional DSR. In other words, we leave this as an
open problem where we discuss the detail of the head-
ers.
Table 1: Notations and their descriptions.
Notation Description
φ empty set
ID
a
||ID
b
concatenation of identities ID
a
and ID
b
,
ID
s
source node ID
ID
d
destination node ID
ID
i
i-th node ID
ID
c
detect node ID
ID
e
broken node ID
ID
r
revoked ID
ID
u
updating node ID
ID
MS
management server ID
msk master secret key
mpk master public key
sk
ID
i
ID
i
’s secret key
σ
ID
i
signature generated by ID
i
in Signing
hd header of packet
RI route information
SRREQ
ID
i
SRREQ generated by ID
i
EI error information
ET error type number
k
ID
shared key between
the management server and ID
Enc(k,m) ciphertext for a message m
by a shared key k
Dec(k,c) message decoded
for a ciphertext c by a shared key k
6.1 Setup
A management server generates a master public key
and a master secret key through the Setup of IBSAS.
SECRYPT 2016 - International Conference on Security and Cryptography
380

The management server issues an identity for each
of the nodes, and generates an ID’s secret key corre-
sponding to the ID for each of the nodes through the
KeyDerivation of IBSAS. The management server
also generates a shared key for each of the nodes to
communicate encrypted messages between the man-
agement server and each of the nodes. Each of nodes
pre-installs the master public key, the secret key for
the node’s IDs and the shared key.
6.2 Secure Route Discovery
6.2.1 Basic Concept
ISDSR constructs a route via the secure route discov-
ery instead of the route discovery in DSR, and guar-
antees that there are no attacker nodes in the route. IS-
DSR searches a route with
secure route request pack-
ets (SRREQs), and construct the route with
secure
route reply
packets (SRREPs).
6.2.2 Search Phase
The search phase for the secure route discovery is the
same as that in DSR except for adding each node’s
signature to a packet. Namely, SRREQ consists of
a header, route information and a signature as de-
scribed in Figure 4. A source node writes its own ID
in route information. The source node then generates
a signature for route information through the Sign-
ing of IBSAS and adds the signature to the SRREQ.
The source node broadcasts the SRREQ to neighbor
nodes. A node that receives the SRREQ adds its own
ID to the route information. The node generates a
new signature for the route information as a message
and the signature in SRREQ by Signing. The node
replaces the old signature with the new signature in
the SRREQ, and broadcasts it around the node. When
the destination node receives the SRREQ, it verifies
the signature in the SRREQ using received interme-
diate nodes IDs by Verification of the IBSAS. If the
signature is valid, the destination node starts the re-
ply phase. Otherwise, the node waits until the node
receives the SRREQ whose signature is valid.
6.2.3 Reply Phase
In the reply phase, the destination node generates a
signature for route information by Signing. It adds
the signature to SRREP and sends the SRREP to its
source node. When the source node receives the SR-
REP, the source node verifies the signature in the SR-
REP Verification with the destination node ID. If the
signature is valid, the route is constructed. Otherwise,
the source node discards the SRREP.
Figure 4: Secure request packet for i-th node (SRREQ
ID
i
).
Figure 5: Secure route reply packet (SRREP).
6.2.4 Algorithms
Notations are as described in Table 1. SRREQ con-
sists of three elements as described in Figure 4; i.e.,
a header hd, route information RI and a signature σ.
SRREP consists of three elements as described in Fig-
ure 5; i.e., a header hd, route information RI and a
signature σ. A header in ISDSR is the same as that
in DSR. RI consists of three kinds of identity; i.e., a
source node ID, a destination node ID and the inter-
mediate nodes ID. A destination node in SRREP is
the same as a source node in SRREQ. RI in SRREP is
given as the reverse order of RI in SRREQ. Functions
SRREQConstructCSRREPConstruct, LoopCheck
and SRREPHeaderUpdate are described in Func-
tion 1 - 4DSRREQConstruct which takes as input
a header, route information and a signature, is a func-
tion which updates the header in a similar manner as
DSR, and constructs a SRREQ with these three kinds
of elements, i.e., the header, the route information
and the signature. LoopCheck which takes as input
a node ID and route information, is a function which
checks whether the node ID is included in the route in-
formation. If so, it returns 1. Otherwise, it returns 0.
SRREPConstruct which takes as input route infor-
mation and a signature, is a function which constructs
the header in a similar manner as that of the conven-
tional DSR, and a SRREP with the header and the
route information. The route information in SRREP
is the reverse order of route information described in
the input in a similar manner as that of the conven-
tional DSR. SRREPHeaderUpdate which takes as
input SRREP, is a function which constructs the SR-
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
381

REP, in which the header is updated. Algorithm 5 -
10 are algorithms in the secure route discovery.
Function 1: SRREQConstruct.
Require: RI, σ, hd
Ensure: SRREQ = (hd,RI, σ)
1: update hd
2: SRREQ ← (hd, RI, σ)
3: return SRREQ
Function 2: LoopCheck.
Require: RI, ID
Ensure: 1 or 0
1: if ID ∈ RI then
2: return 1
3: else
4: return 0
5: end if
Function 3: SRREPConstruct.
Require: RI
′
, σ
Ensure: SRREP = (hd,RI,σ)
1: construct a header hd.
2: RI ← reverse order of RI
′
3: SRREP ← (hd,RI,σ)
4: return SRREP
Function 4: SRREPHeaderUpdate.
Require: SRREP = (hd
′
,RI, σ)
Ensure: SRREP = (hd,RI,σ)
1: update the header
2: return SRREP
Algorithm 5: The search phase on a source node.
Require: sk
ID
s
, ID
s
, ID
d
Ensure: SSREQ
ID
s
= (hd
0
,RI
0
,σ
ID
s
)
1: RI
0
← φ
2: hd ← φ
3: RI
0
← RI
0
||ID
d
||ID
s
4: σ
ID
s
← Signing(sk
ID
s
,RI
0
,1)
5: SSREQ
ID
s
← SRREQConstruct(hd,RI
s
,σ
s
)
6: return SSREQ
ID
s
6.3 Secure Route Maintenance
6.3.1 Basic Concept
A node detects a link break to the next hop in data
transfer. The detect node sends a secure route error
packets
(SRERRs) to a source node. The SRERR
is as described in Figure 6, and includes a signature
generated by the detect node via Signing. Intermedi-
ate nodes between the detect node and its source node
just transfer the SRERR. The source node verifies the
signature by Verification with the detect node ID and
transfers the data again by a route which does not
include the broken link.
Algorithm 6: The search phase on an i-th node.
Require: ID
i
, sk
ID
i
,
SRREQ
ID
i−1
= (hd
i−1
,RI
i−1
,σ
ID
i−1
)
Ensure: SSREQ
ID
i
= (hd
i
,RI
i
,σ
ID
i
) or 0
1: if LoopCheck(RI
i−1
,ID
i
) = 1 then
2: discard SRREQ
ID
i−1
3: return 0
4: else
5: RI
i
← RI
i−1
||ID
i
6: σ
ID
i
← Signing(sk
ID
i
,RI
i
,σ
ID
i−1
)
7: SSREQ
ID
i
← SRREQConstruct(hd
i−1
,RI
i
,σ
ID
i
)
8: return SSREQ
ID
i
9: end if
Algorithm 7: The search phase on a destination node.
Require: SRREQ
ID
n
= (hd
n
,RI
n
,σ
ID
n
)
Ensure: 1
1: while Verification(mpk,RI
n
,σ
ID
n
) 6= 1 do
2: wait other SRREQs
3: end while
4: return 1
Algorithm 8: The reply phase on a destination node.
Require: sk
ID
d
, SRREQ
ID
n
= (hd
n
,RI
n
,σ
ID
n
)
Ensure: SRREP = (hd,RI,σ
ID
d
)
1: σ
ID
d
← Signing(sk
ID
d
,RI
n
,1)
2: SRREP ← SRREPConstruct(RI
n
,σ)
3: return SRREP
Algorithm 9: The reply phase on a i-th node.
Require: SRREP = (hd
′
,RI, σ
ID
d
)
Ensure: SRREP = (hd,RI,σ
ID
d
)
1: SRREP ← SRREPHeaderUpdate(SRREP)
2: return SRREP
6.3.2 Algorithms
Algorithms 11 and 12 are algorithms for secure route
maintenance. SRERR is as described in Figure 6.
SRERR in the secure route maintenance is the same
SECRYPT 2016 - International Conference on Security and Cryptography
382

Algorithm 10: The reply phase on a source node.
Require: SRREP = (hd,RI, σ
ID
d
)
Ensure: 0 or 1
1: if Verification(mpk,σ
ID
d
,RI) = 1 then
2: construct a route
3: return 1
4: else
5: discard SRREP
6: return 0
7: end if
as RERR in the route maintenance of DSR ex-
cept for the addition of a signature. Func-
tion SRERRConstruct is described in Func-
tion 5DSRERRConstruct which takes as input error
information EI, a signature σ and the number ET is
a function which constructs SRERR with error type
ET. Algorithms11 and 12 are algorithms in the se-
cure route maintenance.
Figure 6: Secure route error packet (SRERR) for secure
route maintenance.
Function 5: SRERRConstruct.
Require: EI, σ, ET
Ensure: SRERR
1: construct a header hd which Error Type= ET.
2: SRERR ← (hd,EI,σ)
3: return SRERR
Algorithm 11: A detect node.
Require: sk
ID
c
, ID
c
,ID
s
,ID
e
Ensure: SRERR
1: EI ← φ
2: EI ← EI||ID
c
||ID
s
||ID
e
3: σ
ID
d
← Signing(sk
ID
c
,EI, 1)
4: SRERR ← SRERRConstruct(EI,σ
ID
c
,3)
5: return SRERR
6.4 Key Management
Key management is a mechanism to revoke and up-
date the ID. The key management utilizes SRERR ex-
tended from RERR. The SRERR has two kinds of er-
ror types, i.e., a key revocation type (Error Type=4)
and key update type (Error Type=5) for key manage-
ment.
Algorithm 12: A source node.
Require: SRERR = (hd,EI,σ
ID
c
)
Ensure: 1 or 0
1: if Verification(mpk, σ
ID
c
,ID
c
) = 1 then
2: confirm the broken link.
3: return 1
4: else
5: discard the SRERR.
6: return 0
7: end if
6.4.1 Key Revocation
Basic Concept. When a node ID is revoked as a
public key, a management server broadcasts a SR-
ERR included in the node ID and a signature gener-
ated by the management server via Signing to other
nodes. When nodes receive the SRERR, they veri-
fies the signature in the SRERR by Verification with
the management server ID. If it is valid, nodes delete
routes included in the revocation ID in their caches.
They store the revocation ID in their caches to check
whether the ID is in routes under route construction.
Algorithms. Algorithms 13 and 14 are algorithms
in Key Revocation. The SRERR in Key Revocation
is as described in Figure 7. The Error Type is 4,
the Error Source Node ID is the management server
ID, the Error Destination Node ID is broadcast and
Type-Specific Information is the revocation ID in the
SRERR. The signature generated by the management
server is added to the SRERR.
Figure 7: Secure route error packet (SRERR) for key revo-
cation.
Algorithm 13: A management server.
Require: ID
MS
,ID
r
,sk
ID
MS
Ensure: SRERR
1: EI ← φ
2: EI ← EI||ID
MS
||Broadcast||ID
r
3: σ
ID
MS
← Signing(sk
ID
MS
,EI, 1)
4: SRERR ← SRERRConstruct(EI,σ
ID
MS
,4)
5: return SRERR
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
383

Algorithm 14: Nodes.
Require: SRERR = (hd,EI,σ
ID
MS
)
Ensure: SRERR or 0
1: if Verification(mpk,σ,ID
MS
) = 1 then
2: delete routes included in the ID in their caches.
3: store ID
r
in their caches as the revocation ID.
4: broadcast SRERR.
5: return SRERR
6: else
7: discard SRERR.
8: return 0
9: end if
6.4.2 Key Update
Basic Concept. A management server issues a new
ID and generates a secret key corresponding to the ID
in KeyDerivation. The management server sends a
SRERR included in the new ID, the secret key and
a signature generated by the management server via
Signing to the node in which ID is updated. The
secret key is encrypted by a shared key between the
management server and the node. The node veri-
fies the signature in SRERR by Verification with the
management server ID. If the signature is valid, the
node updates its ID and stores the secret key decoded
by the shared key. Then the management server re-
vokes the old ID with a SRERR in the key revocation.
Algorithms. Algorithms 15 and 16 are algorithms
in the key update. The SRERR of the key update
is described in Figure 8. The Error Type is 5, the
Error Source Node ID is the management server ID
and the Error Destination Node ID is the updating
node ID. A new node ID and an encrypted secret
key is described in the Type-Specific Information.
A signature generated by the management server is
added to the SRERR.
Algorithm 15: A management server.
Require: ID
MS
, sk
ID
MS
Ensure: SRERR
1: EI ← φ
2: EI ← EI||ID
MS
||ID
u
||ID
new
||Enc(k
ID
u
,sk
ID
New
)
3: σ
ID
MS
← Signing(sk
ID
MS
,EI, 1)
4: SRERR ← SRERRConstruct(EI,σ
ID
MS
,5)
5: revoke ID
u
in Key Revocation
6: return SRERR
Algorithm 16: An updating node.
Require: SRERR = (hd,EI,σ
ID
MS
)
Ensure: 1 or 0
1: if Verification(mpk, σ
ID
MS
,ID
MS
) = 1 then
2: ID
u
← ID
New
3: sk
u
← Dec(k
ID
u
,Enc(k
ID
u
,sk
ID
New
))
4: store ID
u
as revocation node ID in its cache.
5: return 1
6: else
7: discard SRERR.
8: return 0
9: end if
Figure 8: Secure route error packet (SRERR) for key up-
date.
7 DISCUSSION
7.1 Performance Analysis
We show IDSDR can decrease the memory size and
the computational overhead. That is,
routing over-
head
(RO) and routing latency (RL) of ISDSR are
smaller than those of other secure routing protocols.
These are main bottlenecks for secure routing proto-
cols. Thus, these decreasement is important for prati-
Table 2: Notations and their descriptions in numerical anal-
ysis.
Notation Description
ID
SIZE
size of node ID
RSASig
SIZE
size of RSA-based signature (2048bit)
RSASig
GEN
RSA-based signature generation time
RSASig
VER
RSA-based signature verification time
ECCSig
SIZE
size of ECC-based signature (224bit)
ECCSig
GEN
ECC-based signature generation time
ECCSig
VER
ECC-based signature verification time
Cert
SIZE
size of public key certificate(about 1KB)
Cert
VER
certificate verification time
MAC
SIZE
size of MAC (128bit)
MAC
GEN
MAC generation time
MAC
VER
MAC verification time
KEY
GEN
shared key generation time
Hash
SIZE
size of hash (128bit)
t number of intermediate nodes
SECRYPT 2016 - International Conference on Security and Cryptography
384

cal use. Table 2 showsnotations and their descriptions
in this section.
7.1.1 Routing Overhead (RO)
The RO here refers to the total number of bytes that
are transmitted over the network to establish a secure
path from any source to any destination. As DSR
does not include any security mechanism, the RO of
the DSR with t intermediate nodes to establish a valid
route is expressed by the following equation:
RO
DSR
= (t + 1) × (RREQ
SIZE
+ RREP
SIZE
). (1)
We consider the RO of ISDSR. In ISDSR, each inter-
mediate node sends a single signature to the next node
in both the search phase and the reply phase.
Therefore the RO of the ISDSR with t intermedi-
ate nodes is computed by the following equation:
RO
ISDSR
= RO
DSR
+ 2× (1+ t) × ECCSIG
SIZE
. (2)
Ghosh and Datta (Ghosh and Datta, 2013) calculate
ROs of other secure routing protocols as follows:
RO
ARAN
=RO
AODV
+ 2× (1+ 2× t)
× (RSASig
SIZE
+Cert
SIZE
),
(3)
RO
SAODV
=RO
AODV
+ 2× (1+ t)
× (RSASig
SIZE
+Cert
SIZE
+ Hash
SIZE
),
(4)
RO
IDSAODV
=RO
AODV
+ 2× (1+ t) × ECCSig
SIZE
+ (3/2× t
2
+ t/2 + 2) × HASH
SIZE
,
(5)
RO
SDRP
=RO
AODV
+ (2+ 3× t) × ECCSig
SIZE
+ t × MAC
SIZE
+ (3/2× t
2
+ t/2 + 2) × ID
SIZE
.
(6)
Ghosh and Datta (Ghosh and Datta, 2013) have
calculated RO
IDSAODV
by using ID
SIZE
instead of
HASH
SIZE
. However, IDSAODV needs the hash val-
ues of its public keys of RSA as ID. Therefore,
we calculate RO
IDSAODV
by using HASH
SIZE
. SDRP
needs hardware addresses of nodes as IDs in addition
to IDs of nodes, which are used in the original spec-
ification of DSR. We denote by ID
SIZE
the overhead
based on this redundant information. However, such
redundant information is unnecessary for ISDSR be-
cause the overhead with respect to the IDs in ISDSR
is identical to RO
DSR
.
DSR is extremely similar to AODV. Therefore it
is fair to consider RO
DSR
= RO
AODV
. The RO of DSR
is smaller than that of other secure routing protocols.
7.1.2 Routing Latency (RL)
RL of a routing protocol is the time required to estab-
lish a valid secure route. In the case of a secure rout-
ing protocol, RL includes latency because of route
discovery and latency because of the addition of se-
curity mechanisms in the protocol.
In Secure Routing Discovery, a signature is gen-
erated (1+ t) times and the signature is verified only
one time in a destination node.
RL
ISDSR
=RL
DSR
+ (2+ t) × ECCSig
GEN
+ 2× ECCSig
VER
.
(7)
Ghosh and Datta (Ghosh and Datta, 2013) also cal-
culate the RLs of other secure routing protocols as
follows:
RL
ARAN
=RL
AODV
+ 2× (1+ t) × RSASig
GEN
+ 2× (2+ t) × RSASig
VER
+ 2× (2+ t) ×Cert
VER
,
(8)
RL
SAODV
=RL
AODV
+ 2× (1+ t)RSASig
GEN
+ 2× (1+ t) × RSASig
VER
+ 2× (1+ t) ×Cert
VER
,
(9)
RL
IDSAODV
=RL
AODV
+ 2× (1+ t) × RSASig
GEN
+ 3× (1+ t) × RSASig
VER
,
(10)
RL
SDRP
=RL
AODV
+ (2+ t) × ECCSig
GEN
+ (3+ 2× t) × ECCSig
VER
+ t × (MAC
GEN
+ MAC
VER
)
+ (1+ t) × Key
GEN
.
(11)
The RL of the DSR is also the same as that of
the AODV. We know that computing ECC-based sig-
natures is faster than computing RSA-based signa-
tures. The shared generation involvesbilinear pairing,
which is also fast. Therefore the RL of the ISDSR is
comparable with any of the existing routing protocols.
7.2 Security Analysis
If route information is forged or there are attacker
nodes in the route information, a signature for the
route information is rejected by verification. In other
words, if a route is constructed with a valid signa-
ture, the route consists of only honest nodes. That
is, ISDSR satisfies requirement 1 in Section 4.1. Be-
cause we do not consider that attackers rob nodes and
their control in ISDSR, the attacker cannot know any
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
385

node’s secret key. Therefore, the attackers cannot
forge signatures. That is, ISDSR satisfies requirement
2 in Section 4.1. Based on these observations, IS-
DSR can guarantee the validity of the route informa-
tion when a route is constructed. Meanwhile, the se-
curity level of ISDSR is equivalent to that of ARAN,
i.e., “managed-open”.
8 CONCLUSION
We proposed ISDSR extended from DSR, which is
the routing protocol in sensor networks, and we con-
sidered ISDSR’s security for the importance of the se-
curity of sensor networks. We showed that ISDSR
guarantees that there are no attacker nodes in the con-
structed routes. Our future research considers further
implementation and evaluation of ISDSR. We focus
on the use of NS-3
1
to evaluate ISDSR. Other future
research will consider stricter security analysis. In
particular, we plan to use formal methods as described
in (Arnaud et al., 2010; Arnaud et al., 2014; Zhang
et al., 2014). We also plan to extend other routing
protocols in ad hoc networks, e.g, AODV, to utilize
IBSAS in the future.
ACKNOWLEDGEMENTS
This research was supported in part by the Japan Soci-
ety for the Promotion of Science KAKENHI Number
16K16065. We appreciate their support.
REFERENCES
Arnaud, M., Cortier, V., and Delaune, S. (2010). Modeling
and verifying ad hoc routing protocols. In Proc. of
CSF 2010, pages 59–74. IEEE.
Arnaud, M., Cortier, V., and Delaune, S. (2014). Modeling
and verifying ad hoc routing protocols. Information
and Computation, 238:30–67.
Boldyreva, A. (2003). Threshold signatures, multisigna-
tures and blind signatures based on the gap-diffie-
hellman-group signature scheme. In Proc. of PKC
2003, volume 2567 of LNCS, pages 31–46. Springer.
Boldyreva, A., Gentry, C., O’Neill, A., and Yum, D. (2007).
Ordered multisignatures and identity-based sequential
aggregate signatures, with applications to secure rout-
ing (extended abstract). In Proc. of CCS 2007, pages
276–285. ACM.
Boneh, D., Gentry, C., Lynn, B., and Shacham, H. (2003).
Aggregate and verifiably encrypted signatures from
1
https://www.nsnam.org/
bilinear maps. In Proc. of EUROCRYPT 2003, vol-
ume 2656 of LNCS, pages 416–432. Springer.
Broch, J., Maltz, D., Johnson, D., Hu, Y.-C., and Jetcheva,
J. (1998). A performance comparison of multi-hop
wireless ad hoc network routing protocols. In Proc. of
MobiCom 1998, pages 85–97. ACM.
Gentry, C. and Ramzan, Z. (2006). Identity-based aggregate
signatures. Public Key Cryptography - PKC 2006,
3958:257–273.
Ghosh, U. and Datta, R. (2011). Identity based secure aodv
and tcp for mobile ad hoc networks. In Proc. of ACWR
2011, pages 339–346. ACM.
Ghosh, U. and Datta, R. (2013). Sdrp: Secure and dynamic
routing protocol for mobile ad-hoc networks. IET Net-
work, 3(3):235–243.
Guillemin, P. (2007). ICTSB - RFID Networks Inter-
net Of Things. ETSI. http://docbox.etsi.org/Partn
ers/ICTSB Open/RFID/ICTSB RFID seminar 2007-
10-24/P.Guillemin
ICTSB.
Hu, Y.-C., Perrig, A., and Johnson, D. (2002a). Ariadne:
a secure on demand routing protocol for ad hoc net-
work. In Proc. of MobiCom 2002. ACM.
Hu, Y.-C., Perrig, A., and Johnson, D. (2002b). Sead: Se-
cure efficient distance vector routing for mobile wire-
less ad hoc networks. In Proc. of WMCSA 2002, pages
3–13. ACM.
Hu, Y.-C., Perrig, A., and Johnson, D. (2005). Ariadne:
a secure on demand routing protocol for ad hoc net-
work. Wireless Networks, 11:21–38.
Itakura, K. and Nakamura, K. (1983). A public-key cryp-
tosystem suitable for digital multi-signatures. NEC
Research and Development, 71:1–8.
Johnson, D., Hu, Y.-C., and Maltz, D. (2007). The dynamic
source routing protocol (dsr) for mobile ad hoc net-
works for ipv4.
Johnson, D. and Maltz, D. (1996). Dynamic source rout-
ing in ad hoc wireless networks. Mobile Computing,
353:153–181.
Karlof, C. and Wagner, D. (2003). Secure routing in wire-
less sensor networks: Attacks and countermeasures.
Ad Hoc Networks, 1(2-3):293–315.
Kim, J. and Tsudik, G. (2009). Srdp: Secure route discov-
ery for dynamic source routing in manets. Ad Hoc
Networks, 7(6):1097–1109.
Lysyanskaya, A., Micali, S., Reyzin, L., and Shacham, H.
(2004). Sequential aggregate signatures from trapdoor
permutations. In Proc. of EUROCRYPT 2004, volume
3027 of LNCS, pages 74–90. Springer.
Micali, S., Ohta, K., and Reyzin, L. (2001). Accountable-
subgroup multisignatures: extended abstract. In Proc.
of CCS 2001, pages 245–254. ACM.
Muranaka, K., Yanai, N., Okamura, S., and Fujiwara,
T. (2015). Secure routing protocols for sensor net-
works: Construction with signature schemes for mul-
tiple signers. In Proc. of Trustcom 2015, pages 1329–
1336. IEEE.
Papadimitratos, P. and Haas, Z. J. (2002). Secure routing
for mobile ad hoc networks. In Proc. of CNDS 2002,
pages 27–31.
SECRYPT 2016 - International Conference on Security and Cryptography
386

Perkins, C. and Royer, E. (1999). Ad-hoc on-demand dis-
tance vector routing. In Proc. of WMCSA 1999, pages
90–100. IEEE.
Sanzgiri, K., LaFlamme, D., Dahill, B., Levine, B. N.,
Shields, C., and Belding-Royer, E. (2005). Authen-
ticated routing for ad hoc networks. IEEE Journal on
Selected Areas in Communications, 23(3):598–610.
Shamir, A. (1984). Identity-based cryptosystems and signa-
ture schemes. In Proc. of CRYPTO 84, volume 196 of
LNCS, pages 47–53. Springer.
Yanai, N., Manbo, M., and Okamoto, E. (2013). Or-
dered multisignature schemes under the cdh assump-
tion without random oracles. In Proc. of ISC 2013,
volume 7807 of LNCS, pages 367–377. Springer.
Zapata, M. and Asokan, N. (2002). Securing ad hoc routing
protocols. In Proc. of WISE, pages 1–10. ACM Press.
Zhang, F., Jia, L., Basescu, C., Kim, T., Hu, Y., and Perrig,
A. (2014). Mechanized network origin and path au-
thenticity proofs. In Proc. of ACM CCS 2014, pages
346–357. ACM.
Zhou, L. and Haas, Z. (1999). Securing ad hoc network.
IEEE Network Magazine, 13(6):24–30.
ISDSR: Secure DSR with ID-based Sequential Aggregate Signature
387