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.


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



[NSA] Maryland Procurement Office


Government Systems Operations

Motorola Inc.

Space and Systems Technology Group

8201 E. McDowell Road

Scottsdale, Arizona 85257





Carl Boos Holly Moyer
LCS Systems Engineer LCS Project Leader



Tom Grimes
Program Manager

Government Systems Office



CAW 3.1

Users Training Course


Security Policy




Revision History






22 July 1997


Incorporates updated forms and procedures

22 October 1997


Module 2. Security Policy and Practices

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 Hierarchy

2.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:

  1. SSO-PIN ORA (SORA): The SORA performs all functions normally associated with the CA, except the actual signing of the certificates and building of CRLs. The SORA completely generates a certificate and then forwards it to the CA as an MMP Certificate Generation Request. The CA validates and signs the certificate and returns it to the SORA as an MMP Certificate Generation Response. The SORA then loads the certificate on the FORTEZZA card and delivers it and the PIN to the end user.
  2. No PIN ORA (NORA): The NORA is an administrative helper to a CA and performs no card management functions. Since the NORA does not have access to the end-user cards, there are no special personnel constraints placed on the NORA The CA must verify the person’s identity and ID picture, before registering that person as a NORA.


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:

  1. The System Administrator (SA),
  2. The Information System Security Officer (ISSO), and
  3. The Certification Authority.

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. 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. 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 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. 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 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 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. 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:

  1. First, take a new FORTEZZA card and login using the factory default SSO PIN.
  2. The CAW generates the USER PIN and a new SSO PIN .

    The PINs are randomly generated by the CAW. An important part of the ISSP security measures is to generate these PINs in such a manner that the CA cannot see them. To prevent this, the PIN is never displayed on the CAW and the CA cannot access the PIN database unless the end user’s card is in the workstation.


    CAW Release 3.1 permits the CA to view PINs and access the database if the privilege is permitted by the PCA.

    3. Next, the CAW generates the Card Storage Key (Ks).

    4. The CAW then loads a random number seed value used for generating public/private key pairs.

    5. A record of the card is now created in the CAW database holding the card’s serial number.

    6. Finally, the CA sets the card’s internal clock.

The Card is now initialized and can be loaded with the end entity’s approved private keys and certificates. 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. 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 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. 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










Figure 2-9. FORTEZZA Cards have different PIN lengths and character types depending on the card’s intended use and classification. 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

  1. The FORTEZZA card must be delivered to the correct individual. This is ensured by either the CA/ORA delivering the card in person, or sending it via an approved method, such as registered mail, which requires a signed return receipt.
  2. The card and PIN must be delivered or mailed separately, and must never be physically together until they are in the possession of their owner/end user. (See Figure 2-10.)
  3. The card should not be tampered with during delivery and the PIN should not be compromised. The end user must notify the CA/ORA if there is evidence of tampering.

Figure 2-10. The FORTEZZA Card and PIN must be delivered
to the end user separately. 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. 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. 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. End User SBU FORTEZZA Card

The following guidelines apply to an end user with an SBU FORTEZZA card. End User Classified FORTEZZA Card

The following guidelines are in addition to, or in replacement of, those listed under "SBU FORTEZZA Card - End User." CA SBU FORTEZZA Card

A CA’s SBU FORTEZZA card is subject to the guidelines listed in paragraph as well as the following requirements: 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 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: 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 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: 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.

  1. If the CAW is not in use, the FORTEZZA card should be physically removed and securely stored. The CAW should be properly safeguarded and all physical security systems should be operable.
  2. If the facility is not continuously used, the security check should be accomplished by the last person to leave. The check should ensure that the FORTEZZA card is removed from the CAW and properly stored, the area is safeguarded against unauthorized access, and any intrusion detection systems are activated.
  3. A facility that is unoccupied for periods longer than 24-hours should be checked at least once a day.
  4. FORTEZZA cards must be properly stored in accordance with their security classification. PINs should be memorized. However, the PIN can be written down if it is stored in a safe location separate from the FORTEZZA card.
  5. In addition to the above, the protection of Classified CAWs must be in accordance with the physical protection requirements defined for their level of classification.

Module 2. Acronyms and Description List



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



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