Part 1: General - Computer Security Resource Center - National ...

March, 2007
c. Restricting plaintext symmetric and private keys to physically protected containers. This
includes key generators, key transport devices, key loaders, cryptographic modules, and
key storage devices.
d. Using integrity checks to assure that the integrity of a key or its association with other
data has not been compromised. For example, keys may be wrapped (i.e., encrypted) in
such a manner that unauthorized modifications to the wrapping or to the associations will
be detected.
e. Employing key confirmation (see Section 4.2.5.5) to help ensure that the proper key was,
in fact, established.
f. Establishing an accountability system that keeps track of each access to symmetric and
private keys in plaintext form.
g. Providing a cryptographic integrity check on the key (e.g., a MAC or a digital signature).
h. The use of trusted time stamps for signed data.
i. Destroying keys as soon as they are no longer needed.
The worst form of key compromise is one that is not detected. Nevertheless, even in this case,
certain protective measures can be taken. Key management systems (KMS) should be designed
to mitigate the negative effects of a key compromise. A KMS should be designed so that the
compromise of a single key compromises as few other keys as possible. For example, a single
cryptographic key could be used to protect the data of only a single user or a limited number of
users, rather than a large number of users. Often, systems have alternative methods to
authenticate communicating entities that do not rely solely on the possession of keys. The object
is to avoid building a system with catastrophic weaknesses.
A compromise recovery plan is essential for restoring cryptographic security services in the
event of a key compromise. A compromise recovery plan shall be documented and easily
accessible. The plan may be included in the Key Management Practices Statement (see Part 2). If
not, the Key Management Practices Statement should reference the compromise recovery plan.
Although compromise recovery is primarily a local action, the repercussions of a compromised
key are shared by the entire community that uses the system or equipment. Therefore,
compromise recovery procedures should include the community at large. For example, recovery
from the compromise of a root CA’s private signature key requires that all users of the
infrastructure obtain and install a new trust anchor. Typically, this involves physical procedures
that are expensive to implement. To avoid these expensive procedures, elaborate precautions to
avoid compromise may be justified.
The compromise recovery plan should contain:
1. The identification of the personnel to notify,
2. The identification of the personnel to perform the recovery actions,
3. The re-key method, and
4. Any other recovery procedures.
Other compromise recovery procedures may include:
5. Physical inspection of the equipment,
60