Logic-Based Security Architecture for Systems Providing Multihop Communication

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.


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 de�ned 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 de�ned 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][4][5][6][7][8], but logic was used to specify and analyze speci�c protocols by de�ning global and local sets, actions, and inference rules. In this paper security architecture is taken as a whole, different actions, sets, and rules which �t 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. is mapping shows the inference rules/actions 2 International Journal of Distributed Sensor Networks 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 speci�ed by their designers. is 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. e 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 speci�cation and analysis of message authentication code (MAC) and digital certi�cate 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.

Security Architecture
Security architecture as de�ned by ITU-T Recommendations X.800 [1] and X.805 [2] de�nes a set of security requirements that must be achieved. Figure 1 illustrates this architecture.
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.
e requirements and their de�nitions 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) �on�dentiality: ensure the secrecy of data. Secret data must be read only by intended recipients.
(iv) Integrity: protect the received data from any kind of modi�cations 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.
ese requirements must be achieved to guarantee secure communication and to prevent and detect different attackers which can be classi�ed into the following.
(i) Internal or external attackers: internal attackers are compromised users who are authorized to enter the system but they are misbehaving. is 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 modi�cations.
(iii) Intentional or accidental: intentional attack is a planned attack while accidental attacking results from system malfunctions such as soware bugs.
Several mechanisms and techniques have been de�ned to achieve different security requirements. Table 1 gives examples of different security enforces that are used to implement the objectives of different security requirements.
Secure protocols usually use the above enforces, among others, to achieve the security requirements. ere 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.

Related Work
e 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 speci�es and analyzes nonmonotonic cryptographic protocols. It is one of the �rst 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 speci�cation and analysis, Rubin logic de�nes global and local sets, actions and inference rules. Rubin and Honeyman [3] focused on authentication protocols. ey took KHAT protocol [9] as an example to discover its �aws. 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. e authors gave special attention to ensure the freshness of data using fresh nonce. e 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 de�ned 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 certi�cates and requests which reveals weakness in Needham and Schroeder public key protocol [10].
Xu and Xie presented in a series of papers [5][6][7][8] the utilization of Rubin logic in analyzing the security for speci�c 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). is 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. e 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 speci�c requirement or a speci�c protocol. is 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. Aer that, we illustrate how LBSA will be used to test security requirements and issues in different security enforcers and protocols.

Logic-Based Security Architecture (LBSA) for Systems Providing Multihop Communication
In this section we illustrate the proposed architecture which de�nes a logical way for specifying and analyzing different enforcers and different protocols that achieve any security requirement as de�ned in [2]. Some researchers used logic as mentioned earlier in Section 3. All sets, actions, and rules de�ned in [3][4][5][6][7][8] which �t in our architecture have been included and labeled by the proposed LBSA. Global sets de�ne the speci�cation of the protocol as a whole. Local sets are private to each principal in the speci�cation. Actions are speci�ed 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. is achieves some rules and conditions which are followed by applying inference rules which in turn update another set(s). Figure  2 shows this relation.
Using different actions, the protocol can be speci�ed exactly as it works. While executing these actions, local and global sets will have new values which lead to applying some rules. is is the process of analyzing protocols.
e 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. GS 3 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. { 1 , 2 , … , }.

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

GS 5
FireWall set( ) is set presents the �rewall 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 1 Possession set( )
is set contains all the data relevant to security that this principal knows or possesses. is includes secret encryption keys, public keys, data that must remain secret, and any other information that is not publicly available. POSS( ) = {poss 1 , poss 2 , … , poss }. Note: poss contains two �elds�the actual data and the origin of this data.

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

LS 4
Seen( ) is set contains text parts (data) that sees from messages sent across the network. e Seen sets collectively contain the same information as the observers set.

LS 5
Haskeys( ) is 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 6
Behavior list( ) is item is a list rather than a set because the elements are ordered. BL {AL, bvr 1 , bvr 2 , … , bvr }. AL is an action list as will be de�ned below.

LS 7
Bindings set( ) is set contains the legal bindings of keys held by a principal. ese are bindings that are created by , and bindings that are received in certi�cates from trusted servers. Bindings ( ) { 1 ⋈ 1 , 2 ⋈ 2 , … , ⋈ }. LS 8 Proofs set( ) is set contains all the other principals' nonrepudiation that can prove. LS 9 PL( ) Principals list contains all the principals that must receive Messages (Msgs) from principals . LS 10 AbnBeh( ) Abnormal behavior set contains all the principals that detect their abnormal behaviors. the set number. ese sets contain the protocol information. ere are �ve global sets GS 1 -GS 5 and ten local sets LS 1 -LS 10 . ese sets have initial values and these values are changed whenever actions and rules are executed. Global sets (GS 1 -GS 4 ) were initilly de�ned in [3] for a speci�c protocol called KHAT [9]. ese global sets have been generalized by LBSA and new global sets are also added. Local sets (LS 1 -LS 8 ) were initially de�ned in [3][4][5] for speci�c protocols, but they are generalized and labeled by LBSA which also de�nes new local sets needed to complete the architecture. ACT 6 Generate-secret(s) Is used to generate a new secret s. Note that the Observers set will be updated. - where # that the value is fresh.
) Is used to construct a message X out of submessages ACT 8 Split(X) When a message contains a set of components, this action is used to break it into its components.
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.
then BEL( ) ACT 10 Check-freshness(X) Is used to verify the freshness of timestamp X. ACT 13 Abort e protocol aborts when different cracks and events that affect the protocol speci�cation happen.
Protocol run is illegal.
Analysis reports failure.
ACT 14 Generate-key-pair( + − ) Is used to generate two keys +  15 Apply-Asymkey(X, k) ere are two cases for applying asymmetric key operation on X. e �rst one when X is in the form of { ′ and k and ′ are inverses to each other. e second case when X is encrypted using k.
is an asymmetric key. ACT 17 Update(X) Aer sending a message this action is used to maintain the observers set.
-Maintains the observers of .
ACT 18 Broadcast(X) Message is broadcasted by to each of its neighbors.
broadcasts to each of its neighbors.
ACT 19 Check-certi�cate(cert ) Is used to verify the freshness of the certi�cate cert .
where is the public key speci�ed in cert .
ACT 20   . RL 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 de�ned for speci�c protocols in [3][4][5][6] had been extracted, generalized, and mapped to LBSA. New rules were also generated by LBSA to complete the security architecture.
Section 5 provides mapping between security requirements and inference rules/actions. It also provides mapping between some protocol services and inference rules/actions.

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.
Actions and rules are needed to complete the speci�cation 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 certi�cate generations, veri�cation, and renewing. Certain services are related to nodes' interaction and protocol functions. Data item refreshments such as messages, keys, certi�cates, 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. e following section presents how the above-presented architecture will be used to formally analyze security enforcers and security protocols.

�. Security �nforcers Speci�cation and Analysis
Different security enforcers are used as part of different protocols to achieve security such as in [15][16][17][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. ese enforcers are message authentication code (MAC) and digital certi�cate which also includes digital signature. e 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 certi�cate) [19][20][21][22][23][24][25]. e following sections show how these enforcers could be veri�ed using LBSA.

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. e sender of the message uses the shared key and the message as an input to a hash function to generate the message digest. en, the sender sends the message and the digest to the receiver. e receiver checks the originality of the message and its correctness by applying the hash function on the received message and the shared key. Aer 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 modi�ed during the transmission since any simple modi�cation will produce a different digest. To mathematically prove that MAC achieves both authentication and integrity using LBSA the following steps must be performed. (ii) �e�ne the �nitial �alues of the �ocal �ets. e second step is to de�ne 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.  Linkage rule (symmetric keys): is rule is applied only once for the same nonce since the LINK item will be removed aer applying it successfully. can believe that a submessage 1 of a message X is fresh when several conditions are applied. e �rst 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. Linkage rules (asymmetric keys): is rule is applied only once for the same nonce since the LINK item will be removed aer applying it successfully. can believe that a submessage 1 of a message X is fresh when several conditions are applied. e �rst 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. Possible origins rule: When P's possession set contains message X which contains submessage 1 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. Submessage origin rule for asymmetric keys: is rule is simpli�ed 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 1 which is marked as coming from . en all other submessages in are marked as coming from . is 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 . is is true because is the only principle that has Q's private key. Rule label Rule Description RL 9 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. at is, the key is not a secret. POSS ( ) , ∄ ( ) POSS( ) Observers ( )

RL 10
Bound key origin rule for symmetric keys: e 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 .
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.

RL 12
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.

RL 13
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 .  (iii) MAC Analysis. e 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. erefore, 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 {Msg} * ∈ Proof(B , we can apply the authentication rule ( 17) and the integrity rule ( 18) 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):
e 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. e above process is also applicable to any other security enforcer.
�.�. �igital Certi�cate. In hierarchical trust model, digital certi�cate �14� is usually issued by a certi�cation 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 certi�cate.
We assume that the CA is the initiator of the protocol which will make one certi�cate for Alice and another for Bob. It sends each certi�cate a�er attaching its signature. Bob needs Alice's public key to send messages to her securely, therefore Alice sends her certi�cate to Bob then Bob starts the signature veri�cation to ensure correct binding between Alice's public key and her identity. Using LBSA to prove the achieved security requirements using the digital certi�cate, we start by presenting the enforcer speci�cation in terms of global and local sets and then we performed the analysis part.
we can apply Submessage origin rule (RL7): Which adding a new value to the POSS(B): 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: Since ( + A ⋈ A) from CA ∈ POSS(B), {cert A } * ∈ POSS(B) we can apply authentication and integrity rules as follows.
e 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 certi�cates but in di�erent meanings. e authentication rule in MAC ensures the authenticity of the received message, whereas in digital certi�cate it ensures the authenticity of the public key. e integrity rule is used in MAC to ensure the correctness of the received message whereas in digital certi�cate it used to ensure the correctness of the certi�cate's contents.

Case Study: Ariadne Protocol
Many secure routing protocols have been proposed in the literature [27][28][29][30][31][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 veri�cation 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. e way the authentication and integrity are achieved is de�ned by the Ariadne protocol itself. In this case study, we mapped Ariadne to LBSA to check Ariadne security correctness.
e 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 �elds.
Route REQUEST packet in Ariadne contains eight �elds: REQUEST (de�ne the type of the message), initiator address, target address, id (uniquely identi�es the request), time interval, hash chain, node list, and MAC list. Note that the last three �elds are updated by each intermediate node receiving that request. Table 7 shows the protocol parameters. e following steps illustrate how Ariadne route discovery using TESLA works: In the Ariadne protocol, the initiator of the REQUEST initializes the hash chain (ℎ 0 ) to MAC (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. e node also checks whether the time interval in the REQUEST is valid. en, the node modi�es the REQUEST by appending its own address, , to the node list in the REQUEST, replacing the hash chain �eld with ( , hash chain), and appending a MAC of the entire REQUEST to the MAC list. e node uses the TESLA key ti to compute the MAC, where is the inde� for the time interval speci�ed in the REQUEST. en, the node rebroadcast the modi�ed REQUEST.
If the target node (destination) determines that the REQUEST is valid, it returns a route REPLY to the initiator, containing eight �elds: REPLY (de�ne 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. e target MAC is set to a MAC computed on the preceding �elds in the REPLY with the key , and the key list is initialized to the empty list. e 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.
���� �ria�n� �p�ci�ca�i�n� First we will present the assumptions of Ariadne protocol which are as follows.
(i) e 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 oneway key chain of each other node.

Conclusions and Future Work
e 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 speci�c requirement or a speci�c 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 speci�ed 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. is 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 certi�cate. 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.