# Cryptographic Key Management in Delay Tolerant Networks: A Survey
## 6 Open Research Challenges  
From the above discussion it becomes obvious that DTN architecture has a number of open issues that must be tackled. Many of them are directly related with the security factor in DTNs and are still open due to disagreements in the DTNRG and/or to the partial insufficiency of the research works in the field [28]. * _Key Management_--As already mentioned, cryptographic key management is the major open issue in DTNs and especially in deep space communications. Section 3 presents and categorises all the schemes proposed until now. Constraints in resources such as memory, power, storage, computation, and bandwidth in DTN nodes put additional challenges on the key management. Resource-conscious key management techniques become a necessity in DTNs. The key management issues that require further research are listed below:
* _Security initialisation_--Security initialisation is an expensive procedure and considering the dynamic nature of DTNs is difficult to handle. As already discussed, the two main approaches are with either a TTP or self-organised. Both approaches have their advantages and disadvantages. * _Key update/key lifetime_--Key lifetime is difficult to choose and must vary based on the different constraints of DTN environments. For instance, if the key update period is too long, the corresponding key may be exposed. If it is is too short, frequent updates can add large overhead. _Key storage_--Considering storage limitations in DTNs in general, and sensor or deep space DTNs in particular, each node must handle the number of possible keying material stored, based on a number of factors, including the number of neighbors, key validity, key expiration, key usage rate, length as well as other stored bundles. Apart from the volume, private keys must be stored securely to avoid compromisation. * _Key revocation_--Key revocation is impractical in DTNs due to the nature of DTNs. Different approaches must be used instead, depending on the specific network constraints. * _Handling Replays_--In DTN networks, due to scarce network resources, the replayed volume of messages must be reduced to the minimum possible. However, this is not always the case due to various DTN scenarios (i.e., authentication scenarios) where at least some replay messages are desirable. Moreover, the huge delays in such networks, complicates handling replays, and therefore the formulation of a DTN replay protection scheme becomes very challenging. * _Traffic Analysis_--There are not any security services for protecting/deterring against traffic analysis. However, for some disruption tolerant networks such as military ones, hiding traffic is rather a sine qua non. * _Routing Protocol Security_--There are no well-documented DTN routing protocols, so DTN routing protocol security is an open issue. However, some of the existing security features of the underlying protocols can be used. * _Multicast Security_--Currently, there is no mechanism to separate between a multicast and anycast endpoint. DTN security architecture does not address the security aspects of enabling a DTN node to register with a particular multicast or anycast endpoint identifier at all. * _Performance Issues_--Security within a DTN imposes both bandwidth utilization costs on the communication links and computational costs at the nodes. In addition, there may be certain limitations regarding how much CPU, storage, energy, and so on can be devoted to security, and the amount of computation costs will undoubtedly depend on the underlying algorithms and their associated parameters. * _Naming_--DTN naming is a hard open issue to cope with [9]. For instance, how names are to be used in routing, and the ways this will be mapped to the underlying routing of each convergence layer network, remains unclear. A properly constructed naming system can aid in simplifying both routing and security.