Discussion

4.4.2.1 Tool Evaluation

Theorem proving approaches aim to provide such formal proof. Initially, it was  decided to verify the IDKE protocol’s correctness by either using the BAN logic (see  Section  4.1.2.1)  or  Isabelle  (see  Section  4.1.2.3).  However,  both  have  serious  drawbacks in discovering actual attacks since they e.g. do not show any attack trace. 

Hence, once a protocol cannot be verified, one does not have the possibility of  rectifying the problem when the vulnerability is not obvious. BAN logic also has  serious  disadvantages  due  to  its  unrealistically  simplified  assumptions  on  authentication. In fact protocols that have been stated as secure by the BAN logic  have been  discovered to  be vulnerable to attacks that break the authentication  capabilities.  

Therefore, the active search for attacks becomes an essential part of the security  verification. As the NPA (see Section 4.1.2.2), which is a hybrid approach for model 

checking and theorem proving is not publicly available; the Casper/FDR approach  was  selected.  This  is  currently  the  most  promising  approach,  especially  for  identifying attacks on protocols, but it is limited in its capability of verifying huge  protocols. The IDKE protocol is in fact immense in size and exceeds the state space of  the FDR when one examines the entire protocol without applying any modifications. 

This results in two conflicting goals: Firstly, of reducing the state space in order to  make the FDR capable of analyzing the IDKE protocol; and secondly to have the  most general scenario for ensuring that all potential attacks are discovered. Thus,  instead of analyzing the protocol in one‐piece, the IDKE protocol is successively  assembled in versions, verified, minimized and consecutively improved. 

4.4.2.2 The Deployment Process

The protocol was successfully improved by beginning with a basic version which  aimed to provide only a subset of the desired properties. This version focuses on  providing a simple key forwarding and does not guarantee any key forward secrecy  or offer any secure tunnel between the ARs. However, under the specified security  properties, this version is stated as secure. Nevertheless, the version was not minimal  since it contained some unnecessary non‐essential parts, such as some IDs. In order  to reduce complexity, a number of identifiers within some of the messages were  removed.  Further analyses  demonstrated  that  some of  the identifiers  were  not  required, while others were relevant. Moreover, a complex attack was unexpectedly  discovered when removing the MN’s identifier in message 4. This attack illustrated  that the protocol could be broken by initially interleaving several protocol runs and  also by acting as man in the middle. As a result of this, the intruder was able to  produce an invalid authentication. However, authentication is also an obligatory  property of the IDKE protocol, even if no secret information is discovered. 

In order to achieve a minimal basic version, the protocol was subsequently trimmed  down by exclusively removing unessential parts. This process resulted in a minimal  and secure basic version. This version later acted as the basis for producing a final  version that contains all of the desired properties. 

A secure tunnel was also established and added between the ARs and the resulting  version  was  successfully  verified  as  being  secure.  Nevertheless,  a  desired  improvement was to add forward secrecy to the tunnel key. Therefore, the version  was modified to include a Diffie‐Hellman key negotiation mechanism. 

However, the integrated DH tunnel was stated as being insecure. The FDR again  discovered a complex interleave‐attack which resulted in a failed authentication,  despite the fact that the key affords forward secrecy. This circumstance led to the  concept of adding interleaved tunnels in order to confront the attack. The first secure 

final version implements an authenticated tunnel which provides forward secrecy  between the ARs. 

4.4.2.3 The Final Version

The FDR trace refinement check of the final CSP input script indicates that this  version  of  the IDKE protocol  is  secure  as  an attack  has  not  been  discovered. 

However, the Casper/FDR approach is limited in its capabilities of model checking. 

Depending on the approach chosen, the security analyses will still reveal attacks and  if used improperly,  the results are unreliable and  almost worthless. One main  problem is the mapping of reality into the checking environment. The environment  in the CSP and the intruder can be modeled to map actual attacks. This means that  the modeling of the environment in this way can map such attacks as those on the  modifying of messages, the reflecting of messages and so on. Therefore, the CSP‐code  producer has a direct control over whether, for example, a message can be delayed or  not (cable vs. wireless environment). However, major problems arise with attacks on  the decryption of electromagnetic radiation, etc. Such attacks are difficult to carry out  and are not really advisable for implementation in the formal analysis due to the  resulting complexity. Furthermore, it is a profound mistake to assume the security of  an implemented protocol purely by its formal analysis. One should always take into  account under what assumptions the protocol was actually stated as being secure.  

The disregard of initial formal assumptions can result in implementation failures that  could destroy the protocol’s security. Thus, the absence of attacks needs to be  carefully considered as the verified implementation only represents a subset of an  infinite space of states.  

Nevertheless, the verified implementation (#System, #Actual variables) covers the  majority of the specification (#Processes, #Free variables).Due to this considerable  coverage a  potential attack can most  probably be discovered.  The Casper/FDR  approach is currently the best available technology and thus, the most promising  method for security protocol analyses.  

However, the Casper/FDR approach is not capable of explicitly analyzing the secrecy  of the session‐key renewal due to its limited state space. This is the main drawback of  this model checking approach. Normally, only very small protocols are analyzed by  Casper/FDR, such as the Needham Schroeder Shared Key Protocol. The analysis of  such small protocols requires less than 30 seconds whereas the IDKE protocol needs  up to 38 hours to complete the task.  

Cremers and Mauw [CM04] stated that Casper/FDR is incapable of handling larger  protocols due to the complexity of the graph analysis. The observations made during  this work showed that the maximum memory which the FDR “state2” subprocess is  able to allocate is approximately 3.1 Gigabyte. If only a 1GB space is required for the 

state space, then approximately three million graph transitions can be performed  before an FDR memory allocation failure occurs. This indicates that larger protocols  can be analyzed when careful design and minimized supplementing is taken into  consideration.  

Nevertheless, the final version realizes a secure key transfer from the pAR to the nAR  using a fresh tunnel key which provides forward secrecy. The protocol was verified  in order to guarantee the authentication between the MN and the next AR, as well as  between the  nAR  and the  pAR.  The secrecy  of all  keys  and  nonces was also  validated. Therefore, the final specification of the IDKE is precise, optimized and  security validated