21 March 2003. Thanks to Anonymous.
More on CAW via Google: search on "CAW 3.1."
Later versions of CAW include 4.1 and 5.0.
11355-AP03-004
October 22, 1997
0N639241: 23 July 1997
Revision 1.1: 22 October 1997
Trainee Guide for the
CAW 3.1 Users Training Course
Module 2 - Security Policy and Practices
MDA904-95-C-4034
PREPARED FOR:
[NSA] Maryland Procurement Office
PREPARED BY:
Government Systems Operations
Motorola Inc.
Space and Systems Technology Group
8201 E. McDowell Road
Scottsdale, Arizona 85257
"NOT RELEASABLE TO THE DEFENSE TECHNICAL
INFORMATION CENTER PER DOD DIR. 3200.12"
"DISTRIBUTION LIMITED TO U.S. GOVERNMENT AGENCIES ONLY, THIS
DOCUMENT CONTAINS NSA INFORMATION (October 1997). REQUEST
FOR THIS DOCUMENT MUST BE REFERRED TO THE DIRECTOR, NSA."
PREPARED BY: REVIEWED BY:
_____________________
Carl Boos Holly Moyer
LCS Systems Engineer LCS Project Leader
APPROVED BY:
_____________________
Tom Grimes
Program Manager
Government Systems Office
TRAINEE GUIDE
CAW 3.1
Users Training Course
MODULE 2
Security Policy
and
Practices
Revision History
|
Revision |
Description |
Date |
|
1.0 |
Original |
22 July 1997 |
|
1.1 |
Incorporates updated forms and procedures |
22 October 1997 |
2.0 Introduction
The NSA developed the Information System Security Policy and Certification Practice Statement for Certification Authorities (ISSP/CPS) to define a common set of polices and practices for physical, technical, operational, and procedural controls. Together, these controls define the "trustworthiness" associated with issuing and managing certificates. Certification Authorities, System Administrators, and Information System Security Officers must strictly adhere to these controls, and recognize that a single Certification Authority Workstation (CAW), operating outside of these controls, jeopardizes the integrity of the entire infrastructure.
This module introduces the student to the ISSP/CPS, and the importance the NSA places on the secure operation of the CAW and the issuing and managing of certificates.
There are six units in this module:
2.1 Certification Hierarchy2.2 DoD CMI Information System Security Policy
2.3 CAW Roles Defined
2.4 Technical Controls on Security
2.5 Procedural Controls on Security
2.6 CAW Environmental Controls
2.1 Certification Hierarchy
Thousands of end users may reside within the MISSI domain, who have a need for secure communications capabilities. Today, the United States is the only MISSI domain; however, future domains are anticipated that will allow the DoD to interoperate with its trading partners. Since a domain’s size is so large, the NSA must divide it by distributing or "decentralizing" the Certification Management Infrastructure. For example, the United States domain may be subdivided into DoD, Civil, and Commercial. Further division might be necessary if a subdomain’s size is still too large.
Each domain is composed of a hierarchy of authorities that perform different functions. (See Figure 2-1) These authorities include the Policy Approving Authority (PAA), Policy Creation Authority (PCA), Certification Authority (CA), and Organizational Registration Authority (ORA), as defined below. Most of the day-to-day operations of the Certification Authority Workstation (CAW) (key/certificate generation, FORTEZZA card programming, FORTEZZA card and PIN distribution, etc.) are performed by a single operator, the CA and/or the ORA.
Figure 2-1. The MISSI Certificate Hierarchy
Due to the critical and sensitive nature of their tasks, these authorities (PAA, PCA, CA, and ORA) must be highly responsible and reliable individuals. The workstations they use to perform their tasks, must also be trusted. These workstations cannot be used for other activities. They must be secured in such a way that only authorized personnel can access them.
2.1.1 Policy Approving Authority (PAA)
A PAA is the top level authority of a MISSI certification hierarchy tree. It represents a community of end users, such as the United States. While the PAA is considered ‘neutral’, a logically distinct hierarchy will be built for each cryptographic domain. A PAA registers PCAs and signs their certificates. A PAA issues a CRL, as all certificate issuing authorities do, but does not issue a CKL.
The PAA provides the "single point of trust" for the entire domain. The final verification of authenticity for all certificates issued in the MISSI domain resides with the PAA. All certificates within a domain become invalid if the PAA or the PAA’s private key is compromised. This catastrophic event compromises the entire system and requires a total restart.
2.1.2 Policy Creation Authority (PCA)
A PCA is the administrative root for the security policy of its domain, such as the DoD. Multiple PCAs may exist within a single cryptographic domain. This means, all CAs and end users under those PCAs can communicate, since they use the same cryptographic algorithms and parameters.
A PCA registers the CAs in its domain, defines their configurations, and issues their certificates and FORTEZZA cards. A PCA has the capability to issue certificates to end users and other end-entities, but is not usually expected to do this. Periodically, a PCA issues CRLs and CKLs for its domain. Note that a PCA is the only MISSI CMI component that can issue a CKL. When a PCA issues a CKL, it "pushes" (or sends) this CKL to its subordinate CAs.
It is the PCA’s responsibility to ensure all subordinate CAs follow the "Information System Security Policy and Certification Practice Statement for Certification Authorities."
All certificates issued by the PCA or the CAs are invalid if the PCA or the PCA’s private key is compromised.
2.1.3 Certification Authority (CA)
A CA is the MISSI administrative authority for an autonomous organization, or major unit of an organization, under a PCA's domain. A CA registers end users and issues their certificates. This includes initializing and loading the end users' FORTEZZA cards, and entering the end users' certificates in the directory (DSA). Periodically, a CA issues a CRL. The CA must distribute all the CKLs that it receives from the PCA, to the end users.
All certificates issued by the CA are invalid if a CA or the CA’s private signature key is compromised.
2.1.4 Organizational Registration Authority (ORA)
The ORA is an optional role. It can be established by the CA to relieve the workload required to manage a CA's administrative domain. It is most useful when the CA serves large end user communities.
The primary function of an ORA is to provide an interface between the end user community and the CA. An ORA should be located near end users because they often interact.
The ORA assists the CA in many tasks, such as:
The ORA is the point-of-contact for end users to:
The ORA may not sign certificates or CRLs. These are the exclusive responsibilities of the CA.
The ISSP/CPS identifies two kinds of ORA for CAW 3.1:
Note:
For the remainder of this Trainee Guide, the role of the ORA is implied whenever the CA is mentioned except for the signing of a certificate or a CRL.
2.1.5 Cryptographic Domains
The MISSI domain is set up with four separate cryptographic domains: (1) Sensitive But Unclassified, (2) Secret, (3) Top Secret, and (4) Sensitive Compartmented Information. (See Figure 2-2.) The unclassified and classified domains use the same cryptographic algorithms, but have different universals to define each domain. This means that end users (and PCAs and CAs), in one domain, are unable to decrypt messages which are sent by an end user in another domain.
Figure 2-2. MISSI Establishes Four Cryptographic Domains
All PCAs within a single cryptographic domain must operate under a common security policy. All CAs subordinate to a PCA must operate consistently with that common policy as administered by the PCA.
Given the global interconnection of MISSI components, all CAs must operate in a secure and trusted manner. Otherwise, the integrity and reliability of the system can be degraded.
2.2 DoD CMI Information System Security Policy
The primary goal of the CMI is to provide management related security services in the following environments:
The MISSI CMI security policy is provided as a listing of 16 security countermeasures and principles in Section 6 of the "Information System Security Policy and Certification Practice Statement for Certification Authorities." These requirements have guided the development of the specific technical and procedural controls described in the remainder of Module 2 and are being followed throughout the DoD.
A summary of the 16 security countermeasures and principles is given below.
Access Control. Every operator within the CMI may only access that information, material, or capabilities necessary to perform their duties.
Audit. Reviews of system records and operator activities will be performed by an independent agent to ensure compliance with established policy. Modification or destruction of audit information is prevented.
Cryptography. The CMI provides a means to encrypt and decrypt security sensitive information.
Tracking/Accounting. The status and location of all sensitive information and material that the CMI produces is tracked.
Integrity Checks. Software, hardware, data, keys, and certificates are protected from accidental or malicious alteration.
Protective Technologies. Tamper-evident features and materials are used to deter and detect tampering with information processing equipment and cryptographic material.
Procedure. Policy, doctrine, and operational instructions will be followed in operating the CMI. The CA executes his/her duties in response to a valid end user request.
Information Sensitivity. A private key takes on the classification of the data it is used to protect. These classifications include: UNCLASSIFIED; SENSITIVE-BUT-UNCLASSIFIED; CONFIDENTIAL; SECRET and TOP SECRET. Other information generated by the CMI is, in general, UNCLASSIFIED.
CMI Operating Modes. The CMI shall evolve to achieve a multi-level secure mode of operation.
CMI Workstations. The hardware and software which comprise the CAW are approved by the NSA.
Personnel Security. All persons with unattended access to a CMI component must be highly responsible and trustworthy. All persons who operate a CAW must have a clearance at least equal to the classification level of the certificates/keys which they generate.
Personnel Training. All CAs must be trained in the operation of the CAW and the applicable security procedures.
Identification and Authentication. All CMI elements and operators are uniquely identified and registered. Authentication of identity is necessary for accessing the CMI, validating messages, and recording actions.
System Backups. All CMI elements perform periodic system backups.
CMI CAW Facility. CAW hardware and software must be protected from misuse and modification. The CA's FORTEZZA card and PIN must be protected against unauthorized use.
Archive. A tamper-proof facility maintains all valid, revoked, and compromised keys for everyone from the PAA down to the end user for the previous thirty years.
2.3 CAW Roles Defined
The CAW is a dedicated special purpose device that must not be used for any other purpose. As such, only authorized personnel may have the ability to physically access the room where the CAW is located. The physical facilities for housing the CAW are defined in the ISSP/CPS.
No single individual has complete access to the system. Administrative
responsibilities for the CAW are divided into three roles which may be assigned
to two or three individuals. These three roles are:
The CAW is most secure if three different individuals perform these roles. However, the SA and ISSO roles may be combined if these roles cannot be assigned individually.
2.3.1 System Administrator
The System Administrator is responsible for the following:
2.3.2 Information System Security Officer
The Information System Security Officer is responsible for the following:
2.3.3 Certification Authority
The MISSI Certification Authority plays a central and critical role in the
secure functioning of the network environment. Potentially, millions of end
users will rely on CAs to acquire and maintain certificates and FORTEZZA
cards for secure communications. Think of the CA as a role which can be performed
by more than one person for any particular CAW. The CA's role is described
in detail in the following documents:
The importance of the CA's role cannot be stressed too strongly. The CA provides an end user's signature key (their identity on the network) used to sign requisitions, battle orders, personnel reviews, and innumerable other important documents. If the CA follows established procedures and sets up the end user's certificate and FORTEZZA card properly, these communications will occur flawlessly. If the CA fails to set up and maintain the certificates and cards properly, the end users will be unable to sign or verify their documents. Worse -- a malicious end user may be able to forge a signature and send a false document. The results could be devastating. Consider what might happen in time of war, if the enemy knew our private signature keys.
2.3.3.1 Qualifications
The CA must be a person of unquestionable loyalty, trustworthiness, and integrity. In addition, the CA must be a U.S. citizen and possess a security clearance at or above the level of the material for which the certificates are being generated. All CAs must sign a statement in which they consent to a non-lifestyle polygraph if deemed necessary.
A CA for DoD must:
The person performing the CA role must be trained to operate the CAW, the system hosting the CAW, and the security procedures of the "Information System Security Policy and Certification Practice Statement for Certification Authorities." This course provides that training. The PCA must receive evidence of proper training before delivering a FORTEZZA card to the CA.
Any CA, SA, or ISSO operating against the policies and procedures stated in the "Information System Security Policy and Certification Practice Statement for Certification Authorities," whether negligently or maliciously, is subject to administrative discipline and possible criminal prosecution.
2.3.3.2 Responsibilities.
Figure 2-3 illustrates the relationship of the CA to other entities within
the CMI. Six of the ten major CMI functions detailed in the ISSP/CPS are
the direct responsibility of the CA. These are as follows:
Additionally, the CA is responsible for maintaining key records (digital and hardcopy) detailing his certification activities.
Figure 2-3. The CA is the primary interface to the end user within the MISSI Infrastructure
2.4 Technical Controls on Security
When the CA creates an end user certificate, the CA can ‘Save X Values. This function stores the end user’s KEA private key in the CAW 3.1 database. To minimize the risks associated with any one individual having access to private key information, the CAW 3.1 enforces a "two-party" mechanism, called Two Party Key Control (TPKC), to extract the private key from the database. These two parties, usually the CA and the ISSO, must be identified with a picture ID and made known to the PCA before establishing the CAW. This is so the PCA can include the necessary information as part of the CAW configuration file.’ Whenever it is necessary to extract a private key from the database, both parties must be present, and both must insert their FORTEZZA cards into the CAW. Key extraction is a relatively rare operation that occurs only when an end user's FORTEZZA card is rebuilt. The CAW software cannot, by policy, save the end user’s DSS key.
The PCA creates and signs a configuration file that is delivered with the CA's FORTEZZA card. This defines the privileges that are granted under the PCA's domain. The CAW 3.1 then ensures that CAs and end users will be able to perform only the actions that they are authorized to perform.
The CAW 3.1 has been reviewed/evaluated/tested by NSA to ensure its proper operation and resistance to natural and human threats. No modification to the CAW 3.1 platform (application, operating system, hardware) is permitted without written permission by the PCA. The CAW application is designed to detect improper software execution and database record modification.
2.5 Procedural Controls on Security
The ISSP/CPS establishes procedural controls on security associated with the CMI functions discussed above in Section 2.3.3.2. Each of these are discussed in the following sections.
2.5.1 End Entity Registration
Registering an end user means recording and validating the information necessary
to issue a certificate and set up a FORTEZZA card. Whenever a new end user
needs to be registered, the registration process must ensure the following:
The CA operates in conjunction with the end user's supervisor, Sub-Registration Authority, and local security officer to accomplish these tasks.
End user registration may be initiated by: end users, a CA/ORA, or another organizational authority setting up a local area network (LAN). In each of these cases, the process differs somewhat.
2.5.1.1 End User Initiated Registration.
An end user initiated registration process is shown in Figure 2-4. An end user may request registration by explaining to the local CA/ORA why they need a certificate.
The end user must present an official picture ID such as a driver's license, military or government civilian ID which is recorded on the X.509 Certificate Request Form by the CA/ORA.
Figure 2-4. End User Initiated Registration
The CA/ORA must also verify the end user’s need to be registered with the requested set of privileges. To do this, the CA/ORA may have prior knowledge or access to records which allow verification of need and privileges. Alternatively, the CA/ORA may contact the end user's supervisor and/or the organization's Security Officer to obtain this verification.
Finally, the CA/ORA must have the end user fill out and sign the X.509 Certificate Request Form (see the unit on "The CA" in Module 3). The end user’s supervisor or security officer then signs the form as the authorizing official.
Figures 2-4, 2-6, and 2-7 combine the roles of the CA and the SORA for end user registration. Figure 2-5 shows the actual interface between the CA and the SORA for registering end users. Remember, the SORA does everything the CA does -- except sign certificates and build CRLs. The SORA’s major responsibility is to help the CA register end users. The SORA validates each registration request and then creates the certificate. The certificate is forwarded to the CA as an encrypted MMP User Registration Request for signing. The CA decrypts the User Registration Request and verifies the SORA’s signature. Next, the CA signs the certificate and sends it back to the SORA as an encrypted MMP User Registration Response. Finally, the SORA decrypts the User Registration Response, verifies the CA’s signature, loads the certificate onto the end user’s card and distributes the card (and PIN, if necessary) to the end user. This process is the same regardless of who initiates the registration request.
Figure 2-5. CA/SORA Interface
2.5.1.2 CA/ORA Initiated Registration
When a CA/ORA initiates the end user registration process (see Figure 2-6), presumably, a decision was made to give the end user some set of privileges. Perhaps some organizational authority (e.g., supervisor or base commander) gave the CA/ORA a list of individuals to be registered along with their privileges.
The CA/ORA first approaches the end user and asks for an official picture ID to verify that this is the correct individual. The CA/ORA explains to the end user that they are being processed to receive their FORTEZZA card. The end user fills out and signs the X.509 Certificate Request Form. The organizational authority signs the form as the authorizing official. A NORA must mail or hand-deliver the request to the CA/ORA if they are the intiator. The CA/ORA may then create a certificate for the end user, and program the FORTEZZA card and deliver it to the end user.
Figure 2-6. CA/ORA Initiated Registration
2.5.1.3 Registration Initiated by Other Organizational Authority
If a supervisor or other organizational authority initiates the registration, they must approach the individual end user(s) and have them fill out and sign a X.509 Certificate Request Form, as shown in Figure 2-7. (Presumably the initiator has established the need for the registration, and knows the individual so that identification is not required.) The organizational authority then signs the form as the authorizing official. The form is then sent to the CA/ORA for processing as described in previous paragraphs.
The CA/ORA has not yet verified the identity of the end user personally. When the CA/ORA delivers the FORTEZZA card to the end user, he/she must ask the end user for an official picture ID such as a driver's license, or military or government civilian ID.
Figure 2-7. Registration Initiated by Other Organizational Authority
2.5.2 FORTEZZA Cards and PINs
The FORTEZZA cryptographic card is the common element in all MISSI components such as workstations, guards, and trusted database servers. It provides the necessary cryptographic services to send and receive messages. It also serves as a personal repository for the end user's certificate and the authorities’ certificates in their certification path. In addition, the FORTEZZA card provides a secure environment for storage of an end user's private keys. Being such a critical item in the secure functioning of a MISSI network, it is vital that the cards are programmed properly, and the certificates are properly maintained -- both on the card and in the directory.
Recall from the unit on "FORTEZZA Cards," FORTEZZA cards can support two types of applications: (1) Sensitive but Unclassified (SBU), (2) and Classified Cards which are used to support classified applications up to TOP SECRET/Sensitive Compartmented Information.
A previously used SBU FORTEZZA card, which is still functional, may be reused for SBU certificates. All stored information on the card must first be zeroized by the CA, and the CA must verify that all certificates which were previously stored on the card have been revoked or are expired. A new SBU card may not be created using a previously used Classified card.
A new SECRET Card may be created using either a new, previously unused card, or a previously used but zeroized SECRET card. A new TOP SECRET card may be created using either a new, previously unused card, or a previously used but zeroized TOP SECRET card. A new Classified card cannot be created using a previously used SBU card.
2.5.2.1 FORTEZZA Card Initialization
Once the end user has completed the registration process, the CA may create
a certificate for the end user, and initialize and program the FORTEZZA card.
The CAW software performs most of the steps required to activate the FORTEZZA
card as follows:
The Card is now initialized and can be loaded with the end entity’s approved private keys and certificates.
2.5.2.2 Public/Private Key Pairs
A word about the public/private key pairs. The FORTEZZA uses the random seed
to generate public/private key pairs:
The private KEA key is backed up in the CAW database. The private DSS key, in accordance with policy, is not backed up.
The CAW also assigns a Key Material Identifier (KMID) to the certificate. The KMID is used to identify a pair of keys if the private key needs to be designated as compromised on a CKL. There is one KMID for a public and private key per key pair - KEA or DSS. Both keys in the pair are invalidated if the KMID is listed on the CKL.
2.5.2.3 Certificate Generation
Using the information gathered on the X.509 Certificate Request Form, the CA now generates an X.509 Certificate. Think of the certificate as a specifically formatted data structure (or string) as shown in Figure 2-8.
It is used to bind the end user’s public key with their identity (Distinguished Name) in a trustable association.
The last field, in the completed certificate, is the CA’s signature. The certificate is signed with the CA’s private signature (DSS) key.
Then, the CA loads the certificate onto the initialized FORTEZZA card and posts the certificate to the directory. This is how others obtain the end entity’s public key. The CA must attach a label to the card after the certificates are loaded on the FORTEZZA card. Labels are printed locally by the CAW, and must be clearly marked to easily distinguish the classification of the card.
Figure 2-8. End User X.509 Certificate Format
2.5.2.4 Organizational Certificates
Beginning with CAW Release 3.1, the CA can generate a group of certificates known as a "family of organizational certificates." This capability is in support of the Defense Message System and allows multiple persons to handle messages on behalf of a single organization. Each person can decrypt and read organizational messages and sign, encrypt, and send organizational messages. In addition, each person has a unique signature, so any action can be traced to a specific person.
The first certificate in the family of organizational certificates is the "first-born"; the rest of the family consists of "other siblings." Typically, the first-born is the published DN to which all organizational messages are addressed.
2.5.2.5 Personal Identification Numbers
Figure 2-9 summarizes the PIN length and character requirements for FORTEZZA
cards. PIN length and character requirements differ depending on the card’s
intended use and the highest classification of the private keys stored on
the card. The PIN length for end user FORTEZZA card is seven numeric characters.
The PIN length for CA FORTEZZA cards (both SBU and Classified) must be exactly
twelve alphanumeric characters. The SSO PIN length for all FORTEZZA cards
(SBU/Classified and end user/CA) must be exactly twelve alphanumeric
characters.
| Card Owner | PIN Type | PIN Length | Character Type |
| End User | User |
7 |
Numeric |
| SORA | User |
7 |
Numeric |
| CA | SSO |
12 |
Alphanumeric |
Figure 2-9. FORTEZZA Cards have different PIN lengths and character types depending on the card’s intended use and classification.
2.5.2.6 Duplicate Cards
The CA is always given a duplicate card. End users may request a duplicate card but the need must be justified on the X.509 Certificate Request Form. Duplicate cards must be locked up in an approved container/location controlled by the owner of the card. The PIN must be stored in a separate location.
2.5.3 FORTEZZA Card/PIN Distribution
Once the FORTEZZA card has been loaded, it must be delivered to the end user.
The corresponding PIN must also
Figure 2-10. The FORTEZZA Card and PIN must be delivered
to the end user separately.
2.5.3.1 Delivery of an end user’s FORTEZZA Card
It is desirable for the CA or ORA to personally deliver the card to the end user. In this scenario, the end user must provide an official picture ID such as a driver's license, military or government civilian ID before taking possession of the card. The CA or ORA may ship the card via an approved method (e.g., registered mail with a signed receipt required) if personal delivery is impossible. In this case, the CA must advise the end user of the ship date, the method of shipping, and the expected date of arrival. In either case, a FORTEZZA User Advisory Statement and Receipt is delivered with the card. The end user must sign and return the receipt to the CA after receiving both the FORTEZZA card and the PIN.
2.5.3.2 Delivery of PINs
It is desirable for the end user to pick up the PIN from the individual who is assigned to distribute it. In this case, the end user must present an official picture ID such as a driver's license, military or government civilian ID. The PIN may be sent to an address provided by the end user, via first class mail, if personal pickup is impossible. It is recommended that this address be different from the address to which the FORTEZZA card is mailed. If this is impossible, the PIN must be mailed with a delay of three days after the card is mailed. The end user must sign and return the FORTEZZA User Advisory Statement and Receipt after receiving both the card and the PIN.
2.5.3.3 Delivery of the CA and TPKC Cards and PINs
SBU cards are created and distributed by the PCA using the same procedures as described for end user SBU cards. An exception occurs when there must be a shipping receipt signed by the CA (for end user SBU cards, the shipping receipt may be signed by anyone). The CAW configuration and inventory files are also shipped with the card.
The CA's PIN letter is sent to the CA's organizational address via registered mail. This address should be different from the address to which the FORTEZZA card is mailed. The CA must personally sign for the PIN letter, and the shipping receipt is sent back to the PCA.
Classified cards are created by the PCA and distributed to the COMSEC Custodian. They are tracked via the CMCS as an ALC-1 item. The short title of the classified CA FORTEZZA cards is KOV-13.
PIN distribution is handled the same as for Unclassified CA FORTEZZA cards.
2.5.4 FORTEZZA Card Handling and Maintenance
As explained in paragraph 2.5.3, cards may be set up as either Sensitive But Unclassified, or FORTEZZA for Classified. All FORTEZZA cards must be treated with care and protected to prevent compromise or unauthorized use. Of course, requirements for SBU cards are less demanding than those for Classified cards. End users must be informed of the guidelines for protecting their card and PIN when the card is given to them. Guidelines are listed below for both the SBU and Classified cards.
Details of card handling requirements are given in NAG 66 and 68 for SBU and FORTEZZA for Classified (FFC) cards respectively.
2.5.4.1 End User SBU FORTEZZA Card
The following guidelines apply to an end user with an SBU FORTEZZA card.
2.5.4.2 End User Classified FORTEZZA Card
The following guidelines are in addition to, or in replacement of, those
listed under "SBU FORTEZZA Card - End User."
2.5.4.3 CA SBU FORTEZZA Card
A CA’s SBU FORTEZZA card is subject to the guidelines listed in paragraph
2.5.4.2 as well as the following requirements:
2.5.4.4 CA Classified FORTEZZA Card
In addition to the end user Classified and CA SBU criteria listed above, a CA’s Classified FORTEZZA card is subject to the following additional requirements:
2.5.5 Certificate Revocation and Key Compromise
2.5.5.1 Certificate Revocation
A certificate becomes invalid when its validity period expires. Anyone who wishes to use this certificate to encrypt a message or verify a signature can determine that it has expired by checking the validity period in the certificate.
However, there are other events which may occur to cause a certificate to become invalid before it expires (see Figure 2-11). When any of these events occur, the invalid certificate identifiers must be electronically posted in a public location where all network end users can find them. A Certificate Revocation List (CRL) is used for this purpose. The CA (or PCA or PAA) who issued the invalid certificate adds the certificate to a CRL, and posts then the CRL in the directory (DSA). The posting must occur within one working day after the CA (or PCA or PAA) is notified of the need for revocation. Once placed on a CRL, a certificate remains there until it expires.
Figure 2-11. Several events can occur that cause a certificate to be revoked.
The following data is contained in a CRL:
2.5.5.2 Key Compromise
Private keys may be compromised, rendering them invalid. When this occurs, the PCA under which the compromised key was issued, is notified. Then, the PCA adds the KMID for the key to the CKL. The PCA pushes the CKL to each of its subordinate CAs by the most expeditious means (e.g., e-mail). Then, the CAs expeditiously pushes the CKL to each of their end users. The CKL is also posted in the directory (DSA). Whenever a key is placed on a CKL, the corresponding certificate is revoked via a CRL. The CA must generate and electronically post the CRL.
CRLs are issued every four weeks. A CRL that is issued as the result of a key compromise must be posted within one working day after notification of the compromise. The CA must also distribute the CKL to the end users within one working day.
Conditions Requiring Key Compromise Processing
The PCA updates the CKL by adding the KMID of the compromised key. The PCA
then posts the updated CKL to the directory and distributes it to each of
his subordinate CAs. The CA, upon receipt of the CKL, places the associated
certificate(s) on the CRL and distributes it. The CA must revoke the end
user's certificate(s) and notify the PCA if one of the following events
occur.
Conditions Requiring Certificate Revocation Only
The following conditions will cause the CA to place an end user's certificate
on the CRL:
Other Conditions
Authorized duplicate cards are maintained in the event the primary card fails. The use of duplicate cards must be controlled. Any time a change is made to one card, the same change must be made to any duplicate card. If certificates of an issuing authority (CA, PCA, or PAA) are placed on a CRL or KMIDs are placed on a CKL, all certificates issued under that authority are invalidated. All FORTEZZA cards programmed under that authority must be updated and new certificates issued. This is a catastrophic event, and should only be undertaken after serious forethought and investigation.
2.5.6 Record Keeping
The CAW database automatically retains a record of all certificates generated, including the end user name, location of end user, organization, date issued, serial number of the certificate issued, and serial number of the corresponding FORTEZZA card. The CAW, Release 3.1, is capable of generating a card report that lists cards in the CA’s database issued to MISSI users. The CA can use the card report to account for the cards the CA issued, thereby complying with the NSA policy requiring the CA to conduct a yearly inventory of the FORTEZZA cards issued to end users in his domain. Figure 2-12 shows the various types of records the CA is responsible to maintain. It is important to understand that these records must be kept current. They are subject to a PCA audit and their status is part of NSA’s recertification determination.
Figure 2-12. The CA maintains a variety of CMI records.
End users must read and sign a FORTEZZA User Advisory Statement and Receipt, as proof that the card and the PIN was received, and the end user is aware of basic FORTEZZA card security procedures. The end user returns this statement to the CA, who must retain it. The CA must also retain the X.509 Certificate Request.
It is the CA's responsibility to maintain the information necessary to track
SBU FORTEZZA cards which have been created with their CAW, once those cards
have been distributed. At a minimum, the following information should be
maintained for each card:
CA FORTEZZA cards which are Classified must be controlled within the CMCS as an ALC 1 item with a short title of KOV-13. They must be continuously accountable by individual chip serial number from the time of creation until final disposition is reported to NSA. CMCS control must begin when the card is set up by the PCAW with private keys and certificates.
2.5.7 Audit and Archive
2.5.7.1 Audit
The CAW 3.1 captures virtually all Certification Authority activity in either the CAW Release 3.1 event logs or the SCO CMW+ audit log. These are reviewed weekly by the ISSO. This is sometimes the last defense in the security of the system, as it permits detection and correction of any security violations which slip past other security mechanisms. When the system has been compromised, audit logs help determine the degree to which the system was penetrated.
The audit log is stored as a protected file on the workstation. Only authorized
personnel are allowed to view the file. Periodically, security relevant
information from the audit log is archived to a long term storage medium,
and the logs are deleted. The CA is not involved in reviewing or archiving
audit logs.
The CAW 3.1 records the following events in the audit log:
2.5.7.2. Archive
The following items are archived:
2.6 CAW Environment Controls
The ISSP/CPS requires a minimal level of protection for the facility in which
the CAW is operated. The facility housing the CAW should be visually checked
once a day.
Module 2. Acronyms and Description List
|
ACRONYM |
DESCRIPTION |
| AA | Audit Agent |
| CA(W) | Certification Authority (Workstation) |
| CKL | Compromised Key List |
| CMI | Certification Management Infrastructure |
| CMW+ | Compartmented Mode Workstation |
| COMSEC | Communications Security |
| CRL | Certificate Revocation List |
| DMS | Defense Messaging System |
| DN | Distinguished Name |
| DOD | Department of Defense |
| DS | Directory System |
| DSA | Digital Signature Algorithm |
| DSA | Directory System Agent (Service) |
| DSS | Digital Signature Standard (Security) |
| FFC | FORTEZZA For Classified |
| ID | Identification |
| INFOSEC | Information Security |
| IP | Internet Protocol |
| ISSO | Information System Security Officer |
| ISSP/CPS | Information Systems Security Policy/Certification Practice Statement |
| KEA | Key Exchange (Encryption) Algorithm |
| KEK | Key Encryption Key |
| KMID | Key Material Identifier |
| Ks | Storage Key |
| LAN | Local Area Network |
| MISSI | Multilevel Information System Security Initiative |
| MMP | MISSI Management Protocol |
|
ACRONYM |
DESCRIPTION |
| NAG | Noncryptographic Operational Guide |
| NORA | No PIN Organizational Registration Authority |
| NSA | National Security Agency |
| ORA(W) | Organizational Registration Authority (Workstation) |
| PAA(W) | Policy Approving Authority (Workstation) |
| PCA(W) | Policy Creation Authority (Workstation) |
| PC | Personal Computer |
| PIN | Personal Identification Number |
| SA | System Administrator |
| SBU | Sensitive But Unclassified |
| SCI | Sensitive Compartmented Information |
| SCO | Santa Cruz Operation Incorporated |
| SORA | SSO PIN Organizational Registration Authority |
| SSO | System (Site) Security Officer |
| TPKC | Two Party Key Control |
| WAN | Wide Area Network |