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.
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 [
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
Security architecture as defined by ITU-T Recommendations X.800 [
Security Architecture extracted from ITU-T Recommendations X.800 and X.805.
Security architecture as shown in Figure
The requirements and their definitions are illustrated as the following.
These requirements must be achieved to guarantee secure communication and to prevent and detect different attackers which can be classified into the following.
Several mechanisms and techniques have been defined to achieve different security requirements. Table
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.
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 [
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 [
Rubin and Honeyman [
Rubin [
Xu and Xie presented in a series of papers [
In [
Xu and Xie [
Two examples of Rubin logic’s applications are given by Xu and Xie in [
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 [
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
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
Table
Global and local sets of LBSA.
Set label | Set name | Description |
---|---|---|
GS1 | Principal set | All principals (i.e., nodes) participate in the protocol are in this set. |
GS2 | Rule set | Inference rules needed to derive new statements from existed assertions that are in this set. |
GS3 | 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. |
GS4 | Observers set | For each |
GS5 | 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 |
LS1 | 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( |
LS2 | 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 |
LS3 | Opaque( |
This set contains candidates to be added to the Seen set. It is used by the Update function (Table |
LS4 | Seen( |
This set contains text parts (data) that |
LS5 | Haskeys( |
This set contains keys that |
LS6 | Behavior list( |
This item is a list rather than a set because the elements are ordered. BL |
LS7 | Bindings set( |
This set contains the legal bindings of keys held by a principal. These are bindings that are created by |
LS8 | Proofs set( |
This set contains all the other principals' nonrepudiation that |
LS9 | PL( |
Principals list contains all the principals that must receive Messages (Msgs) from principals |
LS10 | AbnBeh( |
Abnormal behavior set contains all the principals that |
Tables
(a) Actions (ACT1–ACT10) of LBSA, (b) actions (ACT11–ACT20) of LBSA, and (c) actions (ACT21–ACT30) of LBSA.
Action label | Action name | Description | Condition | Result |
---|---|---|---|---|
ACT1 | Send( |
|
— | Principal |
ACT2 | Receive( |
|
— | Principal |
ACT3 | Encrypt( |
If |
|
POSS( |
ACT4 | Decrypt( |
If |
|
POSS( |
ACT5 | Generate-nonce( |
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( |
— | POSS( |
ACT6 | Generate-secret( |
Is used to generate a new secret |
— |
|
ACT7 | Concat( |
Is used to construct a message |
|
POSS( |
ACT8 | Split( |
When a message contains a set of components, this action is used to break it into its components. |
|
POSS( |
ACT9 | Forget( |
When |
|
POSS( |
ACT10 | Check-freshness( |
Is used to verify the freshness of timestamp |
|
BEL( |
Action label | Action name | Description | Condition | Result |
---|---|---|---|---|
|
Forget-secret( |
When |
|
Observers( |
ACT12 | Apply( |
Is used to apply function |
|
POSS( |
ACT13 | Abort | The protocol aborts when different cracks and events that affect the protocol specification happen. | Protocol run is illegal. | Analysis reports failure. |
ACT14 | Generate-key-pair( |
Is used to generate two keys |
— | POSS( |
ACT15 | Apply-Asymkey( |
There are two cases for applying asymmetric key operation on |
|
if |
ACT16 | Bind( |
Before sending a key, principal |
|
POSS( |
ACT17 | Update( |
After sending a message this action is used to maintain the observers set. | — | Maintains the observers of |
ACT18 | Broadcast( |
Message |
— |
|
ACT19 | Check-certificate( |
Is used to verify the freshness of the certificate |
|
BEL |
ACT20 | 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. |
|
{new routing record |
Action label | Action name | Description | Condition | Result |
---|---|---|---|---|
ACT21 | Comp(A, B) | This action is used to compare two values if they are equal or not. | A, B |
If A and B are equal: |
ACT22 | Renew-key-pair( |
This action is used to renew the public and private keys. | — | POSS = (POSS( |
ACT23 | Multicast( |
It means that Principle |
— | Principle |
ACT24 | Modify( |
This action modifies certificate content. | — | Modify the certificate content. |
ACT25 | Monitor |
It means that principle |
— | Principal |
ACT26 | Generate-Alert( |
|
|
Alert( |
ACT27 | 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( |
If true positive |
ACT28 | Access (Resource) | This action is used to allow or deny the access of resources. | AccessInfo |
Allow resource access. |
ACT29 |
|
This action is used to rename value |
|
|
ACT30 | Process (Pra, Fun) | This action is used in key agreement process. Process parameters received from |
Fun |
Key |
Different inference rules are defined in Tables
(a) Rules (RL1–RL6) of LBSA, (b) rules (RL7–RL11) of LBSA, (c) rules (RL12–RL16) of LBSA, and (d) rules (RL17–RL19) of LBSA.
Rule label | Rule | Description |
---|---|---|
RL1 | Nonce verification rule: | Principle |
|
||
| ||
RL2 | Message meaning rule: |
|
|
||
| ||
| ||
RL3 | Sub-message freshness rule: |
|
| ||
| ||
RL4 | 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. |
#( |
||
LINK( |
||
| ||
| ||
RL5 | 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. |
(a) |
||
LINK( |
||
|
||
(b) |
||
LINK( |
||
| ||
| ||
RL6 | Possible origins rule: | When |
|
||
|
Rule label | Rule | Description |
---|---|---|
RL7 | Submessage origin rule: | A submessage |
|
||
| ||
| ||
RL8 | Submessage origin rule for asymmetric keys: | This rule is simplified version of the |
(a) |
||
|
||
(b) Submessage origin rule for private keys: | ||
| ||
| ||
RL9 | Unbound key rule: | When key |
| ||
| ||
RL10 | Bound key origin rule for symmetric keys: | The protocol abort when |
|
||
| ||
| ||
RL11 | Bound key origin rules for asymmetric keys: | If principle |
(a) ( |
||
|
||
(b) |
||
|
Rule label | Rule | Description |
---|---|---|
RL12 | Conjunction rule: |
When |
(a) |
||
(b) |
||
| ||
RL13 | Ciphertext understanding rule: | When |
( |
||
| ||
| ||
RL14 | Transfer rule: | When |
| ||
| ||
RL15 | Timestamp rule (symmetric keys): | Timestamp rule defined to reason about the message. |
|
||
|
||
| ||
| ||
RL16 | Timestamp rule (asymmetric keys): | Timestamp rule defined to reason about the message. |
|
||
|
||
|
Rule Label | Rule | Description |
---|---|---|
RL17 | Authentication Rule: | This rule adds a new binding to the binding set. Note that its condition will not complete until the comparison action (ACT21) is executed successfully. |
( |
||
|
||
| ||
| ||
RL18 | Integrity Rule: | This rule states that if |
| ||
| ||
RL19 | Non-Repudiation Rule: | This rule states that if we have msg encrypted by |
|
||
|
Section
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
Mappings between security requirements and Inference rules/actions.
Security Requirement | Inference Rules/Actions |
---|---|
Authentication | RL2, RL6, RL7, RL8, RL13, RL17 |
Authorization | ACT28 |
Confidentiality | ACT3, ACT4, ACT15 |
Integrity |
|
Non-Repudiation | RL2, RL6, RL7, RL8, RL13, RL19 |
Privacy | ACT3, ACT15 |
Availability | ACT13, ACT25, ACT26, ACT27, ACT28 |
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
Mappings between protocol services and inference rules/actions.
Protocol Services | Inference rules/actions |
---|---|
Key management | ACT6, ACT11, ACT14, ACT16, ACT19, ACT22, ACT24, ACT30, |
RL4, RL5, RL9, RL10, RL11 | |
Nodes interaction and protocol functions | ACT1, ACT2, ACT7, ACT8, ACT9, ACT12, ACT17, ACT18, ACT20, ACT21, ACT23, ACT29, |
RL12, RL14 | |
Data refreshment | ACT5, ACT10, |
RL1, RL3, RL4, RL5, RL15, RL16 |
The following section presents how the above-presented architecture will be used to formally analyze security enforcers and security protocols.
Different security enforcers are used as part of different protocols to achieve security such as in [
MAC [
(GS1) (GS2) (GS3) (GS4) Observers (
(LS1) POSS(A) = {Msg, (LS2) BEL(A) = (LS6) BL =
(ACT7) Concat (ACT12) Apply (ACT7) Concat (ACT1) Send
(LS1) POSS(B) = (LS2) BEL(B) = (LS6) BL =
(ACT2) Receive (ACT8) Split (ACT7) Concat (ACT12) Apply (ACT21) Comp
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:
Since
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.
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.
In hierarchical trust model, digital 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.
(GS1) (GS2) (GS3) (GS4) Observers ( (GS4) Observers ( (GS4) Observers (
(LS1) POSS(CA) = (LS2) BEL(CA) = (LS7) Binding(CA) = (LS6) BL =
(ACT12) Apply (ACT15) Apply-asymkey (ACT7) Concat (ACT1) Send
(ACT12) Apply (ACT15) Apply-asymkey (ACT7) Concat(certB, (ACT1) Send
(LS1) POSS (LS2) BEL (LS7) Binding (LS6) BL =
(ACT2) Receive (CA, (ACT1) Send (Bob,
(LS1) POSS(B) (LS2) BEL(B) (LS7) Binding(B) (LS6) BL =
(ACT2) Receive (ACT2) Receive(Alice, (ACT8) Split (ACT21) Comp
POSS(CA)
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) = POSS(CA) = 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) =
Since
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: POSS(B) =
Since (
Consequently, applying Authentication Rule (
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.
Many secure routing protocols have been proposed in the literature [
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
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
Ariadne protocol parameters.
Parameter name | Meaning |
---|---|
|
Initiator (source) node. |
|
Target (destination) node. |
|
shared secret keys between |
|
Time interval. |
Id | Message identifier. |
|
TESTLA key ( |
|
TESTLA key ( |
The following steps illustrate how Ariadne route discovery using TESLA works:
In the Ariadne protocol, the initiator of the REQUEST initializes the hash chain (
When any node
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
First we will present the assumptions of Ariadne protocol which are as follows. The source Every node has a TESLA one-way key chain. All nodes know the authentication key of TESLA one-way key chain of each other node.
(GS1) (GS2) (GS3) (GS4) Observers (GS4) Observers (GS4) Observers (GS4) Observers
(LS1) POSS (LS2) BEL (LS6) BL =
(ACT7) Concat ({REQUEST, (ACT12, ACT29) (ACT18) Broadcast ({REQUEST, (ACT2) Receive ( (ACT7) Concat({REPLY, (ACT12, ACT29) (ACT21) Comp (ACT7) Concat (ACT12, ACT29) (ACT21) Comp (ACT7) Concat (ACT12, ACT29) (ACT21) Comp
(LS1) POSS (LS2) BEL (LS7) Binding (LS6) BL =
(ACT2) Receive({REQUEST, (ACT20) Check-request( (ACT10) Check-freshness(ti)—A(3) (ACT7) Concat(A, (ACT12, ACT29) (ACT7) Concat (ACT12, ACT29) (ACT18) Broadcast (ACT2) Receive( (ACT1) Send(S, {REPLY,
(LS1) POSS (LS2) BEL (LS7) Binding (LS6) BL =
(ACT2) Receive({REQUEST, (ACT20) Check-request( (ACT10) Check-freshness(ti)— B(3) (ACT7) Concat( (ACT12, ACT29) (ACT7) Concat({REQUEST, (ACT12, ACT29) (ACT18) Broadcast (ACT2) Receive (ACT1) Send
(LS1) POSS (LS2) BEL (LS6) BL =
(ACT2) Receive (ACT20) Check-request( (ACT10) Check-freshness(ti)—D(3) (ACT12, ACT29) (ACT21) Comp (ACT7) Concat (ACT12, ACT29) (ACT1) Send
Node POSS(
Now we assume that node POSS( BEL(
Now B(1–8) will be executed and the result is POSS BEL
Now the request reaches its target which is node Since
After the execution of D(7) and D(8), the POSS set will be updated as follows POSS(
Therefore, the target (destination) node makes sure that the request is from node
When the target node POSS Proof
Now we can apply the authentication rule (RL17) for each entry in the proof set.
Also we can apply the integrity rule (RL18) for each entry in the proof set.
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
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.
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.