International Journal of Distributed Sensor Networks

Volume 2013 (2013), Article ID 768489, 17 pages

http://dx.doi.org/10.1155/2013/768489

Research Article

Logic-Based Security Architecture for Systems Providing Multihop Communication

Iman Almomani,¹ Eman Al-Banna,¹ and Mousa AL-Akhras²

¹Computer Science Department, King Abdullah II School for Information Technology, The University of Jordan, Amman 11942, Jordan

²Computer Information Systems Department, King Abdullah II School for Information Technology, The University of Jordan, Amman 11942, Jordan

Received 16 June 2012; Revised 1 September 2012; Accepted 2 September 2012

Academic Editor: Leonardo B. Oliveira

Copyright © 2013 Iman Almomani et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

Security is a basic element of distributed systems such as ad hoc and sensor communication networks. Several standards define security requirements and enforcers, such as ITU-T Recommendations X.800 and X.805. It is essential to specify and analyze protocols to know which security requirements they achieve. This paper presents a logic-based security architecture (LBSA). LBSA is a systematic way to test if a protocol is secure by checking what security requirements are achieved. Different rules, actions, and sets which fit into the proposed LBSA are included, new ones are also added to complete the architecture. The key advantage of LBSA is that it enables a security protocol to prove its correctness mathematically. Mathematical proofs provided by LBSA cover more cases that usually cannot be covered exhaustively by simulation tools. This paper also specifies and analyzes several security enforcers and protocols and mathematically proves which security requirements they achieve. Mapping between security requirements and inference rules/actions is also provided to facilitate the use of LBSA. Some enforcers are analyzed using LBSA to demonstrate how they achieve security requirements. Finally, we take Ariadne protocol as a case study and show how to use the proposed LBSA architecture to prove that this protocol is secure.

1. Introduction

When two entities communicate to obtain a certain service(s), they must ensure secure end-to-end communication. Systems do not provide efficient services without applying proper security mechanism due to the existence of different types of attackers. Security can be defined through a set of requirements that must be achieved by the communicating parties to communicate securely and protect services from attackers.

Because of the importance of security for end-to-end communication, many secure protocols have been proposed as will be discussed later in the paper. Some of these protocols had taken prevention measures to stop attackers while others had taken the detection approaches. A way to analyze these protocols is required to check if these protocols are secure as their designers claim and to know which security requirements these protocols achieve. In this paper, we propose a logic-based security architecture (LBSA) which is an easy, fast, and reliable way to specify and analyze secure protocols.

Some security requirements, as defined by several standards such as ITU-T Recommendations X.800 and X.805 [1, 2], must be achieved to declare that a protocol is secure. Using LBSA, a protocol can be tested to check which security requirements it achieves. Several efforts have been done to utilize logic in such test [3–8], but logic was used to specify and analyze specific protocols by defining global and local sets, actions, and inference rules. In this paper security architecture is taken as a whole, different actions, sets, and rules which fit into the architecture have been included, that means specifying and analyzing different enforcers and determining the requirements they satisfy. Also, we had labeled the actions, sets and rules for easy access and we added our own to complete the architecture. Additionally, we mapped different security requirements into inference rules/actions. This mapping shows the inference rules/actions which are used during the protocol analysis to achieve security requirement(s).

Utilizing LBSA, protocols can be tested to check if they achieve the security requirements specified by their designers. This checking can be performed by analyzing the protocol and applying appropriate actions and rules. If the rules are applied successfully we conclude that their claim is true, otherwise it is false.

The rest of this paper is organized as follows: Section 2 illustrates the security architecture. Section 3 presents related work. Section 4 presents the proposed Logic-Based Security Architecture (LBSA) for systems providing multihop communication. Section 5 provides possible mapping between security requirements and inference rules/actions. In Section 6, the specification and analysis of message authentication code (MAC) and digital certificate based on LBSA are discussed. Section 7 illustrates how to specify and analyze protocols using LBSA by taking Ariadne routing protocol as a case study. Finally, Section 8 concludes the paper and presents avenues for future work.

2. Security Architecture

Security architecture as defined by ITU-T Recommendations X.800 [1] and X.805 [2] defines a set of security requirements that must be achieved. Figure 1 illustrates this architecture.

Figure 1: Security Architecture extracted from ITU-T Recommendations X.800 and X.805.

Security architecture as shown in Figure 1 includes a set of security requirements that are used to protect systems from different types of attackers. To achieve the objectives of these requirements, a set of security enforcers must be applied.

The requirements and their definitions are illustrated as the following.

(i)Authentication: Prove the identity of the communicating parties.(ii)Authorization: control the access to the system’s resources. Give different entities different privileges according to their roles.(iii)Confidentiality: ensure the secrecy of data. Secret data must be read only by intended recipients.(iv)Integrity: protect the received data from any kind of modifications during transmission from the sender to the receiver.(v)Nonrepudiation: prevent the users from denying the sending of messages or initiating events that they had performed.(vi)Privacy: protect the identity and/or the location of the node and sometimes the routing protocol being used.(vii)Availability: ensure that no one prevents authorized users from getting access to the system available services.

These requirements must be achieved to guarantee secure communication and to prevent and detect different attackers which can be classified into the following.

(i)Internal or external attackers: internal attackers are compromised users who are authorized to enter the system but they are misbehaving. This type of attack needs a detection mechanism to be discovered as they have the authority to access the system’s services. External attackers, on the other hand, are unauthorized entities attempting to access the system’s services; these attackers must be prevented from accessing the system’s resources.(ii)Passive or active attackers: passive attackers monitor the system without taking any action and usually it is a phase that precedes an active attacking. Active attacker takes actions and does modifications.(iii)Intentional or accidental: intentional attack is a planned attack while accidental attacking results from system malfunctions such as software bugs.

Several mechanisms and techniques have been defined to achieve different security requirements. Table 1 gives examples of different security enforces that are used to implement the objectives of different security requirements.

Table 1: Examples of security requirements enforcers.

Security requirement
Security enforcer

(i) Digital certificate

Authentication
(ii) Digital signature

(iii) Message authentication code (MAC)

Authorization
Firewall

Confidentiality
Encryption

(i) Hash function

Integrity
(ii) MAC

(iii) Digital signature

Nonrepudiation
Digital signature

(i) Achieved partially by encryption

Privacy
(ii) Hide node location

(iii) Hide node identity

(iv) Hide routing protocol

Availability
(i) Intrusion detection scheme (IDS)

(ii) Intrusion prevention scheme (IPS)

Secure protocols usually use the above enforces, among others, to achieve the security requirements. There are different ways to analyze security protocols in terms of achieved security requirements such as simulation and mathematical models; this paper uses logic to do such analysis.

3. Related Work

The importance of security in providing successful services in any distributed system raises the necessity of having formal way to analyze security protocols. Previous effort in using logic for analyzing security is Rubin logic [3, 4].

Rubin logic is an approach that specifies and analyzes nonmonotonic cryptographic protocols. It is one of the first approaches to allow reasoning about nonmonotonic protocols [3]. In nonmonotonic protocols, beliefs are changed during protocol execution time. An example of nonmonotonicity is the belief that a key must be changed when a node becomes compromised. To achieve the protocol specification and analysis, Rubin logic defines global and local sets, actions and inference rules.

Rubin and Honeyman [3] focused on authentication protocols. They took KHAT protocol [9] as an example to discover its flaws. KHAT protocol was built to solve the problem of long running jobs in an authenticated environment where a trusted server issues tickets with limited lifetimes for services. The authors gave special attention to ensure the freshness of data using fresh nonce. The main problem they attempted to solve is that principal B cannot achieve the belief that the session key with principal A is fresh. Finally, the authors defined most of global and local sets that are used later in the literature.

Rubin [4] extended the work presented in [3] by adding one set. Rubin [4] aimed to make sure that keys are observed by their intended parties and data items are fresh, especially the public keys. Rubin [4] made link between certificates and requests which reveals weakness in Needham and Schroeder public key protocol [10].

Xu and Xie presented in a series of papers [5–8] the utilization of Rubin logic in analyzing the security for specific protocols.

In [5], Xu and Xie extended the work presented in [4] to analyze nonrepudiation in routing protocols proposed for wireless mobile ad hoc networks (MANET). This work took ARAN [11] routing protocol to test nonrepudiation.

Xu and Xie [6] use the work presented in [5] to analyze electronic commerce protocols and in [7] they have chosen Zhou-Gollmann [12] protocol which is a simple and effective nonrepudiation protocol to illustrate how an electronic commerce protocol is analyzed using the extended Rubin logic.

Two examples of Rubin logic’s applications are given by Xu and Xie in [8]. First example is the Andrew secure RPC [13] protocol using symmetric keys. The second one is X.509 [14] authentication protocol using asymmetric keys.

As can be illustrated from the above-related work, all attempts to utilize Rubin logic have either focused on a specific requirement or a specific protocol. This paper proposes a logic-based security architecture (LBSA) that presents a formal way to analyze any security requirement in any system providing multihop communication. All sets, actions, and rules presented in previous efforts are considered and generalized; new ones are added to complete the architecture. After that, we illustrate how LBSA will be used to test security requirements and issues in different security enforcers and protocols.

4. Logic-Based Security Architecture (LBSA) for Systems Providing Multihop Communication

In this section we illustrate the proposed architecture which defines a logical way for specifying and analyzing different enforcers and different protocols that achieve any security requirement as defined in [2]. Some researchers used logic as mentioned earlier in Section 3. All sets, actions, and rules defined in [3–8] which fit in our architecture have been included and labeled by the proposed LBSA.

Global sets define the specification of the protocol as a whole. Local sets are private to each principal in the specification. Actions are specified as part of the protocol (i.e., how the protocol works) while inference rules are used to reason about the beliefs during the protocol executing. Consequently, the relation between sets, actions, and rules and the result of the action may update the sets. This achieves some rules and conditions which are followed by applying inference rules which in turn update another set(s). Figure 2 shows this relation.

Figure 2: Relation between sets, actions and inference rules.

Using different actions, the protocol can be specified exactly as it works. While executing these actions, local and global sets will have new values which lead to applying some rules. This is the process of analyzing protocols.

The purpose of LBSA is to generalize rules and actions and not to specify them. Accordingly, these rules and actions can be customized according to the context. Sections 6 and 7 illustrate how these sets, rules, and actions can be customized according to the context. Additionally, each set, rule, and action are described in the following tables using the description column.

Table 2 defines different global and local sets. Global sets are labeled as and local sets are labeled as , where is the set number. These sets contain the protocol information. There are five global sets – and ten local sets –. These sets have initial values and these values are changed whenever actions and rules are executed. Global sets (–) were initilly defined in [3] for a specific protocol called KHAT [9]. These global sets have been generalized by LBSA and new global sets are also added. Local sets (–) were initially defined in [3–5] for specific protocols, but they are generalized and labeled by LBSA which also defines new local sets needed to complete the architecture.

Table 2: Global and local sets of LBSA.

Set label
Set name
Description

GS₁
Principal set
All principals (i.e., nodes) participate in the protocol are in this set.

= . There is one initiator of the protocol and it could be any .

GS₂
Rule set
Inference rules needed to derive new statements from existed assertions that are in this set.

R = , where is of the form  

is a condition and D is a statement.

GS₃
Secret set
Each secret in the system exist in this set. During the analysis, the content of this set will be changed for the emergence of new secrets such as session keys.

.

GS₄
Observers set
For each , observers () contain all the principals who could possibly know the secret by listening to network traffic or generating it themselves. The members of the Observers set can be stated explicitly or maintained as formulas representing their membership.

GS₅
FireWall set()
This set presents the firewall list that contains the access control rules that are needed to be applied to the incoming packets of in order to allow or prevent them.

LS₁
Possession set()
This set contains all the data relevant to security that this principal knows or possesses. This includes secret encryption keys, public keys, data that must remain secret, and any other information that is not publicly available. POSS() = .

Note: contains two fields—the actual data and the origin of this data.

LS₂
Belief set()
This set contains all the beliefs held by a principal. This includes the belief that the keys it holds between itself and other principals are good, beliefs about jurisdiction, beliefs about freshness, and beliefs about the possessions of other principals. BEL.

LS₃
Opaque()
This set contains candidates to be added to the Seen set. It is used by the Update function (Table 3(b)). The set contains text parts (data) of the message and a list of the associated keys needed to read them.

LS₄
Seen()
This set contains text parts (data) that sees from messages sent across the network. The Seen sets collectively contain the same information as the observers set.

LS₅
Haskeys()
This set contains keys that sees either because they are in the initial possession set, or because they appear in a message sent across the network and are added to ’s seen set.

LS₆
Behavior list()
This item is a list rather than a set because the elements are ordered. BL . AL is an action list as will be defined below.

LS₇
Bindings set()
This set contains the legal bindings of keys held by a principal. These are bindings that are created by , and bindings that are received in certificates from trusted servers. Bindings .

LS₈
Proofs set()
This set contains all the other principals' nonrepudiation that can prove.

LS₉
PL()
Principals list contains all the principals that must receive Messages (Msgs) from principals .

LS₁₀
AbnBeh()
Abnormal behavior set contains all the principals that detect their abnormal behaviors.

Tables 3(a)–3(c) define the LBSA actions with their descriptions, conditions, and results. Actions are labeled as , where is the action number and these tables contain 30 actions. The actions describe the node operations such as sending messages, receiving messages, generating key pairs among other operations. Actions (–) that are considered in [3–6] had been generalized and fitted in the proposed LBSA. Moreover, new actions are defined and added by LBSA.

Table 3: (a) Actions (ACT₁–ACT₁₀) of LBSA, (b) actions (ACT₁₁–ACT₂₀) of LBSA, and (c) actions (ACT₂₁–ACT₃₀) of LBSA.

(a)  

Action label
Action name
Description
Condition
Result

ACT₁
Send(, X)
sends msg to .
—
Principal sends msg X to .

ACT₂
Receive(, X)
receives msg X from .
—
Principal receives msg from .

ACT₃
Encrypt()
If possesses msg and knows the key k then it can encrypt X using k and possess .
Observers (k).
POSS() = POSS(.

ACT₄
Decrypt(, k)
If possesses msg X which encrypted under k and knows the key k (symmetric encryption) or its inverse (Asymmetric encryption), then can decrypt X and possess it.
Observers, .
POSS() = POSS(.

ACT₅
Generate-nonce(N)
Is used to check out the freshness. A principal generates a nonce to link a challenge and a response. When the response is received, LINK(N) is removed from BEL().
—
POSS() = POSS(,

BEL() = BEL.

ACT₆
Generate-secret(s)
Is used to generate a new secret s. Note that the Observers set will be updated.
—
S:= , 

Observers, 

POSS() = POSS(, 

BEL BEL( #(s), 

where that the value is fresh.

ACT₇
Concat()
Is used to construct a message X out of submessages .
POSS().
POSS() = POSS(.

ACT₈
Split(X)
When a message contains a set of components, this action is used to break it into its components.
X contains , 

POSS().
POSS() = POSS(.

ACT₉
Forget(X)
When no longer in possession of X, this action will be used. If other principles trust then they can believe that is no longer possesses X.
POSS().
POSS( = POSS(,  

if TRUST.  

then BEL POSS.

ACT₁₀
Check-freshness(X)
Is used to verify the freshness of timestamp X.
POSS(), X is not expired.
BEL() = BEL.

(b)  

Action label
Action name
Description
Condition
Result

Forget-secret(s)
When no longer knows the secret s. If other principals trust then they can believe that no longer possesses s.
Observers (s), POSS().
Observers(s) = Observers,  

POSS()= POSS(  

if TRUST = 1 then BEL = BEL

ACT₁₂
Apply(f, X)
Is used to apply function to .
).
POSS():= POSS(.

ACT₁₃
Abort
The protocol aborts when different cracks and events that affect the protocol specification happen.
Protocol run is illegal.
Analysis reports failure.

ACT₁₄
Generate-key-pair()
Is used to generate two keys (public) and its inverse (private).
—
POSS( POSS(.

ACT₁₅
Apply-Asymkey(X, k)
There are two cases for applying asymmetric key operation on X. The first one when X is in the form of and k and are inverses to each other. The second case when X is encrypted using k.
, 

Observers, 

is an asymmetric key.
if    and 

           k is the inverse of ,  

then 

POSS() = POSS(  

else 

POSS() = POSS(.

ACT₁₆
Bind()
Before sending a key, principal can bind this key to other principle using this action. After this binding, both ’s possession and Binding sets will contain .
POSS(, 

, 

k is a key intended for .
POSS( POSS(,  

Bindings  Bindings.

ACT₁₇
Update(X)
After sending a message this action is used to maintain the observers set.
—
Maintains the observers of .

ACT₁₈
Broadcast(X)
Message is broadcasted by to each of its neighbors.
—
broadcasts to each of its neighbors.

ACT₁₉
Check-certificate()
Is used to verify the freshness of the certificate .
POSS(, 

is not expired
BEL = BEL,  

where    is the public key specified in .

ACT₂₀
Check-request
Is used to record new routing record. Each node receives route discovery packet it records the predecessor of that packet and the successor toward the destination.
∈ POSS(, 

POSS(), 

and is not already seen.
{new routing record POSS(  

Where:   is    address of principle R  and   is nonce of principle R.

(c)  

Action label
Action name
Description
Condition
Result

ACT₂₁
Comp(A, B)
This action is used to compare two values if they are equal or not.
A, B ∈ POSS(.
If A and B are equal: Proof (),  

means message X is checked and not modified  

If they are not equal: POSS( POSS( means message X is checked and it is modified

ACT₂₂
Renew-key-pair()
This action is used to renew the public and private keys.
—
POSS = (POSS(.

ACT₂₃
Multicast( PL, X)
It means that Principle sends msg X to all principles in the PL.
—
Principle sends message X to all principles in the PL.

ACT₂₄
Modify()
This action modifies certificate content.
—
Modify the certificate content.

ACT₂₅
Monitor

(, abnormal behavior)
It means that principle monitors the abnormal behavior of other principals.
—
Principal detects abnormal behaviors of other principal AbnBeh().

ACT₂₆
Generate-Alert()
generates an alert at time because it detects abnormal behavior of .
A bnBeh .
Alert()

ACT₂₇
Alert-Filtering (Alert())
This action is used to do the process of categorizing attack alerts produced from principals in order to distinguish false positive from actual attack.
Alert( POSS(, 

where   is any Principle , 

but not or .
If true positive takes an action.

ACT₂₈
Access (Resource)
This action is used to allow or deny the access of resources.
AccessInfo FireWall, Condition = Allow
Allow resource access.

ACT₂₉

This action is used to rename value to .
POSS()
X ∈ POSS(, Use X instead of Y.

ACT₃₀
Process (Pra, Fun)
This action is used in key agreement process. Process parameters received from .
Fun ∈ POSS(), parameters received from .
Key ∈ POSS()

Different inference rules are defined in Tables 4(a)–4(d). is the rule label where is the rule number. As the rule conditions are executed correctly, the sets’ values will be changed or the protocol will be aborted. Rules defined for specific protocols in [3–6] had been extracted, generalized, and mapped to LBSA. New rules were also generated by LBSA to complete the security architecture.

Table 4: (a) Rules (RL₁–RL₆) of LBSA, (b) rules (RL₇–RL₁₁) of LBSA, (c) rules (RL₁₂–RL₁₆) of LBSA, and (d) rules (RL₁₇–RL₁₉) of LBSA.

(a)  

Rule label
Rule
Description

RL₁
Nonce verification rule: 
Principle can decide that principle believes that X is fresh if P's Belief set contains and X from is in the P's possession set.

RL₂
Message meaning rule: 
P can believe that possesses if it receives from and both P and Q know the key .

from  POSS, 

RL₃
Sub-message freshness rule: 

BEL, 
P can believe that is fresh if it believes that is fresh and have and in the same formula and this formula is in P's Possession set. That is, the part of the message that contains something fresh is fresh.

RL₄
Linkage rule (symmetric keys): 
This rule is applied only once for the same nonce since the LINK item will be removed after applying it successfully. can believe that a submessage of a message X is fresh when several conditions are applied. The first one is when P's Belief set contains LINK (Na) which means the nonce Na has not been used before. Also, the message X that contains the nonce must be encrypted using the key k and k must be fresh and available to P; this is what other conditions state.

#(k) BEL Observers, 

LINK(Na) BEL, contains ,

RL₅
Linkage rules (asymmetric keys):
This rule is applied only once for the same nonce since the LINK item will be removed after applying it successfully. can believe that a submessage of a message X is fresh when several conditions are applied. The first one is when P's Belief set contains LINK (Na) which means the nonce Na has not been used before. Also, the message X that contains the nonce must be encrypted using the public key and the corresponding inverse (private) key must be fresh and available to P; this is what other conditions state.

(a) BEL(), Observers,

LINK(Na) BEL, contains , 

(b) BEL(), Observers, 

LINK(Na) BEL(), contains , 

RL₆
Possible origins rule: 
When P's possession set contains message X which contains submessage and this submessage observed by more than one principal, other than P, it will be marked as coming from all principals by adding new item for each of the P's Possession set.

POSS(), contains , 

(b)  

Rule label
Rule
Description

RL₇
Submessage origin rule: 
A submessage can be marked as coming from Q if P possesses a message X which contains and encrypted using an asymmetric key, and submessage is marked as coming from . And any other principle who observes the inverse key, the submessage is marked as coming from it.

POSS(P), contains from Q, 

RL₈
Submessage origin rule for asymmetric keys:
This rule is simplified version of the submessage origin rule. In (a) If P's Possession set contains message which is encrypted using P's public key. And contains a submessage which is marked as coming from . Then all other submessages in are marked as coming from . This is true because is the only principle that has the corresponding private key so no one can change the content of . In (b) since is the constructor of the message , any submessage of can be marked as coming from . This is true because is the only principle that has Q's private key.

(a) POSS, 

(b) Submessage origin rule for private keys: 

RL₉
Unbound key rule: 
When key is in P's Possession set and this key is not bounded to any principal then all principals () observe it. That is, the key is not a secret.

RL₁₀
Bound key origin rule for symmetric keys: 
The protocol abort when P's Possession set contains the key which is bound to principle , and but this binding is not in P's bindings set which contains legal bindings for .

POSS,  

RL₁₁
Bound key origin rules for asymmetric keys: 
If principle has the binding of an asymmetric key to principle in its possession and binding sets and P's possession set contains a message that is encrypted under the inverse key this means that the message comes from because it is the only principle that have the inverse key. Otherwise, the protocol aborts.

(a) ( POSS, Bindings(P) 

(b) POSS, Bindings, 

(c)  

Rule label
Rule
Description

RL₁₂
Conjunction rule:  
When P's Proof set contains the proof that is accountable for the conjunction and , then it will contain the proof that is accountable for and , respectively.

Contrariwise, the second one is used.

(a)

(b)

RL₁₃
Ciphertext understanding rule: 
When P's Proof set contains the prove that Q is accountable for and holds k then it will contain the prove that is accountable for message .

( Proofs, 

RL₁₄
Transfer rule: 
When P's Proof set contains the proof that Trusted Third Party (TTP) is accountable for message , then it will contain the proof that Q holds message X.

RL₁₅
Timestamp rule (symmetric keys): 
Timestamp rule defined to reason about the message.

BEL, POSS, 

BEL(), contains , 

RL₁₆
Timestamp rule (asymmetric keys): 
Timestamp rule defined to reason about the message.

BEL, POSS), 

BEL contains , 

(d)  

Rule Label
Rule
Description

RL₁₇
Authentication Rule: 
This rule adds a new binding to the binding set. Note that its condition will not complete until the comparison action (ACT₂₁) is executed successfully.

could be any principle except or TTP.

() from POSS, 

BEL,

RL₁₈
Integrity Rule: 
This rule states that if Proof () which means that   received without any modification (i.e., as it sent from ) then we add   Poss () to the believe set.

RL₁₉
Non-Repudiation Rule: 
This rule states that if we have msg encrypted by   and the corresponding public key   in the Binding (), we can prove that is responsible for sending message .

Poss, 

Section 5 provides mapping between security requirements and inference rules/actions. It also provides mapping between some protocol services and inference rules/actions.

5. Possible Mapping between Security Requirements and Inference Rules/Actions

To ensure that the required security requirement is achieved by a security protocol, some inference rules must be applied and some actions must be performed. In this section we provide possible mappings between each security requirement and the inference rule that must be applied or the action that must be executed to achieve it. Table 5 summarizes these mappings.

Table 5: Mappings between security requirements and Inference rules/actions.

Security Requirement
Inference Rules/Actions

Authentication
RL₂, RL₆, RL₇, RL₈, RL₁₃, RL₁₇

Authorization
ACT₂₈

Confidentiality
ACT₃, ACT₄, ACT₁₅

Integrity

Non-Repudiation
RL₂, RL₆, RL₇, RL₈, RL₁₃, RL₁₉

Privacy
ACT₃, ACT₁₅

Availability
ACT₁₃, ACT₂₅, ACT₂₆, ACT₂₇, ACT₂₈

Actions and rules are needed to complete the specification and the analysis processes. In other words, actions and rules add new values to the global and local sets which may result in achieving the mapped rules conditions.

Other actions and rules are needed to perform certain protocol services, including key management which deals with key and certificate generations, verification, and renewing. Certain services are related to nodes’ interaction and protocol functions. Data item refreshments such as messages, keys, certificates, and nonces are among the data that need to be kept fresh.

Table 6 summarizes the mappings between protocol services and the inference rule that must be applied or the action that must be executed to achieve it.

Table 6: Mappings between protocol services and inference rules/actions.

Protocol Services
Inference rules/actions

Key management
ACT₆, ACT₁₁, ACT₁₄, ACT₁₆, ACT₁₉, ACT₂₂, ACT₂₄, ACT₃₀,

RL₄, RL₅, RL₉, RL₁₀, RL₁₁

Nodes interaction and protocol functions
ACT₁, ACT₂, ACT₇, ACT₈, ACT₉, ACT₁₂, ACT₁₇, ACT₁₈, ACT₂₀, ACT₂₁, ACT₂₃, ACT₂₉,

RL₁₂, RL₁₄

Data refreshment
ACT₅, ACT₁₀,

RL₁, RL₃, RL₄, RL₅, RL₁₅, RL₁₆

The following section presents how the above-presented architecture will be used to formally analyze security enforcers and security protocols.

6. Security Enforcers Specification and Analysis

Different security enforcers are used as part of different protocols to achieve security such as in [15–18]. In this section we have chosen well-known enforcers that can be provided at different network layers to illustrate how LBSA could be used to specify and analyze the security enforcers that could be used by many different security protocols. These enforcers are message authentication code (MAC) and digital certificate which also includes digital signature. The reason for using these enforcers is that they are the most used enforcers, in many protocols including routing protocols, to achieve authentication and integrity (MAC) and authentication, integrity and nonrepudiation (digital certificate) [19–25]. The following sections show how these enforcers could be verified using LBSA.

6.1. Message Authentication Code (MAC)

MAC [26] achieves two security requirements, namely, authentication and integrity. In MAC the sender and the receiver of the message must agree on a shared key before initiating the communication. The sender of the message uses the shared key and the message as an input to a hash function to generate the message digest. Then, the sender sends the message and the digest to the receiver. The receiver checks the originality of the message and its correctness by applying the hash function on the received message and the shared key. After that, the receiver compares the resulted digest with the received message digest. If the two digests are equal, this will prove the authenticity of the message as the shared key is only known by sender and receiver. Moreover, it ensures that the message is not modified during the transmission since any simple modification will produce a different digest. To mathematically prove that MAC achieves both authentication and integrity using LBSA the following steps must be performed.

(i) Define the Values of the Global Sets. The first step in the protocol specification is to define the values of the global sets:

 (GS1) Alice, Bob} // Alice is assumed to be the initiator of the protocol.  (GS2) {contains the rules defined in the Tables 4(a)–4(d)} (GS3) //   is the shared key between Alice and Bob  (GS4) Observers () , Bob}.

(ii) Define the Initial Values of the Local Sets. The second step is to define the initial values of the local sets to each principal. Note that some of the global and the local sets values will be changed during the protocol analysis.

Principal A (Alice):

 (LS1) POSS(A) = {Msg, , from B} (LS2) BEL(A) =  (LS6) BL =

 (ACT₇) Concat (ACT₁₂) Apply // Apply hash function to the concatenation  (ACT₇) Concat // prepare the message and digest  (ACT₁) Send // send message and digest to B.

Principal B (Bob):

 (LS1) POSS(B) =  (LS2) BEL(B) =  (LS6) BL =

 (ACT₂) Receive (ACT₈) Split (ACT₇) Concat // concatenate the received message with the key  (ACT₁₂) Apply (ACT₂₁) Comp // compare the calculated digest with the received one.

(iii) MAC Analysis. The last step is to analyze the security enforcer which is MAC in this case to check security requirements it achieves.

Alice is assumed to be the initiator of the protocol. Therefore, four actions in the BL(A) are executed which add new values to the POSS(A) set:

So far no inference rules can be applied. Now, actions in BL(B) are executed and this will produce new values that are added to POSS(B) and the Proof(B) sets. Consequently, both integrity and authentication inference rules can be applied:

Since , we can apply the authentication rule () and the integrity rule () as follows.

Authentication Rule (RL17):

By applying the authentication rule, we proved that MAC successfully authenticated the sender. Since the result of comparison ends successfully, the binding of the shared key and the identity of sender (Alice in this scenario) will be added to the binding set of Bob which ensures the authenticity of the received message.

Integrity Rule (RL18):

The equality of the two digests also proves the correctness of the received message which leads Bob to adding a new value to Bob’s Belief set indicating that the received message is the same as the message sent by Alice.

As can be concluded, LBSA has been used to mathematically prove the achievement of authentication and integrity by MAC. The above process is also applicable to any other security enforcer.

6.2. Digital Certificate

In hierarchical trust model, digital certificate [14] is usually issued by a certification authority (CA). It contains the user identity, public key (), CA’s digital signature, and other information. Using the CA’s digital signature, the user can proof the authenticity of the issuer and ensure correct binding between the identity and the public key in the certificate.

We assume that the CA is the initiator of the protocol which will make one certificate for Alice and another for Bob. It sends each certificate after attaching its signature. Bob needs Alice’s public key to send messages to her securely, therefore Alice sends her certificate to Bob then Bob starts the signature verification to ensure correct binding between Alice’s public key and her identity.

Using LBSA to prove the achieved security requirements using the digital certificate, we start by presenting the enforcer specification in terms of global and local sets and then we performed the analysis part.

(i) Define the Values of the Global Sets.  Consider

 (GS1)  (GS2) contains the rules defined in Tables 4(a)–4(d)} (GS3)  (GS4) Observers () =  (GS4) Observers () =  (GS4) Observers () = .

(ii) Define the Initial Values of the Local Sets to each Principal

Principal (CA):

 (LS1) POSS(CA) =  (LS2) BEL(CA) =  (LS7) Binding(CA) =  (LS6) BL =

 // Generation of Alice’s certificate (ACT₁₂) Apply // digest generation  (ACT₁₅) Apply-asymkey, ) // generation of CA’s digital signature  (ACT₇) Concat,  (ACT₁) Send // Generation of Bob’s certificate (ACT₁₂) Apply (ACT₁₅) Apply-asymkey(certB), )  (ACT₇) Concat(certB,  (ACT₁) SendBob, .

Principal (A) (Alice):

 (LS1) POSSA (LS2) BELA (LS7) Binding (LS6) BL =

 (ACT₂) Receive (CA,  (ACT₁) Send (Bob, )—A(1).

Principal ( ) (Bob):

 (LS1) POSS(B)  (LS2) BEL(B)  (LS7) Binding(B)  (LS6) BL =

 (ACT₂) Receive.) // Bob receives its certificate from the CA  (ACT₂) Receive(Alice, . // Bob receives Alice’s certificate from the Alice—B(1) (ACT₈) Split—B(2) (ACT₂₁) Comp, Apply-asymkey // Bob compares the calculated digest and the digest resulted from the decryption of the digital signature—B(3).

(iii) Digital Certificate Analysis. CA is assumed to be the initiator of the protocol and the first four actions in the BL(CA) are executed which will add new values to the POSS(CA) as follows:

 POSS(CA) , , , certA..

The next action to be executed is the first action in BL(A) which will receive the msg and update the POSS(A) to include the msg content:

 POSS(A) = , . Then CA does the rest of the actions which followed by executing the first action in BL(B) and these actions update the POSS(CA) again and the POSS(B).  POSS(CA) = , , (), , , (certB), , .  POSS(B) = .

Now Alice sends her certificate to Bob which is the action A(1) in the BL(A) and the next actions to be executed are B(1)-B(2) which update the POSS(B):

 POSS(B) = , , , certA, .

Since we can apply Submessage origin rule (RL7):

Which adding a new value to the POSS(B):

 , , certA, , () from CA}.

Finally, executing the action B(3) will add new values to POSS(B) (assuming the comparison action ensures equality) which achieves some rules conditions and these rules can be applied:

 POSS(B) = , , certB. , ., , ( A) from CA, , , .

Since () from CA POSS(B), POSS(B) we can apply authentication and integrity rules as follows.

Authentication Rule (RL17):

Integrity Rule (RL18):

Nonrepudiation Rule (RL19):

Consequently, applying Authentication Rule (RL17) ensures the authenticity of Alice’s public key. Integrity Rule (RL18) confirms the correctness of Alice’s certificate. Finally, Nonrepudiation Rule (RL19) proves the originality of Alice’s certificate, in other words it proves that Alice’s certificate was issued and signed by the CA.

The purpose of LBSA is to generalize the rules, but the way they are applied depends on the enforcer itself. As shown this section, Rules 17 and 18 are used by both MAC and digital certificates but in different meanings. The authentication rule in MAC ensures the authenticity of the received message, whereas in digital certificate it ensures the authenticity of the public key. The integrity rule is used in MAC to ensure the correctness of the received message whereas in digital certificate it used to ensure the correctness of the certificate’s contents.

7. Case Study: Ariadne Protocol

Many secure routing protocols have been proposed in the literature [27–32]. In this section, Ariadne protocol [27], which is a secure, on-demand routing protocol for multihop wireless networks was chosen to illustrate how to use LBSA to specify and analyze secure protocols. Ariadne is based on Timed Efficient Stream Loss-tolerant Authentication (TESLA) [33] which is an efficient broadcast authentication scheme that requires time synchronization. TESLA is commonly used in wireless sensor networks due to its low communication and computation overhead.

Before we start the security verification of Ariadne, we will present an overview of Ariadne route discovery using TESLA. For simplicity, we will use four nodes but what is applied in case of four nodes can be applied to more nodes. In all cases we will have a source, a destination, and a set of intermediate nodes which their number can vary depending on the chosen route. In the case of using more nodes, the change will be in the length of the chain of nodes. The way the authentication and integrity are achieved is defined by the Ariadne protocol itself. In this case study, we mapped Ariadne to LBSA to check Ariadne security correctness.

The source node S begins route instantiation to destination D by broadcasting a route request packet. A and B are intermediate nodes, that is, S → A → B → D. A route reply packet is unicasted by the destination D as a reply to the request packet along the reverse path to the source.

In the route discovery process there are two types of messages REQUEST and REPLY. REQUEST and REPLY messages include the following fields.

Route REQUEST packet in Ariadne contains eight fields: REQUEST (define the type of the message), initiator address, target address, id (uniquely identifies the request), time interval, hash chain, node list, and MAC list. Note that the last three fields are updated by each intermediate node receiving that request.

Table 7 shows the protocol parameters.

Table 7: Ariadne protocol parameters.

Parameter name
Meaning

Initiator (source) node.

Target (destination) node.

,
shared secret keys between and for message authentication in each direction.

Time interval.

Id
Message identifier.

TESTLA key () used by principal (), is the index for the time interval specified in the request.

TESTLA key () used by principal (), is the index for the time interval specified in the request.

The following steps illustrate how Ariadne route discovery using TESLA works:

 : (REQUEST, S, D, id, ti)  broadcast: (REQUEST, S, D, id, ti, , ( ), ( )) : = (A, )  (REQUEST, , , id, ti, , (), ( ))  broadcast: (REQUEST, , , id, ti, , (), ()) : h2= H(B, 1)  (REQUEST, , , id, ti, , (), ())  broadcast: (REQUEST, , , id, ti, , (), (, )) : (REPLY, , , ti, (), (, ))  : (REPLY, , , ti, (), (, ), , ( ))  : (REPLY, , , ti, (), (, ), , ())  : (REPLY, , , ti, (), (), , ().

In the Ariadne protocol, the initiator of the REQUEST initializes the hash chain () to (initiator, target, id, time interval) and the node list and MAC list to empty lists.

When any node receives a route REQUEST for which it is not the target, the node checks its local table of (initiator, id) values from recent REQUESTs it has received to determine if it has already seen a REQUEST from this same Route Discovery. If it has, the node discards the packet. The node also checks whether the time interval in the REQUEST is valid. Then, the node modifies the REQUEST by appending its own address, , to the node list in the REQUEST, replacing the hash chain field with (, hash chain), and appending a MAC of the entire REQUEST to the MAC list. The node uses the TESLA key to compute the MAC, where is the index for the time interval specified in the REQUEST. Then, the node rebroadcast the modified REQUEST.

If the target node (destination) determines that the REQUEST is valid, it returns a route REPLY to the initiator, containing eight fields: REPLY (define the type of the message), target address (which is the initiator address in the REQUEST message), initiator address (which is the target address in the REQUEST message), time interval (the same as in the REQUEST message), node list, MAC list, target MAC, and key list. The target MAC is set to a MAC computed on the preceding fields in the REPLY with the key , and the key list is initialized to the empty list. The route REPLY is then returned to the initiator of the REQUEST along the source route obtained by reversing the sequence of hops in the node list of the REQUEST.

7.1. Ariadne Specification

First we will present the assumptions of Ariadne protocol which are as follows.

(i)The source and destination share the MAC keys and . (ii)Every node has a TESLA one-way key chain.(iii)All nodes know the authentication key of TESLA one-way key chain of each other node.

(i) Define the Values of the Global Sets. Consider

 (GS1)  (GS2) contains the rules defined in Tables 4(a)–4(d)} (GS3)  (GS4) Observers (GS4) Observers  (GS4) Observers  (GS4) Observers .

(ii) Define the Initial Values of the Local Sets for each Principal

Principal ( ):

 (LS1) POSS, from , from , () from A, from  (LS2) BEL, , , ,  (LS6) BL =

 (ACT₇) Concat ({REQUEST, , , id, ti}, )—S(1) (ACT₁₂, ACT₂₉) ApplyREQUEST, , id, ti}. )—S(2)  (ACT₁₈) Broadcast ({REQUEST, , id, ti, , (), () })—S(3) (ACT₂) Receive (, {REPLY, , ti, , (), , —S(4) (ACT₇) Concat({REPLY, , id, ti, (), (, )}, )—S(5) (ACT₁₂, ACT₂₉) Apply, {REPLY, , id, ti, (), —S(6) (ACT₂₁) Comp—S(7)  (ACT₇) Concat REQUEST, , id, ti, , (), —S(8) (ACT₁₂, ACT₂₉) Apply,{REQUEST, , id, ti, , (), —S(9) (ACT₂₁) Comp)—S(10) (ACT₇) ConcatREQUEST, , id, ti, , (), —S(11) (ACT₁₂, ACT₂₉) Apply(, {REQUEST, , id, ti, , (), —S(12) (ACT₂₁) Comp—S(13).

Principal (A):

 (LS1) POSS (LS2) BEL (LS7) Binding (LS6) BL =

 (ACT₂) Receive({REQUEST, , id, ti, , —A(1) (ACT₂₀) Check-request(, id)—A(2) (ACT₁₀) Check-freshness(ti)—A(3)  (ACT₇) Concat(A, )—A(4) (ACT₁₂, ACT₂₉) Apply—A(5) (ACT₇) ConcatREQUEST, , id, ti, , , —A(6) (ACT₁₂, ACT₂₉) Apply, {REQUEST, , id, ti, , (), —A(7) (ACT₁₈) BroadcastREQUEST, , id, ti, , (—A(8) (ACT₂) Receive(B,{REPLY, , ti, , , —A(9)  (ACT₁) Send(S, {REPLY, , ti, (), —A(10).

Principal ( ):

 (LS1) POSS (LS2) BEL (LS7) Binding (LS6) BL =

 (ACT₂) Receive({REQUEST, , id, ti, , (), — B(1) (ACT₂₀) Check-request(, id)— B(2) (ACT₁₀) Check-freshness(ti)— B(3) (ACT₇) Concat()— B(4) (ACT₁₂, ACT₂₉) Apply()— B(5) (ACT₇) Concat({REQUEST, , id, ti, , (—B(6) (ACT₁₂, ACT₂₉) Apply REQUEST, , id, ti, , (), —B(7)  (ACT₁₈) BroadcastREQUEST, , id, ti, , (), —B(8) (ACT₂) ReceiveREPLY, , ti, (), (), , —B(9) (ACT₁) SendREPLY, , ti, (), — B(10).

Principal (D):

 (LS1) POSS, from , from  (LS2) BEL, , ,  (LS6) BL =

 (ACT₂) ReceiveREQUEST, , id, ti, , (), —D(1) (ACT₂₀) Check-request(, id)—D(2) (ACT₁₀) Check-freshness(ti)—D(3) (ACT₁₂, ACT₂₉) Apply(, Concat(, Apply(, Concat (, Apply(, (ACT₇) ConcatREQUEST, , , id, ti—D(4)  (ACT₂₁) Comp —D(5) (ACT₇) ConcatREPLY, , , id, ti, (), —D(6) (ACT₁₂, ACT₂₉) ApplyREPLY, , , id, ti, , . —D(7)  (ACT₁) Send REPLY, , , ti, —D(8).

7.2. Ariadne Analysis

Node S is the initiator of the protocol and its first three actions will be executed which result in new values to be added to the POSS(S) set:

 POSS(S):= POSS(S) , id, ti, REQUEST, , id, ti.

Now we assume that node receives the request so first eight actions in BL() will be executed and the result is

 POSS() = POSS() , ,  = REQUEST, , id, ti BEL() =.

Now B(1–8) will be executed and the result is

 POSS POSS() , (), (, , {REQUEST, , id, ti, , REQUEST, , id, ti,  BEL BEL.

Now the request reaches its target which is node D and its BL(1–5) actions will be executed and the result will be as follows:

 , (), (, REQUEST, , id, tiREPLAY, , id, ti, ,  D D   Since ∈ Proof() we can apply integrity rule RL(18): Proof/ = BEL Poss()}.

After the execution of D(7) and D(8), the POSS set will be updated as follows

 POSS(D) = POSS(REQUEST, , id, ti, , (), , C1 = H(A. B. {REQUEST, S, D, id, ti, {REPLAY, , id, ti, , REPLAY, , id, ti, (), .

Therefore, the target (destination) node makes sure that the request is from node S and it will send a reply message using the reverse path since the comparison action confirms equality. Each intermediate node (A and B in our example) will receive the reply, adds its key to the key list, and forwards it to the next node until it reaches the source. The destination will authenticate each intermediate node using the same process as the target node did.

When the target node S receives the REPLY the rest of its actions will be executed to ensure the validity of the target’s MAC, and each MAC in the MAC list. Node local sets will be updated as follows:

 POSS = , from , from , {REPLY, , ti, , , , , {REPLY, , id, ti, , ., {REQUEST, , , id, ti, 1, , {REQUEST, , id, ti, ,  Proof Proof, , .

Now we can apply the authentication rule (RL17) for each entry in the proof set.

Authentication Rule (RL17):

Also we can apply the integrity rule (RL18) for each entry in the proof set.

Integrity Rule (RL18):

Since we applied the authentication and the integrity rules successfully on the target’s MAC and on each MAC in the MAC list, it can be concluded that the reply is valid and authenticated; consequently node can accept it. Therefore, Ariadne achieves both the authentication and the integrity requirements which detect attackers when they attempt to impersonate the message’s sender or modify its content.

Flaws in this protocol lie in the assumptions of the authors that may affect the usability of the protocol. Ariadne assumed the presence of a working public key infrastructure (PKI) or certificate authority (CA). Consequently, key management services are assumed to be already existed but are not provided by Ariadne. Also, Ariadne did not take the possibility of having internal attackers into consideration and therefore, no IDS are applied to detect them.

Based on the above assumptions, actions such as ACT₆, ACT₁₁, ACT₁₃, ACT₁₄, ACT₁₆, ACT₁₉, ACT₂₂, ACT₂₄, ACT₂₅, ACT₂₆, ACT₂₇, and ACT₂₈ cannot be activated and rules like R4, R5, R9, R10, and R11 cannot be applied. Based on this observation, LBSA can detect the absence of key management system and IDS in Ariadne. As a result, key management services will fail and intruders cannot be detected.

8. Conclusions and Future Work

The success of applications over multihop communication networks principally depends on the achievement of security requirements. Many secure protocols are proposed, consequently, there should be a reliable way to test if these protocols satisfy the security requirements as their designers claim.

Previous attempts to utilize logic in analyzing security have either focused on a specific requirement or a specific protocol. In this paper, we proposed a logic-based security architecture (LBSA) to specify and analyze any security requirement in any system providing multihop communication using logic. Any system or protocol claiming security can be mapped into our architecture in other words it must be specified using various global/local sets and actions, then it can be analyzed by applying different rules. LBSA provides a formal way to analyze security enforcers and security protocols instead of depending only on the simulation tools which are arguable by many researchers in terms of implementation accuracy.

Additionally, using simulation tools usually covers a small set of scenarios whereas using LBSA more cases can be covered that usually cannot be covered exhaustively by simulation tools.

This paper also illustrated how LBSA can be used to verify security enforcers by applying it to two well-known enforcers which are MAC and digital certificate. In addition to that, a case study for a secure routing protocol used in ad hoc and sensor networks named Ariadne was also evaluated in terms of security using LBSA.

To the best of our knowledge, the proposed security architecture covers the most important enforcers. Further development of new enforcers in the future may simply need other sets, actions, and rules to be added. Also, LBSA could be extended by considering new rules and actions for the Interaction between Intrusion Detection System (IDS) and Intrusion Prevention System (IPS). Moreover, LBSA can utilize the computational Intelligence tools in analyzing the security.

References

ITU-T Recommendation X. 800, “Security architecture for Open Systems Interconnection for CCITT applications,” 1991

ITU-T Recommendation X. 805, “Security architecture for systems providing end-to-end communication,” 2003

A. D. Rubin and P. Honeyman, “Nonmonotonic cryptographic protocols,” in Proceedings Computer Security Foundations Workshop, pp. 100–116, June 1994.

A. D. Rubin, “Extending NCP for protocols using public keys,” Mobile Networks and Applications, vol. 2, no. 3, pp. 227–241, 1997.

Y. Xu and X. Xie, “Security analysis of routing protocol for MANET based on extended Rubin logic,” in Proceedings of the IEEE International Conference on Networking, Sensing and Control (ICNSC '08), pp. 1326–1331, Sanya, China, April 2008.

Y. Xu and X. Xie, “Extending rubin logic for electronic commerce protocols,” in Proceedings of the 2nd International Conference on Anti-counterfeiting, Security and Identification (ASID '08), pp. 448–451, Guiyang, China, August 2008.

Y. Xu and X. Xie, “Analysis of electronic commerce protocols based on extended rubin logic,” in Proceedings of the 9th International Conference for Young Computer Scientists (ICYCS '08), pp. 2079–2084, Hunan, China, November 2008.

Y. Xu and X. Xie, “Analysis of authentication protocols based on rubin logic,” in Proceedings of the International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM '08), Dalian, China, October 2008.

A. D. Rubin and P. Honeyman, “Long running jobs in an authenticated environment,” in Proceedings of the USENIX Security Conference IV, pp. 19–28, October 1993.

R. M. Needham and M. D. Schroeder, “Using encryption for authentication in large networks of computers,” Communications of the ACM, vol. 21, no. 12, pp. 993–999, 1978.

K. Sanzgiri, D. LaFlamme, B. Dahill, B. N. Levine, C. Shields, and E. M. Belding-Royer, “Authenticated routing for ad hoc networks,” IEEE Journal on Selected Areas in Communications, vol. 23, no. 3, pp. 598–610, 2005.

J. Zhou and D. Gollmann, “Fair non-repudiation protocol,” in Proceedings of the 17th IEEE Symposium on Security and Privacy, pp. 55–61, Oakland, Calif, USA, May 1996.

M. Satyanarayanan, “Integrating security in a large distributed system,” ACM Transactions on Computer Systems, vol. 7, no. 3, pp. 247–280, 1989.

ITU-T Recommendation X. 509, “Information technology—Open System Interconnection—The Directory: public-key and attribute certificate framework,” 2008

J. Weiss, “Message digest, message authentication codes and digital signature,” in Jave Cryptography Extensions, pp. 101–118, 2004.

J. Zhou and K. Y. Lam, “Securing digital signatures for non-repudiation,” Computer Communications, vol. 22, no. 8, pp. 710–716, 1999.

Z. Shao, “Certificate-based fair exchange protocol of signatures from pairings,” Computer Networks, vol. 52, no. 16, pp. 3075–3084, 2008.

C. H. Lima and P. J. Lee, “Korean certificate-based digital signature algorithm,” Computers and Electrical Engineering, vol. 25, no. 4, pp. 249–265, 1999.

S. Madria and J. Yin, “SeRWA: a secure routing protocol against wormhole attacks in sensor networks,” Ad Hoc Networks, vol. 7, no. 6, pp. 1051–1063, 2009.

S. Ozdemir and H. Çam, “Integration of false data detection with data aggregation and confidential transmission in wireless sensor networks,” IEEE/ACM Transactions on Networking, vol. 18, no. 3, pp. 736–749, 2010.

E. Stavrou and A. Pitsillides, “A survey on secure multipath routing protocols in WSNs,” Computer Networks, vol. 54, no. 13, pp. 2215–2238, 2010.

O. Delgado-Mohatar, A. Fúster-Sabater, and J. M. Sierra, “A light-weight authentication scheme for wireless sensor networks,” Ad Hoc Networks, vol. 9, no. 5, pp. 727–735, 2011.

I. Almomani and M. Saadeh, “Security model for tree-based routing in wireless sensor networks: structure and evaluation,” KSII Transactions on Internet and Information Systems, vol. 6, no. 4, pp. 1223–1247, 2012.

K. Bicakci, I. E. Bagci, and B. Tavli, “Communication/computation tradeoffs for prolonging network lifetime in wireless sensor networks: the case of digital signatures,” Information Sciences, vol. 188, pp. 44–63, 2012.

X. Fan and G. Gong, “Accelerating signature-based broadcast authentication for wireless sensor networks,” Ad Hoc Networks, vol. 10, no. 4, pp. 723–736, 2012.

ISO/IEC 9797-2, “Information technology-security techniques-Message Authentication Code (MACs)—Part 2: mechanisms using a dedicated hash function”.

Y. C. Hu, A. Perrig, and D. B. Johnson, “Ariadne: a secure on-demand routing protocol for ad hoc networks,” Wireless Networks, vol. 11, no. 1-2, pp. 21–38, 2005.

R. Mavropodi, P. Kotzanikolaou, and C. Douligeris, “SecMR—a secure multipath routing protocol for ad hoc networks,” Ad Hoc Networks, vol. 5, no. 1, pp. 87–99, 2007.

J. Kim and G. Tsudik, “SRDP: secure route discovery for dynamic source routing in MANETs,” Ad Hoc Networks, vol. 7, no. 6, pp. 1097–1109, 2009.

S. Gupte and M. Singhal, “Secure routing in mobile wireless ad hoc networks,” Ad Hoc Networks, vol. 1, no. 1, pp. 151–174, 2003.

K. K. Chauhan, A. K. S. Sanger, and V. S. Kushwah, “Securing on-demand source routing in MANETs,” in Proceedings of the 2nd International Conference on Computer and Network Technology (ICCNT '10), pp. 294–297, Bangkok, Thailand, April 2010.

S. G. Yoo, K. Y. Park, and J. Kim, “A security-performance-balanced user authentication scheme for wireless sensor networks,” International Journal of Distributed Sensor Networks, vol. 2012, Article ID 382810, 11 pages, 2012.

A. Perrig, R. Canetti, J. D. Tygar, and D. Song, “The TESLA broadcast authentication protocol,” CryptoBytes, RSA Laboratories, vol. 5, no.2, 2002