Secure Military Messaging in Coalition Operations

Introduction

International military operations are increasingly being conducted as coalitions, such as in the Gulf War, Bosnia, and Timor. While some nations such as those in NATO have considerable experience of combined operations, it is increasingly probable that coalition forces will be composed of diverse nations without any history of combined operations. These coalitions will exhibit many or all of the following characteristics:

• Large number of contingent members. Coalitions may contain a large number of contingent nations, perhaps 20 or more. These members may have significantly different motivations for their presence in the coalition, reflecting their respective national strategic priorities.
• Single lead nation. An authority, such as the UN, will designate a nation as the lead nation to provide the coalition commander.
• Differing levels of trust. Diversity among national contingents may result in differing levels of trust between contingent nations.
• No coalition infrastructure. A coalition operation may occur in a region where there are no fixed military communication assets. Coalition members may have non-interoperable equipment and different processes and procedures.
• Provision of communications infrastructure by Lead Nation. The lead nation would typically provide the communications and information systems (CIS) infrastructure, although other nations may provide some CIS components.
• Common CIS system. A common command support system and communications system is likely to be used in the coalition headquarters, accessed by liaison officers from different contingent members.
• Deployment evolution. The deployment may change over time, with respect to contingent members, command arrangements and involvement of civil agencies.

Although the need to share information for command and control (C2) support is essential, it is unlikely that within a large coalition all contingent nations would be prepared to share information equally. However, within the coalition there may be sub-groups of nations where high levels of information sharing might occur. The dilemma for contingent nations is their need to protect their national systems while supporting a degree of integration with the coalition system. For the Lead Nation this is particularly critical.

Current practice would create both a Secret Coalition and a Restricted Coalition network to mirror national systems. The classifications would be defined in coalition terms, instead of national terms, and the protection of these systems would reflect that of the respective national system. This paper explores the enhancement of a Restricted Coalition system with strong need-to-know protection for C2. The classification level of coalition C2 systems is discussed further in the final section.

Within a traditional national Restricted Defence security infrastructure the requirement to segregate need-to-know information is not particularly high, except for very specific types of information, and is not typically enforced by any technical security means. Within a coalition system the requirement for need-to-know separation is assumed to be high and technical enforcement of separation may be advantageous. Secure messaging products utilising Public Key Infrastructure (PKI) technology (often called 'Certificate Management Infrastructure' (CMI) in the military literature) is now being adopted in commercial and military environments and provides such a technical capability. NATO and AUSCANNZUKUS nations are beginning to deploy PKIs to provide such capabilities.

Fundamental to the solution of these security problems is the need for a security architecture, loosely defined as a series of elements and associated functions to enforce or implement security policies. Associated with security functions are security mechanisms, ranging in strength from those capable of separating information of different security classifications to those with only sufficient strength to separate need-to-know information within a single security classification level. Some mechanisms operate at a coarse level of access control granularity while others implement fine-level granularity. The remainder of this paper explores the possible integration of PKI technology into the security architectures required by coalition operations and the potential capability enhancement this technology offers.

Security architectures

This section describes several possible coalition security architectures suitable for system-high Restricted mode of operation. A coalition deployment may include more highly classified systems, particularly those of the Lead Nation. However, access to these systems is likely to be highly controlled with connection between these systems and the coalition Restricted system being unlikely. These systems are not discussed further in this paper.

Architecture 1—extended national restricted system

This architecture, depicted in Figure 1, connects the Lead Nation’s Restricted network directly to the coalition network allowing common access by coalition members. A particularly important requirement is for the coalition commander to have access to both national command support systems and access to the coalition headquarters system, which would typically include liaison staff of contingent nations and other agencies, such as the UN.

From a security perspective this architecture is a single security domain as there is no segregation of the coalition system from the Lead Nation’s Restricted system. The classification of this system would in effect be Lead-Nation Restricted. As the coalition deployment continues the range of agencies and individuals requiring access will grow, and as the number of coalition members with access to the coalition network increases, so does the likelihood of compromise to the Lead Nation’s Restricted system. Such a broad opening up of a national Restricted network would not be acceptable from a security perspective. Consequently, this approach is not scalable and not viable beyond an initial start-up phase of deployment.

Architecture 2—separate coalition restricted system

Architecture 2, depicted in Figure 2, deploys two separate CIS infrastructures into the theatre of operations, one for the Lead Nation (which may include trusted coalition partners), and another for common coalition use. This traditional air-gap approach avoids the problem inherent in Architecture 1 of opening up the Lead Nation’s system to less trusted members. However, this approach has a significant shortcoming in disallowing access by deployed elements of the Lead Nation to their national command support infrastructure via the coalition system. While this architectural approach is well established in national, strategic systems, the provision of dual systems requires increased communications infrastructure and may not be viable from an operational or a resourcing perspective.

Architecture 3—co-existing national and coalition restricted systems

Architecture 3, depicted in Figure 3, seeks to preserve the integrity of the security domains of Architecture 2 while providing some of the information service transparency of Architecture 1. A common Coalition Domain is created, as per Architecture 2, but a Guard is placed between the Lead Nation’s national Restricted system and the coalition system to protect the Lead Nation’s Restricted domain. Access is regulated by the Guard which permits specific information services, that is messaging and potentially others, to operate across the domain barrier. Coalition members and other agencies cleared to access the coalition network can be given access to the Coalition Domain without being given access to the Lead Nation’s network.

For the Lead Nation access to a range of services within its national infrastructure is permitted from the Coalition Domain that is not possible in Architecture 2. This protection is seen as essential since the threat environment of the coalition system is likely to increase with increasing numbers and diversity of coalition members. Clearly, the strength of the security mechanisms employed by the Guard determines the strength of the protection provided to the Lead Nation’s national systems, but these issues are beyond the scope of this paper. Contingent nations would face similar problems with regard to interconnection with their respective national systems.

Figure 3 also depicts an extension of the Lead-Nation Restricted domain with a Virtual Private Network (VPN). This is achieved by running the VPN over the coalition Wide Area Network, using appropriate encryption to maintain adequate separation of Lead Nation traffic from coalition traffic. The remote Lead-Nation enclave is essentially part of the Lead Nation’s Restricted domain and potentially allows access from within the enclave to all services within the Lead Nation’s Restricted domain, not just those supported by the Guard. VPNs are a mechanism to provide closed user groups of finer granularity than the physical security domains discussed above. PKI, discussed in the next section, provides an even finer-grain mechanism than VPNs.

PKI based application level security services, or writer-to-reader security services, have been developed since the mid 1990s and provide authentication, integrity and confidentiality services on a per-message and per-recipient basis. Identification and Authentication (I&A) are the more commonly discussed security services provided by the PKI digital signature but PKI also supports confidentiality services. While the confidentiality services are generally regarded of secondary importance, our intention is to describe the use of the confidentiality services to provide flexible implementations of closed user groups. Although I&A services would be used in conjunction with confidentiality services, the discussion focuses on confidentiality services.

PKI technology makes use of public key cryptography [1] whereby a pair of keys exists that allows encryption with one member of the key pair and decryption of the encrypted content with the other member of the pair. One of the key pair members is made public while the other is kept private by its owner. When the message is encrypted by the sender with the recipient’(s) public key, it can only be decrypted by the recipient(s) with the recipient’(s) private key. In practice, this mechanism is used to protect a symmetric encryption key (commonly called a Message Encryption Key) which is used to encrypt the message, as symmetric encryption methods are faster than asymmetric public key encryption methods.

Different algorithms exist to support PKI-based encryption and each provides differing capabilities. The Key Exchange Algorithm (KEA) is a variant of the Diffie-Hellmann algorithm and supports multiple encryption key universals [2]. Users can be given common key universals to allow them to encrypt and decrypt messages among themselves. This allows user sub-groups with different key universals to be created where encrypted messages can be exchanged within the sub-group, but not between sub-groups. These sub-groups are referred to as cryptographic sub-domains and support the creation of closed user groups. KEA, or similar algorithms, can be used in a natural way to implement cryptographic sub-domains.

In practice, a user may be allocated to more than one cryptographic sub-domain to allow that user to be a member of more than one closed user group. The operational value of the cryptographic sub-domain is that, after selection of an appropriate sub-domain, the unintended inclusion of a recipient outside that selected user group will result in a cryptographic failure being detected by the sender at message creation. In an operational coalition environment where there is a need to protect need-to-know, this added safeguard provides a valuable ‘fail-safe’ mechanism. Clearly, if a cryptographic sub-domain including all users is selected, or a security policy allowing the sending of unencrypted messages from the domain is permitted, no such protection is afforded.

Users are issued with secure tokens, which contain their private keys, by the RA. These tokens may be software or hardware and protect the private key from disclosure and unauthorised use. Software tokens are simple to deploy and do not require hardware changes to workstations. The software tokens may be transferred to the user’s workstation and unlocked with a pass phrase issued to the user. Software tokens are more susceptible to private key compromise, and unauthorised use than hardware tokens. Hardware tokens, while more expensive, have additional security services and have stronger mechanisms. Hardware tokens can more easily support mobile users as they can be readily transferred securely from workstation to workstation. In a typical deployment a mix of software and hardware tokens could be used and users can be migrated from one token form to another, as required.

The strength of the security services provided by PKI services is largely dependent on the implementation of the elements of the security architecture and this includes the PKI certification practices. Tokens and certificates should only be issued to properly authenticated users who have a legitimate requirement for the service. Compromised keys and associated certificates must be revoked by an appropriate mechanism for the deployed environment. Procedurally, if a need-to-know service is required then sign and encrypt must be selected for every message sent. Messaging clients (applications) need to be configured for this option as the default.

Integration of pki capabilities

PKI technology can be used to create ‘virtual’ domains composed of individual users and may be used in conjunction with any of the security architectures described above. Essentially, a user may encrypt a message on a per-message basis, such that only the designated recipient(s) may decrypt and hence access that message. The message, having been read, is typically stored encrypted on the recipient’s system, using either an encrypt-to-self or storage key technique.

The deployment of public key security services requires the following components:

• Messaging clients enabled with cryptographic security services and associated mechanisms. These are typically available in commercial products or a simple upgrade to existing user e-mail clients.
• User tokens for storage of the user’s private keys.
• A PKI to create, manage, and distribute keys and tokens

Certificates, containing public keys, are created and certified by the CA. The operation of PKI services also requires that certificates and certificate revocation lists are accessible to all recipients by a directory or equivalent service.

Figure 4 depicts the PKI components, that is the CA and distributed RAs. This example shows a single CA which can either be located within the Lead Nation’s Restricted System, or within the Coalition Domain. The CA communicates securely with each RA, using PKI security services or other means, and generates both the user’s token and their certificates each time a new user is added to the system or a user’s privileges are changed. The CA is essentially a ‘lights out’ operation with the RA workstation and operator providing the user interface to the system. RAs are positioned wherever required and, typically, collocated with administration staff. Major sites are provisioned with an RA while minor sites could be supported by their higher-level organisation, or by a neighbouring provider under agreement between organisations. Mobile units would be supported by their home base. The architecture is flexible and can be changed to reflect operational requirements.

Figure 5 demonstrates a flexible configuration of the cryptographic sub-domain services. In this example nation N1 is a member of a cryptographic sub-domain with nations N3, N4 and N5. N1 is also a member of another cryptographic sub-domain with N2 and a member of the entire Coalition PKI Domain.

The provision of the PKI services is flexible and the specifics of the implementation would depend on operational requirements and the capability and level of assurance provided by the PKI. For example, it might be appropriate to provide a cryptographic sub-domain for C2 functions incorporating key command staff, equipped with hardware tokens for additional security. If cryptographic universals are used, then these are securely transferred and authorised to the appropriate PKI sub-domain.

The Coalition PKI Domain can extend beyond the Coalition Domain (Coalition Network), as is shown in Figure 6. User A in the Coalition Domain can send a secure message to users B and C located anywhere outside the Coalition Domain. It is assumed that the Coalition Domain will have an Internet gateway to obtain public information, such as weather reports or other commercial services. A possible scenario is for user B to be reached via the Internet, while C is reached via a military rear link. While E and F may be able to communicate already via other networks, the security services provides the same level of protection as between A, B and C. For users G and A, both within the Coalition Domain, the coalition PKI provides need-to-know protection within the Coalition Domain.

While the example in Figure 4 indicates a deployment of considerable size, comprehensive design is not required during initial deployment. The initial PKI deployment may be as small as a single CA and a single RA with a handful of users. This may be scaled up to include part of the membership of the Coalition Domain, the entire Coalition Domain, and finally persons and organisations beyond the Coalition Domain. Separate cryptographic sub-domains may be implemented later if the PKI product supports such a capability. With very-large-scale deployments a gradual development of the system is essential for manageability. The US Defense Messaging System is an example of a large PKI system, which uses cryptographic domains based on universals and has adopted an evolutionary approach.

Discussion

The intent of this paper is to explore the application of PKI technology, providing strong need-to-know protection for coalition C2 systems. The use of a single C2 network would save infrastructure costs, but there are two major objections to using a classification level of Coalition Restricted for this purpose. Firstly, the C2 network should be Secret. Secret is defined in national terms as the potential for serious damage to national security resulting from unauthorised disclosure (Australian definition) [4]. This may have little meaning in a coalition environment, as participant nations tend to regard material classified as Coalition Secret to be relatively low in national terms. Secondly, a Secret Coalition system needs to be built to a protection standard equivalent to that of a national Secret system. The implementation of PKI goes some way to increase the strength of the protection within a Restricted system. Further discussion of this point is beyond the scope of this paper. However, the PKI mechanisms described could equally be applied to a Coalition Secret system.

As discussed, different levels of trust may exist between different coalition members. While a degree of common purpose between coalition members can be assumed, all members cannot be assumed to have the same objectives and certainly will not have the same strategic objectives beyond the specific coalition operation. Therefore, membership of the coalition may provide an opportunity for intelligence gathering against other members of the coalition or the Lead Nation via shared information systems. The security environment of the coalition system may in reality be more like the Internet environment than a classified network. In this environment the protection of need-to-know gains more importance.

Figure 7 suggests a qualitative weighting of the different security services. Panel (a), fixed strategic networks, shows the high priority afforded to confidentiality compared to panel (b), single nation tactical environments, where confidentiality is deemed to be of much lower importance, reflecting the short information lifetime. The high priority of availability in the tactical environment is clearly indicated. However in panel (c), coalition deployed environments, the confidentiality protection of need-to-know is considered to be much higher than in a single nation tactical environment.

The need to provide confidentiality, including need-to-know protection, is clearly important. This paper has described three mechanisms to provide confidentiality services. The first is security domains separated by Guards or air gaps to regulate flow of information across domain boundaries, and provide access control mechanisms. The second is the VPN which can extend a security domain beyond a single physical environment via a Wide Area Network without the use of dedicated communications bearers. The VPN effectively provides finer granularity by being able to extend a security domain. However, the boundaries of these domains must still be protected to the same level as the security domain to which they are joined. The third mechanism, PKI cryptographic domains, has the finest granularity, allowing an individual member to encrypt the content of a message, and forward it to another individual or group of individuals without other persons intercepting and decrypting the message.

The security services of Identification, Authentication and Non-repudiation have not been addressed specifically despite the fact that PKI is normally advocated for these purposes. Considerable debate has occurred about the ability to provide PKI services in the tactical environment because of the overheads of security protocols, processing overheads, etc. The current view is that these services are desirable if the risks and costs can be mitigated. Messaging provides a valuable information service but one that is highly vulnerable without adequate security services. With complex coalition arrangements becoming increasingly common, the per-message confidentiality services offered by PKI technology represent a potentially valuable capability enhancement.

References

Authors

Dr. Parker has worked in information security and military messaging at DSTO, Australia and worked closely with the Australian Defence Headquarters in the development of the Defence Messaging and Directory Environment (DMDE) capability (now e-Defence). He is currently located within the Command Support Systems Branch, of the Defence Materiel Organisation, Department of Defence, Canberra.

Dr. Henderson has worked in information security at DSTO, Australia. This work was completed while with the Information Security Research Centre of the Queensland University of Technology (under a TAO grant). Dr. Henderson is now with the Department of Mathematics, RMIT University, Melbourne.

Mr. Moore has extensive experience in military C2 and information security. He has been instrumental in developing the Spyrus PKI Certification and Registration Authority product and is a consultant to the Australian Department of Defence on PKI matters.