This article discusses the exchange of information between entities within a security domain and other entities outside of the security domain.
Security Domains
The concept of security domains should be considered when creating a cryptographic key management system (CKMS) security policy. A security domain is a collection of systems (servers, devices, and so on) that share a common set of keys and are attached to an administered network. Security domains are necessary because server-level security becomes difficult in large-scale systems as the number of stand-alone entities increases. By managing and partitioning of a shared set of keys between networks, a common platform can be used to provide security. A policy called the Domain Security Policy, which is a part of the CKMS policy, provides the rules and restrictions that allow computers, networks, applications, and users in the same domain to exchange and process data, keys, and metadata in accordance with the policy.
Conditions for exchanging data within and outside of a security domain
When two mutually trusting entities are in the same security domain, their CKMS policies are equivalent, and they can exchange data, keys, and metadata with the given protection stated in the Data Security Policy. However, when two entities are in different security domains, they may not be able to exchange keys and metadata because they operate under different policies. It is possible for an entity in one domain to send keys and metadata to another entity in another domain, even though their domain security policies are different. There are certain conditions that must be satisfied in order to establish the compatibility needed. First, it must be assumed that the two entities utilize functionally identical encryption/decryption algorithms that use the same key lengths. It is also assumed that there is an open communication channel between the two entities, and that they trust each other enough (and perhaps other entities in the network) to enforce their own security policies. Then it must be determined that the security policies of the two entities must be equivalent (although they are different).
Assurance of domain equivalence
In order for an entity to send a cryptographic key and/or metadata to the receiving end, the sending entity should have the assurance that the protection requirements in the receiver's security policy are at least as good as those in the sender's security policy. Also, the receiving entity needs assurance that the protection requirements in the sender's security policy are at least as good as those in the receiver’s security policy. Once it is found that two security domains are equivalent (either by an authority or an automated program), users in both domains can exchange sensitive data with the assurance that it is protected. In addition, other entities that use one of the two domains can freely share data with each other. This concept is known as “Third-Party Sharing”.
If the two domains are not equivalent, and one entity is found to have weaker security policies than another entity, the CKMS should at least be able to inform the entity with stronger security domain of the possible security consequences if communications are attempted. Two domains that are not equivalent can still be compatible if a certain subset of the provided protections satisfy both security policies, and are found to be equivalent. In this case, data exchange and processing is limited according to the equivalent portion of the policies.
Multi-level Security Domains
The problem that equivalent domains are required before any data can be shared can be partially solved by employing multi-level security domains. For example, the Domain Security Policy of an entity could provide either a high level or a low level of protection to the keys and/or metadata that it processes. The advantage of this is that the CKMS keys and/or metadata from an entity operating at different security level can share data with an entity using a multi-level security domain. The two entities must also be assured that the appropriate level of protection is provided for the keys and metadata by the CKMS in accordance with the multi-level policy.
Upgrading and Downgrading
Upgrading: It is possible for a network in a higher level security domain to receive and protect keys and/or metadata from lower-level security domain (a domain providing less protection). This is called Upgrading, and should only if the risks and consequences are understood, and the network in the lower-level domain can be trusted.
Downgrading: Likewise, the network with a higher-level security domain can pass a key and/or metadata down, or downgrade, to a lower-level domain network. In this case, the domain authority for the higher-level domain should have confidence that the key and/or metadata being passed down only require the lower level of security provided by the receiver.
Configuring a Domain Security Policy
Some domain security policies are configurable, in that key and/or metadata management functions can be manually configured in a CKMS that are used to support and enable communications with entities in other domains. For example, a domain security policy can be configured to support one level for data confidentiality services and another level for data integrity services. So in essence, it would be possible for any two networks with any type of domain security policy to communicate. However, communication between two domains is effective only if the key management mechanisms are properly configured and maintained. It is also possible for two entities to negotiate security for a sensitive transaction based on their existing policies. A new domain security policy (either temporary or permanent) can sometimes be created on the fly (either manually or automatically) to allow the transaction.