1Computer Science Department, King Abdullah II School for Information Technology, The University of Jordan, Amman 11942, Jordan2Computer 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

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.

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.

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.

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.

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.

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.

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.

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.

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.

(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.

(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 () 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.

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.

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, , DDSince ∈ Proof() we can apply integrity rule RL(18): Proof/ = BEL Poss()}.

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.

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 ACT6, ACT11, ACT13, ACT14, ACT16, ACT19, ACT22, ACT24, ACT25, ACT26, ACT27, and ACT28 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.

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.View at Publisher · View at Google Scholar · View at Scopus

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.View at Publisher · View at Google Scholar · View at Scopus

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.View at Publisher · View at Google Scholar · View at Scopus