5 February 1997
Source:
http://WWW.armadillo.huntsville.al.us/Fortezza_docs/current.html#basic
Version 1.0
2 January 1997
Prepared By:
(410) 859-4463
This specification defines the basic requirements for all FORTEZZA-Enabled software applications. All software applications that have been modified (or "enabled") to use the FORTEZZA Cryptographic Card (hereafter called the Card) shall meet these basic requirements. This specification and the references listed at the back of this document are to be used in developing FORTEZZA applications. Government testing for compliance with FORTEZZA application requirements will be based on the mandatory requirements and implemented recommended requirements in this specification and available application-specific FORTEZZA requirements (defined in separate specifications). The detailed testing requirements (derived from this document) will be defined in basic and application-specific certification test plans and procedures.
The document is divided into three sections: mandatory requirements, recommended requirements, and optional features.
Mandatory requirements shall be met by an application in order to pass certification testing by the Government and request to use the NSA-registered FORTEZZA-Enabled Certification Mark. If the vendor has a circumstance that would warrant Government consideration of a requirement waiver, the vendor may make a written request to the National Security Agency. The Government shall post information regarding changes to these requirements. Vendors shall incorporate new requirements in the next release/update to their product. Complete re-testing or regression testing shall be performed on all versions of applications as possible. Vendors that choose not to re-certify may lose the right to use the FORTEZZA-Enabled Certification Mark.A recommended requirement does not have to be implemented, but if it is, it shall meet the requirement statement. Vendors shall indicate to the Government which of these requirements, if any, were implemented.
Optional features describe functionality that the Government would like to see in a product. This list does not necessarily represent all the extra security features users may desire.
This specification applies to all FORTEZZA-Enabled applications designed to use Multilevel Information Systems Security Initiative (MISSI) Version 1 X.509 certificates, MISSI Version 1 Certificate Revocation Lists (CRL) and MISSI Compromised Key Lists (CKL). This specification will be updated to apply to the use of MISSI Version 3 X.509 certificates and Version 2 CRLs.
General background information about the FORTEZZA program can be found in the FORTEZZA Program Overview. More detailed information on system architecture and integration of the Card into a software application can be found in the FORTEZZA Application Implementors Guide.
The mandatory application requirements are divided into two general categories: client software requirements and server software requirements. Client software requirements apply to the FORTEZZA-Enabled software that runs locally on a user's workstation (e.g., electronic mail applications [Simple Mail Transport Protocol (SMTP) and X.400], web browsers, File Transfer Protocol (FTP) clients, etc.). Server software requirements apply to the FORTEZZA-Enabled software that runs unattended on a server (e.g., web servers, FTP servers, Directory System Agents, etc.). Any software resident on a server that includes the capability for a user to perform security functions shall meet the client requirements. Each FORTEZZA-Enabled application may be composed of either client software, server software, or both. Each category of requirements applies only to the software that was modified to interface to the Card. For example: A SMTP electronic mail application can be enhanced to support FORTEZZA. The e-mail application functions using both client software that resides on the user's workstation and server software that resides on the mail server. The client software must be enhanced to use the Card, but the server software does not need to be modified since it does not interface with the Card. Therefore, only the client software requirements would apply to this e-mail application.
1. The application shall include a FORTEZZA compliant Device Driver for those hardware platforms that require device drivers. The list of FORTEZZA compliant device drivers can be obtained from the Government in addition to the Government-owned FORTEZZA device drivers.
2. The application shall implement a FORTEZZA compliant Cryptologic Interface (CI) Library. The list of FORTEZZA compliant CI Libraries can be obtained from the Government in addition to the Government-owned FORTEZZA CI Libraries.
3. The application shall interface to, and function with, any Government certified FORTEZZA Cryptographic Card. The list of compliant Cards can be obtained from the Government.
a. The application shall use the FIPS 185 compliant Skipjack confidentiality algorithm on the Card for symmetric encryption and decryption of data.b. The application shall use the Key Exchange Algorithm (KEA) key exchange algorithm on the Card for asymmetric encryption and decryption of keys.
c. The application shall use the FIPS 180-1 compliant Secure Hash Algorithm (SHA-1) data integrity algorithm on the Card or in software for data hashing.
d. The application shall use the FIPS 186 compliant Digital Signature Algorithm (DSA) signature algorithm on the Card for generating digital signatures.
e. The application shall use the FIPS 186 compliant Digital Signature Algorithm (DSA) signature algorithm on the Card or in software for verifying digital signatures.
f. The application shall use the Random Number Generator on the Card as the source for all random numbers used in cryptographic processing.
4. The application shall detect if two or more Cards are in the computer.
a. The application shall prompt the user to select which Card to login.b. The application shall present the user with the Slot Number and the Card cryptographic engine serial number when selecting a particular Card (at a minimum).
5. The application shall prompt the user for a Personal Identification Number (PIN) and supply the PIN to the Card to enable the Card.
a. The user shall be notified if the PIN authentication process fails.b. The PIN value shall not be displayed to the user.
c. The PIN value shall not be stored in any way for the user or any process.
d. The PIN value shall not be provided to another application or user.
e. The PIN value in memory space shall be overwritten after a successful login.
6. The application shall allow the user to select the Card personality from a displayed list of personalities retrieved from the Card or default to a previously selected personality.
a. The application shall only display to the user the personalities with the following Usage/Equipment Specifiers: INKS, INKX, ONKS, ONKX. All other Usage/Equipment Specifiers shall be not be displayed.b. The application shall display the 24 byte Certificate Label Field of the displayed personalities to the user.
c. The application shall not display the four byte Parent Certificate Index to the user.
d. The application shall interpret the four byte Usage/Equipment Specifier as follows when displaying the personalities: "INKS" is "Individual", "INKX" is "Indiv Read-Only", "ONKS" is "Organizational", and "ONKX" is "Org Read-Only".
e. If the application supports pre-selected personalities, the application shall verify that the certificate in that card slot is the same as the pre-selected personality. This check is performed in case the Card has been reprogrammed.
(1) If the pre-selected personality is no longer found on the Card, the application shall prompt the user to select a personality from a displayed list retrieved from the Card.
7. The application shall allow the user to change Card personalities without having to restart the application or re-enter the Card PIN.
8. When displaying Card certificate slot information to the user for other than personality selection:
a. The application shall display the 24 byte Certificate Label Field to the user.b. The application shall interpret the four byte Usage/Equipment Specifier as follows: "RRXX" is "PAA", "RTXX" is "PCA", "LAXX" is "CAW", "INKS" is "Individual", "INKX" is "Indiv Read-Only", "ONKS" is "Organizational", and "ONKX" is "Org Read-Only". Expansion of acronyms is acceptable.
c. The application shall display the uninterpreted four byte Usage/Equipment Specifier for all unrecognized cases.
9. The application shall allow the user to logout and login to the Card without having to restart the application.
10. The application shall handle and process all CI Library error codes as non-fatal errors so that all expected (typical and atypical) Card and system situations are properly handled (i.e., displayed to the user).
11. The application shall only write information in available empty Card certificate spaces with explicit user permission.
12. The application shall close the socket to the Card when access to the Card is no longer needed (i.e., the application is closing).
1. The application shall include security function and configuration information for the user (i.e., help and readme files).
2. The application shall only use the Card Ks key for encrypting another key (i.e., a token containing a Message Encryption Key), not for encrypting data.
3. The application shall locally maintain MISSI Compromised Key Lists (CKL) and Certificate Revocation Lists (CRL). CKLs and CRLs accessible from a local network meet this requirement.
4. The application shall log the user out of the Card by automatically closing the socket when the application is inactive for a user-specified or default time period.
5. The application shall allow the originator to select the security services (protection) to be performed.
6. The application shall allow the originator to specify the classification of the data prior to or when performing encryption. Valid data classification labels are: Unclassified, Unclassified But Sensitive, Confidential, Secret and Top Secret.
7. The application shall check the user selected data classification against certificate classification permissions to verify that both the originator and recipient have that clearance authorized in their certificates before encrypting data.
a. If the clearance is not authorized for a certificate, the user shall be notified that the clearance is unauthorized for a specified certification path and security processing shall stop.
8. Upon successful authentication or verification of protected data, the application shall:
a. Display to the user the originator's authenticated Distinguished Name (DN).b. Allow the user to view all the DNs in the originator's authenticated certification path.
c. Display to the recipient the classification of encrypted data after successful verification.
(1) The application shall check the data classification against the originator and recipient certificate classification permissions to verify that the clearance is authorized in their certificates before displaying the data.(a) If the classification check fails, the user shall be notified that the clearance is unauthorized and security processing shall stop.
9. The application shall display to the user a descriptive warning upon an unsuccessful security-related operation which states what operation failed and the apparent cause of the failure.
10. The application shall delete all temporary files that are created during encryption and decryption processing. This shall occur prior to the completion of both successful and unsuccessful processing.
1. The application shall, prior to using a private key and parameters, verify the certification path in accordance with requirement C.2. The certification path is composed of the certificate for the desired private key to a certificate signed by a MISSI trusted public key. A MISSI trusted public key and parameters are found in a certificate stored in a read-only Card slot.
2. The application shall:
a. Verify when signing data, for the user certificate, that the "Read-Only" signature privilege bit is not set.(1) If the "Read-Only" bit is set, the user shall be notified that the current personality can not be used to sign data and security processing shall stop.
b. Verify when decrypting data, for the user certificate, that the "Read-Only" signature privilege bit is not set.(1) If the "Read-Only" bit is set, the user shall be notified that the originator is unauthorized to encrypt data and security processing shall stop.
c. Verify, for each certificate in the certification path, that the Key Material Identification (KMID) does not appear on a current and valid CKL. A CKL is current if the current Card or system date falls within the Last Update and Next Update dates in the CKL.(1) If the current CKL is not available, the user shall be notified that the CKL is expired and instructed to obtain a new CKL and security processing shall stop.(2) If the KMID appears on the CKL, the user shall be notified that the personality is revoked and directed to notify their Certification Authority and security processing shall stop.
(3) If the CKL signature is invalid, the user shall be notified that the CKL is invalid and instructed to obtain a new CKL and security processing shall stop.
1. The application shall, prior to using a public key and parameters, verify the certification path in accordance with requirement D.2. The certification path is composed of the certificate chain from the certificate containing the desired public key to a certificate signed by a MISSI trusted public key. A MISSI trusted public key and parameters are found in a certificate stored in a read-only Card slot.
2. The application shall, for each certificate in the certification path, verify that:
a. The signature on the certificate is valid based on the public key and parameters found in the subjectPublicKeyInfo field of the issuer's certificate.(1) If the signature on a certificate is invalid, the user shall be notified which certification path is invalid and security processing shall stop.
b. The current date falls within the certificate validity interval. A certificate is current if the current Card or system date falls within the validity period in the certificate.(1) If the date falls outside the validity interval, the user shall be notified which certification path is invalid and security processing shall stop.
c.The certificate serial number does not appear on a certificate issuer's current and valid CRL. A CRL is current if the current Card or system date falls within the Last Update and Next Update dates in the CRL.(1) If a certificate appears on a CRL, the user shall be notified which certification path has a revoked certificate and security processing shall stop.(2) If a current CRL is not available, the user will be notified when that CRL was valid, recommended to obtain a new CRL and given the option to proceed with that out of date CRL. The CRL signature shall still be checked.
(3) If the CRL signature is invalid, the user shall be notified which CRL is invalid and instructed to obtain a new CRL and security processing shall stop.
d. The Key Material Identification (KMID) does not appear on a current and valid CKL. A CKL is current if the current Card or system date falls within the Last Update and Next Update dates in the CKL.(1) If the current CKL is not available, the user will be notified that the CKL is expired and instructed to obtain a new CKL and security processing shall stop.(2) If the KMID appears on the CKL, the user shall be notified which certification path has a compromised certificate and security processing shall stop.
(3) If the CKL signature is invalid, the user shall be notified that the CKL is invalid and instructed to obtain a new CKL and security processing shall stop.
e. The certificate issuer is a valid issuing authority (PCA or CA).(1) If the issuer is not valid, the user shall be notified which certification path has an invalid certificate issuer and security processing shall stop.
f. The subject name in the issuer's certificate matches the issuer's name in the user's certificate.(1)If the names do not match, the user shall be notified which certification path has a certificate that was signed by an issuer other then identified in the subject certificate and security processing shall stop.
g. The initial portion of the subject DN is identical to the issuer DN, not including the terminal component of the issuer's DN. Name subordination is only checked from the CA to the user, the subordinate CA to the user and the CA to the subordinate CA.(1) If the name subordination check fails, the user shall be notified which certification path is not subordinate and security processing shall stop.
h. The clearance permission bits of the subject certificate are a subset of the clearance permission bits of the issuer certificate. Clearance subordination is not required from the Policy Approving Authority (PAA) to the subordinate PCA.(1) If the clearance level check fails, the user shall be notified which certification path has invalid clearance permissions and security processing shall stop.
1. The application shall include security function and configuration information for the user (i.e., help and readme files).
2. The application shall only use the Card Ks key for encrypting another key (i.e., a token containing a Message Encryption Key), not for encrypting data.
3. The application shall locally store, manage and maintain MISSI CKLs and CRLs. Local can be local network accessible.
4. The application shall allow the data classification to be specified prior to performing encryption. Valid data classification labels are: Unclassified, Unclassified But Sensitive, Confidential, Secret and Top Secret.
5. The application shall check the data classification against certificate classification permissions to verify that both the originator and recipient have that clearance authorized in their certificates before encrypting data for the recipient.
a. If the clearance is not authorized for a certificate, the application shall log the error and security processing shall stop.
6. The application shall check the data classification against the originator and recipient certificate classification permissions to verify that the clearance is authorized in their certificates before displaying the data.
a. If the classification check fails, the application shall log the error, security processing shall stop and any processing data shall be deleted and overwritten.
7. The application shall log unsuccessful security-related operations.
a. At a minimum, a log entry shall contain the event date and time, the operation that failed and the apparent cause of the failure.b. For certification path errors, the application shall also include in a log entry the DN of the failed certificate.
8. The application shall delete all temporary files that are created during encryption and decryption processing. This shall occur prior to the completion of both successful and unsuccessful processing.
1. The application shall, prior to using a private key and parameters, verify the certification path in accordance with requirement F.2. The certification path is composed of the certificate for the desired private key to a certificate signed by a MISSI trusted public key. A MISSI trusted public key and parameters are found in a certificate stored in a read-only Card slot.
2. The application shall:
a. Verify when signing data, for the user certificate, that the "Read-Only" signature privilege bit is not set.(1) If the "Read-Only" bit is set, the application shall log the error and security processing shall stop.
b. Verify, for each certificate in the certification path, that the Key Material Identification (KMID) does not appear on a current and valid CKL. A CKL is current if the current Card or system date falls within the Last Update and Next Update dates in the CKL.(1) If the current CKL is not available, the application shall log the error and security processing shall stop.(2) If the KMID appears on the CKL, the application shall log the error and security processing shall stop.
(3) If the CKL signature is invalid, the application shall log the error and security processing shall stop.
1. The application shall, prior to using a public key and parameters, verify the certification path in accordance with requirement G.2. The certification path is composed of the certificate chain from the certificate containing the desired public key to a certificate signed by a MISSI trusted public key. A MISSI trusted public key and parameters are found in a certificate stored in a read-only Card slot.
2. The application shall, for each certificate in the certification path, verify that:
a. The signature on the certificate is valid based on the public key and parameters found in the subjectPublicKeyInfo field of the issuer's certificate.(1) If the signature on a certificate is invalid, the application shall log the error and security processing shall stop.
b. The current date falls within the certificate validity interval. A certificate is current if the current Card or system date falls within the validity period in the certificate.(1) If the date falls outside the validity interval, the application shall log the error and security processing shall stop.
c. The certificate serial number does not appear on a certificate issuer's current and valid CRL. A CRL is current if the current Card or system date falls within the Last Update and Next Update dates in the CRL.(1) If a certificate appears on a CRL, the application shall log the error and security processing shall stop.(2) If a current CRL is not available, the application shall log the error and security processing shall stop.
(3) If the CRL signature is invalid, the application shall log the error and security processing shall stop.
d. The Key Material Identification (KMID) does not appear on a current and valid CKL. A CKL is current if the current Card or system date falls within the Last Update and Next Update dates in the CKL.(1) If the current CKL is not available, the application shall log the error and security processing shall stop.(2) If the KMID appears on the CKL, the application shall log the error and security processing shall stop.
(3) If the CKL signature is invalid, the application shall log the error and security processing shall stop.
e. The certificate issuer is a valid issuing authority (PCA or CA).(1) If the issuer is not valid, the application shall log the error and security processing shall stop.
f. The subject name in the issuer's certificate matches the issuer's name in the user's certificate.(1) If the names do not match, the application shall log the error and security processing shall stop.
g. The initial portion of the subject DN is identical to the issuer DN, not including the terminal component of the issuer's DN. Name subordination is only checked from the CA to the user.(1) If the name subordination check fails, the application shall log the error and security processing shall stop.
h. The clearance permission bits of the subject certificate are a subset of the clearance permission bits of the issuer certificate. Clearance subordination is not required from the Policy Approving Authority (PAA) to the subordinate PCA.(1) If the clearance level check fails, the application shall log the error and security processing shall stop.
1. If the application implements the reuse of a verified certificate, CRL or CKL instead of verifying the object again, then:
a.The application shall store a verified certificate, CRL or CKL in volatile memory.b. The application shall perform certificate, CRL or CKL reverification at least every 24 hours.
2. If the application provides integrated Directory User Agent functionality to allow the user to access Government X.500 Directory System Agents (DSA), then:
a. The application shall either use the Directory Access Protocol (DAP), as specified in CCITT X.500 (1993) Series of Recommendations and all parts of ISO/IEC 9594, dated 1993 to interface directly with a DSA, or use the Lightweight Directory Access Protocol (LDAP) to interface through a LDAP Server with a DSA.b. The application shall be capable of retrieving MISSI X.509 certificates, CKLs and CRLs for processing.
c. Automatically attempt to retrieve an object from a DSA to replace an invalid certificate, CKL or CRL before processing is stopped.
3. If the application logs unsuccessful security-related operations at the client, then:.
a. At a minimum, the application shall create a log entry that contains the event date and time, the operation that failed, and the apparent cause of the failure.b. For certification path errors, the application shall include in the log entry the DN of the failed certificate.
4. If the application implements the capability to verify digital signatures completely in software (without using the Card), then:
a. The application shall not use a MISSI trusted public key that was provided by the originator.b. The application shall provide a clear indication to the user that the certificate validation did not use the Card if the application is capable of using the Card.
c. The application shall verify that the signature of the MISSI trusted certificate is valid based on the public key and parameters found in the subjectPublicKeyInfo field of that same certificate.
(1) If the signature on the certificate is invalid, the user shall be notified which certification path is invalid and security processing shall stop.
Provide notification to the user when the Card changes state as defined in the Card Interface Control Document.
Always relinquish control of the Card when it is no longer needed (even temporarily). This allows context switching (enabling one application to gain and relinquish control of a Card in an environment where the Card is shared by multiple applications).
Implement the local cache database using the FORTEZZA Certificate Caching Schema so that a single user's local cache can be used by multiple FORTEZZA-Enabled applications.
Provide the user with the option to save received signed and encrypted data as a signed only data.
Provide a means to support archiving of encrypted data. Potential methods are re-encrypting the data encryption key with an archive key or with the local storage key (i.e., Ks key).
Provide the means for the user to view information in the: X.509 Certificate Structure (such as Validity Period, Clearances, and Privileges of certificates on Card or in local cache), CKL (such as the Last Update date and the Next Update date), and CRL (such as the Last Update date and the Next Update date).
Indicate to the user when CKLs and CRLs near expiration. 'Near' should be a user specified period of time.
Provide the option to configure the application to perform overwriting of all temporary data files created during encryption and decryption processing. Overwriting must occur prior to the completion of both successful and unsuccessful processing. Ideal overwriting would be writing a 55 pattern, an AA pattern, and then random data over the data. Writing random data would be the minimum.
Display to the user the DN of the specific certificate which failed a certification path check.
Check for a previously installed FORTEZZA compliant Device Driver. The application should automatically, with user notification, or manually, with user interaction, either use the previously installed device driver or install an updated device driver.
Provide the user the option of setting default security options and classification levels.
Provide a message classification menu.
Create and maintain an error log of all FORTEZZA related error conditions (clients).
Use the certificates retrieved from the following, in the given order as available, when verifying certificates for received data: the received data, the local certificate cache, and a DSA. If a certificate is found to be invalid during data processing, the application should search alternate locations for a valid version of the certificate.
Check the KEA p, q, and g values of the originator and recipient if a CI Library CI_Generate TEK function returns an error when encrypting data so that if the values are different, the user could be notified that encryption can not be performed for a specific reason.
Provide the option to configure the application to enforce a stronger security policy for invalid certificate processing where options are allowed.
Include in user documentation information on the purpose of using digital signature and encryption and examples of appropriate situations to clarify usage.
Include in user documentation a security disclaimer statement that the vendor is not responsible for the cryptographic processes on the Card and for data compromise when application software is executed on non-trusted computers with non-trusted operating systems.
FORTEZZA Program Overview, version 4.0a, February 1996.
FORTEZZA Application Implementors Guide, revision 1.52, 5 March 1996.
FORTEZZA Cryptologic Interface Programmers Guide, revision 1.52, 30 January 1996.
Interface Control Document for the FORTEZZA Crypto Card, revision P1.5, 22 December 1994.
ITU-T Recommendations X-500-X.521, Data Communications Networks: Directory, 1988.
MISSI Key, Privilege, and Certificate Management Plan, version 3.1, 11 September 1995, For Official Use Only.
SDN.701, Message Security Protocol (MSP), revision 3.0, 21 March 1994.
SDN.702, Directory Specifications for Utilization with the SDNS Message Security Protocol, revision 2.7, 26 August 1994.
[End]
Hypertext by JYA/Urban Deadline.
See related NSA MISSI site.