The new key management architecture and framework provides a way to build a shared state by establishing a secure channel between communicating parties by exchanging keys and negotiating cipher suites to use for communication. It also helps the communicating nodes to setup their security policy information dependent upon shared secret state. A way to notify about certain events or to send error messages between communicating parties is also defined in the new key management architecture and framework. All the components of key management framework and how they work together are shown in figure 7-2. This section describes in detail the new key management architecture and framework defined for DTN.
Key Management Architecture and Framework
Public Key Certificate Validation and Revocation Status Checking Mechanism New Certificate Validation and Revocation Method New ESKTS (Efficient, Scalable Key Transport Scheme) Mechanism to Establish Security
Association (SA) Provides
Establishes
Informational Exchanges (Control Message &
Error Information )
Shared Secret Keys, Cryptographic Suites)
Figure 7-2: Key Management Architecture and Framework: Components and their working
7.2.1 Establishing Shared Secret
7.2.1.1 Exchanging Keying Material
A secure channel is a way to transfer data between communicating parties which is resistant to interception and tampering. The secure channel achieves confidentiality, integrity and authentication between communicating parties. A secure channel is termed as “Security
vary in each direction. To establish secure channel between communicating parties in both ways, two SA will be established in each direction.
To establish a SA between communicating parties in two directions, ESKTS should be run in both ways (see chapter 5 for details about ESKTS). ESKTS will enable both communicating parties to generate the symmetric keys at their ends and transfer them to other communicating in a secure way on an unsecure channel. As ESKTS is based on public key cryptography, the certificate of communicating parties will be required to be validated for revocation which can be checked from the CRL distributed via new Certificate revocation and validation mechanism. New heap based CRL certificates revocation mechanism is proposed in chapter 6 to provide a suitable mechanism for DTN based networks.
At this point in secure channel establishment, each party would have generated symmetric key for cryptographic operations like confidentiality and authentication and all keys are delivered securely to other parties. The communicating parties can prefer to use different keys for each of security operation like confidentiality and authentication or can use same key for all security operations depending upon their security requirements. The symmetric keys negotiated can help only for end-to-end integrity, authentication and confidentiality operations. As, DTN requires hop-by-hop integrity and authentication, the same proxy signatures will be used for all secure communication even symmetric keys have been established between end parties.
A separate long life key can also be negotiated in the start which can be used for rekeying of symmetric keys for later on communication. It is totally dependent upon the security and communication requirements of the communication system and is purely deployment decision. The key management architecture and framework can properly work for exchanging new keys each time rekeying is required.
All the payloads in secure channel establishment communication will be encapsulated according to BP and BSP rules (more details are available in chapter 5).
7.2.1.2 Negotiating Cipher suites between communicating Parties
Cipher suites can be negotiated at the time of exchanging keys and building secure channel via ESKTS. There are 4 mandatory cipher suites defined for BSP and there is a support to define any custom cipher suites in BSP. The information about cipher suite to be used can be embedded in the ESKTS payload message according to BSP specifications.7.2.1.3 Security Policy Setup
Security policy is an enforcement point for every node to process messages securely. The security policy can be distributed by many different roles in the network e.g. policy distribution server etc, but we only focus here to distribute the security policy from source to destination in a unicast communication. The details about how the security policy is defined are out of scope of this document. However the defined policy can be encrypted and encapsulated in the bundle blocks according to BP and BSP rules.
The security policy defines many parameters, for example, forwarding conditions; under what conditions the BAB supplied information should be considered enough for authentication etc. As security policy is meant for end-to-end communication, the security policy defined and encapsulated in bundle format can be encrypted by the generated symmetric key at the source end and can be securely transmitted to the destination along with other keying material information in ESKTS message exchange or can be transmitted separately once a secure channel is established.
7.2.2 Informational Exchanges
As DTN networks have characteristics for high delays and high disruptions, there are large chances that bundles sent can be lost. So, there is a big requirement that peers may desire to convey some control or error information e.g. notifications or configuration scripts etc. To accomplish this. Key management architecture and framework defines a support to send these informational messages. These informational exchanges can only happen after establishment of secure channel. Once symmetric keys are established between communicating parties, the informational payload can be encrypted by using the symmetric key and can be sent to destination via secure channel. However, how the informational exchanges are defined is out of the scope of this document as all control information signals and configuration scripts are not yet finalised by DTN community.
7.3 Summary
This chapter has defined a new key management architecture and framework to enable secure, practical deployment of DTN networks. The new key management architecture and framework provides a way to build a shared state by establishing a secure channel between communicating parties by exchanging keys and negotiating cipher suites to use for
information while exchanging the keys by encrypting information with secret key. A way to notify about certain events or to send error messages between communicating parties is also defined in the new key management architecture and framework.
8 Conclusions
In this final chapter, we will highlight the conclusion of the work presented in this thesis, and list a few directions for possible future improvement and new research areas.