Secure OLSR is a minimally modified version of OLSR that adds security. The modifications to OLSR do not change its fundamental operation. Because Secure OLSR closely resembles the original most of the model features still apply. This version of OLSR adds two functions sign() and verif() which together form the basis for securing its operation. Section 2.2.3 provides the details on how these two functions provide security to OLSR.
3.6.1 Model. A model of Secure OLSR must provide implementations for sign() and verif(), Equations 2.1 and 2.2 respectively. The implementation forgoes cryptographic operations necessary in a real-world implementation as long as all nodes, including adversaries, are bound to the rules of a trust relationship, T . The trust relationship, T , is defined in Section 3.4.
The ideal implementation of sign() maps a unique value to every {private key,
message} pair. The only way to generate the unique signature is to possess the private key. Let us define T as the set of trusted node identities, and C as the set of trusted but
compromised node identities, and U as the set of all untrusted node identities. The signing function can then be expressed in Equation 3.11, where id replaces both the private key (k−id) and message, and identity represents the true identity of a benign node.
sign(id a, message b) → a if id == identity a if id ∈ C j, j ∈ U otherwise (3.11)
The implementation of sign() in Equation 3.11 ignores the message field which means that there is no way to associate the original message with the result of the
function. The solution is to always send the result of sign() along with its corresponding message. This solution is allowed according to the Secure OLSR specification.
When a control message, say < origin, message, signature >, is received it is verified by verif(). If the function call returns “valid” then message is processed in accordance with OLSR, otherwise the control message is discarded. It is assumed that the message corresponding to the signature is received in the same packet. Equation 3.12 provides a model of verif():
veri f(id a, message b, signature c) → ‘valid0 if a== c ∧ a ∈ T ‘valid0 if a== c ∧ a ∈ C ‘invalid0 otherwise (3.12)
The first case in Equation 3.12 returns valid when a message is received from a trusted node. The second case in Equation 3.12 returns valid if a message is received that is using a compromised node identity. In all other cases the function will return invalid.
The modeled implementations of sign() and verif() are added to the OLSR model. To implement Secure OLSR: Every HELLO and TC message is sent along with the result of sign(), Equation 3.11. Every HELLO and TC message received is only processed if verif(), Equation 3.12 returns the string valid.
3.6.2 Model Validation. Validation of Secure OLSR requires showing that the sign()and verif() functions are implemented correctly. A good demonstration is that attack vector iii will cause the framework to provide the output FAIL while vector v always results in the output PASS for the inputs φ= φsubset and T = {0..63}. This result is
expected because iii and v use the same attacker definition, but their trust relationships differ. In vector iii all private keys have been compromised, vector v has no compromised keys. The compromised keys allow vector iii to modify control messages and provide the
corresponding signature. The results of these two validation runs are provided in Chapter 4 and correspond to the expected outcomes.
In addition to validating the two new functions it is also necessary to validate that Secure OLSR does not affect the original validation. A validation run with A = i, φ = φcomplete, and T= {0..63} should provide sufficient evidence that the Secure OLSR
model behaves no differently than the original. In this case the output should be PASS for all inputs. Chapter 4 captures the results which validate Secure OLSR.
3.6.3 Security Verification. Security verification can be performed exhaustively over all inputs, T= {0..63}, φ = φsubset, A= {i..v}. Any violations of φ will reveal the
counter-example showing the steps leading to the property violation. The state-space required for the set of topologies T= {64..1023} (i.e., all five-node networks) is too great for performing an exhaustive verification. As a result, only estimates of the full
state-space search are possible. This non-exhaustive verification is performed by setting the verifier’s BITSTATE compilation flag. Using the bit-state approximation should reveal most security violations and provide the appropriate counter-example; however, this does not guarantee that a violation will be found even if it exists for the specified inputs. The Secure OLSR model understands the trust relationships, T , provided in the attack vectors. For this reason attack vectors with no compromised keys should be unable to add false routes. Any findings to the contrary will reveal an unknown attack against Secure OLSR.
The expected outcomes for each attack vector are presented below. Results for all scenarios are available in Chapter 4.
Attack i No attackers are defined, the framework should always output PASS. Attack ii The attacker contains a single compromised identity. With this identity the
of the attacker is trusted nodes in the network will accept the false routes introduced by the attacker.
Attack iii The attacker contains compromised identities for all node identifiers. Given this information the attacker modifies and signs TC messages that it is either elected to forward or generates to advertise itself as an MPR. Because of the compromised identities and attacker definition the framework should output FAIL whenever the attacker node would be selected as an MPR.
Attack iv Although no identities are compromised Secure OLSR is unable to defend against relay attacks. Such attacks are independent of the current trust relationship because the malicious node does not attempt to modify any relayed control traffic. An output of FAIL is expected any time the attacker joins two benign nodes that share no common links.
Attack v The attacker definition is equivalent to iii but no identities are compromised. The security features of Secure OLSR are expected to prevent the injection of any false routes so the framework should always output PASS for this attack vector. 3.7 Chapter Summary
This chapter on the research methodology has presented the goals and assumptions of the security verification framework for secure MANET routing protocols. A justification of the framework’s core model checker, SPIN was given. The design of the framework was presented along with techniques for improving the tractability of MANET routing protocol models. Finally, both OLSR and Secure OLSR models were built and the validation and verification strategies were motivated for each model.
4 Results
A validation and verification strategy was proposed in Section 3.5 for the OLSR protocol. This chapter presents the results of this validation and verification and compares them with the expected outcomes. The chapter also provides the results for the validation and verification of Secure OLSR as discussed in Section 3.6. These results are compared to the expected outcomes for each experiment.